A multi-module aggregation method and related equipment

Abstract

The present application discloses a multi-module aggregation method and related equipment, and relates to the field of electronic design automation. The method comprises: obtaining a superior file; obtaining port information of the superior file based on the superior file, and storing the port information of the superior file in a superior file port information list; determining an instantiation module to be merged based on the superior file; obtaining port information of an instantiation module to be merged corresponding to the instantiation module to be merged, and storing the port information of the instantiation module to be merged in a port information list of the instantiation module to be merged; performing signal deduplication operation, port analysis and signal definition operation, and renaming and comparison connection operation based on the superior file port information list and the instantiation module port information list to be merged to generate a new merged file; and saving the instantiation part of the new merged file in the superior file.

Description

Technical Field

[0001] The present specification relates to the field of electronic design automation, and more specifically, the present application relates to a multi-module aggregation method and related equipment. Background Art

[0002] Currently, in integrated circuit design, engineers are often faced with the task of merging multiple Verilog modules into a top-level module. This merging operation usually involves a lot of manual operations and repetitive code editing, including but not limited to matching module ports, resolving signal naming conflicts, and combing module connection relationships. These manual merging steps are time-consuming and error-prone, especially when facing large-scale system designs, the complexity and workload increase exponentially.

[0003] Therefore, it is necessary to propose a multi-module aggregation method and related equipment to improve the automation level of multi-module aggregation. Summary of the invention

[0004] A series of simplified concepts are introduced in the Summary of the Invention section, which will be further described in detail in the Detailed Description of the Invention section. The Summary of the Invention section of this application does not mean to attempt to define the key features and essential technical features of the claimed technical solution, nor does it mean to attempt to determine the scope of protection of the claimed technical solution.

[0005] In a first aspect, the present application proposes a multi-module aggregation method, comprising:

[0006] Get the parent file;

[0007] Acquire the port information of the upper-level file based on the upper-level file, and store the port information of the upper-level file in the upper-level file port information list;

[0008] Determine the instantiation modules to be merged based on the above-mentioned superior file, wherein the above-mentioned superior file includes the instantiation modules to be merged, the instantiation modules that do not need to be merged, and the module list corresponding to the instantiation modules to be merged;

[0009] Acquire the port information of the instantiated modules to be merged corresponding to the instantiated modules to be merged, and store the port information of the instantiated modules to be merged in the instantiated module port information list to be merged;

[0010] Based on the above-mentioned upper-level file port information list and the above-mentioned instantiated module port information list to be merged, signal deduplication operation, port analysis and signal definition operation, and renaming and comparison connection operation are performed to generate a new merged file;

[0011] The instantiation part of the new merged file is saved in the parent file.

[0012] In a feasible implementation, the port information of the above-mentioned parent file is obtained based on the first regular expression, the above-mentioned instantiation module to be merged is obtained based on the second regular expression, and the port information of the above-mentioned instantiation module to be merged is obtained based on the third regular expression.

[0013] In one possible implementation,

[0014] The port information of the above-mentioned superior file includes superior file name information, superior file port direction information, superior file port type information and superior file port bit width information;

[0015] The port information of the instantiated modules to be merged includes instantiated module name information, instantiated module port direction information, instantiated module port type information and instantiated module port bit width information.

[0016] In a feasible implementation manner, the above-mentioned signal deduplication operation, port analysis and signal definition operation, and renaming and comparison connection operation are performed based on the above-mentioned upper-level file port information list and the above-mentioned instantiation module port information list to be merged to generate a new merged file, including:

[0017] Based on the above-mentioned upper-level file port information list and the above-mentioned instantiated module port information list to be merged, a signal deduplication operation is performed to remove the signals in the instantiated module port information list to be merged that overlap with the above-mentioned upper-level file port information list, and generate a deduplicated instantiated module port information list to be merged;

[0018] Perform port analysis and signal definition operations on the above-mentioned list of instantiated module port information to be merged, so as to determine the port information required for the merged module, and generate definition information of the above-mentioned required port information;

[0019] Rename and compare the remaining signal ports in the above-mentioned instantiated module port information list to be merged to generate a new merged file, wherein the remaining signals in the above-mentioned instantiated module port information list to be merged are the signal ports in the above-mentioned instantiated module port information list except the port information required by the above-mentioned merged module.

[0020] In a feasible implementation manner, the instantiation module to be merged based on the parent file includes:

[0021] Get the statement information corresponding to the specific identifier in the above parent file;

[0022] The specific identifier is removed to obtain the instantiation module to be merged corresponding to the statement information corresponding to the specific identifier, wherein the specific identifier is byte information used to distinguish the instantiation module to be merged, and the instantiation module to be merged is determined based on user selection.

[0023] In a feasible implementation manner, the instantiation modules to be merged are automatically generated based on a partition strategy, and the partition strategy is determined based on communication density, partition similarity, dependency, and resource constraint conditions.

[0024] In a feasible implementation, it also includes:

[0025] Determine an objective function based on the communication density, the partition similarity, and the dependency relationship;

[0026] Determine the partitioning strategy based on a heuristic algorithm according to the objective function and the resource constraints;

[0027] Among them, the above objective function is determined based on the following formula:

[0028]

[0029] The above constraints include resource constraints, partition integrity constraints and minimum partition communication density threshold conditions;

[0030] The above resource constraints are determined based on the following formula:

[0031]

[0032] Partition integrity constraints are determined based on the following formula:

[0033]

[0034] The minimum partition communication density threshold condition is determined based on the following formula:

[0035]

[0036] In the formula, is the objective function, is a partition in the partition set, is the set of all partitions, and For partition The two modules in For modules and The communication density between , for and The number of signal interactions between For modules and The total number of ports, For modules and The functional similarity between For modules and The dependency weight between is the first weight factor, is the second weight factor, is the third weight factor, For modules The resource consumption, The upper limit of the total amount of resources allowed for each partition, Indicates that the modules in all partitions are combined to cover the entire module set , Indicates that there is no overlap between modules in different partitions. is the minimum requirement for communication density within a partition, A collection of all modules.

[0037] In a second aspect, the present application proposes a multi-module aggregation device, comprising:

[0038] A first acquisition unit, used to acquire a parent file;

[0039] A second obtaining unit, configured to obtain the port information of the upper-level file based on the upper-level file, and store the port information of the upper-level file in the upper-level file port information list;

[0040] A first determining unit, configured to determine the instantiation modules to be merged based on the above-mentioned upper-level file, wherein the above-mentioned upper-level file includes the instantiation modules to be merged, the instantiation modules that do not need to be merged, and a module list corresponding to the instantiation modules to be merged;

[0041] A third acquisition unit, configured to acquire port information of the instantiated modules to be merged corresponding to the instantiated modules to be merged, and store the port information of the instantiated modules to be merged in a port information list of the instantiated modules to be merged;

[0042] A generating unit, configured to perform signal deduplication operations, port analysis and signal definition operations, and rename and compare connection operations based on the above-mentioned upper-level file port information list and the above-mentioned instantiation module port information list to be merged, so as to generate a new merged file;

[0043] The saving unit is used to save the instantiation part of the new merged file in the parent file.

[0044] In a third aspect, an electronic device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor is used to implement the steps of the multi-module aggregation method as described in any one of the first aspects above when executing the computer program stored in the memory.

[0045] In a fourth aspect, the present application further proposes a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the multi-module aggregation method of any one of the first aspects is implemented.

[0046] In summary, the multi-module aggregation method proposed in this application can use Python scripts to automate the processing of modules, which greatly reduces the time of manual operation compared to manual merging, especially for the merging requirements of multiple modules in large projects. The automated script can extract, analyze and process the port information and signal relationships of all modules at one time, and the efficiency of merging is greatly improved. Manual merging modules are prone to errors due to engineers' negligence, especially signal conflicts or disconnections. This application uses automated tools to remove and rename signal names and ports, effectively avoiding signal conflicts and connection errors, thereby reducing errors generated during the merging process. Using automated port analysis and renaming strategies, all ports are systematically checked and renamed to avoid naming conflicts. Compared with traditional manual methods, intelligent processing strategies are more standardized and efficient. In large-scale integrated circuit design, the sharp increase in the number of modules will lead to an increase in code complexity. This application simplifies the design hierarchy and improves the readability of the code through module merging. In addition, the automatically generated top-level module makes the code more standardized, which is helpful for subsequent maintenance and debugging. The method of the present application can be integrated into the existing EDA (Electronic Design Automation) tool chain as part of an automation tool or script to improve design efficiency. For example, it can be combined with prototype verification segmentation software to automatically handle module merging requirements at different stages of the design, thereby improving the overall automation level of the EDA tool chain. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present specification. Also, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0048] Figure 1 A schematic diagram of a multi-module aggregation method provided in an embodiment of the present application;

[0049] Figure 2 A schematic diagram of the structure of a multi-module polymerization device provided in an embodiment of the present application;

[0050] Figure 3 A schematic diagram of the structure of a multi-module aggregate electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices. The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments.

[0052] See also Figure 1 , is a schematic diagram of a multi-module aggregation method provided in an embodiment of the present application, the method comprising:

[0053] S110, obtaining superior files;

[0054] Exemplarily, a parent file is obtained, which is a Verilog file containing all modules to be merged and other instantiated modules, as a basis for the merging process.

[0055] S120, obtaining the port information of the upper-level file based on the upper-level file, and storing the port information of the upper-level file in the upper-level file port information list;

[0056] Exemplarily, based on the above-mentioned parent file, the port information of all modules is extracted, and the port information is stored in the parent file port information list, so that the port connection status can be quickly accessed and analyzed when merging.

[0057] S130, determining the instantiation modules to be merged based on the above-mentioned upper-level file, wherein the above-mentioned upper-level file includes the instantiation modules to be merged, the instantiation modules that do not need to be merged, and the module list corresponding to the instantiation modules to be merged;

[0058] Exemplarily, based on the parent file, it is determined which modules need to be merged. The parent file usually contains three types of modules: instantiation modules to be merged, instantiation modules that do not need to be merged, and a list of related modules of the modules to be merged.

[0059] The instantiation modules to be merged are the modules that need to be merged currently. The instantiation modules that do not need to be merged, that is, these modules do not participate in this merge. The related module list of the module to be merged lists the modules associated with the module to be merged to help with subsequent merging.

[0060] S140, obtaining the port information of the instantiated modules to be merged corresponding to the instantiated modules to be merged, and storing the port information of the instantiated modules to be merged in the instantiated module port information list to be merged;

[0061] Exemplarily, specific port information of instantiated modules to be merged is extracted and stored in a list of port information of modules to be merged.

[0062] S150, performing signal deduplication operation, port analysis and signal definition operation, and renaming and comparison connection operation based on the above-mentioned upper-level file port information list and the above-mentioned instantiation module port information list to be merged, so as to generate a new merged file;

[0063] Exemplarily, based on the port information list of the superior file and the port information list of the module to be merged, signal deduplication operations, port analysis and signal definition operations, and renaming and comparison connection operations are performed. Signal deduplication operations include but are not limited to automatically checking signal names and eliminating duplicate signals to avoid conflicts. Port analysis and definition include but are not limited to confirming which signals are generated and used between these modules that need to be merged, taking them out of the port information, and generating corresponding intra-module signal definitions for use in signal transmission between modules. Renaming and comparison connection include but are not limited to renaming the remaining signals in the list according to their original module names as ports of the merged file, and comparing and connecting the corresponding signals with the instantiated module list to generate a new merged file.

[0064] S160. Save the instantiation part of the new merged file in the parent file.

[0065] Exemplarily, the instantiation part of the generated new merged file is finally saved into the parent file, thereby obtaining a complete top-level module.

[0066] It should be noted that the above method can be implemented based on Python scripts.

[0067] In summary, the present application can use Python scripts to automate the processing of modules, which greatly reduces the time of manual operation compared to manual merging, especially for the merging requirements of multiple modules in large projects. The automated script can extract, analyze and process the port information and signal relationships of all modules at one time, and the efficiency of merging is greatly improved. Manual merging of modules is prone to errors due to negligence of engineers, especially signal conflicts or disconnections. The present application uses automated tools to remove and rename signal names and ports, effectively avoiding signal conflicts and connection errors, thereby reducing errors generated during the merging process. Using automated port analysis and renaming strategies, all ports are systematically checked and renamed to avoid naming conflicts. Compared with traditional manual methods, intelligent processing strategies are more standardized and efficient. In large-scale integrated circuit design, the sharp increase in the number of modules will lead to an increase in code complexity. The present application simplifies the design hierarchy and improves the readability of the code through module merging. In addition, the automatically generated top-level module makes the code more standardized, which is helpful for subsequent maintenance and debugging. The method of the present application can be integrated into the existing EDA (Electronic Design Automation) tool chain as part of an automated tool or script to improve design efficiency. For example, it can be combined with prototype verification segmentation software to automatically handle module merging requirements at different stages of the design, thereby improving the overall automation level of the EDA tool chain.

[0068] In some examples, the port information of the above-mentioned parent file is obtained based on a first regular expression, the above-mentioned instantiation module to be merged is obtained based on a second regular expression, and the port information of the above-mentioned instantiation module to be merged is obtained based on a third regular expression.

[0069] Exemplarily, regular expressions are used to automatically parse the contents of Verilog files, mainly including obtaining port information, identifying modules to be merged, and obtaining port information of modules to be merged. The use of regular expressions makes the processing process fast and accurate, and can adapt to files of different formats.

[0070] The first regular expression can be expressed as:

[0071] port_patten = r"(input|output)\s+(wire|reg)?(\[(.+)?:(\w+)])?(\w+)"

[0072] This regular expression is used to extract the module's port definition information from the parent file, including the port type, signal type, and port name. Its structure is relatively complex, and the meaning of each part is explained step by step below:

[0073] (input|output): matches the port type, which can be input or output.

[0074] This part uses the selector symbol (|) to match input or output.

[0075] \s+: matches at least one blank character, indicating that there is a space between the port type and the signal type or bit width.

[0076] (wire|reg)?: matches the signal type, which may be wire or reg, indicating the specific type of the port. The ? at the end indicates that this part is optional, that is, there may be no signal type.

[0077] (\[(.+)?:(\w+)])?: Matching bit width information, which is usually used to describe vector signals, such as [7:0]. The detailed description is as follows:

[0078] \[: Matches a left square bracket [.

[0079] (.+)?: matches the optional high-order index part, which may be a specific number or variable, indicating the highest bit of a multi-bit signal. ? indicates that the part is optional.

[0080] :(\w+): matches the low index after the colon:, usually a number or identifier.

[0081] \]: Matches a right square bracket ].

[0082] The entire bit width portion is indicated by ? as optional, since scalar ports (non-vector) have no bit width information.

[0083] (\w+): matches the port name. \w+ is used to represent an identifier consisting of one or more letters, numbers, or underscores.

[0084] The second regular expression may be determined based on one or more of a specific prefix, suffix, and comment information, thereby determining the port information of the instantiation module to be merged;

[0085] The third regular expression can be expressed as:

[0086] signal_patten = r" (wire|reg)(\[(.+)?:(\w+)])?(\w+)"

[0087] This regular expression is used to extract the signal definition information of the module to be merged, including signal type, bit width information and signal name. The specific explanation is as follows:

[0088] (wire|reg): Matches the signal type, which can be either wire or reg. This means that the signal in the module to be merged can be one of the two types, wire or reg.

[0089] (\[(.+)?:(\w+)])?: matches bit width information, similar to the part in the first regular expression, used to describe multi-bit signals. The detailed explanation is as follows:

[0090] \[: Matches a left square bracket [.

[0091] (.+)?: Matches an optional high index part, which may be a specific number or variable.

[0092] :(\w+): matches the low-order index after the colon:, indicating the low-order boundary of the signal.

[0093] \]: Matches a right square bracket ].

[0094] The entire bit width is indicated by ? as optional, since the signal may be scalar instead of vector.

[0095] (\w+): matches the signal name. \w+ is used to represent an identifier consisting of one or more letters, numbers, or underscores.

[0096] In some examples,

[0097] The port information of the above-mentioned superior file includes superior file name information, superior file port direction information, superior file port type information and superior file port bit width information;

[0098] The port information of the instantiated modules to be merged includes instantiated module name information, instantiated module port direction information, instantiated module port type information and instantiated module port bit width information.

[0099] Exemplarily, the parent file contains the top-level module of the entire design or a larger design module. To realize multi-module merging, it is first necessary to extract and understand the port information of the parent file, which includes the following aspects: parent file name information, parent file port direction information, parent file port type information and parent file port width information.

[0100] The parent file name information refers to the module name of the parent file (top-level module). The parent file port direction information describes the role of the port in the circuit, which may be an input port, an output port, or a bidirectional port. The parent file port type information refers to the specific signal type of the port, such as wire or reg. The port width information indicates the width of the port signal, which is usually a scalar signal or a vector signal.

[0101] The instantiation modules to be merged are usually part of the parent file, these modules are instantiated in the parent file, and the goal of merging is to merge these modules into a larger, comprehensive module. In this embodiment, the port information of the modules to be merged also includes the following aspects: instantiation module name information, instantiation module port direction information, instantiation module port type information and instantiation module port bit width information.

[0102] The instantiation module name information refers to the module name of the module to be merged. The instantiation module port direction information is similar to the port direction of the parent file, which refers to the direction of each port in the instantiation module. The port type information describes the type of the module port, such as wire or reg. The port width information refers to the width of the port signal of the module to be merged.

[0103] In some examples, the signal deduplication operation, port analysis and signal definition operation, and renaming and comparison connection operation are performed based on the above-mentioned upper-level file port information list and the above-mentioned instantiation module port information list to be merged to generate a new merged file, including:

[0104] Based on the above-mentioned upper-level file port information list and the above-mentioned instantiated module port information list to be merged, a signal deduplication operation is performed to remove the signals in the instantiated module port information list to be merged that overlap with the above-mentioned upper-level file port information list, and generate a deduplicated instantiated module port information list to be merged;

[0105] Perform port analysis and signal definition operations on the above-mentioned list of instantiated module port information to be merged, so as to determine the port information required for the merged module, and generate definition information of the above-mentioned required port information;

[0106] Rename and compare the remaining signal ports in the above-mentioned instantiated module port information list to be merged to generate a new merged file, wherein the remaining signals in the above-mentioned instantiated module port information list to be merged are the signal ports in the above-mentioned instantiated module port information list except the port information required by the above-mentioned merged module.

[0107] Exemplarily, the signal deduplication operation is used to remove the signals in the instantiation module port information list to be merged that overlap with the port information list of the parent file. The purpose of this process is to ensure that signals do not appear repeatedly in the merged file, thereby avoiding signal name conflicts.

[0108] Traverse the port information of the module to be merged and check whether they exist in the port information of the parent file. If the port of the module to be merged has the same name as the port of the parent file, remove the port from the port information list of the module to be merged. The port information column of the module to be merged after deduplication: contains the port information without the port name duplication with the port name of the parent file. These remaining ports are the ports that do not conflict with the parent module.

[0109] Perform port analysis and signal definition operations on the port information list of the modules to be merged after deduplication to determine the port information that needs to be retained and transmitted in the merged module, and generate relevant signal definitions. Analyze all ports to determine which signals are used internally between the modules to be merged, and which signals need to be exposed as ports in the top-level merged module. Extract the signals used to be transmitted between modules from the port information. These signals will not appear in the top-level ports of the final merged module, but as signals inside the module. For internal signals that need to be transmitted between modules, generate corresponding signal definition information, which are used for communication between modules in the merged module.

[0110] After completing the port analysis, the remaining work is to rename the ports of the modules to be merged after deduplication and compare the connections to generate a new merged file. Rename the ports in the port information of the modules to be merged that are not included in the top level of the merged module. Usually, they are renamed according to their original module names to avoid conflicts. For example, if the original signal name is data, it can be renamed to mod1_data according to the module name.

[0111] Classify all port information, and use those ports that need to be exposed to the upper-level modules as the top-level ports of the new merged module. Define the signals that need to interact between modules as internal signals to ensure that the modules can communicate correctly. Check all signals that need to be connected to ensure that the direction, type, and bit width of the connected signals are consistent with those of the modules to be merged. Connect the ports of the modules to be merged to the ports of the merged module through signals to form a complete connection relationship. The new merged file contains the code for all module instantiations that have undergone signal deduplication, port analysis, renaming, and connection.

[0112] In some examples, determining the instantiation module to be merged based on the parent file includes:

[0113] Get the statement information corresponding to the specific identifier in the above parent file;

[0114] The specific identifier is removed to obtain the instantiation module to be merged corresponding to the statement information corresponding to the specific identifier, wherein the specific identifier is byte information used to distinguish the instantiation module to be merged, and the instantiation module to be merged is determined based on user selection.

[0115] Exemplarily, statement information corresponding to a specific identifier is obtained from a parent file. The parent file may contain many instantiations of modules, and certain specific identifiers (such as a prefix or suffix of a module name, comment information, etc.) are used to distinguish which modules are to be merged.

[0116] Specific identifiers are used to mark which modules are candidate modules to be merged. They can be defined in the following ways: For example, if the names of the modules to be merged all have a prefix (such as "merge_"), this prefix can be used as a specific identifier to identify the modules to be merged. There may be some comments in the module instantiation code to mark which modules need to be merged. These comments can be used as specific identifiers. All module instantiation instances that match the specific identifier are found from the parent file through regular expressions or other parsing methods, and the relevant statement information of these instantiation modules is extracted.

[0117] By parsing the parent file, find all module instantiation statements. For each instantiation statement, check whether it contains a specific identifier, such as a prefix, suffix, or comment. If a match is successful, the module is a candidate for merging. Extract all module instantiation statements containing a specific identifier for further processing.

[0118] Remove the above specific identifiers to obtain the instantiation modules to be merged. The purpose of this step is to remove the identifiers, leaving the specific statement information of the modules to be merged, and mark these modules as modules that need to be merged. If the identifier of the module to be merged is a prefix (such as "merge_"), then after determining the module to be merged, you need to remove this prefix to get the actual name of the module so that you can correctly reference these modules in the merge operation. If the module instantiation statement contains comment information for marking, then this comment information is no longer needed in subsequent operations, and after removing it, you can get pure module definition information.

[0119] After removing specific identifiers, the statement information of these module instances is saved in a list of modules to be merged, which contains all modules that need to be further processed and merged.

[0120] After obtaining the candidate modules to be merged, the user selects the modules to be merged. This part of the operation allows the user to participate to ensure that the merge operation meets the actual needs. The process of automatically identifying candidate modules may select modules that are not suitable for merging. By reviewing the list of candidate modules, the user can select according to the design requirements. This makes the merge process not only rely on the judgment of the automated tool, but also incorporates the judgment and experience of the design engineer, thereby improving the accuracy and rationality of the merge process.

[0121] In some examples, the instantiation modules to be merged are automatically generated based on a partitioning strategy, and the partitioning strategy is determined based on communication density, partition similarity, dependencies, and resource constraints.

[0122] Exemplarily, the instantiation modules to be merged are automatically generated through a partitioning strategy, and the partitioning strategy is determined based on multiple factors such as communication density, partition similarity, dependency, and resource constraints. This approach makes the selection of modules to be merged more scientific and automated, and is suitable for complex large-scale integrated circuit design scenarios. The following is a detailed explanation of the scheme.

[0123] Partition strategy is used to divide multiple modules into several independent groups (i.e. partitions) to facilitate merging operations. In this solution, the partition strategy is used to automatically select which modules should be merged. The division of these modules is based on a variety of factors. The purpose is to automatically identify the modules that need to be merged by comprehensively analyzing the characteristics between modules, thereby improving the efficiency and effectiveness of the merging process.

[0124] Communication density refers to the frequency of signal interaction between modules. The higher the communication density, the closer the interaction between two modules. In the partitioning strategy, the system automatically calculates the communication density between modules, which is usually measured by the number and frequency of signals between modules.

[0125] Partition similarity refers to the similarity between modules in terms of functions, port characteristics, or other features. In the partition strategy, similarity analysis is used to determine which modules are similar in function and can be merged into the same partition.

[0126] Dependency refers to the signal connection and dependency between modules, that is, the output of one module is used as the input of another module, thus forming a dependency relationship between modules. In the partitioning strategy, the dependency between modules is represented by constructing a dependency graph, where nodes represent modules and edges represent dependencies.

[0127] Resource constraints refer to the need to consider hardware resource limitations during the merging process, such as the number of registers, the number of ports, etc. In the partitioning strategy, when merging modules, it is necessary to ensure that resource limitations are not exceeded. For example, the hardware resources required by a single module should not exceed the upper limit of the resources that the system can provide.

[0128] Based on the above partitioning strategy, the system can automatically determine which modules should be merged into a whole.

[0129] This embodiment automatically determines the modules to be merged through a partition strategy, which is based on factors such as communication density, partition similarity, dependency, and resource constraints to ensure the rationality and efficiency of module merging. This automated module selection and merging method is particularly suitable for large and complex integrated circuit designs, and can significantly improve design efficiency, reduce errors, optimize resource utilization, and enhance the overall performance of the system.

[0130] In some examples, this also includes:

[0131] Determine an objective function based on the communication density, the partition similarity, and the dependency relationship;

[0132] Determine the partitioning strategy based on a heuristic algorithm according to the objective function and the resource constraints;

[0133] Among them, the above objective function is determined based on the following formula:

[0134]

[0135] The above constraints include resource constraints, partition integrity constraints and minimum partition communication density threshold conditions;

[0136] The above resource constraints are determined based on the following formula:

[0137]

[0138] Partition integrity constraints are determined based on the following formula:

[0139]

[0140] The minimum partition communication density threshold condition is determined based on the following formula:

[0141]

[0142] In the formula, is the objective function, is a partition in the partition set, is the set of all partitions, and For partition The two modules in For modules and The communication density between , for and The number of signal interactions between For modules and The total number of ports, For modules and The functional similarity between For modules and The dependency weight between is the first weight factor, is the second weight factor, is the third weight factor, For modules The resource consumption, The upper limit of the total amount of resources allowed for each partition, Indicates that the modules in all partitions are combined to cover the entire module set , Indicates that there is no overlap between modules in different partitions. is the minimum requirement for communication density within a partition, A collection of all modules.

[0143] Exemplarily, the objective function is used to optimize the partitioning strategy of the module to ensure the rationality and efficiency of the module merging process. The objective function is based on communication density, partition similarity and dependency, and by quantifying these factors, it determines how the module should be partitioned, that is, determines which modules need to be aggregated.

[0144] By maximizing the objective function Z, the partitioning strategy tends to put modules with high communication density, similar functions, and close dependencies into the same partition to optimize the module merging effect. The maximization of the objective function needs to meet a series of constraints, which ensure the rationality and feasibility of the partitioning results. Constraints include resource constraints, partition integrity constraints, and minimum partition communication density threshold conditions.

[0145] Resource constraints ensure that the resource consumption of each module in a partition does not exceed the resource limit of the system. This is done to avoid excessive resource consumption after a single partition is merged, which affects system performance.

[0146] The partition integrity constraint ensures that all modules are completely assigned to a specific partition during the partitioning process, and each module can only belong to one partition, ensuring the uniqueness and integrity of the partitioning results.

[0147] The minimum partition communication density threshold condition ensures that the communication density within the partition is not lower than a preset threshold, thereby ensuring that there is sufficient communication interaction within the merged module to achieve the purpose of efficient integration.

[0148] After determining the objective function and constraints, a heuristic algorithm is used to solve the partition optimization problem. The purpose of the heuristic algorithm is to find a better partition strategy in a reasonable time, which is suitable for the case of a large number of modules and a huge search space.

[0149] Heuristic algorithms are a class of algorithms based on empirical rules that are used to find approximate optimal solutions in complex optimization problems, rather than exhaustively searching all possible solutions. In this solution, due to the large number of modules, the complexity of the objective function and constraints, the computational complexity of finding the optimal solution is huge, so the use of heuristic algorithms can significantly reduce the computational time and find a good enough partitioning solution.

[0150] The specific execution steps of the heuristic algorithm are:

[0151] S210, initial partitioning: perform preliminary partitioning on all modules using simple rules (such as module name, initial communication information of modules, etc.).

[0152] S220, objective function optimization: based on communication density, similarity and dependency, gradually adjust the distribution of modules in each partition to gradually increase the value of the objective function Z. Move modules with high communication density, high similarity and strong dependency to the same partition.

[0153] S230, constraint check: each time the partition is adjusted, check whether resource constraints, partition integrity, minimum communication density and other conditions are met. If some constraints are not met, the partition is readjusted or locally optimized.

[0154] S240, iterative optimization: repeat the above steps until the objective function converges, that is, no longer increases significantly, or reaches a preset stop condition.

[0155] In this embodiment, based on the optimization of the objective function and a series of constraints, combined with a heuristic algorithm, a partition strategy for the modules to be merged is automatically generated. The objective function ensures the best overall effect after the module merger by maximizing the communication density, similarity and dependency between modules. Constraints include resource constraints, partition integrity and minimum communication density, etc., to ensure that the partition is reasonable and the merged result is feasible in terms of resources and performance. The heuristic algorithm is used to quickly find a better solution in complex partitioning problems, thereby achieving automated and efficient module partitioning and merging. Through this partitioning strategy, the present solution can automatically and efficiently select the modules to be merged, reduce the workload of manual selection by designers, ensure that the merged modules reach the optimal state in terms of communication, function, dependency and resource utilization, and improve the overall efficiency and reliability of the design.

[0156] In a second aspect, the present application also proposes a multi-module aggregation device, such as Figure 2As shown, including:

[0157] A first acquisition unit 21, used to acquire a parent file;

[0158] A second acquisition unit 22, configured to acquire the port information of the upper-level file based on the upper-level file, and store the port information of the upper-level file in the upper-level file port information list;

[0159] A first determining unit 23 is used to determine the instantiation modules to be merged based on the above-mentioned upper-level file, wherein the above-mentioned upper-level file includes the instantiation modules to be merged, the instantiation modules that do not need to be merged, and the module list corresponding to the instantiation modules to be merged;

[0160] The third acquisition unit 24 is used to acquire the port information of the instantiated modules to be merged corresponding to the instantiated modules to be merged, and store the port information of the instantiated modules to be merged in the instantiated module port information list to be merged;

[0161] A generating unit 25, configured to perform signal deduplication operations, port analysis and signal definition operations, and rename and compare connection operations based on the above-mentioned upper-level file port information list and the above-mentioned instantiation module port information list to be merged, so as to generate a new merged file;

[0162] The saving unit 26 is used to save the instantiation part of the new merged file in the parent file.

[0163] The multi-module aggregation device may further perform the following steps:

[0164] In some examples, the port information of the above-mentioned parent file is obtained based on a first regular expression, the above-mentioned instantiation module to be merged is obtained based on a second regular expression, and the port information of the above-mentioned instantiation module to be merged is obtained based on a third regular expression.

[0165] In some examples,

[0166] The port information of the above-mentioned superior file includes superior file name information, superior file port direction information, superior file port type information and superior file port bit width information;

[0167] The port information of the instantiated modules to be merged includes instantiated module name information, instantiated module port direction information, instantiated module port type information and instantiated module port bit width information.

[0168] In some examples, the signal deduplication operation, port analysis and signal definition operation, and renaming and comparison connection operation are performed based on the above-mentioned upper-level file port information list and the above-mentioned instantiation module port information list to be merged to generate a new merged file, including:

[0169] Based on the above-mentioned upper-level file port information list and the above-mentioned instantiated module port information list to be merged, a signal deduplication operation is performed to remove the signals in the instantiated module port information list to be merged that overlap with the above-mentioned upper-level file port information list, and generate a deduplicated instantiated module port information list to be merged;

[0170] Perform port analysis and signal definition operations on the above-mentioned list of instantiated module port information to be merged, so as to determine the port information required for the merged module, and generate definition information of the above-mentioned required port information;

[0171] Rename and compare the remaining signal ports in the above-mentioned instantiated module port information list to be merged to generate a new merged file, wherein the remaining signals in the above-mentioned instantiated module port information list to be merged are the signal ports in the above-mentioned instantiated module port information list except the port information required by the above-mentioned merged module.

[0172] In some examples, determining the instantiation module to be merged based on the parent file includes:

[0173] Get the statement information corresponding to the specific identifier in the above parent file;

[0174] The specific identifier is removed to obtain the instantiation module to be merged corresponding to the statement information corresponding to the specific identifier, wherein the specific identifier is byte information used to distinguish the instantiation module to be merged, and the instantiation module to be merged is determined based on user selection.

[0175] In some examples, the instantiation modules to be merged are automatically generated based on a partitioning strategy, and the partitioning strategy is determined based on communication density, partition similarity, dependencies, and resource constraints.

[0176] In some examples, this also includes:

[0177] Determine an objective function based on the communication density, the partition similarity, and the dependency relationship;

[0178] Determine the partitioning strategy based on a heuristic algorithm according to the objective function and the resource constraints;

[0179] Among them, the above objective function is determined based on the following formula:

[0180]

[0181] The above constraints include resource constraints, partition integrity constraints and minimum partition communication density threshold conditions;

[0182] The above resource constraints are determined based on the following formula:

[0183]

[0184] Partition integrity constraints are determined based on the following formula:

[0185]

[0186] The minimum partition communication density threshold condition is determined based on the following formula:

[0187]

[0188] In the formula, is the objective function, is a partition in the partition set, is the set of all partitions, and For partition The two modules in For modules and The communication density between , for and The number of signal interactions between For modules and The total number of ports, For modules and The functional similarity between For modules and The dependency weight between is the first weight factor, is the second weight factor, is the third weight factor, For modules The resource consumption, The upper limit of the total amount of resources allowed for each partition, Indicates that the modules in all partitions are combined to cover the entire module set , Indicates that there is no overlap between modules in different partitions. is the minimum requirement for communication density within a partition, A collection of all modules.

[0189] like Figure 3 As shown, an embodiment of the present application also provides an electronic device 300, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor, and when the processor 320 executes the computer program 311, the steps of any of the above-mentioned multi-module aggregation methods are implemented.

[0190] Since the electronic device introduced in this embodiment is a device used to implement a multi-module aggregation device in the embodiment of the present application, based on the method introduced in the embodiment of the present application, technical personnel in this field can understand the specific implementation mode of the electronic device of this embodiment and its various variations. Therefore, how the electronic device implements the method in the embodiment of the present application is not introduced in detail here. As long as the equipment used by technical personnel in this field to implement the method in the embodiment of the present application is within the scope of protection of this application.

[0191] In the specific implementation process, when the computer program 311 is executed by the processor, it can achieve Figure 1 Any implementation manner in the corresponding embodiments.

[0192] It should be noted that in the above embodiments, the description of each embodiment has its own emphasis, and for parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0193] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0194] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0195] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0196] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0197] An embodiment of the present application also provides a computer program product, which includes computer software instructions. When the computer software instructions are executed on a processing device, the processing device executes the multi-module aggregation process in the corresponding embodiment.

[0198] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a server, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server, or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)), etc.

[0199] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0200] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0201] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0202] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0203] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0204] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A multi-module aggregation method, characterized in that: include: Get the parent file; Acquire the port information of the upper-level file based on the upper-level file, and store the port information of the upper-level file in the upper-level file port information list; Determining the instantiation module to be merged based on the parent file, wherein the parent file includes the instantiation module to be merged, the instantiation module that does not need to be merged, and a module list corresponding to the instantiation module to be merged; Acquire the port information of the instantiated module to be merged corresponding to the instantiated module to be merged, and store the port information of the instantiated module to be merged in the instantiated module port information list to be merged; Based on the upper-level file port information list and the instantiated module port information list to be merged, signal deduplication operation, port analysis and signal definition operation, and renaming and comparison connection operation are performed to generate a new merged file; Saving the instantiation part of the new merged file in the parent file; The signal deduplication operation, port analysis and signal definition operation, renaming and comparison connection operation are performed based on the upper-level file port information list and the instantiated module port information list to be merged to generate a new merged file, including: Performing a signal deduplication operation based on the upper-level file port information list and the instantiated module port information list to be merged, so as to remove the signals in the instantiated module port information list to be merged that overlap with the upper-level file port information list, and generating a deduplicated instantiated module port information list to be merged; Performing port analysis and signal definition operations on the port information list of the instantiated modules to be merged to determine the port information required for the merged module and generating definition information of the required port information; Rename and compare the remaining signal ports in the instantiated module port information list to be merged to generate a new merged file, wherein the remaining signals in the instantiated module port information list to be merged are the signal ports in the instantiated module port information list to be merged except the port information required by the merged module.

2. The multi-module aggregation method according to claim 1, characterized in that: The port information of the parent file is obtained based on a first regular expression, the instantiation module to be merged is obtained based on a second regular expression, and the port information of the instantiation module to be merged is obtained based on a third regular expression.

3. The multi-module aggregation method according to claim 1, characterized in that: The port information of the upper-level file includes upper-level file name information, upper-level file port direction information, upper-level file port type information and upper-level file port bit width information; The port information of the instantiated modules to be merged includes instantiated module name information, instantiated module port direction information, instantiated module port type information and instantiated module port bit width information.

4. The multi-module aggregation method according to claim 1, characterized in that: The step of determining the instantiation module to be merged based on the parent file includes: Obtaining statement information corresponding to a specific identifier in the parent file; The specific identifier is removed to obtain the instantiation module to be merged corresponding to the statement information corresponding to the specific identifier, wherein the specific identifier is byte information used to distinguish the instantiation module to be merged, and the instantiation module to be merged is determined based on user selection.

5. The multi-module aggregation method according to claim 1, characterized in that: The instantiation modules to be merged are automatically generated based on a partition strategy, and the partition strategy is determined based on communication density, partition similarity, dependency, and resource constraint conditions.

6. The multi-module aggregation method according to claim 5, characterized in that: Also includes: Determine an objective function based on the communication density, the partition similarity, and the dependency relationship; Determining the partitioning strategy based on a heuristic algorithm according to the objective function and the resource constraint condition; Wherein, the objective function is determined based on the following formula: The constraint conditions include resource constraint conditions, partition integrity constraint conditions and minimum partition communication density threshold conditions; The resource constraint condition is determined based on the following formula: Partition integrity constraints are determined based on the following formula: The minimum partition communication density threshold condition is determined based on the following formula: In the formula, is the objective function, is a partition in the partition set, is the set of all partitions, For partition The two modules in For modules The communication density between , for and The number of signal interactions between For modules and The total number of ports, For modules The functional similarity between For modules The dependency weight between is the first weight factor, is the second weight factor, is the third weight factor, For modules The resource consumption, The upper limit of the total amount of resources allowed for each partition, Indicates that the modules in all partitions are combined to cover the entire module set , Indicates that there is no overlap between modules in different partitions. is the minimum requirement for communication density within a partition, A collection of all modules.

7. A multi-module polymerization device, characterized in that: include: A first acquisition unit, used to acquire a parent file; A second acquisition unit, configured to acquire port information of an upper-level file based on the upper-level file, and store the port information of the upper-level file in an upper-level file port information list; A first determining unit, configured to determine the instantiation module to be merged based on the parent file, wherein the parent file includes the instantiation module to be merged, the instantiation module not to be merged, and a module list corresponding to the instantiation module to be merged; a third obtaining unit, configured to obtain port information of the instantiated modules to be merged corresponding to the instantiated modules to be merged, and store the port information of the instantiated modules to be merged in a port information list of the instantiated modules to be merged; A generating unit, configured to perform signal deduplication operation, port analysis and signal definition operation, and rename and compare connection operation based on the upper-level file port information list and the instantiated module port information list to be merged, so as to generate a new merged file; A saving unit, used for saving the instantiation part of the new merged file in the parent file; The signal deduplication operation, port analysis and signal definition operation, renaming and comparison connection operation are performed based on the upper-level file port information list and the instantiated module port information list to be merged to generate a new merged file, including: Performing a signal deduplication operation based on the upper-level file port information list and the instantiated module port information list to be merged, so as to remove the signals in the instantiated module port information list to be merged that overlap with the upper-level file port information list, and generating a deduplicated instantiated module port information list to be merged; Performing port analysis and signal definition operations on the port information list of the instantiated modules to be merged to determine the port information required for the merged module and generating definition information of the required port information; Rename and compare the remaining signal ports in the instantiated module port information list to be merged to generate a new merged file, wherein the remaining signals in the instantiated module port information list to be merged are the signal ports in the instantiated module port information list to be merged except the port information required by the merged module.

8. An electronic device comprising: A memory and a processor, wherein the processor is used to implement the steps of the multi-module aggregation method as described in any one of claims 1 to 6 when executing a computer program stored in the memory.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the multi-module aggregation method according to any one of claims 1 to 6 are implemented.

Images