Practice

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, buy and ride 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)

PortDirectionTypeDescription
clkin1 bitClock
rstin1 bitSynchronous reset (active high)
buyin1 bitKiosk tap: adds 1 lap at the edge
ridein1 bitStart-line crossing: takes 1 lap back
lapsout8-bit vectorRemaining lap balance (registered)

Behavior (the spec both revisions claim to meet)

  • At a rising edge with buy = 1 and ride = 0, the balance gains 1 lap. At 255 it stays 255
  • At a rising edge with ride = 1 and buy = 0, the balance loses 1 lap. At 0 it stays 0
  • When buy and ride are both 1 or both 0 at the edge, the balance does not change
  • rst = 1 at a rising edge clears the balance to 0, whatever buy and ride carry
  • laps 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 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, and laps 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.

Loading editor...

Click Run to execute your code. Output will appear here.