Seven scope attributes are key for protocol analysis

Seven scope attributes are key for protocol analysis

While all major scope vendors offer protocol decode and triggering applications, those applications can vary widely in capability.

BY JOEL WOODWARD
Senior Product Manager, Oscilloscopes
Agilent Technologies
www.agilent.com

It’s difficult to find a design that doesn’t include one or more lower-speed serial buses, such as JTAG, I2C, SPI, CAN, LIN, FlexRay, RS-232, Mil-std 1553, or a proprietary variant. Furthermore, many products are also incorporating higher-speed serial buses, such as USB, MIPI, and PCIe, for data transport. So protocol apps have become an important scope capability for good reason: with the right scope and protocol application combination, teams can gain quick insight to resolve issues.

While all major scope vendors offer protocol decode and triggering applications today, those applications can vary widely in capability. Therefore, when evaluating an oscilloscope that will include a protocol application, the following seven attributes should be considered.

1. What protocols are supported and to what degree?

If you’ve ever hand-decoded waveforms, you will immediately understand the value of real-time decode. Protocol apps are typically offered as software options, and can be added to an existing scope, or ordered with a new scope. So when selecting a scope, check the datasheet to see what protocols are supported on a particular scope and in the scope family.

The datasheet will also typically have good detail on the degree of support offered. Most vendors offer free short-term trial licenses. Some vendors have a previously acquired example that you can quickly load, or hook up to your own target and try out. Pull up the application on a scope to determine how well the particular protocol is supported.

For example, if you are using SPI, what’s the fastest data rate that is supported? Does the application support 2, 3, and 4-wire SPI, or just a subset? If you are using USB 2.0, does the application support the low-, full-, and high-speed versions of the spec as well as HSIC? If using I2 C, does the application support I2 C where the read/write bit is included in the address field?

Often, there’s a need to look at simultaneous decode of more than one serial bus. How well does the scope allow users to set up decode of multiple buses, navigate between buses, or change which bus is being used as the trigger source?

2. How easy is it to configure for decode?

Engineers excel at problem solving. Anytime too much brain power or time is required for a task, engineers will find another, less taxing method of attacking a problem. Setting up a scope to take a protocol measurement should be something that you can do in a minute or less.

Configuring the scope for protocol decode involves selecting which channels are probing specific serial signals, and setting the threshold value for determining when the signal is high and when it is low. While the concept seems simple enough, when setting up protocol decode for a serial bus with 3, 4, or 5 signals, the task becomes more complex than originally anticipated. If decode is set up for multiple simultaneous serial buses, the task becomes even trickier.

One innovative feature that some vendors offer is “Auto Setup” for decode. After the user assigns channels, the auto setup works a bit like a typical scope autoscale feature: it determines the correct threshold level for each signal and scales the timebase appropriately. This feature is particularly effective for users that don’t frequently make decode measurements.

3. How useful is the protocol decode display?

The decode display can vary from scope to scope to a high degree. So be sure to display the protocol decode for the bus you are interested in on the scope you are considering.

Annotating waveforms with decode is the most common method of displaying protocol packets. Packet content is aligned in time with parametric signal detail. Some vendors colorize packets to make it easier to determine packet sequence, even with larger timebase settings when packet detail is too compressed to see detail.

Some vendors decode the entire acquisition memory, while others decode only what is on screen. Decoding only on-screen info can be problematic. If the entire packet isn’t displayed on screen, the scope won’t decode any of the packet, or worse, may incorrectly decode a partially displayed packet.

Most vendors also offer a lister that will display a decoded list of sequential packets. Listings let users see the flow of packets in a more condensed format (see Figure 1 ). Unlike decode in waveform areas, listings show packet detail independent of timebase settings. Listing detail can vary greatly from vendor to vendor and scope to scope.

Fig. 1. Protocol listers enable users to quickly move between physical and protocol layer with the advantage of seeing packet detail in the lister while zoomed out as shown in this USB decode example.

When evaluating protocol decode on scopes that incorporate a lister, ensure that your vendor provides time alignment between each row in the lister and signals in the waveform display. With time alignment, users can move between physical layer and packet layer quickly and confidently (see Figure 2 ). Some vendors provide listings with minimal or no time alignment with signal detail, which makes debug more challenging.

