Processor verification method and system, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a processor verification method and system, electronic equipment and a readable storage medium. The method comprises the following steps: in response to any verification event triggered by a to-be-tested design of a processor, allocating an event identifier for the verification event, and caching the verification event and the corresponding event identifier to a preset position; compressing the at least two verification events to obtain compression events corresponding to the at least two verification events; adding a compression identifier for the compression event, and sending the compression event and the compression identifier to a receiving end; the compression identifier comprises event identifiers of at least two verification events corresponding to the compression event; and under the condition that a retransmission request sent by a receiving end is received, based on the compression identifier carried by the retransmission request, obtaining at least two verification events corresponding to the event identifier contained in the compression identifier from the preset position, and sending the at least two verification events to the receiving end. The verification effect is improved.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit technology, and in particular to a processor verification method, system, electronic device, and readable storage medium. Background Technology

[0002] In processor co-simulation verification, it is necessary to simultaneously simulate the circuit part of the processor design under test and the software-implemented instruction set simulator (reference model). By comparing the states of the two after each processor instruction has been executed, the processor design under test can be verified.

[0003] During the aforementioned verification process, the hardware side (hardware simulation platform) and the software side (reference model) need to communicate extensively, resulting in high communication overhead. Currently, to reduce communication frequency and data volume, a communication compression strategy is often adopted, which involves compressing multiple verification events before transmission. However, the compressed verification events can only reflect the cumulative result of all instructions. When verification errors occur, it is impossible to accurately locate the erroneous verification event, leading to poor processor verification performance. Summary of the Invention

[0004] The purpose of this invention is to provide a processor verification method, system, electronic device, and readable storage medium to solve the problem of processor verification effectiveness. The specific technical solution is as follows: In a first aspect of the present invention, a processor verification method is provided. The method is applied to a sending end in a processor verification system, the processor verification system further comprising a receiving end, the sending end being communicatively connected to the receiving end; the method includes: In response to any verification event triggered by the processor design under test, an event identifier is assigned to the verification event, and the verification event and the corresponding event identifier are cached in a preset location; Compress at least two verification events to obtain compressed events corresponding to the at least two verification events; A compression identifier is added to the compression event, and the compression event and the compression identifier are sent to the receiving end; the compression identifier contains the event identifiers of at least two verification events corresponding to the compression event; Upon receiving a retransmission request from the receiving end, based on the compression identifier carried in the retransmission request, at least two verification events corresponding to the event identifier contained in the compression identifier are obtained from the preset location, and the at least two verification events are sent to the receiving end. The receiving end is configured to receive each compression event sent by the sending end and execute each compression event; if the verification requirements are not met after executing any compression event, the receiving end sends a retransmission request to the sending end, the retransmission request including the compression identifier of the compression event, and if the receiving end receives at least two verification events retransmitted by the sending end, the receiving end re-executes the at least two verification events.

[0005] In a second aspect of the invention, a processor verification method is also provided. The method is applied to a receiving end in a processor verification system, the processor verification system further including a transmitting end, the transmitting end being communicatively connected to the receiving end; the method includes: Receive each compression event sent by the sending end, and execute each compression event; If, after executing any of the compression events, it is determined that the execution result does not meet the verification requirements, a retransmission request is sent to the sending end. The retransmission request includes the compression identifier of the compression event; the compression identifier includes the event identifiers of at least two verification events corresponding to the compression event. If at least two verification events are received from the sending end and resent, the at least two verification events are re-executed to determine whether the execution result meets the verification requirements; The sending end is configured to respond to any verification event triggered by the processor design under test, assign an event identifier to the verification event, and cache the verification event and the corresponding event identifier in a preset location; compress at least two verification events to obtain compressed events corresponding to the at least two verification events; add a compression identifier to the compressed event, and send the compressed event and the compression identifier to the receiving end; upon receiving a retransmission request from the receiving end, based on the compression identifier carried in the retransmission request, retrieve at least two verification events corresponding to the event identifier contained in the compression identifier from the preset location, and send the at least two verification events to the receiving end.

[0006] In a third aspect of the present invention, a processor verification system is also provided, the processor verification system including a transmitter and a receiver, the transmitter and the receiver being communicatively connected; The sending end is configured to respond to any verification event triggered by the processor design under test, assign an event identifier to the verification event, and cache the verification event and the corresponding event identifier in a preset location; The sending end is used to compress at least two verification events to obtain compressed events corresponding to the at least two verification events; The sending end is configured to add a compression identifier to the compression event and send the compression event and the compression identifier to the receiving end; the compression identifier includes the event identifiers of at least two verification events corresponding to the compression event; Upon receiving a retransmission request from the receiving end, the sending end is compressed based on the retransmission request, and at least two verification events corresponding to the event identifier contained in the compression identifier are obtained from the preset location, and the at least two verification events are sent to the receiving end. The receiving end is used to receive each compression event sent by the sending end and execute each compression event; The receiving end is configured to send a retransmission request to the sending end if the verification requirements are not met after executing any of the compression events. The retransmission request includes the compression identifier of the compression event. Upon receiving at least two verification events retransmitted by the sending end, the receiving end will re-execute the at least two verification events.

[0007] In a fourth aspect of the present invention, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus. Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the method described in the first or second aspect above.

[0008] In a fifth aspect of the invention, a computer-readable storage medium is also provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the method described in the first or second aspect above.

[0009] In a sixth aspect of the invention, a computer program product comprising instructions is also provided, which, when run on a computer, causes the computer to perform the method described in the first or second aspect above.

[0010] The processor verification method provided in this invention adds event identifiers to uncompressed verification events and, after compression, adds compression identifiers containing at least two corresponding verification events to each compressed event. This establishes a correspondence between compressed and uncompressed events using the compression identifiers and event identifiers. Therefore, if the receiving end determines that the verification requirements are not met after executing a compressed event, it can request at least two uncompressed verification events corresponding to the compressed event from the sending end based on the compression identifiers. The receiving end can then re-execute these at least two verification events. This method can quickly locate problematic verification events when verification errors occur, avoiding the problem of not being able to locate errors due to compressed events in related technologies, and thus improving the processor verification effect to a certain extent. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0012] Figure 1 This is a flowchart illustrating the steps of a processor verification method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a processor verification system provided in an embodiment of the present invention; Figure 3 This is a flowchart of another processor verification method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the operation of a processor verification system provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of another processor verification system in an embodiment of the present invention; Figure 6 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

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

[0014] The terms "first," "second," etc., used in the specification and claims of this invention 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 the invention 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 the number of objects is not limited; for example, the 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 embodiments of this invention, the term "multiple" refers to two or more, and other quantifiers are similar.

[0015] Figure 1 This is a flowchart illustrating the steps of a processor verification method according to an embodiment of the present invention. This method can be applied to a sending end in a processor verification system, which also includes a receiving end, and the sending end and the receiving end are communicatively connected. Figure 1 As shown, the method may include: Step 101: In response to any verification event triggered by the processor design under test, assign an event identifier to the verification event and cache the verification event and the corresponding event identifier to a preset location.

[0016] Step 102: Compress at least two verification events to obtain compressed events corresponding to the at least two verification events.

[0017] Step 103: Add a compression identifier to the compression event and send the compression event and the compression identifier to the receiving end; the compression identifier contains the event identifiers of at least two verification events corresponding to the compression event.

[0018] Step 104: Upon receiving a retransmission request from the receiving end, based on the compression identifier carried in the retransmission request, obtain at least two verification events corresponding to the event identifier contained in the compression identifier from the preset location, and send the at least two verification events to the receiving end.

[0019] The receiving end is configured to receive each compression event sent by the sending end and execute each compression event; if it is determined after executing any compression event that the execution result does not meet the verification requirements, it sends a retransmission request to the sending end, the retransmission request including the compression identifier of the compression event, and if it receives at least two verification events retransmitted by the sending end, it re-executes the at least two verification events.

[0020] Regarding steps 101-104 above, this embodiment of the invention can be applied to any co-simulation verification framework for a processor verification system consisting of a hardware side and a software side. Accordingly, the sending end can be a hardware simulation platform, and the receiving end can be a reference model such as an instruction set simulator. Furthermore, the sending end and the receiving end can be communicatively connected. Specifically, the communication connection can be achieved through hardware and software communication methods such as high-speed serial expansion bus (Peripheral Component Interconnect Express, PCIe) or Ethernet. Of course, other methods can also be used, and this embodiment of the invention does not limit this.

[0021] It should be noted that in processor co-simulation verification, the processor design-under-test (DUT) circuitry and a software-implemented instruction set simulator (also known as a reference model) are simulated simultaneously. After each processor instruction is executed, the architectural states of the two are compared to verify the correctness of the DUT implementation. The processor simulation framework extracts processor verification events, such as instruction commits and register updates, after each instruction execution and transmits them to the reference model for comparison.

[0022] Existing processor verification solutions mainly include two technical approaches: one based on software simulators (such as open-source simulators (Verilator), compiled simulators (Verilog Compiled Simulator, VCS), and modeling simulators (ModelSim)) and the other based on hardware simulation platforms (such as hardware simulators (Emulator) and Field-Programmable Gate Arrays (FPGAs)). Among these, the software simulator-based approach is speed-limited when simulating large-scale integrated circuits, capable of simulating only a few thousand processor cycles per second, which cannot meet the simulation requirements of long-term, large-scale verification workloads. To address the speed issues of software emulators, the industry has introduced hardware simulation platforms based on FPGAs or dedicated emulators. The processor design under test is deployed on the hardware simulation platform, while the software reference model is deployed on a host computer with a complex instruction set computer architecture (such as x86) or a reduced instruction set computer architecture (such as Advanced RISC Machines, ARM), forming a "software-hardware co-simulation" architecture. Verification events are transmitted through hardware and software communication methods such as high-speed peripheral component interconnect express (PCIe), Ethernet, and wireless bandwidth (InfiniBand, IB).

