dc时序违规，怎么解决？
startpoint:U_control/o_m_41
(falling edge_triggered flip-flop clocked by i_clk)
endpoint: m41(output port)
path croup: default
path type: max
pointfanoutcapincrpath
U_control/o_m_41/CKN(DFFNSX2)0.000.00f
U_control/o_m_41/Q((DFFNSX2)0.370.37f
m4_pd[1] (net)20.020.000.37f
pad_m41/P1381.961382.33f
m41(net)13.980.001382.33f
m41(inout)0.001382.33f
data arrival time1382.33
max_delay18.0018.00
output extral delay0.0018.00
data requires time18.00
data arrival time-1382.33
slack(VIOLATTED)-1364.33
pad和U_control/o_m_41之间的delay太大了，可能是你的wlm设置的不对吧。……………………
检查你的约束文件不对吧
具体是指什么约束呢?能不能说具体点啊，期待回复，谢谢
m41后面负载电容明显太大了，对output设置set_load
負載太大，設置問題，同樣樓上
我看了下pad的lib文件里面，p端的电容是3.48，我设置的set_load是0.5，两者加起来刚好是3.98，就算我把set_load设置为0 ，这是最理想的情况了，负载电容是3.48，延时还是很大啊 郁闷了，WLM每种情况都试了还是不行啊，到底是哪的问题呢?
补充：今天用report_delay_calculate查看了pad/PD(下拉)到pad/p端的延时计算情况，发现该cell的fall delay延时很大，rise delay延时很小。而pad/PU(上拉)到pad/p端情况相反。看了下io的lib文件，发现里面定义的延时就1000左右。说明是库本身的问题，但是为什么对上下拉电阻的时序这么设置呢?请大家在帮忙分析下。谢谢
对pad 应该要设计set_dont_use属性.
这个违例太大了吧，sdc文件肯定有问题。
是.lib里面定义的延时就特别大~与sdc文件应该没有关系。
pad单元的有些电位没接对?查下pad的使用文档
既然PAD的 R 和 F的延时相差如此之大，是不是说PAD使用的方法的问题呢?
DC来分析setup time slack的时候，是用max来分析的，所以挑了个RF延时较大的delay加入计算。
但是实际应用的时候，这种情况很少，或者和设计违例无关（不好意思，写到这儿忘记了您刚刚说的是R大还是F大了，抱歉！）。
比如这类pad使用的时候，上拉或者下拉。对外输出是 常高 只需要关心 F 或者是 常低 只需要关心 R 的时间。
这种情况下，DC都拿最紧的时间预算来分析就不正确了。一点个人的看法。
抱歉，昨天没有认真看你的贴的时序报告，就只是看到slack负得太恐怖了，就随口回了一句。
解决方法，我个人觉得一你去掉这一级pad（反正PAD也是你自己选的），只综合core里面的，手动计算一下delay。也或者这条路径是mutipath，PAD上的值变化并不多。
或者不要管这条路径了，false_path，相比还是前面一种安全一点。
非常感谢大家的回答，我再去研究研究~
谢谢了，这个答案非常正确，结合电路的实际情况考虑了下，这个负slack的确无关紧要。
不客气，很高兴对你有帮助！
看看来
学习了，，谢谢
学习了
小编一个问题两个贴，问题好像是解决，能不能总结一下?
另一个帖子及其答案：
http://bbs.eetop.cn/viewthread.p ... ;highlight=DC%2Bpad
PAD通常设成dont_touch;
看起来你的lib文件中关于上下拉的值的计算只考虑了上下拉电阻本身的因素；
你要结 ...
fly_haopp 发表于 2010-11-1 16:28
非常感谢，这个答案很正确，我跟做电路的沟通了一下，的确是可以忽略这个违规。另外从人家那了解到：
如果是带上下拉的pad，（CMOS push-pull）输出的话，分几种情况：
1. 作为输出的时候上拉或者下拉都disable，那么相应的timing可以忽略；
2. 作为输出时上拉enable，下拉disable，那么只需要关心上拉的cell_fall timing;
3. 作为输出时下拉enable，上拉disable，那么只需要关心下拉的cell_rise timing;
4. 作为输出时上下拉都enable，design有问题！