Back to EECS 31L Index
EECS 31L • Study Notes • Synthesis
Mahmoud Elfar • Spring 2026 • v0.1
v0.1: Initial version
Table of Contents
Note: You need to understand all the material in this note. However, If you are studying for the exam, you may want to focus on sections 9.4 and 9.5.
Synthesis: the process of translating a design written in an HDL (Verilog or VHDL) into a lower-level representation that can be implemented in hardware.
Target: the physical hardware that will realize the design. Common targets include:
Synthesizer: a software tool that performs synthesis. It takes your Verilog code and transforms it into a netlist. The synthesizers we will use as an example in this course are Xilinx Vivado for FPGA synthesis and Yosys for primitive gate synthesis. In industry, common tools include Synopsys Design Compiler and Cadence Encounter for ASICs; Xilinx Vivado and Intel Quartus for FPGAs.
Netlist: a structural description of the design in terms of target-specific components (such as primitive gates, muxes, standard cells, FPGA resources) and the connections between them.
Bitstream: for FPGAs, the final output of synthesis and place-and-route is a bitstream (bitfile) that can be loaded onto the FPGA to configure it with the desired logic.
Common synthesis tools: Synopsys Design Compiler and Cadence Encounter for ASICs; Xilinx Vivado and Intel Quartus for FPGAs.
Not everything that can be simulated can be synthesized. This is one of the most important distinctions in hardware design.
Verilog was designed as a simulation language first. It can express things that have no meaningful hardware equivalent: # delays, $display, initial blocks, and many behavioral constructs that describe what a circuit does without specifying what components are needed to do it. A simulator can run these — it just executes the code sequentially with its notion of time. A synthesis tool cannot: it needs to infer real gates and flip-flops, and some constructs simply do not map to any hardware.
The synthesis tool reads your Verilog, infers what hardware components are implied by each construct, and builds the netlist from those inferences. This process is called inference. The tool is making judgments about what you meant, guided by a set of synthesizable patterns it recognizes.
Because of this:
#) are always ignored by synthesis. The synthesized hardware has the same timing behavior whether you wrote #5 a = b or a = b.initial blocks are not synthesizable. They do not exist in real hardware.always blocks) is synthesizable only when it follows specific rules — covered in sections 9.5 and 9.6.The complete flow from Verilog to hardware passes through several stages:
HDL description (Verilog)
│
▼
Functional simulation and verification ◄── Testbench
│
▼
HDL compiler
│ (technology-independent optimization + gate-level inference)
▼
Logic synthesis ◄── Technology library ◄── Design constraints
(technology mapping + optimization) (timing, power, area)
│
├──► FPGA netlist ──► Place and route ──► Bitfile
│
└──► ASIC netlist ──► Place and route ──► GDS2
The key stages:
Functional simulation verifies that your Verilog behaves correctly before synthesis. This is where your testbenches run. If your design passes functional simulation, you move forward.
Inference (inside the HDL compiler): the compiler converts behavioral and dataflow Verilog into an explicit structural form using only primitive operations. It identifies which constructs imply which hardware components — AND gates, MUXes, adders, flip-flops, and so on.
Technology mapping and optimization: the inferred primitive gates are replaced by actual cells from the target technology library. For FPGAs, these are look-up tables and flip-flops. For ASICs, these are standard cells. The tool optimizes the mapping to meet timing, area, and power constraints.
Place and route: the mapped cells are physically placed on the chip or FPGA and connected by routing wires. For FPGAs this produces a bitfile; for ASICs it produces a GDS2 layout file.
In Vivado, the terminology is slightly different since it is specific to Xilinx FPGAs. The stages are:
Verilog source files
│
▼
Behavioral Simulation ◄── Testbench
│
▼
RTL Elaboration
│ (parse HDL + infer RTL structures)
▼
Synthesis ◄── FPGA device/library constraints ◄── XDC constraints
│ (map RTL to FPGA primitives) (pins, clocks, timing)
▼
Synthesized Design / FPGA Netlist
│
▼
Implementation
(optimize design → place design → route design)
│
▼
Bitstream Generation
│
▼
Program Device
The slides distinguish three coding styles and what synthesis does with each. All three can describe the same hardware — they differ in how explicitly they specify the components.
always, no initial, no assign.// Explicit structural style
module pie (x, y, a, b, c);
input wire a, b, c;
output wire x, y;
wire t1, t2;
xor x1 (t1, a, b);
not n1 (x, t1);
and a1 (t2, x, c);
or o1 (y, t2, b);
endmodule
assign statements with operatorsalways) blocks.&, |, ^, ~) → primitive gates (AND, OR, XOR, NOT)?:) → multiplexer+, -) → arithmetic modules from the tool’s library (e.g., + defaults to a ripple-carry adder)// Boolean operator → AND gate + OR gate
assign z = (a & b) | c;
// Conditional operator → MUX
assign z = sel ? a : b;
// Arithmetic operator → ripple-carry adder (default)
assign {cout, sum} = x + y;
always blocks.Note: clocked means the sensitivity list contains posedge, negedge or both.
Here, we would like to predict what hardware the synthesizer will infer from a given always block (procedural block or behavioral model). But, why are we picking on always blocks?
By Inference here we mean “what kind of hardware the synthesizer will use to implement that HDL module”.
always can result in a combinational logic inference (primitive gates and muxes)always can also result in a sequential logic inference (flip-flops and registers)You should be able to predict what inference the synthesizer will make for a given always block. Here is the cheatsheet:
| Sensitivity List | |||
|---|---|---|---|
| @(*) | edge | ||
| Assignment Type | Full | CL | FF |
| Partial | Latch | FF | |