Method and apparatus for automatic failure analysis of integrated circuit design schemes

Abstract

This invention discloses an automatic failure analysis method and apparatus for integrated circuit design schemes. This invention utilizes an intelligent agent to drive a large language model for inference. During inference, the agent invokes a simulation error extractor to obtain failure signal information from simulation result files. A waveform reader accesses the verification tool interface to read simulation signal values ​​from the EDA tool's database. The large language model, based on the relevant information of the failure signals and the simulation signal values, locates potentially faulty RTL code blocks, performs semantic analysis, proposes hypothetical causes, and verifies these hypothetical causes to automatically find and trace the failure causes and automatically generate a failure analysis report. This combines the logical reasoning capabilities of the large language model with the physical data acquisition capabilities of the EDA tool. It compresses the cross-tool tracing process, which would normally take hours manually, into automated, one-click execution, improving productivity during the verification phase.

Description

Technical Field

[0001] This invention relates to the field of electronic-aided design (EDA) for integrated circuits, and more specifically to an automatic failure analysis method and apparatus for integrated circuit design schemes. Background Technology

[0002] In the front-end design process of digital integrated circuits, the automation level of electronic design-aided design (EDA) software is continuously improving. Before the integrated circuit design scheme is delivered to the back-end design node, the RTL (Register Transfer Level) code needs to be verified. The core objective of the verification phase is to ensure that the design scheme fully meets the specifications and to discover and fix all logic defects through simulation. During the verification phase, existing EDA tools can simulate and perform functional logic simulation of the integrated circuit design scheme according to the verification process designed by the verifier, and discover failed logic or modules.

[0003] In existing technologies, failure analysis requires manual intervention by verification engineers after a failure occurs. The purpose of failure analysis is to analyze the causes of defects discovered during the verification process and locate the RTL code leading to the defect, facilitating subsequent modifications. This analysis process requires significant human involvement. Although some existing EDA tools provide application programming interfaces (APIs) (e.g., Synopsys PyNPI), allowing verification engineers to write automated scripts to retrieve data from EDA tools, these automated scripts typically only extract and analyze log errors using regular expressions. Their generalization ability is weak, they cannot understand the diverse semantics of verification failures, and they are extremely difficult to dynamically link with waveform databases for inference. Therefore, failure analysis still requires substantial manual intervention, resulting in low efficiency. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide an automatic failure analysis method and apparatus for integrated circuit design schemes, so as to more automatically utilize large language models and intelligent agent technology to perform failure analysis of integrated circuit design schemes and improve design verification efficiency.

[0005] Firstly, an automatic failure analysis method for an integrated circuit design scheme is provided, wherein the integrated circuit design scheme includes multiple RTL code files, and the method includes: Obtain failure analysis requirement information, which includes natural language text and / or structured information; Parse the failure analysis requirement information to determine the failure analysis task context; Based on the task execution context and the inference logic determined by the pre-defined structured control text, the large language model is driven to perform inference, and the following steps are executed during the inference process: The simulation error extractor is invoked to extract the path of the failure signal and the corresponding error timestamp from the verification simulation log. The path of the failure signal includes the module to which the failure signal belongs and the name of the failure signal. The RTL code block to be parsed is determined based on the failure signal path, and the RTL code block to be parsed is at least one line of RTL code in the plurality of RTL code files; Determine the expected signal values ​​of each signal in the RTL code block to be parsed at the error timestamp; Call the waveform reader to access the verification tool interface and extract the simulation signal values ​​of each signal corresponding to the error timestamp; Based on the consistency between the expected signal values ​​and the simulated signal values ​​of each signal, hypothetical reasons are generated, and the hypothetical reasons are verified. If the assumed cause is true, a failure analysis report is generated based on the large language model and in the format specified by the structured control text.

[0006] Furthermore, the reasoning process also includes: In response to a false hypothesis, generate or switch to a new hypothesis and verify the new hypothesis.

[0007] Furthermore, verifying the hypothetical reasons includes: Determine the associated signal based on the hypothesized cause; Call the waveform reader to access the verification tool interface and extract the simulation signal value of the associated signal corresponding to the error timestamp; Determine whether the hypothetical cause is valid based on the simulated signal value and the expected value of the associated signal.

[0008] Furthermore, the reasons for generating assumptions based on the consistency between the expected signal values ​​and the simulated signal values ​​of each signal include: In response to the inconsistency between the expected signal value and the simulated signal value of the input signal, the code tracer is invoked to determine the RTL code position of the output input signal, and the consistency between the expected signal value and the simulated signal value is judged based on the output signal at the new RTL code position. In response to the discrepancy between the expected signal value and the simulated signal value of the output signal, the code tracer is invoked to determine the RTL code location corresponding to the output signal, and the code reader is invoked to determine a new RTL code block to be parsed based on the RTL code location, and the RTL code block to be parsed is inferred and parsed.

[0009] Furthermore, the reasoning process also includes: In response to the assumption that the failure point is unclear, a sliding window comparison is performed on the failure signal to find the inconsistency boundary timestamp, wherein the inconsistency boundary timestamp is the timestamp corresponding to the clock period when the expected signal value and the simulated signal value change from consistent to inconsistent. Inconsistent boundary timestamps are used as erroneous timestamps for inference.

[0010] Furthermore, the RTL code block to be parsed is determined based on the failure signal path, including: Call the code tracer to determine the location of the RTL code corresponding to the failure signal; The code reader is invoked to determine the RTL code block to be parsed based on the RTL code location.

[0011] Furthermore, the RTL code location includes the path of the RTL code, the location of the failure signal in the RTL code file, and a code digest of that location; The call code reader determines the RTL code block to be parsed based on the RTL code location, including: The large language model reads the code digest to determine whether to expand and retrieve code blocks; In response to identifying the extended code block, the code reader is invoked to read the RTL code file and obtain multiple lines of RTL code as the RTL code block to be parsed. In response to determining that the code block should not be expanded, the code digest is used as the RTL code block to be parsed.

[0012] Furthermore, the simulation error extractor and the waveform reader are any of the following: agent skills, tools, or separately configured sub-agents.

[0013] Furthermore, the code tracer and the code reader are any of the following: agent skills, tools, or separately configured sub-agents.

