Hot Potato Token Passer

Verilog problems / Fun & Games

What you must build

Pass a token around a 4-player ring every cycle until a buzzer sounds — whoever's holding it when the music stops loses, and the game freezes there.

Engineers use “Hot Potato Token Passer” as a building block in fun & games. Interviewers ask for the same ports and the same corner cases this judge covers. Completing it in the browser is the same skill as writing synthesizable RTL at work, minus the EDA license.

Port contract

The judge instantiates exactly these ports. Extra ports or a different module name fail to elaborate.

How to approach this kata

This is a medium kata: you will need sequential logic or a small FSM. Decide what is registered versus combinational before you type. Reset polarity and clock edge must match the spec; the judge will fail you on the first mismatched cycle.

Hidden tests instantiate top_module, drive the ports, and compare every sample against a golden model. They do not grade coding style. They do grade X/Z, off-by-one counters, and ignoring enables. Sign in only when you want the run saved on the leaderboard — the specification below is public.

Starter shape

Copy this skeleton into the editor (or press Reset starter). Fill the body; do not rename the module.

module top_module(
  input  clk,
  input  rst,
  input  buzzer,
  output reg [1:0] token_pos,
  output reg game_over,
  output reg [1:0] loser
);

  // Your code here — token_pos advances 0,1,2,3,0... each cycle until buzzer fires;
  // at that moment latch loser=token_pos and set game_over, then freeze.

Why this shows up in interviews

Hot Potato Token Passer sits under Fun & Games (sequential, fsm, game-logic). Concept: The token position advances every cycle (0→1→2→3→0…) until buzzer fires; at that exact moment, whoever currently holds the token is the loser, and the game must freeze ( game_over ) without advancing the token further: if(buzzer) begin game_over<=1; loser<=token_pos; end else token_pos<=token_pos+1; . A subtle but very real party-game bug is advancing the token unconditionally every cycle and only afterward checking the buzzer — that records the loser as whoever is about to receive the token next, not whoever was actually holding it, quietly declaring the wrong player the loser.

A passing solution is synthesizable intent: no delays in the DUT, no initial blocks inside top_module, and no reference to testbench tasks. Use blocking assignments only in combinational always blocks; use non-blocking for registers clocked by clk.

Related problems

• Rock Paper Scissors Lizard Spock — Judge a round of the 5-way expanded rock-paper-scissors from The Big Bang Theory — each move beats exactly two of the other four, so the usual 3-way rule table isn't enough.
• Magic 8-Ball Fortune Teller — Give a "random-feeling" fortune-teller answer on every shake using a self-advancing 3-bit LFSR — a tiny, deterministic taste of pseudo-randomness in hardware.
• Reaction Game Scorer — Score a simple reflex game: a light comes on, the player presses a button, and the circuit measures how many cycles it took — flagging jumping the gun or dozing off.
• Space Invaders Collision Detector — Detect whether a bullet hits an alien: a classic range-overlap check dressed up as retro arcade collision logic.

FAQ