Q053FreeDesign Verification
How to Build an Out-of-Order UVM Scoreboard
Question
A DUT can return responses out of order and may reuse transaction IDs after reset. Which scoreboard design handles matching and reset most robustly? A response generation must be carried by the interface or established by a documented freshness guarantee; assigning the current local epoch to every arriving response is not such a guarantee.
Answer choices
- A. Compare expected and actual queues strictly by arrival position
- B. Disable the monitor during reset but retain all pre-reset expectations indefinitely
- C. Sort all responses by payload value before comparing
- D. Match associative entries by transaction ID and an unambiguously established generation, with explicit reset flush/cancel and safe ID-reuse policies
Short answer
Use identity-based matching keyed by transaction ID plus a reset generation, and define what reset does to outstanding expectations. This supports out-of-order completion while preventing a post-reset response from matching stale pre-reset state that happened to use the same ID.
Why this reasoning works
Arrival-order queues assume responses return in request order, which the DUT explicitly does not guarantee. Instead, the scoreboard should index expected results by protocol identity and retrieve the corresponding entry when an actual response arrives. If a key can have multiple simultaneous requests, its value can hold a queue or another unique sequence field.
Reset makes the ID alone insufficient because the same numeric value may describe traffic from two different lifetimes. Incrementing an epoch on reset separates those lifetimes. The scoreboard must also document whether reset flushes, cancels, or later permits outstanding operations, then report unmatched, duplicate, missing, and late responses according to that policy.
Interview takeaways
- Match by transaction identity
- Include a reset epoch
- Define reset disposition