regarding synchronization

[prav]

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]

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

 

[Jonathan Bromley]

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*.

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

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:
www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO2_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: (e-mail address removed)
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]

Agreed.

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

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*.


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


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

 

[Jonathan Bromley]

hi Jos,

"Jos De Laender" <[email protected]>
wrote in message
[...]

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").

[...]

But thats for newsgroups on electronics

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: (e-mail address removed)
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]

hi Jos,

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 Why did I bump nevertheless
in comparable problems ?

[...]

But thats for newsgroups on electronics

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

)))))