Netlist file adaptive splitting method and device based on line number estimation

Abstract

The application discloses a netlist file adaptive splitting method and device based on line number estimation, and relates to the technical field of EDA. An original netlist file is received, and when the physical size exceeds a set threshold, the original netlist file is parsed into a hierarchical nested structure composed of multiple modules; based on line number information extracted by a netlist parsing tool, the physical size of each module is calculated to estimate the physical size of each module; recursive splitting is performed on the hierarchical nested structure from top to bottom, for the current module traversed, the descendant modules of the current module are traversed to accumulate the volume and calculate the total physical size estimation value; when the recursive trigger threshold is reached, a target submodule is selected to be independently split into a split sub-netlist file, and the submodule is replaced by an abstract placeholder structure; the split submodule is taken as a new current module to continue recursive execution. The scheme can efficiently process large FPGA netlist files, significantly reduce memory overhead, shorten netlist remapping time, and ensure netlist logic integrity.

Description

Technical Field

[0001] This application relates to the field of EDA technology, and in particular to an adaptive splitting method and apparatus for netlist files based on row number estimation. Background Technology

[0002] With the rapid development of big data, complex system simulation, ultra-large-scale network topology analysis, and distributed computing technologies, the size of netlist files (or hierarchical text files, such as description files containing nested declarations) that modern computer software needs to process in various engineering fields to describe the internal components and connections of large-scale complex systems has exploded. In practical industrial applications, the physical size of a fully designed gate-level netlist or complex topology netlist file has generally reached several gigabytes, tens of gigabytes, or even hundreds of gigabytes.

[0003] Faced with such massive netlist files, traditional serial single-node processing architectures are encountering severe performance bottlenecks. To improve processing efficiency and reduce hardware overhead, it is usually necessary to perform "divide and conquer" preprocessing on ultra-large netlist files. This involves splitting them into multiple sub-netlist files of controllable size, meeting specific physical scale thresholds, according to the nested relationships of their internal logic or circuit modules. This allows for subsequent parallel processing using multi-core processors or distributed computing clusters (such as parallel analysis, parallel computing, or simulation), thereby preventing downstream tools from frequently encountering Out of Memory (OOM) errors due to reading ultra-large files at once.

[0004] However, in practical engineering projects involving hierarchical splitting and file segmentation of extremely large-scale netlist files, existing techniques generally suffer from the following fatal technical flaws:

[0005] First, there is a lack of efficient methods for estimating the physical size of modules. Before performing hierarchical partitioning of the netlist, the system must accurately predict the physical size of each submodule or subtree on the file disk to ensure that the partitioned subfiles are strictly within a reasonable size threshold. Existing estimation methods typically fall into two categories: one is to indirectly evaluate based on the circuit logic characteristics of the netlist (such as counting the number of logical nodes, gate instances, or logical nesting depth within a submodule). However, due to the significant differences in the text description structures of different types of components in the netlist file (for example, a storage module containing complex configuration parameters and a regular trigger may have the same order of magnitude in the number of syntax nodes, but the former may have thousands of lines of text description), this method, which relies on the characteristic that the number of logical nodes and the physical text byte size are not strictly linearly proportional, results in extremely inaccurate estimations. In contrast, netlist files follow a unified syntax at the text level, and the number of lines of code, compared to the number of logical nodes, more objectively reflects the text volume. The other method is to directly perform a full text scan and character count on the disk file using a conventional script. However, when faced with extremely large text files of tens of gigabytes, explicitly performing high-frequency full-text stream reading and character calculations can lead to disastrous I / O overhead and time latency. In fact, the processing script itself may trigger memory overflow, which greatly reduces the efficiency of the preprocessing process.

[0006] Second, traditional partitioning mechanisms are highly susceptible to disrupting the hierarchical reference integrity of module structures. During the vertical hierarchical splitting of extremely large netlists, when a subordinate submodule is stripped and exported as an independent partitioned subnetlist file, its corresponding parent module file must undergo corresponding "black-box" placeholder processing to maintain the overall design's topology links. Existing partitioning tools or conventional replacement scripts often lack a deep dynamic understanding of the complex underlying syntax structure of the netlist when performing such conversions. When removing the internal logic of a submodule, they are prone to losing, tampering with, or mismatching the inherent attributes of the original ports (such as port name strings, signal transmission direction, bus width, and multi-level identifier definitions). This incompleteness and "broken links" of interface information can cause downstream topology recovery tools, merging engines, or linkers to fail to accurately identify the hierarchical references between parent and child modules, leading to serious syntax errors or broken logical connections in subsequent processing, compilation, synthesis, or simulation stages.

[0007] Third, the lack of adaptive boundary control in the segmentation algorithm makes it highly susceptible to file fragmentation or uncontrolled file size. Traditional segmentation strategies often employ simple splitting at a fixed depth or a single threshold triggering mechanism. When faced with deeply nested, multi-level complex structures with highly uneven size distribution, the single threshold mechanism either fails to force downward addressing and splitting when the parent module is too large, resulting in the split files still exceeding the limit and failing to solve the memory overflow problem of downstream tools; or, due to the lack of dynamic feedback on the termination boundary, it blindly splits downwards, generating a large number of extremely small files of a few hundred KB or even a few KB. This severe "file fragmentation" not only greatly wastes the storage nodes of the file system but also introduces huge system scheduling overhead and task communication overhead in subsequent distributed job scheduling, violating the original intention of parallel acceleration.

[0008] In summary, the core technical bottleneck that urgently needs to be addressed in the field of accelerating the preprocessing of large and complex netlist files is how to accurately estimate the physical size of ultra-large-scale netlist modules with extremely low computational overhead, and how to implement an efficient segmentation scheme with dual threshold adaptive boundary control while strictly preserving the integrity of module interfaces and hierarchical topology. Summary of the Invention

[0009] This application provides an adaptive splitting method and apparatus for netlist files based on row number estimation, which can efficiently process large FPGA netlist files, significantly reduce memory overhead, shorten netlist remapping time, and ensure the logical integrity of the netlist.

[0010] On the one hand, this application provides an adaptive splitting method for netlist files based on row count estimation, the method comprising: Receive the original netlist file. When the physical size of the original netlist file is greater than a preset file size threshold, use a netlist parsing tool to parse the original netlist file into a hierarchical module structure. Based on the row number information extracted by the netlist parsing tool, the estimated physical size of each module in the hierarchical module structure is estimated. The hierarchical module structure is recursively split from top to bottom: for the current module being traversed, its total physical size is estimated; when the total physical size is greater than or equal to a preset recursive trigger threshold, a target sub-module is selected in the current module and independently split into a segmented subnet list file, and the target sub-module in the current module is replaced with an abstract placeholder structure representation that retains the original port attributes but removes the internal logic implementation; Wherein, if the recursion trigger threshold is greater than the file size threshold, the split target sub-module is recursively executed as the new current module to calculate the total physical size estimate and split the module.

[0011] Specifically, after receiving the raw netlist file, a preprocessing step for the compressed format is also included: Read the header signature of the original netlist file; If the file header signature matches the compression format, the original byte size before decompression is directly read from a specific data segment at the end of the compression format, and the original byte size is used as the basis for determining whether it is greater than the file size threshold.

[0012] Specifically, estimating the physical size of each module based on the row number information extracted by the netlist parsing tool includes: Obtain the total number of lines and the original file size in bytes of the original netlist file; The starting line number of each module in the original netlist file is obtained using a netlist parsing tool, and the number of lines of each module is determined based on the difference between the starting line numbers of adjacent modules. Calculate the estimated physical size of each module. It satisfies the following relationship:

[0013] in, This is the number of rows in the module itself. This represents the total number of rows in the original netlist file. This represents the original file size in bytes.

[0014] Specifically, the calculation of the total physical size estimate includes the subtree-scale caching step: Build a subtree row count cache table in memory; When calculating the estimated total physical size of a current module, if the record of the module is not found in the subtree row count cache table, all descendant modules of the current module are traversed, the row count of the descendant modules is accumulated as the total row count of the subtree of the current module and stored in the subtree row count cache table, and the estimated total physical size of the current module is obtained according to the conversion formula.

[0015] Specifically, the file size threshold and the recursion trigger threshold satisfy the following:

[0016] in For file size threshold, For recursive trigger threshold, ; The file size threshold is used as the upper limit for a single netlist file to suppress the generation of excessively small netlist file fragments; the recursion trigger threshold is used as a recursion trigger limit to ensure that the size of the parent module is forced to be continuously divided and decomposed downwards.

[0017] Specifically, when splitting into separate subnettable files, the following greedy strategy is used in a loop: Sort all submodules in the submodule list of the current module in descending order based on their respective total physical size estimates; Establish a variable for the remaining total size, with the initial value being the estimated total physical size of the current module; The sub-modules with the largest estimated values ​​are selected in descending order and taken as the target sub-modules. If the estimated total physical size of the target submodule is greater than the file size threshold, it is split into the segmented subnet table file, and the estimated total physical size of the target submodule is subtracted from the remaining total size variable. Repeat the sequential extraction and splitting operation until the value of the remaining total size variable is less than the recursion trigger threshold, at which point the splitting stops.

[0018] Specifically, the original port attributes include at least: port name, signal transmission direction, and bus width; The abstract placeholder structure not only completely clones the original port attributes of the target submodule, but also retains the unique triplet identifier of the target submodule in the hierarchical module structure. The unique triplet identifier consists of the library name, unit name, and view name.

[0019] Specifically, after the top-down recursive decomposition is completed, it also includes: The top-level module architecture containing all the abstract placeholder structure representations is retained, exported separately as a top-level skeleton netlist file, and the top-level skeleton netlist file and all the segmented subnetlist files are uniformly marked as compressed and persistently stored.

[0020] Specifically, the method, as a large file preprocessing operation, outputs the segmented subnet list file, which is then sent to a parallel EDA toolchain. The parallel EDA toolchain schedules each of the segmented subnetlist files to multiple parallel task nodes based on the estimated physical size of the subnetlist files, performing device remapping, timing analysis, or simulation, in order to avoid a single node reading an ultra-large netlist file at once and triggering a memory overflow.

[0021] On the other hand, this application provides an adaptive splitting device for netlist files based on row count estimation, the device comprising: The file parsing module is used to receive the original netlist file. When the physical size of the original netlist file is greater than a preset file size threshold, the netlist parsing tool is used to parse the original netlist file into a hierarchical module structure. The file estimation module is used to estimate the physical size of each module in the hierarchical module structure based on the row number information extracted by the netlist parsing tool. The recursive splitting module is used to perform recursive splitting on the hierarchical module structure from top to bottom: for the current module being traversed, its total physical size estimate is calculated; when the total physical size estimate is greater than or equal to a preset recursive trigger threshold, a target sub-module is selected in the current module and independently split into a segmented subnetlist file, and the target sub-module is replaced in the current module with an abstract placeholder structure representation that retains the original port attributes but removes the internal logic implementation; Wherein, if the recursion trigger threshold is greater than the file size threshold, the split target sub-module is recursively executed as the new current module to calculate the total physical size estimate and split the module.

[0022] The beneficial effects of the technical solution provided in this application embodiment include at least the following: In terms of module physical size estimation, this embodiment estimates the physical size of the module by extracting the row number information from the netlist parsing tool. This method cleverly avoids the huge overhead of full text scanning, and at the same time provides a more accurate physical size prediction than logical feature statistics, which significantly improves the efficiency and accuracy of preprocessing. Regarding the integrity of module structure hierarchy references, this embodiment replaces the target submodule with a black-box representation that retains the original port attributes, namely, its port name, signal transmission direction, and bus width. This technique ensures that after physical splitting, the topological link relationship between the parent module and each level of submodules remains intact, effectively avoiding logical breaks caused by the loss of interface information and ensuring the correctness of subsequent parallel processing tools; Regarding adaptive boundary control in the segmentation algorithm, this embodiment achieves adaptive boundary control through a top-down recursive splitting mechanism combined with dual threshold control of file size threshold and recursion trigger threshold. This dual threshold strategy ensures that the size of the split sub-files is within a reasonable range, solving the problem of forced splitting of ultra-large modules and effectively suppressing file fragmentation. Thus, it optimizes the scheduling efficiency of distributed tasks while ensuring the memory safety of downstream parallel processing tools. Attached Figure Description

[0023] Figure 1 This is a flowchart of the adaptive splitting method for netlist files based on row number estimation provided in the embodiments of this application; Figure 2 This diagram illustrates the principles of file preprocessing, line number information collection, and subtree line number caching. Figure 3 This is a flowchart of recursively dividing the current module using a greedy loop strategy; Figure 4 This diagram illustrates the principle of recursive adaptive partitioning and top-level module export. Figure 5 This illustration shows a schematic diagram of the structure of the adaptive splitting device for netlist files based on row number estimation provided in an embodiment of this application; Figure 6 A structural block diagram of a computer device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0025] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0026] In traditional netlist file preprocessing, the estimation of module physical size relies on logical feature statistics or full-text scanning methods. Due to inherent differences in the textual description structures of different components within a netlist file, logical feature statistics methods cannot accurately reflect the actual file size; while full-text scanning methods lead to increased I / O overhead in ultra-large file scenarios. Furthermore, during hierarchical splitting, port attribute information in the parent module is prone to loss or mismatch after each level of sub-module is removed, causing breakage of topological links between modules. In addition, the segmentation algorithm uses a fixed threshold mechanism, lacking the ability to adaptively adjust the splitting depth based on module size distribution, resulting in sub-file sizes exceeding the preset threshold or generating fragmented files. These problems directly reduce preprocessing efficiency and increase the risk of memory overflow or logical errors in downstream parallel processing tools.

[0027] For example, in VLSI design verification, a gate-level netlist file describing a complex processor architecture is being processed. This netlist contains multi-level nested modules, where the cache controller submodule has thousands of lines of description due to its detailed configuration text, while the basic components contain only a few lines. When existing partitioning tools are applied, the estimation method based on the number of logic nodes underestimates the physical size of the cache controller, causing the partitioned subfile to exceed the memory capacity threshold of downstream simulation tools, triggering a memory overflow error. Furthermore, during the stripping of this level of submodules, the port signal transmission direction information is incorrectly modified, preventing the parent module from correctly establishing hierarchical references with this level of submodule, and the downstream linker reports an interface mismatch error. As a result, the design verification process is forced to stop, requiring additional manual intervention to repair it.

