Implement Comprehensive CPI Attribution Framework

[sagar-h007]

Problem Description

Currently, Olympia calculates IPC as a simple ratio (num_retired / cycles) in
core/ROB.cpp:16-17. While the Dispatch unit tracks stall reasons per execution unit (
core/dispatch/Dispatch.hpp:126-156), there is no attribution of CPI contributions to specific microarchitectural events.

Missing capabilities:

• No per-instruction CPI breakdown (e.g., "instruction X stalled Y cycles due to L1D cache miss")
• No aggregated CPI stack (e.g., "10% of cycles lost to branch mispredictions, 25% to memory")
• Dispatch stall counters exist but are cycle-based, not instruction-weighted
• No correlation between stall events and retiring instructions
• No visibility into which pipeline stage contributed most to execution time per instruction
• Specific gap: An instruction might spend 1 cycle in rename, 5 cycles waiting in IssueQueue for a dependency, 3 cycles executing, and 2 cycles in ROB before retire. Currently, we only know it retired—we don't attribute the 11 total cycles to specific causes.

Relevant Components

core/ROB.cpp: Retirement logic and IPC calculation
core/Inst.hpp: Instruction metadata (add CPI tracking fields)
core/dispatch/Dispatch.hpp: Stall reason tracking (already present but not attributed)
core/execute/IssueQueue.cpp: Dependency stall tracking
core/lsu/LSU.cpp: Memory stall tracking
New: CPI attribution collector/aggregator

Why It Matters

• For execution-driven performance models: CPI attribution is the fundamental metric for understanding performance bottlenecks. Without it:

• Architects cannot identify optimization opportunities

• Workload characterization is limited to IPC

• Cache/branch predictor/prefetcher tuning lacks granular feedback

• Model validation against RTL or silicon is difficult (can't compare CPI stacks)

[sagar-h007]

@klingaard I’ve been digging into the IPC and stall-tracking paths while understanding Olympia’s execution-driven flow (ROB retirement, dispatch stall reasons, and issue/LSU behavior).

This issue lines up closely with what I’ve been looking at—especially the gap between cycle-based stall counters and instruction-level CPI attribution. I’d like to work on this if it fits the project goals, and I’m happy to start with a scoped proposal or prototype for CPI attribution and aggregation.