多核体系结构的激增和扩展使调试变得更加困难和耗时，从而反过来增加了对更全面的系统级工具和方法的需求。多核/多处理器设计是最复杂的调试设备。内核之间更多的交互作用和相互依赖性意味着更多的事情可能出错。实际上，可能存在许多问题，工程团队经常不知道从何下手。与单核相比，多核设计包含更多可同时调试的执行流。另外，指令在每个线程中执行，并且每个内核之间会发生复杂的交互。

Valtrix Systems公司首席技术官Shajid Thiruvathodi说："像失序执行这样的微架构特性会进一步加剧调试，因为即使是对非常相同的测试进行重新执行，中间寄存器和内存状态也会不断变化"。

为了简化调试，首先要在算法层面弄清楚故障发生的位置。

"执行痕迹必须用调试打印来注释，这些打印可以识别来自不同内核的事务，"Thiruvathodi说。"这将使人们很容易理解跟踪，并了解在全局层面上发生的事情。在系统层面调试问题往往需要将事务与发起事务的主控匹配起来。从刺激的角度来看，每个核心只写一个共享内存的唯一值，在测试中不会再次重复，这一点非常重要。这有助于在查看总线跟踪或缓存内容时对事务进行歧义。"

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

"采取系统级的观点，而不是从以处理器为中心的角度看问题，绝对是至关重要的。"西门子业务Mentor的研究员Gajinder Panesar说。"你必须接受，大多数多核系统，就像许多非常复杂的系统一样，如果没有大量的技术帮助，人脑是不可能理解的。你需要收集大量的数据来理解现代SoC的运行，但你也需要能够帮助你理解这些数据的工具。这可能包括正确的可视化，以帮助人类理解--也许简单到能够同时查看硬件和软件操作。或者可以是更先进的数据分析、热图和关联，引导工程师对问题进行诊断。"

在调试多核系统时，需要考虑一些具体的因素，包括 "出错即停 "和 "出错即停 "这样久经考验的概念。"

"在多核系统中，如果其中一个处理器抛出了错误，它确实取决于整个系统，"他说。"可能性是，一个处理器故障，不管是什么原因，最终会使整个系统瘫痪。在调试方面，你有一个选择。当你看到这个错误时，你可以停止出错的处理器，其内执行的所有进程都会停止，但其他核心都会继续。一般来说，当你看到一个错误时，你不希望发生这种情况。你想让整个系统优雅地停止。Stop on error是一个比较通用的解决方案。当发生错误时，错误的内核将导致系统停止。"

挑战在于让停止/停止过程优雅地发生。这对于传统的方法来说是行不通的，在传统的方法中，基于主机的调试器检测并捕获错误，然后依次通知其他核心停止并提取它们的状态。在一个多核系统中，要把所有的核都带上，简直太费时间了。相比之下，硬件片上的方法可以检测到一个错误，并立即停止系统，这样就可以捕获状态并分析问题。

这也不是一次性的修复。在整个设计、开发和部署过程中，需要将调试视为一项持续的活动。"单核设计和多核设计之间的关键区别在于增加了核心数量，由于核心和外设之间的相互作用，这加重了调试工作。"Imperas软件公司首席执行官Simon Davidmann说。"多核设计可以基于统一的核心配置，也可以是异构的，具有一系列配置，甚至是混合的ISA。多核还可以包括子系统的设计层次和各种阵列结构的核心集群。"

它变得更加复杂。"如果没有能力控制一个核心与另一个核心的关系，多核设计很可能在物理硬件上是非确定性的，"Davidmann说。"有限的访问甚至可能限制了在调试另一个核心时停止其他一些核心的选项。这需要在设计阶段中采用全面的调试方法，而混合工具设置可能会很复杂，难以同步。"

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

"如果检测到系统故障--相对于单个处理器的某种错误，例如内存访问上的损坏--系统需要优雅地停止并捕获状态，"Mentor的Panesar说。"需要的是说'现在停止'的能力。这就需要一个硬件调试部件，并对核心的调试接口进行连贯和及时的管理。在多核系统中，需要的是一个硬件基础设施，以最小的处理器干预来支持这一过程。这个硬件基础设施可以是一个嵌入式分析总线监控器，它允许你查看片上块之间的事务，以分析系统行为，而不仅仅是CPU代码的执行情况。它并不局限于查看处理器代码执行情况。它不仅仅是一个哑巴显示器。它是运行时可配置的，允许你寻找可能感兴趣的特定事务或事务类别。"

    单核VS多核  

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

