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.
Best Answer
If the average input and output data rates are fixed and different, then you will overflow or underflow a FIFO eventually. There is no 'processing' you can use to avoid corrupting data.
What a FIFO does is act as a flexible buffer to take up temporary variations in the data arrival and consumption rate. The FIFO has to be deep (long?) enough so that it can store all of the excess data, and a bit more for margin.
If your input and/or output rates are not externally fixed, then you can use the FIFO to control one or the other. A FIFO will have full and empty flags, and the Xilinx ones have programmable 'nearly full' and 'nearly empty' flags as well. These can be fed back to your data source and/or and sink to tell them to wait. The deeper the FIFO, the longer you can allow a difference in input/output rate to persist before having to throttle the faster connection.