cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
patolsky
Contributor
Contributor
246 Views
Registered: ‎05-07-2018

Timing violation between GTWIZARD and BUGCTRL_MUX

Hi,

I am using Vivado 2020.1 and ZCU216 EVB.

My design includes example design of GTWIZARD IP , in the example design they are using only one clock(master) of the outputs clocks rxoutclk[3:0]/txoutclk[3:0] (4 lanes).

In my design I am using bugctrl to select one clock of rxoutclk[3:0]/txoutclk[3:0].

as you can see in the figure:

rxclkmux.png

But after implementation I got timing violation because of the source clock path: the wire passes from one side to the other of the chip(to the bufgctrl) and get back to user clock(gtwizard input)

clk_route.pngsource_clock_path.png

 

Is there a way to handle this issue?

I posted this question in transceiver forum and there Roym direct me to this forum. Re: BUFGMUX for output clock from gtwiz - Community Forums (xilinx.com)

Thanks,

Patolsky

0 Kudos
1 Reply
avrumw
Expert
Expert
215 Views
Registered: ‎01-23-2009

My basic answer is "Don't do this" (unless you absolutely have to)...

Multiple clock MUXing should be avoided - the routing is pretty bad. Furthermore, as you see here, the BUFGMUXes are all in the I/O column, which is on the opposite side to the GTs. So this is the best you are going to get in terms of routing.

But I have a couple of questions:

First, what is the actual problem? A delay on the path between the RXOUTCLK and the RXUSRCLK shouldn't create a violation - by design these two clocks are designed to be mesochronous. So even with this large delay, you shouldn't inherently get a failure. What is actually failing - is the actual failing path on one of the GT data outputs? If so, it probably has more to do with how you are clocking the endpoint of the path. You need to show us the entire failing path.

Second (and probably the more important question) - why are you MUXing the different RXOUTCLKs and selecting one as the RXUSRCLK?

If you are clocking multiple GTs with the same RXUSRCLK (I am assuming all the RXOUTCLK are programmed to select the recovered clocks - RXRECCLK) there are two possibilities:

  • The channels are all using clock correction so are absorbing any frequency difference between the multiple RXRECCLKs
  • The transmitters that are the link partners for all four GTs are using the same reference clock in the transmitter, so all four RXRECCLKs are mesochronous

In both of these cases, you shouldn't need to MUX the four clocks together.

In the first case, the clock correction will be able to correct the clock using any "close enough" clock - you can use any one of the RXRECCLK or even the local RX clock.

In the second case since all four RXRECCLK are mesochronous, you can use any one of them to drive the four GTs.

So why do you need to do this MUXing?

Avrum

0 Kudos