Hardware self-recovery system, method and artificial intelligence processor

Abstract

The application discloses a kind of hardware self-recovery system, method and artificial intelligence processor, in the case where computing core hangs, by computing core to self-recovery control module sends interrupt signal;Self-recovery control module receives interrupt signal, compares the preset threshold value of first register cache and the current count value of second register cache, in the case where current count value is not greater than preset threshold value, empty signal is sent to command package processing module, and reset signal is sent to computing core;Command package processing module responds empty signal and carries out empty operation, computing core responds reset signal and executes reset operation;After command package processing module enters idle state and computing core resets, self-recovery control module again sends start signal to command package processing module, controls its recovery to the processing of unfinished command package.The application can realize hardware level automatic recovery, effectively shorten the recovery period of occasional exception, reduce time waste.

Description

Technical Field

[0001] This invention relates to the field of computer processor technology, and in particular to a hardware self-recovery system, method, and artificial intelligence processor. Background Technology

[0002] Currently, artificial intelligence processors are widely used in various industries. When users are developing related tasks, sometimes the computing core may freeze while executing the current task due to occasional reasons such as unstable circuit transmission.

[0003] In existing chips, when a computing core hangs, the core internally packages the interrupt information and sends it to the interrupt collection module. All interrupt information is then collected and sent to the host. Upon receiving the interrupt information, the host software terminates the currently executing process and then sends a restart command to the command processor to resume operation. Clearly, this interrupt reporting and command issuance process is cumbersome and involves software operation, significantly increasing overall response time. For hangs caused by occasional factors, this time consumption can lead to unnecessary performance loss. Summary of the Invention

[0004] The purpose of this invention is to provide a hardware self-recovery system, method, and artificial intelligence processor. By setting a self-recovery control module in the command processor and utilizing the collaborative cooperation between the command processor and the computing core, hardware-level automatic recovery can be achieved in the event of a computing core hang, thereby avoiding interference to the host caused by hangs due to occasional factors, effectively shortening the recovery cycle, and reducing time waste.

[0005] A first aspect of the present invention provides a hardware self-recovery system, comprising: a command processor and a computing core; wherein the command processor comprises: a self-recovery control module, a command packet processing module, a first register, and a second register;

[0006] The first register is used to cache a preset threshold for the number of hardware self-recovery cycles;

[0007] The second register is used to cache the current count of hardware self-recovery attempts;

[0008] The computing core is used to send an interrupt signal to the self-recovery control module in the event of a hangup, and to reset in response to a reset signal sent by the self-recovery control module.

[0009] The self-recovery control module is used to compare the current count value with the preset threshold after receiving the interrupt signal, and send a clear signal to the command packet processing module and a reset signal to the computing core if the current count value is not greater than the preset threshold.

[0010] The command packet processing module is used to respond to the clear signal, stop acquiring new command packets, and clear all command packets and split tasks in the internal cache to enter an idle state.

[0011] The self-recovery control module is further configured to send a start signal to the command packet processing module after the command packet processing module enters an idle state and the computing core is reset, so as to resume the processing of unfinished command packets.

[0012] Optionally, the command package processing module is further configured to respond to the start signal, retrieve the incomplete command package from memory again, unpack the incomplete command package, and distribute the split tasks to the computing core.

[0013] Optionally, the self-recovery control module is further configured to report the interrupt signal to the host when the current count value is greater than the preset threshold, so as to transfer the control of recovery to the host.

[0014] Optionally, an interrupt pulse line is provided between the self-recovery control module and the computing core; wherein, in the event that the computing core hangs, the interrupt pulse line is driven to a specified level by the computing core to send the interrupt signal to the self-recovery control module.

[0015] Optionally, the self-recovery control module sends the clear signal and the start signal to the command packet processing module via a mailbox communication mechanism.

[0016] Optionally, the command packet processing module includes: N user pipeline units and a task distribution unit; wherein each user pipeline unit includes: a hardware queue subunit, a command cache subunit, and a command processing subunit; wherein N≥1;

[0017] The hardware queue subunit is used to read command packets from memory and write them into the corresponding hardware command queue.

[0018] The command cache subunit is used to read command packets from the hardware command queue and write them into the command cache queue;

[0019] The command processing subunit is used to sequentially read the command packets in the command cache queue and perform unpacking processing, and send one or more split tasks to the task distribution unit.

[0020] The task distribution unit is used to store the received tasks into a task cache pool and distribute the tasks in the task cache pool to the computing core through a polling mechanism.

[0021] Optionally, the command package processing module stops acquiring new command packages and clears all command packages and split tasks from its internal cache, including:

[0022] Using the aforementioned hardware queue subunit, the retrieval of new command packets from memory is stopped;

[0023] Clear all command packets in the hardware command queue and the command cache queue;

[0024] Clear the tasks in the task cache pool.

[0025] Optionally, the command processor further includes: a third register; wherein the third register is used to cache the clear control bit;

[0026] The self-recovery control module sends a clear signal to the command packet processing module, including:

[0027] Configure the clear control bit to be in a valid state so that when the command packet processing module detects that the clear control bit is in a valid state, it performs clear processing.

[0028] Optionally, the command processor further includes a fourth register; wherein the fourth register is used to cache the execution read pointer corresponding to the hardware command queue; the execution read pointer points to the storage location of the incomplete command package in memory and is used to generate the start signal.

[0029] A second aspect of the present invention provides an artificial intelligence processor, including the hardware self-recovery system described in any embodiment of the first aspect.

[0030] A third aspect of the present invention provides a hardware self-recovery method, applicable to the hardware self-recovery system described in any embodiment of the first aspect; wherein the hardware self-recovery system includes a computing core and a command processor; the command processor includes a first register, a second register, a self-recovery control module, and a command packet processing module; the method includes:

[0031] The first register is used to cache a preset threshold for the number of hardware self-recovery cycles;

[0032] The second register caches the current count of hardware self-recovery attempts;

[0033] In the event of a hangup, the computing core sends an interrupt signal to the self-recovery control module and responds to a reset signal sent by the self-recovery control module to perform a reset.

[0034] Upon receiving the interrupt signal, the self-recovery control module compares the current count value with the preset threshold. If the current count value is not greater than the preset threshold, it sends a clear signal to the command packet processing module and a reset signal to the computing core.

[0035] The command packet processing module responds to the clear signal, stops acquiring new command packets, and clears all internally cached command packets and split tasks to enter an idle state.

[0036] The self-recovery control module sends a start signal to the command packet processing module after the command packet processing module enters an idle state and the computing core is reset, so as to resume the processing of unfinished command packets.

[0037] Compared with existing technologies, this invention provides a hardware self-recovery system, method, and artificial intelligence processor. In the event of a computing core hang, the computing core sends an interrupt signal to the self-recovery control module. Upon receiving the interrupt signal, the self-recovery control module calls a preset threshold cached in the first register and compares it with the current count value cached in the second register. If the current count value is not greater than the preset threshold, it sends a clear signal to the command packet processing module and a reset signal to the computing core. The command packet processing module responds to the clear signal by performing a clear operation, and the computing core responds to the reset signal by performing a reset operation. After the command packet processing module enters an idle state and the computing core has completed its reset, the self-recovery control module sends a start signal to the command packet processing module to control its resumption of processing of incomplete command packets. Therefore, this invention enables the hardware to autonomously complete the entire recovery process in the event of a computing core hang caused by an occasional factor, without the need for host software intervention. This eliminates the long waiting times caused by cumbersome processes such as multi-level interrupt reporting and software control in existing technologies. Furthermore, the configuration of the first register avoids the hardware from making unlimited recovery attempts, effectively ensuring the stability and reliability of the system. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the structure of an embodiment of the hardware self-recovery system provided by the present invention;

[0039] Figure 2 This is a schematic diagram of another embodiment of the hardware self-recovery system provided by the present invention;

[0040] Figure 3 This is a schematic diagram of another embodiment of the hardware self-recovery system provided by the present invention;

[0041] Figure 4This is a schematic diagram of the structure of an embodiment of the artificial intelligence processor provided by the present invention;

[0042] Figure 5 This is a flowchart illustrating an embodiment of the hardware self-recovery method provided by the present invention. Detailed Implementation

[0043] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0044] The artificial intelligence processor involved in this invention can be any one of CPU (Central Processing Unit), GPU (Graphics Processing Unit), TPU (Tensor Processing Unit), NPU (Neural Network Processing Unit), DPU (Deep Learning Processing Unit), APU (Accelerated Processing Unit), and GPGPU (General-Purpose computing on Graphics Processing Unit), depending on its application to a specific product or technology in the embodiments of this invention.

[0045] See Figure 1 This is a schematic diagram of an embodiment of the hardware self-recovery system provided by the present invention.

[0046] A first aspect of the present invention provides a hardware self-recovery system, including: a command processor 100 and a computing core 200; wherein, the command processor 100 includes: a self-recovery control module 110, a command packet processing module 120, a first register 130 and a second register 140;

[0047] The first register 130 is used to cache a preset threshold for the number of hardware self-recovery cycles;

[0048] The second register 140 is used to cache the current count of hardware self-recovery attempts;

[0049] The computing core 200 is used to send an interrupt signal to the self-recovery control module 110 in the event of a hangup, and to reset in response to a reset signal sent by the self-recovery control module 110.

[0050] The self-recovery control module 110 is used to compare the current count value with the preset threshold after receiving the interrupt signal, and send a clear signal to the command packet processing module 120 and a reset signal to the computing core 200 if the current count value is not greater than the preset threshold.

[0051] The command packet processing module 120 is used to respond to the clear signal, stop acquiring new command packets, and clear all command packets and split tasks in the internal cache to enter an idle state.

[0052] The self-recovery control module 110 is further configured to send a start signal to the command packet processing module 120 after the command packet processing module 120 enters an idle state and the computing core 200 is reset, so as to resume the processing of unfinished command packets.

[0053] It should be noted that the preset threshold (denoted as flush-max-cnt) of the first register 130 cache can be configured by the host software during system initialization according to the application scenario requirements. This is used to limit the maximum number of times the hardware can autonomously handle the hang of computing core 200. If flush-max-cnt is configured to 0, it means that the hardware self-recovery function is disabled.

[0054] The current count of hardware self-recovery attempts (denoted as flush-cnt) is cached in the second register 140. The initial value of flush-cnt is 0, and it has the following two update methods: one is that after the self-recovery control module 110 receives the interrupt signal sent by the computing core 200, before comparing flush-max-cnt and flush-cnt, the flush-cnt value is incremented by one to record the hardware self-recovery operation to be performed this time; the other is that after the self-recovery control module 110 issues a start signal and the command packet processing module 120 resumes processing the unfinished command packets, the flush-cnt value is incremented by one to record the hardware self-recovery operation that has been completed this time.

[0055] If a hang occurs during task execution, the computing core 200 directly sends an interrupt signal to the self-recovery control module 110 to trigger the hardware self-recovery process. Upon receiving the interrupt signal from the computing core 200, the self-recovery control module 110 compares flush-max-cnt with the updated flush-cnt. If the updated flush-cnt is less than or equal to flush-max-cnt, it indicates that the current hang is an intermittent exception, handled autonomously by the hardware. The self-recovery control module 110 sends a clear signal to the command packet processing module 120 and a reset signal to the computing core 200. If the updated flush-cnt is greater than flush-max-cnt, it indicates that the current hang is a non-intermittent exception, requiring host software intervention for investigation and handling to avoid resource waste caused by repeated hardware recovery attempts. Simultaneously, the current flush-cnt is reset to 0 to prepare for the next round of hardware self-recovery for intermittent exceptions.

[0056] After receiving the clear signal, the command packet processing module 120 first stops retrieving new command packets from external memory, then clears all command packets in its internal cache (such as command packets in the hardware command queue and command cache queue), as well as the tasks split from the command packets (located in the task cache pool), and puts itself into an idle state, waiting for a subsequent start signal.

[0057] The self-recovery control module 110 monitors that the command packet processing module 120 has entered an idle state and the computing core 200 has been reset. It then sends a start signal to the command packet processing module 120 to control the command packet processing module 120 to read the incomplete command packets from the external memory before the hangup occurred and to continue to split and distribute the incomplete command packets.

[0058] As can be seen from the above, the hardware self-recovery system provided by the present invention, by setting a self-recovery control module 110 in the command processor 100 and utilizing the coordinated cooperation between the command processor 100 and the computing core 200, can realize hardware-level automatic recovery in the case of the computing core 200 being suspended, thereby avoiding interference to the host caused by suspension problems caused by occasional factors, effectively shortening the recovery cycle and reducing time waste.

[0059] See Figure 2 This is a schematic diagram of another embodiment of the hardware self-recovery system provided by the present invention.

[0060] In an optional embodiment, an interrupt pulse line is provided between the self-recovery control module 110 and the computing core 200; wherein, in the event that the computing core 200 hangs up, the interrupt pulse line is driven to a specified level by the computing core 200 to send the interrupt signal to the self-recovery control module 110.

[0061] It should be noted that the self-recovery control module 110 has a built-in microcontroller (MCU) and runs the corresponding firmware program to execute the self-recovery control logic. The computing core 200 is connected to the interrupt input terminal of the MCU in the self-recovery control module 110 through an independent interrupt pulse line to directly transmit the interrupt signal, thereby avoiding the transmission delay caused by the on-chip network / bus.

[0062] Specifically, when the computing core 200 hangs, the computing core 200 configures the level signal of the interrupt pulse line to a preset specified level (such as pulling the level of the interrupt pulse line from low level to high level); the specified level is directly transmitted to the MCU in the self-recovery control module 110 through the interrupt pulse line, thereby realizing the sending of an interrupt signal to the self-recovery control module 110.

[0063] exist Figure 2 In addition, the self-recovery control module 110 also sends a reset signal to the computing core 200 through the on-chip network to achieve a soft reset of the computing core 200, that is, to clear the suspended state of the computing core 200 and restore it to the initial normal working state, so as to prepare for subsequent reception and execution of tasks.

[0064] In an optional embodiment, the self-recovery control module 110 is further configured to report the interrupt signal to the host when the current count value is greater than the preset threshold, so as to transfer the control recovery authority to the host.

[0065] like Figure 2 As shown, if the current count value is greater than the preset threshold, it indicates that the number of hardware self-recovery attempts in this round has been exhausted. The current hang may be due to a non-incidental anomaly, making it unsuitable for the hardware to continue attempting autonomous recovery. The self-recovery control module 110 needs to report the hang of the computing core 200 to the host via the on-chip network to notify the host software to intervene. In other words, the self-recovery control module 110 transfers the control of recovery to the host software, which then performs subsequent anomaly checks, process cleanup, and task restarts to avoid resource waste caused by repeated hardware recovery attempts.

[0066] In an optional embodiment, the self-recovery control module 110 sends the clear signal and the start signal to the command packet processing module 120 via a mailbox communication mechanism.

[0067] It should be noted that, as Figure 2As shown, the command processor 100 is equipped with a hardware mailbox. The mailbox integrates a set of dedicated registers (such as the third register 150 corresponding to the clear signal) to carry the interactive information between the self-recovery control module 110 and the command packet processing module 120, realizing asynchronous communication between the modules. The sender (self-recovery control module 110) does not need to wait for the receiver (command packet processing module 120) to respond immediately; it can continue to execute other tasks after completing the corresponding register configuration.

[0068] When the self-recovery control module 110 needs to send a flush signal to the command packet processing module 120, it configures the third register 150 in the Mailbox to a valid state. The command packet processing module 120 continuously monitors or periodically polls the Mailbox, and performs a flush operation after detecting that the third register 150 is in a valid state. Similarly, the self-recovery control module 110 can configure a doorbell register in the Mailbox to send a start signal to the command packet processing module 120.

[0069] See Figure 3 This is a schematic diagram of another embodiment of the hardware self-recovery system provided by the present invention.

[0070] In an optional embodiment, the command packet processing module 120 includes: N user pipeline units and a task distribution unit; wherein each user pipeline unit includes: a hardware queue subunit, a command cache subunit, and a command processing subunit; wherein N≥1;

[0071] The hardware queue subunit is used to read command packets from memory and write them into the corresponding hardware command queue.

[0072] The command cache subunit is used to read command packets from the hardware command queue and write them into the command cache queue;

[0073] The command processing subunit is used to sequentially read the command packets in the command cache queue and perform unpacking processing, and send one or more split tasks to the task distribution unit.

[0074] The task distribution unit is used to store the received tasks into a task cache pool and distribute the tasks in the task cache pool to the computing core 200 through a polling mechanism.

[0075] It should be noted that, in Figure 3In this system, "User Pipeline Unit 0" to "User Pipeline Unit N-1" correspond to independent command packet processing pipelines, which can process command packets from different task flows in parallel. Each User Pipeline Unit (denoted as U-pipe) includes: a hardware queue subunit, a command cache subunit, and a command processing subunit; these three subunits work together to complete the process of reading, caching, unpacking, and distributing command packets under normal working conditions.

[0076] like Figure 3 As shown, each hardware queue subunit includes n hardware command queues; where n ≥ 1. Each hardware command queue corresponds to a Hardware Command Queue Descriptor (HCQD). The HCQD is used to define and manage the hardware control structure of the corresponding hardware command queue (such as queue base address, length, status flag, etc.), and synchronizes the execution-read-point of the corresponding hardware command queue to the fourth register 160 for storage. The execution-read-point is used to record the current command packet read position so that the command packet can be retrieved from the breakpoint in scenarios such as exception recovery.

[0077] Through a polling mechanism, the HCQD in the hardware queue sub-unit initiates a command packet read request to the external memory via the on-chip network, and stores the read command packet into the corresponding hardware command queue, thereby realizing multi-way concurrent reading and caching of command packets.

[0078] The command cache subunit retrieves command packets from the corresponding "hardware command queues 0~n-1" and stores them in the command cache queue. As a secondary buffer, the command cache queue can effectively alleviate the processing rate difference between the hardware command queue and the downstream command processing subunits, and avoid pipeline stalls caused by high external memory read latency.

[0079] The command processing subunit sequentially reads command packets from the command cache queue, parses and unpacks the command packets, splitting a single command packet into one or more executable tasks. Each split task carries source identification information, namely the identifier hcqd_id of its respective hardware command queue, for subsequent task distribution and scheduling.

[0080] The task distribution unit is used to receive tasks split from each command processing subunit and store them in the task cache pool for management; it retrieves tasks from the task cache pool through a polling mechanism and sends them to computing core 200.

[0081] Clearly, the entire command packet processing module 120 can efficiently and orderly complete the entire process from retrieving the command packet from memory to distributing the task to the computing core 200.

[0082] In an optional embodiment, the command processor 100 further includes a third register 150; wherein the third register 150 is used to cache the clear control bit;

[0083] The self-recovery control module 110 sends a clear signal to the command packet processing module 120, including:

[0084] The clear control bit is configured to be valid so that when the command packet processing module 120 detects that the clear control bit is valid, it performs clear processing.

[0085] Specifically, the flush control bit is used to indicate whether the command packet processing module 120 needs to perform a flush operation. For example... Figure 2 or Figure 3 As shown, the self-recovery control module 110 accesses the third register 150 in the Mailbox through the on-chip network and configures the clear control bit to a valid state (e.g., set to 1); the command packet processing module 120 continuously monitors or periodically polls the status of the third register 150. If it is in a valid state, it immediately starts the clearing process of the internal cached command packets and tasks.

[0086] It is worth noting that the clear control bit can be represented in different granularities according to system design requirements. One is a coarse-grained representation, which sets a global clear control bit, and when it is in a valid state, it instructs the command packet processing module 120 to perform a clear operation. The other is a fine-grained representation, which assigns an independent clear control bit to each hardware command queue / HCQD; for example, when the command packet processing module 120 includes 8 user pipeline units (U-Pipe), and each U-Pipe is configured with n hardware command queues, then the third register 150 is represented as flush[0:8×n-1], where each bit corresponds to the clear control bit of a hardware command queue / HCQD; after the self-recovery control module 110 determines that Flush-max-cnt ≥ Flush-cnt is true, it configures the third register 150 (i.e., flush[0:8×n-1]) through the on-chip network, setting all clear control bits to 1 (i.e., valid state).

[0087] In an optional embodiment, the command packet processing module 120 stops acquiring new command packets and clears all command packets and split tasks from its internal cache, including:

[0088] Using the aforementioned hardware queue subunit, the retrieval of new command packets from memory is stopped;

[0089] Clear all command packets in the hardware command queue and the command cache queue;

[0090] Clear the tasks in the task cache pool.

[0091] In practice, when the third register 150 is flush[0:8×n-1] and all clear control bits of the cache are 1, each hardware command queue in the hardware queue subunit immediately stops reading new command packets from external memory after detecting that its corresponding clear control bit has been pulled high. After detecting that the third register 150 is configured to be valid, the command cache subunit reads and discards all command packets from its corresponding n hardware command queues, no longer passing them to downstream command processing subunits; in other words, the command cache subunit directly empties the upstream hardware command queue from the middle, stopping the subsequent distribution of command packets. The downstream command processing subunit continues to read the existing command packets in the command cache queue sequentially and splits them into one or more tasks to clear the command cache queue; these split tasks carry the corresponding hcqd_id and are stored in the task cache pool. After detecting that the third register 150 is configured to be valid, the task distribution unit needs to clear the tasks corresponding to all hardware command queues. Since all tasks in the task cache pool carry hcqd_id, and all clear control bits are valid at this time, all task hcqd_ids match the clear condition. The task distribution unit will discard all tasks directly from the output port of the task cache pool and will no longer pass them to the downstream computing core 200 for execution.

[0092] After the hardware command queue, command cache queue, and task cache pool inside the command packet processing module 120 are cleared, the entire module enters an idle state, which means that the following conditions are met: all hardware command queues are empty, the command cache queue is empty, the task cache pool is empty, the MCU built into the command cache subunit is in an idle state (i.e., it has not performed the action of moving command packets from the hardware command queue to the command cache queue), and the command processing subunit is in an idle state (i.e., it has not performed the action of unpacking command packets).

[0093] In an optional embodiment, the command processor 100 further includes a fourth register 160; wherein the fourth register 160 is used to cache the execution read pointer corresponding to the hardware command queue; the execution read pointer points to the storage location of the incomplete command package in memory and is used to generate the start signal.

[0094] It should be noted that after the self-recovery control module 110 determines that the command packet processing module 120 has entered an idle state and the computing core 200 has been reset, it generates a start signal based on the execute-read-point corresponding to each hardware command queue cached in the fourth register 160. That is, it reconfigures the doorbell register (hcqd-doorbell) corresponding to each hardware command queue in the Mailbox. The hardware queue sub-unit rereads the incomplete command packets (i.e., the command packets that were not executed before the computing core 200 was hung) from the position pointed to by the execute-read-point in the external memory according to the corresponding hcqd-doorbell. Subsequently, the command packet processing module 120 writes the reread incomplete command packets into the hardware command queue, completes the command caching and unpacking process in sequence, and distributes the split tasks to the computing core 200 that has been reset, thereby realizing the recovery of the command processing flow.

[0095] It is worth noting that, such as Figure 2 or Figure 3 As shown, the first register 130 (used to cache the preset threshold of the number of hardware self-recovery attempts), the second register 140 (used to cache the current count value of the number of hardware self-recovery attempts), and the fourth register 160 can also be integrated into the Mailbox, forming a dedicated register group for the Mailbox together with the third register 150 and the doorbell register. This enables centralized management of register resources, facilitating read and write operations by the self-recovery control module 110 through a unified mailbox interface, improving access efficiency, and allowing the host software to read or configure these registers through the mailbox when needed.

[0096] See Figure 4 This is a schematic diagram of an embodiment of the artificial intelligence processor provided by the present invention.

[0097] A second aspect of the present invention provides an artificial intelligence processor, including the hardware self-recovery system described in any embodiment of the first aspect.

[0098] Specifically, such as Figure 4 As shown, the hardware self-recovery system integrated within the AI ​​processor is used to achieve hardware-level automatic recovery in the event of a crash in computing core 200. The on-chip network (BN) is the communication bus within the AI ​​processor, responsible for transmitting data and control signals between components within the processor. The BN is also deployed within the hardware self-recovery system to enable signal transmission between sub-modules within the system; for example, the self-recovery control module 110 can send a reset signal to computing core 200 via the BN.

[0099] In addition, the AI ​​processor integrates a host interface and a memory access interface. The host interface connects to the on-chip network (CNN) to enable interaction between the AI ​​processor and an external host. When the self-recovery control module 110 determines that the current count value exceeds a preset threshold (i.e., Flush-cnt > Flush-max-cnt), it reports an interrupt signal to the external host. Upon receiving the interrupt signal, the external host's software uses the host interface and CNNIC to control the command processor and computing cores in the hardware self-recovery system to handle abnormal situations exceeding the hardware's self-recovery capabilities. The memory access interface also connects to the CNNIC, allowing the command packet processing module 120 in the hardware self-recovery system to access external memory for command packet reading and data transfer.

[0100] join Figure 5 This is a flowchart illustrating an embodiment of the hardware self-recovery method provided by the present invention.

[0101] A third aspect of the present invention provides a hardware self-recovery method, applicable to the hardware self-recovery system described in any of the first aspects of the present invention; wherein, the hardware self-recovery system includes a computing core 200 and a command processor 100; the command processor 100 includes a first register 130, a second register 140, a self-recovery control module 110, and a command packet processing module 120; the method includes steps S1 to S6, as follows:

[0102] Step S1: Cache a preset threshold for the number of hardware self-recovery cycles using the first register 130;

[0103] Step S2: Cache the current count value of the number of hardware self-recovery attempts in the second register 140;

[0104] Step S3: In the event of a hangup, the computing core 200 sends an interrupt signal to the self-recovery control module 110 and resets itself in response to a reset signal sent by the self-recovery control module 110.

[0105] Step S4: After receiving the interrupt signal, the self-recovery control module 110 compares the current count value with the preset threshold. If the current count value is not greater than the preset threshold, it sends a clear signal to the command packet processing module 120 and a reset signal to the computing core 200.

[0106] Step S5: The command packet processing module 120 responds to the clear signal, stops acquiring new command packets, and clears all command packets in the internal cache and the split tasks to enter an idle state;

[0107] Step S6: After the command packet processing module 120 enters the idle state and the computing core 200 is reset, the self-recovery control module 110 sends a start signal to the command packet processing module 120 to resume the processing of unfinished command packets.

[0108] It should be noted that the hardware self-recovery method provided in this embodiment of the invention can implement all the processing flows in the hardware self-recovery system described in any of the embodiments of the first aspect above. The specific implementation schemes and technical effects of the hardware self-recovery method correspond to the same specific implementation schemes and technical effects of the hardware self-recovery system described in any of the embodiments of the first aspect above, and will not be repeated here.

[0109] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A hardware self-recovery system, characterized in that, include: The command processor and computing core; wherein the command processor includes: a self-recovery control module, a command packet processing module, a first register, and a second register; The first register is used to cache a preset threshold for the number of hardware self-recovery cycles; The second register is used to cache the current count of hardware self-recovery attempts; The computing core is used to send an interrupt signal to the self-recovery control module in the event of a hangup, and to reset in response to a reset signal sent by the self-recovery control module. The self-recovery control module is used to compare the current count value with the preset threshold after receiving the interrupt signal, and send a clear signal to the command packet processing module and a reset signal to the computing core if the current count value is not greater than the preset threshold. The command packet processing module is used to respond to the clear signal, stop acquiring new command packets, and clear all command packets and split tasks in the internal cache to enter an idle state. The self-recovery control module is further configured to send a start signal to the command packet processing module after the command packet processing module enters an idle state and the computing core is reset, so as to resume the processing of unfinished command packets.

2. The hardware self-recovery system as described in claim 1, characterized in that, The command package processing module is also used to respond to the start signal, retrieve the incomplete command package from memory again, unpack the incomplete command package, and distribute the split tasks to the computing core.

3. The hardware self-recovery system as described in claim 1, characterized in that, The self-recovery control module is also used to report the interrupt signal to the host when the current count value is greater than the preset threshold, so as to transfer the control recovery authority to the host.

4. The hardware self-recovery system as described in claim 1, characterized in that, An interrupt pulse line is provided between the self-recovery control module and the computing core; wherein, in the event that the computing core hangs, the interrupt pulse line is driven to a specified level by the computing core to send the interrupt signal to the self-recovery control module.

5. The hardware self-recovery system as described in claim 1, characterized in that, The self-recovery control module sends the clear signal and the start signal to the command packet processing module through a mailbox communication mechanism.

6. The hardware self-recovery system as described in claim 1, characterized in that, The command packet processing module includes: N user pipeline units and a task distribution unit; wherein each user pipeline unit includes: a hardware queue subunit, a command cache subunit, and a command processing subunit; wherein N≥1; The hardware queue subunit is used to read command packets from memory and write them into the corresponding hardware command queue. The command cache subunit is used to read command packets from the hardware command queue and write them into the command cache queue; The command processing subunit is used to sequentially read the command packets in the command cache queue and perform unpacking processing, and send one or more split tasks to the task distribution unit. The task distribution unit is used to store the received tasks into a task cache pool and distribute the tasks in the task cache pool to the computing core through a polling mechanism.

7. The hardware self-recovery system as described in claim 6, characterized in that, The command package processing module stops acquiring new command packages and clears all command packages and split tasks from its internal cache, including: Using the aforementioned hardware queue subunit, the retrieval of new command packets from memory is stopped; Clear all command packets in the hardware command queue and the command cache queue; Clear the tasks in the task cache pool.

8. The hardware self-recovery system as described in claim 1, characterized in that, The command processor also includes a third register; wherein the third register is used to cache the clear control bit; The self-recovery control module sends a clear signal to the command packet processing module, including: Configure the clear control bit to be in a valid state so that when the command packet processing module detects that the clear control bit is in a valid state, it performs clear processing.

9. The hardware self-recovery system as described in claim 6, characterized in that, The command processor further includes a fourth register; wherein the fourth register is used to cache the execution read pointer corresponding to the hardware command queue; the execution read pointer points to the storage location of the incomplete command package in memory and is used to generate the start signal.

10. An artificial intelligence processor, characterized in that, Includes the hardware self-recovery system as described in any one of claims 1 to 9.

11. A hardware self-recovery method, characterized in that, The method is applicable to a hardware self-recovery system as described in any one of claims 1 to 9; wherein the hardware self-recovery system includes a computing core and a command processor; the command processor includes a first register, a second register, a self-recovery control module, and a command packet processing module; the method includes: The first register is used to cache a preset threshold for the number of hardware self-recovery cycles; The second register caches the current count of hardware self-recovery attempts; In the event of a hangup, the computing core sends an interrupt signal to the self-recovery control module and responds to a reset signal sent by the self-recovery control module to perform a reset. Upon receiving the interrupt signal, the self-recovery control module compares the current count value with the preset threshold. If the current count value is not greater than the preset threshold, it sends a clear signal to the command packet processing module and a reset signal to the computing core. The command packet processing module responds to the clear signal, stops acquiring new command packets, and clears all internally cached command packets and split tasks to enter an idle state. The self-recovery control module sends a start signal to the command packet processing module after the command packet processing module enters an idle state and the computing core is reset, so as to resume the processing of unfinished command packets.

Images