Why do you generate an SDF file with write_sdf as part of timing signoff?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
Static timing analysis confirms the design meets timing inside PrimeTime, but other tools in the flow, gate-level simulation, other STA tools used for cross-checking, or a customer's own verification, need the same delay information in a portable, standard format. write_sdf (PT) exports PrimeTime's computed cell and net delays as a Standard Delay Format file, which is the accepted handoff format for carrying signed-off timing outside PrimeTime itself.
Technical Explanation
- SDF, Standard Delay Format, is a text format that records delay values for every timing arc in the design, independent of any one vendor's tool.
write_sdf my_design.sdf(PT) writes out the delays PrimeTime computed for the currently loaded scenario, reflecting whatever derating, parasitics, and corner were active at the time.- Gate-level simulation uses the SDF file to back-annotate real delays onto the netlist, letting a simulation catch a functional bug that only shows up with realistic timing, something a purely static check cannot do.
- Because SDF reflects one specific scenario's delays, a design signed off across many MCMM corners typically needs a separate SDF export per corner that a downstream user actually needs to simulate against.
- A mismatch between the SDF file and the SPEF or SDC used to generate it, for example exporting SDF before a late ECO's parasitics were re-extracted, hands a stale delay picture to whoever consumes the file next.
- Because it is a deliverable other tools and teams depend on, generating and archiving the right SDF file is treated as a signoff checklist item, not an optional convenience step.
Common Mistake
The Trap: Generating one SDF file from the typical corner and assuming it represents the design well enough for all downstream verification.
- Gate-level simulation looking for a worst-case timing bug needs the worst-case corner's delays, not the typical corner's, so a single generic SDF export can hide exactly the kind of failure the simulation was meant to catch.
Follow-up Question & Model Response
Why must an SDF file be regenerated after a late ECO, even if the netlist edit itself was small?
Candidate Model Response: write_sdf (PT) captures the delays PrimeTime currently has loaded, so if an ECO changed a cell or added a buffer after the last SDF export, the file no longer matches the netlist it is supposed to describe. Simulating with the old SDF against the new netlist can silently pair the wrong delay values with the wrong instances, producing a simulation result that looks fine but does not reflect the real, ECO'd design. Because the ECO also needs fresh parasitic extraction before its final timing is trustworthy, the SDF export has to come after both the netlist edit and the re-extraction, not before. Treating SDF regeneration as automatic after any late ECO avoids handing a stale timing picture downstream.
Practical Example
After fixing eleven hold violations late in signoff, the team regenerates write_sdf worst_case_corner.sdf (PT) from the post-ECO, re-extracted scenario before handing it to the gate-level simulation team, rather than reusing the SDF exported before the ECO round began.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Continue practising