解读

面试官问“如何定义和跟踪验证项目的关键指标”，并不是想听背诵“覆盖率”三个字，而是考察三件事：

1. 能否把“验证目标”翻译成可量化、可落地的指标；
2. 能否在国产芯片“短周期、低成本、一次流片成功”的现实压力下，挑出对 sign-off 真正致命的指标；
3. 能否用国内项目常用的管理链（需求→计划→日报→周报→评审→验收）把指标闭环，让设计、验证、后端、项目经理、客户都能一眼看懂。
   因此，回答必须体现“指标分层、数据自动采集、风险预警、国产工具链适配”四个维度，否则会被认为“纸上谈兵”。

知识点

1. 指标三维分层：
   ① 需求层（feature list、协议条目、性能规格）；
   ② 量化层（功能覆盖率、代码覆盖率、断言覆盖率、时钟/功耗/性能向量、bug 曲线、收敛率）；
   ③ sign-off 层（零 high-priority bug、覆盖率≥阈值、静态/形式验证无 waiver、CDC/RDC 清洁、ECO 回归全通）。
2. 国内常用阈值：
   代码覆盖率 95 %（排除 unreachable）、功能覆盖率 100 %（cover_group 命中 90 %以上）、assertion 覆盖率 100 %、bug 发现峰值在 70 % 时间节点前出现、后 30 % 时间 high-priority bug 必须清零。
3. 跟踪工具链：
   版本管理 GitLab + 国产飞书OKR；自动化回归 Jenkins + 自研 Python 调度；数据可视化 Grafana + 飞书多维表格；缺陷管理 PingCode/禅道；覆盖率合并使用 Verdi/Synopsys URG，国产替代可用“芯华章”或“鸿芯”平台。
4. 预警机制：
   覆盖率日增 < 1 % 连续 3 天自动飞书报警；high-priority bug 超过 5 个未清零触发“红会”评审；回归失败用例数 > 3 直接 block 次日代码合并。
5. 交付物：
   验证计划 V1.0→V3.0、覆盖率报告、bug 趋势图、 waiver 清单、风险登记表、 sign-off checklist，全部归档到国产 PLM 系统，以备客户稽核和后续车规/安规认证。

答案

“我会把关键指标拆成‘需求—量化—sign-off’三层，并在项目第一天就写进验证计划，用飞书OKR 做任务分解，保证人人可跟踪。
第一步，需求层：把设计 spec 拆成 400 条 feature，每条写进 Jira 子任务，挂到对应 covergroup，做到‘一条需求至少一个 coverpoint’。
第二步，量化层：

1. 覆盖率——代码行覆盖率≥95 %，分支覆盖率≥90 %，FSM 覆盖率 100 %，功能覆盖率用 covergroup 命中≥90 % 视为通过；
2. bug 曲线——用 PingCode 记录，要求前 8 周发现 ≥70 % 的 bug，high-priority bug 在流片前 4 周清零；
3. 性能/功耗向量——在 Palladium 或 Z1 国产加速器跑 1000 条实际业务场景，帧率、带宽、动态功耗误差 < 5 %；
4. 回归稳定性——Jenkins 每晚触发全量回归，失败用例次日 10:00 前清零，否则自动发飞书群报警并 block 代码合并。
   第三步，sign-off 层：零 high-priority & zero-day bug，覆盖率报告合并后无 < 95 % 模块，CDC/RDC 清洁，形式验证无 waiver，ECO 回归全通，最后由项目经理、设计负责人、验证负责人三方签字，PDF 报告上传 PLM，才算验证闭环。
   整个流程用 Grafana 做仪表盘，每日自动刷新，项目组成员早上 9 点飞书群收到‘验证日报’，一眼看出哪项指标亮红灯，立即针对性攻关，确保一次流片成功。”

拓展思考

1. 车规/安规场景下，指标阈值如何加严？——可引入“百万小时故障率（FIT）”反向推导，要求断言密度 ≥ 1 条/百行 RTL，并增加故障注入指标。
2. 面对‘小芯片、大 IP’的复用模式，如何防止指标虚高？——需引入“有效覆盖率”概念，用‘特征权重×覆盖命中’再归一化，避免大量冗余 coverpoint 刷分。
3. 国产 EDA 工具覆盖率数据库格式不兼容怎么办？——可写 Python 脚本转 UCIS 标准，再用开源工具 gcov-style 合并，保证数据一致性，避免被国外工具“卡脖子”。