功能验证对VC开发与集成的功能验证分类课件.pptx

《功能验证对VC开发与集成的功能验证分类课件.pptx》由会员分享，可在线阅读，更多相关《功能验证对VC开发与集成的功能验证分类课件.pptx（86页珍藏版）》请在三一办公上搜索。

1、谢谢观赏,1,功能验证,2019-6-9,谢谢观赏,2,主要内容,对VC开发与集成的功能验证分类VSI联盟对虚拟元件的开发与集成的功能验证术语、验证技巧及语言风格,2019-6-9,谢谢观赏,3,功能验证分类,功能验证的技术主要分为以下四大块：从验证方法上分：l目的性验证 目的是验证设计所试图完成的功能在设计中已正确实现。最典型的情况是在抽象程度最高的层次完成，其最终结果是建立一套“黄金模型”，它可以在整个设计过程中作为设计细节的参考。l 等价性验证 目的是验证设计过程中产生的不同层次的设计结果功能是否符合“黄金模型”。从验证对象上分：lVC验证 对某个VC的功能（如：单元测试）进行验证的过程

2、。l 集成块验证 对包含一个或多个VC的SOC进行功能验证的过程。,2019-6-9,谢谢观赏,4,在以上每项任务所使用的技术和工具之间有很大的交迭。虽然验证和SOC验证的过程相同或者相似，但是，验证测试序列的模型和源代码则可能迥然不同。对验证而言，关键的是对的内部逻辑进行详细的功能验证以确保功能的正确性。而集成片验证却只是把研究的重点放在VC的连接和相互作用上，其验证模型只需考虑对VC的接口进行精确的描述，对VC的内部功能则无太高要求。,2019-6-9,谢谢观赏,5,适合于目的验证的工具和技术,动态验证 动态验证是在一系列激励的作用下，对以下几个方 面的测试：一个设计方案的一个或几个模块、

3、某设 计的硬件实现等。静态功能验证 静态功能验证利用公式化的数学技巧来进行验证 而不使用验证测试序列。其测试方法还没有统一 的工业标准，说法比较含糊。形式验证动态形式化混合验证 为了更好的发挥形式化验证技术全面 性的特点，在处理大型设计、更加广 泛的设计风格的设计时使用。（符号 仿真、半形式化仿真）硬、软件联合验证硬件仿真物理样机虚拟样机,2019-6-9,谢谢观赏,6,适用于目的验证的动态验证工具和技术,确定性仿真概念：对一个模块施加激励信号并由这个模块产生响应信号的过程。在确定性仿真中，激励信号被明确给出，而且模块的响应信号能够预知并被检测到。分类：基于事件的仿真基于事件的软件仿真器通过事

4、件的发生（一次一个事件）和在设计中进行传播而进行操作直至获得一个稳定的状态。该设计方案的模块包含内部周期时钟的概念和功能性的概念。输入的激励信号的任何变化都将作为事件被检测到，并将被传遍设计的每个阶段。由于输入信号的到达不同时和底层被测元素的信号的反馈不同时，可以在每个时钟周期对设计的某个元素评估多次。虽然这能提供高精度的仿真环境，但执行速度有赖于设计的规模，在大型的设计中其验证速度会相应降低。基于时间的仿真基于时间的仿真采用了不同的方法。这种仿真不再具有内部周期时钟的概念，它在单个周期中对状态及/或各端口之间进行逻辑评估。由于每个逻辑元素在每个周期中只赋值一次，因此这种方法极大地缩短了执行时

5、间。基于时间仿真的简单模型（没有时序，逻辑状态少等等）限制了仿真器能够处理的电路类型。比如说，依赖于内部周期时钟的电路或在恰当的仿真中传播不确定值的电路就不能使用这种基于时间的仿真方法。,2019-6-9,谢谢观赏,7,适用于目的验证的动态验证工具和技术,随机模式仿真分类：直接模式随机地址和随机控制信号被加入总线或信号流中，而且一个或多个总线监测器对这些信号进行监控，以确保总线协议不会因为这些操作而产生误操作。这种方法对总线验证尤其适用。验证测试序列是直接的，因为操作周期的产生并非纯粹的随机产生，而是以某种特殊的方式来强调设计。这种向量发生器可用来以特定的分配产生特定的传输周期，如：在伪随机序

