Implementation method and system of dynamic logic optimization EDA synthesis tool based on script extension

Abstract

The present invention belongs to the field of electronic design automation technology, and specifically discloses a method and system for implementing a dynamic logic optimization EDA synthesis tool based on script extension, including: constructing a script interface layer, exposing the functions and data structures of a core engine layer implemented in a compiled language to a script language environment through a binding tool; when the EDA synthesis tool is running, dynamically loading user scripts and instantiating proxy objects in the script environment through the script interface layer; the proxy objects hold references or pointers to the original netlist data structure instances in the core engine layer memory; the user scripts directly access and modify the original netlist data in the core engine by operating the proxy objects, and continue subsequent processes based on the modified netlist. The present invention realizes the dynamic expansion of optimization logic without recompiling the tool, while avoiding the data copy overhead of traditional script interaction through direct memory access, ensuring high performance.

Description

Technical Field

[0001] The present invention belongs to the technical field of electronic design automation (EDA), and in particular relates to a method and system for implementing a dynamic logic optimization EDA synthesis tool based on script extension. Background Art

[0002] Electronic design automation (EDA) tools play a crucial role in modern integrated circuit design. Logic synthesis is a key step in the EDA process, transforming high-level hardware description language (HDL) code into an optimized gate-level netlist to meet design goals such as power, performance, and area. Logic optimization is a core step in logic synthesis, and the quality of its algorithms directly impacts the quality of the final chip.

[0003] Traditional EDA logic synthesis tools, particularly their logic optimization modules, are typically developed using compiled languages ​​such as C / C++. This development model presents significant technical pain points: core logic optimization algorithms are typically implemented in high-performance compiled languages ​​like C++ and are deeply coupled with the tool's underlying code. While this tightly coupled design ensures execution performance, it also introduces significant rigidity. Any minor modification to the optimization algorithm, even a simple adjustment to a single logical condition, requires a complete recompilation of the entire, complex tool chain. This process is not only time-consuming but also requires a series of tedious steps such as packaging, deployment, and regression testing, severely hindering rapid algorithm iteration and optimization. Due to significant delays in debugging feedback, R&D personnel are unable to conduct rapid trial and error and verification, resulting in low overall R&D efficiency. Furthermore, algorithm researchers are required to possess deep proficiency in underlying compiled languages ​​(such as C++) and an understanding of complex EDA tool architectures. This inadvertently raises the bar for technological innovation, making it difficult for many excellent academic algorithms to be rapidly validated and applied in industry.

[0004] To alleviate these issues, the industry has explored several existing solutions, but each has its limitations. Some tools allow users to adjust optimization algorithm parameters or switches through configuration files, but this approach is limited to fine-tuning and cannot fundamentally modify or introduce new core algorithm logic. A few tools offer a plug-in architecture, allowing third-party development of extension modules. However, this approach often requires adherence to very strict and complex interface specifications, and the plug-ins themselves are often still developed in compiled languages, remaining constrained by compilation and deployment. To increase flexibility, many tools offer scripting language-based interfaces, but these interfaces often involve inefficient data serialization and deserialization. For example, netlist data in the core engine is converted into text format and passed to the scripting environment. After the script is processed, the results are returned to the core engine for parsing and synchronization. For modern designs with netlists that can easily reach millions or even hundreds of millions of gates, this data-copying and conversion-based interaction model imposes significant performance overhead, severely limiting the execution efficiency and data size of script optimization algorithms, and making it difficult to implement refined operations on the underlying data structures. Summary of the Invention

[0005] Purpose of the invention: The purpose of the present invention is to address the deficiencies of the existing technology and provide a method and system for implementing a dynamic logic optimization EDA synthesis tool based on script extension, which not only retains the execution performance of compiled languages, but also gives developers the flexibility and development efficiency of script languages, thereby realizing truly dynamic, efficient, and deep logic optimization capability expansion in EDA synthesis tools.

[0006] Technical solution: The method for implementing a dynamic logic optimization EDA synthesis tool based on script extension provided by the present invention includes the following steps:

