Method, device and storage medium for generating hardware description language code

Abstract

The application provides a generation method and device of hardware description language code for FPGA development and a storage medium. The generation method of hardware description language code for FPGA development comprises the following steps: in a requirement extraction stage, obtaining a task requirement of a user for the hardware description language code to extract a hardware constraint set for FPGA development; in an architecture design stage, generating a structured development brief meeting a structured delivery contract according to the hardware constraint set; in an RTL implementation stage, generating a workpiece set according to the structured development brief; and in a verification stage, verifying whether the workpiece set and the hardware constraint set match successfully, and generating the hardware description language code for the RTL workpiece in response to a successful verification result. The application can be used to improve the reproducibility, controllability and traceability of the RTL automatic generation process, and support the automatic engineering landing of the whole hardware development process.

Description

Technical Field

[0001] This invention relates to the field of information processing technology, and in particular to a method for generating hardware description language code for FPGA development, an apparatus for generating hardware description language code for FPGA development, and a computer-readable storage medium. Background Technology

[0002] With the continuous increase in the scale and complexity of FPGA (Field Programmable Gate Array) and digital integrated circuit designs, generative AI-assisted Register Transfer Level (RTL) hardware description development and verification technology has become an important technical direction for improving hardware R&D efficiency and lowering design thresholds. Existing technologies around RTL have formed various technical solutions, including prompt-driven generation, domain-specific model fine-tuning, retrieval-enhanced generation, multi-agent role collaboration, tool-enhanced verification closed loop, and formal property constraint assistance. However, these existing technical solutions generally focus on optimizing the quality of code text generation, without establishing a process control mechanism for the entire hardware engineering process. They still commonly suffer from problems such as unstable output parsing and disk write-downs, lack of verifiable structured constraints in cross-stage handovers, and lack of controllable rollback and repair paths with evidence after verification failures.

[0003] In order to overcome the above-mentioned defects in the existing technology, there is an urgent need in this field for a method to generate hardware description language code for FPGA development, so as to improve the reproducibility, controllability and traceability of the automatic RTL generation process and support the automated engineering implementation of the entire hardware development process. Summary of the Invention

[0004] The following provides a brief overview of one or more aspects to offer a basic understanding of them. This overview is not an exhaustive summary of all conceived aspects, nor is it intended to identify key or decisive elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed descriptions that follow.

[0005] To overcome the aforementioned deficiencies in the existing technology, this invention provides a method for generating hardware description language (RTL) code for FPGA development, a device for generating RTL code for FPGA development, and a computer-readable storage medium. By combining a structured delivery contract, a structured handover data model, and a verification closed-loop rollback and retry strategy, this invention can improve the reproducibility, controllability, and traceability of the automatic RTL generation process, supporting the automated engineering implementation of the entire hardware development process.

[0006] Specifically, the method for generating hardware description language (HMR) code for FPGA development provided by the first aspect of the present invention includes the following steps: In the requirements extraction phase, user task requirements for the HMR code are obtained to extract a set of hardware constraints for FPGA development. The set of hardware constraints includes at least interface constraints, reset constraints, and timing constraints; in the architecture design phase, a structured development briefing satisfying a structured delivery contract is generated based on the set of hardware constraints; in the RTL implementation phase, an artifact set is generated based on the structured development briefing. The artifact set includes requirement artifacts, architecture artifacts, and RTL artifacts; and in the verification phase, the matching between the artifact set and the set of hardware constraints is verified, and in response to the successful verification result, HMR code for the RTL artifacts is generated.

[0007] Furthermore, in some embodiments of the present invention, the generation method further includes the following steps: in response to a verification result of unsuccessful matching, generating rollback handover data. The rollback handover data includes a failure summary, evidence citations, a rollback target stage, allowed modification scope, and retry budget; and returning to the rollback target stage in the rollback handover data, and regenerating the artifact set under constrained policy constraints. The constrained policy constraints include at least one of a maximum number of retries, a maximum number of rollbacks, and a maximum total number of steps.

[0008] Furthermore, in some embodiments of the present invention, the step of generating rollback handover data in response to a verification result of unsuccessful matching includes: performing structured parsing on the verification result to determine error information between the set of artifacts and the set of hardware constraints; and determining the rollback target stage and its allowed modification range based on the error information. The rollback target stage is one of the requirement extraction stage, the architecture design stage, the RTL implementation stage, and the verification stage. The allowed modification range is used to indicate the module identifiers, interface lists, and code regions that are allowed to be modified.

[0009] Furthermore, in some embodiments of the present invention, the step of determining the rollback target stage and its allowed modification range based on the error information includes: determining the rollback target stage as the RTL implementation stage when the error category in the error information is a compiler syntax error or an unrecognized identifier; determining the rollback target stage as the architecture design stage or the RTL implementation stage based on the impact range when the error category in the error information is a port name mismatch or a bit width mismatch; determining the rollback target stage as the architecture design stage when the error category in the error information is a timing constraint or a design constraint not met; and determining the rollback target stage as the architecture design stage or the requirements extraction stage when the error category in the error information is a test case function failure.

[0010] Furthermore, in some embodiments of the present invention, the step of returning to the rollback target stage in the rollback handover data and regenerating the workpiece set under the constraints of the restricted policy includes: driving the workflow state machine to roll back to the rollback target stage based on the rollback handover data, and initializing the retry counter and step counter in the restricted policy constraints; regenerating the workpiece set for correction within the allowed modification range, and monitoring the consumption of the retry counter and step counter; and terminating the regeneration process in response to reaching the threshold of the maximum number of retries, the maximum number of rollbacks, or the maximum total number of steps.

[0011] Furthermore, in some embodiments of the present invention, the step of generating an artifact set based on the structured development brief during the RTL implementation phase includes: generating the requirement artifact based on the structured development brief. The requirement artifact includes delivery metadata, confirmed facts, open questions, and requirement text; generating the architecture artifact based on the requirement artifact, wherein the architecture artifact includes module partitioning results, interface timing definitions, and architecture description; generating the RTL artifact based on the architecture artifact. The RTL artifact is subject to the separation of combinational logic and sequential logic, explicit bit-width declaration, non-blocking assignment, and avoidance of implicit latch constraints; and the requirement artifact, the architecture artifact, and the RTL artifact constitute the artifact set.

[0012] Furthermore, in some embodiments of the present invention, the step of verifying whether the set of artifacts and the set of hardware constraints match successfully during the verification phase includes: performing syntax and semantic checks on the RTL artifacts using a style parser to verify whether the RTL artifacts satisfy the interface constraints and generating compilation verification results; performing functional simulation on the RTL artifacts according to the test cases to verify whether the RTL artifacts satisfy the reset constraints and generating simulation verification results; performing logic synthesis and static timing analysis on the RTL artifacts using a fast synthesis tool to verify whether the RTL artifacts satisfy the timing constraints and generating synthesis verification results; and determining that the set of artifacts and the set of hardware constraints match successfully in response to the successful matching of the compilation verification results, the simulation verification results, and the synthesis verification results.

[0013] Furthermore, the hardware description language code generation apparatus for FPGA development provided according to the second aspect of the present invention includes a memory and a processor. The memory stores computer instructions. The processor is connected to the memory and configured to execute the computer instructions stored in the memory to implement the hardware description language code generation method for FPGA development as provided in the first aspect of the present invention.

