In this scenario there is a clock source that shall generate 120MHz clock. This shall go into an FPGA and an ADC. When the ADC is actually transmitting data and not in a power down state, it shall transmit parallel data with a clock signal to the FPGA i.e source synchronous parallel transfer. The clock output by the ADC on this data transfer is 120MHz as well.

Now, we have the FPGA design running at 120MHz and also have ADC source synchronous interface sending data at 120MHz. The primary issue is that, from what I susptect, the region where the ADC data is being registered inside the FPGA, the two clocks inside the FPGA will not be aligned. Also, they will have a different amount of jitter on them.

Now I need to understand how to deal with this problem so data is correctly registered into block RAM in the FPGA and no data corruption occurs.

  1. Is it true that a clock crossing FIFO is not required in this case?
  2. I will certainlg need to specify timing constraints for the FPGA since the ADC clock coming in is basically a write clock for the block RAM. What SDC constraints do I use for this and what values go into the constraints?
  3. The two clocks will be out of phase and have different jitter but I don't think I can predict the precise amount. Do I then use an internal FPGA PLL to align the two clocks? What settings do I provide to it?
  4. The primary issue is not knowing the phase difference between the two clocks practically. What is the proper way to mitigate this? I believe I will need some input from the PCB design team to know length and associated propagation delay of clock signal paths.

I just want to understand the proper way to deal witn this design problem.

  • 1
    \$\begingroup\$ I think the obvious one is to sync the fpga clock to the external clock. A pll block should be able to do that for you. What settings? We don’t even know which fpga you’re using, so how can we tell you the settings? Time to start reading I think. Also note that the phase between two asynchronous clocks will vary. This is why you need the pll. \$\endgroup\$
    – Kartman
    Commented Oct 13, 2021 at 10:16
  • \$\begingroup\$ By settings I meant by how much to delay the ADC clock. One aspect is that when the ADC goes into power down mode, the clock coming from it will stop. PLLs need some finite amount of time to get their lock, this means that before we start storing ADC data, we need to be sure that the PLL has done its job. \$\endgroup\$
    – gyuunyuu
    Commented Oct 13, 2021 at 11:04

1 Answer 1


1. You will most definitely need to do a clock domain crossing. Even if you could get the two clocks in phase, you'd still have to do the same with the data (which sounds like a nightmare). Otherwise you setup and hold timings will be all over the place.

The primary issue is not knowing the phase difference between the two clocks practically. What is the proper way to mitigate this?

You don't. You'd still have to account for changes in temperature and voltages as well as slight differences in manufacturing of each FPGA. I mean you could, but you'd need to build a phase comparator and a variable length delay chain to continuously adjust the phase shift of the ADC clk (and data).

If you use a CDC all you other problems you mentioned will basically disappear (that's why we use them).

Generally speaking, you want to avoid using external clock domains inside the FPGA. We generally try to cross over to an internal PLL clock domain (with a quartz or internal reference) as fast as possible. Especially at high speeds, there is too much risk of corrupted data.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.