[0007] S1: Constructing a script interface layer in an EDA synthesis tool, wherein the script interface layer exposes the functional interface and core data structure of the core engine layer implemented in a compiled language to a script language environment through a binding tool, wherein the core data structure includes at least a netlist data structure;

[0008] S2: dynamically loading and executing a user script containing a custom logic optimization algorithm while the EDA synthesis tool is running;

[0009] S3: Instantiating a proxy object in the scripting language environment through the scripting interface layer, wherein the proxy object holds a reference or pointer to the original core data structure instance in the core engine layer memory;

[0010] S4: executing the user script in the scripting language environment, wherein the user script operates through a proxy object, thereby directly accessing and modifying the original core data structure instance in the core engine layer;

[0011] S5: Based on the core data structure instance modified by the user script, continue to execute the subsequent process of the EDA synthesis tool.

[0012] To further improve the above technical solution, the binding tool is SWIG or pybind11, which is used to implement the binding between the core engine layer and the scripting language environment, and the scripting language environment supports Python or Tcl language.

[0013] Furthermore, the functional interface includes access to or operation of at least one of the following:

[0014] Gate-level netlist structure accessor for accessing cell instances, interconnect networks, and timing paths;

[0015] Process library parameter parsing interface for accessing drive strength, timing arcs, and power models;

[0016] Optimization context access interface for accessing constraints and optimization objective weights.

[0017] Furthermore, the step of executing the user script includes:

[0018] First, obtain the design constraints and optimization goals through the optimization context access interface;

[0019] Then, based on the target, the netlist is modified by the gate-level netlist structure accessor;

[0020] During the modification process, the process library parameter parsing interface is used to query unit characteristic data to assist in decision-making.

[0021] Furthermore, the method further includes at least one of the following safety control steps:

[0022] Through the timeout interrupt mechanism, the script execution is interrupted when the execution time exceeds the preset threshold;

[0023] Through resource quota control mechanism, the execution of the script is terminated when the memory or CPU resources used by the script exceed the limit;

[0024] When an error, timeout, or resource limit is exceeded during script execution, the core data structure instance will be rolled back to the state before the modification.

[0025] Furthermore, the method also includes: utilizing real-time netlist data or timing data obtained through the script interface layer, and combining it with a third-party visualization library selected from the script language environment ecosystem, to generate a visualization view for debugging, wherein the visualization view includes at least one of a timing waveform diagram or a layout heat map.

[0026] Furthermore, the method also includes a parallel optimization step to support the collaborative work of multiple optimization scripts. The parallel optimization step includes: a data parallel method, dividing the core data structure into sub-areas for different scripts to optimize separately; a task parallel method, different scripts perform different types of optimization tasks; a pipeline method, where the output of one script serves as the input of another script.

[0027] The present invention also provides an EDA synthesis tool system for implementing the above method, comprising:

[0028] The core engine layer is implemented based on a compiled language and is used to manage the original core data structure instances in memory;

[0029] a scripting interface layer configured to generate a proxy object through a binding tool and expose the functional interface and core data structure instance of the core engine layer to a scripting language environment, wherein the proxy object holds a reference or pointer to the original core data structure instance in the core engine layer memory, so that user script operations on the proxy object can directly modify the original core data structure instance;

[0030] The user interaction layer is configured to support dynamic loading and execution of user scripts when the system is running.

[0031] Furthermore, the core engine layer also includes at least one of the following: a process library parser for parsing process library parameters; a basic logic optimizer for performing basic logic optimization; and a physical constraint loader for loading physical design constraints.

[0032] Furthermore, the script interface layer also includes a parallel optimization interface configured to support collaborative work of multiple optimization scripts, and the parallel optimization interface includes a priority management mechanism and a data synchronization mechanism between scripts to coordinate access and modification of the core data structure instance by multiple scripts;

[0033] The script interface layer also includes a timeout interruption mechanism and a resource limit control mechanism, wherein: the timeout interruption mechanism is configured to set a maximum time threshold for script execution, and interrupt script execution when the script execution exceeds the maximum time threshold; the resource limit control mechanism is configured to limit the memory and CPU resources used by the script, and terminate script execution when resource usage exceeds the limit; in the event of a script execution error, timeout or resource limit exceedance, the core data structure instance is rolled back to the state before modification.

[0034] Beneficial effects: Compared with the prior art, the advantages of the present invention are:

[0035] The present invention has extremely high flexibility and development efficiency: users can write or modify Python / Tcl scripts at any time to implement new optimization logic, and apply it immediately through dynamic loading commands without stopping or recompiling the entire EDA tool, which greatly shortens the algorithm development, debugging and verification cycle.

[0036] By directly manipulating data instances in the core engine memory through proxy objects, the present invention fundamentally avoids the data serialization, deserialization, and cross-process / environment data copying overhead in traditional script interactions, ensuring that the performance of script execution is close to that of native C++ code and capable of efficiently processing large-scale designs.

[0037] This invention fully exposes the core engine's sophisticated C++ data structures and functional interfaces to the scripting environment. User scripts can deeply access and modify them just like native objects, enabling the implementation of complex and sophisticated optimization algorithms. Furthermore, users can leverage a rich set of third-party libraries (such as scientific computing and data analysis libraries) in scripting languages ​​like Python to analyze and process EDA data, significantly expanding the tool's functionality.

[0038] By introducing mechanisms such as exception handling bridging, timeout interruption, and resource limit control, we effectively prevent errors or bad behaviors in user scripts from causing crashes or deadlocks in the core engine, ensuring the stability and reliability of the entire EDA tool. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 1 is a schematic diagram of the system architecture of a dynamic logic optimization EDA synthesis tool based on script extension provided by an embodiment of the present invention.

[0040] Figure 2 This is a dynamic logic optimization execution flow chart provided by an embodiment of the present invention.

[0041] Figure 3 This is a schematic diagram of data protocol interaction between the core engine layer and the script environment provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The technical solution of the present invention is described in detail below with reference to the accompanying drawings, but the protection scope of the present invention is not limited to the embodiments.

[0043] Example 1: Reference Figure 1 The dynamic logic optimization EDA synthesis tool system based on script extension proposed in the present invention adopts a three-layer architecture design, including a core engine layer, a script interface layer, and a user interaction layer.

[0044] 1. Implementation of the core engine layer

[0045] The core engine layer is the foundation of EDA synthesis tools, implemented in high-performance compiled languages ​​such as C++. It includes: an algorithm engine, which contains a variety of basic and advanced logic optimization algorithms, such as a basic logic optimizer and a physical constraint loader; a netlist processor, which manages the core data structures of the design circuit, particularly the unique, in-memory instance of the original netlist data structure, which is the direct target of all optimization operations; and a data converter, which is responsible for design data input / output (such as reading Verilog files) and internal format conversion. Meanwhile, other auxiliary modules, the algorithm engine and netlist processor, provide the necessary decision-making data. These include a process library parser, which parses process library data (such as drive strength and timing arcs), and a physical constraint loader, which loads physical design constraints (such as timing and area targets).

[0046] 2. Implementation of the script interface layer

[0047] The scripting interface layer bridges the core engine layer with the flexible scripting environment. This layer connects C++ and scripting languages ​​(such as Python and Tcl) through binding tools, such as SWIG (Simplified Wrapper and Interface Generator) and pybind11. Both SWIG and pybind11 are popular tools for connecting C++ and scripting languages. The difference is that SWIG supports multiple scripting languages, while pybind11 specializes in Python. Generally speaking, SWIG is suitable for projects that require multi-language bindings, while pybind11 is more suitable for projects that use Python as the primary scripting language.

