PR遇到的问题？请大家帮看看！

在后端place OPT后，发现fanout和cap都严重违例，查了下.lib文件发现max_capacitance=3.07,而被驱动的pin的capacitance=0.003，我想问下遇到这样的 情况如果处理?
在opt的时候 ，设置了max_fanout=20.
另外，问下各位大侠cap违例怎么引起的，应怎么处理?谢谢

1) 要setOptMode -fixFanoutLoad true
2) 如果input pin cap远远小于 output pin max_cap的话，不应该有cap违法，是不是2个lib里面cap的单位不同?

setOptMode -fixFanoutLoad true这条命令起什么作用呢 ?我已经设置了max_fanout的啊?
请陈涛小编解释下
谢谢！

你是在place的opt后面出现的fanout和cap问题，你检查一下报告是哪条路径，按照你说的情况我认为是clock路径引起的，你做完时钟树看一下clock_report,在时钟树文件中修改的max_fanout的值就能解决。如果不是clock引起的那就是lib文件有问题

楼上说的有道理！
setOptMode -fixFanoutLoad 默认是false

的确是.lib中引起的，我看了下BUFX12的max_cap为3.07，而驱动pin的input cap只有0.003差太多了啊！我不可能dont_use掉这些吧！
另外问个闲外问题：
在做PR时，我们一般会dont_use一些cell，想问下是那些类型的cell?
谢谢！

dont_use cell一般包括: clock cell (CK* 在做timing opt的时候禁用,只是做CTS的时候允许使用) delay cell
(只是在fix hold time的时候使用)驱动过大或过小的cell 比如 D0 D24（foundry的建议)
我暂时想到的就这些 欢迎大侠们补充

我怎么看不懂你的问题呢。place opt阶段clock 是ideal属性，你会不会丢了clock?
或者漏设了ideal clock之类。 buffer input pin cap 0.03 与max_cap 是 3 不冲突啊，
问题可能是你的net loading过大，max_cap是buffer driver 能力，而0.03仅仅是input pin的寄生电容，工具实际计算还包括net load ，我看不出0.03与3.07有何冲突。一个buffer可以驱动3.07pf 很正常啊。
虽然大了一些