基于System Verilog仿真验证平台搭建

介绍

在FPGA验证或者IC验证领域，经常使用System Verilog语言搭建仿真验证平台。其中IC验证领域使用更多的为UVM验证方法学。对于中小型FPGA项目，使用System Verilog语言搭建仿真验证平台更为常见。

平台框架

这里介绍的基于System Verilog的仿真验证平台为作者基于个人自学以及一些项目经历的总结。常见的基于System Verilog语言的仿真验证平台框架如下图所示。

Tb_top
该模块用于将设计顶层模块和仿真平台顶层（Test_top）实例化，并使用接口连接设计的端口和仿真平台的接口。
Test_top
该文件为仿真平台顶层文件，在这实例化测试用例，并执行测试用例。该文件一般为一个program。
Testbase
Testbase和具体的用例Testcase可以理解为一个类，上述框架图中只画出了Testbase。Testbase的作用为将许多的接口驱动或者采集工作封装成task或者function，而Testcase是一个Testbase的扩展类，在Testcase中可以使用父类（Testbase）已经封装好的函数或者任务去驱动接口或者采集接口。此外，Testbase还将实例化Env，驱动或者采集接口的功能均在Env中实现。
Env
环境类作为一个容器类（这种称呼在“UVM实战”书籍中见过），将各个功能块集中实例化。
Agent：Generator、Driver、Monitor
Agent为某个功能模块的实现单元，一般Agent中Generator、Driver和Monitor三个部分构成，其中Generator的作为一般为将需要驱动的数据进行打包封装成一个transaction，并通过Mailbox方法将封装好的数据传递给Driver，Driver负责拿到数据之后，按照指定时序去驱动接口，从而实现激励注入设计DUT。Monitor的作用为监控采集设计输出端口数据，并将采集到的数据打包成transaction，并通过Mailbox传递给Scoredboard。
Reference model
参考模型的作用为模拟设计的行为，生成某个测试激励对应的预期结果。且由于参考模块的实现是使用system verilog高级语言实现的，因此生成预期结果的时间将早于实际结果（设计输出）的时间。
Scordboard
Scordboard的作用为接收来自Reference model预期结果，并且接收来自Monitor的实际结果，将两者进行比较并给出比较结果。
** 其他**
在仿真验证平台框架中，接口通过层层实例化最终连接到Driver和Monitor，在某个功能类中（例如Env）可在构造函数new定义时预留接口形参，这样在通过new函数实例化该功功能类时可将本地的接口连接上该功能块的接口，最终实现Driver和Monitor的接口和设计端口的连接。
此外，在某个项目的仿真平台中，一般需要配置参数，可将配置参数归为config类。

关于System Verilog仿真验证平台的其他理解

上述看过去很繁琐的平台框架，其核心功能为Driver和Monitor，验证的本质就是注入激励，查看实际结果是否满足期望结果。其实使用verilog语言去针对某个需求功能搭建仿真用例也可以，只使用一个.v文件就可以搞定，为什么要搞得像上面那么复杂？
原因有以下几点：
1.上面的平台框架把仿真平台层次化，可以提高的代码的可移植性，同一个代码能否在下一个项目中重复使用（或者稍作修改使用）也是决定这个代码优秀与否的因素。
2.使用上述框架的仿真平台，开发用例者只需要搞懂需求，以及使用Testbase中的哪些任务或者函数来实现激励的发送和输出的采集即可，无需知道顶层如何实现，可以让不熟悉该平台的人员快速开始做项目。

UVM

不管是做FPGA验证还是IC验证，甚至IC设计，UVM都是有个优秀工程师不能跨越的要去学习的内容（初入门的同学可以先看system verilog验证平台搭建–绿皮书，然后在学习UVM实战这本书籍）。知道UVM的读者应该清楚，上述的仿真平台框架和UVM树是一样的，UVM出于用户考虑，讲很多的功能实现都集成了，以此衍生出了UVM自己的很多机制，如factory机制。config_db机制等，以及TLM通信。EDA仿真工具安装包中都自带uvm库文件，读者可自行学习。后续有时间在一块探讨下uvm方法学。