Register configuration file generation method and device, equipment and medium

Abstract

The invention discloses a register configuration file generation method and device, equipment and a medium, and belongs to the technical field of chip verifier.The method comprises the steps that in response to a configuration file generation instruction for a target test case, a target parameter is obtained, the target parameter is used for indicating at least one of the number and the type of the electronic equipment required when the target test case runs; creating a plurality of target variables based on the target parameter through a variable creation function, the plurality of target variables including at least one level of variable in a chip level variable, a module level variable and a register level variable; and according to the sequence of the cluster-level variable, the chip-level variable, the module-level variable and the register-level variable, randomly configuring register values step by step to obtain a register configuration file. According to the application, the register value used by the target test case can be determined from the small-scale register configuration file only by using fewer computing resources of the server.

Description

Technical Field

[0001] This application relates to the field of chip verification, and in particular to a method, apparatus, device, and medium for generating register configuration files. Background Technology

[0002] Before verifying the chip cluster, the values ​​of the registers in the chip cluster need to be configured.

[0003] In related technologies, a mechanism for decoupling verification and configuration has been adopted. This technology generates a register configuration file and stores it on a server. The register configuration file contains all random values ​​for all registers in all chips within the chip cluster. When a specific test case arrives, the server determines the register value for that test case from the register configuration file.

[0004] However, although this decoupling approach can improve the efficiency of register value configuration and avoid generating register values ​​only after verification begins, as the project scale increases, the number of chips involved in the chip cluster, the number of modules within the chips, and the number of registers within each module also increase. The related technology's scheme of determining register values ​​in the full set configuration file by the server will severely consume the server's computing resources. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for generating a register configuration file. When generating the register configuration file, this application configures register values ​​only in the variables corresponding to the electronic devices required for the target test case to run. This reduces the size of the register configuration file, thus requiring only less server computing resources to determine the register values ​​used by the target test case from a small-scale register configuration file, avoiding excessive consumption of computing resources. The technical solution is as follows: According to one aspect of this application, a method for generating a register configuration file is provided, the method comprising: In response to a configuration file generation instruction for a target test case, target parameters are obtained, wherein the target parameters indicate at least one of the quantity and type of electronic devices required for the target test case to run; Using a variable creation function, several target variables are created based on the target parameters. Each target variable corresponds to an electronic device required for the execution of the target test case. The several target variables include at least one level of variables among chip-level variables, module-level variables, and register-level variables. The register values ​​are randomly configured level by level in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables to obtain the register configuration file. The register configuration file is used to determine the register values ​​to be written to the chip cluster before verification based on the target test case.

[0006] According to another aspect of this application, an apparatus for generating a register configuration file is provided, the apparatus comprising: The acquisition module is configured to acquire target parameters in response to a configuration file generation instruction for a target test case, wherein the target parameters are used to indicate at least one of the quantity and type of electronic devices required for the execution of the target test case; A module is created to create a function through variables, which creates several target variables based on the target parameters. Each target variable corresponds to an electronic device required for the execution of the target test case. The several target variables include at least one level of variables among chip-level variables, module-level variables, and register-level variables. The configuration module is used to randomly configure register values ​​level by level in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables to obtain the register configuration file. The register configuration file is used to determine the register values ​​to be written to the chip cluster before verification based on the target test case.

[0007] According to one aspect of this application, a computer device is provided, the computer device comprising: a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the register configuration file generation method as described above.

[0008] According to another aspect of this application, a computer-readable storage medium is provided, the storage medium storing a computer program that is loaded and executed by a processor to implement the register configuration file generation method as described above.

[0009] According to another aspect of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the register profile generation method provided in the above aspect.

[0010] The beneficial effects of the technical solutions provided in this application include at least the following: In this embodiment, several target variables are generated based on target parameters. Each target variable corresponds to an electronic device required for the execution of the target test case. These target variables are variables corresponding to at least one hardware level in the chip cluster. During the process of randomly configuring register values ​​level by level, when configuring to the level corresponding to several target variables, it is only necessary to configure the register values ​​in the variables corresponding to the electronic devices required for the execution of the target test case, rather than configuring the register values ​​in the variables corresponding to all electronic devices. As a result, the generated register configuration file has a small size. Before verification based on the target test case, the server can determine the register values ​​of the registers used by the target test case from the small-scale register configuration file. Since the register configuration file has a small size, it is only necessary to use less computing resources on the server to determine the register values ​​used by the target test case from the small-scale register configuration file, avoiding excessive consumption of computing resources. This application can reduce the computing scale of the server and alleviate the pressure on the server. Furthermore, because the register configuration file is relatively small, the server can quickly determine the register values ​​of the registers used by the target test case from the small register configuration file, thereby improving the overall chip verification speed of this application. Alternatively, this application transforms the static generation process of the register configuration file into a dynamic generation process. This application generates a register configuration file of a corresponding size based on the electronic device corresponding to the target test case, thereby reducing the size of the register configuration file. Furthermore, the register configuration file generated by the method provided in this application is easier to debug; during debugging, only the registers corresponding to the target test case need to be considered, without needing to consider the entire register set. In addition, the method of this application has high portability and can be applied to all subsequent project iterations or other large-scale projects such as SoCs. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating a method for generating a register configuration file provided by an exemplary embodiment is shown; Figure 2 A schematic diagram of the architecture of a chip cluster provided in an exemplary embodiment is shown; Figure 3 A flowchart illustrating a method for generating a register configuration file provided by an exemplary embodiment is shown; Figure 4 A flowchart illustrating a method for generating a register configuration file provided by an exemplary embodiment is shown; Figure 5 A flowchart illustrating a method for generating a register configuration file provided by an exemplary embodiment is shown; Figure 6 A structural block diagram of a register profile generation apparatus provided in an exemplary embodiment is shown; Figure 7 A structural block diagram of a computer device provided in an exemplary embodiment is shown; Figure 8 A structural block diagram of a computer device provided in an exemplary embodiment is shown. Detailed Implementation

