Instruction execution verification method and device, computer device, readable storage medium and program product

Abstract

The application relates to a verification method and device of instruction execution, a computer device, a computer readable storage medium and a computer program product. The method comprises the following steps: responding to a verification request for execution of a target instruction in an instruction execution module; establishing a virtual monitoring interface corresponding to at least one target data path included in the instruction execution module in a preset simulation test platform; the target data path is used for transmitting data related to instruction execution between functional units inside the instruction execution module; collecting interaction signals transmitted in the target data path through the virtual monitoring interface; identifying the interaction signals to obtain an execution process record of the target instruction in the instruction execution module; comparing the execution process record with a pre-stored standard execution process to obtain a verification result corresponding to the verification request. The method can improve the efficiency and accuracy of instruction execution verification.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for verifying instruction execution. Background Technology

[0002] With the development of graphics processing units (GPUs) and high-performance parallel computing technologies, the microarchitecture design of GPUs has become increasingly complex. In order to improve computing throughput and energy efficiency, modern GPUs generally adopt a single instruction multiple threads (SIMT) execution model, and highly integrate multiple vector execution units and scalar execution units within the same instruction execution module.

[0003] Functional verification of the instruction execution module is crucial. In related technologies, the functional verification methods for the instruction execution module generally involve indirectly obtaining instruction execution results through external interfaces for comparison, or pre-implanting debug bus or backdoor access logic in the hardware design to read the values ​​of internal registers. However, these related technologies suffer from limitations in applicable scenarios and suffer from high verification costs and low efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide an instruction execution verification method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve the efficiency of instruction execution verification in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for verifying instruction execution, comprising:

[0006] In response to a verification request regarding the execution status of the target instruction in the instruction execution module;

[0007] In a pre-set simulation test platform, a virtual monitoring interface is established corresponding to at least one target data path included in the instruction execution module; the target data path is used to transmit data related to instruction execution between functional units within the instruction execution module;

[0008] The interactive signals transmitted in the target data path are collected through the virtual monitoring interface.

[0009] The interaction signals are identified to obtain the execution process record of the target instruction in the instruction execution module;

[0010] The execution process record is compared with the pre-stored standard execution process to obtain the verification result corresponding to the verification request.

[0011] In some embodiments, identifying the interaction signal to obtain the execution process record of the target instruction in the instruction execution module includes:

[0012] Based on the instruction identifier, identify the data transmission event associated with the target instruction from the interaction signal;

[0013] If the data transmission event includes multiple sub-transmission events, extract the transmission data segments corresponding to each sub-transmission event from the interaction signal;

[0014] Based on the control signal characteristics in the interaction signal, it is determined whether all the sub-transmission events of the target instruction on the target data path have been completed;

[0015] If all the sub-transmission events are completed, the transmission data segments corresponding to each sub-transmission event are integrated to obtain the execution process record corresponding to the target instruction.

[0016] In some embodiments, the instruction execution module includes an operand acquisition unit, an execution unit, and a result write-back unit; the target data path includes a first data path, a second data path, and a third data path; the first data path is used to transmit operands between the operand acquisition unit and the execution unit; the second data path is used to transmit execution results between the execution unit and the result write-back unit; the third data path is used to transmit write-back data between the result write-back unit and the storage target.

[0017] The execution process record includes input operand data, intermediate result data, and write-back data; the process of identifying the interaction signals to obtain the execution process record of the target instruction in the instruction execution module includes:

[0018] Identify the operand data of the target instruction input from the first data path;

[0019] Identify the intermediate result data submitted by the execution unit to the result write-back unit from the second data path;

[0020] The write-back data written to the storage target by the result write-back unit is identified from the third data path.

[0021] In some embodiments, identifying the input operand data of the target instruction from the first data path includes:

[0022] Monitor the virtual monitoring interface corresponding to the first data path, and identify the first action of sending operands to the execution unit based on the validity identifier in the interaction signal;

[0023] If the first initiation behavior is detected, the instruction identifier associated with the first behavior is recorded, and a collection sequence based on a predefined fixed cycle length is initiated; the fixed cycle length is configured to be equal to or greater than the maximum number of cycles required for all types of instructions to completely transmit all their operands on the data path;

[0024] In each predetermined period of the acquisition sequence, a data segment corresponding to the current period is acquired from the interaction signal; the predetermined period has a preset mapping relationship with the operand source or transmission sequence;

[0025] After the acquisition sequence completes all predetermined fixed cycles, all data segments acquired in sequence are associated with the instruction identifier and merged into the input operand data set of the target instruction; wherein, the input operand data set includes all data acquired within the fixed cycle length.

[0026] In some embodiments, identifying the intermediate result data submitted by the execution unit to the result write-back unit from the second data path includes:

[0027] Monitor the virtual monitoring interface corresponding to the second data path, and identify the second action of the execution unit submitting the execution result to the result write-back unit based on the result validity identifier in the interaction signal;

[0028] If the second behavior is detected, the instruction identifier associated with the second starting behavior is recorded, and a collection sequence based on a predefined submission mode or a fixed period length is initiated; the submission mode or fixed period length is configured to cover a complete submission process that can generate all types of intermediate results by the instruction execution module.

[0029] At each stage of the acquisition sequence, a data segment corresponding to the current stage is acquired from the interaction signal;

[0030] After the acquisition sequence completes all predefined stages, all data fragment sequences acquired in sequence are associated with the instruction identifier and merged into the intermediate result data of the target instruction.

[0031] In some embodiments, identifying the write-back data written to the storage target by the result write-back unit from the third data path includes:

[0032] The virtual monitoring interface corresponding to the third data path is monitored, and the third action of the result write-back unit performing a write operation on the storage target is identified based on the write enable flag and write address flag in the interaction signal.

[0033] If the third behavior is detected, the write address and write data are extracted from the interaction signal and used as the write-back data.

[0034] In some embodiments, the method further includes:

[0035] For at least one of the input operand data, intermediate result data, and write-back data, obtain the program counter value and thread bundle identifier corresponding to the current data;

[0036] Based on the thread bundle identifier, the current data is allocated to the cache queue corresponding to the thread bundle identifier;

[0037] The step of comparing the execution process record with the standard execution process corresponding to the target instruction to obtain the verification result corresponding to the execution status verification request includes:

[0038] The data of the standard execution process is retrieved based on the program counter value of the data retrieved from the cache queue, and compared to generate the verification result.

[0039] In some embodiments, establishing a virtual monitoring interface corresponding to the target data path included in the instruction execution module in a preset simulation test platform includes:

[0040] Analyze the hardware description code of the instruction execution module to identify the interconnection signals between the functional units constituting the target data path;

[0041] In the simulation test platform, a monitoring signal group corresponding to the interconnection signal is defined to construct the virtual monitoring interface; wherein, the timing relationship of the monitoring signal group is configured to match the actual transmission timing of the target data path;

[0042] The process of collecting interactive signals transmitted in the target data path through the virtual monitoring interface includes:

[0043] The interconnection signal in the hardware description code is led out to the monitoring logic of the simulation test platform via the virtual monitoring interface, so as to obtain the signal value of the interconnection signal as the interaction signal during the simulation process.

[0044] Secondly, this application also provides an instruction execution verification device, comprising:

[0045] The response module is used to respond to verification requests regarding the execution status of the target instruction in the instruction execution module;

[0046] A module is established to create a virtual monitoring interface in a preset simulation test platform that corresponds to at least one target data path included in the instruction execution module; the target data path is used to transmit data related to instruction execution between functional units within the instruction execution module.

[0047] The acquisition module is used to acquire interactive signals transmitted in the target data path through the virtual monitoring interface;

[0048] The identification module is used to identify the interaction signals and obtain the execution process record of the target instruction in the instruction execution module;

[0049] The comparison module is used to compare the execution process record with the pre-stored standard execution process to obtain the verification result corresponding to the verification request.

[0050] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in the verification method embodiment for executing any of the foregoing instructions.

[0051] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps included in the verification method embodiment for executing any of the foregoing instructions.

[0052] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps included in the verification method embodiment for executing any of the foregoing instructions.

[0053] The aforementioned verification methods, apparatus, computer devices, computer-readable storage media, and computer program products for instruction execution establish virtual monitoring interfaces corresponding to internal target data paths. This enables the creation of observation points at the source of data generation (between internal functional units), resolving the blind spot problem caused by the instruction execution module's internal data not being exposed to external interfaces, and achieving direct access to the internal data flow. The non-intrusive signal extraction mechanism, obtained through the virtual monitoring interface, eliminates the need to insert debugging logic or modify code in the hardware design, avoiding the increased design complexity, resource consumption, and potential functional interference associated with traditional intrusive methods. This ensures the purity of the object being verified, thereby guaranteeing the accuracy of instruction execution verification. By identifying the interactive signals and obtaining execution process records, the original, low-level signal flow is automatically transformed into high-level, semantic instruction event records. This overcomes the drawbacks of traditional methods that rely on manual waveform analysis or indirect inference, improving the automation level of verification and data analysis efficiency. This invention achieves automated and accurate result verification based on internal direct observation data by comparing the execution process record with pre-stored standards, thus solving problems such as verification blind spots, intrusive modifications, low efficiency, and insufficient automation. Attached Figure Description

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

[0055] Figure 1 This is a diagram illustrating the application environment of a verification method for instruction execution in one embodiment.

[0056] Figure 2 This is a flowchart illustrating the verification method for instruction execution in one embodiment;

[0057] Figure 3 This is a schematic diagram of the data flow within the instruction execution module in one embodiment;

[0058] Figure 4 This is a schematic diagram of the verification result in the verification method of instruction execution in another embodiment;

[0059] Figure 5 This is a structural block diagram of a verification device for instruction execution in one embodiment;

[0060] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0062] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms used in this application include and have, and any variations thereof, are intended to cover non-exclusive inclusion. The term "multiple" in this application refers to two or more. The terms used in this application and / or refer to one of the embodiments, or any combination of multiple embodiments.

[0063] Explanation of related terms:

[0064] GPU (Graphics Processing Unit): A microprocessor specifically designed for handling graphics and parallel computing tasks.

[0065] Vector processor: A processor capable of executing vector instructions.

[0066] EU (Execution Unit): Instruction execution module, which may include vector execution units and scalar execution units.

[0067] ALU (Arithmetic Logic Unit): A component of the execution unit (EU) responsible for performing arithmetic and logical operations.

[0068] Vector Execution Unit (VLU) & Scalar Execution Unit (SLU): These are two different types of computational cores within the GPU Instruction Execution Module (EU). VLU: Each VLU can process data from one thread, suitable for SIMT (Single Instruction, Multithreaded) operations, and capable of parallel operations such as floating-point, fixed-point, and logical operations. Scalar Execution Unit: A serial computation core that processes only one data point / one thread at a time, also capable of performing various single-data operations.

[0069] SIMT (Single Instruction Multithreaded): A parallel execution model for GPUs. A single instruction can control multiple threads (a warp) to execute the same operation simultaneously, but each thread processes its own data.

[0070] Warp (thread bundle): The basic unit of parallel execution in SIMT. For example, a SIMT32 Warp means that a single instruction can allow 32 threads to execute in parallel. Each Warp has a unique ID for identification.

[0071] PC (Program Counter) is a register that stores the address in memory of the next instruction to be executed.

[0072] PC value: Key information used to identify and order instructions. For each warp, instructions are executed sequentially based on the PC value.

[0073] TB (Testbench): In hardware design, a software environment or set of programs used to verify the correctness of the design.

[0074] RTL (Register Transfer Level): A design abstraction level used to describe the behavior of digital circuits, focusing on data flow and logic operations between registers, and can refer to the GPU hardware design code itself to be verified.

[0075] Scoreboard: A component in the validation environment used to temporarily store, sort, and compare data monitored from the design under test (DUT) with expected data.

[0076] Golden (Golden Model): In validation, it refers to a behavioral model, software simulator, or set of expected results that is known to be correct or serves as a reference standard.

[0077] Stage: Refers to the different parts of the processor pipeline where an instruction is processed. Execution units may write back results in different execution stages.

[0078] valid (valid signal): A commonly used control signal in digital circuits, used to indicate whether the data on the current data bus is valid and available.

[0079] In GPU computing, kernel refers to a set of programs or functions that execute in parallel on the GPU.

[0080] cycle: clock cycle, the basic time unit for synchronous operation of digital circuits.

[0081] Dependency refers to the relationship between instructions, such as an instruction waiting for the result of a previous instruction as input.

[0082] Debug bus: A set of signal lines introduced into the hardware design for debugging purposes, used to access internal states.

[0083] Before describing the embodiments of the present invention, the related technologies and their existing problems will be further explained:

[0084] In instruction execution modules employing a single-instruction, multi-threaded design, the operand source registers and result destination registers are typically integrated within the instruction execution module to achieve higher data access bandwidth and lower access latency. In the integrated circuit design flow, functional verification of the aforementioned instruction execution module is a crucial step in ensuring the correctness of the chip design.

[0085] In module-level verification, if the operands of an instruction originate from registers integrated in other modules, or if the result needs to be written back to registers integrated in other modules, the operands and instruction execution results during the simulation can be obtained through the interaction interface with other modules and compared with Golden to verify the correctness of instruction execution. However, when the source register of the operands or the destination register for the result write-back is integrated inside the instruction execution module, since the information is not exposed to the external interface, other verification methods are required.

[0086] One conventional approach is to use the destination register of the instruction to be verified as the source register of operands for subsequent instructions after the instruction has been executed, and to make the destination register of the subsequent registers external registers. This exposes the execution results of the subsequent instructions to the external interface of the instruction execution module, indirectly proving the correctness of the preceding instruction's execution. The drawback of this approach is that it requires adding extra instructions after each instruction to be verified, which is not conducive to generating random tests and prolongs simulation time. Furthermore, this method is not used for cases where the destination register cannot serve as the source register.

[0087] The second conventional approach is to read the values ​​of the source and destination registers via debug bus or backdoor read operations. However, this method is only suitable for instructions with explicitly defined register addresses. For registers whose addresses require additional internal logic processing, this method is not applicable. Furthermore, to perform read operations, a large amount of timing-dependent logic needs to be added to the verification environment, making the verification environment cluttered and lacking readability.

[0088] Alternatively, the logic of the vector execution unit and scalar execution unit in the instruction execution module can be separated for formal verification. Formal verification can accurately verify the ALU part, but it cannot verify the logic for obtaining operands or writing back results.

[0089] In summary, traditional instruction verification methods have at least the following limitations: First, when the operands or results of an instruction flow entirely between internal registers within the module, this information is not exposed to the module's external interface, making direct verification through conventional interface monitoring methods impossible. Second, methods that indirectly expose internal data by inserting additional transfer instructions not only disrupt the original instruction flow and prolong simulation time but are also unsuitable for all types of registers. Furthermore, relying on intrusive methods such as debug buses requires modifications to the hardware design itself, increasing design complexity, and its access scope and real-time performance are limited, making it difficult to adapt to high-speed, variable pipelined data flows. Additionally, while formal verification methods can partially verify computational logic, they cannot cover dynamic timing behaviors such as operand fetching and result write-back.

[0090] Given that instruction execution modules (such as the CUDA Core array of a streaming multiprocessor (SM) in a GPU, or the tensor computation unit in an AI accelerator) typically employ deep pipelines and multi-level internal cache / register designs, the core bottleneck faced by traditional verification methods when verifying such modules lies in the fact that when the operands of the instructions come directly from the module's internal register file, or when the computation results need to be written back to the module's internal dedicated accumulator, this critical data is not visible on the module's external input / output (I / O) pins.

[0091] Therefore, how to directly, accurately, and completely capture the information flowing in such internal data paths without interfering with the normal function of the hardware or changing its original instruction flow, so as to achieve efficient and accurate module-level verification, is a technical problem that needs to be solved.

[0092] The instruction execution verification method provided in this embodiment of the invention can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Server 104 responds to a verification request regarding the execution status of a target instruction in the instruction execution module; this verification request can be sent by terminal 102. Server 104 establishes a virtual monitoring interface in a preset simulation test platform corresponding to at least one target data path included in the instruction execution module. The target data path is used to transmit data related to instruction execution between functional units within the instruction execution module. Through the virtual monitoring interface, interactive signals transmitted in the target data path are collected. Server 104 identifies the interactive signals to obtain a record of the execution process of the target instruction in the instruction execution module. The execution process record is compared with a pre-stored standard execution process to obtain a verification result corresponding to the verification request, which can be returned to terminal 102. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0093] In one exemplary embodiment, such as Figure 2 As shown, a method for verifying instruction execution is provided, which is applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0094] Step 202, in response to a verification request regarding the execution status of the target instruction in the instruction execution module.

[0095] The target instruction refers to the specific machine instruction whose execution is to be verified, such as a floating-point multiply-accumulate instruction of a GPU.

[0096] An instruction execution module refers to the functional unit in a hardware design that specifically executes instruction operations. For example, it could be a module in a GPU that integrates vector execution units and scalar execution units.

[0097] A verification request is a trigger instruction or data structure that initiates this verification process. The verification request can be generated by the verification platform's test scheduler when it loads and parses the verification environment to begin running a specific test case containing the target instruction. This request contains identification information of the target instruction (such as the program counter PC range or opcode) and instance information of the target module, thereby requesting a check on at least one of the following: functionality, timing, and integrity of the specific instruction in a specific hardware module.

[0098] The execution status refers to the performance of the target instruction throughout its entire lifecycle in the hardware, and may include at least one of the following: (1) Functional correctness: whether the computation result of the instruction conforms to the mathematical definition of the instruction set architecture; (2) Timing compliance: whether the delivery of operands, computation start-up, result generation and write-back, etc. meet the pipeline timing and delay defined in the design specifications; (3) Behavioral integrity: whether all operands required by the instruction are fully acquired and whether all results that should be generated are fully output.

[0099] Step 204: In a preset simulation test platform, establish a virtual monitoring interface corresponding to at least one target data path included in the instruction execution module; the target data path is used to transmit data related to instruction execution between functional units within the instruction execution module.

[0100] The simulation test platform can be a software environment built on a preset hardware description language (such as System Verilog) to simulate hardware behavior, apply stimuli, and check its response.

[0101] The target data path can be a data transmission path within the instruction execution module that connects its key sub-functional units (such as the operand fetch unit, execution unit, and result write-back unit) for transmitting instruction operands or results. These paths are internal connections necessary for the module to perform its normal functions.

[0102] A virtual monitoring interface is an abstract communication protocol container (e.g., an interface defined in SystemVerilog) defined within a simulation test platform. The signals defined within it correspond to the physical signals on the target data path to be monitored, thus serving as a bridge or proxy for the test platform's monitoring logic to access the internal hardware signals of the instruction execution module. Specifically, the establishment process of the virtual monitoring interface may include: based on an understanding of the instruction execution module's hardware description code, identifying the interconnection signal groups between its internal functional units (such as operand fetch logic, arithmetic logic unit, and result write-back control logic). These interconnection signal groups constitute the target data path. In this embodiment of the invention, an interface can be defined in the test platform code, and the signal variables (name, bit width) declared in the interface correspond to the identified interconnection signal groups. Furthermore, through the cross-level signal binding function provided by simulation tools (such as VCS, Xcelium) (e.g., SystemVerilog's bind statement), during the simulation compilation or initialization phase, an instance of this interface can be bound to the actual network (Net) of the corresponding interconnection signal in the RTL design level. It should be noted that, in this embodiment of the invention, this operation only occurs at the internal connection database level of the simulator and does not involve any additions, deletions, or modifications to the original RTL source code files. Therefore, the RTL design remains pure, and its functionality, timing, and area characteristics are not affected in any way. By establishing a virtual interface mapped to the internal functional paths, rather than modifying the hardware RTL code, signals are extracted, creating conditions for observing the internal data flow without changing the design being verified itself.

[0103] Step 206: Collect the interactive signals transmitted in the target data path through the virtual monitoring interface.

[0104] In this system, after the virtual monitoring interface is connected to the internal signals of the RTL, any level change on the RTL signal network will be mapped to the corresponding variable on the test platform side interface in real time and synchronously during simulation. By reading these interface variables through the virtual monitoring interface, the instantaneous values ​​of the internal signals of the RTL can be obtained, thereby achieving direct and real-time capture of the internal functional signals of the instruction execution module.

[0105] Interactive signals refer to the sequence of electrical signal values ​​that change on the physical connection of the target data path, actually acquired through a virtual monitoring interface. They can include data signals (such as specific operands or result values) and control signals (such as a valid signal indicating valid data). In this embodiment of the invention, since the signals originate from existing functional paths rather than hardware added specifically for debugging, the captured data has high fidelity and does not affect the original hardware functionality. This overcomes the shortcomings of traditional methods that rely on indirect observation through the insertion of additional instructions or access via a bandwidth-limited debug bus.

[0106] Step 208: Identify the interaction signal to obtain the execution process record of the target instruction in the instruction execution module.

[0107] The identification process refers to the parsing, filtering, and reconstruction of the original signal stream. For example, valid data is identified based on the valid signal, and the data is associated with a specific instruction based on the program counter (PC) or warp ID information in the signal. Specifically, the identification process can include the following two logical levels: Transaction layer identification: This includes segmenting a complete data transmission transaction from a continuous signal waveform based on interface protocols (such as handshake signals). For example, identifying an operand transfer that was successfully handshaked by the valid and ready signals. Instruction layer association and encapsulation: This includes associating transaction layer events with specific instructions, which can be achieved by extracting instruction identification information (such as program counter values ​​and warp IDs) from the signals. Subsequently, the data payload (such as operand values) in the transaction is packaged with this identification information to obtain an atomic record. For an instruction that may generate multiple data transactions, the system will continuously collect multiple atomic records.

[0108] Correspondingly, the execution process record is the result of instruction-level association and encapsulation. It is not a single numerical value, but a collection of data that can be organized according to instructions. For a target instruction, its execution process record may contain multiple atomic records, corresponding to the input events of its different operands, the generation events of different intermediate results, etc., and may contain data content (such as operand values) and context information (such as the PC and Warp ID of the instruction). These records together describe the data activity trajectory of the instruction within the module.

[0109] In this embodiment of the invention, the underlying, time-related signal stream is transformed into upper-level, instruction-level events with clear semantics. This greatly facilitates subsequent automated comparison and manual debugging. Relevant maintenance personnel no longer need to deal with massive amounts of raw waveforms, but can directly view clear instruction execution logs, which can significantly improve the verification efficiency and debugging friendliness of instruction execution.

[0110] Step 210: Compare the execution process record with the pre-stored standard execution process to obtain the verification result corresponding to the verification request.

[0111] The standard execution process refers to the expected behavior and result of executing a target instruction, obtained in advance through a software simulator, instruction set simulator, or other reliable means. It can originate from the golden model, such as an instruction set simulator. This model can provide the expected output of instruction execution based on the instruction program counter (PC) and initial state, including the expected operands, intermediate values, and final result.

[0112] The comparison process may include a verification system (such as a scoreboard) receiving atomic records from the execution process log, retrieving the corresponding expected values ​​from the gold standard model using the program counter value as the primary index, and comparing the actual data in the records with the expected values ​​item by item according to the required precision. The verification result is the comparison result, which can be either pass or fail, and may include detailed error information.

[0113] The embodiments of the present invention are based on reconstructed data captured directly from the hardware and cross-validated with standard behavioral models in real time and with accuracy. This can automatically determine whether the execution of target instructions (function, timing, and completeness) meets expectations, thereby providing reliable data support for subsequent steps such as quickly and reliably exposing defects in hardware design.

[0114] This invention, through the synergistic effect of non-invasive signal mirroring, intelligent semantic reconstruction, and automated precise comparison, forms a complete internal data flow verification system. It can directly, comprehensively, and efficiently verify the internal instruction execution process while maintaining the purity of the hardware design, thereby effectively solving the technical problems of blind spots in internal signal verification, highly invasive verification methods, low efficiency, and insufficient automation in related technologies.

[0115] In some embodiments, identifying the interaction signal to obtain the execution process record of the target instruction in the instruction execution module includes:

[0116] Based on the instruction identifier, identify the data transmission event associated with the target instruction from the interaction signal;

[0117] If the data transmission event includes multiple sub-transmission events, extract the transmission data segments corresponding to each sub-transmission event from the interaction signal;

[0118] Based on the control signal characteristics in the interaction signal, it is determined whether all the sub-transmission events of the target instruction on the target data path have been completed;

[0119] If all the sub-transmission events are completed, the transmission data segments corresponding to each sub-transmission event are integrated to obtain the execution process record corresponding to the target instruction.

[0120] Instruction identifiers refer to information that can uniquely or with a high probability associate data transmission behavior with a specific instruction. In this embodiment of the invention, the instruction identifier can be a program counter value. In parallel architectures (such as GPUs), thread bundle identifiers are used to distinguish different parallel instruction streams; in modules that support out-of-order execution, instruction tags dispatched by the front end may also be included. This identification information typically exists as accompanying signals in the interaction signals, or can be deduced by monitoring earlier instruction dispatch pipelines.

[0121] A data transmission event refers to a valid data transfer transaction identified on a virtual monitoring interface according to a predefined interface protocol (e.g., the setting of the valid signal). A valid data transfer transaction signifies that a data packet (such as an operand or a result) has begun or is in the process of passing through the data path. This embodiment of the invention utilizes instruction identifiers as information anchors to initially classify continuous, undifferentiated signal streams at the physical layer into discrete events belonging to different instructions. This lays the foundation for subsequent refined data extraction and aggregation, solving the source identification problem under the interweaving of multiple instruction data streams.

[0122] A subtransmission event refers to a single valid data transfer at a finer time granularity that constitutes a complete data transmission event. For example, in a typical synchronous digital circuit, a single data transfer accompanied by a valid flag within one clock cycle constitutes a subtransmission event.

[0123] A transmitted data segment refers to the valid data payload extracted from the interaction signal corresponding to a single subtransmission event. For example, the value sampled from the data bus op_data in the first valid cycle of the operand path constitutes a data segment.

[0124] Considering that the data required for certain instructions (such as multiple operands or multiple result components) may need to be transmitted over multiple cycles (i.e., multiple sub-transmission events), each data segment can be periodically and continuously sampled and extracted from the interactive signals during the duration of the data transmission event. By capturing the scattered and fragmented signal values ​​over a period of time into independent data units in chronological order, the acquisition of the original information without omission is ensured, thereby achieving fine-grained acquisition of cross-cycle data packets. It can handle the actual situation where instruction data is delivered in multiple cycles, preparing for subsequent data integrity reconstruction.

[0125] Control signal characteristics are signals or signal patterns used to regulate the boundaries, rhythm, and state of data transmission, and may not directly carry data. For example: a valid signal to indicate the validity of a single transmission, a last signal to indicate the end of a data packet, a tag signal sequence to distinguish the ownership of a data packet, or a fixed number of results submitted corresponding to a specific instruction type. Specifically, the control signal characteristics in the interaction signals are continuously analyzed by a preset decision maker (such as a state machine or a counter) to determine whether all expected sub-transmission events belonging to the same target instruction have occurred according to preset rules. The determination criteria may include: (1) count matching: when the number of extracted data fragments reaches the expected total number for the instruction type (this total number can be obtained by decoding the accompanying instruction opcode); (2) protocol identification: directly detecting a specific signal (such as last) that indicates the end of transmission; (3) sequence matching: identifying at least one of a complete specific control signal sequence (such as a C / D signal sequence) that represents the submission of all results of the instruction.

[0126] Multiple discrete data segments belonging to the same target instruction, collected and temporarily stored, are assembled into a coherent, structured data object according to their acquisition order (or based on the sequence information inherent in the segments). For example, three operand segments belonging to a single instruction are assembled into an array [op0, op1, op2], resulting in a complete data record for a single target instruction on a single target data path, serving as the execution process record. It is understandable that the final complete execution process record of an instruction may be composed of such records produced on multiple data paths (such as the operand path and the result path). This reconstructs the temporally dispersed raw data into a logically complete instruction-level data object that can be directly used for comparison. This allows the verification system to clearly understand hardware behavior from the perspective of instructions and data paths, providing well-formatted and meaningful input data for accurate and efficient comparison with the gold standard model.

[0127] In some embodiments, the instruction execution module includes an operand acquisition unit, an execution unit, and a result write-back unit; the target data path includes a first data path, a second data path, and a third data path; the first data path is used to transmit operands between the operand acquisition unit and the execution unit; the second data path is used to transmit execution results between the execution unit and the result write-back unit; the third data path is used to transmit write-back data between the result write-back unit and the storage target.

[0128] The execution process record includes input operand data, intermediate result data, and write-back data; the process of identifying the interaction signals to obtain the execution process record of the target instruction in the instruction execution module includes:

[0129] Identify the operand data of the target instruction input from the first data path;

[0130] Identify the intermediate result data submitted by the execution unit to the result write-back unit from the second data path;

[0131] The write-back data written to the storage target by the result write-back unit is identified from the third data path.

[0132] Based on an understanding of the microarchitecture of modern processors, especially graphics processing units (GPUs), the complete lifecycle of an instruction—from data preparation and computation to result write-to-disk—generally follows an input-processing-output paradigm in its data flow. Therefore, in this embodiment, the instruction execution module can be a hardware logic set comprising three core functional units that collectively complete the entire instruction input-processing-output process. These three core functional units are: an operand acquisition unit, responsible for reading and preparing the source operands required for the instruction from storage structures such as register files and caches; an execution unit, containing various computational cores (such as vector / scalar ALUs and floating-point units), receiving operands and executing the operations defined by the instruction; and a result write-back unit, responsible for receiving and processing the raw results generated by the execution unit and ultimately writing them to the target storage location.

[0133] Correspondingly, the aforementioned three stages of input-processing-output are typically handled by physically or logically separated dedicated hardware units. The interfaces between these units serve as channels for data flow and are also the best observation points for verifying data integrity. Therefore, based on the above module structure, this embodiment of the invention abstracts the internal data flow into three target data paths, namely, data channels connecting the three functional units respectively:

[0134] The first data path (operand supply line) is used to transfer operands between the operand fetch unit and the execution unit. For example, it can be a bus connecting the vector register file read port to the vector ALU input buffer (for transferring operands required by instructions such as VADD), a dedicated bus connecting the scalar register file to the scalar ALU, a path from the output interface of the constant cache or shared memory to the input of the execution unit, the output bus of the operand collection unit (for summarizing and aligning operands from multiple sources), etc.

[0135] By monitoring the first data path, it is possible to verify whether the hardware correctly, completely, and timely delivers all the source data required by the instruction to the computing engine, that is, to verify the premise of ensuring the correctness of instruction execution.

[0136] The second data path (raw result transport line) is used to transmit execution results between the execution unit and the result write-back unit. For example, it can be the output bus of a vector ALU / FPU, sending calculation results to the write-back queue or result assembly unit; a scalar result path, transmitting scalar results such as addresses and condition codes; and a result return interface of the texture unit / load storage unit.

[0137] Optionally, for complex instructions that produce multiple results (such as vector instructions that output a / b, c, d), the execution unit will submit the results sequentially through time-division multiplexing or a tagged interface. Therefore, monitoring the data, valid signals, and sequence identifier signals (such as C / D signals) on the time-division multiplexing or tagged interface is key to verifying multi-result instructions.

[0138] By monitoring the second data path, it is possible to verify whether the core computational function of the execution unit is correct and whether its output conforms to the pipeline protocol (such as the submission order and timing of multiple results).

[0139] The third data path (final archive write line): used to transfer write-back data between the result write-back unit and the storage target.

[0140] For example, it could be a write port for vector register files (monitoring the wr_en, wr_addr, and wr_data signals), a write port for scalar registers, a write request interface for shared memory / global memory, and an update path for predicate / condition code registers.

[0141] By monitoring the third data path, the endpoint behavior of the entire instruction execution chain can be verified, ensuring that the correct calculation result is atomically written to the correct target location. In this embodiment of the invention, the three monitored data paths collectively cover the data transitions throughout the entire instruction execution chain (comprehensiveness), each carrying different types and stages of data (orthogonality), and all are essential pathways connecting key sub-units (criticality). This provides a clear observation framework for implementing flexible, complete, and in-depth verification.

[0142] Corresponding one-to-one with the three paths mentioned above, this embodiment concretizes the execution process record into three types of data: Input operand data: corresponding to the complete set of operands identified from the first data path, which can be regarded as a raw material list for instruction execution. Intermediate result data: corresponding to the set of raw calculation results identified from the second data path, which can be regarded as the output report of the calculation process. And write-back data: corresponding to the final write transaction (address and data) identified from the third data path.

[0143] Specifically, in this embodiment of the invention, virtual monitoring interfaces can be established and bound to corresponding RTL signals for one or more selected target data paths according to verification requirements. The monitoring logic on each path operates independently, identifying, extracting, and integrating the corresponding input operand data, intermediate result data, or write-back data from the interaction signals. Using a unified instruction identifier (such as a program counter value and a thread bundle identifier), the above three types of data records from different paths belonging to the same instruction are logically associated. For example, the system knows that for the instruction PC=0x8000, Warp=5, its input operands are [A,B], the intermediate result is [C], and the value finally written back to register R3 is C.

[0144] The aforementioned associated and clearly categorized data records together constitute a complete execution process record of the target instruction, which is submitted to the subsequent comparison stage for a comprehensive comparison with the expected input, intermediate output, and final write-back value of the instruction in a standard model (such as the gold model).

[0145] This embodiment concretizes the verification object as an instruction execution module composed of three core units, defines the observation points as three key data paths connecting these three units, and defines the data to be verified as three types of execution process records corresponding to the paths. This constructs a highly specific, implementable, and adaptable verification framework for non-intrusive verification methods, perfectly suited to the microarchitecture of modern processors (such as GPUs). This framework ensures that verification activities systematically cover the entire chain from data preparation and computational execution to result delivery, thereby achieving in-depth and efficient verification of the module's internal functions.

[0146] In some embodiments, identifying the input operand data of the target instruction from the first data path includes:

[0147] Monitor the virtual monitoring interface corresponding to the first data path, and identify the first action of sending operands to the execution unit based on the validity identifier in the interaction signal;

[0148] If the first behavior is detected, the instruction identifier associated with the first behavior is recorded, and a collection sequence based on a predefined fixed cycle length is initiated; the fixed cycle length is configured to be equal to or greater than the maximum number of cycles required for all types of instructions to completely transmit all their operands on the data path.

[0149] In each predetermined period of the acquisition sequence, a data segment corresponding to the current period is acquired from the interaction signal; the predetermined period has a preset mapping relationship with the operand source or transmission sequence;

[0150] After the acquisition sequence completes all predetermined fixed cycles, all data segments acquired in sequence are associated with the instruction identifier and merged into the input operand data set of the target instruction; wherein, the input operand data set includes all data acquired within the fixed cycle length.

[0151] In this embodiment of the invention, considering that multiple operands of an instruction may be delivered to the execution unit asynchronously and over multiple clock cycles, acquisition is driven by a protocol, and acquisition completion is intelligently determined based on the instruction context, ultimately integrating a complete input dataset. The process can be summarized as: triggered acquisition -> continuous extraction -> intelligent determination -> integrated output.

[0152] The validity flag is a control signal used in the first data path interaction to indicate that data is valid. It can be a valid signal (or vld). In the handshake protocol, the simultaneous validity of the valid and ready signals signifies that a transmission has occurred. The first action refers to a valid operand transmission event activated by the aforementioned validity flag. This action can be identified by monitoring signal changes on the virtual interface. For example, detecting a transition from low to high level in the op_valid signal.

[0153] Instruction execution order refers to the order in which operands are expected to be used by the hardware execution unit. This order may be implicit in the data path protocol (such as bus field order) or explicitly indicated by accompanying control information.

[0154] Within the same clock cycle of the first action (or after the protocol-defined setup time), a value is latched from the data bearer signal line of the interaction signal. For example, a 128-bit value is latched from the op_data[127:0] bus. Based on predefined knowledge of the data path format, the latched value is parsed into one or more independent operand values ​​(data fragments). For example, the 128-bit value is parsed into four 32-bit single-precision floating-point numbers. These fragments are sequentially stored in a dedicated buffer associated with the target instruction, thereby converting the physical signal levels into meaningful operand values ​​and organizing them sequentially, providing structured intermediate data for subsequent data integrity checks.

[0155] In this embodiment, the virtual monitoring interface corresponding to the first data path is monitored, and the initial behavior of sending operands to the execution unit is identified as the first behavior based on the validity identifier in the interaction signal. This first behavior is typically identified by setting a validity signal (such as op_valid) accompanying instruction details.

[0156] If the first action is detected, the instruction identifier associated with that action (such as the program counter PC value and the warp ID) is recorded, and a data acquisition sequence based on a predefined fixed cycle length is initiated. The fixed cycle length is configured to be equal to or greater than the maximum number of cycles required for all types of instructions to fully transmit all their operands over the data path. This design ensures complete acquisition capability for the most complex instructions (requiring the most operands) while providing a unified acquisition window for all instructions.

[0157] In each predetermined period of the acquisition sequence, a data segment corresponding to the current period is acquired from the interaction signal. The predetermined period has a preset mapping relationship with the operand source or transmission sequence. For example, the period at which the initial behavior is detected can be defined as period 0, acquiring the first source operand (src1_data) and instruction information; period 1 acquires the second source operand (src2_data); period 2 acquires the third source operand (src3_data). In each predetermined period, the data segment is acquired regardless of whether it is logically valid for the currently executed instruction. This means that even if an instruction only requires two operands, the system will still acquire the signal value on the data bus in the third period.

[0158] After the acquisition sequence completes all predetermined fixed cycles, all sequentially acquired data segments are associated with the instruction identifier and merged into the input operand data set of the target instruction. This set is then output to a subsequent processing module (such as a scoreboard). The input operand data set contains all data acquired within the fixed cycle length. The determination of which data segments in the data set are valid and which are invalid (or irrelevant) is left to the subsequent comparison stage based on instruction semantics (such as through the Golden model or instruction decoding).

[0159] For example: Suppose the system has a preset fixed cycle length of three clock cycles. For an instruction that requires only two operands, after recognizing its initial behavior:

[0160] Phase 0: Acquire the PC, Warp ID, and the first valid operand, operand_a. Phase 1: Acquire the second valid operand, operand_b. Phase 2: Still acquire the value data_on_bus_c on the data bus (which may be an invalid value, zero, or residual data from the previous instruction).

[0161] The final output set of input operand data is [operand_a, operand_b, data_on_bus_c]. If the RTL design has flaws and generates unexpected valid data incorrectly in the second iteration, this data will also be fully recorded, allowing it to be detected in subsequent comparisons with the Golden model and avoiding potential missed errors due to "on-demand data collection." This "full data collection, post-judgment" strategy adopted in this embodiment enhances the rigor of verification and the ability to detect design errors.

[0162] In summary, this embodiment provides a complete verification scheme for the operand input stage, which is triggered by the protocol, collected sequentially, intelligently determined based on the instruction context, and automatically integrated. This provides an accurate and complete input benchmark for the verification of the subsequent calculation process and is a key link in realizing full-link automated verification.

[0163] In some embodiments, identifying the intermediate result data submitted by the execution unit to the result write-back unit from the second data path includes:

[0164] Monitor the virtual monitoring interface corresponding to the second data path, and identify the second action of the execution unit submitting the execution result to the result write-back unit based on the result validity identifier in the interaction signal;

[0165] If the second behavior is detected, the instruction identifier associated with the second behavior is recorded, and a collection sequence based on a predefined submission mode or a fixed period length is initiated; the submission mode or fixed period length is configured to cover a complete submission process that can generate all types of intermediate results by the instruction execution module.

[0166] At each stage of the acquisition sequence, a data segment corresponding to the current stage is acquired from the interaction signal;

[0167] After the acquisition sequence completes all predefined stages, all data fragment sequences acquired in sequence are associated with the instruction identifier and merged into the intermediate result data of the target instruction.

[0168] Considering the complex characteristics of the raw results generated by the execution unit—for example, a single vector instruction may produce multiple data components, and these components may be submitted to the result write-back unit in batches at different pipeline stages or clock cycles—this embodiment of the application needs to accurately aggregate the scattered, seemingly independent result data fragments under their source instruction names and integrate them into a complete intermediate result record. The implementation process may include: identifying submissions, anchoring instructions, continuous data acquisition, intelligent completion determination, and sequential integration.

[0169] Specifically, the result validity identifier can be a control signal in the second data path interaction signal used to indicate that a result submission is valid, such as result_valid, out_vld, or a specific completion pulse. The second action refers to a valid result submission event activated by the aforementioned result validity identifier. This action is identified by monitoring the virtual interface, marking the start of a result data unit moving towards the write-back unit. In this embodiment, the virtual monitoring interface corresponding to the second data path is monitored, and based on the result validity identifier (e.g., result_valid or a specific start pulse) in the interaction signal, the starting action of the execution unit submitting the execution result to the result write-back unit is identified as the second action.

[0170] If the second behavior is detected, the instruction identifier associated with the second behavior is recorded, and an acquisition sequence based on a predefined submission mode or a fixed period length is initiated. The submission mode or fixed period length is configured to cover a complete submission process encompassing all types of intermediate results that the instruction execution module can generate. For example, for a vector execution unit that supports multiple result submissions, its submission mode may be defined by a specific control signal sequence (such as C and D signals); alternatively, the system may use a fixed maximum number of result output beats as the length of the acquisition sequence.

[0171] At each stage of the acquisition sequence, a data segment corresponding to the current stage is acquired from the interaction signal. The acquisition follows a preset pattern or timing sequence and does not depend on real-time judgment of the number of results required by the current instruction.

[0172] After the acquisition sequence completes all predefined stages, all data fragment sequences acquired in sequence are associated with the instruction identifier, merged into the intermediate result data set of the target instruction, and output to the subsequent processing module.

[0173] For example, the result bus of the vector execution unit is monitored, and the signals include vres_valid (valid), vres_pc, vres_data, vres_c_flag, and vres_d_flag. When both vres_valid and vres_c_flag are detected as valid, it marks the start of a multi-result instruction submission.

[0174] Phase 1 (C Phase): Acquire vres_data as the first subset of results (e.g., the result corresponding to register c) and record the C signal. Phase 2 (D Phase): In a subsequent pre-defined timeframe (the next timeframe), acquire vres_data as the second subset of results (e.g., the result corresponding to register d) and record the D signal. The system will execute both phases of acquisition completely, regardless of whether the current instruction theoretically requires a second result (D phase). If the RTL erroneously generates data and sets the D signal when a D result should not exist, this method can acquire the data completely and send it to the comparison stage, thus being identified as an error by the Golden model. This overcomes the problem of potentially missing redundant data outputs when acquiring data solely based on instruction type expectations.

[0175] A similar example is given for the fixed-time submission mode, where all intermediate result submissions are set to be completed within a maximum of two submissions. After detecting the start of a submission, the first result data (res_0) is collected on submission time 0. The second result data (res_1) is collected on submission time 1. The set [res_0, res_1] is output as the intermediate result data set. During subsequent comparisons, the Golden model uses the instruction PC to determine whether the instruction should actually provide one or two valid results, and verifies the collected data accordingly.

[0176] This application provides a verification scheme for the computation output stage, which uses a program counter to precisely anchor instructions, understands and tracks complex submission sequences, intelligently determines data integrity, and automatically integrates data. This method effectively handles complex scenarios such as multiple results and phased outputs, directly verifying the correctness of the execution unit's computational function and the compliance of its output protocol, providing crucial computational process evidence for end-to-end automated verification.

[0177] In some embodiments, identifying the write-back data written to the storage target by the result write-back unit from the third data path includes:

[0178] The virtual monitoring interface corresponding to the third data path is monitored, and the third action of the result write-back unit performing a write operation on the storage target is identified based on the write enable flag and write address flag in the interaction signal.

[0179] If the third behavior is detected, the write address and write data are extracted from the interaction signal and used as the write-back data.

[0180] The third data path carries the final stage of the instruction execution process: atomically writing the processed result data to the target storage location (such as a register file or memory). Unlike the first and second data paths, which may involve the integration of multiple cycles and fragments of data, the verification object on the third path is typically a single, complete, atomic write operation. Therefore, in this embodiment of the invention, it is necessary to capture and record these atomic write operations to verify whether the final result has been correctly and completely written to the specified target address. The implementation process may include identifying write operations, extracting key information, and generating write-back records.

[0181] Specifically, the monitoring virtual monitoring interface corresponding to the third data path identifies the third action of the result write-back unit performing a write operation on the storage target based on the write enable flag and write address flag in the interaction signal. The write enable flag (such as wr_en, write_enable) is a key control signal indicating that a write operation has been initiated and is valid. The write address flag (such as wr_addr) indicates the target location of the data being written. When the monitoring logic detects that the write enable flag is valid (e.g., wr_en is high), it determines that a third action has occurred, i.e., a write operation on the storage target.

[0182] If the third action is detected, the write address and write data are extracted from the interaction signal as the write-back data. At the same sampling moment when write enable is active (typically one clock cycle), the address value (wr_addr) and data value (wr_data) are latched from the corresponding bus of the interaction signal. This (write address, write data) pair itself constitutes a complete write-back data record. This record does not need to wait for completion judgment or multi-segment integration like the preceding path, because it describes a complete hardware atomic transaction. Typically, to associate this write-back record with the source instruction, the instruction identifier associated with the write operation is simultaneously recorded or derived, for example, through the accompanying wr_pc signal or by analyzing the mapping relationship between the write address and the previous result dispatch.

[0183] Taking the final write-back of a scalar addition instruction ADD R5, R3, R4 as an example, this embodiment of the invention is described. The monitoring target is the write port of the Vector Register File (VRF). Key signals include vrf_wr_en (write enable), vrf_wr_addr[6:0] (write address, 0-127 corresponds to R0-R127), vrf_wr_data[31:0] (write data), and vrf_wr_pc[31:0] (associated instruction PC). When the vrf_wr_en signal is detected to be valid in a certain clock cycle, a third action is identified. At the same time, vrf_wr_addr=5 (indicating that the target register is R5), vrf_wr_data=0x0000C350 (decimal 50000), and vrf_wr_pc=0x0A04 are sampled. A write-back data record is then generated, the content of which is: {Associated instruction PC: 0x0A04, Target: VRF, Write address: 5, Write data: 0x0000C350}. This record fully represents this write-back operation.

[0184] This invention provides a verification scheme for directly and atomically capturing the final state update operation at the endpoint of instruction execution. It identifies write transactions by monitoring write enable and write address signals and directly extracts the core elements (address and data) constituting the transaction to form a record. This method verifies the correctness of the final output of the entire instruction execution chain, ensuring that the calculated correct result is stored error-free in the location specified by the architecture state. It is the key and final step in achieving a closed-loop verification and ensuring the continuity of program state.

[0185] In some embodiments, the method further includes:

[0186] For at least one of the input operand data, intermediate result data, and write-back data, obtain the program counter value and thread bundle identifier corresponding to the current data;

[0187] Based on the thread bundle identifier, the current data is allocated to the cache queue corresponding to the thread bundle identifier;

[0188] The step of comparing the execution process record with the standard execution process corresponding to the target instruction to obtain the verification result corresponding to the execution status verification request includes:

[0189] The data of the standard execution process is retrieved based on the program counter value of the data retrieved from the cache queue, and compared to generate the verification result.

[0190] In particular, in a parallel, multi-threaded processor (such as GPU) verification environment, how to efficiently and orderly organize, cache, and schedule the large amount of messy instruction execution data asynchronously collected from different data paths, so as to ensure that the subsequent comparison stage can quickly and accurately correlate and verify the actual data with the correct expected value.

[0191] Specifically, for at least one of the input operand data, intermediate result data, and write-back data, the program counter value and thread bundle identifier corresponding to the current data are obtained. This crucial contextual information has already been embedded into each data record during the data acquisition phase (e.g., PC record, WarpID). The program counter value is a key that uniquely identifies the position of an instruction in the program flow, while the thread bundle identifier is used to distinguish parallel thread groups in a SIMT architecture. Obtaining these two identifiers lays the foundation for subsequent data routing and indexing.

[0192] Based on the thread bundle identifier, the current data is allocated to the cache queue corresponding to that thread bundle identifier. In practice, the verification platform dynamically maintains an independent first-in-first-out (FIFO) cache queue for each thread bundle identifier that may be active in the simulation. When a data record (such as an input operand, intermediate result, or write-back data) is produced, it is pushed to the tail of the dedicated queue of the corresponding thread bundle according to its embedded WarpID. This operation achieves data isolation by execution context, physically separates parallel data streams from different thread bundles, avoids cross-contamination, and naturally maintains the original temporal order of data generation within the same thread bundle through the characteristics of the FIFO queue. This is crucial for verifying the order-preserving execution of instructions within a single thread bundle.

[0193] Based on the program counter value of the data retrieved from the cache queue, the data of the standard execution process is searched and compared to generate the verification result. The comparison phase (usually performed by a separate checker module) retrieves data records from the head of each thread bundle cache queue in a polling or event-driven manner. After retrieving a record, the checker uses its program counter value as a unique query key to query the standard execution process model (such as an instruction set simulator or a pre-generated golden model database) to retrieve the expected data (including expected operands, intermediate results, and final write-back value) of the instruction corresponding to that PC. Subsequently, the checker compares the actual data in the record with the retrieved expected value field-by-field, according to the required precision. If they are completely consistent, the record verification passes; if any inconsistency exists, a detailed error report is immediately generated, including at least the erroneous PC, WarpID, data type, actual value, expected value, and simulation timestamp, and the verification result is marked as failed.

[0194] Taking the GPU dual-threaded execution scenario as an example, the following data was collected sequentially: the input operand data [1.0, 2.0] and write-back data {addr: R3, data: 3.0} of the VADD instruction (PC=0x1000) in Warp 1; and the intermediate result data [3.5] of the FMUL instruction (PC=0x2000) in Warp 2. According to the WarpID, the first two records were routed to the Warp 1 queue, and the third record was routed to the Warp 2 queue. When the checker was working, it retrieved the input operand record from the Warp 1 queue in sequence, queried the golden model using PC=0x1000 to obtain the expected operand [1.0, 2.0], and the comparison passed; then it retrieved the write-back record from the same queue, queried the expected write-back value R3=3.0 using the same PC, and the comparison passed; then it retrieved the intermediate result record from the Warp 2 queue, queried the expected result [3.5] using PC=0x2000, and the comparison passed. The entire process enabled automatic, orderly, and accurate data comparison.

[0195] This embodiment constructs a two-layer data management system based on thread bundle identifier routing and program counter value indexing. This transforms the complex, concurrent data acquisition and output at the front end into a serial comparison task that can be processed efficiently and reliably at the back end. It ensures the orderliness of massive parallel verification data and guarantees that each actual data point matches a unique and correct expected value. This is a key step in ensuring reliability and improving efficiency for large-scale, high-concurrency processor module automated verification.

[0196] In some embodiments, establishing a virtual monitoring interface corresponding to the target data path included in the instruction execution module in a preset simulation test platform includes:

[0197] Analyze the hardware description code of the instruction execution module to identify the interconnection signals between the functional units constituting the target data path;

[0198] In the simulation test platform, a monitoring signal group corresponding to the interconnection signal is defined to construct the virtual monitoring interface; wherein, the timing relationship of the monitoring signal group is configured to match the actual transmission timing of the target data path;

[0199] The process of collecting interactive signals transmitted in the target data path through the virtual monitoring interface includes:

[0200] The interconnection signal in the hardware description code is led out to the monitoring logic of the simulation test platform via the virtual monitoring interface, so as to obtain the signal value of the interconnection signal as the interaction signal during the simulation process.

[0201] In contrast to modifying the RTL function code, this embodiment of the invention utilizes the signal access capabilities provided by the Electronic Design Automation (EDA) simulation tool itself to achieve lossless bypass monitoring of the functional signals inside the hardware.

[0202] Specifically, hardware description code refers to the source code (RTL code) written in a hardware description language (such as Verilog, SystemVerilog, VHDL) that describes the circuit structure, behavior, and interconnections of the instruction execution module. Interconnect signals are signal lines explicitly defined in this code that are used to transmit data between various functional units (such as operand fetch units, execution units, etc.). They are internal connections required for the module to perform its normal functions, rather than additional connections added for debugging purposes.

[0203] The process of establishing a virtual monitoring interface is a mapping and construction from physical to logical. Based on an understanding of the hardware description code, key physical interconnect signals constituting the target data path are identified, such as a set of signals connecting the output port of the operand acquisition unit to the input port of the execution unit (e.g., op_valid, op_data[63:0], op_ready). In the simulation test platform (Testbench), a logical abstract interface is defined, for example, declaring an interface in SystemVerilog and declaring a set of variables corresponding to the names, bit widths, and directional intentions of the aforementioned physical interconnect signals. This interface definition essentially creates an interface on the test platform side that is completely consistent with the internal hardware path format.

[0204] The acquisition of interactive signals does not rely on modifying the RTL source code, but utilizes the cross-layer signal binding mechanism provided by modern EDA simulation tools. During the simulation compilation or initialization phase, specific instructions or scripts (such as the `bind` statement in SystemVerilog) bind the virtual monitoring interface instance defined in the test platform to the corresponding physical interconnect signal network (Net) in the RTL design hierarchy. For example, executing `bind top.dut.exec_unit: tb_env.monitor_if u_mon_if (.valid (internal_valid), .data (internal_data))`. This binding operation only occurs at the simulator's internal database level. It's like connecting a probe line for observation only in parallel to the physical signal lines of the RTL, with the other end of the probe connected to the virtual interface of the test platform. Therefore, during simulation runtime, any level change on the internal interconnect signals of the RTL is mirrored synchronously to the corresponding variables of the virtual interface on the test platform side in real time. The monitoring logic only needs to read these interface variables to obtain interactive signals that are completely synchronized with the internal hardware. In this embodiment of the invention, no modification to the functional RTL code is required, ensuring the purity of the Design Under Test (DUT). The verification focuses on the final design to be fabricated. Simultaneously, it can access any functional interconnect signal, is not limited by debugging hardware resources, and possesses full-bandwidth, real-time observation capabilities.

[0205] This invention constructs a pure, simulation-based signal observation infrastructure by analyzing RTL to identify physical signals -> defining logical interfaces in TB -> using simulation binding to achieve a lossless connection from physical to logical signals. This infrastructure enables transparent, high-fidelity monitoring of critical internal data paths without touching or changing the hardware design itself, and forms the foundation for supporting all the aforementioned data acquisition, identification, and comparison processes.

[0206] In one exemplary embodiment, Figure 3 This is a schematic diagram of the data flow within the instruction execution module in one embodiment. Figure 4 This is a schematic diagram of the verification result in the verification method of instruction execution in another embodiment; as shown. Figure 3 As shown, taking a vector execution unit and a scalar execution unit as examples, the arrows indicate the flow of data within the submodule as instructions are executed. Figure 3As shown, for the interface between the operand acquisition unit and the execution unit, each cycle checks for a valid signal. If a valid signal is found, operand a is acquired in the current cycle, operand b in the next cycle, and operand c in the cycle after that. The acquired three operands, along with the warp ID and program counter (PC), are output to the scoreboard. To identify the validity of each operand, the instruction can be decoded based on the PC in the execution unit (TB), or it can be provided by the hardware and Golden, depending on the implementation.

[0207] For the vector execution unit, each cycle checks for writes to registers a and b. If a write occurs, two cycles later, it checks for a write to register c. If a write occurs, the write address and write data are collected, and a C signal is recorded, indicating that the write to register c in this cycle comes from an instruction that writes to multiple destination registers. In the next cycle, it checks for a write to register d. If a write occurs, the write address and write data to register d are recorded, and a D signal is recorded. In this cycle, the recorded data, warp ID, and program counter (PC) are output to the scoreboard. After outputting, the C and D signals are set to 0. Each cycle similarly checks for writes to registers c and d. When the C / D signals are 0, data is recorded. Data output to register c is output to the scoreboard in the same cycle, while data output to register d is output one cycle later.

[0208] The processing method for scalar execution units is similar to that for vector execution units. The above processing completes the collection and sorting of all outputs for a single instruction, ensuring that the output data corresponds to the PC and is not collected repeatedly.

[0209] When comparing, the comparison is based on the warp ID and PC, such as Figure 4 As shown, assume that the five instructions within a warp are as follows: Instruction 1, a vector instruction with output registers a / b, c, and d; Instruction 2, a vector instruction with output register c; Instruction 3, a vector instruction with output register d; Instruction 4, a scalar instruction with output registers a / b and e; and Instruction 5, a scalar instruction with output register e. The execution process of the instructions in the hardware and the data acquisition and output stream in the verification environment under this method are shown in the table above.

[0210] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0211] Based on the same inventive concept, embodiments of the present invention also provide an instruction execution verification apparatus for implementing the instruction execution verification method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more instruction execution verification apparatus embodiments provided below can be found in the limitations of the instruction execution verification method described above, and will not be repeated here.

