Automated test equipment and method for testing a device under test

Abstract

One embodiment of the invention is an automated test equipment (ATE) for testing a device under test (DUT) comprising a processing unit and a program and / or data memory, wherein the processing unit is capable of executing code from the program and / or data memory. The automated test equipment is configured to establish communication, e.g. by uploading a program to the DUT using a first interface, e.g. a debug interface or debug access port or a general purpose interface that enables access to the processing unit for external control. A typical use case for the first interface is debug access to the DUT, which typically requires limited data rates. In the case of the invention, the first interface is the ATE access for test execution, e.g. an interface that allows access to the processing unit registers. The first interface configures the DUT to open a second interface that runs at a much higher data rate (than the first interface) for additional communication. Furthermore, the second interface can have extended capabilities compared to the first interface, e.g. presenting its own memory as normal system memory to the processing unit of the DUT, only that access times can be slower.

Description

Technical Field

[0001] According to embodiments of the present invention, an automated test apparatus is provided for testing a device under test, the device under test including a processing unit and a memory. The memory may include program and / or data memory.

[0002] A further embodiment of the invention relates to an automated testing apparatus, which includes a test controller, one or more computer interfaces, and shared memory.

[0003] A further embodiment of the present invention relates to a method for testing a device under test (DUT).

[0004] The embodiments of the present invention generally relate to the testing of digital semiconductor devices, and more specifically to system type testing during device manufacturing.

[0005] A further embodiment of the present invention relates to a memory expansion method for system-on-chip testing. Background Technology

[0006] For production testing of digital semiconductor devices, structural testing methods are widely used. However, these tests focus on a complex functional implementation or IP block within a multi-intellectual property (IP) digital semiconductor design. Therefore, with the help of structural test design techniques, IP blocks, which may originate from different IP sources and / or vendors, are often structurally fully testable. These structural tests test the logic functionality, and they are performed in test modes.

[0007] In the final application of digital semiconductor design, i.e. in task and / or operating modes, the device typically or primarily operates in its task mode rather than in test mode.

[0008] If the semiconductor is a system-on-a-chip (SOC) or system-in-a-package (SIP), internal and / or external processing units or a central processing unit (CPU) can execute instructions or program code to process data exchanged between IP blocks. Interactions between IP blocks may introduce new cross-IP error behavior mechanisms. These may be design-related and / or process-related.

[0009] While the initial system boot of a newly designed system aims to find design flaws, a growing number of semiconductor manufacturers are focusing on establishing system-type testing during device manufacturing to identify process-related defects. This testing step requires task-mode operation to establish internal communication or demonstrate cross-IP functionality.

[0010] Typical building blocks of a SOC or SIP design include the processing unit (PU), computer infrastructure (such as cache memory for instructions and / or data, such as L2 cache), peripheral logic, and specific design and / or custom IP blocks.

[0011] During the production testing phase, the systems these SOC chips are designed for are not yet complete. Components such as external memory, mass storage devices, and power management are only partially available, as such components may be added in later production stages, such as during packaging or assembly into application boards.

[0012] Therefore, for example, the storage of program code to be executed on a wafer-level processing unit is very limited, that is, limited by on-chip memory resources, such as small memory libraries and / or cache memory that may be reconfigured to act as memory. This means that test program code and the data to be processed need to be very small in order to fit into these resources. People need to find ways to work around this limitation, such as breaking down the test content into smaller parts.

[0013] External memory interfaces are typically not serviced during wafer prober insertion. They require wide buses, very short traces, and / or round-trip times, typically with trace lengths less than 1 cm. Furthermore, they require significantly more pins because these memory interfaces are often reused as test ports for structural testing. Integrating memory functionality into automated test equipment (ATE) offers limited or no assistance because the need for wide buses, and especially the need for very short traces and / or round-trip times, cannot be adequately met.

[0014] High-speed input / output (HSIO) buses, such as Peripheral Component Interface Express (PCIe). TMUniversal Serial Bus (USB) and Serial Peripheral Interface (SPI) are narrow but high-speed interfaces. Similar to the debug port of the processing unit, ATE coverage is possible and is widely used in the ATE industry for parameterized signal verification.

[0015] To expand the available RAM memory, some designs are known to have special design-for-testability (DfT) hardware, which allows L2 cache memory to be repurposed as additional RAM, for example by disabling cache algorithms.

[0016] Using on-chip RAM solely or exclusively for the execution of test case programs imposes size limitations. Furthermore, the program needs to be fully loaded before execution can begin. Therefore, loading time via JTAG and / or another debug port is relatively finite. Additionally, similar indirect access to test results via the debug port mechanism is required.

[0017] Enabling RAM size expansion by repurposing L2 cache as RAM requires a special DfT (Depth-First Tracing). While caching requires storing the start address and cache line data of what are called cache lines and needs to form contiguous memory regions, the DfT needs to disable these mechanisms to prevent program code from being automatically overwritten. This option has been published, but due to its complexity, it has rarely been observed or applied.

[0018] Using external memory modules on the board, such as RAM, ROM, flash ROM, etc., leads to excessive use of device pins that can no longer be used for test access, resulting in gaps in structural testing. Furthermore, this option requires significant maintenance and / or diagnostic work, such as verifying circuitry, verifying and / or replacing program content. Additionally, without being combined with debug access ports, this option provides limited visibility of test results, meaning that a summary is signaled on a single bit of the device under test (DUT).

[0019] It is desirable to perform functional tests on the DUT by uploading the program to the DUT via the second interface, because it is well known that semiconductor devices exhibit different characteristics in test mode compared to their task mode, such as power consumption characteristics.

[0020] Therefore, there is a need for a concept that allows for increased memory size and / or availability of the DUT during functional testing of the DUT, and / or allows for faster and / or monitored and / or protected communication between the DUT and ATE.

[0021] This objective is addressed by the subject matter of the independent claims. Summary of the Invention

[0022] One embodiment of the present invention (see, for example, claim 1) is an ATE for testing a DUT, the DUT including a processing unit and program and / or data memory, wherein the processing unit is capable of executing code from the program and / or data memory. The automated test apparatus is configured to upload a program to the DUT using a first interface, such as a debug interface or debug access port (DAP) or a general interface that allows access to the processing unit for external control.

[0023] A typical use case for the first interface is software debugging, which is usually quite slow. In the case of this invention, the first interface can be, for example, an ATE access port for test execution, such as an interface that allows access to the internal functions of the DUT.

[0024] The program uploaded to the DUT via the first interface configures the DUT to enable a second interface that operates at a higher data rate (e.g., a much higher data rate), such as a higher (or even much higher) data rate than the first interface, for additional communication.

[0025] For example, an ATE configured to upload and run programs on a DUT can enable a second interface with a higher data rate, thereby reducing the time spent testing the DUT. The second interface may also potentially act as a program and / or data storage, and / or provide additional functionality not available using the first interface.

[0026] This embodiment is based on the idea that by providing a program to the DUT via a relatively slow first interface, the program can enable a relatively fast second interface, which may require, for example, some configuration and / or driver software, thus accelerating the testing process.

[0027] Thus, the second interface can support communication between the ATE or tester and the DUT, and / or can allow the DUT to access memory, which is provided by the tester and may be useful, for example, when performing tests.

[0028] However, while the second interface may not function or fully function upon power-up, the tester can activate it using a program uploaded via the first interface (which may be a simple interface, requiring no software-driver configuration process and / or no driver software), thus enabling improved testing. Using the first interface to download the initial program code into the DUT memory also addresses the issue of potentially unusable one-time programmable ROMs on the chip: these are typically programmed with application ROM code at a later stage in the production process and therefore cannot be used to configure the second device to interact with the ATE, also for safety reasons.

[0029] In summary, by using a two-step process, where a first interface is required to provide the DUT with a procedure that activates the second interface, the DUT can be brought into a state where it can access external memory, allowing for complex testing.

[0030] According to an embodiment (see, for example, claim 2), a program uploaded to the DUT via a first interface performs one or more of the following steps.

[0031] ● The uploaded program configures the DUT and / or uses the DUT's connection blocks, such as the DUT's memory, to load additional program code and / or data via the second interface. If the program is executed by the DUT, for example, if the program is executed from the shared memory of an automated test apparatus, the second interface may include or communicate at a higher data rate than the data rate of the first interface. The second interface may also potentially act as a program and / or data storage, and / or provide other functionalities that cannot be provided using the first interface.

[0032] ● The uploaded program controls the execution of one or more programs.

[0033] ● The uploaded program sets the DUT's registers to the desired values.

[0034] ● The uploaded program configures the DUT's memory access, such as random access.

[0035] The uploaded program is configured to configure the DUT, which may include loading additional programs and data, executing one or more programs, setting DUT register values ​​and memory accesses. The benefits of configuring the DUT may include establishing faster communication between the DUT and ATE, or mapping shared memory, which could result in running programs from and / or reading data from / writing data to shared memory.

[0036] In a preferred embodiment (see, for example, claim 3), the program uploaded to the DUT via the first interface is configured to configure the DUT to access the second interface using memory mapping. This can be achieved, for example, by writing an appropriate value to the DUT's memory mapping control register. And this may result in, for example, the contents of the shared memory of the ATE coupled to the DUT via the second interface appearing as memory to the DUT's processing unit, for example, as memory connected to the DUT's system bus. This can result in an expansion of the DUT's addressable memory.

[0037] According to an embodiment (see, for example, claim 4), a program uploaded to the DUT via the first interface is configured to configure the DUT's resource manager to allocate a memory subrange of the memory range addressable by the DUT's processing unit for accessing the second interface. The program can configure the resource manager such that the contents of the shared memory of the ATE coupled to the DUT via the second interface appear to the DUT's processing unit as memory within the allocated memory subrange. This can result in an expansion of the DUT's memory.

[0038] In a preferred embodiment (see, for example, claim 5), the program uploaded to the DUT is configured to communicate with the ATE as a client or as a host, exchanging data with its counterpart using an appropriate application protocol, i.e., exchanging data with the ATE.

[0039] For example, the exchanged data may include compiled code snippets, setup and configuration data, measurement results data, and / or register values. The DUT is configured to form a stand-alone computer system.

[0040] According to an embodiment (see, for example, claim 6), the ATE is configured or required to authenticate and / or authorize itself for the first and / or second interfaces.

[0041] For example, an ATE is configured to authenticate and / or authorize itself using cryptographic means and / or secret credentials. For instance, authentication may be required to prove its identity, such as for establishing communication. Authorization may be required to gain access to otherwise restricted functions on a device. The required authentication and / or authorization, for example, leads to enhanced security.

[0042] In a preferred embodiment (see, for example, claim 7), the ATE is configured or required to communicate with the DUT in an encrypted manner and / or in a protected manner to prevent modification by using a first interface and / or a second interface.

[0043] For example, the communication is configured to be protected against modification by using standard and / or proprietary data integrity checking methods (such as hashing). For example, the communication is configured to be encrypted by using standard and / or proprietary encryption schemes and / or methods. Using protected and / or encrypted communication results in increased security.

[0044] According to an embodiment (see, for example, claim 8), the ATE is configured or required to communicate with the DUT in a compressed manner using standard and / or proprietary, lossy and / or lossless compaction means through a first and / or second interface, wherein the automated test equipment is configured to compress data to be sent to the DUT and decompress data received from the DUT.

[0045] Sending and / or receiving compressed data is more time-efficient than sending and / or receiving uncompressed data.

[0046] In a preferred embodiment (see, for example, claim 9), the program uploaded to the DUT via the first and / or second interface includes program code for performing compaction and / or decompacting methods to perform compression and / or decompression.

[0047] For example, compaction and / or decompacting methods are only used in test mode, and there may be no obligation for the DUT to include compaction and / or decompacting methods in task and / or operation modes.

[0048] According to an embodiment (see, for example, claim 10), the ATE is configured to cause the processing unit of the DUT to execute test case code and / or test case program, which is stored in the shared memory of the ATE and loaded onto the DUT via a second interface.

[0049] For example, test case code resides in a sub-range of memory within the memory range addressable by the DUT's processing unit, as perceived by the DUT's processing unit. For instance, test case code is suitable for testing one or more functions of the DUT when executed by the DUT's processing unit. Storing and / or executing test case code in the ATE's shared memory reduces the DUT memory requirements in test modes. Furthermore, the ATE can easily manage test case programs stored in the ATE's shared memory.

[0050] In a preferred embodiment (see, for example, claim 11), the ATE is configured to invalidate a cache or cache region before the DUT executes test case code stored in the shared memory of the ATE and loaded into the DUT via the second interface. The second interface may also potentially act as a program and / or data memory, and / or provide additional functionality not available using the first interface.

[0051] Invalidating a cache or cache region in test mode can, for example, lead to the separation of test mode and task and / or operation mode, so that the cache and / or cache region can retain programs and / or data without test mode, and the data in the cache and / or cache region can be prevented from being overwritten by the test process.

[0052] Further benefits of invalidating a cache or cache region may include, for example, the ability to store data or auxiliary data generated during the testing process in shared memory and to be evaluated, for example, by the ATE (Automatic Test Equipment). Testing and / or evaluating this data may also lead to improvements in the quality of the testing process, for example, by increasing the quantity and / or type of input data.

[0053] According to an embodiment (see, for example, claim 12), a program uploaded to the DUT using a first interface is configured to initialize the DUT's processing unit and initialize the DUT's second interface. Furthermore, the program is configured to configure the DUT's second interface to connect to the ATE's shared memory and provide a memory range of the ATE's shared memory as a memory range usable by the DUT's processing unit, for example, through memory mapping. The shared memory range may be accessible, for example, through memory access instructions and / or opcodes.

[0054] The benefits of shared memory may include, for example, that both the ATE and DUT can access the memory, thereby speeding up testing. This is achieved by eliminating the need to store and send / receive data between the ATE and DUT and by allowing the ATE to exchange information near real-time, instantaneously (i.e., whenever the contents of the shared memory change).

[0055] In a preferred embodiment (see, for example, claim 13), the program uploaded to the DUT using the first interface is configured to initialize the memory range to which the memory range of the ATE's memory is mapped, so as to be cached by the cache of the device under test, such as an L2 cache.

[0056] This could result in, for example, extended memory provided by the second interface being presented to the DUT's processing unit as normal system memory, although the processing time might be slower.

[0057] The second interface may also potentially act as a program and / or data storage, and / or provide other functionalities that cannot be provided using the first interface.

[0058] This could further lead to, for example, shared memory between the ATE and DUT, which could be beneficial, for example, as both the ATE and DUT are able to access the memory, thus allowing the ATE to perform tests near real-time, instantaneously (i.e., whenever the contents of the shared memory change).

[0059] According to an embodiment (see, for example, claim 14), the program uploaded to the DUT using the first interface is configured to initialize the memory range to which the shared memory range of the ATE is mapped, such that the extended memory provided by the second interface is presented to the DUT's processing unit as normal system memory (e.g., random access memory), although access time may be slower. The host's memory (which can be mapped to the memory area of ​​the device under test) is cached, thereby enabling the test program to be executed at a reasonable speed.

[0060] This could result in, for example, extended memory provided by the second interface being presented to the DUT's processing unit as normal system memory, although access time might be slower.

[0061] This could further lead to, for example, shared memory between the ATE and DUT, which could be beneficial, for example, as both the ATE and DUT are able to access the memory, thus allowing the ATE to perform tests near real-time, instantaneously (i.e., whenever the contents of the shared memory change).

[0062] In a preferred embodiment (see, for example, claim 15), the program uploaded to the DUT using the first interface is configured such that the DUT transmits the results of program execution to the ATE via a second interface, so as to store the results of program execution in the shared memory of the automated test equipment, for example, via the second interface.

[0063] The benefits of shared memory may include, for example, that both the ATE and DUT can access the memory, thereby speeding up testing. This is achieved by eliminating the need to store and send / receive data between the ATE and DUT and by allowing the ATE to perform tests near real-time, on-demand (i.e., whenever the contents of the shared memory change).

[0064] According to an embodiment (see, for example, claim 16), the ATE is configured to perform data analysis based on results stored in the memory of the ATE via a second interface, which may also act as a program and / or data storage and / or provide other functions that cannot be provided using the first interface.

[0065] The ATE can be further configured to perform characterization of the DUT, such as pass / fail calculation, based on results stored in the memory of the ATE via a second interface.

[0066] The ATE can be further configured to evaluate data access patterns to the ATE's memory via a second interface, for example, to characterize the DUT and / or perform pass / fail detection.

[0067] The ATE can be further configured to analyze real-time information received from the device under test via a second interface in order to characterize the DUT.

[0068] In a preferred embodiment (see, for example, claim 17), the ATE is configured to cause the DUT to execute multiple test case programs sequentially and / or in parallel, for example, in the case of a multi-core DUT. This will, for example, generate different stress patterns and potentially be more realistic. The test case programs are stored in different memory ranges of the ATE's shared memory, which the DUT accesses via a second interface. For example, parallel execution and / or evaluation of test cases can have the benefit of accelerating the testing process by running different tests on different cores.

[0069] According to an embodiment (see, for example, claim 18), a program uploaded to the DUT via a first interface is configured to configure the DUT to load the program code and / or data of the given test case program via a second interface during the execution of the given test case program, thereby expanding the memory of the DUT and allowing the use of, for example, in operating mode instead of test mode, and / or test caching.

[0070] For example, whenever a processing unit of the DUT requests a new opcode, such as when the program loads program code and / or data from a memory region covered by shared memory coupled to the second interface.

[0071] For example, whenever the DUT's caching mechanism retrieves an opcode, such as when the program loads program code and / or data from a memory region covered by shared memory coupled to the second interface (assuming that this program code and / or data may be required by the DUT's processing unit).

[0072] According to an embodiment (see, for example, claim 19), the ATE includes a test controller. Furthermore, the ATE includes a first interface, such as a debug interface, for providing test data to the DUT. Additionally, the ATE includes shared memory accessible by the test controller and accessible by the DUT, for example, via a second interface.

[0073] The ATE can provide test data to the DUT via a first interface or a second interface. Furthermore, for example, the ATE may include a test controller and shared memory. Both the DUT and the test controller have access to the shared memory, which improves data exchange between the DUT and the ATE. Moreover, it can lead to near real-time, instantaneous testing, where the ATE can perform tests whenever the data in the shared memory changes.

[0074] In a preferred embodiment (see, for example, claim 20), the ATE includes a test controller. Furthermore, the ATE includes a first interface, such as a debug interface, for providing test data to the DUT. Additionally, the ATE includes shared memory accessible by the test controller and accessible by the DUT, for example via a second interface that includes a higher data rate than the first interface. This second interface, which may be a high-speed interface, can be comprised of another debug interface operating at a high data rate, which may be, for example, constructed for testing.

[0075] Furthermore, the second interface can be a typical interface of the DUT's end application in application mode, such as, but not limited to, PCIe or USB. This option can also provide advantages in system test coverage for DUT testing.

[0076] According to an embodiment (see, for example, claim 21), the ATE includes a high-speed serial interface configured to allow the DUT to access shared memory.

[0077] A high-speed serial interface may include one serial data channel, or two or more serial data channels, and may act as a secondary interface. The high-speed serial interface (HSIO) can also be a host interface client configured to handle DUT access to the ATE's shared memory.

