HN-F Snoop Filter 性能数学建模与分析

模型说明：本模型以单 Slice 覆盖率 $R_{\text{cover}}=C_{\text{SF,slice}}/C_{\text{L2}}$ 为自变量，所有性能量（溢出率、Miss 比例、延时、单核 IPC、相对衰减）均由此决定；核数 $N_{\text{core}}$ 仅作为整机总容量与 Aggregate IPC 的线性缩放因子出现。下文图表与结论均以单 Slice / 单核归一化量给出，对任意核数体系成立。

1. 架构背景与物理传导链

1.1. HN-F 体系结构概述

在基于 AMBA CHI (Coherent Hub Interface) 协议的 $N_{\text{core}}$ 核服务器 CPU 中，全局一致性由 HN-F (Home Node - Fully Coherent) 网格节点共同维护。系统包含 $N_{\text{core}}$ 个 Compute Tile（各含 1 个 Core 及 $C_{\text{L2}}$ L2 Cache）与 $N_{\text{core}}$ 个 HN-F Slice（各含 L3 Cache 与集成 Snoop Filter），1 个 Core 严格对应 1 个 HN-F Slice。

Snoop Filter (SF) 记录所有 RN-F (Request Node) 内部 L2 Cache 行的存在状态。为了保证一致性目录不出现假阴性，SF 必须维持严格的 Inclusive（包含）或 Filter 包含属性。

主控变量——覆盖率 $R_{\text{cover}}$：由于“1 Core ↔ 1 HN-F Slice”的一一映射，单个 Slice 的 SF 容量 $C_{\text{SF,slice}}$ 与其服务的单核 L2 容量 $C_{\text{L2}}$ 之比

$$R_{\text{cover}} \;=\; \frac{C_{\text{SF,slice}}}{C_{\text{L2}}}$$

是一个局部比值，也是本模型唯一的容量自变量。

1.2. Snoop Filter 替换与 Back-Invalidation 触发机制

当某个 RN-F 发生 L2 Cache Miss 并向 HN-F 发起 Read 请求时，若映射到的 SF Set 已满（16-way 关联度达上限），SF 必须强制淘汰一个现有表项。为保证一致性，HN-F 必须向持有该行的数据节点广播 Back-Invalidation（反向无效化） 报文。

1.3. 非线性物理瓶颈传导链条

当 Snoop Filter 容量不足或产生 Hash 碰撞时，性能降级的传导过程如下：

1. Hash 交织打散 (Hash Interleaving)：通过 XOR/H3 散列算法将访存地址均匀打散至全部 HN-F Slice，使每个 Slice 统计特性相同、大幅平化空间倾斜（倾斜因子从 $\theta_{\text{zipf}}=2.2$ 降低至 $\theta_{\text{zipf}}=1.08$）。

2. 死数据淘汰折扣 (Dead Line Discount)：被淘汰的 Cache Line 有高达 $P_{\text{dead}} = 60\%$ 的概率为不再使用的“死行”，这部分无效化不会产生后续二次 Miss。

3. HN-F SRAM 端口结构性冲突 ($L_{\text{sram\_stall}}$)：高频的 Back-Invalidation 导致 HN-F Tag 阵列发生 RMW (Read-Modify-Write) 端口阻塞。

4. DRAM M/M/1 带宽饱和 ($L_{\text{dram\_eff}}$)：Back-Inv Induced Miss 叠加原始 Miss 使得内存控制器利用率 $\rho \to 0.92$，DRAM 排队延迟呈指数级增高。

5. Core MSHR 挂起 (MSHR Freeze Multiplier)：Hot-Line 误杀引发 Core 乱序执行引擎（ROB）顶端阻塞，导致 IPC 非线性剧烈衰减。

2. 数学模型深度推导与公式详解

2.1. 泊松组相联溢出概率模型推导

在 $W$-way（$W=16$）组相联的 Snoop Filter 中，假设地址经由 Hash 交织打散后映射到各个 Set。单个 Set 接收到的 Line 数量 $X$ 服从参数为 $\lambda$ 的泊松分布：

到达强度 $\lambda$ 的计算公式为：

当映射到某一 Set 的行数 $k > W$ 时，超过相联度上限的 $k - W$ 个行必须被逐出 SF 目录，引发 Back-Invalidation。每个 Set 的期望溢出行数 $E[\text{Overflow}]$ 定义为对 $k > W$ 部分的尾部求和：

