解读

面试官抛出此题，核心意图是判断候选人是否具备“从项目全局视角拆解验证任务”的能力，而不仅仅是会写UVM代码。国内一线芯片公司（海思、平头哥、兆易、地平线等）普遍把“验证计划”视为项目里程碑文档，其质量直接影响schedule、人力、流片窗口。回答时要体现：①对芯片生命周期的理解；②对国内项目节奏（6-9个月交付、多site协同、后端窗口刚性）的适配；③对潜在风险的量化思维。回答结构建议“自顶向下”：先业务目标，再技术拆解，最后量化指标与风险闭环。

知识点

1. 需求分层：市场MRD → 架构SPEC → RTL功能点 → 验证特性（feature list），每一层都要可追踪。
2. 覆盖率模型：代码覆盖、功能覆盖、断言覆盖、场景覆盖、性能覆盖、功耗覆盖（国内先进节点已要求UPF 3.0功耗验证）。
3. 验证方法学：UVM、形式验证（Formal）、硬件仿真（Palladium/Zebu)、FPGA原型、后仿（SDF）、Gate-Level Simulation（国内对GLS有强制sign-off要求）。
4. 质量门禁：0 DRC、100% 功能覆盖+断言覆盖、≥95% 代码覆盖（exclude需评审）、X-prop clean、CDC/RDC clean、低功耗检查（CLP/VC-LP）通过。
5. 风险量化：用“未验证功能点 × 概率 × 影响”算风险值，≥阈值必须加case或加formal。
6. 国内特色：
   • 多site协同（上海/深圳/西安/成都），计划里要留“同步评审”与“版本冻结”窗口；
   • 流片窗口硬约束（TSMC 5nm/7nm slot一旦错过就是三个月），计划必须设“tape-ready”检查点；
   • 国产化替代需求，计划里要单列“兼容寄存器”与“IP替换”回归项。

答案

制定验证计划时，我会从以下八个维度系统拆解，每个维度都给出量化指标与责任人，确保计划可执行、可评审、可追踪：

1. 需求澄清与特性拆分
   对照最新版《设计规格说明书》与《协议文档》，用“需求追踪矩阵”将每一条需求映射到可测量的feature，颗粒度≤1人日。对任何TBD或“可选特性”，在计划里标红并设最后确认日期，避免后期scope creep。

2. 验证策略与平台选型
   根据IP复杂度与复用度选择方法：

   • 控制通路+寄存器：UVM+Formal联合，用Formal做穷举，UVM做性能回环；
   • 数据通路>1 GHz：用硬件仿真跑真实流量，提前在后端网表阶段就带SDF跑“性能模式”；
   • 低功耗场景：用UPF 3.0在Palladium上跑power-aware，确保island切换与retention无死锁。
     在计划里用“方法学决策表”固化，避免后期平台返工。

3. 覆盖率目标与验收标准
   代码覆盖≥95%（exclude须三人评审签字），功能覆盖100%（covergroup由设计、验证、架构三方review），断言覆盖100%（含OVL/SystemVerilog assert），性能覆盖定义“带宽≥理论值90%且延迟≤spec 110%”，功耗覆盖定义“peak power ≤ 1.2×预算”。所有指标在计划里设“阶梯达成曲线”，每周自动跑回归并邮件推送偏差。

4. 测试用例分层与优先级
   L0：冒烟（build+基本通路）——每日回归；
   L1：IP级功能——72小时内clean；
   L2：子系统场景——每周clean；
   L3：芯片级use-case——tape-ready前两周clean；
   L4：corner+压力——用Formal/PGA跑，tape-ready前达标。
   计划里用“燃尽图”跟踪，偏差>5%即触发“橙色预警”，由验证经理拉通设计、后端、 firmware一起复盘。

5. 资源与schedule对齐
   按“人月×平台license×机时”三维估算：

   • 人月：feature点×复杂度系数（1~3）÷ 每人月产出（国内均值35个feature）；
   • license：Palladium 1亿门级平台需提前三个月锁slot，计划里设“平台冻结日”；
   • 机时：formal job跑满32核需约2000 CPU·h，提前申请云算力池。
     所有资源在计划里用“风险缓冲带”表示：人月留15%，机时留20%，防止突发任务。

6. 风险清单与应急方案
   用FMEA方式量化：

   • 风险1：新协议版本在tape前两个月发布 → 概率30%，影响“重写VIP” → 风险值=9，预案“提前与协议组共建golden model”，设Milestone-2必须冻结；
   • 风险2：Formal工具无法证明深度FIFO完整性 → 概率20%，影响“覆盖率缺口” → 风险值=6，预案“用PGA跑伪随机一周≥10^12向量”。
     计划里把top3风险挂在项目Confluence首页，每周高层例会过一遍。

7. 回归与版本管理
   代码分支策略：主干“dev”每日自动merge，验证计划里规定“任何design commit必须附带‘验证影响评估’”，评估表模板固化在GitLab MR模板。回归失败>3次即触发“代码回滚”，由验证经理一键打tag，确保night regression稳定性≥98%。

8. sign-off评审与交付物
   在计划里设三个强制评审点：

   • PRQ（Plan Review Qualification）：计划发布前，架构、设计、验证、后端、firmware五方签字；
   • TRQ（Test Review Qualification）：覆盖率达标+风险关闭，由质量部审计；
   • DRQ（Delivery Review Qualification）：交付包含《验证报告》《覆盖率报告》《风险关闭报告》《未解决issue清单》，所有文档用公司统一模板，PDF加密上传PLM系统，确保“可审计、可追溯”。

通过以上八步，验证计划不再是“写文档”，而是与项目schedule、资源、质量刚性绑定的“活的契约”，可在国内快节奏、高要求的流片环境下直接落地。

拓展思考

1. 敏捷验证在国内的落地：
   越来越多初创公司（GPU/AI/车规芯片）把大瀑布拆成2周sprint，验证计划用“动态burn-down”替代一次性冻结。候选人可补充“如何用Jira+GitLab CI实现sprint验证”，体现对敏捷芯片开发的理解。

2. 车规功能安全（ISO 26262）对验证计划的影响：
   如果目标ASIL-D，计划里必须加“故障注入+DFA”专用章节，FMEDA指标与覆盖率挂钩，且要留“安全机制验证”专用里程碑。能提到这点，可瞬间拉开与普通验证工程师的差距。

3. Chiplet与多die场景：
   国内3D IC项目刚起步，验证计划需考虑“die-to-die接口协议（如UCIe）”与“跨die一致性”，要单列“系统级co-sim+热仿真+电源完整性”验证项，并提前锁定跨die VIP与硬件probe方案。