Prop 1.5, What it could have been..
ImageCraft
Posts: 348
The C compiler thread reminds me of something: I believe the Prop 1.5 could have been made into a decent C Stamp machine. Steve and others SRAM hackers can correct me, but isn't it reasonable to get 128K SRAM running LMM/XMM fetch-execute cycle may be ~10% of native speed, or ~8MHz? Not super fast, but competitive enough for the microcontroller market.
Ah well.
Ah well.
Comments
Yes, I think you are correct - this was an opportunity missed. With a good external SRAM design, we could have had LMM C executing from external SRAM at approximately SPIN speeds - and still have most of the super I/O capability of the Prop available.
Chip said in the "friday forum" today that he expects the Prop I to be around for another 15 years - so I wonder if it's too late for the Prop 1.5?
Ross.
Personally, I do not think $80K or so to churn the silicon is a big risk, especially if Prop 1/1.5 has a 15-20 years of life. That's $5000-$6000 a year.
Oh well.
I should also add that both ImageCraft and Ross have shown that you can most of the multiprocessing features available to LMM C functions. So if the memory is there, you can have most of the unique features of the Propeller available to C users.
are you saying we don't have that? Which bit is missing, the LMM C bit, or the speed part?
Looks to me we do have that.
I think the point of the statement is that when we do that we generally lose most of the I/O pins. Which means we that by adding external RAM we have defeated the point of the Propeller as a micro-controller.
Now if we had those extra pins just for the RAM interface we would have the best of both worlds.
Looks like ImageCraft are happy to invest in a Prop 1.5. Should we start a "Prop 1.5 rescue fund"? If we all chip in in maybe Beau can find a way.
I pledge 200 Euro here and now to kick things off.
So, is it the speed? Didn't we do the maths some time back, essentially more pins = faster external ram speed. Cluso's ram driver is fastest, but uses virtually all the prop pins. The Dracblade is somewhere in the middle and uses 12 pins.
But not everything is speed. If C can be made to run in any arbitrary sized external memory, then you choose the hardware for your speed. Is there a version that runs on an SPI ram - hmm, that only uses two propeller pins. The hardware ends up very simple - a propeller with an external 8 pin chip for eeprom, an external 8 pin chip for external sram, and an SD card.
I'm not sure we have pushed the boundaries of such a model. Consider self contained bits of pasm code, 2k in length, that you can read off an sd card, load into a cog, run for a while, then replace. Your 400kilobyte C program handles loading these in and out. Then you can get the speed with pasm, and have a huge C program as well.
I don't think that needs any new hardware. I think it involves abandoning the idea of "Big Spin", and instead embracing the idea of "Big C with Pasm Cogjects".
The fastest LMM C external memory solution today runs at about 1MIPS uncached.
For SRAM today with one COG it takes about 16 instructions to read a 32 bit instruction for use with LMM C on a smart hardware design (about 3 per byte + address overhead).
Now compare that with what Richard implies: 32 pins used for data is best for LMM C instruction fetch with the rest used for address and IO. One LMM instruction read, would take about 3 instructions (address bits set with two instructions and data read with one). So, to fetch and execute most LMM C instructions would take 5 PASM instructions, that is 250ns or something less than 4MIPS considering overhead of jumps and intermittent HUB access.
So, a Prop1.5 running LMM C straight from external memory would be about the same performance as normal HUB LMM ... if my instruction counts are right. Midnight here so the lack of Coffee (or sleep) may be skewing my judgement
No, I didn't mean we didn't already have it - I meant we could have it as well as a full complement of I/O pins, instead of having to sacrifice a good percentage of them.
Ross.
Thanks Steve, I know you have the numbers :-)
And that's what I meant - a 4MIPS engine (and with FCACHE for loops) is not a bad solution for most people, especially since you have 8 Cogs and zillions of threads if you use Ross' solution. That plus you can always drop to PASM for 80MHz goodness.
This makes a fairly competitive solution as a C-Stamp module.
And 128K is sufficient for most embedded needs. This is speaking from experience. Our customers are not interested in Linux, but reasonably fast IO. The multi-COG is icing on the cake. 128K is almost certainly sufficient for 90% of our customers.
But obviously I don't control the Prop 1.5 destiny.
Someone bitches about their $249 investment in ICC. We sank in $60K-$100K worth of development. If we have Prop 1.5, we may be able to recoup that. Now see why I am so p*off'ed about people complaining about our compiler?
Our partners had warned us about entering the Prop market. Hobbyists and unsure potential with commercial users. Sadly, they are right and I am wrong. Live and learn, as I said.
I have some VERY interesting paper designs for what I could do with that chip - and I have told Ken and Chip that if they make the chip, I will release at least 2 really nice board level products using it.
I also think that Prop 1.5 would co-exist quite nicely with both Prop 1, and later Prop 2 - as it would occupy a different niche. For many solutions Prop 1 is not quite enough, and Prop 2 will be too much... leaving room in the middle for Prop 1.5
Frankly, the number they quoted - a 50k to 100k investment to get Prop 1.5 to market - is peanuts compared to not only the potential income for it, but also compared to what they have recently invested in SX wafers and die's...
But, now with Prop2 around the corner with built in support for external memory (right?), I think Prop2 makes Prop1.5 irrelevant...
You are NOT correct.
If I know Prop II will not be good to BATTERY powered equipment.
THAT give Prop 1.5 all possibility's to FIT space between Prop I and Prop II
Jim
If I recall correctly you were getting the same noise on the PSOC forums.
Your comments on the other (C compiler) thread are of interest as I started that thread in order to get some user opinion before making a decision. QED you provided the answer.
Just a thought:)
It's not clear to me that you couldn't dial down the Prop2 clock speed and get the same processing power for the same battery drain...
-Phil
However, I do think it's a distraction right now, given where Prop II is at, and how well the Propeller currently competes.
It's my opinion that the next Propeller needs to get out there, Parallax makes the sales related investments needed to capture some share, then take the profit from that, back filling with Prop 1.5, and development of Prop III, and related technology.
Time to market is the single most important opportunity cost factor working against Parallax right now.
By way of review, in general, those are:
Cost of operations, Quality, Time to market, Share of market.
Most all core decisions come down to one of those. Often, more than one drives the need for both process innovation, and or product / technology innovation, or building relationships through contracts, covenants, and such.
Where costs are concerned, there are hard costs, where actual dollars exchange hands. Cost of operations, quality drive these more than not. There are soft costs, which can be difficult to put in terms of dollars, and include opportunity costs, where the "cost" really is revenue not recognized, despite the opportunity for it being there and well aligned with the business.
Time to market and overall share contribute to soft costs more than they don't.
Prop 1.5, while desirable, really doesn't impact the core business need at this time.
Having realized a solution to the time to market issue, the focus can move to share, where back filling the product line could deliver a return, multiplied by the increased share possible with the new Prop II.
That's my .02
That's true, but I just happened to be looking at the Prop datasheet and the graphs seem to show that current is nearly perfectly linear with clock frequency...
Personally, I wouldn't care if the Prop 2 were another year or two out. Sure, it'll be great when it gets here; but, in the meantime, there's plenty of untapped capability in the Prop I (and I.5) yet to mine. Moreover, I think Parallax would benefit more by solidifying and extending the Prop I's documentation, dev tools, reference designs, and marketing presence than by committing human and financial capital to an even more complicated chip right away. Overextension would be my greatest fear resulting from a headlong effort to bring the Prop II to market, given the current status of the Prop I.
-Phil
If all goes well, that's where we will be some time from now
You've a valid point Phil, but...
Will those investments in the current Prop, return and balance the opportunity costs associated with Prop II being later to market?
I'm inclined to think they won't, which is why I posted what I did. Not like it's a bad course of action, or that the current base of users wouldn't benefit. I think they would. But... in the longer term, which solidifies the platform and delivers the greatest return?
All of the things you mentioned carry a significant cost, unless done with a well distributed user effort. A return from that will be delayed some, because those things have a time to impact, and it probably takes a cycle or two to really pay off. There is a case for that stuff helping to boost early adoption of Prop II, but then again, wouldn't those efforts, aimed at the new chip do that as well, in that a more solid, potent, easily consumed product launch usually does?
IMHO, that investment made, just starting to really rock when the new device comes out, could have a negative impact, if not matched on Prop II. Otherwise, it may be negative in that the new chip ends up looking "raw" by comparison. Perhaps that's accepted practice, I don't really know, but what I do know is product releases like that typically don't perform as well as those where those investments were made in tandem with the core product engineering and development do. That's true for the industries I've been associated with, and I can't see any reason why it wouldn't be true for this one.
Boiled down then, it's a strong desire for something to happen "now", more than it is a business return, IMHO.
Still, having more pins on Propeller would be a big win in many cases. Parallax's current product development trajectory seems a reasonable extension of the Propeller concept - maybe different variations can be made later.
I agree that prop1.5 would have been great a couple of years ago, or even 1 year ago, even now if the mul and div were implimented in 4 cycles.
This is a bit OT, but "which" Cypress :-)?
They have been shipping our STD compiler since mid-2009 and we sell a PRO compiler as an add-on. Our current relationship is quite fine. Thank you very much.
There are some limits of what we could do to enhance the STD compiler, as Cypress' main goal is to have a absolutely stable product for that. This STD compiler generates 20% better code than our original Cypress STD compiler and 25%-30% better code than Cypress' previous "FREE" compiler. In addition, anyone who wants even more optimizations can get our PRO compiler.
Obviously we have an Agreement for such arrangement.
***
As for "completeness" of the product, we have sold over 10,000 AVR licenses. The Prop C compiler is not less complete than that. So I will leave it as that.
Using VMCOG, once I get the FlexMem driver debugged, I expect LMM running against VMCOG to be 1/2 to 1/4 the speed of running LMM directly from the hub.
Which would actually be pretty damn impressive for SPI serial memory...