cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
yaelg
Visitor
Visitor
3,010 Views
Registered: ‎02-04-2018

generater clock - BUFG insertion

I have a design with 2  generated clocks  which are the system clock divided by 2 and 4.

 

I defined the clock and related constraints :

create_generated_clock -name coreclk_div2 -source [get_pins coreclk_div2*/C] -edges {1 3 5} -edge_shift {0.3 0.3 0.3} [get_pins coreclk_div2*/Q]
create_generated_clock -name coreclk_div4 -source [get_pins coreclk_div4*/C] -edges {1 3 5} -edge_shift {0.3 0.3 0.3} [get_pins coreclk_div4*/Q]
set_multicycle_path -setup 3 -from [get_clocks coreclk_div4] -to [get_clocks clk_extra_c0]
set_multicycle_path -hold 2 -from [get_clocks coreclk_div4] -to [get_clocks clk_extra_c0]
set_multicycle_path -setup 3 -from [get_clocks clk_extra_c0] -to [get_clocks coreclk_div4]
set_multicycle_path -hold 2 -from [get_clocks clk_extra_c0] -to [get_clocks coreclk_div4]

 

during place, I get the following warning:

WARNING: [DRC CKLD-1] Clock Net has non-BUF driver and too many loads: Clock net CL/coreclk_div4 is not driven by a Clock Buffer and has more than 512 loads. Driver(s): CL/coreclk_div4_reg/Q

 

How do I fix this issue?

 

Thanks

Yael

0 Kudos
5 Replies
bruce_karaffa
Scholar
Scholar
2,998 Views
Registered: ‎06-21-2017

Did you use the Clocking Wizard to produce your divided clocks?  It should insert the BUFGs automatically.

0 Kudos
avrumw
Guide
Guide
2,965 Views
Registered: ‎01-23-2009

There are a couple of problems here...

 

First, dividing clocks this way is not recommended. I am assuming that coreclk_div2 is essentially a toggle flip-flop on the main clock, and that coreclk_div4 is a toggle flip-flop running on coreclk_div2. This generates 3 different clocks with no guaranteed phase relationship with eachother. There is some phase delay through the flip-flop and routing, and this is hard to control.

 

All clocks in FPGAs should be generated using proper clock resources. Ideally, you should use an MMCM or PLL for these generated clocks.If you do this, the output clocks of the MMCM/PLL are properly constrained as long as you constrain the input clock.

 

But, if you can't for whatever reason, then you should consider a BUFGCE. A BUFGCE is a proper clock buffer with an enable. By controlling the enable properly you can generate a decimated clock that has the frequency of a divided clock - the only drawback is that it has an uneven duty cycle.

 

Take a look at this post on using a BUFGCE for a decimated clock.

 

Next lets look at your constraints. The create_generated_clock would be more or less correct ; -edges {1 3 5} describes a clock that is divided by 4. But the -edge_shift is (how do I put this...) wrong. I am not sure about what you were trying to convey with this, but it is not correct; even with your toggle flip-flop generated clocks, the generated clock is properly propagated through the circuit; the delay is calculated by the tool, and there is no justification for adding extra delay (which is what your -edge_shift does).

 

By the way, if you use the BUFGCE for generating the clock, then you would end up with a different edge pattern; -edges {1 2 5}.

 

Finally, if you insist on doing the clock division as you are doing it, you will have to manually instantiate BUFGs on each "clock". The output of clkout_div4 absolutely needs a BUFG; the tools are telling you as much - it has a large fanout and hence needs a BUFG. There is a structurally legal connection from the fabric to the BUFG input, but using it incurs both an unknown delay on the net, as well as the large and PVT variable delay through the BUFG and the clock network. Not using a BUFG creates a local clock, which has bad skew problems.

 

For the "clock" between the clkout_div2 and the clkout_div4, it is debatable whether you would use (or want) a BUFG on that net; a local clock with a fanout of 1 is probably relatively harmless.

 

Furthermore, if you did do this, the constraints you have (without the -edge_shift) would accurately describe the timing to the tool and it would do its best to satisfy timing even with this unknown clock phase shift due to the clocks in the fabric.

 

But again, doing clocks this way is not recommended in an FPGA.

 

Lastly, the set_multicycle_path commands are questionable. When you are passing from a slow to a fast clock or vice versa, the "correct" timing relationship is one fast clock period (which is the default). The only time a set_multicycle_path is appropriate is if you ensure that the flip-flops on the fast domain that drive the slow domain change state only on the clock edge of the fast clock that corresponds to the edge of the slow clock, and, for the other side, the flip-flops on the fast clock domain that capture data from the slow clock domain are only enabled on the clock edge of the fast clock that corresponds to the edge of the slow clock. If you don't have circuitry that ensures this, then the set_multicycle_path commands are wrong...

 

Avrum

0 Kudos
yaelg
Visitor
Visitor
2,926 Views
Registered: ‎02-04-2018

Thanks for the prompt response.

1. you are absolutely correct about the setup and hold constraints but they are, in fact, guaranteed by design.

2. I was following this AR  for creating a generated clock (use case 3) https://www.xilinx.com/support/answers/62488.html ,where did I go wrong?

3. can you direct me to a proper AR for creating a divided clock?

 

Thanks

Yael

 

 

 

0 Kudos
avrumw
Guide
Guide
2,899 Views
Registered: ‎01-23-2009

I was following this AR  for creating a generated clock (use case 3) https://www.xilinx.com/support/answers/62488.html ,where did I go wrong?

 

Where did you go wrong? Following that recommendation from the Answer Record. It is wrong!

 

There is no justification for the -edge_shift - in fact, it will produce incorrect timing results. I will file an SR against the answer record. More importantly the AR must point out that this mechanism of generating a divided clock is not recommended in an FPGA.

 

can you direct me to a proper AR for creating a divided clock?

 

I don't know of one (there aren't answer records for everything). The post I referred you to regarding the BUFGCE is one way of doing it, and using the MMCM/PLL is another. The MMCM/PLL is described in the Clocking User's Guide (UG472).

 

Avrum

0 Kudos
yaelg
Visitor
Visitor
2,876 Views
Registered: ‎02-04-2018

Thank you for your help

Yael

0 Kudos