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: 
Adventurer
Adventurer
2,613 Views
Registered: ‎07-24-2016

Cascading BUFGMUXs

Greetings,

 

Quick question: Suppose that two clocks are driving the inputs of a BUFGMUX. Will the output clock have any phase difference with its associated input clock? Does this architecture contribute to phase error or clock uncertainty? 

 

Cheers!

0 Kudos
3 Replies
Scholar austin
Scholar
2,583 Views
Registered: ‎02-27-2008

Re: Cascading BUFGMUXs

c, The global and regional clocks and clock capable inputs are all matched to the specified value in the datasheet. Do not cascade BUFG, as that just doubles uncertainties.
Austin Lesea
Principal Engineer
Xilinx San Jose
Highlighted
Historian
Historian
2,568 Views
Registered: ‎01-23-2009

Re: Cascading BUFGMUXs

The answer is "yes". The BUFGMUX (and BUFG) are high drive buffers intended to drive the entire global clock network. By definition, these have relatively large propagation delays.

 

You don't tell us what the "input clocks" are - if they are already on global clock domains (i.e. already driven by BUFGs), then there will be a large clock skew between the global clocks that are the input clocks and the global clock that is the output of the BUFGMUX - like 1-3ns. This will cause significant hold time problems on any path crossing between the unMUXed domain and the MUXed domain.

 

This will manifest as a large (and PVT variable) clock skew - so neither a phase error or a clock uncertainty. just an unbalanced propagation path between the source clock delay and the destination clock delay (i.e. clock skew).

 

Avrum

Tags (1)
Adventurer
Adventurer
2,541 Views
Registered: ‎07-24-2016

Re: Cascading BUFGMUXs

@austin

@avrumw

Thank you for your replies.

 

You don't tell us what the "input clocks" are - if they are already on global clock domains (i.e. already driven by BUFGs), then there will be a large clock skew between the global clocks that are the input clocks and the global clock that is the output of the BUFGMUX - like 1-3ns. This will cause significant hold time problems on any path crossing between the unMUXed domain and the MUXed domain.

 

The output of the BUGMUX drives an external device via an ODDR. It is not used to clock any other logic, so I guess that's why I don't see any negative slack. The one input is a clock, generated by an MMCM and driven by an BUFG. The other input is driven by a Q pin of a register.

So when the user guide recommends (ug903 p.70) to avoid using LUTs to select between clocks, it does so because the output of the LUT is outside of the clock tree backbone? I thought the recommendation was given mainly because the LUT would contribute more to clock skew between the input and the output clock. And this had led me to the conclusion that cascaded BUFGMUXes are good because they are in the clock tree and because they do not skew their clocks...So we got that one out of the way.

 

However, I remember getting an error in that design (that I tackled by removing a LOC constraint from a BUFG), stating that the two cascaded BUFGMUXes are not optimally placed. Now that we agree that this architecture is just bad, then what is optimal from Vivado's point of view here? If one always gets 1-3 ns skew with this approach, does it even matter if the two BUFGMUXes are adjacent, or if their in-between routing is somehow..."optimal" to minimize skew? Is there a skewing range that Vivado deems as acceptable (e.g. 1-2 ns), and another range that is worse (>2 ns)?

 

Cheers!

0 Kudos