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_data stage one operand into the register file; start/op_sel begin a computation; done/result are the outputs. done pulses the cycle write-back is requested — the register file's actual write lands one clock edge later, not the instant done appears. The live result output is only trustworthy while done is asserted; after the write-completing edge, read the stored register value instead.
  • Protocol: load each operand (load_en pulses once per operand) → pulse start with op_sel set → wait for done (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.