Communication logic to enhance region effectiveness for memory repair mechanisms

Abstract

The invention relates to communication logic to enhance regional effectiveness for memory repair mechanisms. According to an embodiment, a method for testing and repairing local memory in a hardware accelerator from a one-time programmable memory (OTP) is provided. The method includes asserting an authorization signal, loading first repair data from a first partition of the OTP memory for a subset of local memory associated with the master controller, transmitting a status signal indicating completion of the loading after the loading is completed, and de-asserting the authorization signal in response to receiving the status signal.

Description

Technical Field

[0001] The present disclosure relates generally to design for test (DFT) and, in particular embodiments, to an improved system architecture for testing and repairing memory. Background Art

[0002] Hardware accelerators, such as graphics processing units (GPUs), field programmable gate arrays (FPGAs), and application-specific integrated circuits (ASICs), are specialized hardware devices designed to perform specific tasks more efficiently than traditional general-purpose processors. The use of hardware accelerators in machine learning and artificial intelligence has become increasingly important as the size of datasets and the complexity of models have increased, resulting in an increase in both memory count and memory spread across system-on-chip (SoCs).

[0003] In the field of AI and machine learning, hardware accelerators can speed up the computationally intensive tasks involved in training and reasoning machine learning models. By offloading computations to specialized hardware, machine learning algorithms can be trained and deployed faster and more efficiently, resulting in better performance and faster time to market for AI-based products and services.

[0004] Generally speaking, hardware accelerators require a lot of memory space to operate effectively and require the storage of large amounts of data, such as training data sets, model parameters, and intermediate computational results. As a result, the memory in hardware accelerators is becoming more and more complex, requiring more memory channels and higher memory bandwidth to support the growing demands of machine learning and AI workloads. In addition, as the size of workloads continues to grow, the amount of memory required to support them also increases.

[0005] Traditionally, a hierarchical approach is used to test and repair memories, which simplifies the memory repair process by abstracting the details of the underlying memory subsystem and providing standardized interfaces for error detection and correction. In the hierarchical approach, the memory subsystem is divided into multiple abstraction levels, each with its own set of tests and wrappers. The top-level wrapper interfaces with the external environment and generates test patterns for the lower-level wrappers. The lower-level wrappers verify the functionality and performance of the memory at their corresponding abstraction level and provide feedback to the top-level wrapper.

[0006] Conventionally, loading instructions through the test access point (TAP) and communicating with the one-time programmable (OTP) memory is done through a top master controller / sub-controller system architecture in a hierarchical approach. Due to synthesis constraints and multiple processing cores, multiple controllers are used in artificial intelligence and machine learning applications, requiring dedicated OTP memory for each system. However, each system does not necessarily use the entire OTP memory space to store repair data, which results in memory waste.

[0007] The memory test processor calculates a repair signature based on the memory fault location to repair the memory using a hierarchical approach. The repair signature is stored in the OTP memory during manufacturing test. In the field, during the power-on sequence, the repair signature is read from the OTP memory and loaded into the memory repair signature register.

[0008] Therefore, improved system architectures are desired for testing and repairing memory. Summary of the invention

[0009] Technical advantages are generally achieved by embodiments of the present disclosure, which describe an improved system architecture for testing and repairing memory.

[0010] A first aspect relates to a system for testing and repairing a local memory in a hardware accelerator. The system includes a one-time programmable (OTP) memory, an OTP sequencer circuit, a first master controller, a second master controller, and an offset addition and selection logic circuit. The one-time programmable (OTP) memory is configured to store first repair data in a first partition and store second repair data in a second partition in sequence for a first subset of local memory and a second subset of local memory, respectively. The OTP sequencer circuit is configured to assert a first authorization signal. The first master controller is coupled to the OTP sequencer circuit and the first subset of local memory. The first master controller is configured to load first repair data for the first subset of local memory from the first partition for the first time, and transmit a first status signal indicating that the first load is completed to the OTP sequencer circuit after the first load is completed. The OTP sequencer circuit is also configured to de-assert the first authorization signal in response to the OTP sequencer circuit receiving the first status signal and assert the second authorization signal in response to the de-assertion of the first authorization signal. The offset addition and selection logic circuit is configured to add an offset to an address used by the second master controller to access the second partition. The second master controller is configured to load second repair data for a second subset of the local memory associated with the second master controller from the second partition for a second time using the address for accessing the second partition, and transmit a second status signal indicating completion of the second loading to the OTP sequencer circuit after the second loading is completed. The OTP sequencer circuit is further configured to de-assert the second grant signal in response to the OTP sequencer circuit receiving the second status signal.

[0011] A second aspect relates to a method for testing and repairing a local memory in a hardware accelerator from a one-time programmable memory (OTP). The method includes: asserting a first authorization signal by a one-time programmable (OTP) sequencer circuit; loading, by a first master controller, first repair data for a first subset of a local memory associated with the first master controller from a first partition of the OTP memory for the first time; transmitting, by the first master controller, a first status signal indicating completion of the first loading to the OTP sequencer circuit after the first loading is completed; de-asserting the first authorization signal by the OTP sequencer circuit in response to the OTP sequencer circuit receiving the first status signal; asserting a second authorization signal by the OTP sequencer circuit in response to de-assertion of the first authorization signal; and adding, by an offset adding and selecting logic circuit, an offset adding signal. an address added to a second partition of the OTP memory used by the second master controller to access the second partition, wherein the first repair data and the second repair data are sequentially loaded into the OTP memory; second repair data for a second subset of the local memory associated with the second master controller is loaded from the second partition of the OTP memory for a second time using the address for accessing the second partition; a second status signal indicating completion of the second load is transmitted to the OTP sequencer circuit by the second master controller after the second load is completed; and a second grant signal is deasserted by the OTP sequencer circuit in response to the OTP sequencer circuit receiving the second status signal.

[0012] A third aspect relates to a system for testing and repairing a local memory in a hardware accelerator. The system includes a one-time programmable (OTP) memory, a test control register (TCR), a first master controller, a second master controller, and an offset addition and selection logic circuit. The OTP memory is configured to sequentially store first repair data in a first partition and second repair data in a second partition for a first subset of the local memory and a second subset of the local memory, respectively. The TCR is configured to assert a first authorization signal. The first master controller is coupled to the first subset of the local memory, and the first master controller is configured to load first repair data for the first subset of the local memory from the first partition for the first time in response to the first authorization signal being asserted. The offset addition and selection logic circuit is coupled to the TCR and the first master controller. The offset addition and selection logic circuit is configured to add an offset to an address used by the second master controller to access the second partition. The TCR is also configured to de-assert the first authorization signal and assert the second authorization signal in response to the de-assertion of the first authorization signal. The second master controller is configured to load second repair data for a second subset of local memory associated with the second master controller from the second partition a second time using the address to access the second partition in response to the second grant signal being asserted, wherein the TCR is further configured to deassert the second grant signal.

[0013] Embodiments may be implemented in hardware, software, or any combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0015] Figure 1 is a block diagram of an embodiment hardware accelerator;

[0016] Figure 2 , Figure 3 and Figure 4 They are simplified block diagrams of conventional test design (DFT) subsystems, systems, and multi-systems based on a hierarchical approach;

[0017] Figure 5 is a simplified block diagram of a multi-system of an embodiment;

[0018] Figure 6 is a partition of an embodiment OTP memory;

[0019] Figure 7 is a block diagram of an embodiment design of a system;

[0020] Figure 8 and Fig. 9 They are Figure 7 An embodiment timing diagram and corresponding method of the system in operating in a functional mode; and

[0021] Fig.10 and Fig.11 They are Figure 7 An embodiment timing diagram and corresponding method of the system operating in test mode. DETAILED DESCRIPTION

[0022] The present disclosure provides a plurality of applicable inventive concepts that can be implemented in a variety of specific contexts. Specific embodiments only illustrate specific configurations and do not limit the scope of the claimed embodiments. Unless otherwise stated, features from different embodiments can be combined to form additional embodiments.

[0023] The changes or modifications described in one of the embodiments may also be applied to other embodiments. In addition, various changes, substitutions and alterations may be made herein without departing from the spirit and scope of the present disclosure as defined by the appended claims.

[0024] Although the inventive aspects are primarily described in the context of hardware accelerators used in artificial intelligence or machine learning applications, it should also be appreciated that these inventive aspects may also be applied to other applications that benefit from efficient, compact, and optimized test design schemes.

[0025] Figure 1A block diagram of an embodiment hardware accelerator 100 is illustrated. As shown, the hardware accelerator 100 includes a plurality of interconnected cores 102 (i.e., logic blocks), which provide a compact, efficient, flexible, and scalable solution, thereby enabling various functionalities to be integrated into a single chip. In an embodiment, each core 102 includes a large number of gates 104, a processing unit (PU) 106, and a local memory (LM) 108, which may (or may not) be arranged as shown. In addition, the hardware accelerator 100 may include additional components not shown. It should be noted that the number of cores 102, gates 104, processing units 106, and local memories 108 is non-limiting.

[0026] In an embodiment, the hardware accelerator 100 is integrated into an artificial intelligence or machine learning system to process large calculations in a distributed manner. The combination of a parallel architecture, a large number of processing units, distributed on-chip memory, and optimized interconnectivity allows the hardware accelerator 100 to achieve high throughput, efficiently process large amounts of data, and perform fast, complex calculations.

[0027] Each core 102 may include multiple gates 104, allowing for complex designs and integration of numerous functional units and features. In an embodiment, a hardware accelerator 100 may include cores 102. Cores 102 may represent different functional units or subsystems, such as a central processing unit (CPU), a graphics processing unit (GPU), peripherals, or custom IP blocks.

[0028] Furthermore, the hardware accelerator 100 may include a large number of interconnected processing units 106 that operate in parallel, for example, to perform computations on one or more problem sets simultaneously. The processing units 106 typically include CPU cores, GPUs, custom accelerators, or a combination thereof, which may be highly specialized and optimized to perform specific tasks and perform high throughput operations.

[0029] The hardware accelerator 100 includes a plurality of distributed on-chip local memories 108 to facilitate low-latency operations on localized data. Generally, the local memories 108 are located close to the processing units 106 to minimize latency and enable fast data sharing between the processing units 106. The local memories 108 can be of different types, such as RAM (random access memory), ROM (read-only memory), or other specialized memory technologies.

[0030] The local memory 108 provides storage and data access for specific functions performed by the corresponding core 102. Integrating the local memory 108 into each core 102 is beneficial to allow faster and more efficient data access because the local memory 108 is closer to the processing unit 106. In addition, the integration also enables the customization and optimization of memory resources based on the specific requirements of each core 102. Different cores 102 can have different memory capacities, types, or architectures tailored to their needs. In addition, having the core 102 have its own dedicated local memory 108 promotes modularity and scalability of the system design. Each core 102 can operate independently, access and manage its associated local memory 108 without interfering with other cores. This modularity allows the development, testing, and maintenance of various components within the hardware accelerator 100 to be easier.

[0031] The processing units 106 and local memory 108 (and optionally other components of the core 102) are typically interconnected using a highly optimized network, called a network-on-chip (NoC) 110. The network-on-chip 110 provides an efficient communication channel and high-bandwidth data transfer between the processing units 106, local memory 108, gates 104, and other components of the hardware accelerator 100.

[0032] As described above, traditionally, a hierarchical approach is used to test and repair memory by abstracting the details of the underlying memory subsystem and providing standardized interfaces such as for error detection and correction. To achieve reasonable test time, the entire set of cores 102 of the hardware accelerator 100 is divided into smaller subsets and a multi-level hierarchy.

[0033] Figure 2 , Figure 3 and Figure 4 Simplified block diagrams of conventional design for test (DFT) subsystem 200, system 300, and multisystem 400 based on a hierarchical approach are illustrated, respectively. Thus, subsystem 200 is used to test lower level blocks of the hierarchy, system 300 is used to test multiple subsystems 200, and multisystem 400 is used to test multiple systems 300.

[0034] In an embodiment, subsystem 200 may include multiple cores 102. Figure 2 As shown in , subsystem 200 includes subcontroller 202, multiple memory test processors 204, and multiple local memories 108, which may (or may not) be arranged as shown. Subsystem 200 may include additional components not shown. There is no limit to the number of components associated with subsystem 200.

[0035] Each local memory 108 is wrapped within a separate wrapper 206. Each wrapper 206 is associated with and coupled to a memory test processor 204. In an embodiment, each wrapper 206 includes a plurality of local memories 108. In some embodiments, a plurality of wrappers 206 are associated with and coupled to a memory test processor 204. In an embodiment, a memory test processor 204 is a processing unit 106 of a core 102 associated with a local memory 108. Each memory test processor 204 is configured to test a local memory 108 associated with the wrapper 206. A subcontroller 202 is added to the core 102 and coupled to each memory test processor 204 within the subsystem 200.

[0036] In an embodiment, the system 300 may include multiple subsystems 200 coupled to a main controller 302, which are added to the hardware accelerator 100. The system 300 may (or may not) be arranged as shown, and may include additional components not shown. In an embodiment, the main controller 302 is coupled to a test access point (TAP) 304 and a one-time programmable (OTP) memory 306. The main controller 302 is configured to allow the subsystems 200 to communicate with the common TAP 304. There is no limit to the number of components associated with the system 300.

[0037] TAP 304, or boundary scan, tests and diagnoses digital circuits, including memory subsystems. It generally involves adding dedicated test logic to the circuit that can be used to access and control individual device pins, thereby enabling testing of internal signals and detection of faults in the circuit. In memory testing and repair, TAP 304 can access individual memory cells and perform various diagnostic tests, such as read / write, bit-by-bit comparison, and pattern testing. It can also detect and isolate faults in the memory subsystem.

[0038] OTP memory 306 is a type of non-volatile memory that can be programmed only once during manufacturing and retains its value indefinitely. In the context of memory test and repair, OTP memory 306 can store configuration and repair data used during the memory test and repair process.

[0039] For example, a memory test and repair system may use OTP memory 306 to store a repair map that identifies faulty memory cells and their replacement values. During testing, the system may read the repair map from OTP memory 306 and use it to replace the faulty memory cells with the correct values ​​stored in OTP memory 306. OTP memory 306 may also store configuration data, such as test modes, timing parameters, and other settings used during testing and repair. Thus, TAP 304 enables testing and diagnostics of the memory subsystem, while OTP memory 306 provides a reliable and non-volatile storage solution for configuration and repair of data.

[0040] For example, in a system 300 in which the number of subsystems 200 is equal to one, the subsystem 200 is coupled to a 256-word OTP memory 306 through the main controller 302. In this example, repair data for a first local memory 108 of the subsystem 200 is stored in the first word of the OTP memory 306, repair data for a second local memory 108 of the subsystem 200 is stored in the second word of the OTP memory 306, and so on. In this example, the number of local memories 108 of the subsystem 200 is less than 256 (e.g., thirty-two). Therefore, the OTP memory 306 includes a large amount of memory space that is wasted due to inefficient communication between the OTP memory 306 and the main controller 302.

[0041] Typically, in a system-on-chip that is not used in intelligent learning or machine learning applications, during manufacturing (i.e., production), instructions are loaded from the TAP 304 into the memory test processor 204 to test and repair the local memory 108. During the repair process, the repair signature is calculated and stored in the OTP memory 306. Loading instructions from the TAP 304 and communicating with the OTP memory 306 are accomplished using the subsystem 200 and system 300 DFT architectures. As the number of cores 102 in the hardware accelerators 100 used in artificial intelligence and machine learning applications increases, the design of the test architecture has been extended to include higher-level blocks above the system 300, referred to as the multi-system 400.

[0042] In an embodiment, multi-system 400 may include multiple systems 300, where each system 300 is coupled to a respective dedicated OTP memory 402. Multi-system 400 may (or may not) be arranged as shown, and may include additional components not shown.

[0043] Disadvantageously, each system 300 coupled to a corresponding OTP memory 402 does not utilize the entire memory space of the corresponding OTP memory 402 for data storage repair. Therefore, the use of a dedicated OTP memory 402 for each system 300 results in wasted and unused space in each OTP memory 402, which, when multiplied by the number of systems 300 in the multi-system 400, results in a large amount of wasted memory space that could otherwise be used for other purposes.

[0044] For example, in a multi-system 400 where the number of systems 300 is equal to two, each system 300 is coupled to a respective OTP memory 402 of 256 words through a respective master controller 302. In this example, repair data for the set of local memories 108 of the first system 300 is stored in the first OTP memory 402, and repair data for the set of local memories 108 of the second system 300 is stored in the second OTP memory 402.

[0045] In addition, repair data of the first local memory 108 in the set of local memories 108 for the first system 300 is stored in the first word of the first OTP memory 402, repair data of the second local memory 108 in the set of local memories 108 for the first system 300 is stored in the second word of the OTP memory 402, and so on.

[0046] Furthermore, repair data of the first local memory 108 in the set of local memories 108 for the second system 300 is stored in the first word of the second OTP memory 402, repair data of the second local memory 108 in the set of local memories 108 for the second system 300 is stored in the second word of the OTP memory 402, and so on.

[0047] In this example, the number of local memories 108 is less than 256. For example, the number of local memories 108 in the set of local memories 108 of the first system 300 is thirty-two, and the number of local memories 108 in the set of local memories 108 of the second system 300 is twenty. Therefore, in the multi-system 400, each OTP memory 402 includes a large amount of memory space, which is wasted due to the inefficiency of communication between the OTP memory 402 and the main controller 302. In addition, it can be observed that as the size of the local memory 108 increases in, for example, artificial intelligence and machine learning systems, the use of a dedicated OTP memory 402 for each system 300 results in a significant waste of memory space, resulting in poor memory utilization of the system.

[0048] To address this issue, some test design architectures include different controllers (e.g., main controller 302) for repairable and non-repairable memories. Unfortunately, this solution is limited to two controllers. Core 102 may contain both repairable and non-repairable memories, resulting in complex timing closure and increased spatial memory streaming (SMS) logic for each system block.

[0049] Embodiments of the present disclosure provide an improved test design architecture for testing and repairing memory (e.g., local memory 108) that addresses deficiencies in existing solutions. In an embodiment, a single OTP memory is coupled to multiple systems in a multi-system to improve the efficient use of OTP memory space in a hardware accelerator. Communication logic circuits are coupled between a single OTP memory and multiple systems, which allows each main controller 302 to communicate with a single OTP memory. Various aspects of the present disclosure provide a test design method for an on-chip system used in artificial intelligence or machine learning technology (such as automotive applications). Embodiments of the present disclosure are similarly applicable to production (i.e., manufacturing) and functional (i.e., boot mode) testing. These and further details will be discussed in more detail below.

[0050] Figure 5 1 illustrates a simplified block diagram of an embodiment multi-system 500, which may (or may not) be arranged as shown. Figure 4 In contrast to the multi-system 400 in Figure 5 The multi-system 500 in FIG. 5 includes a single OTP memory 502 coupled to each main controller 302 of each system 300 via a communication logic circuit 504. Each main controller 302 is coupled to a plurality of subsystems 200. The multi-system 500 may include additional components not shown, and Figure 5 The number of components shown in is non-limiting.

[0051] In an embodiment, communication logic 504 is configured to allow each host controller 302 to communicate with OTP memory 502. Advantageously, using a single OTP memory 502 for multiple systems 300 allows for more efficient use of memory space compared to conventional test design architectures that include a dedicated OTP memory 402 for each system 300.

[0052] Figure 6The partitioning of the embodiment OTP memory 502 is illustrated. As shown, the OTP memory 502 is partitioned into n different partitions, where n is an integer greater than one - although the OTP memory 502 is shown as including more than two partitions 602, the number of partitions 602 can be less or more and is not limited. In an embodiment, each partition 602 includes associated repair data (i.e., memory repair signature) for a corresponding system 300. In an embodiment, each partition 602 of the OTP memory 502 is dedicated to a different system 300 in the multi-system 500.

[0053] Therefore, embodiments of the present disclosure provide an OTP partitioning scheme and a method for addressing each partition 602 of each system 300 using an offset addition scheme when addressing the OTP memory 502. In an embodiment, repair data for various systems 300 are stored sequentially within the OTP memory 502. Therefore, by utilizing a single OTP memory 502 loaded with sequential repair data, memory space waste in multiple systems 500 is minimized.

[0054] It should be understood that the size of OTP memory 502 and partitions 602 is determined based on, for example, the repair budget and user data of each system 300. Therefore, in some embodiments, the memory space of partitions 602 is the same; in other embodiments, the partition memory space may be different.

[0055] For example, in an OTP memory 502 having four kilobytes of memory space and two partitions dedicated to two systems 300, the first partition 602 may have one kilobyte of memory space and the second partition 602 may have three kilobytes of memory space. As another example, in an OTP memory 502 having four kilobytes of memory space and two partitions dedicated to two systems 300, each of the first partition 602 and the second partition 602 may have two kilobytes of memory space.

[0056] In an embodiment, when the master controller 302 is configured to access the OTP memory 502, the associated offset is added to the address bus. In an embodiment, when the master controller 302 associated with the first partition 602 accesses the OTP memory 502, a null offset (i.e., zero offset) is added to the address bus. In addition, the offset addition scheme can be easily extended to more than two controllers. In an embodiment, adding the offset to the address bus occurs both in the functional mode (i.e., boot mode) and in the test mode.

[0057] Figure 7A block diagram of an embodiment design for a system 700 is illustrated. The system 700 includes an OTP memory 502, an OTP interface circuit 702, an offset logic and selection circuit 704, a test control register (TCR) 716, a first master controller 706a, a second master controller 706b, a first repair controller 708a, a second repair controller 708b, an OTP sequencer circuit 710, a functional logic 712, and an input / output (I / O) multiplexer 714, which may (or may not) be arranged as shown. The system 700 may be used for functional and test mode operations. In an embodiment, the TCR 716 is coupled to the TAP 304 so that the TAP 304 can control the operation of the TCR 716 during the test mode.

[0058] The optional OTP interface circuit 702, which is a logic circuit coupled to the OTP memory 502 and the offset logic and selection circuit 704, provides error correction code and other security features in the system 700. The OTP interface circuit 702 includes a status terminal that is coupled to the I / O multiplexer 714 and is configured to transmit a status signal. In an embodiment, the OTP interface circuit 702 is configured to generate an offset of an address signal based on which the master controller 706a-b communicates with the OTP memory 502.

[0059] Offset logic and selection circuit 704 is coupled to each master controller 706a-b, OTP interface circuit 702, OTP sequencer circuit 710, and TCR 716. Offset logic and selection circuit 704 provides offset addition.

[0060] Although Figure 7 A pair of master controllers 706a-b are included, each coupled to a repair controller 708a-b. However, in an embodiment, the system 700 may include more than two master controllers, each coupled to a corresponding repair controller. Therefore, there is no limit to the number of master controllers and repair controllers.

[0061] Each master controller 706a-b is coupled to a repair controller 708a-b and an offset logic and selection circuit 704. In addition, each master controller 706a-b may include one or more status terminals to exchange corresponding status signals with the OTP sequencer circuit 710, the functional logic 712 of the hardware accelerator 100, and the I / O multiplexer 714. In an embodiment, the master controller 706a-b operates similarly to the master controllers described above. For example, each master controller 706a-b may be as follows: Figure 5 . In an embodiment, each master controller 706a - b is associated with a respective subset of the local memory 108 in the hardware accelerator 100 .

[0062] The OTP sequencer circuit 710 is a logic circuit coupled to the main controller 706a-b, the repair controller 708a-b, and the offset logic and selection circuit 704. In an embodiment, the OTP sequencer circuit 710 includes a reset terminal that is configured to receive a functional mode reset (POR_n) signal 802. In an embodiment, the logic level of the functional mode reset signal 802 indicates whether the hardware accelerator 100 is operating in a functional mode. For example, in response to the functional mode reset signal 802 having a logic level equal to "0", the hardware accelerator has not been booted, and in response to the functional mode reset signal 802 having a logic level equal to "1", the hardware accelerator is running and in a functional mode.

[0063] The OTP sequencer circuit 710 is configured to generate a grant signal during the functional mode operation of the hardware accelerator 100. During the functional mode, the OTP sequencer circuit 710 generates a grant signal for each master controller 706a-b to communicate with the OTP memory 502. For example, in a system including a pair of master controllers 706a-b, Figure 7 In an embodiment of the present invention, the OTP sequencer circuit 710 is configured to generate a first authorization signal 804 for the first master controller 706a and a second authorization signal 808 for the second master controller 706b during the functional mode. In an embodiment, when the first authorization signal 804 is asserted, the second authorization signal 808 is de-asserted. In an embodiment, when the second authorization signal 808 is asserted, the first authorization signal 804 is de-asserted.

[0064] In an embodiment, the OTP sequencer circuit 710 includes dedicated terminals to transmit grant signals (as shown) for each repair controller 708a-b. In an embodiment, the signal terminals of the OTP sequencer circuit 710 may be used to transmit grant signals (not shown) to the repair controllers 708a-b. In other embodiments, other components such as multiplexers may be combined to transmit grant signals from the OTP sequencer circuit 710.

[0065] In an embodiment, a first grant signal 804 is transmitted from the OTP sequencer circuit 710 to the first repair controller 708a and the offset logic and selection circuit 704. In an embodiment, a second grant signal 808 is transmitted from the OTP sequencer circuit 710 to the second repair controller 708b and the offset logic and selection circuit 704.

[0066] The I / O multiplexer 714 is configured to provide a common selection interface between test status and other functional signals transmitted from the host controllers 706 a - b and the OTP interface circuit 702 .

[0067] During functional mode (i.e., when the functional mode reset signal 802 is asserted), the logic level of the grant signal from the OTP sequencer circuit 710 indicates to the repair controller 708a-b which master controller 706a-b is authorized to access the OTP memory 502. The repair controller 708a-b, in response to being authorized to access the OTP memory 502, instructs the master controller 706a-b to load the OTP repair data from the OTP memory 502 using the master controller bus address 812 (e.g., in sequence). The offset logic and selection circuit 704 coupled between the OTP memory 502 and the master controller 706a-b provides the master controller bus address 812 with the appropriate offset to obtain the OTP bus address 814. Therefore, the OTP bus address 814 includes an offset indicating the partition 602 that the master controller 706a-b is to access from the OTP memory 502.

[0068] The TCR 716 is coupled to the offset logic and selection circuit 704. The TCR 716 is configured to generate a grant signal and an access signal 1002 during test mode operation. In an embodiment, the TCR 716 generates the access signal 1002 to indicate operation in the test mode. For example, in response to the access signal 1002 having a logic level equal to "0", the system is in the test mode. In response to the access signal 1002 having a logic level equal to "1", the system is in the test mode.

[0069] During the test mode, the TCR 716 generates corresponding authorization signals for each master controller 706a-b to communicate with the OTP memory 502. For example, in a system including a pair of master controllers 706a-b, Figure 7 In an embodiment, the TCR 716 is configured to generate a first authorization signal 1004 for the first master controller 706a and a second authorization signal 1006 for the second master controller 706b during the test mode. In an embodiment, when the first authorization signal 1004 is asserted, the second authorization signal 1006 is de-asserted. In an embodiment, when the second authorization signal 1006 is asserted, the first authorization signal 1004 is de-asserted.

[0070] During the test mode (i.e., when the access signal 1002 is asserted), the logic level of the grant signal from the TCR 716 indicates which master controller 706a-b is authorized to access the OTP memory 502. In response to being granted access to the OTP memory 502, the coupled system instructs the master controllers 706a-b (e.g., in sequence) to load the OTP repair data from the OTP memory 502 using the master controller bus address 1008. The offset logic and selection circuit 704 coupled between the OTP memory 502 and the master controllers 706a-b provides the master controller bus address 1008 with the appropriate offset to obtain the OTP bus address 1010. Thus, the OTP bus address 1010 includes an offset indicating the partition 602 that the master controller 706a-b is to access from the OTP memory 502.

[0071] Figure 8 and Fig. 9 An example timing diagram 800 and a corresponding method 900 are illustrated, respectively, wherein the system 700 operates in a functional mode. The method begins at step 902, at time t 1 Previously, the functional mode reset (POR_n) signal 802 was de-asserted (eg, logic level low). When the functional mode reset signal 802 was de-asserted, the system had not yet been booted. At step 904, at time t 1 , the functional mode reset signal 802 is asserted (eg, logic level high), and the hardware accelerator 100 enters the boot mode (ie, functional mode).

[0072] At step 906, at time t 2 , the OTP sequencer circuit 710 asserts (e.g., logic level high) the first grant signal 804 for the first master controller 706a and the first repair controller 708a. In response to receiving the first grant signal 804 from the OTP sequencer circuit 710, the first repair controller 708a instructs the first master controller 706a to load the OTP repair data. Since the associated partition 602 for the first master controller 706a starts at address "0", the master controller bus address 812 is the same as the OTP bus address 814 with a null offset. At step 908, at time t 3 With time t 4 Meanwhile, the first master controller 706 a loads the OTP repair data from the first partition 602 of the OTP memory 502 based on the OTP bus address 814 , and de-asserts (eg, logic level low) the first state signal 806 .

[0073] At step 910, at time t 4After the OTP repair data is loaded from the first partition 602 of the OTP memory 502 by the first host controller 706 a , the first status signal 806 is asserted (eg, logic level high).

[0074] In response, at step 912 and at time t 5 , the OTP sequencer circuit 710 asserts (e.g., logic level high) the second grant signal 808 for the second master controller 706b and deasserts (e.g., logic level high) the first grant signal 804 for the first master controller 706a. In addition, the repair controller 708 instructs the second master controller 706b to load the OTP repair data. However, during this sequence, the offset logic and selection circuit 704 adds the offset to the master controller bus address 812 to generate the OTP bus address 814 from which the OTP repair data is loaded (i.e., the second partition 602). Therefore, the OTP bus address 814 points to the second partition 602 in the OTP memory 502.

[0075] At step 914, at time t 6 With time t 7 Meanwhile, the second master controller 706 b extracts the OTP repair data from the second partition 602 of the OTP memory 502 based on the OTP bus address 814 , and de-asserts (eg, logic level low) the second state signal 810 .

[0076] At step 916, at time t 8 After the second master controller 706b completes loading the OTP repair data from the second partition 602 of the OTP memory 502, the second status signal 810 is asserted (e.g., logic level high). At step 918, the OTP sequencer circuit 710 deasserts (e.g., logic level high) the second grant signal 808 for the second master controller 706b.

[0077] Fig.10 and Fig.11 An example timing diagram 1000 and a corresponding method 1100 are illustrated, respectively, in which the system 700 operates in a test mode. The method begins at step 1102, at time t 1 Previously, access signal 1002 was de-asserted (eg, logic level low). When access signal 1002 was de-asserted, hardware accelerator 100 was not yet in test mode. At step 1104, at time t 1 , access signal 1002 is asserted (eg, logic level high), and hardware accelerator 100 enters test mode.

[0078] At step 1106, at time t 2, TCR 716 asserts (e.g., logic level high) the first grant signal 1004 for the first master controller 706a, which instructs the first master controller 706a to load the OTP repair data. Since the associated partition 602 for the first master controller 706a starts at address "0", the master controller bus address 812 is the same as the OTP bus address 814, with a null offset. At step 1108, at time t 2 With time t 3 Meanwhile, the first host controller 706 a loads the OTP repair data from the first partition 602 of the OTP memory 502 based on the OTP bus address 814 .

[0079] At step 1110, at time t 3 After the OTP repair data is loaded from the first partition 602 of the OTP memory 502 by the first host controller 706a, the TCR 716 deasserts (e.g., logic level low) the first grant signal 1004. In an embodiment, the timing is predetermined because there is typically no feedback during test mode and manufacturing test—the test mode time is fixed and typically independent of the feedback signal.

[0080] At step 1112, at time t 4 , TCR 716 asserts (e.g., logic level high) the second grant signal 1006 for the second master controller 706b, instructing the second master controller 706b to load the OTP repair data. However, during this sequence, the offset logic and selection circuit 704 adds the offset to the master controller bus address 812 to generate the OTP bus address 814 from which the OTP repair data is loaded (i.e., the second partition 602). Therefore, the OTP bus address 814 points to the second partition 602 in the OTP memory 502.

[0081] At step 1114, at time t 4 With time t 5 Meanwhile, the second master controller 706 b obtains the OTP repair data from the second partition 602 of the OTP memory 502 based on the OTP bus address 814 .

[0082] At step 1116, at time t 5 After the loading of the OTP repair data from the second partition 602 of the OTP memory 502 is completed by the second master controller 706 b , the second grant signal is de-asserted (eg, logic level low).

[0083] It is noted that all steps listed in the flowcharts of methods 900 and 1100 are not required and may be optional. Additionally, changes to the arrangement of steps, removal of one or more steps and path connections, and addition of steps and path connections are similarly contemplated.

[0084] A first aspect relates to a system for testing and repairing a local memory in a hardware accelerator. The system includes a one-time programmable (OTP) memory, an OTP sequencer circuit, a first master controller, a second master controller, and an offset addition and selection logic circuit. The OTP memory is configured to store first repair data in a first partition and store second repair data in a second partition in sequence for a first subset of local memory and a second subset of local memory, respectively. The OTP sequencer circuit is configured to assert a first authorization signal. The first master controller is coupled to the OTP sequencer circuit and the first subset of local memory. The first master controller is configured to load first repair data for the first subset of local memory from the first partition for the first time, and transmit a first status signal indicating that the first load is completed to the OTP sequencer circuit after the first load is completed. The OTP sequencer circuit is also configured to de-assert the first authorization signal in response to the OTP sequencer circuit receiving the first status signal and assert the second authorization signal in response to the de-assertion of the first authorization signal. The offset addition and selection logic circuit is configured to add an offset to an address used by the second master controller to access the second partition. The second master controller is configured to load second repair data for a second subset of the local memory associated with the second master controller from the second partition for a second time using the address for accessing the second partition, and transmit a second status signal indicating completion of the second loading to the OTP sequencer circuit after the second loading is completed. The OTP sequencer circuit is further configured to de-assert the second grant signal in response to the OTP sequencer circuit receiving the second status signal.

[0085] In a first implementation form of the system according to the first aspect per se, the OTP sequencer circuit is configured to generate the first grant signal in response to the OTP sequencer circuit receiving a functional mode reset signal.

[0086] In a second implementation form of the system according to the first aspect itself or any of the preceding implementation forms of the first aspect, the system further comprises a first repair controller coupled to the first host controller and the OTP sequencer circuit. The OTP sequencer circuit is configured to instruct the first host controller to load the first repair data through the first repair controller in response to receiving the first authorization signal.

[0087] In a third implementation form of the system according to the first aspect itself or any of the preceding implementation forms of the first aspect, the system further comprises a second repair controller coupled to the second master controller and the OTP sequencer circuit. The OTP sequencer circuit is configured to instruct the second master controller to load the second repair data through the second repair controller in response to receiving the second authorization signal.

[0088] In a fourth implementation form of the system according to the first aspect itself or any preceding implementation form of the first aspect, the hardware accelerator comprises a graphics processing unit (GPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a combination thereof.

[0089] In a fifth implementation form of the system according to the first aspect itself or any preceding implementation form of the first aspect, the hardware accelerator is used for artificial intelligence or machine learning.

[0090] In a sixth implementation form of the system according to the first aspect itself or any of the foregoing implementation forms of the first aspect, the second repair data is stored in the OTP memory in sequence after the first repair data, so that the offset added to the address points to the memory space immediately after the first repair data.

[0091] A second aspect relates to a method for testing and repairing a local memory in a hardware accelerator from a one-time programmable memory (OTP). The method includes: asserting a first authorization signal by a one-time programmable (OTP) sequencer circuit; loading, by a first master controller, first repair data for a first subset of a local memory associated with the first master controller from a first partition of the OTP memory for the first time; transmitting, by the first master controller, a first status signal indicating completion of the first loading to the OTP sequencer circuit after the first loading is completed; de-asserting the first authorization signal by the OTP sequencer circuit in response to the OTP sequencer circuit receiving the first status signal; asserting a second authorization signal by the OTP sequencer circuit in response to de-assertion of the first authorization signal; and adding, by an offset adding and selecting logic circuit, an offset adding signal. an address added to a second partition of the OTP memory used by the second master controller to access the second partition, wherein the first repair data and the second repair data are sequentially loaded into the OTP memory; loading, by the second master controller, the second repair data for a second subset of the local memory associated with the second master controller from the second partition of the OTP memory for a second time using the address for accessing the second partition; transmitting, by the second master controller, a second status signal indicating completion of the second loading to the OTP sequencer circuit after completion of the second loading; and deasserting, by the OTP sequencer circuit, a second grant signal in response to the OTP sequencer circuit receiving the second status signal.

[0092] In a first implementation form of the method according to the second aspect per se, the first grant signal is generated in response to the OTP sequencer circuit receiving a functional mode reset signal.

[0093] In a second implementation form of the method according to the second aspect itself or any preceding implementation form of the second aspect, the method further comprises instructing the first host controller to load the first repair data via the first repair controller in response to receiving the first authorization signal. The first repair controller is coupled to the first host controller and the OTP sequencer circuit.

[0094] In a third implementation form of the method according to the second aspect itself or any preceding implementation form of the second aspect, the method further comprises instructing the second master controller to load the second repair data via the second repair controller in response to receiving the second authorization signal. The second repair controller is coupled to the second master controller and the OTP sequencer circuit.

[0095] In a fourth implementation form of the method according to the second aspect itself or any of the preceding implementation forms of the second aspect, the hardware accelerator comprises a graphics processing unit (GPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC) or a combination thereof.

[0096] In a fifth implementation form of the method according to the second aspect itself or any preceding implementation form of the second aspect, the hardware accelerator is used for artificial intelligence or machine learning.

[0097] In a sixth implementation form of the method according to the second aspect itself or any of the foregoing implementation forms of the second aspect, the method also includes storing second repair data in sequence after the first repair data in the OTP memory, so that the offset added to the address points to the memory space immediately after the first repair data.

[0098] A third aspect relates to a system for testing and repairing a local memory in a hardware accelerator. The system includes a one-time programmable (OTP) memory, a test control register (TCR), a first master controller, a second master controller, and an offset addition and selection logic circuit. The OTP memory is configured to sequentially store first repair data in a first partition and second repair data in a second partition for a first subset of the local memory and a second subset of the local memory, respectively. The TCR is configured to assert a first authorization signal. The first master controller is coupled to the first subset of the local memory, and the first master controller is configured to load first repair data for the first subset of the local memory from the first partition for the first time in response to the first authorization signal being asserted. The offset addition and selection logic circuit is coupled to the TCR and the first master controller. The offset addition and selection logic circuit is configured to add an offset to an address used by the second master controller to access the second partition. The TCR is also configured to de-assert the first authorization signal and assert the second authorization signal in response to the de-assertion of the first authorization signal. The second master controller is configured to load second repair data for a second subset of local memory associated with the second master controller from the second partition a second time using the address to access the second partition in response to the second grant signal being asserted, wherein the TCR is further configured to deassert the second grant signal.

[0099] In a first implementation form of the system according to the third aspect per se, the TCR is further configured to assert the access signal to operate the hardware accelerator in the test mode.

[0100] In a second implementation form of the system according to the third aspect itself or any preceding implementation form of the third aspect, the hardware accelerator includes a graphics processing unit (GPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC) or a combination thereof.

[0101] In a third implementation form of the system according to the third aspect itself or any preceding implementation form of the third aspect, the hardware accelerator is used for artificial intelligence or machine learning.

[0102] In a fourth implementation of the system according to the third aspect itself or any of the foregoing implementations of the third aspect, the second repair data is stored in the OTP memory in sequence after the first repair data, so that the offset added to the address points to the memory space immediately after the first repair data.

[0103] Although the present specification has been described in detail, it should be understood that various changes, substitutions and modifications may be made without departing from the spirit and scope of the present disclosure as defined by the appended claims. In the various figures, the same elements are represented by the same reference numerals. Moreover, the scope of the present disclosure is not intended to be limited to the specific embodiments described herein, because those of ordinary skill in the art will readily recognize from the present disclosure that currently existing or later developed processes, machines, manufactures, material compositions, parts, methods or steps can perform substantially the same functions or achieve substantially the same results as the corresponding embodiments described herein. Therefore, the appended claims are intended to include such processes, machines, manufactures, material compositions, parts, methods or steps within their scope.

[0104] Accordingly, the specification and drawings should be regarded as illustrative only of the present disclosure, which is defined by the appended claims, and are intended to cover any and all modifications, variations, combinations or equivalents falling within the scope of the present disclosure.

Claims

1. A system for testing and repairing a local memory in a hardware accelerator, the system comprising: a one-time programmable (OTP) memory configured to sequentially store first repair data in a first partition and second repair data in a second partition for a first subset of the local memory and a second subset of the local memory, respectively; an OTP sequencer circuit configured to assert a first grant signal; A first host controller coupled to the OTP sequencer circuit and the first subset of the local memory, the first host controller being configured to: loading first repair data for the first subset of the local memory from the first partition for the first time, and transmitting a first status signal indicating completion of the first load to the OTP sequencer circuit after the first load is completed, wherein the OTP sequencer circuit is further configured to deassert the first grant signal in response to the OTP sequencer circuit receiving the first status signal and assert the second grant signal in response to deassertion of the first grant signal; an offset addition and selection logic circuit configured to add an offset to an address used by a second host controller to access a second partition; as well as The second master controller is configured as: loading second repair data for a second subset of local memory associated with a second host controller from the second partition a second time using the address to access the second partition, and A second status signal indicating the second loading is completed is transmitted to the OTP sequencer circuit after the second loading is completed, wherein the OTP sequencer circuit is further configured to de-assert the second grant signal in response to the OTP sequencer circuit receiving the second status signal.

2. The system of claim 1, wherein: The OTP sequencer circuit is configured to generate a first grant signal in response to the OTP sequencer circuit receiving a functional mode reset signal.

3. The system of claim 1 , further comprising a first repair controller coupled to the first host controller and the OTP sequencer circuit, wherein the OTP sequencer circuit is configured to instruct the first host controller to load the first repair data through the first repair controller in response to receiving the first authorization signal.

4. The system of claim 1 , further comprising a second repair controller coupled to the second host controller and the OTP sequencer circuit, wherein the OTP sequencer circuit is configured to instruct the second host controller to load the second repair data through the second repair controller in response to receiving the second authorization signal.

5. The system of claim 1, wherein: Hardware accelerators include graphics processing units (GPUs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or a combination thereof.

6. The system of claim 1, wherein: Hardware accelerators are used for artificial intelligence or machine learning.

7. The system of claim 1, wherein: The second repair data is stored in the OTP memory in sequence after the first repair data such that the offset added to the address points to a memory space immediately after the first repair data.

8. A method for testing and repairing a local memory in a hardware accelerator from a one-time programmable memory (OTP), the method comprising: asserting a first grant signal by the OTP sequencer circuit; loading, by the first host controller, first repair data for a first subset of a local memory associated with the first host controller from a first partition of the OTP memory for the first time; After the first loading is completed, the first main controller transmits a first status signal indicating the first loading is completed to the OTP sequencer circuit; deasserting, by the OTP sequencer circuit, a first grant signal in response to the OTP sequencer circuit receiving a first status signal; asserting, by the OTP sequencer circuit, a second grant signal in response to deassertion of the first grant signal; adding, by the offset addition and selection logic circuit, an offset to an address of a second partition of the OTP memory used by the second host controller to access the second repair data, wherein the first repair data and the second repair data are sequentially loaded into the OTP memory; loading, by the second host controller, second repair data for a second subset of local memory associated with the second host controller from the second partition of the OTP memory a second time using the address for accessing the second partition; After the second loading is completed, the second main controller transmits a second status signal indicating the second loading is completed to the OTP sequencer circuit; as well as In response to the OTP sequencer circuit receiving the second status signal, the second grant signal is de-asserted by the OTP sequencer circuit.

9. The method of claim 8, wherein: The first grant signal is generated in response to the OTP sequencer circuit receiving a functional mode reset signal.

10. The method of claim 8, further comprising instructing the first host controller to load the first repair data through a first repair controller in response to receiving the first authorization signal, wherein the first repair controller is coupled to the first host controller and the OTP sequencer circuit.

11. The method of claim 8, further comprising instructing the second host controller to load second repair data through a second repair controller in response to receiving the second grant signal, wherein the second repair controller is coupled to the second host controller and the OTP sequencer circuit.

12. The method of claim 8, wherein: Hardware accelerators include graphics processing units (GPUs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or a combination thereof.

13. The method of claim 8, wherein: Hardware accelerators are used for artificial intelligence or machine learning.

14. The method of claim 8, further comprising storing second repair data in the OTP memory in sequence after the first repair data such that the offset added to the address points to a memory space immediately after the first repair data.

15. A system for testing and repairing local memory in a hardware accelerator, the system comprising: A one-time programmable (OTP) memory configured to sequentially store first repair data in a first partition and second repair data in a second partition for a first subset of the local memory and a second subset of the local memory, respectively; A test control register TCR configured to assert a first authorization signal; a first master controller coupled to the first subset of the local memory, the first master controller configured to first load first repair data for the first subset of the local memory from the first partition in response to the first grant signal being asserted; an offset addition and selection logic circuit coupled to the TCR and the first master controller, the offset addition and selection logic circuit configured to add an offset to an address used by the second master controller to access the second partition, wherein the TCR is further configured to deassert the first grant signal and assert the second grant signal in response to the deassertion of the first grant signal; as well as A second master controller is configured to load second repair data for a second subset of local memory associated with the second master controller from the second partition a second time using the address to access the second partition in response to the second grant signal being asserted, wherein the TCR is further configured to deassert the second grant signal.

16. The system of claim 15, wherein: The TCR is also configured to assert an access signal to operate the hardware accelerator in a test mode.

17. The system of claim 15, wherein: Hardware accelerators include graphics processing units (GPUs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or a combination thereof.

18. The system of claim 15, wherein: Hardware accelerators are used for artificial intelligence or machine learning.

19. The system of claim 15, wherein: The second repair data is stored in the OTP memory in sequence after the first repair data such that the offset added to the address points to a memory space immediately after the first repair data.

20. The system of claim 15, further comprising a test access point (TAP) couplable to the TCR, the TAP configured to control operation of the TCR during a test mode operation of the hardware accelerator.

Images