由于泊松分布的全概率公式与一阶矩公式：

将一阶矩拆分为 $k \le W$ 与 $k > W$ 两个区间：

同理，对常数 $W$ 拆分：

用一阶矩式减去常数拆分式：

由此解得尾部求和项 $E[\text{Overflow}]$：

展开 $P(X = k)$，归一化得到单 Set 的期望溢出比例 $P_{\text{overflow}}(\lambda)$：

图 1：组相联 SF 的泊松溢出尾部。左 $R_{\text{cover}}=2.0\times$（λ=11.7）时仅 1.7% 的行落入 $k>W=16$ 的强制淘汰尾部；右 $R_{\text{cover}}=1.0\times$（λ=23.3）时该比例升至 31.8%——覆盖率不足时溢出率急剧上升。

2.2. 二次 Miss、扇出效应与死数据折扣推导

由 SF 溢出引起的二次 Miss 总数 $M_{\text{back\_inv}}$ 表达为：

其中 $\mu_{\text{fanout\_miss}} = 2.8$ 为多核扇出与重加载放大系数。

总 Miss 数量 $M_{\text{total}}$ 与 Back-Invalidation 产生 Miss 的占比 $r_{\text{back\_inv}}$ 为：

引入 死数据淘汰折扣率 ($P_{\text{dead}} = 60\%$)。在典型的程序执行周期中，被 LRU/PLRU 踢出的 Cache Line 有 $60\%$ 属于不再被访问的“死行”（Dead Line）。真正的“热数据误杀率 ($r_{\text{hot\_inv}}$)”为：

向 RN-F 实际发送的 Snoop 报文总数 $N_{\text{back\_inv\_sent}}$ 考虑多核共享扇出因子：

图 2：Back-Inv 误杀占比 vs 覆盖率。蓝线为目录淘汰引起的总误杀占比；橙线为扣除 60% 死行折扣后的真正热行误杀率，阴影区即被折扣掉的死行部分。

2.3. HN-F SRAM Tag 阵列端口结构性冲突推导

高频的 Snoop 目录更新导致 HN-F 内部 Tag/Data SRAM 阵列频繁发生 RMW (Read-Modify-Write) 读写冲突。设端口利用率为 $U_{\text{sram}}$：

利用 M/G/1 排队论非线性近似模型，SRAM 端口阻塞带来的额外延时惩罚 $L_{\text{sram\_stall}}$ 为：

其中 $\alpha_{\text{sram}} = 25.0$ 为端口冲突延时基数。

2.4. DRAM M/M/1 排队模型与 Core MSHR 冻结推导

DRAM 存储控制器服务利用率 $\rho$ 受突发因子 $\beta_{\text{burst}}$ 调制：

根据 M/M/1 排队论，有效 DRAM 访存延迟 $L_{\text{dram\_eff}}$ 为：

NoC 争用延迟 $L_{\text{noc\_snoop}}$ 表达为：

Core 端 MSHR (Miss Status Holding Register) 冻结乘数 $F_{\text{mshr}}$ 由热行误杀率 $r_{\text{hot\_inv}}$ 驱动：

其中 $\gamma_{\text{mshr}} = 4.5$。

图 3：三路延时瓶颈分解（对数轴）。$R_{\text{cover}}<1.5\times$ 时 SRAM 端口冲突（蓝）封顶主导；$1.5\times$ 后冲突解封、延时断崖式下降，DRAM 排队（橙）转为主导项。

2.5. 综合 AMAT、单核 IPC 与整机 Aggregate IPC（线性缩放）

整体 Miss 延时与加权平均 Miss 惩罚 $\text{Penalty}_{\text{avg}}$ 为：

单核有效 Stall 周期 $\text{Stall}_{\text{eff}}$：

单核有效 IPC：

整机 Aggregate IPC 为单核 IPC 的线性缩放：

3. 模型参数全局汇总表与物理选值理由

下表汇总了性能模型中用到的全部关键参数、其数值、物理含义以及在高性能 CPU 架构设计中的校准与选值理由：

归一化说明：仿真中的 $M_{\text{raw}}$、$N_{\text{access}}$、$C_{\text{dram\_threshold}}$ 均为单个 HN-F Slice 归一化的局部工作负载常量。Hash 交织将全局足迹均匀打散到所有 Slice，每个 Slice 统计特性相同。

