2. Xcelium仿真性能度量体系
在性能回归与仿真加速工程中，最忌讳的一句话是“感觉变快了”。要让优化可复现、可比较、可验收，必须先把“快”拆解成一组可采集、可对比、可归因的量化指标。Xcelium 的性能度量体系通常围绕五个维度展开：编译时间、仿真速度、内存占用、CPU 利用率与回归通过率。前四者刻画“跑得多快、多省”，最后一个刻画“跑得对不对”——脱离通过率的加速没有工程意义。
五个核心指标的定义与采集口径
指标本身不难理解，难的是口径统一。同一份设计，用不同命令、不同统计窗口采集，结果可能相差数倍。因此每个指标都要固定“采集什么、从哪里取、以什么为分母”。
| 指标 | 定义 | 典型采集来源 | 单位/口径 |
|---|---|---|---|
| 编译时间 | 从启动 xrun 到 elaboration 完成、可进入仿真 | xrun 日志时间戳、-elaborate 阶段耗时 | 秒（s），区分单次/增量 |
| 仿真速度 | 单位时间内推进的仿真时间 | 仿真结束报告、$finish 前后时间差 | ns/s 或 仿真时间/墙钟时间 |
| 内存占用 | 仿真进程峰值物理内存 | /usr/bin/time -v、ps 采样、Xcelium 内存报告 | MB / GB（峰值 RSS） |
| CPU 利用率 | 进程占用 CPU 时间与墙钟时间之比 | time 输出 user+sys、top 采样 | 百分比，可大于 100%（多线程） |
| 回归通过率 | 通过用例数 / 总用例数 | 回归报告、xrun 退出码、UVM 报告 | 百分比 |
需要特别强调两个口径问题。第一，仿真速度的分母是墙钟时间而非 CPU 时间，否则多线程优化会被误判。第二，内存要取峰值 RSS 而非平均值，因为仿真崩溃往往发生在内存峰值时刻，平均值会掩盖风险。
指标之间的耦合关系
这五个指标不是孤立的，它们之间存在明显的相互制约。下图展示了各指标在仿真流程中的位置及其耦合方向：编译时间与内存占用共同决定“启动成本”，仿真速度与 CPU 利用率共同决定“运行效率”，而回归通过率是最终约束——任何加速手段若导致通过率下降，都必须回退。
采集实操：从命令行到日志
指标采集要落到具体命令上。以下是一段可直接参考的采集方式，用 /usr/bin/time -v 包裹 xrun，同时捕获墙钟、CPU 与峰值内存：
/usr/bin/time -v xrun -f run.f -l sim.log 2> time.log
# 从 time.log 提取关键字段
grep -E "Elapsed|User time|System time|Maximum resident" time.log
# 从 sim.log 提取仿真时间推进量
grep -E "Simulation time|\\$finish" sim.log假设某次回归的采集结果为：编译 420 s、仿真推进 2.4 ms 仿真时间、墙钟 600 s、峰值 RSS 6.8 GB、user+sys 合计 540 s。则可计算：仿真速度 = 2.4 ms / 600 s ≈ 4.0 ns/s；CPU 利用率 = 540 / 600 = 90%（单线程场景下说明存在约 10% 的 I/O 或等待开销）。若该用例在 8 线程下 user+sys 达到 3200 s，则利用率约 533%，说明多线程确实在并行工作，此时仿真速度的提升才有依据。
-mce/-j 参数下不可直接横向比较。指标解读：从数字到归因
拿到数字只是第一步，解读才是价值所在。常见的判读逻辑如下：
- 编译时间突增：优先检查是否触发了全量重编译（增量编译失效）、是否新增了大量
include或宏展开，而非直接归因于机器变慢。 - 仿真速度下降但 CPU 利用率同步下降：典型信号是 I/O 瓶颈或内存换页，应检查峰值 RSS 是否逼近物理内存上限。
- CPU 利用率高但仿真速度不涨：可能是多线程争用、锁竞争或调试波形（如
-access +rwc）带来的额外开销。 - 通过率下降：无论速度提升多少，都必须先定位是编译选项、时序约束还是测试平台改动导致，不能以“加速”为由放行。
建立基线：让指标可比较
单次采集没有意义，必须建立性能基线。建议对每个回归套件固定一组基线参数：同一 Xcelium 版本、同一编译选项、同一机器配置、同一随机种子。每次回归后将五项指标写入统一记录，形成趋势。判断标准可以量化为：仿真速度波动超过 ±5%、峰值内存超过 ±10%、通过率低于 100% 时触发告警。这样，性能回归才从“凭感觉”变成“看数据”，后续的加速手段也才有明确的验收依据。