fix: keep labeled rail nets on net labels instead of long traces (#670)#702
fix: keep labeled rail nets on net labels instead of long traces (#670)#702DPS0340 wants to merge 3 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Fixes tscircuit#670. LongDistancePairSolver connected any unconnected pins on a net with up to 3 nearest-neighbor traces, regardless of whether the net is rendered with net labels. On the tscircuit#670 board, pins on the labeled V3_3/GND rails (e.g. JP1.2-JP2.2, 10 units apart) got 9-13 unit orthogonal bus traces snaking across the schematic even though every one of those pins already gets a net label. For nets with declared availableNetLabelOrientations and more than two pins, neighbor candidates are now limited to maxMspPairDistance — the same threshold MspConnectionPairSolver uses to decide a pair is too far apart to wire directly. Nearby pins on labeled rails keep their short traces; distant ones stay label-connected. Two-pin labeled nets are unaffected (a single trace is cleaner than a floating label pair). Adds a regression test with the tscircuit#670 board asserting no >5-unit traces remain on labeled nets. 20 board snapshots updated: long V3_3/GND/VCC bus traces disappear in favor of the labels that were already being placed.
Follow-up to the tscircuit#670 fix after rebasing onto UnroutedTraceRecoverySolver (tscircuit#712), which landed while this branch was open. LongDistancePairSolver declines to wire distant pairs on labeled rails, so those pairs now arrive at UnroutedTraceRecoverySolver as failed connections and were being recovered as long detour traces — reintroducing exactly the bus trace tscircuit#670 asks us to avoid. On the ina237 board, BUS_HIGH pins U1.10 and R_SHUNT.1 sit 2.31 units apart (within maxMspPairDistance of 2.4) but are only reachable by a 9.07 unit path around the chips, so the pin-distance guard did not catch it. The recovery solver now skips candidate paths on labeled rail nets whose routed length exceeds maxMspPairDistance. Because the pins can be close while the route is long, the routed length is what decides this, not the straight-line pin distance. The labeled-rail test — declared net-label orientations plus more than two pins — is shared by both solvers in lib/utils/labeledRailNets.ts so they cannot drift apart. Measured against origin/main (total/max orthogonal trace length per board): bug-report-20260716-long-trace-670 63.10/12.73 -> 22.48/2.88 bug-report-20260707T092615Z 109.66/10.20 -> 81.58/4.17 repro-ina237-current-monitor 31.68/7.47 -> 20.07/3.38 example13 39.84/6.88 -> 34.53/6.88 (1 -> 0 long rail traces) example32 21.99/4.40 -> 18.29/4.40 Full suite passes; three snapshots updated to reflect the shorter routes.
1aa1c9c to
d8b7900
Compare
|
Rebased onto current
The ina237 board shows why the existing pin-distance guard did not catch it: The labeled-rail test (declared net-label orientations + more than two pins) is shared by both solvers in Measured against
Every board improves and none regress. Full suite passes (145 pass / 0 fail); three snapshots updated to reflect the shorter routes. |
Same issue @mohan-bee flagged on tscircuit#703/tscircuit#707: bug report directories are generated by .github/scripts/import-json-bug-report.ts and named from the issue's created_at, so they must not be hand-created. Issue tscircuit#670 was opened at 2026-07-16T14:48:56Z and its bot-imported report already exists as bug-report-20260716T144856Z. The hand-made bug-report-20260716-long-trace-670/input.json was a byte-identical copy. Removes the duplicate and points the repro at the existing bug report. Full suite 145 pass / 0 fail.
|
Applied your This branch had the same problem: issue #670 was opened at I've swept my other open branches on this repo for the same mistake — this and #699 were the only two, both fixed now. Full suite 145 pass / 0 fail. |
|
@mohan-bee @seveibar — flagging this one because GitHub's diff stat makes it look far larger than it is, and I suspect that's why it's been skipped. It shows 29 files, +2073/-1658. But 25 of those files are regenerated Fixes #670: a net that already has labels was being wired with a long bus trace across the board instead of using those labels. One thing worth knowing for review: Regression test fails on |
1 participant
Fixes #670.
Problem
On the attached board,
LongDistancePairSolverdraws 9–13 unit orthogonal bus traces across the schematic for pins on the labeled V3_3/GND rails:Every one of those pins already receives a net label (V3_3 is declared
y+, GNDy-inavailableNetLabelOrientations), so the long traces duplicate the label connection — the "long trace instead of netlabel" in the issue title.Root cause
LongDistancePairSolverconnects unconnected pins to up to 3 nearest neighbors on the same net with no distance cap and no awareness of net labels.MspConnectionPairSolverdeliberately skips pairs beyondmaxMspPairDistance(2.4 here) so they become label-connected — but the long-distance pass then bridges those same pins anyway whenever a collision-free route exists.Fix
For nets with declared
availableNetLabelOrientationsand more than two pins, neighbor candidates are now limited tomaxMspPairDistance. This keeps:rotated-components-rail-label).Verification
mainwith the three traces above)bun test— 141 pass, 0 failbunx tsc --noEmit/biome check— clean