Chip said...
What would you rather have in a future Propeller chip:
Option·1: 16 cogs with 128KB of hub RAM. Hub access once every 16 clocks.
Option·2: 8 cogs with 256KB of hub RAM. Hub access once every 8 clocks.
Note that each cog would run at about 160 MIPS, as opposed to the current 20 MIPS.
Chip:
I've not still enough experience in propeller programming, but looking at the examples given at this forum, I could say that Option 2 is my choice ·now, 160 real MIPS sounds very very good !!.
I think that PChip is more than you want, in a simple microcontroller, it's·impressive power·generating video signals, like in VGA signal generation, but don't forget to give it more power at I/O and peripheral level, I think the reality is, that you can't have ALL capabilities in the same chip, the propeller have a lot yet. But, are you thinking to include some of this in the future·?? (UART, SPI, I2C, A/D....etc.).
So, more RAM (256Kb hub RAM) and perhaps more than 512 longs per COG could be great, together a 512Kb eeprom included ...Ohhh my god !!.......sorry.
I think too, that is not necessary more I/O pins, you can expand those easily, and maintain the actual PIN2PIN structure. (I don't know ...what you'll do with all "B" registers......).
"I'm agree, with·the engineers that are doing with the famous 8051 architecture"
I would like option 2. With each cog running at 160 MIPS, we would have about 8 times the speed as before. With all that speed, we need more RAM to take advantage of it.
Leaves things deterministic, cogs that need more bandwidth get it, cogs that don't... don't "waste" bandwidth!
Excellent plan, Chip.
Chip Gracey (Parallax) said...
Maybe when a cog is launched, its hub-access requirement could be stated, and then the launch would pass/fail based not just on whether or not a cog was available, but also on whether or not a requested-bandwidth hub slot was available. For example, you could have 1:4 being the highest, then 1:8, 1:16, and finally 1:32. Every program should use the lowest-possible setting. It would take only a bit of logic in the hub to negotiate the setup·requests and then serve them deterministically thereafter.
B (1:8)················ B······················ B······················ B ·· B······················ B······················ B······················ B ····· B······················ B······················ B······················ B ········ B······················ B······················ B······················ B ··········· B······················ B······················ B······················ B ·············· B······················ B······················ B······················ B ················· B······················ B······················ B······················ B ···················· B······················ B······················ B······················ B
C (1:16)······································· C ·· C·············································· C ····· C·············································· C ········ C·············································· C ··········· C·············································· C ·············· C·············································· C ················· C·············································· C ···················· C·············································· C ······················· C·············································· C ·························· C·············································· C ····························· C·············································· C ································ C·············································· C ··································· C·············································· C ······································ C·············································· C ········································· C·············································· C ············································ C·············································· C
All cog memory is longs, so potentially every pointer points to a byte in a 2^32 address space.
how about using the uppermost address bits to divide the memory map into memory spaces?
ie
$00000000-$3fffffff = hub memory; keeps it compatible with current usage
$40000000-$7fffffff = hub based I/O ports, shared by all cogs, can be wired-or or shared like cog memory
$80000000-$bfffffff = cog memory map; the first 512 locations as currently used, the rest... depends on geometry [noparse]:)[/noparse]
$c0000000-$ffffffff = reserved for future cog specific I/o
So if highest bit is clear, "hub" instructions take two cycles in the new architecture, like you said.
Iif the highest bit is set, add a bit of logic so its single cycle, and accesses "local" cog resources
note this would also potentially give us byte addressible cog memory, for the range after the first 512 longs.
If its simpler, you could actually have two memory spaces per cog, the current 512 longs, only long addressible, and besides it, more cog memory that was byte addressable; or heck, keep the cog memory always long-addressible only.
Much cleaner than banking. *should* be pretty easy to implement.
Chip Gracey (Parallax) said...
inaki said...
I vote for the 256K HUB memory/8 COGs.
By the way, do you have any plan for a future (even distant) extension of the COG's space ?
Yes, but it would be a 64-bit version with up to 64K longs per cog. This would be best for 90nm or smaller technology.
The only way we could augment the current architecture's cog RAM would be to have switchable banks, say in the $000-$0FF region.
I'd be happy with any upgrade!
But I'd have to vote 256k of Hub-ram and 8 cogs.
Cogs are pretty fast as they are now!! So picture what they could do if they where even faster!!
I'm with Andre and say go for both, but if I had to choose, I would say 8 Cogs 256k. When I was working on the video routines for Xracer, it seemed that the biggest bottleneck was reading from the main 32k which is why it takes 5 cogs for rendering(plus 1 for TV driver). At least from a video standpoint the faster access and more memory would be a much better solution. Instead of adding extra sram, you could use the internal Prop memory, and with the fast access you wouldn't need to use as many cogs, and if you did you could get a lot more milage out of it. You could also save an a lot of I/O pins because you wouldn't need to use them all for DMA of SRAM.
Also with the faster ram time, Spin would run a lot faster too which might help free up some cogs since less routines would need·ASM. I am guessing the biggest bottleneck for spin is just pulling instructions and writing the result.
In the case that you absolutely needed·more COGs, you could always string 2 props together with serial or if you needed faster access just tie more I/O pins to each other.
I know you stated that each COG will still have the 512 instruction limit, but I think if it is feasable to quadrupal or even double that since 512 instructions can run out pretty quick. But if not, the 256k is still a huge step in the right direction.
In the end I think people as a whole will need the greater memory and speed then the greater COG count.
shift register enhancement requests - I'll beg if I have to! :-)
1- expose a "strobe" pin that outputs the shift clock. allows for VERY VERY fast SPI out
2- expose an "input" pin so that we can also shift in, have a choice of providing the strobe on an external pin, or accepting an external clock/strobe - gives us the other half of VERY VERY fast SPI in
3- optionally Manchester encode and invert in an 802.3 compatible manner the output bitstream (or input once received) and do clock recovery from the incoming manchester stream (ETHERNET HERE WE COME!)
4- change waitvid so its more generic waitshift to be used for very high speed SPI in/out, and with the control word instead of specifying the color LUT, specifying the shift direction (input or output), number of bits to shift, phase of clock pin maybe pin number, and manchester or not
5- 4/8 bit color video mode as described in another message (with strobing capability please!)
6- the addition of a "SHIFTED" strobe output (or "PRESHIFT" for shift registers taking input), that was pulsed when the specified number of bits were shifted out/in, would also allow very high speed I/O expansion
Now the above is a bit of work for you, BUT it gets us:
- 10/100 Ethernet
- USB high speed (480mbps, needs 3x PLL mode)
- very high speed SPI links to SD cards (some can run at 450Mbps)
- extremely high speed (640MBPS?) inter-propeller links
- very colorful generated video
- high speed digital I/O expansion
Addendum:
After re-reading what I just wrote... I am now firmly in the 8 cog / 256k ram camp, ideally with the bandwidth allocation you described.
640MBPS to another propeller badly beats the memory bandwidth to a 50 or even 100MHz Ferroram, and those only have 64k, another propeller would have 256k [noparse]:)[/noparse]
oh... and I'd still really like the generic "port·X written", "port X read" strobes to be exposed to a pin (ideally with a "LATCH INPUT" alternate input function for the "port X read" strobe)
... and ... I believe it would also make FireWire possible.
Post Edited (Bill Henning) : 11/25/2006 5:51:03 PM GMT
I don't know much about what Bill suggested, but if you guys could swing being able to plug this thing into the back of my cable modem and be able to stream data/webpage to the internet, I think I'd pee myself!
To add to a previous post, if both were possible, you would satisfy everyone (with the selection of 3 props) and end up looking like this guy-> Ken, just buy the dang fab and get over it!
The 32k chip would work well for people's little microcontroller designs.
Now the 256k chip would make most anyone's MicroComputer design a reality!
Parsko, I've seen people build webservers with less powerful microprocessors/controllers. They normally use a very common realtek chip though for the Ethernet interface.
Of the two options you've offered, I'd definitely lean toward more RAM. I've yet to max out the cores with most of my code; serial drivers and the like spend most of their time waiting and can be multitasked.
It would be marvelous if we had at least one semi-configurable interrupt, also. Say, for example, we could trigger a handler based on CTRA; that would allow preemptive multitasking at high-speed (not to mention more efficient serial drivers). I don't feel as strongly on this one, though.
Also, 64-bit is really overrated for the vast majority of applications these days. Unless you've got some pretty pressing use cases, I wouldn't go that route for the Propeller anytime soon. (I spend a lot of my time on 64-bit apps.)
8 cogs focuses on programming - more code space, faster access to main memory ( VM's, FORTH, C, etc )
16 cogs will focus on hardware allow a focus on hardware ( 4 serial links, servo control, I2C controller - low level drivers ) with independent high level control. This would take more parallel cogs, with ( usually ) smaller programs in each.
I already need 11 cogs.
RS233 (via USB ) to PC host,
2xserial to two LANC controller video cameras.
SERVO controller to pan/tilt servos.
THEN
1 cog to process PC commands
2 cogs ( one for each LANC) to process status and commands for cameras
4 cogs ( one for each servo on two cameras) to control commands/status of pan & tilt servos
And that is with out future expansion!
Sure its possible to program around some of these limitations, but the great attraction of the propeller is the ability to do this with very simple ( non-interrupt, non-threaded, non-multitasking ) code.
Does seem to be a need for both versions targeted at different needs.
You know....the more I think about this....the more I have to ask:
What will be the price difference between the three different options?
1. The Propeller we have now.
2. The propeller with same cog count, more hub memory, faster.
3. The propeller with more cogs.
Opinions?
Chip could you chime in here. I'm not asking for a set price...just an educated estimate. Hell....don't even give me a price...just an approximation of percent based on current values. (option 2 estimated at 200% of current value....for instance)
Remember functionality comes with a price.....and for what I use the chips for...this is important. I know there are unseen expenses we never hear about. There are things I don't even fathom about the process to design....let alone market a chip.
I'm trying to weigh out price versus ability as well.
What will be the price difference between the three different options?
1. The Propeller we have now.
2. The propeller with same cog count, more hub memory, faster.
3. The propeller with more cogs.
Either #2 or #3 would probably cost about 50% more than the current chip. The die size would be the same, but the silicon is 50% more expensive. So,·under $20 at 1 piece, and around $12 at 1,000 pieces. It would have to come in higher-pin-count packages because there would need to be separate supplies for I/O (3.3V) and the core (1.8V).
Chip, the variable COG bandwidth option is sweet. I vote yes for this. I like how the current design consumers the power necessary. This option will really let us squeeze the COGS that we need, thus further diminishing the need for COG's. A big net gain in thoughtput and number of potential applications for only a small amount of additional on chip logic. That's a win-win.
I'm also backing bill on his counter proposals. Carefully evaluate those to see which ones really make the difference and please do those now, before we get too large of a body of existing prop code. People are really starting to do stuff. That has shaken down the current instruction set model. For the most part, it was solid, but for auto increment / decrement type stuff Bill described. Had the current prop came with these instructions, we would have seen more thoughtput where it really matters, again for a small amount of logic and minimal change to the instruction set.
If this stuff gets done now, the next wave of code will establish the platform necessary for a lot of people to jump onto the prop with fewer low level hassles. We don't want to lose that as the platform scales.
From a competetive standpoint, this is gonna be huge. Well worth consideration on that basis alone, IMHO.
I've dealt with high end applictions for a lot of years. Many of these were running on SGI NUMA machines. Interesting philosophy that turned out to be very true in a lotta cases: Any compute problem, properly coded, becomes an I/O problem. In this vein, the prop is very similar. We are always gonna need RAM before we need compute for all but a small set of applications. This will be true no matter where on the scale the prop is. Better to service the possible applications with as much RAM as is practical so as to avoid things like swapping from external storage and or RAM.
(Smile battery dead....)
(ran frantically to get power cord --success!)
I would also not violate two other ideals I see in the prop: software driven design with minimal hardware assist (how the video is done), and the deterministic nature of the design. As soon as you lose the deterministic property, a whole lotta complexity crops up that will limit scale, IMHO. Better to just provide robust instructions and a lot of flexibility (this is why I seriously like the variable access time you detailed above) and let the software solutions evolve.
One other thing occured to me, last night. The fastest way to communicate data between COGs is via I/O pins. On the 32 pin model, can we have virtual pins for this purpose? Seems to me, only a subset of applications will demand the full 64 pin model planned. Why not make that tradeoff and further squeeze some thoughtput outta the thing? The nice thing about this is the instructions are already done and the techniques are evolving right now. This plus the auto increment counters would really make for some tight and fast COG code. If virtual pins are not logic heavy, I would vote for this as well.
Somebody mentioned an external RAM interface. This would be sweet, but I suspect a lot to ask. (How to handle addressing for one.) I'm for it, but only if it does not comprimise the other great ideas here.
Great thread everyone! So many solid ideas! It's got me seriously stoked about this platform! I, for one, am quite pleased with it as it stands today and am also very happy that somebody let Chip sit in his corner building for so many years. This is all so very cool.
Post Edited (potatohead) : 11/25/2006 7:00:55 PM GMT
I don't like the idea of multiple versions. My thoughts are this....
Consider Games - Writing a PC game vs writing a game for a game console. Every Playstation is the same as every other playstation, so the programmer has 1 hardware platform to think about, and optimize code for. Coding for a PC is completely different, no 2 PC's are the same. Different processors, video cards, memory sizes, etc the list could go on and on.
You'd either have code that is not compatible with all systems, or features have to be sacrificed so that the code will run cross-platform.
My vote is for 1 version with 8 cogs, and more memory.
In an ideal world, we'd have both new versions available, as well as the existing chip, and hopefully that's what we'll end up with eventually, but I appreciate that it makes more sense to do one at a time.
My initial enthusiasm was for the 16 cog version, especially if each was running at 160Mhz, but that was just my hunger for raw speed winning out over the more sensible areas of my brain. I mean, this proposed 16 cog version would have four times the memory of the existing Propeller anyway.
If I'm being sensible though, as each would be running at eight times the current speed, that would mean that we'd be able to do much more with the same number of cogs, and so that would be fine. Having a full 256K of shared RAM would open up all manner of new possibilities for the chip, and so after some thought I'd vote for option 2.
Regardless of the route taken, having a mechanism for allocating hub bandwidth would be fantastic, and again, would open up all manner of new possibilities.
What I would also like to see is some on-chip flash, to enable a single chip solution without the need for the external EEPROM. That's one of the things that appeals most about chips like the Phillips/NXP range of LPC2xxx microcontrollers.
I'm guessing that for these new chips we'd probably be talking twice the current unit price.
parts-man73 said...
I don't like the idea of multiple versions.
At Parallax, we've learned from our·experience in making microcontroller tools that the slow road to hell is supporting an ever-bifurcating product line·with a standard tool. That's one of the big reasons we quit making tools for other companies' microcontrollers -- it was an expanding wavefront of chaos·with ever-diminishing returns. Even the slight variations of BASIC Stamps we have now takes an inordinate amount of effort to maintain on the tool side.
There is tremendous strength in simplicity, not just for us, but for customers, too. I'm sure that if the BASIC Stamp was 'improving' every six months, it never would have gotten the traction it did (for the exact reasons cited by parts-man73 in his complete post).
I think we're on the road in this thread to picking a really good path. And thanks to everybody for their input. Please keep it coming!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/25/2006 7:02:54 PM GMT
The code would be cross compatable, you just need to make sure you have the right prop. The only problem that comes into play is either you address memory that isn't there(16 cogs 128k), or you try to open more COGs then what is available(8 cogs 256k).
In the end tho, the problem you describe goes beyond the chip itself and is more·what is getting put into, which in that case you will still need the same hardware that is hooked up to the Prop(whether it is used for video, robotics, or anything else).
But I do back that if there can only be one, 8 COGs, 256k.
I vote for 8 and more ram. One question though, related to the architecture. Why the need for a video generator in every cog? Would it not make more sense to have a " dedicated " video controller, with its' own ram, and each cog could have access to it? It would seem that having it integrated with the hub would be more efficient.
This makes me think we should add some bits to the version register that report the number of COGs available, number of real I/O pins, and amount of on chip RAM.
I know just reporting the model number would suffice, but I'm thinking of code compatability. A program written today, could query the chip to know it's bounds and act accordingly. People are gonna get better at this, making such programs a reality.
That's CHEAP for supercomputing chips...
(At least if you like massively parallell computing
1.8V?
Does that mean we also get a reduction in power consumption?
(Not that ta Propeller is a power-hungry monster, exactly )
Will they be able to run at 1.8V only?
(Possibly disabling 3.3V after boot, and only starting it again when external devices need to be addressed)
This is particularly interesting if it's possible to read simple inputs while only using 1.8V
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
kelvin james said...
I vote for 8 and more ram. One question though, related to the architecture. Why the need for a video generator in every cog? Would it not make more sense to have a " dedicated " video controller, with its' own ram, and each cog could have access to it? It would seem that having it integrated with the hub would be more efficient.
kelvin
With current Props that is doable, but you can get more milage out of it by using more COGS. There really isn't enough memory to buffer a screen (this is done with Parallax's drivers, but you are limited to 4 colors every 16 pixels and uses most of the 32k). With a lot of the Hydra stuff and I think with some of Chip's newer drivers there are multiple
COGs rendering scanlines, then the TV/VGA driver pulls the prerendered scanline and displays, then that COG is freed to render another scanline. THe more COGs dedicated to this, the more complex the scanline renderer can be.
With more memory, it would become more feasable to have two 8 bit graphics buffers and have one COG to generate the video signal, and another COG to render the graphics(or the later be done in SPIN and keep it at one COG for video)
For me, right now, 8 cogs is plenty for my projects, especially if you ended up making them faster. What I am constantly struggling with is the memory. I have found ways around it, but having it integrated into the Propeller would make things so much better.
If it was available I would order 5 of them without hesitation.
It's probably a year away. We've got all the memory blocks already laid out, but there's still some architectural refinement, lots of logic/analog/pad layout, some software proving to do, and then however many test chips needed to get to the final version.
JT Cook said...
Chip,
Ballparking, what are you guys aiming for on the release of this next Prop?
6 months, 1 year, 2 years, other?
While I don't think the plan is to bring port B out to the I/O pins with this version, it would be great if it were available internally to allow a 32-bit bus between cogs for inter-cog communications.
Chip says "Note that each cog would run at about 160 MIPS, as opposed to the current 20 MIPS. "
How is that possible ?
If it has a lower voltage core then won't internal level shifting be required to 3.3v , so why not go for 5v ?
Something to output quadurature pulses (2bit) (frequency, direction and quantity of pulse) instead of 1 bit frequency only would help with CNC servo projects.
With a 8x faster cogs it looks like a multiplier/NPU feature might have a low priority, but it would be nice.
Comments
I've not still enough experience in propeller programming, but looking at the examples given at this forum, I could say that Option 2 is my choice ·now, 160 real MIPS sounds very very good !!.
I think that PChip is more than you want, in a simple microcontroller, it's·impressive power·generating video signals, like in VGA signal generation, but don't forget to give it more power at I/O and peripheral level, I think the reality is, that you can't have ALL capabilities in the same chip, the propeller have a lot yet. But, are you thinking to include some of this in the future·?? (UART, SPI, I2C, A/D....etc.).
So, more RAM (256Kb hub RAM) and perhaps more than 512 longs per COG could be great, together a 512Kb eeprom included
I think too, that is not necessary more I/O pins, you can expand those easily, and maintain the actual PIN2PIN structure. (I don't know ...what you'll do with all "B" registers......).
"I'm agree, with·the engineers that are doing with the famous 8051 architecture"
Remember ..still my inexpert opinion.
Regards.
Alberto.
·
But if we could also get Option 1. preferably also with the second set of I/O-pins...
(Sounds great for advanced robotics... )
Edit:
What kind of Spin performance can we expect?
(given that Spin is heavily HUB RAM dependant)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Post Edited (Gadgetman) : 11/25/2006 4:09:39 PM GMT
Leaves things deterministic, cogs that need more bandwidth get it, cogs that don't... don't "waste" bandwidth!
Excellent plan, Chip.
Actually there may be another way.
All cog memory is longs, so potentially every pointer points to a byte in a 2^32 address space.
how about using the uppermost address bits to divide the memory map into memory spaces?
ie
$00000000-$3fffffff = hub memory; keeps it compatible with current usage
$40000000-$7fffffff = hub based I/O ports, shared by all cogs, can be wired-or or shared like cog memory
$80000000-$bfffffff = cog memory map; the first 512 locations as currently used, the rest... depends on geometry [noparse]:)[/noparse]
$c0000000-$ffffffff = reserved for future cog specific I/o
So if highest bit is clear, "hub" instructions take two cycles in the new architecture, like you said.
Iif the highest bit is set, add a bit of logic so its single cycle, and accesses "local" cog resources
note this would also potentially give us byte addressible cog memory, for the range after the first 512 longs.
If its simpler, you could actually have two memory spaces per cog, the current 512 longs, only long addressible, and besides it, more cog memory that was byte addressable; or heck, keep the cog memory always long-addressible only.
Much cleaner than banking. *should* be pretty easy to implement.
1- increment not from clock frequency, but after every hub read (gives us auto increment/decrement hub pointers)
2- increment not from clock frequency, but after every hub write (gives us auto increment/decrement hub pointers)
Yes, I know, the faster cogs can do it in software... but this would save cog memory, and still save a cycle for something else
But I'd have to vote 256k of Hub-ram and 8 cogs.
Cogs are pretty fast as they are now!! So picture what they could do if they where even faster!!
Also with the faster ram time, Spin would run a lot faster too which might help free up some cogs since less routines would need·ASM. I am guessing the biggest bottleneck for spin is just pulling instructions and writing the result.
In the case that you absolutely needed·more COGs, you could always string 2 props together with serial or if you needed faster access just tie more I/O pins to each other.
I know you stated that each COG will still have the 512 instruction limit, but I think if it is feasable to quadrupal or even double that since 512 instructions can run out pretty quick. But if not, the 256k is still a huge step in the right direction.
In the end I think people as a whole will need the greater memory and speed then the greater COG count.
Post Edited (JT Cook) : 11/25/2006 5:18:16 PM GMT
1- expose a "strobe" pin that outputs the shift clock. allows for VERY VERY fast SPI out
2- expose an "input" pin so that we can also shift in, have a choice of providing the strobe on an external pin, or accepting an external clock/strobe - gives us the other half of VERY VERY fast SPI in
3- optionally Manchester encode and invert in an 802.3 compatible manner the output bitstream (or input once received) and do clock recovery from the incoming manchester stream (ETHERNET HERE WE COME!)
4- change waitvid so its more generic waitshift to be used for very high speed SPI in/out, and with the control word instead of specifying the color LUT, specifying the shift direction (input or output), number of bits to shift, phase of clock pin maybe pin number, and manchester or not
5- 4/8 bit color video mode as described in another message (with strobing capability please!)
6- the addition of a "SHIFTED" strobe output (or "PRESHIFT" for shift registers taking input), that was pulsed when the specified number of bits were shifted out/in, would also allow very high speed I/O expansion
Now the above is a bit of work for you, BUT it gets us:
- 10/100 Ethernet
- USB high speed (480mbps, needs 3x PLL mode)
- very high speed SPI links to SD cards (some can run at 450Mbps)
- extremely high speed (640MBPS?) inter-propeller links
- very colorful generated video
- high speed digital I/O expansion
Addendum:
After re-reading what I just wrote... I am now firmly in the 8 cog / 256k ram camp, ideally with the bandwidth allocation you described.
640MBPS to another propeller badly beats the memory bandwidth to a 50 or even 100MHz Ferroram, and those only have 64k, another propeller would have 256k [noparse]:)[/noparse]
oh... and I'd still really like the generic "port·X written", "port X read" strobes to be exposed to a pin (ideally with a "LATCH INPUT" alternate input function for the "port X read" strobe)
... and ... I believe it would also make FireWire possible.
Post Edited (Bill Henning) : 11/25/2006 5:51:03 PM GMT
I don't know much about what Bill suggested, but if you guys could swing being able to plug this thing into the back of my cable modem and be able to stream data/webpage to the internet, I think I'd pee myself!
To add to a previous post, if both were possible, you would satisfy everyone (with the selection of 3 props) and end up looking like this guy->
-Parsko
Now the 256k chip would make most anyone's MicroComputer design a reality!
Parsko, I've seen people build webservers with less powerful microprocessors/controllers. They normally use a very common realtek chip though for the Ethernet interface.
Of the two options you've offered, I'd definitely lean toward more RAM. I've yet to max out the cores with most of my code; serial drivers and the like spend most of their time waiting and can be multitasked.
It would be marvelous if we had at least one semi-configurable interrupt, also. Say, for example, we could trigger a handler based on CTRA; that would allow preemptive multitasking at high-speed (not to mention more efficient serial drivers). I don't feel as strongly on this one, though.
Also, 64-bit is really overrated for the vast majority of applications these days. Unless you've got some pretty pressing use cases, I wouldn't go that route for the Propeller anytime soon. (I spend a lot of my time on 64-bit apps.)
8 cogs focuses on programming - more code space, faster access to main memory ( VM's, FORTH, C, etc )
16 cogs will focus on hardware allow a focus on hardware ( 4 serial links, servo control, I2C controller - low level drivers ) with independent high level control. This would take more parallel cogs, with ( usually ) smaller programs in each.
I already need 11 cogs.
RS233 (via USB ) to PC host,
2xserial to two LANC controller video cameras.
SERVO controller to pan/tilt servos.
THEN
1 cog to process PC commands
2 cogs ( one for each LANC) to process status and commands for cameras
4 cogs ( one for each servo on two cameras) to control commands/status of pan & tilt servos
And that is with out future expansion!
Sure its possible to program around some of these limitations, but the great attraction of the propeller is the ability to do this with very simple ( non-interrupt, non-threaded, non-multitasking ) code.
Does seem to be a need for both versions targeted at different needs.
Just my 2 cents worth.......
Mike
What will be the price difference between the three different options?
1. The Propeller we have now.
2. The propeller with same cog count, more hub memory, faster.
3. The propeller with more cogs.
Opinions?
Chip could you chime in here. I'm not asking for a set price...just an educated estimate. Hell....don't even give me a price...just an approximation of percent based on current values. (option 2 estimated at 200% of current value....for instance)
Remember functionality comes with a price.....and for what I use the chips for...this is important. I know there are unseen expenses we never hear about. There are things I don't even fathom about the process to design....let alone market a chip.
I'm trying to weigh out price versus ability as well.
James L
Chip Gracey
Parallax, Inc.
I'm also backing bill on his counter proposals. Carefully evaluate those to see which ones really make the difference and please do those now, before we get too large of a body of existing prop code. People are really starting to do stuff. That has shaken down the current instruction set model. For the most part, it was solid, but for auto increment / decrement type stuff Bill described. Had the current prop came with these instructions, we would have seen more thoughtput where it really matters, again for a small amount of logic and minimal change to the instruction set.
If this stuff gets done now, the next wave of code will establish the platform necessary for a lot of people to jump onto the prop with fewer low level hassles. We don't want to lose that as the platform scales.
From a competetive standpoint, this is gonna be huge. Well worth consideration on that basis alone, IMHO.
I've dealt with high end applictions for a lot of years. Many of these were running on SGI NUMA machines. Interesting philosophy that turned out to be very true in a lotta cases: Any compute problem, properly coded, becomes an I/O problem. In this vein, the prop is very similar. We are always gonna need RAM before we need compute for all but a small set of applications. This will be true no matter where on the scale the prop is. Better to service the possible applications with as much RAM as is practical so as to avoid things like swapping from external storage and or RAM.
(Smile battery dead....)
(ran frantically to get power cord --success!)
I would also not violate two other ideals I see in the prop: software driven design with minimal hardware assist (how the video is done), and the deterministic nature of the design. As soon as you lose the deterministic property, a whole lotta complexity crops up that will limit scale, IMHO. Better to just provide robust instructions and a lot of flexibility (this is why I seriously like the variable access time you detailed above) and let the software solutions evolve.
One other thing occured to me, last night. The fastest way to communicate data between COGs is via I/O pins. On the 32 pin model, can we have virtual pins for this purpose? Seems to me, only a subset of applications will demand the full 64 pin model planned. Why not make that tradeoff and further squeeze some thoughtput outta the thing? The nice thing about this is the instructions are already done and the techniques are evolving right now. This plus the auto increment counters would really make for some tight and fast COG code. If virtual pins are not logic heavy, I would vote for this as well.
Somebody mentioned an external RAM interface. This would be sweet, but I suspect a lot to ask. (How to handle addressing for one.) I'm for it, but only if it does not comprimise the other great ideas here.
Great thread everyone! So many solid ideas! It's got me seriously stoked about this platform! I, for one, am quite pleased with it as it stands today and am also very happy that somebody let Chip sit in his corner building for so many years. This is all so very cool.
Post Edited (potatohead) : 11/25/2006 7:00:55 PM GMT
Consider Games - Writing a PC game vs writing a game for a game console. Every Playstation is the same as every other playstation, so the programmer has 1 hardware platform to think about, and optimize code for. Coding for a PC is completely different, no 2 PC's are the same. Different processors, video cards, memory sizes, etc the list could go on and on.
You'd either have code that is not compatible with all systems, or features have to be sacrificed so that the code will run cross-platform.
My vote is for 1 version with 8 cogs, and more memory.
Brian
My initial enthusiasm was for the 16 cog version, especially if each was running at 160Mhz, but that was just my hunger for raw speed winning out over the more sensible areas of my brain. I mean, this proposed 16 cog version would have four times the memory of the existing Propeller anyway.
If I'm being sensible though, as each would be running at eight times the current speed, that would mean that we'd be able to do much more with the same number of cogs, and so that would be fine. Having a full 256K of shared RAM would open up all manner of new possibilities for the chip, and so after some thought I'd vote for option 2.
Regardless of the route taken, having a mechanism for allocating hub bandwidth would be fantastic, and again, would open up all manner of new possibilities.
What I would also like to see is some on-chip flash, to enable a single chip solution without the need for the external EEPROM. That's one of the things that appeals most about chips like the Phillips/NXP range of LPC2xxx microcontrollers.
I'm guessing that for these new chips we'd probably be talking twice the current unit price.
There is tremendous strength in simplicity, not just for us, but for customers, too. I'm sure that if the BASIC Stamp was 'improving' every six months, it never would have gotten the traction it did (for the exact reasons cited by parts-man73 in his complete post).
I think we're on the road in this thread to picking a really good path. And thanks to everybody for their input. Please keep it coming!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/25/2006 7:02:54 PM GMT
In the end tho, the problem you describe goes beyond the chip itself and is more·what is getting put into, which in that case you will still need the same hardware that is hooked up to the Prop(whether it is used for video, robotics, or anything else).
But I do back that if there can only be one, 8 COGs, 256k.
kelvin
I know just reporting the model number would suffice, but I'm thinking of code compatability. A program written today, could query the chip to know it's bounds and act accordingly. People are gonna get better at this, making such programs a reality.
(At least if you like massively parallell computing
1.8V?
Does that mean we also get a reduction in power consumption?
(Not that ta Propeller is a power-hungry monster, exactly )
Will they be able to run at 1.8V only?
(Possibly disabling 3.3V after boot, and only starting it again when external devices need to be addressed)
This is particularly interesting if it's possible to read simple inputs while only using 1.8V
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
COGs rendering scanlines, then the TV/VGA driver pulls the prerendered scanline and displays, then that COG is freed to render another scanline. THe more COGs dedicated to this, the more complex the scanline renderer can be.
With more memory, it would become more feasable to have two 8 bit graphics buffers and have one COG to generate the video signal, and another COG to render the graphics(or the later be done in SPIN and keep it at one COG for video)
Ballparking, what are you guys aiming for on the release of this next Prop?
6 months, 1 year, 2 years, other?
For me, right now, 8 cogs is plenty for my projects, especially if you ended up making them faster. What I am constantly struggling with is the memory. I have found ways around it, but having it integrated into the Propeller would make things so much better.
If it was available I would order 5 of them without hesitation.
Here's to the future of the Propeller.
--Chris
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Great discussions,
Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
1. More memory (option #2)
2. PROTECT option, as the SX has
3. Implement Paul Baker's suggestions to make it more RF friendly
If you do come out with a large ram version that cranks, you can call it the RamJet.
Okay, one question for Chip - what tools are you using to design/develop it?
How is that possible ?
If it has a lower voltage core then won't internal level shifting be required to 3.3v , so why not go for 5v ?
Something to output quadurature pulses (2bit) (frequency, direction and quantity of pulse) instead of 1 bit frequency only would help with CNC servo projects.
With a 8x faster cogs it looks like a multiplier/NPU feature might have a low priority, but it would be nice.