Prop: Highest Level Requirements
prof_braino
Posts: 4,313
What are the three primary highest level requirements for whatever "next version" prop? (P2, P1+ whatever)?
Is this correct:
* As many cogs as possible (16 minimum or don't bother)
* As fast as possible (160 Mhz or don't bother)
* As much RAM as possible (512k or don't bother)
Is this correct:
All other aspects of the device should be in support of these. Any functions that do not support thiese or are free (present due to the implementation of the above) are addiional cost.
Are these true statements:
The niche that the prop dominates is high speed deterministic execution.
Other parts can run for example LINUX, but cannot do high speed deterministic execution well.
The distinguishing factor of the prop that we value MOST is the ability is high speed, deterministic execution.
...
I ask because I am confused after all the feature creep discusion. What do we really want? Sometimes clarifying the actual erquirements helps.
In my case, the prop is the lowest cost solution to have a whole boat load of very fast input and outputs; for other needs I would select other parts (if I didn't already have a mess of props on my desk already). Is this the general case, or is this an exception?
Is this correct:
* As many cogs as possible (16 minimum or don't bother)
* As fast as possible (160 Mhz or don't bother)
* As much RAM as possible (512k or don't bother)
Is this correct:
All other aspects of the device should be in support of these. Any functions that do not support thiese or are free (present due to the implementation of the above) are addiional cost.
Are these true statements:
The niche that the prop dominates is high speed deterministic execution.
Other parts can run for example LINUX, but cannot do high speed deterministic execution well.
The distinguishing factor of the prop that we value MOST is the ability is high speed, deterministic execution.
...
I ask because I am confused after all the feature creep discusion. What do we really want? Sometimes clarifying the actual erquirements helps.
In my case, the prop is the lowest cost solution to have a whole boat load of very fast input and outputs; for other needs I would select other parts (if I didn't already have a mess of props on my desk already). Is this the general case, or is this an exception?
Comments
I might suggest the three primary requirements here are:
1) To scratch Chips itch to build a processor/micro-controller. Not any old MCU but one following his own personal vision. Which I hope we need not expound on here.
2) To be able to use said device in furtherance of the other goals of Parallax. Which seem to be diverse. Hobbyist robots and gadgets, educational endeavours etc.
3) To make us forum people happy
Clearly in all this, hard numerical requirements like clock speed, number of COGs amount of RAM, are not cast in stone. Historically they keep getting re-evaluated and changed.
Chips seems to be pushing hard on the boundaries of what is possible with the technology available so it's understandable that the, dare I say it "vision" has more priority than any specific measurable goal.
Edit: Chip, sorry if I seem to be speaking for you. It's just the way it seems from over here.
Of course, but I don't know what the requirements actually are. So I have to ask. Can anybody point a link to the actual requirements, official or otherwise?
Great, but none of these are requirements; they are not quantifiable, and cannot bet tested with a "Yes" or "No" answer. Mistaking those for requirements guarantees we will not get what we want.
Requirements MUST clear and concrete, or they are noise. The degree to which "requirements" stray form being answerable with "yes" or "no" (or present vs not present, ec) is the degree of likelyhood of failure.
To change failure to success, all we need do is change from nebulous "wishes" to concrete requirements, then we have something to work towards.
What requirements were in force when Picasso scrawled his famous pictures, or Maurice Koechlin and
1. To move into markets that the Prop 1 could not enter due to:
a. Lack of I/O.
b. Lack of memory.
c. Lack of speed needed for application (DSP, Audio, better Video, etc.).
2. To NOT be just a "little better P1" that only eats into the P1 sales.
3. To correct limitations in the P1.
a. Better compiler support (helper instructions) for C / C++.
b. Native large program support i.e. hubexec to get around the limitations of COG Ram without needing an interpreter using up resources.
c. Better I/O functions i.e. Analog, PWM, Encoder, Serial, etc. app helper features (either instructions or smart pins).
d. Additional 'quality of life' instructions for PASM.
4. Ability to move from a primarily hobby/educational market to include serious process control, robotics, DSP, and other 'mixed mode' applications where the Prop 1x can be a single source solution for deterministic I/O control, back end logic processing and user interface.
The now dead P2 would have been a killer for the above. From what I read from Chip on where he is going with the new 1x version most of the above are well in hand. I see only two areas that concern me. One is that with SDRAM installed we end up with far less I/O available for control use than a P1 (would prefer at least 32 (P1 qty) + new SDRAM but understand Chip's packaging issues). The other is the still very tight Cog RAM available for deterministic programming. While we have 2x cogs we also have 2x I/O so the work load is the same. Hopefully some of the smart pin features will automate things to reduce the Cog code needed for I/O use. Looks promising so far!
Like the P1, it's a creative act. There aren't any formal requirements. It's not a typical process.
Right now, maximizing the Propeller way of doing things in this process physics is the goal. As a creative act, how that gets done is an artifact of the ideation that went on here, as well as the lessons learned here on the earlier design.
Now that's being applied with the goal of getting a chip out.
I would add a new top one first,
* Fit within the package power envelope,
as that trumps the others, and that is why the P2 is being 're-mixed'
Not entirely - there are many items not on your short list, that Chip/Ken have decided are needed for what I would call 'Critical Commercial Mass', and they include things like Fuses, COG HW Multiply, ADC, DAC, shared MathBlock, smart pins.
I think your summary that lists at least 16 cogs, 160MHz and 512KB of RAM is on target (with the exception of the "don't bother" bit, though I think I get why you said it).
For me, the unwritten requirement statement is to provide a chip that can function as a standalone system that doesn't require an operating system and is easy to program and assemble objects (while maintaining the possibility of determinism).
The 8 cogs of the P1 often aren't enough to provide that functionality (or often constrain things non-ideally), especially with the use of cog-consuming soft peripherals, hence the need for 16 (or even 32, as was toyed with). The 512KB of RAM is highly desired for developing complete standalone systems. Yes, much could still be done with 256KB, but there wouldn't be much breathing room, and video objects would be constrained. 1MB won't fit, but 512KB does (hopefully). I was so pleased when Chip made it a target to have 512KB (if at all possible). Thanks Chip!!! The system speed (MHz or MIPS) is the least rigid factor, I think (i.e., the one that can be lowered if needed), though it's nice that Chip is aiming for 100 MIPS.
Again, the added cogs and memory allow standalone systems that go beyond typical microcontroller applications to be developed, comfortably positioning the chip between microcontrollers and application processors (both of which are inundated with solutions). Doesn't it make a lot of sense for Chip to target that "middleland" between those two extremes? Of course, he is doing so with a view to facilitating signal processing and deterministic code, but I think that the standalone system part will also be important, so much so that I'd say that it's the driving factor (it's nicely boiled down to this over the years). And Chip has mentioned several times about wanting to have a chip that could handle standalone development (such as in education) without requiring use of traditional and complicated OS-based PC's.
To clarify, when I said "standalone systems" above, I wasn't really referring to standalone development systems. That's just one use case, but I was referring to, oh, for example, a home security or control system that not only monitors and controls sensors and actuators but can also handle the interface with ease. That's something that the current Propeller can possibly handle, but it's a bit constrained when it comes to the human interface portion. Anyway, that's just an example. But it does illustrate why video of some sort is necessary for a "middleland" chip, even if many use cases won't need it. In that sense, this new chip is less of a microcontroller than the P1. It's (Chip's) aiming at bigger ground, but not too big. And I'm liking it (apologies to McD's).
I'm liking the way this new chip is shaping up so much that I'm embarrassed that I contended for Parallax to "embrace" the expensive 90nm or smaller technology. Sorry about that, Chip/Ken/Parallax. Fortunately, more pragmatic heads prevailed. Less is more, often, and Chip is refining this new chip splendidly, honing it in terms of functionality, simplicity and power consumption, all within the 180nm process.
Anyway, I have plans for all those cogs. If one were to ask why the chip needs 16 cogs, they might also want to ask the centipede why it needs so many legs (hmm...a new product name? We're beyond the octopus's 8 tentacles). There's a rationale for all those cogs, but the full rationale won't be apparent until the chip is in the field. People that haven't ran out of cogs are probably a combination of [1] brilliant programmers and [2] folks that have confined themselves to microcontroller applications. But people like me that weren't smart enough to or didn't want to move to an application processor "abused" the P1 and have used all of the cogs. There's a reason for all the cogs that goes beyond just numerous soft peripherals...and the reason is standalone-system functionality.
Well, I'm no doubt oversimplifying things (as always), but your question, prof_braino, is thought-provoking.Thanks for bringing it up. --Jim
Prof_braino's list is great because it defines key strengths of the Prop and attempts to magnify them (key strengths I totally agree with, btw). Heater's list is great because it seems brilliantly close to reality, and also because I trust Chip to create something that will combine lots of fun and loads of utility.
Nonsense. Requirements, in engineering, are the things that we need to be present when we are done. They are either present, or not. Anything that cannot be account for in this manner is not a requirement. Hopes, wishes, complaints, hacking, are NOT requirements.
If this is true then we could see them in a list. And there would be no feature creep.
None of these are requirements. There could be TRANSLATED INTO requirements for example:
1. a. 64 i/o
1.b. 512kb memory
1.c. 160 Mhz
2. not a requirement, this is a goal or intent or something else, but not a requirement.
3.a. { This set of instructions to support C/C++}
3.b. { no idea what this could be talking about, but it might be transofrmed into arequirement by Roy E or Jazzed or heater, etc}
3.c. I/O functions i.e. Analog, PWM, Encoder, Serial, etc. (if etc were defined with a descreet list)
app helper features (not a requirement until defined)
(instructions or smart pins). (not a requirement until the instructions are explicitely listed and smart pins is explicitely defined)
4. a wish, but not a requirement
Unfortunately, it IS the typical process, which is why so many projectws for so many outfits go over schedule and over budget. No formal requirements is what we in the industry call "nuts". As in "You guys are nuts to start spending money before you know what you want to buy". Projects that succeed tned to have beter requiremnts, projects that fail tend to have lousey requirements.
This usually results in garabage out, or nothing. What are we seeing so far? Lost of work and effort, and a good basis of learning to move forwared. But the key milestone is what?
This sounds cool. Exactly what it the the package power envelope? I'm guessing something about voltage and current. If this had specific numbers, it could be a requirement. For example, less than 300 mA at 5 volts.
.
Ok, but that is the deal about requires as a tool to fight feature creep. Which of those items take longer and cost more than the items on the short list? Consider rethinking those. Which items contradict the items on the short list? Consider rethinking those. Which items are already present by virtue of the items on the short list? Would those add value? Consider rethinking those (if they are missing).
Keep sight of KISS.
kitchen sink = bad.
on time and under budget = good.
I know this is obvious, but it sometimes helps to mention this again (when we notice churn and feature creep)
Then
"- more Pins"
was added as an omission from the original list.
That seems to be the starting list of requirements.
Now, after the things learned from the first P2 "incremental feature implementation" rounds, there is a power requirement.
Chip has pretty much decided on a package, so there is a package requirement.
Features have been added or identified that are really nice to have and would make it a better product - these requirements are added to the mix.
I think this has to be a creative process to some degree. If much of the creative interaction doesn't take place then we will get 16 cogs, 512K HUBRAM, 64 pins and 160MHz and that will be built and it will be OK, but not great, not inspiring and will be accepted with lukewarm anticipation. Because of many business realities, that's the one shot at a P2 for quite a while - from a business standpoint, lukewarm isn't acceptable.
If we go through the creative process and the iterative development and experimentation process that Chip has invited (and tolerated our involvement) then we can do something better. Through this process there will be added requirements (features) but you are correct that the 4 or 5 core requirements need to remain and be the minimums that we can't go below.
Chip's vision and experience and Ken's business knowledge is what we trust to say when better is good enough and the pursuit to perfect (or even "more better") is no longer a win-win solution.
heater is the one you should listen to.
I only list what is a requirement, and what is not a requirement. From my perspective, I don't know (and I'm not supposed to care) if any given requirement has any particular value. My job is to ask "can it be tested as yes/no, present/not present" ; that is, are there real workable requirements. Usually this shows if and where we are spinning our wheels.
I'm not trying to be jerk or anything. Asking these questions and going through this excersie can sometimes really turn things around.
These are the entry points of feature creep; "nice" and "better" are not testable "yes/no" or "present/not present". This is the red flag that the process guy waves.
Its ALWAYS creative process, the question is whether the process is out of control or not. If not, this can be a way to reel it back in.
In my unexpert opinion, 16 cogs, 512K HUBRAM, 64 pins and 160MHz might be THE game changer. Multicores/no interupts is the primary difference between the prop and other choices. Maximize strengths, don't compete on your weaknesses, all that.
This thread is just process guy input, to review that the requirements are understood and are actionable. As always, people smarter than me get to decide what actions if any are appropriate.
Some people never learn.
I think Chip did learn this though because the P8x32a project is called p-nut, and he bought a wall-nut grove.
You know what I've learned?
You can lead a horse to water, but you can't make it drink.
You can lead a horticulture, but you can't make her think.
You can manage any program, but they never seem to shrink.
I also learned that people get annoyed when you say what Chip should be doing even if you're right.
It's Chip's nut to crack.
I've learned:
You will have better success with #1 and #2
...and Herding cats resembles project management in many ways but with cats, your results are more predictable.
True, but a form of video that is used is large volumes is LCD drive, and hopefully all the Logic in P1+ Video stream can drive not only DACs, but also has an alternate mode for HW streaming parallel data to a LCD. (should also be useful on SDRAM)
Prof. Braino's intervention is well-timed ... the high-level requirements need to be nailed properly in order to move forward successfully.
Is there anyone out there who would seriously argue otherwise?
T o n y
Get me it, NOW!
Perhaps you're a poet, but did not know it.
Please nobody cease speaking about what you think is important here. All your inputs have proven quite valuable. Brutal criticism is welcome, too.
In which case, your beanie clashes with your tie. Sorry, it had to be said.
Jretsapdoog reluctantly raises hand. "Guilty," he pleads, sheepishly. The "ome" would be me. Yeah, it's possible that I got carried away or overstated it.
But here's the thing:
[1] Regarding the Prop 1, I think the inclusion of video (composite and VGA) made it much more enjoyable to design for Chip. It's even possible that he wouldn't have designed it without the thrill of putting video in it. Furthermore, when the chip was described in Circuit Cellar magazine, it seems like the video hardware was what made the chip standout. I'll bet a lot of people, including some engineers, would have never noticed the chip if it didn't include video capabilities. As such, it might not have taken off as well.
[2] Although most current volume users of the P1 don't use video in their final projects, they may have well used video during debugging, and almost for sure used it when learning about the P1. I'd venture that some of those volume users would have never used the P1 without first being attracted to it by its easy video generation. The same will also apply to the new chip.
[3] The P1.X/P2 will likely either be aimed at or at least attract a somewhat different audience than the P1 due to power consumption and cost and maybe other factors. I think that it would be kind of a mistake to assume that the users will be the same. For users wanting to build more complex systems with user interfaces, video could be a deal-maker, not a deal-breaker. No, quadcopters won't likely utilize video while they're flying (though they could upon landing to report things), but things like CNC controllers and so on easily could (if they could fly, lol, lazy me). That's why I restated the user requirements in terms of the type of projects the chip should be able to be applied to, not simply how many cogs or pins and so on (even though I agree with the rough requirements layout that's been given here). The new chip might be the "go-to" chip for video and deterministic control.
[4] Chip has stated that the video circuitry doesn't take up that much space (or overlaps significantly with the other planned (analog) features). And a lot of circuitry was removed when color space conversion was stripped out during streamlining.
[5] The user survey that Ken has touched upon is an incomplete picture of the user experience with the chip. I'm sure he hasn't heard from many users that didn't use the chip as well as not heard from many that did/do. And, if the P1 had had, say, 4 times the hub RAM as it does, perhaps more users would have used video. Seriously!
[6] The new chip (and to some extent the existing one) won't be going into very inexpensive products. It can't due to its cost and the availability of low-cost uC's For Parallax to focus on that market would likely not work (unless they can make a sub-$2 Prop, possibly scaled down). Ken has said that they are targeting companies making products that sort of command a premium price because they target specialized needs or whatever (or words to that effect). It's likely that video could be useful for many of those companies.
[7] The new chip might be able to go after a bit of the display controller market, though at lower color depth (using only hub RAM). However, it can't directly compete without more memory. Now, if the new chip had, say, 1 or 2 megabytes of RAM (or some say 768KB), it could really compete much better, but that's apparently not in the cards. Who knows, though: Chip might magically be able to kick it up a bit somehow (though, if done, there'd probably be little code space left over), or maybe this chip will be the foundation for a follow-on chip done at 90nm or below that does have a meg or so of RAM. Or SDRAM might be interfaced. Anyway, at the very least, the new chip should replace the need for an LCD controller with memory in some applications.
Aside: it would probably really help if Chip would bring out digital video to the pins directly, bypassing the D/A circuitry (as on the P1). That's something that I don't think Chip has ever commented on completely or committed to. I'm not sure why. Perhaps it would change the existing circuit pathways too much or something. Someone should perhaps start a thread on that to try to pin it down further (pun intended). More likely, things are still in a bit of flux and Chip is holding off on making any announcements. Or maybe the smart pins will somehow be fast enough or smart enough to handle that. Perhaps he's answered already but we haven't taken notice. Anyway, I digress.
[8] The thought of producing a next-generation chip NOT capable of self-hosting and/or video is likely anathema to Chip. Didn't he already do video swirling and so on with the P2 design to test and demo it? Anyway, it's almost for sure that Chip's chip and Parallax under Ken's wings will target market segments not adequately served by other chips, and video is a part of that. I recall Ken going to great lengths (with some forum support) to give a presentation about the P1 using the P1 to generate the video. Hello! Eh, ...World! Isn't the chip going to be much more FUN to promote with video!! (rhetorical question) That will impress users that don't necessarily need to implement video in final products.
In conclusion:
(R) CHIP WANTS VIDEO! (G) CHIP WANTS VIDEO! (B) CHIP WANTS VIDEO! (H) CHIP WANTS VIDEO! (V) CHIP WANTS VIDEO!
Video might not be in someone else's list of requirements, but it is in Chip's (thankfully, from my perspective). And as I've said before, VGA video is FAR FROM DEAD! Anyway, to even suggest that video is not a requirement for this chip from Chip and Parallax is completely off-base. It is! Will it be used in some form by most users? That remains to be seen. Will many users use it? Yes, I believe so. Will many users not use it? Of course. So what?
You need a requirements statement? Here it is: Produce a microcontroller-like chip that can target standalone systems that is capable of presenting a decent human interface, with however much memory and speed that is needed to do so and with as many pins and cogs as are required to hit that goal. The latter part is detail. Or, even simpler: Produce a chip that Chip is proud of! Either way, video is a part of that. It has been written (in book-form, I think), "Do what you love and the money will follow" (because you'll do it well and in a special way since you love working on it). The latter seems to drive Chip as much as or more so than confining his creativity to presumed user requirements. With the tag-team of Chip and Ken, binary stars of a sort tugging and whipping each other through space, I believe enough attention will be paid to creativity and business strategy to carry the day for Parallax's purposes (as well as ours).
Even now, video motivates me. I've been diddlefritzing with FISH Forth on the LPC1114 lately. It's a lovely OS/language on a lovely little chip. But like virtually every other uC employing a TIL, it needs to be connected to a terminal. It is incredible that the P1 can run multiple TIL instantiations and still provide its own terminal function by providing video, keyboard, and pointer interfaces. If JRetSapDoog is correct - that Chip wants video in the Px - mark me as +∞
Marketing is indeed different than advertising. Marketing the P1, and probably the Px, imho, should be all about what it can do...simultaneously...and to perfection. It is too difficult to explain at a glance the efficiency of the Propeller's instruction set, or the nuances of cog-to-cog cooperation, or the synergy between SPIN and PASM. Save your breath and your money, and just demonstrate all the crazy results of those cooperating factors.