Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2000-01-31
2003-09-02
Baderman, Scott (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S045000
Reexamination Certificate
active
06615369
ABSTRACT:
BACKGROUND OF THE INVENTION
Logic analyzers are test equipment that allow inspection of patterns (“logic states”) in logic signals, and detect the occurrence therein of selected events. Early equipment that met this definition operated upon serially transmitted data, such as the bits of characters being sent via RS-232 or register contents being sent over serial busses in a serial micro-processor environment. At present, serial micro-processors are less prevalent than their parallel counterparts, although the serial bit-wise transmission of data continues in many forms (e.g., Internet protocol over an Ethernet), and the term “logic analyzer” has generally come to refer to equipment that deals with data occurring in parallel form (as on a sixty-four bit wide bus). The task of serial data analysis has been undertaken by “serial data analyzers” and protocol analyzers. Despite this divergence, many of the fundamental concepts remain the same or quite similar (e.g., the notion of triggering), and despite that fact that our examples are presented in the realm of parallel data, it will nonetheless be appreciated that the techniques described below have applicability in the serial environment as well as in the parallel one.
A logic analyzer is an instrument that samples and acquires digital data from a DUT (Device Under Test) or SUT (System Under Test). In some respects its operation resembles its cousin, the digital oscilloscope, in that they both acquire data to produce waveforms. However, the digital ‘scope can store finely graduated amplitude information, and can condition its trigger on such things as the rate at which a voltage changes. The timing analyzer deals only in highs and lows (excursions about a defined threshold), and only triggers in response to patterns in the data. Modem logic analyzers can be operated either in a timing mode (where samples are acquired at regular intervals, like an oscilloscope) or in a state mode (where the samples are acquired when specific signals occur on the DUT). Logic analyzers are also capable of displaying data as waveforms. This is a standard feature on most commercially available logic analyzers.
Modern logic analyzers have evolved into powerful and sophisticated systems that can monitor hundreds of channels and store tens of millions of states, collectively called a trace, which is stored in a trace memory. However, such a wealth of data is valuable only (1) there is some assurance that the event(s) of interest is indeed among the data; and (2) if the event(s) of interest are not obscured by the sheer number of other routine or uninteresting events that might also be recorded in the trace memory. While post acquisition analysis of a long trace is always a possibility, there are more satisfactory and efficient solutions to this problem. Storage qualification pertains to ways of initially excluding from storage events that are deemed uninteresting. Storage qualification restricts what events that are placed into memory to those that meet some standing criteria; e.g., data read from a certain address in memory. Being finite, however, the memory may eventually be filled, whereupon it is treated as circular and new data overwrites the oldest data. The notion of triggering, on the other hand, is used to recognize the occurrence of some condition believed to be THE EVENT OF INTEREST, and subsequently terminate (immediately or eventually) the data acquisition phase of the measurement (lest the event of interest be overwritten by subsequently acquired data). The stored data of the trace may be likened to a list, and if the trigger event were used in such a way that it occurs at the middle of the completed trace list, then subsequent examination of the trace list would reveal events that led up to the trigger event, as well as those that happened afterwards. It is customary to be able to specify where in the trace list the trigger is to appear, and it is prominently identified as such in the list.
Capturing the desired data frequently hinges on being able to specify a sufficiently meaningful trigger condition. That is, the desired trigger condition (the trigger specification) might be a fairly complicated sequence of events, perhaps even involving alternatives. Often that task of trigger specification development is problematic, since, if one knew what was wrong there would likely be no need to specify a trigger in the first place. But given that there is an unknown problem, one is sometimes forced to discover an effective trigger specification by successive refinement, even with the aid of powerful trigger techniques. This has led to the development of many useful triggering schemes, to which logic analyzers owe much of their present utility.
Initially, trigger specifications were described in boolean terms, using signal names associated with factory assigned input channel names belonging to the analyzer itself, rather than using names associated with the system being investigated. In due course logic analyzers changed to allow the user to specify that certain inputs to the analyzer were to be treated as a field identified by a name, usually called a label. Thus, the operator became free to describe events in terms of more meaningful descriptors, such as ADDR (referring to a defined collection of thirty-two inputs representing an address), DATA (another user defined collection of inputs) and READ (a single bit control line). Once these correspondences are established the associated labels may be treated as variables, allowing the formation of relationships such as ADDR =XXXXXXXX
6
. A trigger specification is an assemblage of labels used as operands in conjunction with various logical operators, such as AND, OR and NOT, possibly including parenthesis, and forming logical expressions with constants (fixed values) and the relations =, < and >. Labels are much easier to work with than, say, logic analyzer channel numbers, since they are descriptive in terms of the system being investigated. Such a textual boolean description of a trigger specification resembles a segment of programming, perhaps similar to C. The HP 1670 series Logic State Analyzers are representative of this textual mode of trigger specification. Handy as it is, however, the textual boolean representation can also sometimes be difficult to create correctly, particularly when elaborate sequences in time are involved. Not all users are comfortable with such a textual description, especially when timing or duration relationships between signals are to be expressed.
In addition, virtually all logic analyzers can display their acquired results not merely as columnar list of symbols, but also as a waveform diagram. Consider the following situation. A trace has been obtained and upon inspection, the data therein reveals, right there in the trace, the existence of some event (some combination and or sequence of signal conditions) that would be a more productive trigger specification than the one that was just used. At this point the operator of the analyzer is thinking: “Aha! I should trigger on that.” What he or she then wants to do is change the trigger specification accordingly and perform the measurement again, the better to get an informative description of the event of interest.
All the information needed to extract the desired now trigger specification is present in a display of the trace. But to alter the existing trigger specification or create a new one, it will generally be necessary to leave the screen (or screens) displaying the waveforms of interest and enter ones specific to trigger specification. So the new trigger information of interest is now some distance removed, and now longer visible. Furthermore, it will be necessary to convert this graphical display of a waveform (or segments thereof) into some other format used to specify trigger conditions, such as a textual description involving binary relationships. Many users find converting from a waveform representation to a conventional textual one to be an aggravating and error prone task, perhaps
Beck Douglas J.
Friedman John H.
Robison Douglas F.
Agilent Technologie,s Inc.
Baderman Scott
Miller Edward L.
LandOfFree
Logic analyzer with trigger specification defined by... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Logic analyzer with trigger specification defined by..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Logic analyzer with trigger specification defined by... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3041109