Skip to main content

Introduction

Six pages already shipped on this site quietly assume something they never explain: that RTL somehow becomes a gate-level netlist. Verilog's own conditional statements page states "synthesis infers a latch" as a fact, with no mechanism behind it. Gate-Level Simulation & X-Propagation runs against "the actual post-synthesis netlist, with real cell delays back-annotated from an SDF file" — assuming that netlist already exists. Property and Equivalence Checking proves RTL matches "a post-synthesis netlist" — again, assumed. Timing Verification and STA names the SDC file as "used by both synthesis and STA," naming synthesis as SDC's other consumer without ever showing that side of it. This topic is where all of that actually comes from.

Synthesis isn't compilation​

It's tempting to think of logic synthesis as something like compiling source code — translating one representation into another, mechanically. It isn't. A compiler's output is functionally equivalent to its input by definition; a synthesis tool's output has to be functionally equivalent and meet real, competing physical constraints: fast enough (timing), small enough (area), efficient enough (power) — constraints the tool actively trades off against each other, not just satisfies. Two synthesis runs of the identical RTL, with different constraints, produce genuinely different gate-level netlists — different cell choices, different logic restructuring, sometimes different numbers of pipeline stages. That's not something "compilation" as a word normally implies.

Scope: standard-cell (ASIC) synthesis, not FPGA synthesis​

There's a second kind of synthesis worth naming explicitly, since it's easy to conflate the two: FPGA synthesis maps a design onto an array of pre-fabricated lookup tables (LUTs) already sitting on the chip — a k-input LUT can implement any function of those k inputs, so mapping is a matter of choosing which LUTs configure to which function, not creating new physical structures. ASIC (standard-cell) synthesis — the kind this topic covers — instead maps a design onto a technology library of individually-fabricated gates (AND, OR, flip-flops, and more complex cells), each implementing exactly one fixed function, chosen from whatever library the target foundry provides. This distinction matters concretely: two logic functions that occupy identical LUT area on an FPGA (since every k-LUT is the same generic structure regardless of what it's configured to do) can occupy very different area on an ASIC, because each standard cell only pays for the specific logic it implements, not a general-purpose k-input capability. Everything in this topic — technology-independent optimization, technology mapping, SDC constraints — targets the ASIC/standard-cell flow specifically.

A third kind of "synthesis" worth ruling out: HLS​

Confusingly, "synthesis" also names a completely different, higher-level process: high-level synthesis (HLS) takes an untimed or partially-timed algorithmic description — typically C, C++, or SystemC, using ordinary software constructs like loops and arrays rather than always-on hardware processes — and automatically generates RTL from it, deciding cycle-by-cycle timing and hardware structure along the way. That RTL then still has to go through the exact logic-synthesis flow this topic covers to become a gate-level netlist; HLS produces an input to this topic's process, it doesn't replace it. The two solve genuinely different problems: this topic's synthesis maps an already-cycle-accurate RTL description onto real gates under real timing/area/power constraints; HLS's job is one level higher — deciding what that cycle-accurate RTL should even look like, starting from a specification that doesn't commit to clock-cycle behavior at all.

Where this topic sits​

  • Verilog/SystemVerilog (complete) teach the RTL language itself — including synthesizable coding style, what constructs to avoid and why. This topic assumes fluent RTL and teaches what a synthesis tool actually does with it once it's written.
  • Digital Design (complete) taught two-level Boolean minimization by hand — K-maps, Quine-McCluskey — and PLA/PAL as a two-level programmable structure. Real synthesis operates at a scale those hand techniques don't reach; this topic covers what actually happens instead, honestly addressing why the gap exists.
  • Verification (complete) checks synthesis's output — gate-level simulation runs against the netlist, equivalence checking proves it matches the RTL, timing verification checks it against the SDC file. This topic produces that netlist and authors that SDC — the same authoring-vs-checking split already established between UPF and Verification's power-aware verification page.
  • Physical design (not a topic on this site) owns everything after synthesis's netlist — placement, clock tree synthesis, routing. This topic stops at what synthesis itself produces.

What's ahead​

Section B covers the actual optimization and constraint-authoring work — technology-independent optimization, technology mapping, writing SDC constraints, and how those constraints steer synthesis decisions. Section C covers the real tradeoffs (power, performance, area), clock gating, what synthesis hands off to the topics that already consume it, and a capstone synthesizing the PWM register block already built elsewhere on this site.

What's next​

Before any optimization or constraint makes sense, the next page covers the actual sequence a synthesis tool runs through — the real four phases between RTL going in and a netlist coming out.

Test Yourself on This Section