Clock Dividers with Clock Domain Crossing

Question

I am doing a design in FPGA that looks like this:

100 MHz is the clock available in my FPGA board. It feeds Module 2. Module 1 is needs a slow clock of 10 MHz clock. So I used a clock divider with flip flops. I thought of not using PLL to make my code purely RTL. Module 1 is transferring some data along with control signals to Module 2.

My current assumption is that:

The main clock and the divided clock are synchronous, and their phase relations are known to the synthesiser. And hence there is no Clock Domain Crossing here. So that I can simply constraint both the clocks and put multi-path SDC constraints between Module 1 and Module 2.

But I am not sure whether I am right. Is this a case of asynchronous clock-domain crossing ? Will I need any synchroniser between Module 1 and Module 2 ?

Any feedback is welcome.

Answer 1

Depends on your vendor

On most modern FPGA's of the two biggest vendors, your first assumption is correct and you won't need synchronization registers for the CDC if your clock divider is written correctly. The synthesis tools will take care of everything.

Synthesis tools by smaller vendors don't always take into account the known phase relationship between the clocks, which might mean you do need a proper CDC. From experience I can say that the old Libero tools for at least the older RTAX and ProASIC lines allow you to specify synchronous clocks, but the specification just gets ignored and proper CDCs need to be added at the RTL level.

Answer 2

Yes, it's all one clock domain as far as synthesis is concerned. You can draw a circle around all three modules, and there's only on clock entering that circle. The fact that some of the logic inside that circle runs at 10 MHz is largely irrelevant.

Depending on how your implemented your ÷10 logic, you'll make things easier or harder for the synthesis to meet timing, because it's going to be doing everything based on the 10 ns period of the master clock. Using a PLL would be good in this sense, because it can effectively eliminate any delay between the two clocks. If you used a ripple counter, that would be the worst, because it creates the largest amount of skew between the clocks. A synchronous counter would create a low, but controlled amount of skew.

Answer 3

Generally not recommended to use logic to drive clock in an FPGA: the clock skew is harder to control as you’re routing logic onto a BUFG (a Xilinx term for an entry point onto a low-skew clock network; other FPGAs have similar concepts.)

The design will synthesize and meet timing easier if you source the 10mhz clock from the same MMCM / PLL (Xilinx terms for their clock tiles) for the 100 MHz. You would treat the domain cross as a multicycle path and constrain it accordingly.

An app note from Xilinx that touches on this. https://www.xilinx.com/support/answers/62488.html

Answer 4

I don't think the phase relationship is known. It is made of 2 clock-to-output delays that may vary over a range of 0 to something (manufacturer dependent). It means that the data+control from Module 1 will reach Module 2 after the 100MHz clock has ticked. That may violate the hold time on Module 2 if the delay is too short. In other words if the sum of the two clock-to-output delays is near zero then you’ll violate the hold time constraint. And since the delay is in a range of zero to something then it’s possible. Assumes a non-zero hold time constraint (also manufacturer dependent).

Some folks might add 2 clock-to-output delays between the 100MHz source and Module 2’s clock input. But I think your idea of assuming they’re not synchronous enough and synchronizing data+control to Module 2 is better.