数字芯片验证入门

1. 数字芯片开发流程简介：五个步骤

• 规格定义
  • 做好芯片的需求分析、完成产品规格定义，以确定设计的整体方向
• 系统设计
  • 明确芯片架构、业务模块、供电等系统级设计，例如CPU、NPU、RAM、接口等。必须综合考量系统交互、功能、成本、功耗、性能、安全及可维可测等综合要素
• 前端设计
  • 确定设计方案
  • RTL编写和验证
  • 输出网表
  • 静态时序分析
• 后端设计
  • Floor Plan
  • Plan and Route
  • Design Rule Check
  • GDS版图
• 生产与封装
  • 光刻
  • 切割
  • 封测
  • 集成SDK&工具

二.验证工作的职责与工作内容

发现Bug，发现所有Bug，直至证明没有Bug，是验证存在的唯一目的。

概念详解：

芯片验证就是在整个开发周期内，采用适当的验证方法，验证工具，验证语言，在芯片生产之前确认芯片的设计：

1. 是否符合客户的原始需求
2. 是否符合芯片定义的规格
3. 是否发现并更正了所有的缺陷

致命误区：

1. 验证就是搭环境写用例跑用例，看PASS/FAIL
2. 验证的工作仅仅是验RTL代码正确与否

按照项目所处阶段划分

• 前期：架构验证

  • 关键字：ESL/建模/性能/软件交互

• 中期：RTL代码验证

  • 关键字：测试点/TC/EDA

• 后期：解决方案验证

  • 关键字：FPGA/EMU

按照验证对象层级分

• Unit/Block Test
  • 模块级功能验证
• Integration Test
  • 子系统级集成验证
• System Test
  • 整系统功能验证

部分非常规验证

• 时序/电源网表仿真与PI/SI/功耗分析
• Romcode验证
• CP/ATE/MBIST测试向量验证
• Formal形式验证（JasperGold）
• 数模混合仿真（.v + .spi4）

验证的发展：

远古时代：directed-test-driven — 没有覆盖率

通过直接用例去保证设计的质量，简单直观。

但是随着设计规模和复杂度变大，这种直接测试导向会遗漏掉很多问题

黄金时代：Coverage-driven — 看覆盖率

已功能覆盖率（function+assert）+代码覆盖率（line+toggle+branch+cond+fsm）为目标；

有效的利用随机用例，在最大程度上保证验证完备性；

但这是基于设计的验证思路，而非原始规格。

信息时代：Metric-driven – 用覆盖率

将验证过程中收集到的coverage数据反标到原始规格中，从而得到一个可视化的验证质量呈现；

确保从需求到实现无遗漏，同时利于分散协作的新研发风格；

同时利用AI/ML技术（例如Synopsys的ICO）利用coverage对输入激励进行自动优化

一句话总结：

架构与设计人员决定一颗芯片的上限

验证人员决定一颗芯片的下限

任何一个遗漏至芯片上的BUG都有可能导致整颗芯片变砖

案例1: 1990年代Intel奔腾处理器浮点除法BUG，复现概率1/9Billion，损失4.75亿$

案例2：高通骁龙810，满负载运行5秒，核心温度可至100度+，人称火龙

一点私货：

*哪个环节最容易被AI替代？ *

后端 > 设计 > 验证 > 架构 ？

三.验证的流程

1. 规格熟悉（规格制定）
2. 测试点分解
3. 验证方案制定
4. 验证环境搭建
5. 冒烟用例与直接用例调试
6. 随机用例调试与回归
7. 完备性分析与用例增补
8. 验证报告

验证质量的核心在于测试点分解，不在搭环境与跑用例！

测试点分解是芯片验证工作中的最重要的一环，是充分体现验证人员经验、能力、智慧、价值的一

项工作。芯片中的bug往往都是没有想到的点或者没有覆盖到的点。所以测试点分解一定要追求完备、细致、无歧义，要做到测试点分解完成后，无论哪个验证人员执行，验证质量都是有保证的。过于粗糙的测试点会导致不同的验证人员在验证用例设计时有不同的理解和实现，或许就会遗漏掉一些corner点。同时粗糙的测试点也会造成工作量评估不准确，导致后期突发任务增多，造成项目延期。

