National Instruments High-Speed Digital ATE and Stimulus Response Features

1. Digital ATE Features

Test engineers can choose from a number of different digital I/O instruments with a range of features for communication and test applications. The core feature of digital test equipment is the ability to perform hardware-timed generation and/or acquisition of a predefined digital test pattern, which is often stored in memory located on the device. Beyond these capabilities of driving a digital pattern of 1s and 0s, digital instruments often support waveforms that can include some or all of the logic states in Table 1.

The six logic states control the voltage driver and, if supported, the compare engine of the digital tester as indicated in Table 1. The states specify what stimulus data the tester drives on a particular channel and the expected response from the DUT. When present in the digital test equipment, these states make it possible to perform bidirectional communication and on-the-fly comparison of acquired response data.

The NI 655x digital waveform generator/analyzer supports all six logic states shown in Table 1. The following sections explain the hardware implementation of these features and provide more detailed analysis of per cycle bidirectional control and real-time hardware compare.

Back to Top

2. Per-Cycle Bidirectional Control

The ability to control the direction of communication is a critical feature when selecting a digital test system for a DUT. The most basic digital I/O instruments have simple unidirectional control, meaning a channel either drives data onto a pin or acquires data. More sophisticated devices can be configured to drive stimulus data onto a pin or acquire data from that pin, but not during the same operation. The two basic logic states, 1 for drive logic high and 0 for drive logic low, can control all the generation operations for these devices. They do not support bidirectional capabilities within the same operation. Typical applications for these devices include basic pattern I/O, handshaking, and digital data logging.

More complex digital testers allow bidirectional capabilities within the same digital operation, meaning the instrument can switch between generating and acquiring data on successive clock cycles. To support this bidirectional control, more than just the two basic logic states are required because a stimulus channel must also be able to disable the voltage driver. This third state is referred to as tristate, which is also commonly referred to as the high-Z or high-impedance state. Tristate provides the ability to control when a device is driving a channel to ensure that multiple devices do not simultaneously drive the channel, which can lead to incorrect data being received. Tristate is necessary for bidirectional applications such as I2C communication, IC testing, bit error rate testing (BERT), and general digital stimulus/response testing.

The NI 655x supports the tristate, also referred to as high-impedance and the “Z” state, on a per channel, per clock cycle basis. Figure 1 shows how a single tristate channel is implemented in the FPGA of the NI 655x digital waveform generator/analyzers. In the figure, the generation logic is illustrated in the top half of the digital tester and the acquisition circuitry is shown in the bottom half.

Figure 1: Block Diagram of a Single NI 655X Digital Channel

A typical test of a bidirectional device, such as a memory chip, begins by loading the stimulus data, or test pattern, into the digital tester’s onboard memory. Next, the stimulus data is decoded to determine if the channel’s voltage driver should be enabled, and if so, what data to drive. In the NI 655x devices, the comparators in the acquisition circuitry are directly connected to the output of the digital tester’s voltage driver. This means that the stimulus data from both the digital tester itself and the DUT can be acquired by the NI 655x. The comparators cannot tell whether the DUT or the digital tester (or both) is driving data onto the channel; you must tristate the digital tester’s voltage driver during a read operation to prevent data from being driven onto the channel from both the DUT and the digital tester’s voltage driver.

Once a signal is acquired, the data interpretation circuitry determines if the acquired signal is a logic low or logic high, and it stores that result in the acquisition onboard memory. The acquired response data is finally written to the PC where it can be analyzed and logged. The next section expands this block diagram further by introducing a feature of the NI 655x device that provides on-the-fly comparison of this acquired response data.

Back to Top

3. Real-Time Hardware Comparison

Another important capability of digital test instruments is the ability to verify that a DUT returns the correct response data under different use cases and stimulus data. To accomplish this goal, there are two primary methods for comparing acquired response data with expected data. The first method is to capture the actual response data and use software to interpret the results. The application program needs only the two basic logic states to configure the tester’s stimulus data. A second method is to preload the hardware with both stimulus and expected response data to make real-time comparisons as data is acquired. Traditionally, this second method was only available on higher-priced digital testers, but powerful, lower-cost FPGA technology is making this functionality more readily available to a broader customer base, enabling real-time hardware comparison through the three compare states shown in Table 1. Whenever a waveform contains a compare state, then the acquired response data is compared to the expected response.

Figure 2 shows the complete block diagram of a NI 655X channel with the hardware compare circuitry as well as the previously discussed per cycle tristate feature.

Figure 2: Block Diagram of NI 655X Digital Channel with Hardware Comparison Circuitry

Data comparison logic in the 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 a FIFO memory, which feeds the expected data to the data comparison logic whenever the acquisition of response data begins. If an error is detected during the comparison, then information on the fault is stored separately from the acquired data so that both can be retrieved by the application software for further analysis.

The FPGA stores the following information for each fault detected:

