来源：内容由 公众号 路科验证 （ID：Rocker-IC）编辑部 原创，谢谢！

首先声明，便携式激励标准(PortableStimulus Standard, PSS)不是一种方法论，而是一种语言。使用语言我们可以有序地传递信息，从而去构建工具，但工具也不是方法。我们所说的方法是指以某种可管理的方式系统地分解及解决问题的手段。工具可以支持方法，并且随着时间的推移，工具可以在方法标准化之后帮助管理方法。但目前还没有针对PSS的标准方法，也没有该语言定义的工具功能。

用便携式激励语法所说明的基于图形的验证技术，在供应商之间提供了某种程度的通用性，这种基于图形的验证技术即我们所用的工具，这些工具可以在现有的方法论中使用，也可以创建以前的工具不支持的新工具。当供应商提供标准之外的功能时，用户群体会决定这些功能的有用程度，并将有用的部分打包到标准的未来版本中，忽略不太有用的部分。这其实就是语言的演变过程，特别是对于在标准出现之前就定义了的语言来说。

举个例子，上一代验证解决方案依赖于功能覆盖率来确定特定测试用例的价值，用RTL功能覆盖率度量的覆盖率代替验证意义上的覆盖率。运行测试时，它认为设计中的值等同于正在执行的预期行为。验证工程师很难创建良好的功能覆盖率模型，更难通过修改约束来增加覆盖率。

使用便携式激励工具会捕捉设计的预期行为，其目标是意图覆盖，它确切地知道一个特定的测试用例应该覆盖什么样设计意图。这样看起来RTL上的功能覆盖率似乎不能提供其他额外的信息。

并非如此。如果PSS模型遗漏了预期行为的一部分，那该怎么办？相对地，如果RTL没能实现所有需要的功能，又该怎么办？基于图形的意图覆盖仅表示测试生成工具认为测试的完整程度，RTL上的功能覆盖不能找到丢失的功能，所以意图覆盖和RTL功能覆盖之间的相互补充可以保证功能的完整性。

这种两面性正是设计和验证的核心。它需要两个独立的模型，系统地对进行比较，找出可能在设计、测试平台或规范中出现的缺陷的差异。但问题是：PSS用户将发觉，与PSS中提供的功能覆盖率相比，RTL功能覆盖率的旧概念有多重要？功能覆盖率只能在仿真中收集。单元级的模拟速度虽然很快，但却无法测试系统级行为，系统级测试平台很慢，这就意味着不能运行大量的测试。

意图覆盖是否应该与仿真中的功能覆盖相关联，以获得对PSS模型的信任，然后应用硬件仿真、FPGA和post-silicon来适当覆盖其余的大型意图覆盖空间？这由用户决定的，继续使用现有的功能覆盖机制的确为用户从一个解决方案迁移到另一个解决方案提供了一种熟悉的机制。用户可能会发现它非常有用，特别是在刚开始的时候。或者也可能认为其得不偿失，这种机制不值得，当然了，功能覆盖现如今被看作是一项要耗费大量时间和精力的工作。

随着时间的推移，方法不断进行优化，同时也在创建相应的工具，比如，帮助提供自动化和追踪。现有的验证管理器类似一个中央驾驶舱，在这里可以存储结果和进度，并启动新的验证活动。首次定义带约束随机时还没有验证管理器，直到它实践到最佳才开始出现。如果你认为这些管理器是基于PSS解决方案的正确使用方法，那就错了。毕竟用户还没有机会确定如何使用现有的解决方案以及希望在其中看到的更改。

在Breker，我们鼓励用户群体探索优化他们时间和资源的方法，并提供我们认为对探索有所帮助的功能，并期望其中的一些功能能被广泛应用。例如，TrekSoC可以提前生成完整的测试，也可以是被动生成的。它能够生成在嵌入式处理器上运行的代码，或者利用与DUT的事务通信，两者兼有也可。每种方式支持不同的方法论。

我们一直并将继续响应用户的需求，可能是通过现有方法的扩展，例如围绕System Verilog和UVM设计的方法，或者是新方法的创建，这些新方法到目前为止依赖于手动工作，没有任何形式的自动化或追踪技术。

作为供应商，我们会了解多数用户正在做什么尝试，并对这些功能的改进支持力度。方法学就是这样发展壮大的，我们一起努力就可以做到。

---

作者介绍

Adnan Hamid, CEO of Breker

Adnan Hamid是Breker的创始人兼首席执行官，也是核心技术的发明者。在他的领导下，Breker已经成为复杂片上系统系统(SoC)功能验证技术，特别是便携式激励技术的市场领导者。Breker在自验证测试用例自动化方面的专业知识为SoC的验证完整性设定了标准。

原文来自：https://www10.edacafe.com/blogs/thebrekertrekker/2019/01/15/methodology-language-and-tools/#more-2112