FPGA Register limitations

[Intaris]

Here's a semi-interesting factoid: (it's interesting to me, but perhaps not for anyone else)

The phase Iteration counters of timed loops corresponding to multiple derived clocks are NOT automatically synchronised when starting the FPGA code.  Even though I am deriving all of my loop clocks from a common base (the 40MHz base clock in this case) the individual loops do NOT always start synchronously.  Sometimes the faster loop is an iteration ahead of the slower loop, sometimes they're the same and sometimes the faster loop is a frame behind the slower loop.  This is unexpected for me and I don't QUITE understand how this comes about.

By placing a timed loop @ 40MHz for X iterations (after which it terminates) and then a timed loop @ 120MHz for Y iterations (after which it terminates and all other code is started (flat sequence)) I can force the clocks to be synchronised at startup.  This way, I can have a guaranteed iteration relationship between my faster and slower loops.  By making the loop counters controls and running the code in interactive mode, the effects of the wrong iteration counts can be reproducibly observed.  Obviously in this relationship, every third iteration count of the 120MHz loop leads to the same result.  The iterations of the 40MHz loop has no effect aside from defining the starting conditions for the 120MHz loop.

Is it logical that such a step is neccessary and is such a step robust?  Testing seems to indicate that it is stable across multiple runs and multiple compilations but a word from NI would be very much appreciated on the matter.

PS No, it's not robust in my case.  Because I have 40, 80 and 120 MHz clocks, I cannot guarantee a given phase relationship between all three clocks.  This is beacue the 80MHz and 120MHz clocks have a non-integer frequency relationship.  I need to refactor so that all derived clocks for this subsystem are integer multiples of each other, then it should work.

[Intaris]

I swear LabVIEW is just mocking me at this stage. Let's me think I have a solution and then when I'm least expecting it, tells me that it doesn't work.

My idea to synchronise the loops won't work with external clocks.  Timed loops with external clocks are not allowed to terminate..... Due to "stability" reasons.  Well our entire code runs off external clocks.  We don't actually have a single loop (in our LV code) which runs off an onboard clock.

Looks like I'll need Block Ram after all..... -sigh-

[Dragis]

You are definitely getting into the nitty-gritty of FPGA programming. The external clocks do create an additional layer of complexity that reduces the features you can use. If at all possible, use the Block Ram FIFOs. If you can't for some reason, the CLIP will be the way to go and the communicty can help with that if necessary.

[Intaris]

I have it up and running with Block Ram at the moment.  I have tried to make all relevant loops run at 160MHz, which workd fine apart from my loop incorporating third-party CLIP code.  It won't compile at 120MHz, let alone 160MHz.  The Communication to and from this loop is currently performed by (very inefficient space-wise) Block RAM FIFOs.

Bearing in mind derived clocks from CLIP isn't officially supported in LV 2012 but I'm using them anyway means I really shouldn't be complaining.

Shane

[Intaris]

I'm mentally revisiting this topic.

Is there a flowchart somewhere explaining exactly how Registers transfer data from faster to slower loops and from slower to faster loops?  And is there the same information for the newer Handshake items?

From what I understood, Registers across clock domains are basically Hanshake items without the flags exposed......

It could turn out that I could achieve what I want with Handshake items if I make sure the loops are both integer multiples of the base clock.

[T-REX$]

Hey Shane,

You ever used ISIM for cycle accurate simulation? Given the following VI, which sends count data from an 80MHz loop to a 40 MHz loop:

Here are the results...

Register:

Handshake:

The biggest difference between the Handshake Item and the Register Item is "Lossless" vs "Lossy". If flow control matters, it will probably be more efficient to use the Handshaking node. Otherwise, use the Register node.

[Intaris]

You know, I never figured out how to use ISIM for simulation.... I always stopped dead in my tracks at the "Develop a test bench" step.  No knowledge of VHDL.....

The information supplied is great, I just need to figure out what's what....

Ah, I see the Ready for Output and Ready for Input booleans in the lower part of the Handshake trace.

For my application, I would need lossless transmission, but at minimum half the rate of the slowest loop....  Registers update here every 5 slow cycles whereas Handshakes update every 7 slow cycles.  Therefore, interleaving 3 Registers of 4 Handshakes would be required.  This requires exact coordination of the read / write indices.  Question is if the Handhake delivers enough information to have the reader side "self-adjust" to the writing pattern in order to guarantee communication.  My plan is to encapsulate this communication into a class so that the object itself takes care of everything behind the scenes.

Thanks again for the help.

Shane.

[T-REX$]

FYI, if you look at the 'testbanch' I developed to create those graphs... its just one line of code. Everything else is auto generated.

WAIT FOR 1us;

 I tend to use ISIM for unit tests on code who's timing I need to verify. The testbenches only become difficult when you need to push real data into your logic, not just constants or simple functions. I often cond. disable around the 3rd party sim. tag to put in simple functions instead of IO for testing.