A bring-up checklist is the ordered list of checks a new chip, board or silicon revision must pass before broad validation starts. A smoke test suite is its automated form: a short set of tests that touch every major feature and run in minutes.
Together they answer one question quickly: is this part, on this board, healthy enough to spend validation time on? This article describes what goes into both, and how comparing parts and boards separates a bad part from a bad setup.
6 min read | Beginner
What You'll Learn
- Build a bring-up checklist with clear pass and fail gates
- Describe what a smoke test suite contains and when it runs
- Use known-good references to separate part, board and setup problems
- Record bring-up results so they stay useful
The Checklist
A checklist is written before silicon arrives, from the design's power, clock and reset specifications and the validation plan. Each item has a measurable result and a limit:
| Gate | Example checks |
|---|---|
| Setup | board revision, socket, configuration switches, firmware version, supply settings |
| Power | rail resistance before power; current per rail within limits; sequence correct |
| Clocks | reference clock present; PLLs lock; measured frequencies correct |
| Reset and debug | reset completes; JTAG ID correct; registers read and write |
| Memories | on-chip SRAM test; DRAM training results within range; DRAM test |
| Peripherals and interfaces | serial port, timers, interrupts, each high-speed link trains |
| Smoke tests | full suite passes |
The gates run in order. A failure at a gate stops the sequence there, because everything after it depends on it.
Smoke Tests
A smoke test suite is a set of short tests, typically minutes in total, that exercise each major feature once. It does not try to find subtle bugs; it checks that nothing basic is broken.
It runs whenever something changes:
- every new part placed in a board,
- every new board,
- every new silicon revision, as in Validating a New Stepping,
- every new version of firmware or test software.
Because it is fast, it catches setup problems before they waste hours of a long test. Its results also give a first health record for every part in the lab.
Quick Check
Q: A 12-hour stress test fails after 10 hours on a newly installed part. Later the team finds that the part's DRAM training had marginal results. What should have caught this earlier?
Show Answer
The checklist and smoke tests. DRAM training results with limits are a checklist item, and a smoke run on the new part would have flagged the marginal training in minutes, before the long test started.
Known-Good References
When something fails, the first question is where the problem lives: in the part, the board, the setup or the software. Known-good references answer it.
A team keeps a few golden parts and golden boards that passed everything and are not modified. A failing combination is then swapped against them.
- If the failure follows the part to the golden board, the part is suspect.
- If it stays with the board when a golden part is used, the board is suspect.
- If every combination with a golden item passes, the problem is in the setup or in how this part and board interact.
Software and firmware get the same treatment: a known-good version is kept to rule them out.
Recording Results
Each checklist run is recorded with the part's identity, the board, the revision of everything involved and the measured values, not just pass or fail. Measured values show trends: a current slightly higher on every part from one wafer, or PLL lock taking longer at low temperature. Many chips have an electronically readable identity, such as fuse-programmed wafer, lot and die coordinates, which links every result to where the part came from.
Quick Check
Q: Why record measured values, such as each rail's current, rather than only pass or fail?
Show Answer
Values show trends and margins that pass or fail hides: a part close to a limit, a drift over time, or differences between wafers and lots. They also give later debug a baseline to compare against when a part starts failing.
In Practice
Checklists and smoke tests are usually run by scripts that drive the supplies, debugger and instruments and write the results to a database. A dashboard then shows every part and board in the lab with its latest status. Teams that do this well spend the first days of a new revision on real validation, not on guessing which setups are healthy.
Common Mistakes
Mistake #1: Skipping the checklist on "known" boards
Boards get modified, switches get moved and firmware changes. Run the checks every time something changes.
Mistake #2: Modifying the golden references
A reference that has been reworked or reconfigured is no longer a reference. Keep golden parts and boards untouched.
Mistake #3: Logging only pass or fail
Without measured values, trends and margins are invisible.
Practice Exercise
Challenge: Locate the Problem
New part P fails smoke tests on new board B. Golden part G passes on board B.
Part P passes on golden board R. Golden part G passes on board R. Where is the problem likely to be, and what would you check?
Hint
Only one combination fails.
Solution
Part P and board B each work with a golden partner, so neither is simply bad. The problem is in their interaction: for example P is slightly slow and B's supply is slightly low, or B's memory needs training settings P is marginal with. Check P's measured currents and training results on both boards and B's supply and clock measurements, and look for a margin issue rather than a hard defect.
Summary
- A bring-up checklist is an ordered set of gates with measurable limits: setup, power, clocks, reset and debug, memories, interfaces, smoke tests.
- Smoke tests run in minutes and are repeated for every new part, board, revision and software version.
- Golden parts and boards separate part, board and setup problems through swapping.
- Recording measured values and part identities turns bring-up results into trend data.
