Asynchronous FIFO cdc question
1) Why there is no multi-bit synchronization problem for slow clock domain ?


The point with a gray counter is that if only one bit changes at a time, you can either see the old value or the new value, but never a wrong value.
If we have a fast counter that changes 0001,0011,0010 within one slow clock cycle, the slow reader sees either 0011 or 0010 and calculates a change of 1 or 2, but in any case reads a valid counter value, albeit one clock cycle later or earlier. There is no chance to get a mix-up between the different counter values because the bits change at very different times.

Compare to a regular counter that changes 0110, 0111, 1000 the receiver sees 0111 or 1000, but could also see a 0110 when reading during the switching phase of the counter.


  2) why "The depth of the FIFO is therefore required to be at least 10 cycles, 5 in each direction for updating the pointer" ?


In principle it is possible to run such a FIFO even with a depth of 1 word only. This will work, but introduces long dead times were no new word can be written to the FIFO: After writing one word, the FIFO is full. The write counter needs update (1 clock cycle) information that one word has been written needs to be transferred to the other clock domain (2-3) and the word has to be read (1). Now this information has to propagate in the opposite direction with the same delay of another 5 clock cycles. This means with our example of a 1-word deep FIFO, one word can be transferred each 10 clock cycles only. To overcome these dead times, the FIFO has to be large enough that it never runs full or empty, which means it has to hold at least 10 words - after the tenth word the input side knows that the very first word has been read and there is again space in the FIFO.

Naturally, this holds only if no side stops writing or reading or the clocks are very different.


  3) Why is the asynchronous FIFO driven with wclk clock from write domain ?


It looks like this is a FIFO with asynchronous read. If the memory is fully synchronous, the read side has to be read using rclk.


  and why rinc does not "AND" with !rempty ?


This looks like an error to me. Either there needs to be some external logic preventing read-when-empty and write-when-full - or we assume the wptr and rptr boxes do take care about this issue.