• SystemVerilog学习 (6)——验证平台


    一、概述

            测试平台(Testbench)是整个验证系统的总称。它包含了验证系统的各个组件、组件之间的互联关系,测试平台的配置与控制等, 从更系统的意义来讲,它还包括编译仿真的流程、结果分析报告和覆盖率检查等。 从狭义上讲,我们主要关注验证平台的结构和组件部分,他们可以产生设计所需要的各种输入,也会在此基础上进行设计功能的检查。

    二、验证平台结构图

            我们在刚开始介绍SV的时候就介绍了完整的验证平台结构应该包含哪些部分:

    ee5b86b52b504014bba1b11f43593f63.jpeg

            这里我们先从一个最简单的测试平台开始,先把平台搭建起来,再根据需求进行逐步完善。在这里我们暂时只考虑驱动器(也叫激励器Stimulator),监测器(Monitor),比较器(Checker)。

    三、激励发生器Stimulator

             Stimulator(激励发生器)是验证环境的重要部件,在一些场合中,它也被称为driver(驱动器)、BFM(bus function  model,总线功能模型),behavioral(行为模型)或者 generator(发生器)。

    1、功能

             Stimulator的主要职责是模拟与DUT相邻设计的接口协议,只需要关注于如何模拟接口信号,使其能够以真实的接口协议来发送激励给DUT。

    2、分类

             从stimulator同DUT的连接关系来看,我们可以将其进一步分为两种:initiator( 发起器)和responder(响应器)。

            对于 initiator,它的功能是主动发起接口数据传输;对于 responder,它的职责是对接口的数据发送请求做出响应,而它自身并不会主动发送数据。

    四、检测器Monitor

    1、功能

            Monitor(监测器)的主要功能是用来观察DUT的边界或者内部信号,并且经过打包整理传送给其它验证平台的组件,例如 checker(比较器)。

    2、分类 

             从监测信号的层次来划分monitor的功能,它们可以分为观察 DUT 边界信号和观察 DUT 内部信号。

    • 观察DUT边界信号。对于系统信号如时钟,可以监测其频率变化;对于总线信号,可以监测总线的传输类型和数据内容,以及检查总线时序是否符合协议。
    • 观察DUT内部信号。从灰盒验证的手段来看,往往需要探视 DUT内部信号,用来指导stimulator的激励发送,或者完成覆盖率收集,又或者完成内部功能的检查。

    3、注意事项

    1.  如果没有特殊的需要,我们应采取灰盒验证的策略(而非白盒)。
    2.  观察的内部信号应当尽量少,且应当是表示状态的信号。不建议采集中间变量信号的原因在于,这些信号的时序、逻辑甚至留存性都不稳定,这种不稳定对于验证环境的收敛是有害的。
    3.  可以通过接口信息计算的,就尽量少去监测内部信号,因为这种方式也有悖于假定设计有缺陷的验证思想。我们观测到的内部信号在被环境采纳之前也有必要确认它们的逻辑正确性,这一要求可以通过动态检查或者断言触发的方式来实现。

    五、比较器Checker

            无论是从实现难度,还是从维护人力上来讲,checker(比较器) 都是最需要时间投入的验证组件了。

    1、功能

             checker肩负了模拟设计行为和功能检查的任务。 缓存从各个monitor收集到的数据。 将DUT输入接口侧的数据汇集给内置的reference model (参考模型)。Reference model在这里扮演了模拟硬件功能的角色,也是需要较多精力维护的部分,因为验证者需要在熟悉硬件功能的情况下实现该模型,而又不应参考真实硬件的逻辑。 通过数据比较的方法,检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致。

    2、分类

    2.1 线上比较(online check)

            在仿真的时候收集数据和在线比较,并且实时报告。

    2.2 线下比较(offline check)

            在仿真时,收集数据记录到文件中,在仿真结束后,通过脚本或者其它手段,进行数据比较。

            在硬件设计发展初期,由于DUT的功能较为简单,采取定向测试(directed test)和线下比较的方式就不足为奇了,甚至验证者没有数据处理脚本或者参考模型,进行人为比较(manual  check)的古老方式也是存在的。而伴随着设计的功能愈加复杂,靠验证者每次进行繁琐检查的方式也缺少了可靠性。于是我们将checker添加到验证环境中,需要它分析DUT的边界激励,理解数据的输入,并且按照硬件功能来预测输出的数据内容。

    3、使用建议

             对于复杂的系统验证,我们倾向于集中管理stimulator和checker,因为它们两者都需要主动给出激励或者判断结果,也需要较多的协调处理。而monitor则相对更独立,因为它只是作为监测方,将其兢兢业业观察到的数据一字不落地交给checker即可,至于checker怎么使用,monitor并不需要关心。因此,stimulator和monitor是一一对应,我们通常将它们进一 步封装在agent单元组件中,而checker则最终集群搁置在中心化的位置。

     

  • 相关阅读:
    曼孚科技入选IDC中国数据智能市场代表厂商
    Chrome浏览器调试页面详解 | 青训营笔记
    【无标题】
    嵌入式接口复习资料
    若依框架维护问题
    零基础学Java第二十七天之前端-HTML5详解
    SCA Nacos 服务注册和配置中心(二)
    GAMES104-如何构建游戏世界
    ISPRS2022/云检测:Cloud detection with boundary nets基于边界网的云检测
    vue开发前的入门准备
  • 原文地址:https://blog.csdn.net/apple_53311083/article/details/134419436