vyges loom em-ir — CLI reference

Generated from vyges loom em-ir --help — this page is the tool’s own output, verbatim.

vyges loom em-ir — EM / IR-drop power-integrity sign-off (PDN -> report)

usage:
  vyges loom em-ir run   JOB [-o OUT] [--json] [--fail-on-violation]
  vyges loom em-ir check JOB
  vyges loom em-ir demo  [-o OUT] [--json]
  vyges loom em-ir em-density (--geom G | --spef S) --lef TECH.lef
                              [--current-map C | --net-current mA] [--fail-on-violation]

em-density is EM sign-off on *extracted SPEF*: it screens each metal segment's
current density (from the loom EM geom sidecar: layer + width) against the tech
LEF DCCURRENTDENSITY (and AC RMS/PEAK when the current map supplies them).

flags:
  -o FILE               write output to FILE (default: stdout)
  --json                machine-readable JSON instead of the text report
  --fail-on-violation   exit 3 if IR drop exceeds the limit or any EM segment fails
  -q, --quiet           suppress non-essential output
  -v, --verbose         extra detail on stderr
  --describe            print a machine-readable JSON description of the command
  -h, --help            show this help
  -V, --version         show version
  --bug-report     file a bug (central: vyges/community)
  --feature-request request a feature (central)
  --sponsor        sponsor Vyges (github.com/sponsors/vyges-ip)
  --star           star this tool on GitHub ⭐

Contract

Generated from vyges loom em-ir --describe.

em-ir

EM / IR-drop power-integrity sign-off (PDN -> report)

Maturity: workflow-validated

run {job}

Consumes: pdn, power_report, spef, emgeom

Artifacts: emir_report (report_path)

Assertion: power-integrity-met — passes when pi_met is true

Provenance limitations

• The job names the PDN or DEF/LEF and any power and decap maps; input_hash covers the job path and arguments, not their contents.
• Solved on a real block: a routed sky130 PDN extracting to 5308 nodes solves in 0.46 s. The solver is conjugate gradient with a Jacobi preconditioner; it was Gauss-Seidel, which on that same block stopped short of tolerance after 50000 sweeps and returned an error rather than a result.
• Partially correlated against OpenROAD PDNSim on one routed sky130 block, at the level of the extracted network rather than the solved voltages (the solver above does not get that far). Per-layer total resistance against PDNSim’s own network: met1 1.003x, met4 1.005x, met5 1.013x, and vias exact at 1635.725 ohm over 1895 vias against 1635.7249999999501. No voltage or IR-drop figure has been correlated against any other tool.
• Wire resistance (rho_sq * L/W) and the per-square resistance itself agree with PDNSim’s model under a default-RC flow; a flow that sets custom layer RC moves PDNSim’s resistance and not ours, and neither tool reports the divergence.
• Via resistance is the cut layer’s per-cut LEF RESISTANCE divided by the cut count taken from the DEF VIAS definition. Keyed on the layer pair as well as the point, because a PDN via stack places several definitions at one coordinate.
• Voltage sources are the power pin’s port shapes where the design declares them, falling back to every pad_layer node only when it does not – PDNSim’s own precedence. On the correlated block the declared pin covers 683 grid nodes where the fallback holds 28, and it moves the answer by 4.1x: worst drop 0.27% under the fallback against 0.06% under the declared pin. Which way that runs is DESIGN-DEPENDENT, turning on how much of the grid a pin covers, so it is measured per design rather than assumed.
• Correlated against OpenROAD PDNSim across SIX routed sky130 blocks, fed the same per-instance currents and compared against a PDNSim run from the same build: worst-IR-drop ratios 1.019, 1.001, 0.994, 0.997, 1.018 and 1.015 – all six within 1.9%, spanning 35 uA to 1.16 mA and 2500 to 19700 grid nodes. PDNSim’s values carry two to three significant figures at these magnitudes, so this is near the floor the comparison resolves.
• Instance current enters the rail at the CELL CENTRE when a cell_lef supplies MACRO SIZE, else at the DEF origin. Both were measured against PDNSim: landing current on the nearest pre-existing grid node under-reported worst IR drop by 3.2x, and using the DEF origin rather than the cell centre displaced every load by half a cell width, worth 8.4% on a block of wide cells and invisible on a block of small ones. Supply a cell_lef for wide-cell designs.
• Only the WORST node is comparable between the two engines: PDNSim’s voltage file reports one row per INSTANCE TERMINAL, this engine reports one row per GRID NODE, and those sample the same field at different places and in different proportions. On one block PDNSim’s median drop is exactly 0.0, because most of its rows sit on the filler and decap cells packed against the supply straps, and the p75 ratio reads 11.3. So percentile-to-percentile comparison is not like-for-like at any percentile; an earlier version of this descriptor read a 4-8% one-sided residual out of exactly such a comparison, and that is withdrawn as an artefact.
• Precision bound: PDNSim’s voltage file prints six decimals, so at these magnitudes 1 uV quantisation is a few tenths of a percent even at the worst node. Agreement is to the precision the oracle publishes.
• The oracle is REGENERATED per run from the same binary. Archived LibreLane net-*.csv voltage files are not a safe baseline: on three of six blocks a fresh PDNSim run on the same .odb disagreed with the archived one by 1.32x, 1.37x and 10x. The builds differ (archived reports lack the Total power line a current build prints); the cause of the disagreement is not established.
• Instance current enters at a tap point on the rail: the instance’s placement projected onto its nearest rail segment, which is split there. Landing current on the nearest PRE-EXISTING node instead under-reported worst IR drop by 3.2x, because the current never crossed the rail resistance between the cell and that node. Projection is axis-aligned only; an instance that cannot be projected falls back to the nearest node and is counted.
• Node counts are not comparable with PDNSim by construction: it resamples nodes on a minimum pitch, this engine places one per polyline point.
• Dynamic (transient) IR has NO oracle: PDNSim is static-only, so nothing exists to correlate it against. It is checked instead against exact analytic cases (with no decap the solve is exactly quasi-static, peak = ipk*R to 1e-9) and construction invariants (linear in switch energy, coincident switches superpose, decap monotonically removes droop), all mutation-checked. Runs at scale: 13292 nodes in 22 s, 248 MB.
• Transient limits, which matter more than its accuracy: every instance switches at ONE global switch_t_ns, so the result is worst-case-simultaneous switching – a strict upper bound, not a waveform; the timestep is implicit at min(switch duration)/10 and cannot be set, so accuracy cannot be traded for runtime and convergence cannot be demonstrated; and only the worst droop is reported, with no waveform exposed.
• EM: PDNSim reports per-segment current but applies no current-density limit and issues no verdict, so only the numerator can be correlated. Maximum segment current per layer, which is what a limit is compared against, across three routed sky130 blocks: met1 1.022/1.026/1.035, via 1.008/1.016/0.992. On the ~10% of segments with an exact geometric counterpart, restricted to those carrying at least 1% of peak current, 92-99% agree within 10% (median 0.997-1.003). The DC/RMS/peak LIMIT check has no counterpart and remains this engine’s own.