Gpu chip reliability verification method, electronic device, and medium

Abstract

The present application relates to the technical field of chip verification, and particularly relates to a GPU chip reliability verification method, an electronic device and a medium, comprising the following steps: S1, constructing a candidate queue and a candidate data packet; S2, constructing a to-be-executed stage; S3, dividing the nth to-be-executed stage into multiple links, and setting link identification information in each A m n S4, in the execution process, if there is a candidate queue with an abnormal injection attribute in A m n S5 is executed; S5, when the link starts to execute, it is judged whether there is a candidate queue with the abnormal injection attribute, if yes, S6 is executed, otherwise, S7 is executed; S6, when the data corresponding to the queue of the candidate queue appears in the corresponding GPU core of the downstream, the candidate queue is destroyed, and S4 is returned; S7, the candidate queue is reconstructed, and the queue management attribute of the candidate queue is set as a non-abnormal injection attribute, and S4 is returned. The present application improves the GPU chip reliability verification efficiency.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and in particular to a GPU chip reliability verification method, electronic device, and medium. Background Technology

[0002] In the front-end verification of Graphics Processing Unit (GPU) chips, test cases are typically constructed using software-driven application programming interfaces (APIs). However, these APIs are too low-level, requiring front-end verification personnel to understand the meaning and purpose of each API, incurring a significant learning cost. Furthermore, these APIs have limited functionality, making it difficult to automate GPU chip reliability verification, resulting in low efficiency. Therefore, improving the efficiency of GPU chip reliability verification is a pressing technical problem. Summary of the Invention

[0003] The purpose of this invention is to provide a GPU chip reliability verification method, electronic device, and medium, thereby improving the efficiency of GPU chip reliability verification.

[0004] According to a first aspect of the present invention, a method for verifying the reliability of a GPU chip is provided, comprising: Step S1: Construct candidate queues and candidate data packets, where the candidate queues include queue management attributes; Step S2: Construct N execution stages, each stage including a corresponding process, each process including a process name and at least one queue packet group consisting of a candidate queue and a candidate data packet. The nth execution stage includes M queue packet groups {A1}. n A2 n ,...,A m n ,...,A M n}, A m n This is the m-th queue to be processed in the n-th stage to be executed. The value of m ranges from 1 to M, and the value of n ranges from 1 to N. Each stage to be executed is independent of the others. Step S3: Divide the nth stage to be executed into Y n Each step is executed sequentially, in each A m n Setting up step identification information B m n B m n Includes Am n Identification of the steps to be performed; Step S4: The nth stage to be executed executes each step sequentially, each A... m n Only in B m n A set in m Execute in the required stages until the nth stage is completed. During execution, if A... m n If a candidate queue is configured with the exception injection attribute as its queue management attribute, then proceed to step S5. Step S5: When the process of executing the candidate queue with the queue management attribute of exception injection attribute begins, determine whether the candidate queue exists. If it exists, execute step S6; otherwise, execute step S7. Step S6: Monitor the downstream GPU cores in real time. If the data corresponding to the candidate queue appears in the downstream GPU cores, destroy the candidate queue and return to step S4. Step S7: Reconstruct the candidate queue and set its queue management attribute to a non-abnormal injection attribute, then return to step S4.

[0005] According to a second aspect of the present invention, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform the method described in the first aspect of the present invention.

[0006] According to a third aspect of the present invention, a computer-readable storage medium is provided, storing computer-executable instructions for performing the method described in the first aspect of the present invention.

[0007] Compared with existing technologies, this invention has significant advantages and beneficial effects. Through the above technical solution, the GPU chip reliability verification method, electronic device, and medium provided by this invention achieve considerable technological advancement and practicality, and have broad industrial application value. It has at least the following beneficial effects: This invention sets an exception injection attribute in the candidate queue, thereby automatically simulating the abnormal scenario of destroying the candidate queue during the execution phase, and rebuilding the candidate queue when it is used again after destruction, thus realizing automated dynamic self-healing scheduling of the candidate queue and improving the efficiency of GPU chip reliability verification. Attached Figure Description

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

[0009] Figure 1 This is a flowchart of a GPU chip reliability verification method provided in an embodiment of the present invention. Detailed Implementation

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

[0011] This invention provides a method for verifying the reliability of a GPU chip, such as... Figure 1 As shown, it includes: Step S1: Construct candidate queues and candidate packets. The candidate queues include queue management attributes.

