菜单
用于比较 XiangShan RTL 与 gem5 BTBTAGE/TAGE 在 allocation、useful、reset 和 update path 上的语义差异，并结合 CI、原始 stats 和 benchmark 结果定位性能变化来源。适用于用户要求检查“和 RTL 是否对齐”、分析 TAGE 相关性能变化、设计最小 A/B 验证时。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
由 CPU 性能模拟器建模经验蒸馏而成的行为级建模规范。强调高性能实现、参数化资源模型、细粒度/粗粒度取舍、控制流抽象、复杂度约束和 stats 驱动验证。适用于新增或修改性能模型、把 RTL 机制抽象成模拟器模型、设计参数化微结构模型、决定哪些行为需要细粒度建模、评审 AI 生成的 CPU 性能模拟代码时。
用于编译 XiangShan RTL trace 版 emu、运行 RTL/gem5 的 TAGE trace、并对 gem5 stats/bp.db 与 RTL CondTrace 做共口径聚合比较。适用于 coremark、SPEC checkpoint slice、sjeng_22213 等单切片对拍与首轮分叉定位。
分析香山 MGSC/SC 在前端微测试上的效果。适用于以下场景：(1) 用 off/l_only/g_only/i_only/full 等 A/B profile 批量运行 mgsc_test；(2) 比较不同 profile 下的 topMispredictsByBranch.csv 和 stats.txt；(3) 使用 bp.db 里的 MGSCTRACE 将每个分支的收益/损失归因到具体 SC 表；(4) 决定如何为 Global 或 IMLI 表设计新的测试。
用于在本地通过 `gh` 远程触发 OpenXiangShan/GEM5 的 `manual-perf.yml`，并在触发后检查 run 是否正常创建。适用于用户明确要求触发 `manual-perf`、组装 `gh workflow run` 命令、校验 workflow 输入项、或确认触发后的 Actions run 状态。
用于从 GitHub Actions 的 gem5 性能 CI 中定位 summary、score.txt 和归档目录，并结合本地 gem5_data_proc 对 spec06/spec17 结果做 weighted score、benchmark 子项对比和通用 stats 归因。适用于用户给出 run URL/run id、commit、workflow run，或要求分析 CI 跑分变化来源时。
用于分析分支 PC 对应的 ELF / 函数 / 源码语义，并判断该分支更像是语义上天然难预测，还是更像预测器没有学好。适用于 SPEC06 checkpoint、benchmark ELF、topMispredictsByBranch.csv、单个 branch PC 归因。
| name | rtl-tage-alignment |
| description | 用于比较 XiangShan RTL 与 gem5 BTBTAGE/TAGE 在 allocation、useful、reset 和 update path 上的语义差异，并结合 CI、原始 stats 和 benchmark 结果定位性能变化来源。适用于用户要求检查“和 RTL 是否对齐”、分析 TAGE 相关性能变化、设计最小 A/B 验证时。 |
这个 skill 用来回答一类固定问题：
建议和 ci-perf-analysis 配合使用：
rtl-tage-alignment 负责语义对照和归因框架ci-perf-analysis 负责取 CI summary、archive 和 gem5_data_proc 数据适用于这些情况：
至少明确下面几项：
/nfs/home/yanyue/workspace/xs-env/XiangShan/src/main/scala/xiangshan/frontend/bpu/tage如果这些版本没钉住，后面的结论都容易漂。
比较顺序建议固定成下面 5 层：
这样不容易把不同层次的问题混在一起。
优先检查：
finalPred != actualTaken 之类的额外 gate这层决定：
allocateSuccessallocateFailure优先检查分配优先级是否一致：
invalidweak && !usefulany !useful要特别确认：
strong && !useful 卡住优先检查：
useful = 0 路径这层主要影响：
altDiffersproviderNauseAltCorrect/useAltWrong最容易忽略，但往往影响很大。
优先检查：
usefulResetCnt 在什么事件下 ++--如果 useful 平时没有局部衰减，这一层实际上就是整个 predictor 的 aging 机制。
必须先搞清楚每个计数器是在统计什么。
典型易混点：
updateAllocFailure
updateAllocFailureNoValidTable
allocProbeNoEligibleVictim
updateAllocFailure
如果不先对齐口径，很容易把结论做反。
allocateSuccessallocateFailureresetUsefultage_update_mispredcond_MPKIBPAllWrongupdateProviderNaupdateAltDiffersupdateUseAltCorrectupdateUseAltWrong这些指标很适合判断：
frontendBoundbadSpecBoundbranchMissPredictionfrontendLatencyBound这些指标可以帮助判断：
先回答：
gem5_data_proc 做 benchmark 级 stats 对比当前这套 CI 默认仍常见 gcc12 切片。
处理 gcc12-spec06-0.3c 归档时，建议显式带：
--slice gcc12
如果以后 workflow 默认切到 gcc15，而本地 run.py 默认行为已经一致，可省略 --slice。
stats.txt当这些情况出现时，必须回到原始 stats.txt：
更像是：
不一定代表真实 allocation 压力变小了。
更像是：
allocateFailure 降了，但 cond_MPKI 反而升了更像是：
如果同时满足下面条件：
useful == 01/2/3 都被视为“受保护”那么 useful 位宽本身很可能不是主矛盾。
这时更值得怀疑的是 reset cadence。
分析前先确认：
allocateFailure 究竟是 probe-level 还是 final-level有些“加 stats”的提交会顺手重构搜索逻辑。
这类提交要先看 diff，再决定能不能当成 stats-only。
如果回退主要集中在：
gobmksjenggccomnetpp优先拿这些 benchmark 的原始 stats.txt 做对照，而不是只看加权平均。
如果出现：
优先检查：
stats.txt 是否支持这个解释回答这类问题时，建议固定成下面顺序：
ci-perf-analysis
score.txt、gem5_data_proc 结果如果后续这套对齐流程稳定下来，再考虑补：