多核调试发展到系统级

多核体系结构的扩散和扩展使得调试变得更加困难和耗时，这反过来增加了对更全面的系统级工具和方法的需求。

多核/多处理器设计是调试最复杂的设备。核心之间更多的交互和相互依赖意味着更多的事情可能会出错。事实上，可能出现的问题太多了，以至于工程团队经常不知道从哪里开始。与单核相比，多核设计包含更多的执行流，可以同时调试。此外，指令在每个线程中执行，并且在每个核心之间发生复杂的交互。

at的CTO Shajid Thiruvathodi说:“像乱序执行这样的微架构特性会进一步加剧调试，因为即使是在重复执行相同的测试时，中间寄存器和内存状态也会不断变化Valtrix系统．

为了简化调试，重要的是首先要在算法级别上找出故障发生的位置。

Thiruvathodi说:“执行跟踪必须用调试打印进行注释，以识别来自不同内核的事务。”“这将使人们更容易理解轨迹，并了解全球范围内正在发生的事情。在系统级别上调试问题通常需要将事务与发起事务的主事务匹配。从刺激的角度来看，对于每个核心来说，只使用在测试中不会再次重复的惟一值来编写共享内存是非常重要的。这有助于在查看总线跟踪或缓存内容时消除事务的歧义。”

与所有调试一样，它需要在上下文中发生。但在多核设计中，这种环境可能非常复杂。

“从系统级的角度看问题，而不是从以处理器为中心的角度看问题，这是绝对重要的，”gjinder Panesar说Mentor是西门子旗下的企业．“你必须接受，大多数多核系统，就像许多非常复杂的系统一样，如果没有重要的技术帮助，人类大脑是不可能理解的。你需要收集大量的数据来理解现代SoC的运行，但你也需要能够帮助你理解这些数据的工具。这可能包括正确的可视化来帮助人类理解——也许就像同时查看硬件和软件操作的能力一样简单。或者可以使用更高级的数据分析、热图和相关性来指导工程师诊断问题。”

在调试多核系统时，有一些特定的因素需要考虑，包括经过时间考验的概念“错误时停止”和“错误时停止”。

他说:“在多核系统中，如果其中一个处理器抛出错误，这确实取决于整个系统。”“不管出于什么原因，一个处理器出现故障，最终都有可能导致整个系统瘫痪。在调试术语中，您有一个选择。当你看到这个错误时，你可以暂停发生错误的处理器，所有在它里面执行的进程都停止，但所有其他核心都在继续。通常，当您看到错误时，您不希望它发生。你想让整个系统优雅地停下来。在错误时停止是一个更通用的解决方案。当错误发生时，错误的核心将导致系统停止运行。”

挑战在于如何优雅地进行暂停/停止过程。这对传统方法不起作用，在传统方法中，基于主机的调试器检测并捕获错误，然后依次通知其他核心停止并提取它们的状态。在一个多核系统中引入所有的核心需要很长时间。相比之下，片上硬件方法可以检测错误并立即停止系统，以便捕获状态并分析问题。

这也不是一次性的解决办法。需要将调试视为贯穿设计、开发和部署的持续活动。“单核和多核设计之间的关键区别在于增加了核的数量，由于核和外围设备之间的交互，这使得调试工作更加复杂，治之软件．“多核设计可以基于统一的核心配置，也可以基于各种配置，甚至是isa的混合。多核还可以包括子系统的设计层次结构和各种阵列结构中的核心集群。”

事情变得更加复杂。“多核设计在物理硬件上可能是不确定的，无法控制一个核与另一个核的关系，”Davidmann说。“有限的访问权限甚至可能会限制在调试其他核心时停止其他核心的选项。这需要在整个设计阶段采用全面的调试方法，而混合工具设置可能会很复杂，难以同步。”

此外，调试系统不仅仅是调试内核上执行的代码。

