PDA

View Full Version : Prop 1.5, What it could have been..



ImageCraft
11-06-2010, 05:50 AM
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.

RossH
11-06-2010, 06:03 AM
Hi Richard,

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.

ImageCraft
11-06-2010, 06:22 AM
I am willing to seed the money for a C Stamp module if Prop 1.5 is available, but it's up to Parallax to produce that Prop 1.5.

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.

Dr_Acula
11-06-2010, 07:50 AM
With a good external SRAM design, we could have had LMM C executing from external SRAM at approximately SPIN speeds

are you saying we don't have that? Which bit is missing, the LMM C bit, or the speed part?

Heater.
11-06-2010, 08:14 AM
Dr_A,

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.

Dr_Acula
11-06-2010, 08:30 AM
Oh, ok, well are they saying that the speed is not fast enough? I've just spent a day getting C working on the dracblade with a LMM (the 'program' is 89kb, so already there is no way it can run on a native propeller).

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".

jazzed
11-06-2010, 08:34 AM
LMM C executing from HUB runs at about 4MIPS (5MIPS*3instructions + 2.5MIPS*1instruction + overhead of complex jumps, etc...).

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 :)

RossH
11-06-2010, 09:09 AM
Hi Dr_Acula,

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.

ImageCraft
11-06-2010, 09:30 AM
LMM C executing from HUB runs at about 4MIPS (5MIPS*3instructions + 2.5MIPS*1instruction + overhead of complex jumps, etc...).

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 :)

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.

Bill Henning
11-06-2010, 04:12 PM
Personally, I regularly bug Ken (and occasionally Chip) for Prop1.5

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...


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.

Rayman
11-06-2010, 04:59 PM
I would have agreed with you guys a while ago...

But, now with Prop2 around the corner with built in support for external memory (right?), I think Prop2 makes Prop1.5 irrelevant...

Sapieha
11-06-2010, 07:16 PM
Hi Rayman.

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





I would have agreed with you guys a while ago...

But, now with Prop2 around the corner with built in support for external memory (right?), I think Prop2 makes Prop1.5 irrelevant...

hover1
11-06-2010, 08:04 PM
An estimated pricing structure would also help, (Prop1=$7.99, Prop1.5=$?, Prop2=$?), to see if the Prop 1.5 would fit, but Sapieha brings up a good point of power consumption.

Jim

Batang
11-06-2010, 08:59 PM
Imagecraft, I know this off topic but since you mentioned it, most of the feedback (I would hesitate to call it bitching) about your C compiler for the propeller that I have read in this forum seems to relate to completeness of product and if your development cost you mention is not exaggerated then it would be reasonable to assume a completed product.

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:)

Rayman
11-06-2010, 09:19 PM
I seem to recall Chip speculating about the cost of the Prop2, and as I remember it, it was very low, just a few dollars more than Prop1.

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 Pilgrim (PhiPi)
11-06-2010, 09:31 PM
A large part or the Prop 2's current consumption comes from leakage, due to the small feature scale, which I don't believe is a function of clock speed.

-Phil

potatohead
11-06-2010, 10:26 PM
IMHO, there is no real reason the Prop 1.5 can't happen.

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

Rayman
11-06-2010, 10:53 PM
A large part or the Prop 2's current consumption comes from leakage, due to the small feature scale, which I don't believe is a function of clock speed.

-Phil

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...

Phil Pilgrim (PhiPi)
11-06-2010, 11:00 PM
...and development of Prop III...
Oh, my! Did you have to say that? Like we need yet another next distraction from reality! :)

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

potatohead
11-06-2010, 11:27 PM
Well, let's just say I'm both a optimist, and longer term thinker.

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.

Ravenkallen
11-06-2010, 11:27 PM
I know this may seem somewhat redundant, but can't people just add more I/O pins using a shift register/ I/O expander? I know these are somewhat slow, but if the main point is extra I/O pins then that would solve the problem, right? Maybe have one cog( using PASM) that will handle all extra I/O functions to increase speed a little? As Phil said, the Prop 1 is still a great uC and it still has a LOT of potential..

jazzed
11-06-2010, 11:54 PM
I know this may seem somewhat redundant, but can't people just add more I/O pins using a shift register/ I/O expander? ...
You're right for many cases. That's one reason why I2C compatible devices are useful. In some cases such as keyboard and mouse data comes in a serial stream anyway so it's not a great loss to use I2C there. Unfortunately other things are more time critical.

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.

hinv
11-07-2010, 03:05 AM
I wonder how fast flexmem could be used in LMM.
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.

ImageCraft
11-07-2010, 05:44 AM
re: PSoC

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.

Bill Henning
11-07-2010, 05:54 AM
Best guess?

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...


I wonder how fast flexmem could be used in LMM.
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.