A CPU verification system and method

Abstract

The present disclosure provides a CPU verification system and method, which determines a design model of a CPU under test based on an RV32 architecture, and executes a test instruction through the design model to generate a result of the executed instruction. Meanwhile, a spike simulator is utilized to synchronously execute the same test instruction to generate a standard result of the executed instruction. Then, a difference comparison module is utilized to compare the two results of the executed instruction, thereby verifying the design model of the CPU under test.

Description

Technical Field

[0001] This disclosure relates to the field of CPU verification technology, and in particular to a CPU verification system and method. Background Technology

[0002] Currently, CPU simulators are widely used in software development and dynamic program analysis. In the field of CPU verification, post-processing model comparison schemes or instruction-level online differential verification schemes are generally used. Instruction-level online differential verification schemes can directly identify and analyze anomalies, offering high accuracy and short anomaly location time. A commonly used instruction-level online differential verification scheme is the difftest differential verification proposed by the RISCV open-source organization, Xiangshan. It supports differential verification of RV64 and its Xiangshan CPU series, but has the following drawbacks: it only supports CPU verification from this organization, primarily for high-performance CPU implementations, and does not support lower-performance CPUs such as the RV32 series. Summary of the Invention

[0003] This disclosure provides a CPU verification system and method. The CPU verification system enables the verification of RV32 architecture CPUs.

[0004] In one aspect, this embodiment provides a CPU verification system, the system comprising: a design model of the CPU under test, the design model being determined based on the RV32 architecture CPU, the design model being used at least to execute test instructions; a spike simulator, the spike simulator being used at least to execute test instructions synchronously with the design model; and a differential comparison module, the differential comparison module communicating with the design model and the spike simulator, being used at least to compare the execution results of the design model and the spike simulator, so as to verify the design model of the CPU under test.

[0005] In embodiments of this disclosure, the design model has one or more CPU cores.

[0006] In embodiments of this disclosure, when the design model has multiple CPU cores, the system further includes a shared storage module, which is used to store at least the test instructions corresponding to the multiple CPU cores, the execution results of the multiple CPU cores on the test instructions, and the execution results of the spike simulator on the test instructions.

[0007] In the embodiments of this disclosure, the shared storage module is also used to store the execution order of test instructions, and to store the test instructions and execution results corresponding to different CPU cores to different addresses.

[0008] In the embodiments of this disclosure, there is one spike simulator and one differential comparison module. The spike simulator is used to execute test instructions corresponding to at least multiple CPU cores.

[0009] In the embodiments of this disclosure, the number of spike simulators is the same as the number of CPU cores, the number of differential comparison modules is the same as the number of spike simulators, there is a one-to-one correspondence between spike simulators and differential comparison modules, and there is a one-to-one correspondence between spike simulators and CPU cores, so as to execute the test instructions of the CPU core corresponding to the spike simulator.

[0010] In embodiments of this disclosure, the system further includes: a data controller, which is at least configured to read test instructions corresponding to multiple CPU cores from a shared storage module, distribute the test instructions to the corresponding CPU cores, and store the execution results of the test instructions by the multiple CPU cores in the shared storage module.

[0011] In embodiments of this disclosure, the test instructions include at least extended functionality test instructions, which are used to represent non-standard RISC-V instructions.

[0012] In another aspect, embodiments of this disclosure provide a CPU verification method, the method comprising: executing test instructions using a design model of the CPU under test, wherein the design model is determined based on an RV32 architecture CPU and the number of CPU cores in the design model is one or more; driving a spike simulator to synchronously execute the test instructions of the design model; and comparing the execution result of the design model on the test instructions with the execution result of the spike simulator on the test instructions, so as to verify the design model of the CPU under test.

[0013] In embodiments of this disclosure, when the design model has multiple CPU cores, the method further includes: reading test instructions corresponding to the CPU cores from a shared storage module, wherein the shared storage module is used to store at least multiple test instructions corresponding to the CPU cores; and storing the execution results of the multiple CPU cores and the execution results of the spike simulator into the shared storage module. Attached Figure Description

[0014] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0015] Figure 1 The schematic diagram illustrates an environmental application according to an embodiment of the present disclosure.

[0016] Figure 2This is a schematic diagram of a CPU verification system according to an embodiment of the present disclosure.

[0017] Figure 3 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure.

[0018] Figure 4 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure.

[0019] Figure 5 A schematic diagram of another CPU verification system according to an embodiment of the present disclosure is shown.

[0020] Figure 6 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure.

[0021] Figure 7 This is a flowchart of a CPU verification method according to an embodiment of the present disclosure.

[0022] Figure 8 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.

[0024] Figure 1 The schematic diagram illustrates an environmental application according to an embodiment of the present disclosure.

[0025] like Figure 1 As shown, the CPU verification system provided in this embodiment can run on computing device 101, maintaining the initial state of the design model of the CPU under test and the spike simulator consistent. The verification environment loads an executable file at a specified address of the CPU, typically a compiled binary file. By controlling the design model of the CPU under test to execute test instructions, the system obtains the results of the instruction execution. Simultaneously, it drives the spike simulator to execute test instructions synchronously, obtaining the results of the instruction execution. Furthermore, the system compares the results of the two executed instructions. If the results of the executed test instructions are inconsistent, the simulation immediately stops, providing the error result and the actual instruction.

[0026] Next, this article will combine Figures 2-8 The CPU verification system and CPU verification method provided in the embodiments of this disclosure will be described in detail.

[0027] Figure 2 This is a schematic diagram of a CPU verification system according to an embodiment of the present disclosure.

[0028] like Figure 2 As shown, the CPU verification system 200 includes a design model 201 of the CPU under test, a spike simulator 202, and a differential comparison module 203.

[0029] In the embodiments disclosed herein, the design model 201 of the CPU under test is determined based on the RV32 architecture CPU. The RV32 architecture CPU is a central processing unit designed based on the RISC-V standard protocol, referring to a circuit designed using the Verilog language. RV32 is an abbreviation for RISC-V 32-bit, a branch of the RISC-V instruction set architecture (ISA). RISC-V is an open-source, free instruction set architecture standard. 32-bit refers to the CPU's general-purpose register width being 32 bits, allowing it to process a maximum of 32 bits of binary data at a time, and its address space is also primarily 32 bits (maximum addressable 4GB of memory). Therefore, RV32 is an open-source CPU instruction set standard specifically designed for 32-bit processors. An RV32 architecture CPU is a CPU designed according to the RV32 instruction set standard, which includes a modular instruction set consisting of a basic instruction set and multiple optional extended instruction sets. Optional extended instruction sets include, for example, the M instruction set (integer multiplication and division instructions), the A instruction set (atomic operation instructions), and the F instruction set (single-precision floating-point instructions).

[0030] It should be noted that when the device under test (DUT) is an RV32 architecture CPU, the instruction set configuration, registers, address space, etc. of the spike simulator 202 and the differential comparison module 203 need to be adjusted to ensure that they are consistent with the behavior specifications of the DUT, thereby ensuring the accuracy and validity of the verification results.

[0031] In the embodiments of this disclosure, the spike simulator 202 can be used as a golden reference model, and its execution result can be used as the standard answer for comparison with the result of the execution instructions of the design model 201. The differential comparison module 203 can obtain the result of the execution instructions of the design model 201 and the result of the execution instructions of the spike simulator 202, and compare the result of the execution instructions of the design model 201 and the result of the execution instructions of the spike simulator 202 line by line to determine whether the design model 201 of the CPU under test is normal, thereby determining whether the RV32 architecture CPU design is correct.

[0032] In some embodiments, design model 201 can obtain an RV32 test instruction from the instruction stream. After executing the instruction, it outputs the complete result of the instruction execution (including register values, memory data, etc.) to the differential comparison module 203. Simultaneously, spike simulator 202 can obtain the same test instruction as design model 201 from differential comparison module 203 and execute the test instruction to generate the correct instruction execution result. Further, spike simulator 202 outputs the result of the executed instruction to differential comparison module 203. After obtaining the results of the two executed instructions, differential comparison module 203 compares the results. If the comparison result shows that the results of the two executed instructions are consistent, it executes the next test instruction; if the comparison result shows that the results of the two executed instructions are inconsistent, it immediately exits and reports an error.

[0033] According to embodiments of this disclosure, differential verification of the RV64 and its Xiangshan CPU series is mainly used for high-performance CPU implementations and does not support lower-performance CPUs of the RV32 series. Therefore, it is not used when dealing with low-cost and low-power CPUs applied in the Internet of Things (IoT), embedded systems, and microcontrollers (MCUs). However, the CPU verification system provided by embodiments of this disclosure can verify these low-cost and low-power RV32 series CPUs, thus enabling its widespread application in IoT and embedded systems fields.

[0034] The CPU verification system provided in this disclosure executes test instructions one by one using the design model 201 and the spike simulator 202. This allows for a step-by-step comparison of the execution results, enabling precise identification of which instruction malfunctioned, thus improving debugging efficiency. Furthermore, the spike simulator 202 generates standard results during the comparison process, enhancing the reliability of the verification results from the design model 201. Moreover, compared to general-purpose verification systems, the CPU verification system provided in this disclosure is specifically tailored for the RV32 architecture, precisely adapting to the RV32's instruction set, registers, and address space, making the verification more targeted.

[0035] In embodiments of this disclosure, the design model has one or more CPU cores.

[0036] The CPU verification system provided in this embodiment supports a design model that can be configured as a single-core architecture or a multi-core architecture. That is, the number of CPU cores can be set to one or more according to actual design requirements. When the number of CPU cores is different, the parameters of the differential comparison module 203 can be adaptively adjusted to adapt to verification scenarios with different numbers of cores.

[0037] Figure 3 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure.

[0038] like Figure 3 As shown, when the number of CPU cores in the design model 201 is multiple, the CPU verification system 200 also includes a shared storage module 204.

[0039] In the embodiments of this disclosure, the shared storage module 204 can be used to store the execution results of test instructions by multiple CPU cores and the execution results of test instructions by the spike simulator 202. For example, after core 0 of design model 201 executes a test instruction, it writes the execution result to the shared storage module 204, which can store the execution result corresponding to core 0 in address 0 or region 0. Similarly, after core 1 of design model 201 executes a test instruction, it can also write the corresponding execution result to the shared storage module 204, which can store the execution result corresponding to core 1 in address 1 or region 1.

[0040] Furthermore, the differential comparison module 203 can transmit the same test instruction as core 0 to the spike simulator 202. The spike simulator 202 can test the instruction and write the execution result to the shared storage module 204. The shared storage module 204 can store the execution result in address 0 or region 0. Simultaneously, the differential comparison module 203 can transmit the same test instruction as core 1 to the spike simulator 202. The spike simulator 202 can test the instruction and write the execution result to the shared storage module 204. The shared storage module 204 can store the execution result in address 1 or region 1. Thus, the shared storage module 204 stores the execution results of the CPU cores for the same test instruction in correspondence with the execution results of the spike simulator 202.

[0041] In some embodiments, the shared storage module 204 can provide a unified storage medium for the execution results of the design model 201 and the spike simulator 202, ensuring that the results of the execution instructions of both parties are stored in an orderly, independent and secure manner, avoiding data chaos and loss, so that the differential comparison module 203 can perform fast and accurate instruction comparison, thereby improving the reliability and efficiency of verification.

[0042] In the embodiments of this disclosure, the shared storage module 204 can also be used to store test instructions corresponding to multiple CPU cores. The shared storage module 204 uniformly stores the instructions to be executed, which facilitates the differential comparison module 203 to control the design model 201 and the spike simulator 202 to fetch and execute instructions synchronously. This ensures that the design model 201 and the spike simulator 202 obtain exactly the same test instructions, avoiding verification errors caused by inconsistencies in the test instructions on both sides.

[0043] In the embodiments of this disclosure, the shared storage module 204 is also used to store the execution order of test instructions, and to store the test instructions and execution results corresponding to different CPU cores to different areas.

[0044] In some embodiments, since different CPU cores can execute different test instructions, when reading test instructions from the shared storage module 204, it is necessary to read the test instructions corresponding to the CPU core. Depending on the CPU core, the corresponding test instructions can be stored in different addresses or regions, so that when reading test instructions, the corresponding address or region can be retrieved based on the CPU core.

[0045] For example, the shared storage module 204 can store test instructions applied to core 0 of design model 201 to address 0 or region 0, and test instructions applied to core 1 of design model 201 to address 1 or region 1. Thus, in addition to storing test instructions corresponding to multiple CPU cores, multiple test instructions applied to different CPU cores can be stored in different regions or addresses, thereby achieving isolation and ensuring the smoothness of the testing process. Simultaneously, the shared storage module 204 uniformly stores instructions to be executed, facilitating the differential comparison module 203 to control the design model 201 and the spike simulator 202 to fetch and execute instructions synchronously. This ensures that the design model 201 and the spike simulator 202 obtain exactly the same test instructions, avoiding verification errors caused by inconsistencies in the test instructions on both sides.

[0046] In some embodiments, test instructions corresponding to different CPU cores can be stored in the same address or region. When stored in the same address or region, the test instructions can include an execution order, which can be used to characterize the CPU core to which the test instruction is applied. For example, the test instructions corresponding to core 0 and core 1 of design model 201 can be stored in address 0 or region 0. Simultaneously, in address 0 or region 0, the execution order of the test instructions can be determined based on the execution order of core 0 and core 1. If core 0 and core 1 execute test instructions alternately, then in address 0 or region 0, the test instructions corresponding to core 0 and the test instructions corresponding to core 1 can be stored alternately, so that core 0 and core 1 execute test instructions alternately.

[0047] In the embodiments of this disclosure, when the design model 201 has multiple CPU cores, the number of spike simulators 202 can be one, and the number of differential comparison modules 203 can also be one. The spike simulator 202 is used to execute test instructions corresponding to multiple CPU cores at least.

[0048] Multiple CPU cores are mapped to a single spike simulator 202, meaning all CPU cores use the same spike simulator 202. In this configuration, a shared storage module 204 can store the test instructions corresponding to each CPU core, and sequentially store multiple test instructions according to the execution order of the test instructions on each CPU core, while also storing the corresponding CPU core information. Therefore, the shared storage module 204 can pass the corresponding test instructions to the design model 201 and the spike simulator 202 according to the execution order of the CPU cores. In this case, the spike simulator 202 needs to support the test instructions corresponding to all CPU cores to complete the verification of the design model 201. Mapping all CPU cores to a single spike simulator 202 effectively saves computational costs.

[0049] Figure 4 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure.

[0050] like Figure 4 As shown, in the CPU verification system 200, the design model 201 of the CPU under test contains multiple CPU cores, such as CPU core 0, ..., CPU core N. CPU cores 0 through N sequentially read the corresponding test instructions from the shared storage module 204 in execution order, generate execution results, and store the results in the shared storage module 204. After one CPU core completes execution and transmits the result to the shared storage module 204, the spike simulator 202 reads the same test instructions through the differential comparison module 203 and transmits the result to the shared storage module 204. If the shared storage module 204 compares the results of the two executed instructions and determines they are consistent, the next CPU core reads the corresponding test instructions from the shared storage module 204 in the execution order of the CPU cores, generates execution results, and the spike simulator 202 executes the same test instructions as the next CPU core. Finally, the differential comparison module 203 can output the differential verification result, or output an error if the results of the two executed instructions do not match.

[0051] In the embodiments of this disclosure, when the design model 201 has multiple CPU cores, the number of spike simulators 202 is the same as the number of CPU cores, the number of differential comparison modules 203 is the same as the number of spike simulators 202, the spike simulators 202 and differential comparison modules 203 are in one-to-one correspondence, and the spike simulators 202 and CPU cores are in one-to-one correspondence, so as to execute the test instructions of the CPU core corresponding to the spike simulators 202.

[0052] In the case where multiple CPU cores are mapped to a single spike simulator 202, the spike simulator 202 needs to support all test instructions. Therefore, embodiments of this disclosure provide another CPU verification system 200, including multiple spike simulators 202, such that one spike simulator 202 corresponds to one CPU core, thereby allowing the spike simulator 202 to support only the test instructions corresponding to that CPU core. For example, differential comparison module A 203 can read the test instructions corresponding to the CPU core from the corresponding region or address in the shared memory module 204 and transmit the test instructions to core A, and can also transmit them to the spike simulator 202 corresponding to core A. Similarly, differential comparison module B 203 can read the test instructions corresponding to the CPU core from the corresponding region or address in the shared memory module 204 and transmit the test instructions to core B, and can also transmit them to the spike simulator 202 corresponding to core B.

[0053] Therefore, by utilizing multiple Spike simulators 202 and mapping each Spike simulator 202 to a CPU core, simultaneous and independent verification across multiple cores can be supported, allowing different CPU cores to execute completely different test instructions. Furthermore, the one-to-one binding of the Spike simulator 202 to each CPU core ensures complete data isolation, preventing comparison errors and false alarms.

[0054] Figure 5 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure.

