Gateway-controlled heterogeneous EDA tool unified execution method and system

Abstract

The application discloses a gateway-controlled heterogeneous EDA tool unified execution method and system, which sets a unified execution gateway and an access layer between an upper calling party and heterogeneous EDA tools, the access layer supports a model context protocol service interface for a large language model intelligent agent and a software development kit interface for a programmed client. The access layer encapsulates a tool calling request into a structured request message, the unified execution gateway completes protocol verification, parameter verification, return mode verification, capability level authorization and capability discovery, and distributes the verified request to a corresponding tool adaptation module. When a task identifier or a skill identifier is carried in the request, the task decomposition, input constraint, calling sequence and session context maintenance rule are read from a skill and capability description module. The application can simultaneously support stable access of an intelligent agent front end and a programmed front end, reduce the integration complexity of heterogeneous EDA tools and reduce the overhead caused by repeated loading of a design environment.

Description

Technical Field

[0001] This invention relates to the field of electronic design automation technology, specifically to a unified execution method and system for heterogeneous EDA tools controlled by a gateway. Background Technology

[0002] In the integrated circuit design process, it is usually necessary to use multiple EDA tools, such as logic synthesis, placement and routing, static timing analysis, simulation, and approval. Since different tools are provided by different vendors or frameworks, their underlying command systems, script interfaces, data organization methods, and operating modes are not unified. When integrating these tools, upper-level automation programs often need to write adaptation scripts and maintain the operating environment separately.

[0003] Current common solutions are direct script connection or single-request invocation. While these solutions can accomplish simple batch processing tasks, in actual EDA work, many tasks require a continuous process of "loading design—generating report—analyzing bottlenecks—performing fixes—re-analyzing—comparing results—rollback if necessary" within the same design context. If each step is completed through independent scripts or temporary processes, the design state, runtime context, and intermediate results are difficult to retain across requests, resulting in high overhead from repeated loading and making it difficult to support continuous optimization.

[0004] In recent years, large language models and intelligent agent technology have been gradually used for EDA automation. However, because the aforementioned tools are provided by different vendors or frameworks, the underlying program interfaces are not unified. In the absence of unified semantics and unified specifications, large language models cannot effectively utilize a variety of different heterogeneous tools.

[0005] On the other hand, if the underlying tool environment is directly exposed to the upper-layer program or agent, it is difficult to limit the upper layer to calling only the expected capabilities, which can easily lead to problems such as unauthorized calls, erroneous calls, and abnormal commands that damage the runtime environment. For large language model agents, if all underlying capabilities and their detailed descriptions are disclosed at once, it will also result in an excessively large space of optional capabilities, increased context consumption, and instability in the calling process.

[0006] Furthermore, even if the raw capability interfaces are exposed using a unified protocol, they are insufficient to directly support complex EDA tasks. In scenarios such as time-series convergence, sub-library selection, and continuous verification, simply providing the underlying interface definitions cannot answer questions like "which capabilities should be called first, in what order, how input parameters should be constrained, and which steps need to be maintained within the same instance context." Therefore, a skill and capability specification mechanism separate from the protocol call layer is needed to express task decomposition, input constraints, session persistence requirements, and call order knowledge in a machine-readable manner. Consequently, a unified execution infrastructure is required between the upper-layer caller and the underlying heterogeneous EDA tools, enabling the underlying tool capabilities to be invoked in a structured, controlled, and discoverable manner, maintaining a continuous session and running state for backend tool instances across multiple requests, while being compatible with large language model intelligent agent frontends, model context protocol frontends, and software development kit frontends, and supporting a skill and capability specification layer separate from the protocol layer. Summary of the Invention

[0007] The purpose of this invention is to provide a unified execution method and system for heterogeneous EDA tools controlled by a gateway, so as to solve the problems mentioned in the background art.

