From schematic to test plan: bring-up and DVT tests from KiCad and Altium designs

To turn a schematic into a test plan, export the netlist and BOM, list every power rail with the part that drives it and the test point that reaches it, take limits from each part's datasheet tables, and write one check per requirement with its source recorded. KiCad and Altium both export everything the method needs.

The example board throughout is USB power into a TI TLV755P 3.3 V LDO feeding a microcontroller. Commands come from the KiCad 10.0 CLI reference and Altium's documentation, limits from TI's TLV755P datasheet.

What does a schematic give a test plan?

A test plan answers four questions for every check: what is measured, where the probe goes, what counts as a pass, and which part the limit came from. The design files answer all four.

A plan written from memory covers the rails someone remembered. A plan derived from the design covers every rail, and when the design changes, a diff of the derived tables shows which tests change with it.

Which design exports does the plan need?

Two come from the schematic: a netlist for connectivity and a BOM for part identity. A test point map follows once the board is laid out. In KiCad, kicad-cli writes the first two, so the same script runs on every revision and in CI:

mkdir -p out
 
# Connectivity as XML: components with their fields, nets with pin types
kicad-cli sch export netlist --format kicadxml -o out/board.xml board.kicad_sch
 
# BOM, one row per reference, with the part-number fields the datasheet lookup needs
kicad-cli sch export bom -o out/bom.csv --exclude-dnp \
  --fields 'Reference,Value,Footprint,MPN,Manufacturer' \
  --labels 'Reference,Value,Footprint,MPN,Manufacturer' \
  board.kicad_sch

• MPN and Manufacturer are your fields, not KiCad's. The BOM default is Reference,Value,Footprint,QUANTITY,DNP, labeled Refs,Value,Footprint,Qty,DNP. Name the field your library uses for the manufacturer part number; it is what leads to a datasheet. Without --group-by, each row is one reference.
• Variants. KiCad 10 adds --variant to the netlist and BOM exports. With assembly variants, export the one the plan is for.

KiCad netlist to test points covers the XML format, a full rail parser in Python, and where test point coordinates come from on the board.

What does the rail table tell you?

Start with the power rails, which bring-up and DVT both depend on. A short script over the XML netlist lists each rail with the part that drives it (pins typed power_out), how many loads it feeds (pins typed power_in), and any test point on the net, skipping DNP parts. On the example board, with the optional sensor U3 marked DNP, the table reads:

VBUS       from J1 (USB_C)                 loads  1 probe TP1
+3V3       from U1 (TLV75533PDBVR)         loads  1 probe TP2
VREF       from ?                          loads  1 probe NONE

The table is only as good as the symbols' pin types: a regulator output drawn as a passive pin shows up as from ?.

The useful lines are the incomplete ones. VREF has no identified source and no test point: either it gets one next revision, or the plan names a probe location now, such as a decoupling capacitor pad. The +3V3 line says what to read next: the TLV755P datasheet.

How do I get the same data out of Altium?

Altium Designer keeps the same information in different places:

• Netlist. Design » Netlist For Project generates a netlist for every schematic in the project in the format you choose, such as OrCAD/PCB2. Add the same generator to an Output Job's Netlist Outputs category so each release exports identical files.
• Test point coverage. In the PCB editor, Tools » Testpoint Manager lists every net with a Complete or Incomplete testpoint status, separately for bare-board fabrication testing and in-circuit assembly testing. It can assign testpoints automatically under Testpoint Style and Testpoint Usage rules, and it needs at least one Style rule scoped to All. It answers the probe NONE lines above.
• Test point report. File » Fabrication Outputs » Test Point Report exports the assignments, with an IPC-D-356A option. The same article compares that file against a netlist extracted from the Gerber and drill data, which confirms the fabrication data matches the design before bring-up.
• BOM. ActiveBOM keeps the BOM as a .BomDoc, which Altium describes as the master list of items needed to build the board, with design components mapped to manufacturer parts.

The parsing differs; the rail table and the rest of the method do not.

Where do test limits come from?

From the datasheet of the part that sets the value, where three tables do different jobs. TI's footnote on the TLV755P says it plainly: operation outside the absolute maximum ratings may cause permanent damage, and those ratings "do not imply functional operation" at those conditions. Recommended operating conditions bound where the part is meant to work. Electrical characteristics are the guaranteed minimum and maximum values under stated test conditions: the source of pass/fail limits.

Here is what the TLV755P datasheet (revision D, September 2024) gives the +3V3 rail, for the SOT-23-5 DBV package:

Source: TI TLV755P datasheet, SBVS320D, sections 5.1, 5.3 and 5.5

Three habits keep these limits honest.

Check the conditions, not just the numbers. The ±1% accuracy holds at a 1 mA load with 3.8 V in. Under real load, add load regulation: about 3 mV typical at 50 mA. From 5 V in, add line regulation: 2 mV typical.

