我开发了一款功耗优化辅助软件，遇到了一些技术问题，恳请高手指点一下。

xixizhihua

大家好，由于工作需要，我需要在不影响时序性能条件下，通过将非关键路径的某些LVT单元替换为HVT单元，来降低leakage功耗。
目前，公司用的相关软件效果不是太好，有不少地方，依然可以手动替换。
因此，我自己基于Encounter吐出的数据，自己做了一个功耗优化软件。
但是，在最后进行时序估算的时候，出现了与Encounter报告不符合情况。请各位高手，帮我看看。

是这样，Encounter的Timingreport的machine格式，对于一个单元会给出如下的报表。
   cell        net        delay       delayincr        slew        load
  XXX       {}           0.26         0.00           0.021        {}
  {}         XX          0.034        0.00           0.045     0.036

这两行，分别代表某标准单元和其后线延迟的slew和load，相信各位高手早都知道。
但是，可以发现，对于一个标准单元，我发现其后的Load是空白。（希望高手能够确切指点一下，为什么呢？）
我估计，是工具用net的load来代替了。

因此，我选择了第一行的slew和第二行的load，来反标到lib库里进行插值运算。
但很奇怪，lib库中（7x7）的延迟表格。
我将数据代入，运行双线性插值运算后：
得到的结果，总是略小于encounter报出的结果。
例如，这个单元的0.26，我运算出来就在0.21左右。（这个差距其实不小了）
换句话说，就是用encounter给出的slew和load算出的Delay，和encounter给出的delay不一样。
请各位高手指点一下，我的软件设计或者思路和算法，是不是哪里出问题了？非常感谢。
对了，使用的lib库是基于台积电40nm的工艺。

另外，我的软件，对静态功耗统计的功能基本已经做全，通过对DEF文件分析，
CELL的leakage功耗，与Encounter误差在1%以内。SRAM总功耗分析，与Encounter的design summary report中的结果，完全一致。
希望大家能够帮我一同攻克最后一个时序误差的难题。
软件做好后，我测试完了，会放到论坛与大家一同分享的。谢谢大家了。

farren

我觉得楼主做的这个挺有意思的.
这样就可以尽可能快的, 尽可能多的替换HVT的cell了.
但我还是找不出问题所在. 期待陈版主驾到.

我想能不能这样.
既然知道结果了. 知道load了. 能不能倒推 slew, 看是一个什么样的值?
难道是cell和net slew之和?

1. 你的软件是什么语言写的,tcl skill 还是perl?
2. 请教双线性插值算法是怎么做的?

我有个疑问. encounter中的时序本来就不准. 这样推到极限替换, 如果时序比较苛刻, 会给收敛带来困难么?

陈涛

用report calculate delay看看encounter是怎么算的

xixizhihua

非常感谢陈版主，我这就回去试。
回复2楼的朋友，现在软件属于实验阶段，我文本抓取和数据运算用的是perl，不过因为def文件很大，所以用了多线程。数据和encounter接口的部分，我使用tcl写的，这样Encounter可以直接读。等算法都实验好了，如果效率上不去，我会用C++去写下关键部分。
另外，双线性插值，我用的是最简单的一种，找到4个点，先算X方向上2个点，再算Y方向，得出最终值。和图形处理中算像素的算法基本是一样的。
因为，lib库的7x7表格，本来就是一个分段线性表。所以我才使用这个算法。

还有一个问题，期待更多高手指点，就是目前我对工具算法，都是自己在摸，大家是否知道，哪些书专门介绍相关的EDA工具的算法的，最好是时序分析的，希望推荐一下，谢谢给位啦。偶看到的都是关于布图的，和时序分析理论的，EDA工具能用的，却非常少。

farren

很期待你的软件啊, 强烈期盼分享, 哪怕是有bug的版本也好.
我很好奇你的多线程是怎么实现的. 我脑子里想到的就是用split把def分成几个.
我也不清楚encounter怎么去查lib的7x7表.
是用双线性插值么?

klzq

楼主很牛啊，希望早日成功

icfbicfb

tsmc 和很多公司有这种 vtswap的软件啊， 不过自己写也很好玩 ，用perl很好，
，首先

没有load 是不是因为 cell 是floating的， 去除那些floating ,dangling things ,
时序误差是不是由derate造成的，   看derate参数

一般来说vtswap都是针对pt，ets等signoff工具的，这样时序比较准确，

icfbicfb

问下，你是用NLDM  .lib还是 ECSM  .lib 分析的，

memory功耗 PR工具分析的基本上不准确，  要看datasheet上的，

ttder

想法很好，创意也很好。现在很多公司都已经做了该流程了，icc也集成了该想法。
     楼主的想法有几个缺陷，下面我一一列出：
     1) 该做法没有考虑到pr和sta的一致性问题。换句话说，你就算全部换好了。到了pt那边，难道就能过吗，pr和sta，特别是encounter和primetime，肯定timing不太一样。所以最好在primetime里面做吧。
      2） 不应该自己去算delay. 我们应该尽量去借助于工具的sta分析功能，不管是encounter还是pt.毕竟里面的model和算法本身就是eda工具的最精华所在。

       我猜测楼主应该用了个小的design去测试了自己的脚步，所以对运行时间没有做过多的关注。
       我提两个小建议楼主可以考虑下：
       1>  可以用get_attribute之类的命令得到经过该cell的slack，一旦该cell的slack为正或没有超过某个阈值，就替换该cell.
           2> 每次替换时都需要检查经过该cell的所有timiing path,一旦发现在本轮中该路径曾经被替换过，就放弃该cell的替换，因为此时你的rc和delay calculate还未必update.否则很有可能发生一条路径上被换了很多次cell的情况。
       3>重复运行整个脚本20-30次，每次运行完以后记得update timing和rc.你会发现，你的r/h的比例会有很大的改观。
    基本原则就是上述这些，具体调试时候请尽量调用程序本身的排序以及正则啥啥算法，会大量减少运行时间。

icfbicfb

这种算法我在某公司见过，实在是先进，
用来自动修复setup/hold time 的，

当时用magma，
report lib delay -slew -cap XXX