A CPU emulation acceleration system

Abstract

The application relates to the technical field of chip simulation verification, in particular to a CPU simulation acceleration system, which supports mutual calling of a CPU simulation module and a firmware program in the form of a dynamic library, compared with an existing scheme, a CPU instruction execution flow is skipped, a hardware operation task is directly called through the dynamic library, the link length of register operation is shortened, the simulation efficiency is greatly improved, and the architecture of a verification platform, the CPU simulation module and the dynamic library is more decoupled, the instruction flow conversion in the link of register operation is clearer, and the convenience of modification and problem positioning in the simulation process is improved.

Description

Technical Field

[0001] This invention relates to the field of chip simulation and verification technology, and in particular to a CPU simulation acceleration system. Background Technology

[0002] In the chip design verification phase, CPU emulation (such as RISC-V CPU) is a core step in verifying hardware functionality. In existing solutions, register configuration requires the following process: the firmware program is compiled into binary code, loaded into the local memory of the CPU emulation module, and then the CPU emulation module parses the binary instructions through pipelined operations such as instruction fetching, decoding, and execution, ultimately completing the read and write operations on the registers.

[0003] However, the simulation overhead of the CPU instruction pipeline, which consists of instruction fetching, decoding, and execution, is large and the simulation efficiency is low in the existing scheme.

[0004] Therefore, improving CPU simulation efficiency has become an urgent problem to be solved. Summary of the Invention

[0005] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0006] A CPU simulation acceleration system includes a verification platform, a CPU simulation module, and a dynamic library. The CPU simulation module includes calling tasks, operating tasks, and operable registers. The dynamic library is compiled from an interface interaction layer, calling functions, and firmware programs. The firmware programs include operating functions.

[0007] The verification platform sends operation instructions to the calling task of the CPU simulation module to operate the registers.

[0008] The CPU simulation module is connected to the dynamic library through a preset interface. After the CPU simulation module's calling task receives the operation instruction, the CPU simulation module calls the calling function through the interface interaction layer according to the operation instruction.

[0009] The calling function is used to send the operation instructions to the firmware program.

[0010] The firmware program is used to call the corresponding operation function according to the operation instruction.

[0011] The operation function calls the operation task in the CPU simulation module through the interface interaction layer to operate on the register.

[0012] Compared with the prior art, the present invention has significant advantages. Through the above technical solution, the CPU simulation acceleration system provided by the present invention achieves considerable technological advancement and practicality, and has broad industrial application value. It has at least the following advantages:

[0013] This invention supports mutual calls between the CPU simulation module and the firmware program in the form of a dynamic library. Compared with the existing solutions, it skips the CPU instruction execution process and directly calls hardware operation tasks through the dynamic library, shortening the link length of register operations and thus greatly improving simulation efficiency. Moreover, the architecture of the verification platform, CPU simulation module and dynamic library is more decoupled, and the instruction flow in the register operation link is clearer, which improves the convenience of modification and problem localization during the simulation process. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0015] Figure 1 This is a flowchart illustrating the execution of a computer program by a processor in a CPU simulation acceleration system according to Embodiment 1 of the present invention.

[0016] Figure 2 This is a flowchart illustrating an interrupt handling method for CPU emulation provided in Embodiment 2 of the present invention. Detailed Implementation

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

[0018] This embodiment provides a CPU emulation acceleration system, see [link to documentation]. Figure 1 This is a schematic diagram of the architecture of a CPU simulation acceleration system provided in Embodiment 1 of the present invention. The system includes: a verification platform, a CPU simulation module and a dynamic library. The CPU simulation module includes calling tasks, operating tasks and operable registers. The dynamic library is obtained by compiling an interface interaction layer, calling functions and firmware programs. The firmware programs include operating functions.

[0019] The verification platform sends operation instructions to the calling task of the CPU simulation module to operate the register;

[0020] The CPU simulation module is connected to the dynamic library through a preset interface. After the calling task of the CPU simulation module receives the operation instruction, the CPU simulation module calls the calling function through the interface interaction layer according to the operation instruction.

[0021] The calling function is used to send the operation instructions to the firmware program;

[0022] The firmware program is used to call the corresponding operation function according to the operation instruction;

[0023] The operation function calls the operation task in the CPU simulation module through the interface interaction layer to operate on the register.

[0024] The verification platform can refer to the top-level control terminal for chip verification, which in this embodiment is used to initiate operation instructions on the registers.

[0025] A CPU simulation module can refer to a CPU simulation model implemented in SystemVerilog and conforming to the RISC-V specification.

[0026] A dynamic library can be a shared library compiled in C language to encapsulate configuration logic and interact with the CPU simulation module. Dynamic libraries can be compiled by gcc from an interface interaction layer, calling functions, and firmware programs.

[0027] The calling task can refer to the entry task in the CPU simulation module that receives instructions from the verification platform, while the operation task can refer to the low-level task that directly operates on the registers.

[0028] The interface interaction layer can refer to an adaptation layer used to implement cross-language calls. In this embodiment, cross-language can refer to SystemVerilog and C. In this embodiment, the interface interaction layer can use DPI Wrapper.

[0029] The calling function can refer to the entry point function of a dynamic library, which is used to receive and dispatch operation instructions.

[0030] Firmware programs can refer to the core modules in a dynamic library that handle business logic, which may include parameter validation, address mapping, exception handling, etc.

[0031] Operation functions can refer to the interfaces in the firmware program that call the underlying operation tasks of the CPU emulation module.

[0032] In one embodiment, the firmware program further includes a reset function, and the CPU emulation module includes a reset task. When the CPU emulation module triggers the reset task, it resets the registers and other components corresponding to the CPU emulation module and calls the reset function through the interface interaction layer. The reset function is used to re-execute the firmware program.

[0033] The reset can include cold reset and hot reset. Cold reset refers to the reset operation when the CPU simulation module starts up, while hot reset refers to the reset operation during the running phase of the CPU simulation module.

[0034] Specifically, implementers can control whether the reset function re-executes the firmware program by setting the corresponding global variable for reset.

[0035] In one specific implementation, the operation instructions include read instructions and write instructions, the operation function includes read functions and write functions, and the operation task includes read tasks and write tasks;

[0036] Accordingly, the firmware program is used to call the corresponding operation function according to the operation instruction, including:

[0037] The firmware program is used to call the corresponding write function according to the write instruction;

[0038] The firmware program is used to call the corresponding read function according to the read instruction.

[0039] Operations on registers can be divided into read operations and write operations. A read operation refers to reading the value from the register, while a write operation refers to modifying the value in the register with the configured value.

[0040] A read instruction can refer to an instruction that retrieves the current value of a register, while a write instruction can refer to an instruction that modifies the value of a register. A read function can refer to the interface function in the firmware program that corresponds to a read operation, and a write function can refer to the interface function in the firmware program that corresponds to a write operation. A read task can refer to the low-level task in the CPU emulation module that performs a read operation, and a write task can refer to the low-level task in the CPU emulation module that performs a write operation.

[0041] Taking a read command as an example, after the verification platform initiates a read command, it calls the function of the dynamic library triggered by the task. The function forwards the command to the firmware program, which recognizes it as a read operation, calls the read function, and finally obtains the register value through the read task.

[0042] In one specific implementation, the operation function calls the operation task in the CPU simulation module through the interface interaction layer to operate on the register, including:

[0043] The write function calls the write task in the CPU simulation module through the interface interaction layer to perform a write operation on the register;

[0044] The read function calls the read task in the CPU simulation module through the interface interaction layer to perform a read operation on the register.

[0045] The write function receives the write instruction from the firmware program and calls the write task of the CPU simulation module through the interface interaction layer. The write task directly writes the value to the register corresponding to the register address. Similarly, the read function calls the read task through the interface interaction layer and returns the register value.

[0046] In one specific implementation, the preset interface is a DPI interface.

[0047] The DPI (Direct Programming Interface) is a cross-language interface of the SystemVerilog standard, supporting bidirectional function calls between SystemVerilog and C / C++.

[0048] In one specific implementation, the CPU simulation module belongs to the SystemVerilog language layer, while the interface interaction layer, calling functions, and firmware program belong to the C language layer.

[0049] The SystemVerilog layer can refer to the simulation logic implemented in a hardware description language (HDL), which is suitable for describing hardware behavior and has timing characteristics. The C language layer can refer to the logic implemented in a software language, which is suitable for writing complex business logic but does not have timing characteristics.

