Tug of War Position Tracker

Verilog problems / Fun & Games

What you must build

Track the rope's position in a tug-of-war: each pull nudges a signed counter one way, and crossing a threshold declares a winner instantly.

Engineers use “Tug of War Position Tracker” 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  pull_a,
  input  pull_b,
  output reg signed [3:0] position,
  output reg [1:0] winner
);

  // Your code here — pull_a (only) moves position -1, pull_b (only) moves it +1 (both/neither: no change).
  // Win threshold is +/-3. Check the NEW position (after this cycle's pull) against the threshold, not the old one.

Why this shows up in interviews

Tug of War Position Tracker sits under Fun & Games (sequential, counter, game-logic). Concept: The rope's position is a signed up/down counter — team A's pull decrements it, team B's pull increments it — and the win check must use the position after this cycle's pull is applied, not the stale value from before it: compute next_pos combinationally, register position<=next_pos , and check next_pos against the threshold in the same cycle. Checking the old, pre-pull position instead of next_pos is a subtle one-cycle-late bug — the win still gets detected eventually, just one full pull later than it actually happened, so a team can be declared the winner only after over-pulling past the real threshold.

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.
• Hot Potato Token Passer — 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.
• 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.

FAQ