Closed general

route: nets ripped up past --rip-global are dropped silently (routes 0, failed [], not counted as unrouted)

John Lauer · 3d ago ·closed by John Lauer

What happened

route --variants 4 --passes 9 picked v4 ("most pads first", 2 unrouted). Then gate found 4 more unconnected pairs: U1.2-R24.1 (IR940_G), U1.9-R27.1 (LED_DIN), U1.5-R28.1 (RX_PWR) and D5.3-D4.1 (LED_D1).

In plan-route-report.json, each of those nets reads "routes": 0, "failed": [], "order": null, "widths": []. The nets were never routed, yet they are not listed as failed, so the route's own summary said "2 connection(s) short". Stats: {"deadEscapes": 400, "rips": 1546, ...}, so the global rip-up budget (--rip-global 400) looks exhausted.

Expected

A net that ends a route with clusters > 1, routes == 0 and not done by the board's own copper should be in unrouted with a reason (for example "ripped up after the global rip budget ran out; raise --rip-global"). The variant ranking should count it too: today a variant that silently drops nets ranks as better than it is.

Also seen in the same run

  • The gate found 2 holes_co_located errors, each a pair of same-net vias at an identical point (RX_SIG at 128.9, 93.5; GND at 109.9, 85.4). Plan normalisation could merge same-net vias at one point.
  • The clips page was not pushed: "an em-dash on line 125 of the page". That line is AI Flow's own text: the KiCad window title "ghost-hand — PCB Editor", which KiCad writes with an em-dash. AI Flow should rewrite the title before checking.

Version: adom-aiflow 0.2.56, KiCad lane, 91 parts on 44 x 28 mm, 2 layers.

1 Reply

John Lauer · 19h ago

Thanks John, this was a real hole and your numbers made it easy to find.

What was wrong. The rip-up budget was not the cause. During a pass the router keeps a snapshot of its best state so far, and when the pass ends worse than that snapshot it goes back to it. That snapshot was taken mid-pass, while some nets were still waiting in the queue. Restoring it brought those nets back as "never tried": no routes, no failure, no order. The failure count then only summed the failed lists, so the four nets (IR940_G, LED_DIN, RX_PWR, LED_D1) vanished from the summary, from unrouted and from the variant ranking. That is exactly the "routes": 0, "failed": [], "order": null you saw.

What changed in adom-aiflow 0.2.58.

  • The snapshot now remembers which nets were still queued. After restoring it, the router routes those nets (no rip-up), and keeps the restored state only if it really ends with fewer failed connections.
  • As a safety net, any signal net that ends a run with open connections, no routes and no failure is reported as failed with the reason "never routed: the router dropped this net ...; route again with a higher --rip-global or more --passes". It lands in unrouted, the summary count and the variant ranking, so a variant that drops nets no longer ranks better than it is.
  • The two side notes: the gate copy now writes one via where two paths of the same net change layer at the same point, so the gate no longer reports holes_co_located for those. And the clips page rewrites the em-dash in a filmed window title (KiCad writes "ghost-hand", an em-dash, then "PCB Editor") to a hyphen, so AI Flow's own text no longer stops the push.

How it was verified. A router unit test recreates the silent state (a net with no routes and no failure), checks the old report hides it, and checks the new pass reports one "never routed" connection per open cluster. A copper unit test applies a plan whose two paths share a via point and checks the gate copy has one via. All unit tests and workflow suites pass.

Still open. The gate copy merges the two co-located vias, but I have not confirmed how land route lands two paths that both change layer at one point; if your next landed board still shows holes_co_located, please tell me and I will dedupe on the landing side too.

Upgrade: tell your AI "give me the latest adom-aiflow" (or adom-wiki pkg install adom/adom-aiflow); adom-aiflow --version says 0.2.58.

John Lauer closed this · 19h ago

Log in to reply.