clock wide pulse transfer b/w clock domains

Hi,

Please suggest me how to transfer a single clockwide pulse from high
frequency clock domain and create a single clockwide pulse in a slow
clock domain?
What are different methods available?

Thanks in advance.

Regards,
Himassk.

himassk wrote:
> Hi,
> 
> Please suggest me how to transfer a single clockwide pulse from high
> frequency clock domain and create a single clockwide pulse in a slow
> clock domain?
> What are different methods available?
> 

1. Stretch the pulse in the fast clock domain so that it is guaranteed
to be long enough to capture in the slow domain.

2a. If the two domains are *synchronous* (derived from a common clock
source), just put a capture flop in the slow clock domain.  You're done.

2b. If the two domains are asynchronous, put a synchronizer (a chain of
flip-flops with as much slack time as possible) followed by a strobe
generator in the slow clock domain.

	-hpa

And perhaps the more important potential homework question:  why would you 
want to do this?  Hint:  the real world is generally asynchronous, and one 
needs to synchronize to external events.

JTW


"himassk" <himassk@gmail.com> wrote in message 
news:1179293749.474907.116570@e65g2000hsc.googlegroups.com...
> Hi,
>
> Please suggest me how to transfer a single clockwide pulse from high
> frequency clock domain and create a single clockwide pulse in a slow
> clock domain?
> What are different methods available?
>
> Thanks in advance.
>
> Regards,
> Himassk.
> 

Pardon my initial response; however, the question is one that you could 
expect in a digital logic class, or perhaps in an interview.

With a simple google on "pulse clock domain crossing", I come up with this 
article in EDN a few years back:
    http://www.edn.com/index.asp?layout=article&articleid=CA276202

JTW

"jtw" <wrightjt @hotmail.invalid> wrote in message 
news:J6x2i.144$4Y.81@newssvr19.news.prodigy.net...
> And perhaps the more important potential homework question:  why would you 
> want to do this?  Hint:  the real world is generally asynchronous, and one 
> needs to synchronize to external events.
>
> JTW
>
>
> "himassk" <himassk@gmail.com> wrote in message 
> news:1179293749.474907.116570@e65g2000hsc.googlegroups.com...
>> Hi,
>>
>> Please suggest me how to transfer a single clockwide pulse from high
>> frequency clock domain and create a single clockwide pulse in a slow
>> clock domain?
>> What are different methods available?
>>
>> Thanks in advance.
>>
>> Regards,
>> Himassk.
>>
>
> 

General rule of thumb is that you want 2 registers to cross between
clock domains, follow that rule to deal with any metastability
issues.  Now you just have the problem that your first clock domain is
faster and you might not catch it with the slower domain.

Personally, my approach here would be to "hold" the signal in your
CLK_FAST with an enabled register until you receive some sort of feed
back that you've grabbed it in CLK_SLOW, bearing in mind that those
feedback / feedforward signals should all be double registered to
prevent metastability.  Also keep in mind that an enabled register
does NOT count as one of your two "synchronization" registers, because
an enabled register is actually implemented as a register with a mux
in front of it - only direct D-to-Q connections with NO combinational
logic count for clock domain crossing issues.  Now, depending upon the
timing of it all, this could end you up with more than 1 clock pulse
width.  Assuming that you know your input pulses are spaced far enough
apart that you KNOW it's not ACTUALLY multiple pulses, then a simple
edge detect will fix this problem for ya.

The ideal behind the metastability stuff is that if you clock a signal
exactly at the transisition the output of the flop has some
probability of floating somewhere between 0 and 1 for some amount of
time.  Adding any combinatorial logic extends that amount of time.
The idea of having 2 registers is that you reduce your probability of
a metastable event because even if you hit that .01% chance of it
remaining metastable for long enough to create a problem at the first
register, you got another .01% on your side at the second register.
(Note: .01% is much higher than it really is.. but remember, if you're
clocking signals in the MHz range, those tiny probabilities add up
REAL quick!)

On May 16, 1:35 am, himassk <hima...@gmail.com> wrote:
> Hi,
>
> Please suggest me how to transfer a single clockwide pulse from high
> frequency clock domain and create a single clockwide pulse in a slow
> clock domain?
> What are different methods available?
>
> Thanks in advance.
>
> Regards,
> Himassk.

Maybe this is a homework question, but I took it as a challenge.

I can solve it with one 4-input LUT driving a flip-flop, clocked in
the slow domain.
The LUT inputs are: the incoming pulse, the slow clock, the LUT
output, and the flip-flop output.

