regarding synchronization

hi all,

I have a counter running at 50 Mhz . Now i have to sample that counter
at 77 Mhz.

My question is can i sample the counter running at 50 mhz directly
with 77 mhz clock or should i synchronize the 50 mhz counter to 77 mhz
clock domain and then only sample it.

what are the effects if i don't the sample the 50 Mhz counter and i
directly sample with 77 Mhz.

rgds,
prav

prav

You're going to have problems doing this no matter how you try.

Don't forget Nyquist theorem, you should sample a signal at least twice as
fast as it itself is expected to change. (i.e. 100MHz in your case)

Anyways - What's the purpose of your project?

Ben

"prav" <> wrote in message
news: om...
> hi all,
>
> I have a counter running at 50 Mhz . Now i have to sample that counter
> at 77 Mhz.
>
> My question is can i sample the counter running at 50 mhz directly
> with 77 mhz clock or should i synchronize the 50 mhz counter to 77 mhz
> clock domain and then only sample it.
>
> what are the effects if i don't the sample the 50 Mhz counter and i
> directly sample with 77 Mhz.
>
> rgds,
> prav

Benjamin Todd

"Benjamin Todd" <> wrote in message
news:c0v7n3$ldk$...

> > I have a counter running at 50 Mhz. Now i have to
> > sample that counter at 77 Mhz.

> You're going to have problems doing this no matter how you try.

Agreed.

> Don't forget Nyquist theorem, you should sample a signal at least twice as
> fast as it itself is expected to change. (i.e. 100MHz in your case)

I think we're OK - if the OP is sampling the *output* (count value)
of a counter clocked at 50MHz, then 77MHz is enough. Nyquist would
get in the way if he were trying to sample the 50MHz *clock*.

> > My question is can i sample the counter running at 50 mhz directly
> > with 77 mhz clock or should i synchronize the 50 mhz counter to 77 mhz
> > clock domain and then only sample it.

Presumably you don't need to see the counter's value on EVERY edge
of the 77MHz clock?

> > what are the effects if i don't the sample the 50 Mhz counter and i
> > directly sample with 77 Mhz.

Think about the timing diagram, complete with the counter's
clock-to-output delays. Your 77MHz clock will sample at essentially
a random point in the 50MHz cycle. For some part of that 20ns 50MHz
cycle, the counter output will be changing as the result of a recent
clock pulse - let's guess that this will happen for up to 3ns after
the clock. Therefore, you have a 3 in 20 (15%) chance that the
77MHz clock will sample a value that's in transition, and therefore
completely unreliable.

It is not good enough simply to sample your counter into the 77MHz
clock domain before reading it, because that sampling process
suffers exactly the same problems that I've already mentioned.

You need either a handshaking mechanism, or else an asynchronous
FIFO. I guess that in your case the FIFO is probably overkill.

There are many possible handshake schemes. In any case you will
need a temporary holding register, clocked by the 50MHz clock.
When the 77MHz side wants a value, it sets a flag which causes
the 50MHz holding register to be enabled. As a result of this
flag, the 50MHz side must:
- wait for one 50MHz clock, to protect against the possibility
that the flag was set very close to a clock edge
- on the following 50MHz clock, copy the counter into the holding
register: note that this all happens in the 50MHz domain so it's OK
- on that same clock, clear the handshake flag
Meanwhile the 77MHz side, having set the flag, waits for it to clear;
as soon as the flag is cleared again, it can take a copy of the
holding register because that register is then known to be stable.

The big problem with this scheme is that the flag must be set by the
77MHz clock, but cleared by the 50MHz clock. Everything else is
purely synchronous logic in one or the other clock domain. For
a good idea on how to do this set/clear flag, do a Google search
for "Weinstein Flancter" and enjoy

Finally, the scheme I've suggested gives quite long latency,
and you may want to reduce that. This is possible by using a
FIFO, triple swinging buffer, or various other ideas. For a
good discussion of the problems you encounter when designing
such things, take a look at the paper on FIFO design by
Peter Alfke and Cliff Cummings:
http://www.sunburst-design.com/paper...FO2_rev1_1.pdf

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

Jonathan Bromley wrote:

> "Benjamin Todd" <> wrote in message
> news:c0v7n3$ldk$...
>
>> > I have a counter running at 50 Mhz. Now i have to
>> > sample that counter at 77 Mhz.
>
>> You're going to have problems doing this no matter how you try.
>
> Agreed.

In the general case, agreed. It all depends on what OP wants to achieve.

>
>> Don't forget Nyquist theorem, you should sample a signal at least twice
>> as fast as it itself is expected to change. (i.e. 100MHz in your case)
>
> I think we're OK - if the OP is sampling the *output* (count value)
> of a counter clocked at 50MHz, then 77MHz is enough. Nyquist would
> get in the way if he were trying to sample the 50MHz *clock*.
>
>> > My question is can i sample the counter running at 50 mhz directly
>> > with 77 mhz clock or should i synchronize the 50 mhz counter to 77 mhz
>> > clock domain and then only sample it.
>
> Presumably you don't need to see the counter's value on EVERY edge
> of the 77MHz clock?
>
>> > what are the effects if i don't the sample the 50 Mhz counter and i
>> > directly sample with 77 Mhz.
>
> Think about the timing diagram, complete with the counter's
> clock-to-output delays. Your 77MHz clock will sample at essentially
> a random point in the 50MHz cycle. For some part of that 20ns 50MHz
> cycle, the counter output will be changing as the result of a recent
> clock pulse - let's guess that this will happen for up to 3ns after
> the clock. Therefore, you have a 3 in 20 (15%) chance that the
> 77MHz clock will sample a value that's in transition, and therefore
> completely unreliable.

