An empirical-driven multi-agent RTL code generation method and system

Abstract

The application discloses an experience-driven multi-agent RTL code generation method and system, and belongs to the application field of agents in electronic design automation. The method comprises the following steps: refining an RTL design task described in natural language to obtain a structured task requirement; evaluating the complexity and field of the structured task requirement, triggering pre-learning when there is a capability gap, and decomposing the task into a sub-task set; topologically sorting the sub-task set according to the dependency relationship to construct a directed acyclic graph of parallel dependency layers; recursively delegating sub-agents to execute and verify repair according to layers of the directed acyclic graph, and outputting RTL code and an execution track; and extracting the execution track and storing it in an experience system after quality filtering. The application aims to improve the task execution capability by accumulating design experience and making up for the capability gap without retraining the underlying model, to realize experience-driven self-adaption of RTL code generation, and to improve the quality and efficiency of RTL code generation.

Description

Technical Field

[0001] This invention relates to computer systems based on agent computing models, specifically to an experience-driven multi-agent RTL code generation method and system that utilizes an agent computing model-based computer system to implement electronic design automation (EDA) applications. Background Technology

[0002] The semiconductor industry is facing increasingly severe challenges in design complexity. Modern System-on-a-Chip (SoC) integrates billions of transistors, involving the collaborative design of multiple heterogeneous modules such as processor cores, memory controllers, interconnect networks, and domain-specific accelerators. RTL code, as a crucial bridge connecting architectural specifications and physical implementation, largely determines the chip's performance, power consumption, and area (PPA) metrics. However, traditional RTL design heavily relies on manual coding by senior engineers, resulting in long design cycles, high labor costs, and a high risk of introducing functional defects. Furthermore, the complexity of electronic design automation (EDA) toolchains further raises the entry barrier for hardware design. With the increasing global shortage of semiconductor talent, exploring efficient methods for automated RTL code generation has become an urgent need for both academia and industry.

[0003] RTL code generation differs fundamentally from general software code generation. Software code typically describes sequentially executed operations, while RTL code describes hardware structures that operate in parallel. In Verilog, always blocks, assign statements, and module instantiation express parallel hardware behavior rather than sequential sequences of instructions. RTL designs must ultimately meet strict timing requirements to achieve physical implementation, although the primary focus at the RTL stage is the functional correctness of the described circuit behavior. Signal bit widths, signed attributes, and cross-module interface matching must be consistently specified. RTL correctness verification is typically performed through an iterative design-verification-debug cycle, generally relying on simulation test platforms, and in advanced workflows, formal verification tools are also used. These characteristics collectively drive the demand for automated RTL generation systems.

[0004] The rapid development of Large Language Models (LLMs) has opened up a new paradigm for RTL code generation. In recent years, numerous studies have demonstrated the potential of LLMs in Verilog code generation. VerilogEval provides a standardized evaluation framework encompassing 156 design problems, RTLLM offers an open-source benchmark covering four major categories, and MAGE, using a multi-agent architecture on VerilogEval with Claude 3.5 Sonnet and leveraging the reference testing platform provided by the benchmark, achieved a 95.7% pass@1. These results indicate that LLMs have a considerable foundation in understanding and generating hardware description languages. However, reliably deploying LLMs into real-world RTL design workflows requires addressing a fundamental challenge: how to provide appropriate context for the LLM at every step of the design process. Current methods address this challenge to varying degrees, but each has significant limitations. Fine-tuning methods train domain models on specialized datasets to improve RTL generation quality, but are constrained by the update cycle of training data and face catastrophic forgetting and high training costs. Single-agent approaches guide large language models through prompts and contextual optimization, with some methods incorporating fine-tuning. However, the limited context window makes it difficult for a single large language model to maintain self-correction throughout the end-to-end design workflow. Fixed-workflow approaches organize the capabilities of large language models through predefined agent roles and execution flows, but their static task decomposition strategies cannot adapt to unexpected problems during the design process. When such systems decompose tasks according to predefined rules, each agent can only access a portion of the task context, limiting its reasoning capabilities. Self-evolving agent approaches introduce cross-task capability enhancement mechanisms on top of multi-agent systems, but lack specific designs for RTL code generation. This challenge manifests in three dimensions: First, during task execution, the large language model must receive context matching the scope and complexity of the current subtask. Static decomposition cannot anticipate all RTL module structures or adapt to unexpected problems; when decomposition is inappropriate, the context received by each agent is incomplete or off-target. Second, at the cross-task level, large language models can benefit from previous design experience, but lack mechanisms for accumulating and reusing such knowledge. Each time a new task is encountered, the agent must rediscover design patterns and validation strategies. Third, when faced with unfamiliar domains, large language models may lack the prior knowledge required to generate correct output, and even contextual matching and relevant experience are of little use.

[0005] Existing RTL code generation methods based on large language models can be categorized into four types: fine-tuning methods, single-agent prompt optimization methods, fixed multi-agent workflow methods, and self-evolving agent methods. Each of these four types addresses certain aspects of the context engineering challenge, but none systematically solves all three dimensions: dynamic context assembly during task execution, cross-task context enrichment through knowledge reuse, and runtime context generation when prior knowledge is insufficient. Fine-tuning methods improve generation quality in known domains but cannot dynamically interact with EDA tools or adjust the context during execution. Single-agent methods optimize prompts and context within a fixed agent, but limited context windows and context degradation hinder continuous self-correction in end-to-end designs. Fixed multi-agent workflows decompose tasks into parallel subtasks with specialized roles, but static task decomposition strategies cannot adapt to unexpected problems during execution. Self-evolving agent methods introduce cross-task capabilities on top of multi-agent systems but do not leverage the hierarchical structure and scalability of RTL design for context learning. Summary of the Invention

[0006] The technical problem to be solved by this invention is to provide an experience-driven multi-agent RTL code generation method and system to address the above-mentioned problems in the prior art. This invention aims to improve task execution capabilities by accumulating design experience and making up for capability gaps without retraining the underlying model, thereby achieving experience-driven adaptive RTL code generation and improving the quality and efficiency of RTL code generation.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: An experience-driven multi-agent RTL code generation method includes the following steps: S1, the refinement stage, includes taking the RTL design task described in natural language as input, clarifying and structuring the RTL design task through a large language model to output structured task requirements, which include task description, design goals, constraints, dependencies and success criteria. S2, Evaluation phase, includes evaluating the complexity and domain of the RTL design task using the structured task requirements as input; if the domain of the RTL design task exceeds the capabilities of the experience system, then triggering the prior learning of the experience system; and decomposing the RTL design task into a set of subtasks based on the complexity. S3, the planning phase, includes taking the set of subtasks as input, performing topological sorting based on the dependencies between subtasks, constructing a directed acyclic graph and dividing it into parallel executable dependency layers, and outputting the directed acyclic graph dependency layer structure. S4, Execution phase, includes taking the directed acyclic graph dependency layer structure, acceptance criteria, structured task requirements and experience retrieved from the experience system as input, recursively delegating subtasks to sub-agents according to the dependency layer order, verifying and repairing according to the acceptance criteria during execution, and outputting the generated RTL code and execution trajectory; S5, Summary phase, includes taking the execution trajectory as input, extracting reusable experience from it and performing quality filtering, and storing the filtered experience in a structured form into the experience system.

