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.
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.
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).
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.