A verification method, device, electronic device and readable storage medium

Abstract

The embodiment of the present invention provides a verification method, device, electronic device and readable storage medium, the method comprising: controlling the design to be tested to execute a test program, and collecting the first execution information of the design to be tested; generating a data packet according to the first execution information of the design to be tested when the triggering condition of a preset event is met; the data packet includes the number of execution instructions of the design to be tested; sending the data packet to the software end; parsing the updated data packet to determine the second execution information of the reference model; comparing the first execution information with the second execution information; and determining that the design to be tested has an error in operation when the first execution information and the second execution information do not match. The embodiment of the present invention increases the visibility of verification, facilitates the rapid location of the error position of the design to be tested, and is conducive to timely fine-grained debugging and inspection of the design to be tested.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a verification method, device, electronic device and readable storage medium. Background Art

[0002] In the whole process of processor development, verification is the longest and most difficult part, usually accounting for 50% to 70% of the development cycle. Therefore, more methods are needed to enhance the agile verification capability of processor chips and further improve the efficiency and quality of processor chip development. Traditional verification methods mainly include software simulation and FPGA prototype verification.

[0003] However, the software simulation verification method has low performance. Its advantage is that it has a high degree of visualization and can be debugged through waveforms, setting breakpoints, etc. However, the main problem with this method is that the operating clock frequency can only reach a few thousand Hertz, and the performance depends on the specific simulation software, which seriously affects the verification efficiency.

[0004] The debugging difficulty of FPGA prototype verification method is very high. As a standard pre-silicon verification method, FPGA prototype verification has been widely adopted by the industry. Its advantage is that it does not require the construction of a simulation platform, but directly implements the RTL design and verifies it on the FPGA. The main feature of this method is that it runs at a fast speed and the operating frequency can reach tens of megahertz. However, the main problem of this method is that the debugging capability is weak, and the visibility of the intermediate information in the verification process is low, which is not conducive to locating and analyzing error problems. Summary of the invention

[0005] The embodiments of the present invention provide a verification method, device, electronic device and readable storage medium, which can increase the visibility of chip verification and improve verification efficiency.

[0006] In a first aspect, an embodiment of the present invention discloses a verification method, which is applied to a hardware end, wherein the hardware end includes a design to be tested, and the hardware end is connected to a software end via a bus interface, and the software end includes a reference model of the design to be tested; the method comprises:

[0007] Controlling the design to be tested to execute a test program and collecting first execution information of the design to be tested;

[0008] When a trigger condition of a preset event is met, a data packet is generated according to the first execution information of the design to be tested; the data packet includes the number of execution instructions of the design to be tested;

[0009] Sending the data packet to the software end, so that the software end drives the reference model to execute the same number of instructions based on the number of executed instructions, and updates the data packet according to the second execution information of the reference model;

[0010] Parsing the updated data packet to determine second execution information of the reference model;

[0011] comparing the first execution information with the second execution information;

[0012] When the first execution information and the second execution information do not match, it is determined that the design under test has an operation error.

[0013] In a second aspect, an embodiment of the present invention discloses another verification method, which is applied to a software end, wherein the software end is connected to a hardware end through a bus interface, wherein the hardware end includes a design to be tested, and wherein the software end includes a reference model of the design to be tested; the method comprises:

[0014] Receiving a data packet sent by the hardware end; the data packet includes the number of execution instructions of the design to be tested;

[0015] driving the reference model to execute the same number of instructions according to the number of executed instructions, and updating the data packet according to the second execution information of the reference model;

[0016] The updated data packet is sent to the hardware end.

[0017] In a third aspect, an embodiment of the present invention discloses a verification device, which is applied to a hardware end, wherein the hardware end includes a design to be tested, and the hardware end is connected to a software end via a bus interface, wherein the software end includes a reference model of the design to be tested; the device includes:

[0018] A control module, used for controlling the design to be tested to execute a test program and collecting first execution information of the design to be tested;

[0019] A data packet generating module, configured to generate a data packet according to the first execution information of the design to be tested when a trigger condition of a preset event is met; the data packet includes the number of execution instructions of the design to be tested;

[0020] A sending module, used for sending the data packet to the software end, so that the software end drives the reference model to execute the same number of instructions based on the number of executed instructions, and updates the data packet according to the second execution information of the reference model;

[0021] A parsing module, used to parse the updated data packet to determine the second execution information of the reference model;

[0022] a comparing module, configured to compare the first execution information with the second execution information;

[0023] A determination module is used to determine that the design under test has an operation error when the first execution information and the second execution information do not match.

[0024] In a fourth aspect, an embodiment of the present invention provides another verification device, which is applied to a software end, wherein the software end is connected to a hardware end through a bus interface, wherein the hardware end includes a design to be tested, and wherein the software end includes a reference model of the design to be tested; the device includes:

[0025] A data packet receiving module, used to receive a data packet sent by the hardware end; the data packet includes the number of execution instructions of the design to be tested;

[0026] a data packet updating module, configured to drive the reference model to execute the same number of instructions according to the number of executed instructions, and to update the data packet according to the second execution information of the reference model;

[0027] The data packet sending module is used to send the updated data packet to the hardware end.

[0028] On the other hand, an embodiment of the present invention further discloses an electronic device, which includes a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions enable the processor to execute the aforementioned verification method.

[0029] The embodiment of the present invention further discloses a readable storage medium. When instructions in the readable storage medium are executed by a processor of an electronic device, the electronic device can execute the aforementioned verification method.

[0030] The embodiments of the present invention include the following advantages:

[0031] The embodiment of the present invention provides a verification method, which performs collaborative verification on the design to be tested based on the hardware side and the software side. When the triggering condition of the preset event is met, a data packet is generated according to the first execution information of the design to be tested, and the data packet is sent to the software side. The software side drives the reference model to execute the same number of instructions according to the number of execution instructions in the data packet. The software side updates the second execution information of the reference model into the data packet and sends the data packet to the hardware side. The hardware side verifies the design to be tested based on the second execution information of the reference model by parsing the data packet. The embodiment of the present invention can trigger the verification of the design to be tested based on the preset event, which increases the visibility of the verification, facilitates the rapid positioning of the error position of the design to be tested, and is conducive to timely fine-grained debugging and inspection of the design to be tested. In addition, compared with software simulation verification, the embodiment of the present invention burns the design to be tested to the hardware side for operation, which improves the verification rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0033] Figure 1 is a flowchart of steps of an embodiment of a verification method of the present invention;

[0034] Figure 2 is a schematic diagram of a data packet format of the present invention;

[0035] Figure 3 It is a communication schematic diagram of a hardware end and a software end of the present invention;

[0036] Figure 4 is a flowchart of another verification method embodiment of the present invention;

[0037] Figure 5 is a structural block diagram of an embodiment of a verification device of the present invention;

[0038] Figure 6 is a structural block diagram of another verification device embodiment of the present invention;

[0039] Figure 7 It is a structural block diagram of an electronic device for verification provided by an example of the present invention. DETAILED DESCRIPTION

[0040] 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 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.

[0041] The terms "first", "second", etc. in the specification and claims of the present invention are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable when appropriate, so that the embodiments of the present invention can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. In the embodiments of the present invention, the term "multiple" refers to two or more, and other quantifiers are similar.

[0042] Method Embodiment

[0043] Reference Figure 1 , shows a flow chart of steps of an embodiment of a verification method of the present invention, the method is applied to a hardware end, the hardware end is connected to a software end via a bus interface, the software end includes a reference model of the design to be tested; the method may specifically include the following steps:

[0044] Step 101, controlling the design to be tested to execute a test program, and collecting first execution information of the design to be tested;

[0045] Step 102: When a trigger condition of a preset event is met, a data packet is generated according to the first execution information of the design to be tested; the data packet includes the number of execution instructions of the design to be tested;

[0046] Step 103: Send the data packet to the software end, so that the software end drives the reference model to execute the same number of instructions based on the number of executed instructions, and updates the data packet according to the second execution information of the reference model;

[0047] Step 104: parse the updated data packet to determine the second execution information of the reference model;

[0048] Step 105: Compare the first execution information with the second execution information;

[0049] Step 106: When the first execution information and the second execution information do not match, determine that the design under test has an operation error.

[0050] The verification method provided by the embodiment of the present invention can be applied to the hardware end, and the hardware end is used to perform collaborative verification on the design under test (DUT) with the software end. The hardware end includes the DUT, and the software end includes the reference model of the DUT.

[0051] Exemplarily, the hardware end in the present invention may be a programmable logic chip (Field Programmable Gate Array, FPGA), and the design to be tested is deployed in a programmable logic (Programmable Logic, PL) area of ​​the FPGA chip.

[0052] It should be noted that FPGA is a reconfigurable integrated circuit chip with a wide range of applications. Unlike traditional fixed-function integrated circuits (ASICs), FPGAs can be flexibly reprogrammed and reconfigured according to user needs to adapt to different applications and functions. FPGAs are composed of a large number of programmable logic blocks and programmable interconnect resources. Programmable logic blocks are usually composed of look-up tables (LUTs), registers, and other logic elements, which can perform various logic functions. Programmable interconnect resources are used to connect logic blocks to form the required circuit structure. With FPGAs, design engineers can use hardware description languages ​​to describe the required circuit functions and convert them into bitstreams compatible with FPGA chips through programming tools. The bitstream contains information for programming and configuring the internal logic and interconnection resources of the FPGA. One of the main advantages of FPGAs is its programmability and flexibility. It allows design engineers to implement customized functions and algorithms at the hardware level without the traditional custom integrated circuit design and manufacturing process. This makes FPGAs play an important role in prototype development and rapid design iteration.

[0053] The design under test (DUT) refers to the circuit design or implementation to be tested in prototype verification. Exemplarily, the design under test can be a register transfer level (RTL) circuit or other hardware design. It should be noted that the RTL circuit is a common hardware description level circuit. The RTL circuit describes the behavior and structure of the digital circuit and is represented using the abstract hierarchy of the register transfer level. The RTL circuit description is usually written in a hardware description language (HDL), such as VHDL (VHSIC Hardware Description Language), Verilog HDL, and System Verilog HDL. Designers can use the RTL level description to define and implement the required digital circuit functions, and then use the synthesis tool to convert the RTL level description into a physical implementation in a field programmable gate array (FPGA).

[0054] The reference model is used to implement the same function as the design under test. During the verification of the design under test, the data generated when the reference model is called can be considered correct and used as reference data for comparison with the data generated by the design under test. It is understandable that different reference models are generated for different designs under test. As an example, before the design under test is subjected to high-level synthesis, a source design model of the design under test can be generated based on the design code of the design under test in C / C++ language. The source design model has the same algorithm function as the design under test and can be used as a reference model of the design under test.

[0055] Software and hardware need to communicate through a defined interaction structure, and the decoupling of software and hardware is achieved through interfaces. For example, for a CPU, the interface between software and hardware is the instruction set architecture ISA. The processor under the ISA is hardware, and the various programs, data sets, files, etc. above the instruction set are software.

[0056] The software end in the embodiment of the present invention refers to a program on an instruction set. The software end can be installed in a personal computer (PC) or in other electronic devices with an operating system that can run software. The electronic devices may include but are not limited to: smart terminals, computers, personal digital assistants (PDAs), tablet computers, etc.

[0057] The hardware and software ends communicate through data interfaces, such as the high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIE) interface, general purpose input and output port (General Purpose Input Output, GPIO), and so on.

[0058] It should be noted that since the intermediate data generated during the operation of the design under test and some signal values ​​or status values ​​that need to be verified are usually invisible, if verification is only based on the final output results of the design under test, errors cannot be reported in time and it is difficult to locate the error position, which is not conducive to debugging the design under test.

[0059] In an embodiment of the present invention, the design under test can be verified based on events. Specifically, during the process of executing the test program of the design under test, if the triggering condition of the preset event is met, a data packet is generated according to the first execution information of the design under test, and the data packet includes the number of execution instructions of the design under test. The hardware end sends the data packet to the software end.

[0060] The software end drives the reference model to execute the same number of instructions based on the number of execution instructions in the data packet, updates the second execution information of the reference model into the data packet, and sends the updated data packet to the hardware end.

[0061] The hardware side parses the updated data packet of the software side to obtain the second execution information of the reference model. Then, the first execution information of the design to be tested is compared with the second execution information of the reference model. If the first execution information does not match the second execution information, it can be determined that the design to be tested has an error.

[0062] The verification method provided by the embodiment of the present invention can trigger the verification of the design to be tested based on a preset event, thereby increasing the visibility of the verification, facilitating the rapid location of the error position of the design to be tested, and facilitating timely fine-grained debugging and inspection of the design to be tested. Moreover, compared with software simulation verification, the embodiment of the present invention burns the design to be tested to the hardware end for operation, thereby increasing the verification rate.

[0063] It should be noted that before the design to be tested is burned into the FPGA chip, the chip code of the design to be tested can be modified, and the data transmitted by each data interface of the design to be tested can be connected to the top-level module of the design to be tested, so as to collect the intermediate data of the design to be tested and the execution information during the operation. Specifically, the chip code of the design to be tested can be analyzed, and a data transmission path pointing to the top-level module can be added for each data interface of the design to be tested, so that the data transmitted by each data interface of the design to be tested can be connected to the top-level module without changing the original operation logic of the design to be tested, so that the external modules or components (such as the control module, monitoring module, etc. in the hardware end) of the design to be tested can be obtained. Among them, the top-level module is a module containing all other modules in the design to be tested, and the top-level module is not instantiated in any other module. After the data in the design to be tested is connected to the top-level module, the data to be verified can be drawn from the top-level module and a data packet can be generated and sent to the software end to drive the reference model to execute the test program.

[0064] The preset event can be determined according to the processor behavior of the design to be tested. For example, taking a processor with multiple out-of-order operations as an example, the processor behavior can be abstracted as: instruction comparison event (instruction execution result comparison event), register comparison event, comparison error event, exception event, external interrupt event, self-trap event, atomic instruction event, and peripheral access event. Among them, the instruction comparison event refers to the comparison of the instruction execution results of the design to be tested and the reference model. The register comparison event refers to the comparison of the values ​​of each register in the design to be tested and the reference model. The comparison error event includes at least one of the comparison error of the instruction execution result of the design to be tested and the comparison error of the register value. The exception event refers to an abnormal event that occurs during the operation of the design to be tested, and the abnormal event will interrupt the normal execution process of the instruction. In the field of chip design, the abnormal events in the design to be tested can usually include hardware execution exceptions or software faults. The exception received by the processor after executing an instruction will trigger the processor to execute a special exception handling process. An external interrupt event refers to an interruption of the design under test caused by an input signal outside the design under test. For example, an external interrupt event of the design under test may include an interrupt module in the hardware end sending an interrupt signal to the design under test when an error occurs in the design under test, causing the design under test to be interrupted. After the processor receives the interrupt signal from the external hardware, it needs to respond to the input interrupt. A trap event is a pre-arranged abnormal event, just like a pre-set "trap". When the processor executes the trap instruction, it will automatically perform corresponding processing according to different trap types, and then return to the next instruction of the trap instruction for execution (if the trap instruction is a transfer instruction, it returns to the transfer target instruction for execution). An atomic instruction event refers to the processor locking the memory space to be accessed to prevent other hardware from accessing it, ensuring that the processor running the program can access data synchronously with multiple threads. An access peripheral event refers to the design under test accessing an external device, and the external device refers to a device mounted on the FPGA chip that does not belong to the PL end or the PS end, such as a double data rate synchronous dynamic random access memory (DDR) and other external storage devices.

