使用软件查找硬件错误

有一个基本的自然法则适用于任何计算芯片，无论是处理器、微控制器还是片上系统：软件总是会发现硬件错误。在我的整个职业生涯中，我参与过的项目中没有一个被证明是正确的。

如果你很不幸，在你制作芯片后软件发现了一个错误，那么接下来会发生什么取决于问题的严重程度。

如果它不是致命的，并且如果你很幸运并且像一些知名处理器制造商那样拥有市场力量，那么每个人都会围绕这个 bug 编写代码，然后所有未来的版本都必须复制这个 bug 以实现向后兼容性。这不适用于我们大多数人。更倾向于：

您可能必须删除不起作用的功能。

功率可能太高，或性能太慢，损害您的竞争力和获得好价格的能力。

在最坏的情况下，您可能不得不花费大量时间并旋转另一套面具。额外的延误和费用。

最好的解决方案是在您投入芯片之前运行该软件并捕获这些错误。您将同时验证软件和硬件。但是怎么做呢？

模拟软件非常慢。我们说的是几年。除了琐碎的代码之外，根本不是一个选项。

相比之下，仿真被证明是解决这个问题的关键工具。您可以在模拟器上实例化硬件，然后让它在合理的时间范围内运行实际代码。也许不是真正的系统速度，但足够快以使其成为可行的解决方案。

但是，假设您要找到问题，您必须能够追踪这些问题的原因，而调试部分在历史上一直是问题所在。事实上，许多工程师一直不愿意使用仿真，因为在过去，访问内部处理器状态的唯一途径是通过 JTAG。仿真器以几 MHz 的时钟速度运行；仿真器上的 JTAG 只运行其中的一小部分。

那么，例如，如果你想单步执行指令？这意味着通过 JTAG 传输大约 400 万个低级位。在仿真器上以 1 MHz 完成，这将需要 4 秒非常昂贵的实时仿真器时间。

而且，更糟糕的是，它是侵入性的：在这 4 秒内，时钟正在走动。处理器状态将保持不变，但处理器之外的世界将继续。如果您只是在调试处理器代码，这可以工作（即使速度很慢）。但是，如果您尝试调试与非处理器硬件的交互，这将变得非常困难，因为在您完成该单个步骤时，处理器之外的所有内容都已更改状态。

由于仿真器上的 JTAG 既缓慢又具有侵入性，调试——尤其是与性能和同步相关的问题——变得非常令人沮丧。因此，考虑到这一点，仿真在过去并不是首选解决方案——阻力仍然存在。

今天的模拟器调试速度很快

但是时代和模拟器已经改变。Mentor 有一种单独的方法来捕获不依赖于 JTAG 的处理器状态，因此它可以快速发生 - 在 40-50 MHz 范围内。这可能比 FPGA 原型上的 JTAG 更快。数据被馈送到我们的 CoModel 主机，状态历史可以在其中存储和重新创建，一个周期一个周期。

鉴于已存储的跟踪，您现在可以针对该跟踪重放任何有问题的软件，它将遵循系统状态，以便您可以看到哪里出了问题。可以单步执行；您可以探测寄存器和内存；你可以看公交车。一切都没有入侵：您的调试工作不会改变系统状态。这一切都可以离线完成——您无需使用实时仿真器，这使其更具成本效益。

因此，关于软件调试在模拟器上是否实用的历史担忧不再适用。您可以在流片前彻底使用您的计算平台。软件开发人员可以在芯片可用甚至 FPGA 原型可用之前很久就开始软件开发。可用于调试的工具旨在为软件工程师所熟悉——即使您最终发现了硬件错误。

行使部分系统

我们要解决的下一个挑战是影响单个 IP 块的开发人员，这些 IP 块最终将成为整个系统的一部分。今天的问题是，在完全系统集成之前，你真的不能用真正的软件运行你的块，因为系统需要你的部分和所有其他部分才能工作。因此，即使您提前完成了块设计，也是“快点等待”。

在 Mentor，我们正在开发一个测试平台增强功能，它将提供计算平台的关键部分。鉴于 ARM 的流行，我们将从 ARM 架构和与 ARM 相关的总线开始。处理器将覆盖 Android 或 Linux。这将让您在仿真器上实现您的模块，并在完整系统设计可用之前将其“插入”抽象环境，让您在验​​证方面领先一步。

总之，您必须在生成掩码之前运行软件，以证明您的计算硬件是正确的。仿真是做到这一点的唯一现实方法，而目前 Mentor 的 Veloce 仿真器上提供的工具使其成为非常实用、高效的练习。您可以用最少的实时仿真时间快速调试您的软件和硬件。而且，在不久的将来，您将能够在完全系统集成之前在 IP 块上运行和调试该软件。

您可以更早地编写软件，并且可以更快地验证您的硬件。所有这些都使得您在真正的硅片中发现这些硬件错误的可能性大大降低。

审核编辑：郭婷