[0014] Secondly, an automatic failure analysis device for an integrated circuit design scheme is provided, the integrated circuit design scheme including multiple RTL code files, the device comprising: Main intelligent agent; The simulation error extractor is used to read the verification simulation log and extract the path of the failure signal and the corresponding error timestamp. A waveform reader is used to access the verification tool interface and extract the simulated signal values ​​of each signal corresponding to the error timestamp; The main intelligent agent is configured to acquire failure analysis requirement information, which includes natural language text and / or structured information; parse the failure analysis requirement information to determine the failure analysis task context; and, based on the task execution context and reasoning logic determined by preset structured control text, drive the large language model to perform reasoning, and execute the following steps during the reasoning process: The simulation error extractor is invoked to extract the path of the failure signal and the corresponding error timestamp from the verification simulation log. The path of the failure signal includes the module to which the failure signal belongs and the name of the failure signal. The RTL code block to be parsed is determined based on the failure signal path, and the RTL code block to be parsed is at least one line of RTL code in the plurality of RTL code files; Determine the expected signal values ​​of each signal in the RTL code block to be parsed at the error timestamp; Call the waveform reader to access the verification tool interface and extract the simulation signal values ​​of each signal corresponding to the error timestamp; Based on the consistency between the expected signal values ​​and the simulated signal values ​​of each signal, hypothetical reasons are generated, and the hypothetical reasons are verified. If the assumed cause is true, a failure analysis report is generated based on the large language model and in the format specified by the structured control text.

[0015] Thirdly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and the computer program, when executed by a processor, implements the method described in the first aspect.

[0016] Fourthly, an electronic device including a memory and a processor, the memory being used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in the first aspect.

[0017] This invention utilizes intelligent agent technology based on a large language model (LLM). Based on pre-defined structured control text-based reasoning logic, the intelligent agent drives the large language model for reasoning. During reasoning, the agent invokes a simulation error extractor to obtain relevant information about failure signals from the simulation result file. Simultaneously, a waveform reader accesses the verification tool interface to read simulation signal waveforms from the EDA tool's database. The large language model, based on the relevant information of the failure signals and the simulation signal waveforms, locates potentially faulty RTL code blocks, performs semantic analysis, proposes hypothetical causes, and verifies these hypothetical causes. This automatically finds and traces the cause of the failure and automatically generates a failure analysis report after the hypothetical cause is verified. Thus, the logical reasoning capabilities of LLM are combined with the physical data acquisition capabilities of EDA tools, reconstructing the underlying verification workflow. This compresses the traditionally time-consuming manual cross-tool tracing process into automated, one-click execution, greatly increasing the productivity of verification engineers. Attached Figure Description

[0018] The above and other objects, features and advantages of the present invention will become clearer from the following description of embodiments of the invention with reference to the accompanying drawings, in which: Figure 1 This is a flowchart of an automatic failure analysis method for integrated circuit design schemes according to an embodiment of the present invention; Figure 2 This is a schematic diagram of an automatic failure analysis device for an integrated circuit design scheme according to an embodiment of the present invention; Figure 3 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0019] The present application is described below based on embodiments, but it is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without these details. To avoid obscuring the substance of the present application, well-known methods, processes, flows, elements, and circuits are not described in detail.

[0020] Furthermore, those skilled in the art should understand that the accompanying drawings provided herein are for illustrative purposes only and are not necessarily drawn to scale.

[0021] Unless the context explicitly requires it, words such as "including" or "contains" throughout the application should be interpreted as including rather than exclusive or exhaustive; that is, meaning "including but not limited to".

[0022] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0023] In the verification phase of integrated circuit front-end design schemes, the functional logic of the integrated circuit design scheme is simulated according to the verification process designed by the verifier to identify failed logic or modules. Some existing technologies use UVM (Universal Verification Methodology), a widely used digital verification framework for integrated circuits. UVM is a standardized verification framework based on SystemVerilog, designed to efficiently and systematically build verification environments for integrated circuits (ICs) and system-on-a-chip (SoCs) by providing a set of predefined, reusable components and mechanisms. The core idea of ​​UVM is to modularize the verification platform and complete verification tasks through layered component collaboration. The top-level Test component is responsible for starting and configuring the entire environment, while the Environment component integrates all verification components. The core Agent component is responsible for interacting with the specific interface of the Design Under Test (DUT). Internally, it encapsulates a driver responsible for converting abstract transactions into physical signals, a Monitor responsible for monitoring the DUT interface and collecting data, and a Sequencer responsible for managing and sending transaction streams. The correctness of the verification is determined by the Scoreboard by comparing the actual results collected by the Monitor with the expected results.

[0024] During the verification process, the EDA tool compiles the user's design code (i.e., the integrated circuit design scheme) and the verification platform code within its simulation environment, generating an executable simulation file, and then enters the simulation execution phase. Users can start specific test cases by passing command-line parameters to the simulator, allowing for flexible execution of different scenarios without modifying the code. Various anomalies or failures during the simulation are recorded in the UVM log for later review by the user (i.e., the verification engineer). After the simulation, the verification engineer needs to review the UVM log to determine if the test passed. If failures exist (i.e., functional errors occur), the verification engineer needs to manually use the waveform viewing tool provided by the EDA tool to load the waveform file generated during simulation (e.g., fsdb or vcd file) to deeply analyze the timing and behavior of signals within the design code, relying on the verification engineer's experience to pinpoint the root cause of the problem.

[0025] While some existing EDA tools provide application programming interfaces (APIs) (e.g., Synopsys PyNPI), allowing verification engineers to write automated scripts to retrieve data from EDA tools, these scripts typically only extract and analyze log errors using regular expressions. They lack generalization ability, cannot understand the diverse semantics of verification failures, and are extremely difficult to implement dynamic inference with waveform databases. Failure analysis still requires significant manual intervention, resulting in low efficiency.

[0026] Meanwhile, some verification engineers have tried to use the reasoning capabilities of large language models to check design code or analyze failure defects. However, large language models can only perform textual reasoning based on input prompts and context. In this scenario, large language models can only perform reasoning based on error text in UVM logs. Large language models cannot obtain simulation results, are prone to illusions, and cannot provide accurate location of logical defects.

[0027] In view of this, embodiments of the present invention propose an automatic failure analysis method and apparatus for integrated circuit design schemes, which combines the logical reasoning capability of LLM with the physical data capture capability of EDA tools, reconstructs the underlying verification workflow, improves the automation level of failure analysis, and improves design verification efficiency.

