• 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中需要注意的最后一点是,它只给出了各块之间一些可能的连接方式,你的测试平台模块间的连接可能会与之不同。比如你的测试层可能需要连接到驱动器层以迫使物理漏洞出现。这里给出的只是一些引导——实际当中应该是,你需要什么就创建什么。

  • 相关阅读:
    企业跨境出海选择AWS怎么样?
    Ubuntu 安装Kafka
    nginx-vts监控模块
    Scrapy第八篇:User-Agent中间件
    删除安装Google Chrome浏览器时捆绑安装的Google 文档、表格、幻灯片、Gmail、Google 云端硬盘、YouTube网址链接(Mac)
    一对一语音直播系统源码——如何解决音视频直播技术难点
    大数据,对于生活的改变
    苹果修复了旧款iPhone上的iOS内核零日漏洞
    最详细的Hashmap源码解析
    标识密码技术在 IMS 网络中的应用
  • 原文地址:https://blog.csdn.net/apple_53311083/article/details/133953016