LatticeSemiconductor
Member level 2
I have a CDC from iCLK_SYS to sfXGMII_CLK_156. I am using a FIFO to buffer the data. The fifo is a black box model but appearently there is a counter r_gcount which is probably checking the watermarks or something. This is giving me a critical path as shown below:
Error: The following path exceeds requirements by 0.214ns (weighted slack = -3.424ns)
Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-)
Source: FF Q inst_pmi_txfifo_dc/FF_142 (from iCLK_SYS +)
Destination: FF Data in inst_pmi_txfifo_dc/FF_76 (to sfXGMII_CLK_156 +)
Delay: 0.486ns (46.3% logic, 53.7% route), 1 logic levels.
Constraint Details:
0.486ns physical path delay inst_pmi_txfifo_dc/SLICE_10225 to inst_pmi_txfifo_dc/SLICE_10232 exceeds
(delay constraint based on source clock period of 6.000ns and destination clock period of 6.400ns)
0.351ns delay constraint less
-0.098ns skew and
0.049ns feedback compensation and
0.128ns M_SET requirement (totaling 0.272ns) by 0.214ns
Physical Path Details:
Data path inst_pmi_rxfifo_dc/SLICE_6075 to inst_pmi_rxfifo_dc/SLICE_6081:
Name Fanout Delay (ns) Site Resource
REG_DEL --- 0.227 R63C112C.CLK to R63C112C.Q1 inst_pmi_rxfifo_dc/SLICE_6075 (from iCLK_SYS)
ROUTE 1 0.264 R63C112C.Q1 to R63C112B.M1 inst_pmi_rxfifo_dc/r_gcount_7 (to sfXGMII_CLK_156)
--------
0.491 (46.2% logic, 53.8% route), 1 logic levels.
It does not seem that there is anything that can improve routing in this case:
Image to the left shows the slice in question. The first LUT shows the counter, clocked with sfXGMII_CLK, the second another one, clocked with iCLK_SYS. The signal w_gcount_5 is used in both domains. The Tool assumes both clocks are related but they are not. Can I tell the tool the path is safe? It should, but I can't have a look inside the code to verify.
Error: The following path exceeds requirements by 0.214ns (weighted slack = -3.424ns)
Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-)
Source: FF Q inst_pmi_txfifo_dc/FF_142 (from iCLK_SYS +)
Destination: FF Data in inst_pmi_txfifo_dc/FF_76 (to sfXGMII_CLK_156 +)
Delay: 0.486ns (46.3% logic, 53.7% route), 1 logic levels.
Constraint Details:
0.486ns physical path delay inst_pmi_txfifo_dc/SLICE_10225 to inst_pmi_txfifo_dc/SLICE_10232 exceeds
(delay constraint based on source clock period of 6.000ns and destination clock period of 6.400ns)
0.351ns delay constraint less
-0.098ns skew and
0.049ns feedback compensation and
0.128ns M_SET requirement (totaling 0.272ns) by 0.214ns
Physical Path Details:
Data path inst_pmi_rxfifo_dc/SLICE_6075 to inst_pmi_rxfifo_dc/SLICE_6081:
Name Fanout Delay (ns) Site Resource
REG_DEL --- 0.227 R63C112C.CLK to R63C112C.Q1 inst_pmi_rxfifo_dc/SLICE_6075 (from iCLK_SYS)
ROUTE 1 0.264 R63C112C.Q1 to R63C112B.M1 inst_pmi_rxfifo_dc/r_gcount_7 (to sfXGMII_CLK_156)
--------
0.491 (46.2% logic, 53.8% route), 1 logic levels.
It does not seem that there is anything that can improve routing in this case:
Image to the left shows the slice in question. The first LUT shows the counter, clocked with sfXGMII_CLK, the second another one, clocked with iCLK_SYS. The signal w_gcount_5 is used in both domains. The Tool assumes both clocks are related but they are not. Can I tell the tool the path is safe? It should, but I can't have a look inside the code to verify.