multiple clock domain

If you need even periods for each half cycle (and complete synchronization), start with a 300 Mhz clock. Divide it by 6 to get 50 Mhz. Divide it by 4 to get 75 Mhz. Everything is synced to the same crystal. This takes 5 flops.

If you don't care about the fine synchronization, you can start with 150 Mhz and divide by 3 and 2. A total of 3 flops.

I think you are saying that the two clocks are supplied and you have no control over either. So you need to move data between the two domains. The best thing to do is to pick one clock to use for the majority of the system and use the other one only as an interface clock. Pick the point of exchange between them that has the fewest number of signals and then design an interface that will prevent (or minimize actually) the possibility of metastability occurring during a data transfer. Otherwise, using multiple clocks is no big deal.

Rick

AMBA

wit=

Thank you Rick for your help. It is indeed the case : I have no manner to control the two clocks supplied. I made some google search on the topic on multi clock domain design. Indeed the metastability is an issue which I will take into account.

Regarding the reset strategy, I think that it is mandatory to have one reset per clock domain, isn't it? Can you comment this point? Do you recommend an asynchronous flip-flop resynchronized reset? (I found some interesting key points @

(My amba bus will be clocked at 75MHz whereas the output buffer for frame sending purpose is clocked at 50Mhz).

Thanks again Dargo

Sure, the whole reset issue is one that I think a lot of designers don't take seriously enough. All resets should be synchronous as asynchronous resets are pointless for synchronous logic. As I see it, there are two approaches to resetting the logic. One is is to divide the clock domain into smaller domains which require synchronous resets to operate correctly, which typically are smaller than the entire clock domain. For example, a data path often does not need to be reset since the data will not be used until it has be set to a known value. If a finite state machine is held in a known state by an input, it needs no reset if the input will be in a known state at reset time, such as from another logic section that is under reset. The other approach is to use a single reset for the entire clock domain.

I have always found it hard to make a good reset circuit using an HDL unless I use an external reset. The trick is to use the global async reset to put two or three sync reset FFs in a known state along with the rest of the design. Then the sync reset FF are used to provide a delayed release sync reset. I typically use a small shift register for this. But I have never found a good way to code this using the global reset (GSR) provided in the chip without driving it from an external signal. If you have an external signal, then you only need to sync it to the internal clocks (which is in essence what the circuit above does). The only other issue would be to make sure the interface between the two clock domains will work correctly regardless of the sequence of release from reset of the two clock domains. That is typically not too hard if you are using state machines to control the interface.

Rick

to

on

some