Method and system for extracting hardware logic design hierarchy information based on linked list tree

Abstract

The application discloses a kind of hardware logic design hierarchy information extraction method and system based on linked list tree, and the hardware logic design hierarchy information extraction method based on linked list tree of the present application includes using synthesis tool to synthesize the RTL code of hardware design into a group of netlist files, extract the information in netlist file, obtain hardware design synthesis report file, process hardware design synthesis report file to generate hardware logic design hierarchy information based on linked list tree, the design level structure information is extracted from a group of hardware module netlist files in the present application, and is organized and stored in the mode of linked list tree, to provide input for logic partition algorithm, the present application has the advantages that hierarchy information extraction is convenient, and storage space resource occupation is less, and visual display can be carried out to facilitate FPGA prototype verification system developer to intuitively understand hardware logic design hierarchy.

Description

Technical Field

[0001] This invention pertains to prototype verification technology in the field of integrated circuit design, specifically relating to a method and system for extracting hierarchical information of hardware logic design based on linked list trees. Background Technology

[0002] With the continuous development of semiconductor technology and the increasing demand for high-performance computing, the complexity of chip design is constantly increasing, leading to higher requirements for verification platforms. Chip prototyping systems built on FPGAs (Field Programmable Gate Arrays) offer advantages such as reflecting the actual performance of chips, discovering real bugs, and faster operation speeds compared to software simulation and hardware simulation accelerators, making them a crucial means of chip verification. However, as chip designs grow larger, the logic scale of the chip to be verified exceeds the logic resources of a single FPGA, making it impossible to fit the complete chip design logic into a single FPGA, thus hindering the construction of an FPGA prototyping system. To address this issue, a logic partitioning algorithm is used to divide the chip logic design into multiple sub-designs. This ensures that the logic resources consumed by each sub-design do not exceed the logic capacity of a single FPGA, and that the interconnection bandwidth between sub-designs is less than the communication bandwidth between FPGAs. By using multiple FPGAs, the problem of chip size exceeding the logic capacity of a single FPGA is solved, enabling the construction of a chip prototyping system.

[0003] The prerequisite for FPGA prototyping systems to perform logic partitioning is to extract the chip's hierarchical structure information. In other words, the chip's hierarchical structure information is the input to the logic partitioning algorithm. The chip's hierarchical structure information includes the connection relationships between modules in the design, the number of interconnection signals between modules, and the logic resources consumed by each module.

[0004] After processing by synthesis tools, the hardware design RTL code yields a set of netlist files. Each design module's RTL file, after synthesis, produces a corresponding netlist file. From each netlist file, information such as registers, signal lines, called submodules, and the number of ports within the corresponding design module can be obtained. However, since the synthesized netlist is for each module individually, a complete and clear hierarchical structure of the hardware design cannot be seen, nor can the complete resource consumption of each module be obtained. Further processing of these netlist files is needed to clarify the call relationships between modules in order to organically organize the netlist information of each design module and obtain the hardware design hierarchical structure information required for the partitioning algorithm. When the hardware design is large and deep, the data structure used to organize and store the hardware design hierarchical structure information has a significant impact on the execution efficiency of the hierarchical structure information algorithm and the storage space occupied by the hierarchical structure information. Therefore, how to extract the hardware logic design hierarchical structure information has become a key technical problem that urgently needs to be solved. Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide a method and system for extracting hardware logic design hierarchical structure information based on linked list trees, which addresses the above-mentioned problems in the prior art. This invention organizes and stores design hierarchical structure information based on linked list trees, and can extract design hierarchical structure information from a set of hardware module netlist files and organize and store it in a linked list tree manner. It has the advantages of convenient extraction of hierarchical structure information and low storage space resource consumption, and can be visualized to help FPGA prototype verification system developers intuitively understand the hardware logic design hierarchical structure.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0007] A method for extracting hierarchical structure information of hardware logic design based on linked list trees, comprising:

[0008] Step M1: Use synthesis tools to synthesize the RTL code of the hardware design into a set of netlist files, extract information from the netlist files, and obtain the hardware design synthesis report file;

[0009] Step M2: Process the hardware design synthesis report file and generate hardware logic design hierarchy information based on a linked list tree.

[0010] Optionally, step M1 includes:

[0011] Step M11: Use a synthesis tool to synthesize the hardware design RTL code and generate a netlist file for each module in the hardware design RTL code. Each netlist file contains the register and signal line resources directly used by the module, the sub-modules called, and the input / output port information.

[0012] Step M12: Process each netlist file one by one according to the keywords, extract the registers and signal line resources directly used by the modules in the netlist file, the called submodules and input / output port information, generate the module synthesis report file corresponding to each netlist file, and summarize all the generated module synthesis report files to obtain the hardware design synthesis report file.

[0013] Optionally, the format of each line in the hardware design synthesis report file in step M1 is as follows:

[0014] Module name: wires_n, wire_bits_n, public_wires_n, public_wire_bits_n, memory_nmemory_bits_n, processes_n ['submodule a', 'submodule b', 'submodule c', ...]

[0015] Wherein, wire_n represents the number of signal lines in this module as n; wire_bits_n represents the sum of the bit widths of all signal lines in this module as n bits; memory_n represents the number of register arrays in this module as n; memory_bits_n represents the sum of the storage capacity of all register arrays in this module as n bits; processes_n represents the sum of the number of if-then-else logic blocks, always logic blocks in Verilog syntax, and process logic blocks in VHDL syntax in this module as n; ['submodule a name', 'submodule b name', 'submodule c name', ...] are the names of the various submodules instantiated by this module.

[0016] Optionally, step M2 includes:

[0017] Step M21: Define a module information retrieval table my_table, where each row of the module information retrieval table my_table is used to store the relevant information of a linked list tree node corresponding to a module;

[0018] Step M22: Define the module logical resource structure logic_data_str to record the logical resource information required by the module;

[0019] Step M23: Read one line from the hardware design synthesis report file and continue to step M24;

[0020] Step M24: Construct a linked list tree from the read line of information, and continue to step M25;

[0021] Step M25: Determine whether the hardware design synthesis report file has been completely read. If it has been completely read, proceed to step M27; if it has not been completely read, continue to step M26.

[0022] Step M26: Read the module information file on the next line of the hardware design synthesis report file, and jump to step M24;

[0023] Step M27: The linked list tree is correctly constructed and output, or the program execution is terminated and an error message is displayed, then jump to step M3.