[0028] Figure 1 This is a flowchart of an automatic failure analysis method for an integrated circuit design scheme according to an embodiment of the present invention. Figure 1 As shown, the automatic failure analysis method in this embodiment includes the following steps: Step S100: Obtain failure analysis requirement information, which includes natural language text and / or structured information.

[0029] In this embodiment, the failure analysis requirement information is entered by the verification engineer after the verification simulation. This requirement information may include the path or access method to the verification simulation log (e.g., the UVM log mentioned above), the specific problem to be analyzed, and other analysis requirements from the verification engineer.

[0030] In some implementations, the failure analysis requirements may also include requirements for the output format. For example, specifying which format to use to output the failure analysis content, or using a specific file format to output the failure analysis content, or using a specific interface to output the failure analysis content to the EDA tool.

[0031] In step S200, the failure analysis requirement information is parsed to determine the failure analysis task context.

[0032] In this step, leveraging the LLM's ability to understand natural language text or structured information, the LLM is used to parse the failure analysis requirement information and extract predetermined slot information as the context for the failure analysis task. This slot information can be information necessary to execute subsequent failure analysis reasoning processes, such as the path or authentication information of the verification simulation log mentioned above.

[0033] In step S300, based on the task execution context and the reasoning logic determined by the preset structured control text, the large language model is driven to perform reasoning, and the following steps are executed during the reasoning process: In this step, the extracted task execution context and the pre-set structured control text are used as input to the agent for the LLM, thereby initiating the inference process.

[0034] Large Language Models (LLMs) are artificial intelligence models built on deep learning techniques, particularly the Transformer architecture. Their core characteristics lie in their massive number of parameters (typically billions to trillions) and pre-training on large-scale text data. LLMs are well-suited for processing human natural language. They are also suitable for general processing of more logical computer programming languages ​​or hardware programming languages. LLMs possess powerful versatility, capable of not only fluently performing text generation, translation, summarization, and question answering, but also executing complex tasks such as coding, logical reasoning, and multi-turn dialogues.

[0035] In this paper, reasoning using LLM refers to the process by which a model, using trained parameters, calculates and generates an answer step-by-step according to a prompt, following the steps specified by the prompt. Through the large language model control capabilities provided by an intelligent agent platform or based on external computer program control, the large language model can play different roles based on the prompt, engaging in thinking, taking action based on current thinking decisions (e.g., calling external tools), and further considering information from external tools until it deems it ready to output.

[0036] In this application, an agent refers to an artificial intelligence system with autonomous perception, planning, decision-making, and execution capabilities. Unlike traditional Large Language Models (LLMs) that only passively respond, agents provide the ability to engage in dialogue with large models and respond in different ways based on the dialogue results. They can proactively break down complex goals and complete tasks through a "perception-thinking-action" cycle. Their core architecture typically includes four main elements: a brain (LLM provides reasoning and planning), memory (stores historical interactions and knowledge), tools (calls external capabilities such as search engines, code interpreters, and APIs), and action (executes specific operations). Different agents can decompose the original problem in different ways based on different prompts and corresponding settings, and generate results according to their assigned focus. Agents can typically be built on agent application platforms or frameworks. Agent application platforms or frameworks usually adopt a layered architecture, transforming the reasoning capabilities of LLMs into the interactive core of agent applications through standardized interfaces and runtime environments. Architecturally, the platform encapsulates LLM API calls and incorporates a context management module that automatically maintains short-term memory (sliding window) and long-term memory (vector database) for the session, ensuring the model "remembers" prior information during interaction. Utilizing a prompt word engineering framework, the user's natural language input is transformed into structured instructions understandable by the model. Combined with Retrieval Augmentation (RAG) technology, knowledge bases or external data are injected in real-time before the model generates responses. Furthermore, through Model Context Protocol (MCP) or function call mechanisms, LLM is empowered to call external tools (such as APIs and databases), enabling the agent not only to "converse" but also to perform specific tasks such as querying and computation. Finally, streaming technology provides real-time feedback of the model's inference results to the user, forming a closed-loop "perception-planning-action" interaction.

[0037] Simultaneously, the intelligent agent application platform also provides the ability to use tools based on LLM's inference decisions, a capability also known as a skill. The platform encapsulates skills as independent modules containing instructions, scripts, and resources, loading only brief metadata descriptions in system prompts to save on context windows. When the LLM identifies a matching skill to invoke based on intermediate inference outputs, it dynamically loads the skill's detailed standard operating procedure (SOP) and code logic into the context, allowing it to execute specific tasks within a secure sandbox. Building upon this, the platform provides comprehensive support, including a generative builder that allows users to create and iterate skills through natural language dialogue, flexible management methods supporting ZIP package uploads or command-line installation, and external tool connectivity based on the Model Context Protocol (MCP). It also integrates a code execution environment, file processing APIs, and interactive artifacts interfaces.

[0038] Based on the capabilities provided by the intelligent agent application platform, an intelligent agent can be built to integrate the thinking and reasoning capabilities of LLM. By calling the application programming interface (API) of EDA tools, the intelligent agent is given the ability to obtain the verification simulation logs and read the simulation signal waveforms during the verification process. Then, according to the intelligent agent's preset reasoning logic, starting from the location of the failure signal, the design code (i.e., RTL code) is traced and the failure cause is located for failure analysis.

[0039] In this embodiment, at least one master agent is set to lead the reasoning process of failure analysis. The reasoning process may include the following steps: Step S310: Call the simulation error extractor to extract the path of the failure signal and the corresponding error timestamp from the verification simulation log. The path of the failure signal includes the module to which the failure signal belongs and the name of the failure signal.

[0040] The simulation error extractor reads the verification simulation log based on the path provided in the failure analysis task context, and extracts relevant information about failure signals indicating logical or functional errors. This information primarily includes the path of the failure signal and its corresponding error timestamp. The path of the failure signal includes the module to which it belongs and the name of the failure signal.

[0041] The following is an example of information extracted by a simulation error extractor: ``` [UVM_ERROR] Mismatch detected @ 1250ns Component: tb_top.scoreboard Signal: tb_top.dut.data_out Expected: 32'hABCD_1234 Actual: 32'h0000_0000 ``` The timestamp is @1250ns, the module associated with the failure signal is tb_top.scoreboard, the failure signal name is tb_top.dut.data_out, the expected signal value is 32'hABCD_1234, and the actual simulated signal value is 32'h0000_0000. A mismatch (i.e., inconsistency) occurred between the expected and simulated signal values. Therefore, it was recorded in the verification simulation log. It should be understood that the above output information is only an example; different information presentation methods can be used according to requirements, as long as the path of the failure signal and the error timestamp are clearly shown.

[0042] In one alternative implementation, the simulation error extractor is built as a callable tool of the main agent. When the LLM inference output deems it necessary to read the verification simulation log, this tool is invoked to run a script that accesses the APIs provided by the EDA tool to read the verification simulation log and extract failure signal-related information, including the path of the failure signal and its corresponding error timestamp. This information is then fed back to the LLM as context for subsequent inference. For example, the path to a script (e.g., a Python script) for reading the verification simulation log can be configured in the prompts used to build the main agent. This script is configured to read the verification simulation log and output specified or all failure signal-related information. Simultaneously, the tool is configured to read the script's output as variables and use it as context for subsequent inference.

[0043] In more complex application environments, simulation error extractors can also be constructed as independent intelligent agents or skills. These sub-agents, based on the routing functionality provided by the intelligent agent platform, are triggered to extract simulation errors according to the identified intent (which may be user input or an intermediate result inferred by the main intelligent agent).

[0044] In step S320, the RTL code block to be parsed is determined according to the failure signal path, wherein the RTL code block to be parsed is at least one line of RTL code in the plurality of RTL code files.

[0045] RTL code is the design code for the integrated circuit design scheme in the embodiments of this invention. RTL code is a code file that describes hardware behavior in digital circuit design. By defining the signal flow between registers and logic gates, it accurately depicts the data transmission and state changes of the circuit under clock drive. RTL code can be converted into a specific gate-level netlist using synthesis tools, and finally implemented on FPGA or ASIC chips to achieve specific logic functions.

[0046] In this step, the main agent invokes necessary tools or skills based on the failure signal path to identify the RTL code block related to the failure signal in multiple RTL code files involved in the integrated circuit design scheme, and performs subsequent failure analysis.

[0047] In one alternative implementation, the code location corresponding to the failure signal can be initially located. Then, the LLM can determine, based on the code context of the code location, whether to treat the line of code at the location of the failure signal as the code to be parsed or to expand the code above and below as the code to be parsed.

[0048] Specifically, step S320 may include: step S321, calling the code tracer to determine the RTL code location corresponding to the failure signal.

[0049] Step S322: Call the code reader to determine the RTL code block to be parsed based on the RTL code location.

[0050] The code tracer is built as a callable tool for the master agent. After the LLM extracts the failure signal path according to the workflow set by the master agent, it calls this tool to run a script to access a predetermined code folder path in the EDA tool or operating system. This allows it to locate the RTL code that defines the failure signal and provides feedback to the LLM as context for subsequent inference. For example, the path of the script used to trace the failure signal (e.g., the path of a Python script) can be configured in the prompts used to build the master agent. This script is configured to find the location of the RTL code that defines the failure signal among multiple RTL codes based on the failure signal path and output the specified signal or failure signal-related information. Simultaneously, the tool is configured to read the script's output as variables and use it as context for subsequent inference.

[0051] In more complex application environments, code tracers can also be built as independent agents or skills. Sub-agents, based on the routing function provided by the agent platform, are triggered to perform code tracing operations according to the identified intent (which may be user input or an intermediate result inferred by the main agent).

[0052] Simultaneously, the code reader is responsible for reading the entire contents of the file containing the RTL code and then handing it over to the LLM inference to determine whether to expand the RTL code block to be parsed into multiple lines. The code reader can also be constructed as any of the locally invoked tools, skills, or independent sub-agents.

[0053] Furthermore, in step S321, the output RTL code location, in addition to the location of the RTL code file and the line number where the failure signal appeared, may also include a code digest for that location. Specifically, the code digest can be the code itself for that location, i.e., that line. The code digest can subsequently be used as pre-read information for the code reader to facilitate its rapid determination, reduce the consumption of computing resources, and optimize inference time.

[0054] The output of an example code tracer is as follows: ``` [Driver Trace Result] Target Signal: tb_top.dut.data_out Driver Found: File: . / rtl / pipe_stage.sv Line: 38-42 Type: Sequential (always_ff) Assignment Preview: data_out <= data_in; ``` In this dataset, Target Signal is the failure signal to be traced, File is the path to the RTL code file, Line is the line number, Type is the signal type, and Assignment Preview is the code summary. It should be understood that the above output information is merely an example; different information formats can be used for information exchange during the inference process as needed.

[0055] The code reader can be configured via prompt words to first read the code digest output by the code tracer, and then decide whether to expand the RTL code block to be parsed based on the analysis of the code digest.

[0056] Step S330: Determine the expected signal values ​​of each signal in the RTL code block to be parsed at the error timestamp.

[0057] In identifying the RTL code block to be parsed, besides the failure signal, there may be several other signals. In this step, the expected signal values ​​corresponding to the error timestamps of all signals in the RTL code block to be parsed are obtained. These expected signal values ​​can be determined through LLM inference of the statements in the RTL code block to be parsed, or they can be obtained by calling a specially configured tool to read from the UVM verification scheme file.

[0058] In one alternative implementation, to prevent the expected signal value from being on the edge of a transition and to obtain a more stable signal value, a predetermined very short time, such as 1 ps, can be added to or subtracted from the error timestamp, and the expected signal value at that moment can be used as the expected signal value of the error timestamp, thereby filtering out failures caused by signals on the edge of a transition.

[0059] Step S340: Call the waveform reader to access the verification tool interface and extract the simulation signal values ​​of each signal corresponding to the error timestamp.

[0060] Existing EDA verification tools provide interfaces for accessing simulated waveforms. For example, Synopsys's PyNPI data interface allows users to access waveform data in debug databases (such as FSDB, FastSignal Database) via Python scripts to obtain simulated signal values.

