面向有挑战性功能块的时序收敛技术
发布时间：2010-10-15 19:48
发布者：techshare
|
第I章：介绍 物理设计中，时序收敛一直是个问题，解决这个问题的方法多式多样。本文将探讨几种可帮助尽早检测到可能要在非常晚期设计阶段才会出现的问题以及降低正常P&R阶段TNS（负余量总和）的方法。这些方法以Magma Talus现有功能为基础，但功能的使用有经过进一步扩展或是重新考量。 第II章：绕障I/O密度地图 随着芯片规模的日益壮大，层次化设计正逐渐成为许多芯片设计的一种常用方法。在层次化设计中，最高层设计师（top level designer）会将整个芯片划分为多个小块。每个小块作为一个独立功能块，将贯穿整个物理设计流程，最后再由最高层设计师将这些小块集成为完整芯片。这样一来，集成的时候块边界难免会有时序和布线问题。通常，这些问题的修复技术是要落实到功能块上，将由块设计师（block designers）应用以进行修复工作。 在一些案例中，功能块设计师将发现很难在布线后晚期阶段修复这些边界问题，这会导致项目进度大大延迟。 图1是一例这种问题。在功能块左上角有个大型宏，它占用了许多布线层，在其周围区域造成了非常高的拥塞情况。图中加亮线是贯穿这个区域的一条路径，中间插入了几个缓冲区。有几点应多加注意： 1.这条路径是往下走的，因为在大型宏的北面没有足够空间用于缓冲区、没有足够导轨用于布线。 2.线路中间部分由于高度拥塞布线而呈割阶状态。 3.很难这个宏旁边找个位置插入新的缓冲区以修复转换和建立违规。  图1 上述第1点和第2 点是导致最高层时序差的罪魁祸首，第3点则是导致这个问题难以修复的原因所在。布线后功能块层中内部状态对于时序和布线来说还是很不错的；但当最高层设计师开始修复这个时序问题后，插入了许多单元，布线也发生了很大变化，这些均使得内部时序和布线变得更为糟糕且难以融合。 原因相当简单：没有足够资源可留给最高层设计师来修复这个时序问题。但如何才能让块设计师知道他需要在哪里保留资源和保留多少资源呢？功能块设计后内部时序和布局很不错，这时要假设将会有问题时真得特别困难。 通过分析具有类似问题的一些功能块后，我们发现了几个能反映最高层设计潜在困难的指标，比如：边界网路绕障严重程度。绕障（Detour）虽可在一定区域实现好的DRC（设计规则检查）数目，但这好DRC背后却隐藏着问题。对于拥塞严重的区域，时序水平一直在降低，新插入的单元先是会让好的布线变差，然后还会变得不可布线。 为了评估边界网路绕障严重程度，设计师首先要计算这些网路的密度，接着再以颜色直观显示其严重级别。这个过程分为5个步骤：
关键是第4步，它意味着最高层修复工作哪里将存在潜在困难。每个步骤的详细内容如下所述： 步骤1 首先，你可将每个边界分为多个小段；可基于个人喜好，设50um或100um作为一段长度。其次，计算出每小段中所有非PG（non-PG）引脚数量，基于每段中引脚数以不同颜色来加亮这些片段；为每小段选择适当颜色阈值很重要，因为它直接影响到你对一个区域是否具有高引脚密度的印象。设计师可基于之前项目经验来设置颜色。你需要将所有信号引脚层、类似模拟的特殊引脚层都计算在内，但电源引脚除外。可视部分可以通过命令“ui layout sketch line …”绘制，而所有其它部分则可通过自带Tcl来完成。  图2 步骤2 步骤2中显示了在一些区域里I/O引脚密度高，那么我们需将存储器从高密度区域（白色区域最高，红色区域其次）移出。 步骤3 完成布线后，接下来是要找出所有连接I/O引脚的绕障网路。判断一个网路是否是绕障网路，可通过对比网路线长与其所连接引脚的曼哈顿距离（Manhattan distance）来完成。设计师可依据个人需求来设置20%或30%作为阈值；当然若能设置最短长度就更好了，这样就可忽略不计比它更短的网路；若没有这个设置，设计师将会看到许多短的“绕障”网路，而实际上这些都是错误警报。 在测试功能块中，1对1连接占了绝大部分。基于这点，作者假设忽略多连接网路不会对最终结果有任何影响，因此此次demo只计算了一个输入一个输出的网路，大大简化了计算脚本编写。当然，这种假设还需要经过其它设计的验证。 这次计算将产生一张所有绕障I/O网路名单。不过，如果直接就加亮所有这些网路（如图3），设计师几乎说不出哪里布线真的很差，哪里还不错可以继续当前布线。 图3中上区域看起来最为拥挤，但事实上，它既不是根源所在，也不是最关键区域。我们需要以另一种可直接反映问题所在的方式来提供信息。  图3 步骤4 我们可对步骤1中加亮I/O密度的脚本进行修改，用于加亮绕障I/O密度。当将一个网路分为多个小段的进行计算时，首先要在已发现的绕障网路名单中进行过滤，且只计算名单中有的那些网路。由于过滤后引脚数将会大大降低，因此设计师需要调整每个分色的阈值。最终结果见图4。 步骤5 图4证明了白色区域具有最多绕障的I/O网路。这建议我们： 1.移动大型宏，这是块设计师可执行的最直接动作。 2.最高层分配引脚时降低白色/红色区域的引脚密度，这需要最高层设计师与功能块设计协作进行。 通常，这些大型宏被设置在那个地方肯定有其原因存在，因此在一些实际项目中重新分布模型引脚这种方式要更为切实可行。  图4 这只是“如何将我们的经验转换为可视化检查”的一个例子。设计师不仅可对这种绕障I/O进行可视化处理来作为潜在问题预测指标，而且还可根据已经过证明的设计相关经验，将其它因素加入到可视化检查中来。 第III章：时钟门控克隆阶段选择 一般来说，执行时钟门控克隆一共有2个阶段：fix cell（修复单元）和fix clock（修复时钟）；设计师还可同时在两个阶段进行克隆。因此在此提出了3种组合： 1.只fix cell阶段克隆 2.只fix clock阶段克隆 3.两个阶段同时克隆 如果是只fix cell阶段克隆，那么设计师可采用命令“run clock gate_clone”在第一次全局布局/布线后执行克隆；相关配置可通过“force clock gate_clone”命令来完成。不过完成克隆后，‘force clock gate_clone’设置的约束将变为无效；如再需要fix cell阶段克隆，那么设计师还要重新应用这些设置。 作者以几个功能块为例，对这3种方法进行了一次测试，通过比较结果来找出适合其中多数功能块的最佳方案。 表1  表1是测试结果，要点如下： 1.黄色数据是一个功能块的最好TNS，绿色数据是最佳区域。 2.第2种方法带来了适合大部分案例的最佳结果，包括最好TNS和最佳区域。 什么样差异会导致这样的结果？图5是功能块一个角点的时钟门控单元分布：  图5 粉色单元是门控单元；黄色单元是时钟树缓冲区；线是时钟树飞线。 3个图片为： 左：第1和第3种方法的fix cell阶段。 中：第3种方法中的fix clock阶段。 右：第2种方法中的fix clock阶段。 图5显示的是：无fix cell阶段克隆，时钟门控单元少了许多，但时钟缓冲区却多了许多。原因之一是：CTS将门控单元后时钟树往上移动，因此对克隆的需求也减更少发。 进一步研究我们又有了其它发现，这可能是对‘为什么第3种方法门控单元更少’的另一种解释。见图6：  图6 图6是2张fix cell volcano中门控单元分布连接图。图中所显示的只有触发器（flops），其它模式单元则是隐藏的。左图无克隆，右图有克隆。左图中，所有连接资源都来自时钟树根；右图中，功能块有明显克隆过的门控单元树结构。 图6显示了一个有趣的地方：如没有fix cell阶段门控克隆，触发器的布局会更为紧密些。这已是对许多案例观察的结果。一种可能解释 是：由相同原始门控单元所控制的触发器在布线期间有直接连接，因此相比那些由于门控单元不同而中断连接的克隆试验，它们的布局更为紧密。 图7是 fix clock volcano中时钟门控单元分布图：  图7 与之前案例一样，若无fix cell阶段克隆，所需时钟树元素将更少。在这个案例中，出于触发器布局更紧密的原因总负载更低，因此所需的门控单元/时钟树元素更少。 在那些测试案例中，第2种方法的门控单元数量要比第1和第3种方法少了30"50%。尽管第2种方法需要在门控单元后创建时钟树，但门控单元面积的降低是创建时钟树这种额外面积所无法比拟的，因此最后总面积的赢家是第2种方法。 从时序角度来看，如果触发器间连接不太复杂，那么在第2种方法中触发器布局更紧密的设置将有助于降低路径上负载，进而在统计时获得更好时序，这是实际设计中最常见情况。 通过比较这些方法来找到一个最好的时钟门控克隆方式的想法源自于一个真实案例。在这个案例中，时钟的时序非常棘手，带有高度复杂的组合逻辑。上百个最高失效端点都是门控单元使能引脚，导致了“门控克隆需针对这个功能块进行优化”的想法。这个功能块的最佳结果是只fix cell阶段克隆、无fix clock阶段克隆。后布线优化图可获得超过50ps的更好结果。原因之一是fix cell阶段克隆将会在这个阶段更早期就暴露出使能引脚相关违规，那么Talus就可更早地对它进行优化。 第IV章：多轮Fix Cell 布局是一个融合过程。运行的布局轮次越多，可获得融合度就越好，但这是以时间和磁盘空间为代价的。设计师不仅可尝试多运行几轮以获得最佳结果，同时还可拥有有关“如何运行每轮fix Cell”的不同选项。本章将探讨3种每轮fix cell运行的方式并比较时序和拥塞。选项有： 1.使用fix cell阶段中‘-iteration #’选项 2.直接在之前fix cell数据库上重新运行fix cell 3.采用之前fix cell网表，基于修复时间、修复计划和修复单元开始重新运行。 第1种方法是最直接方法，易于运行。第2种方法需要明确大部分fix cell快照以便能在未来运行中跳过细节步骤。第3种方法需花更多时间和精力；但如果fix cell期间网表变化很大，那么第3种方法效果最好。 我们选择了几个功能块来测试这些方法，表2是几个功能块的数据。从时序角度来看，结果并不倾向于中意其中任何一种方法；从拥塞角度来看，第2种方法在绝大部分案例中胜出。 表2  ‘拥塞’项目系指fix cell 数据库中‘report congestion $m’的总数。第2种方法可更好处理拥塞热点。请比较图8中拥塞地图，结果更一目了然：  图8 在实际项目中，设计师需要权衡考虑每轮的运行时间及可获得的改善。你尝试得轮次越多，你可获得的效果就越好，但设计进度毫无疑问会被延迟。对于容易功能块，设计师可通过单轮fix cell摸索着运行每个步骤，不需要考虑时序/拥塞问题；对于关键功能块，2"3轮的fix cell将可带来明显的拥塞和时序改善。 对于一些特殊案例，设计师可能要在全局布局后fix cell期间添加大量逻辑。而这些逻辑可能有糟糕的拥塞问题，第2轮的增量全局布局并不能很好地处理这个问题。在这种情况下，第3种方法是3种方法中唯一能起作用的方法。 如果采用第2种方法，设计师需要考虑‘需保留什么快照’‘需清除什么快照’；而且一些步骤可能只运行一次，在其它轮的fix cell中将不再运行。 当资源成本在可接受范围内时，设计师应尝试对设计进行多轮的fix cell，它可与新平面布局试验同步进行；与调整平面布局对比，它所消耗的人力几乎可以忽略不计。在这些方法中，从拥塞角度来看，我们建议你直接在之前数据库上运行fix cell；若在特殊案例中，设计师应尝试第3种方法。 第V章：采用线路延时解决多角点下时序冲突 在许多设计中，设计师常在一些时序路径上设置大的建立容限和保持容限以避免意料之外情况下时序失效，但它可能会给时序收敛带来麻烦，特别是在深亚微米工艺中更是如此。采用单元尺寸调整、缓冲区插入/去除等常规方法有时不能同时清理最佳情况（bc）角点中保持时序和最差情况（wc）角点中建立时序。这种冲突会反复发生，使得时序无法融合。 我们常规的时序修复方法主要针对的是标准单元。而在深亚微米工艺中，不同时序角点的标准单元延时有很大差异。表3显示了测试电路的wc和bc角点中标准单元和金属线路的延时差异比较： 表3  在一个真实案例中，路径有这样需求： 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种方法是虽然是要耗费些精力，但与后布线阶段的时序修复所需耗费精力相比，还是值得的。 图1是一例这种问题。在功能块左上角有个大型宏，它占用了许多布线层，在其周围区域造成了非常高的拥塞情况。图中加亮线是贯穿这个区域的一条路径，中间插入了几个缓冲区。有几点应多加注意： 1.这条路径是往下走的，因为在大型宏的北面没有足够空间用于缓冲区、没有足够导轨用于布线。 2.线路中间部分由于高度拥塞布线而呈割阶状态。 3.很难这个宏旁边找个位置插入新的缓冲区以修复转换和建立违规。 |
网友评论