vyges-lvs — layout-vs-schematic
Part of the Vyges Loom suite. Install once with
vyges install loom, then runvyges loom lvs. It’s also a standalonevyges-lvsbinary on your PATH (the integration contract for flow authors).
vyges-lvs answers one question: does the layout implement the schematic? It
matches the two netlists as graphs — name-independent colour-refinement — and
returns a MATCH / MISMATCH verdict. When they diverge, it names the unmatched
devices and nets, where the open incumbent (Netgen) prints a terse “do not match.”
It can also extract the layout netlist straight from a GDS, so you don’t need a
separate extractor in the loop.
Run it
vyges install loom # one-time: fetch the Loom suite
vyges loom lvs demo # instant: built-in netlist pair → verdict
vyges loom lvs run block.lvs # MATCH / MISMATCH + diagnostics
vyges loom lvs run block.lvs --fail-on-mismatch # exit 3 if not equivalent (CI gate)
vyges loom lvs extract block.gds --rules sky130.rules --top block # native GDS → SPICE
See the full CLI reference (generated from --help).
Where it sits
Layout netlist (or GDS + a layer .rules deck) + the schematic → MATCH / MISMATCH.
It’s the layout-correctness check at sign-off, beside the timing / power / PI
engines. Designed to gate CI: a mismatch returns a distinct non-zero exit code. See
the data spine.
Correlated against the golden tools
On real sky130, vyges-lvs is checked against the reference open tools: native GDS
extraction is net-level identical to Magic on a standard cell (a full LVS MATCH,
hvt included); on a placed-and-routed block (the counter through OpenLane, 229 cell
instances) it reaches exact device parity with Magic — 842 transistors,
421 n / 421 p — in ~1.5 s; and on the verdict it agrees 3/3 with Netgen, while
naming the unmatched classes. Detail lives in the repo’s correlation/.
Source & releases
- Repo: https://github.com/vyges-tools/lvs
- Binaries: https://github.com/vyges-tools/lvs/releases
- Apache-2.0. Per-foundry device-recognition decks are separate (NDA).