Skills

Understand Computer Architecture by Building Below the Language

10 weeks · 0 milestones

Build a working assembler, simple CPU emulator, or cache simulator from scratch — the artifact must demonstrate that you understand what happens below the programming language you normally use: instruction encoding, pipeline stages, cache line behaviour, or memory hierarchy trade-offs. The implementation must be accompanied by a written explanation of every design decision in terms of the specific hardware constraint it addresses. Proof: the working implementation and write-up reviewed by a CS lecturer or systems engineer who traces the execution of a program they haven't shown you through your implementation and asks you to explain every step.

Part of: Computer Science & Data · Proves for: Engineers, UG

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

You'll sign in first, then come straight back here.

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?

You'll sign in first, then come straight back here.

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?

You'll sign in first, then come straight back here.

Part of

Computer Science Fundamentals →

Related outcomes

All outcomes

Skills

Understand Computer Architecture by Building Below the Language

10 weeks · 0 milestones

Part of: Computer Science & Data · Proves for: Engineers, UG

Milestone map

3 milestones

Understand CPU Pipeline and Memory Hierarchy

8–14 weeks

Proof required

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

You'll sign in first, then come straight back here.

Study and Implement Cache Behaviour and Virtual Memory

8–12 weeks (after milestone 1)

Proof required

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?

You'll sign in first, then come straight back here.

Present Architecture Knowledge in a Design Review

4–6 weeks (after milestone 2)

Proof required

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?

You'll sign in first, then come straight back here.

Part of

Computer Science Fundamentals →