Geekly articles weekly

验证数字电路。 复习

图片


我将尝试大体谈谈数字电路的验证。


这方面的验证是一个重要的过程，需要经验丰富的工程师的参与。 例如，通常在具有CPU的系统上工作的验证专家必须具有脚本语言和Shell语言（Tcl，bash，Makefile等），编程语言（C，C ++，汇编器），HDL / HDVL （SystemVerilog [10，附录C-语言历史] [11]，Verilog，VHDL），现代方法和框架（UVM）。


用于验证的时间比例达到了项目总时间的70-80％。 引起这种关注的主要原因之一是，您无法在芯片投入生产后向其发布“补丁”，而只能发布“硅勘误”（不适用于FPGA / FPGA项目）。


用数字电路，我的意思是：


  • 复杂的功能块/知识产权（SFB / IP）；
  • 专用集成电路（ASIC）定制芯片
  • 可编程逻辑集成电路/现场可编程门阵列（FPGA）;
  • 片上系统/晶体上系统（SoC / SoC）;
  • 等

实际验证问题


可以通过以下面临的挑战和问题来判断验证领域的当前状态和趋势[6]：


  • 验证对象（OB）的大小不断增长。 即使是小型的微控制器类型的IC也包含数十个子模块，通常具有复杂的功能。 大型集成电路非常复杂，其中可能有数百亿个晶体管，仅电源管理方案就可以超过某些处理器的复杂性[8]；
  • 在项目开始时就不可能为IMS制定规范并仅在将来遵循它，它在整个开发过程中不断变化（客户改变了需求，技术问题或发现了更优的解决方案迫使我们重新考虑方法等）。 基于此，所有过程都应感知规范变更的动态，并根据要求进行修改；
  • 通常，几个彼此远离的团队进行项目验证，其数量可以达到数十人。
  • 单个测试的数量和类型数量巨大，必须收集和分析其结果；
  • 即使对数字系统进行建模也需要大量的计算机时间。
  • 为项目制定的准备目标的完整性在很大程度上取决于验证专家的能力和直觉；
  • 尽管存在带有测试（指标）的项目覆盖率指标，但完成验证的唯一方法是决定暂停验证，主要基于以下结论：必须投入生产阶段所花费的金钱或时间，看来它们达到了代码覆盖率100 ％，我们已经测试了一个星期，没有发现任何错误等。

验证类型


数字电路验证可分为以下主要类型：


  1. 功能 （功能验证）-名称不言而喻，您检查系统是否正确执行了功能；
  2. 正式验证-通过这种验证，可以确定系统在设计路线的不同阶段或在源代码中放置的语句的实现与系统表示形式的等效性：
    • 等效检查（例如RTL到RTL，RTL到门，门到门）;
    • 属性检查（模型检查）（例如，使用SVA检查代码中指定的属性（断言））。
  3. 静态代码分析-根据正式标准检查源代码，以符合使用该语言及其结构的规则。 通常，已配置的验证规则会发送到RMM [4]。 这种验证程序通常称为lint或linter；
  4. 物理验证 -基本上意味着DRC，LVS，PERC等检查，检查系统的物理表示是否符合技术标准以及物理和逻辑表示的一致性等。 支票的构成高度依赖技术。 通常，物理验证由工程师或拓扑设计团队执行。
  5. 原型设计 -使用FPGA进行功能验证[18]。

所有工作范围内的功能验证都是最重要的，需要人类直接参与。


静态代码分析仅需要对工具进行初始配置即可，该配置与公司采用的内部设计规则相对应，然后该工具就可以为开发人员提供“有价值的指导”，而无需经常进行监督。


正式的验证工具通常也非常独立，只需要仔细分析它们生成的报告即可。 当出于某种原因您知道必须从电路列表中恢复代码时，它们也适用于逆向工程。


验证工具示例