[0014] Furthermore, in some embodiments of the present invention, the processor further includes a requirements extraction module, an architecture design module, an RTL implementation module, and a verification module. The requirements extraction module is used to obtain the user's task requirements for the hardware description language code during the requirements extraction phase, in order to extract a set of hardware constraints for the FPGA development. The architecture design module is used to generate a structured development brief that satisfies the structured delivery contract based on the set of hardware constraints during the architecture design phase. The RTL implementation module is used to generate a set of artifacts based on the structured development brief during the RTL implementation phase. The verification module is used to verify whether the set of artifacts matches the set of hardware constraints during the verification phase.

[0015] Furthermore, the computer-readable storage medium provided in the third aspect of the present invention stores computer instructions thereon. When the computer instructions are executed by a processor, they implement the method for generating hardware description language code for FPGA development as provided in the first aspect of the present invention. Attached Figure Description

[0016] The above-described features and advantages of the present invention will be better understood after reading the following detailed description of embodiments of the present disclosure in conjunction with the accompanying drawings. In the drawings, components are not necessarily drawn to scale, and components having similar related characteristics or features may have the same or similar reference numerals.

[0017] Figure 1 A hierarchical architecture diagram of a hardware description language code generation device for FPGA development is shown, according to some embodiments of the present invention.

[0018] Figure 2 A schematic diagram of a hardware description language code generation apparatus for FPGA development is shown, according to some embodiments of the present invention.

[0019] Figure 3 A flowchart illustrating a method for generating hardware description language code for FPGA development according to some embodiments of the present invention is shown. Detailed Implementation

[0020] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Although the description of the present invention is presented in conjunction with preferred embodiments, this does not mean that the features of the invention are limited to these embodiments. On the contrary, the purpose of describing the invention in conjunction with embodiments is to cover other options or modifications that may be derived based on the claims of the present invention. To provide a thorough understanding of the invention, many specific details will be included in the following description. The invention may also be implemented without using these details. Furthermore, to avoid confusion or obscuring the focus of the invention, some specific details will be omitted in the description.

[0021] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0022] Furthermore, the terms "upper," "lower," "left," "right," "top," "bottom," "horizontal," and "vertical" used in the following description should be understood as the orientations shown in the relevant paragraphs and accompanying drawings. These relative terms are for illustrative purposes only and do not imply that the described apparatus must be manufactured or operated in a specific orientation, and therefore should not be construed as limiting the invention.

[0023] It is understood that although terms such as "first," "second," and "third" may be used herein to describe various components, regions, layers, and / or parts, these components, regions, layers, and / or parts should not be limited by these terms, and these terms are only used to distinguish different components, regions, layers, and / or parts. Therefore, the first components, regions, layers, and / or parts discussed below may be referred to as second components, regions, layers, and / or parts without departing from some embodiments of the present invention.

[0024] Existing technologies surrounding RTL have developed various solutions, including prompt-driven generation, domain-specific model fine-tuning, retrieval-enhanced generation, multi-agent role collaboration, tool-enhanced verification loops, and formal property constraint assistance. However, these existing solutions generally focus on optimizing the quality of generated code text, lacking a process control mechanism for the entire hardware engineering workflow. They still commonly suffer from problems such as unstable output parsing and disk storage, a lack of verifiable structured constraints at cross-stage handovers, and a lack of controllable rollback and repair paths with evidence after verification failures.

[0025] Specifically, based on publicly available information and industry practices, existing technical solutions typically revolve around three types of questions: "how to generate RTL", "how to organize verification", and "how to repair after failure". These can be summarized into several technical routes, and most of them have insufficient reproducibility, controllability and traceability in terms of engineering automation implementation.

[0026] In prompt-based RTL generation schemes (using single-round or few-round prompts), these schemes typically drive the model to directly output Verilog / SystemVerilog code using prompt templates. A typical approach is as follows: after the user provides the problem statement or requirements, a fixed prompt template is used to constrain the output, such as limiting the top-level module name, port list, reset timing, prohibiting the output of explanatory text, or requiring only code blocks to be output. If the generation fails the first time, it is corrected by adding prompts or partially rewriting the code. To improve the hit rate, these schemes often introduce self-checking / self-evaluation prompts (e.g., requiring the model to list potential defects and check for undriven signals, bit width matching, timing-sensitive lists, etc.), or use multi-sample generation and voting / screening strategies to select candidate results. The main limitations of this approach are: the output format and boundaries are still prone to fluctuation (e.g., mixed explanatory text, unclear code block boundaries, inconsistent module names), making it difficult for the program to parse and write to disk stably; it lacks strong, executable constraints on engineering constraints such as filename strategy, extension range, synthesizable constraints, and dependent file organization, making it difficult to directly incorporate into automated pipelines; at the same time, the failure repair process often lacks structured evidence chain transmission, and the repair direction relies more on human prompts and experience, making it difficult to form a reproducible closed loop.

[0027] In domain-specific or fine-tuned model solutions (e.g., models trained for Verilog / HDL), these solutions typically fine-tune the model on HDL corpora, question bank samples, or synthetic / simulated data, employing instructional training or preference alignment to make the model more inclined to output synthesizable HDL code and improve pass rates on specific benchmarks. In engineering, this is often combined with question templates, port / module name constraints, and adaptation rules for dataset evaluation scripts to achieve more stable evaluation results. Its limitations are mainly: it still focuses on "generating code text," lacking a mechanism to directly constrain the output into parsable, disk-based, and traceable engineering deliverables (e.g., file-level artifacts with metadata); when validation fails, repairs usually involve regeneration or partial rewriting, lacking a controllable rollback and error correction path oriented towards requirements-architecture-implementation layers; furthermore, when training data coverage is insufficient or out of distribution, engineering-level defects such as omitted boundary conditions and temporal / reset semantic deviations are still prone to occur.

[0028] In Retrieval Enhancement and Example-Conditioned Generation (RAG) schemes, this type of scheme typically retrieves reference fragments (e.g., interface definitions, state machine templates, counter / pipeline templates, etc.) similar to the current task from historical projects, module libraries, interface specifications, or existing problem-solving examples. The retrieval results are then used as contextual examples to guide model generation or RTL rewriting. Its main limitations are: when the retrieved fragments are inconsistent with the current task in terms of interface, timing, or reset constraints, it is easy to introduce hidden errors that are not immediately noticeable (e.g., inconsistent bit width, clock domain, reset polarity, etc.); at the same time, if there is a lack of structured records and handover of the source of the referenced fragments, adaptation differences, and completion standards, it is often difficult to trace differences and risks in the downstream verification or integration stages; in addition, even if retrieval enhancement improves code quality, if the output structure and file-level delivery are still unstable, it will still affect automatic disk write-to-disk and batch execution.

[0029] In multi-agent natural language collaboration solutions, the requirements analysis, architecture design, implementation, and verification are typically broken down into multiple roles of intelligent agents, which collaborate in stages through dialogue. Some solutions also introduce reviewer / auditor roles to review and provide feedback on the implementation in order to reduce obvious errors. The main limitations are: the information exchange between roles is mostly free text, lacking a verifiable structured handover data model and mandatory field constraints, which can easily lead to information loss, ambiguity accumulation, or premise drift; at the same time, there is a lack of a protocol to unify and solidify the stage outputs into engineering artifacts that can be written to files and referenced, making it difficult to consume the results programmatically and integrate them into automated processes; when a role outputs non-compliant or missing key content, it often still relies on manual intervention or unstructured re-prompting, making it difficult to form a reproducible automatic repair mechanism.

[0030] In tool-enhanced verification closed-loop schemes (including compilation / simulation / static analysis), these schemes typically use simulators, compilers, or static analysis tools as external tools (e.g., compilation, simulation, lint, synthesis pre-checks, etc.), and use tool outputs (e.g., error messages, failure test case summaries, waveforms, or logs) as feedback-driven models for iterative repair. Their limitations are mainly: many schemes still rely on a "failure equals regeneration" loop, lacking structured failure attribution and rollback target selection mechanisms, making it difficult to determine whether to roll back to the requirements, architecture, or implementation phase for targeted repair; when tool outputs and repair suggestions lack a unified data structure, failure evidence (e.g., log fragments, commands, artifact paths, etc.) is easily lost or overwhelmed by noise during multiple rounds of interaction, reducing repair efficiency; furthermore, without constraints such as maximum retries, maximum rollbacks, and maximum total steps, invalid retries, divergent modifications, or context pollution can easily occur.

[0031] In property / assertion-aided solutions, assertions or property descriptions are typically generated for key modules (e.g., handshake protocol constraints, mutual exclusion / consistency constraints, finite state machine coverage, etc.), and formal checks or simulation assertion triggers are used to locate problems. Some solutions use property / constraint descriptions to help the model understand the protocol semantics more accurately. However, these solutions have limitations: the correctness and completeness of the properties or assertions themselves are difficult to guarantee, and if there is a lack of a unified handover and traceability mechanism with requirements / architecture, it is difficult to form a consistent interpretation. At the same time, the results of formalization or assertions usually need to be interpreted in conjunction with the engineering context. If there is a lack of a mechanism for the transmission and archiving of structured artifacts and failure evidence, it is difficult to achieve stable closed-loop operation in an automated pipeline.

[0032] In summary, while existing technologies have made improvements in terms of generation strategies, model capabilities, retrieval enhancement, role collaboration, and tool closure, they still generally suffer from problems such as unstable output parsing and disk storage, lack of verifiable structured constraints in cross-stage handover, and lack of controllable rollback and repair paths with evidence after verification failure. This invention addresses these pain points in engineering implementation through a combination of structured delivery contracts, structured handover data models, and verification closure rollback and retry strategies.

[0033] In particular, compared to schemes that only partially regenerate the currently failed module, the rollback retry of this invention is based on a workflow state machine. It first determines the target stage for rollback based on the failure summary and evidence references, then restores the workpiece boundaries and allowed modification range corresponding to that stage, and then regenerates the subsequent workpiece set. Therefore, its repair target is a "staged workpiece chain" rather than a single text fragment, which is more suitable for the requirement-architecture-implementation-verification closed loop in FPGA / RTL development.

[0034] To overcome the aforementioned deficiencies in the existing technology, this invention provides a method for generating hardware description language (RTL) code for FPGA development, a device for generating RTL code for FPGA development, and a computer-readable storage medium. By combining a structured delivery contract, a structured handover data model, and a verification closed-loop rollback and retry strategy, this invention can improve the reproducibility, controllability, and traceability of the automatic RTL generation process, supporting the automated engineering implementation of the entire hardware development process.

[0035] In some non-limiting embodiments, the above-described hardware description language code generation apparatus for FPGA development provided in the second aspect of the present invention can be implemented based on the hardware description language code generation method for FPGA development provided in the first aspect of the present invention.

[0036] In some non-limiting embodiments, the hardware description language code generation apparatus for FPGA development provided in the second aspect of the present invention includes a memory and a controller. Here, the memory includes, but is not limited to, the computer-readable storage medium provided in the third aspect above, on which computer instructions are stored. The controller is connected to the memory and configured to execute the computer instructions stored in the memory to implement the hardware description language code generation method for FPGA development as provided in the first aspect of the present invention.

[0037] Please refer to Figure 1 . Figure 1 A hierarchical architecture diagram of a hardware description language code generation device for FPGA development is shown, according to some embodiments of the present invention.

[0038] exist Figure 1In the illustrated embodiment, the application access layer B101 is used to receive user tasks, VerilogEval V2 benchmark problems, enterprise RTL requirements, and Alveo V80 experiment configurations. This layer can be implemented as a command-line entry point, web service, IDE plugin, CI pipeline, or enterprise R&D platform interface, and is responsible for passing natural language descriptions, existing code, constraint files, test files, and target platform parameters to the lower orchestration control layer.

[0039] In addition, Figure 1 In the illustrated embodiment, the core components of the orchestration control layer B102 include a Lead Agent, a task state machine, an access control module, a retry budget module, a rollback policy module, the `fpga_project_flow` skill, and the `team_handoff_protocol` skill. `fpga_project_flow` defines the main flow from requirement to delivery, iteration strategy, tool triggering conditions, and token resource management strategy. The `team_handoff_protocol` skill defines the communication format between teammates, including task summary, input artifacts, output artifacts, confirmed facts, assumptions, risks, open questions, evidence of failure, suggested next steps, and allowed modification scope. This layer is responsible for deciding when to invoke teammates, when to invoke tools, when to roll back, and when to terminate the task.

[0040] In addition, Figure 1 In the illustrated embodiment, the agent team layer B103 includes a requirements extraction module 11, an architecture design module 12, an RTL implementation module 13, a verification module 14, and several other agents. The requirements extraction module 11 is responsible for requirements clarification and constraint confirmation. The architecture design module 12 is responsible for module partitioning, interface definition, throughput analysis, and structural realizability. The RTL implementation module 13 is responsible for generating synthesizable RTL code. The verification module 14 is responsible for simulation, assertions, waveform generation, testbench creation, and verification coverage. Other agents are responsible for specific tasks, such as analyzing Vivado timing reports, summarizing long simulation logs, and reviewing whether a module violates coding standards. Teammates hand over artifacts through the orchestration control layer and are subject to role-based access restrictions. For example, the verification module 14 can modify the testbench but cannot modify the RTL without authorization, and the RTL implementation module 13 can modify the RTL but cannot change frozen interfaces beyond its authority.

[0041] In addition, Figure 1In the illustrated embodiment, skill layer B104 is the core of knowledge reuse in this invention. Specifically, the skills required for the requirements extraction phase include `refine_requirement_from_chat` and `gen_requirement_document`. The skills required for the architecture design phase include `roofline_model`, `module_list`, `arch_outline`, `define_interface`, `gen_arch_json`, and `gen_design`. The skills required for the RTL implementation phase include `hier_verilog_gen` and `design_specifications`. The skills required for the verification phase include `tb_scenarios_prompt`, `tb_rules_extract`, `iverilog_waveform_parser`, `mage_sim_judge_tb_fix`, `cocotb_support`, `timing_analysis`, `run_vivado_synthesis`, and `timing_opt`. The skills required for workflow control include `fpga_project_flow` and `team_handoff_protocol`. These skills can be invoked by corresponding roles as prompt contexts, output templates, inspection rules, tool invocation specifications, and failure handling strategies.

[0042] Here, `refine_requirement_from_chat` refers to the skill of confirming necessary development requirements through multiple rounds of dialogue, automatically refining ambiguous requirements, and asking for key information. `gen_requirement_document` refers to the skill of integrating the clarified requirements into a complete specification document.

[0043] `roofline_model` is a skill for analyzing bandwidth, calculating throughput, and design balance based on the Roofline model. `module_list` is a skill for decomposing complex designs into a list of submodules. `arch_outline` is a skill for generating a top-level architecture outline and illustrating module connections. `define_interface` is a skill for generating the interface signals, directions, bit widths, and timing relationships for each module. `gen_arch_json` is a skill for generating an architecture design JSON file for program parsing and validation. `gen_design` is a skill for generating architecture design documentation.

[0044] `hier_verilog_gen` is a skill that supports parsing complex hierarchical structures and generating hierarchical Verilog code. `design_specifications` is a skill used to generate Verilog code that conforms to functionally correct, synthesizable, timing-friendly, and PPA-compliant standards.

[0045] `tb_scenarios_prompt` is a skill for generating prompts for normal, boundary, and abnormal test scenarios. `tb_rules_extract` is a skill for extracting test rules and assertion conditions from specification documents. `iverilog_waveform_parser` is a skill for parsing Icarus Verilog simulation waveforms or logs and extracting signal behavior. `mage_sim_judge_tb_fix` is a skill for identifying simulation failures and automatically fixing the testbench. `cocotb_support` is a skill for generating and organizing test platforms based on cocotb. `timing_analysis` is a skill for automatically classifying circuit types such as combinational logic, sequential logic, pipelined logic, and high fan-out logic, and estimating timing risks. `run_vivado_synthesis` is a skill for calling fast synthesis tools and Vivado / Vitis for synthesis, implementation, and report parsing. `timing_opt` is a skill for optimizing RTL or architecture based on critical paths and timing reports.

[0046] `fpga_project_flow` is a skill that controls the workflow, iteration strategy, and token / resource management of the entire agent team. `team_handoff_protocol` is a skill that defines the communication format, artifact referencing, and failure evidence delivery method between agent teammates.

[0047] Those skilled in the art will understand that the embodiments configured with the above-described skills are merely some non-limiting implementations provided by the present invention, intended to clearly demonstrate the main concept of the present invention and provide some specific solutions that are easy for the public to implement, rather than intended to limit the scope of protection of the present invention.

[0048] Alternatively, in other embodiments, those skilled in the art may add skills such as CDC inspection, formal verification, resource estimation, AXI interface generation, HLS comparison, and power consumption estimation. Multiple small skills may be combined into a composite skill, or renamed according to enterprise specifications.

[0049] In addition, Figure 1In the illustrated embodiment, the tool execution layer B105 is used to translate agent decisions into real engineering actions. Simulation tools include Icarus Verilog, VVP, COCOTB, or alternative commercial / open-source simulators. A waveform parser reads waveform files such as VCD / FST and extracts specific signals, periods, state transitions, and assertion failure contexts. A fast synthesis tool submits RTL, constraint files, and platform parameters to the Vivado / Vitis Tcl Worker to perform synthesis, optimization, placement, physical optimization, and routing. A report parser converts tool outputs such as timing summaries, critical paths, high fan-out networks, resource utilization, and checkpoints into structured text or JSON that can be understood by the agent.

[0050] In addition, Figure 1 In the illustrated embodiment, the state and memory layer B106 is used to store workspace files, requirements documents, architecture documents, architecture JSON, RTL source code, testbench, simulation logs, waveform summaries, synthesis / timing reports, task records, teammate messages, long-term memory, and context-compressed summaries. This layer addresses the issues of excessively long contexts and lost evidence in long tasks. Large-volume tool outputs are not directly fed into the model context; instead, they are saved as files, retaining paths, summaries, and key fragments within the context. Reusable experiences are stored in long-term memory for inheritance in subsequent tasks.

[0051] In addition, Figure 1 In the illustrated embodiment, the EDA and hardware platform layer B107 represents the actual FPGA toolchain and target hardware. In an experimental embodiment of the invention, the target platform is a Xilinx Alveo V80 with a target frequency of 270MHz. The system evaluates the engineering feasibility of generating the RTL through XDC constraints, Vivado / Vitis projects, synthesis reports, placement and routing reports, and timing reports. This layer extends the invention from "simulation passed" to the engineering goal of "synthesizable, implementable, and timing-checkable on a real FPGA platform."

[0052] In addition, Figure 1In the illustrated embodiment, internal data pathways and closed-loop control flows are used to coordinate and control the internal input flow at each level, forming a closed-loop control flow. Specifically, the application access layer B101 provides task input to the orchestration control layer B102, which schedules the agent team layer B103. The agent team layer B103 calls the skill layer B104, which triggers the tool execution layer B105. The tool execution layer connects the EDA and hardware platform layer B107 and generates results. Simultaneously, the orchestration control layer B102, agent team layer B103, tool execution layer B105, and EDA and hardware platform layer B107 all write artifacts, logs, and reports to the state and memory layer B106. This inter-layer closed loop ensures that requirements, architecture, implementation, verification, synthesis, timing, and rollback information are traceable, reusable, and auditable within the system.

[0053] Please refer to further information. Figure 2 . Figure 2 A schematic diagram of a hardware description language code generation apparatus for FPGA development is shown, according to some embodiments of the present invention.

[0054] exist Figure 2 In the embodiment shown, the processor further includes a requirement extraction module 11, an architecture design module 12, an RTL implementation module 13, and a verification module 14.

[0055] Here, the requirement extraction module 11 is used to obtain the user's task requirements for hardware description language code during the requirement extraction stage, so as to extract the set of hardware constraints for FPGA development.

[0056] The architecture design module 12 is used to generate a structured development brief that satisfies the structured delivery contract based on the set of hardware constraints during the architecture design phase.

[0057] RTL Implementation Module 13 is used to generate a set of artifacts based on the structured development brief during the RTL implementation phase.

[0058] The verification module 14 is used to verify whether the workpiece set and the hardware constraint set are successfully matched during the verification phase.

[0059] In addition, Figure 1 In the embodiment shown, the processor may also optionally include a delivery module 15, which is used to encapsulate and deliver the generated workpiece set after the verification module verifies that the workpiece set and the hardware constraint set are successfully matched.

[0060] In addition, Figure 1In the illustrated embodiment, the processor may optionally include a rollback positioning module 16, used to generate rollback handover data after the verification module verifies that the matching between the workpiece set and the hardware constraint set is unsuccessful. Here, the rollback handover data includes a failure summary, evidence citations, rollback target stage, allowed modification range, and retry budget.

[0061] Furthermore, in some optional embodiments, the processor is also configured with a lead agent, serving as the unified scheduling and control core for the entire process. Specifically, the lead agent is used to create a dedicated workspace, register input workpieces, configure iteration budgets, and retrieve historical engineering specifications during the task initialization phase. It also schedules each functional module according to the development sequence as the process progresses, ensuring consistent information transmission across stages through standardized handover protocols, and guaranteeing that the overall process is controllable, efficient, and traceable.

[0062] Those skilled in the art will understand that the above-described embodiments of the requirement extraction module 11, architecture design module 12, RTL implementation module 13, and verification module 14 are merely some non-limiting implementations provided by the present invention, intended to clearly demonstrate the main concept of the present invention and provide some specific solutions that are easy for the public to implement, rather than being used to limit the scope of protection of the present invention.

[0063] Alternatively, in other embodiments, those skilled in the art can adjust the number of modules, for example, by merging the requirements extraction module 11 and the architecture design module 12, or by splitting the verification module 14 into a simulation verification agent, a timing analysis agent, and a board-level implementation agent; specialized modules such as code review, document generation, security checks, and IP integration can also be added.

