来源：Astroys
Chiplet在美国国防部萌芽时期的一个早期概念是一个开放的市场。你可以从市面上现成的产品中购买所需的功能，将它们组合成multi-die组件，经过验证和分析后，就能完成硬件设计。后来的想法将这一设想进一步推进。如果你可以像搭积木一样，把chiplet简单地拼凑在一起，不需要复杂的EDA工具或分析，就能确保组合后的组件正常工作，那会怎样？
这将是极端的平等主义。几乎任何一个能够指定芯片平台行为的人都可以创建一个SiP设计，并由承包商进行组装。即使是没有芯片设计专长、只想完成小批量项目的公司，也能制造出复杂的芯片。
但今天，我们却看到chiplet应用正朝着相反的方向发展。大型GPU、数据中心CPU集群和其它大型项目，都是由资金雄厚的庞大设计团队开发的，使用的都是chiplet。最初的平等主义希望是否正在消失？还是一些技术问题仍有待解决？如果是，那么那些待解的问题是什么？
四大挑战
创建multi-die组件需要解决许多技术问题。其中4个重要题分别是：chiplet的功能；chiplet之间的互连；基板设计；热分析/机械分析。
先看下功能。我们可以想象一个巨大的在线chiplet目录，就像今天的可重复使用的芯片IP在线目录一样。你可以搜索目录，找到设计所需的功能模块，然后订购现成的chiplet。这听起来很简单。但事实证明，与芯片IP的类比很有说服力。
多年前，许多设计人员对芯片IP抱有类似的希望。你只需找到所需的模块，以RTL或硬宏的形式订购IP，然后将其集成到你的设计中。但很快人们就发现，虽然每个人都想要IP，但没人想要与别人完全相同的功能。A想要一个Arm内核，B想要另一种不同的Arm内核，而C想要一个特定配置的RISC-V内核。每个人都想要推理加速器，但需求都不一样。每个设计团队想要的接口、数据通道宽度、最大时钟频率等都略有不同。早期的IP供应商都经历过自己的产品目录在几个基本主题的基础上发生大量分散，以至于最后根本无法管理。
自然而然的解决方案就是使IP可配置。与其授权IP模块，不如授权IP生成器。你可以输入参数，生成器会输出IP模块，然后就可以将其纳入设计中。好像很简单。但是，可配置IP有两个隐藏的权衡因素。一个是灵活性与PPA（Power、Performance、Area）。在IP中集成的灵活性越高，就越要留意能效、速度或紧凑性。一个好的IP生成工具可以帮上忙，但这也会引发第二种权衡：灵活性与易用性。IP模块越灵活，正确配置就越困难。
用一位不客气的观察家的话说，人们很快就会发现，这不是在授权IP，而是在利用IP作为联合开发的诱饵。除了少数情况外，IP开发商最终都会与IP用户合作，共同选择IP、正确配置IP、将IP集成到芯片设计中，并成功完成设计流程。
Chiplet与芯片IP有很多共同点，因此可以遇见会出现类似的情况。但有一个主要区别，可以肯定的是，在设计初期，没有任何一家供应商会拥有一个设计所需的所有不同种类的chiplet。如今，一个普通的SoC使用40或50种不同的芯片IP的情况并不少见。而且，即使供应商有大致正确的功能，也很可能不是完全正确的功能。错误的接口、错误的时序、错误的布局等等。
但主要区别就在这里：chiplet不是一段RTL代码，而是一个成品die。供应商不能只是编辑一个文件或重新运行一个IP生成器，然后把新的RTL通过电子邮件发送给你。即使是很小的改动，也意味着要设计、验证和制造一个全新的die。前端成本很高，而且会延迟数月。
剩下的办法就是FPGA式的可配置性，在chiplet上使用可编程逻辑来改变接口、时序，甚至在某种程度上改变功能。但任何FPGA用户都知道，这种灵活性并不意味着逻辑可以随意改变。除了完整的大型FPGA外，再多的可配置性也无法将Arm chiplet变为RISC-V chiplet，或将CPU chiplet变为GPU chiplet。
Chiplet供应商很可能会遇到与IP供应商相同的问题：目录中永远没有正确的产品，永远没有正确的配置。本应是简单的现成的chiplet销售变成了联合开发。对于chiplet开发商来说，这是一个巨大的商业模式问题。
如果有一个丰富的供应商生态系统，对chiplet用户来说，这个问题就不那么严重。用户可以货比三家，直到找到自己想要的东西。但这也带来了一个先有鸡还是先有蛋的问题。如果没有供应商能够找到一个可行的商业模式，那么就不会有一个丰富的供应商生态系统。这种障碍多年来一直阻碍着芯片IP的发展，可以说正是IP产业由少数几家公司垄断的主要原因。
互联
下一个挑战是chiplet的互联问题。在某种程度上，业界已经在解决这个问题。UCIe和Bunch of Wires规范描述了chiplet间传输数据的高速PCIe接口。它们促进了电信号、格式和基础协议层面的兼容性。
但用一位业内专家的话说，它们虽然都是必要的，但还不够。它们的灵活性足以容纳许多不同的高层协议。因此，它们为PHY和MAC层以上的不兼容性留下了很大的空间。要实现快速组合、正确无误的互操作性，还需要更多的特殊性。
同样，问题在于每个设计都有自己独特的要求。有些设计可能需要以安全数据包的形式传输数据，而另一些设计则可能需要数据流。还有些设计可能需要符合现有的内存协议。有些信号根本不需要通过UCIe这样的高速串行连接来传输，只需将它们从一个die连接到另一个die即可。
更复杂的是，基板上chiplet间的互连与堆栈中chiplet之间的互连完全不同，后者有机会以更低的功耗实现更高的传输速率。
要实现快速组合的互操作性，就需要精确、通用地定义从物理层到应用层的各层，哪些协议将被哪些chiplet以何种方式使用。只有这样，才能确保将所选的CPU die与相应的加密引擎连接起来时，两者能够真正实现互联。
基板
所有这些问题都与基板有关，基板是安装chiplet的一小块电路板材料或硅片，chiplet之间通过基板连接。如果每个项目都要设计一个新的基板，工作量就会非常大。即使接口已经完全确定，还必须布置连接和选择机制（焊接凸点、铜柱、光学接口），以便将chiplet上的信号连接到基板上的导线或波导。必须对所有这些连接进行分析，以确定其电气特性，这种分析在某些方面比分析die上的互连更为复杂。堆栈中chiplet之间的物理连接可能完全不同于chiplet与基板之间的物理连接。
这么大的工作量几乎排除了任何快速组合设计的想法。光是设计基板就需要大量的工作和专业知识。而且基板价格昂贵。当今高性能multi-die组件中使用的interposer，每个批发价高达1000美元。这种interposer的来源也不广泛。
要解决这个问题，唯一明显的办法就是使用现成的基板，但数量有限。这些基板已经为chiplet设计了landing pad，并在垫片之间预设了互连。原则上，一旦基板设计完成并验证了最坏情况下的配置，就无需再进行设计和分析。但这也大大缩小了互连设计的选择范围。例如，一切都必须严格遵守UCIe的特定解释，包括最大频率、焊盘间距和最大通道数等规格。或者，可以接受CPU chiplet的landing pad可能必须在某一特定边缘上有一个专用的高带宽内存端口。同样，灵活性和设计工作量也要相互权衡。
热分析与机械分析
即使在电子设计完成后，仍然存在一些问题。由于其机械复杂性，基于chiplet的SiP需要进一步分析。这种分析的一个分支就是热分析。你必须确保在最坏的情况下，组件中的chiplet能得到足够的冷却，且它们不能在更敏感的元件附近过热。在包含HBM（high-bandwidth memory）芯片的组件中，这已经成为一个问题。与逻辑芯片相比，HBM芯片的工作温度范围较窄，一些设计发现，当CPU chiplet正常工作时，其附近HBM chiplet堆栈的温度会超过其工作温度范围。
机械性能也很重要。在现实世界中，振动、不均匀加热或其他原因造成的机械应力会使multi-die组件弯曲。显然，组件中的元件必须具有类似程度的挠性，这样才不会损坏脆弱的铜柱、微小的金属凸点、易碎的焊球甚至屑片本身。这需要逐个分析。
最初的愿景已死？
考虑到所有这些问题，最初的“快速组装、无需设计的SiP”愿景真的能实现吗？显然，我们面临着巨大挑战，但也许答案仍然是肯定的。Chiplet和接口种类过多的问题即使不能解决，也可以通过缩小问题的范围来解决。例如，专注于一个特定的应用领域（例如视觉处理芯片）来限制chiplet、总线和架构安排的种类。至于这种专注是否会带来足够大的市场总量，足够让企业得以生存，还是个未决问题。
要解决所需分析过多的问题（系统级时序分析以确保所有信号在chiplet间的传输速度足够快、功率分析、故障覆盖分析以确保整个组件得到充分测试、热分析和机械分析），可以通过限制基板上chiplet配置的种类来解决。例如，可以只提供几种预配置基板，并大量使用可编程逻辑。然后，对可能的配置进行最坏情况分析，提供工作极限。这样，任何允许的chiplet配置都能基本保证正常工作。当然，这样做会放弃一些能效、性能和密度，但可以从设计中省去很多分析工作。
因此，如果设计对PPA要求不高，快速组合式解决方案似乎是可行的。Chiplet和基板供应商需要做大量的前端工作。事实上，这种方法可能会导致单一供应商来提供chiplet和基板。而且，这还需要一些细致的规划，以评估市场细分是否有足够的限制性，使这种方法能够奏效，但又有足够的丰富性，使其有充分的利润空间。只有非常大的供应商，例如EDA公司或政府实体，才可能有这样的资源来投资于这种高风险的提议。
因此，最终的答案是，技术上是肯定的，但商业上只是一种可能性。
本文转自：Astroys，转载此文目的在于传递更多信息，版权归原作者所有。如不支持转载，请联系小编demi@eetrend.com删除。