[0023] Figure 2 This is a schematic diagram of the structure of a processor verification system provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the hardware-software co-simulation architecture can include a hardware simulation platform and a software runtime environment. The processor design under test can run on the hardware simulation platform, while reference models such as instruction set simulators can be deployed in the software runtime environment. The hardware simulation platform can be an Emulator or an FPGA, and the software runtime environment can be a host computer using x86 or ARM architecture. Accordingly, both can use different clock frequencies; for example, the hardware side can use 1~50MHz, and the software side can use 50~100MHz. Of course, they can also use the same frequency, and this embodiment of the invention does not impose any limitations on this.

[0024] The processor design under test (DUT) mentioned above can be a pre-set processor design to be verified. The verification events mentioned above refer to the state change information generated by the processor during operation. There can be various types of verification events, such as instruction commits, register updates, memory access information, and exception / interrupt handling. The execution of each instruction triggers a series of verification events related to the architecture behavior.

[0025] Specifically, the sending end can monitor the processor design under test based on verification requirements, and determine to trigger a verification event when a valid event is detected. For example, taking a register update event as an example, the verification framework connects the probe to the processor register file. When the register value changes, the probe records the updated value as a verification event, such as "Register 32 has been updated, and the updated value is X".

[0026] The event identifier mentioned above can be a unique identifier assigned to each verification event. Different verification events can have different event identifiers. For example, the identifier can be Arabic numerals 1, 2, 3, etc., or it can be other types of strings. This embodiment of the invention does not limit this.

[0027] Specifically, the compression operation described above refers to compressing at least two verification events into a single compressed event for transmission. For example, compressing N consecutive command submission events into a single aggregated event with a "submission count of N", thereby reducing the amount of verification data that needs to be transmitted. Correspondingly, a compression identifier can be added to the compressed event, which can contain the event identifiers of the at least two verification events corresponding to the compressed event. For example, if the event identifiers of the aforementioned N consecutive command submission events are 1, 2, 3, ..., N, then the compression identifier of the compressed event obtained by compressing them can be 1 to N.

[0028] Furthermore, the sending end can send compression events and their corresponding compression identifiers to the receiving end. Correspondingly, the receiving end can receive and execute each compression event sent by the receiving end. Further, if the receiving end determines that the execution result does not meet the verification requirements after executing any compression event, it sends a retransmission request carrying the compression identifier of that compression event to the sending end.

[0029] Accordingly, when the sending end receives the retransmission request, it can retrieve at least two verification events corresponding to the event identifiers contained in the compression identifier carried in the retransmission request from a preset location, and send them to the receiving end. The preset location can be a preset cache location in the sending end for storing uncompressed verification events, and can be a preset memory or database, etc., which is not limited in this embodiment of the invention. The sending end can cache each compressed event and its event identifier in the preset location before compressing the verification events.

[0030] Specifically, upon receiving at least two verification events corresponding to the compression event sent by the sender in response to the retransmission request, the receiving end re-executes these at least two verification events. This allows the receiving end to re-execute the corresponding at least two verification events when there are problems in the execution of the compression event, facilitating the verification of the results of each event and thus helping to locate the verification event with the verification problem.

[0031] For example, the verification events for instructions 1-10 are compressed together and transmitted to the software side. The software side executes the 10 instructions accordingly and compares the results, finding inconsistencies. At this point, the software side transmits the identifier (range 1-10) to the hardware side. The hardware side retransmits the cached, uncompressed events for instructions 1-10, and the software side executes the verification events for instructions 1-10 one by one, comparing them with the processor design under test after each instruction. If an inconsistency is found after a certain instruction, it can be determined that there is an execution error in that instruction, thus locating the error event.

[0032] In summary, the processor verification method provided by this invention adds event identifiers to uncompressed verification events and, after compression, adds compression identifiers containing at least two corresponding verification events to the compressed events. This establishes a correspondence between compressed and uncompressed events using the compression identifiers and event identifiers. Therefore, if the receiving end determines that the verification requirements are not met after executing the compressed event, it can request at least two uncompressed verification events corresponding to the compressed event from the sending end based on the compression identifiers. The receiving end can then re-execute these at least two verification events. This allows for rapid location of problematic verification events when verification errors occur, avoiding the problem of error location failure due to compressed events in related technologies, and thus improving the processor verification effect to a certain extent.

[0033] Figure 3 This is a flowchart illustrating the steps of another processor verification method provided in an embodiment of the present invention. This method can be applied to a receiving end in a processor verification system. The processor verification system also includes a sending end, which is communicatively connected to the receiving end. Figure 3 As shown, the method may include: Step 201: Receive each compression event sent by the sending end and execute each compression event.

