A collaborative management system and method for an EDA all-in-one machine

Abstract

This application provides a collaborative management system and method for EDA appliances. The collaborative management system includes a business layer, an application layer, a platform layer, and a hardware layer. The hardware layer provides hardware resources and deploys container instances. The platform layer manages the hardware resources provided by the hardware layer, allocates resource quotas, and controls the instance lifecycle of the container instances. The application layer runs corresponding versions of EDA tools within the container instances. The business layer performs resource planning, template configuration, task scheduling, and result management throughout the entire chip design process of the EDA appliance. This solution integrates the entire chip design process through the business layer, incorporating scattered project information, resource requirements, and result management into a unified framework, breaking down information barriers in the toolchain, and reducing manual coordination costs. It also improves the predictability and traceability of task execution, providing an efficient and orderly collaborative management solution for EDA appliances.

Description

Technical Field

[0001] This application relates to the field of electronic design technology, and more specifically, to a collaborative management system and method for EDA all-in-one machines. Background Technology

[0002] Electronic Design Automation (EDA) technology permeates the chip design process, including schematic design, simulation verification, logic synthesis, placement and routing, and physical verification. As process nodes advance to 3nm and even more advanced processes, design scale and complexity increase exponentially, making traditional distributed toolchains insufficient. EDA appliances integrate various design tools and computing resources to create a unified operating environment from design to verification, effectively shortening development cycles and reducing deployment costs.

[0003] Currently, most EDA all-in-one machines in related technologies adopt static resource allocation and isolated tool deployment methods. The tools, process libraries and hardware resources used in each design stage are isolated from each other, lacking a unified resource and data collaborative management mechanism. This results in toolchain fragmentation, poor version compatibility, and low resource utilization, which seriously restricts chip design efficiency and quality. Summary of the Invention

[0004] The purpose of this application is to provide a collaborative management system and method for EDA all-in-one machines to solve the above-mentioned problems.

[0005] In a first aspect, embodiments of this application provide a collaborative management system for an EDA appliance, comprising: a business layer, an application layer, a platform layer, and a hardware layer, wherein: the business layer, the application layer, the platform layer, and the hardware layer are configured to communicate using a hybrid communication method of layered communication and cross-layer communication; the hardware layer is used to provide hardware resources and deploy container instances; the platform layer is used to manage instances, allocate resource quotas, and control the instance lifecycle of the container instances for the hardware resources provided by the hardware layer; the application layer is used to run corresponding versions of EDA tools in the container instances; and the business layer is used to perform resource planning, template configuration, task scheduling, and result management for the entire chip design process of the EDA appliance. In the implementation of the above solution, the entire chip design process is integrated at the business layer, incorporating scattered project information, resource requirements, and result management into a unified framework. This breaks down information barriers in the toolchain, reduces manual coordination costs, and improves the predictability and traceability of task execution, providing an efficient and orderly collaborative management solution for EDA appliances. On the other hand, the platform layer implements instance management, resource quota allocation, and lifecycle control for hardware resources based on containerization technology. This enables EDA tools to start in an isolated and replicable operating environment, ensuring consistency of tool versions and dependent libraries under the same process node, reducing design deviations caused by environmental differences, and improving the reliability of design results.

[0006] In one implementation of the first aspect, the business layer deploys an automated simulation management module, and the platform layer deploys a computing base, wherein: the automated simulation management module is used to read simulation configuration information and resource requirement information from the simulation process template of the simulation task to be executed, and generate a resource request description based on the resource requirement information; and write the template identifier of the simulation process template and the container instance identifier returned by the computing base into the environment variables of the container instance; the computing base is used to receive the resource request description and the simulation configuration information, create the container instance in the hardware layer based on the simulation configuration information, and return the container instance identifier of the container instance to the automated simulation management module; and allocate resource quotas to the container instance based on the resource request description from the hardware resources provided by the hardware layer; the EDA tool is used to execute the simulation task to be executed based on the template identifier in the environment variables after the container instance starts. In the implementation of the above solution, the automated simulation management module can obtain the EDA tool version, process library path, and resource requirements by parsing the simulation process template, and generate a structured resource request description accordingly. This allows the platform layer to complete the precise matching of tools, versions, and resources before the task starts, reducing the risk of environmental inconsistencies caused by version mismatches due to manual configuration. On the other hand, the computing base allocates hardware resources to container instances based on the resource request description, ensuring clear resource boundaries when multiple instances run in parallel and avoiding node performance jitter caused by single task overload. At the same time, the real-time return of container instance identifiers enables the business layer to maintain the task-instance mapping table in real time, making the task status traceable. Furthermore, after the container instance starts, the EDA tool directly reads the template identifier from the environment variables and loads the corresponding process node and constraint parameters, enabling rapid switching of the running environment of different design projects on the same hardware platform, shortening the design-verification iteration cycle, and avoiding hard-coded paths by using standardized environment variables, thus enhancing the repeatability and portability of the process.

[0007] In one implementation of the first aspect, the automated simulation management module is further configured to: acquire simulation results after the EDA tool completes the simulation task to be executed; calculate at least one performance index based on the simulation results; determine a target performance index among the performance indices; wherein the target performance index is used to characterize the performance indices that do not meet a preset performance index threshold; and generate design optimization suggestions based on the target performance index. In the implementation of the above scheme, by automatically acquiring simulation results and calculating at least one performance index after the simulation task is completed, a quantitative assessment of design quality is achieved, avoiding errors caused by subjective human judgment and improving the objectivity of design quality assessment. On the other hand, by determining a target performance index among the performance indices that do not meet a preset performance index threshold and generating task optimization suggestions based on the target performance index, design weaknesses can be accurately located, providing targeted improvement directions and thus improving the efficiency of design quality optimization.

[0008] In one implementation of the first aspect, the automated simulation management module is further configured to: calculate an error index based on the simulation error analysis results, compare the error index with a preset error index threshold, update the simulation configuration information based on the simulation error analysis results when the error index exceeds the preset error index threshold, and re-execute the simulation task to be executed based on the updated simulation configuration information. In the implementation of the above scheme, by calculating the error index and comparing it with a preset threshold in real time, it is possible to automatically identify whether the simulation results meet the design specifications without manual intervention, thereby improving the automation level and efficiency of the verification process. Furthermore, when the error index exceeds the preset error index threshold, the simulation configuration information can be automatically updated based on the simulation error analysis results. This closed-loop feedback mechanism ensures continuous optimization of design parameters and reduces repetitive manual debugging. Moreover, the simulation task can be automatically re-executed based on the updated simulation configuration information, realizing a complete closed loop of simulation-analysis-optimization-verification, accelerating the design convergence process, and improving overall design efficiency and quality.

[0009] In one implementation of the first aspect, the computing platform is further configured to: monitor the resource utilization rate of the hardware layer in real time; when the resource utilization rate exceeds a preset expansion threshold, add a container instance in the hardware layer and allocate a corresponding resource limit; and when the resource utilization rate is less than a preset shrinkage threshold, release the container instance. In the implementation of the above scheme, the computing platform, by monitoring the resource utilization rate of the hardware layer in real time, can respond promptly to changes in resource demand. When the resource utilization rate exceeds the preset expansion threshold, it can automatically add a container instance and allocate a corresponding resource limit, ensuring that task execution is not limited by resource bottlenecks, which is beneficial to improving the scalability and task execution continuity of the aforementioned collaborative management system. On the other hand, when the resource utilization rate is lower than the preset shrinkage threshold, the computing platform can promptly release idle container instances, avoiding resource waste, thereby improving resource utilization and system economy. Furthermore, the adoption of an automated resource management mechanism reduces manual intervention, lowers operating costs, and improves the efficient operation of the aforementioned collaborative management system under different load conditions, enhancing overall management efficiency and system adaptability.

[0010] In one implementation of the first aspect, the business layer further deploys a hardware resource scheduling and management module, used for: collecting resource usage data of the hardware resources; and allocating hardware resources to the task to be executed at the hardware layer based on the resource requirement information of the task to be executed and the resource usage data before the task to be executed is started. In the implementation of the above scheme, the hardware resource scheduling and management module provides an accurate basis for resource allocation by collecting hardware resource usage data in real time. This ensures that the collaborative management system can accurately allocate resources according to actual resource usage and task requirements before the task to be executed is started, improving the accuracy and efficiency of resource allocation. On the other hand, the hardware resource scheduling and management module allocates resources based on resource requirement information and usage data before the task starts, avoiding interruptions or delays caused by insufficient resources during task execution, ensuring smooth task execution, and improving the stability and reliability of the system. Furthermore, through reasonable resource allocation, the hardware resource scheduling and management module can improve the overall utilization rate of hardware resources, reduce resource waste, and thus reduce the operating cost of the collaborative management system used for EDA all-in-one machines.

[0011] In one implementation of the first aspect, the hardware resource scheduling and management module is further configured to: when multiple tasks to be executed simultaneously request hardware resources and the hardware resources are insufficient, arbitrate the resource allocation order based on the task priority and deadline of each task to be executed, and allocate the hardware resources to the tasks to be executed sequentially according to the arbitration result. In the implementation of the above scheme, when multiple tasks to be executed simultaneously request hardware resources and the resources are insufficient, the hardware resource scheduling and management module, through the arbitration mechanism based on task priority and deadline, can ensure that critical tasks receive priority resource allocation, thereby guaranteeing the timely execution and completion of important tasks and improving the overall efficiency and reliability of the system. On the other hand, by introducing task priority and deadline as decision factors for resource allocation, resource allocation becomes more reasonable and flexible, better meeting the needs of different tasks, avoiding blind and unbalanced resource allocation, and improving resource utilization efficiency. Furthermore, allocating hardware resources to tasks to be executed sequentially according to the arbitration result can avoid resource contention and chaos, ensuring the orderliness and standardization of the resource allocation process, and helping to improve the stability and manageability of the system.

[0012] In one implementation of the first aspect, the hardware resource scheduling and management module is further configured to: collect the resource utilization rate of each hardware node in the hardware layer; and, when the resource utilization rate of a hardware node is higher than a preset upper limit threshold, migrate the container instance on the hardware node to a target node; wherein the target node is the hardware node whose resource utilization rate is lower than a preset lower limit threshold. In the implementation of the above scheme, the hardware resource scheduling and management module can monitor the usage of hardware resources in real time by collecting the resource utilization rate of each hardware node, enabling it to promptly identify nodes with excessively high resource utilization rates and provide data support for subsequent resource optimization and adjustment. Furthermore, when the resource utilization rate of a hardware node exceeds the preset upper limit threshold, the hardware resource scheduling and management module can migrate the container instance to a target node with lower resource utilization. This operation effectively reduces the load pressure on the source node, avoiding system performance degradation or task execution delays caused by single-node overload. Moreover, by migrating container instances to nodes with lower resource utilization rates, load balancing of hardware resources is achieved. This not only improves the overall utilization rate of hardware resources and ensures the reasonable allocation of system resources, but also extends the lifespan of hardware devices and reduces system operating costs.

[0013] In one implementation of the first aspect, the business layer further deploys an environment configuration management module, used to: determine the running parameters of the task to be executed based on the process node of the task to be executed and the version information of the EDA tool; and inject the running parameters into the container instance to drive the EDA tool to execute the task to be executed according to the running parameters. In the implementation of the above scheme, the environment configuration management module, by automatically determining the running parameters of the task to be executed, can ensure that the EDA tool uses parameter settings that match the process node and tool version when executing the task. This helps improve the consistency and accuracy of task execution, reduces simulation or design failures caused by parameter configuration errors, and enhances the reliability of the overall design process. On the other hand, automatically injecting the running parameters into the container instance can avoid errors and delays caused by manual parameter configuration, realize the automation and standardization of task execution, improve work efficiency, and reduce manual intervention costs.

[0014] In one implementation of the first aspect, the business layer further deploys an IP core management module, a PDK management module, and a LIC management module, wherein: the IP core management module is used to maintain an IP core library and perform retrieval, access control, and compliance verification of IP cores; wherein the IP core library includes the functional parameters, applicable processes, performance indicators, and version information of the IP cores; the PDK management module is used to maintain a PDK library and perform version control and access control of PDKs; wherein the PDK library includes process rules, device models, and layer definition information; the LIC management module is used to maintain a license library and perform validity period monitoring and access control of licenses; wherein the license library includes the license type, license validity period, and license scope of the EDA tools and the IP cores. In the implementation of the above scheme, the IP core management module maintains the IP core library and provides retrieval, access control, and compliance verification functions to ensure that the use of IP cores complies with the licensing agreement and meets design requirements. This helps reduce the risk of infringement during the use of IP cores and improves the efficiency and accuracy of IP core management. On the other hand, the PDK management module maintains the PDK library and performs version control and access control to ensure the accuracy and consistency of the process design kit. This helps improve the reliability and manufacturability of chip design and reduce design errors caused by process mismatch. Furthermore, the LIC management module maintains the license library and performs validity period monitoring and access control to ensure that the use of EDA tools and IP cores complies with the license scope and term. This helps avoid legal risks caused by expired licenses or use beyond the scope of authorization and ensures the legality and continuity of the design process.

[0015] In one implementation of the first aspect, the business layer further deploys an EDA tool management module for: maintaining an EDA tool library and performing version control, compatibility verification, and access control for the EDA tools; wherein the EDA tool library includes functional descriptions, applicable design stages, supported process nodes, and version information of the EDA tools. In the implementation of the above scheme, the EDA tool management module, by maintaining the EDA tool library and performing version control, ensures that the EDA tools used in the design process have clear version records and traceability capabilities, helping to avoid design errors and repetitive work caused by inconsistent tool versions, and improving the reliability and maintainability of the design process. On the other hand, the EDA tool management module performs compatibility verification and access control to ensure the adaptability of EDA tools under different process nodes and restricts unauthorized use of tools, helping to reduce design risks.

[0016] In one implementation of the first aspect, the platform layer further deploys a dedicated acceleration module for: invoking a dedicated instruction set and parallel computing units to accelerate the computation of the task to be executed. In the implementation of the above scheme, the dedicated acceleration module, by invoking a dedicated instruction set customized for the characteristics of EDA tasks, can hard-code and accelerate computationally intensive subtasks, shortening the execution time of key steps such as logic synthesis and timing analysis, and reducing the clock cycle overhead of a single iteration. On the other hand, the introduction of parallel computing units enables concurrent execution of multi-path simulations or matrix operations within the same task, improving the effective computational throughput per unit time, thereby increasing the overall computing power utilization of the system without changing the total resources, and reducing task queuing time.

[0017] Secondly, embodiments of this application provide a collaborative management method for an EDA appliance. The method includes: reading simulation configuration information and resource requirement information from a simulation process template of a simulation task to be executed; generating a resource request description based on the resource requirement information; creating a container instance based on the simulation configuration information and returning the container instance identifier; allocating resource quotas to the container instance based on the resource request description; writing the template identifier of the simulation process template and the container instance identifier into the environment variables of the container instance; and executing the simulation task to be executed based on the template identifier in the environment variables after the container instance starts. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A schematic diagram of the architecture of a collaborative management system for an EDA all-in-one machine provided in an embodiment of this application; Figure 2 A schematic diagram of the architecture of a collaborative management system for an EDA all-in-one machine in a certain application scenario provided in this application embodiment; Figure 3 This is a schematic diagram of the architecture of the process management expert subsystem provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the collaborative management method for an EDA all-in-one machine provided in an embodiment of this application.

[0020] The diagram is labeled as follows: 100, Collaborative Management System for EDA Appliance; 110, Business Layer; 120, Application Layer; 130, Platform Layer; 140, Hardware Layer; 111, Automated Simulation Management Module; 112, Hardware Resource Scheduling Management Module; 113, Environment Configuration Management Module; 114, IP Core Management Module; 115, PDK Management Module; 116, LIC Management Module; 117, EDA Tool Management Module; 131, Computing Dock; 132, Dedicated Acceleration Module. Detailed Implementation

[0021] Electronic design automation (EDA) processes encompass multiple interdependent stages, including circuit design, simulation verification, logic synthesis, placement and routing, and physical verification. As chip design scales and the volume of design data and computational complexity continue to increase, the industry commonly integrates multiple EDA tools with high-performance computing hardware into a single EDA appliance. This aims to complete the entire process from design to approval within a single physical device, thereby shortening iteration cycles and reducing deployment costs. Existing EDA appliances generally employ static resource allocation and isolated tool deployment. On the one hand, the EDA tools, process libraries, and hardware resources required for each design stage are fixed during deployment, lacking a unified resource and data collaborative management mechanism. On the other hand, toolchains exchange data point-to-point via files or scripts, and version compatibility relies on manual maintenance, leading to frequent tool version conflicts, data format mismatches, and repetitive adaptation work. This fragmented architecture results in low resource utilization and severely restricts design iteration efficiency. In view of this, this application provides a collaborative management system for EDA all-in-one machines. By integrating the entire chip design process at the business layer, it incorporates scattered project information, resource requirements, and result management into a unified framework, breaking down information barriers in the toolchain, reducing manual coordination costs, and improving the predictability and traceability of task execution. This provides an efficient and orderly collaborative management solution for EDA all-in-one machines. On the other hand, the platform layer implements instance management, resource quota allocation, and lifecycle control for hardware resources based on containerization technology. This enables EDA tools to start in an isolated and replicable operating environment, ensuring the consistency of tool versions and dependent libraries under the same process node, reducing design deviations caused by environmental differences, and improving the reliability of design results.

[0022] Before introducing the aforementioned collaborative management system, let's first describe its application scenarios: This collaborative management system can be deployed in an EDA appliance. An EDA appliance is a dedicated computing device that integrates electronic design automation software tools, computing hardware, storage systems, and network equipment required for chip design, deployed in a rack or chassis. The EDA appliance can adopt a standardized rack structure, integrating multi-node servers, distributed storage arrays, and high-speed switching networks. Before leaving the factory, the toolchain, process library, and operating environment are pre-installed and their consistency verified, forming a physical entity ready to use upon power-on. The EDA appliance can interconnect with the network via an internal bus, or it can pool hardware resources to provide unified computing, storage, and networking capabilities to the upper-layer collaborative management system. Furthermore, the EDA appliance can reserve standard interfaces to support component replacement or capacity expansion based on process evolution or tool upgrades.

[0023] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings. Please refer to... Figure 1This application provides a collaborative management system 100 for an EDA appliance. The system includes a business layer 110, an application layer 120, a platform layer 130, and a hardware layer 140. The business layer 110, application layer 120, platform layer 130, and hardware layer 140 are configured to communicate using a hybrid communication method combining layered and cross-layer communication. The hardware layer 140 provides hardware resources and deploys container instances. The platform layer 130 receives instance management instructions from the business layer 110, manages the hardware resources provided by the hardware layer, allocates resource quotas, controls the instance lifecycle of container instances, and provides a container instance runtime environment to the application layer 120. The application layer 120 runs corresponding versions of EDA tools within the container instances created by the platform layer 130. The business layer 110 sends instance management instructions to the platform layer 130 and receives the running results returned by the application layer 120, performing resource planning, template configuration, task scheduling, and result management throughout the entire chip design process of the EDA appliance.

[0024] The aforementioned hybrid communication method refers to a four-layer architecture consisting of the business layer 110, application layer 120, platform layer 130, and hardware layer 140. This architecture allows adjacent layers to directly exchange control messages and data through standardized interfaces, while also allowing non-adjacent layers to communicate indirectly via the forwarding mechanism of an intermediate layer. The system can dynamically select either a direct communication path or an intermediate layer forwarding path based on message type, real-time requirements, etc., to balance communication efficiency and architectural flexibility. An example implementation of this hybrid communication method is as follows: two types of communication paths are defined between the business layer 110, application layer 120, platform layer 130, and hardware layer 140: direct communication between adjacent layers and cross-layer forwarding communication, both implemented based on a unified layered protocol stack. The protocol stack, from top to bottom, can include a control message layer, a business data layer, a transport adaptation layer, and a physical link layer. The control message layer uses JSON encoding to encapsulate command types, transaction IDs, timestamps, and checksums, used to transmit control signaling such as instance creation, resource quota adjustment, and task status feedback. The business data layer uses Protocol Buffers serialization to carry large amounts of data such as netlists, waveforms, and logs, and supports fragmentation and retransmission. The transport adaptation layer provides two modes: TCP reliable streaming and RDMA zero-copy transmission, which can be dynamically selected according to data volume and real-time requirements. The physical link layer supports 10 / 25 / 40GbE Ethernet and InfiniBandEDR. Link discovery and failover are completed through LLDP and IB Subnet Manager to ensure high availability at the link level. Direct communication between adjacent layers uses gRP Cover TLS as the default interface specification. Two sets of interfaces, ResourceService and TaskService, can be defined between the business layer 110 and the platform layer 130. ResourceService can provide RPC methods such as resource reservation, quota query, and node health detection; TaskService can be responsible for task assignment, status subscription, and result retrieval. The interface description file can use the protobuf compiler's schema, with the version number embedded in the schema header, supporting forward and backward compatibility. Cross-layer forwarding communication can be uniformly implemented by the Message-Broker built into the platform layer 130. The Broker maintains a topic-subscription table, and topics can be named according to a three-level hierarchy of "layer-module-message type". When the business layer 110 needs to transmit out-of-band control commands to the hardware layer, the message is first published to the corresponding topic. The Broker forwards the message to the target layer according to the subscription relationship. The forwarding process uses an asynchronous queue, supports message persistence and replay, and ensures that cross-layer commands are not lost.

[0025] The hardware resources provided by the aforementioned hardware layer 140 may include: (1) computing resources, such as: high-performance server clusters, central processing units, graphics processors, field-programmable gate array accelerator cards, etc.; (2) storage resources, such as: distributed high-speed storage arrays, non-volatile memory, local solid-state drives, etc.; (3) network resources, such as: high-speed Ethernet switches, fiber optic channels, remote direct memory access network interfaces; (4) other supporting resources, such as: uninterruptible power supplies, cabinets and backplane buses, etc.

[0026] The aforementioned container instance refers to an independent runtime environment created using containerization technology on top of the host operating system kernel provided by hardware layer 140. The container instance achieves isolation of the file system, process space, network protocol stack, and device access through namespace and control group mechanisms, and is configured with defined hardware resource quotas, thereby ensuring that the EDA tools running internally do not interfere with external processes. The container instance starts using a read-only image as a template, and the image contains specific versions of EDA tools, dependency libraries, and process documents. During instantiation, a writable file system can be overlaid on the image layer to record temporary data and logs generated during runtime. Platform layer 130 can uniformly manage the instance lifecycle through interfaces, completing creation, startup, pause, and destruction operations, and maintaining the resource mapping relationship between the instance and the host machine.