[0013] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0014] It should be understood that "several" in this article refers to one or more, and "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

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

[0016] Figure 1 A flowchart illustrating a method for generating a register profile according to an exemplary embodiment of this application is shown, illustratively described as being performed by a computer device. The method includes: Step 120: In response to the command to generate a configuration file for the target test case, obtain the target parameters; In this application, a target test case refers to a test case used to test a chipset cluster. The target test case is used to test whether the chipset cluster achieves the expected performance in one or more aspects. For example, a target test case includes a test objective, preconditions, input stimuli, expected response, pass / fail criteria, and execution environment. The test objective refers to the verification objective of the target test case, such as verifying whether the data path of the chipset cluster is functioning correctly or verifying the processing performance of the chipset cluster. Preconditions refer to the state of the chipset cluster before verification, such as the chipset cluster operating at a frequency of 1 GHz and a core voltage of 0.9 V. Input stimuli refer to the main body of the target test case, which includes a series of electrical signals or data patterns applied to pins in chronological order. For example, input stimuli include a specific set of clock signals, reset signals, and values ​​on the data bus and address bus. Expected response refers to the correct response that the chipset cluster should produce under a given input stimuli. For example, after applying the input stimuli, the 8th bit of the data bus in the chipset cluster should go high. Pass / Fail Criteria: These are the criteria used to judge whether a verification passes or fails. Generally, if the actual response of the chip cluster matches the expected response, the verification passes; otherwise, it fails. Execution Environment: This refers to the hardware and software environment required to run the target test cases, such as specific automated testing equipment models, test sockets, and test programs.

[0017] In one embodiment, the target test case can be a test case actively configured by the tester. The tester can generate the target test case by configuring the characteristic parameters of the test case according to the verification requirements. The characteristic parameters mainly include relevant parameters of the input stimulus, such as clock signal parameters, reset signal parameters, input signal parameters, address signal parameters, etc. In another embodiment, the target test case can also be a test case obtained from a preset test case library. The preset test case library contains previously used test cases. By reusing existing test cases as the target test cases for this verification, the workload of the tester can be saved, and there is no need to redesign test cases.

[0018] Chip clusters are the target object to be verified in this application. Optionally, a chip cluster includes all the chips involved in a chip development project. For example, a chip development project develops two central processing units (CPUs) and ten graphics processing units (GPUs), where the CPUs and GPUs are different types of chips. For example, ... Figure 2 As shown, a chip cluster includes multiple types of chips, and each type of chip contains several specific chips. A single chip may contain multiple modules, which may be the same or different. Different types of chips contain different modules. For example, a chip might be a graphics processing unit (GPU), which contains multiple cores; these cores are the "modules" in this context.

[0019] In one embodiment, before verifying the chip cluster based on the target test case, a configuration file generation instruction for the target test case is triggered, and in response to the configuration file generation instruction, target parameters are obtained. Optionally, the configuration file generation instruction for the target test case can be generated by monitoring the test case container. For example, if a computer device detects a new target test case in the test case container, it triggers a configuration file generation instruction for the target test case. Alternatively, the configuration file generation instruction can also be generated by intercepting the target test case. For example, if a computer device monitors signals input to the chip cluster's input interface and detects the target test case, it triggers a configuration file generation instruction for the target test case. Optionally, the configuration file generation instruction for the target test case can also be triggered manually by the user, allowing the user to initiate the configuration file generation instruction for the target test case before verifying the chip cluster based on the target test case.

[0020] The target parameter indicates at least one of the number and type of electronic devices required to run the target test case. Alternatively, the target parameter indicates at least one of the number and type of electronic devices that may be used when the target test case runs. The target parameter is less than the total number of electronic devices in the chip cluster, and the target parameter corresponds to the target test case. Here, the total number of electronic devices has been reduced to the electronic devices that may be used corresponding to the target test case. Optionally, the target parameter indicates the number of electronic devices required to run the target test case, such as five; optionally, the target parameter indicates the type of electronic devices required to run the target test case, such as two; optionally, the target parameter indicates both the number and type of electronic devices required to run the target test case, such as using two first-type electronic devices or three second-type electronic devices. Electronic devices refer to hardware devices in the chip cluster, such as electronic devices including at least one of the following: chips in the chip cluster, modules within a chip, and registers within a module.

[0021] Step 140: Using the variable creation function, create several target variables based on the target parameters. Each target variable corresponds to an electronic device required for the target test case to run. The target variables include at least one level of variables among chip-level variables, module-level variables, and register-level variables. For example, the target parameter is used to indicate the target number of electronic devices required to run the target test case. Several target variables are created through the variable creation function. For example, x target variables are created in the form y=new[x] through the new function, where x is the target number.

[0022] For example, the target parameter is used to indicate the target number and target type of electronic devices required to run the target test case. Several target variables are created through the variable creation function. For example, the sum of the target variables x1 and x2 are created using the new function in the form y1=new[x1] and y2=new[x2]. x1 is the target number of electronic devices of the first type, and x2 is the target number of electronic devices of the second type.

[0023] For example, the target parameter is used to indicate the target number of electronic devices required to run the target test case. Several target variables are created through the variable creation function. For example, the target variables are created in the form of y1=new[] and y2=new[] through the new function, where y1 and y2 are target variables of different types.

[0024] Optionally, the target variable can be a dynamic array, which may contain a dynamic number of values / variables.

[0025] For example, chip-level variables refer to variables corresponding to chips in a chip cluster, module-level variables refer to variables corresponding to modules in a chip cluster, and register-level variables refer to variables corresponding to registers in chip registers. For example, the cluster-level variable is the Top variable, the chip-level variable is the sub_top variable, the module-level variable is the sub_top[i]_block variable, and the register-level variable is the sub_top[i]_block[j]_register variable.

[0026] In some embodiments, the target variables include the following cases: 1. Several target variables include chip-level variables; the electronic device is a chip. 2. Several target variables include module-level variables, with electronic devices as modules; 3. Several target variables include register-level variables; electronic devices use registers. 4. Several target variables include chip-level variables, and electronic devices include chips; and several target variables include module-level variables, and electronic devices include modules; 5. Several target variables include chip-level variables, and electronic devices include chips; and several target variables include register-level variables, and electronic devices include registers; 6. Several target variables include module-level variables, and electronic devices include modules; and several target variables include register-level variables, and electronic devices include registers; 7. Several target variables include chip-level variables, and electronic devices include chips; several target variables include module-level variables, and electronic devices include modules; several target variables include register-level variables, and electronic devices include registers.

[0027] The method provided in this application can generate variables corresponding to at least one hardware level. In a hardware level, this application will only generate variables corresponding to the electronic devices required for the target test case to run, and will not generate variables corresponding to all electronic devices in that hardware level.

[0028] Step 160: Randomly configure register values ​​level by level in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables to obtain a register configuration file. The register configuration file is used to determine the register values ​​to be written to the chip cluster before verification based on the target test cases.

[0029] For example, the `randomize` function is used to randomly configure register values ​​level by level, starting with cluster-level variables. Cluster-level variables include chip-level variables, chip-level variables include module-level variables, and module-level variables include register-level variables. The finally configured register values ​​are stored under the register variables. In one embodiment, multiple register values ​​are randomly configured for each register variable so that the register value used for verification based on the target test case can be determined from the multiple randomly configured register values.

[0030] For example, the register configuration file is used to determine the register values ​​to be used during verification based on the requirements of the target test case. The register configuration file is stored on the server, which determines the register values ​​of the registers used by the target test case from the register configuration file before performing verification based on the target test case. The determined register values ​​are then configured into the chip cluster.

[0031] Understandably, in this embodiment, several target variables will be generated based on the target parameters. Each target variable corresponds to an electronic device required for the execution of the target test case. These target variables are variables corresponding to at least one hardware level in the chip cluster. In the process of configuring register values ​​randomly level by level, when configuring to the level corresponding to several target variables, it is only necessary to configure the register values ​​in the variables corresponding to the electronic devices required for the execution of the target test case, rather than configuring the register values ​​in the variables corresponding to all electronic devices. As a result, the generated register configuration file has a small size. Before verification based on the target test case, the server can determine the register values ​​of the registers used by the target test case from the small-scale register configuration file. Since the register configuration file has a small size, it is only necessary to use less computing resources from the server to determine the register values ​​used by the target test case from the small-scale register configuration file, avoiding excessive consumption of computing resources. This application can reduce the computing scale of the server and alleviate the pressure on the server. Furthermore, because the register configuration file is relatively small, the server can quickly determine the register values ​​of the registers used by the target test case from the small register configuration file, thereby improving the overall chip verification speed of this application. Alternatively, this application transforms the static generation process of the register configuration file into a dynamic generation process. This application generates a register configuration file of a corresponding size based on the electronic device corresponding to the target test case, thereby reducing the size of the register configuration file. Furthermore, the register configuration file generated by the method provided in this application is easier to debug; during debugging, only the registers corresponding to the target test case need to be considered, without needing to consider the entire register set. In addition, the method of this application has high portability and can be applied to all subsequent project iterations or other large-scale projects such as SoCs.

[0032] In one embodiment, before step 160, the following steps S1 and S2 are further included: Step S1: Declare cluster-level variables; During the generation of the register configuration file, cluster-level variables need to be declared first. Cluster-level variables are the top-level variables, and register values ​​are then configured under these cluster-level variables. The declaration operation is an operation that establishes a variable identifier and defines the variable interface. Through the declaration operation, you can tell the computer device that a variable exists, along with its name, the types and number of parameters it receives, and the type of its return value.

[0033] Step S2: Instantiate cluster-level variables, chip-level variables, module-level variables, and register-level variables in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables. Instantiation refers to the operation of allocating storage space in computer memory.

[0034] Computer devices require the sequential instantiation of cluster-level variables, chip-level variables, module-level variables, and register-level variables. Storage space is allocated in computer memory for these variables to store their values. Optionally, during the instantiation of register-level variables, their attributes are configured. These attributes include at least one of the following: mapping relationship, bit width, whether the value can be randomly configured, and initial value. The mapping relationship refers to the correspondence between the register value and its function; for example, a register value of 1 indicates operation, and a register value of zero indicates shutdown. The bit width represents the size of the data in a register variable. Whether the value can be randomly configured indicates whether the register variable can receive randomly configured register values. The initial value represents the initial value of the register variable, such as an initial value of zero.

[0035] In one embodiment, the process of randomly configuring register values ​​step by step is performed under constraints. Constraints refer to the relationship between different register values. For example, if the state corresponding to the register value of a certain register is open, the state corresponding to the register value of another register cannot be closed. By randomly configuring register values ​​under constraints, the server can easily determine the register values ​​that can be directly used for verification of target test cases from the register configuration file.

[0036] In related technologies, all register variables in the chip cluster are randomly configured with register values ​​according to constraints. This may result in overly complex constraints, leading to situations where the constraints cannot be solved. However, the embodiments of this application reduce the number of register variables in the register configuration file, lowering the difficulty of the constraints and improving the efficiency of constraint solving.

[0037] In one embodiment, during the programming of constraints, the style of the constraint code is compatible with the pattern of the current variables. The pattern of the current variables refers to the pattern of several target variables that are dynamic arrays / associative arrays, in order to ensure applicability to all project / test case variations and avoid random failures.

[0038] In one embodiment, the register configuration file is stored on the server corresponding to the target test case. The server corresponding to the target test case determines the register values ​​used for verification of the target test case from the register configuration file. At this time, the servers can be further divided according to the test cases. For example, server 1 determines the register values ​​required for test case 1 from the register configuration file corresponding to test case 1, and server 2 determines the register values ​​required for test case 2 from the register configuration file corresponding to test case 2. This achieves targeted utilization of server resources and improves the utilization rate of server resources.

[0039] Several target variables include chip-level variables; electronic devices include chips. based on Figure 1 In the alternative embodiments shown, Figure 3 A flowchart illustrating a method for generating a register configuration file provided in an exemplary embodiment of this application is shown. Step 120 includes step 320, and step 140 includes step 340, exemplified by the method being performed by a computer device.

[0040] Step 320: In response to the configuration file generation instruction for the target test case, determine the first target parameter corresponding to the type of the target test case, or obtain the first target parameter passed through the command line; The first target parameter is used to indicate at least one of the number and type of chips required to run the target test case; optionally, the first target parameter is used to indicate the number of chips required to run the target test case, such as five; optionally, the target parameter is used to indicate the type of chips required to run the target test case, such as a first type and a second type; optionally, the target parameter is used to indicate the number and type of chips required to run the target test case, such as using two first type chips and using three second type chips.

[0041] For example, the types of target test cases include at least one of the following: functional test cases, performance test cases, data path test cases, parameter test cases, reliability test cases, chip lighting test cases, verification and validation test cases from IP level to system level, and prototype verification test cases.

[0042] Functional test cases refer to test cases used to verify whether a chip cluster meets the functional requirements of its design.

[0043] Performance test cases refer to test cases used to test the performance of a chip cluster, such as test cases used to test the processing speed and memory read / write speed of a chip cluster.

[0044] Data path test cases refer to test cases used to verify whether the chip cluster is conductive.

[0045] Parameter test cases refer to test cases used to measure whether various electrical parameters of a chip cluster are within the specified range.

[0046] Reliability test cases refer to test cases used to verify the long-term reliability of chip clusters under environments such as high temperature, low temperature, and humidity.

[0047] In one embodiment, determining the first target parameter corresponding to the type of the target test case includes: determining the first parameter range corresponding to the type of the target test case; and randomly determining the first target parameter from the first parameter range. Optionally, the first parameter range is a preset parameter range corresponding to the type of the target test case. For example, when the type of the target test case is a performance test case, the value of the first parameter range is a first value; when the type of the target test case is a data path test case, the value of the first parameter range is a second value; wherein, the performance test case is used to test the performance of the chip cluster, and the data path test case is used to test whether the chip cluster is conductive, and the first value is greater than the second value. The performance test case requires the use of more chips in the chip cluster, and the data path test case requires the use of fewer chips in the chip cluster. In this embodiment, if the target test case requires the use of more chips, the first target parameter will be determined from the parameter range with larger values; conversely, if the target test case requires the use of fewer chips, the first target parameter will be determined from the parameter range with smaller values. This embodiment sets parameter ranges for different types of target test cases, which facilitates precise control over the number of chip-level variables for different types of target test cases.

[0048] Optionally, the first target parameter is randomly determined from the first parameter interval, including: dividing the first parameter interval into a first sub-parameter interval based on the feature parameters of the target test case, and randomly determining the first target parameter from the first sub-parameter interval.

[0049] Optionally, the characteristic parameters of the target test case include at least one of the clock signal parameters, reset signal parameters, input signal parameters, and address signal parameters of the input stimulus. These characteristic parameters accurately describe the target test case, and the first sub-parameter interval in the first parameter interval can be accurately determined based on these characteristic parameters. Then, the first target parameter can be randomly determined from the first sub-parameter interval, avoiding the random selection of the number of first parameters from a large range of first parameter intervals and improving the accuracy of the number of first parameters.

[0050] Optionally, a large language model can be used to map the feature parameters of the target test case to a first sub-parameter interval. Specifically, a large language model is introduced, and with fixed prompts, the large language model is prompted to select a sub-parameter interval from the first parameter interval based on the given feature parameters of the target test case. This sub-parameter interval contains values ​​that better meet the number of chips required by the target test case during runtime. The sub-parameter interval selected by the large language model has high accuracy.

[0051] In one embodiment, the user can pass a pre-set first target parameter via the command line (cmdline). In this case, the first target parameter is a pre-set parameter, and the computer device does not need to calculate the first target parameter according to different target test cases. In this case, the pre-set first target parameter will be less than the total number of chips in the chip cluster, which can also achieve the effect of reducing the size of the register configuration file.

[0052] Optionally, the first target parameter passed through the command line has higher priority than the first target parameter determined according to the type of the target test case. When both the first target parameter passed through the command line and the first target parameter determined according to the type of the target test case are used, the first target parameter passed through the command line will prevail and the subsequent process will be executed.

[0053] Step 340: Create chip-level variables based on the first target parameters using the variable creation function. Each chip-level variable corresponds to a chip required for the target test case to run.

[0054] Similar to step 140 above, chip-level variables will be created based on the first target parameter using a variable creation function. For example, the first target parameter indicates the first target quantity of chips required for the target test case to run; chip-level variables will be created using the variable creation function. For example, the first target parameter indicates the first target quantity and first target type of chips required for the target test case to run; chip-level variables will be created using the variable creation function. For example, the first target parameter indicates the first target type of chips required for the target test case to run; chip-level variables will be created using the variable creation function.

[0055] In summary, in this embodiment, chip-level variables are generated based on the first target parameter. Each chip-level variable corresponds to a chip required for the target test case to run. Therefore, during the process of hierarchically configuring register values, when configuring at the chip level, only the variables corresponding to the chips required for the target test case to run need to be configured, rather than configuring register values ​​in all the variables corresponding to all chips. This results in a smaller register configuration file. Before verification based on the target test case, the server can determine the register values ​​of the registers used by the target test case from the smaller register configuration file. Because the register configuration file is small, only a small amount of server computing resources are needed to determine the register values ​​used by the target test case from the small-scale register configuration file, avoiding excessive computing resource consumption. This application can reduce the server's computing scale and alleviate server pressure. Furthermore, because the register configuration file is relatively small, the server can quickly determine the register values ​​of the registers used by the target test case from the small register configuration file, thereby improving the overall chip verification speed of this application.

[0056] Several target variables include module-level variables; electronic devices include modules. based on Figure 1 In the alternative embodiments shown, Figure 4 A flowchart illustrating a method for generating a register configuration file provided in an exemplary embodiment of this application is shown. Step 120 includes step 420, and step 140 includes step 440, exemplified by the method being performed by a computer device.

[0057] Step 420: In response to the configuration file generation instruction for the target test case, determine the second target parameter corresponding to the type of the target test case, or obtain the second target parameter passed through the command line; The second target parameter is used to indicate at least one of the number and type of modules required for the target test case to run; optionally, the second target parameter is used to indicate the number of modules required for the target test case to run, such as five; optionally, the target parameter is used to indicate the type of modules required for the target test case to run, such as second type and second type; optionally, the target parameter is used to indicate the number and type of modules required for the target test case to run, such as using two second type modules or using three second type modules.

[0058] In one embodiment, determining the second target parameter corresponding to the type of the target test case includes: determining the second parameter range corresponding to the type of the target test case; and randomly determining the second target parameter from the second parameter range. Optionally, the second parameter range is a preset parameter range corresponding to the type of the target test case. For example, when the type of the target test case is a performance test case, the value of the second parameter range is a second numerical value; when the type of the target test case is a data path test case, the value of the second parameter range is a second numerical value; wherein, the performance test case is used to test the performance of the module cluster, and the data path test case is used to test whether the module cluster is conductive, and the second numerical value is greater than the second numerical value. The performance test case requires more modules in the corresponding chip cluster, and the data path test case requires fewer modules in the corresponding chip cluster. In this embodiment, if the target test case requires more corresponding modules, the second target parameter will be determined from the parameter range with larger numerical values; conversely, if the target test case requires fewer corresponding modules, the second target parameter will be determined from the parameter range with smaller numerical values. This embodiment sets parameter ranges for different types of target test cases, which facilitates precise control over the number of module-level variables for different types of target test cases.

[0059] Optionally, the second target parameter is randomly determined from the second parameter interval, including: dividing the second parameter interval into a second sub-parameter interval based on the feature parameters of the target test case, and randomly determining the second target parameter from the second sub-parameter interval.

[0060] Optionally, the characteristic parameters of the target test case include at least one of the clock signal parameters, reset signal parameters, input signal parameters, and address signal parameters of the input stimulus. These characteristic parameters accurately describe the target test case, and thus the second sub-parameter interval in the second parameter interval can be accurately determined based on these characteristic parameters. Then, the second target parameter can be randomly determined from the second sub-parameter interval, avoiding the random selection of the number of second parameters from a large range of second parameter intervals, thereby improving the accuracy of the number of second parameters.

[0061] Optionally, a large language model can be used to map the feature parameters of the target test case to a second sub-parameter interval. Specifically, a large language model is introduced, and with fixed prompts, the large language model is prompted to select a sub-parameter interval from the second parameter interval based on the given feature parameters of the target test case. This sub-parameter interval contains values ​​that better meet the number of modules required by the target test case during runtime. The sub-parameter interval selected by the large language model has high accuracy.

[0062] In one embodiment, the user can pass a pre-set second target parameter via the command line (cmdline). In this case, the second target parameter is a pre-set parameter, and the computer device does not need to calculate the second target parameter according to different target test cases. In this case, the pre-set second target parameter will be less than the total number of modules in the chip cluster, which can also achieve the effect of reducing the size of the register configuration file.

[0063] Optionally, the second target parameter passed through the command line has higher priority than the second target parameter determined according to the type of the target test case. When both the second target parameter passed through the command line and the second target parameter determined according to the type of the target test case are used, the second target parameter passed through the command line will be used to execute the subsequent process.

[0064] Step 440: Create module-level variables based on the second target parameter using the variable creation function. Each module-level variable corresponds to a module required for the target test case to run. Similar to step 140 above, module-level variables will be created based on the second target parameter using a variable creation function. For example, the second target parameter indicates the second target number and second target type of modules required for the target test case to run; module-level variables are created using the variable creation function. For example, the second target parameter indicates the second target type of modules required for the target test case to run; module-level variables are created using the variable creation function.

[0065] In summary, in this embodiment, module-level variables are generated based on the second target parameter. Each module-level variable corresponds to a module required for the target test case to run. Therefore, during the process of hierarchically and randomly configuring register values, when configuring at the module level, only the variables corresponding to the modules required for the target test case to run need to be configured, rather than configuring register values ​​in all variables corresponding to all modules. This results in a smaller register configuration file. Before verification based on the target test case, the server can determine the register values ​​of the registers used by the target test case from the smaller register configuration file. Because the register configuration file is small, only a small amount of server computing resources are needed to determine the register values ​​used by the target test case from the small-scale register configuration file, avoiding excessive computing resource consumption. This application can reduce the server's computing scale and alleviate server pressure. Furthermore, because the register configuration file is relatively small, the server can quickly determine the register values ​​of the registers used by the target test case from the small register configuration file, thereby improving the overall chip verification speed of this application.

[0066] Several target variables include chip-level variables, where electronic devices include chips, and several target variables include module-level variables, where electronic devices include modules. based on Figure 1 In the alternative embodiments shown, Figure 5 A flowchart illustrating a method for generating a register configuration file provided in an exemplary embodiment of this application is shown. Step 120 includes steps 521 and 522, and step 140 includes steps 541 and 542, exemplified by the method being performed by a computer device.

[0067] Step 521: In response to the command to generate the configuration file for the target test case, determine the first target parameter corresponding to the type of the target test case, or obtain the first target parameter passed through the command line; For an explanation of step 521, please refer to the relevant content of step 320 above.

