General-purpose computing unit verification method and device, electronic equipment and storage medium

Abstract

This application provides a method, apparatus, electronic device, and storage medium for verifying general-purpose computing units, relating to the field of chip design verification technology. The method includes: instantiating at least one operator configuration stimulus; generating execution stimulus and description stimulus corresponding to each operator configuration stimulus; generating request interface stimulus driving the general-purpose computing unit interface based on the execution stimulus, and generating return interface stimulus driving the general-purpose computing unit interface based on the description stimulus; verifying the general-purpose computing unit by generating request interface transactions based on the request interface stimulus and return interface transactions based on the return interface stimulus. The method and apparatus provided in this application, through a layered and decoupled stimulus generation and management method, achieve hierarchical decomposition and configuration of verification stimulus from top-level operator definitions to bottom-level interface transactions, improving the flexibility, randomness, and completeness of general-purpose computing unit verification, and effectively improving the efficiency of general-purpose computing unit verification.

Description

Technical Field

[0001] This application relates to the field of chip design verification technology, and in particular to a general computing unit verification method, apparatus, electronic device and storage medium. Background Technology

[0002] The General Computing Unit (GCU) is a key module in the front-end design of Application-Specific Integrated Circuit (ASIC). Its main function is to provide the necessary general computing and flexible control capabilities for highly customized ASIC chips.

[0003] The relevant technologies typically involve writing targeted test cases based on the verification scenario, and then generating stimuli directly after static configuration to verify general computing units. This method cannot adapt to the verification needs of different verification scenarios, has poor flexibility and completeness, and low verification efficiency.

[0004] Therefore, improving the flexibility and completeness of verification for general-purpose computing units and increasing verification efficiency have become urgent technical problems for the industry. Summary of the Invention

[0005] This application provides a general computing unit verification method, apparatus, electronic device, and storage medium to address the technical problem of how to improve the flexibility and completeness of general computing unit verification and increase verification efficiency.

[0006] This application provides a general computing unit verification method, including:

[0007] Based on the number of operators corresponding to the current verification process, instantiate at least one operator and configure the incentive.

[0008] Based on preset parameters and / or randomized parameters, execution incentives and description incentives corresponding to the configuration incentives of each operator are generated; the execution incentives are used to define the execution flow of the operator, and the description incentives are used to define the hardware resources required by the operator.

[0009] The execution incentive generates a request interface incentive to drive the general computing unit interface, and the description incentive generates a return interface incentive to drive the general computing unit interface.

[0010] The general computing unit is verified based on the request interface transaction generated by the request interface incentive and the return interface transaction generated by the return interface incentive.

[0011] In some embodiments, the execution stimulus includes start information for identifying the start of operator execution, at least one thread group task for defining operator execution tasks, and end information for identifying the end of operator execution.

[0012] In some embodiments, the descriptive stimulus includes configuration information for various hardware resources required to define the operator.

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

[0014] Obtain the execution status of each operator in the general computing unit and the hardware resource impact parameters of each operator;

[0015] Based on the execution status of each operator and the hardware resource impact parameters of each operator, it is determined whether there is a hardware resource conflict between the current operator and other operators, so as to determine whether to execute the current operator.

[0016] In some embodiments, determining whether there is a hardware resource conflict between the current operator and other operators based on the execution state of each operator and the hardware resource impact parameters of each operator, in order to determine whether to execute the current operator, includes:

[0017] If it is determined, based on the execution status of each operator, that there is no operator currently being executed, then the current operator is executed;

[0018] If it is determined that there is a target operator being executed based on the execution status of each operator, the execution number of the current operator is compared with the execution number of the target operator;

[0019] If the execution number of the current operator is the same as the execution number of any target operator, it is determined that there is a hardware resource conflict between the current operator and any target operator, and the current operator is executed after the execution of any target operator is completed.

[0020] If the execution number of the current operator is different from the execution numbers of each target operator, the hardware resource impact parameters of the current operator are compared with the hardware resource impact parameters of each target operator.

[0021] If the hardware resource impact parameters of the current operator are partially the same as those of any target operator, it is determined that there is a hardware resource conflict between the current operator and any target operator, and the current operator is executed after the target operator has finished executing.

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

[0023] Configure the first delay parameter, the second delay parameter, the third delay parameter, and the fourth delay parameter;

[0024] Wherein, the first delay parameter is used to determine the initialization delay of the first execution stimulus; the second delay parameter is used to determine the initialization delay of the first description stimulus; the third delay parameter is used to determine the delay between execution stimuli; and the fourth delay parameter is used to determine the delay between description stimuli.

[0025] In some embodiments, the preset parameters are determined based on command-line parameters input by the user, or based on the reproduction requirements of a specific application scenario.

[0026] This application provides a general-purpose computing unit verification device, comprising:

[0027] The operator configuration incentive instantiation module is used to instantiate at least one operator configuration incentive based on the number of operators corresponding to the current verification process.

[0028] The execution incentive and description incentive instantiation module is used to generate execution incentives and description incentives corresponding to each operator configuration incentive based on preset parameters and / or randomized parameters; the execution incentive is used to define the execution flow of the operator, and the description incentive is used to define the hardware resources required by the operator;

[0029] The interface incentive instantiation module is used to generate request interface incentives for driving the general computing unit interface based on the execution incentives, and to generate return interface incentives for driving the general computing unit interface based on the description incentives.

[0030] The verification module is used to verify the general computing unit based on the request interface transaction generated by the request interface incentive and the return interface transaction generated by the return interface incentive.

[0031] This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the general computing unit verification method.

[0032] This application provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the general computing unit verification method described above.

[0033] The general computing unit verification method, apparatus, electronic device, and storage medium provided in this application instantiate operator configuration incentives according to the number of operators corresponding to the current verification process, instantiate execution incentives and description incentives according to the operator configuration incentives, and finally determine request interface incentives and return interface incentives. Through a layered and decoupled incentive generation and management method, the verification incentives are decomposed and configured step by step from the top-level operator definition to the bottom-level interface transactions, which improves the flexibility, randomness, and completeness of general computing unit verification and effectively improves the efficiency of general computing unit verification. Attached Figure Description

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0036] Figure 1 This is a flowchart illustrating the general computing unit verification method provided in this application.

[0037] Figure 2 This is a schematic diagram of the incentive configuration structure provided in this application.

[0038] Figure 3 This is a schematic diagram of the data flow for the multi-layered stimulus provided in this application.

[0039] Figure 4 This is a schematic diagram of the multi-operator parallel execution management method provided in this application.

[0040] Figure 5 This is a schematic diagram of delay management for a general computing unit provided in this application.

[0041] Figure 6 This is a schematic diagram of the structure of the general computing unit verification device provided in this application.

[0042] Figure 7 This is a schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0043] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0044] It should be noted that the terms "first," "second," etc., used in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps, units, or modules is not necessarily limited to those explicitly listed, but may include other steps, units, or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0045] When verifying general-purpose computing units, related technologies typically involve hardware developers constructing direct stimuli based on the verification scenario. This approach suffers from poor randomness, low verification efficiency, and an inability to adapt to the verification needs of different scenarios, resulting in poor completeness. Furthermore, the large number of test cases makes maintenance difficult when specifications change or projects iterate. Directedly constructed stimuli are usually static, offering limited flexibility and scalability.

[0046] In order to address the shortcomings of related technologies, Figure 1 This is a flowchart illustrating the general computing unit verification method provided in this application, as shown below. Figure 1 As shown, the method includes steps 110, 120, 130 and 140.

[0047] Step 110: Based on the number of operators corresponding to the current verification process, instantiate at least one operator and configure the stimulus.

[0048] Specifically, the execution subject of the general computing unit verification method provided in this application embodiment is a general computing unit verification device. This device can be implemented by software, such as a general computing unit verification program; or it can be a device that executes the general computing unit verification method, such as a mobile terminal, tablet computer, desktop computer, or server.

[0049] The current verification process can be pre-designed or determined based on actual needs. Verification content may include verifying that the general computing unit can correctly perform general operations, verifying the consistency between the calculation results and the reference results under different precision modes, and verifying the stability of the general computing unit under long-term or large-scale datasets.

[0050] In this application, a verification context represents a complete, independent functional unit or computational task that the general-purpose computing unit needs to execute. It can be a complete set of instructions executed by the general-purpose computing unit, which can be understood as an operator.

[0051] Stimulus refers to test signals or test data used to verify general-purpose computing units. The stimulus base class (basesequence, base-seq) is usually implemented as an abstract class or interface. It defines a set of general test interfaces and methods, while specific test stimuli are created by inheriting from or implementing this base class. This allows for flexible use and extension of stimuli in different test scenarios and improves code maintainability and reusability.

[0052] The number of verification contents (context_num) in the current verification process can be configured in the incentive base class. This number represents the number of verification contents that the general computing unit needs to run in the current verification process, i.e., the number of operators that the general computing unit needs to execute in the current verification process.

[0053] Operator configuration stimulus (context configure sequence, context_cfg_seq) refers to the stimulus that encapsulates all the configuration information and behavioral logic required to complete an operator verification.

[0054] Based on the number of operators set in the incentive base class, one or more operator configuration incentives corresponding to that number of operators can be instantiated. The incentive base class also passes relevant configurable parameters to each operator configuration incentive.

[0055] If users need to perform targeted configuration of each field segment in the interface stimulus of a general computing unit, this must be done simultaneously with the operator instantiation and stimulus configuration. A field segment is a specific part of an instruction used to represent information such as opcodes and register addresses. An instruction typically consists of multiple field segments, each responsible for conveying different information. Each field segment can have different values. Targeted configuration of field segments refers to configuring the value range of the field segment and the value constraints between field segments.

[0056] Step 120: Based on preset parameters and / or randomized parameters, generate execution incentives and description incentives corresponding to the configuration incentives of each operator; execution incentives are used to define the execution flow of the operator, and description incentives are used to define the hardware resources required by the operator.

