FPGA verification method and system for double-layer skill architecture enhanced general agent

Abstract

The application provides an FPGA verification method and system for a double-layer skill architecture enhanced general intelligent agent. The method comprises: encapsulating each verification capability in an FPGA verification process as a business skill module complying with a standardized encapsulation specification; reading the standardized encapsulation description of each business skill module through a capability layer, and dynamically determining a process state to be executed and a business skill module calling relationship according to DUT characteristics; a verification process arranger receiving an FPGA verification instruction and analyzing DUT information, generating a business skill module calling sequence based on the DUT analysis result, and managing process advancement and breakpoint continuation through a state machine; and an exception handler classifying tool-level exceptions, process-level exceptions and logic-level exceptions, executing corresponding recovery strategies, and updating the process state according to the recovery result. The application realizes automatic arrangement of the FPGA verification process, exception recovery and cross-session continuation, and improves verification efficiency and reliability.

Description

Technical Field

[0001] This application relates to the fields of integrated circuit EDA (electronic design automation) and artificial intelligence (AI) verification automation technology, specifically to an FPGA verification method and system for a two-layer Skill architecture-enhanced general-purpose intelligent agent. Background Technology

[0002] Field-programmable gate arrays (FPGAs) are widely used in communications, data centers, autonomous driving, and aerospace electronics due to their high flexibility and parallel processing capabilities. However, verifying the correctness of FPGA designs remains the most time-consuming and labor-intensive step in the entire development process.

[0003] The current FPGA (Field-Programmable Gate Array) verification process mainly relies on manual operation. Engineers need to manually complete tasks such as environment setup, DUT (Design Under Test) analysis, test case writing, script generation, and result analysis.

[0004] In recent years, agent technology has developed rapidly, possessing certain reasoning and code generation capabilities, and has begun to be applied in the engineering field. In the field of agents, the artificial intelligence company Anthropic proposed "Skill technology" in October 2025. Skill technology encapsulates the domain knowledge, operation procedures, tool scripts, and best practices required for specific tasks into a standardized "Skill Package," transforming large models from general chatbots into agents with specific domain expertise.

[0005] However, existing Skill standards only define the encapsulation format and basic calling protocol for a single Skill, without addressing issues such as orchestration and collaboration between multiple Skills, state management, and anomaly self-healing. In FPGA verification, a typical complex engineering scenario characterized by multiple stages, multiple tools, and multiple input / output dependencies, relying solely on the sequential invocation of isolated Skill packages is far from sufficient to achieve end-to-end automated verification.

[0006] In summary, the existing technical solutions have the following main shortcomings: (1) General intelligent agents lack the ability to plan and dynamically orchestrate the FPGA verification process. Currently, intelligent agents can only respond to single-step instructions. Faced with the complex process of FPGA verification, which includes multiple related steps such as environment initialization, DUT (Device Under Test) analysis, policy generation, test platform generation, simulation execution, and result analysis, they cannot autonomously complete step decomposition, sequential arrangement, and state management, resulting in a lack of continuity and controllability in process execution.

[0007] (2) The verification capabilities lack standardized encapsulation, and expert experience cannot be reused across projects. The verification scripts, test platforms and tool configurations developed by different engineers vary, and there is a lack of unified encapsulation specifications. As a result, the verification capabilities cannot be accumulated and reused in the form of standardized modules, and valuable verification experience is lost after the project ends.

[0008] (3) Weak exception handling capabilities and lack of adaptive recovery mechanism based on execution feedback. During FPGA verification, EDA tools (such as Vivado, ModelSim, VCS) frequently encounter exceptions such as startup failure, missing dependencies, and simulation timeouts. Existing solutions directly interrupt the process when encountering exceptions, and cannot classify and automatically recover exceptions based on execution results and logs, resulting in insufficient process robustness and a lot of time wasted on repetitive troubleshooting. Summary of the Invention

[0009] Therefore, it is necessary to provide an FPGA verification method and system for enhancing general intelligent agents with a two-layer Skill architecture to address the aforementioned technical issues.

[0010] Firstly, this application provides an FPGA verification method for a two-layer Skill architecture-enhanced general-purpose intelligent agent, applied to an FPGA chip simulation verification process that includes environment initialization, DUT analysis, verification strategy generation, verification scheme generation, reference model generation, test platform generation, execution script generation, simulation execution, and result analysis. The method includes the following steps: Each verification capability in the FPGA verification process is encapsulated into a business Skill module of the business execution layer that follows a standardized encapsulation specification. The standardized encapsulation specification includes functional description and scope of application, input and output data format, execution prerequisites and result guarantees, and exception reporting method. The capability layer reads the standardized encapsulation descriptions of each of the service skill modules and dynamically orchestrates the FPGA verification process based on the DUT characteristics; the capability layer includes a verification process orchestrator and an exception handler. The verification process orchestrator receives FPGA verification instructions and parses DUT information, then calls the DUT analyzer to generate DUT analysis results. Based on the DUT analysis results and the standardized encapsulation descriptions of each service skill module, the verification process orchestrator generates a service skill module call sequence for the current DUT. The service skill modules are called sequentially according to the call sequence, with preconditions checked before each call and postconditions checked after each call. The output of the upstream service skill module is used as the input of the downstream service skill module. The process state is updated through a state machine, and the advancement and breakpoint resumption of the FPGA verification process are managed. Checkpoints are saved at preset state nodes, and the execution results of each service skill module are summarized and fed back to the general intelligent agent. The exception handler uses the execution results and simulation logs generated by the business Skill module during FPGA simulation verification as the data source to classify tool-level exceptions, process-level exceptions, and logic-level exceptions. It selects and executes candidate recovery strategies based on the exception category, current process state, preconditions, and recovery strategy constraints. It updates the process state based on the recovery execution result and writes the exception context and recovery result into the log and history. If the recovery fails, it selects the next candidate recovery strategy or terminates the current verification process.

[0011] In one embodiment, the functional description and scope of application include applicable DUT hardware design types and EDA toolchain information; the DUT hardware design types include processor cores, interface controllers, and storage subsystems; the EDA toolchain information includes EDA tools used for compilation, simulation, and result analysis, and their version information; the verification process orchestrator matches the business skill modules required for the current verification task based on the DUT analysis results, the functional description and scope of application, and preconditions; the input and output data format is based on JSON. The schema defines the input and output formats for unified data transfer between business skill modules. The execution preconditions and postconditions include: preconditions such as EDA tools being installed and version compatible, DUT source code being parsed or accessible, and reference models or alternative result judges being ready for result comparison; postconditions include verifiable output states such as generated environmental monitoring reports and output test platform code. The exception reporting method maps internal exceptions generated by the business skill module during FPGA verification execution to standardized exception codes and sends them to the exception handler for unified processing. Internal exceptions include EDA tool errors, hardware description language parsing failures, and simulation result mismatches.

