A scoreboard that compares every response it sees can still pass a broken design. If a request is never answered, there is nothing to compare. The test ends, the queues are not empty, and nobody looks. End-of-test accounting closes that hole.
Three faults need three different reports:
Fault | What you see | Report |
|---|---|---|
Leak | One request never answered; the DUT keeps working | The ID or tag, when it was issued, and how long the DUT ran past it |
Hang (stuck stream) | No responses at all for a long time while work is outstanding | Time since last progress and the IDs waiting |
Drop with in-order IDs | A later response on the same ID mismatches | Data mismatch on that ID (the previous lessons) |
The third row is why this lesson uses unique tags. With a pool of tags, each tag has at most one request outstanding, so a dropped request shows up as a missing response instead of shifting every later comparison on that ID.
Issue time per outstanding item, in a queue shaped like the expected queue.
Last progress time: the cycle of the most recent response of any kind.
A watchdog that warns once when an item passes the maximum latency. It finds the leak at the time it happens, not 10,000 cycles later.
A bounded drain: after stimulus stops, wait until nothing is outstanding or a limit passes. Never wait forever.
The drivers must not hang either. A driver that waits forever for a free tag turns a DUT leak into a simulator timeout with no message. The driver in the bench lesson gives up after 100 cycles and says so.
At the end of the drain, classify every item still outstanding:
If the DUT kept answering other requests for more than the maximum latency after this item was issued (last_progress - issued_at > max_lat), the item was leaked. The DUT was alive and skipped it.
Otherwise the item is stuck behind a hang. If nothing has come back for longer than the stall limit, the stream is stuck.
Measuring against last_progress, not against the current time, is the whole trick. Every item looks old once the stream hangs; only the leaked one was old while the DUT was still working.
max_lat comes from the spec or the design's worst case under the test's traffic, plus margin. Here the worst case is about 16 cycles (9 cycles of latency plus seven tags ahead), so 40 is safe.
stall_limit is longer than any legal quiet period: refresh, power state exits, back-pressure the test applies on purpose.
Scale both with configuration. A fixed number tuned on one config gives false leaks on a slower one.
The bench in the next lesson plants two faults in one engine. Reading them on a timeline shows why the report needs both rules.
Cycle | Event | What the accounting records |
|---|---|---|
23 | The third request on tag 5 is accepted and never answered | Issue time 23 joins the outstanding list for tag 5 |
63 | Tag 5 has waited 40 cycles, the maximum latency | The watchdog warns once, long before the end |
About 100 | The engine stops sending any response | Last progress is about cycle 100; every other tag still outstanding is now only waiting |
End of drain | The drain limit passes with items left | Tag 5 was outlived by more than 40 cycles of progress: leaked. The others are stuck behind the hang, and the stream has been quiet for 301 cycles |