[0078] In addition, the HSIO interface can be scaled according to the bandwidth requirements of the test or the end application, which can be important for interface test coverage.

[0079] In a preferred embodiment (see, for example, claim 22), the serial interface is a Fast PCI interface or a Fast PCI-compatible interface, such as PCI Express. TM or PCIe TM .

[0080] Use common serial interfaces, such as PCI Express. TM and / or PCIe TM Interfaces can increase the variety of existing connectors and / or interfaces that can be used, and / or bring the benefits of using existing interfaces, which can reduce complexity and / or cost.

[0081] In a preferred embodiment (see, for example, claim 23), the serial interface is a Universal Serial Bus (USB) interface, such as a USB 1.0 interface, or a USB 1.1 interface, or a USB 2.0 interface, or a USB 3.0 interface, or a USB 3.1 interface, or a USB 3.1 Gen 1 interface, or a USB 3.1 Gen 2 interface, or a USB 3.2 interface, or a USB 4 interface, or any other interface standardized by the USB Implementers Forum and backward compatible with the interfaces mentioned herein.

[0082] Using common serial interfaces, such as different versions of the USB interface, can increase the variety of existing connectors and / or interfaces that can be used, and / or bring the benefits of using existing interfaces, which can reduce complexity and / or cost.

[0083] In a preferred embodiment (see, for example, claim 24), the serial interface is Thunderbolt, or Ethernet, or IEEE-1394, IEEE-1500, IEEE-1687, IEEE-1149, such as the IEEE-1149.10 interface, or a SATA interface, which can be, for example, a SATA interface, or a Fast SATA interface, or an eSATA interface, or a Mini SATA interface, or any other interface backward compatible with these interfaces. Furthermore, the serial or second interface may be part of the first interface.

[0084] Generally speaking, serial interfaces, like any other HSIO interface, are suitable for unidirectional and / or bidirectional data exchange, and may also include dedicated debug and test interfaces.

[0085] Using common serial interfaces, such as Thunderbolt, Ethernet, SATA / eSATA, or IEEE-1394, IEEE-1500, IEEE-1687, and IEEE-1149 interfaces, can increase the variety of existing connectors and / or interfaces that can be used, and / or bring the benefits of using existing interfaces, which can reduce complexity and / or cost.

[0086] In a preferred embodiment (see, for example, claim 25), the ATE is configured such that the shared memory can be accessed by multiple DUTs. Sharing memory among multiple DUTs can reduce costs and / or the number of memory and / or test controllers used when DUTs are tested in parallel. Depending on the desired test objectives, each DUT may access the entire shared memory or only a restricted area.

[0087] In a preferred embodiment (see, for example, claim 26), the ATE includes multiple interfaces, such as host interface clients, coupled to shared memory to allow multiple DUTs to access the shared memory.

[0088] Multiple interfaces coupled to the shared memory allow multiple DUTs to access the shared memory. Sharing memory among multiple DUTs can reduce costs and / or the number of memory and / or test controllers used when several DUTs are tested in parallel.

[0089] According to an embodiment (see, for example, claim 27), the test controller is configured to select which portion or range of shared memory is currently accessible to the DUT. The test controller can ultimately be configured to change this selection when a new test case program is to be executed. The test controller can be configured to select one or more portions of the shared memory, such as one or more memory ranges, and assign them to multiple DUTs.

[0090] Dynamically allocating shared memory ranges can lead to an adaptive testing process, resulting in reduced memory overhead. Tests can utilize memory more efficiently, thus reducing the risk of memory exhaustion, for example, when testing the DUT in parallel.

[0091] According to an embodiment (see, for example, claim 28), the test controller is configured to change the allocation of a portion of the shared memory to a given DUT during a test run, such that, during a first portion of the test run, a first portion of the shared memory is allocated to the given DUT, and during a second portion of the test run, a second portion of the shared memory is allocated to the given DUT.

[0092] Assigning different memory ranges of shared memory to different test processes can result in test processes being separated in such a way that different test cases and / or data from different test cases cannot interact with each other.

[0093] According to an embodiment (see, for example, claim 29), the ATE is configured to modify a currently unused portion of the shared memory to set up a new test case program, while the DUT accesses another portion of the shared memory.

[0094] Setting up new test cases to utilize unused memory ranges in shared memory can potentially speed up the testing process. Using all available memory for testing purposes makes the testing process more time-efficient and / or memory-efficient.

[0095] According to an embodiment (see, for example, claim 30), the ATE is configured to read data stored in the shared memory by the DUT from the shared memory, while the DUT accesses another portion of the shared memory.

[0096] Because the test cases are separate from each other, that is, separate memory portions of shared memory are used for different test cases, it is possible to read and evaluate previous test results while other tests are running on the DUT, that is, the DUT is reading / writing data from / on other portions of shared memory.

[0097] According to an embodiment (see, for example, claim 31), the ATE is configured to analyze data stored by the DUT in shared memory in order to obtain test results, such as pass / fail information or quantitative information about the performance of the DUT.

[0098] Test data can be analyzed by the ATE to obtain test results, qualitative and / or quantitative information, which may be about the pass / fail status and / or measurements of the DUT. Based on (one or more) test results, the quality of the DUT can be determined.

[0099] Each method has been created according to further embodiments of the present invention.

[0100] However, it should be noted that these methods are based on the same considerations as the corresponding apparatus. Furthermore, these methods can be supplemented by any features, functions, and details described herein regarding the apparatus, either individually or in combination. Attached Figure Description

[0101] In the following, embodiments of the present disclosure will be described in more detail with reference to the accompanying drawings, in which:

[0102] Figure 1 A schematic diagram of a test setup is shown, which includes an embodiment of an ATE and a DUT having a processing unit (PU), memory, a first interface, and a second interface;

[0103] Figure 2 A schematic diagram of a test setup is shown, which includes embodiments of a DUT and an ATE, the ATE having a first interface, a test controller, and memory accessible by the test controller and the DUT;

[0104] Figure 3 A schematic diagram of a typical SOC is shown;

[0105] Figure 4 A schematic diagram of a conventional test setup is shown, which includes an ATE and a DUT, with an exemplary DUT PU memory mapping diagram;

[0106] Figure 5 A schematic diagram of a conventional test setup is shown, featuring an ATE and DUT with shared memory, and an exemplary DUT PU memory map including shared memory; and

[0107] Figure 6 A flowchart is shown for a method of uploading a program to a DUT via a first interface in order to configure the DUT to load additional data and / or program code. Detailed Implementation

[0108] Different inventive embodiments and aspects will be described below. Further embodiments will be defined by the appended claims.