[0027] The main functions of the platform layer 130 mentioned above include: (1) Instance management: The platform layer 130 can pool the hardware resources provided by the hardware layer 140 through the containerization interface and generate container instances using the image as a template. During the instance creation process, the platform layer 130 can select the corresponding version of the EDA tool image based on the simulation configuration information issued by the business layer 110, complete the instance identifier allocation, network address configuration and storage volume mounting, so that the container instance has a definite running environment before startup. (2) Resource quota allocation: The platform layer 130 can read the resource request description during the instantiation stage, call the control group mechanism to set the upper limit of the CPU time slice, memory capacity, block device I / O bandwidth and other contents of the container instance, and inject the allocation result into the instance running environment in read-only form. The upper limit cannot be exceeded during the instance operation, thereby ensuring resource isolation and predictability when multiple instances run in parallel. (3) Instance lifecycle control of container instances: The platform layer 130 maintains the full state machine of the instance from creation, startup, suspension, recovery to destruction. The state transition is triggered by the scheduling command of the business layer 110 or the process exit event in the instance. During the transition, the platform layer 130 synchronously reclaims the network identifier, storage volume and resource quota, and reports the state change to the business layer 110 to realize the closed-loop management of the instance lifecycle.

[0028] The aforementioned application layer 120 deploys multiple EDA tools, including circuit schematic and layout design tools, digital / analog pre-simulation tools, digital / analog post-simulation tools, logic synthesis and timing analysis tools, place and route tools, physical verification tools, and reliability analysis tools. These EDA tools are collections of computer programs used to complete specific stages in the entire chip design process, such as circuit modeling, functional verification, logic synthesis, place and route, physical verification, and reliability analysis. EDA tools can be deployed in application layer 120 as executable files, script interfaces, and associated technology libraries. They read design data, process models, and constraints, and output netlists, simulation results, or layout data for further processing in subsequent stages. Within the container instance, EDA tools are provided as image layers, with their versions strictly corresponding to process nodes, standard cell libraries, and design rule check scripts. When an EDA tool starts, it obtains runtime parameters from environment variables injected from the platform layer and executes tasks within the limited resources. Logs and result data generated during EDA tool operation are sent back to the business layer, achieving closed-loop flow of design data and version traceability.

[0029] The main functions of the above-mentioned business layer 110 include: (1) Resource planning: The business layer 110 can perform global statistics and capacity assessment of the computing, storage, network and license resources available in the EDA all-in-one machine. Based on the scale, process node and milestone requirements of the chip design project, it generates a resource requirement plan and issues a resource reservation instruction to the platform layer 130 to ensure that the hardware resources and software licenses are pre-allocated before the project starts, and avoids resource contention during operation. (2) Template configuration: The business layer 110 can maintain a simulation process template library. The template content includes process node, EDA tool version, tool execution order, input and output paths and running parameters. When the project is established, the corresponding template can be selected according to the design type, and the template identifier and version information are written into the container instance environment variable to realize the standardization and repeatability of the design process. (3) Task scheduling: The business layer 110 can decompose the chip design process into schedulable task units according to the dependency relationship defined by the template and the resource reservation status, and generate a scheduling sequence through priority queue and deadline constraints. The scheduling command is sent to the platform layer 130 through the layered communication interface, triggering the creation of container instances and the startup of EDA tools. At the same time, the task status is continuously collected, and abnormal exits or resource shortage events are retried or migrated to ensure the continuity and timeliness of the design process. (4) Result management: After the task is completed, the business layer 110 collects the logs, reports and design data returned by the container instance and stores them in the data base according to the project-stage-iteration index. The logs are parsed through the rule engine to generate error indicators and trend charts, and a visual interface is provided for project managers to trace historical records and compare iteration differences, providing data basis for subsequent optimization and approval decisions.

[0030] The instance management instructions mentioned above are sent from the business layer 110 to the platform layer 130, instructing operations such as creating, configuring, starting, pausing, resuming, and destroying container instances. The business layer 110 generates these instructions based on the resource requirements and priorities of the designed tasks and sends them to the platform layer 130 via the communication interface. After receiving and parsing the instructions, the platform layer 130 creates container instances in the resource pool of the hardware layer 140, allocates hardware resource quotas, and sets up the runtime environment. Upon completion of the operations, the platform layer 130 returns the container instance's identification information to the business layer 110.

[0031] The working principle of the collaborative management system 100 for the EDA appliance described above includes: Upon system startup, the business layer 110 performs a global statistical analysis of the hardware resources provided by the hardware layer 140 based on the process nodes and milestone requirements of the chip design project, generating resource planning results, and then sends the planning information to the platform layer 130. Upon receiving the planning instructions, the platform layer 130 creates container instances within the hardware resource pool, allocates defined resource limits to the instances using a control group mechanism, and maintains the instance lifecycle state, enabling the instances to be quickly activated or reclaimed in subsequent stages. When the design task enters the execution phase, the business layer 110 selects the corresponding EDA tool version and generates template configuration data containing tool paths and runtime parameters. This data can be transmitted to the application layer 120 via a direct communication channel between adjacent layers. The application layer 120 then starts the specified version of the EDA tool within the ready container instance based on the template configuration data. After the task is completed, the application layer 120 can send logs and result data back to the business layer 110. The business layer 110 indexes and stores the data, updates the task status, and completes result management.

[0032] Optionally, the aforementioned business layer 110 deploys an automated simulation management module 111, and the aforementioned platform layer 130 deploys a computing base 131. Specifically: the automated simulation management module 111 reads simulation configuration information and resource requirement information from the simulation process template of the simulation task to be executed, and generates a resource request description based on the resource requirement information; and writes the template identifier of the simulation process template and the container instance identifier returned by the computing base 131 into the environment variables of the container instance; the computing base 131 receives the resource request description and simulation configuration information, creates a container instance at the hardware layer based on the simulation configuration information, and returns the container instance identifier of the container instance to the automated simulation management module; and allocates resource quotas to the container instance based on the resource request description from the hardware resources provided at the hardware layer; and an EDA tool deployed in the application layer 120 executes the simulation task to be executed based on the template identifier in the environment variables after the container instance starts. The aforementioned simulation process template is a predefined structured description file of the business layer 110 for completing the simulation task, and can be stored in a local template library in XML or JSON format. The top-level node of the simulation workflow template can sequentially define process nodes, EDA tool versions, test case sets, input / output paths, runtime parameters, and task dependencies. The process node field associates the PDK version, the tool version field specifies the container image tag, the test case set field lists the stimulus files and reference waveforms, the input / output path field specifies the storage location of the design netlist, constraint files, and result logs, the runtime parameter field includes temperature, voltage corner point, simulation accuracy, and timeout threshold, and the task dependency field specifies the execution order through a list of preceding task IDs, ensuring that circuit simulation, logic simulation, and timing analysis are executed sequentially or in parallel according to a predetermined process. During template instantiation, the automated simulation management module 111 reads the above fields and generates a resource request description, while using the combination of process nodes and tool versions as the basis for image selection. After the template identifier is written to the container instance environment variables, the EDA tool startup script loads the runtime parameters under the corresponding node based on this identifier, thereby reproducing a consistent simulation environment and avoiding version mismatches and parameter drift caused by manual configuration. The automated simulation management module 111 generates resource request descriptions as follows: After receiving a task creation instruction, it first parses the simulation process template and extracts a set of resource-related fields, which may include: the number of CPU cores, memory capacity, number of accelerator cards, temporary storage space size, and runtime limit. These fields exist in the template header in key-value pair format. The automated simulation management module 111 converts them into a structured resource requirement vector through pattern matching. Subsequently, the automated simulation management module 111 compares the resource requirement vector with the currently available resource vector published by the platform layer 130 element by element. If any element shows a demand greater than availability, a resource waiting or expansion prompt is triggered.If all elements are satisfied, the demand vector is encapsulated into a resource request description conforming to the platform layer interface specification. This description includes a version number, task identifier, resource specification list, and quota flag. It can be serialized in JSON format and sent to the compute base 131 for execution of the corresponding resource quota allocation when creating container instances.

[0033] The aforementioned simulation task refers to the computational process performed in the chip design flow to verify the correctness of circuit function, timing, power consumption, or physical implementation. Its inputs include design netlists, test stimuli, process models, and constraint files, while the outputs are waveforms, logs, reports, or revised netlists used to determine whether the design meets specification requirements. In the aforementioned collaborative management system 100 for the EDA appliance, the simulation task uses a simulation flow template as a description carrier and is decomposed into schedulable units such as circuit simulation, logic simulation, timing analysis, and power consumption analysis. Each unit is executed within a container instance by the corresponding version of the EDA tool. The platform layer 130 can allocate limited resources such as the required CPU, memory, and storage bandwidth. The business layer 110 tracks the execution process and collects results through the binding relationship between template identifiers and instance identifiers, achieving full lifecycle management of the task. It is understood that, in addition to executing simulation tasks, the aforementioned EDA appliance can also complete tasks such as logic synthesis, timing analysis, placement and routing, physical verification, and reliability analysis throughout the entire chip design flow. In the logic synthesis phase, hardware description languages ​​can be converted into gate-level netlists, and area, power consumption, and speed can be optimized. In the timing analysis phase, static timing verification of the netlist can be performed to ensure that setup and hold times within the clock domain meet specifications. In the placement and routing phase, cell placement and signal interconnection are completed while considering geometric constraints, and GDSII layout data is output. In the physical verification phase, the EDA appliance performs design rule checks and layout circuit verification. Figure 1 Consistency verification confirms that the layout conforms to the foundry's process specifications. During the reliability analysis phase, electromigration, voltage drop, and hot carrier injection analyses can be performed to assess the chip's lifetime risk under rated operating conditions. All of the above tasks can utilize container instances as execution units, with platform layer 130 uniformly allocating computing and storage resources. Business layer 110 enables one-click switching of process nodes, tool versions, and operating parameters through template configuration, thereby completing the entire design verification process from RTL to approval within the same physical device.

[0034] In the above scheme, the working principle of the collaborative management system 100 for EDA all-in-one machine to achieve automated orchestration of simulation tasks includes: The automated simulation management module 111 first parses the simulation process template corresponding to the simulation task to be executed, extracts the process node, EDA tool version, test case set, and quantifies resource requirements, and maps the resource requirements into a structured vector to generate a resource request description that conforms to the interface specification of platform layer 130. Subsequently, the automated simulation management module 111 sends the resource request description and simulation configuration information to the computing base 131 at the same time, and enters a waiting state to receive the instance identifier returned by platform layer 130. After receiving the resource request description, the computing base 131 selects a node that meets the resource specifications in hardware layer 140, creates a container instance using the container image as a template, and applies hardware resource quota binding to the container instance. After the container instance is successfully created, the computing base 131 returns the unique identifier of the container instance to the automated simulation management module 111. After receiving the container instance identifier, the automated simulation management module 111 writes the template identifier and the instance identifier into the environment variables of the container instance to complete the pre-run binding. After the container instance starts, its internal initialization script reads the template identifier from the environment variables, locates the template file based on the template identifier, and loads the corresponding technology library, constraint file, and runtime parameters. It then activates the specified version of the EDA tool and executes circuit simulation, logic simulation, or timing analysis tasks in the order defined by the template. After the task is completed, logs and results data can be sent back to the business layer 110, triggering a status update, thus achieving fully automated orchestration of the entire process from resource allocation and environment construction to task execution.

[0035] The automated simulation management module 111 in the above scheme can obtain the EDA tool version, process library path, and resource requirements by parsing the simulation process template, and generate a structured resource request description accordingly. This allows the platform layer 130 to complete the accurate matching of tools, versions, and resources before the task starts, reducing the risk of environmental inconsistencies caused by version mismatch due to manual configuration. On the other hand, the computing base 131 allocates hardware resources to container instances based on the resource request description, ensuring clear resource boundaries when multiple instances run in parallel and avoiding node performance jitter caused by single task overload. At the same time, the real-time return of container instance identifiers enables the business layer 110 to maintain the task-instance mapping table in real time, making the task status traceable. Furthermore, after the container instance starts, the EDA tool directly reads the template identifier from the environment variables and loads the corresponding process node and constraint parameters, realizing rapid switching of the running environment of different design projects on the same hardware platform, shortening the design-verification iteration cycle, and avoiding hard-coded paths by using standardized environment variables, thus enhancing the repeatability and portability of the process. The aforementioned automated simulation management module 111 is further configured to: obtain simulation results after the EDA tool completes the simulation task to be executed; calculate at least one performance index based on the simulation results; determine a target performance index among the performance indices; wherein the target performance index is used to characterize performance indices that do not meet a preset performance index threshold; and generate design optimization suggestions based on the target performance index. The aforementioned performance indices refer to indicators used to quantitatively evaluate the performance of a chip design under a specific simulation task, and can include multiple key aspects of the chip design. For example, in analog chip design, performance indices can include gain bandwidth, linearity, noise figure, power consumption, conversion efficiency, etc., which directly reflect the performance of digital chip design in signal amplification, conversion, and processing. As another example, in digital chip design, performance indices can include key indicators such as timing performance, power consumption, and area. Timing performance indices, such as timing violation rate and clock cycle, can be used to evaluate the operational stability of digital chip design under timing constraints. Power consumption indices can include dynamic power consumption and static power consumption, which can be used to measure the energy consumption performance of a circuit in operation and standby states. Area indices can involve the number of transistors and chip size, directly affecting manufacturing costs and performance efficiency. Furthermore, in digital chip design, performance metrics can also focus on reliability and security to ensure the stability of the chip during long-term operation and the security of data processing. The process of calculating performance metrics based on simulation results, as described above, essentially transforms the raw simulation output data into quantitative indicators with clear physical or functional meaning through a series of technical means. After the simulation task is completed, data containing information such as time-domain waveforms, frequency-domain response, and voltage / current change curves is generated. After preprocessing such as screening and filtering, the parts directly relevant to performance evaluation can be extracted from this data.By pre-establishing a mathematical model relating simulation data to performance metrics, the processed data can be mapped to the domain defined by the performance metrics. For example, the gain bandwidth of an analog chip can be obtained by fitting the amplitude-frequency response curve of the output signal, while the timing violation rate of a digital chip is calculated by analyzing path delay data. This process is typically accomplished using automated analysis tools or scripts, which process simulation data in batches according to predefined calculation rules, identify key feature points, and complete the metric calculations.

[0036] The above scheme can pre-set preset performance index thresholds for each performance index. The factors to consider when setting preset performance index thresholds include: (1) Design goals and specifications: The chip design specifications clearly define the specific requirements for each performance index, such as the gain bandwidth, linearity, and noise figure of analog chips, or the timing constraints (such as setup time and hold time), power consumption limits (dynamic power consumption and static power consumption), and area targets of digital chips. These specifications are usually determined by the application scenario and performance requirements of the chip and are the basic principles for setting thresholds. (2) Historical data and experience values: By analyzing the simulation and test data of similar projects in the past, we can understand the actual distribution of each performance index and common problems. (3) Cost and resource constraints: Overly strict thresholds may lead to frequent design iterations and resource waste, while overly lenient thresholds may affect the design quality. Therefore, under the premise of meeting the design goals, we can balance performance and cost to ensure that the preset performance index thresholds are both technically feasible and in line with resource constraints. It is understandable that the above performance indexes can measure whether the chip design meets the specification requirements. The index values ​​are usually related to a variety of factors in the design, such as circuit topology, device size, process parameters, timing constraints, etc. By establishing mathematical models or empirical relationships between performance metrics and these design parameters, key design factors affecting performance metrics can be identified. When a performance metric fails to reach a preset threshold, the correlation between that metric and related design parameters can be analyzed to determine which design parameters need adjustment. For example, in analog chip design, if the gain bandwidth does not reach the target value, the system may analyze the impact of parameters such as circuit device size, bias current, and load capacitance on the metric, and propose optimization suggestions accordingly, such as increasing transistor size to improve driving capability or reducing load capacitance to improve high-frequency response. In digital chip design, if the timing violation rate is too high, the system may check the clock tree structure, logic gate delay, routing parasitic parameters, etc., and suggest optimizing the clock network design or adjusting the logic gate size on the critical path. In addition, the design optimization suggestions generated by the system can be specific to executable operations in the design flow, such as modifying device parameters in the netlist, adjusting placement and routing strategies, and optimizing process corner settings. Design optimization suggestions can be provided to design engineers in the form of reports to help them make targeted improvements to the design in subsequent iterations to improve performance metrics.

[0037] The aforementioned automated simulation management module 111 is also used for: calculating error indicators based on simulation error analysis results, comparing error indicators with preset error indicator thresholds, updating simulation configuration information based on simulation error analysis results when the error indicators exceed the preset error indicator thresholds, and re-executing the simulation task to be executed based on the updated simulation configuration information. The aforementioned error indicators can be selected from at least one or more of the following indicators: (1) Timing violation rate, which can be calculated by: analyzing the timing violation events extracted from the simulation logs, and statistically analyzing the ratio of the number of violations of setup time and hold time in the timing path to the total number of paths. The calculation formula is: Timing violation rate = (number of violation paths / total number of paths) × 100%. The lower the timing violation rate, the better the timing performance of the design. If the indicator exceeds the preset error indicator threshold, it indicates that there are many timing problems, and timing constraints need to be optimized or the circuit structure needs to be adjusted. (2) Logic error rate. The calculation method can be: the ratio of the number of logic error events such as inconsistencies and illegal states that occur during the simulation to the total number of simulation cycles. The calculation formula is: Logic error rate = (number of logic errors / total number of simulation cycles) × 100%. The lower the logic error rate, the more stable the logic function of the design. If the logic error rate exceeds the preset error index threshold, it indicates that there is a functional defect in the design and the relevant logic needs to be corrected. (3) Power consumption exceedance rate. The calculation method can be: compare the circuit power consumption data obtained from the simulation with the power consumption limit in the design specification, and calculate the ratio of the number of clock cycles with power consumption exceeding the limit to the total number of simulation cycles. The calculation formula is: Power consumption exceedance rate = (number of power consumption exceedance cycles / total number of simulation cycles) × 100%. The higher the power consumption exceedance rate, the worse the power consumption performance of the design. If the power consumption exceedance rate exceeds the preset error index threshold, power consumption optimization measures need to be taken, such as adjusting the circuit structure or optimizing the clock gating. The error index can be selected according to the specific chip design requirements and verification objectives, choosing one or more of timing violation rate, logic error rate and power consumption exceedance rate. When selecting multiple metrics, these metrics can be weighted and combined to form a comprehensive error index for a holistic evaluation of simulation results. The weighting of each metric can be determined based on its importance or the focus of the design phase. For example, during the timing convergence phase, the timing violation rate can have a higher weight; during the logic function verification phase, the logic error rate can have a higher weight. This approach provides a more comprehensive reflection of the design quality, offering more accurate guidance for subsequent design optimization. Alternatively, each metric can be individually thresholded. When a preset error index threshold is exceeded, the corresponding information in the simulation configuration is updated. For instance, when a timing violation rate exceeds the preset error index threshold, the main timing bottleneck path is identified based on the critical path information. Timing constraints are updated by shortening clock cycles, increasing register retiring, or optimizing combinational logic depth, redefining the latency limits of timing paths to improve timing performance.

[0038] When error metrics include timing violation rate, logic error rate, and power consumption exceedance rate, the aforementioned automated simulation management module 111 can update simulation configuration information based on simulation error analysis results as follows: When the timing violation rate exceeds a preset error metric threshold, the main timing bottleneck path is determined based on critical path information. Timing constraints are updated by shortening clock cycles, increasing register retiring, or optimizing combinational logic depth, and the delay limits of timing paths are redefined to improve timing performance. When the logic error rate exceeds a preset error metric threshold, the error-reporting module and critical path information are analyzed to locate circuit parts with logical defects, such as incorrect connections in combinational logic or illegal state transitions in state machines. The RTL code or netlist of the design is modified according to the cause of the problem, and the logic function modules are reconfigured to ensure they meet the functional requirements of the design specifications. When the power consumption exceedance rate exceeds a preset error metric threshold, the main power consumption source can be determined based on power consumption analysis results, such as modules with excessive dynamic power consumption or units with large static leakage current. Power consumption-related parameters in the simulation configuration can be updated by optimizing the clock tree structure, increasing clock gating, adjusting power domain partitioning, and applying low-power design techniques to reduce power consumption to an acceptable range. When error metrics include timing violation rate, logic error rate, and power consumption exceedance rate, and these metrics are obtained by weighted summation of the three metrics, the aforementioned automated simulation management module 111's scheme for updating simulation configuration information based on simulation error analysis results may include: identifying the main performance bottlenecks or functional defects based on the critical path information, error-reporting modules, and error types in the error analysis results; prioritizing adjustments to the components that contribute the most to the overall error metric based on the weights of each error metric; for example, if the timing violation rate has a high weight and is a major contributing factor, optimizing timing constraints, such as adjusting the clock cycle, optimizing the logic depth on the critical path, or introducing register retiming; if the logic error rate has a high weight, locating the logic defect module and correcting functional errors in the RTL code or netlist; and if the power consumption exceedance rate has a high weight, optimizing power consumption-related configurations, such as adjusting the clock tree, adding clock gating, or optimizing power domain partitioning. After updating the simulation configuration information, the system automatically re-executes the simulation task. Based on the new simulation results, the above analysis and update process is repeated until the overall error metric falls below the preset error metric threshold, forming a closed-loop optimization process. This process ensures continuous improvement of the simulation configuration until the design meets multi-dimensional performance and functional requirements.

[0039] Factors to consider when setting the above-mentioned preset error index thresholds may include: (1) Design specifications and objectives: Determine the strictness of each error index according to the specific functions, performance and power consumption objectives of the chip design. For example, for high-performance computing chips, the threshold for timing violation rate should be set lower to ensure its stability during high-speed operation; while for low-power IoT chips, the threshold for power consumption exceedance rate needs to be more strictly controlled. (2) Process and technology nodes: The circuit characteristics under different process nodes are quite different, which affects the reasonable range of error indexes. In advanced process nodes, timing violations and power consumption problems are more likely to occur due to factors such as device size reduction and parasitic parameter changes. Therefore, it is necessary to adjust the threshold according to the characteristics of the process node and the design rules provided by the foundry. (3) Historical data and experience: Refer to the simulation and test data of similar projects or chips in the past to understand the actual distribution of each error index under different design stages and conditions. Combine actual project experience to determine a reasonable threshold range so as to more accurately reflect the quality status and potential risks of the current design. (4) Margin and reliability requirements: In order to ensure the reliable operation of the chip under various working conditions, a certain margin needs to be considered in the threshold setting. For applications with high reliability requirements, the threshold for error indicators should be appropriately lowered and the design margin increased to reduce the risk of potential failures.

[0040] Furthermore, the collaborative management system 100 for the aforementioned EDA appliance can generate optimization suggestions based on specific information in the error analysis results (such as error type, module location, and critical path). For example, if the timing violation rate exceeds the limit, suggestions might include adjusting clock constraints, optimizing combinational logic, or repositioning the critical path; if the logic error rate exceeds the limit, suggestions might involve checking the RTL code of specific modules or correcting logical connections in the netlist; if the power consumption exceed the limit, suggestions might include applying clock gating, optimizing power management strategies, or adjusting the operating frequency. Optimization suggestions can be pushed to design engineers through the user interface or notification system. The suggestions are presented in a structured format, including the error type, affected modules, critical path information, and specific adjustment measures.

[0041] The aforementioned computing base 131 is also used for: real-time monitoring of resource utilization in the hardware layer; adding a new container instance and allocating corresponding resource quotas in the hardware layer when the resource utilization exceeds a preset expansion threshold; and releasing the container instance when the resource utilization is less than a preset shrinkage threshold. When the resource utilization exceeds the preset expansion threshold, the expansion method of the computing base 131 can be as follows: First, the computing base 131 pulls a container image of a specified version from the image repository, and then selects a suitable node in the hardware layer 140 for instantiation. During instantiation, the computing base 131 can allocate the required hardware resources to the newly created container instance based on the resource request description and set resource quotas to ensure resource isolation. After the container instance starts, the computing base 131 reports its identifier and available resource information to the platform layer 130 and notifies the business layer to schedule tasks, ensuring that the new instance can be quickly put into operation to meet task execution requirements. When the resource utilization rate is less than the preset shrinkage threshold, the shrinkage method of the computing base 131 can be as follows: the computing base 131 selects idle or low-load container instances for release according to the preset strategy. During the release process, the computing base 131 first safely stops the execution of tasks in the container instance to ensure that the task data has been saved or migrated to other instances. Subsequently, the computing base 131 releases the resources related to the container instance, including removing the resource quota setting, reclaiming computing and storage resources, and updating the resource status information in the platform layer 130. The factors to consider when setting the preset expansion threshold and the preset shrinkage threshold can include: (1) workload characteristics: For tasks with large fluctuations in resource usage, it is recommended to set the expansion threshold in the middle range of resource utilization to quickly respond to sudden resource demands. For tasks with relatively stable resource usage, the expansion threshold can be appropriately increased to reduce frequent expansion operations. (2) resource supply cost: If the resource supply cost is high, it is recommended to appropriately increase the expansion threshold to avoid frequent expansion leading to increased costs. Conversely, if the resource cost is low, the expansion threshold can be appropriately reduced to respond to resource demands more promptly. (3) System stability and performance: When setting the expansion threshold, it is necessary to ensure the stability and performance of the system. The expansion threshold should not be set too high, otherwise it may lead to a performance bottleneck due to insufficient resources. It is generally recommended to set the expansion threshold in the range where the resource utilization rate is in the middle to high range, so as to achieve a balance between system stability and resource utilization rate. At the same time, a certain safety margin should be reserved to prevent the system from crashing or the task from failing due to untimely resource supply. (4) System resource utilization rate: When setting the preset expansion threshold and preset reduction threshold, the system's resource utilization rate should be comprehensively considered. The setting of the expansion threshold should be based on the accurate monitoring and analysis of the system's resource usage to ensure that the system can respond in a timely manner when resource demand increases, and avoid affecting task execution due to insufficient resources. When the resource utilization rate drops to a low level, a reduction threshold can be set to release idle resources and improve the overall utilization rate of resources.By reasonably setting preset expansion and reduction thresholds, the collaborative management system 100 for EDA all-in-one machines can achieve optimal resource allocation while meeting task requirements.

[0042] The computing base 131 in the above solution can respond promptly to changes in resource demand by monitoring the resource utilization rate of the hardware layer 140 in real time. When the resource utilization rate exceeds the preset expansion threshold, it can automatically add container instances and allocate corresponding resource quotas to ensure that task execution is not limited by resource bottlenecks. This is beneficial to improving the scalability and task execution continuity of the collaborative management system 100 used for EDA all-in-one machines. On the other hand, when the resource utilization rate is lower than the preset shrinkage threshold, the computing base 131 can release idle container instances in a timely manner to avoid resource waste, thereby improving resource utilization and system economy. Furthermore, the adoption of an automated resource management mechanism reduces manual intervention, lowers operating costs, and improves the efficient operation of the collaborative management system 100 used for EDA all-in-one machines under different load conditions, thereby improving overall management efficiency and system adaptability.

[0043] The aforementioned business layer 110 also deploys a hardware resource scheduling and management module 112, used for: collecting hardware resource usage data; and allocating hardware resources to the task to be executed in the hardware layer 140 based on the task's resource requirements and usage data before the task is started. The working principle of the hardware resource scheduling and management module 112 allocating hardware resources to the task includes: First, the hardware resource scheduling and management module 112 collects hardware resource usage data in real time through monitoring components deployed in the hardware layer 140, including computing resources (such as CPU utilization and memory usage), storage resources (such as disk I / O and available space), and network resources (such as bandwidth utilization). This data is transmitted periodically or in real-time to the hardware resource scheduling and management module 112 in the business layer 110 through preset data acquisition interfaces and protocols, enabling the hardware resource scheduling and management module 112 to accurately grasp the current status of hardware resources. Second, after receiving the resource requirements information of the task to be executed, the hardware resource scheduling and management module 112 parses the task requirements and extracts the type and quantity of hardware resources required by the task. This parsing process can be based on the resource request parameters passed in the task description file. The hardware resource scheduling and management module 112 can comprehensively analyze the task requirements with the currently collected hardware resource usage data to determine the optimal resource allocation scheme to meet the task execution requirements. Then, based on the analysis results, the hardware resource scheduling and management module 112, in collaboration with the platform layer 130, allocates the corresponding hardware resources to the task to be executed at the hardware layer 140. This process involves resource reservation, allocation, and confirmation steps to ensure that the task obtains the necessary hardware support before startup. Finally, the hardware resource scheduling and management module 112 continuously monitors the task execution status and resource utilization efficiency after resource allocation, so as to make dynamic adjustments as needed during task execution. If insufficient or excessive resource allocation is found, the hardware resource scheduling and management module 112 will promptly reallocate or reclaim resources to optimize resource utilization efficiency and support the resource requirements of other tasks. It should be noted that the hardware resource scheduling and management module 112 and the computing base 131 differ in resource allocation in at least the following ways: (1) Different allocation timing: The hardware resource scheduling and management module 112 mainly allocates resources before the task to be executed starts, reserving and preparing the necessary hardware resources for the task in advance. The computing base 131 usually allocates resources dynamically according to actual needs during the task execution phase, such as adjusting resources according to load changes during task operation. (2) Different allocation granularity: The hardware resource scheduling and management module 112 performs a more macro-level resource allocation, focusing on reserving sufficient hardware resources for the overall task, such as reserving a certain amount of CPU and memory space for a chip design project.The computing base 131 focuses on more micro-level resource allocation, paying attention to allocating specific computing, storage, and network resources to specific container instances, such as allocating a specific number of CPUs, memory size, and network bandwidth to a container instance of a certain EDA tool. (3) Different allocation criteria: The hardware resource scheduling and management module 112 mainly allocates resources based on the resource requirements of the task to be executed and the current hardware resource usage data, and needs to comprehensively consider the expected resource usage of the task and the overall usage of hardware resources. When allocating resources, the computing base 131 focuses more on allocating resources based on the actual running requirements of the container instance and the preset resource limits, based on the resource requests and limitations of the specific task during runtime.

[0044] The aforementioned hardware resource scheduling and management module 112 is further configured to: arbitrate the resource allocation order based on the task priority and deadline of each task when multiple tasks to be executed simultaneously request hardware resources and hardware resources are insufficient, and allocate hardware resources to the tasks to be executed in sequence according to the arbitration result. It is understood that during task execution, multiple tasks to be executed may simultaneously request hardware resources, while available hardware resources may be insufficient to meet the immediate needs of all tasks. Without an effective coordination mechanism, such resource competition may lead to critical tasks failing to complete on time due to resource allocation delays, or even causing task queue blockage. The arbitration mechanism in the above scheme, by introducing task priority and deadline as decision-making criteria, ensures the orderly and reasonable allocation of resources, prioritizing the execution of high-priority and urgent deadline tasks, avoiding blind and unbalanced resource allocation, thereby improving the overall efficiency and reliability of the system. The implementation method of the aforementioned hardware resource scheduling and management module 112 arbitrating the resource allocation order based on the task priority and deadline of each task to be executed may include: the hardware resource scheduling and management module 112 obtaining the task priority and deadline information of the tasks to be executed. Based on the acquired information, tasks are sorted from highest to lowest priority; for tasks with the same priority, they are further sorted from earliest to latest due date. Hardware resources are allocated to tasks in order of sorting. For tasks whose resource requirements cannot be met, the hardware resource scheduling and management module 112 can delay their execution, waiting for subsequent resource release or adjustment.

[0045] The aforementioned hardware resource scheduling and management module 112 is also used to: collect the resource utilization rate of each hardware node in the hardware layer; and, when the resource utilization rate of a hardware node is higher than a preset upper limit threshold, migrate container instances on the hardware node to a target node; wherein, the target node is a hardware node whose resource utilization rate is lower than a preset lower limit threshold. The scheme for the aforementioned hardware resource scheduling and management module 112 to collect hardware node resource utilization rate can be as follows: the hardware resource scheduling and management module 112 can collect the resource utilization rate of hardware nodes in real time through monitoring components deployed in the hardware layer. Specifically, the hardware resource scheduling and management module 112 can use indicators such as performance counters, average load, and memory usage, and periodically obtain these indicators through polling or interrupt mechanisms to calculate the resource utilization rate. In addition, the hardware resource scheduling and management module 112 can also monitor network bandwidth usage through the management interface of network devices, thereby gaining a comprehensive understanding of the resource utilization rate of hardware nodes. The method for the aforementioned hardware resource scheduling and management module 112 to migrate container instances on hardware nodes to target nodes can be as follows: when the resource utilization rate of the source hardware node exceeds a preset upper limit threshold, the hardware resource scheduling and management module 112 initiates the container instance migration process. Select the target hardware node according to the preset strategy, ensuring that the resource utilization of the target node is below the preset lower threshold. Container orchestration tools (such as Kubernetes) can be used to perform migration operations through their built-in migration mechanisms. After migration, update the resource allocation information to ensure that the container instance receives appropriate resource support on the target node, thereby achieving load balancing.

