Electronic Design

Single Instrument Analyzes Protocols And Logic

By combining intelligence and an easy-to-learn user interface, the Bus Doctor simplifies system diagnostics.

System designers today must deal with complex buses and equally complex bus-signaling protocols. This often requires using separate instruments, each optimized for either logic analysis or protocol analysis. But advances in bus operating speeds and changes in protocols frequently cut the instrument's life short. The ideal solution would combine the ability to handle both logic and protocols, while also allowing easy upgrades to support higher speeds and multiple protocols.

Designers at Data Transit have crafted exactly this combination. Known as the Bus Doctor, it performs both logic and protocol analysis. To do this, the instrument leverages programmable logic and software-based control to allow instant reconfiguration and feature upgrades. Moreover, it accomplishes this in a compact, transportable LCD-based package measuring just 13 by 12 by 2.4 in. Plus, such flexibility comes without a performance penalty—the Bus Doctor delivers top-of-the-line capabilities when performing logic analysis, and it handles just about any protocol.

Software developers can take advantage of the easy setup and bus-specific menus for triggering and filtering, as well as a statistical analysis capability. This combination of features simplifies protocol analysis. It also enables hardware developers to make the most of the logic-analysis features, evaluate the timing resolution, set up almost infinite triggering combinations, and adapt to both today's and tomorrow's buses.

The first software release for the Bus Doctor will include configuration files that let the analyzer handle USB 2.0, ATA-100, ATAPI, PCI-X, 1394, Cardbus, Fibre Channel, Gigabit Ethernet, and InifiniBand interfaces. By the end of the summer, the company expects to have Serial ATA, Bluetooth, SCSI 320, and Compact Flash configuration setups. Additional bus interfaces are planned. Custom interfaces can be created, too. Similarly, the Smart Pod created for each bus can be configured by the analyzer to handle variations to the bus. The Bus Doctor also can be updated to support new buses by simply downloading a new configuration file from the host instrument.

Hardware for the Bus Doctor consists of three basic sections: a 633-MHz Intel Celeron-based embedded host computer that runs the Windows 2000 operating system, a PCI card that performs the main analyzer functions, and the configurable Smart Pod (Fig. 1). The heart of the analyzer is a PCI card containing a large SRAM-based FPGA and a high-performance DMA controller. Also included is an SDRAM controller, which keeps tabs on a 144/288-bit wide by 256-Mword deep buffer memory. That combination allows on-the-fly reconfiguration while providing control for the high-bandwidth data transfers needed to view and store large amounts of captured data.

There also are general-purpose logic pods available to turn the Bus Doctor into an ultra-deep logic analyzer. Logic pods support 18 signals each for a total of 108 channels when using all six input cables for logic analysis.

Captured data can stream across the internal PCI bus at over 40 Mbytes/s. This lets users view data without any pauses or delays while providing access to a 4.5-Gbyte (maximum) data buffer. Large traces that must be stored on the system's internal hard drive are only limited by the bandwidth of the ATA bus (40 Mbytes/s sustained) and the size of the drive.

The FPGA-based analyzer card can operate at a 250-MHz sample rate. This translates into trace captures that can be done in as little as 4 ns per 144-bit event. The ability to configure the functionality on-the-fly allows for streamlining and minimizing of the hardware, thereby permitting the circuitry on the FPGA to op-erate at top speed. Because the logic functions can be directly implemented in the FPGA, processor-readable/writable registers aren't needed. This saves space because such registers take up valuable space and complicate the floorplanning with-in the FPGA.

The direct implementation of the logic takes advantage of the fast interconnects between the configurable logic blocks within the FPGA. Additionally, by eliminating all registers, the instrument's designers had room to implement features that otherwise wouldn't fit into the most cost-effective FPGAs available today. So, the Bus Doctor includes very powerful triggering capabilities, plus the ability to collect and display real-time statistics and filter the data during capture.

The trigger sequence is by far the most complex part of the analyzer and possibly the most complex trigger sequencer in any commercial system. It consists of a 12-level trigger sequencer that can be in any level or all levels simultaneously. Two levels are counters, and two are timers. This provides the extra benefit of adding a time element, or a count, to any sequence of events that the user may wish to trigger on.

