Prop II: Speculation & Details... Will it do what you want???
Cluso99
Posts: 18,069
It is great to see Parallax Semiconductors launch and I do wish Parallax all the best.
But with the launch comes more Prop II references indicating that we may only get 128KB of hub memory. While external SDRAM will gain some hardware support, it cannot be used as program memory (or not at least without some of the things we do on the Prop I currently).
I was already disappointed with...
* Only 8 cogs
* No cog ram beyond 2KB, banked or otherwise (the fifo access has not been detailed so we don't know how much of this we can use and how)
* I thought at least one cog could/should be a super cog (more cog ram, perhaps hub access when other cogs do not require it)
* No internal EEPROM/Flash (although internal ROM code may mean we can avoid a chip if we have an SD/uSD card)
We certainly seem to have all the features we require on the I/O, including plenty of them (I don't want hundreds like on FPGAs). And we know the counters have had a major revamp and will include lots of new features.
However, in this age, you only have to look around at other chips to see that 128KB is a very small offering on other micros. Five years ago when the Prop I was released, 32KB was almost unheard of. But things have changed.
I for one was looking for a minimum of 256KB and hoping madly that 384KB or 512KB would be achieved. Sadly, I fear this will not be the case.
Parallax is making a fully fledged attempt to play with the big boys.
IMHO Parallax needs to see what other foundries can offer.
Some alternatives for hub sram...
* (Firstly, remember cogs can access hub at 128 bits wide.)
I also note they are achieving much lower power consumption. What are they doing to achieve this?
I fear these options would have a huge impact on the delivery, but I think they are worth suggesting.
Don't get me wrong. I do see a great future for the Prop II. Just that it is no longer way ahead of it's time in many respects.
Am I the only one who feels this way ???
But with the launch comes more Prop II references indicating that we may only get 128KB of hub memory. While external SDRAM will gain some hardware support, it cannot be used as program memory (or not at least without some of the things we do on the Prop I currently).
I was already disappointed with...
* Only 8 cogs
* No cog ram beyond 2KB, banked or otherwise (the fifo access has not been detailed so we don't know how much of this we can use and how)
* I thought at least one cog could/should be a super cog (more cog ram, perhaps hub access when other cogs do not require it)
* No internal EEPROM/Flash (although internal ROM code may mean we can avoid a chip if we have an SD/uSD card)
We certainly seem to have all the features we require on the I/O, including plenty of them (I don't want hundreds like on FPGAs). And we know the counters have had a major revamp and will include lots of new features.
However, in this age, you only have to look around at other chips to see that 128KB is a very small offering on other micros. Five years ago when the Prop I was released, 32KB was almost unheard of. But things have changed.
I for one was looking for a minimum of 256KB and hoping madly that 384KB or 512KB would be achieved. Sadly, I fear this will not be the case.
Parallax is making a fully fledged attempt to play with the big boys.
IMHO Parallax needs to see what other foundries can offer.
Some alternatives for hub sram...
* (Firstly, remember cogs can access hub at 128 bits wide.)
- Can SDRAM be used for hub ???
- Smaller transistor count per cell
- Use hardware/software for refresh
- Maybe steal a hub cycle from cog 7 as required
- Can a mix of SRAM and SDRAM be used for hub ???
- Can the die size be increased for the proposed chip size ???
I also note they are achieving much lower power consumption. What are they doing to achieve this?
I fear these options would have a huge impact on the delivery, but I think they are worth suggesting.
Don't get me wrong. I do see a great future for the Prop II. Just that it is no longer way ahead of it's time in many respects.
Am I the only one who feels this way ???
Comments
It usually comes down to $$$. If it were possible to
fab millions of Prop2's at a time then probably more
features could be added on or different processes used
to create an even more desirable uC. I'm sure that the
fab price would come down with really huge volumes.
But it would take many millions of dollars of venture capitol
to play that large.
I'd really like to be able to boot from SD and sometimes avoid an
external eeprom chip. I'd love 8kb of cog ram...I could sure
stuff a lot of PASM in there, yippee. 8 cogs is enough for
now. 256k hub would be sweeet. Code protection is not that
big a deal to anyone that realizes her code can be stolen by
the unscrupulous regardless of this barrier. 160MIPS/cog is
great but 400Mips/cog would be even better. If it were only
possible to have a teensy bit of flash or eeprom internally and
not always depend on an external chip or SD that would be sooo
nice. But I'm always told the fab process used on the prop can't
handle flash or eeprom :-(
Macro assembler
A GCC compiler supported by the IDE
A simulator in the IDE
A bit of code generation in the IDE
Partnering with a Chinese board house and
offering special pricing on boards with a prop2
already mounted and a large part of the board
custom designed by the user would be nice.
It would also be nice to offer reasonably priced
cases for these boards with and without touch screens.
Be especially nice if the IDE could generate gerbers
for creating these custom pc boards. (I know that's too much to ask)
I do think that Parallax should have gone for a denser process, though, which would have enabled them to incorporate more memory. The aforementioned competitor uses a 65 nm process for their more recent devices. They will probably be using 40 nm for the devices they will be shipping when the Prop II comes out, which will enable them to offer a lot more speed (my guess is 1000 MIPS per core) and memory.
The lack of on-chip debugging will be a turn-off for a lot of professional users.
I would like to see more HUB RAM too, but 128KB is not unreasonable. Just a little more like 160KB would be nice. Of course we all want more COG memory, but that won't happen now - unless you want to wait 10 more years.
Having quad-long transfers will be very helpful for using SDRAM or others with a HUB cache. With quad-long, 4 longs can be read from SDRAM and written to HUB per cycle - very fast, and very good for caching.
It is too bad an SPWRR scheme like in ATM networks can not be used for COG access. WRR is weighted round robin. SP is strict priority. Essentially, a COG would subscribe to a certain amount of band-width. Whatever is left would be the round-robin access. So one would get a QOS quality of service based on the COG need rather than a general scheduler. SPWRR was the hardest hardware design I ever had to grasp, so i don't really expect something like that to be put into silicon for a microcontroller. Still it would be cool to have COG bandwidth on demand.
Prop2 will offer lots of nice stuff. Let's not derail it now - it's so close now one can hear the train.
So for me, the combination of more pins (enabling external memory), built in DAC (reducing pins required for VGA), and faster processor will dramatically improve the graphics capabilities.
Also, the hardware multiply will finally allow for MP3 decode in real time.
Also, we're supposed to get direct USB connections...
Yes, even 50c Microcontrollers offer that, so leaving it off WILL be costly, especially on a device that users will take a little getting used to.
Silicon costs of Debug is not large, and if it can also be used for Chip Testing, it can come at below zero cost.
(ie the testing time saved, more than pays for the small area cost )
This is a very enticing idea. However I have a feeling it would not be so cool in the end.
Let's say I create some PASM driver "heaterGizmo" that requires the max bandwidth to HUB in order to function.
You the create a "jazzedGizmo" that also has high bandwidth requirements.
We post these to OBEX.
Now a user comes along with a project idea that could use both heaterGizmo and jazzedGizmo.
He downloads both from OBEX and builds his project.
Ooops it does not work, there just is not enough HUB bandwidth available for both. Not cool.
Currently with strict round robin access this cannot happen. One can mix and match anything safe in the knowledge that the timing of one will not upset the timing of another. As soon as you give a little extra to any COG you break that safety.
Of course keeping to strict round robin access does mean that some tasks just cannot be done. Even though in theory there is enough bandwidth to HUB if you could borrow some from other COGS.
It's a tough call in my mind, ensure all COG are equal and thus limit what a single COG can do vs allow the absolute max performance for a COG but destroy the timing guarantees for the entire device. I'm inclined to go with the former option.
* It adds layers, and thus cost, to any chip that uses NV Memory.
* The NV speeds are not great, nor do they scale Vcc well at all.
Analog Devices pulled their FLASH DSP families some years back, and the trends show they were right.
uC/DSC still are rare over 100MHz, and very rare over 150MHz, whilst ADI's RAM based DSPs are over 500MHz, and some have over 5Mb of fast RAM.
Typical recent press release :
http://www.analog.com/en/press-release/4_7_10_ADI_Extends_High_Performance_Low_Power_Floa/press.html
These are sub $10, in TQFP packages, 266MHz+, 375KB SRAM.
Certainly Prop II should consider Asymmetric Splits. That's only a little harder than a simple cut and paste, but it much better suits end use. Toolboxes never contain all one size spanner
NXP have announced an Asymmetric Dual core, and Freescale have offered IO processing for a long time.
RAM Size is always going to be a problem, an dyes. MORE is always better, but the more important detail, is what happens above this ?
Atmel's FpSLIC had a hard RAM ceiling, that was low, and it sunk without trace.
My thinking here, is to support Multiple QuadSPI memory, _and_ include the hardware to memory-map this.
Then, users can put fast code into SRAM, as needed, and use QuadSPI(s) as needed, for serious code elasticity.
4 or maybe even 8 qSPI devices, would give quite reasonable off-bandwidth.
If SRAM load included a simple mapping scheme, and HW streaming burst read, then re-loads become free user choice, and the system behaves like a scaled PC RAM+DISK : On chip RAM for raw speed, and qSPI for NV IO.
Cypress I think have NV Sram, in QuadSPI close to release. That solves a write-delay issue, otherwise, you allocate one qSPI device for Data, and other(s) for Code. (NVSram will always have a premium price).
Certainly determinism is vitally important, but there is room for a little flexibility perhaps ?
Could users take the hard slots allocated to all COGs and then decide to double allocate to one, and thus disable another ?
HW is relatively simple, and there may be limits. I'd expect slot-spreading would matter, so adjacent slots may be not supported.
Now, they have the same determinism, but one process gets double the slots. I think some cores already allow this.
BUT, IMHO 128KB is not going to be nearly enough for lots of things. I see that as being one major inhibitor nowadays and it will only get worse as we find other things to do on Prop II.
I am not looking for a half baked compromise here... I want the real thing for the next 5-10 years! I have waited 3 years now, whats another to get it right???
Postedit: I am not after other changes although some would be real nice. That discussion is over, and I am sorry I mentioned them. I was just sooo disappointed that it is looking more like 128KB hub ram. I guess I am saying I am prepared to wait until I can have 256KB min and preferably 512KB - and it can cost more. So is there another way to get more???
I work in the semi industry, and i believe the root of the Prop's limitations is the design methodologies used.
That is, full custom, down to the transitor, has been the mantra a Parallax as best i can tell.
That is not how chips are done these days. A "hardware Description Language" (HDL) is used to define the design and a foundry specific library is used in the synthesis of the design. The physical design would be out sourced to a company or the foundr's design center and Parallax would focus on verification vectors.
This would be the only way a company the size of Parallax would be able to get a Prop out in less than a year and have features like on-chip flash.
I am thinking that Parallax is a great company for hobby and niche products. Reduce your expectations and have fund with what they have.
rich
IMHO I don't think we have even begun to scratch the surface of what the current prop can do. I guess I say that because if one has a certain task that needs to be done, one can either ask whether it needs a new chip or whether it can be done with the current chip, or even, whether if a new chip comes out one might find that the barriers to solving the problem are actually still there, and that in solving those problems for the prop II, one then solves them for the prop I as well.
An example might be writing big programs. The prop II comes out with x amount of ram. And the only program that can use this ram turns out to be Catalina C. Both Prop Basic and Spin (and other programs) need to be rewritten to support this higher ram. And when that is done, the solution then works for the prop I as well.
I have a feeling that Big Spin and Big Basic are entirely possible on the current propeller using a variety of external memory solutions. But for whatever reason, the code does not exist. Only Catalina (and LMM assembly) can write programs as big as you like.
So we can either wait for the prop II to come out and then find it doesn't solve all our problems, or we can do the hard work and solve those problems using hardware that does exist.
As an aside, I'm writing a Big C program and have already gone over 128k, and at the current rate might go over 512k and have to move from the dracblade to the "jazzedblade" and so the Prop II is not going to help me much here. What helps far more is the brilliant work done by RossH and Jazzed and all the others who have contributed to the vast library of code all available for free in the Obex.
Who is the target audience? Those who might want to replicate the Basic Stamp have Propbasic and it is a perfect solution with more than enough memory.
Those of us pushing the boundaries of big programs have the prop I with a myriad of external memory solutions already and so may not need a Prop II with heaps of internal memory.
Who then needs lots of internal memory?
One group might be the gamers and for 640x480x256 colors, we need more than 128k. But Baggers et al are exploring some fascinating solutions using synchronised props, and I suspect there might be even more solutions using multiple synchronised props plus external ram.
If a solution like that works, then it may well be possible to port it over to the prop II using a fast ram chip and multiple pins.
I guess at the end of this long post I'm just repeating what Rayman said in post #8 - if you have more pins you can do so much more with external ram AND have enough pins left over for all the other USB etc etc.
I think collectively we will be able to push the Prop II to do far more than we can even envisage now.
And I also think that we can push the Prop I further as well.
Back to coding. I'm doing some research on Windows v 1.0 and the chips it ran on and the graphics it used, as I believe that if we can replicate a 1980 CP/M machine on the prop I, I think we might be able to push that out to 1985 for a GUI.
Also the "provided' development tools need to keep pace with industry expectations as well, though this is more for the new professional image that is being promoted.
Opportunity for clarification has arrived.
Rich, the design methodology was a limitation for achieving the Propeller 1, but we've now ported the Propeller 2 (may be only a code name for now) design to HDL and we are working with a design center who will run the synthesis so we can fabricate the die. You know more about this than I, but my understanding is that we can skip the lengthy schematic layout process. Our focus will become testing, characterization and tools. The end result, and our goal, is to be able to release chips more frequently than once every five years. This is a business necessity.
Given the R&D expenditures, fixed cost of shuttle runs and testing setup, it isn't likely to create a positive net income from hobby and niche products alone. Volume sales can't be just a desire or side-effect, but must be a focus of Parallax Semiconductor.
Ken Gracey
My BigSpin effort is on hold until after UPEW. Someone else is developing "BigBasic" right now.
SpinSocket-Flash which will have up to 4MB on a 10 pin interface will run "BigBasic" and other X languages.
RE: jazzedblade - funny name. Make a BattyBlade that uses only 14 pins for SDRAM. Here's a reference schematic if you want to try something. It's not tested yet - i haven't had time or funds allocated to build the board. This design was suggested by Ding-Batty in the thread Adding 32MB SDRAM ....
John Abshier
I totally agree with this, we haven't reached the limits of Propeller yet and I bet if there was a Propeller with more than 32 I/O then the clamour for Prop 2 would lessen dramatically.
I use the Prop in two ways, for my commercial applications I use it as a micro-controller, I don't try to push beyond it's boundaries it is not worth the risk.
Sure I could use a cheaper device but then I wouldn't get the same flexibility that the Prop gives me, this in my opinion is it's greatest strength.
For my own personal projects I use it totally differently, I want to push it as far as I can and I know we haven't reached the limits yet, nowhere near.
Be happy with what we have and make the most of it now! :thumb:
Coley
-Phil
Business suit just arrived - need to make our pitch every opportunity that exists. ARM Holdings revenue was £406 million during Q4 2010, approximately 270x that of Parallax and Parallax Semiconductor combined. With this kind of volume they can choose the most dense process and obtain the lowest fabrication and packaging costs. We won't be able to compete in terms of price, perhaps ever. I think that by company size Parallax Semiconductor has delivered an unusually high benefit to the customer.
Our pitch is quick prototype to production, personalized support (contact one of our FAEs), supply stability and a unique architecture. Our volume customers are in the 1K-100K unit range and are likely entrepreneurs or creators of new technology. These customers find benefits in our shorter development cycles and support in exchange for a slightly higher cost. Some of them really like the tools and the find our Propeller a pleasure to program. The largest customers using Propeller 1 are in newer designs and were not replacing any AVRs, PICs or ARM chips. The designs are all fairly new, too. Strangely, none of our high-volume apps are display or gaming-oriented. They're all using the Propeller in ways that a general-purpose microcontroller would have caused a single-threaded, interrupt-driven programming disaster. And aside from a RAM shortage they're often left with resources to spare.
Development tools - two concurrent efforts are under consideration right now. One of them is a GCC approach for Propeller 2. We're regularly collecting the R&D team up with the FAEs to discuss the plan and preparing to act. Before we go too far we will consult with all of you.
Thank you,.
Ken Gracey
- I hope - It still will have Spin. BUT to all types pf programing. Prop II need have 2 Start modes after programing.
One that start as Propeller I now - Spin and other Starting directly in Assembler (machine code) mode.
Personally, I'd like to see the next chip powerful enough to support a basic browser and email. Frankly, if I could do internet communication and spin programming on the Propeller, I'd have very little use for a PC. As a PC service technician by day, I know that if folks had an inexpensive way to hook to the internet and do email without the potential for Viruses/Spyware/Malware and the like, money would change hands. I'm not sure the next chip have the power to fulfill this role, but even close may be enough for me. I'm sick of power hungry, windows, PCs.
The Propeller has always suffered from being a great product looking for it's amazing application. The creation of Parallax Semiconductor is a giant step in the correct direction.
OBC
That is: will I be able to compile C programs with GCC that will run on Propeller 2?
If so, this is perfect
-Phil
For propforth, prop 1 continues to be overkill. The software is still catching up to the hardware. As with any design, the software simply has to work within the constraints of the hardware. The assembler and debuggers have done the job so far, such that on-chip debugging hardware would only add a small advantage. Software logic analyzer makes it difficult to justify a purchgasing a physical logic analyzer. Multi-prop support allows adding cogs and pins as desired. SD support is targeted to allow unlimited (re)extension of the dictionary on the fly. I wouldn't say the Prop 2 is too much too soon, but definitely not too little too late. I would say prop 1 software evolution takes time because its different, there are simply fewer people thinking in those terms.
Compare to this $10 16bitmcu that only have 16KB of RAM and 256KB of slow write flash.
http://www.mouser.com/ProductDetail/Texas-Instruments/MSP430BT5190IPZ/?qs=HM7Ob9npyBIfx1AMhraHNQ%3d%3d
I guess you have to compromise somewhere.