PSS学前准备篇之一：PSS究竟意味着什么？

相比于验证环境从模块级到系统级的整合、复用，从投入产出比和EDA行业可作为的领域来看，对测试用例的整合更容易在标准层面推行。其实，从EDA用户而言，还有一个整合的角度，即覆盖率的标准整合，即将不同工具（仿真验证、形式验证、FPGA/Emulation验证）和不同EDA厂商的覆盖率格式整合一致，类似于独立的FSDB数据格式。这种整合的思路，很大程度上可以给用户提供更灵活的工具包选择，并且为量化验证提供一个统一数据格式，继而将不同EDA公司在覆盖率驱动验证工具层面（类似Mentor Questa Verification Run Manager, Synopsys VC Execution Manager，Cadence Xcelium vManager）也能够集成其它厂商的工具、命令行和数据合并等流程。

在这里，我们先切回到主题，即测试用例为什么需要整合？从哪些层面可以做到测试用例整合呢？

从下图可以看到，在复杂系统当中，我们在验证模块、子系统和系统时，都需要实现测试用例。现有的测试用例在形式上，主要分为IP级的SV、子系统的SV和C、以及系统级更常用的C测试。在不同级别的测试用例之间，常常不能做到测试用例的复用，无论是测试用例的语言、还是同一测试语言在不同级别的内容，都较难做到垂直复用。例如DDR在IP级的测试如何从SV语言和测试内容、切换到在高速子系统的C/SV测试内容、再到系统层面的C测试内容，如果缺乏一开始的统筹安排，例如在C和SV层面统一好较为一致的常用底层硬件驱动、单元场景操作接口等内容，那么按照从模块到系统的流水验证流程，极容易使得在不同层面的测试用例无法复用。当然，导致无法复用的还有一个问题，那就是模块级、系统级和硅后测试的场景在一开始并未统一下来或者考虑清楚，这使得在各个验证层次的验证场景无法做到一个完整的闭合，而不同抽象层次之间也缺少一致的测试接口使得它们之间能够过渡和复用。

测试用例在垂直复用层面，目前的项目实践中多数新的项目难以做到，这与一开始的规划有关、例如硬件和软件的划分、软件或硅后测试的接口在一开始没有参与到硬件验证流程当中，而在流片后，软件又无法很方便地使用硅前系统验证接口等，都有联系。为什么会出现这样的问题？还是由于软件在前期缺少一个早期的平台能够介入到硬件功能验证流程中有关。

如果我们再将视线抬升到其它试图解决软硬件协同验证的流程和方法，那么我们还会发现虚拟原型建模（virtual prototyping）也是朝着这一目标努力的。只不过，相比于SV的推广程度，在过去的多年中SystemC在IC领域的推广（尤其在国内推广的经验）来看，越是要在一个更高的层面、从系统模型到测试接口再到工作流程，试图开拓一个完整的、新的、甚至引入更具有开拓性经验的（SystemC在HLS高层次综合的经验）雄心，往往需要很多方面的配合，尤其是在流片成本日益攀高、担心试错的芯片行业。从SystemC的推广、应用来看，它的出发点也是为了能够更早地让软件开发、模型评估引入到项目前期，而从目前的实际推广来看，它在模型评估的应用和推广更容易做下来，而在软件早期开发过程中，尤其是为了一个更加精准的模型，让硬件设计团队与软件团队在硬件设计早期有更多的代码细节（包括逻辑和时序）的交流，就殊为不易了。这也导致了，利用虚拟建模来引入软件开发，目前还停留在一些成熟系统（以ARM架构为依托）层面，而不能（更早期地）深入到自研硬件系统的模型层面（需要的不只是时间和人力，还有模型的稳定性和与硬件逻辑映射的准确性，都不是一家初创公司在早期能够承受的），因此这种软硬件系统的流程看起来很美好，但并不是每一家芯片公司的标准配置。这也能解释目前国内虚拟建模领域的有限性，从国外这一领域的发展经验来看，对安全性、准确性、稳定性要求越高、行业集中度越高的芯片公司，越有意愿和需要来做这件事情，比如最近多年，DVCon Europe总是会将SystemC虚拟建模作为一个重要专题来讨论，而这其后的背景在于他们的汽车电子芯片对安全性和稳定性的要求要显著高于消费类电子芯片，换句话说，该领域的芯片更愿意花时间和精力打磨出一个更系统的软硬件协同方案。