[0212] In one exemplary embodiment, such as Figure 5 As shown, a verification device 300 for instruction execution is provided, comprising:

[0213] Response module 302 is used to respond to a verification request regarding the execution status of the target instruction in the instruction execution module;

[0214] A module 304 is established in a preset simulation test platform to establish a virtual monitoring interface corresponding to at least one target data path included in the instruction execution module; the target data path is used to transmit data related to instruction execution between functional units within the instruction execution module.

[0215] The acquisition module 306 is used to acquire interactive signals transmitted in the target data path through the virtual monitoring interface;

[0216] The identification module 308 is used to identify the interaction signal and obtain the execution process record of the target instruction in the instruction execution module;

[0217] The comparison module 310 is used to compare the execution process record with the pre-stored standard execution process to obtain the verification result corresponding to the verification request.

[0218] In the device embodiments, in addition to the device-only embodiments, embodiments of the device items corresponding to all method items must also be written.

[0219] Each module in the verification device executing the above instructions can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0220] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a method for verifying instruction execution. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0221] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0222] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in the verification method embodiment for executing any of the foregoing instructions.

[0223] In one embodiment, a computer-readable storage medium is provided that stores a computer program thereon, the computer program being executed by a processor to implement the steps included in the verification method embodiment for executing any of the foregoing instructions.

