A verification method and related apparatus for a graphics processor

Abstract

The application provides a verification method and related device for a graphics processor, comprising: abstracting, by an interface abstraction layer, original interface access for a target graphics processor into a function call for a virtual firmware execution module, wherein the virtual firmware execution module is a function level modeling of a control processor subsystem in the target graphics processor; the virtual firmware execution module generates a standard transaction sequence according to the function call, so that the virtual firmware execution module and / or the target image processor executes the standard transaction sequence; a consistency monitoring module obtains actual data corresponding to a plurality of checkpoints respectively, wherein the plurality of checkpoints correspond to a whole flow of the interface abstraction layer, the virtual firmware execution module and the target image processor; the consistency monitoring module compares the actual data corresponding to the plurality of checkpoints respectively with expected data corresponding to the plurality of checkpoints respectively one by one, and generates a verification report for the target graphics processor. In the verification process, no firmware instruction is relied on.

Description

Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a verification method and related apparatus for graphics processors. Background Technology

[0002] In the design and verification process of complex System-on-Chip (SoC) devices such as Graphics Processing Units (GPUs), there is a heavy reliance on the firmware programs running on the control processor. In existing technologies, scenarios involving hardware-software co-simulation or early verification typically include the following steps: the host-side driver configures the GPU and submits the task; the firmware image is loaded into an instruction set emulator, which executes the firmware code instruction by instruction; the firmware accesses virtual registers or memory models through the emulator, and these accesses are translated into precise timing stimuli for the hardware model via a bus model; interrupts or status updates generated after the hardware model executes commands are notified to the emulator via the bus, triggering interrupt handling routines in the firmware; finally, verification is completed by comparing the firmware execution path with the hardware output results.

[0003] However, the existing verification methods described above have the following technical problems in practical applications:

[0004] First, the verification cycle is severely delayed. There is a strong bidirectional dependency between the hardware model and the firmware. The correct operation of the hardware model depends on the firmware for driving it, while the development of the firmware requires a stable hardware interface definition (usually derived from register-transfer level design). In the early stages of GPU architecture design, hardware interface definitions frequently change, and the register-transfer level code is not yet stable, making it impossible to provide a stable target for firmware development. Conversely, without a runnable firmware program, the hardware model cannot initiate system-level verification. This "chicken or egg" dilemma means that system-level verification can only begin after both the firmware and the hardware model are essentially complete, severely lagging behind the needs of the architecture exploration phase.

[0005] Second, simulation and debugging are inefficient. Instruction set simulators require extensive low-level calculations, such as instruction decoding, pipeline simulation, and memory access simulation, and involve tedious timing synchronization with precisely timed hardware models. This results in simulation speeds typically being one to two orders of magnitude slower than pure transaction-level models. When firmware logic is complex, a single simulation can take an excessively long time. More importantly, if verification fails, the debugger needs to cross-reference the firmware source code, instruction execution flow, and hardware waveforms simultaneously, making problem localization extremely difficult and debugging inefficient.

[0006] Third, insufficient early verification coverage. During the architecture exploration phase, verification focuses on the correctness of system-level functions, the effectiveness of scheduling strategies, and the consistency of data flow, rather than the implementation details of firmware instructions or the precise cyclic behavior of the hardware model. Using instruction-level methods prematurely introduces irrelevant detail complexity, causing a large amount of verification resources and time to be consumed in verifying the correctness of the firmware code itself, rather than verifying the rationality of the architecture design, thus slowing down the progress of verification coverage of core architectural features.

[0007] Therefore, how to provide a fast, verifiable, and high-fidelity verification method that can be implemented in the early stages of GPU architecture design without relying on instruction-level firmware execution has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0008] This application provides at least one verification method and related apparatus for graphics processors. By abstracting the original interface access into function calls for the virtual firmware execution module through an interface abstraction layer, a standard transaction sequence is generated through the function calls, thereby eliminating the need for firmware instructions. This fundamentally decouples the strong binding relationship between GPU verification and firmware instructions. Furthermore, a consistency monitoring module performs comprehensive verification of multiple checkpoints throughout the entire process to generate a verification report. This enables the verification cycle to be moved forward, significantly improving simulation and debugging efficiency, accurately matching verification targets to the design stage, providing a verifiable verification benchmark, and enabling cross-stage reuse capabilities.

[0009] In a first aspect, this application provides a verification method for a graphics processor, comprising: Through the interface abstraction layer, the raw interface access to the target graphics processor is abstracted into function calls to the virtual firmware execution module, where the virtual firmware execution module is a functional-level model of the control processor subsystem in the target graphics processor. The virtual firmware execution module generates a standard transaction sequence based on the function call, so that the virtual firmware execution module and / or the target image processor can execute the standard transaction sequence; The consistency monitoring module acquires the actual data corresponding to multiple checkpoints, which correspond to the entire process of the interface abstraction layer, the virtual firmware execution module, and the target image processor. The consistency monitoring module compares the actual data corresponding to multiple checkpoints with the expected data corresponding to multiple checkpoints one by one, and generates a verification report for the target graphics processor.

[0010] Secondly, this application also provides a verification device for a graphics processor, comprising: The interface abstraction layer is used to abstract raw interface accesses to the target graphics processor into function calls to the virtual firmware execution module, where the virtual firmware execution module is a functional-level model of the control processor subsystem in the target graphics processor. The virtual firmware execution module is used to generate a standard transaction sequence based on function calls, so that the virtual firmware execution module and / or the target image processor can execute the standard transaction sequence. The consistency monitoring module is used to acquire the actual data corresponding to multiple checkpoints, which correspond to the entire process of the interface abstraction layer, the virtual firmware execution module, and the target image processor. The consistency monitoring module is also used to compare the actual data corresponding to multiple checkpoints with the expected data corresponding to multiple checkpoints one by one, and generate a verification report for the target graphics processor.

[0011] Thirdly, this application also provides an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the verification method for graphics processors provided in this application is executed.

[0012] Fourthly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the verification method for a graphics processor provided in this application.

[0013] Fifthly, this application also provides a computer program product, including a computer program that is executed by a processor to perform the verification method for a graphics processor provided in this application.

[0014] In summary, this application provides a verification method and related apparatus for a graphics processing unit (GPU). The method includes: abstracting the original interface access to the target GPU into function calls for a virtual firmware execution module (VMEP) through an interface abstraction layer, wherein the VMEP is a functional-level model of the control processor subsystem in the target GPU; generating a standard transaction sequence based on the function calls, so that the VMEP and / or the target GPU execute the standard transaction sequence; acquiring actual data corresponding to multiple checkpoints, wherein the multiple checkpoints correspond to the entire process of the interface abstraction layer, the VMEP, and the target GPU; and comparing the actual data corresponding to the multiple checkpoints with the expected data corresponding to the multiple checkpoints one by one to generate a verification report for the target GPU.

[0015] Based on the above method, the original interface access is abstracted into function calls to the virtual firmware execution module through the interface abstraction layer, and a standard transaction sequence is generated through the function calls. This eliminates the need for firmware instructions, fundamentally decoupling the strong binding relationship between GPU verification and firmware instructions. Furthermore, a consistency monitoring module performs comprehensive verification at multiple checkpoints throughout the entire process to generate a verification report, thereby achieving the following effects: First, the verification cycle is brought forward. By replacing the instruction-level firmware with a virtual firmware execution module based on functional-level modeling, system-level verification can be initiated early in the architecture design process without waiting for firmware development, thus solving the problem of cycle lag between firmware programs and hardware models.

[0016] Secondly, simulation and debugging efficiency is significantly improved. By abstracting the timing-precise interface accesses at low abstraction levels into function calls at high abstraction levels through the interface abstraction layer, the underlying timing synchronization overhead is eliminated, and the simulation speed is increased by orders of magnitude. During debugging, relevant personnel only need to focus on the comparison results between the actual data and the expected data at the checkpoints, which greatly improves debugging efficiency.

[0017] Third, the verification target is precisely matched with the design phase. The verification target is clarified from the firmware instructions in the relevant technologies to whether the behavior of data flow through key processing nodes conforms to the architecture specifications. This allows verification resources to be focused on the GPU architecture design itself, avoiding insufficient verification coverage caused by introducing firmware instruction details too early.

[0018] Fourth, it provides verifiable verification benchmarks and cross-stage reuse capabilities. It outputs standardized verification reports, forming a reproducible verification loop. The checkpoint-related content included in the verification report can be reused for functional testing of subsequent instruction-level firmware development and verification of hardware code, ensuring semantic consistency of behavior throughout the entire process.

[0019] Other advantages of this application will be explained in more detail in conjunction with the following description and figures.

[0020] It should be understood that the above description is merely an overview of the technical solution of this application, so as to enable a general understanding of the technical means of this application and to implement it in accordance with the contents of the specification. In order to make the above and other objects, features and advantages of this application more apparent and understandable, specific embodiments of this application are illustrated below. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. The accompanying drawings are incorporated in and constitute a part of this specification. These drawings illustrate embodiments conforming to this application and are used together with the specification to explain the technical solutions of this application. It should be understood that the drawings only illustrate certain embodiments of this application and should not be considered as a limitation on the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. Furthermore, the same reference numerals denote the same components throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a verification method for a graphics processor provided in this application embodiment; Figure 2 A specific flowchart involving an interface abstraction layer is provided for an embodiment of this application; Figure 3 A detailed flowchart of a checkpoint CP1 provided in an embodiment of this application; Figure 4 A detailed flowchart of a checkpoint CP2 provided in this application embodiment; Figure 5 A detailed flowchart of a checkpoint CP3 provided in this application embodiment; Figure 6 A detailed flowchart of a checkpoint CP4 provided in this application embodiment; Figure 7 A specific flowchart for a consistency monitoring module is provided in this application embodiment; Figure 8 A detailed flowchart of a verification method for a graphics processor provided in this application embodiment; Figure 9 This is a schematic diagram of a verification device for a graphics processor provided in an embodiment of this application. Detailed Implementation

[0022] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0023] In the description of embodiments of this application, it should be understood that terms such as “comprising” or “having” are intended to indicate the presence of the disclosed features, figures, steps, behaviors, components, portions or combinations thereof in this specification, and do not exclude the possibility of the presence of one or more other features, figures, steps, behaviors, components, portions or combinations thereof.

[0024] Unless otherwise stated, " / " means "or". For example, A / B can mean A or B. In this article, "and / or" is merely a way of describing the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A alone, A and B at the same time, and B alone.

[0025] The terms "first," "second," etc., are used only for ease of description to distinguish identical or similar technical features and should not be construed as indicating or implying the relative importance or number of these technical features. Therefore, a feature defined by "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of embodiments of this application, unless otherwise stated, the term "multiple" means two or more.

[0026] In the design and verification process of complex on-chip systems such as graphics processing units (GPUs), there is a heavy reliance on the firmware programs running on the control processor. In existing technologies, scenarios involving hardware-software co-simulation or early verification typically include the following steps: the host-side driver configures the GPU and submits the task; the firmware image is loaded into an instruction set emulator, which executes the firmware code instruction by instruction; the firmware accesses virtual registers or memory models through the emulator, and these accesses are translated into precise timing stimuli for the hardware model via a bus model; interrupts or status updates generated after the hardware model executes commands are notified to the emulator via the bus, triggering interrupt handling routines in the firmware; finally, verification is completed by comparing the firmware execution path with the hardware output results.

[0027] However, the existing verification methods described above have the following technical problems in practical applications: First, the verification cycle is severely delayed. There is a strong bidirectional dependency between the hardware model and the firmware. The correct operation of the hardware model depends on the firmware for driving it, while the development of the firmware requires a stable hardware interface definition (usually derived from register-transfer level design). In the early stages of GPU architecture design, hardware interface definitions frequently change, and the register-transfer level code is not yet stable, making it impossible to provide a stable target for firmware development. Conversely, without a runnable firmware program, the hardware model cannot initiate system-level verification. This "chicken or egg" dilemma means that system-level verification can only begin after both the firmware and the hardware model are essentially complete, severely lagging behind the needs of the architecture exploration phase.

[0028] Second, simulation and debugging are inefficient. Instruction set simulators require extensive low-level calculations, such as instruction decoding, pipeline simulation, and memory access simulation, and involve tedious timing synchronization with precisely timed hardware models. This results in simulation speeds typically being one to two orders of magnitude slower than pure transaction-level models. When firmware logic is complex, a single simulation can take an excessively long time. More importantly, if verification fails, the debugger needs to cross-reference the firmware source code, instruction execution flow, and hardware waveforms simultaneously, making problem localization extremely difficult and debugging inefficient.

[0029] Third, insufficient early verification coverage. During the architecture exploration phase, verification focuses on the correctness of system-level functions, the effectiveness of scheduling strategies, and the consistency of data flow, rather than the implementation details of firmware instructions or the precise cyclic behavior of the hardware model. Using instruction-level methods prematurely introduces irrelevant detail complexity, causing a large amount of verification resources and time to be consumed in verifying the correctness of the firmware code itself, rather than verifying the rationality of the architecture design, thus slowing down the progress of verification coverage of core architectural features.

[0030] In view of this, this application provides a verification method and related apparatus for graphics processors. By abstracting the original interface access into function calls for the virtual firmware execution module through an interface abstraction layer, a standard transaction sequence is generated through the function calls, thereby eliminating the need for firmware instructions. This fundamentally decouples the strong binding relationship between GPU verification and firmware instructions. Furthermore, a consistency monitoring module performs comprehensive verification of multiple checkpoints throughout the entire process to generate a verification report. This enables the verification cycle to be moved forward, significantly improving simulation and debugging efficiency, accurately matching verification targets to the design stage, providing a verifiable verification benchmark, and enabling cross-stage reuse capabilities.

[0031] The verification method for graphics processors provided in this application can be implemented using a computer device, which can be a terminal device or a server. The server 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. Terminal devices include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The terminal device and the server can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this connection.

[0032] The following describes a verification method for a graphics processor provided in this application through method embodiments, such as... Figure 1 As shown, Figure 1 This application provides a flowchart of a verification method for a graphics processor, wherein the aforementioned computer device can be a server, and the method includes: S101. Through the interface abstraction layer, the original interface access to the target graphics processor is abstracted into function calls to the virtual firmware execution module. The virtual firmware execution module is a functional-level model of the control processor subsystem in the target graphics processor.

[0033] Specifically, the target graphics processor refers to the graphics processor to be verified.

[0034] Raw interface access refers to the configuration access of the registers of the target graphics processor's control processor subsystem via the PCIe bus on the host side in actual hardware. These operations usually involve low-level details such as bus protocols and timing synchronization.

[0035] The Virtual Firmware Execution Module (VFEM) is a pre-built software module that provides a functional-level model of the control processor subsystem in the target graphics processor (in actual chip design, the control processor subsystem may include multiple RISC-V cores). The VFEM does not execute any instructions or load the firmware image; it only simulates the control semantics of the firmware through its internal state machine and data structures.

[0036] The Interface Abstraction Layer (IAL) is a functional-level abstraction that preserves semantics. It is used to abstract the host-side raw interface access to the GPU hardware into function calls to objects inside the virtual firmware execution module, so that the virtual firmware execution module can use it later.

[0037] like Figure 8 As shown, through the interface abstraction layer, raw interface access to the target graphics processor can be abstracted into function calls to the virtual firmware execution module.

[0038] In one possible implementation, the virtual firmware execution module includes a virtual register file, which is a functional-level model of the registers that control the processor subsystem.

[0039] Specifically, the virtual firmware execution module contains a virtual register file (VRF), which is a functional model of the registers in the control processor subsystem. The virtual firmware execution module can directly read and write to the virtual register file and call the corresponding processing logic according to the register attributes (such as writing to a certain register will trigger a specific action). In this way, the simulation of the actual instruction-level register access path is avoided.

[0040] In one possible implementation, S101 uses an interface abstraction layer to abstract raw interface accesses to the target graphics processor into function calls to the virtual firmware execution module, including: Through the interface abstraction layer, raw interface access to the registers of the control processor subsystem for the target graphics processor is abstracted into function calls to the virtual register file in the virtual firmware execution module.

[0041] Specifically, through the interface abstraction layer, the original raw interface access to registers in the control processor subsystem can be abstracted into function calls to the virtual register file inside the virtual firmware execution module. Writing to registers calls `vrf_write`, and reading registers calls `vrf_read`. The relevant process for writing to registers using `vrf_write` is as follows: Figure 2 As shown, this abstracts register access in a functional-level manner.

[0042] In other words, for registers that originally needed to be accessed by firmware instructions, the virtual firmware execution module can directly perceive and modify their state without introducing additional hardware interface paths or simulating instruction execution.

[0043] In one possible implementation, the virtual firmware execution module includes a virtual queue descriptor, which includes a virtual hardware queue descriptor and a virtual software command queue descriptor. The virtual hardware queue descriptor is a functional-level model of the hardware queue description, and the virtual software command queue descriptor is a functional-level model of the software command queue description.

[0044] Specifically, the virtual firmware execution module includes a virtual queue descriptor, which is further divided into: The Virtual Memory Command Queue Descriptor (vMCQD) is a functional-level model of the Memory Command Queue Descriptor (MCQD) used to represent the status of the queue of commands to be executed issued by the host side.

[0045] The Virtual Hardware Queue Descriptor (vHCQD) is a functional-level model of the Hardware Queue Descriptor (HCQD), used to represent the state and binding information of queues on the hardware engine side.

[0046] Both the virtual hardware queue descriptor and the virtual software command queue descriptor exist as software data objects in the virtual firmware execution module. The scheduling and control logic is accomplished by directly accessing the attributes (such as pointers and status flags) of the virtual hardware queue descriptor and the virtual software command queue descriptor, without needing to simulate the timing details of underlying memory reads or register configurations.

[0047] In one possible implementation, S101 uses an interface abstraction layer to abstract raw interface accesses to the target graphics processor into function calls to the virtual firmware execution module, including: Through the interface abstraction layer, the original interface access to the target software command queue description is abstracted into function calls that configure the target virtual software command queue descriptor corresponding to the target software command queue in the virtual firmware execution module.

[0048] Specifically, in real-world hardware scenarios, such as Figure 2 As shown, in order to submit commands to the target graphics processor, the host-side driver needs to first construct a software command queue description (MCQD) and notify it via email. In this embodiment, the hardware process of "the host configuring the target software command queue description memory and then notifying via email" is abstracted into the host side directly submitting a "create stream" request containing the target software command queue description information to the virtual firmware execution module through the interface abstraction layer, so that the virtual firmware execution module can convert it into an internal target virtual software command queue descriptor (vMCQD) corresponding to the target software command queue.

[0049] S102. The virtual firmware execution module generates a standard transaction sequence based on the function call, so that the virtual firmware execution module and / or the target image processor can execute the standard transaction sequence.

[0050] Specifically, a standard transaction sequence refers to a series of standardized transaction packages generated by the virtual firmware execution module based on function calls, which are used to drive the subsequent verification process.

[0051] After the interface abstraction layer translates raw hardware access into function calls, such as Figure 8 As shown, the virtual firmware execution module generates a standard transaction sequence. Throughout the process, the virtual firmware execution module does not execute any firmware instructions, thus bypassing the overhead and complexity brought by the instruction set emulator. The generated standard transaction sequence can be executed by the virtual firmware execution module itself (such as self-processing transactions) or sent to the target image processor for execution, realizing a complete functional level abstraction of verification-driven processing.

[0052] In one possible implementation, the standard transaction sequence includes command dispatch transactions and / or self-processing transactions, where command dispatch transactions are those that need to be sent to the target graphics processor, and self-processing transactions are those that are processed autonomously by the virtual firmware execution module.

[0053] Specifically, when the original interface access belongs to the "hardware execution class" (such as calculation and rendering commands that need to be executed by the target graphics processor hardware engine), the virtual firmware execution module encapsulates it into a command distribution transaction and sends it to the target graphics processor, which then executes it. This type of transaction carries the specific workload that requires hardware participation.

[0054] When the command package belongs to the "firmware self-processing class" (such as status query, resource management, and other control operations that do not require hardware intervention), the virtual firmware execution module does not send it to the target graphics processor, but instead processes it autonomously within the virtual firmware execution module. The virtual firmware execution module simulates the behavior that firmware should have by updating the virtual register file, modifying the internal queue state, and triggering callback functions, and generates self-processing transactions for logging and consistency monitoring. These transactions demonstrate the functional substitution of firmware control logic by the virtual firmware execution module.

[0055] In one possible implementation, the virtual firmware execution module in S102 generates a standard transaction sequence based on the function call, including: The virtual firmware execution module creates virtual context information and target virtual software command queue descriptors based on function calls; The virtual firmware execution module checks the status of the target virtual software command queue descriptor; If the target virtual software command queue descriptor is schedulable, the virtual firmware execution module binds the target virtual software command queue descriptor to an idle virtual hardware queue descriptor to generate a standard transaction sequence.

[0056] Specifically, the virtual firmware execution module creates virtual context information (Stream) and target virtual software command queue descriptor based on function calls.

[0057] The virtual firmware execution module checks the status of the target virtual software command queue descriptor. For example, it can check the read and write pointer status of the target virtual software command queue descriptor to determine whether it is schedulable. When a pointer inconsistency is detected, the target virtual software command queue descriptor is determined to be in a schedulable state. The virtual firmware execution module binds the schedulable target virtual software command queue descriptor to an idle virtual hardware queue descriptor to generate a standard transaction sequence.

[0058] In one possible implementation, the method further includes: If all virtual hardware queue descriptors are busy, the virtual firmware execution module will configure the schedulable target virtual software command queue descriptor to a waiting state.

[0059] Specifically, if all virtual hardware queue descriptors are in a busy state, the virtual firmware execution module will configure the state of the schedulable target virtual software command queue descriptor to a waiting state (PENDING) instead of binding it immediately, thereby simulating the behavior of waiting due to insufficient resources in real hardware.

[0060] In one possible implementation, the method further includes: The virtual firmware execution module performs barrier writing through the barrier synchronization processing function, generating barrier signal transactions.

[0061] Specifically, the virtual firmware execution module performs barrier writing through the barrier synchronization processing function, generating a barrier signal transaction (FENCE_SIGNAL) to simulate the behavior of barrier (Fence) operations in real hardware.

[0062] In one possible implementation, after generating the barrier signal transaction, the method further includes: In response to the destruction request, the virtual firmware execution module executes the destruction procedure to release the associated virtual resources and reset the state.

[0063] Specifically, after generating the barrier signal transaction, when the virtual firmware execution module receives a destruction request from the host side, the virtual firmware execution module can execute the destruction procedure. The destruction procedure first confirms that all tasks (including barrier synchronization operations) have been completed, then releases the associated virtual resources, which may include virtual software command queue descriptors and virtual hardware command queue descriptors, and resets the relevant internal states.

[0064] In one possible implementation, after generating the barrier signal transaction, the method further includes: The virtual firmware execution module triggers a job completion interrupt by completing the reporting function, and generates a job completion reporting transaction.