[0024] Optionally, in step M21, each row of the module information retrieval table `my_table` includes the following columns: column `name` is the name of the linked list tree node corresponding to the module stored in the current row; column `has_data` indicates whether the logical resource information required by the module has been filled into the node stored in the current row, where `has_data` is 1 and 0 indicates that the logical resource information required by the module has not yet been filled into the node; column `has_father` indicates whether the linked list tree node corresponding to the module stored in the current row has been connected to its parent node, where `has_father` is 1 and 0 indicates that the node has not yet been connected to its parent node. When `father` is 0, it indicates that the node has not yet been connected to a parent node; the `valid_number` column represents the row number of the current row in the module information retrieval table `my_table`; the `pointer_data_node` column is a pointer to the address of the linked list tree node corresponding to the module stored in the current row; the linked list tree node is a linked list tree data structure `tree_node`, which contains three member variables, including: the member variable `pointer_logic_data_str`, which is a pointer to the address of the logical resource information structure `logic_data_str` of the current node; and the member variable `child_tree_node_pointer`. `r` is a pointer to the address of the child node `child_tree_node` of the current linked list tree node, and the member variable `next_tree_node_pointer` is a pointer to the address of the sibling node `next_tree_node` of the current linked list tree node; the parent node refers to the linked list tree node with the current module as its child node; the logical resource information recorded in the module logical resource structure `logic_data_str` in step M22 is the data object pointed to by the member variable `pointer_logic_data_str` in the linked list tree node structure, and the member variables of the module logical resource structure `logic_data_str` include `s`. The fields tr_mod_name, str_wires, str_wires_bit, str_public_wires, str_public_wires_bits, str_memories, str_memory_bits, and str_processes correspond one-to-one with the module name, wires_n, wire_bits_n, public_wires_n, public_wire_bits_n, memory_n, memory_bits_n, and processes_n in each line of the hardware design synthesis report file.

[0025] Optionally, step M24 includes:

[0026] Step M241: Compare the read module names row by row with the name column of the module information retrieval table my_table to determine whether the module has been registered. If it is determined that the module has been registered, proceed to step M242; otherwise, proceed to step M243.

[0027] Step M242: Using the column pointer_tree_node of the row where the registered module is located, find the tree node of the linked list tree corresponding to the module. Then, use the member variable pointer_logic_data_str in the tree node to find the logical resource structure logic_data_str corresponding to the module. Fill each logical resource item in the read information into the variables of the logic_data_str structure in turn, and set the column has_data of the row to 1. Then jump to step M245.

[0028] Step M243: Create a module logical resource structure `logic_data_str` for this module. Fill each variable in the newly created `logic_data_str` with the logical resource information of the module read. Create a linked list tree node for this module. The member variable `pointer_logic_data_str` of this linked list tree node points to the module logical resource structure created for this module. Set the member variables `child_tree_node_pointer` and `next_tree_node_pointer` to empty. Create a new row in the module information retrieval table `my_table` and continue to step M244.

[0029] Step M244: Enter data into the newly created row in the module information retrieval table my_table. Enter the name of the retrieved module in the name column, enter 1 in the has_data column to indicate that the logical resource information of the module has been recorded, enter 0 in the has_father column to indicate that the linked list tree node corresponding to the module has not yet been associated with its parent node, enter the row number in the valid_number column, and enter the pointer_data column to point to the linked list tree node created for the module. Continue to execute step M245.

[0030] Step M245: Determine whether a submodule is instantiated in the read module. If a submodule is instantiated, proceed to step M246; if no submodule is instantiated, proceed to the next line of text and proceed to step M24H.

[0031] Step M246: Determine if the member variable child_tree_node_pointer of the corresponding linked list tree node in the reading module is 0; if it is 0, jump to step M247; if it is not 0, jump to step M24I.

[0032] Step M247: Read the name of the first submodule of this module and jump to step M248;

[0033] Step M248: Compare the read submodule name with the defined module names in each row and column of the module information retrieval table my_table to determine whether they have been defined. If they have been defined, proceed to step M249; otherwise, proceed to step M24B.

[0034] Step M249: Determine whether the defined module is connected to the parent node. If it is not connected to the parent node, jump to M24A; if it is connected to the parent node, jump to step M24D.

[0035] Step M24A: Define the module already defined in step M249 as a child node of the linked list tree node corresponding to the module read in step M241, fill the column has_father with 1 in the row where the module already defined in step M249 is located, and assign the value stored in the column pointer_tree_node to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241; then jump to step M245;

[0036] Step M24B: Create a new row in the module information retrieval table my_table to represent the currently read submodule; then jump to step M24C;

[0037] Step M24C: Enter data into each column of this row in sequence. Enter the name of the currently read submodule in the name column; enter 0 in the has_data column, indicating that no resource information has been read yet; enter 1 in the has_father column, indicating that the linked list tree node corresponding to this module has been connected to the parent node; increment the valid_number column by 1; enter the linked list tree node information currently read in the pointer_tree_node column, and return the value stored in the pointer_tree_node column to the value of the child_tree_node_pointer member variable of the linked list tree node corresponding to the module name in step M241; then jump to step M245;

[0038] Step M24D: Determine if the member variable child_tree_node_pointer of the linked list tree node corresponding to the defined module is 0; if it is not 0, jump to step M24E; if it is 0, jump to step M24F.

[0039] Step M24E: Using the defined module as the root node, traverse and copy the corresponding module, submodule, and linked list tree node in the module information retrieval table my_table. Assign the address value of the copied linked list tree node to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the module name mentioned in step M241; then jump to step M245.

[0040] Step M24F: Based on the defined modules, define a new linked list tree node. Assign the values ​​0 to the member variables child_tree_node_pointer and next_tree_node_pointer of the linked list tree node. Assign the value of pointer_logic_data_str of the linked list tree node equal to the member variable pointer_logic_data_str in the linked list tree node corresponding to the module defined in step M24D. Create a new row at the last row of the module information retrieval table my_table, and then jump to step M24G.

[0041] Step M24G: Enter data into the newly created row of the module information retrieval table my_table. Assign the values ​​to the columns name, has_data, and has_father (the same as the columns defined in step M249). The value of the valid_number column is the value of the valid_number column from the previous row plus 1. The value of the pointer_tree_node column is the address of the linked list tree node defined in step M24F. Then, assign the address value stored in the pointer_tree_node column to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241. Then jump to step M245.

