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: 
4,196 Views
Registered: ‎01-22-2015

report_timing discussion

Jump to solution

I have questions about report_timing results given by Vivado v2016.4 for a simple timing path.

 

In the Vivado schematic shown below, the CLK_GEN block represents an MMCM used to generate the clock called clk_out2. In my HDL, I refer to clk_out2 as CLK250 (a 250MHz clock).

simple_paths1.jpg

For the path from IN2_reg/C to OUT1_reg/D, a first-order calculation for slack(setup) is done as follows (I think). For this calculation, I have pulled numbers from the report_timing results (found in attached file).

 

Arrival Time =   (clock_out2 edge_1 launch time (0.000))

                 + (delay from clkout2_buf to IN2_reg/C (1.364))

                 + (delay clock-to-out for IN2_reg (0.216))

                 + (delay of data path to OUT1_reg (0.337 + 0.043))  =  1.960

 

Required Time = (clock_out2 edge_2 launch time (4.000))

+ (delay from clkout2_buf to OUT1_reg/C (1.172)) 

- (setup requirement for OUT1_reg (0.032))  =  5.140

 

Slack(setup) = (Required Time) – (Arrival Time) = 3.180

 

My calculation (3.180) is close to the report_timing result (3.370) – whew!

 

QUESTION (one of several, I suspect):   Why does report_timing start clock delay calculations at the FPGA clock inputs, CLK_IN1_N/P?  Why not start clock delay calculations at the clk_out2 output of the MMCM (as I did above)?  Isn't everything prior to the clk_out2 output just "common path"?

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
7,406 Views
Registered: ‎01-23-2009

Re: report_timing discussion

Jump to solution

Why does report_timing start clock delay calculations at the FPGA clock inputs, CLK_IN1_N/P? 

 

The simple answer is "because it does"!

 

The more complex answer is that Vivado does timing analysis the same way for all paths, regardless of whether they have the same clock at the startpoint and endpoint or not.

 

For example, in the case where two synchronous clocks enter the device on two different ports, go through different clock networks, potentially with MMCMs/PLLs on them - this is the only (and correct way to do this).

 

Rather than have different rules and timing reports for different types of paths (based on how they are clocked), Vivado does all paths the same way. This is how it works for a setup check:

 

The clocks of the startpoint and endpoint are analyzed to determine the launch and capture edges of the path.

  - the launch and capture edges are the edges of the source clock and destination clock where the separation from the source clock edge to the destination clock edge is the smallest it can be, looking at all possible combinations of source and capture edges

 

