Skip to article

Course Companion

Reading the Tiny Calculator Engine Spec

A concept-level guide to turning the capstone spec document into a short requirements checklist.

3 min read · Updated


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 — these four are what the spec requires. Your own hierarchy can add a wrapper around them without breaking the requirement: Lesson 7.3's tiny_calc_datapath groups the ALU and register file, and still counts as meeting all four.
  • Required operations: ADD, SUB, AND, OR. The flag outputs (zero, sign, carry/overflow) are optional stretch work. A fifth operation such as XOR is not: the two-bit op_sel already uses all four of its codes, so adding one means widening op_sel and changing the interface. Interface width limits what a design can grow into.
  • Registers: the first operand goes in r1 and the second in r2. Every computation stores r1 op r2 in r3, so SUB stores r1 − r2. Values are 4 bits, so a sum that overflows, or a difference below 0, keeps only its low 4 bits.
  • 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.
  • Operation codes: op_sel uses 00 for ADD, 01 for SUB, 10 for AND and 11 for OR. These differ from the Lesson 2.13 and 5.7 ALU, where 01 meant AND. op_sel is read in the cycle start is pulsed; later changes are ignored.
  • done and result: done pulses the cycle write-back is requested. The register file writes only at a rising clock edge, so the stored value changes one clock edge later, not the instant done appears. The spec guarantees the live result only while done is 1; at the write-completing edge the engine stores that value in r3 internally, and the supplied checker verifies it directly — tiny_calc_top exposes no register-read port for a caller to use.
  • 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 r3. Keep load_en at 0 from start until then: a load in that window takes over the register file's write port, and the result is never stored.
  • 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.