CN118605909A - A hardware development system based on RISC-V - Google Patents

Abstract

The present invention provides a RISC-V-based hardware development system, including an instruction tracking module, a waveform slicing module, a deadlock detection module, an emulated memory tracking module, a function call tracking module, a peripheral access tracking module, an instruction simulator, a differential debugging comparison module, a comprehensive debugging module and a calling module; wherein the waveform cycle recorded by the waveform slicing module each time can be configured by itself, greatly reducing the space occupied by the generated waveform file; the differential debugging comparison module can adapt to the execution cycle of each instruction of the processor, that is, a single-cycle processor or a processor using multi-stage pipeline technology can use this module. By using the RISC-V-based hardware development system of the present invention to design a RISC-V processor, the development and debugging efficiency of the processor can be greatly improved.

Description

A hardware development system based on RISC-V

Technical Field

The present invention relates to a hardware development system, and in particular to a hardware development system based on RISC-V.

Background Art

With the continuous development of processor technology, the RISC-V instruction set, as an open and scalable instruction set architecture, has gradually attracted the attention of the industry. In the design of RISC-V processors, how to flexibly and efficiently develop and debug and quickly and accurately locate the erroneous instructions is one of the important directions.

Unlike general ASIC design, processor simulation is the process of executing instructions. When a processor executes a simple test program, there are often tens of thousands or even hundreds of thousands of instructions, and the generated waveform can reach tens to hundreds of GB. Errors in executed instructions often appear after dozens or even hundreds of cycles, which makes it difficult to find the location of the error. At the same time, the processor simulation cannot fully record the executed instructions, and when looking for the erroneous instruction, it may be necessary to observe the waveforms of dozens of signals inside the processor core at the same time. This debugging method is very inefficient.

Summary of the invention

The technical problem to be solved by the present invention is to provide a RISC-V-based hardware development system to improve the efficiency of hardware development.

In order to solve the above technical problems, the technical solution adopted by the present invention is: a RISC-V-based hardware development system, comprising: an instruction tracing module, a waveform slicing module, a deadlock detection module, an emulated memory tracing module, a function call tracing module, a peripheral access tracing module, an instruction simulator, a differential debugging comparison module, a comprehensive debugging module and a calling module;

After the processor is connected to the RISC-V-based hardware development system, the forward cycle is encapsulated as a single_cycle() function, and the calling module calls the waveform slicing module once in the single_cycle() function to perform waveform slicing;

After the processor completes the reset and initialization information, it enters the main loop of the integrated debugging module. The integrated debugging module issues an execution command to call the cpu_exec() function to let the processor execute instructions;

The calling module updates the program counter, and the calling function tracking module determines whether the current address of the program counter is a call or return function;

The calling module calls the single_cycle() function once to indicate that the processor advances one cycle, and then calls the get_cpu_signals() function to obtain the relevant signals in the processor;

The calling module calls the deadlock detection module after the single_cycle() function to check whether the processor enters an infinite loop;

If the processor accesses memory or peripherals during execution, the calling module calls the memory access tracking module and the peripheral access tracking module through the DPIC mechanism to notify the development platform and write the relevant information into the log file;

After an instruction is executed, the calling module calls the instruction tracking module to record the information of the executed instruction;

The calling module calls the differential debugging comparison module to verify whether the processor execution is correct; in the differential debugging comparison module, the instruction simulator is notified to execute an instruction, and then the register stack state of the instruction simulator is obtained and compared with the register stack state of the processor. If the states are the same, the program counter is updated to continue executing the next instruction. If the states are different, the simulation is exited and relevant error information is output.

Furthermore, a commit module is provided in the write-back stage of the processor, which is specifically used to commit only when the instruction of the previous cycle is different from the instruction of the current cycle.

Furthermore, the instruction tracing module is specifically used to write the program counter address and instructions into the logbuf string; call llvm disassembly, input instruction information, and input the disassembled information into logbuf, thereby completing the record of an executed instruction.

