JP2009229304A - Test system and module control method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a test system wherein a module control driver or the like can specify a resource definition of a slave module including a relation between a resource and a port number, in module control of a mater-slave system. <P>SOLUTION: This system is equipped with a plurality of modules 108 capable of supplying a test signal to a device 112 to be tested; a module setting file 130 including information on respective resources and port numbers of the plurality of modules 108; and a module control driver 105 capable of specifying the relation between each resource and each port number of the plurality of modules 108 based on the information included in the module setting file 130, and controlling each resource of the plurality of modules 108 individually by utilizing each port number. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to the technical field of automatic test equipment. In particular, the present invention relates to a slave module control technique in an automatic test apparatus.

  Conventionally, automatic test equipment (hereinafter referred to as “ATE”) has been provided in the specifications of each ATE manufacturer, so the degree of freedom in the configuration of the pin configuration, measurement unit, etc. is low, and reuse of test program assets is possible. It was difficult. Against this background, an open architecture ATE having a standardized interface has been proposed in order to realize a scalable and flexible ATE that can change the system to an optimum configuration according to the function of the device.

For example, OPENSTAR (registered trademark) is one of such open architecture ATE standards (see Non-Patent Document 1). The OPENSTAR system aims to provide a scalable and flexible modular ATE platform, and has established a standard for it. A measurement device (module) provided by a third vendor or the like can be incorporated into the OPENSTAR system by satisfying the hardware and software requirements defined by the OPENSTAR standard.
“Semiconductor Test Consortium”, [online], [searched on March 24, 2008], Internet <URL: http://www.semitest.org/jp/home>

  By the way, in the standard of the conventional OPENSTAR system, it is assumed that a module control driver is provided for each module. However, when a plurality of common modules are incorporated into the system, it may be over-specific to control each of the plurality of common modules with different module control drivers. Therefore, there is a master / slave system module control method in which one of a plurality of common modules is a master module and the rest are slave modules, and the plurality of common modules are controlled by a module control driver provided in the master module. Are known.

  FIG. 10 is a block diagram showing a conventional module control method. FIG. 10A is a block diagram showing an example in which a module control driver is provided for each module based on the standard of the conventional OPENSTAR system. At this time, each module 108 includes a module control driver 105, and each module 108 is controlled by the corresponding module control driver 105.

  FIG. 10B is a block diagram showing an example of a conventional module control method using a master / slave method. In the figure, module A includes a module control driver 105 and functions as a master module 108M. Module B functions as a slave module 108S and does not include a module control driver. The module B is also controlled by the module control driver A.

  In the master / slave system, when viewed from the hardware side, the slave module 108S is an entity of a normal module connected to one bus port of a module connection enabler 106 described later. However, from the software side, the slave module 108S is hidden behind the master module 108M. That is, the slave module 108S does not have a module control driver, but leaves the control of the slave module 108S to the module control driver 105 of the master module 108M.

  FIG. 11 is a schematic diagram showing an example of the relationship between resources and port numbers in the conventional module control by the master / slave method. In the example shown in the figure, one master module 108M includes one slave module 108S, and each module includes a pin 128 connected to the load board 114. Each module has a port number used as an address in the system, the port number of the master module 108M is “10”, and the port number of the slave module 108S is “11”. .

  At this time, in the module control by the conventional master / slave system, the resource (port number and channel pair) of the slave module 108S is based on the port number “10” of the master module 108M, P10.9, P10. 10,..., P10.16. Thus, even if the resource is actually provided by the slave module 108S, in the conventional module control model, the slave module 108S defines the resource based on its own port number ("11" in this example). It is not allowed. As a result, in terms of software, the slave module 108S is treated as not existing from either the module control driver 105 or the site controller 104. That is, in the conventional module control model, the slave module 108S cannot be clearly distinguished from the master module 108M.

  Also, the resource settings are not fixed, and the system integrator can arbitrarily allocate resources. For example, in FIG. 11, the module having the port number “10” is the master module 108M. However, assuming that the module having the port number “11” includes the module control driver 105, the relationship between the master and the slave is shown in FIG. It is also possible to set the reverse of the example. At this time, the resources of each module are represented as P11.1, P11.9, and the like.

  As described above, in the conventional module control by the master / slave method, the slave module 108S is handled without being distinguished from the master module 108M by software, and resource allocation is arbitrarily performed. For this reason, the module control driver 105 cannot control a desired module unless the relationship between the resource and the port number of the module is known. That is, in the example shown in FIG. 11, the module control driver 105 cannot control each resource unless it knows the port numbers of the modules related to the resources P10.1 to P10.16. However, the relationship between each resource and the module port number is known only by the system integrator. Therefore, neither the module control driver 105 nor the site controller 104 can know the relationship between the resource and the port number unless the relationship between the resource and the port number is provided in some form to the ATE.

  The present invention has been made in view of such circumstances, and in master / slave module control, a module control driver or a site controller specifies a resource definition of a slave module including a relationship between a resource and a port number. It is an object to provide a test system that can

  Some aspects of the test system according to the present invention include a plurality of modules capable of supplying a test signal to a device under test, a module setting file including information on resources and port numbers of the plurality of modules, and a module setting file. A module control driver that specifies the relationship between the resource and port number of a plurality of modules based on the included information, and can individually control each resource of the plurality of modules using the port number; .

  Preferably, the plurality of modules include one master module and one or more slave modules, and the module control driver controls one master module and one or more slave modules.

  Preferably, the module setting file includes a port number of each module, information on whether each module is a master module or a slave module, and, if the module is a slave module, the module configuration file. Information about the master module.

  More preferably, an arbitrary identifier that can identify each of the plurality of modules is used instead of the port number. Moreover, it is preferable that the test system is a system based on an open architecture, and the two or more modules conform to a standard specification of the open architecture.

  Some aspects of the module control method of the test system according to the present invention include a test system including a plurality of modules capable of supplying a test signal to a device under test and a module control driver capable of controlling the plurality of modules. A module control driver that reads a module setting file including information on resources and port numbers of each of the plurality of modules, and identifies resource definitions of the plurality of modules based on the contents defined in the module setting file. And the module setting driver individually controls the resources of each of the plurality of modules using the port number.

  The program of the present invention causes a computer to execute each processing step of the inter-module communication method of the present invention. The program of the present invention can be installed or loaded on a computer through various recording media such as an optical disk such as a CD-ROM, a magnetic disk, or a semiconductor memory, or via a communication network.

  In the present specification and the like, “means” or “unit” does not simply mean a physical means, but also includes a case where the function of the means or unit is realized by software. Further, the function of one means or unit may be realized by two or more physical means, or the functions of two or more means or parts may be realized by one physical means.

  Further, in this specification and the like, hardware of a measuring instrument provided by a vendor or the like is referred to as a “module”, and software of the vendor or the like targeted for the hardware is referred to as “module software”.

  Furthermore, the reconfigurable open architecture ATE not only unifies the operation of the test system, but also the module that is optimal for the target test, along with the module software, can be plugged into the existing system by the user himself. Provide an installable platform. For module vendors, a development environment that enables development of such module software is provided.

  According to the present invention, in the module control of the master / slave method, the framework of the test system is extended so that the module control driver or the site controller can specify the resource definition of the slave module including the relationship between the resource and the port number. is doing. As a result, the resource definition can be set based on the port number of the slave module. Further, in the present invention, since the relationship between the port number of the slave module and the resource is described using the module setting file conventionally used for the resource description, the conventional resource description can be inherited, and the intuitive Is reasonable and reasonable.

  Hereinafter, embodiments of the present invention will be described in detail. In addition, the same code | symbol is attached | subjected to the same element and the overlapping description is abbreviate | omitted. Further, the following embodiments are exemplifications for explaining the present invention, and are not intended to limit the present invention only to the embodiments. Furthermore, the present invention can be variously modified and applied without departing from the gist thereof.

  FIG. 1 shows the system architecture of a test system 100 according to one embodiment of the invention. The test system 100 generates a test signal, supplies the test signal to a device under test (hereinafter referred to as “DUT”) 112, and the result signal output as a result of the DUT 112 operating based on the test signal matches the expected value. The quality of the DUT 112 is determined based on whether or not to do so. Note that although the test system 100 according to the present embodiment is described as being realized by an open architecture, the present invention is not limited to an open architecture test system.

  In this embodiment, a system controller (SysC) 102 is connected to a plurality of site controllers (SiteC) 104 via a network. The system controller 102 is a host computer on which an end user performs normal work, and plays a role of managing the entire test system 100. Further, the system controller 102 issues processing requests to the site controllers 104 and arbitrates processing between the site controllers 104. User applications and standard GUI tools operate on the system controller 102 and communicate with the site controller 104 to realize functions.

  The system controller 102 also includes storage for storing module software for controlling the module 108 on the site controller 104, user test programs, pattern programs, and the like. These are sent to the site controller 104 and executed as necessary.

  Each site controller 104 is connected to the module 108 through a module connection enabler 106 to control one or more modules 108 located at the test site 110 to perform tests. This test is executed based on a test program created by the user. Note that the site controller 104 may simultaneously control a plurality of test sites 110 that test one DUT 112.

  There are three main roles of the site controller 104 as follows. First, the module connection enabler 106 is configured according to the configuration of the test site 110 specified by the test program, and the connection of the bus 107 between the site controller 104 and the module 108 is established. Further, module software for controlling the module 108 in the test site 110 is executed. Further, the test program is executed, and the test of the DUT 112 at each test site 110 is executed.

  Depending on the operating environment, the system controller 102 can be arranged on a CPU (central processing unit) different from the operation of the site controller 104. Alternatively, the system controller 102 and site controller 104 can share a common CPU. Similarly, each site controller 104 can be located on its own CPU or as a separate process or thread within the same CPU.

  The module connection enabler 106 is a switch that can arbitrarily configure the connection of the bus 107 between the site controller 104 and the module 108. The module connection enabler 106 can change the configuration of the connected hardware module 108 and also serves as a bus for data transfer (for loading pattern data, collecting response data, controlling, etc.). . Possible hardware implementations include dedicated connections, exchange connections, bus connections, ring connections and star connections. The module connection enabler 106 can be implemented as a switch matrix, for example.

  The module 108 is hardware of a measuring instrument that supplies a test signal to the DUT 112. In the present embodiment, various modules based on an open architecture can be used as the module 108. Software for operating the module hardware 108 is referred to as module software. The module software includes a module driver that controls the module 108 at the time of device measurement, calibration diagnostic software that calibrates and diagnoses the module 108, emulation software that emulates the operation of the module 108 by software, and a pattern unique to the module 108. Includes compilers and GUI tools.

  Each test site 110 is associated with one DUT 112. The DUT 112 is connected to the module 108 of the corresponding test site 110 through the load board 114.

  FIG. 2 is a diagram illustrating an example of a relationship between the schematic hardware configuration of the test site 110 and the load board 114 and various setting files. As shown in FIG. 2, the module 108 is plugged into a module slot in the test head 132 of the test system 100.

  The configuration of the test site 110 is specified by a socket file 118 described in a text format. In this socket file 118, the connection between the DUT pin 122 of the DUT socket 120 and the connector pin 124 on the load board 114 is described for each DUT 112. The connector pin 124 has a block number and a connector number, and is expressed in a format of “(block number). (Connector number)”, for example, “12.3”. The connector pin 124 of the load board 114 is connected to the pin 128 of the module 108 via a tester interface unit (hereinafter referred to as “TIU”) 126.

  On the other hand, the load board 114 often differs depending on the device to be tested. Therefore, in order to prevent the module software from depending on the implementation of the individual load boards 114, the test system 100 can define the pins 128 themselves mounted on the module 108, and based on that, the module 108 can be defined. You must be able to control. In the test system 100, this is achieved by a module configuration file (hereinafter referred to as “MCF”) 130.

  In the MCF 130, a connection relationship between the resource of the module 108 and the connector pin 124 of the load board 114 is designated. As a result, the relationship between the resource, which is a logical pin expression, and the physical pin 128 of the module 108 and the connector pin 124 of the load board 114 to which it is connected is determined. It is desirable that the MCF 130 can be set only by the system.

  In the present embodiment, the function of the module 108 is mainly expressed by a module object that provides a function related to the overall control of the module 108 and a resource object that provides a function for each pin of the module. In the test system 100 according to the present embodiment, these are all connected symmetrically with the actual hardware entity according to the contents described in the MCF 130. The module software that provides these software objects is referred to as a module driver here.

  Further, in the present embodiment, a resource is an abstract representation of the physical pins 128 provided in the module 108 of the test system 100 and their functions using objects. One physical pin 128 of the module 108 may be expressed as one resource, or may be expressed as a plurality of functionally divided resources.

  The functional classification of a resource is called a resource type, and the definition of that function is indicated by a resource definition file provided by the module 108 vendor. A resource indicating a logical pin is a triple of a resource type, a number that identifies the pin 128 within the module 108 (resource ID), and a port number of the bus 107 that identifies the module 108 within the test system 100. It is expressed by Since the relationship between the resource type / resource ID pair and the corresponding physical pin 128 in the module 108 is fixed, when a resource is given, it can be associated with the physical pin 128. Become. Note that it is not essential for the architecture that the resource is associated with the physical pin 128, and the function of the module 108 can be expressed and controlled as if it were a virtual pin.

  FIG. 3 shows an example of the software architecture 200 of the test system 100. The software architecture 200 represents a distributed operating system, system controller software 220 (hereinafter also simply referred to as “system controller 220”), corresponding to the associated hardware system elements 102, 104, 108, at least one. It has components for site controller software 240 (hereinafter also referred to simply as “site controller 240”) and test head software 260 (hereinafter also referred to simply as “test head 260”) including at least one module. .

  As one exemplary choice, test system 100 may use Microsoft Windows® as the software platform and ANSI / ISO standard C ++ as the implementation language. All platform system interfaces are also provided as C ++ classes or interfaces, and user test programs and module software can be implemented in C ++.

  The system controller 220 is the primary interaction point for the user and provides a gateway to the site controller 240 and synchronization of the site controller 240 in a multi-site / DUT environment. User applications and tools, whether based on a graphical user interface (GUI) or not, are executed on the system controller 220.

  The system controller 220 also serves as a repository for all test plan related information, including test plans, test patterns and test parameter files. The memory for storing these files can be local to the system controller 220 or can be connected to the system controller 220 via a network.

  Further, the system controller 220 includes a framework class 221, a system tool 222, an external tool 223, a standard interface 224 to the site controller, and a communication library 230.

  A framework class 221 associated with the system controller 220 provides a mechanism for interacting with objects and provides a reference implementation of the standard interface 224. It also constitutes a software component that provides a gateway to the site controller 240 and provides synchronization of the site controller 240 in a multi-site / DUT environment. In effect, the framework class 221 can serve as an OS that supports the system controller 220.

  A third party developer can provide one or more tools 223 in addition to or in place of the standard system tools 222. The standard interface 224 on the system controller 220 includes interfaces used by those tools to access testers and test objects. Tools (applications) 222, 223 allow interactive and batch control of testers and test objects. The standard interface 224 includes an open interface to a framework object executed on the system controller 220, an interface that enables module software based on the site controller 240 to access and retrieve pattern data, and the like. .

  The communication library 230 residing on the system controller 220 provides a mechanism for communicating with the site controller 240 so that it is transparent to user applications and test programs.

  The site controller 240 is provided with most of the testing functions. The site controller 240 includes a test plan (test program) 241, a test class 242, a site controller framework class 243, a specific module extension interface 244, a standard interface 245, a module software implementation 246, a back A plane communication library 247 and a backplane driver 248 are included.

  The test plan 241 is described by the user. Test plan programs can be written directly in a standard computer language using object oriented components such as C ++, or in higher level test programming languages to generate C ++ code. Can be compiled into a test program that can be executed later.

  The test plan 241 creates test objects by using standard or user-supplied test classes 242 and / or framework classes 243 associated with the site controller 240 and uses standard interfaces 245 to install the hardware. Configure and define the test plan flow. Test plans support several basic services, provide interfaces to services for underlying objects, such as debug services (eg, breakpoint generation), and allow access to underlying frameworks and standard classes To.

  Test class 242 is one implementation of the standard test interface and is specified in the test plan program. Each test class typically implements a specific type of device test, or settings for device test.

  Framework class 243 is a set of classes and methods that implement common test-related operations. The framework class 243 can effectively serve as a local OS that supports each site controller 240.

  The module software is preferably in a DLL (Dynamic Link Library) format so that it can be dynamically loaded into the process of the test system 100 as needed when the test is executed. This is because the test system 100 dynamically determines the module 261 to be controlled at the time of execution according to the configuration of the test site 110 specified by the test plan 241. In addition, all module software is required to implement a module software standard interface 245 defined by the system OS in accordance with the function of the module 261.

  The specific module extension interface 244 is implemented by adding an interface hierarchy having more complicated and specialized functions specific to the module to the module software as necessary. For example, in C ++, an interface can be extended by defining an interface class that inherits the standard interface 245 with module software.

  The standard interface 245 is a minimum necessary general and universally applicable interface defined by the system framework. Using the standard interface 245, all objects can be handled uniformly. As a result, new module software can be seamlessly introduced into the system in a plug-and-play manner without changing the system OS.

  As an example, the standard interface 245 is defined as a C ++ pure virtual interface class. At this time, it is preferable to include a subclass that defines functions for users, a subclass that defines functions used only by the system, and a subclass that defines resource functions. In addition, the standard interface 245 layer introduces the concept of a layer that defines the most basic function of a module, a layer that represents a module that has the function of executing a pattern program, and a test cycle that is shared among multiple pins. Preferably, it is configured by four layers, that is, a layer to which functions specific to the digital module are added. At this time, each module driver is mounted with one of four layers of interfaces according to the function of the module. However, the configuration of the standard interface 245 is not limited to these configurations.

  The backplane communication library 247 provides an interface for standard communication across the backplane, thereby providing the functionality necessary to communicate with the module 108 within the test head 260. This allows vendor-specific module software to communicate with the corresponding module 108 using the backplane driver 248. The backplane communication protocol can use a packet based format.

  The test head 260 is provided with a measurement function for the device. The test head 260 includes a module 261, a TIU 262, a load board 263, and a DUT 264.

  Also, the software architecture 200 is based on a nominated source of software, a system framework 290, a user component 292, a tester operating system 294, a module hardware vendor component 296, and a tool software vendor component. 298.

  The system framework 290 is supplied by the development vendor of the test system 100 and includes a framework class 221, a standard interface 224, a framework class 243, a standard interface 245, and a backplane communication library 247.

  The user component 292 is supplied by the user performing the test and includes a test plan 241, a test class 242, a load board 263, and a DUT 264.

  The tester operating system 294 is supplied as a software infrastructure for basic connectivity and communication and includes a system tool 222, a communication library 230, and a backplane driver 248.

  The module hardware vendor component 296 is supplied by the module 108 developer and includes a specific module extension interface 244, a module software implementation 246, a module 261, and a TIU 262.

  The tool software vendor component 298 is supplied by an external tool developer and includes an external tool 223.

  Next, various setting files will be specifically described based on the schematic hardware configuration shown in FIG.

  FIG. 4 is a diagram illustrating an example of the MCF 130. The MCF 130 illustrated in FIG. 4 is an example in which the hardware schematic configuration illustrated in FIG. 2 is described. “OAI.Digital.dpin” following the “Resource” keyword is the name of the resource type. Further, the combination of the port number and the resource ID of the bus 107 is expressed in a format of “P (port number). (Resource ID)” (for example, “P8.1”).

  FIG. 5 is a diagram illustrating an example of the socket file 118. As shown in FIG. 5, in the test system 100 according to the present embodiment, the configuration of the module 108 and each test site 110 connected to each site controller 104 is determined by the socket file 118, and the module connection enabler 106 is reconfigured accordingly. Thus, the connection of the bus 107 between the site controller 104 and the module 108 and the control of the module 108 are established. Such a module configuration expression method and a high degree of freedom in the bus configuration greatly contribute to ensuring the modularity and scalability of the system, and support the realization of the plug and play of the module 108.

  FIG. 6 is a diagram illustrating a part of the definition of the resource type “OAI.Digital.dpin” illustrated in FIG. 2 as an example of the resource definition file. As shown in FIG. 6, resource attributes are specified by pairs of type and attribute name. For example, in FIG. 6, the attribute “VIH” has a type “Voltage”. The setting value for the resource attribute is specified in the form of “attribute name = value”, for example. In this way, the vendor can freely express the resource function by handling the resource function that strongly depends on the hardware of the module 108 in a very general expression format of name and type. The system framework can handle resources uniformly without depending on the function of the module 108. This realizes high applicability and flexibility of the system.

  Next, a module control method by the master / slave method using the test system 100 configured as described above will be described.

  FIG. 7 is a block diagram showing an example of a schematic configuration for realizing module control by the master / slave method according to the present invention. This figure shows an example in which a module A 108M that functions as a master module and a module B 108S that functions as a slave module are provided. In the present invention, the module control driver 105 controls the master module 108M and the slave module 108S. Therefore, not only resources provided by the master module 108M but also resources provided by the slave module 108S are defined and implemented by the module control driver 105.

  At this time, in the present invention, a master / slave definition unit 140 is newly provided in the MCF 130, and in this master / slave definition unit 140, the resource definition of the master module 108M and the resource definition of the slave module 108S are described. Characterized by points. The module control driver 105 reads the master / slave definition unit 140 in the MCF 130, identifies and implements the resource definitions included in the master module 108M and the slave module 108S. Here, the resource definition of the slave module 108S includes the relationship between the port number of the slave module 108S and the resource (such as the pin 128) provided by the slave module 108S.

  Thus, the module control driver 105 reads the MCF 130 and refers to the contents of the master / slave definition unit 140 to determine which module is the slave module 108S and can be controlled. It is possible to specify what kind of resource the module 108S provides, the control method of the slave module 108S, and the like.

  The conventional ATE includes a module setting file corresponding to the MCF 130 of the present embodiment. However, in the file, the slave module resource cannot be defined separately from the master module resource. Cannot specify the relationship between the port number of the slave module and the resource.

  Specifically, the master / slave definition unit 140 describes, for example, the port number of each module and whether or not the module is a slave module. In the case of a slave module, the port number of the module that functions as the master module of the slave module is associated. As a result, the relationship between the port number of the slave module 108S and the resource provided by the slave module 108S can be specified.

  For example, in the example shown in FIG. 7, in the master / slave definition unit 140 in the MCF 130, the port number of the module A is 10 (first line), and the port number of the module B is 11 (2 (Line), module B functions as a slave module (line 3), and the master module of module B is a module represented by port number 10 (line 4). .

  Note that all types of resources supported by the test system 100 are preferably specified by the master / slave definition unit 140.

  FIG. 8 is a schematic diagram showing an example of the relationship between resources and port numbers in module control by the master / slave method according to the present invention. In the example illustrated in FIG. 11, as in the example of FIG. 11, one master module 108 </ b> M includes one slave module 108 </ b> S, and each module includes a pin 128 connected to the load board 114. Each module has a port number used as an address in the system, the port number of the master module 108M is “10”, and the port number of the slave module 108S is “11”. .

  At this time, in the module control by the master-slave method according to the present invention, the resource (port number and channel pair) of the slave module 108S is P11.1 based on the port number “11” of the slave module 108S itself. , P11.2,..., P11.8. As described above, in the module control model according to the present invention, the resource of the slave module 108S can be defined based on the port number of the slave module 108S itself without being restricted by the port number of the master module 108M. it can. Since the resource of the slave module 108S is expressed based on the port number of the slave module 108S, the master module 108M can specify the port number of the slave module 108S to be controlled by referring to the resource. become able to. Therefore, the module control driver 105 or the site controller 104 can clearly control the slave module 108S from the master module 108M.

  FIG. 9 is a flowchart showing the flow of module control processing by the master / slave method according to the present embodiment. First, when a module 108 is newly incorporated into the test system 100 by a system integrator or the like (S301), the system integrator or the like obtains module information such as the port number of the incorporated module 108 and whether or not it is a slave module. Is newly written to the master / slave definition unit 140 in the MCF 130 (S302). Thereafter, the site controller 104 reads the MCF 130 at a predetermined time (S303), and implements the resource definition in the module control driver 105 based on the contents defined in the master / slave definition unit 140 (S304). In this way, the module control driver 105 can specify the relationship between the slave module resource and the port number.

  As described above, in this test system 100, the module resource definition is defined in the master / slave definition unit 140 in the MCF 130, and the site controller 104 reads the MCF 130 and defines it in the master / slave definition unit 140. Based on the contents, a resource definition for controlling the slave module is implemented in the module control driver 105. As a result, the module control driver 105 can specify not only the master module but also the relationship between the resource and port number of the slave module.

  The present invention is not limited to the above-described embodiment, and can be implemented in various other forms without departing from the gist of the present invention. For this reason, the said embodiment is only a mere illustration in all points, and is not interpreted limitedly. For example, the above-described processing steps can be executed in any order or in parallel as long as there is no contradiction in the processing contents.

  For example, in this embodiment, the relationship between the resource and the port number is exemplified as the resource definition of the slave module. However, any identifier that can uniquely identify the slave module can be used instead of the port number. Needless to say.

1 illustrates a system architecture of a test system 100 according to an embodiment of the present invention. It is a figure which shows an example of the schematic structure of the hardware of the test site 110 and the load board 114, and the relationship between various setting files. 1 shows an example of a software architecture 200 of a test system 100. 3 is a diagram illustrating an example of a module setting file (MCF) 130. FIG. It is a figure which shows an example of the socket file 118. FIG. FIG. 3 is a diagram illustrating a part of a definition of a resource type “OAI.Digital.dpin” illustrated in FIG. 2 as an example of a resource definition file. It is a block diagram which shows an example of schematic structure which implement | achieves module control by a master / slave system. It is the schematic which shows an example of the relationship between a resource and a port number in the module control by a master / slave system. It is a flowchart which shows the flow of the module control processing by a master / slave system. It is a block diagram which shows the conventional module control method. (A) is a block diagram showing an example provided with a module control driver for each module. (B) is a block diagram showing an example of a conventional module control method based on a master / slave system. It is the schematic which shows an example of the relationship between a resource and a port number in the module control by the conventional master / slave system.

Explanation of symbols

100 test system 102 system controller 104 site controller 105 module control driver 106 module connection enabler 107 bus 108 module 108M master module 108S slave module 110 test site 112 device under test (DUT)
114 Load board 118 Socket file 120 Socket 122 Pin 124 Connector pin 126 Tester interface unit (TIU)
128-pin 130 module configuration file (MCF)
132 Test head

Claims (8)

A plurality of modules capable of supplying test signals to the device under test;
A module configuration file including information on the resource and port number of each of the plurality of modules;
Based on the information included in the module setting file, the relationship between the resources of the plurality of modules and the port numbers can be specified, and the resources of the plurality of modules can be individually controlled using the port numbers. A module control driver;
A test system comprising: The plurality of modules include one master module and one or more slave modules,
The module control driver controls the one master module and the one or more slave modules.
The test system according to claim 1. The module configuration file is
The port number of each module,
Information about whether each module is a master module or a slave module; and
If the module is a slave module, information about the master module of the module,
The test system according to claim 2, comprising:   4. The test system according to claim 1, wherein an arbitrary identifier capable of identifying each of the plurality of modules is used instead of the port number. The test system is a system based on an open architecture,
The two or more modules conform to the standard specifications of the open architecture.
The test system according to claim 1, wherein: In a test system comprising a plurality of modules capable of supplying a test signal to a device under test and a module control driver capable of controlling the plurality of modules, a method for individually controlling resources of the plurality of modules. ,
Reading a module configuration file containing information on the resource and port number of each of the plurality of modules;
Identifying the resource definitions of the plurality of modules based on the contents defined in the module configuration file, and implementing them in the module control driver;
The module setting driver individually controlling each resource of the plurality of modules using a port number;
A module control method for a test system comprising:   A program for causing a computer to execute the module control method according to claim 6.   A computer-readable recording medium on which the program according to claim 7 is recorded.

Images