High Performance Computer Architecture

Course projects, experiments, and notes for ECE 5320 / CS 5610 — HPCA Spring 2026.

The focus of the course is learning to measure processor performance, analyze the architectural causes behind observed behavior, and evaluate design tradeoffs using simulation and quantitative methods.

Course goals

The course emphasizes a quantitative understanding of processor performance and modern architectural techniques. Topics include pipelining, high-performance memory systems, instruction-level parallelism, out-of-order and speculative execution, multithreading and multicore design, data-parallel/GPU architectures, and warehouse-scale computing.

What the projects are teaching

• Use quantitative metrics correctly. Measure performance (execution time, CPI, speedup) and make valid comparisons.
• Connect results to architectural causes. Interpret simulator outputs and attribute outcomes to instruction mix, memory behavior, control flow, and microarchitectural constraints.
• Control variables and perform sound experiments. Vary one design element at a time for clear, defensible conclusions.
• Evaluate design tradeoffs. Understand how pipelining, caches, ILP, speculation, and parallel execution improve performance—and what costs they impose.
• Communicate performance findings. Present results with tables/plots and concise interpretation.

Simulation environment

The course uses gem5 (v24.0) as the primary simulation platform. Systems are configured via Python scripts and executed with precompiled workload binaries. gem5's modular SimObject design allows components (CPUs, caches, memory controllers, buses) to be assembled in Python like LEGO bricks.

Repository structure

hpca/
├── project1/
│   ├── part1/          # ISA comparison (x86 vs RISC-V)
│   └── part2/          # L1 cache design space exploration
├── project2/
│   ├── part1/          # Branch prediction analysis
│   └── part2/          # Out-of-order execution analysis
├── test-progs/         # Compiled workload binaries (daxpy, mat_mul, queens)
└── common/             # Shared gem5 configuration modules

Workloads

All projects use three benchmark programs compiled for both x86 and RISC-V:

Workload	Description	Characteristic
daxpy	Double-precision Y = a*X + Y vector op	Memory-bandwidth bound
mat_mul	Matrix A × B → C multiplication	Compute and memory intensive
queens	8-queens solver on a 20×20 board	Control-flow heavy

---

Project 1 — Simulation-driven performance analysis

Part 1: Intro to ISA using gem5 (hpca/project1/part1/)

Simulate three workloads on two ISAs — x86 and RISC-V — using TimingSimpleCPU with no cache hierarchy (CPU ports connect directly to the memory bus). The goal is to verify the performance identity t = instructions × CPI × t_clk, compare CPI across ISAs, compute ISA-level speedup per workload, and produce bar plots.

Key files: simple_x86.py, simple_riscv.py

Run format:

gem5-{ISA} --outdir="{ISA}_{prog}" ~/hpca/project1/part1/simple_{ISA}.py --prog="{prog}"
# ISAs: x86, riscv    progs: daxpy, mat_mul, queens

Part 2: Cache memory subsystem (hpca/project1/part2/)

Add a two-level cache hierarchy — split L1 instruction/data caches plus a unified 256 KiB 8-way L2 — and perform a design-space sweep over L1 data cache size (1, 2, 4, 8 KB) and associativity (1, 4, 8-way). Collect CPI, execution time, and L1D miss rate for mat_mul. Determine the optimal configuration and then test it against daxpy and queens.

Key files: cache_riscv.py, caches.py, analyze.py, analyze_workload.py

Run format:

gem5-riscv --outdir=$HOME/hpca/project1/part2/l1d_{size}_assoc{n} \
  $HOME/hpca/project1/part2/cache_riscv.py \
  --l1d_size={size} --l1d_assoc={n} --prog=mat_mul

---

Project 2 — Advanced microarchitecture

Part 1: Branch prediction (hpca/project2/part1/)

Explore LocalBP and TournamentBP using the same L1/L2 cache system from Project 1 Part 2. Sweep predictor type, table size (16–8192 entries), and counter bits (2 or 4).

Two case studies:

• Case Study 1 — branch predictor sensitivity analysis for mat_mul (12 runs max): predictor type, table size, counter bits, and a type × table-size interaction.
• Case Study 2 — system trade-offs across all three workloads (9 runs): budget / high-end / balanced configurations evaluated on area efficiency (MIPS per 1,000 bits) and bottleneck diagnosis.

Key files: branch_pred.py, run_experiment.sh, analyze_results.py

Run format:

./run_experiment.sh <bp_type> <bp_size> <bp_bits> <workload>
# Example: ./run_experiment.sh tournament 1024 2 mat_mul

Parameter space:

Parameter	Label	Values
Predictor type	bp_type	local, tournament
Table size	bp_size	16, 32, 64, 128, 256, 1024, 2048, 4096, 8192
Counter bits	bp_bits	2, 4
Workload	workload	daxpy, mat_mul, queens

Part 2: Out-of-order execution (hpca/project2/part2/)

Replace TimingSimpleCPU with RiscvO3CPU (4-wide superscalar out-of-order) and sweep three microarchitectural parameters: ROB size (32, 64, 256 entries), instruction queue size (16, 64, 128 entries), and physical register count (64, 128, 256). Fixed baseline: L1D 8 KiB 4-way, L2 256 KiB 8-way, tournament BP (size 1024, 2-bit counters), mat_mul workload.

Case studies cover the full 27-configuration design space, IPC/CPI trends, identification of ROB- vs IQ-limited operating regimes, and cost analysis (hardware state bits vs. performance).

Key files: out_of_order.py, sweep_configs.py, run_experiment.sh, analyze_results.py

---

Performance evaluation is most valuable when experiments are controlled and conclusions are supported by data.