Method and device for prototype verification

Abstract

The embodiment of the invention provides a prototype verification method and device.The method comprises the steps that a debugging instruction list is generated according to configuration information and at least one test case, the debugging instruction list is executed through a first simulation module based on a spike simulator to conduct prototype verification, a first debugging log is obtained, and a second debugging log is obtained; and executing the debugging instruction list through a second simulation module based on the FPGA to perform prototype verification to obtain a second debugging log, burning a to-be-tested register transfer level RTL file in the second simulation module, and comparing the first debugging log with the second debugging log to obtain a joint simulation report. Through the embodiment of the invention, the problem of low efficiency of a prototype verification method in related technologies can be solved, the program bug existing in RTL design can be quickly detected, the maintenance cost is reduced, and the debug efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of chip testing, and more specifically, to a method and device for prototype verification. Background Art

[0002] Chips generally need to integrate tens of millions or even hundreds of billions of transistors, and their design complexity is getting higher and higher, and a single tape-out generally costs a lot of money. Based on the above reasons, it is necessary to ensure that there are no bugs (faults) in the design logic of the register transfer level (RTL) before tape-out, otherwise it will lead to a second tape-out, which is undoubtedly very costly, so it is very important to perform prototype verification before tape-out.

[0003] The related technology is based on prototype verification, especially debug verification for the open source instruction set architecture (RISC-V). Since the RISC-V architecture itself supports the debug mechanism based on the Joint Test Action Group (JTAG), the RISC-V address space can be accessed through JTAG to implement complex software kernel debugging. A common method is to use the debugging solution that combines the open source on-chip debugger (Open On-Chip Debugger, OpenOCD) and the GNU debugger (GNUdebugger, GDB). Although this method can greatly improve the efficiency of development and debugging, it is impossible to quickly discover and eliminate bugs in the RTL design, the verification efficiency is low, and it is necessary to always pay attention to whether the executed commands are correct, and the maintenance cost is high.

[0004] In summary, there is no good solution to the problem of low efficiency of prototype verification methods in related technologies. Summary of the invention

[0005] The embodiments of the present application provide a prototype verification method and device to at least solve the problem of low efficiency of the prototype verification method in the related art.

[0006] According to one embodiment of the present application, a method for prototype verification is provided, the method comprising: generating a debug instruction list according to configuration information and at least one test case; executing the debug instruction list through a first simulation module based on a spike simulator to perform prototype verification, and obtaining a first debug log; executing the debug instruction list through a second simulation module based on an FPGA to perform prototype verification, and obtaining a second debug log, wherein a register transfer level RTL file to be tested is burned into the second simulation module; and comparing the first debug log and the second debug log to obtain a joint simulation report.

[0007] According to another embodiment of the present application, a prototype verification device is provided, the device comprising:

[0008] A generation module, used for generating a debugging instruction list according to the configuration information and at least one test case;

[0009] A first simulation module, comprising a spike simulator, for executing the debugging instruction list to perform prototype verification and obtain a first debugging log;

[0010] A second simulation module, comprising an FPGA, is used to execute the debugging instruction list to perform prototype verification and obtain a second debugging log, wherein the register transfer level RTL file to be tested is burned into the second simulation module;

[0011] A comparison module is used to compare the first debugging log and the second debugging log to obtain a joint simulation report.

[0012] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program executes the steps of any of the above method embodiments when executed by a processor.

[0013] According to another embodiment of the present application, an electronic device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0014] Through the embodiment of the present application, a prototype verification method for joint comparison of spike and FPGA is provided. The verification result of spike is used as a reference standard, and the same test case is injected into FPGA for secondary verification. By comparing the two verification results, bugs in RTL design can be quickly detected, thereby solving the problem of low efficiency of prototype verification methods in related technologies and achieving the technical effect of reducing maintenance costs and improving debug efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a hardware structure block diagram of the prototype verification method of the embodiment of the present application;

[0016] Figure 2 is a flowchart of a prototype verification method according to an embodiment of the present application;

[0017] Figure 3 It is a structural block diagram of a debugging solution based on OpenOCD and GDB in the related art;

[0018] Figure 4 It is a structural block diagram of a debugging scheme for joint comparison of SPIKE and FPGA in one embodiment of the present application;

