--- title: "From Schematic to Test Plan: KiCad and Altium" description: "Schematic to test plan: derive bring-up and DVT tests from a KiCad or Altium design, from nets and test points to BOM checks and datasheet limits." url: https://galoislabs.ai/blog/schematic-to-test-plan author: Alex Hernandez author_url: https://galoislabs.ai/blog/authors/alex-hernandez published: "2026-08-21" topic: Design to test publisher: Galois Labs --- # From schematic to test plan: bring-up and DVT tests from KiCad and Altium designs ![A bare circuit board on standoffs in isometric, three spring probes hanging just above three of its test pads.](https://galoislabs.ai/blog/figures/board-1.light.webp) *FIG. 1 — BOARD, TEST POINTS, PROBES* 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](https://docs.kicad.org/10.0/en/cli/cli.html) and Altium's documentation, limits from [TI's TLV755P datasheet](https://www.ti.com/lit/ds/symlink/tlv755p.pdf). ## 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. | Design artifact | What it answers | Checks it produces | | ---------------- | -------------------------------------------------------- | ------------------------------------------------------------------- | | Nets and rails | What is connected, what drives each rail, what loads it | Rail resistance to ground, rail voltage, sequencing, current budget | | Test points | Where a probe or fixture pin can reach each net | Probe location per measurement; a list of nets that need one | | Datasheet tables | Guaranteed minimum and maximum values, and damage limits | Pass/fail limits; supply and load settings that stay inside ratings | | BOM | Which part, from which manufacturer, fitted or not | Which datasheet applies; ID reads; DNP exclusions; second sources | 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: ```sh title="export.sh" 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](https://galoislabs.ai/blog/kicad-netlist-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: ```text title="Rail table, example board" 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](https://www.altium.com/documentation/altium-designer/orcad-export) 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](https://www.altium.com/documentation/altium-designer/pcb-dlg-testpointmanagertestpoint-manager-ad) 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](https://www.altium.com/documentation/knowledge-base/altium-designer/generating-ipc-d-356a-document-and-compare-to-extracted-netlist). 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](https://www.altium.com/documentation/altium-designer/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: | Datasheet entry | Value | What it becomes in the plan | | ---------------------------------------------------------------------------- | ----------------- | -------------------------------------------------------------- | | Absolute maximum, supply voltage VIN | −0.3 to 6.0 V | Ceiling for the bench supply's limit on VBUS | | Recommended operating VIN | 1.45 to 5.5 V | Outer bounds for DVT input sweeps | | Output accuracy, TJ −40 to 85 °C, VIN = VOUT + 0.5 V, IOUT = 1 mA | −1% to +1% | 3.267 to 3.333 V on +3V3 at light load | | Dropout at 500 mA, 3.3 to 5.0 V outputs, TJ −40 to 125 °C | 238 mV maximum | Input below about 3.54 V at full load is outside the guarantee | | Output current limit, measured where VOUT falls to 90%, 1.5 to 4.5 V outputs | 560 to 865 mA | Expected window in an overload test | | Load regulation, 0.1 to 500 mA | 0.060 V/A typical | No limit: a typical value, so the limit is a design decision | (Source: [TI TLV755P datasheet, SBVS320D, sections 5.1, 5.3 and 5.5](https://www.ti.com/lit/ds/symlink/tlv755p.pdf)) 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. > **Typical is not a limit** > > A typical value is what the manufacturer expects, not what it guarantees. When the only number in the table is typical, the limit is an engineering decision: write it down with the reason, so the next reviewer does not mistake it for a datasheet guarantee. **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](https://galoislabs.ai/blog/kicad-netlist-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. | | Bring-up | DVT | | ------------- | ------------------------------------------- | --------------------------------------------------- | | Question | Is it safe to power, and is it alive? | Does it meet its specification across conditions? | | Units | The first boards of a revision | A sample of production-intent units | | Conditions | Room temperature, nominal input, light load | Input range, load range, temperature corners | | Limits | Wide enough to catch faults, not to grade | Guaranteed values, tolerance stacks and guard bands | | Design inputs | Netlist, test points, current budget | All of those, plus every datasheet table | 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](https://galoislabs.ai/blog/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](https://galoislabs.ai/blog/electronic-load-automation), repeat at temperature, and tighten the limits to the guaranteed values. [EVT, DVT and PVT testing](https://galoislabs.ai/blog/evt-dvt-pvt-testing) covers how the phases divide the work, and the [power rail validation plan](https://galoislabs.ai/blog/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: | ID | Phase | Net and probe | Measurement | Limits | Source | | ------ | -------- | ----------------------------- | --------------------------------------- | -------------------------------------------------- | ---------------------------------- | | PWR-01 | Bring-up | +3V3 at TP2, unpowered | Resistance to GND | Not a short; compared against the first good board | Netlist | | PWR-02 | Bring-up | VBUS, bench supply readback | Input current at first power | Within the load current budget | BOM, load datasheets | | PWR-03 | Bring-up | +3V3 at TP2 | DC voltage at first power | Wide, such as ±5%: a recorded plan decision | U1 part number: fixed 3.3 V output | | PWR-04 | DVT | +3V3 at TP2 | DC voltage, 3.8 V in, light load | 3.267 to 3.333 V, less guard band | TLV755P §5.5, output accuracy | | PWR-05 | DVT | +3V3 at TP2, VBUS at TP1 | Regulation at 500 mA as VBUS falls | Holds down to 3.54 V input | TLV755P §5.5, dropout | | PWR-06 | DVT | +3V3 at TP2, VBUS at 3.79 V | Load current where +3V3 falls to 2.97 V | 560 to 865 mA | TLV755P §5.5, current limit | | REF-01 | Bring-up | VREF, probe point to be named | DC voltage | From the reference's datasheet | Netlist: no test point | 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](https://galoislabs.ai/blog/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](https://galoislabs.ai/blog/scpi-automation-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](https://galoislabs.ai/blog/review-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](https://galoislabs.ai/instruments), 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](https://galoislabs.ai/product) shows how sequences, runs and reports connect, and [AI test automation for hardware benches](https://galoislabs.ai/blog/ai-test-automation-hardware) covers what changes when agents write and run the tests. ## Frequently asked questions ### Which tests come from the netlist and which from the BOM? The netlist gives connectivity: which rails exist, what drives and loads each one, and which test point reaches it. That yields rail-to-ground resistance, rail voltage and sequencing checks, plus a list of nets that need a probe. The BOM gives each part's identity, which leads to its datasheet: pass/fail limits, ID register reads, the current budget, DNP exclusions and second-source windows. ### What is the difference between absolute maximum ratings and electrical characteristics? Absolute maximum ratings are damage limits: exceeding them may cause permanent damage, and staying just inside them implies nothing about correct operation. Electrical characteristics are guaranteed minimum and maximum values under stated test conditions. Pass/fail limits come from the electrical characteristics; supply, load and stress settings stay inside the absolute maximum ratings, and functional tests stay inside the recommended operating conditions. ### Can Altium show which nets have no test point? Yes. The Testpoint Manager, opened with Tools » Testpoint Manager in the PCB editor, lists every net with a Complete or Incomplete status for fabrication and assembly testing, and can assign testpoints automatically under Testpoint Style and Testpoint Usage rules. File » Fabrication Outputs » Test Point Report exports the result, with an IPC-D-356A option. ### Can a test plan be generated from a BOM? Partly. A BOM names each part, which leads to the datasheet tables that set limits and to checks such as ID reads and current budgets. Which rail a part sits on, and where to probe it, come from the netlist and the test points. An agent can draft a sequence from them; review it like any draft before it drives hardware.