A burst driver works against a receiver that is always ready and loses beats against a busy one. Make each beat wait for the receiver, and finish the item only when its last beat is taken.
Hardware context: Burst link whose receiver is busy for several edges after each beat. Hold every beat of a burst until the receiver takes it.
A link carries bursts: each item holds one to four bytes, sent as beats, and the last beat is marked last. A beat transfers at a rising edge where valid and ready are both 1. After taking a beat, the receiver may be busy for a few edges with ready at 0.
The driver passes every test against the idle receiver. Against a busy one, the receiver takes fewer beats than were sent, and some sequences carry on while their last beat is still waiting.
Fix burst_driver so that every beat reaches the receiver, in order, with last on the final beat of each burst, and so that finish_item returns at the edge that took the last beat of its burst.
Full specification
ready changes only at rising edges, by a nonblocking assignment, so the value read just after an edge is the one the receiver used at it. The driver offers at falling edges. Between bursts the driver lowers valid. Each case is a separate link with its own receiver; the sequence sends its bursts back to back and records when each finish_item returns.
Examples
Example 1
An idle receiver- Input
bursts of 3, 1, 2 beats; the receiver is busy for 0 edges after each beat it takes
- Output
beats_sent = 6, beats_taken = 6, stream_matches = yes, bursts = 3, lasts_taken = 3, early_returns = 0
ready is always 1, so every beat transfers at the edge after its offer. Six beats and three last markers are taken, and each finish_item returns at its last beat.
Example 2
Busy one edge after each beat- Input
bursts of 2, 3 beats; the receiver is busy for 1 edge after each beat it takes
- Output
beats_sent = 5, beats_taken = 5, stream_matches = yes, bursts = 2, lasts_taken = 2, early_returns = 0
After each beat the receiver drops ready for one edge. The next beat must stay on the bus through it; the five beats still arrive in order.
Example 3
Busy two edges- Input
bursts of 4, 1, 1 beats; the receiver is busy for 2 edges after each beat it takes
- Output
beats_sent = 6, beats_taken = 6, stream_matches = yes, bursts = 3, lasts_taken = 3, early_returns = 0
Each beat waits two edges for the previous one. A driver that moved on every clock would offer most of these beats while ready was 0, and the receiver would never see them.
Constraints and contract
- Keep the class name and vif; the environment creates it through the factory.
- One item per burst; one beat per transfer; last only on the final beat.
- item_done marks the transfer of the last beat, not the offer.
Hints
Hint 1
An offer is not a transfer. What has to be true at the edge for a beat to count?
Hint 2
While the receiver is busy, the beat must stay on the bus. Which line moves on regardless?
Hint 3
Check ready again after every edge until it is 1, for every beat, not only the last one.
What this judge verifies: Your driver runs on four real links whose receivers are busy for 0 to 3 edges after each beat. The checks compare the beats each receiver took with the beats sent, count the last markers, and check when each finish_item returned.
4 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