[0042] Step M24H: Jump to step M25 to proceed to the judgment of the next line of text, end and exit;

[0043] Step M24I: Read the submodule names one by one; then jump to step M24J;

[0044] Step M24J: Compare each submodule name read with the defined module names in the name column of each row of the module information retrieval table my_table to determine whether it has been defined; if it has been defined, jump to step M24K; otherwise, jump to step M24M.

[0045] Step M24K: Determine whether the defined module is connected to the parent node; if not connected to the parent node, proceed to step M24L; if connected to the parent node, proceed to step M24O.

[0046] Step M24L: Define the module already defined in step M24K as a sibling module of the submodule of the module read in step M241, and fill the column has_father of the module already defined in step M24K with 1, and assign the address value of the linked list tree node stored in the column pointer_tree_node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241; jump to step M245;

[0047] Step M24M: Create a new row in the module information retrieval table my_table to represent the currently read submodule; then jump to step M24N;

[0048] Step M24N: Enter data into each column of the newly created row in sequence. Enter the name of the currently read submodule in the name column; enter 0 in the has_data column, indicating that no resource information has been entered yet; enter 1 in the has_father column, indicating that it has been connected to the parent module; increment the fourth column valid_number by 1; enter the pointer_tree_node column with the currently read linked list tree node information, and return the value stored in the pointer_tree_node column to the value of the next_tree_node_pointer variable of the child_tree_node of the linked list tree node corresponding to the module name in step M241; then jump to step M245.

[0049] Step M24O: Determine if the child_tree_node_pointer of the node tree corresponding to the defined module is 0; if it is 0, jump to step M24Q; if it is not 0, jump to step M24P.

[0050] Step M24P: Using the defined module as the root node, traverse and copy the module and its child modules corresponding to this node in the module information retrieval table my_table. Assign the address value of the copied linked list tree node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the module name in step M241; jump to step M245.

[0051] Step M24Q: Define a new linked list tree node. Set the member variables child_tree_node_pointer and next_tree_node_pointer of the linked list tree node to 0. Set the member variable pointer_logic_data_str of the linked list tree to the pointer_logic_data_str member variable of the linked list tree node corresponding to the module defined in step M24O. Create a new row in the last row of the information retrieval table, and then jump to step M24R.

[0052] Step M24R: Sequentially fill data into the newly created row in the module information retrieval table my_table. Assign the values ​​of column name, column has_data, and column has_father to the columns name, column has_data, and column has_father of the module defined in step M24O, respectively. The value of column vaild_number is the value of vaild_number in the previous row plus 1. The value of column pointer_tree_node is the address of the linked list tree node defined in step M24P. Then assign the address value stored in column pointer_tree_node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241. Then jump to step M245.

[0053] Optionally, step M27 includes:

[0054] Step M271: Traverse the modules corresponding to the rows in the module information retrieval table my_table where the column has_father is 0; then jump to step M272.

[0055] Step M272: Determine whether the total number of modules corresponding to the rows in the module information retrieval table my_table where the column has_father is 0 is 1. If the number is 1, proceed to step M273; if the number is not 1, proceed to step M274.

[0056] Step M273: Output the module name where the has_father column is 0, and recursively traverse and output its corresponding linked list tree node and all its member variables child_tree_node and next_tree_node to the linked list file to obtain the hardware logic design hierarchy information based on the linked list tree; end and exit;

[0057] Step M274: Exit the program execution and prompt that the hardware logic design hierarchy extraction algorithm has encountered an error or the program design processing algorithm has encountered an error.

[0058] Optionally, after obtaining the hardware logic design hierarchy information based on the linked list tree in step M2, the hardware logic design hierarchy information based on the linked list tree is then visualized to intuitively display the hardware design hierarchy.

[0059] Furthermore, the present invention also provides a hardware logic design hierarchy information extraction system based on a linked list tree, comprising a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the hardware logic design hierarchy information extraction method based on the linked list tree.

[0060] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program, the computer program being programmed or configured by a microprocessor to execute the hardware logic design hierarchy information extraction method based on a linked list tree.

[0061] Compared with existing technologies, the present invention has the following main advantages: The present invention includes using synthesis tools to synthesize the RTL code of the hardware design into a set of netlist files, extracting information from the netlist files to obtain a hardware design synthesis report file, and processing the hardware design synthesis report file to generate hardware logic design hierarchical structure information based on a linked list tree. The present invention extracts design hierarchical structure information from a set of hardware module netlist files and organizes and stores it in the form of a linked list tree, providing input for the logic partitioning algorithm. The present invention has the advantages of convenient extraction of hierarchical structure information and low storage space resource consumption, and can be visualized to help FPGA prototype verification system developers intuitively understand the hardware logic design hierarchical structure. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0063] Figure 2 This is a schematic diagram of the process for generating a hardware design comprehensive report file in an embodiment of the present invention.

[0064] Figure 3 This is a flowchart illustrating the process of processing hardware design synthesis report files in an embodiment of the present invention.

[0065] Figure 4 This is a schematic diagram of the output judgment process in an embodiment of the present invention.

[0066] Figure 5 This is a schematic diagram illustrating the process of generating hardware logic design hierarchy information based on a linked list tree in an embodiment of the present invention.

[0067] Figure 6 This is a schematic diagram of the visual linked list tree structure process in an embodiment of the present invention.

[0068] Figure 7 This is a typical tree-like hierarchical structure diagram in an embodiment of the present invention.

[0069] Figure 8 This is a screenshot of the hardware logic design hierarchy information generated based on a linked list tree in an embodiment of the present invention. Detailed Implementation

[0070] like Figure 1 As shown, the hardware logic design hierarchy information extraction method based on linked list trees in this embodiment includes:

[0071] Step M1: Use synthesis tools to synthesize the RTL code of the hardware design into a set of netlist files, extract information from the netlist files, and obtain the hardware design synthesis report file;

[0072] Step M2: Process the hardware design synthesis report file and generate hardware logic design hierarchy information based on a linked list tree.

[0073] like Figure 2 As shown, step M1 in this embodiment includes:

[0074] Step M11: Use a synthesis tool to synthesize the hardware design RTL code and generate a netlist file for each module in the hardware design RTL code. Each netlist file contains the register and signal line resources directly used by the module, the sub-modules called, and the input / output port information.

[0075] Step M12: Process each netlist file one by one according to the keywords, extract the registers and signal line resources directly used by the modules in the netlist file, the called submodules and input / output port information, generate the module synthesis report file corresponding to each netlist file, and summarize all the generated module synthesis report files to obtain the hardware design synthesis report file.

[0076] In this embodiment, in step M11, the synthesis tool yosys is used to synthesize the hardware design RTL code described in Verilog into a set of netlist files. The yosys commands are: yosys -import; read_verilog; hierarchy -auto-top; procs, opt, fsm, opt, memory, opt; techmap, opt; abc -lut 4; tee -o log* stat (the commands are separated by semicolons). The hardware design RTL code is synthesized in the order of the commands to generate netlist files for each module. Each netlist file contains information about the number of variables such as wire, wire_bits, public_wires, public_wire_bits, memories, memory_bits, and processes in that module. Among them: yosys -import means importing all yosys commands as tcl commands into the tcl shell; read_verilog means loading modules from Verilog files into the current design; hierarchy -auto-top means automatically determining and marking the top-level module of the design hierarchy; procs, opt, fsm, opt, memory, opt mean converting behavioral-level descriptions to D-type flip-flops and multiplexers, optimization, extracting and optimizing finite state machines, optimization, converting high-level memory structures to D-type flip-flops and multiplexers, optimization; techmap, opt means mapping using a general method, performing simple optimizations; abc -lut 4 means using the ABC tool to map yosys internal gates to a list of LUT4 nets; tee -o log* `stat` means redirecting the output of the `stat` command to the `log*` (`*=0, 1, 2, 3...`) file; `stat` means outputting the resources of each module in the current design; in step M11, `wire` means netlist resources; `bits` is the sum of the bits of all elements, allowing comparisons between coarse-grained (the entire bus is one element) and fine-grained (each bit is one element); `wire_bits` means the sum of the bits of all netlist resources; `public_wires` means public netlist resources; `public_wire_bits` means the sum of the bits of all public netlist resources; `memories` means addressable memory (arrays); `memory_bits` means the sum of the bits of all memory; `processes` means decision trees (if-then-else statements, etc.), and synchronization declarations from Verilog always statements and VHDL process blocks (clock signals and sensitivity).

[0077] In this embodiment, step M12 extracts information from a set of netlist files obtained in step M11 based on keywords. A netlist information extraction algorithm implemented in Python is used to process each netlist file one by one, extracting information such as registers and signal line resources directly used by the modules, called submodules, and input / output ports from the netlist files. A module synthesis report file log* (n=0, 1, 2, 3...) corresponding to each netlist file is generated. All generated module synthesis report files are summarized to obtain a hardware design synthesis report file.

[0078] In this embodiment, the format of each line in the hardware design synthesis report file in step M1 is as follows:

[0079] Module name: wires_n, wire_bits_n, public_wires_n, public_wire_bits_n, memory_nmemory_bits_n, processes_n ['submodule a', 'submodule b', 'submodule c', ...]

[0080] Wherein, `wire_n` indicates the number of signal lines in this module is n; `wire_bits_n` indicates the sum of the bit widths of all signal lines in this module is n bits; `memory_n` indicates the number of register arrays in this module is n; `memory_bits_n` indicates the sum of the storage capacity of all register arrays in this module is n bits; `processes_n` indicates the sum of the number of if-then-else logic blocks, always logic blocks in Verilog syntax, and process logic blocks in VHDL syntax in this module is n; `['submodule a name', 'submodule b name', 'submodule c name', ...]` are the names of the various submodules instantiated by this module. For example, some modules have the following format:

[0081] presclr_wdt wires_137 wire_bits_226 public_wires_24 public_wire_bits_45 memories_0 memory_bits_0 processes_0

[0082] inc8 wires_23 wire_bits_44 public_wires_2 public_wire_bits_16memories_0 memory_bits_0 processes_0

[0083] alu wires_152 wire_bits_321 public_wires_19 public_wire_bits_106memories_0 memory_bits_0 processes_0 ['add_sub8_co_1','mux2_8_1','mux4_8_4']

[0084] mux2_7 wires_26 wire_bits_44 public_wires_4 public_wire_bits_22memories_0 memory_bits_0 processes_0

[0085] mux2_11 wires_38 wire_bits_68 public_wires_4 public_wire_bits_34memories_0 memory_bits_0 processes_0

[0086] ...

[0087] like Figure 3 As shown, step M2 in this embodiment includes:

[0088] Step M21: Define a module information retrieval table my_table, where each row of the module information retrieval table my_table is used to store the relevant information of a linked list tree node corresponding to a module;

[0089] Step M22: Define the module logical resource structure logic_data_str to record the logical resource information required by the module;

[0090] Step M23: Read one line from the hardware design synthesis report file and continue to step M24;

[0091] Step M24: Construct a linked list tree from the read line of information, and continue to step M25;

[0092] Step M25: Determine whether the hardware design synthesis report file has been completely read. If it has been completely read, proceed to step M27; if it has not been completely read, continue to step M26.

[0093] Step M26: Read the module information file on the next line of the hardware design synthesis report file, and jump to step M24;

[0094] Step M27: The linked list tree is correctly constructed and output, or the program execution is terminated and an error message is displayed, then jump to step M3.

[0095] In this embodiment, the column information of the module information retrieval table my_table in step M21 is shown in Table 1.

[0096] Table 1: Column field table of module information retrieval table my_table.

[0097]

[0098] Referring to Table 1, the columns of each row in the module information retrieval table my_table in step M21 include: (First column) the name column, which is the name of the linked list tree node corresponding to the module stored in the current row; (Second column) the has_data column, which indicates whether the logical resource information required by the module has been filled into the node stored in the current row. When has_data is 1, it means that the logical resource information required by the module has been filled in, and when has_data is 0, it means that the logical resource information required by the module has not been filled in; (Third column) the has_father column, which indicates whether the linked list tree node corresponding to the module stored in the current row has been connected to its parent node. When has_father is 1, it means that it has been connected to its parent node. The parent node, when the has_father column is 0, indicates that it has not yet been connected to the parent node; the fourth column, valid_number, is the row number of the current row in the module information retrieval table my_table; the fifth column, pointer_data_node, is a pointer to the address of the linked list tree node corresponding to the module stored in the current row; the linked list tree node is a linked list tree data structure tree_node, which contains three member variables, including: the member variable pointer_logic_data_str, which is a pointer to the address of the logic resource information structure logic_data_str of the current node; the member variable child_tree... `e_node_pointer` is a pointer to the address of the child node `child_tree_node` of the current linked list tree node, and the member variable `next_tree_node_pointer` is a pointer to the address of the sibling node `next_tree_node` of the current linked list tree node; the parent node refers to the linked list tree node with the current module as its child node; the logical resource information recorded in the module logical resource structure `logic_data_str` in step M22 is the data object pointed to by the member variable `pointer_logic_data_str` in the linked list tree node structure, and the module logical resource structure `logic_data_str`... Member variables include str_mod_name, str_wires, str_wires_bit, str_public_wires, str_public_wires_bits, str_memories, str_memory_bits, and str_processes, which correspond one-to-one with the module name, wires_n, wire_bits_n, public_wires_n, public_wire_bits_n, memory_n, memory_bits_n, and processes_n in each line of the hardware design synthesis report file.

[0099] like Figure 5 As shown, in this embodiment, step M24 includes:

[0100] Step M241: Compare the read module names row by row with the name column of the module information retrieval table my_table to determine whether the module has been registered. If it is determined that the module has been registered, proceed to step M242; otherwise, proceed to step M243.

[0101] Step M242: Using the column pointer_tree_node of the row where the registered module is located, find the tree node of the linked list tree corresponding to the module. Then, use the member variable pointer_logic_data_str in the tree node to find the logical resource structure logic_data_str corresponding to the module. Fill each logical resource item in the read information into the variables of the logic_data_str structure in turn, and set the column has_data of the row to 1. Then jump to step M245.

[0102] Step M243: Create a module logical resource structure `logic_data_str` for this module. Fill each variable in the newly created `logic_data_str` with the logical resource information of the module read. Create a linked list tree node for this module. The member variable `pointer_logic_data_str` of this linked list tree node points to the module logical resource structure created for this module. Set the member variables `child_tree_node_pointer` and `next_tree_node_pointer` to empty. Create a new row in the module information retrieval table `my_table` and continue to step M244.

[0103] Step M244: Enter data into the newly created row in the module information retrieval table my_table. Enter the name of the retrieved module in the name column, enter 1 in the has_data column to indicate that the logical resource information of the module has been recorded, enter 0 in the has_father column to indicate that the linked list tree node corresponding to the module has not yet been associated with its parent node, enter the row number in the valid_number column, and enter the pointer_data column to point to the linked list tree node created for the module. Continue to execute step M245.

[0104] Step M245: Determine whether a submodule is instantiated in the read module. If a submodule is instantiated, proceed to step M246; if no submodule is instantiated, proceed to the next line of text and proceed to step M24H.

[0105] Step M246: Determine if the member variable child_tree_node_pointer of the corresponding linked list tree node in the reading module is 0; if it is 0, jump to step M247; if it is not 0, jump to step M24I.

[0106] Step M247: Read the name of the first submodule of this module and jump to step M248;

[0107] Step M248: Compare the read submodule name with the defined module names in each row and column of the module information retrieval table my_table to determine whether they have been defined. If they have been defined, proceed to step M249; otherwise, proceed to step M24B.

[0108] Step M249: Determine whether the defined module is connected to the parent node. If it is not connected to the parent node, jump to M24A; if it is connected to the parent node, jump to step M24D.

[0109] Step M24A: Define the module already defined in step M249 as a child node of the linked list tree node corresponding to the module read in step M241, fill the column has_father with 1 in the row where the module already defined in step M249 is located, and assign the value stored in the column pointer_tree_node to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241; then jump to step M245;

[0110] Step M24B: Create a new row in the module information retrieval table my_table to represent the currently read submodule; then jump to step M24C;

[0111] Step M24C: Enter data into each column of this row in sequence. Enter the name of the currently read submodule in the name column; enter 0 in the has_data column, indicating that no resource information has been read yet; enter 1 in the has_father column, indicating that the linked list tree node corresponding to this module has been connected to the parent node; increment the valid_number column by 1; enter the linked list tree node information currently read in the pointer_tree_node column, and return the value stored in the pointer_tree_node column to the value of the child_tree_node_pointer member variable of the linked list tree node corresponding to the module name in step M241; then jump to step M245;

[0112] Step M24D: Determine if the member variable child_tree_node_pointer of the linked list tree node corresponding to the defined module is 0; if it is not 0, jump to step M24E; if it is 0, jump to step M24F.

[0113] Step M24E: Using the defined module as the root node, traverse and copy the corresponding module, submodule, and linked list tree node in the module information retrieval table my_table. Assign the address value of the copied linked list tree node to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the module name mentioned in step M241; then jump to step M245.

[0114] Step M24F: Based on the defined modules, define a new linked list tree node. Assign the values ​​0 to the member variables child_tree_node_pointer and next_tree_node_pointer of the linked list tree node. Assign the value of pointer_logic_data_str of the linked list tree node equal to the member variable pointer_logic_data_str in the linked list tree node corresponding to the module defined in step M24D. Create a new row at the last row of the module information retrieval table my_table, and then jump to step M24G.

[0115] Step M24G: Enter data into the newly created row of the module information retrieval table my_table. Assign the values ​​to the columns name, has_data, and has_father (the same as the columns defined in step M249). The value of the valid_number column is the value of the valid_number column from the previous row plus 1. The value of the pointer_tree_node column is the address of the linked list tree node defined in step M24F. Then, assign the address value stored in the pointer_tree_node column to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241. Then jump to step M245.

[0116] Step M24H: Jump to step M25 to proceed to the judgment of the next line of text, end and exit;

[0117] Step M24I: Read the submodule names one by one; then jump to step M24J;

[0118] Step M24J: Compare each submodule name read with the defined module names in the name column of each row of the module information retrieval table my_table to determine whether it has been defined; if it has been defined, jump to step M24K; otherwise, jump to step M24M.

[0119] Step M24K: Determine whether the defined module is connected to the parent node; if not connected to the parent node, proceed to step M24L; if connected to the parent node, proceed to step M24O.

[0120] Step M24L: Define the module already defined in step M24K as a sibling module of the submodule of the module read in step M241, and fill the column has_father of the module already defined in step M24K with 1, and assign the address value of the linked list tree node stored in the column pointer_tree_node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241; jump to step M245;

[0121] Step M24M: Create a new row in the module information retrieval table my_table to represent the currently read submodule; then jump to step M24N;

