这篇论文提出的是 Kairos（Elevating Temporal Prefetching Through Instruction Correlation）：一种片上 temporal prefetcher，通过检测”关键访存指令”并跟踪其 prefetch coverage，来筛选和保留真正高价值的 temporal metadata。

TLDR：

现有 on-chip temporal prefetcher（STMS, Domino, Triage, Triangel）在片上元数据存储容量受限时，利用率普遍不足 —— 要么无差别缓存导致污染，要么像 Triangel 预采样过程本身损失 prefetch 机会。
Insight：少量指令（top 10 IP）贡献绝大多数 cache miss（>90%），且这些 miss 的地址绝大多数会被重用，因此应以”指令”为粒度筛选 metadata，而不是以”地址序列”为粒度统计重复性。
Kairos 三阶段设计：Key IP Detection（miss 贡献 >12.5% 即判为 critical）→ Prefetch Evaluation（用 useful prefetch coverage 把指令分为 positive/negative/neutral 三类以控制 metadata 保留策略）→ Dynamic Partition（PID 控制器动态调整 LLC 中 metadata 区大小）。
相比 Triangel 在 SPEC irregular 上 15.1% 的加速，Kairos 达到 25.2%（即 +10.1%），而且总固定硬件开销仅 251 B，约为 Triangel 17.6 KiB 的 1.4%（两个数量级降低）。

背景和动机

Temporal prefetcher 的基本思路是记录历史访存地址序列，用于预测未来的不规则访存（如 pointer chasing、图遍历）。早期方案（STMS、Domino、ISB、MISB）都因 metadata 体量过大而放在片外，带来带宽和延迟开销。近年来 Triage / Triangel 等方案尝试把 metadata 全部放在片上（复用 LLC 的一部分 way 存 metadata）。

但把 metadata 放到片上后，存储容量变得非常稀缺，出现了一个尚未被充分解决的问题：metadata pollution —— 大量低重用的元数据挤占了真正有用的条目。

Triage 把所有 miss 无差别地记录到 metadata cache，污染严重，prefetch coverage 低。
Triangel 引入 Set Sampler + Reuse Buffer 做”预采样”来判定一条地址序列的重复性是否达到阈值，只有通过者才插入 metadata。代价是：① 采样期间错失 prefetch 机会；② 多级采样结构本身复杂（17.6 KiB）；③ 阈值过严，程序阶段切换时适应慢。

图 1 的测量显示：STMS/Domino/Triage 的 metadata hit rate 较低（元数据利用率差），Triangel 虽然 hit rate 高但 prefetch coverage 并不同步提升（采样损失的 opportunity 被计入）。

两个 open question：

有没有简单快速的方法判断一条 metadata 是”useful metadata”（将被再次访问后触发 prefetch）？
有没有有效方法评估这些 metadata 发出的 prefetch 是否真的有用？

Insight

核心洞察来自两个实证观察（图 2，623.xalancbmk_s）：

Miss 分布高度集中：少数指令（top 10 IP）贡献了绝大多数 cache miss，”Others”（3400 多条指令）仅贡献很小一部分。
这些 miss 的地址绝大多数会被再次访问（>90% repeat miss）—— 也就是说，”由关键指令产生的 miss 地址”几乎天然就是 useful metadata。

这就等价于把问题从”地址序列级的重复性检测”（Triangel 做的事）简化为”指令级的 miss 贡献率检测”。用一句话概括：

通过观察访存指令的高频出现与 miss 数，可以以远更低的代价直接识别高价值的 metadata 来源。

再加一个观察 —— 先识别出关键指令后，并非所有关键指令的 metadata 都能产生 useful prefetch（有的指令的历史 miss 模式本身就不具备强 temporal 可预测性），所以还要再做一次**”事后评估”**：看每条关键指令发出的 prefetch 真正的命中率。

这两步合起来对应于 Kairos 的两阶段筛选：先粗筛（miss 贡献），再精筛（coverage 反馈）。

核心设计

