What I see is an all or nothing mentality. I have been stuck there before. A product has to meet so many specs so nothing ever gets done and there is no middle ground. Big success for other micro manufacturers seems to built around flexibility, diversity, meeting many needs, not getting stuck on ONE product. Parallax may want to shake off the all or nothing mentality and think in terms of smaller incremental chunks. The money spent on the the Grand P2 may have already produced multiple interim products. A cheaper 2 core Prop would serve some needs in the market. A 32core may serve others. The Grand P2 may serve some needs but that is pending some design even still. All these years later and the conversation is on what ONE device to release? It should be on what 5 or 10 or 20 variations to release.
Look at the first post - Ken Gracey's vote is worth exactly the same as AntioneDoniels.
You should prolly add "inherently funding" to Ken's entry.
So - should I put you down as a Yes or a No?
Having not actually used a Propeller I'm easy either way. I've always liked the idea of more Cogs (I was disappointed when the early Prop2 specs was only 8 Cogs - This led to discussions that resulted in the 4 time-sliced threads). More Cogs seems so suited to the idea of software defined devices ... a quickly completed enhanced Prop1 sounds very tempting ... but, at the same time, there is some tasty instructions in the Prop2 that we only get with it.
What I see is an all or nothing mentality. I have been stuck there before. A product has to meet so many specs so nothing ever gets done and there is no middle ground. Big success for other micro manufacturers seems to built around flexibility, diversity, meeting many needs, not getting stuck on ONE product. Parallax may want to shake off the all or nothing mentality and think in terms of smaller incremental chunks. The money spent on the the Grand P2 may have already produced multiple interim products. A cheaper 2 core Prop would serve some needs in the market. A 32core may serve others. The Grand P2 may serve some needs but that is pending some design even still. All these years later and the conversation is on what ONE device to release? It should be on what 5 or 10 or 20 variations to release.
That seems to be the XMOS approach - four device families with several variants (4-7) within each family.
... The money spent on the the Grand P2 may have already produced multiple interim products. ...
It might be fair to say Chip and Parallax have been on decent a learning curve with respect to making use of newer options than what was used for the Prop1. So, now is not a bad time for the incremental moves.
Multiple device variants means multiple production runs, multiple inventories to maintain, multiple documents to create and maintain, multiple examples to maintain, potentially multiple libraries to maintain. You guys do realize Parallax is a business and pretty much EVERYTHING they do costs them money...all in the hope that it will make them at least the same amount of money. Folks lately have been going back to technical conversations everytime I bring up the harsh realities of money issues. None of it will work if the money isn't their.
P16X32, absolutely. So long as it stays simple and absolutely true to the P1 philosophy, I will be able to use it immediately, with almost no additional effort.
What a cream puff. Would it be possible to put someone else on the job of documenting the latest P2 image?
My personal preference would be to for a variant that maximizes HUB-RAM and has energy management features. More RAM>> then more pins and in last place… way behind the other two would be more cogs.
My DE2-115 and add-on board will arrive April 9, which will be a happy day at my house.
I think I already voted yes in other threads but let me make it official. :-) I think an incrementally improved P1 is a good idea. I'm kind of worried that it's going to get loaded up with a lot of "stuff" though. While the 5W power consumption of the current P2 design isn't a problem for me or any of the things I would use it for. I do find the 32IO pins and the 32KB of hub memory is an issue though. Personally I would be happy with a P1 with 64pins. More memory would be real nice and more cogs and higher clock rate would be a nice luxury. I hope Chip and Ken are able to resist adding a lot of "extra stuff" not already in the P1. Keep the P1B an incremental improvement while working on the P2.
While I don't have the ability to do any soldering of surface mount so buying chips by themselves will be of little use to me I can't see how I wouldn't be buying a number of them on boards.
It's nice to have Parallax ask for input, but at some point it starts feeling like they are the kid trying to be popular by throwing parties all the time.
All your "friends" have no problem showing up for the party, but how many stay around to help clean up the house?
The future of Parallax, or at least Parallax Semiconductor, likely hangs in the balance on the decisions to be made in the following weeks.
Listening to the forum members is great, giving them the keys the future not so much.
Ken and Chip need to make the strategic decisions, if they accept forum input on tactical details that is great.
We should not expect them to chart the course of the company that they and their hardworking employees have built based on the winds of the forum.
Would someone be able to remind someone who stopped following P2 development a while ago exactly what the limits on expanding the P1 COG memory are?
I'm aware that all the instructions that affect PC are limited to 9-bit literals which probably implies that the PC itself is only a 9-bit register. And that the last thing that wants to be changed now is the P1 instruction set/encoding. But, for instance, the JMP instruction appears to have 9 unused bits. And there are plenty of processors out there that have limited jump ranges for things like DJNZ
I would buy this, and consider funding it. The analog IO are compelling by themselves. A ton more memory, 2x cogs, and 4x instruction throughput per cog is extra nice. Almost completely backward compatibility is another useful perk. If I was greedy, I'd ask for the multiply instruction as reserved in the P1 machine code docs. (I have one application that could use all the extra MACs)
You better have a better reason to fence sit than that. Even Ken saw fit to throw in a light-hearted vote.
I'm not fence sitting, I'm asking Parallax to take charge and make a decision.
What we all want is more innovative chips like the P1.
To have that Parallax needs to be financially strong, and that needs to happen through organic growth, outside investors will kill the creativity and openness that makes Parallax special.
I want to see Parallax succeed and grow, I know they have the leadership and technical competence to do it.
To me it feels like somehow the forum has become a crutch to put off making hard decisions.
With so few details it's hard to know exactly what it is we're supporting. But you can count me a Yes for the proposed and assumed super P1. I'm probably in the very small camp that would prefer a simple, symmetric, efficient, low power device that's easy to use but more capable than the P1 over the current P2. Too complicated, too power hungry, and not available. I'm sure there are people that would find great uses for it, but currently I don't see it as a fit for my current projects. I hope when it emerges, it's less complex than the forums suggest. The complexity and power budgets suggest I'd be better off with a low power ARM. A super P1 could fix that.
I'm not fence sitting, I'm asking Parallax to take charge and make a decision.
I'm sure Chip is just bouncing some ideas to quickly see what bubbles up. It's one area we can contribute. The votes Ross is collecting certainly aren't any sort of final dictate to Parallax. The forum is not a democracy at all.
Would it be possible to implement the hardware multiply or maybe even full MAC (as planned for Prop2 ) on this incarnation of Propeller ?
Leod
Yes, it's possible to add EVERYTHING in the P2, that's what got us to this thread....I need this; it has to have this feature to compliment this feature we are adding, it won't sell if it doesn't have this.....a year later we have an FPGA emulation that will burn 5 watts when it is in silicon and not any closer to having real silicon.
So, sure it can have what you want....
We'll be back here next year taking a similar poll.
A solid, final, specification needs to be presented and clearly state the THIS is the PaaXbb (P2) chip that will be an incremental release to get to the P3. It will have tehse features, it will go to shuttle on such and such a date and it will be in production on this date barring PRODUCTION problems....not barring FEATURE CREEP.
Put a flag in the ground, call it a P2 and see if people rally to it. Explain the dates involved in creating the P2 and the impact that will have on creating the P3. One immediate impact is Chip's he is a limited and important resource to this effort...and the P2 effort. He can really only work on one at a time. We are deciding where Chip spends his effort and need to realize how that impacts other things Chip is working on. We are deciding where Parallax is to spend its effort and resources (like people and money). Everything you direct toward the PaaXbb (P2) takes the resource away from something else Parallax is doing or is trying to do.
So, sure, everybody can have everything they want in the P2 that is going to be in the P3....it will have a pretty high power demand, it will cause delays and we'll be here next year (again). Go for it!!! As a hobbyist, I'm having as much fun playing with FPGA emulations as I do playing with real chips.......if I was trying to make a livelyhood from Parallax based products, I'd be a bit concerned and be very aware of all the little feature creep problems. I'd also be willing to give up my little pet requests (needs of the one) to help move the ball forward (the needs of the many).
If the future success of a P2 is so dependent on one little feature, it's amazing that there have been 7 or 8 "one little feature" items that MUST GO INTO THE NEXT CHIP!
Would someone be able to remind someone who stopped following P2 development a while ago exactly what the limits on expanding the P1 COG memory are?
I'm aware that all the instructions that affect PC are limited to 9-bit literals which probably implies that the PC itself is only a 9-bit register. And that the last thing that wants to be changed now is the P1 instruction set/encoding. But, for instance, the JMP instruction appears to have 9 unused bits. And there are plenty of processors out there that have limited jump ranges for things like DJNZ
In P1, all JMP/CALL/RET instructions are variations of a single opcode, JMPRET.
The other 9bits are used in CALL and JMPRET variants to point to the location where to store the return address.
But the limit it's mostly related to the ability to fit operation, result flags, condition codes, destination and source registers in a 32bit opcode.
This for any operation, not only jumps, since in our model the cog ram is both code memory and a big register file, and it must be fully addressable.
But the limit it's mostly related to the ability to fit operation, result flags, condition codes, destination and source registers in a 32bit opcode.
Thanks.
If 512 words is too small, and HUBEXEC too complicated, was any sort of sliding window scheme considered?
ie, there's a new 9-bit register called WINDOW BASE which is offset by, say 7 bits upwards and then added to PC to give a 16-bit address. When WINDOW BASE is zero then the COG acts as now but code can be run anywhere within a 512 word window anywhere in a 64k range by setting the new register.
If 512 words is too small, and HUBEXEC too complicated, was any sort of sliding window scheme considered?
That immediately bangs into what was making HubExec complicated - Hub accesses have to be shared between all the Cogs. The resulting caching scheme gets more and more complicated as each case is dealt with. And handling the 4 threads as HubExec'utable also threw in extra complexity (Which, IMHO, was unneeded).
I think there is some decent savings that could be made to HubExec. Starting with ditching HubExec support for the hardware threads. Then, lets say Mooch'ing is implemented, a lot of the complexity in the caching could be removed and just let HubExec'ing Cogs thrash for accesses. This will allow one or two Cogs to get good performance (via Mooch'ing) with HubExec code but will quickly go down hill beyond that. The rest of the Cogs would be best doing background tasks. That should be enough for many a large project.
That immediately bangs into what was making HubExec complicated - Hub accesses have to be shared between all the Cogs.
I wan't necessarily thinking about using it for hub access but to expand the 512 words of COG ram. But doodling with a really hot cup of fresh tea bring all sorts of problems out so it's probably not a flier.
This will allow one or two Cogs to get good performance with HubExec code but will quickly go down hill beyond that. The rest of the Cogs would be best doing background tasks. That should be enough for many a large project.
I wonder if adding more entries to Bill's proposed 64-entry table would help?
I wan't necessarily thinking about using it for hub access but to expand the 512 words of COG ram.
Ah, I hadn't considered that. But with HubExec existing it's not worth expanding CogRAM.
Without HubExec there might be a case for paged/segmented CogRAM, but really, we'll probably be asking for 32 kB per Cog - that really does make it a much larger piece silicon.
Ah, I hadn't considered that. But with HubExec existing it's not worth expanding CogRAM.
Without HubExec there might be a case for paged/segmented CogRAM, but really, we'll probably be asking for 32 kB per Cog - that really does make it a much larger piece silicon.
I'm sure this has alread been mentioned but it is difficult to increase COG memory because of the 9 bit S & D fields of Propeller instructions. You could, I guess, use the same approach that Chip used in P2 to implement hub execution mode to extend COG memory but if you're going to do that you'd probably be better off going ahead and doing hub execution mode instead.
Count on my support for this! Maybe I missed it but what are we talking regarding "funding". I'd be happy to make regular 4-figure contributions but wouldn't this just be a drop in the bucket?
Comments
Look at the first post - Ken Gracey's vote is worth exactly the same as AntioneDoniels.
So - should I put you down as a Yes or a No?
You should prolly add "inherently funding" to Ken's entry.
Having not actually used a Propeller I'm easy either way. I've always liked the idea of more Cogs (I was disappointed when the early Prop2 specs was only 8 Cogs - This led to discussions that resulted in the 4 time-sliced threads). More Cogs seems so suited to the idea of software defined devices ... a quickly completed enhanced Prop1 sounds very tempting ... but, at the same time, there is some tasty instructions in the Prop2 that we only get with it.
That seems to be the XMOS approach - four device families with several variants (4-7) within each family.
It might be fair to say Chip and Parallax have been on decent a learning curve with respect to making use of newer options than what was used for the Prop1. So, now is not a bad time for the incremental moves.
What a cream puff. Would it be possible to put someone else on the job of documenting the latest P2 image?
My personal preference would be to for a variant that maximizes HUB-RAM and has energy management features. More RAM>> then more pins and in last place… way behind the other two would be more cogs.
My DE2-115 and add-on board will arrive April 9, which will be a happy day at my house.
John Abshier
While I don't have the ability to do any soldering of surface mount so buying chips by themselves will be of little use to me I can't see how I wouldn't be buying a number of them on boards.
Why I'm not voting...
It's nice to have Parallax ask for input, but at some point it starts feeling like they are the kid trying to be popular by throwing parties all the time.
All your "friends" have no problem showing up for the party, but how many stay around to help clean up the house?
The future of Parallax, or at least Parallax Semiconductor, likely hangs in the balance on the decisions to be made in the following weeks.
Listening to the forum members is great, giving them the keys the future not so much.
Ken and Chip need to make the strategic decisions, if they accept forum input on tactical details that is great.
We should not expect them to chart the course of the company that they and their hardworking employees have built based on the winds of the forum.
Respectfully,
Chris Wardell
Would someone be able to remind someone who stopped following P2 development a while ago exactly what the limits on expanding the P1 COG memory are?
I'm aware that all the instructions that affect PC are limited to 9-bit literals which probably implies that the PC itself is only a 9-bit register. And that the last thing that wants to be changed now is the P1 instruction set/encoding. But, for instance, the JMP instruction appears to have 9 unused bits. And there are plenty of processors out there that have limited jump ranges for things like DJNZ
You better have a better reason to fence sit than that. Even Ken saw fit to throw in a light-hearted vote.
It's the instruction length, it would have to be increased beyond 32 bit or a different encoding variant used instead.
Would it be possible to implement the hardware multiply or maybe even full MAC (as planned for Prop2 ) on this incarnation of Propeller ?
Leod
I'm not fence sitting, I'm asking Parallax to take charge and make a decision.
What we all want is more innovative chips like the P1.
To have that Parallax needs to be financially strong, and that needs to happen through organic growth, outside investors will kill the creativity and openness that makes Parallax special.
I want to see Parallax succeed and grow, I know they have the leadership and technical competence to do it.
To me it feels like somehow the forum has become a crutch to put off making hard decisions.
C.W.
I'm sure Chip is just bouncing some ideas to quickly see what bubbles up. It's one area we can contribute. The votes Ross is collecting certainly aren't any sort of final dictate to Parallax. The forum is not a democracy at all.
Yes, it's possible to add EVERYTHING in the P2, that's what got us to this thread....I need this; it has to have this feature to compliment this feature we are adding, it won't sell if it doesn't have this.....a year later we have an FPGA emulation that will burn 5 watts when it is in silicon and not any closer to having real silicon.
So, sure it can have what you want....
We'll be back here next year taking a similar poll.
A solid, final, specification needs to be presented and clearly state the THIS is the PaaXbb (P2) chip that will be an incremental release to get to the P3. It will have tehse features, it will go to shuttle on such and such a date and it will be in production on this date barring PRODUCTION problems....not barring FEATURE CREEP.
Put a flag in the ground, call it a P2 and see if people rally to it. Explain the dates involved in creating the P2 and the impact that will have on creating the P3. One immediate impact is Chip's he is a limited and important resource to this effort...and the P2 effort. He can really only work on one at a time. We are deciding where Chip spends his effort and need to realize how that impacts other things Chip is working on. We are deciding where Parallax is to spend its effort and resources (like people and money). Everything you direct toward the PaaXbb (P2) takes the resource away from something else Parallax is doing or is trying to do.
So, sure, everybody can have everything they want in the P2 that is going to be in the P3....it will have a pretty high power demand, it will cause delays and we'll be here next year (again). Go for it!!! As a hobbyist, I'm having as much fun playing with FPGA emulations as I do playing with real chips.......if I was trying to make a livelyhood from Parallax based products, I'd be a bit concerned and be very aware of all the little feature creep problems. I'd also be willing to give up my little pet requests (needs of the one) to help move the ball forward (the needs of the many).
If the future success of a P2 is so dependent on one little feature, it's amazing that there have been 7 or 8 "one little feature" items that MUST GO INTO THE NEXT CHIP!
In P1, all JMP/CALL/RET instructions are variations of a single opcode, JMPRET.
The other 9bits are used in CALL and JMPRET variants to point to the location where to store the return address.
But the limit it's mostly related to the ability to fit operation, result flags, condition codes, destination and source registers in a 32bit opcode.
This for any operation, not only jumps, since in our model the cog ram is both code memory and a big register file, and it must be fully addressable.
Edward Abbey says "One man alone can be pretty dumb sometimes, but for real bona fide stupidity, there ain't nothin' can beat teamwork".
I vote yes.
Thanks.
If 512 words is too small, and HUBEXEC too complicated, was any sort of sliding window scheme considered?
ie, there's a new 9-bit register called WINDOW BASE which is offset by, say 7 bits upwards and then added to PC to give a 16-bit address. When WINDOW BASE is zero then the COG acts as now but code can be run anywhere within a 512 word window anywhere in a 64k range by setting the new register.
That immediately bangs into what was making HubExec complicated - Hub accesses have to be shared between all the Cogs. The resulting caching scheme gets more and more complicated as each case is dealt with. And handling the 4 threads as HubExec'utable also threw in extra complexity (Which, IMHO, was unneeded).
I think there is some decent savings that could be made to HubExec. Starting with ditching HubExec support for the hardware threads. Then, lets say Mooch'ing is implemented, a lot of the complexity in the caching could be removed and just let HubExec'ing Cogs thrash for accesses. This will allow one or two Cogs to get good performance (via Mooch'ing) with HubExec code but will quickly go down hill beyond that. The rest of the Cogs would be best doing background tasks. That should be enough for many a large project.
I wonder if adding more entries to Bill's proposed 64-entry table would help?
Ah, I hadn't considered that. But with HubExec existing it's not worth expanding CogRAM.
Without HubExec there might be a case for paged/segmented CogRAM, but really, we'll probably be asking for 32 kB per Cog - that really does make it a much larger piece silicon.
You should add (and help fund) to my name on the For list.