Propeller, gen.2 info - rev: 20 Oct.2007
Feature Quantity comments Forum pg/date/time
--------------+-------------------+-----------------------------------+------------------
Cogs 16 v 160 MHz, pipelined instr./clock pg1/25Nov06/12:32a
(2 clocks for Hub instr); pg1/25Jun06/12:52a
512 longs/cog; w/full speed Hub pg7/30Nov06/12:39p
pg17/24May07/11:12a
wide data path fetching pg19/28Jun07/9:26a
8 contiguous long accesses/hub R/W pg20/4Jul07/7:18p
--------------+-------------------+-----------------------------------+------------------
Memory RAM 256KB v on-chip pg17/24May07/11:12a
pg20/4Jul07/8:36p
ROM 128K v include entire development system pg20/4Jul07/7:18p
(no need for PC!) pg20/4Jul07/11:40p
--------------+-------------------+-----------------------------------+------------------
I/Os 64 v pg17/24May07/12:50p
INB, OUTB not same as INA, OUTA pg21/5Jul07/11:08a
--------------+-------------------+-----------------------------------+------------------
Clock input min - max freq ?
--------------+-------------------+-----------------------------------+------------------
PLL speed 160 MHz max ?
--------------+-------------------+-----------------------------------+------------------
Packaging QFP preferred pg19/19Jun07/6:03p
QFN ?
LQFP ?
BGA ?
(NO thru-hole DIP) v DIP package would be too large p23/27Aug07/3:23p
--------------+-------------------+-----------------------------------+------------------
Other pins 3.3v (I/O) 4 ? 64 I/Os plus these totals 80 pins pg2/25Nov06/11:26a
1.8v (I/O) 4 ? pg23/27Aug07/3:23p
Gnd 4 ?
Reset 1
BOE 1 ?
Clock 2
--------------+-------------------+-----------------------------------+------------------
16x16 multiply 1 v pg19/23Jun07/3:59p
--------------+-------------------+-----------------------------------+------------------
Dev Sys onchip (see Memory above) in ROM pg20/4Jul07/11:40p
--------------+-------------------+-----------------------------------+------------------
Availability probably a year away p3/25Nov06/1:10p
2 yrs, conservative pg5/7Mar07/12:00p
between 1 - 2 years pg15/7Mar07/12:08p
--------------+-------------------+-----------------------------------+------------------
Longevity most likely for pg8/5Dec06/6:01a
next 15-20 years
--------------+-------------------+-----------------------------------+------------------
'code name' P-Chip 2 p15/7Mar07/12:08p
P16X32 v means 16 cogs, 32-bit width p24/30Aug07/10:33a
--------------+-------------------+-----------------------------------+------------------
Beau Schwabe - IC layout engineer, Parallax pg15/7Mar07/9:53p
legend: '?' = not yet defined by Parallax; 'v' = mentioned by Parallax (Chip, Paul)
Apologies to the editor's baaad formatting. Created on Mac using Monaco, .
9pt and spaces to format; but monospacing not retained
@ Forum moderator, the previous lists, pg19/28Jun07/3:56p and pg21/8Jul07/4:35p could be deleted
Sheesh!?!?!?! What a stupid editor! Looks different even after a 'SUBMIT'!
Propeller, gen.2 info - rev: 20 Oct.2007
Feature Quantity comments Forum pg/date/time
--------------+-------------------+-----------------------------------+------------------
Cogs 16 v 160 MHz, pipelined instr./clock pg1/25Nov06/12:32a
(2 clocks for Hub instr); pg1/25Jun06/12:52a
512 longs/cog; w/full speed Hub pg7/30Nov06/12:39p
pg17/24May07/11:12a
wide data path fetching pg19/28Jun07/9:26a
8 contiguous long accesses/hub R/W pg20/4Jul07/7:18p
--------------+-------------------+-----------------------------------+------------------
Memory RAM 256KB v on-chip pg17/24May07/11:12a
pg20/4Jul07/8:36p
ROM 128K v include entire development system pg20/4Jul07/7:18p
(no need for PC!) pg20/4Jul07/11:40p
--------------+-------------------+-----------------------------------+------------------
16x16 multiply 1 v pg19/23Jun07/3:59p
--------------+-------------------+-----------------------------------+------------------
Clock input min - max freq ?
--------------+-------------------+-----------------------------------+------------------
PLL speed 160 MHz max ?
--------------+-------------------+-----------------------------------+------------------
I/Os 64 v pg17/24May07/12:50p
INB, OUTB not same as INA, OUTA pg21/5Jul07/11:08a
--------------+-------------------+-----------------------------------+------------------
Other pins 3.3v (I/O) 4 ? 64 I/Os plus these totals 80 pins pg2/25Nov06/11:26a
1.8v (I/O) 4 ? pg23/27Aug07/3:23p
Gnd 4 ?
Reset 1
BOE 1 ?
Clock 2
--------------+-------------------+-----------------------------------+------------------
Packaging QFP preferred pg19/19Jun07/6:03p
QFN ?
LQFP ?
BGA ?
(NO thru-hole DIP) v DIP package would be too large pg23/27Aug07/3:23p
--------------+-------------------+-----------------------------------+------------------
Dev Sys onchip (see Memory above) in ROM pg20/4Jul07/11:40p
--------------+-------------------+-----------------------------------+------------------
Availability probably a year away pg3/25Nov06/1:10p
2 yrs, conservative pg5/7Mar07/12:00p
between 1 - 2 years pg15/7Mar07/12:08p
--------------+-------------------+-----------------------------------+------------------
Longevity most likely for pg8/5Dec06/6:01a
next 15-20 years
--------------+-------------------+-----------------------------------+------------------
'code name' P-Chip 2 pg15/7Mar07/12:08p
P16X32 v means 16 cogs, 32-bit width pg24/30Aug07/10:33a
--------------+-------------------+-----------------------------------+------------------
Beau Schwabe - IC layout engineer, Parallax pg15/7Mar07/9:53p
legend: '?' = not yet defined by Parallax; 'v' = mentioned by Parallax (Chip, Paul)
pg = page number of reference in this thread.
Where's the improvement? When displayed. it ultimately is not the same as viewed while editing.
My variant displays correctly in your browser I hope? I didn't spend much time on it - just used my default text editor with it's default fixed width font and deleted the extra spaces where I thought was best.
Looking at my table on the Mac, it is messed up more than I see today on the PC laptop. The latter is a bit nicer on my table. Evanh's is about the way it should appear.
Looks like I should create tables for the forum on the PC instead. Hate incompatibilities. They're getting better and better between Macs and PCs. Probably partly or wholly due to the older browser on the Mac. (Mac is my main machine guys)
I know the MAC has some plan ASCII editors. (If I were in front of one right now, I would just go and locate it.) Some fonts are mixed. Spaces will consume less character space, while chars are largely non-proportional. A quick copy paste of some test text should ferret this out. Build something simple, like:
I'm pretty sure the "Terminal" font is non-proportional. Won't look all that nice, but will render correctly in the code tags here. The Bitstream Vera TTF has a really pretty great non-proportional font in it, that will render nicely on the MAC.
Browser problems like that arise from badly specified web page styles that have one mono-spaced font as the first font entry in the style. But all the fallbacks are proportional. So, if you don't have that very font you get a messed up web page.
The dirty fix is to rename a copy of a mono-spaced font to that which is specified. The common one that gets used on webpages these days is one from M$ Office called Lucida Console.
Yes, and add an AHB and DMA and VIC and 512K Flash etc and shave $5 off the unit price (beer money) and your supervisors will be happy in their little ARMish community with all their buggy contraptions (silicon errata). But it wouldn't be a Propeller any longer, will it? You could call it a Crutch I suppose (something that props an arm up). But why limp when you can Spin a Propeller and fly.
1) huge cost of the chip ; 1000 pieces $8.03 not comparable with others for production. (we use 32 - ARMs and 89s51 due to their low cost.)
In Australia I can get (single quantities) a propeller+eeprom+crystal for about $25 from Ron Nollet or an ATMega8535 for about the same price from Jaycar (local electronics store).
2) there is no other version of prop. For example VSCL and VCFG is can be put only one cog. One cog must be able to take interrupts so that it can handle all the small tasks (k.b mouse, bit manupulation, etc). dedicating a 32 bit cog just for k.b is not logical.(my opinion) So that 4 - 5 cog would be enough for parallel processing.
One of the main ideas of the prop is to eliminate interrupts to make programming easier. Many applications could get by with less cogs (say 4) but the cost of the chip would be about the same as the current prop.
3) parallax must assure us about maintaining the production of the prop. at least 5 years.
They have indicated that the prop will be a major item for them and they will continue to make it for as long as possible. The SX chips have been around for a very, very long time now.
Also fixed point multiplication and division instruction would be nice.
There is are instructions set aside for multiplication and signed multiplication and the indication is that these will be implemented in the propII. I don't think that this has been confirmed by parallax though.
1) Can't argue with you on that, but Parallax is small compared with Microchip...
2) It's sometimes hard to change our mindset from needing interrupts, however that's what you MUST do if you're to enjoy the Propeller! With some work, it's still possible to combine some tasks into one COG - I think someone has already combined keyboard and mouse. Whilst at first glance it may seem wasteful to dedicate a 32bit COG to one sensor, think of the massive reduction in development time as a result of not having to worry about interrupts...
3) I'm sure I've seen something from Parallax stating they have every intention of carrying stock of the Propeller for 8 years or more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Seems this thread will never die, but as it's currently 'in defence of the Propeller' ...
1) Chip cost isn't always the only factor. If the overall outcome will not be as competitive or productive as using an alternative then by all means use something else. The Propeller is not a universal panacea and I don't believe anyone has ever claimed it to be.
2) Multiple Cogs bring benefits which can outweigh the lack of interrupts. A single Cog can handle multiple processes / tasks while complex interrupt functionality can often be emulated using multiple Cogs. The Propeller II will have twice as many Cogs.
Some people see the Propeller as potentially difficult being different to what they have previously used. Others see it as a great improvement. Also see the "Why the Propeller Works" sticky.
3) There's no indication Parallax will not produce and support the Propeller for a long time to come, and given the investment put in and support for it from the highest level of Parallax down there's no reason to believe they won't. However no one can truly foresee what the future holds.
Peter Jakacki said...
Yes, and add an AHB and DMA and VIC and 512K Flash etc and shave $5 off the unit price (beer money) and your supervisors will be happy in their little ARMish community with all their buggy contraptions (silicon errata). But it wouldn't be a Propeller any longer, will it? You could call it a Crutch I suppose (something that props an arm up). But why limp when you can Spin a Propeller and fly.
Please Parallax, keep doing what you are doing.
*Peter*
·"in their little ARMish community " the chip you despised accounts % 75 of the 32 bit risc cpu.
·Shortly i dont believe the contradiction with you·will be beneficial.
·you could try to answer with reasons·(and wih respect)·like others. Be sure i want prop to be used extensively (other than hobby) more than you. That is why i wrote the·features industry wants.
· by the way "lord steve"·the post below is not funny..
Post Edited (davran elektronik) : 4/14/2008 9:11:30 PM GMT
The management of your company may find the chip described on this page linked below more suitable to·their stringent business needs.· Be sure to give them all the information.
Truly amazing how quickly things can deteriorate around here.
Entrenched ideas are hard to change, and are often exploited.
April fool's jokes like Xallarap are supposed to be funny.
Human nature ... take it, leave it, ignore it, laugh or cry for it.
Davran, the two "marketing" questions are clearly something that Parallax would want to address - if they can sell a billion chips at $1 profit vs. 100 millions chips at $2 profit, it's clear what they would do! Not in the HW business, but I imagine partially the relative high cost of the Propeller is due to the custom design. I am sure the smart people at Parallax are looking into ways to ramp that down. Keep in mind that while there are talks of PropII, the Propeller is here to stay.
As for the "interrupt please" request. Again, not a HW person, but besides simplifying the programming model, I'd guess that not having to deal with interrupts simplifies the design considerably as well. A COG is just a relatively computational engine now. With interrupts, you have to break the pipeline, provide context save and restore features. All that add to the complexity of the design and potentially more bugs. Lets say a multiple cycle MUL instruction is added. With interrupt, you have to either disable interrupts around it or save and restore intermediate context. With multiple COGs, once you sync up with the HUB timing, things are more deterministic. Even adding a LMM kernel is not that bad - while the determinism is not precise, it is a narrow range with lower and upper bounds. In other words, I don't think this will change, but then again, we are never suppose to see "Intel Inside" a Mac either. That and $700 gets a Core 2 Duo Mac Mini now, so anything is possible.
Anyway, sell your managers on the strength of the Propeller. Don't mention the negatives
...There are 3 main reasons why our supervisors neglected my offer about using prop in a new design;
1) huge cost of the chip ; 1000 pieces $8.03 not comparable with others for production. (we use 32 - ARMs and 89s51 due to their low cost.)
I know that the Propeller chip is expensive, but it's 53 square mm of silicon, which is huge for a microcontroller. It's very compact for what's on it, but it's nonetheless expensive to make. Considering this, economic justification to use it would have to involve either simplicity of development or its special abilities (video, keyboard, mouse, etc.).
2) there is no other version of prop. For example VSCL and VCFG is can be put only one cog. One cog must be able to take interrupts so that it can handle all the small tasks (k.b mouse, bit manupulation, etc). dedicating a 32 bit cog just for k.b is not logical.(my opinion) So that 4 - 5 cog would be enough for parallel processing.
This requires some different thinking to adapt to. It's true that you wouldn't want to dedicate an ARM for a keyboard, but a single COG in the Propeller is not that "expensive", or even wasteful.
3) parallax must assure us about maintaining the production of the prop. at least 5 years.
Parallax plans to make the Propeller for as long as the 0.35um fabrication process remains available. This should be, at least, 15 more years. Our BASIC Stamp has been in continuous production for over 15 years, already.
Also fixed point multiplication and division instruction would be nice.
We'll have multiplication in the next Propeller, but not division. At least, it's not planned right now. A divider is a lot tougher to make work in 4ns than a multiplier is.
i hope parallax takes into account the feedbacks.
We do take all feedback into consideration, of course. Thanks for sharing your ideas. They all factor into what we are doing.
I am new and have not read all the posts on new propeller. Is there any chance of having PGA 13x13 or PLCC84 packages options ? Such package allow home made prototipe boards and soldering very inexpensive (10 mils route, double layer, no smd, pass-through components becomes vias)
davran, if you feel dedicating a cog for a process is overkill (because it requires neither the space or the speed of a whole cog) you can use the JMPRET command to switch off between multiple processes. Take a look at the assembly driver in FullDuplexSerial for an example of its use.
On the dedicating a cog to a single task, think about this.
On an arm chip you typically have a processor and a number of dedicated peripheral interfaces (anywhere up to about 12 or so?). On the prop you typically have one 'master' cog that does the high level logic and the other cogs doing the jobs of the dedicated peripherals. What's so different about that to an arm chip except for the fact that you can make the peripherals anything you want rather than a canned set of functions?
"in their little ARMish community " the chip you despised accounts % 75 of the 32 bit risc cpu.
Shortly i dont believe the contradiction with you will be beneficial.
you could try to answer with reasons (and wih respect) like others"
" Be sure i want prop to be used extensively (other than hobby) more than you. That is why i wrote the features industry wants.
by the way "lord steve" the post below is not funny.."
See davran, you don't have a sense of humor, you have to learn to laugh at things and sometimes that is at yourself too. My reply was a twist on words from the standpoint of a Propeller convert but formerly I was all for ARM having quite some experience with this chip. See my website at www.pbjtech.com/.
Of course I am going to downplay the ARM from the Propeller standpoint. Just because a chip has 75% of the 32-bit RISC market does not mean that it's the best. It's a licensed core and everyone has taken it on-board because they get acceptance at the same time while they are not supporting any other manufacturer's product. There are many problems with the architecture for embedded use which is why the Cortex variants are getting stronger.
Lord Steve's post was funny and your supervisors are not worthy of you our fellow prop'r, nor are they fit to be Propeller people like us (a little patriotic humor here).
I think this thread is rather funny. On the one side you have people wishing the propeller were something it's not. Some even wish it to be an ARM. If you want what ARM has to offer, use an ARM. On the other hand, you have people who have dedicated their lives (or seemingly so) to promoting the Propeller as the next gold standard for processor design. Most of us Prop fans realize that although the Prop is really cool, it is not the solution for every problem. The Prop II might be!
I work in product development for an automotive supplier. I have used the Propeller on several occasions to very quickly put together concepts that management is impressed with. One such product was an MP3 player with touch screen interface. But once they learn what I used for a processor, they say "You can't use that! It's not automotive approved! You can't program it in C! (you can soon!) And of course-it costs too much, we can get 32 bit processors for under $5! But all of this does not change the fact that I was able to put together something that would have taken a lot more time and money to develop by other means. So even though we might not use this processor in our final production design, it was great for throwing together a concept quickly. For me, this is one thing that the Prop excels at.
I think the direction for the PropII is right on the money. Why have dedicated hardware when you can emulate it with software just as effectively? Everything I have wished the Prop had is planned for the Prop II, and I'm excited and looking forward to the day becomes available.
Love it or hate it, the Prop is a different animal. Use it or don't use it, but don't wish it were something it's not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Ken Peterson said...
But all of this does not change the fact that I was able to put together something that would have taken a lot more time and money to develop by other means. So even though we might not use this processor in our final production design, it was great for throwing together a concept quickly. For me, this is one thing that the Prop excels at.
I've found the same, it's a great tool for rapid development and early prototyping ( fine-tuning the detail as always takes a little longer ).
I can see it in practice but wonder why that is. My best guess is that the Propeller's multi-Cog architecture is worth a lot more than is often appreciated and Spin gives near unlimited ability to do anything in a simple to use form. The Propeller's lack of complexity is not so much a disadvantage but entirely the opposite. The IDE/development environment and super-fast download works like a charm, ideally suiting incremental code-then-test rapid development.
With my flame-proof underwear on - It brings the same revolution to development as MS Visual Basic did and the Basic Stamp previously.
Hopefully this is an appropriate response to this thread.
How about providing one COG dedicated (or configured) as a high speed asynchronous serial interface (presumably running at 160 Mhz), AND provide a couple dedicated or configurable multi-function I/O pins to permit either daisy chaining of Propeller devices or access to external memory, FPGA device, etc?
If you are facing a die size constraint, Would it be feasible to keep eight COGS built with present model at higher clock rate and add eight new ones with more memory per COG AND provide additional RAM space in the master HUB device? Obviously, many typical tasks can be efficiently serviced by a 512 x 32 bit COG at 20 Mhz.
I picked up a copy of the ImageCraft beta C compiler at the ECS last week. I noticed this curious statement in the readme file.
"LMM VIRTUAL MACHINE:
To bypass the 512 long words limitation of a COG RAM program, ICCProp uses
a Large Memory Model (LMM) scheme, originally proposed by Bill Henning. The
basic idea is that instructions in HUB RAM is fetched into the COG RAM, and
then executed inline. The source code is in
c:\iccv7prop\libsrc.prop\kernel.s "
So if this is in fact, the memory model they have adopted, how do they(you) envision executable code being loaded into HUB RAM? If I understand the instruction set, this will require a dedicated COG to manage the buffer space in HUB RAM. That seems like an avoidable bottleneck and perhaps a serious handicap. Am I missing something?
It seems like one drawback in original PROP architecture is the capability to index quickly thru large > 512 x 32 bit arrays?
wg
One of the major advantages of the Propeller architecture is the fact that the cogs are identical, that none of them have special features, that they are interchangeable. You can already configure any cog as a high speed asynchronous serial interface. You can configure several cogs as such. You can configure any cog as an interface to other Propeller devices or access to external memory (if you have enough I/O pins available). What you can't do is extend any of the existing memory spaces with external memory. The timing would have to be different and the whole hub concept and the predictability of hub access would go away.
The instruction set does not permit more than 512 words of cog memory. There's no practical way to expand that. In Prop II, there will be much more hub memory. Because that's accessed with 32 bit words, it could theoretically be of any size.
Read more of the thread on the LMM. You'll find that there's an interpreter involved. It's very simple and mostly reads cog instructions from hub memory to cog memory where they're executed one at a time. The hub access timing works out very nicely so the overhead is low. The program is effectively executed from hub RAM where it's limited to about 32K of instructions and data. There are provisions to load blocks of code from hub RAM to one or another cog's RAM for execution when even the low overhead of the LMM interpreter is too much.
The Propeller is not designed for large array data crunching. It can do some, but not as efficiently or as cleanly as some other processors. If you have to do a lot of data crunching, you'd be better off using something else. It's really a microcontroller. It works best on high speed control applications where timing and time reproducibility is important. The fact that it can do so much else reasonably well is a tribute to its flexibility.
Comments
Propeller, gen.2 info - rev: 20 Oct.2007 Feature Quantity comments Forum pg/date/time --------------+-------------------+-----------------------------------+------------------ Cogs 16 v 160 MHz, pipelined instr./clock pg1/25Nov06/12:32a (2 clocks for Hub instr); pg1/25Jun06/12:52a 512 longs/cog; w/full speed Hub pg7/30Nov06/12:39p pg17/24May07/11:12a wide data path fetching pg19/28Jun07/9:26a 8 contiguous long accesses/hub R/W pg20/4Jul07/7:18p --------------+-------------------+-----------------------------------+------------------ Memory RAM 256KB v on-chip pg17/24May07/11:12a pg20/4Jul07/8:36p ROM 128K v include entire development system pg20/4Jul07/7:18p (no need for PC!) pg20/4Jul07/11:40p --------------+-------------------+-----------------------------------+------------------ I/Os 64 v pg17/24May07/12:50p INB, OUTB not same as INA, OUTA pg21/5Jul07/11:08a --------------+-------------------+-----------------------------------+------------------ Clock input min - max freq ? --------------+-------------------+-----------------------------------+------------------ PLL speed 160 MHz max ? --------------+-------------------+-----------------------------------+------------------ Packaging QFP preferred pg19/19Jun07/6:03p QFN ? LQFP ? BGA ? (NO thru-hole DIP) v DIP package would be too large p23/27Aug07/3:23p --------------+-------------------+-----------------------------------+------------------ Other pins 3.3v (I/O) 4 ? 64 I/Os plus these totals 80 pins pg2/25Nov06/11:26a 1.8v (I/O) 4 ? pg23/27Aug07/3:23p Gnd 4 ? Reset 1 BOE 1 ? Clock 2 --------------+-------------------+-----------------------------------+------------------ 16x16 multiply 1 v pg19/23Jun07/3:59p --------------+-------------------+-----------------------------------+------------------ Dev Sys onchip (see Memory above) in ROM pg20/4Jul07/11:40p --------------+-------------------+-----------------------------------+------------------ Availability probably a year away p3/25Nov06/1:10p 2 yrs, conservative pg5/7Mar07/12:00p between 1 - 2 years pg15/7Mar07/12:08p --------------+-------------------+-----------------------------------+------------------ Longevity most likely for pg8/5Dec06/6:01a next 15-20 years --------------+-------------------+-----------------------------------+------------------ 'code name' P-Chip 2 p15/7Mar07/12:08p P16X32 v means 16 cogs, 32-bit width p24/30Aug07/10:33a --------------+-------------------+-----------------------------------+------------------ Beau Schwabe - IC layout engineer, Parallax pg15/7Mar07/9:53p legend: '?' = not yet defined by Parallax; 'v' = mentioned by Parallax (Chip, Paul)Apologies to the editor's baaad formatting. Created on Mac using Monaco, .
9pt and spaces to format; but monospacing not retained
@ Forum moderator, the previous lists, pg19/28Jun07/3:56p and pg21/8Jul07/4:35p could be deleted
Sheesh!?!?!?! What a stupid editor! Looks different even after a 'SUBMIT'!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 10/20/2007 10:50:14 PM GMT
Propeller, gen.2 info - rev: 20 Oct.2007 Feature Quantity comments Forum pg/date/time --------------+-------------------+-----------------------------------+------------------ Cogs 16 v 160 MHz, pipelined instr./clock pg1/25Nov06/12:32a (2 clocks for Hub instr); pg1/25Jun06/12:52a 512 longs/cog; w/full speed Hub pg7/30Nov06/12:39p pg17/24May07/11:12a wide data path fetching pg19/28Jun07/9:26a 8 contiguous long accesses/hub R/W pg20/4Jul07/7:18p --------------+-------------------+-----------------------------------+------------------ Memory RAM 256KB v on-chip pg17/24May07/11:12a pg20/4Jul07/8:36p ROM 128K v include entire development system pg20/4Jul07/7:18p (no need for PC!) pg20/4Jul07/11:40p --------------+-------------------+-----------------------------------+------------------ 16x16 multiply 1 v pg19/23Jun07/3:59p --------------+-------------------+-----------------------------------+------------------ Clock input min - max freq ? --------------+-------------------+-----------------------------------+------------------ PLL speed 160 MHz max ? --------------+-------------------+-----------------------------------+------------------ I/Os 64 v pg17/24May07/12:50p INB, OUTB not same as INA, OUTA pg21/5Jul07/11:08a --------------+-------------------+-----------------------------------+------------------ Other pins 3.3v (I/O) 4 ? 64 I/Os plus these totals 80 pins pg2/25Nov06/11:26a 1.8v (I/O) 4 ? pg23/27Aug07/3:23p Gnd 4 ? Reset 1 BOE 1 ? Clock 2 --------------+-------------------+-----------------------------------+------------------ Packaging QFP preferred pg19/19Jun07/6:03p QFN ? LQFP ? BGA ? (NO thru-hole DIP) v DIP package would be too large pg23/27Aug07/3:23p --------------+-------------------+-----------------------------------+------------------ Dev Sys onchip (see Memory above) in ROM pg20/4Jul07/11:40p --------------+-------------------+-----------------------------------+------------------ Availability probably a year away pg3/25Nov06/1:10p 2 yrs, conservative pg5/7Mar07/12:00p between 1 - 2 years pg15/7Mar07/12:08p --------------+-------------------+-----------------------------------+------------------ Longevity most likely for pg8/5Dec06/6:01a next 15-20 years --------------+-------------------+-----------------------------------+------------------ 'code name' P-Chip 2 pg15/7Mar07/12:08p P16X32 v means 16 cogs, 32-bit width pg24/30Aug07/10:33a --------------+-------------------+-----------------------------------+------------------ Beau Schwabe - IC layout engineer, Parallax pg15/7Mar07/9:53p legend: '?' = not yet defined by Parallax; 'v' = mentioned by Parallax (Chip, Paul) pg = page number of reference in this thread.Where's the improvement? When displayed. it ultimately is not the same as viewed while editing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Must be something with that editor. Maybe how it interprets tab stops?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Evan
Looking at my table on the Mac, it is messed up more than I see today on the PC laptop. The latter is a bit nicer on my table. Evanh's is about the way it should appear.
Looks like I should create tables for the forum on the PC instead. Hate incompatibilities. They're getting better and better between Macs and PCs. Probably partly or wholly due to the older browser on the Mac. (Mac is my main machine guys)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
I know the MAC has some plan ASCII editors. (If I were in front of one right now, I would just go and locate it.) Some fonts are mixed. Spaces will consume less character space, while chars are largely non-proportional. A quick copy paste of some test text should ferret this out. Build something simple, like:
[noparse][[/noparse]five spaces][noparse][[/noparse]five chars][noparse][[/noparse]five spaces][noparse][[/noparse]five chars], etc....
Then check out the fonts.
There is no reason why one cannot build up a table like this on the MAC. Check out some of this info:
http://www.gutenberg.org/wiki/Gutenberg:Word_Processor_FAQ (font word processor / editor clarification)
Links to various non-proportional fonts. I think you'll need a TTF to MAC font converter tool to deal with any of these.
http://www.codinghorror.com/blog/archives/000969.html
I'm pretty sure the "Terminal" font is non-proportional. Won't look all that nice, but will render correctly in the code tags here. The Bitstream Vera TTF has a really pretty great non-proportional font in it, that will render nicely on the MAC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
The dirty fix is to rename a copy of a mono-spaced font to that which is specified. The common one that gets used on webpages these days is one from M$ Office called Lucida Console.
Evan
i am an engineer @ www.karuzel.com/ in Ankara (T
Please Parallax, keep doing what you are doing.
*Peter*
In Australia I can get (single quantities) a propeller+eeprom+crystal for about $25 from Ron Nollet or an ATMega8535 for about the same price from Jaycar (local electronics store).
2) there is no other version of prop. For example VSCL and VCFG is can be put only one cog. One cog must be able to take interrupts so that it can handle all the small tasks (k.b mouse, bit manupulation, etc). dedicating a 32 bit cog just for k.b is not logical.(my opinion) So that 4 - 5 cog would be enough for parallel processing.
One of the main ideas of the prop is to eliminate interrupts to make programming easier. Many applications could get by with less cogs (say 4) but the cost of the chip would be about the same as the current prop.
3) parallax must assure us about maintaining the production of the prop. at least 5 years.
They have indicated that the prop will be a major item for them and they will continue to make it for as long as possible. The SX chips have been around for a very, very long time now.
Also fixed point multiplication and division instruction would be nice.
There is are instructions set aside for multiplication and signed multiplication and the indication is that these will be implemented in the propII. I don't think that this has been confirmed by parallax though.
1) Can't argue with you on that, but Parallax is small compared with Microchip...
2) It's sometimes hard to change our mindset from needing interrupts, however that's what you MUST do if you're to enjoy the Propeller! With some work, it's still possible to combine some tasks into one COG - I think someone has already combined keyboard and mouse. Whilst at first glance it may seem wasteful to dedicate a 32bit COG to one sensor, think of the massive reduction in development time as a result of not having to worry about interrupts...
3) I'm sure I've seen something from Parallax stating they have every intention of carrying stock of the Propeller for 8 years or more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
1) Chip cost isn't always the only factor. If the overall outcome will not be as competitive or productive as using an alternative then by all means use something else. The Propeller is not a universal panacea and I don't believe anyone has ever claimed it to be.
2) Multiple Cogs bring benefits which can outweigh the lack of interrupts. A single Cog can handle multiple processes / tasks while complex interrupt functionality can often be emulated using multiple Cogs. The Propeller II will have twice as many Cogs.
Some people see the Propeller as potentially difficult being different to what they have previously used. Others see it as a great improvement. Also see the "Why the Propeller Works" sticky.
3) There's no indication Parallax will not produce and support the Propeller for a long time to come, and given the investment put in and support for it from the highest level of Parallax down there's no reason to believe they won't. However no one can truly foresee what the future holds.
·Shortly i dont believe the contradiction with you·will be beneficial.
·you could try to answer with reasons·(and wih respect)·like others. Be sure i want prop to be used extensively (other than hobby) more than you. That is why i wrote the·features industry wants.
· by the way "lord steve"·the post below is not funny..
Post Edited (davran elektronik) : 4/14/2008 9:11:30 PM GMT
The management of your company may find the chip described on this page linked below more suitable to·their stringent business needs.· Be sure to give them all the information.
http://forums.parallax.com/showthread.php?p=719497
Entrenched ideas are hard to change, and are often exploited.
April fool's jokes like Xallarap are supposed to be funny.
Human nature ... take it, leave it, ignore it, laugh or cry for it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
As for the "interrupt please" request. Again, not a HW person, but besides simplifying the programming model, I'd guess that not having to deal with interrupts simplifies the design considerably as well. A COG is just a relatively computational engine now. With interrupts, you have to break the pipeline, provide context save and restore features. All that add to the complexity of the design and potentially more bugs. Lets say a multiple cycle MUL instruction is added. With interrupt, you have to either disable interrupts around it or save and restore intermediate context. With multiple COGs, once you sync up with the HUB timing, things are more deterministic. Even adding a LMM kernel is not that bad - while the determinism is not precise, it is a narrow range with lower and upper bounds. In other words, I don't think this will change, but then again, we are never suppose to see "Intel Inside" a Mac either. That and $700 gets a Core 2 Duo Mac Mini now, so anything is possible.
Anyway, sell your managers on the strength of the Propeller. Don't mention the negatives
Chip Gracey
Parallax, Inc.
I am new and have not read all the posts on new propeller. Is there any chance of having PGA 13x13 or PLCC84 packages options ? Such package allow home made prototipe boards and soldering very inexpensive (10 mils route, double layer, no smd, pass-through components becomes vias)
regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
On an arm chip you typically have a processor and a number of dedicated peripheral interfaces (anywhere up to about 12 or so?). On the prop you typically have one 'master' cog that does the high level logic and the other cogs doing the jobs of the dedicated peripherals. What's so different about that to an arm chip except for the fact that you can make the peripherals anything you want rather than a canned set of functions?
See davran, you don't have a sense of humor, you have to learn to laugh at things and sometimes that is at yourself too. My reply was a twist on words from the standpoint of a Propeller convert but formerly I was all for ARM having quite some experience with this chip. See my website at www.pbjtech.com/.
Of course I am going to downplay the ARM from the Propeller standpoint. Just because a chip has 75% of the 32-bit RISC market does not mean that it's the best. It's a licensed core and everyone has taken it on-board because they get acceptance at the same time while they are not supporting any other manufacturer's product. There are many problems with the architecture for embedded use which is why the Cortex variants are getting stronger.
Lord Steve's post was funny and your supervisors are not worthy of you our fellow prop'r, nor are they fit to be Propeller people like us (a little patriotic humor here).
*Peter*
I work in product development for an automotive supplier. I have used the Propeller on several occasions to very quickly put together concepts that management is impressed with. One such product was an MP3 player with touch screen interface. But once they learn what I used for a processor, they say "You can't use that! It's not automotive approved! You can't program it in C! (you can soon!) And of course-it costs too much, we can get 32 bit processors for under $5! But all of this does not change the fact that I was able to put together something that would have taken a lot more time and money to develop by other means. So even though we might not use this processor in our final production design, it was great for throwing together a concept quickly. For me, this is one thing that the Prop excels at.
I think the direction for the PropII is right on the money. Why have dedicated hardware when you can emulate it with software just as effectively? Everything I have wished the Prop had is planned for the Prop II, and I'm excited and looking forward to the day becomes available.
Love it or hate it, the Prop is a different animal. Use it or don't use it, but don't wish it were something it's not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
I've found the same, it's a great tool for rapid development and early prototyping ( fine-tuning the detail as always takes a little longer ).
I can see it in practice but wonder why that is. My best guess is that the Propeller's multi-Cog architecture is worth a lot more than is often appreciated and Spin gives near unlimited ability to do anything in a simple to use form. The Propeller's lack of complexity is not so much a disadvantage but entirely the opposite. The IDE/development environment and super-fast download works like a charm, ideally suiting incremental code-then-test rapid development.
With my flame-proof underwear on - It brings the same revolution to development as MS Visual Basic did and the Basic Stamp previously.
How about providing one COG dedicated (or configured) as a high speed asynchronous serial interface (presumably running at 160 Mhz), AND provide a couple dedicated or configurable multi-function I/O pins to permit either daisy chaining of Propeller devices or access to external memory, FPGA device, etc?
If you are facing a die size constraint, Would it be feasible to keep eight COGS built with present model at higher clock rate and add eight new ones with more memory per COG AND provide additional RAM space in the master HUB device? Obviously, many typical tasks can be efficiently serviced by a 512 x 32 bit COG at 20 Mhz.
I picked up a copy of the ImageCraft beta C compiler at the ECS last week. I noticed this curious statement in the readme file.
"LMM VIRTUAL MACHINE:
To bypass the 512 long words limitation of a COG RAM program, ICCProp uses
a Large Memory Model (LMM) scheme, originally proposed by Bill Henning. The
basic idea is that instructions in HUB RAM is fetched into the COG RAM, and
then executed inline. The source code is in
c:\iccv7prop\libsrc.prop\kernel.s "
So if this is in fact, the memory model they have adopted, how do they(you) envision executable code being loaded into HUB RAM? If I understand the instruction set, this will require a dedicated COG to manage the buffer space in HUB RAM. That seems like an avoidable bottleneck and perhaps a serious handicap. Am I missing something?
It seems like one drawback in original PROP architecture is the capability to index quickly thru large > 512 x 32 bit arrays?
wg
The instruction set does not permit more than 512 words of cog memory. There's no practical way to expand that. In Prop II, there will be much more hub memory. Because that's accessed with 32 bit words, it could theoretically be of any size.
Read more of the thread on the LMM. You'll find that there's an interpreter involved. It's very simple and mostly reads cog instructions from hub memory to cog memory where they're executed one at a time. The hub access timing works out very nicely so the overhead is low. The program is effectively executed from hub RAM where it's limited to about 32K of instructions and data. There are provisions to load blocks of code from hub RAM to one or another cog's RAM for execution when even the low overhead of the LMM interpreter is too much.
The Propeller is not designed for large array data crunching. It can do some, but not as efficiently or as cleanly as some other processors. If you have to do a lot of data crunching, you'd be better off using something else. It's really a microcontroller. It works best on high speed control applications where timing and time reproducibility is important. The fact that it can do so much else reasonably well is a tribute to its flexibility.