Rank the signals before placement and routing, then place and route in that order

noah · ·edited ·closed by Colby Knox

Rank the signals before placement and routing, then place and route in that order

Seen on: adom-aiflow 0.2.44 (AM32 ESC run, adom/am32-esc-2s6s-molecule). The same ranking applies to any board.

What happened: nothing in the flow asks the AI to decide which signals matter most on this board. route orders nets by length (shortest first in v1, longest first in a variant), with only the spec's decoupling pairs routed ahead. spec.placement (#53), impedanceTargets (#52) and planeUnder each capture one constraint, but nothing ranks them against each other.

On the ESC the results were:

  • The gate-drive traces (driver pin through the gate resistor to the FET gate; the highest di/dt signals after the power loop) were 23 to 47 mm, 33 mm on average.
  • The back-EMF sense lines (the analogue signals AM32's zero-crossing detection depends on) were 47 to 92 mm, two of the three about 90 mm across the board.
  • Debug and telemetry lines got similar treatment.

On the hand-routed board the gate-drive traces are 15 to 29 mm (22 mm on average), the back-EMF lines 17 to 32 mm, and the MCU-to-driver PWM lines about 2 mm (numbers in #128).

How a layout engineer works: rank first. On a board with high-speed USB and a 9600-baud UART, USB comes first: it needs impedance control and a differential pair, and it is far more sensitive to routing errors. You place and route for USB, then make the UART fit. Highest speed, most sensitive and highest power go first. It is the AI's job to make that ranking for each board and say why.

Suggested fix:

  1. A ranking written before placement, as spec.signalPriority: an ordered list of classes, each with its nets and a one-line reason. For example:

    [{"class":"power loop","nets":["VBAT","PH*","GND"],"why":"20 A, sets heat and EMI"},
     {"class":"gate drive","nets":["GH*","GL*","SH*"],"why":"highest di/dt, ringing"},
     {"class":"BEMF sense","nets":["BEMF_*","NEUTRAL"],"why":"analogue zero-crossing"},
     {"class":"PWM","nets":["INH*","INL*"],"why":"timing"},
     {"class":"slow","nets":["SWD*","TLM","SIG"],"why":"kHz or static"}]
    

    The design or placement step requires it, and finish refuses a run without one (or with an explicit deviation). The timeline shows it.

  2. Placement uses it. place check reports each top-class loop or ratsnest length and area. The place pack wish order follows the ranking.

  3. Routing uses it. route routes classes in rank order, top class first, and rips up lower classes before higher ones. The class sets the defaults:

    • via budget
    • geometry strictness (#127)
    • width
    • planeUnder or reference-plane rule
  4. Gate and finish report per class: "gate drive: 6 lines, worst GHA 47 mm, 2 vias (budget 0)".

  5. The aiflow-power-layout and kicad-place-route-loop skills already teach this judgement for power boards. Moving it into a spec field the binary reads makes it apply to every board.

Related: #127 (route geometry), #128 (vias and detours), #130 (placement priorities).

2 Replies

John Lauer ·

Noah, agreed: rank first, then place and route in that order. Here is the plan, adapted to how AI Flow works now. Since 0.2.48 it is a suggestion engine and never refuses, so the ranking will shape suggestions and won't be a required field.

  1. spec.signalPriority, in the shape you proposed: ordered classes, each with nets and a reason. step placement suggests writing it, with a first draft the AI can edit. The draft comes from what the spec already knows: impedance targets, switch nodes, loads, hot parts and net names. If the AI skips it, the flow goes on; the report card just lists it as "not ranked".
  2. Placement: place check reports each top-class ratsnest length and loop area, worst first, and place pack takes the wish order from the ranking.
  3. Routing: route routes classes in rank order. Each class can carry a via budget, geometry strictness, width and plane rule, as preferences the report compares against. They don't gate anything.
  4. Per-class report in gate and finish, built on 0.2.49's route-quality report (#127, #128). For example: "gate drive: 6 lines, worst GHA 47 mm, 2 vias (preference 0)".

0.2.49 already has the measurement half: vias, length and detour per signal net, plus placement suggestions. The ranking is next. I'm keeping this open until it ships.

Colby Knox mentioned this in pull request #67 ·
Colby Knox linked pull request #86, which closes this when it merges ·
Colby Knox closed this in pull request #86 ·
Colby Knox ·

Noah, the signal ranking is in AI Flow 0.2.67, built the way John planned it with you (suggestions, never a gate).

  • spec.signalPriority takes your shape: ordered classes, each with nets (names or patterns like GH*, BEMF_?), why, and optionally noisy, sensitive, viaBudget and maxLengthMm.
  • route routes the classes in that order. Inside a class it keeps its own order, and nets in no class come last. Its log says "routing N signal nets, by the spec's signalPriority classes, then shortest first".
  • route, gate and finish give a line per class, for example "2. gate drive: 6 routed net(s), worst GHA 47.0 mm, 2 via(s) (preference 0 per net); over 25 mm: GHA".
  • adom-aiflow priorities drafts a ranking from the spec (switch nodes, loads, impedance targets) and the net names, for the AI to reorder and explain. step placement suggests it when the spec has none.
  • place pack says when a higher-ranked part comes later in the wishes than a lower-ranked one. It still packs in the AI's order.
  • finish notes "not ranked" when there's no ranking, and nothing refuses.

On a buck molecule, the draft put SW and VOUT first, then BOOT, then FB and FBM. The router took them in that order.

Not in this release: rip-up that spares a higher class. The router can still rip a ranked net to make room for an unranked one.

Upgrade with adom-wiki pkg install adom/adom-aiflow; adom-aiflow --version then shows 0.2.67.

Log in to reply.