spef反标没成功,这种情况你肯定没遇到过

当我们跑完pt之后,第一步要看到的,不是timing,而是要确认spef是否反标成功。

这是一个好的习惯。在pt中用的命令是:report_annotated_parasitics

spef反标没成功,这种情况你肯定没遇到过的图1

当然,你也可以通过timing report中的相应的符号来确认反标成功与否。这种方式的缺点是无法得到一个全面的统计。即便你看的那条path反标成功,也有可能有一些net反标有问题。

一般来说,反标有问题最大的可能性是spef和netlist不匹配。

还有可能一些net确实没有实际绕线,他们自然也不会出现在spef中。比较常见的是芯片的PAD。做顶层的话,你会习以为常。

最近遇到了一个spef没有反标成功的案例。首先确认netlist和spef是基于同一套数据产生的,一致性没有问题。其次确认了这些没有反标上的net,都有实际的绕线。这就奇怪了,很多线没有反标上。

不过这些net有个特点,都比较短。那么是不是这些RC值因为太小而被过滤掉了?

这时候,starRC cmd文件中这些行引起了注意。

spef反标没成功,这种情况你肯定没遇到过的图2

注释掉,然后重新抽RC,再跑PT, 问题解决了。

看来是这些值设置太大导致的。这些值默认会非常小。足够将这些短net的RC值抽取出来。

建议StarRC抽取的时候,除非有官方建议,还是不要改这个值,影响精度,后果很严重。

默认 最新
当前暂无评论,小编等你评论哦!
点赞 评论 收藏
关注