[0061] In this embodiment, the waveform reader is constructed as a callable tool or skill of the master agent. After the LLM extracts the RTL code block to be parsed according to the workflow set by the master agent, it calls this tool to run a script program to access the waveform data of the EDA tool, thereby obtaining the simulated signal values ​​(or stable simulated signal values) of each signal involved in the code block near the error timestamp, and feeding them back to the LLM as context for subsequent inference. For example, the path of the script program for waveform reading (e.g., the path of a Python script program) can be configured in the prompts used to construct the master agent. This script program is configured to read the simulated signal values ​​based on the input signal path and timestamp, and output information in a specified format. At the same time, the tool is configured to read the output of the script program as variables and use it as context for subsequent inference.

[0062] In more complex application environments, the waveform reader can also be built as an independent intelligent agent. Based on the routing function provided by the intelligent agent platform, it can trigger the sub-intelligent agent that is the waveform reader according to the recognized intent (which may be user input or intermediate result inference obtained by the main intelligent agent).

[0063] The output of an example waveform reader is as follows: ``` [Waveform Query Result] Signal: tb_top.dut.valid_in Time: 1249.999ps Value: 1'b1 Width: 1 bit ``` In this data structure, Signal represents the signal path, Time represents the timestamp, Value represents the simulated signal value, and Width represents the signal width or duration. It should be understood that the output information above is merely an example, and different information presentation methods can be used as needed.

[0064] Step S350: Generate hypothetical causes based on the consistency between the expected signal values ​​and the simulated signal values ​​of each signal, and verify the hypothetical causes.

[0065] After the waveform reader returns the simulated signal value of a signal of interest (which may be a failed signal or other related signals), the LLM compares the previously acquired expected signal value and the simulated signal value of that signal. If they match, the process switches to judging other signals in the RTL code block to be parsed. If they do not match, a hypothetical cause is generated for the inconsistency, and the hypothetical cause is verified based on the signals in the RTL code block to be parsed or the signals in the corresponding RTL code file.

[0066] Specifically, in step S350, the reasons for generating the assumption based on the consistency between the expected signal values ​​and the simulated signal values ​​of each signal include: Step S351: In response to the inconsistency between the expected signal value and the simulated signal value of the input signal, the code tracer is invoked to determine the RTL code position of the output input signal, and the consistency judgment between the expected signal value and the simulated signal value is performed based on the output signal at the new RTL code position.

[0067] Step S352: In response to the inconsistency between the expected signal value and the simulated signal value of the output signal, the code tracer is invoked to determine the RTL code position corresponding to the output signal, and the code reader is invoked to determine the new RTL code block to be parsed based on the RTL code position, and the RTL code block to be parsed is inferred and parsed.

[0068] In the above steps, the main agent can decide whether to switch the signal of interest according to the set inference logic, and use it as a new target to find the RTL code block related to the signal. It can also decide whether to read more relevant simulation signal values ​​for the current RTL code block to be parsed, and determine the changes in conditions.

[0069] Specifically, the main agent infers the hypothetical cause based on the triggering conditions and code information of the changed simulation signal values. During the inference and analysis process, it can decide to further trace the code block of the signal involved in the condition as a new RTL code block to be analyzed, or it can decide to call the waveform reader to read more relevant waveforms for verification.

[0070] Therefore, different processing is performed on different types of simulation signals to ensure that the failure of the output signal can be hypothesized and attributed.

[0071] During this verification process, the LLM analyzes what phenomena should be observed in the signal performance if the inconsistency between the expected and simulated signal values ​​of the failed signal is due to a specific cause. For example, the expected and simulated signal values ​​of signal A are consistent, while the existence of signal B is inconsistent. Then, it observes whether the evidence corresponding to the hypothetical cause holds true. This process allows the agent to invoke the aforementioned code tracer, code reader, and waveform reader to reason and observe multiple different signals.

[0072] In one implementation, verifying the hypothetical cause in step S350 may include the following steps: Step S353: Determine the associated signal based on the assumed cause.

[0073] Step S354: Call the waveform reader to access the verification tool interface and extract the simulation signal value of the associated signal corresponding to the error timestamp.

[0074] Step S355: Determine whether the hypothetical cause is valid based on the simulated signal value and expected value of the associated signal.

[0075] If necessary, the code tracer can also be invoked to trace other specific signals (e.g., the input signal of the driver of the currently failed signal) and perform multiple rounds of iterative verification. This process is executed by the LLM corresponding to the main agent based on the needs of the inference process.

[0076] Step S360: In response to the assumption that the cause is true, a failure analysis report is generated based on the large language model and in the format specified by the structured control text.

[0077] In step S370, in response to the false hypothesis, a new hypothesis is generated or switched to, and the new hypothesis is verified.

[0078] It should be understood that the lead agent communicates with the LLM in multiple rounds to advance the reasoning process. The above-described steps are not executed only once; based on the LLM's decision output, the lead agent chooses to use different tools or jump to different steps to advance the reasoning process. For example, if a waveform reader needs to be invoked during the verification of a hypothesis cause, the agent jumps to the corresponding step. Similarly, if a new RTL code block needs to be traced during the generation of a hypothesis cause, the lead agent can control the jump to the step of invoking the code tracer.

[0079] Therefore, based on the failure analysis requirements input by the user, information on failure signals can be obtained from the verification simulation log, and traced back accordingly. The failure signals can be compared with the simulation signal values, and attribution analysis of the relevant RTL code can be performed based on LLM to locate the cause of failure during the verification process and generate an analysis report accordingly.

[0080] Meanwhile, exit logic can be set in the intelligent agent. For example, if multiple hypothetical causes are not found, a failure analysis report can be generated based on the hypothesis with the highest confidence, and further prompts that manual intervention is required; or, a report can be directly issued indicating that the failure analysis was not successfully performed and requiring manual analysis.

[0081] In one implementation, handling logic can also be set for cases where the error timestamp is unclear. Specifically, if the generated hypothesis, based on the parsing of the RTL code block to be parsed, indicates that the failure point is unclear—that is, the location of the failure timestamp cannot be clearly determined from the verification simulation log, or the failure timestamp covers a long time period—then, for more accurate analysis, it is necessary to first find the transition point (also known as the jump point) where the failure signal switches from "good" to "bad." A sliding window comparison can be performed on the failure signal to find the inconsistency boundary timestamp, where the inconsistency boundary timestamp is the clock cycle corresponding to the transition from consistency to inconsistency between the expected signal value and the simulated signal value. Then, the inconsistency boundary timestamp is used as the error timestamp for inference.

