Automated test equipment, devices under test, and test setup methods using trigger lines

Abstract

An automated test apparatus for testing a device under test includes a trigger line controllable by the device under test (or equivalently by a test case that can be executed on the device under test, for example). The automated test apparatus is configured to update one or more tester resources in response to activation of the trigger line by the device under test (or equivalently by a test case that can be executed on the device under test, for example). A device under test, methods, and a computer program are also described.

Description

Technology Field

[0001] Embodiments according to the present invention relate to automated test equipment for testing one or more devices under test.

[0002] Further embodiments according to the present invention relate to a device under test.

[0003] Further embodiments according to the present invention relate to a test setup.

[0004] Further embodiments according to the present invention relate to a method for operating automated test equipment.

[0005] Further embodiments according to the present invention relate to a method for testing a device under test.

[0006] Further embodiments according to the present invention relate to computer programs.

[0007] Generally speaking, embodiments according to the present invention relate to the control of a production tester by on-chip system test. Background Technology

[0008] Automated test equipment (ATE) is a platform for production testing and post-silicon validation that utilizes rapid automated test case execution and flexible control of external test conditions for devices under test (DUT).

[0009] Production tests of digital integrated circuits were conventionally performed by structural tests on an ATE. Cycle-accurate input patterns are applied to the device under test (DUT), and faulty devices are detected by comparing the resulting output patterns with expected patterns.

[0010] The internal structure of DUTs is shifting to complex system-on-chip (SoC) devices that include many subsystems with multiple processors, memory, and peripheral units interconnected by network-on-chip fabrics. Even 99.5% coverage by structural tests results in millions of untested transistors in such SOCs, which has led to the introduction of on-chip system-test (OCST).

[0011] OCSTs are executed as real-time scenarios by embedded software on the processor environment of DUTs, and are narrowing test gaps by checking the functional performance of important use cases, including all subsystems of the SoC.

[0012] Legacy approach to uploading OCST / functional tests by test patterns

[0013] Below, the legacy approach to uploading OCST / functional tests by pattern testing will be described.

[0014] FIG. 4 illustrates a general approach for ATE systems to upload software (SW) of a functional test case (TC) to the memory of a device under test (DUT). The SW is uploaded by a sequence of cycle-accurate patterns applied to the memory interface on the DUT. The disadvantages are the time-consuming conversion of the SW code into pattern sequences and the limitation of the download speed by the maximum clock rate of the digital channels.

[0015] In conclusion, FIG. 4 illustrates OCST / functional test upload and control by test pattern. For example, automated test equipment (410) may include tester resources (420) combined with a workstation (422) that executes an ATE test program (424). For example, digital channels that may be part of the test resources may be used, for example, for pattern-based OCST upload and for control through the digital channels. That is, the digital channels may be used, for example, to upload a test program (e.g., an OCST test case (432)) to a device under test (430). For this purpose, the digital channels of the ATE may be programmed to provide patterns that control the upload of the program (e.g., an OCST test case) to the device under test. Furthermore, additional tester resources, such as, for example, digital channels and / or analog channels and / or supply lines, may be used to provide signals, for example, input signals and / or one or more supply voltages, to the device under test. Furthermore, the test resources (420) may also be used to receive one or more signals from the device under test (430) and to evaluate these signals from the device under test. For example, appropriate supply voltages may be provided to the device under test, and there may also be an interaction between the automated test equipment and the device under test using individual test resources. Furthermore, the test resources may also be used to evaluate the device under test by optionally performing measurements.

[0016] In conclusion, the uploading of OCST test cases can be performed by automated test equipment using appropriate tester resources, and there may be an interaction between the automated test equipment and the device under test using the tester resources of the automated test equipment.

[0017] OCST / Function Test Upload and Control via High-Speed ​​IO

[0018] Below, OCST / functional test upload and control by high-speed IO will be described.

[0019] The evolution of functional test case handling is the use of HSIO interfaces (e.g., USB, PCIe, ETH) of the device under test (DUT) in native mode. This means that, for example, test case software (SW) is now uploaded and, for example, is controlled by full protocol-supported high-speed interfaces rather than by cycle-oriented deterministic patterns. To support HSIO interfaces, drivers may need to be pre-installed on the device under test (DUT), and may need to be uploaded and enabled, for example, via JTAG.

[0020] FIG. 5 illustrates a schematic representation of functional test upload and control by high-speed IO. In this concept, for example, there may be automated test equipment (510) including tester resources (520) and a workstation (522). Furthermore, there may be a device to be tested (530). For example, an ATE test program may influence OCST-TC upload (e.g., on-chip-system-test test-case upload). Furthermore, the test program may also influence execution control. For example, both OCST-TC upload and execution control may be performed using high-speed input-output (HSIO), such as a Universal Serial Bus interface, a "peripheral component interconnect express" interface (PCIe), or via an Ethernet interface (ETH). Thus, a conventional protocol-based high-speed input-output interface may be used for uploading test cases (TC) and for controlling the execution of test cases. In this regard, it should be noted that the OCST test case (532) is typically software that is executed using the device under test (540) (or on the device under test (540)) (e.g., using one or more of the processors of the device under test (530)).

[0021] Additionally, the device under test (530) may be connected to tester resources (520), and, for example, digital channels and / or analog channels and / or supply lines may be used. For example, ATE control signals for DUT supply, test interaction, and measurement may be used. In other words, for example, the tester resources may include one or more device power supplies capable of providing one or more supply voltages to the device under test. Furthermore, the tester resources may include one or more digital channels for providing digital signals to the device under test and / or receiving digital signals from the device under test. For example, the automated test equipment (510) may use one or more digital channels for interaction with the device under test (530), and the automated test equipment (510) may optionally also use the digital channels to perform measurements. Furthermore, for example, the test resources (520) may include one or more analog channels that can be used to provide one or more analog signals to the device under test (530), for example, and / or receive one or more analog signals from the device under test (530). Furthermore, one or more analog channels may optionally also be used to perform measurements to evaluate the signals received from the device under test (530), for example.

[0022] In conclusion, OCST / function test upload and control by high-speed IO was described with reference to Fig. 5.

[0023] Figure 6 illustrates a schematic representation of the deformation by using individual controllers for OCST / function testing.

[0024] The arrangement (600) of FIG. 6 is an automated test equipment (610) including tester resources (620) and a workstation (622). Furthermore, in the test arrangement (600) according to FIG. 6, there is also a test target device (630) on which an OCST test case (632) can be executed.

[0025] However, in addition to the test arrangement (500) according to FIG. 5, the test arrangement (600) according to FIG. 6 includes an on-chip system test controller (640), which may be part of, for example, an automated test equipment (610). For example, the on-chip system test controller (640) may be coupled to a workstation (622) using, for example, a high-speed input-output interface (HSIO) (e.g., USB, PCIe, or ETH). For example, an ATE test program (624) running on the workstation (622) may communicate with the OCST controller (640) via an interface (e.g., via an HSIO interface) to initiate, support, or control OCST-TC upload and / or execution control. For example, the ATE test program may provide the OCST controller (640) with a representation of an OCST test case (TC) and may command the OCST controller (640), for example, to upload the OCST test case to the device under test (630). Subsequently, the OCST controller (640) may perform, for example, the upload of the OCST test case to the device under test (630). Furthermore, the ATE test program (624) may communicate with the OCST controller (e.g., via an HSIO interface) to control the execution of the test case. For example, communication between the ATE test program (624) and the OCST controller (640) may be bidirectional (e.g., as indicated by a bidirectional arrow). Furthermore, the OCST controller (640) may be configured to communicate with the OCST test case (632) running on the device under test (630) to control the execution of the test case. Communication between the OCST controller (640) and the OCST test case (632) can be bidirectional, for example (as indicated by the bidirectional arrow).

[0026] Furthermore, the function of the tester resources (620) may be similar to the function of the tester resources (520) of the test arrangement (500) described above. In other words, for example, the tester resources may include, for example, one or more device power supplies and one or more digital channels and / or analog channels. Thus, the tester resources (620) may be adapted to provide ATE control signals for DUT supply and for test interaction and measurement.

[0027] Accordingly, the device under test can be tested in the test arrangement (600). In conclusion, FIG. 6 illustrates a variation by using individual controllers for OCST / functional testing.

[0028] Furthermore, it should be noted that any of the features, functions, and details described in this section may be optionally used in embodiments according to the present invention (unless they conflict with the embodiments according to the present invention). It should be noted that such features, functions, and details may be introduced individually in any of the embodiments according to the present invention and may also be taken in combination.

[0029] However, considering conventional approaches, there is a need for a concept for testing the device under test that provides an improved trade-off between on-chip system test capabilities, on-chip system test development efforts, and implementation efforts.

[0030] An embodiment according to the present invention creates an automated test apparatus for testing one or more devices under test. The automated test apparatus is configured to receive a command (e.g., in the form of a message) requesting an update of one or more tester resources from a device under test (or equivalently from a test case). Furthermore, the automated test apparatus is configured to update one or more tester resources in response to a command provided by the device under test (or equivalently by the test case), and the automated test apparatus is configured to signal the completion of the tester resource update requested by the device under test by providing an acknowledgment signaling (or acknowledgment signaling) (e.g., an acknowledgment message) to the device under test.

[0031] This embodiment of the present invention is based on the finding that test case development and test case execution are significantly facilitated by using this concept. For example, by using this concept, the execution of a test case can be easily synchronized with the operation of an automated test machine without the need for specific adaptations of an ATE test program (which can be executed on the automated test machine). For example, a test case executed on a device under test can be programmed to provide a command requesting an update of one or more tester resources, and the test case executed on the device under test can also evaluate an acknowledgment signaling. However, because the evaluation of the command by the ATE can be a "standardized" process (e.g., identical for different test cases), and because the acknowledgment signaling can be a "standardized" response to a command requesting an update of one or more tester resources, the provision of the acknowledgment signaling by the automated test machine may not require specific adaptations of the automated test machine (or the ATE test program executed on the ATE) to the test case currently executed on the device under test. Therefore, when adding a command to issue a command requesting an update of one or more test resources to a test case to be executed on the device under test, it may not be necessary to perform any specific adaptations to the ATE test program. Consequently, since the adaptation (or update) of one or more test resources can be entirely under the control of the test case (for example, while the ATE and the test program executed on the ATE act merely as "slaves" executing commands provided by the test case), test development becomes considerably easier.

[0032] Furthermore, by providing acknowledgment signaling, the automated test equipment enables the device under test to operate synchronously with updates to tester resources. Consequently, the delay between a command requesting updates to one or more test resources and the actual completion of the tester resource updates—which is typically unknown to the device under test and, in some cases, may also be non-deterministic—can be easily managed by the device under test. Thus, signaling the completion of tester resource updates requested by the device under test by the automated test equipment through the provision of acknowledgment signaling makes it possible for verification engineers to design reliable test cases to be executed on the device under test without requiring detailed knowledge of the automated test equipment's functions or modifying the code of the automated test equipment test program. Consequently, the automated test equipment described herein enables the central design of test cases and also enables reliable and rapid execution of test cases on the device under test (e.g., by using acknowledgment signaling instead of adding unnecessary precautionary delays to wait for updates to tester resources).

[0033] In a preferred embodiment, the automated test equipment is configured to receive commands in the form of parameterized messages from a device under test (or equivalently from a test case), wherein the parameters of the message describe the desired settings of the tester resources (e.g., desired supply voltage, desired clock frequency, desired signal characteristics, etc.).

[0034] By providing automated test equipment with the capability to evaluate messages containing one or more parameters that have a predefined syntax and describe the desired settings of a tester resource, it may not be necessary to specifically adapt the ATE test program to the test of a specific target device. Rather, it is sufficient for the verification engineer to provide the capability to handle "standardized" parameterized messages (e.g., parameterized messages that follow a predetermined syntax and specify, for example, the tester resource to be modified and the desired new settings), while the verification engineer designing the test cases to be executed on the target device needs only to know the syntax of the commands that can be handled by the automated test equipment (e.g., the ATE test program of the automated test equipment), or even the syntax of the API function that generates the command. Thus, providing the capability to handle parameterized messages in the automated test equipment significantly facilitates test development and eliminates the need to specifically adapt the ATE test program to the test of a specific target device. Furthermore, verification engineers can also quickly and efficiently adapt test cases to be executed on the device under test to various desired settings of test resources.

[0035] In a preferred embodiment, the automated test equipment is configured to provide acknowledgment signaling in the form of messages. It has been revealed that the transmission of messages (e.g., messages having a predefined format including a message header, one or more bits identifying a command, one or more bits identifying a parameter, optional error correction information, and optional message terminator) can be efficiently performed through an interface between the automated test equipment and the device under test. For example, such transmission of messages can be efficiently performed through a high-speed interface (or HSIO interface) between the automated test equipment and the device under test. Furthermore, it has been revealed that, for example, the transmission of messages in a message format suitable for a specific interface type can be efficiently performed using interface drivers adapted to that specific interface type. Accordingly, a specific (e.g., high-speed) interface can be used, for example, for both the transmission of parameterized messages and the transmission of acknowledgment signaling, and also for other data exchanges between the automated test equipment and the device under test. Therefore, a specific interface can be shared for the transmission of different types of messages, which eliminates the need for dedicated signaling lines (e.g., for acknowledgment signaling).

[0036] Furthermore, the concept of using both parameterized message-type commands and message-type acknowledgment signals relaxes timing requirements and can be handled by interface drivers and interfaces with non-deterministic timing behavior. For example, by providing the device under test with an opportunity to wait for acknowledgment signaling before proceeding with test execution, a slight delay in message transmission (of both command and acknowledgment messages) does not significantly affect the execution of test cases on the device under test, and in particular, does not compromise the synchronization between the execution of the test case and the desired updates of one or more test resources.

[0037] In a preferred embodiment, the automated test equipment is configured to receive commands (e.g., messages from the device under test) from the device under test (or equivalently from a test case) through a high-bandwidth interface (preferably protocol-based) (e.g., through a high-speed interface; e.g., through a USB interface or a PCI interface or a PCI-Express interface or a PCI-Express compliant interface or a Thunderbolt interface or an Ethernet interface or an IEEE-1394 interface or a SATA interface or an IEEE-1149 interface or an IEEE-1500 interface or an IEEE-1687 interface). Alternatively or additionally, the automated test equipment is configured to provide acknowledgment signaling (e.g., acknowledgment messages) to the device under test via a high-bandwidth interface (preferably protocol-based) (e.g., via a high-speed interface; e.g., via a USB interface, a PCI interface, a PCI-Express interface, a PCI-Express compliant interface, a Thunderbolt interface, an Ethernet interface, an IEEE-1394 interface, a SATA interface, an IEEE-1149 interface, an IEEE-1500 interface, or an IEEE-1687 interface). By using such high-bandwidth interfaces for the transmission of commands from the device under test to the automated test equipment and / or for the transmission of acknowledgment signaling from the automated test equipment to the device under test, delays can be kept significantly small, and said interfaces can also be reused. For example, the high-speed interfaces mentioned above can be reused for the uploading of on-chip system test software to the device under test and / or for the downloading of result data from the device under test to the automated test equipment.However, it has been found that during the execution of a test case, the high-bandwidth interfaces typically have sufficient bandwidth to be used for transmitting commands from the device under test to the automated test equipment and for transmitting acknowledgment signaling from the automated test equipment to the device under test. It has been found that the interfaces are typically loaded, for the most part (e.g., for transmitting test results), before the start of the on-chip system test and after the completion of the on-chip system test. Therefore, they are also typically used for other purposes in the test of the on-chip system, and thus high-speed interfaces available to drivers on both the automated test equipment side and the device under test side are highly suitable for transmitting commands and acknowledgment signaling. Furthermore, some types of high-speed (or high-bandwidth) interfaces even enable the reserve of time slots, which enables near-real-time (or near-decisive time) forwarding of commands from the device under test to the automated test equipment and / or forwarding of acknowledgment signaling from the automated test equipment to the device under test. Furthermore, the high-bandwidth interface mentioned above typically provides near-real-time transmission even in the absence of reserved time slots due to the high available bandwidth.

[0038] In a preferred embodiment, the automated test equipment is configured to update one or more tester resources during the execution of a test case on the device under test (e.g., system-on-chip) in response to a command by the device under test (or equivalently by the test case) (e.g., under the control of a test case executed on the device under test). However, it has been found that it is possible to update one or more tester resources during the execution of a test case on the device under test without significant problems using the approach of the present invention. For example, the test case may issue a command requesting an update of one or more test resources, and then may continue the execution of test case routines that are insensitive to updates of one or more tester resources (and then, later, may check for the reception of an acknowledgment signaling) or pause to wait for the reception of an acknowledgment signaling. Thus, the automated test equipment no longer needs to provide any additional control signals to the device under test to complete the update of the tester resources, except for the provision of an acknowledgment signaling. For example, the provision of explicit signaling or control signals by automated test equipment to halt test case execution before a resource update or to initiate test case execution after a resource update can be avoided. Consequently, by providing acknowledgment signaling from the automated test equipment to the device under test, delays caused by explicit control of test case execution by the automated test equipment can be avoided. In particular, test case execution can continue during resource updates, which helps reduce valuable test time. Furthermore, waiting for acknowledgment signaling can be performed under the control of the test case running on the DUT, eliminating the need to interrupt the execution of the test case on the DUT.

[0039] In a preferred embodiment, the automated test equipment is configured to provide an application programming interface (API) for use by a test case executed on the device under test. The application programming interface is configured to provide one or more routines (e.g., methods or functions) for transmitting commands requesting the adaptation (or update) of one or more tester resources from the device under test (or equivalently from the test case) to the automated test equipment. Alternatively or additionally, the application programming interface is configured to provide one or more routines (e.g., methods or functions) for time synchronization between the device under test and the automated test equipment (e.g., one or more routines for pausing program execution (e.g., of a test case executed on the device under test) until receiving a signaling indicating the completion of the tester resource update).

[0040] By providing an application programming interface for use by test cases, automated test equipment can significantly support the development of test cases. By providing one or more routines for transmitting commands requesting the adaptation (or update) of one or more tester resources from the device under test to the automated test equipment, verification engineers do not need to know the details regarding the internals of the automated test equipment or the syntax of the commands. Rather, it is sufficient for verification engineers to add one or more routines from the application programming interface to the test program (e.g., to test cases to be executed on dut), which is typically easy if the routines are well documented. Furthermore, the application programming interface can be designed so that test program development is virtually independent of the actual tester hardware or software revisions of the software on the automated test equipment. Consequently, verification engineers have a highly efficient tool, and the development of test cases in which one or more tester resources are updated is very simple, without the need to deal with the details of the test program executed on the automated test equipment. The same applies to the provision of one or more routines for time synchronization between the device under test and the automated test equipment. Such routines can be easily incorporated into test cases (to be executed on the device under test) by a verification engineer without requiring the verification engineer to have detailed knowledge of the internals of the automated test equipment or the ATE test program. Therefore, by providing a suitable ATE, synchronization between the test cases and updates to tester resources can be performed in a simple manner, and test program development can even be independent of the actual tester hardware and / or software revisions of the ATE software.This enables efficient software development with reduced error risks and high portability.

[0041] In a preferred embodiment, the automated test equipment comprises an on-chip system test (OCST) controller, a test program executor for executing a test program, and one or more test resources (e.g., one or more device power supplies and / or one or more analog or digital signal generators). The on-chip system test controller is configured to receive a command (e.g., in the form of a message) requesting an update of one or more test resources from a device under test (or equivalently from a test case) (e.g., via a high-bandwidth interface) and to forward the command (e.g., message) to the test program executor for executing the test program. Furthermore, the test program includes a message handler configured to decode and / or interpret the forwarded message (e.g., according to one or more parameters included in the forwarded message) and then perform (e.g., execute) an update of one or more test resources in response to the (forwarded) command (e.g., in the form of the forwarded message).

[0042] Using this concept, it is possible to have basic functions for controlling tester resources implemented in the test program executor (also sometimes referred to as test resources in this specification), but specific support for on-chip system tests is provided by the on-chip system test controller. For example, the test program executor may exercise control over tester resources in a manner defined by the test program (the test program may, for example, define the handling of commands for updating tester resources received from the device under test). Accordingly, the basic functions of the automated test equipment may be defined by the ATE test program, which enables the automated test equipment to be configured in a manner well adapted to the current test scenario. On the other hand, the on-chip system test controller may provide specific functions related to on-chip system tests in a more efficient manner than the test program executor. For example, the on-chip system test controller may efficiently implement high-speed interfacing functions related to on-chip system tests (e.g., using dedicated hardware support). For example, an on-chip system test controller may include hardware implementations of high-speed input-output interfaces that are highly suitable for communication with a device under test, which may be system-on-chip. By having efficient (and possibly hardware-supported) implementations for communication with the device under test, the on-chip system test controller can relax the requirements for the test program executor and, for example, take over the handling of communication protocols for communication with the device under test.Furthermore, the on-chip system test controller can also support additional functions required for on-chip system testing, such as uploading test cases to one or more devices under test and / or downloading test results from one or more devices under test and / or evaluating test results. For example, the on-chip system test controller can significantly support any protocol-based data exchange with the devices under test, which is typically difficult to handle with conventional tester resources.

[0043] Furthermore, an on-chip system test controller may be particularly well-suited for receiving commands from a device under test, provided that the commands requesting updates to one or more test resources are transmitted using communication protocols and / or interface technologies that can be better handled by the on-chip system test controller compared to the test program executor. Accordingly, by utilizing the capabilities of the on-chip system test controller to receive commands requesting updates to test resources, high-bandwidth communication may be applied for the transmission of said commands, and the use of other test resources that may have difficulties in implementing protocol-based high-speed communication may be avoided. It should be noted that the on-chip system test controller may, for example, extract commands from a high-speed communication protocol and forward the commands (e.g., in their original form or in a converted form) to the test program executor, and that the on-chip system test controller may typically be linked to the test program executor via a high-data-rate ATE internal interface. Accordingly, "conventional" tester resources and also test program executors are not required to take over the typically very difficult task of receiving high-speed communication from the device under test, but rely on the on-chip system test controller as a powerful intermediary. Furthermore, the test program executor can typically receive communication from the on-chip system test controller with almost no effort, and the test program executed on the test program executor can evaluate this forwarded command in a manner flexibly configurable by the ATE test program.In other words, the on-chip system test controller can function as a forwarding instance, which can also take over protocol handling for communication with the device under test, and the test program executor can control actual tester resources under the control of the ATE test program, and the ATE test program can ultimately evaluate commands forwarded by the on-chip system test controller and convert the commands into internal tester (e.g., hardware-related) commands to configure the tester resources of the automated test equipment. As a result, highly efficient sharing of tasks within the automated test equipment can be achieved, which enables the handling of commands in a resource-efficient manner.

[0044] In a preferred embodiment, the message handler is configured to convert a command (e.g., a message) containing a symbolic reference (e.g., "VCC2") of a tester resource (e.g., of a supply voltage or signal) into a tester-hardware related tester resource adjustment (e.g., a command to set the (physical) resource channel of an automated test equipment to a desired value).

[0045] By using this concept, commands generated by test cases executed on the device under test do not need to recognize specific hardware of the automated test equipment, nor do they need to recognize any internal ATE commands for controlling test resources. Instead, test cases executed on the device under test can rely on symbolic references that are easy for verification engineers to understand. Furthermore, the conversion of these symbolic references into tester-hardware related control commands is performed by a message handler in a configurable manner, so that the association between the symbolic references and physical tester resources can be defined, for example, in an ATE test program executed by a tester program executor. Consequently, testers with different actual physical tester resource configurations can be adapted for use in a given test case by a one-time adaptation of the ATE test program to properly handle the given test case using specific symbolic references. As a result, when the actual physical tester hardware changes, the test case does not need to be rewritten or even modified. Consequently, the ATE test program executed by the ATE test program executor constitutes a physical abstraction mechanism, which significantly facilitates testing of target devices on different automated test equipment.

[0046] In a preferred embodiment, the message handler is configured to generate an acknowledgment message and to provide the generated acknowledgment message to an on-chip system test controller (e.g., after the completion of an update of one or more tester resources requested by the device under test). Furthermore, the on-chip system test controller is configured to forward the acknowledgment message provided by the message handler to the device under test, or to provide the acknowledgment message to the device under test in response to the acknowledgment message provided by the message handler.

[0047] By utilizing this concept, acknowledgment messages can be generated in the test program executor, which typically has physical access very close to the tester resources and can also reliably determine when the updates to the tester resources have been completed. Therefore, while a message handler is best suited for generating acknowledgment messages, an on-chip system test controller has been found to be best suited for forwarding them; this forwarding of acknowledgment messages involves, for example, protocol handling for communication with the device under test. Consequently, typically fast communication between the message handler and the on-chip system test controller, and high-speed communication toward the device under test enabled (or best supported) by the on-chip system test controller, can be utilized. Thus, a high-speed mechanism for transmitting acknowledgment messages can be implemented through the efficient use of available resources.

