Script language level multi-database fusion electronic design automation process dynamic management method and system

Abstract

The invention provides a script language level multi-database fusion electronic design automation process dynamic management method and system, and the method comprises the steps: responding to a script language command, dynamically binding an electronic design automation (EDA) component required by the command to a shared main data model, and enabling the EDA component to access design data in the main data model; during the binding period of the EDA component and the main data model, monitoring the data change of the main data model through an event callback mechanism, triggering a callback function of the EDA component, and maintaining the state consistency of the EDA component and the main data model; before the binding between the EDA component and the main data model is removed, establishing association between the business attribute generated by the EDA component and the corresponding design data object in the main data model; unbinding the EDA component and the main data model; and when the EDA component or other EDA components need to be bound again in subsequent response to other script language commands, the component recovers or inherits the previous working state by accessing the associated service attributes in the main data model.

Description

Technical Field

[0001] This invention belongs to the field of integrated circuit design automation technology, specifically relating to a scripting language-level multi-database integrated electronic design automation process dynamic management method and system. Background Technology

[0002] In the field of integrated circuit design automation (EDA), efficient process control and component collaboration are core prerequisites for ensuring chip design quality and efficiency. Current technologies primarily rely on traditional static binding and simple dynamic binding modes for the integration and scheduling of multiple components in EDA processes, which are ill-suited to the refined requirements of complex chip design flows. The static binding mode fixes all required EDA components to the entire process during initialization. Regardless of whether these components are actually invoked in subsequent stages, they continuously consume system memory resources. When processing large-scale chip design data, this not only leads to severe resource waste but also causes excessively high memory spikes, affecting the overall system stability. While the simple dynamic binding mode enables component loading and unloading, it is limited to the beginning and end of the component flow and cannot flexibly schedule components according to the actual needs of each subdivided business step. This makes it difficult to achieve finer-grained component control and fails to fundamentally solve the problem of unreasonable resource allocation.

[0003] Data sharing and interaction between components is another crucial aspect of the EDA workflow. In existing technologies, each component often maintains its own independent data model, lacking a unified collaboration mechanism. Data sharing is primarily achieved through two methods: data copying or transmission in a common data format. While data copying reduces parsing time, it generates a large amount of redundant data, exacerbating memory resource consumption, a problem particularly pronounced when processing high-density, large-scale chip design data. Transmission in a common data format requires data conversion using a writer and parser, increasing system complexity and performance overhead, and posing risks of data loss or format inconsistencies, severely impacting data accuracy. More importantly, the data models of different components are highly heterogeneous. Data sharing between components must be achieved through explicit interface calls. Interface design not only needs to adapt to differences in data infrastructure but also needs to address compatibility issues arising from component version iterations, leading to complex and inefficient data interaction logic between workflows, becoming a bottleneck restricting the overall performance improvement of the EDA workflow.

[0004] Furthermore, existing technologies lack comprehensiveness and refinement in the lifecycle management of EDA components, failing to achieve deep collaboration between component states and business processes and data infrastructure. Current lifecycle management focuses primarily on the loading and unloading of components themselves, without establishing a real-time response mechanism for component and data changes. When the data infrastructure is modified, loaded components cannot promptly detect and update their states, easily leading to inconsistencies between component states and business process states. This can cause EDA tool anomalies or hidden errors, affecting the reliability of design results. Simultaneously, existing technologies lack effective state retention mechanisms during component unbinding and rebinding, making it easy to lose important settings and intermediate calculation results. This not only requires reconfiguring parameters and repeating some calculation steps, increasing operational complexity and time costs, but may also affect business continuity due to parameter configuration deviations or missing intermediate results. Especially in complex chip design flows with frequent switching between multiple stages and components, this problem significantly reduces design efficiency and increases the probability of errors. Summary of the Invention

[0005] To address the shortcomings and deficiencies of existing technologies, such as limitations in resource allocation, insufficient lifecycle management, low data sharing efficiency, and lack of business continuity assurance, this invention provides a scripting language-level multi-database integrated dynamic management method and system for electronic design automation (EDA) processes. This method uses a scripting language as the driving force, constructs a shared master data model for the entire process, and associates it with professional databases at each stage. It achieves refined control of the EDA process through the innovative collaboration of three core mechanisms: First, a dynamic binding and unbinding mechanism, which intelligently triggers binding decisions based on script command categories, establishing associations between EDA components and the master data model as needed, reusing the binding relationships of the same data, and immediately unbinding and releasing resources after the process ends; second, an event callback and lifecycle synchronization mechanism, which introduces pre- and post-callbacks through the observer pattern to achieve bidirectional data change synchronization between components and the data model, ensuring consistency between their states; and third, a cross-component attribute management mechanism, which divides attributes into persistent attributes and business attributes, mounting them to corresponding objects in the master data model through associated indexes, avoiding data copying waste, and automatically restoring key settings and intermediate results when components are rebound. This invention achieves efficient data sharing without relying on common data format conversion, significantly optimizing system resource utilization and process execution efficiency, effectively ensuring business continuity, and possessing good maintainability and scalability. It can be adapted to new EDA components and application scenarios at a low cost. Actual testing shows that this solution significantly reduces peak memory usage, noticeably improves process execution efficiency, and achieves a fully guaranteed recovery rate for important settings and intermediate results.

