tweak生成定时文件和Tweaker生成主脚本介绍

2021-07-28 17:26 来源:电子说

作为第一次接触Tweaker的新人,你可能会担心Tweaker的流程比较麻烦。

但不用担心,Tweaker功能丰富,提供了完整的参考流程,经过大量项目验证,可以直接使用。您可以通过简单地配置输入文件来快速运行调整程序。

这篇短文将教你如何运行Tweaker,让你直观感受到Tweaker引用过程的魅力。

作业监督程序

分析其余部分未修复的原因

检查维修结果

在公关工具中实施生态

测试案例介绍

这是一个真实的设计。我刚运行完icc2,得到了route_opt的数据库。PTSI的结果如下:

53d4aa94-ed0e-11eb-a97a-12bb97331649.png

有1710个设置违例和816个保持违例。注:这里的数字是根据端点(nworst=1)计算的,而不是根据路径计算的。

保持计时正常,但设置有点差。但是没关系,你可以尝试这个过程,而不是追求签署质量的公关结果。

接下来,我们开始构建Tweaker流程,该流程由三个步骤组成:生成Timing文件、生成Tweaker的主脚本、运行Tweaker修复Timing。

调整程序步骤1:生成定时文件

调整者需要读取时间文件的PT,包括SDF,TWF,违反路径报告等。

Tweaker提供了可以从PT会话中快速转储这些文件的脚本。脚本在Tweaker的安装目录中:/etc/scripts/tcl/pt,如下图所示(部分截图):

54318d68-ed0e-11eb-a97a-12bb97331649.png

您只需要使用其中一个主脚本。由于此设计STA使用GBA模式,因此可以使用以下脚本

使用scriPT pt直接源(指定PT会话的位置)生成所有需要的定时文件,如下图所示:

546f60a2-ed0e-11eb-a97a-12bb97331649.png

调整程序步骤2:生成调整程序的主脚本

没有必要从头开始构建Tweaker流程脚本。有大量完整的参考脚本可以直接在Tweaker安装目录下使用。

54abc15a-ed0e-11eb-a97a-12bb97331649.png

从上图可以看出,基本上所有的ECO功能和主流流程都有参考脚本。我们不需要自己选择所需的流程或功能。微调器的脚本生成器功能可以快速生成所需的微调器脚本。

在Tweaker的安装目录下(。/ect/模板/twk_

utilities/special _ command/Script _ Generator),有一个Script Generator的脚本,只需要配置两个配置文件:tweaker _ settings.config和script_tmplate。配置完这两个文件,就可以生成Tweaker的脚本,然后就可以开始做ECO了。

第一个配置文件Tweaker _ settings.config用于配置tweager的输入(如下图所示)。

55188cea-ed0e-11eb-a97a-12bb97331649.png

放l

ib库、lef/def、网表,还有上一步生成的Timing文件等都填进去,修Timing所需的Buffer、Delay Cell等也可以填进去。

第二个配置文件script_template:用于配置ECO的流程,比如修Timing的策略、修哪些Violation、用的什么工艺等等(如下图)。

557385c8-ed0e-11eb-a97a-12bb97331649.png

对这个Case,PR工具可以选择icc2,STA工具选择pt。它提供了很多ECO的功能选择,这个Design可以先只修Setup和Hold。还有这个Design规模比较小,选择用twf的模式来修,可以减少ECO迭代次数。

同时可以把Job Monitor打开,方便进行Debug。

配置完两个文件后,用Script Generator生成Tweaker主脚本:

5598d3f0-ed0e-11eb-a97a-12bb97331649.png

主脚本run.tcl生成后,run.tcl就会去调用所需要的各种脚本,不用我们亲自去找。接下来就可以运行Tweaker了。

Tweaker流程step 3:运行Tweaker修Timing

这一流程用一个命令即可搞定:tweaker -t -cmd run.tcl。它就能按照我们的配置,去做Setup ECO和Hold ECO。

此外,除了简单的Tweaker Flow,Tweaker还提供强大的Debug功能:Job Monitor。

Job Monitor

刚才我们在配置文件里把Job Monitor设为1,所以运行Tweaker时会自动弹出Job Monitor界面,此处可以查看ECO的进度以及其他信息。

55d2b408-ed0e-11eb-a97a-12bb97331649.png

Job Monitor里有大量非常有用的信息,比如可以看到“Task Table”里的步骤,包括它们都做了什么,每个步骤分别花了多少时间:

先是Datain,包括verilog、def、slack rpt、spef、sdf、twf等;

其次是Consistency Check,确保输入的文件没有问题;

然后开始修Setup,用了6种不同的方法去修;

接着开始修Hold,用了8种不同的方法去修;

修复结束,写ECO脚本、报告和存Session。

如果想看修Setup的6种方法分别有什么效果,可以点击左上角的“Scripts Finished”按钮,然后得到以下曲线:

56337860-ed0e-11eb-a97a-12bb97331649.png