[0109] It should be noted that any embodiment defined by the claims may be supplemented by any details (features and functions) described herein. Furthermore, the embodiments described herein may be used alone or optionally supplemented by any details (features and functions) included in the claims. Additionally, it should be noted that the individual aspects described herein may be used alone or in combination. Thus, details may be added to each of the individual aspects without adding details to the other. It should also be noted that this disclosure expressly or implicitly describes features that can be used in an ATE. Therefore, any feature described herein can be used in the context of an ATE.

[0110] Furthermore, the features and functions disclosed herein related to the method can also be used in (applied to perform such functions) an apparatus. Additionally, any features and functions disclosed herein regarding the apparatus can also be used in the corresponding method. In other words, the method disclosed herein can be supplemented by any features and functions described with respect to the apparatus.

[0111] The invention will be more fully understood through the following detailed description and the accompanying drawings of embodiments thereof; however, the detailed description and drawings should not be construed as limiting the invention to the specific embodiments described, but are merely for illustration and understanding.

[0112] according to Figure 1 Test setup

[0113] Figure 1 A schematic diagram of a test setup 100 is shown, which includes embodiments of ATE 110 and DUT 120.

[0114] DUT 120 also includes a processing unit 130, a memory 140, a first interface 150, and a second interface 160, the second interface 160 having a higher data rate than the first interface 150. For example, the processing unit, memory, first interface, and second interface may be coupled via one or more buses or interconnect structures. Both the first interface 150 and the second interface 160 are connected to ATE 110. ATE 110 includes a program 170 to be uploaded to DUT 120.

[0115] ATE 110 is configured to upload program 170 to DUT 120 using first interface 150, wherein first interface 150 may optionally allow bidirectional communication. For example, ATE may be able to read DUT status information and / or DUT values ​​and further information through first interface 150.

[0116] The program 170 uploaded via the first interface 150 is configured to configure the DUT 120 to enable and / or configure the second interface 160 for additional communication 190. The second interface 160 is configured to operate at a data rate higher than or significantly higher than that of the first interface 150, which is, for example, a slow interface and / or a debug interface.

[0117] ATE 110 benefits from the configured second interface 160 because any additional communication 190 between ATE 110 and DUT 120 is much faster than through the first interface 150. This means that sending and / or receiving program code and / or test data is accelerated, and / or the testing process itself is accelerated. Additionally, the second interface can be used to expand the memory of DUT 120.

[0118] according to Figure 2 Test setup

[0119] Figure 2 A schematic diagram of the test setup 200 is shown, which includes... Figure 1 ATE 110 is similar to ATE 210 and... Figure 1 An embodiment of DUT 220 similar to DUT 120.

[0120] ATE 210 includes a test controller 230, shared memory 240, and a first interface 250. Furthermore, ATE 210 is connected to DUT 220 via the first interface 250. The first interface 250 is not necessarily unidirectional; it may optionally allow bidirectional communication. The shared memory 240 of ATE 210 is connected to the test controller 230 and also to DUT 220, for example, via a second interface.

[0121] ATE 210 is configured to send test data 260 to DUT 220 via a first interface 250. DUT 220 can access shared memory 240, for example via a second interface having a higher data rate than the first interface 250. Shared memory 240 can also be accessed by test controller 230 of ATE 210.

[0122] like Figure 1 As described, ATE 110 is configured as uploader 170 to configure the fast second interface 160 of DUT 120.

[0123] Therefore, the shared memory 240 of ATE 210 can be accessed by test controller 230 and by DUT 220 through DUT 220's fast second interface. Both DUT 220 and test controller 230 are capable of writing data to and / or reading data from shared memory 240, while ATE 210 can also send test data 260 to DUT 220 via first interface 250 to, for example, control test execution.

[0124] The shared memory 240 of ATE 210 expands the memory of DUT 220 and eliminates the need to send / receive data between ATE 210 and DUT 220. Data is instead copied to / read from shared memory 240.

[0125] according to Figure 3 DUT

[0126] Figure 3 The typical DUT 300 to be tested is shown, for example. Figure 1 The DUT in the test setup 100. A typical building block of a DUT 300 or SOC design consists of a processing unit, computer infrastructure, peripheral logic and other custom IP blocks 360 connected by a system bus 320.

[0127] Typical processing units include processing unit 310, coprocessor 313, or digital signal processor (DSP) 316, etc.

[0128] Typical computer infrastructure includes, for example, Level 2 cache (L2 cache) 330, SRAM 333, NVRAM 336, BOOT ROM 339, and so on.

[0129] Typical peripheral devices include memory interface 340, flash memory interface 343, debug DfT interface 349, host interface 346, such as PCIe, USB, etc.

[0130] Typically, during the production testing phase, the system design for which these SOC chips are intended is not yet complete. Components such as external memory or mass storage devices 340, power management, etc., are only partially available, as such components may be added at later stages, such as during packaging or assembly into the application board.

[0131] During functional testing, the host interface of the SOC design is typically operated in task and / or operational modes.

[0132] The storage of program code to be executed on the wafer-level processing unit 310 is very limited, for example, by on-chip memory resources, such as small memory groups 333 or 336 and cache memory 330 that may be reconfigured to act as memory.

[0133] and Figure 1 The ATE 110, similar to the ATE, is configured to upload programs via the debug DfT interface 349. The uploaded program is configured to open and / or set up the connection between the DUT 300 and the ATE via the host interface 346, such as via a PCIe or USB interface, which allows for rapid connection between the ATE and the DUT.

[0134] according to Figure 4 Traditional test setup

[0135] Figure 4 An exemplary conventional test setup 400 is shown. This test setup includes... Figure 3 The DUT 420 shown is similar to the DUT 300, and is also similar to... Figure 1 The ATE 410 is similar to the ATE 410, but it has a test controller 430. The test controller 430 of the ATE 410 is connected to the DUT 420 via its debug DfT interface 440.

[0136] Figure 4 An exemplary processing unit memory map 450 is also shown. The processing unit memory map 450 includes addresses of processing units 460, such as addresses of coprocessors, DSPs, and / or custom IP blocks, and addresses of memory units 470, such as addresses of L2 cache, NVRAM, BOOTRAM, SRAM, and addresses of unavailable flash memory and / or memory or mass storage devices. Memory units 470 are covered by L2 cache.

[0137] In traditional solutions, the ATE 410's test controller 430 uploads and / or downloads program code and / or test data to the DUT 420 via the debug DfT interface 440. The program code and / or test data need to comply with memory size limitations.

