Part I·Architectural Foundations·Chapter 12 of 66

Part IArchitectural Foundations

Lab --- The Open-Source HDL Workflow

August 3, 2026·23 min read·beginner

Chapter 11 used Chisel and Verilator to design and simulate a 32-bit ALU. That workflow covers the write-simulate-debug cycle but leaves out two important steps in the digital design flow: synthesis (translating RTL to gates) and event-driven simulation (running a Verilog testbench with full timing). This lab chapter fills those gaps by introducing the open-source HDL workflow that the reader will use for the rest of the book’s projects and labs.

The workflow has five tools. Yosys reads Verilog, optimizes the logic, and maps it to a gate-level netlist. Icarus Verilog (iverilog) provides event-driven simulation with full Verilog timing semantics. Verilator provides fast cycle-accurate simulation for regression testing. Surfer displays the waveforms. Netlistsvg renders the synthesized netlist as a schematic diagram. Together, these five tools give the reader a complete, cross-platform, zero-cost alternative to the commercial EDA suites (Synopsys, Cadence, Siemens) that cost hundreds of thousands of dollars per seat.

01.Setup and Installation

macOS (Homebrew)

macOS setup via Homebrew

Bash

# Yosys (synthesis)
brew install yosys
# Icarus Verilog (event-driven simulation)
brew install icarus-verilog
# Verilator (cycle-accurate simulation)
brew install verilator
# Surfer (waveform viewer)
brew install --cask surfer
# Netlistsvg (netlist visualization, requires Node.js)
brew install node
npm install -g netlistsvg

Verify macOS installations

Bash

yosys -V              # Yosys 0.4x
iverilog -V           # Icarus Verilog version 1x.x
verilator --version   # Verilator 5.x
surfer --version
netlistsvg --version  # should print a version number

Linux (Arch as canonical)

Arch Linux setup

Bash

sudo pacman -S yosys iverilog verilator nodejs npm
yay -S surfer
npm install -g netlistsvg

For Debian/Ubuntu:

Debian/Ubuntu alternative

Bash

sudo apt install yosys iverilog verilator nodejs npm
npm install -g netlistsvg
# Surfer: download AppImage from the Surfer GitHub releases

For Fedora:

Fedora alternative

Bash

sudo dnf install yosys iverilog verilator nodejs npm
npm install -g netlistsvg
# Surfer: same as Debian instructions

Windows (ArchWSL recommended)

Yosys and Icarus Verilog have limited native Windows support. The recommended path is ArchWSL under WSL2:

Windows setup via WSL2 (ArchWSL)

Bash

# Inside the ArchWSL terminal:
sudo pacman -S yosys iverilog verilator nodejs npm
yay -S surfer
npm install -g netlistsvg

Surfer also has a native Windows binary. Download it from the Surfer GitHub releases page and run it on the Windows side. Pass the VCD path from within WSL2 using the /mnt/c/… mapping or copy the trace file to the Windows filesystem.

02.Lab Exercise 1: Event-Driven Simulation with Icarus Verilog

The goal of this exercise is to write a small Verilog design, write a testbench, simulate with Icarus Verilog, and view the waveform in Surfer.

The design: a 4-bit ripple-carry adder

A 4-bit ripple-carry adder in Verilog

Verilog

module rca4 (
  input  [3:0] a, b,
  input        cin,
  output [3:0] sum,
  output       cout
);
  wire [4:0] carry;
  assign carry[0] = cin;

  genvar i;
  generate
    for (i = 0; i < 4; i = i + 1) begin : fa
      assign sum[i]     = a[i] ^ b[i] ^ carry[i];
      assign carry[i+1] = (a[i] & b[i]) |
                          (a[i] & carry[i]) |
                          (b[i] & carry[i]);
    end
  endgenerate

  assign cout = carry[4];
endmodule

The generate for loop unrolls at elaboration time, producing four full-adder stages connected by the carry chain. This is structural Verilog: each iteration describes one piece of hardware that exists simultaneously with all the others.

The testbench

Testbench for the 4-bit adder

Verilog