[0065] Exemplarily, the preset event in the embodiment of the present invention may include at least one of an instruction comparison event and a register comparison event.

[0066] In the embodiment of the present invention, different events may trigger the generation of different data packets. The data packets corresponding to the eight events in the above example may adopt a unified data packet format. Figure 2 , shows a schematic diagram of a data packet format provided by an embodiment of the present invention. Figure 2As shown in FIG. 1 , a data packet can be divided into a metadata segment describing the packet information and a data segment containing specific data. Bits 0-63 of the data packet are the metadata segment, and the subsequent fields such as Data1 and Data2 are the data segment.

[0067] The metadata segment contains the basic information of the data packet, and the fields are introduced as follows: the Message_Size field indicates how many bytes of data are in the data packet; the Sequence field indicates which data packet this is; the Extra_Inforamtion field indicates the valid information of the event; the Data_len field indicates how much data is in the data area of ​​this data packet. This field exists to avoid interference of some transmission characteristics on the software side with data transmission.

[0068] The data segment includes the specific information that needs to be synchronized in the event. The size of the data segment is determined by the Data_Size subfield in the Extra_Inforamtion field. This field determines how many 64 bits a single data occupies. When the Data_Size field is 1 (default), each data occupies 64 bits.

[0069] Different types of data packets are distinguished by Extra_Information. Assuming the data packet size is 512 bits, one transmission can be divided into 8 64-bit data packets, of which DATA1 is used to mark the category information of the event packet, and the remaining 7 DATA records the information that needs to be synchronized to the simulator for each event. The Extra_Information design is as follows:

[0070] XS->NEMU refers to sending the collected processor information on the FPGA to the simulator. The specific format of the information sent is as follows:

[0071] [0]IsNormalCommit: 1 bit, normal command commit event flag;

[0072] [1]IsRegCompare: 1 bit, register comparison event flag;

[0073] [2]IfDiffError: 1 bit, comparison error event flag;

[0074] [3]IsArchEvent: 1 bit, ARCH event flag;

[0075] [4]IsTrapEvent: 1 bit, TRAP event flag;

[0076] [5]IsLrScEvent: 1 bit, atomic event flag;

[0077] [6]IsMMIOEvent: 1 bit, MMIO event flag;

[0078] [7:9]DataSize: 3 bits, the default size of each data is 64.

[0079] Data1 stores the number of instructions to be executed, and DATA2 to DATA7 are used to record the simulator execution result information. This data packet relies on Data_Len to record the amount of information transmitted back to the FPGA side.

[0080] NEMU->XS refers to the information passed by the simulator to the FPGA to mark the simulator execution results. The specific format is as follows:

[0081] [0]IsNormalCommit:1 bit

[0082] [1]IsRegCompare:1bit

[0083] [2]DiffError_Done:1bit

[0084] [3]ArchEvent_Done:1bit

[0085] [4]TrapEvent_Done: 1 bit

[0086] [5]LrScEvent_Done:1 bit

[0087] [6]MMIOEvent_Done:1 bit

[0088] [7:9]DataSize:3bit

[0089] If the data packet format needs to be modified, additional event processing rules are added on the hardware side, and corresponding logic adaptation is performed on the software.

[0090] In an embodiment of the present invention, the hardware end and the software end exchange information through data packets. Exemplarily, when the triggering conditions of a preset event are met, the hardware end generates a data packet according to the first execution information of the design to be tested, and indicates the number of execution instructions to the software end in the data packet. After receiving the data packet, the software end parses it, drives the reference model to execute the same number of instructions based on the number of execution instructions, writes the second execution information of the reference model into the data packet, and sends the updated data packet to the hardware end. The hardware end parses the data packet to determine the second execution information of the reference model, and then verifies the first execution information of the design to be tested based on the second execution information. If the two do not match, it can be determined that the design to be tested has an error.

[0091] It should be noted that the test programs executed by the design to be tested and the reference model are the same, so the order of instructions executed by the two is the same. When the design to be tested and the reference model execute the same number of instructions each time, it can be ensured that the first execution information of the design to be tested and the second execution information of the reference model are synchronized, avoiding inaccurate verification results due to the first execution information and the second execution information being out of sync, thereby ensuring the accuracy of the verification results.

[0092] The contents of the first execution information and the second execution information can be determined according to the data that needs to be verified in the design to be tested. For example, the first execution information and the second execution information can include the values ​​of all general purpose registers (GPR), the values ​​of control and status registers (CSR), the values ​​of program counters (PC), the results of instruction execution, etc. In practical applications, the specific contents of the first execution information and the second execution information can be specified according to the actual situation and specific verification requirements. Taking the design to be tested as a RISC-V processor as an example, when making comparisons, 32 GPR registers, 18 CSR registers and PC values ​​can be compared.

[0093] The first execution information of the design to be tested is compared with the second execution information of the reference model. If the first execution information matches the second execution information, for example, the first execution information is the same as the second execution information, or the value of the parameter in the first execution information falls within the value range of the corresponding parameter in the second execution information, etc., it can be considered that there is no error in the design to be tested. At this time, the design to be tested can be controlled to continue executing the next instruction.

[0094] If the first execution information does not match the second execution information, for example, the first execution information is different from the second execution information, or the value of the parameter in the first execution information does not fall within the value range of the corresponding parameter in the second execution information, etc., it can be considered that the design under test has an error. In this case, a snapshot can be taken of the entire hardware end, the status information of the hardware end can be saved, and the saved data can be sent to the software end, which displays the information so that the verification engineer can perform on-site error checking based on the saved status information.

[0095] In a possible application scenario of the present invention, snapshot information on the hardware side may be imported into simulation software on the software side, and the simulation software may be used to perform fine-grained debugging on the design to be tested.

[0096] Optionally, the preset event includes an instruction comparison event; the triggering condition of the instruction comparison event includes: the number of instructions executed by the design to be tested is greater than or equal to a first threshold, and no synchronization event is detected.

[0097] The synchronization event refers to the need to synchronize the state of the design under test and the reference model. For example, when an abnormal event, external interrupt event, self-trap event, atomic instruction event, or peripheral access event occurs in the design under test, the design under test and the reference model need to be synchronized, that is, the synchronization event is triggered.

[0098] Optionally, comparing the first execution information with the second execution information includes:

[0099] Step S11, writing the first execution information of the design to be tested into the first queue;

[0100] Step S12, writing the second execution information of the reference model into the second queue;

[0101] Step S13: after detecting that both the first queue and the second queue have data written, reading the first execution information recorded in the first queue and the second execution information recorded in the second queue;

[0102] Step S14: Compare the first execution information with the second execution information.

[0103] In an embodiment of the present invention, a queue can be configured for the design to be tested and the reference model respectively on the hardware side for writing execution information. Specifically, the first execution information of the design to be tested is written into the first object, and the second execution information of the reference model is written into the second queue. After detecting that data is written into both the first queue and the second queue, the execution information recorded in the two queues is read and compared.

