Reach the thousands of test professionals we mail to. Sponsor The BestTest Newsletter and we will place your logo here.

How to Select the Right Bus Analyzers and Controllers
By: Alan Lowne, President - Saelig Co. Inc.

How to Select a Bus Analyzer
By: Bill Schuh, Director of Military Electronic Products, Condor Engineering

Considerations in Selecting a Bus Analyzer
By: Nicole Renfro, Marketing Manager at VMETRO, Inc.

 Alan Lowne, President - Saelig Co. Inc.

What are Bus Analyzers and Controllers?

A bus analyzer is a debugging tool, a hardware/software combination used during development of hardware products or device drivers for a specific bus, or for diagnosing bus or product errors. The bus analyzer records the bus signals, decoding and displaying the data. A bus controller is often included, adding the capability to drive the bus with specific, appropriate signals, often simulating a missing device. Bus analyzers are vital diagnostic tools in the design, development, and test of automated systems. Analyzers can be plug-in boards or serial PC-connected modules, or standalone units that capture and/or stimulate bus activity. Features range from transparent logging to full bus control and simulation, and include performance analysis, bus event tracking, anomaly detection, simulated bus activity generation, etc.   Software included with the analyzer allows you to setup test conditions and observe and analyze results.  

Bus activity can be viewed from two different perspectives: hardware and software.  Hardware analysis looks at the I/O activity from the aspect of the physical bus. Hardware analysis can also provide you with the ability to view the actual physical communications that occur on the bus (e.g. handshaking between the host and target). If you want to view detailed timing analysis, such as the time to send the command, data, messaging, etc., then only a hardware analyzer can show you this type of low-level detail.  Software analyzers look at the I/O activity from the operating system's interpretation of those signals.

What are your bus needs?

You probably have a specific problem you’re tackling, so make sure you can analyze the appropriate bus protocol (e.g. serial busses like RS232/422/485; I2C; SPI; CANbus; LINbus or PC system architecture busses like PCI, PMC, cPCI, VME, PC/104, or wireless protocols like Zigbee, WiFi, Bluetooth).  It pays to think toward the future and get an upgradeable product as new protocols emerge.

Decide on a budget and needs/parameters.

Will a simple $100 bus monitor suffice, or do you need to spend $25,000 on a sophisticated standalone box for production verification?   Do you just need to see bus signals – in which case maybe a scope or PC scope adapter will do (e.g. www.picotech.com, www.cleverscope.com, etc.) This may help you debug issues like timing problems, slow rise-times or excess bus capacitance, interference spikes, etc. Engineers troubleshooting ever-faster serial buses encounter digital problems caused by the actual quality of the data signal. Ideal digital pulses have fast, clean transitions. At higher operating speeds, cable terminations and reflections make it increasingly difficult to maintain ideal signal characteristics.  Useful Scope/Logic Analyzer combinations can be found at http://www.cleverscope.com and www. http://www.usbee.com/

Interpreting what the bus signals mean takes some software, so you can spend as little as $100 for a simple “dongle” or as much as $25,000 on a sophisticated standalone bus analyzer.

Using webs resources - how to search without getting garbage links.

Everyone uses Google, but the results often contain too many spurious links to be of much help. Add search words specific to your needs to cut down on specious links.  Of course, you’ll be using http://www.besttest.com/ for a search, but this only works for manufacturers who’ve discovered BestTest and submitted their information. Or go straight to the listing of Test Products and Services at http://besttest.com/BestTestDirectory/ProductDirectory/

Surprisingly, if you go to a technical information site like www.eg3.com and search on “bus analyzers” you get lots of references to just one vendor – not helpful. Eg3 does, however, have great links to most tech magazines for further research.  
Much better resources are: http://www.electronicproducts.com/   www.eepn.com   http://www.globalspec.com/   http://www.embedded.com  http://www.electronicdesign.com/ www.eem.com  since that’s where most manufacturers will send their product press releases.

I like Amazon’s search site www.a9.com because it gives links plus a Wikipedia definition of your search term (if applicable). 

IDE/ATA Serial ATA ATAPI SCSI iSCSI Serial Attached SCSI Fibre Channel RAID USB 1.0 or 2.0 1394 / Firewire Multipath I/O (MPIO) and more! www.bustrace.com

Conclusion