[0006] The specific technical solution adopted by this invention to solve its technical problem is as follows:

[0007] A scripting language-level method for dynamic management of multi-database integrated electronic design automation processes, comprising:

[0008] In response to scripting language commands, the electronic design automation (EDA) components required by the command are dynamically bound to a shared master data model, enabling the EDA components to access the design data in the master data model.

[0009] During the binding of the EDA component with the master data model, an event callback mechanism is used to listen for data changes in the master data model, triggering the callback function of the EDA component to maintain the consistency of the state between the EDA component and the master data model.

[0010] Before unbinding the EDA component from the master data model, associate the business attributes generated by the EDA component with the corresponding design data objects in the master data model;

[0011] Unbind the EDA component from the master data model;

[0012] When subsequent responses to other scripting language commands require rebinding the EDA component or other EDA components, the component restores or inherits the previous working state by accessing the associated business attributes in the master data model.

[0013] Furthermore, the dynamic binding includes: triggering binding decisions according to the preset categories of script language commands; data loading commands do not trigger decisions, while data query and business operation commands trigger decisions; when multiple EDA components depend on the same design data, only the first component is bound, and subsequent components reuse the binding.

[0014] Furthermore, the event callback mechanism enables bidirectional data change synchronization and includes Pre callback and Post callback. The Pre callback is triggered before the operation is executed, and the Post callback is triggered after the operation is executed. The event callback mechanism is implemented using the observer pattern, which configures a corresponding observer for each type of object of the operation and registers the upper-layer business operation.

[0015] Furthermore, the attributes in the master data model include persistent attributes and business attributes. The persistent attributes reside in memory and are accessible to all EDA components. The business attributes are attached to the design data object through associated indexes, so that even after the EDA component is unbound, the business attributes are still associated with the design data object and can be accessed by subsequently bound EDA components.

[0016] Furthermore, the master data model is associated with the professional databases of each stage of the EDA process. After the EDA component is bound to the master data model, it is allowed to access the corresponding professional database data.

[0017] Furthermore, the scripting language is the TCL scripting language. Script commands are registered to the same TCL interpreter through a unified registration interface. During registration, the corresponding EDA components and data dependencies are declared. Before the command is distributed, it is bound according to the registration information and then distributed to the business execution.

[0018] Furthermore, the binding between the EDA component and the master data model is released, and the system memory resources occupied by the EDA component are released simultaneously.

[0019] Furthermore, when the subsequent bound EDA components are of different types, the component can access the business attributes attached to the preceding components through the master data model and inherit the previous working state related to the current operation.

[0020] Furthermore, the business attributes include intermediate results and configuration parameters generated during the execution of the EDA component.

[0021] Furthermore, a scripting language-level multi-database integrated electronic design automation process dynamic management system for implementing the method described above, the system comprising:

[0022] The master data model is used to store integrated circuit design data, persistent attributes, and attached business attributes, and is associated with professional databases at each stage;

[0023] The dynamic management module is configured to respond to script language commands, establish or unbind the electronic design automation (EDA) components from the master data model, and support binding reuse and resource release.

[0024] The event callback module is configured to achieve bidirectional data change synchronization through the observer pattern, triggering Pre and Post callbacks.

[0025] The attribute management module is configured to segment attribute types and mount business attributes through associated indexes, and supports cross-component attribute access and state recovery.

[0026] And a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method described above.

