当最后10%是最困难的部分时，你如何衡量一个项目的完成程度?
贝尔格莱德市正在整修我居住的街道。他们还在我旁边建了一栋新大楼，这样我就可以从阳台上看到建筑工作。
上周，他们封锁了街道大约20分钟，人们从车里出来，在外面等待道路开放。建筑工人并不着急，似乎每个人都能接受，所以我花了几分钟和他们聊了聊。一个人说他们从一月份开始工作，现在已经完成了90%。考虑到我自己项目的“几乎完成”状态，我问他什么时候能完成，他说，好吧，我们已经完成了90%，我们9个月前就开始了。我们将在一个月内完成。
图1:我的街道正在建设中。
覆盖驱动的验证是我们所拥有的关于如何运行验证项目的最好的不完美的想法。
想法很简单:
这就像资本主义:我可以用十页纸来解释为什么它是不对的，但我坚持下去，因为我没有更好的想法。然而。
如果我们在一个典型的项目中检查功能覆盖的收敛，假设它是在项目的早期编写的，我们将看到类似下图的东西。
图2:项目期间的功能覆盖进度。
如果你问验证工程师在第15周的状态如何，你很可能会听到:“我快完成了。”特别是当项目计划持续17周的时候。
在某种意义上，验证工程师是正确的:测试平台是稳定的，大量的测试正在运行，失败很少，发现新的RTL错误的几率很低。
但就时间而言，该项目只完成了60%左右，尽管没有人能预测到这一点。
在覆盖率从90%到100%的这段时间里，我们花费了大量的验证时间，而且，这是每个人都讨厌的时间。最重要的是，在这一点上，距离终点线剩下的时间是非常不可预测的。
行业调查显示，30-50%的验证工作用于调试。仔细一看就会发现，其中80-90%都流向了低效的调试。低效的调试是循环过程I在我的第一篇博客中详细讨论过验证工程师在一个失败的测试周围转来转去，最后发现他们误解了这个场景的故事。随着项目的进展，测试失败或我们试图填补的覆盖漏洞，这种情况会越来越多。
这种调试的效率也很低，因为它没有揭示RTL错误，也没有教会我们任何东西。在IP验证周期的四分之三阶段(例如，上图中的第18周)，人们会期望验证工程师已经是她/他的测试平台的专家，能够快速发现测试问题。
这将我们引向第二个大问题:没有有效的方法来确定对测试工作台的理解。类似的问题被一次又一次地调试。人们往往会忘记。
在Vtool，我们建议将验证范式从调试失败和缺失覆盖转变为诊断。我们首先想要理解故事，当我们看到一个失败的测试时，我们可以首先问:“刚才到底发生了什么?”这就像你看了一场精彩的足球比赛，却无法理解发生了什么，因为它太快了，你的大脑无法捕捉。然后慢镜头回放，你就明白了。我们的主要目标是为工程师提供这种“慢动作”工具。
我们的模拟诊断和调试平台Cogita正是针对这一点。
图3:使验证收敛曲线变直。
如果使用得当，它是在初始调试阶段为任务设置的，而用例仍然相对容易。然后，当最后10%的覆盖填充到来时，它就会真正发挥作用，帮助工程师矫正“几乎完成”的曲线。
|
|
|
|
|
|
|
|
留下回复