有些是市场营销，有些是技术变革，但问题正变得越来越严重。
我发现令人惊讶的是，一个技术领域试图在合理的怀疑之外表明，一个设计在被构建之前是可行的，却在一些基本的事情上做得如此糟糕。我说的是验证术语。
我在这个行业已经呆了40多年了，但情况并没有好转。事实上，情况正在变得更糟。我和那些不得不花时间定义基本术语的人打过很多电话，这是荒谬的。有些困惑可以追溯到很久以前。其中一些是由一家大型半导体公司发起并延续下来的。其中一些是由营销人员造成的，他们想让一些东西看起来比实际更好。
让我们从最早的困惑形式开始。这就产生了诸如测试、测试用例和测试工作台之类的术语。40年前，模拟是生产测试行业的工具。设计师没有模拟。测试人员是巨大而昂贵的机器，您需要开发能够以离线方式在这些测试人员上运行的测试。开发了一组向量，将其加载到测试器中，输入到被测试的设备中，并捕获结果并与黄金向量进行比较。覆盖模型是卡在模型，因为它已经表明，虽然不是所有的制造故障都会导致某些东西被卡在0或1上，但它提供了一个可靠的度量标准来衡量测试的质量。
然后出现了半导体行业，验证的概念从测试行业演变而来。一些公司正确地尝试将名称更改为验证工作台、验证案例和验证下的设计，但这些术语几乎从未使用过。像验证和验证这样的术语由许多组织定义，并开始出现在高科技词典中。虽然这些定义之间存在一些差异，但基本上都是相同的。验证是确保实现与规范相匹配，验证是确定规范是否正确。当时很少有公司进行验证。这就是市场所做的。公司要么购买你的产品，要么从你的竞争对手那里购买，后者开发了一种略微不同的产品。
核查有一些灰色地带。例如，当将设计映射到模拟器或FPGA原型系统时，您创建的实现并不是最终将在硅中实现的实现。所以当你验证那个实现时，你实际上并不关心，你是在进行验证还是验证?实现是最终实现的代理。只要遵循了所有规则，您就相信这些工具在功能上是等价的，因此您正在验证代表设计的RTL。RTL并不是突然变成规范的。它是一个实现，其他实现都是从它派生出来的。这仍然是一种验证行为。
处理器呢?由于RISC-V的出现，这已经成为一个更加活跃的话题，而且它实际上非常简单。分界线是ISA，也就是规范。那么，您是在验证ISA实际上是您想要的ISA，还是在验证您的实现与ISA规范匹配?新的术语，如一致性和限定也在这里发挥作用，这些是由组织定义的松散术语，表示您通过了我们定义的测试用例集。
如果不修改ISA，就不进行验证。RISC-V国际已经为您完成了。您正在验证一个实现。如果你在那个处理器上运行软件，你是在看处理器是否工作。只有在评估处理器是否能够有效地执行该软件，或者修改ISA是否能够提高其性能时，才需要进行验证。如果在运行软件时发现处理器中的瓶颈，这就是验证，因为它与实现有关。你的实现不是最优的，需要修正。
当您试图将这些术语应用到软件本身时，确实会变得有点困难，因为软件很少被指定。这里只有实现，那么您将它与什么进行比较呢?在没有规范或黄金模型的情况下，他们实际上是在做测试——戳软件，看看它是否能做正确的事情。顺便提一下，shmooing实际上是一个来自测试行业的术语。
我还听说过在与标准相关时使用验证术语，比如新的内存接口或其他高速接口。人们说他们试图确定规范是否正确，但大多数时候他们实际上只是在问:“我们知道如何实现它吗?或者它可以使用我们今天可用的技术来实现吗?”如果他们基于实现的尝试改变了规范，我想它可以被定义为验证，即使是出于错误的原因。该规范可能是正确的，但如果没有人能够实现它，则可能没有用处。
还有像功能性覆盖率这样的术语，这是一个笑话。功能性覆盖没有任何功能性。它是一种实现观察，人们已经确定它是已经执行的某个功能的代理。这是一个可怕的度量标准，实际上并不能告诉您任何关于完整性的信息。至少对于大多数实现指标，比如代码覆盖率或路径覆盖率，它们实际上可以告诉您一些消极意义上的有意义的事情——它们会告诉您什么时候还没有完成。他们会在你的验证中找出漏洞。功能性覆盖率不能说明任何问题。它不是一个好的实现度量，也不以任何方式与规范的覆盖联系在一起。
当我们谈到规格的主题时，这里有一个我最喜欢的-便携式刺激。设计这个名称是为了确保它在标准组织中听起来与SystemVerilog没有竞争。它是一个预期功能的模型，因此可能是业界尝试的第一个真正的验证环境。SystemVerilog只不过是一个碎片的大杂烩，从中可以创建一个有点缺陷的验证环境。便携式刺激还定义了一个可信的覆盖模型——不是添加到它上面让它看起来像SystemVerilog的那个，而是基于图覆盖的自然模型——这是数学家们已经研究了很长时间的东西。
因此，如果你曾经考虑使用术语验证，确保你真的确定规格是否正确。大多数人和大多数公司都不做验证。他们的营销部门以非常宽松的方式为他们做这件事。
|
|
|
|
|
|
|
|
|
使用术语“回归”而不是“测试套件”是我最讨厌的。“回归”是以前开发和测试的系统在更改后不能正常工作时所发生的情况。
你好，布莱恩
我忍不住写了一些我不同意的东西:
(a)你写道:“例如，当将一个设计映射到模拟器或FPGA原型系统时，你创建的实现并不是你最终将在硅中实现的实现。所以当你验证实现时，你实际上并不关心，你是在进行验证或验证行为吗?”
我很困惑——在你最初的定义中，为什么会把“模拟”和“原型”过程视为“验证”?如果有人同意“验证”是为了验证规范，那么就不应该围绕传统的RTL仿真进行任何讨论，仿真、原型甚至可以被认为是“验证”步骤。只是说。
(b)这个对我来说是难以置信的。不确定你是如何指出“功能覆盖”是一个笑话。我同意你的说法，各种各样的代码覆盖率度量可以告诉你你错过了什么。一般来说是这样的。应该使用覆盖率度量标准——更多地用于被遗漏的内容——而不是被覆盖的内容。但“功能覆盖率”作为一个指标确实很有用。这独立于底层验证技术——模拟/形式化验证/仿真。当您在验证过程中没有覆盖“功能性事件”时——这是一个巨大的重要信息。为什么它不如传统的行/分支覆盖重要?这根本说不通。
嗨，Rajeev -关于你的第一点，很多人认为只要涉及到软件，你就不再验证硬件了。您可能还在验证软件，但除了在非常特定的条件下，您还将继续验证硬件。至于第二点，这是因为建立一个好的覆盖模式需要智慧，而且需要很多智慧。我认为这是一个糟糕的度量标准。同样，从一个覆盖漏洞到创建一个覆盖它的场景是不容易的，更困难的是约束一个UVM测试平台来攻击它。当您与验证团队交谈时，他们所挣扎的事情之一是创建一个良好的覆盖模型，而这只是那些意识到他们正在做什么的人。问问Harry Foster，他对那些使用功能覆盖的人有什么看法，这意味着他们在一个大型设计中有10个覆盖点。
嗨布莱恩
核查术语似乎没有趋同，这确实令人恼火。
这是我不久前写的一篇相关文章，你可能会觉得很有趣:https://blog.foretellix.com/2015/08/09/terminology-for-multiple-verification-tribes/
你能评论一下在uvm环境下音序器的使用吗?
很好地总结了我们所研究的错觉。有趣的是，验证本身的基础是:没有BUG的证据&没有BUG的证据
曾在类似的线上发帖-
https://whatisverification.blogspot.com/2010/10/proof-of-no-bug-or-no-proof-of-bug.html
“符号执行”用来指软件执行的路径符号探索。