[0055] like Figure 5As shown, in the CPU verification system 200, the design model 201 of the CPU under test contains multiple CPU cores, such as CPU core 0, ..., CPU core N. CPU cores 0 through N can read the corresponding test instructions from the shared storage module 204 in parallel, generate execution results, and store the results in the shared storage module 204. After one CPU core completes execution and transmits the result to the shared storage module 204, the corresponding spike simulator 202 reads the same test instruction through the differential comparison module 203 and transmits the result to the shared storage module 204. If the shared storage module 204 compares the results of the two execution instructions and determines that they are consistent, the CPU core can execute the next test instruction. Simultaneously, other CPU cores can also read the corresponding test instructions from the shared storage module 204, generate execution results, and the corresponding spike simulator 202 executes the same test instructions.

[0056] When outputting differential verification results, multiple differential comparison modules 203, such as differential comparison modules 203 0 to differential comparison modules 203 N, can each output their own differential verification results. Alternatively, multiple differential comparison modules 203 can send their respective differential verification results to the same output module, which will then output the differential verification results uniformly.

[0057] Figure 6 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure.

[0058] like Figure 6 As shown, the CPU verification system 200 also includes a data controller 205.

[0059] In the embodiments of this disclosure, the data controller 205 is at least used to read test instructions corresponding to multiple CPU cores from the shared storage module 204, distribute the test instructions to the corresponding CPU cores, and store the execution results of the test instructions by the multiple CPU cores in the shared storage module 204.

[0060] Each independent core of the RV32 multi-core CPU can execute test instructions from the RV32 instruction set in parallel. The raw data for instruction execution and the result data generated by each CPU core can be transmitted to the data controller 205 in real time. The data controller 205 can uniformly receive heterogeneous data from multiple parallel inputs and perform integrity verification on the data to ensure that the received test instructions / execution result data are transmitted without errors, providing a reliable data source for subsequent transfer.

[0061] In some embodiments, the data controller 205 can also allocate an independent cache processing channel to each CPU core according to the area division rules of the shared storage module 204, logically isolating the test instructions and execution result data of different CPU cores to avoid data overlap between different CPU cores. Simultaneously, the data controller 205 can also store the corresponding test instructions and execution result data into the appropriate areas according to the area division of the shared storage module 204, preventing cross-area data writing issues and thus ensuring the independence of the data source for each CPU core in subsequent differential verification.

[0062] In embodiments of this disclosure, the test instructions include at least extended functionality test instructions, which are used to represent non-standard RISC-V instructions.

[0063] RISC-V, as an open-source instruction set architecture (ISA), features a modular design that allows for flexible selection of instruction set extensions to adapt to different application scenarios. The instruction set in this disclosure may include a basic instruction set and extended functional test instruction sets, such as the RV32I basic integer instruction set, RV32M multiplication and division instruction extensions, RV32C compressed instruction set extensions, and RV32E simplified instruction set variants. The basic instruction set is a necessary instruction set. The CPU verification system provided in this disclosure supports instruction trimming in addition to the extended functional test instruction set, allowing for adaptation to different CPU designs.

[0064] In embodiments of this disclosure, the test instructions may further include a non-standard RISC-V instruction set, which may include multiple non-standard RISC-V instructions. Non-standard RISC-V instructions can be customized according to actual needs, thereby allowing for the creation of the most suitable CPU core based on application requirements.

[0065] Figure 7 This is a flowchart of a CPU verification method according to an embodiment of the present disclosure.

[0066] like Figure 7 As shown in the embodiments of this disclosure, a CPU verification method is applied to the CPU verification system described above.

[0067] S701. Execute test instructions using the design model of the CPU under test. The design model is based on the RV32 architecture CPU and has one or more CPU cores.

[0068] In the embodiments of this disclosure, the design model 201 can obtain an RV32 test instruction from the instruction stream, and after executing the test instruction, output the execution result of the test instruction (including register values, memory data, etc.) to the differential comparison module 203.

[0069] S702 drives the Spike simulator to synchronously execute test instructions for the design model.

[0070] In the embodiments of this disclosure, the spike simulator 202 can obtain the same test instructions as the design model 201 from the differential comparison module 203, execute the test instructions, and generate correct execution results. Furthermore, the spike simulator 202 can output the test results to the differential comparison module 203.

[0071] S703. Compare the execution results of the test instructions on the design model with the execution results of the test instructions on the spike simulator to verify the design model of the CPU under test.

