How does multicycle path arise at CDC even when we use asynchronous fifo?

How does multicycle path arise at CDC when we use asynchronous fifo?

When we cross from a faster clock domain to slower domain, we use an asynchronous FIFO to avoid data loss due to slower sampling rate at the receiving clock domain. But in the following post in this forum, it was discussed about setting multicycle path and false path in CDC.

https://www.edaboard.com/threads/134188/

When there is an asychronous FIFO, how does there come a multicycle path or false path? I ask this because, when we write data into the asynchronous FIFO, the data input to the FIFO and FIFO write are in same clock. So no clock domain crossing occurs at this point. When we read data from the FIFO, the read clock and the data fed circuit will be in same clock domain. Again, no clock domain crossing!! Please correct me if I am wrong!!

I ask this because, when we write data into the asynchronous FIFO, the data input to the FIFO and FIFO write are in same clock. So no clock domain crossing occurs at this point. When we read data from the FIFO, the read clock and the data fed circuit will be in same clock domain. Again, no clock domain crossing!!

Click to expand...

data input to the FIFO and FIFO write data are most probably is the same signal/port(?). In most cases it is indicated by din. This works in the write_clk domain. Then on the read_clk domain you have the read data out signal/port indicated by dout. If read_clk and write_clk are not synchronous (in freq and phase and source) then both these clocks should be treated as asynchronous. In an asynchronous case you have to use the false_path constraint.
So there is clock domain cross in the case mentioned above (asynchronous clocks).

I am not very sure about the multicycle path for FIFOs so will not talk about it (probably it arises when size_of{din} is not equal to size_of{dout} ?).

I think you didn't get my question. Forget about multicycle path. Let us talk about false paths!!
Consider the CDC with an asynchronous FIFO.
Data from a register passes through some combinational logic and reaches the data input of the FIFO. The clocks of the register and the write clock of the FIFO are in same domain. So there is no CDC.
Now, come to the FIFO read situation. The data in the FIFO is read and is given to a register through some combinational path. The read clock and the clock to the register are in same domain. Again no CDC.
Since FIFO is a collection of storage registers, it cannot be considered as a combinational logic and there is no data path from register --> FIFO --> register. There can be two paths like register --> FIFO and FIFO --> register. In either case, why should we set a false path??

You have been initially asking about an asynchronous (domain crossing) FIFO, but are discussing a single clock domain FIFO. It shouldn't use false path statements.

Please clarify your question.

As per #1:

When there is an asychronous FIFO, how does there come a multicycle path or false path?

Click to expand...

I will only answer how false path is related to asychronous FIFO.

Now as per OP #3....

So there is no CDC.

Click to expand...

I think you should analyze the FIFO structure more carefully and also read carefully what I have written.
Data crosses over from the registers belonging to the wr_clk domain to the registers of the rd_clk domain. Only after that data is read out of the FIFO. Hence there is CDC.
Read this freely avilable Xilinx documentation carefully : pg057-fifo-generator.pdf (you can leave out the AXI interface sections).

The data in the FIFO is read and is given to a register through some combinational path.

Click to expand...

Why/How do you say this?

Considering a single bit data, a minimum of 3 stage FFs are recommended for data tx from the wr domain to the rd domain. The 1st FF works in the wr_clk domain and then the other 2 FFs works in the rd_clk domain.

See the block diagram in the section 'Single bit — synchronizer with feedback acknowledge' in the following link!
https://www.verilogpro.com/clock-domain-crossing-part-1/

Since there are 2 clocks and data is transferred between producer and consumer, hence we say that paths between async FIFO are CDC paths. In facts, to resolve CDC issues we add FIFO in the design. Once FIFO is in design, we generally tell STA tool (like primetime) that these paths are FIFO paths, please do not time them. Designer has taken care of these paths from design implementations.

Thanks,
Abhishek

FvM said:

You have been initially asking about an asynchronous (domain crossing) FIFO, but are discussing a single clock domain FIFO. It shouldn't use false path statements.

Please clarify your question.

Click to expand...

No. My write and read clocks of the FIFO are different. My question is like, can we split the data path through the FIFO like register --> FIFO write and FIFO read --> register??
In such a case where we can split the data path and see them separately as write and read sides, we need not see any CDC, right?

- - - Updated - - -

abhiverma812 said:

Since there are 2 clocks and data is transferred between producer and consumer, hence we say that paths between async FIFO are CDC paths. In facts, to resolve CDC issues we add FIFO in the design. Once FIFO is in design, we generally tell STA tool (like primetime) that these paths are FIFO paths, please do not time them. Designer has taken care of these paths from design implementations.

Thanks,
Abhishek

Click to expand...

The STA tools consider a data path from a register to register. In the CDC with asynchronous FIFO, is it like the data path is register --> FIFO --> register ??

Re: How does multicycle path arise at CDC when we use asynchronous fifo?

biju4u90 said:

When we cross from a faster clock domain to slower domain, we use an asynchronous FIFO to avoid data loss due to slower sampling rate at the receiving clock domain. But in the following post in this forum, it was discussed about setting multicycle path and false path in CDC.

https://www.edaboard.com/threads/134188/

When there is an asychronous FIFO, how does there come a multicycle path or false path? I ask this because, when we write data into the asynchronous FIFO, the data input to the FIFO and FIFO write are in same clock. So no clock domain crossing occurs at this point. When we read data from the FIFO, the read clock and the data fed circuit will be in same clock domain. Again, no clock domain crossing!! Please correct me if I am wrong!!

Click to expand...

There are some points need to be clear from your questions:

1/ The thread that you mentioned (https://www.edaboard.com/threads/134188/) is about using FF1 and FF2 for synchronizing the data transfer from "fast" clock to "slow" clock.
Those clocks are asynchronous.
Data will runs like this: FF0/CLK1 --> (FF1/CLK2 --> FF2/CLK2) --> FFn/CLK2, and you can ignore the path FF1/CLK1 -> FF2/CLK2.
Or say can use "set_false_path" for them.

2/ If you use an "asynchronous" FIFO, always you can have timing path FFa/CLK1 --> FIFO/CLK1, and FIFO/CLK2 --> FFb/CLK2. You can set fasle path constraint between CLK1, CLK2.

3/ set_multicycle_path is only possible for 2 clocks that are synchronized to each other and
they have specific relationship in functional operation where more than a cycle is required to get the neccesary data.

BR,
Slu

I always found false_path to be weird. I understand that the clocks are different, but there still is a requirement on skew. Two bits of the gray coded pointer can't have a large difference in delays otherwise two bits of the gray coded counter could change on the same cycle. The same is true for any bus really.