6、列中产生20的读，30的写和50的变址读写。类似的，在数据和地址领域中也可产生随机序列，但是得在有限的范围内使用有限的离散数值。这些类型的测试验证验证用确定性仿真很难验证的临界状态、临界序列以及依赖于数据的状态。用这种方法，任何算法错误都能在设计周期的早期就能被发现和更正。间接模式在间接仿真中，设计的输入直接由随机向量发生器驱动，之后检查其输出以检测任何无效的操作。这种方法最常用于验证数据通道和算术元素，或者用来验证能够接收任何随机序列的小模块。,2019-6-9,谢谢观赏,8,适用于目的验证的动态验证工具和技术,硬件加速 硬件加速是特指为加速某些仿真操作而设计的将软件仿真中部分或全部的成分映

7、射到硬件平台中的操作。最典型情况就是测试平台仍然保留在软件中运行，而被验证的设计却是在硬件加速器中运行。有些类型的加速器也能运行行为级的代码，这种情况下，具体的时钟周期的行为表现并没有给出详细的说明，因此，有可能会全部在硬件加速器中运行纯确定性或随机模式仿真。硬件建模有些软件仿真模型的设计元件难以实现，或者不够精确。解决这个难题的方法就是运行硬件模型中的一个半导体元件，将它连接到软件仿真器上。这个硬件模型的输入是接收来自仿真器的信号，然后将该信号送到半导体元件中运行一个周期，最后获得输出信号并将它送回仿真器。,2019-6-9,谢谢观赏,9,适用于目的验证的动态验证工具和技术,协议检验协议检验

8、器指的是监测接口的数据处理以及检查任何无效操作的元件。如果在仿真器中有任何无效操作被检验到，检验器将会作标记。这种元件可以装备在测试平台中而不作为设计的部分。在这种应用中，检验器仅仅在仿真时才起作用。当然，协议检验器也可以植入设计之中，这样检验器不仅可以在仿真的时候，而且可以在实际的物理设备进行的普通操作中都能查错。不过，设计中植入的这种设备要能够在门级进行综合。预期结果检验是系统测试平台的一部分。它对仿真结果与事先的规定期望响应文件进行比较。如果结果不符，将会报错。,2019-6-9,谢谢观赏,10,形式验证,形式验证利用数学方法对设计结果的功能进行验证。由于它依赖于对设计的数学分析，因此无

9、需使用验证测试序列。适用于等价性检验和目的性验证。适用于目的性验证的形式验证工具和技巧：性能/模型验证 性能/模型验证是运用公式化的数学技巧来校验设计的功能特性。模型验证器搜索一个设计在所有可能条件下的状态空间，去寻找通过仿真很难发现的缺陷。当模型验证员的报告说某种性质是正确的，那么设计者就可以放心：他的报告是100的精确。模型验证不需要建立任何测试平台，其要验证的性质是用以特殊的规范语言描述的查询表形式。当模型验证工具发现错误的时候，它会产生自初始状态开始，到行为或特性出错的地方为止的完全搜索路径。因为包含数据通道的系统经常包含很大很广的状态空间，对这样的系统进行验证就花费昂贵的存储空间和大

10、量的处理时间。所以模型验证通常在控制密集设计的验证中比数据通道密集设计验证更加有效。模型验证者通常能够在各种合法输入序列和合法的输入状态下，如模型验证和性能一样可以直接从仿真验证出某种特定的条件总是真，最终为真还是永远不会是真。这种性质就是对设计的断言，对仿真和模型验证都十分有用。通常，断言表明了某些特定条件必须总是正确，就将该条件列入checker的职能范围之内，一旦在仿真中这种条件有丝毫偏离，checker就会“罢工”，从而使用户得到通知。,2019-6-9,谢谢观赏,11,形式验证,理论证明 基于理论证明技术的验证系统通常支持某种基于选定形式的逻辑的规范语言，并支持一组以该语言命令的形式

