CN117407301A

CN117407301A - Program debugging method, verification method, system, computer equipment and storage medium of FPGA soft core

Info

Publication number: CN117407301A
Application number: CN202311380739.5A
Authority: CN
Inventors: 董艳博; 杨合民; 梁帅奇; 简优宗; 胡静; 田安民; 杨海英; 祝瑞军; 张青杰
Original assignee: State Grid Hubei Electric Power Co Ltd; Nari Technology Co Ltd; State Grid Electric Power Research Institute
Current assignee: State Grid Hubei Electric Power Co Ltd; Nari Technology Co Ltd; State Grid Electric Power Research Institute
Priority date: 2023-10-23
Filing date: 2023-10-23
Publication date: 2024-01-16

Abstract

The invention discloses a program debugging method, a verification method, a system, computer equipment and a storage medium of an FPGA soft core, comprising the following steps: converting the program to be debugged of the FPGA soft core into an array program [ ] of a C language, and compiling the array program [ ] and a debugging operation instruction into a debugging program; running a debugging program on a simulation system of the FPGA soft core to obtain an execution result; obtaining a debugging result by checking the execution result; the simulation system of the FPGA soft core is based on the MCU design.

Description

Program debugging method, verification method, system, computer equipment and storage medium of FPGA soft core

Technical Field

The invention belongs to the technical field of industrial control and embedded type, and particularly relates to a program debugging method, a program verifying system, computer equipment and a storage medium for an FPGA soft core.

Background

Because of the characteristics of parallel processing, programmable processing and the like, the FPGA chip is more widely applied in the fields of communication, control, data processing and the like, and is more used for solving specific problems compared with a general-purpose processor, the FPGA chip has incomparable advantages of the general-purpose processor in terms of solving large-scale logic, time sequence control, data exchange and the like by means of a hardware programming language, but compared with the general-purpose processor, the FPGA chip has complex program design, poor flexibility and low cost performance when processing tasks such as character string processing, memory access, protocol analysis and the like which are general. In order to improve the universality of the FPGA chip and save the system cost, a soft core or hard core processor can be integrated in the FPGA to assist in executing the universal tasks. The method of the invention is illustrated by taking the debug of PicoBlaze soft cores as an example, but the application scope of the method is not limited to the soft core processor. PicoBlaze is a small 8-bit processor soft core developed by Xilinx corporation, and is optimized according to the logic resource structure of the FPGA device of Xilinx, so that the occupied resources are very small.

1 to hundreds of soft cores such as PicoBlaze can be integrated in one FPGA chip, and in the system design of the FPGA chip, the soft cores can be used in many cases, and an assembler is written to complete specific tasks, so that the difficulty of overall design can be reduced, and the flexibility and maintainability are good; however, the greatest difficulty in using the soft core is debugging of an assembler, because the space of the program is small, the soft core only provides one assembler, the designed assembler is assembled by the assembler to generate a program file, the program file can be integrated with the design of the FPGA to finally generate a configuration file of the FPGA, and when the FPGA starts to operate, the soft core starts to operate at the same time, the debugging function of general processing is not supported, and because the space of the program is very small and the assembler is designed, the debugging of serial port output information is impossible; more seriously, because the high-level languages such as the C language are not supported, the assembler needs to process the field preservation and the field recovery of the function, the program is crashed if careless, and under the slightly complex application scene, the method becomes the most time-consuming link when debugging the program, and the current common debugging methods are as follows:

(1) Hardware language simulation: the soft core itself is designed by the hardware design language, so it is also fully emulated, but there are many inconveniences to use hardware language emulation to verify the design of the soft core program: firstly, signal observation is inconvenient, simulation results of hardware languages are presented in a waveform form, key information needs to be searched and monitored from the simulation results, in addition, due to some characteristics of hardware design, some signals cannot be directly checked, for example, variables are written into a RAM, but RAM data cannot be directly checked in simulation, and a RAM port operation needs to be monitored, or a unit simulating the RAM is added, but a great number of signals are added, so that the simulation efficiency is greatly reduced. Moreover, if the soft-core processor is used to access the external memory device, the stimulus is required to simulate the characteristics of command response, data processing, data delay and the like of the memory device, and the stimulus is very complex and tedious, so that the problem is solved; finally, the speed is slow, the result and the actual deviation are the biggest purpose of the simulation of the hardware language is to locate logic errors, time sequence errors and the like, which often only need to simulate for a short period of time to achieve the purpose, but if the design function of the soft-core program is to be verified, the soft-core program may need to run continuously for a long time, for example, the serial communication speed is slow, one data packet transmission may wait for tens of milliseconds, and the waiting time of the memory device during erasing is more likely to reach the second level, which is not acceptable for the simulation.

(2) The real-time waveform data is captured, the internal data oscilloscope function is often used in the FPGA to be matched with the development environment to view signals and data in the FPGA, and the data and waveforms can be viewed in real time in the manner, but the method has a plurality of defects: firstly, the data capture length is limited, the FPGA uses internal RAM resources to store the captured data, which are relatively valuable, and in addition, the FPGA typically captures one data per clock, in design, the clock frequency is generally high, so that only tens of us of data can be captured at a time, which is far from sufficient for verifying soft-core programming; furthermore, the debugging efficiency is low, the real-time hardware language simulation mode is similar, although the operation speed is real-time, the signals which can be observed at the same time are very limited, if the signals which need to be observed are added and deleted, the FPGA program needs to be recombined and then downloaded for operation, and the comprehensive time of the FPGA program can be from a few minutes to a few hours according to the design scale, so the debugging efficiency is very low.

