Automated Test Equipment and Method Generated by Trigger

Abstract

An automated test device includes a main test process control configured to operate a test process among a plurality of device communication units and / or provide trigger configuration information to a local computing unit. The automated test device further includes a device communication unit that includes a trigger generation unit configured to generate a trigger signal. The trigger generation unit is further configured to extract payload data from a protocol-based data stream received from the device under test and generate the trigger signal in response to the extracted payload data or in response to one or more protocol events. A method and a computer program for testing one or more devices under test in an automated test device are also disclosed.

Description

Technical Field

[0001] Embodiments in accordance with the present invention relate to automated test equipment.

[0002] Another embodiment in accordance with the present invention relates to a method for testing a device under test.

[0003] Generally, embodiments in accordance with the present invention relate to generating a trigger signal in response to data received from a device under test.

[0004] Embodiments in accordance with the present invention relate to an automated test equipment and method for a real-time trigger generation system for approaching a DUT interface. Background Art

[0005] The increasing complexity of electronic device structures (including, for example, microprocessors, sensors, digital signal processors, etc.) has led to the development of advanced technologies for testing electronic devices. For example, automated test equipment is commonly used to test devices under test.

[0006] In automated test equipment, the test process depends on the generation of a trigger signal, which causes a change in the test execution. In the trigger structure, a signal for a specific event is typically issued during the test execution process, and the process is allowed to react to the event. In other words, based on the event signal applied to the trigger generation unit, a trigger signal is generated. For example, for an interactive test process that depends on the results from a device under test, the generation of a trigger signal is particularly required, which is equivalent to an interruption in the processing unit.

[0007] It has been found that in a conventional structure, on the one hand, the method of centralized generation of data transmission and triggering from a device under test to a central execution unit usually results in unacceptable (i.e., high) transmission delays. It has been found that a central data bus (i.e., a central data interface or a central communication interface) can, for example, provide a standardized transmission capacity, and thus a high data volume leads to a large traffic on the central data bus and a slow data exchange speed. Therefore, it has been found that it becomes difficult or impossible to maintain the accuracy of signals (such as clocks), which results in limited real-time performance and limited multi-site efficiency.

[0008] On the other hand, a DUT connection method directly based on a PC is commonly used. However, it has been found that such direct PC usage leads to limited multi-site possibilities. In addition, it has been found that the method of directly connecting a device under test based on a PC cannot effectively control tester resources, such as power supplies. It has been found that, thereby, it becomes difficult or impossible to maintain the accuracy of signals (such as clocks), which results in limited real-time performance and limited multi-site efficiency.

[0009] In a third aspect, real-time pattern comparison methods performed by simple matching loops (i.e., simple matching of a pattern bit sequence) are commonly used in conventional solutions of existing ADV cards. However, it has been found that due to difficulties in bit synchronization, real-time comparison of pattern bits is impossible for non-deterministic (e.g., asynchronous transmission) interfaces and impossible for protocol-aware (or protocol-aware communication). In addition, due to limited device-specific information, content-aware implementation is impossible.

[0010] Techniques have been proposed that trigger generation when receiving test result data from a device under test or directly trigger generation in the device under test. For example, in US 20180372780A1, a test and measurement device capable of outputting a trigger signal when receiving a signal from a device under test is disclosed. US20190383873A1 discloses a test and measurement device that receives input data from a device under test only after certain conditions have occurred, thereby detecting anomalies through pattern comparison. In US20090072838A1, a trigger signal obtained from a device under test is disclosed. US9164859B2 discloses a method capable of simultaneously testing a device under test.

[0011] In view of the above, there is a need for a test concept that brings an improved trade-off among test coverage, timing accuracy, latency, and implementation effort. Summary of the Invention

[0012] According to an embodiment of the present invention, an automated test device for testing one or more devices under test is provided, including a main test process control that can be configured, for example, to operate (or coordinate) test processes in a plurality of device communication units and / or provide trigger configuration information. The automated test device further includes a device communication unit that is coupled to the main test process control via a tester interface (e.g., a common or shared tester interface, such as a communication interface (bus)) and is adapted to interface with one or more devices under test. For example, the device communication unit can be coupled to one or more devices under test via one or more DUT interfaces.

[0013] In addition, the device communication unit includes a trigger generator that is configured to generate a trigger signal in response to data received from the device under test (e.g., a protocol-based data stream). For example, data can be received from the device under test via a device under test interface.

[0014] Furthermore, the trigger generator is configured to extract payload data from a protocol-based data stream received from the device under test (e.g., a non-deterministic and / or protocol-aware data stream) and generate a trigger signal in response to the extracted payload data or in response to one or more protocol events.

[0015] The described automated test equipment is based on the insight that by providing protocol-aware trigger generation on the device communication unit, i.e., very close to the device under test, latency can be reduced and bottlenecks can be avoided. Thus, a significant improvement over conventional solutions can be achieved, in which the real-time trigger generation unit may not be close to the device under test interface (or channel), resulting in communication latency during an interactive test process. Therefore, the described embodiments are based on the idea of using a protocol-aware trigger generation unit that is part of the device communication unit and is coupled to the device under test only via the device under test interface. Such a tight coupling of the trigger generation unit to the device under test interface enables the communication latency to be shortened (since it is not necessary to forward the complete data stream via the tester interface between the main test process control and the device communication unit), and better timing prediction (i.e., time synchronization) is achieved due to the short path and real-time performance (or processing) capabilities.

[0016] The described embodiments take into account the real-time requirements of trigger generation, such as maintaining a minimum latency between the event itself and the reaction of the triggered communication or test execution process. In other words, the (protocol-aware) trigger generation unit is part of the device communication unit (not part of the main test process control, as the main test process control can generate trigger data with high latency due to high data traffic in the main test process control) to minimize communication latency.

[0017] In addition, in some cases, time determinacy is another real-time requirement for trigger generation. For example, time determinacy is achieved by allowing a precise reverse mapping of the periods for trigger generation and trigger communication (or broadcast). For example, a finite state machine considers a predictable number of clock cycles (reverse mapping or reverse calculation) to determine the trigger time. However, by providing protocol-aware trigger generation directly on the device communication unit, timing inaccuracies usually caused by congestion on the tester bus can be avoided.

[0018] Thus, by directly providing on the device communication unit the function of evaluating the protocol-based data stream from the device under test, and providing triggers based on the evaluation of the protocol-based data stream (e.g., based on the payload data extracted from the data stream or based on protocol events (similar to a certain protocol state if the protocol can be considered a state machine, or protocol errors)), a particularly fast reaction to one or more predefined events (e.g., the device under test provides predefined data in the data stream, or a protocol violation in the data stream provided by the device under test) can be achieved while avoiding the latency of the tester interface between the main test process control and the device communication unit.

[0019] In addition, trigger generation on the device communication unit can be dedicated to (e.g., directly, e.g., without any active circuitry in between) testing a single device under test coupled to the device communication unit, which in turn allows for a faster response when compared to the processing (e.g., trigger generation) in a main test process control that is typically responsible for parallel testing of multiple devices under test (such that the processing power has to be shared among multiple devices under test).

[0020] In addition, according to one aspect, due to the inadequacy of simple bit comparison of devices with protocol interfaces, more advanced requirements can be defined for triggers. Further, real-time trigger generation can, for example, process device-specific information (e.g., encryption, ID), handshake protocols, device parameters, sensor readings, package counters, packetization protocols, and non-determinism due to the communication interface. Thus, the communication interface can, for example, send data to the device under test and can, for example, receive data formatted according to a defined protocol from the device under test.

[0021] In a preferred embodiment, the device communication unit is configured to transmit a trigger event to the main test process control (which, for example, organizes (e.g., operates or coordinates) the test process among multiple device communication units) or to another device communication unit via a tester interface (e.g., a communication interface (bus)). Thus, for example, the main test process control can be enabled to adjust the test process in response to the communication of the trigger event, thereby reacting to the trigger event. However, by only transmitting the information describing the detection of the trigger event to the main test process control, the amount of data to be sent to the main test process control and the processing load of the main test process control can be significantly smaller when compared to the case where the complete (protocol-based) DUT data stream would be sent to the main test process control (and where the main test process control evaluates the DUT data stream). Thus, the main test process control can be "focused" on the overall control (and / or coordination) of one or more test processes (e.g., with respect to parallel testing of multiple DUTs), while the (protocol-based) generation of trigger information is performed in a decentralized manner by the device communication units.

[0022] In a preferred embodiment, the tester interface (e.g., a communication interface (bus)) is deterministic with respect to the time required for data transfer. In other words, time determinism (e.g., synchronous transfer) can enable prediction of the number of cycles for each specific duration of data transfer to ensure data delivery without retransmission. Thus, the main test process control can react to the information about the trigger event provided by the device communication unit within a more predictable time period. Thus, the reaction to the trigger event can be time-deterministic even if the trigger generation is in a device communication unit separate from the main test process control.

[0023] In a preferred embodiment, the tester interface is configured to allow bidirectional communication between the main test process control and at least one device communication unit. In other words, the bidirectional tester interface is configured to send (or provide) trigger data (e.g., from the device communication unit) to the main test process control and is configured to receive trigger configuration information, for example, from the main test process control. In addition, the bidirectional tester interface is configured to transfer the trigger configuration information to at least one device communication unit and is configured to receive trigger signals from the device communication unit. Thus, the main test process control can set the trigger conditions evaluated by trigger generation and can receive trigger data (e.g., information or a dedicated message indicating a trigger event detected by trigger generation), such that the main test process control can have control over the trigger process. In addition, the main test process control can adjust the test process in response to the receipt of a trigger signal (or a dedicated trigger message) and can send trigger messages to one or more other device communication units, for example, in response to the receipt of a dedicated trigger message.

[0024] In a preferred embodiment, the trigger generator is configured to extract payload data from a packetized data stream and / or a sequential bit stream on one or more pins. For example, this may mean that a packetized data stream including data and formats of a certain protocol (e.g., IJTAG, JTAG, USB, Ethernet, or SATA, etc.) is read by the trigger generator when extracting payload data from the packetized data stream (i.e., the protocol-based data stream). In addition, the trigger generator reads sequential bit streams on multiple possible parallel pins to extract payload data. Thus, the trigger generator processes the data provided at the pins of the DUT in a very straightforward manner, which allows for a very small time delay and avoids data transmission via the internal interface of the automated test equipment (which may cause delays and constitute a bottleneck).

[0025] In a preferred embodiment, the trigger generator is configured to evaluate one or more protocol-aware (i.e., protocol-based) communications between the device communication unit and the device under test, and generate a trigger signal based on the payload data of the one or more protocol-aware (e.g., protocol-based) communications. For example, the protocol-aware communication may include a response to sensor data (or the sensor data itself), which may contain (or may allow detection of) a heat anomaly in the device under test. When extracting the protocol-aware data stream, the trigger generation unit may generate a trigger signal. Thus, the trigger generator can even evaluate and respond (e.g., by providing a trigger signal) to analog characteristics of the device under test, such as DUT temperature, or DUT supply voltage, or DUT supply current, or any other DUT parameter, which are transmitted by the device under test via a digital protocol-based interface. In other words, the trigger generator can respond to one or more DUT parameter values that are represented in digital form in the protocol-based data stream provided by the DUT. Thus, it may no longer be necessary to evaluate the analog quantities representing the DUT parameters in the device communication unit, which are prone to distortion and are generally difficult to process.

[0026] In a preferred embodiment, the trigger generator is configured to extract payload data from the raw device-under-test communication and generate a trigger signal based on the payload. Thus, the trigger generator can generate a trigger based on the payload data, which may be generated, for example, in a well-defined manner by software running on the DUT or may be generated by a hardware unit of the DUT. By evaluating the payload data of the protocol-based communication for triggering, a mechanism is created that allows the DUT (or the software running on the DUT) to effectively determine (or modify) the test flow. Additionally, by evaluating the payload (e.g., by evaluating the magnitude of the digital values included in the payload), triggering can be performed based on the (multi-bit) digital information represented by the payload.

[0027] In a preferred embodiment, the trigger generator is configured to generate a trigger signal in response to data (e.g., payload data) received from the device under test via a JTAG interface, or via an IJTAG interface, or via a boundary scan interface, or via a USB interface, or via an Ethernet interface, or via a SATA interface, or via a debug interface, or via a high-speed IO interface according to, for example, IEEE 1149.10, or a wireless interface according to, for example, IEEE 802.11, or 3GPP LTE, or 3GPP 5G. Additionally, a low-level interface (e.g., a debug interface) enables a hardware component to directly access the device under test, while a high-bandwidth interface (such as a high-speed IO or Ethernet interface) enables a large amount of program code or data to be transferred to or from the device under test at high speed. Therefore, using different interfaces enables an efficient data exchange architecture to be achieved. Furthermore, it has been found that triggering the data flow of such protocol-based interfaces allows for good control of the test process and can help detect communication errors that may be caused by defects in the DUT.

[0028] In a preferred embodiment, the trigger generator is configured to generate comparison information (e.g., a comparison sequence) and generate a trigger signal based on the comparison information and the extracted payload data (e.g., using the comparison result of the comparison information and the extracted payload data). The extraction of the payload data is, for example, from direct data provided by the device under test. In other words, the extraction of the payload data enables the unpacking of protocol data from the direct data. Additionally, the generation of the comparison information allows for the generation of a trigger at high speed and with low computational effort. The generation of the comparison information can, for example, be performed in advance (e.g., before test execution) or can be performed "in time", e.g., during test execution. For example, after unpacking the payload data from the protocol, a simple data comparison can be used, which can be performed at very high speed with very little hardware effort.

[0029] In a preferred embodiment, the trigger generator is configured to generate comparison information based on trigger configuration information, which can be provided, for example, by a main test process control, and which can be the same, for example, for multiple devices under test, and based on device-under-test specific information, which can be specific to the device under test and includes a device-under-test identifier and / or encryption information. The predetermined trigger configuration information provides, for example, a sensor temperature value of 50° and device-under-test specific information, for example, identifying the nth device under test. Thus, the trigger generator is configured to generate comparison information indicating the nth device under test having a sensor temperature value greater than 50°. Such a concept allows for maintaining a certain amount of data, which amount of data has to be distributed by the main test process control and which is rather small. It is sufficient to distribute common comparison information and a relatively small amount of device-specific (or device-individual) information to different trigger generators, instead of providing a large amount of different (DUT-individual) "complete" comparison information to multiple trigger generators (e.g., of different device communication units). Thus, the amount of data transferred within the automated test equipment can be reduced, which is important for performing simultaneous tests of multiple DUTs.

[0030] In a preferred embodiment, the trigger generator includes a hardware circuit (e.g., a configurable hardware trigger circuit, which can include, for example, a hardwired signal flow), which is configured to compare the comparison information (e.g., a locally computed "comparison sequence") with the extracted payload data. In other words, the hardware circuit (implemented, for example, in a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC)) is configured to compare the expected data with the acquired extracted payload data, where the extraction of the payload data is outside of the direct data provided by the device under test. Using a hardware circuit to generate the trigger allows for a particularly high data rate and helps to maintain a small time delay. In addition, since there is usually a well-predictable delay, good timing behavior can be achieved.

[0031] In a preferred embodiment, the trigger generator is configured to provide a trigger signal including one or more of the following information items:

[0032] · A timestamp describing the time at which the trigger event was detected. The timestamp of the trigger signal indicates the number of clock cycles measured relative to a reference point (e.g., a global reference point).

[0033] · Information about the trigger type. The trigger type takes into account temperature, and / or payload data, and / or protocol events, and / or a trigger ID. The trigger type identifies one of multiple trigger events.

[0034] · Information about the trigger source (e.g., information about which DUT among multiple DUTs caused the trigger event, or whether it was the DUT payload data or a component of the device communication unit that caused the trigger event). In other words, it indicates information about the trigger source that caused the trigger event.

[0035] · Information about the payload data (e.g., in the environment before the trigger event is detected, or in the environment after the trigger event is detected).

[0036] · Information about the trigger target (e.g., information indicating which unit of the automated test equipment should respond to the detection of the trigger event). In other words, this information indicates the target unit of the automated test equipment for trigger generation.

[0037] · Information about the trigger priority (e.g., whether multiple trigger conditions with different priorities are defined). For example, the priority can be defined as high, medium, or low, and the trigger data can be processed one by one according to their trigger priorities.

[0038] · Information about the age (e.g., information about the time between the detection of the trigger event and the issuance of the trigger event signal, e.g., via the tester interface). The information about the trigger age can be specified by the number of clock cycles between the time of trigger event detection (e.g., from the extraction of the payload data unit) and the issuance of the trigger event signal (e.g., from the generation of the trigger signal unit).

[0039] Therefore, the trigger signal is very meaningful and allows for precise analysis of the trigger event.

[0040] In a preferred embodiment, the automated test equipment includes a central trigger signal distributor that is configured to receive a trigger signal from the device communication unit and forward the trigger signal to another device communication unit or another trigger target (e.g., a tester device that performs an action in response to the trigger signal, e.g., changing the voltage or signal parameters of the signal provided to the DUT that caused the trigger event). Additionally, the trigger signal distribution can be done, for example, through communication with the tester interface (i.e., the communication interface (bus) or generally the data interface) and listening to the target DCU on the tester interface. By distributing the trigger signal or trigger information in such a way, coordination between multiple device coordination units can be achieved, which is particularly helpful in the case where multiple device communication units cooperate to test a single DUT. Additionally, additional testers can be time synchronized or adjusted in response to the trigger event, which allows for well-controlled testing in response to different DUT responses.

[0041] In a preferred embodiment, the automated test equipment includes one or more additional device communication units coupled to a tester interface (i.e., a communication interface (bus)), wherein at least one of the one or more additional device communication units (e.g., a target device communication unit) is configured to detect a trigger signal on the tester interface provided by a source device communication unit and react to the detection of the trigger signal on the tester interface. Thus, the operation of multiple device communication units (especially the reaction to trigger events) can be synchronized in an efficient manner, wherein the synchronization can be performed without involving the main test process control. Therefore, low latency can be achieved, and the load on the main test process control can be kept low.

[0042] In a preferred embodiment, the automated test equipment includes one or more additional device communication units coupled to a tester interface (i.e., a communication interface (bus)), wherein at least one of the one or more additional device communication units (e.g., a target device communication unit) is configured to receive a dedicated trigger signal from a source device communication unit (e.g., using a loopback on a load board) and react to the reception of the dedicated trigger signal. In other words, the trigger data can be sent directly to the target device communication unit, for example, without passing through the tester interface. Therefore, the load on the tester interface can be kept very small, and the latency can be reduced to a very low value because dedicated trigger lines can be used for the transmission of dedicated trigger signals.

[0043] In a preferred embodiment, the trigger generator is configured to evaluate the match of payload data (or bit stream) according to a full match trigger condition, and / or according to a trigger condition that partially matches a wildcard, and / or according to a regular expression trigger condition to generate a trigger signal. Specifically, the bit stream can be the extracted payload data, for example, the binary representation of the payload data or protocol event information. During the trigger comparison process, the bit stream can have, for example, a full or partial match trigger condition or a syntax-based condition, such as parsing (e.g., context-based condition). In addition, the trigger comparison process can, for example, include different states, such as the activation state of a trigger that is fired (or used) if the activation condition matches, or the disabled state of a trigger that does not match the activation condition (or is deactivated after a certain time), or the enabled state of a trigger that enables the matching activation condition (the prerequisite of the trigger (e.g., an intermediate state, waiting for an event to switch to the activation state)). Thus, a flexible trigger concept is provided. For example, it is possible to have multi-step triggers (e.g., with an intermediate "activation state" that can be reached, for example, from the "enabled state"), which allows the implementation of complex trigger conditions. In addition, by using wildcards (e.g., don't cares) and regular expressions (which can be effectively evaluated by the trigger generator), the actual payload of the data stream can be considered when deciding to trigger.

[0044] In a preferred embodiment, the trigger generator is configured to evaluate a match of payload data (or bitstream) according to a cycle-after-reference trigger condition to generate a trigger signal. For example, this may mean that the time synchronization between the device under test and the device communication unit is achieved by using a global synchronization reference (e.g., from one of the global navigation satellite systems such as the Global Positioning System, or from a common synchronization signal) for the activation state of the trigger that is excited if the activation condition matches, or for the deactivation state of the trigger that does not match the activation condition (or is deactivated after a certain time), or for the enabled state of the trigger that enables the matching activation condition (a prerequisite for the trigger (e.g., an intermediate state, waiting for an event to switch to the activation state)). Thus, good timing synchronization can be achieved, for example, between different device communication units or between different testers. In addition, deterministic timing can be achieved, which allows the analysis of trigger events, for example, when performing debugging or fault analysis of a test program.

[0045] In a preferred embodiment, the trigger generator is configured to evaluate a match of payload data (or bitstream) according to a numerical operation comparison trigger condition to generate a trigger signal. Thus, the numerical value of the payload data can be used, for example, to decide the trigger. Thus, the trigger can be performed according to whether the payload data of the DUT data stream indicates a certain numerical value.

[0046] In a preferred embodiment, the trigger generator is configured to evaluate a match of payload data (or bitstream) according to a minimum match number trigger condition or a maximum match number trigger condition to generate a trigger signal. Thus, the trigger can be very flexible.

[0047] An embodiment provides a method for testing one or more devices under test, including generating a trigger signal in response to data received from a device under test (DUT) (e.g., payload data) (e.g., data received from the DUT via a DUT interface). In addition, the generation of the trigger signal includes extracting payload data from a protocol-based data stream received from the device under test (e.g., a non-deterministic and / or protocol-aware data stream), and generating a trigger signal in response to the extracted payload data or in response to one or more protocol events. This method is based on the same considerations as the above-described apparatus.

[0048] However, it should be noted that the methods described herein can optionally be supplemented by any features, functions, and details disclosed herein that are also related to automated test equipment. It should be noted that the method can optionally be supplemented by these features, functions, and details, either individually or in combination. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Embodiments according to the present invention will be described subsequently with reference to the accompanying drawings, in which:

[0050] Figure 1 A schematic block diagram of an automated test device is shown, which is configured to generate a trigger signal in response to data received from a device under test;

[0051] Figure 2 A schematic block diagram of a module of an automated test device is shown, which is configured to generate a trigger signal in response to data received from a device under test;

[0052] Figure 3 A schematic block diagram of an automated test device is shown, which is configured to generate a trigger signal in response to data received from a device under test;

[0053] Figure 4 A schematic block diagram of a trigger generation block is shown, which is configured to generate a trigger signal in response to data received from a device under test. Detailed implementation manners

[0054] 1. According to Figure 1 Automated test equipment

[0055] Figure 1 A schematic block diagram of an automated test device 100 according to an embodiment of the present invention is shown.

[0056] The automated test device 100 includes a main test process control 110, wherein the main test process control is configured to operate (e.g., coordinate) the test processes to all stations (i.e., operate or control the entire test process to test a device under test or multiple devices under test simultaneously). The automated test device 100 includes a device communication unit 120, and the device communication unit 120 further includes a trigger generator 122. The trigger generator 122 includes an extraction of payload data 124, wherein the extraction of payload data 124 is configured to provide, for example, the extracted payload data 124a and / or protocol event information 124b, which are based on data (or data stream, or DUT data or DUT data stream) 130c provided by the device under test 130. The trigger generator 122 further includes a generation of a trigger signal 126, wherein the generation of the trigger signal 126 is configured to generate a trigger signal 126a, and can be configured to send (e.g., output or transmit) the trigger signal 126a to the main test process control 110 via a tester interface 112, for example.

[0057] In addition, the automated test device 100 is optionally configured to provide test case data 130a (e.g., appropriate test code uploaded to the device under test) and monitoring data 130b (e.g., a monitoring program for uploading and / or starting and / or interrupting test execution) to the device under test, and receive data 130c (e.g., response data) from the device under test 130.

[0058] Thus, in the automated test equipment 100, the trigger generation unit 122, which is part of the device communication unit 120, is directly coupled to the device under test, for example, only through the device under test interface ( Figure 1 not explicitly shown in the figure). The tight coupling of the trigger generation unit 122 with the DUT interface generally provides better timing prediction because the path is shorter and the delay is less, thus providing continuous real-time performance (or processing) capabilities.

[0059] In summary, the automated test equipment 100 allows for distributed and protocol-aware trigger generation, where it is not necessary to forward the complete DUT data to the main test process control. Instead, trigger generation occurs in the "distributed" trigger generation unit 122, which is part of the device communication unit. For example, the trigger generation unit can receive DUT data "in its original form" (e.g., without intermediate transmission through an internal interface of the automated test equipment such as the tester interface), and can evaluate the DUT data 130 considering the communication protocol based on the DUT data. Therefore, the trigger generator 126 can generate a trigger signal 126a based on the payload extracted from the (protocol-based) DUT data and / or based on (or in response to) the detection of one or more protocol events. Thus, a fine evaluation function capable of evaluating the communication protocol based on the DUT data 130c is provided in a distributed manner in the device communication unit, which allows for fast (e.g., real-time) trigger generation while keeping the data volume transmitted through the tester interface 122 and the processing load of the main test process control low.

[0060] In addition, it should be noted that the automated test equipment 100 can optionally be supplemented by any of the features, functions, and details disclosed herein, either individually or in combination.

[0061] 2. According to Figure 2 reference example

[0062] Figure 2 A schematic block diagram of a module 200 of an automated test equipment according to an embodiment of the present invention is shown.

[0063] The module (e.g., part) of the automated test equipment 200 includes a finite state machine (FSM) 210, where the finite state machine 210 can be, for example, the main control block, i.e., controlling the functions of the architecture of the module of the automated test equipment 200. In this regard, it should be noted that compared with the generation of the trigger signal 126 of the automated test equipment 100, the finite state machine 210 can have a wider range of functions.

[0064] In addition, the finite state machine 210 can be implemented, for example, in hardware (e.g., using FPGA or ASIC) or in software (e.g., using a CPU).

[0065] The module 200 of the automated test equipment further includes a tester IF (interface) 220, wherein the tester IF 220 is configured to receive a trigger signal 212. In addition, the module 200 of the automated test equipment includes a random access memory (e.g., dynamic random access memory (e.g., DRAM) 230 or static random access memory), and the random access memory further includes, for example, a monitor 232 and a test case 234. The monitor 232 can be, for example, a monitor program that can be provided (e.g., under the control of the finite state machine 210) to the device under test 250 via a debug interface (e.g., a low-level interface or a hardware interface) (e.g., JTAG). For example, when executed by the processor or CPU of the DUT 250, the monitor 232 is used to control the test execution on the DUT 250 side. For example, the monitor can control the upload of the test case to the DUT and / or the execution of the test case on the DUT. In other words, the monitor can support, for example, sending the test case 234 to the device under test 250 via the high-speed IO interface 216. In other words, the monitor program is used to upload and / or start and / or interrupt the test execution. Similarly, the monitor 232 can, for example, be able to evaluate (or pre-evaluate) the result of the test execution on the DUT.

[0066] In addition, the test case can be used to upload an appropriate test program or appropriate test data to the device under test 250. For example, the test case can include the definition of a test program and / or test data. In addition, the test case 234 can optionally include configuration information for receiving payload data (e.g., response data) from the device under test 250 and for forwarding the response data to the finite state machine 210.

[0067] It should be noted that the test case 234 can be configured to provide a test case program, where the test case program can include, for example, test data or a test program to be processed or executed on the device under test 250, and program code to be executed by the automated test equipment or the finite state machine 210 of the automated test equipment.

[0068] Optionally, module 200 of the automated test equipment further includes a computing unit 240, which provides a config or configuration 242 (e.g., trigger configuration information) to the finite state machine (FSM) 210. In other words, the computing unit 240 can be the engine that configures the FSM 210. The computing unit can provide configuration information, for example, based on data provided by the main test process control, and the configuration information can define a trigger function, and the main test process control can be temporarily stored in the random access memory or DRAM 230, for example. Module 200 of the automated test equipment can communicate with the device under test 250 (i.e., an external device) through, for example, a high-speed IO interface 216 (e.g., in addition to communication via test interfaces such as JTAG, iJTAG, etc.).

[0069] In addition, the finite state machine 210 can switch from one state to another, for example, to control the test of the DUT. In some cases, the state transition can occur in response to payload data 218 (or USB payload data or JTAG payload data or IJTAG payload data, etc.). For example, the state can change between:

[0070] 0) Payload to control (where, for example, data can be provided from the main test process control to the module or device communication unit 200)

[0071] 1) Load monitoring (e.g., the monitor program 232 can be uploaded from the random access memory or DRAM 230 to the DUT 250)

[0072] 2) Load test case (where, for example, the test case 234 can be uploaded from the random access memory or DRAM 230 to the DUT 250)

[0073] 3) Execute the test case (where, for example, the test case 234 can be executed, for example, under the control of or initiated by the monitor program)

[0074] Hereinafter, the state flow transition of the finite state machine 210 will be described in more detail in combination with the application scenario.

[0075] One or more sensors 252 (e.g., on-chip sensors) on the device under test 250 may be configured to capture an impending anomaly of the on-chip structure, for example, by measuring the average temperature. In one application scenario, a finite state machine (FSM) 210 may initially control the transfer of payloads (e.g., from the main test flow control to module 200) in state 0, for example. In state 1, a monitor program may be uploaded to the DUT, in state 2, test case data may be uploaded to the DUT, and testing may be performed in state 3, for example, until the on-chip sensor data reaches a predetermined temperature value. When a trigger condition is met (e.g., at a certain trigger event) (e.g., when the temperature value measured by sensor 252 and encoded in the protocol-based DUT data stream reaches a predetermined value) (e.g., when the sensor data represented by the sensor data stream received (or acquired) from the device under test 250 through the high-speed IO interface 216 matches the trigger condition defined by the trigger configuration information 242), the FSM 210 may trigger a sequence (or state transition).

[0076] Module 200 of the automated test equipment further includes a high-speed IO interface 216 (e.g., Universal Serial Bus (USB), Internal JTAG (IJTAG), Ethernet, Serial Advanced Technology Attachment (SATA), etc.) that enables faster on-chip testing than typical dedicated interfaces (e.g., dedicated test interfaces). The high-speed IO interface 216 may be used, for example, to send (i.e., output or transfer) test case data to the device under test 250, or to receive payload data 218 (e.g., USB payload data or JTAG payload data or IJTAG payload data) embedded in the DUT data stream according to the protocol from the DUT and provide the payload data to the FSM 210, or to receive data from the random access memory or DRAM 230 and forward it to the DUT 250 according to the (communication) protocol.

[0077] In one example, the high-speed IO interface may use the SATA protocol or any other protocol that may include, for example, device-specific information (e.g., encryption, ID) and / or handshake protocol and / or encapsulation counter and / or packetization protocol, etc. Thus, the high-speed IO interface 216 may send data formatted according to the SATA protocol or according to any other protocol to the device under test 250. By using such protocols, device-specific information (e.g., encryption, ID) and non-determinism caused by the communication interface can be processed.

[0078] In addition, a random access memory (e.g., dynamic random access memory (DRAM) 230) may communicate with a processor (e.g., central processing unit (CPU)) through a processor interface (PIF), for example.

[0079] The module 200 of the automated test equipment further includes a tester interface (IF) 220, which is coupled to, for example, a finite state machine (FSM) 210 and a main test process control 110. The tester interface 220 is configured, for example, to enable fast communication (such as sending data or receiving data) with low latency. Additionally, considering the number of cycles required for each data transfer, the tester interface 220 is preferably but not necessarily time-deterministic. In other words, in some embodiments, retransmission is guaranteed not to occur and / or data delivery within a fixed time period is ensured.

[0080] In summary, the module 200 can, for example, allow testing of a DUT, which can be, for example, a system-on-chip. The high-speed IO can, for example, transfer test case data to the DUT 250 using protocol-based data streams and can receive protocol-based data streams from the DUT 250. The high-speed IO 216 can, for example, take over the function of extracting the payload data 124 and can optionally be capable of signaling one or more protocol events (such as the start or end of data transfer or data packet, protocol error, predefined protocol status, etc.). Thus, the FSM or Figure 2 a dedicated trigger generation not shown in the figure can, for example, generate a trigger signal in response to the extracted payload and / or in response to one or more protocol events. The trigger signal can be used, for example, by the finite state machine 210 to control the execution of the test (such as to trigger a state transition), and / or can be forwarded to the main test process control and / or another device communication unit and / or another test instrument.

[0081] Furthermore, it should be noted that the module 200 of the automated test equipment can optionally be supplemented by any of the features, functions, and details disclosed herein, either individually or in combination.

[0082] 3. According to Figure 3 the example of

[0083] Figure 3 A schematic block diagram of an automated test equipment 300 according to another embodiment of the present invention is shown.

[0084] The automated test equipment 300 includes a main test process control 310 (which may correspond to, for example, the main test process control 110), where the main test process control 310 is configured to operate (coordinate) the test flow to all sites (or at least multiple sites). The automated test equipment 300 also includes at least one device communication unit (DCU) 320a to 320n (which may correspond to, for example, the device communication unit 120), and the device communication unit includes a trigger generator 322 (which may correspond to, for example, the trigger generator 122) and at least one device under test interface 324a to 324n. For example, the automated test equipment 300 can parallelly test multiple devices under test 330a to 330n by providing test case data (i.e., test data) to the devices under test 330a to 330n and by receiving response data (i.e., test responses) from each of the multiple devices under test 330a to 330n. For example, the device communication unit may include one or more DUT interfaces 324a to 324n to establish connections with one or more interfaces 334a to 334n of the device under test 330a. However, alternatively, different DUT interfaces 324a to 324n may also be coupled to different devices under test, such that a single device communication unit 320a can simultaneously test multiple devices under test. Alternatively, multiple device communication units may be used to test a single device under test.

[0085] The trigger generation unit 322 is configured to communicate with the main test process control 310 via a tester interface 312 (e.g., a communication interface (bus) for the device communication unit to communicate with the main test process control) (e.g., sending trigger data to the main test process control 310 or receiving control data from the main test process control 310), where the tester interface 312 is, for example, configured to establish two-way communication between the main test process control 310 and at least one DCU 320a to 320n. In addition, the tester interface 312 is, for example, configured to enable fast communication with low latency. The tester interface 312 may be, for example, time-deterministic in terms of the number of cycles required for data transmission. In other words, it can be guaranteed that there is no retransmission of data delivery, or data delivery within a predetermined time (i.e., due to reliable transmission, retransmission of the same data is not necessary).

[0086] In addition, the trigger generator 322 can be, for example, (or include) configurable logic that responds to data inputs from the device under test 330a. In other words, the trigger generator 322 is configured to receive (or read) incoming data (e.g., data, or response data, or payload data, or test result data, or sensor data) from the device under test (i.e., an external device). The incoming data from the device under test can be, for example, a sequential bit stream or packetized data (e.g., protocol data or packetized protocol) on a plurality of possible parallel pins. The trigger generator 322 can be configured to generate a trigger signal and send the trigger signal to the tester interface 312. In addition, the trigger generator 322 can generate multiple triggers. However, the trigger generator can alternatively or additionally be configured to provide a trigger signal to another sub-unit of the device communication unit.

[0087] In the following, implementation variants of the trigger generator 322 (e.g., software and configurable hardware) will be explained.

[0088] Software trigger generation can run, for example, on a central processing unit (CPU). For example, a CPU-based method is used to compare the incoming data stream and generate a trigger via software instructions. By using such a method, local triggers can be generated on the DCU. If appropriate software concepts are applied, the method can be time-deterministic, for example, if the method is implemented without using, for example, caches. However, compared to a hardware solution, this method may be slower, and the hardware solution can be used as another alternative.

[0089] In addition, it should be noted that the automated test device 300 can optionally be supplemented by any of the features, functions, and details disclosed herein, either individually or in combination.

[0090] 4. According to Figure 4 Example of

[0091] Figure 4 A schematic block diagram of a trigger generation block 400 is shown, which is used to generate a trigger signal 426 in response to data received from the device under test. For example, Figure 4 the shown trigger generation block 400 can be part of the device communication unit disclosed herein.

[0092] The trigger generation block 400 includes a trigger generator 420. The trigger generator 420 can correspond, for example, to the trigger generator 122 or 322.

[0093] The trigger generator 420 includes a unit 422 (also denoted as "A") and a hardware (HW) comparison (e.g., FPGA, ASIC) unit 424. The unit 422 can adapt the hardware comparison unit 424 according to the trigger configuration information, for example. The hardware comparison unit 424 is configured to provide (i.e., generate) a trigger signal 426 to the main test process controls 110, 310.

[0094] In a configurable hardware trigger generation method, the local computing unit 410 can generate pre-computed information or signals 412a (e.g., comparison sequences) using a combination of trigger configuration (or trigger configuration information) 412 and DUT-specific information 414. The trigger generator 420 can receive the pre-computed information or signals 412a from the local computing unit 410 via the DUT interface 430, and receive payload data 430a from the device under test. Optionally, at least one protocol event information can be provided by the DUT interface 430 together with the payload data 430a.

[0095] For example, the DUT interface 430 can include a protocol wrapper 432 configured to extract the payload data 430a from the DUT communication. Thus, the payload wrapper can be configured to use device-specific data (such as decryption keys, etc.) to extract the "plain text" payload representation from the DUT communication 440, which can be received from the DUT via, for example, the device communication unit or the DUT interface of the automated test equipment. In addition, the protocol mapper can optionally provide (or signal) information (or signals) describing (or signaling) one or more protocol events (e.g., one or more predefined protocol states, such as the start or end of a frame, or one or more protocol errors (such as framing errors, or parity errors, or packet loss, etc.)) to the trigger generator 420.

[0096] Therefore, the trigger generator can perform a comparison, for example, between the extracted payload data 430a provided by the protocol wrapper 432 of the DUT interface 430 and the pre-computed comparison sequence 412a provided by the local computing unit, where the trigger generator can consider "wildcards" or "don't cares", and can, for example, only consider a part of the extracted payload for trigger generation. If the comparison meets a predetermined condition, the trigger signal can be activated or provided. The trigger configuration information 412 can determine, for example, which part of the extracted payload 430a to consider in the comparison, and which comparison criteria to use to activate (or provide) the trigger signal.

[0097] Alternatively or additionally, when determining the activation of the trigger signal, the trigger generator may consider one or more protocol events that are reported by the protocol wrapper using appropriate signals or information. For example, the trigger signal may be activated or provided in response to a predefined protocol error, or in response to a combination of predefined protocol errors, or in response to another protocol event (e.g., in response to the end of a data frame).

[0098] In summary, the trigger generation block 400 can generate trigger signals in a flexible and configurable manner near the DUT.

[0099] Furthermore, it should be noted that the trigger generation block 400 can optionally be supplemented by any of the features, functions, and details disclosed herein, either individually or in combination.

[0100] 5. Applications

[0101] In one application scenario, the automated test equipment disclosed herein for testing a device under test can particularly control test execution through on-chip sensors of the device under test. During the test process, the test execution can run, for example, until a certain sensor temperature value (e.g., a temperature value of 50°) is reached due to the heating of the DUT circuit (e.g., self-heating on the chip). In other words, the trigger signal is related to test execution and is generated after detecting on-chip self-heating (or other anomalies) in the device under test by using different types of sensors (e.g., temperature sensors).

[0102] Another application scenario may involve controlling the voltage drop of the power supply during the test process by generating other types of trigger signals (e.g., on different device communication units, or in different automated test modules, or in different automated test equipment instruments).

[0103] 6. Conclusions

[0104] Some conclusions will be provided below.

[0105] In the test concept for testing the DUT, the test flow may depend on the generation of trigger signals, which results in variations in the entire test execution. Especially for interactive test flows based on the results from the device under test, the generation of trigger signals is required.

[0106] It should be noted that the embodiments according to the present invention provide better timing prediction with short communication latency (i.e., time synchronization of trigger generation due to the short path between the DUT interface and the trigger generation unit), thus providing better real-time performance (or processing) capabilities and multi-site efficiency compared to conventional concepts.

[0107] Embodiments in accordance with the present invention may not be used as part of, for example, the main test process control because of the large data communication traffic in the main test process control. The main test process control may generate trigger data with communication latency. Instead, according to one aspect of the present invention, the trigger generation unit (or trigger generation block) is part of the device communication unit to minimize communication latency. Specifically, the automated test equipment is based on the insight that the real-time trigger generation unit should be close to the DUT interface (or communication channel) to achieve short communication latency during the interactive test process.

[0108] In summary, the embodiments consider the real-time requirements of trigger generation to maintain a minimum latency between the event itself, the communication of the trigger, or the reaction of the test execution process.

[0109] In summary, embodiments in accordance with the present invention can be used to test a device under test in an efficient manner and are thus superior to other conventional concepts.

[0110] Other aspects and embodiments

[0111] In the following, other aspects and embodiments in accordance with the present invention will be described. These aspects can be used alone or in combination and can optionally be introduced into any of the embodiments disclosed herein alone or in combination.

[0112] According to one aspect, an apparatus for a real-time trigger generation system close to the DUT interface is created in embodiments in accordance with the present invention.

[0113] According to one aspect, embodiments in accordance with the present invention relate to real-time trigger generation close to the channel.

[0114] According to one aspect, the test process may rely on the generation of triggers. For example, one or more triggers may signal a specific event to the test execution process. In addition, one or more triggers may allow the process (or test process) to react to it (e.g., react to the trigger or trigger signal or specific event). For example, an interactive test flow may require the generation of triggers, which depends on the results from the DUT. According to one aspect, a trigger may be equivalent to an interrupt in the processing unit.

[0115] According to one aspect, there may be one or more quality requirements (e.g., with respect to trigger generation or real-time trigger generation):

[0116] · Minimum latency between the event itself and the reaction of the communication / test execution process of the trigger

[0117] · Time determinism allowing cycle-accurate reverse mapping

[0118] ○ Trigger generation

[0119] ○ Trigger communication / broadcast

[0120] ·Flexibility of trigger definition

[0121] ○Simple bit comparison is insufficient for devices with protocol interfaces and higher requirements · Protocol awareness

[0122] ○Need to process device - specific information and non - determinism due to communication interfaces

[0123] ○Handshakes, device parameters, sensor readings, packet counters, packetization protocols, etc.

[0124] According to one aspect of the present invention, one or more or even all of these requirements can be met in embodiments of the present invention.

[0125] Hereinafter, some building blocks used in embodiments according to the present invention will be discussed.

[0126] The main test process control can be coupled to a device communication unit (DCU), where the device communication unit is a local processing unit connected to the DUT.

[0127] The main test process control can be the main execution unit that coordinates the test process for all sites.

[0128] In addition, there can be a tester interface, which can be a communication interface (bus) for the device communication unit to communicate with the main test process (or the main test process control). For example, the tester interface can be coupled between the main test process control and the device communication unit.

[0129] In addition, there can be a trigger generation, which is configurable logic that reacts to data (or data stream) input from the DUT to generate a trigger signal and transmit it to the tester interface. Optionally, multiple triggers can be generated. For example, the trigger generation can be part of the device communication unit.

[0130] In addition, there is a DUT interface that enables communication between the device communication unit and the DUT.

[0131] In addition, the device under test is sometimes denoted as DUT or dut.

[0132] For example, in Figure 3 an example of the arrangement and interaction of the building blocks is shown.

[0133] Hereinafter, some (optional) details, aspects, and some requirements of the general underlying architecture will be described.

[0134] The tester interface is preferably designed to allow fast communication with low latency. Additionally, the tester interface is preferably deterministic in terms of the number of cycles and / or time required for data transfer. Preferably, the tester interface allows guaranteed data delivery without retransmission. Additionally, preferably, the tester interface allows two-way communication between 1..N DCSs and the main test process control.

[0135] Trigger generation can, for example, read incoming data from a device, such as

[0136] - sequential bitstreams on multiple possible parallel pins;

[0137] - packetized data.

[0138] In other words, for example, the input data from a device can be in the form of a packetized sequential bitstream on one pin or in parallel on multiple pins.

[0139] There are different possible implementation variants for trigger generation:

[0140] Software trigger generation can be used (e.g., on a CPU). For example, a CPU-based method can compare the incoming data stream and generate a trigger (or trigger signal) via software instructions. For example, a CPU-based method can be implemented locally in the DCU. In some cases, a CPU-based method is deterministic only when no caching is used. In some cases, a CPU-based method is slower than a hardware solution.

[0141] Alternatively or additionally, trigger generation can be implemented using (or as) a configurable hardware trigger. For example, a configurable hardware trigger can include the local generation of comparison sequences, such as using a combination of configuration and DUT-specific information. For example, a configurable hardware trigger can use a sequence (e.g., a comparison sequence) for local comparison with the payload (or extracted payload) from the DUT. According to one aspect, a configurable hardware trigger can include (or perform) extracting the payload from the direct data from the DUT. According to one aspect, a configurable hardware trigger can unpack protocol data. According to one aspect, a configurable hardware trigger can transmit the trigger to, for example, the main tester interface. According to another aspect, a configurable hardware trigger can transmit the trigger to (e.g., locally transfer to) one or more different device communication units (DCUs), which can be connected to the same device (or the same DUT), for example.

[0142] Figure 4 An example of trigger generation (or the trigger generation block) is shown.

[0143] In the following, some optional aspects and details regarding the trigger (or trigger signal) will be provided. According to one aspect, the trigger (or trigger signal) consists of (or includes) one or more of the following:

[0144] · Timestamp (e.g., clock cycles from a reference point)

[0145] · Trigger type

[0146] · Trigger source

[0147] ○ DUT, DCU

[0148] · Payload data

[0149] · Trigger target

[0150] · Priority

[0151] · Age

[0152] In the following, some optional aspects and details regarding trigger allocation will be provided. For example, a central allocator can be used to perform trigger allocation, e.g., from the DCU to the central (or central allocator), and from the central (or central allocator) to the DCU. As another example, bus communication and listening for the target DCU on the bus can be used to perform trigger allocation. According to another example, there can be direct trigger communication to the target DCU, e.g., using a loopback on a load board for example.

[0153] In the following, some optional aspects and details regarding trigger comparison will be described.

[0154] For example, there can be one, two, or more of the following states:

[0155] · Active: Fired when the activation condition is met

[0156] · Disabled: Activation condition not met

[0157] · Enabled: Enabled to match the activation condition

[0158] For example, when the first condition is met or when the trigger mechanism is enabled through the control of the DCU, there can be a transition from the disabled state to the enabled state, and when the second condition is met, there can be a transition from the enabled state to the active state, and when the activation condition is met, the trigger signal can be provided (or activated). However, different functions are also possible.

[0159] In addition, for example, one or more of the following condition types can be used:

[0160] - Matching of bitstreams (e.g., matching of the extracted payload with a pre-computed reference stream)

[0161] ·Exact match

[0162] ·Partial match using wildcards

[0163] ·Regular expression

[0164] -Reference post-cycle condition

[0165] ·Global synchronization reference, activation, deactivation, enabling

[0166] -Numeric operation comparison

[0167] -Minimum / maximum number of matches

[0168] -React to direct commands (e.g., from DUT, from tester interface)

[0169] In the following, some optional aspects and details regarding the DUT interface will be described. According to one aspect, the DUT interface allows protocol-aware communication between the DCU and the DUT. According to one aspect, the DUT interface can unpack the payload from the original device communication.

[0170] According to one aspect, one or more of the following communication interfaces (or communication interface types) can be used (e.g., as the DUT interface, or as multiple DUT interfaces):

[0171] -JTAG (IEEE 1149.x)

[0172] -IJTAG (IEEE 1687.x)

[0173] -Boundary scan (IEEE 1500)

[0174] -High-speed IO test access

[0175] -IEEE 1149.10

[0176] ·"Over USB" or utilizing one or more USB functions

[0177] ·"Over Ethernet" or utilizing one or more Ethernet functions

[0178] ·"Over SATA" or utilizing one or more SATA functions

[0179] -Ethernet

[0180] -USB

[0181] -SATA

[0182] -Debug interface, e.g., TAP

[0183] Note that IEEE 1149.10 is a standard for general high-speed test access to the DUT, which utilizes parts of existing HSIO interfaces (such as USB, Ethernet, SATA) (such as PHY, (de)serializers, bit and word alignment units). It does not use an existing controller as a whole.

[0184] Some possible applications will be described below.

[0185] According to one aspect, embodiments according to the present invention can be used to implement a test process for on-chip sensor control.

[0186] According to one aspect, reading of on-chip sensor information can be performed. For example, test execution can be performed until the on-chip sensor emits a signal of 50 degrees. As another example, control of the voltage drop of a power supply (such as on different DCUs) can be performed.

[0187] Hereinafter, possible improvements of embodiments according to the present invention over the prior art will be discussed.

[0188] According to one aspect, delays (such as trigger delays) due to data transmission (such as to a central execution unit) and due to the centralized generation of triggers (such as because distributed trigger generation is used in the embodiments) can be avoided.

[0189] Furthermore, when using embodiments according to the present invention, a large traffic on the central data bus (such as the tester interface) is avoided.

[0190] Furthermore, by using embodiments according to the present invention, cycle accuracy can be maintained.

[0191] Furthermore, embodiments according to the present invention exhibit good real-time performance and good multi-site efficiency.

[0192] Furthermore, embodiments according to the present invention have good multi-site possibilities.

[0193] Furthermore, by using embodiments according to the present invention, tester resources such as power supplies can be effectively controlled.

[0194] Embodiments according to the present invention can handle non-deterministic interfaces and are suitable for protocol awareness (or protocol-aware communication).

[0195] Embodiments according to the present invention allow content-aware implementation.

[0196] Embodiments according to the present invention can take into account (or consider) device-specific information.

[0197] Embodiments according to the present invention can allow simple matching of bit sequences.

[0198] Thus, embodiments according to the present invention can offer a number of advantages over conventional methods.

[0199] Implement alternative solutions

[0200] Although some aspects have been described in the context of an apparatus, it is clear that these aspects also represent a description of the corresponding method, where a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of method steps also represent a description of the corresponding block or item or feature of the corresponding apparatus. Part or all of the method steps can be performed by (or using) a hardware device, such as a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of the most important method steps can be performed by such a device.

[0201] According to certain implementation requirements, embodiments of the present invention can be implemented in hardware or software. The implementation can be carried out using a digital storage medium (such as a floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM, or flash memory) having electronically readable control signals stored thereon, which collaborates (or is capable of collaborating) with a programmable computer system to perform the corresponding method. Thus, the digital storage medium can be computer-readable.

[0202] Some embodiments according to the present invention include a data carrier having electronically readable control signals, which is capable of collaborating with a programmable computer system to perform one of the methods described herein.

[0203] Generally, embodiments of the present invention can be implemented as a computer program product having program code that, when the computer program product runs on a computer, is operable to perform one of the methods described above. The program code can be stored, for example, on a machine-readable carrier.

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

[0205] In other words, thus, an embodiment of the method according to the present invention is a computer program having program code that, when the computer program runs on a computer, is used to perform one of the methods described herein.

[0206] Therefore, another embodiment of the method according to the present invention is a data carrier (or digital storage medium, or computer-readable medium) that includes a computer program recorded thereon for performing one of the methods described herein. The data carrier, digital storage medium, or recording medium is generally tangible and / or non-transitory.

[0207] Accordingly, another embodiment of the method of the present invention is a data stream or signal sequence representing a computer program for performing one of the methods described herein. The data stream or signal sequence can be configured, for example, to be transmitted via a data communication connection (such as via the Internet).

[0208] Another embodiment includes a processing device, such as a computer or a programmable logic device, which is configured or adapted to perform one of the methods described herein.

[0209] Another embodiment includes a computer on which a computer program for performing one of the methods described herein is installed.

[0210] Another embodiment according to the present invention includes an apparatus or system configured to transmit (e.g., electronically or optically transmit) a computer program for performing one of the methods described herein to a receiver. For example, the receiver can be a computer, a mobile device, a memory device, etc. The apparatus or system can include, for example, a file server for transmitting the computer program to the receiver.