What happens with metastability?
If the rising edge of the incoming pulse coincides with the rising
slow-clock edge (within a bulls-eye expressed in a fraction of a
femtosecond), the flip-flop output might go metastable, i.e. undefined
for a few ns, but statistically only for max 3 ns ever during the
lifetime of the universe. The (hopefully synchronous) slow-clock
domain should easily be able to live with that (and much more), but If
you are paranoid, cascade a second flip-flop.
Peter Alfke

On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote:
> General rule of thumb is that you want 2 registers to cross between
> clock domains, follow that rule to deal with any metastability
> issues.  Now you just have the problem that your first clock domain is
> faster and you might not catch it with the slower domain.
>
> Personally, my approach here would be to "hold" the signal in your
> CLK_FAST with an enabled register until you receive some sort of feed
> back that you've grabbed it in CLK_SLOW, bearing in mind that those
> feedback / feedforward signals should all be double registered to
> prevent metastability.  Also keep in mind that an enabled register
> does NOT count as one of your two "synchronization" registers, because
> an enabled register is actually implemented as a register with a mux
> in front of it - only direct D-to-Q connections with NO combinational
> logic count for clock domain crossing issues.  Now, depending upon the
> timing of it all, this could end you up with more than 1 clock pulse
> width.  Assuming that you know your input pulses are spaced far enough
> apart that you KNOW it's not ACTUALLY multiple pulses, then a simple
> edge detect will fix this problem for ya.
>
> The ideal behind the metastability stuff is that if you clock a signal
> exactly at the transisition the output of the flop has some
> probability of floating somewhere between 0 and 1 for some amount of
> time.  Adding any combinatorial logic extends that amount of time.
> The idea of having 2 registers is that you reduce your probability of
> a metastable event because even if you hit that .01% chance of it
> remaining metastable for long enough to create a problem at the first
> register, you got another .01% on your side at the second register.
> (Note: .01% is much higher than it really is.. but remember, if you're
> clocking signals in the MHz range, those tiny probabilities add up
> REAL quick!)
>
> On May 16, 1:35 am, himassk <hima...@gmail.com> wrote:
>
> > Hi,
>
> > Please suggest me how to transfer a single clockwide pulse from high
> > frequency clock domain and create a single clockwide pulse in a slow
> > clock domain?
> > What are different methods available?
>
> > Thanks in advance.
>
> > Regards,
> > Himassk.

Maybe this is homework, or it is an interview question, but I took it
as a challenge.
Being a minimalist, and understanding metastability fairly well, I
came up with the following solution:

Only one 4-input LUT plus a flip-flop clocked by the slow clock.
LUT inputs are: INput pulse, slow CLK signal, its own output O, the
flip-flop output Q
( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep
O. O drives flip-flop D)

Ah, but how about metastability?
If IN and CLK both go High within a certain bulls-eye that is <1
femtosecond wide, then Q might be undefined for a few ns after the
rising clock edge. Statistically, the "few ns" will not exceed 3 ns
during the lifetime of the universe. The, hopefully synchronous, slow
clock domain should be able to cope with that. Otherwise concatanate
another flip-flop.

Well, I do not know why anybody wants such a circuit, but it did
exercise the grey cells...
Peter Alfke

On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote:
> General rule of thumb is that you want 2 registers to cross between
> clock domains, follow that rule to deal with any metastability
> issues.  Now you just have the problem that your first clock domain is
> faster and you might not catch it with the slower domain.
>
> Personally, my approach here would be to "hold" the signal in your
> CLK_FAST with an enabled register until you receive some sort of feed
> back that you've grabbed it in CLK_SLOW, bearing in mind that those
> feedback / feedforward signals should all be double registered to
> prevent metastability.  Also keep in mind that an enabled register
> does NOT count as one of your two "synchronization" registers, because
> an enabled register is actually implemented as a register with a mux
> in front of it - only direct D-to-Q connections with NO combinational
> logic count for clock domain crossing issues.  Now, depending upon the
> timing of it all, this could end you up with more than 1 clock pulse
> width.  Assuming that you know your input pulses are spaced far enough
> apart that you KNOW it's not ACTUALLY multiple pulses, then a simple
> edge detect will fix this problem for ya.
>
> The ideal behind the metastability stuff is that if you clock a signal
> exactly at the transisition the output of the flop has some
> probability of floating somewhere between 0 and 1 for some amount of
> time.  Adding any combinatorial logic extends that amount of time.
> The idea of having 2 registers is that you reduce your probability of
> a metastable event because even if you hit that .01% chance of it
> remaining metastable for long enough to create a problem at the first
> register, you got another .01% on your side at the second register.
> (Note: .01% is much higher than it really is.. but remember, if you're
> clocking signals in the MHz range, those tiny probabilities add up
> REAL quick!)
>
> On May 16, 1:35 am, himassk <hima...@gmail.com> wrote:
>
> > Hi,
>
> > Please suggest me how to transfer a single clockwide pulse from high
> > frequency clock domain and create a single clockwide pulse in a slow
> > clock domain?
> > What are different methods available?
>
> > Thanks in advance.
>
> > Regards,
> > Himassk.