[0008] Optionally, step S1 includes: S1.1, The RTL design task of obtaining the natural language description of the input; S1.2, Identify the task description, design goals, constraints, dependencies and success criteria in the RTL design task through the large language model, and eliminate ambiguity in the RTL design task by the large language model, supplement missing constraints and implicit dependencies, and complete the clarification of the RTL design task. S1.3 transforms the clarified RTL design task into a structured representation to obtain structured task requirements, which include task description, design goals, constraints, dependencies, and success criteria.

[0009] Optionally, step S2 includes: S2.1, Using the structured task requirements as input, evaluate the domain knowledge and complexity involved in the RTL design task; S2.2 Determine whether the following two conditions are met simultaneously: the domain knowledge involved in the RTL design task can be covered by the experience system and the complexity involved in the RTL design task does not exceed the preset level. If both conditions are met, proceed to step S2.4; otherwise, determine that the complexity and domain of the RTL design task exceed the requirements and proceed to step S2.3. S2.3, determine whether the number of times the pre-learning is triggered exceeds the preset threshold. If it exceeds the preset threshold, end and exit. Otherwise, trigger the pre-learning of the experience system to enhance the domain knowledge covered by the experience system, and jump to step S2.2. S2.4 Decompose the RTL design task into several sub-tasks according to the complexity of the RTL design task, and define verifiable acceptance criteria for each sub-task. S2.5 outputs the set of subtasks consisting of each subtask and its acceptance criteria.

[0010] Optionally, step S3 includes: S3.1, taking the set of subtasks as input, and combining the dependency relationships in the structured task requirements, analyze the data dependency and control dependency between each subtask; S3.2, perform topological sorting of each subtask based on dependencies and construct a directed acyclic graph; S3.3 divides the directed acyclic graph into multiple dependency layers, so that there are no dependencies between subtasks within the same dependency layer, thus allowing them to be executed in parallel; S3.4 outputs the directed acyclic graph dependency layer structure.

[0011] Optionally, step S4 includes: S4.1, with the directed acyclic graph dependency layer structure, acceptance criteria, structured task requirements, prior learning outputs, and experience retrieved from the experience system as inputs; S4.2, execute layer by layer according to the dependency layer order. For each subtask in the current layer, it is handed over as a tool to a sub-agent for execution. The sub-agent runs as an independent process group and returns the execution result in a structured data format. S4.3 When a subtask can still be further decomposed, the sub-agent recursively delegates it as a tool to the next level sub-agent for execution. S4.4 After the subtask is completed, the execution result is verified according to the corresponding acceptance criteria. If the verification fails, it is repaired and re-verified. S4.5 During execution, retrieve relevant experience from the experience system and inject it into the execution of the subtask; S4.6 summarizes the execution results of each subtask and outputs the generated RTL code and execution trajectory.

[0012] Optionally, step S5 includes: S5.1, using the execution trajectory as input; S5.2 utilizes a large language model to extract reusable experience from the execution trajectory; S5.3, deduplication and merging of newly extracted experience with existing experience; S5.4 stores the deduplicated and merged data in a structured format into the experience system; experiences generated from failed tasks are automatically filtered out and do not enter the experience system. S5.5 For the old experiences queried and used in this task, use the large language model to evaluate the validity and relevance of each validity. The evaluation results of validity include valid, partially valid and invalid, and the evaluation results of relevance include high, medium and low. Based on the results of validity and relevance, update the evaluation record and update the status of old experiences with invalid validity and low relevance to discard, and update the evaluation record of other old experiences.

[0013] Optionally, the experience system is used to store multiple experience entries, each of which consists of an interconnected first-level index entry and a second-level content file: the first-level index entry records the retrieval metadata of the experience entry in structured data, including at least a unique identifier, title, keywords, tags, status, and evaluation record, wherein the status indicates whether the experience entry is valid, and the evaluation record indicates its validity and relevance; the second-level content file records the knowledge content of the experience entry in natural language, including at least an overview, applicable scenarios, specific implementation, and common pitfalls; step S4 includes locating relevant experience entries in the first-level index by keyword matching based on the context of the current subtask, reading its corresponding second-level content file, and then injecting and executing it; step S5 includes writing the newly extracted experience into the second-level content file in the form of an entry, and establishing a corresponding index entry in the first-level index.

[0014] Furthermore, the present invention also provides an experience-driven adaptive multi-agent RTL code generation system, including an interconnected microprocessor and a memory, wherein the microprocessor is programmed or configured to execute the experience-driven multi-agent RTL code generation method.

[0015] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the experience-driven multi-agent RTL code generation method via a processor.

[0016] Furthermore, the present invention also provides a computer program product, including a computer program or instructions that are programmed or configured to execute the experience-driven multi-agent RTL code generation method via a processor.

[0017] Compared with existing technologies, this invention mainly achieves the following beneficial effects: To address the challenges faced by large language models in practical applications of RTL code generation, such as limited context windows, rigid static task decomposition strategies, inability to reuse cross-task knowledge, and difficulty in acquiring domain knowledge when facing unfamiliar domains, this invention's experience-driven multi-agent RTL code generation method addresses these challenges through three complementary mechanisms: First, the graph-structured recursive delegation mechanism implements the Agent-as-Tool paradigm, enabling each agent to process self-contained subtasks within a complete context and dynamically generate workflows based on task dependencies, rather than relying on predefined templates. Second, the structured experience system adopts a two-layer storage architecture of JSON index and Markdown files, combined with a grep-based retrieval mechanism, to extract reusable design patterns from execution trajectories and inject them into subsequent task contexts, achieving cross-task knowledge reuse without retraining the model. Third, the pre-learning mechanism identifies capability gaps during the task evaluation stage, generates simplified learning tasks, and enables agents to acquire domain knowledge before executing the target task. Through the three complementary mechanisms described above, this invention addresses the challenges faced by large language models in practical applications of RTL code generation, including limited context windows, rigid static task decomposition strategies, inability to reuse cross-task knowledge, and difficulty in acquiring domain knowledge when encountering unfamiliar domains. Furthermore, it improves task execution capabilities by accumulating design experience and filling capability gaps without retraining the underlying model, achieving experience-driven adaptive RTL code generation and thus enhancing the quality and efficiency of RTL code generation. Moreover, this invention's experience-driven multi-agent RTL code generation method utilizes a general-purpose large language model with strong reasoning capabilities by directly calling APIs, avoiding the model training costs associated with fine-tuning. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram illustrating the basic principle of the method in an embodiment of the present invention.

