极客工场

Appearance

共 1,768 字预计阅读约 6 分钟

性能验证：带宽、延迟、QoS、仲裁与性能计数器怎么验 ​

更新时间：2026-09-14。本文是数字验证系列第 15 篇。协议合法由总线 VIP 检查，见 AMBA AXI/AHB/APB 验证平台；本篇回答另一个问题：在合法前提下，系统是否满足性能规格。

一、先把指标定义清楚 ​

指标定义常见坑
带宽 throughput单位时间完成的有效字节数把峰值理论值当平均带宽
延迟 latency请求发出到首数据/完成的周期数不测排队延迟，只测服务延迟
outstanding已发未完成事务数满了但没有信用释放机制
utilizationvalid/ready 有效握手占比busy 高但有效 payload 低
jitter延迟波动实时业务只看平均延迟
fairness各 master 获得服务的比例/等待低优先级永久饿死
QoS miss实时通道超过 deadline没有时间戳和 workload

所有指标必须规定：时钟频率、统计窗口、起止点、缓存/预热是否排除、单位（cycle/ns/MBps）。

二、测量点放在哪里 ​

chip-design/verification/14-performance-verification.md D2 示意图

用户规格一般看端到端 issue→complete；调仲裁时要拆成排队和服务两段，否则无法判断是互联拥塞还是 DDR/从设备慢。

三、流量模型：不能只发整齐 burst ​

模型用途
固定地址/顺序 burst理论峰值、FIFO 数据路径
随机地址cache miss、TLB、DDR row miss
热点区域多 master 竞争同一 slave/bank
长尾突发视频流、网络包、磁盘 DMA
混合 QoSCPU 控制 + DMA 大块 + 实时音视频
背靠背/间歇反压信用、仲裁、FIFO 水位
真实 trace从 Emulator/性能模型/软件 profile 回放

CRV 随机不只随机 payload，还要随机 think cycle、burst len、地址分布、优先级、持续时间、错误注入。

四、UVM 里怎么统计 ​

systemverilog
class perf_txn extends uvm_transaction;
  time t_issue, t_accept, t_first, t_complete;
  int  bytes;
  bit [3:0] qos;
endclass

// monitor 在各握手点记录时间，predictor/subscriber 汇总
function void report_latency(perf_txn t);
  `uvm_info("PERF", $sformatf(
    "issue2comp=%0t queue=%0t bytes=%0d qos=%0d",
    t.t_complete-t.t_issue, t.t_accept-t.t_issue,
    t.bytes, t.qos), UVM_LOW)
endfunction

覆盖率使用 bins，而不仅打印平均值：

  • latency min/avg/p95/p99/max；
  • 带宽窗口分布和持续低于阈值时间；
  • outstanding 0/半满/满；
  • QoS 等级 × slave 负载 × reset/clock-gating；
  • 各 master grant 比例、最大饥饿周期。

五、QoS/仲裁检查 ​

功能正确但性能失败的典型：

  1. DMA 大块传输长期占用，CPU 寄存器访问超时。
  2. Round-robin 在请求持续时看似公平，但实时通道 burst deadline 错过。
  3. 高优先级可抢占但没有限幅，低优先级永久饿死。
  4. FIFO 水位阈值过晚触发反压，导致 underflow。
  5. DDR 访问只按到达顺序调度，row miss 过多。
  6. clock gating 唤醒延迟未计入实时路径。

要分别验证：空载延迟、单 master 峰值、多 master 饱和、混合优先级、异常恢复后的性能恢复。

六、硬件性能计数器校准 ​

RTL 里的 cycle counter、事务计数器、stall counter 是硅后定位的主要眼睛，因此硅前必须证明：

  • 计数器在 overflow 时行为正确；
  • filter（master/slave/op/QoS）与 spec 一致；
  • start/stop/clear 不会丢周期；
  • 计数器读通路在时钟门控、断电域仍可访问；
  • RTL monitor 统计值与硬件计数器一致。

这直接影响回片后是否能定位问题，见 硅后 bring-up 与调试。

七、建立性能回归，而不是只出一次报告 ​

性能验证最容易在项目后期“发现不达标但说不清何时变差”。建议从 RTL 早期就维护一组固定 benchmark：空访问延迟、单主设备峰值、多主设备饱和、DDR 随机访问、视频实时通路、低功耗唤醒后恢复。每个 benchmark 固定频率、地址、cache 状态和随机种子，输出机器可读的 CSV/JSON，而不是只在日志里打印平均值。版本之间比较最小、平均、p95、p99 和最大饥饿周期。

性能失败要按层次归因。若 issue 到 accept 时间变长，问题多半在仲裁、路由、FIFO 反压；accept 到 first data 变长，问题可能在从设备、DDR 调度或外部存储；若只在低电压或 DVFS 档位出现，还要加入时钟切换和唤醒延迟。定位时用硬件计数器与 TB monitor 对账，确认不是测量点定义错误。任何微架构优化，例如增大 outstanding、改仲裁权重、调整 burst 合并，都应跑同一组 benchmark，防止一个场景变好、另一个实时通道被饿死。

八、把系统负载变成可复现实验 ​

真实软件流量很难直接复现，因此应从 Emulator、FPGA 或性能模型采样 trace，再转换成总线 sequence。Trace 至少包含时间戳、主设备、读写、地址、长度、ID/QoS 和依赖关系。回放时要区分“精确时间回放”和“保持依赖回放”：前者用于复现拥塞窗口，后者用于探索不同仲裁策略。只回放地址而丢弃 think time，往往会得到比真实系统恶劣得多的流量；只保持平均速率而不保留突发，又会掩盖 FIFO underflow。

最终签核报告应说明 workload 的代表性：它覆盖了 boot、稳态、突发、异常恢复和热/电源状态迁移。对实时通路，不允许只报平均吞吐，必须证明在最坏服务时间、最大抖动和唤醒延迟同时发生时仍不丢数据。这样性能指标才能从验证团队的图表，变成架构和软件团队可依赖的硬件契约。

Checklist ​

  • [ ] 每个关键路径有带宽、平均/尾延迟、jitter 的量化规格。
  • [ ] 统计起止点和 workload 在 spec/testplan 中明确。
  • [ ] 覆盖空载、峰值、热点、混合 QoS、长期饱和。
  • [ ] 记录 p95/p99/max starvation，不只看平均值。
  • [ ] 性能计数器与 TB monitor 结果对账。
  • [ ] 性能失败可回溯到仲裁、FIFO、DDR、时钟/电源策略。
  • [ ] 性能结果附频率、电压、工艺角和配置版本。

相关与延伸 ​

DVFS 对性能的影响见 DVFS 与电压频率缩放；长系统流量可放到 Emulator/FPGA 原型平台。

总结 ​

性能验证要把“感觉不慢”变成可回归的指标：用真实流量模型压出端到端带宽和尾延迟，拆分排队与服务时间，验证 QoS 公平性和硬件计数器；平均值好看但 p99 超时，在实时系统里就是失败。