07-21-2020 04:26 AM
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
07-21-2020 09:13 AM
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: