The GX5296 has a unified Vector memory which combines several pieces of information. Each Vector channel's state is represented in the form of an ASCII character. The ASCII Character encodes the Output, Real Time Expect, Tristate Control (Direction), and Mask information for a particular channel within a Vector. The Vector Memory API functions allow the user to write and read from Vector Memory to any desired channel or group of channels for a given range of Vectors.
A separate Record Memory contains either response data or error data
depending on the Record Mode selected for a particular Step. If the Step’s
Record Mode is set to Response, a ‘1’ indicates a logic high response,
and a ‘0’ indicates a logic low response. If the Step’s Record Mode is
set to Error, a ‘1’ indicates a real time compare error, and a ‘0’ means
no real time compare error occurred. The Record Memory stores up to 64M
of response vectors. Both the Record and Vector memories are 64M deep.
The indices of the Record Memory are mapped 1 to 1 with the Vector Memory.
Opcode |
Description |
Driver State |
Drive Level |
Comparator Expect |
Invert Code |
1 |
Drive High, Don’t Expect (Don’t Care) |
On |
VoH |
None |
Drive Low ‘0’ |
0 |
Drive Low, Don’t Expect (Don’t Care) |
On |
VoL |
None |
Drive High ‘1’ |
h |
Drive High, Expect High |
On |
VoH |
>ViH |
Drive Low, Expect Low ‘l’ |
l |
Drive Low, Expect Low |
On |
VoL |
<ViL |
Drive High, Expect High ‘h’ |
H |
Expect High, Don’t Drive |
Off |
X |
>ViH |
Expect Valid Low ‘L’ |
L |
Expect Low, Don’t Drive |
Off |
X |
<ViL |
Expect Valid High ‘H’ |
Z |
Tristate (Disabled) |
Off |
N/A |
None |
Disable Channel ‘Z’ |
/ |
Drive Low, Expect High |
On |
VoL |
>ViH |
Drive High, Expect Low ‘\’ |
\ |
Drive High, Expect Low |
On |
VoH |
<ViL |
Drive Low, Expect High ‘/’ |
V |
Expect Valid Level |
Off |
X |
>ViH OR <ViL |
Expect Invalid ‘B’ |
B |
Expect Invalid Level |
Off |
X |
<ViH AND >ViL |
Expect Valid ‘V’ |
R |
Repeat previous opcode |
Repeats the last non-repeat/invert code. |
|||
I |
Invert previous opcode |
Inverts the last non-repeat/invert code. Refer to Invert Code |
|||
Vector Opcode Description Sequencer Step Memory
When running the Sequencer executes a series of one or more Steps, as defined by the user. This execution is known as a Burst. The Burst will continue until a non-jumping Step is executed with the Last Step flag set to True. At this point, the Sequencer will enter the Standby state. A Step points to a block of vectors (contiguous, in vector memory) and applies timing, control, and record parameters during run-time.
Each Step can be assigned a block of vectors from the vector memory. The Step contains the number of vectors and the start offset (from Vector memory 0) address. Vector memory should be accessed contiguously. The number of vector s can be from 1 vector up to 67108864 (64M), for each step.
See GtDio6xStepSetVectorCount in Function Reference for more information.
The T0 Clock or System Clock is the programmable clock which is common to all the steps. The clock can be programmed to any value between 1000.0 nSec to 8.0 nSec, and the default is 100 nSec.
See GtDio6xStepSetClock in Function Reference for more information.
Each Step is associated with a Timing Set Index Memory location. The Timing Set Index Memory location points to predefined Phase Assert/Return, and Window Open/Close timing sets in terms of nSec. The Timing Sets available per Step, and the way to configure them is described in the Indexed Timing Sets of this section.
See GtDio6xTimingSetEdgeSet, GtDio6xStepSetTimingSetIndex for more information.
Two clocks are available for triggering the vectors’ phase and window timing sets, System Clock (T0 Clock) and Vector Clock.
The Clocks per Vector determines the number of System Clocks that will be generated for each Vector Clock. When Clocks per Vector = 1, the Vector Clock period is equal to System Clock period. When Clocks per Vector = 2, the Vector Clock period is two times the System Clock period.

Timing Diagram of Clocks per Vector at 1

Timing Diagram of Clocks per Vector at 2

