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!

Mismatch in Timing Numbers between SDF and STA

by Xilinx Employee ‎01-18-2018 12:11 PM - edited ‎01-19-2018 09:32 AM (313 Views)

Occasionally situations are reported where the timing numbers for individual elements during Vivado Static Timing Analysis (STA) do not match the timing numbers shown in the Simulation Standard Delay Format (SDF) file, also generated by Vivado.

 

This article lists various reasons why this discrepancy might occur, and how to interpret/reconcile the differences.

 

    1. The first thing to check is that the numbers being compared are at the same stage.
      For example, if STA is being run at the post-synthesis stage, then we should be looking at the SDF from post-synthesis, rather than from post-route.

      Most Vivado users are already familiar with the importance of keeping the design stages compared consistent.
      It is mentioned here mostly for the sake of completeness.

 

    1. Confirm that the timing corner used is the same.
      The SDF file is always written at the “slow” corner, while the STA can be performed at a different corner (for example, the “fast” corner). Vivado timing does a multi-corner analysis, and then presents/uses the most pessimistic results.
      See the attached files: STA.txt and dummy_synth_time.sdf.
      For IBUF on the clock path, the STA contains a delay of 293ps, while the SDF contains a delay of 600.5:725.7:725.7.
      In the Header portion of the STA, you will see: Path Type: .. at Fast Process Corner.
      This difference in the Process Corner used (Slow for SDF and Fast for STA) caused this mismatch in the IBUF delay.
      To resolve this difference, generate the SDF file using the –process_corner fast switch.
      The resulting file is called: fast.sdf.
      Now, you will see that the IBUF delay in the SDF file for the clock path matches: 292.7ps (-vs- 293 ps in STA).

 

  1.  Now, look at the SETUP numbers for the flop.

    The SDF file (with Fast Corner) gives the SETUP number for D as: -50.0:-44.0:-44.0, while STA considers the SETUP value to be 11 ps.

    This difference can be attributed to a difference in distribution of delays between the net and component.

    In the SDF file, some delays are lumped on the Interconnect, while in the STA file the same delay is lumped on the component.

    The net effect is the same.

    Let us trace a specific path. And to make correlation of the numbers easier, we will ignore everything else.

    Through the STA:

    Path from D pin till flop’s Data pin:

           IBUF delay = 293ps

           Net delay = 259 ps
    Delay till D pin of flop = 552ps
    Setup Value = 11ps.

    This means that the clock has to come after 563 ps.

     

    Through the SDF file: Same Path
    IBUF delay = 293ps (same as in STA)
    Net delay = 313 ps (higher than in STA, because it has an additional delay lumped on the interconnect)

     

    Delay till D pin of flop = 606 ps
    Setup Value = -44 ps (Note the negative sign).

     

    This means that the clock has to come after 562 ps   (the 1 ps difference is due to precision differences. SDF uses a higher degree of precision while writing).

     

    So as shown, there is no real difference in the end. Although the net/cell delays might be accounted for differently by the SDF and STA, the total delay for the path adds up to the same value.

     

    It is just that a portion of the delay is lumped on the Interconnect in the SDF, and on the component in the STA.

     

    Tracing through the data path should reconcile this apparent difference.

 

So now, if you see a difference in delay values in your SDF file compared to the numbers used in STA analysis by Vivado, check if the apparent differences can be explained by the above, before considering that it is a bug.

 

(Acknowledgements: Radhe Raman Singh, David Pefourque, David Sheils, Nadir Rahman for participating in the discussions).

I have also attached the source file (tt.v) and constraints (tt.xdc) which can be used to reproduce the above results on a 7vx485t-ffg1157 device with -1 speed grade.

About the Author
  • Balachander Krishnamurthy is a Sr. Product Marketing Manager for SDSoC. His responsibilities include product planning, inbound and outbound marketing for Xilinx’s Vivado SDx Design Software. Bala holds a Master's degree in Electrical Engineering from San Jose State University. He has worked at Sun Microsystems and Altera for several years in multiple roles in verification, RTL design, first silicon and board bring-up and as an ASIC Product Manager. He has more than 17 years’ experience in the GPU, CPU, ASIC and FPGA industries. His current focus is FPGA methodology for synthesis, implementation and timing closure.
  • Sanjay is Senior Director, Software Validation, at Xilinx, where he and his team validate the company’s Vivado and SDx tool chains. For more than 20 years, Sanjay has worked in EDA and VLSI in India as well as in Silicon Valley in the United States. He has worked extensively on library characterization and modeling, HDLs (focusing more on Verilog than VHDL), simulation, synthesis, static timing analysis, power, clock domain crossing and synchronization, and rule checker-based verification. Sanjay has been learning Vivado in recent years. He has published three books as co-author and editor: Principles of VLSI RTL Design – A Practical Guide, Constraining Designs for Synthesis and Timing Analysis – Using Synopsys Design Constraints, and Designing with Xilinx FPGAs – Using Vivado. In addition, Sanjay has written numerous articles and papers for trade journals and conferences. He holds three patents related to clock gating and isolation cells. A resident of Hyderabad in India, Sanjay is a graduate of the India Institute of Technology Kharagpur in electronics and electrical communications engineering.