Milestone map
Milestone map
3 milestones
Understand CPU Pipeline and Memory Hierarchy
8–14 weeks
Study the von Neumann architecture, CPU fetch-decode-execute pipeline, and memory hierarchy: registers, L1/L2/L3 cache, DRAM, and storage. Implement a simple CPU simulator in Python or C that executes a basic instruction set (at least fetch, decode, execute, and memory access stages). Complete the MIT OCW 6.004 or Berkeley CS61C problem sets on instruction sets and pipelining.
Proof required
Submit: a public GitHub repository containing your CPU simulator that executes at least five instruction types (e.g. ADD, LOAD, STORE, BRANCH, HALT); a test harness with at least three programs that run correctly on the simulator; and a written explanation (300 words) of the pipeline stages your simulator implements and why pipeline hazards exist. Submit to a CS lecturer or hardware engineer who confirms in writing that the simulator is functionally correct and the explanation demonstrates genuine understanding.
What gets checked
- Simulator is publicly available and executes at least five instruction types with a test harness
- Written explanation addresses pipeline hazards specifically — not just a description of pipeline stages
- A CS lecturer or hardware engineer has confirmed the simulator is correct and the explanation shows genuine understanding
Common mistakes
- Building a simulator that 'works' on toy inputs without a test harness — a simulator must be verified against known-correct outputs
- Explanation that describes the pipeline without addressing data hazards, control hazards, or structural hazards
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Run the simulator against the submitted test harness — does it produce correct outputs?
- Ask: 'what is a data hazard and how would your pipeline handle one?' — tests deeper understanding beyond the simulator
- Ask: 'why does cache miss latency matter for algorithm design?' — tests the connection between architecture and software
Study and Implement Cache Behaviour and Virtual Memory
8–12 weeks (after milestone 1)
Study cache replacement policies (LRU, LFU, random), write-back vs write-through, and set-associativity. Study virtual memory: page tables, TLB, page replacement algorithms (FIFO, LRU, clock). Implement a cache simulator and a page table simulator, and verify them against known-correct outputs. Complete an experiment measuring real cache miss rates in your language of choice.
Proof required
Submit: a public GitHub repository containing a cache simulator (configurable associativity and replacement policy) with a test harness; a page table simulator with at least TLB simulation; and a cache experiment report (200 words) showing measured cache miss rates for at least two access patterns (sequential vs. random) in your language of choice, with an explanation of why they differ.
What gets checked
- Cache simulator supports configurable associativity and at least two replacement policies
- Cache experiment shows real measured miss rates from code you ran — not theoretical estimates
- Explanation of why sequential access has lower miss rates than random access uses cache line and spatial locality concepts specifically
Common mistakes
- Implementing simulators without verifying them against known-correct trace outputs — a simulator that 'looks right' may be wrong
- Cache experiment that measures something other than miss rates — timing alone does not prove cache behaviour
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Run the cache simulator against known traces — does it produce correct miss rate outputs?
- Ask: 'why does increasing cache associativity improve miss rates but at a cost?' — tests understanding of the tradeoff
- Does the experiment report show measured data from code that was actually run?
Present Architecture Knowledge in a Design Review
4–6 weeks (after milestone 2)
Write a technical report (1,000 words) analysing the architectural design tradeoffs in a real processor family (e.g. ARM vs x86, RISC-V vs x86, or Apple M-series vs Intel). Present the report to a hardware engineer, CS lecturer, or systems programmer who challenges the analysis with specific questions.
Proof required
Submit: the technical report (at least 1,000 words) with citations to primary sources (datasheets, official architecture manuals, or peer-reviewed papers); and a recording or transcript of a review session with a hardware engineer or CS lecturer where they challenged at least two claims in the report.
What gets checked
- Report cites primary sources — datasheets or architecture manuals, not Wikipedia summaries
- Report discusses specific numerical tradeoffs — clock speeds, cache sizes, transistor counts, or power envelopes — not general descriptors
- Review session includes at least two specific challenges to claims in the report
Common mistakes
- Report that relies on Wikipedia and review articles without citing primary architecture documentation
- Review session that is a conversation rather than a challenge — the reviewer must push back on specific claims
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Are the report citations primary sources — datasheets or architecture specifications?
- Does the report include specific numerical comparisons — not just qualitative statements?
- Were at least two specific claims in the report challenged in the review session?