Lockless log and error reporting for automatic test equipment

Abstract

Device test technology includes allocating log memory, testing the device, and storing test results in the allocated log memory during the device test. The allocated log memory can be accessed via an Application Programming Interface (API) during the device test, and the allocated log memory is kept unlocked during the device test.

Description

Background Technology

[0001] Cross-reference regarding related applications

[0002] This application claims the benefit of U.S. provisional patent application No. 63 / 429,061 filed November 30, 2022 and U.S. provisional patent application No. 63 / 440,373 filed January 20, 2023, all of which are incorporated herein in their entirety.

[0003] Background of the Invention

[0004] Automatic test equipment (ATE) is a device used to perform tests on devices under test (DUT), such as electronic systems and components. An ATE may include multiple instruments capable of performing automatic testing, performance characterization, and fault diagnosis.

[0005] An ATE may include a host device tester (also referred to as a controller), one or more source and capture devices, which are coupled to one or more DUTs by one or more load boards (also referred to as primitives, handlers, or probes). The host device tester, which may be a computer, typically synchronizes one or more source and capture devices. Generally, the ATE logs data and provides error reporting. However, existing data logging techniques require locking log memory before clearing, disabling, or returning logs to the user for analysis or display. Existing solutions may also require multiple log memories. Solutions that involve locking log memory before accessing, clearing, or modifying logs typically require a large amount of memory, and testing or other functions may be delayed until the log lock is released. This results in significant additional overhead and can degrade test and / or debug performance. Furthermore, existing logs are typically stored in the operating system kernel space, which means users cannot easily access them to write directly to the logs. Waiting until the test is completed to access or modify log memory can significantly reduce test efficiency. Therefore, there is a continuous demand for improved logging and error reporting technologies for ATE. [Prior Art] Taiwan Patent Publication No. 202202865 (Published Jan. 16, 2022)

[0006] The present technology is best understood by referring to the attached drawings and the following description used to explain embodiments of the present technology regarding lock-free logging and error reporting for automated test equipment (ATE).

[0007] In one embodiment, a method for testing one or more devices under test (DUTs) includes the step of pre-allocating log memory to store test results of one or more DUTs. After allocating the log memory, a test program is executed to test one or more DUTs. During the test of one or more DUTs, a command to access the log memory may be issued using an application programming interface (API), and the log memory is kept unlocked during the test of one or more DUTs. The log memory may be allocated from user-space memory. The log memory may be allocated from a Linux kernel module that provides a user-space API configured to access entries stored in the log memory. In one implementation, the allocated log memory may store 2048 entries. The API may include a command to clear the log memory, a command to read an entry from the log memory, a command to return an entry from the log memory to the user, and a command to disable logging for the log memory.

[0008] In another embodiment, the ATE architecture may include a host device tester. The host device tester may include a user application space, an operating system kernel space, and a tester application. The operating system kernel space may be configured to load a log driver module and a DUT driver module into the user application space and to allocate log memory for the log driver module. The DUT driver module provides for transmitting test parameters and test results for the DUT to the allocated log memory of the log driver module via a log API. The tester application may be configured to enable, disable, dump, and clear log data for the allocated log memory of the log driver module via a log API. The allocated log memory is kept unlocked during the test of the DUT.

[0009] In another embodiment, a method for testing one or more devices may include the step of allocating log memory. After allocating log memory, one or more devices may be tested. During the test, test results may be stored in the allocated log memory. Additionally, the allocated memory may be accessed via an API during the test of one or more devices, and the allocated log memory is kept unlocked during the test of one or more devices.

[0010] This overview is provided to introduce, in a simplified form, the selection of concepts further explained in the detailed description below. This overview is not intended to identify the primary or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Brief explanation of the drawing

[0011] Embodiments of the present technology are illustrated as examples, not limitations, in the attached drawings where similar reference numbers refer to similar elements. FIG. 1 illustrates an automatic test equipment (ATE) architecture according to an embodiment of the present technology. FIG. 2 illustrates an ATE architecture according to an embodiment of the present technology. FIG. 3 illustrates a method for logging test results and accessing test results during testing of a device under test (DUT) according to an embodiment of the present technology. Specific details for implementing the invention

[0012] Now, embodiments of the present technology will be referred to in detail, examples of which are illustrated in the accompanying drawings. The present technology will be described in relation to these embodiments, but it will be understood that the present technology is not intended to be limited to these embodiments. Rather, the present technology is intended to cover alternatives, modifications, and equivalents that may be included within the scope of the present technology as defined by the appended claims. Furthermore, in the following detailed description of the present technology, many specific details are presented to provide a complete understanding of the present technology. However, it is understood that the present technology may be practiced without these specific details. In other cases, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present technology.

[0013] Some embodiments of the present technology are presented below in terms of routines, modules, logic blocks, and other symbolic representations of operations on data within one or more electronic devices. Descriptions and representations are means used by those skilled in the art to most effectively convey the content of their work to others skilled in the art. In this specification, routines, modules, logic blocks, etc. are generally considered to be a consistent sequence of processes or instructions that produce a desired result. A process involves the physical manipulation of a physical quantity. Although not necessarily, such physical manipulation generally takes the form of electrical or magnetic signals that can be stored, transmitted, compared, and manipulated in electronic devices. For convenience and in relation to common usage, these signals are referred to as data, bits, values, elements, symbols, characters, terms, numbers, strings, etc. in relation to embodiments of the present technology.

[0014] However, it should be kept in mind that these terms are to be interpreted as referring to physical operations and quantities, are merely convenient notations, and should also be interpreted in consideration of terms commonly used in the art. As will be evident in the following discussion, unless otherwise specifically stated, discussions regarding this technology using terms such as "reception" are understood to refer to the operations and processes of electronic devices, such as electronic computing devices, that manipulate and transform data. Data is represented as a physical (e.g., electronic) quantity within the logic circuits, registers, memory, etc., of an electronic device, and is transformed into other data that is similarly represented as a physical quantity within the electronic device.

[0015] In this application, the use of disjunctives is intended to include conjunctives. The use of definite or indefinite articles is not intended to indicate cardinality. In particular, references to “the” object or “a” object are intended to refer to one of a possible plurality of such objects. The use of terms such as “includes,” “comprising,” etc., specifies the presence of the mentioned element but does not exclude the presence or addition of one or more other elements and / or groups thereof. Furthermore, it should be understood that while terms such as first, second, etc. may be used in this specification to describe various elements, these elements should not be limited by these terms. In this specification, these terms are used to distinguish one element from another. For example, without departing from the scope of the embodiments, the first component may be referred to as the second component, and similarly, the second component may be referred to as the first component. Furthermore, it should be understood that where it is stated that an element is "combined" with another element, this may mean that it is connected directly or indirectly to the other element, or that an intermediary element may be present. Conversely, where it is stated that an element is "directly combined" with another element, no intermediary element is present. Additionally, the term "and / or" should be understood to include any and all combinations of one or more of the associated elements. Furthermore, it should be understood that the language and terminology used herein are for illustrative purposes only and should not be construed as limiting.

[0016] Now, referring to FIG. 1, an automatic test equipment (ATE) architecture according to an embodiment of the present technology is illustrated. The ATE architecture includes a tester (110) coupled to one or more load boards (120). The load boards (120) are also referred to as primitives, handlers, or probes. In one implementation, the host device may be implemented by one or more computers running a Linux or Windows operating system (OS), or other combination of computing devices and operating systems, that does not support odd sector size or non-standard sector size memory access. One or more DUTs (140-1, 140-2, 140-n) may be represented as block devices through a Linux or Windows block layer. The host device of the tester (110) may be communicably coupled to one or more load boards (120) by a first communication protocol interface, such as PCIe (peripheral component interface express). One or more devices under test (DUT) (140-1, 140-2, 140-n) may be communicably coupled to one or more load boards (120) by a second communication protocol interface, such as a serial attachment small computer system interface (SAS). In one implementation, the second communication protocol interface may be a SAS4 interface.

[0017] In one implementation, a test application in user space (170) generates commands and test patterns of a test program to test one or more aspects of one or more DUTs. An operating system (160) of a host device of a tester (100) can transmit the commands and test patterns to one or more load boards (120). In another implementation, one or more load boards (120) can generate one or more test patterns for corresponding commands of the test program. One or more load boards (120) can control the execution of commands and test patterns for one or more DUTs to perform corresponding tests of the DUTs. One or more load boards (120) can also provide one or more functions for testing the DUTs (140-1, 140-2, 140-n). For example, the load board (120) can provide a function to compare test results received from one or more DUTs with expected result data in response to the test program. In one implementation, the function of one or more load boards (120) may be implemented by one or more field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc. One or more FPGA or ASIC-implemented load boards (120) may provide a SAS4 protocol interface for communication with one or more DUTs (140-1, 140-2, 140-n). The use of one or more load boards (120) reduces the load on the processor(s) (150) of the host device of the tester (110). For example, one or more processors (150) of the host device tester may transmit commands and test patterns to one or more processors (150). One or more load boards (120) may apply test patterns to each DUT (140-1, 140-2, 140-n) according to the commands.One or more load boards (120) may return only result data related to the detected failure in response to the test pattern applied to each DUT (140-1, 140-2, 140-n), instead of returning all data to the processor (150) of the host device of the tester (110).