[0020] Figure 3 These are five workflow topologies generated through recursive delegation in this embodiment of the invention, wherein... Figure 3 (a) is a chained workflow topology. Figure 3 (b) is a parallel workflow topology. Figure 3 (c) represents the feedback loop workflow topology. Figure 3 (d) is a hierarchical workflow topology. Figure 3 (e) represents a hybrid workflow topology.

[0021] Figure 4 This is a schematic diagram of the experience retrieval process in an embodiment of the present invention.

[0022] Figure 5 This is a schematic diagram of the life cycle of experience in an embodiment of the present invention.

[0023] Figure 6 This is a schematic diagram of an empirical quality filtration process in an embodiment of the present invention. Detailed Implementation

[0024] To address the challenges faced by large language models in practical applications of RTL code generation, such as limited context windows, rigid static task decomposition strategies, lack of reusability of cross-task knowledge, and difficulty in acquiring domain knowledge when encountering unfamiliar domains, this invention aims to solve problems in three dimensions of context engineering through three complementary mechanisms. Hierarchical recursive delegation dynamically constructs execution workflows based on task structures and expands them at runtime, solving the problem of dynamic context assembly. A structured experience system extracts reusable design records from execution trajectories and injects them into subsequent task contexts, solving the problem of enriching cross-task contexts. A pre-learning mechanism identifies capability gaps during the task evaluation phase and generates simplified learning tasks to acquire domain knowledge before execution, solving the problem of runtime context generation when prior knowledge is insufficient.

[0025] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0026] like Figure 1 As shown, the experience-driven multi-agent RTL code generation method in this embodiment includes the following steps: S1, the refinement stage, includes taking the RTL design task described in natural language as input, clarifying and structuring the RTL design task through a large language model to output structured task requirements, which include task description, design goals, constraints, dependencies and success criteria. S2, the evaluation phase, includes evaluating the complexity and domain of the RTL design task using the structured task requirements as input. If the domain of the RTL design task exceeds the capabilities of the experience system, pre-learning of the experience system is triggered. The RTL design task is decomposed into a set of sub-tasks based on the complexity. Through the pre-learning mechanism, capability gaps can be identified in the evaluation phase to generate simplified learning tasks to obtain domain-specific patterns, and the obtained knowledge is injected into the target task context, enabling the method of this embodiment to handle tasks that exceed the scope of stored experience. S3, the planning phase, includes taking the set of subtasks as input, performing topological sorting based on the dependencies between subtasks, constructing a directed acyclic graph and dividing it into parallel executable dependency layers, and outputting the directed acyclic graph dependency layer structure. S4, the execution phase, includes taking the directed acyclic graph dependency layer structure, acceptance criteria, structured task requirements, and experience retrieved from the experience system as input, recursively delegating subtasks to sub-agents according to the dependency layer order, and verifying and repairing according to the acceptance criteria during execution, outputting the generated RTL code and execution trajectory; In this embodiment, the method solves the context engineering problem through hierarchical recursive delegation, drawing on the Agent-as-Tool concept and recursive generation idea, the framework implements delegation as an LLM native tool call, aligning the execution context of each sub-agent with its assigned subtask definition, and dynamically constructing the execution workflow according to the task structure; S5, Summary phase, includes taking the execution trajectory as input, extracting reusable experience from it and performing quality filtering, and storing the filtered experience in a structured form into the experience system.

[0027] like Figure 2 As shown, the method of this invention (ExperiCast) draws on the Agent-as-Tool concept and recursive generation idea, implementing recursive delegation as a native LLM tool call, allowing each agent to handle self-contained subtasks. Since RTL code describes a hardware structure that works in parallel, agents must maintain a complete design context and iteratively verify their outputs; these characteristics make recursive decomposition and dynamic orchestration necessary. This embodiment's method is built around a five-stage pipeline: Refine, Assess, Plan, Execute, and Summarize, which can be abbreviated as the ReAPES pipeline. In the ReAPES pipeline, the assessment stage embeds a pre-learning mechanism: when the framework detects that the current task exceeds the agent's existing experience (i.e., there is a capability gap), it automatically generates and executes a simplified learning task to acquire domain knowledge before proceeding to the planning stage. The five-stage pipeline implements a structured reasoning-action paradigm at the orchestration level. The framework's reasoning phase is comprised of three stages: refinement, evaluation, and planning. Refinement clarifies task requirements, evaluation measures complexity and decomposes the task into subtasks, and planning resolves dependencies between subtasks to form an execution topology. The execution phase constitutes the action phase, where agents execute subtasks according to the planned topology. During execution, each agent runs its own reasoning-action loop through tool calls and self-correction. When unexpected situations arise during execution (such as simulation failures requiring debugging), agents autonomously delegate corrective subtasks not anticipated in the initial plan, expanding the execution graph during runtime. The summary phase integrates the execution trajectories into structured experience and stores it in the experience system for reuse in future tasks.

[0028] In the refinement stage of step S1, the large language model clarifies the ambiguous natural language task description into structured requirements, generating structured task requirements that include task description, design goals, constraints, module dependencies, and success criteria. Specifically, in this embodiment, step S1 includes: S1.1, The RTL design task of obtaining the natural language description of the input; S1.2, Identify the task description, design goals, constraints, dependencies and success criteria in the RTL design task through the large language model, and eliminate ambiguity in the RTL design task by the large language model, supplement missing constraints and implicit dependencies, and complete the clarification of the RTL design task. S1.3, the clarified RTL design task is transformed into a structured representation to obtain structured task requirements, which include task description, design goals, constraints, dependencies, and success criteria. As an optional implementation, the structured task requirements in this embodiment are stored in a JSON file.