"在你遇到棘手的问题之前，这种方法是可行的，这些问题似乎都是围绕着核心之间的共享资源而发生的，"Cadence公司产品管理总监Larry Melling说。"当你在处理多个内核时，共享资源是造成较棘手问题的原因。原因在于，对于每个内核，软件在编写时一般都会说：'我不想依赖硬件的时序。它要执行，要与时序无关。如果有两个内核，每个内核都在执行想要与时间无关的软件，而且它们之间有一个共享资源--无论是共享内存还是，它们都需要访问的其他设备--现在，突然间，我在那里有了一些依赖性。这种依赖性，如果是硬件资源，必然也会涉及到时序依赖性。当然，你可以通过工程设计，让你可以握手，确保如果一个核心在使用一个资源，另一个核心不能使用。"

旧的方法还可能需要对多核设计进行过度设计，从而限制了性能以及多核设计带来的效率和其他好处。

"这些都是旧的工具和我们所做的调整受到挑战的地方，"Melling说。"即使是在硬件上有多个主控的单核设计上，我们也一直面临着不得不调试内存损坏类型的问题，它们都可以访问某种共享内存，而你需要做一件事的内存位置会被别人损坏和覆盖。试图找到并调试这些问题是非常困难的，因为基本上是大海捞针。有几百万或几十亿条指令被执行，什么时候发生的谁也不知道。"

图1：提高软件速度的虚拟和混合平台。

究竟什么是最好的方法，往往是一个偏好的问题。

"有些人会对他们的设计进行现场调试，他们会建立一个FPGA原型，然后放在工作台上，或者他们会运行一个原型系统，他们会使用仿真器，或者他们会使用模拟器，"Synopsys的应用工程科学家Alex Wakefield说。"另外，不同的用户运行不同数量的软件。有些人只是运行裸机启动软件或不运行操作系统的东西。这些测试运行时间通常比较短，这意味着可以用模拟器来完成。其他用户则在该设备制造之前就一直在设备上启动Android系统。"

    异构多核  

当核心不完全相同时，这就变得更加复杂。工具集需要能够同时处理多个核心，以及具有不同架构的多个核心。

"可能有一个Arm核心集群在做数据包处理，也可能有一个神经网络类型的核心在做图像识别，"Wakefield说。"也可能有一个电源控制器核心，还有一些其他应用核心--比如x86，或者PowerPC，或者其他类型的重计算架构，或者更大的Arm核心--在做应用这一块。它们都在同一时间运行，并且都在互相交互。如果工具一次只关注一个特定的核心，你就会很难说一个核心向另一个核心发送了消息，但后来发生了一些事情，它没有得到回复。如果一次只能调试一个，你就无法看到核心之间的交互。工具需要同时处理多个有共享内存空间或独立内存空间的核心，这样就可以调试所有的核心，而且它们都是同步步入的。通常情况下，实时调试对此不会有很好的效果。"

经常，真正的硬件内核会出现技术上的限制。"你必须停止它们，就因为这整个事情的工作方式，不可能同时停止所有的东西，"Synopsys的高级员工研发工程师Kai Schuetz说。"你停止一个核心，然后你停止另一个核心。然后，当你启动核心时，你又会遇到同样的问题，因为你不能同时启动它们。基本上，你会失去精度，因为调试会相互影响。这就像你在对系统进行测量一样，通过进行测量，你会把它弄乱，使系统失去同步。"

这是一个侵入性的过程，实时调试打破了事件的顺序。所以测试可能会给人一种虚假的安全感，认为一切都在工作，或者它可能会产生与不使用调试器不同的行为。

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

    协同仿真  

有一种技术有助于快速到达故障点，那就是协同仿真，即在一个模型和设计上同时执行几条指令，并比较它们所得到的结果。检查涉及到寄存器、指令访问的内存、任何控制寄存器等。对于多核设计来说，想法是一样的，只是每个核上都会执行一条指令。

这就会带来一些潜在的问题。"任何由核心共享的'真'内存都不能被检查，这样的模型，和设计可能会产生不同的值，"Valtrix的Thiruvathodi说。"在许多协同仿真验证环境中，真正的共享内存是不会被检查的。协同仿真是一种非常强大的调试多核设计的方法，因为你将能够很快地到达故障点。但由于它不能检查真正的共享值，我们不得不采用上面提到的技巧。"

