CHIP DESIGN · COURSE

Computer Architecture & Microarchitecture

Follow one instruction from a software-visible contract to committed state, then scale the reasoning through encoding, datapaths, multicycle control, pipelines, hazards, caches, virtual memory, exceptions, I/O, performance, and parallel limits. The course treats every optimization as a timed ownership protocol: instruction identity, operand age, address, permission, request, response, and commit status remain traceable. Hand-checkable models establish meaning first; RTL, FPGA, operating-system, and silicon claims remain explicit later evidence tracks.

Before this course: Completed Digital Logic & Boolean Reasoning, including binary widths, combinational logic, registers, finite-state machines, synchronous timing, and verification traces. No assembly, HDL, operating-system, or electronics experience is assumed.

COURSE FACTSStage, chapters, units, prerequisite, and outcome
Chapter 1

An ISA is a software-visible contract

Objective: When can a normally internal detail become architecturally relevant? Answer by naming the contract owner, the earliest decisive event, and one piece of evidence that would refute the answer.

An instruction set architecture specifies machine-visible operations and state while permitting many internal implementations. Computer architecture connects a software-visible contract to timed state transitions in hardware. For every claim, name the architectural state that software may observe, the microarchitectural structure that implements it, the cycle or event at which ownership changes, and the trace that would expose a disagreement. A block diagram is only a map of possible paths; it does not prove that control selected the right path, that operands were current, that memory accepted a request, or that an exception preserved the required boundary.

The specification used here is: An ISA names instructions, encodings, registers, data widths, address rules, memory effects, control flow, privilege, exceptions, and required ordering visible to software. The invariant is: Two conforming processors may use different pipelines and caches yet must produce the same architecturally defined results for a legal single-threaded program under the same initial state. Begin with a small hand-checkable machine and follow one instruction or transaction through fetch, interpretation, operand selection, execution, memory, and commit as applicable. Keep latency separate from throughput, an address separate from stored data, an instruction-set rule separate from one implementation, and average measurements separate from worst-case bounds. The failure boundary “Treating a measured cycle count as an ISA guarantee confuses one microarchitecture and workload with architectural meaning.” remains visible because it identifies the first owner that can violate the contract.

Two conforming processors may use different pipelines and caches yet must produce the same architecturally defined results for a legal single-threaded program under the same initial state. This statement is an architectural or microarchitectural invariant only within the named assumptions; it is not a claim about every processor, compiler, operating system, cache, or physical memory system.

The program can observe only state and events exposed by the ISA contract. At derivation step 1, preserve instruction identity, operand age, address, privilege, and exception status as applicable. The next step is allowed only after the current owner produces the named valid signal or state record.

Pipeline depth and cache organization are implementation choices unless made visible by an explicit rule or timing interface. At derivation step 2, preserve instruction identity, operand age, address, privilege, and exception status as applicable. The next step is allowed only after the current owner produces the named valid signal or state record.

Therefore conformance compares committed architectural behavior, not identical internal cycles. At derivation step 3, preserve instruction identity, operand age, address, privilege, and exception status as applicable. The next step is allowed only after the current owner produces the named valid signal or state record.

Classify program counter, integer registers, cache tags, pipeline valid bits, and branch-predictor history as architectural or microarchitectural for a simple ISA. Draw a cycle or event table before calculating performance. Each row must name the active instruction or transaction, the state read, the state proposed, and whether the proposal is architecturally committed.

  1. The program counter and named integer registers are directly defined by instruction behavior. For trace step 1, check that widths, addresses, dependencies, and valid/ready conditions agree with the contract. Mark observations from the teaching model separately from evidence that would require an RTL simulator, FPGA, operating system, or fabricated processor.
  2. Cache tags and pipeline valid bits implement delivery but are not named program state. For trace step 2, check that widths, addresses, dependencies, and valid/ready conditions agree with the contract. Mark observations from the teaching model separately from evidence that would require an RTL simulator, FPGA, operating system, or fabricated processor.
  3. Predictor history changes timing and speculation, but a correct implementation prevents it from changing committed meaning. For trace step 3, check that widths, addresses, dependencies, and valid/ready conditions agree with the contract. Mark observations from the teaching model separately from evidence that would require an RTL simulator, FPGA, operating system, or fabricated processor.

Result: PC and integer registers are architectural; cache, pipeline, and predictor records are microarchitectural in this bounded ISA. The result includes the final value and the route by which it became visible. A correct number reached through an illegal encoding, stale operand, wrong privilege, imprecise exception, or unacknowledged memory response is still a failed design.