JP2023531071A - Automated test equipment and method using device specific data - Google Patents

Abstract

The automatic test equipment is configured to broadcast and/or specifically upload input data and/or device specific data including keys and/or authentication information and/or identity and/or configuration information to the matching module. Includes tester control. The automatic test equipment further includes a channel processing unit configured to transform input data using the device specific data to obtain device under test conformance data for testing the device under test. The channel processing unit is further configured to process the DUT data using the device specific data to evaluate the DUT data. A method and computer program for testing one or more devices under test in automatic test equipment are also disclosed. [Selection drawing] Fig. 1a

Description

Embodiments in accordance with the present invention relate to automated test equipment, eg, for multi-site testing.

Another embodiment according to the invention relates to a method of testing a device under test.

Another embodiment according to the invention relates to a computer program for performing the method.

Generally speaking, embodiments in accordance with the present invention relate to providing efficient and secure device-specific communication for multi-site testing.

Additionally, embodiments in accordance with the present invention relate to automated test equipment and methods for providing efficient and secure device-specific communication for multi-site testing.

In traditional device testing concepts, automatic test equipment is typically used to test a device under test (DUT). The test interface between the device under test and the automatic test equipment can use different communication protocols such as iJTAG, RSN, or IEEE1687. It is recognized that while the test program may be the same for all DUTs during test execution, the test run and test data may not be the same. Within this framework, multi-site testing is a well-known technique for testing multiple DUTs in parallel, which, for example, reduces total test time and thus costs. On the other hand, it has been found that the efficiency of multi-site testing is threatened, for example, due to the (high) computational effort required for data stream calculations. It has also been found that other threats may be limited broadcast efficiency due to, for example, device-specific communications and direct device interaction, for example via protected or packetized interfaces.

Moreover, conventional device testing concepts use a centralized processing unit that includes a memory and a computing unit. In a centralized channel architecture, data must be transferred and computed on a central processing unit that cannot perform local data transformations (e.g., device-specific, DUT-specific), which is necessary for device-specific communication. has been found to cause a high communication overhead of

Techniques have been proposed for device-specific communication using channel processing units. For example, US Patent Application Publication No. 2018/0196103A1 discloses an automated test equipment system capable of testing semiconductor devices. Japanese National Publication of International Patent Application No. 2009-508142 discloses a tester for testing a device under test. US Patent Application Publication No. 2019/0383873 A1 discloses a test and measurement device for testing multiple DUTs. US Patent Application Publication No. 2004/0044939 A1 discloses a system for testing different types of semiconductor devices.

U.S. Patent Application Publication No. 2018/0196103 (A1) Japanese Patent Publication No. 2009-508142 U.S. Patent Application Publication No. 2019/0383873(A1) U.S. Patent Application Publication No. 2004/0044939 (A1)

Given this situation, there is a need for testing concepts that offer improved trade-offs between complexity, test throughput and safety.

One embodiment according to the present invention provides an automatic test instrument for testing one or more devices under test (DUTs), the automatic test instrument including a tester controller.

The tester controller has a centralized test flow manager configured to broadcast and/or in particular upload device specific data to the matching module, which may include, for example, keys and/or authentication information and/or identity and/or configuration information. include. For example, the tester control broadcasts the same data to multiple connected channel processing units simultaneously.

In addition, the centralized test flow manager may, for example, send input data (e.g., input tester command streams, or DUT streams, or broadcast data, or shared data, or data that is equal for different DUTs, or common expected result data) to It can be configured to be broadcast and/or specifically uploaded to the matching module.

The automatic test equipment further includes, for example, a channel processing unit coupled to the tester control via a tester data bus.

In addition, the channel processing unit provides device under test conformance data (e.g., local device-specific data (e.g., local device-specific information and/or key , and/or authentication information, and/or identity, and/or configuration) to input data (e.g., input tester command stream, or DUT stream, or broadcast data, or shared data, or data equivalent to different DUTs). , or common expected result data).

Alternatively or additionally, the channel processing unit may be used to test or evaluate the DUT (e.g., by extracting the communication payload, or by evaluating data transmission from the DUT, or device-independent or non-DUT to obtain unique information), using (e.g., local) device-specific data using DUT data (e.g., data from the DUT, e.g., using a protocol determined by device-specific data such as a device-specific key) data) (e.g., transform or analyze or decrypt using device-specific keys, or unwrap from protocol using device-specific protocol information such as packet counters, device IDs) . Accordingly, device-specific data (eg, keys and/or authentication information and/or IDs and/or configurations) are configured to be stored, for example, in local memory (eg, local memory of the channel processing unit).

The automatic test equipment described prevents excessive test throughput limitations in the automatic test equipment caused by bandwidth limitations between the tester control and the channel processing unit by limiting device-specific processing in one or more channel processing units. is based on the finding that it can be overcome using

Therefore, using device-specific data stored locally in the channel processing unit (or even using different device-specific data stored in different channel processing units), the channel processing unit may be provided by the tester control device-specific test equipment for testing different devices under test in automatic test equipment containing multiple channel processing units while avoiding transmission of excessive amounts of data to different channel processing units by transforming the input data of It is possible to obtain test device fit data.

For example, by performing a device-specific adaptation of the test data in the channel processing unit using the device-specific data, it is no longer necessary to transfer different (device-specifically adapted) test data to the channel processing unit, but rather It may be sufficient to transfer common (identical) test data and a (relatively) small amount of device-specific data to the channel processing unit, the common test data being transferred to the channel processing unit (e.g., bandwidth to save). Therefore, the amount of data transferred from the tester control to the channel processing unit is less than the individual (device-specifically adapted) test data for every device under test transferred from the tester control to the channel processing unit. Much less than conventional solutions.

Similarly, by using device-specific data for evaluation of DUT data in the channel processing unit, different device-specific verification data (describing expected DUT data) can be communicated to the channel processing unit, or the complete DUT Data need not be transferred to the tester control for evaluation. Rather, the amount of data transferred from the channel processing unit to the tester control is stored locally (in some cases, DUT data of different devices under test) within the channel processing unit for evaluation of the DUT data from the DUT. can be reduced by using stored device-specific data (which may include a relatively small amount of data), along with common data commonly used for evaluation of . For example, device-specific data can be used to decode DUT data and/or implement DUT-specific communication protocols.

Additionally, a high degree of security and confidentiality can be achieved by storing device-specific data directly in the channel processing unit. For example, storing device-specific data in the channel processing unit can provide savings over storing device-specific data in the tester control. This is because channel processing units are less likely to be attacked due to their typically very specific embedded architecture.

Moreover, implementing processing using device-specific data in the channel processing unit is typically found to be easy to implement given the processing power available in the channel processing unit. In addition, channel processing units are often better suited for real-time (or just-in-time) processing than tester controls so that they can handle the processing effort.

In conclusion, the concept described above can provide a good trade-off between complexity, test throughput and safety.

Furthermore, the automated test equipment described is also a finding that this concept is efficient in the context of secure communication approaches that can help achieve secure multi-site DUT testing by using advanced security architectures. is based on Security mechanisms can include, for example, encrypted/decrypted DUT (Device Specific) communications to prevent unauthorized access to internal device structures by the test and debug interface. Additionally, functional interfaces that are still active after testing may require protection. Further security mechanisms may be, for example, authorization, which refers to granting a certain level of access (eg, only certain tests may be applied, for example, to the DUT), or verifying the user's identity, for example. It can be a pointing authentication. Additionally, the communication between the DUT and the channel processing unit can be further protected, for example by using packet counters and/or error correction codes and/or error identification codes. This guarantees the highest possible security in multi-site testing situations. Thus, using the above concepts, device-specific processing (e.g. conversion of channel processing unit input data using device-specific data, e.g. device-specific encryption information or authorization information) is performed in the channel processing unit. This can reduce the processing load on the tester control and the amount of data transferred from the tester control to the channel processing unit and vice versa, making the channel less susceptible to security attacks than the tester control. Security can be improved by storing confidential information in the processing unit.

Furthermore, the present invention enables efficient device-specific communication, and communication between the tester control and the channel processing unit is performed as device-independent as possible. For example, this can be achieved by a results analysis approach in which input data is broadcast by the tester control to the different channel processing units via the tester data bus. At different channel processing units, input data may be compared with respective (eg, extracted) result data from the DUT, and respective test results are stored in memory. If the respective test results (upstream result data) differ from the input data, the respective test result data and/or the difference between the input data and the respective test result data are for example compressed and transmitted to the tester control. obtain. The data transmitted to the tester control may additionally (or optionally) include the DUT signature. In conclusion, the results analysis approach on the channel processing unit can minimize both test time by reducing bus traffic and CPU requirements.

Further efficiency and security can be achieved using sandboxed channel processing units, which provide local execution of tester commands, for example, using their individual memory and computing power within the channel processing unit. . Therefore, device-specific functionality can also be updated by uploading third-party software to enable efficient device-specific computational processes.

In preferred embodiments, the channel processing unit is configured to communicate with one of the one or more DUTs using a device specific channel and a DUT interface. This is accomplished for communicating device under test conformance data to the device under test and/or for receiving DUT data from the device under test. The DUT interface may be, for example, one of iJTAG interface (IEEE1687 interface) or RSN interface or Debug, or one of IEEE1149.10 interface or high bandwidth interface such as SATA interface or USB interface. good.

In preferred embodiments, the channel processing unit is configured to communicate with the central tester control using a tester interface (eg, data bus or interface or dedicated bus). The tester interface may be, for example, one of iJTAG interface (IEEE1687 interface) or RSN interface or Debug, or one of IEEE1149.10 interface or high bandwidth interface such as SATA interface or USB interface. . However, any other type of interface may be used, such as a high speed parallel interface or an Ethernet interface.

In a preferred embodiment, the tester control is configured to broadcast input data to multiple channel processing units via the tester interface. When broadcasting input data (e.g., an input tester command stream, or a DUT stream, or broadcast data, or shared data, or data that is equal for different DUTs, or common expected result data), the same input data is sent to multiple channel processing units. may be transmitted to Broadcasting is also significantly more bandwidth efficient than individual transmissions of the same data to different channel processing units, and much more than individual transmissions of different (device-specific) data to different channel processing units. Bandwidth efficient.

In a preferred embodiment, the tester interface is a tester data bus coupled to the tester control and the plurality of channel processing units. In particular, equivalent data that can be adapted in a device-specific manner by the device communication unit can be efficiently transferred from the tester control to the device communication unit via such a tester data bus.

In preferred embodiments, the channel processing unit includes volatile storage (eg, memory) and/or non-volatile storage (eg, solid state disk) and a computing unit (eg, CPU, ASIC, FPGA). Further, the channel processing unit is configured to store device-specific data in the channel processing unit's memory and to transform input data sent from the tester control using the computation unit. For example, input data may be converted to device-under-test fit data by using device-specific data. Alternatively or additionally, the channel processing unit is configured to process DUT data, eg transmitted from the DUT, using the computation unit. DUT data processing may include, for example, data compression and/or data encryption and/or generated signatures.

By storing device-specific data in the memory of the channel processing unit and using it to generate device-specific test data (which can be performed "on the fly" prior to DUT testing or during DUT testing), the tester controller and the device communication unit to overcome the need to exchange large amounts of device-specific test data. Rather, only a relatively small amount of device-specific data may need to be uploaded from the test control to the device communication unit, which uses its own computational unit (e.g., device-independent common A relatively large amount of device-under-test qualification data can be generated. Similarly, the channel processing unit may extract device-independent result data, e.g., by decompressing or decoding DUT data received from the device under test, e.g., using the device-specific data, This "device independent" result data can be used, for example, to classify the device under test as passing or failing the test. As a result, the processing load on the tester control unit can be kept low, and the amount of data transferred via the tester interface can be kept small, so bottlenecks can be avoided.

In preferred embodiments, the channel processing unit includes one or more sandboxes, which are configured to execute commands using, for example, individual memory and individual computational power. In other words, a sandbox is a virtual environment that runs its own commands and uses its own data, for example. Additionally, the one or more sandboxes are configured to transform input data, eg, using device-specific data, and/or analyze results received from the DUT (eg, using individual computing power). can do. For example, the use of sandboxes can provide channel processing units for executing one or more programs that can be adapted to the device under test in a secure manner. For example, a program that runs in a sandbox may be provided by a user of the automatic test equipment (rather than by the manufacturer of the automatic test equipment) and runs the risk of interfering with basic functionality of e.g. the channel processing unit. device-specific data may be used to perform the above transformations of the input data. In other words, the sandbox "isolates" the user-provided program, which can be adapted, for example, to the device under test, from other functions of the channel processing unit (which may still allow well-controlled data exchange). "can do. Thus, one or more user-provided programs are securely executed within one or more sandboxes of the channel processing unit to perform device-specific processing of data provided to and/or received from the DUT. be able to.

In a preferred embodiment, the channel processing unit includes a plurality of sandboxes, which host channel processing using one or more protected interfaces such that different sandboxes are isolated from each other. configured to communicate with the unit; This provides a high degree of safety and stability.

In a preferred embodiment, the channel processing unit includes one or more sandboxes, which contain device-specific data (e.g., input data using device-specific encryption keys or device-specific authentication information, data common to multiple DUTs). encryption of input data, or decryption of DUT data using a device-specific decryption key or device-specific authentication information, or processing of input or DUT data using other device-specific information such as device-specific identifiers) configured to perform device-specific functions using Thus, sandboxes can support device-specific processing.

In preferred embodiments, the automated test equipment is configured to upload software to one or more sandboxes to enable device-specific processing of input or DUT data using the sandboxes. Therefore, device-specific functions are updated by uploading from third-party software to enable efficient device-specific computational processes (e.g., communication with a specific DUT interface that knows device configuration). be able to.

In preferred embodiments, the channel processing unit communicates (e.g., one-way or two-way communication) between the channel processing unit and the device under test (e.g., using encryption/decryption and/or to implement device-specific communication protocols using device-specific data to protect (using error detection mechanisms, and/or using error correction mechanisms, and/or using authentication mechanisms); configured to Therefore, individual test access to safety-critical devices under test can be achieved without compromising safety and without overloading the interface between the test control and the device communication unit. can.

Further, the protocol communicating with each DUT is programmable, eg, in HW or SW, and thus reconfigurable. If protocol-aware tests are to be performed, efficient tracing of protocol state may be required. Communication between the device under test and the channel processing unit can be protected by one or more of the methods. The channel processing unit may, for example, detect errors and correct correctable errors. The error detection mechanism can be, for example, a cyclic redundancy check. The error correction mechanism may be (or include) a Viterbi decoding forward error correction code or a block code, for example.

In a preferred embodiment, the channel processing unit comprises a computing unit (CPU, ASIC, FPGA) configured to interact with one or more DUT interfaces. In addition, the computing unit may device-specifically encrypt input data (e.g., of the device communication unit) and/or device-specifically decrypt DUT data to obtain device-under-test compliance data, and/or , perform error detection (e.g. error identification) on DUT data (i.e. detect errors in DUT data) and/or perform error correction on DUT data (i.e. and/or implement a communication protocol using one or more packet counters to obtain device under test conformance data or to evaluate DUT data. and/or configured to implement a communication protocol using one or more device-specific or device-specific identifiers to obtain device-under-test conformance data or to evaluate DUT data be done. By implementing one or more such functions on the channel processing units, the load on the tester controller (eg, which may use multiple channel processing units to coordinate testing of multiple devices under test) is reduced. , the amount of data on the tester interface can be kept reasonably small.

In a preferred embodiment, the channel processing unit comprises a computing unit (CPU, ASIC, FPGA) configured to implement the communication protocol in HW (ASIC/FPGA) and/or SW. In other words, the channel processing units may be configured to communicate with the DUTs by a particular protocol supported by each DUT, the particular protocol being programmable in the HW or SW of the compute unit. Both hardware and software solutions have their particular advantages. Hardware implementations are typically faster and may be necessary to accommodate the needs of very high bandwidth communication interfaces, whereas software implementations are typically more flexible and configurable. be.

In a preferred embodiment, a tester control (e.g. a security credential unit and/or a key unit which may be part of the tester control) obtains (e.g. receives or generates) security credentials and/or keys. broadcast security credentials and/or keys to one or more channel processing units, and/or specifically upload security credentials and/or keys (e.g., in encrypted form) to matching channel processing units. configured to Thus, efficient centralized distribution of security credentials or keys can be achieved, which facilitates the use of automated test equipment in test environments. On the other hand, confidentiality can be guaranteed by using secure communication between the tester control and the channel processing unit, at least for authentication information or keys.

In a preferred embodiment, the tester control (e.g. security credential unit and/or key unit) stores security credentials and/or keys (e.g. automatic test equipment specific security credentials such as automatic test equipment public keys). or key) and broadcast to one or more DUTs.

In preferred embodiments, the communication protocol implementation in the channel processing unit is configured to use (consider) one or more of the following items.
- One or more packet counters - Handshake with device-specific content (e.g. device ID) - Synchronous communication including timestamps - Implementation of communication standards (e.g. IEEE1687.x, IEEE1500, IEEE1149.x)

This makes it possible to establish communication suitable for a particular DUT. The protocol needs of individual DUTs (packet counter device IDs, security certificates or signatures, etc.) can be taken into account without having excessive bandwidth needs in the communication between the tester control and the channel processing unit.

In preferred embodiments, the channel processing unit stores upstream result data (e.g., DUT data from the device under test) and/or analyzes the upstream result data (e.g., using expected result data, For example, compared to expected result data). Analysis of the upstream result data is to identify if there are differences between the upstream result data and the expected result data, which differences may reflect manufacturing defects on the respective DUTs. The channel processing unit preprocesses (e.g., compresses) the upstream result data and/or transmits (forwards) the preprocessed and/or compressed upstream result data to the tester control via the tester interface. is further configured as As a result, the test results can be obtained while the load on the tester control section and the tester interface is light.

In a preferred embodiment, the automatic test equipment includes a plurality of channel processing units, and the tester control transmits common data to the plurality of channel processing units (e.g., simultaneously, e.g., using broadcast, e.g., via a tester data bus). ). In other words, the tester control broadcasts the same (common) data to multiple connected channel processing units simultaneously.

Further, different channel processing units are configured to transform the common data into different device-under-test adaptation data for different devices under test, for example using different device-specific data associated with different devices under test. be. Further, different channel processing units are configured to use different device under test fit data for testing different devices under test. Therefore, common data tailored to a particular device under test within a channel processing unit can be transferred in a bandwidth efficient manner, thereby keeping the load on the tester interface low.

In a preferred embodiment, the tester control stores stimulus data common to multiple channel processing units (e.g., excluding device-under-test-specific characteristics such as device-specific encryption, device-specific identifiers, device-specific configurations). , for example, a central data stream that can define the signal to be output to the device under test). Additionally, the channel processing unit is configured to transform the common stimulus data using local device specific data. Therefore, efficient simultaneous testing of multiple devices under test is possible while avoiding the tester interface as a bottleneck.

In a preferred embodiment, the channel processing unit uses (e.g., encrypted in a device-specific or device-specific manner, or device-specific keys or device-specific authentication information (e.g., adapted to an individual device) configured to transform common stimulus data using local device-specific data or device-specific data to provide device-specific communication. Therefore, individual characteristics of the device under test (authentication information, keys, certificates, device IDs, etc.) can be efficiently taken into account.

In a preferred embodiment, the automatic test equipment includes multiple channel processing units, and the tester control transmits common expected result data to the multiple channel processing units (e.g., simultaneously, using, for example, broadcast, e.g., tester data over a bus). Further, the different channel processing units are configured to obtain respective test results associated with respective devices under test using the common expected result data. Thus, the channel processing unit can determine test results in a distributed manner, avoiding transmitting complete DUT data to the tester control. Device-specific characteristics may be considered in the evaluation using device-specific data, which may also be uploaded from the tester control to the channel processing unit prior to evaluation of test results. Device-specific data may be used, for example, to decode DUT data from the DUT, or to establish a trusted connection with the DUT, or to evaluate the communication protocol used by the DUT.

In a preferred embodiment, the automatic test equipment includes multiple channel processing units, and the tester control transmits common expected result data to the multiple channel processing units (e.g., simultaneously, using, for example, broadcast, e.g., tester data over a bus). Further, different channel processing units use different device-specific data associated with different devices under test to extract respective result data from respective DUT data from different devices under test, and to respective devices under test. It is configured to compare the respective result data to the common expected result data to obtain associated respective test results. Therefore, bottlenecks can be avoided and distributed processing of DUT data can be performed.

Embodiments provide a method for testing one or more devices under test in automatic test equipment that includes a tester controller and a channel processing unit. The method includes device under test conformance data (e.g., protocol recognition data, or data adapted to an individual device under test, or expected result data adapted to a device under test, local device specific data (local device specific information and/or keys and/or or authentication information and/or identity and/or configuration) to input data (e.g., DUT stream, input tester command stream or broadcast data or shared data or data that is equal for different DUTs or common expected result data). Including transforming. The method processes DUT data from a DUT (e.g., data using a protocol determined by device-specific data, such as a device-specific key) in a channel processing unit using local device-specific data ( (e.g., transform or analyze or decrypt using device-specific keys, or unwrap from protocol using device-specific protocol information such as packet counters, device IDs), test and evaluate the DUT. It further includes (extracting the communication payload or evaluating data transmission from the DUT) to obtain device independent or non-DUT specific information.

However, it should be noted that the methods described herein may, if desired, be supplemented by any of the features, functions and details disclosed herein also with respect to automated test equipment. Note that the method may be supplemented with such features, functions and details individually or in combination as desired.

Embodiments according to the invention are described below with reference to the accompanying drawings.

1 shows a block schematic diagram of automatic test equipment for providing device-specific communications to a device under test, according to one embodiment of the present invention; FIG. 1 shows a block schematic diagram of automatic test equipment for providing device-specific communications to a device under test, according to one embodiment of the present invention; FIG. 1 shows a block schematic diagram of automatic test equipment for providing device-specific communications to a device under test, according to one embodiment of the present invention; FIG. Figure 3 shows a block schematic diagram of a channel processing unit according to an embodiment of the present invention; FIG. 4 shows a block schematic diagram of a sandbox within a channel processing unit, according to an embodiment of the present invention; FIG. 4 shows a block schematic diagram of a channel processing unit with a security module, according to one embodiment of the present invention; 1 shows a block schematic diagram of an automated test equipment for credential management, according to one embodiment of the present invention; FIG. FIG. 4 shows a block schematic diagram of a channel processing unit including a protocol implementation unit, according to one embodiment of the present invention; FIG. 4 shows a block schematic diagram of a channel processing unit with pre-processing of upstream result data according to an embodiment of the present invention; FIG. 4 shows a block schematic diagram of a sandbox within a channel processing unit, according to an embodiment of the present invention; 1 shows a block diagram of a conventional automatic test instrument; FIG.

Detailed Description of the Drawings 1 . Automatic Test Equipment According to FIGS. 1a and 1b FIG. 1a shows a block schematic diagram of an automatic test equipment 100 according to one embodiment of the present invention.

Automatic test equipment 100 receives input data 114a (e.g., DUT stream, or input tester command stream, or broadcast data, or shared data, or data that is equal for different DUTs, or common expected result data) and device-specific data 114b. to the matching module (eg, to the channel processing unit) and/or specifically uploaded.

Automatic test equipment 100 includes channel processing unit 124 configured to transform input data 114a using device specific data 114b to obtain device under test conformance data 126 for testing device under test 130. further includes Alternatively or additionally, automatic test equipment 100 is configured to process DUT data 128 from DUT 130 using device-specific data 114 b to test or evaluate DUT 130 .

Thus, the channel processing unit can generate device under test adaptation data in a distributed manner, which transmits different device under test adaptation data to different channel processing units, all of which can be coupled to the tester controller. can help avoid doing so. For example, the amount of input data 114a (which may be device-independent and not tailored to an individual DUT) may be significantly larger than device-specific data, which may be, for example, an individual DUT may vary. As a result, in automatic test equipment that includes multiple channel processing units, it may only be necessary to separately transmit small amounts of device-specific data to the different channel processing units. Also, for example, a tester controller capable of handling simultaneous testing of multiple devices under test using different channel processing units may find that this functionality is taken over by one or more channel processing units coupled to the tester controller. It eliminates the need to perform a DUT-specific (DUT-specific) adaptation of the "input data".

Further, it should be noted that the automated test equipment of FIG. 1a may be supplemented, individually and in combination, by any of the features, functions, and details disclosed herein, as desired.

FIG. 1b shows a block schematic diagram of automatic test equipment 100 according to one embodiment of the present invention.

Automatic test equipment 100 includes tester control section 110 . Tester control 110 includes a centralized test flow manager 112 configured to broadcast and/or specifically upload input data 114a to one or more matching modules (eg, to matching channel processing units 124a-124z). . In addition, the centralized test flow manager provides device-specific data 114b (eg, keys and/or credentials and/or IDs and and/or configured to broadcast and/or specifically upload a configuration).

Automatic test equipment 100 further includes tester 120 . The tester includes a centralized test flow manager 112 (which is part of tester control 110) and a tester data bus 122 coupled to a plurality of channel processing units 124a-124z. Tester data bus 122 receives (or acquires) input data 114a comprising device specific data 114b from centralized test flow manager 112 (which is part of tester control 110) and transfers input data 114a to channel processing units 124a through 124a. 124z. The channel processing unit 124a has a memory unit 124a-1 and a computation unit 124a-2. Device specific data 114b is stored in memory unit 124a-1. Input data 114a is processed along with device specific data 114b in computing unit 124a-2 to obtain device under test fit data 126 for testing device under test 130a-1.

Channel processing unit 124a is configured to transmit device under test conformance data to DUT 130a-1 mounted on load board or probe card 130 . Device-under-test compliance data is transmitted to each DUT 130a-1 by device-specific channel 1.1 and the respective DUT interface. The DUT interface may be coupled to, for example, a PCIe physical interface or a USB physical interface, but may also include a JTAG interface, an iJTAG interface, or any other suitable interface.

Device under test compliance data may represent program code and/or data for a test program (eg, for testing a system-on-chip) to be used (eg, executed or processed) on DUT 130a-1. may be After test execution, the DUT data 128 is transmitted to the channel processing unit 124a via the respective DUT interface and device specific channel 1.1. Channel processing unit 124a may, for example, process respective DUT data using device-specific data to extract upstream result data (eg, respective result data, or DUT data from the device under test). Configured. Accordingly, the channel processing unit 124a is configured to store the upstream result data in the memory unit and/or use the expected result data to analyze or compare the upstream result data with the expected result data. In other words, analyzing the upstream result data is to identify if there are differences between the upstream result data and the expected result data, which differences may reflect manufacturing defects on the respective DUTs. can. In addition, upstream result data may be preprocessed and/or compressed by channel processing unit 124 a and/or transmitted (forwarded) to tester control 110 via tester data bus (interface) 122 .

In multi-site DUT testing, increasing test efficiency plays an important role. Reducing bus traffic and CPU requirements using efficient test methods can help reduce overall cost and test time. Tests applied to multiple DUTs may tend to have the same or similar results if there are no software or hardware related defects or failures on the DUT platform. With this in mind, the channel processing unit of the present invention may apply a comparison operation in the calculation unit. Therefore, in the computing unit, the common expected result data from the tester control is compared with the respective test result data from the DUT. After the comparison operation, only the differences between the common expected test result data and the respective test result data may be compressed and transmitted to tester control 110 . This can reduce bus traffic and CPU requirements for the tester control.

Another (optional) feature that contributes to DUT test efficiency is optional sandboxing that provides better memory (124a-1 to 124z-1) and computational (124a-2 to 124z-2) resource utilization. be. Channel processing units 124a-124z may optionally include one or more sandboxes (eg, as indicated by reference numeral 124z-3), where one or more sandboxes 124z-3 may be architecture-dependent. It is configured to execute commands using the capabilities of virtual individual memory 124z-1 and computation 124z-2, with or without resource sharing accordingly. One or more sandboxes 124z-3 are configured to transform input data 114a using device-specific data 114b, and/or one or more sandboxes 124z-3 transform results received from DUT 130 into Configured to analyze with individual computing power. Additionally, automatic test equipment 100 may upload software to one or more sandboxes 124z-3 to enable device-specific processing of input data 114a or DUT data 128 using sandboxes 124z-3. configured to Thus, the sandboxing feature allows virtual individual memory and computing power to test DUT 130a-1 in an isolated environment.

As an additional note, if desired, two or more devices under test (eg, DUTs 130a-1 and 130a-2) may be connected, for example, to separate channels (eg, channel 1.1 and channel 1 as shown in FIG. 2). .2) can be combined into a single channel processing unit (eg, channel processing unit 124a). However, in some embodiments a single DUT may be coupled to the channel processing unit. Also, if multiple channel processing units are used to test a single DUT, for example if the DUT contains a very large number of pins and/or consists of multiple potentially independent interfaces. can be.

Note, however, that tester 120 need not necessarily have component 124z. Rather, one or more of the components may be omitted or changed, if desired.

Further, it should be noted that automatic test instrument 100 may be supplemented by any of the features, functions, and details disclosed herein, individually and in combination, as desired.

2. Example According to FIG. 2 FIG. 2 shows a block schematic diagram of automatic test equipment 200 for providing device-specific communications to a device under test 230a-1, according to one embodiment of the present invention.

Automatic test equipment 200 includes a tester control section 210 . The tester controller 210 includes a centralized test flow manager 212 configured to broadcast and/or specifically upload input data (eg, data 114a) and device-specific data (eg, data 114b) to one or more matching modules. including.

Automatic test equipment 100 further includes tester 220 . The tester includes a tester data bus 222, which is coupled to a centralized test flow manager 212 and a plurality of channel processing units 224a-224m. Tester data bus 222 is configured to receive input data comprising device-specific data from centralized test flow manager 212 and forward the input data to a plurality of channel processing units 224a-224m. The channel processing unit 224a has a memory unit 224a-1 and a computation unit 224a-2. Device specific data is stored in memory unit 224a-1. The input data is processed with device-specific data in computing unit 224a-2 to obtain device-under-test fit data 126 for testing device-under-test 230a-1.

The use of per-channel processing units transforms input data with (local) device-specific data (eg local device-specific information and/or keys and/or authentication information and/or IDs and/or configurations). Encrypted/decrypted device-specific communications are used to prevent interfaces (eg, channel 1.1 and channel 1.2) from unauthorized access to internal device structures.

Further, it should be noted that automatic test equipment 200 may be supplemented by any of the features, functions, and details disclosed herein, individually and in combination, as desired.

3. Example According to FIG. 3 FIG. 3 shows a block schematic diagram of a channel processing unit 320 according to one embodiment of the invention. Channel processing unit 320 may, for example, replace channel processing units 124a-124z or channel processing units 224a-224m.

Channel processing unit 320 includes memory 320a and computation unit 320b. The memory 320a unit is configured to store data (eg, device specific data, which may include keys and/or authentication information and/or IDs) and configurations. Channel processing unit 320 interprets input data (e.g., DUT streams or input tester command stream or broadcast data or shared data or data equivalent to different DUTs or common expected result data) into device specific data or device specific communications. Secure device communication is achieved through encryption or decryption of DUT communications, or authorization, which refers to granting a certain level of access, or authentication, which refers to verifying the identity of a user.

Furthermore, with respect to secure device communication, the communication between the DUT and the channel processing unit is (alternatively or additionally) further protected by using packet counters and/or error correction codes and/or error identification codes. may be

Protocol-aware data (e.g., device-under-test adaptation data, or data adapted to individual devices-under-test, or expected-result data adapted to devices-under-test) may, for example, be input data sent from the tester control. Obtained by converting with local device specific information.

Thus, channel processing unit 320 can help reduce the load on the tester control and tester data bus while ensuring a high level of security.

Further, it should be noted that channel processing unit 300 may be supplemented by any of the features, functions, and details disclosed herein, individually and in combination, as desired.

4. Example according to FIG. 4 FIG. 4 shows a block schematic diagram of a sandbox within a channel processing unit according to an embodiment of the invention.

Channel processing unit 420 (eg, which may replace any channel processing unit disclosed herein) may optionally include at least one sandbox 420c, wherein at least one sandbox 420c is stored in memory. It includes (or associates) a unit 420a and a computation 420b unit.

At least one sandbox 420c is configured to transform input data using device-specific data and/or at least one sandbox 420c is configured to analyze results received from DUT 430 with individual computing power. configured to Further, automatic test equipment 400 is configured to upload software to at least one sandbox 420c to enable device-specific processing of input or DUT data using sandbox 420c. Additionally, the sandbox may include a secure and well-defined interface to the rest of the channel processing unit to enable the provision of data from the sandbox to the DUT and/or vice versa. Thus, the sandbox feature allows virtual individual memory and computing power to test DUT 430 in an isolated environment.

Further, it should be noted that channel processing unit 400 may be supplemented by any of the features, functions, and details disclosed herein, individually and in combination, as desired.

5. Embodiment According to FIG. 5 FIG. 5 shows a block schematic diagram of a channel processing unit with a security module according to an embodiment of the invention.

Channel processing unit 520 (which may, for example, replace any of the channel processing units disclosed herein) includes memory 520a and computation unit 520b. Computing unit 520b further includes a security module 520c. Device-specific data (eg, keys, credentials, IDs, and configurations) are stored in local memory 520a prior to DUT communication. A computing unit 520b including a security module 520c is configured to interact with the DUT interface.

The security module is configured to protect DUT communications by managing and performing encryption/decryption or authorization or authentication functions. Additionally, communication between the DUT and the channel processing unit may be performed using packet counters and/or error detection techniques, e.g., to detect errors associated with the communication channel (e.g., transmission medium) after the DUT data is received by the channel processing unit. Further protection can be provided by using correction codes and/or error identification codes. Error identification codes and error correction codes add some redundancy to the input data, check the integrity of the transmitted data (e.g. data adapted to the device under test), and are due to channel transmission. to recover received data when it is corrupted. The error identification (detection) code may be (or include) a cyclic redundancy check, for example. The error correction code may typically be (or include) one or more forward error correction codes (eg, Viterbi decoding, block code) and/or automatic repeat requests, and the like.

Further, it should be noted that channel processing unit 500 may be supplemented by any of the features, functions, and details disclosed herein, individually and in combination, as desired.

6. Example According to FIG. 6 FIG. 6 shows a block schematic diagram of an automatic test equipment 600 for credential management according to one embodiment of the present invention.

The tester control 610 includes a centralized test flow manager 612, which further includes a secure credential 614 unit. The tester control obtains (e.g., receives or generates) security credentials and/or keys (e.g., security credentials or keys unique to the automatic test equipment 600, such as the public key of the automatic test equipment 600); Multiple matching modules (eg, channel processing units 524a-624m, which may correspond to any of the channel processing units disclosed herein) and/or one or more DUTs (eg, security credentials or keys) configured to broadcast and/or specifically upload. Additionally, encryption may be applied by (or using) tester-specific credentials known to the CPU.

Further, it should be noted that automatic test equipment 600 may be supplemented by any of the features, functions, and details disclosed herein, individually and in combination, as desired.

7. Example according to FIG. 7 FIG. 7 shows a block schematic diagram of a channel processing unit including a protocol implementation unit according to an embodiment of the invention.

Channel processing unit 720 (which may replace any of the channel processing units disclosed herein) includes memory 720a and computation unit 720b. Compute unit 720b further includes a protocol implementation unit 720c. The protocol that communicates with each DUT is hardware or software programmable and therefore reconfigurable. Compute unit 720b is configured to interact with one or more DUT interfaces.

Communication protocol implementation in channel processing unit 720 may include, for example, one or more packet counters, and/or handshake with device-specific content (e.g., device ID), and/or synchronous communication including timestamps, and/or IEEE1687. x, or IEEE1500, or IEEE1149. It is configured to use (consider) implementations of communication standards such as x.

By using the protocol implementation in compute unit 720b, the amount of data upload from the tester control to the channel processing unit can be kept small as the protocol overhead can be generated by the channel processing unit. Device-specific protocol aspects are also introduced on the side of the channel processing unit, which also significantly reduces the load on the tester bus.

Further, it should be noted that channel processing unit 700 may be supplemented by any of the features, functions and details disclosed herein, individually and in combination, as desired.

8. Applications Some application examples will now be described with reference to FIGS.

FIG. 8 shows a block schematic diagram of a first scenario in which the results of local preprocessing of upstream results are stored and compared with expected results.

Channel processing unit 820 (which may replace any of the channel processing units disclosed herein) includes memory 820a and computation unit 820b. Memory unit 820a includes an expected result unit or memory unit portion 820a-1 that may store common expected result data provided by the tester controller (which may be common to multiple devices under test). Further, computation unit 820b may store received DUT data (or preprocessed DUT data that has been preprocessed in a device-specific or device-specific manner, for example using device-specific data) in memory unit 820a. Includes a comparator unit 820b-1 that may compare expected result data (eg, expected result data processed in a device-specific manner using device-specific data by the channel processing unit).

Channel processing unit 820 processes (or pre-processes) respective DUT data using device-specific data, for example, to extract upstream result data (eg, respective result data, or DUT data from the device under test). processing). Thus, channel processing unit 820 is configured, for example, to store upstream result data in memory unit 820a. Further, channel processing unit 820 is configured to analyze upstream result data using, for example, expected result data. This compares upstream result data with expected result data stored in expected result unit 820a-1 (which is part of memory unit 820a) in comparator unit 820b-1 (which is part of computation unit 820b). can be achieved by

Additionally, the upstream result data may be preprocessed and/or compressed by, for example, a channel processing unit and/or transmitted (forwarded) to the tester control via the tester data bus (interface) 822 . Upstream result data may be compressed, for example, to reduce the amount of data and reduce transmission time for faster exchange of data.

Automatic test equipment 800 may test a device under test (e.g., upload a program and/or execute one or more portions of a test program, and/or generate result data, e.g., based on an entire test executive program in a test sequence, for example). downloading and/or debugging). The channel processing unit 820, for example, controls sequence execution (eg, adjustment of the timing of edges in the signal provided to the DUT) and a sequence that transfers a digital data stream or sequence of signals with specific timing adjustments to the drivers. configured to provide output to a single.

The driver is configured to take input from the sequencing and communicate with the device under test via an (eg, interactive) interface (eg, which may be an iJTAG interface or an RSN interface or an IEEE-1687 interface). . The driver may, for example, be configured to add or adjust analog voltage levels, or the driver may act like a multiplexer to switch the device under test between different voltage levels so that the driver under test An acceptable voltage level may be checked.

The driver stimulates the sequences, which are then transferred over the data communication channel and communicated with the device under test through the DUT interface. For example, the functionality of the device under test over various voltage and frequency levels can be checked through sequences stimulated by the driver. In some cases, the sequence received from the DUT and the sequence transmitted by the DUT must be exactly bit-for-bit identical. The DUT driver may send the data sequence to automatic test equipment 800, for example, via a DfT interface that checks the received sequence for errors. Note that the channel processing unit is for example arranged to compare the received sequence (DUT data) with the expected result in a comparator that is part of the computation unit.

Generally speaking, different approaches are possible. As an example, the channel processing unit receives common expected result data from the tester controller, converts the common expected result data to device matching expected result data, stores the device matching expected result data, and stores the device matching expected result data and the DUT. The DUT can be evaluated by performing a comparison with the DUT data received from. Alternatively, the channel processing unit stores common expected result data (common to multiple DUTs) and uses device-specific data to extract the result data from the DUT data (thereby taking device-specific protocol characteristics into account). ), and the extracted result data may be compared to the common result data, thereby evaluating the DUT. However, different processing operations are also possible.

FIG. 9 shows a block schematic diagram of a second scenario in which a sandboxed channel processing unit 920 is represented according to one embodiment of the invention.

Channel processing unit 920 includes at least one sandbox 920c, which includes memory unit 920a and computation unit 920b. Memory unit 920a is configured to store device specific data and configurations.

Automated test equipment 900 is configured to upload software to at least one sandbox 920c to enable device-specific processing of input or DUT data using sandbox 920c. Similarly, device-specific functionality can be updated by uploading from third-party software to enable efficient device-specific computational processes (e.g., communication with a specific DUT interface that knows device configuration). can do.

The sandboxed channel processing unit 920 is configured to control sequence execution and provide an output to the sequencing that forwards the sequence of signals with specific timing adjustments to the drivers. The driver can be configured to take the digital sequence of signals, add or adjust analog voltage levels, and transfer the signals to the device under test 930a through the DUT interface. For example, the functionality of the device under test over various voltage and frequency levels is checked through sequences stimulated by the driver. The DUT driver can, for example, send the sequences to the debug interface via the DfT interface. The debug interface can, for example, download a sequence of DUT data and transfer it to automatic test equipment 900 for checking the received sequence for errors.

However, it should be noted that the automatic test equipment 800, 900 may be supplemented, individually and in combination, by any of the features, functions and details disclosed herein, if desired.

9. Conventional Solution According to FIG. 10 FIG. 10 shows a block schematic diagram of a conventional automatic test equipment 1000 . However, conventional automatic test equipment 1000 lacks a DUT-specific (or device-specific) channel processing unit and uses encryption/decryption or error detection mechanisms or error correction mechanisms or authentication mechanisms. Note that it is similar to automated test equipment 100, 200, or 600, except for the fact that there are no security aspects such as usage. Rather, prior art solutions rely on centralized channel architectures that cannot perform local data transformations. Furthermore, using a centralized channel architecture requires data to be transferred to a central processing unit and computed on the central processing unit. In this case, there is a high communication overhead or bottleneck for device-specific communication due to central processing operations.

10. Conclusions The following provides some conclusions. Also disclosed are aspects of the present invention, which may be used individually or in combination and introduced individually and in combination into any of the other embodiments as desired.

Embodiments in accordance with the present invention create efficient and secure device-specific communication in multi-site DUT testing.

According to one aspect of the invention, a processing unit for each channel is used to transform a central data stream that is local device specific (or has local device specific data).

According to one aspect, encrypted device-specific communications can be performed in this manner.

According to another aspect, the communication with the channel processing unit (or plurality of channel processing units) is controlled by the characteristics of the individual devices under test (e.g., individual cryptographic keys or individual authentication information), e.g. It is as device independent as possible (in the sense that it is not taken into account in the amount of main data communicated between the part and the channel processing unit).

For example, the automatic test equipment according to FIG. 2 can be used for this purpose.

Certain aspects relating to the channel processing unit are described below.

According to one aspect, the channel processing unit can convert the input tester command stream into device-specific communications, eg, secure device communications and/or protocol awareness with local device-specific information.

According to one aspect, the central processing unit can use transparent input/output streams to external workstations (which can, for example, implement tester controls).

According to one aspect, embodiments in accordance with the present invention enable (or perform) result analysis directly on the channel processing unit to reduce bus traffic and/or CPU requirements.

According to one aspect, the channel processing unit combines storage (eg, memory) and computing (eg, CPU and/or ASIC and/or FPGA).

For example, a channel processing unit according to FIG. 3 may be used to implement these aspects.

According to one aspect, the channel processing unit may employ sandboxing.

For example, sandboxing can include local execution of tester commands using their respective memory and computing power (with or without resource sharing, depending on the architecture).

According to one aspect, the sandboxes communicate with the host channel processing unit using a protected interface such that one sandbox is isolated from other sandboxes. In some embodiments, inter-sandbox communication is only possible if specifically permitted (eg, using configuration).

According to one aspect, there may be one or more sandboxes per channel.

An example of a channel processing unit using one or more sandboxes is shown in FIG.

In the following, applications according to aspects of the invention are described.

According to one aspect, embodiments according to the invention may be used to perform secure device communications.

According to one aspect, device-specific data (eg, keys, credentials, IDs, configurations) are stored in local memory prior to communication.

According to another aspect, the computing module may, for example, use encryption and/or decryption, and/or package counters, and/or using error correction and error identification codes), interacting with the DUT interface.

According to one aspect, the implementation of the communication protocol may be hardware or software.

An example of a channel processing unit using secure device communication is shown in FIG.

According to one aspect, secure device communication includes credential management.

For example, in a first step, authentication information (device-specific or device-identical) is presented to the test flow manager.

Further, for example, in the second step there is an upload to the channel processing unit, which can be performed using broadcast or using a specific upload to the matching module.

Further, according to one aspect, there may be encryption (eg, of the authentication information) with tester-specific authentication information known to the CPUs (eg, the CPU of the tester controller and the CPU of the channel processing unit).

An example of automatic test equipment using credential management is shown in FIG.

According to one aspect, embodiments according to the invention are adapted to perform secure multi-site protocol recognition tests.

According to one aspect of the invention, a protocol implementation on the channel processing unit may for example:
- packet counters; and/or - handshake with device-specific content, e.g. id; /or - eg IEEE 1687. Implementations of communication standards such as IEEE 1500, IEEE 1149.4, etc., can be considered.

An example of a channel processing unit for secure multi-standard protocol recognition testing is shown in FIG.

According to one aspect, embodiments according to the present invention use local preprocessing of upstream results.

According to one aspect, the expected result is stored in the channel processing unit (eg, in a first step).

According to one aspect, during test execution, upstream result data is analyzed and pre-processed prior to transmission over the tester bus interface (eg, using signature generation and/or using test result compression). be done.

This enables multi-site efficient interactive test flow execution.

An example of a channel processing unit (or test chain) using local preprocessing of upstream results is shown in FIG.

According to another aspect, customers can upload code to the sandbox.

According to one aspect, device-specific functions can be executed directly on sandboxed channel processing units as specified by the customer. This allows an efficient device-specific computational process. For example, this allows communication with a specific DfT (design for test) interface that knows the device configuration. In addition, this may enable the execution of multi-site efficient interactive test flows.

An example of a channel processing unit (or test chain) is shown in FIG.

In the following, some advantages of embodiments of the invention over conventional solutions are described. However, it should be noted that embodiments in accordance with the invention need not include some or all of the advantages mentioned below.

According to embodiments of the present invention, a DUT-specific (device-specific) channel processing unit that is part of automatic test equipment is disclosed. In other words, embodiments according to the present invention solve the problem of improving communication overhead by introducing DUT-specific communication. For example, in standard practice, multiple DUTs tested in parallel build up a complete processing load on the central processing unit. DUT-specific processing, on the other hand, is performed in each channel processing unit to improve communication overhead over the interface (or data bus).

Embodiments according to the present invention are based on a secure communication approach to achieve secure multi-site DUT testing by using advanced security architecture. Security mechanisms rely on encrypted/decrypted DUT communications, or error detection/correction or authentication mechanisms. Moreover, the communication between the DUT and the channel processing unit is further protected, for example by using packet counters and/or error correction codes and/or error identification codes. This guarantees the highest possible security in multi-site testing situations.

Furthermore, embodiments in accordance with the present invention enable efficient device-specific communication. In particular, this is achieved through the results analysis approach and the sandboxed channel processing unit approach. For example, in the results analysis technique, each test result data from the DUT is compared with common expected result data broadcast by the tester control within the channel processing unit. if the respective test result (upstream result data) differs from the common expected result data, the difference between the respective test result data and/or the common expected test result data and the respective test result data is compressed; It is transmitted to the tester control section. In conclusion, the result analysis approach to channel processing units minimizes test time by reducing bus traffic and CPU requirements. In some embodiments, a sandboxed channel processing unit is used whose device-specific functionality can be updated by uploading from third-party software to enable efficient device-specific computational processes. be. For example, customized DUT testing can be performed by a third party.

In conclusion, embodiments according to the present invention can be used to test devices under test in an efficient and safe manner and are therefore advantageous over other concepts.

11. ALTERNATIVE IMPLEMENTATIONS The memory described herein (and shown in the figures) can be, for example, as volatile (e.g., using RAM, DDR, embedded memory, etc.) and/or as non-volatile (e.g., for example, using SSD, HDD, flash, etc.).

Although some aspects have been described in the context of an apparatus, it is clear that these aspects also represent descriptions of corresponding methods, where blocks or devices correspond to method steps or features of method steps. Similarly, aspects described in the context of method steps also represent descriptions of corresponding blocks or items or features of the corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus such as a microprocessor, programmable computer or electronic circuitry. In some embodiments, one or more of the most critical method steps may be performed by such apparatus.

Depending on the requirements of a particular implementation, embodiments of the invention can be implemented in hardware or in software. This implementation comprises a digital storage medium, e.g. ) disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM or flash memory. As such, the digital storage medium may be computer readable.

Some embodiments according to the present invention include a data carrier having electronically readable control signals, the electronically readable control signals being programmed to cause one of the methods described herein to be performed. It is possible to work with the system.

Generally, embodiments of the present invention can be implemented as a computer program product having program code that, when the computer program product is run on a computer, performs one of the methods. It is operable. Program code may be stored, for example, in a machine-readable carrier.

Another embodiment includes a computer program stored on a machine-readable carrier for performing one of the methods described herein.

Thus, in other words, an embodiment of the method of the present invention is a computer having program code for performing one of the methods described herein when the computer program is run on the computer. It's a program.

A further embodiment of the method of the invention is therefore a data carrier (or digital storage medium or computer readable medium) bearing a computer program for performing one of the methods described herein. . A data carrier, digital storage medium or recorded medium is typically tangible and/or non-transitory.

A further embodiment of the method of the invention is therefore a data stream or a sequence of signals representing the computer program for performing one of the methods described herein. For example, a data stream or sequence of signals may be arranged to be transferred over a data communication connection, for example, over the Internet.

Further embodiments include processing means, such as a computer or programmable logic device, configured or adapted to perform one of the methods described herein.

A further embodiment includes a computer installed with a computer program for performing one of the methods described herein.

Further embodiments according to the present invention are configured to transfer (e.g., electronically or optically) to a receiver a computer program for performing one of the methods described herein. device or system. A receiver may be, for example, a computer, mobile device, memory device, or the like. The device or system can include, for example, a file server for transferring computer programs to receivers.

In some embodiments, programmable logic devices (eg, field programmable gate arrays) 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 method is preferably performed by any hardware device.

The devices described herein may be implemented using a hardware device, or using a computer, or using a combination of hardware devices and computers.

The devices described herein, or any component of the devices described herein, may be implemented at least partially in hardware and/or software.

The methods described herein can be performed using a hardware apparatus, using a computer, or using a combination of hardware apparatus and computer.

The methods described herein, or any component of the apparatus described herein, may be performed, at least in part, by hardware and/or software.

The above-described embodiments merely illustrate the principles of the invention. It is understood that modifications and variations in the arrangements and details described herein will be apparent to others skilled in the art. It is the intention, therefore, to be limited only by the scope of the appended claims and not by any specific details presented in the description and illustration of the embodiments herein.

Claims (24)

Automatic test equipment for testing one or more devices under test, the automatic test equipment comprising:
a tester control unit;
a channel processing unit;
the channel processing unit is configured to transform input data using device specific data to obtain device under test conformance data for testing the device under test;
and/or the channel processing unit is configured to process DUT data using device specific data to test the DUT;
automatic test equipment. the channel processing unit for communicating the device under test conformance data to the device under test and/or receiving the DUT data from the device under test;
configured to communicate with one of the one or more DUTs using a device-specific channel;
The automatic test instrument of claim 1. the channel processing unit is configured to communicate with the tester control using a tester interface;
3. The automatic test equipment according to claim 1 or 2. the tester control is configured to broadcast input data to a plurality of channel processing units via the tester interface;
An automatic test instrument according to claim 3. the tester interface is a tester data bus coupled to the tester control and a plurality of channel processing units;
Automatic test equipment according to claim 3 or 4. the channel processing unit includes a volatile or non-volatile storage device and a computing unit;
the channel processing unit is configured to store the device specific data in the storage device of the channel processing unit;
the channel processing unit is configured to transform the input data using the computation unit and/or process the DUT data using the computation unit;
Automatic test equipment according to any one of claims 1 to 5. the channel processing unit includes one or more sandboxes;
The one or more sandboxes are configured to execute commands using respective memories, and/or The one or more sandboxes transform the input data using the device-specific data and/or the one or more sandboxes are configured to analyze results received from the DUT,
Automatic test equipment according to any one of claims 1 to 6. the channel processing unit includes a plurality of sandboxes;
the sandbox is configured to communicate with a host channel processing unit using one or more protected interfaces such that different sandboxes are isolated from each other;
Automatic test equipment according to any one of claims 1 to 7. the channel processing unit includes one or more sandboxes, one or more sandboxes configured to perform device-specific functions using the device-specific data;
Automatic test equipment according to any one of claims 1 to 8. The automated test equipment is configured to upload software to one or more sandboxes to enable device-specific processing of the input data or the DUT data using the sandboxes.
Automatic test equipment according to any one of claims 7 to 9. the channel processing unit is configured to implement a communication protocol using the device specific data to secure communications between the channel processing unit and the device under test;
Automatic test equipment according to any one of claims 1 to 10. the channel processing unit includes a computing unit;
The computing unit is configured to interact with one or more DUT interfaces, the computing unit encrypting the input data and/or the decode the DUT data, and/or perform error detection on the DUT data, and/or perform error detection on the DUT data to obtain device compatibility data or to evaluate the DUT data; 1 or configured to implement a communication protocol using multiple device-specific identifiers,
Automatic test equipment according to any one of claims 1 to 11. the channel processing unit includes a computing unit;
the computing unit is configured to implement a communication protocol in HW and/or SW;
Automatic test equipment according to any one of claims 1 to 12. the tester control configured to obtain security credentials and/or keys;
The tester control broadcasts the security credentials and/or keys to the one or more channel processing units and/or specifically uploads the security credentials and/or keys to matching channel processing units. It is configured,
14. An automatic test instrument according to any one of claims 1-13. the tester control is configured to obtain and/or broadcast security credentials to one or more DUTs;
15. An automatic test instrument according to any one of claims 1-14. The communication protocol implementation in the channel processing unit uses one or more of the following items: - one or more packet counters - handshake with device specific content - synchronous communication - implementation of communication standards It is configured,
16. An automatic test instrument according to any one of claims 1-15. Said channel processing unit stores upstream results and/or analyzes upstream result data and/or preprocesses said upstream result data and/or converts preprocessed and/or compressed upstream result data to said configured to transmit to a tester control,
17. An automatic test instrument according to any one of claims 1-16. The automatic test equipment includes a plurality of channel processing units,
the tester control configured to provide common data to the plurality of channel processing units;
Different channel processing units are configured to convert the common data into different device-under-test adaptation data using different device-specific data, and to test the different devices-under-test using the different device-under-test adaptation data. has been
18. An automatic test instrument according to any one of claims 1-17. the tester control configured to provide common stimulus data to a plurality of channel processing units;
the channel processing unit is configured to transform the common stimulus data using device-specific data;
19. An automatic test instrument according to any one of claims 1-18. the channel processing unit is configured to transform the common stimulus data using device-specific data or device-specific data to provide device-specific communication;
20. The automated test equipment of claim 19. The automatic test equipment includes a plurality of channel processing units,
the tester control configured to provide common expected result data to the plurality of channel processing units;
different channel processing units are configured to obtain respective test results associated with the respective devices under test using the common expected result data;
21. An automatic test instrument according to any one of claims 1-20. The automatic test equipment includes a plurality of channel processing units,
the tester control configured to provide common expected result data to the plurality of channel processing units;
different channel processing units extracting respective result data from respective DUT data using different device-specific data;
comparing the respective result data to the common expected result data to obtain respective test results associated with the respective devices under test;
is configured to do
22. An automatic test instrument according to any one of claims 1-21. A method of testing one or more devices under test in an automatic test equipment comprising a tester controller and a channel processing unit, the method comprising:
converting input data using device specific data to obtain device under test conformance data for testing the device under test in the channel processing unit;
and/or
A method comprising: processing DUT data using device specific data to test a DUT in the channel processing unit. 24. A computer program for performing the method of claim 23 when run on a computer.

Images