What would you want more of, cogs or RAM?
cgracey
Posts: 14,258
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/25/2006 6:16:55 AM GMT
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/25/2006 6:16:55 AM GMT
Comments
Andre'
This is because I feel that with more than 8 cogs, you can make some very impressive embedded systems!
I know that I would love to be able to make system that can use multiple vga monitors, a keyboard, mouse and other interface nonsence.· The extra cogs would let you run multiple vga's at higher resolutions and have enough cogs left to support the other stuff.· More I/O pins would rock as well...because at 8 pins per vga hookup, the current Propeller can only support 4 monitors maximum - and that is using every pin possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
while alive = 1
wakeup
program(propeller)
eat(3)
sleep(7)
Before I can intelligently decide which way to vote, I'd like to know how many cycles the hub instructions will take...
Also, I'm guessing you are targeting 160MHz... correct?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
16 cogs please with 128k!
Are you also adding more ROM space?
Plus the enhancements to the video shift registers and timers I suggested earlier, and the I/O strobes.
oohhh the things we will be able to do!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Chip....
Are you going to stay in a 40 pin dip package, or going to say plcc 84 to get the 'port b' on-line? Having both choices would be good; and it could be a packaging option.
If you are going 84 pin, we can get the port strobes without sacrificing general purpose I/O pins!!!!!!
are branches still going to take effectively one clock if taken / two if not?
If you need more cycles, how about adding delay slots, so that we can use the otherwise wasted cycles?
Before I consider the ramifications of each: 'still 512 longs per cog, right?
Thanks,
Phil
Ian.
Chip Gracey
Parallax, Inc.
Consider tight loops... once sync'ed to the hub "rotor", if I understand your intentions...
tightloop rdbyte b, ptr ' 2 cycles
' WE HAVE ROOM FOR 13 INSTRUCTIONS!!!!!!
' FANCY VM's here we come!!!!
' FANCY VGA MODES TOO!!!
djnz somecount, #tightloop ' 1 cycle when taken
SPIN/FORTH/large model·etc simple primitives could execute at 10MIPS (160MHz/16 clocks per hub access)
think of the fancy video drivers... "real" sprites become possible!
Post Edited (Bill Henning) : 11/25/2006 8:07:52 AM GMT
16 cogs * 160 mips = 2,560 mips = 2.56bips!
But, build the larger RAM model first. If the current speed / RAM limitation holds, and I think it will, then we will once again be struggling with on-chip RAM.
One of the biggest strengths is the all in one chip approach. Larger RAM space = more one chip applications.
The higher speed HUB access means faster big mem code. That tells me one COG could do a lot of things that do not require the highest speeds as well. We would end up getting a lot more per COG.
Post Edited (potatohead) : 11/25/2006 8:14:08 AM GMT
In that case, I'd say eight cogs with more RAM. My reasoning is this: Current programs that use close to eight cogs usually have some sort of interleaving going on -- similarly-programmed cogs taking turns (for performance reasons) doing the same thing. But 160 MIPS addresses the speed issue quite handily, freeing these cogs for other, more independent tasks. So, with better-optimized speed and cog usage, the resource limitation that will be most keenly felt is cog RAM. Therefore, hub access speed becomes paramount for overlay swapping and the like. And the eight-cog option delivers hub access at double the rate of the 16-cog option.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
0· 1· 2· 3· 4· 5· 6· 7· 8· 9· 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
A (1:4)···· A·········· A·········· A·········· A·········· A·········· A·········· A
·· A·········· A·········· A·········· A·········· A·········· A·········· A·········· A
····· A·········· A·········· A·········· A·········· A·········· A·········· A·········· A
········ A·········· A·········· A·········· A·········· A·········· A·········· A·········· A
B (1:8)················ B······················ B······················ B
·· B······················ B······················ B······················ B
····· B······················ B······················ B······················ B
········ B······················ B······················ B······················ B
··········· B······················ B······················ B······················ B
·············· B······················ B······················ B······················ B
················· B······················ B······················ B······················ B
···················· B······················ B······················ B······················ B
C (1:16)······································· C
·· C·············································· C
····· C·············································· C
········ C·············································· C
··········· C·············································· C
·············· C·············································· C
················· C·············································· C
···················· C·············································· C
······················· C·············································· C
·························· C·············································· C
····························· C·············································· C
································ C·············································· C
··································· C·············································· C
······································ C·············································· C
········································· C·············································· C
············································ C·············································· C
D (1:32)······································
·· D···········································
····· D········································
········ D·····································
··········· D··································
·············· D·······························
················· D····························
···················· D·························
······················· D······················
·························· D···················
····························· D················
································ D·············
··································· D··········
······································ D·······
········································· D····
············································ D·
··············································· D·
·················································· D·
····················································· D·
························································ D·
··························································· D·
······························································ D·
································································· D·
···································································· D·
······································································· D·
·········································································· D·
············································································· D·
················································································ D·
··················································································· D·
······················································································ D·
························································································· D·
···························································································· D·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/25/2006 9:40:30 AM GMT
It would also be good for games. Games need space to store graphics, sounds, etc. With more RAM you could do more than 4 colors per tile, higher resolutions, and 2 video pages. And how about bigger maps for real time strategy games?
I think we're going to be hitting the memory limitations faster than the speed limitations. If you have a lot of RAM but fewer processors, you can use some of that memory to make more memory hungry but faster algorithms to conserve processing power. (For example, using memory to store indexes for faster searches.) But, if you have a lot of processors and little RAM, once you run out of space, that's it, that's all there is. Then you have to try to squeeze bytes here and there, and you have to stop adding new features to the program.
Not to cast stones but I think the people who want 16 cogs and less memory are reacting more from the emotional attraction of the idea than the concrete benefits vs. more RAM. You can use two Props to get 16 cogs if you need to manage that many independent processes but using 2 cogs (edit: I mean props) to get double the RAM doesn't work out so well because you can't share the RAM across them.
The multiple cogs are just one of the things that makes the Propeller revolutionary. The "secret sauce" of the current propeller is not just the cogs, it's both the cogs and the generous amount of RAM, so increasing either is great.
But having 64 I/O pins will be wonderful. How will you get that into a DIP package? Can you use the "giant" 64 pin DIP package like the Motorola 68000 used? Because I have a lot of sockets for those chips!
Post Edited (Dennis Ferron) : 11/25/2006 9:28:37 AM GMT
For he 16 cog / 128k case:·· The cycles would not be wasted on very CISCy vm's, and each cog would still get twice the HUB bandwidth cogs get now - and there would be 16 cogs...
on the other hand...
Chip, I'd be curious to see how many cog's you'd need to do the tiled 1280x1024 vga mode with both approaches, compared to the current approach.
Also, I have an idea for another video mode.
4 bits per pixel
instead of passing in a long with the four six bit color lookup values, the long is used as the base address of a 16 entry color lookup table in cog memory (or dare·I dream... a 256 entry LUT in hub space?)
Producing multiple versions would need·volumes·to·ramp up steeply. The·overhead cost for a version, especially the masks for the stepper (you need 25-30 of them for a version!) are significant in·submicron processes..
Nico Hattink
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/25/2006 10:01:22 AM GMT
Jim C
By the way, do you have any plan for a future (even distant) extension of the COG's space ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yes, but it would be a 64-bit version with up to 64K longs per cog. This would be best for 90nm or smaller technology.
The only way we could augment the current architecture's cog RAM would be to have switchable banks, say in the $000-$0FF region.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 7/5/2007 3:46:33 AM GMT
Perhaps an external high speed memory bus? Could be used for prop to prop coms and/or memory.
64 I/O
It sounds like faster cogs will allow better video on less cogs, freeing up more cogs for other stuff anyway.
Gavin
Chip, I'm working my Smile off to help get you guys to 90nm! Now I know what you're using to print your litho! Now that I know, my imagination is running wild at where Parallax will be able to go with this. Once you guys start scaling this beautifully simply design, we're going to get some rediculous speeds out of the Propeller. I'm happy I got in on the scene at day two!
From my perspective, 8 cogs, 256k RAM, faster HUB access.
In order to control each cylinder of a V10 engine running at 10,000rpm (600us per control cycle), you'd need the RAM for large lookups, and the faster HUB access to get that data. I see 16 COGs as a daunting task to try to manage in software. Propeller Assembly is so wicked fast and efficient, that if you doubled it's speed and hub access, we'd all be sitting pretty! Plus, as was said, with the larger RAM and speed, one could write software routines to do things that would otherwise be taking up a cog or two, like the floating math.
.........Wow, you guys are getting this sort of speed out of these litho tools, wooooowwwwwwww You are just barely into the lasers!
-Parsko
·
The other way around is not financially smart. Although I'm sure the production cost are similar.
I agree with parsko.....managing 16 cogs would be a chore...unless the software was updated to show available cogs and such.
These are only my opinions, so take them as that.
If the chip was fast enough with eight cogs.....it would be totally possible to cog swap for other processes.
I would go with 8 cogs, faster, with more hub memory.
My opinion,
James L
edit: looking at the numbers that model would be getting hub access at 20Mhz (smells like a logic analyzer to me)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
Post Edited (CJ) : 11/25/2006 2:53:23 PM GMT
Many times I have found myself needing extra processing power and then immediately extra memory to support the extra processing. I would tend to think of the needs going hand in hand.· However, if I were to pick one vs the other, I would pick more cogs and more i/o pins vs more memory and current # of cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·
640k should be enough for everybody, right? [noparse];)[/noparse]