[0046] Factors to consider when setting the preset upper and lower thresholds include: (1) Hardware resource characteristics and capacity: The total amount and distribution of resources of each node in the hardware layer can be comprehensively examined, including the number of CPU cores, memory capacity, storage space and network bandwidth. At the same time, it is necessary to analyze whether the distribution of resources among different nodes is uniform. For systems with uneven resource distribution, a more stringent upper threshold should be set for nodes with tight resources to avoid local resource overload. In addition, the resource redundancy design of the system can also be considered. When the resource redundancy is low, the upper threshold should be appropriately reduced so that the migration mechanism can be triggered in time when the resource utilization rate is high to prevent task execution from being blocked. Conversely, if the resource redundancy is high, the upper threshold can be appropriately increased to reduce unnecessary migration operations and improve system operating efficiency. (2) Task load characteristics: The type, priority, execution frequency and duration of tasks can be considered. For high-priority tasks that run critical business, it should be ensured that the node where it is located has sufficient resource space, and a relatively low upper threshold should be set to prioritize its execution. For low-priority tasks, the upper threshold can be appropriately increased. For tasks with large and unpredictable resource demand, it is recommended to set a lower upper threshold so as to quickly respond to changes in its resource demand and avoid task failure due to insufficient resources. For nodes with frequent and short-duration tasks, a slightly higher upper threshold can be set to reduce migration frequency and improve the continuity of task execution. For tasks with longer execution times, in order to avoid occupying resources for a long time and affecting the execution of other tasks, the upper threshold of the node should be appropriately reduced. (3) System stability and performance requirements: The threshold can be determined based on the system's reliability requirements. For systems with high reliability requirements, a lower upper threshold and a higher lower threshold should be set so that measures can be taken quickly when resource utilization is abnormal to ensure the stable operation of the system. For tasks or systems that are sensitive to performance, reasonable thresholds need to be set. In scenarios with high performance requirements, the upper threshold should be reduced to avoid performance degradation caused by resource contention, while a suitable lower threshold should be set to ensure that tasks have sufficient resources to achieve optimal performance. (4) Historical data and experience: The historical load data of the system can be analyzed, including resource usage in different time periods and different business scenarios. Based on historical load patterns, the changing trend of resource demand can be predicted more accurately, thereby setting reasonable thresholds. The experience and lessons learned in setting thresholds can also be referenced to understand the actual operating effect of the system under different threshold settings, including key indicators such as task execution success rate and resource utilization. We can summarize the appropriate threshold setting range for the current system and learn from successful experiences to optimize the threshold configuration.

[0047] The aforementioned business layer 110 also deploys an environment configuration management module 113, used for: determining the operating parameters of the task to be executed based on the process node and EDA tool version information; and injecting the operating parameters into a container instance to drive the EDA tool to execute the task according to the operating parameters. The operating parameters of the task to be executed refer to the configuration information required by the EDA tool when executing a specific design task, covering process corners (such as temperature and voltage), simulation accuracy, timing constraints, resource allocation (such as memory limits), etc. These parameters ensure that the tool runs according to predetermined conditions. The scheme by which the aforementioned hardware resource scheduling management module 112 determines the operating parameters of the task to be executed based on the process node and EDA tool version information may include: the environment configuration management module 113 retrieves the corresponding operating parameters from the local database based on the process node and EDA tool version information of the task to be executed. By matching the process node and tool version combination, the module obtains a specific set of parameters, including simulation accuracy and timing constraints, which have been verified to ensure the accuracy and efficiency of the design task. The hardware resource scheduling and management module 112 described above can inject runtime parameters into container instances by using container orchestration tools to write runtime parameters into the container instance's environment variables or configuration files. When the container instance starts, the EDA tool reads these parameters and executes tasks accordingly.

[0048] The aforementioned business layer 110 also deploys an IP core management module 114, a PDK management module 115, and a LIC management module 116, wherein: the IP core management module 114 is used to maintain the IP core library and to perform retrieval, access control, and compliance verification of the IP cores; wherein, the IP core library includes the functional parameters, applicable processes, performance indicators, and version information of the IP cores; the PDK management module 115 is used to maintain the PDK library and to perform version control and access control of the PDKs; wherein, the PDK library includes process rules, device models, and layer definition information; the LIC management module 116 is used to maintain the license library and to perform validity period monitoring and access control of the licenses; wherein, the license library includes the license type, license validity period, and license scope of EDA tools and IP cores. The main functions of the aforementioned IP core management module 114 include: (1) IP core library maintenance: the IP core management module 114 is responsible for maintaining a library containing various IP cores, which records in detail the functional parameters, applicable processes, performance indicators, and version information of each IP core. Functional parameters cover the input / output characteristics, interface standards, and resource usage of the IP core; applicable processes clearly define the manufacturing process nodes that the IP core can support; performance indicators include power consumption, latency, and area estimation; version information ensures that designers can trace and compare different versions of the IP core and select the version that best suits the current design requirements. (2) IP core retrieval: The IP core management module 114 provides efficient retrieval functions, allowing designers to quickly locate the required IP core through multiple dimensions such as keywords, process nodes, and performance requirements. The retrieval results not only display the basic information of the IP core but also provide its compatibility under different processes and historical usage records to assist in design decisions. (3) Access control: The IP core management module 114 implements a strict access control mechanism. Access permissions can be assigned according to project requirements and user roles to ensure that only authorized personnel can use specific IP cores. This protects the intellectual property rights of the IP core and avoids design risks caused by misuse. (4) Compliance verification: Before using the IP core, the IP core management module 114 can automatically perform compliance verification to verify whether the use of the IP core complies with the scope and conditions of the authorization agreement. The verification content includes the authorization period, usage area and target process node, etc., to ensure the legality and standardization of the design process. The main functions of the above PDK management module 115 include: (1) PDK library maintenance: PDK management module 115 is responsible for maintaining a comprehensive PDK library, which contains process design kits corresponding to various process technologies. Each PDK contains detailed process rules, device models and layer definition information to ensure that designers can access accurate and verified process data. Process rules define the design constraints that must be followed when manufacturing chips, device models provide electrical characteristic descriptions of basic components such as transistors, and layer definition information clarifies the layout and connection method of each physical layer in the chip manufacturing process. (2) Version control: PDK management module 115 implements strict version control for the PDK library.Whenever the process is updated or improved, the module will promptly incorporate the new PDK version and record the details of the changes between versions. This ensures that designers can use the latest PDK that matches the target manufacturing process, while retaining historical versions to support the continuous maintenance of legacy designs. (3) Access control: The PDK management module 115 implements role-based access control to ensure that only authorized users can access specific PDKs. This prevents the unauthorized use of sensitive process information and protects the intellectual property rights of semiconductor manufacturers. Design teams can apply for access to the corresponding PDKs according to project needs and obtain the right to use them after approval. (4) Compatibility verification: Before the PDK is released or updated, the PDK management module 115 will perform compatibility verification with mainstream EDA tools. This ensures that designers can seamlessly use the PDK for design work on the selected EDA platform and avoid design errors or efficiency losses caused by incompatibility between tools and processes. The main functions of the above-mentioned LIC management module 116 include: (1) License library maintenance: The LIC management module 116 is responsible for maintaining a comprehensive license library, which records the authorization information of all EDA tools and IP cores in detail. Each license entry includes the license type (e.g., node locking, concurrent use), license validity period, and license scope (e.g., the number of users allowed, geographical restrictions, etc.). This ensures that the use of all software resources has a clear authorization basis. (2) Validity period monitoring: The LIC management module 116 continuously monitors the validity period of the license and issues renewal reminders in advance through an automated mechanism to ensure that the license is updated in time before it expires. For expired licenses, the module will automatically restrict their use to prevent legal risks caused by the use of invalid licenses. (3) Access control: The LIC management module 116 implements a strict access control mechanism to restrict access to and use of software resources according to the license's authorization scope. This includes controlling the maximum number of users who can access a specific tool at the same time, restricting the use of the tool in a specific geographical area, and preventing unauthorized users from accessing protected resources. Through collaboration with the user management system, the LIC management module 116 ensures that only authorized users can use software resources within the specified scope.

[0049] The aforementioned business layer 110 also deploys an EDA tool management module 117, which is used to: maintain the EDA tool library and perform version control, compatibility verification, and usage permission management for EDA tools; wherein, the EDA tool library includes the functional description, applicable design stage, supported process node, and version information of the EDA tools. The main functions of the aforementioned EDA tool management module 117 include: (1) Version control: The EDA tool management module 117 is responsible for maintaining a library containing multiple versions of EDA tools, recording the functional description, applicable design stage, supported process node, and version information of each tool. The module supports version updates and rollbacks of tools, and designers can select specific versions according to project requirements to ensure the consistency and repeatability of the design environment. (2) Compatibility verification: The EDA tool management module 117 can perform compatibility verification on the EDA tools in the library to verify the compatibility between different tool versions and between tools and process nodes. By using automated scripts to detect the input and output interfaces, data formats, and dependencies of the tools, it ensures the normal operation of the tools under specific processes. The verification results are stored in the database for designers to query and refer to. (3) Access Control: The EDA Tool Management Module 117 can adopt role-based access control to restrict access to specific EDA tools. Administrators can assign corresponding tool usage permissions to different user roles to ensure the compliant use of tools. The EDA Tool Management Module 117 can also monitor tool usage, record usage logs, provide data support for license management, and avoid tool abuse or resource waste due to improper permissions.

[0050] The aforementioned platform layer 130 also deploys a dedicated acceleration module 132, used to call upon a dedicated instruction set and parallel computing units to accelerate computation of the task to be executed. The aforementioned dedicated instruction set is a processor extension instruction set customized for EDA algorithms, with its opcodes, execution semantics, and hardware pathways designed specifically for typical computational modes such as logical cone traversal, timing graph relaxation, or matrix sparse operations. Each instruction can directly complete multiple arithmetic-logical OR memory access operations required by traditional general-purpose instruction sequences during execution, thereby reducing the number of instruction issues and intermediate register usage, lowering pipeline congestion probability, and shortening the number of clock cycles per task. The aforementioned parallel computing units consist of multiple homogeneous or heterogeneous computing cores, coupled through an on-chip high-bandwidth bus and shared cache, supporting both data-level parallelism and task-level parallelism modes. In data-level parallelism mode, the unit slices the circuit netlist or simulation matrix at a fixed granularity and distributes it to each core for simultaneous processing, and uses reduction hardware to merge the results. In task-level parallel mode, the parallel computing unit schedules multiple independent subtasks to different cores simultaneously based on the EDA task graph dependencies, and completes concurrent computation with a dedicated instruction set, significantly shortening the overall execution time. The working principle of the dedicated acceleration module 132 is as follows: After receiving an acceleration request from the business layer 110, the dedicated acceleration module 132 first extracts the computationally intensive subgraphs in the EDA task to be executed, classifies them into three typical modes: logical cone traversal, temporal relaxation, or matrix sparse operation, and generates corresponding acceleration descriptors. The descriptor contains data base address, scale parameters, and operation type encoding, and is then written into the module's internal command queue, waiting for the scheduler to allocate execution resources. The scheduler uses a dynamic priority strategy; when it detects an idle pipeline in the parallel computing unit, it retrieves the acceleration descriptor from the command queue and maps it to an available computing core. Each core has a built-in dedicated instruction set decoder that can recognize and execute extended instructions: for example, the "logical cone parallel traversal" instruction completes multi-node fan-in / fan-out queries, Boolean evaluations, and result write-back in a single issue, replacing more than ten micro-operations required by traditional general instruction sequences, significantly shortening the single-task execution cycle. Parallel computing units are coupled to a shared cache via an on-chip high-bandwidth ring bus. The scheduler slices the input dataset at the cache line level and broadcasts it to the local storage of each core via the bus. Intermediate results are merged between cores using reduction hardware. During execution, a dedicated acceleration module 132 continuously monitors core utilization and cache hit rate. If a load imbalance is detected, it dynamically adjusts the data slice size or reallocates cores to ensure that all computing units are always under high load, thereby improving the overall computing power utilization.Understandably, the dedicated acceleration module 132 deployed on platform layer 130 can be deeply adapted to the architecture of domestic central processing units. By analyzing the computational characteristics of logical cone traversal, timing relaxation, and matrix sparse operations in EDA tasks, the microarchitecture of domestic CPUs is extended, adding dedicated instruction sets and configurable parallel computing units. At the same time, the compiler backend is optimized, enabling the aforementioned dedicated instruction sets to achieve single-clock-cycle multi-operation execution in the domestic CPU pipeline, thereby increasing the computing power utilization of key EDA sub-tasks to over 90% and shortening the chip design verification cycle.

