RISC-V 用于 AI：是突破还是坏主意？

要点总结:

• RISC-V 在 AI 中的角色存在争议。它的定制化带来了灵活性,但在 CPU 与加速器之间拆分推理工作负载,可能引入代价高昂的数据搬运和编译器复杂性。
• 可控性或许是 RISC-V 的最佳定位。自定义指令有助于编排加速器、降低加载/存储延迟,并在不承担重型推理的情况下处理有限的数学任务。
• 正确的指令并不保证芯片能正常工作。定制 AI 系统还需要可观测性和系统级验证,以暴露性能瓶颈、缓存一致性问题以及互连死锁。

专家圆桌会议：对并行性和能效的需求正推动芯片设计从通用计算转向 AI，增加对灵活、模块化和开放硬件的需求。这一趋势正使 RISC-V 进入 AI 加速领域。可定制的硬件可以直接实现 AI 计算，而不必依赖固定的 CPU 设计。Semiconductor Engineering 邀请了以下嘉宾讨论这些问题：Quadric 首席营销官 Steve Roddy；Siemens EDA Tessent 产品管理与产品工程总监 Francisca Tan；SignatureIP 销售与业务发展高级副总裁 Ewald Liess；以及 Breker CEO Dave Kelf。以下是这次对话的摘录。

左起:Quadric 的 Roddy;Siemens EDA 的 Tan;SignatureIP 的 Liess;Breker 的 Kelf。

SE:随着 AI 模型快速演进,架构师们利用 RISC-V 设计高度专用的扩展。从 IP 供应商的角度来看,您如何在提供标准化、可复用的 IP 核与客户针对 AI 工作负载所要求的极致定制之间取得平衡?

Leiss:我们认为不需要配置,因为我们提供 NoC 以及 PCI Express 和 CXL CHI AMBA 接口。基于此,我们不需要定制,而是对 NoC 进行配置。由于我们拥有预先验证过的 NoC,可以用我们的工具来完成。我们可以配置定制的 RISC-V。当然,客户可能会通过新指令修改 RISC-V 核心,但他们仍会坚持使用 AMBA 总线或 CXL、PCI Express 接口这类接口,因为这使他们能够访问所需的外部组件,例如内存或片外通信。而这正是我们的用武之地。所以 RISC-V 的开发者可以随心所欲地做自己想做的事。

Tan:定制验证与确认也变得重要,可观测性同样如此。在测试和嵌入式分析方面,进行调试或芯片点亮(bring-up)的工程师可以监测、内省和检查内部信号,或计算性能是否达标。在我看来,随着行业面临芯片领域的种种挑战与复杂性,这也关乎硬件的可观测性。

Roddy：在这个特定领域，我们持相反的观点。我们认为从 RISC-V 入手去做 AI 加速器完全是个坏主意，因为这会立刻带来一个问题：一部分东西运行在具有良好 ALU 能力的可编程处理器上，而另一部分则运行在外部加速器上，系统就这样被割裂了。一旦割裂，一旦产生问题，你就需要复杂的编译器去修复它，去解决如何把数据通过一个不错的 NoC 从加速器（或多个加速器）搬运到可编程核心，再来回往返。这是一个扩展性很差的问题：加速器越大，情况越糟。于是你在让问题不断叠加。假设你的算力是 100 TOPS，需要 16 个 RISC-V 处理器从属于一大堆加速器模块，那你当然需要出色的互连、出色的验证，以及随之而来的一切——因为你在试图解决一个根本性的底层问题，而这个问题正是从 CPU 起步造成的。CPU 擅长追逐指针，这就是 CPU 的本职。CPU 拥有精妙的逻辑来处理这样的情况：你有 40 个线程在运行，而到了下一个时钟周期，你完全不知道会运行什么。但做 AI 推理时并不是这样。你能在数百万个周期之前就知道将要发生什么，根本用不上 CPU 的大部分硬件。DSP 稍微接近一点，但 DSP 是向量机——向量对标量或向量对向量。而 AI 中最具挑战性的运算大多是矩阵对矩阵。所以我们造了一台矩阵原生机器。据我所知，唯一另一个与之接近的是数据中心里的 Google 那些庞大的 TPU。其他所有人面临的实际上都是一个被割裂的问题，然后他们苦苦挣扎、花掉数十亿美元去处理这个割裂问题，试图弥补我们认为糟糕的起点。

Kelf：我同意 Steve 的观点，因为我们看到的是大型 AI 加速器——它们可能是不同的架构，SIMD、SIMT——已经相当普遍。这类东西基本上是由某种复杂的状态机控制的，或者说一直由其控制，然后会有某种主机处理器驱动几个这样的不同部件，告诉状态机该做什么，再驱动加速器。我们现在已经在四家公司（既有大公司也有小公司）中看到，状态机是行不通的。所以他们采用 RISC-V 处理器，并把它用作这些加速器之上的控制功能，原因有很多。其一，他们实际上可以内建一堆数学引擎——正是 Steve 提到的那种——向量类型，使用 RISC-V 向量指令或那些指令。然后他们还加入自己的指令，或者一些新的矩阵乘法指令。他们还加入了自己的指令以实现非常高效的加载/存储，从而减少在分区之间看到的延迟。所以他们正在想办法调整这些 RISC-V 处理器，以降低延迟并减少分区问题。我们有很多例子，有的成功，有的不太成功。他们仍在解决这个问题，但 RISC-V 的好处是他们可以添加任何想要的自定义指令，仍然使用常规编译器，并创建一种机制来驱动非常高效的加载/存储，这是其他处理器做不到的。当然，也有像 Arm 和其他公司那样的人在某些处理器中内建了指令，但这些指令是不可变的。RISC-V 对此非常理想，在创建这些强大的自定义指令方面相当独特。