Furthermore, the waveform slicing module is specifically used to record the waveforms of the most recent N cycles. If the processor executes correctly during this period, the waveforms of these N cycles are discarded and the waveforms of the next N cycles are recorded again.

Furthermore, the deadlock detection module is specifically used to record the running cycle of the current delivered instruction. If the current instruction execution exceeds a preset cycle, it is determined that the processor has entered a deadlock, and the hardware development system exits the simulation and outputs relevant debugging information.

Furthermore, the memory access tracking module is specifically used to output relevant information to a log file according to the type of memory access instruction, memory access address, and memory access data, and record the PC address during memory access.

Furthermore, the function call tracking module is specifically used to read the corresponding program elf file according to the current instruction, disassemble and output the current function call information to the log file.

Furthermore, the peripheral access tracking module is specifically used to determine whether it is a peripheral access based on the address of the current memory access, and output the address of the peripheral access, the peripheral name, and the access data information.

Furthermore, the differential debugging comparison module is specifically used to determine whether the current instruction is executed correctly according to the register status in the processor and the instruction simulator after each instruction is executed, and return the determination result to the hardware development system.

Furthermore, the comprehensive debugging module is specifically used for single-step debugging of the processor, printing registers, setting monitoring points, calculating expressions, scanning memory and exiting simulation.

The beneficial effects of the present invention are: using a RISC-V-based hardware development system, it is possible to completely record the operation traces of the processor, automatically detect deadlock situations and reduce the size of waveform files, automatically locate the location of instruction errors, and use a variety of debugging methods for flexible development, thereby greatly improving the efficiency of processor design.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the mechanisms shown in these drawings without paying creative work.

FIG1 is an overall architecture diagram of a RISC-V-based hardware development system according to an embodiment of the present invention;

FIG2 is a flowchart of an execution of a RISC-V-based hardware development system according to an embodiment of the present invention;

FIG3 is a diagram showing the overall architecture of an instruction simulator according to an embodiment of the present invention;

FIG4 is a flow chart of initialization information according to an embodiment of the present invention;

FIG5 is a flowchart of an instruction execution of an instruction simulator according to an embodiment of the present invention;

FIG6 is a diagram showing an overall architecture of differential debugging comparison according to an embodiment of the present invention;

FIG7 is a flowchart of differential debugging comparison execution according to an embodiment of the present invention;

FIG8 is a diagram of the architecture of a comprehensive debugging module according to an embodiment of the present invention.

DETAILED DESCRIPTION

The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

It should be noted that the descriptions of "first", "second", etc. in the present invention are only used for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in the field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

As shown in FIG1 , an embodiment of the present invention is: a RISC-V-based hardware development system, comprising: an instruction tracing module, a waveform slicing module, a deadlock detection module, an emulated memory tracing module, a function call tracing module, a peripheral access tracing module, an instruction simulator, a differential debugging comparison module, a comprehensive debugging module and a calling module;

After the processor is connected to the RISC-V-based hardware development system, the forward cycle is encapsulated as a single_cycle() function, and the calling module calls the waveform slicing module once in the single_cycle() function to perform waveform slicing;

After the processor completes the reset and initialization information, it enters the main loop of the integrated debugging module. The integrated debugging module issues an execution command to call the cpu_exec() function to let the processor execute instructions;

The calling module updates the program counter, and the calling function tracking module determines whether the current address of the program counter is a call or return function;

The calling module calls the single_cycle() function once to indicate that the processor advances one cycle, and then calls the get_cpu_signals() function to obtain the relevant signals in the processor;

In order to determine whether an instruction in the processor has been executed, a delivery module needs to be added to the write-back level of the processor. The characteristics of the instructions that can be delivered are shown in Table 1:

Table 1:

In order to prevent the same instruction from being delivered multiple times, the delivery module will store the instructions of the previous cycle, and delivery will only be performed when the instructions of the previous cycle are different from the instructions of the current cycle. Since the multi-cycle pipeline processor cannot determine the execution cycle of each instruction, a loop is used in the exec_once() function. If the delivery enable signal is not detected to be pulled high, the above execution behavior is repeated, so that it can be compatible with pipeline RISC-V processors of any cycle. According to this principle, the calling module of the present invention calls the deadlock detection module after the single_cycle() function to check whether the processor enters a dead loop;

If the processor accesses memory or peripherals during execution, the calling module calls the memory access tracking module and the peripheral access tracking module through the DPIC mechanism to notify the development platform and write the relevant information into the log file;

After an instruction is executed, the calling module calls the instruction tracking module to record the information of the executed instruction;

The calling module calls the differential debugging comparison module to verify whether the processor execution is correct; in the differential debugging comparison module, the instruction simulator is notified to execute an instruction, and then the register stack state of the instruction simulator is obtained and compared with the register stack state of the processor. If the states are the same, the program counter is updated to continue executing the next instruction. If the states are different, the simulation is exited and relevant error information is output.

In this solution, the waveform cycle recorded by the waveform slicing module each time can be configured by itself, which greatly reduces the space occupied by the generated waveform file; the differential debugging comparison module can adapt to the execution cycle of each instruction of the processor, that is, single-cycle or multi-stage pipeline processors can use this module. All of the above modules are parameterized, and macros can be used to freely choose whether to turn them on. By using the RISC-V-based hardware development system of the present invention, the development and debugging efficiency of the processor is greatly improved.

The following is a detailed introduction to each module:

Instruction tracing module: In order to record the address information of the instruction and program counter after each execution of the processor, the present invention defines a logbuf string in the global scope to store the information recorded each time. First, the address and instruction of the program counter are written into the logbuf string, and then llvm is called to disassemble, the instruction information is input, and the disassembled information is input into the logbuf, so that the record of an executed instruction is completed.

In addition, the present invention also defines an instruction buffer for outputting the last N instructions after each execution (error or normal execution), so as to facilitate finding the position of the erroneous instruction. First, a ringbuf structure is defined, which includes instbuf, head and count. instbuf is a string array for storing the recorded instruction stream. head is a head pointer, which is used to indicate the location where the next instruction is stored in instbuf, ensuring that the latest instruction is always stored in instbuf. count is a counter, which is used to indicate whether instbuf has been filled. The size of the instbuf array can be configured, and it is assumed here that the size is 10. First, the inst_enqueue() function is defined to put the instruction into instbuf, and the position where it is put is the value of head. When updating the head pointer, the head is assigned to (head+1)%10 to realize the function of buffer circular writing, and count is incremented by 1. inst_enqueue() is called after the current instruction is executed to ensure that the recorded instructions are executed correctly. Secondly, the print_inst() function is defined to print the instruction information in instbuf from new to old. If instbuf has been filled, the data from head to 10 will be output first, followed by the data from 0 to head-1. If instbuf has not been filled, the data from 0 to head-1 will be output directly. print_inst() is only called when the simulation exits.

Waveform slicing module: Verilator uses the method of advancing simulation time units to drive simulation, and if waveform generation is set, the waveform file needs to be opened at the beginning of the simulation and closed at the end of the simulation. This feature can be used to refresh the waveform file. The present invention defines a waveform refresh counter in the waveform slicing module. When the simulation advances one cycle, the waveform refresh counter increments by 1. When the count reaches N, the operation of refreshing the waveform file is executed, that is, the waveform file is closed and then opened.

Deadlock detection module: When the processor enters a deadlock state, the instruction cannot enter the next level of the pipeline, resulting in the inability to update the instruction delivery of the last level. The deadlock detection module of the present invention defines a deadlock counter, which judges the instructions in the delivery module after each cycle. If the instruction of the current cycle is the same as the instruction of the previous cycle, the deadlock counter will increase by 1, and the deadlock counter will be cleared after each instruction is delivered. When the deadlock counter counts to N (N is generally set to several hundred), it can be determined that the processor has entered a deadlock state, and the hardware development system is notified to exit the simulation and print relevant debugging information.

