Silicon gives you a few pins and whatever the designers chose to record. A coherence failure involves at least two caches and the home, and the evidence lives in all three. This topic is about the decisions made before tape-out: which messages are traced and with which fields, which counters exist, which hooks let you freeze, inspect and perturb a controller, and how those pieces turn a one-in-a-week failure into a test that fails every run. The triage method that uses them is in the sibling topic Silicon Bring-up Coherency Triage.
Lesson | After it you can... |
|---|---|
Choose the fields of a coherence trace record, size a trace buffer from message rate and record size, and justify per-address filtering. | |
Define a generic counter set, say what each counter answers, and derive metrics that separate coherence-bound from capacity-bound behaviour. | |
List the freeze, dump, step, force, disable and delay hooks a controller needs, with their costs and the security rule for debug access. | |
Turn a rare silicon failure into a repeatable, shrunk test by narrowing addresses and injecting legal delays. |
Suggested order: as listed. Each lesson uses the shared course model and links back to the transaction or race it observes instead of redrawing it. Prerequisites: Controller Resources for pending entries, and Finding False Sharing for the hit-modified event.
Counters can say that, for example, pending-entry occupancy reached its maximum or that retries climbed before the hang, which narrows the mechanism. They cannot say which line, which transaction or which message is missing, because they aggregate over all addresses and time. Without a trace or a dump of the pending entries you cannot name the stuck transaction, so the observability has to be designed in, not added after the failure.