[0057] Specifically, preset parameters refer to user-defined configuration parameters or specific configuration parameters. For example, users typically define their own configuration parameters when reproducing known error scenarios or conducting specific targeted tests.

[0058] Randomization parameters refer to configuration parameters that are automatically generated randomly but conform to design specifications within a preset constraint range (such as project specification constraints) using the randomization methods provided by the SystemVerilog language.

[0059] In the embodiments of this application, within each operator configuration incentive, the information related to the execution operator can be decomposed into two independent incentives based on preset parameters and / or randomization parameters, namely execution incentives and description incentives.

[0060] The execution stimulus (thread_group sequence, tg_seq) is the stimulus that defines the execution flow of the operator, focusing on the execution order and timing of tasks.

[0061] The descriptor sequence (desc_seq) is the stimulus that defines the hardware resources required for the operator, focusing on all the hardware resources required for task execution.

[0062] By adopting the above methods, the flexibility of general computing unit verification is improved, enabling verification engineers to independently and arbitrarily combine execution timing and resource configurations, thereby constructing complex cross-scenarios and stress scenarios that are difficult to cover by traditional methods.

[0063] Step 130: Generate request interface incentives for driving the general computing unit interface based on execution incentives, and generate return interface incentives for driving the general computing unit interface based on description incentives.

[0064] Specifically, interface stimuli can be used to directly drive the interfaces of general-purpose computing units. Execution stimuli and description stimuli can generate and instantiate request interface stimuli and return interface stimuli based on configuration parameters and project specification constraints.

[0065] The request sequence for GCU (gcu_req_seq) is used to convert the execution flow of the operators defined in the execution sequence into command information that can be recognized by the general computing unit interface.

[0066] The return sequence for GCU (gcu_rtn_seq) is used to convert the hardware resource requirements of the operators defined in the description sequence into descriptive information that can be recognized by the general computing unit interface.

[0067] Step 140: Verify the general computing unit based on the request interface transaction generated by the request interface incentive and the return interface transaction generated by the return interface incentive.

[0068] Specifically, an interface transaction refers to the specific data packet that is ultimately sent to the general computing unit interface during the verification process.

[0069] A request transaction for GCU (gcu_req_transaction) is a specific data packet generated based on the request interface stimulus, representing the input from the upstream module to the general computing unit in the verification environment.

[0070] The return transaction for GCU (gcu_rtn_transaction) is a specific data packet generated based on the return interface stimulus, representing the input of the downstream module to the general computing unit in the verification environment.

[0071] The verification process for a general-purpose computing unit (GPCU) typically involves the following steps: The driver in the verification platform executes request and return interface stimuli, which generate a series of request and return interface transactions. The driver then converts these transactions into signal level changes, driving them to the corresponding pins of the GPCU. Simultaneously, the monitor and scoreboard in the verification platform acquire the GPCU's output and compare it with the expected results. By sending these interface transactions and checking the GPCU's responses, a comprehensive verification of the GPCU's functionality is ultimately completed.

[0072] The general computing unit verification method provided in this application instantiates operator configuration incentives based on the number of operators corresponding to the current verification process, instantiates execution incentives and description incentives based on the operator configuration incentives, and finally determines request interface incentives and return interface incentives. Through a layered and decoupled incentive generation and management method, it realizes the hierarchical decomposition and configuration of verification incentives from the top-level operator definition to the bottom-level interface transactions, which improves the flexibility, randomness and completeness of general computing unit verification and effectively improves the efficiency of general computing unit verification.

[0073] It should be noted that each implementation method of this application can be freely combined, rearranged, or executed individually, and does not need to rely on or depend on a fixed execution order.

[0074] In some embodiments, the execution stimulus includes start information for identifying the start of operator execution, at least one thread group task for defining operator execution tasks, and end information for identifying the end of operator execution.

[0075] Specifically, the execution stimulus may include a start message (ctxt_start), at least one thread group task (tg_task), and an end message (ctxt_end). The operator configuration stimulus, based on the configuration parameters passed by the stimulus base class, obtains the configuration information carried in the start message, the number of thread group tasks, and the configuration information carried in the end message after deconstraining.

[0076] The start information is used to identify the start of operator execution. It can be an instruction or a signal. Its function is to notify the general computing unit under test that the current operator is about to start execution.

[0077] A thread group task is the basic unit of granularity that constitutes the actual computational work of an operator. A complex operator is usually decomposed into one or more consecutive thread group tasks for execution.

[0078] The termination information is used to indicate that the operator has ended its operation. It can also be an instruction or a signal. Its function is to notify the general computing unit under test that all thread group tasks of the current operator have been issued and the execution process of the operator has ended.

[0079] The general computing unit verification method provided in this application defines the internal structure of the execution stimulus in detail, enabling the verification platform to accurately simulate the complete process of an operator from startup, task execution to final exit, thereby conducting in-depth and comprehensive verification of the general computing unit.

[0080] In some embodiments, describing the incentives includes configuration information defining the various hardware resources required by the operator.

