cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
795 Views
Registered: ‎12-29-2017

How to solve timing fail with different clock path delay by using vivado?

I have a design with different clock path delay due to unblanced BUFG as below figure.

123.jpg

 

In first register, the clock will through two BUFG, but the second is one.

 

Timing constraint is here:
create_clock -name CLK -period 3.2 [get_pins CLK]

 

After the PAR, I got poor timing with this path due to unblanced start/end clock path delay.

So I made a change as follows:

456.jpg


But the timing sometimes fail. Is there any constraint for this path ?

 

Thanks

Carl

0 Kudos
2 Replies
Highlighted
Guide
Guide
784 Views
Registered: ‎01-23-2009

Re: How to solve timing fail with different clock path delay by using vivado?

Why do you have multiple clock buffers?

 

Certainly the unbalanced clock buffers will fail. At 3.2ns period, the delay of the clock buffer is almost one complete clock period. There will be no way for the tools to fix the hold time violations that result from this setup.

 

Even with the additional clock buffer (to balance), you have two entirely different buffers and networks. This means that delay on these buffers and networks will be subject to on-chip-variation skew. Again, at 3.2ns, this is going to be significant and will mess up timing.

 

So:

  - what device is this (family, device and speed grade)?

  - why do you need multiple clock buffers?

  - please post the detailed timing report from a failed path

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
720 Views
Registered: ‎12-29-2017

Re: How to solve timing fail with different clock path delay by using vivado?

Hi Avrum,

Sorry for late to reply your message.

 

Question: what device is this (family, device and speed grade)?
Reply:

kc705 board, speed grade -2

 

Question: why do you need multiple clock buffers?
Reply:

This clock architecture is related to kc705's GTX.


In my design, GTX can support different speed(10.3125G/3.125G/1.25Gbps) with supported dynamic change for my project application. (I using the GTX just PMA part, without GEARBOX enable)

 

In 10.3125G mode, I need 322.265625MHz and 156.25MHz RXCDR clock, but the GTX can only provide 322.265625MHz
RXCDR clock (RXOUTCLK), another CDRCLK(156.25MHz) is from MMCM by RXOUTCLK.

 

In 3.125G(1.25G) mode, GTX provide 20bits data with CDRCLK 156.25MHz(62.5MHz),  but my design need 10bits with CDRCLK 312.5MHz(125MHz), another bridge design and MMCM must be apply to satisfy this requirements.

 

So, the above clock architecture of the figure included in current project design.

Question: please post the detailed timing report from a failed path

Reply:

I show another constraint path that the clock period define is 3.103ns.
Although the slack is -0.182, the actual on board testing can run well.
But sometimes will get worse slack about -2 ~ -1, the huge delay may happened at data path.

serdes_timing_2_1.png

serdes_timing_2_2.png

serdes_timing_2_3.png

 

 

By the way, the method to insert the BUFG in the second register to blance timing is worked sometimes.
(I know the best way to fix this issue is that these two registers clock source all from the same BUFG)

 

Thanks

Carl

0 Kudos