[0050] In one specific implementation, the operation instruction includes at least an operation type, a register address, and a configuration value.

[0051] The operation type can be used to distinguish between read and write operations, the register address can refer to the physical address of the register to be operated on, the configuration value can refer to the target value during a write operation, and the configuration value can be ignored during a read operation.

[0052] Specifically, the operation instructions may also include extended fields such as CPU ID.

[0053] In one specific implementation, the system includes M CPU simulation modules, where M is an integer greater than 1.

[0054] Among them, M CPU simulation modules can refer to multiple independent RISC-V CPU simulation instances, each with independent registers and tasks. The M CPU simulation modules can share the verification platform and dynamic library framework.

[0055] In one specific implementation, M dynamic libraries are copied, and the memory address spaces corresponding to the M dynamic libraries are different.

[0056] The m-th CPU simulation module is bound only to the m-th dynamic library, where m is an integer in the range [1, M].

[0057] The global variables corresponding to the M dynamic libraries are declared as thread-local storage variables.

[0058] Among them, M dynamic libraries are loaded into different memory regions to avoid symbol conflicts and achieve memory address isolation. Each CPU simulation module has a unique corresponding dynamic library, and each CPU simulation module is bound to its unique corresponding dynamic library. That is, the m-th CPU simulation module is only bound to the m-th dynamic library, thereby achieving physical connection isolation.

[0059] By using "__thread" to declare global variables, each thread, i.e. each CPU simulation module, has an independent instance that does not interfere with each other, thereby avoiding crosstalk between threads and adapting to multi-threaded parallel simulation.

[0060] In one specific implementation, the interface interaction layer, the calling function, and the firmware program are compiled into the dynamic library using GCC. During the compilation process, breakpoints are added using the GDB tool so that the firmware program pauses execution when it reaches the breakpoint.

[0061] In this embodiment, GCC (GNU Compiler Collection) compilation is implemented through the GCC compiler and is used to convert code into dynamic libraries. The GDB (GNU Debugger) tool is used to debug firmware programs.

[0062] Specifically, implementers can use the GDB tool to add custom breakpoints, causing the firmware program to pause when it reaches the breakpoint. If no error occurs when the firmware program reaches the breakpoint, execution continues step by step to check for errors. If an error occurs before reaching the breakpoint, the breakpoint can be moved forward for further evaluation. Therefore, this embodiment provides an efficient method for firmware error checking.

[0063] In this first embodiment, the mutual calling between the CPU simulation module and the firmware program is supported in the form of a dynamic library. Compared with the existing solution, the CPU instruction execution process is skipped, and hardware operation tasks are directly called through the dynamic library, which shortens the link length of register operation and thus greatly improves simulation efficiency. Moreover, the architecture of the verification platform, CPU simulation module and dynamic library is more decoupled, and the instruction flow in the register operation link is clearer, which improves the convenience of modification and problem location during the simulation process.

[0064] This second embodiment provides an interrupt handling method for CPU emulation, see [link to previous document]. Figure 2 This is a flowchart illustrating an interrupt handling method for CPU emulation provided in Embodiment 2 of the present invention. The method includes:

[0065] S201, when the interrupt flag in the received target program is a first preset value, the target program is executed, and after the target program is executed, the interrupt signal corresponding to the CPU simulation module is set to a second preset level.

[0066] S202, when the interrupt flag in the received target program is a second preset value, obtain the interrupt signal corresponding to the CPU simulation module;

[0067] S203, if the interrupt signal is at the first preset level, then execute the target program;

[0068] S204, if the interrupt signal is at the first preset level, then wait for the interrupt signal to change to the second preset level before executing the target program.

[0069] The target program can refer to the firmware program logic to be executed. The target program can be an interrupt program or a main program. The interrupt identifier can be a mark in the target program used to distinguish the program type. The program type is the interrupt program type and the main program type.

[0070] The first preset value can refer to a value used to identify the corresponding program as an interrupt program. In this embodiment, the first preset value can be set to 0.

[0071] The second preset value can refer to a value used to identify the corresponding program as the main program. In this embodiment, the second preset value can be set to 1.

[0072] As can be seen, the interrupt flag only needs to be represented by adding 1 bit to the corresponding function in the target program.

[0073] The first preset level can be a low level, and correspondingly, the second preset level can be a high level. It should be noted that, under normal circumstances, the interrupt triggering of the CPU emulation module can be achieved by a level signal or a pulse signal. A level signal can refer to continuously maintaining the interrupt signal at a high level, while a pulse signal can refer to setting the interrupt signal to a high level within the corresponding trigger cycle and then restoring it to a low level. However, when the firmware program is executing the interrupt program or the main program, it may be unable to detect the pulse signal. Therefore, in this embodiment, the pulse signal is also extended to a level signal, and functions for obtaining the interrupt signal and setting the interrupt signal are set. The function for obtaining the interrupt signal is used to obtain the interrupt signal corresponding to the CPU emulation module, and the function for setting the interrupt signal is used to set the interrupt signal corresponding to the CPU emulation module to the second preset level. Both the function for obtaining the interrupt signal and the function for setting the interrupt signal are implemented through interface functions.

[0074] It should be noted that, typically, the interrupt routine and the main program execute at different times, operating asynchronously. This can lead to address conflicts in global variables between the two programs. In this embodiment, both the interrupt routine and the main program are implemented using infinite loops. Furthermore, functions for acquiring and setting interrupt signals enable the interrupt routine to proactively acquire and handle interrupts, preventing memory leaks caused by address changes. This embodiment allows the interrupt routine to execute directly, ensuring real-time interrupt handling. The main program executes only when the interrupt routine is not running; otherwise, it waits for the interrupt routine to finish, ensuring operational safety, preventing both types of programs from simultaneously accessing registers, and guaranteeing the atomicity of the configuration logic.

[0075] In one specific implementation, the target program is an interrupt program or a main program;

[0076] The interrupt routine includes a first operation function, and the main program includes a second operation function;

[0077] The interrupt flag included in the first operation function is a first preset value, and the interrupt flag included in the second operation function is a second preset value.

[0078] The first operation function can refer to the function that implements the core function in the interrupt routine. In this embodiment, it mainly refers to the function used to operate the register in the interrupt scenario.

[0079] The second operation function can refer to the function in the main program that implements the core function. In this embodiment, it mainly refers to the function used to operate the register in a normal scenario.

[0080] In one specific implementation, both the first operation function and the second operation function correspond to operation tasks in the CPU simulation module. When the first operation function and the second operation function are executed, they both call the operation tasks in the CPU simulation module to operate on the registers.

[0081] The operation task can refer to the low-level task of directly reading and writing registers in the CPU simulation module, and the CPU simulation module can refer to a CPU simulation model implemented in SystemVerilog language and conforming to the RISC-V specification.

[0082] Specifically, the first operation function can be a write operation function or a read operation function, and similarly, the second operation function can be a write operation function or a read operation function. Accordingly, the operation task can include a write operation task and a read operation task.

[0083] In one specific implementation, the target program is a firmware program, and the firmware program, interface interaction layer and calling functions are compiled to obtain a dynamic library. The CPU simulation module loads the dynamic library and connects to the dynamic library through a preset interface.

[0084] The interface interaction layer can refer to an adaptation layer used to implement cross-language calls. In this embodiment, cross-language can refer to SystemVerilog and C. In this embodiment, the interface interaction layer can use DPI Wrapper.

[0085] The calling function can refer to the entry function of a dynamic library, which is used to receive and distribute operation instructions. The operation instructions are sent by the verification platform to the calling task of the CPU simulation module to operate the registers. The CPU simulation module calls the calling function through the interface interaction layer according to the operation instructions.

[0086] Firmware programs can refer to the core modules in a dynamic library that handle business logic, which may include parameter validation, address mapping, exception handling, etc.

[0087] In one specific implementation, there are M CPU simulation modules, where M is a positive integer;

[0088] Accordingly, 2×M dynamic libraries are copied, and each of the 2×M dynamic libraries corresponds to a different memory address space;

[0089] The m-th CPU simulation module is bound to the (2m-1)-2m-1 dynamic library and the 2m-2m dynamic library, where m is an integer in the range [1, M].

[0090] Among them, 2×M dynamic libraries are loaded into different memory regions to avoid symbol conflicts and achieve memory address isolation.

[0091] In one specific implementation, the 2m-1th dynamic library and the 2mth dynamic library have a corresponding mth independent storage area, which is used to support data interaction of global variables that the 2m-1th dynamic library and the 2mth dynamic library need to share.

