VHDL Synchronization- two stage FF on all inputs?

Triple!!! You are aware that using synchronizers in odd numbers puts the metastability back into the circuit, right?

April Fools! Er, December Fools.

--

Rick
Reply to
rickman
Loading thread data ...
[snip]

No I don't have proof, but it stands to reason that noise would help to give a finite upper bound to a metastable event even if it is still only cutting off a statistically small tail

No. The second flip-flop has the same sort of metastable window as the first. If the first flop misses that window because the metastability was longer, then the second flop will resolve on the following clock cycle. I think you may be under the misapprehension that the metastable state means that the first flop is outputing a "1/2" rather that "0" or "1" logic level and any sampling during that time would cause metastability in the second flop. In fact that's not the case.

Your reasoning only follows if you still believe that the second flop goes metastable when the first event lasts any amount greater than "x".

--
Gabor
Reply to
GaborSzakacs

That is why I asked. I don't agree that "it stands to reason". I would at least like to hear a mechanism proposed if not proof which could be in the form of measurement if nothing else.

I don't think that is correct. A metastable event can create all sorts of problems on the output including oscillations and indeterminate levels. These can produce metastability in the second stage without having to hit a bullet with a bullet.

Correct. But regardless, you are ignoring the impact of the longer time period on the exponential. It is *ginormous*.

--

Rick
Reply to
rickman

Think again. A flip-flop has positive feedback gain. Oscillation is definitely not a possibility. Somewhere inside the flop you could sit at a threshold voltage for a while, but once you start to resolve, the swing will be monotonic. The next flop doesn't get fed directly by the node sitting at its threshold, but from a buffered copy. You'd need a buffer that oscillates when its input sits near a threshold for a nanosecond or two. You won't find anything like that in an FPGA.

--
Gabor
Reply to
GaborSzakacs

There is some 40 years of experience and documentation showing the effects of metastability. Please do a little research on the topic.

--

Rick
Reply to
rickman

Thank you, this has been very helpful for me. I feel like a small light bulb turned on in my head, though its fluorescent and it flickers on a off a bit before staying on :)

I think we can agree that metastability is bad and a dual flip flop on an input signal can resolve this. We can add more FF in series to get the probability of a metastability event down to "zero", but lets say that two is good enough. Back to my original question is how would one do this for a large design with many inputs?

Consider my sample code below, lets say I have a design that has 85 inputs. To synchronized everything with dual FF would require 170 internal signals. No big deal if you have an large enough FPGA, but is this a realistic thing to do? In a CPLD this would take up a lot of resources.

How many out there are actually doing this? Is there a better way of doing it?

---------------------------------------------------------------------------------

-- Sample code - Dual FF on all input?

--------------------------------------------------------------------------------- entity BigDesign is port( Clk : in std_logic; IN1 : in std_logic; . . . . . IN85 : in std_logic; out : out std_logic ); end BigDesign;

archictecture behavioral of BigDesign is

Signal IN1_meta : std_logic; signal IN1_Sync : std_logic;

Reply to
hvo

Once again, sometimes you would and sometimes you wouldn't. Let's take the fairly common case of an 8-bit data bus with an active low latch signal. The falling edge of the latch indicates that the data is valid, and that you should latch it.

In this case, the only thing that actually requires synchronization is the latch signal itself. Once you resynchronize it, and see that the new value of that synced signal is 0 whereas it used to be 1, then you can latch the 8-bit data presented because you know that it's stable (by contract) at the time of the falling latch.

Now, the time it takes you to delay may violate that contract; if your two flip-flops are on a 100 MHz clock that's 20 ns; if you're only guaranteed 20 ns of data valid then you need to add 1 level of registers on all that data too. But that's not there to deal with metastability, it's just there to try to match your delays up because, on the clock when you latch the data than you intend to be latched by the falling-edge detector, the data will be stably 0 or 1 and so there's no metastability risk.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

I will add that you don't need two *additional* FFs for each input. It is not the FF that deals with metastability, it is the slack time in the path to the next FF. So you only need to add one FF per input with no logic (or sometimes you can violate that rule if the logic is simple and you use a timing constraint to provide guaranteed slack) in the path to the next FF. Really, it is not how much logic there is, the issue is slack time to resolve the metastable event before reaching the next FF. So in theory, even a path with no logic can have a bad route with very little slack time if the clock is fast enough.

I've never done this, but it would be good practice to use a separate timing constraint to assure slack time on the path you are using to resolve the metastable events on the input.

--

Rick
Reply to
rickman

o
r

Read the last paragraph of my Dec 10 post for the short answer. Whether a design has a large or small number of inputs is not relevant. What you nee d to know is the clock that is used to generate those inputs from their ext ernal source.

s.

No flip flops are needed if:

- In1...In85 are generated synchronous to Clk

- The setup and hold time requirements of In1...In85 to your design are met .

You need to study up on how to perform static timing analysis. As I mentio ned in my first post, what you're struggling with has nothing to do with me tastability. What it does have to do with is simply timing analysis. As a n example, if In1...In85 all are guaranteed to arrive at the input pins bet ween 1 and 5 ns after the rising edge of a 10 ns clock period Clk input, an d the setup time for your design requires 3 ns of setup time and 0 ns of ho ld time, then you have sufficient margin. If the setup time requirement of In43 happens to be 6 ns then you have a 1 ns problem on one input that nee ds to be fixed.