[0051] To facilitate understanding of the working principle of the collaborative management system 100 for EDA all-in-one machines described above, this application embodiment also provides a specific implementation scheme of the collaborative management system 100 for EDA all-in-one machines in a certain application scenario. Specifically, please refer to... Figure 2The collaborative management system 100 for EDA all-in-one machines includes: a business layer 110, an application layer 120, a platform layer 130, and a hardware layer 140, configured to use a hybrid communication method of layered and cross-layer communication for communication connections. The hardware layer 140 provides fundamental support and mainly includes: a high-performance server cluster to provide powerful computing power to support parallel processing of complex EDA tasks; a high-speed storage system with a distributed architecture to ensure low-latency read / write and security redundancy of massive design data; and 10 Gigabit or even 400G high-speed switches to build a low-latency network for high-speed data interaction between servers and storage, ensuring smooth cross-node task collaboration. The platform layer 130 serves as a bridge between the upper and lower layers. The computing base 131 uses containerization technology to achieve elastic resource scheduling and dynamically allocate computing power to meet peak demands; the data base integrates design data lifecycle management, supporting version traceability and multi-tool data sharing; a dedicated acceleration module 132 uses a dedicated instruction set and parallel computing units to accelerate tasks to be executed; standardized API interfaces simplify tool integration and achieve seamless connection between the platform and application layers; and the acceleration library provides FPGA / GPU acceleration, instruction set acceleration, and caching acceleration functions. Application Layer 120 is customer-centric and can flexibly deploy various EDA tools. These tools cover circuit schematic and layout design tools, digital / analog pre- and post-simulation tools, logic synthesis and timing analysis tools, and placement, routing, and physical verification tools. It also supports reliability analysis (such as EM / IR checks) and PDK process data package integration, forming a full-process support capability from design to tape-out, meeting chip design needs in different scenarios. Business Layer 110 focuses on the control of the entire design process, including analog chip design (from specification definition, circuit design to layout generation and verification) and digital chip design (covering RTL design, functional verification, physical implementation, etc.). Business Layer 110 deploys an environment configuration management module 113 and a process management expert subsystem. The environment configuration management module 113 can preset optimal parameters for different process nodes and tool combinations, dynamically adapting to design requirements. The process management expert subsystem manages EDA tools, IP, PDK, and hardware resources, and integrates industry experience to provide process template reuse, abnormal node warnings, and optimization suggestions, improving design efficiency and success rate.

[0052] Please see Figure 3The above-mentioned process management expert subsystem mainly includes: project and resource configuration management module, automated simulation management module 111, hardware resource scheduling management module 112, environment configuration management module 113, IP core management module 114, PDK management module 115, LIC management module 116 and EDA tool management module 117. Among them, the project and resource configuration management module focuses on the overall planning and resource planning of the entire chip design process. Its main functions include: (1) Project information integration: It supports the input of basic information such as project name, R&D cycle, target process node, participating team and core person in charge, forming a project archive, which is convenient for tracking project progress and responsibility division. (2) Resource configuration planning: According to project requirements (such as design stage, simulation task complexity), it pre-allocates and dynamically adjusts the required software tools (EDA tools), hardware equipment (server, CPU, memory), IP cores and PDK resources to avoid resource idleness or conflict and improve resource utilization efficiency. (3) Progress and milestone management: Link key milestones of each stage of the project (such as front-end design, back-end layout and routing, verification), track progress in combination with resource allocation, issue warnings when resources are insufficient or progress is lagging, and assist managers in making timely decisions. EDA tool management module 117 mainly provides systematic version control and usage management for EDA tools relied upon in chip design. Its main functions include: (1) Tool library management: Manage diverse EDA tools and version numbers, record tool function descriptions, applicable design stages (front-end logic synthesis, back-end physical verification, etc.) and supported process nodes, so as to facilitate designers to quickly search and select. (2) Version control and compatibility management: Strictly manage the version iteration of tools, record the release time, update content (such as function optimization, bug fixes) and compatibility information (such as compatibility with specific IP, PDK or hardware environment) of each version. The design team can choose a stable version according to project requirements to avoid design errors caused by version incompatibility. (3) Access Permissions and Log Recording: Set access permissions for different users / teams to EDA tools (such as viewing, downloading, and installing), and record tool usage logs (including user, usage time, version number, and operation content) to facilitate tracing tool usage and troubleshooting. IP Core Management Module 114 is used to establish and maintain an IP core library, which includes self-developed IPs, third-party licensed IPs (such as processor cores and interface IPs), and open-source IPs. It records the functional parameters, applicable processes, performance indicators (such as power consumption and timing), version information, and reuse history of the IPs. It supports IP classification retrieval (such as classification by function into computing, storage, and interface types), access control (such as which projects can be reused), and compliance verification (such as patent authorization status). PDK Management Module 115 is used to establish and maintain a PDK library. PDK is a key data link between design and manufacturing, containing information such as process rules, device models, and layer definitions.The PDK library can store PDK files from different foundries and process nodes, record their versions, release dates and compatible EDA tool versions, and ensure that designers use PDKs that match the manufacturing process to avoid design and production disconnect. The LIC management module 116 is used to track the license file information of EDA tools, IP cores and other resources, including license type (such as node license, concurrent license), validity period, supported tool / IP version and license scope (such as only for specific teams). Set up license expiration warning to avoid design interruption due to license failure, and at the same time, calculate license usage efficiency and optimize license procurement strategy. The hardware resource scheduling management module 112 can provide intelligent scheduling and monitoring of hardware resources for simulation, verification and other tasks with high computing power requirements in chip design. The main functions include: (1) Hardware resource monitoring: Real-time collection of hardware status of servers, workstations and other devices, including indicators such as CPU utilization, memory usage, storage capacity and network bandwidth, and display of resource load through a visual dashboard to help managers grasp resource bottlenecks. (2) Dynamic scheduling and allocation: Based on the priority of project tasks (such as urgent verification tasks and regular simulation tasks) and resource requirements (such as simulation tasks with large memory requirements), hardware resources are automatically or manually allocated. For example, when a project initiates a high-priority simulation task, the system can temporarily allocate CPU and memory resources from idle servers. After the task is completed, the resources are released for use by other tasks, improving resource turnover. (3) Load balancing and conflict resolution: Through load balancing algorithms, concentrated occupation of hardware resources is avoided (such as a server CPU being fully loaded for a long time), ensuring the fairness of resource allocation. When multiple tasks compete for the same resource, conflict arbitration is carried out according to the rules such as task priority and deadline, ensuring the smooth execution of critical tasks. (4) Resource usage statistics and optimization: Record the hardware resource usage time and resource consumption of each team / project, generate statistical reports, provide a basis for resource expansion, hardware procurement and cost accounting, and help refine management. The automated simulation management module 111 is used to automate the entire simulation process. Its main functions include: (1) Automated orchestration of simulation tasks: It supports preset simulation process templates (such as RTL simulation, timing analysis, power consumption simulation), associates the required EDA tool versions, test case sets and hardware resource requirements, triggers batch simulation tasks with one click, and automatically calls the specified resources to execute. (2) Intelligent analysis of results: After the simulation is completed, it automatically parses the log data, identifies the error type (such as timing violation, logic error) through the rule engine, locates the problematic module and critical path, and generates a visual report (including error trend chart and module failure rate statistics). (3) Iterative closed-loop management: It automatically pushes optimization suggestions (such as constraint adjustment schemes and code modification guidelines) for high-frequency problems, supports setting iteration trigger conditions (such as when the error rate exceeds the threshold), and automatically initiates a new round of simulation verification to form a closed loop of "simulation-analysis-optimization-re-verification", reducing the cost of manual intervention and accelerating design convergence.

[0053] For the other functions and implementation methods of the above-mentioned automated simulation management module 111, hardware resource scheduling management module 112, environment configuration management module 113, IP core management module 114, PDK management module 115, LIC management module 116 and EDA tool management module 117, please refer to the above introduction to the collaborative management system 100 for EDA all-in-one machine, which will not be repeated here.