[0027] A non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0028] Compared to existing technologies, this invention and its preferred solution effectively solve the problem of limited resource allocation in existing EDA processes. By dynamically binding and unbinding components on demand, it achieves reasonable allocation and efficient utilization of system resources, avoiding resource occupation and excessive memory peaks during unused phases. In terms of reliability, by leveraging an event callback mechanism and a component lifecycle management framework, a real-time synchronization relationship is established between component states, business processes, and data models. This significantly reduces tool anomalies, process deviations, and result errors caused by inconsistent states, improving the operational stability of the EDA process. Data sharing efficiency is greatly optimized. Through a shared master data model across the entire process and a cross-component attribute mounting mechanism, traditional data copying and general format conversion methods are eliminated. This avoids redundant data occupation and performance overhead, reduces the risk of data loss or format inconsistencies, and simplifies the data interaction logic between components. Business continuity is fully guaranteed. When components are unbound and rebound, important settings and intermediate results can be accurately restored through the attribute management mechanism, eliminating the need to repeatedly perform redundant operations and ensuring smooth process transitions. Meanwhile, relying on the flexibility of scripting languages ​​and the collaborative design of core mechanisms, the solution has good maintainability and scalability, reducing the learning, review and modification costs for engineers. When dealing with changes in process requirements or integrating new EDA components, there is no need to make major modifications to the underlying code. Only the relevant interfaces and logic need to be adapted for seamless integration, and the cost of adapting to different application scenarios is lower. Attached Figure Description

[0029] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments:

[0030] Figure 1 This is an example diagram of the scripting language in an embodiment of the present invention;

[0031] Figure 2 This is a schematic diagram of a multi-database structure according to an embodiment of the present invention;

[0032] Figure 3 This is a schematic diagram of the structure after script-level fusion according to an embodiment of the present invention;

[0033] Figure 4 This is a schematic diagram of data interaction and process in an embodiment of the present invention. Detailed Implementation

[0034] To make the features and advantages of the present invention more apparent and understandable, specific embodiments are described below in detail:

[0035] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0036] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0037] To avoid ambiguity, this invention clarifies the following core terms:

[0038] Master Data Model (DB): A centralized data storage carrier shared throughout the entire process, storing persistent attributes and attached business attributes, and serving as the data interaction hub for all EDA components;

[0039] EDA tool components (such as PlaceDB, RouteDB, STA components): functional modules that implement specific business functions (layout, routing, timing analysis), which can contain temporary running states and interact with the master data model through dynamic binding;

[0040] Specialized database: A stage-specific data storage system that is paired with EDA tool components. It is only accessed during component binding and synchronizes with the master data model in real time.

[0041] Data Model / Data Module: Both refer to the Master Data Model (DB). They are used interchangeably for brevity, but their core functions are the same.

[0042] This invention aims to provide a scripting language-level multi-database fusion workflow technology. The goal is to address the limitations of existing EDA workflow management methods, including limitations in resource configuration, insufficient lifecycle management, low data sharing efficiency and resource waste, and inadequate business continuity assurance. By leveraging the flexible workflow control characteristics of scripting languages, combined with innovative combinations of dynamic binding and unbinding technology, real-time event callbacks and lifecycle synchronization technology, and cross-component attribute mechanisms, this invention provides EDA engineers with an easy-to-write, read, modify, and version-manage workflow control solution, thereby significantly improving the management efficiency and reliability of EDA workflows.

[0043] The innovative script-level fine-grained process integration technology proposed in this invention achieves script-level fine-grained process control through an innovative combination of dynamic binding and unbinding, real-time event callbacks, and cross-component attribute mechanisms.

[0044] Its systematic implementation mainly includes the following core modules:

[0045] 1. Dynamic Binding / Unbinding Module: Enables on-demand binding and unbinding of EDA components. The implementation mechanism is as follows:

[0046] At each stage of process execution, the need for certain component capabilities is dynamically assessed based on business requirements. For example, if APR (Auto Place and Route) capability is required, the APR component is bound to the current process stage in real time. When the process stage is completed or the APR capability is no longer needed, the component is immediately unbound and the resources occupied by the APR component are released.

[0047] 2. Event Callback and Lifecycle Management Module: Handles data module change events and component lifecycle synchronization. The implementation mechanism includes:

[0048] A reverse injection event callback mechanism for data changes in the data module;

[0049] Establish an EDA component lifecycle management framework to achieve real-time synchronization of component and data module states;

[0050] Connect the data interaction interfaces of the upper-level business to enable the use of a single data model throughout the entire process.

[0051] 3. Cross-component property management module: Enables property splitting, mounting, and sharing. The implementation mechanism includes:

[0052] By segmenting simple attributes of the business layer and attaching them to the corresponding objects in the data module, the resource waste of traditional data copying methods is avoided.

[0053] Attributes follow the objects in the data module through all processes without needing to be converted and transmitted through a common data format.

[0054] When components are unbound and rebound, important settings and intermediate results are restored through the property mechanism to ensure data consistency.

