Verification method and apparatus, and electronic device, readable storage medium and program

Abstract

Provided in the embodiments of the present application are a verification method and apparatus, and an electronic device, a computer-readable storage medium and a computer program. The method comprises: controlling a design under test to execute a test program, and collecting first execution information of said design; when a trigger condition for a preset event is met, generating a data packet on the basis of the first execution information of said design, wherein the data packet comprises the number of executed instructions of said design; sending the data packet to a software end; parsing an updated data packet, and determining second execution information of a reference model; comparing the first execution information with the second execution information; and if the first execution information does not match the second execution information, determining that said design has encountered an error during operation. The embodiments of the present application improve the visibility of verification, such that an error position of a design under test can be rapidly determined, thereby facilitating the fine-grained debugging and inspection performed on said design in a timely manner.

Description

A verification method, apparatus, electronic device, readable storage medium, and program.

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411441664.1, filed on October 15, 2024, entitled "A verification method, apparatus, electronic device and readable storage medium", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computer technology, and in particular to a verification method, apparatus, electronic device, computer-readable storage medium, and computer program. Background Technology

[0004] Verification is the most time-consuming and challenging part of the processor development process, typically accounting for 50% to 70% of the development cycle. Therefore, more methods are needed to improve the agile verification capabilities of processor chips, further enhancing the efficiency and quality of processor chip development. Traditional verification methods mainly include software simulation and FPGA prototyping.

[0005] However, software simulation verification methods have relatively low performance. Their advantage lies in their high level of visualization, allowing for debugging through waveforms and breakpoints. But the main problem with this method is that the operating clock frequency can only reach a few kilohertz, and its performance is highly dependent on the specific simulation software, severely impacting verification efficiency.

[0006] FPGA prototyping is notoriously difficult to debug. While widely adopted in industry as a standard pre-silicon verification method, FPGA prototyping offers the advantage of eliminating the need for a simulation platform, allowing for direct implementation and verification of RTL designs on the FPGA. Its main characteristic is high speed, with operating frequencies reaching tens of megahertz. However, its primary drawback is weak debugging capabilities and low visibility of intermediate information during verification, hindering error localization and analysis. Summary of the Invention

[0007] This application provides a verification method, apparatus, electronic device, computer-readable storage medium, and computer program to solve problems in related technologies.

[0008] In a first aspect, embodiments of this application disclose a verification method applied to a hardware terminal, wherein the hardware terminal includes a design under test (DUT), the hardware terminal is connected to a software terminal via a bus interface, and the software terminal includes a reference model of the DUT; the method includes:

[0009] Control the design under test to execute the test program and collect the first execution information of the design under test;

[0010] When the triggering conditions of a preset event are met, a data packet is generated based on the first execution information of the design under test; the data packet includes the number of execution instructions of the design under test.

[0011] The data packet is sent to the software so that the software drives the reference model to execute the same number of instructions based on the number of execution instructions, and updates the data packet according to the second execution information of the reference model;

[0012] The updated data packet is parsed to determine the second execution information of the reference model;

[0013] Compare the first execution information with the second execution information;

[0014] If the first execution information and the second execution information do not match, it is determined that the design under test is malfunctioning.

[0015] Secondly, this application discloses another verification method applied to a software side. The software side is connected to a hardware side via a bus interface. The hardware side includes a design under test (DUT), and the software side includes a reference model of the DUT. The method includes:

[0016] Receive data packets sent by the hardware terminal; the data packets include the number of execution instructions of the design under test;

[0017] The reference model is driven to execute instructions with the same data according to the number of execution instructions, and the data packet is updated according to the second execution information of the reference model;

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

[0019] Thirdly, embodiments of this application disclose a verification device applied to a hardware end, wherein the hardware end includes a design under test (DUT), the hardware end is connected to a software end via a bus interface, and the software end includes a reference model of the DUT; the device includes:

[0020] The control module is used to control the design under test to execute the test program and collect the first execution information of the design under test;

[0021] A data packet generation module is used to generate a data packet based on the first execution information of the design under test when the triggering conditions of a preset event are met; the data packet includes the number of execution instructions of the design under test;

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

[0023] The parsing module is used to parse the updated data packet and determine the second execution information of the reference model;

[0024] The comparison module is used to compare the first execution information with the second execution information;

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

[0026] Fourthly, embodiments of this application provide another verification device applied to a software side. The software side is connected to a hardware side via a bus interface. The hardware side includes a design under test (DUT), and the software side includes a reference model of the DUT. The device includes:

[0027] A data packet receiving module is used to receive data packets sent by the hardware terminal; the data packets include the number of execution instructions of the design under test;

[0028] A data packet update module is used to drive the reference model to execute instructions with the same data according to the number of executed instructions, and to update the data packet according to the second execution information of the reference model;

[0029] The data packet sending module is used to send the updated data packet to the hardware terminal.

[0030] Fifthly, embodiments of this application also provide an electronic device, including a processor;

[0031] Memory used to store the processor's executable instructions;

[0032] The processor is configured to execute the instructions to implement the method.

[0033] In a sixth aspect, embodiments of this application also provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method of the first aspect.

[0034] In a seventh aspect, embodiments of this application provide a computer program including computer-readable code, which, when run on a computing processing device, causes the computing processing device to perform the method described thereon.

[0035] In this embodiment, collaborative verification of the design under test (DUT) is performed on both hardware and software. When a preset event trigger condition is met, a data packet is generated based on the first execution information of the DUT and sent to the software. The software then drives the reference model to execute the same number of instructions based on the number of execution instructions in the data packet. The software updates the data packet with the second execution information of the reference model and sends the data packet to the hardware. The hardware parses the data packet and verifies the DUT based on the second execution information of the reference model. This embodiment can trigger the verification of the DUT based on preset events, increasing the visibility of the verification and facilitating rapid location of errors in the DUT. This allows for timely fine-grained debugging and inspection of the DUT. Furthermore, compared to software simulation verification, this embodiment burns the DUT onto the hardware for execution, improving the verification speed.

[0036] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 is a flowchart of the steps of an embodiment of the verification method of this application;

[0039] Figure 2 is a schematic diagram of a data packet format according to this application;

[0040] Figure 3 is a schematic diagram of communication between the hardware and software sides of this application;

[0041] Figure 4 is a flowchart of another verification method embodiment of this application;

[0042] Figure 5 is a structural block diagram of an embodiment of the verification device of this application;

[0043] Figure 6 is a structural block diagram of another embodiment of the verification device of this application;

[0044] Figure 7 is a structural block diagram of an electronic device for verification provided in this application example. Specific Implementation

[0045] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0046] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0047] Referring to Figure 1, a flowchart of an embodiment of the verification method of this application is shown. The method is applied to a hardware terminal, which is connected to a software terminal via a bus interface. The software terminal includes a reference model of the design under test. The method may specifically include the following steps:

[0048] Step 101: Control the design under test to execute the test program and collect the first execution information of the design under test;

[0049] Step 102: Under the condition that the preset event triggering condition is met, generate a data packet according to the first execution information of the design under test; the data packet includes the number of execution instructions of the design under test;

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

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

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

[0053] Step 106: If the first execution information and the second execution information do not match, determine that the design under test is running incorrectly.

[0054] The verification method provided in this application can be applied to the hardware side, which is used to perform collaborative verification of the Design Under Test (DUT) with the software side. The hardware side includes the DUT, and the software side includes a reference model of the DUT.

[0055] For example, the hardware in this application may be a Field Programmable Gate Array (FPGA), and the design under test is deployed in the Programmable Logic (PL) area of ​​the FPGA chip.

[0056] It's important to note that an 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 to adapt to different applications and functions according to user needs. An FPGA consists of a large number of programmable logic blocks and programmable interconnect resources. Programmable logic blocks typically consist of look-up tables (LUTs), registers, and other logic elements, capable of performing various logical functions. Programmable interconnect resources are used to connect the logic blocks to form the desired circuit structure. Using FPGAs, design engineers can describe the required circuit functions using hardware description languages ​​and translate them into a bitstream compatible with the FPGA chip using programming tools. The bitstream contains information for programming and configuring the FPGA's internal logic and interconnect resources. One of the main advantages of FPGAs is their programmability and flexibility. It allows design engineers to implement custom functions and algorithms at the hardware level without the need for traditional custom integrated circuit design and manufacturing processes. This makes FPGAs play a crucial role in prototyping and rapid design iteration.

[0057] Design Under Test (DUT) refers to the circuit design or implementation to be tested during prototype verification. For example, a DUT can be a Register Transfer Level (RTL) circuit or other hardware designs. It's important to note that RTL circuits are a common type of hardware description level circuit. RTL circuits describe the behavior and structure of digital circuits and are represented using the register transfer level abstraction. RTL circuit descriptions are typically written using Hardware Description Languages ​​(HDLs), such as VHDL (VHSIC Hardware Description Language), Verilog HDL, or System Verilog HDL. Designers can use RTL-level descriptions to define and implement the desired digital circuit functionality, and then use synthesis tools to translate the RTL-level description into a physical implementation in a Field-Programmable Gate Array (FPGA).

[0058] A reference model is used to implement the same functionality as the design under test (DUT). During the verification process of the DUT, the data generated when the reference model is invoked is assumed to be correct and is used as reference data for comparison with the data generated by the DUT. Understandably, different reference models are generated for different DUTs. As an example, before performing high-level synthesis on the DUT, a source design model of the DUT can be generated based on the DUT's C / C++ design code. This source design model has the same algorithmic functionality as the DUT and can serve as a reference model for the DUT.

[0059] Software and hardware need to communicate through a defined interaction structure, achieving decoupling between them through interfaces. For example, for a CPU, the interface between software and hardware is the Instruction Set Architecture (ISA). The processor below the ISA is the hardware, while the various programs, datasets, files, etc., above the instruction set are the software.

[0060] In this application embodiment, the software refers to the program on top of the instruction set. The software can be installed on a personal computer (PC) or on 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.

[0061] The hardware and software communicate through data interfaces, such as the Peripheral Component Interconnect Express (PCIE) interface, General Purpose Input Output (GPIO), and so on.

[0062] It should be noted that the intermediate data generated during the operation of the design under test, as well as some signal values ​​or status values ​​that need to be verified, are usually invisible. If verification is only based on the final output of the design under test, it is impossible to report errors in a timely manner and it is difficult to locate the error location, which is not conducive to debugging the design under test.

[0063] In this embodiment, the design under test can be verified based on events. Specifically, during the execution of the test program by the design under test, if the triggering conditions of a preset event are met, a data packet is generated based on the first execution information of the design under test. This data packet contains the number of execution instructions of the design under test. The hardware sends this data packet to the software.

[0064] The software side 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 side.

[0065] The hardware parses the updated data packets from the software to obtain the second execution information of the reference model. Then, it compares the first execution information of the design under test with the second execution information of the reference model. If the first and second execution information do not match, it can be determined that the design under test is malfunctioning.

[0066] The verification method provided in this application can trigger the verification of the design under test based on preset events, increasing the visibility of the verification and facilitating the rapid location of errors in the design under test. This is beneficial for timely fine-grained debugging and inspection of the design under test. Furthermore, compared to software simulation verification, this application embodiment burns the design under test to the hardware for execution, improving the verification speed.

[0067] It's important to note that before programming the design under test (DUT) onto the FPGA chip, the chip code can be modified to connect the data transmitted from each data interface of the DUT to its top-level module. This allows for the collection of intermediate data and execution information during the DUT's operation. Specifically, the chip code can be analyzed, and a data transmission path pointing to the top-level module can be added to each data interface of the DUT. This allows the data transmitted from each data interface to be connected to the top-level module without altering the original operating logic of the DUT, enabling external modules or components (such as control or monitoring modules in the hardware) to access the data. The top-level module is the module containing all other modules in the DUT and is not instantiated within any other module. After connecting the data from the DUT to the top-level module, the data to be verified can be extracted from the top-level module, generated into a data packet, and sent to the software to drive the reference model to execute the test program.