Kairos 架构（图 4）三个主要模块：Detecting Unit（粗筛关键指令）、Training Unit（为关键指令学习 last-miss-address→next-address 的 temporal metadata，并按 coverage 分类）、Partition Unit（用 PID 控制器动态调整 LLC 中 metadata 区的 way 数）。Metadata 插入 LLC 的 metadata way，查询在 L2C miss 时触发 prefetch。

三阶段工作流：

Key IP Detection：识别 miss 贡献 >12.5% 的关键 IP。
Prefetch Evaluation：跟踪每条关键 IP 的 useful prefetch coverage，分类为 positive / negative / neutral。
Dynamic Partition：按负载阶段变化自适应调整 metadata 存储容量。

1. Detecting Method（Critical Instruction Detection，§3.2）

Detecting Unit 结构（图 5）：32 entries，每 entry 10-bit IP-tag + 1-bit key flag + 9-bit 单 IP miss 计数 + 31-bit PLRU 位，外加一个全局 9-bit total miss counter。总计 85 B。

工作方式：

一次 L2C miss 到来：用 hash 映射到 Detecting Unit 的某个 entry。若 IP 还不是 key IP，则该 entry 的 miss counter 和全局 counter 都 +1。
当某条 IP 的 miss count / total_miss > 12.5% 时（文中称作 deliberately modest threshold），标记它为 key IP，并立刻把它送进 Training Unit。
一旦成为 key IP，它后续的 miss 不再累加 total counter，避免人为放大自身重要性（bias mitigation 机制 1）。
PLRU 替换策略让频繁 miss 的指令更容易被保留，即便还没到达阈值（bias mitigation 机制 2）。
当 total miss counter 饱和（9-bit，最大 512），所有 entry 重置，开启新一轮检测 —— 这也是 Kairos 感知程序相位切换的机制。

与 Triangel 的本质差别（图 3）：Triangel 是”先对具体指令的地址序列采样、验证重复率 → 合格才存 metadata”；Kairos 是”先用指令间的 miss 贡献对比快速挑出 key IP → 边产生 metadata 边验证 prefetch 有效性”。

2. Training Method（Coverage-Based Classification，§3.3）

Training Unit：16 entries，每 entry 10-bit IP-tag + 32-bit last address + 8-bit useful prefetch counter + 8-bit miss counter + 2-bit key tag + 15-bit PLRU，共 122 B。

对每条 critical IP，记录 last miss address。当它再次访存时：

若 cache miss 或 “hit & pref”（命中且被预取标签标记），说明可能是 temporal 模式中的一跳。
用 last address 的高位 XOR 本次 line address 的低位构造 set index，低位作 tag，插入 partition cache（LLC 的 metadata 区）。

Coverage-based 分类（图 6）：当 miss counter 饱和时，按 useful_pref / miss 的 coverage rate 分类：

Positive（coverage ≥ 87.5%）：key tag = 1，其生成的 metadata 插入时 replacement bit rpl = 1（LFU 下更不易被驱逐）。
Negative（coverage ≤ 12.5%）：key tag = -1，直接暂停为该指令生成 metadata（避免污染）。
Neutral（其余）：key tag = 0，正常 rpl = 0 插入。

这种三档策略既鼓励验证有效的指令保留得更久，又彻底隔离已确认无效的指令 —— 即图 3 所示 Kairos 的第二步”同时发起 prefetch 并验证其有效性”。

3. Partition Method（PID-based Dynamic Partitioning，§3.4）

Partition Unit（图 7）只有 44 B，用一个 PID 控制器决定 LLC 中划给 metadata 的 way 数。

Stage 1 — Access Tracking：三个 18-bit 计数器 access_counter / miss_counter / useful_pref_counter，access_counter 满（2^18 = 262 144 访问）时进入下一阶段。

Stage 2 — Metric Calculation：

miss_rate = miss_count / access_count
utility = useful_pref_count / access_count
Δmiss_rate = 本窗口 miss_rate − 上一窗口 miss_rate
ΔΔmiss_rate = Δmiss_rate − 上一窗口 Δmiss_rate

PID 输出：

$$\delta_k = \alpha \cdot \text{utility} + \beta \cdot \Delta\text{miss_rate} + \gamma \cdot \Delta\Delta\text{miss_rate}$$