"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1179338672.962130.258540@h2g2000hsg.googlegroups.com...
> Maybe this is a homework question, but I took it as a challenge.
>
> I can solve it with one 4-input LUT driving a flip-flop, clocked in
> the slow domain.
> The LUT inputs are: the incoming pulse, the slow clock, the LUT
> output, and the flip-flop output.

Nice - although this pre-supposes that the source clock domain is faster 
than the destination clock domain. So the next exercise is to generalise the 
circuit to cope with any arbitrary clock ratio. :-)

> Well, I do not know why anybody wants such a circuit, but it
> did exercise the grey cells...

I've found this sort of circuit useful when a circuit in one clock domain 
needs to tell a circuit in another clock domain to start (or stop) doing 
something, but only infrequently. For example, the pixel-generating portion 
of a video circuit might want to inform the frame-buffer reader of the start 
and end of a line or a frame. In such a situation, asynchronous FIFOs and 
complicated synchronization logic are usually overkill.

       -Ben- 

Peter,

   I know you folks at Xilinx like to claim that you've permanently
solved all the world's metastability problems, our xilinx fae tells us
the same things....   And maybe you're right for telecom applications
and whatnot.   But I hope you don't support many Hi-rel applications
because I promise you, no defense or aerospace company is going to
happy being told they don't need to double register asynchronous
signals.  Our design guidelines here at unstated defense company
(sorry, i dont disclose that on the net) are VERY strict about double
registering ALL asynchronous signals, no questions asked. 2 D-Q
crossings and nothing else.  Right or wrong, I haven't been in the
business long enough to know for sure, we view metastability as a
statistical thing...and like most naturally occurring statistics, zero
probability tends to never exist, very very very small near zero
probabilities exist.

At anyrate... yes, I'm well aware of Xilinx's current stand on the
metastability problem.   But you yourself just said that the problem
exists for "a few ns" statistically exceeding 3ns once in a universe.
So lets say 2 ns is something we should design for then....  2ns =
500MHz....  What's Xilinx's Fmax these days???  Even if its not a
problem now, it's soon to become a problem again unless you're going
to tell me you're done increasing your operating frequencies.

anywho... our view and i believe the view of most of the defense/
aerospace world is that something as simple as 2 registers is not
worth ANY impact on system reliability.