[0068] Preset events can be determined based on the processor behavior of the design under test (DUT). For example, taking a processor with frequent out-of-order execution as an example, processor behavior can be abstracted as: instruction comparison events (instruction execution result comparison events), register comparison events, comparison error events, exception events, external interrupt events, trap events, atomic instruction events, and peripheral access events. Instruction comparison events refer to comparing the instruction execution results between the DUT and the reference model. Register comparison events refer to comparing the values ​​of various registers in the DUT and the reference model. Comparison error events include at least one of the following: an error in comparing the instruction execution results between the DUT and the reference model, or an error in comparing register values. Exception events refer to abnormal events that occur during the execution of the DUT, interrupting the normal instruction execution flow. In the field of chip design, exception events in the DUT typically include hardware execution exceptions or software faults. An exception received after the processor has executed an instruction triggers the processor to execute a dedicated exception handling procedure. External interrupt events refer to the interruption of the design-under-test (DUT) operation caused by input signals from outside the DUT. For example, an external interrupt event could be caused by an error in the DUT's operation, where the interrupt module in the hardware sends an interrupt signal to the DUT, leading to an interruption. After receiving the interrupt signal from the external hardware, the processor needs to respond to the input interrupt. A trap event is a pre-arranged exception event, like a pre-set "trap." When the processor executes a trap instruction, it automatically performs corresponding processing according to different trap types and then returns to the next instruction after the trap instruction (if the trap instruction is a jump instruction, it returns to the jump target instruction). An atomic instruction event refers to the processor locking the accessed memory space to prevent other hardware from accessing it, ensuring that the processor's running program can access data synchronously through multiple threads. A peripheral access event refers to the DUT accessing external devices. These external devices are devices mounted on the FPGA chip that are neither part of the PL nor the PS side, such as Double Data Rate Synchronous Dynamic Random Access Memory (DDR).

[0069] For example, the preset event in the embodiments of this application may include at least one of the instruction comparison event and the register comparison event.

[0070] In this embodiment, different events can trigger the generation of different data packets. The data packets corresponding to the eight events in the above example can adopt a unified data packet format. As an example, referring to FIG2, a schematic diagram of a data packet format provided by an embodiment of this application is shown. As shown in FIG2, the data packet can be divided into a metadata segment describing packet information and a data segment containing specific data. Bits 0-63 of the data packet are the metadata segment, and the subsequent Data1, Data2, etc. fields are the data segment.

[0071] The metadata segment contains basic information about the data packet, and the fields are described 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 valid event information; the Data_len field indicates how much data is in the data area of ​​this data packet. This field exists to avoid interference from some transmission characteristics of the software side on data transmission.

[0072] The data segment contains the specific information that needs to be synchronized during the event. The size of the data segment is determined by the Data_Size subfield within the Extra_Information field. This field determines how many 64 bits each piece of data occupies; when the Data_Size field is 1 (the default), each piece of data occupies 64 bits.

[0073] Different types of data packets are distinguished using Extra_Information. Assuming a data packet size of 512 bits, a single transmission can be divided into eight 64-bit data segments. DATA1 is used to mark the category information of the event packet, and the remaining seven DATA segments record the information that each event needs to be synchronized to the simulator. The specific design of Extra_Information is as follows:

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

[0075] [0]IsNormalCommit: 1 bit, is the normal command commit event flag;

[0076] [1]IsRegCompare: 1 bit, is the register comparison event flag;

[0077] [2]IfDiffError: 1 bit, is the comparison error event flag bit;

[0078] [3]IsArchEvent: 1 bit, which is the ARCH event flag;

[0079] [4]IsTrapEvent: 1 bit, which is the TRAP event flag;

[0080] [5]IsLrScEvent: 1 bit, which is the atomic event flag bit;

[0081] [6]IsMMIOEvent: 1 bit, which is the MMIO event flag;

[0082] [7:9]DataSize:3bit, the default size of each data item is 64.

[0083] Data1 stores the number of instructions to be executed, while DATA2 to DATA7 are used to record simulator execution results. This data packet depends on Data_Len to record the number of information transmitted back to the FPGA.

[0084] NEMU->XS refers to the information of the marked simulator execution result passed from the simulator to the FPGA, and the specific format is as follows:

[0085] [0]IsNormalCommit:1bit

[0086] [1]IsRegCompare:1bit

[0087] [2]DiffError_Done:1bit

[0088] [3]ArchEvent_Done:1bit

[0089] [4]TrapEvent_Done:1bit

[0090] [5]LrScEvent_Done:1bit

[0091] [6]MMIOEvent_Done:1bit

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

[0093] If the data packet format needs to be modified, additional event handling rules are added on the hardware side, and corresponding logic is adapted on the software side.

[0094] In this embodiment, the hardware and software interact via data packets. For example, when a preset event trigger condition is met, the hardware generates a data packet based on the first execution information of the design under test (DUT), indicating the number of execution instructions to the software within the data packet. Upon receiving the data packet, the software parses it, drives the reference model to execute the same number of instructions based on the execution instruction count, writes the second execution information of the reference model into the data packet, and sends the updated data packet to the hardware. The hardware parses the data packet to determine the second execution information of the reference model, and then verifies the first execution information of the DUT based on this second execution information. If the two do not match, it can be determined that the DUT is malfunctioning.

[0095] It should be noted that the test program executed by the design under test and the reference model is the same, so the order of instructions executed by the two is the same. When the design under test and the reference model execute the same number of instructions each time, it can be ensured that the first execution information of the design under test and the second execution information of the reference model are synchronized, avoiding inaccurate verification results due to the asynchrony between the first and second execution information, and ensuring the accuracy of the verification results.

[0096] The content of the first and second execution information can be determined based on the data to be verified in the design under test. For example, the first and second execution information may include the values ​​of all General Purpose Registers (GPRs), the Control and Status Register (CSR), the Program Counter (PC), instruction execution results, and so on. In practical applications, the specific content of the first and second execution information can be specified according to the actual situation and specific verification requirements. Taking a RISC-V processor as an example, during comparison, the 32 GPR registers, 18 CSR registers, and PC values ​​can be compared.

[0097] The first execution information of the design under test 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 the design under test has no error. At this time, the design under test can be controlled to continue to execute the next instruction.

