It may not be worth much, however I definately agree with both Cluso and Ross.
16 core P16x is a great P1-killer, do-able now with very low risk, and most of all, be almost identical to program as the current P1.
Months ago I mentioned the possibility of some sort of big.Little mix of P1/P2. Having a P2 with 8 little P1 cores available (with their own hub), might fix the commonly voiced concern that you have to waste cores on peripherals.
I'd rather see a faster p1 with a few minor improvements. If we keep the quad access to hub would a partial cog load (block copy) capability be possible for lmm people? (runs in background blocking or yielding to hub read/writes).
I think the p2 is an amazing piece of hardware but needs to be locked down and aggressively optimized before it gets me to treat it as a serious player in the uC market.
I work in a lab where we use p1s and $12 arms for most of our PCBs. I love the propeller for its simplicity (the arm chip we use has separate reference and programming manuals at 1400 and 200 pages each :S ). However that complexity really does pay off. Even though the propeller has 4x the MIPS of the more expensive arm chip, in most cases we find the arm outperforms the propeller due to hw serial interfaces and algorithms which don't lend themselves to simple parallelism (not to mention a hw multiplier).
Our research deals a lot with USB power budgets, and the uC we choose cannot use the majority of this power as most USB powered devices contain more components than a single uC. I bring this up not because I want a USB powered p2 device (I will probably graduate before it is finished) but because there has been a fair amount of effort to make the p2 USB capable. USB has a power budget and until the p2 can be run with regulator inefficiencies and some room for additional components at USB power spec without worrying about sw power usage it has limited usefulness in this application.
Finally I think it is possible to bring power consumption down significantly, with a core this complicated disabling unused ALUs is a must and I have seen some amazing power reductions in my colleagues work. This is not something that should be rushed to production and may require significant redesigns. I have designed a few simple 800Mhz digital blocks (unfortunately this was supposed to be 1GHz...) and most of the logic optimizations and reductions didn't come until I had a working FIXED design to stare at for a few months. I don't know where everyone at parallax is at with funding and r&d limits but this all feels a bit rushed. The p2 isn't even finished functionally yet and ought to be given a chance for clever optimizations after it has been functionally completed and thoroughly tested (with automated test sims for optimization verification) before we start arguing over how much functionality or processing power we can live without.
This has been mentioned/asked, not sure if/why the 2K limit can not be increased to 4/8K.
Otherwise, most sales of Parallax P16x will be cannibalized from existing P1 sales.
New people are going to see 16 Cores, 1600 MIPs, and..... 2K Cog ram...
Good point David, this probably won't win many new customers because of that 2K sticking point.
Forget bolting on hub-exec, etc, just increase all Cores to 8K, and HubRam to a reasonable amount while keeping the chip reasonably sized/powerable by batteries.
My question though is will Parallax have any better luck selling it than the have with the original P1? As I mentioned before, it still has the 2K limit for native code and will still require similar solutions for running high level languages. Granted with 512K of hub memory it will be more practical to run LMM and CMM programs and maybe that's enough that there isn't any need for XMM but it still isn't native execution. Will that make this new P1 hard to sell to people who haven't already bought into the Propeller? If so, it might make it it difficult for this new P1 to pay for itself in sales.
For revisionist history, and by that I mean the actual history one can look at on this forum where the P2 has grown and been enhanced for the last year.
Its far outgrown its humble initial paramaters, and if we hadn't hit this power issue, it probably would have been manufactured and thus marketed as............... a P2. And lets not mentioned whats already been published by Parallax, and how rediculous(sp) it will look for Parallax Semi-Conductor o try to retract all P2 materials and republish it with lower end Cogs, etc... Engineers searching for data on P2 will find actual original P2 docs cached, and the new P1 based P2... looks professional.
Just name this a P16nnnnn, which allows the future P2 to have a higher part number.
There's a lot of 'inside baseball' going around here in the forum that Parallax probably needs to disregard and look at from a business point of view.
+1 on the names Peter (I typed the same thoughts some place)
Even though folks will deny it and fight it, you've proven the value of Forth like languages with the speed, size and elegance you been able to display as you implement feature after feature.
That just turns the Propeller into a totally different architecture. Study the propeller instruction formats in the manual to why this is not a "just".
Now I would draw the line exactly there: a P2 evaluation board, complete with SDRAM, video output, bells leds and whistles, should still be able to be powered from USB.
This is why we need to figure out the power on P2! Nobody wants a P1 killer. That chip is pure profit now. We want to maximize it to fund futures.
If we fab a new one that guts the sales of the P1, then we take a loss similar to what we do if we just engineer the P2 fully. Best case is to maximize the P2, and then get after selling it, again funded by the maximized P1.
I agree with Bill in that we may as well keep the 8 cogs. There are USB capable power profiles possible right now. With some optimization efforts, those improve.
We should lock down the P2, optimize the Smile out of it and then see what we end up with at various power profiles.
Any new chip will partially gut Prop1 sales. The total market will also grow. Even so, if everyone ended up on the newer chip it is still sales for Parallax. Where is the failure there?
There will still be a power consumption advantage for the existing Prop1, not to mention the layout/dual power rail requirements of any enhanced Prop1 being more complicated.
New revenue with the P2 won't come at the expense of existing revenue like it would with a P1 variant.
Additionally, the chip is differentiated enough to warrant the Parallax Semiconductor branding, and some commercial sales efforts. None of that has a significant impact on all the P1 efforts, which remain optimized.
Finally, a P1 variant will devalue the P1 itself, forcing margins down to make room for a competitive P1 variant.
Volumes on the P2 will be lower initially, but they don't cannibalize existing revenue! This, in effect, multiples the new revenue! It's worth more to Parallax because it doesn't cost existing to realize!
That just turns the Propeller into a totally different architecture. Study the propeller instruction formats in the manual to why this is not a "just".
I realize that 'just' was not the best term, however lets do a thought exercise.
If the P2 or P16/32 is produced, what happens?
Outside of the forum geeks like us, who buy probably <10 Props/yr, what percentage of Parallax's commercial customer base is Cog/MIP's constrained?
Lets be optimistic, and go with 50%.
Off the bat, Parallax loses 50% commercial sales of P1 to P2. Not sure of margins, so this could be a recurring null change to Parallax balance sheet.
Lets suppose they sell 1-2K to forum geeks. Probably a nice blip on the balance sheet, but it is most likely a one-time event.
Now, as David IIRC mentioned, how does this help Parallax increase their sales to balance sheet impacting new clients?
Is Parallax selling a uController, or a PSOC/Uproc ?
Lets suppose most Design Engineers hear about the new P2/P16/32, and decide to give Parallax the benefit of the doubt and take a look.
They are all going to see Interrupt-less again( hmmmm...), xCog/Cores, x%hundred MIPS/Cog, xK HubRam ( maybe ?), and then, 2K CogRam.
Then, they're going to see the 1000-1500ma current required to get those MIPs.
Some keep saying you can minimize this by just changing Vcore to lower power use, which is correct.
But then, I think most Engineers are going to look at this, and Parallax as trying to pull a fast one over them.
All the promotions are going to mention the 1600/3200 MIPS, however when you eventually dig into the Docs, you're going to see that trying to keep the device within the constraints of your 'normal' uController current, you have to underclock it to the low-end, which cuts that fabulous MIPs down to 1/8 or 1/16 ?
And, in the back of their mind is still the concern, and most likely real reason for dismissing the Prop, that 2K Cog Ram.
People here are used to it, and have learned to work around it, and as such minimize it.
In my estimation, and experience in discussing it with Engineers I've worked with, its the opposite. Its one of the primary reasons they drop it from consideration. And thats usually above the Interrupt-less paradigm.
IIRC, the 2K CogRam is the number of 9-bit Longs, yes?
My question is, if the Prop I is now so blazingly simple, why not actually improve the P1 Cog, maybe by increasing to 11-bit Longs?
OK, maybe there is a technical reason why not, however considering whats been done on the P2, I'd be surprised if it can't be done in a timely fashion.
But again, Parallax has to have a target in mind for the P2, and I think they are trying to sell a PSOC device in the uC space.
The 2-4W seems fine to me for a PSOC device thats Mains connected, or in a high dollar device that can absorb the cost.
How many actual opportunities there are for that, and how many Engineers they can corral is an entirely different question though.
Outside of 1 poster recently who reports ordering 2K devices per year, my suspicion is that most here are homebrew folks.
Definately the wrong market segment to give any significant weight in what should be a commercial device.
Whatever Parallax does will cannibalize some P1 sales, which if they are all gravy now, will actuallly negatively impact balance unless the alternative is priced at a higher margin.
Just because you make it, doesn't mean they will come.
Propeller instructions are 32 bits. There are two 9 bit fields, the instructions operand source and destination. The rest of the bits are used for the op-code, conditional execution bits, etc. There is no room for 4 more bits.
Changing this wold require 36 bit wide COOG registers. Or some clunky memory paging. It would become a different machine.
New revenue with the P2 won't come at the expense of existing revenue like it would with a P1 variant.
Additionally, the chip is differentiated enough to warrant the Parallax Semiconductor branding, and some commercial sales efforts. None of that has a significant impact on all the P1 efforts, which remain optimized.
Finally, a P1 variant will devalue the P1 itself, forcing margins down to make room for a competitive P1 variant.
Volumes on the P2 will be lower initially, but they don't cannibalize existing revenue! This, in effect, multiples the new revenue! It's worth more to Parallax because it doesn't cost existing to realize!
Uhh, no?
Anyone constrained by the P1 will upgrade to the P2.
Those P1 sales are lost, along with the probably higher margins associated with that product. If the P2 goes ahead as is, it sounds like it is rather expensive at the BOM level, which means it has to be priced even higher. Gross margins. If a device takes 1 P1 or 1 P2, if P1 is all gravy, and P2 has lower margin, net-net is lower profit for Parallax.
"New revenue with the P2 won't come at the expense of existing revenue like it would with a P1 variant. "
Failing to adapt and improve the P1 for 10 years is not a good sales strategy. All it does is allow your competition time to overtake you on an feature-parity, and then beat you to death on pricing, power use and speed. A stagnant P1 does not become a value proposition over the years.
"Volumes on the P2 will be lower initially, but they don't cannibalize existing revenue! This, in effect, multiples the new revenue! It's worth more to Parallax because it doesn't cost existing to realize!"
Volumes of the P2 will obviously be low initially. However I think Ken would dispute the rest of your statement as backwards.
I hope the business plan has been better thought out. Not sure where Parallax will stand if the sunk $4M is a non-starter.
>why not actually improve the P1 Cog, maybe by increasing to 11-bit Longs?
Double it to 4KB (1024 longs) with 10bit, as both D and S side needs it the new cog Long will be 34bit.
But keep Hub-ram as 32bit and if Cog-ram is used to store data to/from hub, 2 bits will be unused(wasted) but is not a big deal.
I think the decision for what type and how many has to be a decision Parallax has to make. Part of the problem is that there are different market segments represented here on the forum. Obviously the hobbyists, which may be a lot of people, but usually don't buy too many. Then the education market which might be big numbers, but they have always been very price sensitive. The PLC market, which can be low-moderate volumes, and is usually not price/power sensitive. Then there is the general purpose micro-controller market (which I fall into). Now I can tell you that no one part will solve all the problems, that's why there are literally hundreds of versions of ARMs available to the micro-controller market over a wide range of price and performance. I gather that Parallax wants to at least capture a few design wins in the general purpose market, but I've always thought that was pretty unlikely. I say that because a 200 MIP COG is only true if your code fits in 512 assembly language instructions, and that is pretty unlikely. To drop back to an interpreter is a non-starter for most embedded engineers, because performance drops off too much (typically 10x, but in the Prop case more like 30x because of slow memory access). Interpreters are great on PCs or servers, just look at Java, PHP, JS, ... but then you are executing on a machine with gobs of memory and easily averaging 1000 MIPs. Memory constrained embedded CPUs just don't perform as well, even ARMs.
The P2 has a lot of things going for it over the P1. The first being hub-execution, which to even have a hope in the general market is a MUST have. I'm assuming that with it a COG will average around 100 MIPs, because while you have caching of hub RAM most studies I've seen say you typically get about 4-5 instructions in linear code coming out of compilers. So about half the time you will have a branch and have to wait for another access cutting the speed by at least 1/2. I haven't kept up with the multi-threading of the COG and whether each thread gets a hub buffer or not. Obviously that affects performance greatly, and it would be best if each had a wide buffer.
I think comparing multi-threaded P2 COG would be better than individual P1 COGs for a lot of peripheral emulation. It doesn't take much to be a UART, SPI, I2C ... And it has always seemed like a waste of a P1 to do one of those functions.
As someone above said it would be desirable to be powered from a USB and while there are chargers out there that can supply 10W, most PCs will shut down a port when it exceeds 2.5W. Yes I know you could specify that in the manual, but who reads those, and you'll have to explain to the user why it didn't work, or you have to supply a wall wort, which too me is a pain, because everything else I own runs off a USB connector.
I wonder how much of the growth in the P2 logic is driven by the 1 clock/cycle, which means a pipeline and pipelines mean exception processing (ie waiting for prior instructions to be done with a register another instruction wants to use). That's why I like the multi-threading, as in cases I've seen it adds less logic and gives you a number of virtual CPUs which run deterministically and independently.
So a lot of blather here, but if you build it they will come doesn't work in the real world. You need to decide who you are building it for.
Not trying to be snarky, but this brought a chuckle.
Why exactly do we require LMM again???
2K is 2K is 2K.
Anyone, especially an Engineer looking at a Prop, P2, P3, etc, is going to see 8 Cores, great. 2K, WTF?
Having next a full section on the Hub, and how you can basically swap memory, or do something like LMM seems to be one of those "screw it, starting to remind me of a PIC".
Now, give an Engineer a Prop, P2, P3 with 8 Cores, and 8K each, and THEN mention 64/128K Hub, and you may indeed have something.
Obviously it would take a genius to figure out how to do something like this. And, we just happen to have such a one on Staff!
Seriously, if there ever, ever was a time to take a hard look at this issue, its now.
I'll go one better and say this is a unique and rare Opportunity to fix what is mentioned almost 100% of the time in every thread on the internet where Prop happens to pop-up.
Anyone constrained by the P1 will upgrade to the P2.
Maybe. Likely. But they are also likely to continue using P1 chips! A P1E may well see less use of P1 chips, then again...
Now, after thinking through the power issue, a P1E that really performs will also really use power. Either chip means ongoing P1 sales for that reason alone!
The process dictates that.
So yes, I may be backward. What I really don't know is how the power issue really impacts everybody. Again, either chip will have a power budget that is markedly different from P1. Process issues.
My basic assumption was the low power demands are not well addressed by either chip, meaning a lot of P1 activity will continue because it's super easy, still does what it does very well, and doesn't have the power considerations.
From there, the question is how much new business potential is there for P1E as opposed to the P2?
I don't see the P1E being anywhere near as attractive to new people, not using Propellers at all as the P2 is. And that's really the core basis for what I wrote above.
If that's wrong, then yes! I may well have it backward. Agreed.
I still would want a P2 in some semblance of its current form because of the breakthrough of hub code execution.
It's also just plain faster at clawing through code and toggling pins.
On the P1 I always feel:
1) compiled code space and speed limited
2) instruction execution speed limited (raw pin toggle speed)
3) compute limited (lack of fast multiply, lack of fast floating point)
4) pin guilt (it's like 4-6 I/O pins too short)
Personal conclusions:
P1 is too slow and small for proper USB
P1 is too slow and small for driving a bunch of the 16x32 RGB displays without kludges.
P1 is too slow and small for driving HD video displays (without cog guilt) and the various LCD panels.
P1 lacks analog in and out. Analog saves pins.
P1 lacks serial stream hardware to make it less code intensive to receive and send serial data.
P1 has a comfortable amount of cogs to waste on trivial things without too much guilt.
A 4 cog P2 still solves the compiled code speed and size limitation, compute speed, analog needs, pin count needs, and pin speed problems. And hopefully serial streaming problems.
But nowhere in the last decade did anyone seem to care about power budget, and I'm frankly a bit angry that it seems to have blown up like this.
But a 4 cog P2 does kill the simplicity idea of "just fire off a cog" for this single task. It would require combination drivers to be practical....
But is that bad?
Cog 1: General compute
Cog 2: USB controller (and analog audio?)
Cog 3: Video and SDRAM driver
Cog 4: Peripheral (like serial, SPI, Streaming, Audio, whatever else)
It seems a little cramped.
So what about the 6 cog compromise?
Cog 1: General Compute
Cog 2: USB controller (and analog audio?)
Cog 3: Video and SDRAM driver
Cog 4: Bit bang RS232 Serial and Analog Audio, other bit bang serial like infrared, SPI or I2C using hardware assist.
Cog 5: Ethernet or free cog
Cog 6: blue sky groundbreaking feature driver
I'm working on an industrial application that needs a few hundred high performance chips (P2) as well as many lower performance chips like a P1 for each system. I expect the annual volume of the smaller units to grow to well over 10k units per year, perhaps 100k units. The problem is that I need some code security feature and low power consumption. This leaves the present P1 out of the running, but any of the proposed P2 alternatives would be a good choice for the high performer. So, if a P1B were to become available with the enhancements I need, then I would design that chip in.
Alternately, I would also consider being an anchor client (and possibly funder) for the development of a P1 like device with a few of the P2 features included. I had broached this subject with Ken a year ago, but so far there has been little interest. So my design is currently proceeding on a different path.
Perhaps there is renewed interest and opportunity now.
I look at it the other way around. The P2 has 8 CPU's executing from HUB memory that happen to have 512 registers. But, as a bonus speed boost one can also execute code from those nice fast registers.
When you put multiple processors together sharing RAM as in modern ARM and Intel devices there is a law of diminishing returns coming in to play. Adding more processors reduces the memory bandwidth of each. Past a certain number it's just not worth adding anymore.
This is true of the Prop II as it is of any other symmetric multi-processor. But the PII has that bonus, with fcache the C compiler can stuff small tight loops into the COG and get around that HUB bandwidth problem.
An example of this working very well is the FFT on the propeller, The guts of the FFT executes from withing COG giving about the same performance as the hand crafted PASM version. No special coding need be done to benefit from this bonus.
>Instruction being wider than HUB LONGs would make LMM operation impossible. That is a no-no.
As Special Registers (OUTA,INA etc) should be move to the end of the 4Kb block
The two extra 10bits could be added to bit32 and bit33 of a 34bit long
LMM interpreter would have to live in the upper 512longs only, as to have access to new OUTA location etc
Regular RDlong could use WC flag to set these extra two bits to on or off.
And use WS flag to auto increment by 4, perfect LMM RDlong fixed for you.
There is no P2 no P1B. Just speculation on a processor that has no major design wins and a couple warts that can be show stoppers in terms of adopting the processor by industry.
If Ken and Chip want to make a P1B they should ask folks in the industry not hobbyists what they find as important in terms of processor selection and what they consider show stoppers in terms of adoption.
The problem with the Prop supporters here, is that no matter what flaws the Prop has(like the 2K cogs) they will overlook it and make excuses. To me the 2K limit is bad and needs to be revisited by Chip even if it means redoing the instruction set and upsetting some hobbyists.
Really 2K Ram per processor in 2014. That's just a throwback to the era of the Z-8 and CPM.
>I'm not sure I get the idea.
>LMM code needs to be able to access registers in the COG.
You say don't make cogs above 2Kb, as LMM would not work.
I say fine, you only get to use the upper 2Kb as you have the option to always set the two 10bits every time you get a RDlong from hub.
Though I don't know how to handle #S, as intermediate values can now be 0-to-1023
If the RDlong notice that the I-flag is set it does not set bit10 for the S-field even if WC is specified. (but now only 0-511 values allowed for LMM)
As to not waste cog ram, maybe you can use the lower 512long for a lockup table etc,
For none LMM, double the space will be nice so you can breath.
The P2 with HUBEXEC does not have a 2K limitation.
As for asking industry, I have been a strong advocate of precisely that for years. Posts are there for the looking.
However, we are here, and maximizing this effort happens, or failure happens.
Say we get the P2 produced. The cycle begins again. Maybe asking industry can happen that time for P3,
Market driven design did not happen this cycle. I think the product of this cycle can be sold, and it can fund another attempt.
There are niches where this P2 design can do well. Exploit them!
Of the two, I see the most new nich potential in P2. I see additional revenue, but at a higher P1 revenue cost with P1E.
Bootstrapping Parallax Semiconductor is best aligned with P2, due to the new opportunities it presents and those experiences are high value ones for future devices. I do not see the same dynamics in play for P1E, as it's aimed at the same niches P1 currently is. And it comes with more of the same limitations and less of the high value features and I suspect a similar high power budget, while not offering the same high performance potential the P2 design does too.
Comments
16 core P16x is a great P1-killer, do-able now with very low risk, and most of all, be almost identical to program as the current P1.
Months ago I mentioned the possibility of some sort of big.Little mix of P1/P2. Having a P2 with 8 little P1 cores available (with their own hub), might fix the commonly voiced concern that you have to waste cores on peripherals.
I think the p2 is an amazing piece of hardware but needs to be locked down and aggressively optimized before it gets me to treat it as a serious player in the uC market.
I work in a lab where we use p1s and $12 arms for most of our PCBs. I love the propeller for its simplicity (the arm chip we use has separate reference and programming manuals at 1400 and 200 pages each :S ). However that complexity really does pay off. Even though the propeller has 4x the MIPS of the more expensive arm chip, in most cases we find the arm outperforms the propeller due to hw serial interfaces and algorithms which don't lend themselves to simple parallelism (not to mention a hw multiplier).
Our research deals a lot with USB power budgets, and the uC we choose cannot use the majority of this power as most USB powered devices contain more components than a single uC. I bring this up not because I want a USB powered p2 device (I will probably graduate before it is finished) but because there has been a fair amount of effort to make the p2 USB capable. USB has a power budget and until the p2 can be run with regulator inefficiencies and some room for additional components at USB power spec without worrying about sw power usage it has limited usefulness in this application.
Finally I think it is possible to bring power consumption down significantly, with a core this complicated disabling unused ALUs is a must and I have seen some amazing power reductions in my colleagues work. This is not something that should be rushed to production and may require significant redesigns. I have designed a few simple 800Mhz digital blocks (unfortunately this was supposed to be 1GHz...) and most of the logic optimizations and reductions didn't come until I had a working FIXED design to stare at for a few months. I don't know where everyone at parallax is at with funding and r&d limits but this all feels a bit rushed. The p2 isn't even finished functionally yet and ought to be given a chance for clever optimizations after it has been functionally completed and thoroughly tested (with automated test sims for optimization verification) before we start arguing over how much functionality or processing power we can live without.
Otherwise, most sales of Parallax P16x will be cannibalized from existing P1 sales.
New people are going to see 16 Cores, 1600 MIPs, and..... 2K Cog ram...
Good point David, this probably won't win many new customers because of that 2K sticking point.
Forget bolting on hub-exec, etc, just increase all Cores to 8K, and HubRam to a reasonable amount while keeping the chip reasonably sized/powerable by batteries.
For revisionist history, and by that I mean the actual history one can look at on this forum where the P2 has grown and been enhanced for the last year.
Its far outgrown its humble initial paramaters, and if we hadn't hit this power issue, it probably would have been manufactured and thus marketed as............... a P2. And lets not mentioned whats already been published by Parallax, and how rediculous(sp) it will look for Parallax Semi-Conductor o try to retract all P2 materials and republish it with lower end Cogs, etc... Engineers searching for data on P2 will find actual original P2 docs cached, and the new P1 based P2... looks professional.
Just name this a P16nnnnn, which allows the future P2 to have a higher part number.
There's a lot of 'inside baseball' going around here in the forum that Parallax probably needs to disregard and look at from a business point of view.
I expect more of this of course ;-)
This is why we need to figure out the power on P2! Nobody wants a P1 killer. That chip is pure profit now. We want to maximize it to fund futures.
If we fab a new one that guts the sales of the P1, then we take a loss similar to what we do if we just engineer the P2 fully. Best case is to maximize the P2, and then get after selling it, again funded by the maximized P1.
We should lock down the P2, optimize the Smile out of it and then see what we end up with at various power profiles.
+1
Just don't rush to production decisions until things have actually been finished
There will still be a power consumption advantage for the existing Prop1, not to mention the layout/dual power rail requirements of any enhanced Prop1 being more complicated.
I don't believe a P16x/P32x will be a P1 killer for the simple reason that it won't come as a DIP40.
Anything that require a PCB redesign isn't going to be dropped in without a lot of thought.
What I'm getting at is this:
New revenue with the P2 won't come at the expense of existing revenue like it would with a P1 variant.
Additionally, the chip is differentiated enough to warrant the Parallax Semiconductor branding, and some commercial sales efforts. None of that has a significant impact on all the P1 efforts, which remain optimized.
Finally, a P1 variant will devalue the P1 itself, forcing margins down to make room for a competitive P1 variant.
Volumes on the P2 will be lower initially, but they don't cannibalize existing revenue! This, in effect, multiples the new revenue! It's worth more to Parallax because it doesn't cost existing to realize!
I realize that 'just' was not the best term, however lets do a thought exercise.
If the P2 or P16/32 is produced, what happens?
Outside of the forum geeks like us, who buy probably <10 Props/yr, what percentage of Parallax's commercial customer base is Cog/MIP's constrained?
Lets be optimistic, and go with 50%.
Off the bat, Parallax loses 50% commercial sales of P1 to P2. Not sure of margins, so this could be a recurring null change to Parallax balance sheet.
Lets suppose they sell 1-2K to forum geeks. Probably a nice blip on the balance sheet, but it is most likely a one-time event.
Now, as David IIRC mentioned, how does this help Parallax increase their sales to balance sheet impacting new clients?
Is Parallax selling a uController, or a PSOC/Uproc ?
Lets suppose most Design Engineers hear about the new P2/P16/32, and decide to give Parallax the benefit of the doubt and take a look.
They are all going to see Interrupt-less again( hmmmm...), xCog/Cores, x%hundred MIPS/Cog, xK HubRam ( maybe ?), and then, 2K CogRam.
Then, they're going to see the 1000-1500ma current required to get those MIPs.
Some keep saying you can minimize this by just changing Vcore to lower power use, which is correct.
But then, I think most Engineers are going to look at this, and Parallax as trying to pull a fast one over them.
All the promotions are going to mention the 1600/3200 MIPS, however when you eventually dig into the Docs, you're going to see that trying to keep the device within the constraints of your 'normal' uController current, you have to underclock it to the low-end, which cuts that fabulous MIPs down to 1/8 or 1/16 ?
And, in the back of their mind is still the concern, and most likely real reason for dismissing the Prop, that 2K Cog Ram.
People here are used to it, and have learned to work around it, and as such minimize it.
In my estimation, and experience in discussing it with Engineers I've worked with, its the opposite. Its one of the primary reasons they drop it from consideration. And thats usually above the Interrupt-less paradigm.
IIRC, the 2K CogRam is the number of 9-bit Longs, yes?
My question is, if the Prop I is now so blazingly simple, why not actually improve the P1 Cog, maybe by increasing to 11-bit Longs?
OK, maybe there is a technical reason why not, however considering whats been done on the P2, I'd be surprised if it can't be done in a timely fashion.
But again, Parallax has to have a target in mind for the P2, and I think they are trying to sell a PSOC device in the uC space.
The 2-4W seems fine to me for a PSOC device thats Mains connected, or in a high dollar device that can absorb the cost.
How many actual opportunities there are for that, and how many Engineers they can corral is an entirely different question though.
Outside of 1 poster recently who reports ordering 2K devices per year, my suspicion is that most here are homebrew folks.
Definately the wrong market segment to give any significant weight in what should be a commercial device.
Whatever Parallax does will cannibalize some P1 sales, which if they are all gravy now, will actuallly negatively impact balance unless the alternative is priced at a higher margin.
Just because you make it, doesn't mean they will come.
Propeller instructions are 32 bits. There are two 9 bit fields, the instructions operand source and destination. The rest of the bits are used for the op-code, conditional execution bits, etc. There is no room for 4 more bits.
Changing this wold require 36 bit wide COOG registers. Or some clunky memory paging. It would become a different machine.
Uhh, no?
Anyone constrained by the P1 will upgrade to the P2.
Those P1 sales are lost, along with the probably higher margins associated with that product. If the P2 goes ahead as is, it sounds like it is rather expensive at the BOM level, which means it has to be priced even higher. Gross margins. If a device takes 1 P1 or 1 P2, if P1 is all gravy, and P2 has lower margin, net-net is lower profit for Parallax.
"New revenue with the P2 won't come at the expense of existing revenue like it would with a P1 variant. "
Failing to adapt and improve the P1 for 10 years is not a good sales strategy. All it does is allow your competition time to overtake you on an feature-parity, and then beat you to death on pricing, power use and speed. A stagnant P1 does not become a value proposition over the years.
"Volumes on the P2 will be lower initially, but they don't cannibalize existing revenue! This, in effect, multiples the new revenue! It's worth more to Parallax because it doesn't cost existing to realize!"
Volumes of the P2 will obviously be low initially. However I think Ken would dispute the rest of your statement as backwards.
I hope the business plan has been better thought out. Not sure where Parallax will stand if the sunk $4M is a non-starter.
Double it to 4KB (1024 longs) with 10bit, as both D and S side needs it the new cog Long will be 34bit.
But keep Hub-ram as 32bit and if Cog-ram is used to store data to/from hub, 2 bits will be unused(wasted) but is not a big deal.
The P2 has a lot of things going for it over the P1. The first being hub-execution, which to even have a hope in the general market is a MUST have. I'm assuming that with it a COG will average around 100 MIPs, because while you have caching of hub RAM most studies I've seen say you typically get about 4-5 instructions in linear code coming out of compilers. So about half the time you will have a branch and have to wait for another access cutting the speed by at least 1/2. I haven't kept up with the multi-threading of the COG and whether each thread gets a hub buffer or not. Obviously that affects performance greatly, and it would be best if each had a wide buffer.
I think comparing multi-threaded P2 COG would be better than individual P1 COGs for a lot of peripheral emulation. It doesn't take much to be a UART, SPI, I2C ... And it has always seemed like a waste of a P1 to do one of those functions.
As someone above said it would be desirable to be powered from a USB and while there are chargers out there that can supply 10W, most PCs will shut down a port when it exceeds 2.5W. Yes I know you could specify that in the manual, but who reads those, and you'll have to explain to the user why it didn't work, or you have to supply a wall wort, which too me is a pain, because everything else I own runs off a USB connector.
I wonder how much of the growth in the P2 logic is driven by the 1 clock/cycle, which means a pipeline and pipelines mean exception processing (ie waiting for prior instructions to be done with a register another instruction wants to use). That's why I like the multi-threading, as in cases I've seen it adds less logic and gives you a number of virtual CPUs which run deterministically and independently.
So a lot of blather here, but if you build it they will come doesn't work in the real world. You need to decide who you are building it for.
Why exactly do we require LMM again???
2K is 2K is 2K.
Anyone, especially an Engineer looking at a Prop, P2, P3, etc, is going to see 8 Cores, great. 2K, WTF?
Having next a full section on the Hub, and how you can basically swap memory, or do something like LMM seems to be one of those "screw it, starting to remind me of a PIC".
Now, give an Engineer a Prop, P2, P3 with 8 Cores, and 8K each, and THEN mention 64/128K Hub, and you may indeed have something.
Obviously it would take a genius to figure out how to do something like this. And, we just happen to have such a one on Staff!
Seriously, if there ever, ever was a time to take a hard look at this issue, its now.
I'll go one better and say this is a unique and rare Opportunity to fix what is mentioned almost 100% of the time in every thread on the internet where Prop happens to pop-up.
We may hate it, but Perception is often Realty.
Maybe. Likely. But they are also likely to continue using P1 chips! A P1E may well see less use of P1 chips, then again...
Now, after thinking through the power issue, a P1E that really performs will also really use power. Either chip means ongoing P1 sales for that reason alone!
The process dictates that.
So yes, I may be backward. What I really don't know is how the power issue really impacts everybody. Again, either chip will have a power budget that is markedly different from P1. Process issues.
My basic assumption was the low power demands are not well addressed by either chip, meaning a lot of P1 activity will continue because it's super easy, still does what it does very well, and doesn't have the power considerations.
From there, the question is how much new business potential is there for P1E as opposed to the P2?
I don't see the P1E being anywhere near as attractive to new people, not using Propellers at all as the P2 is. And that's really the core basis for what I wrote above.
If that's wrong, then yes! I may well have it backward. Agreed.
It's also just plain faster at clawing through code and toggling pins.
On the P1 I always feel:
1) compiled code space and speed limited
2) instruction execution speed limited (raw pin toggle speed)
3) compute limited (lack of fast multiply, lack of fast floating point)
4) pin guilt (it's like 4-6 I/O pins too short)
Personal conclusions:
P1 is too slow and small for proper USB
P1 is too slow and small for driving a bunch of the 16x32 RGB displays without kludges.
P1 is too slow and small for driving HD video displays (without cog guilt) and the various LCD panels.
P1 lacks analog in and out. Analog saves pins.
P1 lacks serial stream hardware to make it less code intensive to receive and send serial data.
P1 has a comfortable amount of cogs to waste on trivial things without too much guilt.
A 4 cog P2 still solves the compiled code speed and size limitation, compute speed, analog needs, pin count needs, and pin speed problems. And hopefully serial streaming problems.
But nowhere in the last decade did anyone seem to care about power budget, and I'm frankly a bit angry that it seems to have blown up like this.
But a 4 cog P2 does kill the simplicity idea of "just fire off a cog" for this single task. It would require combination drivers to be practical....
But is that bad?
Cog 1: General compute
Cog 2: USB controller (and analog audio?)
Cog 3: Video and SDRAM driver
Cog 4: Peripheral (like serial, SPI, Streaming, Audio, whatever else)
It seems a little cramped.
So what about the 6 cog compromise?
Cog 1: General Compute
Cog 2: USB controller (and analog audio?)
Cog 3: Video and SDRAM driver
Cog 4: Bit bang RS232 Serial and Analog Audio, other bit bang serial like infrared, SPI or I2C using hardware assist.
Cog 5: Ethernet or free cog
Cog 6: blue sky groundbreaking feature driver
I'm working on an industrial application that needs a few hundred high performance chips (P2) as well as many lower performance chips like a P1 for each system. I expect the annual volume of the smaller units to grow to well over 10k units per year, perhaps 100k units. The problem is that I need some code security feature and low power consumption. This leaves the present P1 out of the running, but any of the proposed P2 alternatives would be a good choice for the high performer. So, if a P1B were to become available with the enhancements I need, then I would design that chip in.
Alternately, I would also consider being an anchor client (and possibly funder) for the development of a P1 like device with a few of the P2 features included. I had broached this subject with Ken a year ago, but so far there has been little interest. So my design is currently proceeding on a different path.
Perhaps there is renewed interest and opportunity now.
Cheers,
Peter (pjv)
Are those a show stopper for P2, assuming it's optimized to 3W or so at higher performance levels?
I look at it the other way around. The P2 has 8 CPU's executing from HUB memory that happen to have 512 registers. But, as a bonus speed boost one can also execute code from those nice fast registers.
When you put multiple processors together sharing RAM as in modern ARM and Intel devices there is a law of diminishing returns coming in to play. Adding more processors reduces the memory bandwidth of each. Past a certain number it's just not worth adding anymore.
This is true of the Prop II as it is of any other symmetric multi-processor. But the PII has that bonus, with fcache the C compiler can stuff small tight loops into the COG and get around that HUB bandwidth problem.
An example of this working very well is the FFT on the propeller, The guts of the FFT executes from withing COG giving about the same performance as the hand crafted PASM version. No special coding need be done to benefit from this bonus.
As Special Registers (OUTA,INA etc) should be move to the end of the 4Kb block
The two extra 10bits could be added to bit32 and bit33 of a 34bit long
LMM interpreter would have to live in the upper 512longs only, as to have access to new OUTA location etc
Regular RDlong could use WC flag to set these extra two bits to on or off.
And use WS flag to auto increment by 4, perfect LMM RDlong fixed for you.
LMM code needs to be able to access registers in the COG. So filling those extra bits in automatically when reading 32 bit's from HUB won't work.
Then there is fache to think about.
You're getting ahead of yourself.
There is no P2 no P1B. Just speculation on a processor that has no major design wins and a couple warts that can be show stoppers in terms of adopting the processor by industry.
If Ken and Chip want to make a P1B they should ask folks in the industry not hobbyists what they find as important in terms of processor selection and what they consider show stoppers in terms of adoption.
The problem with the Prop supporters here, is that no matter what flaws the Prop has(like the 2K cogs) they will overlook it and make excuses. To me the 2K limit is bad and needs to be revisited by Chip even if it means redoing the instruction set and upsetting some hobbyists.
Really 2K Ram per processor in 2014. That's just a throwback to the era of the Z-8 and CPM.
>LMM code needs to be able to access registers in the COG.
You say don't make cogs above 2Kb, as LMM would not work.
I say fine, you only get to use the upper 2Kb as you have the option to always set the two 10bits every time you get a RDlong from hub.
Though I don't know how to handle #S, as intermediate values can now be 0-to-1023
If the RDlong notice that the I-flag is set it does not set bit10 for the S-field even if WC is specified. (but now only 0-511 values allowed for LMM)
As to not waste cog ram, maybe you can use the lower 512long for a lockup table etc,
For none LMM, double the space will be nice so you can breath.
The PII executes code from that 256KB HUB memory. As fast as 8 processors sharing RAM can if I understand correctly.
The processors have 512 registers. Executing code from those registers is a bonus.
@tonty12,
OK, might be workable.
As for asking industry, I have been a strong advocate of precisely that for years. Posts are there for the looking.
However, we are here, and maximizing this effort happens, or failure happens.
Say we get the P2 produced. The cycle begins again. Maybe asking industry can happen that time for P3,
Market driven design did not happen this cycle. I think the product of this cycle can be sold, and it can fund another attempt.
There are niches where this P2 design can do well. Exploit them!
Of the two, I see the most new nich potential in P2. I see additional revenue, but at a higher P1 revenue cost with P1E.
Bootstrapping Parallax Semiconductor is best aligned with P2, due to the new opportunities it presents and those experiences are high value ones for future devices. I do not see the same dynamics in play for P1E, as it's aimed at the same niches P1 currently is. And it comes with more of the same limitations and less of the high value features and I suspect a similar high power budget, while not offering the same high performance potential the P2 design does too.