微波EDA网,见证研发工程师的成长!
首页 > 研发问答 > 微电子和IC设计 > IC后端设计交流 > GigaOpt的正确打开方式之Path Group

GigaOpt的正确打开方式之Path Group

时间:10-02 整理:3721RD 点击:

相信有一些人看到标题的Path Group就不想点进来了,但我还是要用这个标题...
(注:这里说的是EDI14 GigaOpt中的Path Group,不保证其他工具的Path Group用法相同)
【GigaOpt的错误打开方式一】:GigaOpt的过程完全没办法手动干预,只能setOptMode -xxx 然后optDesign开跑
解释:Encounter中最耗时的步骤就是GigaOpt,如果没办法手动干预就太悲催了。事实上Path Group可以极大程度地干预GigaOpt的过程。
【GigaOpt的错误打开方式二】:Path Group的用法就是把时序最差的那堆路径设为高权重高优先级...
解释:这种做法的结果往往和完全不设Path Group没有任何区别(除了换个随机种子)。有过这种经历的工程师通常会得出下面的结论...
【GigaOpt的错误打开方式三】:Path Group没什么用的啦,我从来不用啦~
解释:完全不设Path Group的结果就是EDI自动创建两个High Effort Group(reg2reg和reg2cgate)和一个Low Effort Group(default)。可以说,不管你设不设,Path Group都在那里,不由得你不用。
【正确设置Path Group有什么好处?】
答:可以大大提升收All Paths TNS的能力。
举例一:默认设置下,某条路径这次跑能修干净,下次跑又冒出来...正确设置Path Group后可以完全消灭这种情况;
举例二:假如默认设置下跑出来in2reg、reg2out、in2out的WNS是-0.5、-0.4、-0.3;那么正确设置Path Group后的WNS可能变成-0.5、-0.2、-0.1;
【如何正确设置Path Group?】
这是本帖的主题所在,首先要从GigaOpt调用的两个优化引擎:TNS Optimizer和WNS Optimizer入手:
【关于TNS Optimizer】
大家都知道,设置setOptMode -allEndPoints true后就可以自动调用TNS Optimizer。从字面上看,它就是用来收All Paths TNS的,但实际效果如何呢?
细心看过EDI log的读者都会发现,每轮optDesign,TNS Optimizer只会被调用一次,而WNS Optimizer被调用个十七八次都不奇怪。TNS一轮能收得好才怪啦!
退一步说,丢十几万条Violated Paths让引擎收一轮就把TNS收好,这么智能的引擎地球上还不存在...
最惨的是,I/O路径默认在Low Effort Group(default),有时TNS Optimizer直接就跳过I/O不收了...
一句话,TNS Optimizer对收All Paths TNS有帮助;但离收到最好,还有很长很长的距离...
【关于WNS Optimizer】
正如字面意思,这个引擎只修WNS。如果有一堆-0.5的路径修不动,另一堆-0.4的路径可以轻松修到0,那这个引擎会卡死在修-0.5的路径上,-0.4的路径是绝对不会去修的!
那有没办法让WNS Optimizer去修这堆-0.4的路径呢?答案就是通过设置Path Group,让GigaOpt再启动一次WNS Optimizer去专门修-0.4的这堆路径!
【默认设置下WNS Optimizer的启动模式】
默认设置下,每轮迭代WNS Optimizer会被启动两次:
第一次启动,收High Effort Group(reg2reg和reg2cgate),最差那条路径收不动了,就退出;非最差的违规路径不收
第二次启动,收Low Effort Group(default),最差那条路径收不动了,就退出;非最差的违规路径不收
至此,一轮WNS优化迭代完成。
【设置了Path Group后的WNS Optimizer的启动模式】
假定我们手动创建了三个High Effort Group,名字为groupPriorityHigh、groupPriorityMedium、groupPriorityLow,对应优先级设置为高、中、低;
那么同样,第一次启动时,WNS Optimizer依然是收High Effort Group(上面3个一起收),但在最差路径收不动时,会作一个判断:
<分支1>如果此最差路径属于groupPriorityHigh,那么收High Effort Group结束,跳到收Low Effort Group;(注意:与默认设置完全相同!
<分支2>如果此最差路径属于groupPriorityMedium,那么再启动一次WNS Optimizer,只收groupPriorityHigh;直到最差路径收不动,则收High Effort Group结束;
<分支3>如果此最差路径属于groupPriorityLow,那么再启动一次WNS Optimizer,只收groupPriorityMedium和groupPriorityHigh;最差路径收不动时再作一次判断...
看到这里应该清楚了,我们希望让WNS Optimizer先收时序“最差”的路径,收不动了,再收时序“较差”的路径。这意味这时序“较差”的路径优先级要设得更高,不然分支不会被触发。(而不是把时序最差的优先级设到最高!
【举个栗子】
对于高级的使用者,当然也可以对reg2reg路径细分Path Groups。但在此为了简明起见,还是以收I/O路径为例:
假如默认设置下,preCTS优化完的WNS结果是:
reg2reg、reg2cgate:-0.6
in2reg:-0.5
reg2out:-0.4
in2out:-0.3
那么正确的Path Group设置方法是:
createBasicPathGroups(显式创建reg2reg、reg2cgate两个High Effort Path Groups;由于它们时序最差,优先级权重保持在最低,即默认的0就好)
为in2reg路径创建Path Group,High Effort Level,优先级权重1;
为reg2out路径创建Path Group,High Effort Level,优先级权重2;
为in2out路径创建Path Group,High Effort Level,优先级权重3(时序最好,因此优先级设为最高);

这样设置的GigaOpt过程如下:
第一次启动WNS Optimizer,收reg2reg、reg2cgate、in2reg、reg2out、in2out;
第二次启动WNS Optimizer,收in2reg、reg2out、in2out;
第三次启动WNS Optimizer,收reg2out、in2out;
第四次启动WNS Optimizer,收in2out;
确保每一组路径都被收到最优!
【不信请试试!】
我保证效果是立竿见影的,看到时序报告下巴不要掉下来

n牛贴 ,顶一个!

赞 大牛啊

那ICC要做这件事简单多了,只要把critical range调大就行了,我这样理解有错吗

那ICC要做这件事简单多了,只要把critical range调大就行了,我这样理解有错吗?

EDI中setOptMode -allEndPoints true的前身就是-criticalRange 1(大致如此...)

刚try 了下,结果大跌眼镜&#128077;,真是大牛啊!期待下次分享噢

小编说的权重是指setPathGroupOptions的这个option吗?
-slackAdjustmentPriority <integer>
我觉得你说了怎么多,可以顺便把脚本贴一下参考,谢谢

setPathGroupOptions -effortLevel high -weight <integer>
你说的-slackAdjustmentPriority的具体作用还在摸索中...

貌似路径有丢失



encounter 5> setPathGroupOptions-weight**WARN: (ENCOPT-3602):
You are applying setPathGroupOptions on path_group -weight which does not exist. Make sure to create it if you want the options to apply on it.
Incorrect usage for command setPathGroupOptions
我的版本是13.20,没有你提到的weight选项了。

All Paths数目不对了?
这种Bug我只在EDI13的Beta版CCOpt Native里遇到过...workaround的方法是重新加载一次sdc
也可以试试这个命令:reset_path_groups -all

我看了一下,EDI13确实没有-weight,EDI14是有的。看来旧版EDI是不能使用这个方法了...

我是用13.1,同上楼用的slackAdjustmentPriority
在cts后加,路径没丢失,就是hold后会引起setup违例,要反复三四遍才能接近clean

太牛了!必须顶一个

小编这是捡芝麻丢西瓜啊,在design一开始的时候,constraint特别是IO related,通常都是over-constraint的,这是增加这些IO group的weight就会使internal的timing优化减弱。所以这是在sdc已经golden的情况下这样做才显得合理,而之前的话我们明显是主要优化internal为主的

thanks all of you guys...

牛贴要顶起来大家一起学习下!

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top