SE：关于那些自定义向量指令，EDA 工具是否已经考虑到这一点并实现了验证自动化？

Roddy：我在 Tensilica 待了 17 年。我们把这一切都自动化了。当然，缺点是你需要支付授权费。RISC-V 提供了一个不用向大公司缴纳授权费、贡金、税款的机会。如果你想要定制化，Tensilica 的那些人很多年前就实现了自动化。其理念是修改指令，立刻获得与之匹配的编译器和模拟器，验证也已处理妥当，因为它是在一个结构化的环境中。RISC-V 给了你更大的灵活性，可以超出那些界限。我的看法是，如果你真的想使用 RISC-V，你最好全力以赴，把它彻头彻尾地定制化，才值得花力气手动创建所有这些东西，因为如果你只想做一点点定制，我那些 Tensilica 的老朋友们有一套自动化系统可以实现这一点。是的，它带有商业成本。RISC-V 是一项非常有趣的技术，它绝对有自己的用途。市场领导者不会为控制和 CPU 功能提供那种程度的灵活性。通过针对手头的控制功能来调整和优化处理器，你可以获得很大的价值。只是我们不认为用它来做推理是合理的。但 CPU 有成千上万种用途，RISC-V CPU 或许能以更灵活、更高效的方式完成这些任务，而且价格肯定比其他供应商的固定功能 CPU 更低。我们只是不认为用它来做繁重的推理工作是部署这种技术的正确方式。

Kelf：我基本同意。一些公司正尝试在芯片中构建向量单元，并打造自己的某种数学类 DSP 型指令。我曾与一些遇到问题的客户交谈。他们有一个 SIMT 阵列——单指令多线程——在进行大量并行数学运算，并希望某条并行通道不会与其他通道产生分支发散。但偏偏有一条就发散了。SIMT 的好处在于它允许发散。他们利用 RISC-V 控制处理器来处理因发散产生的部分数学运算，让加速器的其余部分继续完成其余正在进行的数学处理。他们并没有在 RISC-V 内部做重量级处理，只是做到足以让整台机器正常运转并降低延迟的程度，但在 RISC-V 里做了这种挺特别的事情。他们花了很大功夫才使其正常工作，但现在他们觉得相当成功。我同意 RISC-V 在商业方面的优势，即无需支付授权费，我也认同 Tensilica 技术，它对这类应用非常出色，尤其是 DSP 通信。但他们可以在 RISC-V 内部做类似的事情。他们必须自己动手构建，必须懂得如何去做。但一旦做到，RISC-V 周边就有很大的灵活性和大量的标准化支持。他们可以获得编译器，甚至有可能转向另一家公司，并将一些专有功能内置到那个 RISC-V 中。这确实带来了更大的灵活性，同时也带来了更多的标准化，而这些可能是固定处理器和专有处理器所无法提供的。

Tan：关于测试和更好的分析能为自定义指令（尤其是来自 RISC-V 领域的）带来什么，我们支持用于自定义指令追踪的可调试性。我们支持 RISC-V 用户指定在处理器运行时想要追踪哪些自定义指令，以支持这种可调试环境。我们也是 RISC-V 组织的成员之一，几年前我们捐赠了高效追踪（E-Trace）规范。这是一种高度压缩的指令追踪，面向将会产生大量数据的复杂系统，因此我们需要考虑如何压缩这些数据。在我们的基础设施中，关注的不仅是处理器，而是整个系统。所以我们的基础设施既可以从 RISC-V 核心捕获指令追踪，也可以从 RISC-V SoC 的各个部分（如互连、总线监控或我们想要监控的特定信号）捕获指令追踪。

Leiss：我们已经谈了很多关于验证自定义指令集、通过 ISA 级别验证的内容，大多数情况下，生成的 IP 可能会附带验证配套材料，比如测试平台、流量生成器和性能模型。但我从系统的角度来看，这意味着一个高性能系统中通常有多个核心，当你有一个 RISC-V 加速器，或者一个系统里有多个 RISC-V 时，你就会立刻遇到一致性问题，因为你要使用缓存等等。一致性的边界情况和流量突发很容易在互连结构中造成死锁。因此，重要的是，我们从 NoC 这一侧在系统级别进行所有这些验证，以检查流量如何流转，并确保不会陷入死锁状态。简单来说，一条指令可以正确执行，但如果该指令或计算所需的数据突发不可用，芯片仍然可能失败。这正是我们正在解决的领域。