[0081] Specifically, it describes the configuration information of various hardware resources required for the stimulus definition operator. This information is organized in the form of one or more descriptors. A descriptor is a structured data unit that can be directly parsed by a general-purpose computing unit, used to tell the general-purpose computing unit how to acquire, process, and store data.

[0082] Taking three types of hardware resources as an example, the operator configuration stimulus will, based on the configuration parameters passed from the upper layer, resolve constraints to obtain the configuration information for the three types of hardware resources, and generate sub-stimuli corresponding to the description stimulus (desc_seq), namely desc_seq0, desc_seq1, and desc_seq2. If the operator needs the corresponding hardware resources, they are passed; otherwise, they are not passed. Each operator needs to configure a set of description stimuli. Therefore, each set of description stimuli typically contains 0 to 3 sub-stimuli. For example, the description stimulus may not contain any sub-stimuli, may contain one of the three sub-stimuli, may contain two of the three sub-stimuli, or may contain all of the sub-stimuli.

[0083] The general computing unit verification method provided in this application embodiment achieves flexibility in verification configuration by describing the configuration information of various hardware resources required by the stimulus definition operator and separating it from the execution stimulus that defines the execution process.

[0084] Figure 2 This is a schematic diagram of the incentive configuration structure provided in this application, such as... Figure 2 As shown, the incentive base class (base_seq) splits the incentives in this verification into a corresponding number of operator configuration incentives (context_cfg_seq) based on the number of verification contents (context_num). Each operator configuration incentive obtains complete operator incentive information based on the passed configuration parameters, and starts the execution incentive (tg_seq) and description incentive (desc_seq) based on the operator incentive information.

[0085] In the first operator configuration stimulus ctxt_0: the execution stimulus (tg_seq) includes a start message (ctxt_start), multiple thread group tasks (tg_task), and an end message (ctxt_end); the description stimulus (desc_seq) includes three sub-stimuli corresponding to hardware resources, namely desc_seq0, desc_seq1, and desc_seq2.

[0086] In the second operator configuration stimulus ctxt_1: the execution stimulus (tg_seq) includes a start message (ctxt_start), 3 thread group tasks (tg_task), and an end message (ctxt_end); the description stimulus (desc_seq) includes 3 sub-stimuli corresponding to hardware resources, namely desc_seq0 and desc_seq2.

[0087] In the (p+1)th operator configuration stimulus ctxt_p: the execution stimulus (tg_seq) includes a start message (ctxt_start), a thread group task (tg_task), and an end message (ctxt_end). This operator configuration stimulus does not include the description stimulus (desc_seq).

[0088] In the (q+1)th operator configuration stimulus ctxt_q: the execution stimulus (tg_seq) includes a start information (ctxt_start), 3 thread group tasks (tg_task), and an end information (ctxt_end); the description stimulus (desc_seq) includes a sub-stimulus corresponding to one type of hardware resource, which is desc_seq1.

[0089] Figure 3 This is a schematic diagram of the data flow for the multi-layered stimulus provided in this application, such as... Figure 3 As shown in the figure, this application embodiment provides a multi-level incentive management method, the data flow process of which includes:

[0090] First, the incentive base class (base_seq) receives the number of verification content items (context_num) configured by the user and the user-defined verification content configuration information (ctxt_info_cfg), and then passes it to the operator to configure the incentive (context_cfg_seq).

[0091] Secondly, complete configuration information is generated in the operator configuration stimulus (context_cfg_seq), and the complete configuration information is instantiated and sent to each execution stimulus (tg_seq) in the execution stimulus combination (p in total) and each description stimulus (desc_seq) in the description stimulus combination (q in total).

[0092] Next, each execution stimulus (tg_seq) calls its respective request interface stimulus (gcu_req_seq), and each description stimulus (desc_seq) calls its respective return interface stimulus (gcu_rtn_seq).

[0093] Finally, each request interface stimulus (gcu_req_seq) sends the corresponding request interface transaction (gcu_req_transaction) to the GCU, and each return interface stimulus (gcu_rtn_seq) sends the corresponding return interface transaction (gcu_rtn_transaction) to the GCU.

[0094] The above process enables a complete GCU multi-level stimulus configuration.

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

[0096] Obtain the execution status of each operator in the general computing unit and the hardware resource impact parameters of each operator;

[0097] Based on the execution status of each operator and the hardware resource impact parameters of each operator, it is determined whether there is a hardware resource conflict between the current operator and other operators, so as to determine whether to execute the current operator.

[0098] Specifically, the number of operators is managed by the number of verification contents (ctxt_num) in the stimulus base class (base_seq). Since the hardware resources inside the general computing unit are limited, when executing multiple operators in parallel, it is necessary to consider that the hardware resources between operators do not conflict.

[0099] The execution state refers to the stage at which each instantiated operator is located at any given moment during the verification process. The execution state can be represented by busy or idle states.

[0100] Hardware resource impact parameters refer to hardware resource parameters that affect the parallel execution of operators. There can be multiple hardware resource impact parameters, which are represented as parameter 0 (param_0), parameter 1 (param_1), and parameter 2 (param_2), etc.

[0101] Therefore, a parallel_ctxt_status structure can be set to represent the execution status of each operator in the general computing unit, enabling the management of hardware resources within the general computing unit at the operator granularity. `parallel_ctxt_status={busy / idle, ctxt_id, param_0, param_1, param_2…}` Here, `busy / idle` represents the operator's execution status; `ctxt_id` is the operator's execution number; and `param_0, param_1, param_2…` represent hardware resource impact parameters affecting the parallel execution of operators.

[0102] Based on the operator parallel state structure, the execution state of each operator and the hardware resource impact parameters of each operator can be obtained, thereby determining whether there is a hardware resource conflict between the current operator (the newly added operator in the general computing unit) and the other operators, so as to determine whether to execute the current operator.

[0103] The general computing unit verification method provided in this application can dynamically detect resource conflicts when a new operator requests execution by acquiring the execution status and hardware resource usage of each operator. This allows the verification platform to no longer be limited to simply executing operators sequentially, but to simulate complex scenarios in real application scenarios where multiple operators are verified serially or in parallel and compete for hardware resources. This enables the platform to more effectively discover design flaws in GCUs in resource arbitration, task scheduling, and data consistency, and greatly improves the flexibility and completeness of general computing unit verification.

[0104] In some embodiments, based on the execution state of each operator and the hardware resource impact parameters of each operator, it is determined whether there is a hardware resource conflict between the current operator and other operators, in order to determine whether to execute the current operator, including:

[0105] If it is determined, based on the execution status of each operator, that there is no operator currently being executed, then execute the current operator.

[0106] If it is determined that there is a target operator being executed based on the execution status of each operator, the execution number of the current operator is compared with the execution number of the target operator;

[0107] If the execution number of the current operator is the same as the execution number of any target operator, it is determined that there is a hardware resource conflict between the current operator and any target operator, and the current operator is executed after the execution of any target operator is completed.

[0108] When the execution number of the current operator is different from the execution numbers of each target operator, the hardware resource impact parameters of the current operator are compared with the hardware resource impact parameters of each target operator.

[0109] If the hardware resource impact parameters of the current operator are partially the same as those of any target operator, it is determined that there is a hardware resource conflict between the current operator and any target operator, and the current operator is executed after the target operator has finished executing.

[0110] Specifically, Figure 4 This is a schematic diagram of the multi-operator parallel execution management method provided in this application, as shown below. Figure 4 As shown in the diagram, this illustration presents five scenarios.

[0111] Scenario 1: When the current operator is issued, the execution number is context_1. If it is determined based on the execution status of each operator that there is no operator currently being executed, the entire general computing unit is in an idle state and can directly execute the current operator, change the execution status of the current operator to busy, and record the hardware resource impact parameters of the current operator (such as param_0, param_1, param_2, etc.).

[0112] Scenario 2: When the current operator is issued, its execution number is context_2. If, based on the execution status of each operator, it is determined that there are currently executing target operators (e.g., operators with execution numbers context_0 and context_1), the execution number of the current operator is compared with the execution number of the target operators, confirming that they are different. Further comparison is made between the hardware resource impact parameters of the current operator and the hardware resource impact parameters of each target operator, confirming that these parameters are also different. At this point, it can be determined that there is no hardware conflict between the current operator and the target operators (context_0 and context_1), and the current operator can be executed directly. The execution status of the current operator context_2 is changed to busy, and the hardware resource impact parameters of the current operator (e.g., param_0, param_1, param_2, etc.) are recorded.

[0113] Scenario 3: When the current operator is issued, its execution number is context_0. If, based on the execution status of each operator, it is determined that there are currently executing target operators (e.g., operators with execution numbers context_0, context_1, and context_2), the execution number of the current operator is compared with the execution numbers of the target operators. It is determined that the execution number of the current operator is the same as that of the previous executing context_0 (which can be denoted as context_0'), indicating a resource conflict between the current operator context_0 and context_0'. At this point, it is necessary to wait for the context_0' operator to complete execution. After the context_0' operator completes execution (its execution status changes from busy to idle), the hardware resource impact parameters of the current operator are compared with those of the other target operators (context_1 and context_2), confirming that the hardware resource impact parameters are also different. At this point, it can be determined that there is no hardware conflict between the current operator and the target operator (context_1 and context_2). The current operator can be executed directly, the execution status of the current operator context_0 is changed to busy, and the hardware resource impact parameters of the current operator (such as param_0, param_1, param_2, etc.) are recorded.

[0114] Scenario 4: When the current operator is issued, its execution number is context_0. If, based on the execution status of each operator, it is determined that there are currently executing target operators (e.g., operators with execution numbers context_1 and context_2), the execution number of the current operator is compared with the execution number of the target operators, confirming that the execution numbers are different. Further comparison is made between the hardware resource impact parameters of the current operator and those of each target operator. It is determined that the hardware resource impact parameters of the current operator and the hardware resource impact parameters of the context_1 operator are partially identical, thus indicating a hardware conflict between the current operator and the context_1 operator. At this point, it is necessary to wait for the context_1 operator to complete execution. After the context_1 operator completes execution (its execution status changes from busy to idle), the current operator can be executed directly, changing the execution status of the current operator context_0 to busy, and recording the hardware resource impact parameters of the current operator (e.g., param_0, param_1, param_2, etc.).

[0115] Scenario 5: When the current operator is issued, its execution number is context_0. If, based on the execution status of each operator, there are target operators currently executing (e.g., operators with execution numbers context_0, context_1, and context_2), the execution number of the current operator is compared with the execution number of the target operators. If the execution number of the current operator is the same as that of the previous context_0 operator, a resource conflict between the current and previous context_0 operators can be determined. In this case, it is necessary to wait for the previous context_0 operator to complete execution. After the previous context_0 operator completes execution (its execution status changes from busy to idle), the hardware resource impact parameters of the current operator are compared with those of the other target operators (context_1 and context_2). If the hardware resource impact parameters of the current operator are partially the same as those of the context_1 operator, a hardware conflict between the current and context_1 operators can be determined. In this case, it is necessary to wait for the context_1 operator to complete execution. After the context_1 operator finishes execution (the execution state changes from busy to idle), the current operator can be executed directly, the execution state of the current operator context_0 can be changed to busy, and the hardware resource impact parameters of the current operator (such as param_0, param_1, param_2, etc.) can be recorded.

[0116] The general computing unit verification method provided in this application can dynamically detect resource conflicts when a new operator requests execution by obtaining the execution status and hardware resource usage of each operator. This enables the verification platform to simulate complex scenarios in real application scenarios where multiple operators are verified serially or in parallel and compete for hardware resources, greatly improving the flexibility and completeness of general computing unit verification.

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

[0118] Configure the first delay parameter, the second delay parameter, the third delay parameter, and the fourth delay parameter;

[0119] The first delay parameter is used to determine the initialization delay of the first execution stimulus; the second delay parameter is used to determine the initialization delay of the first description stimulus; the third delay parameter is used to determine the delay between execution stimuli; and the fourth delay parameter is used to determine the delay between description stimuli.

[0120] Specifically, in this embodiment of the application, a first delay parameter, a second delay parameter, a third delay parameter, and a fourth delay parameter are set to manage the execution timing of the execution stimulus and the description stimulus, respectively.

[0121] The first delay parameter delay_T0 is used to determine the initialization delay of the first execution stimulus, that is, the time interval between the start of the current verification process and the execution of the first execution stimulus.

[0122] The second delay parameter delay_D0 is used to determine the initialization delay of the first description stimulus, that is, the time interval between the start of the current verification process and the execution of the first description stimulus.

[0123] The third delay parameter, delay_tg[], is used to determine the delay between execution stimuli, that is, the time interval between each execution stimulus in the current verification process. delay_tg[] can be in the form of an array to represent the delay between each execution stimulus. For example, delay_tg[i] represents the delay between execution stimuli tg_seq(i) and tg_seq(i+1).

[0124] The fourth delay parameter, delay_desc[], is used to determine the delay between descriptive stimuli, that is, the time interval between each descriptive stimuli in the current verification process. delay_desc[] can be in the form of an array to represent the delay between each descriptive stimuli. For example, delay_desc[i] represents the delay between descriptive stimuli desc_seq(i) and desc_seq(i+1).

[0125] Figure 5 This is a schematic diagram of the delay management of the general computing unit provided in this application, such as... Figure 5 As shown, the following four scenarios illustrate the delay management process for each stimulus in the verification of the general computing unit. The horizontal axis represents the time axis. Taking the boxes representing tg_seq0 and tg_seq1 as an example, the length of the box represents the execution duration of the stimulus, and the length between the boxes represents the delay between the two stimuli.

[0126] Scenario 1: By setting the first delay parameter `delay_T0` and the second delay parameter `delay_D0`, the timing of the first execution stimulus `tg_seq0` and the first description stimulus `desc_seq0` can be controlled. By adjusting the values ​​of `delay_T0` and `delay_D0`, scenarios such as simultaneous delivery of `tg_seq0` and `desc_seq0`, delivery of `tg_seq0` before `desc_seq0`, and delivery of `tg_seq0` after `desc_seq0` can be implemented.

[0127] Scenario 2: By setting the first delay parameter delay_T0, the second delay parameter delay_D0, the third delay parameter delay_tg[ ] and the fourth delay parameter delay_desc[ ] to zero, the execution stimulus and the description stimulus can be continuously issued simultaneously.

[0128] Scenario 3: By setting the first delay parameter delay_T0 to be much larger than the second delay parameter delay_D0, it is possible to achieve the advance description of the stimulus delivery.

[0129] Scenario 4: By setting the third delay parameter delay_tg[] and the fourth delay parameter delay_desc[], the delay between execution stimuli and the delay between description stimuli can be controlled. For example, delay_tg[0] represents the delay between execution stimuli tg_seq0 and tg_seq1. When delay_tg[0] is non-zero, there is a delay between tg_seq0 and tg_seq1. As another example, delay_desc[0] represents the delay between description stimuli desc_seq0 and desc_seq1. When delay_desc[0] is zero, there is no delay between tg_seq0 and tg_seq1.

[0130] The general computing unit verification method provided in this application embodiment can realize the execution sequence of scheduling execution incentives and description incentives by configuring four delay parameters, so that the verification platform can simulate the complex scenario of multiple tasks running concurrently in real application scenarios, support stress testing and performance testing, and greatly improve the flexibility and completeness of general computing unit verification.

[0131] In some embodiments, the preset parameters are determined based on command-line parameters input by the user, or based on the reproduction requirements of a specific application scenario.

[0132] Specifically, this application provides two methods for configuring targeted parameters.

[0133] Method 1: User-defined. Users input custom parameters via command-line arguments (plusargs) in the verification platform. After recognition, the verification platform will use the user-defined parameters as preset parameters during operator configuration stimulus (context_cfg_seq) randomization, setting the corresponding parameters in the configuration information. Other parameters not defined by the user will be randomly generated within the constraints according to project specifications.

[0134] Method 2: Replay a specific application scenario. To support the reproduction of specific application scenarios (such as hardware simulation scenarios or software application scenarios), the scenario reproduction command replay_en=1 can be set to use the parameters already used in the specific application scenario as the preset parameters when randomizing the operator configuration stimulus (context_cfg_seq).

[0135] The general computing unit verification method provided in this application determines preset parameters through user customization or scenario reproduction, which can support the development, verification and problem localization of general computing units in specific models or scenarios, saving engineers a lot of effort and time, and improving the efficiency of general computing unit verification.

[0136] The apparatus provided in the embodiments of this application is described below. The apparatus described below can be referred to in correspondence with the method described above.

[0137] Figure 6 This is a schematic diagram of the structure of the general computing unit verification device provided in this application, as shown below. Figure 6 As shown, the device includes:

[0138] The operator configuration incentive instantiation module 610 is used to instantiate at least one operator configuration incentive based on the number of operators corresponding to the current verification process.

[0139] The execution stimulus and description stimulus instantiation module 620 is used to generate the execution stimulus and description stimulus corresponding to each operator configuration stimulus based on preset parameters and / or randomized parameters; the execution stimulus is used to define the execution flow of the operator, and the description stimulus is used to define the hardware resources required by the operator;

[0140] The interface incentive instantiation module 630 is used to generate request interface incentives for driving the general computing unit interface based on execution incentives, and to generate return interface incentives for driving the general computing unit interface based on description incentives.

[0141] The verification module 640 is used to verify the general computing unit based on the request interface transaction generated by the request interface incentive and the return interface transaction generated by the return interface incentive.

[0142] The general computing unit verification device provided in this application instantiates operator configuration incentives based on the number of operators corresponding to the current verification process, instantiates execution incentives and description incentives based on the operator configuration incentives, and finally determines request interface incentives and return interface incentives. Through a layered and decoupled incentive generation and management method, it realizes the hierarchical decomposition and configuration of verification incentives from the top-level operator definition to the bottom-level interface transactions, which improves the flexibility, randomness and completeness of general computing unit verification and effectively improves the efficiency of general computing unit verification.

[0143] Figure 7 This is a schematic diagram of the structure of the electronic device provided in this application, such as... Figure 7 As shown, the electronic device may include: a processor 710, a communications interface 720, a memory 730, and a communications bus 740, wherein the processor, communications interface, and memory communicate with each other via the communications bus. The processor can invoke logical commands stored in the memory to execute the methods described in the above embodiments, for example:

[0144] Based on the number of operators corresponding to the current verification process, instantiate at least one operator configuration stimulus; based on preset parameters and / or randomized parameters, generate execution stimuli and description stimuli corresponding to each operator configuration stimulus; the execution stimulus is used to define the execution flow of the operator, and the description stimulus is used to define the hardware resources required by the operator; based on the execution stimulus, generate request interface stimuli that drive the general computing unit interface, and based on the description stimulus, generate return interface stimuli that drive the general computing unit interface; based on the request interface stimuli generated, generate request interface transactions, and based on the return interface stimuli generated, verify the general computing unit.

[0145] Furthermore, the logical commands in the aforementioned memory can be implemented as software functional units and sold or used as independent products, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several commands to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0146] The processor in the electronic device provided in this application embodiment can call logical instructions in the memory to implement the above method. Its specific implementation method is the same as the aforementioned method implementation method and can achieve the same beneficial effect, which will not be repeated here.

