Capturing data signals during embedded system design can prove challenging. Modern logic analyzers make data acquisition tasks easier by providing advanced triggering capabilities that get to the root causes of many complex design problems. Advanced triggering is made even more understandable and easier to use when the logic analyzer provides a simplified trigger-programming interface.
Like its close cousin the digital storage oscilloscope, a logic analyzer acquires data for display and analysis. In addition, logic analyzers can help solve or identify many hardware problems, including logic errors, logic level violations, crosstalk, bus contention, clock skew, timing margins and violations, setup/hold violations, and glitches. They also address real-time software problems such as unexpected software execution, memory variable corruption, stack overruns, incorrect task switching, and incorrect interrupt levels.
The logic analyzer is ideal for solving these kinds of problems because of its capability to characterize timing relationships among hundreds of signals in complicated electronic circuitry. The sampling and data-storage capabilities of the logic analyzer provide a window into circuit operation, helping you determine when certain important data events occur as well as revealing a real-time history of circuit operation and software execution.
Configuring a logic analyzer for data acquisition includes the following key settings:
- Clocking mode, which determines what clock will be used to drive data sampling.
- Channel memory depth, the number of samples that can be stored.
- Channel probe assignments, a mapping of signals from the system under test to analyzer probe channel groupings.
- Setting up the trigger program to identify a specific event or data value.
A trigger program is represented in the user interface as a set of logical instructions that controls the logic analyzer’s acquisition hardware, or module, enabling it to perform real-time data recognition. Depending on the configuration, a logic analyzer system may have numerous acquisition modules, each with its own trigger program.
During acquisition, once a specified data value has been identified, the logic analyzer marks this value and completes the process of filling acquisition memory. The identified data value is known as the trigger sample and provides a reference point against which data from all modules can be time correlated for display and analysis.
Trigger Programming Fundamentals
Different logic analyzers on the market today present various user interfaces to support trigger-program development. Normally, an advanced or expert user interface provides a way to build up a trigger program from smaller functional blocks or conditions. The resulting program usually is displayed as a state machine, in which each state has one or more conditional expressions of the form: If event condition occurs, then perform a corresponding action.
An event condition is an expression evaluated in real time by the logic analyzer. Examples of simple event conditions can be found in Table 1.
An action is an expression performed by the trigger program if the associated event condition has been evaluated as true. There can be multiple actions performed in response to a true event. Actions include programming the acquisition hardware to perform responses such as triggering the logic analyzer, storing a sample, incrementing a hardware counter, starting and stopping a timer, or simply transitioning to another program state.
For example, here is a one-state trigger program containing a single event that tests the Address bus for a value and a single action that triggers the logic analyzer:
State 1:
If Address = 1234 Ü event
Then Trigger Ü action
Because hardware developers are the primary users of logic analyzers, most interface terminology is hardware-oriented, such as AND, OR, Signal, Trigger. However, the general structure of the program is very software oriented since it is a set of if/then conditions.
For instance, the following program, consisting of two events and two actions, demonstrates both kinds of terminology:
State 1:
If Address = 1234 AND Channel 1
Goes Low Ü event AND event
Then Set Signal 1 AND Trigger Ü action AND action
Trigger-Program Development
Most logic analyzers can detect a number of useful event types. These predefined types allow you to organize data signals into collections that make sense for the circuit being analyzed. For example, it is much easier to write a program to monitor changes within a channel group, such as an address bus, than it is to write a program testing each channel individually.
In addition to the predefined event types, trigger programs have mechanisms to filter acquired data so that only data of interest, such as a glitch, transition, or a setup/hold violation, is stored. This reduces the number of samples that must be analyzed and provides a more concise history of data surrounding the trigger event.
In general, because of the power and flexibility of the predefined event types, many simple programming tasks need nothing more than a one-state trigger program. Some typical event types are listed in Table 1 with examples of how they might be used.
For more involved circuit design or software problems, it is more difficult to construct the trigger program. Generally, it is helpful to develop a complicated trigger program by creating smaller, simpler programs of fewer states.
Flowcharts, state tables, or state diagrams can help organize the programming effort. Using this stagewise-development approach allows you to ascertain that program states function as desired.
For example, a common problem in bus analysis or debugging embedded software is to learn when the time between two events exceeds some specified value. Figure 1 shows a program that triggers when the duration between the INTERRUPT line going low and an Address bus match exceeds a given time, which could be used to determine if interrupt handling latency exceeds a specified time.
The example demonstrates a program containing multiple execution states, each of which has one or more event conditions to test. True conditions cause the program to traverse execution states, with one such traversal resulting in a triggered system.
This program could just as easily have been adapted to solve another kind of problem. For example, by using two address matches, we could have profiled a piece of code in which we know the entry and exit addresses and want to determine if execution can complete within a specified maximum time.
As Figure 1 demonstrates, using state diagrams to map out and develop trigger programs provides several advantages. These include accomplishing the following:
- Break down the triggering problem into smaller logical units, making it easier to understand and arrive at the total program solution.
- Detect programming logic errors at a glance.
- Provide a convenient way to document trigger-program intent for communications with other design-team members.
- Represent the program in a way that will facilitate later maintenance, reuse, and extension.
A Simplified Trigger-Programming Interface
In addition to providing a powerful trigger-programming interface, some logic analyzers offer a simplified interface for making trigger programs more accessible and easier to use (see sidebar). This interface prompts you to supply only those selections and values that actually are necessary to use the program. The bulk of the trigger-program implementation is hidden.
Conceptually, a simplified trigger interface is straightforward. A list of trigger programs, organized into problem categories, is presented for you to browse through and select. Typical categories include measuring the time between events, counting event occurrences, looking for event sequences or combinations of events, and triggering on glitch or setup/hold violations.
Once the proper clocking has been set up and the appropriate channel groups created, you can quickly scan through and select the desired trigger program, fill in the event information, and start data acquisition. In cases where the program list does not have an exact solution, most likely there will be a selection that is similar enough to provide a starting point for you to develop your own program in the advanced trigger-programming interface.
An example of a simplified trigger-programming interface is shown in Figure 2. In this figure, which is a portion of the Tektronix TLA family of logic analyzers trigger interface, a timing diagram shows how circuit signals relate to event parameters you set.
Notice that the underlying complexity of the trigger program in Figure 1 has been hidden. No programming is required. You only must set the two events of interest and fill in the time duration. With the addition of textual prompts and descriptions, you can understand what the program does and how best to use it.
Modern logic analyzers can make the complex task of triggering easier. By hiding as many of the programming details as possible and presenting you with a minimum of trigger setup decisions to make, a number of advantages can be achieved.
New and infrequent logic analyzer users quickly become productive because they can focus on the events of interest while the interface hides the underlying program logic. Program data entry mistakes are minimized since selections are entered just once as opposed to many places throughout a trigger program.
Additionally, the interface can easily be structured for reuse with different event types and program descriptive terminology, and images may be tailored for specific users and problem domains. By providing both simplified and advanced trigger programming interfaces, the logic analyzer supports the full spectrum of users who must perform the everyday tasks of real-time hardware and software debugging.
Summary
This brief introduction to logic analyzer trigger programming has focused primarily on support for creating trigger programs as part of data acquisition setup. Many triggering problems can be solved with a single-state program using one or more predefined logic analyzer event types.
When more complex programs are needed, solutions can be mapped out with the use of state diagrams augmented with flow charts. To make a complex trigger program more accessible and easier to use, the logic analyzer can provide a simplified trigger interface with ready-to-use programs for many common triggering tasks.
These programs normally require just a minimum amount of event-parameter setup, relieving you of the burden of constructing the entire underlying program logic. As a result, the simplified trigger interface guides the new and infrequent logic analyzer user over many of the hurdles associated with using advanced trigger programming.
About the Author
Robert Cohn is a software engineer for the logic analyzer product line at Tektronix. He has worked for Tektronix for more than 22 years, 15 of those as a software developer. Mr. Cohn received a B.S. in computer engineering from the University of Portland and an M.S. in computer science from the Oregon Graduate Institute. Tektronix, 13975 S.W. Karl Braun Dr., Beaverton, OR 97077, e-mail: [email protected]
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2002 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
June 2002