11、机械地构造逻辑断言的证明。一个使用基于理论证明技术的验证系统的硬件设计的形式化验证，通常包含：对设计模型(M)的初步描述，将由验证系统支持的逻辑/规范语言的性能（P）的初步描述。在所有可能的输入条件下M能够正确地推出P的断言，从而验证性能P。证明标准的完备性保证了在所有可能的输入状态下，该设计的性能都是正确的。已经有很多的理论证明系统在大型的设计中得以成功地运用，如在浮点指针单元和在复杂流水控制中。同模型校验一样，理论证明验证也不需要创建任何验证测试平台，但是需要有待证明的性能公式。与模型校验不一样的是，理论证明验证不受输入规模和状态空间的限制。因此，理论证明验证更加适于基于数据通道的设计和高

12、层应用的功能验证，如浮点指针单元和复杂流水控制中冒险的验证等。同时，理论证明验证还能用于性能检查中，就如同在一个设计的两个模型之间的等价性校验一样。但是对两个模型的等价性检验而言，在运用系统验证语言对两个模型进行描述之后，还得给两个模型写一个合适的断言并对之加以证明。通过理论证明的验证的主要缺点就是它不如模型校验那样自动化程度较高。因为在通过理论证明的验证中，用户必须使用理论证明的命令进行交互式的证明。同时，另一个缺点就是在对某事件的证明失败时，验证系统无法自动构造搜索指针。用户必须通过人为的分析来寻找错误发生的原因。,2019-6-9,谢谢观赏,12,硬、软件联合验证,在传统的系统设计的串行

13、流程中，首先构造硬件，然后在硬件的基础上编写和调试系统软件。但是在硬、软件联合验证技术中，对系统硬件和软件的验证是同时进行的。在硬件被开发的同时，相应的软件也在硬件仿真平台中执行，这样就实现了硬件和软件的并行调试。虽然联合验证环境的建立需要大量的时间和丰富的经验，但是使用硬、软件联合验证技术的回报也是十分丰厚的。首先，使用硬、软件联合验证技术能够在SOC芯片制造之前就能发现并纠正许多系统级漏洞和问题。在实际的处理器和固件模型中进行的仿真，结果会更加精确，而且同旧的使用总线传输模型的设计流程比较起来，可以进行更广泛的验证。而且，在仿真过程中，软件也得到了调试和验证。相应的允许在芯片实际生成的同时

14、，给系统的发展提供较高的发展速度。最终结果是，硬、软件联合验证技术通过在设计的早期就很快的解决了问题而提高了整个产品开发周期的质量，节省了时间和金钱。,2019-6-9,谢谢观赏,13,硬件仿真,硬件仿真器是通常由某些可重构逻辑（通常为现场可编程门阵列，如FPGA）组成的专门设计的硬件和软件系统。编程这些系统以模仿设计目标的行为和功能，甚至达到将仿真过的设计同设计即将在其中操作的系统的剩余部分直接连接的程度。由于这些系统是以硬件为基础的，因此，它们能够提供与最终设计目标接近的电路仿真速度。这些几千Hz的速度同以软件为基础的仿真所提供的几十Hz的速度形成鲜明的对比。这种几个量级的行为差异使得模拟

