5MSPS PER COG from HUB

Sleazy - G

OK i have a good explanation for what im saying....... just follow me

If you watch the Viewport video (youtube link) youll see the 40Mhz adc being tested toward the end of the video

if you notice, the grid divisions are 20uS per division, and if you look really hard, you can also see "ADC 100 / div"

SO if you calculate this out, thats .2uS per adc to viewport·cycle, which the inverse brings us 5MSPS just as I had expected

i dont think· you can get cogs to output more than once every 16 clock cycles (5MSPS) if you are going to use mutually exclusive resources like the hub registers, or execute cog to cog instructions that require the hub to communicate.·

I mean, if you use more than one cog to do a process of information (which is the point of parallel processing), you have to use the hub to have the cogs talk, only once for 16 clocks.· Or alternatively·, you could try to use one cog with interrupts or subroutines and defeat the purpose of the propeller's architecture.· I dont see a feasible way you can get meaningful processed·data out at the same speed you can read it, even with a dedicated block of·buffer registers, unless you do something ridiculous like·segment·outa.

you have to wait 16 clocks for hub access!· Cogs cant talk to each other in the meantime. If you dont use more than 4 cogs, you cant keep the 80MSPS sample rate. Throw me a bone.

Post Edited (Sleazy - G) : 12/29/2007 8:40:43 AM GMT

Mike Green

What you're saying is not quite true. It is possible (relatively easy) to synchronize cogs. Good examples are the high resolution VGA drivers. If you have 4 cogs synchronized, they can each transfer 4 bytes (one long) between the hub and their local memory per hub cycle. That's 16 bytes per 16 system clocks or, at 80MHz, that's 80 Megabytes per second. Obviously, there's not enough memory to sustain this, but that would be the burst speed. The Viewport system works by using multiple synchronized cogs to read a fast ADC, taking turns doing the reads so they can dump their data to a main memory buffer at maximum hub memory speed.

deSilva

Well explained, Mike! But it is not only "relative simple" to synchronize COGs , but automatic! Beau gave some examples some days ago.

By using COG #1,#3,#5,#7 and just writing to the HUB all COGs will be phase offset by exactly 50 ns.

The tricky thing is to be able to use each HUB cycle for writing a LONG, which needs loop unrolling, and as the data from the DAC is not 32 bits wide, most likely two HUB cycles will be needed to dump an assembled LONG. This seems to be the reason why they cannot get the full 80 MByte/s but half of it only..

Sleazy - G

HEY MIKE, do you realize youre actually agreeing with me and saying im wrong in the same post?· read it again.

· "What you're saying is not quite true. It is possible (relatively easy) to synchronize cogs. Good examples are the high resolution VGA drivers. If·you have 4 cogs synchronized, they can each transfer 4 bytes (one long) between the hub and their local memory per hub cycle. That's 16 bytes per 16 system clocks or, at 80MHz, that's 80 Megabytes per second. Obviously, there's not enough memory to sustain this, but that would be the burst speed. The Viewport system works by using multiple synchronized cogs to read a fast ADC, taking turns doing the reads so they can dump their data to a main memory buffer at maximum hub memory speed."

you say EACH can transfer 1 long between hub and local ram per hub cycle.·

16 clocks per cycle·means 5 million transfers per second, or 5 million longs per second, or 5MSPS , just what I had said.

Notice i do specify that "cogs" can not·output mutually exclusives more than once every 16 clocks, by "cogs" i meant ANY single cog.

kind of like "I dont think dogs can drink more than 1 gallon of water a day".· That doesnt mean all dogs on the planet put together drinking the same gallon.·I think you just read what I had to say differently than how I had intended you to read it.





·

deSilva

Sleazy - G said...
I dont see a feasible way you can get meaningful processed data out at the same speed you can read it, even with a dedicated block of buffer registers,

I think this was the unclear phrase in your posting. Mike said: Of course you can store 80MBytes/sec - this is ths HUB bandwidth - for a (very) limited time: and right he is.
I said in my posting: As you do not get the ADC data in 32 bit lumps per 200 ns in ONE COG you will NOT have 1 LONG per COG per 200 ns to store to the HUB: I think this is correct too.

The Propeller as such can of course - by an unrolled loop and synchronized COGs - sample 1 LONG per 12.5 ns (=320 MBytes/second); taking 4 COGS leaves them convenient 50 ns for the INA instruction

But these are not what you - right as well! - called "meaningful processed data".
But you can store - during 10µs - 800 32-bit samples in 4 COGs, and process them conveniently during the next 10 ms. Rewiring the 32 Propeller pins by a hardware multiplexer allows re-use of the Pins. I think there are applications..

Post Edited (deSilva) : 12/29/2007 11:07:22 AM GMT

Sleazy - G

A multiplexer would not allow a total higher thruput bitrate

And anyway the solution is clear, dual ported ram for the hub.

Hanno

It's relatively straightforward to measure the "CNT" variable instead of the "INA" variable with the QuickSample object. You can then see the measurement on the Logic Analyzer of ViewPort- it will show you every single count of the 80Mhz clock. We did this during development and testing of ViewPort- try it yourself if you're still not convinced that ViewPort can sample at 80Mhz....
Hanno

deSilva

Sleazy - G said...
A multiplexer would not allow a total higher thruput bitrate

I did not talk about throughput - I talked about "burst rate"

said...
And anyway the solution is clear, dual ported ram for the hub.

Poppycock. Buy a decent DSP! Blackfin and Shark are in this season, also some TMS32 models