[0072] In the embodiments of this disclosure, the differential comparison module 203 can obtain the results of the execution instructions of the design model 201 and the execution instructions of the spike simulator 202. After obtaining the results of the two execution instructions, the results of the two execution instructions are compared. If the comparison result shows that the results of the two execution instructions are consistent, the next test instruction is executed. If the comparison result shows that the results of the two execution instructions are inconsistent, the process is immediately terminated and an error is reported.

[0073] In some embodiments, when the design model 201 of the CPU under test corresponds to a CPU core, the number of spike simulator 202 and differential comparison module 203 can be one, to execute the same test instructions as the CPU core.

[0074] In some embodiments, the test instruction set executed on design model 201 can be provided by the user (USER), can be written by the user, or can be generated by other tools. The test instruction set executable file can be compiled by the RISCV compiler into an executable file type (.elf) for the design model 201 of the CPU under test.

[0075] In embodiments of this disclosure, when the design model has multiple CPU cores, such as Figure 7 The method also includes: reading test instructions corresponding to CPU cores from a shared storage module, wherein the shared storage module is used to store at least a number of test instructions corresponding to CPU cores; and storing the execution results of the multiple CPU cores and the execution results of the spike simulator into the shared storage module.

[0076] The shared storage module 204 stores test instructions corresponding to multiple CPU cores. The data controller 205 can read the test instructions corresponding to the CPU cores from the shared storage module 204 and distribute the test instructions to the corresponding CPU cores. Furthermore, after the CPU core executes the test instructions and obtains the execution result, the data controller 205 can write the execution result to the corresponding area in the shared storage module 204, for example, storing the execution result in the same area as where the CPU core's test instructions are stored.

[0077] Simultaneously, the data controller 205 can read the test instruction corresponding to the CPU core from the shared storage module 204 and distribute the test instruction to the spike simulator 202 corresponding to the CPU core. The spike simulator 202 executes the test instruction and obtains the execution result. After the spike simulator 202 executes the test instruction and obtains the result, the data controller 205 can write the result of the execution instruction to the corresponding area in the shared storage module 204, for example, storing the result of the execution instruction in the same area as the area where the test instruction is stored.

[0078] Therefore, the differential comparison module 203 can simultaneously obtain the results of the CPU core execution instructions and the results of the spike simulator 202 corresponding to the CPU core execution instructions from the shared storage module 204, and determine whether to execute the next test instruction based on the results of the two execution instructions.

[0079] In some embodiments, there is only one spike simulator 202. In this case, the spike simulator 202 needs to execute the test instructions corresponding to all CPU cores. When storing multiple test instructions, the shared storage module 204 can store multiple test instructions in the execution order according to the CPU cores, and simultaneously store the corresponding CPU core information. After one CPU core completes the execution of a test instruction, the spike simulator 202 executes the same test instruction. If the execution result of the CPU core and the execution result of the spike simulator 202 are the same, another CPU core executes another test instruction, and the spike simulator 202 executes the same test instruction.

[0080] In some embodiments, the number of spike simulators 202 is multiple, and the number is the same as the number of CPU cores. In this case, one spike simulator 202 only needs to execute the test instructions corresponding to the CPU core. When storing multiple test instructions, the shared storage module 204 can store multiple test instructions according to the CPU core, for example, storing test instructions belonging to the same CPU core in the same area. Multiple CPU cores can execute test instructions simultaneously, and multiple spike simulators 202 execute their corresponding test instructions in parallel.

[0081] Figure 8 This is a schematic diagram of another CPU verification system according to an embodiment of the present disclosure.

[0082] like Figure 8 As shown in the CPU verification system 200, the CPU design model 201 of the CPU under test has multiple CPU cores, such as CPU core 0, ..., CPU core N. Each CPU core has a private data cache module and a cache controller. The private data cache module is a dedicated cache for each CPU core, used to temporarily store frequently accessed instructions and data. The cache controller manages the read / write and consistency of the private cache, and is responsible for moving CPU core instructions / data between the cache and lower-level storage. The cache controllers of multiple CPU cores can read or write data from the data controller 205 through an interconnection network. The last-level cache module can be used to store common data that may be accessed by multiple CPU cores.

[0083] The data controller 205 can read the test instructions corresponding to each CPU core from the shared storage module 204 and distribute them to the cache controller corresponding to each CPU core via the interconnect network. The CPU core can obtain a single test instruction from the cache controller and execute the test instruction. The generated execution result can be transmitted to the data controller 205 via the cache controller and the interconnect network, and then written to the corresponding area of ​​the shared storage module 204 by the data controller 205.

