All work
2025/ Digital design · Verilog/ EECE 320 · with Karen El Helayel

Digital Safe

A keypad-driven combination safe built the way real safes have to be built: wrong the first time is the wrong time to find out. The circuit is a keypad encoder feeding a 4-digit FSM feeding a seven-segment driver, with parameterized multi-press policies. The actual work was proving it correct: self-checking testbenches that exhaustively cover every single-key and dual-key press case.

Try the FSM

A live model of keypad_encoder.sv and safe_fsm.v, not a mockup

keypad_encoder → safe_fsm → seven-segment
·
·
·
·
LOCKED

Enter the 4-digit combination. It's the default in safe_fsm.v, on GitHub if you get stuck.

Dual-key policy (keypad_encoder.sv)

If keys 3 and 7 are pressed at once

code
·
valid
·

At a glance

Language
Verilog / SystemVerilog
Size
~570 lines, two-person team
Verification
78 exhaustive cases: 12 single-key, 66 dual-key
Course
EECE 320 Digital Systems Design

Keypad in, unlock decision out

Three stages, one gatekeeper

A keypad encoder resolves raw key lines into a clean digit event, even when two keys are physically pressed close together in time. That event drives a 4-digit FSM that tracks the entered sequence against the combination, and a seven-segment driver reports state back to the user. The multi-press behaviour, how the FSM should treat two keys registering near-simultaneously, is parameterized rather than hardcoded, so the same core logic can be configured for different real-world debounce and press policies without rewriting the FSM.

Why exhaustive, not sampled

The part that actually took the time

A safe that's wrong on some untested input isn't a minor bug, it's the entire product failing at its one job. So the testbenches don't sample the input space, they exhaust it: every one of the 12 possible single-key presses, and every one of the 66 possible dual-key combinations, each checked against the expected FSM response automatically. This is the same principle behind the "explain and defend" approach that shows up across the self-hosted work too, verification isn't a formality tacked onto the end, it's the deliverable.

Inside the repo

Structure

  • keypad_encoder.svraw key lines to digit events, parameterized dual-key policy
  • safe_fsm.v4-digit combination FSM
  • sevenseg_driver.svdisplay output
  • keypad_encoder_testbench.vencoder cases, self-checking
  • sevenseg_driver_testbench.svdisplay driver cases, self-checking
  • tb_safe_fsm.vall 78 single- and dual-key FSM cases, self-checking

Skills, in context

Where each one actually showed up

Verilog / RTL design Three-stage datapath: encoder, FSM, display driver, with parameterized behaviour rather than fixed logic.
FSM design 4-digit combination tracking with defined transitions for correct, incorrect, and multi-press input.
Exhaustive verification Self-checking testbenches covering all 12 single-key and 66 dual-key cases, not a sampled subset.
Collaboration Two-person build with Karen El Helayel, splitting datapath and verification work.
Next project Fourier-Based Signal & System Design