图片来自 Cadence

那么，为什么PSS有希望能够帮助解决软硬件系统验证这一难题呢？从我在学习和应用这一标准的体会来看，恰恰是PSS已经放弃像SystemC那样大一统了（即从软件层和架构层开始建模、编程、甚至做物理综合这样由软件来映射到硬件）。由软件映射到硬件和由软件定义硬件在流程上我认为是有区别的，后者在硬件实现上有更大的空间。从目前的工程实践经验来看，软件定义硬件（比如AI领域的芯片开发），已经在该航道上行驶了。而在这一航程上，硬件的实现需要考虑软件的约束，并进一步加速软件执行。PSS的推出，实际上也承认这一点，即我们已经无法试图在验证平台、测试场景（验证计划）和验证量化标准（各项覆盖率和数据格式）上形成硬件和软件之间的统一和复用了，那么最有希望且EDA和芯片厂商们都优先达成的统一便是测试场景的统一了。

怎么来理解这个标准推行背后的利益一致呢？正如我们之前已经抛出的，验证平台尽管在UVM上达成了一致，但从IP验证平台到系统验证平台，从需求和实现上来看，存在着不小的差异。在这一点上，各家芯片公司有他们自己的方案，无论采取统一的还是定制的，至少它们被证明可行，而EDA公司在验证平台层面上，被利用最多的还是它们的VIP（Verification IP）即底层验证单元库。如何达到从IP级到系统级的验证平台规范统一，目前行业并没有急迫的需求要解决这一问题，而初创公司在这一方面的经验也依然有限。

对于《芯片验证漫游指南》熟悉的读者也知道，在该书中我也专门用第十五章“验证平台自动化篇”推出了路科自研的平台“Pangu”，目前该平台经过升级成为Liezhen（列阵）以后，要解决的问题之一，便是从IP验证级别到系统验证级别的统一性，即给出一个伸缩性好、可适配性好的验证平台来纵跨不同的验证层级。目前该平台已经投入到商用配置的多个客户项目中投入使用，得到最多的反馈即是该平台带来的验证环境快速部署能力和数据测试打通的便捷性。而Liezhen自动化验证平台的另外一个特性，即提供了标准的测试接口，为接下来的测试用例复用（即自由选择测试语言SV或者C），天然地与PSS共同指向了测试场景统一性这一目标。具体的案例，我们将在其后的示例和芯片验证V3课程中做详细实践。

PSS为什么会是EDA和芯片厂商们在推行下一代验证标准时的首要利益点呢？首先，该语言标准类似于SV一样在2005年推出SystemVerilog 3.0标准、UVM在2011年推出UVM 1.0标准时的背景一样，都是首先吸收了不同语言或者方法学的优势，由主要的EDA玩家带着它们已有的PSS方向工具（一开始采取均是自己定义的语言标准），给出了综合的标准规范建议，经过整理和回顾所得。而芯片厂商们的验证领队也更关心在推向客户的整个过程中，验证面临的首要挑战已经从以往关心的覆盖率完备性转向了测试场景在跨越验证层次中的一致性了。

在这里，并不是覆盖率完备性和随机验证不再重要了，而是越往高层次，越需要将目光转向实际场景的应用、各个子系统、IP之间的调度协调和它们之间可能存在的场景可能性。换句话说，IP级的随机验证应该更多关注协议层面和数据包层面的随机性，这一点SV/UVM可以实现，并且有对应的覆盖率提供支撑，至于覆盖率如何快速收敛，有相对应的工具能够实现（我们也会在V3课程中推广Mentor Infact工具在IP验证覆盖率线性收敛的优势，注意，是线性收敛！）。

那么在系统层面，是不是就该使用C测试而放弃随机测试了？这也是目前验证不同流派讨论的一个焦点。建议使用C的原因在于，系统层面绝大多数都有真核处理器，那么就应该使用C来完成测试，这也便于与以后的硅后测试形成测试语言一致性的对接；而不同意只采用C测试，也赞成同时引入随机测试的观点在于，在系统侧面的定向测试往往固定了整个场景和数据，这使得原本就消耗更多运算资源和人力的系统测试，在后期的回归测试中的价值在逐渐衰减。

