IP 集成挑战持续演变

核心要点：

• 集成挑战远不止确保模块正确连接。语义问题带来的麻烦最多，其中许多源于不完整或有缺陷的规格说明。
• 复杂性——包括不断增加的软件内容——使得跟踪设计中包含的所有内容变得更加困难。
• 许多设计正在逼近功耗和散热的极限，这需要一层新的信息，必须加以规定和跟踪。

IP 集成虽不是半导体设计中最光鲜的工作，却往往是最麻烦的工作之一。它处于模块级验证与系统级交互的交汇点，缺陷通常极难发现。

1996 年虚拟插座接口联盟（VSIA）的成立，对许多人来说，标志着通过集成第三方 IP 模块来设计系统这一理念首次成为现实。它的章程是统一并标准化 IP 的构建、验证、交付和支持方式。该联盟于 2008 年解散，认为其工作已经完成，或将部分工作移交给了更专注于特定问题领域的其他组织。十八年过去，这个问题仍在不断演变。

当时的理念是：每家公司应专注于开发设计中新颖和独特的部分，加入自己的专长，其余部分则交由领域专家来开发。

“十年前，一个设计可能只有几十个 IP 模块，”Keysight EDA 的 SOS 产品经理 Pedro Pires 表示。“如今，一家公司可能拥有数千个 IP，同一个 IP 还有几十个不同版本，而你需要理清这一切。此外，它们的可配置性也比过去强得多。随着每个模块所需的数据在数量和类型上不断增加，用临时应付的方式管理已经变得非常困难。”

这给验证带来了巨大压力。“最棘手的故障几乎从不出现在单个模块内部，”Axiomise 创始人兼 CEO Ashish Darbari 说。“它们出现在模块之间——消息相关的死锁、慢慢泄漏的信用值、被破坏的重排序缓冲区、跨桥接被打破的排序规则。每个模块都通过了自己的验证，但系统却挂起了，只因两个团队对同一条协议规则的理解略有不同。”

随着时间推移，跨 IP 问题的数量在增加。“从 SoC 的角度看，可能是很多不同的问题，包括地址映射、中断、一致性、QoS、安全性，”Synopsys HPC IP 产品组合技术产品管理高级总监 Madhumita Sanyal 说。“此外还有物理实现场景，比如 DVFS——用于降低功耗的动态电压调节。再加上软件和操作系统交互。如果考虑 die-to-die IP，还有互操作性。还有已知良芯封装、信号完整性、电源完整性、供电网络、热耦合、遥测等等。”

虽然设计规模在稳步增长，但仅凭规模并不能衡量复杂性。“我可能正在设计一个拥有 32 个核心的巨型 CPU，但这只是把同样的东西复制 32 份而已，”IC Manage CEO Dean Drako 说。“它上面可能有一个巨大的缓存，那也只是一个单元重复了 1 亿次。复杂性并不总是与芯片的尺寸成正比。它们确实复杂，但复杂性并没有随芯片尺寸线性增长。人脑无法应对这种情况。”

真正重要的是一个模块对周围世界做出了多少假设，而这个数字的增长速度远快于规模。“一个 UART 只需要一个时钟、一个复位和一个寄存器接口，仅此而已，”Axiomise 的 Darbari 说。“而一个一致性缓存、一个 CHI home node 或一个 NoC 则带有数百个假设。其中有排序规则、信用契约、未完成事务的限制、复位与上电时序、地址映射预期和安全属性。此外还有数据手册往往未能完全解释其影响的配置参数。”

日益增大的压力
许多方面都在加剧集成压力，例如 IP 模块规范编写不佳或不完整。在系统层面，软件复杂性日益增加，功耗和热问题日益突出——尤其是在与 chiplet 相关时，模拟内容不断增加，许可、地缘政治限制和出口管制也带来了额外的复杂性。本文将简要提及其中每一项。

糟糕或不完整的规范：众所周知，要让规范做到无歧义或完整是非常困难的。“这些信息往往不够完整，无法让你准确了解它在所有情况下将如何表现，”Keysight 的 Pires 说。“了解系统将在何种条件下运行可能会对你有所帮助，这取决于你的 IP 文档的质量。可能这些 IP 包含与该特定情况相关的信息，从这个意义上说，了解系统将在何种情况下运行会对你有所帮助，但也可能没有帮助。”