Timing Diagram of Clocks per Vector at 3
See GtDio6xStepSetClock for more information.
Each Step can be configured to use the Record Memory in a specific manner.
The Step can be configured to record a response or perform a real time compare of error states.
The user can also choose to not write to the record memory. The following describes the various record modes:
● None - All three record memories are disabled. The record memory does not record any incoming data. The record memory can either be set to record all zeros (No Error) or disabled using the GtDio6xSequencerSetRecordParameters API.
● Record Error - All three memories are enabled, the Error Count and the Error Address Memory, the Record Index Memory and the Record Memory. The Record Memory is set to record real time record data.
● Record Response - All three memories are enabled. All three memories are enabled, the Error Count and the Error Address Memory, the Record Index Memory and the Record Memory. The Record Memory is set to record response data.
See GtDio6xStepSetRecordMode for more information.
The GX5296 supports a Real-Time Hardware Compare (RTC) mode. This mode provides users with the ability to perform on-the-fly comparison of acquired response data against expected data. All the data comparison is performed in hardware on a per-sample basis which significantly reduces the time required to unload and analyze the data. In this mode, the user programs the vector memory with expect or mask values for each vector step and each vector is compared against the programmed expect value. Errors are recorded in a 1K error memory which records errors and the associated address of the failing vector.
Time alignment of response and expect data produced by simulation requires an offset of four vectors in order to avoid recording failures at the wrong step location. To confirm correct alignment of compare data, the user should employ a force failure test routine as a marker to determine correct alignment / offset of the acquired response data against expected data for each unique timing value associated with a burst.
The phase trigger source allows the user to select the phase reset signal source which can be the System Clock or the Vector Clock. The phase reset signal restarts the phase assert and return timing.
See GtDio6xStepSetPhaseTriggerSource for more information.
This flag indicates whether the current step is the last step of the sequence burst or a sub-step of a multi-step burst.
See GtDio6xStepSetLast for more information.
There is one control statement that is evaluated at the end of each Step by the Sequencer. The control statement is part of the Step’s memory structure. At the end of a Step (where one or more Vectors were executed), a control statement allows the Sequencer to Jump, Go to Subroutine, Loop, Stop, or Continue to the next Step. This functionality only applies to the master card in a multi-card GX5296 domain configuration.
The branching can be made on the following conditions:
1. GTDIO6X_CONTROL_CONDITION_ALWAYS: Jump always (Unconditional).
2. GTDIO6X_CONTROL_CONDITION_RTC_ERROR_IN_STEP: Jumps if the Real Time Compare detected at least one failure in the step. See comments for details.
3. GTDIO6X_CONTROL_CONDITION_NO_RTC_ERROR_IN_STEP: Jumps if the Real Time Compare did not detect any failures in the step.
4. GTDIO6X_CONTROL_CONDITION_RTC_ERROR_COUNT_NOT_ZERO: Real Time Compare Error Count Not Zero (burst accumulated).
5. GTDIO6X_CONTROL_CONDITION_RTC_ERROR_COUNT_ZERO: RTC Error Count Zero (burst accumulated). Real Time Compare Error Count Zero (burst accumulated).
6. GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER_0_TRUE: Jump 0 Trigger True.
7. GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER_0_FALSE: Jump Trigger 0 False.
8. GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER_1_TRUE: Jump Trigger 1 True.
9. GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER_1_FALSE: Jump Trigger 1 False.
10. GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER_2_TRUE: Jump Trigger 2 True.
11. GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER_2_FALSE: Jump Trigger 2 False.
12. GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER_3_TRUE: Jump Trigger 3 True.
13. GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER_3_FALSE: Jump Trigger 3 False.
Two jump types can be set, Normal and Gosub.
· Jump: Forces the next sequence step number to be replaced by the specified step number.
· Gosub jumps save the current step number and forces the next sequence step number to be replaced by a specified step number. Subroutines can contain a single step or multiple steps but must be placed after all active steps within a test sequence. The last step of a Gosub must contain a Return Flag. The Return Flag informs the sequencer to return to the beginning of the last saved step plus one. The following test sequence details how a sequence would execute with Gosub calls.
- Step 0
- Step 1 Call Subroutine Step 5
- Step 2
- Step 3 Call Subroutine Step 5
- Step 4 Last Step Flag
- Step 5 First step of the subroutine
- Step 6
- Step 7 Subroutine Return Flag
In the test sequence above if step number 1 and 3 call a Gosub at step 5 then the step number sequence starting from Step 0 would be, 0,1,5,6,7,2,3,5,6,7,4. Step 4 concludes the test sequence.
● GTDIO6X_CONTROL_CONDITION_RTC_ERROR_IN_STEP and GTDIO6X_CONTROL_CONDITION_NO_RTC_ERROR_IN_STEP: The sequence step jump logic includes a pass/fail condition. The pass/fail condition is the combination of all the valid channel comparator results and the condition enable flag for the current vector. The condition enable flag for the current vector is set by calling GtDio6xWriteVectorTestFlagsMemory API and can be enabled/disabled per vector. This pass/fail condition is then inserted in a 32-bit pipeline. The contents of the pipeline are ANDED with the contents of the pipeline mask to generate a pass/fail flag that the sequencer can jump on. Bit 0 is the mask for the first bit in the pipeline and bit 31 is the mask for the last bit in the pipeline. If no bits are set, raw error is used for jumping, counting burst errors and logging errors in the error address memory. See the GtDio6xRealTimeCompareSetJumpPipelineMask API for more details. At least one vector in the specified step has to have its condition vector flag be set. The Real Time Compare condition vector flag allows the user to determine if any of the expect pattern codes will cause the conditional jump pass/fail flag to be set if the expected state is not true. See GtDio6xRealTimeCompareSetJumpSource API.
● GTDIO6X_CONTROL_CONDITION_RTC_ERROR_COUNT_NOT_ZERO and GTDIO6X_CONTROL_CONDITION_RTC_ERROR_COUNT_ZERO: The error vector flag allows the user to determine if any of the expect pattern codes will cause the burst error flag to be set if the expected state is not true. At least one vector in the specified step has to have its error vector flag be set in order to enable the error count. See GtDio6xRealTimeCompareSetJumpSource API.
● GTDIO6X_CONTROL_CONDITION_JUMP_TRIGGER: Four sequence step jump triggers are available. The sequence step jump triggers are used for conditional jumping/looping. A jump/loop can be based on the true/false state of any of the four sequence step jump triggers. For example, if jump trigger 1 test mode is set to 'Low Level', then a jump if trigger 1 true would occur if the selected jump trigger 1 source is low. See the GtDio6xTrigConfigSetJumpTrigger API for more details. The true/false state of the jump triggers is based on the jump trigger test event. If the jump trigger event is set to “Low Level”, then true would indicate the jump trigger signal is low and false would indicate the jump trigger signal is high.
See GtDio6xStepSetControl for more information.