分享数字ic后端项目中一次分析解决问题的过程
发布时间:2023-06-02
后端ICer经常会在项目中遇到问题,如何解决问题,则体现出经验。今天遇到的一个问题,这里做个记录。同时也希望通过读这篇文章,你也能增加一个解决问题的经验。
相对来说,前端更多的是理论,后端更多的是需要经验。
解决问题的过程基本上是这样,首先遇到问题,然后分析问题,最后解决问题。实际上,你会发现,解决问题分析问题是个迭代的过程,很少会一蹴而就。
遇到问题
本项目用的icc2和pt进行物理实现以及时序验证。
遇到的问题是pt中的net电容于icc2中的net电容差距巨大。
pt report
icc2 report
上面两个图分别是pt和icc2中timing report的截取片段。红圈中的数字,前者是fanout,后者是cap。
其中,pt中cap的单位是pF,而icc2中cap的单位fF,如果换算成相同单位,会发现差距巨大。奇怪的是,fanout数值也不一样。一个是3,另外一个是5。
分析问题
首先应该怀疑的是,是不是两者根本不是一套数据,也就是说,网表不一样?
很好解决,分别打开pt和icc2,看一下这条net对应的schematic。
打开后,两个图一模一样。
schematic
看来网表是一样的。这也说明,fanout并不是指的是连接的pin的个数,而是相对于某典型pin的换算。这里排除了数据不匹配的嫌疑。
根据经验,绕线如果没有绕完全的话,starRC通常会插入一个巨大的电阻,而icc2往往会自动将他们连接起来(默认行为),不同的处理方式也会导致两者timing上差异较大。这个也很好验证,在icc2中直接对这条有嫌疑的net用check_lvs命令。验证结果显示,net没有问题,没有open和short。
再来看schematic,这个电路有个特点,就是连接到了port。和port相关的话,就会和sdc里io的约束有关。查看sdc,发现对应的port的cap是3pF。
也就是说,pt的report中的3pF多的net cap是正确的。而icc2中的cap显然过小了。
在icc2中report_units,会发现icc2中的单位是fF。合理怀疑,icc2在读sdc的时候,将port的cap数值3当成3fF。
需要说明一下,sdc的开头是有单位的设置的,并指定的单位是pF,并且在读sdc的时候,也没有报任何错误。鉴于此类情形非常常见,正常来说工具应该可以自动处理。所以大家很少会遇到这样的错误。因此,本人怀疑是工具本身的bug所致。
问题的分析结果就是,工具的bug导致单位识别错误,经io约束中的3pF识别为了3fF。
解决问题
问题分析出来了,问题就解决了大半。真正解决就如同足球中的临门一脚。那么如何解决呢?
既然icc2的默认单位是fF,那么就需要强制改为pF。其实,之所以认为是工具的bug,是因为查看tf file的时候,发现tf file中的单位也是pF,并不是report_units结果所说的是fF,尽管里面有个括号(set by technology library)。
将单位强制为pF,可以用下面这个命令:
改完单位后,重新load sdc,report timing。问题解决。
在debug此类问题的时候,还有一个命令经常用到:report_delay_caculation。不过这里没有用到。
总结
这是一次比较典型的debug问题的过程,还算比较顺利。对于一些比较不确定的问题,解决很大程度上也要靠猜测,然后在通过实验来验证猜测是否正确。
【免责声明】:本站部分文章为转载或网友发布,目的在于传递和分享信息,并不代表本网赞同其观点和对其真实性负责;文章版权归原作者及原出处所有,如涉及作品内容、版权和其它问题,我们将根据著作权人的要求,第一时间更正或删除。