[0138] In some solutions, RAM size can also be expanded by repurposing the L2 cache as RAM.

[0139] The limitations of the traditional solution are the small RAM size of the DUT 420 and the relatively slow upload and / or download speeds between the ATE 410's test controller 430 and the DUT 420 via the debug DfT interface 440.

[0140] During conventional testing, the host interface of the SOC design typically operates in task and / or operational modes. However, unlike the test setup of this invention, nothing is attached to this host interface. Therefore, in a conventional test setup, the host interface can also be disabled because operational behavior cannot be tested in any other way than using Design for Test (DfT) building blocks or methods. One of the key differences between the conventional test setup and the test setup of this invention is that in the test setup of this invention, the ATE connects to the DUT via the host interface, and the ATE also tests the host interface through information exchange between the ATE and the DUT via the host interface.

[0141] Furthermore, conventional solutions do not provide the real-time external analysis and monitoring capabilities demonstrated by this invention.

[0142] according to Figure 5 Test setup

[0143] Figure 5 An exemplary test setup 500 is shown. Test setup 500 includes... Figure 1 ATE 110 is similar to ATE 510 and... Figure 3 The DUT 300 shown is similar to an embodiment of DUT 520. ATE 510 includes a test controller 536 and an ATE processing unit 533, a host interface client 549, and shared memory 543 using address virtualization 546. The shared memory is accessible by the test controller 536 and by the DUT 520 via the host interface client 549 (e.g., PCIe or USB). The host interface client 549 of ATE 510 is connected to the host interface 523 of the DUT. Typically, this interface is, for example, a serial interface, which is latency-tolerant.

[0144] Figure 5An exemplary memory map 550 is also shown. This memory map includes addresses of processing units 553, such as coprocessors, DSPs, and / or other custom IP blocks. The memory map also includes addresses of memory cells 556, such as SRAM, BOOT ROM, NVRAM, L2 cache 529, addresses of unavailable mass storage devices and / or flash memory interfaces, and addresses of shared memory. All memory cells 556 can be covered by L2 cache 529.

[0145] The ATE processing unit 533 and / or test controller 536 of ATE 510 are configured to upload a program to DUT 520 via debug DfT interface 526. The program uploaded to DUT 520 is configured to initialize the DUT, initialize and configure the high-speed interface, set ATE 510 as a link partner, initialize and / or configure shared memory 543, and initialize and / or configure the caching of shared memory by L2 cache 529. Test controller 536 then selects a test case and configures address virtualization 546 for shared memory 543. Test controller 536 is also configured to cause DUT 520 to run the test case stored on shared memory 543 via debug DfT interface 526. During test case execution on DUT 520, test controller 536 can analyze the results of previous tests, monitor the execution of the current test, select the next test case, and / or run a new test case, if, for example, the processing unit of DUT 520 has more than one core.

[0146] In other words, the test controller 536 and / or ATE processing unit 533 of ATE 510 are configured to upload programs to DUT 520 to configure DUT 520 to access shared memory 543 via a faster second host interface 523. Test controller 536 and / or ATE processing unit 533 are also configured to configure address virtualization 546 of shared memory 543 and enable DUT 520 to run selected test cases on shared memory 543 by sending program code and / or test data to debug DfT 526 and / or host interfaces 549, 523.

[0147] Virtualization on the ATE side is unnecessary for DUT execution testing. While the DUT can operate on a "large memory lake," from the perspective of this invention's efficient ATE, the ability to isolate test cases and / or perform preparation and / or DUT execution and / or result analysis in parallel on the ATE side enables higher ATE throughput.

[0148] In other words, the ATE of the present invention is configured to follow the following steps.

[0149] 1. The Debug Access Port (DAP) or Debug DfT interface 526 is used to keep the DUT 520 in a hold state after a reset.

[0150] 2. The DAP 526 is used by the test controller 536 and / or the ATE processing unit 533 to load a small test executable program into the DUT 520 and run it, so that...

[0151] a. Initialize the DUT digital semiconductor chip and / or processing unit;

[0152] b. Initialize and configure the HSIO or host interface, such as the PCIe interface, and set up components in the ATE system 510 as link partners to provide a certain range of memory for the digital semiconductor system memory and / or processing unit memory;

[0153] c. Initialize the "HSIO memory" so that it is also cached by, for example, L2 cache 529, or by, for example, the processing unit.

[0154] 3. Test controller 536 is configured to select a test case, such as test case number 3.

[0155] 4. Invalidate and / or reset the L2 cache, for example, by the processing unit.

[0156] 5. Via DAP: Call the starting address of the test case in the "HSIO memory", for example, by the processing unit.

[0157] 6. Test cases are executed, and the results are also written to the "HSIO memory," for example, by the processing unit.

[0158] 7. The program flow returns to "Debug Control", which means that the processing unit is waiting for DAP.

[0159] 8. If more test cases are available, the test controller may select the next test case and proceed to item 4, and / or jump back to and / or execute the steps in this list starting from step 4.

[0160] 9. In the background, result analysis of completed test cases can begin. Furthermore, the execution of the current test case can be monitored. If necessary, the memory image of the next device can be prepared and / or refreshed. This requires the implementation of dual-port memory in the ATE controller hardware and / or in all ATE processing units.

[0161] 10. The HSIO interface used as a second interface or as an interface for accessing the shared memory on the ATE side is thoroughly tested in operating mode, the operating behavior can be diagnosed, and unexpected operating states can be analyzed.

[0162] according to Figure 6 Method

[0163] Figure 6 A flowchart 600 of a method according to an embodiment of the present invention is shown. The method includes uploading a program to a DUT via a first interface 610, similar to... Figure 3 The method also includes the step of configuring the uploaded program via the second interface 620 to load additional program code and / or data.

[0164] This method is based on the same considerations as the embodiments described above. Moreover, these methods can be supplemented by any features, functions, and details described herein.

[0165] For example, the above method can optionally be derived from... Figure 5 Any features / functions / details described may be used to supplement this description, either individually or in combination.

[0166] Benefits of the present invention

[0167] Compared with traditional solutions, the ATE of the present invention has the following advantages:

[0168] ● Many known HSIO-based data buses provide memory mapping usage models. PCI Express TM This is the most prominent example here: an expansion device announces that it desires or provides a certain memory and / or I / O region. The resource manager in the processing unit's operating environment finds a matching free space and assigns an appropriate starting address to or for that resource. What that resource (behind it), such as actual memory or control registers, depends on the implementation. This method can be used, for example, but not limited to, PCI Express. TM .