[0055] Establish a real-time notification mechanism for attribute changes to enable efficient data synchronization across different components using the same data model.

[0056] The scripting language-level multi-database fusion process technology proposed in this invention solves the shortcomings of existing technologies in resource allocation, lifecycle management, data sharing efficiency, and business continuity through an innovative combination of dynamic binding and unbinding, real-time event callbacks, and cross-component attribute mechanisms. Compared with existing technologies, the advantages of this invention are specifically reflected in the following aspects:

[0057] In terms of reliability, a real-time synchronization relationship is established between the component state and the business process state by establishing a full lifecycle management framework for data components and an event callback mechanism for data changes in data components. This avoids EDA tool anomalies or hidden errors caused by inconsistencies between component states and business process states, and reduces process anomalies and final result anomalies caused by state asynchrony between business processes.

[0058] In terms of maintainability and engineering efficiency, the scripting language's inherent flexible flow control, human-readable presentation, and dynamic binding / unbinding mechanisms effectively reduce learning and review costs. Engineers don't need to overly concern themselves with data lifecycle and validity to ensure smooth operation throughout the entire process. When process requirements change or variations need to be customized for clients, the introduced components can synchronize data modifications through the callback mechanism of the data components without modifying the underlying component code, thereby reducing maintenance costs.

[0059] In terms of scalability, the synergy of three core technologies—dynamic binding / unbinding, real-time event callbacks, and cross-component attributes—enables the system to be extended and validated at a low cost when facing new application scenarios. For example, when integrating new EDA tool components, only the corresponding binding / unbinding interfaces and event callback handling logic need to be implemented to seamlessly integrate into the existing process system.

[0060] In terms of execution performance, traditional EDA tool components require continuous memory consumption throughout the entire process lifecycle, and cannot be released even during process phases when their functionality is not needed. In contrast, the dynamic binding and unbinding technology of this invention enables on-demand allocation and release of component resources, effectively improving the utilization efficiency of system resources. Actual test data shows that peak memory usage is reduced by 50%, and process execution efficiency is improved by 20%.

[0061] The implementation of this solution will be specifically demonstrated and described below with reference to the accompanying drawings through more specific embodiments:

[0062] Scripting language and command registration:

[0063] Generally, EDA tools use the TCL scripting language. By encapsulating the native TCL registration command interface and providing a unified, encapsulated registration command interface for business components, all commands are registered at the same control entry point of the TCL interpreter.

[0064] The registration process is shown below:

[0065] define_cmd read_lef

[0066] -print_exec_info

[0067] -info "Load LEF files."

[0068] -component "Data"

[0069] -args {

[0070] { lef_files "LEF file paths." list:{}}

[0071] }

[0072] -body {

[0073] tcl_run_cmd "read_lef_cmd" $args

[0074] }

[0075] Here, LEF (Library Exchange Format) file refers to the layout exchange format file, component "Data" indicates that it is a data loading command, define_cmd is a predefined TCL function for registering commands, and read_lef is the name of a newly defined command.

[0076] define_cmd rpt_timing

[0077] -print_exec_info

[0078] -info "Generate a timing report for the design."

[0079] -component "STA"

[0080] -dependency "liberty verilog timing_constraint"

[0081] Where component is STA, which represents the query command for timing components, dependency represents the dependency on data components, liberty verilog timing_constraint, liberty file is the timing library file, which stores the timing characteristics (such as latency and power consumption) of standard cells of the memory chip, and is the core input data for timing analysis (STA), verilog file is the hardware description language file, which is used to describe the logic function and netlist structure of the chip, and is the basic file for logic design and verification in the EDA process;

[0082] The -dependency parameter takes the value of a space-separated string of predefined data tags. The tags are identifiers of common data types in the EDA domain (such as liberty time series library data, verilog netlist data, timing_constraint time series constraint data). The syntax is fixed as "tag1 tag2 ...". The data layer parses this parameter by splitting the string and matches it with the data tags already loaded in the database.

[0083] Figure 1 This is a complete TCL scripting language example of the core process in this invention embodiment. Its command sequence corresponds to the key operations in the entire EDA design process: 1. Commands such as load_tech, load_lib, and load_lef are data loading commands (corresponding to the "Data" component in command registration), used to load core design data such as process files, library files, and netlist files into the master data model DB; 7. bind_design is a binding command that triggers the dynamic binding module to establish the association between the master data model and subsequent business components; 9. place_opt, 11. route_opt, etc. are business operation commands (corresponding to the "Place" and "Route" components), and rpt_timing is a query command (corresponding to the "STA" component). This script intuitively reflects the basic logic of "unified command registration + dynamic binding" in this invention. All commands are distributed through the same TCL interpreter. Data loading commands do not trigger binding judgments, while query / business operation commands automatically trigger component binding.

