EmbeddedEra EmbeddedEra

← Notes from the bench.

When a KiCad autorouter is worth using

Sep 17, 2026pcb-designkicadlayoutDrafted with AI assistance, reviewed and edited by our engineer.

Two hundred nets in, the placement looks right and the routing does not want to cooperate. Someone reaches for an autorouter, because surely a computer can connect dots faster than a human dragging traces one at a time. The results are mixed enough, and the forum advice contradictory enough, that most people end up guessing: route it all by hand out of distrust, or hand the whole board to a tool and hope the DRC report comes back clean. Neither is the right default, and the difference between them is worth understanding before the next board, not during it.

What an autorouter is actually doing

KiCad doesn’t ship a built-in autorouter. The long-standing answer is FreeRouting, a separate Java application that reads a board out of KiCad as a Specctra DSN file, routes it, and hands back a session file to import. FreeRouting treats routing as a maze-search problem: for each net, it finds a path through the board’s grid that doesn’t cross an obstacle, using a rip-up-and-reroute pass to back out and try again when a later net blocks an earlier one. It’s a general-purpose tool, and it’s reasonably good at general-purpose problems — two-layer boards, breakout boards, anything where most nets are simple point-to-point connections with no timing or impedance requirement.

A newer entry, OrthoRoute, takes a different approach: it implements Lee’s algorithm — a wavefront that expands outward from a starting pad until it hits the target — parallelized on a GPU. That matters for a specific class of board FreeRouting struggles with: large, dense, highly regular designs like multi-thousand-pad backplanes or BGA escape patterns, where a general maze router can spend hours moving a tiny fraction of the airwires. It’s not a general replacement for FreeRouting; it’s a tool built for the boards where a CPU-bound router runs out of time before it runs out of board.

Both tools solve the same underlying problem — get a trace from pad A to pad B without a short — and neither one understands why a trace exists. That’s the limit that matters most.

What autorouting is good at, and what it isn’t

An autorouter has no concept of signal integrity, current capacity, or what a trace is carrying. It satisfies clearance and connectivity rules and stops there. That makes it well suited to some nets and poorly suited to others, and the split is fairly consistent across boards:

Net typeAutorouter fitWhy
Low-speed digital, GPIO, general I/OGoodPoint-to-point, no length or impedance constraint
Bulk decoupling and ground returnsGood, with a planeRouter just needs a via down to plane, not a routed trace
Differential pairs (USB, Ethernet, LVDS)Poor unmanagedNeeds matched length and controlled spacing the router won’t infer on its own
RF and high-speed single-ended (clocks, SPI at speed)PoorTrace length and via count directly affect signal quality
Power delivery, high currentPoorRouter doesn’t reason about copper cross-section or current density
Dense BGA escape, large regular arraysGood with a dedicated toolThis is what OrthoRoute specifically targets

KiCad’s own interactive router — the push-and-shove tool built into pcbnew, not a separate autorouter — handles the difficult middle ground better than either automated tool. It has an explicit differential-pair mode with length and skew tuning, and its shove behavior lets a human route a critical net while the router nudges everything else in the neighborhood out of the way rather than blocking the move. That’s a manual tool, but it’s the fast kind of manual: routing a differential pair by hand with length tuning in pcbnew takes minutes, not the hours it feels like it should.

The order that actually works

The complaint that autorouting “doesn’t work” almost always traces back to skipping the setup that makes it work. A router that’s handed a bare board with no net classes and no keepouts will connect everything legally and produce a board no one wants to build. The sequence that holds up in practice:

Placement first, every time. No router — human or automated — recovers from bad placement. Group related parts, keep high-speed pairs short before a single trace is drawn, and leave a router something reasonable to work with.

Rules before routing. Set net classes, minimum widths, and differential pair rules in KiCad’s design rules before running any router. An autorouter that doesn’t know a pair needs 90 ohms differential impedance will route it as two unrelated nets, and no amount of post-routing cleanup fully undoes that — it needs to be ripped up and redone with the rule in place from the start.

Route the critical nets manually, first. Power, differential pairs, anything with a length or impedance requirement, and anything carrying real current. This is a small fraction of the net count on most boards but consumes most of the layout risk.

Let a router take the rest. FreeRouting for general nets on a normal-sized board, OrthoRoute if the board is a large regular array where FreeRouting stalls. This is genuinely where automation earns its keep — the tedious, low-risk majority of the connections.

Review before accepting. Don’t trust a clean DRC pass as proof the board is right. DRC checks clearance and connectivity, not whether a router routed a low-speed signal across three layer changes and forty vias to satisfy a keepout it didn’t need to respect.

What to check before the board goes to fab

A router-generated layer, even a well-set-up one, needs a specific review pass before it’s trusted, on top of the usual assembly-quote checklist:

  • Via count per net. An autorouter has no preference against adding a via, and a signal that changes layers four times to avoid a minor obstruction adds inductance and cost for no reason. Anything with more than one or two unnecessary layer changes is worth re-routing by hand.
  • Stub lengths on high-speed nets. Even nets the router wasn’t asked to treat as critical can end up with unnecessary length if the tool chose a longer legal path over a shorter one that required moving a lower-priority trace.
  • Return path continuity. A router respects clearance to a plane; it doesn’t know whether a signal’s return current has a continuous path underneath it. Checking for split-plane crossings on fast signals is a manual step no autorouter performs.
  • Thermal relief and current-carrying copper. Confirm power nets still meet the width and copper weight the design actually needs — an autorouter sized a trace to the net class rule, not to the current the net will carry in service.

None of this makes autorouting the wrong tool. It makes it a tool with a narrow, well-defined job: clear the routing backlog on nets that don’t matter enough to route by hand, so a person’s time goes to the nets that do.

What to send us

If a board has gotten past placement and the routing is either taking longer than it should or is being handed to a tool with no result to check it against, send the KiCad project, the stack-up, and which nets carry a length, impedance, or current requirement. From that we can tell you what’s worth automating, what needs a person, and what the finished layer should look like before it goes to fab.

Have a KiCad board that needs a layout done properly? We route it by hand and check it before fabrication.

ENGINEERING NOTES

One note a week on PCB design, firmware and getting hardware built. No sales email.

Double opt-in. Unsubscribe in one click.