[0008] To achieve the above objectives, the present invention provides the following technical solution: A unified execution method for heterogeneous EDA tools controlled by a gateway includes the following steps: S1, the access layer receives tool invocation requests initiated by upper-layer callers, wherein the upper-layer callers include at least one of a large language model intelligent agent client and a programmatic client, and the access layer includes at least one of a model context protocol service interface and a software development kit interface; and encapsulates the tool invocation request into a structured request message, wherein the structured request message includes at least a request identifier, a tool type identifier, a target capability identifier, a parameter set, and a return mode field; when it is necessary to reuse an existing backend instance, the structured request message also includes an instance identifier; S2. When the structured request message contains a task identifier and a skill identifier, read the skill description corresponding to the target task from the skill and ability description module, and determine at least one of the following based on the skill description: candidate ability set, input constraints, call order constraints, and session context preservation requirements. S3, the unified execution gateway performs protocol parsing on the structured request message and searches for the registered capability interface corresponding to the target capability identifier based on the pre-registered capability registry. The capability registry records the mapping relationship between the registered capability interface and the corresponding tool adaptation module. S4. Determine the target backend instance based on the instance identifier, tool type identifier, and instance identifier; if no reusable target backend instance exists, start the EDA tool process corresponding to the tool type identifier, create a new backend instance, and bind the new backend instance to the newly allocated instance identifier. S5, the unified execution gateway performs parameter validity verification and capability call permission verification on the structured request message, and after the verification is passed, distributes the structured request message to the tool adaptation module corresponding to the target capability identifier; S6, the tool adaptation module converts the native commands, script processes and analysis operations of the target EDA tool into standardized capability calls and executes them on the target backend instance, so that multiple requests using the same instance identifier can reuse the same loaded design state, running context and intermediate results; S7, normalize and encapsulate the execution result and return it to the upper-level caller. The execution result includes at least one of structured data result, text result, original reference and execution status. S8. When the tool call request corresponds to a long-running task, the unified execution gateway returns a task handle to the upper-layer caller and provides task status query, result waiting and result extraction based on the task handle. S9, Perform operation management on the target backend instance, the operation management includes at least keep-alive detection, timeout control, anomaly cleanup and release / reclaim.

[0009] Furthermore, the structured request message also includes a timeout field; In the structured request message, the request identifier is used for tracking, response matching, and error location of a single call; the tool type identifier is used to identify the EDA tool category corresponding to the tool call request, so as to determine the corresponding tool adaptation module and target backend instance; the target capability identifier is used to uniquely identify the capability interface to be called registered in the capability registry; the parameter set is used to carry the input parameters and their values ​​required to call the capability interface to be called; the instance identifier is used for routing and lifecycle management of continuously running backend instances; the return mode field is used to indicate that the execution result is returned in a way that includes structured data, text results, raw results, artifact references, or any one of structured data and raw results; and the timeout field is used to indicate the time limit for a single call and result waiting, so that the unified execution gateway can perform timeout control.

[0010] Furthermore, the capability registry records at least one piece of metadata for each registered capability interface. The metadata includes input parameter constraints, output result type, allowed return mode, calling permissions, dependencies, and calling descriptions. The unified execution gateway only allows calls to capability interfaces registered in the capability registry, thereby blocking unregistered direct script execution and command execution.

[0011] Furthermore, the unified execution gateway adopts a progressive capability exposure mechanism, first exposing connectivity detection interfaces, capability list interfaces, and capability description interfaces to the upper-layer callers. After receiving a query or call request for a target capability interface, it then returns the parameter requirements, input / output formats, dependencies, and execution constraints of that target capability interface.

[0012] Furthermore, when the tool call request corresponds to a long-running task, the task handle is associated with at least a task identifier, an instance identifier, and a task status; the upper-level caller obtains the progress information, stage status, or final result of the long-running task through a result query request.

[0013] Furthermore, the operation management includes: performing readiness detection and heartbeat detection on the target backend instance to achieve the keep-alive detection; updating keep-alive information when the target backend tool instance is active or reused; terminating the long-running task or reclaiming the corresponding target backend tool instance when a timeout is detected to achieve the timeout control; performing exception cleanup when an abnormal fault is detected; performing release and reclamation when explicit release is detected, and reclaiming the process resources and communication resources occupied by the target backend instance; saving the design state snapshot and stage artifacts of the target backend instance, and restoring the target backend instance to the design state corresponding to the previously saved design state snapshot when the execution result of the current branch in the continuous optimization or continuous repair task does not reach the preset target.

[0014] This invention also provides a gateway-controlled unified execution system for heterogeneous EDA tools, used to implement the unified execution method for heterogeneous EDA tools as described above, including: The access layer is used to receive tool invocation requests from clients; The communication layer is used to transmit the tool invocation request and its response result in accordance with a unified message format; A unified execution gateway is used to parse the execution protocol of the tool call request, look up the capability registry, verify parameters, verify permissions, distribute requests, and normalize and encapsulate the results. The tool adaptation module is used to encapsulate the native commands, script processes and analysis operations of different EDA tools into registered capability interfaces, and execute standardized capability calls corresponding to the target capability identifier on the target backend instance; The runtime management layer is used for starting, binding, reusing, keeping alive, monitoring, and recycling backend instances; The unified execution gateway and the operation management layer work together to determine the target backend instance based on the instance identifier and the tool type identifier. The tool adaptation module then executes a standardized capability call corresponding to the target capability identifier on the target backend instance, so that multiple requests corresponding to the same instance identifier can reuse the same loaded design state and runtime context.

