调试所花费的时间是不可预测的。它占用了开发周期的很大一部分时间，可能会打乱计划，但良好的做法可以将其最小化。
Debug 调试经常被称为管理和计划的祸害。它被认为是不可预测的，并且经常发生在开发周期接近尾声时，甚至在开发周期结束后——导致人们疯狂地尝试解决方法。但是，这个问题还在不断加剧。
“从历史上看，大约 40% 的时间都花在调试上，而且这方面变得越来越复杂，”西门子 EDA 产品管理总监 Vijay Chobisa 说。“今天，人们花在调试上的时间更多了。调试有很多挑战。它已经成为一项可以增加流片时间甚至危及流片的任务。”
这不仅仅关乎工程师。“调试一直是我们客户最关心的问题，”Synopsys 验证组战略项目高级总监 Swami Venkat 说。 “以前只有工程师关心调试，但现在高管们也对此感到担忧，因为它会影响项目进度。”
但专注于调试可能是一个错误的重点。“调试本身是一项有用的任务，但如果你调试过度，并且没有进行有效调试的设施，那么调试本身就可能成为进度杀手，”Synopsys 的 AI 产品和研究总监 Stelios Diamantidis 说。“从本质上讲，导致你需要过度调试的原因可能是进度杀手。”
所以真正的问题可能是如何减少或消除调试所花费的时间。“调试已成为验证中的主导任务，而验证是芯片开发的主要部分，”Agnisys 的首席执行官 Anupam Bakshi 说。“但调试只是因为设计和测试台包含错误才有必要，因此减少调试影响的最佳方法是减少错误的数量。”
图 2: 尽早的开始调试来节省研发成本
查找错误
一旦发现问题，就开始调试。 “挑战在于尽量发现错误，” MachineWare CTP Jan 说道。“验证可能是管理的祸根，因为你必须投入尽可能多的资源。你一直这样做，直到最后一刻，即使你正在签署 RTL，即使硅片回来了。这是一个成本函数。错误可能是简单的逻辑功能错误，也可能是性能问题。”
调试挑战也在不断发展。“客户现在在 SoC 级别或 SoC 放入系统时进行大部分验证，”西门子的 Chobisa 说道。“ Block 级和 IP 验证仍然很重要，但有一些工具和技术可以让人们轻松地在该级别进行验证和调试。这种在 SoC 级别进行验证的趋势——当你将东西放入系统中时，你将软件与硬件结合在一起并验证它们以优化整个系统——带来了新的挑战。”
SoC 级验证通常涉及硬件引擎。 Xilinx 测试、测量和仿真市场高级总监 Chris Stinson 表示：“硬件在环功能不断改进，这有助于解决导致调试周期过长的周期时间挑战。此外，实时捕获数据进行分析并在稍后重放的能力也有助于更快地找到根本原因。改进的片上和外部内存带宽在这一高级功能中发挥了关键作用。”
需要大量围绕仿真器或原型解决方案的基础设施来优化调试。Synopsys 产品营销高级总监 Johannes Stahl 表示：“客户希望最大限度地提高硬件资源的使用效率，以达到可以调试波形的程度。如果我在发现问题之前运行了数十亿个向量，你就不会想回到仿真的开头并重新运行它。您需要拥有一个系统级调试方法，始终保存模拟状态和输入状态。这样，如果您需要返回到之前某个时刻，您可以非常快速地完成。”
图 3：使用检查点/恢复来专注于调试挑战。
硬件执行的另一个问题是可重复性。“在块级别，测试台是确定性的，”Chobisa 说。“当您连接物理硬件以使系统具有确定性时，还会面临其他挑战。当您运行基准测试或软件应用程序时，您发现问题，如果您再次运行测试并且问题消失，这是不可接受的。当您第一次运行时，我们会创建一个数据库，我们将在其中捕获边界上发生的所有活动，该活动基于时钟周期。第一次运行后，物理接口不再连接。刺激来自这个重放数据库。现在您将能够重现逐个周期的行为。您还可以将此重放数据库发送给其他团队，因为您不需要物理设置。”
这些问题也可以存在于较小的规模上。“在验证中，很多事情是同步的，很多事情是顺序可预测的，” MachineWare 的 Jan 说。 “还有一些事情更加复杂。我们在 RISC-V 处理器验证中看到的最大挑战之一与异步事件有关——这些事情发生在不可预测的时间，并且可能以不同的方式发生。”
包括软件在内的调试的一个问题是运行时间可能非常长。“如果可能，我们希望测试时间短，”Valtrix Systems 首席执行官 Shubhodeep Roy Choudhury 说。“这在验证和调试过程的早期尤为重要，但它需要扩展到更长的测试，其中可能包括在设计后期阶段集成外围设备驱动程序。”
测试台中的错误
每个逃逸到产品中或超出开发流程中定义的检查点的错误，根据定义都是测试台中的错误。验证未能显示该错误的存在，许多公司制定了政策来分析这些错误逃逸并确定他们应该如何检测它们，以便将来不会出现类似的错误。
但就像设计错误一样，测试台本身也可能包含错误。参考模型可能包含错误，覆盖范围也可能包含错误。这些测试台错误很少被跟踪，因此每个验证工程师都只能依靠自己的经验。
错误可能隐藏在许多地方。“这可能是一个设计问题，可能是他们没有指定这是需要检查的东西，可能是他们指定了但实际上测试台有错误，或者覆盖范围报告了错误，” Jan 说。“这是测试台中的错误还是缺少功能？如果错误逃逸，则意味着您在查找错误方面做得不够好，这与刺激或测试台或对它的测量有关。这是验证解决方案的错误。”
当更改被签入并运行回归时，第一步是错误分类。“如果客户运行回归，其中 500 个记录失败，您真的不知道是否存在设计错误或测试台错误，”Synopsys 的 Venkat 说。 “我们选取失败的案例，使用 AI/ML 读取错误的特征，然后将它们分类。在这些数量较少的分类中，我们现在将额外的 AI/ML 技术应用于根本原因，并确定这是与 DUT 相关的错误还是测试台问题。如果是与测试台相关的错误，那么我们会为他们提供更多线索和更多指示，以准确指出测试台中的错误可能在哪里。测试台中的错误可能出现在许多不同的领域。例如，UVM 类对象中可能存在错误，这些对象可能是一些动态对象，而在这些动态对象中找到错误可能很困难。”
避免错误
到目前为止，驯服调试的最佳方法就是避免它。“你必须确保尽可能少地进行调试，”Synopsys 的 Diamantidis 说。“事实上，如果你可以实现零调试，那么你就非常成功了。现实情况是，这通常是不可能的。我会从优化是什么开始思考，你如何跟踪从 A 到 B 的初始操作，以便尽可能接近 B，最后必须依赖调试。当你依赖调试时，请掌握成功解决问题所需的所有信息，然后完成你的旅程。”
其他人也同意。“如果调试是一种癌症，那么预防性护理就是另一种选择，”Synopsys 营销总监 Shekhar Kapoor 说。“你如何消除所有调试并确保你可以在设计中实际实施技术，使设计更具可预测性，并从这个角度进行调整？数据是调试的命脉，如果你能识别出一些模式和机会，从而提供更好的见解，并尽早将其融入设计中，那么你就可以避免这些问题。在这个领域，有新的解决方案的机会。如今，很多脚本已经完成，但可能会有更多智能辅助功能，可能会有所帮助。”
对于设计的某些方面，可以有效地消除错误。“错误的主要来源之一是不同的团队对芯片规范的解释不同，或者规范版本不同步，” Jade DA 的 Tamaz说。“规范驱动的 IP 和芯片开发可以消除错误并使团队保持同步。对于芯片的某些部分，硬件 RTL 设计、测试台组件、验证序列和用户文档可以从规范中自动生成。规范驱动的开发是一种正确的构造方法，可以防止许多错误，从而减少调试时间。”
在其他领域，例如时钟域或重置域交叉，已经创建了专用解决方案。 “客户已经采用了静态验证等技术，这样可以更轻松地找到一类错误，”Venkat 说。“Linting 一直存在，而且变得更加智能。在 AI 和 ML 的影响下，它变得更加强大。现在可以更早地发现时钟域或重置交叉问题，而不必运行大量向量并尝试通过无数个周期进行调试。”
找到接近插入点的错误会有所帮助。“通过在流程的早期发现和修复错误可以减少芯片开发中的调试时间，理想情况下是在设计和验证工程师输入代码时，”AMIQ EDA 首席执行官 Cristian Amitroaie 说。“集成开发环境 (IDE) 可以‘即时’检测各种错误，并将这些错误的调试时间缩短为零，因为用户可以立即修复它们。在许多情况下，IDE 还通过建议可能的修复和自动完成选项来消除解决错误的努力。”
一切都从规划开始。 OneSpin Solutions 营销主管 Rob van Blommestein 表示：“验证规划是提高可预测性的重要因素。作为计划的一部分，验证应在设计过程的早期进行，以最大限度地获取反馈并简化调试过程。通过提供单一界面的工具可以进一步简化对覆盖率工作的反馈和理解，这些工具可用于查看和分析来自多个验证源（如模拟和形式验证）的数据。”
包括软件
如今，越来越多的功能是由软件定义的，虽然硬件理论上需要能够运行任意软件，但将生产软件纳入其中可以帮助了解系统功能中更重要的领域。
“执行系统级仿真的能力对于识别具有挑战性的软件和硬件交互问题至关重要，”Xilinx 的 Stinson 说。“随着设计复杂性不断增加，模拟所需周期数的能力变得更具挑战性。这就是 FPGA 在系统级验证中发挥越来越重要作用的地方。在硬件中建模系统的能力使设计团队每天可以执行更多的调试周期，并根据需要动态探测设计中的不同信号。此外，由于软件和硬件模型能够相互交互，设计人员可以减少其初始系统启动和验证时间。”
但仿真和原型设计确实依赖于 RTL 的可用性。“我们提供模拟或虚拟平台，因此软件人员可以在硅片、RTL 可用之前就对软件进行测试，”MachineWare Jan 说。 “这使得将软件引入硬件原型、FPGA 或上一代设计中的东西变得容易得多。”
Synopsys 的 Stahl 同意这种方法。“如果你看一下系统集成，接近流片的重点是在芯片上运行软件。避免测试台出错的最佳方法是预先调试软件，此时测试台主要是软件。对于一些客户来说，答案是在虚拟原型中开发他们的软件。然后他们可以在尝试将其放在带有所有 RTL 的模拟器上之前让其基本正确。”
尽管如此，这并不会使硬件/软件调试变得容易。“软件调试任务是软件开发人员的任务，硬件调试是硬件验证工程师的任务，这些任务并不融合，”Stahl 补充道。“它们都需要专业知识。你需要了解硬件，或者你需要了解软件堆栈。这两组人永远不会理解各自世界的完整性。当它们结合在一起时，如果你想要找到性能错误，除了查看联合数据之外别无他法。但这些数据应该比 Verilog 行项目或软件行项目处于更高的级别。它需要处于更高的抽象层，可能是在协议层，或者是协议中的事务之一。软件人员和硬件人员可以一起查看并弄清楚发生了什么。”
数据抽象已成为调试中非常必要的部分。“我们有用于标准协议的协议分析器，可以收集信息并向您显示事务级别，”Chobisa 说。“您可以在 PHY 级别、事务级别或应用程序级别查看它。”
新的调试问题
通过转向系统级，新的调试挑战正在超越基本功能。性能已经提到过，而功耗正迅速成为可能需要调试关注的一个领域。
“模拟器已经发展成为功耗/性能分析的核心，”Chobisa 说。“你必须在 RTL 尚未准备好时就开始。你想运行软件应用程序、工作负载或基准测试，并查看功耗分布。你不必担心毫瓦或微瓦，但你想在启动时、执行固件时查看功耗分布。当我运行愤怒的小鸟或曼哈顿应用程序时，我的功耗是多少？通过在设计验证周期的早期查看此功耗分布，你可以对此采取一些措施。”
新的领域正在出现，例如易受入侵攻击。“一家公司对其嵌入式系统进行了建模，然后对其进行了攻击，” Jan 说。“他们可以观察软件如何响应。他们通过制造错误并查看软件是否能够意识到正在发生的事情并阻止它，有效地进行了变异测试。”
一些挑战源于新的架构。“如果你回顾过去 30 年的半导体工程，你会发现我们已经拥有一套相当固定的软件，这些软件来自为编译器/驱动程序堆栈构建的应用程序，这些应用程序映射到非常具体的架构，数据中心的 x86 和移动设备的 RISC 占主导地位，”Diamantidis 说。“随着我们利用摩尔定律，这些软件从一代硅片发展到另一代硅片，使它们更快、更小、更节能。这在设计过程中设置了很多很好的控制点。在过去三年中，随着人工智能的出现，硅片变得非常特定于领域和个性化。随着这种情况的发生，对功能、架构和几何形状的新要求也随之出现。你现在必须同时满足不同阶段的条件。这为创建更全球化的解决方案提供了机会，而不是专注于某个阶段。”
人工智能/机器学习的影响
虽然人工智能/机器学习可能带来新的调试挑战，但它也即将带来一些显著的生产力提升。 “机器学习将告诉我们哪里犯了错误，哪里可以改进，”Davidmann 说。“验证就是要做得更好，或者减少错误。当我们发现一个错误时，它应该能够推断出漏洞存在的原因。它可能不会告诉你如何修复它。它更有可能说，‘这就是你的弱点所在，这就是你需要关注的地方。’”
很多都还处于早期阶段。“人工智能和机器学习技术可以应用于许多不同的领域，我们看到一些早期采用该技术的人已经参与其中，取得了非常令人鼓舞的结果，”Venkat 说。“通常，需要一周的人工工作现在可以在几个小时内完成。人工智能和机器学习已经有了重大创新。如果调试是祸根，那么这很可能就是解药。”
其他人也认为机器学习是一个重要的工具。 “机器学习在这些新的验证环境中占有一席之地，它自动对数据进行分类，使工程师能够做出快速准确的决策，缩短甚至消除调试周期，”Vtool 首席执行官 Hagai Arbel 表示。“将机器学习与高级可视化和全包式调试方法相结合的方法已被证明可以大大缩短调试周期。实现下一代调试的关键是将这些技术以有效且有凝聚力的方式结合起来。”
调试解决方案可能与过去不同。“每个设计师都对信息保密，”Diamantidis 说。“很难创建适合任意设计问题的全局模型。这既是一种诅咒，意味着它让想要设计全面解决方案的开发人员感到沮丧，但也有好的一面。如果你能够为某些设计风格提供有针对性的解决方案，你通常不需要那么多数据，你的模型也不会那么复杂。我们习惯于尝试构建通用解决方案，一刀切。”
结论
调试不会消失，但它在不断发展。“情况只会越来越糟，”斯塔尔说。“我们正在努力寻找解决问题的新方法。以传统方式推动我们的引擎和调试工具不会让我们达到目的。我们需要做更多。”