Stack the tolerances on adjustable rails. A regulator with a feedback divider sets its output as Vout = Vref × (1 + R1/R2). With a 0.8 V reference at ±1% and 1% resistors, the divider ratio can move about 2%, and that moves Vout by 2% × (1 − Vref/Vout). For a 3.3 V output that is about 1.5%, so the rail's worst case is about ±2.5%, not the ±1% on the regulator's front page. The BOM gives the resistor tolerances; the datasheet gives the reference. KiCad netlist to test points works the corners through for a 5 V buck and reads the values from the schematic.

Respect the lowest rating on the net. The netlist lists every part on VBUS. The bench supply's limit for that net sits below the lowest absolute maximum among them; functional tests stay inside the narrowest recommended range. For the TLV755P alone, that means a limit under 6.0 V and a sweep that stays within 1.45 to 5.5 V.

Then subtract measurement uncertainty. The +3V3 window is 66 mV wide; the meter's specified accuracy at that reading comes off both ends (a guard band), or the plan records why not.

Which checks come from the BOM?

The BOM says what each part is, and several checks follow from that alone.

• One part number, one datasheet revision. Record the datasheet revision next to each limit. When a manufacturer revises a table, you can find every limit that cited the old one.
• Second sources. If the BOM approves an alternate, the pass/fail window has to accept both parts' guaranteed ranges, while stress settings must respect the lower of the two absolute maximums. One is the union, the other the intersection.
• Unfitted parts. DNP parts get no tests. KiCad marks them in the netlist and --exclude-dnp drops them from the BOM; the rail table skips them too.
• Identity reads. Many parts with a digital interface have an ID or version register. Reading it confirms the part is fitted, powered and reachable; the expected value is in its datasheet.
• Clocks. A crystal's or oscillator's datasheet tolerance sets the limits for a frequency check.
• Current budget. The sum of each load's datasheet supply current, with margin, is the expected input current at first power. A board drawing far more has a fault, and the current-limited supply should stop it there.

How does a bring-up plan differ from a DVT plan?

Both plans come from the same derived tables but ask different questions.

A bring-up plan runs in a fixed order: unpowered resistance from each rail to ground to catch shorts, first power from a current-limited supply, rails in their sequencing order, then clocks, resets and the first bus transactions. The board bring-up checklist covers each step.

DVT takes the same rows and adds conditions: sweep VBUS across the recommended range, step the load with an electronic load, repeat at temperature, and tighten the limits to the guaranteed values. EVT, DVT and PVT testing covers how the phases divide the work, and the power rail validation plan goes deeper on ripple, transients and sequencing.

What does a design-derived test plan look like?

Each row names a net, a probe location, a measurement, limits, and the source of those limits. For the example board:

The source column is what makes the plan maintainable. When U1 changes to another part, every row citing the TLV755P is up for review. When TP2 moves, the probe map changes and the limits do not. Keep the export script, the rail table and the plan in version control next to the design, regenerate them on every revision, and review the diff. Hardware test traceability covers tying each result back to the requirement and design revision it checks.

Each row then becomes a script step; SCPI instrument automation with Python covers the instrument side.

Where does Galois fit?

Galois is agent-driven test engineering for hardware teams: agents generate tests and instrument drivers, run them on real benches through the open-source galois-edge daemon, and turn the results into reports and a shared engineering record.

In Galois, the plan table becomes the objective. Open Évariste, the agent in the Galois platform, from the app sidebar (Ctrl+Shift+E) beside the project, and check that the bench supply and meter appear in its list of connected instruments. Then state each row with its probe, limits and source, for example PWR-04: bench supply at 3.8 V on VBUS, meter on +3V3 at TP2, light load, pass from 3.268 to 3.332 V (3.267 to 3.333 V per TLV755P §5.5, less a 1 mV guard band for the meter). Évariste drafts a sequence from the rows, and every edit, in conversation or in the sequence builder, is a new version with a diff. For an instrument without a profile, upload its programming manual; Évariste generates a profile and, after you review it, deploys it to the edge that hosts the instrument and binds it.

Sequences from Évariste are a first draft. Check every limit against its source, then approve the sequence before it drives hardware; how to review an AI-generated test plan lists what to look for. Once approved, start the run; galois-edge executes it on the bench and Monitor shows the channels live. Steps drive instruments through the instrument library, which lists 573 profiles, and each step records the SCPI sent, the raw response, the measured value and its limits. After the run, ask Évariste which steps passed close to a limit, and "Generate a test report from the last run" builds the report. The limits, the review, the approval and the bench setup stay your job; the instrument code, logging and report script are no longer yours to write.

Galois design plugins are in build: an Altium extension that snapshots the design and cross-probes findings back to the schematic, and a KiCad client at an earlier stage. For now, the exports in this essay are the bridge.

The product overview shows how sequences, runs and reports connect, and AI test automation for hardware benches covers what changes when agents write and run the tests.