Additional Propeller?
· In a couple of the·threads here, there has been mention of a 64 pin Propeller and also·the implication of another, or next·version of the Propeller.· Maybe I missed something or another discussion that I cannot find, but what's the scoop about this?· Is another version already in the works?
Just curious and interested,
Tim
Just curious and interested,
Tim
Comments
Another version is not currently in the works but under consideration because the current design ports itself quite easily to a 64-pin package.
Hope this answers your question.
Sincerely,
Ken Gracey
Parallax, Inc.
That does answer the question, and that's what it sounded like based on the comments that I'd read.
As always, thank you (and all the Parallax staff) for your time spent with us directly - that is so appreciated.
Tim
We are also working on the next-generation Propeller chip,·which will be an order of magnitude faster than the current chip. It is·probably a year away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Tim
"We are also working on the next-generation Propeller chip, which will be an order of magnitude faster than the current chip. It is probably a year away."
And then a Propellor Supercomputer is almost unavoidable. Hit ~ 1.5 orders of magnitude (which I calc has you in the low GHz), and Propellors are, err, flying.
I do presume "an order of magnitude" will put it up to 800MHz?
Yours, TDP, ml, msl, & pfpp
Maybe after that, we'll go for a 45nm chip that could be four times as fast, again. That chip could hit 10,000 MIPS, just by itself. These are all a ways away, though, and may not even happen for·unforseen reasons. We do have the current Propeller DONE·and it's working great.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
I understand what you are saying, my order of parts is only waiting on a house closing on the 26th and a few (gasp, shudder) mortage payments under the bridge before I figure out how much I can play with.
You could say I'm salivating over the Propellor as is--but I can imagine what may come.
Yours, TDP, ml, msl, & pfpp
For the next propeller,
don't forget to allow separate clock multipliers for each cog to run at different speeds
so that we can fine tune it to get the lowest current consumption.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Maybe we could do it like this.
Only cogs that run at the same speed as the hub is allowed is access the main memory.
So, if a cog wants to access the shared memory, it first will have to change its multiplier to 16x before accessing the memory,
otherwise it will read all $FF's and write nothing to the HUB.
Seems like a waste to run a cog at 80Mhz just to do PS/2 keyboard interfacing which could be done at 1Mhz.
If the next generation propeller runs at higher frequencies like 160Mhz,
this speed feature would definitely become a necessity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
It's not as bad as you think. These objects that do stuff like keyboard and mouse interfacing are 'sleeping' about 99.99% of the time, because they are in WAITPEQ or WAITPNE (wait-pin-equal or wait-pin-not-equal) instructions, effectively frozen until some pin transition occurs. They don't take much average current, as clocking is severly gated during WAITPEQ or WAITPNE.
Interesting way to handle the COG sync problem. That would simplify the hardware, too.
- Chip
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey) : 4/21/2006 5:28:24 PM GMT
Why not let each COG run at a selectable binary sub-multiple of whatever the "HUB/system" clock is, yet any hub access or I/O transfer still done at full system speed. The slower COGs would simply "tap down" into a divider except for those full speed events. This "tap" method also has the benefit of speed switching without any stabilization time requirements; an absolute must for determinism.
Furthermore, it would be nice if optionally the physical I/O pins were latched (after each COG's direction registers) so that any COG could set a pin, and any COG could clear the pin. Of course each such event would need to be sequenced; probably somehow related to some sub-multiple (1/4?) of the hub's position. Such a system could lead to very interesting co-operative programs running in any number of COGs.
Cheers,
Peter (pjv)