synchronization of LV FPGA derived clocks

[JKneale]

I am working in LabVIEW FPGA 2017 with a PXIe-7961R.  I am running one SCTL at 80MHz and another far simpler one at 240MHz, connected with Block Memory FIFOs.  (Assuming I can close timing) I would like to access the 80 MHz clock in the 240MHz SCTL. 

• One option is to create a third simple SCTL at 160MHz to toggle a bit and use that as the input.  Assuming that all clocks are integer multiples of the 40MHz onboard clock, can I assume that they all start at the same edge and will stay that way.  This would include going through the FIFO.  I know it introduces latency - I'm just wondering if all this is consistent.
• The other option is to run the 80MHz SCTL at 160 MHz and add logic to do nothing every other clock.  That will be far more challenging to close timing with, and coding effort I'd prefer to avoid

- Jim

[Intaris · Accepted solution]

What do you want the 80MHz clock for in the 240MHz clock region?

You do realise that if they are derived from the same base clock, then every third iteration of the 240MHz clock will correspond to 80MHz, but your phases won't be aligned.

BTW, just having derived clocks sharing a common base clock will NOT guarantee synchronous starting. Their Phases will NOT automatically be aligned upon start. I found this out the hard way. I have seen, depending on the bitfile (it doesn't seem to change between deploys, but between compilations), differences in starting phase amongst my multiple clock domains (all sharing a common base clock). YMMV.

[Intaris]

Alternatively, why not do something like this (I do this a lot)

80MHz -> 240MHz (FIFO 1)

                 processing

80MHz <- 240MHz (FIFO2)

continue with result at 80MHz.

The sequence looks serialised, but of course runs in parallel. There will be a latency between the data being sent in FIFO 1 and the appropriate result being received in FIFO 2, but this will be constant for any given compilation and also pretty much constant between compilations.

[JKneale]

The synchronization at startup was my main question, which you answered.  The challenge that I'm facing is that the 80MHz clock isn't directly accessible in the wiring to feed into a FIFO unless a create it in a 2x clock domain.  I can't be sure that the edges of that are in synch with the edges that drive the 80MHz SCTL.
In response to your earlier question, I want to use the 240MHz clock domain to programmatically adjust the skew between the outgoing clock and several other signals.  The higher the clock, the finer my resolution.

[Intaris]

So you want to introduce a defined 240MHz delay into an otherwise 80MHz path?

I don't understand what you mean with the edges of "that" being in synch with the 80MHz clock..... Do you mean the FIFO? If a FIFO crosses two clock domains, it will have two distinct ports, each one running at the respective clock. If you write at 80MHz, the write port will be perfectly synchronous with the 80MHz clock, when reading at 240MHz, it will be perfectly synchronous with the 240MHz clock. Whereabouts do  your uncertainties arise?

Or do you mean you want to input a signal at 160MHz into the FIFO?  You could bundle two elements, ad on the receiver side, whenever you read a valid value from the FIFO, use, and then re-use the value next cycle instead of re-reading from FIFO.

Case State

Start:

Try to Read FIFO

If successful, use first element and State = Element 2

Element 2:

use second element and State = Start

Maybe if you describe more which problem you are trying to solve, it might be easier to come up with an easier solution.

[JKneale]

Intaris -

Good point.  I'm generating several data streams and synchronization pulses in the 80 MHz clock domain.  Once they leave that and go into a FIFO, I don't care as long as the FIFO data elements for the U32 that I pack them into are kept together.  I could then re-create the 80 MHz clock just as easily in an 240MHz SCTL and manipulate it from there.  I would definitely know where my edges are at that point.

Thanks for the fresh point of view on something I was making overly complex.

- Jim