系统与设计
的意见

错误逃,“完成”的定义

需要改变什么验证改善的速度第一个硅成功。

受欢迎程度

荷兹利亚国家半导体的设计中心(NSTA)是我爱上了芯片验证的地方。我于1999年加入了这个团队,仍然在我二元同步通信,遇到了一群创新者与激情创造伟大的asic和改进我们不惜一切代价的方式。

这对我来说是快速学习,工程和验证管理双方的事情。我的大多数管理技能我从利今天仍然是我的一个好朋友。

有一天,我第一次看到著名的度量Bugs-Per-Week图(BPW)。BPW收集虫子发现每周由验证小组,以帮助确定tapeout芯片的准备。

经理预计这一趋势将越来越多的错误显示为团队获得速度,然后越来越少的设计变得清洁。不同的公司使用不同的阈值的图表作为tapeout清单项目。

你知道有时从第一眼看上去,你?但是周围的每个人都将它作为一个简单的事实,然后随着时间的推移,它对你们有帮助吗?每隔一段时间你问自己:这真的有意义吗?

嗯,我记得自己对利说,“你知道,我们真正应该计算的是错误的设计,不是我们已经发现的。如果BPW是因为验证团队的下降趋势只是累了,很难找到这些顽固的错误?”

错误逃

每两年,哈利福斯特,导师与威尔逊研究首席科学家进行验证研究。下面的图表是惊人的。

尽管投资数十亿美元的EDA工具的研发和验证数百亿劳动,只有30%到50%的ASIC设计功能足以让生产后的第一次尝试。甚至这并不意味着他们没有错误,这意味着他们没有bug的足够的关闭党。尽管我们努力,缺陷逃逸,使进入硅,一遍又一遍。

设计越来越大,我们作为EDA社会必须想出更好的主意。

尽管我们的努力,如果我们first-time-right只有30%的时候,便不可能有两个原因:

  1. 我们没有足够的时间来完成一个合适的验证过程。
  2. 我们的“完成”的定义是不够好。

解决第一个原因,我们必须移动速度与验证。在我的前一篇文章我几乎做我谈到如何处理更快的收敛性验证的最后一英里,从95%到100%,Vtool Cogita可以如何帮助。

但100%的什么?

这让我第二个原因——“完成”的定义。

到目前为止,我们的数字功能验证的“完成”的定义是基于代码和功能覆盖率。而这些都是重要的指标,100%在他们两人几乎是保证硅bug。它可能是有趣的数有多少个70%车first-silicons tapeout之前有100%的代码和功能覆盖率。根据我的经验,很多。

后100%的覆盖率bug打猎

有几个限制功能覆盖率:

  1. 它不是客观的。不仅只是一样好其定义的验证工程师,但它也很难真正审查和评估其完整性。
  2. 功能覆盖并不意味着正确的分布不同的场景。“计数”属性,但是大多数人忽略它,因为它很难分析和跟进。
  3. 很难定义基于时间的场景,甚至更难发现他们通过观察报道的结果。

通常,我们发送电波设计师建议不同的测试是否真的引向重要场景的一代。

在Vtool,我们有另一层上覆盖的“完成”的定义。我们在两个水平。

首先是视觉分析。通过观察不同属性的测试随着时间的推移,工程师开发直觉对他们的场景是否足够。

下面的例子展示了包FIFO入住率的分布在一个完整的回归。读写I / f独立工作和FIFO的入住率取决于这些速率,以及数据包的大小。

入住率是定义为一个覆盖项目,通过适当的范围,并与其他属性,如交叉数据包的大小。

经过几个月的努力,达到100%代码块和功能覆盖率。然而,可视化与Cogita显示测试结果是这样的:

在这种情况下,工程师可以看到,所有的测试都遵循类似的趋势,一些基本的场景是失踪。例如,让先进先出一个溢出,然后清空它,然后再次溢出。

当他创建的这个场景中,发现一个错误,否则他们就会发现在硅和你走,另一个布满灰尘。

第二个层次是通过使用分类算法。Cogita能够分类测试属性组与失败或成功的场景。这在调试失败场景提供了巨大的帮助。更重要的是,一个分类率,揭示了反例接近100%。

例如,该算法告诉你一些沿着这些思路:

当块被配置为模式1 gbps上方的以太网端口是活跃一段时间窗口大于2,和直接存储器存取访问共享内存,然后在99.85%的情况下,测试失败。这里是两个反例。

你必须问自己,到底有什么伟大的关于这两个反例,测试通过?

在很多情况下,答案是,“没有什么是伟大的。跳棋错过了。”

就目前而言,我们无法计算的错误的设计,免费搭车到工厂。然而,我们可以找到更多的在我们达到100%覆盖和ASIC first-time-right。



留下一个回复


(注意:这个名字会显示公开)

Baidu