An attribution method, computing system, and storage medium for chip verification

Abstract

This application provides an attribution method, computing system, and storage medium for chip verification. The attribution method includes: before each simulation task runs, acquiring at least one pre-configured configuration factor and vectorizing it; generating a corresponding failure signature when the simulation result indicates task failure; determining the mapping relationship between the simulation result and the at least one configuration factor based on the failure signature, and identifying at least one candidate configuration factor; calculating the failure contribution of each candidate configuration factor, and ranking the candidate configuration factors according to the magnitude of the failure contribution; selecting a preset number of top-ranked candidate configuration factors for targeted verification, and generating an attribution report. The attribution method for chip verification in this application can quickly and accurately determine which configuration factors truly cause simulation failure from multiple configuration factors, greatly improving attribution efficiency and significantly shortening code debugging time.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, and in particular to an attribution method, computing system and storage medium for chip verification. Background Technology

[0002] In chip development, the cost of chip tape-out is extremely high. If a logic error occurs, the entire tape-out is scrapped, resulting in significant losses. Therefore, before chip manufacturing, it is essential to conduct extensive testing across all scenarios in a computer simulation environment, including normal read / write, concurrent transmission, extreme bandwidth, abnormal errors, resets, and interrupts. This testing process requires defining multiple simulation tasks. If all simulation tasks execute successfully, the chip passes the test; if any simulation task fails, the simulation task fails. Currently, root cause analysis of failed test cases still relies heavily on manual methods. However, the larger the number of failed test cases, the more manpower is required to analyze the causes of failure, leading to high analysis costs and long processing times, potentially exceeding the testing cycle and impacting product release schedules. To reduce debugging overhead, developers have proposed some intelligent methods for test case root cause analysis. However, most of these methods currently only utilize failure logs to reproduce the simulation task failure process, and cannot accurately trace the true cause of failure when faced with numerous configuration factors.

[0003] Therefore, how to provide an attribution method, computing system, and storage medium for chip verification to improve the efficiency and accuracy of root cause analysis is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] This application is made in view of at least one of the above-mentioned technical problems existing in the prior art.

[0005] According to one aspect of this application, an attribution method for chip verification is provided. The method includes: before each simulation task runs, acquiring at least one pre-configured configuration factor and vectorizing the at least one configuration factor; generating a corresponding failure signature based on the simulation result of each simulation task, provided the simulation result indicates failure; determining the mapping relationship between the simulation result and the at least one configuration factor based on the failure signature, and identifying at least one candidate configuration factor; calculating the failure contribution of each candidate configuration factor, and ranking all candidate configuration factors according to the magnitude of the failure contribution; selecting a preset number of top-ranked candidate configuration factors for targeted verification, and generating an attribution report based on the verification results. The attribution method for chip verification in this application can quickly and accurately determine which configuration factors truly cause simulation failure from multiple configuration factors, greatly improving attribution efficiency and significantly shortening code debugging time.

[0006] According to another aspect of this application, a computing system is also provided, comprising: one or more processors; and a non-transitory memory storing instructions, wherein when the one or more processors execute these instructions, the instructions configure the one or more processors to execute instructions including: before each simulation task runs, acquiring at least one pre-configured configuration factor and vectorizing the at least one configuration factor; generating a corresponding failure label based on the simulation result of each simulation task, in the case where the simulation result indicates failure; determining at least one candidate configuration factor based on the mapping relationship between the simulation result and the at least one configuration factor; calculating the failure contribution of each candidate configuration factor and ranking all candidate configuration factors according to the magnitude of the failure contribution; selecting a predetermined number of top-ranked candidate configuration factors for targeted verification, and generating an attribution report based on the verification results. This computing system has the same technical effect as the attribution method used for chip verification.

[0007] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, the computer-readable storage medium including instructions, which, when executed by a computer, cause the computer to: before each simulation task runs, acquire at least one pre-configured configuration factor and vectorize the at least one configuration factor; generate a corresponding failure label based on the simulation result of each simulation task, in the case where the simulation result indicates failure; determine at least one candidate configuration factor based on the mapping relationship between the simulation result and the at least one configuration factor; calculate the failure contribution of each candidate configuration factor and rank all candidate configuration factors according to the magnitude of the failure contribution; select a predetermined number of candidate configuration factors with the highest ranking for targeted verification, and generate an attribution report based on the verification results. This non-transitory computer-readable storage medium has the same technical effect as the attribution method used for chip verification. Attached Figure Description

[0008] Figure 1 A schematic flowchart of an attribution method 100 for chip verification according to an embodiment of this application is shown; Figure 2 A schematic flowchart illustrating step S101 according to an embodiment of this application is shown; Figure 3 A schematic flowchart illustrating step S102 according to an embodiment of this application is shown; Figure 4 A schematic flowchart illustrating step S103 according to an embodiment of this application is shown; Figure 5 A schematic flowchart illustrating step S104 according to an embodiment of this application is shown; Figure 6 A schematic flowchart illustrating step S104 according to another embodiment of this application is shown; Figure 7 A schematic flowchart illustrating step S105 according to an embodiment of this application is shown; Figure 8 A schematic flowchart illustrating step S105 according to another embodiment of this application is shown; Figure 9 This diagram illustrates a schematic flowchart of establishing a historical sample matrix based on all complete paths corresponding to all failed samples, according to an embodiment of this application. Figure 10 A schematic flowchart of an attribution method 1000 for chip verification according to another embodiment of this application is shown; Figure 11 A schematic block diagram of an attribution device 1100 for chip verification according to an embodiment of this application is shown; Figure 12 A schematic block diagram of a computing system 1200 according to an embodiment of this application is shown. Detailed Implementation

[0009] To enable those skilled in the art to better understand the technical solutions of the embodiments of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0010] The Universal Verification Methodology (UVM) platform is a standardized, open-source, industrial-grade chip verification library and supporting design specifications designed based on the SystemVerilog (SV) hardware verification language. It is specifically designed to perform functional simulation verification of digital chips (CPUs, SOCs, AXI buses, interfaces, medical chips, etc.) to check for bugs in the chip logic. Because chip tape-out costs are extremely high, if a logic error occurs, the entire tape-out is scrapped, resulting in losses of millions. Therefore, before chip manufacturing, it is essential to conduct extensive testing across all scenarios in a computer simulation environment, such as normal read / write, concurrent transmission, extreme bandwidth, abnormal errors, resets, and interrupts. Early chip verification involved writing simple test code by hand, resulting in messy and unreusable code. UVM, however, unifies the platform architecture, allowing engineers across all companies to use the same standard to write verification environments and verify the Design Under Test (DUT) code within these environments. UVM builds an independent simulation platform that performs three core tasks: generating stimuli (simulating CPU, DMA, peripherals, etc., sending read / write transaction data packets to the DUT), monitoring and acquisition (capturing all input / output signals of the chip in real time), and automatic comparison and error detection (comparing the actual output of the chip with the theoretically correct result; immediately printing error logs if there are discrepancies; and simultaneously calculating bandwidth and coverage to determine if the test is sufficient). Based on the UVM standard library, this layered, reusable simulation and testing platform automatically sends massive bus transactions to the chip for stimulation, automatically verifies the correctness of the chip's output, calculates bus bandwidth performance, and proactively identifies internal logic defects in the chip—a complete industrial process.

[0011] When verifying chips using the UVM verification platform, even a single digital verification regression typically involves a large number of test cases, multiple runtime modes, multiple simulation environment configuration profiles, different random seeds, different macro definitions, different filelists, and combinations of configuration information such as coverage, waveforms, and standard delay files (SDF). Existing verification toolchains can usually handle test list parsing, concurrent task distribution, failure seed recording, and log archiving. However, the root cause localization phase after a failure still primarily relies on engineers manually reviewing logs, manually comparing command lines, and manually guessing candidate configurations. Traditional techniques mainly employ the following methods for root cause localization: (1) The targeted rerun technology based on failed seed can reproduce the same random failure, but can only answer how to trigger the failure again, and cannot answer which profile, macro definition, simulation plusarg, filelist or inheritance source is most likely to cause the failure.

[0012] (2) Log scanning and error pattern matching technology are used to determine PASS / FAIL or extract error type by keywords, but usually ignores the relationship between configuration inheritance path, command components and failure probability.

[0013] (3) Attribution analysis was performed using general data analysis or machine learning classification techniques, but no effective source tracing and attribution analysis was performed on the three-stage command structure and inheritance expansion of case, mode, profile, seed, compile / elab / sim option in chip verification regression.

[0014] It is evident that traditional technologies lack an effective method to automatically trace the source of defects and attribute the causes of failures when faced with regression failures involving multiple running modes, multiple profiles, different seeds, and multiple layers of configuration inheritance.

[0015] Based on at least one of the aforementioned technical problems, this application provides an attribution method for chip verification, characterized in that it is applied to a verification platform (UVM) for running at least one simulation task; the method includes: before each simulation task runs, acquiring at least one pre-configured configuration factor and vectorizing the at least one configuration factor; generating a corresponding failure label based on the simulation result of each simulation task, in the case where the simulation result indicates failure; determining at least one candidate configuration factor based on the mapping relationship between the simulation result and the at least one configuration factor; calculating the failure contribution of each candidate configuration factor and ranking all candidate configuration factors according to the numerical value of the failure contribution; selecting a preset number of top-ranked candidate configuration factors for targeted verification, and generating an attribution report based on the verification results. The attribution method for chip verification in this application can quickly and accurately determine which configuration factors truly cause simulation failure from multiple configuration factors, greatly improving attribution efficiency and significantly shortening code debugging time.

[0016] Figure 1 This diagram illustrates an attribution method for chip verification according to an embodiment of this application; as shown. Figure 1 As shown, the attribution method 100 for chip verification according to an embodiment of this application may include the following steps S101, S102, S103, S104, and S105: In step S101, before each simulation task runs, at least one of its pre-configured configuration factors is obtained, and the at least one configuration factor is vectorized.

[0017] The expression for the simulation task is as follows: (1) in, Represents a set of simulation tasks; Represents a set of test cases; A collection representing patterns; Represents a set of seeds; Represents a set of compiler options; Represents the set of elaboration options; Represents a set of simulation options; This represents a collection of filelist, profile, and SDF file-based configurations. This represents a collection of code versions and tool environments.

[0018] The configuration factor here refers to the independent, switchable parameter item written in the configuration file, which is used to control the simulation's behavior.

[0019] During the attribution process, due to the large number of configuration factors, using a field-by-field iterative comparison approach results in code redundancy and low batch matching efficiency. Therefore, it is necessary to perform vectorization processing on the configuration factors. This involves packaging the configuration factors into a one-dimensional ordered vector according to a unified fixed-dimensional order, for example, using immutable tuples in Python to hold this vector. This allows for overall vector equality judgment instead of multi-field individual verification, improving configuration matching efficiency while standardizing the data format and adapting to subsequent batch matrix operations such as one-hot encoding and probability scoring.

[0020] In one embodiment of this application, such as Figure 2 As shown, step S101, which involves obtaining at least one configuration factor pre-configured for each simulation task before execution and vectorizing the at least one configuration factor, includes steps S201 and S202: In step S201, before each simulation task runs, a snapshot of its valid configuration is recorded; In step S202, based on the type of at least one configuration factor in the effective configuration snapshot, the at least one configuration factor is converted into a corresponding Boolean, enumerated, or numerical mixed feature vector.

[0021] The effective configuration snapshot includes at least the following: simulation project, module under test, test cases, running mode, environment configuration profile, random seed, UVM top-level test case name, hardware description file list, high-level verification language file list, compilation parameters, simulation build parameters, simulation run parameters, coverage configuration parameters, waveform dump configuration parameters, standard delay file (SDF / corner option), simulation tool version number, git code branch, and commit snapshot status.