参数 α=1.0, β=-0.3, γ=0.1（作者强调 system-agnostic，基于控制理论推导：P 保证比例响应、I 抑制过度增长、D 抗噪）。

Stage 3 — Decision：

δ_k > θ_plus (0.25) 或 useful 比例超过当前 way 占比 → 增加 metadata way。
δ_k < θ_minus (-0.5) 且当前 miss_rate 超过上窗口 1.2 倍 → 减少 metadata way。
若性能变化 <5% 连续两窗口 → 保持（防止震荡）。

Stage 4 — Resize：每次调整粒度 1 个 way。

这个方案相比 Triage 的 Bloom filter 或 Triangel 的 set-dueller 更简单，纯计数器和轻量算术就能完成。

4. Prefetch Method（§3.5）

在 L2C miss 到来时用当前 miss 地址作为 index 去 partition cache 中做 metadata 查找，并沿着 metadata 关联链一次触发最多 4 个 prefetch（提高 timeliness 同时控制带宽）。

Positive 指令正常发请求；
Negative 指令不发请求；
Neutral 指令保守发 1 个请求；
成功触发的 prefetch 会把对应 metadata entry 的 rpl 提升为 1，延长其生命周期。

5. Hardware Overhead（§3.6）

Component	Entries	Size (B)
Detecting Unit	32	85
Training Unit	16	122
Partitioning Unit	1	44
Total Fixed	—	251

与 Triage（24.14 KiB）、Triangel（17.63 KiB）相比，Kairos 固定硬件开销 251 B ≈ Triangel 的 1.4% —— 两个数量级的降低。Metadata 本身存在 LLC 中，复用缓存存储。

开源代码解读

开源地址：https://github.com/comp-arch-research/Kairos（论文第 2 页脚注给出）

代码位于 prefetcher/croage/（模块被命名为 croage，实现在 croage.h，作为 L2C 的预取器插件集成到 ChampSim）。下文按论文章节对齐梳理代码细节，并指出几处与论文描述不完全一致的地方。

1. 顶层数据流（`croage.cc`）

prefetcher_cache_operate() 是每次 L2C 访问的入口：

仅对 LOAD / RFO 访问生效；将物理地址右移 LOG2_BLOCK_SIZE 得到 line_addr。
维护全局 access_count / miss_count / prefetch_hit_count，每 TRACKING_WINDOW = 2^18 = 262144 次访问触发一次 evaluate_window()（对应论文 Stage 1 的 18-bit access counter）。
依次执行 predict() → train() → 发起 prefetch_line，这三步顺序很重要：先用当前 line 去查 metadata 链，然后再更新训练单元。
predict() 返回的候选经 removeDuplicates 去重后批量发出（最多 max_degree = 4 条，与论文一致）。

2. 关键 IP 检测：`KeyDetect` 类（对应 Detecting Unit）

结构：FIFOCache<KeyDetectEntry>，容量 KD_SIZE = 32（论文表 1 Detecting Unit 32 entries 对应）。
- KeyDetectEntry 字段：pc / issue_count / miss_count（而不是像论文图 5 中的 PLRU + key flag + miss counter）。
update(pc, cache_hit) 逻辑（croage.h:733-758）：
- 若 pc 不在表里，以 miss_count = !cache_hit 插入（FIFO 替换，非论文所写的 PLRU）。
- 若命中：issue_count++，若 miss 则 miss_count++ & total_miss++。
- 判 key IP 的阈值（两者取或）：
  - miss_count * 2 > issue_count（该 IP 自身 miss rate > 50%），或
  - miss_count * 8 > total_miss（该 IP 占总 miss 的 > 12.5%，对应论文的 12.5% 阈值）。
- 当 total_miss > 511 时（对应 9-bit total miss counter 饱和），把还满足 miss_count*8 > total_miss 的 pc 归入 key_pc 集合，然后清零所有 entry 的计数并 total_miss = 0。
与论文的差异：
- 代码额外包含”单 IP miss rate > 50%”这一条件，论文中未明确提及。
- 代码未显式实现论文提到的”成为 key IP 后不再累加 total_miss”以及 PLRU 替换 —— 这是 bias mitigation，两处都只在论文文本里存在，源码里实际上就是 FIFO + 每窗口全量 reset。

