Synthesis Outputs and Handoff
Every technique across this topic ends the same way: a synthesis run finishes and produces a specific set of real files. This page covers exactly what those files are, and — closing the loop this entire topic opened with — precisely which already-shipped page on this site consumes each one.
What actually comes out
- The gate-level netlist, written as structural Verilog — real, named standard cell instances (per Standard Cell Libraries) wired together, the accumulated result of every phase in the flow.
- An SDF (Standard Delay File) — the actual, characterized delay values for every cell instance in this specific netlist, at this specific set of conditions.
- The SDC file, passed forward largely unchanged from what Authoring SDC Constraints covered — the same constraints that drove synthesis continue on as the constraints later stages check against.
- Reports — timing (worst slack on every path), area (cell count and total area), and power (switching and leakage estimates) — the concrete evidence a real signoff decision is actually made from.
A naming convention worth knowing: telling RTL and netlist apart
Both the RTL source and the synthesized gate-level netlist are, syntactically, Verilog — so real flows adopt a file-naming convention to avoid ever confusing the two, since accidentally simulating or handing off the wrong one is an easy, costly mistake. A gate-level netlist is commonly written with a distinguishing suffix — .vg or .g.v — rather than the plain .v extension RTL source files use, purely so a filename alone tells a reader (or a script) which kind of Verilog it's looking at without opening the file. This is a naming convention, not a UPF/SDC-style formal requirement — different teams and flows pick their own suffix — but the underlying discipline (never let RTL and netlist filenames collide or look interchangeable) is universal.
Naming the timing report's two headline numbers: WNS and TNS
The timing report above isn't just "worst slack on every path" as a flat list — real synthesis and STA tools summarize it with two specific industry-standard metrics, both worth knowing by name since they appear in every QoR (Quality of Results) summary a real flow produces:
- WNS (Worst Negative Slack) — the slack value of the single worst-violating path in the design. If every path meets timing, WNS is zero (or positive, though tools typically clamp positive slack to a passing/non-reported state). A large negative WNS means at least one path is badly broken, regardless of how many other paths are fine.
- TNS (Total Negative Slack) — the sum of the negative slack across every violating path in the design, not just the worst one. TNS answers a different question than WNS: not "how bad is the single worst path" but "how much total timing work remains before the design is clean."
The two numbers can diverge in ways that matter for triage: a design with one catastrophically bad path and nothing else violating has a large negative WNS but a small-magnitude TNS, while a design with hundreds of paths each barely missing timing can have a modest WNS but a large negative TNS — signaling a widespread, systemic issue rather than one isolated bug. Both numbers, alongside the count of violating paths, are exactly what a report_qor-style summary command in a real synthesis tool prints alongside area and estimated wire length.
Before any of it ships: is the netlist actually clean?
A netlist finishing synthesis without a tool error isn't automatically fit to hand off — real flows run a specific set of sanity checks first, since several structural problems can slip through a "clean" run and only surface as confusing failures downstream. The recurring ones worth naming: unmapped cells (a piece of logic that technology mapping, for whatever reason, never matched to a real library cell — often from an incomplete library or an RTL construct the mapper couldn't handle), combinational loops (a feedback path with no register anywhere in it, which has no well-defined settled value and breaks both simulation and STA), floating pins/nets (an input or output left genuinely unconnected — easy to miss by eye in a netlist with thousands of instances), and unintended latches (the same incomplete-assignment mistake Verilog's and SystemVerilog's own pages already warn about, now visible as a real inferred cell in the netlist instead of a warning in RTL). Catching these before handoff, rather than after, is exactly why real flows run a structural check like check_design as a standard step, not an optional one.
Where each one goes next — a handoff already shipped elsewhere on this site
| This topic produces | Already-shipped page that consumes it |
|---|---|
| Gate-level netlist + SDF | Gate-Level Simulation & X-Propagation — runs exactly this netlist, with exactly this SDF back-annotated, catching what RTL simulation structurally can't |
| Gate-level netlist (vs. original RTL) | Property and Equivalence Checking — combinational equivalence checking proves this netlist computes the identical function the RTL did |
| SDC + netlist | Timing Verification and STA — the same constraint file, now checked against real, characterized cell delays instead of driving optimization |
| Timing/area/power reports | Verification Signoff and Metrics — real evidence feeding the "sequence of independent checks that must each pass" signoff decision |
Nothing in that table is a new connection invented for this page — every one of those Verification pages already described consuming exactly this input, before this topic existed to show where it actually came from.
Where this topic's own scope ends
What doesn't appear anywhere above, deliberately: physical placement, clock tree synthesis, routing, or anything downstream of the netlist this page describes. Physical design — turning this netlist into an actual physical layout — is real, substantial work this site doesn't cover as its own topic yet, the same honesty Timing Verification and STA already applied to its own back-end boundary. This topic's job ends exactly where a real gate-level netlist, with real timing data and real reports, exists — not one step further.
What's next
Every piece this topic set out to cover — the flow, the library, optimization, constraints, tradeoffs, clock gating, and now the handoff — exists on its own page. The capstone applies all of it to one real example: synthesizing the PWM register block already built across this site.