Risc-v many-core processor information fault-tolerant transmission method and device

Abstract

The present application relates to the technical field of processor data transmission, and specifically provides a RISC-V many-core processor information fault-tolerant transmission method and device, wherein at each RISC-V local core, a checkpoint state maintenance module and a local data transceiver counter are arranged, the checkpoint state maintenance module maintains information of a last submitted checkpoint, records general register data, PC data, CSR register data, decoding state, write-back data of the RISC-V core at the time of checkpoint submission, and a current index of a mailbox corresponding to the RISC-V core in a coordination node; the local data transceiver records the number of mailbox interaction information experienced by the RISC-V core since the checkpoint submission, and the transmission information is represented by T and the reception information is represented by R. Compared with the prior art, the present application realizes directional state recovery of the error core, effectively improves the error handling efficiency of the RISC-V many-core processor while reducing resource occupation.

Description

Technical Field

[0001] This invention relates to the field of processor data transmission technology, specifically providing a method and apparatus for fault-tolerant information transmission in a RISC-V many-core processor. Background Technology

[0002] With the rapid development of information technology, key fields such as high-performance computing and artificial intelligence are placing continuous demands on the computing power and data processing throughput of processors. As an open-source and scalable instruction set architecture, the RISC-V architecture is gradually becoming a core research subject in academia and a mainstream development direction in industry due to its significant advantages in design flexibility and cost control. Among them, many-core processors, through their collaborative computing mode with multiple processing cores, can achieve a significant leap in computing performance.

[0003] However, with the continuous increase in the number of cores in many-core processors, the frequency of information exchange between cores is also increasing, and the topology paths are becoming more complex. This trend directly leads to two core technical challenges: first, how to ensure the accuracy of information transmission in high-frequency information exchange scenarios and avoid the risk of data errors caused by transmission link interference, timing delays, and other factors; second, how to construct an efficient error recovery mechanism to minimize the impact of errors on the overall computing performance of the system when transmission errors are unavoidable. These issues have become key bottlenecks restricting the performance improvement of many-core processors in fields such as high-performance computing, and are also the focus of current research in related technologies.

[0004] In the process of many-core processors, the mainstream solutions in the industry usually adopt a layered strategy to address the problem of information transmission error recovery: for a small number of data transmission errors, parity check, Hamming code check and other data packet verification mechanisms are used for processing; for a large number of data transmission errors, message log rollback recovery technology is used to solve the problem.

[0005] However, the former's checksum recovery mechanism has obvious limitations. It can only effectively deal with a small number of data bit errors. In scenarios involving large-scale data transmission, it requires excessive resources for data verification, resulting in a significant decrease in transmission efficiency.

[0006] The latter requires storing the status logs of all cores of the many-core processor. During the checkpoint update phase, the execution of each core needs to be paused. During the error recovery phase, the cores need to be rolled back to the corresponding state based on the logs. This not only consumes a lot of storage resources, but also wastes the execution computing power of non-faulty cores. Summary of the Invention

[0007] This invention addresses the shortcomings of the prior art by providing a highly practical RISC-V many-core processor information fault-tolerant transmission method.

[0008] A further technical objective of this invention is to provide a reasonably designed, safe, and applicable fault-tolerant information transmission device for RISC-V many-core processors.

[0009] The technical solution adopted by this invention to solve its technical problem is:

[0010] A fault-tolerant information transmission method for RISC-V many-core processors is proposed, in which a checkpoint status maintenance module and a local data transceiver counter are set up at each RISC-V local core. The checkpoint status maintenance module maintains the information of the last committed checkpoint C0, and records the general-purpose register data, PC value data, CSR register data, decoding module status, write-back data, and the current index y0 of the corresponding mailbox of the RISC-V core in the coordination node when checkpoint C0 is committed.

[0011] The local data transceiver records the number of mailbox interactions experienced by the RISC-V core since checkpoint C0 was committed, with sent information denoted by T and received information denoted by R.

[0012] Furthermore, multiple RISC-V cores participate in the computation, and the submitted checkpoint is C0. The specific implementation steps are as follows:

[0013] S1. First, each core sends information to each other when performing its daily work tasks after the previous checkpoint C0.

[0014] S2, the mailbox communication storage module in the coordination node, completes the corresponding core forwarding of messages, and updates its own storage information and log information;

[0015] S3. Each RISC-V core updates its local data transmission and reception counter after the previous checkpoint C0 based on the data transmission and reception status.

[0016] S4. Determine the RISC-V core directory where communication exists and the total number of received information for each RISC-V core.

[0017] S5. The checkpoint update module in the coordination node sends a checkpoint update signal to the RISC-V core directory with which there is communication, along with the total number of information to be received.

[0018] S6. After the RSIC-V core with communication receives the checkpoint update signal, it compares the total number of core information to be received with the total number of information actually received locally.

[0019] S7. After receiving the ready signals from all RISC-V core directories that are communicating, the checkpoint update module in the coordination node verifies the consistency between the total number of sent messages and the total number of received messages.

[0020] S8. After receiving the checkpoint confirmation signal, the RISC-V core with communication receives the checkpoint confirmation signal, determines the temporary checkpoint C1 as the submitted checkpoint C1, and deletes irrelevant data before C0.

[0021] S9. If a RISC-V core fails subsequently, only the failed RISC-V core and the core object corresponding to the failed RISC-V core information output will perform the recovery operation, while other RISC-V cores will operate normally.

[0022] Further, step S1 includes:

[0023] S1-1, RISC-V core A sends two messages (M1, M2) to RISC-V core B.

[0024] S1-2, RISC-V core B sends a message (M3) to RISC-V core C.

[0025] S1-3, the RISC-V core C did not send messages to other cores.

[0026] Further, step S2 includes:

[0027] The information corresponding to the S2-1 and RISC-V core A mailboxes is empty;

[0028] The corresponding information for the S2-2 and RISC-V core B mailboxes is [M1, M2];

[0029] The corresponding information for the S2-3 and RISC-V core C mailbox is [M3];

[0030] S2-4. Record the currently existing RSIC-V cores for communication as tran_core=[A, B, C].

[0031] Further, step S3 includes:

[0032] S3-1, RISC-V core A sends data T A =2, Receive data R A =0;

[0033] S3-2, RISC-V core B sends data T B =1, receive data R B =2;

[0034] S3-3, RISC-V core C sends data T C =0, receive data R C =1.

[0035] Furthermore, in step S4, there exists a RISC-V core directory tran_core=[A, B, C] for communication, and the total number of received messages for each RISC-V core num_message={core A =0, core B =2, core C =1};

[0036] In step S5, the RISC-V core directory with communication is tran_core=[A, B, C], and the total number of messages to be received is num_message={core A =0, core B =2, core C =1}.

[0037] (1) Send a checkpoint update signal to RISC-V core A, with the information coreA=0;

[0038] (2) Send a checkpoint update signal to RISC-V core B, with the information coreB=2;

[0039] (3) Send a checkpoint update signal to the RISC-V core C, with the information coreC=1.

[0040] Further, in step S6, the total number of core information to be received, core_i, is compared with the total number of information actually received locally, Ri, as follows:

[0041] S6-1, RISC-V Core A: If core A and R A If they are equal, the core creates a temporary checkpoint C1, records the general-purpose register data, PC value data, CSR register data, decoding module status, write-back data, and the current index y1 of the mailbox corresponding to RISC-V core A in the coordinating node, and sends a ready signal back to the checkpoint update module of the coordinating node.

[0042] S6-2, RISC-V Core B: If coreB is equal to RB, the core creates a temporary checkpoint C1, records the general-purpose register data, PC value data, CSR register data, decoder module status, write-back data, and the current index y2 of the mailbox corresponding to RISC-V core B in the coordinating node, and sends a ready signal back to the checkpoint update module of the coordinating node.

[0043] S6-3, RISC-V Core C: If coreC is equal to RC, the core creates a temporary checkpoint C1, records the general-purpose register data, PC value data, CSR register data, decoder module status, write-back data, and the current index y3 of the mailbox corresponding to RISC-V core C in the coordinating node, and sends a ready signal back to the checkpoint update module of the coordinating node.

[0044] S6-4. If the core_i of a certain RISC-V core is not equal to the total number of information actually received locally R_i, then wait for the core to complete data reception before creating a temporary checkpoint C1 and sending a ready signal to the checkpoint update module of the coordinating node.

[0045] Further, in step S7, after the checkpoint update module in the coordinating node receives the ready signals from all RISC-V core directories tran_core=[A, B, C] that are communicating, it verifies the consistency between the sum of sent messages and the sum of received messages, that is, whether TA+TB+TC of each RISC-V core is equal to RA+RB+RC. When the two are equal, the checkpoint update module sends a checkpoint confirmation signal to the RISC-V core directories tran_core=[A, B, C] that are communicating.

[0046] In step S8, after the RISC-V core with communication receives the checkpoint confirmation signal, it determines the temporary checkpoint C1 as the submitted checkpoint C1 and deletes irrelevant data before C0.

[0047] Furthermore, in step S9, if a subsequent RISC-V core B fails;

[0048] (1) RISC-V core B: Read its committed checkpoint C1 information and restore the state from checkpoint C1;

[0049] (2) Based on the current index y2 of the mailbox corresponding to the RISC-V core B in the coordinating node recorded in C1, read the data after y2 in the mailbox;

[0050] (3) Determine the destination core of the faulty RISC-V core mailbox and trigger its checkpoint state rollback.

[0051] (4) Only the faulty RISC-V core B and the core object corresponding to the faulty RISC-V core B information output will perform the recovery operation, while other RISC-V cores will operate normally.

[0052] A RISC-V many-core processor information fault-tolerant transmission device includes: at least one memory and at least one processor;

[0053] The at least one memory is used to store a machine-readable program;

[0054] The at least one processor is used to call the machine-readable program to execute a RISC-V many-core processor information fault-tolerant transmission method.

[0055] Compared with the prior art, the RISC-V many-core processor information fault-tolerant transmission method and apparatus of the present invention have the following outstanding advantages:

[0056] The present invention can achieve targeted state recovery of a specific faulty core by tracking the faulty core's own error state and the core object corresponding to the information output, without interfering with the task processes already executed by other cores. While reducing resource consumption, it effectively improves the error handling performance of the RISC-V many-core processor. Attached Figure Description

[0057] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 This is a flowchart illustrating a fault-tolerant information transmission method for RISC-V many-core processors.

[0059] Figure 2 This is a schematic diagram of a coordination node architecture for a fault-tolerant information transmission method in a RISC-V many-core processor.

[0060] Figure 3 This is a schematic diagram of the core architecture of a RISC-V many-core processor information fault-tolerant transmission method. Detailed Implementation

[0061] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to specific embodiments. Obviously, the described embodiments are merely 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.

[0062] The following is a preferred embodiment:

[0063] like Figure 3 As shown, a top-down architecture is used to build a four-level hierarchical network to realize the distribution of computing tasks and data transmission control of the RISC-V core: the third level is the coordination node, which has a built-in checkpoint update module and communication mailbox module, and is responsible for data forwarding and transmission control between RISC-V cores and checkpoint data update function; the bottom level is the RISC-V core module, which is responsible for the execution of computing tasks and the local maintenance of checkpoint data.

[0064] Each coordination node integrates a mailbox communication module and a checkpoint update module. The mailbox communication module is responsible for enabling communication and transmission between the RISC-V cores and recording the transmission log.

[0065] The specific process is as follows: When the source RISC-V core needs to send data to the target RISC-V core, the data is first transmitted to the corresponding underlying coordination node to determine whether the target RISC-V core belongs to the jurisdiction of the underlying coordination node. If it does, the data is written to the mailbox corresponding to the target RISC-V core, the mailbox write pointer is incremented and the mailbox log is updated to record the RISC-V core directory tran_core with communication interaction and the number of data sent and received num_message. If it does not belong to the target RISC-V core, the process is traced to the upper-level coordination node until the coordination node with which the interaction relationship exists is located.

[0066] When a target node needs to obtain data transmitted from other source RISC-V cores, it reads the data from the corresponding mailbox in its underlying coordinating node:

[0067] If valid data exists in the mailbox (i.e., the mailbox write pointer is greater than the read pointer), the data is read, the mailbox read pointer is incremented, the mailbox log is updated, and the communication core directory `tran_core` and the number of data sent and received (`num_message`) are simultaneously refreshed. If there is no valid data in the mailbox, the target RISC-V core enters a waiting state until valid data is written to the mailbox. This mailbox transmission mechanism effectively avoids memory access sequence conflicts caused by memory interaction between RISC-V cores.

[0068] Meanwhile, the checkpoint update module within each coordination node dynamically updates the internal checkpoint status of each RISC-V core as needed, based on host-side instructions or timing strategies.

[0069] Specifically, when the top-level coordinating node needs to update the checkpoint status of each RISC-V core, it distributes the checkpoint update command level by level downwards. Upon receiving the command, each coordinating node first reads the mailbox log information to determine the RISC-V core directory `tran_core` and the number of data transmissions and receptions (`num_message`) that have had communication interactions since the last checkpoint update. Then, it sends a checkpoint update signal to the corresponding RISC-V core in that directory `tran_core`. RISC-V cores without data interactions do not need to participate in this update. The RISC-V cores that need to perform checkpoint updates receive the signal and determine whether they meet the update conditions based on their own operating status. If they do, they send a ready signal back to each coordinating node. When the coordinating node receives the checkpoint ready signals from all RISC-V cores in the directory `tran_core`, it sends a checkpoint confirmation signal to each RISC-V core and simultaneously sends the mailbox index of the corresponding core.

[0070] When a RISC-V core sends a checkpoint rollback signal to the coordinating node, the coordinating node first receives the mailbox index information of that core, resets the read pointer of the corresponding mailbox to that index value, and invalidates the previous mailbox read operation. At the same time, the coordinating node reads the mailbox log information to determine whether the erroneous RISC-V core has sent data to other RISC-V cores. If so, it sends a checkpoint rollback signal to the corresponding target RISC-V core, triggering it to execute the checkpoint rollback operation.

[0071] like Figure 2 As shown, each RISC-V core is internally divided into five pipeline modules: fetch, decode, issue, execute, and write-back, as well as storage modules such as data cache, instruction cache, CSR control status register, and general-purpose registers. During independent execution of the RISC-V core, the fetch module reads the instruction from the instruction cache according to the fetch PC, the decode module completes the instruction decoding, the issue module reads the operands from the general-purpose registers according to the instruction decoding result, the execute module performs the corresponding calculation according to the instruction operation type and operands, and the write-back module writes the calculation result back to the general-purpose registers. The entire process is controlled by the corresponding configuration in the CSR control status register.

[0072] When communication occurs between RISC-V many-core processors, data transmission and reception are completed through the mailbox communication interface. Data communication between RISC-V cores is divided into valid data communication, instruction data communication, and control information communication, which are distinguished by address mapping spaces and mapped to the data cache, instruction cache, and CSR control status register, respectively. Simultaneously, each RISC-V local core has a checkpoint status maintenance module and a local data transceiver counter.

[0073] The checkpoint status maintenance module maintains information about the last committed checkpoint C0 (recording the general-purpose register data, PC value data, CSR register data, decoder module status, write-back data, and the current index y0 of the mailbox corresponding to the RISC-V core in the coordinating node when checkpoint C0 was committed); the local data transceiver records the number of mailbox interactions experienced by the RISC-V core since checkpoint C0 was committed, with sent information represented by T (the local RISC-V core sends data once via mailbox T+1) and received information represented by R (the local RISC-V core receives data once via mailbox R+1).

[0074] When checkpoint data updates occur between RISC-V many-core processors, the local RISC-V core receives the total number of pending messages sent by the coordination module through the checkpoint update interface and compares it with the received data R in the local transceiver. If they are equal, it means that the local RISC-V core has received all pending data and can trigger the checkpoint update mechanism. After the local RISC-V core meets the conditions for triggering a checkpoint update, it first sends a ready signal and the T / R data in the local transceiver counter to the coordination node. Upon receiving a checkpoint update confirmation signal from the coordination node, the local RISC-V core completes the specific checkpoint update logic.

[0075] Specifically, the checkpoint status maintenance module first clears the internally maintained checkpoint C0 information. Then, it reads the instruction fetch module PC information, decode module status information, general-purpose register data, CSR register data, and write-back data from the RISC-V core and writes them into the checkpoint module. Furthermore, it reads the current index y1 of the mailbox corresponding to the RISC-V core in the coordinating node and synchronously records this index to the checkpoint status maintenance module, designating it as checkpoint C1. When the total number of mailboxes to be received sent by the coordinating module is not equal to the received data R in the local transceiver, it waits for the local RISC-V core to complete reading the corresponding mailbox data before performing the checkpoint update. Throughout the entire process, the local RISC-V core continues to perform its tasks normally without being interrupted by checkpoint data updates.

[0076] When a local RISC-V core pipeline module or storage module triggers an exception or error, it will first be handled by its own exception service function. The exception service function specifies whether the error is handled by the core itself or by triggering a checkpoint rollback. Checkpoint rollback is the last resort for error problems that cannot be resolved by other methods.

[0077] When a checkpoint rollback is triggered, the local RISC-V core reads the C1 checkpoint information from the checkpoint state maintenance module and sends the corresponding information to each stage of the RISC-V core's pipeline modules, causing the local RISC-V core to re-execute the instruction from the PC. At the same time, the local RISC-V core synchronously sends error output information and the mailbox index y1 corresponding to checkpoint C1 to the coordinating node. The coordinating node, based on its own mailbox log information, feeds back the mailbox information that the local RISC-V node needs to receive, and feeds back to other RISC-V cores that have information exchange to see if a checkpoint rollback is needed.

[0078] like Figure 3As shown, taking a current workload that requires 3 RISC-V cores for computation, with the previous "committed checkpoint" at C0 (all core states have been saved) as an example, the following explanation is provided:

[0079] S1. First, each core sends information to each other when performing its daily work tasks after the previous checkpoint C0.

[0080] include:

[0081] S101, RISC-V core 0 sends two messages (M1, M2) to RISC-V core 1.

[0082] S102, RISC-V core 1 sends a message (M3) to RISC-V core 2.

[0083] S103 and RISC-V core 2 did not send messages to other cores.

[0084] S2, the mailbox communication storage module in the coordination node, completes the corresponding core forwarding of messages, and updates its own storage information and log information;

[0085] include:

[0086] The information corresponding to S201 and RISC-V core 0 mailbox is empty;

[0087] The corresponding information for S202 and RISC-V Core 1 mailboxes is [M1, M2];

[0088] The corresponding information for S203 and RISC-V Core 2 mailbox is [M3];

[0089] S204. Record the current RSIC-V core with communication as tran_core=[0,1,2].

[0090] S3. Each RISC-V core updates its local data transmission and reception counter after the previous checkpoint C0 based on the data transmission and reception status.

[0091] include:

[0092] S301, RISC-V core 0 transmits data T1=2, receives data R1=0;

[0093] S302, RISC-V core 1 transmits data T1=1, receives data R1=2;

[0094] S303, RISC-V core 2 sends data T2=0, receives data R1=1.

[0095] S4. The checkpoint update module in the coordinating node starts the checkpoint update logic, reads the mailbox module log information in the coordinating node, determines the RISC-V core directory tran_core=[0,1,2] where communication exists, and the total number of received messages num_message={core0=0, core1=2, core2=1} for each RISC-V core.

[0096] S5. The checkpoint update module in the coordinating node sends a checkpoint update signal to the RISC-V core directory tran_core=[0,1,2] that is communicating, along with the total number of messages to be received num_message={core0=0, core1=2, core2=1}.

[0097] include:

[0098] S501 sends a checkpoint update signal to RISC-V core 0, along with the information core0=0.

[0099] S502: Send a checkpoint update signal to RISC-V core 1, with the information core1=2;

[0100] S503 sends a checkpoint update signal to RISC-V core 2, with the information core2=1.

[0101] S6. After the RSIC-V core with communication receives the checkpoint update signal, it compares the total number of core information to be received, core_i, with the total number of information actually received locally, Ri.

[0102] include:

[0103] S601, RISC-V Core 0: If core0 is equal to R0, the core creates a temporary checkpoint C1 (records the general-purpose register data, PC value data, CSR register data, decoder module status, write-back data, and the current index y1 of the mailbox corresponding to RISC-V core 0 in the coordinating node), and sends a ready signal back to the checkpoint update module of the coordinating node.

[0104] S602, RISC-V Core 1: If core1 is equal to R1, the core creates a temporary checkpoint C1 (recording the general-purpose register data, PC value data, CSR register data, decoder module status, write-back data, and the current index y1 of the mailbox corresponding to RISC-V Core 1 in the coordinating node), and sends a ready signal back to the checkpoint update module of the coordinating node.

[0105] S603, RISC-V Core 2: If core2 is equal to R2, the core creates a temporary checkpoint C1 (recording the general-purpose register data, PC value data, CSR register data, decoder module status, write-back data, and the current index y1 of the mailbox corresponding to RISC-V Core 2 in the coordinating node), and sends a ready signal back to the checkpoint update module of the coordinating node.

[0106] S604. If the core_i of a certain RISC-V core is not equal to the total number of information actually received locally R_i, then wait for the core to complete data reception before creating a temporary checkpoint C1 and sending a ready signal to the checkpoint update module of the coordinating node.

[0107] S7. After receiving the ready signals from all communicating RISC-V core directories tran_core=[0,1,2], the checkpoint update module in the coordinating node verifies the consistency between the sum of sent messages and the sum of received messages, that is, whether T1+T2+T3 of each RISC-V core is equal to R1+R2+R3. When the two are equal, the checkpoint update module sends a checkpoint confirmation signal to the communicating RISC-V core directories tran_core=[0,1,2].

[0108] S8. After receiving the checkpoint confirmation signal, the RISC-V core with communication receives the checkpoint confirmation signal, determines the temporary checkpoint C1 as the submitted checkpoint C1, and deletes irrelevant data before C0.

[0109] S9. If RISC-V core 1 fails subsequently;

[0110] (1) RISC-V Core 1: Read its committed checkpoint C1 information and restore the state from checkpoint C1;

[0111] (2) Based on the current index y1 of the mailbox corresponding to RISC-V core 1 in the coordinating node recorded in C1, read the data after y1 in the mailbox;

[0112] (3) Determine the destination core of the faulty RISC-V core mailbox and trigger its checkpoint state rollback.

[0113] (4) Only the faulty RISC-V core and the core object corresponding to the faulty RISC-V core information output will perform the recovery operation, while other RISC-V cores will operate normally.

[0114] Based on the above method, a RISC-V many-core processor information fault-tolerant transmission device in this embodiment includes: at least one memory and at least one processor;

[0115] The at least one memory is used to store a machine-readable program;

[0116] The at least one processor is used to call the machine-readable program to execute a RISC-V many-core processor information fault-tolerant transmission method.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A RISC-V many-core processor information fault-tolerant transmission method, characterized in that, At each RISC-V local core, a checkpoint state maintenance module and a local data transceiver counter are arranged, the checkpoint state maintenance module maintains information of a last submitted checkpoint C0, records general register data, PC data, CSR register data, decoding module state, write-back data of the RISC-V core at the time of submission of the checkpoint C0, and a current index y0 of a mailbox corresponding to the RISC-V core in the coordination node; The local data transceiver counter records the number of mailbox interaction information experienced by the RISC-V core since the submission of the checkpoint C0, the sending information is represented by T, and the receiving information is represented by R; A plurality of RISC-V cores participate in calculation, the submitted checkpoint is C0, and the specific implementation steps are as follows: S1, first, each core sends information to each other when performing daily work tasks after the last checkpoint C0; S2, the mailbox communication storage module in the coordination node completes the core forwarding of the message and updates the storage information and log information of itself; S3, each RISC-V core updates the local data transceiver counter after the last checkpoint C0 according to the data transceiver situation; S4, determine the directory of RISC-V cores existing communication and the total number of received information of each RISC-V core; S5, the checkpoint update module in the coordination node sends a checkpoint update signal to the directory of RISC-V cores existing communication and carries the total number of received information; S6, after the RISC-V core existing communication receives the checkpoint update signal, the total number of core information to be received is compared with the total number of actual received information locally; S7, after the checkpoint update module in the coordination node receives the ready signal sent by all the directories of RISC-V cores existing communication, the consistency of the total number of sent messages and the total number of received messages is verified; S8, after the RISC-V core existing communication receives the checkpoint confirmation signal, the temporary checkpoint C1 is determined as the submitted checkpoint C1, and C0 and the irrelevant data before C0 are deleted; S9, if a subsequent RISC-V core fails, only the fault RISC-V core and the fault RISC-V core information output the corresponding core object to perform a recovery operation, and other RISC-V cores normally operate.

2. The RISC-V many-core processor information fault-tolerant transmission method according to claim 1, wherein, In step S1, it includes: S1-1, the RISC-V core A sends two pieces of information (M1, M2) to the RISC-V core B; S1-2, the RISC-V core B sends one piece of information (M3) to the RISC-V core C; S1-3, the RISC-V core C does not send messages to other cores.

3. The RISC-V many-core processor information fault-tolerant transmission method according to claim 2, wherein, In step S2, it includes: S2-1, the mailbox corresponding information of the RISC-V core A is empty; S2-2, the mailbox corresponding information of the RISC-V core B is [M1, M2]; S2-3, the mailbox corresponding information of the RISC-V core C is [M3]; S2-4, record the current RISC-V cores existing communication as tran_core=[A, B, C].

4. The RISC-V many-core processor information fault-tolerant transmission method according to claim 3, wherein, In step S3, it includes: S3-1, RISC-V core A sends data T A = 2, receive data R A = 0; S3-2, RISC-V core B sends data T B = 1, receive data R B = 2; S3-3, RISC-V core C sends data T C =0, receive data R C =1.

5. The RISC-V many-core processor information fault-tolerant transmission method according to claim 4, wherein, In step S4, the RISC-V core directory tran_core=[A, B, C] exists, and the total number of received messages num_message={core A=0, core B=2, core C=1} of each RISC-V core; In step S5, the RISC-V core directory tran_core=[A, B, C] exists, and the total number of received messages num_message={core A=0, core B=2, core C=1} is attached; (1) Send a checkpoint update signal to RISC-V core A, with the information coreA=0; (2) Send a checkpoint update signal to RISC-V core B, with the information coreB=2; (3) Send a checkpoint update signal to RISC-V core C, with the information coreC=1.

6. The RISC-V many-core processor information fault-tolerant transmission method according to claim 5, wherein, In step S6, compare the total number of core information to be received core_i with the local actual received information total number R_i, as follows: S6-1, RISC-V core A: if coreA is equal to R A , the core creates a temporary checkpoint C1, records the general register data of the RISC-V core, the PC data, the CSR register data, the decoding module state, the write-back data, and the current index y1 of the mailbox corresponding to RISC-V core A in the coordination node, and feeds back a ready signal to the checkpoint update module of the coordination node; S6-2, RISC-V core B: if coreB is equal to R B , the core creates a temporary checkpoint C1, records the general register data of the RISC-V core, the PC data, the CSR register data, the decoding module state, the write-back data, and the current index y2 of the mailbox corresponding to the RISC-V core B in the coordination node, and feeds back a ready signal to the checkpoint update module of the coordination node; S6-3, RISC-V core C: if coreC is equal to R C , the core creates a temporary checkpoint C1, records the general register data of the RISC-V core, the PC data, the CSR register data, the decoding module state, the write-back data, and the current index y3 of the mailbox corresponding to the RISC-V core C in the coordination node, and feeds back a ready signal to the checkpoint update module of the coordination node; S6-4, if the core_i of a certain RISC-V core is not equal to the local actual received information total number R_i, wait for the core to complete data reception, then create a temporary checkpoint C1 and feedback the ready signal to the checkpoint update module of the coordination node.

7. The RISC-V many-core processor information fault-tolerant transmission method according to claim 6, wherein, In step S7, after the checkpoint update module in the coordination node receives the ready signal from all the RISC-V core directory tran_core=[A, B, C] existing communication, it verifies the consistency of the total number of sent messages and the total number of received messages, i.e. whether TA+TB+TC is equal to RA+RB+RC of each RISC-V core, when the two are equal, the checkpoint update module sends a checkpoint confirmation signal to the RISC-V core directory tran_core=[A, B, C] existing communication; In step S8, after the RISC-V core receiving the checkpoint confirmation signal, the temporary checkpoint C1 is determined as the committed checkpoint C1, and C0 and the irrelevant data before it are deleted.

8. The RISC-V many-core processor information fault-tolerant transmission method according to claim 7, wherein, In step S9, if the subsequent RISC-V core B fails; (1) RISC-V core B: read its committed checkpoint C1 information, and restore the state from the checkpoint C1; (2) According to the current index y2 of the mailbox corresponding to RISC-V core B in the coordination node recorded in C1, read the data in the mailbox after y2; (3) Judge the destination core of the fault RISC-V core mailbox message transmission, also trigger the checkpoint state rollback; (4) Only the fault RISC-V core B and the fault RISC-V core B information output the corresponding core object to perform recovery operation, and other RISC-V cores run normally.

9. A RISC-V many-core processor information fault-tolerant transmission device, characterized in that, Comprise: At least one memory and at least one processor; The at least one memory is used to store machine readable programs; The at least one processor is used to call the machine readable programs to execute the method of any one of claims 1 to 8.

Images