(3) The upper computer IDE simulation, picoBlaze soft core has a special IDE, is used for designing and simulating the program, the simulation environment uses a plurality of visual means, can greatly improve the efficiency of program debugging, but it is only software simulation after all, or has some short boards, including: only an upper computer is used for software simulation, and the upper computer cannot be connected with actual hardware, so that a plurality of actual functional designs cannot be verified; and the simulation result still needs to be manually analyzed and judged, so that the efficiency is low.

Disclosure of Invention

The invention aims to: in order to solve the problems existing in the debugging and verifying of the soft core processor program at present, the invention provides a program debugging method, a verifying method, a system, computer equipment and a storage medium of an FPGA soft core.

The technical scheme is as follows: the invention discloses a program debugging method of an FPGA soft core, which comprises the following steps:

converting the program to be debugged of the FPGA soft core into an array program [ ] of a C language, and compiling the array program [ ] and a debugging operation instruction into a debugging program;

running a debugging program on a simulation system of the FPGA soft core to obtain an execution result;

obtaining a debugging result by checking the execution result;

the simulation system of the FPGA soft core is based on MCU design.

Further, the debugging operation instruction is a breakpoint debugging operation instruction.

Further, the converting the program to be debugged of the FPGA soft core into an array program [ ] of the C language, compiling the array program [ ] and the debugging operation instruction into a debugging program, includes: converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, and compiling the array program [ ] and a storage position ADDR of an instruction to be inserted with a breakpoint into the breakpoint debugging program.

Further, the converting the program to be debugged of the FPGA soft core into an array program [ ] of the C language, compiling the array program [ ] and a storage location ADDR of an instruction to be inserted into a breakpoint debugging program, including:

step1: taking out instruction from array program, judging if the subscript PC of current instruction is equal to ADDR, if so, executing a null operation, making a break point for the null operation, executing Step2; if not, executing Step2;

step2: and decoding the instruction, calling a corresponding instruction function according to the instruction type, and executing the instruction to obtain an execution result.

Further, the debug operation instruction is a print information operation instruction.

Further, the converting the program to be debugged of the FPGA soft core into an array program [ ] of the C language, compiling the array program [ ] and the debugging operation instruction into a debugging program, includes: converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, and compiling the array program [ ] and a storage position ADDR of an instruction to be inserted with printing information into an information printing debugging program.

Further, the converting the program to be debugged of the FPGA soft core into an array program [ ] of the C language, compiling the array program [ ] and a storage location ADDR of an instruction to be inserted with printing information into an information printing debugging program, specifically includes:

S1: taking out the instruction from the array program, judging whether the subscript PC of the current instruction is equal to ADDR, if so, printing the target information, and executing S2; if not, executing S2;

s2: decoding the instruction, calling a corresponding instruction function according to the instruction type, and executing the instruction to obtain an execution result;

the method comprises the steps that target information is stored in an FPGA soft core simulation system, and the position of the target information stored in the FPGA soft core simulation system corresponds to the position of the target information stored in the FPGA soft core.

Further, the target information is message information from an upper computer.

Further, the target information is parameter information when the target function is called.

The invention discloses a program debugging system of an FPGA soft core, which comprises:

the breakpoint debugging program assembly module is used for converting a program to be debugged of the FPGA soft core into an array program [ ] of a C language and compiling the array program [ ] and a debugging operation instruction into a debugging program;

and the simulation system based on the FPGA soft core designed by the MCU is used for running the debugging program to obtain an execution result, and the debugging result is obtained by checking the execution result.

The invention discloses a program verification method of an FPGA soft core, which comprises the following steps:

converting the program to be debugged of FPGA soft core into the array program of C language]Array program]Sum algorithm subfunction mcu _{Function of} Compiling into an algorithm verification program; the algorithm subfunction mcu _{Function of} An algorithm sub-function FPGA for realizing a specific algorithm exists with a program to be debugged in the FPGA soft core _{Function of} Is a sub-function with the same function;

running an algorithm verification program on a simulation system of the FPGA soft core to obtain a verification result, wherein the verification result is an algorithm sub-function FPGA _{Function of} Whether the operation is correct on the FPGA soft core;

the simulation system of the FPGA soft core is based on MCU design.

Further, the compiling the array program [ ] and the algorithm sub-function mcu function into an algorithm verification program specifically includes:

in algorithm sub-function fpga _{Function of} At the entrance, a algorithm subfunction mcu is run _{Function of} Obtaining an algorithm subfunction mcu _{Function of} Is a running result mcu_res of (1);

return to Algorithm subfunction fpga _{Function of} Running the algorithm sub-function fpga _{Function of} Obtaining an algorithm sub-function fpga _{Function of} The running result of fpga_res;

obtaining a verification result by comparing the operation result mcu_res with the operation result fpga_res; if the two functions are the same, the verification result is an algorithm sub-function fpga _{Function of} The method operates correctly on the FPGA soft core, if the two functions are different, the verification result is an algorithm sub-function FPGA _{Function of} The operation is incorrect on the FPGA soft core.

The invention discloses a program verification module of an FPGA soft core, which comprises the following components:

algorithm verification program assembly module for converting the program to be debugged of FPGA soft core into C language array program ]Array program]Sum algorithm subfunction mcu _{Function of} Compiling into an algorithm verification program; the algorithm subfunction mcu _{Function of} An algorithm sub-function FPGA for realizing a specific algorithm exists with a program to be debugged in the FPGA soft core _{Function of} Is the same sub-function;

the simulation system of the FPGA soft core based on the MCU design is used for running an algorithm verification program to obtain a verification result, wherein the verification result is an algorithm sub-function FPGA _{Function of} Whether or not the operation is correct on the FPGA soft core.

Further, the array program]Sum algorithm subfunction mcu _{Function of} Compiling into an algorithm verification program, which concretely comprises the following steps:

The invention discloses equipment, which comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the processor realizes the steps of a simulation method of an FPGA soft core or realizes the steps of a program verification method of the FPGA soft core when executing the computer program.

The invention discloses a storage medium which stores a program that when executed by at least one processor implements steps of a simulation method of an FPGA soft core or implements steps of a program verification method of an FPGA soft core.

The beneficial effects are that: compared with the prior art, the invention has the following advantages:

(1) The program debugging method of the FPGA soft core solves the problem that the FPGA soft core cannot insert program breakpoints;

(2) According to the program debugging method of the FPGA soft core, by inserting the printing information, when the assembler runs, some data and information in the running process can be printed out, errors and alarms in the running process of the assembler can be obtained, and the errors are analyzed and positioned according to the printing information; the problem that information is unlikely to be printed due to the fact that the FPGA soft core is limited in resources and the assembler is complex in design is solved;

(3) By the program verification method of the FPGA soft core, the data processing results in the program of the FPGA soft core can be immediately verified, and in a plurality of data processing links, the data processing link in which an error occurs can be accurately known, so that the problem that the data processing results cannot be verified when the FPGA soft core executes some data processing is solved;

(4) The invention is convenient for debugging and verifying the assembler running on the FPGA soft core by simulating the FPGA soft core.

Drawings

FIG. 1 is a schematic diagram of an FPGA and a verification hardware environment, wherein the left diagram in FIG. 1 is the FPGA and peripheral circuits, and the right diagram in FIG. 1 is the verification hardware environment schematic diagram;

FIG. 2 is a schematic diagram of an FPGA soft core;

FIG. 3 is a flowchart of the execution of a simulator in an MCU chip;

FIG. 4 is a flowchart of an execution of inserting debug breakpoints;

FIG. 5 is a flowchart of the execution of inserting print information;

FIG. 6 is a flow chart of a program verification method;

FIG. 7 is a flowchart showing a program verification method;

FIG. 8 is a schematic diagram of a board including an FPGA;

fig. 9 is a schematic diagram of a board including an MCU chip.

Detailed Description

In order to facilitate understanding of the technical scheme of the invention, the FPGA soft core related to the invention is described.

The left diagram in fig. 1 shows an FPGA and peripheral circuitry, where the FPGA is in turn divided into 2 parts: the FPGA soft core and the FPGA internal logic are connected with the FPGA internal logic and the peripheral circuit design.

As shown in fig. 2, the FPGA soft core is composed of an instruction fetch and decode unit (IDU), an Arithmetic Logic Unit (ALU), a general purpose register (GR), a program memory (ROM), a data storage area (RAM), and a data PORT (PORT), wherein the program memory (ROM) stores assembled instruction data, the instruction fetch and decode unit (IDU) reads the instructions (instruction fetch) and decodes the instructions (decode), the data is loaded from the data storage area (RAM) or the external PORT to the general purpose register (GR) according to the instructions, the Arithmetic Logic Unit (ALU) performs arithmetic or logic operation on the data in the general purpose register (GR), and writes the result back to the general purpose register (GR), the function of the FPGA soft core to the outside is realized by the external PORT, and the FPGA soft core can control the external register through the read/write PORT, thereby realizing control of the peripheral circuit.

The program of the FPGA soft core polls a register or interrupt signal given by the internal logic of the FPGA to execute a designed program flow, and the specific program flow may relate to aspects of data processing, memory access of peripheral circuits, communication and the like, the designed program flow is executed, and the FPGA soft core returns an execution result to the internal logic of the FPGA.

The FPGA soft core only supports assembly language design, files containing instructions can be obtained after assembly is carried out through an assembler, the files have a plurality of formats and are used for different purposes, for example, v files can be directly added into the design of the FPGA for synthesis, log files are similar to disassembly files and contain programs designed by users, instructions corresponding to each program and the storage position of each instruction in a program memory, dec files contain all 1024 instruction data, and the dec files can be easily converted into an array of C language and are used for software design of the MCU soft core simulation module. The instruction length of the FPGA soft core is 18 bits, and 32bit long integer data is needed to store, so that a total of 4096 bytes of storage space is needed.