[0012] In one embodiment, the verification process orchestrator includes: a template baseline, using a standard process state set for FPGA verification as the template baseline, the state set including environment initialization, DUT analysis, verification strategy generation, verification scheme generation, reference model generation, test platform generation, execution script generation, simulation execution, and result analysis; dynamic adjustment, dynamically adjusting the call sequence at runtime based on the hardware design complexity, interface type, and protocol characteristics in the DUT analysis results; and when there is a registered reference model that has passed interface consistency verification, or an alternative result determiner that has been configured and verified to be usable, and the result analyzer is configured to call the corresponding determiner. When the source is in progress, the reference model generation step is marked as exempt from execution; when the protocol features are confirmed and the corresponding protocol validator is available, a protocol compliance verification step is inserted; for breakpoint resumption, checkpoint files are saved and process status files are updated at key state nodes. The process status file records the current state, completed steps, pending steps, and state transition information, while the checkpoint file records state snapshots, output indexes, and verification information, all stored in the workspace directory in JSON format; a new session reads the process status file and the most recent checkpoint file and performs consistency verification. After the verification passes, execution resumes from the next pending step of the most recently confirmed completed state.

[0013] In one embodiment, saving checkpoint files and updating process status files at key state nodes includes: when the verification process orchestrator initializes a new session, it detects whether there are incomplete process status files and the most recent checkpoint file in the workspace, reads the status and product verification information recorded in both, and performs consistency verification; after the verification passes, it continues execution from the next pending step of the most recently confirmed completed state; after the user passes JSONSchema verification, state transition rule verification, and completed product consistency verification, the process status file is edited to adjust the verification process; process status, checkpoint metadata, logs, reports, and structured execution results are saved in text formats such as JSON, Markdown, or HTML, simulation waveforms and other EDA native products are saved in the tool's native format, and their paths, summaries, and verification information are recorded in the process status file or checkpoint file.

[0014] The exceptions of the exception handler are classified as follows: tool-level exceptions, including EDA simulation tool startup failure, running crash, and execution timeout; process-level exceptions, including EDA tool preconditions not being met, missing DUT source code dependency files, and data format mismatch between upstream and downstream business Skill modules; and logic-level exceptions, including FPGA simulation results not matching the expected results of the reference model and verification coverage not meeting the standard.

[0015] In one embodiment, the exception handler sorts candidate recovery strategies based on exception type, current process state, applicable conditions of recovery strategy, and historical execution results, and selects a priority strategy from the candidate recovery strategies that meet the execution conditions. The recovery strategy selection includes: for tool-level exceptions, executing a retry with a backoff strategy or switching to a backup EDA simulation tool that has been verified for compatibility; for process-level exceptions, calling the corresponding business Skill module to locate the missing DUT dependency files, and only completing the missing files when the dependency source is clear and passes the integrity verification, or regenerating the EDA tool configuration, or adjusting the call sequence to meet the preconditions; for logic-level exceptions, recording the details of the difference between the actual simulation output and the expected output, marking the logic-level exception as failed, and continuing to execute subsequent test cases.

[0016] Secondly, this application also provides an FPGA verification system for a dual-layer Skill architecture-enhanced general-purpose intelligent agent, applied to an FPGA chip simulation verification process that includes environment initialization, DUT analysis, verification strategy generation, verification scheme generation, reference model generation, test platform generation, execution script generation, simulation execution, and result analysis. The system includes: The intelligent agent layer is used to receive FPGA verification instructions from users, call the capability layer to perform task parsing, process scheduling and result interaction, and support the access and switching of multiple base large models; The business execution layer includes multiple business skill modules that conform to standardized packaging specifications, used to execute specific FPGA verification tasks. These business skill modules include an environment analyzer, a DUT analyzer, a verification strategy generator, a verification scheme generator, a reference model generator, a test platform generator, an execution script generator, a simulation executor, and a result analyzer. The standardized packaging specifications include functional descriptions and applicable scope, input and output data formats, execution preconditions and postconditions, and exception reporting methods. The capability layer, connected to both the agent layer and the business execution layer, is used to read the standardized encapsulation description of the business execution layer and provide the agent with FPGA verification process orchestration and exception handling capabilities. The dual-layer Skill architecture includes the capability layer and the business execution layer, and the agent layer is an interaction and task scheduling layer connected to the dual-layer Skill architecture. The capability layer includes a verification process orchestrator and an exception handler. The verification process orchestrator is used to decompose the verification task into a call sequence of business Skill modules according to the DUT characteristics, manage the advancement and breakpoint resumption of the FPGA verification process through a state machine, and persist the process status and checkpoints in a structured text file; the process status file records the current status, completed steps and steps to be executed, and the checkpoint file records the status snapshot, output index and verification information. The exception handler is used to classify tool-level exceptions, process-level exceptions, and logic-level exceptions based on the execution results and simulation logs generated by the business execution layer during FPGA simulation verification. It sorts candidate recovery strategies according to exception category, current process state, preconditions, and recovery strategy constraints, selects the recovery strategy that meets the execution conditions, executes the selected recovery strategy, and updates the process state based on the recovery execution result. If the recovery is successful, the interrupted process continues to execute. If the recovery fails, the next candidate recovery strategy is selected or the current verification process is terminated. The exception context and recovery result are written to the history record to form a closed-loop control process for exception handling that includes exception classification, recovery execution, state update, and result feedback. The capability layer reads the standardized encapsulation description of the business execution layer, dynamically arranges the FPGA verification process according to the DUT characteristics, and verifies the call sequence according to the preconditions, input / output formats and state transition rules.

[0017] Preferably, the business execution layer supports the dynamic registration of new business skill modules through a registration interface. The new business skill module submits description information and execution interface that conform to the standardized encapsulation specification. The capability layer reads the description information and, when the input and output formats are compatible with the existing process and the preconditions and postconditions are verifiable, includes the new business skill module in the FPGA verification process orchestration scope without modifying the logic of the verification process orchestrator. Preferably, the intelligent agent layer includes an adapter interface module, which receives a unified format verification task request, converts it into the input format of the target base model, and converts the output of the target base model into a unified response format before transmitting it to the capability layer, so as to realize the replacement of different base models; It has the following technical effects compared to existing technologies: (1) The capability layer provides the general agent with the ability to plan the FPGA verification process. FPGA verification involves multiple interdependent steps such as environment initialization, DUT source code parsing, verification strategy selection, test platform generation, simulation execution, and coverage analysis. The general agent can only respond to single-step instructions and cannot arrange them autonomously. This invention uses the verification process orchestrator in the capability layer to dynamically generate a call sequence based on the hardware design characteristics of the DUT (complexity, interface type, protocol characteristics), enabling the general agent to have the ability to autonomously schedule the entire process from verification planning to simulation execution.

[0018] (2) Standardized encapsulation enables cross-project reuse of FPGA verification capabilities. In different FPGA projects, verification capabilities such as DUT analysis, test platform generation, and simulation script configuration are difficult to reuse due to differences in engineers' personal styles. This invention encapsulates the EDA tool dependencies, Verilog / SystemVerilog input / output data formats, and verification environment prerequisites involved in verification capabilities into standardized modules through a unified Skill encapsulation specification. This supports cross-FPGA project reuse and effectively solves the problems of experience loss and knowledge accumulation among verification experts.

[0019] (3) Improving FPGA verification robustness through anomaly self-healing based on simulation execution feedback. During FPGA verification, EDA simulation tools frequently encounter anomalies such as startup failure, missing dependencies, and simulation timeouts, which traditional solutions directly interrupt the process. The anomaly processor of this invention uses simulation execution results and logs as the basic data source, classifies tool-level, process-level, and logic-level anomalies, and executes recovery strategies within a preset set of recovery strategies, such as retrying, switching to a compatibility-verified EDA tool, completing DUT dependency files with clear sources and integrity verification, or marking failed tests and continuing to execute subsequent tests. The strategy selection is continuously optimized by combining the recovery success rate in historical simulation logs, which significantly reduces the frequency of manual intervention in the FPGA verification process.

