Forums

multiple clock domain

Started by dargo January 12, 2009
Hello,

I have a design with 2 clocks provied to my FPGA (Spartan 3-A). 
The first one comes from an external oscillator @ 50MHZ. 
The second one also comes from an external BUS clock (75MHZ).

The 75MHZ is the main system clock. It is used to feed an internal AMBA
bus.
The 50MHZ is needed to compute with precision a frame (customer need) with
a very low BER.

How can I synchronize those two clocks domains? I was thinking about a
XILINX DLL...

Could anyone help me?

Thanks,
Dargo
dargo wrote:
> > I have a design with 2 clocks provied to my FPGA (Spartan 3-A). > The first one comes from an external oscillator @ 50MHZ. > The second one also comes from an external BUS clock (75MHZ). > > The 75MHZ is the main system clock. It is used to feed an > internal AMBA bus. The 50MHZ is needed to compute with precision > a frame (customer need) with a very low BER. > > How can I synchronize those two clocks domains? I was thinking > about a XILINX DLL...
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. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.
On Jan 12, 4:56=A0pm, "dargo" <fpga_a...@yahoo.fr> wrote:
> Hello, > > I have a design with 2 clocks provied to my FPGA (Spartan 3-A). > The first one comes from an external oscillator @ 50MHZ. > The second one also comes from an external BUS clock (75MHZ). > > The 75MHZ is the main system clock. It is used to feed an internal AMBA > bus. > The 50MHZ is needed to compute with precision a frame (customer need) wit=
h
> a very low BER. > > How can I synchronize those two clocks domains? I was thinking about a > XILINX DLL... > > Could anyone help me? > > Thanks, > Dargo
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
>On Jan 12, 4:56=A0pm, "dargo" <fpga_a...@yahoo.fr> wrote: >> Hello, >> >> I have a design with 2 clocks provied to my FPGA (Spartan 3-A). >> The first one comes from an external oscillator @ 50MHZ. >> The second one also comes from an external BUS clock (75MHZ). >> >> The 75MHZ is the main system clock. It is used to feed an internal
AMBA
>> bus. >> The 50MHZ is needed to compute with precision a frame (customer need)
wit=
>h >> a very low BER. >> >> How can I synchronize those two clocks domains? I was thinking about a >> XILINX DLL... >> >> Could anyone help me? >> >> Thanks, >> Dargo > >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 >
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 @ http://www.sunburst-design.com/papers/) (My amba bus will be clocked at 75MHz whereas the output buffer for frame sending purpose is clocked at 50Mhz). Thanks again Dargo
On Jan 13, 6:41 am, "dargo" <fpga_a...@yahoo.fr> wrote:
> > 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 @http://www.sunburst-design.com/papers/)
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
Thanks again for your help!
I progress in my design...AMBA bus is almost ready
Dargo
>On Jan 13, 6:41 am, "dargo" <fpga_a...@yahoo.fr> wrote: >> >> 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 @http://www.sunburst-design.com/papers/) > >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 >