This has been a high-speed chase keeping up with all the dribs-n-drabs of info on Prop gen #2. I realize this is an iterative process (well, aren't most designs?) So I've 'captured' some of the inputs for the 'specification' that's been doled out.
Chip Gracey said...
What would you rather have in a future Propeller chip:
Option·1: 16 cogs with 128KB of hub RAM. Hub access once every 16 clocks.
Option·2: 8 cogs with 256KB of hub RAM. Hub access once every 8 clocks.
Note that each cog would run at about 160 MIPS, as opposed to the current 20 MIPS.
Not aware of the later 'surprises' I voted for 8 cogs. 160 MIPS was a super surprise; only 6.25 nsec delay on recognizing input changes!!!
Chip said...
Hub instructions will take 2 clocks, so you can fit six regular instructions between them. 160MHz is the clock goal. Cogs are pipelined so instructions take 1 clock.
Paul Baker said...
No the process doesn't support 5V, only upto 3.6V with it optimized for 1.8V. The oxide is too thin to permit a robust 5V I/O design.
Now a second regulator is required for the 'core'. OK, that's expected to come with the 'speed' territory.
Paul said...
No, because PortB will be implemented for a total of 64 I/O. It hasn't been determined if 32 I/O versions will be produced, but it would be possible to do so since the die size will remain the same.
Wow!! Now we find it is the 64 I/O Prop (the Port A and Port we've been reading of. Now we know the packaging has changed. No more DIP package for this speedster. Probably a 84-pin SMD only.
Will the same sink/source currents be available?___ And will current limiting resistors need be larger; or can the oxide 'diodes' still stand mils of current?___
Now, I need to change my mind on number of cogs; now feel 16 should come with the 64 I/O Prop. With all this I/O, some apps will need more than 8 cogs. For my 2-Prop project, that gave me 16, though some got used in Prop-to-Prop comm and freq synth to 2nd Prop; still need more than 8 for gen#2 Prop.
And more RAM, whether 8 or 16 cogs. Winner all the way around.
Does this '160 MHz Prop' use the same 5 MHz crystal?___ And will this higher speed affect some of the existing Objects?____
Yes, as a specialty order a .9" wide 64 pin DIP is availible, but it wouldn't work, 64 I/O + crystal + BOE + RES + Power > 64 pins. And a .9" wide DIP is huge, a more likely scenario is to release a version which only has 32 I/O. Don't worry though, I'm sure there will be a variety of boards availible for the hobbyist that doesn't want to surface mount solder.
Well yes, obviously 64 I/O + anything > 64 pins [noparse]:)[/noparse] I was originally thinking of maybe having only half of port B exposed to pins, so 48 I/O + crystal + BOE + RES + Power < 64 pins. I see your point about the chip being huge though.
Mind you, if port B is not exposed to pins but is otherwise fully functional (as in, all the wait instruction work etc), it could be used as a fast inter-cog communication channel. Cog A waits for a bit to be set, cog B sets that bit plus a few other bits with the "real" data in it, cog A "wakes up" and reads the other bits = much faster than B putting the data in shared RAM and having A wait for the hub to come around.
Personally, I like a PLCC84 package - thruhole .1" sockets are readily available, a "superdip" module is possible, and it has enough pins for ports A&B + the strobes I want [noparse]:)[/noparse]
Yep, I think most of us 8 coggers ended up punting on that decision.
I'm in the 16 cog camp now for sure.
Was a bit bummed about the lower voltage decision that's likely to occur, and the high pin count package. However, I'm also thinking if we have only one new prop, best to make it that way and let other products that make it easier to interface evolve as needed.
They have a PLCC 84 pin to DIP socket conversion mount ... this is the cheapest I have found online... however,·I did some research on this·company, and I·saw·mixed reviews about their service and responsiveness/delivery ...··www.digikey.com has a similar conversion mount, but at· USD 32.00 is·quite a considerable amount for a hobbyist to spend in a·PLCC mount....·well, there·is always the through-hole PLCC socket for less than·two dollars... ······ I hope this helps...
Post Edited (Joe "Bot" Red) : 12/4/2006 8:35:15 PM GMT
It seems that the forum is particularly keen on the 16 cog / 128KB RAM possibility, which was our original goal. It's funny how often the first inclination works out to be the best, after all. So, we'll probably make that one first, but the 8 cog / 256KB RAM wouldn't have to be far behind. There would be only minor hub circuitry differences between them.
Also in the works is a 64 I/O version of the current Propeller (INB/OUTB/DIRB implemented). It will need to be in a 12x12mm LQFP package or in a 10x10mm micro BGA.
2. Possibilities that could be implemented if possible.
We'll probably smarten up the I/O pins so that they can perform some counter functions autonomously and do more analog stuff. Also, we'll have to make some bitwise inter-cog communication circuitry to facilitate faster inter-cog signaling.
I don't want to hold you to any of these statements......I know that you put as many things in your chips,·as are price effective.
There has been so many suggestions and opinions....I for one would like to know where we stand at the moment.
I know this whole thread is a hypothetical discussion.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 12/5/2006 6:41:10 AM GMT
If there was such a thing as a Prop with some A/D capabilities we'd never buy anything else.... recently we've moved away from Stamps somewhat specifically because they don't have analog inputs.
Post Edited (M. K. Borri) : 12/6/2006 12:59:34 AM GMT
I am still in the 8 cog 256K camp. I still beleive that that memory and speed is more important than COGs, but if·Parallax does go the 16 COG route I am glad that they are also considering releasing the faster, greater memory Prop sometime after.
I'd have vote for the 16 cog version. I've been using the propeller for robotics applications and its alot easier to dedicate a cog to monitoring a time sensitive sensor than to try to multiplex multiple sensors with the same cog and worry about interfereing with each others timing. With more pins I'd just want to add more sensors so the problem would be even worse. So I would definitely want·more cogs over more memory. Besides that is what the propeller is so great for. If I want alot of ram I can use one of the many other micros out there, but none of them let be do 8 (or 16) things at once.
Also for some projects it would be great to have some A/D onboard. Its not too hard to add it externally, but sometimes its nice to have it all on one chip. Maybe it could be added to the next generation of development boards.
With Bill Henning's Primatives offering a memory enlargement scheme in software, it seems to me that 16 COGs would be more needed. More pins would be useful to, so the 64 pin model would hopefully come into being [noparse][[/noparse]it would allow more A/D and D/A].
After all, his scheme easily extends memory withing the current version of the Propeller. This is quite exciting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Starting computers late in life has always put my behind the learning curve with new tecnology, so 8/256 sits fine with me, but I do sympathize with the robotics guys where more cogs could be of benifit. Although I am one that is spoiled by interrupts I tend to believe the propeller can cure me of this and 8 cogs is plenty.
Parallax knows more than I when they posted this question as an ultimatum, but I hope they don't lose site of a user configurable module where a cog can be canabolised by another for its ram. Any ram capacity between 128 and 256 could then ·be realized, and for those of use who can't do with out a cog, we ·will just have to suffer on the ram, and vice versa.
I was dreaming when I left my 11 dollar an hour job to work at McDonalds and go back to school too. It didn't hurt then, I hope It doesn't hurt now.
Besides If I have any more fun with them than I am haveing with this Chip my Other Half is going to put me on Ridilen!!!!!!!
Hi all,
I'm new here and in Propeller programming, and a bit late for this interesting thread but I couldn't resist, so warning, I could be talking nonsenses
Chip Gracey (Parallax) said...
Maybe when a cog is launched, its hub-access requirement could be stated, and then the launch would pass/fail based not just on whether or not a cog was available, but also on whether or not a requested-bandwidth hub slot was available. For example, you could have 1:4 being the highest, then 1:8, 1:16, and finally 1:32. Every program should use the lowest-possible setting. It would take only a bit of logic in the hub to negotiate the setup·requests and then serve them deterministically thereafter.
What about leave bandwidth·selection and deterministic·access up to the programmer? I mean, by providing some new priority load instructions ex: MOVL1, MOVL2, etc·the app·could decide how much bandwidth allocate to each cog/task by instruction priority level and cog priority level. So ex. cog 0 would have priority over all other cogs, and MOVL1 over MOVL2...and so on. This method could provide full bandwidth to a cog if need, maybe full bandwidth·to two cogs, if a method to de-synchronize two cogs can be implemented.
Also, any improvement·on intercog comm is need, imho. The use of·I/O pins for I2C or any protocol for intercog comm is an indesired waste of valious resources.
Maybe replace some internal rom by ram, character maps and sin/cos tables are not need for all apps, this space could be better used for ram.·Such tables can still be loaded by external eeprom anyway, even better, they can·be modified if need (ex. a small set or customized characters instead fixed ones). Every bit matters. About that, maybe releasing addreses of useful internal rom routines as external eeprom comm, etc·would be great for reuse.
About the initial question, I'll go for 8 cogs option.
Dennis,
There was a comment by someone (Paul Baker?) in the last day or two that the current sigma-delta ADC capability was not planned, was discovered to be possible with the chip after it was built. The current on-chip circuitry is not at all designed for this use, yet works very well for some applications. With a little deliberate care paid to logic paths, noise, etc., it should work much better. There's nothing wrong with the method itself which is used in a number of commercial ADC chips.
Mike
Comments
For robitcs app's -- and those that require multiple connections with the oustide world -- I'd need all the COGs I can get.
Given that option 1 has twice the COGs and RAM - that gets my vote [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 ;-)
Will the same sink/source currents be available?___ And will current limiting resistors need be larger; or can the oxide 'diodes' still stand mils of current?___
Now, I need to change my mind on number of cogs; now feel 16 should come with the 64 I/O Prop. With all this I/O, some apps will need more than 8 cogs. For my 2-Prop project, that gave me 16, though some got used in Prop-to-Prop comm and freq synth to 2nd Prop; still need more than 8 for gen#2 Prop.
And more RAM, whether 8 or 16 cogs. Winner all the way around.
Does this '160 MHz Prop' use the same 5 MHz crystal?___ And will this higher speed affect some of the existing Objects?____
Too late to change my mind? 16 cogs, please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Post Edited (Harley) : 12/2/2006 12:17:25 AM GMT
IIRC the Motorola 68000 used to come in a 64 pin DIP package, are those·still manufactured?
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 12/2/2006 4:05:28 AM GMT
Mind you, if port B is not exposed to pins but is otherwise fully functional (as in, all the wait instruction work etc), it could be used as a fast inter-cog communication channel. Cog A waits for a bit to be set, cog B sets that bit plus a few other bits with the "real" data in it, cog A "wakes up" and reads the other bits = much faster than B putting the data in shared RAM and having A wait for the hub to come around.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
What's the final decision.
16 cogs or 8 cogs?
Looks like the majority vote is for 16 cogs !.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
I'm in the 16 cog camp now for sure.
Was a bit bummed about the lower voltage decision that's likely to occur, and the high pin count package. However, I'm also thinking if we have only one new prop, best to make it that way and let other products that make it easier to interface evolve as needed.
I've a question:
Will the current prop continue to be sold?
http://www.futurlec.com/PLCC_Adapters.shtml
They have a PLCC 84 pin to DIP socket conversion mount ... this is the cheapest I have found online... however,·I did some research on this·company, and I·saw·mixed reviews about their service and responsiveness/delivery ...··www.digikey.com has a similar conversion mount, but at· USD 32.00 is·quite a considerable amount for a hobbyist to spend in a·PLCC mount....·well, there·is always the through-hole PLCC socket for less than·two dollars...
Post Edited (Joe "Bot" Red) : 12/4/2006 8:35:15 PM GMT
Could you give us all and update......
I'm sure we would all like to know:
1. What options are you considering?
2. Possibilities that could be implemented if possible.
I don't want to hold you to any of these statements......I know that you put as many things in your chips,·as are price effective.
There has been so many suggestions and opinions....I for one would like to know where we stand at the moment.
I know this whole thread is a hypothetical discussion.
James L
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 12/5/2006 6:41:10 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thanks Chip for the update,
James L
Faster 8 cogs with 256k HUB RAM.
But then again, 32 cogs with 2mb ram would be killer.
hehehe
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Coders' Hangout
A place for programmers to hangout!
http://www.codershangout.com
METROID?
Metroid Classic
-Dan
Post Edited (M. K. Borri) : 12/6/2006 12:59:34 AM GMT
Also for some projects it would be great to have some A/D onboard. Its not too hard to add it externally, but sometimes its nice to have it all on one chip. Maybe it could be added to the next generation of development boards.
Kova
After all, his scheme easily extends memory withing the current version of the Propeller. This is quite exciting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
Starting computers late in life has always put my behind the learning curve with new tecnology, so 8/256 sits fine with me, but I do sympathize with the robotics guys where more cogs could be of benifit. Although I am one that is spoiled by interrupts I tend to believe the propeller can cure me of this and 8 cogs is plenty.
Parallax knows more than I when they posted this question as an ultimatum, but I hope they don't lose site of a user configurable module where a cog can be canabolised by another for its ram. Any ram capacity between 128 and 256 could then ·be realized, and for those of use who can't do with out a cog, we ·will just have to suffer on the ram, and vice versa.
I was dreaming when I left my 11 dollar an hour job to work at McDonalds and go back to school too. It didn't hurt then, I hope It doesn't hurt now.
Besides If I have any more fun with them than I am haveing with this Chip my Other Half is going to put me on Ridilen!!!!!!!
I'm new here and in Propeller programming, and a bit late for this interesting thread but I couldn't resist, so warning, I could be talking nonsenses
Also, any improvement·on intercog comm is need, imho. The use of·I/O pins for I2C or any protocol for intercog comm is an indesired waste of valious resources.
Maybe replace some internal rom by ram, character maps and sin/cos tables are not need for all apps, this space could be better used for ram.·Such tables can still be loaded by external eeprom anyway, even better, they can·be modified if need (ex. a small set or customized characters instead fixed ones). Every bit matters. About that, maybe releasing addreses of useful internal rom routines as external eeprom comm, etc·would be great for reuse.
About the initial question, I'll go for 8 cogs option.
Regards, Gus del Solar
Please don't put any dedicated peripherals on the chip.
Cheers,
Peter (pjv)
There was a comment by someone (Paul Baker?) in the last day or two that the current sigma-delta ADC capability was not planned, was discovered to be possible with the chip after it was built. The current on-chip circuitry is not at all designed for this use, yet works very well for some applications. With a little deliberate care paid to logic paths, noise, etc., it should work much better. There's nothing wrong with the method itself which is used in a number of commercial ADC chips.
Mike
More RAM please.
Best regards,
John Baker