4. Python 行为级仿真器实现

以下 Python 仿真器包含 Hash 交织打散、时间突发因子、死数据折扣及 SRAM 端口冲突计算：

import math

class HNF_SnoopFilter_Simulator_v5:
    """
    HN-F Snoop Filter v5.0 行为级仿真器
    以单 Slice 覆盖率 R_cover 为自变量；num_cores 仅用于整机总容量
    与 Aggregate IPC 的线性缩放。与 HTML Dashboard 算式逻辑 100% 精准对齐。
    """
    def __init__(self, num_cores=48, l2_per_core_mb=1.0, assoc_w=16,
                 zipf_factor=1.08, burst_factor=1.35, p_dead=60.0,
                 mshr_factor=4.5, sram_factor=25.0, shared_ratio=35.0,
                 dram_base_lat=200.0, base_ipc_per_core=2.0):
        self.num_cores = num_cores
        self.l2_per_core_mb = l2_per_core_mb
        self.assoc_w = assoc_w
        self.zipf_factor = zipf_factor
        self.burst_factor = burst_factor
        self.p_dead = p_dead
        self.mshr_factor = mshr_factor
        self.sram_factor = sram_factor
        self.shared_ratio = shared_ratio
        self.dram_base_lat = dram_base_lat
        self.base_ipc_per_core = base_ipc_per_core

    def poisson_overflow_rate(self, r_cover):
        lambda_val = (self.assoc_w / max(0.01, r_cover)) * self.zipf_factor * self.burst_factor
        if lambda_val > 300:
            return max(0.0, (lambda_val - self.assoc_w) / lambda_val)
        
        p0 = math.exp(-lambda_val)
        sum_term = self.assoc_w * p0
        current_p = p0
        for k in range(1, self.assoc_w + 1):
            current_p = (current_p * lambda_val) / k
            sum_term += (self.assoc_w - k) * current_p
        
        expected_overflow = lambda_val - self.assoc_w + sum_term
        return max(0.0, expected_overflow / lambda_val)

    def run_sweep_point(self, sf_per_slice_mb):
        total_sf_mb = sf_per_slice_mb * self.num_cores  # 整机总容量输出
        r_cover = sf_per_slice_mb / self.l2_per_core_mb

        # 单 Slice 归一化的局部工作负载常量
        raw_misses = 35000
        total_accesses = 1440000

        overflow_rate = self.poisson_overflow_rate(r_cover)
        back_inv_misses = round(raw_misses * overflow_rate * 2.8)

        total_misses = raw_misses + back_inv_misses
        back_inv_ratio = back_inv_misses / max(1, total_misses)

        p_dead_ratio = self.p_dead / 100.0
        hot_inv_ratio = back_inv_ratio * (1.0 - p_dead_ratio)

        fanout_factor = 1.0 + (self.shared_ratio / 100.0) * 2.2
        back_inv_sent = round(back_inv_misses * fanout_factor)

        dram_capacity_threshold = 140000
        effective_misses_dram = total_misses * self.burst_factor
        rho = min(0.92, effective_misses_dram / dram_capacity_threshold)
        dram_latency_effective = self.dram_base_lat * (1.0 + (rho / (1.0 - rho)))

        snoop_load_factor = back_inv_sent / (total_accesses * 0.015)
        snoop_penalty_effective = 35.0 * (1.0 + 1.8 * (snoop_load_factor ** 2.2))

        sram_port_util = min(0.90, (back_inv_sent * 1.5) / (total_accesses * 0.02))
        sram_stall_penalty = self.sram_factor * ((sram_port_util / (1.0 - sram_port_util)) ** 1.8)

        mshr_stall_multiplier = 1.0 + self.mshr_factor * (hot_inv_ratio ** 1.4)

        total_miss_lat = dram_latency_effective + snoop_penalty_effective + sram_stall_penalty
        avg_miss_penalty = (180.0 * raw_misses + total_miss_lat * back_inv_misses) / max(1, total_misses)
        miss_rate = total_misses / total_accesses
        effective_stall_cycles = miss_rate * avg_miss_penalty * mshr_stall_multiplier
        core_ipc = self.base_ipc_per_core / (1.0 + (self.base_ipc_per_core * effective_stall_cycles / 10.5))
        aggregate_ipc = core_ipc * self.num_cores

        return {
            "sf_per_slice_mb": sf_per_slice_mb,
            "total_sf_mb": total_sf_mb,
            "r_cover": r_cover,
            "back_inv_misses": back_inv_misses,
            "back_inv_ratio": back_inv_ratio,
            "sram_stall_penalty": sram_stall_penalty,
            "dram_latency_effective": dram_latency_effective,
            "core_ipc": core_ipc,
            "aggregate_ipc": aggregate_ipc
        }