[0098] If the first execution information and the second execution information do not match—for example, if they are not the same, or if the value of a parameter in the first execution information does not fall within the range of the corresponding parameter in the second execution information—then the design under test can be considered to be malfunctioning. In this case, a snapshot of the entire hardware can be taken to save its state information, and the saved data can be sent to the software for display. This allows verification engineers to use the saved state information to troubleshoot on-site.

[0099] In one possible application scenario of this application, snapshot information from the hardware can be imported into simulation software on the software side, and the simulation software can be used to perform fine-grained debugging of the design under test.

[0100] Optionally, the preset event includes an instruction comparison event; the triggering conditions for the instruction comparison event include: the number of instructions executed by the design under test is greater than or equal to a first threshold, and no synchronization event is detected.

[0101] Synchronization events refer to the need to synchronize the state of the design under test (DUT) and the reference model. For example, when an abnormal event, external interrupt event, trap event, atomic instruction event, or peripheral access event occurs in the DUT, the DUT and the reference model need to be synchronized, which triggers a synchronization event.

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

[0103] Step S11: Write the first execution information of the design under test into the first queue;

[0104] Step S12: Write the second execution information of the reference model into the second queue;

[0105] Step S13: After detecting that data has been written to both the first queue and the second queue, read the first execution information recorded in the first queue and the second execution information recorded in the second queue;

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

[0107] In this embodiment, a queue can be configured on the hardware side for writing execution information to the design under test and the reference model, respectively. Specifically, the first execution information of the design under test is written to a first object, and the second execution information of the reference model is written to a second queue. After detecting that data has been written to both the first and second queues, the execution information recorded in the two queues is read and compared.

[0108] Referring to Figure 3, a communication diagram of a hardware and software side provided in an embodiment of this application is shown. As shown in Figure 3, Xs_Top is the processor hardware deployed on the FPGA; XDMA is the hardware module for transferring data between the PC and the FPGA; the Handle_Break module is the hardware module used to filter invalid data in the processor input information; the Assign_Commit module is the hardware module for processing processor instruction submission data; the Parse module is used to parse the information transmitted from the simulator on the PC to the modules on the FPGA via XDMA, and write the parsed data into the corresponding FIFO_Diff_Tile for comparison; the Control_Block module is the hardware module that controls the execution order of other modules according to the processor input information; 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 Control_Block and generate control signals for the processor's operation; the Interruption_logic module is used to receive the Gen_Break signal to control the processor clock; and the FIFO_Diff_Tile is a set of symmetrical FIFOs on the left and right sides. When data is written into the FIFO, it is automatically compared, and an error is reported when an error occurs.

[0109] Assume the hardware is the PL (Programmer) side of the FPGA and the software is the NEMU. For an instruction comparison event, Xs_Top executes T instructions, which are written to the FIFO Tile (first queue) on the DUT side after passing through the Handle_Break and Assign_Commit modules. If no synchronization event is encountered, execution continues. If 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, raising control_valid, setting IsNormalCommit = 0, and execute_instr = T. Upon receiving the instruction comparison event, the XsToNemu module generates a data packet and sends it to the software, such as the NEMU. The NEMU receives the data packet (this may require two processes using shared space to maintain the number of instructions to be executed in the NEMU), executes the program according to the instruction count, and stores the instruction execution results into the data packet. After execution, the data packet is sent to the Parse module on the PL side via XDMA. The Parse module parses data packets, parses the header, sets relevant parameters, and sends the parsed data of each frame to the port, writing it to the FIFO_Tile. With an AXI_Stream width (a hardware transmission protocol limiting the data bit width of the XDMA module) of 512 bits, a maximum of 8 data packets are passed in at a time. The data packets are written to the corresponding NEMU-side FIFO (the second queue) according to the last three bits of the instruction counter. The Diff_Tile detects data in both FIFOs, reads the data, compares it, and outputs the comparison result and the number of comparison instructions to the Control_Block module. If the comparison is correct, execution continues; if an error occurs, the instruction counter value, PC value, and other information of the erroneous instruction are output, along with the correct value, to the XsToNemu module. The data packet is then sent to the software for processing, displaying the location of the error to the user. When the execution results of the simulator and the processor are found to be unequal, the erroneous data value and the correct value are sent to the XsToNemu module, which then sends the relevant information about the comparison error to the simulator for notification.

[0110] The FIFO_Diff_Tile consists of two FIFOs and a comparison unit, with a hardware mapping of NEMU_FIFO_Tile——DIFF——XS_FIFOTile. The FIFO_Tile records the execution information that the processor needs to compare. The DIFF module automatically compares whether the data in the FIFOs are equal.

[0111] Optionally, the preset event includes a register comparison event; the step of generating a data packet based on the first execution information of the design under test when the triggering condition of the preset event is met includes:

[0112] If the number of instructions executed by the design under test since the last register compare event is greater than or equal to a second threshold, a register compare data packet is generated based on the number of instructions executed by the design under test since the last instruction compare event.

[0113] Optionally, the hardware further includes a register data module; the first execution information and the second execution information include register values. The comparison of the first execution information and the second execution information includes:

[0114] Step S21: Write the first value of each register in the design under test into the register data module;

[0115] Step S22: Write the second values ​​of each register in the reference model into the register data module;

[0116] Step S23: Compare the first value and the second value.

[0117] In this embodiment of the application, a register data module, such as the Diff_Tile for Reg data module, can be allocated in the hardware. When the triggering condition of the register comparison event is met, the first value of each register in the design under test and the second value of each register in the reference model are written into the register data module for comparison.

[0118] Optionally, the method further includes:

[0119] If the number of instructions executed by the design under test since the last register comparison event is greater than or equal to the second threshold, the operation of the design under test is interrupted until both the first value and the second value are written to the register data module, and then the operation of the design under test is resumed.

[0120] In this embodiment of the application, 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 both written to the register data module, the operation of the design under test can be resumed. This is to avoid the design under test continuing to execute instructions to update the value of the register, which would cause the register state of the design under test to be out of sync with the register state of the reference model.

