Phil, I agree about the need for faster inter-cog communications, however I respectfully disagree - the changes I proposed to the video shift registers would allow for incredible flexibility and some extremely desirable features:
- 100mbit ethernet (half duplex in one cog, full duplex in two) - hardware manchester support would be AWESOME
- 640mbit inter-propeller comm channels (so we can go with 8 cog / 256 model and use very fast spi inter-propeller
- some SD cards will talk SPI at 450mbits/sec - flash disk I/O!
- ferroram's can talk at least at 50mbits, who knows how fast they will talk later?
- using a CPLD to make a 640mbit SPI-memory bridge for fast sram, we could get ~64MB/sec memory read/write bandwidth
- high speed USB support in one cog!
Basically, as I am sure Chip would do a bang-up job of implementing it, it would allow for eight VERY high speed off-chip channels
So such a fast serial link would solve the following current issues:
- fast inter-propeller communications
- memory expansion
- "disk" space
- ethernet
- USB
- higher color depth video
Yep,·as long as transmission length was programmable (say 8..32 bits) and a "xmit complete" pulse was mappable to an I/O pin, this could also be used for a new style video output... consider shifting out a 16 bit word, strobing it into·a latch,·outputs it·to a resistor d/a ladder -> 16 bits for·VGA color!
Phil Pilgrim (PhiPi) said...
I agree with the need for better inter-cog comm support. And an unpinned port B may be all it takes. But, at 160MIPS, I'm not sure that any more is really needed in the hardware for fast serial I/O.
What I would like to see, though, are more counters that could be combined in various ways to support hardware PWM, for example. The DUTY mode is just too fast for some D/A apps, especially those requiring MOSFETs to drive an inductive load, say.
Did I miss anything important? Did I get something wrong?
After having a night to sleep on it,one important thing, to me (and I think likely Cliff and/or KaosKidd too) is the Total Cog Ram. Don't we gain some hidden benefits with having double the amount of COG ram available? Especially if COG-COG communication is faster...?
I wonder if the 8/256 would have the upper hand as far as spin execution speed per cog is concerned, due to the hub access frequency being 20Mhz instead of 10Mhz for the 16/128. with the instruction piplining I would think that speed would depend more on how fast hub ram could be accessed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've been reading this thread for the last several days , but hadn't caught whether this is still in the present 40/44 pin packages. I'm assuming so.
Hearing of increased speed, this is really good news. So far I've not run into a Memory space limit. Just the speed and number of pins; my application interfaces with some 35 TTL signals, thus two Props are being used. This '2-Prop' design is eliminating some 50+ TTL parts. And with the faster speed, possibly a 3rd prop could eliminate another 10 parts. Not enough spare pins with 2 props to do that job.
I'm still wondering if I'm reading things correctly. 160 MHz rate, single clocking of instructions?___ Would that also include the assembly WAITPEQ and WAITPNE instructions, or would they be longer?___ Only 6.25 nsec delay incurred on such instructions is very welcome?___
Wonderful to hear of 'Gen 2' Prop so soon (to us users). Am still waiting for the 64 I/O version though. Unfortunately that probably will only be available in SMD form, like 84-pins. (Not enough pins for a mentioned 68000 style DIP)
Present 8 cogs appear adequate for this application. Which ever is the fastest will be the preference here. My 2¢.
Chip mentioned the need for more than 40 pins to accomodate two power supplies (1.8V for core, 3.3V for I/O). I assume that would mean a 44 pin QFP and QFN type package since the DIP package is not realistically available in greater than 40 pin size.
Respectfully, I'm still unsure about the arguments for more memory. Cog access to shared memory will still be faster than version 1. But I submit that not enough emphasis has been placed on the multi-processor aspect of the prop - this is the key defining element of the prop and therefore requires a different way of thinking about implementing your pojects.
Multiplexing applications into single cogs, I agree would be more complex to implement and require more memory. However if you don't need to multiplex apps into single cogs, it would be simpler and require less memory. And don't forget with 16 cogs you're still getting extra memory.
OK, I'll go away now!
PS, Australia just won the first test against England! Well done boys!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ian Mitchell
www.research.utas.edu.au
8 cogs and 256K RAM for me.
I need to display photos on the TV !
Don't forget to implement internal on-chip 256K eeprom as well, with instructions to access them.
Chip, · It's a bit late in the thread, but I'd go with the 256k 8-COG option ("2" I think?).· If you decide to do a 16-COG component later, try gluing two 8-COG ICs into one package and using the "B" port·I/O bus for inter-propeller-die communication.· This will allow you to scale the internals and the utilization of the current dies without affecting the over-all silicon layout too much (economy of scale makes this option more ideal). · For inter-IC communication I'd recommend a command based communication protocol where one propeller core talks to the other's Hub RAM directly over a split parallel bus (this should allow data transfers with a low clock overhead - but currently at the expense of one COG per die, a FIFO/MUX on the memory block could relieve this).· This is roughly the method I've been toying with, and it works pretty dang fast. · Also - if you're looking at revising the package at all, I'd suggest a stand-alone 512k EEPROM IC be embedded into the package for single-IC designs (this simplifies board layouts and programming architectures...).· Just a thought. · Cheers! · -Tim
Post Edited (GreyBox Tim) : 11/27/2006 9:42:27 PM GMT
Years ago I was sweating bullets trying to write some point papers.· Then inspiration hit me in the head with a 4by4.· I went to my boss and asked, "Who am I writing this for?· Who is the target audience?"· Chip, who is the Propeller's target audience?· Professionals, hobbiests, students/educators, video game writers, industrial control??· Is the future of the propeller to replace the PIC/SX/AVR, 8086, cell?· Here is a audience of one's viewpoint.· I have no need for high resolution video or game programming.· My PC does those tasks quite sufficiently.· I started with the BASIC stamp and soon thereafter with a Sumo11 using Interactive C.· I still love the stamp and will always have one; it does many things well.· But the Stamp and Sumo11 (now sold) did not meet my needs.· I started a migration to AVRs and GNU C.· Then the Propeller came.· I think it is important and way cool that once I have something working on a cog, I can do almost anything on the other cogs and not change the behavior of the first cog.· The ability to drop in objects and make a working program was truth, beauty, and productive.· I took Beau's servo, encoder, HM55B, and H48C objects and the Float32Full objects and in very little time had a working program.· But I am already up to 7 cogs and have more to add.· I know that the HM55B and H48C objects probably could be combined and my needed parts of Float32Full combined to one cog.· That would require learning Propeller assembly.· I have tried since 1973 to avoid assembly, but it keeps comming back.· Many smart people have made suggestions to this thread.· They all represent audiences of one or more if they represent a company.· Several have suggested multitasking a cog.· I remember mention of interrupts and RTOS.· These are a step away from the elegance that first attracted me to the Propeller.
I vote for 16 cogs in the next release and more/faster hub memory in gen 3
I goto see my fiance for a week, and see what happens? A huge discussion on the next version of the Propeller. I'll reserve my opinion, I can speak to Chip directly.
In re: "I want it all": while this may happen eventually, one or the other has to come first, thats the gist of the question.
In re: "Number of I/O pins": Yes PortB will be implemented, whether an "I/O crippled" DIP version (ie only 32 I/O·pins) will be made hasn't been determined yet.·As to expanding the current architecture to implementing PortB internally, Jeff and I have talked about this extensively, there is no space on the die to route these 32 lines between the cogs in the current version and it doesnt make economic sense to alter the die and the process for this.
In re: "Cog memory/ 64 bits": The current 32 bit instruction organization leaves no extra bits to access anthing beyond 512 locations, this is the primary reason for going to a 64 bit architecture, not for the extra computation power which has been shown to only provide·a minimal increase in performance. As Chip mentioned it is possible to use a banking scheme, but it is an unappealing avenue. Also keep in mind, when you increase cog memory, you are doing it cog-fold (8 or 16 times) and it becomes "dedicated" memory that cannot be used for any other purpose than the cog that owns it.
BTX (Alberto) said...
But, are you thinking to include some of this in the future·?? (UART, SPI, I2C, A/D....etc.).
So, more RAM (256Kb hub RAM) and perhaps more than 512 longs per COG could be great, together a 512Kb eeprom included
This is the purpose of objects, all of those functions already exist in software form. See my comment about the cog memory above, the process we use does not support EEPROM, it is much more expensive to do so, and any on board EEPROM takes away real-estate, ie current version, same ram, same cogs but cogs would be faster.
Kevin Wood said...
2. PROTECT option, as the SX has
3. Implement Paul Baker's suggestions to make it more RF friendly
We've talked about protection, haven't reached a conclusion yet. It's not an easy thing to accomplish with the architecture. What suggestion did I give? This is my first post to the thread.
Power Mousey said...
and also a third option....up to 16 cogs active and with a maximum of 256k of ram. also, maybe expand the rom too.
·also how about this?: have the capability in the hardware and software of the propeller chip for sharing and using some of the cogs(other cogs) general purpose ram for some of the program code,memory for extra and fast memory and some of the code in their registers.
It's an either/or situation, both take silicon real-estate, and there's only room for one.
The architecture deliberately prevents peeking into the memory of a cog, this is done to protect the Spin interpreter from being read in it's descrambled form, to prevent competitors from copying it.
M. K. Borri said...
I would like multiply and divide as asm instructions... that's really the only request I have. [noparse]:)[/noparse]
I'm new in the group but I would like to throw my two cents.
I would vote for option 2
The increase in performance would need more RAM to make it more uselful, later if it seems desiarble go for more cogs.
I would also concur with the suggestion to add new instructions to increment or decrement pointer on access to I/O ports.
I have a development system on it's way, and can hardly wait to play with this wonderful chip.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don.Seglio
"Sacred Cows make the best Hamburger!" Don Seglio Batuna
I have a potentially interesting third alternative to propose.
Chip is planning either
a) 16 cogs / 128k hub ram, 8 cycle hub access, 160MHz, single cycle instructions
or
b) 8 cogs / 256k hub ram, 16 cycle hub access, 160MHz, single cycle instructions
Personally, I favor the larger ram variant; but while driving today, I had an interesting idea...
Note, that this may not be feasible in the current process, and it would be a bit bigger than A or B... but bear with me for a moment.
We all want more memory.
We all feel a bit guilty sometimes dedicating a cog to read a PS/2 keyboard.
What about an alternate?
I am thinking of the following - and Chip, PLEASE pipe up, because this may easily be unfeasible; but if it is feasible... oh my, the possibilities (especially if combined with my suggestions for a super-shift register <grin>)
- 8 fast cogs, pipelined, effective 160MPIS
- 4 hyperthreaded cogs; instead of pipelining one instruction stream... alternate between "virtual" cogs. Each of the "slow" cogs would run four threads at "only" 40MIPS each; and the "slow" cogs would only get one slice to share... so with 12 slots on the "rotor", the "fast" 160MIPS cogs would get 1 cycle in 12, that is 13.3M hub accesses each per second (up from 5 in the current propeller).
The slow "hyperthreaded" cogs would get 13.3M/4 = 3.3M hub cycles per second - but that is PLENTY fast enough for keyboards, mice, and most real-world I/O.
This would lead to a VERY interesting architecture...
8 x 160MIPS cogs w/ 53.3MB/sec bandwidth to hub memory each
16x 40MIPS cogs w/ 13.3MB/sec bandwidth to hub memory each.
If its a matter of chip realestate, the "hyperthreaded" cogs could be limited to 128 to 256 longs each, possibly sharing some longs after the "private" cog memory.
This scheme would give us close to 2BOP's, and it would give us 24 cores - 8 fast, 16 "slow" to run programs on.
Oh - and the "slow" cores would be 2x the speed of the current cogs.
as for the hub memory, I see a scheme like
s C C s
C H C
C C
s C C s
ie the "shared" cogs are equally spaced.
Just think... far less guilt in using 1/4 of a hyperthreaded cog for a PS/2 keyboard [noparse]:)[/noparse]
Single cycle multiply, yes; divide, no WOW !
I thought a multplyer uses a lot of realestate and would not be in any cogs, or perhaps one or two gogs, or only in the hub.
What about a 2 sided propeller ? (top and bottom of the same chip) ?
Or a 2nd chip with diferent processes for flash mram ETC. stacked on top of the propellor chip ?
Phillip,
I believe 2 sided chips are very expensive to make and stacking chips (or multiple chips in a package) is also very expensive.
Paul,
Interesting (and makes sense) about deliberately preventing access to cog memory to protect intellectual property. It does make it harder to do interprocess (intercog) communication, but speeding up hub memory access does help a lot there. The biggest problem in making good use of the hub memory will be SPIN related. SPIN as currently constituted, doesn't "play nice" in terms of multiple uses of memory. It can be made to do so, but it doesn't come naturally. Hopefully, by the time the new chip comes out, the firmware (boot loader, SPIN interpreter, etc.) will be friendlier to multiple SPIN and assembly (and hyperthreaded) code pieces.
Don't forget to allow each cog to select it's own speed multiplier.
It's a little crazy to use a 160 Mhz cog to read a PS/2 keyboard or to send 1200bps serial data.
If a cog selects 32x multiplier, it has the usual access to the main memory.
If a cog selects 16x multiplier, it's access to main memory is reduced to half the number of cycles and so on.
About the IC packaging, I think a PLCC version at either 68 or 84 pins would be good for us hobbyists, you can always buy a PLCC socket with a through-hole PCB interface (at about $ 1.00 online) or the Surface Mount Socket for about $ 1.15 .. although the Through-hole option is less intimidating when it comes to soldering, accurately drilling 68 or 84 holes in such a tiny space is difficult, requires a precise and compact drilling tool and a plastic surgeon's steady hand… soo… my vote goes to Surface Mount Socket, it requires no drilling and the PCB layout is simpler. The Catch: you require a steady hand, a good magnifying glass, and a normal soldering tip won't work, it is too big for Surface Mount.. you can get a micro tip for surface mount soldering, or, if you cannot afford it (my case) then cut the lead of a new low wattage resistor (it has to be as long as you can) wrap it around a screw with a similar diameter as the soldering tip, then remove the tip and replace it with the screw/lead combo, it makes for a barely decent micro tip (you need to constantly clean it with flux)… .flux utilization in the soldering process is important.
If you are adventurous enough you can solder the PLCC IC directly on the surface of the PCB….
Just my two cents…
Post Edited (Joe "Bot" Red) : 11/28/2006 3:51:25 PM GMT
I was initially swayed by the idea of 8 cogs/256 ram but upon reflection I think that 16 cogs are a better way to go. It would still offer improvements in all areas. People can still multitask and condense code onto single cogs (especially if they feel efficiency guilt [noparse]:)[/noparse]), but those who prefer to keep things simple will have extra cogs to use. A 16 cog version better supports the whole idea of developing libraries of cog independent objects. For applications where time is money it is more efficient to have the costs go into having more cogs rather than developing more complex software or needing to interface 2 physical chips. It sounds like the need for memory above what the 16 would offer is not necessarily that much with the exception of games and complex language support. As was asked, what is the target market for most of these chips?
I think some are initially put off by seeing the hub access times drop to 16 cycles but the truth is it is still faster than current prop in terms of actual time and there is more of it. As for making use of the cycles in between accesses there are plenty of apps where hub ram isn't necessarily the issue.
Also much has been made of the need for RAM for video and games, etc., but (in addition to the RAM increase) more cogs offers more options for modifying that memory as well as interfacing to external memory.
I vote for the 16 cog model simply because I think it is more flexible and more in keeping with the theme of the propeller (multi processing). Certainly the increased raw performance of the 8 cog boost is nice but I see that as simply supporting more complex software rather than more applications (i.e. uses).
One thing to think about as far as roadmaps is what happens if you continue to add cogs and further "distance" them from hub memory? At what point do you cross from cogs on a hub to multiple props interfaced or on the same die? If you go with an 8 cog design then I wonder if you'll ever cross over to a 16 because of the installed base being used to the "timing" of 8. If you ever want to really do 16 or more cogs on a single hub (as opposed to connecting multiple props as mentioned) I would say do it now and tackle the issues before resistance to it gets too big. Going with 16 will reinforce the ideas behind SPIN objects, etc. while still leaving open the same development doors that currently exist. Going with a super 8 might cause the software side to veer to custom solutions and neglect SPIN.
I also vote for Bill's ideas if they will indeed allow the prop to do ethernet, etc. without extra chips. Again this will increase the potential applications of the prop.
Also please forgive me if I have made some faulty assumptions or something. I am new to the prop [noparse]:)[/noparse].
I think on balance the FIRST one should be the 8 cog more ram one. You can do lots with 8 cogs anyway but it will make things that involve graphics and video processing etc easier.
My wish list based on what I think and what some· customers have told me ..
8· cogs with more· RAM· + faster sounds good.
Implement a simple bit sharing scheme on the B port since we have 8 COGS allow each Cog to write ie set/reset 4 bits in the B port ie COG 1 has access to bits 0..3·· COG 2 has access to bits 4...7 and so on· this would allow lightning fast syncing /triggering/starting/stopping ·of other COGS..
How hard would it be to make hub ram dual-ported?· I could see two nice options for this.· With a 16-cog prop it "should" enable clk/8 access to hub ram, although this adds the possability of cog's clobering eachother's memory access.· My second idea is make the second hub ram port a "DMA" port that can be grabbed by any cog to quickly swap sections of cog-ram into or out of hub-ram.·
I vote for all the upgrades to the counters suggested so far.·(allowing them to use hub read/writes as a clock source in addition to the system clock is a really cool idea) ·I'd also like to see a way to internally link CtrA and CtrB without having to use a pin.· (say for a "burst" clock that spits out 16 clock cycles at clk/8 Hz when "kicked")· Modifying the Tv hardware to act as a half-duplex SPI hardware as suggested before is an exciting idea.·
I think the best way to do Inter-cog communications would be with a set of Left/Right registers.· (I.e. a left read and write register and a right read and write register)· This is·a system used by other multi-multi-core chips.· (the Cell chip and SEAfourth24 that i know of)· This type of communication scales well.· And while it forces communicating cogs live next to each other it makes it impossable for another cog to accidently screw up communications.
Hyperthreading cogs is an interesting proposition.· I think a better solution would be to move this functionality up into the SPIN interpreter.· With the massive speed boost of the Propellar II, a single cog should be able to run several independant SPIN programs at once·each with the same speed·as the current propellar·running one SPIN program on a single cog.·
Bill Henning said...
I have a potentially interesting third alternative to propose.
...
FWIW, I believe the KEY concept of the propeller is that all the COGs are IDENTICAL. Not some have h/w multiply, some dont. Some have hyperthreading, some dont. I think they all run off the same clock too, so each cog is always the same speed.
The key to the prop is 8 Cogs, any/all of which can be effectively made a SPI port, a I2C port, a PWM driver, PS/2 Keyboard, PS/2 mouse or whatever.
Can't your hyperthreading idea be 'easily' implemented via the 'large memory model' coding scheme?
Personally, I would rather have the 16 Cogs. That way I can keep the s/w as simple as possible. So what if you dedicate a whole cog to a ps/2 keyboard? My dad worries about his hard drive has 18gig used. So what, he's still got 40gig free. Worry about diskspace when you get down to 2gig free. Worry about using a cog for a keyboard when you need that extra cog to get the project out the door.
With the 16 cog option, I still have a lot more hub ram, with faster access. And I have many more 'soft' perpherials on the chip. With and AVR or PIC, I need to pick different chip models for each project based on the requirements. 1 project might need 3 ADC ports, while another needs 4 pwm counters. So I end up picking different AVR/PIC chips for each project.
With the Prop, I 'make' my own perpherals via software. How cool is that. Use the same chip over and over for different projects.
The more cogs I have, the more customized I can 'make' my prop. 16 cogs = 1 processor + 15 perpherals.
I'd rather have 8 extra cogs I don't use, than need 1 extra I don't have.
Wow! You all have lots of good ideas. It seems that many of you already have a very thorough grasp of the current Propeller.
I have a question to ask you all:
Which would you rather have:
a) 350uA quiescent current with 160MHz operation (as planned)
b) 1400uA quiescent current, but with 200MHz operation (lower Vt transistors for faster operation, but more leakage).
In 0.18um process technology, there is going to be much greater leakage than there is in the current 0.35um process. Would it be worth it to·suffer·another 3x increase in leakage for 25% more performance? What do you think?
P.S. The current Propeller's leakage is only 600nA, which makes it viable for battery-powered, always-on applications. A 0.18um chip, in any case, will waste a lot of juice just by being powered up, even if there is no toggling.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/29/2006 5:31:35 AM GMT
That's a 4x increase in current for a 1.25x increase in performance... I'd rather have the first option honestly... this thing is mighty fast as it is, and just adding one-cycle multiplication makes a hell of a difference as well.
Right now my AI abortion runs for about 8 hours on C cells while driving two standard servos and powering a gps module, about 12 hours by itself... honestly thought the Prop ate up more current than that, cool!
Comments
- 100mbit ethernet (half duplex in one cog, full duplex in two) - hardware manchester support would be AWESOME
- 640mbit inter-propeller comm channels (so we can go with 8 cog / 256 model and use very fast spi inter-propeller
- some SD cards will talk SPI at 450mbits/sec - flash disk I/O!
- ferroram's can talk at least at 50mbits, who knows how fast they will talk later?
- using a CPLD to make a 640mbit SPI-memory bridge for fast sram, we could get ~64MB/sec memory read/write bandwidth
- high speed USB support in one cog!
Basically, as I am sure Chip would do a bang-up job of implementing it, it would allow for eight VERY high speed off-chip channels
So such a fast serial link would solve the following current issues:
- fast inter-propeller communications
- memory expansion
- "disk" space
- ethernet
- USB
- higher color depth video
Yep,·as long as transmission length was programmable (say 8..32 bits) and a "xmit complete" pulse was mappable to an I/O pin, this could also be used for a new style video output... consider shifting out a 16 bit word, strobing it into·a latch,·outputs it·to a resistor d/a ladder -> 16 bits for·VGA color!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
Hearing of increased speed, this is really good news. So far I've not run into a Memory space limit. Just the speed and number of pins; my application interfaces with some 35 TTL signals, thus two Props are being used. This '2-Prop' design is eliminating some 50+ TTL parts. And with the faster speed, possibly a 3rd prop could eliminate another 10 parts. Not enough spare pins with 2 props to do that job.
I'm still wondering if I'm reading things correctly. 160 MHz rate, single clocking of instructions?___ Would that also include the assembly WAITPEQ and WAITPNE instructions, or would they be longer?___ Only 6.25 nsec delay incurred on such instructions is very welcome?___
Wonderful to hear of 'Gen 2' Prop so soon (to us users).
Present 8 cogs appear adequate for this application. Which ever is the fastest will be the preference here. My 2¢.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Multiplexing applications into single cogs, I agree would be more complex to implement and require more memory. However if you don't need to multiplex apps into single cogs, it would be simpler and require less memory. And don't forget with 16 cogs you're still getting extra memory.
OK, I'll go away now!
PS, Australia just won the first test against England! Well done boys!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ian Mitchell
www.research.utas.edu.au
Post Edited (IanM) : 11/27/2006 1:36:36 AM GMT
I need to display photos on the TV !
Don't forget to implement internal on-chip 256K eeprom as well, with instructions to access them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
·
It's a bit late in the thread, but I'd go with the 256k 8-COG option ("2" I think?).· If you decide to do a 16-COG component later, try gluing two 8-COG ICs into one package and using the "B" port·I/O bus for inter-propeller-die communication.· This will allow you to scale the internals and the utilization of the current dies without affecting the over-all silicon layout too much (economy of scale makes this option more ideal).
·
For inter-IC communication I'd recommend a command based communication protocol where one propeller core talks to the other's Hub RAM directly over a split parallel bus (this should allow data transfers with a low clock overhead - but currently at the expense of one COG per die, a FIFO/MUX on the memory block could relieve this).· This is roughly the method I've been toying with, and it works pretty dang fast.
·
Also - if you're looking at revising the package at all, I'd suggest a stand-alone 512k EEPROM IC be embedded into the package for single-IC designs (this simplifies board layouts and programming architectures...).· Just a thought.
·
Cheers!
·
-Tim
Post Edited (GreyBox Tim) : 11/27/2006 9:42:27 PM GMT
I vote for 16 cogs in the next release and more/faster hub memory in gen 3
In re: "I want it all": while this may happen eventually, one or the other has to come first, thats the gist of the question.
In re: "Number of I/O pins": Yes PortB will be implemented, whether an "I/O crippled" DIP version (ie only 32 I/O·pins) will be made hasn't been determined yet.·As to expanding the current architecture to implementing PortB internally, Jeff and I have talked about this extensively, there is no space on the die to route these 32 lines between the cogs in the current version and it doesnt make economic sense to alter the die and the process for this.
In re: "Cog memory/ 64 bits": The current 32 bit instruction organization leaves no extra bits to access anthing beyond 512 locations, this is the primary reason for going to a 64 bit architecture, not for the extra computation power which has been shown to only provide·a minimal increase in performance. As Chip mentioned it is possible to use a banking scheme, but it is an unappealing avenue. Also keep in mind, when you increase cog memory, you are doing it cog-fold (8 or 16 times) and it becomes "dedicated" memory that cannot be used for any other purpose than the cog that owns it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I would vote for option 2
The increase in performance would need more RAM to make it more uselful, later if it seems desiarble go for more cogs.
I would also concur with the suggestion to add new instructions to increment or decrement pointer on access to I/O ports.
I have a development system on it's way, and can hardly wait to play with this wonderful chip.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don.Seglio
"Sacred Cows make the best Hamburger!" Don Seglio Batuna
Chip is planning either
a) 16 cogs / 128k hub ram, 8 cycle hub access, 160MHz, single cycle instructions
or
b) 8 cogs / 256k hub ram, 16 cycle hub access, 160MHz, single cycle instructions
Personally, I favor the larger ram variant; but while driving today, I had an interesting idea...
Note, that this may not be feasible in the current process, and it would be a bit bigger than A or B... but bear with me for a moment.
We all want more memory.
We all feel a bit guilty sometimes dedicating a cog to read a PS/2 keyboard.
What about an alternate?
I am thinking of the following - and Chip, PLEASE pipe up, because this may easily be unfeasible; but if it is feasible... oh my, the possibilities (especially if combined with my suggestions for a super-shift register <grin>)
- 8 fast cogs, pipelined, effective 160MPIS
- 4 hyperthreaded cogs; instead of pipelining one instruction stream... alternate between "virtual" cogs. Each of the "slow" cogs would run four threads at "only" 40MIPS each; and the "slow" cogs would only get one slice to share... so with 12 slots on the "rotor", the "fast" 160MIPS cogs would get 1 cycle in 12, that is 13.3M hub accesses each per second (up from 5 in the current propeller).
The slow "hyperthreaded" cogs would get 13.3M/4 = 3.3M hub cycles per second - but that is PLENTY fast enough for keyboards, mice, and most real-world I/O.
This would lead to a VERY interesting architecture...
8 x 160MIPS cogs w/ 53.3MB/sec bandwidth to hub memory each
16x 40MIPS cogs w/ 13.3MB/sec bandwidth to hub memory each.
If its a matter of chip realestate, the "hyperthreaded" cogs could be limited to 128 to 256 longs each, possibly sharing some longs after the "private" cog memory.
This scheme would give us close to 2BOP's, and it would give us 24 cores - 8 fast, 16 "slow" to run programs on.
Oh - and the "slow" cores would be 2x the speed of the current cogs.
as for the hub memory, I see a scheme like
s C C s
C H C
C C
s C C s
ie the "shared" cogs are equally spaced.
Just think... far less guilt in using 1/4 of a hyperthreaded cog for a PS/2 keyboard [noparse]:)[/noparse]
I thought a multplyer uses a lot of realestate and would not be in any cogs, or perhaps one or two gogs, or only in the hub.
What about a 2 sided propeller ? (top and bottom of the same chip) ?
Or a 2nd chip with diferent processes for flash mram ETC. stacked on top of the propellor chip ?
I believe 2 sided chips are very expensive to make and stacking chips (or multiple chips in a package) is also very expensive.
Paul,
Interesting (and makes sense) about deliberately preventing access to cog memory to protect intellectual property. It does make it harder to do interprocess (intercog) communication, but speeding up hub memory access does help a lot there. The biggest problem in making good use of the hub memory will be SPIN related. SPIN as currently constituted, doesn't "play nice" in terms of multiple uses of memory. It can be made to do so, but it doesn't come naturally. Hopefully, by the time the new chip comes out, the firmware (boot loader, SPIN interpreter, etc.) will be friendlier to multiple SPIN and assembly (and hyperthreaded) code pieces.
If you guys could the Propeller more RF friendly based on the concerns in the following thread, that would be great:
http://forums.parallax.com/showthread.php?p=583301
It's a little crazy to use a 160 Mhz cog to read a PS/2 keyboard or to send 1200bps serial data.
If a cog selects 32x multiplier, it has the usual access to the main memory.
If a cog selects 16x multiplier, it's access to main memory is reduced to half the number of cycles and so on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
If you are adventurous enough you can solder the PLCC IC directly on the surface of the PCB….
Just my two cents…
Post Edited (Joe "Bot" Red) : 11/28/2006 3:51:25 PM GMT
I think some are initially put off by seeing the hub access times drop to 16 cycles but the truth is it is still faster than current prop in terms of actual time and there is more of it. As for making use of the cycles in between accesses there are plenty of apps where hub ram isn't necessarily the issue.
Also much has been made of the need for RAM for video and games, etc., but (in addition to the RAM increase) more cogs offers more options for modifying that memory as well as interfacing to external memory.
I vote for the 16 cog model simply because I think it is more flexible and more in keeping with the theme of the propeller (multi processing). Certainly the increased raw performance of the 8 cog boost is nice but I see that as simply supporting more complex software rather than more applications (i.e. uses).
One thing to think about as far as roadmaps is what happens if you continue to add cogs and further "distance" them from hub memory? At what point do you cross from cogs on a hub to multiple props interfaced or on the same die? If you go with an 8 cog design then I wonder if you'll ever cross over to a 16 because of the installed base being used to the "timing" of 8. If you ever want to really do 16 or more cogs on a single hub (as opposed to connecting multiple props as mentioned) I would say do it now and tackle the issues before resistance to it gets too big. Going with 16 will reinforce the ideas behind SPIN objects, etc. while still leaving open the same development doors that currently exist. Going with a super 8 might cause the software side to veer to custom solutions and neglect SPIN.
I also vote for Bill's ideas if they will indeed allow the prop to do ethernet, etc. without extra chips. Again this will increase the potential applications of the prop.
Also please forgive me if I have made some faulty assumptions or something. I am new to the prop [noparse]:)[/noparse].
Graham
My wish list based on what I think and what some· customers have told me ..
8· cogs with more· RAM· + faster sounds good.
Implement a simple bit sharing scheme on the B port since we have 8 COGS allow each Cog to write ie set/reset 4 bits in the B port ie COG 1 has access to bits 0..3·· COG 2 has access to bits 4...7 and so on· this would allow lightning fast syncing /triggering/starting/stopping ·of other COGS..
Protection please Protection Please Protection Please Protection Please..
Enhance the counter register capability by adding· A B quadrature encoding in hardware.
Did I mention protection ( + build in eeprom )
cheers·
Ronald Nollet
Parallax Australia distributor
Forgot to add that alot of customers ask for a C Compiler as well..
Did I mention Protection ?
Ronald Nollet
I vote for all the upgrades to the counters suggested so far.·(allowing them to use hub read/writes as a clock source in addition to the system clock is a really cool idea) ·I'd also like to see a way to internally link CtrA and CtrB without having to use a pin.· (say for a "burst" clock that spits out 16 clock cycles at clk/8 Hz when "kicked")· Modifying the Tv hardware to act as a half-duplex SPI hardware as suggested before is an exciting idea.·
I think the best way to do Inter-cog communications would be with a set of Left/Right registers.· (I.e. a left read and write register and a right read and write register)· This is·a system used by other multi-multi-core chips.· (the Cell chip and SEAfourth24 that i know of)· This type of communication scales well.· And while it forces communicating cogs live next to each other it makes it impossable for another cog to accidently screw up communications.
Hyperthreading cogs is an interesting proposition.· I think a better solution would be to move this functionality up into the SPIN interpreter.· With the massive speed boost of the Propellar II, a single cog should be able to run several independant SPIN programs at once·each with the same speed·as the current propellar·running one SPIN program on a single cog.·
My 2 cents,
Marty Lawson
FWIW, I believe the KEY concept of the propeller is that all the COGs are IDENTICAL. Not some have h/w multiply, some dont. Some have hyperthreading, some dont. I think they all run off the same clock too, so each cog is always the same speed.
The key to the prop is 8 Cogs, any/all of which can be effectively made a SPI port, a I2C port, a PWM driver, PS/2 Keyboard, PS/2 mouse or whatever.
Can't your hyperthreading idea be 'easily' implemented via the 'large memory model' coding scheme?
Personally, I would rather have the 16 Cogs. That way I can keep the s/w as simple as possible. So what if you dedicate a whole cog to a ps/2 keyboard? My dad worries about his hard drive has 18gig used. So what, he's still got 40gig free. Worry about diskspace when you get down to 2gig free. Worry about using a cog for a keyboard when you need that extra cog to get the project out the door.
With the 16 cog option, I still have a lot more hub ram, with faster access. And I have many more 'soft' perpherials on the chip. With and AVR or PIC, I need to pick different chip models for each project based on the requirements. 1 project might need 3 ADC ports, while another needs 4 pwm counters. So I end up picking different AVR/PIC chips for each project.
With the Prop, I 'make' my own perpherals via software. How cool is that. Use the same chip over and over for different projects.
The more cogs I have, the more customized I can 'make' my prop. 16 cogs = 1 processor + 15 perpherals.
I'd rather have 8 extra cogs I don't use, than need 1 extra I don't have.
<end rant>
Seth
I have a question to ask you all:
Which would you rather have:
a) 350uA quiescent current with 160MHz operation (as planned)
b) 1400uA quiescent current, but with 200MHz operation (lower Vt transistors for faster operation, but more leakage).
In 0.18um process technology, there is going to be much greater leakage than there is in the current 0.35um process. Would it be worth it to·suffer·another 3x increase in leakage for 25% more performance? What do you think?
P.S. The current Propeller's leakage is only 600nA, which makes it viable for battery-powered, always-on applications. A 0.18um chip, in any case, will waste a lot of juice just by being powered up, even if there is no toggling.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/29/2006 5:31:35 AM GMT
Right now my AI abortion runs for about 8 hours on C cells while driving two standard servos and powering a gps module, about 12 hours by itself... honestly thought the Prop ate up more current than that, cool!