[0084] Dynamic binding and unbinding: Controlling the loading and unloading of the database between different TCL processes.

[0085] ① Triggering timing: Each script command is categorized according to its registration type, into loading, querying, and modifying.

[0086] The data loading type will not trigger the judgment;

[0087] The data query type will trigger a binding check;

[0088] The type of business operation will trigger a binding check.

[0089] ② Triggering method:

[0090] Command registration uses a unified registration interface, and command distribution also uses a unified distribution interface. Before distributing a command to a specific business logic, a binding request is initiated to the data layer based on the command registration category. The data layer binds the data based on the already loaded input data and the target data required by the business layer. The association between these two parts was already established during TCL registration. After binding is complete, the command distribution function distributes the command to the specific business execution logic.

[0091] In this embodiment, the data layer's association mapping mechanism is as follows: When registering a TCL command, the -dependency parameter is passed a predefined list of data tags (separated by spaces). Each tag corresponds to a unique identifier for a type of data in the master data model (DB) (e.g., liberty corresponds to time-series library data, and verilog corresponds to netlist data). When a data loading command (e.g., read_liberty) is executed, the DB automatically tags the loaded data and stores it in a hash table. The binding decision algorithm parses the -dependency tag list of the current command, queries the hash table to determine whether the required data has been loaded, and simultaneously uses the component binding status table (used to record bound components and dependent data tags; this table uses data tags as keys to record the component ID and reference count of the data currently bound to that tag) to determine whether there is duplicate binding: if the same data tag is already associated with a bound component, the binding relationship is directly reused without needing to create it again.

[0092] ③ Binding and unbinding:

[0093] Data dependency binding occurs only once when multiple business components depend on the same data. If the data required by the current TCL command has been fully loaded and no other unexecuted commands depend on the current component, the component is temporarily bound before the command is executed. After the command is executed, the component is unbound and its resources are released immediately to prevent the component from unnecessarily occupying memory.

[0094] Event callback mechanism: Data response between different business components within a single TCL instance;

[0095] ① Triggering timing: Add Post or Pre callbacks during critical database operations.

[0096] After the key operation corresponding to the Post callback has been executed;

[0097] The Pre callback corresponds to the execution of key operational behaviors before they are performed.

[0098] Key behaviors in EDA tools include modifications to netlists, such as adding new instance objects or creating a new instance object for an existing network connection.

[0099] ② Implementation method:

[0100] Define generic event messages.

[0101] class Observer {

[0102] public:

[0103] virtual ~Observer();

[0104] Observer(ObserverType type, uint32_t priority, bool enabled,ObserverOwner *owner = nullptr);

[0105] ObserverType type_;

[0106] func(void*) funcs_;

[0107] bool enabled_;

[0108] uint32_t priority_;

[0109] ObserverOwner *owner_;

[0110] };

[0111] For each key behavior, the object being operated on has a unified observer of its type.

[0112] For example, the network object Net has its own NetObserver, and the connection operation NetObserver has corresponding implementation methods PreConnectPin and PostConnectPin.

[0113] Register the upper-layer business operation to the observer by calling the method of NetObserver::PreConnectPin(upper-layer business operation).

[0114] At this point, in the connection operation of the network object, the Notify operation is performed on NetOberve's PreConnectPin and PostConnectPin, that is, all methods that have been registered with the Observer are executed once, which completes the event callback content.

[0115] Here, func(void*) funcs_ actually points to an array of function pointers that conform to the signature of ObserverCallback, which is used to store multiple callback functions registered by the same Observer instance. During the Notify operation, they are traversed and executed in priority order.

[0116] In this embodiment, the creation and management of Observers are handled by the global callback manager built into the master data model (DB). This manager maintains a list of Observer instances corresponding to various data objects (such as Net and Inst). After dynamically binding with the DB, business components (such as PlaceDB) register callback functions through the unified registration interface provided by the DB::register_observer(ObserverType type, ObserverCallback callback), where type specifies the type of the associated data object (such as OBSERVER_TYPE_NET corresponding to Net), and callback is a pointer to a callback function defined by the component.

[0117] DB's data operation interfaces (such as connect_pin) have pre-defined callback trigger points: when the connect_pin operation is executed, DB first calls the PreConnectPin method of the corresponding Observer to execute all registered pre-callback logic; after the operation is completed, the PostConnectPin method is called to trigger the post-callback. The unified signature definition of the callback function is: typedef void (*ObserverCallback)(void* observed_object, const void*operation_context), where observed_object points to the data object that triggers the callback (such as a Net instance pointer), and operation_context points to a context structure containing operation details (such as ConnectPinContext, which stores pin ID, connection status, and other information).

[0118] Attribute management: Managing the data lifecycle between different TCLs.

[0119] Management scope: Management operations can be performed on data models that require dynamic binding and unbinding.

[0120] Persistent properties: Memory properties that need to reside in memory.

[0121] Business attributes: Data that only needs to be manipulated when the corresponding business is enabled.

[0122] The specific operation process involves splitting the data members of the data model and classifying them according to task type. The following example demonstrates the data declaration of instance objects in a netlist object.

[0123] struct InstDataStruct {

[0124] InstDataStruct() {

[0125] memset(this, 0, sizeof(*this));

[0126] }

[0127] UInt dont_touch : 6;

[0128] UInt orient :4;

[0129] UInt is_implicit_ : 1;

[0130] UInt small_weight_ : 3;

[0131] UInt inst_group_ : 3;

[0132] UInt is_disabled_ : 1;

[0133] }

[0134] struct InstPlaceDataStruct {

[0135] UInt has_oc_ : 1;

[0136] UInt has_anchor_ : 1;

[0137] UInt has_place_pin_ : 1;

[0138] UInt has_floating_pin : 1;

[0139] }

[0140] InstDataStruct *inst_data_struct;

[0141] InstPlaceDataStruct *inst_place_data_struct;

[0142] This structure is an example definition of business attributes. The meanings of each field are as follows: has_oc_:1 indicates whether the instance has an overload constraint; has_anchor_:1 indicates whether the instance is a layout anchor; has_place_pin_:1 indicates whether the instance contains a layout-specific pin; has_floating_pin:1 indicates whether the instance contains a floating pin. This is only used to illustrate the classification and mounting logic of business attributes and does not restrict the specific field definitions.

[0143] The example includes properties that need to be persistent and properties that the layout module stores in the database and needs to be enabled. Persistent properties are accessible to all module components, and layout module properties are accessible to other components when the layout module is enabled.

[0144] In this embodiment, the master data model (DB) provides a unified mounting and access interface for business attributes: Components mount business attributes to a specified instance object through DB::mount_business_attr(InstId inst_id, ComponentType comp_type, void*attr_data), where comp_type identifies the component type (such as COMP_TYPE_PLACE for PlaceDB), and the DB adds access permission identifiers to the attributes based on this type; after the component is bound, it retrieves the attributes through DB::get_business_attr(InstId inst_id, ComponentType comp_type). The interface internally verifies whether the currently bound component type matches the attribute permission identifier, and only allows authorized components to access it.

[0145] The property freeze during component unbinding is a memory retention mechanism: the business properties themselves are stored in the business property storage area of ​​the DB. Unbinding only releases the component's own runtime resources, and the property data remains resident in memory in an indexed manner, without the need for serialization / deserialization. After rebinding, it can be read directly through the above access interface, achieving seamless state recovery.

[0146] Example 1: Basic Process Control Implementation Method

[0147] A typical integrated circuit design flow includes stages such as reading design data, placement optimization, and routing optimization. For example... Figure 2 as well as Figure 3As shown, the multi-database fusion architecture of the present invention includes a master data model DB and specialized databases for different design stages, such as PlaceDB (a layout-specific database that stores design data (such as cell layout positions and layout constraints) for the layout optimization stage, which is only enabled through dynamic binding in the layout stage and is used for the layout optimization stage) and RouteDB (a routing-specific database that stores design data (such as metal wire connection information and routing constraints) for the routing optimization stage, which is only enabled through dynamic binding in the routing stage and is used for the routing optimization stage).

[0148] Figure 2 This invention presents a hierarchical architecture for multiple databases, reflecting a relationship between the master data model (DB) (core) and specialized databases (stage-specific). The master data model is mandatory, while the specialized databases are optional, activated only after being bound to their respective components. The core is the mandatory master data model (DB), which stores persistent attributes shared throughout the entire process, such as chip basic process parameters and the core netlist structure. Surrounding it are optional specialized databases (PlaceDB, CtsDB (a dedicated database for clock tree synthesis), etc.), corresponding to specific design stages such as placement and clock tree synthesis. "Mandatory" means the master data model resides in memory throughout the entire process, ensuring basic data sharing; "optional" means the specialized databases are dynamically loaded only during their corresponding business stages and unbound immediately after the process ends, releasing resources. This structure solves the isolation problem of existing "independent data models," providing architectural support for real-time synchronization and cross-component attribute sharing between the master data model and specialized databases.