[0104] Reference Figure 3 , shows a communication schematic diagram of a hardware end and a software end provided by an embodiment of the present invention. Figure 3As shown in the figure, Xs_Top is the processor hardware deployed on the FPGA; XDMA is the hardware module for transmitting data between the PC and the FPGA; the Handle_Break module is the hardware module for filtering invalid data in the processor input information; the Assign_Commit module is the hardware module for processing the processor instruction submission data; the Parse (analysis) module is used to parse the information transmitted from the simulator on the PC to the module on the FPGA through XDMA, and write the parsed data into the corresponding FIFO_Diff_Tile for comparison; the Control_Block module is a hardware module that controls the execution order of other modules according to the processor input information, and the XsToNemu module is used to receive the hardware data packet generated by the processor information and send it to XDMA for transmission to the simulator running on the PC; the Gen_Break module is used to receive the control information of the Control_Block and generate the operation signal of the control processor; the Interruption_logic module is used to receive the Gen_Break signal to control the processor clock; the FIFO_Diff_Tile is a group of FIFOs with left and right sides symmetrical. When data is written into the FIFO, it is automatically compared and the error position is reported after an error.

[0105] Assume that the hardware end is the PL end of the FPGA and the software end is NEMU. For the instruction comparison event, Xs_Top executes T instructions, which are written to the FIFO Tile on the DUT side, that is, the first queue, after passing through the Handle_Break module and the Assign_Commit module. If no synchronization event is encountered, execution continues. When the instruction counter in the Control_Block module reaches T instructions and no synchronization event is detected, an instruction comparison event is sent to the XsToNemu module, control_valid is pulled high, IsNormalCommit=0, and execute_instr=T. When the XsToNemu module receives the instruction comparison event, it will generate a data packet and send it to the software end, such as NEMU. NEMU receives the data packet (it may be necessary to open two processes here, use shared space, and maintain the number of instructions to be executed by NEMU), execute the program according to the number of instructions, and store the instruction running results in the data packet. After execution, the data packet is sent to the Parse module on the PL side through XDMA. The Parse module parses the data packet, parses the packet header, sets relevant parameters, parses the data of each frame and sends it to the port, writes it to FIFO_Tile, and when the width of AXI_Stream (a protocol for hardware transmission, which limits the data bit width of the XDMA module) is 512 bits, a maximum of 8 data are passed in at a time, and the data is written into the corresponding NEMU side FIFO according to the last three digits of the instruction counter, that is, the second queue. Diff_Tile detects that there is data on both sides of the FIFO, reads the data in and compares it, and outputs the comparison result and the number of compared instructions to the Contol_Block module. If the comparison is correct, the execution continues. If the comparison is wrong, the instruction counter value, PC value and other information of the wrong instruction are output, and the correct value is output to the XsToNemu module, and then the data packet is sent to the software end for processing, showing the user the location of the error. When the comparison shows that the execution results of the simulator and the processor are not equal, the comparison error data value and the correct value will be sent to the XsToNemu module, which will send the relevant information of the comparison error to the simulator for notification.

[0106] Among them, FIFO_Diff_Tile contains two FIFOs and a comparison unit. Its hardware mapping is: NEMU_FIFO_Tile——DIFF——XS_FIFOTile. FIFO_Tile will record the execution information that the processor needs to compare. The DIFF module automatically compares whether the data in the FIFO is equal.

[0107] Optionally, the preset event includes a register comparison event; and when a trigger condition of the preset event is met, generating a data packet according to the first execution information of the design to be tested includes:

[0108] When it is detected that the number of instructions executed by the design under test since the last register comparison event occurs is greater than or equal to a second threshold, a register comparison data packet is generated according to the number of instructions executed by the design under test since the last instruction comparison event occurs.

[0109] Optionally, the hardware end further includes a register data module; the first execution information and the second execution information include register values. The comparing the first execution information with the second execution information includes:

[0110] Step S21, writing the first value of each register in the design to be tested into the register data module;

[0111] Step S22, writing the second value of each register in the reference model into the register data module;

[0112] Step S23: compare the first value and the second value.

[0113] In an embodiment of the present invention, a register data module, such as a Diff_Tilefor Reg data module, may be allocated in the hardware end. When the triggering condition of the register comparison event is met, the first value of each register in the design to be tested and the second value of each register in the reference model are written into the register data module for comparison.

[0114] Optionally, the method further comprises:

[0115] When it is detected that the number of instructions executed by the design under test since the last register comparison event occurs is greater than or equal to a second threshold, the operation of the design under test is interrupted until the first value and the second value are all written into the register data module, and then the operation of the design under test is resumed.

[0116] In an embodiment of the present invention, when the triggering condition of the register comparison event is met, the operation of the design under test can be interrupted first. After the first value of the register in the design under test and the second value of the register in the reference model are written into the register data module, the operation of the design under test can be resumed to avoid the design under test continuing to execute instructions to update the value of the register, causing the register state of the design under test to be out of sync with the register state of the reference model.

[0117] by Figure 3For example, for register comparison events, when the Control_Block module detects that S instructions have been submitted since the last register value comparison event, it outputs an interrupt signal to stop the execution of the DUT, and at the same time counts the number of instructions between the last instruction comparison event and transmits it to the XsToNemu module. The XsToNemu module receives the register comparison event, sets the corresponding information bit in the data packet, and puts the number of instructions to be executed into Data1. NEMU receives the data packet, parses the instructions to be executed, first completes the instruction execution, stores the instruction submission result in the data packet and sends it to the PL-side Parse module via XDMA (followed by normal instruction comparison events), and then NEMU stores the values ​​of all gpr, fpr and csr registers in the data packet, sets the data packet Extra_Information bit to IsRegCompare high, and sends it to the PL-side Parse module via XDMA. The Parse module parses the data packet, sets it to the RegCompare state, writes the data into the Diff_Tile for Reg data module, and sends a completion signal to the Control_Block module after all data are sent. Among them, RegCompare is the register comparison flag, which is used to mark the register comparison event of the processor, write the register value of the processor at this stage into the FIFO, and wait for the execution result of the receiving simulator to be compared.

[0118] While transmitting to the XsToNemu module, Control_Block transmits the register comparison event (DUT and REF comparison) to the Assign_Allreg module, which reads the values ​​of all registers and writes them into the Diff_TileforReg data module in multiple cycles. After writing, it sends a completion signal to the Control_Block module. Among them, the Assign_Allreg module is a module dedicated to register comparison, which is used to write the processor's register information into the FIFO_Diff_Tile in sequence for comparison.

[0119] When the Control_Block module receives that both DUT and NEMU have completed the input of register data, the register comparison event ends and the interrupt signal is cancelled.

[0120] Furthermore, when Diff_Tile (forreg or for commit) detects a comparison error, it sends an error signal to the Control_Block module. If the commit information is wrong, the wrong PC and the target PC and the instruction count are attached. If the reg information is wrong, the wrong register number, the wrong register value and the target register value, as well as the instruction count at this time are attached. Among them, Diff_Tile (forreg or forcommit) is a module in FIFO_Diff_Tile used to compare FIFO data, and is used to compare whether the data of the execution result of the storage processor and the data of the execution result of the simulator are consistent. If they are inconsistent, a comparison error message is output.

[0121] Optionally, the preset event includes a synchronization event, and a triggering condition of the synchronization event includes at least one of the following:

[0122] An external interrupt event occurs in the design under test;

[0123] The design under test operates abnormally;

[0124] A self-trap event occurs in the design under test;

[0125] The design under test executes atomic instructions;