[0054] In the above scheme, the data flow, control flow and dependencies within the collaborative management system 100 for the EDA appliance may include: (1) Automated simulation management function; The data flow includes: The automated simulation management module 111 first reads the simulation configuration information and resource requirement information from the simulation process template of the simulation task to be executed, generates a resource request description based on the resource requirement information, and writes the template identifier of the simulation process template and the container instance identifier returned by the computing base 131 into the environment variables of the container instance. After the EDA tool completes the simulation task to be executed, the automated simulation management module 111 obtains and parses the simulation log output by the container instance, determines the simulation error type, error module and critical path information, and generates simulation error analysis results. If the error index exceeds the preset error index threshold, the automated simulation management module 111 updates the simulation configuration information based on the simulation error analysis results, and re-executes the simulation task to be executed based on the updated simulation configuration information. The control flow includes: The automated simulation management module 111 controls the entire process of the simulation task from resource application to execution to result analysis. The automated simulation management module 111 first parses the simulation process template to obtain the necessary information, then generates a resource request description and sends it to the computing base 131. After the container instance is created and started, the automated simulation management module 111 guides the EDA tool to execute the simulation task through environment variables. After the task is completed, the automated simulation management module 111 analyzes the simulation results. If a problem is found, it triggers the process of updating the simulation configuration and re-executing the task. The dependencies include: the automated simulation management module 111 depends on the simulation process template provided by the business layer 110 to obtain simulation configuration information and resource requirement information. The automated simulation management module 111 depends on the computing base 131 of the platform layer 130 to create the container instance and allocate resource quotas. In addition, the automated simulation management module 111 depends on the EDA tool in the application layer 120 to execute the simulation task and depends on the container instance to obtain simulation logs for result analysis. (2) Hardware resource scheduling management function; the data flow includes: the hardware resource scheduling management module 112 collects the resource usage data of the hardware resources and allocates hardware resources for the task to be executed in the hardware layer 140 based on the resource requirement information and resource usage data of the task to be executed before the task to be executed is started. When multiple tasks simultaneously request hardware resources and resources are insufficient, the hardware resource scheduling and management module 112 arbitrates the resource allocation order based on the task priority and deadline of each task, and allocates hardware resources to the tasks in sequence according to the arbitration result. In addition, the hardware resource scheduling and management module 112 also collects the resource utilization rate of each hardware node in the hardware layer, and when the resource utilization rate of a hardware node exceeds a preset upper threshold, it migrates the container instances on the hardware node to a target node with a resource utilization rate below a preset lower threshold.The control flow includes: the hardware resource scheduling and management module 112, which monitors hardware resource usage and allocates and arbitrates resources based on task resource requirements and priorities. Before task startup, the hardware resource scheduling and management module 112 ensures tasks receive sufficient resources and allocates resources reasonably through an arbitration mechanism when resources are insufficient. Simultaneously, the hardware resource scheduling and management module 112 also monitors the resource utilization of hardware nodes and migrates container instances when necessary to achieve load balancing. Dependencies include: the hardware resource scheduling and management module 112 relies on hardware resource usage data provided by the hardware layer 140 for real-time monitoring of resource usage. The hardware resource scheduling and management module 112 relies on the platform layer 130 to create and manage container instances, ensuring interaction with container instances during resource allocation and migration. Furthermore, the hardware resource scheduling and management module 112 relies on resource requirement and priority information of tasks to be executed provided by the business layer 110 to perform reasonable resource allocation and arbitration. (3) Environment configuration management function; Data flow includes: The environment configuration management module 113 determines the running parameters of the task to be executed based on the process node and EDA tool version information, and injects the running parameters into the container instance to drive the EDA tool to execute the task according to the running parameters. Control flow includes: Before task execution, the environment configuration management module 113 determines appropriate running parameters based on the process node and EDA tool version, and injects these parameters into the container instance to ensure that the EDA tool can run under the correct configuration. Dependencies include: The environment configuration management module 113 depends on the process node and EDA tool version information of the task to be executed provided by the business layer 110 to determine appropriate running parameters. The environment configuration management module 113 depends on the platform layer 130 to create and manage the container instance to ensure that the running parameters can be correctly injected into the container instance. In addition, the environment configuration management module 113 depends on the EDA tool in the application layer 120 to ensure that the tool can correctly execute the task according to the configured running parameters. (4) IP core management, PDK management, and LIC management functions; the data flow includes: IP core management module 114 maintains the IP core library and performs retrieval, access control, and compliance verification of IP cores. PDK management module 115 maintains the PDK library and performs version control and access control of PDKs. LIC management module 116 maintains the license library and performs validity monitoring and access control of licenses. The control flow includes: IP core management module 114, PDK management module 115, and LIC management module 116 are respectively responsible for managing the use of IP cores, PDKs, and licenses to ensure that their use complies with the licensing agreement and design requirements. These modules ensure the legality and continuity of the design process through functions such as retrieval, version control, access control, and compliance verification.Dependencies include: IP core management module 114, PDK management module 115 and LIC management module 116 rely on the design requirements and authorization information provided by the business layer 110 to ensure that the use of IP cores, PDKs and licenses complies with design requirements and authorization agreements. These modules rely on the platform layer 130 to ensure the correct use of IP cores, PDKs and licenses, for example through access control and compliance verification. In addition, these modules rely on EDA tools in the application layer 120 to ensure the correct use and management of IP cores, PDKs and licenses in the design process. (5) EDA tool management function; Data flow includes: EDA tool management module 117 maintains the EDA tool library and performs version control, compatibility verification and usage permission management for EDA tools. Control flow includes: EDA tool management module 117 is responsible for managing the version and use of EDA tools, ensuring that the EDA tools used in the design process have clear version records and traceability capabilities, and avoiding design errors and duplication of work caused by inconsistent tool versions. Dependencies include: EDA tool management module 117 relies on design requirements and authorization information provided by business layer 110 to ensure that the use of EDA tools complies with design requirements and authorization scope. EDA tool management module 117 relies on application layer 120 to ensure the correct deployment and use of EDA tools. In addition, EDA tool management module 117 relies on platform layer 130 to manage container instances, ensuring that EDA tools can run in the correct environment.

[0055] Please see Figure 4 Based on the same inventive concept, this application also provides a collaborative management method for an EDA appliance, comprising: step S210: reading simulation configuration information and resource requirement information from the simulation process template of the simulation task to be executed; step S220: generating a resource request description based on the resource requirement information; step S230: creating a container instance based on the simulation configuration information and returning the container instance identifier; step S240: allocating resource quotas to the container instance based on the resource request description; step S250: writing the template identifier of the simulation process template and the container instance identifier into the environment variables of the container instance; step S260: after the container instance starts, executing the simulation task to be executed based on the template identifier in the environment variables. It is understood that the above-described collaborative management method for an EDA appliance can achieve any function of the above-described collaborative management system 100 for an EDA appliance. For simplification, please refer to the above-described system embodiments for specific implementation methods of each function in the method embodiments, which will not be repeated here.

[0056] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A collaborative management system for EDA all-in-one machines, characterized in that, include: The business layer, application layer, platform layer, and hardware layer are as follows: The business layer, the application layer, the platform layer, and the hardware layer are configured to communicate using a hybrid communication method that combines layered and cross-layer communication. The hardware layer is used to provide hardware resources and deploy container instances; The platform layer is used to receive instance management instructions sent by the business layer, perform instance management, resource quota allocation and instance lifecycle control of the hardware resources provided by the hardware layer, and provide the container instance runtime environment to the application layer. The application layer is used to run the corresponding version of the EDA tool in the container instance created by the platform layer, and to send the running results back to the business layer. The business layer is used to send the instance management instructions to the platform layer and receive the running results returned by the application layer, and to perform resource planning, template configuration, task scheduling and result management for the entire chip design process of the EDA all-in-one machine. The business layer is equipped with an automated simulation management module, and the platform layer is equipped with a computing base, wherein: The automated simulation management module is used to read simulation configuration information and resource requirement information from the simulation process template of the simulation task to be executed, and generate a resource request description based on the resource requirement information; and to write the template identifier of the simulation process template and the container instance identifier returned by the computing platform into the environment variables of the container instance. The computing platform is configured to receive the resource request description and the simulation configuration information, create the container instance in the hardware layer based on the simulation configuration information, and return the container instance identifier of the container instance to the automated simulation management module; and allocate resource limits to the container instance based on the resource request description from the hardware resources provided in the hardware layer. The EDA tool is used to execute the simulation task to be executed based on the template identifier in the environment variables after the container instance is started.

2. The collaborative management system for EDA all-in-one machines according to claim 1, characterized in that, The automated simulation management module is also used for: After the EDA tool completes the simulation task to be performed, the simulation results are obtained; Calculate at least one performance index based on the simulation results; A target performance index is determined from the performance indicators; wherein the target performance index is used to characterize the performance index that does not meet the preset performance index threshold; Based on the target performance indicators, design optimization suggestions are generated.

3. The collaborative management system for EDA all-in-one machines according to claim 2, characterized in that, The automated simulation management module is also used for: Error indicators are calculated based on simulation error analysis results, and the error indicators are compared with preset error indicator thresholds. When the error indicators exceed the preset error indicator thresholds, the simulation configuration information is updated based on the simulation error analysis results. Furthermore, the simulation task to be executed is re-executed based on the updated simulation configuration information; wherein, the simulation error analysis results are obtained by means of: after the EDA tool completes the simulation task to be executed, the automated simulation management module obtains and parses the simulation logs output by the container instance, determines the simulation error type, the error module and the critical path information, and generates the simulation error analysis results.

4. The collaborative management system for EDA all-in-one machines according to claim 1, characterized in that, The computing base is also used for: Real-time monitoring of the resource utilization rate of the hardware layer; when the resource utilization rate exceeds the preset expansion threshold, adding a new container instance to the hardware layer and allocating the corresponding resource limit. And, when the resource utilization rate is less than a preset shrinkage threshold, the container instance is released.

5. The collaborative management system for EDA all-in-one machines according to claim 1, characterized in that, The business layer also deploys a hardware resource scheduling and management module, used for: Collect resource usage data of the aforementioned hardware resources; Furthermore, before the task to be executed is started, hardware resources are allocated to the task at the hardware layer based on the resource requirement information of the task to be executed and the resource usage data.

6. The collaborative management system for EDA all-in-one machines according to claim 5, characterized in that, The hardware resource scheduling and management module is also used for: When multiple tasks to be executed simultaneously request the hardware resources and the hardware resources are insufficient, the resource allocation order is arbitrated based on the task priority and deadline of each task to be executed, and the hardware resources are allocated to the tasks to be executed in sequence according to the arbitration result.

7. The collaborative management system for EDA all-in-one machines according to claim 5, characterized in that, The hardware resource scheduling and management module is also used for: Collect the resource utilization rate of each hardware node in the hardware layer; And, when the resource utilization rate of the hardware node is higher than a preset upper limit threshold, the container instance on the hardware node is migrated to the target node; wherein, the target node is the hardware node whose resource utilization rate is lower than a preset lower limit threshold.

8. The collaborative management system for an EDA all-in-one machine according to any one of claims 1 to 7, characterized in that, The business layer also deploys an environment configuration management module, used for: Based on the process node of the task to be executed and the version information of the EDA tool, the running parameters of the task to be executed are determined; In addition, the runtime parameters are injected into the container instance to drive the EDA tool to execute the task to be executed according to the runtime parameters.

9. The collaborative management system for an EDA all-in-one machine according to any one of claims 1 to 7, characterized in that, The service layer also deploys an IP core management module, a PDK management module, and a LIC management module, among which: The IP core management module is used to maintain the IP core library and to perform IP core retrieval, access control, and compliance verification; wherein, the IP core library includes the functional parameters, applicable processes, performance indicators, and version information of the IP cores; The PDK management module is used to maintain the PDK library and perform version control and access control on the PDK; wherein, the PDK library includes process rules, device models and layer definition information; The LIC management module is used to maintain the license repository and monitor the validity period and control access of licenses; wherein, the license repository includes the license type, license validity period and license scope of the EDA tool and the IP core.

10. The collaborative management system for an EDA all-in-one machine according to any one of claims 1 to 7, characterized in that, The business layer also deploys an EDA tool management module, used for: Maintain the EDA tool library and perform version control, compatibility verification, and access control for the EDA tools; wherein, the EDA tool library includes the functional description, applicable design stage, supported process node, and version information of the EDA tools.

11. The collaborative management system for an EDA all-in-one machine according to any one of claims 1 to 7, characterized in that, The platform layer also deploys a dedicated acceleration module for: It invokes a dedicated instruction set and parallel computing units to accelerate the computation of the task to be executed.

12. A collaborative management method for an EDA all-in-one machine used in the system described in any one of claims 1 to 11, characterized in that, The method includes: Read the simulation configuration information and resource requirement information from the simulation process template of the simulation task to be executed; Generate a resource request description based on the resource demand information; A container instance is created based on the simulation configuration information, and the container instance identifier of the container instance is returned; Based on the resource request description, allocate resource limits to the container instance; Write the template identifier of the simulation process template and the container instance identifier into the environment variables of the container instance; After the container instance starts, the simulation task to be executed is performed based on the template identifier in the environment variables.

Images