Hardware design method and apparatus

Abstract

Embodiments of the present application provide a hardware design method and device. The method comprises: obtaining a design task and design specification; if the proportion of description information of graphical hardware with specific spatial or timing semantics in the design specification does not exceed a preset proportion threshold, determining that the design task is a text dominant task, and generating register transfer level code through a large language model according to the text dominant task and the corresponding design specification; otherwise, determining that the design task is a component dominant task, calling a tool through a large language model according to the component dominant task and the corresponding design specification; and generating register transfer level code according to the tool; the tool comprises a retrieval enhanced knowledge base, a rule type script and an electronic design automation simulation verification tool. The scheme of the present application improves the accuracy of hardware design.

Description

Technical Field

[0001] This application relates to the field of chip design, and more particularly to a hardware design method and apparatus. Background Technology

[0002] In modern chip development, hardware design automation is a core element in ensuring design efficiency and quality. Designers need to complete the transformation from natural language requirements to synthesizable hardware logic through processes such as register-transfer-level (RTL) code generation, functional verification, and debugging and optimization.

[0003] Current RTL code generation solutions mostly rely on large language models to generate RTL code based on task requirements. However, this approach can lead to design intent deviations or functional errors, resulting in poor accuracy of the generated RTL code. Summary of the Invention

[0004] The hardware design method and apparatus provided in this application are used to improve the accuracy of hardware design.

[0005] In a first aspect, embodiments of this application provide a method, including:

[0006] In one possible implementation, a design task and a design specification are obtained; the design specification includes a description of the design specifications, functions, and implementation logic of the design task.

[0007] If the proportion of the description information of graphical hardware with specific spatial or temporal semantics in the design specification does not exceed a preset proportion threshold, the design task is determined to be a text-driven task. Based on the text-driven task and the corresponding design specification, register transfer level code is generated through a large language model.

[0008] Otherwise, the design task is determined to be a component-driven task. Based on the component-driven task and the corresponding design specifications, the tool is invoked through the large language model; and register transfer level code is generated based on the tool; the tool includes a retrieval-enhanced knowledge base, rule-based scripts, and electronic design automation simulation verification tools.

[0009] In one possible implementation, the step of generating register-transfer level code based on the text-driven task and the corresponding design specifications using a large language model includes:

[0010] Using the large language model, the text-driven task is decomposed to obtain a list of design requirements for the text-driven task.

[0011] Based on the design requirements list, a logical framework is constructed; the logical framework is used to define the constituent modules of the hardware design corresponding to the text-driven task, the functions of the constituent modules, and the connection relationships between the constituent modules.

[0012] Based on the aforementioned logical framework, the register transfer level code is generated.

[0013] In one possible implementation, the step of invoking the tool through the large language model based on the component-driven task and the corresponding design specifications includes:

[0014] According to the design specifications, the component-driven task is broken down into multiple sub-tasks using the large language model.

[0015] Based on the functional requirements of each subtask, the corresponding tools for each subtask are invoked through the large language model.

[0016] In one possible implementation, the step of calling the corresponding tools for each subtask based on the functional requirements of each subtask through the large language model includes:

[0017] Obtain tool information for each tool in the tool library; the tool information includes tool function, parameter requirements, and output format.

[0018] Based on the functional requirements of each subtask and the tool information, the tool that matches the functional requirements of each subtask is determined through the large language model.

[0019] The tool corresponding to each subtask is invoked through the model context protocol server.

[0020] In one possible implementation, generating register-transfer level code according to the tool includes:

[0021] The tool is used to execute the sub-tasks corresponding to the tool and generate execution results.

[0022] Based on the execution result, the register transfer level code is generated using the large language model.

[0023] In one possible implementation, the method further includes:

[0024] The syntax and functionality of the register transfer level code are verified;

[0025] If the syntax and functionality are both correct, then the register transfer level code is correct.

[0026] Otherwise, the register transfer level code is determined to be faulty.

[0027] In one possible implementation, verifying the syntax and functionality of the register transfer level code includes:

[0028] The register-transfer-level code is compiled, and the compiled register-transfer-level code is compared with preset syntax rules. If the comparison is consistent, the register-transfer-level code is determined to be syntactically correct; otherwise, the register-transfer-level code is determined to be syntactically incorrect.

[0029] The simulation test verifies whether the function of the register transfer level code is consistent with the requirements of the design task; if it is consistent, the function of the register transfer level code is determined to be correct; otherwise, the function of the register transfer level code is determined to be incorrect.

[0030] In one possible implementation, the method further includes:

[0031] If the register-transfer level code of the text-driven task is faulty, then based on the error information from the simulation test, the faulty step in generating the register-transfer level code is determined by the large language model.

[0032] The steps containing errors are iteratively optimized to ensure that the register transfer level code is correct.

[0033] In one possible implementation, the method further includes:

[0034] If the register transfer level code of the component-driven task is faulty;

[0035] Then obtain the tool information called, the steps to generate register transfer level code, and the error information fed back by the simulation test;

[0036] The tool information called, the steps for generating register-transfer level code, and the error information from the simulation test are respectively input into at least two large language models to determine the steps in generating the register-transfer level code that contain errors.

[0037] The steps containing errors are iteratively optimized to ensure that the register transfer level code is correct.

[0038] In one possible implementation, the step of inputting the invoked tool information, the step of generating register-transfer-level code, and the error information from simulation testing into at least two large language models to determine if there is an error in the step of generating the register-transfer-level code includes:

[0039] The tool information invoked, the steps for generating register-transfer level code, and the error information from the simulation test are respectively input into at least two large language models to obtain scores from at least two large language models for the steps of generating the register-transfer level code;

[0040] The steps for generating the register-transfer-level code are scored by the at least two large language models, and a weighted sum is taken to determine the step with the highest score among the steps for generating the register-transfer-level code.

[0041] The step with the highest score is considered the step in generating the register transfer level code that contains an error.

[0042] In one possible implementation, the method further includes:

[0043] If the number of iterations exceeds a preset threshold, and the register transfer level code is faulty, then the optimization stops and the iteration process is output; the iteration process includes the faulty step, the adjustment content, and the verification feedback result.

[0044] In one possible implementation, tool information, iteration processes, and issues where the number of errors exceeds an error threshold, along with their corresponding feedback results, are stored in the form of metadata.

[0045] Secondly, embodiments of this application provide a hardware design apparatus, including:

[0046] The acquisition module is used to acquire the design task and design specifications; the design specifications include descriptions of the design specifications, functions and implementation logic of the design task.

[0047] The generation module is used to determine that the design task is a text-driven task if the proportion of the description information of graphical hardware with specific spatial or temporal semantics in the design specification does not exceed a preset proportion threshold, and to generate register transfer level code based on the text-driven task and the corresponding design specification through a large language model.

[0048] Otherwise, the design task is determined to be a component-driven task. Based on the component-driven task and the corresponding design specifications, the tool is invoked through the large language model; and register transfer level code is generated based on the tool; the tool includes a retrieval-enhanced knowledge base, rule-based scripts, and electronic design automation simulation verification tools.

[0049] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0050] The memory stores computer-executed instructions;

[0051] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0052] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0053] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0054] The hardware design method and apparatus provided in this application obtain a design task and a design specification. The design specification includes descriptions of the design specifications, functions, and implementation logic of the design task. If the proportion of descriptions of graphical hardware with specific spatial or temporal semantics in the design specification does not exceed a preset threshold, the design task is determined to be a text-driven task. Based on the text-driven task and the corresponding design specification, register transfer level (RTL) code is generated using a large language model. Otherwise, the design task is determined to be a component-driven task. Based on the component-driven task and the corresponding design specification, a tool is invoked using a large language model, and RTL code is generated using the tool. The tool includes a retrieval-enhanced knowledge base, rule-based scripts, and electronic design automation simulation verification tools. The solution in this application first determines whether the current design task is a text-driven or component-driven task by the proportion of descriptions of graphical hardware with specific spatial or temporal semantics in the design specification. If it is a text-driven task, RTL code is directly generated using a large language model based on the specific text-driven task and the corresponding design specification. For component-driven tasks, the large language model is used to call auxiliary tools to help the large language model parse the graphical hardware description with specific spatial or temporal semantics; with the help of the tools, RTL code is generated, thereby improving the accuracy of hardware design. Attached Figure Description

[0055] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0056] Figure 1 An exemplary flowchart of a hardware design method is shown. Figure 1 ;

[0057] Figure 2 An exemplary flowchart of a hardware design method is shown. Figure 2 ;

[0058] Figure 3 A schematic diagram of the hardware design framework for example;

[0059] Figure 4 A diagram illustrating the percentage of test cases successfully resolved using different debugging methods across 340 scenarios;

[0060] Figure 5 A diagram illustrating the cumulative resolution rate of different debugging methods over ten runs, serving as an example.

[0061] Figure 6 An exemplary schematic diagram of a hardware design device is shown;

[0062] Figure 7 An exemplary schematic diagram of an electronic device is shown.

[0063] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and textual descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

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

[0065] The following is an explanation of the terms used in this application:

[0066] Large Language Model (LLM): A deep learning model trained on massive amounts of data that can understand and generate natural language content.

[0067] Register-Transfer Level (RTL): An abstract description level for synchronous digital circuits, used to express data transfer and logical operations between registers.

[0068] Electronic Design Automation (EDA): A software tool system used to assist in the design, verification, and implementation of integrated circuits.

[0069] State-of-the-Art (SoTA): refers to the best-performing and most advanced technology or method in a particular research or application field.

[0070] Model Context Protocol (MCP): A standardized protocol for exchanging contextual information between tools and models to support a more stable inference process.

[0071] Retrieval-Augmented Generation / Repository (RAG): A method or system that improves the accuracy of generated content by retrieving external knowledge sources and combining them with model reasoning.

[0072] Finite State Machine (FSM): A mathematical model that uses states, inputs, and transition functions to describe the behavior of a system and is used to represent control flow.

[0073] Karnaugh Map (K-map): A graphical method for simplifying Boolean algebra, which helps generate more concise logical expressions.

[0074] In modern chip development, hardware design automation is a core element in ensuring design efficiency and quality. Designers must complete the transformation from natural language requirements to synthesizable hardware logic through processes such as register-transfer-level (RTL) code generation, functional verification, and debugging optimization. However, hardware design tasks heavily rely on complex technical components (such as Karnaugh maps, finite state machine (FSM) diagrams, and timing waveforms). These components embody the dynamic timing relationships and spatial logic structures of hardware behavior, which are difficult to fully express through plain text descriptions. For example, when designing synchronous adders, memory interfaces, or protocol controllers, designers need to combine logical expressions, state transition diagrams, timing constraints, and other components to ensure that the code meets functional specifications and performance indicators. Currently, designers face two major challenges: First, while automation tools based on large language models (LLMs) can quickly generate text-driven designs, their understanding of specific hardware components is limited, easily leading to design intent deviations or functional errors. Second, while traditional tool-based methods (such as templated scripts and EDA tools) possess stability, they struggle to adapt to diverse design needs and have poor scalability. This contradiction leads to frequent manual intervention in the design process, which seriously affects the accuracy of RTL code generation for hardware designs.

[0075] The hardware design method and apparatus provided in this application aim to solve the aforementioned technical problems of the prior art. The hardware design method and apparatus provided in this application acquire a design task and a design specification; the design specification includes descriptive information about the design specifications, functions, and implementation logic of the design task; if the proportion of descriptive information about graphical hardware with specific spatial or temporal semantics in the design specification does not exceed a preset threshold, the design task is determined to be a text-driven task. Based on the text-driven task and the corresponding design specification, register-transfer level code is generated through a large language model; otherwise, the design task is determined to be a component-driven task. Based on the component-driven task and the corresponding design specification, a tool is invoked through a large language model; and register-transfer level code is generated based on the tool; the tool includes a retrieval-enhanced knowledge base, rule-based scripts, and electronic design automation simulation verification tools. The solution of this application first determines whether the current design task is a text-driven task or a component-driven task by the proportion of descriptive information about graphical hardware with specific spatial or temporal semantics in the design specification, based on the design task and design specification. For text-driven tasks, the large language model directly generates RTL code based on the specific text-driven task and corresponding design specifications. For component-driven tasks, the large language model is used in conjunction with auxiliary tools to assist in parsing the graphical hardware description with specific spatial or temporal semantics; with the assistance of these tools, RTL code is generated, thus improving the accuracy of hardware design.

[0076] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0077] Example 1

[0078] Figure 1 An exemplary flowchart of a hardware design method is shown. Figure 1 ;like Figure 1 As shown, the method includes:

[0079] Step 101: Obtain the design task and design specifications; the design specifications include descriptions of the design task's design specifications, functions, and implementation logic.

[0080] In this embodiment, the design task may include a generation task and a debugging task. The generation task primarily refers to the task of generating RTL code according to the design requirements. When it is a generation task, the user needs to provide a design specification describing the expected behavior of the design, including design specifications, functional descriptions, and implementation logic. The debugging task primarily refers to the task of debugging the generated RTL code if it has defects. When it is a debugging task, the user needs to provide the defective RTL code, the relevant verification components required to trigger the defects (such as a test platform or a gold reference model), and a complete design specification.

[0081] Step 102: If the proportion of description information of graphical hardware with specific spatial or temporal semantics in the design specification does not exceed a preset proportion threshold, the design task is determined to be a text-driven task. Based on the text-driven task and the corresponding design specification, register transfer level code is generated through a large language model. Otherwise, the design task is determined to be a component-driven task. Based on the component-driven task and the corresponding design specification, a tool is invoked through a large language model. Register transfer level code is generated based on the tool. The tool includes a retrieval-enhanced knowledge base, rule-based scripts, and electronic design automation simulation verification tools.

[0082] In this embodiment, based on current research and practical experience, hardware design and software development are fundamentally different. In the field of software development, Large Language Models (LLMs) have demonstrated outstanding capabilities in code generation, debugging, and verification tasks. However, hardware design is not a purely text-driven process. Although Register Transfer Level (RTL) code can express the structural and behavioral intent of a design, the successful implementation of hardware design and verification highly depends on hardware-specific components (design components) such as K-maps, FSM diagrams, waveform trajectories, timing diagrams, and schematic layouts. These components carry essential dynamic and spatial relationship information about hardware behavior, but are difficult for LLMs to process effectively. Compared to text data, LLMs have a significantly weaker ability to understand these components, and the proportion of hardware-specific components in current LLM training datasets is also severely insufficient. The direct problem resulting from this is that when LLMs are directly applied to hardware design tasks, misunderstandings of design intent often occur, and reasoning capabilities are limited when dealing with core issues such as time-dependent behavior, concurrent logic, and state transitions, ultimately making it difficult for overall performance to meet practical requirements.

[0083] To address this issue, LLM can be used to automatically extract hardware-specific components such as K-maps, FSM diagrams, and waveform trajectories from the task description. A proportion-based heuristic method is then employed to calculate the percentage of these hardware-specific components within the overall task content. Finally, a classification decision is made based on a comparison of this percentage with a threshold. If the percentage exceeds the threshold, the task is classified as component-driven; otherwise, it is classified as text-driven. This classification mechanism can operate automatically and supports adjusting the threshold to adapt to the needs of different design scenarios.

[0084] For text-driven tasks, a rapid thought process can be enabled. LLM generates results directly through step-by-step reasoning, i.e., RTL code, without requiring external tools. Optionally, Figure 2 An exemplary flowchart of a hardware design method is shown. Figure 2 ;like Figure 2 As shown, based on the text-driven task and corresponding design specifications, register-transfer level code is generated using a large language model, including:

[0085] Step 201: Using a large language model, decompose the text-driven task to obtain a list of design requirements for the text-driven task.

[0086] For example, the design requirements list breaks down the task of describing natural language using a large language model into multiple structured requirements. Text-driven tasks are hardware design tasks where the design intent is clearly expressed primarily through text, such as the design of basic logic gate circuits, and the development of arithmetic operation modules like adders and subtractors. The core requirements and implementation logic of these tasks can be fully described in text, without relying on complex hardware-specific components for explanation. A rapid thinking process is adopted to fully leverage the inherent advantages of LLM in text semantic understanding and code logic generation.

[0087] LLM utilizes the vast amounts of text patterns, programming language syntax rules, and hardware design-related code structure knowledge accumulated during training. Combined with the functional requirements in the task description, such as "design an 8-bit synchronous adder that supports carry output," it directly generates RTL code that conforms to the correct syntax. The entire process is completed solely through LLM's autonomous inference capabilities, without requiring any external tools.

[0088] Step 202: Based on the design requirements list, construct the logical framework; the logical framework is used to define the components of the hardware design corresponding to the text-driven task, the functions of the components, and the connection relationships between the components.

[0089] In this embodiment, a logical framework is constructed based on the requirement list obtained from the aforementioned task decomposition. The logical framework, after the large language model has been trained with massive amounts of training data, comprises the hardware design modules corresponding to the text-driven tasks generated from the requirement list, outlining the functions of each module and their interconnections. For example, for the task "Design an 8-bit synchronous adder supporting carry output," the logical framework may include: modules such as an input register module, an 8-bit adder core, and an output register module. The interconnections between these modules can be divided into three levels; the first level is input synchronization and capture. External, unstable input signals are directly connected to the input of the input register module; the system clock and reset signal are also connected to this module; at each rising edge of the clock, the input register module captures and latches these external input values; upon reset, its internal registers are cleared; the output from this module is a synchronized and stored stable value. The second stage is the core computation. Stable operands output from the input register module are directly and in parallel sent to the corresponding input ports of the 8-bit adder core. The adder core is a pure combinational logic circuit, internally composed of logic gates (such as AND gates, OR gates, and XOR gates), without a clock or registers. When the input signal arrives, after a fixed logic gate delay, the adder core will produce the result at its output port: an 8-bit combinational logic sum and a combinational logic carry output. The third stage is output synchronization and latching. The instantaneous combinational result generated by the adder core is directly and in parallel sent to the data input of the output register module. The same system clock and reset signal are also connected to this module. On the next rising edge of the clock (or when the reset is valid), the output register module will capture and latch these combinational results. The output from this module is the final stable output signal, strictly synchronized with the clock, which will be provided to external users of the circuit.

[0090] Step 203: Generate register transfer level code based on the logical framework.

[0091] In this embodiment, the large language model directly generates register-transfer level code through the constructed logical framework.

[0092] In this embodiment, by breaking down the requirements step by step, constructing a logical framework, and converting the reasoning path into RTL code, the accuracy and efficiency of generating RTL code are improved.

[0093] For component-driven tasks, a slow-thinking process can be initiated. For component-driven tasks, additional analysis and reasoning are required for components that LLMs are not adept at. Therefore, large language models need to utilize tools for further analysis.

[0094] Optionally, based on the component-driven task and corresponding design specifications, tools can be invoked through a large language model, including:

