Reference checks and release gate

A toolchain that never fails anything proves nothing. Before a release, the lab therefore rebuilds a small set of reference designs with a known fault each and checks that the tools say what they must. The same set, built clean, is the positive control. The results are kept with job ids and tool versions, so a claim like "DRC catches spacing violations on SKY130" always points at a stored build.

The reference set#

The blocks are written by vvrefs/make_macros.py as plain GDSII and LEF (no library), included in the build as a macro (MACROS in openlane/config.json) and instantiated once in the RTL. The two layout references set ERROR_ON_MAGIC_DRC, ERROR_ON_KLAYOUT_DRC and ERROR_ON_LVS_ERROR to false so the flow runs through sign-off and the lab's own pass rule (the counts in the report) is what has to catch the fault, which is the stricter test. The LVS reference also sets MAGIC_EXT_USE_GDS so the extraction reads the real layout; the flow's default reads the abstract view and would not see a short inside a block.

The antenna reference turns off, in its own openlane/config.json only, every antenna repair the flows have: GRT_REPAIR_ANTENNAS, RUN_HEURISTIC_DIODE_INSERTION, DIODE_ON_PORTS (none), the input buffer (DESIGN_REPAIR_BUFFER_INPUT_PORTS), and on IHP also LibreLane's repair during detailed routing (DRT_ANTENNA_REPAIR_ITERS 0). Every other project keeps the lab's usual repair. Why it is off: with repair on, the flows fix this fault, which is what they should do. Measured: the same design with the usual settings, SKY130 BLD-20261030-0047, had 2 nets over the limit at the first antenna check and 0 after diode insertion (PASSED); on IHP the first antenna-fail build, BLD-20261030-0040, still had LibreLane's routing repair on, which inserted 1 diode, so it PASSED and the gate said FAIL (not caught) until that repair was switched off too.

In the lab the references are ordinary projects of the lab's test account, named vvref-<name>-<process>. Their reports open like any other build report.

Latest run (30 October 2026)#

Record 20261030-155141 with seven references per process, adding antenna-fail (OpenLane's antenna repair is switched off in that reference only, so the planted violation stays): 25 PASS, 3 not applicable, 0 FAIL. The 29 and 30 October results are identical on ASAP7, GF180MCU and IHP SG13G2; on SKY130 the verdicts are identical and the numbers moved only because the builds started using each project's own clock file. A planted-rule DRC regression adds 6 to 8 different rules per deck (SKY130 8, GF180MCU 7, IHP SG13G2 7 Magic / 6 KLayout), every one caught. The gate reruns every Sunday.

What was measured (29 October 2026, all four processes)#

On SKY130 and GF180MCU, OpenLane 2.3.10 stops a build with "Setup violations found", so the lab's report shows "Tool exited with code 2" and no slack; the slack above is read from the run folder.

The gate records are kept in /var/lib/nelix-complete/vv-gate/. All four are PASS:

The automated tests below passed on 29 October 2026 (record tests-20261029-061347: 66 cases, 0 failed).

Rerun on 30 October 2026: do the results agree?#

Every reference was rebuilt through the lab on every process a second time, on 30 October 2026 (record 20261030-124238), and compared with the 29 October records (sudo nelix-vv-gate --compare; final comparison of all four processes kept as compare-20261030-155239). A third SKY130 rebuild the same day (record 20261030-143008, BLD-20261030-0033 to -0037) agrees with the first 30 October one in every verdict and number (compare-20261030-155243, 0 differences): with the same inputs the builds repeat exactly.

GF180MCU with KLayout. OpenLane does not run KLayout DRC on GF180MCU, so the gate now runs the GF180 kit's own KLayout deck on the final layout of the spacing reference and of the clean reference (record 20261030-135629): the spacing reference shows exactly the planted rule, M1.2a (metal-1 spacing), 1 marker; the clean reference shows 0 markers in 649 rules. The result is kept per layout fingerprint (sha256) and reused for the same layout.

The layer numbers and spacing rules of the hand-made layout blocks are each kit's own: GF180 Metal1 34/0, 0.23 µm; IHP Metal1 8/0, 0.18 µm. ASAP7 has no sign-off DRC or LVS in the lab, because it is learning only, so the DRC and LVS references do not apply there. What these results mean for the size of design the lab has shown clean is on Qualification envelope.

Antenna reference (30 October 2026)#

The same references through sudo nelix-ci run exit with code 60 (antenna) on all three: CI-20261030-152952-fe7382 (SKY130, BLD-20261030-0054), CI-20261030-153156-d910ec (GF180, BLD-20261030-0055), CI-20261030-153350-715a05 (IHP, BLD-20261030-0056). Code 60 means "antenna violations left after the flow's repair"; in this reference the repair is off on purpose.

Planted-rule DRC regression (30 October 2026)#

sudo nelix-vv-gate --drc-rules --pdk sky130A,gf180mcuD,ihp-sg13g2 checks that each process's two DRC rule decks still catch several different, named rules on a real layout. It takes the final layout of the latest passed clean reference, writes a copy with small planted faults beside the chip (a line too narrow, two shapes too close, a shape too small, on metal 1, 2 and 3, and SKY130's local interconnect), and runs the kit's own Magic and KLayout decks, with the options the chip build uses, on the copy and on the untouched layout. A planted fault counts as caught only when the deck reports that rule's own name inside the fault's spot. The untouched layout must show none of the planted rules (the control). It builds nothing; it checks the decks, not the design.