[0028] If the above issues are not addressed, the netlist file preprocessing process will be unable to meet the parallel processing requirements of ultra-large-scale designs. File fragmentation increases file system storage management overhead and distributed task scheduling complexity; excessively large files will directly cause memory overflow errors in downstream tools. Broken topology links will result in incomplete design data, causing subsequent logic verification or simulation phases to fail. These problems will reduce the reliability and efficiency of the design process, increase hardware resource consumption, and ultimately prevent the entire design project from being completed.

[0029] To address this, this application proposes an adaptive splitting method for netlist files based on row count estimation, such as... Figure 1 As shown, the solution includes the following steps: Step 110: Receive the original netlist file. When the physical size of the original netlist file is greater than the preset file size threshold, use a netlist parsing tool to parse the original netlist file into a hierarchical module structure. The raw netlist file refers to the initial file generated by electronic design automation (EDA) synthesis tools that describes the logical connections of digital circuits. It is usually stored in standard formats such as EDIF. In this solution, we specifically refer to the raw EDIF format netlist file (supporting gzip compression format), which is usually quite large, possibly reaching several GB, tens of GB, or even hundreds of GB.

[0030] This embodiment uses an EDIF netlist file as an example. After receiving the original EDIF netlist file, the system checks its physical size. For example, the file's byte size can be obtained by reading the file system's metadata. If the physical size is greater than a preset file size threshold, it indicates that the file needs further processing. At this time, the system calls a netlist parsing tool to parse the original netlist file.

[0031] Netlist parsing tools can take the form of tools like the Verific library, which are software libraries or applications. Their internal netlist parsing engine is the core component, provided as a netlist parsing library. Its function is to read and understand the syntactic structure of netlist files, converting them into a hierarchical data model that can be manipulated in memory. Netlist parsing tools are not limited to any specific commercial or open-source library. Since EDIF netlists are essentially text files, their parsing process generally follows a software architecture of "lexical analysis (lexer / tokenizer), syntax analysis (parser), and construction of internal netlist objects (Netlist Object)." In this process, line number information is the basic metadata naturally maintained by the text parser when sequentially reading the file. Therefore, regardless of whether a commercial closed-source parsing scheme, an open-source parsing scheme, or a self-developed parsing module is used, the line numbers of the EDIF file containing netlist objects such as cells, views, nets, and instances can be obtained incidentally while parsing using conventional methods.

[0032] In addition, for netlist parsing tools that do not have a line number API, a text parsing module based on a lexer and a parser can be used. During the lexical analysis phase, the parser (tokenizer) records the current line number while generating each token. During the parsing phase, when a cell node of the representation module is parsed, the line number corresponding to the token is written into the metadata field of the cell object.

[0033] The transformed hierarchical module structure reflects a data model of the nested relationships between modules within the system. This structure is typically represented as a tree or graph, containing a top-level module, sub-modules, and the connections between them.

[0034] Step 120: Based on the row number information extracted by the netlist parsing tool, estimate the physical size of each module in the hierarchical module structure. Line number information refers to the start and / or end line numbers recorded by the netlist parsing tool for each module or code segment in the original netlist file during the parsing process. This line number information can reflect the relative position of the module in the original file and the text length.

[0035] While constructing the hierarchical module structure, the netlist parsing tool records the start and end line numbers of each module in the original netlist file. Subsequently, the system can estimate the physical size of each module based on its line count, combined with the total number of lines and total bytes in the original netlist file, through a simple proportional calculation.

[0036] Step 130: Perform recursive splitting of the hierarchical module structure from top to bottom: For the current module being traversed, calculate its total physical size estimate; when the total physical size estimate is greater than or equal to the preset recursive trigger threshold, select the target sub-module in the current module and split it into a segmented subnetlist file, and replace the target sub-module in the current module with an abstract placeholder structure representation that retains the original port attributes but removes the internal logic implementation.

[0037] This process involves iterating through all direct and indirect sub-modules of the current module, accumulating their individual physical size estimates, and then adding this to the current module's own physical size estimate to obtain the total physical size estimate. When this total physical size estimate is greater than or equal to a preset recursion trigger threshold, the system selects a target sub-module within the current module and independently splits it into a segmented subnetlist file. For example, the physical size estimates of all modules can be sorted, and the sub-modules can be selected for splitting in descending order.

[0038] A subnetlist file refers to a smaller fragment of the netlist file obtained by splitting the original netlist file. Abstract placeholder representation refers to a simplified representation where, during netlist splitting, the split submodules retain only their external interface definitions (port names, directions, bit widths, etc.) in their parent module, while internal implementation details are removed or hidden. In this embodiment, this can be implemented using a blackbox or stub / dummy cell. This significantly reduces the size of the parent module's EDIF file; the integrity of hierarchical references is maintained, and the parent module remains aware of the submodule's existence and interface; during subsequent re-merging, the blackbox / placeholder can be automatically replaced by the corresponding complete module definition.

[0039] The following embodiments of this solution are described in a black-box manner. For example, in the EDIF 2.0.0 format, a module is represented by a "cell," and each cell contains one or more "views." Each view consists of two parts: "interface" and "contents." The "interface" defines the list of ports through which the module interacts with the external environment, declared using LISP-style prefix bracket syntax, such as "(port (direction input) (name clk))". The "contents" define the netlist implementation within the view, including instances and connections. When a target submodule is replaced with a black-box representation, the view of that cell in the generated EDIF netlist retains only the "interface" part, omitting the "contents" part (or setting "contents" to an empty structure). For example: (cell sub_module (cellType GENERIC) (view structural_view (viewType NETLIST) (interface (port clk(direction INPUT)) (port rst(direction INPUT)) (port data_in(direction INPUT)(array (dimension 8) 0 7)) (port data_out (direction OUTPUT) (array (dimension 8) 0 7)) ) There is no contents block here, or there is (contents) but the content is empty. ) ) In Verilog, a black box is represented as a module that only declares ports and has no internal logic. For example, a black box definition of a target submodule might look like this: ( black_box ) module target_submodule ( input wire clk, input wire rst, input wire [7:0] data_in, output wire [7:0] data_out ); endmodule The module declaration above contains all port directions, names, and bit width information for the submodule, but the module body does not contain any assign statements, instantiations, or logical descriptions.

[0040] After the target submodule is split, the system replaces it with a black-box representation in the current module. This black-box representation can be a simple module declaration that only contains the name of the target submodule and its original port attributes, while its internal logic implementation is completely removed.

[0041] In summary, current techniques for estimating module physical size either rely on logical feature statistics, which result in significant discrepancies between the estimated size and the actual physical size, or lead to disastrous I / O overhead and time delays when using full-text scanning, and may even cause memory overflow in the processing script itself. This embodiment estimates the module's physical size using line number information extracted from a netlist parsing tool. This method cleverly avoids the huge overhead of full-text scanning while providing a more accurate physical size prediction than logical feature statistics, significantly improving the efficiency and accuracy of preprocessing. Regarding the integrity of module structure hierarchy references, relevant segmentation mechanisms often lack a deep understanding of the complex syntax of the underlying netlist when separating sub-modules at each level. This can easily lead to the loss or alteration of original port attributes, resulting in broken topological links between parent and child modules. This embodiment replaces the target sub-module with a black-box representation that retains its original port attributes, namely its port name, signal transmission direction, and bus width. This technique ensures that after physical splitting, the topological link relationship between the parent module and each level of sub-modules remains intact, effectively avoiding logical breaks caused by the loss of interface information and guaranteeing the correctness of subsequent parallel processing tools. In terms of adaptive boundary control in segmentation algorithms, traditional segmentation strategies often employ fixed depth or single-threshold triggering mechanisms. When processing large or complex netlist files, this may result in split files still exceeding the limit (if the threshold is too high) or generating a large number of tiny file fragments (if the threshold is too low), thus introducing significant scheduling and communication overhead. This embodiment achieves adaptive boundary control through a top-down recursive segmentation mechanism combined with dual threshold control of file size and recursive triggering thresholds. This dual-threshold strategy ensures that the size of the split sub-files is within a reasonable range, solving the problem of forced splitting of extremely large modules while effectively suppressing file fragmentation. This optimizes the scheduling efficiency of distributed tasks while ensuring the memory safety of downstream parallel processing tools.

[0042] Traditional methods of estimating size based on the number of modules or logical depth are inaccurate because the amount of text descriptions for different modules in an EDIF netlist file varies greatly—a large memory module may have thousands of lines of EDIF description, while a simple trigger may only have a few lines. Furthermore, in practical engineering applications, original netlist files are often stored compressed, and not all netlist files reach the required size for segmentation. Performing uniform parsing and segmentation on all files would result in unnecessary waste of computational resources and would fail to effectively identify compressed files, causing subsequent processing to be unable to accurately obtain the true physical size of the files, thus affecting the efficiency and accuracy of the segmentation strategy.

[0043] Provided Figure 2 and Figure 4The overall structure of the recursive adaptive segmentation algorithm based on row count estimation is shown in the diagram. It is split into multiple sub-netlist files according to the hierarchical nesting relationship of the netlist modules. Its core consists of five steps: step <1> File size pre-check; step <2> Line number information collection; step <3> Subtree row count calculation and caching; step <4> Recursive adaptive segmentation (core step); step <5> : Exporting the top-level module.

[0044] After receiving the raw netlist file, the process also includes a file size pre-check and preprocessing steps for compressed formats. A. Read the header of the original netlist file to identify whether a compression format identifier exists; Taking this embodiment as an example, after opening the EDIF file, the first two bytes are read. If the first two bytes are detected as a specific compression identifier (hexadecimal values ​​0x1F and 0x8B), then it is determined to be a gzip compression format.

[0045] B. If the file is identified as a compressed format, the original size after decompression will be used as the basis for determining the file size. If the file is confirmed to be in gzip compression format, read the original size before compression from the end of the file; otherwise, directly obtain the file size.

[0046] C. If the size of the original netlist file does not exceed the file size threshold, the original netlist file is marked as not split and directly passed to the subsequent device remapping step; For example, this application sets the size of each sub-file to not exceed a preset threshold (the default threshold is 50MB). If the file size is less than 50MB, it is marked as "not split", the file information is recorded, and it is directly passed to the subsequent stage; if the file size exceeds 50MB, it enters the splitting process.

[0047] The above steps, by introducing a preprocessing mechanism, effectively solve the technical problems of traditional methods when processing ultra-large netlist files in compressed formats, which involve huge disk I / O overhead, memory consumption, and the inability to quickly determine the file size before decompression due to the need for full decompression. Decompression and parsing are only performed when the file truly needs to be split, greatly reducing the computational resource consumption and time latency in the preprocessing stage, significantly improving the efficiency of preprocessing ultra-large netlist files, and effectively avoiding memory overflow problems that may be caused by blindly decompressing ultra-large files, laying a high-efficiency foundation for subsequent parallel processing.

[0048] In the above steps, before recursively splitting the determined netlist file, it is also necessary to perform the steps of collecting line number information, calculating the number of subtree rows, and caching. Figure 2This diagram illustrates file preprocessing, line number information collection, and subtree line number caching. The process is as follows: 1) Use a netlist parsing library to read the original EDIF netlist file and obtain the top-level netlist object, which represents the top-level module of the entire design; 2) Obtain the total number of rows in the EDIF netlist file from the parsing library; 3) Call the hierarchical traversal interface of the parsing library to obtain the complete set of netlist objects from top to bottom, that is, the set of modules at all levels contained in the top-level module; 4) For each netlist object, obtain its starting line number in the EDIF netlist file; 5) Sort all netlist objects by their starting row number; 6) For the sorted adjacent netlist objects, calculate their respective "number of lines" = the starting line number of the next netlist - the starting line number of the current netlist (the number of lines of the last netlist = the total number of lines in the file - its starting line number). 7) Establish a mapping relationship between each netlist object and its own row number, and store it in the row number mapping table.

[0049] This stage involves establishing the hierarchical nesting structure of each (decompressed) original EDIF netlist file object to be segmented, including its top-level module and various sub-modules, forming a complete mapping relationship between netlist objects and line counts. Furthermore, the line count information of each sub-module is extracted to determine the file's physical size and for dual-threshold judgment.

[0050] For example, the system receives a 2GB raw EDIF netlist file. The system determines that the file needs to be split. It then launches a netlist parsing tool, which begins parsing the raw EDIF netlist file. This tool identifies module definition keywords in the file and parses the entire netlist file into a hierarchical module structure. For example, top-level module A contains sub-modules B, C, and D, and sub-module B contains grandchild modules E and F, and so on. During the parsing process, the tool records the start and end line numbers of each module in the original file.

[0051] Furthermore, when traditional netlist files process complex netlists with deeply nested structures, performing a full tree traversal for each module will generate a large amount of redundant computation overhead, resulting in low estimation efficiency. Moreover, when dealing with extremely large-scale netlists, frequent traversal operations will significantly increase the consumption of memory and computing resources.

[0052] To address this, this application introduces a subtree row count calculation and cache verification mechanism, which performs the following steps when calculating the estimated total physical size: 1) Construct a subtree row count cache table in memory to store the total number of subtree rows of each level of netlist objects that have been calculated; 2) For any current module, the method for calculating the total number of rows in its subtree is as follows: a) When calculating the estimated total physical size of a current module, first check if there is already a record in the <subtree row count cache table>; b) If the record for this module is found in the subtree row count cache table, return the cached value directly; c) If the record for this module is not found in the subtree row count cache table, the hierarchical traversal interface of the parsing library is called to obtain all descendant modules of the netlist object to be calculated, the row count of each descendant module in the row count mapping table is accumulated, the result is stored in the cache and returned.

[0053] When calculating the estimated total physical size of a current module, if the module's record is not found in the subtree row count cache table, all descendant modules of the current module are traversed. The row count mapping table is queried, and the row counts of each descendant module are accumulated. The accumulated result is stored in the subtree row count cache table as the total row count of the current module's subtree. Further, the estimated total physical size of the current module can be obtained.

[0054] The above steps effectively address the performance bottleneck caused by repeated subtree traversal during recursive computation by introducing a subtree size caching mechanism. Building a subtree row count cache table in memory persistently stores the already calculated module size information. When the same module is accessed again in subsequent recursive processes, the result is directly read from the cache, avoiding repeated scanning and accumulation calculations of the same subtree structure. By performing traversal accumulation and storing the result in the cache when the cache is not hit, a logical closed loop in the computation process is ensured. This allows the system to significantly reduce computational redundancy in large-scale netlist parsing by trading space for time. This cache-based dynamic programming approach not only optimizes the execution efficiency of physical size estimation but also reduces the overall I / O pressure of the system by reducing repeated reading and parsing of the original netlist file. Therefore, while ensuring the accuracy of the estimation, it fundamentally prevents memory overflow in the preprocessing stage and improves the overall response speed of netlist splitting preprocessing.

[0055] In this embodiment, the solution estimates the physical size of each module based on the row number information extracted by the netlist parsing tool, which can be achieved in the following way: A. Obtain the total number of rows and the size of the original netlist file in bytes; B. Use a netlist parsing tool to obtain the starting line number of each module in the original netlist file, and determine the number of lines of each module based on the difference between the starting line numbers of adjacent modules; C. Calculate the estimated physical size of each module. It satisfies the following relationship:

[0056] in, This is the number of rows in the module itself. This represents the total number of rows in the original netlist file. This represents the original file size in bytes.

