Logic analyzers are instruments that have a reputation for being difficult to learn and difficult to use. They earned this reputation because they are unusually complex and require users to understand how they were designed in order to understand how to use them. This is like requiring a driver to understand how an automobile was designed in order to drive a car.

Infrequent usage magnifies user difficulties; logic analyzers are only used during the design stage when hardware is available for debug. This means that most engineers may not use a logic analyzer for several months and many have said that each time they use the instrument, they must re-learn it.

Recent research on the logic analyzer usage model has simplified logic analyzers by streamlining the tasks that users perform in setup, triggering and data analysis. We review the new innovations in each area, using the Agilent 16900 logic analysis system as an example.

Figure 1: The Bus/Signal setup dialog

Unless the number of buses and signals is very low, it is easy to see that specifying channels one by one can be a tedious process even if you have a list of exactly which channels to use. Unfortunately, when connectors, such as MICTORs, are used on the device under test (DUT), this mapping from signals to channels isn't available. The problem is:

• each signal is routed to a specific pin on the connector, such as Pin 38, and
• the probe (which connects the logic analyzer to the connector) maps Pin 38 to Channel 0 on whichever pod is used with that probe.

In other words, what engineers have in their schematic maps signals to pins, but the logic analyzer does not accept pins, but does accept channels. Previously, engineers were required to manually do the conversion themselves with the help of the probe documentation.

Fortunately, a new feature has been added that displays connector pins in the Bus/Signal Setup dialog such that users no longer need to perform the manual transformation. All that the user needs to do is define which type of connector was used and which logic analyzer pods were connected to it. For example, a single-ended MICTOR connector uses two pods. To avoid confusion, these two pods are labeled "Even" and "Odd" (see the example of defining a MICTOR connector using the "Add Probe" dialog in Figure 2). Notice that the user has specified Pod 4 for "Even" and Pod 3 for "Odd".

Figure 2: The Add Probe dialog

Once the user has defined their probes, the connector pin information can be shown in the Bus/Signal dialog as shown in Figure 3. Notice that there is a new row located above the logic analyzer channels (this row has a yellow background color and cell 15 has the value "7" in it). With the connector pins displayed, it is clear that the signal D0 is connected to Pin 7, which is the same as Pod 4 Channel 15. Now users can read the information directly from their schematic and enter it into the logic analyzer without having to reference the probe documentation to perform a transformation.

Figure 3: The Bus/Signal dialog showing connector pins beneath the channels

Netlist Import
While the display of connector pins does make entering buses and signals easier, an even better method is to import buses and signals directly from the EDA tool used to layout the board. Many EDA tools create ASCII netlist files, and now logic analyzers, such as the 16900A, are able to import buses and signals directly from these design simulation tools.

The ASCII netlist file maps nets to connections, such as D0 to J1-7. Notice in Figure 2 that users specified the name of the board connection, which was "J1" in this example. This name is used to identify which nets in the netlist file map to pins on a connector such as a MICTOR. Nets that are not mapped to logic analyzer probes are ignored. In other words, if a user defines J1 and J2 as connectors using the "Add Probe" dialog, then all connections other than J1 and J2 in the netlist file will be ignored. The result is an automatic method for setting up buses and signals that is fast and accurate. This method is possible because the logic analyzer was enhanced to accept what the user has readily available, a netlist file, instead making the user transform this into the format used by the logic analyzer. The time saved by importing a netlist directly into the logic analyzer can be hours or even days. According to one engineer who had a DUT with eight MICTOR connectors, "It could take a week to enter all of the buses and signals manually."

Probe Summary
Once users have defined the probes, a Probe Summary dialog is created, as shown in Figure 4. The purpose of this dialog is to tell users how to re-connect the probes in the event that this becomes necessary. This task can be a fairly common occurrence because most labs have very few logic analyzers and several engineers must share the instrument. This means that engineers frequently are not allowed to keep their DUT connected to the logic analyzer for the duration of their project forcing them to connect and re-connect their DUT to the logic analyzer. The Probe Summary dialog saves time by showing at a glance exactly how to re-connect the probes.

Figure 4: The Probe Summary allows users to re-connect the probes

Unified Sampling Dialog
There are two main methods for telling a logic analyzer when to acquire a sample, either at regular intervals (Timing Mode) or based upon a DUT clock signal (State Mode). While setting up the sampling might seem easy because there are relatively few choices, this has been difficult because the settings were spread across several dialogs that mapped to the underlying logic analyzer architecture. The key innovation here was to allow the user to specify all parameters in a single dialog (see Figure 5).

Figure 5: The Unified Sampling Dialog

Users select Timing or State Mode at the top of the dialog. If the user choses Timing Mode, then the sampling period is specified. If the user choses State Mode, then one or more clock signals are selected. Notice that there is one clock channel per pod. Each clock channel is clearly labeled and has an activity indicator. The innovation in this case is to put everything together in one place such that users do not forget a step. The most common problem in the past was when users selected State Mode but forgot to specify which clocks to use and then the logic analyzer could not collect data.

Eye Finder
When using a logic analyzer in State Mode, it is essential to only take a sample when bus values are stable. In other words, the logic analyzer should not take a sample when a bus is transitioning from one value to another. If it does so, then the bus value will be random implying that there could be a problem on the DUT that does not actually exist. Now users have a feature called Eye Finder. Eye Finder analyzes each bus to determine, relative to the sample clock, where the bus values are stable and where they are transitioning from one value to another. Eye Finder automatically sets up the logic analyzer to take a sample at that point (see Figure 6). The colored regions in Eye Finder are where the bus values are transitioning and the white regions are where they are stable. The blue lines are where the logic analyzer will acquire a sample.