• Sample number of the fault
• Channel that was at fault
• Total number of errors

Back to Top

4. Common Digital Test Applications

This section explores how to implement the Digital ATE Features described in the previous section in common digital test applications, such as functional tests and characterization.

Functional Tests

One of the most important tests for many industries is the functional testing of components, such as custom ASICs and off-the shelf A/D converters. A common bidirectional device that requires extensive functional testing is a memory chip. Figure 3 illustrates a typical SRAM integrated circuit (IC) with its pinout.

 

Figure 3: SRAM IC Pinout

A typical memory IC, as shown previously, has three address lines, eight data lines, a write enable (WE) line, and a read enable (OE) line. Table 2 shows a marching zeros test pattern that can be used to test this SRAM chip.

When WE (write enable) is high, the IC receives data from an external device, such as a digital tester, and writes the data to the location specified by the address lines. If OE (read enable) is high, the IC retrieves data from the location specified by the address lines and drives that data onto the data lines. The final step in verifying the operation of such a memory device is to analyze the output by comparing it with the expected response.

The next two sections discuss how to implement a functional test using both a software solution and hardware comparison solution in LabVIEW with the NI 655x digital waveform generator/analyzer.

Software Comparison Method

During a software comparison application, the tester generates the stimulus data, captures the actual response data, and then performs analysis of the response data after it is stored in the host PC memory. The actual response data analysis is performed entirely in software and not in real-time. The following steps describe software comparison in more detail.

1. The original test data, as shown in Table 3, is entered by a user or read from a file. The test data contains both stimulus and response data.

2. The pure stimulus data is extracted from the test data as shown in Table 3. 1’s and 0’s in the test data specify stimulus data; all other characters indicate that no data is generated, so the voltage drivers must be disabled by being placed into the tristate.

3. The stimulus data is generated onto the channel by the digital tester, and the response data is acquired. Both the generation and acquisition operations occur in parallel.

4. Once the generation and acquisition is complete, the application program performs the comparison on a per bit basis in software. Table 4 shows an example of the acquired response data. 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.

Software comparison requires that all data be transferred to the host computer for post-processing, making it suitable for slower speed applications. If more data is acquired than can fit on the tester’s onboard memory, then transferring all the data to the host computer may exceed computer bandwidth limitations. For this situation and other cases that require faster comparison rates, real-time hardware comparison must be used.

National Instruments LabVIEW, a graphical programming language, is used below to illustrate the functions needed in a digital software comparison application for the NI 655x device. The next several images illustrate how to create the separate generation and acquisition operations and then how to combine them into a synchronized functional test application.

To begin with, Figure 4 shows how to create the generation portion of the LabVIEW program. They key functions include configuring the tester, loading the test pattern, and starting the generation.

Figure 4. LabVIEW High-Speed Digital Generation Program

Before the test data is loaded into the onboard generation memory, the original digital test data, shown in Figure 5, is parsed into the stimulus data and expected response data. After the data is parsed, the stimulus data is downloaded to the NI 6552 for generation.

Figure 5. LabVIEW Digital Tables

Creating the acquisition section of the program is very similar. Figure 6 shows the acquisition program required for the function test application.

Figure 6. LabVIEW high-speed digital acquisition program

The NI 6552 supports the simultaneous operation of both of these programs; however, simply combining them is not an effective test. Simply running our acquisition program and generation program simultaneously will not result in the acquired data correctly aligning with the expected response data. Since these programs run in nondeterministic software, you cannot rely on the timing of the programs to remain consistent. In addition, propagation delays through the DUT and any cables to the DUT must be taken into account. The time required for the data to move from the digital tester, through the cable and DUT, and back to the tester is known as round trip delay and is shown in Figure 7.

Figure 7. Using External Connections to Account for Round-Trip Delay.

The best way to account for round-trip and software delays is to export a signal with an edge that corresponds to the start of the test. For the NI 655x, the Data Active event provides this functionality and can be routed externally to trigger the start of acquisition, as shown in Figure 8. Notice that you must ensure that the signal is routed such that it has the same round trip delay as the data.

Figure 8. Using the Data Active event to Trigger the Acquisition from Generation

You can also use the Data Active event to control the relative delay between the response data and the active edge of the Sample clock. For example, you can export the Data Active event on PFI 1 and route it to PFI 2, which can be configured as the acquisition Start trigger source, as shown in Figure 8. You can export the generation Sample clock to DDC CLK OUT and set the acquisition Sample clock to STROBE.

Figure 9 shows a LabVIEW program that configures and externally routes the Data Active event and the Sample clock. The functions marked with an arrow perform the additional configuration required.

Figure 9. Using the Data Active event and Exported Sample Clock to Synchronize Generation and Acquisition

The acquisition operation must be started before the generation, as shown in Figure 10, to ensure that the acquisition is armed and ready to receive the Start trigger before generation begins. The final optional step is the analysis of the acquired data, which you can use to make a simple pass/fail decision. Rather than go into the software analysis of the acquired response data in more detail, the following section looks at how to use the real-time hardware compare feature to do this analysis more efficiently then can be done in software.

