Write do_kill for a sequence that holds the run phase open by hand: release its objection and account for the work the kill cancelled.
Hardware context: Background traffic sequence that holds the run phase with its own objection. Release the objection of a killed sequence and account for its cancelled work.
A background traffic sequence keeps the run phase open with an objection it raises in pre_start and drops in post_start. When an error path kills it, post_start never runs. The objection stays raised, and the test hangs until the phase timeout.
Write bg_traffic, a subclass of the given bg_traffic_base, with a do_kill that releases the objection the sequence still holds and records what the kill did to its work.
cancelled is the number of items that never reached the driver. in_flight is 1 when the driver was holding one of this sequence's items at the moment of the kill: the driver still finishes that item. A sequence that is never killed must end exactly as before.
Full specification
class bg_traffic extends bg_traffic_base;
`uvm_object_utils(bg_traffic)
int unsigned cancelled; // items that never reached the driver
int unsigned in_flight; // the item the driver held when the kill came, if any
function new(string name = "bg_traffic"); super.new(name); endfunction
endclass
| Inherited member | Meaning |
|---|---|
| n_items | items the sequence would send |
| granted | items whose start_item has returned: the driver has taken them |
| finished | items whose finish_item has returned: the driver has completed them |
| obj_phase, raised | the phase holding this sequence's objection, and whether it is still raised |
Each case runs one sequence on its own sequencer and driver. The driver takes an item, works 10 ns, calls item_done and rests 5 ns. The bench kills the sequence at a set time, or never, and afterwards counts any objection the sequence still holds before releasing it.
Examples
Example 1
Killed while the driver holds an item- Input
6 items; kill() at 33 ns
- Output
items = 6, granted = 3, completed = 3, cancelled = 3, in_flight = 1, objection_left = 0, stopped = yes, finished = no
Items 0 and 1 are done at 10 and 25 ns; item 2 was taken at 30 ns. At 33 ns three items are granted and two finished: one in flight, three cancelled. The driver still completes item 2.
Example 2
Killed between items- Input
6 items; kill() at 27 ns
- Output
items = 6, granted = 2, completed = 2, cancelled = 4, in_flight = 0, objection_left = 0, stopped = yes, finished = no
At 27 ns the driver is resting after item 1, so nothing is in flight. Two items were granted and four are cancelled.
Example 3
Never killed- Input
4 items; no kill
- Output
items = 4, granted = 4, completed = 4, cancelled = 0, in_flight = 0, objection_left = 0, stopped = no, finished = yes
do_kill never runs. post_start drops the objection and the sequence ends in UVM_FINISHED with every item completed.
Constraints and contract
- Keep the class name and the two counters; the bench reads them.
- Drop the objection exactly once, and only if it is still raised.
- The kill itself and anything the sequencer does with locks are not your code.
Hints
Hint 1
Which of the sequence's hooks still run after kill()? Its own cleanup has to live in the one that does.
Hint 2
The two inherited counters already tell you where the sequence was: compare them with each other and with n_items.
Hint 3
The objection was raised with this sequence as its object. Drop it the same way, and remember the flag that says it is held.
What this judge verifies: Your sequence runs on six real sequencers and drivers and is killed by the bench at set times, or not at all. The checks count the objections it still holds afterwards, the items the driver completed, its final state and your two counters.
6 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