[0082] In one alternative implementation, the user-input failure analysis requirements or the RTL codebase may also include a design intent description file. The main agent can load the design intent description file as context or from the RTL codebase during inference to understand the design intent of the entire integrated circuit design scheme. Based on this design intent, subsequent inference can be performed, thereby accelerating the inference process and improving its accuracy and rationality.

[0083] In one optional implementation, a rapid judgment skill for common failure scenarios can be set for the master agent. This skill lists multiple codes and analyses of failures caused by different reasons, allowing the LLM to quickly determine whether similar problems exist in the code based on the skill-defined approach. After determining the RTL code block to be parsed in step S320, the rapid judgment skill is first invoked to parse the RTL code block or the entire RTL code file to determine whether there are failures caused by common reasons, such as backpressure, overflow, deadlock, and other common problems.

[0084] This invention utilizes intelligent agent technology based on a large language model (LLM). Based on pre-defined structured control text-based reasoning logic, the intelligent agent drives the LLM to perform inference. During inference, the agent calls a simulation error extractor to obtain relevant information about failure signals from the simulation result file. Simultaneously, a waveform reader accesses the verification tool interface to read simulation signal waveforms from the EDA tool's database. The LLM, based on the relevant information of the failure signals and the simulation signal waveforms, locates potentially faulty RTL code blocks, performs semantic analysis, proposes hypothetical causes, and verifies these hypothetical causes. This automates the search and tracing of failure causes, and automatically generates a failure analysis report after the hypothetical causes are verified. Thus, the powerful logical reasoning capabilities of the LLM are combined with the physical data acquisition capabilities of the EDA tool to reconstruct the underlying verification workflow. This compresses the traditionally time-consuming manual cross-tool tracing process into automated, one-click execution, greatly increasing the productivity of verification engineers.

[0085] Figure 2 This is a schematic diagram of an automatic failure analysis device for an integrated circuit design scheme according to an embodiment of the present invention. Figure 2 As shown, the automatic failure analysis device in this embodiment includes a main intelligent agent 21, an LLM 22, a simulation error extractor 23, and a waveform reader 24. It should be understood that the LLM 22 can be a model specifically designed for the intelligent agent as part of the device, or it can be an external model shared by multiple intelligent agent applications and interactable via API. In some implementations, the LLM 22 is independent of the automatic failure analysis device. The main intelligent agent 21 can obtain failure analysis requirement information through the necessary input layer (or human-machine interface layer), which includes natural language text and / or structured information; parse the failure analysis requirement information to determine the failure analysis task context; based on the task execution context and the inference logic determined by the preset structured control text, drive the LLM 22 to perform inference, and execute the following steps based on the intermediate decisions output by the LLM 22 during the inference process: The simulation error extractor 23 is invoked to extract the path of the failure signal and the corresponding error timestamp from the verification simulation log. The path of the failure signal includes the module to which the failure signal belongs and the name of the failure signal. Based on the failure signal path, the RTL code block to be parsed is determined, which is at least one line of RTL code from the plurality of RTL code files. The expected signal value of each signal in the RTL code block to be parsed at the error timestamp is determined. The waveform reader 24 is invoked to access the verification tool interface to extract the simulation signal value of each signal corresponding to the error timestamp. Based on the consistency between the expected signal value and the simulation signal value of each signal, a hypothetical cause is generated, and the hypothetical cause is verified. In response to a valid hypothetical cause, a failure analysis report is generated based on the large language model and in the format specified by the structured control text. In response to a invalid hypothetical cause, a new hypothetical cause is generated or switched to, and the new hypothetical cause is verified. This process is iterated until an automatic analysis report can be automatically output.

[0086] In one optional implementation, the operation of determining the parsed RTL code block can be performed by the code tracer 25 and the code reader 26 working together. The code tracer 25 determines the RTL code location corresponding to the failure signal, and the code reader 26 determines the RTL code block to be parsed based on the RTL code location. In one example, the RTL code location output by the code tracer 25 may include not only the location of the RTL code file and the line number where the failure signal appears, but also a code digest for that location. Specifically, the code digest can be the code itself at that location, i.e., the line number. This code digest can subsequently be used as pre-read information for the code reader 26 to facilitate rapid judgment, reduce computational resource consumption, and optimize inference time.

[0087] The code reader 26 can be configured by prompt words to first read the code digest output by the code tracer, and then expand the RTL code block to be parsed based on the analysis of the code digest.

[0088] The automatic failure analysis device in this embodiment can be implemented in different ways.

[0089] In one implementation, this is achieved through an agent application platform that supports local tools or skills. In this implementation, the simulation error extractor 23, waveform reader 24, code tracer 25, and code reader 26 are encapsulated as callable tools or skills to verify simulation logs, simulation signal waveforms, and read RTL code as needed for the inference process. In agent technology, a tool is an atomic capability unit for an agent to perform specific operations; essentially, it is a function or API interface with explicit input and output (such as file reading, code execution, network search, etc.). Tools are only responsible for completing a single deterministic task, lacking business logic and context memory. They require active invocation by the agent to execute, and their core value is providing the agent with the basic execution capabilities to interact with external systems, serving as the underlying support for the agent's transition from "thinking" to "acting." A skill, on the other hand, is a composite capability package that encapsulates domain knowledge, operational procedures, tool invocation logic, and best practices, acting like a "professional experience library" for the agent. It exists in a structured form (such as a SKILL.md file containing metadata and instructions), allowing intelligent agents to autonomously determine task scenarios and invoke corresponding capabilities. It can complete complex tasks by combining multiple tools (such as "generating a research report" which requires invoking multiple tools such as search and file processing), and has context awareness and process orchestration capabilities. For example, for code reader 26, because it needs to make necessary decisions, code reader 26 and code tracer 25 can be encapsulated together as a single skill.

[0090] In another implementation, the automatic failure analysis device of this embodiment is implemented through an agent application platform that supports multi-agent interaction. In this implementation, the simulation error extractor 23, waveform reader 24, code tracer 25, and code reader 26 are encapsulated as sub-agents that can interact with the main agent. Compared to tools or skills, sub-agents can achieve more independent and complex reasoning operations by interacting more with the LLM. Meanwhile, skills can share context with the main agent, while sub-agents are context-isolated from the main agent.