[0029] It's important to note that the primary criterion for success is functional correctness. RTL code generation differs fundamentally from general software code generation. Software code typically describes sequentially executed operations, while RTL code describes hardware structures that operate in parallel. In Verilog, always blocks, assign statements, and module instantiation express parallel hardware behavior rather than sequential instruction sequences. RTL designs must ultimately meet strict timing requirements to achieve physical implementation, although the primary focus at the RTL stage is the functional correctness of the described circuit behavior. Signal bit widths, signed attributes, and cross-module interface matching must be consistently specified. Verification of RTL correctness is typically performed through an iterative design-verification-debug cycle, generally relying on simulation test platforms, and in advanced workflows, formal verification tools are also used. These characteristics collectively drive the need for automated RTL generation systems. This embodiment uses functional correctness as the primary evaluation criterion, a fundamental requirement for any RTL design and a standard metric adopted by mature benchmarks such as VerilogEval and RTLLM.

[0030] In this embodiment, step S2 includes: S2.1, taking the structured task requirements as input, evaluate the domain knowledge and complexity involved in the RTL design task; in this embodiment, for structured task requirements stored in JSON files, the large language model evaluates them from three dimensions according to domain-specific complexity rules: structural complexity (number of modules, number of interface signals, data path width), verification complexity (simulation testing, waveform inspection, multi-scenario coverage), and integration complexity (module interface matching, timing constraints, bit width consistency), and comprehensively gives the complexity level (low / medium / high, divided according to the estimated number of tool call rounds: less than or equal to 3 rounds is low, 3 to 8 rounds is medium, and more than 8 rounds is high). S2.2 Determine whether the following two conditions are met simultaneously: the domain knowledge involved in the RTL design task can be covered by the experience system and the complexity involved in the RTL design task does not exceed the preset level. If both conditions are met, proceed to step S2.4; otherwise, determine that the complexity and domain of the RTL design task exceed the requirements and proceed to step S2.3. S2.3, determine whether the number of times the pre-learning is triggered exceeds the preset threshold. If it exceeds the preset threshold, end and exit. Otherwise, trigger the pre-learning of the experience system to enhance the domain knowledge covered by the experience system, and jump to step S2.2. S2.4, based on the complexity of the RTL design task, decompose the RTL design task into several subtasks, and define verifiable acceptance criteria for each subtask; based on the level of complexity, the large language model space can decompose the RTL design task into a set of subtasks, and split them according to the task granularity rules (each independent file, module or component corresponds to a subtask). At this stage, the subtasks are identified but their interdependencies have not yet been determined. S2.5 outputs the set of subtasks consisting of each subtask and its acceptance criteria.

[0031] It should be noted that the pre-learning in step S2 is triggered after the evaluation phase and before the planning phase. As pre-learning is embedded within the evaluation phase and triggered on demand by the detection results of the evaluation phase, it can be set to enter pre-learning only when the following three conditions are met simultaneously, otherwise directly enter the planning phase: (1) the current agent is the top-level agent (depth=0), and the sub-agents do not trigger pre-learning; (2) the large language model in the evaluation phase determines that the flag need_learning for pre-learning is true, that is, the domain-specific experience is insufficient or the task complexity is medium or above and the experience base coverage is insufficient; (3) the pre-learning function is not disabled through environment variables. In the evaluation phase, the method of this embodiment analyzes the task complexity and decomposes the sub-tasks, while identifying the capability gaps and deciding whether to trigger pre-learning. The flag indicating the need for prior learning is determined by the large language model during the evaluation phase based on the following conditions: (1) the number of experience entries in the experience system that match the keywords of the current task is less than the threshold τ (default τ=2); (2) the task is assigned a high complexity score; (3) the task involves domain terms or design patterns that the large language model marks as "unfamiliar" in the evaluation response. When any of the above conditions are met, the large language model can set the flag indicating the need for prior learning to true, thereby entering the prior learning phase.

[0032] The goal of pre-learning is to enhance the domain knowledge covered by the experiential system. It can be implemented in the desired manner, for example, by orchestrating intelligent agents to enhance the domain knowledge covered by the experiential system. S2.3.1, Use a large language model to evaluate the experience system and extract a set of capability gaps from the evaluation results. , where any i-th gap Represents knowledge in a specific domain; S2.3.2, for each notch Generate simplified learning tasks ,follow The principles, among which For difficulty, Capacity gap set The target task; S2.3.3, Utilize a large language model to execute each gap Simplified learning tasks Receive learning output log This includes code implementation and execution logs; S2.3.4 packages the learning outputs (code implementation and execution logs) into a structured context and injects it into the execution phase of the formal task, providing specific code references for subsequent agents. This is to achieve compliance... This goal can be achieved by instructing the large language model to adhere to three heuristic constraints to limit the difficulty: (a) the number of subtasks in the learning task does not exceed half that of the target task; (b) the learning task does not require cross-module interface matching; and (c) the number of acceptance criteria for the learning task is less than that of the target task. These constraints are enforced at the prompt word level and have not yet been procedurally validated. The design of the learning tasks follows two principles: (1) coverage, with each learning task covering the core knowledge gaps; and (2) transferability, with the learning outputs directly applicable to the target task.

[0033] In the planning phase of step S3, the method of this embodiment takes the set of subtasks generated in the evaluation phase as input, analyzes the data dependencies and execution order relationships between the subtasks using a large language model (e.g., the top-level integration module depends on the output of the functional module), and constructs a directed acyclic graph (DAG) by topologically sorting the dependencies between the subtasks, where nodes are subtasks and edges are dependencies. Topological sorting divides the subtasks into multiple dependency layers. Subtasks within the same dependency layer have no dependencies and can be executed in parallel; different dependency layers have a sequential order, with the successor layer starting only after the predecessor layer is completed. Specifically, in this embodiment, step S3 includes: S3.1, taking the set of subtasks as input, and combining the dependency relationships in the structured task requirements, analyze the data dependency and control dependency between each subtask; S3.2, perform topological sorting of each subtask based on dependencies and construct a directed acyclic graph (DAG). S3.3 divides the directed acyclic graph into multiple dependency layers, so that there are no dependencies between subtasks within the same dependency layer, thus allowing them to be executed in parallel; S3.4, outputs a directed acyclic graph dependency layer structure. In this embodiment, the five workflow topologies dynamically generated at runtime by the various recursive delegation mechanisms described above are as follows: Figure 3 As shown, where Figure 3 (a) is a chained workflow topology. Figure 3 (b) is a parallel workflow topology. Figure 3 (c) represents the feedback loop workflow topology. Figure 3 (d) is a hierarchical workflow topology. Figure 3 (e) represents a hybrid workflow topology, where the workflow topology is dynamically determined at runtime by the delegation relationship.

