RVV 微架构设计对比

RVV 微架构对比报告

总体结论

实现	架构定位	核心设计取向
XiangShan RTL	OoO scalar core 内建 RVV 后端	RVV 作为乱序核心的一等执行资源，decode 拆 uop，rename/ROB/异常恢复统一纳入 CPU 后端
Saturn RVV	Rocket/Shuttle 外挂的 decoupled vector unit	独立向量单元，frontend 先做精确 fault check，backend 用 VAT age + issue queue + sequencer 做动态调度和 chaining
T1 / Titan-I	长向量 coprocessor / vector machine	lane-based 长向量机，靠 slot、VRF record、element/group scoreboard 和 SRAM VRF 支撑 chaining；避免 ROB/rename/复杂投机

1. 集成方式

XiangShan

XiangShan 的 RVV 是 OoO core 后端的一部分

• 默认 VLEN=128、ELEN=64、HasVPU=true
• 向量数据类型也直接定义在 backend datapath 中：VecData=128、V0Data=128、VlData=log2Up(VecData)+1

这意味着 RVV 指令走 XiangShan 原有 fetch/decode/rename/dispatch/issue/ROB/commit 框架，只是在后端增加向量寄存器、向量执行、VLSU、VType/vstart 等状态路径。

Saturn

Saturn 是挂在宿主 core 后面的 vector unit。Rocket 版本继承 RocketVectorUnit，wrapper 里实例化 VectorDispatcher、SaturnRocketFrontend、VectorBackend、VectorMemUnit。Shuttle 版本结构类似。

它的主路径是 frontend 做 fault check 后发给 dispatcher，dispatcher 再分 backend 指令流和 memory macro-op，backend 与 VMU 交换 load/store 数据。

T1

T1 是外接 Rocket 的向量处理器。顶层注释明确包含 LSU、Decoder、Lane、CSR、Instruction Queue，并承载 Vector Sequencer 与 Mask Unit。接口是 issue 输入、retire 输出、两个 load/store AXI 端口。

T1 支持 intensive chaining 和 SRAM-based VRF。

2. ISA 覆盖和参数化

维度	XiangShan	Saturn	T1
VLEN	默认 128b	可配，要求 vLen >= dLen 且整除	从 zvl...b 解析，支持 128b 到 64K 级配置
ELEN	64	支持 application-profile RVV，README 写 Zve64d/ELEN=64	从 zve... 解析，当前主线是 Zve32x/Zve32f
并行宽度	core 内 128b vector datapath	dLen/mLen 表示 SIMD datapath/memory datapath	dLen 是总带宽，datapathWidth=laneScale*eLen，laneNumber=dLen/datapathWidth
VRF 组织	OoO core 的向量物理寄存器体系，另有 V0/VL 类	banked VRF，element group = vLen/dLen	每 lane SRAM/banked VRF，VRF record 跟踪 element/group 完成

