HELP: a Funny asynchronous input design

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?

Reply to
Aiken
Loading thread data ...

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

Reply to
Peter Alfke

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

Reply to
Aiken

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.
Reply to
Gabor

nd

?

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

Reply to
Peter Alfke

thanks

Reply to
Aiken

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.

formatting link

Philip Freidin

=================== Philip Freidin snipped-for-privacy@fpga-faq.org Host for

formatting link

Reply to
Philip Freidin

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

Reply to
Jim Granville

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.
Reply to
RCIngham

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 snipped-for-privacy@fpga-faq.org Host for

formatting link

Reply to
Philip Freidin

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

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.