[0019] Figure 5 is a schematic diagram of the operation of the cosim prototype verification system according to an embodiment of the present application;

[0020] Figure 6 is a schematic diagram of the operation of the spike simulation module according to an embodiment of the present application;

[0021] Figure 7 Schematic diagram of the operation of the FPGA simulation module according to the embodiment of the present application

[0022] Figure 8 It is a block diagram of a prototype verification device according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0025] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 is a hardware structure block diagram of the prototype verification method of the embodiment of the present application, such as Figure 1 As shown, the hardware board may include one or more ( Figure 1 Only one is shown in the figure) a processor 12 (the processor 12 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device) and a memory 14 for storing data, wherein the mobile terminal may also include a transmission device 16 for communication functions and an input and output device 18. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the mobile terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0026] The memory 14 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the prototype verification method in the embodiment of the present application. The processor 12 executes various functional applications and prototype verification methods by running the computer programs stored in the memory 14, that is, implementing the above method. The memory 14 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 14 may further include a memory remotely arranged relative to the processor 12, and these remote memories may be connected to the mobile terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0027] The transmission device 16 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider. In one example, the transmission device 16 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 16 can be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet wirelessly.

[0028] In one embodiment of the present application, a prototype verification method is provided. Figure 2 is a flowchart of a prototype verification method according to an embodiment of the present application, such as Figure 2 As shown, the process includes the following steps:

[0029] Step S202, generating a debugging instruction list according to the configuration information and at least one test case;

[0030] Step S204, executing the debugging instruction list to perform prototype verification through a first simulation module based on the spike simulator to obtain a first debugging log;

[0031] Step S206, executing the debugging instruction list to perform prototype verification through a second simulation module based on FPGA to obtain a second debugging log, wherein the register transfer level RTL file to be tested is burned into the second simulation module;

[0032] Step S208: Compare the first debugging log and the second debugging log to obtain a joint simulation report.

[0033] The embodiment of the present application designs a combined simulation (Combined Simulation, abbreviated as cosim) method based on spike and FPGA. Through the methods in the above steps S202 to S208, the fast execution speed of FPGA can be used to quickly detect bugs in RTL design. At the same time, the spike verification results are used as a reference standard to locate bugs through comparison, thereby improving debug efficiency and solving the problem of low efficiency of prototype verification methods in related technologies.

[0034] In the embodiments of this application, the following professional terms in the chip field are involved:

[0035] RISC-V is an open source instruction set architecture for designing and implementing processor chips. It is simple, scalable and customizable, and can adapt to various application fields and needs.

[0036] Register-Transfer Level (RTL) is an abstract level for describing logic circuits in digital circuit design. The RTL level describes how data is transferred and processed between registers, including registers, data paths, and control logic.

[0037] GNU Debugger (GDB) is a powerful source-level debugging tool. It can be used to debug programs in various programming languages, including C, C++, Ada, etc. GDB can check the value of variables, observe the execution process of the program, and perform breakpoint debugging, single-step execution, etc. while the program is running.

[0038] Open On-Chip Debugger (OpenOCD) provides debugging, system programming and boundary scan functions for embedded devices. It supports multiple processor architectures and chips, can be connected to the chip through a debugging interface (such as JTAG), and provides many debugging functions, such as reading and writing registers, monitoring variables, downloading programs, etc. The functions of OpenOCD need to be completed with the assistance of an emulator, because the debugging host (the host running OpenOCD) usually does not have the direct analysis function of electrical signals, which needs to be provided by the emulator.

[0039] spike, a RISC-V instruction set emulator, can simulate the hardware thread or processor core (Hardware Thread, referred to as hart) in the RISC-V architecture and support RISC-V instruction set debugging and performance analysis functions.

[0040] Field-Programmable Gate Array (FPGA) is an integrated circuit chip that has programmable logic gates and programmable wiring. In the chip field, FPGA is often used for prototype design and verification.

[0041] In some embodiments, step S202 may include the following steps:

[0042] Step S2022, obtaining an executable file of at least one test case from one or more test case libraries;

[0043] Step S2024, disassembling the executable file to generate a program flow tracking log of the at least one test case;

[0044] Step S2026: Determine the debugging instruction list according to the configuration information and the program flow tracking log.