[0211] In some embodiments, a programmable logic device (such as a field programmable gate array) can be used to perform some or all of the functions of the methods described herein. In some embodiments, a field programmable gate array can cooperate with a microprocessor to perform one of the methods described herein. Generally, these methods are preferably performed by any hardware device.

[0212] The apparatus described herein can be implemented using a hardware device, or using a computer, or using a combination of a hardware device and a computer.

[0213] The apparatus described herein or any component of the apparatus described herein can be implemented at least in part using hardware and / or software.

[0214] The methods described herein can be performed using a hardware device, or using a computer, or using a combination of a hardware device and a computer.

[0215] The methods described herein or any component of the apparatus described herein can be performed at least in part by hardware and / or software.

[0216] The above embodiments are merely illustrative of the principles of the present invention. It should be understood that modifications and variations to the arrangements and details described herein will be apparent to other technicians in the art. Therefore, this document is intended to be limited only by the scope of the appended patent claims, and not by the specific details presented by the description and explanation of the embodiments herein.

Claims

1. An automated test device (100; 200) for testing one or more devices under test (130; 250; 330a to 330n), the automated test device (100; 200) comprising: A main test process control (110; 310); A device communication unit (120; 320a to 320n) coupled to the main test process control (110; 310) via a tester interface (112; 220; 312) and adapted to interface with one or more devices under test (130; 250; 330a to 330n); Wherein the device communication unit (120; 320a to 320n) includes a trigger generator (122; 322; 420) configured to generate a trigger signal in response to data received from a device under test (130; 250; 330a to 330n); Wherein the trigger generator (122; 322; 420) is configured to extract payload data from a protocol-based data stream received from the device under test (130; 250; 330a to 330n), generate the trigger signal in response to the extracted payload data or in response to one or more protocol events, and send the trigger signal to the main test process control (110; 310) via the tester interface (112; 220; 312); The main test process control (110; 310) is configured to adjust the test process based on the trigger signal received from the trigger generator (122; 322; 420).

2. The automated test device (100; 200) according to claim 1, Among them, The device communication unit (120; 320a to 320n) is configured to transmit trigger events to the main test process control (110; 310) or another device communication unit (120; 320a to 320n) via the tester interface (112; 220; 312).

3. The automated test device (100; 200) according to claim 1 or 2, Among them, The tester interface (112; 220; 312) is deterministic in terms of the time required for data transmission.

4. The automated test device (100; 200) according to claim 1, Among them, The tester interface (112; 220; 312) is configured to allow bidirectional communication between the main test process control (110; 310) and the device communication unit (120; 320a to 320n).

5. The automated test device (100; 200) according to claim 1, Among them, The trigger generator (122; 322; 420) is configured to extract the payload data from a packetized data stream and / or a sequential bit stream on one or more pins.

6. The automated test device (100; 200) according to claim 1, Among them, The trigger generator (122; 322; 420) is configured to evaluate one or more protocol-aware communications between the device communication unit (120; 320a to 320n) and the device under test (130; 250; 330a to 330n), and generate the trigger signal based on the payload data of the one or more protocol-aware communications.

7. The automated test device (100; 200) according to claim 1, Among them, The trigger generator (122; 322; 420) is configured to extract payload data from the raw device-under-test communication, and generate the trigger signal based on the payload.

8. The automated test device (100; 200) according to claim 1, Among them, The trigger generator (122; 322; 420) is configured to generate the trigger signal in response to data received from the device under test (130; 250; 330a to 330n) via a JTAG interface, or via an IJTAG interface, or via a boundary scan interface, or via a USB interface, or via an Ethernet interface, or via a SATA interface, or via a debug interface, or via a high-speed IO interface such as IEEE 1149.10, or via a wireless interface such as IEEE 802.11 or 3GPP LTE or 3GPP 5G.

9. The automated test device (100; 200) according to claim 1, Among them, The trigger generator (122; 322; 420) is configured to generate comparison information such as a comparison sequence and generate the trigger signal based on the comparison information and the extracted payload data.

10. The automated test device (100; 200) according to claim 9, Among them, The trigger generator (122; 322; 420) is configured to generate the comparison information based on trigger configuration information and based on DUT-specific information.

11. The automated test device (100; 200) according to claim 9, Among them, The trigger generator (122; 322; 420) includes a hardware circuit configured to compare the comparison information with the extracted payload data.

12. The automated test device (100; 200) according to claim 1, Among them, The trigger generator (122; 322; 420) is configured to provide a trigger signal including one or more of the following information items: A timestamp describing the time when a trigger event is detected, Information about the trigger type, Information about the trigger source, Information about the payload data, Information about the trigger target, Information about the trigger priority, Information about the age.

13. The automated test device (100; 200) according to claim 1, Among them, The automated test device includes a central trigger signal distributor configured to receive a trigger signal from the device communication unit (120; 320a to 320n) and forward the trigger signal to another device communication unit (120; 320a to 320n) or another trigger target.

14. The automated test equipment (100; 200) according to claim 1, Among them, wherein the automated test equipment includes one or more additional device communication units (120; 320a to 320n) coupled to the tester interface (112; 220; 312), and at least one of the one or more additional device communication units (120; 320a to 320n) is configured to detect a trigger signal provided by a source device communication unit (120; 320a to 320n) on the tester interface (112; 220; 312) and respond to the detection of the trigger signal on the tester interface (112; 220; 312).

15. The automated test equipment (100; 200) according to claim 1, Among them, wherein the automated test equipment includes one or more additional device communication units (120; 320a to 320n) coupled to the tester interface (112; 220; 312), and at least one of the one or more additional device communication units (120; 320a to 320n) is configured to receive a dedicated trigger signal from a source device communication unit (120; 320a to 320n) and respond to the receipt of the dedicated trigger signal.

16. The automated test equipment (100; 200) according to claim 1, Among them, wherein the trigger generator (122; 322; 420) is configured to evaluate a match of payload data according to an exact match trigger condition, and / or according to a trigger condition that partially matches a wildcard, and / or according to a regular expression trigger condition to generate the trigger signal.

17. The automated test equipment (100; 200) according to claim 1, Among them, wherein the trigger generator (122; 322; 420) is configured to evaluate a match of payload data according to a reference post-cycle trigger condition to generate the trigger signal.

18. The automated test equipment (100; 200) according to claim 1, Among them, wherein the trigger generator (122; 322; 420) is configured to evaluate a match of payload data according to a numerical operation comparison trigger condition to generate the trigger signal.

19. The automated test equipment (100; 200) according to claim 1, Among them, wherein the trigger generator (122; 322; 420) is configured to evaluate a match of payload data according to a minimum match number trigger condition or according to a maximum match number trigger condition to generate the trigger signal.

20. A method for testing one or more devices under test (130; 250; 330a to 330n), the method comprising: Among them, generating a trigger signal in response to data received from the device under test (130; 250; 330a to 330n); Wherein, the generation of the trigger signal includes extracting payload data from the protocol-based data stream received from the device under test (130; 250; 330a to 330n), and generating the trigger signal in response to the extracted payload data or in response to one or more protocol events. Wherein, the method further includes sending the trigger signal to the main test process control (110; 310) and adjusting the test process based on the trigger signal.

21. The method according to claim 20, Among them, The method is executed in a device including the main test process control (110; 310) and the device communication unit (120; 320a to 320n). Wherein, the device communication unit (120; 320a to 320n) is coupled to the main test process control (110; 310), and wherein, the device communication unit (120; 320a to 320n) interfaces with one or more devices under test (130; 250; 330a to 330n). Wherein, the generation of the trigger signal is executed in the device communication unit (120; 320a to 320n).

22. A computer-readable storage medium storing a computer program, which is used to execute the method according to claim 20 or 21 when running on a computer.

Images