CN120011239A

CN120011239A - GPU system verification method, device, electronic device, storage medium and program product

Info

Publication number: CN120011239A
Application number: CN202510168068.9A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Mole Thread Intelligent Technology Beijing Co ltd
Current assignee: Mole Thread Intelligent Technology Beijing Co ltd
Priority date: 2025-02-14
Filing date: 2025-02-14
Publication date: 2025-05-16

Abstract

The present disclosure relates to a GPU system verification method, device, electronic device, storage medium and program product. The method comprises: obtaining a target random test stimulus sequence; inputting the target random test stimulus sequence into a GPU function model and a register transfer level model respectively; wherein the GPU function model is a software model for simulating the function of a GPU; the register transfer level model is a model written based on a hardware description language, and the register transfer level model is used to describe the hardware implementation and behavior of the GPU; obtaining the functional simulation result output by the GPU function model in response to the target random test stimulus sequence, and the simulation result output by the register transfer level model in response to the target random test stimulus sequence; comparing the functional simulation result with the simulation result to obtain the first random verification result of the GPU system. The present disclosure can significantly improve the flexibility of GPU system verification.

Description

GPU system verification method, device, electronic equipment, storage medium and program product

Technical Field

The present disclosure relates to the field of integrated circuit technology, and in particular, to a GPU system verification method, a GPU system verification device, an electronic device, a computer readable storage medium, and a computer program product.

Background

With the rapid development of artificial intelligence (ARTIFICIAL INTELLIGENCE, AI) technology, the functionality and the scene of a GPU (Graphics Processing Unit ) as the core hardware for AI computation are growing exponentially. GPU systems are important components in chip design, and their verification work is particularly important. However, due to the increasing high complexity and functionality requirements of GPU systems, conventional GPU system verification methods have been difficult to meet.

Disclosure of Invention

The disclosure provides a GPU system verification technical scheme.

According to an aspect of the present disclosure, there is provided a GPU system verification method, including:

obtaining a target random test excitation sequence;

The target random test excitation sequence is respectively input into a GPU function model and a register transmission level model, wherein the GPU function model is a software model for simulating the functions of the GPU, the register transmission level model is a model written based on a hardware description language, and the register transmission level model is used for describing the hardware realization and the behavior of the GPU;

Obtaining a functional simulation result output by the GPU functional model in response to the target random test excitation sequence, and a simulation result output by the register transmission stage model in response to the target random test excitation sequence;

and comparing the functional simulation result with the simulation result to obtain a first random verification result of the GPU system.

In one possible implementation, the GPU functional model is consistent with the model structure and interface definition of the register transfer level model;

The method further comprises the steps of:

Obtaining first intermediate interface response data generated by an intermediate interface of the GPU functional model based on the target random test excitation sequence, and second intermediate interface response data generated by an intermediate interface of the register transmission level model based on the target random test excitation sequence;

And comparing the first intermediate interface response data with the second intermediate interface response data to obtain a second random verification result of the GPU system.

In one possible implementation of the present invention,

The step of inputting the target random test excitation sequence into a GPU functional model and a register transmission level model respectively comprises the steps of synchronously inputting the target random test excitation sequence into the GPU functional model and the register transmission level model;

The comparison of the function simulation result and the simulation result to obtain a first random verification result of the GPU system comprises the steps of comparing the function simulation result and the simulation result in real time to obtain the first random verification result of the GPU system.

In one possible implementation of the present invention,

Before the target random test excitation sequence is obtained, the method further comprises the steps of generating a random test excitation sequence;

the obtaining the target random test excitation sequence comprises the step of obtaining the target random test excitation sequence from the random test excitation sequence passing constraint inspection.

In one possible implementation, the generating a random test stimulus sequence includes:

Generating an incentive generator based on the programming guide information;

A random test stimulus sequence is generated by the stimulus generator.

Receiving user input parameters through a graphical interface, wherein the user input parameters comprise at least part of the following types of frame size, tile size and core size;

Based on the user input parameters, a random test stimulus sequence is generated.

In one possible implementation, the method further includes:

In response to a user selecting a vertex in the graphical interface, a graphic formed by the vertex is displayed in the graphical interface.

In one possible implementation, the performing constraint checking on the random test stimulus sequence includes:

And performing constraint checking on the random test stimulus sequence based on a global constraint set, wherein the global constraint set is generated based on constraint conditions of a plurality of levels and constraint conditions among the plurality of levels.

In one possible implementation, the GPU functionality model includes:

The GPU full-function model is used for simulating all functions of the GPU, wherein the GPU full-function model is mounted on a top-level verification environment;

And

And the GPU sub-function model is used for simulating the functions of part of the modules of the GPU, wherein the GPU sub-function model is hung on a sub-verification environment, and the input of the GPU sub-function model is from the register transmission level model.

In one possible implementation, the method further comprises multiplexing a constraint checker of the sub-verification environment to perform constraint checking on random test stimulus sequences.

In one possible implementation, the number of sub-authentication environments is at least one, and any one sub-authentication environment controls the switch according to a user instruction.

In one possible implementation, the method further includes:

Analyzing the interface information of the GPU according to a predefined rule to obtain at least two levels of interface data;

And generating a statistical chart corresponding to the interface information of the GPU according to the interface data of the at least two levels.

In one possible implementation, the at least two levels include at least part of:

draw call level, tile level, frame level.

According to an aspect of the present disclosure, there is provided a GPU system authentication apparatus, including:

the first acquisition module is used for acquiring a target random test excitation sequence;

The system comprises an input module, a register transmission level model, a data processing module and a data processing module, wherein the input module is used for respectively inputting the target random test excitation sequence into a GPU function model and the register transmission level model, the GPU function model is a software model for simulating the functions of a GPU, the register transmission level model is a model written based on a hardware description language, and the register transmission level model is used for describing the hardware realization and the behaviors of the GPU;

the second obtaining module is used for obtaining a functional simulation result output by the GPU functional model in response to the target random test excitation sequence and a simulation result output by the register transmission stage model in response to the target random test excitation sequence;

and the first comparison module is used for comparing the functional simulation result with the simulation result to obtain a first random verification result of the GPU system.

the apparatus further comprises:

The third obtaining module is used for obtaining first intermediate interface response data generated by the intermediate interface of the GPU functional model based on the target random test excitation sequence and second intermediate interface response data generated by the intermediate interface of the register transmission level model based on the target random test excitation sequence;

and the second comparison module is used for comparing the first intermediate interface response data with the second intermediate interface response data to obtain a second random verification result of the GPU system.

In one possible implementation of the present invention,

The input module is used for synchronously inputting the target random test excitation sequence into a GPU functional model and a register transmission level model;

The first comparison module is used for comparing the functional simulation result with the simulation result in real time to obtain a first random verification result of the GPU system.

In one possible implementation of the present invention,

The apparatus further comprises:

the first generation module is used for generating a random test excitation sequence;

the checking module is used for performing constraint checking on the random test excitation sequence;

the first obtaining module is used for obtaining a target random test excitation sequence from the random test excitation sequence passing the constraint check.

In one possible implementation manner, the first generating module is configured to:

Generating an incentive generator based on the programming guide information;

A random test stimulus sequence is generated by the stimulus generator.

In one possible implementation, the apparatus further includes:

and the display module is used for responding to the selection of the vertexes in the graphical interface by a user and displaying the graphics formed by the vertexes in the graphical interface.

In one possible implementation, the checking module is configured to:

In one possible implementation, the GPU functionality model includes:

And

In one possible implementation, the apparatus further includes:

and the multiplexing module is used for multiplexing the constraint checker of the sub-verification environment and performing constraint check on the random test excitation sequence.

In one possible implementation, the apparatus further includes:

the analysis module is used for analyzing the interface information of the GPU according to a predefined rule to obtain at least two levels of interface data;

And the second generation module is used for generating a statistical chart corresponding to the interface information of the GPU according to the interface data of the at least two levels.

draw call level, tile level, frame level.

According to an aspect of the disclosure, an electronic device is provided, comprising one or more processors, a memory for storing executable instructions, wherein the one or more processors are configured to invoke the executable instructions stored by the memory to perform the above method.

According to an aspect of the present disclosure, there is provided a computer readable storage medium having stored thereon computer program instructions which, when executed by a processor, implement the above-described method.

According to an aspect of the present disclosure, there is provided a computer program product comprising a computer readable code, or a non-transitory computer readable storage medium carrying computer readable code, which when run in an electronic device, a processor in the electronic device performs the above method.

In the embodiment of the disclosure, a target random test excitation sequence is obtained, the target random test excitation sequence is respectively input into a GPU functional model and a register transmission level model, wherein the GPU functional model is a software model for simulating functions of a GPU, the register transmission level model is a model written based on a hardware description language, the register transmission level model is used for describing hardware implementation and behaviors of the GPU, a functional simulation result which is output by the GPU functional model in response to the target random test excitation sequence is obtained, and a simulation result which is output by the register transmission level model in response to the target random test excitation sequence is obtained, and the functional simulation result is compared with the simulation result to obtain a first random verification result of the GPU system. The embodiment of the disclosure can effectively make up the defects of the traditional pdump test set, is beneficial to covering modification and special edge scenes of a micro-architecture, and can effectively verify complex scenes such as context switch (context switch), and the like, because the random verification scheme can simulate various possible running paths, the verification coverage rate can be improved, and the risk of error or defect (bug) missing detection is reduced.

By adopting the GPU system verification method provided by the embodiment of the disclosure, the efficiency and the accuracy of GPU system verification can be improved, and rapid growth of GPU functions and scenes can be better dealt with. The embodiment of the disclosure has wide application prospect in the field of GPU chip design and has important significance for promoting the development of artificial intelligence technology. By ensuring high quality and reliability of the GPU chip, wider application scenes can be supported, and innovation and progress of AI technology are further promoted.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Other features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments, which proceeds with reference to the accompanying drawings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the technical aspects of the disclosure.

Fig. 1 shows a flowchart of a GPU system verification method provided by an embodiment of the present disclosure.

Fig. 2 is a schematic diagram of a GPU system verification method according to an embodiment of the present disclosure.

Fig. 3 shows another schematic diagram of a GPU system verification method provided by an embodiment of the present disclosure.

Fig. 4 is another schematic diagram of a GPU system verification method according to an embodiment of the present disclosure.

Fig. 5 shows a block diagram of a GPU system authentication apparatus provided by an embodiment of the present disclosure.

Fig. 6 shows a block diagram of an electronic device 1900 provided by an embodiment of the disclosure.

Detailed Description

Various exemplary embodiments, features and aspects of the disclosure will be described in detail below with reference to the drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Although various aspects of the embodiments are illustrated in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

The word "exemplary" is used herein to mean "serving as an example, embodiment, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

The term "and/or" is merely an association relationship describing the associated object, and means that three relationships may exist, for example, a and/or B may mean that a exists alone, while a and B exist together, and B exists alone. In addition, the term "at least one" herein means any one of a plurality or any combination of at least two of a plurality, for example, including at least one of A, B, C, may mean including any one or more elements selected from the group consisting of A, B and C.

Furthermore, numerous specific details are set forth in the following detailed description in order to provide a better understanding of the present disclosure. It will be understood by those skilled in the art that the present disclosure may be practiced without some of these specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art have not been described in detail in order not to obscure the present disclosure.

In the related art, the GPU system verification method mainly relies on pdump (PARAMETER DUMP ) test set generated by software, but pdump test set has the following problems:

first, pdump test sets are under-covered. pdump test cases in pdump test sets are limited, so that the modification of micro-architecture and some special edge scenes (burner scenes) are difficult to cover, and missing errors or defects (bug) are easy to cause.

Second, pdump test sets have difficulty in timing coverage. Because the time sequence of the software is inconsistent with the time sequence of the hardware, the pdump test set is difficult to achieve time sequence coverage, and particularly when complex time sequence tests such as context switch (context switch) and the like are performed, errors or defects are easy to miss.

In particular, the operation of GPU hardware is typically highly parallelized and its execution order may be affected by many factors, such as memory latency, cache hits/misses, hardware optimizations, and so forth. In contrast, software (e.g., drivers and applications) typically execute instructions in a more explicit order, which may result in timing inconsistencies between the software and hardware when capturing and analyzing pdump data.

Context switching is a very complex operation in GPUs that involves saving the state of the current context, loading new context states, and possibly memory management and reconfiguration of other hardware resources. This process may involve a time span of microseconds to milliseconds and may involve interaction of multiple hardware components and software. Since pdump may not be able to accurately capture all relevant interactions and events, certain important details or events may be missed when analyzing complex timing operations such as context switches.

Timing coverage means that the test set is able to cover and verify all possible or critical timing paths and scenarios. However, the pdump test set may have difficulty fully covering all critical timing paths due to the software and hardware timing inconsistencies described above and the complexity of context switching. Particularly when interactions between multiple contexts, competing conditions of hardware resources, and exception or error handling are involved, pdump test sets may be more prone to missing certain errors or flaws.

In order to solve the technical problems similar to the above, the embodiments of the present disclosure provide a GPU system verification method, by obtaining a target random test excitation sequence, inputting the target random test excitation sequence into a GPU functional model and a register transmission level model, respectively, where the GPU functional model is a software model for simulating functions of a GPU, the register transmission level model is a model written based on a hardware description language, and the register transmission level model is used to describe hardware implementation and behavior of the GPU, obtain a functional simulation result output by the GPU functional model in response to the target random test excitation sequence, and compare the functional simulation result with the simulation result, obtain a first random verification result of the GPU system, thereby introducing a random verification scheme, covering a wider scene in the GPU system with a random test case, and significantly improving flexibility of GPU system verification. The embodiment of the disclosure can effectively make up the defects of the traditional pdump test set, is beneficial to covering modification and special edge scenes of a micro-architecture, and can effectively verify complex scenes such as context switch (context switch), and the like, because the random verification scheme can simulate various possible running paths, the verification coverage rate can be improved, and the risk of error or defect (bug) missing detection is reduced.

The GPU system verification method provided by the embodiments of the present disclosure is described in detail below with reference to the accompanying drawings.

Fig. 1 shows a flowchart of a GPU system verification method provided by an embodiment of the present disclosure. In one possible implementation, the execution subject of the GPU system verification method may be a GPU system verification device, for example, the GPU system verification method may be executed by a terminal device or a server or other electronic device. The terminal device may be a User Equipment (UE), a mobile device, a User terminal, a cellular phone, a cordless phone, a Personal digital assistant (Personal DIGITAL ASSISTANT, PDA), a handheld device, a computing device, a vehicle mounted device, or a wearable device. In some possible implementations, the GPU system validation method may be implemented by way of a processor invoking computer readable instructions stored in a memory. As shown in fig. 1, the GPU system verification method includes steps S11 to S14.

In step S11, a target random test stimulus sequence is obtained.

In step S12, the target random test excitation sequence is input into a GPU functional model and a register transmission level model, respectively, where the GPU functional model is a software model for simulating functions of a GPU, the register transmission level model is a model written based on a hardware description language, and the register transmission level model is used to describe hardware implementation and behavior of the GPU.

In step S13, a functional simulation result output by the GPU functional model in response to the target random test stimulus sequence is obtained, and a simulation result output by the register transfer level model in response to the target random test stimulus sequence is obtained.

In step S14, the functional simulation result is compared with the simulation result, so as to obtain a first random verification result of the GPU system.

In an embodiment of the present disclosure, the GPU system is validated based on a GPU functional model and a register transfer stage (REGISTER TRANSFER LEVEL, RTL) model.

The GPU functional model may be a software model for simulating the functions of the GPU. In the process of verifying the GPU system, the GPU function model can be used as a reference model.

In one possible implementation, the GPU functional model may be a functional model written in a high level programming language (e.g., C or c++). The high-level programming language provides a programming interface and rich library functions that are easier to understand and use, enabling developers to more quickly implement and verify the functionality and operation of the GPU. For example, the GPU functionality model may be a C model (cmodel).

Of course, the GPU functional model need not be written based on a high level programming language, and there are other programming modes or tools that can be used to write the GPU functional model, depending on the requirements and goals of the project. In some cases, the functional model may be written using a particular GPU programming language or framework (e.g., CUDA, openCL, etc.) to better utilize the parallel computing capabilities of the GPU.

In the disclosed embodiments, a register transfer level model may be used to simulate the behavior and functionality of the GPU hardware for verification and testing prior to actual hardware fabrication. The register transfer level model may be written using a hardware description language (e.g., verilog or VHDL) and may describe the connection and operational behavior between the various registers and logic units in the GPU.

Fig. 2 is a schematic diagram of a GPU system verification method according to an embodiment of the present disclosure. As shown in fig. 2, a register transfer level model and a GPU functional model are included in the top level verification environment, and a random test stimulus sequence may be input to the register transfer level model and the GPU functional model, respectively. In fig. 2, a first DDR may represent a DDR (Double Data Rate) used by the register transfer level model, and a second DDR may represent a DDR used by the GPU functional model.

In the disclosed embodiments, the target random test stimulus sequence may be any random test stimulus sequence used to validate the GPU system. In random testing, the stimulus sequence used for each test may be random, meaning that the input for each test may be different even for the same test target. By using different test seeds, different random test stimulus sequences can be generated. This diversity enables random testing to cover more test scenarios and paths, i.e., to explore a wider test space, and potentially discover defects that are difficult to discover based on a fixed test case set (e.g., pdump test set). By randomly generating a large number of test cases, it is possible to cover more code paths and state transitions as long as the test time is long enough. Thus, random testing can improve coverage of GPU system verification, especially for those parts that are complex and difficult to fully cover by conventional pdump testing methods.

Also, random testing need not depend on a particular software environment or input data. The method can directly test the bottom interfaces of hardware or a system, so that the time sequence of each interface can be controlled more flexibly. This is particularly important for testing those timing related functions (e.g., context switches, interrupt handling, etc.). Because the random test can flexibly control the time sequence of the interface, the random test can better simulate the time sequence abnormal condition possibly occurring in an actual system. For example, in testing context switches, random testing may simulate different context switch frequencies, time intervals, and priority changes to verify that the GPU system is able to properly handle these timing related scenarios.

In one possible implementation, before the obtaining the target random test excitation sequence, the method further comprises generating a random test excitation sequence, performing constraint checking on the random test excitation sequence, and obtaining the target random test excitation sequence, wherein the obtaining the target random test excitation sequence comprises obtaining the target random test excitation sequence from the random test excitation sequence passing the constraint checking.

In this implementation, a large number of random test stimulus sequences may be generated for comprehensive testing of the performance and stability of the GPU when performing GPU system validation. A random test stimulus sequence is a set of input data that is used to drive the GPU to perform a particular task or operation. Because of the complexity and variety of GPUs, the generated random test stimulus sequences may contain inputs that are invalid or otherwise not compliant with the test requirements, and therefore require constraint checking of these random test stimulus sequences.

Specifically, in this implementation, first, a series of random test stimulus sequences may be generated. The random test stimulus sequence may contain various possible combinations of inputs, intended to cover different operating scenarios and boundary conditions of the GPU system.

The generated random test stimulus sequence may be subjected to a constraint checking process. Constraint checking is a process that ensures that a random test stimulus sequence meets certain conditions or rules. In GPU system validation, these constraints may include validity of the input data, usage limitations of GPU resources, limitations of execution time, and so on. Through constraint inspection, the random test excitation sequences which do not meet the requirements can be filtered out, and the effectiveness and accuracy of subsequent tests are ensured.

And, a target random test stimulus sequence may be selected or generated from the random test stimulus sequences that pass the constraint check to verify the GPU system with the target random test stimulus sequence.

In the implementation mode, by introducing a generation and constraint checking mechanism of a random test excitation sequence, test data meeting the verification requirement of the GPU system can be efficiently and accurately generated. The method not only improves the comprehensiveness and coverage rate of the verification of the GPU system, but also reduces the probability of invalid or repeated test, thereby improving the efficiency and accuracy of the verification of the GPU system.

In one possible implementation, the generating a random test stimulus sequence includes generating a stimulus generator based on programming guide (programming guide) information, and generating a random test stimulus sequence by the stimulus generator.

In this implementation, the stimulus generator may be a tool capable of automatically or semi-automatically generating a random test stimulus sequence. As one example of this implementation, a top-down approach may be employed to generate the stimulus generator based on programming guide information. That is, in generating the stimulus generator, the specific implementation details may be refined step by step, starting from a high level of requirements or specifications. For example, in GPU system validation, configuration and input data to various stages may be started from the entire rendering flow or function and then refined. The generated stimulus generator may be used to generate a random test stimulus sequence that meets various constraints.

The programming guide information may provide, among other things, detailed information about how to configure and use the GPU hardware or software interface. This information is critical to creating a legitimate test stimulus. For example, programming guide information may specify which parameters are optional, which parameters are interdependent, their effective range, and so forth. For example, the programming guide information may include a register configuration, an instruction sequence of a shader code (shader code), data preparation in a memory or memory area supporting a back door access mode, and so forth.

For example, the random test stimulus sequence may include register configuration information for the GPU, where the register configuration information for the GPU defines how the hardware works. For example, block size (tile size), block rendering mode (TIR mode, TILE RENDERING mode), multi-sampling antialiasing mode (multi-SAMPLE ANTI-actuation mode, MSAAmode), etc. are examples of GPU register configurations. The correctness of these configuration parameters is crucial for obtaining a correct rendering result. For example, once the block rendering mode and the multi-sampling antialiasing mode are determined, the block size will also be determined. Once the block size is determined, the block partitioning of the frame (frame) will be affected, thereby affecting the partitioning of which block each triangle belongs to in the geometry stage and the associated processing of fragments. These constraints may be obtained from programming guide information and written to the stimulus generator to ensure that the random test stimulus sequence generated is legal and valid.

In one possible implementation, the generating the random test stimulus sequence includes receiving user input parameters through a graphical interface, wherein the user input parameters include at least part of a frame size, a tile size, a kernel size, and generating the random test stimulus sequence based on the user input parameters.

In this implementation, the graphical interface provides an intuitive interaction environment, and the user can input various parameters by means of mouse clicking, keyboard input and the like. The parameters entered by the user may be used to generate a random test stimulus sequence. For example, the user input parameters may include frame size (Framesize), tile size (Tilesize), kernel size (Kernel size), and so on. After the parameters entered by the user are received by the graphical interface program, the graphical interface program may generate a random test stimulus sequence based on the user entered parameters.

In one example, the graphical interface may include a frame size input box in which a user may input the width and height of a frame (e.g., 1920x 1080). The graphical interface may include a tile size input box in which a user may input the width and height of a tile (e.g., 32x 32). The graphical interface may include a core size input box in which a user may input the size (e.g., 16x 16) of each core in the computing task.

In one example, the user may enter parameters through a visualization form of the graphical interface. Wherein the visualization form is an interactive component for entering and configuring parameters. It is presented in a form that allows the user to enter parameters by filling in the various fields in the form.

The realization mode remarkably improves the efficiency and convenience of GPU excitation manufacturing through the visual interface. The user can intuitively configure parameters of the graphics rendering or parallel computing task, such as frame size, tile size, kernel size, etc. This not only optimizes stimulus generation flow, but also enhances coverage of complex test scenarios, especially boundary (burner) test points. In addition, the implementation method accelerates project progress, improves flexibility and adaptability of verification work, and brings higher efficiency and wider applicability to GPU verification work.

In one possible implementation, the method further includes displaying a graphic formed by the vertices in the graphical interface in response to a user selecting the vertices in the graphical interface.

In this implementation, the user may manually select vertices through a graphical interface, which define corner points of a graph (e.g., triangle, quadrilateral, etc.). The graphical interface may display the graphics formed by the vertices in real-time as the user selects the vertices. This visual function allows the user to intuitively observe the size and shape of the graphic, thereby more precisely controlling the generation of the test stimulus.

In one possible implementation, the performing constraint checking on the random test stimulus sequence includes performing constraint checking on the random test stimulus sequence based on a global constraint set, wherein the global constraint set is generated based on a plurality of levels of constraints and constraints between the plurality of levels.

The configuration and operation of a GPU involves multiple levels that each play a different role in processing graphics tasks. For example, multiple levels include a register level (REGISTER LEVEL) level, a draw call (Drawcall) level, an Instruction (Instruction) level, each of which has different characteristics and constraints.

In generating the random test stimulus sequence, generation of the random test stimulus sequence is typically performed based on constraint conditions of each level, that is, constraint errors across levels may occur in generating the random test stimulus sequence.

As one example of this implementation, the global set of constraints may be generated based on constraints of all levels and constraints between all levels.

As one example of this implementation, the random test stimulus sequence may be constraint checked by a global constraint checker based on a global constraint set. In one example, the global constraint checker may be represented by vseq _ons_ checker.

In this implementation, a global constraint set may be generated based on constraint conditions of a plurality of levels and constraint conditions between the plurality of levels, and constraint checking is performed on the random test excitation sequence based on the global constraint set, thereby leveling all levels, and detecting whether the random test excitation sequence satisfies all constraint conditions in real time. Once the random test excitation sequence is detected to not meet any constraint condition, constraint inspection on the random test excitation sequence can be stopped immediately, and GPU system verification is not performed by using the random test excitation sequence, so that verification workload of excitation errors can be reduced, invalid verification work is reduced, workload of verification staff is reduced, and efficiency of verification on a GPU system and convergence speed of projects are improved.

In this implementation, by uniformly processing the constraint conditions of all the levels through the global constraint set, it is possible to check whether the random test stimulus sequence satisfies the constraint conditions of all the levels at one time without performing constraint checking on each level separately. The leveling processing mode can obviously reduce the iteration times and repeated work in the verification process, thereby improving the verification efficiency.

In addition, since the global constraint set includes constraints of all levels and constraints between levels, various aspects of the GPU system can be fully covered. The comprehensive constraint checking can reduce verification failure caused by cross-level constraint errors and reduce verification error rate.

By reducing invalid verification work and reducing verification error rate, the convergence speed of the GPU system verification project can be accelerated by flattening all the layers and performing constraint checking. The verification team can discover and repair potential problems faster, ensuring that the quality and performance of the GPU system reaches the intended goal.

Fig. 3 shows another schematic diagram of a GPU system verification method provided by an embodiment of the present disclosure. As shown in FIG. 3, a random test stimulus sequence may be generated by a stimulus generator and may be constraint checked by a global constraint checker in a top-level verification environment.

In the embodiment of the disclosure, the target random test excitation sequence may be input into the GPU functional model and the register transmission stage model, respectively, and a functional simulation result output by the GPU functional model in response to the target random test excitation sequence and a simulation result output by the register transmission stage model in response to the target random test excitation sequence may be obtained.

The functional simulation result may represent a final output of the GPU functional model in response to the target random test excitation sequence, and the simulation result may represent a final output of the register transfer level model in response to the target random test excitation sequence. In some application scenarios, the output of the GPU functional model may also be referred to as a reference model output result, etc., without limitation, and the output of the register transfer level model may also be referred to as a hardware model output result, etc., without limitation.

In the embodiment of the disclosure, the functional simulation result and the simulation result may be compared to obtain a first random verification result of the GPU system. The first random verification result may represent a verification result obtained by comparing the functional simulation result with the simulation result.

In one possible implementation manner, the step of inputting the target random test excitation sequence into a GPU function model and a register transmission stage model respectively comprises the step of synchronously inputting the target random test excitation sequence into the GPU function model and the register transmission stage model, and the step of comparing the function simulation result with the simulation result to obtain a first random verification result of the GPU system comprises the step of comparing the function simulation result with the simulation result in real time to obtain the first random verification result of the GPU system.

In this implementation, the target random test stimulus sequence may be input to the GPU functional model and the register transfer level model in a synchronous manner. That is, the GPU functional model and the register transfer level model may receive the same stimulus sequence at the same time.

In addition, in the implementation mode, the function simulation result output by the GPU function model is compared with the simulation result output by the register transmission stage model in real time. Wherein, the real-time comparison can indicate that the comparison is performed immediately once the result is generated in the test process, rather than waiting for all the tests to be completed.

In the related art, pdump test set is an offline test for a GPU functional model (e.g., cmodel).

In the implementation mode, an online GPU function model is used for testing, namely, the GPU function model and a register transmission level model synchronously receive a target random test excitation sequence, and a function simulation result output by the GPU function model is compared with a simulation result output by the register transmission level model in real time, so that the real-time performance and the accuracy of verification of a GPU system can be improved. The real-time comparison can immediately find out the difference or error in the design of the GPU system, so that the problem is rapidly positioned, and the verification efficiency and accuracy of the GPU system are improved. Compared with the traditional offline testing method, the implementation mode can feed back the random verification result more quickly, and further shortens the period of product development and verification.

In one possible implementation manner, the GPU function model is consistent with the model structure and interface definition of the register transmission level model, the method further comprises the steps of obtaining first intermediate interface response data generated by an intermediate interface of the GPU function model based on the target random test excitation sequence and second intermediate interface response data generated by an intermediate interface of the register transmission level model based on the target random test excitation sequence, and comparing the first intermediate interface response data with the second intermediate interface response data to obtain a second random verification result of the GPU system.

In this implementation, the GPU functional model and the register transfer level model may be designed to have a consistent model structure (i.e., consistent module partitioning) and interface definition. That is, the GPU functional model and the register transfer level model are logically mutually corresponding. When the target random test stimulus sequence is input into the GPU functional model and the register transfer level model, the GPU functional model and the register transfer level model generate respective intermediate interface response data. Specifically, the GPU functional model generates first intermediate interface response data based on the random test stimulus sequence, and the register transfer level model generates second intermediate interface response data based on the random test stimulus sequence.

In this implementation, the second random authentication result may represent an authentication result obtained by comparing the first intermediate interface response data and the second intermediate interface response data.

By adopting the implementation mode, the data difference of the GPU function model and the register transmission level model at the intermediate interface can be found in real time or as early as possible. Compared with the verification method based on pdump test sets, the implementation mode does not need to wait for all the tests to be completed before comparison, so that the verification efficiency and accuracy are remarkably improved. Once the discrepancy is found, the implementation can directly locate the errant module or interface, speeding up the debugging process.

In one possible implementation, the GPU function model comprises a GPU full function model for simulating all functions of the GPU, wherein the GPU full function model is mounted on a top-level verification environment, and a GPU sub function model for simulating functions of partial modules of the GPU, wherein the GPU sub function model is mounted on a sub verification environment, and inputs of the GPU sub function model are from the register transfer level model.

In this implementation, a hierarchical verification environment structure may be employed, and the verification environment may include a top-level verification environment and a sub-verification environment.

The GPU full function model may be located in a top level validation environment, responsible for simulating all functions of the GPU. Based on the GPU full-function model, various complex GPU operations and functional tests can be performed.

Meanwhile, in order to verify specific parts or modules of the GPU more carefully, a GPU sub-function model is also introduced. GPU sub-function models are installed in a sub-verification environment, each of which may be focused on a particular module or function of the simulated GPU, respectively. The GPU sub-function model enables a verifier to conduct targeted testing and verification on different parts of the GPU. Wherein, the input of the GPU sub-function model comes from a register transfer level model (RTL model), thereby ensuring the accuracy and consistency of the input data.

As an example of this implementation, the top-level verification environment and the sub-verification environment may run in parallel, thereby improving verification efficiency. For example, a GPU full-function model may be tested on a large scale, fully in a top-level verification environment, while a particular GPU module or function may be tested in detail, in depth, in a sub-verification environment. The parallel verification method not only quickens the verification speed, but also improves the accuracy and reliability of verification.

As an example of this implementation, the sub-verification model may be a verification environment for Unit Test (UT) or a verification environment for Block Test (BT).

In this implementation, a high degree of flexibility and scalability is provided for GPU system verification through hierarchical and modular designs. Whether a comprehensive GPU functional test is performed or a detailed verification for a specific module or function is performed, can be easily implemented under this framework.

In this implementation, the number of sub-verification environments is flexible and may be one or more. For example, multiple sub-authentication environments may be included, each focusing on authenticating a particular portion or function of the GPU. This design makes the verification process more modular, and each sub-verification environment can be independently run and debugged.

In this implementation, a user (such as a verifier) may turn on or off a sub-verification environment through specific instructions or interface operations according to actual needs. Such control may be based on a variety of factors, such as validation progress, resource allocation, error localization, etc.

For example, during an early stage of GPU development, a verifier may only need to verify a core computing module of a GPU, and may only turn on a sub-verification environment associated with the core computing module. With the development in depth, other sub-verification environments may be turned on gradually as more modules or functions need to be verified.

In the implementation mode, by controlling the switch of the sub-verification environment according to the user instruction, a verification person can flexibly select the sub-verification environment to be operated according to the actual condition and the requirement of the project, so that the function verification of the GPU is more efficiently performed. The flexibility can not only improve the verification efficiency, but also save verification resources and reduce the verification cost. At the same time, since each sub-verification environment is independent, this also makes error localization and problem debugging easier and more efficient.

In this implementation, the constraint checker of the sub-verification environment may be multiplexed to perform constraint checking on the random test stimulus sequence. During the verification process of the GPU system, sub-verification environments, such as a verification environment for unit testing and a verification environment for module testing, may be constructed, each having its own constraint checker for ensuring that the test stimulus sequence meets predetermined rules and conditions.

In this implementation, there is no need to develop a completely new constraint checker for each verification environment, but rather the constraint checker of the existing sub-verification environment is multiplexed. This means that when constraint checking of a randomly generated test stimulus sequence is required, the constraint checker previously developed for unit testing or module testing can be used directly. Multiplexing these constraint checkers can greatly reduce the time and resources required to develop a new constraint checker because they are already validated and used for a particular test scenario.

The implementation simplifies the development process of the global constraint checker and reduces the complexity and cost of verification. By multiplexing existing constraint inspectors, repeated development of the same or similar inspection logic can be avoided, thereby improving verification efficiency. In addition, due to the fact that the verified constraint checker is used, accuracy and reliability of random test excitation sequences are improved, and overall verification quality of the GPU system is further improved.

In addition, in the implementation mode, the constraint checker in the sub-verification environment can be packaged, and complex logic and interfaces of the constraint checker in the sub-verification environment are hidden, so that external calling is simpler and unified. In a multi-layer nested environment, each layer may have its own constraint checker, and encapsulation may ensure that each layer complies with the same interface specification, reducing the complexity of layer-to-layer communication. In addition, packaging may also avoid code redundancy because the logic of the same constraint checker may be reused in multiple places.

The packaged constraint checker may be more easily migrated from one environment to another as long as the new environment meets the interface requirements of the constraint checker. In addition, packaging generally means that the constraint checker is a stand-alone module, independent of the particular system or hardware configuration, which further enhances its portability. Furthermore, encapsulation makes it easier to add new functionality or modify existing functionality on the basis of existing constraint inspectors.

Fig. 4 is another schematic diagram of a GPU system verification method according to an embodiment of the present disclosure. As shown in fig. 4, the verification environment may include a top-level verification environment, where the top-level verification environment may mount a GPU full-function model, and a plurality of sub-verification environments, where the sub-verification environment may mount a GPU sub-function model. The top-level verification environment may include a global constraint checker, and each sub-verification environment may also include a constraint checker, respectively.

In one possible implementation, the GPU may be fully verified based on CDV (coverage driven verification ) methods to ensure that the GPU design operates correctly and without errors in various usage scenarios, thereby avoiding missing potential errors or defects to the maximum extent.

The CDV method has the core idea of improving the sufficiency and accuracy of verification by ensuring that the test coverage (i.e., the degree of coverage of the test on the design space) reaches a preset target. In GPU system validation, the CDV method may focus on various possible inputs, state transitions, functional paths, etc., to ensure that the test can cover every corner of the GPU system design.

In one possible implementation manner, the method further comprises analyzing the interface information of the GPU according to a predefined rule to obtain at least two levels of interface data, and generating a statistical chart corresponding to the interface information of the GPU according to the at least two levels of interface data.

As an example of this implementation, the interface information of the GPU may be parsed by a scripting tool according to predefined rules.

The predefined rules refer to a series of standards or methods formulated according to verification requirements before parsing the GPU interface information. The predefined rules determine how to decompose the interface information into different levels of data. In one example, the predefined rules may parse interface information from different functional modules of the GPU (e.g., vertex shader, pixel shader, rasterizer, etc.), in another example, the predefined rules may parse interface information from data types (e.g., vertex data, pixel data, texture data, etc.), in another example, the predefined rules may parse interface information from time series (e.g., per rendered frame, per draw call, etc.), and so forth.

Interface information may refer to data and control signals transferred in a GPU system when interacting between different modules or between a GPU and other system components. For example, the interface information may include, but is not limited to, vertex data (e.g., vertex position, normal, texture coordinates, etc.), pixel data (e.g., pixel color values, depth values, template values, etc.), control signals (e.g., draw call instructions, interrupt signals, synchronization signals, etc.), state information (e.g., a currently executing stage (e.g., vertex shading stage, pixel shading stage), context switch state, etc.), and the like.

As one example of this implementation, the at least two levels include at least part of a draw call level (DRAW CALL LEVEL), a tile level (TILE LEVEL), a frame level (FRAME LEVEL).

The interface data of the drawing call level may include the number of top points, the number of pixels, etc. processed in each drawing call, the interface data of the tile level may include the number of pixels, etc. processed in each tile, and the interface data of the frame level may include the total number of top points, the total number of pixels, etc. processed in the frame.

In this implementation, the statistical chart may include, but is not limited to, a histogram, bar chart, line graph, pie chart, etc., to visually demonstrate the distribution of the different levels of interface data.

In the related art, in the GPU system verification process, although there is the along-the-path information for auxiliary debugging (debug), the information is generally obscure and difficult to directly interpret and understand, which affects the efficiency of problem location to a great extent. In particular, when faced with large amounts of data text information, verification engineers often need to manually perform complex transformations and parsing to extract valuable specific information therefrom for determining the source and location of the problem. The manual processing process is time-consuming and labor-consuming, is prone to error, and greatly reduces the efficiency of verification work.

In the implementation manner, the interface information of the GPU is analyzed according to the predefined rule to obtain at least two levels of interface data, and the statistical chart corresponding to the interface information of the GPU is generated according to the at least two levels of interface data, so that a user can intuitively know the distribution condition of the interface data, the problem positioning and verification efficiency is accelerated, and meanwhile, the completeness of verification is facilitated.

The GPU system verification method provided by the embodiment of the present disclosure is described below through a specific application scenario.

