Reading the Tiny Calculator Engine Spec
A concept-level guide to turning the capstone spec document into a short requirements checklist.
Updated 2026-07-27
A spec document is easiest to use once it becomes a checklist: which modules must exist, which operations must work, and what evidence counts as "done."
The Tiny Calculator Engine's spec states each of these plainly:
- Required modules:
alu_4bit,reg_file_4x4,control_fsm,tiny_calc_top— no more, no fewer. - Required operations: ADD, SUB, AND, OR. XOR and the flag outputs (zero, sign, carry/overflow) are optional stretch work.
- Interface: seven functional signals plus clock and reset.
load_en/load_addr/load_datastage one operand into the register file;start/op_selbegin a computation;done/resultare the outputs.donepulses the cycle write-back is requested — the register file's actual write lands one clock edge later, not the instantdoneappears. The liveresultoutput is only trustworthy whiledoneis asserted; after the write-completing edge, read the stored register value instead. - Protocol: load each operand (
load_enpulses once per operand) → pulsestartwithop_selset → wait fordone(write-back requested) → one more clock edge → the result is now stored in the register file. - Required evidence: passing simulation, waveform evidence, a design explanation, a verification explanation, a synthesis-awareness note, and one documented bug-and-fix.
Reading a spec closely before opening an editor pays off later: every blank you fill in Lessons 7.3 through 7.5 traces back to one of these four required modules, and every field you fill in Lesson 7.8's submission traces back to one of these six required evidence types.