[0126] The design under test accesses external devices on the hardware side.

[0127] Optionally, the method further comprises:

[0128] When the triggering condition of the synchronization event is met, the operation of the design to be tested is interrupted until a synchronization end signal is received from the software end, and then the operation of the design to be tested is resumed.

[0129] In an embodiment of the present invention, when the triggering condition of the synchronization event is met, the operation of the design to be tested is interrupted, and the state information of the design to be tested is sent to the software end through a data packet. The software end updates the state of the reference model according to the state information of the design to be tested, so that the reference model and the design to be tested maintain state synchronization. After the software end completes the state synchronization of the reference model, it sends a synchronization end signal to the hardware end. After the hardware end receives the synchronization end signal sent by the software end, it resumes the operation of the design to be tested.

[0130] by Figure 3For example, when the Control_Block module detects that the DUT encounters an event that requires synchronization (such as interruption, exception, self-trap, access to peripherals, atomic instruction events, etc.), it outputs an interrupt signal and enters the synchronization processing state. At this time, the relevant state of the DUT needs to be sent to the NEMU end and the corresponding synchronization processing function of the NEMU end is started. The Control_Block module detects the synchronization event and outputs the corresponding synchronization event number to the XsToNemu module. At the same time, it also outputs the number of instructions to be executed. The XsToNemu module reads the corresponding synchronization information from Syn_reg according to the synchronization event signal and forms a data packet, and sets the corresponding synchronization information bit. Among them, the Syn_reg signal is the information sent by the Control_Block module to indicate the event type of automatically generated data packets. After receiving the synchronization event, NEMU first executes the instruction according to the number of instructions to be executed and writes the result into the data packet. After that, NEMU extracts the synchronization information in the data packet and passes it into the synchronization processing function to update the relevant state in NEMU. After the processing is completed, the end state of the data packet is set, and the data packet is sent to the Parse module of the PL end through XDMA. The Parse module parses the data packet, generates a synchronization event end signal, and sends the signal to the Control_Block module. At the same time, it writes the execution result of the instruction in the data area of ​​the data packet into the FIFO_Tile. The Control_Block receives the synchronization event end signal, ends the interrupt signal, and the synchronization event ends.

[0131] In summary, an embodiment of the present invention provides a verification method, which performs collaborative verification on the design to be tested based on the hardware side and the software side. When the triggering condition of the preset event is met, a data packet is generated according to the first execution information of the design to be tested, and the data packet is sent to the software side. The software side drives the reference model to execute the same number of instructions according to the number of execution instructions in the data packet. The software side updates the second execution information of the reference model into the data packet and sends the data packet to the hardware side. The hardware side verifies the design to be tested based on the second execution information of the reference model by parsing the data packet. The embodiment of the present invention can trigger the verification of the design to be tested based on the preset event, which increases the visibility of the verification, facilitates the rapid positioning of the error position of the design to be tested, and is conducive to timely fine-grained debugging and inspection of the design to be tested. In addition, compared with software simulation verification, the embodiment of the present invention burns the design to be tested to the hardware side for operation, which improves the verification rate.

[0132] Reference Figure 4 , shows a flow chart of steps of an embodiment of a verification method of the present invention, the method is applied to a software end, the software end is connected to a hardware end through a bus interface, the hardware end includes a design to be tested, and the software end includes a reference model of the design to be tested; the method may specifically include the following steps:

[0133] Step 201, receiving a data packet sent by a hardware end; the data packet includes the number of execution instructions of the design to be tested;

[0134] Step 202: driving the reference model to execute the same number of instructions according to the number of executed instructions, and updating the data packet according to the second execution information of the reference model;

[0135] Step 203: Send the updated data packet to the hardware end.

[0136] The verification method provided in the embodiment of the present invention can be applied to the software end, and the software end is used to perform collaborative verification on the design to be tested with the hardware end. The hardware end includes the design to be tested, and the software end includes the reference model of the design to be tested.

[0137] Exemplarily, the hardware end may be an FPGA chip, and the design to be tested is deployed on the PL end of the FPGA chip.

[0138] Software and hardware need to communicate through a defined interaction structure, and the decoupling of software and hardware is achieved through interfaces. For example, for a CPU, the interface between software and hardware is the instruction set architecture ISA. The processor under the ISA is hardware, and the various programs, data sets, files, etc. above the instruction set are software.

[0139] The software end in the embodiment of the present invention refers to the program on the instruction set. The software end can be installed in a personal computer or in other electronic devices with an operating system and capable of running software. The electronic devices may include but are not limited to: smart terminals, computers, personal digital assistants, tablet computers, etc.

[0140] The hardware side and the software side communicate through data interfaces, such as PCIE interface, GPIO interface, and so on.

[0141] In an embodiment of the present invention, the design under test can be verified based on events. Specifically, during the process of executing the test program of the design under test, if the triggering condition of the preset event is met, a data packet is generated according to the first execution information of the design under test, and the data packet includes the number of execution instructions of the design under test. The hardware end sends the data packet to the software end.

[0142] The software end drives the reference model to execute the same number of instructions based on the number of execution instructions in the data packet, updates the second execution information of the reference model into the data packet, and sends the updated data packet to the hardware end.

[0143] The hardware side parses the updated data packet of the software side to obtain the second execution information of the reference model. Then, the first execution information of the design to be tested is compared with the second execution information of the reference model. If the first execution information does not match the second execution information, it can be determined that the design to be tested has an error.

[0144] The verification method provided by the embodiment of the present invention can trigger the verification of the design to be tested based on a preset event, thereby increasing the visibility of the verification, facilitating the rapid location of the error position of the design to be tested, and facilitating timely fine-grained debugging and inspection of the design to be tested. Moreover, compared with software simulation verification, the embodiment of the present invention burns the design to be tested to the hardware end for operation, thereby increasing the verification rate.

[0145] Optionally, the software end includes a data receiving program, a data sending program and a data processing program; the receiving of the data packet sent by the hardware end includes:

[0146] Step A11, the data receiving program receives the data packet sent by the hardware end, and writes the data packet into the shared memory when the data processing program is idle;

[0147] The step of driving the reference model to execute the same number of instructions according to the number of executed instructions, and updating the data packet according to the second execution information of the reference model, comprises:

[0148] Step A12, the data processing program obtains the data packet from the shared memory, and drives the reference model to execute the same number of instructions based on the number of execution instructions in the data packet, and updates the data packet according to the second execution information of the reference model;

[0149] Step A13, when the data sending program is idle, the data processing program writes the updated data packet into the shared memory;

[0150] The sending of the updated data packet to the hardware end includes:

[0151] Step A14: the data sending program obtains the updated data packet from the shared memory, and sends the updated data packet to the hardware end.

[0152] In the embodiment of the present invention, the software end can be divided into three independent programs according to the function, namely: a data receiving program, a data processing program and a data sending program. Among them, the data receiving program is used to receive data from the hardware end; the data processing program is used to parse and process the received data; and the data sending program is used to send the processing result of the data processing program (such as the second execution information of the reference model) to the hardware end.

[0153] The data receiving program, the data processing program and the data sending program implement data transmission through the shared memory. Specifically, after the data receiving program receives the data packet from the hardware end, the data packet is written into the shared memory when the data processing program is idle. The data processing program obtains the data packet from the shared memory, drives the reference model to execute the same number of instructions based on the number of execution instructions in the data packet, and updates the data packet according to the second execution information of the reference model, and then writes the updated data packet into the shared memory when the data sending program is idle. The data sending program obtains the updated data packet from the shared memory, and then sends the updated data packet to the hardware end, so that the hardware end can compare the first execution information of the design to be tested with the second execution information of the reference model.

