The Post-Silicon Validation Plan

A post-silicon validation plan is the document that says what will be tested on the first chips, how, with what equipment and software, by whom, and what results are needed before production. It is written long before silicon exists, at the same time as the chip's architecture, because everything post-silicon validation needs, from debug features in the design to boards in the lab, takes months to prepare. This article describes what goes into the plan, when each part is prepared, and how the plan defines when validation is done.

7 min read | Intermediate

What You'll Learn

• List the parts of a post-silicon validation plan
• Explain why the plan starts with the architecture, not with the RTL
• Describe the readiness work that runs in parallel with the design
• Define exit criteria that support the production release decision

Readiness Starts at the Architecture

The work that prepares for first silicon is often called post-silicon readiness. It runs in parallel with architecture, design, implementation and pre-silicon verification, and it starts at about the same time as product planning.

That timing has a consequence: when the validation plan is first written, there is no detailed design yet, often not even a full microarchitecture. The first version is written from the architectural specification and refined as the design matures, new features are added, and the target applications become clear.

Post-silicon test plans are usually more elaborate than pre-silicon ones. Pre-silicon plans focus on blocks and their interactions within the short tests a simulator can run. Post-silicon plans target system-level use cases: the chip booting an operating system, running real applications, entering and leaving power states, talking to real peripherals, which cannot be exercised in simulation.

What the Plan Contains

Features and coverage targets

The heart of the plan is a list of what must be shown to work: every feature, mode and interface, each with the scenarios and corner cases to cover and how coverage will be judged. Each item says which platform covers it: some features are fully verified before silicon and need only a quick check, others, such as long software scenarios, electrical behaviour and speed paths, can only be covered on silicon.

Test content

Two kinds of tests are planned:

• Focused tests, written by experts to target specific features: multiprocessor protocols, register configurations, address decoding, power management. They take a lot of manual effort and can run for hours on silicon.
• Random and constrained-random tests, such as generators that produce random instruction sequences or random interleavings of traffic, to exercise the chip in ways nobody thought of. On silicon such a generator can run hundreds of millions of seeds.

Because silicon runs so many cycles, test templates for silicon must allow much more variation than pre-silicon ones; a template that is too specific quickly starts repeating itself.

Platforms and equipment

Debug boards, system boards, sockets, test cards and peripherals, the number of each, and the lab equipment for electrical measurements and temperature control. Compatibility validation needs large collections of peripherals and software versions, which must be bought and set up in advance.

Design-for-debug requirements

What the chip itself must provide: which internal states must be observable, which features must be possible to disable or override, how the debugger connects, how much trace storage there is, and how debug access is protected in production parts. These requirements go to the design team early, because they become hardware. The next articles, starting with Design for Debug: Observability and Controllability, cover them in detail.

Debug software

A surprising amount of software is needed before the first test can run:

• Instrumented system software: a reduced operating system or bare-metal environment with debug hooks, because a full commercial operating system is too complex to debug hardware under.
• Configuration and trigger tools to read and set internal registers and set up tracing, for example "trace signal S only when register R holds value u".
• Transport software to move debug data off the chip, through the debug pins or through functional ports such as USB, without disturbing the function it is observing.
• Analysis software to turn raw trace bits into transactions, timelines and statistics.

Debug software is written for a chip that is still changing, so it has bugs of its own. It is common for a lab failure to be traced back to the debug software rather than the silicon.

Schedule, people and the bug process

Who does what, as in Teams and Roles in Post-Silicon Validation, how many chips and boards each team gets, and how failures are handled. Many teams use staged terms: a failure that survives the first sanity checks is a pre-sighting; once it can be reproduced reliably it becomes a sighting; once a plan to track, work around and fix it exists, it is a bug.

Exit Criteria

A good plan says in advance what "done" means, so that the production release decision of The Post-Silicon Timeline is a check against agreed criteria rather than a debate. Typical criteria:

Thresholds differ between products. A chip for cars or medical devices needs far stricter criteria than a consumer part, and a part that can be patched in the field can accept more known issues than one that cannot.

Keeping the Plan Alive

The plan changes throughout the project. Features are added or cut, pre-silicon verification finds areas that are weak and need more silicon coverage, and after first silicon the plan is updated with what was learned: areas full of bugs get more tests, and areas that turned out clean need fewer. Many teams track plan items in the same system as bugs, so progress and readiness can be reported from one place.

In Practice

A common technique is to run the post-silicon test content on an emulator or hardware accelerator before tapeout. It checks that the tests themselves work, finds pre-silicon bugs as a side effect, and measures which plan items the tests actually cover, so the gaps can be filled before the lab needs the tests. Shortly before first silicon, a regression suite is assembled from the tests that reached the most coverage on the accelerator, ready to run on the first day.

Common Mistakes