Fault tracing

 Years ago, maybe even eons ago, I and a few others at HP Colorado Springs spent time trying to 'Chase Glitches"    The idea was that in the newfangled digital circuits of the day, the gremlins causing the 'real problems' were glitches, transient spikes of energy usually attributed to mis-designed logical paths, or to "race conditions" that had long bedeviled IBM mainframe designers of synchronous circuitry abetted by careful attention to wire cable lengths and timing diagrams for fast logic circuitry.

Bill Farnbach, a brilliant designer in our sampling 'scope labs  understood this problem from a different standpoint, which was that we needed to ignore these spikes and look ONLY where conditions were stable, after a switching event had 'settled down' -- this of course became the basis for HP's valuable Logic State Analyzer approach, and a couple of generations of logic designers got 'relief' from the worst of these transient behaviors.

But this is not a universal panacea, and HP Colorado Springs has continued to be on the forefront of dealing with these issues, even supplanting the 'old standard' Tektronix in this arena.   And a couple of weeks ago, at Greg Peters' urging, I made contact with Brad Doerr, the site manager for HP Colorado Springs, who graciously took me through a tour of their amazing new "Fault Tracer"

Talk about a versatile solution.  This is essentially a fully tailorable 'trigger system' for a 'scope (analog) display, or a logic analyzer (state) display.   The trigger shape, pattern, magnitude, directionality, and duration can all be controlled by the operator -- what we in the olden days would have called a "do-all" trigger function.   I was mesmerized.   The world has definitely evolved from the simple one I knew.

I am attaching the first page of a once-confidential document that describes this for your reading interest.   And I thank Greg and Brad for their patience with my questions about it.