The arrival time starts at the time of the launch edge (which isn't necessarily 0) and adds

  - the [longest] source clock delay

     - the delay from the primary clock attachment point to the startpoint (the clock pin of the clocked element)

  - the [longest] datapath delay

     - the delay from the clock pin of the clocked element, through all combinatorial elements (including the clock to out of the startpoint) to the data input of the endpoint

 

The required time starts at the time of the capture edge and

  - adds the [shortest] destination clock delay

      - the delay from the primary clock attachment point to the endpoint (the clock pin of the clocked element)

  - subtracts the setup requirement of the destination cell

  - subtracts the clock uncertainty

  - adds back the clock pessimism

 

The slack is then the required time - the arrival time.

 

This is the formula for all setup checks...

 

Avrum

0 Kudos
5 Replies
Historian
Historian
7,407 Views
Registered: ‎01-23-2009

Re: report_timing discussion

Jump to solution

Why does report_timing start clock delay calculations at the FPGA clock inputs, CLK_IN1_N/P? 

 

The simple answer is "because it does"!

 

The more complex answer is that Vivado does timing analysis the same way for all paths, regardless of whether they have the same clock at the startpoint and endpoint or not.

 

For example, in the case where two synchronous clocks enter the device on two different ports, go through different clock networks, potentially with MMCMs/PLLs on them - this is the only (and correct way to do this).

 

Rather than have different rules and timing reports for different types of paths (based on how they are clocked), Vivado does all paths the same way. This is how it works for a setup check:

 

The clocks of the startpoint and endpoint are analyzed to determine the launch and capture edges of the path.

  - the launch and capture edges are the edges of the source clock and destination clock where the separation from the source clock edge to the destination clock edge is the smallest it can be, looking at all possible combinations of source and capture edges

 

The arrival time starts at the time of the launch edge (which isn't necessarily 0) and adds

  - the [longest] source clock delay

     - the delay from the primary clock attachment point to the startpoint (the clock pin of the clocked element)

  - the [longest] datapath delay

     - the delay from the clock pin of the clocked element, through all combinatorial elements (including the clock to out of the startpoint) to the data input of the endpoint

 

The required time starts at the time of the capture edge and

  - adds the [shortest] destination clock delay

      - the delay from the primary clock attachment point to the endpoint (the clock pin of the clocked element)

  - subtracts the setup requirement of the destination cell

  - subtracts the clock uncertainty

  - adds back the clock pessimism

 

The slack is then the required time - the arrival time.

 

This is the formula for all setup checks...

 

Avrum

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
4,144 Views
Registered: ‎05-14-2008

Re: report_timing discussion

Jump to solution

The default source and destination clock path analysis is to start from the source point of the clock, for example, the clock input pad in your example. 

In your example, it is an intra-clock path and the source and destination clocks have a portion of common path. In this case, the common path segment will be removed from the calculation by "Clock Pessimism Removal" factor, as shown in below image.

clock_pessimism.png

Tags (1)
4,117 Views
Registered: ‎01-22-2015

Re: report_timing discussion

Jump to solution

Avrum – Thanks! Your example of two synchronous clocks entering the device on two different ports and going thru two MMCMs makes it clear why the general clock path must start where clocks enter the device.

 

Your comments about “[longest] source clock delay” and “[shortest] destination clock delay” prompted me to study of the report_timing results more carefully. What I called “common path” was only partially common. Delay variations thru components (eg. IBUFDS and MMCM) can cause clk_out2 edges to come out of the MMCM either early or late. Since timing analysis is pessimistic, it selects a source-clock edge that comes out late and a destination-clock edge that comes out early. This pushes the two clock edges closer together in time and results in a smaller (more pessimistic) value for slack.

 

Vivian – thanks for comments on the “clock pessimism” part of report_timing results. After reading about this more, I can see how it accounts for truly “common path” stuff and keeps calculated slack from being too pessimistic.

 

MORE QUESTIONS: Please consider the last few lines of the report_timing results (shown below):

 

   BUFGCTRL_X0Y0        BUFG (Prop_bufg_I_O)         0.072     1.628  r MYC/inst/clkout2_buf/O

                        net (fo=16, routed)          1.172     2.800    CLK250

   SLICE_X0Y225         FDRE                                          r OUT1_reg/C

                        clock pessimism             -0.471     2.329  

                        clock uncertainty           -0.065     2.263  

   SLICE_X0Y225         FDRE (Setup_fdre_C_D)        0.032     2.295    OUT1_reg    

-------------------------------------------------------------------                

                        required time                          2.295  

                        arrival time                           1.075  

-------------------------------------------------------------------

                        slack                                  3.370

 

Note that the destination-clock delay is 2.800 coming into OUT1_reg/C. Then, things get added (making slack less pessimistic) or subtracted (making slack more pessimistic). So, why is “clock pessimism(0.471)” subtracted? Also, why is “setup time(0.032)” for OUT1_reg added?  These two lines seem to contradict comments from Avrum (and my understanding).

0 Kudos
Historian
Historian
4,105 Views
Registered: ‎01-23-2009

Re: report_timing discussion

Jump to solution

So both of these are oddities are similar...

 

So, why is “clock pessimism(0.471)” subtracted? Also, why is “setup time(0.032)” for OUT1_reg added? 

 

They are not...

 

Setup time is always subtracted from the required time. However for the fabric flip-flop, the required setup time is actually negative - in this case, the requirement is -0.032ns - as long as the data arrives no later than 0.032ns after the clock edge then it will meet the setup time. Ideally the report should have shown - (-0.032), but (and this has been a pet peeve of mine since the early days of Synopsys, which does the same thing) the tool collapses the two minus signs so that it looks like addition.

 

Negative setup times are not a problem - this means that even at the cell level, the delay from the D pin to the "part of the FF that actually holds the value" is shorter than the delay from the CLK pin to the "part of the FF... that actually holds the value".

 

Similarly, the clock pessimism is always added. However, in this case, the clock pessimism is actually negative. This is a side effect of the fact that the MMCM delay is a large negative number - the way the numbers work out, the MMCM delays actually are too optimistic, and the hence a negative clock pessimism is required. Take a look at this technical blog post that addresses this question.

 

Avrum

4,049 Views
Registered: ‎01-22-2015

Re: report_timing discussion

Jump to solution

Negative pessimism (optimism?) and negative setup time – fascinating ! !   I think I’ve reached the limit of my understanding on this one. Thanks much to both of you for very patient and clear replies.

 

Mark