这个问题往往在缺陷泄漏之后才被发现。“架构师、设计人员、软件团队、DV 负责人和形式验证团队都看着同一个失效，却看到不同的东西，”Darbari 说。“没有人能就系统应该做什么达成一致，因为从来没有人以所有人都共享的形式把它写下来。这些意见分歧从第一天起就存在。它们只是在两年后才浮现出来，而且往往是在流片后的调试阶段，那时修复成本最高。”

软件复杂性：虽然有些软件是完全封装的，对任何外部接口都不可见，但很多并非如此。“即使是像 PHY 这样简单的东西，也包含大量软件内容，”Synopsys 的 Sanyal 说。“有启动固件，它将建立所有的时钟、复位和内存。然后 PHY 还有校准固件，它负责初始校准和自适应，并且会持续更新。该驱动程序需要与操作系统中断和 DMA 框架对接，还有 PCI 控制器之类的 BIOS 和 hypervisor、一致性或 IOMMU 依赖。这些都将依赖关系扩展到了顶层拓扑结构、操作系统服务和电源管理框架之间的中断。”

这些问题已经严重到 UCIe 标准试图加以解决的地步。“UCIe 3.0 对固件在初始化早期如何下载进行了标准化，”Darbari 说，“麻烦在于，硬件往往只有在某些软件假设下才是正确的。例如，寄存器可能必须按特定顺序编程，或者某个字段在事务进行过程中绝不能被写入。这些规则很少被写下来，而仅靠 RTL 验证也从不检查它们。”

硬件与软件之间的鸿沟很大。“软件世界和硬件世界非常不同，这意味着在硬件侧工作的人与在软件侧工作的人不同，”Pires 说，“这包括固件——与 IP 深度绑定的软件。这两个团队的工作流程和节奏也不一样。”

功耗与散热：功耗控制正在成为一个越来越大的问题。“电源管理已经成为一项功能特性，也是功能性缺陷的一个主要来源，”Darbari 说。“每个电源域都会增加状态、转换、隔离和唤醒序列。一个模块在通电时可能完全正确，但当它的邻居在传输中途断电时，仍可能丢失事务或挂起握手。诸如‘如果该域在响应尚未返回时被关掉，这个请求会不会丢失’这类问题，是经典的形式化验证问题。仿真很少恰好落在出问题的那个周期上。”

功耗产生热量，而热量反过来可能改变敏感电路的行为。“如今功耗和散热决定着 SoC 的极限，模拟 IP 再也不能被动地坐在那里了，”Agile Analog 产品营销副总裁 Chris Morrison 说，“我们必须通过嵌入式 PVT 传感器、时序监视器、电压跌落检测器和毛刺检测器来主动管理芯片，它们将实时遥测数据反馈给电源管理单元，以便在问题影响运行之前将其捕获。”

模拟内容：模拟内容一直面临着独特的挑战。“这些 IP 的工作范围有限，而且它们非常针对特定用例，”Pires 说。“虽然 AI 在许多领域都有所帮助，但由于数据稀缺，在创建 AI 自动化以加速射频和模拟设计方面，我们看到了一个巨大的挑战。要获得一个质量足够好、数量足够多、可以用来训练智能体去完成流程中某个特定部分的数据集，并不容易。相关信息更加定制化、聚焦且狭窄，而且往往是不对外提供的专有信息。”

模拟模块的创造者正在寻找将其设计抽象到数字世界的方法。“客户越来越多地要求完整的模拟子系统，而不是去对付十几个单独的模块，”Agile Analog 的 Morrison 说。“在 SoC 层级用 SPICE 仿真大型模拟子系统耗时太长，因此可以用数字封装器将 IP 隔离起来，从而简化验证。在内部完成繁重的混合信号处理工作，意味着数字 SoC 集成团队可以尽早拿到 SystemVerilog 实数模型（RNM），并在他们的数字环境中运行整芯片验证。”