[0154] It is understandable that, in the embodiment of the present invention, only one of the data receiving program and the data processing program can write to the shared memory at the same time. In other words, the data receiving program and the data processing program cannot write to the shared memory at the same time to avoid the data receiving program and the data processing program writing data to the shared memory at the same time, resulting in data errors (for example, the data receiving program and the data processing program change the same memory space in the shared memory at the same time, which will cause data errors). The data receiving program receives data packets from the hardware end, and when the data processing program is idle, the accumulated data packets are passed to the data processing program by writing the shared memory. It should be noted that in the process of the data processing program reading the data packets from the shared memory and driving the reference model to execute the test program, the data receiving program can continue to receive data from the hardware end, but it is not written to the shared memory temporarily, and the data is accumulated locally, and the accumulated data packets are written to the shared memory after the data processing program is idle.

[0155] Only one of the data processing program and the data sending program can perform a read operation or a write operation on the shared memory at the same time. In other words, when the data processing program writes data to the shared memory, the data sending program cannot read the data from the shared memory to avoid the data errors read by the data sending program due to the difference in the data order between the data processing program and the data sending program (for example, one program writes data sequentially, and the other program reads data in reverse order), the difference in instantaneous data rate (for example, the data writing frequency of the data processing program is 200Mhz, and the data reading frequency of the data sending program is 50Mhz), etc. The data processing program executes the instructions in the test program to obtain the second execution information, and updates the data packet according to the second execution information, and waits for the data sending program to be idle before writing the updated data packet to the shared memory. It should be noted that in the process of the data sending program reading the updated data packet from the shared memory, the data processing program can continue to execute the next data processing task, but temporarily does not write the result data to the shared memory, accumulates data locally, and waits until the data sending program is idle before writing the accumulated data to the shared memory.

[0156] Exemplarily, the hardware end generates a data packet according to the first execution information of the design to be tested under the trigger condition of meeting the preset event, and sends the data packet to the software end. The data receiving program of the software end receives the data packet from the hardware end. At this time, the data processing program and the data sending program are both in the initial state, that is, the idle state, and the data receiving program can directly write the data packet to the shared memory. The data processing program reads the data packet from the shared memory, and drives the reference model to execute the same number of instructions based on the number of execution instructions in the data packet, and updates the data packet according to the second execution information of the reference model. At this time, the data sending program is in an idle state, and the data processing program can write the updated data packet to the shared memory. After writing, the data processing program is in an idle state. The data sending program reads the updated data packet from the shared memory and sends the updated data packet to the hardware end. When the data processing program is in an idle state, the data receiving program continues to write new data packets received from the hardware end into the shared memory.

[0157] Optionally, the software end is mounted on an electronic device, and the electronic device further includes a communication driver; the data receiving program receives a data packet sent by the hardware end, including:

[0158] Step A21, the data receiving program receives a data packet from the hardware end through the communication driver;

[0159] The data sending program obtains the updated data packet from the shared memory and sends the updated data packet to the hardware end, including:

[0160] Step A22: the data sending program obtains the updated data packet from the shared memory, and sends the updated data packet to the hardware end through the communication driver.

[0161] The communication driver may include a software driver library (eg, an XDMA driver function library) and a hardware driver configuration, such as PCIE-XDMA.

[0162] Exemplarily, the hardware end (i.e., FPGA board) is connected to the PCIE card slot of the electronic device (i.e., PC) equipped with the software end. The hardware end uses the AXI-STREAM protocol interface to send data to the software end, and the data receiving program can interact with the hardware end through the XDMA driver function library to receive data packets from the hardware end. The updated data packet on the software end is returned to the hardware end by the data sending program through PCIE-XDMA, and the data is parsed by the parsing module on the hardware end and then written to the FIFO or passed to the hardware for processing. Among them, FIFO is the abbreviation of "First In, First Out", which is called "First In, First Out" in Chinese. It is a common queue data structure management method. In FIFO, the element that enters the queue first will be taken out first, and the element that enters the queue last will be taken out last, which is like the person in front of the queue will leave the queue first. This data structure can be used to simulate various actual scenarios, such as queuing, processing requests, etc. FIFO queues are often used to manage shared resources, process tasks, cache management, etc.

[0163] Optionally, the shared memory includes at least two memory partitions;

[0164] The data receiving program receives the data packet sent by the hardware end, and writes the data packet into the shared memory when the data processing program is idle, including:

[0165] Step A31, the data receiving program receives the data packet sent by the hardware end, and writes the data packet into a first memory partition when the data processing program is idle; the first memory partition is any idle memory partition in the shared memory;

[0166] The data processing program writes the updated data packet into the shared memory when the data sending program is idle, including:

[0167] Step A32: When the data sending program is idle, the data processing program writes the updated data packet into the second memory partition; the second memory partition is any idle memory partition in the shared memory.

[0168] In the embodiment of the present invention, the shared memory may be divided into a plurality of memory partitions, and the data receiving program, the data processing program and the data sending program may use the shared memory in turn by means of a ping-pong operation.

[0169] Specifically, the hardware end generates a data packet according to the first execution information of the design to be tested, and sends the data packet to the software end when the triggering condition of the preset event is met. The data receiving program of the software end first receives the data packet from the hardware end. At this time, the data receiving program, the data processing program and the data sending program are all in the initial state, that is, the idle state. After the data receiving program receives the data packet D1 from the hardware end, when the data processing program is idle, the data packet D1 is written to the first memory partition R1; the data processing program obtains the data packet D1 from the first memory partition R1, and drives the reference model to execute the same number of instructions based on the number of execution instructions in the data packet, and updates the data packet according to the second execution information of the reference model to obtain the updated data packet S1; at this time, the data sending program is in an idle state, and the data processing program writes the updated data packet S1 to the second memory partition R2. The data sending program obtains the updated data packet S1 from the second memory partition R2 and sends the updated data packet S1 to the hardware end.

[0170] It is understandable that when the data processing program writes the updated data packet S1 to the second memory partition R2, the data processing program is idle for the first memory partition R1, so the data receiving program can continue to write new data packets D2 to the first memory partition R1.

[0171] Through this ping-pong operation, the data receiving program and the data processing program can write data to the shared memory at the same time (write to different memory partitions), saving program waiting time and improving data transmission efficiency.

[0172] It should be noted that after all the data in a memory partition has been read, the memory partition can be cleared to allow new data to be written.

[0173] Furthermore, in the embodiment of the present invention, semaphores can be used to control the access of the data receiving program, the data processing program, and the data sending program to the shared memory. A semaphore is a synchronization mechanism in an operating system, which is used to control the access of multiple processes to shared resources. In the embodiment of the present invention, semaphores can be used to determine the occupancy of the shared memory and control the execution logic between multiple programs.

[0174] In summary, an embodiment of the present invention provides a verification method, which performs collaborative verification on a design to be tested based on a hardware end and a software end. After the software end receives a data packet sent by the hardware end, it drives the reference model to execute the same number of instructions according to the number of execution instructions in the data packet, updates the second execution information of the reference model into the data packet and sends the data packet to the hardware end. The hardware end verifies the design to be tested based on the second execution information of the reference model by parsing the data packet. An embodiment of the present invention can trigger the verification of the design to be tested based on a preset event, which increases the visibility of the verification, facilitates the rapid location of the error position of the design to be tested, and is conducive to timely fine-grained debugging and inspection of the design to be tested. Moreover, compared with software simulation verification, an embodiment of the present invention burns the design to be tested to the hardware end for operation, thereby improving the verification rate.

