调试:日程杀手

调试经常被贴上管理和进度的诅咒的标签。它被认为是不可预测的，通常会发生在接近开发周期的末尾，甚至是之后——导致疯狂的尝试解决方法。这个问题还在加剧。

“从历史上看，大约40%的时间花在调试上，这方面变得越来越复杂，”Vijay Chobisa说西门子EDA．“如今，人们花费更多的时间进行调试。调试有很多挑战。它已经成为一项增加录制时间的任务，甚至有可能导致录制失败。”

这不仅仅关乎工程师。“调试一直是我们客户最关心的问题，”校验组战略项目高级总监Swami Venkat说Synopsys对此．“过去只有工程师关心调试，但现在高管们担心它，因为它会影响项目进度。”

但是专注于调试可能是错误的关注点。“调试本身是一项有用的任务，但如果你过度调试，如果你没有进行有效调试的设施，那么调试本身可能会成为日程杀手，”Synopsys人工智能产品和研究总监斯泰利奥斯·迪亚曼提迪斯(Stelios Diamantidis)说。“从本质上讲，导致你需要过多调试的原因可能是日程杀手。”

因此，真正的问题可能是如何减少或消除花在调试上的时间。Agnisys首席执行官Anupam Bakshi表示:“调试已经成为验证的主要任务，而验证是芯片开发的主要部分。“但是调试是必要的，因为设计和测试平台包含bug，所以减少调试影响的最好方法就是减少bug的数量。”

找到bug
一旦发现问题，就开始调试。公司创始人兼首席执行官西蒙•大卫曼表示:“挑战在于刺激细菌治之软件．核实可能是管理的诅咒，因为你必须在你能负担得起的范围内投入尽可能多的资源。你会一直这样做，直到最后一刻，甚至当你签署了RTL，甚至当硅回来了。这是一个代价函数。漏洞可以是简单的逻辑功能漏洞，也可以是性能问题。”

调试挑战也在不断发展。西门子的乔比萨表示:“现在，客户的大部分验证都是在SoC级别进行的，或者是在SoC进入系统时进行的。块级和IP验证仍然很重要，但有一些工具和技术可以让人们在这个级别上进行验证和调试。这种在SoC级别进行验证的趋势——当你把东西放在一个系统中，你把软件和硬件结合在一起，并为了优化整个系统而对它们进行验证——提出了新的挑战。”

soc级别的验证通常涉及硬件引擎。的测试、测量和仿真市场高级总监Chris Stinson说:“硬件在环功能不断改进，这有助于解决导致长调试周期的周期时间挑战。赛灵思公司．“此外，实时捕获数据进行分析和回放的能力也提高了更快地找到根本原因的能力。芯片内和外部内存带宽的提高在这种先进能力中发挥了关键作用。”

这需要大量的基础设施模拟器或原型解决方案优化调试。Synopsys产品营销高级总监Johannes Stahl表示:“客户希望最大限度地利用硬件资源，以达到调试波形的目的。”“如果我在找到一个问题之前运行了数十亿个向量，你不会想要回到模拟的最开始并重新运行它。您需要有一个系统级调试方法，在这个方法中，您一直保存模拟的状态，保存输入的状态。然后，如果你必须回到之前的时刻，你可以很快做到这一点。”

图1显示了模拟器供应商部署的解决方案。

图1:使用检查点/恢复来关注调试挑战。来源:西门子EDA

硬件执行的另一个问题是可重复性。“在街区层面，测试的长椅都是决定性的，”乔比萨说。“当你连接物理硬件以使系统具有确定性时，还存在额外的挑战。当您正在运行基准测试或软件应用程序时，您看到了一个问题，如果您再次运行测试而问题消失了，这是不可接受的。当您第一次运行时，我们创建一个数据库，在其中捕获边界上发生的所有活动，这是基于时钟周期的。第一次运行后，物理接口不再连接。刺激来自于回放数据库。现在你就可以重现一个一个循环的过程了。你也可以把这个回放数据库发送给其他球队，因为你不需要物理设置。”

这些问题也可以在较小的范围内存在。Imperas的Davidmann说:“在验证过程中，很多事情是同步的，很多事情是顺序可预测的。“还有一些事情更复杂。这是我们所看到的最大挑战之一RISC-V处理器验证必须与异步事件有关——在不可预测的时间内发生的事情，可能以另一种方式发生。”

包括软件在内的调试的一个问题是运行时间可能很长。“在可能的情况下，我们希望进行短时间的测试，”公司首席执行官舒布霍迪普•罗伊•乔杜里表示Valtrix系统．“这在验证和调试过程的早期尤其重要，但需要扩展到更长的测试，其中可能包括在设计的后期阶段集成外围驱动程序。”

测试台上的bug
每个逃到产品中或超出开发流中定义的检查点的错误，都是测试台中定义的错误。验证未能显示该错误的存在，许多公司制定了策略来分析这些错误逃逸，并确定他们应该如何检测它们，以便将来不会出现类似的错误。

