UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
2,382 Views
Registered: ‎06-10-2014

Automatic BUFG insertion in a design using clock gating

Hi,

 

I am facing Timing issues in my design, I know the reason but I don't know how to fix them using Vivado because of its automatic clock buffer insertion.

 

I explain my flow :

1- There is a BUFGCE instantiated in my design for manual clock gating purpose, half of the design is gated the other is not. This design is synthetized using Synplify Pro and the tools recognize the BUFGCE as a black box.

2- The Synplify synthetized netlist of is added in my Vivado project in order to run the full Synthesis/Implementation flow, targeting a Virtex-7 V2000T. 

3- Now, 2 possibles ways :

   -> I let Vivado doing the automatic clock insertion, it adds a BUFG on the primary clock entering into my design inferring cascaded BUFGs, that is resulting into an error. 

untitled.png

   -> I constraint the primary clock using:  attribute clock_buffer_type of CLK_P_2 : signal is "NONE" to force Vivado to NOT add a Clock buffer on the primary but then I have Hold timing issues between some nets from the GATED DESIGN and the NON GATED DESIGN (because they are not on the same Clock buffer level) :

untitled2.png

 

My question is : is it possible to configure Vivado to do a smart clock buffer insertion to not result into Hold timing issues with this type of implementation ?

 

 

Thanks a lot.

-Jean-Baptiste

 

 

0 Kudos
4 Replies
Highlighted
Historian
Historian
2,371 Views
Registered: ‎01-23-2009

Re: Automatic BUFG insertion in a design using clock gating

So, what you are describing in your synplify design is a problem.

 

You have inserted a clock buffer on your "gated design", but not one on your "ungated design". All clocks must have at least one clock buffer before the leaf cells - otherwise the clock is a local clock which creates hold time problems.

 

Vivado recognizes that there are unbuffered clock loads, so it puts in a BUFG on the input to fix it, which leads to the cascaded buffer. If you force it not to, then it leaves the "ungated design" on a local clock.

 

The solution is to manually insert a BUFG in front of the "ungated design". This way all your loads go through a clock buffer, so Vivado will not try and insert another one (you won't even need to force it).

 

Furthermore, since both buffers are essentially the same insertion delay (see caveat below) then the clocks for the gated and ungated designs will have very small skew, and hence you will not likely have hold time issues crossing between the two domains.

 

The caveat is if this is UltraScale or UltraScale+. In all previous families, all global clock buffers (BUFG, BUFGCE, BUFGMUX, BUFGCTRL) have very similar insertion delays and routing paths to the loads. In UltraScale/UtraScale+ this is no longer true, since the tools dynamically build the clock tree and determine where the CLOCK_ROOT is to be placed. If you want to clock domains to be skew matched (in this case the gated and ungated clock) then you need to put them in the same CLOCK_DELAY_GROUP. See this post on the CLOCK_DELAY_GROUP.

 

Avrum

0 Kudos
2,323 Views
Registered: ‎06-10-2014

Re: Automatic BUFG insertion in a design using clock gating

Hi Avrum, Thanks for the reply.

 

Actually I tried a run without the attribute on the clock buffer, and it went fine this time.. 

I don't understand why because I was expecting a "Cascaded buffers error" or Hold Timing issues between nets of the gated and non gated design. 

 

I can also see from the Clock network report and the schematic that there are the 2 cascades :

IBUDS -> BUFG -> BUFGCTRL (the clock gate) -> Core clock of the gated design. 

IBUDS -> BUFG -> clock of the non-gated design. 

 

clocknetwork.png

 

How is it possible to not having the cascaded BUFG error neither Hold Timing issues in this case ?

 

-Jean-Baptiste

 

 

0 Kudos
Historian
Historian
2,315 Views
Registered: ‎01-23-2009

Re: Automatic BUFG insertion in a design using clock gating

and it went fine this time.. 

 

Well, it didn't go fine - it still cascaded buffers! My answer is the same - manually insert both buffers in parallel.

 

How is it possible to not having the cascaded BUFG error neither Hold Timing issues in this case ?

 

I don't know what error you are/were seeing and/or why it isn't present now. But as for the hold times, the tool can fix hold times - potentially even the large hold time problems that you get from the extra clock buffer. The fact that it can do so, though, doesn't make this the right thing to do - the tool is using lots of routing resources to fix these hold times, and may have trouble meeting timing in other parts of the design as a result...

 

Avrum

0 Kudos
2,306 Views
Registered: ‎06-10-2014

Re: Automatic BUFG insertion in a design using clock gating

Well, it didn't go fine - it still cascaded buffers! My answer is the same - manually insert both buffers in parallel.

Actually we already used this cheat for previous projects to fix hold timing issues and we know that it is working, but we would prefer to not manually insert a "FPGA timings issues resolver" BUFG in our non-gated design because we are designing for an ASIC flow and just using the FPGA for validation.

 

Ans what I was trying to do in the first place was finding out if Vivado has an automatic way to insert clock buffers on the valid clocks paths when there is already a Clock Gate buffer (BUFGCE) instantiated. 

 

 

I don't know what error you are/were seeing and/or why it isn't present now. But as for the hold times, the tool can fix hold times - potentially even the large hold time problems that you get from the extra clock buffer. The fact that it can do so, though, doesn't make this the right thing to do - the tool is using lots of routing resources to fix these hold times, and may have trouble meeting timing in other parts of the design as a result...

I will try to catch the error message.

 

Thanks a lot,

-Jean-Baptiste

 

0 Kudos