How to evaluate an AI PCB design tool

Choose a task that can actually fail

Write the supply range, interfaces, board outline, allowed layers and required deliverables before running the tool. Include a constraint that a generic reference design will miss. Keep the brief identical across tools, and document any clarification provided to one entrant so the others receive the same information.

Inspect the artifact, then the explanation

Open the schematic and board in the target EDA application. Check connectivity, part identity and the rule settings before inspecting routing statistics. A report saying DRC passed is weaker evidence than a reproducible report generated from the submitted files under your frozen rule deck.

Record intervention alongside success

Separate fully automatic completion from a design repaired by an engineer. Record elapsed time, tool calls, failed attempts and editing time. A useful evaluation can show that a tool accelerates review even when it cannot autonomously finish a board; those are different outcomes and deserve different metrics.

Practical checklist

1. Freeze the brief and input files.
2. Require the native project and manufacturing exports.
3. Run ERC, DRC and requirements checks independently.
4. Record human edits and failed attempts.
5. Repeat on a second, structurally different board.

A concrete example

Ask two tools to design the same sensor board from a written brief.

Evidence to accept

Both outputs are checked with the same rules and a published list of required functions.

Evidence that is insufficient

One entry gets a repaired netlist or relaxed clearances without that intervention being recorded.

Common questions

Primary references and further reading

Use the matching device documentation and project configuration when applying this checklist. These references explain the underlying tools and evaluation approaches.

• KiCad PCB editor documentation
• KiCad schematic editor documentation
• PCBWorld: engine-grounded PCB design automation