[0057] The following is a concrete example to illustrate this. Suppose there is an original EDIF netlist file named `top_design.edif`, whose physical size... 100MB, total number of lines It contains 1,000,000 lines. The file contains multiple modules, such as ` `、` `and` First, the system will obtain the information through the file system API. and Next, when the netlist parsing tool parses the `top_design.edif` file and builds its hierarchical structure, it records the starting line number of each module. For example, ` The definition of ` begins on line 1000. The definition of ` begins on line 100000. The definition of ` begins at line 500,000. Based on these starting line numbers, the line number of each module can be determined:` ` its own row number Okay; ` its own row number Okay; ` its own row number Okay. Finally, calculate the estimated physical size of each module according to the formula: physical size estimate ;` physical size estimate ;` physical size estimate .

[0058] Through the above process, without performing a full text scan and character counting, by establishing a linear proportional mapping model between the number of lines and the physical byte size, a module physical size estimate with engineering-acceptable accuracy can be quickly obtained with extremely low computational overhead, providing reliable data support for subsequent adaptive splitting. It should be noted that in EDA gate-level netlist text, the syntactic structure exhibits extremely high repetition and regularity, and the number of lines and text byte occupancy show a high linear correlation. This estimation model can provide an engineering approximation with extremely low I / O overhead without performing a full disk character scan.

[0059] To mitigate the issue of single-line character length deviation caused by excessively long string parameters and complex initialization configurations in special modules, this solution also includes single-line character density correction and a fallback mechanism based on post-testing: (1) Pre-emptive character density correction When obtaining the starting line number of a module, a preset number of code lines within the module are randomly sampled, and the average character length of a single sampled line is calculated. At the same time, obtain the global average character length of the original netlist file. ; Calculate the character density correction factor The estimated physical size of each module can be corrected as follows:

[0060] When the single-line length of a module deviates significantly from the global average, the correction factor... It can automatically smooth out evaluation biases.

[0061] (2) Post-event verification and secondary downgrade splitting After independently splitting and exporting the subnetlist files, compare them with the preset file size threshold. Perform a check; if the value is greater than [a certain value] due to an extremely long line. If this happens, a fallback splitting process is triggered, using the sub-file as a new input netlist and forcing recursive splitting of its subordinate sub-modules until the actual physical byte size of all exported final split sub-netlist files is strictly less than [a certain value]. .

[0062] In actual application, no extreme cases as described above have occurred in this project, and the number of rows in the initial design phase is reasonably controlled to avoid the occurrence of extremely long rows. Therefore, the approximately linear proportional relationship emphasized in this embodiment still holds true.

[0063] In some embodiments, when splitting the current module (i.e., the current netlist object) into separate sub-netlist files independently, Figure 3 As shown, it can be executed cyclically using the following strategy: Step 310: Sort all submodules in the submodule list of the current module in descending order based on their respective total physical size estimates; Step 320: Establish the remaining total size variable, with the initial value being the estimated total physical size of the current module; Step 330: Sort the sub-modules with the largest estimated values ​​in descending order and select them as the target sub-modules; Step 340: If the estimated total physical size of a target submodule is greater than the lower limit threshold for segmentation (i.e., the file size threshold specified above), then it is split into a segmented subnet list file, and the estimated physical size of the target submodule is subtracted from the remaining total size variable. Step 350: If there are no sub-modules larger than the file size threshold, and the remaining total size of the current module is still not less than the recursion trigger threshold, pack and aggregate the n sub-modules smaller than the file size threshold in descending order to generate a combined split subnet list file with a total volume between the file size threshold and the recursion trigger threshold, and then peel it off. Step 360: Repeat the sequential extraction and splitting operations until the value of the remaining total size variable is less than the recursion trigger threshold, at which point the splitting stops.

[0064] A greedy strategy is an algorithm that makes the best or optimal choice at each step, aiming to achieve a globally optimal result. In this context, it refers to prioritizing the sub-modules that contribute the most to the total physical size of the current module during the partitioning process, in order to reduce the total physical size of the current module below a threshold as quickly as possible.

[0065] To prevent the extreme scenario where "the total size of the parent module far exceeds the recursion trigger threshold, but the sizes of its subordinate child modules are all smaller than the file size threshold," leading to premature splitting, this solution's greedy splitting algorithm includes a two-stage closed-loop control mechanism: When the estimated total physical size of the current module (When the recursive trigger threshold is reached): (1) Priority stripping phase for large modules: Iterate through the list of submodules and estimate the size of any single item. For sub-modules with a file size threshold, the sub-modules are independently split into segmented subnetlist files in descending order of estimated size, and replaced with abstract placeholder structures in the current module, and the remaining total size of the current module is updated. (2) Packaging and aggregation stage of residual small modules: If no individual item exists in the current module after the first stage... The submodules, but the remaining total size of the current module is still greater than The system automatically triggers the small module aggregation program: Select multiple smaller sub-modules in descending order and combine them into a package. When the cumulative package size reaches... When the scope is defined, the entire combination is split into a combined split subnetlist file, and each sub-module within it is uniformly replaced with the corresponding abstract placeholder structure in the current module; Repeat the above process to ensure that the final physical size of the current module's residual is forced to decrease. (or )the following.

[0066] In actual execution, if there is a lack of fine-grained control over the splitting boundaries, it is very easy to cause severe fragmentation of the split netlist files, resulting in a large number of tiny files, or the file size may still exceed the limit due to insufficient splitting depth, thereby causing excessive system scheduling overhead or memory overflow of downstream tools.

[0067] Therefore, this application proposes a dual-threshold control strategy, the specific control strategy of which is as follows: The file size threshold and recursion trigger threshold satisfy the following:

[0068] in For file size threshold, For recursive trigger threshold, ; The file size threshold is used as the upper limit for a single netlist file to suppress the generation of excessively small netlist file fragments; the recursion trigger threshold is used as a recursion trigger limit to ensure that the size of the parent module is forced to be continuously split and decomposed downwards.

[0069] `k` is a dynamic adjustment coefficient used to link the file size threshold and the recursion trigger threshold, ensuring a reasonable proportional relationship between the two thresholds. This allows the splitting strategy to both avoid fragmentation and guarantee effective splitting. This dual threshold can be combined with a greedy strategy to ensure that, when the recursion trigger condition is met, the largest submodule is split first, in order to reduce the size of the parent module as quickly as possible.

[0070] In one possible implementation, the following specific parameters can be set:

[0071] The 100MB recursive threshold is twice the 50MB splitting lower limit. This ensures that when the size of the parent module (calculated by the number of lines) plus the size of the unsplit child modules exceeds 100MB, the system will continue to split until it drops to a reasonable range. The 50MB lower limit ensures that a large number of extremely small split files are not generated, thus avoiding excessive scheduling overhead.

[0072] The selection of thresholds and coefficients is based on the total number of modules, the maximum nesting depth, and the physical size distribution of modules at each level. When the total number of modules in the netlist is large but the size of each sub-module is small and evenly distributed, the system recommends setting the file size threshold to be comparable to the typical size of the sub-module, and taking a value close to 1 for k, so that the recursion trigger threshold is slightly higher than the file size threshold, avoiding insufficient splitting due to an excessively large threshold. When the netlist has a deep nesting level (e.g., more than 4 levels) and the size of each level of modules decreases, the system recommends taking a medium value for k (e.g., k=0.7) to balance the relationship between recursion depth and file fragmentation. When there are a few particularly large modules in the netlist and the rest of the modules are small (i.e., the size distribution has a long tail feature), the system recommends taking a value close to 0.5 for k to ensure that large-scale modules can be fully recursively split, while the file size threshold remains at its default value to prevent fragmentation. After completing the above analysis, the system presents the recommended threshold combination and k value as suggested values ​​to the user, while reserving the default value (file size threshold 50MB, recursion trigger threshold 100MB, k=0.5) as a fallback. Users can adjust the above parameters themselves through the configuration interface provided by the software, based on factors such as the memory limitations of the actual project, the number of parallel nodes, and the processing capabilities of downstream tools, and then run iteratively.

[0073] Figure 4 This is a schematic diagram illustrating the principle of recursive adaptive partitioning and top-level module export. Using the netlist file in the diagram as an example, the input is the current netlist object, and the output is the total number of rows in the subtrees of the partitioned netlist. Execution process: 1) Collect the subnetlist list: Iterate through all instance references of the current netlist, collect the netlist objects pointed to by each instance, and form the subnetlist list; 2) Preprocessing submodule: For each subnettable object in the <subnettable list> (skipping those marked as black boxes): a) Retrieve the total number of subtree rows in the current netlist from the subtree row count cache table; b) Convert the number of lines to megabytes (MB): Subnet table estimated size (MB) = (Number of subtree lines in subnet table / Total number of lines in EDIF file) × Original size of EDIF file (bytes) / (1024 × 1024); c) If the estimated size of the subnet table is greater than or equal to the recursion trigger threshold (default 100MB), then the aforementioned steps are recursively called. <4> Perform a split on the <subnet list> and use the updated subtree row count after the split; 3) Sorting and total calculation: a) Sort the subnet lists at each level in the <Subnet List> by estimated size from largest to smallest, and store the sorted subnet lists in the <Subnet List Size Sort Table>. b) Calculate the total estimated size of the current netlist = the size converted from the number of rows in the current netlist itself + the sum of the estimated sizes of all subnetlists; 4) Greedy partitioning loop: When the total estimated size of the current netlist is greater than or equal to the recursion trigger threshold (default 100MB), execute the following loop: a) Extract the subnet table with the largest estimated size, <Maximum Subnet Table>, from the <Subnet Table Size Sort Table>. b) If the estimated size of the <maximum subnet> is greater than the lower threshold for partitioning (default 50MB), then perform an independent partitioning operation on it: i. Write the contents of the <maximum subnetlist> into a separate EDIF subnetlist file (gzip compressed format). ii. In the current netlist, replace the maximum subnet list with an abstract placeholder structure (e.g., marked as a black box), retain only the port interface information, and remove the internal implementation; iii. Subtract the estimated size of the <maximum subnet table> from the total estimated size, and remove the subnet table from the <subnet table size sorting table>; c) If there is no subnetlist with an estimated size greater than the file size threshold, but the total estimated size of the current netlist is still greater than or equal to the recursion trigger threshold (default 100MB), then perform packing aggregation splitting: i. Select n smaller subnet lists with estimated sizes less than the file size threshold in descending order and combine them into a package, so that the cumulative estimated size of the combination is between the file size threshold and the recursion trigger threshold (i.e., 50MB ≤ combined size < 100MB). ii. Extract the entire package and write it into a separate EDIF subnetlist file (gzip compression format); iii. In the <Current Netlist>, mark all n sub-netlists within this combination as black boxes, retain only the port interface information, and remove the internal implementation; iv. Subtract the cumulative estimated size of this combination from the total estimated size, and remove these n subnets from the <subnet size sorting table>; d) Continue checking the next largest subnet table; 5) Update cache: Recalculate the total number of rows in the subtrees of the current netlist. Subnets that have been segmented and marked as black boxes are no longer counted in the internal row count. Update the subtree row count cache table. 6) Return the total number of rows in the updated subtree.

[0074] The following example will provide a more detailed explanation of the above technical solution: Suppose user A possesses a massive raw netlist file, physically 2GB in size, describing a complex integrated circuit design. This file needs to be processed by a parallel EDA toolchain, but its enormous size means direct processing would result in a memory overflow. The method proposed in this embodiment is used to preprocess this file.

[0075] First, in step S1, the system receives the 2GB raw EDIF netlist file. The preset file size threshold is set to 50MB. Since 2GB is greater than 50MB, the system determines that the file needs to be split. The netlist parsing tool is then launched, and it begins parsing the raw EDIF netlist file. This tool identifies module definition keywords in the file and parses the entire netlist file into a hierarchical module structure. For example, top-level module A contains sub-modules B, C, and D, and sub-module B contains grandchild modules E and F, and so on. During the parsing process, the tool records the start and end line numbers of each module in the original file.

[0076] Next, in step S2, the system estimates the physical size of each module based on the line number information extracted by the netlist parsing tool. For example, if the original 2GB netlist file has a total of 4 million lines, and a certain module occupies 400,000 lines in the original file, then its estimated physical size will be calculated as (400,000 lines / 4 million lines). 2GB = 200MB (approximate). The physical size estimates for all modules are calculated in this way.

[0077] Subsequently, in step S3, the system recursively splits the hierarchical module structure from top to bottom. The preset recursion trigger threshold is set to 100MB.

[0078] The system first traverses the top-level module A. Assuming the estimated total physical size of module A is 800MB, the system needs to split module A. The system selects a target submodule from the submodules of module A; for example, it selects submodule B with the largest estimated size (assuming its estimated total physical size is 110MB, greater than the recursion threshold of 100MB). Submodule B is then set as the new current module, and the system recursively performs the calculation of the estimated total physical size and the splitting operation on it. The system selects a target submodule from submodule B; for example, the largest of these is submodule E (assuming its estimated total physical size is 50MB). Submodule E is independently split into a segmented subnetlist file and replaced with a black-box representation in submodule B. At this point, the size of the subtree of module B is updated to 110MB - 50MB = 60MB.

[0079] After recursively processing all submodules of top-level module A that exceed the recursion threshold and require recursive processing, the system iterates through the current submodules of A and their estimated total size. For example, when iterating to module B, whose size is 60MB, which exceeds the file splitting threshold, submodule B is independently split into a separate subnetlist file (e.g., named "sub_netlist_B.edif"), and its internal logic is removed from the original EDIF netlist file. Simultaneously, within module A, submodule B is replaced with a black-box representation. This black-box representation only contains the raw port attributes of submodule B, such as port name, signal transmission direction, and bus width, while its internal logic implementation is removed.

[0080] This process continues until the estimated total physical size of all split modules is less than the recursion trigger threshold of 50MB, or until no further effective splitting is possible. Ultimately, the original 2GB netlist file is split into multiple subnetlist files of manageable size; for example, multiple subnetlist files of 50-100MB may be generated, along with a top-level skeleton netlist file containing all black-box representations.

[0081] Through the above technical solution, this application effectively solves the problems of uneven file size and uncontrolled splitting boundaries in traditional splitting mechanisms. This greedy strategy, by prioritizing the splitting of large sub-modules, can rapidly reduce the overall size of the current module, ensuring that the split sub-netlist files meet the processing requirements of downstream tools while avoiding situations where the parent module cannot be effectively processed due to excessive residual size. Simultaneously, introducing a lower limit threshold for splitting effectively filters out excessively small sub-modules, preventing the generation of a large number of meaningless file fragments, thereby optimizing the storage efficiency of the file system and reducing the overhead of subsequent distributed job scheduling and task communication. Furthermore, by dynamically monitoring the remaining total size variable and using a recursive trigger threshold as the stopping condition, adaptive boundary control of the splitting process is achieved, ensuring that the split sub-netlist files are of balanced size and have a reasonable structure. This provides high-quality input data for subsequent parallel EDA toolchains, significantly improving the efficiency and stability of preprocessing ultra-large-scale netlist files.

[0082] In the above embodiments, after the top-down recursive decomposition is completed, the top-level module export step is executed. It should be noted that in the black-box representation stage, the raw port attributes refer to the basic characteristics of the module's external interface. Their function is to define the specifications for interaction between the module and other modules. These attributes can be extracted by parsing the port declaration statements in the netlist file, and they include at least one of the following: port name, signal transmission direction, and bus width.

[0083] The black box not only completely clones the original port attributes of the target submodule, but also retains the unique triplet identifier of the target submodule in the hierarchical module structure. The unique triplet identifier consists of the library name, unit name, and view name. Its function is to provide a globally unique identity for the module in a complex hierarchical design, which facilitates tracking and recovery.

[0084] When exporting the top-level module, the top-level module architecture containing all black-box representations is retained and exported separately as an independent top-level skeleton netlist file (i.e., the top-level EDIF file, at which point its descendant modules have all been segmented and marked as black boxes). The top-level skeleton netlist file and all segmented subnetlist files are uniformly marked as compressed and persistently stored. All information of the segmented netlist files (filename, size, path, etc.) is recorded in the record table.

[0085] Furthermore, when applying the split netlist files to the downstream EDA toolchain, a lack of targeted scheduling strategies can lead to memory overflows in downstream tools when processing extremely large netlists due to excessive load on a single node, and the inability to fully utilize distributed computing resources for efficient parallel analysis. This application, as a large file preprocessing operation, sends the output split sub-netlist files to the parallel EDA toolchain.

[0086] A "parallel EDA toolchain" refers to a software system composed of multiple EDA tools that can work together and support parallel computing. These tools are typically used in different stages of integrated circuit design, such as logic synthesis, placement and routing, timing analysis, power analysis, formal verification, and simulation. The parallel EDA toolchain, based on the estimated physical size of each sub-netlist file, evenly distributes it across multiple parallel task nodes to perform device remapping, timing analysis, or simulation, thus avoiding memory overflows triggered by a single node reading an extremely large netlist file at once.

[0087] Figure 5 This application illustrates an adaptive splitting apparatus for netlist files based on row count estimation, the apparatus comprising: The file parsing module 510 is used to receive the original netlist file. When the physical size of the original netlist file is greater than the preset file size threshold, the netlist parsing tool is used to parse the original netlist file into a hierarchical module structure. The file estimation module 520 is used to estimate the physical size of each module in the hierarchical module structure based on the line number information extracted by the netlist parsing tool. The recursive splitting module 530 is used to perform recursive splitting on the hierarchical module structure from top to bottom: for the current module being traversed, its total physical size estimate is calculated; when the total physical size estimate is greater than or equal to the preset recursive trigger threshold, the target sub-module in the current module is selected and independently split into a split subnet list file, and the target sub-module in the current module is replaced with an abstract placeholder structure representation that retains the original port attributes but removes the internal logic implementation; If the recursion trigger threshold is greater than the file size threshold, the split target sub-module is recursively executed as the new current module to calculate the estimated total physical size and perform the splitting operation.

[0088] Furthermore, this application also provides a computer device, the computer device including a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement the adaptive splitting method for netlist files based on row number estimation described above.

[0089] Furthermore, this application also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the adaptive splitting method for netlist files based on row number estimation described above.

[0090] The adaptive splitting device for netlist files based on row number estimation provided in this application embodiment can be applied to the adaptive splitting method for netlist files based on row number estimation provided in the above embodiments. For relevant details, please refer to the above method embodiments. The implementation principle and technical effect are similar, and will not be repeated here.

[0091] It should be noted that the adaptive splitting device for netlist files based on row number estimation provided in this embodiment is only illustrated by the above-described division of functional modules / units. In practical applications, the functions can be assigned to different functional modules / units as needed, that is, the internal structure of the adaptive splitting device for netlist files based on row number estimation can be divided into different functional modules / units to complete all or part of the functions described above. Furthermore, the implementation method of the adaptive splitting method for netlist files based on row number estimation provided in the above method embodiments and the implementation method of the adaptive splitting device for netlist files based on row number estimation provided in this embodiment belong to the same concept. For details of the specific implementation process of the adaptive splitting device for netlist files based on row number estimation provided in this embodiment, please refer to the above method embodiments, which will not be repeated here.

[0092] Figure 6This illustration shows a structural block diagram of a computer device provided in an exemplary embodiment of this application. The device can be a desktop computer, laptop computer, handheld computer, or cloud server, etc. The computer device may include, but is not limited to, a processor and memory. The processor and memory can be connected via a bus or other means. The processor can be a Central Processing Unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, graphics processing units (GPUs), embedded neural network processing units (NPUs) or other dedicated deep learning coprocessors, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0093] This application also discloses a computer-readable storage medium. Specifically, the computer-readable storage medium is used to store a computer program, which, when executed by a processor, implements the methods described in the above-described method embodiments. Those skilled in the art will understand that implementing all or part of the processes in the methods described in the above-described embodiments of this application can be accomplished by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0094] This specific embodiment is merely an explanation of the present invention and is not intended to limit the invention. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of the present invention.

Claims

1. An adaptive splitting method for netlist files based on row count estimation, characterized in that, The method includes: Receive the original netlist file. When the physical size of the original netlist file is greater than a preset file size threshold, use a netlist parsing tool to parse the original netlist file into a hierarchical module structure. Based on the row number information extracted by the netlist parsing tool, the estimated physical size of each module in the hierarchical module structure is estimated. The hierarchical module structure is recursively split from top to bottom: For the current module being traversed, its total physical size is estimated; when the total physical size estimate is greater than or equal to a preset recursion trigger threshold, a target submodule is selected in the current module and independently split into segmented subnetlist files using a greedy strategy, and the target submodule is replaced in the current module with an abstract placeholder structure representation that retains the original port attributes but removes the internal logic implementation; the greedy strategy is as follows: Sort all submodules in the submodule list of the current module in descending order based on their respective total physical size estimates; Establish a variable for the remaining total size, and sequentially select the sub-modules with the largest estimated values ​​in descending order as the target sub-modules; the initial value is the estimated total physical size of the current module. If the estimated total physical size of the target submodule is greater than the file size threshold, it is split into the segmented subnet table file, and the estimated total physical size of the target submodule is subtracted from the remaining total size variable. If there are no sub-modules larger than the file size threshold, and the remaining total size of the current module is still not less than the recursion trigger threshold, then the n sub-modules smaller than the file size threshold are packaged and aggregated in descending order to generate a combined split subnet list file with a total volume between the file size threshold and the recursion trigger threshold, and then the subnet list file is stripped. Repeat the sequential extraction and splitting operation until the value of the remaining total size variable is less than the recursion trigger threshold, at which point the splitting stops. Wherein, if the recursion trigger threshold is greater than the file size threshold, the split target sub-module is recursively executed as the new current module to calculate the total physical size estimate and split the module.

2. The method according to claim 1, characterized in that, After receiving the raw netlist file, a preprocessing step for the compressed format is also included: Read the header signature of the original netlist file; If the file header signature matches the compression format, the original byte size before decompression is directly read from the data segment set at the end of the compression format, and the original byte size is used as the basis for determining whether it is greater than the file size threshold.

3. The method according to claim 1, characterized in that, The estimation of the physical size of each module based on the row number information extracted by the netlist parsing tool includes: Obtain the total number of lines and the original file size in bytes of the original netlist file; The starting line number of each module in the original netlist file is obtained using a netlist parsing tool, and the number of lines of each module is determined based on the difference between the starting line numbers of adjacent modules. Calculate the estimated physical size of each module. It satisfies the following relationship: in, This is the number of rows in the module itself. This represents the total number of rows in the original netlist file. This represents the original file size in bytes.

4. The method according to claim 3, characterized in that, The calculation of the total physical size estimate includes a subtree-scale caching step: Build a subtree row count cache table in memory; When calculating the estimated total physical size of a current module, if the record of the module is not found in the subtree row count cache table, all descendant modules of the current module are traversed, the row count of the descendant modules is accumulated as the total row count of the subtree of the current module and stored in the subtree row count cache table, and the estimated total physical size of the current module is obtained according to the conversion formula.

5. The method according to claim 1, characterized in that, The file size threshold and the recursion trigger threshold satisfy the following: in For file size threshold, For recursive trigger threshold, ; The file size threshold is used as the upper limit for a single netlist file to suppress the generation of excessively small netlist file fragments; The recursive trigger threshold is used as a recursive trigger limit to ensure that the size of the parent module is forced to be continuously divided and decomposed downwards.

6. The method according to claim 1, characterized in that, The original port attributes include at least: port name, signal transmission direction, and bus width; The abstract placeholder structure not only completely clones the original port attributes of the target submodule, but also retains the unique triplet identifier of the target submodule in the hierarchical module structure. The unique triplet identifier consists of the library name, unit name, and view name.

7. The method according to claim 1, characterized in that, After the top-down recursive splitting is complete, it also includes: The top-level module architecture containing all the abstract placeholder structure representations is retained, exported separately as a top-level skeleton netlist file, and the top-level skeleton netlist file and all the segmented subnetlist files are uniformly marked as compressed and persistently stored.

8. The method according to any one of claims 1 to 7, characterized in that, The method is used as a large file preprocessing operation, and the output segmented subnet list file is sent to a parallel EDA toolchain. The parallel EDA toolchain schedules each of the segmented subnetlist files to multiple parallel task nodes based on the estimated physical size of the subnetlist files, performing device remapping, timing analysis, or simulation, in order to avoid a single node reading an ultra-large netlist file at once and triggering a memory overflow.

9. An adaptive splitting device for netlist files based on row count estimation, characterized in that, The device includes: The file parsing module is used to receive the original netlist file. When the physical size of the original netlist file is greater than a preset file size threshold, the netlist parsing tool is used to parse the original netlist file into a hierarchical module structure. The file estimation module is used to estimate the physical size of each module in the hierarchical module structure based on the row number information extracted by the netlist parsing tool. The recursive splitting module is used to perform recursive splitting of the hierarchical module structure from top to bottom: For the current module being traversed, its total physical size estimate is calculated; when the total physical size estimate is greater than or equal to a preset recursion trigger threshold, a target sub-module is selected in the current module and independently split into segmented subnetlist files using a greedy strategy, and the target sub-module is replaced in the current module with an abstract placeholder structure representation that retains the original port attributes but removes the internal logic implementation; the greedy strategy is as follows: Sort all submodules in the submodule list of the current module in descending order based on their respective total physical size estimates; Establish a variable for the remaining total size, and sequentially select the sub-modules with the largest estimated values ​​in descending order as the target sub-modules; the initial value is the estimated total physical size of the current module. If the estimated total physical size of the target submodule is greater than the file size threshold, it is split into the segmented subnet table file, and the estimated total physical size of the target submodule is subtracted from the remaining total size variable. If there are no sub-modules larger than the file size threshold, and the remaining total size of the current module is still not less than the recursion trigger threshold, then the n sub-modules smaller than the file size threshold are packaged and aggregated in descending order to generate a combined split subnet list file with a total volume between the file size threshold and the recursion trigger threshold, and then the subnet list file is stripped. Repeat the sequential extraction and splitting operation until the value of the remaining total size variable is less than the recursion trigger threshold, at which point the splitting stops. Wherein, if the recursion trigger threshold is greater than the file size threshold, the split target sub-module is recursively executed as the new current module to calculate the total physical size estimate and split the module.

Images