打造IC人才
科技生态圈

分享数字ic后端项目中一次分析解决问题的过程

发布时间:2022-12-23

来源:IC修真院

后端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,可以用下面这个命令:

image

改完单位后,重新load sdc,report timing。问题解决。

在debug此类问题的时候,还有一个命令经常用到:report_delay_caculation。不过这里没有用到。

总结

这是一次比较典型的debug问题的过程,还算比较顺利。对于一些比较不确定的问题,解决很大程度上也要靠猜测,然后在通过实验来验证猜测是否正确。

相关推荐:

「ARM 架构」是一种怎样的处理器架构?

SoC的功能验证

初学者如何学习FPGA?一文为你讲解清楚

推荐阅读

换一换