测试点分解

TestPoint-验什么

“CP模块应支持Rd control的优先级高于Wr control”

ConFiguration and Stimulate description - 怎么验

”模块正在处理DMA操作，且SrcREQQ中缓存有rd_req和wr_req未下发，再发送rd_control“

Check description -怎么检查

“断言检查：rd control 的data准备好之后，须先于wr_req的data发送出去，否则报错”

Coverage description-怎么保证有覆盖到此场景

“功能覆盖率/断言覆盖率确保用例中有同时出现rd_req和wr_req命令”

测试点的颗粒度
粗：“需要覆盖中断功能的测试。”
细：“覆盖不同中断信号使能打开、关闭测试”
“覆盖中断正常清除测试”
“覆盖延迟清除中断测试”
“覆盖不同中断来源的中断测试”
“覆盖中断有效后相关中断状态寄存器正确性检查”
“覆盖中断不同来源同时有效的优先级测试”
“覆盖多中断次数测试场景”
更细（把“覆盖延迟清除中断测试”继续展开 ）：
“覆盖延迟清中断，延迟时间小范围随机”
“覆盖延迟清中断，延迟时间等到下一个中断来之后再清除”
“。。。”

进阶–IPD

业务线：DCP=Decision Check Point业务决策评审点

Charter+CDCP：想做什么？策略是否可行？

PDCP：做什么？计划是什么?需要什么资源？是否值得继续投资？

投片临时DCP：风险控制点，当前进度与风险是否符合既定策略

ADCP+GA：产品包是否可以批量交付，运作与交付条件是否具备

EOM/EOP/EOS：终止销售/生产/服务

研发线：TR = Techinal Review（包含三个重要开发阶段85%，95%，100%）

TR1：确定产品的包需求是否满足客户需求

TR2/3：确定产品设计规格和设计概要是否满足包需求

TR4：对协同开发验证结果进行评审，判断是否投片

TR4A：对回片测试结果进行评审，判断是否进行小批量试制

TR5：对样机功能性能测试结果，以及芯片量产可靠性进行评估，判断是否进行风险备货

TR6：评审产品测试与试用结果，判断是否进行上量生产与正式发货

除业务线和研发线，还有：
资料开发
市场发布
客户试用与早期销售ESS
物料采购与供应链管理
IP与算法开发
产品BOM管理
EDA工具管理
预算与合同管理
质量回溯与经验总结

价值：明确特定角色，在特定时间，按照特定标准，完成特定的交付，并保证交付产品准确规范。

项目节点	行动项	说明	重要性
需求分析阶段	规格场景分析、验证重难点分析	要求验证人员在项目初期不能被动的等待设计Release代码，要主动参与到需求分析与规格制定的讨论中，了解自己所负责的模块/子系统整芯片在实际产品形态下的应用场景、工作模式，并对其潜在的重点难点做出有效预判指导后续验证工作开展	高
需求分析阶段	异常场景分析	设计和验证人员往往会重点保证正常功能的正确性，异常处理流程是容易被忽略的地方。不同产品形态的芯片对于异常处理流程有着不同的要求，且构造异常场导对验证环境有若较大影响。因此要求验证人员对异常发生的场景，应有的处理策略( 是否记录是否上报软件、是否自恢复 ) 做出分析，指导后续验证工作	低
需求分析阶段	历史问题单分析	对负责验证的模块的前一版本、或者对口设计同事负责的前一模块的历史问题单进行分析总结缺陷分布情况( 原因分布、位置分布、时间分布等)，预判潜在风险点，做针对性强化验证。	中
概要设计阶段	checklist学习	项目组根据历史经验对于曾经出过错或者容易出错的地方、会总结归纳checklist。要求提前学习	低
概要设计阶段	测试点分解及评审	测试点分解是验证人员最重要的能力没有之一，指导验证环境的搭建与验证用例的构造，直接决定验证完备性。测试点分解需要明确1)要验证什么特性 ;2)构造什么激励去覆盖这个特性 ;3)怎么检查激励产生的结果是不是正码 ;4)怎么保证构造的激励覆盖到了这个特性。	高
概要设计阶段	FS/AS反串讲	规格传递过程中大概率会引入偏差，而设计、验证、SE对规格的认知偏差是缺陷的重要来源因此安排验证工作启动前对FS/AS进行一轮反串讲，绕一对规格特性的理解	高
概要设计阶段	ST/IT/BT/EMU/FPGA互补测试需求分析	对规模较大的芯片交付，BT/IT/ST/原型验证会承担不同层次的验证工作，对于部分无法在本层次有效覆盖，需要在上层或者下层进行补充覆盖的特性，需要明确的列出来并进行跟踪，确保覆盖。	中
概要设计阶段	验证方案编写及评审	综合描述验证平台的设计思路，包括激励随机策略与功能覆盖率方案RM与检查比对方案验证平台结构说明等	高
验证开发阶段	环境搭建	应当与设计代码同步开发	高
验证开发阶段	基本用例测试与冒烟	基本用例指能涵盖该模块典型工作场景的用例或者用例组，应尽量在RTL交付2周内完成基本用例的调试与冒烟	中
验证开发阶段	FPGA/EMU版本支持	在项目中期FPGAVEMU的原型验证过程中会产生不少问题需要验证人员支持定位或者构造用例复现，验证同事需要给予全力支持	中
验证开发阶段	随机测试用例调试与回归	在CDV流程中不能仅靠定向用例去覆盖测试点，在基本用例冒烟后需要启动随机用例调试与功能覆盖率模型的构建，并最终启动大规模随机用例的回归。同时应当有一条( 或多条 )ALLIN ONE用例表盖规格允许的尽可能多的场景。	高
验证开发阶段	单点专项验证	构造用例对典型业务用例无法覆盖的特定电路做专门的验证，包括但不限于: 接口、Memory、Register,lowpower、CRGinitreg+xprop、反压、性能、调度、异步、异常、结构类( FIFO/TIMER等)、DFX、功耗、连线、PAD与I0等	中
验证开发阶段	覆盖率分析与增补	验证工作的基本出口指标就是覆盖率达标，包括代码覆盖率和功能覆盖。这是一个反复迭代的过程，需要与设计一起对覆盖率情况作出分析，修正激励完备性与RTL风格。	高
验证出口阶段	验证质量分析	Review虚证环境质量，包括但不限于RM有效性、随机引擎有效性、不能自动比对的特殊点说明、CR( 需求变更)验证方案补充、验证环境force点与交叉引用点说明、编译LOG及仿真LOG中Waming分析等	中
验证出口阶段	重点波形review/互补需求落地review/OR/DR/FS/AS再次反串讲	略	低
验证出口阶段	验证报告与验证总结	验证报告是对前述验证工作的系统性总结，是项目经理/验证经理判断该模块的验证工作是否出口的重要依据，需要如实的反应ORDR-测试点-用例-覆盖率的对应情况、验证平台最终架构、验证过程中发现的缺陷及分析、force及交叉引用点使用，性能分析、功耗分析、风险评估等等。
验证出口阶段	问题单与遗留单问题清零	要求所有遗留问题、待增补事项、问题单都解决并闭环

四.验证的技能树 — 基础技能

验证最重要的技能点是“责任心”，直接决定交付质量，其余技能点仅决定加班否
基本语言/语法：
Verilog/SystemVerilog/Makefile/UVM、、、
进阶语言/语法：
Python/C/SystemC/TCL/PERL/SVA。。。
基本电路知识：
数电基础（组合电路、时序电路、时钟复位、分频、状态机、FIFO、、、）综合与STA基础
常见IP及相关协议：
AMBA总线，SRAM接口，CPU基本原理（取指、译码、、、）
EDA工具类：
VCS、VERDI、Emulator、、、
办公环境类：
Linux命令、GVIM、SVN/GIT、SHELL、、、