Memory access tracking module: The memory access operation in the processor can be implemented using the DPI-C mechanism of Verilator, and the operation similar to accessing SRAM is implemented by calling the C function in Verilog to access the defined memory array (pmem). The present invention defines the memory_trace() function in calling the DPI-C function, which accepts the current PC address of memory access, the memory address accessed, the data accessed, the data length of the memory access, and the type of memory access (read/write) as parameters, and writes this information into the log file.

Peripheral access tracking module: The RISC-V manual stipulates that RISC-V peripheral access is implemented by memory mapping, that is, memory access instructions are used when accessing peripherals, and the address of memory access is no longer a memory address but the address of the peripheral on the bus. Similar to the memory access tracking module, the peripheral access tracking module defines the device_trace() function in the function that calls DPI-C for memory access. This function accepts the pc address of the currently accessed peripheral, the address of the accessed peripheral, the accessed data, the length of the accessed data, and the type of access (read/write) as parameters, and determines which peripheral is being accessed based on the accessed peripheral address, and writes this information to the logfile.

Function call tracing module: According to the RISC-V manual, function calls and returns are executed by executing the two instructions jal and jalr. Therefore, the present invention defines the trace_func_call() and trace_func_ret() functions to be called when the two instructions jar and jalr are executed. The trace_func_call() function accepts the program counter and target as parameters, where the program counter is the address where the instruction is located, and the target is the first address of the called function, such as in the following function call, pc = 0x8000000c, target = 0x80000260; 0x8000000c: call[_trm_init@0x80000260]. Sometimes the compiler will optimize the return of the function into a tail call, that is, the pseudo instruction jr (expanded to jalr x0,0(rs1)) is used when calling the function, and the return address is not recorded in x1 (return address for jumps), but in x0 (hardwired to0, ignores writes), which is equivalent to directly discarding the return address. Therefore, in trace_func_call(), it is also necessary to identify the situation where the destination register of the address is x0, and record the current program counter value (representing the function that will not be displayed as returned). When a function returns, check whether there is a "waiting to return" function in the upper layer. If so, call trace_func_ret() to return together. The trace_func_ret() function accepts the program counter as a parameter, where the program counter is the address where the instruction is located, indicating that the function has returned at the instruction address. In order to identify the names of the calling and returning functions, the present invention parses the .symtab of the elf file. First, a structure SymEntry is defined for storing a row in the symbol table (symtab). symbol_tbl is an array of SymEntry type, and each element represents a symbol recorded in the symbol table, that is, a row in .symtab. In the read_symbopl_table() function, the address, information, size and other data of symtbl in the elf file are parsed and copied to symbol_tbl. Then, in the find_symbol_func() function, the function address is converted to the subscript corresponding to symbol_tbl. The function call must jump to the function's first address, while the function return instruction may fall within the range [Value, Value+Size). Therefore, is_call is used to distinguish between calls and returns for more accurate judgment.

Instruction simulator: The instruction simulator of the present invention adopts trace driver, and the instruction set architecture is RV64IM. Through macro switch, it can be compatible with RV32E, RV32I and RV32IM instruction sets. As shown in Figure 3, there are mainly two processes in the instruction simulator: after initialization information, it enters the main loop of instruction execution.