[0034] In the execution phase of step S4, the method of this embodiment implements the main tool call loop. In this embodiment, step S4 includes: S4.1, with the directed acyclic graph dependency layer structure, acceptance criteria, structured task requirements, prior learning outputs, and experience retrieved from the experience system as inputs; S4.2, execute layer by layer according to the dependency layer order. For each subtask in the current layer, it is handed over as a tool to a sub-agent for execution. The sub-agent runs as an independent process group and returns the execution result in a structured data format. S4.3 When a subtask can still be further decomposed, the sub-agent recursively delegates it as a tool to the next level sub-agent for execution. S4.4 After the subtask is completed, the execution result is verified according to the corresponding acceptance criteria. If the verification fails, it is repaired and re-verified. S4.5 During execution, retrieve relevant experience from the experience system and inject it into the execution of the subtask; S4.6 summarizes the execution results of each subtask and outputs the generated RTL code and execution trajectory.

[0035] like Figure 2 As shown, the experience system in this embodiment is used to store multiple experience entries. Each experience entry consists of an interrelated first-level (L1) index entry and a second-level (L2) content file. The first-level index entries record the retrieval metadata of the experience entry in structured data, including at least a unique identifier (ID), title, keywords, tags, status (active / deprecated), and evaluation record (including validity and relevance). The status indicates whether the experience entry is valid, and the evaluation record indicates its validity and relevance. It can be stored in a JSON index file (index.json). The second-level content file records the knowledge content of the experience item in natural language, including at least an overview, applicable scenarios, specific implementation and common pitfalls. It can be stored in Markdown files, with each experience item corresponding to one file, forming a self-contained knowledge unit that is human-readable and parsable by a large language model.

[0036] Step S4 includes locating relevant experience entries in the first-level index by keyword matching based on the context of the current subtask, reading the corresponding second-level content file, and then injecting and executing it; Step S5 includes writing the newly extracted experience into the second-level content file in the form of entries, and creating corresponding index entries in the first-level index.

[0037] The experience system in this embodiment adopts a two-layer storage architecture, which supports a grep-based retrieval mechanism. It extracts reusable design records from the execution trajectory and injects relevant experience into the context of subsequent tasks, achieving cross-task knowledge reuse without model retraining. Figure 4As shown, in step S4.1, when the experience retrieved from the experience system is used as input, this includes using the grep command "grep keyword" to search for matching entries in the L1-level JSON index file (index.json) by keyword, then using the jq command to extract the complete metadata of the matching entries (including the file path of L2), and finally using the cat command to read the L2-level Markdown file to obtain the complete experience content. Then, the experience pattern is detected, and the retrieved experience execution context is injected into the current execution context. Here, the experience pattern refers to the reusable design patterns and verification strategies stored in the experience system, such as how to design FIFO overflow protection, how to implement secure coding of state machines, etc. The detection method is as follows: During the execution phase, the agent uses the grep command to search for matching experience entries in the L1-level JSON index based on the keywords of the current subtask, then uses the jq command to extract the complete metadata, and finally uses the cat command to read the L2-level Markdown file to obtain the complete experience content. The detected experience is injected into the agent's execution context as a context reference to guide the implementation of the current task—the agent can refer to the design patterns in the experience to choose an implementation scheme and refer to common pitfalls to avoid known errors. In terms of experience retrieval, this embodiment (ExperiCast) uses a lightweight lexical retrieval pipeline built on grep, jq, and cat, rather than retrieval augmentation generation (RAG). This choice is based on four considerations: (1) avoiding reliance on embedding models, which may introduce domain mismatches in RTL-specific corpora; (2) flexibility and editability, as experience files stored in pure Markdown can be directly read and verified by engineers; (3) natural compatibility with agent toolchains, as large language model agents can natively execute grep and cat commands; and (4) determinism, as precise string matching produces reproducible results. Recent research on agent retrieval has shown that lexical search can match or even outperform semantic vector search in the agent retrieval loop, further supporting the choice of lightweight lexical methods.

[0038] The intelligent agents used in step S4.2 include a top-level intelligent agent and sub-intelligent agents. The top-level intelligent agent, according to the planned topology, delegates subtasks within each dependency layer to the sub-intelligent agents in parallel. Each sub-intelligent agent is created via the `delegate_task` command, runs in an independent process group, and completes the subtask through `execute_command` tool calls and self-correction. The input to the delegation is a subtask description and its context (including refined JSON structured task requirements, relevant experience keywords, and prior learning outputs, injected into the sub-intelligent agent via system prompts). The output is a structured execution result (including execution status, tool call rounds, final response, and standard output summary), returned to the parent intelligent agent in JSON format. When unexpected problems occur during execution (such as simulation failure or specification ambiguity), the intelligent agent autonomously expands the execution graph through a verification-repair loop: if the subtask includes acceptance criteria, this embodiment automatically delegates a verification sub-intelligent agent to check the execution result; if verification fails, the reason for the failure is passed to the repair sub-intelligent agent for targeted repair, and verification is retried after repair, with a maximum of two retry rounds. If the repair retries exhaust all attempts and the problem still fails, this embodiment triggers a re-evaluation. The large language model selects strategies based on the failure history, such as splitting the task into smaller subtasks, simplifying the implementation, skipping the task, or retrying using a different method. In this embodiment, experience extraction is completed by the large language model from the execution log through structured hints during the summary phase. The experience output by the large language model includes five core content fields (title, problem description, solution mechanism, principle explanation, common pitfalls) and metadata fields (keywords, tags, quality rating, lessons learned). Subsequently, this embodiment automatically converts the experience into L1 JSON entries and corresponding L2 Markdown file formats for storage. The large language model simultaneously excludes general known knowledge and task-specific implementation details, retaining only design patterns and validation strategies with cross-task reusability. This design is based on three considerations: (1) an abstract design pattern record may be sufficient to handle module-level tasks, since RTL generation mainly involves selecting design patterns rather than reusing specific code snippets; (2) pre-learning provides concrete implementation examples when the agent needs detailed references beyond the abstract patterns; and (3) the L2 file is human-readable and portable, forming self-contained knowledge units that can be understood and verified by both large language models and human engineers.

[0039] In step S4.5, the process of retrieving and utilizing experience is as follows: The agent uses the `grep` command to search for matching entries in the L1-level JSON index based on the keywords of the current subtask; since `grep` only returns matching lines without complete metadata, `jq` is used to extract the complete information of the matching entries (including unique identifiers and L2 file paths); finally, `cat` is used to read the L2-level Markdown file to obtain the complete experience content. The retrieved experience is injected into the agent's execution context in the form of a structured context. The agent refers to the design patterns within this context to select an implementation scheme and avoids known errors by referring to common pitfalls.