[0121] Taking Figure 3 as an example, for register comparison events, when the Control_Block module detects that S instructions have passed since the last register value comparison event, it outputs an interrupt signal to stop the execution of the DUT. Simultaneously, it counts the number of instructions since the last instruction comparison event and transmits this count to the XsToNemu module. The XsToNemu module receives the register comparison event, sets the corresponding information bits in the data packet, and puts the number of instructions to be executed into Data1. The NEMU receives the data packet, parses out the instructions to be executed, executes the instructions, 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). Then, the NEMU stores the values ​​of all gpr, fpr, and csr registers in the data packet, sets the Extra_Information bit of the data packet 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 has been sent. RegCompare is a register comparison flag used to mark a processor register comparison event, write the processor's register values ​​at this stage into the FIFO, and wait to receive the simulator's execution results for comparison.

[0122] While transmitting data to the XsToNemu module, Control_Block also transmits register comparison events (DUT and REF comparison) to the Assign_Allreg module. This module reads the values ​​of all registers and writes them into the Diff_Tile for Reg data module over multiple cycles. After writing, it sends a completion signal to the Control_Block module. The Assign_Allreg module is dedicated to handling register comparisons, used to sequentially write the processor's register information into the FIFO_Diff_Tile for comparison.

[0123] When the Control_Block module receives confirmation that both the DUT and NEMU have completed the input of register data, it ends the register comparison event and cancels the interrupt signal.

[0124] Furthermore, when Diff_Tile (for reg or for commit) detects a comparison error, it sends an error signal to the Control_Block module. If the commit message has an error, it includes the error's PC, the target PC, and the instruction count. If the reg message has an error, it includes the error's register number, the error's register value, the target register value, and the current instruction count. Diff_Tile (for reg or for commit) is the module within FIFO_Diff_Tile used to compare FIFO data. It compares the data storing the processor's execution results with the data storing the simulator's execution results; if they are inconsistent, it outputs a comparison error message.

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

[0126] The design under test sends an external interrupt event;

[0127] The design under test is malfunctioning;

[0128] The design under test has encountered a self-trapping event;

[0129] The design under test executes atomic instructions;

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

[0131] Optionally, the method further includes:

[0132] If the triggering conditions of the synchronization event are met, the operation of the design under test is interrupted until a synchronization end signal is received from the software, at which point the operation of the design under test is resumed.

[0133] In this embodiment, when the triggering condition of the synchronization event is met, the operation of the design under test (DUT) is interrupted, and the state information of the DUT is sent to the software via data packets. The software then updates the state of the reference model based on the DUT's state information, ensuring that the reference model and the DUT remain synchronized. After completing the synchronization of the reference model's state, the software sends a synchronization termination signal to the hardware. Upon receiving the synchronization termination signal from the software, the hardware resumes the operation of the DUT.

[0134] Taking Figure 3 as an example, when the Control_Block module detects that the DUT encounters an event requiring synchronization (such as an interrupt, exception, trap, peripheral access, atomic instruction event, 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 and the corresponding synchronization processing function on the NEMU side needs to be 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 assembles it into a data packet, setting the corresponding synchronization information bits. Among them, the Syn_reg signal is a message issued by the Control_Block module to indicate the event type for automatically generating data packets. The NEMU receives the synchronization event, first executes the instructions according to the number of instructions to be executed and writes the result into the data packet. Then, the NEMU extracts the synchronization information from the data packet and passes it to the synchronization processing function to update the relevant state in the NEMU. After processing, the data packet end state is set, and the data packet is sent to the Parse module on the PL side via XDMA. The Parse module parses the data packet, generates a synchronization event end signal, and sends this 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. When Control_Block receives the synchronization event end signal, it terminates the interrupt signal, and the synchronization event ends.

[0135] In summary, this application provides a verification method that collaboratively verifies the design under test (DUT) using both hardware and software. When a preset event trigger condition is met, a data packet is generated based on the first execution information of the DUT and sent to the software. The software then drives a reference model to execute the same number of instructions based on the number of execution instructions in the data packet. The software updates the data packet with the second execution information of the reference model and sends the data packet to the hardware. The hardware parses the data packet and verifies the DUT based on the second execution information of the reference model. This application allows verification of the DUT to be triggered based on preset events, increasing the visibility of the verification and facilitating rapid location of errors in the DUT. This enables timely fine-grained debugging and inspection of the DUT. Furthermore, compared to software simulation verification, this application burns the DUT onto the hardware for execution, improving the verification speed.

[0136] Referring to Figure 4, a flowchart of an embodiment of the verification method of this application is shown. The method is applied to a software side, which is connected to a hardware side via a bus interface. The hardware side includes a design under test (DUT), and the software side includes a reference model of the DUT. The method may specifically include the following steps:

[0137] Step 201: Receive the data packet sent by the hardware terminal; the data packet includes the number of execution instructions of the design under test;

[0138] Step 202: Drive the reference model to execute instructions with the same data according to the number of execution instructions, and update the data packet according to the second execution information of the reference model;

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

[0140] The verification method provided in this application can be applied to the software side, which is used to perform collaborative verification of the design under test (DUT) with the hardware side. The hardware side includes the DUT, and the software side includes a reference model of the DUT.

[0141] For example, the hardware can be an FPGA chip, and the design under test is deployed on the PL side of the FPGA chip.

[0142] Software and hardware need to communicate through a defined interaction structure, achieving decoupling between them through interfaces. For example, for a CPU, the interface between software and hardware is the Instruction Set Architecture (ISA). The processor below the ISA is the hardware, while the various programs, datasets, files, etc., above the instruction set are the software.

[0143] In this application embodiment, the software refers to a program on top of an instruction set. The software can be installed on a personal computer or on 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, tablet computers, etc.

[0144] The hardware and software communicate through data interfaces, such as PCIe interfaces, GPIO interfaces, and so on.

[0145] In this embodiment, the design under test can be verified based on events. Specifically, during the execution of the test program by the design under test, if the triggering conditions of a preset event are met, a data packet is generated based on the first execution information of the design under test. This data packet contains the number of execution instructions of the design under test. The hardware sends this data packet to the software.

[0146] The software side 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 side.

[0147] The hardware parses the updated data packets from the software to obtain the second execution information of the reference model. Then, it compares the first execution information of the design under test with the second execution information of the reference model. If the first and second execution information do not match, it can be determined that the design under test is malfunctioning.

[0148] The verification method provided in this application can trigger the verification of the design under test based on preset events, increasing the visibility of the verification and facilitating the rapid location of errors in the design under test. This is beneficial for timely fine-grained debugging and inspection of the design under test. Furthermore, compared to software simulation verification, this application embodiment burns the design under test to the hardware for execution, improving the verification speed.

[0149] Optionally, the software includes a data receiving program, a data sending program, and a data processing program; receiving the data packets sent by the hardware includes:

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

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

[0152] Step A12: The data processing program retrieves the data packet from the shared memory, drives the reference model to execute instructions with the same data 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;

[0153] Step A13: When the data sending program is idle, the data processing program writes the updated data packet into the shared memory;

[0154] Sending the updated data packet to the hardware includes:

[0155] Step A14: The data sending program retrieves the updated data packet from the shared memory and sends the updated data packet to the hardware.

[0156] In this embodiment, the software can be divided into three independent programs according to their functions: a data receiving program, a data processing program, and a data sending program. The data receiving program receives data from the hardware; the data processing program parses and processes the received data; and the data sending program sends the processing results (e.g., the second execution information of the reference model) from the data processing program to the hardware.

[0157] The receiving program, data processing program, and data sending program transmit data through shared memory. Specifically, after receiving a data packet from the hardware, the receiving program writes the data packet to shared memory when the data processing program is idle. The data processing program retrieves the data packet from shared memory, drives the reference model to execute the same number of instructions based on the number of instructions in the data packet, updates the data packet according to the second execution information of the reference model, and then writes the updated data packet to shared memory when the sending program is idle. The sending program retrieves the updated data packet from shared memory and then sends the updated data packet to the hardware so that the hardware can compare the first execution information of the design under test with the second execution information of the reference model.

[0158] It is understood that, in this embodiment, only one of the data receiving program and the data processing program can perform write operations on the shared memory at any given time. In other words, the data receiving program and the data processing program cannot perform write operations on the shared memory simultaneously to avoid data errors caused by both programs writing data to the shared memory at the same time (for example, if the data receiving program and the data processing program simultaneously modify the same memory space in the shared memory, it will lead to data errors). The data receiving program receives data packets from the hardware and then, when the data processing program is idle, writes the accumulated data packets to the shared memory to transmit the data packets to the data processing program. It should be noted that while the data processing program is reading 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, but it will not write the data to the shared memory temporarily. Instead, it will accumulate the data locally and write the accumulated data packets to the shared memory when the data processing program becomes idle.

[0159] Only one program, either the data processing program or the data sending program, can perform read or write operations on the shared memory at any given time. In other words, when the data processing program writes data to the shared memory, the data sending program cannot read data from it. This is to avoid errors caused by differences in data order between the two programs (e.g., one program writes data sequentially while the other reads it in reverse order) or differences in instantaneous data rates (e.g., the data processing program writes data at 200MHz while the data sending program reads data at 50MHz). The data processing program executes the instructions in the test program to obtain the second execution information and updates the data packet based on this information. It then waits for the data sending program to become idle before writing the updated data packet to the shared memory. It should be noted that while the data sending program is reading the updated data packet from the shared memory, the data processing program can continue executing the next data processing task, but it will not write the result data to the shared memory immediately. Instead, it will accumulate the data locally until the data sending program becomes idle, at which point it will write the accumulated data to the shared memory.

[0160] For example, under the triggering condition of a preset event, the hardware generates a data packet based on the first execution information of the design under test and sends the data packet to the software. The receiving program on the software receives the data packet from the hardware. At this time, both the data processing program and the sending program are in the initial state, i.e., the idle state. The receiving program can directly write the data packet to shared memory. The data processing program reads the data packet from 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, updating the data packet according to the second execution information of the reference model. At this time, the sending program is in the idle state. The data processing program can write the updated data packet to shared memory. After writing, the data processing program is in the idle state. The sending program reads the updated data packet from shared memory and sends the updated data packet to the hardware. While the data processing program is in the idle state, the receiving program continues to write new data packets received from the hardware to shared memory.

[0161] Optionally, the software is mounted on an electronic device, which further includes a communication driver; the data receiving program receives data packets sent by the hardware, including:

[0162] Step A21: The data receiving program receives data packets from the hardware terminal through the communication driver;

[0163] The data transmission program retrieves the updated data packet from the shared memory and sends the updated data packet to the hardware, including:

[0164] Step A22: The data sending program retrieves the updated data packet from the shared memory and sends the updated data packet to the hardware terminal through the communication driver.

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

[0166] For example, the hardware (i.e., the FPGA board) is connected to the PCIe slot of an electronic device (i.e., a PC) with software. The hardware sends data to the software using the AXI-STREAM protocol interface. The receiving program can interact with the hardware through the XDMA driver library to receive data packets from the hardware. Updated data packets from the software are returned to the hardware by the sending program via PCIe-XDMA. The hardware's parsing module then parses the data and writes it to the FIFO or passes it to the hardware for processing. FIFO stands for "First In, First Out," a common queue data structure management method. In FIFO, the first element to enter the queue is the first to be removed, and the last element to enter the queue is the last to be removed, just like someone at the front of the queue leaves first. This data structure can be used to simulate various real-world scenarios, such as queuing and request processing. FIFO queues are commonly used for managing shared resources, processing tasks, and cache management.

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

[0168] The data receiving program receives data packets sent by the hardware terminal, and when the data processing program is idle, writes the data packets into shared memory, including:

[0169] Step A31: The data receiving program receives the data packet sent by the hardware terminal, and when the data processing program is idle, writes the data packet into the first memory partition; the first memory partition is any free memory partition in the shared memory.

[0170] When the data sending program is idle, the data processing program writes the updated data packet to the shared memory, including:

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

[0172] In this embodiment of the application, the shared memory can be divided into multiple memory partitions, and the data receiving program, data processing program and data sending program can take turns using the shared memory in a ping-pong operation.

[0173] Specifically, under the triggering conditions of a preset event, the hardware generates a data packet based on the first execution information of the design under test and sends the data packet to the software. The software's receiving program first receives the data packet from the hardware. At this time, the receiving program, data processing program, and data sending program are all in their initial states, i.e., idle states. After receiving the data packet D1 from the hardware, the receiving program, while the data processing program is idle, writes the data packet D1 to the first memory partition R1. The data processing program retrieves 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. It then 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 retrieves the updated data packet S1 from the second memory partition R2 and sends the updated data packet S1 to the hardware.

[0174] 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 in an idle state 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.

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

[0176] It should be noted that once all the data in a memory partition has been read, that memory partition can be cleared so that new data can be written.

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

[0178] In summary, this application provides a verification method that collaboratively verifies the design under test (DUT) using both hardware and software. After receiving a data packet from the hardware, the software drives a reference model to execute the same number of instructions based on the number of execution instructions in the data packet. The software then updates the reference model's second execution information into the data packet and sends the packet back to the hardware. The hardware parses the data packet and verifies the DUT based on the reference model's second execution information. This application can trigger the verification of the DUT based on preset events, increasing the visibility of the verification and facilitating rapid location of errors in the DUT. This allows for timely fine-grained debugging and inspection of the DUT. Furthermore, compared to software simulation verification, this application burns the DUT onto the hardware for execution, improving the verification speed.

[0179] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily necessary for the embodiments of this application.

[0180] Device Examples

[0181] Referring to Figure 5, a structural block diagram of a verification device according to this application is shown. The device is applied to the hardware side, which includes a design under test (DUT). The hardware side is connected to the software side via a bus interface, and the software side includes a reference model of the DUT. Specifically, the device may include:

[0182] The control module 501 is used to control the design under test to execute the test program and collect the first execution information of the design under test;

[0183] The data packet generation module 502 is used to generate a data packet based on the first execution information of the design under test when the triggering conditions of a preset event are met; the data packet includes the number of execution instructions of the design under test.

[0184] The sending module 503 is used to send the data packet to the software terminal, so that the software terminal drives the reference model to execute the same number of instructions based on the number of execution instructions, and updates the data packet according to the second execution information of the reference model;

[0185] The parsing module 504 is used to parse the updated data packet and determine the second execution information of the reference model;

[0186] Comparison module 505 is used to compare the first execution information with the second execution information;

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

[0188] Optionally, the preset event includes an instruction comparison event; the triggering conditions for the instruction comparison event include: the number of instructions executed by the design under test is greater than or equal to a first threshold, and no synchronization event is detected.

[0189] Optionally, the comparison module includes:

[0190] The first writing submodule is used to write the first execution information of the design under test into the first queue;

[0191] The second writing submodule is used to write the second execution information of the reference model into the second queue;

[0192] The reading submodule is used 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 has been written to both the first queue and the second queue.

[0193] The first comparison submodule is used to compare the first execution information with the second execution information.

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

[0195] The data packet generation submodule is used to generate a register comparison data packet based on the number of instructions executed by the design under test since the last register comparison event when the number of instructions executed by the design under test since the last instruction comparison event is detected to be greater than or equal to a second threshold.

[0196] Optionally, the hardware further includes a register data module; the first execution information and the second execution information include the values ​​of the registers;

[0197] The comparison module includes:

[0198] The third write submodule is used to write the first value of each register in the design under test into the register data module.

[0199] The fourth write submodule is used to write the second values ​​of each register in the reference model into the register data module;

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

[0201] Optionally, the device further includes:

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

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

[0204] The design under test sends an external interrupt event;

[0205] The design under test is malfunctioning;

[0206] The design under test has encountered a self-trapping event;

[0207] The design under test executes atomic instructions;

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

[0209] Optionally, the device further includes:

[0210] The second interrupt control module is used to interrupt the operation of the design under test when the triggering conditions of the synchronization event are met, and to resume the operation of the design under test after receiving a synchronization end signal from the software.

[0211] Referring to Figure 6, a structural block diagram of another verification device of this application is shown, applied to the software side. The software side is connected to the hardware side via a bus interface. The hardware side includes a design under test (DUT), and the software side includes a reference model of the DUT. The device includes:

[0212] The data packet receiving module 601 is used to receive data packets sent by the hardware terminal; the data packets include the number of execution instructions of the design under test;

[0213] The data packet update module 602 is used to drive the reference model to execute instructions with the same data according to the number of executed instructions, and to update the data packet according to the second execution information of the reference model;

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

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

[0216] The data receiving program is used to receive data packets sent by the hardware terminal and write the data packets into shared memory when the data processing program is idle.

[0217] The data processing program is configured to retrieve the data packet from the shared memory, drive the reference model to execute instructions with the same data based on the number of execution instructions in the data packet, update the data packet according to the second execution information of the reference model, and write the updated data packet into the shared memory when the data sending program is idle.

[0218] The data sending program is used to retrieve the updated data packet from the shared memory and send the updated data packet to the hardware.

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

[0220] The system receives data packets sent by the hardware and, when the data processing program is idle, writes the data packets into a first memory partition; the first memory partition is any free memory partition in the shared memory.

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

[0222] When the data transmission program is idle, the updated data packet is written to the second memory partition; the second memory partition is any free memory partition in the shared memory.

[0223] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0224] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0225] Regarding the processor in the above embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0226] Referring to Figure 7, it is a structural block diagram of an electronic device for verification provided in an embodiment of this application. As shown in Figure 7, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store executable instructions, which cause the processor to execute the verification method of the aforementioned embodiment.

[0227] The processor can 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 programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0228] The communication bus may include a path for transmitting 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 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one line is used in Figure 7, but this does not mean that there is only one bus or one type of bus.

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

[0230] This application also provides a non-transitory computer-readable storage medium, which, when the instructions in the storage medium are executed by the processor of an electronic device (server or terminal), enables the processor to execute the verification method shown in FIG1 or FIG4.

[0231] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0232] The terms "an embodiment," "embodiment," or "one or more embodiments" as used herein mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of this application. Furthermore, please note that the examples of the phrase "in one embodiment" do not necessarily all refer to the same embodiment.

[0233] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0234] In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0235] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0236] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0237] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

[0238] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0239] The present application provides a detailed description of a verification method, apparatus, electronic device, computer-readable storage medium, and computer program. Specific examples have been used to illustrate the principles and implementation methods of the present application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present application. Therefore, the content of this specification should not be construed as a limitation of the present application.

Claims

1. A method of authentication, wherein, The method is applied to a hardware component, which includes a design under test (DUT). The hardware component is connected to a software component via a bus interface. The software component includes a reference model of the DUT. Control the design under test to execute the test program and collect the first execution information of the design under test; When the triggering conditions of a preset event are met, a data packet is generated based on the first execution information of the design under test; the data packet includes the number of execution instructions of the design under test. The data packet is sent to the software so that the software drives the reference model to execute the same number of instructions based on the number of execution instructions, and updates the data packet according to the second execution information of the reference model; The updated data packet is parsed to determine the second execution information of the reference model; Compare the first execution information with the second execution information; If the first execution information and the second execution information do not match, it is determined that the design under test is malfunctioning.

2. The method of claim 1, wherein, The preset events include instruction comparison events; The triggering conditions for the instruction comparison event include: the number of instructions executed by the design under test is greater than or equal to a first threshold, and no synchronization event is detected.

3. The method of claim 2, wherein, The step of comparing the first execution information with the second execution information includes: Write the first execution information of the design under test into the first queue; Write the second execution information of the reference model into the second queue; After detecting that data has been written to both the first queue and the second queue, read 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 of claim 1, wherein, The preset events include register comparison events; The step of generating a data packet based on the first execution information of the design under test, when the triggering conditions of a preset event are met, includes: If the number of instructions executed by the design under test since the last register compare event is greater than or equal to a second threshold, a register compare data packet is generated based on the number of instructions executed by the design under test since the last instruction compare event.

5. The method of claim 4, wherein, The hardware also includes a register data module; the first execution information and the second execution information include the values ​​of the registers. The step of comparing the first execution information with the second execution information includes: Write the first value of each register in the design under test into the register data module; Write 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 of claim 5, wherein, The method further includes: If the number of instructions executed by the design under test since the last register comparison event is greater than or equal to the second threshold, the operation of the design under test is interrupted until both the first value and the second value are written to the register data module, and then the operation of the design under test is resumed.

7. The method of claim 1, wherein, The preset events include synchronization events.

8. The method of claim 1, wherein, The triggering conditions for the synchronization event include at least one of the following: The design under test sends an external interrupt event; The design under test is malfunctioning; The design under test has encountered a self-trapping event; The design under test executes atomic instructions; The design under test accesses external devices on the hardware side.

9. The method of claim 8, wherein, The method further includes: If the triggering conditions of the synchronization event are met, the operation of the design under test is interrupted until a synchronization end signal is received from the software, at which point the operation of the design under test is resumed.

10. A method of authentication, wherein, The method is applied to the software side, which is connected to the hardware side via a bus interface. The hardware side includes a design under test (DUT), and the software side includes a reference model of the DUT. Receive data packets sent by the hardware terminal; the data packets include the number of execution instructions of the design under test; The reference model is driven to execute instructions with the same data according to the number of execution instructions, and the data packet is updated according to the second execution information of the reference model; The updated data packet is sent to the hardware.

11. The method of claim 10, wherein, The software includes a data receiving program, a data sending program, and a data processing program; receiving the data packets sent by the hardware includes: The data receiving program receives data packets sent by the hardware terminal, and writes the data packets into shared memory when the data processing program is idle.

12. The method of claim 11, wherein, The step of driving the reference model to execute instructions with the same data according to the number of execution instructions, and updating the data packet according to the second execution information of the reference model, includes: The data processing program retrieves the data packet from the shared memory, drives the reference model to execute instructions with the same data 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; When the data sending program is idle, the data processing program writes the updated data packet into the shared memory.

13. The method of claim 12, wherein, Sending the updated data packet to the hardware includes: The data sending program retrieves the updated data packet from the shared memory and sends the updated data packet to the hardware.

14. The method of claim 11, wherein, The shared memory includes at least two memory partitions; The data receiving program receives data packets sent by the hardware terminal, and when the data processing program is idle, writes the data packets into shared memory, including: The data receiving program receives data packets sent by the hardware terminal, and when the data processing program is idle, writes the data packets into the first memory partition; the first memory partition is any free memory partition in the shared memory.

15. The method of claim 13, wherein, When the data sending program is idle, the data processing program writes the updated data packet to the shared memory, including: When the data sending program is idle, the data processing program writes the updated data packet to the second memory partition; the second memory partition is any free memory partition in the shared memory.

16. A verification device, wherein, The device is applied to a hardware component, which includes a design under test (DUT). The hardware component is connected to a software component via a bus interface. The software component includes a reference model of the DUT. The device comprises: The control module is used to control the design under test to execute the test program and collect the first execution information of the design under test; A data packet generation module is used to generate a data packet based on the first execution information of the design under test when the triggering conditions of a preset event are met; the data packet includes the number of execution instructions of the design under test; A sending module is configured to send the data packet to the software terminal, so that the software terminal drives the reference model to execute the same number of instructions based on the number of execution instructions, and updates the data packet according to the second execution information of the reference model; The parsing module is used to parse the updated data packet and determine the second execution information of the reference model; The comparison module is used to compare the first execution information with the second execution information; The determination module is used to determine that the design under test has an operational error when the first execution information and the second execution information do not match.

17. A verification device, wherein, The device is applied to the software side, which is connected to the hardware side via a bus interface. The hardware side includes a design under test (DUT), and the software side includes a reference model of the DUT. The device includes: A data packet receiving module is used to receive data packets sent by the hardware terminal; the data packets include the number of execution instructions of the design under test; A data packet update module is used to drive the reference model to execute instructions with the same data according to the number of executed instructions, and to update the data packet according to the second execution information of the reference model; The data packet sending module is used to send the updated data packet to the hardware terminal.

18. An electronic device, comprising: The electronic device includes a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store executable instructions, which cause the processor to execute the verification method as described in any one of claims 1 to 15.

19. A readable storage medium, wherein, When the instructions in the readable storage medium are executed by the processor of the electronic device, the processor is enabled to perform the verification method as described in any one of claims 1 to 15.

20. A computer program comprising computer-readable code that, when executed on a computing processing device, causes the computing processing device to perform the method according to any one of claims 1 to 15.

Images