如果我们按照验证的生命历程来看的话，最早先时候人家并没有将验证的重要性提到今天如此高的程度，甚至30年前人们大概还没有验证的完整概念，或者更多地停留在简单的测试上面。如果我们将镜头再拉近十年，那个时候伴随着仿真器的性能革新，hdl语言几乎统治了数字IC设计的市场，而我们所学到的“behavior. code”则是用来对设计进行测试的，而且受限制与HDL的特性，那个时候的测试是清一色的直接测试。直到许多年以后的今天，我们高校的教育还大多停留在重设计、无验证的阶段，学生们会写fifo和FSM，而且用HDL写一点简单的直接测试用例。从学生的实践感受来看，他们也还认为，那些对硬件理解更深的人可以做设计，而其余的人则可以做验证。然而，外面的世界是这样的吗？路桑在大学授课时，只能讲Systemverilog的语法和应用，而不能再深入下去讲一点UVM的知识，因为就SV而言，它对验证世界的扩展和应用已经够同学们认真学习完一个学期了。这么看来UVM对在校学生而言，并不是那么友好，甚至对于公司中的UVM初学者，也是如此。

然而，掌握了UVM，就得到了“天下”吗？我们应该首先祝贺你的是，你获得了码砖的资格证书，从此你将可以自己进入验证这个领域，然而未知的东西、verifier们需要学习的还有很多。而对于未来验证技术趋势上的主流预测则是，一个名为“portable stimulus”（便携激励）的测试标准将在接下来的五年内会逐渐普及。在本章后面的术语使用中，我们将用“PSS”来作为portable stimulus standard的简称。

那么为什么PSS将会成为下一个验证效率的增长点？这得要从目前验证面临的问题说起。从仿真验证的项目周期开始说起的话，UVM在模块级验证的优势是最明显的，一方面它的随机验证更易发现验证薄弱点，另外一方面功能覆盖率可以量化验证过程。然而到了子系统级别和芯片系统级别，UVM的长处收到了越来越多的限制，同时更多的测试场景逐渐交由了C代码去完成，验证的重点也渐渐地从覆盖尽可能多的场景，转而到了去按照优先级覆盖可能会使用到的场景。所以，芯片系统级的验证上，随机变得不再那么重要，而模块集成、性能和效能的验证成为了重点。这种现状，使得从模块级的UVM测试场景代码到系统级的C测试代码的复用既受到了语言边界的影响也收到了不同驱动层次的测试代码复用影响。譬如，UVM的代码要转为C的代码，不单单是语言转化的问题，而且也要考虑，UVM中的virtual sequence控制总线发送数据的驱动层（寄存器层？协议层？还是物理层？）是否可以更方便地跨接到C一侧的驱动层。所以，这是关于从模块级到芯片系统级复用过程中面临的垂直复用问题。

然而，仿真技术在越来越复杂的系统集成中，受到了各方面的挑战。比如在完备性测试中，无论从完整性还是效率上看，它都比形式验证要逊色；而在大型或者超大型SoC系统仿真中，它又因为受限于仿真时对server过重的负载，而不得不将大型仿真和长耗时仿真的需求，转移到emulator和FPGA上；再到更早期的芯片架构评估上，所需要使用到的virtual prototype和virtualizer的仿真技术，这也是simulator无法提供的。所以从验证的技术趋势来看，目前的几种主流技术都有其专长的领域，而且都在快速发展。那么对于一个大型的SoC验证，在RTL设计阶段，会同时进行simulation、emulation和FPGA prototype，那么除了在验证平台的构建上要考虑的跨平台复用（即一个验证平台同时能够在simulator和emulator，或者simulator和FPGA之间跨接），也需要考虑不同平台上的测试用例是否可以复用？例如，emulator或者FPGA上测试时出现了异常错误，而受制于这两种平台较为有限的调试手段，它们可以将该用例在simulator平台上仿真调试，利用更好的调试手段可以更快定位出硬件的问题所在。那么，理想地看，如果在不同的验证平台上可以实现跨平台复用的问题，进一步延伸，就可以考虑，在芯片后期的驱动层和软件层开发中，也应该考虑引入RTL验证时的用例，或者在这不同的开发阶段之间，应该有统一的测试标准，从而实现更广义的测试复用。

