Software and hardware debugging method, system, device and storage medium for generative RISC-V SoC

Abstract

The present application relates to a method, system, device and storage medium for software and hardware debugging of a generative RISC‑V SoC, and relates to the field of RISC‑V SoC. The method includes: using Chisel to construct a RISC‑V SoC generator, the RISC‑V SoC generator includes a parameterized template file; receiving custom parameter change information, changing the template file according to the custom parameter change information to obtain a RISC‑V SoC generated file; compiling the RISC‑V SoC generated file by a compilation tool to generate the Verilog RTL code of the RISC‑V SoC; when receiving a software simulation instruction, using the Verilog RTL code to build a software simulation environment, creating a simulation top-level file according to the software simulation environment and performing software simulation; when receiving an FPGA prototype verification instruction, using the Verilog RTL code to build an FPGA prototype verification environment, creating a top-level file according to the FPGA prototype verification environment and performing FPGA prototype verification. The technical effect of the present application is: using the defined generator framework, users only need to change simple parameters to generate a customized RISC‑V SoC, which improves the flexibility and efficiency of the design.

Description

Technical Field

[0001] The present application relates to the field of RISC-V SoC, and in particular to a method, system, device and storage medium for software and hardware debugging of a generative RISC-V SoC. Background Art

[0002] RISC-V SoC (System on Chip) refers to a system-level chip based on the RISC-V architecture. RISC-V is an open standard instruction set architecture that allows users to freely customize the processor core as needed, thereby creating SoCs that are suitable for various applications. Software debugging is a key link in the software development process, which generally refers to the process of reproducing software defects, locating and finding the root cause of the problem, and ultimately solving the problem. Hardware debugging refers to the process of testing and debugging the hardware system through hardware testing equipment and tools.

[0003] Traditional digital circuit design methods are based on Verilog, System Verilog, and VHDL, which can accurately describe circuit behavior. However, these languages ​​have limited parameterization capabilities and are difficult to handle complex parameterized designs. They focus more on static hardware descriptions, which can cause inconvenience to current hardware designs that generate variable structures. Summary of the invention

[0004] In order to better generate a custom RISC-V SoC and perform software and hardware debugging, the present application provides a software and hardware debugging method, system, device and storage medium for a generative RISC-V SoC.

[0005] In a first aspect, the present application provides a method for software and hardware debugging of a generative RISC-V SoC, which adopts the following technical solution: the method comprises:

[0006] Using Chisel to build a RISC-V SoC generator, the RISC-V SoC generator including a parameterized template file;

[0007] Receiving custom parameter change information, and changing the template file according to the custom parameter change information to obtain a RISC-V SoC generated file;

[0008] Compile the RISC-V SoC generation file by a compilation tool to generate the Verilog RTL code of the RISC-V SoC;

[0009] When receiving a software simulation instruction, using the Verilog RTL code to build a software simulation environment, creating a simulation top-level file according to the software simulation environment and performing software simulation;

[0010] When an instruction for FPGA prototype verification is received, the Verilog RTL code is used to build an FPGA prototype verification environment, a top-level file is created according to the FPGA prototype verification environment, and FPGA prototype verification is performed.

[0011] Through the above technical solution, a RISC-V SoC generator is built through the Chisel language to generate a RISC-V SoC. Chisel has better reuse and modularity characteristics, and has powerful parameterization functions. It can modify parameters to generate a custom RISC-V SoC, which improves the flexibility and efficiency of the design. After software and hardware debugging, a RISC-V SoC that can meet the user's design requirements can be obtained.

[0012] In a specific implementation scheme, creating a simulation top-level file according to the software simulation environment and performing software simulation includes:

[0013] Creating a simulation top-level file according to the software simulation environment;

[0014] Calling a simulation model IP, wherein the simulation model IP includes a simulation IP Verilog definition file;

[0015] Obtain a required file list--filelist file according to the simulation top-level file and the simulation IP Verilog definition file;

[0016] Retrieve a simulation case, configure simulation parameters according to the simulation case, and call the filelist file to generate an executable simulation file;

[0017] The executable simulation file is imported into the software simulation environment, and simulation is performed according to the simulation parameters to obtain simulation results.

[0018] Through the above technical solution, a software simulation environment is automatically generated. The environment provides a simulation model, and users do not need to design the model required for simulation. At the same time, it provides a variety of test cases, and can perform complete ISA instruction set simulation and C program simulation such as kernel benchmarking programs, etc. The entire simulation process is highly automated, and different cases can be called to complete the simulation using simple script commands, thereby improving simulation efficiency.

[0019] In a specific implementation scheme, creating a top-level file according to the FPGA prototype verification environment and performing FPGA prototype verification includes:

[0020] Creating a top-level file according to the FPGA prototyping environment;

