【数字IC验证快速入门】29、SystemVerilog项目实践之AHB-SRAMC（9）（AHB-SRAMC SVTB Overview）

导读：作者有幸在中国电子信息领域的排头兵院校“电子科技大学”攻读研究生期间，接触到前沿的数字IC验证知识，旁听到诸如华为海思、清华紫光、联发科技等业界顶尖集成电路相关企业面授课程，对数字IC验证有了一些知识积累和学习心得。为帮助想入门前端IC验证的朋友，思忱一二后，特开此专栏，以期花最短的时间，走最少的弯路，学最多的IC验证技术知识。

一、内容概述

• AHB-SRAMC 验证计划
• AHB-SRAMC 验证平台的架构图
• AHB-SRAMC 验证平台的代码目录
• 如何跑一个简单的仿真
  • 编写 Makefile 编译代码并且跑仿真
• 如何利用波形进行调试验证平台
  • 如何利用VSIM调用波形文件
  • 通过查看interface上的信号，确认激励是否正确
  • 通过查看interface上的信号，确认响应是否正确

二、AHB-SRAMC 验证计划

• 验证目标
  • RTL VS Specification
    • 针对 Specification 中的 Feature 去分解测试点（Test point）构造测试用例（Test case），而后去验证RTL是否满足Specification的要求。
  • Code Coverage：line，interface toggle，（FSM，Expression，Path）【客观】
    • 通过覆盖率，来衡量我们的验证进度
  • Function coverage【主观】
    • 自己去建模，自己去建立cover group，然后针对要覆盖的点去写cover point
  • 完备性、正确性、协议符合型、容错处理
    • 完备性要求我们一定要在 Specification 基础上将 Feature 分解全！
    • 正确性要求我们构造的用例需要真pass，整个环境的check要比较全面
    • 协议符合型要求我们要符合协议，在该项目中就是AHB协议了
    • 容错处理这个异常处理场景也需要去考虑，如何构造异常场景包（用例）
      • 如：地址addr和size要对齐，假如size是16bit，那么地址可以发0或者2，不能发1或者3。这个容错处理就是讲，如果发了1或者3，不能让我们的总线挂死！这个也要作为Feature的测试点列出来！
• 验证语言
  • SystemVerilog
• 验证平台架构
• 验证策略
  • 覆盖率驱动的验证策略
  • 白盒验证策略
  • 激励
    • 定向测试（极大、极小、边界跳转空间等）
    • 带约束的随机化验证策略
  • 基于断言的验证策略（测试内部信号跳变）
• 功能点划分（根据 Features 来分解测试点 testpoints，根据测试点再来构造测试用例 testcases）
  • Features
  • testpoints
  • testcases
    • 如：No.1 testcase：把SRAM的地址空间全部写1，然后再读全部是否为1
    • No.2 testcase：把SRAM的地址空间全部写0，然后再读全部是否为0
    • No.3 testcase：向SRAM中写8bit的数
    • No.4 testcase：向SRAM中写16bit的数
    • No.5 testcase：做一些随机…
    • …（这里仅仅举例，Testcase没有固定模板，每个人可能分解出来都不一样（思路、方法），但最终我们是要通过覆盖率来得到一个验收。）

三、SystemVerilog Testbench 架构图

注：当然此处的架构是原来的基础上简化的，我们实际使用会该其基础上再添加一个agent组件。

• data modeling 就是我们的transaction，即我们要发的数据内容。如AHB的transaction就包含：HSEL、HWRITE、HADDR、HWDATA…（定义一个calss，并将其定义为一个rand随机数）
• transaction 产生之后，便会在geneator产生具体的数据。geneator的主要作用是分各种场景，如：write32(Addr, Data)，其中Addr 和 Data 由Testcase来告知，generator 收到write32的命令后，就会把transaction 中的一些信号赋值：tr.hsel = 1'b1; tr.haddr=Addr; tr.trans=2'b10; tr.hsize=2'b10;。除了 write32 的命令，当然还会提供 read32、write8 等命令。generator 就要提供对SRAM操作的各种场景的接口，如何去用这些接口，是testcase来决定的。就像之前所讲，testcase就像音乐指挥家，generator里面就有很多乐器了，比如鼓手（write32）、吉他手（read32）、钢琴等，要去演奏一首歌曲时，什么时候鼓手动，什么时候吉他手动，都是指挥家（testcase）决定的。所以什么时候去用write32这些命令是testcase告诉他，告诉它之后，会根据wirte32的功能去把要发的数据值给填好，然后再通过mailbox传到driver。
• 当然本项目实际的架构，会在generator和driver之间加一个agent，agent除了能接收generator的数据并传送到driver，还可以将数据传送到scoreboard，如下图所示。

• generator会提供各种场景的数据产生方式，至于产生方式在用例中怎么用，是testcase来决定的，testcase会例化整个Environment。整个 hierarchy 最顶层是top，top下有多个testcase，如：testcase1、testcase2…。每一个testcase就会例化同一套ENV代码，ENV能支持多种testcase。每种testcase去调用generator里面的场景的函数是不一样的。

Top 
	---- Testcase0
		---- ENV
	---- Testcase1
		---- ENV	

• 1
• 2
• 3
• 4
• 5
• 6

• driver 的作用就是当tr给过来之后，按照AHB协议传输。产生数据的时候地址和数据同时产生，但是在driver的时候会先一个时钟周期发地址，再到下一个时钟周期发数据。
• 左边的 monitor 会把激励数据采集进来，并送到 scoreboard 去做一个check（送给Reference Model 做 Gold 模型输入的）。 右边的Monitor 是采集的结果，并把结果送到scoreboard做一个自动化的比对。
• reciver 一般是没有的
• coverage modeling 一般是指 function coverage