[0068] Step 522: In response to the command to generate the configuration file for the target test case, determine the second target parameter corresponding to the type of the target test case, or obtain the second target parameter passed through the command line; For details on step 522, please refer to the relevant content of step 420 above.

[0069] Step 541: Create chip-level variables based on the first target parameters using the variable creation function. Each chip-level variable corresponds to a chip required for the target test case to run. For an explanation of step 541, please refer to the relevant content of step 340 above.

[0070] Step 542: Create module-level variables based on the second target parameter using the variable creation function. Each module-level variable corresponds to a module required for the target test case to run. For an explanation of step 542, please refer to the relevant content of step 440 above.

[0071] In summary, in this embodiment, chip-level variables are generated based on the first target parameter, and module-level variables are generated based on the second target parameter. Therefore, during the process of hierarchically and randomly configuring register values, configuration is only required for the variables corresponding to the chips and modules needed for the target test case to run, without needing to configure register values ​​for all chips and modules. This results in a smaller register configuration file. Before verification based on the target test case, the server can determine the register values ​​of the registers used by the target test case from the smaller register configuration file. Because the register configuration file is small, only a small amount of server computing resources are needed to determine the register values ​​used by the target test case from the small-scale register configuration file, avoiding excessive computing resource consumption. This application can reduce the server's computing scale and alleviate server pressure. Furthermore, because the register configuration file is relatively small, the server can quickly determine the register values ​​of the registers used by the target test case from the small register configuration file, thereby improving the overall chip verification speed of this application.

[0072] Figure 6 This application shows a structural block diagram of a register profile generation apparatus provided in an exemplary embodiment, the apparatus comprising: The acquisition module 601 is used to acquire target parameters in response to the configuration file generation instruction for the target test case. The target parameters are used to indicate at least one of the number and type of electronic devices required for the target test case to run. Create module 602, which is used to create functions through variables to create several target variables based on target parameters. Each target variable corresponds to an electronic device required for the execution of the target test case. The several target variables include at least one level of variables among chip-level variables, module-level variables, and register-level variables. Configuration module 603 is used to randomly configure register values ​​level by level in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables to obtain register configuration file. Register configuration file is used to determine the register values ​​to be written to the chip cluster before verification based on target test cases.

[0073] In an optional embodiment, when several target variables include chip-level variables and the electronic device is a chip, the acquisition module 601 is further used to determine the first target parameter corresponding to the type of the target test case; or, Retrieve the first target parameter passed via the command line; The first target parameter is used to indicate at least one of the number and type of chips required to run the target test case. The types of target test cases include at least one of the following: functional test cases, performance test cases, data path test cases, parameter test cases, reliability test cases, chip lighting test cases, verification and validation test cases from IP level to system level, and prototype verification test cases.

[0074] In an optional embodiment, the acquisition module 601 is further configured to determine the first parameter range corresponding to the type of the target test case; The first target parameter is randomly determined from the first parameter range.

[0075] In an optional embodiment, when the type of the target test case is a performance test case, the value of the first parameter range is a first value. When the target test case is a data path test case, the value of the first parameter range is the second value; Among them, the performance test cases are used to test the performance of the chip cluster, and the data path test cases are used to test whether the chip cluster is conductive. The first value is greater than the second value.

[0076] In an optional embodiment, the acquisition module 601 is further configured to divide a first sub-parameter interval from the first parameter interval based on the feature parameters of the target test case; and randomly determine a first target parameter from the first sub-parameter interval.

[0077] In an optional embodiment, the acquisition module 601 is further configured to prompt the large language model to select a first sub-parameter interval from the first parameter interval based on the feature parameters of the target test case using fixed prompt words.

[0078] In an optional embodiment, when several target variables include module-level variables and the electronic device is a module, obtaining module 601 is also used to determine the second target parameter corresponding to the type of the target test case; or, Retrieve the second target parameter passed via the command line; The second target parameter is used to indicate at least one of the number and types of modules required to run the target test case. The types of target test cases include at least one of the following: functional test cases, performance test cases, data path test cases, parameter test cases, reliability test cases, chip lighting test cases, verification and validation test cases from IP level to system level, and prototype verification test cases.

[0079] In an optional embodiment, when the target variables include chip-level variables and the electronic device includes chips, and when the target variables include module-level variables and the electronic device includes modules, the acquisition module 601 is further configured to determine a first target parameter corresponding to the type of the target test case; or, acquire the first target parameter passed through the command line; the first target parameter is used to indicate at least one of the number and type of chips required for the target test case to run. In addition, determine the second target parameter corresponding to the type of the target test case; or, obtain the second target parameter passed through the command line; the second target parameter is used to indicate at least one of the number and type of modules required for the target test case to run. The target test cases include at least one of the following types: functional test cases, performance test cases, data path test cases, parameter test cases, reliability test cases, chip lighting test cases, verification and validation test cases from IP level to system level, and prototype verification test cases.

[0080] In an optional embodiment, the device further includes a program processing module 604. The program processing module 604 is used to declare cluster-level variables; and to instantiate cluster-level variables, chip-level variables, module-level variables, and register-level variables in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables, where instantiation refers to the operation of allocating storage space in computer memory.

[0081] In an optional embodiment, the program processing module 604 is further configured to configure the attributes of the register variable during the instantiation of the register-level variable. The attributes include at least one of the following: mapping relationship, bit width, whether the value can be randomly configured, and initial value.

[0082] Figure 7This is a structural block diagram of a computer device according to an exemplary embodiment. The computer device 700 includes a Central Processing Unit (CPU) 701, a system memory 704 including Random Access Memory (RAM) 702 and Read-Only Memory (ROM) 703, and a system bus 705 connecting the system memory 704 and the CPU 701. The computer device 700 also includes a basic input / output system (I / O system) 706 to facilitate information transfer between various devices within the computer device, and a mass storage device 707 for storing an operating system 713, application programs 714, and other program modules 715.