The core of the invention is to simulate the FPGA soft core by adopting the MCU chip, the peripheral circuit design of the MCU chip and the peripheral circuit design of the FPGA soft core to be simulated are kept consistent as far as possible, and the verified assembler on the MCU chip is ensured to have no problem when running on the actual FPGA soft core. Since the MCU chip itself has rich resources and debugging means, it is much more convenient and quick to verify the assembler on the MCU chip.

The technical scheme of the invention is further described with reference to the accompanying drawings and the embodiments.

Example 1:

the embodiment discloses a simulation method of an FPGA soft core, which is mainly used for simulating the FPGA soft core by adopting an MCU chip, and specifically comprises the following steps:

step 1: building a verification hardware environment, wherein the verification hardware environment comprises an MCU chip, a peripheral circuit and FPGA internal logic; referring specifically to the right diagram in fig. 1, the MCU chip connects the peripheral circuits and the FPGA internal logic. The peripheral circuit shown in the right diagram in fig. 1 is the same as the peripheral circuit shown in the left diagram in fig. 1. For the FPGA internal logic connected with the FPGA soft core, the FPGA internal logic can be directly realized by using an actual FPGA in the simulation verification design, and can also be realized by an FPGA logic simulator realized by MCU software.

Step 2: designing a simulator in an MCU chip, wherein the simulator simulates an FPGA soft core, in the simulator, a program memory of the FPGA soft core is realized by an array, and each element in the array is an assembled instruction and is identical to an instruction running on the FPGA soft core; the data storage area and the general register of the FPGA soft core can be realized by the simulation of the data storage area of the MCU chip; the execution flow of the simulator is shown in fig. 3, the instructions in the array are read, the instructions are decoded according to the format of the FPGA soft core instructions, the functions of data access, logic operation, program jump and the like in the instructions are executed, and in the process of executing the instructions, the data storage area and the general register are read and written.

When simulating the external port function of the FPGA soft core, the simulator binds with the peripheral function of the MCU chip, namely, the IP core of the FPGA soft core is adapted to the corresponding peripheral of the MCU chip; for example, when the FPGA soft core needs to access the external SPI Flash, according to the FPGA design implementation manner, the IO simulation or the SPI module is used to implement the SPI communication protocol, and the port register is used to control the data transmission and reception of the IO or the SPI peripheral, during simulation, the simulator also needs to access the external SPI Flash, if the FPGA soft core uses the IO simulation SPI manner, the simulator can only use the IO simulation SPI manner, if the FPGA soft core uses the hardware SPI module manner, the simulator can use the IO simulation SPI manner, or can use the hardware SPI peripheral, because the program of the FPGA soft core needs to be verified instead of the SPI module design.

Step 3: because the FPGA soft core only supports assembly language design, when in simulation, the assembly program of the FPGA soft core is converted into an array program of C language, each element of the array program represents an instruction of the FPGA soft core, and the subscript of each element represents the storage address of the instruction;

step 4: and decoding and simulating the instruction in the array program to realize the simulation of the FPGA soft core.

Example 2:

step 1: and building a verification hardware environment. As shown in fig. 8, the hardware environment where the FPGA soft core to be simulated in this embodiment is located includes an upper computer, a soft core system of the FPGA, and an SPI FLASH chip, where the upper computer communicates with the soft core system of the FPGA through a serial port protocol (UART), and tells the soft core system of the FPGA to perform operations such as reading, writing, erasing, and the like on the SPI FLASH chip connected to the FPGA through a serial port command. The soft core system of the FPGA comprises an FPGA soft core and 2 IP cores expanded by the FPGA soft core: a UART IP core and an SPI IP core; the UART IP core is used for communicating with the upper computer, and the SPI IP core is used for communicating with the SPI FLASH.

The embodiment mainly performs debugging and verification on an assembler to be operated on an FPGA soft core, and for facilitating understanding, the function of the assembler is simplified into the following steps:

step 1: the upper computer calculates a check code for the serial port command, and sends the command and the check code to a UART IP core of a soft core system of the FPGA;

step 2: the FPGA soft core reads the received upper computer command data packet through the UART IP core, checks the upper computer command data packet, and executes the step 3 when only checking passes;

Step 3: according to the command of the upper computer, the soft core system of the FPGA checks the SPI FLASH through the SPI IP to carry out read-write and erasing operations, packages the operation result and returns the operation result to the upper computer.

Therefore, as shown in fig. 9, the verification hardware environment set up in this embodiment includes an upper computer, an MCU chip and an SPI FLASH chip, and the set up verification hardware environment needs to satisfy the following functions:

function one: the MCU chip is provided with a UART peripheral (UART 1 shown in fig. 9) and is communicated with the upper computer, wherein command interaction is included;

and the function II: the MCU chip is configured with an SPI peripheral, can communicate with the SPI FLASH through the SPI peripheral, or if the MCU chip is not configured with the SPI peripheral, enough general IO is needed, and the MCU chip communicates with the SPI FLASH in an SPI simulation mode;

and the third function: the MCU chip is configured with an additional 1 UART peripheral (UART 2 shown in FIG. 9), and the UART2 is used for printing information in the debugging and verification process;

function IV: the MCU chip itself needs to be capable of simulation debugging;

function five: SPI FLASH can be operated through MCU chip;

function six: the MCU chip can communicate with the upper computer through a UART protocol.

