马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?注册
x
本帖最后由 fengduzhuo 于 2020-6-3 22:04 编辑
验证计划制定篇 (教科书版,在工作时要简化)
Verfication Plan 验证计划
Verification Environment 验证环境
Verification Guidelines 验证原则
验证策略?
验证RTL设计代码,即验证RTL code和design spec的一致性。
1、需要哪些资源?比如工具,VCS,几个人几个VNC端口,磁盘空间多大等
2、需要验证哪些内容?比如,只做功能验证不做时序验证,需不需要FPGA做原型验证,需不需要硬件加速器。
3、是否输入应用场景所对应的所有可能?——输入符合实际应用的场景。
4、如何发现错误?——看波形和自动比较
5、如何衡量验证进度?——覆盖率驱动的验证策略,CDV。当然也可以用时间节点花费,比如用5个个月达到80%,7个月达到100%
6、什么时间验证结束?——覆盖率100%。1点是所有test都pass了,还有一个是代码覆盖率和功能覆盖率都达到100%。
那么反应到实际验证计划中是这样的。
首先在项目之初就要构建时间节点,设计和验证是并行的,他们之间有重合和迭代的。
验证计划的内容(教科书详细版)
1、验证层次描述(单元->模块->IP)。实际中这一般不归DV管。
2、需要的工具:逻辑仿真工具、自行开发的工具、软硬协同。实际中是公司有啥你用啥,需不需要软硬协同也是架构的事。
3、风险和前提条件。人不够怎么办?要买IP,IP没用怎么办?
4、验证功能点
5、特定的验证方法
6、覆盖率要求:代码覆盖率+功能覆盖率
7、测试案列的应用场景:上电复位、数据传输、命令处理、容错处理
8、资源要求:人员、硬件、软件
9、时间安排
一、验证层次
验证层次结构要明确:一般做block和IP层次的
将不同的电路层次结构组合成功能组件
每个功能模块的复杂程度:复杂功能需要较高的可控制性和可观察性。简单功能不需要,可以在其他不同的层次结构经行控制和观察。
接口定义和设计规格要清晰:可变接口的功能必须独立验证;共呢个简单的稳定接口可以跟其它模块组合验证。
二、需要的EDA工具
逻辑仿真工具:QuestaSim/IES/VCS(动态仿真)
形式验证工具:Conformal/Formality (静态仿真) 基于断言的工具 调试工具:VSIM/Veridi/DVE 硬件加速仿真器:Veloce,Palladium 软硬联合仿真:FPGA原型验证 高级验证语言:SV,SC,C/C++ 功能库文件 VIP\IIP
三、风险和前提条件。
工具风险……这一般是公司层面的玩意儿,DV不管。
重点关注时间风险,也就是时间节点。RTL设计代码的及时发布,先发布第一版简单功能的RTL,之后再发布功能复杂的RTL代码。
至于设计架构的收敛……DV也不管,这一般是放MAS/MRD里的,就是架构的文档里的。
四、功能点的划分
关键功能:设计必须会使用的功能。
次要功能:
1、针对流片而言,非关键功能,比如性能相关的、下个版本可以实现的、软件可以实现的。
2、下一个验证层次中,非关键功能,比如可以在不同层次,可并行验证的功能;边界条件情况。
通用功能:
正常运行过程中不会发生的操作 系统复位和时钟的生成 错误处理 系统调试
本层次不需要验证的功能 在逻辑仿真过程中,可以较低层次的验证,也可以在更高的层次验证的功能 在该层次上不使用的功能
五、特定的验证方法 验证类型: 需要验证的功能 内部结构 错误现象 资源可用性
验证策略: 确定性仿真-简单设计 随机化仿真-复杂设计 形式化验证
随机验证: 因为循环导致hang 低概率应用场景 特定的直接测试案列
抽象层次
检测策略: 白盒验证 灰盒验证 黑盒验证
六、覆盖率需求(code coverage/function coverage) 定义覆盖率目标:通过反馈机制来确定验证环境的激励生成的质量 1、所有的命令和响应类型 2、特定的数据类型和数据的数值范围 3、所有有效激励 4、容错处理
统计覆盖率 分析覆盖率漏洞 必要情况下编写定向测试案例
七、测试案例的应用场景 列出所有的实际应用场景 1、所有DUV/DUT输入端口的实际序列(seq) 2、边界条件(Corner case) 3、错误条件(Error handing) 4、……
八、资源要求
九、时间安排 列出不同验证活动的时间安排 1、验证团队提交的结果和内容 2、验证主要工作、流程和标准
项目进度安排: 1、设计架构和文档的正式发布时间 2、验证平台开发 3、第一版RTL设计代码的发布时间 4、一个基本测试案列跑通的时间(VR1) 5、启动回归测试的时间 VR0写计划、VR1第一个测试案列调通的时间、VR2回归测试OK,覆盖率达到100% 6、流片时间
大的项目还需要统计Bug rate
十、验证环境 TB环绕在DUV周围 产生激励 获取响应 检查正确性 通过覆盖率衡量验证进度
验证平台的属性 可重用,易修改,OOP 分层的TB易于重用,将代码分隔成独立的功能模块,将通用的功能放在一段代码中
迅速获取信息并快速达到较高的覆盖率 随机化验证技术(Randomize)
分层的验证平台 1、信号层:DUV与TB的链接(interface) 2、命令层:驱动器、接收器、编写断言 3、功能层:transactions、Agent、checker、scoreboard 4、应用层:Generator(生成期望的数据、定向测试、带约束的随机测试) 5、测试层:搭配置 6、功能覆盖率:收集test case的仿真结果去指示出问题
来源E课网
|