fast flop NB7V52

The last time I got involved with "fast" logic not behaving well, the badly behaved logic was regular TTL. It had been built into a hand-tuned fast pulse generator, and the shift registers involved had to be hand-selected to have the right delays to make it work, and after a year's use the delays would drift enough that a new set had to be selected.

The experimenter who used it wasn't worried by this, but he found a small - sub-nanosencond - time shift that depended on the spacing between adjacent pulses.

I suggested using a bit of ECL at the crucial point, and got stuck with with job of doing it. It did get rid of adjacent pulse effect. What was weird was the TTL coming out of an ECL-to-TTL converter chip was equally clean.

The working hypothesis was that a close-by-pulse (in time) was dragging the TTL rail down, and even through the TTL rail going to the ECL-to-TTL converter was just a dirty as the original, the long-tailed pair inside the ECL-to-TTL converter seemed to be less sensitive to variations in collector voltage than regular TTL outputs.

The original circuit seem to go back to the early 1980's and I got involved after I mover to Nijmegen in the Netherlands in 1993 - probably around 1996.

There were some really bad ECL-TTL converters. The Motorola part was ghastly.

One big problem with TTL was metastability. A flop couldn't make up its mind to settle to 0 or 1 and might oscillate between them for a long while. 74LS was especially bad that way.

If you carefully balance a pencil on its point, it will eventually fall over, but it won't oscillate first. TTL did.

CMOS flops, transmission-gate based, were much better. Seems like the EP and NB7 fast ECL parts are pretty good too.

It would be interesting to do some experiments on them. Our NB7V52 test probably didn't resolve metastability issues.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

The problem was solved in the 1970s or 1980s by a felllow I knew back in the day. I'll try to find the reference.

Joe

you can't "solve" metastability, you can only reduce the probability of it happening

That billion year MTBF is scary. I'd better use a dual-rank synchronizer. Or triple.

But it seems to me that an oscilloscope is a better way to resolve metastability than their circuit.

And a negative feedback teaser. With the 2-clock method, the vast majority of shots yield no data.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Hey, I knew Peter Alfke. I met him at the Foothill Flea Market, when we both had our heads inside a big box of books.

He said that I just shouldn't worry about metastability in a Xilinx FPGA. And FPGAs are a lot faster now.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

The part that I was using was the regular Motorola ECL-to-TTL converter. It behaved unexpectedly well, but I had paid attention to the layout - I laid out the board that added in the ECL elements. The original board had used through the board components, and while I couldn't get a surface mount version of the TTL shift register, everything else got switched to surface mount, which gave me enough extra space to squeeze in the ECL.

"Metastability" is always with us - if you can't meet the set-up and hold conditions the settling time to a stable state can become quite long.

If you toleranced your timings properly you never saw it - I certainly didn't - but the manufacturer's application notes made a fuss about it.

TTL systems have noisy power rails. The "metastable state" wouldn't oscillate, but it could be sensitive to external disturbances.

CMOS gates have to charge up their gate capacitance before they switch. Fast ECL parts are lot faster than TTL. I remember publishing a comment on a paper in Rev. sci. instrum. that made a lot of fuss about replacing TTL with 10kH ECL, which was four times faster and my comment pointed out that ECLinPS - which was freely available by then - was four times faster again than 10kH. Those sorts pf edge speeds to tend to force designers to be careful with their layouts. Motorola's ECL application notes did make a lot of fuss about printed circuit layout, and it was hard tog et people who were used to designing with TTL to read those bits of the application notes.

It you satisfy the set-up and hold time constraints, you won't have any of them to resolve. I assume you know what they are. They are in the data sheet, if you read it anything like carefully.

The Moto part had gigantic jitter. Somebody second-sourced it with a much better design.

Nowadays, an LVDS-to-TTL part, like DS90LV012, is faster and cheaper and super clean.

But ECL is expensive and clutzy so we rarely use it any more. FPGAs are crazy fast inside and a gate costs a fraction of a cent.

TTLs definitely oscillated in metastable cases. LSTTL could be teased into oscillating for many microseconds. They would make pops on nearby FM radios.

Sometimes one has to synchronize an async input, or cross clock domains.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

It didn't when I used it. It was notoriously difficult to get layout draughts people to layout ECL circuits as carefully as they needed to.

I'm inclined to suspect that inexpert use produced the jitter that you thought you saw.

LVDS does use different rail voltages than ECL, even if the voltage swings are the same, and people now have a lot more experience with transmission line effects - like reflections.

It was always the expensive go-faster option, and uses a lot more power.

Once we got the transistors small enough to let us fit lots of them in a single package, having logic that could drive transmission lines lost a lot of it appeal.

On boards laid out by idiots.

True, but sensible people get good at avoiding it. The pressure to do it usually comes from marketing, who want to tell the customers what the customers want to hear, rather than what the customers need to hear.

Am 13.07.26 um 02:51 schrieb john larkin:

I once met him at an XFEST in Berlin. Very interesting to talk with.

Gerhard

True, nobody really needs a uP and an FPGA on the same board, or ever needs to accept external triggers.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

In this case, "solve" meant "understood at last".

The remedy was to make the metastable core very fast, and then wait long enough for it to have decided with a very high probability. The original analysis was made with a pair of bipolar transistors in a flip-flop circuit. Later, tunnel diode core was tested.

Anyway, I did find the foundational reference:

"Theoretical and Experimental Behavior of Synchronizers Operating in the Metastable region", by George R. Couranz and Donald F. Wann, IEEE Transactions on Computers, Vol. C-24, No. 6, June 1975, pages 604-615. Now DOI 10.1109/T-C.1975.224273, behind a pay wall. Searching for articles that reference this article could be informative.

Joe

He used to post a lot on comp.arch.fpga

he died in 2011

yeh, when his conclusion ~25 years ago was that it can safely be ignored for <200MHz, it is probably not something you need to think much about now

The best I found is "Synchronization and Metastability" by Steve Golson of Tribolite Systems of Carlisle MA (near Boston), published in

Joe

If you need a uP and an FPGA on the same board, derive the clocks for both from the same source.

Sometimes you do need to process externally generated triggers, but in lots of cases you can avoid it if you try hard enough. Marketing hates asking customers to even try.

Welcome to the 21st century. Everything noadays uses a low frequency crystal oscillator and has multiple PLLs inside to step it up. Our RP2040s use a 12 MHz clock but, after bootup, pll that up to 150. But the ethernet chip needs a 25 MHz rock.

Our FPGA can use the 25 MHz clock but PLLs that up to several frequencies, including 200 for the Wishbone bus and 400 for the DDS. Of course, the DDS makes a programmble clock and its phase wobbles around some.

None of those many clocks can be phase aligned.

People who buy digital delay generators want the delays to start on their trigger. They'd think we are nuts if we told them to synchronize their enormous process to our clock.

Having multiple clock domains is unavodable in anything nontrivial. And one crosses them carefully.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

If you need tight timing, don't use cheap crap on your boards.

It obviously has to be able to do that, but there should be mechanisms that lets you bypass it,

Or at least you haven't tried to.

They might think you less nuts if you told them why it might be a good idea.

The "enormous process" is there to serve a purpose. If you ask them to think about what's going on and what the easier way to get it to work right you might get a rational response, at least some of the time.

Based on your performance here, you aren't all that well-equipped to ask that kind of question or understand the answer you'd get, but you might be able to learn

Or at least you haven't been able to avoid them.

And gets rid of them wherever possible.

We work on facilities that are kilometers square. How are you proposing to align clock edges across them?

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics