Detailed Synthesis Flow
RTL to gate-level netlist stage by stage: read, elaborate (GTECH), logic optimization, technology mapping, post-map optimization, and formal equivalence.
Synthesis is a compiler for hardware. It takes your RTL (Verilog / SystemVerilog / VHDL), a technology library of real cells, and a set of timing constraints, and produces a gate-level netlist: the same behaviour rebuilt out of actual standard cells wired together. The flow is a fixed sequence of stages, and every stage narrows the design from abstract logic toward physical cells while trying to hit your timing, area and power targets.
The synthesis flow at a glance
Every synthesis tool runs the same conceptual stages, whatever the command names. You read and elaborate the RTL into a generic, technology-independent form, optimise that logic, map it onto real library cells, optimise again now that real delays are known, and write out the netlist with its forwarded constraints and reports. Two side inputs steer the whole thing: the .lib/.db library (what cells exist and how fast they are) and the SDC (how fast the design must be).
1. Read and analyze
The tool reads your HDL files and checks them for syntax and basic semantic errors, building an internal parse of each module. This step is library-independent, it is just understanding the code. Reading order and a clean file list matter here; missing or mis-ordered files surface as unresolved references later.
2. Elaboration
Elaboration builds the actual design from the top module down: it resolves parameters and generics, connects the module hierarchy, and infers hardware from your code, registers from clocked always blocks, arithmetic from + and *, muxes from case statements, and finite-state machines from your state logic. The result is a generic netlist of technology-independent gates (often called GTECH), a boolean representation that does not yet know which foundry it will be built in.
Incomplete if / case statements are the classic elaboration trap: if a combinational signal is not assigned on every path, the tool infers a latch to hold the old value. Unintended latches break timing and testability. Always complete your conditionals (a final else / default, or a default assignment) and read the latch-inference warnings.
3. Technology-independent logic optimization
Before touching real cells, the tool optimises the boolean logic itself. It propagates constants, removes unreachable and duplicate logic, shares common sub-expressions across the design, and restructures the boolean network, balancing the trade-off between a flattened form (fast, more area) and a structured form (smaller, more logic levels). Doing this on the generic netlist is cheap and sets up a better starting point for mapping.
4. Technology mapping
Mapping is where generic gates become real library cells. The tool covers the boolean network with cells from the .lib, using pattern matching and tree-covering algorithms, and chooses among the many functionally equivalent options (different drive strengths, different threshold voltages) to best meet the SDC. This is the first stage that needs both the library and the constraints, because the tool is now trading real delay, real area and real leakage against each other.
5. Post-mapping (incremental) optimization
With real cells placed in the netlist, the tool now knows real delays and can do targeted fixes: resize cells on critical paths, insert buffers to drive heavy loads or long nets, clone or duplicate cells to split high fanout, restructure the worst paths, and swap threshold voltages to recover leakage on paths that have slack. It also fixes design-rule violations, maximum transition, capacitance and fanout, which the netlist must satisfy regardless of timing.
6. Netlist, constraints and reports out
Finally the tool writes the gate-level netlist (Verilog), forwards the SDC so physical design starts from the same constraints, and emits the QoR reports, timing (WNS/TNS), area and power, plus any DRC and check-design warnings. Those reports are the contract handed to the back-end team.
The compile commands
In Synopsys Design Compiler the whole flow is usually one command, compile_ultra, wrapped by the read/constrain/report steps. In Cadence Genus the stages are explicit: syn_generic, syn_map, syn_opt. Either way the sequence maps directly onto the stages above.
# Design Compiler (concise)
read_verilog rtl/*.v
current_design top
link
source constraints.sdc ;# create_clock, I/O delays, exceptions
compile_ultra -gate_clock ;# elaborate + optimize + map + opt
report_qor ; report_timing
write -format verilog -hierarchy -output top_netlist.v
write_sdc top.sdc
# Cadence Genus (explicit stages)
read_libs *.lib
read_hdl rtl/*.v ; elaborate top
read_sdc constraints.sdc
syn_generic ; syn_map ; syn_opt ;# generic -> mapped -> optimized
write_hdl > top_netlist.v ; write_sdc > top.sdcAlways close the loop with formal equivalence
Synthesis rewrites your logic aggressively, so after it finishes you prove the netlist still matches the RTL with a logic-equivalence check (Synopsys Formality, Cadence Conformal). LEC compares the two mathematically rather than by simulation, so it catches optimisation and constraint bugs that random test vectors would miss. A synthesis run is not really done until LEC is clean.
Recap: read and elaborate RTL into generic logic, optimise it, map it to real library cells, optimise again with real delays, then write the netlist, SDC and reports. The library says what is possible and the SDC says what is required; everything in between is the tool trading timing, area and power. Finish with a formal equivalence check.