ridecore流水线解读

• 源码地址

流水线stage分属前后端

IF -> ID -> DP -> SW -> EX -> COM

分类	阶段	说明
前端	IF	指令获取阶段。PC 使用分支预测器，访问指令存储器。典型前端操作。
前端	ID	解码并寄存器重命名，这仍然属于前端操作，因为没有开始实际执行。
中间（交界处）	DP	分发阶段是前端和后端的“桥梁”：它决定指令是否能够进入执行系统（Reservation Station）。
后端	SW	Issue 阶段已经涉及硬件调度和等待执行资源。
后端	EX	执行阶段。指令在对应的执行单元中运行。
后端	COM	提交/写回阶段，更新寄存器状态和 ROB，彻底属于后端。

Dispatch（DP）阶段通常被认为是“前端的最后阶段”或者“前后端的分界点”。它从解码器/寄存器重命名器中取出指令，并将它们放入合适的 Reservation Station（RS）。你可以把它看成是：前端准备好的指令交给后端执行的关键一步，所以分析系统时，很多资料会将 DP 归为前端，但也有资料将它作为交界点来单独分析。结论：DP 更偏向前端，但有一定后端属性。

PC

PC的值根据优先级优先级1(top) : reset时 : ENTRY_POINT // 来自于 芯片定义优先级2      : prmiss  : jmpaddr // 来自于 exunit_branch: stall_IF : pc  // 来自于 流水线的stall: 其余情况  : npc // 来自于 IF 模块的npc

pipeline

IF

• 负责项

1.指令的获取及invalid // 不考虑
2.npc的计算

• npc 计算原理

npc的计算gshare 命中               : btb中计算出来的 地址第二条指令 invalid  : pc+4其他               : pc+8gshare 的设计 // 属于分支预测模块BHR // 分支历史寄存器PHT // 模式历史表PCBTB // 分支目标缓冲区流程在每个时钟的负边沿，使用的读取地址是 PC[12:3] 和 BHR 做异或（⊕）得到的结果, 从 PHT 中读取预测信息. 如果(读出的值大于1,即2或3)跳转（Taken）：用 PC 查 BTB → 得到 跳转目标地址将目标地址 更新到 npc否则（Not Taken）：npc += 4 or 8（顺序执行）模块读写BHR 的读写会基于当前预测结果进行更新；但如果最终证明预测是错误的，BHR 会回滚到更新前的状态。因此，在每次更新之前，BHR 都会先被备份。PHT 的读写 // PHT 是 Gshare 预测器中的一个数组，数组中的每个单元是一个2 位饱和计数器读一个用于 IF 阶段；一个用于 COM 阶段。写一个写端口用于 COM 阶段的写操作 // 在时钟的负边沿先读取当前值 , // 然后在正边沿写入更新后的值// 当一条分支指令完成时，会对其对应的 PHT 条目进行更新// 如果条件是“跳转”，则对应计数器加1；// 如果是“不跳转”，则计数器减1。// 饱和计数器最多为3，最少为0，典型行为如下：0,1 → Not Taken；2,3 → Taken（实现 hysteresis）BTB 的读写TODO

• 问题

1. 按地址 0x4 取指,  那么 inst2 会 invalid  吗 ?  另外, 岂不是 会存在 一拍 没有 inst2 发送到后端 会是的，确实会出现某一拍中只有一条有效指令（Inst1）被送入 IF/ID latch。

ID

1. 给 每一条处于投机路径的指令 分配一个 Speculative Tag // 分支预测相关// 目的是在 exunit_branch 模块 验证出 分支预测失败 时，清楚知道哪些指令是错误路径的，需要取消、回滚// 它的主要目的是跟踪指令的投机状态，以便在分支预测失败时快速恢复系统状态。// 和 用于寄存器重命名的 tag 是 两个系统。// 注意混淆 :// 1. 两者都用到了 "tag" 一词// 2. 两者都需要唯一标识一条或一组指令// 3. 它们都在支持乱序执行
2. 解码 // 不考虑

项目	内容
功能	为每条投机路径上的指令分配 Speculative Tag，以支持分支恢复
核心输出	sptagN 和 speculativeN
使用者	Decoder、Dispatch、ROB、RS(Reservation Station)、Commit 等
解决问题	精确追踪投机指令，支持分支预测失败时快速恢复系统状态

模块	主要用途
寄存器重命名 tag（如RRF中分配的物理寄存器编号）	建立写后读/写后写依赖关系，支持乱序执行
投机 tag（Tag Generator 生成）	标记哪些指令是投机的，支持错误恢复

以一个预测成功的分支为例：

1. 分支指令 B 发射 → branchvalid1=1, enable=1
2. Tag Generator：
   • 分配一个新的 Tag（比如 00010）
   • 设置 sptag1=00010, speculative1=1
   • tagreg 左移（进入下一轮准备）
   • brdepth+1
3. 后续投机指令 C、D、E 都被分配同样的 sptag=00010
4. 如果分支 B 后来预测成功（prsuccess=1）：
   • brdepth--，该 Tag 被释放，其他无影响
5. 如果分支 B 后来预测失败（prmiss=1）：
   • tagreg ← tagregfix（恢复到分支预测前状态）
   • brdepth ← 0
   • 所有 sptag==00010 的指令都将被清除（flush）

阶段	动作	模块	说明
IF	预测（Prediction）	Branch Predictor（BTB / GShare）	猜跳不跳、跳到哪，控制 PC
ID	恢复环境（Prediction）	Speculative Tag gen	跟踪指令的投机状态
EX	验证（Resolution）	exunit_branch	分支指令实际执行，看预测对不对，发出 prsuccess / prmiss 信号

DP

• 负责项

1.为每个指令中的"被写入寄存器" 分配 rename register
2.

• tag generator 与 寄存器重命名机制 原理

tag generator避免 写后读（RAW）(Read After Write)、写后写（WAW）、读后写（WAR） 等寄存器冲突(乱序执行导致的冲突)问题，会使用寄存器重命名机制每条指令的目标寄存器在进入后端之前都会被重新命名为一个“Tag”，这个 tag 是由 Tag Generator 生成的。

模块	功能
Tag Generator	为目标寄存器生成唯一的标识符（Tag），用于寄存器重命名与依赖跟踪
所在阶段	通常在 Decode 或 Dispatch 阶段
在乱序中的地位	关键，维持指令依赖关系和正确性

模块Architected Register File (ARF)：程序员视角下的寄存器集合（逻辑寄存器）Rename Register File (RRF)：物理寄存器集合（或者是寄存器标记表）Reorder Buffer (ROB)：保持提交顺序，支持恢复/回滚Tag Generator：为每条指令分配唯一标识符（tag），表示结果的位置

步骤	描述
分配 tag	为每个目标寄存器分配唯一 tag
更新 Rename Table	建立逻辑寄存器到物理 tag 的映射
消除冒险	使用 tag 跟踪依赖，避免多个指令写同一个寄存器
回写/提交	使用 ROB 确保乱序执行但顺序提交

如果只是顺序执行，那么根本不需要引入 RRF
为了支持乱序执行，必须引入物理寄存器（RRF）来保存未提交的指令结果，并通过 tag 建立依赖关系，使得即使写同一个逻辑寄存器也能正确调度。
乱序执行了之后，也需要计算依赖，然后重新执行吧，是不是浪费资源了只有发生 分支错误预测 时，才需要回滚和重新执行后续指令。这种情况虽然代价高，但在正确率高的预测器（如 Gshare）下，概率已经较低。

DP 与 SW 中间没有latch

SW

COM