近年来，随着社会快节奏的发展，各个Soc厂商的Soc设计更新迭代速度越来越快，为了能够更快速的切入一个新项目的验证工作，一个简单易用的验证环境对于每个IC公司都显得至关重要，那么怎么去实现这样的一个验证环境的搭建呢？下面我们来谈谈我们的实现过程:

背景

我们要实现一个符合DO-254标准并且适用于PCIe和Avalon Streaming（Altera公司的流接口）接口的UVM VIP，其中主要难点在于怎么利用我们的UVM VIP验证DUT以及DUT的PCIe接口，怎么实现验证过程中产生的文件都符合DO-254规范标准。

第一步:构建项目管理环境

由于本次验证项目需要遵循DO-254标准，除了考虑如何构建UVM验证环境之外，我们还必须考虑如何在满足DO-254标准的前提下有效地实现对项目各个方面的管理，下面是几个主要方面:

• 验证需求管理: 对于需求管理我们应用了比较传统的管理方法，Word和Excel,我们的项目需求和验证计划用Word进行描述，对于验证计划更新迭代信息我们记录在Excel表格中，这样的需求管理方式虽然可以实现我们的要求，但还是比较难以操作，因为我们的对于需求文件的改变记录在Word中，每次改变之后，对于改变的内容，改变的人等等这些信息都是被手动的记录的，而且添加新的需求后，Word并不能自动对这些新的需求进行排序更新，这使得对于需求改变的相关日志文件都需要我们以及手动去完成，一是浪费时间，二是容易出错，所以选择一个专业的需求管理工具将是一个很好的选择，这一点我们将在下一个项目中进行改进，例如选择像ReqTracer这样的专业需求管理工具。

• 版本控制:对于版本控制，我们选择了SVN,它是免费的，而且被很好的集成在项目管理工具Trac中。

• 配置管理:在一个符合DO-254标准的项目中配置管理是一个很重要的方面，我们采用的配置管理工具也是基于SVN的，这样我们就可以在我们的配置文件上产生一些SVN的标签，然后在我们仿真测试用例的时候根据这些标签去选择在我们的验证环境顶层用什么样的配置文件，这可以使得我们的验证环境会变为可配置的，而且对于每一个配置文件的发布，SVN都会自动记录这些配置文件的更改情况并写进日志文件中，这样每次我们对配置文件进行更新后就不用再去关注更新内容，更新的文件这些信息了，因为SVN会帮我们自动生成好。

• 项目管理:我们需要一个项目管理工具，尤其是在要求符合DO-254标准的项目中，我们采用了Trac工具作为项目管理工具，版本控制工具是SVN,Trac是一个非常好的项目管理工具，它对Subversion,Git以及SVN等其他版本管理工具都提供了很好的接口，而且它允许我们把bug的记录信息，任务的记录信息，文件的改变信息等等无缝的链接到wiki的页面上，清楚的记录下项目的每一个节点，使得我们对整个项目进度的把控更容易。

第二步:明确验证需求

当我们的项目开始进行一段时间后，我们就会有我们的第一版的验证需求，这样我们就会开始针对验证需求搭建我们的UVM验证环境，然而，验证需求并不是一成不变的，随着项目的进行可能会进行许多次的更改，我们也就需要跟着手动去更改我们的验证计划和需求迭代的表格，这时这些用Word和Excel记录信息的更改就会给我们带来很多问题，例如我们可能改错，可能落下哪一个点，等等。

第三步:搭建UVM验证环境

在开始搭建UVM验证环境之前，我们需要准备一个顶层的验证环境的框图，基于这个框图和我们的验证团队讨论怎么去实现验证环境的搭建，对于整个环境的搭建创建一个搭建计划，实现难度做一个初步的估计，把整个验证环境分成一个一个的节点并记录在Trac系统中，让大家跟着这些节点去进行，每个人的任务也都会被记录在这些节点中，你做了那些改变，提交了哪些任务我们都可以在这个节点中看见，这样可以让我们的工作进行的更有条理，更顺利。

对于具体环境的搭建，我们需要在一开始先实现我们一些公共的基础的类和组件如:monitor,sequencer,sequence item等等，这些类的实现在我们项目中大概需要两个人做一个月。完成后另一个工程师尝试着去集成Mentor公司的PCIe VIP在DUT中，并且跑一些仿真测试用例，Mentor提供了一个怎么把PCIe VIP集成到Altera的PCIe硬核IP中去的一个例子，而且Mentor公司提供了关于PCIe VIP的详细文档信息，这让我们的集成工作变得很容易。

第四步:添加测试激励和结果分析报告

我们有大概200+的测试仿真用例需要去实现，而且所有的测试用例都是基于随机测试，他们被一一对应的链接到需求条目上，对于每一个测试用例，我们都针对DUT定义了断言，覆盖点等，用Questa作为仿真器，然后把断言，覆盖率的信息以XML的格式收集起来放到test_plan.ucdb中，ucdb文件允许我们把每一条覆盖率的信息对应到我们的testcase上面去，这样，在跑完我们所有的测试用例后，我们可以看到我们所有的覆盖率信息，包括单个和所有的测试用例覆盖率信息，这样便于我们去分析哪些语句被覆盖到了，哪些没有，让我们的验证工程师更容易的去做覆盖率的分析。

对于测试用例的仿真，我们利用C-shell语言写了一个脚本，它可以去仿真一个单个的测试用例，也可以读入所有的测试用例名字再去仿真，还可以传入一些其他的仿真参数，例如GUI参数，要不要dump波形，要不要打开coverage等等，这极大的方便了我们进行测试用例的仿真，但它还有两个比较大的缺点:一是不可以并行的仿真测试用例;二是不可以对一个测试用例设置仿真次数。

基于上面的这些需求，我们引进了Mentor公司的VRM（Verification Run Manager）,这样我们跑测试用例的方式更容易了，我们可以对不同测试用例设置不同的仿真次数，不同的仿真参数,而且VRM可以和Questa一起协同工作，这样我们可以基于仿真的结果，对failed的测试用例以GUI形式仿真进行debug,而且有了VRM我们对于仿真结果的分析也变得更加容易，VRM可以收集UVM的错误警告信息，并把它们放到我们的log文件中用于项目报告，也更方便我们进行debug。

总结

实现一个UVM的验证环境，尤其是VIP，是一件比较困难的事情，需要大量的时间和经验，然而，一个好的验证环境将会给我们的验证带来巨大的改善，因为它可以在以后的项目中被一次次的复用，而且它会帮我们做许多验证流程中的事情，让我们的工程师把更多的时间放在验证收敛的核心问题上，也极大程度的降低了新员工的学习成本，让他们以更快的速度进入到验证流程中去。

您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证，并注明出处“路科验证”。