The vector statement specifies the label for the vector, the opcodes to execute, the data to drive to or compare from the
DUT pins, and the time set that contains the timing information to apply to the data using the following syntax:
pin2_state …; [// comment]
where the required
timeset is a valid identifier the time set declaration defines or a single dash (-) to indicate to repeat the previous time set and
pin<n>_state represents the pin states.
Vector Statement Conditions
The following conditions apply to vector statements:
Every vector must include a time set reference, which can be a time set declared in the time set declaration or a single
dash (-). A dash specifies to use the same time set as the previous cycle.
Do not use a dash (-) for the time set on the first vector of a pattern file unless the file is used only as a target of a jump or call operation.
At run time, the time set reference resolves to a time set. An error occurs when the time set declaration does not contain
the time set you reference in the vector statement.
A terminating semicolon (;) specifies the end of the vector data.
The pattern sequencer does not automatically stop execution at the end of the pattern. You must specify the
halt opcode on the last vector in the pattern to stop the execution of the pattern. Undefined behavior results in patterns that
complete without a halt code.
The following conditions apply to labels:
The first vector in a pattern file is automatically assigned a label that matches the pattern name. You must export a pattern name to use it as a target of an opcode from another pattern. You can use a pattern name as a
start label parameter value for niDigital API calls without exporting the pattern name. The label resolves to the address of the first vector in the pattern of the same name.
If you rename or delete a label, you must manually update any other references to that label to avoid run-time errors.
For memory efficiency, use labels only on vectors that are targets for jumps, calls, or loops. Use comments for general documentation
about the behavior of the pattern.
Names must begin with an ASCII letter or underscore (_) and are limited to
You cannot duplicate labels in the same pattern.
A vector label cannot duplicate any item in the import declaration.
Local labels are labels that have not been exported.
The Digital Pattern Editor assumes that any label you reference but do not specify in a pattern is an imported label.
The following conditions apply to opcodes:
The vector can contain opcodes the digital pattern instrument processes when the vector executes. Some opcodes include parameters.
Pin State Conditions
pin_item<n> identifier can include one of the following optional format specifiers for pin groups, for example,
||Binary or symbolic; default format
0 — Drive zero.
1 — Drive one.
L — Compare low.
H — Compare high.
X — Do not drive; mask compare.
M — Compare midband, not high or low.
V — Compare high or low, not midband; store results from capture functionality if configured.
D — Drive data from source functionality if configured.
E — Compare data from source functionality if configured.
- — Repeat previous cycle. Do not use a dash (-) for the pin state on the first vector of a pattern file unless the file is used only as a target of a jump operation.
On power-up, pins are in a high impedance state. To avoid unexpected results for DUTs that are sensitive to the initial state of a pattern burst, programmatically specify
the initial pin state by using the niDigital Write Static VI, the DigitalPinSet.WriteStatic .NET method, or the niDigital_WriteStatic
C function. You can interactively set the initial state for a pin by selecting the corresponding driver symbol in the Drive
section of the Pin View pane of the Digital Pattern Editor.
After each pattern burst, the ending state of the last executed vector persists until the start of the next pattern burst
or until you programmatically or interactively change the pin state or pin function.
|For binary data, the length of the binary data sequence must match the width of the pin item as defined by the pin definition.
The exception to this rule is a single
- character, which implies a data value of
- for all pins in the pin item.
When you are not driving data, the pins use the termination mode you select in the test program, such as High Z, Active Load,
.d<decimalvalue> — Drive
.c<decimalvalue> — Compare
|For decimal data, the data value when converted to binary must not exceed the width of the pin item. This restriction does
not apply to leading zeros.
.d<hexvalue> — Drive
.c<hexvalue> — Compare
|For hexadecimal data, the data value when converted to binary must not exceed the width of the pin item. This restriction
does not apply to leading zeros.
The following conditions apply to pin state data:
The number of
pin_state items that follow the time set reference must equal the number of
pin_items the pattern declaration specifies.
pin_item that is a single pin, the
pin_state must use one of the binary (symbolic) pin state symbols.
Currently, the Digital Pattern Editor does not support using system pins in patterns. To burst from a pin that spans all sites,
configure a pin with a shared pin connection in the Pin Map Editor to share a channel across multiple sites and use that pin
in your pattern instead.
pin_item that is a pin group, the
pin_state value width must match the number of pins defined for the pin group in the pin and channel map.
You can include comments on a single line or multiple lines separated with carriage returns before each label and vector statement.
You can also include comments on the same line as a label and vector statement after the semicolon but before the end of the
line. You cannot include comments on the line after the last vector statement. You cannot include comments on the same line
as an edge multiplier statement. By default, the compiled, binary version of the pattern file preserves comments. To disable
preserving comments in the compiled, binary version of the pattern file, use the
-no-comments command-line option in the Digital Pattern Compiler. All comments start with double forward slashes
'//' followed by Unicode characters.