[0022] The effective configuration snapshot here records the UVM simulation compilation and runtime configuration parameters. Here, "project" refers to the overall identifier of the entire simulation project, used to distinguish different chip / module development projects; its script is used to isolate log, waveform, and coverage file directories. "Module" refers to an independent functional unit within the chip, such as a routing module, ΔVBE benchmark module, bus interface module, etc.; as a configuration factor, "module" specifies the top-level HDL module to be compiled / verified in this simulation. "Case" refers to a single simulation stimulus scenario, corresponding to a UVM sequence / test, such as normal packet sending, exception injection, boundary threshold testing, etc.; for batch simulations, a case list is required for batch testing. "Mode" refers to the mode controlling the simulation operation, such as compile, compile only, simulation only, with waveform dump, coverage only, fast release mode, debug mode, etc. "Profile" refers to a predefined set of combined parameter templates, packaging compilation options, simulation options, process corners, and coverage switches into a profile, allowing one-click switching back to the profile (such as regression or debug profiles). `seed` refers to the seed generated by the UVM random stimulus generator; the same seed generates completely identical random data packets and random constraint stimuli to facilitate problem reproduction; changing the seed allows traversing multiple sets of random scenarios. `UVM_testname` refers to the UVM environment entry class (inheriting from `UVM_test`), which is automatically instantiated after simulation starts, carrying the entire verification environment and sequence startup logic. `hdl_filelist` refers to the RTL source code listing, used to store Verilog / SystemVerilog / VHDL design code and DUT hardware module file paths. `hvl_filelist` refers to the UVM verification platform code listing, containing SystemVerilog verification code such as agent, driver, monitor, sequence, scoreboard, and test. `compile_opts` refers to the parameters passed to the simulator when compiling RTL & UVM code, including macro definitions, include paths, compilation alarm masking, syntax check switches, etc. `elab_opts` refers to the set of parameters for the netlist instantiation stage after compilation and before simulation, used to control top-level instances, signal debugging visibility, assertion global switches, circuit hierarchy expansion, and timing back-annotation configurations. sim_opts is a set of control parameters for the simulation runtime phase, used to control runtime behaviors such as simulation duration, timeout exit, random seed passing, memory limits, and transaction log printing on / off.Coverage options include collection switches for control function coverage, code line coverage, condition coverage, and state machine coverage, as well as coverage data storage paths and merge coverage. These are used to quantify whether simulation testing has adequately tested the hardware code and product functional scenarios, and are core evaluation indicators for chip verification and delivery. Wave options refer to waveform storage options for control signals, specifying the dump level, dump format (VCD / FST / FSDB), waveform start and end times, and whether to store bus / UVM transaction waveforms. The SDF / corner option stores chip gate-level timing delay information. Corner refers to extreme chip manufacturing conditions (fast / slow process, high / low temperature, high / low voltage). Therefore, the SDF / corner option specifies the loaded SDF timing file and the selected process corner environment during timing simulation configuration. Tool version refers to the version of the simulator such as VCS / Xcelium / Questa. Different versions have different compilation and timing behaviors; the tool version must be locked when reproducing bugs. Git code branches refer to independent copies of the main codebase, created without altering the main codebase. These branches are used for modifying code, implementing features, and fixing bugs, and their code does not interfere with each other. Examples include development branches, release branches, and fix branches. A commit status refers to a unique commit hash value that is currently locked in the code. This hash accurately identifies all RTL / verification code versions at that moment, allowing for complete reproduction of the current simulation environment for version tracking and problem localization.

[0023] In step S202, at least one configuration factor in the valid configuration snapshot needs to be converted into a corresponding Boolean, enumerated, or numerical mixed feature vector according to its type. The conversion expression is as follows: (2) in, Represents the set of eigenvectors; Represents the simulation task; Indicates the configuration encoding function; This represents the eigenvector.

[0024] It is worth noting that different configuration factors may have different types, and therefore the feature vectors converted from configuration factors may also have different types. For example, depending on the type of configuration factor, it may be converted into a mixed feature vector of Boolean type, enumeration type and numerical type.

[0025] In step S102, based on the simulation results of each simulation task, a corresponding failure signature is generated if the simulation results indicate failure.

[0026] The simulation results may include the following states: PASS / FAIL criterion, simulation exit code, timeout status, and error pattern. Only the PASS status is considered a successful simulation, while the FAIL criterion, simulation exit code, timeout status, and error pattern are all considered simulation failures due to failure to pass the test. When a simulation fails, a failure label can be generated for each simulation task. This is to facilitate determining the reason for failure based on the failure label. Among them, ,exist A value of 1 indicates that the simulation task was successful; When the value is 0, it indicates that the simulation task has failed.

[0027] In one embodiment of this application, such as Figure 3 As shown, step S102 generates a corresponding failure signature based on the simulation results of each simulation task, in the case where the simulation results indicate failure, including steps S301 and S302: In step S301, the simulation results of each simulation task are obtained; In step S302, if the simulation result indicates failure, error information is extracted from the simulation task's running log, and a failure signature is formed based on the error information.

[0028] The error information includes at least the error category, the time of the first error, the UVM phase, the assertion identifier, the file line number, and the error information hash value.

[0029] The expression for the failed signature is as follows: (3) in, Indicates a failed signature; Indicates the error category; Indicates the time of the first error report; Indicates assertion identifier; Indicates the file line number; This represents the hash value of the error message.

[0030] In addition, in other embodiments, information such as the UVM phase can be added to the error message as needed. The above-described failure signature is merely an illustrative example to illustrate the inventive concept of this application and is not intended to limit the scope of protection of this application.

[0031] In this embodiment of the application, attribution analysis requires multiple regression simulation tests, meaning multiple test cases are needed for simulation. During each regression simulation, each test case has simulation and attribution options. It is necessary to analyze the reasons for test case simulation failures, or the reasons leading to the most frequent failures. For example, reasons for simulation failures include timeouts, failures, abnormal exits, and incorrect simulation options.

[0032] However, simulation failures can be categorized into true root causes and apparent failures (false failures, accompanying failures). True root causes are due to incorrect configuration factors, while apparent failures only occur simultaneously with error messages, exhibiting only statistical correlation and lacking causal relationship. What appears to be a failure caused by configuration factors is actually merely a distractor, hence the term "apparent failure." This application's embodiments record various error messages in the failure signature, enabling analysis of the failure cause or the most frequent cause of failure. This distinguishes between multiple simulation failures caused by the same configuration factor and apparent failures caused by different configuration factors, thus providing a more accurate analysis of the failure cause and preventing all failure samples from being confused.

[0033] For example, when determining whether a failure is of the same type, the number of error messages at each failure is used to determine whether it is a failure of the same type. If there are a total of 6 error messages, and 4 of the error messages are the same in the two simulation failures, it is considered to be a failure of the same type. If the number of error messages is different, it is considered to be a representation failure caused by different configuration factors.

[0034] Furthermore, a threshold for the number of items can be set. For example, if the threshold is 4, then 4 items or 4 items with the same error message are considered to be of the same type of failure.

[0035] In step S103, based on the failure signature, the mapping relationship between the simulation result and the at least one configuration factor is determined, and at least one candidate configuration factor is determined.

[0036] In this embodiment, the system no longer determines the cause of failure solely based on PASS / FAIL. Instead, it solidifies information such as error category, first error time, UVM phase, assertion identifier, file line number, and error message hash value in the failure log into a structured failure signature. This allows the system to identify whether multiple failures belong to the same type of failure, avoiding the mixing of failures caused by different mechanisms in the statistics, thereby improving the accuracy of candidate configuration factor screening and subsequent attribution ranking.

[0037] In one embodiment of this application, such as Figure 4As shown, step S103, which determines the mapping relationship between the simulation result and the at least one configuration factor based on the failure signature, and determines at least one candidate configuration factor, includes steps S401, S402, S403, and S404: In step S401, a defect tracing graph is established between simulation tasks, configuration factors, failure signatures, runtime logs, simulation results, and code versions; In step S402, the complete path of each failed sample from its original configuration to its execution process and then to its failure signature is traced back in reverse according to the defect tracing map. In step S403, based on the complete path, all configuration factors that cause each failed sample are determined; In step S404, based on all the configuration factors, the configuration factor that causes the number of failures of each failed sample to reach a preset number is determined as the candidate configuration factor.

[0038] The defect source map expression is as follows: (4) in, This represents a defect source mapping model; Represents the vertex set of test cases; Represents the vertex set of the running mode; Indicates the configuration template vertex set; Represents the set of vertices with additional parameters; Represents a random seed vertex set; Represents the set of vertices in the simulation log; Represents the vertex set of the signal waveform; Represents the vertex set of the code version; This represents a directed edge, which includes inheritance, overriding, splicing, execution, failure, and archiving relationships.

[0039] In other words, the defect tracing graph described above includes nodes such as Case, Mode, Profile, Option, FileList, Seed, Log, Signature, and Git, and edges include inheritance, overriding, concatenation, execution, failure, and archiving relationships. When using the defect tracing graph to determine the configuration factors causing simulation failure, when the user selects a candidate configuration factor for a failed sample, the graph can be traced backwards to find the complete path from the original configuration to the final command and then to the failure signature, marking the configuration factors causing the simulation failure along the path. Based on the number of failures caused by this configuration factor, candidate configuration factors are determined. For example, if the failure threshold is 5 times, then if the simulation fails 5 times, this configuration factor can be identified as a candidate configuration factor. A historical sample matrix is ​​then generated, and these candidate configuration factors are marked in the historical sample matrix.

[0040] Furthermore, these configuration factors can be sorted based on the number of times they cause failures, and the top N configuration factors can be selected as candidate configuration factors. For example, if N is 5, then the top 5 configuration factors are candidate configuration factors.

[0041] In this application embodiment, on the one hand, information originally scattered in testlists, profiles, command lines, logs and reports can be unified into a defect tracing map, solving the technical problem in traditional technologies that the source of simulation results cannot be traced; on the other hand, it can accurately determine which configuration factors are most suspicious from multiple configuration factors, reducing reliance on human experience and significantly shortening the initial debugging screening time.

[0042] In step S104, the failure contribution of each candidate configuration factor is calculated, and all candidate configuration factors are sorted according to the magnitude of the failure contribution.

[0043] The contribution of failure can be represented by the conditional probability difference for each candidate configuration factor. The conditional probability difference is a core statistical indicator for failure attribution; its value equals the failure conditional probability when the configuration factor is enabled minus the failure conditional probability when it is disabled. The conditional probability difference can be calculated based on failure signatures and used to quantify the strength of the influence of configuration parameters on the probability of failure occurrence.

[0044] In one embodiment of this application, such as Figure 5 As shown, step S104 calculates the failure contribution of each candidate configuration factor and sorts all candidate configuration factors according to the magnitude of the failure contribution, including steps S501 and S502: In step S501, the conditional probability difference for each candidate configuration factor is calculated; In step S502, all candidate configuration factors are sorted according to the numerical value of the conditional probability difference.

[0045] The expression for the failure contribution is as follows: ; (5) ; (6) in, Indicates the first The failure contribution of each candidate allocation factor; Indicates the label of the binary classification result; λ represents the conditional probability; λ represents the smoothing coefficient.

[0046] The embodiments of this application introduce a smoothing coefficient λ, which can avoid score oscillations under small sample conditions.

[0047] Furthermore, embodiments of this application can also calculate the confidence weights of candidate configuration factors to ensure the accuracy of the results. For example... Figure 6 As shown, step S104, which calculates the failure contribution of each candidate configuration factor and sorts all candidate configuration factors according to the magnitude of the failure contribution, also includes steps S601, S602, and S603: In step S601, the confidence weight of each candidate configuration factor is calculated; In step S602, the ranking weight is calculated based on the confidence weight, the fault severity weight, and the failure contribution. In step S603, all candidate configuration factors are sorted in descending order of their sorting weights.

[0048] The expression for the confidence weight is as follows: (7) in, Indicates the confidence weight; The expression for the ranking weight is as follows: (8) in, Indicates the sorting weight; Indicates the severity weight of the fault; Indicates the first The failure contribution of each candidate allocation factor; This represents the confidence weight.

[0049] The SeverityWeight here is used to increase the sorting weight of configuration factors that cause timeouts, fatalities, assertion failures, or failures of high-priority modules.

[0050] For example, when simulation results for a fixed seed frequently report errors, the seed's score (conditional probability difference) and confidence level will increase. Based on its ranking weight (RankScore), its ranking will also improve, and the top-ranked configuration factors can be marked as candidate configuration factors. The purpose of ranking is to determine which candidate configuration factors to target for validation. For example, a ranking validation threshold can be used, such as targeting the top 3 configuration factors for validation.

[0051] Furthermore, after determining which candidate configuration factors to target for validation, these factors need to be converted into one-hot factors. That is, using one-hot encoding, all configuration factors are converted into binary 0 / 1 one-hot factors. For example, a value of 1 for a candidate configuration factor indicates that the factor is enabled or effective; a value of 0 indicates that the factor is disabled or ineffective. In other words, candidate configuration factors must be independently controllable; each candidate configuration factor can be turned on or off independently while other parameters remain unchanged. This allows for individual targeted validation of each candidate configuration factor.

[0052] It is worth noting that candidate allocation factors may have different types, and different conversion methods are required when using the one-hot encoding method to transform candidate allocation factors.

[0053] For enumerated configurations, such as profile or mode, whose values ​​are a finite set of fixed options, they cannot be directly used in numerical statistics and probability calculations. Instead, they can be decomposed into mutually exclusive binary one-hot configuration factors based on all their possible enumerated values. For example, when the current task matches the value of profile or mode, the configuration factor is set to 1, and otherwise to 0. After converting these configuration factors into one-hot configuration factors, the enumerated options can be used as independent features in subsequent targeted validation.

[0054] For option-based configurations, such as compiler macros (+define macros), timing control, and parameter assignment options, there are no mutual exclusion constraints, and they can be enabled in any combination. Each independent compiler / simulation parameter is mapped to a binary independent configuration factor. The distribution of fault samples under each parameter's enabled scenario is statistically analyzed, and the correlation, causal confidence, and comprehensive ranking score are calculated independently to facilitate subsequent targeted verification.

[0055] For example, a configuration factor for multiple failed regression tasks might carry both the `+notimingchecks` and `+define+POST_SIM` parameters. These two parameters are not mutually exclusive; they can both be 1 or both be 0. In this case, the two parameters are not packaged into a single unit but scored separately. That is, the two parameters in this configuration factor are treated as two independent factors, meaning the configuration factor is decomposed into two independent one-hot factors. This facilitates the identification of the true root cause of the simulation failure in subsequent targeted validation.

