使用PrimeTime进行快速时序ECO经验分享
📑 目录
使用PrimeTime进行快速时序ECO经验分享
会议: SNUG Taiwan 2011
作者: 孙维敏, 张进朝, 陈玉娟 (Nuvoton, Hsinchu, Taiwan)
页数: 8
源文件: SNUG_2011_Taiwan_Poppen_Experience Sharing o_paper.pdf
Page 1
使用PrimeTime进行快速时序ECO经验分享
孙维敏, 张进朝, 陈玉娟 新唐科技 (Nuvoton) Hsinchu, Taiwan www.nuvoton.com
摘要
所有物理布线工具的修复能力总是有限的。在最终阶段对那些难以修复的违例路径进行手动时序ECO是不可避免的。随着IC设计复杂度的增长，快速时序ECO成为一个巨大挑战，特别是对于在不同工艺角和功能模式下具有多个场景的设计。为了满足上市时间目标，本文展示了一种快速ECO解决方案——使用PrimeTime ECO修复功能来减少修复迭代的大量周转时间。
Page 2
SNUG 2011
目录
1. 动机 ........................................................................................................................ 2 2. PT ECO介绍 ........................................................................................................ 3 3. 实验 ........................................................................................................................ 5 4. 结论 ........................................................................................................................ 8
图表目录
图1：签核流程中日益增长的设计复杂性 图2：PT ECO流程 图3：PT "fix_eco_timing"修复建立时间违例 图4：PT "fix_eco_timing"修复保持时间违例
表格目录
表1：PT DMSA模式下的保持时间修复 表2：PT DMSA模式下的建立时间修复 表3：通过多次迭代减少建立时间违例 表4：PT1106版本的运行时间改进 表5：旧ECO 表6：Cheetah ECO 表7：旧ECO与Cheetah ECO混合 表8：PT DMSA对不同设计的修复能力
动机
尽管所有物理布线工具的修复能力逐年变得更智能，但用户永远不会满意，因为在最终阶段对那些难以修复的违例路径进行手动时序ECO总是不可避免的。
对于手动时序ECO，有一件令人烦恼的事情——布线工具和签核工具之间的时序差异。在尝试校准各种变量和设置并进行分析后，发现有两个主要因素是无法避免的： - RC提取器差异 - 延迟计算引擎差异
Page 3
SNUG 2011
您可能会奇怪为什么这两个主要因素是无法避免的。我们能否要求布线工具提供与签核工具相同的时序分析结果？理论上，这是可行的，但不幸的是，在运行时间上是不切实际的。布线工具专注于布线优化，报告时序违例需要更长的运行时间。如果布线工具使用与黄金RC提取器和签核工具相同的质量，将会有更多的客户抱怨布线工具的运行时间。
随着IC设计复杂度的增长，时序必须在越来越多场景和工艺角下进行分析和修复。修复所有场景和所有工艺角的所有违例成为一个越来越关键的挑战。当我们听说PrimeTime具有ECO修复能力时，我们决定进行尝试。
PT ECO介绍
因为APR布线工具与PrimeTime具有不同的时序分析结果，在PrimeTime中发现的违例路径不一定能在APR工具中发现。然而，时序签核标准必须基于PrimeTime的分析结果。因此，时序收敛可能需要大量迭代和手动修复。
其思路是，如果我们能够使用PT的分析引擎执行ECO 工程变更指令，将显著减少修复迭代次数，并消除大量手动修复时间。因此，PT自PT0906版本起支持"fix_eco_timing"命令。
Page 4
SNUG 2011
图2简要说明了PT ECO流程。对于在PrimeTime中发现的违例路径，"fix_eco_timing"可以自动尝试使用"size_cell"或"insert_buffer"修复时序违例，并快速准确地估算新的修复结果。ECO更改可以通过"write_change"命令写出。内容是ASCII格式，IC Compiler或第三方布线工具可以读取并遵循PT的ECO指导约束来执行物理ECO。如果有任何时序违例，我们可以再次执行PT ECO修复。
PT DMSA 多场景分析也支持ECO能力。"fix_eco_timing"可以同时为多个工艺角和多个场景修复时序违例。
Page 5
SNUG 2011
实验
为了评估PrimeTime在DMSA模式下的ECO能力，我们选择了一个具有10个场景的大型设计来评估建立时间和保持时间修复的修复率。实验结果如表1和表2所示。由于PT不直接执行物理ECO，有两个修复率：一是PT报告的修复结果，另一个是使用PT ECO约束进行后ECO的物理修复结果。
Page 6
SNUG 2011
表1. PT DMSA模式下的保持时间修复
| Hold | 10 scenarios | Pre-ECO | PT ECO | Post-ECO |
| WNS | -12.863 | -0.046 | -0.024 | |
| TNS | 801.273 | -0.082 | -0.155 | |
| # Violations | 5078 | 13 | 94 | |
| Fix Rate | - | 99.74% | 98.15% |
保持时间的修复率非常高。仅通过一次迭代，保持时间违例几乎完全修复。看到Post-ECO的修复率略低于PT报告中的修复率是正常的。毕竟，PT ECO约束所需的交换单元可能不在修复路径附近。
表2. PT DMSA模式下的建立时间修复
| Setup | 10 scenarios | Pre-ECO | PT ECO | Post-ECO |
| WNS | -0.6633 | -0.241 | -0.359 | |
| TNS | -27.84 | -7.645 | -12.749 | |
| # Violations | 993 | 520 | 622 | |
| Fix Rate | - | 47.63% | 37.36% |
另一方面，PT中的建立时间修复率约为47%，Post-ECO的建立时间修复率降至37%。建立时间修复比保持时间修复困难得多，特别是PT需要同时处理10个场景。因此，我们不能说这个PT建立时间修复结果不好。然而，看起来我们需要对建立时序违例执行更多的修复迭代。
表3. 通过多次迭代减少建立时间违例
| Setup | 10 scenarios | Initial | Iter1 Post-ECO | Iter2 Post-ECO | Iter3 Post-ECO | Iter4 Post-ECO |
| WNS | -0.6633 | -0.359 | -0.355 | -0.233 | -0.229 | |
| TNS | -27.84 | -12.749 | -11.100 | -5.149 | -4.730 | |
| # Violations | 993 | 622 | 574 | 402 | 374 |
正如您在表3中看到的，建立时间违例的数量随着更多修复迭代而逐渐减少。然而，PT修复迭代越多，PT运行时间就越长。PT ECO会遇到运行时间长的问题吗？让我们做另一个关于PT ECO运行时间的实验。
Page 7
SNUG 2011
表4. PT1106版本的运行时间改进
| Iteration 1 | 10 scenarios | E-2010.12 | F-2011.06 | F-2011.06 New ECO |
| # Hold violations | 13 | 13 | 286 | |
| # Setup violations | 537 | 520 | 701 | |
| WNS | -0.078095 | -0.078094 | -0.12771 | |
| run time (minute) | 98 | 80 | 24 |
对于一次建立时间和一次保持时间修复的运行时间，PT 2010.12需要98分钟，而PT 2011.06需要80分钟。与使用APR工具的后ECO运行时间相比，PT ECO的运行时间性能相当不错且可接受。此外，PT 1106有一个新的ECO引擎，称为Cheetah，默认启用。如您所见，Cheetah ECO的运行时间为24分钟，不到旧ECO的三分之一。使用PT DMSA对10个场景的运行时间改进令人惊叹。
不幸的是，我们发现Cheetah ECO的修复结果比旧ECO差。这不是我们希望看到的。幸运的是，PT提供了一个可选开关。如果您想切换回旧ECO引擎，可以使用以下设置：
set eco_enable_old_fixing_technology true
尽管我们可以切换回使用旧ECO方法，但有没有方法可以在享受Cheetah ECO的运行时间的同时保持旧ECO的修复能力？答案是肯定的。
我们使用另一个设计做了一个更简单的实验，如表5、表6和表7所示。如您所见，我们可以使用Cheetah ECO引擎快速减少修复运行时间，同时大幅减少违例数量。对于剩余的违例，我们可以切换回旧ECO引擎以获得更好的修复结果。
表5. 旧ECO
| Setup | # violations | WNS | TNS | Run time |
| Before ECO | 3256 | -0.153 | -83.224 | - |
| Old 1st fixing | 2418 | -0.082 | -61.524 | 35 |
| Old 2nd fixing | 2206 | -0.079 | -51.425 | 20 |
| Old 3rd fixing | 2206 | -0.076 | -43.914 | 23 |
Page 8
SNUG 2011
表6. Cheetah ECO
| Setup fixing | # violations | WNS | TNS | Run time |
| Before ECO | 3256 | -0.153 | -83.224 | - |
| New 1st fixing | 928 | -0.128 | -20.933 | 31 |
| New 2nd fixing | 928 | -0.128 | -20.933 | 2 |
| New 3rd fixing | 928 | -0.128 | -20.933 | 2 |
表7. 旧ECO与Cheetah ECO混合
| Status | # of setup time violation | WNS | TNS | Run time |
| Before ECO | 3256 | -0.153 | -83.224 | - |
| New 1st fixing | 928 | -0.128 | -20.933 | 31 |
| Old 2nd fixing | 535 | -0.078 | -8.439 | 23 |
| Old 3rd fixing | 514 | -0.080 | -7.914 | 21 |
我们还尝试选择不同的设计评估PT ECO能力，如表8所示。根据实验结果，DMSA模式下的PT ECO可以帮助我们在短时间内减少违例数量的目标。
表8. PT DMSA对不同设计的修复能力
| case A | case B | case C | |
| # of scenarios | 4 | 7 | 10 |
| Pre-ECO | 36432 | 262 | 6228 |
| Post ECO | 4 | 0 | 345 |
| Fixing Rate | 99.99% | 100.00% | 94.46% |
| area overhead | 0.003% | 0.152% | 0.254% |
| run time (minute) | 15 | 24 | 216 |
结论与未来增强
基于实验结果，DMSA中的PT ECO确实有能力在短时间内减少跨多个工艺角和多个场景的违例。对于那些具有大量违例路径的设计，我们可以使用旧ECO和Cheetah ECO引擎的混合方法，在短时间内减少一个或特定场景的违例数量。这正是我们希望看到的。
目前，PT不支持功耗驱动的VT单元交换功能。希望PT将来能支持此功能。
图片索引
本文共 5 张图片，存放于 _images/ 目录。
第3页：图1 - 签核流程中日益增长的设计复杂性 第4页：图2 - PT ECO流程 第5页：图3、图4 - PT fix_eco_timing修复建立时间/保持时间违例