Step 2: designing a simulator on an MCU chip, and simulating an FPGA soft core by the simulator; the specific operation comprises the following steps:

The operation flow of the whole simulator is shown in fig. 3, and corresponds to 2 parts of software design, including: public software and custom software; the public software decodes and simulates the instructions of the soft core system of the FPGA, and is the same for all assembler programs to be verified; the customized software is the simulation of an IP core of a soft core system of the FPGA through port expansion, and is specially designed according to the requirements of different assembler programs on function expansion.

Since the soft core system of the FPGA has several tens of instructions, and simulation of instructions is not an important point of the present invention, simulation of only a few representative instructions thereof will be described in the present embodiment.

LOAD instruction: the LOAD instruction is used to LOAD data from a source register into a destination register or 1 immediate into a destination register, and is executed as follows:

step 1: the instruction starts;

step 2: decoding the instruction to obtain the number of the target register; judging the type of the source data, if the source data is a register, acquiring the number of the source register from the instruction, turning to the step 3, otherwise, acquiring the immediate number from the instruction, turning to the step 4;

Step 3: assigning the value of the source register to the target register, and turning to step 5;

step 4: assigning the immediate value to a target register, and turning to step 5;

step 5: the instruction ends.

SUBCY instruction: the SUBCY instruction is used to subtract the values or immediate of registers 1 and 2 and update the registers and flag bits based on the result of the calculation. The execution steps are as follows:

step 1: the instruction starts;

step 2: decoding the instruction, obtaining the number of a register 1 (the number to be decremented) and obtaining the type of the decrement, if the number is the register (the register 2), obtaining the number of the register 2 from the instruction, turning to the step 3, otherwise obtaining the immediate number from the instruction, turning to the step 4; step 3: subtracting the value of the register 2 from the value of the register 1, and subtracting a carry FLAG (C_FLAG) to obtain a calculation result, and turning to the step 5;

step 4: subtracting the value of the immediate value from the value of the register 1, and subtracting a carry FLAG (C_FLAG) to obtain a calculation result, and turning to the step 5;

step 5: if the calculation result is 0, setting a zero FLAG (Z_FLAG) to 1, otherwise setting the Z_FLAG to 0;

step 6: if the calculated result is negative, setting C_FLAG to 1, otherwise setting C_FLAG to 0;

step 7: assigning the lower 8 bits of the calculation result to the register 1;

Step 8: the instruction ends.

The JUMP instruction may execute conditional JUMP according to C_FLAG or Z_FLAG, or JUMP directly. The execution steps are as follows:

step 1: the instruction starts;

step 2: decoding an instruction, acquiring a jump target address, judging whether the jump is conditional jump or direct jump, if the jump is conditional jump, turning to step 3, and if the jump is direct jump, modifying the value of a PC (program counter) into the jump target address, turning to step 4;

step 3: judging the jump condition (C_FLAG is 0, C_FLAG is not 0, Z_FLAG is not 0), comparing the jump condition with the corresponding FLAG bit, if the jump condition is consistent with the corresponding FLAG bit, modifying the PC value as a jump target address, and turning to the step 4; if not, modifying the PC value to be (PC+1), namely continuously executing the next instruction, and turning to the step 4;

step 4: ending the instruction;

and the CALL instruction is used for calling the subfunction, and can be directly called or can be called under the condition. The execution steps are as follows:

step 1: instruction start

Step 2: decoding an instruction, acquiring a call target address, judging whether the call is a conditional call or a direct call, turning to step 3 if the call is the conditional call, modifying the value of a PC (program counter) into the call target address if the call is the direct call, and turning to step 4;

Step 3: judging the calling conditions (C_FLAG is 0, C_FLAG is not 0, Z_FLAG is not 0), comparing the calling conditions with corresponding FLAG bits, and if the calling conditions are consistent with the corresponding FLAG bits, modifying the PC value as a calling target address, and turning to the step 4; if the two instructions are inconsistent, pushing the current PC into a call stack, and modifying the PC value to be (PC+1), namely, not calling, and continuously executing the next instruction, and turning to the step 4;

step 4: the instruction ends.

The RETURN instruction is used for returning from the subfunction, and may RETURN directly or may RETURN under a condition. The execution steps are as follows:

step 1: the instruction starts;

step 2: decoding an instruction, judging whether the instruction is returned under the condition or directly, if the instruction is returned under the condition, turning to the step 3, if the instruction is returned under the condition, popping a value from a CALL stack, adding 1 to the value, and assigning the value to a PC (program counter), namely, continuing to execute the program from the next instruction of the last CALL instruction, and turning to the step 4;

step 3: judging the return condition (C_FLAG is 0, C_FLAG is not 0, Z_FLAG is not 0), comparing the return condition with the corresponding FLAG bit, if the return condition is consistent with the corresponding FLAG bit, popping a value from the CALL stack, adding 1 to the value, and assigning the value to a PC (program counter), namely, continuing to execute the program from the next instruction of the last CALL instruction, and turning to step 4; if not, modifying the PC value to be (PC+1), namely, not returning, and continuously executing the next instruction, and turning to the step 4;

The instruction ends.

