从跨平台测试用例复用想到IP测试意图交付

记得在大概6、7年前的时候，我当时看到这家公司海量的emulation资源时那种惊掉下巴的样子现在都还记得。现在国内使用EMU也越来越多了，不过从测试用例的比重上看，EMU所占比例总体还是有较大空间提升的。这篇论文的格式更为自由一些，就跟聊天似的把他们在做跨平台复用的动机、架构、方法都介绍了，不过更为细节的东西并没有透露。但是从一个initiative的角度出发，这篇论文还是能够回答我在学习PSS（Portable Stimulus Standard）时的一个疑问，那就是在PSS execution层面的颗粒度应该做到多大才合适。我们接下来且顺着这篇论文的思路一起捋一遍。

像Intel这样的大公司，在产品线每年跟摩尔定律一样按照产品路线推出芯片的时候，他们在测试时的测试用例肯定不会跟初创公司似的，需要从零开始构建。大公司呆过的人都知道那里的流程封装得多么完善，那里蹲着多少资深的工程师，当然那里的测试用例也都是每个项目一个个地继承下来的。

谈到继承，就不得不接着探讨类似像这样产品线稳定，产品按版本、参数迭代的情况下，会对验证（文中称为validation，即分为pre-validation和post）的要求有哪些大格局的要求。

SoC和子系统（subsystems）也是IP的集合，在SoC或者子系统层面验证时，相比于IP验证时的功能深入，我们更关注于IP在系统中的角色、它与其它IP之间的互动。而如果SoC类芯片一代一代滚动起来，那么代与代之间的配置、参数差异，以及同一代产品的各个小版本之间的差异，都将会给测试的复用带来挑战。

此外，不同测试阶段使用的工具、环境也会带来挑战。比如你在FPGA上面做原型验证它是可以带着真实的外部板卡做测试的，但如果在EMU上面做，那么终端设备可能是真实板卡，也可以是虚拟板卡，还可以使用transactors去模拟IP和controller之间的数据交互。再比如，在制造环节筛选时，也由于post-silicon平台的制约，可能会采取不同的设备和其它组件用作测试。这种跨平台的差异，也给测试用例的复用带来了挑战。

这里其实没有谈到有关UVM的部分，有的时候UVM环境和用例往往意味着IP/子系统层面的测试，而到了SoC层面的测试，会更多关注于系统各个资源建模和调度场景。而且，为什么以前国内FPGA公司做产品会更早地在FPGA上线去跑应用呢？除了系统没有SoC复杂之外，FPGA研发团队距离客户近、FPGA产品更方便迭代也是一个重要原因。

在这篇论文里，没有专门谈到pre-silicon simulation的部分，这一点读者们可能会好奇，但有的时候当一家公司“财大气粗”的时候，他们真的是有财力可以把多数测试用例放在硬件仿真资源EMU上面去跑的。所以，这篇论文的语境其实是，当我们在开发一个SoC系统且已经到了SoC测试阶段的时候，我们为了测试更多的应用场景，如果在裸机（bare metal）上、最小OS kernel上、或者更大OS层面去运行的时候，如何去解决这些跨平台（wide diversity of platforms）、跨系统（various operating systems Windows/Linux etc）的挑战？

这里给的一个方案是提出IP validation software stack，即构建出弹性的结构以便让IP测试时的测试意图可以最终通过PSS生成测试代码，而这些测试代码可以利用这个IP validation software stack，根据所处的平台、芯片系统的版本不同都能够稳定运行，最终实现IP在集成层面的测试快速生成和运行。

这篇论文的逻辑，是从底部往上走的，即先提出这个IP测试的软件栈，解释需要利用它的data generator来存储和产生跨不同测试平台、不同芯片版本的配置参数，而后可以利用这些参数，再与runtime driver+business logic结合，以便让目标IP得到恰当的配置，最初匹配的行为。

为此，保存和产生系统相应参数的data generator如下

这些参数在获取以后，可以利用IP驱动（IPDMA）进行配置，而在IPDMA内可以“弹性”地根据IP功能来实现（即底层的OS/HAL+寄存器配置）。

“IPDMA”也并不需要指出该DMA的版本、通道、缓存等具体信息，它“暴露”给测试人员的，也无需指出IP版本或者具体寄存器等信息。而在“IPDMA”内可以利用“dp”来获得该IP的参数，再利用它们进行功能配置。在配置时，所使用的“mem_write”等函数，也脱离实际的操作系统，实现更为底层的操作，即这些底层函数可以“刚性”地跨平台（这一点不难做到）。

有了这样的一个IP测试的软件栈，便可以理解跨平台、芯片系统版本差异的问题，继而为各个IP和SoC系统测试意图能够在其之上进一步完成创造了条件。

事实上，这个简化后的IP测试软件栈也能解决一些读者目前的困境，尤其是公司开始批量出货，既想要继承以前的测试用例（但受限于系统差异无法做到直接复用），也想要节省人力（如果测试能够继承，那么节省人力也就自然可以达成）。

我在更早前已经完整地梳理过一次PSS基础语法，突出PSS的可移植特点也是体现在不同的测试平台和测试语言层面，无论它解决的是测试平台问题，还是测试层次问题，还是测试语言问题，PSS呈现出的都是从更高的视角去给每个IP进行建模，继而将这些IP模型构建成为一个更大的系统，再在这个系统模型中去创建一些各个IP和资源之间的调度关系。也就是说，PSS做的是测试意图（validation content）层面的工作，诸如PerSpec/inFact/Breker Trek做的是content2graph的工作即从意图到测试场景生成的工作，而生成的测试场景，无论采用的是什么语言，都需要我们给到一个恰当的颗粒度。这样才能把PSS在实际工作中运用好。