The above comments should help you find useful bus products more speedily.  So don’t get offended if your boss tells you that you need more analysis!

 Bill Schuh, Director of Military Electronic Products, Condor Engineering

The wide range of protocols in use today in various bus systems for military, avionics and other commercial applications has brought about highly-efficient information exchange that is both swift and accurate. This, in turn, has accelerated the demand for a continuing evolution in bus analyzers. What follows are some essential requirements that you will want to examine in selecting a suitable bus analyzer.

• PC-Based Analyzers versus Box-Based Analyzers — A distinct benefit of a PC-Based Analyzer, that includes the graphical user interface (GUI) and an interface card, over the Box-Based Analyzer, that may be anything from a handheld to rack-mount device, is this: Not only will it perform protocol checking but it also provides a very simple and easy way of setting up terminals because of the GUI software that supports it. Also, the ease with which you can set up data streams and data buffers enable the importation of information into spreadsheets such as Excel for spreadsheet and database manipulation. Another plus for the PC-based approach is that the companion software-based bus tools that are part of such analyzers brings with it the ability to interpret data, including the ability to perform engineering-unit conversion. This would be very difficult to set up in a Box-Based Analyzer.
• Clear, User-Friendly Human Interface — Anyone who uses a bus analyzer will expect it to be endowed with a very clear icon-based human interface —  such as buttons and symbols — or tree-based presentations of the bus components, as can be seen in Condor Engineering's BusTools/1553 and BusTools/AFDX (www.condoreng.com). A tree-based presentation is going to have the bus components and their sub-features broken out, thereby providing the user with a very clear representation of what he or she wants to do. Furthermore, a bus analyzer should provide a detailed presentation of bus activity while the analyzer is running. Included, as a bare minimum, are just which components on the bus are seen, as well as protocol errors and data errors that are occurring.
• Fulfills Three Distinct Functions — The activities of a full-featured bus analyzer can be divided into three categories: Logic-analyzer type functions, such as the ability to trigger, enabling the user to set up separate files, based upon certain activity patterns or events that occur on the bus. A logic analyzer also filters, which means it can be programmed to discard words or messages that are totally unrelated to bus analysis. There is also the protocol-analyzer capability. Whereas the third activity can be thought of system-level troubleshooting, which is based upon interpretation and therefore has the ability to evaluate the system data and set upper and lower boundaries. System-level troubleshooting denotes that data that is being transferred. For instance, a user may set up lower and upper limits, say a lower limit of less than 45 units and an upper value limit greater than 500 so that an alarm will be sent whenever the value breaks these boundaries. 
• Archiving Traffic — Another important feature in a bus analyzer is the capability of archiving traffic off the bus, which means the user can play back a particular activity. The reason this is such an invaluable feature is that the user can recreate a problem that has been observed by re-running it repeatedly and then can appraise just how the data is performing. A related feature, which can be found on some bus analyzers, is the ability to play back to the interface bus, the screen or to both.
• Different Vantage Points — When examining protocol and system-level analysis it is important to be able to view activity from different vantage points. PC-based bus analyzer tools provide you with many different ways to look at your protocol and your system level analysis. For instance, we can use a 'data watch' feature that allows one to actually graph the data as it occurs.  Multiple comparative windows enable analysis of bus activity at different points within the bus traffic, allowing comparison of messages and/or the data. For instance, with some analyzers, such as Condor Engineering BusTools, you can request a sequential view, which displays the data that occurs contiguously within an inverted stack. It displays the first message recorded, followed by a sequence of other messages, which followed the first message. This is sometimes called a 'sequential view' or a 'stacked view'.
• Simulation Ability — Another important requirement to consider in choosing a bus analyzer is the ability to simulate the terminals related to your data bus traffic. For instance, in MIL-STD-1553 you would want the analyzer to simulate the bus controller or a remote terminal. This means loading up the bus analyzer with data and errors that can then be used to stimulate other components on the bus to learn just how they will react.

Nicole Renfro, Marketing Manager at VMETRO, Inc.

A Bus Analyzer is a pre-configured logic analyzer conforming to the logical, electrical and mechanical specifications of the target bus. These analysis tools are hard-wired to capture the protocol of the target bus and offer formatted trigger setups and trace displays. Typically a bus analyzer is a single board unit; thus making it portable and ready-to-run. Bus Analyzers are available for many standardized form factors including VME, PCI, PCI-X, PMC and CompactPCI. When selecting a bus analyzer, engineers often consider several factors.  

