I built a framework to explore a high‑dimensional CPU microarchitecture design space using SimpleScalar as the evaluation engine. The system samples and evaluates processor pipeline and memory hierarchy configurations across 18 encoded parameters, using a fixed 5‑benchmark suite. The goal is to identify designs that balance performance, energy, and area using four composite objectives: ED2P, EDP, ED2AP, and EDAP. The framework includes:
- Configuration validator that enforces cross‑parameter constraints (cache inclusivity, block‑size relationships, associativity/latency linkages, queue sizes, etc.).
- Heuristic proposal engine that intelligently selects the next configurations to evaluate, replacing naive random sampling.
- Formalize a realistic microarchitectural design space and enforce validity constraints across pipeline, cache hierarchy, and memory system parameters.
- Build heuristic search strategies tailored to different optimization goals (performance, energy, area), with up to 1000 evaluations per objective.
- Analyze trends and tradeoffs in performance/energy/area, compare results to microarchitectural intuition, and document findings.
- 18 integer‑coded parameters passed to a shell wrapper that maps each dimension to SimpleScalar flags.
- Results are normalized to a fixed baseline configuration:
0,0,0,0,0,0,5,0,5,0,2,2,2,3,0,0,3,0. - Not every combination is legal; the validator rejects invalid settings before evaluation.
Configuration validation
- L1I and L1D share the same block size; L1I block size matches IFQ word size.
- L2 block size ≥ 2× L1 block size and ≤ 128B; L2 capacity is inclusive of L1I + L1D.
- Latency–size–associativity linkages:
- L1 size → latency: 8KB→1, 16KB→2, 32KB→3, 64KB→4; add +1 cycle (2‑way), +2 cycles (4‑way).
- L2 size → latency: 128KB→7, 256KB→8, 512KB→9, 1MB→10, 2MB→11; adjust by associativity: +1 (8‑way), +2 (16‑way), −1 (2‑way), −2 (DM).
- System constraints:
mplat = 3- fetch:speed ≤ 2
ifqsize ≤ 8words;decode:width = issue:width = fetch:ifqsizemem:width = 8B;memport ≤ 2;mem:lat = 51 + 7cycles (for 8‑word)tlb:lat = 30; TLB ≤ 512 entries, 4‑wayruu:size ≤ 128(power‑of‑two)lsq:size ≤ 32(power‑of‑two)
Heuristic proposal engine
- Objective‑specific exploration policies for ED2P, EDP, ED2AP, and EDAP.
- Prioritizes valid, promising regions; mixes greedy neighborhood moves with diversification to avoid local minima.
- Tracks visited sets and Pareto candidates to reduce redundancy and focus evaluations.
Performance
- Instruction count per benchmark is fixed; optimize IPC and cycle time.
- Cycle time varies with fetch width and scheduling style:
- Dynamic: width 1→115 ps, 2→125 ps, 4→150 ps, 8→175 ps
- Static: width 1→100 ps, 2→120 ps, 4→140 ps, 8→165 ps
Energy
- Core leakage scales with scheduling and fetch width.
- Cache/memory access energy and leakage/refresh scale with capacity (instruction fetches included).
- Energy per committed instruction depends on scheduling and width.
Area
- Static base:
(fetch_width^2)/2sq‑mm - Dynamic base:
4 + (fetch_width^2)/3sq‑mm - Cache:
1 sq‑mm / 32KB - LSQ:
(size/2)^2 × 1/128sq‑mm - RUU:
(size/4)^2 × 1/128sq‑mm - Predictors: Not‑taken (0), Bimodal (0.25), 2‑level (0.5), comb (0.75), “Perfect” treated as prohibitively large
- Compute per‑benchmark metrics, normalize to the baseline, and aggregate with geometric means over the 5‑benchmark suite.
- Minimize:
- ED2P = energy × delay² (performance emphasis)
- EDP = energy × delay (efficiency emphasis)
- ED2AP = energy × delay² × area^p (performance + area)
- EDAP = energy × delay × area^p (energy + area + performance)
- ED2P: Favor wider fetch/issue/decode (while managing cycle penalties), dynamic scheduling, larger RUU/LSQ, moderate‑to‑large L1/L2 with balanced associativity.
- EDP: Favor narrower widths/static scheduling when viable, compact and efficient caches to limit leakage and access energy, conservative queue sizes.
- ED2AP/EDAP: Factor area directly into move selection; trade predictor complexity, cache capacity/associativity, and structure sizes to avoid area blowups.
src/- Core framework (driver, evaluation harness, utilities)
YOURCODEHERE.cpp: configuration validation and heuristic proposal logic
scripts/worker.sh: maps 18 encoded parameters to SimpleScalar flags and constraints
data/- Raw outputs, logs, summaries per run
plots/- Analysis notebooks and result visualizations
Makefile
- Generate a candidate configuration (proposal engine).
- Validate against cross‑parameter rules; reject early if invalid.
- Evaluate via SimpleScalar through the shell wrapper.
- Record metrics; update objective‑specific search state.
- Iterate until reaching 1000 evaluations per objective; export results.
- Build with the provided
Makefile. - Ensure SimpleScalar, benchmarks, and paths are correctly configured in
scripts/worker.sh. - Select an objective mode and run; the framework explores up to 1000 valid points.
- Use the generated summaries for plotting and analysis.
- Start from the baseline and perform coarse sweeps to identify sensitive dimensions per objective; then refine locally.
- Track a Pareto frontier (energy, delay, area) to guide multi‑objective searches.
- Associativity affects both misses and latency—seek balance rather than extremes.
- Predictor choice matters: complex predictors reduce control misses but cost area; area‑aware objectives often prefer simpler predictors.
I include plots and summaries comparing the best configurations found for each objective, highlight the most impactful parameters (e.g., fetch width, L1/L2 sizing, RUU/LSQ), and discuss tradeoffs between IPC gains, cycle time penalties, leakage, and area growth.
Thanks to the SimpleScalar ecosystem and the broader research community for tools and ideas that informed this exploration.