[0065] Specifically, after generating the barrier signal transaction, the virtual firmware execution module triggers a simulated job completion interrupt by completing the reporting function, and generates a job completion reporting transaction (JOB_DONE_REPORT) accordingly.

[0066] In one possible implementation, the virtual firmware execution module includes a scheduling control unit, which performs functional-level modeling of the target graphics processor model's mailbox-based communication function, hardware queue description scheduling function, idle state management function, and exception management function.

[0067] Specifically, in addition to performing functional-level simulations of key objects such as registers, hardware queue descriptions, and software command queue descriptions of the control processor subsystem, the virtual firmware execution module may also include a scheduling control unit, which simulates the scheduling and control logic of the target graphics processor model.

[0068] The mailbox-based communication function simulates the mailbox mechanism in hardware, used for transmitting control information (such as creating streams, submitting commands, and querying status) between the host driver and firmware. In this embodiment, messages are received and corresponding processing is triggered via function calls.

[0069] The virtual hardware queue description scheduling function performs functional-level modeling of the command ring buffer state in the virtual software command queue descriptor. When a pointer inconsistency is detected, it determines that the virtual software command queue descriptor is schedulable and binds the virtual software command queue descriptor to an idle virtual hardware queue descriptor based on a preset strategy.

[0070] The idle state management function simulates the firmware's management and state switching behavior of the idle state during the operation of the target graphics processor model. For example, it enters a low-power or waiting state when there are no schedulable tasks, and wakes up when a task arrives.

[0071] The exception management function is a simulated firmware process for detecting and pre-setting the handling of hardware errors and abnormal events during the operation of the target graphics processor model.

[0072] Through the above functional-level modeling, the scheduling control unit completely replaces the complex control logic in the instruction-level firmware in a pure software manner.

[0073] In one possible implementation, the virtual firmware execution module includes a command distribution processing unit, which performs functional-level modeling of command distribution functions for command distribution transactions, command self-processing functions for self-processing transactions, command stop and start functions, barrier synchronization processing functions, and completion reporting functions.

[0074] Specifically, the virtual firmware execution module includes a command distribution processing unit, which simulates the firmware's logic for distributing and processing commands to the target graphics processor model.

[0075] The command dispatch function for command dispatch transactions simulates the dispatch of the parsed command dispatch transaction to the corresponding target graphics processor model.

[0076] The command self-processing function for self-processing transactions identifies and processes specific command packets that should be processed by the control processor subsystem in the target graphics processor, simulating their effects by updating internal states or triggering callbacks.

[0077] The command stop and start function simulates the control behavior of firmware in response to stop commands, pausing or resuming task flow.

[0078] The barrier synchronization processing function manages barrier operations related to task synchronization, including writing barrier values ​​and updating their status.

[0079] The completion reporting function organizes completion status information and triggers the reporting process after the task flow is completed.

[0080] Through the above functional-level modeling, the command distribution and processing unit completely replaces the command processing flow in the instruction-level firmware in a pure software manner.

[0081] S103, the consistency monitoring module obtains the actual data corresponding to multiple checkpoints, where the multiple checkpoints correspond to the entire process of the interface abstraction layer, the virtual firmware execution module, and the target image processor.

[0082] Specifically, checkpoints are pre-determined verification points in the entire process from receiving the original interface access from the host side through the interface abstraction layer, processing by the virtual firmware execution module, to execution and feedback by the target graphics processor model.

[0083] To systematically verify the target graphics processor, the consistency monitoring module acquires corresponding actual data at multiple predefined checkpoints. This actual data can include system state snapshots and actual transaction data, such as... Figure 8 As shown, the consistency monitoring module monitors the entire process through multiple checkpoints.

[0084] In one possible implementation, the multiple checkpoints include a first checkpoint for the task creation phase, which at least verifies whether the values ​​of the virtual registers in the virtual register file are consistent with the values ​​of the registers controlling the processor subsystem.

[0085] Specifically, among the multiple checkpoints is a first checkpoint for the task creation phase. The first checkpoint is used to verify at least whether the virtual firmware execution module correctly captures and parses the key control register values ​​written by the host side through PCIe configuration, and whether the values ​​of the virtual registers in the virtual register file are consistent with the expected values ​​of the registers controlling the processor subsystem as defined in the hardware specification. This ensures that the virtual firmware execution module captures and parses the host driver configuration correctly.

[0086] like Figure 3 As shown, "Checkpoint CP1" can be the first checkpoint, used to verify whether the register value conforms to the specification.

[0087] The first checkpoint can be placed before the creation stream transaction (TXN_CREATE_STREAM) is generated.

[0088] In one possible implementation, the multiple checkpoints include a second checkpoint for the context establishment phase, which at least verifies whether the virtual firmware execution module has successfully created virtual context information and whether the target virtual software command queue descriptor has been successfully created.

[0089] Specifically, among the multiple checkpoints is a second checkpoint for the context establishment phase. The second checkpoint is used to verify at least whether the virtual firmware execution module has successfully created the virtual context information based on the information passed by the host driver, and whether it has successfully created the corresponding target virtual software command queue descriptor (vMCQD). At the same time, it checks whether the initial state of the target virtual software command queue descriptor is completely matched with the preset value of the host driver.

[0090] like Figure 3 As shown, "Checkpoint CP1" can be a second checkpoint used to verify whether the initial state of the target virtual software command queue descriptor (vMCQD) is correct.

[0091] The second checkpoint can be implanted after the creation of the stream transaction (TXN_CREATE_STREAM) is generated and before the payload is solidified.

[0092] In one possible implementation, the multiple checkpoints include a third checkpoint for scheduling conditions during the scheduling and queue binding phase. The third checkpoint is used to verify at least that the target virtual software command queue descriptor is in a schedulable state and that there is at least one virtual hardware queue descriptor in an idle state.

[0093] Specifically, among the multiple checkpoints is a third checkpoint addressing the scheduling conditions during the scheduling and queue binding phase. This third checkpoint verifies at least whether the target virtual software command queue descriptor (vMCQD) is in a schedulable state, whether the target virtual software command queue descriptor (vMCQD) is in a READY state (read / write pointer inconsistency), and whether there is at least one idle virtual hardware queue descriptor (vHCQD). Only when both of these conditions are met simultaneously does the scheduling binding satisfy the scheduling conditions. Figure 4 As shown, the verification is performed on whether the target virtual software command queue descriptor (vMCQD) is in a schedulable state and whether there is at least one virtual hardware queue descriptor (vHCQD) in an idle state.

[0094] The third checkpoint can be implanted when the scheduling state machine (MS-FSM) responds to the doorbell event and attempts to initiate a binding.

[0095] In one possible implementation, the multiple checkpoints include a fourth checkpoint for resource management during the scheduling and queue binding phase, which is used to verify that the number of virtual hardware queue descriptors in a busy state does not exceed the number of hardware queue descriptors supported by the target graphics processor.

[0096] Specifically, the multiple checkpoints include a fourth checkpoint for resource management during the scheduling and queue binding phases. This fourth checkpoint verifies at least two things: The number of virtual hardware queue descriptors (vHCQDs) currently in a busy state must not exceed the total number of hardware queue descriptors (HCQDs) supported by the target graphics processor. This ensures that the scheduling behavior of the virtual firmware execution module does not exceed the resource limits of the physical hardware. When all virtual hardware queue descriptors are busy, verify that the virtual firmware execution module correctly configures the schedulable target virtual software command queue descriptor (vMCQD) to a pending state, thereby simulating the correct waiting behavior instead of immediately binding.

[0097] like Figure 4 As shown, "Checkpoint CP2" can be used as the fourth checkpoint to verify that the number of virtual hardware queue descriptors (vHCQDs) currently in a busy state (BUSY) does not exceed the total number of hardware queue descriptors (HCQDs) supported by the target graphics processor.

[0098] The fourth checkpoint can be implanted before the binding (TXN_BIND) transaction is generated.

[0099] In one possible implementation, the multiple checkpoints include a fifth checkpoint configured for the content of the scheduling and queue binding phase. The fifth checkpoint is used to verify at least whether the binding snapshot field of the target virtual software command queue descriptor records the information to be recorded in the command ring buffer of the corresponding virtual hardware queue descriptor at the time of binding.

[0100] Specifically, multiple checkpoints include a fifth checkpoint for the content configuration of the scheduling and queue binding phase. The fifth checkpoint is used to verify at least the binding snapshot field of the target virtual software command queue descriptor (vMCQD), such as the bound_snapshot field in vHCQD, whether it accurately records the information to be recorded in the command ring buffer of the corresponding virtual hardware queue descriptor (vHCQD) at the time of binding. The information to be recorded may include ring buffer base address (ring_base), write pointer (wptr), etc., which ensures that the data source for command distribution after binding is correct.

[0101] like Figure 4As shown, "Checkpoint CP2" can be used as the fifth checkpoint to verify whether the state transition of the target virtual software command queue descriptor (vMCQD) is legal.

[0102] The fifth checkpoint can be placed after the bind (TXN_BIND) transaction is committed and before the first command dispatch (TXN_DISPATCH) transaction is issued.

[0103] In one possible implementation, the multiple checkpoints include a sixth checkpoint for classification identification of the command distribution and processing phases. The sixth checkpoint is used at least to verify whether the standard transaction sequence is accurately classified as a command distribution transaction and a self-processing transaction.

[0104] Specifically, the multiple checkpoints include a sixth checkpoint for classification and identification of the command distribution and processing phases. The sixth checkpoint is used to verify at least whether transactions in the standard transaction sequence are accurately classified as command distribution transactions (DISPATCH) and self-processing transactions (SELF_OP), that is, whether the classification result of each command packet is consistent with the hardware specification definition.

[0105] like Figure 5 As shown, this is used to verify whether each command package is successfully classified into a command dispatch transaction (DISPATCH) and a self-processing transaction (SELF_OP).

[0106] The sixth checkpoint can be implanted after the Command Parsing and Distribution Engine (CPDE) parses each command packet.

[0107] In one possible implementation, the multiple checkpoints include a seventh checkpoint for self-processing compliance during the command distribution and processing phase. This seventh checkpoint is used to verify that the virtual firmware execution module's execution of self-processing transactions conforms to the firmware processing rules of the control processor subsystem.

[0108] Specifically, multiple checkpoints include a seventh checkpoint for self-processing compliance during the command distribution and processing phase. The seventh checkpoint is used to verify at least whether all side effects generated by the Virtual Firmware Execution Module (VFEM) when performing self-processing transactions (such as writing to the virtual register file, updating internal state, generating transactions or callbacks) fully comply with the firmware processing rules of the control processor subsystem, i.e., whether they are consistent with the behavior defined by the hardware specifications.

[0109] like Figure 5 As shown, "Checkpoint CP3" can be used as the seventh checkpoint to verify whether the self-processing transaction (SELF_OP) is compliant.

[0110] The seventh checkpoint can be placed after all self-processing transactions have been completed.

[0111] In one possible implementation, the multiple checkpoints include an eighth checkpoint for the synchronization phase, which at least verifies whether the barrier signal transaction was generated after all associated command distribution transactions have been executed by the target graphics processor and whether the barrier write conforms to the barrier write criterion.

[0112] Specifically, the multiple checkpoints include an eighth checkpoint for the synchronization phase, which verifies at least two things: Whether the barrier signal transaction (FENCE_SIGNAL) is generated only after all associated command dispatch transactions (DISPATCH) have been executed and feedback has been completed by the target graphics processor, thus ensuring correct timing; Whether the barrier write operation conforms to the barrier write standard defined by the hardware architecture (such as whether the memory address and write value are consistent with the Fence definition in the task context) is used to ensure data correctness.

[0113] Verification for the synchronization phase, such as Figure 6 As shown.

[0114] The eighth checkpoint can be implanted when the barrier signal (TXN_FENCE_SIGNAL) transaction is generated.

[0115] In one possible implementation, the multiple checkpoints include a ninth checkpoint for the cleanup phase, which at least verifies whether the virtual firmware execution module receives the destruction request after the barrier signal transaction is generated and whether the destruction procedure meets the destruction criteria.

[0116] Specifically, the multiple checkpoints include a ninth checkpoint for the cleanup phase, which verifies at least two things: Does the Virtual Firmware Execution Module (VFEM) receive the destruction request only after the barrier signal transaction (FENCE_SIGNAL) is generated, in order to ensure timing correctness? Whether the execution of the destruction procedure conforms to the destruction standards defined by the hardware architecture, including whether all associated virtual resources (such as vMCQD, bound vHCQD, etc.) are completely released and the state is correctly reset.

[0117] The ninth checkpoint can be implanted when the virtual firmware execution module responds to a destruction request issued by the host.

[0118] In one possible implementation, the multiple checkpoints include a tenth checkpoint for the interruption reporting phase. The tenth checkpoint is used at least to verify whether the job completion reporting transaction is generated after the barrier signal transaction and whether the information corresponding to the job completion reporting transaction is consistent with the context information of the completed function call.

[0119] Specifically, the multiple checkpoints include a tenth checkpoint for the interruption reporting phase, which verifies at least two things: Whether the job completion reporting transaction is generated after the barrier signal transaction is generated, thus ensuring the correctness of the timing; The information carried in the job completion reporting transaction (such as Stream ID, status code, etc.) is completely consistent with the context information corresponding to the completed function call, thereby ensuring information consistency.

[0120] Verification for the interruption reporting phase, such as Figure 6 As shown.

[0121] In summary, through the verification of the above multiple checkpoints, a comprehensive judgment can be made on the target graphics processor, which meets the following criteria: State and Transition Legality Criteria: The transitions of all state machines (such as MS-FSM and the states of each virtual hardware queue descriptor) in the virtual firmware execution module must belong to a predefined set of legal transitions. For example, the prerequisite for a virtual hardware queue descriptor to transition from a busy state to an idle state is that the corresponding engine completion event has been received.

[0122] Data integrity criteria: Data integrity and consistency must be maintained during transaction transmission. For example, the snapshot data of the virtual hardware queue descriptor in the fifth checkpoint must be consistent with the target virtual software queue descriptor data obtained in the second checkpoint, and the value written to the barrier in the eighth checkpoint must match the value defined during task initialization.

[0123] Timing and Sequence Criteria: Transactions must adhere to strict causal and sequential relationships. Core criteria include: under the same task identifier (stream_id), the command dispatch transaction (TXN_DISPATCH) must precede the barrier signal transaction (TXN_FENCE_SIGNAL); the barrier signal transaction (TXN_FENCE_SIGNAL) must precede the job completion report transaction (TXN_JOB_DONE_REPORT). Violation of the order will result in failure.

[0124] Resource constraint criteria: The virtual firmware execution module's use of virtual resources (such as virtual hardware queue descriptions) must not exceed the limits of the physical hardware, and management strategies (such as binding and releasing) must simulate real hardware behavior.

[0125] S104. The consistency monitoring module compares the actual data corresponding to multiple checkpoints with the expected data corresponding to multiple checkpoints one by one, and generates a verification report for the target graphics processor.

[0126] Specifically, the expected data is based on the predetermined expected values ​​of the target graphics processor, which can be directly derived from the architecture specification of the target graphics processor.

[0127] like Figure 8 As shown, the consistency monitoring module compares the expected data preset for each checkpoint with the actual data captured in step S103 point by point. After all checkpoints are compared, a structured verification report is generated.