[0034] Step 202: If, after executing any of the compression events, it is determined that the execution result does not meet the verification requirements, a retransmission request is sent to the sending end. The retransmission request includes the compression identifier of the compression event; the compression identifier includes the event identifiers of at least two verification events corresponding to the compression event.

[0035] Step 203: Upon receiving at least two verification events resent by the sending end, re-execute the at least two verification events to determine whether the execution result meets the verification requirements.

[0036] The sending end is configured to respond to any verification event triggered by the processor design under test, assign an event identifier to the verification event, and cache the verification event and the corresponding event identifier in a preset location; compress at least two verification events to obtain compressed events corresponding to the at least two verification events; add a compression identifier to the compressed event, and send the compressed event and the compression identifier to the receiving end; upon receiving a retransmission request from the receiving end, based on the compression identifier carried in the retransmission request, retrieve at least two verification events corresponding to the event identifier contained in the compression identifier from the preset location, and send the at least two verification events to the receiving end.

[0037] The processor design under test (DUT) mentioned above can be a pre-set processor design to be verified. The verification events mentioned above refer to the state change information generated by the processor during operation. There can be various types of verification events, such as instruction commits, register updates, memory access information, and exception / interrupt handling. The execution of each instruction triggers a series of verification events related to the architecture behavior.

[0038] Optionally, the processor design under test runs at the transmitting end, and the receiving end deploys a reference model of the processor design under test.

[0039] Specifically, the sending end can monitor the processor design under test based on verification requirements, and determine to trigger a verification event when a valid event is detected. For example, taking a register update event as an example, the verification framework connects the probe to the processor register file. When the register value changes, the probe records the updated value as a verification event, such as "Register 32 has been updated, and the updated value is X".

[0040] The event identifier mentioned above can be a unique identifier assigned to each verification event. Different verification events can have different event identifiers. For example, the identifier can be Arabic numerals 1, 2, 3, etc., or it can be other types of strings. This embodiment of the invention does not limit this.

[0041] Specifically, the compression operation described above refers to compressing at least two verification events into a single compressed event for transmission. For example, compressing N consecutive command submission events into a single aggregated event with a "submission count of N", thereby reducing the amount of verification data that needs to be transmitted. Correspondingly, a compression identifier can be added to the compressed event, which can contain the event identifiers of the at least two verification events corresponding to the compressed event. For example, if the event identifiers of the aforementioned N consecutive command submission events are 1, 2, 3, ..., N, then the compression identifier of the compressed event obtained by compressing them can be 1 to N.

[0042] Furthermore, the sending end can send compression events and their corresponding compression identifiers to the receiving end. Correspondingly, the receiving end can receive and execute each compression event sent by the receiving end. Further, if the receiving end determines that the execution result does not meet the verification requirements after executing any compression event, it sends a retransmission request carrying the compression identifier of that compression event to the sending end.

[0043] Accordingly, when the sending end receives the retransmission request, it can retrieve at least two verification events corresponding to the event identifiers contained in the compression identifier carried in the retransmission request from a preset location, and send them to the receiving end. The preset location can be a preset cache location in the sending end for storing uncompressed verification events, and can be a preset memory or database, etc., which is not limited in this embodiment of the invention. The sending end can cache each compressed event and its event identifier in the preset location before compressing the verification events.

[0044] Specifically, upon receiving at least two verification events corresponding to the compression event sent by the sender in response to the retransmission request, the receiving end re-executes these at least two verification events. This allows the receiving end to re-execute the corresponding at least two verification events when there are problems in the execution of the compression event, facilitating the verification of the results of each event and thus helping to locate the verification event with the verification problem.

[0045] For example, the verification events for instructions 1-10 are compressed together and transmitted to the software side. The software side executes the 10 instructions accordingly and compares the results, finding inconsistencies. At this point, the software side transmits the identifier (range 1-10) to the hardware side. The hardware side retransmits the cached, uncompressed events for instructions 1-10, and the software side executes the verification events for instructions 1-10 one by one, comparing them with the processor design under test after each instruction. If an inconsistency is found after a certain instruction, it can be determined that there is an execution error in that instruction, thus locating the error event. This method avoids global state recovery; complete information for each instruction can be obtained simply by local retransmission.

[0046] Specifically, after each verification event is executed, the states of the reference model and the processor design under test can be compared. If they match, it indicates that the verification event has no errors. Conversely, if they do not match, it indicates that the verification event has execution errors. This allows for further testing and optimization of the components of the processor design under test used to execute the verification event.

[0047] In summary, the processor verification method provided by this invention adds event identifiers to uncompressed verification events and, after compression, adds compression identifiers containing at least two corresponding verification events to the compressed events. This establishes a correspondence between compressed and uncompressed events using the compression identifiers and event identifiers. Therefore, if the receiving end determines that the verification requirements are not met after executing the compressed event, it can request at least two uncompressed verification events corresponding to the compressed event from the sending end based on the compression identifiers. The receiving end can then re-execute these at least two verification events. This allows for rapid location of problematic verification events when verification errors occur, avoiding the problem of error location failure due to compressed events in related technologies, and thus improving the processor verification effect to a certain extent.

[0048] Optionally, embodiments of the present invention may further include: S21. Before executing any of the compression events, set the current execution position as the latest checkpoint and record the state of the reference model corresponding to the latest checkpoint.

[0049] S22. During the execution of any of the compression events, record the data changes in the state relative to the latest checkpoint as an incremental log.

[0050] In this embodiment of the invention, before executing any compression event, the current execution position can be set as the latest checkpoint, and the state of the reference model corresponding to the latest checkpoint can be recorded. Correspondingly, during the execution of any compression event, the data changes of the reference model's state relative to the latest checkpoint can be further recorded as incremental logs. Each time the reference model executes multiple actions identical to those of the processor based on the compressed verification event, the reference model first sets a checkpoint and rolls back to that checkpoint in case of an error. If the results are consistent after all actions are executed according to the compression event, then this checkpoint does not need to be used.

[0051] It should be noted that existing debugging methods generally rely on hardware snapshot mechanisms, which periodically save the entire processor's hardware circuit state during simulation and rerun from the snapshot to recover uncompressed events when an error occurs. This approach requires storing and restoring large-scale hardware states. Even if only debugging information near the error point needs to be restored, the entire processor circuit details need to be rerun, which is a "global recovery." This inefficient global replay method severely impacts debugging efficiency and is not conducive to quickly locating and fixing errors.

[0052] In this embodiment of the invention, the software-side reference model does not employ a global snapshot saving method. Instead, it records incremental modification logs since the most recent checkpoint, such as the original values ​​of registers or memory before modification. When a mismatch is detected by a compression event, the reference model can roll back to the most recent checkpoint state by reversing the writing of these modification logs, thereby completing state recovery in a lightweight manner.

[0053] Optionally, before re-executing the at least two verification events, the embodiments of the present invention may further include: The reference model's state is restored to the latest checkpoint based on the incremental log.

[0054] Specifically, before re-executing the above at least two verification events, the incremental logs can be executed in reverse order to roll back the state of the reference model to the latest checkpoint, that is, the state before the above compression events were executed.

[0055] This method can accurately restore the state of the reference model and accurately restore the verification behavior details of each instruction, making it easier to re-execute at least two verification events corresponding to the compression event and ensuring the accuracy of the verification.

[0056] Optionally, embodiments of the present invention may further include: S31. Obtain the current state of the processor design under test as the first state, and obtain the current state of the reference model as the second state.

[0057] S32. If the first state and the second state are consistent, determine that the execution result meets the verification requirements.

[0058] Specifically, S31 and S32 can be executed after any compression event is completed, or they can be executed after any verification event corresponding to a compression event that has an execution error is re-executed. This embodiment of the invention does not limit this.

[0059] The aforementioned state may include register values, cached values, etc., and this embodiment of the invention does not impose any limitations on this. It should be noted that if the above S31 is executed after re-executing any verification event corresponding to the compression event with an execution error, the current state of the processor design under test can be the post-execution state of the corresponding verification event in its execution log.

[0060] For example, if a compression event with an execution error includes an addition instruction, the execution result of the processor under test after executing the addition instruction can be obtained as the first state, and the execution result of the reference model after executing the addition instruction can be obtained as the second state. The first state and the second state can be compared. If they are consistent, it indicates that the addition instruction was executed accurately. Conversely, if they are inconsistent, it indicates that the addition instruction has an execution error. Accordingly, the above verification requirement can be that the first state and the second state are consistent.

[0061] In this way, by comparing the state of the processor design under test and the reference model, it can be determined whether the execution result meets the verification requirements.

[0062] Optionally, embodiments of the present invention may further include: If the execution result does not meet the verification requirements, the components to be optimized in the processor design under test are determined based on the execution result.

[0063] For example, if the first state and the second state corresponding to the above addition instruction are inconsistent, it indicates that there is an error in the addition operation unit of the processor under test, which can facilitate the designer to further test and optimize it.

[0064] In this way, the erroneous instruction and its corresponding microstructural unit can be accurately located, thus enabling lightweight, instruction-level error debugging.

[0065] It is important to note that in processor co-simulation verification, verification events are the core clues for error localization and debugging. The execution of each instruction triggers a series of events related to the architecture's behavior, such as instruction commit, register updates, memory access information, and exception / interrupt handling. By comparing the consistency of the processor design-under-test (DUT) and the reference model in these events, the erroneous instruction can be accurately located, and further narrowed down to the corresponding microarchitecture module. For example, if a register write-back value does not match the reference model after a load instruction is executed, and a cache access event is also abnormal, it can be determined that the problem may lie in the implementation logic of the memory hierarchy. Therefore, the details of instruction-by-instruction verification events are crucial for error localization. However, due to the extremely high overhead of hardware-software communication in hardware simulation platforms, existing solutions generally employ communication compression strategies, compressing the verification events of multiple instructions before transmission to reduce communication frequency and data volume. While this method significantly improves the speed of co-simulation, it inevitably loses the verification details of each instruction. When an error occurs, the compressed events can only provide compressed information and cannot directly reflect the verification behavior corresponding to each instruction, posing significant difficulties for debugging.

[0066] To recover this fine-grained verification information, existing methods typically rely on hardware snapshot mechanisms. Hardware snapshots refer to periodically saving the complete hardware state of the entire processor, including register files, caches, and memory, during simulation execution. When an error is detected, the simulation platform reruns the processor from the most recent snapshot state, regenerating uncompressed verification events periodically to reconstruct the complete instruction-by-instruction verification. While this method provides the necessary debugging details, saving and restoring the global hardware state incurs significant storage and time overhead, hindering fast and efficient debugging.

[0067] While existing co-simulation verification methods can reduce the amount of communication data between hardware and software through data compression, current compression techniques compress verification events from multiple instructions into a single dataset, losing the details of each instruction's verification behavior. Since the compressed verification events only reflect the cumulative result of all instructions, it becomes impossible to trace back to a specific erroneous instruction and its corresponding microstructure when an error occurs, significantly reducing debugging efficiency. Furthermore, existing debugging methods generally rely on hardware snapshot mechanisms, which periodically save the entire processor's hardware circuit state during simulation and rerun from the snapshot to recover uncompressed events when an error occurs. This approach requires storing and restoring large-scale hardware states; even if only debugging information near the error point needs to be restored, the entire processor circuit details must be rerun, constituting a "global recovery." This inefficient global replay method severely impacts debugging efficiency and hinders the rapid location and repair of errors.

[0068] Figure 4 This is a schematic diagram of the operation of a processor verification system provided in an embodiment of the present invention, such as... Figure 4 As shown, the relay flow is as follows: On the hardware side, each instruction is configured with a different verification event for checking. For example, IC1 represents the commit event of the first instruction (Instruction Commit, instr.commit, IC).

[0069] The hardware side buffers the verification events IC1 and IC2 into the replay buffer and fuses them into IC1-2 before transmitting them to the software side.

[0070] The software submitted two consecutive instructions based on IC1-2 and compared the results, finding an error. It then reverted to the state before IC1-2 (revert IC).

[0071] The software side notifies the rollback range (i.e., instructions 1-2) to the hardware side, and the Replay Buffer retransmits the uncompressed IC1 and IC2.

[0072] By checking IC1 and IC2 one by one on the software side, the error can be located in IC2.

[0073] In summary, the processor verification method provided by this invention utilizes the architectural behavior information of verification events, i.e., the correspondence between events, architectural behaviors, and microarchitectural components. Here, the aforementioned behavioral information refers to changes in the processor's architectural state. For example, an instruction commit verification event indicates that the CPU has completed an addition instruction, and a register update event indicates the result of this addition. For instance, based on the verification event, we know that the processor performed an addition and knows the result. We then have the reference model also perform an addition and compare the results. If the results are inconsistent, it indicates that errors have occurred in the addition operation (architectural behavior) and the addition operation unit (microarchitectural component). Architectural behavior refers to changes in the processor's architectural state, such as an instruction commit and register changes. Microarchitectural components refer to the tools the processor uses to perform these behaviors; for example, an addition unit can be used to perform addition. In this embodiment of the invention, the original uncompressed events are cached and assigned identifiers on the hardware side. On the software side, when a mismatch is detected in the compressed events, the reference model rolls back to the nearest checkpoint before the error and precisely requests the hardware to return the uncompressed events near the error point through the identifier. Then, the events are replayed and compared one by one, thereby locating the error to a certain instruction and its related microstructure.

[0074] Meanwhile, in the reference model state rollback section, the overhead of state recovery needs to be considered. Since errors may occur and rollbacks may be necessary during each compression event check, taking a snapshot of the reference model before each check would incur high resource and time overhead. Considering that the interval between each possible rollback is small and the modifications are minimal, this embodiment of the invention proposes an incremental rollback method based on modification logs. This method only records modifications between adjacent checkpoints, such as the original memory value before each memory write, and achieves lightweight state recovery by writing back the modification records in reverse order.

[0075] This invention, based on existing hardware and software communication compression methods, adds event caching, range determination, and reference model rollback mechanisms. It addresses the problem of instruction-by-instruction debugging detail loss caused by compressing multiple instruction verification events in existing compression acceleration methods, as well as the high storage and time overhead of existing hardware snapshot-based debugging methods.

[0076] Compared to traditional hardware snapshots, this invention eliminates the need for global recovery. Instead, it achieves lightweight debugging through local verification event replay, preserving the acceleration benefits of compressed communication while resolving the issue of instruction-level detail loss, thus enabling efficient error localization and debugging. It retains the performance advantages of compressed communication in co-simulation verification while restoring instruction-by-instruction verification details through event caching and replay mechanisms, achieving lightweight instruction-level debugging. It avoids the global recovery overhead of existing hardware snapshot methods, providing instruction-by-instruction debugging capabilities while maintaining communication compression efficiency, significantly improving the efficiency and debuggability of processor co-simulation verification.

[0077] This invention avoids the global state saving and restoration required by traditional hardware snapshots during debugging, significantly reducing storage and time overhead. Experimental results based on the DiffTest co-simulation verification framework show that while maintaining a 78–80x speedup, this solution can quickly replay uncompressed verification events near the error point, achieving instruction-by-instruction error localization and debugging, with the introduced additional resources and simulation time overhead being less than 1%, which is negligible. This solution has been successfully applied to the co-simulation verification framework of the "Xiangshan" processor hardware simulation platform, helping to discover and fix more than 150 complex design defects during actual verification. This solution has good versatility and can be quickly deployed in verification tasks of various Reduced Instruction Set Computer V (RISC-V) and other processor architectures, significantly improving the verification efficiency and debuggability of complex processors.

[0078] 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 the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0079] Figure 5 This is a schematic diagram of another processor verification system according to an embodiment of the present invention, such as... Figure 5 As shown, the system 30 may include a transmitter 301 and a receiver 302, which are communicatively connected. The sending end is used to respond to any verification event triggered by the processor design under test, assign an event identifier to the verification event, and cache the verification event and the corresponding event identifier to a preset location; The sending end is used to compress at least two verification events to obtain compressed events corresponding to the at least two verification events; The sending end is configured to add a compression identifier to the compression event and send the compression event and the compression identifier to the receiving end; the compression identifier includes the event identifiers of at least two verification events corresponding to the compression event; Upon receiving a retransmission request from the receiving end, the sending end is compressed based on the retransmission request, and at least two verification events corresponding to the event identifier contained in the compression identifier are obtained from the preset location, and the at least two verification events are sent to the receiving end. The receiving end is used to receive each compression event sent by the sending end and execute each compression event; The receiving end is configured to send a retransmission request to the sending end if the verification requirements are not met after executing any of the compression events. The retransmission request includes the compression identifier of the compression event. Upon receiving at least two verification events retransmitted by the sending end, the receiving end will re-execute the at least two verification events.

[0080] Optionally, the processor design under test runs at the transmitting end, and the receiving end deploys a reference model of the processor design under test.

[0081] Optionally, the receiving end is further configured to: Before executing any of the compression events, the current execution position is set as the latest checkpoint, and the state of the reference model at the latest checkpoint is recorded; During the execution of any of the compression events, data changes relative to the state of the latest checkpoint are recorded as incremental logs.

[0082] Optionally, the receiving end is further configured to: restore the state of the reference model to the latest checkpoint based on the incremental log.

[0083] Optionally, the receiving end is further configured to: obtain the current state of the processor design under test as a first state, and obtain the current state of the reference model as a second state; If the first state and the second state are consistent, the execution result is determined to meet the verification requirements.

[0084] Optionally, the receiving end is further configured to: determine, based on the execution result, the components of the processor design under test that need to be optimized if the execution result does not meet the verification requirements.

[0085] In summary, the processor verification system provided in this embodiment of the invention allows the sending end to add event identifiers to uncompressed verification events and, after compression, add compression identifiers containing at least two corresponding verification events to the compressed events. This establishes a correspondence between compressed and uncompressed events using the compression identifiers and event identifiers. Therefore, if the receiving end determines that the verification requirements are not met after executing the compressed event, it can request at least two uncompressed verification events corresponding to the compressed event from the sending end based on the compression identifiers. The receiving end can then re-execute these at least two verification events. This allows for rapid location of problematic verification events when verification errors occur, avoiding the problem of error location failure due to compressed events in related technologies, and improving the processor verification effect to a certain extent.

[0086] As the system implementation is basically similar to the method implementation, it is described in a relatively simple way. For relevant details, please refer to the description of the method implementation.

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

[0088] Regarding the communication device in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0089] This invention also provides an electronic device, including: a processor and a memory for storing processor-executable instructions, wherein the processor is configured to execute the processor verification method described above.

[0090] Reference Figure 6 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Figure 6 As shown, 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 at least one executable instruction, which causes the processor to execute the processor verification method of the aforementioned embodiment.

[0091] It should be noted that the electronic devices in the embodiments of this application include mobile electronic devices and non-mobile electronic devices.

[0092] The processor can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), a 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.

[0093] 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 an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0094] 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 Disk Read Only), magnetic tape, floppy disk and optical data storage devices, etc.

[0095] This invention also provides a non-transitory computer-readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device (server or terminal), enables the processor to perform... Figure 1 The processor verification method shown.

[0096] This invention also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform... Figure 1 The processor verification method shown.

[0097] This application also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the processor verification method embodiments described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0098] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

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

[0100] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid state disks (SSDs)).

[0101] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0102] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0103] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0104] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0105] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0106] It should be noted that the various data-related processes in the embodiments of this application are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.

[0107] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0108] The present invention has provided a detailed description of a processor verification method, system, electronic device, and readable storage medium. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. 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 invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A processor verification method, characterized in that, The method is applied to a sending end in a processor verification system, the processor verification system further including a receiving end, the sending end and the receiving end being communicatively connected; the method includes: In response to any verification event triggered by the processor design under test, an event identifier is assigned to the verification event, and the verification event and the corresponding event identifier are cached in a preset location; Compress at least two verification events to obtain compressed events corresponding to the at least two verification events; A compression identifier is added to the compression event, and the compression event and the compression identifier are sent to the receiving end; the compression identifier contains the event identifiers of at least two verification events corresponding to the compression event; Upon receiving a retransmission request from the receiving end, based on the compression identifier carried in the retransmission request, at least two verification events corresponding to the event identifier contained in the compression identifier are obtained from the preset location, and the at least two verification events are sent to the receiving end. The receiving end is configured to receive each compression event sent by the sending end and execute each compression event; if it is determined after executing any compression event that the execution result does not meet the verification requirements, it sends a retransmission request to the sending end, the retransmission request including the compression identifier of the compression event, and if it receives at least two verification events retransmitted by the sending end, it re-executes the at least two verification events.

2. A processor verification method, characterized in that, The method is applied to a receiving end in a processor verification system, the processor verification system further comprising a sending end, the sending end being communicatively connected to the receiving end; the method includes: Receive each compression event sent by the sending end, and execute each compression event; If, after executing any of the compression events, it is determined that the execution result does not meet the verification requirements, a retransmission request is sent to the sending end. The retransmission request includes the compression identifier of the compression event; the compression identifier includes the event identifiers of at least two verification events corresponding to the compression event. If at least two verification events are received from the sending end and resent, the at least two verification events are re-executed to determine whether the execution result meets the verification requirements; The sending end is configured to respond to any verification event triggered by the processor design under test, assign an event identifier to the verification event, and cache the verification event and the corresponding event identifier in a preset location; compress at least two verification events to obtain compressed events corresponding to the at least two verification events; add a compression identifier to the compressed event, and send the compressed event and the compression identifier to the receiving end; upon receiving a retransmission request from the receiving end, based on the compression identifier carried in the retransmission request, retrieve at least two verification events corresponding to the event identifier contained in the compression identifier from the preset location, and send the at least two verification events to the receiving end.

3. The method according to claim 2, characterized in that, The processor design under test runs at the transmitting end, and a reference model of the processor design under test is deployed at the receiving end.

4. The method according to claim 3, characterized in that, The method further includes: Before executing any of the compression events, the current execution position is set as the latest checkpoint, and the state of the reference model at the latest checkpoint is recorded; During the execution of any of the compression events, data changes relative to the state of the latest checkpoint are recorded as incremental logs.

5. The method according to claim 4, characterized in that, Before re-executing the at least two verification events, the method further includes: The reference model's state is restored to the latest checkpoint based on the incremental log.

6. The method according to claim 3, characterized in that, The method further includes: The current state of the processor design under test is obtained as the first state, and the current state of the reference model is obtained as the second state; If the first state and the second state are consistent, the execution result is determined to meet the verification requirements.

7. The method according to any one of claims 2 to 6, characterized in that, The method further includes: If the execution result does not meet the verification requirements, the components to be optimized in the processor design under test are determined based on the execution result.

8. A processor verification system, characterized in that, The processor verification system includes a transmitter and a receiver, which are communicatively connected. The sending end is configured to respond to any verification event triggered by the processor design under test, assign an event identifier to the verification event, and cache the verification event and the corresponding event identifier in a preset location; The sending end is used to compress at least two verification events to obtain compressed events corresponding to the at least two verification events; The sending end is configured to add a compression identifier to the compression event and send the compression event and the compression identifier to the receiving end; the compression identifier includes the event identifiers of at least two verification events corresponding to the compression event; Upon receiving a retransmission request from the receiving end, the sending end is compressed based on the retransmission request, and at least two verification events corresponding to the event identifier contained in the compression identifier are obtained from the preset location, and the at least two verification events are sent to the receiving end. The receiving end is used to receive each compression event sent by the sending end and execute each compression event; The receiving end is configured to send a retransmission request to the sending end if the verification requirements are not met after executing any of the compression events. The retransmission request includes the compression identifier of the compression event. Upon receiving at least two verification events retransmitted by the sending end, the receiving end will re-execute the at least two verification events.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

11. A computer program, characterized in that, The computer program is executed by a computer to implement the method as described in any one of claims 1-7.

Images