The steps for this article are split into the following sections:
- Overview of Scan Pattern Compression
- Usage of the Scan Opcode in a Pattern
- Achievable Memory Compression in the PXIe-6570 and PXIe-6571
In semiconductor test, a 'scan' operation is a 'Design-for-Test' strategy to stimulate the internal logic of a device under test (DUT) without the need to functionally configure or operate the device. To achieve this, the DUT can be designed with a special 'scan mode' that combines all its internal logic into a series of shift registers terminated by specific IO pins (the SCAN_IN and SCAN_OUT pins). The 'scan' test is performed by shifting a serial bitstream representing 'current state' logic into the SCAN_IN pin, clocking the internal logic once to obtain its 'next state' logic, and then shifting that logic as a serial bitstream out of the SCAN_OUT pin.
Note: 'Scan' is a term that is used in other places as well to refer to different operations. This type of 'scan' testing is not the same as 'boundary scan' (JTAG), the CompactRIO 'NI Scan Engine', or the NI-Switch 'Scan List' functionality
From the point of view of the NI-Digital Pattern Instrument, this serial bitstream is no different from any other serial bitstream and can be performed in a normal 'flat' pattern without any special functionality. However, serial bitstreams for scan operations can be very long and consume tens of millions of vectors worth of vector memory space. To reduce the memory usage during a 'scan' operation, a special pattern opcode was added into the NI-Digital pattern format that reduces vector memory usage of pins being used for SCAN_IN and SCAN_OUT IO and frees up vector memory space that would be used for the non-scan IO (which do not change state during a serial scan shift).
To use the 'scan' opcode in a pattern, you must first designate at least one pattern pin as either 'scan_in' (driving a serial bitstream into the DUT's SCAN_IN IO) or 'scan_out' (reading a serial bitstream from the DUT's SCAN_OUT IO). This can be done by right-clicking the pin item in the pattern and selecting 'Change Pin Type':

Alternately, if creating a pattern in the .digipatsrc format, you can designate pins as scan_in or scan_out in the format header:

The syntax of the opcode itself is 'scan(X)', where 'X' is the number of cycles in the serial bitstream. In the Digital Pattern Editor, the scan cycles will be collapsed but can be expanded by clicking on the expansion arrow beside the vector number:

In the above image, you can see that the pin data for the non-scan pins is grayed out, indicating that during the 'scan' operation these pins do not change state but will otherwise behave according to the configured timing for those pins.
In the .digipatsrc format, the scan opcode and pin data is listed differently than other pattern pin data for readability and file size purposes. This is because scan operations can potentially be very long:

The following restrictions apply when using the 'scan' opcode in a pattern:
- If a pin is defined as scan_in, only the following pin states can be used alongside the scan opcode: '0', '1'
- If a pin is defined as scan_out, only the following pin states can be used alongside the scan opcode: 'L', 'H', 'X'
- You cannot use any other opcodes in combination with a scan opcode. This includes source, capture, repeat, etc.
The advantage of using a 'scan' opcode when loading or unloading a serial scan bitstream is a reduction in vector memory usage for that operation. This is accomplished through compressing the pin data for scan_in and scan_out pins and repurposing the vector memory space for the non-scan pins which do not change state during scan operations. As such, the amount of memory compression directly depends on how many of a card's 32 pattern pins are being used as scan_in or scan_out.
Each card can support memory compression on up to 16 scan_in and 16 scan_out pins, due to the way the pattern compiler interleaves pin data in vector memory. More than 16 pattern pins on a card can be defined as scan_in or scan_out, but this will prevent the pattern compiler from being able to perform memory compression. The level of compression that the compiler can achieve depends on the higher number of defined scan_in or scan_out pins on a single card according to the following table:
Greater of # of scan_in or # of scan_out | Achievable Memory Compression |
1 | 42x |
2-3 | 21x |
4-7 | 10x |
8-11 | 5x |
12-15 | 3x |
16 | 2x |
17-32 | 1x (no compression) |
This compression only applies to vectors with the 'scan' opcode. All other vectors will be loaded into vector memory normally; therefore, this is not representative of the memory usage of the entire pattern set. However, with the proper pin distribution the scan opcode can significantly optimize memory usage of serial scan bitstreams.