More frequent releases, and potentially a target to a more capable process is highly desirable.
I can't help but think of the design that got fabbed. It was excellent, and it had none of the advance features, save the video engine, and even that one was more simple.
We all would have made a ton of stuff with it. Just to highlight what opportunity cost meand in a more identifiable way.
Keeping volume customers successful is a bigger deal right now.
I say make this design sing and do it more P1 style than not, and target the next one for a better process. A fork essentially. Updates to the P1 line happen regularly enough to serve those users well, and move toward a system on chip type design as we almost have in the P2 design too hot for the process.
On a side note, that design at 80Mhz rules. I would use it and I know som others had plans for it too. Seems to me, that one could get fabbed at some point to start the other line and potentially fund a shrink to a process that really performs.
Right now, everybody is thinking there will only be one chip and expectations are too high for it. Set those aside, and it being an update to the P1 is awesome!
Ken, it would be great to have a strategy discussion. Parallax internal for sure. Maybe openly, though I balk at that.
Not promises, strategy. Publish that, and it will improve the discussion here because the conflicting goals for the one chip would fall into place where a path for them exists apart from this single design.
Frankly, I see a clear split. The P2 design represents something more than a P1 will be, and a lot of people want it. The current design, being P1+ makes sense in the context of people needing to improve on their P1 success without having to redesign their products so radically.
I am fine with two paths and more than fine with an improved P1.
Have this discussion. Please. Just camp out some where, get it done and do us all a lot of good.
I would have been happy to play with a 64 pin P1, so a P1+ as currently described is certainly more than welcome by me (fwiw).
I can't help but to wonder, though, if going for 8 cogs, but more ram is overall a better use of die space. Of course, there's no definitive answer as some designs could use more cogs with less ram, and vice-versa. However, an added benefit of sticking with 8 cogs is increased hub bandwidth which is extremely valuable especially if the 4 longs hub R/W doesn't make it.
More importantly will they survive if the P1+ ends up draining sales from the P1 instead of opening up significant new markets?
I am beginning to think we would have been better off with a 4 core 80 MHZ P2 with the full I/O. At least that could have targeted different applications than a P1/P1+.
Don't get me wrong, I think the P1+ will be a great update to the P1... the problem is that it is looking more and more like just an update.
Several thoughts were spurred from your message that have little or nothing to do with your point, except for maybe the first one.
We won't be naming the chip P1+ as it suggests we could've done so much better. I understand why forum members refer to it with this naming convention, but internally and to our customers we would like to discourage this name. It's going to benefit the whole community and Parallax to drop P1+ as a street name. So, what is the name? We'll get there quickly - for now you can call it P16X64A.
As for P16 just being an update - the features proposed are exactly what our customers have requested since 2006, maybe except the one for more cogs but we seem to get these somewhat easily. It's an update to some of us because we've discussed something so much bigger with massive video capability, but so much bigger that it was like stuffing an octopus into a little bag so it's off the table.
This is exactly what I have heard over and over from our customers with applications in robotics, telemetry, medical, renewable energy, machine control and internet connected applications. They have asked for:
- A/D on any I/O pin
- faster speed
- more RAM
- code protect
- C support
Some of these RAM/speed requests may have been in response for handling math in PID loops, alleviated by cordic.
I think the last item of C support would be better with hubexec (right?) but my instinct is that it should wait for a future release based on hints Chip dropped about design challenges.
Occasionally we receive requests for a low-core Propeller. Some similar requests are to produce a very high-speed, low-pin, low-cost Propeller. Their assumption, however, is that a device would cost them less than a dollar. While low-core, low-pin, low-cost devices are somewhere to go when we start winning the race, it's not the turn to take considering already-paying customers asking standing on our freeway looking for a longer ride. Customers can always find a cheaper way, but we'll win by giving them a better, faster, easier way to get their project done. You know our customers: entrepreneurs and creators of new technology, and their volumes are in the 1K-10K range (nice for us, peanuts to the big players). Low-core, low-cost, low-pin may be much higher volume users, and although we aspire to serve them, it's not the first turn to take.
P16X64A all the way. [It's to our benefit to let the use of "A" in P8X32A refer to a revision scheme instead ports since we never came out with P8X32B. The second numerical part of the numbering scheme be a pin count. This way, if hubexec comes later the third design would be P16X64B, preserving some freedom in a simple part numbering scheme for more frequent, future iterations].
Well, one advantage of no hub exec is that we don't have to change the PropGCC code generator much for the new chip. There will, of course, be more opportunities to optimize its output using some of the new features but just getting PropGCC working should be easier than if we had hub exec.
This, David, is a very valuable point in my opinion and I am very glad to hear it because it is our goal to be able to release P16X64A with equal Spin and C support when actual hardware is available.
Ken, others:
I think it is a valuable thing for people to understand that just because a feature doesn't make it into this next chip, doesn't mean that it's gone forever. The impression I get from you and Chip is that iteration will be much more often than before. It may even be possible that we end up with a new incremental revision once a year, with some of those just being a shrink down to a new process that allows faster speed and more RAM (or whatever simple changes).
The really big change for the P16 from the P8 right now is the I/O pins. It's the defining difference really. The speed and memory size are incremental, the analog/smart I/Os are game changers.
It's going to benefit the whole community and Parallax to drop P1+ as a street name. So, what is the name? We'll get there quickly - for now you can call it P16X64A.
The P<cogs>X<I/O pins><rev> makes sense as an official part numbering scheme, but P16X64A is a bit long to use on the forum. The part number P8X32A is hardly ever used on the forum when referring to the current Propeller chip. On the forum, most people are calling it the P1. I think we should start calling the current chip under development P2 instead of P1+. After the P2 comes out the next chip would be P3, and so on.
The P<cogs>X<I/O pins><rev> makes sense as an official part numbering scheme, but P16X64A is a bit long to use on the forum. The part number P8X32A is hardly ever used on the forum when referring to the current Propeller chip. On the forum, most people are calling it the P1. I think we should start calling the current chip under development P2 instead of P1+. After the P2 comes out the next chip would be P3, and so on.
Sure, I agree with your suggestions and understand the logic. P2 = P16X64A.
I think the last item of C support would be better with hubexec (right?) but my instinct is that it should wait for a future release based on hints Chip dropped about design challenges.
Possibly, but it may be better if (and only if) a good scheme for allocating COG HUB access slots is possible.
How could it be better?
1) No instruction caching (simplifies hardware)
2) Same instruction set and startup handling (simplifies software)
3) Freedom to run at a given speed and/or mix of COGs (satisfies performance)
How could it be worse?
1) Any delays in implementing a solution from Chip beyond schedule tolerance
2) Using a solution that may be encumbered by a greed driven third party
Sure, I agree with your suggestions and understand the logic. P2 = P16X64A.
Argh! Just when I made up my mind to start typing P16. In all honesty, though, I think this will cause quite a lot of confusion for anyone who doesn't happen to see these few posts.
Cool beans. Yeah, P16 works easy for me too. Edit, whatever name is fine.
You know, I'm a supporter and what ever makes the most sense for a release this time is fine by me. People can be making stuff. They need to, and that is most important.
Ken, others:
I think it is a valuable thing for people to understand that just because a feature doesn't make it into this next chip, doesn't mean that it's gone forever. The impression I get from you and Chip is that iteration will be much more often than before. It may even be possible that we end up with a new incremental revision once a year, with some of those just being a shrink down to a new process that allows faster speed and more RAM (or whatever simple changes).
The really big change for the P16 from the P8 right now is the I/O pins. It's the defining difference really. The speed and memory size are incremental, the analog/smart I/Os are game changers.
I have a minor nit to pick here! :-) When the issue with the power consumption of the then P2 surfaced and the decision was made to scale up the capabilities of the Prop rather then scale back the P2 it was made clear that while the end goal was to make a micro like the P2 as it was the next chip would be an intermediate step!! (sorry for the run on sentence, I was trying to write a complete paragraph in a single sentence) The nit is that we need to remember that and keep it in mind rather then understand. I know it's minor but it is important to remember that this next chip isn't the end of the line. There will be other new and improved chips in the future.
As to the request from Ken that this chip not be called the P1+ like most of us have been doing. I understand the reason and agree with it. However we need to work out a short hand way of referencing it in the forums to keep the amount of typing down. :-) I'm kind of liking P2 it will be the second in the propeller family of chips. I don't expect this to be the final "name" or part number of the chip. I will defer to Ken and Chip and refer to the chip with the name they request.
This is exactly what I have heard over and over from our customers with applications in robotics, telemetry, medical, renewable energy, machine control and internet connected applications. They have asked for:
- A/D on any I/O pin
- faster speed
- more RAM
- code protect
- C support
This is what your current customers have been asking for. Doesn't that mean it is the list of features needed to keep the customers you already have? Will this be enough to attract new customers? Or is retaining the current customer base sufficient to sustain Parallax?
I think that the P2/P16 should be kept simple and be made available ASAP. It will be an awesome device.
The "dream chip" (what used to be called the P2) with all the fancy stuff should be another line that parallels the Propeller chips. It is sounding to me like it will be a significant enough evolutionary step from the P1 or P16 that is should be considered a new species.
In many markets a company's best future customers are their current customers. So it makes sense to address the needs of the current customers. The P2 will attract many more new customers with the new features. The new P2 design should be much less expensive to build than the old P2 design, so this should make it more competitive from a cost perspective also.
I think the last item of C support would be better with hubexec (right?) but my instinct is that it should wait for a future release based on hints Chip dropped about design challenges.
Yes, but keep the context that what Chip calls a challenge, does not take long !
Plus Hubexec is a solved problem, not an open ended one, it has been done, and field tested - I would be very cautious about throwing away proven work.
ie Nail down more details on what the impacts actually are.
I guess I agree as well but I wonder if a P1+ that is mostly the same as P1 with twice the COGs and more memory will have a bigger market than the P1 did. Can Parallax survive if the P1+ sells only as well as P1 sold?
-snip- Ken has spoken.
Edit- Actually, it sounds as though the entire plan has been downgraded from a 'jump forward' to a nice, incremental update.
Good to keep the existing customers, with some potential to attract new ones.
However, since the last I heard was $1M to go to a finer process, kind of hard to see that happening in a year or two.
Unless Parallax has a great many of the higher 1-10K volume customers, whom I expect also get some sort of negotiated discount.
I'd agree with JMG, dumping what seems to be proven to work for what might potentially be a week or month of Chip time delay needs to be looked at closely.
Such a benefit as hubexec is arguably THE killer feature that allows the average engineer to make that mid-way transition step to the Prop methodology.
Without it, its hard to see why somewhat faster Cores or more memory will somehow create any great increase in adoption.
As everyone here is so keen to say, if they want faster they just need to look at the next higher model in the currently familiy they are using, or wait 6 months to get it in the one they are using now.
However if Ken can keep the lights on and Chip and company happy with the P16, then that is fine to.
Ken what would you like us to refer to the "other" one as? P8X96A? P8X92A? Or P3?
The chip formerly known as P2 should have a code name....how about Tierra del Fuego?
P16X64A or P16 or P2 certainly seems reasonable for the chip currently under development - probably one of the first two if you want to be perfectly clear about which chip.
The P<cogs>X<I/O pins><rev> makes sense as an official part numbering scheme, but P16X64A is a bit long to use on the forum. The part number P8X32A is hardly ever used on the forum when referring to the current Propeller chip. On the forum, most people are calling it the P1. I think we should start calling the current chip under development P2 instead of P1+. After the P2 comes out the next chip would be P3, and so on.
For the prior design, I suggest "The Homer," because ... um ... well, it knocked one out of the park ... yeah ... a park that couldn't contain it ... yeah, that's the ticket! The pitcher was pitchin' heat, but no fanning for The Homer!
I'm a little wary of using same label arrangement as the Prop1. Something to show it's not directly compatible with the Prop1. Maybe something like PB16X64A or PB1664A.
Some thoughts about numbering: Numbers are just symbols. And there is a simple method to make numbers unique: invent a new one every time. So it started, by accident with the number P1. Following conventions, the next would be P2. P3, P4.... and there is no fear to run out of available symbols. Now link those predefined symbols to something that is a real object. (or has it do be: an real object? Please give advice) . This real object can be an idea, a design, a fabricated chip, one can buy.. The moment we have created this link, everybody knows what is meant with "Px" if the link is followed and a full description can be found. There is no need to have an association between symbol and the object it represents besides the link. P5 means nothing if it doesn't trigger your brain to recall everything that was related with a certain propeller design, incorporating a set of features. No symbol can adequately describe the power of the propeller if you didn't feel it by experience. So we need a sticky list: P1 = existing propeller, P2: design x, P3: design y, ... reaching P9 we could continue Pa, reaching Pf we could continue Pg etc. And the original P][ can now be given any name. If you like to know more about numbers, continue reading here: http://nietzsche.holtof.com/reader/friedrich-nietzsche/human-all-too-human/aphorism-19-quote_7c0c932f5.html
Comments
I can't help but think of the design that got fabbed. It was excellent, and it had none of the advance features, save the video engine, and even that one was more simple.
We all would have made a ton of stuff with it. Just to highlight what opportunity cost meand in a more identifiable way.
Keeping volume customers successful is a bigger deal right now.
I say make this design sing and do it more P1 style than not, and target the next one for a better process. A fork essentially. Updates to the P1 line happen regularly enough to serve those users well, and move toward a system on chip type design as we almost have in the P2 design too hot for the process.
On a side note, that design at 80Mhz rules. I would use it and I know som others had plans for it too. Seems to me, that one could get fabbed at some point to start the other line and potentially fund a shrink to a process that really performs.
Right now, everybody is thinking there will only be one chip and expectations are too high for it. Set those aside, and it being an update to the P1 is awesome!
Ken, it would be great to have a strategy discussion. Parallax internal for sure. Maybe openly, though I balk at that.
Not promises, strategy. Publish that, and it will improve the discussion here because the conflicting goals for the one chip would fall into place where a path for them exists apart from this single design.
Frankly, I see a clear split. The P2 design represents something more than a P1 will be, and a lot of people want it. The current design, being P1+ makes sense in the context of people needing to improve on their P1 success without having to redesign their products so radically.
I am fine with two paths and more than fine with an improved P1.
Have this discussion. Please. Just camp out some where, get it done and do us all a lot of good.
I can't help but to wonder, though, if going for 8 cogs, but more ram is overall a better use of die space. Of course, there's no definitive answer as some designs could use more cogs with less ram, and vice-versa. However, an added benefit of sticking with 8 cogs is increased hub bandwidth which is extremely valuable especially if the 4 longs hub R/W doesn't make it.
Several thoughts were spurred from your message that have little or nothing to do with your point, except for maybe the first one.
We won't be naming the chip P1+ as it suggests we could've done so much better. I understand why forum members refer to it with this naming convention, but internally and to our customers we would like to discourage this name. It's going to benefit the whole community and Parallax to drop P1+ as a street name. So, what is the name? We'll get there quickly - for now you can call it P16X64A.
As for P16 just being an update - the features proposed are exactly what our customers have requested since 2006, maybe except the one for more cogs but we seem to get these somewhat easily. It's an update to some of us because we've discussed something so much bigger with massive video capability, but so much bigger that it was like stuffing an octopus into a little bag so it's off the table.
This is exactly what I have heard over and over from our customers with applications in robotics, telemetry, medical, renewable energy, machine control and internet connected applications. They have asked for:
- A/D on any I/O pin
- faster speed
- more RAM
- code protect
- C support
Some of these RAM/speed requests may have been in response for handling math in PID loops, alleviated by cordic.
I think the last item of C support would be better with hubexec (right?) but my instinct is that it should wait for a future release based on hints Chip dropped about design challenges.
Occasionally we receive requests for a low-core Propeller. Some similar requests are to produce a very high-speed, low-pin, low-cost Propeller. Their assumption, however, is that a device would cost them less than a dollar. While low-core, low-pin, low-cost devices are somewhere to go when we start winning the race, it's not the turn to take considering already-paying customers asking standing on our freeway looking for a longer ride. Customers can always find a cheaper way, but we'll win by giving them a better, faster, easier way to get their project done. You know our customers: entrepreneurs and creators of new technology, and their volumes are in the 1K-10K range (nice for us, peanuts to the big players). Low-core, low-cost, low-pin may be much higher volume users, and although we aspire to serve them, it's not the first turn to take.
P16X64A all the way. [It's to our benefit to let the use of "A" in P8X32A refer to a revision scheme instead ports since we never came out with P8X32B. The second numerical part of the numbering scheme be a pin count. This way, if hubexec comes later the third design would be P16X64B, preserving some freedom in a simple part numbering scheme for more frequent, future iterations].
Ken Gracey
This, David, is a very valuable point in my opinion and I am very glad to hear it because it is our goal to be able to release P16X64A with equal Spin and C support when actual hardware is available.
Ken Gracey
I think it is a valuable thing for people to understand that just because a feature doesn't make it into this next chip, doesn't mean that it's gone forever. The impression I get from you and Chip is that iteration will be much more often than before. It may even be possible that we end up with a new incremental revision once a year, with some of those just being a shrink down to a new process that allows faster speed and more RAM (or whatever simple changes).
The really big change for the P16 from the P8 right now is the I/O pins. It's the defining difference really. The speed and memory size are incremental, the analog/smart I/Os are game changers.
Sure, I agree with your suggestions and understand the logic. P2 = P16X64A.
Ken Gracey
Thanks for your posts this morning. P16X64A makes sense to me.
I'll take whatever you have to offer.
How could it be better?
1) No instruction caching (simplifies hardware)
2) Same instruction set and startup handling (simplifies software)
3) Freedom to run at a given speed and/or mix of COGs (satisfies performance)
How could it be worse?
1) Any delays in implementing a solution from Chip beyond schedule tolerance
2) Using a solution that may be encumbered by a greed driven third party
For those just skimming, or have otherwise overlooked this, Ken asks that we stop calling it P1+ and start calling it
P16X64A
(note: though, I'll probably just refer to it as P16, which Ken himself has done.)
Argh! Just when I made up my mind to start typing P16. In all honesty, though, I think this will cause quite a lot of confusion for anyone who doesn't happen to see these few posts.
You know, I'm a supporter and what ever makes the most sense for a release this time is fine by me. People can be making stuff. They need to, and that is most important.
I have a minor nit to pick here! :-) When the issue with the power consumption of the then P2 surfaced and the decision was made to scale up the capabilities of the Prop rather then scale back the P2 it was made clear that while the end goal was to make a micro like the P2 as it was the next chip would be an intermediate step!! (sorry for the run on sentence, I was trying to write a complete paragraph in a single sentence) The nit is that we need to remember that and keep it in mind rather then understand. I know it's minor but it is important to remember that this next chip isn't the end of the line. There will be other new and improved chips in the future.
As to the request from Ken that this chip not be called the P1+ like most of us have been doing. I understand the reason and agree with it. However we need to work out a short hand way of referencing it in the forums to keep the amount of typing down. :-) I'm kind of liking P2 it will be the second in the propeller family of chips. I don't expect this to be the final "name" or part number of the chip. I will defer to Ken and Chip and refer to the chip with the name they request.
The "dream chip" (what used to be called the P2) with all the fancy stuff should be another line that parallels the Propeller chips. It is sounding to me like it will be a significant enough evolutionary step from the P1 or P16 that is should be considered a new species.
Yes, but keep the context that what Chip calls a challenge, does not take long !
Plus Hubexec is a solved problem, not an open ended one, it has been done, and field tested - I would be very cautious about throwing away proven work.
ie Nail down more details on what the impacts actually are.
-snip- Ken has spoken.
Edit- Actually, it sounds as though the entire plan has been downgraded from a 'jump forward' to a nice, incremental update.
Good to keep the existing customers, with some potential to attract new ones.
However, since the last I heard was $1M to go to a finer process, kind of hard to see that happening in a year or two.
Unless Parallax has a great many of the higher 1-10K volume customers, whom I expect also get some sort of negotiated discount.
I'd agree with JMG, dumping what seems to be proven to work for what might potentially be a week or month of Chip time delay needs to be looked at closely.
Such a benefit as hubexec is arguably THE killer feature that allows the average engineer to make that mid-way transition step to the Prop methodology.
Without it, its hard to see why somewhat faster Cores or more memory will somehow create any great increase in adoption.
As everyone here is so keen to say, if they want faster they just need to look at the next higher model in the currently familiy they are using, or wait 6 months to get it in the one they are using now.
However if Ken can keep the lights on and Chip and company happy with the P16, then that is fine to.
Ken what would you like us to refer to the "other" one as? P8X96A? P8X92A? Or P3?
The chip formerly known as P2 should have a code name....how about Tierra del Fuego?
P16X64A or P16 or P2 certainly seems reasonable for the chip currently under development - probably one of the first two if you want to be perfectly clear about which chip.
Man, I sure hope we get to a place where we can flesh that one out some more and do it on a process that's appropriate for it.
Until then, P2 it is for this one! Which I'm excited about. It can happen, and that's worth a lot!
"A metaphor too far ..."
-Phil
+1!
This system has worked well for other things in the past - I have found in my humble experience.
...wow, is the bottle of scotch all gone already....