[0175] It should be noted that, for the sake of simplicity, the method embodiments are described as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0176] Device Embodiment

[0177] Reference Figure 5 , shows a structural block diagram of a verification device of the present invention, which is applied to a hardware end, wherein the hardware end includes a design to be tested, and the hardware end is connected to a software end via a bus interface, wherein the software end includes a reference model of the design to be tested; the device may specifically include:

[0178] The control module 501 is used to control the design to be tested to execute a test program and collect first execution information of the design to be tested;

[0179] The data packet generating module 502 is used to generate a data packet according to the first execution information of the design to be tested when the triggering condition of the preset event is met; the data packet includes the number of execution instructions of the design to be tested;

[0180] A sending module 503, configured to send the data packet to the software end, so that the software end drives the reference model to execute the same number of instructions based on the number of executed instructions, and updates the data packet according to the second execution information of the reference model;

[0181] A parsing module 504, configured to parse the updated data packet to determine the second execution information of the reference model;

[0182] A comparison module 505, configured to compare the first execution information with the second execution information;

[0183] The determination module 506 is used to determine that the design under test has an operation error when the first execution information and the second execution information do not match.

[0184] Optionally, the preset event includes an instruction comparison event; the triggering condition of the instruction comparison event includes: the number of instructions executed by the design to be tested is greater than or equal to a first threshold, and no synchronization event is detected.

[0185] Optionally, the comparison module includes:

[0186] A first writing submodule, used for writing first execution information of the design to be tested into a first queue;

[0187] A second writing submodule, used for writing second execution information of the reference model into a second queue;

[0188] A reading submodule, configured to read the first execution information recorded in the first queue and the second execution information recorded in the second queue after detecting that data is written to both the first queue and the second queue;

[0189] The first comparison submodule is configured to compare the first execution information with the second execution information.

[0190] Optionally, the preset event includes a register comparison event; and the data packet generation module includes:

[0191] The data packet generation submodule is used to generate a register comparison data packet according to the number of instructions executed by the design under test since the last register comparison event occurred, when it is detected that the number of instructions executed by the design under test since the last register comparison event occurred is greater than or equal to a second threshold.

[0192] Optionally, the hardware end further includes a register data module; the first execution information and the second execution information include a register value;

[0193] The comparison module comprises:

[0194] A third writing submodule, used for writing the first value of each register in the design to be tested into the register data module;

[0195] a fourth writing submodule, used for writing the second value of each register in the reference model into the register data module;

[0196] The second comparison submodule is used to compare the first value and the second value.

[0197] Optionally, the device further comprises:

[0198] The first interrupt control module is used to interrupt the operation of the design under test when it is detected that the number of instructions executed by the design under test since the last register comparison event is greater than or equal to a second threshold, and resume the operation of the design under test after the first value and the second value are all written into the register data module.

[0199] Optionally, the preset event includes a synchronization event, and a triggering condition of the synchronization event includes at least one of the following:

[0200] An external interrupt event occurs in the design under test;

[0201] The design under test operates abnormally;

[0202] A self-trap event occurs in the design under test;

[0203] The design under test executes atomic instructions;

[0204] The design under test accesses external devices on the hardware side.

[0205] Optionally, the device further comprises:

[0206] The second interrupt control module is used to interrupt the operation of the design to be tested when the triggering condition of the synchronization event is met, and resume the operation of the design to be tested after receiving the synchronization end signal from the software end.

[0207] Reference Figure 6 , shows a structural block diagram of another verification device of the present invention, which is applied to a software end, the software end is connected to a hardware end through a bus interface, the hardware end includes a design to be tested, and the software end includes a reference model of the design to be tested; the device includes:

[0208] The data packet receiving module 601 is used to receive a data packet sent by the hardware end; the data packet includes the execution instruction number of the design to be tested;

[0209] A data packet updating module 602, configured to drive the reference model to execute the same number of instructions according to the number of executed instructions, and update the data packet according to the second execution information of the reference model;

[0210] The data packet sending module 603 is used to send the updated data packet to the hardware end.

[0211] Optionally, the software end includes a data receiving program, a data sending program and a data processing program;

[0212] The data receiving program is used to receive the data packet sent by the hardware end, and write the data packet into the shared memory when the data processing program is idle;

[0213] The data processing program is used to obtain the data packet from the shared memory, and drive the reference model to execute the same number of instructions based on the number of execution instructions in the data packet, and update the data packet according to the second execution information of the reference model; when the data sending program is idle, write the updated data packet to the shared memory;

[0214] The data sending program is used to obtain the updated data packet from the shared memory and send the updated data packet to the hardware end.

[0215] Optionally, the shared memory includes at least two memory partitions; and the data receiving program is specifically used for:

[0216] receiving a data packet sent by the hardware end, and writing the data packet into a first memory partition when the data processing program is idle; the first memory partition is any idle memory partition in the shared memory;

[0217] The data processing program is specifically used for:

[0218] When the data sending program is idle, the updated data packet is written into the second memory partition; the second memory partition is any idle memory partition in the shared memory.

[0219] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0220] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0221] Regarding the processor in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0222] Reference Figure 7 , is a structural block diagram of an electronic device for verification provided by an embodiment of the present invention. Figure 7 As shown, the electronic device includes: a processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions enable the processor to execute the verification method of the aforementioned embodiment.

[0223] The processor may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other editable devices, transistor logic devices, hardware components or any combination thereof. The processor may also be a combination that implements a computing function, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0224] The communication bus may include a path to transmit information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The fact that only one line is used in the diagram does not mean that there is only one bus or only one type of bus.

[0225] The memory can be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it can be an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory), a magnetic tape, a floppy disk, an optical data storage device, etc.

[0226] The embodiment of the present invention also provides a non-temporary computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device (server or terminal), the processor is able to execute Figure 1 or Figure 4 The verification method shown.

[0227] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0228] It should be understood by those skilled in the art that the embodiments of the present invention can be provided as methods, devices or computer program products. Therefore, the embodiments of the present invention can take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, the embodiments of the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0229] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems) and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0230] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a predictable manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0231] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0232] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0233] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0234] The above is a detailed introduction to a verification method, device, electronic device and readable storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A verification method, characterized in that: Applied to a hardware end, the hardware end includes a design to be tested, the hardware end is connected to a software end via a bus interface, and the software end includes a reference model of the design to be tested; the method includes: Controlling the design to be tested to execute a test program and collecting first execution information of the design to be tested; When a trigger condition of a preset event is met, a data packet is generated according to the first execution information of the design to be tested; the data packet includes the number of execution instructions of the design to be tested; Sending the data packet to the software end, so that the software end drives the reference model to execute the same number of instructions based on the number of executed instructions, and updates the data packet according to the second execution information of the reference model; Parsing the updated data packet to determine second execution information of the reference model; comparing the first execution information with the second execution information; In the case where the first execution information and the second execution information do not match, determining that the design under test runs incorrectly; Wherein, the preset event is determined according to the processor behavior of the design to be tested, and the preset event includes at least one of an instruction comparison event, a register comparison event and a synchronization event; The software terminal includes a program on the instruction set, and the software terminal is installed in a personal computer, or in other electronic devices with an operating system that can run software; The method further comprises: The chip code of the design to be tested is analyzed, and a data transmission path pointing to the top-level module is added for each data interface of the design to be tested. Based on the data transmission path, the data transmitted by each data interface of the design to be tested is connected to the top-level module to extract the first execution information of the design to be tested from the top-level module and generate a data packet.

