K.I.S.S. Design for Prop II or III concept...

RinksCustoms

First off, please know that i'm not an IC layout engineer, IC design engineer, and my profession (until the layoff at least) has nothing to do with MCU's. This is more or less something I thought up as a concept.

Instead of 8 segregated cogs, each with their own counters and VSU's, why not make the individual resources globally accessable to any cog. One cog having acess to all 16 counters may seem a bit extreme, but if counters and VSU's could be acessed as a spinoff of COGNEW, wouldn't programs be a bit easier to write if you didn't have to launch chunks of code as COGNEW to give your porgram acess to multiple resources? Wouldn't that scheme also allow acess to unsused cogs for additional processing, kinda like a co-processor?

From my P.O.V. when programming the prop, it appears that your main program divides up tasks for 8 individual 32 bit MCU's with individual CTR & VSU units·in an optimised pkg design with shared I/O acess, an inter-cog data buss,·a global clock, PLL, and power. I'm not knocking the Propeller at all, this processor is awesome. And I can only imagine what it would take to make what I described a possibility while being fast, reliable and efficient.

This is more of a daydream than a suggestion or question, & I realize the devil is in the details,·but isn't that how the·Apple & IBM PC started?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E³ = Thought

http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.

Ale

I sort of agree with you... I like to program in assembler, just in that. So most programs end up being chunks in different cogs for the sake of space (I'll start using LMM soon to counter most of these). The same can be said for the resources, maybe a COG with 4 timers can control several things together instead of devoting two cogs. OTOH the lack of interrupts may limit the usability of 4 timers. I do not see the Propeller I as a not KISS approach, on the contrary, but generalization has prices. We should not forget that a hammer can only perform a task well, a swiss knife many more without excelling in any.
Some problems should be resolved using just what is needed for the task, without generalizing, because it may only provide bloat and unused features. (Something I always forget).

Phil Pilgrim (PhiPi)

The problem is routing all those data lines. As Chip and Beau have hinted in their various posts, even creating a 32-bit communication register that's accessible from all cogs would be a challenge.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

RinksCustoms

I wonder if there "could" be an option in a future version that would allow for nCogs or even all Cogs to be synced at once. Then you effectively would have up to 8 "Series" processors acting as a single Parallel sense/process/decide/act state machine. Although I'm not sure about the exact details of how syncing all the cogs would affect how instructions would be dealt with, if they would wait for the next instruction (system clock or not) or just crash the cog. I guess there pro's & cons to both syncronous and Asyncronus designs. It seems it's one or the other. You cannot syncronize an asyncronous system that well, likewise, you cannot opperate a sync'd system asyncronously that well either. The human brain effectively is one hell of an analog parallel multiprocessor. And I fear the day when AI surpasses our own abilities to be "human", emotions and all.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E³ = Thought

http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.