Chip debugging method, device and server

Abstract

The application relates to a chip debugging method, device and server. The method comprises the following steps: obtaining a plurality of simulation test cases for a chip; in the case that a running error occurs in the process of running the plurality of simulation test cases, obtaining log information corresponding to the running error; analyzing the log information to determine a target defect type existing in the chip and a target simulation test case corresponding to the target defect; the target defect comprises at least one type of defect; and waveform information corresponding to the target simulation test case is generated to debug the chip according to the waveform information. The verification debugging period is shortened, and the chip debugging efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a chip debugging method, apparatus and server. Background Technology

[0002] As chip design complexity continues to increase, functional verification has become a crucial step in ensuring the correctness and reliability of chip designs, and its efficiency and effectiveness directly affect the final quality of the chip. Simulation verification, as a mainstream dynamic verification method, simulates the behavior of the chip in real-world scenarios by running a large number of test cases. However, with the growth in verification scale and the acceleration of design iterations, traditional simulation verification methods face severe challenges in resource management, error debugging, and verification strategy optimization, often leading to low utilization of computing resources, difficulty in problem localization, and extended overall verification cycles.

[0003] In traditional techniques, debugging is done manually based on error patterns that appear in simulation tests, which results in low debugging efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a chip debugging method, device, and server that can improve debugging efficiency in response to the above-mentioned technical problems.

[0005] In a first aspect, this application provides a chip debugging method, the method comprising:

[0006] Obtain multiple simulation test cases for the chip;

[0007] If a runtime error occurs during the execution of the multiple simulation test cases, obtain the log information corresponding to the runtime error;

[0008] The log information is analyzed to determine the type of target defect present in the chip and the corresponding target simulation test case; the target defect includes at least one type of defect;

[0009] The waveform information corresponding to the target simulation test case is generated so as to debug the chip based on the waveform information.

[0010] In one embodiment, analyzing the log information to determine the target defect type of the chip and the target simulation test case corresponding to the target defect includes:

[0011] Feature extraction is performed on the log information to obtain the feature information of the log information;

[0012] The feature information is analyzed and clustered based on a preset defect analysis model and a preset defect database to determine at least one type of target defect in the chip; the defect database includes descriptive information for multiple defect types.

[0013] Based on each of the target defect types, at least one target simulation test case corresponding to each target defect type is determined from the plurality of simulation test cases.

[0014] In one embodiment, determining at least one target simulation test case corresponding to each target defect type from the plurality of simulation test cases based on each target defect type includes:

[0015] For each of the target defect types, determine the corresponding candidate simulation test cases;

[0016] Based on the number of candidate simulation test cases, the number of target simulation test cases is determined, and based on the number of target simulation test cases, at least one target simulation test case corresponding to the target defect type is determined from the candidate simulation test cases.

[0017] In one embodiment, the method further includes:

[0018] The target defects and their corresponding test cases that do not exist in the defect database are stored in a preset storage location, so as to update the defect database according to the target defects and their corresponding test cases.

[0019] In one embodiment, the method further includes:

[0020] Based on a preset feature extraction model, features are extracted from the multiple simulation test cases to determine the predicted simulation time and predicted resource requirements for each simulation test case.

[0021] Based on the predicted simulation time and predicted resource consumption of each simulation test case, the simulation priority of each simulation test case is determined.

[0022] Each simulation test case is run according to its simulation priority.

[0023] In one embodiment, determining the simulation priority of each simulation test case based on the predicted simulation time and predicted resource consumption of each simulation test case includes:

[0024] The initial priority of each simulation test case is determined based on the predicted simulation time and predicted resource consumption of each simulation test case.

[0025] The initial priority is adjusted according to the preset regression strategy to determine the simulation priority of each simulation test case.

[0026] In one embodiment, running each simulation test case according to its simulation priority includes:

[0027] Get the current resource utilization rate;

[0028] The number of runnable use cases is determined based on the resource utilization rate;

[0029] Each simulation test case is run according to the number of runnable test cases and the simulation priority of each simulation test case.

[0030] In one embodiment, the defect analysis model is a large language model.

[0031] Secondly, this application also provides a chip debugging apparatus, comprising:

[0032] The first acquisition module is used to acquire multiple simulation test cases for the chip;

[0033] The second acquisition module is used to acquire log information corresponding to the execution error when an execution error occurs during the running of the multiple simulation test cases;

[0034] The analysis module is used to analyze the log information to determine the type of target defect present in the chip and the target simulation test case corresponding to the target defect; the target defect includes at least one type of defect;

[0035] The debugging module is used to generate waveform information corresponding to the target simulation test case, so as to debug the chip based on the waveform information.

[0036] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0037] Obtain multiple simulation test cases for the chip;

[0038] If a runtime error occurs during the execution of the multiple simulation test cases, obtain the log information corresponding to the runtime error;

[0039] The log information is analyzed to determine the type of target defect present in the chip and the corresponding target simulation test case; the target defect includes at least one type of defect;

[0040] The waveform information corresponding to the target simulation test case is generated so as to debug the chip based on the waveform information.

[0041] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0042] Obtain multiple simulation test cases for the chip;