[0015] Furthermore, the unified execution gateway includes a capability discovery unit and a method description unit. The capability discovery unit is used to provide the upper-layer caller with a connectivity detection interface and a capability list interface. The method description unit is used to return the parameter requirements, input / output formats, dependencies, and execution constraints of the target capability interface. The unified execution gateway only allows calls to explicitly registered capability interfaces.

[0016] Furthermore, the operation management layer includes a process hosting unit, an instance binding unit, a readiness detection unit, a heartbeat monitoring unit, an asynchronous task unit, and a cleanup and recycling unit. The process hosting unit is used to start and host the EDA tool process. The instance binding unit is used to establish the binding relationship between the backend instance and the instance identifier. The readiness detection unit is used to detect whether the backend instance is in an executable state. The heartbeat monitoring unit is used to perform keep-alive detection. The asynchronous task unit is used to handle long-running tasks. The cleanup and recycling unit is used to reclaim instance resources when explicitly released, timed out, or exited due to a fault.

[0017] Furthermore, the tool adaptation module includes at least one of the following: a static timing analysis tool adaptation module, a logic synthesis tool adaptation module, a simulation tool adaptation module, and a place-and-route tool adaptation module. The static timing analysis tool adaptation module encapsulates timing analysis and reporting capabilities; the logic synthesis tool adaptation module encapsulates synthesis and netlist export capabilities; the simulation tool adaptation module encapsulates compilation, running, and debugging capabilities; and the place-and-route tool adaptation module encapsulates placement, routing, and physical implementation process capabilities. The access layer includes at least one of a software development kit (SDK) interface, a command-line interface, and a proxy-oriented protocol service interface. The SSD interface is used for programmatic clients to construct requests and decode responses; the command-line interface is used for interactive calls or interactive debugging; and the proxy-oriented protocol service interface is used for large language model agents to initiate tool calls.

[0018] Compared with the prior art, the beneficial effects of the present invention are: 1) By using a unified execution gateway to manage the unified access, controlled verification, and explicit registration of heterogeneous EDA tools, the integration complexity of the upper-layer system can be reduced, and the operational risks caused by arbitrary script pass-through can be reduced.

[0019] 2) Using a unified execution gateway as the control center, a clear call boundary is established through capability registry, parameter verification, and permission verification to reduce the execution risk caused by arbitrary script pass-through.

[0020] 3) By supporting both the model context protocol service interface and the software development kit interface at the access layer, the front end of the large language model intelligent agent and the programmatic front end can share the same set of underlying call semantics, error model and instance governance logic, avoiding redundant encapsulation.

[0021] 4) By persisting backend instances, loaded design states, runtime contexts, and intermediate results can be reused across requests, making it more suitable for EDA tasks such as multi-step analysis, continuous repair, and continuous optimization.

[0022] 5) By using the skills and capabilities description module, task breakdown, parameter constraints, call order and session persistence rules are separated from the protocol layer in a machine-readable manner, which can provide more stable task-level call guidance for agents or programmatic clients without directly exposing any underlying script capabilities.

[0023] 6) By separating the request identifier and the instance identifier, both request-level tracing and instance-level session continuity are achieved, which facilitates runtime observation, error localization and instance governance.

[0024] 7) By using a tool adaptation module to shield the differences in native commands of different EDA tools, the complexity of adapting heterogeneous tools to upper-layer programs is reduced.

[0025] 8) Improve the stability and engineering feasibility of multi-tool, multi-round EDA task execution through progressive capability exposure, asynchronous processing of long tasks, keep-alive, timeout and recycling mechanisms. Attached Figure Description

[0026] Figure 1 This invention provides a flowchart of a unified execution method for heterogeneous EDA tools controlled by a gateway.

[0027] Figure 2 : Schematic diagram of optional application scenarios of the present invention (shown in hierarchical order).

[0028] Figure 3 : Schematic diagram of optional application scenarios of the present invention (shown by module).

[0029] Figure 4 : Request execution flowchart, used to illustrate the process of structured request access, gateway verification, instance determination, adaptation execution and result return.

[0030] Figure 5 A diagram illustrating the lifecycle of a backend instance, showing the state transitions of instance creation, binding, ready, busy, release, and cleanup.

[0031] Figure 6 : A diagram illustrating the progressive capability exposure process, used to show the on-demand disclosure relationship between the capability discovery interface and the specific capability description interface.

[0032] Figure 7 : Continuously optimize application diagrams to illustrate typical application methods. Detailed Implementation

