ASIC芯片设计之UVM验证

随着ASIC芯片的规模越来越大，验证在整个芯片研制过程的地位越来越重要。在目前的集成电路项目开发中，验证占据了2/3的时间，已经成为开销最大，不可或缺的重要一环。验证工程师也成为供不应求，各大公司开高薪追逐的香馍馍。曾经，会写verilog，能输出激励信号灌入DUT（待测设计）进行仿真，就能胜任验证工程师工作。这在芯片达到百万门级，动不动就是一个SOC芯片的今天，已是too young too simple。 那么对于立（hun）志（kou）成（fan）为（chi）验证工程师的童鞋们，需要掌握什么样的基本功呢？先看一看各大招聘网站对验证工程师的招聘要求：

关键词：

UVM（当然OVM，VMM也是可以的）

systemverilog（高级编程语言是基础，嗯）

协议（做一两个项目就get了）

如今不懂点验证方法学，真不好意思和人说是做验证的。在各种验证方法学中，UVM是目前最新，最普及的一种。

百度百科对UVM的释义如下：通用验证方法学（Universal Verification Methodology, UVM）是一个以SystemVerilog类库为主体的验证平台开发框架，验证工程师可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境。

还是get关键词，一是可重用组件和标准化层次结构，二是systemverilog类库。

我们先从第一点入手，什么是可重用组件和标准化层次结构呢？铛铛铛，祭出UVM bench结构。

自上而下，首先是testbench，中间是interface，用来连接testbench和dut（design under test，待测设计），最底下是dut，也就是被测试的部分。

而在testbench中，由外而内，最外层是test，这是验证平台运行的起点，严格意义来说，testcase不属于testbench，一个成熟验证平台为了测试dut各种的功能点，会产生很多的testcase。

environment（图中缩写为env）是验证平台的最顶层模块，env被例化在testcase中，当我们运行一个testcase时，在build phase中会动态构建env这个组件，env中包含了agent和scoreboard等组件，并且完成agent和scoreboard之间通信信道的连接。

agent（图中缩写为agt）是代理模块，其作用类似一个sub env，里面包含了sequencer，driver和monitor这些组件。在完成构建这些组件之后，会连接sequencer和driver之间通信信道，monitor的通信端口连接到agent的通信端口上，以便通过agent和scoreboard等组件进行连接。

sequencer（图中缩写为sqr）是产生激励的组件，准确地来说，激励是从依附于sequencer的sequence中产生的。对于一个sequencer而言，可以有多个sequence，不同sequence产生不同的激励，如长度固定的数据包，长度随机的数据包，读命令的数据包，写命令的数据包，带校验的数据包，故意出错的数据包……配合testcase，不同testcase可以选取不同的sequence，运行在sequencer这个组件中，产生符合测试者意图的激励，并通过sequencer和driver之间的信道传输给driver。

driver（图中缩写为drv）是将sequencer产生的激励转化为驱动信号由interface驱动到dut中的组件。sequencer和driver之间的关系就像是将军和士兵的关系，sequencer是发号施令的将军，driver则是具体执行的士兵，两者紧密配合，才能驱动dut工作。

monitor（图中缩写为mon）是采集dut信号的组件，信号被采集回来进行监测和比对。所以monitor采集到的信号会封装为transaction，由通信信道传输到其他组件，比如被送到scoreboard中进行比较。

sequencer，driver，monitor是agent中典型组成部分，此外agent中还可以包含config，用来存储和控制agent的配置信息。agent还可以有active agent和passive agent之分，前者通常是master agent，包含向dut输送激励，和从dut采集输出两部分内容，即包括了sequencer，driver和monitor三个组件。passive agent则是slave agent，不驱动dut，只用来收集dut的输出，也就是只有monitor，不包含sequencer和driver。根据不同项目可以选择选用active或者passive agent。而作为验证工程师，更常用的做法是开发一个agent，包括了sequencer，driver和monitor这几个部分，然后设置一个变量，决定当前是active还是passive，如果是前者会例化sequencer，driver和monitor，如果后者则仅仅例化monitor。

scoreboard（图中缩写为scb）是记分板组件，用来收集dut输出和期望值进行比对。dut的输出通常由monitor采用，而期望值则需要根据实际情况，比对内容的不一样有不同处理方式，有些可以直接从monitor采集dut的输入，有些从driver中拿原始的激励。dut比较复杂的情况下，需要引入reference model对原始的激励进行转化，从而和dut的输出进行比对。reference model可以是system verilog语言，c语言，或者其他语言编写。scoreboard实现了自动比对，不仅解决了工程师手工比对的繁杂和易出错的问题，而且是大规模回归测试的前提条件。

刚刚阐述了uvm中各个组件的功能和作用，接下来说明uvm验证平台的层次划分。

最上层是测试（test）层，由各种testcase组成，接下来是场景（scenario）层，由产生激励的sequencer构成，第三层是功能层，包括scoreboard等组件，第四层是命令（command）层，由driver和monitor这种和interface打交道的组件构成，最底下是信号（signal）层，这一层是通过interface和dut进行交互。这几个层次各司其职，相互配合，实现了一个面向高层建模的可重用验证平台。

UVM的第二个关键词是systemverilog类库，这些类库一方面包括了各种组件的基础代码，如uvm_driver，uvm_scoreboard，验证工程师通过扩展这些源代码，就可以为各种项目开发组件，搭建验证平台，另一方面这些类库包含了各种内建的函数，例如copy，compare，这些通用函数帮助我们减少工作量，节省开发时间。

这样的uvm验证平台看起来并不复杂，那么，对于如今soc芯片动辄数十个外设模块的验证来说，它可以胜任么？

其实，这就是uvm这套验证方法学中可重用组件和层次化验证平台的优势。以一个agent为例，可重用组件的意思是同个agent可以运用在不同规模的验证平台上，也可以在不同项目中随意搬。

以uart为例，在ip级验证中，验证平台可以长成这样：

在soc级验证中，除了uart，还有cpu，memory，以及一大堆的外设，比如i2c，spi，uart，sdmmc，usb……在uvm框架下，一套接口做成一个agent，所以我们只要把ip级验证时开发的uart agent移过来，interface重新连接下，就能重用了。瞧，这样的soc bench结构是不是很眼熟？