[0043] If a runtime error occurs during the execution of the multiple simulation test cases, obtain the log information corresponding to the runtime error;

[0044] The log information is analyzed to determine the type of target defect present in the chip and the corresponding target simulation test case; the target defect includes at least one type of defect;

[0045] The waveform information corresponding to the target simulation test case is generated so as to debug the chip based on the waveform information.

[0046] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0047] Obtain multiple simulation test cases for the chip;

[0048] If a runtime error occurs during the execution of the multiple simulation test cases, obtain the log information corresponding to the runtime error;

[0049] The log information is analyzed to determine the type of target defect present in the chip and the corresponding target simulation test case; the target defect includes at least one type of defect;

[0050] The waveform information corresponding to the target simulation test case is generated so as to debug the chip based on the waveform information.

[0051] The aforementioned chip debugging method, apparatus, and server acquire multiple simulation test cases for the chip; when runtime errors occur during the execution of these simulation test cases, they acquire the corresponding log information; they analyze the log information to determine the target defect type and the corresponding target simulation test case; the target defect includes at least one type of defect; and they generate waveform information corresponding to the target simulation test case for chip debugging. By acquiring log information when errors occur during simulation test case execution, the target defect type and the target simulation test case that triggered the defect are located, and corresponding key waveform information is generated, thus achieving a closed loop from error occurrence to debugging. This integrates the traditional manual review of massive logs and scattered debugging steps into a coherent analysis process, improving the accuracy and speed of defect location and providing intuitive debugging criteria, thereby shortening the verification and debugging cycle and improving chip debugging efficiency. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies 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.

[0053] Figure 1 This is a diagram illustrating the application environment of a chip debugging method in one embodiment;

[0054] Figure 2 This is a flowchart illustrating a chip debugging method in one embodiment;

[0055] Figure 3 This is a flowchart illustrating a chip debugging method in another embodiment;

[0056] Figure 4 This is a flowchart illustrating a chip debugging method in another embodiment;

[0057] Figure 5 This is a flowchart illustrating a chip debugging method in another embodiment;

[0058] Figure 6 This is a flowchart illustrating a chip debugging method in another embodiment;

[0059] Figure 7 This is a flowchart illustrating a chip debugging method in another embodiment;

[0060] Figure 8 This is a schematic diagram of the architecture of the second server in one embodiment;

[0061] Figure 9This is a flowchart illustrating a chip debugging method in another embodiment;

[0062] Figure 10 A flowchart illustrating the chip debugging method in another embodiment;

[0063] Figure 11 This is a structural block diagram of a chip debugging device in one embodiment;

[0064] Figure 12 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0066] The chip debugging method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, the first server 102 communicates with the second server 104 via a network. A data storage system can store the data that the second server 104 needs to process. The data storage system can be integrated onto server 104 or placed in the cloud or on another network server. The second server 104 obtains multiple simulation test cases for the chip from the first server 102, runs these test cases, and determines and debugs the chip based on the simulation test results. The first server 102 can be implemented using a standalone server or a server cluster consisting of multiple servers; the second server 104 can also be implemented using a standalone server or a server cluster consisting of multiple servers.

[0067] In one embodiment, such as Figure 2 As shown, a chip debugging method is provided, which can be applied to... Figure 1 The second server in the example is used for illustration, including:

[0068] S201, obtain multiple simulation test cases for the chip.

[0069] In this embodiment of the application, multiple simulation test cases for the chip are obtained from a first server, wherein the first server can be a verification management platform, a version control system, etc.

[0070] Optionally, simulation test cases can be written by verification engineers and can cover chip-specific functional points, interface protocols, or performance boundaries.

[0071] Optionally, the second server may parse the metadata of each simulation test case, such as the pre-defined complexity tags, historical average runtime, and the simulation environment configuration it depends on. Furthermore, a dynamic resource scheduling algorithm is executed to allocate appropriate computing resources to each simulation test case, allowing multiple simulation test cases to run.

[0072] S202: When a runtime error occurs during the execution of multiple simulation test cases, obtain the log information corresponding to the runtime error.

[0073] In this embodiment, after the simulation job begins execution, the running status of all simulation test cases is continuously monitored. When a simulation test case reports a running error due to triggering an error condition in the chip design, an error response and information collection process is triggered to capture the log file of that simulation test case. Optionally, the error condition may include functional assertion failure, protocol checker alarm, or simulation timeout, etc.

[0074] Optionally, the log information may include the execution content of the simulation test case, the precise time point of the simulation failure, snapshots of the values ​​of key signals and registers, the current code coverage status, and a complete record of all relevant hardware assertion triggers.

[0075] S203, Analyze log information to determine the type of target defect present in the chip and the target simulation test case corresponding to the target defect; the target defect includes at least one type of defect.

[0076] In this embodiment, server log information is analyzed and identified. For example, by analyzing error characteristics, abnormal signal sequences, and related assertion conditions, the cause of the operational error is determined, i.e., the target defect type in the chip. For example, the target defect type can be a logic function error, timing violation, or interface protocol violation. Simultaneously, simulation test cases corresponding to the target defect type are associated, and these associated simulation test cases are identified as target simulation test cases.

[0077] S204 generates waveform information corresponding to the target simulation test case, so as to debug the chip based on the waveform information.

