数字芯片验证入门

文章目录

  • 数字芯片验证入门
    • 1. 验证那些事
    • 2. 芯片验证系列——Testpoints分解
    • 3. 芯片验证系列——验证计划
    • 4. 关于芯片验证中写testcase的一些想法
  • SystemVerilog
    • 1. 随机化策略——随机变量rand、约束constraint、权重dist、随机数产生示例
    • 2. SV -- Coverage 覆盖率
    • 3. SystemVerilog Tutorial
    • 4. foreach
    • 5. 多线程

数字芯片验证入门

最近在整一个验证项目,需要写验证计划,然e我是新手,之前主要干设计,从未接触过验证。因此搜集了一些我认为讲解的比较全面的博客,贴出来供和我一样的小白入门。

1. 验证那些事

验证那些事
这篇文章是一位比较有经验的验证工程师写的,比较全面的讲解了芯片验证的各个流程。
比较好的测试点分为场景类、功能类、性能类、白盒测试点(设计人员提供)、接口类、异常类6个维度,全面、明确、细致,无歧义的将所有验证特性细化为一个个不可分割的小点,每个点明确采用directtest还是coverage覆盖还是assertion覆盖。

2. 芯片验证系列——Testpoints分解

芯片验证系列——Testpoints分解
Testpoints(测试点)需要从提取出的verification feature进一步分解得来,测试点描述应该包括要测什么、怎么测、如何确保真的测试了。用英语表述就是:1. What needs to be verified(明确问题)? 2. How will it be verified(解决问题:激励和checker)? 3. How will it be covered(确保问题发生:覆盖率)? 经典的1W2H。
Testpoint是最小的功能点,不可以继续拆解,必须用陈述句能无歧义地描述被测对象的某一功能,无歧义意思就是任何对这个测试点,看了只会有一种理解。可以通过这样的方式描述:通过什么样的输入(input),RTL会做什么反应(process),最终有什么的结果或输出(output),也就是IPO原则。
有了上文基础之后,看这篇文章,讲的更加细致全面:【验证技能】测试点分解总结

3. 芯片验证系列——验证计划

芯片验证系列——验证计划
验证计划是验证策略的更具体实施计划。验证策略是在高层次描述对验证的整体规划(目标制定、时间安排、工作流程、验证方法学、版本管理、总体覆盖率进度等)和对RTL进行哪些层面测试,包括UT/IT/ST/FPGA/Emulation/Formal等。验证策略不会涉及验证的详细计划,验证计划就是对验证策略进一步详细地阐述,包括详细时间安排、人力需求、TB结构、配置、提取Verification feature并划分优先级、TB局限性分析、reuse组件、 testcases规划、覆盖率和每个阶段验收标准等等,甚至可以包含coding guideline。验证计划用于规范验证的行为,不仅仅用于决定何时验证可以结束和peer review,也可用于同一个team同事在实现TB功能和testcases时有依据可循。以下是写验证计划时,需要涉及的一些参考点。

4. 关于芯片验证中写testcase的一些想法

关于芯片验证中写testcase的一些想法
在芯片验证中,搭建好testbench后,就必须开始着手创建testcases。testcase按功能可划分为三类:冒烟用例、随机用例、定向用例。按开发时间顺序,一般也是冒烟用例→随机用例→定向用例。

SystemVerilog

1. 随机化策略——随机变量rand、约束constraint、权重dist、随机数产生示例

随机化策略——随机变量rand、约束constraint、权重dist、随机数产生示例
为什么要采用随机化验证策略?
  随机化策略指的是:激励随机化,配置随机化等。
1)、对于较大的验证空间,随机化策略可以使验证有条件趋于量化流程,达到以时间换空间的效果。
2)、使用随机化产生激励,可以很容易的在短时间内产生大量的随机激励,随机激励可以达到我们工程师可能会忽略的地方,相对于固定的激励(难以覆盖较大的可激励空间),随机化的激励可以用更为抽象的数据包传输,简化数据场景,更能验证出DUT可能隐藏的错误,提高验证的完备性
  所谓配置随机化指的是,测试平台配置的随机化。可配置的测试平台可以为DUT创造出多种模拟的运行环境,而且这种模拟的环境越多越好。比如DUT具有一个I2C Master接口,那么测试平台应该具有提供1个到多个Master和slave的能力。
  其实之所以需要随机化是因为工程师的思维总是具有局限性,不可能想到所有的测试情况。就算想到了所有的情况,那么也不可能付诸实践。比如要测试一个32位的加法器,如果要全部覆盖则需要2的33次方个定向的testcase。这是无论如何也做不到的。如果使用大量的随机测试,只要部分验证通过,我们就可以认为验证通过。

2. SV – Coverage 覆盖率

SV – Coverage 覆盖率
覆盖率用来衡量设计中已经被测部分和未测部分的比例,通常被定义为已达到所需验证部分的百分比.
目标覆盖率是指在验证计划中规定的需要验证点的目标值。 在验证计划中, 当验证点实际覆盖率没有达到 100% 的时候, 说明验证工作还未完成目标方案。 没有达到 100% 的项目需要通过添加测试用例或者修改约束等来对其进行充分的验证;
验证计划中列出的项目都要一一被测试, 当然这需要一个比较全面和完整的验证计划。为此, 在验证环境搭建的前期, 制定验证计划, 明确验证点并确定目标覆盖率是一项艰巨而且细致的工作;
快速理解systemverilog bins:什么是systemverilog bins?

3. SystemVerilog Tutorial

SystemVerilog Tutorial
带有例程的讲解了SystemVerilog的语法,很容易理解,但是是英文的。

4. foreach

SystemVerilog foreach loop
【system verilog】foreach遍历多维数组

5. 多线程

systemverilog在for循环中使用fork_join和fork_join_none的区别
这篇文章主要讲解如何通过for循环来创建多个并行的线程,并详细解释了fork_join, fork/join_none, fork/join_any的区别
for循环+fork-join_none结构的坑,你有注意到吗?
这篇文章主要讲解通过for循环创建并行线程的时候为什么直接使用for loop id不能得到想要的结果。

你可能感兴趣的:(验证,数字IC设计,Verilog,uvm,system,verilog,数字芯片验证)