cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
3,918 Views
Registered: ‎06-22-2016

High net delay of BUFGCE compared to BUFGCTRL

Jump to solution

Hello. I'm having an issue related to high clock skew. In a nutshell, my design is like this. One MMCM drives a BUFGCE and a BUFGCTRL (clock mux) and the output of those is driving shared logic (I've attached a schematic drawing). And I know that clock muxes and FPGAs are not the best of friends, but I can't change the design :'(

 

clk_skew2.png

 

I've made sure that the clock source and the loads are placed in the same clock regions to minimize clock skew, but after doing timing analysis (post place and post route), I've found that the net delay from the BUFGCE is twice as high as the one from the BUFGCTRL which is causing me to have very high hold violations (due to high clock skew). I have checked in the device view and both seem to be routed through clock dedicated routes.

One thing I noticed is that the timing report says that the clock region of the output nets of both BUFGs is a different one from the real one (also happening on the latest Vivado version). Is this a different kind of clock region?

 

clk_region.png

 

Has anybody had this issue before?

 

Some extra info in case it is useful

  • Vivado Version: 2016.3 (also checked on 2017.2)
  • Target device: Virtex Ultrascale (XCVU440)
  • Synthesis Tool Vendor: Synopsys

 

Thanks!

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
5,120 Views
Registered: ‎01-23-2009

You need to call attention to the fact that this is UltraScale (you mention it at the end).

As opposed to all other FPGAs, the clock networks in UltraScale are not fixed - while they use dedicated routing, the tool creates different trees for each different domain. As a result, the domains can be unbalanced as you have found.

But the good news is there is an property specifically for this situation!

If you want two (or more) clock nets to be balanced against each other, you give them the same CLOCK_DELAY_GROUP. This instructs the tool to make sure that the CLOCK_ROOT of these domains are located in the same clock region. You do this on the clock nets. The group can be any name as long as it is unique to the set of nets you want to be balanced against eacho ther.

set_property CLOCK_DELAY_GROUP MUX_and_BUFGCE [get_nets {green_net red_net}]

With this set (after you re-run place and route) these domains should be properly balanced.

By the way, there is no problem with balancing a BUFGCTRL (MUX) and a BUFGCE against each other - these are similar resources and both driving global clocking nets - the path you are showing should be fine. However, you will need some other constraints to deal with the "other" clock. As is, the tool will time TWO paths - one from the source FF on the BUFGCE clock to the destination FF clocked on the clock on I1 (I am assuming the bottom one is I1), and a second path from the source FF (on BUFGCE) to the destination FF clocked by the clock on I0. If this second path is not a real path, then you will need an exception to declare it false.

Avrum

View solution in original post

3 Replies
Highlighted
Guide
Guide
5,121 Views
Registered: ‎01-23-2009

You need to call attention to the fact that this is UltraScale (you mention it at the end).

As opposed to all other FPGAs, the clock networks in UltraScale are not fixed - while they use dedicated routing, the tool creates different trees for each different domain. As a result, the domains can be unbalanced as you have found.

But the good news is there is an property specifically for this situation!

If you want two (or more) clock nets to be balanced against each other, you give them the same CLOCK_DELAY_GROUP. This instructs the tool to make sure that the CLOCK_ROOT of these domains are located in the same clock region. You do this on the clock nets. The group can be any name as long as it is unique to the set of nets you want to be balanced against eacho ther.

set_property CLOCK_DELAY_GROUP MUX_and_BUFGCE [get_nets {green_net red_net}]

With this set (after you re-run place and route) these domains should be properly balanced.

By the way, there is no problem with balancing a BUFGCTRL (MUX) and a BUFGCE against each other - these are similar resources and both driving global clocking nets - the path you are showing should be fine. However, you will need some other constraints to deal with the "other" clock. As is, the tool will time TWO paths - one from the source FF on the BUFGCE clock to the destination FF clocked on the clock on I1 (I am assuming the bottom one is I1), and a second path from the source FF (on BUFGCE) to the destination FF clocked by the clock on I0. If this second path is not a real path, then you will need an exception to declare it false.

Avrum

View solution in original post

Highlighted
Guide
Guide
3,890 Views
Registered: ‎01-23-2009

As for the mismatch in properties, the "Clock region" is telling you the clock region of the buffer - the CLOCK_ROOT is different, it is the clock region where the clock net makes the transition from the "clock routing network" to the "clock distribution network". These are independent things...

 

And the tools are clearly telling you that the CLOCK_ROOTs are in different clock regions (X5Y3 and X3Y5) - the CLOCK_DELAY_GROUP will ensure that the CLOCK_ROOTs go in the same clock region, thus minimizing the skew between the networks.

 

Avrum

Highlighted
Visitor
Visitor
3,851 Views
Registered: ‎06-22-2016

Wow, that is very interesting information (I would have never guessed it). I will give that a try.

 

Thanks a lot! :D

0 Kudos