“如果检测到系统故障——而不是单个处理器中的某种错误，比如内存访问的损坏——系统需要优雅地停止并捕获状态，”Mentor的Panesar说。“我们需要的是能够说，‘现在就停下来。这需要一个硬件调试小部件，并以一致和及时的方式管理到核心的调试接口。多核系统所需要的是一种硬件基础设施，能够以最小的处理器干预来支持该进程。硬件基础设施可以是一个嵌入式分析总线监视器，允许您查看芯片块之间的事务，以分析系统行为，而不仅仅是CPU代码执行。它并不局限于查看处理器代码的执行。这不仅仅是一个愚蠢的显示器。它是运行时可配置的，允许您查找可能感兴趣的特定事务或事务类别。”

单核vs.多核
这代表了对传统单处理器方法的突破，这种方法最初是作为多核调试的基础。但是利用单处理器方法的局限性很快就显现出来。

“在遇到棘手的问题之前，这种方法一直有效，这些问题似乎都发生在核心之间共享资源的问题上，”微软的产品管理总监拉里·梅林(Larry Melling)说节奏．“当你在处理多个核心时，共享资源是造成更棘手问题的原因。这样做的原因是，对于每个核心，软件通常都是这样写的，‘我不想依赖于硬件的时间。它想要执行，并且不考虑时间。如果有两个内核，每个执行的软件都希望是时间无关的，并且它们之间有一个共享资源——无论是共享内存还是它们都需要访问的其他设备——现在，突然之间，我在那里有了一些依赖关系。这种依赖关系(如果是硬件资源)也不可避免地涉及到时间依赖关系。当然，你可以设计一些东西，这样你就可以握手，确保如果一个核心在使用资源，另一个就不能。”

旧的方法也可能需要多核设计的过度工程，这限制了性能，以及多核设计带来的效率和其他好处。

梅林说:“在这些地方，旧的工具和我们所做的适应都受到了挑战。”“即使是在具有多个主硬件的单核设计中，我们也总是面临着必须调试内存损坏类型的问题，即它们都可以访问某种共享内存，并且你需要做一件事的内存位置被其他人损坏和覆盖。试图找到并调试这些可能非常困难，因为基本上这是大海捞针。有数百万或数十亿条指令正在被执行，而何时发生就不得而知了。”

图1:提高软件速度的虚拟和混合平台。来源:节奏

确切地说，什么是最好的方法往往是个人偏好的问题。

“有些人会对他们的设计进行现场调试，他们会构建一个FPGA原型并将其放在工作台上，或者他们会运行一个原型系统，他们会使用模拟器，或者他们会使用模拟器，”Alex Wakefield说Synopsys对此．此外，不同的用户运行不同数量的软件。有些只是运行裸机启动软件或不运行操作系统的东西。这些测试运行通常相对较短，这意味着它可以用模拟器来完成。还有一些用户在设备生产出来之前就已经启动了Android系统。”

异构多核
当内核不相同时，情况会变得更加复杂。工具集需要能够同时处理多个核心，以及具有不同体系结构的多个核心。

韦克菲尔德说:“可能有一群Arm核心在做数据包处理，也可能有一个神经网络类型的核心在做图像识别。”“也可能有一个电源控制器核心，和一些其他的应用程序核心——比如x86，或者PowerPC，或者另一种类型的重计算架构，或者更大的Arm核心——做一个应用程序部分。它们都在同一时间运行，并相互作用。如果该工具一次只关注一个特定的核心，那么您将很难判断一个核心向另一个核心发送了消息，但随后发生了一些事情，它没有得到答复。如果一次只能调试一个内核，就无法看到内核之间的交互。该工具需要同时处理多个具有共享内存空间或单独内存空间的内核，以便能够调试所有内核，并且它们都在同步中一起进行。通常情况下，实时调试并不适合这种情况。”

