家»系统设计»跟踪问题以确保您不必调试两次

跟踪问题以确保您不必调试两次

文章：Ronak Dham和Sourabh Goyal

以下是一种跟踪工程师通常面临的问题的技术，以确保他们不必调试两次相同的问题。

你多久有一个笨拙的vu？就像你之前已经看到过了已经调试的问题一样，当你不能在挖掘到几个小时后挖掘时，最终会调试相同的问题，从而再次重新投资相同的时间。

以下是一些事实要考虑：

修复错误比写入代码长30倍。
75％的开发人员的时间花在调试中;这一年为1,500小时。

已知的问题和解决方案或“kias”是作者作为一个简短的笔记本形式创建的术语，该笔记本包括所有面临的问题，从项目中的所有问题到像GVIM这样的编辑器到Linux和Windows相关的操作系统问题。

随着时间的推移，笔记本成为一个单词文件并移动到云端。然后，越来越困难让系统中的其他人涉及，因为没有人真的觉得记录了这些东西。去寻找这个预先注册的页面/文档中的问题的额外步骤太麻烦了，因此人们放弃了这个想法。

即使人们现在正在记录有关问题的信息，然后，一旦在调试周期中发现一个问题，就没有人在寻找问题，渲染无用的所有记录信息，就没有人发现。所以，我们提出了一个可执行的kias的想法。

但是，在我们深入了解之前，主要动机是什么？这是一个修辞问题。我们真的想增加更多的时间在我们已经花在调试问题上吗？因此，解决方案旨在删除两个依赖性：

通过消除第一次调试问题的人的依赖来依赖“谁”。
通过消除对自我记忆的依赖项来记住一个问题的依赖性，“何时”和“如何”。

解决方案旨在为先前面对开发人员面临的错误添加两个方面：

向用户提供根本原因分析（RCA）信息。
为用户提供可能的解决方案列表。

在这里，值得一提的是Jira和其他错误跟踪工具有局限性。这些工具并未主动告诉用户此问题之前出现了此问题，并且可能无法忘记以常见问题的常见问题。

执行kias.

以下是如何实现可执行kias的想法：

通过在yaml文件中记录Kias信息 - 几乎可以是任何格式，包括XML，JSON，TXT - 以及用于解析预注册错误的脚本，并将信息追加到编译/模拟日志文件中所示的错误。
通过使用System Verilog回调拦截UVM_ERROR / UVM_FATAL消息，并在将其打印到日志之前分析和追加信息。

现在让我们探索两个选项。

使用System Verilog回调

对于只希望记录KIAS进行运行时问题和UVM错误的用户，这是一个理想的解决方案。它使用UVM_Report_Catcher类中的Catch并投掷机制。这就像在我们想要在某些测试中缩短某些错误时，在实现某些错误时实现异常处理。

但是，在这种情况下，我们在做什么通过将Kias信息附加到错误字符串本身来修改错误消息，从而自动化所讨论的错误/问题的过去记录调试信息的打印。

UVM_Report_Catcher用于捕获UVM报告服务器发出的消息。捕集器是UVM_CALLBACKS＃（UVM_REPORT_OBJECT，UVM_REPORT_CATCHER）对象，因此UVM_CALLBACK和UVM_CALLBACKS＃（T，CB）类中的所有设施都可用于注册捕集器和控制捕集状态。

UVM_Callbacks＃（UVM_Report_Object，UVM_Report_Catcher）类是别名的UVM_REPORT_CB，以使其更易于使用。可以使用Report对象注册多个报告捕集器。该捕集器可以注册为默认捕集器，该捕集器捕获所有UVM_REPORT_OBJECT报告者的所有报告，或者可以附加到特定的报告对象（即组件）。

UVM_Report_Catcher的用户扩展必须实现Catch方法，其中指定了捕获报告的捕获操作。Catch方法可以捕获，在这种情况下，报告的进一步处理立即停止，或者返回投掷（可能修改）报告传递给其他注册捕集器。捕集器按照注册的顺序处理。

在捕获报告时，Catch方法可以在报表服务器最终发出报告之前修改严重性，ID，操作，冗长或报告字符串。在这种情况下，我们打算更改报告字符串。

图1一些我们已定义的宏，以帮助我们提供基于字符串的消息，我们想在记录错误时看。