Instruction timing between COGs

Cluso99

Does anyone know how the COG instructions are aligned to the clock?

What I am after, is there a way to enforce 4 COGs to be offset by one clock cycle each?

I have a Data Logger (basically like the Dscope sample) which currently samples at 50nS (at 5MHz xtal). I'd like to interleave 4 COGs to get me 12.5nS.

I'll post the code soon

Mike Green

It's been done. Basically, the WAITCNT instruction has a granularity of a clock cycle. You start the 4 cogs, passing to them a future CNT value, far enough in the future so they can complete their initialization, then each cog waits for a different offset (+0, +1, +2, +3) from that future CNT value. After the WAITCNT, the cogs are in lockstep on successive clock cycles. If they access hub memory, you have to resynchronize them. You don't have to restart them, but they all have to again wait for a future CNT value plus a per-cog offset.

Ken Peterson

Before you launch your cogs, calculate a cnt value some time in the future for your cogs to sync to. Let's call it start_cnt. Make sure start_cnt is far enough in the future that all of your cogs can load and initialize before start_cnt == cnt.

Launch cog1 with start_cnt as a starting point
Launch cog2 with start_cnt+1 as a starting point
Launch cog3 with start_cnt+2 as a starting point
Launch cog4 with start_cnt+3 as a starting point

In each cog, do a waitcnt first using the starting point that you gave it. Then they will all be in sync, each with it's own offset.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Ken Peterson

Looks like Mike and I were writing at the same time and he got the hub window first!··

If they all do hub access the same way, and they started in the proper order, all of the cogs will fall back into lock step after the hub accesses because even hub access is deterministic when timed properly.· When launching the cogs you might want to specify which cog is used by using·COGINIT instead of COGNEW.· Keep in mind that hub access windows come to each cog in a round-robin fashion, so the cog you start first should be the first one in line to get the hub, then the second one, etc.· I assume you are running identical code in each cog since you want them all synchronized.

I assume you only want 4 samples at a time at 12.5 ns intervals.· You can't sustain that rate because you need 16 clocks to read the sample,·increment your pointer, write·the sample·and then loop.· If you write to HUB memory it's even more.

Seems to me you would need 4 cogs just to sample at 50nS at a sustained rate, and that doesn't include hub access...unless I'm making some wrong assumptions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Post Edited (Ken Peterson) : 5/16/2008 3:50:05 PM GMT

Cluso99

Thanks Kike & Ken.

I get about 470 clear scan cycles per·cog (currently set at 450 with some debug statements).

So I want to be able to interleave 4 or join 4 end on end. It was the interleaving I was't sure about.

I know about the latency in hub access (I hope anyway).

Currently putting the code together·with the great VGA display·- already sending out formatted serially to the PC.

Ken Peterson

Cluso99: You mean you're using cog memory to hold your samples? What are you sampling if I may ask?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Cluso99

@Ken

All 32 I/O pins. I want to be able to either interleave 4 cogs or 4 sequentially to lengthen the no. of samples.

At the moment I am dumping them out the serial port after the samples have been obtained.

(added) Just sampling the pins at present - I am writing an 8 port serial driver in a single cog and want to be able the check the in and out timings. Then maybe some other things later. I have two proto boards and an FT2232C interface that drives both. I posted a topic last week about getting 2 IDE's working.

Post Edited (Cluso99) : 5/17/2008 4:12:09 AM GMT