[0020] (4) The open architecture supports the business expansion of FPGA verification capabilities and the replacement of the base model. The business execution layer adopts a modular skill design, which supports the registration of new verification capabilities on demand (such as adding support for UVM verification methodology, adding adaptation to specific EDA toolchains), without modifying the orchestration logic of the capability layer; the general intelligent agent layer supports the flexible replacement of the underlying large model through the adapter pattern, reducing the impact of model iteration on the upper-layer FPGA verification business assets, and maintaining interface consistency through unified output format verification.

[0021] (5) Verification process interaction based on text files enables cross-session resume and human-machine collaboration. FPGA verification processes are typically time-consuming, and EDA tool malfunctions or human error may cause agent sessions to be interrupted. This invention persists the verification process status, checkpoints, and intermediate products to the workspace in the form of structured text files, allowing new agent sessions to resume execution from the interrupted position by reading the file, thus avoiding the waste of resources by repeatedly executing completed steps. At the same time, the text file format makes the verification status transparent to the user, allowing the user to edit the status file to adjust the verification process after JSON Schema verification, state transition rule verification, and consistency verification of completed products, thereby realizing human-machine collaborative verification process control. Attached Figure Description

[0022] Figure 1This is a schematic diagram of an FPGA verification method for a two-layer Skill architecture-enhanced general-purpose agent in one embodiment. Figure 2 Here is a flowchart of the verification process orchestrator in one embodiment; Figure 3 This is a schematic diagram of the cross-session verification process in one embodiment; Figure 4 This is a flowchart illustrating exception handling in one embodiment; Figure 5 This is a flowchart illustrating the verification process in one embodiment; Figure 6 This is a block diagram of an FPGA verification system for enhancing a general-purpose agent using a two-layer Skill architecture, as shown in one embodiment. Detailed Implementation

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

[0024] In one embodiment, such as Figure 1 As shown, an FPGA verification method for enhancing general-purpose intelligent agents using a two-layer Skill architecture is provided. This embodiment illustrates the method by applying it to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps: Step S1: Encapsulate each verification capability in the FPGA verification process into a business Skill module of the business execution layer that conforms to the standardized encapsulation specification.

[0025] The standardized encapsulation specifications include functional descriptions and applicable scope, input and output data formats, execution prerequisites and result guarantees, and exception reporting methods.

[0026] Step S2: Read the standardized encapsulation description of each of the service Skill modules through the capability layer, and dynamically orchestrate the FPGA verification process according to the DUT characteristics; the capability layer includes a verification process orchestrator and an exception handler; Step S3: The verification process orchestrator receives the FPGA verification instruction and parses the DUT information, calls the DUT analyzer to form the DUT analysis result; the verification process orchestrator generates a service skill module call sequence for the current DUT based on the DUT analysis result and the standardized encapsulation description of each service skill module; the service skill modules are called sequentially according to the call sequence, and the preconditions are checked before each call and the postconditions are checked after each call. The output of the upstream service skill module is used as the input of the downstream service skill module, and the process state is updated through the state machine to manage the advancement and breakpoint resumption of the FPGA verification process; checkpoints are saved at preset state nodes, and the execution results of each service skill module are summarized and fed back to the general intelligent agent; Step S4: The exception processor uses the execution results and simulation logs generated by the business Skill module during FPGA simulation verification as the data source to classify tool-level exceptions, process-level exceptions, and logic-level exceptions. It selects and executes candidate recovery strategies based on the exception category, current process state, preconditions, and recovery strategy constraints. It updates the process state based on the recovery execution result. If the recovery is successful, it continues to execute the interrupted process. If the recovery fails, it selects the next candidate recovery strategy or terminates the current verification process. The exception context and recovery result are written to the log and history.

[0027] In this context, a business skill module refers to a verification execution unit that encapsulates a specific verification capability within the FPGA verification process. Each business skill module contains the domain knowledge, operation procedures, tool invocation scripts, and best practices required to complete that verification capability. Each business skill module adheres to standardized encapsulation specifications, ensuring a unified interface description format and interaction protocol between different modules, thereby supporting data transfer and process integration between modules.

[0028] Furthermore, the standardized encapsulation specification defines a unified description format for the business skill module to be presented externally.

[0029] The functional description and scope of application declare the types of verification tasks and applicable scenarios that this business skill module can complete. It includes applicable DUT hardware design types and EDA toolchain information; the DUT hardware design types include processor cores, interface controllers, and storage subsystems; the EDA toolchain information includes EDA tools used for compilation, simulation, and result analysis, and their version information; the capability layer's verification process orchestrator matches the business skill modules required for the current verification task based on the DUT analysis results, functional description and scope of application, and preconditions.

[0030] Input and output data formats are defined to establish standardized input and output formats for unified data transfer between business skill modules. Input and output formats are defined based on JSON Schema. The output of upstream business skill modules must conform to the input format requirements of downstream business skill modules, and the orchestrator uses this to verify the data compatibility of the call chain.

[0031] The execution preconditions and postconditions include the declaration of preconditions and postconditions corresponding to the functions of each business Skill module. Preconditions include that the EDA tools are installed and the versions are compatible, the DUT source code has been parsed or is accessible, and the reference model or alternative result judge is ready when result comparison is required; postconditions include verifiable output states such as the generation of environmental detection reports and the output of test platform code; the verification process orchestrator uses these to verify the legality of the FPGA verification call chain.

[0032] The exception reporting method is used to map internal exceptions generated by the business Skill module during FPGA verification execution into standardized exception codes and send them to the exception handler in the capability layer for unified processing; the internal exceptions include EDA tool errors, hardware description language parsing failures, and simulation result mismatches.

[0033] In one embodiment, step S3 is implemented as follows: This embodiment defines a standard set of process states for FPGA verification as a template baseline for orchestration: environment initialization → DUT analysis → strategy generation → scheme generation → reference model generation → test platform generation → script generation → simulation execution → result analysis.

[0034] Template Baseline: The above standard process serves as the default execution template, covering the common steps of most FPGA verification projects.

[0035] Dynamic Adjustment: At runtime, the verification orchestrator dynamically adjusts the call sequence based on the DUT analysis results (including design complexity assessment, interface type identification, and protocol feature detection). For example, when a validated reference model, formal verification result, or protocol-level result determiner is detected, and the corresponding alternative result determination conditions are met, the reference model generation step can be marked as exempt from execution; when protocol features are confirmed and the corresponding protocol validator is available, a protocol compliance verification step is inserted.

[0036] Resume execution from the last checkpoint: Checkpoint files are saved at critical state nodes (such as when DUT analysis is complete or the test platform is generated). These files contain the current process status, output data of completed steps, and a list of steps to be executed. If the process is interrupted due to an exception, the orchestrator can resume execution from the most recent checkpoint without having to start from the beginning.

