Advanced Features of High-Speed Digital I/O devices: Hardware Compare


This paper belongs to the Advanced Features in High-Speed Digital I/O Devices: White Paper Series

Download a PDF of the entire Advanced Features of High-Speed Digital I/O Devices White Paper Series

This paper describes how to use Hardware compare on the NI-HSDIO devices. The hardware compare feature allows users to perform digital comparisons of data on device itself. This allows for real time hardware comparison, which is not possible if data is transferred back to the host computer. This allows for tests such as Bit Error Rate Testing (BERT) and digital waveform comparisons.

Table of Contents

  1. Introduction
  2. Digital ATE Logic States
  3. Implementing real time hardware compare
  4. Verifying Response Data
  5. Hardware Compare in LabVIEW
  6. Conclusion
  7. Additional Resources


Hardware comparison is used to verify that a unit under test (UUT) returns the correct response data under different use cases and stimulus data.  There are two primary methods for comparing acquired response data with expected data (1) software processing and (2) real-time or hardware comparison. With the first method, the device captures the actual response data into PC memory and uses software to post-process the results. The software uses only the two basic logic states, 0 and 1, to configure the tester’s stimulus data.  With the second method, you can pre load the device with both stimulus and expected response data and make real-time comparisons as data is acquired. Whenever a waveform contains a comparison logic state (H or L), then the acquired response data is compared to the expected response. You can choose whether this real-time hardware comparison operation drives and compares data (Stimulus and Expected Response mode) or whether it only acquires and compares (Expected Response Only mode).

Data comparison logic in the onboard FPGA connects the generation and acquisition circuitry. The data decoder receives data from onboard memory and enables/disables the driver based on the logic state of each sample. The decoder transfers the expected response to the acquisition engine. A FIFO allows the alignment of the actual response with the expected response. If an error is detected during the comparison, then information on the fault is stored separately from the acquired data so the application software can retrieve both types of information for further analysis.

The device stores the following information for each fault detected:

  • Sample number of the fault
  • Channel(s) at fault
  • Total number of repeated errors (useful if the Filter Repeated Sample Errors property or the NIHSDIO_ATTR_HWC_FILTER_REPEATED_SAMPLE_ERRORS attribute is enabled)


Back to top

Digital ATE Logic States

These logic states are supported in the LabVIEW digital graph and the digital waveform editor as well. With hardware compare, the user defines/loads expected values prior to running.  The permissible values are H (Compare response data to logic high), L (Compare response data to logic low) and X (Ignore the DUT output).  The acquired bits are compared against expected values in memory.  The errors show up in software API immediately.

Logic States



Drive States

0 Drive logic low to DUT
1 Drive logic high to DUT
Z Tristate (high impedance)


Compare States

L Compare logic low from DUT
H Compare logic high from DUT
X Ignore the DUT output

Table 1: Logic States and Their Operations

Back to top

Implementing real time hardware compare

Digital instruments such as the NI 6551/2, NI 6555/6 and the NI 6547/8 can perform real-time hardware comparisons using onboard FPGAs.

Figure 1: Channel Circuity on the 6551. This diagram shows how the NI 6551 implements Hardware Compare.

To perform a comparison in hardware between the expected data and the actual response data, the generation and acquisition sessions have to be linked together as shown in Figure 1.  With this feature, you can perform real time bit-error identification of response data.  You can compare the value of the expected data with the actual data.  Most applications require the flexibility of being able to perform a comparison on any of the channels of the digital instrument.  The NI stimulus/response instruments provide input/output/tri-state/open-drain control on a per channel basis, allowing you to control the direction or state of every channel independent of the other.  Buses such as I2C also require these channels to be able to change state on a per cycle / per sample basis, which is also supported by the NI stimulus/response instruments.

The NI 6547/8 devices can perform per pin, per cycle tristate similarly to the NI 655x devices but first must set the Supported Data States property to O, 1, Z (tristate) or the NIHSDIO_ATTR_SUPPORTED_DATA_STATES attribute to NIHSDIO_VAL_STATES_0_1_Z before writing or allocating any waveforms. This value puts the device in extended data mode, which supports the high-impedance (Z) state. Extended data mode reduces the number of channels available for dynamic generation with tristate to 24 with the NI 6547/8.  The top eight channels are still available though for acquisition or static generation. 

You can use LabVIEW SignalExpress to perform a graphical hardware comparison where if the expected data is not returned, it is highlighted in red.

Figure 2 - The Digital Waveform Editor can be used to implement hardware compare.  All the logic states mentioned above can also be implemented in the Digital Waveform Editor.


Back to top

Verifying Response Data

A typical memory chip has some input lines for the memory address, a few control lines, and then several bidirectional data lines.  These data lines are used to store (write) data into the memory device and are also used to retrieve (read) data from the memory chip.   Let’s look at how we can communicate with one of these data lines using the new features of the NI 6551/2, 6555/6 and 6547/8.  The stimulus data will be the digital waveform we write to the board that is generated from memory and the response data is any data we acquire from the memory chip during our test.


Figure 3 - The response of Hardware Compare shows the locations at which the received data did not match with the expected data.

Back to top

Hardware Compare in LabVIEW

Figure 4 - Programming Hardware Compare in LabVIEW.  This figure shows how to implement Hardware Compare in LabVIEW.  The Generation Session fills up the FIFO with data which will be used for the comparison.  The acquisition session grabs the DUT data and compares it with the data that is in the FIFO.

Note: the example above is the Stimulus Response Load from HWS that you may find in the NI-HSDIO Examples that come with the driver. Use Example Finder in your version of LabVIEW to check out other Hardware Compare examples to begin your development.

To programmatically activate hardware comparison, you can use the SupportedDataStates property node, which is shown in the figure below.  This property configures the device to compare expected data in real-time. To use this property node you must have an acquisition session and a generation session running concurrently. When you set this property to either 0, 1, Z, L, H, X (stim/resp) or L, H, X (resp only), the generation engine sends expected data to the acquisition session to compare against the acquired data.

Figure 5 - In LabVIEW the SupportedDataStates property node can be used to select between different modes of Hardware Compare.

Back to top


Hardware Compare provides users with the ability to perform digital waveform comparisons on hardware. Many digital circuits and chips require real time comparisons to be able to perform bit error tests and various other tests. To perform these comparisons in software would be very slow and not beneficial to the overall application.  For such applications, the hardware compare feature of the NI 6551/2, 6555/6, and 6547/8 boards is useful.

Back to top