新手请教：IP核（eeprom）的时序问题

设计中包含一个EEPROM，用DC综合以及astro布局布线都没有时序问题，但是用encounter就显示eeprom的延时过大，
encounter时序分析如下：

可见eeprom的PRE_CHG到EEDBO1的延时很大，而我的时钟周期只有140，造成严重违例，而从lib中的信息来看，这个延时信息没错啊，我的问题是为什么DC和astro中都没有报错，即为什么没有考虑eeprom这个延时?

下面是eeprom的lib中的信息：
pin(EEDBO1) {
direction : output ;
function :"PRE_CHG " ;
capacitance : 0.000000 ;
max_capacitance : 0.714032 ;
timing() {
related_pin : "PRE_CHG" ;
cell_rise(Table1) {
values(\
"10000.019531, 10000.059570, 10000.089844, 10000.169922",\
"10000.330078, 10000.370117, 10000.400391, 10000.480469",\
"10001.580078, 10001.629883, 10001.660156, 10001.730469",\
"10003.150391, 10003.190430, 10003.219727, 10003.299805",\
"10004.709961, 10004.759766, 10004.790039, 10004.860352"\
);
}
rise_transition(Slew1) {
values(\
"4.482940, 8.836245"\
);
}
cell_fall(Table1) {
values(\
"10000.019531, 10000.070312, 10000.099609, 10000.169922",\
"10000.349609, 10000.400391, 10000.429688, 10000.500000",\
"10001.639648, 10001.690430, 10001.719727, 10001.790039",\
"10003.250000, 10003.299805, 10003.330078, 10003.400391",\
"10004.870117, 10004.919922, 10004.950195, 10005.019531"\
);
}
fall_transition(Slew1) {
values(\
"3.214440, 6.280863"\
);
}
}
}

打开DC，报同样的path，比较结果，找原因

这是DC报的该路径的时序分析，可见DC认为eeprom延时为0……

Startpoint: eeprom_control/state_reg_3_
(rising edge-triggered flip-flop clocked by clock)
Endpoint: read_write_compare_c/state_reg_1_
(rising edge-triggered flip-flop clocked by clock)
Path Group: clock
Path Type: max
PointIncrPath
--------------------------------------------------------------------------
clock clock (rise edge)0.000.00
clock network delay (propagated)5.475.47
eeprom_control/state_reg_3_/H02 (F612NQ)0.005.47 r
eeprom_control/state_reg_3_/N01 (F612NQ)2.928.40 r
eeprom_control/U87/N01 (F202)0.488.88 f
eeprom_control/U86/N01 (F202N1)1.1510.03 f
eeprom_control/U85/N01 (L302)0.5010.54 r
eeprom_control/U131/N01 (L101)0.5111.05 f
eeprom_control/pre_charge (eeprom_control)0.0011.05 f
HMEEPSF256B00V3/EEDBO1 (HMEEPSF256B00V3)0.0011.05 f
eeprom_control/EEDBO1 (eeprom_control)0.0011.05 f
eeprom_control/U153/N01 (F111)0.9111.96 f
eeprom_control/data_from_rom[1] (eeprom_control)0.0011.96 f
read_write_compare_c/data_from_rom[2] (read_write_compare)
0.0011.96 f
read_write_compare_c/sll_198_2/A[1] (read_write_compare_DW01_ash_0)
0.0011.96 f
read_write_compare_c/sll_198_2/M1_0_2/N01 (L565)2.2014.16 f
read_write_compare_c/sll_198_2/M1_1_2/N01 (Y565)2.4616.62 f
read_write_compare_c/sll_198_2/M1_2_6/N01 (Y565)2.4319.06 f
read_write_compare_c/sll_198_2/U19/N01 (L312)1.0620.11 f
read_write_compare_c/sll_198_2/B[6] (read_write_compare_DW01_ash_0)
0.0020.11 f
read_write_compare_c/U234/N01 (L512)1.1221.23 r
read_write_compare_c/U238/N01 (L318)2.1723.39 r
read_write_compare_c/U286/N01 (L312)1.1224.52 r
read_write_compare_c/U10/N01 (L434)0.4825.00 f
read_write_compare_c/U97/N01 (Y216)3.5728.57 f
read_write_compare_c/U98/N01 (Y101)0.7429.32 r
read_write_compare_c/U102/N01 (Y212)1.0230.33 r
read_write_compare_c/U103/N01 (Y101)0.5130.84 f
read_write_compare_c/state_reg_1_/H01 (L612NQ)0.0030.84 f
data arrival time30.84
clock clock (rise edge)140.00140.00
clock network delay (propagated)5.47145.47
clock uncertainty-0.35145.12
read_write_compare_c/state_reg_1_/H02 (L612NQ)0.00145.12 r
library setup time-2.23142.89
data required time142.89
--------------------------------------------------------------------------
data required time142.89
data arrival time-30.84
--------------------------------------------------------------------------
slack (MET)112.05

估计是超过了DC的默认最大值，被强迫置零了
encounter的timing是对的，你要对这种极慢的逻辑单独处理，比如false path，但是要与前端确认

eeprom 有个毛timing啊，都是异步logic吧，设计上可以保证的，

能否具体些?是说只要前端设计能保证功能正确，后端就不用管这个大延时了吗?

是

好的，谢谢指导！