其实timing的差异体现在cell delay variation、net delay variation。cell delay主要是由input transition和output load决定的,其delay值都是通过cell lib里面的delay template通过插值法计算得到。所以pr工具和pt工具如果在input transition和output load相同的情况下,计算得到的cell delay应该都是一致的。
对于load来说,pin的load都是写在lib中的,对于transition来说,cell transition也是根据lib中的template计算得到的。因此,transition和load的差一点就在net上了。
由于innovus自带的抽取rc的引擎和starrc的引擎是有差异的。因此,在计算net上的rc时,其结果也会有偏差。那么就会导致net上的load值计算出来就有偏差。对于同一个cell,如果计算其delay时,假设input transition在相同的情况下,其output load应该由net load+被驱动的cell load之和,而cell load可以通过lib直接查找得到(值应当相同),而net load则是由rc引擎计算得到。由于他们之前的rc引擎不同,导致计算出来的net load不一致,因而导致此处的cell delay出现了差异。
同理,假设cell output load一致的情况下,其input transition是通过前一级cell的output transition通过net传导过来的(假设前一级cell的output transition是一致的情况下),而net上的transition是通过等效戴维南模型计算得到的。net导致的transition的的变化在不同rc引擎计算也是不一致的。所以这也导致了cell input transtion出现了差异。
再者,net delay也是通过rc引擎将net等效成一定电阻电容模型去计算得到的。所以不同的rc引擎计算出来的net delay也不一样。
因此innovus提供了一套可以解决starrc和其自身rc引擎差异的小工具。其实在innovus创建rc corner的时候,我们可以看到其有cap sale factor, res scale factor, Clock Cap scale factor, Clock Res scale factor,这些factor就是用来调整其抽出来的电阻、电容值与starrc抽出来的相一致的一个调整参数。那么这个参数是如何产生的呢?
这就要用到innovus提供的一个命令了:generateRCFactor,generateRCFactor -postroute medium -reference externalSpef -spefMapfile <spef_map> -outputFile <rc_factor_file>
生成后的rc factor file
ps: 注意该spefmap文件,工具只会去抽取active rc-corner,也就是说如果该rc corner没有在set_analysis_view中体现,那么即使spefmap中设置了该rc_corner,工具依然不会去抽取该rc corner下的factor。
通过这个命令我们便会得到rc_factor_file这个文件,然后在mmmc中将里面的内容贴在create_rc_corner下方即可。
上述内容请参照图片进行理解。
#小编是一个入行多年的数字后端工程师,本身对编程方面比较感兴趣,在数字后端的脚本、flow上比较擅长,可以为大家提供答疑咨询服务。如有需求,可打开星球芯冰乐,获取更多知识干货分享与答疑服务。