VHDL Clock Domains

No, this is not the best method. Actually, this not a good method at all. Two alternatives:

One, general case : you should put a FIFO buffer with pointers and everything... Once a FIFO reaches some depth, you flush it with slow clock.

Two, more "special" case : if your data arrives once in a period of time which is more than 3 slow clock cycles, there are some nice things we can do using asynchronous reset of a FF :-) if you really want to go with this one, let me know. It's a nice working solution.

What is the data transmission rate & how bursty the transmission is?

Vladislav

If your fast data are coming in a burst you have to use a FIFO.

If your fast signal is just one clock cycle high make it longer so that the slower clock domain can sample it. If this sampled signal is used to change for example a state in a FSM (slow clock domain) it is no problem.

BUT Question: What if the signal in the slow clock domain should also be one clock cycle high ?=20

Rgds Andr=E9

Make a synchronizer and a synchronous level change detector on the fast clock.

-- Mike Treseler

And since he didn't say why it is not a good method...

If your clk_rd and clk_wr are asynchronous (you don't actually mention whether they are), then this method is guaranteed to corrupt the data. Let's look at why.

You get a strobe_in and generate a fast_event and capture the data. These signals travel to the registers that make up slow_clock_process, each signal taking slightly different amounts of time due to routing. Some of the fast_column signals go faster than fast_event, and some go slower.

A clk_rd event happens to occur in the time between when fast_event has arrived, but not all of the fast_column signals. If the clocks are truly asynchronous, this is guaranteed to happen occasionally. The fast_event causes slow_event to be captured, but only part of the slow data, because not all the fast data has arrived yet.

On the next clk_wr, the fast process sees the slow_event flag and takes away fast_event.

There are a number of possible solutions, but the best solution depends to a large extent on the characteristics of when the fast data arrives, and the relative clock speeds.

Also, I should point out that since fast_event goes to all the slow side registers, it arrives at each individual register at different times, which is another source of asynchronous problems.

There is a simple rule for situations where that can happen. If a control signal crossing a clock domain goes to multiple places, then it must go through a synchronizing flipflop first.

Hi Brad,

I've always like this paper as a good introduction to intra-domain transfers:

There are some other papers from the same author that are pretty good too.

Regards,

Paul Leventis Altera Corp.