Figure 6: The Eye Finder dialog makes it easy to see where a bus is stable relative to the sample clock. The blue lines indicate where the logic analyzer should take a sample.

Before Eye Finder, it was difficult to be sure where the eye of a bus was located. While Figure 6 shows all of the bits of the ADDR bus with the same stable region, this can vary from signal to signal depending upon where each signal is probed. Without Eye Finder, engineers were forced to measure signals a few at a time on an oscilloscope and then manually enter the sample position on the logic analyzer.

Figure 7: Simple Trigger in a Waveform window

Simple Trigger is not designed to provide all of the trigger functionality for the logic analyzer. That is why there is also a separate dialog for more advanced triggers. But whenever users want to specify a simple trigger, they can do so quickly and easily without having to open a separate trigger dialog.

Quick Trigger
Another easy method for specifying a trigger is known as Quick Trigger. In this case, the user can see the event in the waveform window that they want to trigger on. To set the trigger, they simply draw a box around the region and select Quick Trigger from the popup menu. This causes the values in the selected area to be copied to the Simple Trigger as shown in Figure 8.

Figure 8: Highlighting a region to be the trigger

Quick Trigger is limited to setting simple triggers and cannot be used to specify a sequence of events. So when a box is drawn around a bus that transitions from one value to another, only the left most value is copied to the Simple Trigger. Yet this feature does cover a surprising number of common triggers. Quick Trigger was created because engineers told us that simply selecting an area of the screen was the simplest method for specifying a trigger.

Flexible Trigger Functions
Trigger functions are building blocks that simplify the process of setting up advanced trigger sequences. While such functions have existed in logic analyzers for some time, they cannot be modified. In other words, if the user was unable to find an exact match for the trigger they needed, then the functions were of no use. As an example of a flexible trigger function, see the "Pattern present for > time" function in Figure 9. This causes the logic analyzer to trigger when there has been a value of 0123456 on the ADDR bus that lasts at least 5 ns.

Figure 9: An unmodified trigger function

While this is a useful function, users may want to trigger when both the ADDR bus and DATA bus have their values for a period of time. With a flexible trigger function, it is only a matter of adding another event as shown in Figure 10. Therefore, we didn't need to find an exact match in the trigger functions. All we had to do was find a near match and then make a quick modification and the trigger has been set up. The resulting modified trigger function is shown in Figure 11.

Figure 10: Adding an event to a trigger function

Figure 11: A modified trigger function. Now there is a bus and signal that both must be stable for 10 ns

Beyond just changing a trigger function, two or more functions can be combined to form a "Followed By", as in "Find Event X followed by Event Y". In Figure 12, we see an example of finding an "Edge and Pattern" followed by a "Pattern present for > time". While users can still build advanced triggers from scratch, flexible trigger functions save valuable time.

Figure 12: Two trigger functions combined to form a "Followed By"

Trigger History
The Trigger History recognizes that engineers often want to switch back and forth between several different triggers. To make this as easy as possible, each time we run the logic analyzer, the trigger is saved. This is very much like an Internet Browser which provides a history of the sites that we visited. While users could simply save each trigger themselves after each run, it is more efficient for the system to remember the triggers. An example of this feature is shown in Figure 13.

Figure 13: The Trigger History retains all of the triggers from recent runs so that users can easily switch between them.

Figure 14: Placing a marker on an edge

Snap-to-Edge markers save time because the markers are placed precisely on the edge. Secondly, they are also useful for finding edges which are not visible on screen. Because the Snap-to-Edge markers will cause the time delay to be changed when snapping to off screen edges, they are also a new method for navigating through waveform data.

Quick Measurement Tool Tips
Measuring the time of an event on the screen should be a very easy task, but unfortunately, in the past, this required placing a marker on either side of event of interest and then displaying the time difference between the two markers. Now, measuring time is simply a matter of drawing a box as shown in Figure 15. Notice the tool tip provides a quick measurement of the selected area.

Figure 15: A Quick Measurement Tool Tip

Quick Search
Quick Search is very similar to Quick Trigger. The only difference is that instead of setting up the trigger based on the selected waveforms, it performs a search using the selected waveforms. This eliminates the need to locate and understand a Find dialog unless performing a more sophisticated search.

Value Based Markers
Most logic analyzer markers can only be placed at a specific point in time. This means that each time that the logic analyzer is run the markers are at the same point in time even if the event at that point has changed. If the user is interested in placing it in an event rather than a specific point in time, then each marker must be moved to the event of interest after each run. Value based markers solve this problem by associating markers with an event relative to the trigger. For example, a user might create a marker that is always located on the first occurrence of DATA = 1234 after the trigger. After each run, the marker automatically moves to this event. While time based markers are still valuable, now logic analyzers give users the choice of making each marker either time based or value based. Value based markers are shown in Figures 16 and 17. In these two figures, the marker M3 is defined as being on the first occurrence of DATA = 1111 after the trigger. M3 will automatically move to this position after each run.

Figure 16: Selecting "Value" as the position for a marker

Figure 17: Setting up a Value Based Marker