Users can configure the trigger in all 12 levels at the same time, with each level waiting for an event on which to trigger. The ability to be in multiple levels at once means that the trigger sequencer can exclude or include specific data sequences. The counter levels also include a NOT term, allowing users to create complex sequences like: Wait for A and NOT B to occur X times, then trigger or enable another level. Such a condition lets the user count a data pattern that's NOT some value.

For example, the A portion of the term may define the Data phase or a data transfer, while the NOT B term could be some data pattern such as 0xA5A5A5A5. As long as the data wasn't 0xA5A5A5A5, the counter would increment until reaching the desired count, causing the analyzer to trigger. This count could be 1, which means the analyzer could recognize an incorrect data pattern. Imagine a read/write compare test that's run where all data is 0xA5A5A5A5. Here, the analyzer could be configured to trigger any time the data was incorrect.

Also, the trigger sequencer can force the capture on or off while in any level, which permits filtering by a sequence of events. Each level can use the filter while in that level, letting the user simultaneously filter at a high level and at a lower level. For instance, if the user wants to view the first eight data transfers on an SCSI bus, but only if the SCSI ID=4, then the filter can be configured to pause capture after eight data transfers and continue on any nondata pattern. The trigger sequencer could be configured so that one level waits for a selection of SCSI ID=4. That level would enable the capture, but the filter would continue filtering any data beyond eight. Other levels in the trigger sequencer could be configured to force capture off while in those levels. The counter level could be used to specify the NOT term as well or force capture off after a count of 1 and NOT SCSI ID=4.

Another novel feature of the Bus Doctor is its ability to collect real-time statistics. Like any other function, the terms or patterns that drive the real-time statistics can be specified via an easy-to-use software interface tailored for the bus under test. Not stored in the buffer, this data can be viewed at any time. The analyzer doesn't even have to be running for users to view the real-time statistics, including total number of events, events/s, or events/other unit of measurement.

The analyzer comes in a 36-channel implementation. Multiple PCI analyzer cards can be plugged into the host system. But for higher channel requirements, a 108-channel card also is available. The analyzer's input channels employ low-voltage differential signaling to minimize noise and ensure signal integrity.

Configurable Pods
The Smart Pod contains another FPGA that's configured via a file downloaded by the Bus Doctor. The file configures logic in the bus-specific pod to the bus interface. For high-speed serial buses, the configuration might also include link-level hardware and the other signals needed to deserialize the data. In some ways, the Smart Pod acts a lot like an oscilloscope probe. It presents a low-capacitance but high-impedance interface to the bus under test. In addition to the bus data, the pod provides signals telling the analyzer what type of pod it is, and if the cables are connected properly.

When the LVDS data enters the analyzer, it first encounters a 36-term pattern-recognition array. These terms are used to drive the real-time filter, the 12-by 12-level trigger sequencer, the six real-time statistic counters, and the capture engine that determines which data samples are stored in the buffer memory. Support for 36 terms by 108 channels is another benefit to partial reconfiguration of the FPGA. As the user defines the patterns in software, the hardware for recognizing those patterns is generated in its simplest form and downloaded into the FPGA on-the-fly.

To accomplish this, the software looks at each input channel and determines the desired logic level. This can be a high, low, falling edge, rising edge, either edge, or don't care. Once this is known, the bit file that's downloaded into the FPGA is modified so the pattern-recognition hardware only gets tailored to what's needed. All input channels can recognize all signal sequences (Hi, Low, Rise, Fall, X), allowing the use of any input channel as a clock that can trigger on a falling edge, rising edge, or either edge. The ability to trigger on either edge of a signal is useful whenever using double-transition data transfers, now common in many bus protocols.

Then, the 36 terms or patterns are fed into specific hardware functions that permit the analyzer to trigger, filter, and provide real-time statistics. The input channel data is passed through a FIFO buffer to the SDRAM controller. At that point, it may or may not be stored in the trace memory. The State Recognition terms and the filter terms ultimately control what goes into the SDRAM. Data can be streamed into the trace memory at the full 250-MHz bus clock, so the analyzer can achieve an aggregate data-transfer rate of 4.5 Gbytes/s.

