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

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.

by Visitor mfiorentino
on ‎03-09-2018 06:07 PM

I'm facing a problem that may be related to this (very interresting) article, maybe you can help me figure it out!


I have a post-routing simulation (back annotated with SDF) that is giving me bigger delays than my STA on a significant number of paths (same corner, post-route). We are talking of few ns.


Although I didn't expect the paths delays to be identical, as STA is supposed to report worst case scenario that may not be triggered during simulation, I certainly didn't expect simulation delays to be greater.


Modelsim reported unusual warnings (vsim-3004 and vsim-3316), which led me to this article (the details of the warning description can be found using verror 3004 and verror 3316 in a modelsim shell). Basically, it says that negative timing checks were encountered in the SDF during back-annotation. The Modelsim timing algorithm could not find any solution to satisfy them, and as a result, set the negative timing limits to zero. 


If I understood your article correctly, it seems that vivado is balancing some delays from 'interconnect' to 'setuphold' timing checks in the SDF (for some reasons which I'm not sure to understand). Now, If modelsim set all these negative limits (found in the setuphold checks) to zero, could it be cause of the differences between my simulation delays and my STA ?


Regarding how negative delays are supposed to be handled in verilog and sdf, the most relevant readings I came accross were in the IEEE standard section 15.8 : Negative timing checks.


I have investigated further, and found a details that bugs me. All the Modeslim warnings pointed to the FDCE.v flop model from the unisim library. More specifically, they pointed to the $setuphold constraint between posedge C and posedge D (same timing check in the SDF that could not be resolved by Modelsim).


Maybe I missed something, but I find the way the $setuphold function is used in the FDCE.v file a bit odd: In both the IEEE standard and the Modelsim documentation it is stated that the last two parameters for $setuphold are supposed to be delayed version of the reference and data (C and D input in this case), and are used in case of negative timing checks. In FDCE.v, the C_dly and D_dly wires fulfill this role, however, they are not assigned to anything! How could they represent delayed version of C and D if they have no physical link to them ? Maybe it is related to the way the $setuphold function works, I couldn't find enough information on this. But it also look like a trick that vivado is using, and that Modelsim is not aware of! Maybe you have more information on this.