|
| 1 | +CARP Meeting 9 |
| 2 | +======================== |
| 3 | + |
| 4 | +.. note:: |
| 5 | + |
| 6 | + This meeting focuses on **branch prediction research and design**—laying the groundwork for next week’s implementation. |
| 7 | + Building on Meeting 8, we’ll move from concept to architectural plan for the **Pattern History Table (PHT)**, **Branch Register**, and **2-bit saturating predictor FSM**, as well as reviewing jump instruction control flow. |
| 8 | + |
| 9 | +Where We Left Off |
| 10 | +----------------- |
| 11 | + |
| 12 | +- **Meeting 8:** Presented our progress and conceptual overview of control transfer. |
| 13 | +- **Status:** Branch and jump decoding logic defined; hazards mapped out. |
| 14 | +- **Next Goal:** Design a working predictive control unit that can feed the pipeline fetch stage. |
| 15 | + |
| 16 | +Focus Areas |
| 17 | +------------ |
| 18 | + |
| 19 | +**1. Branch Prediction Research** |
| 20 | + - Study classic branch prediction schemes: |
| 21 | + - Static: *Always-taken*, *backward-taken/forward-not-taken*. |
| 22 | + - Dynamic: *1-bit* and *2-bit saturating counter* models. |
| 23 | + - Understand predictor integration with instruction fetch. |
| 24 | + - Explore speculative PC updates and misprediction recovery. |
| 25 | + |
| 26 | +**2. Pattern History Table (PHT)** |
| 27 | + - Structure: indexed table storing 2-bit prediction states. |
| 28 | + - Goal: implement compact memory with index from lower PC bits. |
| 29 | + - Discuss memory mapping (size, associativity, update policy). |
| 30 | + |
| 31 | +**3. Branch Register File** |
| 32 | + - Holds recent branch addresses and outcomes. |
| 33 | + - Supports correlation between consecutive branches. |
| 34 | + - Evaluate tradeoffs: per-branch vs global history registers. |
| 35 | + |
| 36 | +**4. 2-Bit Predictor FSM** |
| 37 | + - Design the 4-state finite state machine: |
| 38 | + - Strongly Taken (ST) |
| 39 | + - Weakly Taken (WT) |
| 40 | + - Weakly Not Taken (WNT) |
| 41 | + - Strongly Not Taken (SNT) |
| 42 | + - Define transition conditions and update logic: |
| 43 | + - Increment/decrement on correct/mispredicted outcome. |
| 44 | + - Sketch Verilog pseudocode and state diagram. |
| 45 | + |
| 46 | +**5. Jump Implementation Planning** |
| 47 | + - Review `JAL` and `JALR` PC computation: |
| 48 | + - `JAL` = `PC + imm` |
| 49 | + - `JALR` = `(RS1 + imm)` (with bit 0 cleared) |
| 50 | + - Discuss interaction between jump logic and predictor. |
| 51 | + - Ensure clean pipeline flush on taken jump or misprediction. |
| 52 | + |
| 53 | +Architecture Discussion |
| 54 | +----------------------- |
| 55 | + |
| 56 | +- Define where the predictor hooks into **FETCH** and **DECODE**. |
| 57 | +- Plan control signals for: |
| 58 | + - Prediction request (`pred_req`) |
| 59 | + - Prediction valid (`pred_valid`) |
| 60 | + - Actual outcome feedback (`branch_taken`) |
| 61 | + - Table update enable (`pht_we`) |
| 62 | +- Determine timing for updates: at **EX/MEM** stage when branch result is known. |
| 63 | + |
| 64 | +Verification Strategy |
| 65 | +---------------------- |
| 66 | + |
| 67 | +- Simulate predictor convergence with simple loop patterns. |
| 68 | +- Add waveform probes for: |
| 69 | + - Prediction state transitions |
| 70 | + - PHT indexing and updates |
| 71 | + - PC redirection on misprediction |
| 72 | +- Develop directed tests for both `BEQ/BNE` and `JAL/JALR`. |
| 73 | + |
| 74 | +Next Steps |
| 75 | +----------- |
| 76 | + |
| 77 | +**This Week (Meeting 9):** |
| 78 | +- Research predictor types and finalize architecture diagrams. |
| 79 | +- Draft Verilog stubs for PHT, Branch Register, and FSM. |
| 80 | +- Document design rationale and state diagram. |
| 81 | + |
| 82 | +**Next Week (Meeting 10):** |
| 83 | +- Begin RTL implementation. |
| 84 | +- Integrate predictor into fetch/decode path. |
| 85 | +- Run first simulations of speculative execution and flush handling. |
| 86 | + |
| 87 | +--- |
| 88 | + |
| 89 | +*Note:* |
| 90 | +This phase marks our transition from conceptual understanding to architectural design for **speculative control flow**. |
| 91 | +Treat this as a preparation sprint before implementation week. |
0 commit comments