A chip hangs in the lab once a day under a customer's workload. In simulation, the team would open a waveform and trace backwards. In silicon, they have a few status registers, a debugger that cannot reach the hung interconnect, and nothing else. A week later they find the cause by guessing. The next chip has a small trace buffer on every major interface, and the same class of hang is diagnosed in an afternoon.
What must an interconnect expose so that it can be debugged and tuned after it is built?
The obvious answer is that simulation and emulation catch the bugs, so silicon needs little debug logic. But silicon runs real software for billions of cycles, with real timing and real traffic, and some bugs only appear there. Performance problems also only become visible with real workloads. Without visibility, every silicon issue becomes a guessing game, and the cost of the missing logic is paid in weeks.
Layer | Shows | Cost |
|---|---|---|
Status and error registers | Current state: outstanding counts, credit levels, FSM states, sticky error bits with the failing address and ID | Very low |
Performance counters | Events over time: transfers, stall cycles, retries, credit-starved cycles, latency histograms | Low |
Transaction trace | A recent history of transactions with timestamps, in a circular buffer or streamed off chip | Medium: buffer area or trace bandwidth |
Triggers and cross-triggers | Stop or start tracing when a condition occurs (an error, a timeout), across blocks | Low |
External protocol analysers | Full capture of an off-chip link in the lab | Lab equipment |
A separate debug access path: if reading debug state needs the hung interconnect, it is useless when you need it most.
Sticky error capture: record the first error's address, ID, type and time, not just a flag.
Timestamps from a common clock: traces from different blocks must line up.
Trigger on the interesting moment: a timeout or error freezes the trace so the buffer holds the cycles before the failure.
Budget it: a few percent of area for counters and modest trace buffers on critical interfaces is normal; choose where the risk is.
System | Visibility |
|---|---|
Arm CoreSight | Execution trace (ETM), software and hardware trace messages (STM) and cross-triggering (CTI) across blocks (fact A29) |
PCI Express | Advanced Error Reporting logs error types and headers of failing packets; LTSSM state is readable for link debug (facts P30, P32) |
Off-chip links | Protocol analysers capture and decode traffic in the lab |
The opening hang (illustrative) was diagnosed on the next chip in an afternoon: a timeout trigger froze the interconnect's trace buffer, which showed a write response returned with an ID no request had used, after which the requester waited for ever. The fault was in a bridge's ID remapping table. On the first chip, without the trace, nothing pointed at the bridge.
It records which transaction failed (address, ID, type), which points at the cause; a flag only says something went wrong.
A circular buffer keeps overwriting; freezing it at the failure preserves the cycles that led up to it.
Silicon has no waveform viewer: debug visibility must be designed in.
Layer it: status and sticky errors, counters, timestamped trace, triggers, with a debug path that works when hung.
Budget it where the risk is, and review it with the architecture.