Figure 10. Ensure the Acquisition Is Ready for a Start Trigger Before the Generation Begins

Real-Time Hardware Comparison Method

Leveraging the onboard FPGA to perform the comparison of the acquired response data to the expected data drastically increases the speed and reliability of a stimulus-response application. To develop a program to compare the response data in hardware, only a few small modifications to the previously described LabVIEW software comparison program are required.

1. Enable the hardware comparison block on the NI 655x using an niHSDIO property node during the configuration stage of both the generation and acquisition sessions, as shown in Figure 11.

Figure 11. Property Nodes Make it Easy to Enable Hardware Comparison

2. Once hardware comparison is enabled, the six logic states in the waveform dictate the NI 655x operation, which eliminates the need for any parsing and analysis functions. Refer to Table 1 for more information about the six logic states.

3. 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 containing an error
• Bits within each sample that were in error
• Expected response from the DUT

Using another property node with the HardwareCompare.SampleErrorBacklog property, you can retrieve the total number of errors directly from the NI 655x FPGA. Figure 12 shows the section of a hardware compare example where the sample error backlog property is used to fetch the acquired response data that contained an error along with the five samples that were acquired before and after the sample in error. By capturing this information, you can perform more detailed fault analysis.

Figure 12. Use the sample error backlog to fetch the data around each error

All the data comparison is performed in hardware on a per-sample basis, which significantly reduces the time spent analyzing the data in software. Using this hardware comparison method, the NI 655x can be easily programmed for high-performance functional tests and other stimulus-response applications.

For this complete hardware compare example, refer to the “High-Speed Digital Real-time Hardware Compare” example located online in the National Instruments Developer Zone (ni.com/zone).

Characterization

The functional test example discussed previously can be expanded to also perform characterization of a DUT. For example, to characterize the maximum clock rate of a DUT, the application must be modified to sweep across a range of Sample clock rates, starting with a low frequency. The characterization test returns a pass/fail decision using the methods discussed for the functional tests; however, if the test passes, the Sample clock rate is increased and the test is rerun. These steps are repeated until the DUT fails. The highest frequency that passes can be interpreted as the DUT’s maximum operating frequency.

To implement this type of characterization, add a loop to the program so that the desired test parameter can be adjusted and then the test repeated. NI-HSDIO does not require each setting of the digital tester to be reconfigured during every loop iteration, so reconfiguration time between tests is minimized. Figure 13 shows an example this code modification.

Figure 13. Characterization Is Performed by Adding a Loop and Modifying a Parameter

See Also:
High-Speed Digital Real-time Hardware Compare

Back to Top

5. Scalability

As digital electronics become more advanced, their components can have anywhere from a few pins for serial devices to well over a hundred pins for complicated ICs. To test these devices, a digital test system must scale its channel count. Using NI-TClk (Trigger Clock) synchronization technology, multiple NI 655x modules can be synchronized easily at the subnanosecond level in a single system to test high-channel count devices. For example, if a system requires 40 channels, the following program illustrates the additional functions required to synchronize multiple devices.

Figure 14. Efficiently Configure Multiple Devices using a For Loop and Array of Instrument Names

Each module must still be configured and controlled by its own set of functions; however, adding a simple For loop drastically reduces the required programming. Figure 14 shows a generation program expanded to multiple modules using a For loop and array of instrument names. Once all the devices are configured inside the loop, only three additional VIs are required for NI-TClk synchronization, shown in Figure 15.

Figure 15. Three NI-TClk functions that enable subnanosecond synchronization

You can also use NI-TClk to write programs where multiple modules respond to external triggers with the same synchronization. For more information about NI-TClk technology, refer to the National Instruments T-Clock Technology for Timing and Synchronization of Modular Instruments white paper by visiting ni.com/info and entering the info code rdtctf.

When synchronizing multiple modules with NI-TClk to perform a hardware comparison, if a fault is detected on one NI 655x device, only that device stores information about the fault. The other NI 655x devices in the system continue as if that sample passed. Since each device only registers its own errors, you need not worry about an error being counted multiple times; however, you may need to post-process information from all the modules to build a comprehensive list if a sampler error rate is desired.

Back to Top

6. Conclusion

With the addition of per cycle bidirectional control and real-time hardware comparison, the NI 655x digital waveform generator/analyzers offer a more comprehensive solution to digital test applications then any other PC-based device. New solutions possible range from the functional testing of memory chips to quick characterization applications to BERT (bit error rate testing). The scalability of the PXI platform and the flexibility of software continue to improve the flexibility and power of digital test instruments.

See Also:
National Instruments T-Clock Technology for Timing and Synchronization

Related Links:

National Instruments High-Speed Digital I/O
NI 655x Digital Stimulus/Response Instruments