[0021] Obtain the IP configuration file of Xilinx IP and the FPGA prototype verification board model for verification;

[0022] Create an FPGA project that conforms to the FPGA prototype verification board model according to the top-level file, the Verilog RTL code, and the IP configuration file;

[0023] Generate an executable file executable by the RISC-V SoC through the compilation tool;

[0024] Compiling the FPGA project using the compilation tool to generate a bitstream file that runs on the FPGA prototype verification platform;

[0025] Download the bitstream file to the corresponding FPGA;

[0026] The executable file is run on the FPGA to obtain a debugging result.

[0027] Through the above technical solution, the FPGA prototype verification environment is automatically generated. The prototype verification project can be created using a fully automatic script using several defined FPGA prototype verification boards. It supports the definition and modification of the project configuration file according to the user's FPGA prototype verification board. After completion, a project suitable for the user's FPGA prototype verification board can be generated with one click.

[0028] In a specific implementation scheme, downloading the bitstream file to the corresponding FPGA includes:

[0029] Get the pin binding information in the FPGA project;

[0030] Generate a constraint file of the FPGA according to the pin binding information, wherein the constraint file describes a mapping relationship between the bitstream file and the FPGA;

[0031] The bit stream file is downloaded to the FPGA according to the mapping relationship.

[0032] Through the above technical solution, the FPGA constraint file is obtained in the FPGA engineering environment, and then compiled to obtain a bitstream file that can run on the specified FPGA, so that the functions and performance of the RISC-V SoC chip can be fully verified in the FPGA prototype environment.

[0033] In a specific implementation scheme, running the executable file on the FPGA to obtain a debugging result includes:

[0034] Using a RISC-V ISA simulator to perform simulation verification on the executable file to verify whether the executable file can run normally;

[0035] If the executable file can run normally, the executable file is run on the FPGA to obtain a debugging result.

[0036] Through the above technical solution, simulation verification of the executable file can not only help the FPGA prototype to verify the normal operation, but also eliminate the problem of the executable file when the FPGA prototype verification fails, and perform targeted inspections on the hardware circuits running inside the FPGA.

[0037] In a specific implementation scheme, compiling the FPGA project by the compilation tool to generate a bitstream file running on the FPGA prototype verification platform includes:

[0038] Determine whether the scale of the RISC-V SoC exceeds the capacity of a single-chip FPGA;

[0039] If the scale of the RISC-V SoC does not exceed the capacity of a single FPGA chip, compiling the FPGA project with the compilation tool to generate a bitstream file that runs on the FPGA prototype verification platform;

[0040] If the scale of the RISC-V SoC exceeds the capacity of a single-chip FPGA, the compilation tool compiles the FPGA project to obtain a netlist file;

[0041] Splitting the netlist file to obtain a number of split netlists, and compiling the split netlists to obtain a number of bitstream files;

[0042] Downloading the bitstream files to corresponding FPGAs using a download tool;

[0043] The bitstream file and the executable file are run on a plurality of the FPGAs to obtain debugging results.

[0044] Through the above technical solution, when the required FPGA resources exceed a single chip, the FPGA resources can be divided into multiple FPGAs for debugging by splitting the netlist file, thereby realizing hardware debugging of complex RISC-V SoC.

[0045] In a specific implementation scheme, after using Chisel to build a RISC-V SoC generator, the method further includes:

[0046] Calling a corresponding accelerator in the RISC-V SoC generator according to the RISC-V instructions and special algorithms of the RISC-V SoC;

[0047] The accelerator is coupled to a RISC-V processor of the RISC-V SoC.

[0048] Through the above technical solution, an accelerator is coupled to the RISC-V processor to form a coprocessor that can accelerate special instructions, thereby improving efficiency and reducing time when generating complex RISC-V SoCs.

[0049] In a second aspect, the present application provides a software and hardware debugging system for a generative RISC-V SoC, which adopts the following technical solution: the system includes:

[0050] A generator construction module for constructing a RISC-V SoC generator using Chisel, wherein the RISC-V SoC generator includes a parameterized template file;

[0051] A custom RISC-V SoC module, used for receiving custom parameter change information, and changing the template file according to the custom parameter change information to obtain a RISC-V SoC generated file;

[0052] A RISC-V SoC generation module, used to compile the RISC-V SoC generation file through a compilation tool to generate a Verilog RTL code of the RISC-V SoC;

[0053] A software simulation module, for building a software simulation environment using the Verilog RTL code when receiving a software simulation instruction, creating a simulation top-level file according to the software simulation environment and performing software simulation;

[0054] The FPGA prototype verification module is used to build an FPGA prototype verification environment using the Verilog RTL code when receiving an instruction for FPGA prototype verification, create a top-level file according to the FPGA prototype verification environment, and perform FPGA prototype verification.