[0012] Step S2: Construct N phases to be executed. Each phase includes a corresponding process. Each process includes a process name and at least one queue packet group consisting of a candidate queue and a candidate data packet. The nth phase includes M queue packet groups {A1}. n A2 n ,...,A m n ,...,A M n}, A m n Let m be the m-th queue to be processed in the n-th execution stage, where m ranges from 1 to M and n ranges from 1 to N. Each execution stage is independent of the others. N is the total number of execution stages constructed in step S2, and M is the total number of queues to be processed in the n-th execution stage.

[0013] It should be noted that there is a one-to-one correspondence between the execution stage and the process, and there is also a one-to-one correspondence between the candidate queues and candidate data packets in the pending queue packet group. The execution stage and the pending queue packet group can have a one-to-one or one-to-many correspondence.

[0014] Step S3: Divide the nth stage to be executed into Yn Each stage is executed sequentially, in each A m n Setting up step identification information B m n B m n Includes A m n The steps that need to be performed are identified.

[0015] Specifically, one-hot codes can be used in B. m n Configuration A m n The execution process can be divided into several stages, for example, the nth stage to be executed is divided into 4 stages, A m n If it needs to be executed in stages 1 and 3, then B... m n The configuration is 0101. For example, A. m n If it needs to be executed in the second stage, then B m n The configuration is set to 0010. During execution, A... m n Only in B m n A set in m It executes within the required stages, achieving multi-level business nesting.

[0016] Step S4: The nth stage to be executed executes each step sequentially, each A... m n Only in B m n A set in m Execute in the required stages until the nth stage is completed. During execution, if A... m n If a candidate queue is configured with the exception injection attribute as its queue management attribute, then step S5 is executed.

[0017] Step S5: When the process of executing the candidate queue with the queue management attribute of exception injection attribute begins, determine whether the candidate queue exists. If it exists, execute step S6; otherwise, execute step S7.

[0018] Step S6: Monitor the downstream GPU cores in real time. If the data corresponding to the candidate queue appears in the downstream GPU cores, destroy the candidate queue and return to step S4.

[0019] It should be noted that when the corresponding data for the candidate queue appears in the downstream GPU core, it indicates that the candidate queue has started processing the corresponding business. Only then is destroying the candidate queue for abnormal insertion meaningful. Furthermore, to further improve reliability, after destroying the candidate queue in step S6, it is necessary to further check whether the candidate queue has been completely destroyed. If so, return to step S4 to continue to the next step; otherwise, an error should be reported.

[0020] Step S7: Reconstruct the candidate queue and set its queue management attribute to a non-abnormal injection attribute, then return to step S4.

[0021] It should be noted that by setting the queue management attribute to a candidate queue for exception injection, exception injection can be performed. The exception simulation is achieved by destroying the corresponding candidate queue only after ensuring that the data corresponding to that queue appears in the downstream GPU core. Furthermore, after destroying the candidate queue, it may be reused in subsequent stages. In this case, the candidate queue is rebuilt in step S7, achieving dynamic self-healing.

[0022] As one embodiment, the non-abnormal injection attributes include a queue destruction attribute and a queue non-destruction attribute. If the candidate queue is executed only in one stage, the queue management attribute is configured as the queue destruction attribute; if the candidate queue is executed in multiple stages, the queue management attribute is configured as the queue non-destruction attribute. In step S4, during execution, if A... m n If a queue management attribute is set to "destroy queue", then the queue corresponding to the candidate queue, A, is... m n China B m n When the corresponding step is completed, the candidate queue is destroyed. It should be noted that in most cases, the candidate queue is only executed in one step, so the default value of the queue management attribute can be configured to destroy the queue attribute.

[0023] As one embodiment, in step S4, when all steps in the nth pending execution stage are completed, all candidate queues in the nth pending execution stage are destroyed. It should be noted that when all steps in the nth pending execution stage are completed, the candidate queues are no longer destroyed based on queue management attribute configuration; instead, all candidate queues in the nth pending execution stage are directly destroyed to release resources.

[0024] As one embodiment, step S1 includes: Step S11: Construct candidate test cases, candidate queues, candidate data packets, candidate computing kernels, and candidate buffers, wherein the candidate data packets include at least one candidate computing kernel, and the candidate computing kernels include at least one candidate buffer.

[0025] It should be noted that including at least one candidate computing kernel in the candidate data packet specifically means adding the name of the candidate computing kernel to the candidate data packet and invoking the corresponding candidate computing kernel. Including at least one candidate cache in the candidate computing kernel specifically means adding the name of the candidate cache to the computing kernel and invoking the corresponding candidate cache.

