Automatic test equipment and method using trigger generation - Patents.com

Abstract

The automatic test equipment includes a main test flow control unit configured to operate test flows in a plurality of device communication units and / or provide trigger configuration information to a local computing unit. The automatic test equipment further includes a device communication unit including 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 a 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 automatic test equipment are also disclosed.

Description

[Technical field]

[0001] SUMMARY OF THE PRESENT EMBODIMENTS FIELD OF THE PRESENT DISCLOSURE The present invention relates to automatic test equipment.

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

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

[0004] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments in accordance with the present invention relate to automatic test equipment and methods for a real-time trigger generation system close to the DUT interface. [Background technology]

[0005] For example, the increasing complexity of electronic device structures, including microprocessors, sensors, digital signal processors, etc., leads to the development of advanced techniques for testing electronic devices. For example, automatic test equipment is typically used to test the device under test.

[0006] In automatic test equipment, a test flow relies on the generation of trigger signals that result in a change in the test execution. In a trigger structure, a specified event is usually signaled in the test execution flow, allowing the flow to react to the event, i.e. the trigger signal is generated based on an event signal applied to a trigger generation unit. The generation of trigger signals is especially required for interactive test flows that depend on results from the device under test, corresponding for example to an interrupt in a processing unit.

[0007] In the conventional structure, in one aspect, the approach of transmitting data from the device under test to a central execution unit and generating triggers centrally has been found to typically cause unacceptable (i.e., high) transmission delays. A central data bus (i.e., a central data interface or a central communication interface) can provide, for example, a standardized transmission capacity, with which a large amount of data has been found to cause high traffic and slow data exchange on the central data bus. Thus, it has been found that it becomes difficult or impossible to maintain the accuracy of signals (e.g., clocks), thereby limiting real-time performance and limiting multi-site efficiency.

[0008] In another aspect, a direct PC-based DUT connection approach is commonly used. However, such direct PC use has been found to limit multi-site possibilities. Furthermore, it has been found that direct PC-based device under test connection techniques cannot efficiently control tester resources, such as power supplies. This makes it difficult or impossible to maintain signal (e.g., clock) accuracy, thereby limiting real-time performance and multi-site efficiency.

[0009] In a third aspect, a real-time pattern comparison technique performed through a simple match loop (i.e., a simple match of a pattern bit sequence) is usually used in conventional solutions in existing ADV cards. However, it has been found that a real-time pattern bit comparison is not possible for non-deterministic (e.g., asynchronous transmission) interfaces due to the difficulty of bit synchronization, and is not possible for protocol-aware (or protocol-aware communication). Furthermore, content-aware implementation is not possible due to limited device-specific information.

[0010] Techniques have been proposed for receiving test result data from a device under test to generate a trigger, or for generating a trigger directly in the device under test. For example, US Patent Application Publication No. 20180372780(A1) discloses a test and measurement instrument that allows a trigger signal to be output upon receiving a signal from a device under test. US Patent Application Publication No. 20190383873(A1) discloses a test and measurement device that receives input data from a device under test only after a specific condition occurs, along with detecting anomalies through pattern comparison. US Patent Application Publication No. 20090072838(A1) discloses a trigger signal derived from a device under test. US Patent No. 9,164,859 discloses a method for enabling simultaneous testing of devices under test. [Prior art documents] [Patent documents]

[0011] [Patent Document 1] US Patent Application Publication No. 20180372780(A1) [Patent Document 2] US Patent Application Publication No. 20190383873(A1) [Patent Document 3] US Patent Application Publication No. 20090072838(A1) [Patent Document 4] U.S. Pat. No. 9,164,859 Summary of the Invention [Problem to be solved by the invention]

[0012] In view of the above, a test concept is desired that provides an improved compromise between test coverage, timing accuracy, latency and implementation effort. [Means for solving the problem]

[0013] An embodiment according to the present invention provides an automatic test equipment for testing one or more devices under test, the automatic test equipment including a main test flow control section that may be configured, for example, to operate (or coordinate) a test flow in a plurality of device communication units and / or to provide trigger configuration information. The automatic test equipment further includes a device communication unit that is coupled to the main test flow control section via a tester interface (e.g., a common or shared tester interface, e.g., a communication interface (bus)) and adapted to interface with one or more devices under test. The device communication unit may, for example, be coupled to one or more devices under test via one or more DUT interfaces.

[0014] Furthermore, the device communication unit includes a trigger generator configured to generate a trigger signal in response to data (e.g., a protocol-based data stream) received from the device under test, for example, the data may be received from the device under test via a device under test interface.

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

[0016] The described automatic test equipment is based on the insight that by providing a protocol-aware trigger generation unit on the device communication unit, i.e. in close proximity to the device under test, latency can be reduced and bottlenecks can be avoided. Thus, a significant improvement can be achieved over conventional solutions where the real-time trigger generation unit may not be close to the device under test interface (or channel), resulting in communication latency during the interactive test flow. The described embodiment is therefore 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 close coupling of the trigger generation unit to the device under test interface allows for short communication latency (since there is no need to transfer the complete data stream through the tester interface between the main test flow control unit and the device communication unit), better timing prediction (i.e. time synchronization) due to the short path, and real-time performance (or processing) capabilities.

[0017] The embodiment takes into account real-time requirements for trigger generation, such as maintaining minimal latency between the event itself and the communication of the trigger or reaction of the test execution flow, in other words, the (protocol aware) trigger generation unit is part of the device communication unit (and not part of the main test flow control, which may generate trigger data with high latency due to high traffic of data in the main test flow control) in order to minimize communication latency.

[0018] Furthermore, time determinism is in some cases another real-time requirement for trigger generation. Time determinism is achieved, for example, by enabling cycle-accurate back-mapping for trigger generation and trigger communication (or broadcast). For example, a finite state machine considers a predictable number of clock cycles (back-mapping or back-calculation) to determine the time of the trigger. However, by providing a protocol-aware trigger generator directly on the device communication unit, timing inaccuracies that may traditionally be caused by congestion on the tester bus can be avoided.

[0019] Thus, by providing the ability to evaluate the protocol-based data stream from the device under test directly on the device communication unit and provide a trigger based on the evaluation of the protocol-based data stream (e.g. based on payload data extracted from the data stream or based on a protocol event (such as a particular protocol state if the protocol can be considered as a state machine or a protocol error)), a particularly fast reaction to one or more predetermined events (e.g. provision of predetermined data by the device under test in the data stream, or a protocol violation in the data stream provided by the device under test) can be achieved while avoiding latency in the tester interface between the main test flow control section and the device communication unit.