那么在系统层面，是否应该引入随机测试呢？路桑的观点是应该引入，不过引入的方式可能与现有的实践方式有区别。

先来看看，目前Liezhen平台在系统测试层面，能够采取的随机测试方式有哪些？Liezhen可以在系统中的互连网络（internetworking）中为验证开辟的触发端（initiator port）接入适配接口的随机激励，或者直接代管处理器与互连网络的接口进行数据收发，至于测试接口语言可以采用C或者SV的标准接口，也可以在更底层采用传统的UVM测试序列做细致约束实现。想必这些实现方式，一些团队已经在使用当中了。那它们与IP级的随机有本质差别吗？其实是没有的，因为它们所关注的随机层级仍然局限在接口时序和数据包内容上面，这并不是说这一点在系统级没有意义，而是说在系统级的验证也应该伴随着从IP到系统级的跃升，发生层级的变化，也应该上升到系统测试场景的随机，即测试场景中可能关联的设计单元实例、功能模式、协作方式（串行、并行）、关键资源（数据存放、数据流通信、资源互斥或共享）等系统资源的随机调度。这恰恰是以往在系统层面中的测试所缺少的、或者无能为力的。

因此，在系统层面的测试，并不是不需要随机，而是也应该相应地提升随机的层次和量化系统随机的覆盖率（覆盖率指标也需要对应提升，来标照系统的随机性资源调度覆盖率）。

这里再回到本节的提出的问题，PSS为什么有机会来解决测试场景的一致性呢？这就是该标准中一开始提到的目标，即，它可以用以来定义一个统一的定义激励和测试的场景，而该场景的使用可以横跨不同的验证层级和配置，并且用来为该测试场景产生不同的测试代码，继而能够运行在不同的测试平台上，这包括但不限于仿真平台、硬件加速平台、FPGA原型验证平台和硅后测试平台等。

从这一目标的提出和PSS与其工具的应用模式来看，第一，PSS的标准不代表颠覆性，即它不会影响原有的测试平台、测试语言和测试接口；第二，PSS的引入不会为原有的测试流程带来新的岗位和跨部门的频繁沟通压力，这里要提醒的，新的工作量恐怕是不可避免的，但也仅限于不同部门对于PSS投入的运用，即对于不同的流程，该流程是可选项，但不要求不同的测试平台全部采用PSS，而采用PSS也没有资源依赖性，即各个平台都可以自己投入和产出PSS，也可以共用PSS构建的测试意图，这种流程引入不至于伤筋动骨，对保守的芯片验证流程需要先在某个阶段例如从IP级到系统级的仿真阶段引入PSS先试吃螃蟹，没有全盘推进的压力，可在某个项目试行；第三，PSS可以在任何的产品周期进行热插拔，比如在产品第一版流片之前迫于项目压力没有采用，在后期延续项目过程中，还可以引入PSS，来梳理系统层面的测试场景，补充系统测试中的资源调度随机性和对应的覆盖率，增加系统测试的完备性。

所以，在本节的末尾，希望读者们可以认识到，PSS可能会为将来的验证流程带来这些新的变化，它们包括：

• 测试场景可以在早期与架构侧和软件侧进行沟通，在确定和建模系统资源之后（利用PSS），共同定义测试场景，该方式由于PSS的DSL属性，要比更抽象的自然语言规范或者对模型更准确的C规范更易于在早期、不同团队之间展开。

• PSS的学习曲线对于不同的参与者而言，不是相同的难度，即利用PSS做测试场景建模的工程师和采用PSS测试场景并为之提供映射测试单元动作（atomic action）接口语言实现的工程师是不相同的，总体的学习难度就SV相比而言，更易于上手，且有SV/UVM的诸多属性和测试习惯可以参照。

• 在不同层级的验证过程中，验证工程师还将会持续贯彻他们之前的验证动作，例如IP验证仍然重点落在接口协议、数据完整性和功能特性检查上，但与此同时，PSS的测试场景将会纵跨各个验证环境层级，验证工程师需要提供测试单元动作的接口映射，将系统测试场景的实现、随机化和覆盖率引入到不同验证等级。

