A vendor checker catches every bug in its log, yet the UVM test still passes. Route each failure to the report server, under its own ID and with the unit's path.
Hardware context: Pulse units with a bound vendor protocol checker. Route the failures of a vendor checker to the report server with one ID per rule.
Five pulse units sit in one bench, and four of them carry a planted bug. A vendor checker for the unit's protocol is bound into every instance. Its three assertions fire exactly where the bugs are.
The regression still reports a pass. The checker's fail actions call $warning: the simulator prints a line, and the UVM report server, which decides the verdict, counts nothing.
Fix the checker so every failure becomes a UVM error that the regression can sort: one ID per rule, and the failing assertion's path as the report's context, so each error names its unit. Leave the three rules as they are.
Full specification
| Assertion | Report ID |
|---|---|
| a_latency | SVA_LATENCY |
| a_spurious | SVA_SPURIOUS |
| a_tag | SVA_TAG |
Report with the global uvm_report_error from uvm_pkg and pass $sformatf("%m") as the context argument; inside an action block that is the assertion's path, such as tb.u2.chk.a_spurious. The bench counts UVM errors per unit and ID and shows them as warnings so the run can finish. Simulator note: on this Verilator, $error in an action block stops the run at the first failure, so it is no way out here.
Examples
Example 1
The correct unit- Input
u0: the correct unit; four starts, three or four edges apart, with tags 5, 6, 9 and c
- Output
latency_errors = 0, spurious_errors = 0, tag_errors = 0, other_errors = 0, errors_without_a_unit = 0
Every start is answered two edges later with its own tag, so no assertion fails and u0 has no errors.
Example 2
A late answer- Input
u1: answers the second start one edge late; four starts, three or four edges apart, with tags 5, 6, 9 and c
- Output
latency_errors = 1, spurious_errors = 1, tag_errors = 1, other_errors = 0, errors_without_a_unit = 0
The second start is answered three edges after it instead of two. a_latency fails at the second edge; at the third, done has no start two edges before it and its tag, 6, is not the 0 sampled then, so a_spurious and a_tag fail once each.
Example 3
An extra done- Input
u2: raises an extra done with no start; four starts, three or four edges apart, with tags 5, 6, 9 and c
- Output
latency_errors = 0, spurious_errors = 1, tag_errors = 0, other_errors = 0, errors_without_a_unit = 0
A done with no start appears three edges after the last answer: one SVA_SPURIOUS error. Its tag is 0, like the tag sampled two edges earlier, so a_tag holds.
Constraints and contract
- Keep the interface, its ports, the three properties and the bind line.
- One UVM error per failing attempt, no errors for passes.
- Every error must carry its unit's path in its context.
Hints
Hint 1
Who decides whether a UVM test passed? Follow a $warning and see whether it ever reaches that place.
Hint 2
An interface is not a component and has no report methods of its own. uvm_pkg has global ones.
Hint 3
The same report call takes a context string as its last argument, and %m in an action block names the assertion that failed.
What this judge verifies: Your checker is bound into five real pulse units, four with a planted bug, and runs inside a UVM test. The checks count the UVM errors the report server received per unit and ID against an independent cycle model of the units and the three rules.
5 checks on UVM · local server. Run the examples first, then check the full regression. The suite is local and inspectable. A passing result establishes the tested cases, not a proof for all possible inputs.
See all 1 problem on this path