Digital Design in Verilog — Seowon Lucy Park

I built a complete multi-cycle LC-3 processor in Verilog: ALU, register file, memory interface, and the finite-state-machine controller that sequences them, covering the entire LC-3 instruction set across arithmetic, memory, and control flow.

Block diagram of the PUnC datapath: PC, memory, register file, ALU, sign extension, and the address and data muxes that connect them. — The datapath. Every mux select, load enable, and reset comes from the controller; nothing here decides on its own.

Block diagram of the controller: IR field extraction feeding next-state logic, a clocked state register, and output logic driving the datapath's control signals. — The controller itself: next-state logic reads the opcode and current state, the state register clocks it forward, and output logic turns each state into the datapath's control signals.

The debugging is the part worth reading. Simulation hung with no error message, which is the least informative failure a processor can give you. Waveform analysis in Vivado traced it to unassigned control-mux selects: certain controller states left mux inputs undriven, so the datapath stalled on undefined values rather than faulting. Fixing it meant making every control signal explicitly assigned in every state instead of relying on defaults. The final design passed all 19 tests with zero errors.

Vivado waveform showing the LC-3 simulation: clock, reset, program counter, register file, and memory signals traced across roughly 900 nanoseconds. — The Vivado waveform that found it. Once every control signal was traced cycle by cycle, the undriven mux select stood out from everything defined around it.

Also built this way: Simon, a two-player memory game in Verilog, on the same controller-and-datapath split. The FSM owns game flow (generate, play back, read input, judge, advance); the datapath owns sequence storage and comparison. Verified module by module before full-game simulation and FPGA deployment.