[0122] Step M24N: Enter data into each column of the newly created row in sequence. Enter the name of the currently read submodule in the name column; enter 0 in the has_data column, indicating that no resource information has been entered yet; enter 1 in the has_father column, indicating that it has been connected to the parent module; increment the fourth column valid_number by 1; enter the pointer_tree_node column with the currently read linked list tree node information, and return the value stored in the pointer_tree_node column to the value of the next_tree_node_pointer variable of the child_tree_node of the linked list tree node corresponding to the module name in step M241; then jump to step M245.

[0123] Step M24O: Determine if the child_tree_node_pointer of the node tree corresponding to the defined module is 0; if it is 0, jump to step M24Q; if it is not 0, jump to step M24P.

[0124] Step M24P: Using the defined module as the root node, traverse and copy the module and its child modules corresponding to this node in the module information retrieval table my_table. Assign the address value of the copied linked list tree node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the module name in step M241; jump to step M245.

[0125] Step M24Q: Define a new linked list tree node. Set the member variables child_tree_node_pointer and next_tree_node_pointer of the linked list tree node to 0. Set the member variable pointer_logic_data_str of the linked list tree to the pointer_logic_data_str member variable of the linked list tree node corresponding to the module defined in step M24O. Create a new row in the last row of the information retrieval table, and then jump to step M24R.

[0126] Step M24R: Sequentially fill data into the newly created row in the module information retrieval table my_table. Assign the values ​​of column name, column has_data, and column has_father to the columns name, column has_data, and column has_father of the module defined in step M24O, respectively. The value of column vaild_number is the value of vaild_number in the previous row plus 1. The value of column pointer_tree_node is the address of the linked list tree node defined in step M24P. Then assign the address value stored in column pointer_tree_node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241. Then jump to step M245.

[0127] In summary, there are 18 possible scenarios for constructing a linked list tree from the read line of information in steps M241 to M24R, as shown in Table 2.

[0128] Table 2: Types and steps of constructing linked list trees.

[0129]

[0130] In Table 2, "new (old) module" refers to a module whose name was read before it was registered in my_table; "having (no) submodule" refers to a module whose name was read before it was instantiated; "child node of new (old) module is 0 (1)" means that the child node value of the linked list tree node corresponding to the new (old) module is 0 (1); "submodule not (already) registered" means that the submodule read before it was registered in my_table; "registered submodule not (already) connected to parent module" means that the has_father of the row where the submodule registered in my_table is read is 0 (1); "registered submodule has no (has) submodule" means that the child_tree_node_pointer of the linked list tree node corresponding to the submodule registered in my_table is 0 (1).

[0131] like Figure 4 As shown, step M27 in this embodiment includes:

[0132] Step M271: Traverse the modules corresponding to the rows in the module information retrieval table my_table where the column has_father is 0; then jump to step M272.

[0133] Step M272: Determine whether the total number of modules corresponding to the rows in the module information retrieval table my_table where the column has_father is 0 is 1. If the number is 1, proceed to step M273; if the number is not 1, proceed to step M274.

[0134] Step M273: Output the module name where the has_father column is 0, and recursively traverse and output its corresponding linked list tree node and all its member variables child_tree_node and next_tree_node to the linked list file to obtain the hardware logic design hierarchy information based on the linked list tree; end and exit;

[0135] Step M274: Exit the program execution and prompt that the hardware logic design hierarchy extraction algorithm has encountered an error or the program design processing algorithm has encountered an error.

[0136] See Figure 1 In this embodiment, after obtaining the hardware logic design hierarchy information based on the linked list tree in step M2, the method further includes visually displaying the hardware design hierarchy in a visual manner based on the obtained hardware logic design hierarchy information based on the linked list tree.

[0137] like Figure 6 As shown, the hierarchical structure of the hardware design is visually represented, including:

[0138] Step M31: Define a recursive drawing function draw(), which includes the drawing action lambda and recursive traversal of the left node. Execute the recursive drawing function draw(), and then jump to step M32.

[0139] Step M32: Determine whether the result of step M31 has been generated. If not, proceed to step M33; if it has been generated, proceed to step M34.

[0140] Step M33: Exit the program and output: "Hardware design hierarchical linked list tree visualization algorithm execution error";

[0141] Step M34: Output the result as an image and open the image; then proceed to step M35.

[0142] Step M35: Open the image; Output: Visualization successful; Jump to step M3 main program, exit all programs.

[0143] The recursive drawing function draw() takes the left node name as its parameter and can be represented as: draw (left node name).

[0144] The drawing action `lambda` takes a node name as its parameter and can be represented as `lambda(node_name)`. The execution process of `lambda(node_name)` includes: if the node name equals the root node, then the action is executed: draw the root node's member variable `logic_data_str`; otherwise, draw a unidirectional line segment plus the current node's member variable `logic_data_str` under the current node's parent node, and recursively traverse the current node's right nodes. During the execution of `lambda(node_name)`, the recursive traversal of the current node's right nodes can be expressed as: `draw(right node_name)`. Figure 7 The image shown is the result of visually demonstrating the hierarchical structure of the hardware design in this embodiment. Figure 8 A schematic diagram of the module information for generating the hierarchical structure of this hardware design.

[0145] In summary, this embodiment provides a method for generating a design hierarchy linked list tree for logic partitioning in FPGA prototyping systems. It includes steps such as hardware design RTL code synthesis, constructing the design hierarchy linked list tree, and visualizing the design hierarchy linked list tree. It can extract design hierarchy information from a set of hardware module netlist files and organize and store it in a linked list tree format, providing input for the logic partitioning algorithm. This invention has the advantages of convenient extraction of hierarchy information and low storage space consumption, and it can be visualized to help FPGA prototyping system developers intuitively understand the hardware logic design hierarchy. Through this embodiment, FPGA prototyping system developers can clearly understand the design hierarchy and provide a design hierarchy information representation method with smaller storage space requirements for the logic partitioning algorithm of the FPGA prototyping system.

[0146] Furthermore, this embodiment also provides a hardware logic design hierarchy information extraction system based on a linked list tree, including a microprocessor and a memory interconnected thereon. The microprocessor is programmed or configured to execute a hardware logic design hierarchy information extraction method based on a linked list tree. Additionally, this embodiment also provides a computer-readable storage medium storing a computer program for being programmed or configured by the microprocessor to execute the hardware logic design hierarchy information extraction method based on a linked list tree.

