原创 NoC 互连入门

作者： Benoit de Lescure

以前的博客文章讨论了片上网络 (NoC) 互连相对于交叉开关(crossbar)互连的优势。 如果那些想法听起来很有趣，那么 SoC 团队应该如何评估 NoC 是否符合后续产品的目标？ 或许在当前设计中有困难的时序收敛问题，在下一个设计中预计会更糟。 这可能是尝试不同方法的一个很好理由。反过来说，这种改变可能会有什么风险？ 设计师是否需要在架构或实施方面进行专业再培训？ 工程师如何量化对当前架构的改进？ 有哪些选项可以用于管理后期时序问题？ 本文简要回答了这些问题。

首先，构建 NoC 与构建crossbar没有什么本质的区别。 NoC 只是提供了更大的灵活性，因为它在整个网络中使用一种通用协议以及基于数据包的交换。 这种方法消除了复杂的交换树和协议桥。 在 NoC 中可以插入时钟和电源的域交叉点，而不需要进行分区。 

因此，在试验设计中，没有必要重复在基线中或以前生产设计中使用的互连分区。 最好是构建 NoC 来满足设计的系统需求，例如分隔安全域或构建可重复使用的子系统，而不考虑先前的基于总线或基于crossbar的互连结构。 换句话说，在实施 NoC 技术时，您应该从 SoC 的要求出发，而不是 “调整修改”先前的基于crossbar的实施。

从平面图开始。 这似乎有点落后，但 NoC 的一个重要优势是面积效率。 此外，当从早期设计开始时，它使评估更容易。可以将平面图导入 FlexNoC 工具，以试验布线拥塞情况，并为高带宽低延迟的路径和性能未受限制的窄通道配置宽通道。还有一个自动管道选项，当路径上时序要求无法满足时，该选项会沿着互连路径自动添加管道（也称为寄存器片）。 这些实验应该开始提供一些指示，说明基于 NoC 的平面图和时序收敛将如何进展。

平面图试验: 左侧是基于crossbar的互连设计，表现出严重拥塞。 右侧是基于 NoC 的互连设计，更有效地利用区块之间的空间并使拥塞最小化。

一旦建立了一个初步的NoC结构，就可以通过对其进行调整以满足服务质量（QoS）目标。执行此操作的快速方法是使用NoC互连IP生成器输出的SystemC模型，以及IP供应商提供的初步定时或周期精确的模型（Arteris IP也提供模型），以针对QoS指标对网络进行调整。也可以在仿真中运行试验以获得最大的准确性。

在基准试验中可能考虑的其他选项包括：将一些通信通道串行化，以降低芯片上长时间运行的拥塞，试验可编程选项（来自软件，每个主控）或使用可以插入网络接口单元的调节器来引导首选带宽。

此时，RTL设计已经准备好开始真正的实施，以准确评估拥塞和时序收敛。

对任何生产设计团队来说，重要的是 NoC 在他们的设计上带来的结果，而不是营销文献所说的内容。第一个也是最明显的结果是面积缩减。与基于crossbar的同类设计相比，预期网络面积会缩小 30-40%。

QoS可能有点难以比较，但一个正确配置的基于NoC的实施方案至少应该能与基于crossbar的设计实现同样的带宽和延迟目标。

对于采用 NoC 技术的团队来说，实现时序收敛的简便性和快速性是一个主要卖点。评估基准无法模拟生产计划中发现的所有复杂情况。尽管如此，即使允许在评估上有一些偷工减料，时序收敛的速度也应该大大加快。

任何使用情况下的平均功率都应该更低一些（因为FlexNoC的网络元素很小，而且布线应该更少）。如果基于NoC的设计允许在网络内断开电源，那么平均功率应该会更低。

下一篇博客：如果一个设计需要管理高速缓存一致性，如何通过NoC来实现这一目标？