What "Tapeout-Ready" Means: A Staged Pre-Signoff Checklist

A design is tapeout-ready when there is no remaining engineering reason to delay submission, only a calendar reason. That is a stronger statement than "it works on my testbench." It means the RTL synthesizes cleanly, lints cleanly, simulates cleanly, crosses clock domains cleanly, agrees with its post-synthesis netlist, and matches the metadata the foundry or shuttle program actually consumes. This page lists the 12 gates that block a submission. Each gate has an objective pass criterion, a tool that produces the evidence, and a pointer to the deeper concept pages. The list is ordered roughly by how often each item bites. For Tiny Tapeout submissions the bottom three items have hard enforcement; for commercial flows they map to your foundry's submission package.

The 12 things that block a tapeout submission

1. Synthesis elaborates without errors

Synthesis must reach the elaborated netlist stage with zero errors and a zero exit code. A design that simulates but fails to elaborate is not a chip. Run Yosys early; do not wait until the last week of the project. See Yosys synthesis.

2. No unintended inferred latches

An incomplete if chain in a combinational always_comb or always @* block infers a latch. Latches in a synchronous design are almost always wrong: they create timing arcs the rest of the toolchain does not analyze, and they hold stale data when you expected zero. Use always_comb and assign a default at the top of every branch. See inferred latches in Verilog.

// Wrong: latch on out when sel == 2'b11
always_comb begin
  case (sel)
    2'b00: out = a;
    2'b01: out = b;
    2'b10: out = c;
  endcase
end

// Right: default before case
always_comb begin
  out = 8'h00;
  case (sel)
    2'b00: out = a;
    2'b01: out = b;
    2'b10: out = c;
  endcase
end

3. No inferred memories you did not ask for

A large array of registers may infer a memory macro that does not exist in your target library, or may inflate the gate count to unsubmittable size. Yosys reports inferred memories during the memory pass. If the memory is intended, instantiate the foundry-provided macro explicitly. If it is not intended, narrow the array, refactor to flops, or set an attribute that pins the inference behavior. For Tiny Tapeout, all storage must fit in flops within the tile budget.

4. Every output is driven from a known state

A top-level output that is never assigned is a tristate or a floating gate input on the chip, neither of which you want. Synthesis catches the obvious cases; subtler cases (output driven only inside a case branch that the testbench never hits) hide. See output never assigned. The defensive pattern is the same as for latches: assign a default at the top of every combinational block and a reset value for every flop.

5. Lint clean at the chosen severity

Lint is the cheapest check available; running it costs seconds. Treat warnings like errors for the categories that matter: incomplete sensitivity lists, blocking assignments in always_ff, width mismatches, multiple drivers, and unused signals. Document waivers; do not silence warnings globally. See Verible lint.

6. Simulation regression green with self-checking testbench

The regression has to fail when something is wrong. A green regression with a passive testbench (no checker, no scoreboard, no assertions) is meaningless. Set a coverage target appropriate to the block (commonly 95% line, 90% branch, 100% FSM-state) and close it. See Verilator simulation.

7. Reset is correct from cold and warm starts

Every flop must reach a known state from reset, and the post-reset behavior must match across simulation and silicon. The most common bugs here are an initial block in the design that simulators honor and silicon ignores; a reset that is asserted asynchronously and deasserted asynchronously, producing recovery violations; and a missing reset on a flop that happens to power up correctly in simulation but powers up at random on the chip. Run a regression that explicitly asserts reset mid-test and verifies the design recovers.

8. CDC clean

If the design has more than one clock domain, every crossing must have a recognizable synchronizer structure. Single-bit signals take a 2-flop synchronizer; multi-bit data takes either an asynchronous FIFO or a MUX-recirc with a synchronized valid; pulses take a toggle handshake; resets need a reset synchronizer per destination domain. Functional simulation will not catch missing synchronizers. See clock domain crossing.

9. Formal smoke on critical properties

A small set of properties usually covers the highest-impact residual risk: every FSM is deadlock-free and reachable, every arbiter is fair, no X propagates to a top-level output once reset deasserts, every assertion stated in the spec is provable (or has a documented bound). SymbiYosys with Yices, Boolector, or Z3 closes these in minutes for typical block sizes.

10. EQY post-synthesis equivalence

Run equivalence between the elaborated RTL and the synthesized netlist. A pass certifies that the synthesizer did not change functional behavior. A failure points at either a synthesis bug or, more often, a non-synthesizable construct in the RTL that the synthesizer interpreted differently from the simulator. Equivalence is mandatory for any commercial flow and a strong recommendation for hobbyist tapeouts.

11. Top-level pin map matches the platform

The top-level module name, port names, port widths, and port directions must match exactly what the shuttle expects. For Tiny Tapeout this means matching the tt_um_* template (8-bit ui_in and uo_out, 8-bit bidirectional uio_in / uio_out / uio_oe, plus ena, clk, rst_n). For commercial flows it means matching whatever pin list the package layout was committed against. Mismatches here are submission-blocking, not signoff-blocking.

12. info.yaml and project metadata are correct

For Tiny Tapeout the info.yaml file declares the top-level module name, the source file list, the clock frequency, and the project author. The submission pipeline reads it before reading the RTL. A mistyped module name or a source file omitted from the list causes the build to fail before lint or synthesis even runs. For commercial flows the equivalent is the foundry submission package: layer mapping, tile footprint, IP licenses, and the BOM of macro instances.

Summary table

Tiny Tapeout specifics

Tiny Tapeout is a low-cost shuttle program that gives small designs a fixed pin interface and a tile-budgeted area. The submission pipeline runs an open flow (OpenLane / OpenROAD) on the RTL automatically. That means the bar is not a polished report; it is "does the open flow accept this RTL?"

• The top module must be named tt_um_* and follow the standard 8-bit input, 8-bit output, 8-bit bidirectional, plus enable, clock, and active-low reset interface.
• Drive every bit of uo_out; tie unused bits to 1'b0. Drive uio_oe consistently with uio_out; do not float bidirectional pins.
• Storage must fit in flops within the tile budget. There is no SRAM macro available on the smallest tile sizes.
• The clock frequency in info.yaml has to match what the design closes timing at. Aim conservative; the open flow's timing margin is small.
• No latches. The submission flow rejects designs whose synthesis pass produces unintended latches.

A pragmatic reading order

If you are putting this list into practice for the first time, start with the cheap gates and work down: lint, then elaboration, then a self-checking simulation, then synthesis with latch detection, then CDC, then equivalence. The expensive gates (formal, EQY) are worthwhile but only after the cheap ones are green; running them on a still-leaky design wastes solver time on bugs lint would have caught in seconds. For more depth see the RTL verification guide and the CDC guide.

The staged readiness checklist

The 12 gates above are ordered by how often each one bites. The same work also maps onto five sequential stages, and it is worth seeing it that way because each stage is a prerequisite for the next: there is no point chasing timing closure on RTL that still infers latches, and no point proving equivalence against a netlist whose function the testbench never pinned down. Run the stages in order and treat a stage as done only when its gates are green.

Open-tool evidence vs a foundry signoff: what each covers

This is the honest center of the page, so it is worth being precise. Pre-signoff evidence on open tools is real and reproducible — but it is not a foundry signoff, and the two cover deliberately different ground. Knowing exactly where the line falls keeps you from either under-testing (skipping cheap evidence) or over-claiming (treating open-tool green as a tapeout guarantee).

The short version: open-tool evidence proves the design is internally consistent and free of the structural and functional bugs that should never reach a foundry. A foundry signoff proves the implemented design meets the rules of the specific node on characterized libraries. The first is a precondition for the second; it is not a replacement for it, and nothing here is a certification or a guarantee of silicon success.

How ChipVerify AI accelerates this

ChipVerify AI runs the applicable automated checks among items 1 through 10 against uploaded RTL and reports the result with evidence, per-gate explanations, and links to the bug-level concept pages for any failures. The checks that need a tool, a testbench, or human judgment (and the manual or optional gates) are tracked separately rather than auto-run in a single pass. For Tiny Tapeout submissions, the public scanner at /tinytapeout checks pin-map and metadata gates (items 11 and 12) on top of the RTL readiness items. For broader pre-tapeout work, request access to the full product. ChipVerify AI does not replace foundry signoff; it eliminates the population of bugs that should never reach foundry signoff.

FAQ

Related topics by stage

This page is the hub; each gate has a deeper concept page. Work the links in stage order to build the evidence a tapeout needs.

Stage 1 — RTL clean

• RTL lint checklist — the cheapest gate; categories worth treating as errors.
• Clock domain crossing — synchronizer structures simulation will not catch.
• Reset domain crossing — the reset-side crossing hazard, structurally similar to CDC.
• Metastability — why a 2-flop synchronizer is the structure CDC looks for.
• Width mismatch in Verilog — silent truncation and extension that lint flags early.
• Inferred latches in Verilog — the latch gate that submission flows enforce.
• FSM encoding — state encoding and reachability that feed the formal smoke.

Stage 2 — Functional

• Functional coverage closure — how to set and close a coverage target that means something.
• SystemVerilog assertions — the checkers that make a green regression mean something.

Stage 3 — Equivalence

• Logical equivalence checking — proving the synthesized netlist matches the RTL.

Stage 4 — Implement

• Setup, hold and STA basics — timing closure on the implemented design.
• DFT and scan readiness — making the design testable before it is fabricated.
• Low-power and UPF basics — isolation, retention and the power-aware crossing checks.
• RTL-to-GDSII on sky130 — the open implementation flow that produces STA, DRC and LVS.

Across stages

• RTL verification — the broader flow these gates sit inside.