Synchronous and asynchronous capture combined with the right triggering is the key to efficient debug.
Today’s digital designs are evolving in a variety of ways, prompting new approaches to design, simulation, measurement and debug. One change is the use of more serial buses. Another is the use of system-on-a-chip (SOC) integrated circuits or advanced field-programmable gate arrays with SOC capability. Despite this evolution, there’s still a role for classic parallel buses in many designs and the need to measure those buses.
Before looking at specific measurement examples, it is helpful to consider the difference between synchronous and asynchronous capture and the benefits and limitations of each.
Synchronous (state-mode) capture means that the measurement system in the logic analyzer determines the logic value of digital parallel buses or control lines when there’s an associated valid clock, such as a rising edge on a system clock line. The primary purpose of such measurements is to determine if the basic functionality of the system is correct.
In contrast, asynchronous (timing-mode) capture means that the measurement system samples the value of a bus or individual digital lines “asynchronously” from the system under test. The measurement clock is generated by the logic analyzer rather than the target system. Typically, that sampling happens faster than the target system clock rate, ideally four times to even 10 times the system clock rate. This allows one to see the “timing” characteristics of the signals involved.
Functional verification with synchronous capture
When a digital design physical prototype is turned on, some designers first want to know if the correct functionality is occurring in the system through a variety of synchronous state-mode measurements. If something doesn’t look right, they’ll then move to asynchronous timing-mode measurements to see if they can figure out the problem.
Let’s consider a simple 8-bit counter circuit, and, for this particular example, the design was to produce counter data that would be valid and settled prior to the rising edge of a clock.
An initial evaluation of whether the counter is working properly is made by connecting eight data input lines of a logic analyzer to the eight data bit output lines of the circuit.
The logic analyzer is placed in a state- or synchronous-capture mode and clocking is set up to capture data on the rising edge of the clock signal. One easy place to set up a simple trigger is from the waveform window. The value hexadecimal E7 can be entered alongside the bus name “counter” to define a simple trigger event (Figure 1).
After pressing “run”, a sequence of hexadecimal values appear in the waveform view. They appear to be counting properly as shown in Figure 1; but another way of getting a more complete view of this data quickly is to turn on “chart mode”. A chart mode view can be seen in Figure 2, but the expected clean ramp is not seen.
Upon closer inspection, discontinuities are seen at the transitions from hex value F to 0 in the least significant bit of the counter.
Validation with asynchronous capture
The next step of digging deeper is accomplished through timing validation with asynchronous capture. This should sort out whether there is a functional issue, a timing issue or both.
In this mode, it is critical to sample and view the clock signal, as well as the data signal. An additional label is defined called “clock” and the proper logic analyzer clock input line is selected that has been physically attached to the counter circuit clock signal. The simplest trigger setup is just to enter the value “FF” into the simple trigger menu next to the counter bus in the waveform window.
An asynchronous capture with this trigger can be seen in Figure 3. The trigger event is on the left side of the trace and the transition can be seen to “00 hex”. In this mode, down to the resolution of the logic analyzer sampling circuit, one can see the signal timing on each line of the device under test. Data is supposed to be settled and valid before the rising edge of the clock line. Looking closely at the value of the counter bits in the vicinity of the clock rising edge, one has to check to see if basic setup and hold requirements between clock and data are being met.
Looking at the trace at the clock rising point where the counter bus should have transitioned from FF to 00, one can see that there is something drastically wrong. At this point the data bus has not yet settled to a 00 value. In fact, it becomes clear that it has settled in the vicinity of the falling edge of clock. A mistake was made in design timing. Markers are placed on the falling edge of clock (M1), at the start of settled bus value 00 (M2) and at the end of settled bus value 00 (M3). Simple timing measurements show the amount of setup time (M1-M2) and hold time (M3-M1) present, relative to the falling edge of clock.
Often it is difficult to pinpoint a problem in a design. Setting the right kind of trigger can be crucial to getting to the bottom of a design flaw. One of the most important trigger types is called a timeout trigger. This makes the logic analyzer watch for a repeating, expected target system behavior and then trigger if that behavior doesn’t happen within a certain, expected time period. This is especially helpful when a target system has a data bus lock up or hang to a fixed data value while the clock continues to run.
A timeout trigger is defined to watch for the counter bus to have a value of 00 at least every 10 usec. This trigger setup can be seen in Figure 4.
A logic analyzer capture of the counter circuit experiencing the anomaly can be seen in Figure 5 where normal operation can be seen on the left side of screen, while the right side of the screen shows a transition into abnormal operation, where the bus transitions from FF to 80 instead of from FF to 00. Notice the trigger occurs 10 usec after the counter has a value of 00 but never has that value again. An oscilloscope is also synchronized to the logic analyzer trace and imported to the screen to get an analog view of failing counter bit 7.
Despite the changes in digital system architecture, including transitions to serial bus protocol-oriented bus structures, many designs today still employ basic parallel bus architectures. Often, such buses must be analyzed to either validate a design or track down a defect. Knowing how to use synchronous and asynchronous capture modes as well as intelligent triggering can significantly influence the speed of moving a design past the debug stage and into the market.