使用统一的 RTL-to-GDSII 产品更快地实现更佳的结果

由于在逻辑阶段和物理阶段内需要进行太多的迭代，并且逻辑阶段和物理阶段之间也要进行太多的迭代，因此设计时间（实际工程花费的时间，即工程需要设计人员进行权衡和折中以优化架构的时间）被迫缩短了。

逻辑阶段对物理阶段的数据一无所知，而物理阶段对逻辑阶段的数据也是一无所知。这就对 TTR 造成了影响。

在传统流程中，收敛之所以如此棘手，主要有两个原因。

由一个工具创建并由后续工具使用的数据，通过文件传输进行传递。前者提取了可能存在于内存中的大量数据，以便仅将必要的部分传递给下一个工具。这是一个效率问题，事实上，点工具必须传递特定的文件格式。这意味着每个工具都只能访问传递给它的文件中的数据。在某一点上可能存在许多其他有用的数据，但是如果不包含在文件中，那么就不能用来获得更好的下游结果。

逻辑阶段和物理阶段都有在自己的阶段内提供收敛的引擎。例如，综合工具会有一个计时器、一个寄生参数估计器/提取器，或具有合法化器的定位器，以及全局路由器或拥塞建模器。物理级别的布局和布线则会有自己的此类引擎版本。但是每一组工具由不同的团队创建，每个团队都是自行决定在传输文件中提取哪些数据。因此，操作方式虽然相似，却并不完全相同。这些差异可能导致在阶段内部和阶段之间产生额外的迭代。每一套工具本身都非常好用。只是难以相互协作。

使用统一的数据模型

针对这个问题，我们做出的第一个重大改变是使用单一数据模型。无论是逻辑模型还是物理模型，在任何时候都对所有工具可用，无论是逻辑工具还是物理工具。这意味着逻辑引擎可以从物理参数中获得一些线索来改进它们的结果；同样，物理工具可以从设计过程的早期挖掘架构和逻辑意图，从而交付更好的整体解决方案

一个特别有趣的情况是在设计过程的早期阶段，我们正在进行层级规划或评估总体设计的“可实现性”；如能获得目标流程的物理信息，就意味着我们可以创建一个更好的高层布局，一个可以考虑到流程物理特征的布局。在我们继续推进流程时，这个早期的布局自然会得到改进。

另一个例子是时钟综合。由于 ARM 架构依赖跨逻辑分区的周期借用，诸如并发时钟和数据 (CCD) 优化之类的新技术，在高效闭合服务器级 ARM® 内核时至关重要。如果不了解要使用的时钟和数据驱动程序，就无法有效地完成。这就是逻辑阶段所需的物理数据的一个范例。如果没有这些特定的数据，这些工具将不得不对时钟驱动程序的潜力及其隐含的拓扑结构做出假设。如果经过证明，这些假设与实际相去甚远，我们将不得不回到之前，重新规划甚至重新构建整个 CPU 子系统。

统一的模型和流程促进产生更好的结果

采用这种方法设计出来的结果令人鼓舞。例如：

• 在 7 纳米节点上的数百万个实例设计减少了 10% 的漏电、10% 的总负余量 (TNS)、5% 的动态功耗和 3% 的面积。
• 在 7 纳米节点上设计了 400 – 600 万个实例，也节省了 6-8% 的功耗，并且 TTR 降低了 40% 以上。
• 在一个 16 纳米节点上拥有 200 – 500 万个实例的模块减少了三分之一的最差负余量 (WNS)，时序违反路径总数 (NVP) 也减少了一半。面积缩
• 超过 10%，而且集成门控时钟的数量和逆变器/缓冲器的数量也明显下降。TTR 缩短了 90%。
• 在 28 纳米工艺中拥有 200 – 700 万个实例的模块，其 WNS 和 TNS 减少了一半，面积减少了 10%，标准 VT 晶体管数量减少了 30%，换来了节能 7% 的高 VT 晶体管 (pre-CTS)。
• 设计 500 – 1000 万个实例可节省 22-37% 的功耗。
• 一个 ECO 操作的时间从 2 周减少到 1 天，ECO 迭代的数量从 12 减少到 0，并且在不降低结果质量的情况下减少了 2% 的实例。

当然，这其中的一些成就得归功于对特定工具的改进。但很大一部分的这些改进都是由于，仅仅由于，统一的数据模型使每个引擎都可以访问所有内容而取得。

从异构的整合数据模型组转变为单一的统一模型，并在统一的 RTL-to-GDSII 流程中使用单一的引擎组，可能会对 TTR 和 PPA 结果产生重大影响。获取所有数据，使得算法可以变得更加有效。由于逻辑和物理结果之间具有良好的相关性，迭代可以显著减少。

如果我们缩短通过流程管理设计所花费的时间，就可以加快上市速度。同时，我们也可以多花时间去优化结果。我们甚至可以同时实现这两个目标：更快地推出更具竞争力的产品。这也是设计师们最终想要并且应该做的事情。