Arcade Token Machine

Half the entries in the boardwalk arcade's complaint book point at the same cabinet: the token dispenser by the door. Its temporary controller, soldered together from forum schematics, ate one customer's chips and sold the next a token at half price. The operator wants a rebuilt controller before the summer crowd shows up.

The mechanics stay. The validator pulses one line when it swallows a 5-credit chip and another for a 10-credit chip, but never both in the same cycle.

The old board had two faults, and the contract below exists to rule them out. It kept counting chips during the dispense cycle itself. Its outputs depended directly on the validator signals, so electrical noise from the validator could briefly activate the coil that releases a token.

Your task: rebuild the controller. Keep a running credit total and sell 25-credit tokens. When the total lands on exactly 25, the token drops alone. When it lands on 30 (a 10-credit chip on top of 20), the token drops together with a 5-credit chip back as change, in the same cycle.

Interface

Behavior

• After reset the accumulated credit is 0 and both outputs are 0
• Each credit5_i pulse adds 5, each credit10_i pulse adds 10; at most one of the two is high in any cycle
• When the total reaches exactly 25, dispense_o pulses for one cycle with change_o = 0
• When the total reaches 30 (a 10-credit chip on top of 20), dispense_o and change_o pulse together for one cycle
• After dispensing, the machine returns to zero credit by itself; leftover credit is never carried over
• A chip inserted during the dispense cycle is ignored
• rst_i = 1 at a clock edge clears the accumulated credit

What the bench checks

• The testbench checks dispense_o and change_o after every chip and around every vend
• It reaches exactly 25 with five small chips and two mixed chip orders, checking that no earlier total vends
• Three 10-credit chips must pulse both outputs at 30, while every exact payment must pulse dispense_o alone
• Both outputs must clear after one cycle, and a chip offered during that pulse must be ignored
• A reset mid-count must clear accumulated credit without vending, then allow a fresh exact-payment sequence

Constraints

TIMING: everything is synchronous to clk_i, and both outputs depend only on registered state. No combinational path from the validator lines may reach either output.

SCOPE: this models the credit logic between validator and release coil. The coin mechanics, the validator's pulse shaping, and the coil electronics are out of scope.

FSM TYPE: Moore: dispense_o and change_o depend only on the current state, and each is high for exactly one cycle per token.

Cover every state explicitly in the next-state logic.

Do not add ports.