SystemVerilog学习（1）——验证导论

写在最前

        选课不慎，选修课选了个SystemVerilog，事情比必修还多，上课老师讲的一点用没有，但是学分还得修，只能自学了，既来之则安之。

一、什么是SystemVerilog

        SystemVerilog简称为SV语言，是一种相当新的语言，它建立在Verilog语言的基础上，是 IEEE 1364 Verilog-2001 标准的扩展增强，兼容Verilog 2001，将硬件描述语言（HDL）与现代的高层级验证语言（HVL）结合了起来，并成为下一代硬件设计和验证的语言。

        System Verilog是Verilog语言的拓展和延伸。Verilog适合系统级，算法级，寄存器级，逻辑级，门级，电路开关级设计而System Verilog更适合于可重用的可综合IP和可重用的验证用IP设计，以及特大型基于IP的系统级设计和验证。

        相比与HDL，HVL具有一些典型的性质：

        （1）受约束的随机激励产生

        （2）功能覆盖率

        （3）更高层次的结构，尤其是面向对象的编程

        （4）多线程及线程间的通信

        （5）支持HDL数据类型，例如Verilog的四状态数值

        （6）集成了事件仿真器，便于对设计施加控制

        简单说，SV是建立在Verilog基础上的，一种用于验证的语言（其实也可以用于设计吧，毕竟很多综合工具都是支持SV的）。

二、验证流程

        验证的流程并行于设计的流程。对于每个设计模块，设计者需要首先阅读硬件描述规范，解析自然语言描述，然后使用RTL代码之类的机器语言创建相应的逻辑。为了完成这个过程，设计者需要知道输入格式，传输函数和输出格式，解析过程中总会有模糊的地方，原因可能是规范文档本身的表达不清楚，遗漏了细节或者细节不一致。验证工程师也必须阅读硬件规范并拟定验证计划，创建测试来检查RTL代码是否准确实习了所有的特征。

三、基本测试平台功能 

        测试平台的用途在于确定待测试的正确性。包含下列步骤：

        （1）产生激励

        （2）把激励施加到DUT上

        （3）捕捉响应

        （4）检测正确性

        （5）对照整个验证目标测算进展情况

四、分层的测试平台

        对于任意一个新型的验证方法学来说，分层的测试平台是一个关键的概念。虽然分层似乎会使得测试平台变得更加复杂，但是它能够把代码分而治之，确实有助于帮助测试工程师减轻自己的工作负担。不要尝试去编写一个包含所有功能的子程序，用它来随机产生所有类型的激励，包含合法的非法的，并使用多层协议进行错误注入。这样的子程序很快就会变得很复杂，并且难以维护。

4.1 信号与命令层

        下图是一个测试平台中最低的几个层次

        在底部的信号层，包含有待测试和把待测试设计连接到测试平台的信号。

        再往上一层就是命令层，执行总线读或者写命令的驱动器驱动了待测设计的输入。待测设计的输出与监视器相连，监测器负责监测信号的变化，并把这些变化按照命令分组。断言也穿过命令层与信号层，它们负责监视独立的信号以寻找穿越整个命令的信号变化。

4.2 功能层 

        下图为加上功能层的测试平台，功能层向下面对的是命令层。代理（在VMM 中称为事务处理器）接收到来自上层的事务，例如，DMA读或写，把它们分解成独立的命令。这些命令也被送往用于预测事务结果的记分板。检验器则负责比较来自监视器和记分板的命令。

4.3 场景层

        如图1.11所示，功能层被位于场景层中的发生器所驱动。什么是场景呢？记住一点，作为验证工程师，你的工作是确保待测设备能够完成预期的任务。一个设备案例是MP3 播放器，它能一边播放事先存储好的音乐，一边从一台主机上下载新的音乐，并且同时对用户输人如音量调整或音轨控制等操作保持响应。这中间的每一个操作都能称为一个场景。下载一个音乐文件需要若干步骤，例如前期准备时的控制寄存器读和写、歌曲传送过程中多次DMA写，以及之后的很多读写操作。场景层就是负责组织协调这些步骤的，操作的参数如音轨大小和寄存器位置等都采用受约束的随机值。
        在测试平台环境中的这些块（位于图1.11虚线框内）是在刚开始开发的时候画出来的。随着项目的进展，它们可能会有一些变化，你也可能会加入一些功能，但是这些块对于每个独立的测试都是不应该改变的。可以通过在代码中留下"钩子"来做到这一点，这样即使这些块的行为需要在测试时改变，也不必重新编写代码。"钩子"可以使用工厂模式和回调函数来创建。

4.4 测试的层次和功能覆盖率

        现在到了测试平台的最顶层——测试层，如图1.12所示，待测设计模块间的漏洞是比较难以发现的，因为这些模块可能是不同的人按照不同的规范设计出来的。

        这个顶层的测试就像一个指挥官：他不演奏任何乐器，但引领着其他人的表演，测试包含了用于创建激励的约束。
        功能覆盖率可以衡量所有测试在满足验证计划要求方面的进展，随着各项测量标准的完成，功能覆盖率代码在整个项目过程中会经常变化，由于代码经常被修改，所以它不作为测试环境的组成部分。
        你可以在受约束的随机环境中创建"定向测试"。只需在随机序列中间插人定向测试的代码，或者把两部分代码并列。定向代码执行你期望的任务，而随机的"背景噪声"可能会使漏洞暴露出来，而且漏洞还有可能是在你从来没有想到过的模块里。
        在你的测试平台中是否需要所有的层次呢？答案要视待测设计而定。设计越复杂。则所需的测试平台就要越完备。测试层则是必须的。对于一个简单的设计来说，场景层可能过于简单以至于可以把它合并到代理中。在估算对一个设计进行测试所需要的工作量时。不要以门数作为计算依据，而应该考虑设计人员的数目。每次往设计团队里增加一个人员，就意味着同时也增加了一种对规范的不同解读。
        当然，你可能还需要更多的层次。如果你的待测设计有多个协议层，那么每个层都应该在测试平台环境中有对应的层。例如，你使用IP封装了TCP流量，然后通过以太网数据包的形式发送，对这种情况的测试应该考虑使用三个独立的层来产生和校验数据。如果能够使用已有的验证构件则更好。
        图1.12中需要注意的最后一点是，它只给出了各块之间一些可能的连接方式，你的测试平台模块间的连接可能会与之不同。比如你的测试层可能需要连接到驱动器层以迫使物理漏洞出现。这里给出的只是一些引导——实际当中应该是，你需要什么就创建什么。