The design of the customized software mainly comprises the simulation of an IP core of an FPGA soft core system through port expansion and the adaptation of the IP core and verification hardware environment, and takes the function of verification hardware environment as an example, the designed customized software needs to adapt a UART IP core of the FPGA soft core to UART peripheral equipment of an MCU chip and adapt an SPI IP core of the FPGA soft core to SPI peripheral equipment of the MCU chip.

The soft core system of the FPGA completes the IP core through port expansion by reading and writing the designated port address, and for the expansion of one IP core, the expansion can be simplified into the access to 3 ports:

control Register (CR): control configuration, enabling, and operation of IP, etc.;

status Register (SR): acquiring the state of the IP, such as buffer full, transmission BUSY and the like;

data Register (DR): by reading and writing DR, the transmission data can be written into the transmission buffer or the received data can be read from the reception buffer.

For convenience of explanation, the soft core system of the FPGA is called as the external expansion IP of the soft core for short by port external expansion IP, and the register specific definition of the external expansion IP of the soft core is different from the register specific definition of the corresponding peripheral of the MCU chip, so that the external expansion IP and the register specific definition of the corresponding peripheral of the MCU chip need to be adapted, which is a function that the customization software is required to realize.

For the purpose of illustrating the principle, the register definition of the external expansion IP of the soft core and the registers of the UART peripheral and the SPI peripheral of the MCU chip are defined, and for the purpose of better illustration, the SPI peripheral of the MCU chip is realized by adopting general IO simulation.

The soft-core UART IP register is defined as follows:

FPGA_CR：

bit0: FLASH_CS, CS pin control of SPI FLASH, 1 represents CS high level, 0 represents CS low level

Bit1-7: reservation of

FPGA_SR：

Bit0: SPI_BUSY, SPI transmitting BUSY status

Bit1: UART_RX_EMPTY, UART receiving buffer EMPTY state

Bit2: UART_TX_FULL, UART transmit buffer FULL status

Fpga_uart_dr: UART IP data register, which can be written when uart_tx_full=0 and read when uart_rx_empty=0

Fpga_spi_dr: the data register of SPI IP may be written when spi_busy=0, then spi_busy will become 1, and after SPI transmission is completed, spi_busy becomes 0, the register may be read, and the received data may be acquired.

For convenience of description, the registers are not specifically defined on the side of the MCU chip, and only specific operations are described:

gpio_spi_cs: MCU IO connected to SPI FLASH CS pin

Gpio_spi_sck: MCU IO connected to CLK pin of SPI FLASH

GPIO_SPI_MOSI: MCU IO connected to DIN pin of SPI FLASH

Gpio_spi_miso: MCU IO connected to DOUT pin of SPI FLASH

The customization software further includes simulation and adaptation of operation instructions of ports, and the number of port operation instructions of the soft core system of the FPGA is 2, OUTPUT and INPUT, wherein OUTPUT is writing a value of a source register into a designated port, INPUT is reading one data from the designated port and storing the data in a target register, and in this embodiment, the steps of simulating the two port operation instructions are as follows:

OUTPUT instruction:

step 1: the OUTPUT instruction begins;

step 2: decoding an OUTPUT instruction, acquiring a port number port_id and a source register number, and assigning a value of the source register to a variable port_data;

step 3: if the PORT number is equal to the port_cr, go to step 4; if port_id is equal to port_uart_dr, go to step 5; if port_id is equal to port_spi_dr, go to step 6; other port_ids, go to step 7;

step 4: assigning port_data to a global variable cr_reg for reading a port, judging bit0 of the port_data, and if the port_data is 0, setting GPIO_SPI_CS of the MCU to be low level; if the value is 1, setting the GPIO_SPI_CS of the MCU to be high level, and turning to the step 7;

step 5: writing port_data into a transmitting data register of a UART peripheral of the MCU, transmitting data through a serial port, and converting to the step 7;

Step 6: through IO simulation SPI, port_data is sent to SPI FLASH through SPI protocol (realized by controlling GPIO_SPI_SCK, GPIO_SPI_MOSI and GPIO_SPI_MISO), received data (SPI is duplex communication and is sent and received simultaneously) is assigned to designated variable spi_recv_byte, and step 7 is shifted;

step 7: the instruction ends.

INPUT instruction:

step 1: the INPUT instruction begins;

step 2: decoding an INPUT instruction to obtain a port number port_id;

step 3: if the PORT number is equal to the port_cr, go to step 4; if the PORT number is equal to PORT_SR, turning to step 5; if port_id is equal to port_uart_dr, go to step 6; if port_id is equal to port_spi_dr, go to step 7; if other port_ids, go to step 8;

step 4: assigning the value of cr_reg to a variable rd_reg, and turning to the step 8;

step 5: defining a temporary variable sr_temp, giving an initial value of 0, firstly checking a non-empty mark of a receiving register of the MCU UART, if not, resetting bit1 of the sr_temp, otherwise, setting bit1 of the sr_temp to 1; then checking whether the MCU UART sending register is empty, if so, resetting bit2 of the sr_temp, otherwise, setting bit2 of the sr_temp to 1; assigning the value of sr_temp to a variable rd_reg, and turning to step 8;

Because the general IO is adopted to simulate SPI data receiving and transmitting, the completion instruction of each time of receiving and transmitting is finished, the SPI_BUSY bit can be always kept to be 0;