[0078] In this embodiment, for a determined target simulation test case, the complete waveform data of the test case within the time window in which the error occurred is retrieved or re-extracted from the simulation result database. Further, the server can process and analyze the waveform data, generating a structured waveform information report based on signals related to the target defect type. For example, the waveform information report may include signal transitions before and after defect triggering, timing relationships establishing hold-time violations, or error sequences in protocol interactions, thereby providing debugging personnel with a basis for debugging. Optionally, debugging personnel can debug and correct the chip design code based on the waveform information.

[0079] The aforementioned chip debugging method involves acquiring multiple simulation test cases for the chip; when errors occur during the execution of these simulation test cases, obtaining the corresponding log information; analyzing the log information to determine the target defect type and the corresponding target simulation test case; the target defect includes at least one type of defect; and generating waveform information corresponding to the target simulation test case for chip debugging. By acquiring log information when errors occur during simulation test case execution, the target defect type and the target simulation test case that triggered the defect are located, and corresponding key waveform information is generated, thus achieving a closed loop from error occurrence to debugging. This integrates the traditional manual review of massive logs and scattered debugging steps into a coherent analysis process, improving the accuracy and speed of defect location and providing intuitive debugging basis, thereby shortening the verification and debugging cycle and improving chip debugging efficiency.

[0080] In one embodiment, one implementation of the above-described S204 is provided, such as... Figure 3 As shown, the above-mentioned "obtaining the debugging parameters corresponding to the target defect from the database and debugging the chip based on the debugging parameters" includes:

[0081] S301, extract features from the log information to obtain the feature information of the log information.

[0082] In this embodiment, the acquired log information can be preprocessed, including cleaning irrelevant entries, standardizing timestamp formats, parsing hierarchical error messages, and normalizing various signal identifiers. Further, based on a preset feature extraction model or logic, feature extraction is performed on the log information to obtain its feature information.

[0083] Optionally, the feature extraction logic may include a target field, thereby enabling the extraction of feature information from log information based on the target field. For example, the feature information may include the classification code of the error event, the level and transition sequence of signals before and after the error occurs, the triggering logic conditions of related assertion statements, the protocol compliance status word of the bus transaction, and the configuration snapshot of the simulation environment.

[0084] S302, based on a preset defect analysis model and a preset defect database, analyzes and clusters feature information to determine at least one type of target defect in the chip; the defect database includes descriptive information for multiple defect types.

[0085] The preset defect analysis model can be an artificial intelligence model trained with chip defect data to perform defect diagnosis; the preset defect database includes detailed descriptions of various defect types, and the descriptions of each defect type include its corresponding feature patterns.

[0086] In this embodiment of the application, feature information is input into a preset defect analysis model. The defect analysis model performs deep computation on the input feature information. By analyzing the complex correlations and hidden patterns between the dimensions within the feature information, and performing distributed matching and clustering computation with the description information of multiple defect types stored in the preset defect database, at least one defect type with the highest matching degree with the current feature information is identified, namely the target defect type.

[0087] Optionally, structured feature dimensions for analysis can be extracted from each group of records first. These dimensions include, but are not limited to, the explicit error type of the defect, the specific design module involved, the abnormal pattern in the signal waveform, and the excitation scenario and configuration of the simulation test case. Then, the unsupervised clustering algorithm deployed in the model is called to calculate the multidimensional similarity between all records based on the above feature dimensions. Based on the algorithm rules, defect records with highly similar features are automatically aggregated and merged to obtain several different defect classifications, each representing a potentially common fault mode.

[0088] Optionally, the defect analysis model is a large language model. The large language model can first understand the error context, signal behavior semantics, and state transition logic contained in the feature information, and then, based on its extensive knowledge of chip design defects, combined with the defect types stored in the pre-set defect database, it can infer the most likely defect category that leads to the systemic anomaly, i.e., the target defect type.

[0089] S303, based on each target defect type, determine at least one target simulation test case corresponding to each target defect type from multiple simulation test cases.

[0090] In this embodiment, for each target defect type, multiple simulation test cases that trigger the target defect type during simulation are selected, and at least one target simulation test case corresponding to each target defect type is determined from the multiple simulation test cases. Optionally, a simulation test case can be randomly selected from the multiple simulation test cases of the target defect type as the target simulation test case.

[0091] Optional, such as Figure 4 As shown, the above chip debugging method also includes:

[0092] S304, store the target defect and its corresponding test case that do not exist in the defect database to a preset storage location, so as to update the defect database according to the target defect and its corresponding test case.

[0093] In this embodiment, when the target defect does not exist in the defect database, an archiving and storage operation for new defect information is performed. The target defect generated in this analysis, the simulation test case that caused the defect, and the log information of the simulation test case's execution error are associated and encapsulated to form a data packet, which is then stored in a preset storage location. Optionally, a status flag and timestamp can be generated for this data packet to indicate that the data packet is in a state awaiting further analysis and summarization, thereby providing accurate raw data for subsequent updates and expansions of the defect knowledge database.