[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] Please see Figure 1 A unified execution method for heterogeneous EDA tools controlled by a gateway includes the following steps: S1, the access layer receives tool invocation requests initiated by upper-layer callers, the upper-layer callers including at least one of large language model intelligent agent clients and programmatic clients, and the access layer including at least one of model context protocol service interfaces and software development kit interfaces; and encapsulates the tool invocation request into a structured request message, the structured request message including at least a request identifier, tool type identifier, target capability identifier, parameter set, return mode field, and timeout field; when it is necessary to reuse an existing backend instance, the structured request message also includes an instance identifier.

[0035] In the structured request message, the request identifier is used for tracking, response matching, and error location of a single call; the tool type identifier is used to identify the EDA tool category corresponding to the tool call request, so as to determine the corresponding tool adaptation module and target backend instance; the target capability identifier is used to uniquely identify the capability interface to be called registered in the capability registry; the parameter set is used to carry the input parameters and their values ​​required to call the capability interface to be called; the instance identifier is used for routing and lifecycle management of continuously running backend instances; the return mode field is used to indicate that the execution result is returned in a way that includes structured data, text results, raw results, artifact references, or any one of structured data and raw results; and the timeout field is used to indicate the time limit for a single call and result waiting, so that the unified execution gateway can perform timeout control.

[0036] Furthermore, the capability registry records at least one piece of metadata for each registered capability interface. The metadata includes input parameter constraints, output result type, allowed return mode, calling permissions, dependencies, and calling descriptions. The unified execution gateway only allows calls to capability interfaces registered in the capability registry, thereby blocking unregistered direct script execution and command execution.

[0037] S2. When the structured request message contains a task identifier and a skill identifier, read the skill description corresponding to the target task from the skill and capability description module, and determine at least one of the following based on the skill description: candidate capability set, input constraints, call order constraints, and session context preservation requirements.

[0038] S3, the unified execution gateway performs protocol parsing on the structured request message and searches for the registered capability interface corresponding to the target capability identifier based on the pre-registered capability registry. The capability registry records the mapping relationship between the registered capability interfaces and the corresponding tool adaptation modules. The unified execution gateway adopts a progressive capability exposure mechanism, first exposing connectivity detection interfaces, capability list interfaces, and capability description interfaces to the upper-layer caller. Upon receiving a query or call request for the target capability interface, it then returns the parameter requirements, input / output formats, dependencies, and execution constraints of the target capability interface from the capability registry.

[0039] S4. Determine the target backend instance based on the instance identifier, tool type identifier, and instance identifier. If there is no reusable target backend instance, start the EDA tool process corresponding to the tool type identifier, create a new backend instance, and bind the new backend instance to the newly allocated instance identifier.

[0040] S5, the unified execution gateway performs parameter validity verification and capability call permission verification on the structured request message, and after the verification is passed, distributes the structured request message to the tool adaptation module corresponding to the target capability identifier.

[0041] S6, the tool adaptation module converts the native commands, script processes and analysis operations of the target EDA tool into standardized capability calls and executes them on the target backend instance, so that multiple requests using the same instance identifier can reuse the same loaded design state, runtime context and intermediate results.

[0042] S7. Normalize and encapsulate the execution result and return it to the upper-level caller. The execution result includes at least one of structured data result, text result, original reference and execution status.

[0043] S8. When the tool call request corresponds to a long-running task, the unified execution gateway returns a task handle to the upper-layer caller. The task handle is associated with at least a task identifier, an instance identifier, and a task status. Based on the task handle, task status query, result waiting, and result extraction are provided. The upper-layer caller obtains the progress information, stage status, or final result of the long-running task through a result query request.

[0044] S9, Perform operation management on the target backend instance, the operation management includes at least keep-alive detection, timeout control, anomaly cleanup and release / reclaim.

[0045] The operation management includes: performing readiness detection and heartbeat detection on the target backend instance to achieve the keep-alive detection; updating keep-alive information when the target backend tool instance is active or reused; terminating the long-running task or reclaiming the corresponding target backend tool instance when a timeout is detected to achieve the timeout control; performing exception cleanup when an abnormal fault is detected; performing release and reclamation when explicit release is detected, and reclaiming the process resources and communication resources occupied by the target backend instance; saving the design state snapshot and stage artifacts of the target backend instance, and restoring the target backend instance to the design state corresponding to the previously saved design state snapshot when the execution result of the current branch in the continuous optimization or continuous repair task does not reach the preset target.

[0046] Please see Figure 2 The present invention also provides a gateway-controlled unified execution system for heterogeneous EDA tools, used to implement the unified execution method for heterogeneous EDA tools as described above, including: The access layer is used to receive tool invocation requests from clients; The communication layer is used to transmit the tool invocation request and its response result in accordance with a unified message format; A unified execution gateway is used to parse the execution protocol of the tool call request, look up the capability registry, verify parameters, verify permissions, distribute requests, and normalize and encapsulate the results. The tool adaptation module is used to encapsulate the native commands, script processes and analysis operations of different EDA tools into registered capability interfaces, and execute standardized capability calls corresponding to the target capability identifier on the target backend instance; The runtime management layer is used to start, bind, reuse, keep alive, monitor, and reclaim backend instances.

[0047] The unified execution gateway and the operation management layer work together to determine the target backend instance based on the instance identifier and the tool type identifier. The tool adaptation module then executes a standardized capability call corresponding to the target capability identifier on the target backend instance, so that multiple requests corresponding to the same instance identifier can reuse the same loaded design state and runtime context.

[0048] Furthermore, the unified execution gateway includes a capability discovery unit and a method description unit. The capability discovery unit is used to provide the upper-layer caller with a connectivity detection interface and a capability list interface. The method description unit is used to return the parameter requirements, input / output formats, dependencies, and execution constraints of the target capability interface. The unified execution gateway only allows calls to explicitly registered capability interfaces.

[0049] Furthermore, the operation management layer includes a process hosting unit, an instance binding unit, a readiness detection unit, a heartbeat monitoring unit, an asynchronous task unit, and a cleanup and recycling unit. The process hosting unit is used to start and host the EDA tool process. The instance binding unit is used to establish the binding relationship between the backend instance and the instance identifier. The readiness detection unit is used to detect whether the backend instance is in an executable state. The heartbeat monitoring unit is used to perform keep-alive detection. The asynchronous task unit is used to handle long-running tasks. The cleanup and recycling unit is used to reclaim instance resources when explicitly released, timed out, or exited due to a fault.

[0050] Furthermore, the tool adaptation module includes at least one of the following: a static timing analysis tool adaptation module, a logic synthesis tool adaptation module, a simulation tool adaptation module, and a place-and-route tool adaptation module. The static timing analysis tool adaptation module encapsulates timing analysis and reporting capabilities; the logic synthesis tool adaptation module encapsulates synthesis and netlist export capabilities; the simulation tool adaptation module encapsulates compilation, running, and debugging capabilities; and the place-and-route tool adaptation module encapsulates placement, routing, and physical implementation process capabilities. The access layer includes at least one of a software development kit (SDK) interface, a command-line interface, and a proxy-oriented protocol service interface. The SSD interface is used for programmatic clients to construct requests and decode responses; the command-line interface is used for interactive calls or interactive debugging; and the proxy-oriented protocol service interface is used for large language model agents to initiate tool calls.

[0051] Specifically, the access layer corresponds to method step S1, which is used to receive tool call requests initiated by upper-layer callers and complete structured request message encapsulation. The unified execution gateway corresponds to method steps S3, S5, S7, and S8. Among them, the capability discovery unit and method description unit mainly correspond to method step S3, which is used to provide capability discovery and capability description. The unified execution gateway is also used to complete parameter validity verification, permission verification, request distribution, result normalization encapsulation, and task handle return and result query in long-running task scenarios. The process hosting unit, instance binding unit, and ready detection unit in the operation management layer correspond to method step S4, which is used to determine, start, bind, and detect target backend instances. The heartbeat monitoring unit and cleanup and recycling unit correspond to method step S9, which is used to perform keep-alive detection, timeout control, exception cleanup, and release and recycling. The asynchronous task unit cooperates with the unified execution gateway and corresponds to method step S8, which is used to handle long-running tasks. The tool adaptation module and its various tool adaptation sub-modules, corresponding to method step S6, are used to encapsulate and convert the native commands, script processes, and analysis operations of different EDA tools into standardized capability calls, which are then executed on the target backend instance. The communication layer, spanning method steps S1 to S8, is used to transmit request, response, and result query information according to a unified message format. Each layer, module, and unit in this application can be implemented by hardware circuits, computer programs executed by a processor, or a combination of both.

[0052] Implementation Method 1: Overall Architecture like Figure 2 and Figure 3 As shown, where Figure 2 It demonstrates an architecture hierarchically based on capabilities. Figure 3 The modular architecture is illustrated based on functional differentiation. In this embodiment, the unified execution system includes at least an access layer, a communication layer, a gateway layer, a tool adaptation layer, and a runtime management layer. The access layer receives requests from script programs, command-line programs, software development kit interfaces, or proxy-oriented protocol service interfaces; the communication layer transmits requests and responses in a unified message format; the gateway layer is responsible for protocol parsing, capability registry lookup, parameter validation, permission validation, request distribution, and result normalization; the tool adaptation layer is responsible for encapsulating the native commands, script processes, or analysis operations of different EDA tools into registered capability interfaces; and the runtime management layer is responsible for instance startup, instance reuse, instance routing, keep-alive, exception cleanup, and recycling.

