04-23-2018 05:13 AM
As shown in a simple clock structure, module1's ip can only run clk's divide by 2, I use generate to generate a clk_div2, the result will report between clk and clk_div2 sometimes need. How can I set clock constraints on such a small structure? Clk and clk_div2 belong to the same clock, need to check the wrong time? Please help explain how this structure clock is constrained. Thank you very much.
04-23-2018 05:21 PM
04-23-2018 07:44 AM
what tools are you using to generate this ?
04-23-2018 05:21 PM
04-23-2018 07:13 PM
04-23-2018 11:23 PM
04-24-2018 05:36 AM
You haven't actually given us all the information, which makes the question hard to answer. There are LOTS of wrong ways of doing this and only a couple of right ways.
Using a fabric divider (a flip-flop) to perform clock division is almost never the right way to go. Using a fabric flip-flop introduces a large skew between the base clock and the generated clock...
Where does the clock come from? If "CLK" is the output of an MMCM, then the easiest way of doing this is to have the MMCM also generate the clock with the /2 frequency and use a single BUFGMUX to select between them. Done this way, all constraints are taken care of by the MMCM, and there is no (or little) skew between the clocks.
Another way of doing it is using a BUFG and a BUFGCE - take a look at this thread on using the BUFGCE and constraining it.
Another way of doing it is not using a divided clock at all, but running all logic on the faster clock and using an enable to enable logic that needs to only run every second clock
always @(posedge clk)
... reset stuff...
else if (ce)
... stuff that runs every second clock
(Assuming ce is asserted on every other clock).
None of these use a fabric generated clock, and hence you don't have the skew (and other) problems associated with fabric clocks.
04-24-2018 06:02 PM
Thank you very much for your reply, because the clock coming out of MMCM will go through two choices. I would listen to your suggestion and switch to BUFGMUX to make a choice, but I will report an ERROR that cannot be cascaded between BUFG and BUFG. I am very puzzled about this problem. For example, I In the application of choice is greater than or equal to three certainly will need to call BUFGMUX twice to do the choice, but vivado will not allow BUFG and BUFG cascade, if I block out the rules, there will be a timing violation. As shown in the figure, clk1 clk2 is the clock out of MMCM. How do I correctly complete the clock selection structure? Looking forward to your reply, thank you very much.
04-24-2018 08:16 PM
04-25-2018 12:35 PM
but I will report an ERROR that cannot be cascaded between BUFG and BUFG. I am very puzzled about this problem....
I am not clear on your post. Are you saying you need to do more than a 2:1 MUX, or are you saying that you are getting an error with a 2:1 MUX?
If you are only using a 2:1 MUX, there should not be any BUFG/BUFG cascade.
The MMCM generates two clocks; CLKOUT0 and CLKOUT1 (possibly in addition to CLKFBOUT).
If you only need the MUXed version of the clock, then you only use the BUFGMUX; CLKOUT0 goes to the I0 and CLKOUT1 goes to the I1. The output of the BUFGMUX is a global clock and needs no further buffering.
If you need either or both of CLKOUT0 and/or CLKOUT1 in addition to the MUXed clock, then the additional BUFGs for these clocks go in parallel with the BUFGMUX
CLKOUT0 drives the I0 input of the BUFGMUX and the I input of a BUFG
CLKOUT1 drives the I1 input of the BUFGMUX and the I input of another BUFG
So, if you need all three clocks (CLKOUT0, CLKOUT1 and the MUXed CLKOUT0/CLKOUT1) you use two BUFGs and one BUFGMUX, all in parallel (as described above).