All of this information comes out of the timing report. The input to the t iming report is the routed design and the timing constraints (in the above case that In1...In85 all have between 1 and 5 ns of delay).

Kevin Jennings

Reply to
KJ

Rick,

If you had even started to look into some of that 40 years of research, you may have come across a host of articles like this one:

formatting link

The only mention of oscillation is that it doesn't happen. At least not at the output latch node.

Reply to
GaborSzakacs

This one says it can oscillate...

formatting link

This one does too...

formatting link

Another...

formatting link

This one has pictures...

formatting link

You can talk about positive feedback, but that does not preclude oscillations. With the appropriate condition such as the data input changing at the right time just around the clock edge, both outputs of the master FF (Q and Q not) can be in the same state. With approximately equal delays in each gate, this condition will change to both outputs changing to the opposite state, then back, etc until one of the states "catches up" with the other and the circuit reaches a stable state.

Some of the very earliest work analyzing the metastable state in digital logic well documented oscillations in such circuits. Anyone who tells you otherwise is talking through their hats.

--

Rick
Reply to
rickman

Oscillation vs invalid level is dependent on the logic family. I would go and dig out some 30/40 year old oscillograms, but they are currently inaccessible.

Reply to
Tom Gardner

Any older ones? CMOS flip-flops built from transfer gates will not oscillate. The only reputable instances I could find showing oscillation referred to much older families that used cross-coupled gates. Note that there are no "Q and Q not" outputs of a CMOS flip-flop unless "Q not" is generated with an inversion after the transfer gate latch. Cross-coupled gate implementations could oscillate. You won't find those in an FPGA.

Reply to
GaborSzakacs

A simple thought on the topic, as it's often difficult to see the forest for the trees:

When an asynchronous signal is sampled, there can be timing violations. No number of chained FFs can give a _deterministic_ result. But they guarantee that it won't change between clock cycles and will look the same to all connected inputs, whatever the value.

For example, a metastable reset could release some blocks one cycle before others, and the circuit is off to a bad start.

--------------------------------------- Posted through

formatting link

Reply to
mnentwig

If you are talking about the circuit shown in your reference it will still oscillate the same way as a gate based FF. Each inverter in the loop produces a signal, one is Q the other is Q not whether it is labeled as such or not. Oscillations happen.

--

Rick
Reply to
rickman

OK, so clearly you didn't actually read the artical.

1) Those inverters in a loop are "latches" that work because there are exactly two inversions forming positive feedback.

2) There is no Q not as you would have in a cross-coupled gate flip-flop. i.e. the middle of each inverter pair is not accessible. In fact you could re-draw the schematics showing the pair as a single non-inverting buffer and it would not change the way the circuit works. There is no need for inversion to hold the current state.

3) Oscillations don't "happen." The most you'll get is two transitions when you go into metastability and eventually resolve to the original state (0 to 0 or 1 to 1).

In any case, this thread is getting too old...

As someone said in another recent thread:

whatever

--
Gabor
Reply to
GaborSzakacs

Yes, two inverters in a loop. Bistable with delays in each element... that part is *exactly* the same as the cross coupled gates and this is

*exactly* the feature that allows oscillations.

Whether or not the inverted signal is brought out is irrelevant. If you don't like the name "Q not" tell me what you wish to call it. Then substitute that name in the explanation I gave and it still describes the functionality that will allow oscillations.

Again, you seem to think hiding the details changes operation of the circuit. There is no such thing as a non-inverting primitive element. A "non-inverting" buffer is two inverting buffers cascaded, each with delay. To get a non-inverting element requires either common drain or a common gate arrangement of the transistors which are not suitable for logic elements.

Yes, the thread is old as are the excuses for not properly analyzing the operation of the circuit.

Try putting this in any simulator and testing it. If you change the data input at the right moment so that the first inverter output has changed at the moment the feedback gate closes the loop and the input gate disconnects the input, you will have two signals of incompatible polarity which will chase each other around the loop. In a simulator the oscillations will persist potentially forever. In the real world they will die out... but in an indeterminate time. Actually the time is determinate... if you can nail down all the variables, *but* the result relative to the variables such as the exact time of the input transition is very chaotic. In fact, if I can get an approximate model for the typical transistor used in modern digital logic I will run a simulation.

If you just treat the circuit as a bunch of logical elements rather than electronics I can see where you would not properly understand the operation. You keep trying to explain the circuit with your view of it (which I have tried to explain how it is faulty), but you have not explained what is faulty about my view of the circuit.

If you don't wish to discuss this further, that's fine.

--

Rick
Reply to
rickman

From my understanding, it does not oscillate - it simply tries to resolve and the lesser the initial voltage difference between the two nodes of the latch, the bigger the time constant. Any big swing to call it "oscillation" should put it out of the metastable state already.

Could it be that the master latch does not oscillate, but during the time it being metastable (exponentially resolving), the slave (at that time transparent) due to indeterminate logic level and noises does the observed oscillation? This could be very misleading.

That's for the flip-flop constructed with pass gates, which should be close to what is actually used these days (?). I have no direct ASIC experience.

Rick, if you happen to make such simulation, please share the results.

One of the more interesting threads.

Reply to
Vladimir Ivanov

There are a bunch of simulations in the document. None of them oscillate.

Bye

Reply to
GaborSzakacs

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.