I was wondering that the reason is of using FIFO in the asynchronous domain in VLSI.
Basically, to prevent x propagation in the asynchronous domain (aka CDC domain), it was taken care of by the two-stage F/F method for resolving the issue.
I think I can use the same idea to the multiple depth data path, but people still use FIFO in the CDC domain. Why?
I want to know what the specific reason is for using FIFO in the Cross Domain Clock.
The FIFO read and write ports can be on different clocks. For systems with asynchronous clocks this solves the basic cross-domain data transfer problem, so long as the FIFO read and write pointers don't cross.
Even if the clocks are the same frequency, isolating large areas in separate timing domains using FIFOs or register slices (that is, shallow FIFOs) eases system timing closure, at the expense of latency. This is especially useful in large SoCs where maintaining clock phase alignment across a large die becomes very difficult, even with careful clock tree design.
For those FIFO boundary cases where flow control comes up (full, almost full, empty, etc), flag generation resolves the clock domain crossing by using special techniques, such as gray-coding, to ensure reliable full/empty calculations within each clock domain.
This cross-boundary flag synchronization adds latency however, so the designer must allocate extra FIFO room to guard against overrun. This can be by using an almost-full indicator, or by adding small FIFO called a skid buffer that catches the extra data emitted by the host during the flag latency time.
Basically, to prevent x propagation in asynchronous domain(aka CDC domain), I was taken care of 2 stage F/F method for resolving issue. I think I can use the same Idea to the multiple depth data path. but People still using the FIFO in CDC domain why?
Usually there's a 3rd FF in there, but we'll let that go for the moment.
The problem with what you've described for multiple data paths (that is, multiple bits, like a 8-bit data word), is that the different paths may resolve the metastable condition that arises differently. So if the input word to the clock crossing circuit is 01010101, what comes out of the 8-bit synchronizer may be something different.
The FIFO designer, if they did their job right, has taken care of those kinds of problems for you.
Also, the FIFO provides storage/buffer for n-bytes/words, while what you've described just works for 1 single piece of data (byte, word, etc).
Why do I need to use Asynchronous FIFO, when there are other clock domain crossing techniques?
Asynchronous FIFO makes synchronization easier when you stream multi-bits of data continuously than individual registers/slices combined, the WRITE and READ works in different clock domain, the faster to slower domain transfers occurs without any data loss with an appropriate depth calculation of FIFO memory, the sampling of WR_PNTR and RD_PNTR across the clock domains happens with reliable technique grey-coding, generate the flags (FULL, EMPTY, ALMOST FULL, ALMOST EMPTY, etc.),
Things to explore:-
--> What are the scenarios, I needed to go for Asynchronous FIFO? --> How do I calculate the depth of FIFO ? --> Why RD and WR pointers are one bit wider than RD and WR address? --> How binary to grey conversion and grey to binary conversion useful here? In short Grey-coding technique? --> What are flag condition (full, empty, etc.)? --> How do I calculate depth when there is no burst rate given? --> How can I make sure, there are no meta-stability in my clock domain crossing design?
http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO1.pdf