The initialization information is shown in Figure 4. First, the input information is initialized. This function will determine whether to open the batch mode, specify the log file, specify the image file required by the differential debugging comparison module, and specify the elf file required by the function call tracking module according to the compilation parameters given in the Makefile. The srand() function of the stdlib.h library is used to initialize the random number generator. The real-time time of the computer is obtained through the gettimeofday() function and converted as the parameter of srand(). In the initialization of the log file, the log output is specified as stdout (i.e., terminal output) by default, and then the w mode of fopen() is used to open the specified log file. If the specified log file cannot be opened, Assert will be reported and an error will be reported. In the initialization of memory, the memset() function is used to assign pmem (i.e., the defined memory array) to a random number, and the random number seed uses the rand() function of the stdlib.h library. According to the RISC-V manual, the program counter address will be reset to 0x8000_0000. Therefore, the address of accessing pmem is actually pc-0x8000_0000. Different peripheral ports are added according to the supported peripherals in the initialization peripherals. The instruction simulator of the present invention is an RV64IM architecture. According to the RISC-V manual, 32 64-bit wide general registers are required, so a structure cpu is defined, and its structure members are gpr and pc. Wherein cpu.gpr is used to create 32 64-bit wide general registers, and cpu.pc is used to store the program counter address of the next instruction. In the initialization ISA, a program is first copied to pmem to prevent the instruction simulator from running and reporting an error when the program image does not exist. Then the cpu.pc of the current instruction is set to the reset value, that is, 0x8000_0000. According to the RISC-V manual, the 0 register of the general register is always 0, so the cpu.gpr[0] register needs to be assigned to 0. In the initialization test program, first determine whether the img_file pointer is a null pointer. If it is a null pointer, print an error message and return 4096 (this is the size of the default image). Then use fopen's rb mode to open the image file. If it cannot be opened, use Assert to report an error. After opening the image file, use the fseek() function to move the file pointer to the end of the file, and use the ftell() function to get the current position of the file pointer to get the size of the file. Then use the fseek() function again to move the file pointer to the beginning of the file, and call the fread() function to read data from the file into pmem. Finally, return the size of the test program image file. The instruction simulator is used as a reference for the processor, so the initialization of the differential debugging comparison module can be done directly with an empty function. In the initialization of the comprehensive debugging module, the regular expression is initialized first, and the regcomp() function is called to compile the regular expression of the current rule, and then check whether the return value ret of regcomp() is 0. If it is not 0, it means that the compilation failed. Through this cycle, all regular expression rules are compiled and stored in the corresponding regex_t structure. Then initialize the monitoring point. The monitoring point is implemented by a linked list with the head insertion method, so except for the last node pointing to NULL, other nodes point to the next node. In the initialization instruction Buffer, the head and count of the ringbuf structure are assigned to 0.

After initialization is completed, the main loop of instruction execution is entered, and the flow of instruction execution is shown in Figure 5. The present invention defines a structure Decode in the global scope, and its members include pc, snpc, dnpc, isa_inst_val, and logbuf. Among them, Decode.isa_inst_val is used to indicate the instructions under the current instruction set, and Decode.logbuf is used to record the currently executed instruction information in the instruction tracking module. Decode.pc, Decode.snpc and Decode.dnpc are mainly used for instruction execution. Decode.pc is the program counter address of the current instruction; Decode.snpc is the static nextpc, that is, snpc=pc+4 in RV64IM; Decode.dnpc is the dynamic nextpc, and dnpc=snpc by default. When encountering a branch/jump instruction, dnpc will be assigned to the actual jump address. At the same time, a structure CPUState is also maintained in the global scope, and its members include state, halt_pc, and halt_ret. The state is used to determine the current state of the simulator, and can have the following values: RUNNING, STOP, END, ABORT, QUIT. halt_pc is used to indicate the address of the program counter when the simulator exits runtime, and halt_ret is used to indicate the value of the $a0 register when the simulator exits runtime. This register can indicate whether there is any error in the program running when the simulator exits.

