Add execution-driven CPI attribution framework

[sagar-h007]

What this PR is about

This PR adds a CPI (Cycles Per Instruction) attribution framework to Olympia so it’s easier to understand where execution time is actually being spent in the pipeline.

Until now, we had IPC and a few aggregate stall counters, but no clear way to tie stalls back to retiring instructions. This change fills that gap by tracking CPI at the instruction level and aggregating it at retirement.

⸻

What’s included

• Per-instruction CPI breakdown across 8 pipeline stages:
• Fetch, Decode, Rename, Dispatch, Issue Queue, Execute, Memory, and ROB
• Lightweight timestamping as instructions move through the pipeline
• CPI calculation done at retirement, so there’s no added pressure on the execution path
• ROB-level aggregation using Sparta counters, which shows up naturally in reports

⸻

How it works (high level)

Each pipeline stage records when an instruction enters it.
When the instruction retires, CPI components are computed as differences between these timestamps and accumulated into ROB counters.

This keeps the implementation simple, execution-driven, and easy to extend.

⸻

Design notes

• Attribution is stage-based, not fine-grained causal (e.g., L1 vs L2 vs TLB)
• That tradeoff is intentional for a first step and keeps the model stable
• More detailed breakdowns can be layered on later if needed

⸻

Why this is useful

This makes it possible to answer questions like:

• Are we front-end bound, memory bound, or execution bound?
• Which pipeline stages dominate CPI for a given workload?
• How do micro-architectural changes impact real execution time?

⸻

Scope

• New CPI/timestamp metadata on instructions
• New CPI finalization logic
• Small instrumentation changes across Fetch → ROB
• ROB-level CPI aggregation via Sparta

⸻

Fixes: #293

If this direction looks good, I’m happy to iterate on naming, attribution granularity, or validation strategy based on feedback.