I would propose that looking for solutions would require zooming way out from opcodes and flops and electrons. Trying to settle on one ultimate option is never going to work here(it hasn't to date) even for the short term. I suggest to produce a shuttle run of the 4 cog Grand Prop, sell it at a cost that will recoup the shuttle costs, maybe even put it on a dip or dev type board. This makes it more useable than the current platform for testing. Some on the forum will pay a premium for it(viewed as investment), with maybe a few early adopters buying it. How many chips can be produced in a shuttle, at what cost per 10, 100, 1000? Perhaps another option is for a third party to fund the shuttle of the 4cog at a gamble it can sell a batch for a premium and make a few percent off it.
With the Grand Prop 4 cog shuttle pieces being put to real world use, that product can evolve on it's own pace until such a time as the better process can be afforded to bump it up to 8 cogs.
Simultaneously work on the upgraded P1 for the next true product release.
FWIW I would expect that if a solution to mix P1 and P2 cogs was found / agreed upon, that the P1 cogs could run the P1 instruction set coded as a subset of the P2 instruction set. Therefore I would suggest mixing P1 and P2 cogs be looked at a little more.
I have been thinking about how to simply add hubexec th the P16X32B. If the PC were used like the P2 (pc > $200*4=$800) then if code was executed from hub then all calls and jumps become relative +/-255. Add 1 new jump direct instruction. Add 1 save/load z and c flags instruction. When in hubexec mode it fetches direct from hub (no cache) so it operates at hub speed.
If, as hasbeen suggested, hub access is made configurable, the the hubexec cogs could be given more hub slots. If it were also able to utilise unused slots this would also improve hubexec performance. While its not P2 hubexec, its better than LMM because its more power efficent (idles while waiting for next hub slot instead of fetching, incrementing, executing, looping).
FWIW I would expect that if a solution to mix P1 and P2 cogs was found / agreed upon, that the P1 cogs could run the P1 instruction set coded as a subset of the P2 instruction set. Therefore I would suggest mixing P1 and P2 cogs be looked at a little more.
I have been thinking about how to simply add hubexec th the P16X32B. If the PC were used like the P2 (pc > $200*4=$800) then if code was executed from hub then all calls and jumps become relative +/-255. Add 1 new jump direct instruction. Add 1 save/load z and c flags instruction. When in hubexec mode it fetches direct from hub (no cache) so it operates at hub speed.
If, as hasbeen suggested, hub access is made configurable, the the hubexec cogs could be given more hub slots. If it were also able to utilise unused slots this would also improve hubexec performance. While its not P2 hubexec, its better than LMM because its more power efficent (idles while waiting for next hub slot instead of fetching, incrementing, executing, looping).
So I see you and Rick both skipped the opium den this morning!
Seems worth exploring. Simple, effective, I like it.
- more pins
Covered with having 64 I/O
- more RAM
Covered with the plan for having 256KB
- code protect
See below
- A/D
Covered with the new I/O Chip plans to reuse from the P2 design
- higher speed
Covered by 2 clock per instruction vs. the current 4 and double clock speed
If code protect was a high priority and your research shows it would siginificantly increase adoption of the chip:
- Make COG0 special and add enough hardware to it to implement a code protection scheme similar to that planned for the P2.
Some addition thoughts that might be simple and help justify this being a step up from the P1:
- Consider implementing AUX Ram similar to the P2.
The AUX is great for stacks and lookup tables, reduces pressure on the limited COG Ram.
- Consider some instuctions and/or hardware to better support serial protocols, these seem to have always been complaint points.
- Would it make any sense to put one or more CORDIC in as hub mapped devices so no special instructions are required in the COGS.
This might be of use for UAVs or other math heavy applications.
This is just my observation and opinion, only Parallax can decide what is right for the company.
Make COG0 special and add enough hardware to it to implement a code protection scheme similar to that planned for the P2.
Why make it special? Why not takes Chip's CORDIC engine idea and do the same with an encryption engine accessible to any COG? Like that we keep all COGs identical.
I'm really bummed right now, because going down to 4 cogs pretty much kills the P2 for me.
I really hate the idea of having to do the multitasking thing to get enough parallel stuff happening. Squeezing 4 cog drivers into 1 cogs memory is a drag. You also have to constantly be aware of the multitasking issues and limitations. It's going to be really un-fun to code.
Most of the "real" P1 projects I have worked on (or am working on) utilize 6-8 cogs, and several of them are using most or all of the cogs memory. I'd MUCH prefer nuking a bunch of features and reducing HUB memory to keep 8 cogs on the P2.
For me 8 verses 4 cogs is the difference between coding the on the P2 being fun verses it being a chore (that I don't want to do, and probably wont).
I could not agree more...great post...
Chip if you could solve/include a hub exec routine in the 16 cog p1 plus model...that feature might be the best of both worlds
IRC COG0 does the loading, that is why I just suggested it as part of COG0. If it would be useful for other things then certainly making it a shared resource would be fine.
Would it be simple (P1X or P2X) to add a pair of 32bit registers (one read and one write) between each pair of cogs for direct access between cogs? (ie cog3 can talk directly to both cogs 1 & 3 without going via the hub). This would mean we could bypass the hub altogether for some drivers requiring more than 1 cog.
This seems like a good way to let adjacent COGs communicate without involving the hub.
It got a little discussion on the "Consensus on the P16X32B?" thread.
I understand Ross' desire to make the access more universal so that COG order can stay independent, but that adds considerable complexity to what may otherwise be a workable solution.
I don't see it as much of a burden for an object to require adjacent COGs. Is it perfect, no, seeking perfect got us the multi-watt P2, right now we need pragmatic more than perfect.
Pretty much what I replied to David & RossH on their questions why the simplest hubexec for P1 style cogs is barely faster than LMM.
I've been pushing the idea of a hub slot assigment table precisely to boost video and LMM / hubexec performance.
I like your suggested addition of the short form @addressing from P2 being added to p1 cogs, and a single 16 bit jump opcode. Gets rid of the need of most LMM primitives, and the extra slots will help the hub bandwidth limit. All of a sudden P1 hubexec should be ~2x-3x the speed of P1 LMM, for very low cost in gates.
FWIW I would expect that if a solution to mix P1 and P2 cogs was found / agreed upon, that the P1 cogs could run the P1 instruction set coded as a subset of the P2 instruction set. Therefore I would suggest mixing P1 and P2 cogs be looked at a little more.
I have been thinking about how to simply add hubexec th the P16X32B. If the PC were used like the P2 (pc > $200*4=$800) then if code was executed from hub then all calls and jumps become relative +/-255. Add 1 new jump direct instruction. Add 1 save/load z and c flags instruction. When in hubexec mode it fetches direct from hub (no cache) so it operates at hub speed.
If, as hasbeen suggested, hub access is made configurable, the the hubexec cogs could be given more hub slots. If it were also able to utilise unused slots this would also improve hubexec performance. While its not P2 hubexec, its better than LMM because its more power efficent (idles while waiting for next hub slot instead of fetching, incrementing, executing, looping).
It seems unlikely that anyone would complain about the P1's low power. Is there any way to gauge your volume customers' power concerns? Are these 4 wants acceptable at any power level?
Mixing up P1 and PII style COGS is a total nightmare of an idea.
Agreed. One of the big selling points for the P1 was all the I/O pins were the same (I know about the four pins for boot but after that) and that outside of the initial boot all cogs were equal. This meant you never had to think about which core something was going to run in. The P1 was also very easy to program and useful programs could be written very quickly.
If you don't want to loose 8 years of development and all these nice new features of the Prop2 then the only way I see is to make a mix of P1 and P2 cogs. 4 cogs are not enough, and 16 P1 cogs are not powerfull enough to make the new chip a success. There is no hope that Parallax will find 1-2 Million $ for a smaller structure.
For example 8 P1 cogs and 4 P2 cogs. After Reset the chip starts cog 0 which is a P1 cog. The compiler will add a Spin1 interpreter and the P1-ROM content to the binary.
The ones that want just a better Prop1 with more RAM and faster cogs have now 8 cogs compatible to the Prop1.
The ones that need power can start one of the 4 P2 cogs and shut down the first P1 cog. They are aware that the chip needs now much more milliamps and another language/compiler.
If there is a fuse to disable the P2 part, you can sell a cheaper variant of the same chip as a P1B. And if the next shuttle run has errors the chance that one part works is much higher.
And you can fulfil the expectations of two different groups of Propeller users with one chip.
Software:
Just see it so that the chip has two modes with two different compilers. So at begin we don't even need complicated tools that handle 2 different CPU models.
But very soon some smart people will make compilers and tools that can access Spin1 objects from the P2 part. I mean it's also possible to mix different Memory modells in PropGCC and even to access Spin objects from C. The sections have acess to the same hubmemory so communication fast via mailboxes is always possible.
Solving the software side is much much easier than finding a solution for the 180nm issues.
HubAccess:
P2 as it is now is optimized for 8 hub-cycle round robin, the old P1 works with 16 hub cycles. If we keep that, the following is possible:
For example the 3-P2 and 10-P1 variant will have the following hub access (A..C=P2 cogs, 0..9=P1 cogs:
01234ABC56789ABC 01234ABC56789ABC
so P2 has the hub all 8 cycles and P1 all 16.
The P1 cogs should be as close to the old Prop1 as possible, with 4 cycles per instruction and the old counters. Otherwise all the tricks, like using the counters for fast SPI will not work.
I can see that adapting the P1 cogs to the 256bit wide hubmemory and the new pin hardware will take some work and time. Also a way to start P2 cogs must be implemented (there are 4 unused instructions, or two if MUL will be implemented.
...16 P1 cogs are not powerful enough to make the new chip a success...
But you're assuming that 'power', by which I assume you mean raw MIPS, is THE measure of a chips success. In the microcontroller world, based on my 30+ years of experience in it, it rarely is. Once you start interacting with people and mechanical things you don't need that many raw MIPS in your main code.
With a 16+ COG P1 you don't need to push your mainline code. Your USART can be intelligent and deal with all the front-end protocol decoding. All your main code sees is a buffer with everything sorted and error checked. Your keyboard handler can likewise deal with all the nitty-gritty all sort the debounce and repeat key timing.
The current thinking looks like it'll be a minimum of 16 P1 "COGs on Steroids" each at 100 MIPS. That's a lot of grunt.
I think there is only going to be one more chip this decade.
If the 16 COG P1 is built, it takes away the funding and resources to build the P2. It will be a moderate improvement, not groundbreaking, but hub bandwidth starved as usual.
I think it will be financially successful. I bet the P1 sales curve is already on the downswing (unless I'm totally wrong), so it'll be a double-hump kind of sales increase again. Business practicalities keep pushing the P2 to "next year". Next year becomes about 6 years. Who knows what the competition will come up with in 6 years?
If a 180 nm P2 is built with 4 cogs, I'm thinking it will be a curiosity unless some really powerful development tools and design standards are created to insert shared objects arbitrarily into quarter-cogs. I just don't see Chip doing this because he doesn't seem to have this kind of mindset (requires an iron fist and hostile dev tools). A capable chip but I think secretly hated by the creator because it is more optimized to run high-level language, with barely any of the unique assembly language instructions being used. The CORDIC and MAC stuff would be heavily used. Complaints of "hard to use" would kill its educational market (without a very explanatory and verbose compiler and "cog object fitter"). The educational market is fickle, as { } brackets and semicolons after every instruction is even considered "difficult".
If the 65 nm 8 Cog P2 is built, unless some sort of miracle happens, I bet the setup and mask costs will cripple Parallax. The per-chip cost would be too high, too high chip prices will never congeal into a revenue stream. But what if Parallax can find a volume buyer committed to acquiring the number of chips necessary to keep the stream flowing. I think everyone wins with the 65 nm P2, but only in a fairy-tale kind of way. The only other way is to wait 12-24 months and hope that either inflation makes the whatever million dollars seem cheaper, or the 65 nm mask setup and fab cost itself drops because of some other factory opening up due to losing its current business. That's a big gamble. With no chips your audience becomes dormant and loses momentum, the project eventually being dropped or becoming just a kind of licensed IP core.
If the 16 COG P1 is built, it takes away the funding and resources to build the P2.
It might also provide the funding and resources to build the P2.
I would also beg to differ with anyone who avers that the P2 effort will have been wasted if the P2 isn't built. You can never erase the lessons learned -- both good and bad -- from such an endeavor. Besides, we're already seeing aspects of the P2 design incorporated into the dialog about the P1+. And that's a good thing.
It might also provide the funding and resources to build the P2.
I would also beg to differ with anyone who avers that the P2 effort will have been wasted if the P2 isn't built. You can never erase the lessons learned -- both good and bad -- from such an endeavor. Besides, we're already seeing aspects of the P2 design incorporated into the dialog about the P1+. And that's a good thing.
I agree. Four cogs feels very claustrophobic. It can be argued that they are so much more powerful than Prop1 cogs, but you'd have to carefully mix programs into them - which would NOT be fun. I like the feeling of being able to fire up another cog without any other contingencies.
...
Chip, It's obvious to me that go did an amazing design for the P2 cogs. The fact that it hits a wall on a 180nm process doesn't diminish the concept or the design, it just limits the quantity that you can stuff on one chip. P2 cores will allow things that can't be done on P1 cores.
On the other hand, as you said, mixing programs into one core will not be fun for the user, but we can restore the fun for them if we do our homework on the SW side. Building some carefully arranged mix of typical functions (apply a 80/20 rule here) will help to avoid wasted cores and at the same time speed up the users architecture design phase.
We could even become sophisticate on a second phase by allowing a "configurator" program your where you to pick the modules you need and gives you back a nicely packed module that runs standalone in it's own core. Thus you save cores for your real needs and not for the commodity peripherals.
So 4 P2 cores with some combined SW peripherals already tested is a selling combination for me.
FWIW I would expect that if a solution to mix P1 and P2 cogs was found / agreed upon, that the P1 cogs could run the P1 instruction set coded as a subset of the P2 instruction set. Therefore I would suggest mixing P1 and P2 cogs be looked at a little more.
I have been thinking about how to simply add hubexec th the P16X32B. If the PC were used like the P2 (pc > $200*4=$800) then if code was executed from hub then all calls and jumps become relative +/-255. Add 1 new jump direct instruction. Add 1 save/load z and c flags instruction. When in hubexec mode it fetches direct from hub (no cache) so it operates at hub speed.
If, as hasbeen suggested, hub access is made configurable, the the hubexec cogs could be given more hub slots. If it were also able to utilise unused slots this would also improve hubexec performance. While its not P2 hubexec, its better than LMM because its more power efficent (idles while waiting for next hub slot instead of fetching, incrementing, executing, looping).
I fully agree.
* Keep the small-size of 'P1' COG, but re-code opcodes so it is P2 PASM compatible - ie a P2S = P2 Shrink/Subset.
( a good litmus test here, is to keep P2S logic less than the COG RAM area.)
* Remove the large Mathops from P2 , and make them hub-shared ( as Chip is now looking at doing.)
That both shrinks the P2 COG(s), and lifts the choices of P2S.
* Use a Mapping scheme for HUB slots, and Power Envelope control (one array can do both)
* All COGs get the vital but small P2 Counter upgrades of True PWM, Quadrature, Capture (atomic) but not the Sine Gen extras
* A small sprinkle of P2 opcodes can be added to the P2S, but keep it small.
If Hubexec doubles the size, then perhaps just pull in some Auto-inc opcodes that allow SW LMM to tune with the Map Array.
(P2 still has Hubexec, so it is not vital on P2S, plus a Mathop-removed P2 is also now smaller)
If you don't want to loose 8 years of development and all these nice new features of the Prop2 then the only way I see is to make a mix of P1 and P2 cogs. 4 cogs are not enough, and 16 P1 cogs are not powerfull enough to make the new chip a success. There is no hope that Parallax will find 1-2 Million $ for a smaller structure.
If there is a fuse to disable the P2 part, you can sell a cheaper variant of the same chip as a P1B. And if the next shuttle run has errors the chance that one part works is much higher.
And you can fulfil the expectations of two different groups of Propeller users with one chip.
Yes, this testing coverage aspect of including a P2 on the next shuttle run is often overlooked.
The P1 cogs should be as close to the old Prop1 as possible, with 4 cycles per instruction and the old counters. Otherwise all the tricks, like using the counters for fast SPI will not work....
I
That bit I would fine tune a little :
There is already a small 2 Clock P1, and that meshes nicely with smaller Dual COG port memory.
If that 2 clock core has a run option for ClockGate/2, you can have a choice of a virtual 4 cycle P1.
I think the P2 counters include all the old modes, so that should be implicit, but I would add the vital but small P2 Counter upgrades of True PWM, Quadrature, Capture (atomic)
I'm not sure we would want 4 P2 COGs and N P1 COGs though. It seems like 1 or maybe P2 COGs should be enough. Did someone suggest this already? I haven't been reading everything in this thread because I'm so disgusted by the whole power idea especially after the latest 8 COG max power dissipation estimate (watt per cog?).
Given 2 P2 COGs and say 14 P1 COGs, that means there would be plenty of power for HUBEXEC users and lots of peripheral COG capability. I really believe having 2 P2 COGs is too fat and not necessary - but at least that wouldn't smell bad.
Chip is such a compromise realistic?
What schedule impact would that have? 3 months?
What would the dissipation be with 2P2+14P1?
Could HUBRAM still be 256KB? (not really enough compared to other solutions in the projected price range, but I'll take it).
[
Could HUBRAM still be 256KB? (not really enough compared to other solutions in the projected price range, but I'll take it).
If 256K fitted with 8 x P2, then certainly a lot more memory is possible with reduced P2 COGs.
Chip has been asked for P2 COG vs memory area, but I guess even that is a moving target, as Chip is looking to move BIG MathOPs out from the P2 COG to a common shared area, so P2 COG is about to shrink. (and the smaller COGS get shared smarter)
(The power will not shrink the same, so fewer P2 cogs are still demanded by Power Envelope reasons.
The die-cost per P2 COG will be smaller, which will allow more Memory, or maybe one click more on P2 Number. )
Agreed. One of the big selling points for the P1 was all the I/O pins were the same (I know about the four pins for boot but after that) and that outside of the initial boot all cogs were equal. This meant you never had to think about which core something was going to run in. The P1 was also very easy to program and useful programs could be written very quickly.
Agreed. Mixing P1 and P2 cogs breaks the Propeller paradigm big time.
16 P1 cogs are not powerfull enough to make the new chip a success. There is no hope that Parallax will find 1-2 Million $ for a smaller structure.
There is no evidence in favor of either of these propositions, and much evidence to the contrary in the consensus thread.
Yes, there isn't evidence of this. What would be more useful is to understand what contributes to success. Is it running big programs faster? If so, I share that concern. Maybe it can be addressed.
Comments
With the Grand Prop 4 cog shuttle pieces being put to real world use, that product can evolve on it's own pace until such a time as the better process can be afforded to bump it up to 8 cogs.
Simultaneously work on the upgraded P1 for the next true product release.
I have been thinking about how to simply add hubexec th the P16X32B. If the PC were used like the P2 (pc > $200*4=$800) then if code was executed from hub then all calls and jumps become relative +/-255. Add 1 new jump direct instruction. Add 1 save/load z and c flags instruction. When in hubexec mode it fetches direct from hub (no cache) so it operates at hub speed.
If, as hasbeen suggested, hub access is made configurable, the the hubexec cogs could be given more hub slots. If it were also able to utilise unused slots this would also improve hubexec performance. While its not P2 hubexec, its better than LMM because its more power efficent (idles while waiting for next hub slot instead of fetching, incrementing, executing, looping).
So I see you and Rick both skipped the opium den this morning!
Seems worth exploring. Simple, effective, I like it.
C.W.
http://forums.parallax.com/showthread.php/155014-We-re-looking-at-5-Watts-in-a-BGA!?p=1256727&viewfull=1#post1256727
- more pins
Covered with having 64 I/O
- more RAM
Covered with the plan for having 256KB
- code protect
See below
- A/D
Covered with the new I/O Chip plans to reuse from the P2 design
- higher speed
Covered by 2 clock per instruction vs. the current 4 and double clock speed
If code protect was a high priority and your research shows it would siginificantly increase adoption of the chip:
- Make COG0 special and add enough hardware to it to implement a code protection scheme similar to that planned for the P2.
Some addition thoughts that might be simple and help justify this being a step up from the P1:
- Investigate the HUBEXEC method suggested by Ray.
http://forums.parallax.com/showthread.php/155014-We-re-looking-at-5-Watts-in-a-BGA!?p=1256904&viewfull=1#post1256904
- Consider implementing AUX Ram similar to the P2.
The AUX is great for stacks and lookup tables, reduces pressure on the limited COG Ram.
- Consider some instuctions and/or hardware to better support serial protocols, these seem to have always been complaint points.
- Would it make any sense to put one or more CORDIC in as hub mapped devices so no special instructions are required in the COGS.
This might be of use for UAVs or other math heavy applications.
This is just my observation and opinion, only Parallax can decide what is right for the company.
C.W.
I could not agree more...great post...
Chip if you could solve/include a hub exec routine in the 16 cog p1 plus model...that feature might be the best of both worlds
C.W.
This seems like a good way to let adjacent COGs communicate without involving the hub.
It got a little discussion on the "Consensus on the P16X32B?" thread.
http://forums.parallax.com/showthread.php/155083-Consensus-on-the-P16X32B?p=1256851&viewfull=1#post1256851
http://forums.parallax.com/showthread.php/155083-Consensus-on-the-P16X32B?p=1256867&viewfull=1#post1256867
I understand Ross' desire to make the access more universal so that COG order can stay independent, but that adds considerable complexity to what may otherwise be a workable solution.
I don't see it as much of a burden for an object to require adjacent COGs. Is it perfect, no, seeking perfect got us the multi-watt P2, right now we need pragmatic more than perfect.
C.W.
Agreed.
Pretty much what I replied to David & RossH on their questions why the simplest hubexec for P1 style cogs is barely faster than LMM.
I've been pushing the idea of a hub slot assigment table precisely to boost video and LMM / hubexec performance.
I like your suggested addition of the short form @addressing from P2 being added to p1 cogs, and a single 16 bit jump opcode. Gets rid of the need of most LMM primitives, and the extra slots will help the hub bandwidth limit. All of a sudden P1 hubexec should be ~2x-3x the speed of P1 LMM, for very low cost in gates.
Agreed. One of the big selling points for the P1 was all the I/O pins were the same (I know about the four pins for boot but after that) and that outside of the initial boot all cogs were equal. This meant you never had to think about which core something was going to run in. The P1 was also very easy to program and useful programs could be written very quickly.
For example 8 P1 cogs and 4 P2 cogs. After Reset the chip starts cog 0 which is a P1 cog. The compiler will add a Spin1 interpreter and the P1-ROM content to the binary.
The ones that want just a better Prop1 with more RAM and faster cogs have now 8 cogs compatible to the Prop1.
The ones that need power can start one of the 4 P2 cogs and shut down the first P1 cog. They are aware that the chip needs now much more milliamps and another language/compiler.
If there is a fuse to disable the P2 part, you can sell a cheaper variant of the same chip as a P1B. And if the next shuttle run has errors the chance that one part works is much higher.
And you can fulfil the expectations of two different groups of Propeller users with one chip.
Software:
Just see it so that the chip has two modes with two different compilers. So at begin we don't even need complicated tools that handle 2 different CPU models.
But very soon some smart people will make compilers and tools that can access Spin1 objects from the P2 part. I mean it's also possible to mix different Memory modells in PropGCC and even to access Spin objects from C. The sections have acess to the same hubmemory so communication fast via mailboxes is always possible.
Solving the software side is much much easier than finding a solution for the 180nm issues.
HubAccess:
P2 as it is now is optimized for 8 hub-cycle round robin, the old P1 works with 16 hub cycles. If we keep that, the following is possible:
For example the 3-P2 and 10-P1 variant will have the following hub access (A..C=P2 cogs, 0..9=P1 cogs: so P2 has the hub all 8 cycles and P1 all 16.
The P1 cogs should be as close to the old Prop1 as possible, with 4 cycles per instruction and the old counters. Otherwise all the tricks, like using the counters for fast SPI will not work.
I can see that adapting the P1 cogs to the 256bit wide hubmemory and the new pin hardware will take some work and time. Also a way to start P2 cogs must be implemented (there are 4 unused instructions, or two if MUL will be implemented.
Andy
But you're assuming that 'power', by which I assume you mean raw MIPS, is THE measure of a chips success. In the microcontroller world, based on my 30+ years of experience in it, it rarely is. Once you start interacting with people and mechanical things you don't need that many raw MIPS in your main code.
With a 16+ COG P1 you don't need to push your mainline code. Your USART can be intelligent and deal with all the front-end protocol decoding. All your main code sees is a buffer with everything sorted and error checked. Your keyboard handler can likewise deal with all the nitty-gritty all sort the debounce and repeat key timing.
The current thinking looks like it'll be a minimum of 16 P1 "COGs on Steroids" each at 100 MIPS. That's a lot of grunt.
I think there is only going to be one more chip this decade.
If the 16 COG P1 is built, it takes away the funding and resources to build the P2. It will be a moderate improvement, not groundbreaking, but hub bandwidth starved as usual.
I think it will be financially successful. I bet the P1 sales curve is already on the downswing (unless I'm totally wrong), so it'll be a double-hump kind of sales increase again. Business practicalities keep pushing the P2 to "next year". Next year becomes about 6 years. Who knows what the competition will come up with in 6 years?
If a 180 nm P2 is built with 4 cogs, I'm thinking it will be a curiosity unless some really powerful development tools and design standards are created to insert shared objects arbitrarily into quarter-cogs. I just don't see Chip doing this because he doesn't seem to have this kind of mindset (requires an iron fist and hostile dev tools). A capable chip but I think secretly hated by the creator because it is more optimized to run high-level language, with barely any of the unique assembly language instructions being used. The CORDIC and MAC stuff would be heavily used. Complaints of "hard to use" would kill its educational market (without a very explanatory and verbose compiler and "cog object fitter"). The educational market is fickle, as { } brackets and semicolons after every instruction is even considered "difficult".
If the 65 nm 8 Cog P2 is built, unless some sort of miracle happens, I bet the setup and mask costs will cripple Parallax. The per-chip cost would be too high, too high chip prices will never congeal into a revenue stream. But what if Parallax can find a volume buyer committed to acquiring the number of chips necessary to keep the stream flowing. I think everyone wins with the 65 nm P2, but only in a fairy-tale kind of way. The only other way is to wait 12-24 months and hope that either inflation makes the whatever million dollars seem cheaper, or the 65 nm mask setup and fab cost itself drops because of some other factory opening up due to losing its current business. That's a big gamble. With no chips your audience becomes dormant and loses momentum, the project eventually being dropped or becoming just a kind of licensed IP core.
I would also beg to differ with anyone who avers that the P2 effort will have been wasted if the P2 isn't built. You can never erase the lessons learned -- both good and bad -- from such an endeavor. Besides, we're already seeing aspects of the P2 design incorporated into the dialog about the P1+. And that's a good thing.
-Phil
I couldn't agree more!
Funding the future is primary in all of this, agreed.
Chip, It's obvious to me that go did an amazing design for the P2 cogs. The fact that it hits a wall on a 180nm process doesn't diminish the concept or the design, it just limits the quantity that you can stuff on one chip. P2 cores will allow things that can't be done on P1 cores.
On the other hand, as you said, mixing programs into one core will not be fun for the user, but we can restore the fun for them if we do our homework on the SW side. Building some carefully arranged mix of typical functions (apply a 80/20 rule here) will help to avoid wasted cores and at the same time speed up the users architecture design phase.
We could even become sophisticate on a second phase by allowing a "configurator" program your where you to pick the modules you need and gives you back a nicely packed module that runs standalone in it's own core. Thus you save cores for your real needs and not for the commodity peripherals.
So 4 P2 cores with some combined SW peripherals already tested is a selling combination for me.
Alex
I fully agree.
* Keep the small-size of 'P1' COG, but re-code opcodes so it is P2 PASM compatible - ie a P2S = P2 Shrink/Subset.
( a good litmus test here, is to keep P2S logic less than the COG RAM area.)
* Remove the large Mathops from P2 , and make them hub-shared ( as Chip is now looking at doing.)
That both shrinks the P2 COG(s), and lifts the choices of P2S.
* Use a Mapping scheme for HUB slots, and Power Envelope control (one array can do both)
* All COGs get the vital but small P2 Counter upgrades of True PWM, Quadrature, Capture (atomic) but not the Sine Gen extras
* A small sprinkle of P2 opcodes can be added to the P2S, but keep it small.
If Hubexec doubles the size, then perhaps just pull in some Auto-inc opcodes that allow SW LMM to tune with the Map Array.
(P2 still has Hubexec, so it is not vital on P2S, plus a Mathop-removed P2 is also now smaller)
Agreed.
<snip>
Yes, this testing coverage aspect of including a P2 on the next shuttle run is often overlooked.
That bit I would fine tune a little :
There is already a small 2 Clock P1, and that meshes nicely with smaller Dual COG port memory.
If that 2 clock core has a run option for ClockGate/2, you can have a choice of a virtual 4 cycle P1.
I think the P2 counters include all the old modes, so that should be implicit, but I would add the vital but small P2 Counter upgrades of True PWM, Quadrature, Capture (atomic)
I'm not sure we would want 4 P2 COGs and N P1 COGs though. It seems like 1 or maybe P2 COGs should be enough. Did someone suggest this already? I haven't been reading everything in this thread because I'm so disgusted by the whole power idea especially after the latest 8 COG max power dissipation estimate (watt per cog?).
Given 2 P2 COGs and say 14 P1 COGs, that means there would be plenty of power for HUBEXEC users and lots of peripheral COG capability. I really believe having 2 P2 COGs is too fat and not necessary - but at least that wouldn't smell bad.
Chip is such a compromise realistic?
What schedule impact would that have? 3 months?
What would the dissipation be with 2P2+14P1?
Could HUBRAM still be 256KB? (not really enough compared to other solutions in the projected price range, but I'll take it).
Yes, once you have two COGs, Large and Small, any mix is easily possible.
The small COGs naturally become P2 binary-opcode subsets. (P1 opcodes remap)
Still waiting on OnSemi Sim numbers on a 2 Clock small COG
If 256K fitted with 8 x P2, then certainly a lot more memory is possible with reduced P2 COGs.
Chip has been asked for P2 COG vs memory area, but I guess even that is a moving target, as Chip is looking to move BIG MathOPs out from the P2 COG to a common shared area, so P2 COG is about to shrink. (and the smaller COGS get shared smarter)
(The power will not shrink the same, so fewer P2 cogs are still demanded by Power Envelope reasons.
The die-cost per P2 COG will be smaller, which will allow more Memory, or maybe one click more on P2 Number. )
It's all just great! Really.
3 months add on would put chips into the start of 2015's shooting, gardening, outside with the dog (low Prop activity) season.
John Abshier
Agreed. Mixing P1 and P2 cogs breaks the Propeller paradigm big time.
Ross.
There is no evidence in favor of either of these propositions, and much evidence to the contrary in the consensus thread.
Ross.
Yes, there isn't evidence of this. What would be more useful is to understand what contributes to success. Is it running big programs faster? If so, I share that concern. Maybe it can be addressed.