cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Prakhar
Visitor
Visitor
415 Views
Registered: ‎06-17-2020

How to report timing delay from source clock path to generated clock path in Vivado/2017.2?

simple_scenerio.jpg

In the above figure when I am reporting timing to rx_data_int, I am able to see source latency in rx_phy_mode_clk from the created clock.

I have generated clock and sourced at clk/2 block's output 

now when I am reporting timing to rx_data_out_int then I am unable to see source latency in rxclk_pcs from the created clock.

Please let me know what options could be used to report the timing of the path(purple+blue) while reporting timing for rxclk_pcs?

Using vivado/2017.2 version

0 Kudos
1 Reply
avrumw
Guide
Guide
388 Views
Registered: ‎01-23-2009

Any timing analysis considers the source clock delay and destination clock delay, so you should see it on this path assuming the constraints are correct.

The problem is likely how you specified the generated clock. A clock like this must be created with  "create_generated_clock" - not a "create_clock". If you use a create_clock then you are telling the tool that this is the startpoint of the clock, and nothing upstream of that matters.

Without seeing the actual construction of this divider, I can't help you with the actual clock command - it depends on how you generate this clock internally.

I will point out to you that most ways of implementing this are not recommended in an FPGA. The clock trees in an FPGA are dedicated; taking a clock into the fabric to divide it causes lots of problems; you need to figure out what to do with the clock afterward (put it on a another dedicated clock net?) and you will have very large skew between the source clock and the divided clock - this may make it difficult or impossible to meet timing. Note: this is not a static timing analysis problem; when constrained properly, the tools can completely analyze structures like this. However, the architecture of the FPGA makes it unlikely that systems like this will meet timing.

Working with portions of the design that run at half the clock rate have a number of "good" solutions:

  • Use the full speed clock, but only enable the flip-flops updating on every second clock (with functional logic)
  • Use an MMCM/PLL to generate the divided clock and make sure the two clocks use the same type of clock buffer (and are in the same CLOCK_DELAY_GROUP for UltraScale/UltraScale+/Versal)
  • Use a BUFGCE_DIV in US/US+/Versal
  • Use a BUFGCE or BUFHCE in older architectures (or in US/US+/Versal if you can't use the BUFGCE_DIV)

Avrum

0 Kudos