[0055] In a third aspect, the present application provides a computer device, which adopts the following technical solution: it includes a memory and a processor, and the memory stores a computer program that can be loaded by the processor and executes the software and hardware debugging method of the generative RISC-V SoC as described above.

[0056] In a fourth aspect, the present application provides a computer-readable storage medium, which adopts the following technical solution: storing a computer program that can be loaded by a processor and execute the software and hardware debugging method of the above-mentioned generative RISC-V SoC.

[0057] In summary, this application has the following beneficial technical effects:

[0058] (1) This application generates RISC-V SoC by constructing a RISC-V SoC generator through Chisel. Chisel has better reuse and modularity characteristics and powerful parameterization functions. By using the defined generator framework, users only need to change simple parameters to generate customized RISC-V SoCs including multi-core SoCs or heterogeneous SoCs, which improves the flexibility and efficiency of the design. After software and hardware debugging, a RISC-V SoC that meets the user's design requirements can be obtained.

[0059] (2) The present application can automatically generate a software simulation environment, which provides a simulation model, and the user does not need to design the model required for simulation; it provides a variety of test cases, and can perform complete ISA instruction set simulation and C program simulation such as kernel benchmark testing, etc., and the entire simulation process is highly automated. Different cases can be called to complete the simulation using only simple script commands, which is user-friendly.

[0060] (3) This application can automatically generate an FPGA prototype verification environment. You can use several defined FPGA prototype verification boards to create prototype verification projects using fully automatic scripts. It supports defining and modifying project configuration files according to the user's FPGA prototype verification board. Once completed, you can generate a project suitable for the user's FPGA prototype verification board with one click.

[0061] (4) This application provides an accelerator module that users can use to accelerate the processing of special tasks. It also provides a template for accelerator design, accelerator development and testing software. The accelerator can be used as a coprocessor of the RISC-V processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1 It is a flowchart of the software and hardware debugging method of the generative RISC-V SoC in the embodiment of the present application.

[0063] Figure 2 It is a schematic diagram of generating a custom RISC-V SoC in an embodiment of the present application.

[0064] Figure 3 It is a schematic diagram of the circuit structure when the accelerator is used as a coprocessor in an embodiment of the present application.

[0065] Figure 4 It is a structural block diagram of the software and hardware debugging system of the generative RISC-V SoC in the embodiment of the present application.

[0066] Figure numerals: 401, generator building module; 402, custom RISC-V SoC module; 403, RISC-V SoC generation module; 404, software simulation module; 405, FPGA prototype verification module. DETAILED DESCRIPTION

[0067] The following is combined with Figure 1-Figure 4 This application is described in further detail.

[0068] The embodiment of the present application discloses a method for software and hardware debugging of a generative RISC-V SoC, which is used to generate a customized RISC-V SoC and perform software and hardware debugging.

[0069] RISC-V SoC (System on Chip) refers to a system-level chip based on the RISC-V architecture. RISC-V is an open standard instruction set architecture that allows users to freely customize the processor core as needed, thereby creating SoCs that are suitable for various applications. Software debugging is a key link in the software development process, which generally refers to the process of reproducing software defects, locating and finding the root cause of the problem, and ultimately solving the problem. Hardware debugging refers to the process of testing and debugging the hardware system through hardware testing equipment and tools.

[0070] Traditional digital circuit design methods are based on Verilog, System Verilog, and VHDL, which can accurately describe circuit behavior. However, these languages ​​have limited parameterization capabilities and are difficult to handle complex parameterized designs. They focus more on static hardware descriptions, which can cause inconvenience for current hardware designs that generate variable structures and cannot meet the needs of users to generate custom RISC-V SoCs.

[0071] Therefore, the present application proposes a software and hardware debugging method for a generative RISC-V SoC, which is used to generate a custom RISC-V SoC and perform software and hardware debugging.

[0072] like Figure 1 As shown, the method specifically comprises the following steps:

[0073] S10, use Chisel to build a RISC-V SoC generator, which includes parameterized template files.

[0074] Combination Figure 2 Instructions for building a custom RISC-V SoC.

[0075] Specifically, Chisel is a hardware construction language embedded in the Scala language, which can write complex, parameterizable circuit generators, so Chisel is used to build the RISC-V SoC generator, which includes parameterized template files, which are Chisel source codes that describe various types of hardware. The RISC-V SoC generator also includes cores, peripherals, buses, and custom accelerators that can process specific instructions or algorithms.

[0076] The configuration file can be used to specify the kernel type, including simple pipeline kernels, out-of-order superscalar kernels, multi-core heterogeneous kernels, and kernels coupled with custom accelerators. By changing the parameters, single-core, dual-core, quad-core and other multi-core SoCs can be realized.

[0077] S20, receiving custom parameter change information, and changing the template file according to the custom parameter change information to obtain a RISC-V SoC generation file.

[0078] Specifically, the user inputs custom parameter change information according to the desired RISC-V SoC design, and changes the template file according to the custom parameter change information to obtain the RISC-V SoC generation file. The RISC-V SoC generation file here is used to generate source files that can implement the user design, which is an important step in completing the custom RISC-V SoC.

[0079] S30, compile the RISC-V SoC generation file through a compilation tool to generate a Verilog RTL code of the RISC-V SoC.

[0080] Specifically, this application provides various compilation tools to create a complete compilation environment for Chisel, C, C++, MakeFile and other files. The compilation tools contain a complete RISC-V cross-compilation tool chain. The RISC-V SoC generation file is compiled by the compilation tools to obtain a customized RISC-V SoC. The compilation environment can automatically generate Verilog RTL code for the synthesizable RISC-V SoC. The Verilog RTL code is the expression form of the RISC-V SoC.

[0081] S40, when receiving a software simulation instruction, using Verilog RTL code to build a software simulation environment, creating a simulation top-level file according to the software simulation environment and performing software simulation.

[0082] Specifically, after obtaining a customized RISC-V SoC, debugging is required. For simple designs, software simulation can be performed first, followed by FPGA prototype verification. When receiving software simulation instructions, the Verilog RTL code of the RISC-V SoC is used to automatically build a software simulation environment, and a simulation top-level file is created based on the software simulation environment. The software simulation environment and the simulation top-level file are both preparatory work for software simulation. The environment provides a simulation model, and users do not need to design the model required for simulation. The FPGA prototype verification environment provides a variety of test cases, and the entire simulation process is highly automated. Different cases can be called to complete the simulation using simple script commands.

[0083] S50, when receiving the instruction of FPGA prototype verification, using Verilog RTL code to build FPGA prototype verification environment, creating top-level files according to the FPGA prototype verification environment and performing FPGA prototype verification.

[0084] Specifically, all customized RISC-V SoCs will undergo FPGA prototype verification, and debugging will be performed on the FPGA board to verify the performance of the RISC-V SoC. First, the Verilog RTL code is used to automatically build an FPGA prototype verification environment, and a top-level file is created based on the FPGA prototype verification environment. After completing the preparatory work of building the FPGA prototype verification environment and creating the top-level file, FPGA prototype verification is performed.

[0085] This application uses Chisel to build a RISC-V SoC generator to generate RISC-V SoC. Chisel has better reuse and modularity, and has powerful parameterization capabilities. Using the defined generator framework, users only need to change simple parameters to generate customized RISC-V SoCs, including multi-core SoCs or heterogeneous SoCs, which improves the flexibility and efficiency of the design. After software and hardware debugging, a RISC-V SoC that can meet the user's design needs can be obtained.

[0086] In one embodiment, considering that the traditional software simulation process requires manual design of simulation models, setting of simulation parameters, and issuance of simulation instructions, the software simulation efficiency is not high.

[0087] In order to improve the efficiency of software simulation, the steps of creating a simulation top-level file and performing software simulation according to the software simulation environment can be performed as follows:

[0088] First, create a simulation top-level file according to the software simulation environment. Specifically, create a simulation top-level file in the software simulation environment. The simulation top-level file plays a vital role in the simulation process. It usually serves as the entry point of the simulation and is responsible for calling and connecting other modules or subsystems. Then, call the simulation model IP. The simulation model IP includes the simulation IP Verilog definition file. Specifically, the user provides the circuit module simulation IP for the software simulation environment. The simulation IP includes the IP configuration file and the hardware description file of the simulation IP. The IP configuration file includes the configuration information related to the IP core, such as parameter settings, bit width, etc. The hardware description file of the IP includes the circuit behavior description of the hardware model, etc. Next, the required file list -- filelist file is obtained according to the simulation top-level file and the simulation IP Verilog definition file. Specifically, the simulation tool loads all necessary files according to the filelist file list, including the simulation top-level file, IP configuration file, and description files of each circuit module required for simulation, as well as any necessary library files and test vector files. The simulation tool parses the loaded files and compiles them according to the grammatical rules of the hardware description language; after compilation, the simulation tool will connect each module according to the connection information in the simulation top-level file to form a complete simulation system; the simulation tool packages all the compilation and connection results into an executable simulation file. Then, the simulation case is called, and the filelist file is called according to the simulation case configuration simulation parameters to generate an executable simulation file. Specifically, the software simulation environment provides developers with a variety of test cases, including ISA tests, C program codes, kernel running test cases, etc. Different test cases can be called for simulation using simple script commands. Finally, the executable simulation file is imported into the software simulation environment, and simulation is performed according to the simulation parameters to obtain simulation results. Specifically, the obtained simulation results may include waveforms, data tables, reports, etc. This application mainly debugs by analyzing the generated waveforms to verify whether the RISC-V SoC meets the design requirements. This may include comparing the actual output with the expected output, analyzing the RISC-V SoC performance (such as response time, power consumption, etc.), and checking whether there are any abnormal behaviors.

[0089] Automatically generate FPGA prototype verification environment. You can use several defined FPGA prototype verification boards to create prototype verification projects using fully automatic scripts. It supports defining and modifying project configuration files according to the user's FPGA prototype verification board. After completion, you can generate a project suitable for the user's FPGA prototype verification board with one click.

[0090] In one embodiment, in order to better debug the RISC-V SoC and verify whether the RISC-V SoC meets the design requirements, the step of creating a top-level file and performing FPGA prototype verification according to the FPGA prototype verification environment can be specifically performed as follows:

[0091] First, create a top-level file according to the FPGA prototype verification environment. Specifically, create a top-level file in the FPGA prototype verification environment. The top-level file plays a vital role in the simulation process. It is usually used as the entry point of the simulation and is responsible for calling and connecting other modules or subsystems. Then, obtain the IP configuration file of Xilinx IP and the FPGA prototype verification board model used for verification. Specifically, in the FPGA prototype verification environment, MIG IP of Xilinx is used for implementation. When obtaining the IP configuration file of Xilinx IP, it is necessary to adjust it according to the FPGA prototype verification environment to obtain an IP configuration file suitable for running in the FPGA prototype verification environment. At the same time, it is also necessary to obtain the FPGA prototype verification board model used for verification. Next, an FPGA project that conforms to the FPGA prototype verification board model is created based on the top-level file, Verilog RTL code, and IP configuration file. Specifically, the Verilog RTL code, top-level file, and IP configuration file of the RISC-V SoC compiled by the generator create an FPGA project that conforms to the FPGA prototype verification board model. After the FPGA project is created, the script will be used to automatically complete the constraints, synthesis, and layout and routing on the FPGA. The constraint file includes pin binding information. The IP configuration file and constraint file used to create the project will be automatically called during compilation, and users do not need to manually create or change the project.

[0092] Then, the compilation tool is used to generate an executable file that can be executed by the RISC-V SoC. Specifically, during the actual prototype verification on-board debugging, the software system also provides the host computer function of the serial port or other control interfaces, which can realize hardware debugging or data loading, etc. In order to facilitate the user to compile software, the software system has a fully functional RISC-V compilation chain, which can compile C language, assembly language and other programs into executable files that can be executed by the RISC-V SoC. It should be noted that the system image file is a type of executable file. During compilation, a device tree file will be generated according to the hardware definition. When the system image is compiled, the device tree file will be automatically called to generate a system image file that can support the prototype verification environment to start the operating system.

[0093] Next, compile the FPGA project through the compilation tool to generate a bitstream file that runs on the FPGA prototype verification platform. Specifically, when compiling the FPGA project through the compilation tool, the FPGA chip model can be specified during compilation. The files used to create the FPGA project will be automatically called during compilation, and the bitstream file that runs on the FPGA prototype verification platform will be generated with one click. Next, download the bitstream file to the corresponding FPGA. Specifically, the files used to create the project will be automatically called during compilation, and the user does not need to manually create or change the project. After the compilation is completed, the user can download the automatically generated bitstream file to the corresponding model of the FPGA prototype verification board for on-board verification. Finally, run the executable file on the FPGA to obtain the debugging results. Specifically, once the bitstream file is successfully loaded onto the FPGA, the executable file pre-written into the memory starts running. The peripherals on the FPGA verification board, such as the serial port, can be used to capture and analyze the output information of the FPGA design, so as to analyze whether the functions and performance of the RISC-V SoC meet the design expectations and achieve the debugging effect.

[0094] This application can automatically generate an FPGA prototype verification environment. You can use several defined FPGA prototype verification boards to create prototype verification projects using fully automatic scripts. It supports defining and modifying project configuration files according to the user's FPGA prototype verification board. After completion, you can generate a project suitable for the user's FPGA prototype verification board with one click.

[0095] In one embodiment, in order to accurately map the bitstream file to the FPGA and improve the accuracy of the debugging result, downloading the bitstream file to the corresponding FPGA can be specifically performed as follows:

[0096] First, obtain the pin binding information in the FPGA project. Specifically, the FPGA automatic compilation environment will perform pin binding according to the IO configuration of the top-level file. When the top-level file is used to generate the FPGA project, the pin binding information can be obtained from the FPGA project. Then, generate the FPGA constraint file based on the pin binding information. The constraint file includes the mapping relationship between the bitstream file and the FPGA. Specifically, the pin binding information contains the I / O constraints of the FPGA. Generating the FPGA constraint file based on the pin binding information explains the mapping relationship between the bitstream file and the FPGA. Finally, download the bitstream file to the FPGA according to the mapping relationship to accurately simulate the performance of the RISC-V SoC chip.

[0097] In one embodiment, in order to better perform FPGA prototype verification, the step of running the executable file on the FPGA to obtain the debugging result can be specifically performed as follows:

[0098] Use the RISC-V ISA simulator to simulate and verify the executable file to verify whether it can run normally. Specifically, before running the executable file on the FPGA, verify the executable file in the software environment to verify whether the executable file can run normally. If the executable file can run normally, it means that the executable file functions well and can be executed on the FPGA to obtain debugging results. If the executable file cannot run normally, it is necessary to eliminate the problems such as the software compilation of the executable file before verifying it on the board, otherwise the FPGA prototype verification cannot be carried out smoothly.

[0099] It should be noted that this step can not only help the FPGA prototype to verify the normal operation, but also eliminate the problem of the executable file when the FPGA prototype verification fails, and conduct targeted inspections on the hardware FPGA.

[0100] In one embodiment, considering the situation that the resources exceed the single-chip FPGA, the step of compiling the FPGA project by a compilation tool to generate a bitstream file running on the FPGA prototype verification platform can be specifically performed as follows:

[0101] First, determine whether the scale of the RISC-V SoC exceeds the capacity of a single FPGA chip. Specifically, when the defined kernel is too complex, the required FPGA resources will exceed the capacity of a single FPGA chip. If the scale of the RISC-V SoC does not exceed the capacity of a single FPGA chip, compile the FPGA project through the compilation tool to generate a bitstream file that runs on the FPGA prototype verification platform, as described above.

[0102] If the scale of RISC-V SoC exceeds the capacity of a single FPGA, the compilation tool compiles the FPGA project to obtain a netlist file. Specifically, when the scale of RISC-V SoC exceeds the capacity of a single FPGA, the compilation of the FPGA project will not be able to perform layout and routing, and it will not be able to generate a bitstream file on a single FPGA. The netlist file can be obtained during the synthesis process. Next, the netlist file is split to obtain several split netlists, and several split netlists are compiled to obtain several bitstream files. The several bitstream files are downloaded to several corresponding FPGAs using a download tool. Specifically, the split tool is used to split the super-large design, that is, the netlist file is split into several netlist files, and the bitstream file compiled from each netlist is downloaded to several FPGAs. Finally, the bitstream file and the executable file are run on several FPGAs to obtain the debugging results. Specifically, after the splitting is completed, the bitstream file and the executable file are run on multiple FPGA devices to complete the debugging.

[0103] By splitting the netlist file, FPGA prototype verification can be performed even when the resources exceed the single-chip FPGA, completing the verification of the complex designed RISC-V SoC.

[0104] In one embodiment, Figure 3 , in order to improve the efficiency of RISC-V SoC in executing specific instructions or algorithms, after building the RISC-V SoC generator using Chisel, you can also perform the following steps:

[0105] First, according to the RISC-V instructions and special algorithms of the RISC-V SoC, the corresponding accelerator in the RISC-V SoC generator is called. Specifically, the accelerators in the RISC-V SoC generator currently include machine learning accelerators (used to perform machine learning tasks), vector accelerators (used to perform vectorized operations), special algorithm accelerators (such as processing various encryption function algorithms), etc. Different accelerators can be used according to task requirements, and accelerators can also be customized according to the RISC-V instructions and special algorithms of the RISC-V SoC. Then, the accelerator is coupled to the RISC-V processor of the RISC-V SoC. Specifically, the accelerator that processes special algorithms is coupled to the RISC-V processor of the RISC-V SoC to form a coprocessor that can accelerate special tasks.

[0106] It should be noted that the implementation of the accelerator can be divided into three parts: the interface between the accelerator and the processor, the interface between the accelerator and the memory, and the implementation of the accelerator's operational logic. When the acceleration module is defined and connected to the processor, when the processor executes the RISC-V custom instruction, it sends a request to the accelerator through the command port between the processor and the accelerator. The accelerator will return a ready signal to the processor through the command response interface. The processor and the accelerator will notify the CPU or accelerator whether it is busy through a busy indication signal to avoid task blocking. The processor passes the data in the source register and other information to the accelerator through the command port. The accelerator controls the execution of the data path according to the result of instruction decoding, including: data fetching, calculation, write-back and other operations to achieve task acceleration.