15、技术能够执行在软件硬件仿真时要用几个月甚至几年才能完成的大型验证任务。这种验证任务的例子包括数据集的处理如视频数据流等，或者是有成千上万行的软件如操作系统的引导程序等。在带有嵌入式处理器的SOC在转化至硅片之前，在软件在与周围逻辑协同工作时，需要硬件仿真技术或样机技术对软件在嵌入的处理器上运行时的复杂功能进行验证。正因为这样，通常认为这种硬件仿真系统在并行设计流程中是介于硬件和软件之间的。,2019-6-9,谢谢观赏,14,硬件仿真,有很多不同的体系结构都借用这种硬件仿真系统来提供灵活性、可控性、可视性和性能。这些体系结构包括FPGA的互联阵列，自定义处理器阵列，带有可编程纵横切换器的磁头系统

16、和可编程总线接口的系统等。这些不同的体系结构能够在设计容量、行为特性和最优布局结构方面能提供一定程度的折衷方案，并且力图能够兼容并辅助包括其他验证技术如软件模拟、时序验证、形式化验证和逻辑分析的验证方法。虽然硬件仿真的设计方案是从建立在一般的硬件平台上的，但是在某种程度上可以看作有限精度的样机。通常硬件仿真器支持对设计的内部节点保持高度的可观察性，使设计在更类似于模拟而非真实物理样机的方式除错。事实上，因为软件模拟器与仿真器交互工作的方式在本质上与硬件模拟加速器相同，有时仿真器也用作模拟目的。虽然硬件仿真器有时候能够接近最终设计的速度，但是，除非它们能够同与最终设计一样的系统相联，否则，它们的

17、速度仍将受到限制。另外，硬件仿真系统的成本往往限制了一个项目中允许的系统数目，反过来，这又限制了能够同时运行硬件仿真的工程师的数目。,2019-6-9,谢谢观赏,15,物理样机,一种目标设计的硬件代替品，它的运行能够“接近”目标设计平台的性能。执行速度能够比软件仿真系统的速度快出许多。物理样机能够支持以下功能：在SOC器件可用之前，应用软件和系统软件的开发和调试 系统的系统级性能测试 目标设计的高性能仿真平台，该设计能支持复杂测试周期 具有支持硬、软件联合仿真的硬件平台和软件环境 用于测试的逻辑分析接口 目标设计的市场演示 典型情况下，物理样机在与目标系统速度相同的数量级范围内运行，因此，它的

18、执行速度能够比软件仿真系统的速度快出许多。这意味着全部的测试序列都能够装载到物理样机中去，并同系统级验证测试向量一起运行。在考虑到可以样机化的设计的数目、执行速度以及性能变化时间时，通过不同的方法得到的样机就会有不同的性能。在以下系统中都可以在SOC设计上建立可重用的样机：硬件仿真系统的样机 可重构样机系统 专用样机系统,2019-6-9,谢谢观赏,16,虚拟样机,一个虚拟样机就是一个产品、一个元件或一个系统的计算机模拟模型。同其它基于其自身特性的“模型”术语不一样的是，“虚拟样机”这个术语并不是指任何特殊的模型特性，而指在设计流程中做模型的角色。一般来说，一个虚拟模型应该支持下列任务：l 试

19、探开发设计的替代品l 证明设计的概念l 测试需求的满意度和正确度虚拟样机可以在各个抽象的层次上构建也可以包含一个多层次的混合体。在一个设计系统中可以有一个和几个虚拟样机同时存在，每个虚拟样机都能完成上述所说的任务。为了能在更大的设计系统中发挥作用，一个虚拟样机应该对设计的元件或系统的接口进行定义。与物理样机相比，物理样机需要有详细的硬件和软件设计描述，而虚拟样机能够更快、更有效、更加抽象而且在设计流程中能够更早的加以构建。因此，其中的一个区别就是，虚拟样机作为一个计算机仿真器，比起物理样机的常规操作来，能提供有关内部状态的更多的，无害的可视化信息。此外，与物理样机相比较而言，虚拟样机的一个主要