Due to the large amount of data that the analyzer can capture, users can split the buffer into as many as 256 independent segments. This allows for storage of up to 256 traces in memory without saving the data to the hard drive. The buffer can be configured to automatically increment the segment and start running again when the post-trigger counter expires. The user can then set up the system and step away from the analyzer for long periods of time while the instrument collects the data.

Such a capability has great use for identifying multiple anomalies that happen on the bus. Because the trigger sequencer can be configured to trigger on any of several patterns, this becomes a powerful tool for isolating complex problems. But the large amount of data that the system captures requires it to provide a hardware-assisted find capability. The find feature works in both the forward and reverse directions and can speed up many post-capture processes that would otherwise take much time to perform.

The State Capture hardware determines what data gets stored into the trace memory. By turning on and off the state bits, the user can easily eliminate unwanted data from being stored into the trace memory. This isn't the same as filtering, although the final outcome can be the same in some cases. In other words, more than one method exists for filtering the data. The disadvantage to filtering this way is that the filtering is achieved by not storing certain states. On the other hand, filtering with the filter lets the user store all states, but specify (using the filter terms) when the analyzer should pause and continue capture.

Powerful Software, Simple Interface
The software that runs the Bus Doctor is highly modular and provides an easy-to-use user interface that allows the designers to configure the instrument and view captured data (Fig. 2). When the software first boots, it checks to see if an analyzer card is present. If not, the software puts the Bus Doctor into a demo mode, permitting the user to view and configure the instrument, but it grays-out the Run button. If an analyzer is found, the software will attempt to locate the Pod and read the Pod ID. If a proper Pod ID is found, the software will download the appropriate bit file into the Pod's FPGA. If no pod is found, the analyzer also will go into a demo mode.

Once the pod is programmed, the software opens the appropriate configuration file specific to the attached pod. This file is then passed into the bit-file configurator, which parses the configuration file and modifies the FPGA bit file as required. The bit file is next downloaded to the analyzer card's FPGA. Transparent to the user, all of these operations take place in the background. At this point, the analyzer looks and behaves like a protocol analyzer for the bus defined by the pod. The main application portion of the software can deliver bus-specific menus that are intuitive for the bus or protocol used.

The basic configuration menu is a simple dialog box with four tabs, each representing a main function of the analyzer. Buffer size and segmentation, trigger, filter, and state capture make up the four main areas of configuration. Each tabbed page presents the user with a high-level easy-to-use menu that will configure the analyzer with a click of the mouse. So even beginners, unfamiliar with the bus protocol, can easily configure the analyzer to trigger and filter on complex command or data sequences.

In an actual bus analysis example, the Bus Doctor might capture the command sequence in one window, the state listing in another, and the bus timing in a third (Fig. 3). Plus, the system can provide a histogram of command execution and errors, giving designers a running view of the system performance.

In the design of the Bus Doctor, Data Transit designers combined their efforts with that of Brian Von Herzen, an FPGA design consultant who helped to develop the on-the-fly reconfiguration capability (www.fpga.com). Data Transit also acknowledges the work of several key designers: David Keenan contributed the 250-MHz SDRAM controller with hardware search capabilities, Eric Lanning developed the GUI and bitfile reconfiguration software, and the project leader, Travis Ferguson, was the architect behind the hardware.

Price & Availability
The Bus Doctor is available in several versions, costing from about $8000 for a unit without the LCD to around $23,000 for a version with a high-brightness LCD, a 30-Gbyte hard drive, 4.5 Gbytes of RAM, and the 108-channel PCI analyzer card. The Smart Pods range in price from about $1000 to about $3500 depending on the interface complexity.

Data Transit Corp., 1721 Little Orchard St., Suite Q, San Jose, CA 95125; Dale Smith, (408) 279-1555; www.data-transit.com.

TAGS: Intel
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.