[0056] Furthermore, since the calculation of ranking weights needs to consider whether it is more likely to lead to failure, whether the statistics are reliable, and whether the failure is severe, this application embodiment selects failure contribution, confidence weight, and fault severity weight to calculate the ranking weights. In this way, failure contribution can be used to represent the correlation strength between the configuration factor and the failure probability, confidence weight can be used to suppress the accidental high scores caused by small samples, and fault severity weight can be used to prioritize the handling of failures with greater impact, such as timeout, fatal, and assertion fail. This makes the ranking of the Top-N candidate configuration factors more stable and more in line with the screening principles.

[0057] In step S105, a predetermined number of candidate configuration factors at the top are targeted for verification, and an attribution report is generated based on the verification results.

[0058] In the process of determining candidate configuration factors, the RankScore can identify one or more candidate configuration factors. However, this only proves that these candidate configuration factors are strongly correlated with the cause of failure, but it cannot directly prove that these candidate configuration factors caused the failure, as they may only be accompanying factors and not the root cause. Therefore, it is necessary to verify each candidate configuration factor individually. That is, under the same conditions, set the candidate configuration factors to different values ​​and observe whether the simulation results are different. If there is a difference, it means that the candidate configuration factor is at work. After multiple verifications, the candidate configuration factors that truly caused the failure can be identified, and these candidate configuration factors can be written into the attribution report.

[0059] In one embodiment of this application, such as Figure 7 As shown, step S105 involves selecting a preset number of configuration factors with the highest ranking for targeted verification, including steps S701, S702, S703, S704, S705, and S706: In step S701, for each candidate configuration factor, the same random seed and the same test cases are used to execute the same simulation task in the same running mode, and when executing the same simulation task, only each candidate configuration factor is turned on or off; wherein, each candidate configuration factor has been converted into a one-hot factor through a one-hot encoding method; In step S702, it is determined whether the simulation result is flipped when each candidate configuration factor is turned on and off; if it is flipped, step S703 is executed; otherwise, step S704 is executed. In step S703, the order of each candidate configuration factor is placed at the top; In step S704, the order of each candidate configuration factor is placed last; In step S705, it is determined whether the verification of all candidate configuration factors has been completed; if so, step S706 is executed; otherwise, step S701 is returned to be executed to perform targeted verification of the next candidate configuration factor. In step S706, all candidate configuration factors that have been flipped are output.

[0060] If a fixed seed is not used during target verification, the random data packets will be different each time the simulation is performed, and the fault will occur intermittently, making it difficult to distinguish whether the error is caused by configuration or random stimulus. Therefore, a fixed seed needs to be used to lock the same random seed throughout the process to eliminate the interference caused by random stimulus.

[0061] With the same seed fixed, the random stimulus remains completely unchanged, and only the configuration to be verified changes, making the experimental variable unique. Then, for each Top-N candidate configuration, a separate round of comparative simulation is performed, without mixing them together for testing.

[0062] Specifically, flip the state of a configuration factor (on / off) and observe whether the failure label flips accordingly. When flipping the state of the configuration factor, switch the 0 / 1 state of the configuration factor a_j. For example, if the original state is a_j=1 and the simulation fails (label y=1), after flipping the original state, the configuration factor is turned off (a_j=0), and the simulation is re-run using the same fixed seed. If the label flips synchronously (y=0), it indicates a strong causal relationship between the configuration factor and the failure cause, meaning this configuration is directly the trigger for the failure, and the two are causally related; this configuration factor is the actual factor causing the simulation failure. If the label remains unchanged (y=1), it indicates that the configuration factor is merely correlated and has no real causal relationship. If the simulation task fails regardless of whether the configuration factor is on or off under the fixed seed, it indicates that the configuration factor only appears synchronously with the bug, is not the root cause, and is merely a distractor.

[0063] Each candidate factor has a validation state: unvalidated, validation flipped, and validation not flipped. After validating the current candidate configuration factor, the next round will only select candidate configuration factors with a validation state of "unvalidated" for validation.

[0064] It is worth noting that in this embodiment, simply marking the top few candidate configuration factors is insufficient. Therefore, it is also necessary to update the verification status and causal confidence of each candidate configuration factor. In other words, targeted verification of candidate configuration factors does not involve recalculating the attribution scores for all candidates, but rather updating the priority of the candidate queue.

[0065] For example, consider a candidate configuration factor called the fast process corner, where a_j=1 represents enabled and a_j=1 represents disabled. With the seed triggering the bug fixed at 888, and the fast process corner enabled, the simulation fails, with a failure label y=1. Reversing the fast process corner configuration factor (disabling it while keeping all other parameters unchanged, such as git code, compiler options, and seed=888) and re-simulating, the simulation succeeds, with a failure label y=0. If the fast process corner is then enabled again with a fixed seed, the simulation fails again. After multiple verifications, it can be determined that the fast process corner is the true cause of the simulation failure, and a causal relationship exists between the two. Therefore, the fast process corner is the actual configuration factor leading to the simulation failure.

[0066] The embodiments of this application can verify each candidate configuration factor obtained by automatic screening by using a control variable control experiment with a fixed random seed; only the enabled / disabled state of the target configuration is switched, while keeping the rest of the simulation environment completely consistent, and observe whether the simulation failure results are synchronously reversed, thereby distinguishing between statistical correlation and real causal relationship, and accurately locating the root cause of the failure.

[0067] Furthermore, after performing targeted validation and identifying the configuration factors that truly cause simulation failure, causal validation can be performed on the results. The expression for the causal validation gain is as follows:

[0068] in, Indicates configuration factor The causal verification gain; This means that while keeping the test cases, running mode, and random seed unchanged, only the configuration factor is switched. Then run the simulation again; Indicates simulation label The function changes from failure (FAIL) to success (PASS) or from success (PASS) to failure (FAIL); I[] represents an indicator function, which has a value of 1 when the condition is true and a value of 0 otherwise.

[0069] Causal validation gain is a metric that quantifies the improvement in diagnostic accuracy brought about by a univariate control experiment. It measures the difference in accuracy between the identified true root causes of failure after a targeted experiment. A causal validation gain of 1 indicates that the selected candidate configuration factor is accurate. This effectively filters out superficially failing configuration factors that only have statistical correlations, and accurately identifies the true configuration factors with genuine causal relationships.

[0070] In one embodiment of this application, such as Figure 8 As shown, step S105, which generates an attribution report based on the verification results, includes steps S801 and S802: In step S801, the verification result is written into the attribution report; In step S802, the attribution report is sent to the human-computer interaction interface for display.

[0071] The attribution report includes at least: attribution results, verification results, the complete path of the candidate configuration factor, and a recommended reproduction command.