PSS学前准备篇（合辑）

PSS基础篇（合辑）

PSS测试篇（合辑）

而这篇论文解决的正是“颗粒度”的这个问题，通过论文作者他们已经验证过的IP validation software stack，不但他们给出了诸如“IPDMA”这样的颗粒度适合的接口，也可以在该接口内部“弹性”地解决跨平台、适配芯片系统版本差异的问题。

至于PSS的具体应用，他们没有在论文中谈到（也不是他们要在论文中介绍的流程）。他们也提到了目前在应用的是Cadence PerSpec工具和SLN（System Level Notation）语言，而且有计划将现有的模型过渡到PSS标准。随着2021 PSS 2.0版本的推出以及PerSpec已经对PSS的支持来看，他们推进模型转换的工作是迟早的。这也让我想起了当时从OVM/VMM过渡到UVM的一段时间。

论文中同样有价值的是作者在不同的项目之间，通过复用IP测试意图，继而由PerSpec生成可以跨平台的测试用例以后，不但节省了很多的人力，也同样提高了工作效率。下面是采取复用测试意图生成测试用例所发现的bug数量，以及这些bug数量在每个项目中所占到的比重。无论是数量还是占比，这种复用方法，如果想要拨开跨平台、系统差异、测试语言这些纷乱的因素，那么测试意图的复用将会让不同平台的测试人员之间达成一致（大家不再因为技术因素而难以达成某种程度的联合）。而且如果这种复用从一开始的架构就能够规划好，那么也将会在芯片代与代之间、产品与产品之间放大它的效力。

继而在增效的前提下，为接下来制造环节和人力环节的成本节省，也就理所应当了。从数字来看还是相当可观的，也许一些读者目前还暂时没有遇到这种处境（哎这也是产品线又长又广的毛病，可谓是大厂们有些凡尔赛的苦恼），但如果想增效，就应该把测试层面去拔高，不管是simulation/emulation/fpga，还是pre-silicon/post-silicon，都应该站在更大的一个格局去考虑这些事情，从大厂出来的人看待这些问题更有视野，也更愿意在早期投入一部分精力去筹划这些事情。

做久了工程，我常常觉得，你的团队未来的工作模式就来自于各条技术线的总监在一开始的架构规划。

接下来再来谈谈我们篇文章的题目“从跨平台测试用例复用想到IP测试意图交付”里的“IP测试意图交付”。以前IP交付时不管是内部IP还是第三方IP，并不会给我们交付RTL和功能文档的同时交付功能测试点（因为这是人家内部的文档，也牵扯到IP的完整开发，更可能被反向做IP开发）。我们这个时候要集成IP做测试的时候，有两部分可以借鉴。一部分是IP配置生成后的测试代码（Verilog/UVM居多），一部分是IP文档中有时会出现的programming case/scenario的例子。但更多是将IP作为一个独立组件，就实现其某些功能，做的配置描述。有的时候，IP还会提供一些驱动（这已经很友好了），但至于拿到这些IP如何在系统环境中与其它IP/资源进行交互，其实IP提供商是没有这个义务的（他们不会包含在产品中，但你如果邀请他们提供service花这笔钱也是可以有的）。

在这种情况下，如果以后PSS普及、且PSS测试意图到测试代码的实现也更为规范的话，那么IP提供商是可以在交付IP的时候，同时交付这个IP的PSS模型的，以便我们以后既可以集成在上层系统模型中，也可以利用它的action在系统层面构建一些activity。只不过在文中也谈到，这样的要求有些不合理（unreasonable requirement）。

为什么需要IP的PSS模型，以及针对它们构建的集成测试PSS场景呢？因为如果有了这样高层次的描述，我们在拿到一个IP以后做集成测试的时候，也就有了指向性更为明确的方向。不然就容易造成目前国内很多SoC公司在集成IP时有些尴尬的情况，花了几十个million买的各类IP，在集成测试的时候都有点盲人赶路，战战兢兢的（这个事实往往在初创公司都心照不宣了吧）。

要解决这个问题，就需要考虑实现“IP测试意图交付”。目前大厂里不同平台的人员针对IP集成测试，或者是看测试计划、测试点，或者是看各个参考用例，可这是建立在验证人员有经验的情况下的。一旦脱离了这个条件，要在大的方向上完成“及格测试”，都会有些困难。于是乎，我们目前提出了在UVM/C层面的IP测试复用建议，该建议要求针对每个IP在SoC层面测试时，利用一致化的测试指令（例如V3课程提供的Liezhen平台），构建每一个测试用例，而这些测试用例在项目发生变化时，可以较为方便地移植到（毕竟标准化测试平台的底层指令是一样的，无论是simulation还是emulation，无论是UVM还是C）。

这种方案可以在客户那里将前期项目中的测试更早地标准化下来，也便于在接下来的项目中复用，更实际地说，也较为符合我们国内公司目前普遍发展的阶段。

只不过，我们如果要更为长远地看，想要实现更多跨平台的复用，就不能只在测试用例复用、测试指令标准化、测试平台自动化上面下功夫，下一个要考虑的还是PSS、IP建模和测试意图复用。这一阶段我们总归是要走到的，目前国内已经有小比例的公司在试行PSS和相应工具了。也希望这篇论文的解读，能够在接下来芯片一代代产品测试复用时带来启发，也希望读者们（如果）在的初创公司能走到芯片量产，拥有这种一代一代芯片测试的幸福烦恼。

审核编辑 ：李倩