Using the onboard FPGA to compare the acquired response data to the expected data has the following benefits:
  • Increases speed.
  • Reduces the post-processing data analysis of stimulus-response applications.

To develop a program to compare the response data in hardware, complete the following steps:

  1. The original test data is entered by a user or read from a file. The test data may contain both stimulus and response data.
    Note Use the Waveform Data Type (WDT) instance of the niHSDIO Write Named Waveform VI to write expected data to the device. The device drives any values of 0, 1, or Z in the waveform, while values of H, L, or X are treated as expected data values.
  2. Stimulus data is extracted from the test data. 1s and 0s in the test data specify stimulus data; all other characters indicate that no data is generated, so the voltage drivers are disabled.
  3. Use the Supported Data States property or the NIHSDIO_ATTR_SUPPORTED_DATA_STATES attribute to enable the hardware comparison block on the device during the configuration stage of both the generation and acquisition sessions. When hardware comparison is enabled, a six-state digital waveform controls acquisition, generation, and comparison, removing the need for parsing or software analysis.
  4. Configure a start trigger for your device. Valid start trigger source and destination terminals include PFI <0..3>.
    Note RTSI and PXI trigger lines are not recommended for triggering hardware comparison operations because RTSI and PXI trigger lines are not synchronous to the data.
  5. The stimulus data is generated onto the channel by the digital tester, and the response data is acquired. The generation and acquisition operations occur in parallel, so eliminating the round-trip delay can be important.
  6. Once the generation and acquisition are complete, the application program performs the comparison on a per bit basis in software. The final pass/fail decision is only effected by the response data that was acquired when an H or L was present in the original test data.
  7. For applications requiring more complex fault analysis, a fetch function can acquire the faulty data and any samples surrounding that error. For every sample that is in error, you can retrieve the following information:
    • 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 are enabled)

Use the Sample Error Backlog property or the NIHSDIO_ATTR_HWC_SAMPLE_ERROR_BACKLOG attribute to query how many errors can be returned using the niHSDIO HWC Fetch Sample Errors (U32) VI or the niHSDIO_HWC_FetchSampleErrors function. Use the Number Of Sample Errors property or NIHSDIO_ATTR_HWC_NUM_SAMPLE_ERRORS attribute, along with the Samples Compared property or the NIHSDIO_ATTR_HWC_SAMPLES_COMPARED attribute, to calculate the sample error rate. By capturing this information, you can perform more detailed fault analysis.

The hardware performs all the data comparison on a per sample basis, which significantly reduces the time spent analyzing the data in software. Using this hardware comparison method, you can program the device for high-performance functional tests and other stimulus-response applications.
Note Using hardware compare with script wait statements results in inaccurate data.

For a complete hardware compare example, refer to the Hardware Compare - Fetch Error Records example included with NI-HSDIO.