Page 374 - A Practical Guide from Design Planning to Manufacturing

344 Chapter Eleven

flaw producing a bug requires special equipment and methodologies. Silicon
debug is the specific task of identifying the cause of silicon bugs and deter-
mining how they can be fixed. This is discussed in the next section.
After silicon debug has identified a fix, it must be determined how each
silicon bug was missed by pre-silicon validation. This is not for the pur-
pose of assigning blame, but because if a flaw in the pre-silicon tools or
methodology allowed one bug to escape into silicon, it is extremely likely
that there are other bugs in silicon that were missed for the same reason.
Ideally, the pre-silicon tools will be fixed and rerun on the design to look
for more bugs that may have not yet been found in silicon. Just as impor-
tant, continually improving overall pre-silicon validation will reduce the
number of silicon bugs on future projects. As processor designs continue
to grow in complexity, validation before and after first silicon will remain
a critical part of the design flow.

Silicon Debug
Once post-silicon validation has detected a reproducible bug, even as work-
arounds are investigated, silicon debug begins at once. The silicon debug
team must discover not only the cause of the bug, but also a way to fix the
problem. This task can feel like a frantic search for a needle in a haystack.
It may be that a single transistor out of 100 million is connected or sized
incorrectly. This one design flaw may be all that is preventing the product
from shipping.
The primary tools of the silicon debug team are specialized machines
designed specifically to test integrated circuits. These testers are called
automatic test equipment (ATE) and can cost more than a million
8
dollars each. The same type of testers will be used to find manufacturing
defects during silicon test. Unlike a validation platform, which operates
in much the same way as the end-user system, ATEs are stored-response
testers. For each test, the ATE stores a cycle-by-cycle pattern of what
values should be driven on each of the processor input pins and what
values are expected on each of the output pins. The ATE does not respond
to the processor as a real system would. If an output pin is driven dif-
ferently than expected, the ATE does not react in any way other than
to record the mismatch. A test of even a few seconds may require load-
ing a pattern of billions of cycles, so ATEs are not practical for running
large numbers of very long tests. As a result, most post-silicon validation
cycles will be run on validation platforms rather than testers. However,
ATEs have several significant advantages compared to a standard
platform.

8
Nelson, “Affordable ATE: From Lab to Fab.”