step 6: reading data from a UART receiving register of the MCU, assigning the read data to a variable rd_reg, and turning to the step 8;

step 7: assigning the value of the spi_recv_byte to the variable rd_reg, and turning to the step 8;

step 8: the value of rd_reg is written into the specified register and the instruction ends.

Thus, the transplanting and adapting of the verification software are completed.

Step 3: running a simulator; the simulator is to be run using the following operations:

step 3-1: machine instruction translation: converting the compiled program of the FPGA soft core into an array program [ ] of a C language, wherein each element of the array represents an instruction of the FPGA soft core, and the subscript of the array element represents the storage address of the instruction in a program storage area;

step 3-2: the array program [ ] is added to the simulator program.

The simulator is running: the program starts, the simulator is initialized, for example, the PC is set to zero, the register, RAM and the like are cleared, and the corresponding instruction is obtained from the array program by taking the PC as a subscript; decoding the instruction, judging the instruction type, and calling a corresponding instruction simulation function according to the instruction type.

Example 3:

the present embodiment proposes a program debugging method for an FPGA soft core based on embodiments 1 and 2, where the debugging method is mainly used for inserting program breakpoints. The FPGA soft core is incapable of inserting program breakpoints, but the program of the MCU chip can be debugged by inserting the program breakpoints through an emulator of the MCU chip, so that the program breakpoints are simply added into the emulator, firstly, a log file generated by an assembler is checked, a storage position ADDR of an instruction corresponding to an assembly statement of the program breakpoints to be inserted is checked, and then, as shown in fig. 4, an operation is added between the instruction fetching and decoding flow of the emulator: judging whether the current PC value is the same as the ADDR value, if so, executing a null operation (such as NOP instruction), and marking a program breakpoint for the null operation, when the simulator runs, if the simulator runs to the ADDR, the program breakpoint is entered, and the data of the current simulator storage unit can be checked through the simulator of the MCU chip to see whether the data are consistent with the expected data, so that the purpose of debugging is achieved.

Example 4:

the present embodiment proposes a program debugging method for an FPGA soft core based on embodiment 1 and embodiment 2, and the debugging method is mainly used for inserting print information. When the assembler runs, some data and information in the running process are printed out, errors and alarms in the running process of the assembler can be obtained, and the errors can be analyzed and positioned according to the printing information, but the FPGA soft core is unlikely to print information due to limited resources and complex design of the assembler, and the operation can be conveniently carried out through a simulator.

For example, the parameters when the objective function call in the assembler is desired to be printed are first located to the first instruction after entering the objective function through the log file, find the storage location ADDR of the instruction, as shown in fig. 5, add an operation in the middle of the instruction fetching and decoding flow of the simulator: judging whether the current PC value and ADDR are the same, if so, reading the parameters according to the position (register or data storage area) stored by the parameters of the objective function in the assembler, and printing the values of the parameters through a debugging serial port of the MCU.

The operation can also be adopted to print and view the message content, and the message comes from an upper computer. The specific operation comprises the following steps: according to the log file generated by assembly, determining the storage address ADDR of an instruction to be inserted with printing information, judging that the PC and the ADDR are equal, adding the printing information, wherein the printing information is a message from an upper computer, the received message is stored in a certain section of memory of an FPGA soft core, corresponding message information (message length and the like) is possibly stored in a register of the FPGA soft core, finding out the section of memory in a simulator and the actual memory of an MCU chip corresponding to the register, inserting codes in a simulator program, and printing out the section of memory for analysis. And recompiling the simulator program of the MCU, running the program to the address ADDR, and printing the information of the message.

Example 5:

the embodiment provides a program verification method for an FPGA soft core based on embodiment 1 and embodiment 2. The FPGA soft core performs some data processing, but the data processing result is that the error cannot be immediately verified, if there are multiple data processing links, it cannot be known which data processing link the error is in when the error is finally reported, and because of the characteristics of the assembler design, it is not easy to verify the data processing result, but if the same data processing algorithm is designed by using the C language, the error probability is much smaller, and it is easy to verify the data processing result of the data processing assembler running on the FPGA soft core in the simulator, as shown in fig. 6 and 7, and the specific operations include:

if FPA certain algorithm subfunction of the GA soft core is used to implement an algorithm, and in order to verify the accuracy of the algorithm, the same algorithm subfunction (which may be written in the C language) is added to the simulator program, and for convenience of expression, the algorithm subfunctions are named as: algorithm sub-function fpga _{Function of} Sum algorithm subfunction mcu _{Function of} It should be understood that both are functions having the same function.

In algorithm sub-function fpga _{Function of} At the entrance, call the algorithm subfunction mcu _{Function of} Algorithm sub-function fpga _{Function of} The required parameters and source data are used as an algorithm sub-function mcu _{Function of} Parameters and source data of the simulator can be obtained from registers and memory areas of the simulator, and the simulator algorithm subfunctions cannot change the parameters and the parameters to obtain an operation result mcu_res;

returning to the algorithm subfunction fpga _{Function of} Executing the algorithm sub-function fpga _{Function of} Obtaining an operation result fpga_res;

comparing whether the running result mcu_res is the same as the running result fpga_res can judge whether the algorithm sub-function of the FPGA soft core runs correctly or not, but the premise is that the algorithm sub-function of the simulator of the MCU runs without problems.