由上图可见,一开始有1706个Violated Endpoints,然后Fix Setup第一个步骤将Violated Endpoints数目降到了446个,第二个步骤继续降到了347个……直到第6个步骤降到了315。然后是修Hold的步骤,可以看到修Hold时并没有损害Setup,Setup保持得非常好。

也可以看修Hold的曲线:

5660004c-ed0e-11eb-a97a-12bb97331649.png

最开始有809个Hold Violated Endpoints。Setup修完后,Hold还有762条,保持得非常好。这是因为Tweaker在修Setup时会看Hold,同时在修Hold时也会看Setup。

Hold第一个步骤从762条修到了549条,第二个步骤修到了80条……到最后一个步骤,Hold只剩下54条了。

通过这张图,不仅能看到修复的过程及结果如何,还可以快速分析出哪些步骤是最有效的,哪些步骤是低效或者无效的,然后可以有针对性地去改进。

查看修复结果

可继续用Job Monitor查看Summary。点击Job Monitor界面上的Action Buttons -》 Tweaker QoR Info -》 QoR summary,会弹出网页格式的Summary,信息非常丰富,此处可挑一些重点看看:

569611a0-ed0e-11eb-a97a-12bb97331649.png

在这里能快速看到,这个Design总共有224k的Instance,但在ECO Domain里只有8.5k的Instance,只占总Cell的1/3。这就是为什么ECO Domain能大大降低Memory使用和减少Runtime的重要原因之一。如果不用TWF Mode来修,而是基于slack rpt来修,ECO Domain可以继续降低到10%,Runtime还可以再加快4倍!

看修复率:

56ccdb2c-ed0e-11eb-a97a-12bb97331649.png

Setup:按Endpoint个数算,修复率是83%;按Total Path TNS算,修复率是90%。

Hold:按Endpoint个数算,修复率是93%;按Total Path TNS算,修复率是64%。

最后再看看ECO的Cost:

56d90834-ed0e-11eb-a97a-12bb97331649.png

情况一目了然——总共插了1133个Cell(Buffer、Inverter、Delay Cell等),Size了32017个Cell,Cell面积约增加438.2,时间约20分钟,用了近6.7GB的Memory。

分析剩余没有修掉的原因

根据修复结果,Setup/Hold还有一些没有修掉,为什么呢?Tweaker提供了多种分析功能,可选择其中一种方法来分析——

打开Slack Review,如下图:

56fca802-ed0e-11eb-a97a-12bb97331649.png

总共290条Setup Violated Endpoints,都在ssgnp_0p675v_125c里。其中Clock Gating占了24条,core_clock_0占了266条。

点击clock_gating_default那一行,下面就会列出这个Group所有的Violated Path。

可以看到,这些Path虽然还有Slack,但是Slack都已经有所改进(Diff这一栏是改进的值),有的改进少些(比如Path 3679,改善了17ps),有的改进了很多(比如Path 3478,改进了57ps)。

ICG的Timing本来就很难修,加上Clock Skew很大(参考Skew那一行),所以剩下的Path的确难以修复。但可以继续看看具体是哪些潜在因素导致修不下去,比如双击第一条Path 3679,可得到如下Path View:

576ac24c-ed0e-11eb-a97a-12bb97331649.png

最后一列是Blocking Code,它解释了这个Cell不能继续修的原因是什么。随意点击上面一个B086做参考,出现下图:

5795e562-ed0e-11eb-a97a-12bb97331649.png

它除了解释Blocking Code的意思,同时还给出了可能的解决方案,即相关的三个变量,我们可以调整这三个变量的值来进一步改进修复率。

由于篇幅限制,此处不展开叙述。

P&R工具里实现ECO

把刚才Tweaker写出来的ECO tcl文件给icc2做ECO:

icc2_shell》 source ECO.icc2_high_level.tcl。

icc2执行结果如下:

57b7603e-ed0e-11eb-a97a-12bb97331649.png

可以看到,所有的ECO动作都没有问题,都被成功地执行了。

然后检查Legality:check_legality

57d1b2cc-ed0e-11eb-a97a-12bb97331649.png

可以发现,新加的Cell和Size的Cell没有任何的Legality的问题。这就是Tweaker的Physical-Aware的强大之处。0 Displacement能让ECO Route带来的影响最小!

接下来做ECO 绕线:route_eco。

ECO绕线后,导出数据,给STARRC和PT再做一次STA分析。看看ECO后,真实的Timing如何:

57f1db9c-ed0e-11eb-a97a-12bb97331649.png

可以看到,Tweaker修完后的Violation条数,和PT看到的很接近,也就是Tweaker和PT的Correlation非常好。

Tweaker提供了强大的、易用的脚本,所以即使是新手,上手也非常快。同时,这些脚本经过很多项目实践,所以基本不用做什么修改,拿来即用。

同时Tweaker也提供了强大的Debug功能,即使是新手,也能快速分析问题所在。

编辑:jq

延伸 · 阅读