也正因为如此，对于同样的测试场景，存在着重复开发测试用例、不同平台和不同层次的测试代码无法复用的问题。所以在验证领域过去的十年中逐步统一了验证方法学实现了验证完备性之后，接下来的十年需要提高的是验证效率。验证效率的提高是一个大的命题，而且从已有的技术来看，我们仍然需要依赖于多种验证技术和工具来完成功能验证，所以如何实现不同技术、不同层次上验证产出的最大化将是一个重要的考量。PSS的提出就是为了缩短产品的测试时间，通过产品的功能描述来指定一个标准格式的翻译（包括设计和测试两部分），进而使得验证用例和验证计划变得在垂直复用和跨平台复用上实现连续性。

那么是否现有的语言标准可以提供“统一的测试描述”呢？不是没有想过。例如现有的UVM，虽然它对于验证工程师而言是统一的验证方法学，但是对于其它平台和其它开发周期链条上的工程师，他们并不熟悉SV&UVM，而且UVM的学习成本也高。同时受限制与SV语言本身，UVM无法在系统级验证提供更好的支持。那么SystemC或者C++呢？它们也有各自的语言优势，然而依然无法在更高的系统层面来描述一个测试场景。那么一个单独的PSS的语言标准应该具备哪些特性呢？

• 这个语言应该提供统一的库接口，该接口需要被不同的EDA公司的VIP所支持。这么做是为了加速SoC集成和测试。

• 一旦在不同EDA公司的各个平台和VIP上实现了统一的接口，那么无论对于EDA公司还是verifier，它们将会拥有更上层的统一接口，继而在这个接口上面做开发。关于这个特性，是否让你想起了UVM的发展路径呢？EDA公司们当年也是各自圈地，而后发现这么做不但没有形成各自的优势，反而给客户们造成了困扰。因此，验证方法学还不是EDA公司建立技术壁垒的距离，而到了测试场景描述的需求上面，这一次EDA公司们就容易合作，共同推出一个EDA公司和工业都认可的标准。继而，我们期望的是下一个十年在此基础上做合作和竞争，这对于整个行业是有益的。

• 如果实现了不同EDA、不同平台、不同验证层次的测试机动性，则可以预见的是，无论是在产品哪个开发周期、哪个平台和层次的开发测试人员，都将采用一致的场景描述语言输入，这对于产品开发过程中的沟通和产出都是有帮助的。

• PSS并没有采用现有的语言而是另外设计出了一个描述方式。这留给了EDA厂商足够的空间去联合它们现有平台和VIP资源，而这一点很重要，因为要实现统一的测试描述，从高层的描述到底层的验证方式，中间存在的平台和VIP资源是各个EDA公司有各自的架构和特点。PSS只用来规定描述场景的语言和方法，而并没有规定EDA厂商如何实现从高抽象级到低一级测试的映射方式。

• PSS语言采取了一种自然的（易读易学的）和准确的方式来帮助用户定义便携测试的场景。这种易学易读的特性也在无形中扩大了它的潜在用户群体，譬如对于系统工程师和硬件设计人员，他们在面对一个用PSS描述的场景时，几乎不同学习就能了解该测试的大致意思。

讲到这里，我们不妨再联系之前的《验证平台自动化篇》中介绍的Pangu TB自动化工具和其生成的uTB特性：

• 可以快速集成各个现有的VIP资源，无论它来在于哪一家EDA公司还是自开发的VIP。

• 可以用统一的、易读的、易学的测试指令来描述测试场景，从而实现垂直复用和良好的维护性。

• 由于结构化的特点，可以统一收集功能覆盖率，并且利用覆盖率实现更智能的激励创建和覆盖率收敛。
  

从这些核心特性可以看出，Pangu和uTB在开发伊始，也是充分考虑到了以后的资源和准备要实现的测试复用场景，那就是想在各个VIP的资源上面实现更快速的验证环境搭建，以及用统一的测试描述命令来提供一种便携激励定义的可能。而在Pangu实际的使用经验中，我们已经得知它在垂直复用和测试描述一致性上面取得了成功。所以，Pangu在开发时，已经将PSS的理念融入其中，而它未能实现跨平台复用也是与路桑所在项目的各个平台的复杂历史原因有关。

而再回到PSS本身，从目前的成功推出PSS产品的EDA公司来看，它们在2015年就达成一致与业界公司验证专家组成了Accellera PSWG（Portable Stimulus Working Group）。该工作小组的创立目标就是综合业绩需求和EDA公司已开发的PSS工具手段之上，推出大家一致认可的PSS标准。我们在下一节中将介绍目前已经推出的几家EDA公司的工具。也许读者们还并没有认识到这些工具将要刮起的蝴蝶效应，而路桑相信伴随着这些公司的PSS工具和EDA公司已有的资源日益整合，未来这些PSS工具在高效验证场景的出场概率会越来越大。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。