[0037] The process status file is also used for: When a new session is initialized, the verification process orchestrator checks whether there is an incomplete process status file in the workspace. If it exists, it reads the interruption position from the process status file and continues execution. The process status file is stored in JSON format, allowing users to directly view the verification progress and edit it to adjust the verification process after passing JSONSchema verification, status transition rule verification, and completed product consistency verification. Furthermore, the verification intermediate products and final results contained in the checkpoint file and the process status file are all in text format, and the text format is adapted to the file difference comparison and history backtracking of the version control system.

[0038] Validate the detailed workflow of the process orchestrator, such as Figure 2 As shown: Step S301: Receive instruction; The verification process orchestrator receives verification-related instructions from the upper-layer general agent. These instructions are expressed in natural language (e.g., "Execute the complete FPGA verification process for the current DUT"), and are parsed by the general agent based on the user's natural language input before being sent to the capability layer's verification process orchestrator.

[0039] Step S302: Parse the instruction; The verification process orchestrator parses the received verification instructions and extracts key parameters of the verification task, including but not limited to: DUT (Design Under Test) identification information (such as design name, top-level module name, source code path); verification objectives (such as functional verification, coverage collection, timing verification); verification constraints (such as time limits, coverage target values); and user-specified special requirements (such as specific EDA tool preferences, specific test case scope).

[0040] Step S303: Determine the business skill invocation sequence based on the verification phase; Based on the verification task parameters obtained from step 2, the verification process orchestrator matches the corresponding business Skill modules for each stage (preparation stage, planning stage, implementation stage, execution stage, and analysis stage) with the standardized FPGA verification workflow template, forming a complete call sequence.

[0041] The preparation phase corresponds to the following business skill modules: environment analyzer and DUT analyzer. The environment analyzer is used to detect the EDA toolchain (Vivado, VCS, ModelSim, etc.) in the runtime environment, verify the version compatibility and license availability of each tool, and generate an environment detection report. The DUT analyzer is used to parse Verilog / SystemVerilog source code, identify the DUT's interface type (such as AXI, APB, UART), protocol characteristics, and design complexity, and output a DUT analysis report.

[0042] The business skill modules corresponding to the planning phase are: Verification Strategy Generator and Verification Plan Generator. The Verification Plan Generator generates candidate verification strategies based on the DUT analysis results and project constraints. After rule validation or manual confirmation, the adopted verification strategy (such as dynamic simulation, formal verification, or a hybrid strategy) is determined. The Verification Plan Generator generates detailed verification plan documents, sets coverage targets, and plans test cases.

[0043] The corresponding business skill modules for the implementation phase include: a reference model generator, a test platform generator, and an execution script generator. The reference model generator generates or adapts Python / C reference models based on design specifications, interface protocols, reference algorithms, existing reference models, or confirmed behavioral constraints. These models are then validated through interface consistency testing and differential testing for subsequent simulation result comparison. The test platform generator generates test platform code and stimulus data, supporting various modes such as CSV unit testing and UVM testing. The execution script generator generates standardized compilation scripts and execution scripts (build scripts) for various EDA toolchains.

[0044] The simulation execution engine corresponding to the execution phase: Based on the compilation script and simulation script generated by the execution script generator, after command verification and permission control are passed, EDA tools (such as VCS, ModelSim) are launched to perform dynamic simulation verification on the DUT, and generate simulation logs and waveform files.

[0045] The corresponding business skill module for the analysis phase is the Result Analyzer. It is used to parse simulation logs, classify error messages, automatically compare simulation outputs with the expected results of the reference model, statistically analyze coverage data, and generate validation reports.

[0046] Step S304: Sequentially invoke business skills to perform verification actions according to the verification stage; The verification process orchestrator, following the business Skill invocation sequence determined in step S3, sequentially calls the corresponding business Skill modules in the business execution layer to perform verification actions according to the verification stage order. For each business Skill module invocation: Before calling the business Skill module, the orchestrator checks whether the preconditions are met. If not, it triggers the exception handler to handle the process-level exception. After the orchestrator is invoked, it verifies whether the postconditions of the business Skill module have been met. If they have not been met, it determines that an execution exception has occurred. The orchestrator automatically saves checkpoint files at each critical state node (such as DUT analysis completion, test platform generation completion, simulation execution completion), recording the current process status and the output data path of completed steps.

[0047] Step S305: Summarize the results and return them to the agent.

[0048] After all business skill modules have completed execution, the verification process orchestrator collects the execution results generated at each stage, including: report files generated by each business skill module (such as environmental detection reports, DUT analysis reports, verification plan documents, verification reports, etc.); log files generated by simulation execution (such as simulation logs, compilation logs); coverage data; and a summary of the execution results of all test cases. The verification process orchestrator then aggregates all the above results and returns them to the upper-level general agent, which presents them to the user in natural language, completing the closed loop of the verification process.

[0049] This application utilizes a text file-based verification process for interaction and cross-session continuation. A structured text file (JSON format) serves as the unified interaction medium between the general intelligent agent and the FPGA verification process. The verification process's state, intermediate products, and execution results are persistently stored in the workspace directory as text files, including: Process status file: records the current status node of the verification process, the list of completed steps, and the list of steps to be executed; Checkpoint file: A snapshot saved at critical state nodes (such as when DUT analysis is completed or the test platform is generated), containing the output data of the completed steps; Execution result files: Structured output generated after each business verification execution unit is executed (such as DUT analysis report, test platform code, simulation log, etc.).

[0050] In one embodiment, in a cross-session resume scenario: when an agent session terminates due to network interruption, user-initiated closure, or EDA tool malfunction, the new session can resume execution from the last interrupted position by reading the process status file and checkpoint file in the workspace, without needing to verify the process from scratch. The verification process orchestrator automatically detects whether there are incomplete process status files in the workspace when a new session is initialized; if so, it prompts the user to choose to resume or restart.

[0051] In one embodiment, in the scenario of verification status visualization and manual intervention: all verification process statuses and intermediate products are stored in human-readable text format. Users can directly view the verification progress and intermediate results, and can manually edit the status file to skip specific steps, modify verification parameters, or adjust the execution order, thereby achieving human-machine collaborative verification process control.

[0052] In one embodiment, when verifying the version management of outputs: since all intermediate outputs and final results are in text format, they can be included in version control tools such as Git for tracking and backtracking, supporting the auditing and reproduction of the verification process.

[0053] The workflow for text file interaction is as follows: User initiates verification command → Verification process orchestrator creates process status file in workspace → Business verification execution units are called step by step and the status file is updated → Each verification execution unit writes the execution result to workspace → Verification process orchestrator reads upstream results from workspace as downstream input → Checkpoint file is written at key nodes → Status file is retained when process is completed or interrupted → New session reads status file to resume transmission.

[0054] like Figure 3 As shown, the cross-session interaction process of the verification process based on text files fully describes how, when an agent's session is interrupted, a new session resumes the verification process from the breakpoint by reading a persistent text file in the workspace. The specific process is as follows: Session 1 (Original Agent Process) – Execution phase before breakpoint.

[0055] Session 1 represents the agent session process that initiates the verification process for the first time. This process executes each business Skill module in the business execution layer sequentially according to the call sequence determined by the verification process orchestrator, and persists the execution results of each stage to the workspace directory in the form of a structured text file. The specific process is as follows: Execute the environment analyzer skill. Session 1 calls the environment analyzer skill to detect the environment (EDA toolchain version, license availability, etc.). After execution, the environment detection report is written to the 01_environment / directory of the workspace in text format. The generated files include: workspace.json (workspace configuration information), tool.json (EDA tool detection results), and env_repo.md (environment details report).