[0020] Furthermore, the trigger generation section on the device communication unit may be dedicated to testing a single device under test coupled to the device communication unit (e.g., directly, e.g., without any active circuitry in between), allowing for faster response times compared to processing (e.g., trigger generation section) in the main test flow control section that is typically responsible for parallel testing of multiple devices under test (where processing power must be shared among multiple devices under test).

[0021] Further, according to one aspect, due to the insufficiency of simple bit comparison for devices with protocol interfaces, more advanced requirements for trigger definitions can be specified. Furthermore, the real-time trigger generator can handle, for example, 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 receive data from the device under test that is, for example, formatted according to a defined protocol.

[0022] In a preferred embodiment, the device communication unit is configured to communicate the trigger event to a main test flow control unit (e.g., coordinating (e.g., operating or coordinating) test flows in multiple device communication units) or to another device communication unit via a tester interface (e.g., a communication interface (bus)). The main test flow control unit can thus adapt the test flow in response to the communication of the trigger event, thereby reacting to the trigger event. However, by communicating only information describing the detection of the trigger event to the main test flow control unit, the amount of data transmitted to the main test flow control unit and the processing load of the main test flow control unit can be significantly smaller compared to when a complete (protocol-based) DUT data stream is sent to the main test flow control unit (and the main test flow control unit evaluates the DUT data stream). Thus, the main test flow control unit can "centralize" the overall control (and / or coordination) of one or more test flows (e.g., for parallel testing of multiple DUTs), while the (protocol-based) generation of the trigger information is performed in a distributed manner by the device communication unit.

[0023] In a preferred embodiment, the tester interface (e.g., a communication interface (bus)) is deterministic with respect to the time required for data transmission. In other words, time determinism (e.g., synchronous transmission) may make it possible to predict the number of cycles per specific duration for data transmission in order to guarantee data delivery without retransmission. Thus, the main test flow control unit can react to information about a trigger event provided by the device communication unit within a sufficiently predictable period of time. Thus, the reaction to a trigger event may be time deterministic even if the trigger generation unit is in a device communication unit separate from the main test flow control unit.

[0024] In a preferred embodiment, the tester interface is configured to enable bidirectional communication between the main test flow control unit and at least one device communication unit. In other words, the bidirectional tester interface is configured to transmit (or provide) trigger data (e.g., from the device communication unit) to the main test flow control unit, e.g., configured to receive trigger configuration information from the main test flow control unit. Furthermore, the bidirectional tester interface is configured to communicate the trigger configuration information to the at least one device communication unit, and configured to receive a trigger signal from the device communication unit. Thus, the main test flow control unit can set trigger conditions to be evaluated by the trigger generation unit and can receive trigger data (e.g., information or dedicated messages indicating detection of a trigger event by the trigger generation unit), so that the main test flow control unit has control over the trigger process. Also, the main test flow control unit can adapt the test flow in response to receiving a trigger signal (or a dedicated trigger message), e.g., can send a trigger message to one or more other device communication units in response to receiving a dedicated trigger message.

[0025] In a preferred embodiment, the trigger generator is configured to extract payload data from a packetized data stream and / or from a sequential bit stream on one or more pins. This may mean, for example, that a packetized data stream containing data and format of a certain protocol (e.g. IJTAG, or JTAG, or USB, or Ethernet, or SATA, etc.) is read by the trigger generator when extracting payload data from the packetized data stream (i.e. protocol-based data stream). Furthermore, to extract the payload data, possibly sequential bit streams on multiple pins are read in parallel by the trigger generator. Thus, the trigger generator processes data provided at the pins of the DUT in a very direct manner, which allows very low latency and avoids data transfer through the internal interface of the automatic test equipment (which may cause delays and constitute a bottleneck).

[0026] 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 payload data of the one or more protocol-aware (e.g., protocol-based) communications. The protocol-aware communications may, for example, include a response of sensor data (or sensor data itself) that may contain (or allow detection of) a heating anomaly in the device under test. Once the protocol-aware data stream is extracted, the trigger generator unit can generate a trigger signal. Thus, the trigger generator can even evaluate and respond to (e.g., by providing a trigger signal) analog characteristics of the device under test (such as DUT temperature, or DUT supply voltage, or DUT supply current, or any other DUT parameter) communicated 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 ​​represented in digital form in the protocol-based data stream provided by the DUT. Thus, it may no longer be necessary to evaluate analog quantities representing DUT parameters (which are prone to distortion and typically difficult to process) in the device communication unit.

[0027] In a preferred embodiment, the trigger generator is configured to extract payload data from raw device under test communication and generate a trigger signal based on the payload. The trigger generator may thus generate a trigger based on the payload data, which may be generated in a well-defined manner, for example, 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 software running on the DUT) to efficiently determine (or modify) the test flow. Furthermore, by evaluating the payload (for example, by evaluating the magnitude of the digital values ​​contained in the payload), triggering can be performed depending on (multi-bit) numerical information represented by the payload.

[0028] 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, e.g. according to IEEE 1149.10, or via a wireless interface, e.g. according to IEEE 802.11, or 3GPP LTE, or 3GPP 5G. Furthermore, a low-level interface (e.g., a debug interface) allows direct access to the hardware components of the device under test, while a high-bandwidth interface (such as a HighSpeed ​​IO, or an Ethernet interface) allows communicating large amounts of program code or data at high speed to or from the device under test. Thus, by using different interfaces, it is possible to have an efficient data exchange architecture. Furthermore, it has been found that triggering on the data stream of such a protocol-based interface allows a good control of the test flow and can help to detect communication errors that may be due to defects in the DUT.

[0029] In a preferred embodiment, the trigger generator is configured to generate comparison information (e.g., a comparison sequence) and to generate a trigger signal based on the comparison information and the extracted payload data (e.g., using a comparison between the comparison information and the extracted payload data). The extraction of the payload data is, for example, performed from direct data provided by the device under test. In other words, the extraction of the payload data allows unwrapping the protocol data from the direct data. Furthermore, the generation of the comparison information may, for example, be performed in advance (e.g., before a test run) or may be performed "just in time", for example, during a test run, allowing for fast and low computational effort trigger generation. For example, a simple data comparison can be used after unwrapping the payload data from the protocol, which can be performed very fast with little hardware effort.