In this application scenario, the verification environment may include a top-level verification environment and a plurality of sub-verification environments. The top-level verification environment may include, among other things, a register transfer level model, a GPU full-function model, and a global constraint checker. The sub-verification environment may include a GPU sub-functional model and a constraint checker. Any sub-authentication environment controls the switch according to user instructions.

The stimulus generator may be generated based on programming guide information, and a random test stimulus sequence may be generated by the stimulus generator. The random test stimulus sequence may be subjected to constraint checking by a global constraint checker and a constraint checker in a sub-verification environment. The target random test stimulus sequence may be obtained from a random test stimulus sequence that passes the constraint check.

The target random test stimulus sequence may be input synchronously to the GPU full function model and the register transfer level model. Functional simulation results output by the GPU full-functional model in response to the target random test excitation sequence and simulation results output by the register transfer level model in response to the target random test excitation sequence can be obtained. The functional simulation result and the simulation result can be compared to obtain a first random verification result of the GPU system. The first intermediate interface response data generated by the intermediate interface of the GPU full-function model based on the target random test stimulus sequence and the second intermediate interface response data generated by the intermediate interface of the register transfer level model based on the target random test stimulus sequence may be obtained. And comparing the first intermediate interface response data with the second intermediate interface response data to obtain a second random verification result of the GPU system.

It will be appreciated that the above-mentioned method embodiments of the present disclosure may be combined with each other to form a combined embodiment without departing from the principle logic, and are limited to the description of the present disclosure. It will be appreciated by those skilled in the art that in the above-described methods of the embodiments, the particular order of execution of the steps should be determined by their function and possible inherent logic.

In addition, the disclosure further provides a GPU system verification device, an electronic device, a computer readable storage medium, and a computer program product, which can be used to implement any one of the GPU system verification methods provided in the disclosure, and the corresponding technical scheme and technical effect can be referred to the corresponding records of the method section and are not repeated.

Fig. 5 shows a block diagram of a GPU system authentication apparatus provided by an embodiment of the present disclosure. As shown in fig. 5, the GPU system verification device includes:

a first obtaining module 51 for obtaining a target random test excitation sequence;

The input module 52 is configured to input the target random test excitation sequence into a GPU functional model and a register transmission level model, where the GPU functional model is a software model for simulating functions of a GPU, the register transmission level model is a model written based on a hardware description language, and the register transmission level model is used for describing hardware implementation and behavior of the GPU;

a second obtaining module 53, configured to obtain a functional simulation result output by the GPU functional model in response to the target random test excitation sequence, and a simulation result output by the register transfer level model in response to the target random test excitation sequence;

And the first comparison module 54 is configured to compare the functional simulation result with the simulation result to obtain a first random verification result of the GPU system.

the apparatus further comprises:

In one possible implementation of the present invention,

The input module 52 is configured to input the target random test excitation sequence into a GPU functional model and a register transfer level model synchronously;

The first comparison module 54 is configured to compare the functional simulation result with the simulation result in real time, so as to obtain a first random verification result of the GPU system.

In one possible implementation of the present invention,

The apparatus further comprises:

the first obtaining module 51 is configured to obtain a target random test excitation sequence from the random test excitation sequences that pass the constraint check.

Generating an incentive generator based on the programming guide information;

A random test stimulus sequence is generated by the stimulus generator.

In one possible implementation, the apparatus further includes:

In one possible implementation, the checking module is configured to:

In one possible implementation, the GPU functionality model includes:

And

In one possible implementation, the apparatus further includes:

draw call level, tile level, frame level.

In some embodiments, functions or modules included in an apparatus provided by the embodiments of the present disclosure may be used to perform a method described in the foregoing method embodiments, and specific implementation and technical effects of the functions or modules may refer to the descriptions of the foregoing method embodiments, which are not repeated herein for brevity.

The disclosed embodiments also provide a computer readable storage medium having stored thereon computer program instructions which, when executed by a processor, implement the above-described method. Wherein the computer readable storage medium may be a non-volatile computer readable storage medium or may be a volatile computer readable storage medium.

The disclosed embodiments also propose a computer program comprising computer readable code which, when run in an electronic device, causes a processor in the electronic device to carry out the above method.

Embodiments of the present disclosure also provide a computer program product comprising computer readable code, or a non-transitory computer readable storage medium carrying computer readable code, which when run in an electronic device, causes a processor in the electronic device to perform the above method.

The embodiment of the disclosure also provides electronic equipment, which comprises one or more processors and a memory for storing executable instructions, wherein the one or more processors are configured to call the executable instructions stored in the memory to execute the method.

The electronic device may be provided as a terminal, server or other form of device.

Fig. 6 shows a block diagram of an electronic device 1900 provided by an embodiment of the disclosure. For example, electronic device 1900 may be provided as a server or a terminal. Referring to FIG. 6, electronic device 1900 includes a processing component 1922 that further includes one or more processors and memory resources represented by memory 1932 for storing instructions, such as application programs, that can be executed by processing component 1922. The application programs stored in memory 1932 may include one or more modules each corresponding to a set of instructions. Further, processing component 1922 is configured to execute instructions to perform the methods described above.

The electronic device 1900 may also include a power component 1926 configured to perform power management of the electronic device 1900, a wired or wireless network interface 1950 configured to connect the electronic device 1900 to a network, and an input/output interface 1958 (I/O interface). The electronic device 1900 may operate based on an operating system stored in memory 1932, such as the Microsoft Server operating system (Windows Server ^TM), the apple Inc. promoted graphical user interface-based operating system (Mac OS X ^TM), the multi-user, multi-process computer operating system (Unix ^TM), the free and open source Unix-like operating system (Linux ^TM), the open source Unix-like operating system (FreeBSD ^TM), or the like.

In an exemplary embodiment, a non-transitory computer readable storage medium is also provided, such as memory 1932, including computer program instructions executable by processing component 1922 of electronic device 1900 to perform the methods described above.

The present disclosure may be a system, method, and/or computer program product. The computer program product may include a computer readable storage medium having computer readable program instructions embodied thereon for causing a processor to implement aspects of the present disclosure.

The computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical encoding device, punch cards or intra-groove protrusion structures such as those having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media, as used herein, are not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., optical pulses through fiber optic cables), or electrical signals transmitted through wires.

The computer readable program instructions described herein may be downloaded from a computer readable storage medium to a respective computing/processing device or to an external computer or external storage device over a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network interface card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium in the respective computing/processing device.

The computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as SMALLTALK, C ++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present disclosure are implemented by personalizing electronic circuitry, such as programmable logic circuitry, field Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), with state information of computer readable program instructions, which can execute the computer readable program instructions.

Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable medium having the instructions stored therein includes an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The computer program product may be realized in particular by means of hardware, software or a combination thereof. In an alternative embodiment, the computer program product is embodied as a computer storage medium, and in another alternative embodiment, the computer program product is embodied as a software product, such as a software development kit (Software Development Kit, SDK), or the like.

The foregoing description of various embodiments is intended to highlight differences between the various embodiments, which may be the same or similar to each other by reference, and is not repeated herein for the sake of brevity.

If the technical scheme of the embodiment of the disclosure relates to personal information, the product applying the technical scheme of the embodiment of the disclosure clearly informs the personal information processing rule and obtains personal independent consent before processing the personal information. If the technical solution of the embodiment of the present disclosure relates to sensitive personal information, the product applying the technical solution of the embodiment of the present disclosure obtains individual consent before processing the sensitive personal information, and simultaneously meets the requirement of "explicit consent". For example, a clear and obvious mark is set at a personal information acquisition device such as a camera to inform that the personal information acquisition range is entered, personal information is acquired, if the personal voluntarily enters the acquisition range, the personal information is considered as consent to acquire the personal information, or if a clear mark/information is used on a personal information processing device to inform that the personal information processing rule is used, personal authorization is obtained through popup information or a mode of requesting the personal information to upload the personal information by the personal, wherein the personal information processing rule can comprise information such as a personal information processor, a personal information processing purpose, a processing mode, a processed personal information type and the like.

The foregoing description of the embodiments of the present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the improvement of technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A GPU system verification method, comprising:

Obtaining a target random test stimulus sequence;

Inputting the target random test stimulus sequence into a GPU functional model and a register transfer level model respectively; wherein the GPU functional model is a software model for simulating the function of a GPU; the register transfer level model is a model written based on a hardware description language, and the register transfer level model is used to describe the hardware implementation and behavior of the GPU;

Obtaining a functional simulation result output by the GPU functional model in response to the target random test stimulus sequence, and a simulation result output by the register transfer level model in response to the target random test stimulus sequence;

The functional simulation result is compared with the simulation result to obtain a first random verification result of the GPU system.

2. The method according to claim 1, wherein the model structure and interface definition of the GPU functional model are consistent with those of the register transfer level model;

The method further comprises:

Obtaining first intermediate interface response data generated by the intermediate interface of the GPU functional model based on the target random test stimulus sequence, and second intermediate interface response data generated by the intermediate interface of the register transfer level model based on the target random test stimulus sequence;

The first intermediate interface response data and the second intermediate interface response data are compared to obtain a second random verification result of the GPU system.

3. The method according to claim 1, characterized in that

The step of inputting the target random test stimulus sequence into the GPU functional model and the register transfer level model respectively comprises: synchronously inputting the target random test stimulus sequence into the GPU functional model and the register transfer level model;

The comparing the functional simulation result with the simulation result to obtain the first random verification result of the GPU system includes: comparing the functional simulation result with the simulation result in real time to obtain the first random verification result of the GPU system.

4. The method according to any one of claims 1 to 3, characterized in that

Before obtaining the target random test stimulus sequence, the method further includes: generating a random test stimulus sequence; performing a constraint check on the random test stimulus sequence;

The obtaining of the target random test stimulus sequence includes: obtaining the target random test stimulus sequence from the random test stimulus sequence that passes the constraint check.

5. The method according to claim 4, characterized in that the generating of the random test stimulus sequence comprises:

generating a stimulus generator based on the programming guide information;

A random test stimulus sequence is generated by the stimulus generator.

6. The method according to claim 4, characterized in that the generating of the random test stimulus sequence comprises:

Receiving user input parameters through a graphical interface; wherein the user input parameters include at least some of the following types: frame size, tile size, and core size;

7. The method according to claim 6, characterized in that the method further comprises:

In response to a user selecting a vertex in the graphic interface, a graph formed by the vertex is displayed in the graphic interface.

8. The method according to claim 4, characterized in that the performing constraint checking on the random test stimulus sequence comprises:

Based on a global constraint set, a constraint check is performed on the random test stimulus sequence, wherein the global constraint set is generated based on constraint conditions of multiple levels and constraint conditions between the multiple levels.

9. The method according to any one of claims 1 to 3, wherein the GPU function model comprises:

A GPU full-function model for simulating all functions of the GPU, wherein the GPU full-function model is mounted in a top-level verification environment;

as well as,

A GPU sub-function model for simulating the functions of some modules of the GPU, wherein the GPU sub-function model is mounted in a sub-verification environment, and the input of the GPU sub-function model comes from the register transfer level model.

10. The method according to claim 9, characterized in that the method further comprises:

The constraint checker of the sub-verification environment is reused to perform constraint checking on the random test stimulus sequence.

11. The method according to claim 9 is characterized in that the number of the sub-authentication environments is at least one, and any sub-authentication environment controls the switch according to user instructions.

12. The method according to any one of claims 1 to 3, characterized in that the method further comprises:

Parsing the interface information of the GPU according to predefined rules to obtain at least two levels of interface data;

A statistical chart corresponding to the interface information of the GPU is generated according to the at least two levels of interface data.

13. The method according to claim 10, characterized in that the at least two levels include at least part of the following:

Draw call level, tile level, frame level.

14. A GPU system verification device, comprising:

A first acquisition module is used to obtain a target random test stimulus sequence;

An input module, used to input the target random test stimulus sequence into a GPU functional model and a register transfer level model respectively; wherein the GPU functional model is a software model for simulating the function of a GPU; the register transfer level model is a model written based on a hardware description language, and the register transfer level model is used to describe the hardware implementation and behavior of the GPU;

A second obtaining module is used to obtain a functional simulation result output by the GPU functional model in response to the target random test stimulus sequence, and a simulation result output by the register transfer level model in response to the target random test stimulus sequence;

The first comparison module is used to compare the functional simulation result with the simulation result to obtain a first random verification result of the GPU system.

15. An electronic device, comprising:

one or more processors;

a memory for storing executable instructions;

The one or more processors are configured to call the executable instructions stored in the memory to execute the method described in any one of claims 1 to 13.

16. A computer-readable storage medium having computer program instructions stored thereon, wherein the computer program instructions implement the method according to any one of claims 1 to 13 when executed by a processor.

17. A computer program product, comprising a computer-readable code, or a non-volatile computer-readable storage medium carrying a computer-readable code, characterized in that when the computer-readable code is executed in an electronic device, a processor in the electronic device executes the method described in any one of claims 1 to 13.