[0072] In this embodiment of the application, candidate configuration factors determined based on the attribution results can be written into the attribution report, and configuration factors that actually cause simulation failure, obtained from targeted verification, can also be written into the attribution report; the complete path of the candidate configuration factors and the recommended reproduction command can also be written into the report.

[0073] The aforementioned recommended reproduction command refers to a complete set of simulation start instructions that the system automatically generates based on the fault tracing diagram and comparative experimental results. This set of instructions can be directly copied and executed and is specifically designed to reproduce the error scenario of the current failed sample. It integrates all the necessary reproduction conditions and is a one-click reproduction script / command recommended by the platform to the user.

[0074] Recommended reproduction commands can include the following fixed parameters: fixed seed, fixed target test cases, fixed run mode, complete compilation options (compile_opts, simulation parameters sim_opts), start / stop candidate configuration factors (automatically include verified fault cause configurations), code baseline locking (automatically associate with corresponding git branches and commit versions to prevent code changes from causing inability to reproduce), SDF process angle, waveform dump, coverage parameters, etc.

[0075] For example, when a user selects a failed sample, the system traces back along the defect source map (G_{lineage}) to extract all the original configurations. Combining the RankScore score and the experimental conclusions of the fixed seed comparison, the system forces the candidate configurations that have been verified to have a causal relationship into the command, eliminates irrelevant interference configurations, and generates the simplest, stable and reproducible complete simulation command, which is the recommended reproducibility command.

[0076] By including recommended reproduction commands in the attribution report, bugs can be reproduced reliably with a single click. Developers no longer need to manually piece together dozens of configuration parameters; instead, they can directly copy the command and run it on the server or local machine. Each time, the same assertion failure, the same waveform, and the same error message hash will be reproduced, helping developers accurately pinpoint the root cause. Moreover, the recommended reproduction command includes the core candidate configuration factors that triggered the failure. If these candidate configuration factors are removed before executing the recommended reproduction command, the error will no longer occur, allowing for direct verification of the causal relationship.

[0077] In one embodiment of this application, such as Figure 9 As shown, the method further includes: In step S901, a historical sample matrix is ​​established based on all complete paths corresponding to all failed samples; In step S902, the attribution results and target validation results are appended to the historical sample matrix to facilitate the next round of attribution analysis.

[0078] The historical sample matrix is ​​a two-dimensional feature matrix storing the encoded vectors of multi-round regression simulation tasks and success / failure labels. It serves as the underlying statistical data source for the fault attribution process. It is used to batch calculate the fault association scores of each configuration factor, screen candidate root causes, and distinguish pseudo-correlation co-occurrence relationships between configurations. Specifically, in step S402, when tracing the complete path of each failed sample from its original configuration to the execution process and then to the failure signature based on the defect source map, a historical sample matrix is ​​constructed, with each row representing a historical simulation task sample and each column corresponding to a configuration factor. This pre-marking of potential surface-failure configurations provides a candidate list for subsequent causal control experiments.

[0079] Then, after targeted validation of the candidate configuration factors—that is, after identifying the configuration factors that truly caused the simulation failure—these factors are added to the historical sample matrix based on their complete path. This allows them to be used for causal validation gain calculation in the next round of attribution analysis, providing global data support for reusing historical conclusions regarding similar failures.

[0080] Since many simulation failures are triggered by random stimuli, changing the seed resolves the issue. Therefore, in this embodiment, the same random seed is used to execute the simulation task during targeted verification; that is, a fixed seed is used. Specifically, a specific number is manually assigned as the random seed for this simulation, instead of using a randomly generated seed automatically by the simulator. All random data packets, random delays, and random constraint variables in UVM are calculated and generated by this fixed seed using a pseudo-random algorithm. The fixed seed generates exactly the same random stimulus sequence, ensuring that the same anomaly, the same set of random data packets, and the same timing waveform are reproduced each time the simulation task is executed. This allows for stable bug reproduction, facilitating defect localization and accurately identifying the configuration factors causing the simulation failure.

[0081] In addition, during targeted verification, the embodiments of this application also require the use of the same test cases and the execution of the same simulation task under the same operating mode to identify the configuration factor that caused the simulation failure. For example, by flipping a candidate configuration factor from on to off, if the simulation task execution changes from failure to success, it indicates that the failure was caused by the candidate configuration factor; if the simulation task still fails, it indicates that the candidate configuration factor is not the configuration factor that caused the simulation failure.

[0082] Furthermore, after identifying a specific configuration factor that truly caused the simulation failure... This configuration factor can be adjusted. The correct value is then used as the basis for the next round of regression testing, ultimately determining all the correct values. Configuration factors that cause simulation failures are identified, and closed-loop iteration is implemented.

[0083] Please note that the attribution method for chip verification provided in this application does not replace the original simulation execution engine. Instead, it adds a defect tracing and attribution analysis layer between regression task generation, execution, report archiving, and failure regression testing. By executing the attribution method for chip verification in this application, the attribution of simulation failures can be achieved.

[0084] The attribution method for chip verification in this application embodiment can quickly and accurately determine which configuration factors truly cause simulation failure from multiple configuration factors, greatly improving attribution efficiency and significantly shortening code debugging time.

[0085] In another embodiment of this application, the implementation process of the embodiments of this application is described in more detail. The test list defines multiple test cases, each of which can run in modes such as smoke, feature, regression, gls_zd, and gls_sdf; the profile file defines simulation modes such as RTL, gate-level zero latency, and gate-level SDF; the regression engine generates simulation tasks and performs regression execution based on the same case, mode, and seed. Figure 10 The diagram shown is a schematic flowchart of an attribution method 1000 for chip verification according to another embodiment of this application. Figure 10 The attribution method 1000 for chip verification includes steps S1001, S1002, S1003, S1004, S1005, S1006, S1007 and S1008.

[0086] In step S1001, configuration factors are collected and vectorized.

[0087] In this step, the effective configuration factors for each simulation task can be obtained by parsing the testlist, profile files, GUI temporary configurations, and command-line arguments, as well as expanding case, mode, profile, filelist, compile options, elab options, and simoptions.

[0088] In step S1002, based on the effective configuration factor and task parameters of each simulation task, a task_manifest is generated for each simulation task, recording its case, mode, profile, seed, compile / elab / sim options, filelist, SDF / corner, coverage / wave switch, git commit, and tool version, etc.

[0089] In step S1003, the execution results of the simulation task are collected, and failure labels are generated based on the failed execution results. That is, based on the collected simulation execution results, PASS / FAIL labels, timeout status, exit code, failure seed, logpath, and the maximum simulation runtime threshold max_sim_time are generated.

[0090] In step S1004, for failed tasks, the failure log is scanned, and error_type, first_error_time, UVM phase, assertion name, file line number and message_hash are extracted to generate a failure signature sig_i.