[0107] Several optional accelerator modules are provided, which users can use to accelerate the processing of special tasks. At the same time, templates for accelerators to implement simple algorithms are provided. Users can define the algorithms or tasks that need to be accelerated according to the template files to develop accelerators for use as RISC-V coprocessors.

[0108] Based on the above method, the embodiment of the present application also discloses a software and hardware debugging system for a generative RISC-V SoC, such as Figure 4 The system includes the following modules:

[0109] A generator construction module 401 is used to construct a RISC-V SoC generator using Chisel, where the RISC-V SoC generator includes a parameterized template file;

[0110] A custom RISC-V SoC module 402 is used to receive custom parameter change information, and to modify a template file according to the custom parameter change information to obtain a RISC-V SoC generated file;

[0111] A RISC-V SoC generation module 403 is used to compile a RISC-V SoC generation file through a compilation tool to generate a Verilog RTL code of the RISC-V SoC;

[0112] The software simulation module 404 is used to build a software simulation environment using Verilog RTL code when receiving a software simulation instruction, create a simulation top-level file according to the software simulation environment, and perform software simulation;

[0113] The FPGA prototype verification module 405 is used to build an FPGA prototype verification environment using Verilog RTL code when receiving an instruction for FPGA prototype verification, create a top-level file according to the FPGA prototype verification environment, and perform FPGA prototype verification.

[0114] In one embodiment, the generator construction module 401 is specifically used to call the corresponding accelerator in the RISC-V SoC according to the RISC-V instructions and special algorithms of the RISC-V SoC; and couple the accelerator to the RISC-V processor of the RISC-V SoC.

[0115] In one embodiment, the software simulation module 404 is specifically used to create a simulation top-level file according to the software simulation environment; call the simulation model IP, the simulation model IP includes a simulation IP Verilog definition file; obtain the required file list--filelist file according to the simulation top-level file and the simulation IP Verilog definition file; call the simulation case, configure the simulation parameters according to the simulation case, and call the filelist file to generate an executable simulation file; import the executable simulation file into the software simulation environment, and simulate according to the simulation parameters to obtain the simulation results.

[0116] In one embodiment, the FPGA prototype verification module 405 is specifically used to create a top-level file according to the FPGA prototype verification environment; obtain the IP configuration file of the Xilinx IP and the FPGA prototype verification board model used for verification; create an FPGA project that conforms to the FPGA prototype verification board model according to the top-level file, Verilog RTL code and IP configuration file; generate an executable file that can be executed by the RISC-V SoC through a compilation tool; compile the FPGA project through the compilation tool to generate a bitstream file that runs on the FPGA prototype verification platform; download the bitstream file to the corresponding FPGA; and run the executable file on the FPGA to obtain a debugging result.

[0117] In one embodiment, the FPGA prototype verification module 405 is specifically used to obtain pin binding information in the FPGA project; generate a constraint file of the FPGA according to the pin binding information, the constraint file describes the mapping relationship between the bitstream file and the FPGA; and download the bitstream file to the FPGA according to the mapping relationship.

[0118] In one embodiment, the FPGA prototype verification module 405 is specifically used to use a RISC-V ISA simulator to perform simulation verification on the executable file to verify whether the executable file can run normally; if the executable file can run normally, the executable file is run on the FPGA to obtain a debugging result.

[0119] In one embodiment, the FPGA prototype verification module 405 is specifically used to determine whether the scale of the RISC-V SoC exceeds the capacity of a single-chip FPGA;

[0120] If the scale of RISC-V SoC does not exceed the capacity of a single FPGA, the compilation tool is used to compile the FPGA project to generate a bitstream file that runs on the FPGA prototype verification platform; if the scale of RISC-V SoC exceeds the capacity of a single FPGA, the compilation tool is used to compile the FPGA project to obtain a netlist file; the netlist file is split to obtain several split netlists, and several split netlists are compiled to obtain several bitstream files; the several bitstream files are downloaded to several corresponding FPGAs using a download tool; the bitstream files and executable files are run on several FPGAs to obtain debugging results.

[0121] The embodiment of the present application also discloses a computer device.

[0122] Specifically, the computer device includes a memory and a processor, and the memory stores a computer program that can be loaded by the processor and execute the software and hardware debugging method of the above-mentioned generative RISC-V SoC.

[0123] The embodiment of the present application also discloses a computer-readable storage medium.

[0124] Specifically, the computer-readable storage medium stores a computer program that can be loaded by a processor and execute the software and hardware debugging method of the generative RISC-V SoC as described above. The computer-readable storage medium includes, for example: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

Claims