3. 训练与 Coverage 分类：`TrainUnit` / `TrainUnitEntry`（对应 Training Unit）

结构：LRUCache<TrainUnitEntry>，容量 TU_SIZE = 16（对应论文表 1 16 entries）。
TrainUnitEntry 字段：pc, last_addr, cur_addr, total_evict(16b), useful_evict(16b), useful_tu(bool), BOP。
- 对应论文图 6 的 “last addr / useful pref counter / miss counter / key tag”，其中 useful_tu 就是 key tag。
训练逻辑（train() 于 croage.h:1224-1269）：
1. 只有 DetectUnit.update(pc, cache_hit) 返回 true（即 pc 是 key IP）时才做后续训练。
2. 若 TrainUnit 里没有该 pc，新建 entry；否则当本次是 miss 或 “useful prefetch hit” 时，把 cur_addr → last_addr，本次地址写入 cur_addr。
3. **每积累 128 次 evict（total_evict == 128）**对该 IP 做 coverage 评估：
  - 若 useful_evict × 16 > total_evict × 15（即 useful ratio > 93.75% ≈ 15/16），设 useful_tu = true；否则 useful_tu = false。
  - 与论文差异：论文用 87.5% 和 12.5% 两档门槛把指令分成 positive / neutral / negative 三类；代码只有 两档（boolean），没有 negative 分支，也不存在”直接暂停 metadata 生成”。
4. 用 last_addr → cur_addr 调用 tem_up() 更新 metadata cache（无论是否跨页）。
5. 训练单元内部也给每 IP 维护一个 BOP（best-offset predictor）副本 —— 但在 predict() 里调用 BOP 的那几行被注释掉了，当前版本的 Kairos 实际上只用 temporal chain 预测，BOP 分支是历史残留/保留接口。

4. Metadata 存储：`CroageRepl<uint64_t>` + `MetaData` 向量

拓扑：MetaData 是 HT_SET = 4096 个 set 的 vector，每个 set 是 CroageRepl 容量 HT_WAY = 48（初始值；partition 动态调整）。
Set index：set_num = (last_addr ^ (last_addr >> 13)) & (HT_SET - 1) —— 论文说”高位 XOR 低位”，代码里具体是 addr ^ (addr >> 13) 哈希后取低 12 位。
替换策略：CroageRepl::popVictim()（croage.h:654-668）实现了一个时钟式 LFU：从尾部往前扫，若 rpl < max_rpl(=3) 则 rpl += 1 并把节点挪到头部、递归继续，直到找到 rpl == max_rpl 的淘汰者。
- set() 插入时，若 useful_tu == true（positive 指令的产出）则把新 entry 的 rpl 初始化为 max_rpl - 1 = 2，而非常规的 max_rpl = 3 —— 这就是论文说的”positive metadata 更不易被驱逐”（rpl=1 的策略在代码里用”降低初始 rpl”的方式体现）。
- get() 命中时 rpl -= 1（下限 0），命中越多越不易被逐。
查询：tem_pre(last_addr)（croage.h:1181-1191）在 set 内按 key（last_addr）查 CroageRepl，命中则返回预测的 cur_addr，并把 in_metadata[last_addr] = true（给统计 useful_entry_number 用）。
预测（predict() 于 croage.h:1271-1300）：从当前 line_addr 开始，串行沿 metadata 链最多走 4 跳（recurrent 展开），产生最多 4 个候选 —— 这符合论文”issues up to 4 prefetch requests via metadata correlation chains”。

5. 动态分区：`evaluate_window()` + `resize_metadata()`

实际的 PID 控制器在 croage.h:1041-1133，计算：

miss_rate    = miss_count / TRACKING_WINDOW
utility      = prefetch_hit_count / miss_count
delta_miss   = (miss_count − previous_miss_count) / access_count
delta_k      = ALPHA·utility + BETA·delta_miss + GAMMA·(delta_miss − previous_delta_miss)

决策（代码里的实际参数，croage.h:840-861）：

参数	代码值	论文值
ALPHA	0.6	1.0
BETA	−0.3	−0.3
GAMMA	0.1	0.1
THETA_PLUS	0.5	0.25
THETA_MINUS	−0.25	−0.5
TAU	1.2	1.2
MAX ways	96	—
MIN ways	12	—
调整步长	12 ways/步	论文写”1 way”

重要：代码与论文在 α、θ_plus、θ_minus 以及 resize 步长上存在明显出入。论文声称每次调 1 个 way，代码里 resize_metadata() 则是 new_size = current ± 12（一次一整个”块”），并通过 llc_cache->set_available_ways(NUM_WAY − occupied_ways)，其中 occupied_ways = current_metadata_size / 12 把 LLC way 划给 metadata。这说明实际的 LLC 共享粒度是以每 12 个 metadata-way 换 1 个 LLC way 的方式实现，而不是论文描述的 1:1。

另外，代码里还加了一个论文没提到的 EMA 平滑（smoothed_miss_rate = EMA_ALPHA·miss_rate + (1-EMA_ALPHA)·smoothed, EMA_ALPHA = 0.7），但当前版本算出来后没有真正参与决策（只维护了状态，没进入 delta_k）。

稳定性约束：若连续 MAX_NO_IMPROVEMENT_WINDOWS = 2 个窗口 miss_rate 改善 < 5%，强制 resize_decision = 0（与论文”连续两个窗口变化 <5% → 保持”一致）。

6. 统计与打印

prefetcher_final_stats() 输出：metadata_hit 次数、当前 metadata way 数、increase/decrease/maintain 决策分布（图 17 所示），以及遍历 in_metadata 统计 useful / useless entry 计数（对应图 11 的 Useful Entry Ratio）。

7. 代码与论文的关键差异汇总

Coverage 分类只有 2 档（≥93.75% 为 positive，其余为 neutral），论文描述的 negative 类（直接暂停 metadata 生成）在代码中不存在。
Coverage 阈值是 15/16 (93.75%)，论文写 87.5% 和 12.5%。
PID 参数：α=0.6 vs 论文 1.0；θ_plus=0.5 vs 0.25；θ_minus=−0.25 vs −0.5。
分区步长：代码是 12-way 一步（通过 occupied/12 折成 LLC way），论文写 1 way 一步。
BOP（best-offset）支路：代码里保留了 IP 级 BOP 和全局 BOP 的结构与训练代码，但 predict() 中的 BOP 预测已注释掉 —— 当前版本是纯 temporal。
Detecting Unit：代码用 FIFO + 每窗口全量 reset，论文写 PLRU + bias-free total miss counter。这两项”bias mitigation”机制在开源版本中未完整实现。
额外阈值：代码里 miss_count*2 > issue_count（单 IP miss rate > 50%）也可直接判定 key IP，论文没提。

这些差异既可能是”论文投稿时 + 最终版之间的迭代差异”，也可能是作者在论文里做了概念化简化而保留了工程上更复杂的实现。使用本开源代码进行对比实验时，应以源码中的实际行为为准。

实验 Setup

实验平台：ChampSim（commit 2ff2501，截至 2025-05-10），trace-driven OoO 模拟器，近似 ARM Cortex X2。

系统设置（表 2）：

Core：3 GHz，8-issue / 8-retire，352-entry ROB，45.2 KiB TAGE
L1D：64 KiB, 4-way, 4 cycles，带 IP-stride 基线预取器
L2C：512 KiB, 16-way, 11 cycles（Kairos 工作在 L2C）
LLC：2 MiB/core, 16-way, 20 cycles（metadata 存在这里）
DRAM：3200 MTPS，4 GiB 单通道单核 / 8 GiB 双通道多核

Workload：

SPEC CPU2006 + SPEC CPU2017 中 LLC MPKI > 3 的内存密集应用；irregular 子集与 Triage 保持一致
CloudSuite（cassandra, classification, cloud9, nutch, streaming）
GAP（图计算）与 SPEC CPU Regular 作为补充
多核：从单核池里随机采样，组成 20 个 4 核 heterogeneous mix，以及多线程 trace

