Additional Propeller?

Tim-M · 2006-04-20 16:21

· 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

Ken Gracey · 2006-04-20 16:33

Tim,

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.

Tim-M · 2006-04-20 16:41

Ken,

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

cgracey · 2006-04-20 17:01

We plan to make a 64-I/O-pin version of the current Propeller soon. It will be·identical, except for the addition of a 32-pin 'B' port, and of course a bigger package with more pins. This chip should be ready in six months.

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-M · 2006-04-20 17:43

All I can say is Wow, you all work really hard over there in Rocklin! Thanks for the fun and creativity we all relish in as a result of that hard work.

Tim

tperkins · 2006-04-20 18:12

Chip wrote:

"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

cgracey · 2006-04-20 18:45

tperkins said...

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

The speed increase comes mainly from pipelining, so that there will be a 1:1 instruction:clock ratio, instead of the current 1:4. It will clock up to twice as fast, too. That accounts for about one order of magnitude. There's more, also, like twice the COGs and 4x the HUB RAM. Also, single-cycle multiply instructions (128x, right there).

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.

Paul Baker · 2006-04-20 18:59

I deleted my previous post because I didnt want to disclose too much, but now that Chip has... Only a small percentage of speed up is due to increased clock speed. A 4x speed up is due to pipelining, a 2x speed up is due to the number of cogs, that leaves a 1.25x speed up due to the clock speed (4 x 2 x 1.25= 10) or 1.6 BIPS (billion instructions/second), Ill leave it to you to figure out what the target clock speed is.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10

tperkins · 2006-04-20 19:37

"We do have the current Propeller DONE and it's working great."

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

william chan · 2006-04-21 05:59

Chip,

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

cgracey · 2006-04-21 06:06

We've though about this, but it would mean double-buffering all HUB accesses, which would cause main memory access to both slow down AND become indeterminant. It would be neat, though, to hard-code ASM programs for a constant frequency. I suppose we could make a hybrid interface where it could be locked to the main clock and be determinant, or be separately clocked and be indeterminant. We'll see. Usually, simple is best.

william chan said...
Chip,

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

william chan · 2006-04-21 06:16

I now see your point, and agree that it could be difficult.
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

cgracey · 2006-04-21 06:22

william chan said...
I now see your point, and agree that it could be difficult.
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.

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.

William,

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

Don D · 2006-04-21 11:47

william chan said...

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.

Thinking along those lines, perhaps all main memory accesses could trigger max speed transfer if a certain configuration bit is set? (Maybe getting too complicated as Chip said...)

pjv · 2006-04-21 17:05

Hi All;

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)

Additional Propeller?

Comments