PSS学前准备篇之三：如何引入PSS流程？
在我们发布了上一节“PSS能带来什么变化”以后，有朋友在后台留言询问PSS目前在哪些公司开展使用，我给的回复是，Cadence在国内推广他们的Perspec工具有一些时间了，而Mentor其实在更早就推出了他们的类似PSS标准的工具，而Synopsys研发人员也宣称他们会在今年推出一款PSS应用工具（可能代号为VC PS）。愿意尝试这些工具的公司，或者是人员充沛、有先锋项目可以尝试新方法和新工具，或者是该企业对研发节点没有太紧急的压迫感，有时间试用新方法。只不过国内企业满足上述条件之一的并不多，最近这两年我服务的企业研发团队也是以产品和项目为导向，很少有时间去做这些他们认为是“锦上添花”的探索。
没办法， 要推广PSS标准，就如同推广UVM一样，只能路科自己来了吧。我们希望读者们能够跟我们一起学习这门新技术，更直观地感受它的细节、再提高到系统层面理解它的魅力，能够在接下来的PSS基础和PSS应用两部分学习以后，在有时间、有技术的情况下试用这些新方法，为下一代的验证技术演进做好准备，等风来之前先练好自身本领。
在考虑引入PSS流程时的第一个问题就是PSS会取代UVM吗？可以给的回答是，它并不会取代UVM，它与UVM之间关注的层次不一样，要解决的问题也在之前“PSS究竟意味着什么”里提到是不一样的。
首先，PSS要解决的是在不同的测试平台、不同的层次和不同的功能配置情况下，通过一个新的语言来描述测试意图。从层级来讲，PSS要比UVM更高，从激励控制接口而言，PSS也并不会与系统激励配置直接对接（它们之间仍然依赖于原有的测试接口语言，比如UVM和C接口）。
其次，如果要提高语言抽象度、做到抽象层次的测试场景定义，那么它必然无法做到像现存测试接口一样的对激励控制的颗粒度和细节。PSS作为一种新的语言，吸收了面向对象编程语言，硬件验证语言和行为模型语言的多方面核心特性，尤其 补足了其它语言在描述测试意图时无法触及到的领域。从PSS推广的应用来看，它会专注在特定的层级，而与其它测试语言（UVM/C）实现链接，利用现存语言和验证环境的手段、工具、流程和代码基础，更高效地实现项目产出。从这个层面来看， PSS与现存硬件验证语言的关系是并存与合作，不会将取代作为目的（验证工程师们也可以在这里松口气儿了吧，不至于前端的各种工具和手段都在赶着验证人员玩儿命狂奔）。
我们这里先撇开PSS在语法层面的基础，而是从起点直接传送到PSS应用的终点，即通过PSS模型与已有验证语言的互动，来看它们之间如何完成映射关系。由于现存验证环境中包含激励生成接口、监测、参考模型和检查等诸多要素，并且在系统层面对各个设计IP的功能配置、数据收发都存在相应的应用编程接口（Application Programming Interfaces，APIs）， PSS和现存验证语言之间需要通过一致的接口来完成，该接口就是过程接口（Procedural Interface，PI）。
在接下来的“PSS基础篇”中，读者们会看到更多的细节，即有哪些PI入口在PSS和C/UVM之间完成了互动，但在这里我们只需要从下面的图中认识到，为了完成这种测试映射关系，需要在底层PSS的单元动作（atomic action）实现与外部语言的链接。
这里的映射关系不只是支持API接口的映射，PSS也能够支持从外部语言中导入（import）类，实现更多的类型映射。与SV DPI import与export关系类似，PSS也可以导出动作（action）到外部语言，而外部语言可以将这些导出的动作像从库中调用函数来使用。
如果要更细致地划分PSS与外部语言之间的映射机制，那么它们可以分为这三种：
而以上这三种映射机制实际上，又不是相互独立的、或者存在着明显界限，在使用过程中，它们往往可以混合使用，灵活实现测试意图。而依赖这些不同的映射机制，PSS也可以实现多种测试形式，它们包括：
- 依赖PSS本身的测试活动执行顺序，可以通过直接调用导入PSS的API接口，来实现直接测试。这种方式本身不会实现额外的目标语言代码，而是会利用PSS工具引擎完成PSS和外部语言在测试时的动态绑定关系，这种方式类似于依然活跃于今的Specman引擎和仿真器之间的关系（Specman可以与多种仿真器实现绑定，这也是它当年实现热插拔、在EDA巨头之间寻求共生关系的产品定位）。
- 对应PSS中的某个组件模型，可以将它从PSS层级沉降到目标语言层级，即生成目标语言代码用来在描述该模型，而生成的模型代码可以参与到后续测试场景中。
- 针对PSS中的系统测试场景，也可以生成目标代码，继而能够直接在目标代码测试环境中利用该代码来完成测试。
从这些可能的PSS测试实现方式来看，PSS应用工具也可以从多个角度出发，来支持测试的实现。不过从目前的PSS应用工具来看，将PSS系统测试场景映射到测试目标代码是一致提供的功能。即测试代码生成环节由PSS工具结合PSS模型来实现，而生成的静态测试代码将在接下来由目标平台实现编译和导入。这种方式从工具开发的独立性来看，是包袱更少，也是更多验证团队愿意采纳的方式，毕竟这不会要求更多的流程和环境变化，即可将PSS模型和工具引入到已有环境中来，也保证了已有项目或者进程中项目的稳定性。
而以上对PSS测试映射机制和测试实现方式的可能性论述有助于接下来对PSS标准的学习过程中，能够在心中有基本的认识，那就是PSS标准的学习和PSS工具的特性应用是有联系的，但又不是能够完全划等号的，更何况在过去多年里，几家EDA公司的PSS产品仍然在一边向前走，一边吸取用户的意见，增加和完善产品功能。我们在接下来的PSS基础篇的学习基线，也会沿着PSS 2.0标准研读（而不是某一款具体的PSS应用工具）。
我们这里在谈到PSS标准和PSS应用工具的差别时，其实这对于国内未来EDA数字仿真工具扩大用户范围、增加用户黏性提出了某种可行的市场推广方式，可以试想我们在什么情况下，会引入一款国产数字仿真器产品（尤其是现存数字仿真器市场相当成熟）？如果它能够解决某些痛点，尤其是在未来2-3年里，系统测试空间复杂度提升、汽车电子安全性测试要求等情况下，如果能够借鉴PSS标准当初制定的初衷，在已有验证平台或者测试用例的基础上，更平滑地引入PSS和他们的数字仿真工具的话，那么这可能会成为用户的一个买入点。
那么，我们又走到了这一节要讨论的第二个话题， 什么样的工具会给验证工程师带来更多助力，赢得他们的肯定，再逐步扩大PSS的应用范围（而不是一开始就从流程层面来植入性推广，这种方式未必是推广的最佳路径）。
我们先来看，当前系统测试流程中（硅前和硅后），验证人员面临的痛点有哪些？一方面， 不同阶段的验证库之间的底层接口未做统一，另外一方面， 不同阶段的顶层测试意图也未做统一，这就使得如果要从PSS植入的角度（逆向引入）来实现，会遇到很多的阻力。
如果是正向引入呢？即在硅前系统级测试过程中，可以利用PSS对系统中的部分组件构建模型，并且在后续测试场景中引入这些PSS模型和必要的资源模型，来共同实现测试意图。而且这种正向引入，还可以分段式进行，比如认为应该在硅前系统级测试先开展PSS应用，那么其它部分的验证环境可以先不引入PSS。
在这种正向引入PSS的策略中，可能还会面临一个问题就是如何实现颗粒度合适的PI接口，使得PSS场景在描述测试意图时，可以不用考虑硬件功能的细节配置，而更关注系统层面的资源调度。如果缺少这样的PI接口，那么在PSS与外部语言的映射中，就难以把握抽象层级，使得不仅在不同验证环境中（UVM或者C）无法实现统一的PI接口，也使得同一个PSS测试模型无法在项目之间复用，这仍然可能归结于PI接口没有规范下来。
这里谈到PI接口的规范，其实思路有些像在系统软件开发过程中，会将硬件寄存器的单个配置、提升到整体功能配置、再提升到场景配置这样从单一驱动到函数封装，继而便于在软件层面可以实现统一接口以供其它软件开发人员调用。
关于PI接口的规范，我认为未来会有基于PSS的可以重用的SoC库，用来对处理器行为（例如Cache一致性、数据存储访问等）、存储模型、各类高速接口、片上网络数据传输、算法模型等做高抽象层面的归纳，统一它们的单元动作和与外部语言的PI接口，这样便于验证工程师能够更加有的放矢，在不同验证环境早期，有意识地朝着目标PI接口实现UVM序列或者C函数。
这种带有中间层PSS开发框架的思路，其实已经有PSS应用工具开发了，例如Cadence Perspec的基于ARM处理器结构的专有库和基于此系统的方法学库（System Methodology Library）。我认为在PSS逐步进入全球IC设计公司系统开发视野，逐步得到广泛引用以后，下一步就是推出一种 开源的PSS系统模型库（System Model Library），这种关系类似于SV与UVM的关系一样，相当于我们在未来会有一个更加统一和规范的与SoC不同类型组件对接的PSS模型和接口，基于这些规范的PSS模型和PI接口，用户可以更快地描述PSS测试，并且将其通过规范PI接口，实现为目标语言的测试代码。
从以上对PSS和现存验证语言的辩证关系论述可以知道，PSS语言标准的初衷是为了能够在不同测试平台、利用抽象模型快速构建测试场景，并将其在不同测试平台实现具体测试语言的映射。不过国内现有验证基础设施均已经多数基于UVM/C构架，如何将PSS模型和其测试场景引入到项目，也是需要积累更多的案例分享给读者。
路桑将会在未来推广PSS基础和典型应用的同时，也将介绍一些在客户那里引入PSS流程的案例，以作参考。由于我们在提供技术咨询的过程中，往往会帮助客户部署 Liezhen自动化验证平台，基于该平台的 标准测试指令以及对SV/UVM/C的多方位支持，都使得PSS的流程引入变得更为平滑，关于这一点读者可以在我们稍后的自动化验证平台应用篇和PSS应用篇逐步认识，当然对于已经具备一定验证经验的工程师，还可以参加我们的V3级别芯片验证课程对这些高阶环境架构展开进一步的学习。
系列回顾：
PSS学前准备篇之一：PSS究竟意味着什么？
PSS学前准备篇之二：PSS能带来什么变化？
除了这门升级中的V2Pro课程，恐怕你找不到更好的学验证的途径了
在V2Pro春季班开班前，你是否还在疑虑这些问题？
路科发布| 稳中带涨！25w成芯片校招薪资平均底！2020应届秋招数据全面分析！
相约今晚8点 社招转岗有顾虑？成功上岸的同学来帮你
UVM RAL模型：用法和应用
如果你突然被裁员了，你的Plan B是什么？
[彩虹糖带你入门UVM]
理解UVM-1.2到IEEE1800.2的变化，掌握这3点就够 返回搜狐，查看更多
责任编辑：