[0064] The working principle of the above-mentioned hardware description language code generation device for FPGA development will be described below with reference to some embodiments of methods for generating hardware description language code for FPGA development. Those skilled in the art will understand that these embodiments of methods for generating hardware description language code for FPGA development are merely non-limiting implementations provided by this invention, intended to clearly demonstrate the main concepts of this invention and provide some specific solutions convenient for public implementation, rather than limiting all functions or all operating methods of the hardware description language code generation device for FPGA development. Similarly, the hardware description language code generation device for FPGA development is also only a non-limiting implementation provided by this invention, and does not limit the executing entity and execution order of each step in these methods for generating hardware description language code for FPGA development.

[0065] Please refer to Figure 3 . Figure 3A flowchart illustrating a method for generating hardware description language code for FPGA development according to some embodiments of the present invention is shown.

[0066] like Figure 3 As shown, the processor can first obtain the user's task requirements for the hardware description language code through the requirement extraction module 11 (Advisor) during the requirement extraction phase, so as to extract the hardware constraint set for FPGA development. Here, the hardware constraint set includes at least interface constraints, reset constraints, and timing constraints.

[0067] Here, the requirement extraction module 11 has the refine_requirement_from_chat and gen_requirement_document skills.

[0068] Specifically, in the requirements extraction phase, the requirements extraction module 11 first uses the `refine_requirement_from_chat` skill to identify incomplete or ambiguous content in the requirements, focusing on checking information such as port definitions, bit widths, clock domains, reset polarity, pipeline delays, ready / valid handshakes, boundary behaviors, abnormal inputs, throughput, area, frequency, and verification criteria. If key conditions are missing, the requirements extraction module 11 can trigger multiple rounds of clarification for the user. If the information is sufficient to proceed, the `gen_requirement_document` skill is invoked to generate a complete requirements specification document, clearly defining functional goals, design goals, interface constraints, clock and reset constraints, hardware constraints, and pass / fail criteria. The technical role of this step is to reduce implicit guessing about ports, resets, delays, constraints, and boundary conditions in the model during the RTL phase.

[0069] Furthermore, in some alternative embodiments, the processor can initialize the project via a master agent prior to the requirements extraction phase. The processor receives user-provided natural language requirements, interface descriptions, clock reset constraints, performance targets, existing RTL or test files, target FPGA platform, and toolchain configuration. The master agent invokes the `fpga_project_flow` and `team_handoff_protocol` skills to create a task workspace, register input artifacts, initialize retry budgets, rollback budgets, tool permissions, and context budgets, and retrieve coding standards, platform constraints, common errors, and historical optimization experiences relevant to the current project from long-term memory. The technical purpose of this step is to transform unstructured requirements into a task state that can be consumed by subsequent agents and the toolchain.

[0070] After that, as Figure 3As shown, during the architecture design phase, the processor can generate a structured development brief that satisfies the structured delivery contract based on the set of hardware constraints via the architecture design module 12 (Architect).

[0071] Here, the architecture design module 12 has the skills roofline_model, module_list, arch_outline, define_interface, gen_arch_json, and gen_design.

[0072] Specifically, the architecture design module 12 uses the `roofline_model` tool to analyze and calculate whether throughput, storage bandwidth, and interface bandwidth match, avoiding the generation of a structure that is functionally correct but performance-unachievable. Furthermore, the architecture design module 12 uses the `module_list` tool to break down complex designs into top-level modules, control modules, data path modules, cache or FIFO modules, interface adaptation modules, etc. Additionally, the architecture design module 12 uses `arch_outline` to generate the top-level architecture, data flow, and control flow. Furthermore, the architecture design module 12 uses `define_interface` to specify the ports, directions, bit widths, handshake relationships, and timing relationships of each submodule. Furthermore, the architecture design module 12 uses `gen_arch_json` to generate machine-readable architecture JSON. Finally, the architecture design module 12 uses the `gen_design` skill to create an implementation-oriented architecture design document. The technical role of this step is to pre-define the module boundaries, interface relationships, data flow, control flow, and performance constraints in complex scenarios, reducing the free divergence in subsequent RTL generation.

[0073] After that, such as Figure 3 As shown, during the RTL implementation phase, the processor, via the RTL implementation module 13 (Implementer), generates a set of artifacts based on the structured development brief. This set of artifacts includes requirement artifacts, architecture artifacts, and RTL artifacts.

[0074] Here, the RTL implementation module 13 has the hier_verilog_gen and design_specifications skills.

[0075] Specifically, the processor can first generate requirement artifacts based on the structured development briefing via RTL implementation module 13. Here, the requirement artifacts include delivery metadata, confirmed facts, open questions, and the requirement text.

[0076] Subsequently, the processor can generate architectural artifacts based on the required artifacts via RTL implementation module 13. Here, the architectural artifacts include the module partitioning results, interface timing definitions, and architectural descriptions.

[0077] Subsequently, the processor can generate RTL artifacts based on the architecture artifacts via RTL implementation module 13. Here, the RTL artifacts are subject to the separation of combinational and sequential logic, explicit declaration of bit width, non-blocking assignment, and avoidance of implicit latch constraints.

[0078] Subsequently, the processor can use the RTL implementation module 13 to form a set of workpieces from the requirement workpiece, the architecture workpiece, and the RTL workpiece.

[0079] Here, RTL implementation module 13 can generate Verilog / SystemVerilog source code based on requirements documents, architecture documents, and architecture JSON. The `hier_verilog_gen` skill supports complex hierarchical structure parsing and multi-module RTL generation, avoiding stacking all logic in a single `always` block. The `design_specifications` skill is used to constrain the generated code to meet industry standards for functional correctness, synthesizability, timing friendliness, and PPA friendliness, including file, module, port, and signal naming, clock reset design, separation of combinational / timing logic, explicit bit width declaration, non-blocking assignment usage, avoidance of implicit latches, avoidance of non-synthesizable statements, pipelined register insertion, combinational path control, and modular encapsulation. The output RTL is registered as an engineering artifact and associated with the corresponding requirements version and architecture version. The technical role of this step is to convert the preceding structured design into a disk-persistent, compileable, and traceable RTL implementation.

[0080] After that, such as Figure 3 As shown, during the verification phase, the processor can verify whether the set of artifacts and the set of hardware constraints are successfully matched via the verification module 14 (Tester), and in response to the verification result of successful matching, generate hardware description language code for the RTL artifacts.

[0081] Here, the verification module 14 has skills such as tb_scenarios_prompt, tb_rules_extract, cocotb_support, mage_sim_judge_tb_fix, and iverilog_waveform_parser.

[0082] Specifically, verification module 14 uses the `tb_scenarios_prompt` skill to generate normal, boundary, and abnormal test scenarios. Furthermore, verification module 14 uses the `tb_rules_extract` skill to extract assertion conditions and check rules from the requirements specification. Additionally, verification module 14 uses the `cocotb_support` skill to generate or organize a Python / cocotb test platform, depending on the applicable scenario. Furthermore, verification module 14 invokes Icarus Verilog, VVP, cocotb skills, or other simulation tools to perform compilation and simulation. If the simulation fails, verification module 14 uses the `iverilog_waveform_parser` skill to parse VCD / FST waveforms or simulation logs, extracting key cycles, signal jumps, differences between expected and actual values, state machine transition anomalies, and output delay deviations. Furthermore, verification module 14 uses the `mage_sim_judge_tb_fix` skill to determine whether the failure originates from RTL or the Testbench, and repairs problems if they exist in the test platform. The technical purpose of this step is to transform functional errors, test errors, and waveform evidence into structured verification results that can be used for subsequent attribution.

