Integrating the engines into a flow

The engines are the Vyges Loom suite — end users run them as vyges loom <engine> after a one-time vyges install loom. Under the hood each is a standalone binary that cooperates by handing the next one standard files (Liberty, SPEF, SPICE) — see the data spine. This page is for tool and flow authors (OpenROAD / LibreLane / OpenLane 2 / custom orchestrators): where each engine plugs in, and how to call it directly as a binary (the leanest integration — no vyges front door required).

Where each engine plugs into an OpenROAD / LibreLane flow

There is no single integration point — each engine is a drop-in second opinion / alternative at its own stage:

Engine	Flow stage	Sits beside (OSS)	Adds
`vyges-char`	cell characterization (upstream)	Liberate	a `.lib` when you don’t already have one
`vyges-extract`	parasitic extraction (post-route)	OpenRCX	coupling-aware SPEF (the SI input)
`vyges-power`	power analysis (post-synth / post-route)	OpenSTA `report_power`	leakage + dynamic, and the activity map em-ir needs
`vyges-sta-si`	static timing (signoff)	OpenSTA	SI/crosstalk + statistical (AOCV/POCV-LVF) OCV
`vyges-em-ir`	power integrity (PDN)	PDNSim	IR-drop / EM second opinion
`vyges-lvs`	layout-vs-schematic (signoff)	Netgen	MATCH/MISMATCH with the divergence named; native GDS extraction

“Just integrate sta-si?” Start there — it’s the highest-value single drop-in (the SI-aware timing answer base OpenSTA can’t give). Then adopt the rest à la carte, each at its own stage — not “through sta-si”: extract deepens sta-si’s SI with coupling SPEF; power feeds both a power number and em-ir; em-ir is parallel (power integrity, not timing); lvs is layout-correctness at sign-off; char only if you lack a .lib.

Already on OpenLane / LibreLane? Drop these in.

These are sign-off engines, not another flow — single std-only binaries, seconds not stages, no nix store and no 60-stage orchestration just to sanity-check timing. You keep running LibreLane for place-and-route; you just enter it cleaner and verify its output with a faster, more legible checker. Because their inputs differ, they sit at two points:

Right after Yosys (pre-P&R) — shift the gate left. Catch a broken constraint, a timing wall, or a power problem before you spend an hour in P&R, so you re-spin the heavy flow fewer times.

Engine	Runs on	Catches early
`vyges-sta-si`	synth netlist + `.lib` + SDC	broken constraints, a timing wall, bad clock setup
`vyges-power`	synth netlist + `.lib` + VCD/vectorless	a power / activity problem while it’s still cheap to fix

After the flow produces layout — independent fast sign-off. Run on LibreLane’s own DEF/GDS for a second opinion — faster than re-spinning the flow, and it names what diverges.

Engine	Runs on	Role
`vyges-extract`	routed DEF	SPEF — second opinion vs OpenRCX (0.997 on a routed block)
`vyges-sta-si`	netlist + real SPEF	post-route timing with the actual parasitics
`vyges-em-ir`	PDN + currents	IR-drop / electromigration
`vyges-lvs`	extracted GDS + schematic	MATCH / MISMATCH with readable diagnostics vs Netgen

Be precise about “faster convergence.” These don’t touch LibreLane’s optimizer, so they don’t make P&R itself faster. The honest mechanism is two-fold, and both are real: (1) cleaner entry → fewer expensive flow spins — catching a broken SDC or a timing/power wall post-Yosys means you don’t discover it 50 minutes into P&R and re-spin; (2) an independent verdict that catches what the flow’s own tools miss or report cryptically (vyges-lvs vs Netgen, vyges-extract vs OpenRCX, vyges-sta-si vs OpenSTA). char isn’t in this loop — it builds libraries, not per-design checks.

Three ways to integrate — leanest first

0. Direct binary — no Python, no TCL (recommended for new / upstream integration)

Every engine is a plain binary: a declarative job in, the standard artifact + JSON out, a CI-gating exit code. Any tool, any language, just shells out:

vyges-sta-si  run timing.sta --json     # → {"wns_ns": -0.05, "tns_ns": -0.2, ...}  exit 3 if WNS<0
vyges-extract run top.ext               # → SPEF
vyges-char    run cells.char            # → Liberty .lib
vyges-em-ir   run top.emir              # → IR/EM report

No plugin, no interpreter, no linking — the binary is the contract.

1. An adapter for the incumbent’s script format (where one exists)

For teams with existing scripts: e.g. vyges-sta-si ships an experimental OpenSTA-TCL-subset adapter (vyges-sta-si tcl script.tcl) so an existing OpenSTA script runs through the engine with zero rewrite. (See the sta-si repo’s docs/opensta-integration.md.)

2. An orchestrator step — for native flow metrics

For LibreLane flows that want the result as native metrics next to OpenSTA’s, the sta-si repo ships a LibreLane plugin Step (integrations/librelane/) that reads the flow State and emits vyges__… metrics — the SI second opinion becomes a metric comparison. (Longer term these land in the Sley orchestrator.)

We want to help

Integrating a Vyges engine directly into your tool — and have a question, a missing job-file field, or a JSON-schema tweak you need? We’re happy to help and to shape the interface to your flow. Reach us at https://vyges.com/contact.

Deeper, per-engine integration docs (the OpenSTA boundary, the LibreLane step, the full cross-engine map) live in each engine’s repository under docs/ and integrations/ — linked from that engine’s chapter above.

Keyboard shortcuts

Vyges