Not necessarily _completely_ unreliable. Remember the Gray coding of
a counter in which only one bit changes at a time ? In that case
you have a reliable sampling which is N or N+1 at the transition.
(still need some timing margin for recovering from metastability though)

>
> It is not good enough simply to sample your counter into the 77MHz
> clock domain before reading it, because that sampling process
> suffers exactly the same problems that I've already mentioned.
>
> You need either a handshaking mechanism, or else an asynchronous
> FIFO. I guess that in your case the FIFO is probably overkill.
>

Or a Gray code thus.

> There are many possible handshake schemes. In any case you will
> need a temporary holding register, clocked by the 50MHz clock.
> When the 77MHz side wants a value, it sets a flag which causes
> the 50MHz holding register to be enabled. As a result of this
> flag, the 50MHz side must:
> - wait for one 50MHz clock, to protect against the possibility
> that the flag was set very close to a clock edge
> - on the following 50MHz clock, copy the counter into the holding
> register: note that this all happens in the 50MHz domain so it's OK
> - on that same clock, clear the handshake flag
> Meanwhile the 77MHz side, having set the flag, waits for it to clear;
> as soon as the flag is cleared again, it can take a copy of the
> holding register because that register is then known to be stable.
>
> The big problem with this scheme is that the flag must be set by the
> 77MHz clock, but cleared by the 50MHz clock. Everything else is
> purely synchronous logic in one or the other clock domain. For
> a good idea on how to do this set/clear flag, do a Google search
> for "Weinstein Flancter" and enjoy

But thats for newsgroups on electronics :-p

>
> Finally, the scheme I've suggested gives quite long latency,
> and you may want to reduce that. This is possible by using a
> FIFO, triple swinging buffer, or various other ideas. For a
> good discussion of the problems you encounter when designing
> such things, take a look at the paper on FIFO design by
> Peter Alfke and Cliff Cummings:
> http://www.sunburst-design.com/paper...FO2_rev1_1.pdf
>
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW,
> UK
> Tel: +44 (0)1425 471223 mail:
>
> Fax: +44 (0)1425 471573 Web:
> http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

--
Jos De Laender

Jos De Laender

hi Jos,

"Jos De Laender" <Voornaam.AchternaamMetUnderscoreVoorSpatie@Pandor a.Be>
wrote in message news:skaZb.7300$...

[...]
> > Think about the timing diagram [...]
> > you have a 3 in 20 (15%) chance that the
> > 77MHz clock will sample a value that's in transition, and therefore
> > completely unreliable.
>
> Not necessarily _completely_ unreliable. Remember the Gray coding of
> a counter in which only one bit changes at a time ? In that case
> you have a reliable sampling which is N or N+1 at the transition.
> (still need some timing margin for recovering from metastability though)

I have to admit that when I wrote the reply I didn't think about
Gray coding. But there were two good reasons for that:

1) Someone suggested converting the binary count to Gray, shipping
it across the clock boundary and converting back. This doesn't
work unless the binary-to-gray conversion is registered; if you
take an incoherent binary count and re-code it as a Gray code,
it will remain incoherent. I do indeed know that no professional
would ever make this mistake, but a newbie reading the suggestion
might easily do so.

2) As you point out, the Gray solution is not general. I've been
bitten too many times by someone taking a special-purpose
solution ("It's worked for years, it must be OK") and then
mistakenly applying it to a new situation ("It's only a tiny
change, just that the counter counts up in steps of 19 now").

[...]
> > For
> > a good idea on how to do this set/clear flag, do a Google search
> > for "Weinstein Flancter" and enjoy
>
> But thats for newsgroups on electronics :-p

Pah. They wouldn't know a clock domain if they tripped over
its boundary
--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

Jonathan Bromley wrote:

> hi Jos,
>

<snip>

> 2) As you point out, the Gray solution is not general. I've been
> bitten too many times by someone taking a special-purpose
> solution ("It's worked for years, it must be OK") and then
> mistakenly applying it to a new situation ("It's only a tiny
> change, just that the counter counts up in steps of 19 now").

But for sure OP , just as all of us , would document into boring detail and
linked into an unseparatable way from the design code, what were his
assumptions at design time , what are the limitations of its implementation
etc. So the problem you mention is unlikely :-p Why did I bump nevertheless
in comparable problems ?

>
> [...]
>> > For
>> > a good idea on how to do this set/clear flag, do a Google search
>> > for "Weinstein Flancter" and enjoy
>>
>> But thats for newsgroups on electronics :-p
>
> Pah. They wouldn't know a clock domain if they tripped over
> its boundary

)))))

--
Jos De Laender

Jos De Laender