cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
368 Views
Registered: ‎03-25-2019

Generated clock problems

Jump to solution

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.

 

0 Kudos
Reply
1 Solution

Accepted Solutions
327 Views
Registered: ‎01-22-2015

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:

Fig2_32_UG903.jpg

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

View solution in original post

2 Replies
328 Views
Registered: ‎01-22-2015

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:

Fig2_32_UG903.jpg

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

View solution in original post

275 Views
Registered: ‎03-25-2019

Thanks - this helped

0 Kudos
Reply