pr之后做sta时，是否还需要set_load的约束？
在完成pr后，提取了spef文件，读给pt。
那么是否还需要原来约束用的set_load，已经set_drive set_driving_cell等?
个人感觉可以去掉了，
我只在dc做预估的时候用到，pr的约束里面都不加这些了。
求助，这是否可行
你好，你说的仍然需要，是否指代：sta时需要设置这个三个约束，但是pr的时候可以不用?还是说，dc到pr到sta都需要这三个约束?
我一直认为set_load是dc时才用到的预估容性负载，
至于set_drive和set_driving_cell我也是只在dc的时候去约束一个驱动电阻。
spef 文件只是抽取芯片内部RC寄生参数时序文件，而set_load是芯片PAD驱动外部负载的能力，也是反映PAD
驱动延迟，set_load的值不一样则PAD的输出延迟不一样，看芯片外部负载情况，所以做静态时序分析还是要加的
不加就是默认值，有肯能端口时序会过于乐观。
想问问，设计最重要的就是要有一个好的时序，“传输延时”也就是transition time，能影响时序的也就是一个RC延时导致的。
那么最后肯定要将结果反映到delay time上，再最后也就是buffer的问题，有没有违例，有没有加上buffer等等。
因此，set_load的大小估计就显得很重要，如果设计带有pad，这个好说，我可以拿foudary的文件，查查库，然后根据文件信息给out port 加上约束。
但是如果设计没有pad，而是一个数字设计，最后要个模拟部分一些信号连接起来，那么这个set_load要怎么办，还有set_drive等?
个人觉得带PAD的设计，set_load也不好估计。要去和板级的工程师讨论。如果你的设计output port连的是模拟模块，可以将模拟模块当成黑盒子，请模拟的工程师给出这个输出端连接的load。或者将数字设计和模拟设计整在一起，让工具分析。
你好，对于带pad的设计，有个问题我一直没搞清楚。
pad是有in和out两个端口的，set_load是对out这个对口做约束么?我感觉这样做的约束不太正确
因为，如果这个set_load导致最后的一些时序，或者是transtion time有违例，需要工具加buffer的时候，那么是加在哪，会不会加到pad的out端口的后面?但这个不太合理呀，因为pad在我的约束中已经加上成为dont_touch属性了。
“如果这个set_load导致最后的一些时序，或者是transtion time有违例，”需要的是调整PAD的选型，不同类型的PAD驱动能力不一样。
个人觉得 应该flow最好这样 pt read pr_netlist , source sdc , read_para spef, set clock signoff margin and si ,analysis timing
set_load只是模拟一下输出的驱动，一个都是给一个相对保守的驱动能力给片外，实际上都是有一定的margin在输出端了，load大，在以这个port 为end point的 timing path中，工具就会报一下到这个port的timing violation 和对其进行优化,而不是在pad后面做所谓的优化了
至于set_drive和set_driving_cell我也是只在dc的时候去约束一个驱动电阻。
“以这个port为end point”，这里的port是指代pad的输出端口还是输入端口?
”工具会对其优化“：是采用什么样的优化?对于一个foundary给定的pad，而且综合时候会加上dont_touch属性，工具会在哪里优化?
当然是输出端口了，pad本身自然不动了，但是regout这一级的路径上的cell 优化了
你的意思是否是说，优化了reg2out（代码中的输出端）可以改善pad的输入端的时序等，最后就会影响到pad的输出端，从而满足set_load所预估的约束?
需要的
请教前辈,icc中运行Rail分析，在终端里显示“Invoking PrimeRail”，但PrimeRail窗口就是不出现，
请问什么原因?感激涕零。
详细请看看我的求助帖子，如下链接：
http://bbs.eetop.cn/viewthread.p ... highlight=primerail
请教前辈,icc中运行Rail分析，在终端里显示“Invoking PrimeRail”，但PrimeRail窗口就是不出现，
请问什么原因?感激涕零。