[0095] According to the design specifications, the component-driven task is broken down into multiple sub-tasks using a large language model.

[0096] In this embodiment, some complex tasks in hardware design require the processing of hardware-specific components such as K-maps, FSM diagrams, and waveform trajectories. The dynamic timing relationships and spatial logic structures carried by these components are difficult to parse using plain text, and directly relying on LLM reasoning can easily lead to misunderstandings or functional errors. For these hardware-specific component-driven tasks, LLM is no longer just a generation tool, but plays the role of an intelligent agent with decision-making capabilities: first, the complex design task is broken down into multiple logically related sub-tasks, and then the appropriate tool is dynamically selected according to the needs of each sub-task, ensuring that each step of the processing conforms to the hardware design specifications.

[0097] Based on the functional requirements of each subtask, the corresponding tools for each subtask are invoked through the large language model.

[0098] In hardware design automation scenarios, stability and domain adaptability are core elements determining the practical value of a framework. Stability ensures the repeatability of the design process and the reliability of results, while domain adaptability requires the framework to fit the professional needs of hardware design and handle diverse design tasks and technical specifications. To simultaneously meet these two requirements, a tool integration system centered on a Model Context Protocol (MCP) server was constructed. The MCP server structurally integrates various professional tools and resources with deterministic outputs, providing standardized API access interfaces for all tools and enabling dynamic tool invocation, cross-type collaboration, and functional expansion based on the real-time needs of different design tasks. This design avoids the invocation chaos caused by decentralized tool management and lays the foundation for flexible resource allocation in subsequent tasks. The integrated toolset specifically includes four types of tools, each playing a differentiated and crucial role in the hardware design process:

[0099] Retrieval Enhanced Knowledge Base (RAG): Contains fully validated hardware designs, providing design knowledge, reusable RTL modules, and diverse code patterns, supporting retrieval-based reasoning and context enhancement.

[0100] EDA tools: Integrates tools such as Verilator, Icarus Verilog, and Yosys for compiling, simulating, and formally verifying RTL designs, ensuring the correctness of code syntax and the effectiveness of functionality.

[0101] Rule-based scripts: automate deterministic subtasks (such as extracting logical expressions from K-maps), avoiding the unreliability of LLMs in such tasks.

[0102] LLM executors: include general-purpose LLMs and hardware-specific fine-tuned LLMs, supporting adaptive inference for general-purpose and hardware-domain-specific subtasks.

[0103] The MCP server acts as a central controller, responsible for the registration, retrieval, and management of tools, maintaining metadata such as tool functions, parameters, and resource usage, supporting the parallel and conflict-free execution of heterogeneous components, and enabling on-demand invocation of tools without manual intervention.

[0104] In this embodiment, the component-driven task is divided into subtasks based on the large language model, and each subtask has corresponding functional requirements. The functional requirements of the subtasks may require external knowledge support or professional computing capabilities (such as lack of design experience for a certain type of hardware module or the need for formal verification of RTL code). For example, the functional requirements of a subtask may include retrieving the RTL code corresponding to the current subtask in the RAG database; when the RTL code already found in the RAG database matches the functional requirements of the subtask, the testing and verification tool can be directly called to verify the RTL code; when the RTL code already found in the RAG database does not match the functional requirements of the subtask, the RTL code is modified accordingly, and the testing and verification tool is called to verify the modified RTL code; or a pattern script can be used to extract the logical expression task of the determined graphical hardware from the subtask; or the large language model tool can be called to generate the corresponding RTL code based on the task description of the current subtask.

[0105] Based on the tools available in the aforementioned tool library and the functional requirements of each subtask, further calls are made to the tools corresponding to each subtask.

[0106] Optionally, based on the functional requirements of each subtask, the corresponding tools for each subtask can be invoked through the large language model, including:

[0107] Retrieve tool information for each tool in the tool library; tool information includes tool function, parameter requirements, and output format.

[0108] Based on the functional requirements and tool information of each subtask, tools that match the functional requirements of each subtask are determined through a large language model.

[0109] The tool corresponding to each subtask is invoked through the model context protocol server.

[0110] In this embodiment, the large language model first determines the tool information matching the aforementioned sub-functions based on the tool information of each tool in the tool library. The large language model then calls the tool matching the sub-task through the MCP server. For example, when a sub-task requires external knowledge support or specialized computing capabilities (such as lack of design experience for a certain type of hardware module or the need for formal verification of RTL code), it can dynamically call the appropriate tool from the toolset managed by the MCP server. The tool selection process is not random, but rather determined by the LLM agent based on two aspects: first, the contextual reasoning requirements of the current sub-task (e.g., "need to generate DDR3 interface timing verification code," in which case tools related to the storage protocol are prioritized); and second, the tool metadata recorded in the metadata (including tool functions, parameter requirements, applicable scenarios, etc.), ensuring that the selected tool can accurately solve the current problem. The tools corresponding to the sub-task can include two types of operations:

[0111] External Knowledge Acquisition (RAG Invocation): If the selected tool is the Retrieval Enhanced Knowledge Base (RAG), then the professional knowledge and reference resources required for hardware design are acquired through this tool. The specific process is as follows: First, the LLM agent generates an accurate query term q based on the inference context of the current subtask. For example, for the subtask of "designing an SPI protocol host module," the query term might be set to "SPI protocol host RTL implementation of synchronous clock data sampling mechanism"; then, the embedded model is used... (Example, the Qwen3-Embedding model can be used) Calculate the embedding vectors of the query term q and each document d in the RAG knowledge base respectively—the embedding model can transform text information into high-dimensional vectors, and semantically similar content will correspond to similar vectors; then, calculate the semantic similarity between q and d using the cosine similarity formula, "sim(q,d)=cos(E(q),E(d))", which measures the degree of semantic association by the cosine value of the angle between two vectors, and the closer the value is to 1, the higher the similarity; then, select the top k retrieval candidates with the highest semantic similarity from all documents (k can be selected according to needs, and this application embodiment does not impose restrictions, for example, k=5, which ensures knowledge coverage and avoids information redundancy); finally, the LLM agent does not directly reuse the retrieval results, but combines the specific intent of the current design task (such as the data transmission rate and clock frequency requirements of the SPI module) and functional relevance (such as whether it supports multi-slave communication), and selects the knowledge that best meets the needs from the 5 candidates (such as "Verilog SPI master supporting 100MHz clock"). Implement the code and integrate it into the reasoning context as a reference to help LLM generate outputs that conform to design specifications more accurately and avoid design deviations caused by insufficient knowledge.

[0112] External computation execution (EDA tool / script call): If the selected tool is an executable tool (such as an EDA tool or a rule-based script), the tool will complete the professional computation or automated processing tasks in the hardware design. In specific operation, the LLM agent will first refer to the function description recorded in the "Tool Information" module of the metadata to clarify the input parameters required by the tool (such as specifying the RTL file path and target process library when calling Yosys for synthesis), and then construct a structured call instruction that meets the requirements of the tool interface; then the instruction will be sent to the MCP server, and the server will schedule the tool to execute the corresponding computation (such as Verilator compiling and simulating RTL code, and rule-based scripts automatically extracting the simplest logical expression from K-map); after the tool is executed, it will return the results in a standardized format (such as simulation logs and logical expression text), and the LLM agent will integrate these results into the inference flow of the current subtask as the basis for the next step of processing (such as correcting the clock constraints of the RTL code based on the timing violation information in the simulation log).

[0113] Optionally, depending on the tool, hardware design code can be generated, including:

[0114] The tool executes its corresponding subtasks and generates execution results.

[0115] Based on the execution results, register transfer level code is generated using a large language model.

[0116] In this embodiment, the corresponding subtask is executed according to the invoked tool, and the execution result is obtained; then, RTL code is generated based on the execution result. For example, the large language model first divides the component-driven task into multiple subtasks. The large language model extracts one of the subtasks according to task priority. When the subtask is to retrieve the RAG database, if RTL code that meets the functional requirements of the subtask can be retrieved, the large language model can invoke a test simulation verification tool to optimize the retrieved RTL code, obtaining optimized RTL code. If the subtask is executable, the execution result is fed back to the large language model, which then executes the next subtask. For example, when the current subtask is a description of graphical hardware, a rule-based script needs to be invoked to convert it into a logical expression.

[0117] Once all subtasks have been completed, the RTL code corresponding to the component-driven task can be generated.

[0118] In one example, the large language model receives a natural language description of a high-level hardware design task. It first breaks this top-level "large task" down into a series of logically connected, finer-grained "subtasks." Each subtask is not necessarily pre-bound to a tool, but rather defines a goal and a requirement type. For the subtask to be processed, the large language model determines its requirement type and then dynamically calls the most suitable tool: Retrieval tasks: If the subtask is of a "retrieval / query" nature (e.g., "finding the standard code paradigm for asynchronous reset in Verilog"), the large model calls a knowledge retrieval tool. This tool retrieves relevant code snippets, protocol templates, or design rules from an internal knowledge base, design specification documents, or best practice manuals, and returns the results to the large model. Execution / generation tasks: If the subtask is of a "build / generate / transform" nature (e.g., "converting this state transition diagram into case statements" or "generating module declarations based on this interface description"), the large model calls a code generation tool. This tool might be a finely tuned professional code generation model that receives a context (design intent + retrieval results) prepared by a larger model and outputs corresponding code drafts or logical expressions. For verification and analysis tasks: if the subtask is of an "inspection / verification" nature (e.g., "checking for combinational logic loops in this code" or "verifying syntax correctness"), the larger model will invoke static analysis tools (such as lint tools, syntax checkers, and the basic rule set of formal verification tools). This tool analyzes existing code snippets and outputs issue reports, warnings, or pass signals. Each subtask doesn't necessarily correspond to a "unique" tool, but rather to a "tool type." The large language model acts as a "scheduler," dynamically selecting and invoking the most suitable tool from the available toolset based on the immediate needs of the current subtask. The large language model integrates the tool's execution results (retrieved knowledge, generated code snippets, verification reports) into the current design context. If the result is a retrieval result, the large model will understand and absorb this information to guide the next generation step. If the result is generated code, the large language model will temporarily store it as part of the "current work output."

[0119] If the feedback received is verification feedback (such as errors or warnings), the large language model will prioritize processing this feedback. The large language model may create new, urgent subtasks and re-invoke the corresponding tools (fixing tools, interpretation tools). This "generate -> verify -> feedback -> regenerate" cycle essentially continuously optimizes the inference path. The large language model's initial "plan" may not be optimal, but through the immediate feedback from the verification tools, it can correct its direction in real time, ensuring that each step's output gradually converges towards "synthesizable, syntax-free, and specification-compliant" RTL code. After successfully completing a subtask (i.e., obtaining "pass" verification feedback or no critical errors), the large language model will move on to the next planned subtask based on the latest, correct design state. The code starts from module declarations, gradually adding internal signals, combinational logic, and sequential logic, with each step potentially undergoing multiple "generate-verify" fine-tuning steps. When all planned functional subtasks are completed, the large language model will initiate a final, comprehensive verification subtask (potentially calling more complex simulation test generation or formal property checking tools for preliminary verification). Finally, all the verified and correct code snippets are combined in logical order into a complete RTL code.

[0120] For example, after generating RTL code in the aforementioned manner, electronic design automation (EDA) tools can be called to generate the circuit netlist for the hardware design. The obtained RTL code, through the use of EDA toolsets, undergoes subsequent transformations, optimization mappings, and other processes to generate the corresponding circuit netlist. This circuit netlist can then be used to implement the chip's hardware design in actual production.

[0121] In this embodiment, firstly, based on the design task and design specifications, the proportion of descriptive information about graphical hardware with specific spatial or temporal semantics in the design specifications is used to determine whether the current design task is a text-driven or component-driven task. If it is a text-driven task, RTL code is directly generated using a large language model based on the specific text-driven task and the corresponding design specifications. If it is a component-driven task, auxiliary tools are invoked using the large language model to assist in parsing the description of graphical hardware with specific spatial or temporal semantics; with the assistance of these tools, RTL code is generated, thus improving the accuracy of the hardware design.

[0122] Optionally, the method also includes:

[0123] The syntax and functionality of the register transfer level code are verified.

[0124] In this embodiment, regardless of whether it is a text-driven or component-driven task, an iterative verification and optimization phase is required after RTL code generation. Optionally, the syntax and functionality of the register-transfer level code are verified, including:

[0125] The register-transfer-level code is compiled, and the compiled register-transfer-level code is compared with the preset syntax rules. If the comparison is consistent, the register-transfer-level code is determined to be syntactically correct; otherwise, the register-transfer-level code is determined to be syntactically incorrect.

