Post-Silicon Validation Interview Questions

Why is post-silicon validation needed if pre-silicon verification is thorough?

Silicon runs millions of times faster than simulation, so in a few minutes it reaches states that pre-silicon verification never covered. It also shows effects that models do not capture: electrical behaviour across voltage and temperature, real software and real boards, and variation between manufactured parts.

Only a small share of bugs escape to silicon, but they are the hardest ones, and finding them before customers do is the purpose of post-silicon validation.

Read more on Pre-Silicon vs Post-Silicon.

What is the biggest challenge of debugging on silicon?

Observability. In simulation every signal is visible at every cycle, but on silicon only the pins, a few trace signals and whatever can be dumped through debug logic are visible. The cause of a failure can also be millions of cycles before the symptom, so the trace window rarely contains it.

Controllability is limited too: it is hard to force a precise internal condition. Design-for-debug features are added before tapeout to reduce both problems.

Read more on What Is Post-Silicon Validation?.

Which design-for-debug features would you ask for before tapeout?

• Scan dump of all flops and array dump of memories through JTAG.
• On-chip trace buffers with flexible triggers and cross-triggering between blocks.
• Performance and event counters.
• On-die voltage, temperature and droop monitors.
• Clock stretching or single-cycle clock control for speedpath debug.
• A cycle-reproducible mode, and chicken bits to disable risky features.
• Spare cells so bugs can be fixed with metal-only changes.

Read more on Design for Debug.

What are the steps of bring-up on first silicon?

Bring-up starts with power: check for shorts, then ramp supplies with current limits while watching the current. Next come clocks and reset, then debug access through JTAG, reading identification registers to confirm the chip responds.

After that, simple code runs from on-chip memory, then memory interfaces are trained, firmware boots, and finally an operating system and applications run. Each step builds on the one before, and the order is rehearsed on emulation before silicon arrives.

Read more on First Power-On and Bring-Up Checklist.

How do you check results of tests running for billions of cycles on silicon?

Comparing every cycle with a reference simulation is far too slow, so tests check themselves. Common methods are self-checking tests that compute and compare expected results, multi-pass consistency where the same test runs several ways and the results must match, signatures that compress results into a checksum, and comparison with a reference model at chosen points.

On-chip exercisers use these methods to generate, run and check random tests in a loop without a host.

Read more on Checking Results on Silicon.

What is a shmoo plot?

A shmoo plot shows pass or fail of a test across two swept conditions, usually supply voltage and clock frequency. A healthy part reaches a higher frequency as voltage rises, so the boundary between pass and fail rises smoothly.

Other shapes point to specific problems: failures at low frequency (a floor) suggest leakage on a dynamic node, failures above a voltage at every frequency (a wall) suggest noise or a race, and random pass and fail cells suggest uninitialized state.

Read more on Shmoo Plots.

What is a skew lot?

A skew lot is a set of wafers processed on purpose to land near the process corners: fast NMOS and fast PMOS, slow and slow, and the mixed corners. It gives validation many corner parts early, instead of waiting for natural variation to produce them.

Slow parts limit maximum frequency, fast parts limit power, leakage and hold timing, and mixed corners expose ratioed circuits such as SRAM cells. On-die ring oscillators show where each part really sits.

Read more on Skew Lots.

What is a guard band?

A guard band is the extra margin between the production test limit and the specification. A part tested at 3.15 GHz for a 3.0 GHz specification, for example, has a 5 % guard band.

It covers effects the tester does not reproduce: transistor aging over the product's life, supply droop under real workloads, tester accuracy, temperature differences and test coverage gaps. Too little causes field failures; too much rejects good parts.

Read more on Margins and Guard Bands.

How do you debug a failure that happens only occasionally?

1. Check it is the chip: try other boards, platforms and parts.
2. Make it reproducible: a cycle-reproducible mode, fixed clocks and memory timing, controlled voltage and temperature.
3. Shorten the test by bisection to find the window where the state first goes wrong.
4. Disable features one at a time to localize the block involved.
5. Use trace around the window and compare a scan dump with simulation to find the first difference.
6. Confirm the root cause in simulation or with a targeted test, then plan a workaround or fix.

Read more on Reproducing and Isolating a Failure.

How do you tell a logic bug from an electrical problem or a manufacturing defect?

Run the test on several parts and sweep voltage, frequency and temperature. A failure on every part at every condition points to a logic bug. A failure on every part only at some conditions points to an electrical problem. A failure on one part while others pass points to a defect in that part.

Before any of that, rule out the setup: boards, firmware, software and the test itself cause many early sightings.

Read more on Classifying Failures.

What is a speedpath, and how do you find it?

A speedpath is the timing path that fails first as the clock frequency rises. To find it, run a test at a failing frequency and lengthen one clock cycle at a time (clock stretching). If stretching a particular cycle makes the test pass, the failing path ends in that cycle.

A scan dump after that cycle, compared with simulation, shows which flops captured wrong values. The timing report and simulation of that cycle then narrow it to a few candidate paths.

Read more on Speedpaths.

What options exist for a bug found after tapeout?

• Workaround: a software, firmware or microcode change, or a chicken bit that disables the faulty feature.
• Erratum: document the bug, its conditions, implication and workaround for customers.
• Metal fix: rewire spare cells by changing only some metal masks, returning silicon in weeks.
• Full respin: change the transistor layers with a full mask set, taking months.

Most bugs ship with a workaround and an erratum; silicon fixes are grouped into the next stepping.

Read more on Workarounds and Metal Fix or Full Respin.

What is burn-in?

Burn-in runs parts at high temperature and voltage, typically around 125 to 140 °C and well above nominal supply, for a period before shipping. Weak parts with hidden defects fail early in life (infant mortality); burn-in makes them fail in the factory instead of in a customer's system.

It is expensive and stresses the design, since leakage is huge at those conditions, so teams try to shorten it with other screens such as voltage stress tests and outlier screening.

Read more on Burn-In and Early Failures.

Why are debug features a security risk, and how are they protected?

Debug features give deep visibility and control: JTAG can rewrite firmware or read memory, and scan chains can dump the internal state of a crypto engine to recover its key. In a production part, an attacker can use them the same way validation did.

Protection uses lifecycle states set by one-way fuses, so debug access is reduced as a part moves to production; challenge-response authentication so only trusted users can unlock debug; and resetting scan flops on entry to test mode.

Read more on Locking Debug.