What Synthesis Actually Does

1. Engineering intuition — a spec compiled into gates

Think of synthesis as a compiler for hardware. Your RTL is the source: a behavioral specification of what the circuit must do — these outputs as functions of these inputs and this clock. The synthesizer is the compiler: it figures out a concrete arrangement of real gates and flip-flops that behaves the same way, then optimizes it hard and maps it onto the actual cells available in your chip. Just as a C compiler does not emit one machine instruction per line of C, synthesis does not emit one gate per line of VHDL — it is free to share, simplify, and restructure as long as the behavior is preserved. Internalizing "RTL is a spec, synthesis picks an implementation" is what stops you expecting the netlist to mirror your source.

2. Formal explanation — the synthesis stages

-- SYNTHESIS: RTL (behavioral spec) → gate-level NETLIST mapped to a target technology.
--
--  1. ELABORATE & PARSE: resolve generics, build the design hierarchy, check the synthesizable subset.
--  2. INFER hardware from RTL PATTERNS:
--        clocked process (rising_edge)      → flip-flops
--        incomplete combinational assignment → latch (usually unintended! 16.3)
--        expressions / if / case            → combinational logic (gates / LUTs)
--        array + clocked R/W                → memory (block/distributed RAM)
--        +, -, *                            → adders / multipliers (or DSP blocks)
--  3. OPTIMIZE: Boolean minimization, CONSTANT FOLDING, DEAD-LOGIC removal, RESOURCE SHARING.
--  4. TECHNOLOGY-MAP: bind the optimized logic to real target CELLS (LUTs, FFs, DSP, BRAM, carry chains).
--  5. RESULT: a netlist (+ timing/area reports). NOT 1:1 with the source.

Synthesis runs elaborate → infer → optimize → technology-map → netlist. Inference recognizes hardware from RTL patterns (clocked process → FF, expression → logic, array → RAM). Optimization restructures freely while preserving behavior. Technology mapping binds the result to the target's real primitives. The netlist is an implementation of the spec, not a transcription of the source.

3. Production usage — reading RTL as a behavioral contract

-- This RTL is a SPECIFICATION; synthesis chooses an implementation meeting it.
process (clk) begin
  if rising_edge(clk) then
    if   a = b then y <= x"01";        -- the BEHAVIOR: y as a function of inputs at the clock edge
    elsif a > b then y <= x"02";
    else             y <= x"00";
    end if;
  end if;
end process;
-- Synthesis may: build a comparator + priority mux + an output register; SHARE the a/b comparison;
-- CONSTANT-FOLD if a or b is tied; remove the register if y is unused; map it all to LUTs+FFs.
-- The resulting GATES need not resemble the source structure — only the behavior is guaranteed.

What hardware does this become? A registered comparator/select — one valid implementation among many. Synthesis might merge the a=b/a>b comparisons into shared logic, fold constants if an input is fixed, drop the output register if y feeds nothing, and pack everything into the target's LUTs and flip-flops. Two different synthesizers (or settings) can produce different netlists from this same source, all behaviorally equivalent. That is the contract: you specify behavior; synthesis owns the structure — which is exactly why you optimize by shaping the spec (coding style, Module 16.4) rather than drawing gates.

4. Structural interpretation — the synthesis pipeline

5. Why this is structural, not timing

Synthesis is a process — a pipeline that transforms a behavioral spec into a mapped netlist — so the pipeline diagram above is the right picture, not a waveform. It is a compile-time activity producing structure (gates, timing reports), not a run-time behavior; the behavior is what it preserves, already studied in the combinational/sequential modules. The substance here is the transformation — infer, optimize, map — and the mental model that RTL specifies behavior while synthesis owns the implementation, both structural rather than trace-level facts.

6. Debugging example — expecting the netlist to mirror the source

Expected: the synthesized circuit looks like the RTL — one gate per operation, registers exactly where written. Observed: the netlist has fewer (or differently-arranged) gates, shared logic, vanished signals, or constants folded away — and an engineer worries the tool "changed the design." Root cause: the mental model was RTL-as-drawing instead of RTL-as-spec: synthesis legitimately optimizes (shares comparisons, folds constants, removes dead logic) and technology-maps, so the netlist is an equivalent implementation, not a transcription. (A genuine problem would be a behavioral difference — caught by equivalence/gate-level checking, 15.5 — not mere structural difference.) Fix: verify behavior (equivalence, gate-level sim), not structure; influence the result by shaping the spec (coding style, constraints), and treat structural divergence from the source as normal optimization. Engineering takeaway: judge synthesis by behavioral equivalence, not by how much the netlist resembles your RTL — optimization and mapping make them differ by design.

-- BUG (mindset): "the netlist doesn't match my code, the tool broke it."
--   → synthesis SHARES logic, FOLDS constants, PRUNES dead nets — structural difference is expected.
-- FIX (mindset): confirm BEHAVIORAL equivalence (gate-level sim / formal equivalence);
--   shape results via coding style + constraints, not by expecting a 1:1 netlist.

7. Common mistakes & what to watch for

• Treating RTL as a gate drawing. It is a behavioral spec; synthesis chooses the implementation, so the netlist won't mirror the source.
• Judging by structure, not behavior. Verify behavioral equivalence (gate-level/formal); structural divergence from the source is normal optimization.
• Expecting identical results across tools/settings. Different synthesizers/options yield different, equivalent netlists — that is fine.
• Forgetting sim-only constructs vanish. Delays, wait-as-logic, and assertions are ignored by synthesis (16.2 / 15.5).
• Trying to micro-control gates from RTL. Influence results through coding style and constraints (16.4/16.8), not by hand-placing logic in source.

8. Engineering insight & continuity

Synthesis compiles RTL — a behavioral specification — into a technology-mapped netlist through elaborate, infer, optimize, and technology-map stages, producing an equivalent implementation that is deliberately not one-to-one with the source. The key mindset is RTL-as-spec: you own the behavior, synthesis owns the structure. For the tool to do this, your code must be synthesizable — fall within the subset it can turn into hardware — which is precisely the next lesson, The Synthesizable Subset of VHDL: which constructs map to gates and which are simulation-only.