[0048] When C++ objects (such as netlist objects and cell instances) are exposed to the scripting interface layer, the scripting interface layer does not directly operate on the original C++ memory addresses. Instead, the binding tool creates a "proxy object" in the scripting environment. This proxy object behaves like an ordinary object at the scripting language level, but it holds a pointer or reference to the actual C++ object internally. When the script operates on the proxy object (such as calling methods and accessing properties), these operations are forwarded to the actual C++ object for execution. This process is handled by the wrapper code generated by the binding tool. The script accesses and modifies the unique netlist instance in the C++ core engine through the proxy object, which means that the changes made by the script are directly reflected in the core engine's data.

[0049] The script interface layer exposes three types of functional interfaces, including:

[0050] (1) Optimization context access interface: This interface is used by scripts to obtain the current optimization target and environment information. For example, scripts can use this interface to query design constraints (such as timing constraints, power consumption targets, and area targets), the current optimization stage, and the weights of the optimization targets. This provides macro-level guidance for the optimization algorithm, helping it determine the direction and focus of optimization.

[0051] (2) Gate-level netlist structure accessor: After understanding the optimization context, the script primarily interacts with the designed circuit structure through this interface. It allows the script to query detailed information about the netlist (such as cell instances, pins, wires, drive relationships, and load relationships), traverse critical paths, and modify the netlist (such as replacing cells, inserting buffers, and re-faning out). This is the core interface for performing specific optimization operations and relies on the information provided by the optimization context interface to guide its operations (for example, identifying cells on the critical path for optimization based on timing constraints).

[0052] (3) Process library parameter parsing interface: When the netlist structure accessor identifies the unit to be optimized or needs to select a new unit, the script will use this interface to query the detailed parameters of the standard unit in the process library. These parameters include the unit's drive strength, timing arc (such as delay, conversion time), power consumption characteristics, area, etc. When the netlist structure accessor needs to evaluate the impact of a modification (such as replacing a unit) on PPA (Power, Performance, Area), or needs to select a suitable unit (such as a buffer with different drive strengths), it will indirectly or directly prompt the script to call the process library parameter parsing interface to obtain the unit characteristic data required for decision-making.

[0053] These three interfaces work together when the script executes a custom optimization algorithm, providing the algorithm with necessary information and operational capabilities. These three interfaces complement each other: the optimization context provides the target, the netlist accessor provides the operation objects and means, and the process library interface provides the decision basis.

[0054] 3. Implementation of the user interaction layer

[0055] The user interaction layer provides the CLI console, which serves as the entry point for users to interact with the system. The CLI console handles standard input (keyboard input), standard output (displayed to the console), and standard error (error messages displayed to the console). When users execute script commands or directly enter script code in the CLI console, this script code can access core engine functionality exposed through the scripting interface layer.

[0056] The general flow of user interaction is as follows: The user enters a command in the CLI console to load and execute a script. The user interaction layer receives this command and instructs the script interpreter to execute the specified user script. During execution, the user script interacts with the core engine through the API provided by the script interface layer, querying data and performing modifications. The core engine's execution results or printed information from the script are returned via the API and ultimately displayed to the user by the CLI. After script execution completes, the system returns to a waiting state.

[0057] Utilize real-time netlist data or timing data obtained through the scripting interface layer, combined with third-party visualization libraries selected from the scripting language environment ecosystem, and use third-party scripting language libraries to quickly generate visual debugging views (timing waveforms, layout heat maps).

[0058] Example 2: Reference Figure 2 , the method of the present invention specifically comprises the following steps:

[0059] Step S1: Build the script interface layer. When developing an EDA synthesis tool, define the C++ classes and functions that need to be exposed to the script, and use binding tools such as SWIG or pybind11 to generate wrapper code that connects the C++ core engine and the script interpreter to build the script interface layer.

[0060] Step S2: Dynamically load and execute user scripts. During the EDA tool's execution, when the predetermined logic optimization phase is reached, the main thread is paused, and the user can enter commands through the CLI console of the user interaction layer to dynamically load a user script containing a custom optimization algorithm.

[0061] Step S3: Inject the current netlist data and constraints. After the script is loaded, the script interface layer instantiates proxy objects for the core data that the script needs to access (such as the current design netlist). Through these proxy objects, the user script calls the exposed functional interfaces to directly access and modify the original netlist data structure instance in the core engine layer's memory.

