Patent Application
20070294580
For a better understanding of the invention, and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawings, in which:
In order to support instrument plug and play, the virtual tester must accommodate any set of compliant instruments that corresponds to a permitted set of hardware instruments, and it must also ensure independence among the instrument models. Each instrument of the virtual tester is a distinct software process that models the behavior of an instrument of the physical tester. Each instrument model must be self-contained and require no information regarding the behavior of the other instruments or whether any other instrument exists. However, all the instruments must work together to function as a system. For example, depending upon device test requirements, one instrument model may need to wait until another instrument has completed a particular task before proceeding (e.g. a device with HSS buses might have to train the serial ports before running the functional vectors on all the pins). Several instruments may need to detect a device condition together before proceeding (e.g. conditional branching or match loops across pins connected to multiple instruments).
Referring to
Similarly, each abstract instrument comprises an abstract interface and a model of a selected concrete instrument. Each abstract instrument has the same abstract interface, which allows the instrument to issue and receive sync messages respectively to and from the abstract test head. The abstract test head functions in conjunction with any abstract instrument that complies with the requirements of the abstract test head, just as a physical test head that supports instrument plug and play is able to accommodate any physical instrument that complies with the mechanical and electrical requirements established for such physical instruments. For example, the abstract test head might issue and receive sync messages having a particular format, and a compliant abstract instrument must accept sync messages in the form issued by the abstract test head and issue sync messages in the form accepted by the abstract test head. Each model of the selected concrete instrument emulates the behavior of a physical instrument. The manner in which the abstract instrument responds to a sync message that it accepts from the abstract test head, or the manner in which the abstract instrument generates a sync message that it issues to the abstract test head, are functionally determined by the concrete instrument and not directly by the abstract test head. Similarly, the manner in which the abstract test head responds to a sync message that it accepts from the abstract instrument, or the manner in which the abstract test head generates a sync message that it issues to the abstract instrument, are functionally determined by the concrete test head itself and not directly by the abstract instrument.
The generic fixture 48 interfaces with the device logic simulator 52 and corresponds to the physical socket that receives the DUT in a physical tester. The generic fixture is a list of channel data structures, one for each pin of the DUT. The data structure for a given pin may contain values to be supplied to the device logic simulator 52 and acted upon by the device logic simulator, or may contain values supplied by the device logic simulator to be transmitted to a channel of an abstract instrument. The device logic simulator may accept messages in the form (pin, activity, level, delay) and issue messages of the form (pin, true/false). Accordingly, the data structures of the generic fixture may store messages of the form (pin, activity, level, delay) or (pin, true/false).
The physical DUT generally has alphanumeric pin names (e.g. A0-A31, D0-D31, etc.). Correspondingly, the device logic simulator has an array of alphanumeric pin indexes corresponding to the pin names of the DUT and the channel data structures of the generic fixture are specified by corresponding alphanumeric pin indexes.
Each physical test instrument has a slot number within the test head and each channel within the test instrument has a number. Each abstract instrument has an index corresponding to the slot number of the physical test instrument and has a local set of numeric channel indexes corresponding to the channel numbers of the physical test instrument. The VT engine 56 orders the alphanumeric pin indexes of the generic fixture alphabetically and assigns consecutive numerical indexes to the pins in the global pin list, and also creates a channel relay matrix 60 that maps the local pin indexes within the abstract instruments to the global pin list in the generic fixture. Thus, the channel relay matrix serves the purpose of the relay matrix in the physical tester in providing communication between a pin of the DUT and the instrument channel that serves the pin.
The test program defines the test to be conducted and is to be validated by the virtual tester. The test program specifies a succession of test activities by referring to (at least) a channel that is to perform the activity, the action that the channel is to perform, and the delay time. The test activity may also refer to a sync condition that must be met before the activity is performed. The test activities and sync conditions are reflected in data that the test program loads into data structures of the virtual tester.
The VT engine 56 defines a common abstract interface for different instrument models and passes messages to and from the instruments. The only interface between the VT engine and other parts of the virtual tester is the abstract interface.
The common abstract interface of the VT engine includes a sync messaging mechanism that allows an instrument model to post sync messages to the VT engine and permits other instrument models to evaluate and act on the sync messages. Thus, the VT engine provides the functionality, in the tester system software, of the ring bus or backplane in the physical tester.
An instrument model generates a sync message containing the following elements:
The action that is to be taken is specified in the test program, and is also part of the hardware instrument design/implementation. Thus, the hardware instrument determines what will happen when the sync condition is met, and this behavior is modeled in the concrete instrument.
This sync message mechanism allows the VT engine to synchronize the instruments without use of specific information regarding the hardware instruments, which would otherwise be difficult because the accuracy and latency requirements differ from tester to tester and the transferred information (format, content) for synchronization differs from tester to tester.
The instrument models generate the proper sync messages and the contents of the sync messages are determined by the user test program and by the hardware behavior (as made available to the abstract instrument by the corresponding concrete instrument model). For example, the sync name is usually defined in the test program (such as a trigger or pattern instruction) but the sync time must incorporate hardware latency (such as the number of pipelines through which the message must propagate in the event that the VT engine emulates a ring bus rather than a backplane).
A sync message does not refer to a destination instrument, because it is necessary that the model of an instrument be independent of other abstract instruments. For example, if a message issued by instrument 3 relates to a condition at pin 1, which is served by instrument 2, the message would refer to pin 1, not to instrument 2. The source instrument posts the sync message to the VT engine, which delivers the sync message to each other instrument. The destination instrument will recognize the sync message and act upon it, while the other instruments will ignore the message. In the case of the example, instrument 2 compares the message to the list of pins served by that instrument, recognizes that it is the destination instrument for the message since it serves pin 1, and acts upon the message.
The VT engine executes an algorithm in a continuous progression from the start of a test to the end of the test, and controls the progression of the algorithm based on virtual tester cycles. For each virtual tester cycle, the VT engine goes through the following steps:
Because the concrete test head and concrete instruments communicate through respective abstract interfaces, the concrete test head is not dependent on implementation of the concrete instruments and similarly, the concrete instruments are not dependent on implementation of the concrete test head. Use of abstract interfaces in this manner allows the virtual tester to accommodate any set of compliant instruments, without reference to the concrete test head. Similarly, the concrete test head can be configured to model a physical test head having a ring bus or a backplane without regard to the concrete instruments.
It will be appreciated that the invention is not restricted to the particular embodiment that has been described, and that variations may be made therein without departing from the scope of the invention as defined in the appended claims and equivalents thereof. Unless the context indicates otherwise, a reference in a claim to the number of instances of an element, be it a reference to one instance or more than one instance, requires at least the stated number of instances of the element but is not intended to exclude from the scope of the claim a structure or method having more instances of that element than stated.