但是就像设计错误一样，测试平台本身也可能包含错误。参考模型可以包含bug，覆盖也可以包含bug。对这些测试台中错误的跟踪很少，因此每个验证工程师都只能依靠自己的经验。

有很多地方可以藏虫子。大卫曼说:“这可能是一个设计问题，也可能是他们没有指定这是需要检查的东西，也可能是他们确实指定了，但实际上测试平台有一个错误，或者覆盖率报告了一些错误。”“这是测试台中的一个bug，还是一个缺失的功能?如果一个错误逃脱了，这意味着你在发现错误方面做得不够好，这与刺激、测试平台或它的测量有关。这是核查方案的错。”

当检入更改并运行回归时，第一步是错误分类。Synopsys的Venkat说:“如果一个客户运行一个回归，其中500个记录了一个失败，你真的不知道是设计错误还是测试台错误。”“我们采用失败的案例，使用AI/ML读取错误的签名，并将其丢弃。对于这些较小数量的箱子，我们现在应用额外的AI/ML技术来查找根本原因，并确定这是与dut相关的错误还是测试台架问题。如果这是一个与测试平台相关的错误，那么我们会给他们更多的线索和更多的指针，让他们知道错误在测试平台中的确切位置。测试台中可能存在很多不同的缺陷。例如，你可能在UVM类对象中有bug，这些对象可能是一些动态对象，在这些动态对象中找到bug可能很困难。”

避免错误
到目前为止，驯服调试的最好方法是避免它。Synopsys的Diamantidis说道:“你必须确保尽可能少地进行调试。“事实上，如果你能调试零，你就非常成功了。现实情况是，这通常是不可能的。我会从什么是优化开始思考过程，你如何跟踪从A到B的初始操作，这样你就可以尽可能接近B，你必须依赖最后的调试。当你真的依赖于调试时，你需要拥有成功解决问题所需的所有信息，然后完成你的旅程。”

其他人也同意。Synopsys的市场总监Shekhar Kapoor说:“如果调试是一种癌症，那么预防性护理就是另一种选择。”“你如何消除所有的调试，并确保你可以在设计中实际实施技术，在设计中有更多的可预测性，并从这个角度进行调整?数据是调试的命脉，如果您能够识别出一些模式和机会，从而提供更好的见解，并将它们更早地引入到您的设计中，那么您就可以防止这些问题。在这个领域有一个新的解决方案的机会。现在已经有很多脚本编写了，但可能会有更智能的帮助。”

对于设计的某些方面，可以有效地消除bug。Agnisys的巴克希说:“漏洞的主要来源之一是不同的团队对芯片规格的解释不同，或者在规格版本上不同步。”“规格驱动的IP和芯片开发可以消除漏洞，并保持团队的同步。对于芯片的某些部分，硬件RTL设计、测试台组件、验证序列和用户文档，可以根据规格自动生成。规范驱动的开发是一种根据构造纠正的方法，它可以防止许多错误，从而减少调试时间。”

在其他领域，比如时钟域或重置跨域，已创建专用解决方案。Venkat说:“客户已经采用了静态验证等技术，这样你可以更容易地找到一类错误。“婷婷一直在那里，而且变得更聪明了。在AI和ML的影响下，它变得更有能力。时钟域或重置交叉问题现在可以更早地发现，而不必运行大量向量，并试图通过无数个周期进行调试。”

在插入点附近找到bug会有所帮助。AMIQ EDA首席执行官Cristian Amitroaie表示:“通过在过程的早期发现和修复错误，可以减少芯片开发中的调试时间，最好是在设计和验证工程师输入代码的时候。”“集成开发环境(IDE)可以‘动态地’检测各种错误，并将这些错误的调试时间减少到零，因为用户可以立即修复这些错误。在许多情况下，IDE还通过建议可能的修复和自动完成选项来消除解决错误的工作。”

一切都从计划开始。”验证计划是提高可预测性的一个重要因素。”OneSpin解决方案．“作为计划的一部分，验证应该在设计过程的早期进行，以最大限度地提高反馈并简化调试过程。通过提供单一界面来查看和分析来自多个验证源(如模拟和正式验证源)的数据的工具，可以进一步简化对覆盖工作的反馈和理解。”

包括软件
如今，越来越多的功能是由软件定义的，虽然理论上硬件需要能够运行任何任意的软件，但将生产软件引入图中可以帮助获得更重要的系统功能领域。

“执行系统级模拟的能力对于识别具有挑战性的软件和硬件交互问题至关重要，”Xilinx的Stinson说。“随着设计复杂性的不断增加，模拟所需循环次数的能力变得更具挑战性。这就是fpga在系统级验证中发挥越来越重要作用的地方。在硬件中建模系统的能力允许设计团队每天执行更多的调试周期，以及根据需要动态探测设计中的不同信号。此外，由于软件和硬件模型能够相互交互，设计师可以减少初始系统启动和验证时间。”

但是模拟和原型确实依赖于RTL是可用的。大卫曼说:“我们提供了模拟或虚拟平台，这样软件人员就有办法在芯片和RTL可用之前测试软件。”“这使得在硬件原型、fpga或从上一代设计中拼凑出来的东西上引入软件变得容易得多。”