[0147] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the methods provided in the above embodiments.

[0148] The specific implementation method is the same as the aforementioned method implementation method and can achieve the same beneficial effects, so it will not be repeated here.

[0149] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method described above.

[0150] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0151] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0152] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A general computing unit verification method, characterized in that, include: Based on the number of operators corresponding to the current verification process, instantiate at least one operator and configure the incentive. Based on preset parameters and / or randomized parameters, execution stimuli and description stimuli corresponding to the configuration stimuli of each operator are generated; the execution stimuli are used to define the execution flow of the operator, and the description stimuli are used to define the hardware resources required by the operator; the execution stimuli include start information for identifying the start of operator execution, at least one thread group task for defining the operator execution task, and end information for identifying the end of operator execution; the description stimuli include configuration information defining the various hardware resources required by the operator. The execution incentive generates a request interface incentive to drive the general computing unit interface, and the description incentive generates a return interface incentive to drive the general computing unit interface. The general computing unit is verified based on the request interface transaction generated by the request interface incentive and the return interface transaction generated by the return interface incentive. The method further includes: Obtain the execution status of each operator in the general computing unit and the hardware resource impact parameters of each operator; Based on the execution status of each operator and the hardware resource impact parameters of each operator, it is determined whether there is a hardware resource conflict between the current operator and other operators, so as to determine whether to execute the current operator; Configure the first delay parameter, the second delay parameter, the third delay parameter, and the fourth delay parameter; Wherein, the first delay parameter is used to determine the initialization delay of the first execution stimulus; the second delay parameter is used to determine the initialization delay of the first description stimulus; the third delay parameter is used to determine the delay between execution stimuli; and the fourth delay parameter is used to determine the delay between description stimuli. The step of determining whether to execute the current operator based on the execution status of each operator and the hardware resource impact parameters of each operator includes: If it is determined, based on the execution status of each operator, that there is no operator currently being executed, then the current operator is executed; If it is determined that there is a target operator being executed based on the execution status of each operator, the execution number of the current operator is compared with the execution number of the target operator; If the execution number of the current operator is the same as the execution number of any target operator, it is determined that there is a hardware resource conflict between the current operator and any target operator, and the current operator is executed after the execution of any target operator is completed. If the execution number of the current operator is different from the execution numbers of each target operator, the hardware resource impact parameters of the current operator are compared with the hardware resource impact parameters of each target operator. If the hardware resource impact parameters of the current operator are partially the same as those of any target operator, it is determined that there is a hardware resource conflict between the current operator and any target operator, and the current operator is executed after the target operator has finished executing.