[0083] The basic input / output system 706 includes a display 708 for displaying information and an input device 709 for user input, such as a mouse or keyboard. Both the display 708 and the input device 709 are connected to the central processing unit 701 via an input / output controller 710 connected to the system bus 705. The basic input / output system 706 may also include the input / output controller 710 for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 710 also provides output to a display screen, printer, or other types of output devices.

[0084] The mass storage device 707 is connected to the central processing unit 701 via a mass storage controller (not shown) connected to the system bus 705. The mass storage device 707 and its associated computer device-readable media provide non-volatile storage for the computer device 700. That is, the mass storage device 707 may include computer device-readable media (not shown), such as a hard disk or a compact disc read-only memory (CD-ROM) drive.

[0085] Without loss of generality, the computer device readable medium may include computer device storage media and communication media. Computer device storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer device readable instructions, data structures, program modules, or other data. Computer device storage media include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), CD-ROM, digital video disc (DVD), or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that the computer device storage media are not limited to the above-mentioned types. The system memory 704 and mass storage device 707 described above can be collectively referred to as memory.

[0086] According to various embodiments of this disclosure, the computer device 700 can also be connected to a remote computer device on a network, such as the Internet. That is, the computer device 700 can be connected to the network 711 via a network interface unit 712 connected to the system bus 705, or the network interface unit 712 can be used to connect to other types of networks or remote computer device systems (not shown).

[0087] The memory also includes one or more programs stored in the memory, and the central processing unit 701 executes the one or more programs to implement all or part of the steps of the above-described method for generating the register configuration file.

[0088] Figure 8 This illustration shows a structural block diagram of a computer device 800 provided in an exemplary embodiment of this application. The computer device 800 may be a portable mobile terminal, such as a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. The computer device 800 may also be referred to as a user device, portable terminal, laptop terminal, desktop terminal, or other names.

[0089] Typically, computer device 800 includes a processor 801 and a memory 802.

[0090] Processor 801 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 801 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 801 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 801 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 801 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0091] Memory 802 may include one or more computer-readable storage media, which may be non-transitory. Memory 802 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in memory 802 is used to store at least one instruction, which is executed by processor 801 to implement the register profile generation method provided in the method embodiments of this application.

[0092] In some embodiments, the computer device 800 may also optionally include a peripheral device interface 803 and at least one peripheral device. The processor 801, memory 802, and peripheral device interface 803 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 803 via a bus, signal line, or circuit board. For example, the peripheral device may include at least one of the following: a radio frequency circuit 804, a display screen 805, a camera assembly 806, an audio circuit 807, and a power supply 808.

[0093] Peripheral device interface 803 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 801 and memory 802. In some embodiments, processor 801, memory 802 and peripheral device interface 803 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 801, memory 802 and peripheral device interface 803 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0094] The radio frequency (RF) circuit 804 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 804 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 804 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 804 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 804 can communicate with other terminals through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 804 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0095] Display screen 805 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 805 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 801 for processing. In this case, display screen 805 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 805, disposed on the front panel of computer device 800; in other embodiments, there may be at least two display screens, disposed on different surfaces of computer device 800 or in a folded design; in still other embodiments, display screen 805 may be a flexible display screen, disposed on a curved or folded surface of computer device 800. Furthermore, display screen 805 may be configured as a non-rectangular irregular shape, i.e., a non-rectangular screen. Display screen 805 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0096] The camera assembly 806 is used to acquire images or videos. Optionally, the camera assembly 806 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 806 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.

[0097] The audio circuit 807 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting the sound waves into electrical signals that are input to the processor 801 for processing, or input to the radio frequency circuit 804 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each located in a different part of the computer device 800. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 801 or the radio frequency circuit 804 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 807 may also include a headphone jack.

[0098] Power supply 808 is used to supply power to various components in computer device 800. Power supply 808 can be alternating current, direct current, a disposable battery, or a rechargeable battery. When power supply 808 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery that is charged via a wired line, while a wireless rechargeable battery is a battery that is charged via a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0099] In some embodiments, the computer device 800 further includes one or more sensors 809. The one or more sensors 809 include, but are not limited to, an accelerometer 810, a gyroscope 811, a pressure sensor 812, an optical sensor 813, and a proximity sensor 814.

[0100] Accelerometer 810 can detect the magnitude of acceleration along the three coordinate axes of a coordinate system established by computer device 800. For example, accelerometer 810 can be used to detect the components of gravitational acceleration along the three coordinate axes. Processor 801 can control display screen 805 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 810. Accelerometer 810 can also be used for games or for acquiring user motion data.

[0101] The gyroscope sensor 811 can detect the orientation and rotation angle of the computer device 800. The gyroscope sensor 811, in conjunction with the accelerometer sensor 810, can collect 3D motion data from the user on the computer device 800. Based on the data collected by the gyroscope sensor 811, the processor 801 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

[0102] The pressure sensor 812 can be disposed on the side bezel of the computer device 800 and / or on the lower layer of the display screen 805. When the pressure sensor 812 is disposed on the side bezel of the computer device 800, it can detect the user's grip signal on the computer device 800, and the processor 801 can perform left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 812. When the pressure sensor 812 is disposed on the lower layer of the display screen 805, the processor 801 can control the operable controls on the UI interface based on the user's pressure operation on the display screen 805. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0103] An optical sensor 813 is used to collect ambient light intensity. In one embodiment, the processor 801 can control the display brightness of the display screen 805 based on the ambient light intensity collected by the optical sensor 813. For example, when the ambient light intensity is high, the display brightness of the display screen 805 is increased; when the ambient light intensity is low, the display brightness of the display screen 805 is decreased. In another embodiment, the processor 801 can also dynamically adjust the shooting parameters of the camera assembly 806 based on the ambient light intensity collected by the optical sensor 813.