[0056] Execute the DUT analyzer Skill. Session 1 calls the DUT analyzer Skill to parse the DUT source code (identify interface types, evaluate design complexity, and detect protocol characteristics). After execution, the DUT analysis report is written to the 02_dut_analysis / directory, generating the dut_introduction.md file.

[0057] The execution strategy generator Skill is invoked in Session 1. Based on the DUT analysis results, candidate verification strategies are generated. After rule validation or manual confirmation, the adopted verification strategy is determined. After execution, the strategy report is written to the 03_strategy / directory, generating strategy.md and verification_strategy.json files.

[0058] The execution strategy generator skill is invoked in Session 1 to generate a detailed verification strategy document and set coverage targets and test case plans. After execution, the strategy document is written to the 04_strategy / directory, generating the verification_plan.md and Coverage_matrix.json files.

[0059] After the above four steps are completed, Session 1 automatically saves the checkpoint information to the process status file at the key status node (Solution Generation Completed), records the current process status as "Solution Generation Completed", the list of completed steps as ["Environment Analyzer", "DUT Analyzer", "Strategy Generator", "Solution Generator"], and the list of steps to be executed as ["Reference Model Generator", "Test Platform Generator", "Script Generator", "Simulation Execution", "Result Analyzer"].

[0060] After completing the scheme generation step in Session 1 but before starting the reference model generation step, the agent session process unexpectedly terminates due to network interruption, user-initiated closure of the session window, or EDA tool malfunction. At this point, the workspace directory contains complete execution result text files for the four stages from 01_environment / to 04_strategy / , as well as process status files and checkpoint files recording the current process progress.

[0061] Session 2 (New Agent Process) - Breakpoint Recovery and Continuation of Execution.

[0062] Session 2 represents the new agent session process started after the user re-establishes the connection. This process automatically executes breakpoint detection and recovery procedures during initialization. Breakpoints are detected when a new session starts. After session 2 starts, the verification process orchestrator automatically scans the workspace directory and detects incomplete process status files (status: "Solution generation complete", list of pending steps is not empty). The orchestrator determines that there are currently resumable verification process breakpoints.

[0063] Read log / status / breakpoint information. Verify that the process orchestrator reads the process status file and checkpoint file, and extracts the following information from them: Current process status: "Solution generation completed"; Completed steps and their output data paths: 01_environment / , 02_dut_analysis / , 03_strategy / , 04_strategy / ; List of steps to be executed: ["Reference Model Generator", "Test Platform Generator", "Script Generator", "Simulation Execution", "Result Analyzer"].

[0064] Additionally, the orchestrator can read the output files of completed steps (such as DUT interface information in dut_introduction.md and strategy preferences in verification_strategy.json) as input parameters for subsequent steps to be executed.

[0065] Execution resumes from the breakpoint. Based on the breakpoint information read, the verification process orchestrator skips the first four completed steps (Environment Analyzer, DUT Analyzer, Strategy Generator, and Solution Generator) and continues execution directly from the first step in the list of pending steps—"Reference Model Generator": Call the reference model generator Skill to generate a reference model based on the DUT analysis report in 02_dut_analysis / and output it to the 05_ref_model / directory; Call the test platform generator Skill to generate test platform code based on the DUT analysis report and verification plan, and output it to the 06_testbench / directory; Call the script generator Skill (i.e., the script generator) to generate EDA tool compilation and execution scripts, and output them to the 07_scripts / directory; Call the simulation execution engine, execute the simulation script, generate simulation logs and waveform files, and output them to the 08_simulation / directory; Call the results analyzer Skill to parse the simulation logs, compare the expected results, calculate the coverage, generate a verification report, and output it to the 09_results / directory.

[0066] The workspace directory contains intermediate and final result files for the entire process, from environment initialization to result analysis. Process status, logs, reports, and structured execution results are saved in text formats such as JSON, MD, or HTML. Simulation waveforms and other native EDA artifacts are saved in the tool's native format, and their paths, summaries, and verification information are recorded in the process status file or checkpoint file. The verification process orchestrator collects and summarizes the execution results from each stage and returns them to the agent, which then presents the verification status and result summary to the user.

[0067] The core feature of this process is the use of structured files to achieve state persistence and cross-session recovery of the verification process: each verification stage has an independent working directory, and the process status, logs, reports, and structured results of each stage are stored in standardized text files; simulation waveforms and other native EDA artifacts are saved in the native format of the tool, and the path, summary, and verification information are recorded in the process status file or checkpoint file; the output files of completed steps are used by downstream steps of the current session and can also be read by subsequent new sessions to restore the context; after passing JSON Schema verification, state transition rule verification, and consistency verification of completed artifacts, users can edit the process status file to adjust the verification process, achieving controlled human-machine collaboration.

[0068] In one embodiment, the exception handler in step S4 uses the execution results and execution logs of the business execution layer Skill as a unified input data source to achieve closed-loop processing of exception classification and recovery strategy selection.

[0069] The exception handler parses the execution results and logs of the business execution layer Skill, and, in conjunction with the standardized exception codes provided by the Skill's exception reporting method, classifies exceptions into three categories: Tool-level anomalies, including EDA simulation tool startup failures, crashes, and execution timeouts, are usually caused by tool configuration errors or missing environments. Process-level anomalies include unmet prerequisites for EDA tools, missing DUT source code dependency files, and data format mismatch between upstream and downstream business skill modules; Logic-level anomalies include mismatches between FPGA simulation results and expected results from the reference model, and failure to meet verification coverage standards.

[0070] In one embodiment, the recovery strategy selection in step S4 is as follows: For categorized anomalies, the anomaly handler combines the current anomaly type with the recovery success rate records of similar anomalies in historical logs to select the preferred strategy from the candidate recovery strategies: For tool-level exceptions, perform a retry with a backoff strategy or switch to a compatibility-verified backup EDA simulation tool; For process-level anomalies, the corresponding business Skill module is invoked to locate the missing DUT dependency files, and the missing files are only completed when the dependency source is clear and passes the integrity verification; the environment analyzer or its EDA tool configuration generation submodule is used to regenerate and verify the EDA tool configuration, or the call sequence is adjusted to meet the preconditions. For logic-level exceptions, record the details of the difference between the actual simulation output and the expected output of the reference model or alternative result determiner, mark the current test case as failed and continue to execute subsequent test cases that have not been executed; when the preset termination condition is met or automatic recovery fails, terminate the current verification process and record the reason for termination.

[0071] In one embodiment, the closed-loop mechanism in step S4 is as follows: The complete context of each exception handling (exception type, triggering conditions, selected recovery strategy, and recovery execution result) is written to the log as historical reference data for subsequent exception handling. As the system accumulates experience, when the exception handler encounters similar exceptions, it combines historical success rates, current execution context, and recovery strategy constraints to rank candidate recovery strategies and prioritize the strategy ranked higher, thereby continuously optimizing exception handling capabilities.

[0072] The closed-loop process for exception handling is as follows: Execute the business Skill module → Generate execution results and logs → The exception handler classifies exceptions based on the results and logs → Select a recovery strategy based on the current process status and historical records → Execute recovery → Update the process status based on the recovery results → Write the exception context and recovery results into the historical records → Use them as the basis for strategy selection in subsequent similar exception handling.

[0073] like Figure 4 As shown, the detailed workflow of the exception handler describes the closed-loop processing from the execution of the business skill to exception capture, classification and identification, recovery strategy selection, resumption of execution, status update, and finally, process continuation or termination. The specific process is as follows: I. Business Skills Execution and Status Assessment Execution of Business Skills. The verification process orchestrator invokes a specific business skill module in the business execution layer according to the invocation sequence to execute the specific FPGA verification task. After the business skill is executed, it returns the execution result (including standardized exception codes and status information) and generates the corresponding simulation log.

[0074] Status determination. The exception handler obtains the execution results and simulation logs generated after the business Skill module has finished executing, and determines the execution status—by parsing the status code in the execution result and the error keywords in the log, it determines whether the current execution belongs to a "normal" or "abnormal" state.

[0075] II. Normal Branches Normal: The capability layer continues the process. If the status judgment result is "normal" (i.e., the execution result status code is successful and there are no fatal errors in the simulation log), the exception handler determines that the current business Skill has been executed successfully and does not trigger the exception handling logic. The verification process orchestrator continues to execute the next business Skill module according to the call sequence, and the FPGA verification process proceeds normally.

[0076] Normal: Return to the agent. After all business Skill modules have completed their execution normally, the verification process orchestrator summarizes the execution results of each stage and returns them to the upper-level general agent, which then presents the verification completion status and result summary to the user.

[0077] III. Abnormal Branches Exception: Exception capture. If the status judgment result is "Exception" (i.e., the execution result status code is non-zero, or the simulation log contains error keywords), the exception handler captures the current exception and obtains the complete context information related to the exception, including: the identifier of the business Skill module where the exception occurred, the standardized exception code, the exception description information, the error fragment in the simulation log, and the current process status node.

[0078] Anomaly classification and identification. The anomaly processor takes the captured anomaly context information as input.

[0079] Select a recovery strategy. Based on the anomaly classification results and historical success rate data of various recovery strategies for similar anomalies compiled from historical logs, the anomaly processor selects the preferred recovery strategy from the candidate recovery strategy library for execution. Retry: Applicable to tool-level exceptions. Executes retries with an exponential backoff strategy (retry intervals increase sequentially, maximum number of retries is configurable), effective when EDA tools fail due to transient failures (such as temporary license unavailability or temporary system resource shortages).

[0080] Switching Scheme: Applicable to tool-level anomalies and some process-level anomalies. When the primary EDA tool repeatedly fails, switch to a backup EDA tool (e.g., switch from VCS to ModelSim); when the current Skill fails to execute, switch to a functionally equivalent alternative Skill module. The "switching scheme" in this step corresponds to the recovery strategies described in the patent, such as "switching to a backup EDA simulation tool" and "calling the corresponding business Skill to complete missing dependencies or adjust the call sequence."

[0081] Termination Process: Applicable to severe exceptions that cannot be automatically recovered. When both retry and switching solutions fail, or when the exception is a logical-level exception that cannot be repaired by automatic strategies (such as functional defects in the design itself), the exception handler terminates the current verification process, records the termination reason and context information, returns to the agent, and reports the failure details to the user.

[0082] Perform recovery and close the loop. The exception handler executes the selected recovery strategy and writes the recovery execution result (success / failure / partial success) to the history log, forming a closed loop. Specifically: If the recovery is successful, the exception handler will write the recovery result, recovery time, and selected strategy to the historical log, and then verify that the process orchestrator continues to execute subsequent steps from the breakpoint. If the recovery process fails, the exception handler records the reason for the failure and attempts to select the next priority recovery strategy (such as retrying first and then switching strategies). If all strategies fail, the process is terminated.

[0083] This application provides an FPGA verification method and system with a two-layer Skill architecture enhanced general-purpose agent. The system reuses the existing general-purpose agent as the interaction entry point. The capability layer provides the general-purpose agent with verification process orchestration, state management, and exception handling capabilities. The business Skill modules in the business execution layer follow a unified standardized encapsulation specification, declaring functional descriptions and scope of application, input / output data formats, execution preconditions and postconditions, and exception reporting methods. The verification process orchestrator generates a business Skill module call sequence based on the process template and DUT analysis results, manages process advancement through a state machine, and persists process states and checkpoints using structured files. The exception handler classifies tool-level exceptions, process-level exceptions, and logic-level exceptions, executes corresponding recovery strategies, and updates the process state based on the recovery results, forming a closed-loop exception handling mechanism. This application enables automatic orchestration of FPGA verification processes, exception recovery, and cross-session continuation, improving verification efficiency and reliability.

[0084] It should be understood that, provided that preconditions, input-output dependencies, and state transition rules are not violated, the execution order of steps in the flowchart that are not dependent on each other can be adjusted; steps with precondition dependencies are executed according to the state machine rules. For steps containing multiple steps or stages, each step or stage can be completed at different times and can be executed alternately with other steps or stages that are not dependent on each other.

[0085] Based on the same inventive concept, this application also provides an FPGA verification system for implementing the above-described method using a two-layer Skill architecture to enhance a general-purpose intelligent agent. The solution provided by this system is similar to the implementation described in the above-described method; therefore, the specific limitations in the system embodiments provided below can be found in the limitations of the above-described method, and will not be repeated here.

[0086] In one embodiment, such as Figure 6 As shown, an FPGA verification system with a two-layer Skill architecture and enhanced general-purpose intelligent agent is provided. This system is applied to the FPGA chip simulation verification process, which includes environment initialization, DUT analysis, verification strategy generation, verification scheme generation, reference model generation, test platform generation, execution script generation, simulation execution, and result analysis. The intelligent agent layer is used to receive FPGA verification instructions from users, call the capability layer to perform task parsing, process scheduling and result interaction, and support the access and switching of multiple base large models; The business execution layer includes multiple business skill modules that conform to standardized packaging specifications, used to execute specific FPGA verification tasks. These business skill modules include an environment analyzer, a DUT analyzer, a verification strategy generator, a verification scheme generator, a reference model generator, a test platform generator, an execution script generator, a simulation executor, and a result analyzer. The standardized packaging specifications include functional descriptions and applicable scope, input and output data formats, execution preconditions and postconditions, and exception reporting methods. The capability layer, connected to both the agent layer and the business execution layer, is used to read the standardized encapsulation description of the business execution layer and provide the agent with FPGA verification process orchestration and exception handling capabilities. The dual-layer Skill architecture includes the capability layer and the business execution layer, and the agent layer is an interaction and task scheduling layer connected to the dual-layer Skill architecture. The capability layer includes a verification process orchestrator and an exception handler. The verification process orchestrator is used to decompose the verification task into a call sequence of business Skill modules according to the DUT characteristics, manage the advancement and breakpoint resumption of the FPGA verification process through a state machine, and persist the process status and checkpoints in a structured text file; the process status file records the current status, completed steps and steps to be executed, and the checkpoint file records the status snapshot, output index and verification information. The exception handler is used to classify tool-level exceptions, process-level exceptions, and logic-level exceptions based on the execution results and simulation logs generated by the business execution layer during FPGA simulation verification. It sorts candidate recovery strategies according to exception category, current process state, preconditions, and recovery strategy constraints, selects the recovery strategy that meets the execution conditions, executes the selected recovery strategy, and updates the process state based on the recovery execution result. If the recovery is successful, the interrupted process continues to execute. If the recovery fails, the next candidate recovery strategy is selected or the current verification process is terminated. The exception context and recovery result are written to the history record to form a closed-loop control process for exception handling that includes exception classification, recovery execution, state update, and result feedback. The capability layer reads the standardized encapsulation description of the business execution layer, dynamically arranges the FPGA verification process according to the DUT characteristics, and verifies the call sequence according to the preconditions, input / output formats and state transition rules. The intelligent agent layer reuses existing general intelligent agents as the interaction entry point and task scheduling subject, supporting natural language understanding, context management, code generation, and access and switching of different base large models; the dual-layer Skill architecture refers to the capability layer and the business execution layer, and the intelligent agent layer is the host interaction layer connected to the dual-layer Skill architecture.

[0087] Capability Layer: A collection of verification domain capability modules providing general-purpose agents with FPGA verification process orchestration, state management, and exception handling capabilities. The capability layer connects to the agent layer and generates business skill module call sequences through standardized encapsulation descriptions of the business execution layer. The capability layer includes a verification process orchestrator and an exception handler. The verification process orchestrator manages the verification process advancement through a state machine and supports breakpoint resumption. The exception handler performs exception classification, recovery strategy selection, and recovery result feedback based on the execution results and logs of the business execution layer.

[0088] The Business Execution Layer contains multiple business skill modules that follow a unified encapsulation specification. Each business skill module encapsulates a specific verification execution capability, such as DUT analysis, test platform generation, simulation execution, or result analysis, and is responsible for actually executing the corresponding verification tasks. The Business Execution Layer supports dynamically extending business skill modules through a registration interface.

[0089] The capability layer does not hardcode the order of calling the business execution layer. Instead, it discovers available capabilities by reading the standardized encapsulation descriptions of the business execution layer's Skills and dynamically orchestrates the call sequence based on the DUT characteristics.

[0090] The business execution layer supports the dynamic registration of new business skill modules through a registration interface. The new business skill module submits description information and execution interface that conform to the standardized encapsulation specification. The capability layer reads the description information and, when the input and output formats are compatible with the existing process and the preconditions and postconditions are verifiable, incorporates the new business skill module into the FPGA verification process orchestration scope without modifying the logic of the verification process orchestrator.

[0091] Figure 5 This is a schematic diagram of the verification process in one embodiment, such as... Figure 5 As shown, the specific process is as follows: The environment analyzer is used to detect the EDA toolchain in the operating environment, verify version compatibility, generate environment detection reports and environment scores, and generate verified EDA tool configurations based on EDA tool versions, project paths, and process parameters.

[0092] The DUT analyzer is used to parse Verilog / SystemVerilog source code, identify interfaces and protocols, evaluate design complexity, and output a DUT analysis report.

[0093] The verification strategy generator is used to generate candidate verification strategies based on the DUT analysis results and project constraints, and the verification strategy to be adopted (such as dynamic simulation, formal verification or hybrid strategy) is determined after rule verification or manual confirmation.

[0094] The validation plan generator is used to generate detailed validation plan documents, set coverage targets, and plan test cases.

[0095] The reference model generator is used to generate or adapt Python / C reference models based on design specifications, interface protocols, reference algorithms, existing reference models, or confirmed behavioral constraints. It is verified through interface consistency testing and differential testing for simulation result comparison.

[0096] Test platform generator, used to generate test platform code and stimulus data, supports test modes such as CSV unit testing and UVM testing.

[0097] An execution script generator is used to generate standardized compilation and execution scripts for various EDA toolchains.

[0098] The simulation executor receives the compiled script and execution script generated by the execution script generator. After passing command verification, permission control, and tool version compatibility verification, it calls the EDA tool to perform dynamic simulation and generate simulation logs, waveform files, and structured execution results.

[0099] The results analyzer is used to parse simulation logs and structured execution results, compare actual results with expected results in conjunction with a reference model or alternative result decision maker, calculate verification coverage, and generate a verification report.

[0100] The aforementioned business skill modules adhere to defined standardized encapsulation specifications and transmit data through a unified JSON input / output data format. The system supports reading the description information and execution interface of new business skill modules via a registration interface. When the input / output format is compatible with existing processes and the preconditions and postconditions are verifiable, the new business skill module is incorporated into the capability layer orchestration scope without requiring modification to the capability layer's orchestration logic. The intelligent agent layer includes an adapter interface module. This module receives verification task requests in a unified format, converts them into the input format of the target base model, and converts the output of the target base model into a unified response format before transmitting it to the capability layer, thereby enabling the replacement of different base models.

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

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

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

Claims

1. A dual-layer Skill architecture-enhanced general-purpose intelligent agent FPGA verification method, applied to an FPGA chip simulation verification process including environment initialization, DUT analysis, verification strategy generation, verification scheme generation, reference model generation, test platform generation, execution script generation, simulation execution, and result analysis, characterized in that, include: Each verification capability in the FPGA verification process is encapsulated into a business Skill module of the business execution layer that follows a standardized encapsulation specification. The standardized encapsulation specification includes functional description and scope of application, input and output data format, execution preconditions and execution postconditions, and exception reporting method. The standardized encapsulation descriptions of each business skill module are read through the capability layer, and the process status to be executed and the calling relationship of business skill modules are dynamically determined based on the characteristics of the DUT. The capability layer includes a verification process orchestrator and an exception handler; The verification process orchestrator receives FPGA verification instructions and parses DUT information, and calls the DUT analyzer to generate DUT analysis results. The verification process orchestrator generates a sequence of business skill module calls for the current DUT based on the DUT analysis results and the standardized encapsulation descriptions of each business skill module. The business Skill modules are called sequentially according to the calling sequence. Before each call, the preconditions are verified, and after each call, the postconditions are verified. The output of the upstream business Skill module is used as the input of the downstream business Skill module. The process state is updated through the state machine, and the progress of the FPGA verification process and the breakpoint resume are managed. Save checkpoints at preset state nodes and summarize the execution results of each business Skill module and feed them back to the general intelligent agent; The exception handler uses the execution results and simulation logs generated by the business Skill module during FPGA simulation verification as the data source to classify tool-level exceptions, process-level exceptions, and logic-level exceptions. Based on the anomaly type, current process status, preconditions, and recovery strategy constraints, select and execute candidate recovery strategies. Update the process status based on the recovery execution result. If the recovery is successful, continue the interrupted process. If the recovery fails, select the next candidate recovery strategy or terminate the current verification process, and write the exception context and recovery result to the log and history.

2. The method according to claim 1, characterized in that, In the standardized packaging specification: The functional description and scope of application include applicable DUT hardware design types and EDA toolchain information; the DUT hardware design types include processor cores, interface controllers, and memory subsystems; the EDA toolchain information includes EDA tools used for compilation, simulation, and result analysis, and their version information; The verification process orchestrator matches the business skill modules required for the current verification task based on the DUT analysis results, the functional description and applicable scope, and the preconditions. The input and output data format is defined based on JSON Schema, which is used to unify data transfer between business skill modules; The execution preconditions and postconditions include the following: the EDA tool is installed and the version is compatible; the DUT source code has been parsed or is accessible; and the reference model or alternative result judge is ready when result comparison is required. The postconditions include verifiable output states such as the environmental monitoring report has been generated and the test platform code has been output. The aforementioned exception reporting method maps internal exceptions generated by the business Skill module during FPGA verification execution into standardized exception codes and sends them to the exception handler for unified processing. The internal exceptions include EDA tool errors, hardware description language parsing failures, and simulation result mismatches.

3. The method according to claim 1, characterized in that, The verification process orchestrator includes: Template baseline: The standard process state set for FPGA verification is used as the template baseline. The state set includes environment initialization, DUT analysis, verification strategy generation, verification scheme generation, reference model generation, test platform generation, execution script generation, simulation execution, and result analysis. Dynamic adjustment: During runtime, the call sequence is dynamically adjusted based on the hardware design complexity, interface type, and protocol characteristics in the DUT analysis results; when there is a registered reference model that has passed the interface consistency check, or when there is a configured and verified alternative result determiner that is available, and the result analyzer is configured to call the corresponding decision source, the reference model generation step is marked as exempt from execution; when the protocol characteristics have been confirmed and the corresponding protocol verifier is available, the protocol compliance verification step is inserted. Resume execution from breakpoint: Save checkpoint files and update process status files at critical status nodes; the process status file records the current status, completed steps, steps to be executed, and status transition information, while the checkpoint file records status snapshots, output indexes, and verification information. Both are stored in the workspace directory in JSON format; a new session reads the process status file and the most recent checkpoint file and performs a consistency check. If the check passes, execution resumes from the next step to be executed after the most recently confirmed completed status.

4. The method according to claim 3, characterized in that, Save checkpoint files at critical status nodes and update process status files, including: When a new session is initialized, the verification process orchestrator checks whether there are incomplete process status files and the most recent checkpoint file in the workspace, reads the status and product verification information recorded in both and performs consistency verification; after the verification passes, it continues execution from the next pending step of the most recently confirmed completed status. The process status file is stored in JSON format, allowing users to directly view the verification progress. After passing JSON Schema verification, state transition rule verification, and completed product consistency verification, users can edit the process status file to adjust the verification process. Process status, checkpoint metadata, logs, reports, and structured execution results are saved in JSON, Markdown, or HTML text formats; simulation waveforms and other native EDA artifacts are saved in the tool's native format, and their paths, summaries, and verification information are recorded in the process status file or checkpoint file.

5. The method according to claim 1, characterized in that, The exception classification of the exception handler includes: Tool-level exceptions include EDA simulation tools failing to start, crashing, and timing out. Process-level anomalies include unmet prerequisites for EDA tools, missing dependency files in the DUT source code, and data format mismatch between upstream and downstream business Skill modules; Logical anomalies include mismatches between simulation results and expected results output by the reference model or alternative result determiner, and actual verification coverage falling below the preset coverage target in the verification scheme.

6. The method according to claim 5, characterized in that, The exception handler sorts the candidate recovery strategies according to the exception type, current process status, applicable conditions of the recovery strategy, and historical execution results, and selects the priority strategy from the candidate recovery strategies that meet the execution conditions. The recovery strategy selection includes: For tool-level exceptions, perform a retry with a backoff strategy or switch to a compatibility-verified backup EDA simulation tool; For process-level anomalies, the corresponding business Skill module is invoked to locate the missing DUT dependency files, and the missing files are only completed when the dependency source is clear and passes the integrity verification; the environment analyzer or its EDA tool configuration generation submodule is used to regenerate and verify the EDA tool configuration, or the call sequence is adjusted to meet the preconditions. For logic-level exceptions, record the details of the difference between the actual simulation output and the expected result output of the reference model or alternative result determiner, mark the current test case as failed and continue to execute subsequent test cases that have not been executed; when the preset termination condition is met or automatic recovery fails, terminate the current verification process and record the reason for termination.

7. An FPGA verification system for enhanced general-purpose intelligent agents using a dual-layer Skill architecture, employing the method described in any one of claims 1 to 6, applied to an FPGA chip simulation verification process including environment initialization, DUT analysis, verification strategy generation, verification scheme generation, reference model generation, test platform generation, execution script generation, simulation execution, and result analysis, characterized in that, include: The intelligent agent layer is used to receive FPGA verification instructions from users, call the capability layer to perform task parsing, process scheduling and result interaction, and support the access and switching of multiple base large models; The business execution layer includes multiple business Skill modules that follow standardized packaging specifications, used to execute specific FPGA verification tasks; The business Skill module includes an environment analyzer, a DUT analyzer, a verification strategy generator, a verification scheme generator, a reference model generator, a test platform generator, an execution script generator, a simulation executor, and a result analyzer; the standardized encapsulation specification includes functional descriptions and applicable scope, input and output data formats, execution preconditions and postconditions, and exception reporting methods. The capability layer, which connects to the agent layer and the business execution layer respectively, is used to read the standardized encapsulation description of the business execution layer and provide the agent with the ability to orchestrate the FPGA verification process and handle exceptions. The two-layer Skill architecture includes a capability layer and a business execution layer. The intelligent agent layer is an interaction and task scheduling layer connected to the two-layer Skill architecture. The capability layer includes a verification process orchestrator and an exception handler. The verification process orchestrator is used to decompose the verification task into a call sequence of business Skill modules according to the DUT characteristics, manage the advancement and breakpoint resumption of the FPGA verification process through a state machine, and persist the process status and checkpoints in a structured text file; the process status file records the current status, completed steps and steps to be executed, and the checkpoint file records the status snapshot, output index and verification information. The exception handler is used to classify tool-level exceptions, process-level exceptions, and logic-level exceptions based on the execution results and simulation logs generated by the business execution layer during FPGA simulation verification. It sorts candidate recovery strategies according to exception category, current process state, preconditions, and recovery strategy constraints, selects the recovery strategy that meets the execution conditions, executes the selected recovery strategy, and updates the process state based on the recovery execution result. If the recovery is successful, the interrupted process continues to execute. If the recovery fails, the next candidate recovery strategy is selected or the current verification process is terminated. The exception context and recovery result are written to the history record to form a closed-loop control process for exception handling that includes exception classification, recovery execution, state update, and result feedback.

8. The FPGA verification system for enhanced general-purpose intelligent agents with a two-layer Skill architecture according to claim 7, characterized in that, The business execution layer supports the dynamic registration of new business skill modules through a registration interface. The new business skill module submits description information and execution interface that conform to the standardized encapsulation specification. The capability layer reads the description information and, when the input / output format is compatible with the existing process and the preconditions and postconditions are verifiable, incorporates the new business skill module into the FPGA verification process orchestration scope without modifying the logic of the verification process orchestrator.

9. The FPGA verification system for enhanced general-purpose intelligent agents with a two-layer Skill architecture according to claim 7, characterized in that, The intelligent agent layer includes an adapter interface module, which receives a unified format verification task request, converts it into the input format of the target base model, and converts the output of the target base model into a unified response format before transmitting it to the capability layer to realize the replacement of different base models.

Images