【路科V0】验证环境1——验证环境结构

验证环境结构

        测试平台(testbench)是整个验证系统的总称。

        它包括验证结构中的各个组件、组件之间的连接关系、测试平台的配置和控制。

        从更系统的意义来讲，它还包括编译仿真的流程、结果分析报告和覆盖率量化等。

        从狭义上讲，我们主要关注验证平台的结构和组件部分，他们可以产生设计所需要的各种输入，也会在此基础上进行设计功能的检查。

测试平台(testbench)结构图

典型验证结构框图

验证结构： 

• 待测设计：DUT
• 验证必备组件：激励发生器、监测器、比较器

验证过程：

        激励发生器按照接口协议时序和测试场景，生成对应的激励向量

        待测设计接收了这些数据之后，需要做出响应

        监测器通过将待测设计的输入端和输出端数据监测，发送至比较器

        比较器将这些数据进行预测和比较，发现有问题的数据。继而协助验证工程师调试设计。

        如果设计有缺陷，需要修复该设计。修复设计之后，仍然需要交付测试平台，进行反复测试，直到出错的测试可以顺利完成

        此外，测试平台和待测设计，都需要时钟/复位。这是为了能够向设计发送同步的激励数据。

验证结构特点：

• 各个组件之间是相互独立的
• 验证组件与设计之间需要连接（通过接口interface）
• 验证组件之间也需要进行通信（利用线程通信完成。例如，监测器需要将监测数据打包发送给比较器）
• 验证环境也需要时钟和复位信号的驱动
• 验证组件及软件之间的通信就要自由的多（可以利用软件通信方式来完成）

主流验证语言

        过去的十年中，SystemVerilog的使用比例明显占据主导地位。

        Verilog和C/C++在验证部分也有其应用空间。

        借助于语言的统一趋势,方法学(UVM)）的统一也已经完成。

验证结构的层次 

        设计是由多个层次构成的,无论是物理分区例如FPGA/ASIC，还是逻辑分区例如合成单元/核心子系统。
        验证也可以按照不同的级别来安排目标。

设计对应的验证层次

         单元模块、核心模块、子系统、系统级、板级，测试的重点是不相同的。每个验证级别都有最合适的验证目标。

测试的重点

• 单元模块和核心模块：基础操作和功能
• 子系统级和系统级：数据流传输，子系统间的协调
• 系统间测试即板级联调时：系统间的连接和接口时序是否正常工作

        如果将不属于该级别的测试场景在该级别实现，那么会变得困难和难以覆盖。

        较小的模块更容易验证，因为它们提供更大的可控性和可观察性。

        对于它们，很容易设置条件和状态组合，并观察其反应是否符合预期。（这样的检查器关注的功能逻辑也不会太大，以至于无法聚焦）

        由小模块组成的子系统，则需要以较低的可控性和可观察性为代价去验证。（因此，测试子系统或者系统的重点变为测试模块之间、子系统之间的协作集成）

        也因此，不同级别的验证有着不同的验证重心。

        任何层次的待验设计，都应该具备相对稳定的接口和预期的功能。

        理想情况下，每个子系统或者模块，都应该有自己的硬件描述文档。（验证工程师只要依赖硬件描述文档，才可以展开制定验证计划和构建验证环境）

        在验证过程中，如果接口或者功能不断变化，那么测试平台也将一同发生变化，这毫无疑问将严重影响验证的进度。因此设计的接口和功能都应该逐步稳定下来，这对验证进度能否按时完成至关重要。

        对设计稳定性的要求，一般是先期待其接口稳定下来，再使得功能可以稳定下来。每一个功能都有对应的测试用例。待该层次所有测试用例都通过以后，转向下一个验证层次。