Example 6:

the embodiment discloses a computer device, which comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the processor executes the computer program to realize the steps disclosed in any one of the embodiments.

Example 7:

the present embodiment discloses a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps disclosed in any of the embodiments described above.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, or the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory. By way of illustration, and not limitation, RAM can be in the form of a variety of forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), and the like.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The above examples merely represent a few embodiments of the present application, which are described in more detail and are not to be construed as limiting the scope of the invention. It should be noted that it would be apparent to those skilled in the art that various modifications and improvements could be made without departing from the spirit of the present application, which would be within the scope of the present application. Accordingly, the scope of protection of the present application is to be determined by the claims appended hereto.

Claims

1. A program debugging method of an FPGA soft core is characterized in that: the method comprises the following steps:

obtaining a debugging result by checking the execution result;

the simulation system of the FPGA soft core is based on MCU design.

2. The program debugging method of an FPGA soft core according to claim 1, wherein: the debugging operation instruction is a breakpoint debugging operation instruction.

3. The program debugging method of an FPGA soft core according to claim 2, wherein: the method for converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, compiling the array program [ ] and the debugging operation instruction into a debugging program comprises the following steps: converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, and compiling the array program [ ] and a storage position ADDR of an instruction to be inserted with a breakpoint into the breakpoint debugging program.

4. A method for debugging a program of an FPGA soft core according to claim 3, wherein: the method for converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, compiling the array program [ ] and a storage position ADDR of an instruction to be inserted with a breakpoint into the breakpoint debugging program comprises the following steps:

5. The program debugging method of an FPGA soft core according to claim 1, wherein: the debugging operation instruction is a printing information operation instruction.

6. The method for debugging the program of the soft core of the FPGA of claim 5, wherein: the method for converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, compiling the array program [ ] and the debugging operation instruction into a debugging program comprises the following steps: converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, and compiling the array program [ ] and a storage position ADDR of an instruction to be inserted with printing information into an information printing debugging program.

7. The method for debugging the program of the soft core of the FPGA of claim 6, wherein: the method comprises the steps of converting a program to be debugged of an FPGA soft core into an array program [ ] of a C language, compiling the array program [ ] and a storage position ADDR of an instruction to be inserted with printing information into an information printing debugging program, and specifically comprises the following steps:

8. The method for debugging the program of the soft core of the FPGA of claim 7, wherein: the target information is message information from an upper computer.

9. The method for debugging the program of the soft core of the FPGA of claim 7, wherein: the target information is parameter information when the target function is called.

10. A program debugging system of an FPGA soft core is characterized in that: comprising the following steps:

11. The program debug system of an FPGA soft core of claim 10, wherein: the debugging operation instruction is a breakpoint debugging operation instruction.

12. The program debug system of an FPGA soft core of claim 11, wherein: the method for converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, compiling the array program [ ] and the debugging operation instruction into a debugging program comprises the following steps: converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, and compiling the array program [ ] and a storage position ADDR of an instruction to be inserted with a breakpoint into the breakpoint debugging program.

13. The program debug system of an FPGA soft core of claim 10, wherein: the debugging operation instruction is a printing information operation instruction.

14. The program debug system of an FPGA soft core of claim 13, wherein: the method for converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, compiling the array program [ ] and the debugging operation instruction into a debugging program comprises the following steps: converting the program to be debugged of the FPGA soft core into an array program [ ] of C language, and compiling the array program [ ] and a storage position ADDR of an instruction to be inserted with printing information into an information printing debugging program.

15. A program verification method of an FPGA soft core is characterized by comprising the following steps of: comprising the following steps:

the simulation system of the FPGA soft core is based on MCU design.

16. The program verification method of an FPGA soft core according to claim 15, wherein: the compiling of the array program [ ] and the algorithm subfunction mcu function into an algorithm verification program specifically comprises the following steps:

17. The program verification module of the FPGA soft core is characterized in that: comprising the following steps:

algorithm verification program assembly module for converting the program to be debugged of FPGA soft core into C language array program]Array program]Sum algorithm subfunction mcu _{Function of} Compiling into an algorithm verification program; the algorithm subfunction mcu _{Function of} An algorithm sub-function FPGA for realizing a specific algorithm exists with a program to be debugged in the FPGA soft core _{Function of} Is the same sub-function;

the simulation system of the FPGA soft core based on the MCU design is used for running an algorithm verification program to obtain a verification result, wherein the verification result is an algorithm sub-function FPGA _{Function of} At FPWhether the GA soft core is operating correctly.

18. The program verification module of an FPGA soft core of claim 17, wherein: the array program]Sum algorithm subfunction mcu _{Function of} Compiling into an algorithm verification program, which concretely comprises the following steps:

19. An apparatus comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of a method for program debugging an FPGA soft core according to claims 1 to 9 or the steps of a method for program verification of an FPGA soft core according to any of claims 15 to 16 when the computer program is executed.

20. A storage medium storing a program which, when executed by at least one processor, implements the steps of a program debugging method of an FPGA soft core according to claims 1 to 9 or implements the steps of a program verification method of an FPGA soft core according to any one of claims 15 to 16.