工程师可以从急诊室医生那里学到什么。
前段时间，我和朋友一起去急诊室，他的脸上突然有一种麻木的感觉。他觉得还好(其他一切对他来说都很好)，但小心谨慎总比后悔强。
当医生给他做检查时，我注意到，在追踪问题本身之前，她问了一些问题，以排除她已经熟悉的问题，这些问题可能以类似的方式表现出来。只有在“好吧，不是那么好”之后，她才从各个方面来总结出可能的问题。
我为什么要告诉你这些?因为这位医生的诊断和我们日常的病毒搜寻之间没有根本的区别。也许我们能从她身上学到些什么。
在我上一篇博文，我讨论了漫长而乏味的验证收敛阶段。每个复杂的SoC领导者都知道将验证工作集中到项目结束的过程是多么漫长和痛苦，以及达到足够低的停产风险是多么困难。
术语“调试”指的是“消除错误”，即执行根本原因分析，找出问题，并修复它。
然而，如果我们从一个失败的测试或回归到一个通过的测试来看验证工程师的过程，调试只是工作的一部分。很多时候，从失败追溯到根本原因并不是有效的，至少在我们之前不是理解场景．人类以“故事”的方式思考，正因为如此，当遇到一个失败的测试时，首先要做的就是询问这个测试在做什么。当行业从定向测试转向随机验证时，这个问题加剧了，并且在某种程度上被忽视了。当查看全芯片故障时，这个问题可能会更严重，其中执行许多不同的测试工作台、子例程和并行线程来创建随机而复杂的场景。我们称之为理解故事的过程诊断．
有趣的是，很少有人教授正确的调试技术。有很多UVM和正式的验证课程，但是当测试失败时该怎么办?似乎在这个广阔的领域，我们让工程师们在没有指导方针和方法的情况下独自战斗。
在Vtool，我们使用Cogita，我们的诊断和调试平台，教工程师如何执行系统和结构化的分析过程。
第一步总是回答这个问题:“发生了什么事?”在运行随机测试时，通常并不清楚测试执行了什么或试图执行什么。这一步，如果操作得当，使用合适的工具，可以节省数小时的追鬼时间。当这个问题得不到回答时，除了浪费验证工程师的时间外，很多时候也浪费了RTL设计人员的时间。这是因为所谓的RTL漏洞并没有从问题场景的角度进行解释。
为了正确地执行这一步，必须有一个控制面板或诊断工具，它们将用几个简单的图像来说明整个过程。文本形式是做不到的。它会太长太复杂。
只有在回答了“发生了什么”问题之后，才能执行一步一步的调试。在这方面，人们也必须得到帮助，提出正确的问题(或提出有用的假设)，并快速有效地得到答案。因为调试是一项孤独的工作，很多时候，仅仅因为对这些调试步骤没有控制和指导，过程就会出现分歧。在这里，Cogita也可以作为一个指导平台，帮助提高验证工程技能。
急诊室的医生因为学会了一种方法而执行了一个有效的过程。我们核查工程师应该开发这样的方法，并在核查界推广。
|
|
|
|
|
|
|
|
留下回复