slack为负，为啥经过每个cell的延迟都挺大
这是我的time-report，请大侠帮帮忙，约束哪里设置不合理
Startpoint: U1/mult_141/inst_clk_r_REG225_S1
(rising edge-triggered flip-flop clocked by inst_clk)
Endpoint: U1/mult_141/inst_clk_r_REG132_S1
(rising edge-triggered flip-flop clocked by inst_clk)
Path Group: inst_clk
Path Type: max
Des/Clust/Port Wire Load Model Library
------------------------------------------------
DW_mult_pipe_inst ibm13_wl30 scx3_cmos8rf_lpvt_ss_1p08v_125c
Point Incr Path
--------------------------------------------------------------------------
clock inst_clk (rise edge) 0.00 0.00
clock network delay (ideal) 0.30 0.30
U1/mult_141/inst_clk_r_REG225_S1/CK (DFFSHQX8TS) 0.00 0.30 r
U1/mult_141/inst_clk_r_REG225_S1/Q (DFFSHQX8TS) 0.93 1.23 r
U1/mult_141/U1368/Y (BUFX20TS) 0.45 1.69 r
U1/mult_141/U1473/Y (CLKXOR2X8TS) 0.77 2.45 r
U1/mult_141/U763/Y (INVX16TS) 0.23 2.68 f
U1/mult_141/U534/Y (OAI22X4TS) 0.63 3.31 r
U1/mult_141/U1140/CO (CMPR22X4TS) 0.88 4.19 r
U1/mult_141/U1470/S (ADDFHX4TS) 1.06 5.25 f
U1/mult_141/U1166/Y (MX2X4TS) 0.75 6.00 f
U1/mult_141/inst_clk_r_REG132_S1/D (DFFRX4TS) 0.00 6.00 f
data arrival time 6.00
clock inst_clk (rise edge) 5.00 5.00
clock network delay (ideal) 0.30 5.30
clock uncertainty -0.30 5.00
U1/mult_141/inst_clk_r_REG132_S1/CK (DFFRX4TS) 0.00 5.00 r
library setup time -1.17 3.83
data required time 3.83
--------------------------------------------------------------------------
data required time 3.83
data arrival time -6.00
--------------------------------------------------------------------------
slack (VIOLATED) -2.17
如果我将clk周期设为20ns的话，slack则变为了0，
data required time 18.84
data arrival time -18.84
--------------------------------------------------------------------------
slack (MET) 0.00
是不是约束设的太严格了，需要改哪些约束条件呢
U1/mult_141/U1140/CO (CMPR22X4TS) 0.88 4.19 r
U1/mult_141/U1470/S (ADDFHX4TS) 1.06 5.25 f
这两条路径的延时比较大，看看是不是扇出太多了。
过约束可能会导致时序分析不过，这个很正常，关键是看你到底要跑在什么时钟下。
过约束的时候，工具可能会使用驱动能力较大的单元，要注意的。
library setup time -1.17这个挺大的，你查查有没有超过库里面的查找表范围
学习
学习学习
谢谢啦，果然是库太差了，换个库要好的多
这位大虾，怎么检查其扇出呢，如果扇出太多了，应该怎么加约束呢
扇出太大可以通过优化选项复制寄存器解决下
我觉得：第一是你的速度过快（200MHz），第二你的库的速度过慢，数据通过一个寄存器要将近1ns?（如果不是过驱动的问题的话）。所以用一个慢库的器件去实现高速的功能，就造成了lz现在的问题。
11# sagegao
谢谢高手，如果是驱动的问题，应该怎么解决呢
约束太紧了
多谢啊 了解不少
学习了
小编，你好。
这个库太差，请问你是怎么换的呢?