[0094] Optionally, for each defect category, the internally integrated Large Language Model (LLM) is first invoked. Combining the feature similarity grouping provided by the clustering results, semantic analysis and logical deduction are performed on all simulation test cases that trigger defects within each group. By understanding the stimulus scenarios of the simulation test cases, the deep semantics of the error logs, and the temporal context of the defect occurrence, one or a few of the most representative simulation test cases that can cover and represent the main failure modes of that category are selected and identified as typical defect cases. Furthermore, based on the textual analysis conclusions of the Large Language Model on the root causes of failures, structured defect description information can be generated to clearly explain the reasons for typical defects.

[0095] Optionally, by replaying and analyzing the simulation process of typical defect cases, typical error waveform segments, key signal transition sequences, and environmental state snapshots with high reference value can be extracted and generated, and used as the core components of debugging parameters.

[0096] In the above application embodiments, log information is transformed into categorized defect diagnosis results and test case associations, realizing automated closed-loop analysis, reducing the workload of manual investigation and repeated debugging, and improving the efficiency of defect location and the targeting of debugging.

[0097] In one embodiment, one implementation of S303 above is provided, such as... Figure 5 As shown, the above-mentioned "determining at least one target simulation test case corresponding to each target defect type from multiple simulation test cases based on each target defect type" includes:

[0098] S401, for each target defect type, determine the candidate simulation test cases corresponding to the target defect type.

[0099] In this embodiment, for each target defect type, candidate simulation test cases are determined by filtering based on the correlation data of the preset defect analysis model during the analysis process, as well as the historical records and log information of the simulation task. For example, simulation test cases where the stimulus scenario, running path, or state transition during simulation operation has a correlation or temporal intersection with the triggering conditions of the target defect type are identified as candidate simulation test cases for that target defect type.

[0100] S402, determine the number of target simulation test cases based on the number of candidate simulation test cases, and determine at least one target simulation test case corresponding to the target defect type from the candidate simulation test cases based on the number of target simulation test cases.

[0101] In this embodiment, the number of candidate simulation test cases corresponding to each target defect type is first determined. Then, based on a preset quantity-based selection strategy, the target number of target simulation test cases to be selected from the candidate simulation test cases is determined. Further, the target number of test cases is randomly selected from the candidate simulation test cases as target test cases. For example, the number of target simulation test cases can be determined based on a preset ratio and the number of candidate simulation test cases; or, the number of target simulation test cases can be determined based on the correspondence between a preset quantity range and the target quantity.

[0102] The above-mentioned application embodiments avoid the waste of resources caused by including too many test cases in the debugging scope, and avoid the risk of missing defects due to insufficient test case coverage, thereby improving the reliability of subsequent debugging operations and the efficiency of resource utilization.

[0103] In one embodiment, such as Figure 6 As shown, the above chip debugging method also includes:

[0104] S501, based on a preset feature extraction model, performs feature extraction on multiple simulation test cases to determine the predicted simulation time and predicted resource consumption for each simulation test case.

[0105] In this embodiment, for each simulation test case to be simulated, a preset feature extraction model is first invoked. This model reads the source code, configuration parameters, and historical running data of the simulation test case, and extracts key features affecting simulation efficiency. These features include, but are not limited to, the code complexity of the test case, the length of the stimulus sequence, the number of assertions, the number of covered targets, and the historical average simulation time. Further, based on the extracted feature vectors, a preset prediction model is used to calculate and output the predicted simulation time and predicted resource consumption for each simulation test case. The predicted resource consumption may include the estimated number of CPU cores, memory capacity, and storage I / O bandwidth required.

[0106] Optionally, the feature extraction model can be a deep learning model based on a Long Short-Term Memory (LSTM) network or a Transformer architecture.

[0107] S502, determine the simulation priority of each simulation test case based on the predicted simulation time and predicted resource consumption of each simulation test case.

[0108] In this embodiment, the server has a pre-defined dynamic priority determination rule. This rule is based on predicted simulation time, predicted resource consumption, and pre-defined functional importance labels or risk levels for the test cases. For each simulation test case, the predicted simulation time and predicted resource consumption are substituted into the determination rule for comprehensive calculation, and a quantified simulation priority is assigned to each simulation test case. The calling order of the simulation test cases is then determined according to the priority. For example, simulation test cases with higher simulation priority scores are called first.

[0109] For example, prioritization rules may include a preference for completing short-term tasks first in order to quickly free up resources.

[0110] S503 runs each simulation test case according to its simulation priority.

[0111] In this embodiment, the simulation test case list is sorted in descending order of simulation priority. Based on this order and the real-time resource utilization of each computing node in the second server, the simulation test cases are dynamically allocated and submitted to the most suitable computing node or job queue. Furthermore, the server monitors and initiates the actual simulation execution of these test cases on the allocated resources, and continues to collect actual performance data during execution for subsequent model optimization.

[0112] Optionally, the most suitable computing node can be determined by first scanning the status of cluster nodes in real time and comparing the task resource requirements with the available resources of each node to complete the initial screening; then, the nodes with the highest scores in terms of computing resource suitability, load balancing and data locality are evaluated, and finally the node with the highest score is selected to submit the task, thereby achieving optimal utilization of cluster resources and load balancing while meeting the requirements.

