SystemVerilog学习笔记(一)


1. 相关名词

  • 验证: verify/verification (国外也称为validation)
    • pre-silicon validation: 流片之前做的验证
    • post-silicon validation: 流片之后做的测试
    • 国内公司区分验证与测试较明确,或将流片后的测试工作外包;国外通常将验证与测试归为同一岗位。
  • TestBench:测试平台,为了检验待测设计(design under test,DUT)而搭建的验证环境。
  • DUT(Design under Test)/DUV(design under Verification):待测设计
  •  Stimulator:激励发生器
  • monitor:监测DUT的输入
  • test case:测试用例
  • Emulator :硬件加速器

2. 芯片开发概述

2.1 验证的概念

  • 用来证明设计功能正确,符合设计功能描述的流程

2.2 测试平台

* 对DUT创建测试序列 ,Stimulator利用Clock发送激励(Stimulus)。 * monitor观察DUT的输入 * Checker对DUT的输出数据与预期数据进行比对 * 报告检查结果

硬件验证区别于软件软件在于时序

2.3 设计与验证

设计和验证要独立工作

2.4 芯片体积有多大

职业规划:事业第一个五年把IP的项目整
个流程与SoC项目的整个流程都过一遍

2.5 芯片开发流程

  • 市场人员与客户沟通,了解用户需求
  • 系统设计人员按照功能划分为各个子系统
  • 子系统进一步被划分为功能模块,由设计团队人员实现
  • 验证人员对设计功能展开验证,发现设计缺陷,交由设计人员修正。验证人员需要写两部分代码
    • 验证环境文件:写验证组件
    • 测试代码:产生数据、配置等
  • 验证没有出现漏洞后,交由后端人员进行综合、布局、布线。
  • 后端人员将核心数据交由FAB进行流片。

2.6 验证和设计的紧密关系

  • 验证最好能够懂设计
  • 验证相比设计入门更加容易,但验证与设计同样重要,验证的行业天花板持平设计甚至更高。
  • 设计和验证都需要围绕功能文档。
  • 尽量在流水线中做并行的工作(设计初步实现之后需要验证入场),尽量提前芯片开发的周期。
  • 验证发现结果不符合预期时,如果漏洞明显可交由设计修正,待返回再测试;如果功能实现与设计存在分歧,则需共同回顾功能描述,统一对功能的理解。

2.7 验证人员的工作

在设计人员根据设计功能描述,实现各个模式RTL代码之后,开始构建验证环境,做几项工作来检查设计:

  • 设计文件是否正确地按照功能描述文挡去实施了?
  • 硬件设计人员是否有遗漏掉的边界情况(corner case) ?
  • 硬件设计是否足够稳定来处理一些错误情况(errorresponse) ?

2.8 验证与设计的协作

  • 验证和设计都需要认真阅读功能描述文档
  • 设计会将功能描述文档翻译为RTL模型
  • 验证会按照其功能发送激励和比较结果

3. 芯片验证概述

3.1 验证的目标

  • 按时保质低耗“完成目标硬件设计的验证工作
    • 按时
      • 按照项目预先的进度来考虑验证的节点(milestone),即系统、子系统、模块等的deadline
      • 模块之间相互关联,个人的延时会影响团队的延时
    • 保质
      • 尽可能少将缺陷暴露在流片之后,缺陷暴露在不同阶段造成的损呈指数增长
      • 被市场发现缺陷会对芯片设计公司和客户双方造成消极影响
    • 低耗
      • 更短的时间、更少的人力来完成芯片设计任务
      • 控制缺陷暴露的阶段

3.2 验证的重要性

  • 缺陷率增长曲线
    • 重大缺陷造成额外的成本损失是越靠后越巨大
    • 缺陷率增长曲线的曲率又是逐渐减小的
    • 快而全地提供缺陷率增长是理想目标
  • 二次流片
    一旦芯片在出片以后被检测出的严重缺陷会直接导致芯片的二次流片,这对于成本控制是—种额外的损失,消耗时间和人力资源。一方面,重新流片带来的成本巨大;另一方面,涉及到Fab厂产能、排期等复杂因素,重新流片的时间窗口至少为3个月。

3.3 验证的环节

1. 拿功能详述文档创建验证计划 2. 开发验证环境(实验1-2) 3. 调试环境和HDL文件 4. 递归测试:避免“拆东墙补西墙” 5. 硅后测试 6. 展开逃逸分析

具体为:
1)了解spec,即代码的规格说明书,有结构模型、功能描述、信号端口、寄存器定义等,它是设计和验证对接工作的桥梁。
2)制定testplan,一个完整的验证计划需要考虑的东西有很多,它为后续工作的进行提供了方向。
3)构建testbench,根据具体验证需求选择相应的组件,搭建出尽量可重用的验证环境。
4)编写testcase,根据之前定制的验证计划,coding相应的测试用例,debug fail case,把全部case调试至pass。
5)收集coverage,跑regression回归,根据覆盖率来决定是否加case,直到满足RTL freeze要求。

4. 问答题

1.设计人员和验证人员他们的协作关系体现在哪些地方?

答:主要体现在功能模块的共同实现上:设计人员根据功能描述文档将模块功能以RTL代码实现,给出HDL文件;验证人员同样需要阅读功能描述文档,根据模块的功能发送激励展开验证,判断设计是否满足要求等。
若满足要求即可交予后端人员进行下一步操作,结果不符合预期时,如果漏洞明显可交由设计修正,待返回再测试;如果功能实现与设计存在分歧,则需共同回顾功能描述,统一对功能的理解。因此,验证人员与设计人员共同完成功能模块的实现。

2.为什么芯片验证的重要性目前越来越高?

答:芯片验证的目的是”按时保质低耗”完成目标硬件设计的验证工作。其中,最重要的一点是通过芯片验证能够将尽可能少将缺陷暴露在流片之后。根据额外成本与缺陷发现时间关系曲线分析可知, 重大缺陷造成额外的成本损失靠后呈指数递增。若在RTL级发现缺陷交予设计人员修正即可;若在流片之后发现严重缺陷,可能导致芯片的二次流片。一方面,重新流片带来的成本巨大;另一方面,涉及到Fab厂产能、排期等复杂因素,重新流片的时间窗口至少为3个月。若在投入市场后发现重大缺陷,或给芯片设计厂与客户都带来巨大损失。因此,通过芯片验证尽可能早发现缺陷对于成本的控制具有重要意义。

3.在一个完成的验证周期中,有哪些工作需要完成呢?

答:验证人员首先根据功能描述文档制订验证计划,接着开发验证环境,编写并调试验证环境文件与测试代码,写测试用例。接着进行递归测试,完成后进行流片前完备性检查。流片以后进行硅后系统测试,最后进行展开逃逸分析,吸取教训。


文章作者: DPH
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 DPH !
  目录