• Saturn 参数集中在 VectorParams，包括 VDQ、load/store queue、issue queue、dLen/mLen/vatSz、enableChaining、enableOOO、`vrfBanking
• T1 参数集中在 T1Parameter：vLen 从 zvl...b 解析，eLen 从 zve... 解析，laneNumber = dLen / datapathWidth

3. Decode 和 uop / element 拆分

三者在“指令拆分、状态追踪、retire”上的根本差异：

• XiangShan 是 decode 拆 uop 后共享同一 ROB SRAM 项，并通过同一个 robIdx 汇聚完成位
• Saturn 是 VAT 年龄表加 sequencer 按 element group 发 token
• T1 是 requestReg、slot、token queue、lane 和 responseCounter 串成的长向量顺序完成模型。

XiangShan：decode 阶段硬件拆 uop

• XiangShan 在 DecodeUnitComp 中把复杂 RVV 指令拆成多个 DecodeOutUop
• RVV unit-stride、fault-only-first、strided、indexed、segment load/store 都有专门拆分逻辑

关键点：拆出来的是 core 后端真实 uop，会进入 rename/dispatch/issue，但 ROB 不按每个 uop 分配 entry。

Saturn：frontend decode，backend sequencer 按 element group 生成 micro-op

• 先形成 VectorIssueInst，进入 VectorDispatcher，再进 backend 的 VDQ 和各类 issue queue。Backend 建了 vlissq/vsissq/vpissq/vxissq，分别接 load/store/special/execute sequencer。
• 真正的拆分发生在 sequencer：get_next_eidx 按 dLen/mLen/EEW/mask 推进元素范围，execute/load/store sequencer 生成带 eidx/tail/wmask/wvd_eg 的 micro-op

T1：顶层 issue 到 slot，lane 内按 group 执行

1. 先用 1-entry requestReg 锁存指令、CSR、decode result 和 instruction index
2. 之后分配到 chainingSize 个 slot。特殊指令如 mask unit、跨 lane 交换、unordered slide、vd=v0 被分配到最后一个 slot。
3. Lane 内每个 slot 走 Stage0/Stage1/Stage2/ExecutionBridge/Stage3
   • Stage0 按 mask/SEW/group counter 找下一个 group
   • Stage1 发起 VRF 读并做 chaining check
   • ExecutionBridge 把 Decoder.uop 发给 VFU

4. ROB / retire / 顺序模型

实现	在飞指令状态
XiangShan	CPU ROB + rename 表 + 物理寄存器。RVV split uop 共享同一个 robIdx
Saturn	VAT age tag + VDQ/issue queue/sequencer 状态；不是宿主 CPU ROB 的每 uop 模型
T1	instructionCounter/responseCounter + 顶层 slots + lane/LSU endTag；无传统 ROB/rename

XiangShan: 一条 RVV 指令拆出的多个 uop 共享 ROB entry

• rename 分配 robIdx 只随 lastUop 计数推进；
• ROB 入队用 firstUop

Saturn: 让可能 fault 的 memory op 先在 frontend 被检查/阻塞/重放，backend 只接收已经可安全推进的 vector work

• 用 vat_tail/vat_head/vat_valids 给向量指令分配年龄标签
• Backend 完成后通过 vat_release 释放
• 和标量核的顺序不是靠 Saturn backend 里的 VAT 单独保证，而是靠宿主 core 的 vector frontend 接口先把 RVV 指令纳入标量流水线的 retire/trap 协议，再把已通过检查的 vector op 发给 backend。
• 精确异常主要在 frontend 解决：PipelinedFaultCheck / IterativeFaultCheck 在 vector memory op 进入 backend 前完成 TLB/fault 检查；若 IFC busy，则 io.core.wb.xcpt/cause/tval/retire 直接来自 IFC。也就是说 Saturn 尽量避免“已经在 backend 执行很远之后才发现精确 trap”的情况
• Saturn backend 没有 XiangShan ROB 那种通用 flush/rollback 恢复路径：VectorBackend 主要输出 busy/vat_release/scalar_resp/set_vxsat/set_fflags，没有接收来自宿主核的全局 redirect/flush 信号；PipelinedFaultCheck 只在进入 backend 前用 io.core.killm kill 掉还在前端流水的指令，IterativeFaultCheck 自己有 flush 用于清理 frontend 的 indexed/masked replay 状态

T1:

• 用 instructionCounter 分配指令号
• 用 responseCounter 按 retire 递增
• slot 只有在 lane/LSU/mask 都完成且轮到该 index 时才 commit
• T1 和标量核的顺序主要由 Rocket 侧的 T1 接口和 scoreboard 维护，而不是 T1 本体内部的 ROB, T1 本体内部保证的是“进入 T1 的 vector 指令按 instruction index 完成”：因此 T1 对标量核表现为一个可排队、按完成响应释放的长延迟执行单元
• T1 对精确异常和复杂内存一致性的硬件保证弱于 Saturn/XiangShan。T1 不检查异常，并把 PMP/PMA legal/read/write 范围设为全地址；lane 侧也有 TODO，要求 scalar core 在 vstart != 0 时抛 illegal，T1 内部 executeIndex := 0.U。所以 T1 目前更像“Rocket 顺序发射/回收 + T1 内部顺序 retire”的协处理器模型：和标量指令的提交顺序由 Rocket 侧队列/scoreboard 约束，vector memory 的完成用 retire.mem 释放；
• T1 使用的是自带 rocketv 的 in-order Rocket 风格宿主核。所以 T1 模型应理解为“scalar pipeline 发射到 T1 queue，T1 顺序返回 retire 事件”，不是“vector 指令进入 scalar ROB 后由 ROB 精确提交”。这也是为什么 T1 对异常恢复的能力依赖 Rocket 侧前端约束和 T1 的顺序 retire，而不是依赖一个统一 ROB 来回滚向量后端状态。

5. 调度和 chaining

• XiangShan 依托 OoO issue queue 的 wakeup/bypass tag 广播
• Saturn 以 VAT 年龄比较和 element group hazard mask 清除推进 younger 指令
• T1 以每 lane VRF 的 chainingRecord SRAM、ChainingCheck、WriteCheck 追踪 element/group readiness

XiangShan

XiangShan 对 RVV 支持 OoO 框架下的投机唤醒和 bypass，但这不等价于 Saturn/T1 那种按 element group 或 VRF element readiness 推进的“经典 chaining”。

具体说，向量 uop 进入 vec scheduler 后，会和其他后端 uop 一样参与 issue queue 的 wakeup/select 机制

• Backend 把 vecRegion.io.wakeUpToDispatch 接到 dispatch wakeup 网络
• Region 内把 issue queue 的 wakeupToIQ、WB wakeup、load wakeup 等接回 IQ
• IssueQueueWakeUpBundle 也有 vecWen/v0Wen/vlWen 这些向量寄存器写回唤醒字段
  因此 producer vector uop 可以在写回/旁路时唤醒 consumer uop

数据通路上，DataSource 明确定义了 forward/bypass/bypass2，BypassNetwork 会按 exu/source 选择 forward/bypass 数据。所以 XiangShan 可以做“指令级/物理寄存器级”的投机唤醒与 bypass。

但是 XiangShan 不支持 element-level chaining

Saturn

Saturn 默认 enableChaining=true。
chaining 关键是 hazard mask 随 element group 推进而清除

• Load/Store/Execute sequencer 每发出一个 uop，如果跨到新 element group，就清除已读/写的 hazard mask，让年轻指令可以继续推进
• 主要用 pipe_hazards/iter_hazards 表示流水中未写回结果，backend 用 VAT age 判断 older writes/reads，更像动态 scoreboard + element group chaining

T1

T1 的 chaining 核心在 VRF record

• VRF 内维护 chainingRecord，读请求进入前实例化 ChainingCheck
• 如果 younger read 命中 older pending write，则阻塞，否则允许继续
• 写侧还有 WriteCheck 覆盖 WAW/WAR
• 支持 load-to-exec-to-store-to-load chaining 和 SRAM VRF

6. VRF 和 mask/v0 组织

XiangShan 把 vector、v0、vl 作为不同数据/寄存器类处理：VecData、V0Data、VlData 分开定义:

• 数据宽度上 VecData/V0Data 都是 128b，VlData 是 log2Up(VecData)+1
• rename 和 regfile 路径上也有独立的 vec/v0/vl free list、read/writeback port 和寄存器文件实例
• 这种设计更适合 OoO 物理寄存器重命名：mask v0 和 vl 被当成特殊寄存器类来避免和普通 vector RF 混在一起
• 物理寄存器多端口结构：VFEX0/VFEX1/VLSU0/VLSU1 静态绑定不同的 VF/V0/VL 读写端口
  • 每个 VFEX/VLSU 通常读 3 个 VF 源和 1 个 V0 源
  • VFEX0/VLSU0 还可写 VL，VLSU0/VLSU1 分别占用 VF/V0 写回端口 2/3

Saturn 的 VRF 是 banked register file

• 每个 bank 有普通 vrf 和 v0_mask memory
• 写普通 VRF 时，如果 eg < maskRows 同步更新 mask 副本
• VRF 支持 1/2/4 bank
• 读侧用 RegisterReadXbar 按 eg 低位选择 bank，再用每 bank 的 arbiter 仲裁
• 写侧按 bankId 把 pipe writes / load-lane writes 分发到对应 bank

T1 的 VRF 是每 lane SRAM/banked 组织

• VRFParam 定义 32 个寄存器、read port connection tree、bank 数、depth、read latency
• 实际实现含 RAM、bank split、chaining detection
• T1 还把 v0 复制给 LSU/mask 使用
• T1 的 VRF 更像为长向量 lane 设计的本地 SRAM 子系统
  • 每 lane 有 banked RAM
  • 读请求先经过 connection tree / bank split，写回时更新 SRAM 和 chainingRecord
  • 读侧通过 ChainingCheck 判断 older write 是否已经覆盖目标 element/group
  • 写侧通过 WriteCheck 避免 WAW/WAR 类 hazard
• 读写端口：VRFParam.connectTree 默认为 chainingSize * 3 + 1 + 1 个读请求入口，含每个 slot 的 3 个读源、masked write 读源和 LSU 读源；vrfReadPort = connectTree.size
  • 物理 SRAM 侧再由 portFactor/ramType 决定 bank 数和读写端口形态，读请求经过 bank select、first/second read pipe 和 ChainingCheck，写请求经 writePipe/writeBankPipe 与读端口冲突检测共同仲裁

7. LSU 和访存

XiangShan 的 vector load/store 是 core 内 VLSU/LSQ 体系的一部分

1. decode 先拆地址/数据/segment/indexed 等 uop
2. ROB/ExceptionGen 再合并精确异常信息
3. FOF load 的最后 uop 还会写 VL
4. XiangShan 的 VLSU 是 scalar core LSQ 的扩展，而不是外置 vector memory engine

Saturn 的访存是 decoupled access-execute

1. Frontend 有 PipelinedFaultCheck 和 IterativeFaultCheck，先做 TLB/fault 检查
2. Backend/VMU 再处理 load/store data

• VMU 内有 load addr/IFQ/segmenter、store compactor/segmenter/addr/IFQ/ROB
• Load 还有 LoadOrderBuffer 做保序
• 和标量内存的一致性则靠两层机制：
  1. frontend 对 scalar pipeline 给出 block_mem，条件包括当前 vector memory op 和 scalar_check.conflict
  2. VMU 里 ScalarMemOrderCheckIO 用标量访存物理地址和 vector load/store queue 的 block overlap 做冲突检测
  3. store/load queue 之间还有 ld_dep_mask/st_dep_mask 保序

T1 的 LSU 是高带宽长向量设计

• LSU 顶层包含 LoadUnit、StoreUnit、SimpleAccessUnit 和可选 ZVMA
• 每 lane 有到 VRF 的写回队列
• 每 memory bank 有多个 MSHR，并支持 instruction-level interleaved vector load/store
• LSU 对外有高带宽 load/store AXI 端口和 indexed/simple 访问端口；内部把一个向量访存按 lane/group 拆到 MSHR group，MSHR 等待请求/响应并把 load data 经 queue/crossbar 写回 lane VRF，最后通过 endTag 通知 T1 slot/responseCounter。追求长向量吞吐和 outstanding memory 并行度

8. 异常、vstart 和精确性

异常精确性的硬件落点：

1. XiangShan 在后端由 VLSU/vector pipe 产生候选异常，再经 ExceptionGen、ROB 和 CSR 写出精确 vstart
2. Saturn 在 frontend 用 pipelined/iterative fault check 截断 faulting memory op，检查通过后才进入 backend
3. T1 当前更偏长向量顺序完成模型，非零 vstart 主要依赖标量核判断 illegal

实现	vstart / precise trap 策略
XiangShan	后端 ROB/ExceptionGen/CSR 协同，vector load exception 写回精确 vstart
Saturn	frontend 先行 fault check；复杂内存用 IFC 逐元素检查，异常前不送后端执行
T1	当前基本不支持非零 vstart 重启；源码注释要求 scalar core 对非零 vstart 抛 illegal，T1 自身不检查异常

1. XiangShan ROB 在 vector load exception 时生成 vecExcpInfo 并写 CSR vstart

   • ExceptionGen 对同一 ROB 内 vector 异常按 vstart 选择更早元素

2. Saturn 的 IterativeFaultCheck 逐元素检查 indexed/masked/跨页访问

   • 异常输出精确 vstart/tval
   • FOF 非 0 元素 fault 则 retire 并更新 VL
   • 非 memory 指令若 vstart != 0 会被判 illegal

3. T1 的 tile 注释明确写着 T1 不检查异常

   • T1Issue 携带 vstart，但 lane 入口处有 TODO，注释要求 scalar core 对非零 vstart 抛 illegal
   • LSU 也有 todo: vstart

9. vtype/vl CSR

RVV 的 vtype/vl/vstart/vcsr 看起来是普通 CSR 状态，但在硬件实现上会直接决定向量指令的拆分、源操作数 readiness、tail/mask 行为、异常恢复和 commit 精确性

1. XiangShan 把 vl 深度融入 OoO rename/ROB 体系
2. Saturn 把 vconfig/vstart 放在 frontend fault check 和 sequencer 之间流动
3. T1 则由标量核在 issue 时把 CSR snapshot 一次性送入 decoupled vector accelerator

1. XiangShan：vtype 走 ROB 精确提交，vl 走物理寄存器重命名

XiangShan 没有把 vl 简单当作 CSR 旁路值使用，而是把它做成独立的物理寄存器类：

• 参数中有 vlPreg，VlData 的宽度由 vlWidth = log2Up(VLEN) + 1 决定
• rename 阶段也有独立的 vlRat 读端口和 vlCommits 提交回收路径
• vl 可重命名、可被 wakeup/busy table 跟踪的特殊物理寄存器

vtype 的路径更接近精确 CSR/ROB 状态：

• Backend 从 int/vf region 收集 VSET 类执行单元产生的 VType，寄存到 vsetvlVType 后送回 decode
• ROB 侧同时提供 commitVType 和 hasVsetvl
• 最后通过 mux 选择提交态或最新 VSET 态写入 CSRFile
• vtype 需要处理 speculative VSET 与 ROB commit 的一致性，因此有 commit/walk/resume 相关路径
• decode 阶段依赖当前可见 vtype/vstart 做后续 RVV 指令合法性、拆分和控制生成，但最终架构态仍由 ROB/CSR 精确提交保证

好处: VSET 与后续向量指令可以在 OoO 后端中形成寄存器依赖关系，不必完全串行化所有 vector CSR 访问

代价: vl/vtype 状态管理比 in-order accelerator 更复杂，需要 RAT、free list、ROB commit、decode 回传和 CSR 写回之间保持一致

2. Saturn：Fault Check 前移

Saturn 的 IssueInst 直接携带 vconfig、fission_vl 和 vstart

1. PipelinedFaultCheck 和 IterativeFaultCheck 都拿 vconfig/vstart 参与地址范围、TLB、mask 和元素索引检查；
   • 复杂跨页或 indexed/masked 访存可以被拆成更小的 fault-check 片段，并通过 fission_vl 或 set_vstart/set_vconfig 控制后续执行
2. 如果 PipelinedFaultCheck 产生 fission_vl，dispatch 会覆盖当前 vconfig.vl
3. frontend dispatch 会根据特殊情况修改 vl/vstart，例如 move-to-scalar 时把 vl 设成 1、vstart 设成 0
4. backend sequencer 消费的则是随指令携带的 vconfig.vl/vtype/vstart
   • load/store sequencer 用 vstart 初始化 eidx，用 vconfig.vl 判断 tail
   • execute sequencer 用 vconfig.vtype.vsew/vlMax、vconfig.vl 计算 eff_vl、next_eidx 和 mask/tail 边界

这种设计更像 access-execute vector unit：vconfig/vstart 是指令包的一部分:

1. 减少了后端处理精确异常的压力
2. 对 frontend fault-check、TLB 和 replay/fission 控制提出更高要求

3. T1：标量核 issue 时携带 CSR snapshot

1. T1Issue 在发射到 T1 accelerator 时携带 instruction/rs1Data/rs2Data/vtype/vl/vstart/vcsr
   • T1 的 Rocket 侧定义了完整的 vector CSR bundle，包括 vtype/vl/vcsr/vstart
2. T1 顶层收到 issue 后把这些 raw CSR bit 解码成 CSRInterface：vlmul/vSew/vta/vma/vl/vStart/vxrm/frm 等字段被锁存成请求态，再广播给 lane、mask unit 和 LSU

T1 的特点是:

• CSR 状态是每条进入 accelerator 的指令快照
• lane 内部用 csrInterface.vl/vSew/vlmul 计算 mask/tail、last group、lane 是否参与执行
• LSU 用同一份 CSRInterface 计算 memory element 数、whole-register load/store 的 evl 和请求终止条件

这种设计适合 decoupled 长向量 accelerator：标量核负责 CSR 架构态和发射顺序，T1 内部只需要保存每条指令的 CSR snapshot 并驱动 lane/LSU

代价: 非零 vstart 的完整支持仍有 TODO/限制

XiangShan RVV 后续性能优化点

基于当前 XiangShan RTL，RVV 的主要性能瓶颈不在“是否能 decode 拆 uop”本身，而在 uop 拆分后对 ROB/IQ/VRF/LSQ 资源的放大，以及向量执行结果只能按较粗粒度唤醒依赖指令。下面这些方向按收益潜力和实现侵入性排序。

1. 细粒度 Chaining

• 向量算术之间没有 element/group 级 chaining
• 已有 BypassNetwork 对 isVfExeUnit && writeVfRf 到 readVfRf 的 bypass2 通路做了支持，不过是 uop/物理寄存器级的转发
• producer uop 完成后以物理寄存器为单位唤醒 consumer

Saturn/T1 则能在 element group 或 VRF bank/record 层面判断部分结果已可读，从而实现更细粒度 chaining。

可优化方向：

1. 在 VFEX/VLSU 写回侧维护 vd + element group range 的 ready record
2. 在 vector issue 读源时检查 consumer 所需 element group 是否已 ready，而不是等待整条 vector uop 完成
3. 先只对 unit-stride load -> VFEX、VFEX -> VFEX、VFEX -> vstore 三类路径做有限 chaining，避免一次性覆盖所有 RVV 指令

预期收益：长向量场景下可以隐藏 producer/consumer 间完整向量 uop 的延迟，尤其是 load-use、compute-store、compute-compute pipeline。

风险：较大微架构改动，会影响异常精确性、vstart、mask inactive element、tail policy、ROB commit 语义和 VRF 端口调度

2. 降低 RVV uop 对 ROB/IQ 的资源放大

XiangShan decode 阶段会把一条 RVV 指令拆成多个 uop:

1. ROB 语义仍围绕原始指令精确提交
2. IssueQueue、LSQ、VLSU 内部则要承载拆分后的 uop。长向量或 segment/indexed memory 指令会显著放大 IQ/LSQ 压力。

可优化方向：

1. 对规则的 unit-stride vector memory 指令引入更强的 macro-uop/iterator 执行模式，减少进入 IQ 的 uop 数。
2. 对 segment load/store 建立专用 segment sequencer，避免每个子访问都完全消耗通用 issue 资源
3. 对简单 vector ALU 指令支持 repeat issue 或 internal micro-sequencer，让 IQ 只看到较少的控制 uop

预期收益：减少 ROB 后端压力、IQ entry 占用和 wakeup CAM 压力，对大 vl 程序尤其有效

风险：需要保持 precise exception、interrupt、flush、vstart 更新和 ROB 完成计数一致；实现上要明确“ROB 看到的完成”和“内部 element/uop 完成”的边界。

3. 继续强化 VLSU/LSQ 投机执行

1. 对 vector load replay 增加更细的 store address/data readiness scoreboard，减少保守 replay
2. 对 vector store 的 illegalIssue 防护从临时 check 演进为正式的 physical SQ credit/lease 机制，减少因为 physical SQ 窗口不确定导致的停顿。
3. 对 indexed/strided load 提高 outstanding miss 并行度，接近 T1 的 MSHR-group 思路，但仍保留 XiangShan 的精确异常模型

预期收益：提升 memory-bound RVV kernel，例如 memcpy-like、stencil、gather/scatter、segment load/store。

风险：memory violation、store forwarding、TLB exception、FOF load 修改 VL 都会和更激进的投机交织，需要配套验证。

4. 优化 VRF/V0/VL 端口和 bank 冲突

XiangShan 把 Vec/V0/VL 拆成独立物理寄存器类，适合 OoO rename，但高吞吐 RVV 对 VRF read/write port 的压力很大。当前 VFEX/VLSU 端口静态分配清晰，但容易在混合 vector ALU + vector memory 下形成端口热点。

可优化方向：

1. 统计 VFEX0/VFEX1/VLSU0/VLSU1 的 VRF port 冲突，按 workload 重新平衡读写端口绑定。
2. 对 v0 mask 读建立类似 Saturn 的 mask shadow/copy，减少普通 V0/VF 端口竞争。
3. 对 VL/VTYPE 这种小状态增加专用 bypass/forward path，减少通过通用寄存器 wakeup 带来的延迟。

预期收益：提升多发射 vector pipe 的持续吞吐，减少“FU 空闲但 RF 端口不可用”的结构冒险。

风险：端口增加会直接推高面积和时序压力；mask shadow 还要处理 v0 写回一致性。

5. 改进 FOF、segment 和 indexed 指令的专用路径

FOF、segment、indexed 是 RVV 中最容易触发保守拆分和异常处理的指令族。当前 dispatch 对 segment 和 FOF fix-vl uop 有特殊处理，说明这类指令仍有较多临时边界条件。

可优化方向：

1. FOF load 的 fault check 和 VL 写回路径前移，减少最后 uop 对 commit 的长尾阻塞。
2. segment load/store 使用专用 reorder/merge buffer，提升多 field 合并和异常定位效率。
3. indexed memory 增加地址生成队列和乱序 miss 返回合并，避免所有元素被最慢地址拖住。

预期收益：改善数据库、稀疏计算、结构体数组访问等 RVV 程序。

风险：精确 vstart、部分完成、inactive element 和 exception priority 是主要复杂点。