• 原有的系统验证测试用例，在习惯了PSS方式之后，可能会更多地转向先利用PSS实现测试场景描述，继而利用PSS测试场景来实现更为详尽和系统资源随机性覆盖更全面的测试代码生成。做出这一点的转变，也应该是处于意识到了系统验证中资源随机调度的重要性而做出的决定，并且PSS在实现系统资源调度随机和底层测试驱动接口的随机性上面都能兼顾，从而使得验证工程师可以利用PSS既能够更准确地关注到系统层面建模和测试，也能够利用PSS工具保证底层随机的完备性。

测试场景可以在早期与架构侧和软件侧进行沟通，在确定和建模系统资源之后（利用PSS），共同定义测试场景，该方式由于PSS的DSL属性，要比更抽象的自然语言规范或者对模型更准确的C规范更易于在早期、不同团队之间展开。

PSS的学习曲线对于不同的参与者而言，不是相同的难度，即利用PSS做测试场景建模的工程师和采用PSS测试场景并为之提供映射测试单元动作（atomic action）接口语言实现的工程师是不相同的，总体的学习难度就SV相比而言，更易于上手，且有SV/UVM的诸多属性和测试习惯可以参照。

在不同层级的验证过程中，验证工程师还将会持续贯彻他们之前的验证动作，例如IP验证仍然重点落在接口协议、数据完整性和功能特性检查上，但与此同时，PSS的测试场景将会纵跨各个验证环境层级，验证工程师需要提供测试单元动作的接口映射，将系统测试场景的实现、随机化和覆盖率引入到不同验证等级。

原有的系统验证测试用例，在习惯了PSS方式之后，可能会更多地转向先利用PSS实现测试场景描述，继而利用PSS测试场景来实现更为详尽和系统资源随机性覆盖更全面的测试代码生成。做出这一点的转变，也应该是处于意识到了系统验证中资源随机调度的重要性而做出的决定，并且PSS在实现系统资源调度随机和底层测试驱动接口的随机性上面都能兼顾，从而使得验证工程师可以利用PSS既能够更准确地关注到系统层面建模和测试，也能够利用PSS工具保证底层随机的完备性。

至于这些变化什么时候会到来，国内的情况恐怕与美国和欧洲的发展现状不同，对于PSS的推广和部署也会不同，但从现有的系统测试痛点来看，PSS的引入、该标准的日渐成熟、及其多个工具在PSS标准推出2.0以后对于该语言标准的支持，都在宣告目前我们现在“买入PSS”的时机是合适的，尤其是已经迈入验证职业3+年的工程师，了解PSS的基础语法和基本应用场景，对于在未来有机会应用PSS并试水，提供了可能性。

为什么现在“买入PSS”标准正当时，以及该标准大概在何时能够在团队中或者行业中进一步扩大影响力，并逐渐成为动态仿真中的一个必要“环节”，以及对该标准的推广度和易用性的评价，也将在本篇的后续内容为大家逐一分析。

#外记

在准备芯片验证V3课程途中，我们由于需要引入PSS的语言基础和工具应用，我就不得不将可能归于下一本书有关系统验证构建的内容，提前开始布局，而PSS作为各大EDA厂商和芯片公司共同推动的下一代验证规范（与SV/UVM不冲突、不替代），将是这本书中的主要角色之一，我选择在PSS 2.0标准推出后的不久来完成该书的这部分内容，也是认为这是一个合适的“买入”时机，毕竟从18年的PSS 1.0到21年的PSS 2.0已经过去了3年时间，而PSS 2.0标准又增加了很多新内容有待需要解读。更重要的是，在结合国内芯片发展现状来看，在未来的2-3年出版一本有关于系统验证的工程实践图书，也可以及时满足国内广大工程师的需要。希望这个愿望，能够将《芯片验证漫游指南》出版以后更多的工程实践经验分享给读者，促进国内芯片验证的技术发展。

除了这门升级中的V2Pro课程，恐怕你找不到更好的学验证的途径了

在V2Pro春季班开班前，你是否还在疑虑这些问题？

路科发布| 稳中带涨！25w成芯片校招薪资平均底！2020应届秋招数据全面分析！

相约今晚8点 社招转岗有顾虑？成功上岸的同学来帮你

UVM RAL模型：用法和应用

如果你突然被裁员了，你的Plan B是什么？

[彩虹糖带你入门UVM]

理解UVM-1.2到IEEE1800.2的变化，掌握这3点就够 返回搜狐，查看更多