Classifications

• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
  • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
  • G01R31/26—Testing of individual semiconductor devices
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
  • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
  • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
  • G01R31/317—Testing of digital circuits
  • G01R31/3181—Functional testing
  • G01R31/319—Tester hardware, i.e. output processing circuits
  • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
  • G01R31/31907—Modular tester, e.g. controlling and coordinating instruments in a bus based architecture
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
  • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
  • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
  • G01R31/317—Testing of digital circuits
  • G01R31/3181—Functional testing
  • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
  • G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
• • G—PHYSICS
  • G01—MEASURING; TESTING
  • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
  • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
  • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
  • G01R31/317—Testing of digital circuits
  • G01R31/3181—Functional testing
  • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
  • G01R31/318342—Generation of test inputs, e.g. test vectors, patterns or sequences by preliminary fault modelling, e.g. analysis, simulation
• • H—ELECTRICITY
  • H01—ELECTRIC ELEMENTS
  • H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
  • H01L22/00—Testing or measuring during manufacture or treatment; Reliability measurements, i.e. testing of parts without further processing to modify the parts as such; Structural arrangements therefor

Definitions

• the present invention relates to the testing of integrated circuits (ICs), and more particularly to developing a test program for automated semiconductor test equipment (ATE).
• ICs integrated circuits
• ATE automated semiconductor test equipment
• Testers use their own proprietary languages to develop test programs for semiconductor test systems (testers). For example, machines produced by Advantest Corporation utilize the Test Description Language (TDL), and Credence Systems offers its own Waveform Generation Language (WGL). To overcome this degree of specialization, IC and tester manufacturers tried to find a common ground by developing IEEE standard 1450, the Standard Test Interface Language (STIL). STIL, however, is a highly specialized language for defining pins, test commands, timing, etc. Moreover, a test engineer running STIL nevertheless still needs to translate STIL into the proprietary manufacturer- specific language required by the tester. Thus STIL merely serves as an intermediate language that is nonetheless highly specialized and not generally known to programmers.
• TDL Test Description Language
• WGL Waveform Generation Language
• STIL Standard Test Interface Language
• STIL is a highly specialized language for defining pins, test commands, timing, etc.
• a test engineer running STIL nevertheless still needs to translate STIL into the proprietary manufacturer- specific language required by the tester.
• STIL merely serves as an intermediate language that
• test program can be written in a general purpose language.
• this method should allow for easy development of test programs for an open architecture test system.
• This application describes test program development using object-oriented constructs, e.g., C++ objects and classes.
• this method is suitable for developing test programs for an open architecture tester, such as that described in U.S. application serial nos. 60/449,622, 10/404,002 and 10/403,817, assigned to the assignee ofthe present invention.
• An embodiment ofthe present invention provides a method for developing a test program by describing test system resources, test system configuration, module configuration, test sequence, test plan, test condition, test pattern and timing information in general-purpose object-oriented, e.g., C/C++, constructs to test a device under test, e.g., an IC, on a semiconductor test system, such as automated test equipment (ATE).
• ATE automated test equipment
• the files containing these descriptions are stored in memory, i.e., a computer-readable medium, accessible to the test system or related equipment that uses the files.
• Describing test system resources may comprise specifying a resource type, where the resource type is associated with at least one test module for applying a test to the IC, specifying a parameter type associated with the resource type, and specifying a parameter ofthe parameter type.
• Describing test system configuration may comprise specifying a site controller for controlling at least one test module, where each test module applies a test to the IC, and specifying an input port of a module connection enabler.
• the test system couples the site controller to the module connection enabler at the specified input port, and the module connection enabler couples the site controller to a test module.
• the module connection enabler may be implemented as a switch matrix.
• Describing module configuration may comprise specifying a module identifier for specifying a module type, specifying executable code for controlling a test module ofthe module type specified by the module identifer, and specifying a resource type associated with the test module.
• the executable code may take the form of a dynamic link library.
• Describing module configuration may further involve the user specifying a slot identifier for specifying an output port ofthe module connection enabler, where the test system couples the test module to the module connection enabler at the output port, and the module connection enabler couples the test module to a corresponding site controller.
• the user may also specify a vendor identifier for identifying the provider ofthe test module, and an identifier ofthe maximum number of resource units available in connection with the resource type.
• the resource type may be, for example, digital tester pins and the resource units tester channels. Alternatively, the tester channel resource units may also correspond to resource types such as, for example, analog tester pins, RF tester pins, power supply pins, digitizer pins, and arbitrary waveform generation pins.
• An indicator relating to which resource units are disabled may also be provided. The resource units indicated as disabled may represent defective resource units of the test module.
• Describing test conditions may comprise specifying at least one test condition group, specifying a specification set including at least one variable; and specifying a selector for selecting an expression to be bound to a variable. Association ofthe test condition group with a selector for the specification set defines a test condition.
• Describing a test sequence may comprise specifying the order (or flow) in which various tests can be applied.
• Describing test patterns may comprise specifying the test patterns, associated voltage and current levels, transitions in signal values, corresponding rise and fall times and associated timing.
• An embodiment ofthe present mvention also includes the use of preheader files.
• a preheader file is compiled to create a header file for a class associated with a test entity.
• the preheader mcludes a parameter block for specifying parameters for setting at least one attribute ofthe test entity, and a template block for specifying source code that is inserted by a compiler into the header file for the test entity class.
• the header file may be a C++ header file.
• the test entity may be a test and the test entity class may be a test class, for example.
• the parameters may relate to pattern lists and test conditions, for example.
• a pattern compiler of an embodiment ofthe invention includes at least one module-specific pattern compiler, and an object file manager for directing each module-specific compiler to compile both a corresponding module-specific section of a pattern source file and a common section ofthe pattern source file.
• the common section includes information accessible to all ofthe module-specific compilers.
• An output ofthe compiler includes at least one module- specific pattern data section. Module-specific pattern loaders load into corresponding test modules module-specific pattern data from corresponding module-specific pattern data sections for execution.
• Figure 1 illustrates a conventional tester architecture
• Figure 2 illustrates a tester architecture according to an embodiment ofthe present invention.
• Figure 3 illustrates a tester software architecture according to an embodiment of the present invention.
• Figure 4 illustrates a test program compiler according to an embodiment ofthe present mvention.
• Figure 5 illustrates how different test instances may be derived from a single test class according to an embodiment ofthe present invention.
• Figure 6 illustrates a pattern compiler according to an embodiment ofthe present invention.
• Figure 7 illustrates a ordered pattern tree example according to an embodiment of the present invention.
• Figure 8 illustrates another ordered pattern tree example according to an embodiment ofthe present invention.
• Figure 9 illustrates the relationships among files that are required by a test program according to an embodiment ofthe present invention.
• Figure 10 illustrates waveform generation according to an embodiment ofthe present invention.
• Figure 11 illustrates a mapping used for timing according to an embodiment of the present invention.
• Figure 12 illustrates another mapping used for timing according to an embodiment ofthe present mvention.
• the present invention is generally described in terms ofthe Open architecture test system as disclosed in U.S. application serial nos. 60/449,622, 10/404,002 and 10/403,817 by the same assignee. Those skilled in the art will recognize, however, that embodiments ofthe test program development system and method of the present invention are applicable not only to an open tester architecture, but also to fixed tester architectures, as well.
• FIG. 1 illustrates a generalized architecture of a conventional tester showing how a signal is generated and applied to a device-under-test (DUT).
• DUT device-under-test
• Each DUT input pin is connected to a driver 2 that applies test data, while each DUT output pin is connected to a comparator 4.
• tri-state driver-comparators are used so that each tester pin (channel) can act either as an input pin or as an output pin.
• the tester pins dedicated to a single DUT collectively form a test site that works with an associated timing generator 6, waveform generator 8, pattern memory 10, timing data memory 12, waveform memory data 14, and block 16 that define the data rate.
• FIG. 2 illustrates a system architecture 100 according to an embodiment ofthe present invention.
• a system controller (SysC) 102 is coupled to multiple site controllers
• Each site controller is coupled to control one or more test modules 108 located at a test site 110.
• the module connection enabler 106 allows reconfiguration of connected hardware modules 108 and also serves as a bus for data transfer (for loading pattern data, gathering response data, providing control, etc.). Possible hardware implementations include dedicated connections, switch connections, bus connections, ring connections, and star connections.
• the module connection enabler 106 may be implemented by a switch matrix, for example.
• Each test site 110 is associated with a DUT 112, which is connected to the modules ofthe corresponding site through a loadboard 114. In one embodiment, a single site controller may be connected to multiple DUT sites.
• the system controller 102 serves as the overall system manager. It coordinates the site controller activities, manages system-level parallel test strategies, and additionally provides for handler/probe controls as well as system-level data-logging and error handling support. Depending on the operational setting, the system controller 102 can be deployed on a CPU that is separate from the operation of site controllers 104. Alternatively a common CPU may be shared by the system controller 102 and the site controllers 104. Similarly, each site controller 104 can be deployed on its own dedicated CPU (central processing unit), or as a separate process or thread within the same CPU.
• system architecture can be conceptually envisioned as the distributed system shown in Figure 2 with the understanding that the individual system components could also be regarded as logical components of an integrated, monolithic system, and not necessarily as physical components of a distributed system.
• FIG. 3 illustrates a software architecture 200 according to an embodiment of the present invention.
• the software architecture 200 represents a distributed operating system, having elements for the system controller 220, at least one site controller 240, and at least one module 260 in correspondence to related hardware system elements 102, 104, 108.
• the architecture 200 mcludes a corresponding element for module emulation 280 in software.
• the development environment for this platform can be based on Microsoft Windows.
• the use of this architecture has side benefits in program and support portability (e.g., a field service engineer could connect a laptop which runs the tester operating system to perform advanced diagnostics).
• the relevant software can be made as an independent entity capable of running independently to allow job scheduling across distributed platforms.
• Related software tools for batch jobs are thus capable of running on multiple platform types.
• ANSI/ISO standard C++ can be taken as the native language for the software.Of course, there are a multitude of options available (to provide a layer over the nominal C++ interfaces) that allows a third party to integrate into the system with an alternative language of its own choice.
• Figure 3 illustrates a shading of elements according to their organization by nominal source (or collective development as a sub-system) including the tester operating system , user components 292 (e.g., supplied by a user for test purposes), system components 294 (e.g., supplied as software infrastructure for basic connectivity and communication), module development components 296 (e.g., supplied by a module developer), and external components 298 (e.g., supplied by external sources other than module developers).
• nominal source or collective development as a sub-system
• user components 292 e.g., supplied by a user for test purposes
• system components 294 e.g., supplied as software infrastructure for basic connectivity and communication
• module development components 296 e.g., supplied by a module developer
• external components 298 e.g., supplied by external sources other than module developers.
• the tester operating system (TOS) interface 290 include: System Controller to Site Controller interfaces 222, framework classes 224, Site Controller to Module interfaces 245, framework classes 246, predetermined module-level interfaces, backplane communications library 249, chassis slot IF (Interface) 262, loadboard hardware IF 264, backplane simulation IF 283, loadboard simulation IF 285, DUT simulation IF 287, Verilog PLI (programming language interface) 288 for DUT's Verilog model and C/C++ language support 289 for DUT's C/C++ model.
• TOS tester operating system
• User components 292 include: a user test plan 242, user test classes 243, hardware loadboard 265, and DUT 266, a DUT Verilog model 293 and a DUT C/C++ model 291.
• System components 294 include: system tools 226, communications library 230, test classes 244, a backplane driver 250, HW backplane 261, simulation framework 281, backplane emulation 282, and loadboard simulation 286.
• Module-development components 296 include: module commands implementation 248, module hardware 263, and module emulation 284.
• External components 298 include external tools 225.
• the system controller 220 includes interfaces 222 to site controller, framework classes 224, system tools 226, external tools 225, and a communications library 230.
• the System Controller software is the primary point of interaction for the user. It provides the gateway to the Site Controllers ofthe invention, and synchronization ofthe Site Controllers in a multi-site/DUT environment as described in U.S. application no. 60/449,622 by the same assignee. User applications and tools, graphical user interface (GUI)-based or otherwise, run on the System Controller.
• GUI graphical user interface
• the System Controller also may act as the repository for all Test Plan related information, including Test Plans, test patterns and test parameter files. The memory storing these files may be local to the system controller or offline, e.g., connected to the system controller through a network.
• a test parameter file contains parameterization data for a Test class in the object oriented environment of an embodiment ofthe invention.
• the standard interfaces 222 on the System Controller 220 include interfaces that the tools use to access the tester and test objects.
• applications 225, 226 allow interactive and batch control ofthe test and tester objects.
• the tools include applications for providing automation capabilities (through, for example, the use of SECS/TSEM, etc.)
• the Communications library 230 residing on the system controller 220 provides the mechanism to communicate with the Site Controllers 2 0 in a manner that is transparent to user applications and test programs.
• the Interfaces 222 resident in memory associated with the System Controller 220 provide open interfaces to the framework objects that execute on the System Controller. Included are interfaces allowing the Site Controller-based module software to access and retrieve pattern data. Also included are interfaces that applications and tools use to access the tester and test objects, as well as scripting interfaces, which provide the ability to access and manipulate the tester and test components through a scripting engine. This allows a common mechanism for interactive, batch and remote applications to perform their functions.
• the Framework Classes 224 associated with the System Controller 220 provide a mechanism to interact with these above-mentioned objects, providing a reference implementation of a standard interface.
• the site controller 240 ofthe mvention provides a functional test object.
• the system controller framework classes may provide a corresponding functional test proxy as a remote system controller-based surrogate ofthe functional test object.
• the standard functional test interface is thus made available to the tools on the system controller 220.
• the framework classes effectively provide an operating system associated with the host system controller. They also constitute the software elements that provide the gateway to the Site Controllers, and provide synchronization ofthe Site Controllers in a multi-site/DUT environment. This layer thus provides an object model in an embodiment ofthe invention that is suitable for manipulating and accessing Site Controllers without needing to deal directly with the Communications layer.
• the site controller 240 hosts a user test plan 242, user test classes 243, standard test classes 244, standard interfaces 245, site controller framework classes 246, module high level command interfaces (i.e., predetermined module-level interfaces 247, module commands implementation 248, backplane communications library 249, and a backplane driver 250.
• site controllers 104/240 Preferably most ofthe testing functionality is handled by the site controllers 104/240, thus allowing independent operation ofthe test sites 110.
• Test Plan 242 is written by the user.
• the plan may be written directly in a standard computer language employing object-oriented constructs, such as C++, or described in a higher level test programming language to produce C++ code, which can then be compiled into the executable test program.
• object-oriented constructs such as C++
• TPL Test Program Language
• the test program compiler 400 acts in part as a code generator including a translator section 402 to translate a test program developer's source files 404 describing tests and associated parameters into object-oriented constructs, such as C++ code.
• a compiler section 406 compiles and links the code into executables, e.g., DLLs, to create the test program that may be executed by the tester system.
• executables e.g., DLLs
• the compiler section may be a standard C++ compiler known in the art.
• the test plan creates test objects by using the Framework Classes 246 and/or standard or user supplied Test Classes 244 associated with the site controllers, configures the hardware using the Standard Interfaces 245, and defines the test plan flow. It also provides any additional logic required during execution ofthe test plan.
• the test plan supports some basic services and provides an interface to the services of underlying objects, such as debug services (e.g., break-pointing), and access to underlying framework and standard classes.
• the source code input to the test program compiler 400 includes a Test Plan description file that specifies the objects used in a test plan and their relationships to one another.
• This file is translated to C++ code that is executed on the Site Controller in the form of an implementation of a standard interface, which may be denoted iTestPlan.
• This code is packaged into a Windows dynamic link library (DLL), which may be loaded onto the Site Controller.
• DLL Windows dynamic link library
• the Test Program DLL is generated to have standard known entry points that the Site Controller software can use to generate and return the TestPlan object it contains.
• the Site Controller software loads the Test Program DLL into its process space and uses one ofthe entry points to create an instance ofthe Test Plan object. Once the Test Plan object has been created, the Site Controller software can then execute the test plan.
• the Framework classes 246 associated with the site controllers are a set of classes and methods that implement common test-related operations.
• the site controller-level framework mcludes, for example, classes for power supply and pin electronics sequencing, setting level and timing conditions, obtaining measurements, and controlling test flow.
• the framework also provides methods for runtime services and debugging.
• the framework objects may work through implementing the standard interfaces. For example, the implementation of the TesterPin framework class is standardized to implement a general tester pin interface that test classes may use to interact with hardware module pins.
• Certain framework objects may be implemented to work with the help ofthe module-level interfaces 247 to communicate with the modules.
• the site controller framework classes effectively act as a local operating system supporting each site controller.
• the program code In general more than ninety percent ofthe program code is data for the device test, and the remaining ten percent ofthe code realizes the test methodology.
• the device test data is DUT-dependent (e.g., power supply conditions, signal voltage conditions, timing conditions, etc.).
• the test code consists of methods to load the specified device conditions on to ATE hardware, and also those needed to realize user-specified objectives (such as datalogging).
• the framework of an embodiment ofthe invention provide a hardware-independent test and tester object model that allows the user to perform the task of DUT test programming.
• test code may be made independent of any device-specific data (e.g., pin name, stimulus data, etc.), or device-test-specific data (e.g., conditions for DC units, measurement pins, number of target pins, name of pattern file, addresses of pattern programs). If code for a test is compiled with data of these types, the reusability ofthe test code would decrease. Therefore, according to an embodiment ofthe invention, any device-specific data or device-test-specific data may be made available to the test code externally, as inputs during code execution time.
• device-specific data e.g., pin name, stimulus data, etc.
• device-test-specific data e.g., conditions for DC units, measurement pins, number of target pins, name of pattern file, addresses of pattern programs.
• a Test Class which is an implementation of a standard test interface, denoted here as ITest, realizes the separation of test data and code (and hence, the reusability of code) for a particular type of test.
• ITest a standard test interface
• Such a test class may be regarded as a "template” for separate instances of itself, which differ from each other only on the basis of device-specific and/or device-test-specific data.
• Test classes are specified in the test plan file.
• Each Test class typically implements a specific type of device test or setup for device test.
• an embodiment ofthe invention may provide a specific implementation ofthe ITest interface, for example, Func ionalTest, as the base class for all functional tests for DUTs.
• ACParametricTests ACParametricTests
• DCParametricTests DCParametricTests
• test types may provide default implementations of some virtual methods (e.g., init ( ) , preExec ( ) , and postExec ( ) ). These methods become the test engineer's entry points for overriding default behavior and setting any test-specific parameters. However, custom test classes can also be used in test plans.
• Test classes allow the user to configure class behavior by providing parameters that are used to specify the options for a particular instance of that test.
• a Functional Test may take parameters PList and TestConditions, to specify the Pattern List to execute, and the Level and Timing conditions for the test, respectively. Specifying different values for these parameters (through the use of different "Test" blocks in a test plan description file) allows the user to create different instances of a Functional Test.
• Figure 5 illustrates how different test instances may be derived from a single test class.
• These classes may be programmed directly in object-oriented constructs, such as C++ code, or designed to allow a test program compiler to take the description ofthe tests and their parameters from a test plan file and generate corresponding C++ code, which can be compiled and linked to generate the test program.
• a Template Library may be employed as the general-purpose library of generic algorithms and data structures. This library may be visible to a user ofthe tester, so that the user may, for example, modify the implementation of a test class to create a user-defined test
• an embodiment ofthe system supports integration of such test classes into the framework in that all test classes derive from a single test interface, e.g., ITest, so that the framework can manipulate them in the same way as the standard set of system test classes.
• a single test interface e.g., ITest
• Users are free to incorporate additional functionality into their test classes, with the understanding that they have to use custom code in their test programs to take advantage of these additional facilities.
• Each test site 110 is dedicated to testing one or more DUTs 106, and functions through a configurable collection of test modules 112.
• Each test module 112 is an entity that performs a particular test task.
• a test module 112 could be a DUT power supply, a pin card, an analog card, etc. This modular approach provides a high degree of flexibility and configurability.
• the Module Commands Implementation classes 248 may be provided by module hardware vendors, and implement either the module-level interfaces for hardware modules, or provide module-specific implementations of standard interfaces, depending on the commands implementation method chosen by a vendor.
• the external interfaces of these classes are defined by pre-determined module level interface requirements, and backplane communications library requirements. This layer also provides for extension ofthe standard set of test commands, allowing the addition of methods (functions) and data elements.
• the Backplane Communications Library 249 provides the interface for standard communications across the backplane, thereby providing the functions necessary to communicate with the modules connected to the test site. This allows vendor-specific module software to use a Backplane Driver 250 to communicate with the corresponding hardware modules.
• the backplane communications protocol may use a packet based format.
• Tester Pin objects represent physical tester channels and derive from a tester pin interface, denoted here as ITesterPin.
• the software development kit (SDK) of an embodiment ofthe invention provides a default implementation of ITesterPin, which may be called TesterPin, which is implemented in terms of a predetermined module-level interface, IChannel. Vendors are free to make use of TesterPin if they can implement their module's functionality in terms of IChannel; otherwise, they must provide an implementation of ITesterPin to work with their module.
• the standard module interface denoted here as -Module, provided by the tester system ofthe invention generically represents a vendor's hardware module.
• Vendor-supplied module-specific software for the system may be provided in the form of executables such as dynamic link libraries (DLLs).
• DLLs dynamic link libraries
• Software for each module-type from a vendor may be encapsulated in a single DLL.
• Each such software module is responsible for providing vendor- specific implementations for the module interface commands, which comprise the API for module software development.
• module interface commands serve as the interface for users to communicate (indirectly) with a particular hardware module in the system
• third-party developers can take advantage of to integrate their own modules into the site controller level framework.
• module interface commands provided by the framework are divided into two types:
• a tester pin interface provides methods to get and set level and timing values
• a power supply interface iPowerSupply provides methods for powering up and powering down, for example.
• the framework provides the special category ofthe predetermined module-level interfaces, which can be used to communicate with the modules. These are the interfaces used by framework classes (i.e., "standard” implementations of framework interfaces) to communicate with vendor modules.
• the use ofthe second aspect, the module-level interfaces is optional.
• the advantage of doing so is that vendors may then take advantage ofthe implementations of classes such as ITesterPin and IPowerSupply, etc. while focusing on the content of specific messages sent to their hardware by implementing the module-level interfaces. If these interfaces are inappropriate to the vendor, however, they may choose to provide their custom implementations ofthe framework interfaces (e.g., vendor implementations of ITesterPin, IPowerSupply, etc.). These would then provide the custom functionality that is appropriate for their hardware.
• the framework interfaces e.g., vendor implementations of ITesterPin, IPowerSupply, etc.
• the test environment comprises a set of files that specify the necessary conditions for bringing up the tester, and for preparing it to run a set of tests.
• the test environment preferably includes files for:
• Tester Resource definition for the specification ofthe types of tester resources
• Tester configuration for the specification of Site Controllers, sites and corresponding mappings.
• Module configuration for specification ofthe hardware module in each site .
• Pin descriptions for naming of DUT pins, such as signal pins, power supplies, and to describe pin groups, 5.
• Socket for the specification of DUT pin-to-tester pin assignments
• Pin options for the specification of special options, or modes, for pins.
• Pattern lists for the specification of test patterns and their sequence.
• items 1-3 are created by ICF (installation and configuration files) with information from a CMD (configuration management database), and made available at a well-known location, while items 4-8 are user-specified.
• ICF installation and configuration files
• CMD configuration management database
• items 4-8 are user-specified.
• This section provides descriptions for the items 1-6 above; items 7-8 are described in more detail in section E. Specific methods and rules are preferably used to develop each of these components; these methods and rules will be described in this section with examples. Al.
• Each hardware module provides one or more types of hardware resources (resources for short) for use by the test system.
• the tester Resource Definition is preferably used to declare a set of resource names for the available resource types, and a set of parameter names and types associated with each particular resource type.
• the resource name dpin is used to refer to digital tester pins.
• These resources have parameters such as VIL (for the input low voltage), VEH (for the input high voltage), VOL (for the output low voltage), VOH (for the output high voltage), etc.
• a resource definition file will have the extension ".rsc". Shown below is an example resource definition, containing some tester resources:
• # PRE_WAIT specifies the lime to wait after voltage # reached its final value to start pattern
• # POST_WAT ⁇ _MIN specifies the time to wait after pattern
• Time PRE_WAIT_MIN Time POST_WAIT; Time POST_WAIT_MIN;
• a resource parameter such as Voltage or Time
• Vendors supplying special purpose resources that prefer the specification of different parameters should provide their own resource definition files.
• resource-file version-info resource-defs
• resource-def resource-name ⁇ resource-params-decl-list ⁇
• resource-params-decl-list resource-params-decl resource-params-decl-list resource-params-decl
• resource-params-decl elementary-type-name resource-param-name-list ;
• resource-param-name-list resource-param-name resource-param-name-list , resource-param-name
• version-identifier A sequence of one or more characters from the set
• resource-name A sequence of one or more characters from the set [a- zA-Z_0-9], not starting with a digit. It represents the name of a resource, such as dpin or dps.
• elementary-type-name A sequence of one or more characters from the set [a-zA-Z_0-9], not starting with a digit. It represents the name of an elementary type, such as Voltage (cf.).
• resource-param-name A sequence of one or more characters from the set [a-zA-Z_0-9], not starting with a digit. It represents the name of a resource parameter, such as VIL.
• Tester Configuration is a set of rules that is preferably used to list the Site Controllers in a particular system configuration, and the connection ofthe Site Controllers to the Switch Matrix input ports.
• a single Site Controller can be connected to a single switch matrix input port.
• the switch matrix connections serve as implicit identifiers for the Site Controllers in the system (other configurations are possible).
• the following is an example of a typical tester configuration:
• the first field is the hostname ofthe Site Controller machine
• the second field is the switch matrix input port number, which # implicitly serves as the identifier for the Site Controller
• the system configuration for a particular test-floor system is part ofthe system profile, and is made available as the system configuration file Sys.cfg.
• the Site Controller connected to port 1 (“127.0.0.0" in the above example) may enjoy special status, in which it alone configures the Switch Matrix.
• This "special" Site Controller will be referred to as SITEC-1.
• the site controller address in this example is an IP address because the site controllers may be connected to the system controller by an internal network. Conversely, the system controller may be connected to an external network to access files, such as pattern data.
• system-conflg-file version-info
• system-conflg version-info
• version-identifier A sequence of one or more characters from the set [0-9a-zA-Z.]. It represents a version number.
• octet A nonnegative integer from 0 to 255 (in decimal notation).
• name A sequence of one or more characters from the set [a-zA-Z_0-9], not starting with a digit. It represents a name segment in a domain- qualified hostname.
• the Module Configuration allows the specification ofthe physical configuration ofthe tester, e.g., the physical location and type of each module in a SYSTEM chassis. This is necessitated by the dynamic nature ofthe tester bus configuration, which allows a mapping of the tester bus address to the physical slot location. This information allows a hardware discovery process that occurs at system boot-up time to validate the SYSTEM configuration.
• Each output port ofthe Switch Matrix defines a physical slot, which is preferably occupied by a single hardware module. Shown below is an example of a module configuration specified in the file Modules.cfg in accordance with an embodiment ofthe invention:
• MaxAvailable 16 # Resource units 1 .. 16.
• a slot refers to connector through which a hardware module can be connected, such as an output port ofthe switch matrix.
• Each configuration definition provides information about the module that may be attached to one or more slots.
• the VendorlD specified in a configuration definition is a unique ID associated with a vendor.
• the ModulelD refers to a type of module provided by this vendor. There may be several instances ofthe same ModulelD in a tester configuration.
• the ModuIeDriver refers to a vendor supplied DLL to service the module.
• the Resource refers to the units serviced by this module, and provides a name for the resource type; the resource name is obtained from the resource definition file.
• the above example describes three configuration blocks in a module configuration file.
• the first configuration block, slots 1 - 12 and 32 - 48 are serviced by a module produced by vendor 1.
• This vendor provides the module, the identifier "1" to refer to this module type, and the module driver library to control the module.
• This module can provide two types of resource units, one designated by the resource name "dpin”, with preferably a total number of 32 resource units (i.e., "channels"), all of which are available, and the other designated by the resource name "analog”, with a total number of 16 resource units, of which only 9 through 16 are available.
• the second and third configuration blocks are specified in a manner similar to the first configuration.
• a configuration block may have one or more slot identifiers. When a block has more than a single slot identifier, then the identified slots are said to be cloned.
• the module configuration file, Modules.cfg is created as part ofthe system profile by the ICM (installation configuration management system) (with test-floor-speeif ⁇ c information provided by the user), and made available at a well-known location.
• the ICM is a utility that can be local to the test system, e.g., on the system controller, or reside elsewhere on the network to which the system controller is connected.
• the ICM manages the CMD (configuration management database), and typically updated on hardware changes to the system configuration. ICM allows the user to configure the system, e.g., site controllers and modules.
• the CMD is a database that stores the configurations. For actual tester configuration/operation ICM generates the configuration files, e.g., module configuration, and other files, and copies them and associated files, such as particular module DLLs, onto the tester.
• file-contents version-info module-config-def version-info:
• slot-info required-config-list required-config-list: required-config required-config-list required-config required-config:
• version-identifier A sequence of one or more characters from the set [0-9a-zA-Z.], where the first character must be from the set [0-9].
• id-code A sequence of one or more characters from the set [a-zA-Z_0- 9].
• resource-name A sequence of one or more characters from the set [a- zA-Z_0-9], where the first character must be from the set [a-zA-Z].
• comments are supported; comments start with the '#' character, and extend to the end ofthe line.
• the DUT pin descriptions are described using a Pin Descriptions file.
• the user makes available a description ofthe DUT pins in a pin description file, which has the extension .pin.
• This plain text file contains, at least the following: a listing ofthe DUT pin names; and initial definitions of named pin groups, which make use ofthe defined DUT pin names ("initial" since they can be subsequently modified or added to, etc., programmatically).
• DUT pin and pin group definitions are encapsulated within resource type blocks, to allow the compiler to correlate pin and pin group definitions with the allowable parameter settings for Levels, etc.
• Pin groups and pins share the same namespace and have global (i.e., Test Plan) scope.
• Test Plan i.e., Test Plan
• One ofthe consequences of the global scoping of these names is that pins and pin groups cannot use duplicated names, even when declared in different resource blocks.
• At least one Resource definition is required in the pin description file.
• At least one pin name should be defined in each resource.
• Group definitions if given, should have at least one pin name or group name (i.e., a group definition cannot be empty).
• a pin group definition can include a reference to a previously-defined pin group.
• a pin group definition can include set operations such as addition and subtraction of previously defined pins and/or pin groups.
• Group pin-group-name ⁇ pin-group-def-item-list ⁇ pin-group-def-item-list: pin-def pin-group-def-item-list , pin-def
• version-identifier A sequence of one or more characters from the set [0-9a-zA-Z.]. It represents a version number.
• resource-name A sequence of one or more characters from the set [a- zA-Z_0-9] not starting with a digit. It represents the name of a resource, such as dpin or dps.
• pin-name A sequence of one or more characters from the set [a-zA- Z_0-9] not starting with a digit. It represents the name of a pin A0.
• pin-group-name A sequence of one or more characters from the set [a- zA-Z_0-9] not starting with a digit. It represents the name of a pin group ABUS. index: A nonnegative integer. It represents the lower bound or an upper bound on a group of related pins.
• the Socket specifies the mapping between DUT pin names and physical tester pin (channel) assignments (the physical tester channel numbers are defined in the module configuration file). Note that different Sockets can be used to support different DUT packages and different load board configurations, etc. For a multi-DUT system, the Socket definitions for DUT/channel assignments can support "cloning" of a basic Socket to multiple sites. However, different Sockets (i.e., different physical mappings for the same logical pins) should respect site module partitions. Thus, in addition to providing DUT pin to tester channel assignments, the socket also effectively defines the site partitioning. A Socket file could thus contain definitions for several individual site sockets. Shown below is a sample socket file defining three DUT sites:
• the CLK pin is assigned to resource dpin, 5 # slot 2, resource unit (channel) 13.
• the DIR pin is assigned to resource dpin, 10 # slot 5, resource unit 15.
• # BBUS[5] is assigned to the same slot 5, and to 20 # resource units 4, 5 and 6 respectively.
• the VI pin is assigned to resource dps, 30 # slot 1 , resource unit (channel) 1.
• VCC2 pin is assigned to resource dps
• the Socket file uses information from both module configuration file, and the user's pin description files for the given DUT types (see specification for PinDescription in the example above).
• the module configuration information is made implicitly available to the Socket file compiler.
• the socket file compiler is a sub-part ofthe pattern compiler that reads and analyzes the socket DUT name to tester channel mapping, and the module configuration and pin description files to set up the mapping of tester pins to DUT pins used by the pattern compiler. 2.
• At least one DUT site definition per DUT type is required, and it must use the full-specification syntax, as opposed to the SlotOffset syntax. If more than one DUT site definition is provided for the same DUT type, the first one must use the full-specification syntax.
• Each subsequent DUT site definition (for the same DUT type) may use either the full-specification syntax or the SlotOffset syntax, but not both. This allows individual sites to deviate from a standard pattern (due to, for example, inoperative channels).
• the bindings derived from the SlotOffset syntax are defined relative to the first site defined for that DUT type (which uses the full- specification syntax). 5. DUT sites do not need to be declared in the actual physical order. This allows a case where the first (physical) site deviates from the pattern.
• the DUT site IDs are required to be unique across the entire Socket (i.e., across all DUT types defined therein).
• At least one resource definition is required per DUT site definition.
• the site definitions must be used in conjunction with the module configuration to determine if the test configuration is single-site/single- DUT or single-site/multi-DUT.
• Socket file should specify a set of DUT channel mappings which are consistent with the pin description file and the module configuration file.
• DUT channels are disconnected from the tester (for example, by designating the assigned physical channel as one with the special ID "0.0").
• these DUT channels may be used and referenced in the context ofthe test program. Operations on such channels will result in system warnings (but not errors.).
• pattern data for disconnected channels will be discarded.
• socket-file version-info socket-def
• socket-def SocketDef ⁇ device-specific-socket-def-list ⁇
• device-specific-socket-def-list device-specific-socket-defi device-specific-socket-def-list device-specific-socket-def
• pin-description-file PinDesc pin-description-file-name ;
• dut-info-list dut-info dut-info-list dut-info
• site-controller-input-port SiteControIler switch-matrix-input-port-number ;
• resource-info-list resource-info resource-info-list resource-info resource-info:
• Resource resource-name resource-item-unit-assignment-list ⁇
• resource-item-unit-assignment-list resource-item-unit-assignment resource-item-unit-assignment-list resource-item-unit-assignment
• resource-item-unit-assignment resource-item-name slot-number .
• resource-unit resource-item-name [ resource-item-index ] slot-number .
• resource- unit-index resource-item-name [ resource-item-index-range ] ⁇ slot-number . [ resource-unit-index-range ] ;
• resource-item-index-range resource-item-index : resource-item-index
• resource-unit-index-range resource-unit-index : resource-unit-index
• version-identifier A sequence of one or more characters from the set [0-9a-zA-Z.]. It represents a version number.
• DUT-type-name A sequence of one or more characters from the set [0-9a-zA-Z.], where the first character must not be from the set [0-9].
• DUT DUT
• pin-description-file-name The simple name of a file, not including its directory name, but including all extensions.
• the filename is ofthe syntax recognized by the host operating system, and allows blanks and other characters if enclosed in quotes.
• switch-matrix-input-port-number A nonnegative integer in decimal notation to represent the port number ofthe input port connected to the Site Controller.
• dut-id A nonnegative integer in decimal notation to identify an instance of a DUT.
• resource-name A sequence of one or more characters from the set [0-9a-zA-Z.], where the first character must not be a digit. It represents the name of a resource defined in a resource file.
• resource-item-name A sequence of one or more characters from the set [0-9a-zA-Z.], where the first character must not be a digit. It represents the name of a resource unit, such as a pin or a pin group.
• resource-item-index A nonnegative integer in decimal notation that represents a particular member of a group of resource items. When in the context of a resource-item-index-range it represents the lower or upper bound of a contiguous sequence of resource item group.
• resource-unit-index A nonnegative integer in decimal notation that represents a particular member of a group of resource units (channels). When in the context of a resource-unit-index-range it represents the lower or upper bound of a contiguous sequence of resource unit group.
• a Pin Mode Option definition would support the configuration of special options or modes for a tester channel. This could, for example, be used to select and configure channel multiplexing. It is preferred that the Pin Mode Option only be used as part of a Test Plan initialization flow, since it might require significant channel configuration.
• the Pin Option syntax supports vendor-defined options. An example is shown below: PinModeOptions
• the resource definition file (Resources. rsc), the system configuration file (Sys.cfg) and the module configuration file (Modules.cfg) are preferably made available at a "well-known" location.
• This "well-known" location is the directory specified by the value ofthe system environment variable Tester_ACTIVE_CONFIGS. For example, if the value of Tester_ACTIVE_CONFIGS is the directory F: ⁇ Tester_SYS ⁇ configs, the system will expect the following files to be present:
• the Installation and Configuration Management system (ICM) residing on the host computer will preferably set the value of
• Tester_ACTIVE_CONFIGS Every time the ICM creates a new version of one ofthe above files, it will place the new version in the location pointed to by Tester_ACTIVE_CONFIGS. Note that in addition to the above three files, other system configuration files such as the simulation configuration file are also placed in the location pointed to by Tester ACTIVE CONFIGS.
• test environment One ofthe two principal end-user oriented components ofthe tester system is the test environment.
• the other component is the programming facility that the tester makes available for the end user (i.e., test engineer and test class developers).
• test plan uses test classes (which are different implementations of a test interface denoted Test), which realize the separation of test data and code for particular types of tests.
• the plan may be written directly as a C++ test program, or described in a test plan description file, which is processed by a Test Program Generator (translator 402) to produce object-oriented code, such as C++ code.
• the generated C++ code can then be compiled into the executable test program.
• the data required for populating a test class instance, such as levels, timings, etc., are specified by the user in the test plan description file.
• a test program contains a set of user written files that specify details for running a test on a device.
• An embodiment ofthe invention mcludes sets of rules that permit a user to write these files using C++ constructs.
• test program in accordance with the preferred embodiment ofthe present invention comprises a set of files as follows:
• files *.ph for a pre-header files for custom functions and test classes. files *.ctyp for custom types;
• a single test program will preferably comprise a single test plan file, and the files it imports.
• An "import" refers to other files with data that is either directly referenced by the importer (the file that specifies the import), or is imported by some other file directly referenced by the importer.
• the test plan file could define globals, flows, and other such objects within it, or it could import this information from other files. These rules allows any ofthe above components to be either in their own individual files, or directly inlined into a test plan file. Note that the test plan is similar in concept to a C-language main() function.
• Test Plan Test program identifiers preferably start with an upper or lower case alphabetical character, and can subsequently have any number of alphabetical, numerical, or underscore ( _ ) characters. It has several keywords which are provided in the description given below. These keywords are visually identified in code in this document using a bold font, such as Version. Keywords are reserved, and preferably not be used as identifiers. There are several special symbols such as ⁇ , ⁇ , (, ), :, and others which are described below.
• An import of a test description file enables the importing file to refer to names of objects made available by the imported file. This allows the importing file to reference the objects named by the imported file.
• a socket file aaa.soc that imports a pin description file xxx.pin.
• neither of these imports cause the objects described by xxx.pin to come into existence. They merely reference objects that are already assumed to exist.
• test plan mickey .tpl causes the objects in xxx.pin and aaa.soc to be elaborated:
• y has an import statement that names x;
• test program When a test program is compiled, it will elaborate all the objects in the files that are imported by the test plan.
• the set of files imported by a test plan are topologically sorted to yield an order in which the files are elaborated.
• the set of files imported by a test plan is referred to as the import closure ofthe test plan. If the import closure of a test plan cannot be topologically sorted, then there must be an imports cycle. Such a situation is erroneous, and will be rejected by the compiler.
• Constants are objects whose value is bound at compile time, and cannot be changed. The maximum integer value, for instance, would be a constant.
• the expression bound to variables can change at runtime via an API.
• the types Integer, Unsignedlnteger, Double, and String are referred to as Basic Types.
• the Basic Types have no measurement units.
• the Elementary Types which are not basic types are a Double, with an associated measurement unit and a scale.
• the scaling symbols are common engineering scaling symbols:
• constants should not be changed once they are defined.
• the expression bound to a constant can involve previously defined constants and literal values.
• Variables on the other hand, can be changed via an API.
• the expression bound to a variable can involve previously defined variables, constants and literal values.
• Each variable is bound to an expression object which is maintained at runtime. This provides the capability of changing the expression associated with a variable at runtime, and then re-evaluating all the variables.
• the expression object is a parsed form ofthe right hand side of a variable or constant definition. In one embodiment, no facility is provided for the changing of constants at runtime. Their value is preferably fixed at compile time.
• Const Time ClkTick 1.0ns; # 1 nanosecond
• Const Resistance R10 10.0 kOhms; # 10 kilo Ohms
• the compiler preferably checks that units and types match up. Note that since a Voltage times a Current yields a Power, the equations for PLow and PHigh above will compile. However, a statement such as the following will typically not compile: #
• Double Z Pyyy; # Pyyy gets converted to a unitless Double Explict type conversion to Double, Unsignedlnteger and Integer is also permitted:
• the TestPlan object provides a UserVars class which is a collection that contains names and their associated expressions, values, and types. User variables can go into a Default User Variables Collection, or into a Named User Variables Collection.
• Integer Y Maxlnteger - X;
• Integer Y2 Maxlnteger - X; ⁇
• a name is qualified — i.e., a name comprises two segments separated by a dot — then the variable comes from a named user variables collection, named by the segment that precedes the dot. So, MyVars.X above refers to the X in the MyVars collection. The name "_UserVars" can be used to explicitly denote the default user variables collection.
• the name If the name is not qualified, and there is a constant or variable of the same name in the present collection, then the name resolves to that constant or variable.
• Evaluation of a block of definitions in a UserVars collection can be thought of happening sequentially, from the first definition to the last. This may require each variable being defined before it is used.
• a UserVars collection uses a variable from another collection, it preferably uses just the raw value ofthe variable. No dependency information is maintained between collections. Thus, dependency based re-evaluation can be limited to a single collection.
• Each user variables collection refers to an instance of a C++ UserVars class.
• the default object ofthe C++ UserVars class is named "JUserVars".
• Variables in an UserVars declaration that is unnamed are from the default user variables collection, and are added to this default object.
• Variables in a named user variables collection are added to an object ofthe C++ UserVars class having that name.
• the "MyVars" C++ object will end up having the variables X, Y and Z.
• User variables are implemented as a collection of w-tuples having the name string, a const/var boolean, the type as an enumerated value and the expression as an expression tree.
• the expression of a name can be set by a call: enum ElemenaryType ⁇ UnsignedlntegerT, IntegerT, DoubleT, VoltageT, ... ⁇ ;
• the Expression class preferably has constructors that represent the parsed form ofthe expression.
• Expression has several constructors, including one that takes a string literal and parses it, and another that takes a string literal to use just as a string literal. These are distinguished by additional parameters which are not specified above for the sake of readability.
• User variables in the default user variables collection will be managed by the _UserVars object of class UserVars.
• User variables in a named user variables collection Xxx will be managed by a UserVars object named Xxx.
• the C++ UserVars class that contains these names and expressions exports an application programming interface (API) to evaluate and modify these values at runtime. Modification ofthe expressions associated with UserVars also addresses the issue of when the UserVars will be reevaluated, and what the impact of the evaluation will be.
• API application programming interface
• UserVars Collection Re-evaluation is re-evaluation limited to a single UserVars collection. The semantics of this operation is to re-evaluate all the variables of this collection once again.
• UserVars Targeted Re-evaluation is re-evaluation limited to a change to the expression bound to a single name. This would enable the user to change the expression of a single name, and cause the re-evaluation ofthe collection to take place, taking into consideration only this particular change.
• User Vars Global Re-evaluation is re-evaluation of all UserVars collections. This basically triggers a re-evaluation of all the UserVars collections in declaration order and is quite costly.
• Dependent objects will have a dirty bit that represents that it needs re-evaluation. Any time a UserVars collection is programmatically changed, it will also set the dirty bit on all dependent objects. This will trigger re-evaluation of the dependent objects.
• UserVars would be to only use the default UserVars collection. That way, the ripple effect of making a change can happen to all UserVars. This ripple effect can be limited by having several named UserVars collections.
• Multiple collections can refer to variables from one another, but the values bound to the variables are bound at time of use. No dependency is maintained between UserVars collections.
• the setExpression() call can fail if the expression results in a circular dependency. For instance if the following two calls were made, the second call would fail with a circular dependency failure setExpression("X”, true, IntegerT, Expression("Y+l")); setExpression("Y", true, IntegerT, Expression("X+l”));
• this API does not typically support unsolicited re-evaluation.
• a call to setExpressionQ may not automatically cause the variable, and all other variables that depend on it, to be re-evaluated. The values bound to all variables will stay unchanged until a call to reevaluateCollection() (below) occurs.
• the class will maintain equations related to all the variables, and their dependencies. When this method is called, all ofthe variables will get re-evaluated.
• the UserVars Targeted Re-evaluation method The UserVars Targeted Re-evaluation method.
• the class will maintain equations related to all the variables, and their dependencies. When this method is called, the named variable, and all of its dependents will get re-evaluated.
• a method to determine if a particular name is defined:
• the Specification Set is used to supply a collection of variables which can take on values based on a Selector. For example, consider the following Specification Set that uses selectors Minnie, Mickey, Goofy and Daisy: # File Aaa.spec #
• Maxlnteger - xxx - 1 Maxlnteger - xxx - 2
• # value which will be chosen regardless ofthe # selector. It is equivalent to:
• a specification set a is list of selectors (Minnie, Mickey, Goofy and Daisy in the example above), along with a list of variable definitions (xxx, yyy, zzz and www in the example above).
• the definition of a variable involves a list of expressions that is either as long as the list of selectors, or comprises a single expression.
• a specification set can be thought of as a matrix of expressions, whose columns are the Selectors, whose rows' are the variables and whose entries are expressions.
• a particular selector (column) binds each variable (row) to a specific expression (entry). If the list has a single expression, it represents a row with the expression replicated as many times as there are selectors.
• Specification sets can appear in two separate contexts. They could be separately declared in a .spec file, in which case they appear as shown above. These are named specification sets. Otherwise, local specification sets can be declared within a Test Condition Group. In such a declaration, the specification set will not be provided with a name. It will be a local specification set, of significance only to the enclosing test condition group.
• Named specification sets can be modeled after the named user variables collection.
• the above specification set can be modeled as a UserVars collection named Aaa, which will have expressions for xxx[Minnie], xxx[Mickey] 5 xxx[Goofy], xxx[Daisy], yyy [Minnie], and so on.
• Aaa UserVars collection
• a particular selector say Mickey
• the values of xxx, yyy and zzz are obtained from the variable name and the specification set name.
• a test condition group can have at most one specification set, which is either a local specification set, or a reference to a named specification set. Local specification sets appear only in the context of a test condition group, and have no explicitly specified name. Such a specification set has an implicit name that is defined by the name ofthe enclosing test condition group. To resolve a name in a test condition group at a point where several specification sets and several UserVars collections are visible, the following rules are applied: 1. If the name is qualified, it must be resolved in a named user variables collection.
• the name is resolved in either a local specification set, if it is declared in the test condition group, or in the named specification set, if one is referenced in the test condition group.
• VInLow refers to VInLow from MyVars.
• Specification sets can be implemented by the C++ SpecificationSet class.
• the SpecificationSet class has essentially the same API as the UserVars class, except for an extra String parameter for the selector. Consequently, this API is not described in detail.
• All named specification sets are preferably associated with a C++ object of that name.
• a local specification set in the context of a test condition group will have a name that is unique to that test condition group. It is illegal to refer to a variable of a local specification set outside the context ofthe test condition group that it is defined in.
• the Levels are used to specify parameters of pins and pin groups. It is a collection of declarations ofthe form:
• Such a declaration specifies the setting ofthe various parameters ofthe named pin or pin-group.
• such a statement could be used to set the YEL values for all pins in the InputPins group, as shown in the example below:
• Import pentium3resources.rsc Import pentium3pins.pin;
• # Pin parameters will be set in order from
• VIL v_il
• VIH v_ih + 1.0
• # pin group have special parameters:
• # PRE_WAtT specifies the time to wait after voltage # reached its final value to start pattern
• # POST_WAIT specifies the time to wait after pattern
• VCC Slew(0.01, 2.0 V); ⁇
• each Levels block is preferably made up of a number of levels items, each of which specifies parameters for a pin or pin group.
• Each levels item can specify a number of resource parameters.
• the runtime semantics for the setting of these levels values is as follows: The levels items ofthe Levels block are processed in declaration order. Any pin that occurs in more than one levels item will get processed multiple numbers of times. Multiple specification of values for a single parameter should be maintained and applied in specification order.
• the resource parameters in a levels item are processed in the order they are specified.
• the Delay statements cause the process of setting levels to pause for approximately the indicated duration, prior to setting the next group of levels.
• the Delay statements divide up the Levels specification into a number of subsequences, each of which will require separate Test Condition Memory settings for processing.
• the MinDelay statements cause the process of setting levels to pause for at least the specified duration prior to setting the next group of levels.
• MinDelay statements divide up the Levels specification into a number of subsequences, each of which will require separate Test Condition Memory settings for processing.
• Each pin or pin-group name is specified in exactly one resource in a pin description file (suffix .pin), and therefore has a certain set of viable resource parameters specified in the resource file (suffix .rsc). All the parameters named must be from among this set of viable resource parameters, and must be ofthe same elementary type as the expression used to set their value. Information about the names and types of resource parameters comes from the resource file.
• the resource file Resources.rsc is implicitly imported, providing tester with the names and types for parameters of standard resources such as dpin, and dps. Resource parameters are assigned expressions that can use UserVars, and values from named specification sets or a currently visible local specification set.
• Dps pin resources have special parameters PRE_WAIT and POST_WAIT.
• the PRE_WAIT parameter specifies the time that needs to elapse from the time the power pin has reached its destination voltage to the time pattern generation can start.
• the POST_WAIT parameter specifies the time that needs to elapse from the time pattern generation has stopped to the time the power pin shuts off.
• Dps pins also specify how the voltage parameter reaches its final value. They could specify it simply by an equation, as all other pin parameters. In that case the value will be reached as the hardware allows it. They could also specify it using a Slew statement.
• a Slew statement specifies that the power supply voltage reaches its final value from the initial value in a ramp with a specified absolute Voltage Slew Rate.
• This operation binds an expression to a parameter of a pin or a pin group.
• the dpin.InPins VIH value is set by: setParameter("InPins", “VIH”, VoltageT, Expression("v_ih + 1.0"); This operation will be called several times for all the declarations in the Levels object.
• Test Condition Group Sub-language packages together the description of specifications, timings and levels. Timing objects are often specified using parameters. Parameters can be used in timings to specify leading and trailing edges of various pulses. Likewise, Levels can be parameterized by specifying maximum, minimum and typical values of various voltage levels.
• TCG Test Condition Group
• a TestConditionGroup declaration contains an optional SpecificationSet.
• the SpecificationSet declaration may be an inlined (and unnamed) local SpecificationSet, or it may be a reference to a named SpecificationSet declared elsewhere.
• the optional SpecificationSet declaration in a TCG declaration is followed by at least one Levels or Timings declaration. It can have both Levels and a Timings, in any order. However, it is disallowed from having more than one Levels and Timings declaration. These restrictions are syntactically enforced.
• Timings declaration comprises a single declaration of a Timings object from a specified timings file.
• a file with a test condition group is an example of a file with a test condition group:
• # The specification set specifies a table giving values for # variables that can be used in expressions to initialize
• Time t_le 1.0E-6 uS
• # Refers to file timingl .tim containing the single # timing Timingl .
• the filename should be quoted if
• Timings Timingl
• Time clock e 10.00 uS, 10.02 uS, 10.01 uS
• Time clockje 20.00 uS, 20.02 uS, 20.01 uS
• Timing is from the file "timing2.tim”. The timings
• the test condition group TCGl describes a specification set with three selectors named "min”, "typ” and "max”. There can be any number of distinct selectors.
• variables y_il, v h, t e and tje are initialized with triples of values, corresponding to the selectors. So in the above example, an instance of TCGl with the selector "min” will bind the variable v l with the first numeric value, (vInputLow+0.0). It bears repetition that the selectors for a specification set are user defined, and any number of them is allowed. The only requirement is that:
• the selectors of a specification set be unique identifiers. Each value specified in the specification set is associated with an array of values that exactly the same number of elements as the set of selectors. Picking the I th selector will cause each value to be bound to the z - h value of its associated vector of values.
• Levels declaration is used to set levels for various pin parameters.
• the variables identified in the specification set will be used to set these levels, permitting a dynamic binding of different actual values for pin parameters based on the selector used to initialize the TCG.
• VIL v_il
• VIH v h + 1.0
• Timings object can be initialized based on the selected values ofthe specification set variables. It is not necessary to have both a Timings and a Levels declaration. Either can be present by itself, or both in any order, as illustrated by the following example:
• Time tje 0.9E-3, 1.1E-3, 1.0E-3;
• Timings there should not be more than one Timings and more than one Levels in a TCG. Thus, in summary, there should be at least one of Timings or Levels, and at most one of each. Test Conditions
• TestCondition object ties a TCG to a specific Selector. Once a TCG has been declared as shown above, it is possible to declare TestCondition objects as shown below:
• TestConditionGroup TCGl ;
• TestCondition TCMin
• the name is qualified (cf. page), it must be resolved in a named user variables collection. 2. If the name is not qualified, the name is resolved in either a local specification set, if it is declared in the test condition group, or in the named specification set, if one is referenced in the test condition group.
• Test condition groups have the following runtime semantics:
• a Test (such as a FunctionalTest) will reference a TCG with a particular selector from its SpecificationSet, using an instantiated TestCondition. This selector will bind each variable in the SpecificationSet to its value associated with the chosen selector. This binding of variables to their values will then be used to determine Levels and Timings.
• Parameter Levels in a TestConditionGroup are preferably set sequentially, in the order of presentation in the Levels block. So in the Pentium3Levels block, the order in which parameter levels would be set is as follows (notation: ⁇ resource-name>. ⁇ resource-parameter>):
• This sequencing order enables the test writer to control the explicit power sequencing of power supplies. Furthermore, if a levels item occurs twice, naming the same pin- parameters for a pin, then that pin-parameter gets set twice. This can happen programmatically also.
• VCC SIew(0.01, 2.0 V); it means that VCC will reach its final value of 2.0 volts from its present value in a ramp with a Voltage Slew Rate of ⁇ 0.01 volts per second.
• Timings object in the TCG.
• the Timings object will then be initialized based on the selected variables.
• Such a mechanism could be used to customize a Timings object, as, for instance, by specifying leading and trailing edges of waveforms.
• Test Condition Group can be declared in a C++ TestConditionGroup class, and initializing it as follows:
• TestConditionGroup which will set the specification set for the TestConditionGroup. This may either be a local specification set, or a named specification set, or null (if there is none).
• Levels object which will set the Levels object for the TestConditionGroup. This may either be a locally declared levels object, or an externally declared levels object, or null (if there is none).
• the Bin Definitions class defines bins, a collection of counters that summarize the results of testing many DUTs. During the course of testing a DUT, the DUT can be set to any bin, e.g., to indicate the result of a particular test. As testing proceeds, the DUT may be set to another bin. The bin that the DUT is finally set to is the last such setting at the end ofthe test. The counter for this final bin is incremented at the end ofthe test of this DUT.
• a separate file with bin definitions should have the suffix .bdefs. Bin definitions are preferably hierarchical. For example, at an outermost level, there may be the PassFailBins with two bins named Pass and Fail.
• HardBins some of which map to the Pass bin, and others which map to the Fail bin.
• the HardBins are said to be a refinement ofthe PassFailBins.
• SoftBins a refinement of HardBins, many of which map to the same Hard bin.
• LeakageFail "DUTs failing leakage"
• HardBins are a refinement of HardBins. BinGroup SoftBins : HardBins ⁇
• BinGroup X is said to be a group of base bins if some other BinGroup is a refinement of X.
• the BinGroup HardBins is a group of base bins since the BinGroup SoftBins is a refinement of HardBins.
• the bins of SoftBins are referred to as leaf bins.
• a BinGroup Y is said to be a group of leaf bins if no other BinGroup is a refinement of Y.
• BinGroup Z Z to be a group of most base bins, as well as a group of leaf bins.
• BinGroup names are global in scope. There can be any number of BinDefs blocks, but the declared BinGroups must be distinct. A BinGroup from one BinDefs block is allowed to be a refinement of a BinGroup from another BinDefs block. So in the above example, SoftBins could be in a separate BinDefs block from HardBins. However, it is strongly recommended to have a single BinDefs block with all the BinGroups defined for the sake of readability.
• HardBins are a refinement ofthe PassFailBins, # as indicated by "HardBins : PassFailBins".
• HardBins are a refinement of HardBins. BinGroup SoftBins : HardBins
• BinGroup PassFailBins are typically not a refinement of any bins.
• the BinGroup HardBins are a refinement ofthe PassFailBins and are also base bins.
• SoftBins are a refinement ofthe HardBins, and are a group of leaf bins. The above example had only tliree BinGroups in the hierarchy. Below is a more complicated hierarchy:
• Ax and Ay are refinements of A
• Axx is a refinement of Ax
• Ayy is a refinement of Ay.
• This example also provides BinGroups B and Bx where Bx is a refinement of B.
• the BinDefs declaration above with the BinGroups named PassFailBins, HardBins and SoftBins will be used as a continuing example in this section.
• Each bin in a BinGroup has:
• BinGroup the name ofthe bin it is a refinement of, also known as the base bin.
• Bin names may be a literal string, or an identifier. Bin names must be unique in a BinGroup, but may be duplicated across BinGroups. BinGroup names, however, are global in scope, and must be unique across a test plan.
• the bins "3GHzPass” and “2.8GHzPass” both map to the "Pass" bin ofthe PassFailBins.
• the rest ofthe HardBins map to the "Fail" bins ofthe PassFailBins.
• runtime When the test completes, runtime will increment the counter ofthe final bin assignment ofthe DUT, and for all other bins it is a refinement of.
• a SetBin statement is allowed only on a leaf bin. It is illegal to set a base bin.
• the counter incrementing semantics above assures that: 1. If the bin is a leaf bin, it is the number of times a SetBin statement was executed for this bin at the end of testing a DUT.
• the bin is a base bin, it is the sum ofthe counters ofthe bins that it is a refinement of. Thus, in the above example, only SoftBins are allowed in a SetBin statement.
• a BinDefinitions declaration is comprised of several BinGroup declarations.
• Each BinGroup declaration has a name, an optional BinGroup name that it is a refinement of, followed by a block of bin declarations.
• Bin declarations comprise a name, followed by a description, optionally followed by the name of a base bin that this bin is a refinement of.
• Bin names can be a string literal, or an Id. The empty string should not be a valid bin name. Bin names should be unique among names in the BinGroup declaration, but the same name could be used in other BinGroup declarations.
• BinGroup declaration Xxx is a refinement of another BinGroup declaration Yyy
• all ofthe bin declarations in Xxx must declare the name of a base bin from Yyy.
• each ofthe bin declarations in SoftBins is a refinement of a bin of HardBins, since the SoftBins are declared to be a refinement of HardBins.
• a BinGroup declaration that is not a refinement of another BinGroup declaration, such as PassFailBins will preferably have Bin declarations that do not declare base bins.
• a bin Bbb has a set of bases which is the entire set of bins that Bbb is a refinement of. It is formally defined as follows:
• Aaa is the base bin of Bbb, then Aaa is in the set of bases of Bbb. 2. Any base of Aaa is also in the set of bases of Bbb. BinGroup names are global in a TestPlan. Bin names are local to a BinGroup. A SetBin statement is only allowed for a leaf bin. C++ for Bin Definitions
• BinGroup can be constructed for each ofthe BinGroup declarations in the BinDefs declaration.
• the class BinGroup will have a subclass LeafBinGroup.
• the operations of these two classes are the same, except that BinGroup: ncrementBin is a C++ protected operation, whereas LeafBinGroup: ⁇ ncrementBin is a C++ public operation.
• BinGroup a BinGroup or a LeafBinGroup which is not a refinement of any other BinGroup.
• TestPlan state will be include number of BinGroup members, one for each
• BinGroup declaration The C++ for the above BinDefinitions would be as follows:
• State for a TestPlan includes a m_pCurrentBinGroup which is initialized to the undefined BinGroup (NULL) and the m_currentBin undefined bin name (the empty string).
• NULL undefined BinGroup
• m_currentBin undefined bin name the empty string.
• test plan When the test plan completes execution, it will call m_pCurrentBinGroup->incrementBin(m_currentBin); causing this bin and all its base bins to have their counters incremented.
• the BinGroup counters are reset when the test plan is elaborated, but are not reinitialized each time a test is run.
• the counters can be reset by an explicit call to BinGroup:: resetBin.
• the test plan can be thought of as a main structure ofthe test program.
• the Test Plan can import files, as well as define similar constructs inline. Thus, it is possible to import a file given definitions of some globals, as well as declaring additional globals inline.
• a Flow encapsulates a finite state machine. It comprises several Flowltems which run an IFlowable object and then transition to another flow item. Running an IFlowable involves running an object that implements the IFlowable interface. Typical objects that implement the IFlowable interface are Tests and Flows themselves.
• a Flow has Flowltems which runs Tests and other Flows, and then transition to another Flowltem. It also provides for the opportunity to call user customized routines on various return results from running an IFlowable.
• a Flow thus has the following form:
• the first two Result clauses handle 0 and 1 respectively, and the third handles all the rest ofthe result values.
• FlowTestl will, on a successful run, run a device through the minimum, typical and maximum versions of Testl, and then return.
• FlowTest2 will operate in a like manner.
• a Flow as described above basically describes a Finite State Machine with states and transitions.
• the Flowltems are basically states, which will do the following:
• IFlowable (it could be a previously defined Flow, or a Test, or a user defined Flow that can be implemented in C++ with the above rules).
• a Flowltem has the following components:

Landscapes

• Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• Manufacturing & Machinery (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Power Engineering (AREA)
• Tests Of Electronic Circuits (AREA)
• Test And Diagnosis Of Digital Computers (AREA)
• Non-Volatile Memory (AREA)

Priority Applications (15)

Applications Claiming Priority (8)

Publications (1)

Family

ID=32872965

Family Applications (2)

Family Applications After (1)

Country Status (8)

Cited By (16)

Families Citing this family (24)

Citations (3)

Family Cites Families (3)

• 2004
  • 2004-02-13 TW TW093103547A patent/TWI344595B/zh not_active IP Right Cessation
  • 2004-02-16 JP JP2006502670A patent/JP3939336B2/ja not_active Expired - Fee Related
  • 2004-02-16 KR KR1020057015016A patent/KR20050101216A/ko not_active Ceased
  • 2004-02-16 JP JP2006502669A patent/JP3954639B2/ja not_active Expired - Fee Related
  • 2004-02-16 WO PCT/JP2004/001649 patent/WO2004072670A1/en not_active Ceased
  • 2004-02-16 KR KR1020057015017A patent/KR20050099626A/ko not_active Ceased
  • 2004-02-16 EP EP04711445A patent/EP1592975B1/en not_active Expired - Lifetime
  • 2004-02-16 EP EP04711471A patent/EP1592976B1/en not_active Expired - Lifetime
  • 2004-02-16 DE DE602004011320T patent/DE602004011320T2/de not_active Expired - Lifetime
  • 2004-02-16 AT AT04711471T patent/ATE384269T1/de not_active IP Right Cessation
  • 2004-02-16 WO PCT/JP2004/001648 patent/WO2004072669A1/en not_active Ceased
  • 2004-02-16 CN CN2004800096901A patent/CN1784609B/zh not_active Expired - Fee Related
• 2006
  • 2006-09-19 JP JP2006252498A patent/JP2007052028A/ja not_active Withdrawn

Patent Citations (3)

Also Published As

Similar Documents

Legal Events