[0053] In the architecture, the access layer includes at least one of the following: a Model Context Protocol (MGP) service interface and a Software Development Kit (SDK) interface. The MGP service interface is geared towards large language model agents, transforming the agent's tool call intents into structured request messages; the SSD interface is geared towards programmatic clients, used to construct requests, decode responses, and manage sessions.

[0054] In this architecture, the gateway layer is the central control hub. Upper-layer clients do not directly invoke commands from the underlying EDA tools; instead, they access the capability interfaces registered in the capability registry through the target capability identifier. The tool adaptation layer can correspond to static timing analysis tools, logic synthesis tools, simulation tools, place-and-route tools, or other approval tools, thereby providing a consistent entry point to the upper layers under a unified messaging protocol.

[0055] Implementation Method Two: Skills and Abilities Description Layer In this embodiment, the skill and capability description layer stores machine-readable skill descriptions for prompting and constraining the large language model agent. Each skill description may include at least one of the following: task identifier, candidate capability set, parameter binding rules, invocation order constraints, session context preservation rules, result verification rules, and operation template. When the access layer large language model agent receives a task-level request, it first searches for a match in the skill and capability description layer based on the task identifier.

[0056] In this implementation, the skill and capability description layer does not directly execute arbitrary low-level tool commands, nor does it bypass the unified execution gateway. In other words, the skill and capability description layer is responsible for expressing "what to do, how to do it sequentially, and how parameters are constrained," while the unified execution gateway is still responsible for verifying "which capabilities are allowed to be exposed, whether the request is valid, and which capability interface the request should be distributed to." Through this separation of responsibilities, task-level process knowledge can be introduced into the agent and programmatic call chain without weakening execution boundary control.

[0057] Implementation Method 3: Unified Execution Procedure like Figure 4 As shown. First, the client sends a structured request. The structured request includes at least a request identifier, a target capability identifier, a parameter set, and a tool type identifier; when an existing session needs to be reused, the structured request also includes an instance identifier. Optionally, the structured request also includes a return mode field and a timeout field, used to specify the result return format and the call time limit.

[0058] Then, the unified execution gateway performs protocol parsing on the structured request and searches the capability registry for the registered capability interface corresponding to the target capability identifier. The capability registry records input parameter constraints, output result type, allowed return modes, calling permissions, dependencies, and calling descriptions for each capability interface. If the target capability identifier is not registered in the capability registry, the unified execution gateway directly rejects the request.

[0059] Subsequently, the gateway layer and the operation management layer collaborate to determine the target backend instance. If the request contains an instance identifier and the corresponding instance is in a reusable state, the request is routed to that instance; if no reusable instance exists, the EDA tool process corresponding to the tool type identifier is started, a new backend instance is created, and the newly allocated instance identifier is bound to that backend instance.

[0060] After the instance is determined, the unified execution gateway performs validity checks on the request execution parameters and capability call permissions. Once the checks pass, the request is distributed to the corresponding tool adaptation module. The tool adaptation module converts the native commands, script processes, and analysis operations of the underlying tools into standardized capability calls and executes them on the target backend instance to preserve the loaded design state, runtime context, and intermediate results within the same instance.

[0061] After execution, the gateway layer normalizes and encapsulates the results. The normalized results can be returned to the client in the form of structured data, text results, raw results, artifact references, or a combination thereof, depending on the return mode field.

[0062] Implementation Method 4: Gradual Capability Exposure and Operational Governance like Figure 5 As shown. In one implementation, to avoid increasing the complexity of calls due to exposing all underlying tool capabilities at once, the unified execution gateway adopts a progressive capability exposure mechanism. Initially, the system only exposes the connectivity detection interface, capability list interface, and capability description interface; when the client confirms that it needs to call a specific capability interface, it further obtains the parameter requirements, input and output formats, dependencies, and execution constraints of that capability interface.

[0063] In one implementation, the request identifier and instance identifier are designed separately. The request identifier is used for tracing, response matching, and error localization of a single call, while the instance identifier is used for routing and lifecycle management of continuously running backend instances. Thus, the same backend instance can be called multiple times without losing its design context, while independent tracing is still possible between different calls.

