IEEE 1450.3-2007 PDF

IEEE 1450.3-2007 PDF

— Define structures in STIL for the specification of resource mapping of ATE hardware architectures. An example of resource mapping is the assignment of tester resources to waveform characters that are used in STIL vectors. — Define structures in STIL for including ATE-specific instructions in-line with the STIL data. — Define structures in STIL that allow for “incremental processing” whereby, a set of STIL files may be targeted to multiple ATE systems by allowing separately identified ATE data to coexist. — Define structures in STIL for defining tester rules checks to ensure that the set of generated STIL files conform to the selected resources on one or more ATE systems. — Define structures in STIL for the specification of the resources required for the execution of a set of STIL files on a given ATE system.
Transferring “tester independent” test program/pattern data as represented in STIL to a specific ATE system is a desired capability. It is required to be able to completely and unambiguously specify how the STIL program/patterns are mapped onto a specific tester’s resources. Because of the various different use models for the creation and consumption of test data, it is necessary to enable certain operations (such as rules checking) very early in the process. Likewise it is desirable to allow other operations (such as resource allocation) to be done very late in the process. The STIL language extensions enable the user/creator a standard way of specifying and controlling the application of test program/pattern data to specific ATE systems to the extent necessary for each use model scenario.
New IEEE Standard – Inactive-Reserved. The STIL environment supports transferring tester-independent test programs to a specific ATE system. Although native STIL data are tester independent, the actual process of mapping the test program onto tester resources may be critical, and it is necessary to be able to completely and unambiguously specify how the STIL programs and patterns are mapped onto the tester resources. TRC (which stands for either tester resource constraints or tester rules checking, depending on the usage) is an extension to the STIL language to facilitate this operation.