Record drcrules-20261030-154446, PASS; the planted layouts and both decks' reports are kept under vv-gate/drc-rules/<layout sha256>/. The first live run (15:26 UTC) said FAIL: the untouched layout is stored readable by the lab only, so the check container could not open it, and Magic then checked an empty cell. The check now copies the layout first and counts Magic as not run unless it reports the chip's own outline.

The same build twice on IHP and ASAP7 (30 October 2026)#

The clean reference was built twice in a row on each process through the lab (input fingerprint taken before each build, as on SKY130 and GF180):

Both were also rebuilt from their downloaded bundle alone (sh reproduce/rebuild.sh). An earlier pair (IHP BLD-20261030-0017 against -0045, ASAP7 -0030 against -0046) had identical numbers but different fingerprints: the lab's own build software had been updated in between (one more file), and the fingerprint said so.

The release gate#

sudo nelix-vv-gate runs the fast part (lint and simulation of every reference, offline, one at a time, at the lowest priority) and compares the latest stored chip build of each reference with its expectation. --build rebuilds the references through the lab first (one at a time; it waits while anyone else has work queued, 5 to 20 minutes each). --tests also runs the automated tests below. Every run is kept under /var/lib/nelix-complete/vv-gate/ with the tool versions and image fingerprints it ran with and every job id. Site administrators see the runs at /app/admin/vv-gate.

--compare OLD.json NEW.json lines up two runs reference by reference (verdict, build state, setup slack, DRC, LVS and antenna counts, lint codes, simulation counts, GF180 KLayout markers) and keeps the comparison. A weekly rerun (Sunday 03:30 UTC, every reference on every process, compared with the previous full run) is on since 30 October 2026 (owner approved): sudo nelix-vv-gate --schedule on|off|status. Its first run is Sunday 1 November 2026, 03:30 UTC.

The rule is strict: a reference counts as as expected only on measured evidence (a kept report, a job log, a run folder); without evidence it is not run, never a pass.

Automated tests kept with the gate#

Limits#

• The gate proves the tools catch these faults. It is not a full regression of every rule in a design-rule deck.
• Build results depend on the images and kits in use; the gate records their fingerprints so a change is visible.
• Each process was gated on 29 and 30 October 2026 and every reference agrees between the two days (SKY130's numbers moved only because its input constraints changed, see above).
• A build that cannot run (for example a full disk) counts as a failure with its reason, never as caught.
• On GF180MCU the DRC reference is caught by Magic in the build and by the kit's KLayout deck in the gate (the build itself runs no KLayout DRC).
• The planted-rule regression covers 6 to 8 width, spacing and area rules per deck, not every rule (vias, enclosures, density and the front-end layers are not planted).

Ask Nelix Agent under a gate run opens Design Chat with that run's verdict and every reference that is not as expected (or not run) in the question: what it means for a release and what to check first. The gate's verdicts come from the kept evidence only; the Agent never changes them.