[0064] Operation and governance, such as Figure 5 As shown. In one embodiment, the operation management layer includes a process hosting unit, an instance binding unit, a readiness detection unit, a heartbeat monitoring unit, an asynchronous task unit, and a cleanup and recycling unit. For long-running tasks, the unified execution gateway can first return a task handle, which is associated with at least a task identifier, an instance identifier, and a task status. The client subsequently obtains progress information, stage status, or final result through a result query request. The operation management layer updates keep-alive information when the instance is active or reused, and reclaims corresponding resources when explicit release, timeout, or failure exit is detected.

[0065] In one implementation, the system also supports saving design state snapshots or stage artifacts for the target backend instance. When the performance of a branch in continuous optimization or continuous repair is worse than the preset target, the backend instance can be restored to an earlier design state and other branch requests can continue to be executed.

[0066] Implementation Method 5: Application Scenario Description The focus of this invention is on the unified execution framework itself, rather than being limited to a specific EDA task. Based on the aforementioned unified execution gateway, tool adaptation, and operation management mechanism, this invention can be used for continuous analysis-execution-review tasks, as well as multi-round search and optimization tasks involving cross-tool collaboration. For example, in some implementations, the caller can continuously execute report queries, bottleneck analysis, repair operations, and result reviews within the same design context; in other implementations, the caller can switch between multiple managed tool instances to continuously execute design import, constraint processing, synthesis, analysis, simulation, workpiece extraction, or approval-related operations. The above application scenarios are only used to illustrate the universal execution capabilities of the framework of this invention and do not constitute a limitation on the scope of application of this invention.

[0067] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A unified execution method for heterogeneous EDA tools controlled by a gateway, characterized in that, Includes the following steps: S1, receiving a tool invocation request initiated by an upper-layer caller through the access layer, wherein the upper-layer caller includes at least one of a large language model intelligent agent client and a programmatic client, and the access layer includes at least one of a model context protocol service interface and a software development kit interface; and encapsulating the tool invocation request into a structured request message, wherein the structured request message includes at least a request identifier, a tool type identifier, a target capability identifier, a parameter set, and a return mode field; When it is necessary to reuse an existing backend instance, the structured request message also includes an instance identifier; S2. When the structured request message contains a task identifier and a skill identifier, read the skill description corresponding to the target task from the skill and ability description module, and determine at least one of the following based on the skill description: candidate ability set, input constraints, call order constraints, and session context preservation requirements. S3, the unified execution gateway performs protocol parsing on the structured request message and searches for the registered capability interface corresponding to the target capability identifier according to the pre-registered capability registry. The capability registry records the mapping relationship between the registered capability interface and the corresponding tool adaptation module. S4. Determine the target backend instance based on the instance identifier, tool type identifier, and instance identifier; if no reusable target backend instance exists, start the EDA tool process corresponding to the tool type identifier, create a new backend instance, and bind the new backend instance to the newly allocated instance identifier. S5, the unified execution gateway performs parameter validity verification and capability call permission verification on the structured request message, and after the verification is passed, distributes the structured request message to the tool adaptation module corresponding to the target capability identifier; S6, the tool adaptation module converts the native commands, script processes and analysis operations of the target EDA tool into standardized capability calls and executes them on the target backend instance, so that multiple requests using the same instance identifier can reuse the same loaded design state, running context and intermediate results; S7, normalize and encapsulate the execution result and return it to the upper-level caller. The execution result includes at least one of structured data result, text result, original reference and execution status. S8. When the tool call request corresponds to a long-running task, the unified execution gateway returns a task handle to the upper-layer caller and provides task status query, result waiting and result extraction based on the task handle. S9, Perform operation management on the target backend instance, the operation management includes at least keep-alive detection, timeout control, anomaly cleanup and release / reclaim.

2. The unified execution method for heterogeneous EDA tools controlled by a gateway according to claim 1, characterized in that, The structured request message also includes a timeout field; In the structured request message, the request identifier is used for tracking, response matching, and error location of a single call; the tool type identifier is used to identify the EDA tool category corresponding to the tool call request, so as to determine the corresponding tool adaptation module and target backend instance; the target capability identifier is used to uniquely identify the capability interface to be called registered in the capability registry; the parameter set is used to carry the input parameters and their values ​​required to call the capability interface to be called; the instance identifier is used for routing and lifecycle management of continuously running backend instances; the return mode field is used to indicate that the execution result is returned in a way that includes structured data, text results, raw results, artifact references, or any one of structured data and raw results; and the timeout field is used to indicate the time limit for a single call and result waiting, so that the unified execution gateway can perform timeout control.

3. The unified execution method for heterogeneous EDA tools controlled by a gateway according to claim 1, characterized in that, The capability registry records at least one piece of metadata for each registered capability interface. The metadata includes input parameter constraints, output result type, allowed return mode, calling permissions, dependencies, and calling instructions. The unified execution gateway only allows calls to capability interfaces registered in the capability registry, thereby blocking unregistered direct script execution and command execution.

