Data processing: measuring – calibrating – or testing – Measurement system in a specific environment – Electrical signal parameter measurement system
Reexamination Certificate
1999-03-01
2001-12-04
Grimley, Arthur T. (Department: 2852)
Data processing: measuring, calibrating, or testing
Measurement system in a specific environment
Electrical signal parameter measurement system
C345S501000, C702S070000, C714S724000, C714S736000
Reexamination Certificate
active
06327544
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to signal measurement systems and, more particularly, to storing trigger specifications in a signal measurement system.
2. Related Art
Analyzers and testers are commonly available to assist in the development, manufacturing and troubleshooting of complex digital electronic/software devices and integrated circuits having incorporated therein microprocessors, random-access memories (RAM), read-only memories (ROM), and other circuits. Such analyzers and testers, generally referred to as signal measurement systems herein, include logic analyzers, digital oscilloscopes, protocol analyzers, microprocessor emulators, bit error rate testers, network analyzers, among other instruments. Logic analyzers in particular have emerged for this purpose and are commercially available from a number of vendors, such as Hewlett-Packard Company, Tektronix, Inc., and others.
Logic analyzers are digital data acquisition instruments that allow an operator to acquire and display digital signal data from a large number of logic signals (“signals”), such as those that travel over address, data and control lines of a device under test (DUT). A device under test may include one or more separately packaged devices such as those noted above, as well as other circuits and devices.
The signals are acquired from the device under test on hardwired lines referred to as channels. The channels may be physically assembled into groups commonly referred to as pods. The received signals are sampled and digitized to form signal data. Digitizing typically includes comparing a voltage magnitude of each logic signal sample to a reference voltage threshold to determine the logic state of the signal. Sampling may occur at one of a number of selectable rates, depending on the frequency at which the sampled signals change logic states. The resultant signal data are stored, under the control of a sampling clock, in a signal data memory generally having a fixed size. The data are typically stored in a sequential manner such that consecutive signal samples are stored in consecutive memory locations. Due to the quantity of signal data, signal data memory is commonly implemented as a wrap-around buffer.
Selection of the portion of the signal data that is separately stored and subsequently presented on the display is determined by an operator-defined trigger specification. The trigger specification (also referred to as a trigger set-up) is specified generally by a trigger definition and a number of parameters, collectively referred to herein as trigger control parameters or, simply, trigger controls. The trigger definition identifies the occurrences under which signal data is to be stored. The trigger controls identify the characteristics of the captured signal data including, for example, the relative position of the occurrence defined by the trigger definition and the signal data to be stored. A predetermined quantity of signal data occurring before and after the specified occurrence is then stored in memory for subsequent analysis.
A trigger definition, also referred to as a trigger sequence, is comprised of one or more trigger sequence levels. Each sequence level may include any number of trigger branches each of which sets forth a branch condition that causes the logic analyzer to execute the action defined in that trigger branch. Such execution results in the storage of signal data or further processing of a subsequent sequence level. The final branch condition that causes the acquisition of signal data is commonly referred to as a trigger condition.
Branch conditions are specified by the occurrence of one or more events. An event is defined as an occurrence of certain characteristics or properties of a signal, such as a rising or falling edge, a logic high or logic low signal state, etc. Events may also be defined based on internal resources, such internal timers, counters, etc. Typically, a branch condition specifies a number of events that occur simultaneously or in a relative time sequence.
After the trigger specification is specified, the operator can perform a measurement; that is, initiate acquisition of signal samples. When signal data capture is initiated, the signal data is compared to the specified trigger definition. When the trigger definition is satisfied, the signal data is captured in accordance with the specified trigger controls. Subsequently, the signal data memory may be sequentially accessed and signal data displayed.
Constructing a proper trigger definition can be very complicated and time consuming. A common approach to developing a trigger definition is to construct and test individual portions of a trigger definition at a given time. As each portion is verified, additional layers of complexity are added to the previously verified trigger definition. For example, operators often begin trigger specification development with a simple trigger definition, perform an acquisition, and examine the captured data. If the results are as anticipated, then the operator adds another portion; that is, a branch or an event, to the trigger definition, to further define the trigger definition so as to capture the desired information. If the branch condition does not operate as desired, the operator will eliminate one or more of the recently-added portions of the trigger definition in an attempt to return to a trigger definition that is known to operate as desired. The operator may then perform another attempt to develop the next branch condition. This process is repeated until the current portion of the trigger definition operates as anticipated before additional layers of complexity are added.
However, it is often difficult to recall which aspects of a trigger definition have changed during a number of past acquisitions, which branch conditions successively acquired data, etc. Oftentimes, a number of events have been added or previous events and conditions have been modified. As a result, operators often spend considerable time evaluating past acquisitions, inevitably repeating prior work developing portions of a trigger definition that were previously verified. Not only are such activities time consuming, they often prevent novice operators that are not familiar with the triggering process from invoking useful acquisitions without further assistance or guidance from a more experienced operator. This is problematic in that a more experienced operator may not be available and the labor costs associated with the measurement increase significantly.
One solution has been to utilize the assistance of a common feature in conventional logic analyzers that provides the operator with an opportunity to store and subsequently retrieve from memory a predetermined number of selected trigger specifications. Generally, such functions require the operator to perform a number of explicit actions to store a trigger specification. For example, it is not uncommon for an operator to have to invoke a save trigger specification function through the implementation of a separate dedicated button, soft key, GUI button or menu item, etc. Oftentimes, the operator must first navigate through a series of soft key menus or GUI windows to arrive at the appropriate logical location that contains this save function interface. Once selected, the operator must assign a name or other identifier to the trigger specification which is to be saved. After the trigger specification is saved, the operator then again navigates to the soft key menu or GUI window to perform additional trigger definition development.
This process is difficult for the novice operator to utilize as well as inconvenient and distracting for an experienced operator. In particular, a novice operator often does not realize that a particular branch condition will not operate as anticipated, or does not recall the availability of the trigger definition save functionality. As a result, novice operators often inadvertently create a trigger specification that does not capture the desired data and from
Agilent Technologie,s Inc.
Charioui Mohamed
Grimley Arthur T.
LandOfFree
Automatic storage of a trigger definition in a signal... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Automatic storage of a trigger definition in a signal..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Automatic storage of a trigger definition in a signal... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2557091