Method and system for software and hardware joint simulation

Abstract

The invention discloses a method and a system for software and hardware joint simulation. The method comprises the steps that at least one interface function corresponding to a target hardware function module is set according to behaviors of the target hardware function module, and each interface function achieves one behavior of the target hardware function module through a software algorithm. In the register transfer level hardware circuit code where the target hardware module is located, operation on the target hardware module is replaced by calling of the at least one interface function, and therefore the modified register transfer level hardware circuit code is obtained. And uniformly compiling the transformed register transfer level hardware circuit code and the software code corresponding to each of the at least one interface function to generate a first simulation program. According to the method, the risk that errors are introduced from a software algorithm to hardware RTL manual translation is eliminated from the source, the performance evaluation period of the hardware level is greatly shortened, and the hardware research and development cost is remarkably reduced.

Description

Technical Field

[0001] This application relates to the field of hardware development technology, and specifically to methods and systems for hardware-software co-simulation. Background Technology

[0002] The statements in this section are merely to provide background information in relation to this application to aid in understanding it, and such background information does not necessarily constitute prior art.

[0003] In modern high-performance processor design, the hardware development process typically follows a fixed pattern: First, algorithms are designed and explored at the software level. Developers use high-level languages ​​(such as C++) to build software simulators. These simulators can simulate hardware behavior, facilitating rapid debugging and performance verification. Next, after verifying and selecting ideal algorithms using software simulators, the hardware implementation phase begins. Developers write the verified algorithms (software algorithms) in hardware description languages ​​(HDLs, such as Verilog and Chisel) to create hardware RTL (Register Transfer Level) code (or simply hardware RTL), and integrate it into the complete hardware design. Subsequently, logic simulation is performed on the integrated hardware design to verify its functional correctness and evaluate its performance under real-world timing conditions. The traditional hardware development process separates software simulation and hardware implementation into two independent stages, leading to numerous bottlenecks in the process from software algorithm to hardware implementation, resulting in inefficiency and a high risk of errors. Summary of the Invention

[0004] The objective of this application is achieved through the following technical solution: According to a first aspect of this application, a method for hardware-software co-simulation is provided, comprising: setting at least one interface function corresponding to a target hardware functional module based on the behavior of the target hardware functional module, each interface function implementing a behavior of the target hardware functional module through a software algorithm; replacing operations on the target hardware module with calls to the at least one interface function in the register transfer level hardware circuit code (hardware RTL) where the target hardware module is located, thereby obtaining modified register transfer level hardware circuit code; and uniformly compiling the modified register transfer level hardware circuit code and the corresponding software code of each of the at least one interface function to generate a first simulation program.

[0005] Preferably, the method further includes: executing the generated first simulation program based on a standard test set and recording the behavior and performance indicators related to the target hardware functional module to obtain a standard log; replacing the calls to the interface functions of the target hardware module with the hardware algorithm implementation of the target hardware module in the modified register transfer level hardware circuit code, and recompiling to obtain a second simulation program; executing the second simulation program based on the standard test set and recording the behavior and performance indicators related to the target hardware functional module to obtain a test log; and locating logical errors in the hardware algorithm implementation of the target hardware module based on the comparison between the standard log and the test log.

[0006] Preferably, the standard log and the log to be tested are further implemented by embedding data recording probes in the software algorithm implementation and hardware algorithm implementation of the target hardware functional module to record context information related to the operation of the target hardware functional module.

[0007] Preferably, the software algorithm implementation of the target hardware functional module includes software code corresponding to each interface function, and the software code has been verified at the software level and can simulate each behavior of the target hardware functional module.

[0008] Preferably, the method further includes: using a script tool to parse the standard log and the log to be tested, and generating a visualization file for debugging the hardware algorithm implementation of the target hardware module based on the parsing results and preset visualization requirements.

[0009] Preferably, the script tool uses Python to call the database toolbox and / or the drawing toolbox to generate visualization files.

[0010] Preferably, the call to the at least one interface function in the register transfer level hardware circuit code where the target hardware module is located is implemented using the DPI-C interface standard in SystemVerilog, and the software algorithm implementation of the interface function is written in C / C++.

[0011] Preferably, the process of uniformly compiling the modified register-transfer level hardware circuit code and the corresponding software code of each of the at least one interface function to generate the first simulation program includes: inputting the file of the modified register-transfer level hardware circuit code and the file of the corresponding software code of each of the at least one interface function into a simulation tool that supports DPI-C; the simulation tool that supports DPI-C uniformly compiles the input files to generate the first simulation program.

[0012] Preferably, the simulation tools that support DPI-C include Verilator and VCS.

[0013] According to a second aspect of this application, a system for software-hardware co-simulation is provided, comprising: an interface function setting module, a hardware code modification module, and a compilation and simulation module; wherein, the interface function setting module is configured to set at least one interface function corresponding to the target hardware functional module according to the behavior of the target hardware functional module, and each interface function implements a behavior of the target hardware functional module through a software algorithm; the hardware code modification module is configured to replace the operation on the target hardware module with a call to the at least one interface function in the register-transfer level hardware circuit code where the target hardware module is located, thereby obtaining modified register-transfer level hardware circuit code; the compilation and simulation module is configured to compile the modified register-transfer level hardware circuit code and the corresponding software code of each of the at least one interface function in a unified manner to generate a first simulation program.

[0014] Preferably, the system further includes a hardware debugging module configured to: execute a generated first simulation program based on a standard test set and record behaviors and performance metrics related to the target hardware functional module to obtain a standard log; in the modified register-transfer level hardware circuit code, replace the calls to the interface functions of the target hardware module with the hardware algorithm implementation of the target hardware module, and compile again to obtain a second simulation program; execute the second simulation program based on the standard test set and record behaviors and performance metrics related to the target hardware functional module to obtain a test log; and locate logical errors in the hardware algorithm implementation of the target hardware module based on the comparison between the standard log and the test log.

[0015] Compared with existing technologies, the advantages of this application are: it enables the direct and unmodified application of algorithm code verified on software simulators to the simulation evaluation of hardware RTL, eliminating the risk of errors introduced by manual translation from software algorithm to hardware RTL from the source, greatly shortening the performance evaluation cycle at the hardware level, reducing the time and manpower costs caused by rework due to errors, thereby shortening the development cycle, significantly reducing the cost of hardware R&D, and making rapid iterative verification of algorithms possible. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a flowchart illustrating a method for hardware-software co-simulation according to an embodiment of this application; Figure 2 This is a schematic diagram of a visualization of the intra-group replacement situation of a replacement algorithm according to an embodiment of this application; Figure 3 This is a schematic diagram of the execution process of a hardware-software co-simulation system according to an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided through specific embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0018] As mentioned in the background section, traditional hardware development processes suffer from numerous bottlenecks in the transition from software algorithms to hardware implementation. The inventors, while researching hardware implementation, were deeply troubled by the disconnect between software simulation and hardware implementation in traditional hardware development processes. An algorithm that performed exceptionally well on a software simulator failed to meet performance expectations after significant effort was invested in hardware RTL implementation and simulation (verifying the implementation of register-transfer level hardware circuitry).

[0019] The inventors discovered the following main problems during their research and practice in hardware development: *Simulation efficiency drops drastically: Software simulators often use event-driven methods, while hardware RTL simulations require precision down to the clock cycle level, and their running speed is typically several orders of magnitude (thousands of times or more) slower than software simulators. This makes large-scale performance evaluations or parameter regression tests on hardware extremely time-consuming, severely slowing down development progress.

[0020] *Algorithm migration is difficult and error-prone: Manually translating the algorithm logic verified in a software simulator into hardware RTL code is a complex process that is highly susceptible to errors. On one hand, the framework of the software simulator and the implementation framework of hardware RTL (such as pipeline structure and timing requirements) may differ significantly, causing the algorithm logic to be incompatible and requiring extensive modifications, thus compromising the "purity" of the original software algorithm. On the other hand, developers inevitably introduce logical errors due to oversight during the manual transcription process, and these errors are often difficult to detect.

[0021] Hardware debugging methods are limited and inefficient: Software simulators possess powerful and flexible debugging capabilities, easily printing any intermediate variables, data structures, and statistical information to help developers quickly locate problems. Hardware RTL debugging, however, typically relies on observing waveform files or analyzing hardware performance counters, outputting only macroscopic statistical information and lacking microscopic analysis. This results in extremely low efficiency in locating performance bottlenecks or logical errors and demands greater experience from developers.

[0022] The inventors discovered that the root cause of the aforementioned problems lies in the lack of a direct and efficient communication bridge between the software algorithm model and the hardware RTL entity, requiring manual translation of software code into hardware implementation. Existing technologies only treat software simulation results as a static target for hardware design, without considering directly introducing dynamic and flexible software models into the hardware simulation environment for verification. The traditional view that hardware algorithm design must be a purely hardware description leads to the aforementioned efficiency gap and correctness risks.

[0023] To address the technical challenges of long development cycles, error-prone migration processes, and difficult hardware debugging in existing hardware development technologies when migrating from software models to hardware RTL implementations, this application provides a novel solution that enables software algorithm code to work directly with hardware RTL code. The hardware RTL code can directly call interface functions that implement the software algorithm's functionality, thereby achieving hardware-software co-simulation.

[0024] Figure 1 This is a flowchart illustrating a method for hardware-software co-simulation according to an embodiment of this application. Figure 1 As shown, the method mainly includes: Step S101. Setting at least one interface function corresponding to the target hardware functional module according to the behavior of the target hardware functional module, each interface function implementing a behavior of the target hardware functional module through a software algorithm. In some embodiments, the software algorithm implementation corresponding to each interface function has been verified and confirmed as the final solution on a software simulator. The software algorithm implementation of the target hardware functional module includes software code corresponding to each interface function, such software code has been verified at the software level and can simulate each behavior of the target hardware functional module. Step S102. In the register transfer level hardware circuit code where the target hardware module is located, replacing the operation on the target hardware module with a call to at least one interface function, thereby obtaining the modified register transfer level hardware circuit code. Step S103. Compiling the modified register transfer level hardware circuit code and the corresponding software code in each of the at least one interface function into a unified manner to generate a first simulation program.

[0025] In some embodiments, at least one interface function is called in the register transfer level hardware circuit code where the target hardware module is located using the DPI-C (Direct Programming Interface for C) standard interface in SystemVerilog.

[0026] In some embodiments, the modified register-transfer level hardware circuit code file and the corresponding software code file for each of at least one interface function are input to a DPI-C-enabled simulation tool (e.g., Verilator, VCS). The DPI-C-enabled simulation tool compiles the input files to generate a first simulation program. In some embodiments, the input files may also include a test stimulus code file. The test stimulus code serves as an external driver for hardware operation, specifying how the values ​​of the hardware's clock signal, reset signal, and various input ports change.

[0027] The following section uses the cache replacement algorithm in cache controller design as an example to illustrate this. Figure 1 The execution process of each step of the method shown.

[0028] Step S101 includes analyzing the behavior of the cache replacement algorithm to determine the information required for its interaction with other cache hardware. The information required for interaction may include information related to bus requests received by the cache (e.g., request address, opcode, parameters), and internal cache state information (e.g., cache block state, whether the cache block has been reused). Based on the behavior of the cache replacement algorithm and the information required for interaction, the cache replacement algorithm is abstracted into the following interface function: reset(): The reset function is called by the hardware at the start of the simulation or when the system is reset. It is used to initialize the internal state data structure of the cache replacement algorithm in the software.