每次仿真 warmup 50M SimPoint + 统计 200M SimPoint。几何平均汇总。

Evaluated prefetchers：SPP, Berti, Triage, Triangel, Kairos。

Energy：CACTI-P（cache）+ Micron DRAM Power Calculator（DRAM），22 nm。

实验结果

实验 1：单核整体性能（图 8）

设计：SPEC CPU Irregular + CloudSuite，对比 5 种预取器。
结果（geomean speedup vs. 纯 IP-stride 基线）：

Triangel：1.15×
Kairos：1.25×（SPEC Irregular）
CloudSuite 上 Kairos geomean 1.073×，仍最高
结论：Kairos 在 irregular 场景平均比 Triangel +10.1%，尤其在 450.soplex, 482.sphinx3, 623.xalancbmk 等具有强 temporal locality 的负载超过 1.5×；在 Triangel 阈值过严导致失效的 471.omnetpp/620.omnetpp 上仍保持较高性能。

实验 2：Coverage 与 Accuracy（图 9, 10）

结果：

Kairos 平均 prefetch coverage 48.8%，比 Triangel 的 ~41.5% 高 17.6%。
Accuracy：Triangel 最高 79.6%，Kairos 68.8%（下降 10.8%），但 coverage 收益足以覆盖 accuracy 损失。
结论：Kairos 有意识地用少量精度换更多 coverage，这是靠”Detection Unit 粗筛 + Coverage 精筛”而非”严格地址级采样”实现的。

实验 3：Metadata Utilization（图 11, 12）

Useful Entry Ratio（图 11）：Triangel 75.8% 最高，Kairos 50.9%（约 Triangel 的 2/3）。
Metadata Hit Rate（图 12）：Kairos 反而高于 Triangel —— 因为 LFU + rpl 策略使 positive 指令的 metadata 被反复命中，转换率更高。

实验 4：Traffic & Energy（图 13, 14）

LLC traffic：Triangel 最低（强过滤），Kairos > Triangel 但 < Triage。
动态能耗相对 baseline：SPP 32.0% > Kairos 30.7% > Berti 29.8% > Triangel 24.5% > Triage 48.1%。
静态漏电：Kairos 最低（因完成工作所需时间最短）。
结论：Kairos 带宽/能量开销略高于 Triangel，但远低于 Triage；综合性能-能量效率最优。

实验 5：多核（图 15）

4-core 20 mixes，Kairos 相对 baseline geomean 1.251× = +25.1%，Triangel 18.7%，Triage 10.2%。

实验 6：SPEC Regular + GAP（图 16）

在规则负载上 Berti（spatial）占优，Kairos 不如 Berti，但Kairos+Berti 组合在 GAP 上 +3.2%，并在 sssp 上表现出明显正交性：Kairos 6.8M useful prefetch @14% accuracy + Berti 4M @57.2% → 组合 10.7M @19.3%，超越线性叠加。

实验 7：PID 分区决策（图 17）

大多数 workload 下 PID 控制器选择 “Maintain”，仅在 miss rate 显著变化或相位切换时才调整，验证了 cautious partitioning 的设计目标。

实验 8：敏感性（图 18）

Detecting Unit / Training Unit 缩小到 0.25× → 性能下降 ~7%；缩小到 0.5× → 仅下降 ~1.5%
放大到 2× / 4× → 性能提升 <1%
说明现有 251 B 配置接近”甜点”。

实验 9：设计选择（图 19）

Kairos_Global（在 Training Unit 里加入 IP-independent 全局关联 miss 表）：性能反而下降 —— 证明”以 key instruction 为焦点”才是性能源头。
Kairos+Berti 合用：irregular 上 Berti 会稀释 Kairos 优势。
Kairos_Infinite（无限 metadata 容量）：整体优，但并非对所有 workload 都显著 —— 说明瓶颈是识别，不是容量。

Limits

