SV学习笔记(六)-验证环境结构

验证环境结构

概述

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

测试平台结构图

在这里插入图片描述

所有TB的组件跟DUT的连接都通过接口(interface)

  • stimulator:发送激励
  • DUT:被测硬件电路(RTL)
  • monitor:监测激励
  • checker:比较数据
  • clock/reset:时钟/复位信号

测试平台总结

  • 各个组件之间是相互独立
  • 验证组件与设计之间需要连接-interface(接口)
  • 验证组件之间也需要进行通信-mailbox(信箱)
  • 验证环境也需要时钟和复位信号的驱动-时序

验证环境组件

激励发生器
  • Stimulator(激励发生器)是验证环境的重要组件,在一些场合中,它也被称为driver(驱动器)、BFM(bus function model,总线功能模型),behavioral(行为模型)或者generator(发生器)
  • Stimulator的主要职责是模拟与DUT相邻设计的接口协议,只需要关注于如何模拟接口信号,使其能够以真实的接口协议来发送激励给DUT
  • Stimulator不应该违反协议,但不拘束于真实的硬件行为,还可以给出更多丰富的只要协议允许的激励场景
  • 比真实硬件行为更丰富的激励,会使得在模块级的验证更加充分,因为它不但验证过了硬件普通的接口协议场景,还模拟出更多复杂的,在更高系统级别无法产生出来的场景
  • Stimulator的接口主要是同DUT之间连接,此外,也应该有时钟和复位的输入,确保生成的数据同DUT的接口一侧是同步的关系
  • 较精细的stimulator还可以有其它的配置接口用来控制接口的数据生成
  • Stimulator也可以有存储接口数据生成历史的功能,这可以用来在仿真运行时或者结束后查看接口数据,方便统计和调试
  • 从stimulator和DUT的连接关系来看,可以将其分为两种:initiator(发生器)、responder(响应器)
    • 与下行通道从端(channel slave)的连接或寄存器接口的连接,这两部分的stimulator都属于initiator,功能是主动发起接口数据传输
    • 与formatter接口连接,则stimulator属于responder,功能是对接口的数据发送请求做出响应,而它本身不会主动发送数据(被动响应DUT的信号)
监测器
  • Monitor(监测器)的主要功能就是用来观察DUT的边界或者内部信号,并且经过打包整理传送给其它验证平台的组件,例如checker(比较器)
  • 从监测信号的层次来划分monitor的功能,可以分为观察DUT边界信号和观察DUT内部信号
    • 观察DUT边界信号:对于系统信号如时钟,可以监测其频率变化;对于总线信号,可以监测总线的传输类型和数据内容,以及检查总线时序是否符合协议
    • 观察DUT内部信号:从灰盒验证的手段来看,往往需要探视DUT内部信号,用来指导stimulator的激励发送,或者完成覆盖率手机,又或者完成内部功能的检查
  • 如果没有特殊的需求,我们应采取灰盒验证的策略而非白盒
  • 观察的内部信号应当尽量少,且应当是表示状态的信号,不建议采集中间变量信号的原因在于:这些信号的时序,逻辑甚至留存性都不稳定,这种不稳定对于验证环境的收敛是有害的
  • 可以通过接口信息计算的,就尽量少去监测内部信号,因为这种方式也有悖于假定设计有缺陷的验证思路。我们观测的内部信号在被环境采纳之前也有必要确认他们的逻辑正确性,这一要求可以通过动态检查或者断言触发的方式来实现
比较器
  • 无论是从实现难度,还是从维护人力上来讲,checker(比较器)都应当是需要时间投入的验证组件
  • checker减负了模拟设计行为和功能检查的任务
  • 缓存从各个monitor收集到的数据
  • 讲DUT输入接口测的数据汇集给内部的reference model(参考模型)在这里扮演了模拟硬件功能的角色,也是需要较多精力维护的部分,因为验证者需要在熟悉硬件功能的情况下实现该模型,而又不应参考真实硬件的逻辑
  • 通过数据比较的方法,检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致
  • 对于设计内部的关键功能模块,也有相对应的线程进行独立的检查
  • 在检查工程中,可以将检查成功的信息同一纳入到检查报告中,便于仿真后的追溯。如果检查失败,也可以采取暂停仿真同时报告错误信息的方式进行在线调试
  • 分类
    • 线上比较(online check):在仿真是收集数据和在线比较,并且实时报告
    • 线下比较(offline check):将仿真时收集到的数据记录在文件中,在仿真借宿后,通过脚本或者其它手段进行数据比较
  • 在硬件设计发展初期,由于DUT的功能较为简单,采取定向测试(directed test)和线下比较的方式就不足为奇,甚至验证者没有数据处理脚本或者参考模型,进行人为比较(manual check)的古老方式也是存在的
  • 伴随着设计的功能越发复杂,靠验证者进行繁琐检查的方式也缺少可靠性
  • 于是将checker添加到验证环境中,需要它分析DUT的边界激励,理解数据的输入,并且按照硬件功能来预测输出的数据内容
  • 这种预测(prediction)的过程,发生在reference model中,有事也称之为predictor
  • reference model也会内置一些缓存,分别存放从DUT输入端观察到的数据,以及经过功能转换的数据,同时checker也有其他缓存在存放从输出端采集到的数据
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值