Generated clock problems

[david.wende@ltts.com]

Hi,

Please see the attached schematic from Vivado and part of the XDC file that are both essential to understanding my problem.

Starting from the right hand side of the schematic:

This shows two clocks that drive logic; the clocks are "Ck_Ext" and "O".

The Ck_Ext clock relies on the first constraint to set period of 20.6 nS.

The O clock can be sourced physically from either the MMCM or the clk_UART_in pin (both can be seen on left hand side of schematic).

When it is sourced from the MMCM through gated_clk_20 there are no valid data paths between Ck_Ext and O.

When it is sourced from clk_UART_in through gated_clk_21 there ARE valid inter-clock data paths.

However, Vivado is not recognizing that these data paths should be timed.

What am I doing wrong?

Thank you.

[markg@prosensing.com · Accepted solution]

david.wende@ltts.com 

First, you should not use LUTs to multiplex clocks.  This will pull the clocks from the clock tree and make it difficult for your design to pass timing analysis.  Instead, you should use BUFGMUX to multiplex clocks.

Preventing unnecessary timing analysis for multiplexed clocks is described nicely starting on page 43 of UG903(v2020.1).   For your special situation, Fig 2-32 applies:

Then, as UG903 says, "Because only the clock domain crossing paths of the shared clock tree must be ignored, the wizard recommends to create generated clocks that are copies of clkA and clkB but that only exist on the shared clock tree. The clock groups constraint is applied to the generated clocks only, so that the paths outside the logic of the shared clock tree can still be normally timed."  Examples of the recommended "create_generated_clock" and "set_clock_groups -logically_exclusive" are then shown on page 44 of UG903.

Cheers,
Mark

[david.wende@ltts.com]

Thanks - this helped