IP集成难度攀升：模块数量与配置复杂度成验证新压力

IP集成在半导体设计里不算最受关注，却常常最难对付。模块级验证与系统级交互碰在一起的地方，缺陷往往藏得很深。

1996年

这套思路是让每家公司只管开发设计中真正新颖独特的部分、拿出自己的专长，剩下的交给领域专家去做。

Keysight EDA 的 SOS 产品经理 Pedro Pires 提到，十年前一个设计里或许只放几十个 IP 模块；到了今天，一家公司手里的 IP 可能多达数千个，同一个 IP 还衍生出几十种版本，这些信息都得厘清。他说，这些 IP 的可配置程度也远非过去可比，每个模块涉及的数据量和数据类型都在涨，再靠临时应付的办法去管，难度已经很大。

验证因此承受着巨大压力。Axiomise创始人兼首席执行官Ashish Darbari表示：“最严重的故障几乎从来不会发生在单个区块内。它们出现在区块之间——

跨IP的问题数量随着时间推移不断攀升。从SoC的角度看，牵涉的问题可能很多，地址映射、中断、一致性都在其中，

IC Manage 首席执行官 Dean Drako 表示，设计尺寸的确在一点点变大，但尺寸本身并不能说明复杂性。“我可能在做一颗 32 核的大型 CPU，可它不过是 32 个相同单元的复制；也可能配一块很大的缓存，那也只是同一个单元重复了 1 亿次。复杂性未必与芯片尺寸成正比，它们确实复杂，但这种复杂并不会随着芯片变大而线性上升。这么庞大的数据量，人脑是处理不了的。”

真正要看的是一个模块对周边环境做了多少假设，而这个数字涨得远比模块自身尺寸快。“一个

集成压力越来越大，好几类因素又在加剧它，比如IP模块规范写得不完善或不完整。到了系统层面，软件复杂性持续上升，功耗和散热问题也越发突出——芯片组集成、模拟电路含量增加，以及许可、地缘政治限制和

规格说明写得糟糕或者不完整：要把规格说明写清楚、写完整，本来就很难，这一点业内已有共识。是德科技的 Pires 说：“信息常常不够完整，你没法据此准确判断系统在各种情形下如何运行。弄清系统运行的条件或许有用，但这要看你的 IP 文档质量如何。IP 文档里可能写着与特定情形有关的信息，从这个角度说，了解系统运行的条件会有帮助，但也可能帮不上忙。”

问题常常要等漏洞暴露出来才被发现。“架构师、设计师、软件团队、设计验证负责人和

软件这块的复杂性同样不小。有些软件做了完整封装，外部接口一概不露；可大量软件并不是这样。“即使是像

这类问题之棘手，让硬件和软件之间的落差相当大。皮雷斯说：“软件世界和硬件世界截然不同，这意味着负责硬件的人员和负责软件的人员完全不同。”“这包括固件，以及与知识产权紧密相关的软件。这两个团队的工作流程和工作节奏也截然不同。”

电源和散热这块，电源控制正变得愈发棘手。Darbari 说：“电源管理现在既是一项功能特性，也是功能性缺陷的主要来源。”“每增加一个电源域，就会多出状态、转换、隔离和唤醒序列。一个数据块在通电时可能完全没问题，可要是相邻数据块在传输途中断了电，交易照样可能丢失，握手也会中断。像‘响应还没完成时某个域断电，这个请求会不会丢？’这种问题，就是典型的形式化问题。仿真很难准确抓到出错的周期。”

功耗上去，热量就跟着来，敏感电路的运行因此受到牵连。Agile Analog 产品营销副总裁 Chris Morrison 说：“功耗和散热如今已经卡住了 SoC 性能的脖子，模拟 IP 不能再被动运行了。”“必须主动去管它。嵌入式模拟内容面临的挑战一直很特别。”Pires 表示：“这些 IP 的应用范围有限，而且高度针对特定用例。”“人工智能在很多领域都派上了用场，可数据稀缺让加速射频和模拟设计的 AI 自动化很难做。要凑够高质量数据集来训练智能体、让它执行流程中的特定环节，并不容易。这类信息更定制化、更聚焦、也更窄，往往还是拿不到的专有信息。”

