當我們跑完pt之后，第一步要看到的，不是timing，而是要確認spef是否反標成功。

這是一個好的習慣。在pt中用的命令是：report_annotated_parasitics

當然，你也可以通過timing report中的相應的符號來確認反標成功與否。這種方式的缺點是無法得到一個全面的統計。即便你看的那條path反標成功，也有可能有一些net反標有問題。

一般來說，反標有問題最大的可能性是spef和netlist不匹配。

還有可能一些net確實沒有實際繞線，他們自然也不會出現在spef中。比較常見的是芯片的PAD。做頂層的話，你會習以為常。

最近遇到了一個spef沒有反標成功的案例。首先確認netlist和spef是基于同一套數據產生的，一致性沒有問題。其次確認了這些沒有反標上的net，都有實際的繞線。這就奇怪了，很多線沒有反標上。

不過這些net有個特點，都比較短。那么是不是這些RC值因為太小而被過濾掉了？

這時候，starRC cmd文件中這些行引起了注意。

注釋掉，然后重新抽RC，再跑PT, 問題解決了。

看來是這些值設置太大導致的。這些值默認會非常小。足夠將這些短net的RC值抽取出來。

建議StarRC抽取的時候，除非有官方建議，還是不要改這個值，影響精度，后果很嚴重。