[0091] In this embodiment, the reasoning process of the main intelligent agent can be constructed by defining its workflow, that is, the steps described in the above reasoning logic, and defining the processing principles and logic for different situations based on the workflow. At the engineering implementation level, certain constraints also need to be added to handle errors and avoid hallucinations, etc.

[0092] The following is an example of the automatic failure analysis process performed by the automatic failure analysis device according to an embodiment of the present invention: After performing a verification simulation, the verification engineer discovered an error: "`UVM_ERROR tb_top.sv(38)@ 75000: scb [SCB_FAIL] Data mismatch! Exp: aaaa1111, Act: 0`". The verification engineer can input this error into the automated failure analysis device and attach failure analysis requirements, such as the path to the code folder of the simulated integrated circuit design.

[0093] After receiving the failure analysis request information, the automatic failure analysis device parses the key information and then begins reasoning. First, the main agent 21 calls the verification simulation error extractor 23 to read the verification error log, thereby obtaining the corresponding failure signal path and timestamp, as follows: ``` [UVM_ERROR] Mismatch detected @ 1250ns Component: tb_top.scoreboard Signal: tb_top.dut.data_out Expected: 32'hABCD_1234 Actual: 32'h0000_0000 ``` The timestamp is @1250ns, the module containing the failure signal is tb_top.scoreboard, the failure signal name is tb_top.dut.data_out, the expected signal value is 32'hABCD_1234, and the actual simulated signal value is 32'h0000_0000. A mismatch (i.e., inconsistency) occurred between the expected and simulated signal values.

[0094] Based on the failure signal path, the main agent 21 calls the code tracer 25 to determine the RTL code location corresponding to the failure signal, and outputs the following content to the agent: ``` [Driver Trace Result] Target Signal: tb_top.dut.data_out Driver Found: File: . / rtl / pipe_stage.sv Line: 38-42 Type: Sequential (always_ff) Assignment Preview: data_out <= data_in; ``` That is, the RTL code file path corresponding to the target signal tb_top.dut.data_out is ". / rtl / pipe_stage.sv", the corresponding position is lines 38-42, and the code summary is "data_out<= data_in", which means that the signal of the data_in port is directly output to data_out.

[0095] Based on this, the main agent 21 calls the code reader 26 to read the corresponding position of the corresponding RTL code file, and determines the RTL code block to be parsed as follows: ```systemverilog if (valid_in) begin data_out <= data_in; end else begin data_out <= 32'h0; end ``` The RTL code above is written in SystemVerilog and sets the value of the Data_out signal based on the status of the valid_in signal.

[0096] Then, the main agent 21 determines the expected signal values ​​of each signal in the aforementioned RTL code block to be parsed according to a predetermined workflow. This determination can be made by the main agent 21 reading the entire pipe_stage.sv code file and then reasoning about it, or it can be obtained from the UVM verification simulation scheme (which is usually a file written in SystemVerilog).

[0097] The main agent 21 simultaneously accesses the FSDB database through the waveform reader 24 to read the simulated signal values ​​of each signal at the error timestamp of 1250ns, for example: ``` [Waveform Query Result] Signal: tb_top.dut.valid_in Time: 1249.999ps Value: 1'b1 Width: 1 bit ``` In the example above, the simulated signal value of the valid_in signal is read. It is offset from the error timestamp to ensure the stability of the sampled simulated signal value.

[0098] The main agent 21 compares the expected signal values ​​and simulated signal values ​​of each signal, and when they are inconsistent, it analyzes the cause through LLM reasoning and decides to trace the associated code of valid_in to determine the new RTL code block to be parsed as follows: ``` if (valid_in&&!stall) begin valid_out <= 1'b1; end else if (ready_out) begin valid_out <= 1'b0; end ``` Furthermore, the waveforms of signals such as valid_out in the RTL code block are judged, the code block is analyzed, and the hypothetical cause is determined based on the analysis. Then, the cause is verified, and after the cause is verified, a failure analysis report is output.

[0099] In the example above, by starting from the data_out signal, tracing back to the valid_in signal, and then tracing back to the state of related signals through the valid_in signal, the main agent verifies the hypothetical cause and concludes that the occurrence of the failure signal is due to the following in the parsed RTL code block: ``` end else begin data_out <= 32'h0; ``` This is caused by an incorrect condition setting; that is, the output of data_out cannot be controlled by the statement data_out<= 32'h0; when the signal valid_in is not 0.

[0100] Based on this, the main intelligent agent 21 can drive the LLM 22 to further generate a failure analysis report based on the above analysis. The failure analysis report can describe the analysis process, provide attribution, and provide suggestions for code modification.

[0101] This invention utilizes a large language model-based intelligent agent technology. Based on a pre-defined structured control text-based reasoning logic, the intelligent agent drives the large language model to perform inference. During inference, the agent calls a simulation error extractor to obtain relevant information about failure signals from the simulation result file. Simultaneously, a waveform reader accesses the verification tool interface to read simulation signal waveforms from the underlying database of the EDA tool. Using the large language model, based on the relevant information of the failure signals and the simulation signal waveforms, the system locates potentially faulty RTL code blocks, performs semantic analysis, proposes hypothetical causes, and verifies these hypothetical causes. This automatically finds and traces the cause of the failure and automatically generates a failure analysis report after the hypothetical cause is verified. Thus, the powerful logical reasoning capabilities of LLM are combined with the physical data acquisition capabilities of EDA tools to reconstruct the underlying verification workflow. This compresses the traditionally time-consuming manual cross-tool tracing process into automated, one-click execution, greatly increasing the productivity of verification engineers.

[0102] Figure 3 This is a schematic diagram of an electronic device according to an embodiment of the present invention. In this embodiment, the electronic device 3 includes a server, a workstation, etc. Figure 3 As shown, the electronic device 3 includes at least one processor 31; a memory 32 communicatively connected to at least one processor 31; and a communication component 33, which receives and transmits data under the control of the processor 31; wherein the memory 32 stores instructions executable by at least one processor 31 to implement the above method.