而在软件工作负载巨大的地方，这就变得特别困难。"有很多很多的周期，"Cadence的Melling说。"有一些虚拟化技术，如虚拟平台，以及指令集模拟器，可以让软件执行的速度甚至高于在其上运行软件的CPU设计。在那个硬件控制的速度下运行，你可以利用虚拟化的这些抽象来更快的执行，而且因为你设计的软件是独立于硬件时序的，除了有握手和必须发生同步的事情，你基本上可以独立运行这些。我们一直在和客户做混合型的产品，就是虚拟世界和硬件世界的结合，看到OS启动等方面有40倍到50倍的改进。这就是协同仿真发生的另一面，它是关于性能的另一个层次的跃升--能够做更多的软件，以及在全系统、硅前环境中更多的验证。"

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

    更快地找到错误  

其中一个大的挑战是在设计过程中更快、更早地发现bug。

Synopsys的Wakefield指出，形式化验证可以提供帮助，并且已经看到客户成功地使用形式化来发现一些问题，某些类型的设计更适合形式化。"当软件与硬件坐在一起的时候，这个问题就会变得非常大，对于formal来说可能太难了。至少在今天，formal需要有一个很大的飞跃，才能够处理这个问题。"

不过，formal还是有重要作用的。"多核设计的一些大挑战涉及到性能分析，以及内存子系统和结构，"OneSpin Solutions的产品专家Nicolae Tusinschi说。"调试一个单核的SoC已经够复杂了，随着核数的增加，事情会变得成倍地复杂。在这种类型的分析过程中，处理本可以在早期阶段发现的设计问题是非常低效的。这也是使用低质量的开源内核可能不是最佳选择的原因之一，即使是在构建演示器时。RTL错误可能会减慢项目的速度，甚至掩盖性能问题。第一步是拥有高质量的内核和IP模型，并设置一个自动化流程来正式证明IP的布线正确。他补充说："在许多情况下，对结构和内存子系统进行正式验证也是有益的，以排除在仿真中经常遗漏的死锁和livelock条件。

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

"在你的设计中引入一个CPU的那一刻，它是复杂的，然后随着每一个新的CPU，它的复杂性在增加，"Vtool的项目经理Olivera Stojanovic说。"在开源方面，你需要在调试过程中进行跟踪，也需要把整个系统带起来，这是有复杂性的。为此，你需要一点魔法。另外，总是有很多问题。你需要不同领域的知识。你需要了解流程。你需要了解C，你需要了解包括什么。然后，与UVM在另一边，一切将如何一起工作？这真的很复杂。除此之外，你还需要了解整个系统。你的测试用例或用例会是什么？而且你通常需要和架构师一起做这些事情，这需要很多不同的知识，你需要一个非常好的工程师来处理。"

总的来说，验证中最复杂的部分是处理器之间的交互，因为涉及到的文件太多了，Vtool的验证总监Darko Tomusilovic说。"为了运行哪怕是最简单的软件方案，你需要做很多不同的事情。光是在新的处理器上运行'你好，世界'，我总是要花上一个月的时间。简单地说，它本身就很复杂。你需要了解一点软件、一点硬件、一点编译流程，你需要了解很多不同的方面。"

    最佳实践  

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

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

不过，基本的假设是，把一个单核调试系统扩展到多核是充满危险的。

"你也许可以将单核方法扩展到少量的核心，但现代系统有很多很多的核心，"Mentor的Panesar说。"我们有客户正在部署数百个，有时甚至数千个核心，这并不罕见。此外，值得区分同质多核和异质多核。他解释说："与多个相同的核心，或至少是来自同一供应商的核心相比，处理多个核心架构的挑战略有不同。"他说。

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

第二个原则是要摒弃以处理器为中心的调试观点。现在大多数的bug都归结为系统级的交互。你不会通过执行多个单处理器调试会话，并希望系统交互会自己处理来发现它们。这需要系统级的观点。此外，处理器并不是当今芯片上唯一的复杂结构。NoC和片上总线、自定义逻辑、内存控制器等的行为都会对系统行为产生重大影响--如果你能采取措施观察和分析它们的运行情况，而不仅仅是CPU代码的执行情况，你不仅会发现更多的bug，而且找到根本原因并修复它们也会变得非常容易。

一般来说，需要把调试过程看作是让产品变得更好的机会。并不是所有的bug都会让人眼前一亮，把产品做得越好越好和修复坏掉的东西一样有价值。

多核调试方案最终会演变成什么样子，还有待确定。有人认为，传统的调试将转向片上的系统级分析与本地智能，外部主机则留给可视化和处理更高层次的关联。但无论最终如何解决都需要改变。根据在多核设计相对较少的年代所做的研究，软件调试和带机大约需要占SoC总开发时间的50%到75%。

"这个术语，'多'本身就意味着每个设计中的内核相对较少，"Panesar说。"随着我们转向'真正的'多核设计，这个数字肯定不会减少，所以这是一个我们需要非常重视的问题。"