[0026] As one embodiment, the candidate test cases include a test case name, an inherited test case name, GPU global static parameters, and process information. The process information includes a process name and process variables. The test case name and process name are mandatory configuration information. If non-mandatory configuration parameters are omitted, random values ​​are generated based on the corresponding preset random range for configuration. Mandatory configuration information refers to information that must be configured and cannot be omitted, while non-mandatory configuration information refers to information that can be left unconfigured and can be left at the default value. It is understood that the preset random range is a random range that meets the GPU verification requirements. It should be noted that if an inherited test case name is configured in the candidate test case, the configuration information of the corresponding test case is inherited first, and then further configuration is performed. If it does not exist, the candidate test case is configured directly. The GPU global static parameters may specifically include virtual function enable information, virtual machine enable information, and the number of virtual functions to be created. The GPU global static parameters may include one or more process information, and the process variables include the process name, the bound physical GPU device identifier, the bound virtual function identifier, and the bound process identifier.

[0027] As one embodiment, the candidate queue includes a queue name, a queue identifier, and queue configuration information, wherein the queue name is mandatory configuration information; if non-mandatory configuration information parameters are omitted, random values ​​are generated based on the corresponding preset random range for configuration. The queue configuration information includes one or more of the following: queue scheduling priority, queue working mode, ring buffer read pointer address, ring buffer write pointer address, write pointer polling address, and write pointer mode control register.

[0028] As one embodiment, the candidate data packet includes a data packet name, header information, and payload information. The data packet name is mandatory; if non-mandatory configuration parameters are omitted, random values ​​are generated based on a corresponding preset random range for configuration. The header information specifically includes one or more of the following: packet type identifier, barrier control information, fencing scope, dimension information, completion signal event identifier write enable, completion signal atomic operation disable, skip execution information, completion signal interrupt enable, and completion signal timestamp enable. The payload information includes one or more of the following: computation unit address mask, private memory size, private memory base address, and completion signal enable.

[0029] As one embodiment, the candidate computing kernel, in addition to the candidate cache, also includes a computing kernel name, file type, and kernel configuration. The kernel name and file type are mandatory configuration information. The file type can be configured as a binary file, a Python file, or a CPP file, supporting multiple file types, but all can ultimately be compiled into the corresponding binary file. If non-mandatory configuration parameters are omitted, random values ​​are generated based on the corresponding preset random range for configuration. Kernel configuration includes one or more of the following: computing program resource configuration, enabling private segment buffer registers, enabling scheduler pointer registers, enabling queue pointer registers, enabling kernel parameter segment pointer registers, enabling scheduler flag registers, enabling flattened private memory initialization registers, enabling private segment size registers, enabling out-of-order scheduling, enabling grid dimension registers, enabling block dimension registers, and computing resource limit configuration. As one embodiment, the candidate cache includes a cache name, cache identifier, scope, cache size, cache type, and initialization data. The cache name is a mandatory configuration information, and the scope is configured as either global or the calling instance type. When the scope is configured as global, the cache size is a mandatory configuration information, and the cache identifier is set to automatically increment by default. When the scope is configured as the calling instance type, the cache type is a non-mandatory configuration information, the cache identifier is set to be automatically mapped and generated when the instance is called, and the cache size is dynamically determined by the kernel and data packet creation of the corresponding instance by default. Other non-mandatory configuration parameters are configured with random values ​​generated based on the corresponding preset random range by default. Specifically, the cache type can be set to a 64-bit unsigned integer type (u64), a 64-bit signed integer type (int64), a 32-bit unsigned integer type (u32), a 32-bit signed integer type (int32), a 16-bit unsigned integer type (u16), a 16-bit signed integer type (int16), an 8-bit unsigned integer type (u8), or an 8-bit signed integer type (int8). It should be noted that other non-essential configuration parameters are configured with random values ​​generated based on the corresponding preset random range when defaulted, which increases the randomness of the verification.

[0030] As one embodiment, step S4 includes: Step S41: Select a target test case from the candidate test cases and add the constructed execution phase to the target test case.

[0031] Step S42: Parse the target test case to generate the corresponding target C++ test case.

[0032] Specifically, candidate test cases, candidate queues, candidate data packets, candidate computation kernels, candidate caches, and execution stages can be in JSON format. Since the parameter information and relationships between parameters are clearly defined in these candidate test cases, candidate queues, candidate data packets, candidate computation kernels, candidate caches, and execution stages, the target C++ test cases can be generated by parsing the JSON-formatted candidate test cases, candidate queues, candidate data packets, candidate computation kernels, candidate caches, and execution stages and then converting them into their corresponding C++ forms.

[0033] Step S43: Input the target C++ test case into the GPU chip design for verification. During the verification process, each step is executed sequentially in the nth execution stage.