[0040] Figure 5 This is a schematic diagram of the experience lifecycle in this embodiment. The operations within the lifecycle include: 1. Generation; 2. Integration; 3. Query (retrieval); 4. Evaluation; 5. Update / discard / delete. Figure 5 In this embodiment, ① represents generation → integration / consolidation: After the experience is extracted from the execution log during the summary phase, it is deduplicated and merged into the experience system for subsequent task queries. ② represents integration / consolidation → query: After the integrated experience is stored in the experience repository, it can be retrieved by agents through keyword searches and injected into the execution context during the execution phase. ③ represents query → evaluation: The queried and used experience is evaluated by the large language model from two dimensions: effectiveness and relevance after the task is completed. ④ represents evaluation → update / discard / delete: Based on the evaluation results, the old experience is updated (improved content), discarded (marked as deprecated), or deleted. ⑤ represents update / discard / delete → generation: After the experience system is updated, it enters the next round of task execution, and the new execution trajectory will produce new experience again, forming a complete experience lifecycle. In this embodiment, in the summary phase of step S5, the method extracts structured experience from the execution logs of all sub-agents, filters it for quality, and stores it in the experience system for future task reuse. In this embodiment, step S5 includes: S5.1, using the execution trajectory as input; S5.2 utilizes a large language model to extract reusable experience from the execution trajectory; S5.3, deduplication and merging of newly extracted experience with existing experience; S5.4 stores the deduplicated and merged data in a structured format into the experience system; experiences generated from failed tasks are automatically filtered out and do not enter the experience system. S5.5 For the old experiences queried and used in this task, the large language model is used to evaluate the validity and relevance of each validity. The evaluation results of validity include valid, partially valid and invalid, and the evaluation results of relevance include high, medium and low. Based on the results of validity and relevance, the evaluation records of old experiences with invalid validity and low relevance are updated and their status is updated to deprecated (marked as deprecated, and automatically excluded in subsequent queries), and the evaluation records of other old experiences are updated.

[0041] See Figure 5 The filtering process, based on pre-defined rules, can be performed in both the experience generation and integration phases. In the generation phase, when the large language model extracts experience from the execution log using structured prompts, it filters according to the following rules: excluding generalized common sense (such as modular design, code documentation, and other software engineering knowledge), task-specific details (complete implementations of specific modules, lacking cross-task reuse value), statements without information (correct but instructive descriptions), and duplicate topics (content already covered by keywords). The default is `should_keep=False`, meaning experience is only retained if the large language model determines it has reuse value. In the integration phase, this embodiment deduplicates newly extracted experience with existing experience: it determines duplication by semantic comparison of title topics and core knowledge points; if duplicates are found, keywords and supplementary content are merged instead of creating new entries. For previously queried and used experience, the large language model evaluates it from two dimensions: validity (valid / partially valid / invalid) and relevance (high / medium / low). Experiences deemed invalid or with low relevance are marked as deprecated and automatically excluded from subsequent queries. Furthermore, experience generated from failed tasks is automatically filtered during the integration phase and not added to the experience repository. like Figure 6As shown, ⑥ indicates applying filtering rules → default rejection: Newly extracted experiences are first screened using preset filtering rules (excluding generalized common sense, task-specific details, statements without information, and duplicate topics). The system default setting is should_keep=False, meaning experiences are only retained if the large language model determines they have reuse value. ⑦ indicates default rejection → deduplication: Experiences that pass the initial screening enter the deduplication stage. Semantic comparison of the title, topic, and core knowledge points determines whether they duplicate existing experiences. If duplicates are found, keywords and supplementary content are merged instead of creating new entries. ⑧ indicates deduplication → evaluation feedback: The deduplicated new experiences, along with the old experiences queried in this task, enter the evaluation feedback stage. The large language model evaluates them from two dimensions: effectiveness (effective / partially effective / ineffective) and relevance (high / medium / low). ⑨ indicates evaluation feedback → update or discard: Based on the evaluation feedback results, old experiences are either updated (improved content or summary) or discarded (marked as deprecated and automatically excluded in subsequent queries). Experiences generated from tasks that fail are automatically filtered out and not added to the experience database. Figure 6 The "default rejection" refers to the conservative strategy adopted by the system for newly extracted experiences during the experience generation stage: the default setting is should_keep=False (i.e., not retained by default), and should_keep is only set to true and retained when the large language model determines that the experience has cross-task reuse value through quality filtering rules. Specifically, the large language model needs to confirm that the experience does not belong to the following four categories of filtered content: (1) generalized common sense; (2) task-specific details; (3) statements without information; (4) duplicate topics. Only experiences that pass these four categories of filtering will be retained in the database. In addition, when the output of the large language model cannot be parsed into valid JSON, the system also defaults to rejection to prevent low-quality experiences from entering the experience database. Default rejection (should_keep=False): Only when the large language model determines that the experience does not belong to generalized common sense, task-specific details, statements without information, or duplicate topics will it be retained (should_keep=True); the large language model output cannot be parsed, and it is also rejected by default.

[0042] To verify the effectiveness of the method in this embodiment (ExperiCast), it is evaluated on two mature RTL code generation benchmarks: VerilogEval v2, a comprehensive benchmark containing 156 Verilog design problems organized by difficulty. Each problem includes a natural language specification and a testbed for automated verification. The ability to generate correct implementations from the specification is evaluated using the spec-to-rtl dataset. RTLLM v2.0 is an open-source benchmark containing 50 designs, covering four categories: arithmetic (21 designs, including adders, multipliers, dividers, and comparators), storage (5 designs, including FIFO, LIFO, RAM, and ROM), control (10 designs, including finite state machines, counters, and frequency dividers), and others (14 designs, including edge detectors, synchronizers, and converters). In this embodiment, the top k pass rate (Pass@k) defined by VerilogEval is used to evaluate the generation quality. For each problem, let... To generate the number of samples, The number of functionally correct samples is defined as follows: ; in, Let this be the expected value of the problem. Pass@1 represents the expected proportion of a single sampled candidate problem solved. In the specific implementation of the method in this embodiment (ExperiCast), the large language model backbone is MiMo-V2.5-Pro ​​(with thinking mode enabled), accessed via the OpenAI compatible API. MiMo-V2.5-Pro's thinking mode uses fixed sampling parameters (temperature=1.0, top_p=0.95); the results are from a single run, and repeated experiments may differ. Simulation tools include iverilog v12.0 and vvp for Verilog syntax checking and functional simulation. Each agent is allocated a maximum of 40 rounds of tool calls. A strict test platform isolation protocol is adopted: during generation and debugging, the agent can only access task prompts and module interface definitions, and can generate its own test platform for self-checking, but cannot access the benchmark test platform, reference implementation, or simulation error messages used to evaluate the method in this embodiment. After the agent generates the final code, the evaluation phase independently loads the official test platform and only reports PASS or FAIL. Under the evaluation protocol, the pre-learning tasks are only executed and summarized, skipping the refinement, evaluation, and planning phases to prevent recursive learning from being triggered. The root agent skips the summary phase to reduce evaluation time and token consumption. A configuration using the experience system preloads 29 general hardware design experience entries, covering basic RTL coding specifications, common pitfalls, and verification strategies. The method of this embodiment (ExperiCast) is compared with three major baselines. Finally, the Pass@1 comparison results (156 designs) on the VerilogEval v2 benchmark are shown in Table 1.

