Kart Lap Credit

Karting Melle rents electric go-karts. Drivers load laps at the pit kiosk: one fob tap adds 1 lap to the kart's balance. A loop under the start line takes 1 lap back at each crossing. Last month some teenagers found a trick. Ride the balance down to 0, cross the line once more, and the dashboard shows 255 free laps.

The counter in every kart is rev A. The vendor now ships rev B and calls the problem fixed. They refuse to pay for the fleet recall unless a test proves rev A wrong and rev B right. Your rig has both revisions wired side by side, fed the same signals.

Your task: write the acceptance test. Drive rst_i, buy_i and ride_i through a short day at the track. After each step, call the given check_laps with the balance the spec demands. Your run passes when every expected balance matches rev B, and at least 1 check catches rev A misbehaving.

Interface (each revision)

Behavior (the spec both revisions claim to meet)

• At a rising edge with buy_i = 1 and ride_i = 0, the balance gains 1 lap. At 255 it stays 255
• At a rising edge with ride_i = 1 and buy_i = 0, the balance loses 1 lap. At 0 it stays 0
• When buy_i and ride_i are both 1 or both 0 at the edge, the balance does not change
• rst_i = 1 at a rising edge clears the balance to 0, whatever buy_i and ride_i carry
• laps_o is registered: a change shows the cycle after the edge that caused it

What the bench checks

• The grading bench (the read-only testbench tab) runs your bench inside it and replays every check_laps call against both revisions
• Every balance you expect must match rev B, at every check
• At least 1 check must catch rev A holding a balance different from your expected value
• At least 5 checks must run, and at least 1 sound check must expect a balance above 0
• No check may run before rst_i has been high through a rising edge
• The run ends when your bench sets tb_done; a stalled bench times out and fails

Constraints

TIMING: both revisions are synchronous to clk_i, and laps_o is registered: a change shows the cycle after its edge. Check 1 ns after the edge you want judged.

SCOPE: the deliverable is the acceptance test, not a fix; rev A and rev B stay as shipped. The fob kiosk, the start-line loop, and the karts are out of scope.

GIVENS: keep the given signal names, the two instances and the check_laps check helper exactly as they are. The grader finds them by name.

DO NOT MODIFY: either revision. The deliverable is the test, not the fix.

• Report mismatches only through check_laps. The grader owns the verdict, so never print the word FAIL yourself
• Drive inputs the way the given reset lines do, and call check_laps 1 ns after the edge you want judged

Do not add ports.