Bug Zoo BUG_9 loses a credit whenever a send and a credit return happen in the same cycle. Under heavy traffic that happens constantly; an output that started with 4 credits soon has 1. Yet every packet still arrives intact, in order, at the right output. The credit count lives inside DCRouter and no pin shows it. The only outside symptom is that the output gets slower, and a functional scoreboard does not measure speed.
How directly can the testbench see the state where a bug lives?
The obvious answer is to check the outputs: every bug that matters must eventually show up there. Eventually is the problem. Some wrong state takes thousands of cycles to affect an output; some only affects performance; some affects an output only in a later, different test. A check at the outputs can be correct and still blind to state that has not yet surfaced.
Observability is the ease of seeing a state from the outputs: whether a wrong value appears at all, how soon, and how clearly it points back to its cause.
Internal state | How it reaches the outside | Observability |
|---|---|---|
Flit data and order | out_data on every send | High: wrong data is visible the cycle it leaves |
Error decisions | out_err on the tail | High |
FIFO occupancy | in_rdy goes low only when full | Partial: only the full boundary is visible |
Output locks | STATUS bits, when software reads them | Low: only if a test reads at the right time |
Credit counts | Indirectly, as fewer sends | Very low: no functional failure, only lost throughput |
Round-robin pointers | Which input wins, over many packets | Low: needs a fairness measurement |
Error and packet counters | Register reads | Medium: visible when read, but a wrong count can sit unread |
Audits: drive a state where the hidden value must show. Lesson 4.8's credit audit stalls a sink and counts flits: exactly 4 must leave, so lost credits become a functional failure.
Read-back at the end: compare every counter with what the testbench saw (PKT_CNT against packets received).
Measurements: fairness and throughput monitors make performance state visible (Part 5).
Internal checks: assertions bound to internal signals see the value the moment it goes wrong (lesson 3.4).
Design features: ask for status bits or debug counters for important hidden state (lesson 3.6).
Practice | Purpose |
|---|---|
End-of-test checks of all counters and status | Wrong values that never reached a data pin are still caught |
Assertions inside the design | Catch the wrong value at its source, with a precise failure point |
Performance monitors in the testbench | Turn hidden throughput loss into a measured number |
In lesson 4.8, the same DCRouter traffic without the final credit audit would pass with BUG_9 present: every packet arrives intact. Only the audit, which turns the hidden credit count into a count of flits, catches it. Observability was added by the test, not provided by the design.
Losing credits only makes DCRouter send less often; every packet still arrives intact and in order, so no flit is wrong.
With the sink stalled, the number of flits that leave equals the credits the output holds; any number other than 4 is a visible failure.
A bug is found only if a wrong value reaches a check.
Data paths are observable; counters, credits, pointers and performance state often are not.
Add observability with audits, read-backs, internal assertions and design features.