Text preview for : 5990-8359EN Selecting the Right Scope for Protocol Analysis Applications - Application Note c2014061 part of Agilent 5990-8359EN Selecting the Right Scope for Protocol Analysis Applications - Application Note c2014061 Agilent 5990-8359EN Selecting the Right Scope for Protocol Analysis Applications - Application Note c20140610 [14].pdf
Back to : 5990-8359EN Selecting the | Home
Keysight Technologies
Selecting the Right Oscilloscope for
Protocol Analysis Applications
Application Note
Introduction
Serial buses are pervasive in today's electronic designs to
provide critical communication between ICs, subsystems, boards and
systems. I2C and SPI have found their way into a broad array of chips and
peripherals including FPGAs, a variety of I/O, ADCs, sensors, ASICs and
processors. JTAG serial buses, test chips and boards also provide debug
ports for microprocessors and other integrated circuits. CAN, LIN and
FlexRay enable noise-immune communication networks for automotive
and industrial products. USB ports have become pervasive on mobile and
other consumer products, and PCIe has gained a foothold by passing large
amounts of data quickly. Even legacy serial buses like RS-232/485/485 and
MIL-STD 1553 continue to prosper despite their age. Low cost, minimal pin
usage and a protocol layer that eases software implementation make serial
buses ideal for a wide variety of applications across a range of industries.
All major oscilloscope vendors now offer scope-based protocol applica-
tions that enable you to gain faster and better insight when debugging
systems with serial buses. These applications let oscilloscopes trigger on
and display packets in addition to parametric signal detail. They help you
answer questions, including "How are the devices on each end of the bus
negotiating the link?" and "What values are being passed on the bus?"
With the right combination of oscilloscope and protocol application, you
can resolve issues quickly, saving days to weeks of time. Although all
major scope vendors offer protocol decode and triggering applications, the
applications vary in capability and quality. When evaluating a new oscil-
loscope that will include protocol applications, you should consider the
following six questions.
1. What protocols are supported and to what
degree?
Make sure the oscilloscope vendor has support for protocols that you currently
use or are likely to use in the near future. It's easy to check a Web page to see
if the protocol you are interested in is supported on a particular scope. Getting
a trial license is a great way to make a determination. You need to pull up the
application on an oscilloscope or look through detail in the datasheet, to deter-
mine how well the particular protocol is supported.
Figure 1. View product web pages to see
if the protocol you are interested in is
supported on a particular scope.
For example, if you are using SPI, what is the fastest data rate that is support-
ed? Does the application support 2-, 3- and 4-wire SPI or only a subset? If you
are using USB 2.0, does the application support the low-, full- and high-speed
versions of the specification as well as HSIC? If using I2C, how well does the
application support I2C where the read/write bit is included in the address field?
Figure 2. Try out a protocol application on
your oscilloscope to better determine its
capabilities.
3
1. What protocols are supported and to what
degree? (Cont.)
Do you need to look at simultaneous decode of more than one serial bus (Figure
3)? How easy is it to set up decode of multiple buses, navigate between buses
or change which bus is being used as the trigger source?
Figure 3. Keysight Infiniium scopes
support simultaneous, time-correlated
decode of up to 4 serial buses.
Check with your oscilloscope vendor to determine which serial buses they sup-
port with a protocol application. You will need the information to meet current
needs and plan for future needs.
Table 1. Infiniium scopes support a wide array of serial protocols.
Serial Bus Protocol Infiniium Oscilloscope Family
S-Series 90000 Series 90000 X-Series
CAN and CAN .dbc
symbols
Ethernet 10GBase-KR
FlexRay
HDMI Up to 740 Mbps
IC
2
JTAG
LIN
MIPI
PCIe
RS-232/485/488
SAS
SATA Up to 1.5 Gbs
SPI
SVID
USB
Xaui
8B/10B
4
2. How easy is it to set up protocol 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 oscilloscope to take a protocol measurement should take
you a minute or less.
To configure the scope for protocol decode, select which channels are probing
specific serial signals and set the threshold value to determine when the signal
is high and when it is low.
Although the concept seems simple enough, when you set 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.
Keysight Technologies, Inc. offers "Auto Setup" for decode (Figure 4). After you
assign channels, Auto Setup works a bit like autoscale. Auto Setup determines
the correct threshold level for each signal and scales the timebase appropriately.
This feature is particularly effective for users who don't often make decode
measurements or set up of multiple decodes simultaneously.
Figure 4. Auto Setup lets you set
up protocol decode on one or more
buses in less than 30 seconds.
5
3. How is the protocol decode displayed?
Although all vendors provide some level of decode, decode quality varies dra-
matically. Start by displaying protocol decode for the bus you are interested in
on the oscilloscope you are considering.
Decode on waveforms is the most common method of displaying protocol pack-
ets (Figure 5). Packet content is aligned in time with parametric signal detail.
Figure 5. Decode on waveforms enables
you to see time-aligned packets with the
serial signal sources, but requires you to
zoom in to see packet detail.
Keysight colorizes packets to make it easier to determine packet sequence even
with larger timebase settings when packet detail is too compressed to see detail.
Figure 6. Keysight colorizes packets
to make it easier to determine packet
sequence.
Some vendors decode the entire acquisition memory, while others decode only
what is on screen. Decoding only on-screen information can cause problems. If
the entire packet isn't displayed on-screen, the oscilloscope won't decode any
of the packet, or worse, decode it incorrectly. To correct the problem, users are
forced to create a main display with all acquisition memory and a second zoom
window to show decode detail, as shown in Figure 7.
Figure 7. Zoom in on detail in the
waveform area while protocol packets
from off-screen capture is still shown in
the listing area.
6
3. How is the protocol decode displayed? (Cont.)
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 (Figure 8).
Unlike decode in waveform areas, listings show packet detail independent of
timebase settings. But be aware that listing detail can vary greatly from vendor
to vendor and scope to scope. Are lister rows colorized to match waveform
decode color for rapid transition between physical and protocol layers?
Figure 8. Infiniium protocol listers let
you move quickly between physical and
protocol layer with the advantage of
seeing packet detail in the lister while
zoomed out, as shown in this USB
example.
When evaluating protocol decode on oscilloscopes 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 with confidence (Figure 9).
Some vendors provide listers with minimal or no time alignment with signal
detail.
Figure 9. Time-aligned markers on
Infiniium oscilloscopes track in the listing
when moved in the waveform area or
track in the waveform area when a new
row of the lister is highlighted, as shown
in this SPI example.
7
3. How is the protocol decode displayed? (Cont.)
Does your oscilloscope allow different views of packet content?
Here's an example of Keysight's Infiniium protocol viewer. In addition to seeing
packet detail, users can see specified packet content in different formats. For
example, see data packet payloads and packet detail in the header section as it
would appear in a databook.
Figure 10. Packet details, payload, and
header show additional info for the packet
highlighted by the blue alignment bar.
Does your oscilloscope allow the listers to go full screen to display a greater
number of packets at once? Infiniium oscilloscopes allow users to determine
how much of the display to dedicate to the lister versus the waveform area.
Figure 11. Infiniium oscilloscope with full
screen lister.
On Infiniium oscilloscopes, a Demo Center stores saved files that can be quickly
loaded into the scope for all supported protocol decodes. You can rapidly evalu-
ate how decode is displayed for your particular protocol.
Figure 12. Connect to a live target or use
built-in previously captured signals to
evaluate decode and trigger capability for
a specific protocol application.
8
4. What type of packet triggering and searching
is standard or incorporated in the protocol
application?
Determining when to have the oscilloscope trigger and begin acquiring packets
is critical for debug. Traditional edge, width and pattern trigger are not sufficient
for packet triggering. Oscillocope 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 you plan
to trigger on infrequent events.
Hardware-based serial packet triggers are implemented in hardware--typi-
cally an FPGA--and run in real time. The vendor implements a real-time state
machine that tracks incoming packet content. When a specified condition is
met, this hardware interacts with the scope's trigger
circuitry. For single-shot protocol acquisitions that require a trigger, hardware-
based triggering is a requirement (Figure 13).
Software-based serial packet triggers are implemented in software. After each
acquisition, the software analyzes the acquired packets and determines if any
meet the trigger condition. If so, the oscilloscope displays the acquired signals.
Alternatively, if the software searches the decoded packets and doesn't find
the specified trigger condition, the oscilloscope discards the acquisition without
display and acquires a new acquisition, starting the process again.
Software-based triggering has significant dead time between acquisitions,
which makes it likely it will miss trigger conditions that occur infrequently. As
memory depth increases, so does processing time, making dead time between
acquisitions for software-based triggering even larger.
Given the superiority of hardware-based protocol triggering, why would a pro-
tocol app offer only software-based triggering? It's likely that hardware-based
triggering for that specific protocol wasn't developed.
Pull up a serial trigger on your vendor's oscilloscope for the protocol you are
working with. See what types of packet-based triggering are available and
whether the trigger is implemented in hardware or software.
Figure 13. Hardware-based protocol
triggers will absolutely enable the
oscilloscope to trigger on a specified
condition no matter how infrequent or brief
the specified event is, with minimal latency
between successive triggers. Shown is an
USB enumeration trigger example.
9
5. How much memory does your scope support
for packet capture?
Capturing a sufficient number of protocol packets is
critical for effective debug. Oscilloscopes acquire asynchronously and therefore
use memory more quickly than dedicated protocol analyzers or state-based logic
analyzers. For this reason, scope users with protocol analysis needs benefit
greatly from deep-memory oscilloscopes. To maximize memory and display
utilization, check to see if your scope vendor allows you to set memory depth,
sample rate and timebase independently. This capability makes it dramatically
easier to capture and view protocol signals with full memory depth.
Oscilloscopes ship with a fixed amount of standard memory and users enable
optional acquisition memory. To get a first order approximation of how many
packets you can acquire in a single run, you can do a quick calculation by using
the required sample rate for a specific bus coupled with the oscilloscope's time-
base and optional memory. Most oscilloscope vendors have channel interleaving,
which doubles memory depth only when 2 of the 4 analog channels are used. For
example, Keysight Infiniium oscilloscopes ship with 50 Mpts memory standard
on 4 channels or 100 Mpts standard on 2 channels. Users can enable optional
memory to 400 Mpts on 4 channels and 800 Mpts on 2 channels (Figure 14).
Serial traffic often incorporates periods of dense activity followed by relatively
long periods of dead time. Using the oscilloscope's segmented memory mode
enables you to capture significantly longer periods with the same amount of
memory. Each segment is started when the oscilloscope sees a specified trigger
condition. For example, the trigger might be when a USB device enumerates
a number of packets are sent, each with a SETUP packet. Using segmented
memory, this sequence of events can be captured using 100 times less memory
(Figure 15).
Check to make sure your oscilloscope vendor supports decode in segmented
memory mode.
Figure 14. How much memory does your scope have? In this Figure 15. Infiniium's segmented memory mode supports protocal
example, Infiniium S-Series used 100 Mpts memory sampling at decode. Using segmented memory mode, the required
100 MSa/s to capture over 2 full seconds of USB traffic, including acquisition memory was reduced by 100 times, from 50 Mpts
a USB enumeration sequence in its entirety. to 500 Kpts, to capture 6 seconds of time including the USB
enumeration sequence.
10
6. If using mixed-signal oscilloscope for protocol
analysis, what else should you consider?
Mixed Signal Oscilloscopes (MSOs) are a great choice for protocol analysis for
several reasons. First, they free up analog channels for viewing other system
activity. Second, if you are viewing more than one serial bus, MSOs offer additional
channels, unlike digital storage oscilloscopes with only four channels. Third, some
vendors have more standard MSO acquisition memory than is available on the
analog channels, enabling capture of additional packets when the MSO digital
channels are used rather than the scope's analog channels (Figure 16).
This may be surprising, but many vendors do not support segmented memory
with MSO digital channels. This means that the MSO channels cannot provide
protocol decode when you use segmented memory mode. Be sure to see if your
oscilloscope vendor supports segmented memory on the MSO channels.
Figure 16. Check with your oscilloscope
vendor to see if acquisition memory
is shared between analog and digital
channels or if each has separate
acquisition memory. If separate, see
how much memory, is available for MSO
channels. For example, Keysight Infiniium
MSO digital channels offer separate
acquisition memory, with 128 Mpts of
memory on digital channels versus
20 Mpts standard on analog channels.
Figure 17. MSO channels are a great
choice for protocol triggering and decode,
as shown in this SPI example.
11
Conclusion
Adding protocol analysis capabilities to a oscilloscope enables you to debug a
wider range of issues faster. Evaluating both specific protocol applications and
the scope's underlying ability to effectively perform packet-based triggering and
decode will help you select the scope that best meets your needs.
Keysight encourages oscilloscope users to compare Infiniium protocol trigger
and decode capabilities and performance with any other oscilloscope on the
market.
Only Keysight Infiniium offers the following combination of protocol features: