A CoSim alignment method and system for RISC-CV architecture multi-core CPUs

Abstract

This invention relates to the field of CPU technology, specifically to a CoSim alignment method and system for multi-core CPUs with a RISC-CV architecture. The method sequentially defines the functions `mcc_item_create`, `mcc_item_exec`, `mcc_item_commit`, and `mcc_store_perform` to maintain the load and store instruction states of the model. The load and store instructions are broken down into multiple actions. By collecting the timing of the DUT's actions, the execution time of the model is controlled, ensuring a complete match between the CPU's execution pipeline and the DUT, thereby completing the multi-core CPU CoSim alignment. This invention breaks down a single action of the model's load and store instructions into multiple actions, collects the timing of the DUT's actions, and precisely controls the model's execution time to achieve a complete match with the DUT. This allows for CoSim alignment between the model and the DUT with minimal modifications to the existing functional model, demonstrating strong market application potential.

Description

Technical Field

[0001] This invention relates to the field of CPU technology, specifically to a CoSim comparison method and system for RISCCV architecture multi-core CPUs. Background Technology

[0002] In a single-core CPU system, we can use the CoSim method to compare each instruction of the CPU. That is, while simulating the DUT, we run a functional model of an instruction set (hereinafter referred to as the model). When the DUT commits an instruction, we control the model to execute a step as well. Then we compare the result of the DUT instruction with the result of the model. This is equivalent to comparing each instruction. When the result of any instruction does not match the model, we can quickly find the bug in the DUT.

[0003] However, the situation is different in multi-core CPU systems. The RISC architecture mandates RVWMO (weak memory ordering) for memory consistency. This allows a store instruction to not be immediately written to the cache or memory after commit, but rather potentially stored in its own core's buffer. In this case, even if the store instruction is committed, other cores cannot see this store. This leads to inconsistencies between the DUT's behavior and the model's behavior, although both conform to the architecture's specifications, making it impossible to use the CoSim method to verify multi-core CPU systems.

[0004] There are two existing methods for verifying multi-core systems. One method is to write a checker to check the correctness of the memory execution process in the multi-core system. This method can only check whether the memory-related data load / store is correct, but cannot check the correctness of instruction execution. Moreover, this checker is highly dependent on the microarchitecture and requires writing a corresponding checker for each CPU with a different microarchitecture, resulting in poor versatility.

[0005] Another approach is to write a model with the same timing as the RTL, and then use this model to perform CoSim with the RTL to achieve instruction-level comparison. This method can compare every instruction, but the model is highly dependent on the microarchitecture, and writing such a complete model is quite difficult.

[0006] Therefore, this paper introduces a method that solves the problem of not being able to use the CoSim method for verification in multi-core CPU systems. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention discloses a CoSim comparison method and system for RISCV architecture multi-core CPUs, which solves the problem that the CoSim method cannot be used for verification in multi-core CPU systems.

[0008] This invention is achieved through the following technical solution:

[0009] In a first aspect, this invention discloses a CoSim alignment method for a multi-core CPU based on a RISC-CV architecture. The method sequentially defines the functions mcc_item_create, mcc_item_exec, mcc_item_commit, and mcc_store_perform to maintain the load and store instruction states of the model. The load and store instructions are broken down into multiple actions. By collecting the timing of the DUT actions, the execution time of the model is controlled so that the execution pipeline of the CPU executing the DUT is completely matched with the DUT, thereby completing the multi-core CPU CoSim alignment.

[0010] Furthermore, when the method defines the function mcc_item_create, if the instruction reaches the dispatch stage and is determined to be a load / store instruction, the function is called to request an item, store it in the queue of the corresponding core of mcc_global_q, and set the status of the item to INIT.

[0011] Furthermore, when the method defines the function mcc_item_exec, when the instruction reaches the ex2 stage, it retrieves the paddr / vaddr / data of the DUT, matches a load / store entry based on the id, stores it in the queue, and changes the status of the item to EXEC.

[0012] Furthermore, when defining the function mcc_item_exec, if the instruction is load, the value of the model is compared with the value loaded by the DUT. If they are inconsistent, the DUT is faulty. In this case, the value of the model is first searched for in the mcc_global_q of the core. If a matching address is found, the value in mcc_global_q is used first. If it is not found in mcc_global_q, it is read from memory.

[0013] Furthermore, when the method defines the function mcc_item_commit, when the instruction reaches the commit stage, it iterates through mcc_global_q, checks the instructions that need to be committed, finds the current instruction item with the matching ID, and then sets the item's state to COMMITTED.

[0014] Furthermore, when defining the function mcc_item_commit, if the current instruction is store, the value of the address of the store operation is temporarily saved first, then the model is executed one step, the execution result of the model is compared with the data of the DUT, and after the execution is completed, the value temporarily saved earlier is injected back into the model to restore the value of the address.

[0015] If the current instruction is load, then the model is executed one step directly, and the DUT value is injected back into the model's GPR, modifying the model's GPR and removing it from mcc_global_q.

[0016] Furthermore, when the method defines the function mcc_store_perform, when a store instruction is actually written to memory, it searches for the matching store item in mcc_global_q, actually writes it to memory, and deletes the store from mcc_global_q, thus completing the entire store process.

[0017] Furthermore, in the method, the execution process of load includes the following steps:

[0018] In the S1.DUT to dispatch stage, the platform collects DUT signals, calls the model's mcc_item_create function to create an item, and stores the item in mcc_global_q;

[0019] From S2.DUT to ex2 stage, the platform acquires DUT signals, calls the model's mcc_item_exec function, and passes the paddr, vaddr, and data read by the DUT to the model. The model then reads the value at that address from its own memory and compares it with the DUT's data. If an error is found, an error is reported and the simulation stops.

[0020] When S3.DUT reaches the commit stage, the platform collects DUT signals and calls the model's mcc_item_commit function, and the model will execute one step.

[0021] S4. Inject the DUT's data into the model's GPR in reverse, and finally remove the item from mcc_global_q.

[0022] Furthermore, in the method, the execution process of the store includes the following steps:

[0023] During the dispatch phase from T1.DUT, the platform collects DUT signals, calls the model's mcc_item_create function to create an item, and stores the item in mcc_global_q;

[0024] From T2.DUT to ex2 stage, the platform collects DUT signals and calls the model's mcc_item_exec function to pass the paddr, vaddr, and data read by the DUT to the model;

[0025] When T3.DUT reaches the commit stage, the platform collects DUT signals, calls the model's mcc_item_commit function, first reads the value of the corresponding memory address of the model and saves it in a temporary variable; then the model is executed one step.

[0026] T4. Check if the data in the store is correct, then inject the value in the temporary variable back into the model to restore the value before the store instruction;

[0027] When T5.DUT reaches the perform stage, the platform collects DUT signals, calls the model's mcc_store_perform function, writes the value at the corresponding address into memory, and finally deletes the item from mcc_global_q.

[0028] Secondly, this invention discloses a CoSim alignment system for a RISCV architecture multi-core CPU. The system is used to implement the CoSim alignment method for a RISCV architecture multi-core CPU described in the first aspect, including a pipeline of several stages from dispatch, ex0, ex1, ex2 to commit, and an LSU module for allocating execution units dispatch and allocating load and store.

[0029] The beneficial effects of this invention are as follows:

[0030] This invention breaks down the single action of the load and store instructions of the Model into multiple actions, and collects the timing of the DUT actions to precisely control the execution time of the Model, thereby achieving a complete match with the DUT. This enables the Model and DUT to be compared using CoSim with minimal changes to the existing functional model. Attached Figure Description

[0031] 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 only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is an execution pipeline diagram of the DUT CPU in an embodiment of the present invention;

[0033] Figure 2 This is an execution pipeline diagram of a system with two cores in an embodiment of the present invention;

[0034] Figure 3 This is a diagram illustrating the execution process of load in an embodiment of the present invention;

[0035] Figure 4 This is a diagram illustrating the execution process of the store in an embodiment of the present invention;

[0036] Figure 5 This is a diagram illustrating the implementation effect of an embodiment of the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, 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.

[0038] Example 1

[0039] This embodiment discloses a CoSim alignment method for multi-core CPUs with a RISC-CV architecture. The method sequentially defines the functions mcc_item_create, mcc_item_exec, mcc_item_commit, and mcc_store_perform to maintain the load and store instruction states of the model. The load and store instructions are broken down into multiple actions. By collecting the timing of the DUT actions, the execution time of the model is controlled to ensure that the execution pipeline of the CPU executing the DUT is completely matched with the DUT, thereby completing the multi-core CPU CoSim alignment.

[0040] In this embodiment, if the DUT is an out-of-order CPU, it may be flushed before commit. `mcc_item_flush` is defined. When the DUT is flushed, this function is called to remove younger instructions from `mcc_global_q`.

[0041] This embodiment allows for CoSim alignment between the model and the DUT with minimal changes to the existing functional model. Furthermore, this method has less dependence on microarchitecture compared to the two background techniques.

[0042] Example 2

[0043] This embodiment assumes that the execution pipeline of the DUT CPU is as follows: Figure 1 As shown, the pipeline consists of several stages: dispatch, ex0, ex1, ex2, and commit. Dispatch allocates execution units; load and store are typically assigned to the LSU module. ex0, ex1, and ex2 form the LSU pipeline. For a load instruction, the data can be retrieved from memory at ex2. For a store instruction, the data is written to memory only after commit.

[0044] As can be seen from the pipeline above, for a single instruction, reading memory, writing memory, and committing the instruction are not completed at the same time. However, since the Model has no concept of time, these three actions are completed simultaneously. This leads to inconsistency between the DUT and the Model.

[0045] In this embodiment, it is assumed that the system has two cores. Figure 2As shown, core0 executes a load instruction, and core1 executes a store instruction, writing a value of 1. Both operate on the same address, which was 0 before execution. If, using the single-core CoSim method, the model executes an instruction at commit time, the result would be that core1's store instruction executes first, writing the value of the address to 1, then core0's load instruction executes, reading a value of 1. However, the DUT behaves differently. Although core1's store instruction executes in the DUT, it hasn't yet been written to memory. At this point, core0 cannot read the value written by core1, so core0 reads a value of 0. Therefore, the DUT and model cannot match, failing to achieve the purpose of comparison.

[0046] As can be seen from the above analysis, the reason why the DUT and model cannot match is that the DUT's load and store operations each consist of two actions, while the model's only has one action. Therefore, the core idea of ​​this embodiment is to perform the model's load and store operations in two steps.

[0047] Example 3

[0048] This embodiment defines a structure to maintain the instruction states of load and store.

[0049] typedef struct{

[0050] uint64_t id;

[0051] uint64_t vaddr;

[0052] uint64_t paddr;

[0053] uint64_t data;

[0054] uint8_t vaddr_vld;

[0055] uint8_t paddr_vld;

[0056] uint8_t data_vld;

[0057] uint8_t size;

[0058] uint8_t state;

[0059] uint8_t type;

[0060] }mcc_item_t,*p_mcc_item_t;

[0061] in:

[0062] id: Identifies a load / store command

[0063] vaddr: The virtual address operated on by this instruction.

[0064] vaddr_vld: Whether the virtual address operated on by this instruction is valid.

[0065] paddr: The virtual address that this instruction operates on.

[0066] paddr_vld: Whether the virtual address operated on by this instruction is valid.

[0067] data: The data that this command operates on. If it's `load`, it indicates the data read out; if it's `store`, it indicates the data to be written.

[0068] data_vld: Whether the data operated on by this instruction is valid.

[0069] size: The size of the memory that this command reads or writes.

[0070] state: The state of this instruction

[0071] type: The type of this instruction, either load or store.

[0072] Each core maintains a list of this structure to store all load / store commands in flight.

[0073] std::list<p_mcc_item_t> mcc_global_q[MCC_HART_MAX].

[0074] Example 4

[0075] This embodiment defines the function `mcc_item_create`. When the instruction reaches the dispatch stage, if it is a load / store instruction, this function is called to request an item and store it in the queue of the corresponding core in `mcc_global_q`. The status of this item is then set to INIT.

[0076] This embodiment defines the function `mcc_item_exec`. When the instruction reaches the ex2 stage, the paddr / vaddr / data of the DUT is retrieved, and a load / store entry is matched based on the ID, stored in the queue, and the status of the item is changed to EXEC. If the instruction is a load, the value of the model is compared with the value of the DUT load. Since the read times of the model and the DUT are now consistent, a comparison at this point will show that if they are inconsistent, it indicates a DUT error. The value of the model needs to be searched in the `mcc_global_q` of the core. If a matching address is found, the value in `mcc_global_q` is used first, as it indicates that a store has been stored but not yet written to memory. If the value is not found in `mcc_global_q`, it is read from memory.

[0077] This embodiment defines the function `mcc_item_commit`. When an instruction reaches the commit stage, it iterates through `mcc_global_q`, checking that all instructions preceding the one requiring commit have already been committed. Then, it finds the current instruction item with a matching ID, and sets the item's state to `COMMITTED`.

[0078] If the current instruction is a store, the value at the address of the store operation is temporarily saved. Then, the model executes the next step, and the result of the model's execution is compared with the DUT's data. Since the model has already executed the store instruction, and cannot write to it at this point, the previously temporarily saved value is injected back into the model after execution, effectively restoring the value at that address.

[0079] If the current instruction is load, the model is executed one step directly, and then the DUT values ​​are injected back into the model's GPR. Since the correctness of the DUT values ​​has already been checked, the model's GPR can be modified directly here without errors. Because the load instruction ends at this step, it can be removed from mcc_global_q.

[0080] This embodiment defines the function `mcc_store_perform`. When a store instruction is actually written to memory, which is generally when it is written from the merge buffer to the cache, it means that this store can be seen by other cores. At this time, `mcc_global_q` searches for the matching store item, actually writes it to memory, and deletes the store from `mcc_global_q`, thus completing the entire store process.

[0081] Example 5

[0082] This embodiment discloses as follows: Figure 3 The execution process of the load shown is as follows:

[0083] 1. During the DUT to dispatch stage, the platform collects DUT signals, calls the model's mcc_item_create function to create an item, and stores the item in mcc_global_q.

[0084] 2. From the DUT to the ex2 stage, the platform acquires the DUT signal, calls the model's mcc_item_exec function, and passes the paddr, vaddr, and data read from the DUT to the model. The model then reads the value at that address from its own memory and compares it with the DUT's data. If an error is found, an error is reported and the simulation stops.

[0085] 3. During the DUT's commit stage, the platform collects DUT signals and calls the model's `mcc_item_commit` function. The model executes one step, then injects the DUT's data back into the model's GPR. Since the execution stage has already checked the data's correctness, this data is definitely correct. Finally, the item is removed from `mcc_global_q`.

[0086] Example 6

[0087] This embodiment discloses as follows: Figure 4 The execution process of the store is shown below:

[0088] 1. During the DUT to dispatch stage, the platform collects DUT signals, calls the model's mcc_item_create function to create an item, and stores the item in mcc_global_q.

[0089] 2. From the DUT to the ex2 stage, the platform acquires the DUT signals and calls the model's mcc_item_exec function to pass the paddr, vaddr, and data read by the DUT to the model.

[0090] 3. During the DUT to commit stage, the platform collects DUT signals and calls the model's `mcc_item_commit` function. First, it reads the value from the corresponding memory address of the model and stores it in a temporary variable; then it executes the model one step; next, it checks whether the store's data is correct; then it injects the value in the temporary variable back into the model, thereby restoring the value before the store instruction, as if the store instruction had never been executed.

[0091] 3. When the DUT reaches the perform stage, the platform collects the DUT signals, calls the model's `mcc_store_perform` function, and writes the value at the corresponding address into memory. Finally, the item is deleted from `mcc_global_q`.

[0092] Example 7

[0093] This embodiment uses the method in Embodiment 1. After Core1's store instruction commits, the memory value in the model remains the value before the store. Core0 loads data from the memory and obtains a value of 0, which matches the DUT, indicating a successful match. Then, it commits again, deleting the load item from `mcc_global_q`. Core1 then performs again, writing 1 to the model's memory. The entire process perfectly matches the DUT, allowing all instructions to be CoSim-compatible. Therefore, this embodiment breaks down the single action of the model's load and store instructions into multiple actions and collects the timing of the DUT actions, precisely controlling the model's execution time to achieve a perfect match with the DUT, thus completing the multi-core CPU CoSim comparison.

[0094] Example 8

[0095] This embodiment discloses a CoSim comparison system for a RISCV architecture multi-core CPU, including a pipeline of several stages from dispatch, ex0, ex1, ex2 to commit, and an LSU module for allocating execution units dispatch and allocating load and store.

[0096] In summary, this invention breaks down the single action of the load and store instructions of the Model into multiple actions, and collects the timing of the DUT actions to precisely control the execution time of the Model, thereby achieving a complete match with the DUT. This enables the Model and DUT to be compared using CoSim with minimal changes to the existing functional model.

[0097] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A CoSim alignment method for RISC-CV architecture multi-core CPUs, characterized in that, The method sequentially defines the functions mcc_item_create, mcc_item_exec, mcc_item_commit, and mcc_store_perform to maintain the load and store instruction states of the model. The load and store instructions are broken down into multiple actions. By collecting the timing of the DUT actions, the execution time of the model is controlled to ensure that the model execution pipeline of the CPU executing the DUT is completely matched with the DUT, thereby completing the multi-core CPU CoSim comparison. The model maintains the items corresponding to the memory access instructions in the queue mcc_global_q through function calls.

2. The CoSim comparison method for RISC-CV architecture multi-core CPUs according to claim 1, characterized in that, When the function mcc_item_create is defined, if the instruction reaches the dispatch stage and is determined to be a load / store instruction, the function mcc_item_create is called to request an item, store it in the queue of the corresponding core of mcc_global_q, and set the status of the item to INIT.

3. The CoSim comparison method for RISC-CV architecture multi-core CPUs according to claim 2, characterized in that... When the function mcc_item_exec is defined, when the instruction reaches ex2stage, the physical address paddr, virtual address vaddr, and data of the DUT are retrieved. A load / store entry is matched according to the id, stored in the queue, and the status of the item of the instruction is changed to EXEC.

4. The CoSim comparison method for RISC-CV architecture multi-core CPUs according to claim 3, characterized in that, When defining the function mcc_item_exec, if the instruction is load, the value of model is compared with the value loaded by the DUT. If they are inconsistent, the DUT is faulty. In this case, the value of model is first searched for in the core's mcc_global_q. If a matching address is found, the value in mcc_global_q is used first. If it is not found in mcc_global_q, it is read from memory.

5. The CoSim comparison method for RISC-CV architecture multi-core CPUs according to claim 1, characterized in that, When defining the function mcc_item_commit, when the instruction reaches the commit stage, it iterates through mcc_global_q, checks the instructions that need to be committed, finds the current instruction item with the matching ID, and then sets the item's state to COMMITTED.

6. The CoSim comparison method for RISC-CV architecture multi-core CPUs according to claim 5, characterized in that, When defining the function mcc_item_commit, if the current instruction is store, the value of the address of the store operation is temporarily saved first, then the model is executed one step, the execution result of the model is compared with the data of the DUT, and after the execution is completed, the value temporarily saved earlier is injected back into the model to restore the value of the address of the store operation. If the current instruction is load, then the model is executed one step directly, and the DUT value is injected back into the model's GPR, modifying the model's GPR and removing it from mcc_global_q.

7. The CoSim comparison method for RISC-CV architecture multi-core CPUs according to claim 1, characterized in that, When defining the function mcc_store_perform, when a store instruction actually writes to memory, it searches for the matching store item in mcc_global_q, actually writes it to memory, and deletes the store item from mcc_global_q, thus completing the entire store process.

8. The CoSim comparison method for RISC-CV architecture multi-core CPUs according to claim 1, characterized in that, In the method described, the execution process of load includes the following steps: In the S1.DUT to dispatch stage, the platform collects DUT signals, calls the model's mcc_item_create function to create an item, and stores the created item in mcc_global_q; From S2.DUT to ex2 stage, the platform acquires DUT signals and calls the model's mcc_item_exec function to pass the paddr, vaddr, and data read by the DUT to the model. The model reads the values ​​of the addresses corresponding to paddr and vaddr from its own memory and compares them with the DUT's data. If there is an error, it reports an error and stops the simulation. When S3.DUT reaches the commit stage, the platform collects DUT signals and calls the model's mcc_item_commit function, and the model will execute one step. S4. Inject the DUT's data into the model's GPR in reverse, and finally delete the load item that matches the load from mcc_global_q.

9. The CoSim comparison method for RISC-CV architecture multi-core CPUs according to claim 1, characterized in that, In the method described, the execution process of the store includes the following steps: During the dispatch phase from T1.DUT, the platform collects DUT signals, calls the model's mcc_item_create function to create an item, and stores the created item in mcc_global_q; From T2.DUT to ex2 stage, the platform collects DUT signals and calls the model's mcc_item_exec function to pass the paddr, vaddr, and data read by the DUT to the model; When T3.DUT reaches the commit stage, the platform collects DUT signals, calls the model's mcc_item_commit function, first reads the value of the corresponding memory address of the model and saves it in a temporary variable; then the model executes one step. T4. Check if the data in the store is correct, then inject the value in the temporary variable back into the model to restore the value before the store instruction; When T5.DUT reaches the perform stage, the platform collects DUT signals, calls the model's mcc_store_perform function, writes the value at the corresponding address into memory, and finally deletes the item from mcc_global_q.

10. A CoSim alignment system for RISC-CV architecture multi-core CPUs, the system being used to implement the CoSim alignment method for RISC-CV architecture multi-core CPUs as described in any one of claims 1-9, characterized in that, This includes the LSU module, which allocates execution units from dispatch, ex0, ex1, ex2 to commit, as well as load and store allocation.

Images