数字电路验证工具示例（顶部数字路由）：


  • 验证管理工具
    • Mentor Graphics-Questa验证管理
    • Cadence-vManager
    • Synopsys-Verdi，VC执行管理器（“ ExecMan”）
  • 功能性-通常是模拟器
    • Mentor Graphics-ModelSim，QuestaSim
    • 节奏-尖锐的Xcelium
    • 新思科技-VCS
    • 独立开发人员提供的免费软件-模拟器Verilator，Icarus [5]
  • 正式的
    • Mentor Graphics-正式Pro，Questa正式验证
    • Cadence-JasperGold，保形LEC，精巧的形式验证平台
    • Synopsys-形式化，VC形式化
  • 静态代码分析
    • Mentor Graphics-Questa自动检查
    • Cadence-HAL，JasperGold
    • 新思科技-SpyGlass Lint
  • 实物验证
    • Mentor Graphics-机芯
    • Cadence-飞马，物理验证系统，
    • Synopsys-Hercules，IC验证器

功能验证方法


功能验证-是一组测试，我将有条件地允许自己分为三类（这不是教条，这是根据个人经验得出的）：


  1. 积极分支机构 -验证正常情况下的行为，由设备规范或标准等规定 即 我们会检查一切顺利的情况。
  2. 负分支 -检查偏离标准情况，但在规范或标准的框架内，例如-校验和，接收到的数据数量不匹配等。 即 当出现问题时，但我们知道可能会发生，并且我们知道如何在这种情况下工作。
  3. 非标准情况 -从违反通信协议，数据顺序到接口中的物理冲突，逻辑元素状态的随机变化等任何随机情况。 即 这是什么事情都可能发生的时候，您需要确保OB进入工作状态后才能出来。

前两个阶段可以使用UVC / VIP（通用验证组件/验证IP）自动进行，在那很快就可以增加各种测试的数量，包括自动生成的测试。 第三阶段是验证中的“杰作”，该阶段需要非凡的方法和经验，很难实现自动化，因为 大多数情况是单独的算法，可能是CAD脚本或“手动”检查指令。


功能验证指标的类型


指标是项目测试覆盖率的指标。 为了了解需要开发哪些其他测试来验证可能的情况以及验证需要花费多少时间，需要使用它们[16]。


不幸的是，仅基于项目的源代码评估一种度量标准，其余类型的标准的定义是智力工作的结果。


此外，必须记住，通过一种类型的指标实现所需指标通常并不意味着可操作性，因此始终需要评估复杂性。


指标类型[3]：


  • 功能涂料 。 显示已测试多少OB功能。 覆盖范围的标准可以通过测试计划以及在测试环境和/或OM中引入特殊结构（covergroup [1]）来确定，这些特殊结构监视是否执行了该功能或动作，数据是否以某种方式更改等。 CAD中可以自动收集源代码中嵌入的设计中的信息。
  • 代码覆盖率 -在测试期间更改源代码构造的状态。 它是由CAD自动收集的，不需要在源代码中引入任何结构。 例如：
    • 切换寄存器（切换覆盖）；
    • 每行代码的活动（行覆盖率）；
    • 表达式的活动（Statement Coverage），实际上-这是Line Coverage，但是可以在编辑器中跟踪多于一行的表达式；
    • 条件语句或过程中的代码段活动（块覆盖率），语句覆盖率的变体；
    • 条件语句的所有分支的活动，例如是否，用例，同时，永远重复，for，循环（分支覆盖率）；
    • 组件逻辑表达式的所有状态（真，假）的更改（表达式覆盖率）；
    • 状态机的状态（有限状态机覆盖率）。
  • 索赔范围 。 陈述是一种特殊的语言构造，可跟踪各种事件和序列，并根据指定的标准确定事件发生的合法性。

功能验证方法


定向测试方法（DTM）


直接，有意义的测试。 如果在项目中采用此方法，则验证计划由旨在检查特定兴趣点（州）上有机物行为的测试组成。 检查所有可能的情况，尤其是在复杂项目中，几乎是不可能的。
同时，在设备开始在实际条件下使用之前，未检测到在测试未涵盖的情况下可能出现的问题。 通常，这些测试使用功能覆盖率指标。


覆盖范围驱动的验证，度量驱动的验证（CDV，MDV）[17]


创建测试的概念旨在实现某种有机物质的“测试覆盖率”。 他们依靠指标来了解需要将哪些测试添加到验证计划中，以实现项目准备目标。
您需要使用覆盖率分析工具来查看要添加到验证计划中的其他内容。 实际上，如果我们至少依靠“代码覆盖率”来开始调整DTM中的验证计划，那么我们已经可以假设我们已经从DTM平稳过渡到CDV。