[0113] Optionally, for simulation test cases with the same priority score, the server can use a default auxiliary strategy for sorting. For example, the auxiliary strategy can prioritize test cases with lower predicted resource requirements.

[0114] Optional, such as Figure 7 As shown, S503 includes:

[0115] S601, Get the current resource utilization rate.

[0116] S602 determines the number of runnable use cases based on resource utilization.

[0117] S603 runs each simulation test case based on the number of runnable test cases and the simulation priority of each simulation test case.

[0118] In this embodiment, the resource utilization rate of the second server is obtained by real-time monitoring data. Based on the resource utilization rate, the remaining available capacity of various resources is determined, such as the total number of available CPU cores and the total amount of idle memory. Furthermore, based on the predicted simulation time and predicted resource size of each simulation test case, the maximum number of simulation test cases that can be scheduled, i.e. the number of test cases that can be run, is determined. Thus, the simulation test cases with the highest simulation priority and the number of runnable test cases are determined from all simulation test cases. Then, the simulation test cases are dynamically allocated and submitted to the most suitable computing node or job queue in sequence.

[0119] In the above-mentioned application embodiments, the traditional fixed resource allocation is transformed into dynamic, prediction-driven allocation, which improves the resource utilization efficiency and task throughput of the simulation server cluster at the global level, ensures the priority execution of high-priority or high-efficiency use cases, thereby shortening the overall queue waiting time and execution cycle of simulation verification, and providing a basic guarantee for accelerating chip development iteration.

[0120] Optional, such as Figure 8 As shown, the server may include:

[0121] (1) Data layer. Used for historical data storage: storing historical records such as simulation time, error logs, and case characteristics; Real-time data interface: receiving input parameters and simulation results of the current use case.

[0122] (2) Artificial Intelligence (AI) prediction layer, including: simulation time prediction model, deep learning model based on LSTM or Transformer, input use case features, output prediction time; error log analysis model: Natural Language Processing (NLP) model extracts log keywords, performs preprocessing based on keywords, performs error classification based on LLM large language model and context engineering.

[0123] (3) Resource scheduling layer, including: dynamic resource allocator, which dynamically adjusts the CPU / GPU resource allocation ratio according to the predicted time and server load and storage load; task priority queue: sorts the test cases by predicted time and custom priority of the test cases, and dynamically queues them to ensure that the total time of regression tasks is minimized.

[0124] (4) Error analysis layer, including: Typical use case filter: Based on clustering results and large language model analysis, select use cases that cover the main failure modes and generate valuable typical waveforms for users to debug; Root cause analysis (RCA): Locate design defects or test platform problems.

[0125] (5) Feedback optimization layer, which is used to continuously optimize AI model parameters, adjust resource allocation strategies and error analysis rules by utilizing simulation results and debugging feedback.

[0126] In the above-mentioned embodiments, the analysis time of the root cause of the error is shortened, the accuracy and consistency of defect identification are improved, and a clear target is provided for subsequent precise debugging, thereby compressing the entire diagnostic cycle from simulation failure to defect confirmation and accelerating the verification iteration process.

[0127] In one embodiment, one implementation of S502 described above is provided, such as... Figure 9 As shown, the above "determining the simulation priority of each simulation test case based on the predicted simulation time and predicted resource consumption of each simulation test case" includes:

[0128] S701, determine the initial priority of each simulation test case based on the predicted simulation time and predicted resource consumption of each simulation test case.

[0129] In this embodiment, based on historical simulation data, the predicted simulation time and predicted resource consumption data for each simulation test case are predicted. The predicted resource consumption includes predicted values ​​for the CPU's computing resource usage time and memory consumption. Further, based on the predicted simulation time and predicted resource consumption, an initial priority score is generated. Based on a preset correspondence between the initial priority score and the initial priority, the initial priority of each simulation test case is determined.

[0130] Optionally, for any simulation test case, based on the test type of the simulation test case, the historical test time of test cases of the same test type can be read from historical simulation data, and the predicted simulation time of the simulation test case can be predicted based on the average of multiple historical test times; and the historical resource consumption of test cases of the same test type can be read from historical simulation data, and the predicted resource consumption of the simulation test case can be predicted based on the average of multiple historical resource consumption.

[0131] S702, adjusts the initial priority according to the preset regression strategy to determine the simulation priority of each simulation test case.

[0132] In this embodiment, the number of simulation test cases can be determined by combining the current running time period, real-time collected server load data, and storage usage. Then, based on the characteristics of each simulation test case, historical execution data, user-specified business priority tags, and the overall regression scheduling strategy, the initial priority score is calibrated. Finally, among the simulation test cases with the same priority after calibration, a weighted priority is introduced to differentiate them and determine the simulation priority of each simulation test case. The weighted priority can be determined based on the functional importance of the test case and the historical defect detection rate.

[0133] In the above-mentioned application embodiments, historical data, real-time cluster status, user business intent and weight mechanism are integrated into one, so that the simulation priority can adapt to the cluster environment and diverse verification objectives, thereby significantly improving the resource utilization efficiency of simulation task scheduling at the global level.

[0134] In one embodiment, such as Figure 10 As shown, a complete chip debugging method is provided, including:

[0135] S1, obtain multiple simulation test cases for the chip.

