DC综合结果report_timing cell delay问题
背景：我的设计按照bottom-up方式综合的；reference design “intrlv_1024”在上层design “DEC”之下，例化名为”Inst_intrlv“。问题：我单独综合design “intrlv_1024”的时候时序没问题，但是我在综合 “DEC”时将底层设计 “intrlv_1024”导入并且设置dont_touch属性后发现时序在”Inst_intrlv“里面的有些cell_delay的延迟很大，应该是高扇出问题，但是这些cell不在边界上，应该不存在胶粘逻辑，并且我是在DC-T下用compile_ultra综合的，这个指令自带边界优化。具体问题如下截图所示：
“intrlv_1024”的timing report：
“DEC”的timing report：
希望大家遇到过此问题的给个建议或者解决方案，谢谢了
是不是你的负载电容设置很大，set load?
不大呀，我是设置的某个DFF的D端口
把你整个综合脚本贴出来看看
report_timing 多加一些选项，-cap -net -trans -input
以上是我的约束文件
多加选项解决不了问题吧，最多只能增大找到原因的概率而已
The problem of timing violation with setup timing is the critical path to long.
That is the rtl coding issue. Your clcok source was the gate clock. Does you can reduce the clock propagation delay?
我觉得有点问题，首先时钟网络和复位信号都设置成ideal_network，所以复位信号的驱动能力应该设置成无限大set_drive 0 [get_ports "rst ...."]和时钟网络一样，再次是在进行增量编译之前要把子模块的dont_touch去掉。还有你的工作环境设置我不知道是不是放在一个单独的脚本里面了，如果没有的话得加上。上面是我的一点看法。
对于工作环境的设置这一问题，我的工作的逻辑库和物理库已经指定，加上我用的是DC-T，不需要设置WLM，该算法会根据virtual place&route来估计RC，所以应该不需要设置工作环境。你说的对复位信号设置无限大驱动这个约束我先试试，谢了
关键路径在单独的底层模块中是完全满足我的是需要求的，分析我的设计的框图，在顶层应该是不存在关键路径过长过大这一情况的
1. If your sub-module was met of this path. So the timing violation report does the whole chip timing report.2. May be you can check your hide line cell. The AOI and BUFFER cell delay too much. That doesn't make sense.
3. From the item 2, I guess that is the coding issue. May be you can attach you rtl code. We can discussion more detail.
以下是我在DC中查看的关键路径部分信息
fanout违反了我设置的set_max_fanout 10的drc，并且capacitance也违反了我设置的set_max_capacitance 0.3。代码量太大，不方便粘贴在帖子中
我之前没用过DC-T，今天用了一下，有一个在compile_ultra时有个错误：ErrorC-topograpical Failed to link physical library.(OPT-1428).我是用pdb格式的物理库，set physical_library "tsmc18_5lm.pdb",物理库的路径这些都检查过过没问题。不知道你做的时候遇到个这个问题没有?
你check_lib看看结果，应该是你的物理库在配置文件中没有导入，我用的是milkyway的，跟你的有点不一样，pdb的我没用过。我遇到过这个问题，原因就是物理库没导入进去
多加属性还是能看一些问题的，你先加上属性， -nets -cap -trans -input_pins -attr，然后看报告中clock传输的path是不是还是ideal的。感觉在那个大地方就已经不是ideal的了。
先不说多的，要我碰到了这问题就会打开lib，然后根据输入transition还有输出load，在lut里面查看看delay对不对，如果transition或者load超出范围了的话，那就说明那个drc违反得先修复好了再说~
不知道小编碰到这个问题有试着没有这么干~
还有一点，你确定这里的组合逻辑是你代码中想要实现的逻辑吗?rst是不是全部提取出来了，有没有内部reset?
能否看看你的check_timing的报告
在那个大地方本来就不是ideal的吧，我只对clk、rst设置了ideal_network。而Ideal networks are an extension of ideal nets that incorporate automatic propagationoftheidealattribute. the compile command treats all nets, cells, and pins on the transitive fanout of these objectsas ideal.所以我对这个命令的理解是只有与clk、rst fanout相关的是ideal的，不过你说的这个倒是提供了一种思路
check_timing部分截图如下：
今天我查找资料弄了一整天，发现pdb格式的物理库，读不进去，check_lib可以知道物理库读进DC内存中，但是还是一样的显示那个错误。可以把你用milkway设置物理库的脚本贴上来分享一下吗?
多谢
那那个大延迟的原因找到了吗?是因为没设INPUT DELAY产生的?
感觉跟input delay没关系，你仔细看看path，clock经过了一个nor门，你只设了clock是ideal的，但是nor的另一个输入是否也是ideal，如果不是，那么clock的ideal属性是穿不透这个nor的。我想这也是产生那个大delay的原因。像这种跟时钟有组合逻辑的情况，一般都是手动例化的，哪有让工具自动综合的啊，注意！我们一般都是自己例化CLKMUX等等
敢问小编是怎么结局问题的?我也遇到这个问题了。