[0030] In a preferred embodiment, the trigger generator is configured to generate the comparison information based on trigger configuration information, which may be provided by the main test flow controller, for example, and may be identical for multiple devices under test, and based on device under test specific information, which may be specific to the device under test, and may include a device under test identifier and / or encryption information. The given trigger configuration information provides, for example, a sensor temperature value of 50°, and the device under test specific information identifies, for example, the nth device under test. Thus, the trigger generator is configured to generate comparison information indicative of the nth device under test having a sensor temperature value greater than 50°. Such a concept allows the amount of data that must be delivered by the main test flow controller to be kept reasonably small. Instead of providing a large amount of different (DUT-specific) "complete" comparison information to multiple trigger generators (for example of different device communication units), it is sufficient to deliver common comparison information and a relatively small amount of device-specific (or device-specific) information to different trigger generators. Thus, the amount of data communicated in an automatic test equipment can be reduced, which is important for performing simultaneous testing of multiple DUTs.

[0031] In a preferred embodiment, the trigger generator includes a hardware circuit (e.g., a configurable hardware trigger circuit, which may include a hardwired signal flow) configured to compare the comparison information (e.g., a locally calculated "comparison sequence") with the extracted payload data. In other words, the hardware circuit (e.g., implemented in a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC)) is configured to compare expected data with the obtained extracted payload data, the extraction of the payload data being made from direct data provided by the device under test. Using a hardware circuit for trigger generation allows particularly high data rates and helps to keep the latency small. Also, there is generally a well-predictable delay, so that a good timing behavior can be achieved.

[0032] In a preferred embodiment, the trigger generator is configured to provide a trigger signal comprising one or more of the following items of information: A timestamp describing the time when the trigger event was detected. The timestamp of a trigger signal indicates the measured number of clock cycles relative to a reference point (e.g. a global reference point). Information about the trigger type. The trigger type considers temperature, and / or payload data, and / or protocol events, and / or trigger ID. The trigger type identifies one of multiple trigger events. Information about the trigger origin (e.g., which DUT among multiple DUTs caused the trigger event, or which component of the DUT payload data or device communication unit caused the trigger event), i.e., information about the trigger source that generated the trigger event. Information about the payload data (e.g., in the environment before a trigger event is detected, or in the environment after a trigger event is detected). · Information about the trigger target (e.g., information indicating which unit of the automatic test equipment should react to detection of a trigger event), i.e. information indicating which unit of the automatic test equipment is targeted for generating a trigger. Information about trigger priority (e.g., if multiple trigger conditions with different priorities are defined). For example, the priority can be defined by a level of high, medium, or low, and the trigger data can be processed one by one according to their trigger priority. Information about the age (e.g. information about the time between detection of a trigger event and signaling of the trigger event, e.g. via a tester interface). Information about the trigger age may be specified through the number of clock cycles between the time of detection of the trigger event (e.g. from extraction of a payload data unit) and the signaling of the trigger event (e.g. from generation of a trigger signal unit).

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

[0034] In a preferred embodiment, the automatic test equipment includes a central trigger signal distributor configured to receive a trigger signal from a 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., changes a voltage or a signal parameter of a signal provided to the DUT causing a trigger event). Furthermore, distribution of the trigger signal can be achieved, for example, through communication with a tester interface (i.e., a communication interface (bus), or generally speaking, a data interface) and listening of the target DCU on the tester interface. By distributing the trigger signal or trigger information in such a manner, coordination between multiple device coordination units can be achieved, which is particularly useful when multiple device communication units cooperate to test a single DUT. Also, additional tester instruments may be time-synchronized or coordinated in response to the trigger event, thereby enabling well-controlled testing in response to different DUT responses.

[0035] In a preferred embodiment, the automatic test equipment comprises one or more further device communication units coupled to a tester interface (i.e. a communication interface (bus)), where at least one of the one or more further device communication units (e.g. a target device communication unit) is configured to detect a trigger signal on the tester interface provided by the source device communication unit and to react to the detection of the trigger signal on the tester interface. Thus, the operation of the multiple device communication units (and in particular the reaction to the trigger event) can be efficiently synchronized, and the synchronization can be performed without the involvement of the main test flow control. This allows for low latency and a low load on the main test flow control.

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

[0037] In a preferred embodiment, the trigger generator is configured to evaluate the match of the payload data (or the bit stream) according to an exact match trigger condition, and / or according to a partial match trigger condition with wildcard, and / or according to a regular expression trigger condition, in order to generate a trigger signal. In particular, the bit stream may be a binary representation of the extracted payload data, e.g., payload data or protocol event information. In the trigger comparison process, the bit stream may have, e.g., an exact match or partial match trigger condition, or a syntax-based condition such as parsing (e.g., a context-based condition). Furthermore, the trigger comparison process may include different states, e.g., an activation state of the trigger by firing (or for firing) if the activation condition is matched, or a disabled state of the trigger by not matching the activation condition (or stopping after a certain time), or an enabled state of the trigger by allowing matching of the prerequisites for triggering (e.g., 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 intermediate "activation states" that can be reached from an "enabled state"), which allows complex trigger conditions to be implemented. Furthermore, by using wildcards (e.g., don't cares) and regular expressions (which can be efficiently evaluated by the trigger generator), it is possible to take into account the actual payload of the data stream when making decisions about triggering.

[0038] In a preferred embodiment, the trigger generator is configured to evaluate the match of the payload data (or bit stream) according to the post-reference cycle trigger condition in order to generate the trigger signal. This may mean, for example, that time synchronization of the device under test and the device communication unit is achieved 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 an activated state of the trigger by firing when the activation condition is matched, or a disabled state of the trigger by mismatch of the activation condition (or stopping after a certain time), or an enabled state of the trigger by an enabled match of the activation condition (precondition for triggering (e.g., intermediate state, waiting for an event to switch to the activated state)). As a result, for example, good timing synchronization can be achieved between different device communication units or between different test instruments. Also, deterministic timing can be achieved, which allows analysis of trigger events, for example, when performing debugging or failure analysis of a test program.

[0039] In a preferred embodiment, the trigger generator is configured to evaluate a match of the payload data (or bit stream) according to a numerical comparison trigger condition to generate a trigger signal. Thus, a numerical value of the payload data can be used to determine, for example, a trigger. Thus, a trigger can be performed depending on whether the payload data of the DUT data stream exhibits a particular numerical value.

[0040] In a preferred embodiment, the trigger generator is configured to evaluate the match of the payload data (or bitstream) according to a minimum number of matching trigger conditions or according to a maximum number of matching trigger conditions in order to generate a trigger signal, thus making the trigger very flexible.

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

[0042] However, it should be noted that the method described herein may be supplemented, if desired, with any of the features, functions, and details disclosed herein, also with respect to automatic test equipment. It should be noted that the method may be supplemented, if desired, with any of such features, functions, and details, either individually or in any combination.

[0043] Embodiments according to the present invention will now be described with reference to the accompanying drawings. [Brief description of the drawings]

[0044] [Figure 1] 1 shows a block schematic diagram of automatic test equipment for generating a trigger signal in response to data received from a device under test. [Diagram 2] 1 shows a block schematic diagram of a module of an automatic test equipment for generating a trigger signal in response to data received from a device under test. [Diagram 3] 1 shows a block schematic diagram of automatic test equipment for generating a trigger signal in response to data received from a device under test. [Figure 4] 2 shows a block schematic diagram of a trigger generation block for generating a trigger signal in response to data received from a device under test; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0045] 1. Detailed description of the drawings 1.1. Automatic test equipment according to Fig. 1 FIG. 1 shows a block schematic diagram of an automatic test equipment 100 according to one embodiment of the present invention.