20、缺点就是，它的操作速度同软件仿真器的速度十分接近，因此就限制了在一定的时间内所能完成的验证数目。,2019-6-9,谢谢观赏,17,适合于等价性验证的工具和技术,动态验证形式化等价性检验 物理验证,2019-6-9,谢谢观赏,18,等价性验证中的动态验证工具和技术,确定性仿真：给模型施加明确定义的信号，产生相应的响应，在将仿真结果与预期值比较。一旦在RTL级模型上的验证平台和验证测试向量被开发出来，那么同样地验证向量集合也能在门级网表上对原设计进行仿真，以检查结果是否相同。在有些情形下，也有可能在对同样的设计的高层或者低层仿真过程中进行同样的验证测试。预期结果检查：对仿真结果同先前指定了的预期

21、响应文件进行比较。出现任何错误的时候，检查者就会报错。黄金模型检查：监视一个设计中两个模型的响应，将响应信号与输入激励相比较，并且对任何偏差作出标记。其中一个为“黄金模型”或可信任模型，而另外一个则是待证明的模型。一般情况下，这种比较不包括任何形式化验证技术，两个模型之间的响应信号比较仅基于信号的变化。验证测试序列的迁移：把系统级验证测试序列应用到设计的其它层次需要有可以将其迁移或转换为设计的RTL级或网表级应用序列格式的能力。包括：功能级向RTL级的迁移 和RTL级向网表级迁移。,2019-6-9,谢谢观赏,19,等价性验证中的动态验证工具和技术,回归测试：最通常用来验证一个设计的更改没有使

22、现有的验证测试产生失败。在一个设计上运行一个回归测试通常意味着两种验证环境属性：第一种是在自动化验证环境下，其中所有的EDA工具、验证测试过程及结果分析都能成批的进行；第二种真正回归测试方法的特点是测试的成功或失败都在批处理模式中实现。在每次运行的随机行为都等价时，回归测试最经常被用来与目的性模拟和随机向量模拟一起使用。Regression environment:用以收集，编译，并运行testbench和激励文件的机制。验证有一个很典型的问题，即在解决bug的的过程中，可能会无意识地引入另一个bug，在此时我们应该在其中加入regression测试组，帮助验证：在新特性加入、旧bug解除时，

23、现存的功能基本点得以保留。在整个项目的验证阶段，在验证的过程之中，一旦检测到bug，在regression测试组就应加入对bug的测试，这一点非常重要。regression测试组可以基于一个规则一定的基础。在同一个模型上的不同的环境context（如不同的激励向量序列，或反标时序）中运行验证工具（如模拟）。对于每次运行都同时备有建立pass/fail 状态的机制。,2019-6-9,谢谢观赏,20,形式化等价性检验,形式化等价性检验工具要证明的是：两个设计从I/O接口和基于一个接一个的周期的角度来看功能上是等价的。形式化等价性检验通常用在设计的RTL级和门级网表级。在有些情形下，也能用于更高或

24、者更低的模型。同软件仿真相比，形式化等价性检验具有几个优点。首先，与仿真不同，形式化等价性检验能够提供完整的等价性检验，而仿真只验证到一个验证测试组是否在设计中运行的程度。另外，形式化等价性检验能够在很短的时间内执行完需要复杂仿真才能完成的任务，这就有利于将验证和错误调试自动化。等价性检验工具通常会提供与小的独立逻辑块不匹配的详细“反例”。包括布尔等价性检验和时序等价性检验。,2019-6-9,谢谢观赏,21,形式化等价性检验,布尔等价性检验许多等价性检验工具是布尔等价性检验器，这意味着它们检验的是组合逻辑。运用这些工具，通常自动进行两个设计的存储元件（如触发器、锁存器等）间格式的比较，从而完

25、成对名词的映射。当映射确定以后，相应的工具就开始对存储器的每对映射名词的输入的组合逻辑开始检查是否等价。这意味着对每一种可能的输入组合，组合逻辑输出（也即存储器元件的输入）是相同的。时序等价性检验有这样一种情况：两个设计的存储元件的数目不同或排列不同，但是就输入输出数据流的生成以及在两个状态机之间给定的某些初始状态方面两者是等价的。这就是时序等价。这样的例子如有限状态机的两种实现方式：一个采用全译码方式，即用3个锁存器编码8个状态；另一种采用one-hot编码，用8个锁存器为8个状态编码。然而这两个状态机都有同样的输出/入数据信号，都开始于相同的初始状态，有相同的输入数据流。时序等价性检验比布