[0083] Specifically, the processor can first use the style parser to perform syntax and semantic checks on the RTL artifact via the verification module 14 to verify whether the RTL artifact meets the synthesizability constraints and interface constraints, and generate compilation verification results.

[0084] Subsequently, the processor can perform functional simulation on the RTL workpiece according to the test cases via the verification module 14 to verify whether the RTL workpiece meets the reset constraints and generate simulation verification results.

[0085] Then, the processor can use the verification module 14 and the fast synthesis tool to perform logic synthesis and static timing analysis on the RTL artifact to verify whether the RTL artifact meets the timing constraints and generate synthesis verification results.

[0086] Here, the verification module 14 has the skills run_vivado_synthesis, timing_analysis, and timing_opt.

[0087] Specifically, for tasks requiring engineering feasibility verification, verification module 14 invokes the `run_vivado_synthesis` skill to launch the self-developed rapid synthesis tool. This tool consists of an outer script and a Vivado Tcl Worker: the outer script is responsible for input verification, RTL file discovery, constraint configuration, strategy selection, parallel task scheduling, and report aggregation. Verification module 14 uses the Tcl Worker skill to perform project creation, RTL / XDC reading, synthesis, optimization, placement, physical optimization, routing, and report export in Vivado / Vitis. Verification module 14 further invokes the `timing_analysis` skill to classify and analyze combinational logic, sequential logic, pipelines, high fan-out, cross-clock domain, critical path, and resource utilization, and invokes the `timing_opt` skill to provide optimization strategies such as adding pipeline stages, splitting combinational logic, reducing fan-out, adjusting state machine coding, refactoring memory access, inserting register slices, or returning to the architecture stage to modify module boundaries. The technical role of this step is to advance the RTL generation results to the synthesis, implementation, and timing check stages in the real FPGA development chain.

[0088] Subsequently, in response to the successful matching of the compilation verification results, simulation verification results, and comprehensive verification results, the processor can determine, via verification module 14, that the workpiece set and the hardware constraint set are successfully matched.

[0089] Next, the processor can deliver the successfully matched artifacts. When simulation, synthesis, implementation, or timing checks meet the targets, the processor can output the final RTL source code, requirements document, architecture design document, architecture JSON, test platform, simulation report, synthesis / timing report, failure repair record, and auditable logs. If the budget is exhausted and the targets are not met, the system outputs the current best artifact, evidence of failure, unresolved issues, suggested points for manual intervention, and directions for future optimization. The technical purpose of this step is to deliver the results as a collection of engineering artifacts, rather than just outputting a piece of untraceable code text.

[0090] Alternatively, in some embodiments, in response to a verification result of an unsuccessful match, the processor may generate rollback handover data via the rollback positioning module 16. Here, the rollback handover data includes a failure summary, evidence citations, rollback target stage, allowed modification scope, and retry budget.

[0091] Specifically, the processor can perform structured parsing of the verification results to determine error information between the set of workpieces and the set of hardware constraints.

[0092] The processor can then determine the target rollback stage and its permitted modification scope based on the error information. Here, the target rollback stage is one of the aforementioned requirements extraction stage, architecture design stage, RTL implementation stage, and verification stage. The permitted modification scope indicates the module identifiers, interface list, and code regions that are allowed to be modified.

[0093] For example, in response to an error message indicating a compiler syntax error or an unrecognized identifier, the processor can determine that the rollback target stage is the RTL implementation stage.

[0094] For example, when the error category in the error message is port name mismatch or bit width mismatch, the processor can determine whether the rollback target stage is the architecture design stage or the RTL implementation stage based on the scope of impact.

[0095] For example, when the error category in the error message is that timing constraints or design constraints are not met, the processor can determine that the rollback target stage is the architecture design stage.

[0096] For example, when the error category in the error message is "test case functionality failed", the processor can determine whether the rollback target stage is the architecture design stage or the requirements extraction stage.

[0097] For example, when the error category in the error message is test platform stimulus error, assertion rule error, or expected value setting error, the processor can determine that the rollback target stage is the verification stage.

[0098] The technical purpose of this step is to avoid simply attributing all failures to the RTL text generated during the RTL implementation phase, thereby improving the accuracy of the repair direction.

[0099] Those skilled in the art will understand that the above-described embodiments of rollback using the requirements, architecture, RTL, verification, and timing phases are merely some non-limiting implementations provided by the present invention, intended to clearly demonstrate the main concepts of the present invention and provide some specific solutions that are easy for the public to implement, rather than intended to limit the scope of protection of the present invention.

[0100] Alternatively, in other embodiments, those skilled in the art may also employ version rollback based on Git / worktree, artifact snapshots based on object storage, state recovery based on database, or partial rollback based on difference patches. As long as evidence of failure is preserved and the scope of modification is limited, controlled iteration can be achieved.

[0101] Furthermore, the simulation tools mentioned above are replaceable. For example, Icarus Verilog / vvp can be replaced by Verilator, VCS, Xcelium, QuestaSim, or other simulators. cocotb can be replaced by SystemVerilog UVM, a custom Python test framework, or a C++ test framework. The key is that the tool output should be parsed into structured evidence.

[0102] Synthesis and implementation tools are replaceable. For example, Vivado / Vitis and Xilinx Alveo V80 are preferred embodiments. For Intel FPGAs, Quartus can be used instead. For open-source workflows, Yosys, nextpnr, or OpenROAD can be used. For ASIC front-ends, Design Compiler, Genus, or other synthesis tools can be used instead. As long as synthesis, timing, resource, or implementation reports can be output, the feedback loop of this invention can be integrated.

[0103] The hardware platform is replaceable. For example, the Alveo V80 can be replaced with other Xilinx, AMD, Intel, Lattice, or domestic FPGA platforms. The target frequency can be changed to 100MHz, 200MHz, 300MHz, or other values ​​depending on the task. The XDC constraint can also be replaced with SDC or other constraint formats.

[0104] The processor can then return to the rollback target stage in the rollback handover data and regenerate the artifact set under constrained policy constraints. These constrained policy constraints include at least one of the following: maximum number of retries, maximum number of rollbacks, and maximum total number of steps.

[0105] Specifically, the processor can first drive the workflow state machine to roll back to the rollback target stage based on the rollback handover data, and initialize the retry counter and step counter in the constrained policy.

[0106] Afterwards, the processor can regenerate the workpiece set for correction within the allowed modification range via the RTL implementation module 13, and monitor the consumption of the retry counter and the step counter.

[0107] Subsequently, in response to reaching the threshold of maximum retries, maximum rollbacks, or maximum total steps, the processor can terminate the regeneration process.

[0108] Specifically, at this stage, the controlling agent does not retry indefinitely. Instead, it records a failure summary, evidence references, recovery points, allowed modification range, remaining retry budget, and remaining rollback budget after each failure. For example, when the synthesis report shows that the control signal fanout of a certain state machine is too high, the processor can restrict the RTL implementation module 13 to modify only the control signal registers and local fanout structures. When the critical path comes from an architecturally unreachable single-cycle multiply-accumulate chain, the processor can roll back to the architecture design stage to replan the pipeline. If the task continues for multiple rounds, the processor writes a large amount of logs, waveforms, synthesis reports, and intermediate code to the working area, retaining only the summary, path, and key evidence in the context, and writing platform constraints, coding standards, historical failure reasons, and optimization strategies to long-term memory. The technical role of this step is to maintain the consistency of key constraints in long tasks, while preventing unbounded retries, irrelevant modifications, and context pollution.

[0109] In summary, the above-mentioned method, apparatus and storage medium for generating hardware description language code for FPGA development provided by the present invention can improve the reproducibility, controllability and traceability of the automatic RTL generation process by constructing a structured delivery contract, a structured handover data model and a verification closed-loop rollback and retry strategy, and support the automated engineering implementation of the entire hardware development process.

[0110] Specifically, the above-mentioned method, apparatus and storage medium for generating hardware description language code for FPGA development provided by the present invention establish a collaborative framework and workflow for a complete agent team for FPGA development.

[0111] The hardware description language code generation device for FPGA development first receives task input from the master intelligent agent and establishes a task state machine. The task state machine includes at least the following states: requirement extraction, architecture design, RTL implementation, functional verification, synthesis timing check, failure location, rollback and retry, and delivery archiving. The master intelligent agent calls the corresponding role-based teammates according to the current state. Requirement extraction module 11 handles requirement clarification, architecture design module 12 handles module partitioning and interface design, RTL implementation module 13 handles RTL code generation, and verification module 14 handles test platform setup, simulation, and waveform analysis. For long logs, timing reports, or partial code review tasks, the master intelligent agent derives sub-intelligent agents to process and return a summary. The system further configures accessible artifacts, callable tools, and modifiable file ranges for each role, and transmits the task summary, input artifacts, output artifacts, confirmed facts, assumptions, risks, open questions, failure evidence, and allowed modification range as structured fields through `team_handoff_protocol`. For long-cycle tasks, the system writes a large amount of logs, waveforms, synthesis reports, and intermediate code to the workspace, only writing summaries, paths, and key evidence to the current context, and writing platform constraints, coding standards, historical failure reasons, and optimization strategies to long-term memory. When simulation failures, assertion failures, waveform anomalies, synthesis errors, timing violations, or resource anomalies occur, the master control agent determines the rollback target based on the error category, affected artifacts, line number / signal name, critical path, or failed stage in the structured evidence, and returns to the requirements, architecture, RTL, test platform, or timing optimization stage for re-execution, carrying evidence references, recovery points, allowed modification scope, and remaining budget.

[0112] Through the aforementioned methods, the hardware description language code generation device for FPGA development transforms the large model from a single-cycle code generator into an engineering process executor constrained by a state machine, reducing role confusion and implicit assumptions. Structured handover and permission boundaries mitigate the risks of cross-role information loss, unauthorized modifications, and artifact inconsistencies. Context compression and long-term memory maintain consistency of key constraints, platform rules, and historical failure experiences across multiple rounds of FPGA development tasks. Evidence-based phased rollback avoids blindly rewriting current code after failures, improving the controllability, traceability, and convergence speed of complex RTL tasks. In the current experiment, this complete collaborative framework and workflow, as the system-level foundation, increased the full pass rate of VerilogEval V2 from 46.5% generated directly by GPT-5.2 to 95.6%, demonstrating a significant improvement over single-cycle or few-round prompt generation methods.

[0113] Furthermore, the above-mentioned method, apparatus and storage medium for generating hardware description language code for FPGA development provided by the present invention are configured with 20 skills covering five types of tasks.

[0114] Specifically, the hardware description language code generation device for FPGA development defines the applicable stage, calling role, input artifact, output artifact, execution steps, inspection rules, and failure handling methods for each skill, and the master control agent loads the corresponding skills according to the task status and role permissions. In the requirements extraction stage, `refine_requirement_from_chat` is used to extract ports, resets, clocks, delays, throughput, boundary behaviors, and hardware constraint gaps from user input, and `gen_requirement_document` is used to generate reviewable requirement specifications. In the architecture design stage, `roofline_model` is used to calculate bandwidth and throughput balance, `module_list` is used to split sub-modules, `arch_outline` is used to generate the top-level structure, `define_interface` is used to determine port orientation and bit width, `gen_arch_json` is used to form a machine-resolvable architecture file, and `gen_design` is used to generate design documents. In the code implementation phase, `hier_verilog_gen` generates a hierarchical Verilog based on the architecture JSON and module list, while `design_specifications` constrains naming, clock reset, bit width, separation of combinational / timing logic, pipelining, synthesizability, and PPA friendliness. In the verification phase, `tb_scenarios_prompt`, `tb_rules_extract`, `iverilog_waveform_parser`, `mage_sim_judge_tb_fix`, `cocotb_support`, `timing_analysis`, `run_vivado_synthesis`, and `timing_opt` handle test scenarios, assertion rules, waveform parsing, test platform repair, COcotb support, timing classification, synthesis execution, and timing optimization, respectively. In the workflow control phase, `fpga_project_flow` and `team_handoff_protocol` control iteration strategies, token resources, role handover, and rollback protocols.

[0115] Through the above methods, FPGA engineering experience is no longer confined to scattered prompts but transformed into process knowledge that can be invoked in stages, reviewed, and reused. Unified input-output constraints exist between requirements, architecture, implementation, verification, and timing optimization, reducing omissions and inconsistencies in complex scenarios such as multi-stage pipelines, interface definitions, state machines, asynchronous FIFOs, synchronizers, testbench, and timing optimization. Simultaneously, different agents collaborate under the same set of skill constraints, reducing the propagation of ambiguity caused by free text collaboration. This skill system is one of the key reasons why this invention maintains a high pass rate in complex tasks, especially enabling the system to handle complex pipeline, state machine, synchronizer, FIFO, and timing constraint problems that are difficult to solve stably with direct GPT-5.2, thus supporting a 95.6% pass rate across all 156 questions.

[0116] Furthermore, the above-mentioned method, apparatus and storage medium for generating hardware description language code for FPGA development provided by the present invention establish an automated tool closed loop for the real FPGA development chain.

[0117] Specifically, after the RTL is generated, the hardware description language code generation device for FPGA development is triggered by the verification module 14 or the main control agent to simulate the toolchain, calling IcarusVerilog, VVP, COcotb, or other simulators to compile and run the code, and registering stdout / stderr, failed test cases, assertion results, and waveform files as verification artifacts. The waveform analysis tool reads files such as VCD / FST, and automatically extracts signal transitions, key cycles, state transitions, and differences between expected and actual values ​​based on failed test cases, assertion conditions, candidate signals, and time windows, and generates a structured failure summary of "signal-cycle-expected behavior-actual behavior-possible cause". The difference between this tool and GTKWave is that GTKWave is mainly for manual viewing and interactive analysis, while the waveform analysis tool of this invention is for automatic diagnosis by the intelligent agent, and can output a summary that can be used for subsequent prompts, attribution, and rollback without manual visual operation. For tasks requiring engineering feasibility verification, the system calls `run_vivado_synthesis` to launch a rapid synthesis tool. This tool consists of an outer script and a Vivado Tcl Worker. The outer script handles input validation, RTL file discovery, constraint configuration, strategy selection, parallel task scheduling, log trimming, and report aggregation. The Tcl Worker performs project creation, reads RTL / XDC, synthesis, optimization, placement, physical optimization, routing, and report export within Vivado / Vitis. The difference between this tool and Vivado / Vitis is that Vivado / Vitis provides low-level synthesis implementation and timing analysis capabilities, while this invention's rapid synthesis tool encapsulates the call process and output results in an agent-oriented closed-loop manner. It automatically extracts WNS / TNS, critical paths, high fan-out networks, resource utilization, logical levels, failure stages, suspicious modules / signals, and reporting paths, and sends these results back to `timing_analysis`, `timing_opt`, and the master agent to determine whether to perform local RTL optimization or architecture-level rollback.

[0118] Through the aforementioned methods, the feedback obtained by the hardware description language code generation method, apparatus, and storage medium for FPGA development provided by this invention comes from real EDA tools and FPGA implementation processes, rather than relying solely on model self-judgment. Simultaneously, waveforms and synthesis results, originally primarily intended for human reading or interaction, are transformed into structured evidence that can be consumed by intelligent agents, enabling repair suggestions to be mapped to specific signals, periods, paths, modules, or stages. The generated code thus gradually converges from being "syntactically similar to Verilog" into an engineering deliverable that is simulable, synthesizable, implementable, timing-checkable, and capable of PPA optimization. In current Alveo V80 board-level implementation experiments, the pass rate for directly generating baselines on 27 timing / performance issues was 0%, VerilogCoder-like methods achieved 33.3%, while this invention reached 88.9%, demonstrating that the tool's closed-loop significantly improves the ability of generated RTL to enter the real FPGA implementation process.

[0119] Although the methods described above are illustrated and depicted as a series of actions for the sake of simplicity, it should be understood and appreciated that these methods are not limited by the order of the actions, as some actions may occur in a different order and / or concurrently with other actions from the illustrations and descriptions herein or not illustrated and described herein but which may be understood by those skilled in the art, according to one or more embodiments.

[0120] Those skilled in the art will understand that information, signals, and data can be represented using any of a variety of different techniques and skills. For example, the data, instructions, commands, information, signals, bits, symbols, and chips described throughout the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any combination thereof.

[0121] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps are described above in a generalized manner in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as departing from the scope of the invention.

[0122] Although the controller described in the above embodiments can be implemented through a combination of software and hardware, it is understood that the controller can also be implemented in software or hardware. For hardware implementation, the controller can be implemented using one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic devices for performing the above functions, or a selection of combinations of the above devices. For software implementation, the controller can be implemented using independent software modules such as procedures and functions running on a general-purpose chip, each module performing one or more functions and operations described herein.

[0123] The various illustrative logic modules and circuits described in conjunction with the embodiments disclosed herein may be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternatives, it may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0124] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read and write information to / from the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and storage medium may reside as discrete components in the user terminal.

[0125] In one or more exemplary embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functionality may be stored or transmitted as one or more instructions or code on or through a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, encompassing any medium that facilitates the transfer of a computer program from one location to another. A storage medium may be any available medium accessible to a computer. By way of example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and is accessible to a computer. Any connection is also legitimately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. As used in this article, disk and disc include compact discs (CDs), laser discs, optical discs, digital multi-purpose discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of these should also be included within the scope of computer-readable media.

[0126] The prior description of this disclosure is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for generating hardware description language code for FPGA development, characterized in that, Includes the following steps: During the requirement extraction phase, the user's task requirements for the hardware description language code are obtained to extract the hardware constraint set for the FPGA development. The hardware constraint set includes at least interface constraints, reset constraints, and timing constraints. During the architecture design phase, a structured development briefing that satisfies the structured delivery contract is generated based on the set of hardware constraints. In the RTL implementation phase, requirement artifacts are generated based on the structured development briefing, architecture artifacts are generated based on the requirement artifacts, and RTL artifacts are generated based on the architecture artifacts. The requirement artifacts, architecture artifacts, and RTL artifacts constitute an artifact set. The requirement artifacts include delivery metadata, confirmed facts, open issues, and requirement text. The architecture artifacts include module partitioning results, interface timing definitions, and architecture descriptions. The RTL artifacts are subject to the separation of combinational and sequential logic, explicit bit-width declaration, non-blocking assignment, and avoidance of implicit latch constraints. During the verification phase, a style parser is used to perform syntax and semantic checks on the RTL artifact to verify whether the RTL artifact meets the interface constraints and to generate compilation verification results. Based on the test cases, functional simulation is performed on the RTL workpiece to verify whether the RTL workpiece satisfies the reset constraint, and simulation verification results are generated. The RTL artifact is subjected to logic synthesis and static timing analysis using a rapid synthesis tool to verify whether the RTL artifact meets the timing constraints and generate synthesis verification results. In response to the successful matching of the compilation verification result, the simulation verification result, and the comprehensive verification result, it is determined that the workpiece set and the hardware constraint set are successfully matched; and In response to the successful verification result, hardware description language code for the RTL artifact is generated.

2. The generation method as described in claim 1, characterized in that, It also includes the following steps: In response to a verification result indicating an unsuccessful match, rollback handover data is generated, including a failure summary, evidence citations, rollback target stage, allowed modification range, and retry budget; and Return to the rollback target stage in the rollback handover data, and regenerate the workpiece set under the constraints of the restricted strategy, wherein the restricted strategy constraints include at least one of the maximum number of retries, the maximum number of rollbacks, and the maximum total number of steps.

3. The generation method as described in claim 2, characterized in that, The step of generating rollback handover data in response to a verification result of unsuccessful matching includes: The verification results are structured and parsed to determine error information between the workpiece set and the hardware constraint set; and Based on the error information, the target rollback stage and its allowed modification range are determined. The target rollback stage is one of the requirement extraction stage, the architecture design stage, the RTL implementation stage, and the verification stage. The allowed modification range is used to indicate the module identifiers, interface lists, and code areas that are allowed to be modified.

4. The generation method as described in claim 3, characterized in that, The step of determining the rollback target stage and its allowed modification range based on the error information includes: When the error category in the error message is a compiler syntax error or an unrecognized identifier, the rollback target stage is determined to be the RTL implementation stage; When the error category in the error message is port name mismatch or bit width mismatch, the target stage for the rollback is determined to be the architecture design stage or the RTL implementation stage based on the scope of impact. When the error category in the error message is that the timing constraint or design constraint is not met, the rollback target stage is determined to be the architecture design stage; and When the error category in the error message is "test case function fails", the target rollback stage is determined to be either the architecture design stage or the requirements extraction stage.

5. The generation method as described in claim 2, characterized in that, The step of returning to the rollback target stage in the rollback handover data and regenerating the workpiece set under constrained policy constraints includes: Based on the rollback handover data, the workflow state machine is driven to roll back to the rollback target stage, and the retry counter and step counter in the restricted policy constraints are initialized. Within the allowed modification range, the workpiece set is regenerated for correction, and the consumption of the retry counter and step counter is monitored; and The regeneration process is terminated in response to reaching the threshold of the maximum number of retries, the maximum number of rollbacks, or the maximum total number of steps.

6. A device for generating hardware description language code for FPGA development, characterized in that, include: Memory, on which computer instructions are stored; as well as A processor, connected to the memory, and configured to execute computer instructions stored in the memory to implement the method for generating hardware description language code for FPGA development as described in any one of claims 1 to 5.

7. The generating apparatus as described in claim 6, characterized in that, The processor further includes: The requirement extraction module is used to obtain the user's task requirements for the hardware description language code during the requirement extraction stage, so as to extract the set of hardware constraints for the FPGA development. The architecture design module is used to generate a structured development brief that satisfies the structured delivery contract based on the set of hardware constraints during the architecture design phase. The RTL implementation module is used to generate a set of artifacts based on the structured development brief during the RTL implementation phase; and The verification module is used to verify, during the verification phase, whether the workpiece set and the hardware constraint set are successfully matched.

8. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the computer instructions are executed by the processor, the method for generating hardware description language code for FPGA development as described in any one of claims 1 to 5 is implemented.

Images