[0048] In a preferred embodiment, the automated test equipment is configured to execute a test program, and the test program is configured to initialize the test resources of the automated test equipment to enable the initiation of the test program execution on the device under test. Furthermore, the test program is configured to perform additional updates to the test resources under the control of the device under test (e.g., under the control of one or more on-chip-system-test cases executed on the device under test). Accordingly, the sharing of tasks between the ATE test program and the test cases executed on the device under test can be achieved. The startup conditions most suitable for reliable startup of the device under test can be performed by the ATE test program, for example, at a time when there are no test cases executed on the device under test. Subsequently, later, different test conditions caused by the updates to the test resources under the control of the device under test can be reached, for example, under the higher control of the test cases. Accordingly, difficult tests that may cause testing of the device under test, for example, under limit conditions, can be controlled by the test cases. It has been found that this concept makes test development particularly simple and reliable.

[0049] In a preferred embodiment, the automated test equipment includes an on-chip system test controller. The automated test equipment includes one or more tester resources (e.g., one or more device power supplies, and / or one or more analog or digital signal generators). The on-chip system test controller is coupled to one or more tester resources (e.g., directly coupled; e.g., coupled in a manner that bypasses a test program executor). Furthermore, the on-chip system test controller is configured to provide control signals to one or more tester resources (e.g., via a data bus and / or one or more synchronization lines and / or a synchronization bus) in order to update the one or more tester resources in response to a command from the device under test (or equivalently, from a test case).

[0050] Using this concept, it is possible to perform very rapid updates of one or more tester resources in response to commands from the device under test. For example, an on-chip system test controller can be adapted to communicate very rapidly with the device under test, for instance, using a high-speed interface (e.g., HSIO). By handling the protocol of the high-speed interface, the on-chip system test controller can be configured to enable rapid communication between the on-chip system test controller and the device under test with moderate effort. Thus, the on-chip system test controller is well adapted to receive commands from the device under test requesting updates of one or more tester resources. Furthermore, by providing the on-chip system test controller with an interface that enables direct control of one or more tester resources without the involvement of, for instance, a test program executor or workstation controlling automated test equipment, the on-chip system test controller can perform very rapid updates of one or more tester resources in response to commands issued by the device under test (e.g., via the high-speed interface). For example, an on-chip system test controller may be provided with direct access to an interface (e.g., a data bus) that enables the configuration (or reconfiguration) of one or more tester resources. Thus, the latency of updating one or more tester resources in response to a command from the device under test may be reduced compared to, for example, other solutions in which a test program executor also involves updating one or more tester resources.

[0051] In a preferred embodiment, the on-chip system test controller is configured to convert a command (e.g., a message) containing a symbolic reference to a tester resource (e.g., "VCC2") (e.g., of a supply voltage or signal) into a tester-hardware related tester resource adjustment (e.g., a command to set a (physical) resource channel of an automated test equipment to a desired value).

[0052] By using this conversion of symbolic references to tester-hardware related tester resource coordination, the development of test programs can be significantly facilitated for verification engineers. For example, a verification engineer designing test cases needs only to refer to symbolic references and does not need to be aware of the specific physical configuration of the automated test equipment. Furthermore, test cases can consequently be executed on automated test equipment of different configurations (e.g., without modification). Therefore, the concept of using command conversions offers significant advantages for both test development and test execution. Moreover, the above descriptions regarding command conversion in test program executors are also referenced.

[0053] In a preferred embodiment, an on-chip system test controller is coupled to one or more tester resources via a data bus and via a synchronization line or a synchronization bus. The on-chip system test controller is configured to prepare (e.g., initialize) a new setting (e.g., a new voltage) of a selected tester resource (e.g., a device power supply whose output voltage is to be changed) by relying on (or accordingly) message parameters of a command received from the device under test (or equivalently, from a test case) (e.g., to define future characteristics of the selected tester resources). Furthermore, the on-chip system test controller is configured to activate the prepared new setting of the selected tester resource via the synchronization line or via the synchronization bus (e.g., using a synchronization bus event or a synchronization bus message). Using this concept, the on-chip system test controller can obtain very accurate knowledge when the update of the test resource is actually prepared. Although the communication of a desired new configuration via the data bus, based on the message parameters of the command received from the device under test, may not enable the precise determination of when the test resource update actually occurs, there is typically a very well-predictable timing relationship between the activation of the synchronization line or the transmission of data via the synchronization bus and the time when the test resource is actually updated. Accordingly, acknowledgment messages can be generated by the on-chip system test controller with high reliability and without the need to add unnecessary delays "simply to be on the safe side." Consequently, this concept enables rapid test execution and helps reduce test costs.

[0054] In a preferred embodiment, the on-chip system test controller is configured to provide acknowledgment signaling (e.g., in the form of an acknowledgment message) to the device under test. Accordingly, synchronization with the execution of a test case on the device under test can be ensured, and communication from the on-chip system test controller to the device under test is typically particularly fast, considering the performance of the on-chip system test controller which efficiently utilizes high-speed interfaces.

[0055] An embodiment according to the present invention creates a device under test. The device under test is configured to provide a command (in the form of a message) to an automated test device requesting an update of one or more tester resources (e.g., under the control of a test case executed on the device under test). Furthermore, the device under test is configured to pause the execution of the test case until an acknowledgment signaling (e.g., an acknowledgment message) indicating the completion of the tester resource update requested by the device under test is received by the device under test.

[0056] Such a device under test enables particularly efficient execution of the test. The device under test (or the test case executed on the device under test) can control the test environment of the device under test (e.g., the setting of one or more supply voltages supplied to the device under test and / or the setting of one or more clock frequencies of the device under test and / or the characteristics of input signals provided to the device under test by automated test equipment). Furthermore, timing synchronization between the test case executed on the device under test and the update of one or more test resources can be achieved by pausing the execution of the test case until an acknowledgment signaling indicating the completion of a test resource update requested by the device under test is received by the device under test. For example, the device under test can wait with the execution of test program steps requiring updates of one or more test resources until the acknowledgment signaling is received, which helps ensure that the test case is always executed in the appropriate expected test environment. Additionally, by using acknowledgment signaling, unnecessary delays to "stay on the safe side" can be avoided. As a result, test cases can be executed quickly and with very high reliability (e.g., by immediately continuing test case execution rather than using a large fixed delay when an acknowledgment signaling is received). Furthermore, the development of such test cases is typically very easy for verification engineers, as changes to the test environment can be made by individual commands included in the test cases to be executed on the device under test, without performing adaptations of the test program running on automated test equipment. Therefore, both the development and debugging of test cases to be executed on dut are simple and reliable.

[0057] In a preferred embodiment, the device under test is a system-on-chip. The device under test is configured to execute a test case (e.g., a program that performs a test procedure for testing the device under test). Furthermore, the device under test is configured to provide commands to automated test equipment under the control of the test case. Accordingly, the test case provides highly reliable control over the adjustment of the test environment by having the potential to request updates to one or more tester resources (e.g., parameter changes) and also having the potential to evaluate signaling indicating the completion of updates to these tester resources.

[0058] Accordingly, the test case itself can control the test environment (e.g., supply voltages of the device under test, or physical parameters of one or more signals provided to the device under test by automated test equipment). This enables the performance of very thorough testing that is effectively under the (higher-level) control of the test case and, accordingly, can be efficiently defined by the verification engineer designing the test case.

[0059] In a preferred embodiment, the device under test is configured to provide commands in the form of parameterized messages, wherein the parameters of the message describe the desired settings of the tester resources (e.g., desired supply voltage, desired clock frequency, desired signal characteristics, etc.). It has been found that the use of commands in the form of parameterized messages simplifies the verification engineer in communicating specific requirements for automated test equipment. Furthermore, it has been found that parameterized commands typically provide very good readability of the program code underlying the test case. Furthermore, the advantages discussed above, provided by the use of commands in the form of parameterized messages, are also referenced.

[0060] In a preferred embodiment, the device under test is configured to receive acknowledgment signaling in the form of a message. It has been found that the device under test, which includes one or more high-speed interfaces, is well suited for receiving messages because it typically includes communication interface drivers capable of handling messages (such messages may include, for example, a message header, message data, optional error correction information, and optional message terminator). Furthermore, it has been found that handling of messages is typically possible by software running on the device under test, for example by software supported by an operating system running on the device under test, or by using a loop that waits for the reception of messages. Additionally, evaluation of messages is typically easily possible using a finite state machine that can be implemented on the DUT with reasonable effort.

[0061] In a preferred embodiment, the device under test is configured to provide commands (e.g., messages to automated test equipment) to automated test equipment through a high-bandwidth interface (preferably protocol-based), for example, through a high-speed interface (e.g., a USB interface or a PCI interface or a PCI-Express interface or a PCI-Express compliant interface or a Thunderbolt interface or an Ethernet interface or an IEEE-1394 interface or a SATA interface or an IEEE-1149 interface or an IEEE-1500 interface or an IEEE-1687 interface). Alternatively or additionally, the device under test is configured to receive acknowledgment signaling (e.g., acknowledgment messages) (e.g., from automated test equipment) through a high-bandwidth interface (preferably protocol-based) (e.g., through a high-speed interface; e.g., through a USB interface or a PCI interface or a PCI-Express interface or a PCI-Express compliant interface or a Thunderbolt interface or an Ethernet interface or an IEEE-1394 interface or a SATA interface or an IEEE-1149 interface or an IEEE-1500 interface or an IEEE-1687 interface).

[0062] It has been found that the use of these high-speed interfaces (or high-bandwidth interfaces) is highly suitable for many devices under test that may include one or more of these interfaces on a chip and may include drivers for one or more of these interfaces. For example, the interfaces may be reused for multiple purposes during on-chip system testing, such as for uploading test cases from automated test equipment to the device under test and / or for downloading test results from the device under test to automated test equipment and / or for testing the interfaces themselves. Accordingly, the high-speed interfaces can be readily used for transmitting commands to automated test equipment and also for receiving acknowledgment signaling from automated test equipment, and the use of these high-speed interfaces enables low latency.

[0063] In a preferred embodiment, the device under test is configured to use one or more library routines (e.g., of a software library provided by the automated test equipment) to provide commands and / or evaluate acknowledgment signaling (the use of library routines may be enabled, for example, by an application programming interface provided by the automated test equipment). The use of library routines by the device under test enables the provision of commands and / or evaluation of acknowledgment signaling, and facilitates a verification engineer in developing an appropriate test program. For example, library routines may be provided by the manufacturer of the automated test equipment and thus can be well adapted to the automated test equipment. For example, a verification engineer designing a test case does not need to have any detailed knowledge of the internals of the automated test equipment and / or protocols for sending messages or sending acknowledgment signaling. Rather, a verification engineer designing a test case to be executed on the test device may only need to use an application programming interface provided, for example, by the automated test equipment (e.g., as part of the automated test equipment software). Accordingly, verification engineers can develop test programs reliably and comfortably.

[0064] An embodiment according to the present invention creates a test setup. The test setup includes automated test equipment as outlined above and a device under test as outlined above. This test setup is based on the same considerations as the automated test equipment and device under test discussed above.

[0065] Another embodiment according to the present invention provides a method for operating an automated test apparatus. The method comprises the step of receiving a command (e.g., in the form of a message) from a device under test (or equivalently from a test case) requesting an update of one or more test resources. Furthermore, the method comprises the step of updating one or more test resources in response to a command provided by the device under test (or equivalently from a test case). Furthermore, the method comprises the step of signaling the completion of the test resource update requested by the device under test by providing an acknowledgment signaling (e.g., an acknowledgment message) to the device under test. The method is based on the same considerations as the automated test apparatus mentioned above. Furthermore, the method may optionally be supplemented by any of the features, functions, and details discussed herein in relation to the automated test apparatus. The method may optionally be supplemented by such features, functions, and details, all taken individually and in combination.

[0066] Another embodiment according to the present invention provides a method for testing a device under test. The method comprises the step of providing a command (e.g., in the form of a message) requesting an update of one or more tester resources from the device under test (or equivalently from the test case) to an automated test device (e.g., under the control of the test case running on the device under test) under the control of a test case running on the device under test. The method comprises the step of pausing the execution of the test case (e.g., under the control of the test case) until an acknowledgment signaling (e.g., an acknowledgment message) indicating the completion of the tester resource update requested by the device under test is received by the device under test (and detected, e.g., by the test case). Furthermore, the method comprises the step of updating one or more test resources in response to the command provided by the device under test (or equivalently by the test case). Additionally, this method includes the step of signaling the completion of a tester resource update requested by the device under test by providing an acknowledgment signaling (e.g., an acknowledgment message) to the device under test. Furthermore, this method includes the step of continuing the execution of a test case upon detection of the acknowledgment signaling by the device under test.

[0067] This method implements the interaction between the automated test equipment discussed above and the device under test discussed above. Accordingly, this method is based on the same considerations discussed for the automated test equipment and the device under test and includes the same benefits. Furthermore, this method may be supplemented by any of the features, functions, and details discussed herein for the automated test equipment and the device under test, which are optionally taken individually and in combination.

[0068] Another embodiment according to the present invention generates a computer program for carrying out the methods discussed herein.

[0069] Another embodiment according to the present invention creates an automated test device for testing one or more devices in a test. The automated test device is configured to receive a command (e.g., in the form of a message) from a test case requesting an update of one or more test resources. The automated test device is configured to update one or more test resources in response to the command provided by the test case. Furthermore, the automated test device is configured to signal the completion of the test resource update requested by the test case by providing an acknowledgment signaling (e.g., an acknowledgment message) to the test case. Such an automated test device is based on considerations similar to those of the automated test device discussed above. However, it should be noted that the automated test device is generally configured to receive a command from a test case, and the test case is typically executed on the device under test (but can also be executed in a distributed manner, for example, distributed between the automated test device and the device under test). Furthermore, it should be noted that the automated test equipment may optionally be supplemented by any of the features, functions, and details discussed herein in relation to the automated test equipment that receives commands from the device under test. For example, receiving commands from a test case may substitute for receiving commands from the device under test. The automated test equipment may be supplemented by these features, functions, and details, all taken individually and in combination (a test case may substitute for, for example, where appropriate).

[0070] Another embodiment according to the present invention provides a method for operating an automated test equipment. This method includes the step of receiving a command (e.g., in the form of a message) from a test case requesting an update of one or more test resources. This method includes the step of updating one or more test resources in response to the command provided by the test case. Furthermore, this method includes the step of signaling the completion of the test resource update requested by the test case by providing an acknowledgment signaling (e.g., an acknowledgment message) to the test case. This method is based on the same considerations as the method for operating an automated test equipment described above, and the command is provided by the test case. This method may optionally be supplemented by any of the features, functions, and details described herein in relation to the corresponding automated test equipment. This method may be supplemented by these features taken individually and in combination (the test case may, for example, substitute for the DUT where appropriate).

[0071] Furthermore, embodiments according to the present invention also generate individual computer programs.

[0072] An embodiment according to the present invention creates an automated test apparatus for testing a device under test. The automated test apparatus includes a trigger line (e.g., a hardware trigger line, e.g., a GPO trigger line) controllable by the device under test (or equivalently by a test case that can be executed on the device under test). The automated test apparatus is configured to update one or more tester resources (sometimes also referred to herein as test resources) in response to activation of the trigger line by the device under test (or equivalently by a test case that can be executed on the device under test) (e.g., to change one or more supply voltages provided to the device under test by the automated test apparatus, or to change one or more signal characteristics of one or more analog or digital signals provided to the device under test by the automated test apparatus).

[0073] This embodiment according to the present invention is based on the idea that, in an automated test apparatus, a test can be executed with high timing accuracy under the control of a device under test (e.g., which may be a system-on-chip) by providing a trigger line that enables the device under test to trigger an update of one or more tester resources. Accordingly, it is possible for the device under test to influence the test environment with little effort but with high timing accuracy. For example, by providing the device under test with access to a trigger line that triggers an update of one or more tester resources, the automated test apparatus of the present invention provides the device under test with the possibility to change the settings of the automated test apparatus (or more precisely, one or more test resources) without requiring the device to transmit commands, for example, using a protocol-based interface. Accordingly, the device under test can perform (or trigger) an update of one or more tester resources by simply enabling (or disabling) a single output pin (e.g., a general-purpose output pin or any other output pin) or a single input / output pin, which is typically possible with very little effort and with very high timing accuracy.

[0074] For example, using this concept, a device under test, which may be a system-on-chip, may request a single machine instruction (or a very small number of machine instructions) to trigger an update of one or more test resources (e.g., by an edge on said output pin or input / output pin) simply by enabling or disabling an output (or, more precisely, a single output pin or a single input / output pin). The enabling (or disabling) of such an output, which may be combined with a trigger line, may be possible within a very short time and may not, for example, cause the need to use any complex drivers or communication protocols. Delays or timing indeterminacy that may be caused by drivers required to operate protocol-based high-speed interfaces can be avoided (or bypassed) in this way.

[0075] Furthermore, additional delays in automated test equipment can also be avoided by using the aforementioned trigger line, because simple activation of the trigger line (e.g., a rising or falling edge on the trigger line) typically does not require complex protocol handling or command conversion on the automated test equipment side, thereby avoiding both effort and delays. Moreover, the trigger line, which may be a dedicated trigger line, can act directly on test resources, thereby minimizing both the delay and complexity of the arrangement. Thus, a simple falling or rising edge on the trigger line can cause an update to the tester resources.

[0076] In conclusion, providing the device under test with access to the trigger line described above offers a very good trade-off between response time, implementation effort, and ease of use.

[0077] In a preferred embodiment, the automated test equipment is configured such that the activation of a trigger line (e.g., a simple edge or transition on the trigger line) bypasses a test program executor executing a test program (e.g., a test program executor of the automated test equipment executing an ATE test program) and directly triggers the update of one or more test resources. By bypassing the test program executor, unnecessary delays can be avoided, and test resources, such as an ATE power supply, an analog channel module, or a digital channel module, can be directly triggered by the device under test. Furthermore, the execution of the ATE test program is not interrupted by the activation of the trigger line, so the test program executor can perform its activities (e.g., evaluating result data provided by the device under test) in an uninterrupted manner, which helps reduce test time. Additionally, interruption of the operation of the test program executor that could cause data loss (e.g., if the test program executor is responsible for capturing result data from the device under test) can also be avoided.

[0078] In a preferred embodiment, the automated test equipment comprises one or more tester resources (e.g., one or more device power supplies, and / or one or more digital signal modules or signal sources, and / or one or more analog signal modules or signal sources, and / or one or more mixed signal modules). Furthermore, one or more tester resources (also designated as test resources) are coupled to a test program executor via an interface, which enables programming of one or more features of the one or more test resources (e.g., supply voltage, e.g., digital pattern, e.g., digital waveform, etc.) under the control of a test program (e.g., under the control of an ATE test program executed by the test program executor of the automated test equipment). Furthermore, one or more tester resources are coupled to a trigger line controllable by the device under test (or equivalently by a test case that can be executed on the device under test, e.g.). Furthermore, one or more tester resources are configured to update signal features in a pre-programmed manner (e.g., as a value) under the control of a test program in response to activation of a trigger line by the device under test (or equivalently, by a test case that can be executed on the device under test).

[0079] In this concept, the test program executor maintains control of the actual parameters to which one or more tester resources are configured. Accordingly, there may be a sharing of responsibilities between the test program executor and the device under test; the test program executor is responsible for programming the characteristics of one or more test resources and also for pre-programming the configuration of one or more tester resources to be handed over in response to the activation of a trigger signal, while the device under test only needs to activate the trigger signal at an appropriate time (e.g., determined by a test case executed on the DUT). Consequently, the device under test (typically an intelligent device under test, such as a system-on-chip) only needs to take over a small part of the function (e.g., triggering the update of signal characteristics of one or more tester resources with values ​​pre-programmed by the test program executor), which enables very simple communication between the device under test and the automated test equipment (requiring only the activation or deactivation of a single output of the device under test that provides the trigger signal). On the other hand, the test program executor of the automated test equipment typically includes knowledge of updates to one or more test resources required by the device under test, and preferably also has some timing coordination with the execution of test cases on the device under test. However, such "rough" timing synchronization between the test program executor of the automated test equipment and the execution of test cases on the device under test is typically provided, because the test program executor typically controls the uploading of test cases to the device under test and also communicates with the device under test to receive test result information from the device under test.Accordingly, the test program executor typically recognizes the state of the device under test and therefore also knows which update of one or more test resources will be next requested by the device under test, so the test program executor can easily pre-program one or more test resources for which one or more parameters of one or more test resources must be updated in response to the subsequent activation of a trigger line by the device under test. As a result, it is evident that the concept mentioned herein is highly efficient because it enables communication between the device under test and automated test equipment while providing very high timing accuracy.

[0080] In a preferred embodiment, the automated test equipment includes a test program executor configured to pre-program one or more tester resources to pre-define the response of one or more tester resources to the activation of a trigger line by the device under test (or equivalently, by a test case that can be executed on the device under test, for example) (e.g., a change in signal characteristics to a new parameter value). By pre-define the response of one or more tester resources to the activation of a trigger line by the device under test under the control of an ATE test program, communication between the device under test and the automated test equipment can be kept very simple, so that, consequently, a simple activation of a trigger signal by the device under test is sufficient to cause a well-defined response of one or more tester resources, said response being pre-defined by the test program executor (e.g., under the control of an ATE test program).

[0081] In a preferred embodiment, an automated test device (e.g., a test program executor of the automated test device) is configured to pre-program one or more tester resources according to one or more commands (e.g., commands defining desired parameters for pre-programming) provided in a test program (e.g., an ATE test program executed by the test program executor of the ATE) in order to pre-define the response of one or more tester resources to the activation of a trigger line by the device under test (or equivalently, e.g., by a test case that can be executed on the device under test) (e.g., a change in signal characteristics to a new parameter value). By defining the pre-programming of one or more tester resources using the commands provided in the test program (e.g., an ATE test program), the appropriate update of one or more tester resources can be prepared in a programmable manner by the appropriate development of the ATE-side test program (which must, in some way, be time-synchronized at least roughly with the execution of the test case on the device under test). On the other hand, communication of parameters for updating tester resources from the device under test to the automated test device is not required (and may be omitted).

[0082] In a preferred embodiment, an automated test device (e.g., a test program executor of the automated test device) is configured to receive a command (e.g., in the form of a message) from a device under test (or equivalently from a test case that can be executed on the test device) that defines one or more parameters for updating one or more tester resources (the update is triggered, for example, not by the command defining the parameters, but by the (subsequent) activation of a trigger line). Furthermore, an automated test device (e.g., a test program executor of the automated test device) is configured to pre-program one or more tester resources according to a command received from the device under test (or equivalently, from a test case that can be executed on the device under test) (e.g., according to a command defining one or more parameters for updating) in order to pre-define the response of one or more tester resources to the activation of a trigger line by the device under test (or equivalently, by a test case that can be executed on the device under test) (e.g., according to a command defining one or more parameters for updating).

[0083] By using this concept, the device under test itself can signal to the automated test equipment which update of one or more parameters of one or more tester resources will be required next. However, this signaling from the device under test to the automated test equipment can be performed, for example, under relaxed timing requirements, because the actual time of the update of one or more tester resources is determined by the activation of the trigger line by the device under test, which can be done in a very time-accurate manner (as discussed above). Using this concept, the automated test equipment (or the test program executor of the automated test equipment) no longer needs to know which parameter update of one or more tester resources will be required by the device under test next. Accordingly, there is no need for synchronization between the execution of a test case on the device under test and the execution of an ATE test program on the ATE test program executor. Furthermore, the verification engineer can define not only the time when the update of one or more tester resources should occur, but also one or more parameters that one or more tester resources must be set in the update within the test case to be executed on the device under test. Therefore, verification engineers do not need to modify both the test cases to be executed on the device under test and the ATE test program to define appropriate updates for tester resources. Consequently, it is considerably easier for verification engineers to develop test cases and the likelihood of errors is lower, because verification engineers no longer need to adapt the ATE test program when forwarding desired new parameters of one or more tester resources using commands (e.g., in the form of messages).

[0084] Therefore, at least with respect to the adaptation (update) of the test environment, the development of test cases is substantially independent of the adaptation of the ATE test program using this concept. Furthermore, by distinguishing between a command defining one or more parameters for updating one or more test resources and the actual activation of a trigger signal by the device under test, there exists a separation between the non-time-critical part "command" (a command defining one or more parameters for future updates of one or more test resources) and the actual trigger of said update (the latter is typically a very time-critical process). Consequently, the command, which typically contains a larger amount of data, can be transmitted, for example, using a high-speed interface, which may be, for example, protocol-based and non-real-time capable (or ideally not real-time capable), while the trigger signal can be generated by the simple activation of a single output of the device under test, which can be done in a very time-critical manner.

[0085] In a preferred embodiment, one or more tester resources include a trigger mechanism configured to update signal characteristics (e.g., signal voltage provided to the test device or frequency of a clock signal provided to the test device) in response to activation of a trigger line by the device under test (or equivalently, by a test case that can be executed on the device under test). By providing such a trigger mechanism to one or more tester resources, it is possible to achieve a very fast response time and to pre-program desired new values ​​(for which the test resources must be switched in response to activation of the trigger signal), which makes the pre-programming non-time critical. In contrast, upon activation of the trigger line (provided by the device under test or by a test case), the test resources can then quickly switch to the use of one or more new signal parameters (pre-programmed), and for the actual execution of the update, the tester resources only need to receive a trigger signal from the device under test (e.g., via the trigger line). Therefore, the non-time-critical pre-programming of the desired new value(s) to be used in response to the activation of the trigger line can be separated from the time-critical activation of the trigger line. Accordingly, very short response times can be achieved, and the actual trigger for the update of one or more test resources no longer requires just-in-time transmission of the desired new parameters to one or more tester resources.

[0086] In a preferred embodiment, the automated test equipment includes an on-chip system test controller and one or more test resources. In this case, the trigger line is a hardware line that bypasses the on-chip system test controller and the test program executor and extends directly from the interface of the device under test of the automated test equipment to one or more test resources (e.g., device power supply, signal generator module, channel module, etc.).

[0087] Using this approach, updates to one or more tester resources can be triggered with minimal latency, and the triggering of such updates does not impose any additional computational requirements on the on-chip system test controller or test program executor. Accordingly, updates to one or more tester resources can be performed very quickly, while avoiding interruption of the on-chip system test controller or test program executor's functionality.

[0088] In a preferred embodiment, one or more tester resources include: a device power supply; and one or more of a signal generator module and / or a channel module. It has been found that these types of tester resources are typically very suitable for rapid updating of one or more parameters and significantly determine the test environment of the device under test. Consequently, it has been found that a direct trigger for updating one or more signal parameters of these tester resources under the direct control of the device under test is highly advantageous.

[0089] In a preferred embodiment, one or more tester resources are coupled to a test program executor through an interface. Accordingly, it is possible for the test program executor to initialize the one or more tester resources (e.g., even before a test case is executed on the device under test). Furthermore, providing an interface that couples the one or more tester resources to the test program executor further enables the test program executor to pre-program desired updates to the one or more tester resources (e.g., under the control of an ATE test program). Furthermore, by providing an interface between the tester resources and the test program executor, it may also be possible to fully control the tester resources through this interface. In conclusion, it appears advantageous to have both an interface between the one or more tester resources and the test program executor, and a trigger line that extends directly between the one or more tester resources and the device under test interface.

[0090] In a preferred embodiment, one or more tester resources are physically separated from the test program executor (e.g., different printed circuit boards or different interchangeable modules) (and preferably also physically separated from the OCST controller).

[0091] By using such physically separated and, preferably, modular concepts, automated test equipment can be flexibly adjusted to specific test needs. Furthermore, by separating different functions into physically distinct components, distortions in signal integrity can be kept significantly small. Moreover, it should be noted that the test program executor is typically adapted to control multiple significantly different tester resources (e.g., one or more device power supplies and one or more analog channel modules and one or more digital channel modules), and the number of tester resources typically varies between different applications. Accordingly, it is highly recommended to have a single test program executor coupled to multiple different tester resources (e.g., one or more device power supplies, and one or more channel modules, such as analog channel modules and / or digital channel modules). In such a system configuration, bypassing the test program executor using one or more trigger lines that extend directly from the device interface under test to one or more tester resources is particularly efficient, because the test program executor can be simultaneously involved in tasks related to multiple different tester resources and thus may experience significant latency.

[0092] An embodiment according to the present invention creates a device under test. The device under test is configured to trigger updates to one or more test resources via a dedicated trigger line by providing a trigger signal to automated test equipment (e.g., the device under test may be under the control of a test case). By providing the device under test with the ability to directly trigger updates to one or more test resources using the activation of the trigger line, the latency for performing resource updates can be minimized, and resource updates can be executed with minimal effort. For example, in this concept, it is possible to trigger updates to one or more test resources under the control of the device under test, and the triggering of resource updates is possible with very little software and hardware effort, because the device under test only needs to change the state of the dedicated trigger line. However, the device under test does not need to use protocol-based communication, which, for example, may require complex drivers and often suffer from a lack of real-time capabilities and latency. Therefore, a test case that can be executed on the device under test has a very high degree of control over the test environment with minimal latency without requiring device driver overhead.

[0093] In a preferred embodiment, the device under test is configured to provide a trigger signal under the control of a test case executed by the device under test (e.g., using one or more programmable processor devices and / or one or more microprocessor cores). Using this approach, an "intelligent" device under test capable of executing a test case can trigger an update of one or more tester resources under the control of the test case executed by the device under test. However, to trigger an update of one or more tester resources, the test case may require only a very simple command, such as a command to change the state of a single output pin of the device under test coupled to the trigger line (output of the trigger signal). Thus, the device under test has a very direct low-latency effect on the update of test resources.

[0094] In a preferred embodiment, the device under test is configured to provide a command to an automated test device (e.g., via a common interface different from a dedicated trigger line) that defines one or more parameters for updating one or more test resources (e.g., to initiate a pre-definition of the response of one or more test resources to the activation of a trigger line). Furthermore, the device under test is configured to trigger an update of one or more test resources using one or more parameters by providing a trigger signal (e.g., to the automated test device; e.g., directly to the test resources) (e.g., via a dedicated trigger line).

[0095] By using this two-stage mechanism, the device under test may use an appropriate interface (e.g., a protocol-based high-speed interface) to transmit to automated test equipment a command that is typically not particularly time-critical, which defines one or more parameters for updating one or more test resources. For example, a command defining one or more parameters for updating one or more test resources may be transmitted by the device under test to the automated test equipment well prior to the actual update of one or more test resources. For example, a command defining one or more parameters for updating one or more test resources may be transmitted to the automated test equipment even immediately after the trigger of a previous update of one or more test resources, so that there is sufficient time for transmitting the command to the automated test equipment using a protocol-based interface, and also for handling said command by the automated test equipment (handling of the command by the automated test equipment may include, for example, parsing of the command by a test program executor and pre-programming of one or more test resources of the automated test equipment by the test program executor). Furthermore, the actual time-critical trigger for the update of one or more tester resources can be executed by the provision (or activation) of a trigger signal (e.g., via a dedicated trigger line), which helps keep latency low and also helps avoid interruptions (of high priority) to the test program executor of the automated test equipment. Consequently, the concept of providing a command defining one or more parameters for the (future) update of one or more tester resources to the automated test equipment, separate from the actual trigger for the update of one or more tester resources, provides a good trade-off between efficiency and latency.

[0096] An embodiment according to the present invention creates a test setup, and the test setup includes automated test equipment as previously described and a test target device as previously described.

[0097] An embodiment according to the present invention provides a method for operating an automated test equipment comprising a trigger line (e.g., a hardware trigger line; e.g., a GPO trigger line) controllable by the device under test (or equivalently by a test case that can be executed on the device under test). The method comprises the step of updating one or more tester resources in response to activation of the trigger line by the device under test (or equivalently by a test case that can be executed on the device under test). (e.g., changing one or more supply voltages provided to the device under test by the automated test equipment, or changing one or more signal characteristics of one or more analog or digital signals provided to the device under test by the automated test equipment).

[0098] This method for operating automated test equipment is based on considerations similar to those for the automated test equipment described above. Furthermore, it should be noted that the method for operating automated test equipment may be supplemented by any of the features, functions, and details described herein (also in relation to automated test equipment), which are optionally taken individually and in combination.

[0099] Another embodiment according to the present invention provides a method for testing a device under test. The method includes the step of pre-programming one or more tester resources (e.g., under the control of automated test equipment) with one or more individual parameter values ​​to be handed over in response to a trigger signal using a test program executor. The method includes the step of providing a trigger signal to one or more tester resources directly from the device under test (e.g., bypassing the test program executor) to cause one or more tester resources to hand over the pre-programmed one or more individual parameter values.

[0100] This method for testing the device under test is also based on the automated test equipment described above and considerations similar to those for the device under test described above. Accordingly, this method may optionally be supplemented by any of the features, functions, and details described herein for both the automated test equipment and the device under test. This method may optionally be supplemented by such features, functions, and details, all taken individually and in combination.

[0101] Another embodiment according to the present invention generates a computer program when a computer program for performing the above methods is executed on one or more computers and / or on one or more microprocessors and / or on one or more microcontrollers.

[0102] Another embodiment according to the present invention creates an automated test apparatus for testing a device under test. The automated test apparatus includes a trigger line (e.g., a hardware trigger line; e.g., a GPO trigger line) controllable by a test case (e.g., which may be executed on the device under test, but alternatively, may be executed partially on the device under test and partially on the automated test apparatus). The automated test apparatus is configured to update one or more tester resources in response to activation of the trigger line by the device under test (e.g., to change one or more supply voltages provided to the device under test by the automated test apparatus, or to change one or more signal characteristics of one or more analog or digital signals provided to the device under test by the automated test apparatus).

[0103] This embodiment is based on considerations similar to those of the automated test equipment described above, and it should be noted that in this embodiment, the trigger line is controllable by the test case (so that the test case assumes the role of the device under test) (e.g., independently of the question of how the test case is distributed between the device under test and the automated test equipment).

[0104] Furthermore, it should be noted that this automated test equipment may optionally be supplemented by any of the features, functions, and details described herein in relation to other automated test equipment. The automated test equipment may be supplemented by such features, functions, and details, all taken individually and in combination.

[0105] Another embodiment according to the present invention relates to a method for operating an automated test device, wherein the automated test device comprises a trigger line (e.g., a hardware trigger line; e.g., a GPO trigger line) controllable by a test case (e.g., which may be executed on a device under test or distributed between the device under test and the automated test device). The method comprises the step of updating one or more test resources in response to the activation of the trigger line by the test case (e.g., which may be executed on a device under test or distributed) (e.g., changing one or more supply voltages provided to the device under test by the automated test device, or changing one or more signal characteristics of one or more analog or digital signals provided for testing by the automated test device).

[0106] The method for operating such automated test equipment is based on considerations similar to those for operating other automated test equipment described herein. However, it should be noted that the test case serves as a substitute for the function of the device under test. Furthermore, it should be noted that the method for operating the automated test equipment may be supplemented by any of the features, functions, and details disclosed herein in relation to the automated test equipment and also in relation to the device under test. This method may be supplemented by such features, functions, and details, which are optionally taken individually and in combination.

[0107] An embodiment according to the present invention provides a method for testing a device under test. The method includes the step of pre-programming one or more tester resources (e.g., under the control of automated test equipment) with one or more individual parameter values ​​to be handed over in response to a trigger signal using a test program executor. Furthermore, the method includes the step of providing one or more tester resources directly from a test case (e.g., bypassing the test program executor) a trigger signal that causes one or more tester resources to hand over the pre-programmed one or more individual parameter values.

[0108] This method for testing the device under test is similar to the method for testing the device under test described above, wherein the test case takes the role of the device under test. Furthermore, it should be noted that this method may be supplemented by any of the features, functions, and details described herein in relation to automated test equipment and the device under test. This method may be supplemented by such features, which are taken optionally, individually, and in combination.

[0109] Another embodiment according to the present invention generates a computer program when a computer program for performing the methods described herein is executed on one or more computers and / or on one or more microprocessors and / or on one or more microcontrollers.

[0110] An embodiment according to the present invention creates an automated test apparatus for testing one or more devices under test. The automated test apparatus is configured to receive a command (e.g., in the form of a message) from a device under test requesting the measurement of one or more physical quantities (e.g., a supply voltage provided to the device under test, e.g., a current supplied to the device under test, e.g., signal characteristics of a signal provided to the device under test, e.g., signal characteristics of a signal provided to the device under test, e.g., clock frequency of a clock signal provided to the device under test, e.g., environmental parameters such as temperature, humidity, atmospheric pressure, magnetic field, or electric field in the environment of the device under test). Furthermore, the automated test apparatus is configured to perform or initiate the measurement of one or more physical quantities in response to the command provided by the device under test. Furthermore, the automated test apparatus is configured to signal the measurement result requested by the device under test by providing a measurement result signaling (e.g., an acknowledgment message) to the device under test.

[0111] Using this concept, the device under test, or equivalently, a test case executed on the device under test, can control the execution of one or more measurements and further process the measurement results, because the measurement results are provided to the device under test (or equivalently, to the test case) using measurement result signaling. Consequently, the device under test can significantly control the execution of a test that includes measurements to be performed to characterize the function or performance of the device under test. Consequently, a verification engineer designing the test can add program instructions to the test case to be executed on the device under test that cause the provision of one or more commands requesting the measurement of one or more physical quantities by automated test equipment, and is also configured to place commands to be executed on the device under test to evaluate one or more measurement results (provided to the device under test by automated test equipment using measurement result signaling) into the test case. Consequently, most steps of the test can be controlled by the device under test (or by the test cases executed on the device under test), which means that verification engineers can focus on developing the test cases to be executed on the device under test and do not need to focus on developing the ATE test programs to be executed on the automated test equipment. For example, using the concept disclosed herein, verification engineers may not need to adapt the test programs to be executed on the automated test equipment to perform measurements at specific points in the execution of the test cases.Rather, the ATE test program may simply define a standard response to a command provided by the device under test (e.g., in a predefined format), said standard response may include, for example, appropriate control of physical tester resources to perform measurements and provide signaling of measurement results. Consequently, the device under test (or equivalently, a test case executed on the device under test) may request measurements of one or more physical quantities whenever appropriate, taking into account the progress of the execution of the test case on the device under test, and the device under test (or the test case executed on the device under test) may protocolize and / or evaluate the measurement results. For example, the device under test may even use the measurement results to make decisions regarding further execution of the test, and, for example, change the execution of the test case based on the measurement results.

[0112] Furthermore, by providing measurement results to signal to the device under test, and thereby signaling the measurement results requested by the device under test, the automated test equipment also enables simple time synchronization between the operation of the automated test equipment and the device under test, because the device under test can be confident that the measurement is complete when it receives the measurement result signaling from the automated test equipment (and the device under test also knows that the measurement will not be performed before the device under test requests the measurement of one or more physical quantities). Consequently, the mechanism disclosed herein can ensure that measurements are taken at an "appropriate time," that is, at the exact time of execution of the test case by the device under test.

[0113] In conclusion, the concept described herein significantly facilitates the work of verification engineers because control over the measurements is shifted toward the test case, good timing synchronization is provided between the device under test and the execution of the measurements, and additionally provides the device under test (or the test case executed on the device under test) with the opportunity to use the measurement results for test control.

[0114] In a preferred embodiment, the automated test equipment is configured to receive commands from the device under test in the form of parameterized messages, the parameters of the message describing the physical quantities to be measured (e.g., supply voltage, clock frequency, signal characteristics, environmental characteristics, etc.). However, it has been found that the use of parameterized messages makes it particularly easy for a verification engineer to develop tests (e.g., to develop test cases to be executed on the device under test). In particular, parameterized messages are typically particularly well readable by verification engineers, and the use of parameterized messages is well adapted to applications where different physical quantities may be measured. Thus, for example, the parameters of the message may specify which physical quantity is to be measured, and the parameters may also (optionally) provide additional information characterizing the measurement (e.g., may define whether a filter or averaging should be used, may define the measurement resolution, or may define any other settings of one or more parameters of the measurement resources of the automated test equipment). Consequently, by using these parameterized messages, the device under test can define measurement requirements in much greater detail.

[0115] Furthermore, it should be noted that messages are typically very suitable for transmission from a device under test to automated test equipment, because the device under test may include one or more protocol-based interfaces that are very suitable for the communication of messages (messages may include, for example, a message header, a message payload, and optionally error detection information or error correction information and a message terminator). However, it was also found that parameterized messages can be easily transmitted through these interfaces, and in simple cases, messages can be encoded using ASCII strings. In conclusion, it was found that the concept of receiving commands in the form of parameterized messages from a device under test can be easily implemented and enables accurate measurement definition.

[0116] In a preferred embodiment, the automated test equipment is configured to provide measurement result signaling in the form of a message. By providing measurement result signaling in the form of a message, it is typically easy to communicate the measurement results from the automated test equipment to the device under test. For example, the device under test often includes one or more interfaces (e.g., high-speed interfaces) capable of receiving (and decoding) messages. In particular, result information can typically be extracted from the message in a computationally efficient manner, for example, using a parsing function. Thus, providing measurement result signaling in the form of a message is well suited for the efficient communication of measurement results to the device under test.

[0117] In a preferred embodiment, the automated test equipment is configured to receive commands (e.g., messages from the device under test) from the device under test (preferably protocol-based) through a high-bandwidth interface (e.g., through a high-speed interface; e.g., through a USB interface or a PCI interface or a PCI-Express interface or a PCI-Express compliant interface or a Thunderbolt interface or an Ethernet interface or an IEEE-1394 interface or a SATA interface or an IEEE-1149 interface or an IEEE-1500 interface or an IEEE-1687 interface). Alternatively or additionally, automated test equipment is configured to provide measurement result signaling (e.g., measurement result message) to the device under test through a high-bandwidth interface (preferably protocol-based) (e.g., through a high-speed interface; e.g., through a USB interface or a PCI interface or a PCI-Express interface or a PCI-Express compliant interface or a Thunderbolt interface or an Ethernet interface or an IEEE-1394 interface or a SATA interface or an IEEE-1149 interface or an IEEE-1500 interface or an IEEE-1687 interface).

[0118] It has been found that these high-bandwidth interfaces are particularly well-suited for transmitting commands from a device under test to automated test equipment, and for transmitting measurement result signaling from automated test equipment to the device under test, because the high-speed interfaces typically include sufficiently low latency and sufficiently high bandwidth. Furthermore, typical devices under test inherently include one or more high-bandwidth interfaces, at least one of which is typically used when testing the device under test, for example, for uploading test cases to the device under test and / or for downloading test results from the device under test to automated test equipment. Furthermore, in many situations, at least one of the high-bandwidth interfaces is also tested by automated test equipment. Accordingly, it has been found that the function for communication between automated test equipment and the device under test, provided in many test arrangements in some way, can be efficiently reused to transmit commands requesting the measurement of one or more physical quantities from the device under test to the automated test equipment and / or to transmit measurement result signaling from the automated test equipment to the device under test. In particular, it has been found that conventional high-bandwidth interfaces have sufficient data transmission capacity to transmit measurement result signaling and / or commands requesting the measurement of one or more physical quantities, in addition to other data supporting the test of the device under test (e.g., test case data or test result data).Furthermore, by employing the concept of transmitting a command requesting the measurement of one or more physical quantities from the device under test to automated test equipment, and also using measurement result signaling, signaling the measurement results to the device under test typically makes the timing of the measurement insignificant; this enables the use of protocol-based and / or high-bandwidth interfaces that can be shared for different purposes, and thus may lead to some timing non-determinism. In conclusion, it has been found that the use of high-bandwidth interfaces for requesting measurements and / or receiving measurement result signaling provides a good trade-off between implementation effort and timing accuracy.

[0119] In a preferred embodiment, the automated test equipment is configured to perform measurements of one or more physical quantities during the execution of a test case on the device under test in response to a command provided by the device under test (e.g., under the control of a test case executed by the device under test (e.g., system-on-chip)). By having the concept that the measurement of physical quantities is requested by the device under test, it is possible to perform the measurement in good synchronization with the execution of the test case, and the execution of the test case on the device under test may be, for example, non-deterministic. In other words, according to an aspect of the invention, the automated test equipment (or a test program executed on the automated test equipment) may not have any detailed knowledge of when the measurement should be performed until the automated test equipment receives a command from the device under test requesting the measurement of one or more physical quantities. However, according to the concept, it is not necessary to interrupt the execution of the test case on the device under test for the measurement. Furthermore, it is possible to perform a measurement at a time when the measurement yields the desired result, even under the control of the test case and accordingly, taking into account the current execution state of the test case. For example, a test case running on a device under test may issue a command requesting the measurement of one or more physical quantities just before entering a phase of the test case that requests the measurement (or monitoring) of one or more physical quantities, such as current consumption or die temperature.In conclusion, by enabling the device under test to request the measurement of one or more physical quantities, it is possible to perform measurements in synchronization with the execution of the test case on the device under test without the need to interrupt the test case, and by providing measurement result signaling to the device under test, the test case also recognizes the time when the measurement is completed and the time when the test case can proceed to another processing stage. Therefore, the concept described above enables particularly fast testing because there is no longer a need to interrupt the execution of the test case for timing synchronization between the test case running on the device under test and the automated test equipment.

[0120] In a preferred embodiment, the automated test equipment is configured to provide an application programming interface (API) for use by a test case executed on the device under test. The application programming interface is configured to provide one or more routines (e.g., methods or functions) and / or routine headers (e.g., method headers or function headers) for transmitting commands requesting the measurement of one or more physical quantities from the device under test to the automated test equipment. Alternatively or additionally, the application programming interface is configured to provide one or more routines (e.g., methods or functions) or routine headers (e.g., method headers or function headers) for time synchronization between the device under test and the automated test equipment (e.g., one or more routines or routine headers for pausing program execution (e.g., of a test case executed on the device under test) until a signal indicating a measurement result is received).

[0121] By providing an application programming interface, the development of test cases by verification engineers can be significantly facilitated. For example, it may be sufficient for a verification engineer developing a test case to possess only knowledge of the syntax of methods or functions provided (or expressed) by the application programming interface, and the verification engineer may not require any detailed knowledge of the internals of the automated test equipment. Therefore, by providing an application programming interface (e.g., in the software repository of the automated test equipment), the manufacturer of the automated test equipment can provide the interface using their excellent knowledge of the details of the automated test equipment, which ultimately enables the verification engineer designing the test case to access the measurement functions provided by the automated test equipment using simple (and possibly parameterized) function calls or method calls. Additionally, the application programming interface may also enable the verification engineer designing the test case to use one or more methods or functions that support time synchronization between the device under test and the automated test equipment, such as a function or method that waits for measurement result signaling. These functions can also make measurement results available to test cases as return values, and thus support synchronization between test case execution and measurement. Furthermore, these functions enable the use of measurement results in subsequent executions of test cases.

[0122] In this case, methods or functions of the application programming interface may handle the provision of a command requesting the measurement of one or more physical quantities, and may also provide the measurement results in a form that is easy to handle by test cases (e.g., as numerical representations) by handling the evaluation of the measurement result signaling (e.g., parsing and / or conversion).

[0123] In a preferred embodiment, the automated test equipment comprises an on-chip system test (OCST) controller, a test program executor for executing a test program, and one or more tester resources (e.g., one or more device power supplies and / or one or more analog or digital signal generators and / or one or more measurement resources). The on-chip system test controller is configured to receive a command (e.g., in the form of a message) requesting the measurement of one or more physical quantities from a device under test (e.g., via a high-bandwidth interface) and to forward the command (e.g., message) to the test program executor for executing the test program. Furthermore, the test program includes a message handler configured to decode and / or interpret the forwarded message (e.g., according to one or more parameters included in the forwarded message) and then perform (e.g., execute) the measurement of one or more physical quantities in response to the (forwarded) command (e.g., in the form of the forwarded message).

[0124] Using this concept, the OCST controller can handle communication between, for example, the device under test and automated test equipment, and the on-chip system test controller may have dedicated processing means (e.g., dedicated hardware) specifically adapted for high-speed communication with the device under test. Furthermore, the on-chip system test controller may also include additional functions to support system-on-chip testing, such as uploading test programs (or test cases) to the device under test and downloading test results from the device under test. Furthermore, the on-chip system test controller may also include additional functions to enable the evaluation of test results provided by the device under test. Preferably, the on-chip system test controller may be configured to efficiently handle real-time (but typically non-deterministic or protocol-based) communication with the device under test, and thus may be highly suitable for exchanging data with the on-chip system. On the other hand, the test program executor may be configured to execute an ATE test program and may be closely linked (or communicate directly) with tester resources, such as, for example, one or more device power supplies and / or one or more digital channel modules and / or one or more analog channel modules and / or one or more measuring instruments (it is not necessary to have all of these components, and the measuring instruments may be, for example, analog channel modules or digital channel modules or part of the device power supplies).