[0147] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0148] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for extracting hierarchical structure information of hardware logic design based on linked list trees, characterized in that, include: Step M1: Use synthesis tools to synthesize the RTL code of the hardware design into a set of netlist files, extract information from the netlist files, and obtain the hardware design synthesis report file; Step M2: Process the hardware design synthesis report file and generate hardware logic design hierarchy information based on a linked list tree; Step M2 includes: Step M21: Define a module information retrieval table my_table. Each row of the module information retrieval table my_table stores relevant information about a linked list tree node corresponding to a module. The columns of each row of the module information retrieval table my_table include: column name, which is the name of the linked list tree node corresponding to the module stored in the current row; column has_data, which indicates whether the node stored in the current row has been filled with the logical resource information required by the module (has_data = 1 indicates it has been filled, has_data = 0 indicates it has not); column has_father, which indicates whether the linked list tree node corresponding to the module stored in the current row has been connected to its parent node (has_father = 1 indicates it has been connected, has_father = 0 indicates it has not); column valid_number, which is the row number of the current row in the module information retrieval table my_table; and column pointer_data_node, which is a pointer to the address of the linked list tree node corresponding to the module stored in the current row. Step M22: Define the module logical resource structure logic_data_str to record the logical resource information required by the module; Step M23: Read one line from the hardware design synthesis report file and continue to step M24; Step M24: Construct a linked list tree from the read line of information, and continue to step M25; Step M25: Determine whether the hardware design synthesis report file has been completely read. If it has been completely read, proceed to step M27; if it has not been completely read, continue to step M26. Step M26: Read the module information file on the next line of the hardware design synthesis report file, and jump to step M24; Step M27: The linked list tree is correctly constructed and output, or the program execution is terminated and an error message is displayed, then jump to step M3.

2. The method for extracting hierarchical structure information of hardware logic design based on linked list tree according to claim 1, characterized in that, Step M1 includes: Step M11: Use a synthesis tool to synthesize the hardware design RTL code and generate a netlist file for each module in the hardware design RTL code. Each netlist file contains the register and signal line resources directly used by the module, the sub-modules called, and the input / output port information. Step M12: Process each netlist file one by one according to the keywords, extract the registers and signal line resources directly used by the modules in the netlist file, the called submodules and input / output port information, generate the module synthesis report file corresponding to each netlist file, and summarize all the generated module synthesis report files to obtain the hardware design synthesis report file.

3. The method for extracting hierarchical structure information of hardware logic design based on linked list tree according to claim 1, characterized in that, The format of each line in the hardware design synthesis report file in step M1 is as follows: Module name: wires_n, wire_bits_n, public_wires_n, public_wire_bits_n, memory_nmemory_bits_n, processes_n ['submodule a', 'submodule b', 'submodule c', ...] Wherein, wire_n represents the number of signal lines in this module as n; wire_bits_n represents the sum of the bit widths of all signal lines in this module as n bits; memory_n represents the number of register arrays in this module as n; memory_bits_n represents the sum of the storage capacity of all register arrays in this module as n bits; processes_n represents the sum of the number of if-then-else logic blocks, always logic blocks in Verilog syntax, and process logic blocks in VHDL syntax in this module as n; ['submodule a name', 'submodule b name', 'submodule c name', ...] are the names of the various submodules instantiated by this module.

4. The method for extracting hierarchical structure information of hardware logic design based on linked list tree according to claim 1, characterized in that, The linked list tree node is a linked list tree data structure called `tree_node`. This structure contains three member variables: `pointer_logic_data_str`, which is a pointer to the address of the `logic_data_str` structure containing the required logical resource information of the current node; `child_tree_node_pointer`, which is a pointer to the address of the `child_tree_node` child node of the current linked list tree node; and `next_tree_node_pointer`, which is a pointer to the address of the `next_tree_node` sibling node of the current linked list tree node. The parent node refers to the linked list tree node with the current module as its child node. The logical resource information recorded in the `logic_data_str` structure of the module in step M22 is the logical resource information in the linked list tree node structure. The data object pointed to by the member variable pointer_logic_data_str, the module logic resource structure logic_data_str, includes member variables str_mod_name, str_wires, str_wires_bit, str_public_wires, str_public_wires_bits, str_memories, str_memory_bits, and str_processes, which correspond one-to-one with the module name, wires_n, wire_bits_n, public_wires_n, public_wire_bits_n, memory_n, memory_bits_n, and processes_n in each line of the hardware design synthesis report file.