[0018] In one implementation, one or more load boards (120) may be PCIe (peripheral component interface express) boards. The ATE architecture may also include one or more host bus adapters (HBAs) (130-1, 103-m) coupled between one or more DUTs (140-1, 140-2, 140-n) and one or more load boards (120). In one implementation, one or more HBAs may provide communication between one or more load boards (120) and one or more DUTs (140-1, 140-2, 140-n) using a second communication interface, such as one or more SAS communication protocol interfaces. In one implementation, the HBA (130-1, 130-m) may be a commodity third-party HBA. As used in this specification, a third party refers to a manufacturing entity of the tester (110) and / or load board (120) or one or more manufacturing entities different from the entities.

[0019] In one implementation, first and second communication protocol interfaces may be programmed into one or more HBAs (130-1, 130-m) along with conversions between the first and second communication protocol interfaces. Thus, one or more HBAs (130-1, 130-m) may be reconfigured to support multiple different first and second communication protocol interfaces. In another implementation, one or more HBAs (130-1, 130-m) may implement a specific set of first and second communication protocol interfaces along with conversions between the first and second communication protocol interfaces. If a different set of communication protocol interfaces is required along with conversions between them, the HBA implementing the first and second communication protocol interfaces and the conversions between them may be replaced with a different HBA implementing a different set of communication protocol interfaces and the conversions between them. Additionally, one or more HBAs may use a log driver module, enable communication protocol interface commands, and return logging. For example, a SAS communication protocol driver may use a log driver module, enable SAS communication protocol commands, and return logs. Communication protocol commands issued during testing and returned results may be extracted and analyzed by a user. The host device tester (110) may provide lock-free data logging and error reporting. In one embodiment, a log memory for storing test results may be pre-allocated.

[0020] The tester (110) may include additional modules, components, subsystems, etc., but are not described here because they are not necessary to understand the aspects of the technology. Similarly, the ATE architecture may also include additional modules, components, subsystems, etc., but are not described here because they are not necessary to understand the aspects of the technology.

[0021] The operation of the ATE will be further described with reference to FIG. 2, which illustrates additional aspects of the ATE architecture. The ATE architecture may include a host device tester (210) coupled to one or more DUTs (220). In one implementation, the host device tester (210) may be coupled to one or more DUTs (220) by one or more load boards (not shown), by one or more load boards and one or more HBAs, or by any similar configuration. The host device tester (210) may implement one or more log driver modules (230), one or more DUT driver modules (240), and one or more tester applications (250) as software, firmware, hardware, or any combination thereof running on one or more processors. Log memory (260) may be allocated by the log driver module (230), operating system driver module, etc.

[0022] The operation of the ATE will be further described with reference to Fig. 3, which illustrates a method for logging test results and accessing test results during testing of one or more DUTs. This method may include the step of allocating log memory in 310. Log memory may be pre-allocated for each DUT to be tested. Log memory may be allocated in an operating system driver module. For example, log memory may be allocated in a Linux operating system driver module. For example, log memory may be divided into 2048 or more entries depending on the amount of allocated memory and the entry size. In one implementation, log memory may be allocated as a 256 KB (kilobyte) circular buffer of 2048 entries or any other selected number of entries, with each entry being 128 bytes in size. In most cases, a single log memory is sufficient for one DUT. Alternatively, one log memory may be allocated per queue. For an implementation testing 16 DUTs, 16 log memories may be allocated, where the log memory for each DUT being tested can be 1 MB (megabyte). An operating system kernel module may provide user-space log APIs to access entries stored in log memory. Depending on the log API, functions such as clearing log memory, reading entries from log memory, returning log entries to the user for analysis or display, and disabling logging to enable maximum test performance may be supported. Log memory can also advertise to the storage block device kernel module to write information to log memory via the corresponding kernel module. In 320, one or more devices may be tested. In 330, test results may be stored in the allocated log memory during the testing of one or more devices.Commands submitted to the DUT and data returned from the DUT can be logged in log memory. In one implementation, only test failure results are logged in the allocated log memory. In another implementation, all DUT test parameters and results are logged in the allocated log memory. In the 340, the allocated log memory can be accessed via API during the testing of one or more devices, and the allocated log memory remains unlocked during the testing of one or more devices. In most cases, command submissions to the log memory and dates returned / retrieved from the log memory are used for debugging purposes. Accessing the log memory in this manner reduces the necessary associated overhead because there is no lock.