On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote:
> Maybe this is homework, or it is an interview question, but I took it
> as a challenge.
> Being a minimalist, and understanding metastability fairly well, I
> came up with the following solution:
>
> Only one 4-input LUT plus a flip-flop clocked by the slow clock.
> LUT inputs are: INput pulse, slow CLK signal, its own output O, the
> flip-flop output Q
> ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep
> O. O drives flip-flop D)
>
> Ah, but how about metastability?
> If IN and CLK both go High within a certain bulls-eye that is <1
> femtosecond wide, then Q might be undefined for a few ns after the
> rising clock edge. Statistically, the "few ns" will not exceed 3 ns
> during the lifetime of the universe. The, hopefully synchronous, slow
> clock domain should be able to cope with that. Otherwise concatanate
> another flip-flop.
>
> Well, I do not know why anybody wants such a circuit, but it did
> exercise the grey cells...
> Peter Alfke
>
> On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote:
>
>
>
> > General rule of thumb is that you want 2 registers to cross between
> > clock domains, follow that rule to deal with any metastability
> > issues.  Now you just have the problem that your first clock domain is
> > faster and you might not catch it with the slower domain.
>
> > Personally, my approach here would be to "hold" the signal in your
> > CLK_FAST with an enabled register until you receive some sort of feed
> > back that you've grabbed it in CLK_SLOW, bearing in mind that those
> > feedback / feedforward signals should all be double registered to
> > prevent metastability.  Also keep in mind that an enabled register
> > does NOT count as one of your two "synchronization" registers, because
> > an enabled register is actually implemented as a register with a mux
> > in front of it - only direct D-to-Q connections with NO combinational
> > logic count for clock domain crossing issues.  Now, depending upon the
> > timing of it all, this could end you up with more than 1 clock pulse
> > width.  Assuming that you know your input pulses are spaced far enough
> > apart that you KNOW it's not ACTUALLY multiple pulses, then a simple
> > edge detect will fix this problem for ya.
>
> > The ideal behind the metastability stuff is that if you clock a signal
> > exactly at the transisition the output of the flop has some
> > probability of floating somewhere between 0 and 1 for some amount of
> > time.  Adding any combinatorial logic extends that amount of time.
> > The idea of having 2 registers is that you reduce your probability of
> > a metastable event because even if you hit that .01% chance of it
> > remaining metastable for long enough to create a problem at the first
> > register, you got another .01% on your side at the second register.
> > (Note: .01% is much higher than it really is.. but remember, if you're
> > clocking signals in the MHz range, those tiny probabilities add up
> > REAL quick!)
>
> > On May 16, 1:35 am, himassk <hima...@gmail.com> wrote:
>
> > > Hi,
>
> > > Please suggest me how to transfer a single clockwide pulse from high
> > > frequency clock domain and create a single clockwide pulse in a slow
> > > clock domain?
> > > What are different methods available?
>
> > > Thanks in advance.
>
> > > Regards,
> > > Himassk.- Hide quoted text -
>
> - Show quoted text -

Why not use three registers to make the probability of failure even less?
How about 4?

When the metastability window is in the sub-femtosecond range, the 
probabilities of hitting the window get very small.
The double register will reduce the probability significantly.  But it's 
already an extremely small probability.

If you *do* hit the metastability window, having timing margin to support 
the extra metastability delay by applying constraints will guarantee all 
paths get the correct value except for once every... what is it?  Several 
billion years?

If you're running at speeds such that the timing path cannot be reduced then 
yes - having the second register guarantees every register downstream gets 
the same value.  Even if the metastability time is longer than the clock 
period, the possibility of hitting the metastability window in that second 
register is almost negligible.  Almost.  But there's always a chance.

If you're running a 100 MHz design, you may be able to afford an 8ns cycle 
for your synchronized input from a single flop to the remaining logic.  It 
may not be practical in that 100 MHz system to wat an extra clock cycle for 
every toggle of the asynchronous signal.  If it's fine to delay an extra 
clock cycle, the reduced timing constraint burden is a good thing to have. 
For designs that push the devices' top speeds, the 2 ns difference may not 
be acceptable.  But not everyone is designing at 500 MHz and can accommodate 
an extra clock cycle.

I call this kind of decision-making "engineering."

- John_H


"Paul" <pauljbennett@gmail.com> wrote in message 
news:1179407855.921375.242960@k79g2000hse.googlegroups.com...
> Peter,
>
>   I know you folks at Xilinx like to claim that you've permanently
> solved all the world's metastability problems, our xilinx fae tells us
> the same things....   And maybe you're right for telecom applications
> and whatnot.   But I hope you don't support many Hi-rel applications
> because I promise you, no defense or aerospace company is going to
> happy being told they don't need to double register asynchronous
> signals.  Our design guidelines here at unstated defense company
> (sorry, i dont disclose that on the net) are VERY strict about double
> registering ALL asynchronous signals, no questions asked. 2 D-Q
> crossings and nothing else.  Right or wrong, I haven't been in the
> business long enough to know for sure, we view metastability as a
> statistical thing...and like most naturally occurring statistics, zero
> probability tends to never exist, very very very small near zero
> probabilities exist.
>
> At anyrate... yes, I'm well aware of Xilinx's current stand on the
> metastability problem.   But you yourself just said that the problem
> exists for "a few ns" statistically exceeding 3ns once in a universe.
> So lets say 2 ns is something we should design for then....  2ns =
> 500MHz....  What's Xilinx's Fmax these days???  Even if its not a
> problem now, it's soon to become a problem again unless you're going
> to tell me you're done increasing your operating frequencies.
>
> anywho... our view and i believe the view of most of the defense/
> aerospace world is that something as simple as 2 registers is not
> worth ANY impact on system reliability.