1. The MTS Tester
1.1. Basic concepts
The MTS tester is a low-speed tester adequate for checking the functionality of chips or hybrids with large pin count. It is designed as a set of boards plugged in a PC/AT. Each board may handle 64 pins of stimulus/check data, but the current test setup uses only 60 pins per board. Testing speed depends on the number of boards used.
Test vectors are captured during a Rosemary simulation of the chip using MTSVector (c.f. section 2.). As vector capture uses the effective behaviour of the device under test (DUT), this simulation must be completely faithful the the effective behaviour of the chip, i.e. a transistor-level simulation is very strongly recommended.
The test vector file is tranfered to the PC/AT, and the test is performed on the PC/AT using MTTest (c.f. section 3. for details). During testing, a log of all errors is kept. This can can be transfered back to the Dorado for further analysis.
NOTE: The log analysis program(s) have not be written yet...
1.2. The MTS board: hardware summary
The MTS boards are driven directly from the PC, where they are memory-mapped. Each board controls 64 channels, of which only 60 are used. Those 60 channels are grouped in three flat-cable connectors named T1, T2, T3. Those cables are in turn connected to the test fixture, on which the DUT will be mounted.
Each channel may be driven to Gnd, driven to Vdd or left in a high-impedance. Switching a channel from driving to high-impedance is not guaranteed to occur simultaneously across all channels. Changing the driven value is synchronous among all channels. All the channels may also be sampled synchronously.
Testing is driven by a set of test vectors. Each test vector uses 3 bits per channel to describe the driven/expected value , whether the channel is driven or high-impedance, and whether the channel resulting value is significant. Details of this encoding are presented in section 3.
As the MTS boards have minimal hardware, testing is slow as all is done by software. The test speed depends on the number of boards used, which depends in turn mostly on the fixture arrangement.
There is a standard fixture, which is a 400-pin PGA ZIF socket, used for testing all mounted chips in the Dragon project. The fixture has jumpers for all power supplies. Pull-ups may also be installed wherever needed. Test files contain a full description of the fixture (including power connections & pull-ups), which is checked by the software before running tests.
2. Generating an MTS vector file
2.1. Principles
An MTS vector file contains 2 major pieces of information: the mapping of DUT (Device Under Test) wires (in the Core sense) onto the fixture and MTS boards, and the test vectors themselves. MTSVector test vector files use the suffix xtv (for eXecutable Test Vectors). They are in binary for efficiency reasons, so don't even try to open them...
The mapping between Core wire names and the fixture setup is obtained through a package file, which describes the mapping between Core wire names and package geometrical pin names (which reflect positional information of pins on the package). The geometrical pin names are themselves mapped onto the MTS board channels through a fixture file, which describes the connections between package and MTS boards. Both files are textual, and are described in section 2.3.
The test vectors are captured during a simulation that includes the DUT as a subcell. The capture process requires the package & fixture files.
MTSVector captures the exact behaviour of the DUT, not what you test procs or oracles check for. For example, if you do not check the value of a wire at a given cycle, but this wire has a definite value, MTSVector will require that the DUT present that value on the tester. Thus, it is extremely important that the simulation of the DUT corresponds exactly to the real chip behaviour.
2.2. Vector capture in Rosemary
Vector captures is done from a Rosemary simulation having the DUT as one of its subcells. It is strongly recommended to run this simulation at gate level (transistor-level may raise problems if the test setup is not a simple oracle, macro-level may get a number of X's wrong). A full example is provided in the MTSVector DF-file (ALS652.dale) which should clarify most of the following points.
The chip which is to be tested must be encapsulated within a
cell (not an icon!) that includes the following extra information:
- properties on each of the public wires to indicate the wire port structure. The easiest way is to use the icons provided in RoseTestProcIcons.dale, in DAUser.df. MTSVector only knows
l,
ls,
b and
bs port types. Using bool and bool-sequence types is
not recommended as it may loose some testing information. For level-sequence and bool-sequence wires, you should specify whether the drive is homogeneous or not using the
ts icon (
not
ds). MTSVector checks that wires specified as having homogeneous drive really do so. This information is required because vector capture is done using a tester port created on the DUT cell, even if it is not the top level. An additional property
MTSOption may be added to DUT public wires to modify the capture behaviour. A single option is currently supported:
MTSOption: $After -> should be used on inputs that combinatorially modify outputs
- special Core properties (i.e. CD object satellites):
Vectors: ROPE -- base name of vector file, suffix mtsVectors is automatically added. This information is used both for capture and replay.
Package: ROPE -- base name of package file, suffix mtsPackage is automatically added. This information is used only for capture.
Title: ROPE -- optional comment written to the test file for verification on the PC side. This information is used only for capture.
One at least of Vectors and Package must be present. If only one is present, the other one is taken to have the same value. The syntax for both types of files is described in sections 2.3. and 2.4.
Tests: LIST ["MTSReplay"] -- should be present to allow replaying the vectors later (MTSReplay is a special test procedure provided by MTSVector).
The simulated Core cell must have the DUT (or an icon for the DUT) as a subcell and must have the following Core properties:
DUT: ROPE -- the CoreFlat path name leading from the simulated celltype to the DUT record celltype (not the icon, if you have one: this may require explicit recasting).
Tests: LIST OF ROPE -- the test procs needed for simulation. If your simulation is designed to run with the standard Logic test proc (which supports Oracles), you must specify this property as Tests: LIST ["MTSCapture", "Logic Test"] . The first test proc does simulation with capture, the second one is the default test proc, which will not do the capture. If you use custom test procs, see the end of this section.
CutSet: Logic.gate -- Forces the capture to be done at gate level. Capturing at transistor level is not recommended. Capturing with high-level simulation procedures invoked inside the DUT may produce incorrect results (especially regarding handling of Xs). Using high-level procedures outside the DUT is perfectly acceptable.
If the DUT requires external pullups during testing, those pullups should not be put inside the DUT celltype in the simulation, but outside. The MTSPackage description file (see 2.3) should reflect the existence of those external pullups (this is necessary both for proper vector generation and to allow the fixture setup to be verified properly before testing a chip).
Once this information has been setup correctly, start your simulation using the <SPACE>-F menu and select the right test procedure. You may also start the simulation from code.
There are numerous ways for vector capture to break down:
- some of the required properties may be missing.
- incorrect port information setup. This is not handled very gracefully by the code... The best manual check is to print the Core for the DUT, and check that all wires carry port setup information.
- incorrect syntax in the fixture or package files. The scanner will choke on the first error, but the error reporting is fairly clear.
- inconsistency during simulation (such as different drives when shared drive was specified).
If you have custom test procs, the best solution is to have a look at the high-level section of the interface MTSVector.mesa and at the procedure MTSCaptureTP in MTSVectorImpl.mesa (this procedure is functionally equivalent to LogicRosemaryImpl.LogicTest, but includes vector capture). The MTSVector interface has been designed to provide reasonably simple integration into test procedures, but it remains quite tricky due to the flexibility of custom TestProcs.
2.3. Package file syntax
The package file describes the relationship between the DUT Core wire names (relative to the DUT public) and the geometrical pin information on the package itself. It also indicates some special properties of wires, such as power supplies, unused pins and pull-ups. The package file refers to the fixture file, which describes how the package is connected to the tester boards. Package files have the suffix mtsPackage.
The file is made of a series of statements terminated by semicolumns ";". Columns ":" are ignored and may be used to separate tokens. The syntax is:
<package file> :: <name> <fixture> <wire>*
<name> :: Name <id> ;
<fixture> :: Fixture <id> ;
<wire> :: Wire [/0V | /5V | /PU | /NC ] <id> <id>* ;
<id> :: <alphanumeric rope starting with a letter, including brackets>
The name is used for documentation purposes. It is strongly recommended that the name be equal to the base name of the package file.
The fixture statement indicates the basename of the corresponding fixture file.
Wire statements map a given
atomic Core wire name (in the DUT public) to a list of fixture pin names. The first identifier is the Core wire name, followed by an optional flag. The following identifiers are pin identifiers defined in the specified fixture file. The following flags are supported:
/0V : must be used to identify pins that are grounded on the fixture (including power Gnd pins).
/5V : must be used to identify pins that are connected to 5V supply on the fixture (including power Vdd pins).
/PU : must be used to identify pins that have external pullups on the test fixture. This is necessary both to ensure correct capture and to allow verification of the fixture wiring.
/NC : must be used to identify pins that should not be used during testing. This is especially important for non-standard power supplies and non-difital signals. NC pins are never driven by the tester. Pins that require voltages outside of 0-5V require a special test fixture to avoid damaging the tester. If the NC option is used, pin identifiers may be ommitted (this is the only case where an empty pin id list is allowed).
The GenMTSPinList command (in IcPack.df) allows to generate an almost-correct MTSPackage file, which will still require minor hand editing.
An example is included in the MTSVector DF-file (ALS652.mtsPackage).
2.4. Fixture file syntax
The fixture file describes the relationship between the geometrical pin information on the package and the tester boards. It is not dependant on the chip being tested, but only on the fixture arrangement. Fixture files have the suffix mtsFixture.
The file is made of a series of statements terminated by semicolumns ";". Columns ":" are ignored and may be used to separate tokens. The syntax is:
<fixture file> :: <name> <connector>* <pin>*
<name> :: Name <id> ;
<connector> :: Connector <id> <0..7> [ T1 | T2 | T3 ] ;
<pin> :: Pin <id> <id> <1..20> ;
<id> :: <alphanumeric rope starting with a letter>
<0..7> :: <integer constant in [0..7]>
<1..20> :: <integer constant in [1..20]>
The name is used for documentation purposes. It is strongly recommended that the name be equal to the base name of the fixture file.
The connector statement is used to name a connector from a tester board as seen on the fixture PCB. Each board has 3 connectors, designated as T1, T2, T3. Boards are numbered from 0 to 7, allowing for up to 480 signals and power connections. The connector identifier should be the one printed on the fixture PCB, in order to facilitate probing.
The pin statement indicates how a given package pin is connected to a connector. Each connector has 40 wires, but only the low order 20 (numbered 1 to 20) carry signals. The other 20 are grounded to provide better noise immunity of the tester channels. The pin identifiers are arbitrary. They are used in the package file to identify package pins. The normal convention is to use some sort of geometric coordinate system (e.g. A to Z vertically, 1 to 20 horizontally).
The file PGA400.mtsFixture, included in the MTSVector DF-file, correspond to the generic 400-pin ZIF PGA socket test fixture.
2.5. Checking an MTS vector file
It is strongly recommended to check you test file before rushing onto the tester as vector capture is quite tricky in some situations and is not 100% guaranteed...
MTSVector provides special test procs that replay a test vector file again the DUT in isolation, trying to emulate as closely as possible what the tester actually does. You should run a Rosemary simulation on the DUT
cell (not on the icon!) with the following properties:
Tests: LIST ["MTSReplay"]
Vectors: "<basename of vector test file>"
CutSet: NIL -- to run at transistor level
If your DUT simulation cannot run at transistor level (e.g. because it is too big) and you use the clockEval hack, the properties should instead be:
Tests: LIST ["MTSReplayGate"]
Vectors: "<basename of vector test file>"
CutSet: Logic.gate -- to run at gate level
You may need to change the CutSet to include the requirements for your personnal EvalProcs, if any.
When using MTSReplay, the simulated Eval number is equal to the vector number. When using MTSReplayGate, the simulated Eval number is equal to twice the vector number (as there are 2 Evals per vector).
MTSReplay and MTSReplayGate simulate the tester behaviour when tri-state verification is not enforced. Two additional procedures, MTSReplayTS and MTSReplayTSGate, simulate the tester behaviour when tri-state verification is enforced.
NOTE: MTSReplayTS and MTSReplayTSGate have not been written yet.
3. Running a test on the MTS tester
3.1. Overview
The program MTTest runs on the PC, with a test fixture attached. The test file must have been copied on the PC's local disk (c.f. section 3.2.). MTTest runs interactively and allows to use different test files and different test chips during a run. It provides different testing modes, and two levels of test conformance (with and without tri-state checking).
The MTTest command accepts a single optional argument, which is the name of the initial test file.
3.2. Transfering a test file to the PC/AT
The process is cumbersome, to say the least. It goes in two steps: Dorado to Sun, Sun to PC.
- Dorado to Sun:
- From a command tool on your Dorado, do:
BridgeChange TCP
Bridge Palain
- In the Bridge Unix command tool, do:
RFTP
- In the RFTP window:
Set transfer mode to binary (very important!)
Setup source & target directories
Setup the file name and transfer it
- You may now destroy the RFTP window and logout from Palain
- Sun to PC:
- On the PC, do:
cd the directory where you want your file
ftp palain
enter your user ID & password at the prompt
ftp> cd the directory where you stored the file
ftp> verbose
ftp> binary
ftp> get file.xtv
ftp> quit
- Note that transfer times may be a bit long as test files can be very large. FTP on the PC is rather sluggish.
It is very important to use binary mode for boths transfers. If you don't, the transfer protocols will perform some CR/LF substitutions and null removals that will prove very harmful to the binary test file... The file carries a checksum, but it is only a very weak protection. If your test does not work at all, you may suspect a transmission problem.
Transfering a file from the PC back to the Dorado follows the same steps in reverse.
This process should be improved in the future when we change the TCP/IP software on the tester PC from Win/PC to NFS/PC which provides transparent access to NFS file servers.
3.3. MTTest concepts
MTTest permits to load a test vector file, test fixture conformity, mount and unmount a chip on the test fixture, and initiate tests. Optionally, MTTest provides detailed reports on failures, and logs detailed fault information on a log file. Test files may be larger than the available physical memory (currently 2 MBytes), but test then becomes much slower due to disk access (you'll hear the disk if this is the case...).
To access any other commands of MTTest, a test file must have been loaded. When a test file is loaded, MTTest will check that is is valid and update the display accordingly.
Each time a new test file has been loaded, the user should require MTTest to verify that the fixture is configured (through its straps) in the correct way. MTTest will check that power is supplied only at the designated power pins, that pullups are located as indicated in the package file, and that there are no shorts between pins or between pins and power, other than specified in the initial package and fixture files.
In MTTest, a chip is a specific IC (i.e. instance as opposed to object...). Each chip is identified by a unique name, and MTTest should be kept aware at all times of the currently mounted chip name (if any) because it keeps statistics and logs information on a per-chip basis. Moreover, fixture testing may be performed only when no chip is mounted on the fixture (doing otherwise might damage the chip).
The user may choose if MTTest verifies tri-state pins on the DUT or just ignores them. Although tri-state testing carries a significant time penalty, it should be used at least a few times on each chip. Tri-state test mode is an option that may be toggled from the keyboard.
MTTest offers 3 basic test modes:
- Single test does a single pass over the test file. The pass is stopped at the first discrepancy, and the fault is displayed on screen and logged on the log file.
- Loop test behaves as Single test, except that is is repeated until the user stops it explicitly. Loop test may be verbose (fault info displayed on screen, as for single test), or terse (no fault info displayed).
- Scope test is designed to help debugging problems on the scope. In order to provide correct scope synchronization, it tries to have a constant delay per test pass. Scope testing replays the test file permanently until stopped by the user. During each pass, the whole test file is rplayed, even if error occurs. At the first error in a pass, the fault signal is enabled and may be used to synchronize the scope. The pass signal (those names are historical only...) is asserted once per pass, just before a specific vector (the sync vector) is issued by the tester, The number of the sync vector may be modified from the keyboard. Scope mode should not be used for test files that exceed 2 MBytes, as the refresh rate will probably be too slow to be useful due to disk access.
For single and loop tests, MTTest keeps track, per chip, of the number of passes and the number of succesfull passes (passes interrupted by canceling loop mode are not counted). It also keeps track of the next most succesful case (high-watermark: vector number of `best' failure, and number of times it occured). Scope test mode does not affect those statistics for speed reasons.
3.4. MTTest display
MTTest offers a full-screen display with various fixed fields and a typescript-style scrollable area.
The first display line indicates in that order:
- test file name (8 characters at most)
- package name (8 characters at most)
- fixture name (8 characters at most)
- fixture state (???, OK or BAD)
The second display line indicates in that order:
- name of chip being tested (8 characters)
- tri-state test mode active or not (highlighted or barely visible)
- number of tests performed on this chip / number of succesfull tests
- high-watermark (high-watermark count)
The last display line contains:
- error & prompt message area
- if running in scope mode test, the synchro delta and position (see further on)
All other display lines form a scrollable typescript on which MTTest prints its feedback. This typescript limited only by disk space.
3.5. MTTest commands
MTTest accepts the following commands:
F1 : Open a test file. Prompts for the file name.
F2 : Test the fixture. A test file must be opened, but no chip may be mounted.
F3 : Mount a chip. Prompts for chip name.
F4 : Unmount a chip. Use only if no new chip is to be mounted.
F5 : Start a scope test. Scope test is stopped by pressing the ESCAPE key. During scope test, the sync vector may be updated by pressing the + and - keys, which increment and decrement the sync vector number by a specified delta. The value of this delta is set by pressing keys 0 to 4 to set it to 1, 10, 100, 1000, 1000.
F6 : Start a single test.
F7 : Start terse loop test. Loop test is stopped by pressing the ESCAPE key.
F8 : Start verbose loop test. Loop test is stopped by pressing the ESCAPE key.
F9 : Display a help message describing commands.
F10 : Exit MTTest.
? : Display information on a wire. Accepts Core wire names, package pin names or pin-on-connector pin names (such as P23.14).
ALT-T : Toggle the tri-state test mode bit.
Cursor keys : The vertical cursor movement keys on the keypad (up arrow, down arrow, page up, page down, home and end) act on the scrollable typescript area as expected.
3.6. Fixture test
Fixture testing works as follows:
- First pass:
- Check that power pins are connected to power supply and that power supply is on
- Check that non-power pins are not connected to power supply
- Check that pins with pull-up do have a pull up, and that it is resistive enough to be overriden when driving Gnd into it.
- Second pass:
- For each pair of non-power pins, check that driving one of them to either Gnd or Vdd does not affect the state of the other
During the first pass, MTTest will indicate all pins that do not pass the test, together with an indication of the failure reason (e.g. power supply not strong enough, pull-up missing, etc...). The first pass does not detect that the power supply itself is not on. If the power supply is turned off, MTTest will most likely complain about all Vdd connections & pull-ups.
During the second pass, MTTest will indicate all pairs of wires that seem to be connected together (capacitive coupling between pins is not always properly detected).
The fixture state indicator, at the right end of the first display line, indicates fixture test status. It may indicate:
??? : The fixture has not been tested since the current test file was loaded
BAD : The fixture failed the test
OK : The fixture has been tested succesfully.
MTTest will accept to test a chip if the fixture has not been tested, but it will refuse any chip test command if the fixture was tested and failed. It is strongly recommended to test the fixture each time you load a test file.
3.7. Chip test
Tri-state checking is much slower than normal test (about 5-8x if the test file fits in memory, same speed if the test file does not fit), but it catches more errors. Normal test only verifies that signals driven by the tested chip have the expected values, and ignores all TS pins. When the test is performed with TS mode on, it first does as the normal test, then, for all TS pins, it tries to drive them to Gnd and Vdd, float them and check that the value has not changed within a short time.
Scope test does not provide any screen feedback, except to maintain the sync vector position and delta.
Terse loop test only provides a summary report indicating the total number of passes and the total number of succesfull pass. It also updates the chip-level statistics (second display line).
Verbose loop test and single test provide a full error report on the first error of each pass. The chip-level statistics are also updated at each pass.
Test error reports indicate the vector number where the failure occured, together with a list of all incorrect signals within that vectors. The report uses 2 sets of symbols, one for the test vector specification, another for the test vector result (observed value).
Wires are identified by their core name, their package name and the connector identification. For example, CK(D6/JP5.9). The connector identification allows to find immediately where to put a scope probe to observe signals.
The following symbols are to designate test vector specification on a channel:
X : not driven, not checked
? : should not occur, but behaves like X
L : not driven, expect a low level
H : not driven, expect a high level
0 : driven to low, expect a low level
1 : driven to high, expect a high level
F : driven to low, not checked
T : driven to high, not checked
Z : driven to high or low, checked to be tri-state by device (only in TS mode). Z is in fact a renaming of the states T and F when tri-state mode is on.
The following symbols are to designate test vector observed values on a channel:
? : incomprehensible (i.e. varying value)
L : low level sampled
H : high level sampled
Z : device pin is tri-stated (only if TS mode is enabled)
Error reports present first all atomic wires, with "name : request -> observed", with as many wires as will fit per line. A wire may be presented multiple times if all pins connected to it did not behave in the same way. Then, all buses are presented, with 3 lines per bus. The first line carries the bus name, the second one the requested value for the whole bus, one character per wire, bit 0 on the left. The third line shows the corresponding response. In both cases, observed values are highlighted if they are different from what was expected (only bus value may be non-highlighted). Examples of output are:
CK(D6/JP5.9): 1->L .....
3.8. Using the PGA400 test fixture
The PGA400 test fixture is a board mounted on top of a PC/AT extension chassis that contains 8 MTS test boards. The board has a 400-PGA ZIF socket, which can be used to test DIPs or PGAs up to 20x20 pins.
Power supplies to the chip are setup through straps on the wire-wrap style connectors labelled JP1 to JP20. Each of those connectors has tester channels coming in from the PC on the middle pins, and Vdd and ground on the left & right pins (Vdd/Gnd is printed on the PCB). The connectors may also be used to install pull-ups if necessary (there is not yet any fixed arrangement to help that, you will have to be creative...). Finally, the connectors also offer a convenient way to probe signals if you need to use a scope.
To mount a chip, release the ZIF socket lever, put the chip in and press the ZIF socket lever back in place (not pushing the lever back will produce very poor contacts).
The tester tends to introduce ringing on clock signals. If your test does not yield repetitive results, try to add a small capacitor (typ. 10 to 100 pf) between the clock signals and Gnd.
If you start a series of tests, always check the fixture state before starting (command F2). Be careful to remove any chip from the ZIF before doing so, as the test may damage any chip present on the fixture. Moreover, fixture testing will fail if a chip is present.
Appendix A. Specification of MTS vector files
File format
<MTSFile> ::= <Header> <Block>*
<Header> ::= <signature> <1st block offset> <number of channel groups> <block size> <time stamp> <nVects> <chksum> <testID> <signal>* <padding> -- padded to 1st block offset
<Block> ::= <vector>* <padding> -- with 0's to block size. Vectors do not span blocks.
<padding> ::= 00H *
-- padding with 0 bytes
<signature> ::= CHAR[8] -- version of file format, currently "MTSX0003"
<1st block offset> ::= INT32 -- byte offset of 1st block in file, multiple of 1024 bytes
<number of channel groups> ::= INT16 -- number of boards used in this test
<block size> ::= INT16 -- byte size of a block, must be 0x4000 (16 K = 1 EMM page)
<nVects> ::= INT32 -- number of test vectors in file (last block is incomplete)
<time stamp> ::= BasicTime.GMT -- time stamp to identify test file and log file
<chksum> ::= BYTE -- sum off all bytes in file must be 0 MOD 256
<testID> ::= CHAR[120] -- a title
<signalName> ::= <groupNum> <byteNum> <mask> <bitNum> <pkgName> <conName>
<length> ::= BYTE -- number of bytes in signal name
<groupNum> ::=
BYTE
-- board number to which signal is connected, in [0..7]
Last signal only contains groupNum, equal to 0xFF.
<byteNum> ::= BYTE -- Byte number on board, in [0..7]
<mask> ::= BYTE -- mask for bit in byte
<bitNum> ::= BYTE -- pin number on board, in [1..60], redundant.
<pkgName> ::= CROPE -- name of pin on package. e.g. F17
<conName> ::=
CROPE
-- name of pin on connector, e.g. P4.15
a CROPE is a null-terminated sequence of characters
<vector> ::= <group><number of channel groups> -- a group per board
<group> ::= <triState> <Data> <Mask>
<triState> ::= <field>
<Data> ::= <field>
<Mask> ::= <field>
<field> ::= BIT[64] -- in strict little-endian order
The header may have an arbitrary size, as the table of signal names in not limited. The header size (indicated in <1st block offset>) should be a multiple of 1024 for efficiency reasons. Block padding is smaller than the size of a vector except for the last block of the file (i.e. all except the last block are filled to capacity). All INT32 are written in little-endian order (least significant byte first). Fields are written in bit little-endian order, i.e. byte 0 is (b7, b6, b5, b4, b3, b2, b1, b0) and so on.
Semantics
The set of corresponding bits in a field may have 8 values with the following semantics:
triState Data Mask Symbol Action
0 0 0 X Not driven, not checked
0 0 1 L Not driven, expect L
0 1 0 ? Undefined
0 1 1 H Not driven, expect H
1 0 0 F Drive L, check tri-stated
1 0 1 0 Drive L, check L result
1 1 0 T Drive H, check tri-stated
1 1 1 1 Drive H, check H result
The F and T actions perform or not tri-state checking according to a run-time switch during the test.