26、尔等价性检验存在更大的困难。因此能够执行这种任务的工具更加稀少。有很多的布尔等价性检验确实支持时序等价性检验，允许检验很小的有限状态机（通常用户必须手动地支持一些等价状态赋值的映射，因而限制了这种检验只能适合于小规模的状态机），或者允许检验某些组合逻辑器件跨越存储器元件边界的简单操作。但是，从实际的观点来看，总的说来大规模设计的时序等价性检验中有很多有待解决的问题。,2019-6-9,谢谢观赏,22,物理验证,物理验证就是通过检验图形设计的数据库以确信物理实现确实是原始逻辑设计的正确表述。物理验证包括以下三个部分：电学规则检验（以下简称ERC）、设计规则检验（以下简称DRC）及布线和电路图检验

27、（以下简称LVS）。标准的图形数据库形式是GDSII数据流。一个设计的GDSII数据流数据库包括电路的多边形表述，并对目标设计划分成不同的设计层次。ERC指的是检验图形数据库是否有与电学设计规则相违背之处。这些电学规则就是流程说明，并包含检验是否有无用输入，浮点输入和装载冲突等。还检验连接是否合法，如短路和短接。DRC指的是检验图形数据库是否有与设计流程规则相违背之处。这些规则收集在DRC规则文件中，并包含层与层之间的空间检验、布线宽度、层与层的相互重叠等。LVS就是检验提取的图形数据库是否有与“黄金”网表相违背之处。LVS工具从多边形数据中构建网表以及从物理布局中提取器件模型。提取出的网表需

28、和“黄金”模型保持一致。所有的器件和互连都必须严格地相匹配。其他的影响时序的物理验证如信号的完整性、串扰、金属迁移、噪音等不在功能验证论述的范围内。,2019-6-9,谢谢观赏,23,VC验证,VC验证包含目的性验证和等价性验证。目的性验证可以在任何层次完成。但是，应该指出的是，所应用的抽象层次越高，验证的效率就越高。现在，因为RTL级是在设计和验证过程中许多工具所能提供的最高抽象层次，所以通过在设计过程中使用许多工具（如比如模型验证、等价性检查、代码覆盖率等），目的验证的典型情况在RTL级完成。等价性验证必须至少在设计分解的最底层（如GDSII流，网表等）同黄金模型（在先前目的验证中已验证的

29、模型）进行验证时也能通过验证。一般很多（当然不一定是所有的）中间设计抽象也都需要进行验证。,2019-6-9,谢谢观赏,24,集成块验证,集成块验证包含目的性验证和等价性检验，它致力于验证含有一个或多个VC的SOC。因为其目的是验证一块集成的SOC而不是单个的元件，在验证中可以使用“灰箱”模型。它们精确地模拟VC的接口而非VC的内部功能。虽然集成块测试无需重复VC提供者执行的VC验证，但集成者还是想知道VC验证计划来评定/证明VC。第六部分就提供了有可能被验证的模型层次的小结。由于集成块验证以VC提供者难以预期的方式激励VC，因此，于VC自身而言，对含有全部内部功能的“白箱”模型的验证在错误探

30、测方面具有大的发展潜力。,2019-6-9,谢谢观赏,25,功能验证映射,左表给出了不同的功能验证模型和技术与不同的验证步骤之间的对应关系。,2019-6-9,谢谢观赏,26,验证衡量方法,以下部分所描述的技术和工具，可以用来衡量对某设计验证的完备性：一、硬件代码覆盖率：可以在仿真过程中通过硬件代码覆盖率分析工具来评定验证测试序列的覆盖率指标。把特定的测试验证序列输入到特定设计中，通过代码覆盖率分析就有可能得出功能覆盖率的某些方面的信息。分析工具可以提供以下信息：每个被评估属性的百分比的覆盖率值设计中没有执行或者只是部分执行的区域的列表代码覆盖率分析通常是在设计流程的RTL级上进行的，评估的是

