Post-silicon validation is not one team's job. When first silicon arrives, engineers from design, verification, board design, software, analog, test, reliability and customer support all work on the same chips at once, often in the same lab, under the same deadline.
Knowing who does what, and how a failure travels from the person who sees it to the person who fixes it, is half of understanding how post-silicon validation works. This article describes the usual roles, how they work together, and the bug-tracking process that ties them together.
6 min read | Beginner
What You'll Learn
- List the main roles in a post-silicon team and what each delivers
- Describe how roles start working long before silicon arrives
- Follow a failure from discovery to root cause and fix
- Explain why bug tracking and triage matter so much
The Roles
Team names differ between companies, and in a small company one person may hold several roles, but the work itself is much the same everywhere:
| Role | What it does |
|---|---|
| Validation planning and leads | write the post-silicon validation plan, track progress against it, run triage, report readiness for the production release decision |
| Platform and bring-up | design the validation and debug boards, sockets and lab setups; power on the first chips |
| Functional validation | write and run tests and test generators on silicon, boot and stress software, check results |
| Compatibility and system validation | run the chip with operating systems, peripherals and applications as products will use it |
| Electrical validation | measure I/O timing and signal quality, power delivery, clocks and analog blocks across conditions |
| Characterization and product engineering | measure many parts to set specifications and speed grades, correlate with test, follow yield |
| Silicon debug | find the root cause of failures that are not obvious, using the chip's debug features |
| Design and design-for-debug | the designers of each block, who confirm bugs, propose fixes and workarounds; the team that built the debug features |
| Firmware and software | boot code, drivers and workarounds in software or firmware |
| Failure analysis | physical analysis of failing parts: probing, imaging, cross-sections |
| Test engineering | the manufacturing test program, which often finds and confirms problems too |
| Reliability and quality | qualification, burn-in and failure rate data |
| Customer or applications engineering | support customers using early samples and bring their problems back |
The activity categories overlap, and post-silicon validation in practice involves close collaboration among all of them. A functional failure may turn out to be electrical, an electrical problem may need a firmware workaround, and a customer's report may need all three.
Work Starts Before Silicon
Most of these roles are busy long before the first chip arrives. On large processors, the team preparing lab tools and tests often starts as soon as the key features are fixed at the high-level design stage, and later runs its test programs, often called exercisers, on a hardware acceleration platform before silicon exists. That checks the exercisers, helps pre-silicon verification find bugs of its own, and prepares the test runs used in the lab.
The general pattern:
- The validation leads write the plan and get design-for-debug features into the design.
- The platform team designs and builds boards so they are ready when the chips arrive.
- Validation and software teams develop tests and firmware on emulators and FPGA prototypes.
- Electrical and characterization teams prepare their equipment and measurement scripts.
- Test engineering prepares the first version of the manufacturing test program.
Quick Check
Q: Why would a chip company design its validation boards months before the first chip exists, rather than after seeing the chip work?
Show Answer
Boards take months to design, manufacture and debug, and nothing can be validated without them. If they are not ready when silicon arrives, the expensive and fixed time between first silicon and production release is spent waiting. Building them early, from the chip's pinout and package, lets bring-up start on the first day.
The Life of a Failure
A failure travels through several hands:
- Seen. A test fails in the lab, or a customer reports a problem.
- Logged. It is entered in the bug database with the conditions: silicon revision, part, board, voltage, frequency, temperature, software version, how often it fails.
- Triaged. A regular meeting of leads decides how serious it is, who owns it, and whether it might duplicate a known bug.
- Reproduced and classified. Is it the test, the board, the software, an electrical margin, a defect in that one part, or a real design bug?
- Root-caused. Debug engineers and designers find the exact mechanism.
- Worked around and fixed. A workaround keeps validation moving; the fix goes into software, firmware, or the next silicon revision.
- Verified. The fix or workaround is tested, and the bug is closed but kept on record.
Bug Tracking and Triage
Bug tracking is an important tool for the whole design cycle: each bug is entered with its location, nature and severity, the person who found it and the person responsible for fixing it. Fixed bugs stay in the system, so that reintroduced bugs can be spotted and problem areas of the design become visible.
The number of bugs over time shows whether a design is converging: a downward trend means it is, an upward trend that it is early in its verification.
In post-silicon work, the bug database is also the main input to the production release decision, described in The Post-Silicon Timeline. That makes discipline important: duplicates inflate the count, missing conditions make bugs impossible to reproduce, and a bug that is fixed in the design but not checked on the next revision may still be in the product.
Quick Check
Q: Three engineers in different teams each log the same hang under different names. Why is that a problem beyond extra paperwork?
Show Answer
The bug count and trend no longer reflect reality, so readiness looks worse than it is; three people may debug the same problem in parallel, wasting scarce lab time; and a fix may be checked against only one of the three reports. Triage merges duplicates so the database stays a reliable picture of the chip.
In Practice
In the first weeks after silicon arrives, lab time is the scarcest resource: there are few chips, few boards and many teams. Labs schedule boards and testers around the clock, run long tests overnight and keep the most capable debug setups for the hardest failures. The daily triage meeting decides which failures get those setups first, usually the ones that block other teams.
Common Mistakes
Mistake #1: Logging a failure without its conditions
A failure without the revision, part, board, voltage, frequency, temperature and software version is often impossible to reproduce. Record them every time.
Mistake #2: Assuming every failure is a design bug
Many lab failures come from tests, boards, software or a single marginal part. Classify before debugging the design.
Mistake #3: Closing a bug when the fix is designed
A bug is closed when the fix is verified on the silicon revision that contains it, not when the design change is made.
Practice Exercise
Challenge: Route the Failures
Which role should own each first: (a) a USB device enumerates on one brand of host but not another; (b) the I/O voltage on one board sags when all outputs switch; (c) one chip out of 40 hangs in every test, all others pass; (d) the processor hangs only when two specific cache operations meet in the same cycle?
Hint
First ask whether the problem is about compatibility, electrical behaviour, one part or the design's logic.
Solution
(a) Compatibility validation, with the USB block's designers. (b) Electrical validation, with the platform team, since the board's power delivery may be the cause.
(c) Characterization or product engineering, and possibly failure analysis: a single failing part suggests a defect, not a design bug. (d) Functional validation and silicon debug, with the cache designers: an identical failure on every part is a design bug.
Summary
- Post-silicon validation involves many roles: planning, platform, functional, compatibility and electrical validation, characterization, debug, design, firmware, failure analysis, test, reliability and customer engineering.
- Most roles start long before silicon, preparing boards, tests, firmware and debug features.
- A failure is logged with its conditions, triaged, reproduced, classified, root-caused, worked around, fixed and verified.
- The bug database and its trend are the main evidence for the production release decision.