[0023] Unlike Linux or Windows tracing, which captures commands and data from all DUTs along with all other software running on the host tester device, the log driver can store commands and data for each individual DUT in separate logs assigned to each device being tested.

[0024] An embodiment of the present technology advantageously provides a low-overhead solution for logging and error reporting without the need to lock log memory before accessing or modifying logs.

[0025] The foregoing description of specific embodiments of the present technology is provided for illustrative and illustrative purposes only. It is not intended to be comprehensive or to limit the present technology to the exact form disclosed, and it is evident that many modifications and changes are possible in light of the foregoing teachings. The embodiments have been selected and described to best illustrate the principles of the present technology and its practical applications, thereby enabling those skilled in the art to make the best use of the present technology and various embodiments through various modifications suitable for the specific use being considered. The scope of the present invention is intended to be defined by the claims appended to this specification and their equivalents.

Claims

Claim 1 A method for testing a device under test (DUT) by a host device tester, comprising the steps of pre-allocating a log memory for storing test results of the DUT, executing a test program to test the DUT, and issuing a command to access the log memory using an application programming interface (API) during the test of the DUT, wherein the log memory is kept unlocked during the test of the DUT, while test result data is stored in the log memory, and while the test result data is accessed using the API. Claim 2 A method according to claim 1, wherein the step of pre-allocating a log memory for storing test results of the DUT includes the step of pre-allocating the log memory in user space memory. Claim 3 A method according to claim 1, wherein the step of pre-allocating a log memory for storing test results of the DUT comprises the step of pre-allocating the log memory in a Linux kernel module that provides a user space API configured to access entries stored in the log memory. Claim 4 A method according to claim 1, wherein the log memory is configured to store 2048 entries. Claim 5 A method according to claim 1, wherein the log memory includes a circular buffer. Claim 6 A method according to claim 1, wherein the API comprises at least one of a command to clear the log memory, a command to read an entry from the log memory, a command to return an entry from the log memory to a user, and a command to disable logging for the log memory. Claim 7 An Automatic Test Equipment (ATE) architecture, wherein the Automatic Test Equipment architecture comprises a host device tester connected to a device under test (DUT), and the host device tester comprises a user application space and an operating system kernel space that loads a log driver module and a device under test (DUT) driver module into the user application space and allocates a log memory for the log driver module—the DUT driver module provides to transmit test parameters and test results for the DUT to the allocated log memory of the log driver module during the test of the DUT via a write application programming interface (API)—and a tester application for enabling, disabling, dumping, and clearing log data for the allocated log memory of the log driver module during the test of the DUT via a log API, wherein the allocated log memory is kept unlocked during the test of the DUT. Claim 8 In claim 7, the ATE architecture wherein the allocated log memory contains 2048 or more entries. Claim 9 In claim 7, the ATE architecture wherein the allocated log memory includes a circular buffer of 256 KB (kilobyte) or more. Claim 10 In claim 7, the ATE architecture in which test failure data is logged in the allocated log memory by the DUT driver module. Claim 11 In claim 7, the ATE architecture in which the most recent test parameters are logged in the allocated log memory by the DUT driver module. Claim 12 In claim 7, the ATE architecture wherein the log API advertises to the record API to write information to the allocated log memory through the DUT driver module. Claim 13 An ATE architecture according to claim 7, wherein the log API can provide clearing the allocated log memory, reading an entry from the allocated log memory, returning an entry from the allocated log memory, and disabling logging in the allocated log memory. Claim 14 In claim 7, the ATE architecture wherein the host device tester is communicably coupled to the DUT by a load board. Claim 15 In claim 14, the load board and the host device tester communicate using a first communication interface, and the load board includes a host bus adapter configured to provide communication between the load board and the DUT using a second communication interface and to convert commands and data between the first communication interface and the second communication interface, an ATE architecture. Claim 16 A method for testing a device under test (DUT) by a host device tester, comprising the steps of allocating a log memory, testing the DUT, storing test results during the test of the DUT in the allocated log memory, and accessing the allocated log memory through an application programming interface (API) during the test of the DUT, wherein the allocated log memory is kept unlocked during the test of the DUT. Claim 17 A method according to claim 16, wherein the step of accessing the allocated log memory comprises one or more of clearing the allocated log memory, reading an entry from the allocated log memory, returning an entry from the allocated log memory, and disabling logging in the allocated log memory. Claim 18 In paragraph 16, the method wherein the log memory is configured to store 2048 entries in a 256 KB (kilobyte) circular buffer. Claim 19 A method in which the log memory is allocated for each DUT being tested in paragraph 16. Claim 20 A method according to claim 16, wherein the log memory is allocated to each queue of the DUT being tested.

Images