[0169] ●For example, PCI Express TM The use of the card as a memory expander and therefore as a source of program code and / or data is not actually known, especially for testing purposes (in which testing purposes) it is not known.

[0170] ● A practical observation of many HSIO interfaces is that they are used to control peripheral devices via memory-mapped control registers and / or also via data areas in the computer system's global memory map.

[0171] ● These data areas are used as the source of computer code executed by the processing unit of the computer system, that is, as an extension of the processing unit memory. Test case code is displayed at a specific address in the processing unit memory. Execution begins by jumping to or calling that address, which can be initiated by the test controller.

[0172] ● The processing unit cache can be configured in such a way that this memory extension is accepted as normal system memory. In other words, the cache's memory range will need to be programmed accordingly, which is a normal use case. This means that no special DfT is required.

[0173] ● Tests of digital semiconductor designs run in task mode to identify faults, such as those in communication between various contained IP blocks. That is, the tests generate data "traffic" from one IP to another. A key test item is often the use of HSIO buses (e.g., Fast PCI and USB, but not limited to these) in task mode. The operation of these interfaces poses challenges to the flow of traffic across clock domains in the design under test. Testing HSIO interfaces for stability, as described above, is a byproduct of this invention.

[0174] ●Now, many larger and / or more realistic test cases are possible.

[0175] ● No additional download and / or copy time overhead is required. Downloads are performed via the HSIO bus during execution time. Runtime performance is guaranteed and / or improved by the L2 cache.

[0176] ● The test controller can also manage multiple test cases and allow the DUT to "step through".

[0177] ● The execution of test cases can be monitored and analyzed simultaneously by ATE.

[0178] Further general improvements

[0179] The present invention can be further improved by adding security features, which may include the following features:

[0180] ○ Qualify the ATE and / or tester for the first interface and / or the second interface:

[0181] ATE and / or tester may be required to use, for example, cryptographic means and / or secret credentials to self-authenticate against the first and / or second interfaces to prove their identity, such as that required to establish communication.

[0182] ○ Authorize the ATE and / or tester for the first interface and / or the second interface:

[0183] ATE and / or testers may be required to authorize themselves against a first or second interface using, for example, cryptographic means and / or secret credentials, to gain permissions on the device, such as access to otherwise restricted functions.

[0184] ○ Perform integrity checks on the communication between the DUT and ATE and / or test equipment:

[0185] Standard and / or proprietary data integrity checking methods, such as hashing, can be used to protect communication between the DUT and the ATE and / or the tester and / or the first and / or second interfaces of the ATE to prevent modification.

[0186] ○ Encryption of communication between the DUT and ATE and / or tester:

[0187] Communication between the DUT and the ATE and / or the tester and / or one or more interfaces of the ATE can be encrypted using standard encryption schemes and / or proprietary encryption methods.

[0188] The invention can be further improved by adding compression features, which may include the following features:

[0189] ○ Compression of communication between the DUT and ATE and / or tester:

[0190] Communication between the DUT and the ATE and / or tester, or the primary and / or secondary interfaces of the ATE, can be compressed using standard or proprietary, lossy or non-lossy compression methods. This includes the ATE and / or tester compressing data before sending it to the device for decompression, and / or the device compressing or compressing the transmitted data before sending it to the tester and / or the tester decompressing the data.

[0191] Compression of communication between the DUT and ATE may also be required:

[0192] ■ The required compaction and / or decompacting methods may or may be uploaded to the DUT using the first interface and / or the second interface as part of the program code.

[0193] Implementation method replacement

[0194] Although some aspects have been described in the context of the apparatus, it should be 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 a corresponding block, item, or feature of the corresponding apparatus.

[0195] Depending on certain implementation requirements, embodiments of the present invention can be implemented in hardware or software. This implementation can be executed using digital storage media, such as floppy disks, DVDs, CDs, ROMs, PROMs, EPROMs, EEPROMs, or flash memory, storing electronically readable control signals that cooperate (or are capable of cooperating with) a programmable computer system to cause the corresponding methods to be executed.

[0196] Some embodiments of the invention include a data carrier having electronically readable control signals that are capable of cooperating with a programmable computer system to enable one of the methods described herein to be executed.

[0197] Generally, embodiments of the present invention can be implemented as a computer program product having program code that operates 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 medium.

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

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

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

[0201] Another embodiment of the inventive method is therefore a sequence of data streams or signals representing a computer program for performing one of the methods described herein. This sequence of data streams or signals may, for example, be configured to be transmitted via a data communication connection, such as via the Internet.

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

[0203] Another embodiment includes a computer having a computer program installed thereon for performing one of the methods described herein.

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

[0205] 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, the field-programmable gate array may cooperate with a microprocessor to perform one of the methods described herein. Generally, the methods are preferably performed by any hardware device.

[0206] The apparatus described herein can be implemented using hardware devices, computers, or a combination of hardware devices and computers.

[0207] The apparatus described herein, or any component thereof, may be implemented, at least in part, in hardware and / or in software.

[0208] The methods described herein can be executed using hardware devices, computers, or a combination of hardware devices and computers.

Claims

1. An automated testing device (110, 210, 410, 510) for testing a device under test (120, 220, 300, 420, 520), wherein the device under test includes a processing unit (130, 310, 313, 316) and a program and / or data memory (140, 330, 333, 336). in, The automated testing equipment is configured to upload programs to the device under test using a first interface (150, 250, 349, 440, 526). The program (170) uploaded to the device under test via the first interface configures the device under test to enable a second interface (160, 346, 523) operating at a higher data rate for additional communication (190). The automated testing equipment is configured to invalidate cache (330, 529) or cache region before the device under test executes the test case code. The test case code is stored in the shared memory of the automated testing equipment and loaded into the device under test via the second interface.

2. The automated testing equipment according to claim 1, in, The program uploaded to the device under test via the first interface is used for: The device under test is configured to load additional program code (170) and / or data (170) via a second interface for execution by the device under test, the second interface including a higher data rate than the first interface; and / or Controlling the execution of one or more programs; and / or Set the registers (450, 550) of the device under test to the desired values; and / or Configure memory access (470, 556) for the device under test.

3. The automated testing equipment according to claim 1, in, The program uploaded to the device under test via the first interface configures the device under test to access the second interface using memory mapping (450, 550).

4. The automated testing equipment according to any one of claims 1 to 3, in, The program uploaded to the device under test via the first interface configures the resource manager of the device under test to allocate a memory subrange (470, 556) of the memory range addressable by the processing unit of the device under test for accessing the second interface.

5. The automated testing equipment according to any one of claims 1 to 3, in, The program uploaded to the device communicates with the automated testing equipment as a client or as a host, and exchanges data with its counterpart using application protocols.