[0034] This invention enables the automatic simulation of abnormal scenarios involving the destruction of the candidate queue during the execution phase by setting an exception injection attribute in the candidate queue. Furthermore, the candidate queue is rebuilt when it is used again after destruction, thereby achieving automated dynamic self-healing scheduling of the candidate queue and improving the efficiency of GPU chip reliability verification.

[0035] It should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of these steps can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the steps can be rearranged. A process can be terminated when its operation is complete, but it may also have additional steps not included in the figures. A process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0036] This invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform the method described in this invention.

[0037] This invention also provides a computer-readable storage medium storing computer-executable instructions for performing the methods described in this invention.

[0038] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for verifying the reliability of a GPU chip, characterized in that, include: Step S1: Construct candidate queues and candidate data packets, where the candidate queues include queue management attributes; Step S2: Construct N execution stages, each stage including a corresponding process, each process including a process name and at least one queue packet group consisting of a candidate queue and a candidate data packet. The nth execution stage includes M queue packet groups {A1}. n A2 n ,...,A m n ,...,A M n }, A m n This is the m-th queue to be processed in the n-th stage to be executed. The value of m ranges from 1 to M, and the value of n ranges from 1 to N. Each stage to be executed is independent of the others. Step S3: Divide the nth stage to be executed into Y n Each step is executed sequentially, in each A m n Setting up step identification information B m n B m n Includes A m n Identification of the steps to be performed; Step S4: The nth stage to be executed executes each step sequentially, each A... m n Only in B m n A set in m Execute in the required stages until the nth stage is completed. During execution, if A... m n If a candidate queue is configured with the exception injection attribute as its queue management attribute, then proceed to step S5. Step S5: When the process of executing the candidate queue with the queue management attribute of exception injection attribute begins, determine whether the candidate queue exists. If it exists, execute step S6; otherwise, execute step S7. Step S6: Monitor the downstream GPU cores in real time. If the data corresponding to the candidate queue appears in the downstream GPU cores, destroy the candidate queue and return to step S4. Step S7: Reconstruct the candidate queue and set its queue management attribute to a non-abnormal injection attribute, then return to step S4.

2. The method according to claim 1, characterized in that, Non-abnormal injection attributes include the queue destruction attribute and the queue non-destruction attribute. If the candidate queue is executed only in one stage, the queue management attribute is configured as the queue destruction attribute; if the candidate queue is executed in multiple stages, the queue management attribute is configured as the queue non-destruction attribute. In step S4, during execution, if A... m n If a queue management attribute is set to "destroy queue", then the queue corresponding to the candidate queue, A, is... m n China B m n Once the corresponding step is completed, the candidate queue is destroyed.

3. The method according to claim 1 or 2, characterized in that, In step S4, when all steps in the nth stage to be executed are completed, all candidate queues in the nth stage to be executed are destroyed.

4. The method according to claim 1, characterized in that, Step S1 includes: Step S11: Construct candidate test cases, candidate queues, candidate data packets, candidate computing kernels, and candidate caches, wherein the candidate data packets include at least one candidate computing kernel, and the candidate computing kernels include at least one candidate cache; The candidate test cases include test case name, inherited test case name, GPU global static parameters and process information. The process information includes process name and process variables. The test case name and process name are required configuration information. The candidate queue includes a queue name, a queue identifier, and queue configuration information, wherein the queue name is mandatory configuration information; The candidate data packet includes a data packet name, header information, and payload information, wherein the data packet name is a required configuration information; The candidate computing kernel also includes a computing kernel name, file type, and kernel configuration. The kernel name and file type are mandatory configuration information, and the file type includes binary files, Python files, and CPP files. The candidate cache includes cache name, cache identifier, scope, cache size, cache type, and initialization data. The scope includes global type and calling instance type. The cache name is a required configuration information. When the scope is set to global type, the cache type is a required configuration information. If non-essential configuration parameters are not configured, random values ​​will be generated based on the corresponding preset random range during the initialization phase for configuration.

5. The method according to claim 4, characterized in that, Candidate test cases, candidate queues, candidate data packets, candidate computing kernels, candidate caches, and stages to be executed are all in JSON format.

6. The method according to claim 4, characterized in that, Step S4 includes: Step S41: Select a target test case from the candidate test cases and add the constructed execution phase to the target test case; Step S42: Parse the target test case to generate the corresponding target C++ test case; Step S43: Input the target C++ test case into the GPU chip design for verification. During the verification process, each step is executed sequentially in the nth execution stage.

7. An electronic device, characterized in that, include: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that are executed by the at least one processor, the instructions being configured to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, The device stores computer-executable instructions for performing the method as described in any one of claims 1-6.

Images