[0092] Specifically, for a single CPU simulation module, the global variables that need to be shared by the two dynamic libraries bound to the CPU simulation module are only visible or synchronized between the two dynamic libraries bound to the CPU simulation module.

[0093] In one specific implementation, global variables that do not need to be shared between the 2m-1th dynamic library and the 2mth dynamic library are declared as thread-local storage variables.

[0094] In this system, the global variables of the dynamic libraries corresponding to different CPU simulation modules are completely isolated, and the global variables of the two dynamic libraries bound to the same CPU simulation module that do not need to be shared are also completely isolated to avoid interference.

[0095] In one specific implementation, the CPU emulation module prohibits the repeated loading of dynamic libraries.

[0096] To avoid crosstalk between the interrupt routine and the main program, the CPU simulation module prohibits the repeated loading of dynamic libraries, thereby ensuring the accuracy of the interrupt synchronization logic.

[0097] Compared to existing technologies, this second embodiment adds an interrupt flag to the target program, and the firmware program actively acquires and sets the interrupt signal, effectively avoiding global variable address conflicts caused by asynchronous program execution. Based on the interrupt flag and interrupt signal, it can realize the mechanism of immediate execution of the interrupt program and waiting for the interrupt program to complete, avoiding simultaneous operation of registers by two types of programs, ensuring the atomicity of configuration logic, avoiding concurrent conflicts, conforming to the timing logic of interrupt response priority, and improving the reliability of simulation.

[0098] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of this invention is defined by the appended claims.

Claims

1. A CPU emulation acceleration system, characterized by, The system comprises a verification platform, a CPU simulation module and a dynamic library, wherein the CPU simulation module comprises a calling task, an operating task and an operable register, the dynamic library is obtained by compiling an interface interaction layer, a calling function and a firmware program, and the firmware program comprises an operating function; The verification platform sends an operating instruction to the calling task of the CPU simulation module to operate the register; The CPU simulation module is connected with the dynamic library through a preset interface, and after the calling task of the CPU simulation module receives the operating instruction, the CPU simulation module calls the calling function through the interface interaction layer according to the operating instruction; The calling function is used to send the operating instruction to the firmware program; The firmware program is used to call a corresponding operating function according to the operating instruction; The operating function calls the operating task in the CPU simulation module through the interface interaction layer to operate the register.

2. The CPU emulation acceleration system of claim 1, wherein, The operating instruction comprises a read instruction and a write instruction, the operating function comprises a read function and a write function, and the operating task comprises a read task and a write task; Correspondingly, the firmware program is used to call a corresponding operating function according to the operating instruction, comprising: The firmware program is used to call a corresponding write function according to the write instruction; The firmware program is used to call a corresponding read function according to the read instruction.

3. The CPU emulation acceleration system of claim 2, wherein, The operating function calls the operating task in the CPU simulation module through the interface interaction layer to operate the register, comprising: The write function calls the write task in the CPU simulation module through the interface interaction layer to perform a write operation on the register; The read function calls the read task in the CPU simulation module through the interface interaction layer to perform a read operation on the register.

4. The CPU emulation acceleration system of claim 1, wherein, The preset interface is a DPI interface.

5. The CPU emulation acceleration system of claim 1, wherein, The CPU simulation module belongs to a SystemVerilog language layer, and the interface interaction layer, the calling function and the firmware program belong to a C language layer.

6. The CPU emulation acceleration system of claim 1, wherein, The operating instruction at least comprises an operating type, a register address and a configuration value.

7. The CPU emulation acceleration system of claim 1, wherein, The system comprises M CPU simulation modules, wherein M is an integer greater than 1.

8. The CPU emulation acceleration system of claim 7, wherein, M dynamic libraries are obtained by copying, and the memory address spaces corresponding to the M dynamic libraries are different; The mth CPU simulation module is only bound with the mth dynamic library, wherein m is an integer in the range of [1, M]; The global variables corresponding to the M dynamic libraries are declared as thread-local storage variables.

9. The CPU emulation acceleration system of claim 1, wherein, The interface interaction layer, the calling function and the firmware program obtain the dynamic library by GCC compilation, and in the compilation process, a breakpoint is added by using a GDB tool to make the firmware program pause execution when the breakpoint is reached.

Images