Synopsys的斯塔尔同意这种做法。“如果你看看系统集成，接近于带出，重点是在芯片上运行软件。避免在测试台中出现错误的最好方法是预先调试软件，在那个时候，测试台中主要是软件。对于一些客户来说，答案是在一个环境中开发软件虚拟样机．这样他们就可以在尝试把它放到一个包含所有RTL的模拟器上之前，基本做到正确。”

不过，这并没有使硬件/软件调试变得容易。“软件调试任务是软件开发人员的任务，而硬件调试是硬件验证工程师的任务，这两者是不一致的，”Stahl补充道。“它们都需要专业知识。你需要了解硬件，或者你需要了解软件堆栈。这两个群体永远无法理解他们各自世界的完整。当它们结合在一起时，当您想要找到性能错误时，除了查看联合数据没有其他方法了。但是该数据应该处于比Verilog行项或软件行项更高的级别。它需要在更高的抽象上，可能是在协议级别，或者协议中的某个事务。这些都是软件人员和硬件人员可以一起查看并弄清楚发生了什么事情的地方。”

数据抽象已经成为调试中非常必要的一部分。“我们有标准协议的协议分析器，可以收集信息并向你显示交易级别，”乔比萨说。“您可以在PHY级别、事务级别或应用程序级别查看它。”

新的调试问题
通过转移到系统级别，在基本功能之外出现了新的调试挑战。前面已经提到了性能，而电源很快就成为需要注意调试的一个领域。

“模拟器已经发展成为功率/性能分析的核心，”乔比萨说。“当你的RTL刚刚准备好时，你必须尽早开始。您希望运行软件应用程序、工作负载或基准测试，并查看电源配置文件。您不必担心毫瓦或微瓦，但您希望在运行引导和执行固件时看到功率配置文件。当我运行“愤怒的小鸟”或“曼哈顿”应用程序时，我的能力是什么样子的?通过在设计验证周期的早期查看功率配置，你可以采取一些措施。”

新的领域正在出现，比如易受入侵的脆弱性。大卫曼说:“一家公司建模了他们的嵌入式系统，然后攻击它。“他们可以观察软件如何反应。他们通过出错来有效地进行突变测试，看看软件是否能意识到发生了什么并阻止它。”

新架构带来了一些挑战。迪亚曼提迪斯说:“回顾过去30年的半导体工程，我们已经有了一套相当固定的软件，它们来自为编译器/驱动程序堆栈构建的应用程序，映射到非常特定的架构，主要是数据中心的x86和移动设备的RISC。”“随着我们利用摩尔定律，这些芯片从一代硅芯片到一代硅芯片，使它们更快、更小、更节能。这在设计过程中设置了许多控制点。在过去的三年里，随着人工智能的出现，硅变得非常特定和个性化。在这种情况下，对功能、体系结构和几何结构的新需求就会出现。现在您必须同时满足不同阶段的条件。它带来了创造更全球化的解决方案的机会，而不是只关注阶段。”

AI/ML的影响
虽然AI/ML可能会带来新的调试挑战，但它也即将带来一些显著的生产力提高。“机器学习将告诉我们哪里犯了错误，哪里可以改进，”大卫曼说。“验证就是要把事情做得更好，或者少一些错误。当我们发现bug时，它应该能够推断出漏洞存在的原因。它可能不会告诉你如何修复它。它更像是在说，‘这是你的弱点所在，这也是你需要专注的地方。’”

其中很多仍处于早期阶段。Venkat说:“人工智能和机器学习技术可以应用在许多不同的领域，我们从一些已经与该技术的早期采用者进行的接触中看到了非常令人鼓舞的结果。”“通常情况下，需要一个星期的体力劳动现在可以在几个小时内完成。人工智能和机器学习领域已经有了重大创新。如果调试是诅咒，那么这很可能是治愈方法。”

其他人也认为ML是一个重要的工具。“机器学习在这些新的验证环境中有一席之地，自动对数据进行分类，使工程师能够做出快速准确的决策，缩短甚至消除调试周期，”Hagai Arbel说Vtool．“一种将机器学习与高级可视化结合起来的方法，以及一种全面的调试方法，已被证明可以大大缩短调试周期。实现下一代调试的关键是将这些技术以有效和紧密的方式结合起来。”

调试解决方案可能与过去不同。迪亚曼提迪斯说:“每个设计师都把信息藏得更紧。“很难创建适合任意设计问题的全球模型。这既是一个诅咒，意味着它会让那些想要设计全面解决方案的开发人员感到沮丧，但也有一线希望。如果你能够为特定的设计风格提供有针对性的解决方案，你通常不需要那么多的数据，你的模型也不会那么复杂。我们习惯于尝试建立通用的解决方案，即一刀切。”

结论
调试并没有消失，而是在不断地发展。“情况只会越来越糟，”斯塔尔说。“我们正在非常努力地寻找解决这个问题的新办法。以传统的方式推动我们的引擎和调试工具并不能让我们达到目标。我们需要做得更多。”