[0128] In one possible implementation, the consistency monitoring module in S104 compares the actual data corresponding to multiple checkpoints with the expected data corresponding to the multiple checkpoints one by one, generating a verification report for the target graphics processor, including: If the actual data and the expected data for each of the multiple checkpoints are consistent, the consistency monitoring module determines that the target graphics processor has been successfully verified. The verification report includes the actual data and the expected data for each of the multiple checkpoints.

[0129] Specifically, in this embodiment, a comprehensive judgment criterion is adopted, such as... Figure 7 As shown, the consistency monitoring module determines that the target graphics processor verification is successful only when the actual data of all checkpoints is consistent with the corresponding expected data, thereby ensuring the reliability of the verification.

[0130] To ensure the verification report can be reused in subsequent verification phases, it can include the actual and expected data for each of the multiple checkpoints.

[0131] In one possible implementation, the consistency monitoring module in S104 compares the actual data corresponding to multiple checkpoints with the expected data corresponding to the multiple checkpoints one by one, generating a verification report for the target graphics processor: If the actual data corresponding to any of the multiple checkpoints is inconsistent with the corresponding expected data, the consistency monitoring module determines that the target graphics processor verification has failed, and the verification report shall include at least the actual data and expected data corresponding to the faulty checkpoint.

[0132] Specifically, in this embodiment, a comprehensive judgment criterion is adopted, that is, the consistency monitoring module determines that the target graphics processor verification is successful only when the actual data of all checkpoints is consistent with the corresponding expected data. At this time, such as... Figure 7 As shown, if the actual data corresponding to any of the multiple checkpoints is inconsistent with the corresponding expected data, it can be determined that the target graphics processor verification has failed.

[0133] In order to accurately locate model problems, the verification report should include at least the actual data and expected data corresponding to the fault checkpoints, i.e., output the minimum set of failure evidence for subsequent troubleshooting.

[0134] In summary, this application provides a verification method for a graphics processing unit (GPU). The method includes: abstracting the raw interface access to the target GPU into function calls for a virtual firmware execution module (VMEP) through an interface abstraction layer, wherein the VMEP is a functional-level model of the control processor subsystem within the target GPU; generating a standard transaction sequence based on the function calls, so that the VMEP and / or the target GPU execute the standard transaction sequence; acquiring actual data corresponding to multiple checkpoints, wherein the multiple checkpoints correspond to the entire process of the interface abstraction layer, the VMEP, and the target GPU; and comparing the actual data corresponding to the multiple checkpoints with the expected data corresponding to the multiple checkpoints one by one to generate a verification report for the target GPU.

[0135] Based on the above method, the original interface access is abstracted into function calls to the virtual firmware execution module through the interface abstraction layer, and a standard transaction sequence is generated through the function calls. This eliminates the need for firmware instructions, fundamentally decoupling the strong binding relationship between GPU verification and firmware instructions. Furthermore, a consistency monitoring module performs comprehensive verification at multiple checkpoints throughout the entire process to generate a verification report, thereby achieving the following effects: First, the verification cycle is brought forward. By replacing the instruction-level firmware with a virtual firmware execution module based on functional-level modeling, system-level verification can be initiated early in the architecture design process without waiting for firmware development, thus solving the problem of cycle lag between firmware programs and hardware models.

[0136] Secondly, simulation and debugging efficiency is significantly improved. By abstracting the timing-precise interface accesses at low abstraction levels into function calls at high abstraction levels through the interface abstraction layer, the underlying timing synchronization overhead is eliminated, and the simulation speed is increased by orders of magnitude. During debugging, relevant personnel only need to focus on the comparison results between the actual data and the expected data at the checkpoints, which greatly improves debugging efficiency.

[0137] Third, the verification target is precisely matched with the design phase. The verification target is clarified from the firmware instructions in the relevant technologies to whether the behavior of data flow through key processing nodes conforms to the architecture specifications. This allows verification resources to be focused on the GPU architecture design itself, avoiding insufficient verification coverage caused by introducing firmware instruction details too early.

[0138] Fourth, it provides verifiable verification benchmarks and cross-stage reuse capabilities. It outputs standardized verification reports, forming a reproducible verification loop. The checkpoint-related content included in the verification report can be reused for functional testing of subsequent instruction-level firmware development and verification of hardware code, ensuring semantic consistency of behavior throughout the entire process.

[0139] In the description of this specification, references to terms such as "some possible implementations," "some implementations," "example," "specific example," or "some examples" indicate that a specific feature, structure, material, or characteristic described in connection with that implementation or example is included in at least one implementation or example of this application, and the aforementioned terms do not necessarily refer to the same implementation or example. Furthermore, the described specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more implementations or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different implementations or examples described in this specification, as well as the features of different implementations or examples.

[0140] The method flowcharts for embodiments of this application describe certain operations as different steps performed in a certain order. Such flowcharts are illustrative and not restrictive. Some steps described herein may be grouped together and performed in a single operation, or some steps may be divided into multiple sub-steps, and some steps may be performed in an order different from that shown herein. The various steps shown in the flowcharts may be implemented in any way by any circuit structure and / or tangible mechanism (e.g., by software running on a computer device, hardware (e.g., logic functions implemented by a processor or chip), and / or any combination thereof).

[0141] Those skilled in the art will understand that in the methods described in the above specific embodiments, the order in which the steps are written does not imply a strict execution order, and the specific execution order of each step should be determined by its function and possible internal logic.

[0142] Based on the foregoing Figures 1-8 The following describes the verification apparatus for graphics processors provided in this application through device embodiments. Figure 9 A schematic diagram of a verification device for a graphics processor provided in an embodiment of this application is shown below. Figure 9 As shown, the verification device 900 for the graphics processor includes: Interface abstraction layer 901 is used to abstract raw interface accesses to the target graphics processor into function calls to the virtual firmware execution module, where the virtual firmware execution module is a functional-level model of the control processor subsystem in the target graphics processor. The virtual firmware execution module 902 is used to generate a standard transaction sequence based on the function call, so that the virtual firmware execution module and / or the target image processor can execute the standard transaction sequence. The consistency monitoring module 903 is used to acquire the actual data corresponding to multiple checkpoints, where the multiple checkpoints correspond to the entire process of the interface abstraction layer, the virtual firmware execution module, and the target image processor. The consistency monitoring module 903 is also used to compare the actual data corresponding to multiple checkpoints with the expected data corresponding to multiple checkpoints one by one, and generate a verification report for the target graphics processor.

[0143] In one possible implementation, the standard transaction sequence includes command dispatch transactions and / or self-processing transactions, where command dispatch transactions are those that need to be sent to the target graphics processor, and self-processing transactions are those that are processed autonomously by the virtual firmware execution module.

[0144] In one possible implementation, the virtual firmware execution module includes a virtual register file, which is a functional-level model of the registers that control the processor subsystem.

[0145] In one possible implementation, the interface abstraction layer is used for: The raw interface access to the registers of the control processor subsystem for the target graphics processor is abstracted into function calls to the virtual register file in the virtual firmware execution module.

[0146] In one possible implementation, the virtual firmware execution module includes a virtual queue descriptor, which includes a virtual hardware queue descriptor and a virtual software command queue descriptor. The virtual hardware queue descriptor is a functional-level model of the hardware queue description, and the virtual software command queue descriptor is a functional-level model of the software command queue description.

[0147] In one possible implementation, the interface abstraction layer is used for: The raw interface access to the target software command queue description is abstracted into function calls that configure the target virtual software command queue descriptor corresponding to the target software command queue in the virtual firmware execution module.

[0148] In one possible implementation, the virtual firmware execution module is used for: The virtual firmware execution module creates virtual context information and target virtual software command queue descriptors based on function calls; Check the status of the target virtual software command queue descriptor; If the target virtual software command queue descriptor is schedulable, bind the target virtual software command queue descriptor to an idle virtual hardware queue descriptor to generate a standard transaction sequence.