[0136] S2, based on the preset feature extraction model, performs feature extraction on multiple simulation test cases to determine the predicted simulation time and predicted resource requirements for each simulation test case.

[0137] S3. Determine the initial priority of each simulation test case based on the predicted simulation time and predicted resource consumption of each simulation test case.

[0138] S4. Adjust the initial priority according to the preset regression strategy to determine the simulation priority of each simulation test case.

[0139] S5 retrieves the current resource utilization rate.

[0140] S6 determines the number of runnable use cases based on resource utilization.

[0141] S7 runs each simulation test case based on the number of runnable test cases and the simulation priority of each simulation test case.

[0142] S8 retrieves log information corresponding to runtime errors when runtime errors occur during the execution of multiple simulation test cases.

[0143] S9. Extract features from the log information to obtain the feature information of the log information.

[0144] S10: Based on a preset defect analysis model and a preset defect database, the feature information is analyzed and clustered to determine at least one type of target defect in the chip.

[0145] S11, for each target defect type, determine the corresponding candidate simulation test cases.

[0146] S12, determine the number of target simulation test cases based on the number of candidate simulation test cases, and determine at least one target simulation test case corresponding to the target defect type from the candidate simulation test cases based on the number of target simulation test cases.

[0147] S13 generates waveform information corresponding to the target simulation test case, so as to debug the chip based on the waveform information.

[0148] S14, store the target defect and its corresponding test case that do not exist in the defect database to a preset storage location, so as to update the defect database according to the target defect and its corresponding test case.

[0149] The aforementioned chip debugging method involves acquiring multiple simulation test cases for the chip; when errors occur during the execution of these simulation test cases, obtaining the corresponding log information; analyzing the log information to determine the target defect type and the corresponding target simulation test case; the target defect includes at least one type of defect; and generating waveform information corresponding to the target simulation test case for chip debugging. By acquiring log information when errors occur during simulation test case execution, the target defect type and the target simulation test case that triggered the defect are located, and corresponding key waveform information is generated, thus achieving a closed loop from error occurrence to debugging. This integrates the traditional manual review of massive logs and scattered debugging steps into a coherent analysis process, improving the accuracy and speed of defect location and providing intuitive debugging criteria, thereby shortening the verification and debugging cycle and improving chip debugging efficiency.

[0150] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0151] Based on the same inventive concept, this application also provides a chip debugging apparatus for implementing the chip debugging method described above. This apparatus can be applied to or integrated into a chip or chip module, for example. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more chip debugging apparatus embodiments provided below can be found in the limitations of the chip debugging method described above, and will not be repeated here.

[0152] In one embodiment, such as Figure 11 As shown, a chip debugging device is provided, including: a first acquisition module 10, a second acquisition module 11, an analysis module 12, and a debugging module 13, wherein:

[0153] The first acquisition module 10 is used to acquire multiple simulation test cases for the chip;

[0154] The second acquisition module 11 is used to acquire log information corresponding to the running error when a running error occurs during the running of multiple simulation test cases;

[0155] Analysis module 12 is used to analyze log information to determine the type of target defect present in the chip and the target simulation test case corresponding to the target defect; the target defect includes at least one type of defect;

[0156] The debugging module 13 is used to generate waveform information corresponding to the target simulation test cases, so as to debug the chip based on the waveform information.

[0157] In one embodiment, the analysis module 12 includes: an extraction unit, an analysis unit, and a first determination unit, wherein:

[0158] The extraction unit is used to extract features from log information to obtain the feature information of the log information;

[0159] The analysis unit is used to analyze and cluster feature information based on a preset defect analysis model and a preset defect database to determine at least one type of target defect in the chip; the defect database includes descriptive information for multiple defect types.

[0160] The first determining unit is used to determine at least one target simulation test case corresponding to each target defect type from multiple simulation test cases based on each target defect type.

[0161] In one embodiment, the first determining unit is specifically used to determine, for each target defect type, candidate simulation test cases corresponding to the target defect type; determine the number of target simulation test cases based on the number of candidate simulation test cases; and determine at least one target simulation test case corresponding to the target defect type from the candidate simulation test cases based on the number of target simulation test cases.

[0162] In one embodiment, the analysis module 12 further includes a storage unit for storing target defects and corresponding test cases that do not exist in the defect database to a preset storage location, so as to update the defect database according to the target defects and corresponding test cases.

[0163] In one embodiment, the chip debugging apparatus further includes: a first determining module, a second determining module, and a running module, wherein:

[0164] The first determination module is used to extract features from multiple simulation test cases based on a preset feature extraction model, and to determine the predicted simulation time and predicted resource requirements for each simulation test case.

[0165] The second determining module is used to determine the simulation priority of each simulation test case based on the predicted simulation time and predicted resource consumption of each simulation test case.

[0166] The run module is used to run each simulation test case according to its simulation priority.

[0167] In one embodiment, the second determining module includes: a second determining unit and a third determining unit, wherein:

[0168] The second determining unit is used to determine the initial priority of each simulation test case based on the predicted simulation time and predicted resource consumption of each simulation test case.

[0169] The third determining unit is used to adjust the initial priority according to the preset regression strategy and determine the simulation priority of each simulation test case.