[0084] The differential comparison module 203 corresponding to the CPU core, such as differential comparison module 203 0 or differential comparison module 203N, can read the corresponding test instructions from the shared memory module 204 and pass them to the corresponding spike simulator 202, such as spike simulator 202 0 or spike simulator 202 N. The spike simulator 202 corresponding to the CPU core executes the same test instructions as the CPU core. After the spike simulator 202 generates the result of the executed instructions, it writes the result of the executed instructions into the area corresponding to the CPU core in the shared memory module 204 through the differential comparison module 203.

[0085] Furthermore, the differential comparison module 203 can read the execution results generated by the CPU core and the execution results generated by the spike simulator 202 from the shared storage module 204, and compare the two to determine the differential verification result.

[0086] The above description, with reference to the accompanying drawings, illustrates a CPU verification system and method according to embodiments of the present disclosure. The system determines a design model based on an RV32 architecture CPU and executes test instructions to generate execution result. Simultaneously, the same test instructions are executed synchronously using a spike simulator to generate standard execution result. A differential comparison module then compares the results of the two execution instructions to verify the design model of the CPU under test. When the design model of the CPU under test includes multiple CPU cores, a shared storage module stores the different test instructions for each CPU core, and the results of the CPU core execution instructions and the corresponding spike simulator execution instructions are stored in the same region or address. This allows multiple CPU cores to process synchronously and in parallel without interference.

[0087] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0088] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0089] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0090] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0091] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described above can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0092] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0093] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A CPU verification system, characterized in that, The system includes: The design model of the CPU under test is determined based on the RV32 architecture CPU, and the design model is used at least to execute test instructions; The spike simulator, at least for executing the test instructions synchronously with the design model; and A differential comparison module communicates with the design model and the spike simulator, and is used at least to compare the execution results of the design model and the spike simulator to verify the design model of the CPU under test.

2. The CPU verification system according to claim 1, characterized in that, The design model has one or more CPU cores.

3. The CPU verification system according to claim 2, characterized in that, When the number of CPU cores in the design model is multiple, the system further includes: A shared storage module is provided, which is used to store at least the test instructions corresponding to the multiple CPU cores, the execution results of the test instructions by the multiple CPU cores, and the execution results of the test instructions by the spike simulator.

4. The CPU verification system according to claim 3, characterized in that, The shared storage module is also used to store the execution order of the test instructions, and to store the test instructions and execution results corresponding to different CPU cores to different addresses.

5. The CPU verification system according to claim 3, characterized in that, The number of spike simulators is one, the number of differential comparison modules is one, and the spike simulator is used to execute at least a plurality of the test instructions corresponding to the CPU cores.

6. The CPU verification system according to claim 3, characterized in that, The number of spike simulators is the same as the number of CPU cores, the number of differential comparison modules is the same as the number of spike simulators, each spike simulator corresponds to a different comparison module, and each spike simulator corresponds to a CPU core, so as to execute the test instructions of the CPU core corresponding to the spike simulator.

7. The CPU verification system according to claim 3, characterized in that, The system also includes: A data controller is configured to at least read the test instructions corresponding to the plurality of CPU cores from the shared storage module, distribute the test instructions to the corresponding CPU cores, and store the execution results of the test instructions by the plurality of CPU cores in the shared storage module.

8. The CPU verification system according to claim 1, characterized in that, The test instructions include at least extended function test instructions, which are used to represent non-standard RISC-V instructions.

9. A CPU verification method, characterized in that, The method includes: Test instructions are executed using a design model of the CPU under test, wherein the design model is based on the RV32 architecture CPU and the number of CPU cores in the design model is one or more. Drive the spike simulator to synchronously execute the test instructions of the design model; and The execution results of the test instructions by the design model are compared with the execution results of the test instructions by the spike simulator to verify the design model of the CPU under test.

10. The CPU verification method according to claim 9, characterized in that, When the number of CPU cores in the design model is multiple, the method further includes: The test instructions corresponding to the CPU core are read from the shared storage module, wherein the shared storage module is used to store at least a plurality of the test instructions corresponding to the CPU core; and The execution results of the multiple CPU cores and the execution results of the spike simulator are stored in the shared storage module.

Images