确定验证方法找到最后一个bug的能力。
经常有人问我这样一个问题:“处理器验证什么时候完成?”或者换句话说，“我如何衡量我的测试平台的效率，我如何对验证的质量有信心?”这个问题没有简单的答案。在行业中有一些常用的指标，如覆盖率和bug曲线。虽然它们是绝对必要的，但这些还不足以达到尽可能高的质量。事实上，这样的指标并不能真正揭示验证方法找到最后一个bug的能力。有了经验，我懂得了测量处理器错误的复杂性是一个很好的指标，可以在整个项目开发过程中使用。
经验告诉我，我们可以通过计算击中bug所需的独立事件或条件的数量来定义bug的复杂性。
让我们举一个简单的例子。一个典型的错误是在缓存中发现的，当必要的危险缺失时。数据损坏可能发生在以下情况:
外部内存返回以前的数据，因为来自驱逐的最新数据丢失了，导致数据损坏。
在本例中，需要4个事件(或条件)来命中bug。这4个事件给这个bug打了4分，换句话说，复杂度是4分。
为了衡量一个bug的复杂性，我们可以提出一个将被整个bug使用的分类处理器验证团队。在之前的博客文章中，我们讨论过4种类型的bug并解释了我们如何使用这些类别来提高我们的测试平台和验证的质量。让我们更进一步，将这种方法与bug复杂性结合起来。
一个简单的错误可能需要触发1到3个事件。第一个简单测试失败。一个角情况下将需要4个或更多的事件。
回到上面的例子，我们有一个4分的bug。如果四个条件中的一个不存在，那么bug就不会被击中。
一个有约束的随机测试平台需要几个特性才能达到上面的例子。地址序列应该足够智能，可以重用以前请求中的先前地址，外部总线上的延迟应该足够非典型，以实现快速读取和足够慢的写入。
一个隐藏的情况下将需要更多的事件。也许更微妙的错误与我们的例子具有相同的条件，但它只在缓存上发现ECC错误时发生，与中断发生完全相同，并且仅在核心完成FPU操作时发生，导致除零错误。在典型的随机测试台中，概率有所有这些条件加在一起非常低，使其成为一个“隐藏的”bug。
使这些隐藏的错误在测试台中更容易达到是在提高验证的质量。它是把隐藏的情况变成角落的情况。
这种分类没有任何限制。经验告诉我，一个能够找到8分或9分的错误的测试平台是一个强大的模拟测试平台，是交付高质量RTL的关键。据我所知，如今最先进的模拟测试平台都能找到复杂程度高达10级的bug。幸运的是，使用形式化验证可以更容易地发现具有更高复杂性的bug，为更好的设计铺平道路，并为在模拟中改进什么提供线索。
这种分类和方法只有在验证开始时以及在整个项目开发过程中使用时才有用，原因有二:
最后，通过将这种方法与我们的方法相结合，包括猎杀成群飞行的虫子，我们确保高水平的质量验证，这有助于我们确信我们超越了验证签署标准。
|
|
|
|
|
|
|
|
留下回复