FIFO depth calculation and schme architecture for CLOCK DOMAIN CROSSING

Question: Data is coming out from Design A which runs at a clock speed of 10 MHz A at a rate of 10 MHZ. This data is needed to be send to Design B which runs at clock rate of 5MHz.

What is the scheme to tranfer this data safely from one clock domain clock rate of 10MHz to the other clock domain which has clock rate of 5MHz ? The clocks of both the domains are independent.

Can we go through a mechanism of using a FIFO? If yes, how to calculate the depth of the FIFO in this case? What will be the implementation of the logic that will be associated to tranfer the data from one clock domain to anothe clock domain?

You can't calculate the FIFO depth only with clock information. You need a read and write rate, or you can make a FIFO which can stop the sender from transmitting the data when the FIFO is full.

Design a FIFO which, on the write side, has 10MHz clock and a "full" status bit, and on the read side, has 5MHz clock and an "empty" status bit. When write side writes data into FIFO, it checks the "full" bit before writing. Similarly, on the read side, read happens only when "empty" bit is not asserted. Write and read pointers of FIFO can be passed to the other side using gray code.

Things can be more complicated if Design A can't stop sending data if needed. It then may require to have a certain fifo depth to absorb the data from Design A in a burst fashion.

Hi

Ltostinxlation : I have provided the data OUTPUT rate FROM clock domain A as 10 MHz. and data entry rate at clock domain B as 5MHz. SO the problem is complete.

For ebuddy: The question was to design that FIFO. So you need to provide the depth of that FIFO? How will decide the depth of the FIFO with the ful end empty signal? Why do we use grey code for write and read pointers?

Regards

ASIC_intl said:

Hi

Ltostinxlation : I have provided the data OUTPUT rate FROM clock domain A as 10 MHz. and data entry rate at clock domain B as 5MHz. SO the problem is complete.

Click to expand...

Hmmm, really ?
Do you understand a clock speed and data rate are two different things ?

But if you insist that is the data rate assuming the data comes and goes every clock cycle, what do you mean by how to calculate the FIFO depth ?
Even though you had 1 million entries in the FIFO, it will overflow unless you have a flow control. And if you have a flow control on free running data, FIFO depth doesn't matter. Therefore, the question on FIFO depth doesn't make sense to me.

Hi lostinxlation

Why write and read pointers of FIFO are passed to the other side using gray code during clock domain crossing?

Regards,

---------- Post added at 10:35 ---------- Previous post was at 10:34 ----------

Hi ebuddy

It is complicated because A can't stop sending data if needed. How will you do this in this case? PLease elaborate. Can you guide to me a general procedure of deciding FIFO depth?

OK, let's alter the question a little bit, to better explain it. Let's say nothing changes except B side is running at 1MHz, instead of 5MHz, so the rate of clock A to clock B is 10:1.

First of all, if data from A side entering FIFO at a faster pace than B side taking data out of FIFO, then data will accumulate in FIFO, until FIFO overflows. So A side must have some idle clock cycles where there is no data going into FIFO, and on average, the rate that data enter the FIFO has to be the same as the one data coming out of FIFO. Let's keep that in mind.

Now consider this scenario: clock A brings data into FIFO at its cycle 1 to 5, and its cycle 6-50 are idle; clock B, meanwhile, takes data out of FIFO on every clock cycle. Since the rate of clock B is 1/10 of clock A, it becomes obvious that data accumulate in FIFO at the beginning, and then get depleted. This is exactly the role FIFO is playing here - to absorb burst data and pass them to other clock domain.

The minimum FIFO depth depends on the how "bursty" the data flow is. In the example above, we need buffer 5 entries of data in FIFO. If data flow from A side is more bursty, for example, clock A carries data at cycle 1 to 50, and cycle 51 to 500 are idle, then your FIFO needs to be bigger (several entries fewer than 50), to store the data.

Hope this explanation can give you a pretty good picture.

Hi ebuddy

1. Why write and read pointers of FIFO are passed to the other side using gray code during clock domain crossing?

2. Can you guide to me a general procedure of deciding FIFO depth?

ASIC_intl said:

Why write and read pointers of FIFO are passed to the other side using gray code during clock domain crossing?

Click to expand...

Because the pointer sequence 000 -> 001 -> 010 -> 011 -> .... may end up in 000 -> 001 -> 011 ... due to the clock skew.

It is complicated because A can't stop sending data if needed. How will you do this in this case? PLease elaborate. Can you guide to me a general procedure of deciding FIFO depth?

Click to expand...

If A cannot stop sending data and the data keeps comming every cycle, you'll lose some data no matter how deep the FIFO is. A has to have the ability to stop sending the data, or A must have some idle cycles which makes overall input data rate match the output data rate. FIFO depth matters only in the latter case.

Hi

The grey coding is for crossing the counter output safely from write clock domain to read clock domain or vice versa. Is not it?

Perhaps I can expand on the advice from lostinxlation and ebuddy.
To determine a minimum FIFO depth, there is an additional factor which you need to quantify - indicated by ebuddy as "burst". Depending on your application, you may have 3 more terms for describing this variable, one might be called a packet size or a block size, the second is the difference in data rate between the worst case (slowest over the long term) receiving data rate and the fastest (over the long term) transmitting data rate, the third is the long-term time interval over which the system must operate before data is lost. Here's a couple of examples which illustrate how you would use 'block' or 'packet' size to determine the minimum FIFO depth.