The instruction execution process is encapsulated in the cpu_exec() function. This function accepts the parameter n, which indicates how many instructions to execute. Entering the cpu_exec() function, first determine whether n is less than the set MAX_INST_TO_PRINT, in order to prevent printing too much instruction information on the screen. Then determine the state of CPUState. If it is END or ABORT, return directly. In other cases, the state is assigned to RUNNING by default. Below is the execute() function, which also accepts the parameter n, indicating how many instructions to execute. After execution, different results are printed according to the value of state. If it is RUNNING or STOP, then exit directly; if it is EEND or ABORT, then print the address of the instruction program counter when the execution stops, and finally output information such as the program running time and number of instructions. There is a for loop in the execute() function, which is used to implement the operation of executing N instructions. Executing an instruction is defined as the exec_once() function. This function accepts a pointer &s of type Decode and a global variable cpu.pc. In the exec_once() function, first assign s->pc and s->snpc to pc, which is the pc of the current instruction. Then an isa_exec_once() function is defined. This function accepts a pointer &s of type Decode as a parameter, and mainly implements the functions of fetching, decoding, and executing instructions. First, the inst_fetch() instruction fetch function is used to read the instruction corresponding to the program counter address from the memory array and assign it to isa_inst_val, and at the same time update the value of snpc, that is, increment by 4. Then the decodee_exec() function is defined. This function accepts a pointer &s of type Decode as a parameter. In decodee_exec(), first, according to the provisions of the RISC-V manual, the immediate values of types I, U, S, J, and B are decoded, and src1 and src2 are indexed from the general registers according to the addresses of the source registers rs1 and rs2. Then, by default, dnpc is assigned to snpc. An INSTPAT macro is defined below. In the RISC-V instruction format, the instruction can be determined based on opcode, func3, and func7. Therefore, this macro can determine the specific instruction based on the different instruction formats input and execute the corresponding operation of the instruction. For example, for the add instruction, the input parameters are: INSTPAT("0000000 ?????? ?????? 000 ?????? 01100 11",add,R,R(rd)＝src1+src2); when it is recognized as an add instruction, it means that this is an R-type instruction, and the values of rs1 and rs2 are added, and the result is assigned to the rd register. If it is a jump instruction beq, the input parameter is: INSTPAT("???????????? ???????????? ????????? 000 ????????? 11000 11",beq,B,s->dnpc＝(src1＝＝src2)?(s->pc+imm):s->snpc); beq instruction is a B-type instruction. The execution process is to determine whether the values of source registers rs1 and rs2 are equal. If they are equal, the next pc address (i.e. dnpc) is assigned to pc+imm, otherwise the next pc address is still snpc. If it is an ebreak instruction, the CPUTRAP() function will be triggered. This function will assign state to END and determine whether the result of program execution is correct based on the value of the $a0 register. After the instruction is executed, it returns to the exec_once() function and assigns cpu.pc to dnpc, which is the final nextpc. After executing an instruction, the counter recording the instruction will be incremented by 1, and then the trace_and_difftest() function will be called. In this function, the differential debugging and comparison module and the instruction tracking module will be called, and the traces of the executed instructions will be printed on the screen according to the situation. Next, it is determined whether the state is RUNNING. If not, the loop will be jumped out, and the subsequent instructions will not be executed. And according to the state of the state, it is determined whether the current simulator executes the program correctly. Finally, if the current simulator supports peripherals, the status of the peripherals needs to be refreshed once.

Differential debugging and comparison module: The differential debugging and comparison module of the present invention is divided into two parts, namely the REF part in the instruction simulator and the DUT part in the processor, as shown in FIG6 .