[0091] In step S1005, a historical sample matrix and a defect tracing graph are generated. This involves merging historical multiple rounds of regression reports, task_manifests, and failure log signatures to construct a historical sample matrix X and a label vector y, and establishing a defect tracing graph among case, mode, profile, option, seed, log, signature, and git commit.

[0092] In step S1006, the defect source map is scored to obtain candidate configuration factors, which are then ranked to determine the top N candidate configuration factors. The system calculates Score, Confidence, and RankScore for each configuration factor (the calculation method can be found above) to obtain the Top-N candidate configuration factors, and outputs the complete path of the corresponding simulation task execution results to facilitate source tracing.

[0093] In step S1007, targeted validation is performed on each candidate configuration factor based on a fixed seed. That is, a fixed seed control experiment is generated based on the Top-N candidate configuration factors. While keeping the case and seed unchanged, the specified configuration factor is switched or removed, and it is verified whether the failure results are reversed.

[0094] In step S1008, an attribution report is generated and displayed. This involves writing the attribution results, candidate factor ranking, failure signatures, evidence paths, control experiment results, and recommended reproduction commands into the attribution report and displaying it in a GUI or web page.

[0095] For example, suppose that in a regression test, 20 tasks fail, 18 of which run on profile=gls_sdf and include +define+POST_SIM and hdl_filelist=netlist_ss.f; while in the RTL profile, the same case and seed combination does not fail. Then, after constructing the historical sample matrix, it can be calculated according to the above formulas (5) and (6): Score(profile=gls_sdf)=P(fail|gls_sdf)-P(fail|not gls_sdf) Score(+define+POST_SIM)=P(fail|POST_SIM)-P(fail|not POST_SIM) If the above configuration factor scores high and the confidence weight meets the threshold, it is listed as a Top-N candidate configuration factor, and a fixed seed control experiment is further generated. That is, the case and seed are kept unchanged, and the mode is switched from gls_sdf to gls_zd or POST_SI is removed. The M macro. If the failure disappears, the system increases the causal confidence of this factor and suggests in the report to prioritize checking the SDF injection path, the POST_SIM conditional compilation branch, and the corner corresponding to netlist_ss.f.

[0096] This application also provides an attribution device for chip verification, such as... Figure 11 As shown, the attribution device 1100 for chip verification in this embodiment of the application includes an acquisition module 1101, a signature module 1102, a mapping module 1103, a sorting module 1104, and a verification module 1105: The acquisition module 1101 is used to acquire at least one pre-configured configuration factor before each simulation task runs, and to vectorize the at least one configuration factor. The signature module 1102 is used to generate a corresponding failure signature when the simulation result indicates failure, based on the simulation result of each simulation task. The mapping module 1103 is used to determine, based on the failure label, the mapping relationship between the simulation result and the at least one configuration factor, and to determine at least one candidate configuration factor; The sorting module 1104 is used to calculate the failure contribution of each candidate configuration factor and sort all candidate configuration factors according to the magnitude of the failure contribution. The verification module 1105 is used to select a preset number of candidate configuration factors with the highest ranking for targeted verification and generate an attribution report based on the verification results.

[0097] This application's embodiments can run on chip verification server environments such as Linux and CentOS, as well as on configuration analysis clients on systems such as MAC OS or Windows. It can interface with Synopsys VCS, Verdi, DVE, UVM regression systems, JSON / JSON5 / YAML testlists, coverage databases, and enterprise internal HTTP reporting platforms.

[0098] This application's embodiments can be used as a post-processing analysis module for existing DV simulation tools, or integrated into a GUI as buttons for Failure Attribution, Root Cause Ranking, and Explain Failure. Its core functionality does not depend on specific EDA vendor command formats; as long as the task configuration, execution results, and log paths are available, root cause attribution can be completed.

[0099] The following is combined Figure 12 The computing system 1200 of this application is described, wherein, Figure 12 A schematic block diagram of a computing system 1200 according to an embodiment of this application is shown.

[0100] like Figure 12As shown, the computing system 1200 includes: a non-transitory memory 1201 storing instructions and one or more processors 1202, which, when executed by the one or more processors, configure the one or more processors to execute instructions including the following: Before each simulation task runs, at least one of its pre-configured configuration factors is obtained, and the at least one configuration factor is vectorized. Based on the simulation results of each simulation task, if the simulation results indicate failure, a corresponding failure signature is generated; Based on the failure label, the mapping relationship between the simulation result and the at least one configuration factor is determined, and at least one candidate configuration factor is identified; Calculate the failure contribution of each candidate configuration factor, and sort all candidate configuration factors according to the magnitude of the failure contribution. Select a preset number of candidate configuration factors with the highest rankings for targeted validation, and generate an attribution report based on the validation results.

[0101] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, the computer-readable storage medium including instructions that, when executed by a computer, cause the computer to: Before each simulation task runs, at least one of its pre-configured configuration factors is obtained, and the at least one configuration factor is vectorized. Based on the simulation results of each simulation task, if the simulation results indicate failure, a corresponding failure signature is generated; Based on the failure label, the mapping relationship between the simulation result and the at least one configuration factor is determined, and at least one candidate configuration factor is identified; Calculate the failure contribution of each candidate configuration factor, and sort all candidate configuration factors according to the magnitude of the failure contribution. Select a preset number of candidate configuration factors with the highest rankings for targeted validation, and generate an attribution report based on the validation results.

[0102] The computing system and non-transitory computer-readable storage medium of this application embodiment have the same advantages as the aforementioned attribution method for chip verification because they are able to implement the attribution method for chip verification described above.

[0103] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of this application. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of this application. All such changes and modifications are intended to be included within the scope of this application as claimed in the appended claims.

[0104] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0105] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0106] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0107] Similarly, it should be understood that, in order to streamline this application and aid in understanding one or more of the various inventive aspects, features of this application may sometimes be grouped together in a single embodiment, figure, or description thereof in the description of exemplary embodiments of this application. However, this approach should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the corresponding claims, its inventive point lies in solving the corresponding technical problem with features fewer than all features of a single disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0108] Those skilled in the art will understand that, apart from the mutual exclusion of features, all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or elements of any method or apparatus so disclosed may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0109] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the claims, any one of the claimed embodiments can be used in any combination.

[0110] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules according to the embodiments of this application. This application can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0111] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0112] The above description is merely a specific embodiment or illustration of the embodiments of this application. The scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. The scope of protection of this application shall be determined by the scope of the claims.

Claims