1. A method for software and hardware debugging of a generative RISC-V SoC, characterized in that: The method comprises: Using Chisel to build a RISC-V SoC generator, the RISC-V SoC generator including a parameterized template file; Receiving custom parameter change information, and changing the template file according to the custom parameter change information to obtain a RISC-V SoC generated file; Compile the RISC-V SoC generation file by a compilation tool to generate the Verilog RTL code of the RISC-V SoC; When receiving a software simulation instruction, using the Verilog RTL code to build a software simulation environment, creating a simulation top-level file according to the software simulation environment and performing software simulation; When receiving an instruction for FPGA prototype verification, using the Verilog RTL code to build an FPGA prototype verification environment, creating a top-level file according to the FPGA prototype verification environment and performing FPGA prototype verification; The creating a simulation top-level file according to the software simulation environment and performing software simulation comprises: Creating a simulation top-level file according to the software simulation environment; Calling a simulation model IP, wherein the simulation model IP includes a simulation IP Verilog definition file; Obtain a required file list--filelist file according to the simulation top-level file and the simulation IP Verilog definition file; Retrieve a simulation case, configure simulation parameters according to the simulation case, and call the filelist file to generate an executable simulation file; The executable simulation file is imported into the software simulation environment, and simulation is performed according to the simulation parameters to obtain simulation results.

2. The method according to claim 1, characterized in that: The creating a top-level file according to the FPGA prototype verification environment and performing FPGA prototype verification comprises: Creating a top-level file according to the FPGA prototyping environment; Obtain the IP configuration file of Xilinx IP and the FPGA prototype verification board model for verification; Create an FPGA project that conforms to the FPGA prototype verification board model according to the top-level file, the Verilog RTL code, and the IP configuration file; Generate an executable file executable by the RISC-V SoC through the compilation tool; Compiling the FPGA project using the compilation tool to generate a bitstream file that runs on the FPGA prototype verification platform; Download the bitstream file to the corresponding FPGA; The executable file is run on the FPGA to obtain a debugging result.

3. The method according to claim 2, characterized in that: The downloading of the bitstream file to the corresponding FPGA includes: Get the pin binding information in the FPGA project; Generate a constraint file of the FPGA according to the pin binding information, wherein the constraint file describes a mapping relationship between the bitstream file and the FPGA; The bit stream file is downloaded to the FPGA according to the mapping relationship.

4. The method according to claim 2, characterized in that: The step of running the executable file on the FPGA to obtain a debugging result includes: Using a RISC-V ISA simulator to perform simulation verification on the executable file to verify whether the executable file can run normally; If the executable file can run normally, the executable file is run on the FPGA to obtain a debugging result.

5. The method according to claim 2, characterized in that: The step of compiling the FPGA project by the compilation tool to generate a bitstream file running on the FPGA prototype verification platform includes: Determine whether the scale of the RISC-V SoC exceeds the capacity of a single-chip FPGA; If the scale of the RISC-V SoC does not exceed the capacity of a single FPGA chip, compiling the FPGA project with the compilation tool to generate a bitstream file that runs on the FPGA prototype verification platform; If the scale of the RISC-V SoC exceeds the capacity of a single-chip FPGA, the compilation tool compiles the FPGA project to obtain a netlist file; Splitting the netlist file to obtain a plurality of split netlists, and compiling the plurality of split netlists to obtain a plurality of bitstream files; Downloading the plurality of bitstream files to a plurality of corresponding FPGAs using a download tool; The bitstream file and the executable file are run on a plurality of the FPGAs to obtain debugging results.

6. The method according to claim 1, characterized in that: After building a RISC-V SoC generator using Chisel, it also includes: Calling a corresponding accelerator in the RISC-V SoC generator according to the RISC-V instructions and special algorithms of the RISC-V SoC; The accelerator is coupled to a RISC-V processor of the RISC-V SoC.

7. A software and hardware debugging system for a generative RISC-V SoC, characterized in that: The system comprises: A generator construction module (401) is used to construct a RISC-V SoC generator using Chisel, wherein the RISC-V SoC generator includes a parameterized template file; A custom RISC-V SoC module (402) is used to receive custom parameter change information, and to change the template file according to the custom parameter change information to obtain a RISC-V SoC generation file; A RISC-V SoC generation module (403) is used to compile the RISC-V SoC generation file using a compilation tool to generate a Verilog RTL code of the RISC-V SoC; A software simulation module (404) is used to build a software simulation environment using the Verilog RTL code when receiving a software simulation instruction, create a simulation top-level file according to the software simulation environment, and perform software simulation; The FPGA prototype verification module (405) is used to build an FPGA prototype verification environment using the VerilogRTL code when receiving an instruction for FPGA prototype verification, create a top-level file according to the FPGA prototype verification environment, and perform FPGA prototype verification.

8. A computer device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program which can be loaded by the processor and executes the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: A computer program is stored which can be loaded by a processor and execute the method according to any one of claims 1 to 6.

Images