# HELP: a Funny asynchronous input design

#### Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

•  Subject
• Author
• Posted on
input: Asynchronous, non-fix width, non-fix frequeny(but equal or
smaller than 30 Mhz), something like random fast signal coming in.
System clock is only 40MHz,

What can I latch the "rising" edge of the input and synchronize it and
don't get into big trouble of Metastability?
Since the input freq is very near the System clock and Asynchronous
don't have a clock signal coming in.
is it possible that connecting the input signal directly to FF clock
then following with a negative clk edge FF then positive clk edge FF?
will it make any trouble and how to solve it?

Re: HELP: a Funny asynchronous input design

Synchronizing a 30 MHz signal with a roughly 40 MHz clock will
generate an uncontrollable extra metastable delay of a few ns
occasionally.
But an extra 4 ns only once per many thousand years, statistically.
You really do not have to worry about metastability.
At ten times higher frequencies, you would run into problems...
Se my Xilinx appnote XAPP094...
Peter Alfke

Re: HELP: a Funny asynchronous input design

My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean
that the min time different between two signal will be =( 1/30Mhz). In
income signal don't have a clock domain, it just "Happen".

Re: HELP: a Funny asynchronous input design

Still what Peter seems to suggest is that you can just sample
the asynchronous input with your 40 MHz clock and don't worry
about metastability.  In fact you could sample on both clock
edges and still have a very small chance of seeing a metastable
event at those frequencies.  Just be sure that there is only
one point of sampling on the input signal.  The output of that
single sampling flip-flop can then be used within the design.
Adding one more stage after the sampling flip-flop can improve
your metastability tolerance in two ways.

1) The second flip-flop would receive the sample flip-flop input
after a complete cycle without LUT delays.  This increases the
length of a metastable event required to upset the second
stage.

2) Having a single second point of sampling prevents logic
upsets caused by different loads sampling the metastable
vs. post-metastable state of the first sampling flop.

Re: HELP: a Funny asynchronous input design

Yes, Gabor, we agree. This is a non-problem, as long as the usual
precautions are being observed.
Peter Alfke

Re: HELP: a Funny asynchronous input design

thanks

Re: HELP: a Funny asynchronous input design

Remember the Nyquist sampling criterion. If the minimum "pulse width" i
33ns (= 1/30MHz), that is roughly equivalent to a 15MHz maximum signa
frequency, so 40MHz sampling is OK.

Re: HELP: a Funny asynchronous input design

What do you mean by non-fix width? Are you referring to a single signal
line with a pulse width that is at least 33 ns wide (1/30MHz), but
variable, or do you mean multiple signal lines, and you aren't sure how
many signal lines?

The standard approach to handling a single asyc signal is to pass it
through a two stage synchronizer. Both FFs are clocked by the 40 MHz,
both on the same edge.

Your signal should go to the D of the first of 2 FFs described above.
Clocking on alternate edges is not nearly as good as both FFs in the
synchronizer clocked by the same edge. While it saves 1/2 a cycle of
latency, it seems a silly optimization for a signal that is asynchronous.

Philip Freidin

===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG

Re: HELP: a Funny asynchronous input design

True, but dual edges might have other merit, if there is ever a chance
the OP needs to catch a pulse under 33ns, and under 25ns too.
Dual edges can resolve close to 12.5ns, and a Glitch catcher, could
allow you to catch pulses even shorter,
( but only time defined to the nearest 12.5ns time slot)

-jg

Re: HELP: a Funny asynchronous input design
On Fri, 13 Jun 2008 18:31:51 +1200, Jim Granville

True, but your use of dual edge is not what the OP was suggesting.
His proposed usage was as follows:
a) Async signal into the CLK of a FF1, with let us assume D tied high
b) Q of FF1 to D of FF2, with FF2 clocked by falling 40 MHz clock
c) Q of FF2 to D of FF3, with FF3 clocked by rising 40 MHz clock
d) Q of FF3 to the rest of his system.

This will catch any pulse that meets min clock high of FF1 (assuming
it is rising edge triggered). Not explained is the logic to clear
FF1, and the dead time till that ripples through FF2 and FF3.

The problem with the OPs circuit is that it contains the often
proposed (and counter productive) arrangement of FF2 and FF3 on
opposite clock edges. Since the signal is asynchronous, you must
deal with the worst case latency through the synchronizer at the
system level. At the component level you are trying to deal with
moving an asynchronous domain signal to a synchronous domain.
Assuming you are a competent and experienced designer, you have an
understanding that this is important for system reliability,
specifically to deal with metastability, but also to avoid race
conditions, if the signal must be used in multiple destinations.

With the current technology available in FPGAs, with min clock high
times typically below 1 ns, his circuit could reliably catch pulses
probably below 2 ns wide. This has nothing to do with the 40 MHz
clock edges. Having caught and latched the rising async transition,
the OP must now transfer it to the synchronous domain. Dual rising
edge FFs is a recomended way to do it. A rising and a falling edge
synchronizer is not recommended (or at least, not by me).

What you describe is something quite different. Two separate
synchronization paths, one clocked on the rising edge of the 40 MHz
clock and one clocked by the falling edge. This gives two paths
12.5 ns out of phase, as you describe. But then you (typically)
have to combine these signals into 1 signal, in (one would assume)
the 40 MHz, at which point you are back to 25 ns resolution.
To retain the 12.5 ns resolution (of questionable value given the
asynchronous nature of the signal), you have to duplicate the down
stream logic, or pass it around with a tag to indicate which
synchronizer reported the signal first. Hardly something that is
typically needed.

Cheers,
Philip Freidin.

===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG

Re: HELP: a Funny asynchronous input design
<snip>

What 'is typically needed', depends on the application  :)

There are a number of event/edge capture schemes, where
extra time resolution is a good thing.

Still, I am sure we have expanded the OP's horizons, by showing
he can resolve to 12.5ns relatively easily.
(should this, or another app require it).

-jg