Help on timing closure

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.

Hello, I always async any clock domain so that (in my case) Vivado doesn't try and time the exact path you are having issues with. If you async the two clock domains (please verify you can do that and all your domain crossings are handled properly in your design) this issue will go away as the tool won't be calculating setup/hold between those two registers.

I hope I've read and understood what you've done so far and what you are asking. Please let me know your results.

I marked the path as multicycle to close timing but the system is not stable anymore.

Anyway the FIFO must meet timing to work properly. I can only apply any relaxation if proper CDC takes care of this, like two-way handshake synchronisation

LatticeSemiconductor said:

I marked the path as multicycle to close timing but the system is not stable anymore.

Anyway the FIFO must meet timing to work properly. I can only apply any relaxation if proper CDC takes care of this, like two-way handshake synchronisation

Click to expand...

Are you saying the FIFO doesn't handle the CDC correctly?

It is vendor IP complain to the vendor, if it's your own home grown FIFO then fix it or use the vendor's FIFO IP.

LatticeSemiconductor said:

I marked the path as multicycle to close timing but the system is not stable anymore.

Anyway the FIFO must meet timing to work properly. I can only apply any relaxation if proper CDC takes care of this, like two-way handshake synchronisation

Click to expand...

Wait, why would this be multicycle? if the FIFO guarantees the 'handshake', you can mark the clocks as mutually exclusive.

Did I misunderstand something?

When you use manufacturers ip (async fifo) CDC's handshaking is kinda taken into account. Thus the read_valid signals, read count etc.

I'm with ads-ee on this one. Elevate it to the vendor.

I'm assuming that since he said the FIFO is a black box model and he "can't look inside the code to verify" that it is from the vendor. He should provide some additional information, sounds like a vendor issue.