[0046] The automatic test equipment 100 includes a main test flow control unit 110, which is configured to operate (e.g., coordinate) the test flow to all sites (i.e., operates or controls the entire test flow for testing a device under test or for testing multiple devices under test simultaneously). The automatic test equipment 100 includes a device communication unit 120, which further includes a trigger generation unit 122. The trigger generation unit 122 includes a payload data extraction unit 124, which is configured to provide extracted payload data 124a and / or protocol event information 124b based on, for example, data (or data stream, or DUT data or DUT data stream) 130c provided by a device under test 130. The trigger generation unit 122 further includes a trigger signal generation unit 126, which is configured to generate a trigger signal 126a and may be configured to transmit (e.g., output or transmit) the trigger signal 126a to the main test flow control unit 110 via the tester interface 112, for example.

[0047] Additionally, the automatic test equipment 100 is configured to provide test case data 130a (e.g., appropriate test code uploaded to the device under test) and monitor data 130b (e.g., monitor programs used to upload and / or start and / or abort test execution) to the device under test and to receive data 130c (e.g., response data) from the device under test 130, as desired.

[0048] Thus, in the automatic test equipment 100, the trigger generation unit 122, which is part of the device communication unit 120, is, for example, directly coupled to the device under test, for example, via only a device under test interface (not explicitly shown in FIG. 1). Tight coupling of the trigger generation unit 122 to the DUT interface typically provides better timing prediction due to shorter paths and less latency, and therefore continuous real-time performance (or processing) capabilities.

[0049] In conclusion, the automatic test equipment 100 allows distributed protocol-aware trigger generation and does not require the transfer of complete DUT data to the main test flow control. Rather, the trigger generation is performed in a "distributed" trigger generation unit 122 that is part of the device communication unit. For example, the trigger generation unit may receive the DUT data "in its original form" (e.g., without intermediate transmission through an automatic test equipment internal interface such as a tester interface) and evaluate the DUT data 130 taking into account the communication protocol underlying the DUT data. Thus, the trigger generation unit 126 may generate a trigger signal 126a based on a 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 sophisticated evaluation function capable of evaluating the communication protocol underlying the DUT data 130c is provided in a distributed manner in the device communication unit, which allows fast (e.g., real-time compatible) trigger generation while keeping the amount of data transmitted through the tester interface 122 and the processing load of the main test flow control low.

[0050] Furthermore, it should be noted that the automatic test equipment 100 may be supplemented, as desired, with any of the features, functions, and details disclosed herein, both individually and in any combination.

[0051] 1.2 Reference example based on Figure 2 FIG. 2 illustrates a block schematic diagram of an automatic test equipment module 200 according to one embodiment of the present invention.

[0052] The automatic test equipment module 200 (e.g., a part of it) includes a finite state machine (FSM) 210, which may, for example, be the main control block, i.e., control the functionality of the architecture of the automatic test equipment module 200. In this regard, it should be noted that, compared to the trigger signal generator 126 of the automatic test equipment 100, the finite state machine 210 may have broader functionality.

[0053] Furthermore, the finite state machine 210 may be implemented, for example, in hardware (eg, using an FPGA or ASIC) or software (eg, using a CPU).

[0054] The automatic test equipment module 200 further includes a tester IF (interface) 220, which is configured to receive the trigger signal 212. Furthermore, the automatic test equipment module 200 includes a random access memory (e.g., a dynamic random access memory (e.g., DRAM) 230 or a static random access memory), which further includes, for example, a monitor 232 and test cases 234. The monitor 232 may be, for example, a monitor program that can be provided to the device under test 250 (e.g., under the control of the finite state machine 210) via a debug interface (e.g., a low-level interface or a hardware interface) (e.g., JTAG). The monitor 232 is used to control test execution on the DUT 250 side, for example, by being executed by a processor or CPU of the DUT 250. For example, the monitor can control uploading of test cases to the DUT and / or execution of the test cases on the DUT. In other words, the monitor may support, for example, sending test cases 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 stop test execution. The monitor 232 may also be capable of, for example, evaluating (or pre-evaluating) the results of test execution on the DUT.

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

[0056] It should be noted that the test case 234 may be configured, for example, to provide a test case program, which may include, for example, both test data or test programs that are processed or executed on the device under test 250, and program code that is executed by the automatic test equipment or by the finite state machine 210 of the automatic test equipment.

[0057] The automatic test equipment module 200 further includes a computation unit 240 that optionally provides a configuration 242 (e.g., trigger configuration information) to the finite state machine (FSM) 210. In other words, the computation unit 240 may be an engine that configures the FSM 210. The computation unit may provide configuration information that may define, for example, trigger functions based on data provided by a main test flow control that may be temporarily stored in, for example, a random access memory or DRAM 230. The automatic test equipment module 200 may communicate with a device under test 250 (i.e., an external device) via, for example, a high-speed IO interface 216 (in addition to communicating via a test interface such as JTAG, iJTAG, etc.).

[0058] Additionally, the finite state machine 210 can switch from one state to another, for example, to control testing of the DUT. In some cases, switching between states can occur in response to payload data 218 (or USB payload data or JTAG payload data or IJTAG payload data, etc.). For example, the states can change between: 0) Payload for control (e.g., data may be provided from the main test flow control to the module or device communication unit 200) 1) Loading the monitor (e.g., the monitor program 232 may be uploaded from the random access memory or DRAM 230 to the DUT 250) 2) Loading test cases (eg, test cases 234 may be uploaded from random access memory or DRAM 230 to DUT 250). 3) Test case execution (eg, test cases 234 may be executed under the control of or initiated by a monitor program, for example).