约束随机验证（CRV）


通过提交随机影响进行验证。 这些实际上是自动测试，会对OM产生随机影响，但是很难想象没有与ABV共生的情况。
起初该方法非常昂贵，因为 准备工具需要很长时间。 在准备工作的初始阶段完成之后，可以使用不同的初始数据自动重复开始测试。 如果检测到断言不匹配，则开发和验证团队将开始分析检测到的错误。
在一个实际的项目中，不能只局限于这种方法，因为 使用这种方法，您可以收集代码覆盖率和语句覆盖率，并且它们对操作系统的正确操作无能为力，即 符合规格。 它必须补充功能测试。
要实施此方法，需要：


  1. 在OB源代码和测试环境的所有重要方面实施“声明”；
  2. 开发随机动作生成器及其工作场景，即 影响是随机的，但有范围限制（我们没有时间来整理所有内容），提交顺序等。

基于断言的验证[9]（ABV）


带有语句的验证。 可能这甚至不是一个独立的方法，而是上述的某些组件或基本组件。


ABV的一个重要问题是如何分配断言，哪些断言最好放在OB的源代码中，哪些断言应该在测试环境中。


应当立即指出，Verilog语言在其标准中没有断言（可以使用基本语言结构创建断言，但是合成器需要使用伪指令，以便它不处理其转换）。 断言仅出现在SystemVerilog标准中，并且最初也出现在VHDL和e语言标准中。


我建议您熟悉专家的建议，包括Clifford Cummings [12，有关SVA的文章]，有关其著作分配的信息，以及Verification Academy网站上ABV的材料[13]。


参考文献


  1. IEEE标准1800TM-2012。 IEEE SystemVerilog标准-统一硬件设计，规范和验证语言
  2. 克莱夫·麦克斯菲尔德（Clive Maxfield）。 FPGA设计。 体系结构，工具和方法。 年轻战士的历程。 ISBN 978-5-94120-147-1（RUS），ISBN 0-7506-7604-3（ENG）
  3. 验证学院。 覆盖率食谱。 专业测试范围
  4. 迈克尔·基廷（Michael Keating），皮埃尔·布里科（Pierre Bricaud）。 重用方法手册，用于片上系统设计。 打印ISBN 1-4020-7141-8，电子书ISBN 0-306-47640-1
  5. 许可和自由分发的CAD清单
  6. 导师图形。 当前状态和验证范围的统计示例
  7. WikiChip。 芯片维基百科
  8. 维基百科 有关IC中晶体管数量的一般数据
  9. 哈里·福斯特，亚当·科罗尼克，大卫·莱西。 基于断言的设计。打印ISBN 1-4020-8027-1，电子书ISBN 1-4020-8028-X
  10. Stuart Sutherland，Simon Davidmann，Peter Flake。 SystemVerilog设计。 列印ISBN-10：0-387-33399-1，电子书ISBN-10：0-387-36495-1
  11. 克里斯·斯皮尔（Chris Spear），格雷格·图姆布什（Greg Tumbush）。 用于验证的SystemVerilog。 印刷ISBN：978-1-4614-0714-0，电子书ISBN：978-1-4614-0715-7
  12. 朝阳设计。 论文
  13. 验证学院。 ABV课程
  14. 杜洛斯。 有用的资料在线和参考书
  15. Prakash Rashinkar，Peter Paterson和Leena Singh。 片上系统验证。 方法和技巧。 打印ISBN：0-792-37279-4，电子书ISBN：0-306-46995-2
  16. 验证学院。 SoC验证中的指标
  17. 杜洛斯。 覆盖率驱动的验证方法
  18. 道格·阿莫斯（Doug Amos），奥斯汀·勒西（Austin Lesea），里内·里希特（Rene Richter）。 基于FPGA的原型方法论手册：原型设计（FPMM）中的最佳实践。 印刷ISBN：978-1617300042。 从Synopsys网站免费下载

Source: https://habr.com/ru/post/zh-CN481542/

More articles:


All Articles