`timescale 1ns / 1ps

module rca4_tb;
  reg  [3:0] a, b;
  reg        cin;
  wire [3:0] sum;
  wire       cout;

  rca4 dut (.a(a), .b(b), .cin(cin),
            .sum(sum), .cout(cout));

  initial begin
    $dumpfile("rca4.vcd");
    $dumpvars(0, rca4_tb);

    // Test vector 1: 5 + 3 = 8
    a = 4'd5; b = 4'd3; cin = 0;
    #10;

    // Test vector 2: 15 + 1 = 16 (overflow)
    a = 4'd15; b = 4'd1; cin = 0;
    #10;

    // Test vector 3: 7 + 8 + 1 = 16 (carry-in)
    a = 4'd7; b = 4'd8; cin = 1;
    #10;

    // Test vector 4: 0 + 0 + 0 = 0
    a = 4'd0; b = 4'd0; cin = 0;
    #10;

    $finish;
  end

  // Self-checking
  reg [4:0] expected;
  always @(*) begin
    expected = a + b + cin;
    #1;
    if ({cout, sum} !== expected)
      $display("FAIL: %d + %d + %d = %d, got %d",
              a, b, cin, expected, {cout, sum});
  end
endmodule

Running the simulation

Compile and simulate with Icarus Verilog

Bash

# Compile the design and testbench
iverilog -o rca4_sim rca4.v rca4_tb.v
# Run the simulation (produces rca4.vcd)
vvp rca4_sim
# Open the waveform
surfer rca4.vcd

In Surfer, add signals a, b, cin, sum, and cout to the waveform display. Verify that the sum and carry-out match the expected values at each time step.

03.Lab Exercise 2: Synthesis with Yosys

The goal of this exercise is to synthesize the 4-bit adder with Yosys and inspect the resulting gate-level netlist.

Running synthesis

Synthesize with Yosys

Bash

yosys -p "
  read_verilog rca4.v;
  synth -top rca4;
  write_json rca4.json;
  stat
"

The synth command performs technology-independent optimization (constant propagation, dead-code elimination, logic minimization). The write_json command exports the netlist in Yosys’s JSON format. The stat command prints a summary of the cell counts.

Viewing the netlist

Generate an SVG schematic from the netlist

Bash

netlistsvg rca4.json -o rca4.svg

Open rca4.svg in a web browser or image viewer. The schematic shows the gate-level structure of the adder: XOR gates for the sum bits, AND-OR trees for the carry chain, and the connections between them. Compare this with the structural Verilog source. The synthesis tool may have optimized or restructured some of the logic, but the functional equivalence is guaranteed.

Gate-level simulation

To verify that the synthesized netlist produces the same outputs as the RTL, export the netlist as Verilog and simulate it with the same testbench:

Gate-level simulation with Icarus Verilog

Bash

# Export Verilog netlist from Yosys
yosys -p "
  read_verilog rca4.v;
  synth -top rca4;
  write_verilog rca4_gates.v
"
# Simulate the gate-level netlist
iverilog -o rca4_gate_sim rca4_gates.v rca4_tb.v
vvp rca4_gate_sim

If the testbench reports no failures, the gate-level netlist is functionally equivalent to the RTL. This is the same equivalence check (at a basic level) that ASIC design teams run after synthesis and after place-and-route.

04.Lab Exercise 3: Cycle-Accurate Simulation with Verilator

Icarus Verilog is an event-driven simulator: it re-evaluates signals whenever their inputs change, which faithfully models Verilog timing semantics (including delays and glitches) but runs slowly on large designs. Verilator takes a different approach. It compiles the RTL into a C++ class that evaluates the circuit once per clock cycle, ignoring intra-cycle glitches. The result is dramatically faster simulation at the cost of losing sub-cycle timing information.

For regression testing of processors and other large designs, Verilator is the standard choice in the open-source hardware community. The RISC-V Rocket Chip, BOOM, and many Linux-capable SoC designs use Verilator as their primary simulation platform.

A simple C++ testbench for Verilator

Verilator C++ testbench for the 4-bit adder

C++

#include "Vrca4.h"
#include "verilated.h"
#include "verilated_vcd_c.h"
#include <cstdio>

int main(int argc, char **argv) {
    Verilated::commandArgs(argc, argv);
    Verilated::traceEverOn(true);

    Vrca4 *dut = new Vrca4;
    VerilatedVcdC *vcd = new VerilatedVcdC;
    dut->trace(vcd, 99);
    vcd->open("rca4_verilator.vcd");

    int time = 0;
    int errors = 0;

    // Test all 4-bit input combinations
    for (int a = 0; a < 16; a++) {
        for (int b = 0; b < 16; b++) {
            for (int cin = 0; cin < 2; cin++) {
                dut->a   = a;
                dut->b   = b;
                dut->cin = cin;
                dut->eval();
                vcd->dump(time++);

                int expected = a + b + cin;
                int got = (dut->cout << 4) | dut->sum;
                if (got != expected) {
                    printf("FAIL: %d+%d+%d=%d, "
                          "got %d\n",
                          a, b, cin, expected, got);
                    errors++;
                }
            }
        }
    }

    vcd->close();
    delete dut;

    printf("Tests: 512, Errors: %d\n", errors);
    return errors ? 1 : 0;
}

Building and running with Verilator

Build and run the Verilator testbench

Bash

# Compile the design into C++
verilator --cc rca4.v --trace --exe tb_rca4.cpp
# Build the executable
make -C obj_dir -f Vrca4.mk
# Run the simulation
./obj_dir/Vrca4
# View the trace
surfer rca4_verilator.vcd

The Verilator simulation tests all 512 input combinations ( $16 \times 16 \times 2$ ) in a fraction of a second. Icarus Verilog also finishes this sweep quickly, because 512 vectors through a handful of gates is a trivial workload for either engine. The event-driven engine’s higher per-evaluation overhead becomes the limiting factor only once the design grows to a full CPU core and the vector count grows with it.

05.Lab Exercise 4: Putting It All Together

The final exercise applies the full workflow to a slightly larger design: the 32-bit ALU from Chapter 11, this time written in Verilog rather than Chisel.

ALU in Verilog

32-bit ALU in Verilog (abbreviated)

Verilog

module alu32 (
  input  [31:0] a, b,
  input  [3:0]  op,
  input  [4:0]  shamt,
  output reg [31:0] result,
  output            zero
);
  always @(*) begin
    case (op)
      4'b0000: result = a + b;
      4'b0001: result = a - b;
      4'b0010: result = a & b;
      4'b0011: result = a | b;
      4'b0100: result = a ^ b;
      4'b0101: result = ~(a | b);
      4'b0110: result = ($signed(a) < $signed(b))
                        ? 32'd1 : 32'd0;
      4'b0111: result = (a < b) ? 32'd1 : 32'd0;
      4'b1000: result = a << shamt;
      4'b1001: result = $signed(a) >>> shamt;
      default: result = 32'd0;
    endcase
  end

  assign zero = (result == 32'd0);
endmodule

Workflow steps

The exercise asks the reader to perform each step of the workflow:

Step 1: Simulate with Icarus Verilog. Write a Verilog testbench that tests at least five operations. Compile with iverilog, run with vvp, and inspect the VCD in Surfer.

Step 2: Simulate with Verilator. Write a C++ testbench (or use ChiselTest if the Chisel version from Chapter 11 is preferred). Run all 10 operations with multiple input vectors. Verify zero errors.

Step 3: Synthesize with Yosys. Run synth -top alu32 in Yosys. Record the cell counts from stat. Export the JSON netlist and generate an SVG schematic with Netlistsvg. Identify the adder, the mux tree, and the shifter in the schematic.

Step 4: Gate-level simulation. Export the synthesized Verilog netlist and simulate it with the same testbench. Confirm functional equivalence.

This four-step workflow (RTL simulation, cycle-accurate regression, synthesis, gate-level verification) is the backbone of every open-source hardware project. The rest of the book’s projects and labs follow this exact pattern, scaling up to pipelined CPUs, cache controllers, and multicore interconnects.

06.Tool Summary

Table 1. Open-source HDL workflow tool summary.

Tool	Role	Key command
Yosys	Synthesis	`yosys -p "read_verilog f.v; synth; write_json f.json; stat"`
Icarus Verilog	Event-driven sim	`iverilog -o sim f.v tb.v && vvp sim`
Verilator	Cycle-accurate sim	`verilator --cc f.v --trace --exe tb.cpp`
Surfer	Waveform viewer	`surfer trace.vcd`
Netlistsvg	Netlist viewer	`netlistsvg f.json -o f.svg`

07.Understanding Yosys Internals

Yosys processes a design through a pipeline of internal passes. Each pass transforms the design representation. Understanding the major passes helps the reader interpret synthesis reports and diagnose unexpected results.

Parsing. The read_verilog command parses Verilog source into Yosys’s internal abstract syntax tree (AST). SystemVerilog support is partial and requires the -sv flag. VHDL support is available through the ghdl plugin (ghdl --synth followed by read_verilog).

Elaboration. Yosys resolves parameters, unrolls generate loops, and flattens the module hierarchy (if the user requests -flatten). After elaboration, every module instance is a concrete collection of cells and wires with fixed widths.

Technology-independent optimization. The opt family of passes runs constant propagation (opt_const), dead-code elimination (opt_clean), and logic simplification (opt_reduce). These passes remove unused signals, fold constant muxes, and simplify Boolean expressions without knowing anything about the target technology.

Technology mapping. For FPGA targets, the synth_ice40, synth_ecp5, or synth_xilinx commands map the optimized logic to the target’s lookup tables (LUTs), flip-flops, and block RAMs. For ASIC targets, the abc pass (which invokes the ABC logic synthesis engine from UC Berkeley) maps logic to cells from a Liberty (.lib) standard-cell library.

Output. The mapped netlist is written in the requested format: write_verilog for Verilog, write_json for JSON (consumed by Netlistsvg and other tools), or write_blif / write_edif for other downstream tools.

Table 2. Common Yosys commands and their roles.

Command	Purpose
`read_verilog`	Parse Verilog source
`synth`	Run the full generic synthesis flow
`synth_ice40`	Synthesize for Lattice iCE40 FPGAs
`opt`	Technology-independent optimization
`abc`	Technology mapping via the ABC engine
`stat`	Print cell and wire count statistics
`write_verilog`	Export gate-level Verilog
`write_json`	Export JSON netlist for Netlistsvg
`show`	Render a GraphViz diagram (requires xdot)

08.Makefile for the Workflow

As the number of source files and tool invocations grows, typing commands by hand becomes tedious and error-prone. A Makefile automates the workflow and ensures that each step uses the correct flags and file paths.

Makefile for the open-source HDL workflow

Makefile

DESIGN   = rca4
TOP      = rca4
SOURCES  = $(DESIGN).v
TB_IV    = $(DESIGN)_tb.v
TB_VL    = tb_$(DESIGN).cpp

# Icarus Verilog simulation
.PHONY: sim-iv
sim-iv: $(DESIGN).vcd
$(DESIGN).vcd: $(SOURCES) $(TB_IV)
    iverilog -o $(DESIGN)_iv $(SOURCES) $(TB_IV)
    vvp $(DESIGN)_iv

# Verilator simulation
.PHONY: sim-vl
sim-vl: obj_dir/V$(TOP)
    ./obj_dir/V$(TOP)
obj_dir/V$(TOP): $(SOURCES) $(TB_VL)
    verilator --cc $(SOURCES) --trace \
      --exe $(TB_VL) --top-module $(TOP)
    make -C obj_dir -f V$(TOP).mk

# Yosys synthesis
.PHONY: synth
synth: $(DESIGN).json
$(DESIGN).json: $(SOURCES)
    yosys -p "read_verilog $(SOURCES); \
      synth -top $(TOP); \
      write_json $(DESIGN).json; stat"

# Netlist visualization
$(DESIGN).svg: $(DESIGN).json
    netlistsvg $(DESIGN).json -o $(DESIGN).svg

# Gate-level simulation
.PHONY: gate-sim
gate-sim: $(DESIGN)_gates.v $(TB_IV)
    iverilog -o $(DESIGN)_gate_sim \
      $(DESIGN)_gates.v $(TB_IV)
    vvp $(DESIGN)_gate_sim
$(DESIGN)_gates.v: $(SOURCES)
    yosys -p "read_verilog $(SOURCES); \
      synth -top $(TOP); \
      write_verilog $(DESIGN)_gates.v"

# View waveform
.PHONY: wave
wave: $(DESIGN).vcd
    surfer $(DESIGN).vcd

# Clean
.PHONY: clean
clean:
    rm -rf obj_dir *.vcd *.vvp *_iv *_sim \
      *.json *.svg *_gates.v

With this Makefile in place, the entire workflow reduces to a few short commands: make sim-iv for event-driven simulation, make sim-vl for Verilator regression, make synth for synthesis, make gate-sim for gate-level equivalence testing, and make wave to open Surfer. The reader should adapt this Makefile for every lab and project chapter that follows.

09.Comparing Event-Driven and Cycle-Accurate Simulation

The choice between Icarus Verilog and Verilator is not a matter of quality. It is a matter of purpose.

Event-driven simulation (Icarus Verilog) faithfully models the Verilog timing semantics. Every signal change triggers re-evaluation of every expression that depends on it. Time advances in discrete events, and the simulator can model propagation delays, setup/hold checks (with appropriate annotations), and intra-cycle glitches. The cost is speed: an event-driven simulator may run 10 to 100 times slower than a cycle-accurate simulator for the same design.

Cycle-accurate simulation (Verilator) evaluates the entire design once per clock cycle. It does not model delays or glitches. The output of every combinational path is the steady-state value, computed as if the combinational logic settles instantaneously. This abstraction matches the RTL designer’s mental model (the output is correct at the end of every clock cycle) and enables much higher simulation throughput.

For the projects in this book, Verilator is the default simulation engine. Icarus Verilog is used when the reader needs to inspect intra-cycle behavior or when a testbench relies on Verilog timing constructs (#delay, @(posedge ...) with specific timing) that Verilator does not support.

10.Debugging Strategies

When a test fails, the open-source workflow provides several approaches for locating the bug.

Waveform inspection. The first step is always to open the VCD or FST trace in Surfer and add the signals of interest. Look for the clock cycle where the actual output diverges from the expected output. Then trace backward through the combinational logic by adding intermediate signals to the waveform. Most bugs are visible as a signal that stays at an unexpected constant value (an unconnected wire, a stuck mux select) or that changes one cycle too early or too late (a missing register, an off-by-one in a counter).

Print statements. In an Icarus Verilog testbench, $display and $monitor print signal values to the console at specific simulation times. In a Verilator C++ testbench, printf serves the same role. Print statements are crude but fast, and they are often the quickest path to a diagnosis when the waveform has thousands of signals and the failing cycle is buried deep in the trace.

Assertions. SystemVerilog’s assert keyword (supported in both Icarus Verilog and Verilator with the --assert flag) checks a condition at simulation time and reports an error if it fails. Placing assertions at key points in the design (the output of every mux, the carry chain of every adder, the state register of every FSM) turns silent data corruption into an immediate, located failure.

Gate-level versus RTL comparison. If the RTL simulation passes but the gate-level simulation fails, the bug is in the synthesis mapping (rare with Yosys for combinational logic, more common when latches are inferred). If both fail identically, the bug is in the RTL. If neither fails but the waveform looks wrong, the bug is in the testbench.

11.Looking Ahead

This lab chapter completes Part I of the book. The reader now has the full set of foundational tools and concepts: the computing stack and the layers of abstraction (Chapter 1), technology trends and the quantitative principles of design (Chapter 2), number systems and encodings (Chapter 3), Boolean algebra and combinational logic (Chapter 4), digital building blocks (Chapter 5), sequential logic and timing (Chapter 6), integer and floating-point arithmetic (Chapters 7 and 8), the physics of CMOS and technology scaling (Chapter 9), hardware description languages (Chapter 10), the 32-bit ALU built in Chisel (Chapter 11), and the open-source HDL workflow (this chapter).

Part II turns to instruction set architectures: the programmer-visible contract between software and hardware. The first concept chapter (Chapter 13) opens with the anatomy of an instruction and the design decisions that distinguish one ISA family from another. The HDL and simulation skills from Chapters 10 through 12 return in full force in Part III, where the reader builds a single-cycle and then a pipelined RISC-V CPU.

12.Worked Examples

Example: Reading Yosys Statistics

After synthesizing the 4-bit ripple-carry adder, Yosys reports the following cell counts:

Plain Text

  Number of cells:    28
    $_AND_          12
    $_OR_            8
    $_XOR_           8

Explain why these counts make sense for a 4-bit adder with a carry-in.

Solution. Each full-adder bit produces a sum using XOR gates and a carry using AND-OR gates. The sum for bit $i$ is $a_{i} \oplus b_{i} \oplus c_{i}$ , which requires two XOR gates (or one 3-input XOR, which Yosys decomposes into two 2-input XOR cells). The carry for bit $i$ is $(a_{i} \cdot b_{i}) + (a_{i} \cdot c_{i}) + (b_{i} \cdot c_{i})$ , which maps to three 2-input AND gates and two 2-input OR gates.

For 4 bits with carry-in: $4 \times 2 = 8$ XOR cells for the sum bits, $4 \times 3 = 12$ AND cells and $4 \times 2 = 8$ OR cells for the carry chain, giving 28 cells in total. The exact counts depend on Yosys’s optimizer, which can push the total lower by sharing the $a_{i} \oplus b_{i}$ term between the sum and the carry and rewriting the carry as $a_{i} b_{i} + (a_{i} \oplus b_{i}) c_{i}$ , a form that costs two AND cells and one OR cell per bit instead of three and two. Either way the per-bit structure (a pair of XOR cells for the sum and a small AND-OR tree for the carry) is what a ripple-carry adder looks like at the gate level.

Example: Verilator Speed Advantage

A design contains 50,000 gates. An event-driven simulator runs at 10,000 events per millisecond of wall-clock time. Verilator compiles the design and runs at 500,000 cycles per second of wall-clock time. The 10,000 events/ms figure counts total events across all signals, and in a 50,000-gate design a single clock edge triggers events on every gate whose inputs change. Assume that a few percent of the gates toggle in a typical cycle, so each simulated clock cycle costs an average of 2,000 events. How many simulated clock cycles can each simulator complete in one minute of wall time?

Solution. Event-driven: 10,000 events/ms $= 10^{7}$ events/s. At 2,000 events per cycle, that is $10^{7} / 2{,}000 = 5 \times 10^{3}$ cycles/s. In one minute: $5 \times 10^{3} \times 60 = 3 \times 10^{5}$ cycles.

Verilator: $5 \times 10^{5}$ cycles/s. In one minute: $5 \times 10^{5} \times 60 = 3 \times 10^{7}$ cycles.

Verilator therefore completes $(3 \times 10^{7}) / (3 \times 10^{5}) = 100$ times as many cycles in the same wall-clock minute, which sits at the top of the 10 to 100 range quoted earlier in this chapter. This is why Verilator is the tool of choice for regression testing on large designs.

Example: Gate-Level Equivalence Check

After synthesizing and gate-level simulating the 4-bit adder, the testbench passes all test vectors. Does this guarantee that the synthesized netlist is functionally equivalent to the RTL for all inputs?

Solution. No. The testbench only checks the specific input vectors it applies. A 4-bit adder has $2^{4} \times 2^{4} \times 2 = 512$ possible input combinations, which is small enough to test exhaustively (the Verilator exercise does exactly this). For a 32-bit adder, exhaustive testing is infeasible ( $2^{65}$ combinations). In industrial practice, formal equivalence checking (FEC) tools mathematically prove that two netlists are equivalent for all inputs. Yosys includes a basic equivalence checker (equiv_simple), and commercial tools (Synopsys Formality, Cadence Conformal) handle full-scale designs.

Example: Interpreting a Netlistsvg Diagram

The Netlistsvg output for a 2-to-1 mux shows four cells: one labeled $_NOT_, two labeled $_AND_, and one labeled $_OR_. The select input sel feeds the inverter, whose output drives one AND gate. The other AND gate receives sel directly. Both AND outputs feed the OR gate. Explain why Yosys maps a 2-to-1 mux to this structure.

Solution. A 2-to-1 mux implements $y = (\overline{\text{sel}} \cdot a) + (\text{sel} \cdot b)$ . The $_NOT_ cell produces $\overline{\text{sel}}$ . The first AND computes $\overline{\text{sel}} \cdot a$ . The second AND computes $\text{sel} \cdot b$ . The OR combines them. This is the canonical sum-of-products implementation, and it is what Yosys produces when targeting a generic gate library with no dedicated mux cells.

13.Exercises

Exercises

Install and verify. Install all five tools (Yosys, Icarus Verilog, Verilator, Surfer, Netlistsvg) on your platform. Run the version commands from the setup section and confirm that each tool is accessible from the command line.
Simulate a decoder. Write a Verilog 3-to-8 decoder and a testbench that exhaustively tests all eight input combinations. Simulate with Icarus Verilog and view the waveform in Surfer.
Synthesize and visualize. Synthesize your 3-to-8 decoder with Yosys. Export the JSON netlist and generate an SVG schematic. How many gate cells does Yosys report? Compare the schematic with what you would expect from the decoder’s truth table.
Verilator exhaustive test. Write a Verilator C++ testbench that exhaustively tests a 4-bit multiplier (result = a * b) for all $16 \times 16 = 256$ input combinations. Report the number of errors and the simulation time.
FST versus VCD. Re-run the 4-bit adder Verilator simulation with FST output (verilator --cc --trace-fst). Compare the file size of the FST trace with the VCD trace for the same simulation. Open the FST file in Surfer and confirm it displays correctly.
Gate-level timing. Export the Yosys-synthesized Verilog netlist of the 4-bit adder. Add #1 delays to each gate (e.g., replace assign y = a & b; with assign #1 y = a & b;). Simulate with Icarus Verilog and observe the propagation ripple through the carry chain in Surfer. How many nanoseconds does the carry take to propagate from bit 0 to the carry-out?
Yosys optimization levels. Synthesize the 32-bit Verilog ALU with synth -top alu32 and record the cell count. Then synthesize again with synth -top alu32 -flatten (which removes hierarchy before optimization). Does flattening change the cell count? Explain why or why not.
Parameterizable design. Modify the 4-bit ripple-carry adder to accept a parameter WIDTH. Synthesize it for WIDTH = 4, WIDTH = 8, and WIDTH = 16. Record the cell counts. Does the cell count scale linearly with WIDTH? Explain.
Comparing Chisel and Verilog ALUs. Generate the Verilog output from the Chisel ALU of Chapter 11. Synthesize both the Chisel-generated Verilog and the hand-written Verilog ALU of this chapter with Yosys. Compare the cell counts and the critical-path estimates (if available). Are the two results equivalent?
Full workflow on a new design. Design a 4-bit up/down counter with synchronous reset and a direction control input. Follow the full four-step workflow: (1) RTL simulation with Icarus Verilog, (2) regression testing with Verilator, (3) synthesis with Yosys, (4) gate-level simulation. Report the cell count and confirm functional equivalence.

Book mode

	#0
	0!
	0"
	#10
	1!
	#20
	0!
	1"

	# Yosys (synthesis)
	brew install yosys

	# Icarus Verilog (event-driven simulation)
	brew install icarus-verilog

	# Verilator (cycle-accurate simulation)
	brew install verilator

	# Surfer (waveform viewer)
	brew install --cask surfer

	# Netlistsvg (netlist visualization, requires Node.js)
	brew install node
	npm install -g netlistsvg

	yosys -V # Yosys 0.4x
	iverilog -V # Icarus Verilog version 1x.x
	verilator --version # Verilator 5.x
	surfer --version
	netlistsvg --version # should print a version number

	sudo pacman -S yosys iverilog verilator nodejs npm
	yay -S surfer
	npm install -g netlistsvg

	sudo apt install yosys iverilog verilator nodejs npm
	npm install -g netlistsvg
	# Surfer: download AppImage from the Surfer GitHub releases

	sudo dnf install yosys iverilog verilator nodejs npm
	npm install -g netlistsvg
	# Surfer: same as Debian instructions

	# Inside the ArchWSL terminal:
	sudo pacman -S yosys iverilog verilator nodejs npm
	yay -S surfer
	npm install -g netlistsvg

	# Compile the design and testbench
	iverilog -o rca4_sim rca4.v rca4_tb.v

	# Run the simulation (produces rca4.vcd)
	vvp rca4_sim

	# Open the waveform
	surfer rca4.vcd

	yosys -p "
	read_verilog rca4.v;
	synth -top rca4;
	write_json rca4.json;
	stat
	"

	# Export Verilog netlist from Yosys
	yosys -p "
	read_verilog rca4.v;
	synth -top rca4;
	write_verilog rca4_gates.v
	"

	# Simulate the gate-level netlist
	iverilog -o rca4_gate_sim rca4_gates.v rca4_tb.v
	vvp rca4_gate_sim

	# Compile the design into C++
	verilator --cc rca4.v --trace --exe tb_rca4.cpp

	# Build the executable
	make -C obj_dir -f Vrca4.mk

	# Run the simulation
	./obj_dir/Vrca4

	# View the trace
	surfer rca4_verilator.vcd