This chip is definitely shaping up to something nice! All that I ask is that a PLCC version of the chip be made, so that I don't have to hand solder over 64 tiny pads 1mm or less apart. With a PLCC chip, I can solder a socket with a nice .1" spacing, and have a pretty high degree of certainty that I haven't shorted anything (and, because it's through-hole, a 100% certainty that the chip is properly lined up)
Just my .02$ on what to put into the large ROM space of the propeller V2.
It would be excellent to have functions for creating on-screen(vga etc) widgets like tabs, buttons,sliders,text,simple graphics(gif),etc.
Each widget could have associated event handlers to pick up on keyboard and mouse input.
Since this would be needed for a development system anyway, why not make them available for general use?
Something approaching the functionality of this would be great.
www.amulettechnologies.com
Fabian Nunez said...
This chip is definitely shaping up to something nice! All that I ask is that a PLCC version of the chip be made, so that I don't have to hand solder over 64 tiny pads 1mm or less apart. With a PLCC chip, I can solder a socket with a nice .1" spacing, and have a pretty high degree of certainty that I haven't shorted anything (and, because it's through-hole, a 100% certainty that the chip is properly lined up)
The 84 pin package would be needed to bring out all 64 I/O, that's a big package! Or maybe a 68 pin package with a slightly reduced I/O count would be a better config with PLCC.
Actually, this idea could extend down to using a 32 pin QFP/24 pin skinnyDIP or something like that for cheaper/smaller options. Still using the same die with all 64 I/O internally available for IPC.
making the Hub's round robin indexing engine smarter might be in order also.
Please elaborate ...
Off the top of my head, adding a request bit for each Cog that goes true when that Cog is waiting for bus access and having a priority encoder applied to the index adder instead of just the existing +1 incrementing.
No, not quite right. [noparse][[/noparse]couple of edits later ...]
Needs to have a barrel shifter of the pending bits, rotated by the index register value. The output of this shifter can then be priority encoded and added back to the index.
This sounded a bit familiar .... I knew I read it somewhere..
United States Patent 20070089112
An apparatus for selecting one of N requestors of a shared resource in a round-robin fashion is disclosed. One or more of the N requesters may be disabled from being selected in a selection cycle. The apparatus includes a first input that receives a first value specifying which of the N requesters was last selected. A second input receives a second value specifying which of the N requesters is enabled to be selected. A barrel incrementer, coupled to receive the first and second inputs, 1-bit left-rotatively increments the second value by the first value to generate a sum. Combinational logic, coupled to the barrel incrementer, generates a third value specifying which of the N requesters is selected next.
Regards,
··········· QuattroRS4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 7/28/2007 5:25:58 PM GMT
Ok, the purpose is to auto-skip any/all Cog cores that aren't waiting for service.
Eg: Setup 6 of the 8 Cogs doing hardware like functions where they only access Hub memory to update it when the I/O conditions dictate. Leaving the remaining two Cogs to alternate say 90% of the Hub slices between them.
Admittedly, this means variable results for main memory bandwidth from an individual Cog's pov.
It would be interesting to know how many patents Parallax have enquired about. Since every single function inside the Propeller will be covered by older patents. Even the basic bit-shift for example!
This has been discussed a bit earlier in the thread, but one of the main advantages of the Propeller's hub setup is that the timing relationship of one cog to another is fixed once the cogs synchronize to each other including hub memory access. It make things like the video drivers much easier for example. If you add a priority scheme, you lose this. What has been discussed as a possible implementation is that of a settable hub access assignment. All cogs would have at least one hub access per cycle and the other 8 access slots could be assigned to specific cogs during program initialization (much as the clock mode can be reset, but not without affecting everything). This keeps the predictability, but allows cogs with low bandwidth needs to hub memory to contribute some of their resources to other cogs.
[noparse][[/noparse]quote]Admittedly, this means variable results for main memory bandwidth from an individual Cog's pov.
Yes, it's a trade-off between determinism and maxing out the MIPS. I'd guess for most scenarios that you'd use a propeller for, predictable response is more important than maximum throughput.
I agree. It's the fact that an assembly driver running in one cog has almost zero ability to mess up one running in another cog that is the genius of the Propeller. The isolation, the lack of interaction even on timing issues, is what allows someone to combine many different pieces of code and still have confidence that they'll work as well together as they did separately.
That is also very true. And (an often overlooked) additional benefit is that you don't have to worry much about interrupt latency - or priority. That nightmare grows gradually and gets tough when you have five or six interrupt sources and can't really decide which has priority or how long it can wait, worst case. I have been into that several times. And I do not wish to go there again.
Is there a T-shirt with a red heart and a propeller on it? I think that I would look good in one
We plan on implementing wide data path fetching to overcome memory bandwidth issues of larger cog counts. This way we can maintain the determinism and improve the bandwidth.
So we are talking about a 16 cogger with somewhere between 160MB/Second bandwidth for each cog all the way up to possibly up to 640MB/Sec/cog
Very Cool, Lots of Cogs and bandwidth too.
Any final word on Hub Memory Size? 128K? 256K? 512K?
How about booting. For a quick boot is there the option to just load to the end of the program size, not the whole eeprom?
Now I an see the demo boards for this thing are going to have DVI connectors, 100BaseT, 6 Channel audio, USB 2.0 etc!
And with 64 pins, strapping on an extra couple of megabytes of ram shouldn't be too tough!
With that kind of bandwidth, maybe I could do a SCSI to MicroSD raid controller!
You sound a little loopy, but that would probably·be possible with the propellor 2. but 640 MB a second sounds like a myth for the prop 2, If you want that speed, you'd have to do quite a bit of work to get it to do perfectly. right now I belive the fastest bandwith speed ever done on the prop 1 was about 6 MB per second. Still, it doesn't mean all that extra ram for programs and all those cogs plus a USB hardrive and whatever ethernet stuff you connect can't make it possible!
I hope that they implement it, perhaps also support Png's Jpegs' and TNG's. So that you can browse the internet without seeing X's on all those images.
But, I doubt that the demoboards are gonna have ALL that. But hopefully they will at least have the DVI connection and·a USB hardrive for storage incase of large programs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Realize that I am really a mad scientist··· and
Will the single-cycle multiplier be the 16x16=32 bits variety?· Will there be a "long" multiply 32x32=64 bits?
How many blowable fuses will be present?
What's the real reason why we can't be treated to a Propeller with FLASH in lieu of that EEPROM?· If it's "the process", then why can't that be changed?· It does seem kinda silly that Parallax is of the opinion that dedicated peripherals is wasted silicon, yet all my precious non-volatile storage is being wasted on dedicated tables.· That being said, I enjoy working with it. [noparse]:D[/noparse]
The multiplier is 16 x 16. There won't be a hardware 32 x 32 multiplier. You'll have to do that with a short subroutine.
The real reason we can't have on-chip flash memory is exactly what has been stated. The manufacturing process used for the chip cannot create the proper structures for flash memory. I suspect that it can't be changed because the tradeoffs in choosing a process would markedly increase the cost of the chip or require that some of the functionality be dropped.
You may think it was silly to give up dedicated peripherals, but it was a well thought out design decision to not have dedicated peripherals and to use general purpose processors to implement any dedicated functions. You may not like it, but it was not lightly chosen. Designers get to make those kinds of choices.
Again, it was not an option to have flash memory on-chip. On the other hand, ROM is made using the same kinds of structures as the rest of the chip and a certain amount of ROM was needed for the boot loader and the Spin interpreter. The dedicated tables are of two kinds: 1) font tables; 2) transcendental tables. The first goes with the other video-friendly features. The second has been a built-in feature of the Stamps since the beginning and is useful in robots and sensor processing. ROM is pretty cheap in terms of chip area, so, once some ROM had to be included, 32K was the next useful size boundary. What would you have put in there that would have been available early in the chip development?
······· I would like to be able to write code in SX/B for this chip. I need to use this chip for one of my applications but I don't know Spin or assembly. I would like to suggest that if you offer a PBASIC compiler for the propeller I think it would open the door for newbie’s like me.· Parallax has given me an opportunity to develop my own projects. I think if you provide ways to program all your chips in a basic environment it would open more doors for us all. I moved through the BS1 and BS2 pretty quick. I am using the SX chip now but I would like to use the Propeller chip to output a freq from 100 to 50mhz. I heard this chip can do what a DDS chip does but I can’t write in assembly or spin so I have to add a Co-processor to communicate to the DDS chip with 32 bit word in order to output ·the frequency I want.· I heard the propeller can do that. It probably won’t happen but I put in my 2 cents.. ·
While it's always nice to be able to use the tools that you are used to, it doesn't always make sense. The SX does things very differently from the Propeller and, except for built-in basic functions, you can't just convert from one to another. A lot of things that are done easily with the Stamps or demonstrate functionality (like frequency synthesis) are already written for you as library routines or sample programs in Spin, possibly with some bits in assembly where needed. They're well commented and can often be used as is or with minor changes. You'll find stuff like this in the Propeller Object Exchange or included with the Propeller Tool.
I think, particularly if you start with the tutorials from the Propeller Education Kit, that you can learn Spin fairly quickly, particularly starting with the examples that are close to what you need for your project. You could also use something like FemtoBasic which is a very simple interpreted Basic, but does allow access to the I/O pins and to the counters used for frequency synthesis.
I don't think you'll see anything like PBasic any time soon. What resources are available at Parallax are best spent in development of teaching tools (texts, tutorials, further well documented examples) for Spin and assembly, let alone the development of future Propeller chips.
Paul Baker (Parallax) said...
We plan on implementing wide data path fetching to overcome memory bandwidth issues of larger cog counts. This way we can maintain the determinism and improve the bandwidth.
Hi Paul, has it all been finalised?
Or would something like load multiple bytes into longs be possible to add? ie read one long from hubram and put it into 4 longs in cog ram etc?
That would come in handy too. [noparse]:)[/noparse]
The Prop 2 is amazing...Infact it's essentially exactly what I've always wanted the prop 1 to be! [noparse]:o[/noparse]
This prop 2·seems·to have more than enough power to generate a 16 bit sprite engine with scaling,rotation,parallax scrolling and 3d floormapping along with tiles...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Realize that I am really a mad scientist··· and
Comments
pocket supercomputer anyone?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.
Again, the editor changed the formatting; may be because 'table' originally was in monospaced (iMac) Monaco font. I have left it as it pasted in.
Propeller, gen.2 info - rev: 8 Jul.2007 Feature Quantity comments Forum pg/date/time --------------+-------------------+-----------------------------------+------------------ Cogs 16 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 pg19/28Jun07/9:26a pg20/4Jul07/7:18p --------------+-------------------+-----------------------------------+------------------ Memory RAM=256KB on-chip pg17/24May07/11:12a ROM=128K pg20/4Jul07/8:36p pg20/4Jul07/7:18p --------------+-------------------+-----------------------------------+------------------ I/Os 64 pg17/24May07/12:50p --------------+-------------------+-----------------------------------+------------------ Clock input min - max freq ? --------------+-------------------+-----------------------------------+------------------ PLL speed 160 MHz max --------------+-------------------+-----------------------------------+------------------ Packaging QFP preferred pg19/19Jun07/6:03p QFN ? LQFP ? BGA ? thru-hole DIP NO ? --------------+-------------------+-----------------------------------+------------------ Other pins 3.3v (I/O) 4 ? 64 I/Os plus these totals 80 pins pg2/25Nov06/11:26a 1.8v (I/O) 4 ? Gnd 4 ? Rst/ 1 BOE/ 1 ? Clock 2 --------------+-------------------+-----------------------------------+------------------ 16x16 multiply 1 ? pg19/23Jun07/3:59p --------------+-------------------+-----------------------------------+------------------ Dev Sys onchip 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 --------------+-------------------+-----------------------------------+------------------ legend: '?' = not yet defined by Parallax Beau Schwabe - IC layout engineer, Parallax pg15/7Mar07/9:53p▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
It would be excellent to have functions for creating on-screen(vga etc) widgets like tabs, buttons,sliders,text,simple graphics(gif),etc.
Each widget could have associated event handlers to pick up on keyboard and mouse input.
Since this would be needed for a development system anyway, why not make them available for general use?
Something approaching the functionality of this would be great.
www.amulettechnologies.com
The 84 pin package would be needed to bring out all 64 I/O, that's a big package! Or maybe a 68 pin package with a slightly reduced I/O count would be a better config with PLCC.
Actually, this idea could extend down to using a 32 pin QFP/24 pin skinnyDIP or something like that for cheaper/smaller options. Still using the same die with all 64 I/O internally available for IPC.
Evan
At this point, making the Hub's round robin indexing engine smarter might be in order also.
Please elaborate ...
Regards,
QuattroRS4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Something like, index = encoder - index
Evan
Needs to have a barrel shifter of the pending bits, rotated by the index register value. The output of this shifter can then be priority encoded and added back to the index.
Evan
United States Patent 20070089112
An apparatus for selecting one of N requestors of a shared resource in a round-robin fashion is disclosed. One or more of the N requesters may be disabled from being selected in a selection cycle. The apparatus includes a first input that receives a first value specifying which of the N requesters was last selected. A second input receives a second value specifying which of the N requesters is enabled to be selected. A barrel incrementer, coupled to receive the first and second inputs, 1-bit left-rotatively increments the second value by the first value to generate a sum. Combinational logic, coupled to the barrel incrementer, generates a third value specifying which of the N requesters is selected next.
Regards,
··········· QuattroRS4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 7/28/2007 5:25:58 PM GMT
Eg: Setup 6 of the 8 Cogs doing hardware like functions where they only access Hub memory to update it when the I/O conditions dictate. Leaving the remaining two Cogs to alternate say 90% of the Hub slices between them.
Admittedly, this means variable results for main memory bandwidth from an individual Cog's pov.
I mean that is really basic stuff - One shift, one encode, and one add.
Evan
Yip - it's the way of the world as we know it !
Regards,
QuattroRS4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Yes, it's a trade-off between determinism and maxing out the MIPS. I'd guess for most scenarios that you'd use a propeller for, predictable response is more important than maximum throughput.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Is there a T-shirt with a red heart and a propeller on it? I think that I would look good in one
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
So we are talking about a 16 cogger with somewhere between 160MB/Second bandwidth for each cog all the way up to possibly up to 640MB/Sec/cog
Very Cool, Lots of Cogs and bandwidth too.
Any final word on Hub Memory Size? 128K? 256K? 512K?
How about booting. For a quick boot is there the option to just load to the end of the program size, not the whole eeprom?
Now I an see the demo boards for this thing are going to have DVI connectors, 100BaseT, 6 Channel audio, USB 2.0 etc!
And with 64 pins, strapping on an extra couple of megabytes of ram shouldn't be too tough!
With that kind of bandwidth, maybe I could do a SCSI to MicroSD raid controller!
I hope that they implement it, perhaps also support Png's Jpegs' and TNG's. So that you can browse the internet without seeing X's on all those images.
But, I doubt that the demoboards are gonna have ALL that. But hopefully they will at least have the DVI connection and·a USB hardrive for storage incase of large programs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
How many blowable fuses will be present?
What's the real reason why we can't be treated to a Propeller with FLASH in lieu of that EEPROM?· If it's "the process", then why can't that be changed?· It does seem kinda silly that Parallax is of the opinion that dedicated peripherals is wasted silicon, yet all my precious non-volatile storage is being wasted on dedicated tables.· That being said, I enjoy working with it. [noparse]:D[/noparse]
Ready to be flamed.
The real reason we can't have on-chip flash memory is exactly what has been stated. The manufacturing process used for the chip cannot create the proper structures for flash memory. I suspect that it can't be changed because the tradeoffs in choosing a process would markedly increase the cost of the chip or require that some of the functionality be dropped.
You may think it was silly to give up dedicated peripherals, but it was a well thought out design decision to not have dedicated peripherals and to use general purpose processors to implement any dedicated functions. You may not like it, but it was not lightly chosen. Designers get to make those kinds of choices.
Again, it was not an option to have flash memory on-chip. On the other hand, ROM is made using the same kinds of structures as the rest of the chip and a certain amount of ROM was needed for the boot loader and the Spin interpreter. The dedicated tables are of two kinds: 1) font tables; 2) transcendental tables. The first goes with the other video-friendly features. The second has been a built-in feature of the Stamps since the beginning and is useful in robots and sensor processing. ROM is pretty cheap in terms of chip area, so, once some ROM had to be included, 32K was the next useful size boundary. What would you have put in there that would have been available early in the chip development?
·
I think, particularly if you start with the tutorials from the Propeller Education Kit, that you can learn Spin fairly quickly, particularly starting with the examples that are close to what you need for your project. You could also use something like FemtoBasic which is a very simple interpreted Basic, but does allow access to the I/O pins and to the counters used for frequency synthesis.
I don't think you'll see anything like PBasic any time soon. What resources are available at Parallax are best spent in development of teaching tools (texts, tutorials, further well documented examples) for Spin and assembly, let alone the development of future Propeller chips.
Or would something like load multiple bytes into longs be possible to add? ie read one long from hubram and put it into 4 longs in cog ram etc?
That would come in handy too. [noparse]:)[/noparse]
Just my 2p's worth.
·
This prop 2·seems·to have more than enough power to generate a 16 bit sprite engine with scaling,rotation,parallax scrolling and 3d floormapping along with tiles...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
Post Edited (Bob the Builder on a C64) : 8/1/2007 9:39:14 PM GMT