Wenn das Post-Silicon-Debug-Team im getesteten Chip einen Fehler entdeckt, so ist dieser zunächst sehr abstrakt und mit vielen Unbekannten behaftet. Zunächst bemerkt man nur, dass der Chip nicht reagiert, Pakete verliert, falschen Output liefert oder ähnliches. Um der Ursache des Verhaltens auf die Spur zu kommen, muss man wissen, was im Chip passiert.

Viele Chips werden deshalb heute mit Trace-Funktionen ausgestattet. Sie können beim Auftreten bestimmter Ereignisse angehalten werden und interne Logikanalysatoren ermöglichen die Ausgabe bestimmter Signalgruppen an externe Anschlüsse. Die Zustände ausgewählter Signale in einem Zeitraum von n Zyklen vor dem Anhalten lassen sich in einem internen Speicher ablegen, und überdies können die Zustände von Flipflops über Scan-Ketten herausgetaktet werden. Das Post-Silicon-Debug-Team kann sich also darüber informieren, was in den Zyklen unmittelbar vor (und evtl. auch kurz nach) dem Auftreten eines Problems abgelaufen ist.

Die aufgezeichneten Trace-Informationen geben klar Auskunft darüber, dass ein unzulässiges Verhalten aufgetreten ist und was in den letzten n Zyklen vor dem Problem abgelaufen ist. Wie es zu diesem Zustand kam, bleibt jedoch im Dunkeln. Hinzu kommt, dass immer nur eine begrenzte Anzahl Signale beobachtet werden kann und dass die Auswahl der richtigen Signale nicht gerade einfach ist.

Üblicherweise bedient man sich der gesteuerten Zufallssimulation, um den Bug einzukreisen. Wo der Fehler ursprünglich auftritt, ist nicht bekannt. Was man weiß, ist, dass er ein fehlerhaftes Verhalten in Block D zur Folge hat. Der Fehler tritt den Beobachtungen zufolge nach 3- bis 4-stündiger Laufzeit im Labor auf, wenn eine bestimmte Art von Traffic injiziert wird (z.B. nur bei Lese-Transaktionen auf Bus X).

Diesem Fehler per Simulation auf die Spur zu kommen, wird meist unmöglich sein. Wenn es im realen Betrieb schon Stunden dauert, bis der Bug auftritt, wieviel mehr Zeit müsste man mit der 1000-mal langsameren Simulation veranschlagen?