6. The automated testing equipment according to any one of claims 1 to 3, in, The automated testing equipment is configured to authenticate and / or authorize itself for the first interface and / or the second interface.

7. The automated testing equipment according to any one of claims 1 to 3, in, The automated test equipment is configured to communicate with the device under test in an encrypted manner and / or in a manner protected against modification.

8. The automated testing equipment according to any one of claims 1 to 3, in, The automated test equipment is configured to communicate with the device under test in a compressed manner using compaction methods, wherein the automated test equipment is configured to compress data to be sent to the device under test and decompress data received from the device under test.

9. The automated testing equipment according to claim 8, in, The program uploaded to the device under test via the first interface and / or the second interface includes program code for performing compaction and / or decompacting methods to perform the compression and / or decompression.

10. The automated testing equipment according to any one of claims 1 to 3, in, The automated test equipment is configured to cause the processing unit of the device under test to execute test case code, which is stored in the shared memory of the automated test equipment and loaded into the device under test via the second interface.

11. The automated testing equipment according to claim 1, in, The program uploaded to the device under test using the first interface is used for: Initialize the processing unit of the device under test. Initialize the second interface of the device under test, and The second interface of the device under test is configured to connect to the memory (240, 543) of the automated test equipment and the memory range (240, 543, 546) of the automated test equipment's memory is provided as the memory range that the processing unit of the device under test can use.

12. The automated testing equipment according to claim 11, in, The program uploaded to the device under test using the first interface initializes the memory range mapped to the memory range of the automated test equipment's memory, so that it can be cached by the cache of the device under test.

13. The automated testing equipment according to claim 11 or 12, in, The program uploaded to the device under test using the first interface initializes the memory range mapped to the memory range of the automated test equipment, so that the extended memory (240, 543, 546) provided by the second interface is presented to the processing unit of the device under test as normal system memory, although the access time may be slower.

14. The automated testing equipment according to any one of claims 1 to 3, in, The program uploaded to the device under test via the first interface enables the device under test to transmit the program execution results to the automated testing equipment via the second interface.

15. The automated testing equipment according to claim 14, in, The automated test equipment is configured to perform data analysis based on results stored in the memory (240, 543, 546) of the automated test equipment via the second interface, and / or The automated test equipment is configured to perform characterization of the device under test based on results stored in the memory of the automated test equipment via the second interface; and / or The automated test equipment is configured to evaluate data access patterns to the memory of the automated test equipment via the second interface; and / or The automated testing equipment is configured to analyze information received from the device under test via the second interface in order to characterize the device under test.

16. The automated testing equipment according to any one of claims 1 to 3, wherein, The automated test equipment is configured to cause the device under test to execute multiple test case programs sequentially or in parallel. The multiple test case programs are stored in different memory ranges of the automated test equipment's memory and are accessed by the device under test via the second interface.

17. The automated testing equipment according to any one of claims 1 to 3, in, The program uploaded to the device under test via the first interface configures the device under test to load the program code and / or data of the given test case program via the second interface during the execution of the given test case program.

18. The automated testing equipment according to any one of claims 1 to 3, in, The automated testing equipment includes test controllers (230, 430, 536); The automated testing equipment includes the first interface for providing test data (260) to the device under test; and The automated testing equipment includes a shared memory (240, 543), which can be accessed by the test controller and by the device under test.

19. An automated testing device for testing a device under test. in, The automated testing equipment includes a test controller; The automated testing equipment includes a first interface for providing test data to the device under test; The automated testing equipment includes a shared memory that can be accessed by the test controller and the device under test. The automated test equipment is configured to invalidate cache (330,529) or cache region before the device under test executes the test case code, which is stored in the shared memory of the automated test equipment and loaded into the device under test via a second interface that operates at a higher data rate.

20. The automated testing equipment according to claim 19, in, The automated test equipment includes a serial interface (549) configured to allow the device under test to access the shared memory.

21. The automated testing equipment according to claim 20, in, The serial interface is a Fast PCI interface or a Fast PCI compliant interface.

22. The automated testing equipment according to claim 20, wherein, The serial interface is a Universal Serial Bus (USB) interface.

23. The automated testing equipment according to claim 20, in, The serial interface is a Thunderbolt interface, an Ethernet interface, an IEEE-1394 interface, or a SATA interface, or wherein the serial interface is an IEEE-1149 interface, or wherein the serial interface is an IEEE-1500 interface, or wherein the serial interface is an IEEE-1687 interface, or wherein the serial interface may be a part of the first interface.

24. The automated testing equipment according to any one of claims 19 to 23, in, The automated test equipment is configured such that the shared memory can be accessed by multiple devices under test.

25. The automated testing equipment according to claim 24, in, The automated test equipment includes multiple interfaces coupled to the shared memory to allow multiple devices under test to access the shared memory.

26. The automated testing equipment according to any one of claims 19 to 23, in, The test controller is configured to select which portion (546) of the shared memory (240, 543) can be accessed by the device under test; or The test controller is configured to select portions (543, 546) of the shared memory for allocation to multiple devices under test.

27. The automated testing equipment according to any one of claims 19 to 23, in, The test controller is configured to change the allocation of a portion of the shared memory to a given device under test during test runs. So that the first portion of the shared memory is allocated to the given device under test during the first part of the test run, and This causes the second portion of the shared memory to be allocated to the given device under test during the second part of the test run.

28. The automated testing equipment according to any one of claims 19 to 23, in, The automated test equipment is configured to modify the currently unused portion of the shared memory to set up new test case programs, while the device under test accesses another portion of the shared memory.

29. The automated testing equipment according to any one of claims 19 to 23, in, The automated test equipment is configured to read data stored in the shared memory by the device under test (DUT) from the shared memory, while the DUT accesses another portion of the shared memory.

30. The automated testing equipment according to claim 29, in, The automated testing equipment is configured to analyze data stored in the shared memory by the device under test in order to obtain test results.

31. A method (600) for testing a device under test, said device under test including a processing unit and a program and / or data memory, in, The method includes uploading (610) a program to the device under test using a first interface. The program uploaded to the device under test via the first interface configures the device under test (620) to load additional program code and / or data via a second interface for execution by the device under test, the second interface including a higher data rate than the first interface, and The method further includes invalidating the cache (330,529) or cache region before the device under test executes the test case code, which is stored in the shared memory of an automated test device for testing the device under test and loaded into the device under test via the second interface.

32. A computer program product comprising a computer program for performing the method of claim 31 when executed on a computer.

Images