[0062] Step S4: Execute the script algorithm, which includes the main steps and three exception handling branches:

[0063] The main step is to obtain the modified netlist, and then execute step S5;

[0064] The three exception handling branches include: if the script is wrong, perform exception handling and roll back the netlist; if the execution times out, use interrupt handling and timeout handling; if the resource exceeds the limit, use termination to protect resources.

[0065] Step S5: Continue to execute the subsequent process. After the user script is executed, the netlist data in the core engine layer has been directly updated. The main process of the EDA tool then continues to execute the subsequent synthesis or layout preparation steps based on this modified netlist.

[0066] Reference Figure 3 This section shows how data is exchanged between the C++ core and a scripting environment (using Python / Tcl as an example) through SWIG / pybind11 wrappers and proxy objects. The data of C++ objects (netlist objects, timing engines, and process libraries) is exposed to the scripting environment through the wrappers. The Python / Tcl proxy objects in the script represent the netlist objects or timing engines in the C++ core.

[0067] Example 3: During the execution of the above method, three methods are provided for task allocation:

[0068] Data parallelism: If the optimization task can be decomposed into different parts of the netlist (for example, optimizing unrelated cones of logic in the design separately), the netlist can be divided into multiple subregions, with each script responsible for one or more subregions. User-written scripts are responsible for defining and assigning these subregions.

[0069] Task parallelism: Different scripts can perform different types of optimization tasks (e.g., one script focused on timing optimization, another on power optimization, acting on the entire design or specific parts in different stages or iterations).

[0070] Pipeline: The output of one script becomes the input of another script, forming an optimized process.

[0071] This invention provides two approaches to ensure data sharing and consistency: one is that all scripts access and modify the same netlist instance in the core engine. This is the most direct approach, but also the most prone to conflicts. The script user is responsible for resolving conflicts. The other is an isolated copy approach: each script works on a separate copy of the netlist, and upon completion, the results need to be merged back into the main netlist. In this case, the script user can choose to merge or abandon the netlist based on the netlist evaluation results, which also requires the user to handle conflicts.

[0072] To facilitate users in handling conflicts, the core engine provides the script layer with available synchronization methods:

[0073] If scripts share data (e.g., modifying the same netlist directly), the core engine provides a locking mechanism that allows scripts to acquire locks when accessing critical sections (e.g., modifying specific parts of the netlist), preventing race conditions. These locks are exposed to scripts through the script interface layer.

[0074] Condition variables are registered in the core engine and exposed to the script layer through the script interface layer: they can be used for communication and waiting between scripts. A script can wait for another script to complete a specific task or send a signal.

[0075] The core engine of the EDA tool can start a separate thread for each script or a group of scripts. The scripts interact with the core data through some of the mechanisms provided above.

[0076] The "Parallel Optimization Interface" in the present invention provides a thread-safe netlist access API, allowing an external scheduler (a main script written by the user) to run optimization scripts in different threads, and the scripts are responsible for synchronization.

[0077] Example 4: The method of the present invention also supports integration with third-party visualization libraries to provide powerful debugging capabilities. By leveraging real-time netlist data or timing data acquired through the scripting interface layer and combining it with a third-party visualization library selected from the scripting language environment ecosystem, visual debugging views (timing waveforms, layout heatmaps) can be quickly generated using the third-party scripting language library.

[0078] As described above, although the present invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the present invention itself. Various changes may be made to it in form and detail without departing from the spirit and scope of the present invention as defined in the appended claims.

Claims