[0103] Specifically, the electronic device includes: one or more processors 31 and a memory 32. Figure 3 Taking a processor 31 as an example, the processor 31 and the memory 32 can be connected via a bus or other means. Figure 3 Taking a bus connection as an example, memory 32, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Processor 31 executes various functional applications and data processing of the device by running the non-volatile software programs, instructions, and modules stored in memory 32, thus implementing the above method.

[0104] The memory 32 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store an option list, etc. Furthermore, the memory 32 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 32 may optionally include memory remotely located relative to the processor 31, and these remote memories can be connected to external devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0105] One or more modules are stored in memory 32 and, when executed by one or more processors 31, perform the methods in any of the above method embodiments.

[0106] The above-mentioned products can perform the methods provided in the embodiments of this application, and have the corresponding functional modules and beneficial effects of performing the methods. For technical details not described in detail in this embodiment, please refer to the methods provided in the embodiments of this application.

[0107] Another embodiment of the present invention relates to a non-volatile storage medium for storing a computer-readable program for use by a computer to execute some or all of the above-described method embodiments.

[0108] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0109] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An automatic failure analysis method for an integrated circuit design scheme, wherein the integrated circuit design scheme includes multiple RTL code files, characterized in that, The method includes: Obtain failure analysis requirement information, which includes natural language text and / or structured information; Parse the failure analysis requirement information to determine the failure analysis task context; Based on the task execution context and the inference logic determined by the pre-defined structured control text, the large language model is driven to perform inference, and the following steps are executed during the inference process: The simulation error extractor is invoked to extract the path of the failure signal and the corresponding error timestamp from the verification simulation log. The path of the failure signal includes the module to which the failure signal belongs and the name of the failure signal. The RTL code block to be parsed is determined based on the failure signal path, and the RTL code block to be parsed is at least one line of RTL code in the plurality of RTL code files; Determine the expected signal values ​​of each signal in the RTL code block to be parsed at the error timestamp; Call the waveform reader to access the verification tool interface and extract the simulation signal values ​​of each signal corresponding to the error timestamp; Based on the consistency between the expected signal values ​​and the simulated signal values ​​of each signal, hypothetical reasons are generated, and the hypothetical reasons are verified. If the assumed cause is true, a failure analysis report is generated based on the large language model and in the format specified by the structured control text.

2. The method according to claim 1, characterized in that, The reasoning process also includes: In response to a false hypothesis, generate or switch to a new hypothesis and verify the new hypothesis.

3. The method according to claim 1, characterized in that, Verification of the hypothetical reasons includes: Determine the associated signal based on the hypothesized cause; Call the waveform reader to access the verification tool interface and extract the simulation signal value of the associated signal corresponding to the error timestamp; Determine whether the hypothetical cause is valid based on the simulated signal value and the expected value of the associated signal.

4. The method according to claim 1, characterized in that, The reasons for generating assumptions based on the consistency between the expected and simulated signal values ​​of each signal include: In response to the inconsistency between the expected signal value and the simulated signal value of the input signal, the code tracer is invoked to determine the RTL code position of the output input signal, and the consistency between the expected signal value and the simulated signal value is judged based on the output signal at the new RTL code position. In response to the discrepancy between the expected signal value and the simulated signal value of the output signal, the code tracer is invoked to determine the RTL code location corresponding to the output signal, and the code reader is invoked to determine a new RTL code block to be parsed based on the RTL code location, and the RTL code block to be parsed is inferred and parsed.

5. The method according to claim 1, characterized in that, The reasoning process also includes: In response to the assumption that the failure point is unclear, a sliding window comparison is performed on the failure signal to find the inconsistency boundary timestamp, wherein the inconsistency boundary timestamp is the timestamp corresponding to the clock period when the expected signal value and the simulated signal value change from consistent to inconsistent. Inconsistent boundary timestamps are used as erroneous timestamps for inference.

6. The method according to claim 1, characterized in that, Based on the failure signal path, the RTL code blocks to be parsed include: Call the code tracer to determine the location of the RTL code corresponding to the failure signal; The code reader is invoked to determine the RTL code block to be parsed based on the RTL code location.

7. The method according to claim 6, characterized in that, The RTL code location includes the path of the RTL code, the location of the failure signal in the RTL code file, and the code summary at that location; The call code reader determines the RTL code block to be parsed based on the RTL code location, including: The large language model reads the code digest to determine whether to expand and retrieve code blocks; In response to identifying the extended code block, the code reader is invoked to read the RTL code file and obtain multiple lines of RTL code as the RTL code block to be parsed. In response to determining that the code block should not be expanded, the code digest is used as the RTL code block to be parsed.

8. The method according to claim 1, characterized in that, The simulation error extractor and the waveform reader are any of the following: agent skills, tools, or separately configured sub-agents.

9. The method according to claim 4 or 6, characterized in that, The code tracer and the code reader are any of the following: agent skills, tools, or separately configured sub-agents.

10. An automatic failure analysis device for an integrated circuit design scheme, wherein the integrated circuit design scheme includes multiple RTL code files, characterized in that, The device includes: Main intelligent agent; The simulation error extractor is used to read the verification simulation log and extract the path of the failure signal and the corresponding error timestamp. A waveform reader is used to access the verification tool interface and extract the simulated signal values ​​of each signal corresponding to the error timestamp; The main intelligent agent is configured to acquire failure analysis requirement information, which includes natural language text and / or structured information; parse the failure analysis requirement information to determine the failure analysis task context; and, based on the task execution context and the inference logic determined by the preset structured control text, drive the large language model to perform inference, and execute the following steps during the inference process: The simulation error extractor is invoked to extract the path of the failure signal and the corresponding error timestamp from the verification simulation log. The path of the failure signal includes the module to which the failure signal belongs and the name of the failure signal. The RTL code block to be parsed is determined based on the failure signal path, and the RTL code block to be parsed is at least one line of RTL code in the plurality of RTL code files; Determine the expected signal values ​​of each signal in the RTL code block to be parsed at the error timestamp; Call the waveform reader to access the verification tool interface and extract the simulation signal values ​​of each signal corresponding to the error timestamp; Based on the consistency between the expected signal values ​​and the simulated signal values ​​of each signal, hypothetical reasons are generated, and the hypothetical reasons are verified. If the assumed cause is true, a failure analysis report is generated based on the large language model and in the format specified by the structured control text.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-9.

12. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory being used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in any one of claims 1-9.

Images