Constraining two clocks

Hello, here's my situation.

I have a Zynq processor that writes data to registers at 100MHz. These values are used in a clock domain of 62.5MHz (period of 16ns). These 2 clocks are generated by the Zynq processor from a 33.333MHz. The path requirement for this clock domain crossing is only 2ns and the timing fails. What can I do to fix the timing issue? Do I have to treat them as asynchronous clock and use double sync registers and also set the constraint as false path?

What about the other way from 62.5MHz to 100MHz?

I don't know if it makes a difference but when the processor writes data to the registers, it takes several clock cycles before these values are used. Do I have to take care about the double sync in this case?

I'm confused about this situation. Please help me.

Depending on the formatting of the data the Zynq is writing...individual independent bits in the register or fields (multi-bit values) within a register...your method of crossing the clock domain changes. It also depends on how fast the Zynq will write to the register in the 100 MHz clock domain. As you only specify several clocks, I'm not sure what that really means and am assuming the Zynq register write protocol takes at least 5-6 clock cycles if not more (5 only allows for slightly over 3 clocks in the 62.5 MHz domain).

If all the bits are independent control bits (no multi-bit fields) then a simple 2 stage synchronizer will work. However, if the you have multi-bit fields in the register then you have to enforce some sort of protocol that ensures the data in those fields are stable before capturing them in the 62.5 MHz clock domain. I usually do this by double buffering the register. The load signal for the register write gets synchronized across the clock domains and that synchronized load is used to update the second register in the new clock domain. Of course this means there has to be an upper limit on how fast the Zynq is allowed to write to the register.

Crossing back from the 62.5 MHz to 100 MHz is done in the same fashion, depending on the type of data in the register.

asd-ee, I understand and it makes sense for a fast writing sequence in the same register. In my case, these are configuration registers and they don't change often and are not used immediatly. In this situation, I have 2 questions. Do I still need the double synchronisation? If yes, do I still have to set a false path between these two clocks in my timing constraint file to remove the timing error reporting?

Thanks for your support

Tetik said:

Do I still need the double synchronisation?

Click to expand...

If you can answer yes to both of these questions then you could get away without the synchronization.
1. This code is never going to be used in another design
2. It's 100% guaranteed by design that this register is never read by any other clock domain, while it's being loaded. (i.e. there is an enable on anything that uses the output of this register and that enable will never occur while the register is being updated by the Zynq)

If yes, do I still have to set a false path between these two clocks in my timing constraint file to remove the timing error reporting?

Click to expand...

You should have a line something like this in your sdc timing constraints file: set_clock_groups -asynchronous -group [get_clocks {clk_10 clk_20}] -group [get_clocks clk_33]. This will keep the tools from trying to meet timing in the paths between the clocks clk_10/clk_20 with clk_33.

Here is a blog on CDC from eetimes: https://www.eetimes.com/author.asp?section_id=36&doc_id=1320110.

Regards

Thanks for the link, very useful. I see now the difference between the set_false_path and set_clock_groups -asynchronous command. I also added the command set_max_delay -datapath_only to 10ns to constraint the delay between the ffs.

Thanks