新思科技等：IP集成挑战演变，语义与功耗问题凸显

核心要点：集成挑战不仅仅是确保模块正确连接。语义问题引发的问题最多，其中许多源于不完整或糟糕的规范。包括软件内容不断增加在内的复杂性，使得跟踪设计中包含的所有内容变得更具挑战性。许多设计正在突破功耗和散热边界，这需要一层新的信息，必须加以规定和跟踪。

IP集成并非半导体设计中最光鲜的任务，但通常是最麻烦的任务之一。在模块级验证与系统级交互的交汇处，缺陷往往非常难以发现。

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

这一理念是，每家公司应专注于开发设计中新颖独特的部分，加入自身专长，并允许其余部分由领域专家开发。

「十年前，一个设计可能只有几十个IP模块，」是德科技EDA的SOS产品经理Pedro Pires表示。「如今，一家公司可能拥有数千个IP，同一个IP可能有数十个不同版本，而你需要理解所有这些内容。此外，它们比过去更具可配置性。随着每个模块所需的数据数量和类型不断增加，要以临时方式管理这些内容正变得非常困难。」

这给验证带来了很大压力。「最棘手的故障几乎从不在单个模块内部，」Axiomise创始人兼首席执行官Ashish Darbari表示。「它们出现在模块之间——消息依赖死锁、缓慢泄漏的信用、被破坏的重排序缓冲区，以及跨桥被违反的顺序规则。每个模块都通过了自身验证，但系统仍会挂起，因为两个团队对同一条协议规则的理解略有不同。」

随着时间推移，跨IP问题的数量不断增加。「从SoC的角度来看，可能存在许多不同问题，包括地址映射、中断、一致性、QoS、安全，」新思科技HPC IP产品组合技术产品管理高级总监Madhumita Sanyal表示。「此外还有物理实现场景，例如用于降低功耗的动态电压频率调节（DVFS）。还有软件和操作系统交互。如果考虑裸片到裸片IP，则存在互操作性。还有已知良好裸片封装、信号完整性、电源完整性、供电网络、热耦合、遥测等等。」

虽然设计规模稳步增长，但仅凭这一点并不能作为复杂度的指标。「我可能正在设计一个有32核的大型CPU，但那只是同一事物的32个副本，」IC Manage首席执行官Dean Drako表示。「它可能带有巨大的缓存。那只是一个单元重复1亿次。复杂度并不总与芯片尺寸成正比。它们很复杂，但复杂度并未随芯片尺寸线性增长。人脑无法处理它。」

重要的是一个模块对周围环境做了多少假设，而这一数量增长远快于规模。「一个UART只需要时钟、复位和寄存器接口，差不多就是这样，」Axiomise的Darbari表示。「一个一致性缓存、一个CHI home节点或一个NoC则带有数百项假设。存在顺序规则、信用契约、未完成事务数量限制、复位和上电时序、地址映射预期以及安全属性。除此之外，还有配置参数，其效果往往无法通过数据手册完全说明。」

压力不断增大。许多领域加剧了集成压力，例如IP模块的规范撰写糟糕或不完整。在系统层面，软件复杂度不断提高，功耗和散热问题——尤其是与芯粒相关时——模拟内容增加，以及许可、地缘政治限制和出口管制带来的额外复杂性。这些内容将逐一简要提及。

不良或不完整的规范：规范众所周知难以做到无歧义或完整。「这些信息往往不足以准确呈现其在所有情况下的行为方式，」是德科技的Pires表示。「了解系统将在何种条件下运行可能会对你有帮助，具体取决于IP文档的质量。IP中可能包含与特定环境条件相关的信息，从这个意义上说，了解系统运行环境会有帮助，但也可能没有帮助。」

问题常在缺陷漏出时被发现。「架构师、设计师、软件团队、DV负责人和形式验证团队都会看着同一个故障，却看到不同内容，」Darbari表示。「没有人能就系统本应做什么达成一致，因为从来没有人以每个人都共享的形式把这些写下来。这些意见分歧从第一天起就存在。它们只是两年后才浮现，而且往往出现在后硅调试阶段，此时修复成本最高。」

软件复杂性：虽然一些软件完全封装并隐藏于任何外部接口之外，但许多并非如此。「即使像PHY这样简单的东西，也有大量软件内容，」新思科技的Sanyal表示。「有用于建立所有时钟、复位和内存的启动固件。然后，PHY具有校准固件，将进行初始校准和适配，并持续更新。该驱动程序需要与操作系统中断和DMA框架，以及PCI控制器等的BIOS、虚拟机管理程序或一致性或IOMMU依赖项连接起来。这些都将依赖关系扩展到拓扑之间的中断、操作系统服务和电源管理框架。」

