Reason About CPU Microarchitecture and Simulator Design
Company: Google
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: hard
Interview Round: Technical Screen
# Reason About CPU Microarchitecture and Simulator Design
Answer the following systems questions for a modern out-of-order CPU. State architectural assumptions when behavior can vary by implementation.
### Part 1: Trace an Instruction
Given a short assembly sequence containing a conditional branch, a load, and a dependent arithmetic instruction, explain how it moves through fetch, prediction, decode, rename, scheduling, execution, completion, and retirement. Describe what happens on a branch misprediction and on a cache miss.
#### What This Part Should Cover
- Branch prediction and speculative fetch
- Register renaming and reorder-buffer state
- Dependency tracking and out-of-order issue
- Precise recovery and in-order retirement
### Part 2: Explain the Memory Hierarchy
Explain the roles and interactions of caches, MOESI coherence states, miss-status holding registers, virtually indexed physically tagged caches, the TLB, and a hardware page walk.
#### What This Part Should Cover
- Coherence permissions and dirty-data ownership
- Tracking several outstanding misses
- VIPT index and tag timing constraints
- Translation hits, misses, page walks, and resulting cache accesses
### Part 3: Design a Branch-Predictor Simulator Module
Design a C++ module for simulating a branch predictor. Define the interface, state, update timing, statistics, and tests. Explain how speculative updates are recovered if the chosen model includes them.
#### What This Part Should Cover
- Predict and update APIs with stable branch identity
- Separation of predictor policy from simulator plumbing
- Deterministic state and reproducible traces
- Accuracy, aliasing, warm-up, and rollback tests
### Part 4: Choose a Simulation Model
Compare cycle-based, event-based, cycle-accurate, and cycle-approximate simulation. Explain which model you would choose for correctness exploration, detailed performance work, and fast design-space search, and how you would optimize it.
#### What This Part Should Cover
- Fidelity versus speed trade-offs
- Event scheduling and idle-period skipping
- Modeling of contention and backpressure
- Profiling, batching, parallelism limits, and validation against a reference
### What a Strong Answer Covers
A strong answer connects each named structure to the instruction's progress, separates architectural correctness from timing fidelity, and designs simulator interfaces that are testable, deterministic, and explicit about approximation.
### Follow-up Questions
- How can a VIPT L1 cache avoid synonym problems?
- When is an Owned coherence state useful?
- Which predictor updates must be undone after a squash?
- How would you validate a fast approximate simulator?
Quick Answer: Trace instructions through a modern out-of-order CPU, explain memory-hierarchy mechanisms, and design a testable branch-predictor simulator module. Compare simulation models while examining speculation, cache misses, coherence, translation, recovery, timing fidelity, determinism, performance, and validation.