[0029] get_next_state(): The state update function is called when a valid access occurs to the cache (whether it is a hit or a new block is filled after a miss), and updates its internal replacement strategy state based on this information.

[0030] invalidate(): The invalidation function is called when a cache line must be invalidated due to an external request (such as a consistency protocol requirement), marking the line as invalid.

[0031] `get_replace_way()`: The replacement way selection function, called when a cache miss occurs. Based on its internally maintained replacement strategy state, it calculates and returns a way that should be replaced, prioritizing invalid ways if any exist.

[0032] In step S102, in the hardware RTL code of the cache controller (using SystemVerilog as an example), the original, fixed cache replacement logic module is removed or commented out, and calls to the aforementioned interface functions are inserted at the corresponding locations. The following is an example of the modified replacement algorithm's hardware RTL code: import "DPI-C" function void reset(); import "DPI-C" function void get_next_state(input int set, input intway); import "DPI-C" function void invalidate(input int set, input intway); import "DPI-C" function int get_replace_way(input int set); module CacheController ( input clk, input reset_n, / / ... other ports ); / / ... caching logic... / / Call the software's reset function during system reset. always_ff @(posedge clk) begin if (!reset_n) begin reset(); end end / / If a cache miss occurs, the replacement path selection function needs to be called. always_comb begin if (cache_miss && !has_invalid_way) begin way_to_replace = get_replace_way(current_set_index); end / / ... Other replacement logic... end In some embodiments, a software algorithm implementation file (e.g., replacer.cpp) for the above-mentioned interface functions is created using a high-level language such as C++. This file contains the software code for the specific software algorithm implementation of the interface functions determined in step S101. Below is the high-level language software code for the LRU (Least Recently Used) replacement algorithm as an example: #include <vector> #include <list> #include <map> / / Use a map to store the LRU state list for each set. static std::map <int, std::list <int>> lru_state; const int NUM_WAYS = 8; / / Assuming 8-way group associativity extern "C" { / / Use C linking to ensure Verilog can find these functions void reset() { lru_state.clear(); } void get_next_state(int set, int way) { / / If the group already exists if (lru_state.count(set)) { / / Remove the way from the list first (if it exists). lru_state[set].remove(way); } / / Push this way to the front of the list to indicate that it has been most recently used. lru_state[set].push_front(way); } void invalidate(int set, int way) { / / For LRU, a simple approach is to remove it from the state. / / This way it won't be considered "recently used," thus indirectly becoming a candidate for replacement.

[0033] if (lru_state.count(set)) { lru_state[set].remove(way); } } int get_replace_way(int set) { / / The last item in the list is the least recently used. if (lru_state.count(set) && !lru_state[set].empty()) { int way_to_replace = lru_state[set].back(); lru_state[set].pop_back(); / / Remove from state return way_to_replace; } / / If the state is empty (e.g., after invalidate), return a default value, such as way 0. return 0; } / / extern "C" Continue to refer to Figure 1 In step S103, a DPI-C-enabled simulation tool is used to input the compilation command (for example, Verilator, the compilation command is as follows: verilator –cc –exe —build top_module.svtestbench.cpp replacer_lru.cpp) to jointly compile the modified register transfer level hardware circuit code file and the interface function software code file to generate a simulation executable program (i.e., a hardware and software joint simulation program, which can also be called the first simulation program).

[0034] In another embodiment of this application, the hardware algorithm implementation of the target hardware module to be verified can also be verified using a first simulation program. Specifically, the generated first simulation program is executed based on a standard test set, and the behavior and performance indicators related to the target hardware functional module are recorded to obtain a standard log. In the modified register-transfer level hardware circuit code, the interface function calls to the target hardware module are replaced with the hardware algorithm implementation of the target hardware module, and then compiled again to obtain a second simulation program (i.e., a hardware simulation program). The second simulation program is executed based on the standard test set, and the behavior and performance indicators related to the target hardware functional module are recorded to obtain a test log. In this way, by comparing the standard log and the test log, logical errors (bugs) existing in the hardware algorithm implementation of the target hardware module can be easily located. Among them, the behavior and performance indicators related to the target hardware functional module are preset according to the target hardware functional module. Taking the cache replacement algorithm as the target hardware module as an example, the replacement path selected each time can be regarded as the relevant behavior, and the hit rate can be regarded as the performance indicator. The preset test set can be a standard test set, which is a set of programs (Benchmarks) used to test and evaluate CPU performance, such as the classic SPEC CPU 2006 test set.

[0035] In the above embodiments, the benchmark for comparison is a fully verified and correct software algorithm implementation. Therefore, any inconsistencies directly expose logical errors in the implementation of the hardware RTL code to be verified. Compared with traditional hardware debugging that locates problems through waveform debugging, the solution in this application transforms the hardware debugging process from tedious waveform analysis to intuitive data analysis, reducing debugging difficulty, increasing the speed of problem location, and efficiently verifying the correctness of the hardware implementation.

[0036] To better address the difficulties in hardware simulation and debugging, in some embodiments, standard logs and test logs are implemented by embedding data recording probes in the software and hardware algorithm implementations of the target hardware functional module to record context information related to the operation of the target hardware functional module. For example, whenever an operation of the target hardware functional module occurs, the relevant context information is recorded in a structured format (such as CSV or JSON) in a log file (e.g., cache_behavior_trace.csv). Taking a cache replacement algorithm as an example, the operation of the target hardware functional module includes cache access, prefetch triggering, and replacement decision. The context information related to the operation of the target hardware functional module includes the request address, request operation type, selected replacement path, and aging values ​​of each path.

[0037] Furthermore, script tools can be used to parse standard logs and test logs, and based on the parsing results and preset visualization requirements, visualization files for debugging the hardware algorithm implementation of the target hardware module can be generated. Taking the cache replacement algorithm as the target hardware module as an example, the parsing results can include automatically calculated total hit rate, read / write hit rate, prefetch accuracy, and prefetch coverage. Regarding the visualization files, the visualization requirements differ for debugging different target hardware modules. For example, for prefetch algorithms, a prefetch distance distribution map or a prefetch hit / failure time series map can be plotted; for replacement algorithms, the replacement situation within the same set can be plotted to observe whether the replacement algorithm is effective.

[0038] Figure 2 This is a schematic diagram of a visualization file showing the intra-group replacement situation of a replacement algorithm according to an embodiment of this application. Figure 2 As shown, green indicates a read hit, red indicates a replacement / insertion, and cyan indicates data writing. The table header is shown in Table 1. Table 1 Below is a code example of embedding a data logging probe into hardware code implemented in SystemVerilog to generate logs: int log_file; initial begin log_file = $fopen("cache_behavior_trace.csv", "w"); $fdisplay(log_file, "Timestamp,Address,Set,IsHit,ReplacedWay,PrefetchAddr"); / / Write the CSV header end always @(posedge clk) begin if (cache_access_valid) begin / / Use $sformatf to construct the formatted string to avoid confusion with the $fwrite parameter. string log_entry = $sformatf("%0t,%h,%d,%b,%d", $time, access_addr, current_set_index, is_hit, way_to_replace); $fdisplay(log_file, log_entry); end end. Therefore, the embodiments of this application can solve the problem of unintuitive hardware debugging information. By making the "black box" behavior inside the hardware transparent through visualization, developers can quickly grasp the macro performance of the algorithm (such as hit rate and prefetch accuracy) and perform micro behavior pattern analysis based on the generated visualization file. This greatly accelerates the performance bottleneck analysis and debugging process and reduces the debugging difficulty.

[0039] In one embodiment of this application, a system for hardware-software co-simulation is also provided, comprising an interface function setting module, a hardware code modification module, and a compilation and simulation module. The interface function setting module can be configured to set at least one interface function corresponding to the target hardware functional module based on the behavior of the target hardware functional module. Each interface function implements a behavior of the target hardware functional module through a software algorithm. The hardware code modification module can be configured to replace operations on the target hardware module with calls to at least one interface function in the register-transfer level hardware circuit code where the target hardware module resides, thereby obtaining modified register-transfer level hardware circuit code. The compilation and simulation module can be configured to compile the modified register-transfer level hardware circuit code and the corresponding software code of each of the at least one interface function into a unified format to generate a first simulation program.

[0040] Figure 3 The execution flow of the system is illustrated. The register-transfer level hardware circuit code containing the target hardware module includes calls to the interface functions corresponding to the target hardware module. For example, at least one interface function can be called using the DPI-C standard calling interface in SystemVerilog, thereby replacing the operation on the target hardware module. The software algorithm implementation of each interface function is written in C / C++. The software algorithm implementation of the target hardware functional module includes the software code corresponding to each interface function. This software code has been verified at the software level and can simulate every behavior of the target hardware functional module.

[0041] like Figure 3 As shown, the system inputs a file containing the modified register-transfer level hardware circuit code and a file containing the corresponding software code for each of at least one interface function into a DPI-C-enabled simulation tool (e.g., Verilator). The DPI-C-enabled simulation tool then compiles the input files to generate a first simulation program. In some embodiments, the input files may also include a file containing test stimulus code. This test stimulus code serves as an external driver for hardware operation, specifying how the values ​​of the hardware's clock signal, reset signal, and various input ports change.

[0042] In another embodiment, the system may further include a hardware debugging module. This hardware debugging module can be configured to: execute a generated first simulation program based on a standard test set, and record behaviors and performance metrics related to the target hardware functional module to obtain a standard log; replace calls to interface functions of the target hardware module with the hardware algorithm implementation of the target hardware module in the modified register-transfer level hardware circuit code, and recompile to obtain a second simulation program; execute the second simulation program based on the standard test set, and record behaviors and performance metrics related to the target hardware functional module to obtain a test log; and conveniently locate logical errors in the hardware algorithm implementation of the target hardware module by comparing the standard log and the test log.

[0043] As can be seen, the methods and systems described above according to the embodiments of this application can directly and without modification apply the algorithm code verified on the software simulator to the simulation evaluation of hardware RTL. This eliminates the risk of errors introduced by manual translation from software algorithm to hardware RTL from the source, greatly shortens the performance evaluation cycle at the hardware level, reduces the time and manpower costs caused by rework due to errors, thereby shortening the development cycle, significantly reducing the cost of hardware R&D, and making rapid iterative verification of algorithms possible.

[0044] References to "various embodiments," "some embodiments," "one embodiment," or "embodiment" in this specification refer to a particular feature, structure, or property described in connection with an embodiment that is included in at least one embodiment. Therefore, the appearance of the phrases "in various embodiments," "in some embodiments," "in one embodiment," or "in an embodiment" throughout the specification does not necessarily refer to the same embodiment. Furthermore, a particular feature, structure, or property can be combined in any suitable manner in one or more embodiments. Thus, a particular feature, structure, or property shown or described in connection with one embodiment can be combined, in whole or in part, with features, structures, or properties of one or more other embodiments without limitation, provided that such combination is not illogical or inoperable.

[0045] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments or implementation methods. Similar or identical parts between the various embodiments of this application can be referred to mutually. The implementation principles and technical effects of the inventive concept can be mutually referenced, and will not be repeated here. Where there is no conflict, the various embodiments or implementation methods in this application can be combined with each other.

[0046] It should be noted that although the steps are described in a specific order above, it does not mean that the steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently, or even in a different order, as long as the required function can be achieved.

[0047] This application can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this application. A computer-readable storage medium may be a tangible device that holds and stores instructions used by an instruction execution device. Computer-readable storage media may include, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof.

[0048] The embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used in the embodiments of this application is chosen to best explain the principles, practical applications, or technological improvements in the market, or to enable other those skilled in the art to understand the embodiments disclosed in this application.< / int> < / map> < / list> < / vector>

