vyges physical tap — CLI reference

Generated from vyges physical tap --help — this page is the tool’s own output, verbatim.

vyges physical tap — row cutting and physical-cell insertion

USAGE:
  vyges physical tap cut-rows <design.odb> [--halo-x UM] [--halo-y UM] [--row-min-width UM]
                                       [--endcap-master NAME]
  vyges physical tap place-tapcells <design.odb> --master NAME [--distance UM] [--tap-prefix P]
  vyges physical tap place-endcaps <design.odb> [--corner NAME] [--edge-corner NAME]
                               [--endcap-horizontal A,B] [--endcap-vertical NAME]
                               [--left-top-corner NAME] ... [--prefix P]
  vyges physical tap tapcell <design.odb> --tapcell-master NAME --endcap-master NAME
                          [--distance UM] [--halo-width-x UM] [--halo-width-y UM]
                          [--cnrcap-nwin-master NAME] [--tap-nwintie-master NAME] ...
  vyges physical tap ripup <design.odb> [--tap-prefix TAP_] [--endcap-prefix PHY_]
  vyges physical tap boundary <design.odb>
  vyges physical tap --describe
  vyges physical tap --help

OPTIONS:
  --halo-x UM            keep-out around a macro, horizontally, in MICRONS (default 2)
  --halo-y UM            keep-out around a macro, vertically, in MICRONS (default 2)
  --row-min-width UM     do not leave a row narrower than this, in MICRONS
  --row-min-height UM    do not leave a row region shorter than this, in MICRONS
  --endcap-master NAME   reserve room for one endcap at each end of every row
  --out-odb FILE         write the database here (default: IN PLACE, over the input)
  --out-def FILE         also write the result as DEF (for diffing against a golden)
  --dry-run              report what would be cut, write nothing
  -o FILE                write the report to FILE instead of stdout
  --json                 emit JSON (the default)
  --describe             print a machine-readable JSON description of the command

EXIT STATUS:
  0  applied     rows were cut and the database written
  0  vacuous     the run changed nothing -- NOT a transformation; read the count
  1  refused     the design cannot be processed as asked
  2  error       usage error, unreadable database, no DBU scale, or a failed write

Contract

Generated from vyges physical tap --describe.

tap

row cutting around macros, and physical-cell insertion (well taps, endcaps)

Maturity: structured

cut-rows {odb}

Consumes: odb

Artifacts: tap_report (report_path)

Assertion: rows-cut — passes when status equals applied

Provenance limitations

• input_hash covers the argument vector, not the content of the .odb it names.
• The boundary verb is INSPECT-ONLY: it reports the row-region, edge and corner classification and writes nothing. Every other verb that places (place-endcaps, place-tapcells, tapcell) does mutate the design – they create physical instances, orient, locate, lock and mark them – as does cut-rows, and ripup removes them. This line previously read “NOTHING IS PLACED from it yet, ONLY cut-rows mutates”, which was true of an early build and stayed here after placement shipped and was measured exact; it is corrected rather than deleted because a reader who saw the old text needs to know it moved, not wonder which of two claims to believe.
• Unnamed endcap positions are filled from the library’s own LEF58 master types (odb reports these as space-separated strings like “ENDCAP LEFTBOTTOMCORNER”, not the enum spelling). Two masters claiming one position is an ERROR naming both, not a coin flip: a wrong endcap is a well-tie fault nobody sees until silicon. A position nothing fills stays empty and places nothing.
• Taps and endcaps use DIFFERENT default name prefixes – TAP_ and PHY_ – because they are separate namespaces that can be ripped up independently.
• MEASURED 2026-08-23 against the upstream goldens at pin 945a9f48dc6e5cc91d865daa92c45a1094cb682c: cut_rows 10 of 10 comparable cases exact (DEF ROW diff), and endcap placement 9 of 9 exact – every physical cell matching the golden in master, position and orientation.
• status is one of applied, planned, vacuous or error. VACUOUS IS NOT APPLIED: it means the run changed nothing – no row cut, no cell inserted, none removed – and the declared assertion passes only on applied, so a no-op fails it rather than reporting a transformation that did not happen. Zero may still be the right answer for the design; read the count and decide. A dry run reports planned, which never claimed to have applied anything.
• All five commands are implemented: cut-rows, place-endcaps, place-tapcells, the combined tapcell, and ripup. Rip-up matches by NAME PREFIX, which is the only mark these cells carry – they are physical-only instances with no nets. An EMPTY prefix removes nothing rather than everything, which is the difference between undoing a tap step and destroying the design.
• COMBINED TAPCELL IS 20 OF 20 AT THIS PIN. It was 16 of 16 at the previous pin 945a9f48dc6e5cc91d865daa92c45a1094cb682c and read 14 of 20 the moment the pin moved, with nothing in this engine changed: upstream had reworked endcap placement across sixteen commits and added four regression cases. A SCORE IS ONLY TRUE OF ONE COMMIT – quote the pin beside it. The last case closed by walking a hole the way the reference walks it: the reference receives holes wound like outer boundaries and walks every ring counter-clockwise, while this engine winds holes clockwise, so the classification agreed and the placement ORDER did not – and where two cells contend for one position, whichever is walked to first keeps it.
• Row cutting itself is odb’s own cutRows from odb/util.h, not a reimplementation: it is odb’s algorithm on odb’s rows, and OpenDB is the substrate. What this engine decides is the policy around it – which instances are blockages, the halo, and the minimum row width.
• Blockages are placed macros (dbInst::isBlock). A macro that is NOT placed is skipped and reported by name (upstream TAP-32), never silently ignored, because rows would otherwise be left crossing wherever it lands.
• The minimum row width is the LARGER of two endcap widths and any –row-min-width given, so a caller’s floor cannot quietly produce rows too narrow to cap.
• Halos and widths are given in MICRONS and converted with the database’s dbu_per_micron. A database with no DBU scale is an error rather than an assumed scale.
• Written against the upstream tap regression goldens at pin 945a9f48dc6e5cc91d865daa92c45a1094cb682c (vyges-openroad 2026.08.0). Conformance for the implemented subset is measured by diffing the DEF ROWS section against each case’s .defok: 10 of 10 comparable cases exact. ⚠️ A correlation result is a statement about ONE upstream commit – this one was re-measured when the pin moved, and combined tapcell regressed from exact.
• The corner classification is no longer checked by a separate harness. That check compared this engine’s corner CENSUS against the corner CELLS a golden holds and reported 4 exact and 6 unresolved; it was retired on 2026-08-23 because those 6 could never resolve – upstream classifies every corner too and filters only at placement (getRow), so a corner no row reaches leaves no trace in any golden on either side. All 10 of its cases are compared cell by cell by the DEF gates instead, and the corner TYPE is part of the instance name those compare (PHY_CORNER_ROW_0_OuterBottomLeft_0), alongside master, position and orientation.
• The default output is IN PLACE, over the input database. Pass –out-odb to write elsewhere, or –dry-run to report without writing.