Practical 2 Cog MiniProp ?
pjv
Posts: 1,903
Hi All;
While at UPEW expo I had an opportunity to chat with Chip about a smaller prop... something to take over from the SX. This request was driven by a potential project I may get involving just under a half million units. For that potential application the SX would have been a reasonable answer, but the Prop 1 is too costly, and has considerably more capability than I need. So how about a smaller "MiniProp" as has been suggested here and there in the forums. I wondered about the practicality of 4 cogs, but he said that would not make enough of a difference. To get twice as many dies on a wafer,·a reduction·to 2 cogs could work rather nicely by folding the layout around. In pressing a little farther and asking if that could be "in the cards", his response was that it would take very little of his time, and not much total time,·and that it could be done after Prop1 revB were finished.... the impression I got was "soon". It would·require different (external?)·staff than is being used on the Prop 2, so almost no impact on that delivery.
I cannot recall now what the MiniProp I/O complement was as that was not an important issue for me in this project, but I do recall that the price could be well less than half the current Prop.... perhaps even less than $3.00
I also asked about implementing some OTP fuses, but that seemed to be more difficult, and faster delivery would dictate fewer changes.
For me·a 2 cog MiniProp·would be a great replacement for the SX as my needs are very low power consumption...... 3 years on a pair of D cells while still doing significant work. As far as cogs is concerned, one really can get a ton of work done in even a single cog using multithreading......
Sure, I'm aware that the new TI (430?) series·could do this perfectly for less than two dollars, but I dont want to learn yet another architecture. I'm comfortable here, and prefer to stay with Parallax with their great attitude and great support.
I really hope this flies, and soon!
Cheers,
Peter (pjv)
Post Edited (pjv) : 7/2/2010 3:40:36 AM GMT
While at UPEW expo I had an opportunity to chat with Chip about a smaller prop... something to take over from the SX. This request was driven by a potential project I may get involving just under a half million units. For that potential application the SX would have been a reasonable answer, but the Prop 1 is too costly, and has considerably more capability than I need. So how about a smaller "MiniProp" as has been suggested here and there in the forums. I wondered about the practicality of 4 cogs, but he said that would not make enough of a difference. To get twice as many dies on a wafer,·a reduction·to 2 cogs could work rather nicely by folding the layout around. In pressing a little farther and asking if that could be "in the cards", his response was that it would take very little of his time, and not much total time,·and that it could be done after Prop1 revB were finished.... the impression I got was "soon". It would·require different (external?)·staff than is being used on the Prop 2, so almost no impact on that delivery.
I cannot recall now what the MiniProp I/O complement was as that was not an important issue for me in this project, but I do recall that the price could be well less than half the current Prop.... perhaps even less than $3.00
I also asked about implementing some OTP fuses, but that seemed to be more difficult, and faster delivery would dictate fewer changes.
For me·a 2 cog MiniProp·would be a great replacement for the SX as my needs are very low power consumption...... 3 years on a pair of D cells while still doing significant work. As far as cogs is concerned, one really can get a ton of work done in even a single cog using multithreading......
Sure, I'm aware that the new TI (430?) series·could do this perfectly for less than two dollars, but I dont want to learn yet another architecture. I'm comfortable here, and prefer to stay with Parallax with their great attitude and great support.
I really hope this flies, and soon!
Cheers,
Peter (pjv)
Post Edited (pjv) : 7/2/2010 3:40:36 AM GMT
Comments
-Phil
Moving to Spin for ease of programming and more code space is going to give you 10 fold less equivalent MIPs.
Using LMM for bigger code space helps but you still end up with basically a very slow micro-controller.
Further a two COG prop can be almost viewed as a one normal CPU with one interrupt source/handler. Whatever code you put there could just as well be done with one normal processor and an interrupt handler. It would probably be just as easy and speedy given the limitations described.
I'm not sure I get the point of a 2 COG Prop unless your app really can fit in there and you are willing to pony up for an order of half a million units.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/30/2010 5:22:12 PM GMT
@ Phil.... you are selling the Prop short! The I/O and application can all be readily done in a single cog.... that is full duplex serial at 115,200, I2C/SPI, buttons and LCD display plus application code all written in multithreaded assembly. Video is not normally required, but then there is always that second cog.
Cheers,
Peter (pjv)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 6/30/2010 5:49:55 PM GMT
Or at least 3...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Is that really true? I'm not about to start sizing this up but its seems a lot to fit into a single COGs 496 instruction space.
If it fits at all, with all the polling going on to make it work and the overhead of a thread scheduler, can it really hit 115200 baud.
Again if you are going to it that way it can all be done with many other micros.
I still don't see what is in it for Parallax to make such a thing unless there is a big order on the table.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I vote yay on MiniProp!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!
Some of my objects:
MCP3X0X ADC Driver - Programmable Schmitt inputs, frequency reading, and more!
Simple Propeller-based Database - Making life easier and more readable for all your EEPROM storage needs.
String Manipulation Library - Don't allow strings to be the bane of the Propeller, bend them to your will!
Fast Inter-Propeller Comm - Fast communication between two propellers (1.37MB/s @100MHz)!
I went on to other things... but as cool as the Prop is.... and as FANTASTIC as the new prop will be... there are going to remain applications where the absolute component bottom line will determine what chip runs it.
These ARE the apps where the volume WILL be in the multi-thousand unit quantities, so if Chip could "Saw the Prop in half"... I think this "Glider" might easily take wing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "
··············································· ( R.A.H. )
····································
I'm certain the previous extra baggage of the Prop will still be required.
Cheers,
Peter (pjv)
If price isn't the main concern, you could make an 8 I/O Prop in a DIP-24 package if you wanted, as shown in the attached.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andrew Williams
WBA Consulting
PowerTwig Dual Output Power Supply Module
My Prop projects: Reverse Geo-Cache Box, Custom Metronome, Micro Plunge Logger
Not to mention its·use as a natural upgrade path for the Basic Stamp line.
In my wild fantasies, the perfect MiniProp would be:
- 4 COGs
- P0..P15 and P28..P31 with same pinout as ports B, C and A in SX28
- other pins available for internal COG to COG use
- 16KB of HUB RAM (maybe mirrored 2 times?)
- 32KB of ROM, same as current P8X32
- Same 16-cycle/8-tap hub access, but with 4 different access modes for COGs:
Don't know if that last two HUB modes are really feasible, but if so they could allow a consistent speedup for 8-bit VMs like SPIN and Zog, thus recovering on the code density side too.
Also, even with fewer RAM·and·I/O pins·it would still be great as video co-processor for other MCUs.
Maybe even better than the P8X32... Arduino users would not be scared anymore by "the other processor" on the shield being bigger than the main one
Regards
Alessandro
But only 2 Cogs would really limit the possible applications. Every video driver needs a full cog and also a fast PWM or SPI.
An unconvential configuration to half the silicon space:
- 3 Cogs
- 20..24 kB HubRAM
- ROM without characterset and tables
- Only 15..16 I/Os (20 Pin package with 15 IOs, Vdd,Gnd, XI,XO, Res)
The nice thing with 2 cogs: The Hub speed is the same as the execution speed of native PASM ! So LMM is nearly as fast as PASM in the cog.
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!
Some of my objects:
MCP3X0X ADC Driver - Programmable Schmitt inputs, frequency reading, and more!
Simple Propeller-based Database - Making life easier and more readable for all your EEPROM storage needs.
String Manipulation Library - Don't allow strings to be the bane of the Propeller, bend them to your will!
Fast Inter-Propeller Comm - Fast communication between two propellers (1.37MB/s @100MHz)!
Heck, we could do that now! 'Got a hacksaw?
Seriously, though, depending on where the die ends, you'd just be cutting through the leadframe and some plastic.
-Phil
I'm going to add msp430 skills to my bag of tricks soon.
(soon as my books and 3 of those cute 4$ demo boards get here)
Of the uC's I play with I prefer the propeller...wish it was what I got
to program at work.
I have not tried any PIC's since I programmed the 16F84 a long time ago.
Maybe the new ones are not quite as silly as the old bank switch 8bit devices were.
That poor little tired W register in the PIC...LoL MOVLW, CLRW, RETLW,
ANDLW, ...etc...etc
The new Prop2 will be great.
It would be nice if they partnered with some cheap Chinese board house
to provide low cost custom boards with the new prop already soldered down.
So those frightened by the prospect of soldering a large sm prop could stay
in the game. Sparkfun has some kind of deal with a cheap board house, I have never
used it though.
Having just 2 COGs is not completely unreasonable for small applications.
I have a hard time giving up the HUB RAM especially with LMM requiring almost 4x space as SPIN.
DIP20-24 (skinny-dips) or TSOP28 are nice packages for small control applications.
Fooling around with some DIP package ideas: DIP 20 (Internal Clock) ++_++ P0 --| |-- 3.3V P1 --| |-- P31 P2 --| |-- P30 P3 --| |-- P29 P4 --| |-- P28 P5 --| |-- P27 P6 --| |-- P26 P7 --| |-- P25 P8 --| |-- P24 GND--| |-- RST +---+ DIP 22 (external clock / BOE) ++_++ P0 --| |-- 3.3V P1 --| |-- P31 P2 --| |-- P30 P3 --| |-- P29 P4 --| |-- P28 P5 --| |-- P27 P6 --| |-- P26 P7 --| |-- P25 P8 --| |-- P24 BOE--| |-- XIN GND--| |-- RST +---+ DIP 24 (Prop IO 16) ++_++ P0 --| |-- 3.3V P1 --| |-- P31 P2 --| |-- P30 P3 --| |-- P29 P4 --| |-- P28 P5 --| |-- P27 P6 --| |-- P26 P7 --| |-- P25 P8 --| |-- P24 P9 --| |-- XOUT BOE--| |-- XIN GND--| |-- RST +---+There are JEDEC pinout alternatives, but does that help?
Also, would it make sense to have a Stamp footprint?
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
@pjv: For a smaller chip, I am presuming for that volume it would be smt. Yes, others would like it in a DIP format and that could be possible. If you are certain of the quantity then I suggest you chat offline with Ken (if you haven't already). I am not sure of the economies of scale, but it could be possible for Parallax to approach something close in price for that volume with the existing Prop.
Here is another suggestion... Could your code be frozen? If you are certain your code could be frozen, for 500K parts, it could be worth·changing the ROM code for you using the existing Prop. This would save you the EEPROM cost and with the price discount for that quantity perhaps you may achieve your objective total price. By dropping the ROM code for the bitmap (and the sin tables, etc) and a subtle change to the ROM booter code, and place your code in ROM.·The booter could test a pin (say·P28 (SCL) - you pull it·low via 10K) and if low it would use your new ROM boot code instead of looking for serial download or EEPROM. This way, the EEPROM would be optional, so you would save its cost. Perhaps there could be an advantage here for Parallax by providing an SD boot code also. I have some ideas for this.
@all: I was about to say that IMHO a 2 cog prop would be a waste. It would just not have enough grunt to do much. However, thinking a bit more I came to the following advantages...
*·Hub access time could decrease. Could it be done in 4 cycles or would it be 8 due to the·read/write instruction?
* Could the cogs be forced to be out of step·by 2 cycles?
* Both the above could mean the hub contention could be removed and read/write could take the normal 4 cycles? (no wait delays)
* If so, then LMM would be much faster
* If so,·SPIN would be a bit faster
Now thinking a little further...
The rom code for the character bitmap would now be useless, so the Interpreter could use my decoding as the decode table could be in rom. Also, the Interpreter could be unravelled because of extra space. This could give a nice improvement in speed. The rom booter could look for P28 being pulled-down (low). If low, there is no EEPROM and therefore do something like the SX did. (I have not looked at what the SX did).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
With half a million units, there must be some economies of scale. The same reason a small tyre for my ride-on mower costs three times the price of a much bigger tyre for a car. Making more of one thing can be cheaper than making smaller amounts of lots of different things. Even when the design might mean more than half the cogs are not being used.
Maybe only parallax can answer this, but if they sold half a million more units, could the price come down to $3?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I appreciate all the comments and advice.
My understanding is that the target price I am looking for just can't be met with Prop 1 because of its size; there just are not enough chips on a wafer. And the geometry remaining by cutting the cogs to 4 does not release enough area. That's when Chip thought 2 might work to get somewhere near twice as many dies on one wafer, and "would not be too hard to do".
Also, I'm not sure how simple the suggestions for architectural modifications are to implement..... obviously the more changes, the more effort, and room for gremlins, hence time, cost etc. I'd be happy with just 2 cogs as an SX successor.
There are also issues with my business case to be considered. Delivery would be spread over four or so years, not just a single order. The early deliveries need to finance the later deliveries, otherwise too much working capital is required. And besides 400K units over four years is still 100K per year, or 400 units per day. That will already stretch my shop's capacity, and some investment in manufacturing facilities and staff will need to be made.
I realize there are other processors and methods to satisfy this potential project, but if I'm successful in landing it, I'm hoping that it could be the catalyst for creating this MiniProp..... it would be such fun.
Cheers,
Peter (pjv)
That would be great, even if the price wasn't super low.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]
However, like you, it would be good to ditch the eeprom. I am thinking there would be other stuff we could put into the space currently occupied by the rom font. You are the very person who might be able to guide what is required for an SX Prop 2 cog replacement (PropBasic??). (see my rom font thread) http://forums.parallax.com/showthread.php?p=919656
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I know that the eeprom cannot be manufactured on the propeller die. I'm talking about two die in one package.
If anything should be in the ROM, I would vote for either femtoBasic (or similar embedded BASIC) with a serial interface.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]
As chip geometries decrease over time·there will be an opportunity to respin the Prop I in a smaller geometry, which will produce a smaller die size.· At that point it may be feasible to package a version of the Prop I in smaller surface mount and DIP packages that don't provide all 32 I/O pins, but I wouldn't count on it.· At the very least, the smaller die size will allow for a lower price with the current package pinouts.
The proposed features of the Prop II are really exciting.· With single-cycle multipliers, A/Ds and an interface to DDR memory it could compete in a very interesting video graphics and DSP market.· I could see a lot of applications for it.· However, it will need to execute C code and other high-level languages efficiently to be accepted in this market segment.· Spin is too slow, and professional graphics programmers aren't going to expend the effort to port their existing code to it.· This will require efficient LMM execution, or highly expanded bank-switched cog memories.
Dave
As has been discussed before, if you reduce the size of the features on the chip (to reduce the die size), the leakage current increases. The minimum operating current rises even though the total operating current for the whole chip (per MHz) will drop (for the same number of gates). That was one of the tradeoffs in producing the Prop II. The total operating current would not be orders of magnitude more than the current for the Prop I despite the much higher speed and number of gates, but the quiescent current would be a lot higher. Making a Prop I with the same process and feature size as the Prop II would result in a much smaller die, but the chip would be unsuitable for really low power battery powered applications.
That is obviously more complicated than just doing a waitpeq, but it might be a solution for applications that need low standby power.· Maybe a respun Prop I could include circuitry to help control external power management chips.· The respun Prop I would have to support a very low operating voltage.· I don't know if that's feasible or not.· It may require isolating the I/O pins so they can withstand higher logic levels when the chip is in a low voltage mode.