[time-nuts] BBB DDMTD - analysis

[Chuck Harris]

Generally speaking, metastability problems with FF's are caused
by an inappropriate timing relationship causing both of the latch
gates to get stuck between a logic 1 and a logic 0.  If you are
in the exact right spot, the FF has no way to decide whether to go
up, or to go down, so it just hangs there until the right noise
combination comes by and bounces it one way or the other... It can
take a surprising long time for the metastability condition to get
itself sorted out... It is like rolling dice and waiting for the
right number to come up.

When I was teaching, we would casually mention metastability in
the lecture, and then give the kids a lab problem that because
of their dangerous level of knowledge, was begging to create a
metastability issue, and watch them try to figure out why the FF
was behaving in a logically inconsistent manner.  You can give
the kids all the information in the world on what metastability
is, and how metastability happens, but it isn't until it kicks
them in the head that they start to truly understand the condition.

If the FF is placed into a breadboard, there is bound to be an
additional variable added, and that is a bouncy power, and ground
connection.  So, if the FF is stuck between 0 and 1, it is basically
a very high gain amplifier, and it can, under the right circumstances
of the ground wiggling up and down, start to oscillate.

Try mounting the FF onto a ground plane, and directly attach a
0.1uf cap from the power lead to the ground plane...

Then all that will be left is the metastability condition... which
is non deterministic in how long it takes to clear.

-Chuck Harris

Simon Marsh wrote:
> Lots more pictures and data uploaded here:
> https://drive.google.com/folderview?id=0BzvFGRfj4aFkMFBtNWFSZVBKWkk&usp=sharing
>
> In an effort to understand which component was responsible for my ~17us spikes I
> decided to go back to basics with just a single DFlop (AC74) on a breadboard; no BBB,
> just a couple of oscillators driving the data and clock pins (the microcrystal and
> 8663 in this case). I think I can hear Bob shaking his head at using a breadboard :)
> but the point was to change the parameters (even if it was for the worse) to
> determine what was causing the problem.
>
> The first few pics (DFlop-unsync-floating-*) show the Q output, which was unconnected
> to anything other than the oscilloscope. They show a few glitches at the edge then a
> load of funky stuff going on later. Connecting Q to an input pin
> (DFlop-unsync-connected) cleared the problem suggesting that in this period, the
> DFlop output wasn't being driven and Q had been left floating.
>
> What surprised me about these traces is not that strange stuff was happening at all,
> but just how long an interval it was happening for. I'd expected, say, tens of clock
> cycles (~1us maybe), but here the dflop is still reacting over 100us later. The
> period where the output was floating was just over 50us long.
>
> The next few traces (DFlop-sync-*) show the output synchronised through the second
> DFlop of the AC74. The first few clearly show glitching bang on the 17us mark,
> revealing that the data I'd seen wasn't because of quantisation but because glitches
> were specifically occuring at those points. It also nicely ruled out the BBB as this
> wasn't connected.
>
> The last few DFlop-sync-* traces show a variety of edge transition cases. What is
> becoming clear is that the set of transitions near an edge are _not_ a nice standard
> distribution as you might expect from simulation, so this is going to make the edge
> detection algorithm interesting.
>
> After messing around with the AC dflop, I decided to try swapping to a slower part to
> see what impact this would have. I switched to an HC595 shift register, in part so I
> could also rule out my mess of wires between the sampling and synchronising flip flop
> as being the cause of the problem. The last couple of traces show an HC595 seeing
> exactly the same type of glitches as the DFlop.
>
> Finally, I hooked the BBB back up and tried quite a few different combinations of
> parts and clocking techniques to see what impact they may have. I've included plots
> of the edge transition distribution of the AC74 dflop, HC595 shift register and
> AHC595 shift register for comparison.
>
> Each of the profiles are slightly different, but they _all_ show glitching at ~17us
> increments. The final surprising bit is just how consistent this number is given the
> wide variety of different setups I've tried. I've changed practically most of the
> setup at some point or another and despite how hopeless by hardware layout has been,
> the transitions have always been occuring within one or two clock cycles every time
> (169-172 sample clocks).
>
> To wrap up, despite the glitching, I managed to get noise down to reach about 7E-11 @
> 1s which is pretty hopeful given it was botched up on a breadboard.
>
> Cheers
>
>
> Simon
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>