[0224] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps included in the verification method embodiment for executing any of the foregoing instructions.

[0225] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0226] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0227] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0228] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for verifying instruction execution, characterized in that, The method includes: In response to a verification request regarding the execution status of the target instruction in the instruction execution module; In a pre-set simulation test platform, a virtual monitoring interface is established corresponding to at least one target data path included in the instruction execution module; the target data path is used to transmit data related to instruction execution between functional units within the instruction execution module; The interactive signals transmitted in the target data path are collected through the virtual monitoring interface. The interaction signals are identified to obtain the execution process record of the target instruction in the instruction execution module; The execution process record is compared with the pre-stored standard execution process to obtain the verification result corresponding to the verification request.

2. The method according to claim 1, characterized in that, The step of identifying the interaction signal to obtain the execution process record of the target instruction in the instruction execution module includes: Based on the instruction identifier, identify the data transmission event associated with the target instruction from the interaction signal; If the data transmission event includes multiple sub-transmission events, extract the transmission data segments corresponding to each sub-transmission event from the interaction signal; Based on the control signal characteristics in the interaction signal, it is determined whether all the sub-transmission events of the target instruction on the target data path have been completed; If all the sub-transmission events are completed, the transmission data segments corresponding to each sub-transmission event are integrated to obtain the execution process record corresponding to the target instruction.

3. The method according to claim 1, characterized in that, The instruction execution module includes an operand acquisition unit, an execution unit, and a result write-back unit; the target data path includes a first data path, a second data path, and a third data path; the first data path is used to transmit operands between the operand acquisition unit and the execution unit; the second data path is used to transmit execution results between the execution unit and the result write-back unit; the third data path is used to transmit write-back data between the result write-back unit and the storage target. The execution process record includes input operand data, intermediate result data, and write-back data; the process of identifying the interaction signals to obtain the execution process record of the target instruction in the instruction execution module includes: Identify the operand data of the target instruction input from the first data path; Identify the intermediate result data submitted by the execution unit to the result write-back unit from the second data path; The write-back data written to the storage target by the result write-back unit is identified from the third data path.

4. The method according to claim 3, characterized in that, The step of identifying the input operand data of the target instruction from the first data path includes: monitoring the virtual monitoring interface corresponding to the first data path, and identifying the first action of sending operands to the execution unit based on the validity identifier in the interaction signal; If the first behavior is detected, the instruction identifier associated with the first behavior is recorded, and a collection sequence based on a predefined fixed cycle length is initiated; the fixed cycle length is configured to be equal to or greater than the maximum number of cycles required for all types of instructions to fully transmit all their operands on the data path. In each predetermined period of the acquisition sequence, a data segment corresponding to the current period is acquired from the interaction signal; the predetermined period has a preset mapping relationship with the operand source or transmission sequence; After the acquisition sequence completes all predetermined fixed cycles, all data segments acquired in sequence are associated with the instruction identifier and merged into the input operand data set of the target instruction; wherein, the input operand data set includes all data acquired within the fixed cycle length.

5. The method according to claim 3, characterized in that, The step of identifying the intermediate result data submitted by the execution unit to the result write-back unit from the second data path includes: monitoring the virtual monitoring interface corresponding to the second data path, and identifying the second action of the execution unit submitting the execution result to the result write-back unit based on the result validity identifier in the interaction signal; If the second behavior is detected, the instruction identifier associated with the second behavior is recorded, and a collection sequence based on a predefined submission mode or a fixed period length is initiated; the submission mode or fixed period length is configured to cover a complete submission process that can generate all types of intermediate results by the instruction execution module. At each stage of the acquisition sequence, a data segment corresponding to the current stage is acquired from the interaction signal; After the acquisition sequence completes all predefined stages, all data fragment sequences acquired in sequence are associated with the instruction identifier and merged into the intermediate result data of the target instruction.

6. The method according to claim 3, characterized in that, The step of identifying the write-back data written to the storage target by the result write-back unit from the third data path includes: The virtual monitoring interface corresponding to the third data path is monitored, and the third action of the result write-back unit performing a write operation on the storage target is identified based on the write enable flag and write address flag in the interaction signal. If the third behavior is detected, the write address and write data are extracted from the interaction signal and used as the write-back data.

7. The method according to claim 3, characterized in that, The method further includes: For at least one of the input operand data, intermediate result data, and write-back data, obtain the program counter value and thread bundle identifier corresponding to the current data; Based on the thread bundle identifier, the current data is allocated to the cache queue corresponding to the thread bundle identifier; The step of comparing the execution process record with the standard execution process corresponding to the target instruction to obtain the verification result corresponding to the execution status verification request includes: The data of the standard execution process is retrieved based on the program counter value of the data retrieved from the cache queue, and compared to generate the verification result.

8. The method according to claim 1, characterized in that, The step of establishing a virtual monitoring interface in a preset simulation test platform, corresponding to the target data path included in the instruction execution module, includes: Analyze the hardware description code of the instruction execution module to identify the interconnection signals between the functional units constituting the target data path; In the simulation test platform, a monitoring signal group corresponding to the interconnection signal is defined to construct the virtual monitoring interface; wherein, the timing relationship of the monitoring signal group is configured to match the actual transmission timing of the target data path; The process of collecting interactive signals transmitted in the target data path through the virtual monitoring interface includes: The interconnection signal in the hardware description code is led out to the monitoring logic of the simulation test platform via the virtual monitoring interface, so as to obtain the signal value of the interconnection signal as the interaction signal during the simulation process.

9. A verification device for instruction execution, characterized in that, The device includes: The response module is used to respond to verification requests regarding the execution status of the target instruction in the instruction execution module; A module is established to create a virtual monitoring interface in a preset simulation test platform that corresponds to at least one target data path included in the instruction execution module; the target data path is used to transmit data related to instruction execution between functional units within the instruction execution module. The acquisition module is used to acquire interactive signals transmitted in the target data path through the virtual monitoring interface; The identification module is used to identify the interaction signals and obtain the execution process record of the target instruction in the instruction execution module; The comparison module is used to compare the execution process record with the pre-stored standard execution process to obtain the verification result corresponding to the verification request.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images