[0149] In one possible implementation, the virtual firmware execution module is also used for: If all virtual hardware queue descriptors are busy, configure the schedulable target virtual software command queue descriptor to a waiting state.

[0150] In one possible implementation, the virtual firmware execution module is also used for: Barrier writes are performed using the barrier synchronization processing function, generating barrier signal transactions.

[0151] In one possible implementation, the virtual firmware execution module is also used for: After generating the barrier signal transaction, in response to the destruction request, the destruction procedure is executed to release the associated virtual resources and reset the state.

[0152] In one possible implementation, the virtual firmware execution module is also used for: After generating the barrier signal transaction, the job completion interruption is triggered by completing the reporting function, and the job completion reporting transaction is generated.

[0153] In one possible implementation, the virtual firmware execution module includes a scheduling control unit, which performs functional-level modeling of the target graphics processor model's mailbox-based communication function, virtual hardware queue description scheduling function, idle state management function, and exception management function.

[0154] In one possible implementation, the virtual firmware execution module includes a command distribution processing unit, which performs functional-level modeling of command distribution functions for command distribution transactions, command self-processing functions for self-processing transactions, command stop and start functions, barrier synchronization processing functions, and completion reporting functions.

[0155] In one possible implementation, the multiple checkpoints include a first checkpoint for the task creation phase, which at least verifies whether the virtual firmware execution module has successfully captured and parsed the register values ​​written on the host side and whether the values ​​of the virtual registers in the virtual register stack are consistent with the expected values ​​of the registers of the control processor subsystem defined in the hardware specification.

[0156] In one possible implementation, the multiple checkpoints include a second checkpoint for the context establishment phase, which at least verifies whether the virtual firmware execution module has successfully created virtual context information and whether the target virtual software command queue descriptor has been successfully created.

[0157] In one possible implementation, the multiple checkpoints include a third checkpoint for scheduling conditions during the scheduling and queue binding phase. The third checkpoint is used to verify at least that the target virtual software command queue descriptor is in a schedulable state and that there is at least one virtual hardware queue descriptor in an idle state.

[0158] In one possible implementation, the multiple checkpoints include a fourth checkpoint for resource management during the scheduling and queue binding phase. This fourth checkpoint is used to verify at least whether the number of busy virtual hardware queue descriptors does not exceed the number of hardware queue descriptors supported by the target graphics processor, and whether the target virtual software command queue descriptor in a schedulable state is configured to a waiting state when all virtual hardware queue descriptors are busy.

[0159] In one possible implementation, the multiple checkpoints include a fifth checkpoint configured for the content of the scheduling and queue binding phase. The fifth checkpoint is at least used to verify whether the binding snapshot field of the target virtual software command queue descriptor records the information to be recorded in the command ring buffer of the corresponding virtual hardware queue descriptor at the binding time.

[0160] In one possible implementation, the multiple checkpoints include a sixth checkpoint for classification identification of the command distribution and processing phases. The sixth checkpoint is used at least to verify whether the standard transaction sequence is accurately classified as a command distribution transaction and a self-processing transaction.

[0161] In one possible implementation, the multiple checkpoints include a seventh checkpoint for self-processing compliance during the command distribution and processing phase. This seventh checkpoint is used to verify that the virtual firmware execution module's execution of self-processing transactions conforms to the firmware processing rules of the control processor subsystem.

[0162] In one possible implementation, the multiple checkpoints include an eighth checkpoint for the synchronization phase, which at least verifies whether the barrier signal transaction was generated after all associated command distribution transactions have been executed by the target graphics processor and whether the barrier write conforms to the barrier write criterion.

[0163] In one possible implementation, the multiple checkpoints include a ninth checkpoint for the cleanup phase, which at least verifies whether the virtual firmware execution module receives the destruction request after the barrier signal transaction is generated and whether the destruction procedure meets the destruction criteria.

[0164] In one possible implementation, the multiple checkpoints include a tenth checkpoint for the interruption reporting phase. The tenth checkpoint is used at least to verify whether the job completion reporting transaction is generated after the barrier signal transaction and whether the information corresponding to the job completion reporting transaction is consistent with the context information of the completed function call.

[0165] In one possible implementation, the consistency monitoring module is used for: If the actual data corresponding to each of the plurality of checkpoints is consistent with the corresponding expected data, the consistency monitoring module determines that the target graphics processor has been successfully verified, and the verification report includes the actual data and expected data corresponding to each of the plurality of checkpoints.

[0166] In one possible implementation, the consistency monitoring module is used for: If the actual data corresponding to any of the multiple checkpoints is inconsistent with the corresponding expected data, the consistency monitoring module determines that the target graphics processor verification has failed, and the verification report shall include at least the actual data and expected data corresponding to the faulty checkpoint.

[0167] It should be noted that the apparatus in the embodiments of this application can implement each process of the aforementioned method and achieve the same effect and function, which will not be elaborated here.

[0168] This application also provides an electronic device, including a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the following processing is performed: Through the interface abstraction layer, the raw interface access to the target graphics processor is abstracted into function calls to the virtual firmware execution module, where the virtual firmware execution module is a functional-level model of the control processor subsystem in the target graphics processor. The virtual firmware execution module generates a standard transaction sequence based on the function call, so that the virtual firmware execution module and / or the target image processor can execute the standard transaction sequence; The consistency monitoring module acquires the actual data corresponding to multiple checkpoints, which correspond to the entire process of the interface abstraction layer, the virtual firmware execution module, and the target image processor. The consistency monitoring module compares the actual data corresponding to multiple checkpoints with the expected data corresponding to multiple checkpoints one by one, and generates a verification report for the target graphics processor.

[0169] This application also provides a computer-readable storage medium storing a computer program. When a processor runs the computer program, it performs the steps of the verification method for a graphics processor described in the above method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0170] This application also provides a computer program product, including a computer program carrying program code. The program code includes instructions that can be used to execute the steps of the verification method for graphics processors described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0171] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0172] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the descriptions of the apparatus, device, and computer-readable storage medium embodiments are simplified because they are substantially similar to the method embodiments; relevant details can be found in the descriptions of the method embodiments.

[0173] The apparatus, device, and computer-readable storage medium provided in the embodiments of this application correspond one-to-one with the method. Therefore, the apparatus, device, and computer-readable storage medium also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the apparatus, device, and computer-readable storage medium will not be repeated here.

[0174] While the spirit and principles of this application have been described above with reference to several specific embodiments, it should be understood that this application is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined. This application is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A verification method for a graphics processing unit, characterized in that, include: Through the interface abstraction layer, the original interface access to the target graphics processor is abstracted into function calls to the virtual firmware execution module, wherein the virtual firmware execution module is a functional-level model of the control processor subsystem in the target graphics processor. The virtual firmware execution module generates a standard transaction sequence according to the function call, so that the virtual firmware execution module and / or the target image processor execute the standard transaction sequence; The consistency monitoring module acquires the actual data corresponding to multiple checkpoints, wherein the multiple checkpoints correspond to the entire process of the interface abstraction layer, the virtual firmware execution module, and the target image processor; The consistency monitoring module compares the actual data corresponding to each of the multiple checkpoints with the expected data corresponding to each of the multiple checkpoints, and generates a verification report for the target graphics processor.

2. The method according to claim 1, characterized in that, The standard transaction sequence includes command distribution transactions and / or self-processing transactions. The command distribution transaction is a transaction that needs to be sent to the target graphics processor, and the self-processing transaction is a transaction that is processed autonomously by the virtual firmware execution module.

3. The method according to claim 1, characterized in that, The virtual firmware execution module includes a virtual register file, which is a functional-level model of the registers of the control processor subsystem.