阈值是启发式的：12.5% miss 贡献、87.5%/12.5% coverage 分类、PID 参数 α=1.0/β=-0.3/γ=0.1 都靠经验；虽然作者解释为”system-agnostic”，但不同平台是否仍最优未充分验证。
Accuracy 下降 10.8%：虽整体被 coverage 收益覆盖，但在带宽受限系统中可能放大负面影响；论文未深入分析 bandwidth-constrained 场景（例如低主存 BW）。
仅在 ChampSim 上评估：没有 RTL/FPGA 验证，251 B 的面积/时序优势缺乏硬件层面证据。
无法处理 computation-driven 访存：在 GAP 图负载上 Kairos 不敌 Berti，说明 pure temporal correlation 对那些需要针对性优化的访存模式（如 SSSP 里依赖计算结果的访问）天生弱势。
Key IP 数量固定为 16/32 entries：当 workload 的关键指令数超过容量时，虽然 PLRU 可以轮转，但相位切换开销（reset 后要重新累积到阈值）在访存分布极扁平的应用上可能造成暂时性退化。
未覆盖安全/侧信道维度：以指令为粒度记录 miss 行为，可能放大 IP-level 侧信道泄露，论文没讨论。

Kairos (2025 MICRO): Elevating Temporal Prefetching Through Instruction Correlation

背景和动机

相关工作

Insight

核心设计

1. Detecting Method（Critical Instruction Detection，§3.2）

2. Training Method（Coverage-Based Classification，§3.3）

3. Partition Method（PID-based Dynamic Partitioning，§3.4）

4. Prefetch Method（§3.5）

5. Hardware Overhead（§3.6）

开源代码解读

1. 顶层数据流（`croage.cc`）

2. 关键 IP 检测：`KeyDetect` 类（对应 Detecting Unit）

3. 训练与 Coverage 分类：`TrainUnit` / `TrainUnitEntry`（对应 Training Unit）

4. Metadata 存储：`CroageRepl<uint64_t>` + `MetaData` 向量

5. 动态分区：`evaluate_window()` + `resize_metadata()`

6. 统计与打印

7. 代码与论文的关键差异汇总

实验 Setup

实验结果

实验 1：单核整体性能（图 8）

实验 2：Coverage 与 Accuracy（图 9, 10）

实验 3：Metadata Utilization（图 11, 12）

实验 4：Traffic & Energy（图 13, 14）

实验 5：多核（图 15）

实验 6：SPEC Regular + GAP（图 16）

实验 7：PID 分区决策（图 17）

实验 8：敏感性（图 18）

实验 9：设计选择（图 19）

Limits

背景和动机

相关工作

Insight

核心设计

1. Detecting Method（Critical Instruction Detection，§3.2）

2. Training Method（Coverage-Based Classification，§3.3）

3. Partition Method（PID-based Dynamic Partitioning，§3.4）

4. Prefetch Method（§3.5）

5. Hardware Overhead（§3.6）

开源代码解读

1. 顶层数据流（croage.cc）

2. 关键 IP 检测：KeyDetect 类（对应 Detecting Unit）

3. 训练与 Coverage 分类：TrainUnit / TrainUnitEntry（对应 Training Unit）

4. Metadata 存储：CroageRepl<uint64_t> + MetaData 向量

5. 动态分区：evaluate_window() + resize_metadata()

6. 统计与打印

7. 代码与论文的关键差异汇总

实验 Setup

实验结果

实验 1：单核整体性能（图 8）

实验 2：Coverage 与 Accuracy（图 9, 10）

实验 3：Metadata Utilization（图 11, 12）

实验 4：Traffic & Energy（图 13, 14）

实验 5：多核（图 15）

实验 6：SPEC Regular + GAP（图 16）

实验 7：PID 分区决策（图 17）

实验 8：敏感性（图 18）

实验 9：设计选择（图 19）

Limits

1. 顶层数据流（`croage.cc`）

2. 关键 IP 检测：`KeyDetect` 类（对应 Detecting Unit）

3. 训练与 Coverage 分类：`TrainUnit` / `TrainUnitEntry`（对应 Training Unit）

4. Metadata 存储：`CroageRepl<uint64_t>` + `MetaData` 向量

5. 动态分区：`evaluate_window()` + `resize_metadata()`