Even though you would be in turbo mode, with the non-turbo cogs running sequentially, you will have dead time for the turbo cogs. Sure they will have a great through put, but their timing will be toasted. Most everything which requires a high bandwidth is very timing dependent. Ram and busses are no different.
Because the hub has to operate in the round robin fashion, I do not see where the advantage would be. Sure you could have four sequential hub locations (for example) for a turbo cog, but I think you would find timing to be a huge problem then.
The primary non-turbo cogs is where the problem is. If every cog was turbo, with only 4 running, then it is just a matter of each cog getting twice the bandwidth. But when you throw in the non-turbo, the poop hits the fan.
That is the whole problem. Intermixing two different speed requirements (or bandwidth in this case) just doesn't work.
It is not like the extra unused bandwidth of one cog(one running) could be used for the next. I don't think it works that way. You could use the bandwidth from a non-running cog, but that may not help depending on the way the cogs are loaded. Then you introduce a whole new set of problems. Cog ordering, which up to this point has been trivial. Then one object will not work with another due to cog ordering, and has to be rewritten.
Interesting, but still not my preferred choice. It introduces a lot of complexity. Maybe not now, but at some point. That is unless there is a strict rule of how non-turbo objects load into cogs. Rules.....rules.....even more rules.
I guarantee it would eventually bite someone somewhere.
Better to continue to learn how to do things multi-cog. That's where the power is, if needed. I would have significantly less productivity with Propeller, given the added complexity. And I wonder about the silicon requirements. The state machine for the COG - HUB interaction would be complicated significantly...
As it is, we are gonna get lots of stuff in Prop II.
Potatoprediction: Even though there will be 96 pins, they will quickly become the bottleneck anyway, because the multi-processor element just can control pins like no other!
The cog and hub memory is actually 128 bits, but normal 32 bit access to the cog and 32/16/8 hub access will still be supported. So, there will be new quad-long access instructions for read and write. No issues here.
The turbo mode isn't that difficult. The normal cog round robbin would take place. However, if a slot is not required by the specific cog, then the slot would be reallocated to a turbo cog requesting a slot, rather than waiting it's turn. This would shine in spin where we currently have to wait for each cog's turn. Also, in fetching data for a VGA display, and again in the SD access, ZiCog, etc. In all cases, a speed improvement for what I see as a little silicon, nothing fancy, just a little bit of logic to allow another cog access rather than going idle, determined by a turbo bit.
Anyway, it's too late in the game!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Just a quick thought why not have two counters for which cog has control of the hub, the first one that cycles up one at a time, and the other that counts through the turbo enabled cogs, when a cog isn't requesting a hub-op then allow the next turbo'd cog that is requesting one use it? that way we keep the deterministic operation for the cogs that need it [noparse]:)[/noparse]
Cluso99 said...
The cog and hub memory is actually 128 bits, ...
I'd be surprised if that were actually true of the cog memory. I'd be more inclined to believe four simultaneous and independent 32-bit accesses could occur, given that it's a four-port RAM. While those accesses could be to sequential addresses, that's not the same as saying the data path is 128 bits wide. Even then it's not at all clear, with a four-port RAM, that more than one of the four simultaneous accesses can be a write. In normal pipelined operation, only one access at a time is a write to the destination register. The others are read instruction, read source, and read destination.
Also, I will grant that the mechanism for a so-called "turbo" hub-access mode may not be all that complicated. It's the philosophy behind it that I would call into question, simply because turbo timing cannot be guaranteed. And without that guarantee, there's no advantage to using it. None.
I thought only cog ram was going to be 4-port. I would be surprised if the cog could access multiple memory locations in hub ram in a single cycle.
Also, a program can be written from the ground up to take advantage of the turbo mode, guaranteeing desired bandwidth. Even on the current prop, maximum bandwidth of sysClcok/16 * 32-bits per cog can not be guaranteed if code is not written to properly take advantage of it. It's the job of the programmer to utilize the tools wisely.
Yes Phil, You maybe correct that the cog is not 128 bit, but indeed 4 port ram. I am not sure of the subtleties involved here. However, Chip has said that quad-long transfers will be supported in one clock, so the data path has to be 128 bits wide.
As to the advantage of turbo mode, I respectfully disagree to the statement "... there's no advantage to using it. None." Obviously there is a speed advantage!! Your agrument only hinges upon whether it will upset determinism and that "should" be left to the users to decide. Anyway, as I keep saying, this is moot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I agree, even though I don't support the idea of the turbo. There are advantages and clear ones. No question on that.
This discussion has made me consider the value of how the Prop is right now -vs- it's overall value with a change like this. The code management cost is pretty high. Each of us will have a different value judgement on that, clearly.
I question "wasted" access slot too. If the value of things is considered holistically, that unused access slot is no different than a video generator sitting idle, for a bit of code that's mashing on the pins, right? Seems to me, the philosophy hangs together that way, if nothing else.
Having a known state for all code is very, very valuable. I think the desire to get "our" application working to peak is tempting enough to outweigh either factoring it to use more than one COG, or being able to blend bits of code together so easily.
BTW: If a COG can get that many longs between accesses, isn't that a huge boost over the current Prop I instruction to HUB memory access ratio, in effect applying a "turbo" to all COG's, thus addressing the need for a wide scope of use cases, while not yielding on the code re-use and determinism values?
Cluso99 said...
Yes Phil, You maybe correct that the cog is not 128 bit, but indeed 4 port ram. I am not sure of the subtleties involved here. However, Chip has said that quad-long transfers will be supported in one clock, so the data path has to be 128 bits wide.
As to the advantage of turbo mode, I respectfully disagree to the statement "... there's no advantage to using it. None." Obviously there is a speed advantage!! Your agrument only hinges upon whether it will upset determinism and that "should" be left to the users to decide. Anyway, as I keep saying, this is moot.
I will conceded that you are right, there could be cases that turbo would improve speed. My problem with the turbo would be the programming require to get it to work. Most instances of high speed use would be used by people to do things which are inherently timing based.
I know the point is moot. I read that back before I posted. I know we are all talking hypothetically.
It is an interesting idea......but for myself (even if it were available) I would probably not use it. Most things I program are based on timing some way or another. Not that I need to figure out timing, but the timing needs to be certain. With the current arrangement, I can either do it in my first attempt or try a different way. When I achieve the speed I need, I do not have to worry about possibly breaking it.
I know sometimes using two cogs for one action is not possible, but there are times it is. That fact alone will allow "turbo" for the people which are good enough to use two cogs for the same purpose. I am currently not good enough on the propeller to do such an action, and probably never will be. I just do not have time enough to play with it that much.
My statement that there's no advantage to using turbo mode, if it existed, is due to the fact that one must always program for the worst case, performance-wise. And the worst case for turbo mode would be no speedup whatsoever. Hence my rhetorical question, "So why use it?" It may be statistically faster, but a reliance on statistical performance metrics for real-time programming tasks is a road to ultimate failure. Moreover, the statistics for a turbo cog will always be skewed by other cogs in a dance that's too complex to model simply. This is especially true when those other cogs are executing Spin or LMM interpreters, which are constantly banging the hub for code.
Yikes! I must have missed a valuable thread. Where was it said (by reputable source) that propII will have 96 I/Os?
Maybe there are there are other specs I missed. Maybe some hints to a eta ;^)
markaeric: It's moot only because this has been designed so it's not going to change. However, I do believe there are uses for it to gain extra bandwidth.
hinv: There is another recent thread. It is likely to be 96+8 I/O's where the 8 may also be special purpose. All I/O's have DAC's ADC's various optional pullups and pulldowns (IIRC 10K and 1K).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I understand why you've suggested it's a moot point, Cluso. Nevertheless, the available Prop2 bandwidth is very satisfactory, especially for a uC.
Doug,
VGA is supposed to run off only 5 pins now, as the analog RGB signals will be generated by the DACs in each pin. A larger color palette will be available as it will now be 5-Bits per pixel. And, you know, a whole bunch of other cool things!
This occurred to me in the middle of the night last week, upon awakening with mild discomfort from too much holiday cheer. One way to solve the "turbo mode" vs. determinism issue would be the following:
1. When a cog is launched with cognew, the two LSBs of the of the argument to par (which are otherwise unused) could indicate the "turboness" of the cog:
····a) %00 = 1 access per hub "rotation" (i.e. the current default). ····b) %01 = 2 accesses per rotation (i.e. the cog gets every fourth hub access). ····c) %10 = 4 accesses per rotation (i.e. the cog gets every other hub access). ····d) %11 = 0 accesses per rotation (i.e. the cog doesn't get any hub access; any hubop attempt will result in an infinite wait).
2. Hub access slots that are claimed by a turbo cog cannot be filled by any other cog, unless that cog is initiated using a cognew with turbo mode = %11 (i.e. no hub access).
3. coginit is deprecated, as it should have been from day one.
This way, cogs requesting "turbo mode" hub access are guaranteed the timing they request, without getting preempted by a cog that resides in one of its turbo slots (since no other hub-using cog can reside there). Of course, this also means that the total number of active cogs can be limited by the number of extra hub slots claimed by turbo-access cogs.
The cognew allocation mechanism would be of the "first fit" variety: grab the first slot allocation that fits the request. The onus would then be on the programmer to start the "greediest" cogs first, thus providing the best chance of fitting all the requests.
Of course this, along with the related discussion preceding it, is just hypothetical blather. Such a mechanism might have benefited the Prop I, but the Prop II has such efficient hub access, that the added complication is not worth the bother.
Phil: "but the Prop II has such efficient hub access, that the added complication is not worth the bother." I fear you may eat those words. We might be stupid enough to put windoze or linux on the PropII. *grin*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
Even though you would be in turbo mode, with the non-turbo cogs running sequentially, you will have dead time for the turbo cogs. Sure they will have a great through put, but their timing will be toasted. Most everything which requires a high bandwidth is very timing dependent. Ram and busses are no different.
Because the hub has to operate in the round robin fashion, I do not see where the advantage would be. Sure you could have four sequential hub locations (for example) for a turbo cog, but I think you would find timing to be a huge problem then.
The primary non-turbo cogs is where the problem is. If every cog was turbo, with only 4 running, then it is just a matter of each cog getting twice the bandwidth. But when you throw in the non-turbo, the poop hits the fan.
That is the whole problem. Intermixing two different speed requirements (or bandwidth in this case) just doesn't work.
It is not like the extra unused bandwidth of one cog(one running) could be used for the next. I don't think it works that way. You could use the bandwidth from a non-running cog, but that may not help depending on the way the cogs are loaded. Then you introduce a whole new set of problems. Cog ordering, which up to this point has been trivial. Then one object will not work with another due to cog ordering, and has to be rewritten.
Interesting, but still not my preferred choice. It introduces a lot of complexity. Maybe not now, but at some point. That is unless there is a strict rule of how non-turbo objects load into cogs. Rules.....rules.....even more rules.
I guarantee it would eventually bite someone somewhere.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
Post Edited (James Long) : 12/29/2009 8:53:01 AM GMT
Better to continue to learn how to do things multi-cog. That's where the power is, if needed. I would have significantly less productivity with Propeller, given the added complexity. And I wonder about the silicon requirements. The state machine for the COG - HUB interaction would be complicated significantly...
As it is, we are gonna get lots of stuff in Prop II.
Potatoprediction: Even though there will be 96 pins, they will quickly become the bottleneck anyway, because the multi-processor element just can control pins like no other!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I know this seems weird after talking about maximum bandwidth, but I hope long addressing isn't going to be a pain with a 128-bit hub bus.
The turbo mode isn't that difficult. The normal cog round robbin would take place. However, if a slot is not required by the specific cog, then the slot would be reallocated to a turbo cog requesting a slot, rather than waiting it's turn. This would shine in spin where we currently have to wait for each cog's turn. Also, in fetching data for a VGA display, and again in the SD access, ZiCog, etc. In all cases, a speed improvement for what I see as a little silicon, nothing fancy, just a little bit of logic to allow another cog access rather than going idle, determined by a turbo bit.
Anyway, it's too late in the game!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Also, I will grant that the mechanism for a so-called "turbo" hub-access mode may not be all that complicated. It's the philosophy behind it that I would call into question, simply because turbo timing cannot be guaranteed. And without that guarantee, there's no advantage to using it. None.
-Phil
I thought only cog ram was going to be 4-port. I would be surprised if the cog could access multiple memory locations in hub ram in a single cycle.
Also, a program can be written from the ground up to take advantage of the turbo mode, guaranteeing desired bandwidth. Even on the current prop, maximum bandwidth of sysClcok/16 * 32-bits per cog can not be guaranteed if code is not written to properly take advantage of it. It's the job of the programmer to utilize the tools wisely.
As to the advantage of turbo mode, I respectfully disagree to the statement "... there's no advantage to using it. None." Obviously there is a speed advantage!! Your agrument only hinges upon whether it will upset determinism and that "should" be left to the users to decide. Anyway, as I keep saying, this is moot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
This discussion has made me consider the value of how the Prop is right now -vs- it's overall value with a change like this. The code management cost is pretty high. Each of us will have a different value judgement on that, clearly.
I question "wasted" access slot too. If the value of things is considered holistically, that unused access slot is no different than a video generator sitting idle, for a bit of code that's mashing on the pins, right? Seems to me, the philosophy hangs together that way, if nothing else.
Having a known state for all code is very, very valuable. I think the desire to get "our" application working to peak is tempting enough to outweigh either factoring it to use more than one COG, or being able to blend bits of code together so easily.
BTW: If a COG can get that many longs between accesses, isn't that a huge boost over the current Prop I instruction to HUB memory access ratio, in effect applying a "turbo" to all COG's, thus addressing the need for a wide scope of use cases, while not yielding on the code re-use and determinism values?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I will conceded that you are right, there could be cases that turbo would improve speed. My problem with the turbo would be the programming require to get it to work. Most instances of high speed use would be used by people to do things which are inherently timing based.
I know the point is moot. I read that back before I posted. I know we are all talking hypothetically.
It is an interesting idea......but for myself (even if it were available) I would probably not use it. Most things I program are based on timing some way or another. Not that I need to figure out timing, but the timing needs to be certain. With the current arrangement, I can either do it in my first attempt or try a different way. When I achieve the speed I need, I do not have to worry about possibly breaking it.
I know sometimes using two cogs for one action is not possible, but there are times it is. That fact alone will allow "turbo" for the people which are good enough to use two cogs for the same purpose. I am currently not good enough on the propeller to do such an action, and probably never will be. I just do not have time enough to play with it that much.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Prop1: 20MB/sec per cog @ 80MHz clock
Prop2: 240MB/sec per cog @ 120MHz
That's a pretty significant increase (12X!) if I must say so myself.
Maybe there are there are other specs I missed. Maybe some hints to a eta ;^)
Doug
hinv: There is another recent thread. It is likely to be 96+8 I/O's where the 8 may also be special purpose. All I/O's have DAC's ADC's various optional pullups and pulldowns (IIRC 10K and 1K).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Doug,
VGA is supposed to run off only 5 pins now, as the analog RGB signals will be generated by the DACs in each pin. A larger color palette will be available as it will now be 5-Bits per pixel. And, you know, a whole bunch of other cool things!
1. When a cog is launched with cognew, the two LSBs of the of the argument to par (which are otherwise unused) could indicate the "turboness" of the cog:
····a) %00 = 1 access per hub "rotation" (i.e. the current default).
····b) %01 = 2 accesses per rotation (i.e. the cog gets every fourth hub access).
····c) %10 = 4 accesses per rotation (i.e. the cog gets every other hub access).
····d) %11 = 0 accesses per rotation (i.e. the cog doesn't get any hub access; any hubop attempt will result in an infinite wait).
2. Hub access slots that are claimed by a turbo cog cannot be filled by any other cog, unless that cog is initiated using a cognew with turbo mode = %11 (i.e. no hub access).
3. coginit is deprecated, as it should have been from day one.
This way, cogs requesting "turbo mode" hub access are guaranteed the timing they request, without getting preempted by a cog that resides in one of its turbo slots (since no other hub-using cog can reside there). Of course, this also means that the total number of active cogs can be limited by the number of extra hub slots claimed by turbo-access cogs.
The cognew allocation mechanism would be of the "first fit" variety: grab the first slot allocation that fits the request. The onus would then be on the programmer to start the "greediest" cogs first, thus providing the best chance of fitting all the requests.
Of course this, along with the related discussion preceding it, is just hypothetical blather. Such a mechanism might have benefited the Prop I, but the Prop II has such efficient hub access, that the added complication is not worth the bother.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm