Clock crossings, scan test and virtual bring-up

These three checks sit on a project's V&V page next to the lint, simulation, coverage and formal rows. Each one runs in the background in the lab's own tool containers (one at a time, lowest priority), keeps its files, and reports a state the lab measured: pass, fail, not run, not supported or error. The lab never shows a pass it did not measure.

Clock and reset domain crossings (CDC/RDC)#

What it checks. Your RTL is read by Yosys into a netlist of flops and logic. Every flop belongs to the clock that drives it: a clock input port is a clock domain; a flop output or a piece of logic used as a clock is a derived or gated clock, which the report flags as a domain of its own. A signal that goes from a flop in one domain into a flop in another is a crossing. It is reported safe only when it lands directly, with no logic in between, on a 2-flop synchroniser: two consecutive flops in the receiving domain with nothing between them, the first feeding only the second. Everything else is an unsafe crossing, listed with the sending flop, the receiving flop, the signal names and the file and line when Yosys kept them.

Reset domains. The report also lists reset problems: a flop whose asynchronous reset is released by a flop of another clock domain; a reset port that resets flops in two clock domains without a reset synchroniser in the second one (two flops in that domain, the first tied to a constant, the second's output used as the reset); and, inside one clock domain, a flop with one asynchronous reset feeding a flop with a different one (when the first reset fires, the second flop keeps running and can capture a changing value).

What you see. A single-clock design says "one clock domain, no crossings". Otherwise: the domains, every crossing (SAFE or UNSAFE and why), every reset issue, and the reset synchronisers the lab recognised. The state is pass only with no unsafe crossing and no reset issue. With the option on, opencdc 0.9.4 runs as a second opinion and its findings are listed with their own file:line, clearly labelled; they never change the state.

Limits. A bus synchronised bit by bit is reported safe with a note that its bits can arrive in different cycles. Handshakes, FIFOs and Gray codes are not recognised as such (their crossings are reported unsafe unless each bit lands on a 2-flop synchroniser). Timing constraints and false paths are not read. VHDL projects are not read by this check.

DFT: scan, ATPG and stuck-at fault coverage#

What it is. When a chip comes back from the fab, a tester has to find out whether every gate was made correctly. The classic way is a scan chain (every flop can be loaded and read out through one shift register) plus ATPG (automatic test pattern generation): test vectors chosen so that a wire stuck at 0 or stuck at 1 shows up at an output. The fault coverage is the share of such stuck-at faults the vectors would catch. This check runs that, at teaching level, with Fault (Cloud V's open-source DFT toolchain, version 0.9.4) on the gate-level netlist of your latest finished chip build (the synthesis netlist; since 31 October 2026 a build that failed only its sign-off checks counts, and the result says so), using the cell library's own Verilog models and liberty.

Steps.

1. fault cut cuts every flop out of the netlist, so each flop's input becomes an output the tester can see and each output an input the tester can set: the full-scan model an ATPG works on (skipped when scan is off or the netlist has no flops).
2. fault atpg generates pseudo-random stuck-at test vectors, simulates them against the cell models, keeps the ones that find new faults, and reports the coverage %, the number of (compacted) test vectors and how many faults stayed undetected. The vector budget is an option (150, 300 or 600).
3. fault chain inserts a real scan chain (scan multiplexers in front of the flops and boundary cells) and re-synthesises with the liberty; the scan-inserted netlist is kept, with the chain length.

What you see. The coverage with the number of vectors and undetected faults, each step's result, and files: the cut netlist, the scan-inserted netlist, the test vectors (Fault's JSON) and the logs. The state is pass at or above 90 % coverage (a teaching threshold, named in the text), fail below it. Try scan off on the same design to see what a scan chain buys: the ATPG then has to drive everything through the primary inputs and the coverage drops (on a counter it falls to almost nothing).

Processes. SKY130, GF180MCU and IHP SG13G2 builds are supported (their cell models and liberties are in the lab's tool image). ASAP7 is not: it is a teaching process whose models are not in the image, and the row says so. A build that kept no gate-level netlist is reported the same way, and so is a build that uses one of the kit's memory blocks (SRAM macros): Fault works on standard cells, and the lab has no gate-level fault model of a memory block. The What the lab checks table on each process page has a DFT row with the same support level.

On the way to a real chip. This check shows whether the netlist is testable at teaching level. A normal build has no scan chain in its layout; the V&V check DFT: scan chain built into the chip builds one into a separate -scan project and checks it. The lab does not test real chips. Everything the lab does and does not do between a layout and a working chip is on one page: Manufacturing boundary.

Transition (at-speed) faults. With scan on, the same check also grades transition faults (a wire too slow to rise or to fall) with launch-on-capture pairs: Fault's vectors plus seeded random pairs, the primary inputs held, at logic level (no path delays). The result gives the coverage, the coverage if the inputs could change at launch, and every undetected transition fault by name. How it works and the measured numbers: Seeds, proof limits, equivalence and the SystemVerilog subset.

Limits. This is pseudo-random ATPG with a budget, not a deterministic full run; coverage can be a few percent below what a commercial tool reaches. Netlists of more than about 8,000 cells are reported as unsupported up front: the Fault tool did not finish on a 20,000-cell CPU (31 Oct 2026). The undetected stuck-at faults are listed by name (undetected.txt).

Virtual power-on and bring-up#

What it is. A scripted simulation of the chip as a test engineer would exercise it at power-on, on the gate-level netlist of your latest finished build (passed, or failed only on sign-off) with the cell library's functional models (labelled "gate-level"). When there is no finished build, no netlist, or the process has no models in the image (ASAP7), the lab runs your RTL instead and labels the result "RTL, not gate-level". When the build uses one of the kit's memory blocks (SRAM macros), the bench also compiles the block's behavioural model from the lab's catalog and the row says "gate-level with the SRAM macro model"; a netlist that uses a module the lab has no model for is reported as unsupported with that module's name. A memory block's model returns X for words never written (a real chip reads whatever is in the cells), so outputs that carry the block's read data (the lab traces them in the netlist) are reported as information rather than a failed reset; the state then comes from your sequence, or reads measured when the project has no bringup/sequence.txt yet.

Scenarios.

1. Reset. Every input at 0, reset held 5 clocks, released. Every output must be known (no X bits) within 20 clocks; the values after reset are recorded.
2. Register access. When the ports look like a register interface (addr/wdata/rdata with a write enable, or APB psel/penable/pwrite/paddr/pwdata/prdata, or Wishbone cyc/stb/we/adr/dat_i/dat_o/ack), the lab writes a pattern to register 0 and reads it back. The result is reported as a measurement, not a verdict: register 0 may not be a plain read/write register. Otherwise the row says "no register interface detected: reset and idle scenarios only" and checks that the outputs stay known for 20 more clocks.
3. Your sequence. A file bringup/sequence.txt in the project, one step per line: reset, write <input>=<hex>, wait <n>, expect <port>=<hex>; lines starting with # are notes. The lab executes it step by step. An expect with the wrong value is a failed step that shows the actual value. Project → V&V → Bring-up sequence shows the file, the ports you can use, and writes a starter from your design's ports.

What you see. View the power-on on the row opens a page that draws what happened in order (reset held and released, outputs known, every step of your sequence, the failed step in red) and shows the recorded signals (clock, reset, inputs, outputs) in the waveform viewer with a marker at each event; Jump to reset release puts the cursor there. Below it: the step-by-step log with simulation times in ns, the values after reset, and files: the waveform (VCD, to download), the log and the generated testbench. The state is fail when an output is still X after reset, when an expect fails, or when the simulation could not run; pass otherwise.

Limits. Ports whose width is a parameter are driven as 64-bit values. inout ports are left undriven. The bench drives the clock at 100 MHz in simulation time; it says nothing about real timing (that is the build's timing report).

Ask Nelix Agent on the Bring-up sequence page opens Design Chat with the design's ports and the state of bringup/sequence.txt in the question: suggest sequence lines for this design, explain a line the lab cannot read, or review the file.