[0126] The simulation test verifies whether the function of the register-transfer-level code is consistent with the requirements of the design task; if it is consistent, the function of the register-transfer-level code is determined to be correct; otherwise, the function of the register-transfer-level code is determined to be incorrect.

[0127] If the syntax and functionality are both correct, then the register transfer level code is correct.

[0128] Otherwise, a register transfer level code error is determined.

[0129] For example, integrated EDA verification tools can be invoked to perform dual verification on the generated RTL code. On one hand, the code is checked for syntax errors, such as incomplete port declarations or misuse of keywords; on the other hand, simulation tests are used to verify whether the code's functionality matches the design intent. Figure 1 For example, the accuracy of the calculation results in the arithmetic module and the correctness of the input-output mapping of the logic gates are checked. If both checks are correct, the RTL code is considered correct; otherwise, the RTL code is considered incorrect.

[0130] In this embodiment, the correctness of the RTL code is ensured by performing inspection, further improving the reliability of the generated RTL code.

[0131] Optionally, the method also includes:

[0132] If the register-transfer level code for a text-driven task is faulty, the faulty step in generating the register-transfer level code is determined using a large language model based on the error information from the simulation test.

[0133] Iterative optimization is performed on steps with errors to ensure the register transfer level code is correct.

[0134] In this embodiment, when a verification error occurs in the RTL code of a text-driven task, the system will feed back the error information, including the location of the syntax error and details of the functional deviation, to the LLM. The LLM will then locate the root cause of the problem based on this feedback information and perform targeted iterative corrections to the code, forming an iterative cycle of "generation-verification-optimization".

[0135] In this embodiment, the accuracy and reliability of the generated RTL code are improved by iteratively optimizing the generated RTL code.

[0136] Optionally, the method also includes:

[0137] If the register transfer level code for a component-driven task is faulty.

[0138] This allows you to obtain information about the tools being called, the steps involved in generating register transfer level code, and error messages from simulation tests.

[0139] In this embodiment, when the verification step (such as syntax checking of RTL code and functional simulation verification) fails, three types of key information can be extracted completely: first, the task context (including original design requirements, current subtask objectives, etc.) to ensure that the analysis does not deviate from the core of the task; second, the sequence of inference steps in the execution history (such as the step record of "calling RAG to obtain SPI protocol knowledge → generating RTL code → calling EDA simulation") to clarify the complete processing path before the failure occurred; and third, the verification information in the tool's memory (such as the syntax error log output by the EDA tool and the timing violation details in the functional simulation) to provide data support for judging the cause of the failure.

[0140] Input the tool information, the steps for generating register-transfer level code, and the error information from simulation tests into at least two large language models to identify the steps in generating register-transfer level code that contain errors.

[0141] Based on the extracted information, the fault localization phase begins. Optionally, the tool information invoked, the steps for generating register-transfer-level code, and the error information from simulation tests are input into at least two large language models to identify the steps in generating register-transfer-level code that contain errors, including:

[0142] The tool information, the steps for generating register-transfer level code, and the error information from the simulation test are input into at least two large language models to obtain scores from at least two large language models for the steps of generating register-transfer level code.

[0143] The steps for generating register-transfer level code are scored by at least two large language models, and a weighted sum is taken to determine the step with the highest score among the steps for generating register-transfer level code.

[0144] The step with the highest score is considered the step with the error in generating register transfer level code.

[0145] In this embodiment, an LLM resource pool can be invoked to call at least two large language models of different types to independently evaluate each step in the inference step sequence. Each model assigns a "failure contribution probability score" to each step based on its own understanding of the hardware design logic; a higher score indicates a greater likelihood that the step will lead to verification failure. Subsequently, the scores given by all models are aggregated (using a weighted average to balance the judgment weights of different models), and finally, the step with the highest score is determined as the most likely erroneous step.

[0146] Iterative optimization is performed on steps with errors to ensure the register transfer level code is correct.

[0147] In this embodiment, once an error is identified, targeted optimization can be performed instead of recalculating the entire inference chain (to avoid resource waste and efficiency loss). Only the identified faulty step is adjusted. For example, if the fault source is "insufficient RAG knowledge retrieval," the query terms are re-optimized and RAG is called again to obtain more accurate references; if the fault source is "RTL code logic error," the LLM is guided to correct the code based on verification feedback, ensuring that optimization focuses on the core problem.

[0148] In this embodiment, when an error occurs in the RTL code corresponding to a component-driven task, at least two different large language models are invoked to analyze the erroneous steps in order to determine the steps where the error occurred, thereby further improving the accuracy of error localization.

[0149] Optionally, the method also includes:

[0150] If the number of iterations exceeds the preset threshold, a register transfer level code error occurs, and the optimization stops and the iteration process is output. The iteration process includes the error step, the adjustment content, and the verification feedback result.

[0151] In this embodiment, if the number of iterations does not reach a predefined threshold (for example, regardless of whether it's a text-driven or component-driven task, the number of iterations for optimizing the corresponding RTL code when an error occurs can be 5), then the optimized inference steps continue. If the problem is still not resolved after reaching the upper limit, optimization stops and the iteration process is output; the iteration process includes the erroneous step, the adjustment content, and the verification feedback result. For example, the erroneous step can be the process of the large language model performing inference for a text-driven task, including the process of breaking down task requirements, building a logical framework, and generating RTL code. Any of these processes may result in an erroneous step, such as unreasonable requirement breakdown or unreasonable logical framework construction. It can also be an unreasonable subtask division or unreasonable tool calling in the large language model for a component-driven task. That is, the erroneous step is an unreasonable step in the process of generating RTL code based on the design task, which leads to errors in the generated RTL code. The adjustment content refers to the content that is corrected specifically based on the erroneous step, such as adjusting which descriptions correspond to a requirement or which descriptions correspond to a subtask. The verification feedback results represent the correctness or error of the adjusted RTL code during multiple iterations of optimization. Furthermore, recurring error types and key optimization insights can be generated into a structured summary and fed back to the next round of inference. Specifically, when the number of iterations reaches a preset threshold, the task requirements are completely decomposed or reclassified to provide direction for subsequent processing and avoid repeating the same pitfalls.

[0152] In this embodiment, when optimizing the steps for RTL errors, if the problem persists even after exceeding a preset threshold number of iterations, the optimization is stopped, and the iteration process is output and stored, thereby improving the efficiency of RTL generation.

[0153] Optionally, the method also includes:

[0154] The tool information, iteration process, and issues where the number of errors exceeds the error threshold, along with the corresponding feedback results, are stored in the form of metadata.

[0155] In this embodiment, LLMs typically cannot maintain long-term task states, limiting their ability to correct earlier inference results. However, hardware design is a complex, multi-step process that requires ensuring continuity between steps. For example, a complete debugging process includes subtasks such as error analysis, fix generation, simulation verification, and code iteration optimization. Without persistent state, LLMs cannot utilize earlier inference results or feedback, potentially leading to repetitive work and error accumulation. Tool information, iteration processes, and issues with more than a certain number of errors, along with their corresponding feedback, can be stored as metadata. When it's necessary to correct the execution steps of the inference process, the stored metadata can be directly retrieved, and adjustments can be made based on the error steps corresponding to this execution history. For example, tool information describes the function, parameter requirements, and output format of each tool, ensuring reliable tool invocation and output parsing. Inference steps, decisions, and sub-process results, as well as log compiler information, simulation errors, and other details, can also be recorded for targeted optimization; and after a predefined number of rollbacks, recurring problems and feedback can be summarized to provide improvement guidance for subsequent iterations. Store all metadata to ensure efficient retrieval, parsing, and runtime updates, while maintaining the traceability of the reasoning process.

[0156] In one example Figure 3 A schematic diagram of the hardware design framework for example; such as Figure 3As shown, the user task is first taken as input; for example, the description of the user task can be: Implement a circuit whose function is… (user task description) Generate complete code for me; this task description can also include a K-map graph. After classifying the user task through a classification mechanism, it is determined whether the current user task is a text-driven task or a component-driven task. When it is a text-driven task, the fast thinking process is executed, and the large language model performs the inference (r) step to generate RTL code, and performs the verification (v) step (verify the syntax and function of the code). If successful (the syntax and function are both correct), the RTL code is output (e.g., the code of the top-level module ()... the code of the end module is private); if it fails, a new round of optimization is started. When the number of iterations exceeds the threshold and the RTL code still has problems, the corresponding iteration history is output (e.g., iteration 1: The user's task is <task>. I tried to use <tool> in <step>, but an <error> occurred. Iteration 2: ...). For component-driven tasks, a slow-thinking process is executed: the MCP server is invoked, available tools are identified and executed, and then code generation begins. This involves identifying available tools, testing one, executing it, generating RTL code, validating its syntax and functionality, and producing the final iteratively optimized RTL code. If functional or syntax errors occur, the dynamic programming module optimizes the execution steps, initiating a new round to update the erroneous steps until correct RTL code is output. If the rollback counter's recorded iteration count exceeds a threshold and the RTL code still has issues, the iteration history (the most likely steps output by a weighted summation vote from the large language model tool pool) is output, and the summary module is activated to summarize recurring problems (indicating the error types as follows). Figure 3 The system also includes a metadata management module, comprising a tool information module for storing tool information (e.g., description: a description of the tool's function; parameters: details of input parameters; return: details of output specifications). A memory unit stores execution history (all iteration information) and tool memory (details of tool interactions). The former records inference steps, decisions, and sub-process results; the latter records log compiler information, simulation errors, and other details for targeted optimization. Triggered after a predefined number of rollbacks, it summarizes recurring issues (common problems) and feedback (recommended solutions), providing improvement guidance for subsequent iterations.

[0157] Table 1 compares the pass rate of the intelligent architecture (SmartCraft) of this application with other models in RTL generation;

[0158]

[0159] As shown in Table 1, the solution based on this embodiment achieves an RTL code generation pass rate of 76.57%, which is 14.91% higher than the most advanced existing technology. It performs exceptionally well in component-driven tasks such as FSM, K-map, and waveform tracing. The debugging and repair rate reaches 87.79%, which is 11.79% higher than the most advanced existing technology. It maintains high accuracy in debugging test platform-type syntax errors, functional errors, and assertion-type errors. Specifically, the test platform-type syntax error repair rate reaches 90.04%, and the functional error repair rate reaches 86.42%.

[0160] Table 2 shows a performance comparison of each scheme on debugging tasks based on the test platform and assertion.

[0161]

[0162] As shown in Table 2, the debugging task speed was increased by an average of 23.44 times, significantly reducing the workload compared to manual engineers. Among them, the debugging speed of the test platform type of storage module was increased by 56.87 times.

[0163] Figure 4 This diagram illustrates the proportion of different debugging methods that successfully resolved test cases across 340 scenarios; for example... Figure 4 As shown, it balances adaptability and stability: it adapts to 163 different design tasks, covering various scenarios of text-driven and component-driven approaches, and successfully solved 93.5% of the cases in 340 test platform-type debugging cases, far exceeding traditional tool-type solutions (RTL-Repair 2.1%, Strider 8.5%) and current LLM frameworks;

[0164] Figure 5 This is a diagram illustrating the cumulative resolution rate of different debugging methods over ten runs; for example... Figure 5 The system exhibits excellent stability, with a performance change Δ of only 0.11 over ten rounds of repeated operation, which is far lower than GPT-4.1 (Δ=0.28) and UVLLM (Δ=0.32), meeting the consistency requirements of industrial scenarios.

[0165] The hardware design method provided in this application first determines whether the current design task is text-driven or component-driven based on the proportion of descriptive information about graphical hardware with specific spatial or temporal semantics in the design specifications, according to the design task and design specifications. If it is a text-driven task, RTL code is directly generated using a large language model based on the specific text-driven task and the corresponding design specifications. If it is a component-driven task, auxiliary tools are invoked using the large language model to assist in parsing the description of graphical hardware with specific spatial or temporal semantics; with the assistance of these tools, RTL code is generated, thus improving the accuracy of the generated RTL code.

[0166] Example 2

[0167] Figure 6 An exemplary schematic diagram of a hardware design device is shown; such as Figure 6 As shown, the device includes:

[0168] The acquisition module 21 is used to acquire the design task and design specifications; the design specifications include descriptions of the design specifications, functions and implementation logic of the design task.

[0169] The generation module 22 is used to determine that if the proportion of the description information of graphical hardware with specific spatial or temporal semantics in the design specification does not exceed a preset proportion threshold, the design task is determined to be a text-driven task. Based on the text-driven task and the corresponding design specification, register transfer level code is generated through a large language model. Otherwise, the design task is determined to be a component-driven task. Based on the component-driven task and the corresponding design specification, a tool is invoked through a large language model. Register transfer level code is generated based on the tool. The tool includes a retrieval-enhanced knowledge base, rule-based scripts, and electronic design automation simulation verification tools.

[0170] The hardware design apparatus provided in this embodiment can execute the hardware design method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0171] Example 3

[0172] Figure 7 An exemplary schematic diagram of an electronic device is shown. The device includes:

[0173] The device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can invoke logical instructions stored in the memory 292 to execute the methods described in the example above.

[0174] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0175] The memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, that is, it implements the methods in the above method examples.

[0176] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0177] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method in any of the embodiments.

[0178] This application also provides a computer program product, including a computer program that, when executed by a processor, is used to implement the method in any of the embodiments.

[0179] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

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

[0181] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0182] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0183] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0184] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0185] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0186] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0187] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A hardware design method, characterized in that, include: Obtain the design task and design specifications; The design specifications include descriptions of the design specifications, functions, and implementation logic of the design task. If the proportion of the description information of graphical hardware with specific spatial or temporal semantics in the design specification does not exceed a preset proportion threshold, the design task is determined to be a text-driven task. Based on the text-driven task and the corresponding design specification, register transfer level code is generated through a large language model. Otherwise, the design task is determined to be a component-driven task. Based on the component-driven task and the corresponding design specifications, the tool is invoked through the large language model; and register transfer level code is generated based on the tool; the tool includes a retrieval-enhanced knowledge base, rule-based scripts, and electronic design automation simulation verification tools.

2. The method according to claim 1, characterized in that, The step of generating register-transfer level code based on the text-driven task and corresponding design specifications, using a large language model, includes: Using the large language model, the text-driven task is decomposed to obtain a list of design requirements for the text-driven task. Based on the design requirements list, a logical framework is constructed; the logical framework is used to define the constituent modules of the hardware design corresponding to the text-driven task, the functions of the constituent modules, and the connection relationships between the constituent modules. Based on the aforementioned logical framework, the register transfer level code is generated.

3. The method according to claim 1, characterized in that, The step of invoking tools based on the component-driven task and corresponding design specifications, through the large language model, includes: According to the design specifications, the component-driven task is broken down into multiple sub-tasks using the large language model. Based on the functional requirements of each subtask, the corresponding tools for each subtask are invoked through the large language model.

4. The method according to claim 3, characterized in that, The step of calling the corresponding tools for each subtask based on its functional requirements through the large language model includes: Obtain tool information for each tool in the tool library; the tool information includes tool function, parameter requirements, and output format. Based on the functional requirements of each subtask and the tool information, the tool that matches the functional requirements of each subtask is determined through the large language model. The tool corresponding to each subtask is invoked through the model context protocol server.

5. The method according to claim 4, characterized in that, The step of generating register transfer level code according to the tool includes: The tool is used to execute the sub-tasks corresponding to the tool and generate execution results. Based on the execution result, the register transfer level code is generated using the large language model.

6. The method according to claim 1, characterized in that, The method further includes: The syntax and functionality of the register transfer level code are verified; If the syntax and functionality are both correct, then the register transfer level code is correct. Otherwise, the register transfer level code is determined to be faulty.

7. The method according to claim 6, characterized in that, The verification of the syntax and functionality of the register transfer level code includes: The register-transfer-level code is compiled, and the compiled register-transfer-level code is compared with preset syntax rules. If the comparison is consistent, the register-transfer-level code is determined to be syntactically correct; otherwise, the register-transfer-level code is determined to be syntactically incorrect. The simulation test verifies whether the function of the register transfer level code is consistent with the requirements of the design task; if it is consistent, the function of the register transfer level code is determined to be correct; otherwise, the function of the register transfer level code is determined to be incorrect.

8. The method according to claim 6, characterized in that, The method further includes: If the register-transfer level code of the text-driven task is faulty, then based on the error information from the simulation test, the faulty step in generating the register-transfer level code is determined by the large language model. The steps containing errors are iteratively optimized to ensure that the register transfer level code is correct.

9. The method according to claim 6, characterized in that, The method further includes: If the register transfer level code of the component-driven task is faulty; Then obtain the tool information called, the steps to generate register transfer level code, and the error information fed back by the simulation test; The tool information called, the steps for generating register-transfer level code, and the error information from the simulation test are respectively input into at least two large language models to determine the steps in generating the register-transfer level code that contain errors. The steps containing errors are iteratively optimized to ensure that the register transfer level code is correct.

10. The method according to claim 9, characterized in that, The step of inputting the invoked tool information, the step of generating register-transfer level code, and the error information from simulation testing into at least two large language models to determine if there is an error in the step of generating the register-transfer level code includes: The tool information invoked, the steps for generating register-transfer level code, and the error information from the simulation test are respectively input into at least two large language models to obtain scores from at least two large language models for the steps of generating the register-transfer level code; The steps for generating the register-transfer-level code are scored by the at least two large language models, and a weighted sum is taken to determine the step with the highest score among the steps for generating the register-transfer-level code. The step with the highest score is considered the step in generating the register transfer level code that contains an error.

11. The method according to any one of claims 8-10, characterized in that, The method further includes: If the number of iterations exceeds a preset threshold, and the register transfer level code is faulty, then the optimization stops and the iteration process is output; the iteration process includes the faulty step, the adjustment content, and the verification feedback result.

12. The method according to claim 1, characterized in that, The method further includes: The tool information, iteration process, and issues where the number of errors exceeds the error threshold, along with the corresponding feedback results, are stored in the form of metadata.

13. A hardware design device, characterized in that, include: The acquisition module is used to acquire design tasks and design specifications. The design specifications include descriptions of the design specifications, functions, and implementation logic of the design task. The generation module is used to determine that the design task is a text-driven task if the proportion of the description information of graphical hardware with specific spatial or temporal semantics in the design specification does not exceed a preset proportion threshold, and to generate register transfer level code based on the text-driven task and the corresponding design specification through a large language model. Otherwise, the design task is determined to be a component-driven task. Based on the component-driven task and the corresponding design specifications, the tool is invoked through the large language model; and register transfer level code is generated based on the tool; the tool includes a retrieval-enhanced knowledge base, rule-based scripts, and electronic design automation simulation verification tools.

Images