这些问题十分棘手，以至于UCIe标准曾试图解决它们。「UCIe 3.0标准化了在初始化早期下载固件的方式，」Darbari表示。「问题在于，硬件往往只有在某些软件假设成立时才正确。例如，寄存器可能必须按特定顺序编程，或者在事务处理期间绝不能写入某个字段。这些规则很少被写下来，而RTL验证本身从不检查它们。」

硬件与软件之间的鸿沟很宽。「软件世界与硬件世界非常不同，这意味着硬件侧和软件侧由不同人员操作，」Pires表示。「这包括固件，以及深入绑定IP的软件。这两个团队的工作流程和节奏也不同。」

功耗与散热：控制功耗正成为更大的问题。「电源管理已成为一项功能特性，也是功能缺陷的主要来源，」Darbari表示。「每个电源域都会增加状态、转换、隔离和唤醒序列。一个模块在上电时可能完全正确，但当相邻模块在传输过程中下电时，它仍可能丢失事务或使握手挂起。像『如果该域在响应尚未完成时关闭，这个请求是否会丢失』这样的问题是典型的形式验证问题。仿真很少恰好落在出错的精确周期。」

功耗产生热量，热量又会改变敏感电路的行为。「随着功耗和散热如今决定SoC极限，模拟IP不能再被动地放在那里，」Agile Analog产品营销副总裁Chris Morrison表示。「我们必须对其进行设计，利用嵌入式PVT传感器、时序监控器、压降检测器和毛刺检测器主动管理芯片，并将实时遥测反馈给电源管理单元，以便在问题影响运行之前发现它们。」

模拟内容：模拟内容一直具有独特挑战。「这些IP的工作范围有限，而且非常针对特定用例，」Pires表示。「虽然AI在许多方面都有帮助，但我们看到，由于数据稀缺，创建用于加速RF和模拟设计的AI自动化面临重大挑战。要获得数量足够大、质量足够好的数据集来训练代理执行流程中的特定部分，并不容易。这些信息更定制化、更聚焦、更狭窄，而且往往是专有信息，我们无法获取使用。」

模拟模块创建者正在寻找将设计抽象到数字世界的方法。「客户越来越多地要求完整的模拟子系统，而不是自己处理十几个独立模块，」Agile Analog的Morrison表示。「在SoC层面用SPICE仿真大型模拟子系统耗时过长，因此可以通过用数字封装层包裹IP来简化验证。在内部完成繁重的混合信号工作，意味着数字SoC集成团队可以尽早采用SystemVerilog实数模型（RNM），并在其数字环境中运行全芯片验证。」

芯粒：芯粒可被视为IP的一种新的物理交付机制。「芯粒放大了这一问题，并使其也成为供应链集成问题，」新思科技系统解决方案战略项目执行总监Frank Schirrmeister表示。「你不仅有IP问题，还将设计边界从SoC边界提升到封装边界。现在，它把IP集成变成了供应链集成。你不仅在集成设计，还在集成可能来自不同公司、节点和晶圆厂的各个部分，而它们在IP层面都有自己的验证方法。」

这些集成问题都不会消失。「NoC如今正跨越裸片边界延伸，因此多个裸片看起来像一个互联结构，」Darbari表示。「UCIe正在很好地处理物理层和链路层，跨供应商互操作性也正在得到验证。但可用的链路并不等于可用的系统。你仍然需要在地址映射、一致性模型和软件上达成一致，而这些正是标准留给语义层面的问题。如今规范包括DFD、DFT和DFM，以及可管理性，因此芯粒开始不像被动模块，更像拥有自身管理固件的小型系统。」

芯粒需要比IP模块更多的信息。「现在有多物理场开始发挥作用，这意味着你需要关于所管理IP的大量更多信息，」Pires表示。「把所有这些数据放在一起正变得难以处理。这意味着随IP一起传递的复杂性更多。例如，电源意图需要作为额外交付物随IP一起传递。」

验证：对于IP，尤其对于芯粒而言，对模块的可见性使验证更加困难。「大型IP越来越多地以加密形式交付，因此你无法阅读RTL来弄清它真正期望什么，」Darbari表示。「你只能依靠文档，而根据我的经验，缺陷往往就在那里。这些模块还以生成器而非固定设计交付。供应商验证了某些配置集合，但你可能流片的是另一种配置。一旦参数超过少数几个，就很容易落入没有人测试过的组合。」

阅读全文，请访问：https://semiengineering.com/ip-integration-challenges-evolve/

来源: 海外媒体