There are a variety of good tools on the market for debugging digital designs. Each has advantages and disadvantages that solve specific niche problems. No tool can solve all problems at all speeds and for all protocols. This paper provides a discussion of the relative merits and demerits of high speed digital test approaches and dynamic protocol reconfiguration.
Protocol analyzers: Protocol analyzers are ubiquitous and come in two main categories:
- software based acquisition and
- hardware based acquisition.
A good example of a software based protocol analyzer is WireShark. Because it's free, it's a real bargain. It supports decodes for over 980 protocols. One big limitation to these software based systems is that they are only as good as the acquisition system used to capture the data. Many acquisition systems drop frames, have few ports, or only interface with one protocol at a time (and possibly only one protocol ever). They work by putting the ports in a 'promiscuous mode' that attempts to capture all frames. Because of hardware limitations, frames are often dropped. Partial frames, or corrupted frames are typically filtered out. Users may end up wasting time troubleshooting a system for a dropped frame that wasn't really dropped. Dropped frames might also conceal a problem.
This type of analyzer typically acts as an endpoint or it connects via a monitor port or external TAP. Monitor ports often filter, and drop traffic. Without a TAP, these systems don't act as a 'man-≠in-≠the-middle' to watch a dynamic conversation. Man-≠in≠-the≠-middle systems are able to watch the link as it comes up and down and troubleshoot the auto-negotiation process.
Hardware based protocol analyzers can be sourced from companies such as Network Scout Systems, and Network Instruments. If you spend enough money you can often buy hardware that runs wirespeed without dropping packets. But this isn't available for all technologies.
Disadvantages of hardware based protocol analyzers:
- they typically only support one protocol,
- they have poor physical layer capability (because they were developed for IT guy to use in troubleshooting a network),
- the hardware can be expensive and not very scalable (because it was designed for low-port-count IT purposes),
- they probably don't have real-≠-time triggering and viewing capability (not needed for IT work),
- they may not be able to cross trigger external devices in real time for advanced diagnostics, and
- this approach is inadequate for information assurance and cyber security applications where the ability to see the physical layer bits can be important.
Today's modern high speed real-≠time oscilloscopes are often used to evaluate communications links such as Ethernet or USB. This market is dominated by Tektronix (Danaher), Agilent, and LeCroy. Two of the key uses of a fast oscilloscope are the ability to display eye diagrams and measure jitter. Oscilloscopes can be used to measure and solve many problems (especially at the physical layer).
Limitations to real-≠time oscilloscopes include
- Low channel count.
- Poor protocol awareness (and therefore poor protocol triggering).
- High performance oscilloscopes will also be very high priced. Depending on bandwidth, speed, memory and port count modern oscilloscopes can cost $100,000 to $1,000,000.
- Oscilloscopes are usually standalone instruments. Integrating the oscilloscope into a system requires the use of LabView (or equivalent) or an engineer to write software code.
The logic analyzer market is dominated by Agilent and Tektronix. Logic analyzers can be very helpful ≠- especially if you need to monitor many channels. One of the strengths of a logic analyzer is that it can be used to look at the kernel, IO, and other parts of the board simultaneously. These instruments are versatile and can look at almost any kind of digital signal within the bandwidth and voltage ratings of the instrument.
Logic analyzers run in either timing or state mode. In the timing mode, the system asynchronously oversamples. By doing this a logic analyzer can be used to detect timing related problems. In the state mode, the system samples synchronously at the rate of the system under test.
Disadvantages of the logic analyzer include:
Router and switch testers:
- A one bit A-≠D that cannot do jitter or eye diagrams (hence the need for scopes),
- Poor protocol awareness -≠ they may trigger on a bit pattern but they have limited understanding of the context of the conversation,
- They are most effective on the old parallel bus systems but face challenges on high speed serial interfaces,
- Even the fastest state mode logic analyzers can't keep up with the speeds of modern serial interfaces (sometimes this can be solved with an external serial to parallel convertor),
- These are also stand-≠-alone instruments. Although it's possible to use a logic analyzer with an external traffic generator it often requires the use of two different graphical user interfaces. Often the traffic generator is a very dumb device and blasts bits with minimal understanding of the protocol,
- They can't be used on fiber optic signals unless you have a high speed optical to electrical convertor (O-≠E). You probably won't be able to source an O-≠E that operates at speeds necessary for looking at the newer technologies. If you could source it, it would be cost prohibitive for multiple channels.
This market exploded when Ethernet switches became popular around 1994. Originally developed as switch testers, they became increasingly powerful and gained the capability to test routers and then application layer devices. This market is dominated by Spirent Communications and Ixia. Recently, a new variation of the router tester was developed for cyber security testing (BreakingPoint Technologies and Ixia).
Router and switch testers come in two main flavors:
- The straight FPGA/ASIC traffic generator can generate massive volumes of traffic but lacks a microprocessor for traffic generation. These cards can't service incoming requests and have no contextual sense of the conversation. These cards are strongest for testing routers and switches at layers 2 and 3 where they can generate very high volumes of traffic,
- The second approach is a hybrid card that generates high speed dumb traffic and interlaces it with smart traffic.
Disadvantages to these systems:,
Dynamic protocol reconfiguration:
- Because their main market is switch and router test they have limited protocol support and don't support other standards such as PCIe, SerialRapidIO, Aurora, Thunderbolt etc.
- They don't have the ability to view or alter framing bits,
- They weren't designed for debugging so they have limited triggering and pre-≠-capture filtering,
- Intelligent traffic can't run at full line-≠-rate or fast enough when testing the newer technologies.
This is based on the concept that "There is only one basic protocol -≠ high speed Ssrial". At first this may sound shocking but with modern FPGAs -≠ devices can be reprogrammed as needed to test a large variety of protocols.
So, why buy a tester that is dedicated to a single protocol? Why not get a tester that can rapidly switch between protocols? Advantages include:
- Hardware cost savings,
- Less bench space, and
- A much shorter learning curve to learn a single system instead of several.
Dynamic protocol reconfiguration also allows you to configure port pairs to run different protocols simultaneously. A single chassis that holds up to 32 ports can simultaneously send and receive traffic with up to sixteen protocols simultaneously! Another advantage of dynamic protocol reconfiguration is that all of the test capability is in one chassis. So, picture a single chassis that contains: many protocol analyzers, traffic generators, delay lines, BERT testers, integrated TAPs, and Error Injectors. You don't need to write any scripts to coordinate these devices. In fact, they can all be controlled with one GUI!
Most people don't need to test more than a handful of protocols simultaneously. But having this ability opens a whole new area of test - mixed protocol testing. In the real world systems often have subsystems, each using different protocols. These subsystems need to communicate with each other. Within each subsystem there are often buffers. A few common questions:
- Are these buffers being utilized effectively?
- Do we have enough memory in each buffer?
- Have we put too much memory into the buffer?
- What is the latency as a datagram transits through different subsystems?
- Do the packets arrive in sequence, or do they need to be re-sequenced (which slows the system).
- Are packets lost or corrupted in the process?
- If I prioritize the traffic with QoS does the system behave as desired?
- If I send a command to slow or stop traffic does it behave as desired?
- If I can measure these parameters, I can optimize my systems' performance.
Although some systems can answer these questions at the IO points, for a true analysis it's helpful to get visibility into the chip-≠to-≠chip links and the backplanes. In the real world a million things can go wrong
It's a good idea to try many of these adverse scenarios on your system to uncover latent problems. It's better that you find the problem before the plane crashes. In other words, the earlier you find the problem the less costly the solution. Scopes, logic analyzers, and protocol analyzers typically don't have errored traffic capability. Router testers may have some capability. They can typically send oversize frames, undersize frames, and bad CRC's. But a lot more can and should be done.
Error injectors can test:
- 10n bit errors but with valid CRC's (tests the receiver error handling),
- selected packets dropped out of a conversation,
- selected (and worst-≠-case) bits dynamically corrupted,
- electronically settable and varied cable lengths,
- short or missing preambles,
- corrupted SOF or EOF bits,
- not enough idle bits between frames,
- programmatically dropping link in the middle of a conversation.
One advantage to using error injectors is the ability, to create specific deterministic test cases to test various recovery mechanisms within the system architecture. By injecting a deterministic error into a conversation, at the desired point a specific error recovery mechanism can be exercised, and debugged if necessary. About the author:
Glen Broderick (glen.broderick@AbsoluteAnalysis.com
) is in Technical Marketing at Absolute Analysis
If you found this article to be of interest, visit the Test & Measurement Designline
where you will find links to relevant technical articles, blogs, new products and news.
You can also get a weekly newsletter highlighting the latest developments in this sector - just Click Here
to request this newsletter using the Manage Newsletters tab - if you aren't already a member you'll be asked to register.