四、AHB-SRAMC 验证平台的目录结构

• 一级目录
  • ahb_sramc_svtb
• 二级目录
  • doc rtl verif
    • RTL就是架构图中的DUT
• 三级目录（verif展开）
  • agent env sim tb tests
    • env包含：Transaction、Generator、Agent、Driver、Scoreboard
    • tb包含：最顶层top的tb文件，还有就是interface
    • tests包含：各种testcase
    • sim包含：不会放.sv文件，一般放Makefile脚本，启动验证；还会放file list文件

当然它这个验证平台的目录架构有点模仿UVM的手法，UVM会把generator、driver、monitor这几个组件包裹在一个叫agent的组件中。当然我们做的话，就是按照SystemVerilog比较典型的calssic的去做。故我们实际去做的时候，三级目录中是每个agent的！

五、如何一步一步的编写SystemVerilog Testbench？

• 第一步，根据ahb_slave接口信号，编写 ahb_slave_interface
• 第二步，根据 ahb_slave 输入和输出接口，进行数据建模（Transaction）
  • 根据interface来产生数据包Transaction
• 第三步，编写数据生成模块 generator
  • 不同的场景对应的Transaction数据不一样，在generator中将各种scenario写出来，产生不同的Transaction
• 第四步，编写 agent 模块，仅仅是一个数据转发的功能
• 第五步，编写数据处理模块 driver
• 第六步，编写 monitor 模块，不然scoreboard无法比较！
• 第七步，编写自动比较模块 scoreboard（在这之前会）
• 第八步，根据Specification和接口信号，编写覆盖率模型（看覆盖情况，去增补用例）
• 第九步，编写测试用例 testcase

注：环境要能够进行testcase的扩展，ENV不变的情况下。

六、思考练习

• 编写AHB-SRAMC功能验证计划
• 构建AHB-SRAM控制器的验证平台目录结构
  • 在Linux 服务器上建立testbench的目录结构
• 如何利用SystemVerilog 语言一步一步的构建testbench？
• 如何利用带约束的随机化方法编写testcase？
• 对比AHB协议和波形文件，检查AHB Slave接口信号是否正确？
• 如何利用Makefile调用Questasim（VCS）运行仿真环境
• 如何利用Questasim（VCS）生成和仿真波形？

注：通过本文的学习，可能只会可以回答前两个问题，不过不要紧，我们继续往下学习，回头再看这些问题就会一目了然！

七、如何调试TestBench

注：一个一个模块去调试，这里以Questasim为例，后面实际例子以VCS进行详细演示！

• vlib work
  • 创建一个library
• vlog -sv -f rlt.f
  • 首先编译RTL设计代码，确认RTL代码没有编译问题
• vlog -sv -f rtl.f …/…/agent/ahb/ahb_slv_if.sv
  • 再增加编译自己编写的interface，其中的文件使用相对路径（相对于sim文件夹）
  • 确认自己编写的interface没有语法错误
• vlog -sv -f rlt.f …/…/agent/ahb/ahb_slv_if.sv …/…/agent/ahb_ahb_slv_pkt.sv …/…/agent/ahb/ahb_slv_generator.sv …/…/agent/ahb/ahb_slv_driver_vase.sv …/…/agent/ahb/ahb_slv_driver.sv
  • 依次编写packet（数据建模）、generator、driver等分层的SVTB功能模块
  • 并对每一个功能模块进行编译，并进行编译和仿真
• 编写test和tb_top模块，并进行编译和仿真
  • 通过查看DUT的端口的波形，确保所有的输入没有x或者z
  • 检查DUT的接口信号的输入是否是正确

八、Debug 分析及操作技巧

8.1、输入端口有X（出现红色）

• 仿真最前面出现红色的信号，而后恢复正常，这样的信号是正常的。但是一直都是红色就有问题了，比如图中的haddr信号。
• DUT的输入信号haddr是x，所有输入不正确，即driver的信号没有通过interface驱动到DUT的接口，因此需要检查driver是否正确动了interface，然后再检查interface是否正确跟DUT进行连接。

8.2、输入端口有Z（出现蓝色）

• DUT的hburst信号出现了z，点击信号前的“+”，可以看到[0] = 1’'h0，[1] 和 [2] 为 z，说明信号的驱动的位宽不正确，即DURT是3bit输入信号，驱动是1bit信号！
• 修改完代码，重新跑仿真时，需要先把整个环境清除干净！
  • make clean -f Makefile.qs; make all -f Makefile.qs

8.3、hrdata为什么是红色的x？

情形一：

• 原因是sram默认情况没有初始化，直接读sram的信号的话，就会读出x
• 因此正确的处理方法是：首先对sram进行初始化，然后再进行读操作

情形二：

• Hsize = 3’b000（8bit）；3’b001（16bit）；3’b010（32bit）
• 如果只读了8bit数据，其他24bit数据还是x态；同理如果只读了16bit数据，其他16bit数据还是x态

8.4、调试经验（实践中体会）

• 将DUT的所有输入和输出端口全部加载到波形窗口，检查DUT的所有输入接口是否有X，如果DUT的输入端口存在X，所有有错误！
  • X 可能是input信号floating导致的，就是input接口没有驱动
• 将DUT的所有内部信号加载到波形窗口，检查是否存在x，如果存在x，可以有问题

8.5、在波形图中双击左键的效果

• 左键双击波形信号，会把对应的代码（source code）弹出来（不推荐）
• 左键双击信号名，会把对应的属性（properites）弹出来

8.6、将source code 中的信号添加到波形中

• 左键选中某一个信号，然后组合键ctrl+w（实用 ）

8.7、查找信号的驱动