Reset processing method for computing core, computing device and computing system

Abstract

The present disclosure relates to a reset processing method for a computing core, a computing device and a computing system. The method comprises: intercepting, on a transmission path of a computing core reporting interrupt information to an instruction controller, abnormal interrupt information sent by the computing core due to processing an instruction packet abnormally, and instructing a firmware to perform a reset operation on the computing core based on the abnormal interrupt information; and in response to a reset completion notification of the firmware, releasing the abnormal interrupt information to the instruction controller, so that the instruction controller updates an instruction packet tracking record based on the abnormal interrupt information. The method of the present disclosure embodiment can effectively reduce the time overhead of the computing core reset waiting.

Description

Technical Field

[0001] This disclosure relates to the field of chip technology, and more specifically, to a reset processing method for a computing core, a computing device, and a computing system. Background Technology

[0002] In a computing system, the instruction controller manages instruction packets for pending tasks and distributes them to each computing core via the task distribution unit. The computing cores then parse the instruction packets and execute the corresponding tasks. When an exception occurs during instruction packet processing, the exception interrupt information issued by the computing core reaches the instruction controller and the firmware responsible for exception handling via the task distribution unit. The firmware needs to wait for the instruction controller to clear the incomplete count of the issued instruction packets before it can reset the computing core. This results in a long waiting time for the computing core to resume normal processing, severely impacting its processing efficiency. Summary of the Invention

[0003] One object of this disclosure is to provide a new reset processing method for computing cores to reduce the time overhead of computing core reset waiting.

[0004] According to a first aspect of this disclosure, a reset processing method for a computing core is provided, the method comprising: On the transmission path where the computing core reports interrupt information to the instruction controller, the abnormal interrupt information sent by the computing core due to an abnormal instruction packet processing is intercepted, and the firmware is instructed to perform a reset operation on the computing core based on the abnormal interrupt information. In response to the firmware reset completion notification, the abnormal interruption information is released to the instruction controller, so that the instruction controller updates the instruction packet tracking record based on the abnormal interruption information.

[0005] Optionally, intercepting the exception interruption information issued by the computing core due to an abnormal processing instruction packet includes: The gating unit latches the exception interrupt information issued by the computing kernel due to an abnormal processing instruction packet.

[0006] Optionally, the indicator firmware performs a reset operation on the computing core based on the abnormal interruption information, including: By setting the gating enable flag, the firmware is instructed to perform a reset operation on the computing core based on the abnormal interrupt information; The reset completion notification is sent by the firmware after the reset operation is completed by clearing the gating enable flag.

[0007] Optionally, the method further includes: Receive interrupt information from the computing core; Determine the type of the interruption information; If the interrupt information is the abnormal interrupt information, the steps of intercepting the abnormal interrupt information issued by the computing core based on the abnormal processing instruction packet are executed, and the firmware is instructed to reset the computing core based on the abnormal interrupt information are performed. If the interrupt information is an instruction completion interrupt information, the instruction completion interrupt information is released to the instruction controller so that the instruction controller updates the instruction packet tracking record based on the instruction completion interrupt information.

[0008] Optionally, the abnormal interrupt information issued by the computing core is returned to the instruction controller via the instruction completion queue; the instruction completion queue is also used to receive instruction completion interrupt information issued by the computing core after the instruction packet is completed normally. The process of releasing the abnormal interruption information to the instruction controller includes: The abnormal interruption information is released into the instruction completion queue, so that the abnormal interruption information is returned to the instruction controller via the instruction completion queue.

[0009] Optionally, the instruction controller manages instruction packets corresponding to multiple computing cores; the method is implemented by an interrupt handling unit, and the multiple computing cores are configured one-to-one with the multiple interrupt handling units; the step of intercepting the abnormal interrupt information issued by the computing core due to an abnormal instruction packet processing, and instructing the firmware to perform a reset operation on the computing core based on the abnormal interrupt information, includes: Intercept the abnormal interrupt information issued by the corresponding computing core due to an abnormal processing instruction packet, and instruct the firmware to perform a reset operation on the corresponding computing core based on the abnormal interrupt information.

[0010] Optionally, the firmware is configured to detect the status indications of multiple interrupt handling units in a polling manner, and when any interrupt handling unit is detected to have pending abnormal interrupt information, to perform a reset operation on the corresponding computing core based on the abnormal interrupt information intercepted by the interrupt handling unit.

[0011] Optionally, the exception interrupt information released by each interrupt handling unit is returned to the instruction controller via the instruction completion queue; multiple interrupt handling units share one instruction completion queue.

[0012] Optionally, the computing core is a computing core that performs video encoding and decoding tasks.

[0013] According to a second aspect of this disclosure, a computing device is also provided, comprising: Multiple computing cores; The instruction controller is used to manage instruction packets corresponding to the multiple computing cores and maintain instruction packet tracking records for the instruction packets that have been issued to the multiple computing cores. An interrupt handling unit is located on the transmission path from the computing core to the instruction controller for reporting interrupt information; the interrupt handling unit is configured to perform the method according to the first aspect of this disclosure.

[0014] Optionally, the computing device includes a plurality of interrupt handling units, each of which is configured in one-to-one correspondence with a plurality of computing cores. The interrupt handling unit is located on the transmission path from the corresponding computing core to the instruction controller for reporting interrupt information, and is used to intercept abnormal interrupt information sent by the corresponding computing core.

[0015] According to a third aspect of this disclosure, a computing system is also provided, the computing system including a control device and the computing device according to a second aspect of this disclosure, the control device being configured to send instruction packets of a required processing task to the computing device.

[0016] In this embodiment, the interrupt handling unit intercepts the abnormal interrupt information sent by the computing core due to an error in processing instruction packets on the transmission path from the computing core to the instruction controller. After the firmware completes the reset of the computing core based on the abnormal interrupt information, the abnormal interrupt information is released to the instruction controller. This allows the instruction controller to update its maintained instruction packet tracking records, thereby maintaining the pairing relationship between the issued instruction packets and the interrupt information that serves as the instruction packet execution response, ensuring system state consistency. In this embodiment, by intercepting the abnormal interrupt information, the firmware can first handle the reset of the abnormal interrupt information without immediately synchronizing it to the instruction controller. This avoids the serial dependency problem where the firmware must wait for the instruction controller to complete the clearing of incomplete count values ​​before resetting the computing core. Therefore, the firmware can reset the computing core first, allowing it to quickly resume normal processing of instruction packets, effectively improving the processing efficiency of the computing core.

[0017] The features and advantages of the embodiments of this specification will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of this specification and, together with their description, serve to explain the principles of these embodiments.

[0019] Figure 1 This is a schematic diagram of the structure of a computing system to which the methods of the embodiments of this disclosure can be applied; Figure 2 This is a schematic diagram of the structure of a computing device; Figure 3 This is a flowchart illustrating a reset process according to some embodiments; Figure 4 This is a flowchart illustrating a reset process according to other embodiments; Figure 5 This is a schematic diagram of the structure of a computing device according to some embodiments; Figure 6 This is a schematic diagram of the structure of a computing device according to other embodiments. Detailed Implementation

[0020] Various exemplary embodiments of this specification will now be described in detail with reference to the accompanying drawings.

[0021] The following description of at least one exemplary embodiment is merely illustrative and is not intended to limit the embodiments of this specification or their application or use.

[0022] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0023] This disclosure relates to a reset handling method when an exception occurs during the execution of an instruction package by a computing kernel. Figure 1 This is a schematic diagram of the composition structure of a computing system 1000 to which the reset processing method provided in the embodiments of this disclosure can be applied.

[0024] like Figure 1 As shown, the computing system 1000 includes a computing device 1100, a control device 1200, and a storage device 1300. The computing device, control device, and storage device can communicate with each other via a bus network or other means.

[0025] Storage device 1300 is used to store instructions and / or data, which can be retrieved and used by a control device or a computing device. For example, the storage device can store program instructions executed by the control device or the computing device, or it can store data such as text, images, audio, and configuration parameters. Control device 1200 is used to control the computing device to perform related tasks to achieve corresponding system functions, such as artificial intelligence, scientific computing, image processing, and video processing based on user needs. Exemplarily, the control device can be a central processing unit (CPU); the computing device can be a graphics processing unit (GPU), a general-purpose graphics processing unit (GPGPU), a neural network processing unit (NPU), or a tensor processing unit (TPU); the storage device can be static random access memory (SRAM), read-only memory (ROM), or erasable programmable read-only memory (EPROM). The storage device may also be referred to as memory, and the computing device 1100 may also be referred to as a chip, processor, or artificial intelligence chip. It is understood that the computing system 1000 may also be referred to as an artificial intelligence chip or artificial intelligence system, and this disclosure does not limit it in this way.

[0026] The aforementioned control device 1200 is used to break down the target task into multiple subtasks, each subtask corresponding to an instruction packet. Taking a video processing task as an example, the control device 1200 is used to pre-break down the video processing task into multiple instruction packets, each instruction packet corresponding to the processing of one video frame, and send the multiple instruction packets to the instruction controller for management.

[0027] The aforementioned computing device 1100 is equipped with multiple computing cores for executing tasks, an instruction controller for managing instruction packets corresponding to the multiple computing cores, and a task distribution unit for these computing cores. The instruction controller distributes instruction packets to the corresponding computing cores for processing through the task distribution unit.

[0028] Taking video processing tasks as an example, the computing device 1100 has a video processing module (Video Codec), which is responsible for decoding the raw data used for training or inference. The decoded data is then used by the GPU computing cores for training or inference. Figure 2As shown, the video processing module of computing device 1100 may include an instruction controller 1130, a task distribution unit 1110, and multiple computing cores 1120 for performing video encoding and decoding tasks. Figure 2 The diagram schematically shows four computing cores: computing core 1120-0, computing core 1120-1, computing core 1120-2, and computing core 1120-3. In the video processing module, the task distribution unit 1110 is also referred to as the Video Command Processor Dispatch (VCPD).

[0029] The task distribution unit includes an instruction delivery module, which receives instruction packets from the instruction controller and delivers them to the corresponding computing cores for execution. The instruction delivery module may include, for example, multiple instruction channels, an instruction channel selection unit, multiple computing core instruction cache units, and a computing core instruction cache selection unit.

[0030] Multiple instruction channels are configured to receive instruction packets from the instruction controller. Each instruction channel can be configured with its own instruction distribution control state machine.

[0031] The instruction channel selection unit is configured to select from multiple instruction channels.

[0032] When selecting an instruction channel, the instruction channel selection unit may use the following method: if the instruction cache unit of the computational core corresponding to the computational core pointed to by the instruction packet at the head of the queue in the current instruction channel is not full, then the current instruction channel is determined as a candidate instruction channel, and the instruction allocation control state machine of the instruction channel is set to the candidate allocation state; then, all candidate instruction channels are randomly selected to determine the selected instruction channel.

[0033] The number of instruction cache units for multiple computing cores is the same as the number of computing cores. Each instruction cache unit corresponds one-to-one with a computing core and is used to temporarily store instruction packets destined for that core. Instruction packets from the selected instruction channel are cached in the instruction cache unit corresponding to the computing core to which the instruction packet is destined.

[0034] The core instruction cache selection unit is configured to select a core instruction cache unit that is in a non-empty state and whose corresponding core is in an idle state, and then read the instruction packets from the selected core instruction cache unit and send them to the corresponding core. The instruction channel selection operation and the core instruction cache unit selection operation can be performed in parallel within the same clock cycle.

[0035] Taking video processing tasks as an example, if an exception occurs during the execution of instruction packets by the computing core, an exception interruption message will be issued. This exception interruption message is sent to the instruction controller 1130 and the firmware responsible for exception handling via the task distribution unit 1110. To ensure system state consistency, the firmware needs to wait for the instruction controller to complete the tracking and recording of the corresponding instruction packets it maintains before it can perform a reset operation on the computing core, resulting in a long waiting delay for the computing core to resume normal processing. The instruction controller can track and record the issued instruction packets by maintaining an "Outstanding" count value. The instruction controller increments this count value by 1 for each issued instruction packet and decrements it by 1 for each interruption message corresponding to that instruction packet it receives. Depending on the instruction packet processing status of the computing core, this interruption message may be a normally completed instruction completion interruption message or an exception interruption message.

[0036] Furthermore, the firmware can only respond to and process abnormal interruption information from a single computing core at a time. If multiple computing cores issue abnormal interruption information simultaneously, the excessively long waiting latency will further reduce the overall processing efficiency of the computing cores. Although related technologies optimize this by deploying multiple firmware files to handle abnormal interruptions from different computing cores, this approach significantly increases software resource overhead.

[0037] To address this, this disclosure proposes a reset processing scheme. On the transmission path from the computing core to the instruction controller, abnormal interrupt information generated by the computing core due to an abnormal processing instruction packet is intercepted. After the firmware completes the reset operation of the computing core based on the abnormal interrupt information, the abnormal interrupt information is released to the instruction controller for updating the instruction packet tracking record. This enables the firmware to respond quickly to the abnormal interrupt information of the computing core, effectively reducing the waiting delay for the computing core reset and recovery.

[0038] The following will combine Figure 1 The computing system shown and Figure 2 The computing device shown illustrates various embodiments of this disclosure.

[0039] <First Embodiment> Figure 3 A reset processing method for a computing core according to some embodiments is illustrated, which can be implemented by an interrupt handling unit set up in the task distribution unit of the computing device. For example... Figure 3 As shown, the reset processing method of this embodiment may include the following steps S310 and S320.

[0040] Step S310: On the transmission path of the computing core reporting interrupt information to the instruction controller, intercept the abnormal interrupt information sent by the computing core due to an abnormal instruction packet processing, and instruct the firmware to perform a reset operation on the computing core based on the abnormal interrupt information.

[0041] In this embodiment, the interrupt handling unit is located on the transmission path from the computing core to the instruction controller when reporting interrupt information. When an exception occurs during the processing of an instruction packet, the computing core generates an exception interrupt message, which is intercepted by the interrupt handling unit on the path to the instruction controller.

[0042] A computing core, for example, is a video core that performs video encoding and decoding tasks, while an instruction packet is an instruction packet that processes video frames. During task execution, the video core may encounter various abnormal situations, such as decoding timeouts, encoding errors, bus access errors, and memory overflows. When these abnormalities occur, the computing core generates corresponding exception interrupt information.

[0043] Those skilled in the art will understand that the method of this embodiment is also applicable to computing cores that perform general computing tasks, and this disclosure does not limit it.

[0044] In some examples, the interrupt handling unit includes a gate to latch the exception interrupt information. This gate can be implemented using hardware logic such as register circuitry. After receiving the exception interrupt information from the computation core, the gate temporarily stores the exception interrupt information within the gate and does not immediately transmit it to the instruction controller.

[0045] In some examples, after the interrupt handling unit intercepts and temporarily stores abnormal interrupt information, it can initiate an abnormal interrupt handling request to the firmware. This triggers the firmware to read the temporarily stored abnormal interrupt information within the interrupt handling unit and perform a reset operation on the computing core corresponding to the abnormal interrupt information. The abnormal interrupt information carries a computing core identifier and an exception type identifier. The firmware can locate the target computing core based on the computing core identifier and match the corresponding reset operation based on the exception type identifier, thus restoring the computing core to normal business processing capabilities.

[0046] In other examples, after the interrupt handling unit intercepts abnormal interrupt information, it instructs the firmware to process the intercepted abnormal interrupt information by setting the gating enable flag.

[0047] In this embodiment, the firmware performing a reset operation on the computing core may include: the firmware sending a reset command to the target computing core, which controls the computing core to terminate the currently processed instruction packet and return to the initial working state; the firmware waiting to receive a reset completion response signal from the computing core to confirm that the reset operation was successfully executed.

[0048] Taking video processing tasks as an example, an anomaly in the processing of a single video frame does not affect the overall progress of the video processing task. After the malfunctioning computing core is reset and its normal processing capability is restored, it can continue to process other instruction packets in the subsequent video processing task.

[0049] In step S320, in response to the firmware reset completion notification, the abnormal interrupt information is released to the instruction controller so that the instruction controller updates the instruction packet tracking record based on the abnormal interrupt information.

[0050] After completing the reset operation on the computing core, the firmware sends a reset completion notification to the interrupt handling unit. Upon receiving the reset completion notification, the interrupt handling unit releases the exception interrupt information, enabling it to return to the instruction controller to update the instruction packet tracking record. This maintains the correspondence between the issued instruction packets and the received interrupt information, ensuring normal task operation.

[0051] In some examples, the instruction packet trace includes an outstanding value for incomplete calculations of issued instruction packets. The instruction controller can track the completion status of issued instruction packets by maintaining the outstanding count. In this example, the instruction controller cleans up the instruction packet trace based on abnormal interruption information, including updating the outstanding count based on the abnormal interruption information. Specifically, upon receiving the abnormal interruption information, the instruction controller decrements the outstanding count by 1.

[0052] In other examples, the instruction packet trace log includes instruction packet trace entries. The instruction controller maintains a trace entry for each issued instruction packet. In this example, the instruction controller cleans up the instruction packet trace log based on abnormal interruption information, including: the instruction controller deleting the trace entry for the instruction packet corresponding to the abnormal interruption information, or updating the status field in the trace entry to "completed" or "abnormally completed," etc.

[0053] In some examples, the reset completion notification is achieved by the firmware clearing the gating enable flag of the interrupt handler after completing the reset operation. In this example, the gating enable flag is reused by the interrupt handler and the firmware to save hardware resources. When the interrupt handler intercepts an abnormal interrupt message, it can set the gating enable flag (e.g., set it to 1); after completing the reset operation, the firmware notifies the interrupt handler to release the latched abnormal interrupt message by clearing the gating enable flag (e.g., setting it to 0).

[0054] In other examples, the reset completion notification may also be sent by the firmware in a pulse manner via a separate signal line, such as a reset completion notification via a rising edge or falling edge pulse signal.

[0055] In this embodiment, after receiving a reset completion notification, the interrupt handling unit releases the intercepted abnormal interrupt information to the instruction controller. Upon receiving this abnormal interrupt information, the instruction controller recognizes that the abnormal interrupt handling for the corresponding instruction packet has ended, and at this point, the tracking record of the instruction packet indicated by the abnormal interrupt information can be cleared.

[0056] Taking a video processing task as an example, when a computing core encounters an anomaly while processing a video frame corresponding to a certain instruction packet, it sends an anomaly interrupt message to the task distribution unit. This anomaly interrupt message is intercepted upon reaching the interrupt handling unit. The interrupt handling unit then triggers the firmware to perform a reset operation on the corresponding computing core based on the anomaly interrupt message, enabling the computing core to restore its normal processing capabilities and continue processing subsequent instruction packets in the video processing task. After the firmware completes the reset operation, the interrupt handling unit releases the anomaly interrupt message to the instruction controller, allowing the instruction controller to decrement the incomplete count value, etc. The fact that some video frames cannot be processed normally does not affect the validity of the results of the remaining normally processed frames in the video task.

[0057] In some examples, exception interrupt messages issued by the computing core due to an error in processing an instruction packet, and instruction completion interrupt messages issued by the computing core when it successfully completes instruction packet processing, are both returned to the instruction controller via the instruction completion queue in the task distribution unit. This instruction completion queue is used to cache interrupt messages awaiting return to the instruction controller and manages them in a first-in, first-out (FIFO) manner. The depth of the instruction completion queue can be configured based on the number of computing cores and the expected number of concurrent interrupts. In this embodiment, the entry of interrupt message into the instruction completion queue indicates that the instruction packet corresponding to the interrupt message has been completed normally or terminated abnormally. After reading the interrupt message from the instruction completion queue, the instruction controller sequentially updates the instruction packet tracking record until it confirms that all instruction packets for the current task have been completed. By returning both types of interrupt messages via the same instruction completion queue, the instruction controller does not need to distinguish between the types of interrupt messages; it only needs to read the interrupt messages sequentially from the queue and update the instruction packet tracking record, thereby simplifying the instruction controller's processing logic and reducing hardware implementation complexity.

[0058] In this example, releasing the exception interrupt information to the instruction controller in step S320 may include: releasing the exception interrupt information into the instruction completion queue, so that the exception interrupt information returns to the instruction controller via the instruction completion queue.

[0059] Based on steps S310 and S320 above, this embodiment intercepts the abnormal interrupt information sent by the computing core through the interrupt handling unit, enabling the firmware to intervene and process the abnormal interrupt information before it reaches the instruction controller, without waiting for the instruction controller to complete the update of the incomplete count value. This significantly shortens the reset time of the computing core, allowing it to recover to normal status and receive new instruction packets more quickly, thereby improving the overall processing efficiency.

[0060] Furthermore, since the method in this embodiment reduces the time overhead of waiting for the computing core to reset, when multiple computing cores issue abnormal interrupt information, the abnormal interruption can be reset sequentially by a single firmware, without having to configure independent firmware for each computing core to alleviate the pressure of reset waiting, thereby effectively reducing software overhead.

[0061] <Second Embodiment> In this embodiment, all types of interrupt information issued by the computing core are routed to the interrupt handling unit for classification and processing. These interrupt information types include exception interrupt information and instruction completion interrupt information. The interrupt handling unit identifies the type of the received interrupt information and adopts different processing strategies for different types of interrupt information based on the identification results.

[0062] Figure 4 A flowchart illustrating the reset processing method of this embodiment is shown. Figure 4 As shown, the method includes the following steps S400 to S430.

[0063] Step S400: Receive interrupt information from the computing core and determine the type of interrupt information.

[0064] The interrupt handling unit can determine the type of interrupt information by checking specific identifier fields in the interrupt information. For example, the interrupt information may contain a type identifier bit, where a value of 0 indicates a normal instruction completion interrupt, and a value of 1 indicates an exception interrupt, etc.

[0065] Step S410: If the interrupt information is an abnormal interrupt information, intercept the abnormal interrupt information issued by the computing core based on the abnormal processing instruction packet, instruct the firmware to reset the computing core based on the abnormal interrupt information, and wait for the firmware to return a reset completion notification.

[0066] In step S420, in response to the firmware reset completion notification, the abnormal interrupt information is released to the instruction controller so that the instruction controller updates the instruction packet tracking record based on the abnormal interrupt information.

[0067] Step S430: If the interrupt information is an instruction completion interrupt information, release the instruction completion interrupt information to the instruction controller so that the instruction controller updates the instruction packet tracking record based on the instruction completion interrupt information.

[0068] In this embodiment, the interrupt handling unit does not intercept normal instruction completion interruption information, but directly transmits it to the instruction controller. After receiving the instruction completion interruption information, the instruction controller can update the incomplete count value (decrement by 1), indicating that the instruction packet has been processed.

[0069] According to steps S400 to S430, this embodiment routes all interrupt information to the interrupt processing unit for centralized classification and processing. This can effectively reduce hardware complexity compared to setting independent transmission paths for different types of interrupt information.

[0070] <Third Embodiment> In this embodiment, as Figure 5 As shown, the computing device is equipped with multiple interrupt handling units, each configured in a one-to-one correspondence with multiple computing cores. Each interrupt handling unit is located on the transmission path from the corresponding computing core to the instruction controller to report interrupt information. It is used to receive abnormal interrupt information issued by the corresponding computing core, or, as in the second embodiment described above, to receive various types of interrupt information issued by the corresponding computing core and classify and process different types of interrupt information.

[0071] This embodiment configures an independent interrupt handling unit for each computing core, enabling the parallel latching and independent release of abnormal interrupt information for each core. When multiple computing cores experience simultaneous exceptions, each interrupt handling unit can simultaneously intercept and latch the abnormal interrupt information of its corresponding core, eliminating the need for queuing and significantly improving the response speed to concurrent exceptions. Furthermore, in the example where all types of interrupt information are categorized and processed by the interrupt handling unit, since each unit only deals with a single computing core, it can instantly identify and quickly release instruction completion interrupt information without increasing the latency of normal instruction responses. Simultaneously, each interrupt handling unit only needs to process the interrupt information of its corresponding computing core; its internal state machine does not need to distinguish the interrupt source, greatly simplifying the hardware logic and resulting in a more regular overall hardware structure, facilitating implementation and verification.

[0072] Of course, in another embodiment, abnormal interrupt information from multiple computing cores can also be processed by a single interrupt handling unit based on a cache queuing mechanism.

[0073] For example, such as Figure 5As shown, the computing device includes four computing cores: computing core 1120-0, computing core 1120-1, computing core 1120-2, and computing core 1120-3. Correspondingly, the computing device is equipped with four interrupt handling units: interrupt handling unit 1111-0, interrupt handling unit 1111-1, interrupt handling unit 1111-2, and interrupt handling unit 1111-3.

[0074] In some examples, each interrupt handling unit contains a gating unit. The gating unit is used to intercept and temporarily store exception interrupt information issued by the corresponding computing core.

[0075] In some examples, when two or more computing cores simultaneously issue abnormal interrupt messages, a single firmware unit sequentially processes the abnormal interrupt messages intercepted by each interrupt handling unit. In this example, because the abnormal interrupt messages are intercepted by the interrupt handling unit, the firmware can directly perform a reset operation on the abnormal computing core without waiting for the instruction controller to first complete the cleanup of instruction packet trace records. Therefore, even in scenarios where multiple computing cores issue abnormal interrupt messages simultaneously, by using a single firmware unit to sequentially process the abnormal resets of each computing core in a polling manner, a rapid response to abnormal events of each computing core can be achieved, without the need to configure independent firmware for each computing core to alleviate the pressure of reset waiting. Thus, while ensuring the real-time nature of exception handling, software overhead and system complexity are significantly reduced.

[0076] For example, the firmware is configured to poll the status indicators of multiple interrupt handling units, and when any interrupt handling unit is detected to have pending abnormal interrupt information, to perform a reset operation on the corresponding computing core based on the abnormal interrupt information intercepted by that interrupt handling unit.

[0077] When two or more computing cores simultaneously issue abnormal interrupt messages, the firmware will respond to the instructions of each interrupt handling unit in a polling order, processing the abnormal interrupt messages intercepted by each interrupt handling unit one by one. For example, if computing core 0 and computing core 1 both issue abnormal interrupt messages, the abnormal interrupt message issued by computing core 0 will be intercepted by interrupt handling unit 0, and the abnormal interrupt message issued by computing core 1 will be intercepted by interrupt handling unit 1. Interrupt handling units 0 and 1 will respectively instruct the firmware to process the messages. Following the polling order, the firmware first detects that interrupt handling unit 0 has pending abnormal interrupt messages. At this time, based on the abnormal interrupt messages intercepted by interrupt handling unit 0, it performs a reset operation on computing core 0 and sends a reset completion notification to interrupt handling unit 0 after the reset is complete. Subsequently, the firmware detects that interrupt handling unit 1 has pending abnormal interrupt messages. At this time, it performs a reset operation on computing core 1 and sends a reset completion notification to interrupt handling unit 1 after the reset is complete.

[0078] For example, firmware can also use an interrupt-driven approach to respond to abnormal interrupt handling requests from the interrupt handling unit, and process the trigger events from different interrupt handling units in sequence according to the order of the requests.

[0079] See in some examples Figure 5 Although the computing device is configured with multiple interrupt handling units (e.g., 4), these interrupt handling units can share a single instruction completion queue 1112. All abnormal interrupt information released by each interrupt handling unit, or various types of interrupt information (including instruction completion interrupt information and abnormal interrupt information), are written into the same instruction completion queue 1112, and then uniformly output to the instruction controller by the instruction completion queue 1112.

[0080] The instruction completion queue can be managed using a first-in, first-out (FIFO) method to ensure that the interrupt information written first is output to the instruction controller first, thus maintaining the timing order of the interrupt information.

[0081] <Fourth Embodiment> This disclosure also provides a computing device, such as a computing device that is Figure 1 The computing device 1100 is configured, in some embodiments, to perform a reset processing method according to any embodiment of the present disclosure.

[0082] In some embodiments, such as Figure 6 As shown, the computing device 1100 may include multiple computing cores 1120, an instruction controller 1130, and an interrupt handling unit 1111.

[0083] Multiple computing cores 1120 are used to receive and execute instruction packets. In some examples, the computing cores are video encoding / decoding computing cores, used to perform video decoding or encoding tasks. When an exception occurs during the processing of an instruction packet, the computing core generates an exception interrupt message.

[0084] The instruction controller 1130 is used to manage instruction packets corresponding to multiple computing cores and maintain instruction packet tracking records for instruction packets issued to multiple computing cores.

[0085] Interrupt handling unit 1111 is located on the transmission path from the computing core to the instruction controller for reporting interrupt information. This interrupt handling unit is configured to execute a reset processing method according to any embodiment of this disclosure, including: intercepting abnormal interrupt information issued by the computing core due to an error in processing an instruction packet, and instructing the firmware to perform a reset operation on the computing core based on the abnormal interrupt information; and, in response to a reset completion notification from the firmware, releasing the abnormal interrupt information to the instruction controller, so that the instruction controller updates the instruction packet tracking record based on the abnormal interrupt information.

[0086] In some examples, the interrupt handling unit includes a gating unit for latching abnormal interrupt information. The gating unit has a gating enable flag to indicate whether it is in an intercepting state, i.e., to indicate whether abnormal interrupt information exists. When the gating unit intercepts abnormal interrupt information, the gating enable flag is set. Accordingly, after completing a reset operation, the firmware can notify the gating unit to release the abnormal interrupt information by clearing the gating enable flag.

[0087] In some examples, the computing device also includes an instruction completion queue for caching interrupt information to be returned to the instruction controller.

[0088] In some examples, the computing device includes multiple interrupt handling units configured one-to-one with the multiple computing cores. The interrupt handling unit is located on the transmission path from the corresponding computing core to the instruction controller to report interrupt information, and is used to receive abnormal interrupt information issued by the corresponding computing core, or to receive various types of interrupt information issued by the corresponding computing core.

[0089] <Fifth Embodiment> This disclosure also provides a computing system, which includes a control device and a computing device. The computing device can be the computing device according to the second embodiment. The control device is used to generate a sequence of computing core instruction packets corresponding to a task oriented towards the computing device, and to send these computing core instruction packets to the computing device for execution.

[0090] The computing device of this computing system is, for example, Figure 1 The computing device 1100 and the control device are, for example, Figure 1 The control device 1200 in the middle.

[0091] The form of the computing system can be a chip, module, terminal device, workstation or server, etc., without limitation.

[0092] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0093] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and apparatuses according to various embodiments of this specification. In this regard, each block in a flowchart or block diagram may represent a module, unit, or part of a circuit. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using hardware that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. Unless otherwise specified, implementation in hardware, implementation in software, and implementation using a combination of software and hardware can be equivalent.

[0094] Various embodiments of this specification have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A reset processing method for computing cores, characterized in that, The method includes: On the transmission path where the computing core reports interrupt information to the instruction controller, the abnormal interrupt information sent by the computing core due to an abnormal instruction packet processing is intercepted, and the firmware is instructed to perform a reset operation on the computing core based on the abnormal interrupt information. In response to the firmware reset completion notification, the abnormal interruption information is released to the instruction controller, so that the instruction controller updates the instruction packet tracking record based on the abnormal interruption information.

2. The method according to claim 1, characterized in that, The interception of the exception interruption information issued by the computing kernel due to an abnormal processing instruction packet includes: The gating unit latches the exception interrupt information issued by the computing kernel due to an abnormal processing instruction packet.

3. The method according to claim 1, characterized in that, The firmware instruction performs a reset operation on the computing core based on the abnormal interruption information, including: By setting the gating enable flag, the firmware is instructed to perform a reset operation on the computing core based on the abnormal interrupt information; The reset completion notification is sent by the firmware after the reset operation is completed by clearing the gating enable flag.

4. The method according to claim 1, characterized in that, The method further includes: Receive interrupt information from the computing core; Determine the type of the interruption information; If the interrupt information is the abnormal interrupt information, the steps of intercepting the abnormal interrupt information issued by the computing core based on the abnormal processing instruction packet are executed, and the firmware is instructed to reset the computing core based on the abnormal interrupt information are performed. If the interrupt information is an instruction completion interrupt information, the instruction completion interrupt information is released to the instruction controller so that the instruction controller updates the instruction packet tracking record based on the instruction completion interrupt information.

5. The method according to any one of claims 1 to 4, characterized in that, The abnormal interrupt information issued by the computing core is returned to the instruction controller via the instruction completion queue; the instruction completion queue is also used to receive the instruction completion interrupt information issued by the computing core after the instruction packet is completed normally. The process of releasing the abnormal interruption information to the instruction controller includes: The abnormal interruption information is released into the instruction completion queue, so that the abnormal interruption information is returned to the instruction controller via the instruction completion queue.

6. The method according to any one of claims 1 to 4, characterized in that, The method is implemented by an interrupt handling unit; the instruction controller manages instruction packets corresponding to multiple computing cores; the multiple computing cores are configured in a one-to-one correspondence with the multiple interrupt handling units; the step of intercepting the abnormal interrupt information issued by the computing core due to an abnormal instruction packet processing, and instructing the firmware to perform a reset operation on the computing core based on the abnormal interrupt information, includes: Intercept the abnormal interrupt information issued by the corresponding computing core due to an abnormal processing instruction packet, and instruct the firmware to perform a reset operation on the corresponding computing core based on the abnormal interrupt information.

7. The method according to claim 6, characterized in that, The firmware is configured to detect the status indications of multiple interrupt handling units in a polling manner, and when any interrupt handling unit is detected to have pending abnormal interrupt information, to perform a reset operation on the corresponding computing core based on the abnormal interrupt information intercepted by the interrupt handling unit.

8. The method according to claim 6, characterized in that, The exception interrupt information released by each interrupt handling unit is returned to the instruction controller via the instruction completion queue; multiple interrupt handling units share one instruction completion queue.

9. The method according to any one of claims 1 to 4, characterized in that, The computing core is the computing core that performs video encoding and decoding tasks.

10. A computing device, characterized in that, include: Multiple computing cores; The instruction controller is used to manage instruction packets corresponding to the multiple computing cores and maintain instruction packet tracking records for the instruction packets that have been issued to the multiple computing cores. An interrupt handling unit is located on the transmission path from the computing core to the instruction controller for reporting interrupt information; the interrupt handling unit is configured to perform the method according to any one of claims 1 to 9.

11. The computing device according to claim 10, characterized in that, The computing device includes multiple interrupt handling units, each configured in a one-to-one correspondence with a plurality of computing cores. Each interrupt handling unit is located on the transmission path from the corresponding computing core to the instruction controller for reporting interrupt information, and is used to intercept abnormal interrupt information sent by the corresponding computing core.

12. A computing system, characterized in that, include: A control device and a computing device, wherein the computing device is the computing device according to claim 10 or 11, and the control device is used to send instruction packets for the required processing tasks to the computing device.

Images