[0059] In the following, the state flow transitions of the finite state machine 210 are explained in more detail using an application scenario.

[0060] One or more sensors 252 (e.g., on-chip sensors) on the device under test 250 may be configured to capture impending anomalies of the on-chip structure, for example, by measuring an average temperature. In one application scenario, the finite state machine (FSM) 210 may, for example, initially control the transfer of payloads (e.g., from the main test flow control to the module 200) in state 0. In state 1, a monitoring program may be uploaded to the DUT, in state 2, test case data may be uploaded to the DUT, and in state 3, a test may be executed, for example, until the on-chip sensor data reaches a predetermined temperature value. The FSM 210 may trigger a sequence (or state transition) when a trigger condition is met (e.g., upon a particular trigger event) (e.g., when a temperature value measured by the 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 via the high-speed IO interface 216 matches a trigger condition defined by the trigger configuration information 242).

[0061] The automatic test equipment module 200 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 allows faster on-chip testing than typical dedicated interfaces (e.g., proprietary test interfaces). The high-speed IO interface 216 can be used, for example, to send (i.e., output or transmit) test case data to the device under test 250, or to receive payload data 218 from the DUT embedded in the DUT data stream according to a protocol (e.g., USB payload data or JTAG payload data or IJTAG payload data) and provide the payload data to the FSM 210, or to receive data from a random access memory or DRAM 230 and forward it to the DUT 250 according to a (communication) protocol.

[0062] In one example, the HighSpeed ​​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 a handshake protocol and / or a package counter and / or a packetization protocol. Thus, the HighSpeed ​​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 a protocol, device specific information (e.g., encryption, ID) and non-determinism due to the communication interface may be handled.

[0063] Additionally, a random access memory (eg, dynamic random access memory (DRAM) 230) may communicate with a processor (eg, a central processing unit (CPU)), for example, via a processor interface (PIF).

[0064] The automatic test equipment module 200 further includes a tester interface (IF) 220 coupled to, for example, a finite state machine (FSM) 210 and the main test flow control unit 110. The tester interface 220 is configured, for example, to enable high-speed communication (e.g., sending data or receiving data) with low latency. Furthermore, the tester interface 220 is preferably, but not necessarily, time-deterministic, taking into account the number of cycles per time required for data transmission. In other words, in some embodiments, data delivery without retransmission and / or within a fixed time period is guaranteed.

[0065] In conclusion, the module 200 may enable testing of a DUT, which may be, for example, a system on chip. The high-speed IO may, for example, communicate test case data to the DUT 250 using a protocol-based data stream and may receive a protocol-based data stream from the DUT 250. The high-speed IO 216 may, for example, take over the function of the payload data extractor 124 and may be capable of signaling one or more protocol events (e.g., start or end of a data transmission or data packet, a protocol error, a predefined protocol state, etc.) as desired. Thus, the FSM, or a dedicated trigger generator not shown in FIG. 2, may generate a trigger signal, for example, in response to the extracted payload and / or in response to one or more protocol events. The trigger signal may, for example, be used by the finite state machine 210 to control the execution of the test (e.g., to trigger a state transition) and / or may be forwarded to the main test flow control unit and / or another device communication unit and / or another test instrument.

[0066] Furthermore, it should be noted that the automatic test equipment module 200 may be supplemented, as desired, with any of the features, functions, and details disclosed herein, both individually and in combination.

[0067] 1.3 Example according to FIG. 3 FIG. 3 shows a block schematic diagram of an automatic test equipment 300 according to another embodiment of the present invention.

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

[0069] The trigger generation unit 322 is configured to communicate with the main test flow control unit 310 (e.g., to send trigger data or receive control data) via a tester interface 312 (e.g., a communication interface (bus) for the device communication unit to communicate with the main test flow control unit), and the tester interface 312 is configured to establish, for example, a bidirectional communication between the main test flow control unit 310 and at least one DCU 320a-320n. Furthermore, the tester interface 312 is configured, for example, to enable high-speed communication with low latency. The tester interface 312 may be, for example, time-deterministic in the number of cycles required for data transmission. In other words, data delivery without retransmission or within a predefined time may be guaranteed (i.e., retransmission of the same data is not essential for reliable transmission).

[0070] Furthermore, the trigger generator 322 may be (or may include) a configurable logic that reacts to data input, for example, from the device under test 330a. In other words, the trigger generator 322 is configured to receive (or read) input 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 input data from the device under test can be, for example, a sequential bit stream on multiple pins, possibly in parallel, or packetized data (e.g., protocol data, or packetized protocol). The trigger generator 322 may be configured to generate a trigger signal and send the trigger signal to the tester interface 312. Furthermore, the trigger generator 322 may generate multiple triggers. However, the trigger generator may alternatively or additionally be configured to provide a trigger signal to another subunit of the device communication unit.

[0071] In the following, implementation variations of the trigger generator 322 (eg, software and configurable hardware) are described.

[0072] Software trigger generation can be performed, for example, on a central processing unit (CPU). A CPU-based approach is used, for example, to compare input data streams and generate triggers by software instructions. By using such an approach, it is possible to have a local trigger generation unit on the DCU. If appropriate software concepts are applied, for example, the approach can be time-deterministic, for example, if the approach is implemented without using a cache. However, this approach can be slow compared to hardware solutions that may be used as another alternative.

[0073] Furthermore, it should be noted that the automatic test equipment 300 may be supplemented, as desired, with any of the features, functions, and details disclosed herein, both individually and in combination.

[0074] 1.4 Example according to FIG. 4 4 shows a block schematic diagram of a trigger generation block 400 for generating a trigger signal 426 in response to data received from a device under test. The trigger generation block 400 shown in FIG. 4 may be, for example, part of a device communication unit as disclosed herein.

[0075] The trigger generation block 400 includes a trigger generation unit 420. The trigger generation unit 420 may correspond to the trigger generation unit 122 or 322, for example.

[0076] The trigger generation section 420 includes, for example, a unit 422 (also indicated by "A") that can adapt a hardware comparison unit 424 according to trigger configuration information, and a hardware (HW) comparison (e.g., FPGA, ASIC) unit 424 configured to provide (i.e., generate) a trigger signal 426 to the main test flow control section 110, 310.

