Question about synchronization

[googler]

I have the following scenario. There are two clock domains A and B.
Clock A is much faster than clock B (26 MHz vs 3 MHz for example).
There is a data line (1 bit) that goes from domain A to domain B,
where it first passes thru a synchronizer (2-stage) and then used. Is
there any requirement that the signal cannot change at domain A for at
least 2 clock B periods in order to work properly? Thanks.

 

[Muzaffer Kal]

On Sun, 20 Jul 2008 18:54:19 -0700 (PDT), googler
<pinaki_m77@yahoo.com> wrote:

I have the following scenario. There are two clock domains A and B.
Clock A is much faster than clock B (26 MHz vs 3 MHz for example).
There is a data line (1 bit) that goes from domain A to domain B,
where it first passes thru a synchronizer (2-stage) and then used. Is
there any requirement that the signal cannot change at domain A for at
least 2 clock B periods in order to work properly? Thanks.

If you want to catch every single pulse from domA with clockB, then
the width of the pulse should be at least slightly larger than a
period of clockB (ie ~ Tb + holdB). This way even if you violation
setup of receiving flop in domB, you will have have one good pulse in
the next cycle. Two Tb is also sufficient but not necessary.

 

[googler]

On Jul 20, 10:58 pm, Muzaffer Kal <k...@dspia.com> wrote:

On Sun, 20 Jul 2008 18:54:19 -0700 (PDT), googler

pinaki_...@yahoo.com> wrote:
I have the following scenario. There are two clock domains A and B.
Clock A is much faster than clock B (26 MHz vs 3 MHz for example).
There is a data line (1 bit) that goes from domain A to domain B,
where it first passes thru a synchronizer (2-stage) and then used. Is
there any requirement that the signal cannot change at domain A for at
least 2 clock B periods in order to work properly? Thanks.

If you want to catch every single pulse from domA with clockB, then
the width of the pulse should be at least slightly larger than a
period of clockB (ie ~ Tb + holdB). This way even if you violation
setup of receiving flop in domB, you will have have one good pulse in
the next cycle. Two Tb is also sufficient but not necessary.

Thanks for the reply. I have a similar question now, but in the
context of asynchronous FIFO. I have designed an asynchronous FIFO in
which write happens on the faster clock A and read happens on slower
clock B. I am using Gray-coded pointers for write and read. I need to
pass each pointer to its other side for status computation. So I am
passing each bit of the write pointer thru synchronizer to the read
side, where it is used to compute if the FIFO is 'empty'. Similarly, I
am passing each bit of the read pointer thru synchronizer to the write
side, where it is used to compute if the FIFO is 'full'. Is this the
correct way to do it? I had read that this is the most common way to
design asynchronous FIFO _without worrying about relative frequencies_
of the two clocks. Is that right? If that is true, then that means it
will also work for the case I described in my last post? For example,
if the write side is on faster clock, do I still need to make sure
that the Gray-coded write pointer (in domain A) does not change before
two clock periods of clock B? Thanks for any information on this.

 

[gabor]

On Jul 21, 12:50 am, googler <pinaki_...@yahoo.com> wrote:

On Jul 20, 10:58 pm, Muzaffer Kal <k...@dspia.com> wrote:

On Sun, 20 Jul 2008 18:54:19 -0700 (PDT), googler

pinaki_...@yahoo.com> wrote:
I have the following scenario. There are two clock domains A and B.
Clock A is much faster than clock B (26 MHz vs 3 MHz for example).
There is a data line (1 bit) that goes from domain A to domain B,
where it first passes thru a synchronizer (2-stage) and then used. Is
there any requirement that the signal cannot change at domain A for at
least 2 clock B periods in order to work properly? Thanks.

If you want to catch every single pulse from domA with clockB, then
the width of the pulse should be at least slightly larger than a
period of clockB (ie ~ Tb + holdB). This way even if you violation
setup of receiving flop in domB, you will have have one good pulse in
the next cycle. Two Tb is also sufficient but not necessary.

Thanks for the reply. I have a similar question now, but in the
context of asynchronous FIFO. I have designed an asynchronous FIFO in
which write happens on the faster clock A and read happens on slower
clock B. I am using Gray-coded pointers for write and read. I need to
pass each pointer to its other side for status computation. So I am
passing each bit of the write pointer thru synchronizer to the read
side, where it is used to compute if the FIFO is 'empty'. Similarly, I
am passing each bit of the read pointer thru synchronizer to the write
side, where it is used to compute if the FIFO is 'full'. Is this the
correct way to do it? I had read that this is the most common way to
design asynchronous FIFO _without worrying about relative frequencies_
of the two clocks. Is that right? If that is true, then that means it
will also work for the case I described in my last post? For example,
if the write side is on faster clock, do I still need to make sure
that the Gray-coded write pointer (in domain A) does not change before
two clock periods of clock B? Thanks for any information on this.

First of all, the Gray-coded pointers need to be synchronized in their
own clock domain before re-synchronizing in the other domain. i.e.
if you follow the standard practice of generating the Gray-code from
a binary counter output, you cannot feed the combinatorial output from
the binary to Gray conversion directly to the other clock domain as
this will have decoding glitches in it. If your Gray-coded pointers
are actually directly generated as a Gray-code counter (unusual) you
don't need the extra synchronization.

Secondly in the case of the FIFO you don't need to guarantee multiple
clock period stability of the pointers, just realize that at the next
edge of your clock B the value of the pointer may have changed by more
than one step. As long as you have logic to prevent overflow of the
FIFO this is perfectly O.K.

HTH,
Gabor