if __name__ == "__main__":
    # 以单核 IPC 为基准计算衰减
    sim = HNF_SnoopFilter_Simulator_v5()
    sweep_points = [round(0.10 * i, 2) for i in range(1, 21)]
    baseline_core_ipc = sim.run_sweep_point(2.00)["core_ipc"]

    print(f"{'Slice MB':<10} | {'R_cover':<8} | {'Back-Inv Miss':<13} | {'Ratio':<7} | {'SRAM Stall':<10} | {'DRAM Lat':<10} | {'CoreIPC':<8} | {'Degradation':<11}")
    print("-" * 100)
    for pt in sweep_points:
        res = sim.run_sweep_point(pt)
        deg = ((baseline_core_ipc - res['core_ipc']) / baseline_core_ipc) * 100.0
        print(f"{res['sf_per_slice_mb']:<10.2f} | {res['r_cover']:<8.2f}x | {res['back_inv_misses']:<13,d} | {res['back_inv_ratio']*100:<6.1f}% | {res['sram_stall_penalty']:<10.1f} | {res['dram_latency_effective']:<10.1f} | {res['core_ipc']:<8.4f} | -{deg:<10.1f}%")

5. Hash 交织下的仿真结果与数据分析

以下为单 Slice / 单核归一化结果；整机量按 $N_{\text{core}}$ 线性缩放（总容量 $=N_{\text{core}}\times$ 单 Slice 容量，Aggregate IPC $=\text{IPC}_{\text{core}}\times N_{\text{core}}$）。

引入 Hash 交织（$\theta_{\text{zipf}} = 1.08$）与突发/死数据折扣后 0.10× 高颗粒度精细扫频数据 如下：

图 4：单核性能 vs 覆盖率。上为单核 IPC，下为相对性能衰减；背景色带为四档运行状态（抖动瘫痪 / 显著瓶颈 / 轻度衰减 / 安全），虚线为 1.2× 容量警戒线，绿点线标出 1.6×–1.8× 的 PPA 黄金区。

5.1. 细颗粒度扫描核心发现：

1. 拐点响应区 ($1.30\times \to 1.80\times$)：在该维度下，从 $1.30\times$ 增加到 $1.80\times$ 时，随着 SRAM 端口冲突与 DRAM 排队压力同步纾解，IPC 呈现陡峭上升 F 趋势。

2. 容量保护界限：当 $R_{\text{cover}} < 1.20\times$ 时，SRAM 端口利用率封顶、DRAM 流量迅速逼近饱和，单核性能损失扩大至 -78% 以上。

3. PPA 黄金推荐点：综合考虑硬件 SRAM 面积开销与容量边际收益，选型推荐落在 $1.60\times \sim 1.80\times$ 覆盖率；其中 $\geq 1.7\times$ 时单核性能衰减已收敛至 10% 以内。

6. PPA 硬件架构设计建议与选型总结

6.1. 选型黄金区间建议

基于 Hash 交织打散与精细建模分析，对于任意核数的服务器架构（$R_{\text{cover}}$ 是唯一选型维度；整机容量按 $N_{\text{core}}$ 缩放，括号内为 $N_{\text{core}}=48$ 示例）：

• 最佳 PPA 选型：单 Slice 配置 1.60MB ~ 1.80MB Snoop Filter（$N_{\text{core}}=48$ 时整机 76.8MB ~ 86.4MB），即 $R_{\text{cover}} = 1.60\times \sim 1.80\times$。这能在节约 10%~20% SF SRAM 硅片面积的同时，将性能损失控制在很轻微的范围内。

• 危险警戒区：严禁配置 $R_{\text{cover}} < 1.20\times$。一旦跌破 $1.20\times$，SRAM Tag 端口冲突与 DRAM M/M/1 队列将发生排队雪崩，单核 IPC 降幅将超过 -78%。