[0043]

[0044] In the Pass@1 (%) column of Table 1, (1) is the reference test platform provided by the benchmark during the generation and debugging process. ChipCraftBrain reports the mean of 7 runs (best: 98.7%). (2) is the test platform that only uses agent generation during the generation process; the benchmark platform is only used for the final evaluation. As can be seen from Table 1, Plain LLM means direct large language model generation of this embodiment without using any agents (MiMo-V2.5-Pro). MAGE is a multi-agent RTL generation system, whose original paper reports a 95.7% achievement on VerilogEval using Claude 3.5 Sonnet and the reference test platform provided by the benchmark. CodeV-R1 performs inference-enhanced generation (68.8% on VerilogEval). To control for differences in the backbone model, MAGE was re-evaluated under the same backbone model and test platform access strategy (MiMo-V2.5-Pro, test platform using only agent generation). The Pass@1 metric of this embodiment (ExperiCast) is 97.4, achieving a Pass@1 rate of 97.4% with a full configuration, comparable to the average of 97.2% reported by ChipCraftBrain (best run: 98.7%). More notably, ExperimentCast, using only agent-generated testbeds during the generation process (97.4%), still outperformed the MAGE reproduction (96.2%) using the reference testbed provided by the benchmark, leading by 1.2 percentage points. Under the same backbone model and testbed access conditions (MiMo-V2.5-Pro, agent-generated testbed only), ExperimentCast (97.4%) outperformed MAGE (82.7%) by 14.7 percentage points, demonstrating the contribution of the method design in this embodiment. On RTLLM v2.0, the method in this embodiment (ExperiCast) achieved a pass@1 of 80.0%, which is 16.2 percentage points higher than QiMeng-CRUX (63.8%) and 4.2 percentage points higher than ChipMATE (75.8%).

[0045] To evaluate the contribution of each component of the method in this embodiment (ExperiCast), six configurations were evaluated as shown in Table 2.

[0046]

[0047] In the top-level modes of Table 2, "O" represents orchestration, "E" represents execution, and "-" indicates inapplicability. In this embodiment, a core progressive chain (Plain LLM, Orchestration-only, ExperimentCast-Orch, ExperimentCast) is used to progressively introduce dynamic orchestration, pre-learning, and the experience system. Two single-agent configurations (ExperiCast-Fast, ExperimentCast-Fast+Exp) provide supplementary perspectives. Note that pre-learning runs during the evaluation phase and cannot be isolated in single-agent configurations. The final ablation results on VerilogEval v2 are shown in Table 3.

[0048]

[0049] As shown in Table 3, Orchestration-only (79.5%) improved by 3.9 percentage points compared to Plain LLM (75.6%), indicating that dynamic orchestration provides baseline gains through structured task decomposition and self-correction. ExperiCast-Orch (86.5%) further outperformed Orchestration-only by 7.0 percentage points, attributed to the pre-learning mechanism that fills the knowledge gaps in unfamiliar tasks. ExperiCast Full Configuration (97.4%) achieved the highest results, with the experience system contributing an additional 10.9 percentage points. ExperiCast-Fast (81.4%), despite lacking explicit task decomposition, still outperformed Orchestration-only (79.5%). One possible explanation is that, with MiMo-V2.5-Pro's 1 million-token context window, a single agent can accommodate the complete task context without decomposition, and the information loss introduced by explicit subtask boundaries outweighs the gains brought by orchestration on these benchmarks. The ExperiCast-Fast+Exp (94.2%) results demonstrate that the experience system itself can significantly improve single-agent performance, indicating that high-quality experience records can provide effective guidance even without orchestration or pre-learning. The comparison between ExperiCast-Orch and Orchestration-only isolates the effects of pre-learning in the orchestration pipeline (+7.0pp). The comparison between ExperiCast Full Configuration and ExperiCast-Orch isolates the effects of the experience system in the orchestration pipeline (+10.9pp). The comparison between ExperiCast-Fast+Exp and ExperiCast-Fast isolates the effects of the experience system in a single-agent environment (+12.8pp). These results suggest that the components of the method in this embodiment (ExperiCast) provide complementary gains rather than operating independently.

[0050] As can be seen, the experience-driven multi-agent RTL code generation method in this embodiment solves the context engineering problem through hierarchical recursive delegation, a two-layer storage architecture, a structured experience system based on grep retrieval, and a pre-learning mechanism for capability gap compensation. On VerilogEval v2 and RTLLM v2.0, ExperimentCast achieved Pass@1 of 97.4% and 80.0%, respectively. Under the same backbone model and test platform access conditions (MiMo-V2.5-Pro, a test platform using only agent generation), ExperimentCast outperformed MAGE by 14.7 percentage points on VerilogEval v2. Ablation studies show that the three components all contribute complementaryly to the overall performance, and the complete method in this embodiment achieves a gain of 21.8 percentage points compared to the pure large language model baseline. This embodiment addresses the challenges faced by large language models in RTL code generation, including limited context windows, rigid static task decomposition strategies, inability to reuse cross-task knowledge, and difficulty in acquiring domain knowledge in unfamiliar domains. It improves task execution capabilities by accumulating design experience and filling capability gaps without retraining the underlying model, achieving experience-driven adaptive RTL code generation, thereby improving the quality and efficiency of RTL code generation. Furthermore, this experience-driven multi-agent RTL code generation method utilizes a general-purpose large language model with strong reasoning capabilities by directly calling APIs, avoiding the model training costs associated with fine-tuning.

[0051] Furthermore, the present invention also provides an experience-driven adaptive multi-agent RTL code generation system, including an interconnected microprocessor and a memory, wherein the microprocessor is programmed or configured to execute the experience-driven multi-agent RTL code generation method.

[0052] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the experience-driven multi-agent RTL code generation method via a processor.