[0170] In one embodiment, the above-mentioned operating module includes: an acquisition unit, a fourth determination unit, and an operating unit, wherein:

[0171] The acquisition unit is used to obtain the current resource utilization rate;

[0172] The fourth determining unit is used to determine the number of runnable use cases based on resource utilization.

[0173] The execution unit is used to run each simulation test case according to the number of runnable test cases and the simulation priority of each simulation test case.

[0174] In one embodiment, the above defect analysis model is a large language model.

[0175] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0176] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 12 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores chip debugging data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a chip debugging method.

[0177] Those skilled in the art will understand that Figure 12The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0178] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0179] Obtain multiple simulation test cases for the chip;

[0180] If a runtime error occurs while running multiple simulation test cases, obtain the log information corresponding to the runtime error;

[0181] Analyze log information to determine the type of target defect present in the chip and the corresponding target simulation test cases; the target defect includes at least one type of defect.

[0182] Generate waveform information corresponding to the target simulation test cases to debug the chip based on the waveform information.

[0183] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0184] Feature extraction is performed on the log information to obtain its feature information;

[0185] Based on a pre-set defect analysis model and a pre-set defect database, feature information is analyzed and clustered to determine at least one type of target defect in the chip; the defect database includes descriptive information for multiple defect types.

[0186] Based on each target defect type, at least one target simulation test case corresponding to each target defect type is determined from multiple simulation test cases.

[0187] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0188] For each target defect type, determine the corresponding candidate simulation test cases;

[0189] Based on the number of candidate simulation test cases, determine the number of target simulation test cases, and based on the number of target simulation test cases, determine at least one target simulation test case corresponding to the target defect type from the candidate simulation test cases.

[0190] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0191] Store the target defects and their corresponding test cases that do not exist in the defect database to a preset storage location, so as to update the defect database based on the target defects and their corresponding test cases.

[0192] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0193] Based on a pre-defined feature extraction model, features are extracted from multiple simulation test cases to determine the predicted simulation time and predicted resource requirements for each simulation test case.

[0194] Based on the predicted simulation time and predicted resource consumption of each simulation test case, the simulation priority of each simulation test case is determined.

[0195] Run each simulation test case according to its simulation priority.

[0196] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0197] Based on the predicted simulation time and predicted resource consumption of each simulation test case, the initial priority of each simulation test case is determined.

[0198] The initial priority is adjusted according to the preset regression strategy to determine the simulation priority of each simulation test case.

[0199] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0200] Get the current resource utilization rate;

[0201] The number of runnable use cases is determined based on resource utilization.

[0202] Run each simulation test case according to the number of runnable test cases and the simulation priority of each simulation test case.

[0203] In one embodiment, when the processor executes a computer program, the defect analysis model is a large language model.

[0204] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0205] Obtain multiple simulation test cases for the chip;

[0206] If a runtime error occurs while running multiple simulation test cases, obtain the log information corresponding to the runtime error;

[0207] Analyze log information to determine the type of target defect present in the chip and the corresponding target simulation test cases; the target defect includes at least one type of defect.

[0208] Generate waveform information corresponding to the target simulation test cases to debug the chip based on the waveform information.

[0209] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0210] Feature extraction is performed on the log information to obtain its feature information;

[0211] Based on a pre-set defect analysis model and a pre-set defect database, feature information is analyzed and clustered to determine at least one type of target defect in the chip; the defect database includes descriptive information for multiple defect types.

[0212] Based on each target defect type, at least one target simulation test case corresponding to each target defect type is determined from multiple simulation test cases.

[0213] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0214] For each target defect type, determine the corresponding candidate simulation test cases;

[0215] Based on the number of candidate simulation test cases, determine the number of target simulation test cases, and based on the number of target simulation test cases, determine at least one target simulation test case corresponding to the target defect type from the candidate simulation test cases.

[0216] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0217] Store the target defects and their corresponding test cases that do not exist in the defect database to a preset storage location, so as to update the defect database based on the target defects and their corresponding test cases.

[0218] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0219] Based on a pre-defined feature extraction model, features are extracted from multiple simulation test cases to determine the predicted simulation time and predicted resource requirements for each simulation test case.

[0220] Based on the predicted simulation time and predicted resource consumption of each simulation test case, the simulation priority of each simulation test case is determined.

[0221] Run each simulation test case according to its simulation priority.

[0222] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0223] Based on the predicted simulation time and predicted resource consumption of each simulation test case, the initial priority of each simulation test case is determined.

[0224] The initial priority is adjusted according to the preset regression strategy to determine the simulation priority of each simulation test case.

[0225] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0226] Get the current resource utilization rate;

[0227] The number of runnable use cases is determined based on resource utilization.

[0228] Run each simulation test case according to the number of runnable test cases and the simulation priority of each simulation test case.

[0229] In one embodiment, when the computer program is executed by a processor, the defect analysis model is a large language model.

[0230] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0231] Obtain multiple simulation test cases for the chip;

[0232] If a runtime error occurs while running multiple simulation test cases, obtain the log information corresponding to the runtime error;

[0233] Analyze log information to determine the type of target defect present in the chip and the corresponding target simulation test cases; the target defect includes at least one type of defect.