实际硬件核心经常会出现技术限制。Synopsys高级研发工程师Kai Schuetz说:“你必须阻止他们，正因为整个事情的运作方式，不可能同时阻止所有事情。”“你停止一个核，然后你停止另一个核。然后在启动核心时又会遇到同样的问题，因为不能同时启动它们。基本上，由于调试交互，您将失去精度。这就像你在对系统进行测量，通过进行测量，你可能会把它搞砸，让系统失去同步。”

这是一个侵入式的过程，实时调试打破了事件的顺序。因此，测试可能会给人一种错误的安全感，以为一切都在正常工作，或者它可能会产生与未使用调试器时不同的行为。

虚拟建模的侵入性较小，但并不总是那么有效。“现在我们看到很多人对RISC-V的虚拟建模很感兴趣，人们用它发现了很多错误，”公司的营销总监Louie De Luna说Aldec．“我们也看到人们使用QEMU进行多核调试，这是一个免费的开源模拟器，他们使用相同的环境来调试软件和硬件。这是一个有趣的想法，但还没有完全实现。”

联合仿真
一种有助于快速到达故障点的技术是联合仿真，它涉及在一个模型和设计上同时执行多条指令，并比较从中获得的结果。检查涉及寄存器、指令访问的内存、任何控制寄存器等。对于多核设计，除了指令将在每个核上执行之外，思路是相同的。

这就带来了一些潜在的问题。Valtrix公司的Thiruvathodi说:“任何由核心共享的‘真实’内存都不能被检查，这样模型和设计可能会产生不同的值。”“在许多联合模拟验证环境中，真正的共享内存不会被检查。联合仿真是调试多核设计的一种非常强大的方法，因为您可以非常快速地到达故障点。但因为它不能检验真正的共同价值观，我们不得不求助于上述技巧。”

在软件工作负载很大的情况下，这变得特别困难。“有很多很多的周期，”Cadence的梅林说。虚拟平台和指令集模拟器等虚拟化技术允许软件以比在其上运行软件的CPU设计更高的性能执行。以由硬件控制的速度运行，你可以使用这些虚拟化的抽象来更快地执行，因为你设计的软件是独立于硬件计时的，除了握手和必须发生同步的事情，你基本上可以独立地运行这些。我们一直在与虚拟世界和硬件世界相结合的客户进行混合，并在操作系统引导等方面看到了40到50倍的改进。这是正在发生的联合仿真的另一方面，它是关于跳到另一个性能水平——能够做更多的软件，并在一个完整的系统中进行更多的验证，在前硅环境中。”

联合仿真还可以涉及不同抽象层次上的指令精确模型。“最好的例子是RISC-V处理器验证方法，基于处理器硬件RTL功能与RISC-V参考模型的比较，并使用指令级分析进行步进-比较方法，”Davidmann说。在目标处理器(硬件)上以指令流(软件)的形式运行随机、定向和体系结构测试用例场景的组合，这是通过将Imperas模拟器与RTL测试台架紧密集成在一起来实现的SystemVerilog模拟。这直接导致了一种调试安排，以交互方式研究在单一工具环境中运行在RTL和参考模型上的相同代码。”

更快地找到bug
最大的挑战之一是在设计过程中更快更早地发现bug。

Synopsys的Wakefield指出，正式的验证可以有所帮助，并且已经看到客户成功地使用正式的方法来发现一些问题，某些类型的设计更适合正式。“当软件凌驾于硬件之上时，这个问题就会变得相当大，而且可能很难正式。至少在今天，正式场合需要有一个很大的飞跃才能应对这种情况。”