4. The unified execution method for heterogeneous EDA tools controlled by a gateway according to claim 1, characterized in that, The unified execution gateway adopts a progressive capability exposure mechanism. It first exposes the connectivity detection interface, capability list interface, and capability description interface to the upper-layer caller. After receiving a query or call request for the target capability interface, it returns the parameter requirements, input and output formats, dependencies, and execution constraints of the target capability interface.

5. The unified execution method for heterogeneous EDA tools controlled by a gateway according to claim 1, characterized in that, When the tool call request corresponds to a long-running task, the task handle is associated with at least a task identifier, an instance identifier, and a task status; the upper-level caller obtains the progress information, stage status, or final result of the long-running task through a result query request.

6. The unified execution method for heterogeneous EDA tools controlled by a gateway according to claim 1, characterized in that, The operation management includes: performing readiness detection and heartbeat detection on the target backend instance to achieve the keep-alive detection; updating keep-alive information when the target backend tool instance is active or reused; terminating the long-running task or reclaiming the corresponding target backend tool instance when a timeout is detected to achieve the timeout control; performing exception cleanup when an abnormal fault is detected; performing release and reclamation when explicit release is detected, and reclaiming the process resources and communication resources occupied by the target backend instance; saving the design state snapshot and stage artifacts of the target backend instance, and restoring the target backend instance to the design state corresponding to the previously saved design state snapshot when the execution result of the current branch in the continuous optimization or continuous repair task does not reach the preset target.

7. A gateway-controlled unified execution system for heterogeneous EDA tools, used to implement the unified execution method for heterogeneous EDA tools as described in any one of claims 1-6, characterized in that, include: The access layer is used to receive tool invocation requests from clients; The communication layer is used to transmit the tool invocation request and its response result in accordance with a unified message format; A unified execution gateway is used to parse the execution protocol of the tool call request, look up the capability registry, verify parameters, verify permissions, distribute requests, and normalize and encapsulate the results. The tool adaptation module is used to encapsulate the native commands, script processes and analysis operations of different EDA tools into registered capability interfaces, and execute standardized capability calls corresponding to the target capability identifier on the target backend instance; The runtime management layer is used for starting, binding, reusing, keeping alive, monitoring, and recycling backend instances; The unified execution gateway and the operation management layer work together to determine the target backend instance based on the instance identifier and the tool type identifier. The tool adaptation module then executes a standardized capability call corresponding to the target capability identifier on the target backend instance, so that multiple requests corresponding to the same instance identifier can reuse the same loaded design state and runtime context.

8. The heterogeneous EDA tool unified execution system according to claim 7, characterized in that, The unified execution gateway includes a capability discovery unit and a method description unit. The capability discovery unit is used to provide the upper-layer caller with a connectivity detection interface and a capability list interface. The method description unit is used to return the parameter requirements, input and output formats, dependencies, and execution constraints of the target capability interface. The unified execution gateway only allows calls to explicitly registered capability interfaces.

9. The heterogeneous EDA tool unified execution system according to claim 7, characterized in that, The operation management layer includes a process management unit, an instance binding unit, a readiness detection unit, a heartbeat monitoring unit, an asynchronous task unit, and a cleanup and recycling unit. The process management unit is used to start and manage the EDA tool process. The instance binding unit is used to establish the binding relationship between the backend instance and the instance identifier. The readiness detection unit is used to detect whether the backend instance is in an executable state. The heartbeat monitoring unit is used to perform keep-alive detection. The asynchronous task unit is used to handle long-running tasks. The cleanup and recycling unit is used to reclaim instance resources when explicitly released, timed out, or exited due to a fault.

10. The heterogeneous EDA tool unified execution system according to claim 7, characterized in that, The tool adaptation module includes at least one of the following: a static timing analysis tool adaptation module, a logic synthesis tool adaptation module, a simulation tool adaptation module, and a place-and-route tool adaptation module. The static timing analysis tool adaptation module encapsulates timing analysis and reporting capabilities; the logic synthesis tool adaptation module encapsulates synthesis and netlist export capabilities; the simulation tool adaptation module encapsulates compilation, running, and debugging capabilities; and the place-and-route tool adaptation module encapsulates place, routing, and physical implementation process capabilities. The access layer includes at least one of a software development kit (SDK) interface, a command-line interface, and a proxy-oriented protocol service interface. The SSD interface is used for programmatic clients to construct requests and decode responses; the command-line interface is used for interactive calls or interactive debugging; and the proxy-oriented protocol service interface is used for large language model agents to initiate tool calls.

Images