Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
2000-01-27
2004-02-10
Sax, Steven (Department: 2174)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000, C345S215000, C345S215000, C345S215000, C345S215000, C702S057000, C702S066000, C702S067000
Reexamination Certificate
active
06690398
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. This is not surprising when one considers that today, a post acquisition processing facility that provides serial data analysis capability is often sold as an accessory or option to a parallel logic state analyzer.
From their humble beginnings of eight channels of data and memories of only sixteen states in depth, (parallel data) 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 if events of interest are not obscured by the sheer number of other events that might be recorded in the trace memory. While post acquisition analysis of the trace is always a possibility, a more efficient solution to this potential dilemma takes the form of ways to initially exclude from storage events that are deemed uninteresting. Storage qualification and triggering are two ways that this is done. 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, the memory may eventually be filled, whereupon it is treated as circular and new data overwrites the oldest data. 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
16
. 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.
Occasional severe dissatisfaction with the textual symbolic boolean trigger specifications have led to the development of graphical methods of trigger specification. These techniques represent logic signals as logic waveforms, and the user specifies what waveform (or related family of waveforms) constitutes the trigger specification. This mode of description is, for many users, a more natural mode of expression for describing certain kinds of relationships between signals of interest. The Agilent 9340A is an example of a logic analyzer having a graphical mode of trigger specification.
The two trigger specification methods, textual and graphical, are generally considered to be philosophically equivalent in terms of capability, in that what can be done with one technique can usually be done with the other. That said, however, one is not obliged to consider them equally easy to use in all situations. Some trigger specification situations are more easily handled (by at least some users) with a textual description, and others with graphical one. Prior art logic analyzers have forced the user to choose between the two methods. It would be desirable if it were possible to combine, within a single trigger specification, the advantages of both methods, as indicated by the nature of the problem.
SUMMARY OF THE INVENTION
A solution to the problem of an inappropriate trigger specification mechanism in a logic analyzer is to integrate the capabilities of both textual and graphical description into a common environment, so that each can be used as needed, and in conjunction with the other. In an example embodiment to be described a trigger specification can comprises as many as six “steps”. A step can be conceptualized as an atomic segment of flow charting that involves or investigates a quantity or condition of interest. These steps may involve testing, and a decision concerning whether or not to trigger or whether or not to advance to a next step. A given step (as defined above) can be either textual or graphical. A GUI (Graphical User Interface, as in computer windows, and not to be confused with ‘graphical’ meaning ‘waveform-like’) on a CRT screen in conjunction with a pointing device (e.g., mouse) provides the presentation of the
Backsen Michael Shaun
Beck Douglas James
Friedman John Howard
Robison Douglas Fred
Agilent Technologie,s Inc.
Miller Edward L.
Nguyen Thomas T.
Sax Steven
LandOfFree
Logic analyzer with mixed textual and graphical trigger... 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 mixed textual and graphical trigger..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Logic analyzer with mixed textual and graphical trigger... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3345468