业界缺乏在验证中有效使用抽象的方法，但这种情况可能正在改变。
验证依赖于关注点的分离。否则任务就没完没了。有时我们不假思索地这么做，但作为一个行业，我们从来没有设法完全定义它，从而使它成为一种被接受和信任的方法。当我们把抽象性引入画面时，这一点变得尤其正确。
虚拟原型意味着对行为是真实的，但是在它和低级抽象(如RTL)之间可能存在时间差异。这些时间差异是由于实现细节造成的，比如处理器的微体系结构、它的管道以及像中断这样的东西是如何实现的。只要RTL不添加或删除任何行为，这些都不会使虚拟原型失效。修改行为意味着RTL实际上有一个错误。我们可以更进一步地说，RTL的每个可能实现都必须符合行为模型。
在理想的世界中，验证意味着独立于设计，这意味着测试台可以验证设计的任何实现。在现实中，这种情况有很多例外，因为以黑盒方式做所有事情不仅更困难，而且更耗时。便携式刺激(PSS)之所以有趣，是因为它在这方面采取了中间立场。测试平台知道实现中存在的数据路径，但不知道它们的细节。它不知道它们的实现，在大多数情况下，甚至不能推断它们是否利用了共享的通信结构，尽管可以将这些知识嵌入到模型中。
利用虚拟原型进行验证是有问题的。因为我们不能正确地确定正在验证什么，所以很难知道每次运行都完成了什么。软件的行为是否得到验证?如果时间发生变化，是否会影响验证行为?几乎可以肯定，在时机改变了某些事情的结果之后，它会走上不同的道路，这就是问题的一部分。验证依赖于始终验证同一件事情的测试，如果没有测试，关闭覆盖可能会变得更加困难。
这件事有两面性。在RTL模拟中，每次我们使用特定的测试平台进行模拟时，都会得到相同的结果。即使有两个并发输入，在现实中，每个输入都有50/50的机会被首先“看到”，模拟器总是会首先看到相同的输入。这有点问题，因为这意味着模拟器从几个可能的路径中选择一个，并掩盖其余的路径。我们可以认为，如果这是重要的，它将导致一个覆盖漏洞，并且有人将发现如何调整测试平台以允许选择其他订单。
我们该如何避开虚拟原型困境?这就是这个行业一直没有找到答案的地方。业界采用的是统计方法，即你应该在模拟器或原型系统上重新运行在虚拟原型上运行的特定百分比的测试。在这方面，模拟器不太可能有用，因为对虚拟原型的任何合理测试都可能在模拟器上花费过多的时间。
便携式刺激计划可能会为我们提供答案。当测试合成引擎创建测试时，它知道任务之间的所有依赖关系，以及如何以及何时应用外部刺激。它从测试台上拿走了所有的绝对计时，这就是问题的根源。因此，如果一个任务在实现上或者甚至在真正的硅上运行时花费了更长的时间，这并不重要，模型和测试合成的方式意味着它们将始终在测试台模型方面提供相同的覆盖率。实现级别的覆盖可能会因为局部时间差异而改变，但是PSS模型定义的图的覆盖将保持不变。
不幸的是，致力于PSS的Accellera委员会还没有设法标准化PSS覆盖模型，而是依赖于对SystemVerilog中存在的现有实现覆盖概念的扩展。拥有基于图的模型将使虚拟原型上的验证成为流的一个定义良好的部分，并减少跨抽象所需的重复量。这些都不能消除对独立块级验证的需要，也不能消除systemverilog类型覆盖的概念，但它将为验证流中抽象的有意义的角色铺平道路。
我承认，我远不是便携式刺激计划专家，所以我在这一点上可能是错的。我很想听听其他人的意见。
|
|
|
|
|
|
|
|
|
|
你好布莱恩,
虽然PSS试图解决部分问题，但我相信更深层次或根本原因还在于我们将以下陈述转化为现实世界——“在理想的世界中，验证意味着独立于设计，这意味着测试台可以验证设计的任何实现。”要做到这一点，反映设计/意图的文件必须完整。在现实中我们错过了它!!另一个问题是像UVM这样的标准的有效使用。我们讨论了较长的模拟时间，但没有数据表明模拟时间也因UVM的不正确使用而变得沉重。增加困境的不是设计或刺激方案，而是实验台。不幸的是，对于验证来说，跨行业抽象似乎是遥远的!!