In an Instrumentation application, you're designing one of many remote data collection transmitters. Regular triggering events occur, for each event, the unit has a block of data to send which contains up to n bytes of data (the data is only valid if the block of data remains coherent but a whole block may be discarded if the buffer is full). In this case, the minimum FIFO depth is just n bytes.
But if the same instrument was not expected ever to discard data, then the receiver's data rate will clearly be as high as the transmitter's data rate (irrespective of clock speeds), so the minimum FIFO depth is determined by the difference between the fastest transmission rate (bytes/sec) and the slowest receiving rate multiplied by the time period (secs) over which the system must operate before data is lost.

You're designing a point of sale terminal in which each transaction has a maximum data block size of n bytes, and where every transaction must be processed faultlessly, but which may go into 'sleep' mode between transactions when the buffer is full (ie less than one block free, not an 'overflow'). In this case, the minimum FIFO depth is n.
If you require the terminal to guarantee availability for a minimum number of consecutive transactions, then miimum FIFO depth is n * avails.
If you require the terminal to have guaranteed availability over a full business day, then the minimum FIFO depth is determined by the difference between the fastest transmission rate (byes/sec) and the slowest receiving rate multiplied by the length of the working day (in seconds).

The clock rates do not come into these calculations, but I hope it has become clear that the buffer may have to be very large if the receiving data rate cannot be maintained close to the transmission rate.

Further analysis of the worst case actual data flow is required.

In Calculating FIFO Depth (the link), there they have written designing a FIFO. But this seems to wrong and not work when continously bursts of different size is coming.

Do you also think that it is wrong if B there is the worst case burst size. The calculation fails if bursts of size B is coming contimuously.

I agree that the link you provided is unreliable and over-simplifies the question.
Perhaps a fixed size (packet) and rate (speed) would apply in some applications. In many real-world applications they do not.
I strongly urge taking a more thorough analysis of the actual variables in your application and to very carefully identify all of the worst-case conditions which must be processed faultlessly.

Some common mistakes includes forgetting to allow for the additional bandwidth required in dealing with corrupt / incomplete packets, or re-sending data following conflicts arising from contention issues, or re-sending & duplicating data after detecting a data error, or failing to allow for the reduced read rate during interrupt handling and other 'hidden' processes. They all add to the requirement for bigger buffers!
If you could provide more information about the task then I'm sure some on here would be able to give reliable advice.

ASIC_intl said:

Hi

The grey coding is for crossing the counter output safely from write clock domain to read clock domain or vice versa. Is not it?

Click to expand...

When the pointer crosses the clock domain, the 2nd transition in above sequential code, which is supposed to be 01 -> 10, may go 01 -> 11 where bit1 successfully changes but bit0 fails to do so. It's due to the fact 2 bits changing at the same time and there might be a small clock skew between the flops receiving the 2 bit pointer.
This problem doesn't exist with gray code since gray code changes only 1 bit at a time.

Some documents say that the grey code is used for metastability issues and not what lostinxlation is replying. Can anybody/lostinxlation explain this?

We really need to know more about the actual equipment which you are attempting to interface with the different clock rates. It will help to ensure that advice given is appropriate to your application.

Grey code has a few useful applications, including FIFO buffer pointers, specifically where it is possible for the one pointer to be read/written by one device during a read/write cycle of the other device. At present, ony you know if that is a possible event in your circuits. Perhaps you have inhibited the read logic in hardware during write cycles? Perhaps you are implementing a boolean ready/wait flag in firmware? Perhaps you are exchanging reuseable packet ID numbers in software, which one application uses instead of directly addressing the FIFO pointer?

I have NOT used Grey code for FIFO pointers where there has been substantial blocks of data in each 'transaction'/'event'. In those applications I have disabled the lower priority application while the entire block of data is being written/read by the higher priority application. Of course, a boolean ready/wait flag doesn't require any coding to be resilient to the state-change of one bit edges!

Hi DXNewcastle

I want to learn about designing a FIFO for clock domain crossings. Do you have nay proper document location from where I can learn it. I tried to learn from Calculating FIFO Depth (the link), but I saw in many situations tghis will fail.

The purpose for me writing in this blovk is to learn it.

I always find that the counters are grey coded in clock domain crossings using a FIFO. It is demanded that it is must. But what is the reason that grey code is must? Do you want to demand you have experienced in designing FIFO for clock domain crossings with counters that are not grey coded?

I do not have any documents and cannot help with your learning.
If you have a specific circuit or application in a real-world problem, then I will try to help, but you must provide the details.

I can only repeat my very general reply above: yes, when transferring data between asynchronous systems there are several methods of ensuring systems are resilient to loss and errors. There are alternative methods to gray coding FIFO pointers. There may be more than one successful implementation of solutions to a specific application and the choice of strategy should follow from an assessment of the overall system.

Hi DXNewcastle

Is it true that data are passed from one clock domain to another clock domain using FIFO if read clock is faster than write clock?

"Is it true . . . ?"
If you still cannot provide any details of a specific system then I can only answer in a very general way: Yes, it is possible. The FIFO may only be used to a depth of one byte, and a lot of people wouldn't call that a FIFO buffer, but its possible. Does that make it "true"?

I have tried to show you that there are other strategies for solving the task, and I have tried to warn you that there are other factors which increase the depth of a buffer beyond just read and write clock rates. I can't see what further help I can give unless you provide details of a specific system.