[0125] For example, a test program executor may include a test program capable of interpreting a command requesting the measurement of one or more physical quantities and causing an appropriate measurement resource or measuring instrument to perform the requested measurement. For example, a part of the ATE test program (executed on the test program executor) responsible for interpreting and executing the commands may be independent of the program code of the test case and thus may remain the same for the test cases. Accordingly, using this concept, efficient sharing of functions may exist between the on-chip system test controller and the test program executor. The on-chip system test controller can be used for non-deterministic tasks that need to be executed, for example, in real time or at very high speeds, while the test program executor can take over tighter control of other tester resources (such as device power supplies, analog channel modules, digital channel modules, and measurement resources) and can execute a typically freely configurable ATE test program that can define the test environment for the device under test (such as, for example, one or more supply voltages, one or more clock signals, one or more predefined input signals, etc.). Accordingly, the test can be executed in an efficient manner, and the on-chip system test controller can act as an intermediary between the device under test and the test program executor.

[0126] In a preferred embodiment, a message handler (which may be part of a test program) is configured to convert a command (e.g., a message) containing a symbolic reference (e.g., "VCC2") of a test resource (e.g., a supply voltage or a signal) into a tester-hardware related measurement command (e.g., a command to perform a measurement of voltage, temperature, or signal characteristics).

[0127] By using this command conversion that utilizes symbolic references, engineers can use symbolic references that are easy to understand in their test programs, while the message handler converts these commands into tester-hardware related measurement commands. Accordingly, it should be noted that verification engineers programming test cases do not need to possess any knowledge of the internals of the automated test equipment and can use symbolic references in an efficient manner, and that the use of symbolic references is typically much less prone to errors than the specifications of specific hardware resources of the automated test equipment. In contrast, the message handler can be adapted (e.g., by an engineer well-versed in the internal physical details of the automated test equipment) to make an assignment between the symbolic reference and the physical tester hardware associated with the said symbolic reference in the current tester configuration (e.g., considering both the physical resources of the automated test equipment and the connections between specific pins (or pads) of the device under test and the physical resources of the ATE).

[0128] By using this concept, test cases can be used on different tester hardware because they use commands that include symbolic references, while only the message handler needs to be adapted to specific hardware (e.g., available tester resources and connections between the ATE hardware and the pins of the device under test). As a result, high efficiency in test case development can be achieved.

[0129] In a preferred embodiment, a message handler is configured to generate a measurement result message and to provide the generated measurement result message to an on-chip system test controller (e.g., after the execution of a measurement). Furthermore, the on-chip system test controller is configured to forward the measurement result message provided by the message handler to the device under test, or to provide the measurement result message to the device under test in response to the measurement result message provided by the message handler. By using this concept, the ability of the on-chip system test controller to communicate efficiently with the device under test (e.g., using a protocol-based high-speed interface) can be utilized, while the measurement result message is generated (or executed) by a message handler that typically involves more direct access to tester resources (e.g., measurement resources). Thus, the measurement result can be communicated to the device under test (or to a test case executed on the device under test) in a very efficient manner, and the on-chip system test controller can forward the measurement result in an unchanged manner or apply some message transformation to adapt the measurement result message (e.g., to the requirements of the specific high-speed interface being used). Therefore, a highly resource-efficient concept can be achieved.

[0130] In a preferred embodiment, an automated test device (e.g., a test program executor of the automated test device) is configured to execute a test program. The test program is configured to initialize the tester resources of the automated test device to enable the initiation of program execution on the device under test. Furthermore, the test program is configured to perform additional updates to the test resources under the control of the device under test (e.g., under the control of one or more test cases executed on the device under test). Alternatively, the test program is configured to perform one or more measurements under the control of the device under test (e.g., under the control of one or more OCST test cases executed on the device under test).

[0131] Using this concept, a test program (i.e., an ATE test program that can be executed, for example, on a test program executor of automated test equipment) can take over multiple functions. For example, the test program can pre-configure the tester resources of the automated test equipment to enable reliable startup of the device under test by setting the power supplies to provide a supply voltage that enables highly reliable operation of the device under test. Accordingly, the test program executed on the test program executor of the automated test equipment can support the safe uploading of test cases to the device under test by providing reliable conditions.

[0132] Furthermore, the test program can control (or at least support) the uploading of initial program code that enables, for example, the initialization of the device under test and optionally, for example, the establishment of communication between the device under test and the on-chip system test controller using a high-speed interface. By performing additional updates to test resources under the control of the device under test, the test environment of the device under test can be changed to, for example, be more "challenging" than the initial test environment, thereby enabling the execution of test cases under "stress" conditions. By enabling additional updates to test resources under the control of the device under test, tests can be defined primarily by test cases executed on the device under test, which brings significant advantages in test development. Furthermore, the updating of test resources (and consequently the updating of the test environment) under the control of the device under test enables good coordination between the execution of test cases on the device under test and variations in the test environment without requiring modification of the ATE test program by the verification engineer defining the tests. Furthermore, by selectively providing the device under test (or test case) with control over both updates to the test environment and measurements to be performed by the resources of the automated test equipment, the test case to be executed by the device under test can control a very large portion of all functions required for thorough testing of the device under test. Consequently, test design becomes particularly easy. Moreover, there is efficient sharing of functions between the test case to be executed on the device under test and the ATE-side test program.

[0133] In a preferred embodiment, the automated test equipment includes an on-chip system test controller. The automated test equipment includes one or more tester resources, such as one or more device power supplies and / or one or more analog or digital signal generators and / or one or more measurement resources. The on-chip system test controller is coupled to one or more tester resources (e.g., directly coupled; e.g., coupled in a manner that bypasses a test program executor). Furthermore, the on-chip system test controller is configured to provide control signals to one or more tester resources (e.g., via a data bus and / or via one or more synchronization lines and / or via a synchronization bus) to perform measurements of one or more physical quantities in response to a command from the device under test.

[0134] By using this configuration, where the on-chip system test controller has direct access to tester resources (bypassing the test program executor), measurements can be performed particularly quickly without interfering with the execution of the ATE test program executed by the test program executor. Using this concept, the capabilities of the on-chip system test controller to perform protocol-based high-speed communication with the device under test in an efficient manner (e.g., using dedicated hardware) can be utilized. By providing the on-chip system test controller with the ability to directly control one or more tester resources, such as one or more measurement resources, delays caused by the test program executor can be avoided. Furthermore, interference with the operation of the test program executor by commands requesting the measurement of one or more physical quantities can also be avoided, allowing the test program executor to handle its task of evaluating test results more efficiently. Consequently, faster and more resource-efficient execution of tests can be achieved.

[0135] In a preferred embodiment, the on-chip system test controller is configured to convert a command (e.g., a message) containing a symbol reference (e.g., "VCC2") of a tester resource (e.g., a supply voltage or a signal) (or to a tester resource) into a tester-hardware related measurement command (e.g., a command to perform measurements of one or more physical quantities by a measurement resource of an automated test equipment).

[0136] Providing the on-chip system test controller with the capability to convert commands containing symbolic references into tester-hardware-related measurement commands enables the tester-hardware-agnostic development of test cases to be executed on the device under test. By using symbolic references in commands transmitted from the device under test to automated test equipment, test cases can be used in different hardware configurations of the automated test equipment, and the mapping from the symbolic references to the actual physical resources of the tester (ATE) can be defined once for the current tester configuration and provided to the on-chip system test controller as configuration information. Consequently, it is easy to use automated test equipment with different hardware configurations without adapting the test cases.

[0137] In a preferred embodiment, the on-chip system test controller is coupled to one or more tester resources via a data bus and a synchronization line or a synchronization bus. Furthermore, the on-chip system test controller is configured to prepare (e.g., initialize) a measurement (e.g., voltage measurement, current measurement, or temperature measurement) of a selected physical quantity (e.g., supply voltage or supply current or ambient temperature) via the data bus according to message parameters of a command received from the device under test (e.g., message parameters defining the physical quantity to be measured). Furthermore, the on-chip system test controller is configured to trigger a measurement of the physical quantity to be measured by the synchronization bus or by the synchronization line (e.g., using a synchronization bus event or a synchronization bus message).

[0138] Using this concept, an on-chip system test controller can perform measurements with high timing accuracy. By pre-configuring the measurement of selected physical quantities, the settings of the measurement resources can be prepared so that the measurement resources can respond very quickly to the trigger of the measurement. Accordingly, the on-chip system test controller can first initialize the measurement resources according to message parameters (message parameters can determine, for example, what voltage to measure and / or what filtering or averaging to use for these measurements), and then the actual measurement can be triggered by the on-chip system test controller with high timing accuracy. Accordingly, the device under test may even be able to request a specific measurement timing, and the on-chip system test controller can first pre-configure the measurement (for example, by setting individual measurement resources to an appropriate state or configuration) and then trigger the measurement resources at the desired timing. As a result, highly accurate measurements that meet the requirements defined in the test case can be performed.

[0139] In a preferred embodiment, the on-chip system test controller is configured to provide measurement result signaling (e.g., in the form of a measurement result message) to the device under test. By having a function for providing measurement result signaling to the device under test implemented within the on-chip system test controller, high efficiency and short latency can be achieved.

[0140] An embodiment according to the present invention creates a device under test. The device under test is configured to provide a command (e.g., in the form of a message) requesting the measurement of one or more physical quantities to an automated test device (e.g., under the control of a test case executed on the device under test). Furthermore, the device under test is configured to wait for the reception of a measurement result signaling (e.g., a measurement result message) indicating a measurement result requested by the device under test (e.g., by pausing the execution of the test case until the measurement result requested by the device under test is received by the device under test). Such a device under test can efficiently control the measurements of one or more physical quantities and additionally time-synchronize the execution of the test case with these measurements. By waiting for a measurement result signaling indicating a measurement result requested by the device under test, the device under test can avoid proceeding to a test execution (e.g., where the test result could be falsified) before the measurement result is actually obtained. Therefore, this procedure enables the acquisition of reliable measurement results under the control of the device under test, even if there may not be perfect timing synchronization between the execution of test cases on the device under test and the automated test equipment. For example, the device under test can maintain the conditions for measurement until it receives the measurement result signaling, and consequently, the validity of the measurement result can be guaranteed.

[0141] Therefore, reliable measurements can be made even without a perfect timing synchronization mechanism between the device under test and the automated test equipment (which may be true for many system-on-chips that do not involve strict timing determinism).

[0142] In a preferred embodiment, the device under test is a system-on-chip. The device under test is configured to execute a test case (e.g., performing a test to test the device under test). Furthermore, the device under test is configured to provide commands to automated test equipment under the control of the test case. It has been found that the concept disclosed herein is particularly suitable for testing a system-on-chip capable of executing a test case using, for example, one or more internal processors or processor cores. In particular, it has been found that the test case is highly suitable for providing commands to automated test equipment because the test case typically accesses one or more high-speed interfaces using, for example, a basic interface driver.

[0143] In a preferred embodiment, the device under test is configured to provide a command in the form of a parameterized message, and the parameters of the message describe one or more physical quantities to be measured, such as supply voltage, supply current, clock frequency, signal characteristics, environmental parameters, etc.

[0144] The aforementioned advantages can be achieved by using parameterized messages. In particular, the use of parameterized messages facilitates verification engineers in writing test programs, as they can use one or more parameters to describe which physical quantity should be measured and, optionally, which measurement settings (e.g., measurement range, averaging operation, filtering operation, etc.) should be applied when performing the measurement. Furthermore, by using parameters that can define, for example, the quantity to be measured (e.g., a specific voltage at a specific pin of the device under test, or a specific current flowing through a specific pin of the device under test), the command set can be kept small, and the actually measured quantity can be described by the parameters. This enables highly "readable" code, which allows for efficient communication between the device under test and automated test equipment (e.g., an on-chip system test controller or test program executor can evaluate commands and the parameters described within the commands). Furthermore, it should be noted that the use of messages is particularly well-suited for transmission over high-speed interfaces (e.g., protocol-based), as many high-speed interfaces are typically well-suited for the transmission of messages (messages may include, for example, a message data payload containing a message header, a message identifier, and parameters, and optionally error detection or error correction information and optionally a message terminator). These well-defined messages can typically be easily transmitted over high-speed interfaces, and individual interface drivers present on the device under test can support message transmission. Thus, a highly efficient concept is provided.

[0145] In a preferred embodiment, the device under test is configured to receive measurement result signals in the form of messages. As previously mentioned, the messages are highly suitable for communication through high-speed interfaces (e.g., protocol-based), enabling high-speed communication through interfaces that can also be shared for other functions (e.g., for uploading test cases to the device under test and / or for downloading test results from the device under test to automated test equipment).

[0146] By evaluating the measurement result signal in the form of a message, the message can be detected, for example, by parsing the information received toward the device under test. Since messages featuring a message header are typically used, the message signaling the measurement result can be easily distinguished, for example, from other received information. Therefore, since message parsing can be achieved with reasonable effort, the reception of measurement result signaling in the form of a message has been found to be highly advantageous.

[0147] In a preferred embodiment, the device under test is configured to provide commands (e.g., messages to automated test equipment) to automated test equipment through a high-bandwidth interface (based on a preferred protocol) (e.g., through a high-speed interface; e.g., a USB interface or a PCI interface or a PCI-Express interface or a PCI-Express compliant interface or a Thunderbolt interface or an Ethernet interface or an IEEE-1394 interface or a SATA interface or an IEEE-1149 interface or an IEEE-1500 interface or an IEEE-1687 interface, etc.). Alternatively or additionally, the device under test is configured to receive measurement result signaling (e.g., measurement result messages) (e.g., from automated test equipment) through a high-bandwidth interface (based on a preferred protocol) (e.g., through a high-speed interface; e.g., through a USB interface or a PCI interface or a PCI-Express interface or a PCI-Express compliant interface or a Thunderbolt interface or an Ethernet interface or an IEEE-1394 interface or a SATA interface or an IEEE-1149 interface or an IEEE-1500 interface or an IEEE-1687 interface).

[0148] The use of these interfaces brings the advantages discussed above. In particular, the provision of commands to automated test equipment and / or the reception of measurement result signaling through these high-bandwidth interfaces enables very fast communication and, additionally, allows for the reuse of said high-bandwidth interfaces for other purposes, such as updating test cases for the device under test or providing test result data to automated test equipment. Furthermore, high-bandwidth interfaces typically have sufficient bandwidth to transmit measurement-related information (e.g., commands requesting a measurement and measurement result signaling) in addition to other payloads. Also, high-bandwidth interfaces can often mix different types of payloads (e.g., to insert short messages into other data communication processes). Consequently, efficient use of the available resources of the device under test is possible. Moreover, the high-bandwidth characteristics of the interfaces typically also result in relatively low latency, which is advantageous for triggering measurements and helps reduce test time.

[0149] In a preferred embodiment, the device under test is configured to use one or more library routines (e.g., of a software library provided by an automated test device) to provide commands and / or evaluate measurement result signaling (the use of library routines may be enabled, for example, by an application programming interface provided by an automated test device).

[0150] The use of one or more library routines to provide commands and / or evaluate measurement result signaling brings about the benefits discussed above and significantly facilitates the development of test cases to be executed on the device under test. In addition, the risk of error is reduced.

[0151] In a preferred embodiment, the device under test is configured to continue test case execution according to the measurement result indicated by the measurement result signaling (e.g., by selectively branching according to the measurement result).

[0152] Accordingly, the execution of test cases can be based on actual measurement results, which can, for example, help identify the maximum rating of the device under test. For example, if a particular test case causes excessive current consumption or excessive heating of the device under test, subsequent tests can be executed with reduced processing load to avoid excessive stress on the device under test. Thus, the device under test, or equivalently, the test case executed on the device under test, can efficiently consider the measured results and adapt its test case execution accordingly.

[0153] An embodiment according to the present invention creates a test setup. The test setup includes automated test equipment as previously discussed and a device under test as previously discussed. The test setup is based on the same considerations as the automated test equipment and the device under test discussed above. The test setup may optionally be supplemented by any of the features, functions, and details disclosed herein for both the automated test equipment and the device under test. The test setup may optionally be supplemented by these features, functions, or details, all taken individually and in combination.

[0154] An embodiment according to the present invention provides a method for operating an automated test apparatus. The method comprises the step of receiving a command (e.g., in the form of a message) from a device under test requesting the measurement of one or more physical quantities. The method further comprises the step of performing or initiating the measurement of one or more physical quantities in response to the command provided by the device under test. Furthermore, the method comprises the step of signaling the measurement result requested by the device under test by providing the device under test with a measurement result signaling (e.g., a measurement result message). The method is based on the same considerations as the automated test apparatus described above. Furthermore, the method may optionally be supplemented by any of the features, functions, and details disclosed herein in relation to the automated test apparatus. The method may be supplemented by such features, functions, and details, all taken individually and in combination.

[0155] An embodiment according to the present invention provides a method for testing a device under test. The method comprises the step of providing a command (e.g., in the form of a message) requesting the measurement of one or more physical quantities from the device under test to an automated test device (e.g., under the control of a test case executed on the device under test) under the control of a test case executed on the device under test. Furthermore, the method comprises the step of pausing the execution of a test case (e.g., under the control of a test case) until a measurement result signaling (e.g., a measurement result signal or a measurement result message) indicating the measurement result requested by the device under test is received by the device under test (and detected, e.g., by a test case). Furthermore, the method comprises the step of performing the measurement of one or more physical quantities in response to the command provided by the device under test. Furthermore, the method comprises the step of signaling the measurement result requested by the device under test by providing the measurement result signaling (e.g., a measurement result message) to the device under test. Furthermore, this method includes the step of continuing the execution of a test case in response to the reception of a measurement result signaling by the device under test.

[0156] This method is based on the same considerations as the automated test equipment and the device under test described above. This method may optionally be supplemented by any of the features, functions, and details disclosed herein for the automated test equipment and also for the device under test. This method may optionally be supplemented by such features, functions, and details, all taken individually and in combination.

[0157] Another embodiment according to the present invention generates a computer program for carrying out this method.

[0158] Another embodiment according to the present invention creates an automated test device for testing one or more devices under test. The automated test device is configured to receive a command (e.g., in the form of a message) from a test case requesting the measurement of one or more physical quantities (e.g., a supply voltage provided to the device under test, e.g., a current supplied to the device under test, e.g., a signal characteristic of a signal provided to the device under test, e.g., a clock frequency of a clock signal provided to the device under test, e.g., environmental parameters such as temperature, humidity, atmospheric pressure, magnetic field, or electric field in the environment of the device under test). Furthermore, the automated test device is configured to perform or initiate the measurement of one or more physical quantities in response to the command provided by the test case. Furthermore, the automated test device is configured to signal the measurement result to the test case by providing the measurement result signaling (e.g., an acknowledgment message) to the test case.

[0159] This automated test equipment is based on the same considerations as the automated test equipment described above, and the test case serves as the automated test equipment. However, it should be noted that while the test case may preferably be executed on the device under test, it may also be distributed between the device under test and the automated test equipment. Furthermore, this automated test equipment may optionally be supplemented by any of the features, functions, and details disclosed herein in relation to other automated test equipment. The automated test equipment may be supplemented by such features, functions, and details, all taken individually and in combination.

[0160] Another embodiment according to the present invention provides a method for operating automated test equipment. The method comprises the step of receiving a command (e.g., in the form of a message) requesting the measurement of one or more physical quantities from a test case (e.g., which may be executed on a device under test but may also be distributed between the device under test and the automated test equipment). The method further comprises the step of performing or initiating the measurement of one or more physical quantities in response to the command provided by the test case. Furthermore, the method comprises the step of signaling the measurement result requested by the test case by providing the test case with a measurement result signaling (e.g., a measurement result message).

[0161] This method is based on the same considerations as the method described above, and the test case acts as the device under test. This method may optionally be supplemented by any of the features, functions, and details taken individually or in combination.

[0162] Another embodiment according to the present invention generates individual computer programs. Brief explanation of the drawing

[0163] Next, embodiments according to the present invention will be described with reference to the accompanying drawings. FIG. 1a illustrates a schematic representation of an automated test equipment according to an embodiment of the present invention. FIG. 1b illustrates a schematic representation of a device under test according to an embodiment of the present invention. FIG. 2a illustrates a schematic representation of an automated test equipment according to an embodiment of the present invention. FIG. 2b illustrates a schematic representation of a device under test according to an embodiment of the present invention. FIG. 2c illustrates a schematic representation of an automated test equipment according to an embodiment of the present invention. FIG. 3a illustrates a schematic representation of an automated test equipment according to an embodiment of the present invention. FIG. 3b illustrates a schematic representation of a device under test according to an embodiment of the present invention. Figure 4 illustrates a schematic representation of on-chip system test (OCST) / functional test upload and control by test pattern. FIG. 5 illustrates a schematic representation of on-chip system test (OCST) / functional test upload and control by high-speed input / output (IO). Figure 6 illustrates a schematic representation of the deformation by using individual controllers for OCST / function testing. FIG. 7 illustrates a schematic representation of an on-chip system test (OCST) extended by a tester resource control path according to an embodiment of the present invention. FIG. 8 illustrates a schematic representation of a variation including an OCST controller to include a tester resource control path according to an embodiment of the present invention. FIG. 9 illustrates a graphic representation of a message flow for tester resource control according to an embodiment of the present invention. FIG. 10 illustrates a schematic representation of OCST extended by a tester resource measurement path according to an embodiment of the present invention. FIG. 11 illustrates a schematic representation of a variation including an OCST controller to include a tester resource control path according to an embodiment of the present invention. FIG. 12 illustrates a graphic representation of a message flow for measuring tester resources according to an embodiment of the present invention. FIG. 13 illustrates a schematic representation of a production tester controlled by an on-chip system test according to an embodiment of the present invention. FIG. 14 illustrates a schematic representation of a production tester controlled by an on-chip system test according to an embodiment of the present invention. FIG. 15 illustrates a schematic representation of a scenario in which a functional test case is fully positioned on the DUT according to an embodiment of the present invention. FIG. 16 illustrates a schematic representation of a scenario in which a functional test is logically separated into a DUT portion and a workstation portion according to an embodiment of the present invention. FIG. 17 illustrates a schematic representation of a concept including library support ATE environment control according to an embodiment of the present invention. FIG. 18 illustrates a schematic representation of a resource controlled by a data and synchronization bus according to an embodiment of the present invention. FIG. 19 illustrates a schematic representation of a tester resource controlled by a GPO trigger according to an embodiment of the present invention. Specific details for implementing the invention

[0164] 1. Automated test equipment according to Fig. 1a

[0165] FIG. 1a illustrates a schematic representation of an automated test equipment according to an embodiment of the present invention.

[0166] The automated test equipment illustrated in FIG. 1a is designated as 100. The automated test equipment is typically intended to be coupled with the device under test (110). The automated test equipment (100) is configured to receive a command (122) requesting an update of one or more tester resources from the device under test (110) (or equivalently from a test case). Furthermore, the automated test equipment is configured to update one or more tester resources in response to the command (122) provided by the device under test (110). Furthermore, the automated test equipment is configured to signal the completion of the tester resource update requested by the device under test (110) by providing an acknowledgment signaling (124).

[0167] Accordingly, the automated test equipment (100) enables the device under test (110) to exercise control over one or more test resources by providing a command (122) requesting an update of one or more test resources. Accordingly, the device under test (110) may issue a command that causes the automated test equipment to change the parameters of the test resources, for example, to change the supply voltage of the device under test (110) or to change the characteristics of other signals provided to the device under test at the request of the device under test (110). Furthermore, the automated test equipment (100) also provides an acknowledgment signaling (124) to the device under test so that the device under test (110) becomes aware of the execution of the update of one or more test resources. Accordingly, the device under test (110) may use the acknowledgment signaling (124) to determine when to continue the test execution that may require the requested update of one or more test resources for proper execution. Accordingly, reliable testing can be performed under the control of the device under test.

[0168] Furthermore, it should be noted that the automated test equipment (100) may be optionally supplemented by any of the features, functions, and details disclosed herein, all taken individually and in combination.

[0169] 2. Test subject device according to Fig. 1b

[0170] FIG. 1b illustrates a schematic representation of a test target device (200) according to an embodiment of the present invention. The test target device (200) may be configured to execute a test case, for example. Accordingly, the test target device (200) may be configured to provide a command (212) (e.g., in the form of a message) requesting an update of one or more tester resources (e.g., to an automated test device). The provision of the command (212) may be under the control of a test case executed on the test target device, for example. The generation of the command (212) may be performed on the test target device (200), for example, using a library routine that can define a function to generate the command and enable the generation of the command in a user-friendly manner.

[0171] Furthermore, the device under test is configured to receive an acknowledgment signal (214) indicating the completion of a tester resource update. Furthermore, the device under test is configured to pause the execution of a test case until an acknowledgment signaling (214) (e.g., an acknowledgment message) indicating the completion of a tester resource update requested by the device under test is received by the device under test. For this purpose, for example, the device under test (200) may be configured to evaluate the acknowledgment message using, for example, a library routine. For example, the library routine may define a function for detecting or evaluating the acknowledgment signaling (214), and may also provide a function to pause the execution of a test case until, for example, the acknowledgment signaling is received (or detected) in a user-friendly manner.

