Skip to content

vsntll/Dynamically-Scheduled-Processor

Repository files navigation

Dynamically Scheduled Processor — Heuristic Design Space Exploration with SimpleScalar

Overview

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.

Project Goals

  • 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.

Design Space

  • 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.

What’s Implemented

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 ≤ 8 words; decode:width = issue:width = fetch:ifqsize
    • mem:width = 8B; memport ≤ 2; mem:lat = 51 + 7 cycles (for 8‑word)
    • tlb:lat = 30; TLB ≤ 512 entries, 4‑way
    • ruu: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.

Modeling Assumptions

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)/2 sq‑mm
  • Dynamic base: 4 + (fetch_width^2)/3 sq‑mm
  • Cache: 1 sq‑mm / 32KB
  • LSQ: (size/2)^2 × 1/128 sq‑mm
  • RUU: (size/4)^2 × 1/128 sq‑mm
  • Predictors: Not‑taken (0), Bimodal (0.25), 2‑level (0.5), comb (0.75), “Perfect” treated as prohibitively large

Objectives and Metrics

  • 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)

Search Strategies (High Level)

  • 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.

Repository Layout

  • 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

Workflow

  • 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.

How to Run

  • 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.

Notes and Practical Tips

  • 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.

Results and Discussion

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.

Acknowledgments

Thanks to the SimpleScalar ecosystem and the broader research community for tools and ideas that informed this exploration.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

1 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors