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
