Yosys Open Synthesis Suite: What It Catches Before Tapeout

Yosys is a framework for RTL synthesis, technology mapping, and formal-friendly netlist transformation. Engineers reach for it when they want a fast, scriptable, free path from Verilog to a gate-level .json or BLIF netlist, and when they want lint-grade structural feedback long before a Design Compiler or Genus run reports the same thing as a critical warning. Yosys 0.64 ships in the oss-cad-suite binary release alongside Verilator, SymbiYosys, and Z3 — one tarball, one PATH, no build step.

Who maintains Yosys

Yosys was started by Claire Wolf and is now maintained by YosysHQ. The source lives at github.com/YosysHQ/yosys under ISC. It is the synthesis engine used by SymbiOS / Tabby CAD, OpenROAD, OpenLane, and most academic ASIC tape-ins. Releases are tagged regularly; yosys -V reports the build, e.g. Yosys 0.64 (git sha …).

The synthesis pipeline

Yosys is a sequence of passes you can drive interactively or from a script. A typical generic-synth flow looks like:

# top.ys
read_verilog -sv rtl/*.sv
hierarchy -check -top my_top
proc
opt
fsm
opt
memory
opt
techmap
opt
write_json out/top.json
stat

Run it with yosys -s top.ys. Each pass has a job:

• read_verilog -sv parses SystemVerilog into Yosys’ AST. Use -defer for elaboration on demand.
• hierarchy -check -top my_top walks the design from my_top down. Missing modules and parameter mismatches surface here as fatal errors.
• proc is where always blocks become muxes, registers, and latches. This is the pass that emits the famous Latch inferred for signal warning.
• opt, fsm, memory rewrite the netlist into something a tech mapper can consume. opt_clean deletes unused wires and warns when something looks dangling.
• techmap followed by a vendor pass — synth_xilinx, synth_lattice, synth_ice40, synth_ecp5, synth_intel_alm, or just synth for a generic library — produces the final mapped netlist.
• write_json emits a JSON netlist that netlistsvg can render and that nextpnr consumes for FPGA P&R.

What Yosys catches that simulation misses

Synthesis is structural. The compiler has to decide, for every signal driven inside an always block, whether to build a flop, a mux, or a level-sensitive latch. If your RTL is ambiguous, Yosys is the first tool to tell you — usually before you ever boot the simulator on the new module.

Inferred latches

Consider this almost-correct combinational decoder:

always @* begin
  case (op)
    2'b00: y = a;
    2'b01: y = b;
    2'b10: y = c;
    // missing 2'b11 - and no default
  endcase
end

The proc pass complains:

Warning: Latch inferred for signal `\decoder.y' from process `\decoder.$proc$decoder.v:5$1'.

That single warning is the highest-yield Yosys signal in practice. We break it down at /learn/inferred-latches-verilog with the four canonical patterns that produce it.

Multiply-driven nets

Two always blocks writing the same signal — a frequent merge-conflict aftermath — show up as:

Warning: multiple conflicting drivers for `\top.bus_sel'

Verilator silently picks the last assignment in the file. Yosys refuses to and tells you.

Undriven and dangling logic

After opt_clean, anything left dangling is logged:

Removed 1 unused cells and 7 unused wires.
Warning: Wire \top.tmp_dbg is used but has no driver.

That is often a typo in a port name, a forgotten assign, or an interface signal that was renamed in one of the two endpoints. Closely related: see blocking vs non-blocking assignment for the simulation-vs-synthesis mismatch this can hide.

Width mismatches and truncation

On a port connection or assignment with mismatched widths, Yosys emits warnings like Warning: Resizing cell port … or Warning: Truncating value …. They surface integer-vs-vector and parameter-vs-localparam mistakes you would otherwise hit at place-and-route.

Hierarchy and blackbox issues

hierarchy -check stops the run if anything is unresolved:

ERROR: Module `fifo_ctrl' referenced in module `top' in cell `u_fifo' is not part of the design.

Use -libdir or declare the module as (* blackbox *) when it is an external IP. A forgotten blackbox attribute is a common cause of false-fail Yosys runs in CI.

Common rule classes Yosys surfaces

• Inferred latch (proc) — incomplete combinational assignment.
• Multiply-driven net (opt_merge, proc_dff).
• Undriven wire / dangling sink (opt_clean).
• Width truncation and port resize warnings (flatten, hierarchy).
• Unsupported construct — DPI, file I/O, hierarchical reference into RTL.
• FSM extraction and one-hot encoding hints (fsm, fsm_info).
• Memory inference fallbacks — when an array can’t fold to a BRAM and degenerates to flops.

Where Yosys stops, and what to run next to it

Yosys is excellent at structural and elaboration checks. It is not a functional simulator and not a timing tool. Specifically:

• SystemVerilog support is partial. Constructs Yosys does not support — class-based UVM, complex constraints, full DPI — go through the Slang frontend (read_slang) or stay outside synthesis. Tabby CAD bundles a richer SystemVerilog frontend than upstream Yosys.
• Yosys does not give you cycle-by-cycle simulation. Pair it with Verilator or Icarus for that.
• Stylistic feedback (always_comb without default, missing reset branches, naming conventions) belongs in Verible lint — Yosys is happy to synthesize ugly-but-valid RTL.
• For property proving, drive Yosys from SymbiYosys — it lowers the design and feeds it to Z3 or Boolector.

Yosys vs Design Compiler / Genus

Commercial synthesizers (Synopsys Design Compiler, Cadence Genus, Siemens Oasys-RTL) drive sign-off-grade logic synthesis with standard-cell timing closure, multi-mode multi-corner, formal equivalence, and tight Liberty/.lib integration. Yosys targets a different point on the curve:

• Same elaboration-class warnings (latch inference, multi-driver, dangling) — usually faster on small blocks and free to run on every commit.
• No Liberty-driven QoR. Standard-cell timing, area, and power numbers from Yosys + ABC are useful for relative comparison, not for sign-off.
• Scriptable (Tcl-ish, but mostly its own command language) and CI-friendly — runs in a few seconds in a Docker container with no license server.
• Practical use: catch the bugs at every push so the nightly DC run is clean.

Quick CLI reference

# Version
yosys -V

# One-liner generic synth
yosys -p "read_verilog -sv top.sv; synth -top top; stat"

# Lint-style elaboration only (no mapping)
yosys -p "read_verilog -sv top.sv; hierarchy -check -top top; proc; opt; check -assert"

# FPGA flow (Lattice ECP5)
yosys -p "read_verilog -sv top.sv; synth_ecp5 -top top -json out.json"

# JSON for netlistsvg / nextpnr
yosys -p "read_verilog top.sv; synth -top top; write_json top.json"

The check -assert at the end of an elaboration script turns latch and multi-driver warnings into a non-zero exit. That is the form CI should run.

How ChipVerify AI integrates Yosys

ChipVerify AI runs Yosys as one of several engines. It runs when you invoke a Yosys-backed flow — synth-lint or design-structure generation — not automatically on every project. We elaborate the RTL with read_verilog -sv (Yosys’ native Verilog/SystemVerilog frontend), run hierarchy -check, drive a proc; opt; check -assert chain, and surface every latch-inferred / multi-driven / undriven warning into the unified score. Yosys timeouts and memory-pressure events are reported back with the same evidence panel as a simulator failure, so they are actionable rather than hidden in a log.

The public Tiny Tapeout scanner at /tinytapeout runs the same Yosys pipeline against any submitted design and posts a badge with the warning summary. It is the fastest way to see what Yosys says about your project without an account.