尽管如此，正式仍然扮演着重要的角色。“多核设计面临的一些重大挑战包括性能分析、内存子系统和结构，”英特尔的产品专家Nicolae Tusinschi说OneSpin解决方案．“用单核调试SoC已经够复杂的了，随着核心数量的增加，事情会变得越来越复杂。在这种类型的分析中，处理本可以在早期阶段检测到的设计问题是非常低效的。这就是使用低质量的开源内核可能不是最佳选择的原因之一，即使在构建演示程序时也是如此。RTL bug可能会拖慢项目进度，甚至掩盖性能问题。第一步是拥有高质量的核心和IP模型，并设置一个自动化流程，以正式证明IP是正确连接的。在许多情况下，对结构和内存子系统进行正式验证以排除在模拟中经常遗漏的死锁和活锁条件也是有益的，”他补充道。

无论如何处理，调试多核设计都是复杂的。

“当你在你的设计中引入一个CPU时，它是复杂的，然后随着每一个新的CPU，它都会增加复杂性，”olvera Stojanovic说Vtool．“在调试过程中，你需要对开源进行跟踪，而且还需要查看整个系统，这是很复杂的。为此，你需要一点魔法。而且，总会有很多问题。你需要不同领域的知识。你需要理解流程。你需要理解c。你需要知道该包括什么。然后,与UVM另一方面，一切将如何协同工作?这真的很复杂。最重要的是，您需要了解整个系统。您的测试用例或用例是什么?你通常需要和建筑师一起完成所有这些工作，这需要很多不同的知识，你需要一个真正优秀的工程师来处理这些问题。”

Vtool的验证主管Darko Tomusilovic表示，总体而言，验证中最复杂的部分是处理器之间的交互，因为涉及到太多文件。“为了运行最简单的软件场景，你需要做很多不同的事情。在新的处理器上运行“Hello, World”总是要花费我一个月的时间。简单地说，它本身就很复杂。你需要知道一点软件，一点硬件，一点编译流程，你需要知道很多不同的方面。”

最佳实践
尽管存在这些障碍，但还是有一些调试多核设计的最佳实践。

例如，梅林建议硬件团队与软件团队走得更近一些。“做硬件的工程师需要开始了解在硬件之上会有什么样的软件和软件架构，以及所有这些的影响。如果你设计软件意识，你就有最大的成功机会。”

尽管如此，基本的假设是，将单核调试系统扩展到多核是充满危险的。

Mentor的Panesar说:“你可以将单核方法扩展到少数核心，但现代系统有很多很多核心。”“我们的客户部署了数百甚至数千个内核，这种情况并不少见。同样值得区分同质多核和异构多核。处理多个核心架构的挑战略有不同，而不是多个相同的核心，或至少来自同一供应商的核心，”他解释道。

Panesar指出了一些调试多核设计的指导原则。首先，在体系结构阶段考虑调试总是很重要的。这需要理解需要使用哪些结构和设计增强来促进调试。

第二个原则是放弃以处理器为中心的调试视图。现在的大多数错误都归结于系统级的交互。您不会通过执行多个单处理器调试会话并希望系统交互能够自行处理来发现它们。它需要一个系统级视图。此外，处理器并不是当今芯片上唯一的复杂结构。noc和片上总线、自定义逻辑、内存控制器等的行为会对系统行为产生重大影响——如果你能采取措施观察和分析它们的操作，而不仅仅是CPU代码执行，你不仅会发现更多的错误，而且还会更容易找到根本原因并修复它们。

一般来说，调试过程需要被视为一个使产品变得更好的机会。并不是所有的bug都是令人扫兴的，把产品做到最好和修复坏掉的东西一样有价值。

结论
多核调试解决方案最终会发展成什么样还有待确定。一些人认为，传统的调试将转移到具有本地智能的芯片上的系统级分析，而外部主机将可视化和处理更高级别的相关性。

但无论最终如何解决，改变都是必须的。根据在多核设计相对较少的时候进行的研究，软件调试和启动大约占SoC总开发时间的50%到75%。

Panesar说:“‘多’这个词本身就意味着每种设计的核心数量相对较少。“随着我们转向‘真正的’多核设计，这个数字当然不会减少，所以这是一个我们需要非常非常认真对待的问题。”