搞模拟模块设计的人，正琢磨着把设计抽象到数字世界里。Agile Analog 的 Morrison 说：“客户越来越想要完整的模拟子系统，而不是费劲去对付十几个独立模块。”“在 SoC 级别用 SPICE 仿真大型模拟子系统太耗时间，所以用数字封装把 IP 隔离出来，验证流程就能简化。繁重的混合信号处理在内部完成，数字 SoC 集成团队就能尽早用上

Chiplets 可以看成 IP 的一种全新物理交付方式。“Chiplets 放大了这个问题，并将其升级为

集成上的老毛病一个都没少。Darbari 说：“片上网络（NoC）如今跨出了芯片边界，多颗芯片看起来就像一个整体。”“UCIe 在物理层和链路层处理上做得不错，跨厂商互操作性也已经得到验证。但链路能用，不等于系统能用。地址映射、一致性模型和软件，这些还得谈拢，而它们恰恰是标准还没解决的语义问题。规范现在要求的信息，比 IP 模块那会儿还多。”Pires 说：“多物理场效应开始起作用了，这意味着你对自己管理的 IP 需要掌握更多信息。”“把这些数据拢到一块儿，管理起来非常难。这意味着 IP 会变得更复杂。比如电源意图，就得作为额外组件随 IP 一起传。”

验证环节，对 IP 尤其是芯片组来说更难做，因为模块内部结构没法直接看。Darbari 说道：“大型 IP 越来越多地采用加密方式交付，因此你无法读取 RTL 代码来了解其真实需求。”“你只能依靠文档，而根据我的经验，漏洞往往就藏在文档里。这些模块通常以生成器的形式交付，而非固定设计。供应商验证的是某些配置，但你实际流片的很可能是另一套配置。参数众多时，很容易出现未经测试的组合。”

也有好的一面：知识产权的功能并非全都要验证。Sanyal 说：“把合法的功能子集识别出来，是一项架构和验证任务。”“这事没法一劳永逸，也不能自动化。验证方面，我们现在和客户都在用人工智能模型，处理那些特殊情况比过去快多了。关键还是得往验证环节里扎。”

很少有第一次就把事情做全的，初版发出去之后，漏洞得一个个补。IC Manage 的 Drako 表示：“非人工智能版本的关键是知识产权生命周期管理。有了人工智能，周期可能更快，但这些生命周期照样得管。你也可以让人工智能替你干这部分活，不过前提是数据和系统都在，能追踪得起来：哪些流片做完了、哪些产品开发了、哪些知识产权用在了什么地方。”

硬件与软件的交付节奏、更新周期并不一致。Darbari 提到：“现场固件更新可能会改变芯片在验收完成后的运行方式。”他还说，中断、电源状态、DMA缓冲区和安全属性由硬件和软件共用，冲突常常在启动阶段冒出来，原因是第一个真正运行的驱动程序会执行一段没人明确指定过的序列。

两边的版本控制手段往往也不一样。Pires 表示：“挑战在于如何将所有这些数据集成到一个系统中。”他接着说，某个版本的硬件要对应某个版本的软件，这种对应关系平常就躺在 Excel 表格里，乱且容易出错。集成系统时，配置本身要管，比如特定系统的物料清单，还有系统里组件的具体搭配；每改一次，都得把改动记下来，保证可追溯。

看起来，这个麻烦正在变得越来越让人头疼。不过 EDA 领域多数问题都是这样：事情越严重，得到的关注就越多，投入上去，最终会换来更好的办法。

皮雷斯说：“管理问题日益严重，但解决该问题的机制也在随之发展。相对而言，痛点依然存在，但其背后的问题却更加严重了。”

本报告第二部分将讨论近来的改进，以及怎样用人工智能改善 IP 的挑选、配置与集成。