I am doing a design in FPGA that looks like this: enter image description here

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 CDC ? Will I need any synchroniser between Module 1 and Module 2 ?

Any feedback is welcome.

  • 1
    \$\begingroup\$ I think, to be absolutely sure, you should clock stuff out of module 1 on (say) the rising clock edge of 10 MHz and clock it in to module 2 on the falling edge of the 10 MHz clock. This means feeding the 10 MHz to module 2 so it can utilize it. \$\endgroup\$ – Andy aka Jul 3 '19 at 11:51
  • \$\begingroup\$ As an aside, you should learn how to export graphics from whatever tool you are using. The red squiggly line under "Clk_divider" makes it obvious that you took a screenshot, which looks amateurish. \$\endgroup\$ – Elliot Alderson Jul 3 '19 at 12:37

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.


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.

  • 1
    \$\begingroup\$ You mean timing meeting can be hard because there is a chance of some large skew between Module 1 and Module 2 clock paths ? (if No PLL) \$\endgroup\$ – Meenie Leis Jul 3 '19 at 12:28
  • \$\begingroup\$ @MeenieLeis Without a PLL the clock has to pass through the whole divider and likely an extra clock net from launch to your register. \$\endgroup\$ – DonFusili Jul 3 '19 at 12:30
  • \$\begingroup\$ When you use logic to make a clock, it adds a layer layer of routing through the fabric that not only adds skew, but skew with a larger variance, even if the clock ends up on a low-skew net. This is true even for a synchronous counter which has only one clock-to-Q delay. At any rate, Xilinx specifically warns against this practice. There is the option in Xilinx to use a BUFGCE and make a gated clock, which would work better. It’s easier just to use a PLL. \$\endgroup\$ – hacktastical Jul 5 '19 at 15:33

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


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.

  • 4
    \$\begingroup\$ The manufacturer (and their tools) have a very good idea of what the internal delays are. That's what static timing analysis is all about! \$\endgroup\$ – Dave Tweed Jul 4 '19 at 11:56
  • \$\begingroup\$ They also know that the delays may change depending on a number of conditions. So the delay times are published as a range of times. \$\endgroup\$ – scorpdaddy Jul 4 '19 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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