跳到主要内容

前端验证与性能调试方法

前端 bug 往往不是“某表算错一位”，而是多个正确模块在 stall、flush、override 的交界处状态错位。因此验证必须围绕协议和不变量组织。

四层验证​

1. 单元 reference model​

对饱和计数器、折叠历史、循环指针、FTB target 编码等写软件模型，随机比较每次更新。

2. 模块协议验证​

随机施加 ready backpressure、redirect 与连续请求，断言 payload 稳定、事务不丢不重、flush 后无旧响应生效。

3. 子系统 trace 对账​

为每个 FTQ 项记录 prediction → fetch → predecode → redirect/commit → update。检查同一身份的 PC、meta、target 始终一致。

4. workload 性能归因​

运行 benchmark，使用 top-down 事件区分 control redirect、BTB/TAGE/SC/ITTAGE/RAS miss、FTQ full、ICache/ITLB miss 和后端背压。

必写断言​

  • stall 时级间 payload 稳定；
  • flush 后旧 epoch 的响应不能写入当前状态；
  • FTQ occupancy 不越界；
  • commit update 只能针对仍有效且已提交项；
  • 历史恢复后与 reference model 一致；
  • 一个取指块最终选择至多一个最早 taken 控制流；
  • 同一请求不能同时被记为完成和 replay。

调试顺序​

遇到错误 PC 时不要从最终波形向所有模块发散。按顺序问：

  1. 错误 PC 第一次在哪里产生？
  2. 当时选择的是哪一级预测？
  3. 对应 FTQ 项和 epoch 是什么？
  4. 历史/FTB entry/meta 是否来自同一事务？
  5. 是否有更高优先级 redirect/flush 同拍？
  6. 错误是值计算问题还是身份错位？

身份错位通常表现为“值看起来合理但属于上一条请求”，这类 bug 单看组合公式很难发现。

性能调试纪律​

任何优化都同时报告：IPC、分支 MPKI、覆盖次数、恢复周期、FTQ/IBuffer occupancy、ICache/ITLB 指标、频率和面积估计。只报告命中率提升不足以证明优化有效。