Claims

1. A method for hardware-software co-simulation, wherein, include: Based on the behavior of the target hardware functional module, at least one interface function corresponding to the target hardware functional module is set, and each interface function implements a behavior of the target hardware functional module through a software algorithm. In the register-transfer level hardware circuit code where the target hardware module is located, the operation on the target hardware module is replaced with a call to at least one interface function, thereby obtaining the modified register-transfer level hardware circuit code. The modified register transfer level hardware circuit code and the corresponding software code of each of the at least one interface function are compiled together to generate the first simulation program.

2. The method according to claim 1, further comprising: The generated first simulation program is executed based on a standard test set, and the behavior and performance metrics related to the target hardware functional modules are recorded to obtain a standard log. In the modified register transfer level hardware circuit code, the calls to the interface functions of the target hardware module are replaced with the hardware algorithm implementation of the target hardware module, and then compiled again to obtain the second simulation program. The second simulation program is executed based on the standard test set, and the behavior and performance indicators related to the target hardware functional modules are recorded to obtain the test log. Logical errors in the hardware algorithm implementation of the target hardware module are located by comparing the standard log and the log to be tested.

3. The method according to claim 2 further includes the standard log and the log to be tested being implemented by embedding data recording probes in the software algorithm implementation and hardware algorithm implementation of the target hardware functional module to record context information related to the operation of the target hardware functional module.

4. The method according to claim 3, wherein the software algorithm implementation of the target hardware functional module includes software code corresponding to each interface function, the software code having been verified at the software level and capable of simulating each behavior of the target hardware functional module.

5. The method according to claim 3, further comprising: The standard log and the log to be tested are parsed using script tools, and a visualization file for debugging the hardware algorithm implementation of the target hardware module is generated based on the parsing results and preset visualization requirements.

6. The method according to claim 5, wherein the script tool uses Python to call the database toolbox and / or the drawing toolbox to generate visualization files.

7. The method according to claim 1, wherein: The call to at least one interface function in the register transfer level hardware circuit code where the target hardware module is located is implemented using the DPI-C interface standard in SystemVerilog, and the software algorithm implementation of the interface function is written in C / C++.

8. The method according to claim 7, wherein, The process of compiling the modified register-transfer level hardware circuit code and the corresponding software code in each of the at least one interface function to generate the first simulation program includes: Input the modified register-transfer level hardware circuit code file and the corresponding software code file for each of the at least one interface function into a simulation tool that supports DPI-C. The simulation tool that supports DPI-C compiles the input files uniformly to generate the first simulation program.

9. A system for hardware and software co-simulation, comprising: The module includes an interface function setup module, a hardware code modification module, and a compilation and simulation module; among them, The interface function setting module is configured to set at least one interface function corresponding to the target hardware functional module according to the behavior of the target hardware functional module, and each interface function implements a behavior of the target hardware functional module through a software algorithm. The hardware code modification module is configured to replace the operation on the target hardware module with a call to at least one interface function in the register transfer level hardware circuit code where the target hardware module is located, thereby obtaining the modified register transfer level hardware circuit code. The compilation simulation module is configured to compile the modified register transfer level hardware circuit code and the corresponding software code of each of the at least one interface function into a unified compilation to generate a first simulation program.

10. The system according to claim 9, further comprising a hardware debugging module configured to: The generated first simulation program is executed based on a standard test set, and the behavior and performance metrics related to the target hardware functional modules are recorded to obtain a standard log. In the modified register transfer level hardware circuit code, the calls to the interface functions of the target hardware module are replaced with the hardware algorithm implementation of the target hardware module, and then compiled again to obtain the second simulation program. The second simulation program is executed based on the standard test set, and the behavior and performance indicators related to the target hardware functional modules are recorded to obtain the test log. Logical errors in the hardware algorithm implementation of the target hardware module are located by comparing the standard log and the log to be tested.

Images