vyges physical drt — CLI reference
Generated from vyges physical drt --help — this page is the tool’s own output, verbatim.
vyges-drt — detailed routing
USAGE:
vyges-drt pin_access (--db IN.odb | --lef A.lef [--lef B.lef …] --def D.def)
[--max-routing-layer LAYER] --out OUT.odb [-o REPORT.json]
vyges-drt detailed_route --db IN.odb [--via-access-layer LAYER] [--end-iteration N]
--out OUT.def|OUT.odb [-o REPORT.json]
vyges-drt --describe
vyges-drt --help
vyges-drt --version
pin_access groups the instances into unique classes, finds every pin's access points (cost rounds
of candidates, each planar direction and via checked against the design rules), chooses one
access pattern per class and one per instance along each row of abutting cells, and writes the
results into the database: every master pin's access points, each routed instance terminal's
preferred points, each single-pin port's points. The report (JSON) goes to stdout.
detailed_route routes the design on its route guides: pin access, guide processing, track
assignment, then search-and-repair iterations until no design-rule marker stands, and writes the
routes (a DEF or a database). The routing layers are the block's minimum and maximum routing
layers as the database holds them; the non-default rules are the database's. Nets already routed
in the database are kept: their wires are read, the first three iterations reroute only the other
nets, and the report counts both (routed_before, rerouted). Refused: FIXED wiring, a wire using
one of the design's own vias, a routed net on a non-default rule.
OPTIONS:
--db IN.odb read the design from a database
--lef FILE / --def FILE or from LEF files and a DEF
--max-routing-layer LAYER set the block's maximum routing layer first (as a
signal-layer range ending at LAYER does)
--via-access-layer LAYER detailed_route: the via-access layer (default the second
routing layer)
--end-iteration N detailed_route: stop after search-and-repair iteration N
(counted from 0), whatever markers stand
--out OUT.odb write the database here
-o FILE write the JSON report to FILE instead of stdout
--threads N worker threads (also VYGES_THREADS); default a balanced count
from the machine's physical cores; 1 is serial. The routes are
the same at any count
--json accepted; the report is JSON either way
--describe print a machine-readable JSON description of the command
EXIT STATUS:
0 written access points computed (or the design routed clean) and the output written
1 markers detailed_route: routing ended with design-rule markers standing; written
2 vacuous nothing to access: no routed instance terminal and no routed port. NOT a pass;
nothing is written
2 error usage, unreadable input
3 refused a step this engine does not model (among them a multi-patterned routing
layer), a terminal with no access point, or a row with no pattern
combination — see `reason`
Contract
Generated from vyges physical drt --describe.
drt
detailed routing on the design’s route guides: pin access, track assignment and search-and-repair until no design-rule marker stands, the routes written as a DEF or a database; pin access alone is its own command
Maturity: structured
detailed_route --db {db} --out {out}
| Input | Type | Required | Description |
|---|---|---|---|
db | string | yes | the design database to read (detailed_route: placed, with route guides) |
out | string | yes | where to write the result: detailed_route writes a DEF if the name ends in .def, else a database; pin_access writes a database |
via_access_layer | string | no | detailed_route: the via-access layer (default the second routing layer) |
end_iteration | integer | no | detailed_route: stop after this search-and-repair iteration (counted from 0) |
threads | integer | no | bound the worker threads; leave unset (the results are identical at any count) |
report | string | no | write the JSON report to FILE instead of stdout |
Consumes: odb
Artifacts: routed_design (out)
Assertion: routed-clean — passes when status equals written
Threads
- Option:
--threads - Environment:
VYGES_THREADS - Default: the machine’s physical cores (within this process’s CPU affinity), one fewer when there are more than four, at most 16
- 0 / serial: 0 = the default / 1 = serial
- Same results at any count: yes
- Reported: the run logs the count it chose and why
Leave it unset: the default is chosen from the machine and the results are identical at any count. Pass –threads N only to bound CPU or memory, for example when running several jobs at once (give each a share of the cores).
Provenance limitations
- detailed_route status is one of written, markers, refused or error: written is routed with no design-rule marker standing (exit 0); markers is routed and written with markers standing (exit 1, a finding, not a pass); error is exit 2; refused is exit 3.
- pin_access status is one of written, vacuous, refused or error. VACUOUS IS NOT WRITTEN: the design has no routed instance terminal and no routed port, and nothing is written. Exit status is 0 for written, 2 for vacuous and for error, 3 for refused.
- detailed_route is correlated end to end on the DEF it writes, compared WHOLE and byte for byte against a fresh reference run: 16 of 16 cases, 2026-09-25 – 14 of the reference router’s own regression scripts (the largest 16,880 nets over 5 search-and-repair iterations), its incremental-routing script, and one constructed incremental case. Each stage (guides, rule tables, track assignment, every worker of every iteration) is also correlated against an instrumented reference. The correlation harness is not part of this repository.
- An incremental run’s DEF cannot tell incremental rip-up from rerouting everything, which writes the same DEF: the report’s routed_before and rerouted counts say which ran.
- pin_access is correlated stage by stage against an instrumented reference router, and end to end on the database it writes (preferred points, point counts, port points, pin-access indices) on sky130hs designs, and stage by stage on Nangate45 and GF180 designs, 2026-09-25.
- Design rules modelled: shorts (metal and cut), non-sufficient metal, the parallel-run spacing table, LEF 5.4 spacing limited to a width range (SPACING … RANGE), cut spacing (one plain rule per cut layer), LEF 5.4 end-of-line spacing (with or without a parallel edge), minimum width, minimum area (patched where the router can, reported where it cannot), minimum enclosed area (MINENCLOSEDAREA without a WIDTH; a rule with one is skipped, as the reference skips it), minimum step (MINSTEP), minimum cut (MINIMUMCUT), rect-only layers (which are also unidirectional), right-way-on-grid-only layers, LEF58 end-of-line keep-out, LEF58 end-of-line spacing with SPACING, ENDOFLINE, WITHIN, ENDTOEND and PARALLELEDGE (a rule with EXCEPTEXACTWIDTH, FILLCONCAVECORNER or EQUALRECTWIDTH is skipped, as the reference skips it), LEF58 corner spacing (CONVEXCORNER, with CORNERONLY or CORNERTOCORNER; the router patches corners that break it), LEF58 cut classes, the LEF58 different-net cut spacing table of a cut layer, LEF58 enclosure (only the rules the reference itself keeps), and a cell obstruction with its own DESIGNRULEWIDTH or SPACING (checked as a blockage of its own, by its own rule). A net carrying antenna jumpers (the database’s hasJumpers, set by global routing’s antenna repair) is routed at ten times the off-guide cost.
- REFUSED rather than approximated, by detailed_route: any other rule family a layer carries (other LEF58 end-of-line clauses, LEF58 minimum step and minimum cut, SPACINGTABLE INFLUENCE, LEF58 max spacing, two-wires forbidden spacing, orthogonal width tables, wrong-direction spacing, the orthogonal spacing table, a metal-width via map and the rest, named in the reason; only the rules the reference itself keeps count); corner spacing with CONCAVECORNER, SAMEMASK or EXCEPTEOL, or in a design that instantiates a BLOCK master; a cut spacing table between layers (LAYER) or with SAMENET or SAMEMETAL; more than one plain cut spacing rule on a cut layer; a layer whose via pads break its minimum step (the check’s min-step patch is not modelled); a multi-patterned routing layer; a non-default rule with hard spacing, via generate rules or wire extension; FIXED wiring, a via or patch with no wire, or a routed net on a non-default rule already in the database; and congested input guides. From iteration 7 a congested worker widens the clip of later rows, and from iteration 23 NEARDRC rips up the nets near each marker; both are transcribed but no correlated design exercises them yet.
- REFUSED rather than approximated, by pin_access: a nearby-track cost round (a pin that no other round can reach); and every rule family or layer property detailed_route refuses (the access points are judged by the same design-rule check), named in the reason.
- The router settings are its defaults: via-access layer the second routing layer (detailed_route takes –via-access-layer), no via-in-pin range, three sparse points per pin, non-preferred tracks allowed. detailed_route routes between the block’s minimum and maximum routing layers as the database holds them, with the database’s non-default rules; pin_access’s top routing layer is the block’s maximum routing layer, else the topmost.
drt.pin_access
compute every pin’s access points and write them into the database
pin_access --db {db} --out {out}
| Input | Type | Required | Description |
|---|---|---|---|
db | string | yes | the placed design database to read |
out | string | yes | the database to write, access points included |
max_routing_layer | string | no | the block’s maximum routing layer, set first |
threads | integer | no | bound the worker threads; leave unset |
report | string | no | write the JSON report to FILE instead of stdout |
Assertion: pin-access-written — passes when status equals written