rockeric.com
昨晚在等班机的途中，又翻了几篇DVCon2018 US的论文，它们更多的在偏重于不同场景、不同领域的方法学应用，而真正能够创新且有使用价值的论文还是珍贵。看多了这些阳春白雪的东西，一方面在感叹为什么国内验证思想和应用与国外依然有如此之差距以外，一方面也在考虑除了DVCon、DAC、SNUG等展会论文以后还有哪些途径的论文可以对我们国内读者的工作能够起到及时雨的帮助。
我在做2019研究课题背景之前，也跟不少从事FPGA测试的朋友聊天，话里话外他们都挺想学习UVM验证，可依然无从下手。原因有二，一是目前项目环境就是纯FPGA的测试环境，没有仿真器在其上；二是他们也缺乏一些仿真器使用的知识，也不会SV/UVM的基础。
与此同时，我还跟不少国内的研究所、国企、中小企业在聊他们面临的芯片验证问题（这些群体实际上代表了行业真正的总体水平），他们目前也在想有没有进一步地规范芯片验证，如何将RTL验证引入到FPGA测试流程中来。即，如何在现有团队的知识结构、人员配备上可以分步地将SV/UVM验证方法学引入进来。如果引入的节奏合适，那么也就自然而然可以进一步规范验证流程，从更多的方面来量化验证。
我大概能想到几种方法，可供大家考虑，也会就这几种方式，给大家做一些分析。
彼此独立的Simulator和FPGA验证环境
这即是单独引入RTL仿真流程，且针对已有的设计构建可运行于仿真器中的SV/UVM验证环境。这是属于增量改造，这里的增量包括工具、技术手段、流程等。
这种方式的优点在于，工程师可以不依赖于FPGA资源，而直接学习SV/UVM和RTL验证理论，可以招聘验证工程师从零开始构建环境。
这种方式的缺点在于，学习曲线较长，而且需要招聘验证工程师来帮助构建环境，或者需要在紧张的人力资源中抽出一小部分人来做“先锋队员”，攻坚克难。同时，在构建好RTL验证环境之后，RTL验证和FPGA验证的人力也无法做到很好的复用，因为验证平台、验证用例和覆盖率均无法复用。
可综合的验证环境
这个话题实际上是比较古老的，因为在很多年以前，SV/UVM还没有统一验证世界的时候，各个公司都是各显神通，创意无穷的，有点像春秋战国呢。这其中有一个流派就是可综合验证环境的方法学，什么意思呢？就是无论是设计部分还是验证部分，都全部是可综合的代码。也因此，DUT和TB无论在仿真器还是FPGA，均是不需做什么移植工作的。不过这种方式下，功能覆盖率还无法实现（因为其不可综合），但是测试平台和测试用例均是可以跨平台复用的。
这种方式的优点在于，工程师几乎不需要学习太多SV/UVM的技术，便可以利用设计经验来构建一些验证环境的组件，再在顶层对其进行连接。
这种方式的缺点在于，该种测试平台更注重上层软件的测试，即FPGA验证平台的使用，也因此无法在RTL验证环境中实现功能覆盖率、断言、随机等功能。
Simulator与FPGA软硬件联合仿真
该技术基于标准的UVM架构，实现了一种软硬件联合仿真验证平台。这种联合仿真可以将仿真器、FPGA以及它们之间通信连接的驱动总线协调起来，进行联合仿真。这里，我们给出一篇论文 陈锐2017《基于UVM和FPGA软硬件联合仿真验证技术研究》，有兴趣的同学可以在文末点击“阅读原文”，下载该篇论文。
从论文中的示意图来看，simulator和FPGA可以通过PCI总线进行通信，这样simulator可以同FPGA目标测试硬件平台同时运行。
simulator中可以运行UVM环境，由driver产生transaction（抽象命令层），该命令将会借由PLI/VPI接口来连接PCI驱动。同时PCI驱动会同FPGA之间建立通信，将抽象命令层间接通过PLI/VPI和PCI驱动传至FPGA，并转为验证驱动指令，继由FPGA中各个激励组件来驱动时序。
值得注意的是，在这种情况下，UVM一侧的driver所发出的驱动不再应该是将其驱动到interface上，而是需要借由指令的发送代理端PCI驱动送至FPGA一侧。
这种方式实际上与目前的emulation剥离验证时序的思路是相同的。所以，UVM环境中的driver只需要从sequence中接收transaction，并且通过PLI/VPI接口、PCI驱动发送至FPGA中。而对于PCI数据包中的命令解析、以及涉及时序的激励驱动，则交由FPGA中的AMBA等总线IP实现。
这种软硬件联合验证平台的方式，一个优势在于可基于原有FPGA测试平台来扩展，即将原有由FPGA系统软件定向激励驱动的方式，交由simulator来完成。这里需要注意，simulator产生的激励是抽象指令级别的，而非时序级别的。抽象指令待通过PCI总线，到达FPGA内部之后才会被解析，继而分配路由给对应的各个AMBA IP。
这种方式的另外的一个优势即是很顺滑地引入了UVM验证方式。可能有一些读者对这种方式似曾相识，这跟Emulation的解决方案看起来有点类似啊。没错，至少双顶层的TB拓扑结构是类似的，不过emulation与FPGA相比还有其它丰富的外设以及调试资源，而且emulator对于语言支持的子集（例如Mentor Veloce TBX）也做了相应的扩充。
从上面给出的该方案的软硬件联合验证系统结构图来看，相当一部分都是FPGA的系统开发软件自带的，而要做该方案的开发，主要花的力气在于从simulator到FPGA一侧，从抽象指令层到验证指令层的转换，以及对应的验证指令在FPGA一侧时序的执行。
不过该篇没有做更多的数据比对，因为我们关心的还包括，在较高层面的软硬件联合仿真在获得UVM的优势的时候，由于联合仿真所带来的速率下降大概是什么样的情况。同时，我们还应当注意，如果要使能simulator一侧的覆盖率，那么如何能够将DUT（FPGA一侧）的信号变化也能够通过PCI通信驱动转至simulator一侧。类似地，有没有更多的可能可以让simulator一侧观察到更多的FPGA内部信号，来增强simulator一侧的调试可视化呢？这些问题都非常意思。
总结
这三种模式都有各自的应用方向，从FPGA团队的适应性来看，采取第三种方案即软硬件联合仿真的方案从TB复用、测试复用和覆盖率复用都具备优势。从TB复用性来看，我们还应当考虑软硬件联合仿真的模式如果能够兼容纯粹的simulation，即将DUT也置于FPGA当中。
这种测试模式兼容的方案在将来也会非常受欢迎，因为FPGA测试的人马还是那么多，只不过是将验证平台扩展到了simulation的范围，也引入了SV/UVM随机测试和覆盖率量化的长处。一个灵活的测试平台，在测试初期可以只在simulator中测试，这样方便覆盖率收集和调试，而到了设计后期稳定的时候，可以将DUT置入到FPGA当中获得更大的仿真加速，而测试平台依然保持很好的可扩展性。
在这个基础上，我们还应当考虑，面向系统测试时，如何让测试用例也能够得到很好的复用。毫无疑问，C/C++/Python等高级语言也将需要被这个平台所支持。而这个话题，我们将在下一次关于FPGA如何验证算法模型的话题来谈论它。
2019年路科验证实战就业VIP春季班
早鸟报名通道开启
扫码即可报名
前30名报名的同学给予早鸟价格
优惠500元！
往期精彩：