2. The method according to claim 1, characterized in that The preset event includes an instruction comparison event; the triggering condition of the instruction comparison event includes: the number of instructions executed by the design to be tested is greater than or equal to a first threshold, and no synchronization event is detected.

3. The method according to claim 2, characterized in that The comparing the first execution information with the second execution information includes: Writing first execution information of the design to be tested into a first queue; Writing second execution information of the reference model into a second queue; After detecting that data is written to both the first queue and the second queue, reading the first execution information recorded in the first queue and the second execution information recorded in the second queue; The first execution information is compared with the second execution information.

4. The method according to claim 1, characterized in that: The preset event includes a register comparison event; The step of generating a data packet according to the first execution information of the design to be tested when a trigger condition of a preset event is met includes: When it is detected that the number of instructions executed by the design under test since the last register comparison event occurs is greater than or equal to a second threshold, a register comparison data packet is generated according to the number of instructions executed by the design under test since the last instruction comparison event occurs.

5. The method according to claim 4, characterized in that The hardware end also includes a register data module; the first execution information and the second execution information include register values; The comparing the first execution information with the second execution information includes: Writing the first value of each register in the design to be tested into the register data module; Writing the second value of each register in the reference model into the register data module; The first value and the second value are compared.

6. The method according to claim 5, characterized in that The method further comprises: When it is detected that the number of instructions executed by the design under test since the last register comparison event occurs is greater than or equal to a second threshold, the operation of the design under test is interrupted until the first value and the second value are all written into the register data module, and then the operation of the design under test is resumed.

7. The method according to claim 1, characterized in that The preset event includes a synchronization event, and the triggering condition of the synchronization event includes at least one of the following: An external interrupt event occurs in the design under test; The design under test operates abnormally; A self-trap event occurs in the design under test; The design under test executes atomic instructions; The design under test accesses external devices on the hardware side.

8. The method according to claim 7, characterized in that The method further comprises: When the triggering condition of the synchronization event is met, the operation of the design to be tested is interrupted until a synchronization end signal is received from the software end, and then the operation of the design to be tested is resumed.

9. A verification method, characterized in that: Applied to a software end, the software end is connected to a hardware end through a bus interface, the hardware end includes a design to be tested, and the software end includes a reference model of the design to be tested; the method includes: Receiving a data packet sent by the hardware end; the data packet includes the number of execution instructions of the design to be tested; driving the reference model to execute the same number of instructions according to the number of executed instructions, and updating the data packet according to the second execution information of the reference model; Sending the updated data packet to the hardware end; Wherein, the data packet is generated by the hardware end according to the first execution information of the design to be tested when the trigger condition of the preset event is met; the preset event is determined according to the processor behavior of the design to be tested, and the preset event includes at least one of an instruction comparison event, a register comparison event and a synchronization event; the hardware end adds a data transmission path pointing to the top-level module for each data interface of the design to be tested, and connects the data transmitted by each data interface of the design to be tested to the top-level module based on the data transmission path, so as to extract the first execution information of the design to be tested from the top-level module and generate a data packet; The software end includes a program on the instruction set, and the software end is installed in a personal computer, or in other electronic devices with an operating system that can run software.

10. The method according to claim 9, characterized in that The software end includes a data receiving program, a data sending program and a data processing program; the receiving of the data packet sent by the hardware end includes: The data receiving program receives the data packet sent by the hardware end, and writes the data packet into the shared memory when the data processing program is idle; The step of driving the reference model to execute the same number of instructions according to the number of executed instructions, and updating the data packet according to the second execution information of the reference model, comprises: The data processing program obtains the data packet from the shared memory, and drives the reference model to execute the same number of instructions based on the number of execution instructions in the data packet, and updates the data packet according to the second execution information of the reference model; The data processing program writes the updated data packet into the shared memory when the data sending program is idle; The sending of the updated data packet to the hardware end includes: The data sending program obtains the updated data packet from the shared memory and sends the updated data packet to the hardware end.

11. The method according to claim 10, characterized in that The shared memory includes at least two memory partitions; The data receiving program receives the data packet sent by the hardware end, and writes the data packet into the shared memory when the data processing program is idle, including: The data receiving program receives the data packet sent by the hardware end, and writes the data packet into a first memory partition when the data processing program is idle; the first memory partition is any idle memory partition in the shared memory; The data processing program writes the updated data packet into the shared memory when the data sending program is idle, including: When the data sending program is idle, the data processing program writes the updated data packet into a second memory partition; the second memory partition is any idle memory partition in the shared memory.

12. A verification device, characterized in that: The device is arranged at a hardware end, wherein the hardware end includes a design to be tested, and the hardware end is connected to a software end via a bus interface, wherein the software end includes a reference model of the design to be tested; the device includes: A control module, used for controlling the design to be tested to execute a test program and collecting first execution information of the design to be tested; A data packet generating module, configured to generate a data packet according to the first execution information of the design to be tested when a trigger condition of a preset event is met; the data packet includes the number of execution instructions of the design to be tested; A sending module, used for sending the data packet to the software end, so that the software end drives the reference model to execute the same number of instructions based on the number of executed instructions, and updates the data packet according to the second execution information of the reference model; A parsing module, used to parse the updated data packet to determine the second execution information of the reference model; a comparing module, configured to compare the first execution information with the second execution information; A determination module, configured to determine that the design to be tested has an operation error when the first execution information and the second execution information do not match; Wherein, the preset event is determined according to the processor behavior of the design to be tested, and the preset event includes at least one of an instruction comparison event, a register comparison event and a synchronization event; The software terminal includes a program on the instruction set, and the software terminal is installed in a personal computer, or in other electronic devices with an operating system that can run software; The device also includes: A configuration module, wherein the configuration module is used to analyze the chip code of the design to be tested, add a data transmission path pointing to the top-level module for each data interface of the design to be tested, and connect the data transmitted by each data interface of the design to be tested to the top-level module based on the data transmission path, so as to extract the first execution information of the design to be tested from the top-level module, so as to enable the data packet generation module to generate a data packet.

13. A verification device, characterized in that: Applied to a software end, the software end is connected to a hardware end through a bus interface, the hardware end includes a design to be tested, and the software end includes a reference model of the design to be tested; the device includes: A data packet receiving module, used to receive a data packet sent by the hardware end; the data packet includes the number of execution instructions of the design to be tested; a data packet updating module, configured to drive the reference model to execute the same number of instructions according to the number of executed instructions, and to update the data packet according to the second execution information of the reference model; A data packet sending module, used for sending the updated data packet to the hardware end; Wherein, the data packet is generated by the hardware end according to the first execution information of the design to be tested when the trigger condition of the preset event is met; the preset event is determined according to the processor behavior of the design to be tested, and the preset event includes at least one of an instruction comparison event, a register comparison event and a synchronization event; the hardware end adds a data transmission path pointing to the top-level module for each data interface of the design to be tested, and connects the data transmitted by each data interface of the design to be tested to the top-level module based on the data transmission path, so as to extract the first execution information of the design to be tested from the top-level module and generate a data packet; The software end includes a program on the instruction set, and the software end is installed in a personal computer, or in other electronic devices with an operating system that can run software.

14. An electronic device, characterized in that: The electronic device comprises a processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store executable instructions, and the executable instructions enable the processor to execute the verification method according to any one of claims 1 to 8, or to execute the verification method according to any one of claims 9 to 11.

15. A readable storage medium, characterized in that: When the instructions in the readable storage medium are executed by a processor of an electronic device, the processor is enabled to execute the verification method as claimed in any one of claims 1 to 8, or execute the verification method as claimed in any one of claims 9 to 11.

Images