[0149] Figure 3 The user-data-component collaborative structure of this invention, achieved through script-level fusion, is as follows: Users initiate design commands via a unified interface using TCL script instructions. The main data model (DB) serves as the core hub, handling data import and attribute storage. Specialized components such as Place and Route establish temporary associations with the DB through dynamic binding, remaining unloaded when there are no business requirements. This structure embodies the core of the fine-grained process control of this invention: components and the DB are not fixedly bound, but rather "bound on demand and unbound after use" triggered by script instructions. Furthermore, all components share the same DB data model, eliminating the need for data copying or format conversion. Compared to the existing "static binding + independent data model" approach, the fused structure of this invention achieves a balance between minimizing resource consumption and maximizing data interaction efficiency.

[0150] In the implementation process, design data is first read into the master data model (DB) through the user interface. When entering the layout optimization phase, the dynamic binding / unbinding module binds the PlaceDB component to the current process stage in real time according to script instructions. The event callback and lifecycle management module establishes the event callback relationship between the PlaceDB component and the DB data model, ensuring that data changes can be synchronized in real time.

[0151] During the layout optimization process, such as Figure 4 As shown, when PlaceDB modifies the netlist structure, it notifies the DB application of the corresponding modifications through an event callback mechanism. At the same time, the DB will also notify the upper-layer PlaceDB component of some detailed modifications, forming a two-way real-time synchronization.

[0152] Figure 4 This invention presents the full-process data interaction logic for the "layout optimization - routing optimization" stage switching in an embodiment of the invention, namely the collaborative workflow of the three core modules: dynamic binding and unbinding, event callback, and cross-component attribute management.

[0153] 1. During process initialization, the user reads the design data into the master data model DB;

[0154] 2. When executing place_opt, the PlaceDB component is dynamically bound. The layout design is carried out through the "read DB data - perform optimization" link. Changes in the netlist structure are synchronized bidirectionally to the DB and the upper-level components through "real-time event callbacks" to ensure data consistency.

[0155] 3. After the layout is completed, trigger "Dynamic Unloading of Cache Between Components", close PlaceDB and freeze its critical business attributes to the database;

[0156] 4. When executing route_opt, the RouteDB component is dynamically bound, and the frozen Place property in the DB can be directly accessed through "component key property sharing" without repeated calculation or data transfer.

[0157] After layout optimization is completed, the routing optimization phase begins. At this point, the dynamic binding / unbinding module performs dynamic unloading of inter-component caches, shuts down the PlaceDB component, and freezes critical business attributes in the database, such as... Figure 4 As shown. Then, the RouteDB component is bound, allowing RouteDB to directly access the previously frozen Place property, thus enabling cross-component property sharing.

[0158] Example 2: Implementation of Complex Process Control

[0159] In more complex integrated circuit design flows, there may be multiple switching between different specialized components. This embodiment demonstrates how to maintain state during multiple binding / unbinding processes using a cross-component attribute management module.

[0160] When a component is unbound, the cross-component attribute management module will split the component's key configuration parameters and intermediate calculation results and attach them to the corresponding objects in the master data model. When the component is rebound in subsequent processes, the system automatically restores the previous important settings and intermediate results through the attribute mechanism, ensuring business continuity.

[0161] As an implementation example: In a complex process involving layout optimization, clock tree synthesis, and routing optimization, after the PlaceDB component performs layout optimization, its business attributes (such as cell layout position, layout constraint parameters, and optimizer iteration status) are mounted to the DB via DB::mount_business_attr. When switching to the clock tree synthesis stage, PlaceDB is unbound and resources are released. After the CtsDB component is bound, it obtains the layout attributes via DB::get_business_attr and performs clock tree planning based on these attributes. If the layout needs to be adjusted during clock tree synthesis, when PlaceDB is rebound, the system automatically restores the previously mounted layout constraint parameters and optimizer status without re-initialization, and continues optimization directly from the interruption point, ensuring business continuity.

[0162] Through practical application testing of the above-described embodiments, the present invention has achieved significant technical effects:

[0163] 1. Peak memory usage was reduced by 50%, effectively alleviating resource shortages;

[0164] 2. Process execution efficiency improved by 20%, thus increasing design efficiency;

[0165] 3. Achieved a 100% recovery rate for critical settings and intermediate results, ensuring business continuity;

[0166] 4. By using a single data model throughout the entire process, the complexity of data interaction is simplified and the probability of errors is reduced.