4. The method according to claim 3, characterized in that, The process of abstracting the raw interface access to the target graphics processor into function calls to the virtual firmware execution module through the interface abstraction layer includes: Through the interface abstraction layer, the raw interface access to the registers of the control processor subsystem of the target graphics processor is abstracted into function calls to the virtual register file in the virtual firmware execution module.

5. The method according to claim 1, characterized in that, The virtual firmware execution module includes a virtual queue descriptor, which includes a virtual hardware queue descriptor and a virtual software command queue descriptor. The virtual hardware queue descriptor is a functional-level model of the hardware queue description, and the virtual software command queue descriptor is a functional-level model of the software command queue description.

6. The method according to claim 5, characterized in that, The process of abstracting the raw interface access to the target graphics processor into function calls to the virtual firmware execution module through the interface abstraction layer includes: Through the interface abstraction layer, the original interface access to the target software command queue description is abstracted into function calls in the virtual firmware execution module that configure the target virtual software command queue descriptor corresponding to the target software command queue.

7. The method according to claim 6, characterized in that, The virtual firmware execution module generates a standard transaction sequence based on the function call, including: The virtual firmware execution module creates virtual context information and the target virtual software command queue descriptor according to the function call; The virtual firmware execution module checks the status of the target virtual software command queue descriptor; If the target virtual software command queue descriptor is schedulable, the virtual firmware execution module binds the target virtual software command queue descriptor to an idle virtual hardware queue descriptor to generate a standard transaction sequence.

8. The method according to claim 7, characterized in that, The method further includes: If all virtual hardware queue descriptors are busy, the virtual firmware execution module will configure the schedulable target virtual software command queue descriptor to a waiting state.

9. The method according to claim 1, characterized in that, The method further includes: The virtual firmware execution module performs barrier writing through the barrier synchronization processing function, generating barrier signal transactions.

10. The method according to claim 9, characterized in that, After generating the barrier signal transaction, the method further includes: In response to a destruction request, the virtual firmware execution module executes a destruction procedure to release the associated virtual resources and reset the state.

11. The method according to claim 9, characterized in that, After generating the barrier signal transaction, the method further includes: The virtual firmware execution module triggers a job completion interruption by completing the reporting function, and generates a job completion reporting transaction.

12. The method according to claim 1, characterized in that, The virtual firmware execution module includes a scheduling control unit, which performs functional-level modeling of the target graphics processor model's mailbox-based communication function, virtual hardware queue description scheduling function, idle state management function, and exception management function.

13. The method according to claim 1, characterized in that, The virtual firmware execution module includes a command distribution processing unit, which performs functional-level modeling of command distribution functions for command distribution transactions, command self-processing functions for self-processing transactions, command stop and start functions, barrier synchronization processing functions, and completion reporting functions.

14. The method according to claim 3, characterized in that, The plurality of checkpoints includes a first checkpoint for the task creation phase, which is at least used to verify whether the virtual firmware execution module has successfully captured and parsed the register values ​​written on the host side and whether the values ​​of the virtual registers in the virtual register stack are consistent with the expected values ​​of the registers of the control processor subsystem defined in the hardware specification.

15. The method according to claim 7, characterized in that, The plurality of checkpoints includes a second checkpoint for the context establishment phase, which is at least used to verify whether the virtual firmware execution module has successfully created virtual context information and whether it has successfully created the target virtual software command queue descriptor.

16. The method according to claim 7, characterized in that, The plurality of checkpoints includes a third checkpoint for scheduling conditions during the scheduling and queue binding phase. The third checkpoint is used at least to verify that the target virtual software command queue descriptor is in a schedulable state and that there is at least one virtual hardware queue descriptor in an idle state.

17. The method according to claim 8, characterized in that, The multiple checkpoints include a fourth checkpoint for resource management during the scheduling and queue binding phase. This fourth checkpoint is used to verify at least whether the number of busy virtual hardware queue descriptors does not exceed the number of hardware queue descriptors supported by the target graphics processor, and whether the target virtual software command queue descriptor in a schedulable state is configured to a waiting state when all virtual hardware queue descriptors are busy.

18. The method according to claim 7, characterized in that, The plurality of checkpoints includes a fifth checkpoint configured for the content of the scheduling and queue binding phase. The fifth checkpoint is at least used to verify whether the binding snapshot field of the target virtual software command queue descriptor records the information to be recorded in the command ring buffer of the corresponding virtual hardware queue descriptor at the time of binding.

19. The method according to claim 2, characterized in that, The plurality of checkpoints includes a sixth checkpoint for classification and identification of the command distribution and processing phases, which is used at least to verify whether the standard transaction sequence is accurately classified as a command distribution transaction and a self-processing transaction.

20. The method according to claim 2, characterized in that, The plurality of checkpoints includes a seventh checkpoint for self-processing compliance during the command distribution and processing phase. The seventh checkpoint is used at least to verify that the virtual firmware execution module performs the self-processing transaction in accordance with the firmware processing rules of the control processor subsystem.

21. The method according to claim 9, characterized in that, The plurality of checkpoints includes an eighth checkpoint for the synchronization phase, which is at least used to verify whether the barrier signal transaction is generated after all associated command distribution transactions have been executed by the target graphics processor and whether the barrier write conforms to the barrier write standard.

22. The method according to claim 10, characterized in that, The plurality of checkpoints includes a ninth checkpoint for the cleanup phase, which is at least used to verify whether the virtual firmware execution module receives the destruction request after the barrier signal transaction is generated and whether the destruction procedure meets the destruction criteria.

23. The method according to claim 11, characterized in that, The plurality of checkpoints includes a tenth checkpoint for the interruption reporting phase. The tenth checkpoint is used at least to verify whether the job completion reporting transaction is generated after the barrier signal transaction is generated and whether the information corresponding to the job completion reporting transaction is consistent with the context information of the completed function call.

24. The method according to claim 1, characterized in that, The consistency monitoring module compares the actual data corresponding to each of the multiple checkpoints with the expected data corresponding to each of the multiple checkpoints, and generates a verification report for the target graphics processor, including: If the actual data corresponding to each of the plurality of checkpoints is consistent with the corresponding expected data, the consistency monitoring module determines that the target graphics processor has been successfully verified, and the verification report includes the actual data and expected data corresponding to each of the plurality of checkpoints.

25. The method according to claim 1, characterized in that, The consistency monitoring module compares the actual data corresponding to each of the multiple checkpoints with the expected data corresponding to each of the multiple checkpoints, and generates a verification report for the target graphics processor, including: If the actual data corresponding to any of the multiple checkpoints is inconsistent with the corresponding expected data, the consistency monitoring module determines that the target graphics processor verification has failed, and the verification report includes at least the actual data and expected data corresponding to the fault checkpoint.

26. A verification device for a graphics processor, characterized in that, include: An interface abstraction layer is used to abstract raw interface accesses to the target graphics processor into function calls to the virtual firmware execution module, wherein the virtual firmware execution module is a functional-level model of the control processor subsystem in the target graphics processor. A virtual firmware execution module is configured to generate a standard transaction sequence based on the function call, so that the virtual firmware execution module and / or the target image processor execute the standard transaction sequence; The consistency monitoring module is used to acquire the actual data corresponding to multiple checkpoints, wherein the multiple checkpoints correspond to the entire process of the interface abstraction layer, the virtual firmware execution module, and the target image processor; The consistency monitoring module is also used to compare the actual data corresponding to the multiple checkpoints with the expected data corresponding to the multiple checkpoints one by one, and generate a verification report for the target graphics processor.

27. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the memory via the bus, and the machine-readable instructions, when executed by the processor, perform the verification method for a graphics processor as described in any one of claims 1 to 25.

28. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the verification method for a graphics processor as described in any one of claims 1 to 25.

29. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, performs the verification method for a graphics processor as described in any one of claims 1 to 25.

Images