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

后端ICer经常会在项目中遇到问题，如何解决问题，则体现出经验。今天遇到的一个问题，这里做个记录。同时也希望通过读这篇文章，你也能增加一个解决问题的经验。

相对来说，前端更多的是理论，后端更多的是需要经验。

解决问题的过程基本上是这样，首先遇到问题，然后分析问题，最后解决问题。实际上，你会发现，解决问题分析问题是个迭代的过程，很少会一蹴而就。

遇到问题

本项目用的icc2和pt进行物理实现以及时序验证。

遇到的问题是pt中的net电容于icc2中的net电容差距巨大。

 

 

上面两个图分别是pt和icc2中timing report的截取片段。红圈中的数字，前者是fanout，后者是cap。

其中，pt中cap的单位是pF，而icc2中cap的单位fF，如果换算成相同单位，会发现差距巨大。奇怪的是，fanout数值也不一样。一个是3，另外一个是5。

分析问题

首先应该怀疑的是，是不是两者根本不是一套数据，也就是说，网表不一样？

很好解决，分别打开pt和icc2，看一下这条net对应的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，可以用下面这个命令：

 set_user_unit -type capcitance -value 1.0e-12

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

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

总结

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