1. A method for implementing a dynamic logic optimization EDA synthesis tool based on script extension, characterized in that: The following steps are involved: S1: Constructing a script interface layer in an EDA synthesis tool, wherein the script interface layer exposes the functional interface and core data structure of the core engine layer implemented in a compiled language to a script language environment through a binding tool, wherein the core data structure includes at least a netlist data structure; wherein the functional interface includes: a gate-level netlist structure accessor for accessing unit instances, interconnect networks, and timing paths; a process library parameter parsing interface for accessing drive strength, timing arcs, and power consumption models; and an optimization context access interface for accessing constraints and optimization target weights; S2: dynamically loading and executing a user script containing a custom logic optimization algorithm while the EDA synthesis tool is running; S3: Instantiating a proxy object in the scripting language environment through the scripting interface layer, wherein the proxy object holds a reference or pointer to the original core data structure instance in the core engine layer memory; S4: executing the user script in the scripting language environment, wherein the user script operates through a proxy object, thereby directly accessing and modifying the original core data structure instance in the core engine layer; wherein the step of executing the user script includes: obtaining design constraints and optimization targets through the optimization context access interface; Based on the optimization goal, modifying the netlist through the gate-level netlist structure accessor; During the modification process, the process library parameter parsing interface is used to query unit characteristic data to assist in decision making; S5: Based on the core data structure instance modified by the user script, continue to execute the subsequent process of the EDA synthesis tool.

2. The method for implementing a dynamic logic optimization EDA synthesis tool based on script extension according to claim 1, wherein: The binding tool is SWIG or pybind11, which is used to implement the binding between the core engine layer and the scripting language environment. The scripting language environment supports Python or Tcl language.

3. The method for implementing a dynamic logic optimization EDA synthesis tool based on script extension according to claim 1, wherein: The method further comprises at least one of the following safety control steps: Through the timeout interrupt mechanism, the script execution is interrupted when the execution time exceeds the preset threshold; Through resource quota control mechanism, the execution of the script is terminated when the memory or CPU resources used by the script exceed the limit; When an error, timeout, or resource limit is exceeded during script execution, the core data structure instance will be rolled back to the state before the modification.

4. The method for implementing a dynamic logic optimization EDA synthesis tool based on script extension according to claim 1, wherein: The method further includes: utilizing real-time netlist data or timing data obtained through the script interface layer, and combining it with a third-party visualization library selected from the script language environment ecosystem, to generate a visualization view for debugging, wherein the visualization view includes at least one of a timing waveform diagram or a layout heat map.

5. The method for implementing a dynamic logic optimization EDA synthesis tool based on script extension according to claim 1, wherein: The method further includes a parallel optimization step to support collaborative work of multiple optimization scripts, and the parallel optimization step includes: Data parallelism divides the core data structure into sub-regions for different scripts to optimize separately; Task parallelism: different scripts execute different types of optimization tasks; In a pipelined manner, the output of one script is used as the input of another script.

6. A system for implementing the script-expanded dynamic logic optimization EDA synthesis tool implementation method according to claim 1, characterized in that: include: The core engine layer is implemented based on a compiled language and is used to manage the original core data structure instances in memory; a scripting interface layer configured to generate a proxy object through a binding tool and expose the functional interface and core data structure instance of the core engine layer to a scripting language environment, wherein the proxy object holds a reference or pointer to the original core data structure instance in the core engine layer memory, so that user script operations on the proxy object can directly modify the original core data structure instance; The user interaction layer is configured to support dynamic loading and execution of user scripts when the system is running.

7. The system according to claim 6, characterized in that The core engine layer further includes at least one of the following: a process library parser for parsing process library parameters; a basic logic optimizer for performing basic logic optimization; Physical Constraint Loader for loading physical design constraints.

8. The system according to claim 6, wherein: The script interface layer further includes a parallel optimization interface configured to support collaborative work of multiple optimization scripts, wherein the parallel optimization interface includes a priority management mechanism and a data synchronization mechanism between scripts to coordinate access and modification of the core data structure instance by multiple scripts; The script interface layer also includes a timeout interruption mechanism and a resource limit control mechanism, wherein: the timeout interruption mechanism is configured to set a maximum time threshold for script execution, and interrupt script execution when the script execution exceeds the maximum time threshold; the resource limit control mechanism is configured to limit the memory and CPU resources used by the script, and terminate script execution when resource usage exceeds the limit; in the event of a script execution error, timeout or resource limit exceedance, the core data structure instance is rolled back to the state before the modification.

Images