[0045] In this embodiment, testing may be performed on one or more test cases each time, and each test case may generate multiple debugging instructions.

[0046] In some embodiments, the configuration information in step S202 may include a debugging instruction list generation method. Specifically, the debugging instruction list generation method includes a manual method and an automatic method.

[0047] In some embodiments, the configuration information in step S202 also includes a test case script or an instruction restriction condition. Further, step S2026 can be divided into the following two cases:

[0048] When the debugging instruction list generation mode is the manual mode, editing the test case script according to the program flow tracking log to obtain the debugging instruction list;

[0049] When the debugging instruction list generation mode is the automatic mode, the program flow tracking log is screened according to the instruction restriction condition to obtain the debugging instruction list.

[0050] In an exemplary embodiment, the instruction restriction condition may include but is not limited to any of the following parameters:

[0051] Whether to limit the number of instructions is_limit, the limit number limit_instruction_num, the instruction set of interest list_riscv_instructions, start filtering instructions start_instruction_flag, whether to delete the instructions of repeated PC is_del_repeat_pc, etc.

[0052] The configuration information in the embodiments of the present application can be set according to the test scenario requirements, and different test scenarios can be implemented by editing relevant attribute parameters.

[0053] In an exemplary embodiment, the test case library (case repo) of the joint comparison simulation can also be specified in the configuration information by setting a parameter of specifying the execution file dir_elfs.

[0054] In some embodiments, the first simulation module in step S204 may include: a GNU debugger GDB, an open source on-chip debugger OpenOCD, and the spike simulator.

[0055] In some embodiments, step S204 may include the following steps:

[0056] Step S2042, parsing the debugging instruction list, and starting the GDB, the OpenOCD and the spike emulator;

[0057] Step S2044, executing each debugging instruction in the debugging instruction list in sequence through the spike simulator, the OpenOCD, and the GDB to obtain a first debugging result of the debugging instruction;

[0058] Step S2046: Store the first debugging result of the multiple debugging instructions corresponding to each of the test cases in the corresponding test case path to obtain the first debugging log.

[0059] In some embodiments, step S204 may also include: if the first simulation module successfully executes the debugging instruction list, obtaining the first debugging log and entering the prototype verification process of the second simulation module; if the first simulation module fails to execute the debugging instruction list, ending this prototype verification.

[0060] In the embodiment of the present application, the spike simulator is a standard instruction simulator. The simulation result of the first simulation module is the reference standard for the second simulation module. If the simulation of the first simulation module fails, there may be a problem with the test case itself. At this time, the cosim program can be exited directly.

[0061] In some embodiments, the second simulation module in step S206 includes: GDB, OpenOCD and the FPGA.

[0062] In some embodiments, step S206 may include the following steps:

[0063] Step S2062, parsing the debugging instruction list, and starting the GDB, the OpenOCD and the FPGA;

[0064] Step S2064, executing each debugging instruction in the debugging instruction list in sequence through the FPGA, the OpenOCD, and the GDB to obtain a second debugging result of the debugging instruction;

[0065] Step S2066: store the second debugging result of the multiple debugging instructions corresponding to each of the test cases in the corresponding test case path to obtain the second debugging log.

[0066] In some embodiments, step S206 may also include: if the second simulation module executes the debugging instruction list successfully, obtaining the second debugging log and entering the debugging log comparison process; if the second simulation module fails to execute the debugging instruction list, ending this prototype verification.

[0067] In the embodiment of the present application, if the simulation of the first simulation module succeeds and the simulation of the second simulation module fails, there is no problem with the test case, and there may be a problem with the execution logic of the FPGA.

[0068] In some embodiments, step S208 may include the following steps:

[0069] Step S2082, comparing the debugging results of each test case in the first simulation module and the second simulation module according to the first debugging log and the second debugging log to see whether they are consistent;

[0070] Step S2084: generating the joint simulation report according to the comparison result of the at least one test case.

[0071] In the related technology, since the RISC-V structure supports the debug mechanism based on the Joint Test Action Group (JTAG), for the debug verification of the RISC-V architecture, the RISC-V address space can be accessed through JTAG to implement complex software kernel debugging. Specifically, it can be implemented through OpenOCD and GDB.

[0072] Figure 3 It is a structural diagram of the debugging solution based on OpenOCD and GDB in the related technology, such as Figure 3 As shown, the debugging scheme includes the following structure:

[0073] GDB(31), OpenOCD(32), Adapter(33), DTM(34), DMI(35) and DM(36).

[0074] The GDB debugging tool uses the Transmission Control Protocol (TCP) to connect to OpenOCD.

[0075] OpenOCD is a software used to debug embedded chips. It needs to be used with a debug adapter (such as JLink, ST-Link, DAP-Link) and GDB (or Telnet). It is responsible for converting GDB's high-level commands into JTAG commands, packaging them according to the requirements of a specific downloader, and then calling the system's USB driver to send them out via USB.

[0076] The adapter is responsible for protocol conversion, converting and outputting the USB JTAG control information according to the JTAG protocol to meet the electrical characteristics defined by the protocol. For example, in a Linux test environment, a Jlink adapter can be used to drive JTAG.

[0077] The debug transport module (DTM), also known as the hardware bottom receiving module, is used to receive and process JTAG signals.

[0078] The debug module (DM) can control the processor core, read registers, access memory internally, and connect to the JTAG controller externally.

[0079] The Debug Module Interface (DMI) is the interface of the DM module. One side is connected to the DTM, for example, to receive host signals. The other side is connected to the DM to drive the bus interface of the DM module. The bus interface that drives the DM module is determined by the system itself and can be ABH, AXI4, TileLink or other simple interfaces.

[0080] In this embodiment, if only OpenOCD and GDB are combined, although the development and debugging efficiency can be greatly improved, it is impossible to quickly discover problems in the RTL design and debug, and the debugging solution needs to pay attention to whether the executed commands are correct at all times, and the maintenance cost is high. Therefore, this application proposes a debugging solution of spike and FPGA joint comparison to improve the efficiency of verification.

[0081] Figure 4 : is a structural block diagram of a debugging scheme for joint comparison of SPIKE and FPGA in an embodiment of the present application, such as Figure 4 As shown, the debugging scheme includes the following structure:

[0082] GDB process (41), OpenOCD process (42), SPIKE process (43), FPGA (44).

[0083] In this embodiment, the test environment includes GDB+OpenOCD+SPIKE and GDB+OpenOCD+FPGA. SPIKE is an instruction simulator that can run RISC-V instructions, and the synthesized RTL design code is burned into the FPGA.

[0084] In this embodiment, the processes of GDB (41), OpenOCD (42), and SPIKE (43) are all run inside a test host (Debug PC), and the FPGA (44) is a hardware device outside the test host.

[0085] In some embodiments, the test environment of the debugging solution is Linux.

[0086] In some embodiments, ELF (Executable and Linkable Format) is a disassembled file of a test case.

[0087] In some embodiments, on the GDB+OpenOCD+SPIKE side, Listening9801TCP is used between the GDB and OpenOCD processes, and bitbang 9800 is used for communication between OpenOCD and spike, but the present application is not limited thereto.

[0088] In some embodiments, on the GDB+OpenOCD+FPGA side, Listening3333TCP is used for communication between GDB and OpenOCD processes, and USB Jlink is used between OpenOCD and Spike to drive JTAG to achieve communication with FPGA, but the present application is not limited to this.

[0089] In some embodiments, the FPGA executive program may be started and injected with the synthesized RTL file before the cosim program is started.

[0090] Furthermore, the FPGA does not need to be restarted repeatedly. After all debugging instructions are executed in each test case, the processes of other software except the FPGA are closed and then restarted.

[0091] In this embodiment, the ELF file of each test case needs to be injected into the spike and FPGA in turn through GDB in the execution order of spike first and FPGA later, and all commands in the debugging instruction list (GDB_cmd_list) are executed to generate the corresponding debugging log (GDB_output_python_log). Finally, the debugging logs of the two outputs are compared and a joint simulation report (cosim report) is generated.

[0092] The joint comparison simulation scheme in the embodiment of the present application can be started and run automatically with one click, and can also be started and tested manually.

[0093] The embodiment of the present application can utilize the fast execution speed of FPGA to quickly detect bugs in RTL design. At the same time, using the spike verification results as a reference standard, the bug is located through comparison, the debugging efficiency is improved, and the problem of low efficiency of prototype verification methods in related technologies is solved.

[0094] In one embodiment of the present application, a prototype verification system is also provided, which is used to execute the steps in any of the above method embodiments.

[0095] Figure 5 is a schematic diagram of the operation of the cosim prototype verification system according to an embodiment of the present application, such as Figure 5 As shown, the cosim prototype verification method may include the following steps:

[0096] Step S501, one-key automatic operation of simulation and joint comparison;

[0097] Step S502, generating required instruction list information;

[0098] Step S503, spike simulation runs and outputs a log;

[0099] Step S504, FPGA simulation runs and outputs a log;

[0100] Step S505, reading the log;

[0101] Step S506, comparing logs and generating a joint simulation report;

[0102] Step S507, exit the joint simulation.

[0103] The cosim prototype verification system in the embodiment of the present application can be started with one click, and will not end until the debugging instruction list (gdb_cmd_list) of all test cases (cases) is run, and a joint simulation report (cosimreport) is automatically generated.

[0104] In some embodiments, if an exception is encountered during the execution process, the cosim simulation process can be exited in advance. In this case, the cosim simulation fails and no joint simulation report is generated.

[0105] In some embodiments, according to the requirements of the test scenarios, relevant properties in the debug configuration file (debug cfg file) can be edited to implement different test scenarios.

[0106] Specifically, the debugging configuration file can contain any of the following attribute parameters:

[0107] dir_elfs (specify executable file) can specify the test case library to be executed in this joint simulation. The specific content can be determined according to the test needs. The specified test case library can be one or more. There is no need to manually edit dir_elfs. After the cosim program starts executing, the executable files of the relevant test cases will be automatically written into the file.

[0108] generate auto debug cmd list constraint info (generate automatic debugging instruction list constraint information), that is, the instruction constraint conditions in the above embodiment, only restrict the debugging instruction list generated in an automatic manner. The default is not to make any restrictions. Subsequent tests can be restricted as needed.

[0109] Furthermore, the instruction restriction condition may also include any of the following attribute parameters:

[0110] start_instruction_flag (start filtering flag) is the instruction to start filtering. The default value is null and the configuration value is an instruction, such as jar.

[0111] is_del_repeat_pc (whether to delete instructions with duplicate PC), that is, whether to remove instructions with duplicate PC. The default value is 0. When this parameter is set to 1, only the first matching instruction found will be retained, and all subsequent ones will be deleted, that is, they will not be filtered into the debugging instruction list.

[0112] is_limit (whether to limit the number of instructions) and limit_instruction_num (limit number) indicate whether to limit the number of instructions. The default value is 0. When the is_limit parameter is 1, the limit number is the set limit_instruction_num parameter.

[0113] list_riscv_instructions (the set of instructions of interest), when automatically generating a debug instruction list, traverse the program flow trace log according to this parameter and automatically filter the corresponding instructions. The value of this parameter can be flexibly configured according to the test needs. For example, the default value of this parameter is:

[0114] list_riscv_instructions:[jar,jal,amo,wfi,ebreak,mret,fence,fence.i,csrrw,csr rs,csrrwi,csrrsi,csrrci,csrrai]

[0115] debug_cmd_generate_type (debug command list generation method) can determine the way the debug command list (gdb_cmd_list) is generated. The values ​​are auto_generate_debug_cmd (automatically generate debug commands) and manual_generate_debug_cmd (manually generate debug commands).

[0116] In some embodiments, the automatic mode means that after cosim starts executing, the program automatically disassembles the elf (executable file) of the test case (case), generates a corresponding trace file (trace log), that is, a program flow tracking log, and filters instructions from the trace log according to list_riscv_instructions and some other restrictions to generate a debugging instruction list.

[0117] In some embodiments, the manual method can directly edit the debug testcase script in the debug configuration file according to trace_log to generate a debug instruction list.

[0118] In some embodiments, the debug instructions (debug gdb cmd) are finally placed in the corresponding test case path. Each time cosim is re-executed, the debug gdb cmd in the default directory will be cleared and the debug instruction list needs to be regenerated.

[0119] In some embodiments, if the last debug gdb cmd needs to be executed, the option update_last can be added after the cosim execution program to load the historical debugging instructions.

[0120] In some embodiments, debug gdb cmd will eventually be merged into the debug instruction list (debug_gdb_cmd_list), which includes all commands to be executed in this cosim, specifically debug_gdb_cmd_list, load executable file (load elf), automatic startup of related software programs, etc.

[0121] In some embodiments, if the spike simulation program (spike sim run) executes abnormally, cosim will exit. If the spike simulation is successful, cosim enters the FPGA simulation program (fpga sim run), and if the FPGA simulation is successful, it enters the log automatic comparison.

[0122] Furthermore, the debug log generated by the spike simulation is used as a reference standard for the joint comparison. Generally, the simulation will succeed. If the spike simulation fails, there may be a problem in the designed test case. If the FPGA simulation fails, there may be a problem with the FPGA execution logic.

[0123] In some embodiments, cosim will compare the debug logs in each test case in turn and generate a cosim report. If there is a test case comparison failure, the cosim simulation fails, and the cause of the simulation failure needs to be further analyzed based on the simulation log.

[0124] In the embodiment of the present application, a prototype verification method of joint comparison of spike and FPGA is adopted. After the cosim program is started, no human intervention is required, which can reduce maintenance costs and improve debug efficiency.

[0125] Furthermore, the embodiments of the present application also have the following beneficial effects: bugs in RTL design can be quickly detected; the entire cosim is completed automatically without human intervention in the process, and after the cosim is completed, the tester can directly know the comparison results through the report. It also provides a rich log for fast debugging; it provides a rich configuration selection, and users can configure the case repo and instruction set to be tested according to their needs.

[0126] Figure 6 is a schematic diagram of the operation of the spike simulation module according to an embodiment of the present application, such as Figure 6 As shown, the process includes the following steps:

[0127] S601, parsing the test case and generating a debugging instruction list;

[0128] S602, parsing the instruction list and starting related tools;

[0129] S603, automatically executing the debugging instruction;

[0130] S604, output log.

[0131] In some embodiments, since spike simulation needs to be performed first, the generation of spike_debug_gdb_cmd_list can also be completed in the spike simulation module, but the present application is not limited to this.

[0132] In some embodiments, the spike simulation run (spike sim run) executes the pre-generated commands in the debugging instruction list line by line and outputs a log corresponding to each test case.

[0133] In some embodiments, the logs output by the spike simulation may include but are not limited to: spike debug log (spike_gdb_run_log), DMI log (dmi_log), etc.

[0134] Figure 7 is a schematic diagram of the operation of the FPGA simulation module according to an embodiment of the present application, such as Figure 7 As shown, the process includes the following steps:

[0135] S701, parsing the instruction list and starting related tools;

[0136] S702, automatically executing debugging instructions;

[0137] S703, output log.

[0138] In some embodiments, the FPGA simulation run (FPGA sim run) executes the pre-generated commands in the debugging instruction list line by line and outputs a log corresponding to each test case.

[0139] In some embodiments, the log output by the FPGA simulation may include but is not limited to: FPGA debug log (fpga_gdb_run_log), DMI log (dmi_log), etc.

[0140] According to another aspect of the embodiments of the present application, a prototype verification device is also provided.

[0141] Figure 8 is a block diagram of a prototype verification device according to an embodiment of the present application, such as Figure 8 As shown, the device comprises:

[0142] A generating module 82, configured to generate a debugging instruction list according to the configuration information and at least one test case;

[0143] A first simulation module 84, comprising a spike simulator, for executing the debugging instruction list to perform prototype verification and obtain a first debugging log;

[0144] A second simulation module 86, comprising an FPGA, is used to execute the debugging instruction list to perform prototype verification and obtain a second debugging log, wherein the register transfer level RTL file to be tested is burned into the second simulation module;

[0145] The comparison module 88 is used to compare the first debugging log and the second debugging log to obtain a joint simulation report.

[0146] Through the embodiments of the present application, the fast execution speed of FPGA can be utilized to quickly detect bugs in the RTL design. At the same time, the spike verification results are used as a reference standard to locate the bugs through comparison, thereby improving the debugging efficiency and solving the problem of low efficiency of the prototype verification method in the related technology.

[0147] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program executes the steps of any of the above method embodiments when executed by a processor.