[0104] A proximity sensor 814, also known as a distance sensor, is typically located on the front panel of a computer device 800. The proximity sensor 814 is used to detect the distance between the user and the front of the computer device 800. In one embodiment, when the proximity sensor 814 detects that the distance between the user and the front of the computer device 800 is gradually decreasing, the processor 801 controls the display screen 805 to switch from a screen-on state to a screen-off state; when the proximity sensor 814 detects that the distance between the user and the front of the computer device 800 is gradually increasing, the processor 801 controls the display screen 805 to switch from a screen-off state to a screen-on state.

[0105] Those skilled in the art will understand that Figure 8 The structure shown does not constitute a limitation on the computer device 800, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0106] This application also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the register configuration file generation method provided in the above method embodiments.

[0107] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the register configuration file generation method provided in the above-described method embodiments.

[0108] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0109] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. The above descriptions are merely optional embodiments of this application and are not intended to limit the application. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for generating a register configuration file, characterized in that, The method includes: In response to a configuration file generation instruction for a target test case, target parameters are obtained, wherein the target parameters indicate at least one of the quantity and type of electronic devices required for the target test case to run; Using a variable creation function, several target variables are created based on the target parameters. Each target variable corresponds to an electronic device required for the execution of the target test case. The several target variables include at least one level of variables among chip-level variables, module-level variables, and register-level variables. The register values ​​are randomly configured level by level in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables to obtain the register configuration file. The register configuration file is used to determine the register values ​​to be written to the chip cluster before verification based on the target test case.

2. The method according to claim 1, characterized in that, When the plurality of target variables includes the chip-level variables, and the electronic device is a chip. The acquisition of target parameters includes: Determine the first target parameter corresponding to the type of the target test case; or, Retrieve the first target parameter passed via the command line; The first target parameter is used to indicate at least one of the quantity and type of chips required to run the target test case. The type of the target test case includes at least one of the following: functional test case, performance test case, data path test case, parameter test case, reliability test case, chip lighting test case, verification and validation test case from IP level to system level, and prototype verification test case.

3. The method according to claim 2, characterized in that, The first target parameter corresponding to the type of the target test case is determined as follows: Determine the first parameter range corresponding to the type of the target test case; The first target parameter is randomly determined from the first parameter range.

4. The method according to claim 3, characterized in that, When the type of the target test case is a performance test case, the value of the first parameter range is a first value; When the type of the target test case is a data path test case, the value of the first parameter range is the second value; The performance test case is used to test the performance of the chip cluster, and the data path test case is used to test whether the chip cluster is conductive. The first value is greater than the second value.

5. The method according to claim 3, characterized in that, The step of randomly determining the first target parameter from the first parameter range includes: Based on the characteristic parameters of the target test case, a first sub-parameter interval is divided from the first parameter interval; the first target parameter is randomly determined from the first sub-parameter interval.

6. The method according to claim 5, characterized in that, The step of dividing the first sub-parameter interval from the first parameter interval based on the feature parameters of the target test case includes: By using fixed prompt words, the large language model is prompted to select the first sub-parameter interval from the first parameter interval based on the feature parameters of the target test case.

7. The method according to claim 1, characterized in that, When the target variables include the module-level variables, and the electronic device is a module. The acquisition of target parameters includes: Determine the second target parameter corresponding to the type of the target test case; or, Retrieve the second target parameter passed via the command line; The second target parameter is used to indicate at least one of the number and types of modules required for the execution of the target test case. The types of the target test cases include at least one of the following: functional test cases, performance test cases, data path test cases, parameter test cases, reliability test cases, chip lighting test cases, verification and validation test cases from IP level to system level, and prototype verification test cases.

8. The method according to claim 1, characterized in that, When the plurality of target variables includes the chip-level variables and the electronic device includes a chip, and when the plurality of target variables includes the module-level variables and the electronic device includes modules, The acquisition of target parameters includes: Determine the first target parameter corresponding to the type of the target test case; or, obtain the first target parameter passed through the command line; the first target parameter is used to indicate at least one of the number and type of chips required to run the target test case. And, determine the second target parameter corresponding to the type of the target test case; or, obtain the second target parameter passed through the command line; the second target parameter is used to indicate at least one of the number and type of modules required for the target test case to run; The target test cases include at least one of the following types: functional test cases, performance test cases, data path test cases, parameter test cases, reliability test cases, chip lighting test cases, verification and validation test cases from IP level to system level, and prototype verification test cases.

9. The method according to any one of claims 1 to 8, characterized in that, Before the step of randomly configuring register values ​​level by level in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables, the following steps are included: Declare the cluster-level variables; The cluster-level variables, chip-level variables, module-level variables, and register-level variables are instantiated in the following order: cluster-level variables, chip-level variables, module-level variables, and register-level variables. Instantiation refers to the operation of allocating storage space in computer memory.

10. The method according to claim 9, characterized in that, The method further includes: During the instantiation of the register-level variable, the attributes of the register variable are configured, including at least one of the following: mapping relationship, bit width, whether the value can be randomly configured, and initial value.

11. An apparatus for generating a register configuration file, characterized in that, The device includes: The acquisition module is configured to acquire target parameters in response to a configuration file generation instruction for a target test case, wherein the target parameters are used to indicate at least one of the quantity and type of electronic devices required for the execution of the target test case; A module is created to create a function through variables, which creates several target variables based on the target parameters. Each target variable corresponds to an electronic device required for the execution of the target test case. The several target variables include at least one level of variables among chip-level variables, module-level variables, and register-level variables. The configuration module is used to randomly configure register values ​​level by level in the order of cluster-level variables, chip-level variables, module-level variables, and register-level variables to obtain the register configuration file. The register configuration file is used to determine the register values ​​to be written to the chip cluster before verification based on the target test case.

12. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the register configuration file generation method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is loaded and executed by a processor to implement the method for generating a register configuration file as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, The computer program product stores a computer program that is loaded and executed by a processor to implement the register configuration file generation method as described in any one of claims 1 to 10.

Images