In the REF section, the difftest_memcpy() function is defined. This function copies n bytes from dut to ref memory, that is, copies the test program to the memory of the instruction simulator. The diff_get_regs() function gets the register status of ref to dut. This function defines the cpu type structure diff_context, and assigns diff_context->gpr[i] to cpu.gpr[i] through a loop. The diff_set_regs() function sets the register status of ref to dut. Similar to the diff_get_regs() function, it assigns cpu.gpr[i] to diff_context->gpr[i]. difftest_regcpy The difftest_regcpy() function copies the program counter and register status between ref and dut. When direction is `DIFFTEST_TO_DUT`, get the register status of ref and pc to dut, that is, call diff_set_regs() function; when direction is `DIFFTEST_TO_REF`, set the register status of ref and pc to dut, that is, call diff_get_regs() function. The function of difftest_exec() function is to let ref execute N instructions. Because the present invention uses the instruction simulator as the ref for differential debugging comparison, ref executes N instructions by calling cpu_exec(n) function. Finally, initialize the differential debugging comparison function of ref, and call the initialization memory and initialization ISA in the initialization information. Because the memory space is too large, and judging whether the processor behavior is correct essentially only requires observing the general registers in the processor core, the differential debugging comparison module of the present invention only compares the general registers. After completion, compile the instruction simulator into a shared object file for dynamic linking.

In the DUT part, the init_difftest() function is first defined. In this function, the dlopen() function is used to open the incoming dynamic library file ref_so_file, and then the API symbols in the dynamic library (that is, the differential debugging functions defined in the REF part) are symbolically resolved and relocated through dynamic linking, and then their addresses are returned. Next, the differential debugging comparison function of REF is initialized, that is, the difftest_init() function of ref is called; then the memory data, register status and cpu.pc of the DUT are copied to ref, thus completing the initialization of the entire differential debugging comparison.

The differential debugging comparison process of the DUT part is shown in Figure 7. First, the difftest_step() function is defined to be called after exec_once(). In this function, the cpu type pointer ref_r is defined as the intermediate variable for differential debugging comparison between REF and DUT. In the difftest_step() function, it is first determined that if the instruction is skipped, then only the register state of ref is set to dut. Then let ref execute an instruction and get the ref register state to dut, and finally call the checkregs() function to check the general registers in ref and dut. In the checkregs() function, the pc of ref and dut are first compared. If the pc is not equal, it means that the status of ref and dut is inconsistent, and the simulation is directly exited and the current pc address is output. If the pc address is the same, the values of 32 general registers are compared through the for loop. If they are equal, it means that the processor instruction is executed correctly and it returns directly.

Comprehensive debugging module: The comprehensive debugging module is essentially a loop that implements the effect of the command line by calling the readline library, and then parses the command line input parameters to determine what operations need to be performed, as shown in Figure 8.

The single-step execution is to call the cpu_exec(n) function, where n is the number entered in the command line. The instruction execution will directly call cpu_exec(-1). Since the input parameter defined by the cpu_exec() function is of type uint_64t, -1 will be directly converted to the maximum value of uint_64t. Scanning memory means accessing pmem according to the given memory address and returning the data of the corresponding memory address.

To calculate an expression, you first need to add regular expression rules, such as arithmetic addition, subtraction, multiplication and division, logical AND, OR, equality, inequality, left and right brackets, decimal and hexadecimal numbers, 32 general registers and PC, etc. Next, you need to split the expression and find the main symbol (the symbol with the lowest priority). After finding the main symbol, calculate the expression. If the expression only has numbers, then directly return the corresponding value; if the expression is a general register, then return the value of the corresponding general register; if the expression is PC, then return the value of cpu.pc; if the expression has brackets, then remove the outer brackets and then make a recursive call; finally, calculate the main operator and return the calculated value.

Setting monitoring points is implemented using a linked list structure with the head insertion method, and a calculation expression is required to cooperate. Assume that at the beginning of the program, when wpc == 0x8000_0000 is entered at pc = 0x8000_0000, the expression is calculated to be false, and the expression is written to the first node of the linked list. Next, the instruction is executed. When pc = 0x8000_000c is executed, the monitoring point detects that the value of the node changes from false to true, and the state is assigned to STOP to stop the execution of the instruction. In this way, a similar effect to a breakpoint can be achieved. At the same time, if the monitoring point set is a value in memory, the changes in memory data can be monitored, which greatly improves the efficiency of debugging.

To exit the simulation, you can directly assign the state value to QUIT. At the same time, in order to facilitate debugging, the current instruction and pc address will be printed at the same time when exiting.

