你可能还记得VennsaOnPoint工具获取验证结果，帮助识别错误和可能的原因。该工具早期的重点是识别可疑问题并让您从那里开始工作。

去年DAC期间，我们注意到他们进一步提出了可能的修复方案(但你必须确认它们是否真的是修复方案)，并更好地进行分类，将可能有共同原因的东西聚集在一起。

但这都反映了调试的典型反向跟踪:找到问题并回溯到可能的原因。这与前向调试相反，在最糟糕的情况下，前向调试包括猜测要进行更改的位置，并向前跟踪更改以查看它们是否修复了问题。从这些方面来看，向前迈进听起来更像是一种绝望之举。

今年，他们改进了他们的“因果引擎”，您可以从建议的修复程序开始，并看到从每个建议的修复程序到现在更正的问题点的逻辑链，从而证明修复程序是有效的。您可以继续工作，除了修复的具体位置和修复它们的值现在是由OnPoint提供的，而不是通过愿望和祈祷。

需要注意的是，提议的“修复”并不是电路修复;它们只是将删除违规行为的逻辑值(在状态机等情况下是时间)。你仍然需要想出一个电路变化来实现修复，然后模拟它，以确保你没有在其他地方给自己制造问题。

这样做的好处之一是，验证人员现在可以为设计人员节省大量的调试时间。在此之前，设计师可能会说:“有个问题;这就是失败的测试。”现在，这些信息可以加上，“这里有一系列的解决方案，你可以从中选择。”使互动更加友好。

你可以在他们的释放．

• 
• 
• 
• 
•