04-12-2018 07:54 PM - edited 04-12-2018 07:56 PM
I have a design with different clock path delay due to unblanced BUFG as below figure.
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:
But the timing sometimes fail. Is there any constraint for this path ?
04-12-2018 08:15 PM
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.
- 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
04-15-2018 11:11 PM
Sorry for late to reply your message.
Question: what device is this (family, device and speed grade)?
kc705 board, speed grade -2
Question: why do you need multiple clock buffers?
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
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.
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)