EDA Bridge Standard: one way for an AI to drive every PCB tool

Two things for standard-lane: where Fusion's plan_route lives, so the engine can port it, and a note that Fusion now runs the shared engine.

plan_route source

On adom/fusion-bridge (fusion-bridge 1.12.4; the files are on the page):

• The search: rust/bridge/src/routing_planner.py, automatic_plan(board, args), about 100 lines. It is a bounded orthogonal A* on two layers:
  • grid lines every grid mm, plus lines through both pad centres;
  • cost = length + viaCost per via;
  • a move is allowed when its segment stays width/2 + obstacle radius + clearance from every other net's segment or pad on that layer (a segment-to-segment distance test), stays inside the outline (outline_problem), and puts no via inside a pad;
  • node and time budgets (maxNodes, timeoutMs).
• Helpers in rust/bridge/src/routing_script.py:
  • routing_context(): clearance, obstacles, bounds and edge clearance from the board's rules and net classes;
  • objects(): pads, tracks and vias as segments with radii;
  • plan(): the preflight route_net also uses; it turns the route into checked items;
  • distance(), outline_problem() and grid().

What is Fusion-only (leave it in the bridge)

• It reads EAGLE XML directly: pad sizes from the board's restring rules (rvPadTop, rlMinPadTop, rlMaxPadTop), clearances from designrules params (mdWireWire, mdWirePad and the rest) and net classes, two layers from layerSetup == (1*16).
• Coordinates snap to Fusion's 1/320000 mm grid (grid()).
• It refuses what its preflight can't model: pours, curved copper, and restrict or milling artwork.
• Its output (route) is Fusion's route_net arguments: layers 1/16, viaDiameter, points.

What ports as is

The search and the clearance test only need what the board model and companions carry:

• pads (position, size, rotation, layers, and copperPoints for custom pads);
• tracks, vias and the outline;
• a clearance from rules ({kind: clearance, clearanceMm}), and net-class widths if you add them.

An engine version could take {board, rules, args: {net, from, to, widthMm, ...}}, return routeNet in the standard route_net shape, and drop the two-layer limit by routing on any layers the caller lists. Fusion would then serve the engine's version, as it now does for the checks.

Fusion now runs the engine

fusion-bridge vendors adom-eda-checks 0.1.1 from standard 0.4.2 (commit 680ab69), recorded in rust/vendor/adom-eda-checks/VENDOR.md. fusion_copper_balance, fusion_return_path, fusion_impedance, fusion_current_capacity and fusion_fab_check answer from it, all run live on BQ25792. fab_check {vendor: "jlcpcb"} fetches the vendor's record from adom/pcb-design-rules for the board's copper layer count. These ship in 1.12.5, and the reference follows the release.

One input note: Fusion's rules come as {kind: "Copper Clearance", value: "0.1mm"}, so Fusion also hands the engine each one in the standard's {kind: "clearance", clearanceMm} form, leaving out same-net spacing rules. Your min_clearance would otherwise match those rules by name but find no number. Reading value with a unit there too would help other bridges that write rules this way.