[0077] In a configurable hardware trigger generator approach, pre-computed information or signals 412a (e.g., comparison sequences) may be generated by a local computation unit 410 using a combination of a trigger configuration (or trigger configuration information) 412 and DUT specific information 414. The trigger generator 420 may receive the pre-computed information or signals 412a from the local computation unit 410 and payload data 430a from the device under test via a DUT interface 430. Along with the payload data 430a, at least one protocol event information may optionally be provided by the DUT interface 430.

[0078] The DUT interface 430 may include a protocol wrapper 432 configured to extract, for example, payload data 430a from the DUT communication. The payload wrapper may thus be configured to use, for example, device specific data (such as a decryption key) to extract from the DUT communication 440 a “plain text” payload representation that may be received from the DUT via, for example, a DUT interface of a device communication unit or an automatic test equipment. Furthermore, the protocol mapper may also optionally provide information (or signals) to the trigger generator 420 describing (or signaling) one or more protocol events (e.g., one or more predefined protocol states such as a start or end of a frame, or one or more protocol errors (such as a framing error, or a parity error, or a packet loss)).

[0079] Thus, the trigger generator may perform a comparison between, for example, 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 computation unit, and the trigger generator may take into account "wild cards" or "don't cares", for example, only a portion of the extracted payload for trigger generation. If the comparison satisfies a predefined condition, a trigger signal may be activated or provided. The trigger configuration information 412 may determine, for example, which portion of the extracted payload 430a is taken into account in the comparison and which comparison criteria are used to activate (or provide) the trigger signal.

[0080] Alternatively, or in addition, the trigger generator may take into account one or more protocol events reported by the protocol wrapper using an appropriate signal or information when deciding about activating the trigger signal. For example, the trigger signal may be activated or provided in response to a predefined protocol error, or in response to a predefined combination of protocol errors, or in response to another protocol event (e.g., in response to the end of a data frame).

[0081] In conclusion, the trigger generation block 400 is able to generate trigger signals in a flexibly configurable manner in close proximity to the DUT.

[0082] It should further be noted that the trigger generation block 400 may be supplemented, as desired, with any of the features, functions and details disclosed herein, both individually and in combination.

[0083] 1.5 Application The automatic test equipment disclosed herein in connection with testing a device under test can, in one application scenario, in particular, control test execution through an on-chip sensor of the device under test. During the test process, the test execution can be executed until, for example, a certain sensor temperature value (e.g., a temperature value of 50°) is reached due to heating (e.g., on-chip self-heating) of the DUT circuitry. In other words, a trigger signal is generated after detection of on-chip self-heating (or other anomaly) in the device under test by using a different sensor type (e.g., a temperature sensor) in connection with the test execution.

[0084] Another application scenario may relate to controlling power supplies (e.g., on different device communication units, or in different automatic test modules, or in different automatic test equipment instruments) for voltage drops during a test process by generating other types of trigger signals.

[0085] 1.6 Conclusion Some conclusions are offered below.

[0086] In a test concept for testing a DUT, the test flow may depend on the generation of trigger signals that cause changes throughout the test execution. The generation of trigger signals is especially required for interactive test flows that are based on results from the device under test.

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

[0088] An embodiment according to the invention may not be used as part of a main test flow control unit, which may generate trigger data with communication latency due to, for example, high traffic of data in the main test flow control unit. Rather, according to one aspect of the invention, the trigger generation unit (or trigger generation block) is part of the device communication unit to minimize communication latency. In particular, the described automatic test equipment is based on the insight that in order to achieve low communication latency during interactive test flows, the real-time trigger generation unit should be close to the DUT interface (or communication channel).

[0089] In conclusion, the present embodiments take into account real-time requirements for trigger generation in order to maintain minimal latency between the event itself, the communication of the trigger, or the reaction of the test execution flow.

[0090] In conclusion, embodiments according to the present invention can be used to test a device under test in an efficient manner and are therefore advantageous over other conventional concepts.

[0091] 2. Further Aspects and Embodiments Further aspects and embodiments according to the present invention are described below. The aspects may be used individually or in combination and may be incorporated into any of the embodiments disclosed herein, both individually and in combination, as desired.

[0092] According to one aspect, an embodiment in accordance with the present invention creates an apparatus for a real-time trigger generation system close to the DUT interface.

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

[0094] According to one aspect, a test flow may depend on the generation of a trigger. For example, the trigger(s) may signal a specified event to the test execution flow. The trigger(s) may also enable the flow (or test flow) to react thereto (e.g., to the trigger, or to a trigger signal, or to a specified event). The generation of a trigger may be required, for example, for an interactive test flow that depends on results from the DUT. According to one aspect, a trigger may be equivalent to an interrupt in the processing unit.

[0095] According to one aspect, there may be one or more quality requirements (eg, for the trigger generator or real-time trigger generation). Minimal latency between the event itself and the communication of the trigger / reaction to the test execution flow Time determinism allowing accurate backmapping of cycles ○Trigger generation ○Trigger communication / broadcast -Flexibility in defining triggers ○ Simple bit comparison is insufficient for protocol interfaces and devices with more advanced requirements Protocol awareness ○ It is necessary to handle device-specific information and non-determinism due to communication interfaces. ○ Handshakes, device parameters, sensor readings, package counters, packetized protocols, ...

[0096] According to one aspect of the invention, embodiments of the invention may meet one or more, or even all, of these requirements.

[0097] In the following, some building blocks used in embodiments according to the present invention are discussed.

[0098] The main test flow control may be coupled to a device communication unit (DCU), which is a local processing unit connected to the DUT.

[0099] The main test flow controller may be the main execution unit that coordinates the test flow for all sites.

[0100] Furthermore, there may be a tester interface, which may be a communication interface (bus) for the device communication unit to communicate with the main test flow (or the main test flow control unit). The tester interface may be coupled, for example, between the main test flow control unit and the device communication unit.

[0101] Additionally, there may be a trigger generator, which is configurable logic that responds to data (or data stream) input from the DUT to generate a trigger signal and communicate it to the tester interface. Multiple triggers can be generated as desired. The trigger generator may be part of the device communication unit, for example.

[0102] Additionally, there is a DUT interface that allows communication between the device communication unit and the DUT.

[0103] Furthermore, the device under test may also be referred to as a DUT or a dut.

[0104] An example of the arrangement and interaction of building blocks is shown, for example, in FIG.

