It is difficult to find a design that does not 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 incorporating higher-speed serial buses such as USB, MIPI and PCIe for data transport.
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, the applications vary in capability. So when evaluating an oscilloscope that will include a protocol application, here are seven attributes that should be considered.
1. What protocols are supported and to what degree?
If you have 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 or a specific scope family.
The datasheet will also typically have good detail on the degree of support offered. Most vendors offer free short-term trial licences. 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 the scope, to determine how well a particular protocol is supported. For example, if you are using SPI, what is 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 low-, full- and high-speed versions of the spec as well as HSIC? If using I2C, does the application support I2C where the read/write bit is included in the address field?
Often, there is a need to look at simultaneous decode of more than one serial bus. How well does the scope allow you 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 three, four or five 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 autoscale. It determines the correct threshold level for each signal and scales the timebase appropriately. This feature is particularly effective for users who don’t make decode measurements frequently.
3. How useful is protocol decode display?
Decode display can vary from scope to scope to a high degree. Display 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 colourise 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 the screen. Decoding only on-screen info can be problematic. If the entire packet is not displayed on the screen, the scope would not decode any of the packets, or worse, may decode a partially displayed packet incorrectly.
Most vendors also offer a lister that will display decode of sequential packets. Listings let users see the flow of packets in a more condensed format (see Fig. 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.
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 Fig. 2). Some vendors provide listings with minimal or no time alignment with signal detail, which makes debug more challenging.
4. What type of packet triggering is incorporated in protocol application?
Scope vendors typically bundle packet-based triggers with each decode application. These triggers can be implemented in software or hardware. Knowing this level of detail is important if the user plans triggering 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 trigger circuitry of the scope. 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. They accomplish the task using post-processing software and hence are slower than hardware-based protocol triggers. 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 does not 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 pull up a serial trigger on your vendor’s scope for the protocol you are working with. See what types of packet-based triggering is available and whether the trigger is implemented in hardware or software.
5. How much memory does your scope support for packet capture?
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 typically come with some base memory, which can optionally be expanded by purchasing a licence to turn on additional memory. Scopes acquire asynchronously and hence use memory more quickly than dedicated protocol analysers or state-based logic analysers. For this reason, protocol apps benefit greatly from deep-memory scopes.
Check whether the scope under consideration allows you to independently set memory depth, sample rate and time base. This 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, use of segmented memory allows the users to capture this sequence of events using a hundred times less memory (50 kpts instead of 5 Mpts).
6. How fast does your scope process and display serial packets?
Decoding serial packets can be taxing on scope performance. While vendors will tout fast analogue 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 maximum update rate of 250 thousand waveforms per second. With 10 Mpts used for serial decode, the same scope updates at just one waveform every six seconds—more than a million times slower.
Slow update rates for protocol are problematic for several reasons. When viewing signals in real time, slow update rates dramatically degrade signal detail seen on the scope, miss showing infrequent events and frustrate 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 analogue scope channels for viewing other system activity (see Fig. 3). Second, when viewing more than one serial bus, MSOs offer additional channels unlike digital signal oscilloscopes that max out at four channels. Third, some vendors have more standard MSO acquisition memory than is available on scope channels, enabling capture of additional packets when the MSO’s digital channels are used rather than analogue channels.
Many vendors do not support segmented memory with MSO digital channels. This means that MSO channels cannot provide protocol decode when segmented memory mode is utilised. Check whether 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.
The author is senior product manager at Agilent Technologies