5. The method for extracting hierarchical structure information of hardware logic design based on linked list tree according to claim 1, characterized in that, Step M24 includes: Step M241: Compare the read module names row by row with the name column of the module information retrieval table my_table to determine whether the module has been registered. If it is determined that the module has been registered, proceed to step M242; otherwise, proceed to step M243. Step M242: Using the column pointer_tree_node of the row where the registered module is located, find the tree node of the linked list tree corresponding to the module. Then, use the member variable pointer_logic_data_str in the tree node to find the logical resource structure logic_data_str corresponding to the module. Fill each logical resource item in the read information into the variables of the logic_data_str structure in turn, and set the column has_data of the row to 1. Then jump to step M245. Step M243: Create a module logical resource structure `logic_data_str` for this module. Fill each variable in the newly created `logic_data_str` with the logical resource information of the module read. Create a linked list tree node for this module. The member variable `pointer_logic_data_str` of this linked list tree node points to the module logical resource structure created for this module. Set the member variables `child_tree_node_pointer` and `next_tree_node_pointer` to empty. Create a new row in the module information retrieval table `my_table` and continue to step M244. Step M244: Enter data into the newly created row in the module information retrieval table my_table. Enter the name of the retrieved module in the name column, enter 1 in the has_data column to indicate that the logical resource information of the module has been recorded, enter 0 in the has_father column to indicate that the linked list tree node corresponding to the module has not yet been associated with its parent node, enter the row number in the valid_number column, and enter the pointer_data column to point to the linked list tree node created for the module. Continue to execute step M245. Step M245: Determine whether a submodule is instantiated in the read module. If a submodule is instantiated, proceed to step M246; if no submodule is instantiated, proceed to the next line of text and proceed to step M24H. Step M246: Determine if the member variable child_tree_node_pointer of the corresponding linked list tree node in the reading module is 0; if it is 0, jump to step M247; if it is not 0, jump to step M24I. Step M247: Read the name of the first submodule of this module and jump to step M248; Step M248: Compare the read submodule name with the defined module names in each row and column of the module information retrieval table my_table to determine whether they have been defined. If they have been defined, proceed to step M249; otherwise, proceed to step M24B. Step M249: Determine whether the defined module is connected to the parent node. If it is not connected to the parent node, jump to M24A; if it is connected to the parent node, jump to step M24D. Step M24A: Define the module already defined in step M249 as a child node of the linked list tree node corresponding to the module read in step M241, fill the column has_father with 1 in the row where the module already defined in step M249 is located, and assign the value stored in the column pointer_tree_node to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241; then jump to step M245; Step M24B: Create a new row in the module information retrieval table my_table to represent the currently read submodule; then jump to step M24C; Step M24C: Enter data into each column of this row in sequence. Enter the name of the currently read submodule in the name column; enter 0 in the has_data column, indicating that no resource information has been read yet; enter 1 in the has_father column, indicating that the linked list tree node corresponding to this module has been connected to the parent node; increment the valid_number column by 1; enter the linked list tree node information currently read in the pointer_tree_node column, and return the value stored in the pointer_tree_node column to the value of the child_tree_node_pointer member variable of the linked list tree node corresponding to the module name in step M241; then jump to step M245; Step M24D: Determine if the member variable child_tree_node_pointer of the linked list tree node corresponding to the defined module is 0; if it is not 0, jump to step M24E; if it is 0, jump to step M24F. Step M24E: Using the defined module as the root node, traverse and copy the corresponding module, submodule, and linked list tree node in the module information retrieval table my_table. Assign the address value of the copied linked list tree node to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the module name mentioned in step M241; then jump to step M245. Step M24F: Based on the defined modules, define a new linked list tree node. Assign the values ​​0 to the member variables child_tree_node_pointer and next_tree_node_pointer of the linked list tree node. Assign the value of pointer_logic_data_str of the linked list tree node equal to the member variable pointer_logic_data_str in the linked list tree node corresponding to the module defined in step M24D. Create a new row at the last row of the module information retrieval table my_table, and then jump to step M24G. Step M24G: Enter data into the newly created row of the module information retrieval table my_table. Assign the values ​​to the columns name, has_data, and has_father (the same as the columns defined in step M249). The value of the valid_number column is the value of the valid_number column from the previous row plus 1. The value of the pointer_tree_node column is the address of the linked list tree node defined in step M24F. Then, assign the address value stored in the pointer_tree_node column to the value of the member variable child_tree_node_pointer of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241. Then jump to step M245. Step M24H: Jump to step M25 to proceed to the judgment of the next line of text, end and exit; Step M24I: Read the submodule names one by one; then jump to step M24J; Step M24J: Compare each submodule name read with the defined module names in the name column of each row of the module information retrieval table my_table to determine whether it has been defined; if it has been defined, jump to step M24K; otherwise, jump to step M24M. Step M24K: Determine whether the defined module is connected to the parent node; if not connected to the parent node, proceed to step M24L; if connected to the parent node, proceed to step M24O. Step M24L: Define the module already defined in step M24K as a sibling module of the submodule of the module read in step M241, and fill the column has_father of the module already defined in step M24K with 1, and assign the address value of the linked list tree node stored in the column pointer_tree_node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241; jump to step M245; Step M24M: Create a new row in the module information retrieval table my_table to represent the currently read submodule; then jump to step M24N; Step M24N: Enter data into each column of the newly created row in sequence. Enter the name of the currently read submodule in the name column; enter 0 in the has_data column, indicating that no resource information has been entered yet; enter 1 in the has_father column, indicating that it has been connected to the parent module; increment the fourth column valid_number by 1; enter the pointer_tree_node column with the currently read linked list tree node information, and return the value stored in the pointer_tree_node column to the value of the next_tree_node_pointer variable of the child_tree_node of the linked list tree node corresponding to the module name in step M241; then jump to step M245. Step M24O: Determine if the child_tree_node_pointer of the node tree corresponding to the defined module is 0; if it is 0, jump to step M24Q; if it is not 0, jump to step M24P. Step M24P: Using the defined module as the root node, traverse and copy the module and its child modules corresponding to this node in the module information retrieval table my_table. Assign the address value of the copied linked list tree node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the module name in step M241; jump to step M245. Step M24Q: Define a new linked list tree node. Set the member variables child_tree_node_pointer and next_tree_node_pointer of the linked list tree node to 0. Set the member variable pointer_logic_data_str of the linked list tree to the pointer_logic_data_str member variable of the linked list tree node corresponding to the module defined in step M24O. Create a new row in the last row of the information retrieval table, and then jump to step M24R. Step M24R: Sequentially fill data into the newly created row in the module information retrieval table my_table. Assign the values ​​of column name, column has_data, and column has_father to the columns name, column has_data, and column has_father of the module defined in step M24O, respectively. The value of column vaild_number is the value of vaild_number in the previous row plus 1. The value of column pointer_tree_node is the address of the linked list tree node defined in step M24P. Then assign the address value stored in column pointer_tree_node to the value of the member variable next_tree_node_pointer of the child_tree_node of the linked list tree node corresponding to the current parent module, where the current parent module is the module read in step M241. Then jump to step M245.

6. The method for extracting hierarchical structure information of hardware logic design based on linked list tree according to claim 1, characterized in that, Step M27 includes: Step M271: Traverse the modules corresponding to the rows in the module information retrieval table my_table where the column has_father is 0; then jump to step M272. Step M272: Determine whether the total number of modules corresponding to the rows in the module information retrieval table my_table where the column has_father is 0 is 1. If the number is 1, proceed to step M273; if the number is not 1, proceed to step M274. Step M273: Output the module name where the has_father column is 0, and recursively traverse and output its corresponding linked list tree node and all its member variables child_tree_node and next_tree_node to the linked list file to obtain the hardware logic design hierarchy information based on the linked list tree; end and exit; Step M274: Exit the program execution and prompt that the hardware logic design hierarchy extraction algorithm has encountered an error or the program design processing algorithm has encountered an error.

7. The method for extracting hierarchical structure information of hardware logic design based on linked list tree according to claim 1, characterized in that, After obtaining the hardware logic design hierarchy information based on the linked list tree in step M2, the process also includes visually displaying the hardware design hierarchy in a visual manner.

8. A hardware logic design hierarchical structure information extraction system based on linked list trees, comprising interconnected microprocessors and memory, characterized in that, The microprocessor is programmed or configured to execute the hardware logic design hierarchy information extraction method based on a linked list tree as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program is used to be programmed or configured by a microprocessor to execute the hardware logic design hierarchy information extraction method based on a linked list tree as described in any one of claims 1 to 7.

Images