[0148] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0149] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0150] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0151] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0152] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0153] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A prototype verification method, characterized in that: The method comprises: generating a debugging instruction list according to the configuration information and at least one test case; Executing the debugging instruction list to perform prototype verification by a first simulation module based on the spike simulator to obtain a first debugging log; Executing the debugging instruction list through a second simulation module based on FPGA to perform prototype verification, and obtaining a second debugging log, wherein the second simulation module is burned with a register transfer level RTL file to be tested; The first debugging log and the second debugging log are compared to obtain a joint simulation report.

2. The method according to claim 1, characterized in that: Generate a debugging instruction list according to the configuration information and at least one test case, including: Obtaining an executable file of at least one test case from one or more test case repositories; Disassembling the executable file to generate a program flow tracking log of the at least one test case; The debugging instruction list is determined according to the configuration information and the program flow tracing log.

3. The method according to claim 2, characterized in that The configuration information includes a debugging instruction list generation mode, wherein the debugging instruction list generation mode includes a manual mode and an automatic mode.

4. The method according to claim 3, characterized in that The configuration information also includes a test case script or an instruction restriction condition, and determining the debugging instruction list according to the configuration information and the program flow tracking log includes: When the debugging instruction list generation mode is the manual mode, editing the test case script according to the program flow tracking log to obtain the debugging instruction list; When the debugging instruction list generation mode is the automatic mode, the program flow tracking log is screened according to the instruction restriction condition to obtain the debugging instruction list.

5. The method according to claim 1, characterized in that: The first simulation module includes: a GNU debugger GDB, an open source on-chip debugger OpenOCD and the spike simulator.

6. The method according to claim 5, characterized in that The first debugging log is obtained by executing the debugging instruction list to perform prototype verification based on the first simulation module of the spike simulator, including: Parsing the debugging instruction list, and starting the GDB, the OpenOCD and the spike emulator; Execute each debugging instruction in the debugging instruction list in sequence through the spike emulator, the OpenOCD and the GDB to obtain a first debugging result of the debugging instruction; The first debugging result of the plurality of debugging instructions corresponding to each of the test cases is stored in the corresponding test case path to obtain the first debugging log.

7. The method according to claim 1, characterized in that The second simulation module includes: GDB, OpenOCD and the FPGA.

8. The method according to claim 7, characterized in that The debug instruction list is executed by a second simulation module based on FPGA to perform prototype verification, and a second debug log is obtained, including: Parsing the debugging instruction list, and starting the GDB, the OpenOCD, and the FPGA; Execute each debugging instruction in the debugging instruction list in sequence through the FPGA, the OpenOCD, and the GDB to obtain a second debugging result of the debugging instruction; The second debugging result of the plurality of debugging instructions corresponding to each of the test cases is stored in the corresponding test case path to obtain the second debugging log.

9. The method according to claim 1, characterized in that: The method further comprises: executing the debugging instruction list by a first simulation module based on a spike simulator to perform prototype verification, and obtaining a first debugging log, and further comprising: obtaining the first debugging log and entering a prototype verification process of the second simulation module when the first simulation module executes the debugging instruction list successfully; and ending the prototype verification when the first simulation module fails to execute the debugging instruction list. Prototype verification is performed by executing the debugging instruction list through a second FPGA-based simulation module to obtain a second debugging log, which also includes: when the second simulation module successfully executes the debugging instruction list, the second debugging log is obtained and a debugging log comparison process is entered; when the second simulation module fails to execute the debugging instruction list, the prototype verification is terminated.

10. The method according to claim 1, characterized in that Comparing the first debugging log and the second debugging log to obtain a joint simulation report includes: According to the first debugging log and the second debugging log, respectively comparing whether the debugging results of each of the test cases in the first simulation module and the second simulation module are consistent; The joint simulation report is generated according to the comparison result of the at least one test case.

11. A prototype verification device, characterized in that: The device comprises: A generation module, used for generating a debugging instruction list according to the configuration information and at least one test case; A first simulation module, comprising a spike simulator, for executing the debugging instruction list to perform prototype verification and obtain a first debugging log; A second simulation module, comprising an FPGA, is used to execute the debugging instruction list to perform prototype verification and obtain a second debugging log, wherein the register transfer level RTL file to be tested is burned into the second simulation module; A comparison module is used to compare the first debugging log and the second debugging log to obtain a joint simulation report.

12. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program executes the method described in any one of claims 1 to 10 when executed by a processor.

13. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 10.

Images