Print registers Use a for loop to print out the values of the general registers in cpu.gpr one by one.

The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims (10)

1. A RISC-V based hardware development system comprising: the system comprises an instruction tracking module, a waveform slicing module, a deadlock detection module, a copy tracking module, a function call tracking module, a peripheral access tracking module, an instruction simulator, a differential debugging comparison module, a comprehensive debugging module and a call module;

After a processor is accessed to a hardware development system based on RISC-V, a forward cycle is packaged into a single_cycle () function, and a calling module calls a waveform slicing module once in the single_cycle () function to carry out waveform slicing;

after the processor finishes resetting and initializing information, entering a main loop of the comprehensive debugging module, and sending an execution command by the comprehensive debugging module to call a cpu_exec () function to enable the processor to execute instructions;

The calling module updates the program counter, and the calling function tracking module judges whether the address of the current program counter is a calling or returning function;

The calling module calls a single_cycle () function once to indicate that the processor advances for one cycle, and then calls a get_cpu_signals () function to acquire related signals in the processor;

the calling module calls the deadlock detection module after the single_cycle () function to check whether the processor enters the dead cycle;

If the processor has the action of accessing the memory or accessing the peripheral in the execution process, the calling module calls the memory tracking module and the peripheral access tracking module through a dpic mechanism to inform the development platform, and relevant information is written into the log file;

After one instruction is executed, the calling module calls the instruction tracking module to record the executed instruction information;

The calling module calls the differential debugging comparison module to verify whether the processor is executed correctly or not; and informing the instruction simulator to execute an instruction in the differential debugging comparison module, acquiring the register file state of the instruction simulator to compare with the register file state of the processor, updating the program counter again to continue executing the next instruction if the states are the same, and exiting simulation and outputting related error information if the states are different.

2. The RISC-V based hardware development system of claim 1 wherein: the write-back stage of the processor is provided with a delivery module which is specifically used for delivering only when the instruction of the last cycle is different from the instruction of the current cycle.

3. The RISC-V based hardware development system of claim 1 wherein: the instruction tracking module is specifically configured to write the address of the program counter and the instruction into a logbuf character string; and invoking llvm to disassemble, inputting instruction information, and inputting the disassembled information into logbuf to complete the recording of the one-time execution instruction.

4. The RISC-V based hardware development system of claim 1 wherein: the waveform slicing module is specifically configured to record the waveform of the last N periods, discard the waveform of the N periods if the processor executes correctly during the period, and restart recording the waveform of the next N periods.

5. The RISC-V based hardware development system of claim 1 wherein: the deadlock detection module is specifically configured to record an operation cycle of a current delivery instruction, and if the current instruction is executed over a preset cycle, determine that the processor enters a deadlock, and the hardware development system exits simulation and outputs related debug information.

6. The RISC-V based hardware development system of claim 1 wherein: the access tracking module is specifically configured to output related information to the log file according to the type of the access instruction, the access address and the access data, and record the pc address during the access.

7. The RISC-V based hardware development system of claim 1 wherein: the function call tracking module is specifically configured to read a corresponding program if file according to a current instruction, disassemble and output current function call information to a log file.

8. The RISC-V based hardware development system of claim 1 wherein: the peripheral access tracking module is specifically configured to determine whether the peripheral access belongs to the peripheral access according to the address of the current access memory, and output the address of the peripheral access, the name of the peripheral, and the access data information.

9. The RISC-V based hardware development system of claim 1 wherein: the differential debugging comparison module is specifically used for judging whether the current instruction is executed correctly or not according to the states of registers in the instruction execution post-processor and the instruction simulator, and returning the judging result to the hardware development system.

10. The RISC-V based hardware development system of claim 1 wherein: the comprehensive debugging module is specifically used for single step debugging of the processor, printing registers, setting monitoring points, calculating expressions, scanning memory and exiting simulation.