芯粒（Chiplets）： 芯粒可以被视为 IP 的一种新的物理交付机制。Synopsys 系统解决方案战略项目执行总监 Frank Schirrmeister 表示：“芯粒放大了这个问题，并使其同时也成为一个供应链集成问题。你不仅要面对 IP 层面的问题，还要把设计从 SoC 边界提升到封装边界。现在，IP 集成变成了供应链集成。你不仅在集成设计，还在集成这些可能来自不同公司、不同工艺节点和不同代工厂的部件，而它们在 IP 层面都有各自不同的验证方法学。”

集成问题一个都没有消失。Darbari 表示：“NoC 现在正被延伸跨越裸片边界，多颗裸片看起来像同一个互连结构。UCIe 在物理层和链路层的处理上表现良好，跨供应商的互操作性也已被演示。但一条能工作的链路并不意味着一个能工作的系统。你仍然需要在地址映射、一致性模型和软件方面达成一致，而这些恰恰是标准留白不予规定的语义问题。现在的规范已包含 DFD、DFT 和 DFM 以及可管理性，因此芯粒开始变得不再像一块被动的模块，而更像一个拥有自己管理固件的小型系统。”

芯粒比 IP 模块需要的信息还要多。Pires 表示：“现在有多种物理效应同时起作用，这意味着你需要多得多的关于你所管理的 IP 的信息。要把所有这些数据放在一起已经变得难以驾驭。这意味着更多的复杂性将伴随你的 IP。例如，功耗意图需要作为一个额外的交付物随你的 IP 一起传递。”

验证： 对于 IP，对芯粒来说更是如此，对模块内部缺乏可见性会使验证变得更加困难。Darbari 表示：“大型 IP 现在越来越多地以加密形式交付，因此你无法通过阅读 RTL 来弄清它真正的预期行为。你只能依靠文档，而根据我的经验，bug 往往就出在文档上。这些模块还是以生成器而非固定设计的形式交付。供应商验证了某一套配置，但你流片的很可能是另一套配置。只要参数超过几个，就很容易落在一个没人测试过的组合上。”

好消息应该是，并非 IP 的每一项功能都需要验证。Sanyal 表示：“识别功能合法子集是一项架构和验证任务。它不是那种可以一刀切自动化的东西。如果从验证的角度看，现在已经有 AI 模型在投入使用，我们在用，我们的客户也在用，以便比以前更快地覆盖那些边界情况。它正在切入验证这一环节。”

版本控制
很少有东西在第一次尝试时就完美无缺。Bug 会在首次发布后被修复。IC Manage 的 Drako 表示：“非 AI 的版本情况是，这涉及 IP 生命周期管理。有了 AI，这些生命周期可能会变化更快，但你仍然需要管理这些生命周期。也许你可以让 AI 替你去做，但你必须有相应的数据和系统来跟踪它，知道你流片了什么，知道你构建了什么，知道什么被用在了哪里，哪个 IP 被用在了哪里。”

硬件和软件的交付与更新遵循不同的时间表。Darbari 表示：“现场的固件更新可能会改变硅片在签核之后的行为。中断、电源状态、DMA 缓冲区和安全属性在硬件与软件之间共享，而冲突往往在系统启动时浮现——此时第一个真实的驱动程序运行了一段无人规定过的操作序列。”

硬件和软件通常使用不同的版本控制机制。Pires 表示：“挑战在于如何将所有这些数据整合到一个系统中。特定版本的硬件需要对应特定版本的软件，而这种关联往往存在于 Excel 电子表格中，既混乱又容易出错。在集成系统时，你需要管理配置本身，例如某个系统的物料清单，以及系统中各组件的具体组合。每当你对其进行更改，都需要持久保存。你必须把它保存下来，以便获得可追溯性。”

结论
这看起来似乎是一个日益令人担忧的问题。但正如 EDA 领域的大多数问题一样，问题越大，它受到的关注也越多，而对问题的投入最终会带来更好的解决方案。

Pires 表示：“管理问题在增长，但应对问题的机制也在随之演进。相对而言，痛苦程度保持不变，但其背后的问题却越来越大了。”

编者注：本报告的第二部分将探讨近期的改进，以及 AI 如何被用于改进 IP 的选择、配置和集成。

相关文章
加速 IP 复用
如何将 1,000 个 IP 放入芯片设计并确保它们协同工作。

垂直集成日益普及
不了解硬件与软件两者，就无法优化任何系统，而做出正确的架构选择需要协作。