[0167] Based on the same inventive concept, this invention also provides a computer device, comprising: one or more processors, and a memory for storing one or more computer programs; the programs include program instructions, and the processor executes the program instructions stored in the memory. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, used to implement one or more instructions, specifically for loading and executing one or more instructions stored in a computer storage medium to implement the above-described method.

[0168] It should be further explained that, based on the same inventive concept, the present invention also provides a computer storage medium storing a computer program, which, when executed by a processor, performs the above-described method. This storage medium can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0169] It should be noted that, unless otherwise defined, the technical or scientific terms used in this invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0170] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

[0171] This invention is not limited to the preferred embodiments described above. Anyone inspired by this invention can derive other forms of scripting language-level multi-database integrated electronic design automation process dynamic management methods and systems. All equivalent changes and modifications made within the scope of the claims of this invention shall fall within the scope of this invention.

Claims

1. A scripting language-level method for dynamic management of multi-database integrated electronic design automation processes, characterized in that, include: In response to scripting language commands, the electronic design automation (EDA) components required by the command are dynamically bound to a shared master data model, enabling the EDA components to access the design data in the master data model. During the binding of the EDA component with the master data model, an event callback mechanism is used to listen for data changes in the master data model, triggering the callback function of the EDA component to maintain the consistency of the state between the EDA component and the master data model. Before unbinding the EDA component from the master data model, associate the business attributes generated by the EDA component with the corresponding design data objects in the master data model; Unbind the EDA component from the master data model; When subsequent responses to other scripting language commands require rebinding the EDA component or other EDA components, the component restores or inherits the previous working state by accessing the associated business attributes in the master data model.

2. The scripting language-level multi-database integrated electronic design automation process dynamic management method according to claim 1, characterized in that: The dynamic binding includes: triggering binding decisions according to the preset categories of script language commands; data loading commands do not trigger decisions, while data query and business operation commands trigger decisions; when multiple EDA components depend on the same design data, only the first component is bound, and subsequent components reuse the binding.

3. The scripting language-level multi-database integrated electronic design automation process dynamic management method according to claim 1, characterized in that: The event callback mechanism enables bidirectional data change synchronization and includes Pre callback and Post callback. Pre callback is triggered before the operation is executed, and Post callback is triggered after the operation is executed. The event callback mechanism is implemented using the observer pattern, which configures a corresponding observer for each type of object of the operation and registers the upper-layer business operation.

4. The scripting language-level multi-database integrated electronic design automation process dynamic management method according to claim 1, characterized in that: The attributes in the master data model include persistent attributes and business attributes. Persistent attributes reside in memory and are accessible to all EDA components. The business attributes are attached to the design data object through associated indexes, so that after the EDA component is unbound, the business attributes are still associated with the design data object and can be accessed by the subsequently bound EDA components.

5. The scripting language-level multi-database integrated electronic design automation process dynamic management method according to claim 1, characterized in that: The master data model is associated with the professional databases of each stage of the EDA process. After the EDA components are bound to the master data model, they are allowed to access the corresponding professional database data.

6. The scripting language-level multi-database integrated electronic design automation process dynamic management method according to claim 1, characterized in that: The scripting language is TCL scripting language. Script commands are registered to the same TCL interpreter through a unified registration interface. During registration, the corresponding EDA components and data dependencies are declared. Before the command is distributed, it is bound according to the registration information and then distributed to the business execution.

7. The scripting language-level multi-database integrated electronic design automation process dynamic management method according to claim 1, characterized in that: Unbind the EDA component from the master data model and release the system memory resources occupied by the EDA component.

8. The scripting language-level multi-database integrated electronic design automation process dynamic management method according to claim 1, characterized in that: When the subsequent bound EDA components are of different types, the component can access the business attributes attached to the preceding components through the master data model and inherit the previous working state related to the current operation.

9. The scripting language-level multi-database integrated electronic design automation process dynamic management method according to claim 1, characterized in that: The business attributes include intermediate results and configuration parameters generated during the execution of the EDA component.

10. A scripting language-level multi-database integrated dynamic management system for electronic design automation processes, characterized in that, The system for implementing the method of any one of claims 1-9 comprises: The master data model is used to store integrated circuit design data, persistent attributes, and attached business attributes, and is associated with professional databases at each stage; The dynamic management module is configured to respond to script language commands, establish or unbind the electronic design automation (EDA) components from the master data model, and support binding reuse and resource release. The event callback module is configured to achieve bidirectional data change synchronization through the observer pattern, triggering Pre and Post callbacks. The attribute management module is configured to segment attribute types and mount business attributes through associated indexes, and supports cross-component attribute access and state recovery.

Images