How do you control the analyzer? Analyzer host connection methods vary greatly from Ethernet to USB to RS-232. Interfacing to the analyzer over Ethernet allows an engineer to connect to the analyzer from anywhere, either locally or remotely. Thus, an engineer no longer has to be located in the lab next to the equipment to debug. A remote connection such as Ethernet also allows an engineering team to troubleshoot issues for customers without going into the field which saves time and money. An Ethernet connection can be established over DHCP, fixed IP or VPN connections. Ethernet connection also allows sharing of a bus analyzer between multiple engineers on a team.

Is the trace buffer of sufficient size to capture the events of interest? The trace buffer should be large enough to capture all transactions required in diagnosing non-routine software problems. In addition to the buffer size, the analyzer should be able to easily filter trace data and acquire only data of interest to the engineer. If the analyzer demultiplexes 64-bit Address, Data, Attribute (PCI-X only), RMW (VME protocol), Command and Byte Enables (PCI/PCI-X protocols) valuable trace buffer space can be conserved without setting pre-acquisition filters. Some analyzers allow an engineer to filter out cycles that are not of interest by changing the sampling options. For example, retry cycles could be excluded when a device retries 8 times before the transaction occurs.

Some analyzers offer multiple trace views to provide higher level views of trace data. Using one of these analyzers would allow a software engineer working in PCI or PCI-X protocol to view the transaction at a transaction level and then the engineer can expand the transaction to see the actual data being transferred. This same engineer is saving buffer space by not filling the trace buffer with the details of the transactions (i.e. when FRAME#, IRDY# and TRDY# assert). However, a hardware engineer trying to debug an issue may need to see the transaction details. VMETRO’s Vanguard family of Bus Analyzers (www.vmetro.com/bus_analyzers) enables each engineer to use the sampling mode most appropriate for the application.

How easy to use is the analyzer? Download demonstration software and begin getting familiar with the tool. The GUI software should be easy to use and have all functions easily accessible. Try to set up triggers and review sample trace data. Some bus analyzer vendors incorporate extensive mnemonics for common signals. Some analyzers also allow the user to set user defined mnemonics. For example, an engineer can name each device that is being worked with. If the analyzer is very powerful, it is beneficial to request a demonstration from the sales contact to get up and running as quickly as possible. Evaluate the product and the vendor’s support system. The documentation should thoroughly explain each function in the analyzer. Determine if there is additional information available to help familiarize new users with the tool. Ask questions and provide feedback on how the tool works for you during the evaluation.

What other functionality is available in the analyzer? When making the investment in a test tool, it is important to review all functionality available in the product, since the next project the engineer works on may require additional functionality or another engineer on the same project may need additional functionality. Typical additional functionality available in bus analyzer tools includes API software interfaces, statistics (Performance benchmarking tools), protocol checking, exercisers and compliance testers. Sometimes additional hardware or software is needed to perform all functions at one time.

Does the analyzer function independently and concurrently with the statistics, exerciser and protocol checker capabilities? To debug real world problems, an engineer will want to run the analyzer at the same time as the other functions. For example, to debug a software issue, an engineer may need to run the analyzer triggering on the failure condition, monitor statistics to see the performance of the system, check for violations to the specification and generate bus transactions with the exerciser. Some analyzers limit what functions can be performed at the same time, so engineers have to work harder to achieve the same information. VMETRO’s Vanguard Analyzers (www.vmetro.com/bus_analyzers) enable each function to operate independently and concurrently to save engineering hours in the debug process.

In Conclusion: Bus Analyzers are designed to reduce the need for detailed user knowledge of the bus protocol. Choosing an analyzer which provides ease of use and decoding in the trace data will save engineering hours as well as reduce the time required to debug complex problems. Utilizing an Ethernet port allows engineers to remotely debug problems in the field as well as work outside the laboratory. In solving design problems, engineers often need more than just a passive analysis tool.

• If your friend forwarded this newsletter to you, please register as a member and receive The BestTest Newsletter -- absolutely free!
• If you wish to update your news preferences or cancel the subscription, please unsubscribe.
• If you have any questions, please email experts@BestTest.com

Get the widest selection of test related books and software at the BestTest Online Store.