面向有挑战性功能块的时序收敛技术

在一个真实案例中，路径有这样需求：
1.在最差情况（wc）中，路径延时少于2.5ns(建立)
2.在最好情况（bc）中，路径延时多于1ns(保持)

但实际延时是：
1.最差情况（wc）中延时为2.1ns。
2.最好情况（bc）中延时为0.8ns。

因此路径满足了建立需求，但却造成了保持违规。

想象一下通过改变单元（减少尺寸、插入、交换）来修复保持违规，多数延时变化只发生在单元上。到时将发生以下情况：
1.将保持延时从0.8ns修正为1ns，测试案例中延时提高了0.2ns。
2.使用只针对单元（cell only）方法，如：插入缓冲区、减少尺寸。如表3所描述，它给最差情况中单元延时带来的改变是3倍，即0.2ns * 3 =0.6ns.
3.最差情况中延时从2.1ns提高到2.7ns，造成建立违规

2个角点间单元延时变化很大，因此如果设计师只盯着单元，而靠路径本身解决冲突根本不可能。

根据测试电路结果，线路延时在不同角点下延时差异更小，因此如果使用线路延时来修复保持违规，最差情况（wc）中延时的反弹也不会这么大。最好情况中0.2ns的线路延时增长将只会带来最差情况中0.24ns延时，因此最差情况中总延时为2.1ns + 0.24 ns = 2.34ns。这种方法可兼顾建立和保持时序两方面需求。

以下是一些有关‘如何使用线路延时优化来修复时序’的详细内容。

以保持修复为例。第一步就是要识别一组带有这类建立和保持冲突的时序路径。这类路径可通过初步时序优化或通过项目约束文件来获取；然后我们就可分析这些候选路径并选择真正目标。

第二步就是进行详细时序分析并开始时序修复，它包括：
1.插入延时单元并手动将它们设置在版图中。
2.决定单元和模式和尺寸，确保无转换违规。
3.评估线路延时。如布线形状良好，那么实际延时与评估结果间差别将不会太大。
4.采用talus在布线后分析时序结果。如还有时序违规，尝试使用有用偏斜来修复。
5.如它们不能通过有用偏斜修复，那么回到步骤1或2开始新一轮修复工作。

设计师可能需要几轮的这类修复工作才可完成时序清理。融合速度取决于线路延时评估精确性和实际布线形状。.

实施步骤虽简单，但在实施过程中设计师可能仍会遭遇到一些问题。其中之一就是，实际线路延时值与原始评估值差异相当大。如果差异是由不好的布线形状所造成，那么设计师可打开Talus volcano并以交互方式修复它们。通常，有两种不好的布线形状：jog（割阶）和绕障（detour）。对于割阶，它可通过Talus命令：“run route optimize jog …”或“run route refine model –type jog…”来去除。

对于绕障，它通常出现在资源不足的后布线阶段一些线路布线的时候。一种解决方法是：先在一个已布局却未布线的volcano中单独进行这些线路的布线；接着将它们加载回到后布线volcano中。设计师可选择性地设置这些线路为软或硬的预布线，以便他们在布线引擎尝试解决布线DRC时不会有太多的割阶。此外，你还可设置首选层，这样主要线路的布线工作可在资源丰富的层中完成。

另一个可能问题是：恶化的耦和时序。这通常发生在一群总线信号单元相互布局紧密的时候，它们拥有到同一个方向的相似连接。连接这些单元的线路布局非常紧密，有长距离地并行布线。这些线路中每一条都是到其它网路的一个聚集器，同时也是一个牺牲品。这会导致严重的耦和时序违规。解决这类问题的关键是在完成线路修复后尽可能早地输入耦和问题，否则它会在设计后期将带来非常大的麻烦。通过控制布线形状可很轻松地避免耦和时序恶化，如：使用多间距、添加屏蔽或在不同层进行它们的布线。

如采用线路延时进行多轮修复后，时序冲突仍未解决，那么建议检查一下原始约束是否合理，是否有缓和约束的空间。约束变更会有进度延时和项目失败的风险，因此设计师必须确保在项目一开始就尽其所能地检查出更多的潜在问题，建立合理约束。

总结

有挑战性功能块总是需要非同一般的方法才能让其时序回归正常。这些方法虽是利用了现有Magma Talus功能，但并不局限这些功能，对功能及功能的使用都进行进一步扩展。上文中这4种方法是虽然是要耗费些精力，但与后布线阶段的时序修复所需耗费精力相比，还是值得的。