1. An attribution method for chip verification, characterized in that, The method includes: Before each simulation task runs, at least one of its pre-configured configuration factors is obtained, and the at least one configuration factor is vectorized. Based on the simulation results of each simulation task, if the simulation results indicate failure, a corresponding failure signature is generated; Based on the failure signature, determine the mapping relationship between the simulation result and the at least one configuration factor, and determine at least one candidate configuration factor; Calculate the failure contribution of each candidate configuration factor, and sort all candidate configuration factors according to the magnitude of the failure contribution. Select a preset number of candidate configuration factors with the highest rankings for targeted validation, and generate an attribution report based on the validation results.

2. The attribution method according to claim 1, characterized in that, Obtain at least one configuration factor pre-configured for each simulation task before execution, and vectorize the at least one configuration factor, including: Before each simulation task runs, record a snapshot of its valid configuration. Based on the type of at least one configuration factor in the effective configuration snapshot, the at least one configuration factor is converted into a corresponding Boolean, enumerated, or numerical mixed feature vector: The effective configuration snapshot includes at least the following: simulation project, module under test, test cases, running mode, environment configuration profile, random seed, UVM top-level test case name, hardware description file list, high-level verification language file list, compilation parameters, simulation build parameters, simulation running parameters, coverage configuration parameters, waveform dump configuration parameters, standard delay file and process corner, simulation tool version number, git code branch and commit snapshot status. The expression for the simulation task is as follows: in, Represents a set of simulation tasks; Represents a set of test cases; A collection representing patterns; Represents a set of seeds; Represents a set of compiler options; Represents the set of elaboration options; Represents a set of simulation options; This represents a collection of filelist, profile, and SDF file-based configurations. This represents a collection of code versions and tool environments.

3. The method according to claim 1, characterized in that, Based on the simulation results of each simulation task, if the simulation results indicate failure, a corresponding failure signature is generated, including: Obtain the simulation results for each simulation task; If the simulation result indicates failure, error information is extracted from the simulation task's runtime log, and a failure signature is generated based on the error information; wherein, the error information includes at least the error category, the first error reporting time, the assertion identifier, the file line number, and the error information hash value; The expression for the failed signature is as follows: in, Indicates a failed signature; Indicates the error category; Indicates the time of the first error report; Indicates an assertion identifier; Indicates the file line number; This represents the hash value of the error message.

4. The method according to claim 1, characterized in that, Based on the failure signature, determine the mapping relationship between the simulation result and the at least one configuration factor, and determine at least one candidate configuration factor, including: Establish a defect tracing graph connecting simulation tasks, configuration factors, failure signatures, runtime logs, simulation results, and code versions; Based on the defect tracing map, the complete path of each failed sample from its original configuration to its execution process and finally to its failure signature can be traced in reverse. Based on the complete path, determine all configuration factors that caused each failed sample to fail; Based on all the configuration factors, the configuration factor that causes the number of failures of each failed sample to reach a preset number is determined as the candidate configuration factor; The defect source map expression is as follows: in, This represents a defect source mapping model; Represents the vertex set of test cases; Represents the vertex set of the running mode; Indicates the configuration template vertex set; Represents the set of vertices with additional parameters; Represents a random seed vertex set; Represents the set of vertices in the simulation log; Represents the vertex set of the signal waveform; Represents the vertex set of the code version; This represents a directed edge, which includes inheritance, overriding, splicing, execution, failure, and archiving relationships.

5. The method according to claim 1, characterized in that, Calculate the failure contribution of each candidate configuration factor, and sort all candidate configuration factors according to the magnitude of the failure contribution, including: Calculate the conditional probability difference for each candidate configuration factor; All candidate configuration factors are sorted according to the magnitude of the conditional probability difference. The expression for the failure contribution is as follows: ； ； in, Indicates the first The failure contribution of each candidate allocation factor; Indicates the label of the binary classification result; λ represents the conditional probability; λ represents the smoothing coefficient.

6. The method according to claim 5, characterized in that, Calculating the failure contribution of each candidate configuration factor, and ranking all candidate configuration factors according to the magnitude of the failure contribution, further includes: Calculate the confidence weight for each candidate configuration factor; The ranking weight is calculated based on the confidence weight, the fault severity weight, and the failure contribution. All candidate configuration factors are sorted in descending order according to their sorting weights; The expression for the confidence weight is as follows: in, Indicates the confidence weight; The expression for the ranking weight is as follows: in, Indicates the sorting weight; Indicates the severity weight of the fault; Indicates the first The failure contribution of each candidate allocation factor; This represents the confidence weight.

7. The method according to claim 1, characterized in that, Select the top-ranked preset number of configuration factors for targeted validation, including: For each candidate configuration factor, the same random seed and the same test cases are used, and the same simulation task is executed in the same running mode. When executing the same simulation task, each candidate configuration factor is either turned on or off. Each candidate configuration factor has been converted into a one-hot factor using a one-hot encoding method. If the execution result is reversed, the order of each candidate configuration factor is placed at the front; Otherwise, the order of each candidate configuration factor is placed last, and the next candidate configuration factor is targeted for verification until the verification of all candidate configuration factors is completed. Output all candidate configuration factors that have been flipped.

8. The method according to claim 1, characterized in that, Generate an attribution report based on the validation results, including: Write the verification results into the attribution report; The attribution report is sent to the human-computer interaction interface for display. The attribution report includes at least: attribution results, verification results, the complete path of the candidate configuration factor, and a recommended reproduction command.

9. The method according to claim 1, characterized in that, The method further includes: A historical sample matrix is ​​built based on all complete paths corresponding to all failed samples. The attribution results and target validation results are appended to the historical sample matrix to facilitate the next round of attribution analysis.

10. A computing system, characterized in that, The computing system includes: One or more processors; as well as Non-transitory memory storing instructions that, when executed by one or more processors, configure the one or more processors to execute instructions including the following: Before each simulation task runs, at least one of its pre-configured configuration factors is obtained, and the at least one configuration factor is vectorized. Based on the simulation results of each simulation task, if the simulation results indicate failure, a corresponding failure label is generated; Based on the mapping relationship between the simulation results and the at least one configuration factor, at least one candidate configuration factor is determined; Calculate the failure contribution of each candidate configuration factor, and sort all candidate configuration factors according to the magnitude of the failure contribution. Select a preset number of candidate configuration factors with the highest rankings for targeted validation, and generate an attribution report based on the validation results.

11. A non-transitory computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed by a computer, cause the computer to: Before each simulation task runs, at least one of its pre-configured configuration factors is obtained, and the at least one configuration factor is vectorized. Based on the simulation results of each simulation task, if the simulation results indicate failure, a corresponding failure label is generated; Based on the mapping relationship between the simulation results and the at least one configuration factor, at least one candidate configuration factor is determined; Calculate the failure contribution of each candidate configuration factor, and sort all candidate configuration factors according to the magnitude of the failure contribution. Select a preset number of candidate configuration factors with the highest rankings for targeted validation, and generate an attribution report based on the validation results.

Images