解读

面试官问“怎么估算验证进度”，并不是想听“大概三个月”这种拍脑袋数字，而是考察候选人能否把“验证收敛”这件事量化、可追踪、可落地。国内项目普遍周期紧、人力少，流片窗口一旦错过就是百万级成本，因此进度估算必须兼顾“技术深度”和“管理可见性”。回答时要体现三层能力：

1. 能把“验证工作”拆成可量化单元；
2. 能用历史数据+工具链把“量化单元”转成“人/周”数字；
3. 能在项目执行阶段用闭环指标持续校正估算偏差。

知识点

1. 验证任务拆解技术

   • 功能点清单（Feature List）→ 场景点（Scenario Point）→ 覆盖点（Cover Point）三级拆解，颗粒度到“单条covergroup可闭合”。
   • 用“验证需求追踪矩阵（VRM）”把每条feature映射到test、assertion、covergroup，确保拆解无遗漏。

2. 规模度量模型

   • Testcase Point（TCP）：给每条testcase打权值，权重=复杂度×场景深度×调试难度，历史项目校准后得到“单人日/TCP”。
   • Coverage Point Velocity（CPV）：统计“每周新增covergroup命中数”，建立“人/周”基线。
   • 断言密度法：RTL千行代码断言数≥20条时，形式验证收敛周期≈0.6×仿真周期，可提前折算人力。

3. 回归收敛曲线（Regression Burn-down）

   • 用 nightly regression 的“fail count / total test”画指数衰减拟合，R²≥0.9 时预测剩余收敛周期误差<10%。

4. 风险缓冲模型

   • 采用“三点估算”（乐观/最可能/悲观），给每条feature加1.3×标准差缓冲，国内项目普遍取1.5×以应对需求漂移。

5. 国内常用工具链

   • 任务管理：Jira + 自研验证看板插件，字段必须包含“TCP、CPV、阻塞原因、预计close日期”。
   • 数据抓取：CI nightly 调用Python脚本解析UCIS + SQLite，自动更新TCP、CPV。
   • 校正会议：每周“验证度量例会”，用燃尽图对比计划/实际，偏差>15%即触发重新估算。

答案

验证进度估算我采用“三步量化+闭环校正”方法，已在三个28 nm/16 nm SoC项目中落地，误差控制在±7%以内。
第一步，需求拆解：
把设计规格逐条导入VRM，拆出feature→scenario→covergroup，确保每条feature可追踪到至少一条covergroup。以最近一颗AI加速器为例，共拆出410条feature、2380个scenario、1.1万条covergroup。

第二步，规模度量：

1. 用历史基线给每条testcase打TCP权值，例如“单精度浮点异常处理”场景复杂度8，调试系数1.5，TCP=12。项目总TCP=1.24万。
2. 根据团队历史速度（人均每周关闭85 TCP），得出“纯 testcase 阶段”需12400/85≈146人/周。
3. 再用covergroup维度做交叉校验：团队历史CPV=650/人/周，1.1万covergroup需17人/周；两者差异<10%，取高值146人/周作为初始预算。

第三步，回归收敛与缓冲：
建立 nightly regression 后，每天记录fail count，用指数衰减模型拟合。经验表明当fail数降到初始5%且连续3天零新增fail，即可进入sign-off。若模型预测还需18天，则把18天×团队规模加入总进度。同时给每条feature加1.5×风险系数，最终输出“22周±1周”的sign-off窗口。

执行阶段，每周例会对比实际TCP关闭速率与计划，若偏差>15%，立即用蒙特卡洛重新跑5000次仿真，更新交付区间，并同步给项目经理和PD。通过该流程，三颗芯片均一次流片成功，无功能ECO。

拓展思考

1. 当项目采用硬件加速（Palladium/Zebu）时，可把“长周期随机场景”从仿真域移到加速域，TCP权值需乘0.3~0.4，但引入“编译-迭代”额外开销，需在估算里单独列“compile week”。
2. 对于RISC-V等开源IP，若缺乏历史基线，可先用“同类ARM A55项目”数据做类比估算，并在Sprint 0跑两周探针回归，用实测速度重新校准TCP/CPV。
3. 在国内普遍存在的“需求并行开发”场景，建议把验证估算拆成“增量交付”里程碑，每个milestone输出“可回归版本+覆盖率报告”，避免到最后阶段才发现结构性缺陷导致进度雪崩。