Fig. 2. Time-aligned markers track in the listing when moved in the waveform area, or conversely tracks in the waveform area when a new row of the lister is highlighted as shown on this SPI decode example.

4. What type of packet triggering does the protocol application provide?

Scope vendors typically bundle packet-based triggers with each decode application. These packet-based triggers can be implemented in software or hardware, and knowing this level of detail is important if the user plans to trigger on infrequent events.

Hardware-based serial packet triggers are typically implemented in an FPGA, and run in real-time. The vendor implements a real-time state machine that tracks incoming packet content and, when the specified condition is met, this hardware interacts with the scope’s trigger circuitry. Hardware-based protocol triggers will absolutely trigger the scope on a specified packet no matter how infrequent the event occurs.

Software-based serial packet triggers can be developed more easily, but is slower than hardware-based protocol triggering because it is accomplished using post-processing. That is, after each acquisition, the software searches the acquisition record for the specified packet. If the specified condition is found, the scope displays the acquired memory buffer including both signal and packet detail. Alternatively, if the software searches the acquired memory and doesn’t find the specified trigger condition, the scope discards the acquisition and acquires a new acquisition. Due to the high amount of processing after each acquisition, software-based triggering has significant dead time between acquisitions and is extremely likely to miss trigger conditions that occur infrequently. As memory depth increases, so does processing time, thus significantly increasing dead time between acquisitions.

So be sure to pull up a serial trigger for the protocol you are working with on the scope you’re considering. See what types of packet-based triggering is available and whether the trigger is implemented in hardware or software.

5. How much packet-capture memory does your scope support?

Users typically don’t know how much memory is needed until they encounter a situation that requires longer time capture than their scope is capable of. Scopes acquire asynchronously and hence use memory more quickly than dedicated protocol analyzers or state-based logic analyzers. For this reason, protocol apps benefit greatly from deep-memory scopes. So scopes typically come with some base memory which can optionally be expanded by buying a license to turn on additional memory.

Ask whether a scope you’re considering allows users to independently set memory depth, sample rate, and time base. Having such capability makes it dramatically easier to capture and view protocol signals with full memory depth. On scopes where this is not possible, users must capture the entire acquisition on screen, then pan and zoom to see packet detail.

Serial traffic often incorporates periods of dense activity followed by relatively long periods of dead time. For this purpose, using the scope’s segmented memory mode enables users to capture significantly longer periods with the same amount of memory. Each segment is started when the scope sees a specified trigger condition: for example, when a USB device sends a number of packets, each with a SETUP packet. Using segmented memory this sequence of events can be captured using 100 times less memory (50 kpts instead of 5 Mpts).

6. How fast can your scope process and display packets?

Decoding serial packets can be taxing on scope performance. While vendors will tout fast analog channel update rates when very shallow memory is used, few vendors will communicate how fast or slow they decode serial packets particularly with deep memory.

For example, one scope vendor specifies a max update rate of 250 thousand waveforms per second. When 10 Mpts are used for serial decode, the same scope updates at just 1 waveform every 6 seconds more than a million times slower.

Slow update rates for protocol are problematic for several reasons. If viewing signals in real time, slow update rates dramatically degrade signal detail seen on the scope, miss showing infrequent events, and frustrates users with sluggish instrument control.

7. What benefits does using an MSO have for protocol analysis?

Mixed-signal oscilloscopes (MSOs) make great choices for protocol analysis for several reasons. First, they free up analog scope channels for viewing other system activity (see Figure 3 ). Second, if viewing more than one serial bus, MSOs offer additional channels, unlike DSOs that max out at four channels. Third, some vendors have more standard MSO acquisition memory than is available on the scope channels enabling capture of additional packets when the MSO digital channels are used rather than the scope’s analog channels.

Fig. 3. MSOs can use any combination of digital or analog channels for protocol decode as shown in this SPI decode example. This preserves some analog channels for other time-correlated measurements, and allows sufficient channel availability if needs arise to decode multiple buses simultaneously.

Many vendors do not support segmented memory with MSO digital channels. This means that the MSO channels cannot provide protocol decode when segmented memory mode is utilized. Check to see if your scope vendor supports segmented memory on the MSO channels.

Adding protocol analysis capabilities to a scope enables teams to debug a wider range of issues faster. Evaluating both specific protocol apps, and the scope’s underlying ability to effectively perform packet-based triggering and decode will result in selection of the scope that best fits your team’s need. ■