[0053] Furthermore, the present invention also provides a computer program product, including a computer program or instructions that are programmed or configured to execute the experience-driven multi-agent RTL code generation method via a processor.

[0054] Those skilled in the art will understand that the technical solutions provided by this invention may take the form of a method, system, or computer program product. Therefore, this invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this invention may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce an implementation of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0055] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. An experience-driven multi-agent RTL code generation method, characterized in that, Includes the following stages: S1, the refinement stage, includes taking the RTL design task described in natural language as input, clarifying and structuring the RTL design task through a large language model to output structured task requirements. These structured task requirements include task description, design goals, constraints, dependencies, and success criteria. S2, Evaluation phase, including evaluating the complexity and domain of the RTL design task with the structured task requirements as input. If the domain of the RTL design task exceeds the capabilities of the experience system, the prior learning of the experience system is triggered. Decompose the RTL design task into a set of subtasks based on complexity; S3, the planning phase, includes taking the set of subtasks as input, performing topological sorting based on the dependencies between subtasks, constructing a directed acyclic graph and dividing it into parallel executable dependency layers, and outputting the directed acyclic graph dependency layer structure. S4, Execution phase, includes taking the directed acyclic graph dependency layer structure, acceptance criteria, structured task requirements and experience retrieved from the experience system as input, recursively delegating subtasks to sub-agents according to the dependency layer order, verifying and repairing according to the acceptance criteria during execution, and outputting the generated RTL code and execution trajectory; S5, Summary phase, includes taking the execution trajectory as input, extracting reusable experience from it and performing quality filtering, and storing the filtered experience in a structured form into the experience system.

2. The experience-driven multi-agent RTL code generation method according to claim 1, characterized in that, Step S1 includes: S1.1, The RTL design task of obtaining the natural language description of the input; S1.2, Identify the task description, design goals, constraints, dependencies and success criteria in the RTL design task through the large language model, and eliminate ambiguity in the RTL design task by the large language model, supplement missing constraints and implicit dependencies, and complete the clarification of the RTL design task. S1.3 transforms the clarified RTL design task into a structured representation to obtain structured task requirements, which include task description, design goals, constraints, dependencies, and success criteria.

3. The experience-driven multi-agent RTL code generation method according to claim 1, characterized in that, Step S2 includes: S2.1, Using the structured task requirements as input, evaluate the domain knowledge and complexity involved in the RTL design task; S2.2 Determine whether the following two conditions are met simultaneously: the domain knowledge involved in the RTL design task can be covered by the experience system and the complexity involved in the RTL design task does not exceed the preset level. If both conditions are met, proceed to step S2.4; otherwise, determine that the complexity and domain of the RTL design task exceed the requirements and proceed to step S2.

3. S2.3, determine whether the number of times the pre-learning is triggered exceeds the preset threshold. If it exceeds the preset threshold, end and exit. Otherwise, trigger the pre-learning of the experience system to enhance the domain knowledge covered by the experience system, and jump to step S2.

2. S2.4 Decompose the RTL design task into several sub-tasks according to the complexity of the RTL design task, and define verifiable acceptance criteria for each sub-task. S2.5 outputs the set of subtasks consisting of each subtask and its acceptance criteria.

4. The experience-driven multi-agent RTL code generation method according to claim 1, characterized in that, Step S3 includes: S3.1, taking the set of subtasks as input and combining the dependency relationships in the structured task requirements, analyze the data dependency and control dependency between each subtask; S3.2, perform topological sorting of each subtask based on dependencies and construct a directed acyclic graph; S3.3 divides the directed acyclic graph into multiple dependency layers, so that there are no dependencies between subtasks within the same dependency layer, thus allowing them to be executed in parallel; S3.4 outputs the directed acyclic graph dependency layer structure.

5. The experience-driven multi-agent RTL code generation method according to claim 1, characterized in that, Step S4 includes: S4.1, with the directed acyclic graph dependency layer structure, acceptance criteria, structured task requirements, prior learning outputs, and experience retrieved from the experience system as inputs; S4.2, execute layer by layer according to the dependency layer order. For each subtask in the current layer, it is handed over as a tool to a sub-agent for execution. The sub-agent runs as an independent process group and returns the execution result in a structured data format. S4.3 When a subtask can still be further decomposed, the sub-agent recursively delegates it as a tool to the next level sub-agent for execution. S4.4 After the subtask is completed, the execution result is verified according to the corresponding acceptance criteria. If the verification fails, it is repaired and re-verified. S4.5 During execution, retrieve relevant experience from the experience system and inject it into the execution of the subtask; S4.6 summarizes the execution results of each subtask and outputs the generated RTL code and execution trajectory.

6. The experience-driven multi-agent RTL code generation method according to claim 1, characterized in that, Step S5 includes: S5.1, using the execution trajectory as input; S5.2 utilizes a large language model to extract reusable experience from the execution trajectory; S5.3, deduplication and merging of newly extracted experience with existing experience; S5.4 stores the deduplicated and merged data in a structured format into the experience system; experiences generated from failed tasks are automatically filtered out and do not enter the experience system. S5.5 For the old experiences queried and used in this task, use the large language model to evaluate the validity and relevance of each validity. The evaluation results of validity include valid, partially valid and invalid, and the evaluation results of relevance include high, medium and low. Based on the results of validity and relevance, update the evaluation record and update the status of old experiences with invalid validity and low relevance to discard, and update the evaluation record of other old experiences.

7. The experience-driven multi-agent RTL code generation method according to claim 1, characterized in that, The experience system is used to store multiple experience entries. Each experience entry consists of an interconnected first-level index entry and a second-level content file. The first-level index entry records the retrieval metadata of the experience entry in structured data, including at least a unique identifier, title, keywords, tags, status, and evaluation record. The status indicates whether the experience entry is valid, and the evaluation record indicates its validity and relevance. The second-level content file records the knowledge content of the experience entry in natural language, including at least an overview, applicable scenarios, specific implementation, and common pitfalls. Step S4 includes locating relevant experience entries in the first-level index by keyword matching based on the context of the current subtask, reading their corresponding second-level content file, and then injecting and executing them. Step S5 includes writing the newly extracted experience into the second-level content file in the form of an entry and creating a corresponding index entry in the first-level index.

8. An experience-driven adaptive multi-agent RTL code generation system, comprising interconnected microprocessors and memory, characterized in that, The microprocessor is programmed or configured to execute the experience-driven multi-agent RTL code generation method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the experience-driven multi-agent RTL code generation method of any one of claims 1 to 7 via a processor.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the experience-driven multi-agent RTL code generation method of any one of claims 1 to 7 via a processor.

Images