[0105] In the following, some (optional) details and aspects of the general underlying architecture, as well as some requirements, are described.

[0106] The tester interface is preferably designed to enable high speed communication with low latency. Furthermore, the tester interface is preferably deterministic in the number of cycles and / or time required for data transmission. Preferably, the tester interface enables guaranteed data delivery without retransmissions. Furthermore, the tester interface preferably enables bidirectional communication between 1...N DCS(S) and the main test flow control.

[0107] The trigger generating unit may receive, for example, input data from a device, for example, -Sequential bit stream on multiple pins, possibly in parallel -Packetized data can be read.

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

[0109] There are different possible implementation variants for trigger generation.

[0110] A software trigger generator (e.g., on the CPU) may be used. A CPU-based approach may, for example, compare input data streams and generate a trigger (or trigger signal) by software instructions. A CPU-based approach may, for example, be implemented locally on the DCU. In some cases, the CPU-based approach is only deterministic without using a cache. In some cases, the CPU-based approach is slow compared to hardware solutions.

[0111] Alternatively or additionally, the trigger generator may be implemented using (or as) a configurable hardware trigger. For example, the configurable hardware trigger may include local generation of a comparison sequence, e.g., using a combination of configuration and DUT specific information. For example, the configurable hardware trigger may use a local comparison of a sequence (e.g., a comparison sequence) with a payload (or an extracted payload) from the DUT. According to one aspect, the configurable hardware trigger may include (or perform) extraction of a payload from direct data from the DUT. According to one aspect, the configurable hardware trigger may unwrap protocol data. According to one aspect, the configurable hardware trigger may communicate the trigger, e.g., to a main tester interface. According to another aspect, the configurable hardware trigger may communicate the trigger, e.g., for local transmission to a different device communication unit (DCU)(s), which may be connected to the same device (or the same DUT), for example.

[0112] An example of a trigger generation unit (or trigger generation block) is shown in FIG.

[0113] In the following, some optional aspects and details regarding the trigger (or trigger signal) are provided. According to one aspect, the trigger (or trigger signal) consists of (or includes) one or more of the following items: A timestamp (e.g. clock cycles since a reference point) Trigger Type -Trigger start point DUT, DCU Payload Data Trigger Target ·Priority Age

[0114] In the following, some optional aspects and details regarding distribution of triggers are provided. For example, trigger distribution may be performed using a central distributor, e.g., from the DCU to the central (or central distributor) and from the central (or central distributor) to the DCU. As another example, trigger distribution can be performed using bus communication and listening of the target DCU on the bus. According to another example, there may be direct trigger communication to the target DCU, e.g., using a loopback on the load board.

[0115] Some optional aspects and details regarding the trigger comparison are described below.

[0116] For example, one, two or more of the following conditions may exist: Activate: Fires when activation conditions are met Disabled: No activation conditions met · Enable: Enables matching the activation conditions.

[0117] For example, there may be a transition from a disabled state to an enabled state when a first condition is met or when a trigger mechanism is enabled by control of the DCU, a transition from the enabled state to an activated state when a second condition is met, and provision (or activation) of a trigger signal when an activation condition is met. However, different functionality is also possible.

[0118] Additionally, one or more of the following condition types may be used, for example: Matching of the bitstream (e.g., of the extracted payload) with a pre-computed reference stream Exact match Partial match with wildcards ·Regular expression - Cycle after reference conditions Global sync reference, activate, disable, enable -Numeric operation comparison -Min / Max Match Count - Direct command support (e.g. from the DUT, from the tester interface)

[0119] Some optional aspects and details regarding the DUT interface are described below. According to one aspect, the DUT interface enables protocol-aware communication between the DCU and the DUT. According to one aspect, the DUT interface can perform unwrapping of payload from raw device communication.

[0120] According to one aspect, one or more of the following communication interfaces (or communication interface types) may be used (eg, as a DUT interface or as multiple DUT interfaces): -JTAG (IEEE1149.x) -IJTAG (IEEE1687.x) -Boundary scan (IEEE1500) -HighSpeed ​​IO Test Access -IEEE1149.10 "Via USB" or utilizing one or more USB functions "via Ethernet" or utilizing one or more Ethernet capabilities "Through SATA" or utilizing one or more SATA features -Ethernet -USB -SATA - Debugging interface, e.g. TAP

[0121] Note that IEEE 1149.10 is a standard for generic high speed test access to the DUT, and utilizes parts (e.g. PHY, (de-)serializer, bit and word alignment units) of existing HSIO interfaces such as USB, Ethernet, SATA, etc. It does not use existing controllers as a whole.

[0122] Some possible applications are described below.

[0123] According to one aspect, embodiments in accordance with the present invention may be used to implement an on-chip sensor controlled test flow.

[0124] According to one embodiment, a readout of on-chip sensor information may be performed. For example, a test run may be performed until the on-chip sensor signal reaches 50 degrees. As another example, a control of the power supply (e.g., on a different DCU) for voltage drop may be performed.

[0125] In the following, possible improvements of embodiments according to the invention over the prior art are described.

[0126] According to one aspect, delays (e.g., of triggers) due to transmission of data (e.g., to a central execution unit) and due to centralized generation of triggers can be avoided (e.g., because an embodiment uses a decentralized trigger generation unit).

[0127] Furthermore, using embodiments in accordance with the present invention, high traffic on a central data bus (eg, tester interface) is avoided.

[0128] Furthermore, cycle accuracy can be maintained using embodiments in accordance with the present invention.

[0129] Additionally, embodiments in accordance with the present invention exhibit good real-time performance and good multi-site efficiency.

[0130] Also, embodiments in accordance with the present invention include good multi-site capabilities.

[0131] Furthermore, embodiments in accordance with the present invention may be used to efficiently control tester resources, such as power supplies.

[0132] Embodiments in accordance with the present invention can handle non-deterministic interfaces and are suitable for protocol awareness (or protocol-aware communication).

[0133] Embodiments according to the present invention allow for content-aware implementations.

[0134] Embodiments in accordance with the present invention may take into account (or be able to take into account) device specific information.

[0135] An embodiment in accordance with the present invention may allow for a simple match of bit sequences.

[0136] Thus, embodiments in accordance with the present invention may provide numerous advantages over conventional approaches.

[0137] 3. Alternative Implementations Although some aspects have been described in the context of an apparatus, it will be apparent that these aspects also represent a description of a corresponding method, where a block or device corresponds to a method step or feature of a method step. Similarly, aspects described in the context of a method step also represent a description of a corresponding block or item or feature of a corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of the most important method steps may be performed by such an apparatus.

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