[0234] Generate waveform information corresponding to the target simulation test cases to debug the chip based on the waveform information.

[0235] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0236] Feature extraction is performed on the log information to obtain its feature information;

[0237] Based on a pre-set defect analysis model and a pre-set defect database, feature information is analyzed and clustered to determine at least one type of target defect in the chip; the defect database includes descriptive information for multiple defect types.

[0238] Based on each target defect type, at least one target simulation test case corresponding to each target defect type is determined from multiple simulation test cases.

[0239] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0240] For each target defect type, determine the corresponding candidate simulation test cases;

[0241] Based on the number of candidate simulation test cases, determine the number of target simulation test cases, and based on the number of target simulation test cases, determine at least one target simulation test case corresponding to the target defect type from the candidate simulation test cases.

[0242] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0243] Store the target defects and their corresponding test cases that do not exist in the defect database to a preset storage location, so as to update the defect database based on the target defects and their corresponding test cases.

[0244] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0245] Based on a pre-defined feature extraction model, features are extracted from multiple simulation test cases to determine the predicted simulation time and predicted resource requirements for each simulation test case.

[0246] Based on the predicted simulation time and predicted resource consumption of each simulation test case, the simulation priority of each simulation test case is determined.

[0247] Run each simulation test case according to its simulation priority.

[0248] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0249] Based on the predicted simulation time and predicted resource consumption of each simulation test case, the initial priority of each simulation test case is determined.

[0250] The initial priority is adjusted according to the preset regression strategy to determine the simulation priority of each simulation test case.

[0251] In one embodiment, when the computer program is executed by a processor, it further performs the following steps:

[0252] Get the current resource utilization rate;

[0253] The number of runnable use cases is determined based on resource utilization.

[0254] Run each simulation test case according to the number of runnable test cases and the simulation priority of each simulation test case.

[0255] In one embodiment, when the computer program is executed by a processor, the defect analysis model is a large language model.

[0256] Based on the same inventive concept, this application also provides a chip, including a processor coupled to a memory, for executing a computer program or instructions stored in the memory, and implementing the steps in the above method embodiments when the processor executes the computer program or instructions.

[0257] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0258] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0259] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A chip debugging method, characterized in that, The method includes: Obtain multiple simulation test cases for the chip; If a runtime error occurs during the execution of the multiple simulation test cases, obtain the log information corresponding to the runtime error; The log information is analyzed to determine the type of target defect present in the chip and the corresponding target simulation test case; the target defect includes at least one type of defect; The waveform information corresponding to the target simulation test case is generated so as to debug the chip based on the waveform information.

2. The method according to claim 1, characterized in that, The analysis of the log information to determine the target defect type of the chip and the corresponding target simulation test case includes: Feature extraction is performed on the log information to obtain the feature information of the log information; The feature information is analyzed and clustered based on a preset defect analysis model and a preset defect database to determine at least one type of target defect in the chip; the defect database includes descriptive information for multiple defect types. Based on each of the target defect types, at least one target simulation test case corresponding to each target defect type is determined from the plurality of simulation test cases.

3. The method according to claim 2, characterized in that, The step of determining at least one target simulation test case corresponding to each target defect type from the plurality of simulation test cases based on each target defect type includes: For each of the target defect types, determine the corresponding candidate simulation test cases; Based on the number of candidate simulation test cases, the number of target simulation test cases is determined, and based on the number of target simulation test cases, at least one target simulation test case corresponding to the target defect type is determined from the candidate simulation test cases.

4. The method according to claim 2, characterized in that, The method further includes: The target defects and their corresponding test cases that do not exist in the defect database are stored in a preset storage location, so as to update the defect database according to the target defects and their corresponding test cases.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Based on a preset feature extraction model, features are extracted from the multiple simulation test cases to determine the predicted simulation time and predicted resource requirements for each simulation test case. Based on the predicted simulation time and predicted resource consumption of each simulation test case, the simulation priority of each simulation test case is determined. Each simulation test case is run according to its simulation priority.

6. The method according to claim 5, characterized in that, The step of determining the simulation priority of each simulation test case based on the predicted simulation time and predicted resource consumption of each simulation test case includes: The initial priority of each simulation test case is determined based on the predicted simulation time and predicted resource consumption of each simulation test case. The initial priority is adjusted according to the preset regression strategy to determine the simulation priority of each simulation test case.

7. The method according to claim 5, characterized in that, The step of running each simulation test case according to its simulation priority includes: Get the current resource utilization rate; The number of runnable use cases is determined based on the resource utilization rate; Each simulation test case is run according to the number of runnable test cases and the simulation priority of each simulation test case.

8. The method according to any one of claims 2-4, characterized in that, The defect analysis model is a large language model.

9. A chip debugging device, characterized in that, The device includes: The first acquisition module is used to acquire multiple simulation test cases for the chip; The second acquisition module is used to acquire log information corresponding to the execution error when an execution error occurs during the running of the multiple simulation test cases; The analysis module is used to analyze the log information to determine the type of target defect present in the chip and the target simulation test case corresponding to the target defect; the target defect includes at least one type of defect; The debugging module is used to generate waveform information corresponding to the target simulation test case, so as to debug the chip based on the waveform information.

10. A server comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images