FPGA game logic

Flip That Digit

The game only works if the software models the physical board: switch mapping, contact bounce, release timing, and display limits.

Flip That Digit is a constrained FPGA game on the Basys3 board. A target digit appears on the seven-segment display, the player flips the matching switch, and the Assembly game loop updates score and target through memory-mapped I/O.

The technical challenge was reliability under hardware constraints. The board has real switches and buttons, a four-digit display, and an OTTER MCU wrapper, so the game had to be explicit about input validity and timing.

SystemVerilog + AssemblyBasys3 deploymentrelease-edge input handling

View source repo Resume context

This project appears under Projects on my resume.

Basys3 FPGA board used for Flip That Digit — Deployment target: Basys3 board with switches, LEDs, and seven-segment output.

System flow

Game loop

01target digit
02switch snapshot
03decode one bit
04wait release
05score update

State machine and display packing

The game models physical switch behavior.

The important work is timing: press, debounce, validate, update, and wait for release before another event can count.

WAIT
PRESS DETECTED
DEBOUNCE
VALIDATE SWITCH
UPDATE SCORE
WAIT FOR RELEASE

digit80b1111111

segment mask40b0110011

display outputtarget << 12 | scoreMMIO write

Mechanical switch bounceLimited seven-segment outputMemory-mapped I/OAssembly loop constraintsOTTER MCU integration

Project artifacts

Evidence you can see.

Real project media appears where available, with placeholder cards only where sanitized screenshots are still needed.

Basys3 board mapping for Flip That Digit switches — Switch-to-digit mapping used by the game contract.

High-level program flowchart for Flip That Digit — High-level game flow: read input, validate, update display.

Score update subroutine diagram — Score-update logic captured as a deployment artifact.

Project mark used alongside the FPGA implementation.

Technical deep dives

A press is not one clean event on real hardware.

Release timing as game correctness

The SystemVerilog debouncer synchronizes the input, waits for stable high and low periods, and emits a one-shot pulse after release. That prevents contact bounce and held buttons from registering as multiple actions.

The state machine separates low, low-to-high, high, high-to-low, and one-shot states.
Rise and fall debounce windows are expressed in clock cycles.
The pulse is generated after the input has returned low stably.

Source sectionDebouncer source

The software rejects ambiguous input before changing state.

Assembly owns the game contract

The Assembly loop reads switches from MMIO, masks to the low 16 bits, rejects zero or multiple bits, maps Basys3 switch positions to digits 0-9, and waits for release before continuing.

Exactly-one-bit validation uses the classic x & (x - 1) check.
Only SW15 through SW6 are accepted as game digits.
Wrong or invalid input never increments score.

Source sectionAssembly game loop ArtifactBoard mapping

Four seven-segment digits leave no room for vague UI state.

Display constraints force clear state

The target and score are packed into one display word, with the target in the leftmost digit and the score in the rightmost digit. The game communicates progress through tight numeric state rather than graphics.

The loop packs target << 12 with score & 0xF.
A win condition displays A00A and turns on all LEDs.
The target advances deterministically with modulo arithmetic for predictable testing.

ArtifactProgram flowchart ArtifactScore subroutine diagram

Animated artifact

A physical switch becomes one game event

The animated artifact cycles the seven-segment display and exposes the WAIT -> PRESS -> RELEASE -> UPDATE state path.

waitpressreleaseupdate

Code evidence

Short excerpts that show the design choices.

Snippets are trimmed for readability and paired with the source file they came from.

addi t1, t0, -1
and  t2, t0, t1
bne  t2, zero, DS_FAIL

addi t5, zero, 6
blt  t3, t5, DS_FAIL

The decoder only accepts one active switch and rejects out-of-range switches before the game compares against the target.

Source sectionOpen main.asm

ST_HIGH_TO_LOW: begin
  if (!btn_sync && cnt == FALL_CLKS - 1) begin
    ns = ST_ONE_SHOT;
    cnt_rst = 1'b1;
  end
end

The state machine waits for a stable release before emitting the one-shot event, which prevents accidental double triggers.

Source sectionOpen debouncer

Outcome and reflection

What this project proves.

Built a complete hardware/software game loop for Basys3 deployment.
Handled real input behavior through debounce, release waiting, and strict switch validation.
Learned that embedded interaction bugs often come from physical timing, not high-level game logic.

This project shows that I can reason across hardware and software boundaries. The important design move was treating the board as an imperfect physical interface and making the state machine absorb that reality.