2. The universal computing unit verification method according to claim 1, characterized in that, The preset parameters are determined based on command-line parameters input by the user, or based on the reproduction requirements of a specific application scenario.

3. A general-purpose computing unit verification device, characterized in that, include: The operator configuration incentive instantiation module is used to instantiate at least one operator configuration incentive based on the number of operators corresponding to the current verification process. An execution incentive and description incentive instantiation module is used to generate execution incentives and description incentives corresponding to each operator configuration incentive based on preset parameters and / or randomized parameters. The execution incentive is used to define the execution flow of the operator, and the description incentive is used to define the hardware resources required by the operator. The execution incentive includes start information to identify the start of the operator's operation, at least one thread group task to define the operator's execution task, and end information to identify the end of the operator's operation. The description incentive includes configuration information defining the various hardware resources required by the operator. The interface incentive instantiation module is used to generate request interface incentives for driving the general computing unit interface based on the execution incentives, and to generate return interface incentives for driving the general computing unit interface based on the description incentives. The verification module is used to verify the general computing unit based on the request interface transaction generated by the request interface incentive and the return interface transaction generated by the return interface incentive. The device is used for: Obtain the execution status of each operator in the general computing unit and the hardware resource impact parameters of each operator; Based on the execution status of each operator and the hardware resource impact parameters of each operator, it is determined whether there is a hardware resource conflict between the current operator and other operators, so as to determine whether to execute the current operator; Configure the first delay parameter, the second delay parameter, the third delay parameter, and the fourth delay parameter; Wherein, the first delay parameter is used to determine the initialization delay of the first execution stimulus; the second delay parameter is used to determine the initialization delay of the first description stimulus; the third delay parameter is used to determine the delay between execution stimuli; and the fourth delay parameter is used to determine the delay between description stimuli. The step of determining whether to execute the current operator based on the execution status of each operator and the hardware resource impact parameters of each operator includes: If it is determined, based on the execution status of each operator, that there is no operator currently being executed, then the current operator is executed; If it is determined that there is a target operator being executed based on the execution status of each operator, the execution number of the current operator is compared with the execution number of the target operator; If the execution number of the current operator is the same as the execution number of any target operator, it is determined that there is a hardware resource conflict between the current operator and any target operator, and the current operator is executed after the execution of any target operator is completed. If the execution number of the current operator is different from the execution numbers of each target operator, the hardware resource impact parameters of the current operator are compared with the hardware resource impact parameters of each target operator. If the hardware resource impact parameters of the current operator are partially the same as those of any target operator, it is determined that there is a hardware resource conflict between the current operator and any target operator, and the current operator is executed after the target operator has finished executing.

4. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the general computing unit verification method as described in claim 1 or 2.

5. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the general computing unit verification method as described in claim 1 or 2.

Images