找到一个错误应该是一个提示来寻找更多的人在同一地区。
在几代cpu在分析错误,我得出的结论是,“虫子飞在中队。“换句话说,当一个错误被发现在一个特定区域的设计,还有其他错误的概率与相似的条件下,在同一地区的设计,是相当高的。
找到一个CPU错误总是令人满意的,然而它本身不应该结束。如果我们考虑到虫子不单飞而是在团体或飞行中队——找到一个错误应该是一个提示处理器验证团队寻找更多的人,在同一地区。
这是一个场景。一个随机测试后发现了一个bug数千小时的测试。我们可以问自己:它是如何找到这个错误呢?答案是可能的组合之前没有遇到的事件。另一个问题可能是:为什么随机测试发现这个错误呢?这很可能是由于外部修改:修改参数测试,RTL修改,或模拟器修改为例。
罕见的错误发现,有了这个新的,我们知道我们有一个更好的性能testbench,现在可以测试一个新的设计领域。之前,然而,我们也知道testbench得到改善,这个区域的设计并不强调。如果我们认为bug在中队飞行,这意味着我们有一个新的设计领域进一步探索发现更多的缺陷。我们如何提高我们的验证方法?
改善我们testbench和打击这些错误,我们可以添加跳棋和断言,我们可以添加测试。让我们关注测试。
扩大范围,所以我们有信心我们将这些错误,我们使用smart-random测试。当复制这个错误直接测试方法,只达到同样的错误。然而,我们说虫子飞在团体和有其他错误的概率在同一地区,具有类似条件下,高。我们的想法是我们扩大范围。随机测试将不会有用,在这种情况下,因为我们了解我们想要的目标,遵循中队的模式。
假设缺陷被发现在一个特定RISC-V指令。我们可以提高我们的测试该指令通过增加的概率测试?乍一看,可能,因为统计你得到更多的失败暴露相同的错误。然而,大多数bug被发现的罕见的事件:一个停滞的管道,一个完整的FIFO,或其他microarchitectural实现细节。标准testbenches可以很容易地调整的概率一个指令通过简单地改变测试参数。但做一个FIFO完整是不能直接访问从测试参数。它是其他独立的组合参数(如延迟),使先进先出完整的多。
使用smart-random测试在我们的验证方法允许我们是针对性和广泛足以有效地找到更多的错误在这个新发现的区域。它包含在调优测试激活更多的其他事件引发错误。换句话说,这意味着调整几个参数的测试,而不仅仅是一个。看起来更耗费时间,但这种方法很有效的提高我们的测试质量。
改善testbenches遵循bug中队,杀死他们每个人在产品开发是关键。
|
|
|
|
|
|
|
|
留下一个回复