[0139] Some embodiments according to the invention include a data carrier having an electronically readable control signal, which is capable of cooperating with a programmable computer system such that one of the methods described herein is performed.

[0140] Generally, embodiments of the present invention can be implemented as a computer program product having program code operable to perform one of the methods when the computer program product is run on a computer. The program code may for example be stored on a machine readable carrier.

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

[0142] In other words, an embodiment of the inventive methods is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer.

[0143] A further embodiment of the inventive method is therefore a data carrier (or digital storage medium, or computer readable medium) having recorded thereon a computer program for performing one of the methods described herein. The data carrier, digital storage medium or recorded medium is typically tangible and / or non-transferable.

[0144] A further embodiment of the inventive method is therefore a data stream or a sequence of signals representing the computer program for performing one of the methods described herein. For example the data stream or the sequence of signals may be adapted to be transferred through a data communication connection, for example via the Internet.

[0145] A further embodiment comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted to perform one of the methods described herein.

[0146] A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein.

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

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

[0149] The apparatus described herein may be implemented using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer.

[0150] The apparatus described herein, or any components of the apparatus described herein, may be implemented at least in part in hardware and / or software.

[0151] The methods described herein may be performed using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer.

[0152] Any of the methods described herein, or any of the components of the apparatus described herein, may be at least partially implemented by hardware and / or software.

[0153] The above-described embodiments merely exemplify the principles of the present invention. It is understood that modifications and variations of the configurations and details described herein are apparent to others skilled in the art. It is therefore intended to be limited only by the scope of the appended claims and not by the specific details presented in the description and illustration of the embodiments herein.

Claims

1. 1. An automatic test equipment for testing one or more devices under test, the automatic test equipment comprising: a main test flow control section; a device communication unit coupled to the main test flow control unit via a tester interface and adapted to interface with one or more devices under test; the device communication unit includes a trigger generator configured to extract payload data from a protocol-based data stream received from the device under test, generate a 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 flow controller via the tester interface; the main test flow control unit changes the contents of the test flow or triggers a state transition in the test flow in response to the trigger signal transmitted from the trigger generation unit; Automatic test equipment.

2. the device communication unit is configured to communicate a trigger event to the main test flow control unit or another device communication unit via the tester interface; 2. The automatic test equipment of claim 1.

3. The tester interface synchronously transmits data to the main test flow control unit.

3. An automatic test equipment according to claim 1 or 2.

4. the tester interface is configured to enable bidirectional communication between the main test flow control unit and the device communication unit; 4. An automatic test equipment according to any one of claims 1 to 3.

5. the trigger generator is configured to extract the payload data from a packetized data stream and / or a sequential bit stream on one or more pins; 5. An automatic test equipment according to any one of claims 1 to 4.

6. the trigger generator is configured to evaluate one or more protocol-aware communications between the device communication unit and the device under test, and generate the trigger signal based on payload data of the one or more protocol-aware communications.

6. Automatic test equipment according to any one of claims 1 to 5.

7. the trigger generator is configured to extract payload data from raw device under test communications and generate the trigger signal based on the payload data.

7. Automatic test equipment according to any one of claims 1 to 6.

8. The trigger generation unit is configured to generate the trigger signal in response to data received from a 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 IEEE 1149.10, or via a wireless interface according to IEEE 802.11, or 3GPP LTE, or 3GPP 5G.

8. Automatic test equipment according to any one of claims 1 to 7.

9. the trigger generator is configured to generate comparison information and generate the trigger signal based on the comparison information and the extracted payload data.

9. Automatic test equipment according to any one of the preceding claims.

10. The trigger generator is configured to generate comparison information based on trigger configuration information and based on DUT specific information.

10. Automatic test equipment according to any one of the preceding claims.

11. the trigger generator includes a hardware circuit configured to compare the extracted payload data with the comparison information; 11. Automatic test equipment according to any one of claims 1 to 10.

12. The trigger generator receives the following information items: A timestamp describing when the trigger event was detected; Information about the trigger type, Information about the trigger origin, Information about the payload data, Information about the trigger target, Information about trigger priority, and configured to provide a trigger signal including one or more of the information relating to the age of the device.

12. Automatic test equipment according to any one of the preceding claims.

13. the automatic test equipment includes a central trigger signal distributor configured to receive a trigger signal from a device communication unit and to forward the trigger signal to another device communication unit or to another trigger target; 13. Automatic test equipment according to any one of the preceding claims.

14. the automatic test equipment including one or more further device communication units coupled to the tester interface; at least one of the one or more further device communication units is configured to detect a trigger signal on the tester interface provided by a source device communication unit and to react to the detection of the trigger signal on the tester interface.

14. Automatic test equipment according to any one of the preceding claims.

15. the automatic test equipment including one or more further device communication units coupled to the tester interface; at least one of the one or more further device communication units is configured to receive a dedicated trigger signal from the source device communication unit and to react to said reception of the dedicated trigger signal; 15. Automatic test equipment according to any one of the preceding claims.

16. the trigger generator is configured to evaluate a match of payload data according to an exact match trigger condition, the exact match being satisfied by an exact match of the extracted payload data bit stream with a reference stream, to generate the trigger signal.

16. Automatic test equipment according to any one of the preceding claims.

17. the trigger generator is configured to evaluate a match of payload data according to a mathematical comparison trigger condition to generate the trigger signal.

17. Automatic test equipment according to any one of the preceding claims.

18. the trigger generator is configured to evaluate a match of payload data according to a minimum number of matched trigger conditions or according to a maximum number of matched trigger conditions to generate the trigger signal.

18. Automatic test equipment according to any one of the preceding claims.

19. 1. A method for testing one or more devices under test, the method comprising: extracting payload data from a protocol-based data stream received from the device under test, generating a trigger signal in response to the extracted payload data or in response to one or more protocol events, and transmitting the trigger signal to a main test flow control via a tester interface; and changing the content of the test flow or triggering a state transition in the test flow in response to the trigger signal sent to the main test flow control unit. method.

20. The method is performed in an apparatus including a main test flow control unit and a device communication unit, the device communication unit is coupled to the main test flow control; the device communication unit interfaces with one or more devices under test; said generating said trigger signal being performed in said device communication unit; 20. The method of claim 19.

21. A computer program product for causing a computer to carry out the method according to claim 19 or 20.

Images