31、以下类型的覆盖率：语句覆盖率：表明每条语句被执行的次数；信号触发覆盖率：表明设计信号中的哪一位被触发；有限状态机覆盖率：表明进行了多少个有限状态机的转变过程，可以视为路径覆盖率的一部分；被访问状态覆盖率：表明有限状态机有多少个的状态参与了仿真；触发覆盖率：表明每个进程是否被敏感度列表中的每个信号唯一触发到；分支覆盖率：表明哪一条“case”或者“ifelse”语句被执行；表达式覆盖率：表明“if”条件布尔表达式或赋值布尔表达式的执行的好坏程度；路径覆盖率：表明通过“ifelse”和“case”顺序结构的哪条路径被执行；信号覆盖率：表明状态信号或ROM寻址的执行的好坏程度。,2019-6-9,谢

32、谢观赏,27,验证衡量方法,二、功能覆盖率功能覆盖率是一种由用户定义的、反映在验证过程中被运行到的功能点的范围的衡量方法。功能点可以是对VC用户而言可视的体系结构特点，也可以是主要的微结构特征。通常情况下，这些特征不能从实现中自动生成，因此需要在验证testbench中的一些规范。功能覆盖率数据一般是一些时序行为（如总线的交易）和一些数据（如交易源、目的和优先级等）的交叉组合。附加覆盖率信息可以从功能覆盖率点的交叉引用中得到。比如，在一个器件的两个引脚之间进行的数据处理的相互关系，或者在一个处理器中指令和中断的关系等。与代码覆盖率不一样的是功能覆盖率的指标需要开发者自行定义。一个好的定义不仅与

33、验证平台紧密相关，而且应覆盖VC中的所有主要特征。因此，功能覆盖率比代码覆盖率的要求更加严格。经验表明，功能覆盖率与bugs/每周衡量法之间有紧密联系。虽然有些方面可以在更低或者更高的层次上评估，功能覆盖率分析通常还是在设计的RTL级上进行。,2019-6-9,谢谢观赏,28,Terminology(1),Branch coverage:确定在模拟中运行到了哪些RTL源代码的分支的代码覆盖率类型。Code coverage:一种通过报告被模拟过的RTL源代码以测量覆盖率的测量方法。代码覆盖率的类型包括语句，分支，条件和触发器覆盖率。Condition coverage:检查条件语句中的子表达式

34、以确定那些子表达式的哪些值导致了在模拟中高一层表达式为真/假的代码覆盖率类型。Finite state machine(FSM)coverage:Metric that measures coverage by reporting which states,transitions,and/or input patterns of an FSM have been simulated.Compiled stimulus:C,assembly,or other language higher than a binary representation that is compiled into bi

35、nary.Configuration:Collection of set up values applied to the configurable modules.,2019-6-9,谢谢观赏,29,Terminology(2),Logic checking(also equivalence checking):Use of formal mathematical methods to determine if the boolean functions of two designs are the same;typically performed automatically using a

36、 software program.Master mode:Mode in which the processor executes code from either internal or external memory.Mux checking(also one-hot checking):Use of formal mathematical methods to determine if the high-impedance multiplexors in a design all exhibit the property that one and only one enable is

37、active at a time;typically performed automatically using a software program.Pin:External physical connection.Regression:一种在同一个模型上的不同的环境context（如不同的激励向量序列，或反标时序）中运行验证工具（如模拟）的做法。对于每次运行都同时备有建立pass/fail 状态的机制。Regression environment:用以收集，编译，并运行testbench和激励文件的机制。,2019-6-9,谢谢观赏,30,Terminology(3),Simulation