[0172] Accordingly, the device under test may command an automated test equipment (e.g., automated test equipment (100)) to update one or more tester resources, and the device under test (200) may also synchronize the execution of the test case with the completion of the update of one or more tester resources by, for example, pausing the execution of the test case until an acknowledgment signaling (214) is received. Consequently, the device under test (200) (or equivalently, the test case running on the device under test) may request an update of the test environment in which the device under test (200) operates, and may also be guaranteed to continue the execution of the test case only when one or more test resources have been updated by pausing the execution of the test case until an acknowledgment signaling is received. Consequently, the test may largely be performed under the control of the device under test, and higher reliability of the test may be achieved by evaluating an acknowledgment signaling indicating the completion of the tester resource update.

[0173] Furthermore, it should be noted that the device under test (200) may be optionally supplemented by any of the features, functions, and details described herein, all taken individually and in combination.

[0174] 3. Automated test equipment according to Fig. 2

[0175] FIG. 2 illustrates a schematic representation of an automated test equipment (240) according to an embodiment of the present invention. The automated test equipment (240) includes a trigger line (250) (e.g., a hardware trigger line, e.g., a GPO trigger line) controllable by a device under test (242) (or equivalently by a test case that can be executed on the device under test (242)). For example, the trigger line may be controllable by a general-purpose output of the device under test and may respond to a single edge, for example. Furthermore, the automated test equipment is configured to update one or more tester resources in response to activation of a trigger line (250) (e.g., in the sense of single / simple toggling of a state) by the device under test (242) (or equivalently by a test case that can be executed on the device under test). (e.g., to change one or more supply voltages provided to the device under test (242) by the automated test equipment, or to change one or more signal characteristics of one or more analog or digital signals provided to the device under test (242) by the automated test equipment.

[0176] Accordingly, the automated test equipment (240) can enable the device under test (242) to trigger an update of one or more tester resources by the (simple) activation of the trigger line (250) (e.g., in the sense of generating a single edge or pulse on the trigger line). Accordingly, the automated test equipment (240) provides the device under test (242) with very precise timing control for the update of one or more test resources, because the trigger for the update of one or more tester resources can be directly influenced by the device under test and therefore is not influenced by latencies that may exist in the test program executor of the automated test equipment and / or the on-chip system test controller of the automated test equipment (240). Thus, the automated test equipment (240) enables very high timing accuracy that can be directly controlled by the device under test (242). Accordingly, the device under test (242) can trigger an update of one or more tester resources at a time that is very well controllable by the device under test. Consequently, the device under test can rapidly continue the execution of the test (e.g., the execution of a test case) after the activation of the trigger line, because the device under test needs to consider only the typically low latency of the actual tester resources, and not the (typically non-deterministic) latency of the test program executor of the automated test equipment and / or the latency of the on-chip test controller of the automated test equipment and / or the latency of protocol-based communication.

[0177] As a result, particularly fast testing can be achieved, which is well controlled by the device under test (and consequently by test cases typically executed on the device under test). Additionally, by providing a trigger line (on the ATE side), the device under test may need to activate (or toggle) only a single pin coupled to the trigger line, which is typically possible with very low software effort and requires the use of only a single pin of the device under test. Consequently, the automated test equipment (240) provides excellent support for testing the device under test, which can control its own test environment by causing the automated equipment to update one or more tester resources.

[0178] Furthermore, it should be noted that the automated test equipment (240) may be optionally supplemented by any of the features, functions, and details described herein, all taken individually and in combination.

[0179] 4. Test subject device according to Fig. 2b

[0180] FIG. 2b illustrates a schematic representation of a test target device (260) according to an embodiment of the present invention. The test target device (260) may be configured to execute, for example, a test case (262). Furthermore, the test target device (260) is configured to trigger an update of one or more tester resources via a dedicated trigger line by providing a trigger signal (264) (e.g., to automated test equipment). In this regard, it should be noted that the test target device (260) may correspond, for example, to a test target device (242), and the trigger signal (264) may be provided, for example, to a trigger line (250).

[0181] Furthermore, it should be noted that, for example, the device under test may be under the control of a test case (262) executed by the device under test. Furthermore, it should be noted that, optionally, the device under test (260) may also be configured to provide a command (266) that defines one or more parameters for updating one or more tester resources. Accordingly, the device under test (260) can prepare automated test equipment (or tester resources of automated equipment) for updating one or more test resources by defining, prior to the activation of the trigger signal (264), what new parameters each individual one or more tester resources should be set to in response to the activation of the trigger signal. Accordingly, the device under test has a very high degree of control over its test environment. By optionally providing a command (266) that defines one or more parameters for updating one or more tester resources, the device under test can determine details regarding the update of one or more tester resources. Furthermore, by the activation of the trigger signal (264), the device under test can determine with very high timing accuracy when updates to one or more tester resources should be executed. As a result, the device under test (260) can, for example, control most of the test with high timing accuracy, and thus can execute the test quickly, and the synchronization overhead for synchronization with automated test equipment is relatively small.

[0182] Furthermore, it should be noted that the device under test (260) may be optionally supplemented by any of the features, functions, and details disclosed herein, all taken individually and in combination.

[0183] 5. Automated test equipment according to Fig. 2c

[0184] FIG. 2c illustrates a schematic representation of an automated test equipment (280) according to an embodiment of the present invention. The automated test equipment (280) includes a test program executor (282) configured to execute a test program (284). Furthermore, the automated test equipment (280) also includes an on-chip system test controller (286) that may be configured to support testing of a system-on-chip. Furthermore, the automated test equipment (280) includes a plurality of tester resources (288a, 288b, 228c). For example, the tester resources (288a to 288c) may include a device power supply and / or a digital channel module (or digital signal module) and / or an analog channel module (or analog signal module) and / or a signal generator module. For example, one or more of the tester resources (288a, 288b, 288c) may include a trigger mechanism (289c), which may perform, for example, a change in the configuration of the individual tester resource, which is also designated as an update of the individual tester resource. For example, a test program executor (282) may be coupled to the tester resources (288a, 288b, 288c) through an interface and may, for example, program one or more tester resources. For example, the test program executor may be able to set one or more parameters of the tester resources (288a, 288b, 288c) and may also be configured to pre-program the behavior of one or more tester resources represented by one or more tester resources in response to the activation of a trigger line that may be coupled to the trigger mechanism (e.g., the trigger mechanism (289c)). Furthermore, the automated test equipment may include a test target device interface (290), and signals (292a, 292b, 292c) of one or more tester resources may be provided to the test target device through the test target device interface (290).Furthermore, the device interface under test may also have a trigger input (294) (e.g., as part of the device interface under test (290)), and the trigger input may be configured to receive a trigger signal from the device under test and may be coupled to a trigger line (295) that may be directly coupled to trigger mechanisms of one or more tester resources (288a to 288c), for example. For example, FIG. 2c shows that the trigger line (295) is coupled to a trigger mechanism (289c) of a tester resource (288c), but other tester resources (288a, 288b) may also include individual trigger mechanisms.

[0185] Furthermore, the automated test equipment (280) may be configured to receive a command (296) that defines one or more parameters for updating one or more tester resources through the test target device interface (290). This command (296) may preferably be received from the test target device, but generally speaking, this command may also be received from a test case (which may be executed on the test target device and also partially on the test target device and partially on the automated test equipment). The command (296) may be received, for example, by an on-chip system test controller (286) or by a test program executor (282). In some configurations, the command (296) may also be first received by an on-chip system test controller (286) and then forwarded from the on-chip system test controller (286) to a test program executor (282) (in its original form or in a modified form). The test program executor (282) may preconfigure one or more of the tester resources (288a, 288b, 288c) in response to the command, for example.

[0186] Accordingly, one or more test resources pre-configured in response to a command (296) defining one or more parameters for updating one or more test resources can subsequently respond to the activation of a trigger line (295) by the device under test by changing one or more parameters, and said change (e.g., one or more new parameters to be used after the change) is defined, for example, by the pre-configuration. Consequently, one or more test resources can respond very quickly to the activation of the trigger line, and there may be no need to provide any additional information to one or more test resources (288a to 288c) at the time when actual updates of one or more test resources are required. Consequently, the device under test can exercise very fast control over the configuration of one or more test resources.

[0187] Furthermore, it should be noted that a command defining one or more parameters for updating one or more test resources may alternatively be received from the test case. Such a command is designated as 298. The command from the test case may be directed to an on-chip system test controller (286) or a test program executor (282). In relation to this matter, it should be noted that the test case may be executed, for example, only on the device under test, and alternatively, the test case may be executed partly on the device under test and partly on automated test equipment. However, while the command (298) may affect the preconfiguration of one or more test resources and thereby define the response of one or more test resources to the activation of a trigger line, the trigger signal may still be received from the device under test, for example, via an input (294).

[0188] In conclusion, the automated test equipment (280) provides the device under test with the possibility to perform (or trigger) a change in the signal characteristics of one or more signals provided to the device under test in a very simple manner, simply by the activation of a trigger line, and typically with very small latency.

[0189] Furthermore, it should be noted that the automated test equipment (280) may be optionally supplemented by any of the features, functions, and details disclosed herein, all taken individually and in combination.

[0190] 6. Automated test equipment according to Fig. 3a

[0191] FIG. 3a illustrates a schematic representation of an automated test device (300) according to an embodiment of the present invention. The automated test device (300) is configured to test a test target device (310) that can be coupled to the automated test device. For example, the automated test device is configured to receive a command (322) (e.g., in the form of a message) requesting the measurement of one or more physical quantities from the test target device (310), such as a supply voltage provided to the test target device, a current supplied to the test target device, a signal characteristic of a signal provided by the test target device, a clock frequency of a clock signal provided to the test target device, or environmental parameters such as temperature, humidity, atmospheric pressure, magnetic field, or electric field in the environment of the test target device. Furthermore, the automated test device is configured to perform or initiate the measurement of one or more physical quantities in response to the command provided to the test target device.

[0192] For example, the automated test equipment may cause one or more internal measurement resources of the automated test equipment to measure (or trigger) one or more physical quantities specified in a command. For example, the measurement functions of one or more channel modules of the automated test equipment may be used to perform the measurement. Alternatively, however, the automated test equipment may control one or more external measurement resources (such as external precision measuring equipment or external high-frequency measuring equipment, or external optical measuring equipment) to perform the requested measurement. Furthermore, the automated test equipment is configured to signal the measurement result requested by the device under test (310) by providing the device under test with a measurement result signaling (324) (e.g., an acknowledgment message or a message containing the measurement result).

[0193] Accordingly, the automated test equipment (300) enables the device under test (310) to trigger measurements to be performed (or initiated) by the automated test equipment, so that, for example, the test case executed on the device under test can define which measurements are taken at any point in the execution of the test case. As a result, measurements can be taken under the control of the device under test, which significantly facilitates test development, because a large portion of the activities to be performed by the automated test equipment during the execution of the test case can be defined in the test case itself.

[0194] Furthermore, by providing measurement result signaling that can signal measurement results to the device under test and also indicate to the device under test that the measurement is complete, the device under test is made able to use the measurement results. For example, the device under test can use the measurement results to decide on further execution of test cases based on the measurement results. As another example, the device under test (310) can use the measurement results to generate test result information. In conclusion, the automated test equipment (300) enables the device under test to request measurements and also forwards the measurement results to the device under test. Accordingly, tests or test cases can generally be executed under the control of the device under test, which significantly facilitates the creation of test cases and enables the definition of very powerful and efficient test cases that can even utilize measurement results for the control of test case execution.

[0195] Furthermore, it should be noted that the automated test equipment (300) may be optionally supplemented by any of the features, functions, and details disclosed herein, all taken individually and in combination.

[0196] 7. Test subject device according to Fig. 3b

[0197] FIG. 3b illustrates a schematic representation of a test target device (350) according to an embodiment of the present invention. The test target device (350) is configured to provide a command (312) (e.g., in the form of a message) requesting the measurement of one or more physical quantities (e.g., under the control of a test case executed on the test target device). Furthermore, the test target device (350) is configured to wait for the reception of a measurement result signaling (314) (e.g., a measurement result message) indicating the measurement result requested by the test target device (e.g., by pausing the execution of the test case until the measurement result requested by the test target device is received by the test target device).

[0198] Accordingly, the device under test (350) can initiate the execution of a measurement by an automated test device (or by an external measurement device coupled to the automated test device), and the device under test can also receive the measurement result and synchronize the execution of a test case on the device under test with the measurement. For example, a measurement result signaling (314) may indicate that the measurement is complete so that the device under test can continue the execution of the test case when the measurement result signaling (314) is received by the device under test (350). Consequently, the device under test (350) can be assured that the execution of the test case (e.g., having a new test phase) will not continue before the measurement is complete, which helps to avoid falsification of the measurement result. Furthermore, the device under test (or the test case executed on the device under test) may consider the measurement result to make a decision on how to further execute the test case, for example. Accordingly, the device under test (350) has a large degree of control over the test, because the test case executed on the device under test can determine the processing operations performed on the device under test and also determine the measurements to be made by the automated test equipment, and the described mechanism, which provides a command requesting the measurement of one or more physical quantities and waits for the reception of the measurement result signaling from the automated test equipment, enables good time synchronization between the test case executed on the device under test and the measurements to be made by the automated test equipment.

[0199] Furthermore, it should be noted that the device under test (350) may be optionally supplemented by any of the features, functions, and details disclosed herein, all taken individually and in combination.

[0200] 8. Measurement arrangement according to Fig. 7

[0201] FIG. 7 illustrates a schematic representation of a measurement arrangement (700) according to an embodiment of the present invention. The measurement arrangement (700) includes automated test equipment (710) and a device to be tested (730). The automated test equipment (710) includes tester resources (720) and a workstation (722), and the workstation (722) may be adapted to execute an ATE test program (724). The device to be tested (730) may be configured to execute an OCST test case (740).

[0202] The tester resources (720) of the automated test equipment (710) may include, for example, one or more digital channels (or digital channel modules) and / or one or more analog channels (or channel modules) and / or one or more power supplies (e.g., device power supplies). Accordingly, the tester resources (720) may be coupled with the device under test (730). For example, one or more digital channels of the tester resources (720) may be coupled with digital pins of the device under test (730) (e.g., digital inputs or digital outputs or digital input / outputs). Alternatively or additionally, one or more analog channels of the tester resources (720) may be coupled with one or more analog pins of the device under test (730) (e.g., analog inputs or analog outputs or analog inputs / outputs). Alternatively or additionally, one or more supply lines that can be combined with one or more power supplies from the tester resources (720) or device power supplies may be combined with the device under test (730) (e.g., supply pins or supply pads of the device under test (730)). Accordingly, analog and / or digital signals may be provided to the device under test (730) by individual tester resources. Furthermore, one or more supply voltages and / or supply currents may be provided to the device under test (730) by individual tester resources. Generally speaking, the combination between the tester resources (720) and the device under test (730) may be used for DUT supply, test interaction, and ATE control signals for measurement. In particular, it should be noted that the combination between the tester resources (720) and the device under test (730) may be, for example, bidirectional.For example, one or more digital signals and / or one or more analog signals may be provided to the device under test (730) using individual tester resources. Alternatively or additionally, one or more digital signals and / or one or more analog signals may be provided by the device under test (730) and received (and typically evaluated) by individual tester resources (720). For example, the tester resources (720) may provide one or more digital and / or analog stimulus signals to the device under test (730) and optionally also evaluate one or more digital and / or analog response signals of the device under test. If the device under test (730) includes a system-on-chip, the tester resources (720) may be used, for example, to initialize this system-on-chip or, for example, to enable safe startup of the device under test (730) by applying appropriate signals. Furthermore, tester resources (720) may be used to upload a test program and / or a basic operating system to a test device (e.g., using the JTAG port of the test device, etc.) in order to prepare for the execution of a test case (740) on the test device (730).

[0203] Furthermore, the device under test (730) may be combined with automated test equipment to enable, for example, on-chip system test-test case upload (OCST-TC upload) and execution control. For example, the automated test equipment (710) may be adapted to enable communication between the ATE test program (724) and the OCST test case (740) (or more generally, between the workstation (722) and the device under test (730). For example, for communication between the automated test equipment and the device under test (for example, for communication between the ATE test program and the OCST test case, or for communication between the ATE test program and the control software running on the device under test (730), the control software may have the function of, for example, enabling the upload of one or more test cases and enabling the control of the execution of one or more test cases). High-speed input / output (HSIO) (e.g., high-speed interface) may be used. For example, HSIO may include a USB interface and / or a PCIe interface or an Ethernet interface (ETH), or any other type of high-speed interface. In conclusion, generally speaking, OCST-TC upload and execution control can be performed using a high-speed interface (or high-bandwidth interface or high-data-rate interface) between the automated test equipment and the device under test.

[0204] Furthermore, the ATE and the device under test may be configured to allow the OCST test case (740) to request resource updates. For example, the OCST test case (740) may request resource updates from the ATE test program (724), for example, using a parameterized message. Furthermore, the ATE test program (724) may provide an acknowledgment to the OCST test case (740) (for example, in the form of an acknowledgment message or in the form of an acknowledgment signaling). Thus, there may be message exchanges between the OCST test case (740) and the ATE test program (724), for example, using a resource update request message (750), also designated as a resource update request message, and an acknowledgment message (752), also designated as an acknowledgment message. For example, message exchanges including the resource update request message (750) and the acknowledgment message (752) may be used for tester resource control via HSIO. In other words, the resource update request message (750) and the acknowledgment message (752) can be exchanged between the OCST test case (740) and the ATE test program (724), for example, using HSIO. For example, the message exchange including the resource update request message (750) and the acknowledgment message (752) can use the same HSIO, which is also used for OCST test case upload and execution control.

[0205] Accordingly, the OCST test case (740) has the function of performing test routines on the device under test, and also has the function of requesting changes to the test environment of the DUT by requesting a resource update using a resource update request message (750). Furthermore, the OCST test case (740) also receives an acknowledgment message (752) and can use this acknowledgment message for timing synchronization.

[0206] For example, a resource update request message (750) may request that the parameters of one of the test resources (720) be changed (or updated). Just as an example, the OCST test case (740) may request that the supply voltage provided to the device under test (730) be changed by changing the settings of the device power supply that is part of the test resources (720). Furthermore, the ATE test program provides an acknowledgment message (752) to the OCST test case (740) (or, generally speaking, to the device under test (730)) to signal that the resource update is complete, and the OCST test case (740) may continue the execution of a new test phase after receiving the acknowledgment message (752). Accordingly, the OCST test case can be assured that appropriate test conditions exist for the test (or for the new test phase) as requested.

[0207] In conclusion, the test arrangement (700) according to FIG. 7 enables a very efficient test, and control of test execution can be performed to a significant extent by OCST test cases.

[0208] Furthermore, it should be noted that, as described herein, the ATE itself should be considered as an embodiment of the present invention. Furthermore, it should be noted that the device under test as described herein should also be considered as an embodiment of the present invention. Furthermore, it should be noted that the test arrangement, the automated test equipment, and the device under test may be complemented by any of the features, functions, and details disclosed herein, which are optionally taken individually and in combination.

[0209] 9. Test arrangement according to Fig. 8

[0210] FIG. 8 illustrates a schematic representation of a test arrangement (800) according to an embodiment of the present invention.

[0211] Test arrangement (800) is similar to test arrangement (700). Accordingly, the above description of test arrangement (700) is referenced.

[0212] The test arrangement (800) includes automated test equipment (810) and a device to be tested (830). The automated test equipment (810) includes, for example, tester resources (820) that are very similar to tester resources (720), and the above descriptions also apply. The automated test equipment (810) also includes a workstation (822) that may be similar to a workstation (722). The workstation (822) is adapted to execute an ATE test program capable of taking over various functions. For example, the ATE test program (824) may be configured to perform initialization of the tester resources (e.g., tester resources (820)). For example, the ATE test program (824) may be configured to initialize the tester resources (820) to enable the start of program execution on the device to be tested (830). Furthermore, the ATE test program (824) may include, for example, a message handler. The message handler may, for example, perform transformations of messages and may include, for example, the generation of acknowledgment messages. Furthermore, the ATE test program may be configured to perform additional updates to one or more of the tester resources (820) under the control of the device under test, for example, in response to a message evaluated by the message handler.

[0213] However, in addition to the tester resources (820) and workstation (822), the test equipment (810) also includes an on-chip system test controller (826) that can be connected, for example, between the device under test (830) and the workstation (822). For example, the on-chip system test controller may be configured to receive a request for resource updates from the device under test (830) or from an OCST test case (832) running on the device under test (830). Furthermore, the on-chip system test controller (826) may be configured to forward such requests or commands. Alternatively, or additionally, the OCST controller (826) may be configured to perform command conversion, for example, by converting a request for resource updates (850) from a first command format to a second command format. For example, an on-chip system test controller (826) may be configured to provide a request (860) for a resource update to a workstation (822) or to an ATE test program (824). For example, the OCST controller (826) may forward the request (or request message) (850) without correction so that the request (or request message) (860) may be identical to the request (or request message) (850). However, the OCST controller (826) may also perform a conversion so that the request (or request message) (850) for a resource update provided by the OCST test case (832) may be converted into a different format so that the format of the request (or request message) (860) for a resource update is different from the format of the request (or request message) (850) for a resource update.However, it should be noted that the OCST controller (826) can handle, for example, a high-speed interface protocol and, by, for example, unwrapping a request (or request message) (850) from a communication protocol, forward the unwrapped request (or request message) to the ATE test program (824). That is, the OCST controller can, for example, extract a representation of the request (or request message) from the communication protocol and provide the "plain" form of the request to the ATE test program (824).

[0214] Furthermore, the OCST controller (826) may receive acknowledgment information (or acknowledgment signaling or acknowledgment message) from the ATE test program (824) and may forward this acknowledgment information to the OCST test case (832). However, the OCST controller (826) may, for example, receive acknowledgment information from the ATE test program (824) (for example, acknowledgment information acknowledging updates to one or more tester resources in response to a request issued by the OCST test case) and may generate acknowledgment signaling or acknowledgment message to be forwarded to the OCST test case (832). For example, the acknowledgment information provided to the OCST controller (826) by the ATE test program is designated as 862, and the acknowledgment signaling or acknowledgment message or acknowledgment information provided to the OCST test case (832) by the OCST controller (826) is designated as 852. For example, message exchange for tester resource control can be performed using HSIO (e.g., using a high-speed interface or a high-bandwidth interface). For example, a high-speed interface or a high-bandwidth interface may be used for communication between the OCST controller (826) and the OCST test case (832), and the OCST controller (826) may provide hardware support for the use of such high-speed interfaces, for example (high-speed interfaces are typically protocol-based, and the OCST controller (826) may include support for handling the protocols of the high-speed interfaces). Furthermore, the device under test (830) may also typically include support for high-speed interfaces, such as appropriate high-speed interface drivers and dedicated hardware that provide access to the high-speed interfaces to the OCST test case (832).Optionally, a high-speed interface may also be used for communication between the OCST controller (826) and the workstation (822) or the ATE test program (824). For example, HSIO may be used for transmitting a resource update request message (860) from the OCST controller (826) to the ATE test program (824) and also for providing acknowledgment information (862) from the ATE test program (824) to the OCST controller (826). However, different types of interfaces may be used for communication between the ATE test program and the OCST controller, and for communication between the OCST controller and the OCST test case.

[0215] Additionally, the ATE test program (824) may communicate with the OCST controller (826), for example, to upload and / or control the execution of OCST test cases. Furthermore, communication may also exist between the OCST controller (826) and the OCST test case (832) for uploading and / or controlling the execution of OCST test cases. For example, the ATE test program (824) may provide the OCST controller (826) with an OCST test case to be uploaded to the device under test using an appropriate interface between the ATE test program (824) and the OCST controller (826). Furthermore, the OCST controller (826) may upload such an OCST test case to the device under test using an appropriate interface between the OCST controller (826) and the device under test (830) (or test case (832)). Similarly, to control the execution of a test on the device under test, communication may exist between the ATE test program (824) and the OCST controller (826). This communication may be, for example, bidirectional. Additionally, to control the execution of a test case, communication may also exist between the OCST controller (826) and the OCST test case (832). This communication may also be bidirectional.

[0216] For example, communication between the ATE test program (824) and the OCST controller for OCST test case upload and execution control can be performed using a high-speed interface (HSIO), such as a USB interface, a PCIe interface, or an Ethernet interface (ETH). Furthermore, communication between the OCST controller (826) and the OCST test case (832) for OCST test case upload and execution control can also be performed using a high-speed interface (HSIO), such as a USB interface, a PCIe interface, or an Ethernet interface (ETH).

[0217] However, it should be noted that, for example, a request (850) and an acknowledgment (852) for a resource update may be communicated using the same high-speed interface as OCST test case upload and / or execution control. Similarly, a resource update request message (or signaling or command) (860) and an acknowledgment (862) may be communicated using the same high-speed interface as OCST test case upload and / or execution control. In other words, the high-speed interface between the OCST controller and the OCST test case may be shared, for example, for OCST test case upload and execution control and also for messages (850, 852). Similarly, the high-speed interface between the ATE test program (824) and the OCST controller (826) may be shared for messages (860, 862) and for OCST test case upload and / or execution control.

[0218] In conclusion, in the test arrangement (800) according to FIG. 8, the OCST controller (826) may be used as an intermediary between, for example, the ATE test program (824) and the device under test (830) (or OCST test case (832)). For example, the OCST controller may take over time-critical (and possibly non-time-deterministic) communication with the device under test (830) or the OCST test case (832) under the superior control of, for example, the ATE test program (824). Thus, the OCST controller (826) may take over the task of, for example, uploading one or more test cases to the device under test (830) and issuing commands to control the execution of one or more test cases (e.g., to test case executor software running on the device under test (830)). Furthermore, the OCST controller can also handle, for example, the download of test results from the DUT and, optionally, perform preprocessing of these test results before reporting the test results or a preprocessed version thereof to the ATE test program (824).

[0219] Furthermore, the OCST controller (826) can act as an intermediary, for example, when an OCST test case requests a resource update. The OCST controller (826) can forward this request for a resource update to the ATE test program (824), and the ATE test program (824) can handle direct communication with the tester resources (820).

[0220] However, alternatively, the OCST controller (826) may also be coupled to the tester resources (820) using, for example, a data bus and / or a synchronization bus and / or one or more synchronization lines. Thus, the OCST controller (826) may optionally access the tester resources (820) directly (e.g., bypassing the workstation (822) and the ATE test program (824)) and perform an update of one or more tester resources as requested by the OCST test case (832) by using the direct connection between the OCST controller (826) and the tester resources (820) (e.g., a data bus and / or a synchronization bus and / or one or more synchronization lines). In this case, the OCST controller also does not need to forward the resource update request message (860) to the ATE test program (824) or receive an acknowledgment (862) from the ATE test program (824).

[0221] In conclusion, the general concept for handling a resource update request message (850) from an OCST test case (832) in an automated test facility may be supported by an OCST controller (826), or the OCST controller may act as an intermediary between the OCST test case (832) and the ATE test program (824), or the OCST controller (826) may directly handle the requested resource update (e.g., by using a direct connection with tester resources (820). Furthermore, the OCST controller may also support the forwarding of an acknowledgment (852) to the OCST test case, for example, by acting as an intermediary between the ATE test program (824) and the OCST test case, or provide an acknowledgment message (852) under its control. Consequently, a high level of control over the ATE test process is provided to the OCST test case (832).

[0222] It should be noted that an embodiment of the present invention can be verified in an automated test device (810) including an OCST controller (826). Furthermore, another embodiment according to the present invention can be verified in a device under test (830).

[0223] Furthermore, it should be noted that the test arrangement (800), the automated test equipment (810), or the device under test (830) may be supplemented by any of the features, functions, and details disclosed herein, when taken optionally, individually, or in combination.

[0224] 10. Message flow according to Fig. 9

[0225] FIG. 9 illustrates a schematic representation of a message flow for tester resource control that can be used in embodiments according to the present invention. For example, the message flow can be used in any of the automated test equipment disclosed herein. For example, the message flow of FIG. 9 can be used in a test arrangement (800) according to FIG. 8.

[0226] Regarding the message flow, it should be noted that there are four entities accompanying the message flow: for example, a tester resource (910) that corresponds to a tester resource (820), for example, an ATE test program (920) that corresponds to an ATE test program (824), for example, an OCST controller (930) that corresponds to an OCST controller (826), and for example, an OCST test case (940) that corresponds to an OCST test case (832).

[0227] The message flow may begin, for example, with the fact that an OCST test case is running, which is illustrated by reference number (950). A tester resource update request may exist within the test case (e.g., in the form of a program command), which is illustrated by reference number (952). In response to a test resource update request in the test case, a message (954) may be executed, and the message (954) may be transmitted, for example, from the test case (or from the device under test) to the OCST controller (930). The message may include, for example, the command "Set VCC1 to 5.5 volt" (e.g., in an encoded form). This message may be encoded, for example, using a predefined syntax, and may be represented, for example, by an appropriate ASCII string. The message (954) may be received by the OCST controller (930), and the OCST controller (930) may forward the message to the ATE test program. The forwarding of the message is illustrated by reference number (956), and the forwarded version of the message is illustrated by reference number (958). The forwarded message (958) may contain, for example, the same format as message (954) and may express, for example, the command "Set VCC1 to 5.5 volt". However, when forwarding message (954), the OCST controller (930) may, for example, unwrap message (954) from protocol-based high-speed communication so that message (958) can be handled more easily by the ATE test program. Optionally, the OCST controller may also perform message conversion when providing message (958) based on message (954), for example, in the form of syntax conversion. However, the OCST controller (930) may also forward message (954) in an unchanged manner so that message (958) is identical to message (954).

[0228] In the ATE test program (920), a message handler may be active, which is illustrated in reference number (962). The message handler may recognize the reception of message (958), and, for example, parse message (958) and / or interpret message (958). For example, a message handler within the ATE program may "decode" message (958) and convert message (958) into a physical command (964), which causes a requested update of the tester resource and is forwarded to the tester resource (910). For example, the message handler (962) may receive and evaluate message (958) and convert the message into a bus access command representing a requested update of the tester resource. For example, the message handler may replace the symbolic reference (e.g., "VCC1") with a low-level (e.g., bus access) command that instructs the appropriate tester resource (e.g., a device power supply providing a supply voltage referenced as "VCC1") to take a desired value. For this purpose, the message handler may also convert the numeric representation within the message (958) into a numeric representation that is adapted to the specific tester resource. Thus, the ATE test program (920) provides a message (964) that causes the desired update of the test resource. In this case, message decoding causes, for example, an update of the VCC1 supply to 5.5 volts. Furthermore, the test resource (910) may provide the ATE test program (920) with an "update successful" message (966) (which may be considered optional, for example). Accordingly, the ATE test program (920) can recognize that the resource update is complete. However, the ATE test program can also conclude that the update was successfully completed from the timing evaluation.For example, the ATE test program (920) may assume that the test resource update has been successfully completed when a specific amount of time has elapsed since the provision of the update command for the tester resource (910), for example.

[0229] However, when the ATE test program confirms that the tester resource update is successful (e.g., based on the update success message (966) or based on the time evaluation), the ATE test program provides an acknowledgment message (968) to the OCST controller. Furthermore, in response to the receipt of the acknowledgment message (968), the OCST controller (930) provides an acknowledgment message (e.g., an acknowledgment message due to a successful voltage update) to the OCST test case (940). The acknowledgment message provided from the OCST controller to the OCST test case may be designated as 970. For example, the OCST controller (930) may simply forward the acknowledgment message (968) to the OCST test case, or the OCST controller (930) may generate an acknowledgment message (970) in response to the receipt of the acknowledgment message (968) from the ATE test program. Subsequently, the OCST test case receives an acknowledgment for the tester resource update and continues execution, which is illustrated by reference number (974).

[0230] However, according to one aspect, the OCST test case (940) may be in a “waiting for acknowledgment” state between the transmission of the message (954) and the reception of the acknowledgment message (970). During this waiting condition, the OCST test case may, for example, pause the execution of the test case, or the OCST test case may perform one or more tests that do not require updates to test resources and, preferably, may be insensitive to updates to test resources. However, the OCST test case may delay the execution of any tests that require updates to test resources until the acknowledgment message (970) is received. By using this message flow, reliable execution of test cases that require updates to test resources can be performed largely under the control of the test case.

[0231] It should be noted that the message flow described herein may be optionally used in any of the embodiments according to the present invention, and that message (954) may be provided by an OCST test case, message (970) may be evaluated by an OCST test case, message (954) may be received by automated test equipment, and 970 may be provided by automated test equipment. Messages (958, 964, 966, 968) may be ATE internal messages.

[0232] Furthermore, it should be noted that the message flow according to FIG. 9 may be supplemented by any of the features, functions, and details disclosed in this specification, which are optionally taken individually and in combination.

[0233] 11. Test arrangement according to Fig. 10

[0234] FIG. 10 illustrates a schematic representation of a test arrangement according to an embodiment of the present invention. It should be noted that the test arrangement (1000) according to FIG. 10 is similar to the tester arrangement (700) according to FIG. 7, and therefore the same components will not be described again herein. Rather, the descriptions above are referenced.

[0235] The test arrangement (1000) includes automated test equipment (1010) which may be similar to automated test equipment (710). The automated test equipment (1010) may include one or more tester resources (1020) which may be similar to tester resources (720). However, it should be noted that one or more tester resources (1020) may include at least one measurement resource configured to measure physical quantities, such as, for example, physical characteristics of an analog or digital signal provided to a device under test or physical characteristics of an analog or digital signal received from a device under test. However, the tester resources (1020) may also include a measurement resource configured to measure environmental parameters, such as temperature, pressure, humidity, etc. (e.g., in the environment of the device under test). The automated test equipment (1010) also includes a workstation (1022) which may be similar to a workstation (722). The workstation (1022) can be configured to run an ATE test program (1024).

[0236] Furthermore, there exists a test target device (1030) that can be combined with one or more tester resources (1020) in a manner described, for example, with reference to FIG. 7. Thus, one or more connections may exist between one or more tester resources (1020) and the test target device (1030), and these connections provide, for example, ATE control signals for DUT supply, test interaction, and measurement.

[0237] However, the test arrangement (700) is distinguished from the test arrangement (1000) in that a different type of communication is performed between the OCST test case (1040) and the ATE test program (1024). In the test arrangement (1000), the OCST test case (1040) is configured to request a resource measurement from the ATE test program (1024). For this purpose, the OCST test case (1040) transmits a resource measurement request message (1050) (also designated as a resource measurement request message) to the ATE test program (1024), which may be, for example, a parameterized message. In response to this message (1050), the ATE test program (1024) may command one of the tester resources, such as a measurement resource, to perform the requested measurement and provide the measurement result. For example, the ATE test program (1024) may command the device power supply to perform a current measurement. Alternatively, the ATE test program (1024) may command a digital channel module to perform a measurement of a digital signal provided by the device under test, or the ATE test program (1024) may command an analog channel module to perform a measurement of an analog signal provided by the device under test. However, the ATE test program (1024) may alternatively command a measurement resource (which may be part of the tester resources (1020)) to perform any other measurement of a physical quantity.

[0238] When the measurement is completed, the ATE test program (1024) can provide the measurement result message to the OCST test case (1040). The measurement result message is designated as 1052.

[0239] Accordingly, the OCST test case (1040) may request a measurement to be performed by one of the test resources, and the ATE program (1024) responds to this request by commanding the appropriate measurement resource to perform the measurement. Subsequently, the ATE test program (1024) reports the measurement result to the OCST test case using a measurement result message (1052). The OCST test case may wait for the measurement result message (1052), for example, to ensure that the measurement result is not falsified by the execution of an unsuitable test case step. Thus, it is possible for the OCST test case to exercise a high level of control and be time-synchronized with the measurement. Furthermore, the measurement result may be considered in a subsequent execution of the OCST test case.

[0240] Furthermore, it should be noted that the test arrangement (1000) may also be supplemented by any of the features, functions, and details described herein, all taken individually and in combination. Furthermore, it should be noted that an automated test device (1010) may be considered as an embodiment of the present invention. Similarly, a device under test (1030) may also be considered as an embodiment of the present invention.

[0241] 12. Test arrangement according to Fig. 11

[0242] FIG. 11 illustrates a schematic representation of a test arrangement (1100) according to an embodiment of the present invention. The test arrangement (1100) includes an automated test equipment (1110) and a test target device (1130).

[0243] The automated test equipment (1110) may include, for example, test resources (1120) that correspond to test resources (1020). Furthermore, the automated test equipment (1110) includes, for example, a workstation (1122) that corresponds to the workstation (1020) described above. The workstation (1122) is configured to execute an ATE test program (1124) that corresponds to, for example, an ATE test program (1024). However, in addition to the automated test equipment (1010), the automated test equipment (1110) also includes an on-chip system test controller (1150) that can be combined, for example, with the workstation (1122) and optionally also with the tester resources (1120). In addition, the on-chip system test controller (1150) is typically configured to receive a resource measurement request (1160) from the device under test (1130) or from a test case (1140) running on the device under test (1130), and to provide a measurement result (1162) to the OCST test case (1140) running on the device under test (1130) or to the device under test (1130).

[0244] For example, the OCST controller (1150) may be coupled with the device under test (1130) for message exchange for tester resource measurement via a high-speed interface (HSIO). Furthermore, the OCST controller (1150) may also be coupled with a workstation (1122) to provide a resource measurement request (or resource measurement request message) (1170) to the workstation (1122) or to an ATE test program (1124) running on the workstation (1122). Furthermore, the OCST controller may also be configured to receive a measurement result (or measurement result message) (1172) from the workstation (1122) or from the ATE test program (1124). In other words, the OCST controller (1150) may also be configured to perform message exchange for tester resource measurement with the workstation (1122) or the ATE test program (1124) via a high-speed interface (HSIO). However, it should be noted that the high-speed interface between the OCST controller (1150) and the workstation (1122) may, of course, be different from the high-speed interface between the device under test (1130) and the OCST controller (1150). Additionally, the OCST controller may also be configured to communicate (e.g., bidirectionally) with the device under test (1130) (or with the OCST test case (1140)) to perform OCST test case upload and / or execution control. Furthermore, the OCST controller (1150) may also be configured to communicate (e.g., bidirectionally) with the workstation (1122) or with an ATE test program (1124) running on the workstation (1122) to perform OCST-TC upload and / or execution control.To perform OCST-TC upload and / or execution control, communication between the OCST controller (1150) and the DUT (1130) may use, for example, a high-speed interface (e.g., USB, PCIe, ETH, or any other suitable high-speed interface).

[0245] Similarly, communication between the ATE test program (1124) or workstation (1122) and the OCST controller (1150) for performing or supporting or controlling OCST-TC upload and / or execution control can be performed, for example, using a high-speed interface (e.g., USB, PCIe, ETH, or any other suitable interface). Accordingly, the OCST controller can support on-chip-system testing. For example, by having a particularly good ability to perform high-speed communication with the device under test or with the OCST test case (1140), the OCST controller (1150) can perform the upload of the on-chip system test-test case to the device under test (1130) in a particularly fast manner, which helps to speed up the test. Furthermore, the on-chip system test controller (1150) can also provide execution control information and / or execution control commands to the device under test (1130) or the OCST test case (1140), for example, through a high-speed interface. Thus, the OCST controller can help perform OCST tests in a fast and time-saving manner. However, for example, the OCST controller (1150) can receive an OCST test case from an ATE test program capable of controlling the entire test flow. Furthermore, the ATE test program can also provide information regarding the desired entire test flow to the OCST controller (1150), so that the OCST controller (1150) can provide execution control information and / or execution control commands to the device under test (1130) or the OCST test target device (1140) based on this. Therefore, the OCST test controller (1150) can act as an intermediary between the workstation (1122) or ATE test program (1124) on one side and the DUT (1130) or OCST test case (1140) on the other side.

[0246] Furthermore, the OCST test controller (1150) may also act as an intermediary in the resource measurement procedure described herein. For example, the OCST controller may be configured to receive a resource measurement request (1160) from an OCST test case (1140) and forward this resource measurement request (which may also be considered as a resource measurement command or a resource measurement request message) to a workstation (1122) or an ATE test program (1124) (e.g., in the form of a resource measurement request (1170)). The OCST controller may forward the resource measurement request in its original form and may, for example, handle only the communication protocol of the high-speed interface between the OCST controller (1150) and the DUT (1130). However, the OCST controller (1150) may alternatively also perform a conversion of the resource measurement request, which may be considered as a "command conversion." Accordingly, the OCST controller (1150) may provide a resource measurement request (1170) such that the resource measurement request (1170) becomes a converted version of the resource measurement request (1160). For example, the OCST controller (1150) may perform this command conversion if appropriate considering a specific interface or communication format between the OCST controller (1150) and the workstation (1122).

[0247] Furthermore, the OCST controller (1150) can forward measurement result information (1172) provided by the workstation (1122) or provided by the ATE test program (1124) to the DUT (1130) or the OCST test case (1140) in an unchanged manner, and the OCST controller (1150) can take over protocol handling for a high-speed interface between the OCST controller (1150) and the device under test (1130), for example. However, the OCST controller (1150) can also generate measurement results (1162) based on the measurement result information (1172) received from the workstation (1122) or the ATE test program (1124).

[0248] In conclusion, the OCST controller may act as a "simple intermediary" that merely forwards resource measurement requests (1160) from the OCST test case (1140) to the ATE test program (1124) without corrections and forwards measurement results (1172) from the ATE test program (1124) to the OCST test case (1140) without corrections, and merely handles high-speed communication protocols. However, alternatively, the OCST controller may also include extended functions (in addition to protocol handling) such as command conversion and / or measurement result message conversion or measurement result message generation.

[0249] Accordingly, an OCST test case (1140) executed on a device under test (1130) may provide a command requesting the measurement of one or more physical quantities (e.g., a resource measurement request (1160)) and may receive measurement result signaling (1162). An OCST controller (1150) acts as an intermediary and takes over protocol handling for high-speed communication between the automated test equipment (1110) and the device under test (1130). The OCST controller (1150) also communicates with an ATE test program (1124) and forwards the resource measurement request (1160) to the ATE test program (1124) in its original form or in a converted form. Furthermore, the OCST controller (1150) also acts as an intermediary for measurement result signaling from the ATE test program (1124) to the OCST test case (1140). Additionally, the OCST controller optionally takes over functions in OCST test case upload and / or execution control, for example, the same physical interface between the OCST controller (1150) and the device under test (1130) can be used on one side for OCST test case upload and / or execution control and on the other side for transmitting resource measurement requests (1160) and measurement result signaling (1162). Accordingly, the high-speed interface between the OCST controller (1150) and the device under test (1130) can be used in a particularly advantageous manner for a number of purposes.

[0250] Furthermore, it should be noted that the explanation in Fig. 10 is also referenced in relation to the basic function of the concept.

[0251] Additionally, it should be noted that the test arrangement (1100) may be supplemented by any of the features, functions, and details described herein, which are optionally taken individually and in combination. Furthermore, it should be noted that both the automated test equipment (1110) and the test target device (1130) described herein should be considered as embodiments of the present invention.

[0252] 13. Test flow according to Fig. 12

[0253] FIG. 12 illustrates a schematic representation of a test flow (1200) according to an embodiment of the present invention. The test flow can be executed, for example, in a test arrangement (1100).

[0254] FIG. 12 illustrates a communication or message flow involving a tester resource (1210) (e.g., corresponding to a tester resource (1120)), an ATE test program (1220) (e.g., corresponding to an ATE test program (1124)), an OCST controller (1230) (e.g., corresponding to an OCST controller (1150)), and an OCST test case (1240) (e.g., corresponding to an OCST test case (1140)). As can be seen, an OCST test case is running, as illustrated in reference number (1250). The OCST test case transmits a message (1254) requesting the measurement of a physical quantity, e.g., the message "Measure VCC1", to the OCST controller (1230). The OCST controller (1230) includes a message forwarding function (1256). In this example, the OCST controller (1230) forwards this message to the ATE test program (1220) in the form of a message (1258), for example. For example, the message (1258) still contains the command "Measure VCC1". The ATE test program (1220) includes a message handler (1262) that is active and evaluates the message (1258) received from the OCST controller.

[0255] The message handler (1262) may, for example, perform message decoding of the message (1258) and consequently provide a message (or command) (1264) to the test resource (1210), said command (1264) affects the requested measurement of a physical quantity. For example, the message or command (1264) may be in the form of a (physical) hardware command that causes the test resources (1210) to perform the desired measurement. Accordingly, the ATE test program (1220) receives measurement result information (1266) (e.g., a measurement result message) from the test resource (1210). The measurement result information (1266) may, for example, indicate a specific value of the physical quantity (e.g., VCC1 to be measured). However, it should be noted that the ATE test program (1220) can actively read measurement result information (1266) from, for example, a tester resource (1210). Alternatively, the tester resource (1210) can also provide the measurement result information (1266) to the ATE test program (1220) in the form of a measurement result message. Consequently, the ATE test program (1220) can generate a result message (1268) indicating the value of the physical quantity to be measured and provide this measurement result message to the OCST controller (1230). The OCST controller (1230) can, for example, forward the measurement result message (1268) to an OCST test case in the form of a measurement result message (1270). However, it should be noted that the OCST controller (1230) may optionally include a function to convert the message (1268) into the message (1270), for example, by modifying the syntax. Subsequently, the OCST test case (1240) can receive and evaluate the measurement result message (1270). For example, the OCST test case (1240) can parse the result message (1270) and extract measurement result information from the measurement result message (1270).Additionally, optionally, test case execution may continue based on the received results (e.g., based on measurement results). However, alternatively, the OCST test case (1240) may simply store the measurement results and report them back to the automated test equipment later (or use them for test case-side determination of test results).

[0256] In conclusion, using the message flow of FIG. 12, an OCST test case can request the measurement of a physical quantity, and the automated test equipment can utilize the protocol handling capabilities of the OCST controller (1230) to handle this request. Thus, the measurement results can be signaled to the OCST test case (1240) in an efficient manner, and the OCST test case (1240) can use the test results.

[0257] Furthermore, it should be noted that the message flow (1200) according to FIG. 12 may be used in any of the embodiments according to the present invention, and the message flow (1200) of FIG. 12 may be supplemented by any of the features, functions and details described herein when taken optionally, all individually and in combination.

[0258] 14. Test arrangement according to Fig. 13

[0259] FIG. 13 illustrates a schematic representation of a test arrangement (1300) according to an embodiment of the present invention. The test arrangement (1300) includes an automated test equipment (1310), which may correspond to other automated test equipment described herein. For example, the automated test equipment (1310) may include a workstation (1322) and tester resources (1320) that may be configured to execute an ATE test program (1324). The automated test equipment (1310) may also include a so-called "FT service device (1350)" which may be a functional test case service device that may be a CPU-assisted hardware instance including a DUT test controller. The test controller of the FT service device (1350) is designated as 1352. For example, the test controller (1352) may be configured to communicate with the ATE test program (1324) using a so-called "DCCP-IF" which may be a data, control, and communication path interface. In addition, the test controller (1352) may also be configured to communicate with a test case (1340) executed on the test target device (1330) through a DCCP interface which is a data, control, and communication path interface.

[0260] Regarding the function of the test arrangement (1300), reference is made to the discussion above, for example, and it should be noted that the automated test equipment (1310) may correspond to, for example, the automated test equipment (810) or the automated test equipment (1110). Furthermore, it should be noted that the FT service device (1350) may correspond to, for example, the OCST controller (826) or the OCST controller (1150). The DCCP interface (1360) may take on the function of interfaces between, for example, the OCST controller (826) and the ATE program (824), and the DCCP interface (1362) may take on the role of interfaces between, for example, the OCST controller (826) and the OCST test case (832).

[0261] As can be seen from FIG. 13, for example, it may be sufficient to have a single DCCP interface (1362) between the test controller (1352) and the test case (1340), said single DCCP interface (1362) may be used for, for example, to upload and / or control the execution of the OCST test case, and also for transmitting resource update requests (e.g., 850) and acknowledgment signaling (e.g., 852). Similarly, a single DCCP interface (1360) between the test controller (1352) and the ATE test program (1324) may be sufficient. For example, this single DCCP interface (1360) may be used for OCST test case upload and / or execution control, and may also be used for sending resource update requests (e.g., 860) from the test controller (1352) to the ATE test program (1324) and for sending acknowledgment signaling (e.g., 862) from the ATE test program (1324) to the test controller (1352).

[0262] In conclusion, FIG. 13 illustrates a test arrangement (1300) in which a functional test case (1340) is fully positioned on a device under test (1330). The DCCP interface to the test controller (1352) is realized by a physical interface, such as, for example, HSIO PCIe or USB.

[0263] However, it should be noted that the test arrangement (1300) may be supplemented by any of the features, functions, and details disclosed herein, which are optionally taken individually and in combination. Furthermore, it should be noted that both the automated test equipment (1310) and the device under test (1330) may be considered as embodiments according to the present invention.

[0264] 15. Test arrangement according to Fig. 14

[0265] FIG. 14 illustrates a schematic representation of a test arrangement (1400) according to an embodiment of the present invention. The test arrangement (1400) includes an automated test equipment (1410) that may be similar to the test arrangement (1300), with reference to the above discussion. The test arrangement (1400) also includes a test target device (1430) similar to the test target device (1330), with reference to the above descriptions.

[0266] The automated test equipment (1410) includes test resources (1420) similar to test resources (1320), and the automated test equipment (1410) also includes a workstation (1422) similar to a workstation (1322). Accordingly, the above description is referenced. For example, an ATE test program (1424) is executed on the workstation (1422), and the test program (1424) may be similar or identical to the test program (1324) executed on the workstation (1322). Furthermore, the automated test equipment (1410) includes a functional test case service device (1450) which is also designated as an FT service device (FSI). The functional test case service instrument (1450) can correspond to, for example, the functional test case service instrument (1350) and can take over the function of, for example, the on-chip system test controller (e.g., the on-chip system test controller (826)).

[0267] However, in the test arrangement (1400) according to FIG. 14, the test case (1440) is distributed between the device under test (1430) and the functional test case service device (1450). For example, part of the test case may be executed on the functional test case service device (1450), and other part of the test case may be executed on the device under test (1430). Just as an example, the functional test case service device (1450) may include a hardware component that communicates closely with the device under test (1430) and can substitute for hardware that must be coupled to the device under test (1430) in a real environment, for example.

[0268] According to the aspect, there may be a DCCP interface (1462) between the test controller (1452) of the functional test case service device (1450) and the test case (1440). Accordingly, the DCCP interface (1462) may enable, for example, OCST test case upload and / or execution control, and may also handle the transmission of resource update requests (e.g., 850) and the transmission of acknowledgment signaling (e.g., 850). Furthermore, a DCCP interface (1460) also exists between the test controller (1452) and the ATE test program (1424).

[0269] In conclusion, in the test arrangement (1400) according to FIG. 14, the functional test case is logically separated into a DUT part and an FSI part. The DCCP interface between the test controller and the test case is realized, for example, by software running on the FSI. Software for handling the physical connection between the FSI and the DUT is located, for example, inside the test case.

[0270] Furthermore, it should be noted that the test arrangement (1400) according to FIG. 14 may be supplemented by any of the features, functions, and details described herein, which are optionally taken individually and in combination.

[0271] Furthermore, it should be noted that both the ATE (1410) and the device under test (1430) can be considered as embodiments according to the present invention.

[0272] In conclusion, FIG. 14 illustrates an extension handling an additional interface topology for communication with a test case. According to one aspect, integration of DUT interface control within the test case may exist. However, integration of DUT interface control within the test case is also within the scope of the present invention.

[0273] 16. Test arrangement according to Fig. 15

[0274] FIG. 15 illustrates a schematic representation of a test arrangement (1500) according to an embodiment of the present invention. The test arrangement (1500) includes automated test equipment (1510) and a device to be tested (1530). The automated test equipment (1510) includes test resources (1520) and a workstation (1522), and an ATE test program (1524) is executed on the workstation (1522). Furthermore, a test case (1540) is executed on the device to be tested.

[0275] With respect to automated test equipment, a test arrangement (700) according to FIG. 7, which includes similar functions, is referenced. For example, automated test equipment (1510) may correspond to automated test equipment (710), and a test target device (1530) may correspond to a test target device (730). As can be seen in FIG. 15, a DCCP interface (1550) exists between the ATE test program (1524) and the test case (1540). For example, the DCCP interface (1550) may be used for OCST test case upload and / or execution control as described with reference to FIG. 7, and the DCCP interface (1550) may also be used for resource update requests (1550) (e.g., 750) and for acknowledgment signaling (e.g., 752). Thus, for example, a single DCCP interface (1550) may be used for multiple purposes.

[0276] Furthermore, it should be noted that the function of the test arrangement (1500) may be similar to the function of the test arrangement (700), so the above descriptions are also referenced.

[0277] In conclusion, in the test arrangement (1500) according to FIG. 15, the functional test case is located entirely on the device under test. The DCCP interface for the ATE test program is realized by a physical interface such as, for example, HSIO PCIe or USB.

[0278] Furthermore, it should be noted that the test arrangement (1500) according to FIG. 15 may be supplemented by any of the features, functions, and details disclosed herein, which are optionally taken individually and in combination. Furthermore, it should be noted that both the ATE (1510) and the DUT (1530) may be considered as embodiments according to the present invention.

[0279] 17. Test arrangement according to Fig. 16

[0280] FIG. 16 illustrates a schematic representation of a test arrangement according to an embodiment of the present invention. The test arrangement (1600) according to FIG. 16 includes automated test equipment (1610) and a device to be tested (1630). The automated test equipment (1610) may correspond, for example, to the automated test equipment (1510) according to FIG. 15. The automated test equipment (1610) includes test resources (1620) that may correspond, for example, to test resources (1520), and the automated test equipment (1610) also includes a workstation (1622) that may correspond, for example, to a workstation (1522). An automated test equipment test program (1624) is executed on the workstation (1622).

[0281] However, test cases (1640) are distributed between the workstation (1622) and the device under test (1630). Thus, functional testing can be logically separated into, for example, a DUT part and a workstation part (e.g., a DUT part running on the device under test (1630) and a workstation part running on the workstation (1622). A DCCP interface between the two parts is realized, for example, by software running on the workstation (1622). Software for handling the physical connection between the workstation and the DUT is located, for example, inside the test case (1640).

[0282] Furthermore, it should be noted that the DCCP interface (1650) between the ATE test program (1624) and the test case (1640) may include functions comparable to, for example, the functions of the DCCP interface (1550). For example, the DCCP interface (1650) may be used for OCST test case upload and / or execution control (e.g., as described for FIG. 5), and the DCCP interface (1650) may also be used for sending resource update requests (e.g., 750) and acknowledgment signaling (e.g., 752).

[0283] Furthermore, it should be noted that the test arrangement (1600) may be optionally supplemented by any of the features, functions, and details described herein, all taken individually and in combination.

[0284] Furthermore, it should be noted that automated test equipment (1610) and a test target device (1630) can be considered as embodiments according to the present invention.

[0285] In conclusion, FIG. 16 illustrates an extension handling an additional interface topology for communication with a test case. According to one aspect, integration of DUT interface control within the test case may exist. However, integration of DUT interface control within the test case is also within the scope of the present invention.

[0286] 18. Test arrangement according to Fig. 17

[0287] FIG. 17 illustrates a schematic representation of a test arrangement (1700) according to an embodiment of the present invention.

[0288] The test arrangement (1700) includes, for example, automated test equipment (1710) that corresponds to automated test equipment (810). For example, the automated test equipment (1710) may include tester resources (1720) that correspond to tester resources (820). Furthermore, the test arrangement (1700) may include a workstation (1722) that corresponds to a workstation (822). Furthermore, the test arrangement (1700) may include an OCST controller (1726) that corresponds to an OCST controller (826). Furthermore, the test arrangement (1700) includes a test target device (1730) that corresponds to a test target device (830).

[0289] However, the test arrangement (1700) also includes a library (1770) which may be, for example, part of an automated test device (1710). The library may include, for example, one or more message application programming interfaces (APIs). Furthermore, the library (1770) may include, for example, one or more symbol references. Additionally, the library (1770) may optionally include signal mapping.

[0290] For example, message APIs may define calls to library procedures or library functions. For example, message APIs may define syntax for calls to procedures or functions to be used in the development of OCST test cases (e.g., in the form of function headers or method headers or function interfaces or method interfaces). Furthermore, the library may also optionally include implementations of said functions or methods (e.g., in a pre-compiled form or in the form of source code). For example, functions or methods defined by the APIs of the library (1770) may define the creation (and transmission) of resource update request messages. Just as an example, message APIs may define a function or method, the call of which causes the creation of a message that functions to request a resource update of a tester resource. Such a function or method may be defined, for example, to create a message with appropriate syntax and transmit such message to the OCST controller (1726) or the ATE test program (1724) via a high-speed interface. Accordingly, the developer of the OCST test case only needs to include a function call or method call as defined in the library (1770) in the source code of the OCST test case, and then can generate executable code for the OCST test case (e.g., using an appropriate representation of the implementation of the procedures or functions defined in the message APIs).

[0291] In conclusion, one of the functions or methods defined in the library (1770) may define the generation (and preferably also transmission) of a resource update request message, and another method or function defined in the library may define the detection of whether an acknowledgment signaling has reached the device under test or the waiting for the reception of an acknowledgment signaling at the device under test.

[0292] Alternatively or additionally, one of the functions or methods defined in the library may define the generation (and preferably also transmission) of a resource measurement request message, and another function or method defined in the library may define the evaluation of measurement result signaling.

[0293] The library (1770) may optionally also include representations of symbolic references, said symbolic references may be symbolic references for abstract test resource control and signal mapping. For example, the library (1770) may include symbolic references for commonly used signal names, such as, for example, VCC1, VCC2, VCC3, fCLK1, fCLK2, etc. Thus, the symbolic references within the library may be user-friendly names of signals or signal features that can be easily understood by a verification engineer designing a test for a specific device under test.

[0294] Furthermore, the library (1770) may optionally include a signal mapping that can define a mapping of symbolic references to actual physical signals provided by, for example, an automated test equipment (1710).

[0295] Furthermore, it should be noted that the library (1770) may include message APIs for test cases as well as message APIs for test cases and / or OCST controllers and / or test programs. For example, the library (1770) may include message APIs that can be used in the design of a program to be executed on an OCST controller (1726) and can define functions or methods for evaluating resource update request messages and / or generating acknowledgment messages. Furthermore, the message APIs included in the library (1770) may also be included in an ATE test program (1724) and can define functions or methods for evaluating resource update request messages or generating acknowledgment messages. Thus, the message APIs included in the library (1770) can support the development of OCST test cases and also support the development of ATE test programs. In addition, the message APIs included in the library (1770) can also support the development of software to be executed on the OCST controller (1726).

[0296] Furthermore, symbolic references can assist, for example, developers of OCST test cases, because they can define signals and / or quantities in a device-related manner, for example (closely related to the naming of individual signals in device specifications or device data sheets).

[0297] Furthermore, signal mapping may be used, for example, in the creation of a program to be executed on the OCST controller (1726) or in the development of the ATE test program (1724), and may also be used at runtime in the ATE test program (1724) or in the OCST controller (1726). For example, signal mapping defined in the library (1770) may be used by the OCST controller (1726) or the ATE test program (1724) to convert symbolic references, and may be used, for example, to convert messages from an OCST test case (1726) (which may include symbolic references included in resource update request messages) into commands that reference specific physical tester resources.

[0298] Just as an example, the ATE test program (1724) can convert a symbolic reference "VCC1" that may be included in a resource update request message into a physical identifier (e.g., bus address) of a specific device power supply (e.g., device power supply 1). It should be noted that the symbolic references may be independent of, for example, the actual physical configuration of the automated test equipment, and rather may be related to the naming conventions of the device under test. Thus, signal mapping can define, for example, "conversion rules" from DUT-related symbolic references to actual physical tester resources.

[0299] In conclusion, the library (1770) significantly facilitates the development of OCST test cases and also ATE test programs. Furthermore, the use of symbolic references and signal mapping reduces the risk of error for developers of OCST test cases and, moreover, enables the portability of tests to ATEs of different hardware configurations with less effort.

[0300] Furthermore, it should be noted that the library (1770) described herein may be optionally introduced into any of the other test arrangements and automated test equipment disclosed herein. Furthermore, it should be noted that the test arrangement (1700) may be optionally supplemented by any of the features, functions, and details disclosed herein, all taken individually and in combination.

[0301] Furthermore, it should be noted that both the ATE (1710) and the device under test (1730) can be considered as embodiments according to the present invention.

[0302] 19. Test arrangement (1800) according to FIG. 18

[0303] FIG. 18 illustrates a schematic representation of a test arrangement (1800) according to an embodiment of the present invention. The test arrangement (1800) includes an automated test equipment (1810) and a device to be tested (1830). The automated test equipment includes test resources (1820) and a workstation (1822) on which a test program (1824) is executed. Furthermore, the automated test equipment (1810) also includes an OCST controller (1826). The device to be tested (1830) is typically configured to execute an OCST test case (1840).

[0304] With respect to the automated test equipment (1810), it should be noted that the test resources (1820) may be similar to, for example, the tester resources (820) described above. However, it should also be noted that the tester resources (1820) are coupled (induced) to an OCST controller (1826) which may be similar to, for example, the OCST controller (826).

[0305] However, it should be noted that the OCST controller (1826) is configured to receive a resource update request (1850) (e.g., in the form of a message) from the OCST test case (1840) and to provide an acknowledgment signaling (1852) (e.g., in the form of a message) to the OCST test case. However, the OCST controller (1826) is directly coupled to one or more tester resources (1820), for example, via a data and synchronization bus (1880). Accordingly, the OCST controller (1826) can directly trigger a response to the resource update request (1850) (e.g., by bypassing the workstation (1822)). For example, the OCST controller (1826) may access one or more test resources (1820) via a data and synchronization bus (1880) (typically interconnecting all tester resources (1820) and the OCST controller (1826), but not necessarily). Accordingly, in response to the resource update request (1850), the OCST controller (1826) may directly command the specific tester resource indicated in the resource update request message (1850) to update its features (e.g., by bypassing the workstation (1822)).

[0306] For example, the OCST controller (1826) may transmit a command or instruction to a specific tester resource (1820) (e.g., a device power supply or a clock signal generator, etc.) in response to a resource update request (1850) to change its parameters to new parameters specified by the OCST controller (1826). For example, the OCST controller (1826) may write one or more data words on a data bus that directly connects one or more test resources (1820) and the OCST controller (1826), and the OCST controller (1826) may, for example, address the desired tester resource (1820) in this data bus access. For example, the transmission of one or more appropriate data words over the data bus (1880) can directly cause the designated (or addressed) tester resource to update its features (e.g., voltage provided by the device power supply, or clock frequency of the clock signal provided by the clock signal generator). However, in some implementations, one or more data words communicated from the OCST controller (1826) to the designated tester resource over the data bus (1880) may define new parameters for the designated tester resource that are activated only in response to a synchronization event. For example, the OCST controller may consequently trigger an actual update of the tester resource's features by communicating a synchronization event to the designated tester resource (1820) (or all tester resources (1820)) over the synchronization bus. However, as an alternative, the OCST controller may communicate this synchronization to the designated tester resource through a dedicated trigger line. For example, the activation of a synchronization line (not shown in FIG. 18) can cause a designated tester resource coupled to this synchronization line to take over a new setting (which can be considered as an update of the tester resource).

[0307] In conclusion, by having a direct coupling between the OCST controller (1826) and the tester resources (1820) (e.g., via the data and synchronization bus (1880)) or by using a data connection and (optional) a synchronization mechanism such as one or more dedicated synchronization lines or trigger lines, the OCST controller (1826) can perform updates of one or more tester resources with very low latency. For example, the OCST controller (1826), which is typically configured to establish high-speed communication with the OCST test case (1840) using a high-speed interface, can respond very quickly to a resource update request message from the OCST test case and can directly command one or more test resources to perform the requested resource update. Accordingly, there is no longer a need to rely on the handling of resource update requests by the workstation (1822) or the ATE test program (1824) so ​​that latency can be avoided. Furthermore, by using the concept of granting direct access to one or more tester resources to the OCST controller, interruption of the ATE test program (1824) can also be avoided. Accordingly, fast and efficient testing of the device under test can be achieved.

[0308] Furthermore, it should be noted that the test arrangement (1800) may be optionally supplemented by any of the features, functions, and details disclosed herein, all taken individually and in combination.

[0309] Furthermore, it should be noted that both the automated test equipment (1810) and the test target device (1830) can be considered as embodiments according to the present invention.

[0310] 20. Test arrangement according to Fig. 19

[0311] FIG. 19 illustrates a schematic representation of a test arrangement (1900) according to an embodiment of the present invention. The test arrangement (1900) includes automated test equipment (1910) and a device to be tested (1930). The automated test equipment includes tester resources (1920) which may be similar to, for example, tester resources (820, 1820). Furthermore, the automated test equipment (1910) also includes a workstation (1922), and an ATE test program (1924) may be executed on the workstation (1922). The workstation (1922) may be similar to, for example, workstation (822) or workstation (1822), so that the above descriptions also apply. Furthermore, the automated test equipment (1910) includes, for example, an OCST controller (826) or an OCST controller (1926) that may be similar to an OCST controller (1826).

[0312] However, one or more of the tester resources may be configured to receive trigger signaling from the GPO trigger line (1990). For example, the automated test equipment (1910) may be configured to make the GPO trigger line accessible at the DUT interface. For example, the GPO trigger line may be coupled to the general-purpose output (1942) of the device under test (1930) (e.g., via a load board located between the device under test (1930) and the DUT interface of the automated test equipment). For example, the general-purpose output pin (1942) of the device under test (1930) may be controlled by a test case (1940) running on the device under test. Accordingly, the OCST test case (1940) may trigger an update of the test resources, for example, by the activation of the GPO trigger line (1990). Consequently, it is possible for an OCST test case (1940) to perform an update of one or more tester resources (1920) in a manner that requires minimal hardware and software effort. In principle, preferably, a single pin of the device under test (1930) that is not otherwise used in the test arrangement and can be programmed with appropriate effort by an OCST test case (1940) may be used to trigger the tester resource update.

[0313] Furthermore, it should be noted that one or more tester resources to be updated in response to the activation of the GPO trigger line (1990) may be pre-programmed, for example, by the ATE test program (1924). For example, the ATE test program (1924) may provide a command to a specific tester resource (1920) indicating a new state to be taken in response to the activation of the GPO trigger line (e.g., in response to the activation of an associated GPO trigger line). That is, the ATE test program may be time-synchronized, for example, with the execution of the OCST test case (1940) on the device under test (1930), and thus it may be possible to anticipate which resource update will be requested by the OCST test case (1940) upon the next activation of the GPO trigger line (1990). Accordingly, the ATE test program may pre-configure the specific tester resource to which the features will be updated next by providing information regarding the desired features to the specific tester resource. Subsequently, a specific tester resource (1920) may perform an update to use pre-configured features in response to the activation of a GPO trigger-line (1990) by an OCST test case. Accordingly, the ATE test program (1920) may define, for example, a new value to be updated by the specific tester resource (1920), and the OCST test case (1940) determines the exact timing at which the tester resource's update to the new feature (or new value) should be made by the activation of the GPO trigger-line (1990). In this scenario, while the time at which pre-configuration occurs is relatively insignificant, the response to the activation of the GPO trigger-line typically occurs within a well-defined time period (e.g., with very high timing accuracy).Therefore, the OCST test case (1940) has very high control over the timing of the tester resource update, while a very simple communication mechanism, namely a single GPO trigger line, may be sufficient to actually perform the tester resource update.

[0314] However, in some embodiments, the OCST test case (1940) may also be able to communicate desired new features (or desired new settings) of one or more tester resources to be updated. For example, the OCST test case (1940) may use a protocol-based high-speed interface for this purpose, and communication may extend, for example, from the OCST test case (1940) to the OCST controller, from the OCST controller to the ATE test program, and from the ATE test program to the tester resources. Alternatively, however, this communication may also extend from the OCST test case (1940) to the OCST controller (1926) and from the OCST controller (1926) directly to the tester resources (1920), so that the OCST controller bypasses the ATE test program (1924) and directly pre-programs the tester resources (1920) for the desired update of their features.

[0315] In conclusion, by providing automated test equipment with the capability to receive trigger signaling that triggers updates of one or more tester resources from the device under test, it is possible to achieve very precise timing control of the updates of tester resources by the device under test, which may be a system-on-chip. This helps enable very fast execution of OCST test cases running on the device under test because the latency is very low. Furthermore, complex variations in the test environment, such as transient drops in supply voltage or spikes in supply voltage, can be defined under the control of the OCST test case and with very precise timing relationships to the OCST test case.

[0316] However, it should be noted that the test arrangement (1900) may optionally be supplemented with any of the features, functions, and details described herein. Furthermore, it should be noted that both the automated test equipment (1910) and the device under test (1930) may be considered as embodiments according to the present invention.

[0317] 20. Additional embodiments and aspects

[0318] Generally speaking, embodiments according to the innovations described herein describe an ATE integrated solution that extends on-chip system test capabilities through a path for controlling ATE tester resources (TRs).

[0319] 20.1. Tester Resources

[0320] Tester resources are, for example, hardware (HW) modules installed in automated test equipment (ATE) used to provide the electrical environment, stimulus generation, and signal evaluation of the device-under-test (DUT) during test execution. Typical test modules cover power supply, digital, mixed-signal, and RF-IO areas, for example, having features for applying and measuring test-specific patterns and test signals.

[0321] 20.2. Comparison between Legacy and New TR Control Paths

[0322] Tester resources are typically controlled by an ATE test program running on, for example, an ATE workstation (see, e.g., FIGS. 5 and 6). Any ATE environment update is initiated by the test program (e.g., typically), and environment updates by OCST test cases are not expected.

[0323] In this regard, a test case may be defined, for example, as a functional OCST test case to be executed as software (SW) embedded on the device under test (DUT). Furthermore, for example, the test program is defined as an ATE-specific program executed on a workstation to control the test.

[0324] However, it was found that the missing interconnection of OCST test cases for controlling the ATE environment significantly limits the usefulness of OCST development.

[0325] According to an aspect of the present invention, the solution proposed herein compensates for these disadvantages by a new control path from an OCST test case to an ATE test program based on communication channels (see, for example, FIG. 7 and FIG. 8). The new control path is realized, for example, by a software approach and uses messages that can be exchanged between the test case and the test program. The related message calls are provided, for example, by an API and can be placed, for example, at any line of code inside the test case.

[0326] As mentioned above, FIG. 7 illustrates a schematic representation of OCST extended by a tester resource control path (the tester resource control path may enable, for example, the transmission of a resource update request message (750) and an acknowledgment message (752).

[0327] Furthermore, FIG. 8 illustrates a schematic representation of a variant including an OCST controller to include a tester resource control path. For example, the tester resource control path may enable the transmission of resource update request messages (850, 860) and the transmission of acknowledgment messages (862, 852).

[0328] These functions may be included in any of the embodiments disclosed herein, which are optionally taken individually and in combination.

[0329] 20.3. Message-based Tester Resource Control Flow

[0330] According to an aspect of the present invention, ATE environment configurations can now be further controlled by an OCST test case, for example, by sending a specific parameterized message to an ATE test program. For example, a message handler within the test program interprets the message and executes tester resource updates according to the message parameters. After the completion of the resource updates, an acknowledgment message is sent to a waiting DUT, and then the execution of the test case continues.

[0331] FIG. 9 illustrates a schematic representation of the message flow for controlling tester resources. Below, the tester resource update flow will be briefly outlined.

[0332] Tester resource update flow

[0333] 1. The OCST test case uses API message calls during execution to request a resource update and enters a wait loop until a resource update acknowledgment response message is received.

[0334] 2. The message is propagated to the ATE test program through the OCST controller and interpreted by the message handler.

[0335] 3. Tester resources are updated according to the decoded message parameters.

[0336] 4. An acknowledgment message is propagated to the OCST test case through the OCST controller upon a successful tester resource update for synchronization purposes.

[0337] 5. The OCST test case continues execution after receiving an acknowledgment message.

[0338] These functions may be included in any of the embodiments disclosed herein, which are optionally taken individually and in combination.

[0339] 20.4. Message-based Tester Resource Measurement Flow

[0340] According to an aspect of the present invention, in addition to controlling tester resources, the message interface may also be used to trigger resource measurements by OCST test cases (alternatively or additionally). This is useful for executing OCST test cases according to ATE-specific environmental conditions, such as the level of supply voltage or ambient temperature, for example.

[0341] For example, FIG. 10 illustrates a schematic representation of OCST extended by a tester resource measurement path. For example, the tester resource measurement path can enable the transmission of a resource measurement request message (1050) and a measurement result message (1052).

[0342] Furthermore, FIG. 11 illustrates a schematic representation of a variant including an OCST controller to include a tester resource control path. In this case, the tester resource control path may enable, for example, the forwarding of resource measurement request messages (1160, 1170) and the transmission of measurement result messages (1172, 1162).

[0343] For example, an OCST test case can trigger ATE resource-specific measurements by transmitting parameterized measurement messages (e.g., messages (1160)) to an ATE test program (e.g., ATE test program (1124)). A message handler within the test program (e.g., ATE test program (1124)) can interpret, for example, a measurement message parameter (e.g., a parameter indicating that voltage (VCC1) should be measured) and trigger an identified tester resource (e.g., a tester resource capable of measuring a physical voltage specified by the symbol reference (VCC1)) to perform the measurement. Then, the result of the resource measurement is transmitted back to, for example, a standby DUT (1130), which continues the test case according to, for example, a received result value (e.g., a result value indicating that VCC1 takes on a specific value such as, for example, 5.46V).

[0344] Figure 12 illustrates a schematic representation of the message flow for measuring tester resources.

[0345] Below, an example of the tester resource measurement flow will be explained.

[0346] Tester resource measurement flow

[0347] 1. An OCST test case uses an API message call (e.g., message (1254)) during execution to request a resource measurement, for example, and enters a waiting loop until it receives a measurement result message (e.g., message (1270)).

[0348] 2. A message (e.g., message (1254)) is propagated to an ATE test program (e.g., ATE test program (1220)) through an OCST controller, for example, and interpreted by a message handler (e.g., a message handler that is part of the ATE test program).

[0349] 3. A tester resource (e.g., tester resource (1210)) performs a measurement according to a decoded message parameter (e.g., according to parameter VCC1 indicating that a specific voltage should be measured).

[0350] 4. The measurement value is propagated to the OCST test case through the OCST controller (e.g., using messages (1260, 1270)).

[0351] 5. The OCST test case (e.g., OCST test case (1240)) continues execution, for example, according to the received result (e.g., according to the result described by the result message (1270)).

[0352] These functions may be included in any of the embodiments disclosed herein, which are optionally taken individually and in combination.

[0353] 20.5. Logical Expansion of Test Cases and Required Control and Communication Interfaces for Different Test Topologies

[0354] In the following, the logical development of test cases and the required control and communication interfaces will be described for different tester topologies.

[0355] Some definitions will be provided below. For example, tester resources are hardware (HW) modules installed in an ATE used to provide, for example, the electrical environment of the DUT and / or stimulus generation and / or signal evaluation during a test run. Typically, tester modules cover power supply, digital, mixed-signal, and / or RF-IO areas having features for applying and measuring, for example, test-specific patterns and test signals.

[0356] The workstation typically executes ATE test programs and controls tester resources. The test program controls test cases directly, for example, through a test controller or the DCCP interface, depending on the test topology. For example, this additionally listens for incoming communication messages from the test controller or test cases via the DCCP-IF. For example, the workstation can be directly coupled to the device under test, or the OCST controller can act as an intermediary between the workstation and the device under test.

[0357] The FT service device (or functional test case service device) is a CPU-supported hardware (HW) instance that includes, for example, a DUT test controller (e.g., an OCST controller).

[0358] The test controller (or OCST controller) handles, for example, the upload process of DUT test cases, controls the execution of test cases, and collects execution result information.

[0359] A test case is, for example, functional test code executed on the processor system of the DUT. It may include, for example, software (SW) parts for handling the physical interface parts for the FT service device or workstation. For example, a test case may include driver software that enables the test case to communicate with the workstation or the OCST controller through a high-speed interface (e.g., as previously described). However, the driver software does not necessarily have to be part of the test case, but may also be part of the operating system running on the device under test, for example.

[0360] The DCCP interface (DCCP-IF) is a data, control, and communication path interface (DCCP-IF) used for, for example, the following:

[0361] Test case upload and / or control, and / or

[0362] For example, a communication path between a test program and a test case for tester resource updates and / or measurements.

[0363] The DCCP interface can be, for example, one of the high-speed interfaces mentioned above.

[0364] A DUT is a device under test that includes, for example, a processor system for executing functional tests.

[0365] A DUT is a device under test that includes, for example, a processor system for executing functional tests.

[0366] Figures 13–16 illustrate different test arrangements.

[0367] FIG. 13 illustrates a test arrangement in which a functional test case (1340) is fully positioned on the device under test (1330). The DCCP-IF (1362) for the test controller is realized by a physical interface, such as, for example, HSIO PCIe or USB.

[0368] FIG. 14 illustrates a test arrangement in which a functional test case (1440) is logically separated into a DUT and an FSI portion. The DCCP interface (1462) between the test controller (1452) and the test case (1440) is realized, for example, by software (SW) running on the FSI. Software for handling the physical connection between the FSI and the DUT is, for example, located inside the test case.

[0369] FIG. 15 illustrates a test arrangement in which a test case (1540) is fully positioned on a device under test (1530). The DCCP-IF (1550) for the ATE test program (1524) is realized by a physical interface, such as, for example, HSIO PCIe or USB.

[0370] FIG. 16 illustrates a test arrangement in which a functional test (1640) is logically divided into a DUT and a workstation portion. The DCCP interface between the two portions is realized, for example, by software running on the workstation. Software for handling the physical connection between the workstation (1622) and the DUT (1630) is located, for example, inside the test case (1640).

[0371] These functions may be included in any of the embodiments disclosed herein, which are optionally taken individually and in combination.

[0372] 20.6. Benefits of Enabling ATE Environment Control by OCST Test Cases

[0373] 20.6.1 Resource control can be synchronized with the execution of test cases.

[0374] According to an aspect of the present invention, updates to tester resources during test case execution are now possible. For example, updates can occur not only before the execution of the test case but also at any line of code in the test case program. In contrast, legacy approaches did not allow changing test resources during test case execution.

[0375] 20.6.2 Tester resources can be configured by test case parameters.

[0376] According to an aspect of the present invention, parameters of a test case call can be used to initiate tester resource updates. This extends the variability and flexibility of the test case.

[0377] 20.6.3 Development of OCST Test Cases Without ATE Expert Support

[0378] Use case-specific test cases are typically developed by verification engineers because they are familiar with the internals of the DUT. However, conventionally, additional adaptations of ATE test programs by test engineers are required to execute OCST test cases in specific ATE environments.

[0379] A single OCST has always, until now (e.g., conventionally), required the following:

[0380] Development efforts to align test programs and test cases.

[0381] Verification engineers and test engineers for generating OCST test cases and ATE test programs.

[0382] It has been found that the effort required to develop OCST can be significantly reduced by the solution described herein to shift ATE environment control from test programs to OCST test cases. For example, a proprietary test program is used for all OCST test cases, and it may be required to set up the ATE environment for guaranteed safe DUT startup. Now, additional test case-specific ATE environment updates are controlled by the OCST test case itself (e.g., according to aspects of the present invention). Accordingly, the verification engineer becomes independent from the test engineer, as the verification engineer can now control the ATE environment and execute the test cases themselves. Now, the development of on-chip system tests is limited to OCST test cases.

[0383] 20.6.4 ATE Environment Control and OCST Test Case Sequences in a Single Source

[0384] According to an aspect of the present invention, there are no longer any dependencies between the ATE test program and the OCST test case. In some embodiments according to the present invention, tester resource control and test case development are now located in a single test case source file.

[0385] However, it should be noted that, for example, the initialization of tester resources may still be provided by the ATE test program. Also, in some cases, there may be at least approximate time synchronization between the ATE test program and the test case.

[0386] 20.6.5 ATE Independent OCST Test Case Development Possible

[0387] According to an aspect of the present invention, no knowledge of the ATE environment is required for test case development. Tester resources are accessed by a verification engineer, for example, by abstract symbolic signal references in the form of one or more message parameters, target values, and / or mode settings (or by using them). The interpretation of parameters of the tester resources and the resulting test-specific programming sequence are executed, for example, by a message handler of an ATE test program.

[0388] 20.6.6 No hardware (HW) adaptation required

[0389] According to an aspect of the present invention, the concept of updating tester resources is based on a pure software approach. In some cases, no hardware adaptations to the ATE are required to implement the concepts according to the present invention.

[0390] However, it should be noted that one or more of the advantages mentioned above may exist, for example, in embodiments according to the present invention.

[0391] 21. Libraries to support ATE environment control

[0392] Below, according to an (optional) aspect of the present invention, the use of libraries to support ATE environment control will be described. These functions may be included in any of the embodiments disclosed herein, which are optionally taken individually and in combination.

[0393] For example, FIG. 17 illustrates a schematic representation of libraries for supporting ATE environment control (e.g., in the context of test arrangement).

[0394] 21.1. Message APIs for Supporting Different DUTs

[0395] APIs for controlling the ATE environment use, for example, predefined methods for exchanging messages with the ATE test program. To cover DUT-specific interfaces (e.g., USB and / or PCIe) and to adapt to different DUT processor core types (e.g., ARM, Atmel, Microchip…), libraries with different versions of the message API may be prepared, for example.

[0396] For example, the library may include application programming interfaces for transmitting one or more types of messages (e.g., resource update request messages or resource measurement request messages) through interfaces of different types (e.g., through high-speed interfaces of different types). Furthermore, the library may include implementations of the aforementioned functions or methods predefined in message APIs that are adapted for use with different types of DUT processor cores.

[0397] Accordingly, a verification engineer can generate test cases using one or more appropriate message APIs provided in the library (e.g., in the form of pre-compiled code that can be included in a test case using a linker) and predefined implementations for, for example, different types of DUT process cores and different types of (high-speed) interfaces to be used. Accordingly, the development of OCST test cases is very simple for the verification engineer because the verification engineer does not need to worry about specific implementations of functions or methods for requesting resource updates or resource measurements, but only needs to use predefined message APIs provided in the library (1770).

[0398] 21.2 Symbolic References for Identifying Resources and Channels

[0399] According to an aspect of the present invention, characteristics, modes, and signals of tester resources are selected by parameters of messages and are represented by symbolic references. For example, a test case developer may use these references to control all kinds of signals applied to the DUT, for example, to control the DUT supply environment. For example, a message handler of an ATE test program uses symbolic references to identify tester resources and / or tester channels and / or uses operation modes to execute operations requested by predefined resource-specific sequences.

[0400] A simple example will be provided below.

[0401] In this example, the supply voltage (VCC2) must be set to 5V.

[0402] Exemplary API calls can take the following forms: Message ("VCC2", 5V)

[0403] The message handler identifies parameter "VCC2" as a supply module-specific test resource, for example, by searching for the symbol reference "VCC2" in the mapping table. The voltage setting of "VCC2" is executed by a predefined supply module programming sequence that includes the parameter target voltage "5V" and the resource channel "10103".

[0404] Exemplary mapping table

[0405] Symbol reference Tester resources Resource Channel VCC1 Supply Module 10102 VCC2 Supply Module 10103 GPO1 digital channels 20101 … … …

[0406] In conclusion, a mapping table can define, for example, "signal mappings" and can be included in a library. For example, a mapping table can map symbolic references of signals or numbers to physical resource identifiers that identify specific tester resources. Accordingly, if the hardware configuration of the automated test equipment changes (e.g., by removing or adding tester resource modules), the mapping table may change. Thus, OCST test cases can use symbolic references, and these symbolic references are then converted into references to physical tester resources, for example, by an ATE test program (or alternatively, by an OCST controller), using the mapping table.

[0407] 22. Additional variations of ATE environments controlled by OCST

[0408] Below, additional optional variations of the ATE environment controlled by OCST will be described according to embodiments of the present invention.

[0409] 22.1. Control of Tester Resources by Synchronization Bus Events

[0410] According to an aspect of the present invention, all test resources (or at least some of the test resources) and the OCST controller are interconnected by a data and synchronization bus. The bus system is used to exchange data and transmit synchronization events between bus members. For example, a test resource update is initiated by a message transmitted from an OCST test case to the OCST controller. The OCST controller initializes the selected test resources according to message parameters by a data bus configuration sequence and activates new settings, for example, by a dedicated synchronization bus event.

[0411] Figure 18 illustrates a schematic representation of a tester resource controller by data and synchronization buses.

[0412] Below, an example of a test resource update flow will be explained.

[0413] 1: An OCST test case (e.g., OCST case (1840)) requests that a tester resource be updated by a message (e.g., message (1850)) sent to an OCST controller (e.g., OCST controller (1826)), and enters a loop to wait for a message (e.g., message (1852)) to acknowledge the update.

[0414] 2: The OCST controller (e.g., OCST controller (1826)) configures a selected tester resource (e.g., from among test resources (1820)) according to message parameters (e.g., included in a resource update request message (1850)) and activates a new setting, for example, through a dedicated trigger signal on a synchronization bus (e.g., on a data and synchronization bus (1880)).

[0415] 3: To flag (or signal) a successful update, an acknowledgment message (e.g., acknowledgment message (1852)) is sent back to the OCST test case. For example, the test case leaves the acknowledgment wait loop (ACK wait loop) and continues processing.

[0416] It should be noted that such embodiments according to the present invention may be supplemented by any of the features, functions, and details disclosed herein, which are optionally taken individually and in combination.

[0417] Additionally, any of these functions may be optionally included in any of the embodiments disclosed herein, all of which are taken individually and in combination.

[0418] 22.2. Control of Tester Resources by GPO Triggers

[0419] According to an aspect of the present invention, GPO ports of a DUT (e.g., general-purpose output ports) are interconnected with tester resources and used as trigger lines to activate pre-configured resource configurations. As merely an example, it may be sufficient for a single general-purpose output port (or general-purpose output pin) of the DUT to be interconnected with a tester resource and used as a trigger line. However, it is also possible for multiple general-purpose output ports or general-purpose output pins of the DUT to be interconnected with test resources and used as trigger lines.

[0420] This allows the OCST test case to update test resources by setting the relevant GPO line (or equivalently, by setting the general-purpose output port or general-purpose output pin of the device under test to a predetermined state, e.g., active state).

[0421] A minor drawback is that, in some cases, the test program and the test case are not independent because the intended configuration may need to be prepared by the ATE test program before the execution of the OCST test case. Therefore, the approach is not flexible for dynamic resource updates in some cases. Additionally, in some cases, only one configuration per GPO line may be supported, and hardware modifications are required to route GPO lines to tester resources.

[0422] However, these minor drawbacks can be selectively overcome by providing an OCST test case that allows the possibility of communicating desired resource updates to automated test equipment, for example, before the activation of a trigger line, so that the automated test equipment can prepare the intended update configuration, for example, under the control of the OCST test case. Furthermore, by dynamically changing the update configuration used in response to the activation of a specific GPO line (or trigger line), good functionality with very high timing accuracy can be achieved.

[0423] Moreover, hardware modifications for routing GPO lines to tester resources are trivial in some cases.

[0424] For example, Fig. 19 illustrates a schematic representation of tester resource control by a GPO trigger.

[0425] Below, an example of a test resource update flow will be explained.

[0426] 1: An ATE test program (e.g., an ATE test program (1924)) initializes the target configuration of each individual tester resource (e.g., among the test resources (1920)).

[0427] 2: An OCST test case (e.g., OCST test case (1940)) requests a tester resource update by activating a GPO line (e.g., by activating a GPO trigger line (1940)).

[0428] 3: Pre-configured tester resource settings (e.g., as configured in Step 1) are activated by the detection of a GPO trigger event (e.g., the detection of a GPO trigger event occurs in a tester resource).

[0429] Furthermore, it should be noted that such embodiments according to the present invention may be supplemented by any of the features, functions, and details described herein, which are optionally taken individually and in combination.

[0430] 23. Implementation Alternatives

[0431] Some aspects have been described in relation to devices, but these aspects also represent descriptions of methods for corresponding steps, where it is evident that a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in relation to method steps also represent descriptions of corresponding blocks or items or features of a corresponding device. Some or all of the method steps may be executed by (or using) a hardware device, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of the most important method steps may be executed by such a device.

[0432] Depending on specific implementation requirements, embodiments of the present invention may be implemented in hardware or software. Implementation may be performed using a digital storage medium, such as a floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM, or flash memory, which stores electronically readable control signals that cooperate (or can cooperate) with a programmable computer system to perform each method. Thus, the digital storage medium may be computer-readable.

[0433] Some embodiments according to the present invention include a data carrier having electronically readable control signals that can cooperate with a programmable computer system so that one of the methods described herein is performed.

[0434] Generally, embodiments of the present invention may be implemented as a computer program product having program code that operates to perform one of the methods when the computer program product is executed on a computer. The program code may be stored, for example, on a machine-readable carrier.

[0435] Other embodiments include a computer program for performing one of the methods described herein, stored on a machine-readable carrier.

[0436] That is, one embodiment of the method of the present invention is, accordingly, a computer program having program code for performing one of the methods described in this specification when the computer program is executed on a computer.

[0437] Accordingly, additional embodiments of the methods of the present invention include a data carrier (or digital storage medium, or computer-readable medium) recorded thereon, comprising a computer program for performing one of the methods described herein. The data carrier, digital storage medium, or recorded medium is typically tangible and / or non-transient.

[0438] Accordingly, a further embodiment of the method of the present invention is a data stream or sequence of signals representing a computer program for performing one of the methods described herein. The data stream or sequence of signals may be configured to be transmitted, for example, through a data communication connection, for example, over the Internet.

[0439] Additional embodiments include processing means, for example, a computer or programmable logic device configured or adapted to perform one of the methods described herein.

[0440] Additional embodiments include a computer installed with a computer program for performing one of the methods described herein.

[0441] Further embodiments according to the present invention include a device or system configured to transmit a computer program for performing one of the methods described herein to a receiver (e.g., electronically or optically). The receiver may be, for example, a computer, a mobile device, a memory device, etc. The device or system may include, for example, a file server for transmitting the computer program to the receiver.

[0442] In some embodiments, a programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described herein. In some embodiments, a field-programmable gate array may cooperate with a microprocessor to perform one of the methods described herein. Generally, the methods are preferably performed by any hardware device.

[0443] The device described in this specification may be implemented using a hardware device, a computer, or a combination of a hardware device and a computer.

[0444] Any of the devices described in this specification or any components of the devices described in this specification may be implemented at least partially in hardware and / or software.

[0445] The methods described in this specification may be performed using a hardware device, or using a computer, or using a combination of a hardware device and a computer.

[0446] Any of the methods described in this specification or any components of the device described in this specification may be performed at least partially by hardware and / or software.

[0447] The embodiments described above are merely examples of the principles of the invention. It is understood that modifications and variations of the arrangements and details described herein will be apparent to those skilled in the art. Accordingly, this is intended to be limited only to the appended claims, rather than to the specific details presented by the description and explanation of the embodiments in this specification.

Claims

Claim 1 Automated test equipment (240; 280; 1910) for testing a device under test (242; 260; 1930), wherein the automated test equipment includes a trigger line (250; 295; 1990) controllable by the device under test (242; 260; 1930), and one or more tester resources (288a, 288b, 288c; 1920) are directly coupled to the trigger line (250; 295; 1990), and the automated test equipment is configured to update the one or more tester resources (288a, 288b, 288c; 1920) in response to activation of the trigger line by the device under test. Claim 2 In claim 1, the automated test equipment (240;280;1910) is configured such that the activation of the trigger line (250;295;1990) bypasses the test program executor (282;1922) that executes the test program (284;1924), thereby directly triggering the update of one or more tester resources (288a,288b,288c;1920). Claim 3 In claim 1, the automated test equipment comprises one or more tester resources (288a, 288b, 288c; 1920), said one or more tester resources are coupled to a test program executor (282; 1922) through an interface (285), said test program executor enables programming of one or more features of said one or more tester resources under the execution of a test program (284; 1924); said one or more tester resources are coupled to a trigger line (250; 295; 1990) controllable by said test target device (242; 260; 1930), and said one or more tester resources are configured to update signal features in a pre-programmed manner under the control of said test program in response to activation of said trigger line by said test target device, said automated test equipment (240; 280; 1910). Claim 4 In claim 1, the automated test equipment (240;280;1910) comprises a test program executor (282;1922) configured to pre-program the one or more test resources (288a, 288b, 288c;1920) in order to pre-define the response of one or more test resources to the activation of the trigger line (250;295;1990) by the test target device (242;260;1930). Claim 5 In claim 1, the automated test equipment (240;280;1910) is configured to pre-program the one or more tester resources (288a,288b,288c;1920) according to one or more commands provided in the test program (284;1924) in order to pre-define the response of one or more tester resources (288a,288b,288c;1920) to the activation of the trigger line (250;295;1990) by the test target device (242;260;1930). Claim 6 In claim 1, the automated test equipment (240; 280; 1910) is configured to receive a command (296) from a test target device (242; 260; 1930) that defines one or more parameters for updating one or more tester resources, and the automated test equipment is configured to pre-program one or more tester resources (288a, 288b, 288c; 1920) according to the command received from the test target device in order to pre-define the response of one or more tester resources to the activation of the trigger line (250; 295; 1990) by the test target device. Claim 7 In claim 1, the one or more tester resources (288a, 288b, 288c; 1920) comprise an automated test equipment (240; 280; 1910) configured to update signal features in response to activation of the trigger line (250; 295; 1990) by the device to be tested (242; 260; 1930). Claim 8 In claim 1, the automated test equipment comprises an On-Chip-System-Test controller (286;1926) and a test program executor (282;1922), and one or more tester resources (288a, 288b, 288c;1920), and the trigger line is a hardware line that bypasses the On-Chip-System-Test controller and the test program executor and extends directly from the test target device interface (290) of the automated test equipment to one or more tester resources, the automated test equipment (240;280;1910). Claim 9 In claim 1, the one or more tester resources (288a, 288b, 288c; 1920) comprise: - a device power supply unit; - a signal generator module; - one or more of a channel module, an automated test device (240; 280; 1910). Claim 10 In claim 1, the one or more tester resources (288a, 288b, 288c; 1920) are connected to a test program executor (282; 1922) via an interface (285), an automated test device (240; 280; 1910). Claim 11 In claim 1, the one or more tester resources (288a, 288b, 288c; 1920) are automated test equipment (240; 280; 1910) that is physically separated from the test program executor (282; 1922). Claim 12 A test target device (242;260;1930), wherein the test target device is configured to trigger an update of one or more tester resources (288a,288b,288c;1920) through a dedicated trigger line (250;295;1990) directly connected to one or more tester resources (288a,288b,288c;1920) by providing a trigger signal (262;294;1942) to an automated test equipment (240;280;1910). Claim 13 In claim 12, the test target device (242;260;1930) is configured to provide the trigger signal (262;294;1942) under the control of a test case (262;1940) executed by the test target device. Claim 14 In claim 12, the test target device is configured to provide a command (266; 296) defining one or more parameters for updating one or more tester resources (288a, 288b, 288c; 1920) to the automated test equipment (240; 280; 1910), and the test target device is configured to trigger an update of one or more tester resources using the one or more parameters by providing the trigger signal (262; 294; 1942), the test target device (242; 260; 1930). Claim 15 A test setup (1900), wherein the test setup comprises an automated test equipment (240; 280; 1910) according to claim 1 and a test target device (242; 260; 1930) according to claim 12. Claim 16 A method for operating an automated test equipment (240;280;1910) comprising a trigger line (250;295;1990) controllable by a device to be tested (242;260;1930) and one or more tester resources (288a,288b,288c;1920) directly connected to said trigger line (250;295;1990), wherein the method comprises the step of updating said one or more tester resources (288a,288b,288c;1920) in response to activation of said trigger line (250;295;1990) by said device to be tested. Claim 17 A method for testing a device to be tested (242; 260; 1930), comprising: a step of pre-programming one or more tester resources (288a, 288b, 288c; 1920) with one or more individual parameter values ​​to be transferred in response to a trigger signal (262; 294; 1942) using a test program executor (282; 1922); and a step of directly providing the one or more tester resources from the device to be tested (242; 260; 1930) a trigger signal (262; 294; 1942) that causes the one or more tester resources to transfer the one or more pre-programmed individual parameter values. Claim 18 A computer program stored on a computer-readable storage medium, wherein the computer program is executed on one or more computers and / or on one or more microprocessors and / or on one or more microcontrollers to perform the method of claim 16 or the method of claim 17. Claim 19 Automated test equipment (240; 280; 1920) for testing a device to be tested, wherein the automated test equipment includes a trigger line (250; 295; 1990) controllable by a test case (262; 1940), and the automated test equipment is configured to update one or more tester resources (288a, 288b, 288c; 1920) in response to activation of the trigger line by the test case. Claim 20 A method for operating an automated test equipment (240; 280; 1990) comprising a trigger line (250; 295; 1990) controllable by a test case (262; 1940), comprising the step of updating one or more tester resources (288a, 288b, 288c; 1920) in response to activation of the trigger line by the test case. Claim 21 A method for testing a device to be tested (242; 260; 1930), comprising: a step of pre-programming one or more tester resources (288a, 288b, 288c; 1920) with one or more individual parameter values ​​to be transferred in response to a trigger signal (262; 294; 1942) using a test program executor (282; 1922); and a step of directly providing one or more tester resources from a test case (262; 1940) a trigger signal that causes the one or more tester resources to transfer the one or more pre-programmed individual parameter values. Claim 22 A computer program stored on a computer-readable storage medium, wherein the computer program is executed on one or more computers and / or on one or more microprocessors and / or on one or more microcontrollers to perform the method of claim 20 or the method of claim 21.

Images