38、:Process of applying a stimulus pattern to a software model that propagates the effect of input stimulus changes as if the model was the actual device.The software model allows for various kinds of monitoring,probing and debugging tools to be run in conjunction with the simulation.Master mode:Mode i

39、n which the processor executes code from either internal or external memory.Slave mode:Mode in which processor bus is directly controlled by a bus driver.At the SoC level,this requires the SoC to support an external bus interface(EBI)or other means to access the bus from the outside.Specification co

40、verage:Metric that measures coverage by reporting how many factual attributes in the specification have been demonstrated to be true during simulation.Statement coverage:Type of code coverage that determines which executable statements in the RTL source code have been executed during simulation.Test

41、 mode:Mode in which special factory test features are enabled.,2019-6-9,谢谢观赏,31,Terminology(4),Stimulus:Definition for a specific set of state changes(e.g.,transactions)to be applied to the DUT through a suitable testbench and drivers/monitors.May or may not also specify constructs to analyze respon

42、se values generated by the DUT.Testbench:Verification-specific constructs that provide the glue between the DUT,driver,monitors,and stimulus.Toggle coverage:Type of code coverage that checks that each node in a gate level representation changes polarity(toggles)during simulation and so is not stuck

43、at one level.Vector:Single unit of stimulus and response.It specifies stimulus by assigning a zero,one,or Z to each input and bidirectional pin,and it specifies response by assigning a zero,one,Z,or X to each output and bidirectional pin.Contention must be avoided on bi-directional pins by conformin

44、g to the following constraints:If the pin is stimulated with zero or one,its expected response must be specified as X.If the expected response of the pin is zero or one,it must be stimulated with Z.,2019-6-9,谢谢观赏,32,验证技巧及语言风格,1.Coding for Verification2.Testbench3.Drivers and Monitors4.Detailed Behav

45、ioral Model for VC5.Detailed Behavioral Model for Memory6.Detailed Behavioral Model for I/O Pads7.Stub Model8.Stimulus9.Simulation Scripts10.Coverage11.Formal Logic Equivalence Checking12.Functional Coverage13.Formal Model Checking14.Emulation,2019-6-9,谢谢观赏,33,1.Coding for Verification,标准编码指南帮助VC设计者

46、和集成者共享设计数据并开发SoC解决办法。以下规则和指南主要适用于Verilog HDL.1.General Rules and Guidelines2.Symbolic Constants3.Routines4.Signal State and Time,2019-6-9,谢谢观赏,34,2.Testbench,下面讲述VC testbench和系统级 testbench的标准.这些规则和指南要求一个由激励、序列控制、时钟、driver和monitors之间的接口组成的testbench的体系结构.见Figure 9-1.,2019-6-9,谢谢观赏,35,2.Testbench,1.Clo

47、cking2.I/O and Pads3.Messages4.Termination5.Synchronization6.External Interface Functions7.Configuration Control8.VC Reset,2019-6-9,谢谢观赏,36,3.Drivers and Monitors,9.4.1 Testbench Interface9.4.2 Drivers9.4.3 Monitors9.4.4 Common Command Set,2019-6-9,谢谢观赏,37,4.Detailed Behavioral Model for VC,The deta

48、iled behavioral model for VC(block behavior checker)watches requests that come into a unit,and verifies the proper response on some other interface.Block behavior checker verifies that operations are happening and that the results are correct.Detailed behavioral models for VC should only describe de

49、tails that are functionally relevant and not convey intellectual property.R 9.5.1 Configure the detailed behavioral model independent of the VCBlock behavior checkersmust be configured via the testbench,stimulus,and/or monitors.Configuration of the behavioral must not occur based on the internal VC

50、state.Behavioralsmay be used to preload states into the VC.Reason:Problems with the VC configurationmay be masked.This provides independent verification of the VCoperation and configurationmechanism.,2019-6-9,谢谢观赏,38,5.Detailed Behavioral Model for Memory,Memory array models are verification compone