Abstract syntax tree-based module data generation method, electronic device, and storage medium

Abstract

The application relates to the technical field of integrated circuit design, and discloses a module data generation method based on an abstract syntax tree, an electronic device and a storage medium, the method comprising the following steps: acquiring a digital circuit design file, analyzing the digital circuit design file, and generating a corresponding abstract syntax tree; identifying a module scope contained in the abstract syntax tree, and creating a variable relationship data structure corresponding to the module scope; determining a signal correlation relationship between leaf nodes, and creating a correlation relationship object in the variable relationship data structure based on the signal correlation relationship between the leaf nodes, so that the problem that it is difficult to accurately identify the signal interaction relationship between the leaf nodes by only relying on the abstract syntax tree is effectively avoided, and the efficiency and accuracy of calculation and analysis of the signal correlation relationship in the module scope by electronic design automation software are improved.

Description

Technical Field

[0001] This application belongs to the field of integrated circuit design technology, and in particular relates to a method for generating module data based on abstract syntax trees, an electronic device, and a storage medium. Background Technology

[0002] Electronic Design Automation (EDA) refers to the design method that uses computer-aided design software to complete the functional design, synthesis, verification, and physical design (including placement, routing, layout, and design rule checking) of very large-scale integrated circuit (VLSI) chips. It is a commonly used design tool for integrated circuit designers.

[0003] In EDA software, the Verific parser performs lexical, syntactic, and semantic analysis on HDL design files such as Verilog. Specifically, during the parsing phase, electronic design automation (EDA) software typically requires a parser to structure the user-input design files so that subsequent modules can access and analyze the design content in a unified manner. These digital circuit design files are also known as Verilog files. In existing technologies, the Verific parser, provided by Verific Design Automation, is widely used in various EDA software programs. As an industrial-grade parsing component, the Verific parser supports language standards such as Verilog, SystemVerilog, VHDL, and Unified Power Format (UPF), and can perform lexical analysis, syntactic analysis, and semantic analysis with high precision. Through this parsing process, the Verific parser transforms the design files in the EDA software into internal data structures, providing formal input for subsequent functional modules.

[0004] In the field of electronic design automation (EDA), the Verific parser, as a parsing tool, typically parses Hardware Description Language (HDL) design documents into Abstract Syntax Trees (ASTs) through lexical and syntactic analysis. These ASTs serve as a unified representation of the design's syntactic structure, supporting subsequent semantic analysis, structural expansion, timing analysis, and circuit-level processing. Specifically, the Verific parser, based on its internal tools such as flex and bison, performs lexical and syntactic analysis on chip design documents written in hardware description languages ​​like Verilog, transforming the textual design content in the source code into a structured AST. This AST is generated entirely based on the user's design definition, and its node set represents the various syntactic elements and their hierarchical relationships within the design document. In this AST, the AST forms a one-to-one correspondence with the source code in a tree structure. Each node represents a part of the syntactic unit in the program or circuit description, such as variables, constants, operators, expressions, function calls, procedural blocks, or module instances; while the parent node represents the syntactic inclusion or composition relationships with its child nodes. For example, in the syntax construction of function calls or procedure calls, the corresponding AST nodes typically include a name node to represent the called object, and several child nodes to represent the parameter list or sensitivity list, thus explicitly reflecting the syntax hierarchy and combinational logic in the source code in the tree structure.

[0005] However, EDA software cannot directly execute algorithmic operations on the abstract syntax tree (AST) data structure generated by the Verific parser. This is because the AST is a tree structure that only describes the hierarchical relationships of language syntax. Its nodes reflect syntactic subordination through unidirectional parent-child relationships, lacking object-level interconnections and signal-level topological features. For example, in the sensitivity list of the always block, if conditional statements, case branch structures, and for loop statements, the AST only records the semantic association between variables and syntactic constructs, without establishing interconnections between signals. Due to the lack of this signal connection information, in practical use, EDA software cannot directly execute algorithmic operations requiring circuit-level connectivity, such as load checks, loop detection, or clock edge determination, based on the AST. Although the AST output by Verific is suitable for syntax parsing and semantic recognition, it is difficult to support subsequent algorithmic processing and interactive operations of circuit structures by electronic design automation software. Summary of the Invention

[0006] This application provides a module data generation method, electronic device, and storage medium based on abstract syntax trees, aiming to provide a module data scheme that facilitates algorithmic operations in electronic design automation software.

[0007] On one hand, embodiments of this application provide a method for generating module data based on an abstract syntax tree, characterized by comprising the following steps:

[0008] Obtain digital circuit design files, parse the digital circuit design files, and generate corresponding abstract syntax trees;

[0009] Identify the module scopes contained in the abstract syntax tree and create a variable relationship data structure corresponding to the module scopes;

[0010] Traverse the abstract syntax tree corresponding to the module scope, determine the leaf nodes in the abstract syntax tree during the traversal, and create node objects corresponding to the leaf nodes in the variable relationship data structure;

[0011] Determine the signal association relationships between the leaf nodes, and create association relationship objects in the variable relationship data structure based on the signal association relationships between the leaf nodes.

[0012] On the other hand, embodiments of this application provide an electronic device, including: a processor; and a memory for storing processor-executable instructions, wherein the processor-executable instructions, when executed by the processor, cause the processor to perform the steps of the above-described module data generation method based on an abstract syntax tree.

[0013] In another aspect, embodiments of this application provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the steps of the above-described module data generation method based on an abstract syntax tree.

[0014] This application embodiment obtains a digital circuit design file, parses the digital circuit design file, and generates a corresponding abstract syntax tree; identifies the module scopes contained in the abstract syntax tree, and creates a variable relationship data structure corresponding to the module scopes; traverses the abstract syntax tree corresponding to the module scopes, determines the leaf nodes in the abstract syntax tree during the traversal process, and creates node objects corresponding to the leaf nodes in the variable relationship data structure; determines the signal association relationships between the leaf nodes, and creates association relationship objects in the variable relationship data structure based on the signal association relationships between the leaf nodes. This approach, while maintaining the original process and parsing method of parsing digital circuit design files and generating abstract syntax trees, supplements the construction of a variable relationship data structure. The variable relationship data structure creates node objects corresponding to the leaf nodes, as well as relationship objects representing the signal relationships between leaf nodes. By mapping variable reference information scattered across different syntax structures and semantic categories in digital circuit design files to the same variable relationship data structure, the problem of accurately identifying signal interaction relationships between leaf nodes by relying solely on abstract syntax trees is effectively avoided. Furthermore, the variable relationship data structure can fully reflect the signal relationships within a module, enabling electronic design automation software to directly perform calculations and analyses based on the variable relationship data structure without repeatedly backtracking the abstract syntax tree or executing complex syntax-level algorithms. This improves the efficiency and accuracy of electronic design automation software in calculating and analyzing signal relationships within the module's scope. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a module data generation method based on an abstract syntax tree provided in one embodiment of this application;

[0017] Figure 2 This is a schematic diagram of the abstract syntax tree in the module data generation method based on the abstract syntax tree provided in one embodiment of this application;

[0018] Figure 3 This is a schematic diagram of the variable declaration syntax construction of a module data generation method based on an abstract syntax tree provided in one embodiment of this application;

[0019] Figure 4 This is a schematic diagram of node objects in a variable relationship graph of a module data generation method based on an abstract syntax tree provided in one embodiment of this application;

[0020] Figure 5 This is a schematic diagram of the connection between node objects and edge objects in the variable relationship graph of the module data generation method based on abstract syntax tree provided in one embodiment of this application;

[0021] Figure 6 This is a schematic diagram of a node mapping table recording node objects in the form of a module data generation method based on an abstract syntax tree provided in one embodiment of this application;

[0022] Figure 7 This is a schematic diagram of a node mapping table recording node objects and edge objects in the form of a module data generation method based on an abstract syntax tree provided in one embodiment of this application;

[0023] Figure 8 This is a schematic diagram of a node mapping table recording node objects and edge objects in the form of a module data generation method based on an abstract syntax tree, provided in another embodiment of this embodiment.

[0024] Figure 9 This is a schematic diagram of the structure of an electronic device using a module data generation method based on an abstract syntax tree, provided in another embodiment of this application. Detailed Implementation

[0025] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0026] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0027] Figure 1This illustration shows an optional flowchart of a module data generation method based on an abstract syntax tree according to an embodiment of this application.

[0028] See Figure 1 The module data generation method based on abstract syntax trees provided in this embodiment includes the following steps:

[0029] S100: Obtain digital circuit design files, parse digital circuit design files, and generate corresponding abstract syntax trees;

[0030] S200 identifies the module scopes contained in the abstract syntax tree and creates a variable relationship data structure corresponding to the module scopes;

[0031] S300, traverse the abstract syntax tree corresponding to the module scope, determine the leaf nodes in the abstract syntax tree during the traversal, and create node objects corresponding to the leaf nodes in the variable relation data structure;

[0032] S400, determine the signal association relationship between leaf nodes, and create an association relationship object in the variable relationship data structure based on the signal association relationship between leaf nodes.

[0033] In this embodiment, the digital circuit design file is a data carrier used to hold the hardware description language source file to be parsed. The digital circuit design file is a source code file written in a hardware description language (HDL) to describe the behavior or structure of a digital logic circuit. The digital circuit design file includes syntactic constructs such as circuit module definitions, port declarations, variable declarations, and logical assignments. The aforementioned digital circuit design file can be, but is not limited to, a text file in Verilog, SystemVerilog, or VHDL format. The file extension of the digital circuit design file can be .v, .sv, or .vhd.

[0034] As an example, the Verilog code used in a digital circuit design file to describe the structure, behavior, and connections of a digital circuit is as follows:

[0035] module TOP(

[0036] input [3:0] clk,

[0037] input [3:0] rst,

[0038] input di_0,

[0039] input en1,

[0040] input en2,

[0041] output reg do_0 );

[0043] reg din_ff1;

[0044] reg din_ff2;

[0045] reg din_ff3;

[0046] reg samp;

[0047] always @(posedge clk[0] or negedge rst[0])begin

[0048] if(!rst[0])begin

[0049] din_ff1 <= 'd1 ;

[0050] din_ff2 <= 'd1 ;

[0051] din_ff3 <= 'd1 ;

[0052] end

[0053] else begin

[0054] din_ff1 <= di_0;

[0055] din_ff2 <= din_ff1;

[0056] din_ff3 <= din_ff2;

[0057] end

[0058] end

[0059] always @(*)begin

[0060] if((din_ff1&din_ff2) || (din_ff2&din_ff3)||(din_ff1&din_ff3))begin

[0061] samp = 1'b1;

[0062] end

[0063] else

[0064] samp = 1'b0;

[0065] end

[0066] always @(*)begin

[0067] if(en1)begin

[0068] if(en2)begin

[0069] do_0 = 1'b0;

[0070] end

[0071] else if (samp)begin

[0072] do_0 = 1'b1;

[0073] end

[0074] end

[0075] else

[0076] do_0 = di_0;

[0077] end

[0078] endmodule

[0079] In this embodiment, the abstract syntax tree (AST) is a tree-like data structure generated after parsing the digital circuit design file. It is used to hierarchically represent the various syntactic constructs and their nesting relationships in the source code. For example... Figure 2 As shown, the abstract syntax tree (AST) includes syntactic units such as module definitions, variable declaration blocks, and procedural blocks. The generation of this AST is accomplished by the parser built into the electronic design automation (EDA) software. For example, the steps of parsing the digital circuit design file and generating the AST can be implemented using the Verific parser. As an example, the Verific parser's parsing process can include the following steps: The Verific parser first performs lexical analysis on the digital circuit design file, decomposing the source code into a token stream. Then, it performs syntactic analysis on the token stream according to preset syntactic rules, constructing an AST that reflects the hierarchical and nested relationships of the syntactic structures in the source code, thus converting the original unstructured text code into structured syntactic data that can be processed by a computer. In the final AST, each node corresponds to a different syntactic unit in the source code, and the parent-child relationship between nodes represents the inclusion and hierarchical relationships between syntactic structures. For example, the syntactic node corresponding to a procedural block serves as the parent node, and its child nodes represent the syntactic components such as the sensitivity list, conditional expressions, and statement bodies within that procedural block.

[0080] In this embodiment, module scope is the syntactic scope structure corresponding to a single circuit design module in the abstract syntax tree. The module scope is defined by the syntax node corresponding to the module definition statement `module` in the digital circuit design file as its starting boundary, and the syntax node corresponding to the module termination statement `endmodule` that matches the module definition statement as its ending boundary. Together, they define the scope range within the abstract syntax tree. A module scope is described as a module node in the abstract syntax tree. In some implementations, a digital circuit design file may contain multiple module scopes; correspondingly, the abstract syntax tree may include multiple module scope nodes. The Verific parser identifies each module scope as an independent module scope node, which also contains procedural blocks, variable declaration blocks, etc., as child nodes.

[0081] In this embodiment, the variable relationship data structure is a data structure generated based on and stored independently of the abstract syntax tree (AST), used to record the variable entities within a module scope and the signal connections and driving relationships between them. Specifically, the variable relationship data structure in this embodiment includes node objects representing specific circuit variables and association objects representing the signal connection or driving relationships between node objects. As an example, in electronic design automation (EDA) software, the variable relationship data structure in this embodiment can be an instantiated data structure created for a module scope, such as VariableGraph. This instantiated data structure can store all leaf node objects related to the module scope and their associated relationship objects. In this embodiment, an independent VariableGraph instance is created for each module scope.

[0082] In this embodiment, a leaf node in the abstract syntax tree refers to the smallest syntactic unit node that directly corresponds to a variable, port, or signal and no longer contains lower-level child nodes. Leaf nodes are used to represent indivisible semantic entities in digital circuit design files, specifically corresponding to identifiers such as variable names, signal names, register names, or logical constant values. In some optional implementations, leaf nodes include at least identifier leaf nodes, constant leaf nodes, and reference-type leaf nodes. Identifier leaf nodes represent independently occurring variable identifiers or port identifiers; constant leaf nodes represent literal constants; and reference-type leaf nodes represent structured references to identifier leaf nodes. Structured references include at least bit-select references, partial-select references, and member access references. Specifically, when a leaf node is located under a bit-select syntax construction, partial-select syntax construction, or member access syntax construction, the electronic design automation software classifies the leaf node as a reference-type leaf node and records the corresponding base variable identifier and its reference method information in the parsing information to clarify the reference relationship between the leaf node and the base variable. For example, during the traversal of the abstract syntax tree, when encountering the assignment statement syntax construct din_ff1 <= di_0, the electronic design automation software identifies the leaf node di_0 on the right side of the assignment statement and the leaf node din_ff1 on the left side, and determines the non-blocking assignment-driven relationship between them. Here, din_ff1 and di_0 correspond to the identifier leaf nodes of variable names, respectively. Similarly, in the port declaration statement input clk, clk corresponds to the identifier leaf node under the variable declaration syntax construct.

[0083] In the variable relation data structure of this embodiment, a node object is an electronic design automation software object created for a leaf node in the abstract syntax tree within the variable relation data structure. Each node object corresponds one-to-one with a leaf node in the abstract syntax tree and is used to record the variable information, identifier information, or type information of the corresponding leaf node. In some implementations, in addition to recording the node name or identifier information, the node object also records at least one or more of the following fields: a node type field indicating the semantic category of the leaf node, used to distinguish between identifier leaf nodes, constant leaf nodes, or reference-type leaf nodes; a module scope identifier indicating the module scope to which the node object belongs; bit width information representing the signal bit width corresponding to the leaf node; pointer information pointing to the corresponding leaf node in the abstract syntax tree; and parsing information representing complex reference structures such as bit-select references, partial-select references, or member access. During the process of the electronic design automation software traversing the abstract syntax tree corresponding to the module scope, when a leaf node is detected, the electronic design automation software searches for a node object with the same name within the same module scope in the variable relation data structure. If it does not exist, a new node object is instantiated. For example, when a leaf node is identified in the example code above, a corresponding node object is created in the variable relationship data structure. The leaf node includes the signal names from the example code, such as: clk, rst, di_0, en1, en2, do_0, din_ff1, din_ff2, din_ff3, and sample. It should be noted that the leaf nodes in the abstract syntax tree are syntactic units generated by the parser, while the node object in this embodiment is another set of data related to but not identical to the leaf nodes, constructed by the electronic design automation software in the variable relationship data structure.

[0084] In this embodiment, the signal association relationships between leaf nodes are the signal interaction relationships formed by different leaf nodes in the abstract syntax tree in the circuit structure or timing behavior, used to characterize the driving, control, or dependency effects between variables or signal entities within the same module scope. Signal association relationships are determined by at least one syntax construct. Specifically, signal association relationships include propagation-type signal association relationships and mapping-type signal association relationships. Propagation-type signal association relationships are used to define the direction of signal propagation, characterizing the direction of signal propagation from the signal source node to the signal target node, thereby supporting subsequent drive load traversal analysis. Mapping-type signal association relationships are used to establish a binding mapping between variable reference entities and variable declaration entities and are not used to define the propagation direction. In some optional implementations, the above-mentioned propagation-type signal association relationships include assignment-driven relationships determined by assignment statement syntax, port connection relationships determined by module instantiation syntax, and timing-triggered reference relationships determined by event control syntax; wherein, assignment-driven relationships and port connection relationships are directional relationships, used to characterize the direction of signal propagation from the signal source node to the signal target node, to support subsequent drive load traversal analysis.

[0085] Specifically, the steps for determining the assignment-driven relationship for the assignment statement syntax construction appearing in the abstract syntax tree include: when traversing to the assignment statement syntax construction, the electronic design automation software identifies the leaf nodes contained on both sides of the assignment operator in the assignment statement, and creates node objects of rvalue reference type and lvalue reference type corresponding to the leaf nodes respectively; based on the driving semantics determined by the assignment statement, an assignment-driven type association object is created in the variable relation data structure, wherein the assignment-driven type association object is used to represent the data propagation relationship between rvalue reference and lvalue reference; the association object corresponding to the assignment reference signal association relationship is used to represent the binding mapping relationship between the reference node object and its declaration entity node object, and the above binding mapping relationship is not used to define the data propagation direction.

[0086] Similarly, the steps for determining the timing trigger reference relationship for the process block syntax construction appearing in the abstract syntax tree include: when traversing to the timing trigger description in the process block syntax construction, the electronic design automation software identifies the trigger signal leaf nodes contained in the sensitivity list and creates node objects of timing trigger reference types corresponding to the leaf nodes in the variable relationship data structure. The node objects of timing trigger reference types include node objects of rising edge trigger reference types and node objects of falling edge trigger reference types; based on the timing trigger semantics, an association object of timing trigger reference types is created in the variable relationship data structure. The association object is used to connect the node object used to represent the trigger signal declaration with the node object of the timing trigger reference type, and the connection direction is defined as from the trigger signal declaration node object to the timing trigger reference type node object; further, based on the association relationship between the timing trigger reference type node object and the node object corresponding to the triggered variable in the process block syntax construction, an association object of trigger influence type is created, and the connection direction is defined as from the timing trigger reference type node object to the node object corresponding to the triggered variable, so as to represent the triggering influence of the trigger signal in the sensitivity list on the triggered variable.

[0087] The steps for determining bit selection dependency relationships in the bit selection syntax constructions appearing in the abstract syntax tree include: when traversing to the leaf nodes contained in the bit selection syntax construction, the electronic design automation software determines the base variable identifier corresponding to the bit selection reference leaf node and obtains the node object corresponding to the base variable declaration leaf node in the variable relationship data structure; based on the bit selection syntax construction, it is determined that there is a bit selection dependency relationship between the bit selection reference leaf node and its belonging multi-bit variable declaration leaf node, and an association object of the bit selection dependency type is created in the variable relationship data structure. The association object of the bit selection dependency type is used to represent the dependency mapping relationship between the multi-bit variable declaration node object and the bit selection reference node object.

[0088] In this embodiment, the association object is an objectified entity in the variable relationship data structure used to represent the logical association between two or more node objects based on syntax construction, and used to carry the signal association information between node objects. Specifically, the signal association between the leaf nodes includes the timing trigger reference relationship determined by the trigger edge type and the trigger signal leaf node in the event control syntax construction. The keywords corresponding to the trigger edge type include posedge or negedge, and the keywords corresponding to the trigger signal leaf node include clk[0] and rst[0]. In addition, the assignment driving relationship between the right leaf node and the left leaf node in the non-block assign statement, the control relationship between the condition leaf node and the target leaf node in the conditional statement, the logical driving relationship between multiple leaf nodes in the combinational logic expression that constitute the output leaf node, and the connection relationship between the upper-level port and the sub-module port in the module instantiation statement.

[0089] This embodiment, through the above steps, can supplement the original process and parsing method of parsing digital circuit design documents and generating abstract syntax trees by constructing a variable relationship data structure. Within this variable relationship data structure, node objects corresponding to leaf nodes and relationship objects representing the signal relationships between leaf nodes are created. By mapping variable reference information scattered across different syntax constructions and semantic categories in the digital circuit design document to the same variable relationship data structure, the problem of accurately identifying signal interaction relationships between leaf nodes by relying solely on the abstract syntax tree is effectively avoided. Furthermore, the aforementioned variable relationship data structure can fully reflect the signal relationships within a module, enabling electronic design automation software to directly perform calculations and analyses based on the variable relationship data structure without repeatedly backtracking the abstract syntax tree or executing complex syntax-level algorithms. This improves the efficiency and accuracy of electronic design automation software in calculating and analyzing signal relationships within the module's scope.

[0090] As a preferred implementation, the step of identifying the module scope contained in the abstract syntax tree and creating a variable relationship data structure corresponding to the module scope includes: creating a variable relationship graph, which includes graph node objects and edge objects. The graph node objects correspond to the node objects in the variable relationship data structure, and the edge objects correspond to the association objects in the variable relationship data structure. The ends of the edge objects in the variable relationship graph are connected to the corresponding graph node objects.

[0091] In this embodiment, the variable relationship graph is a graph structure data structure created based on the variable relationship data structure. It is used to structurally represent the variable entities corresponding to each leaf node within the module's scope and the signal relationships between them using graph theory. This forms a topology model that supports traversal analysis and the tracing of signal relationships such as drive load relationships. The variable relationship graph is one implementation of the variable relationship data structure. The aforementioned variable relationship graph uses graph node objects as nodes in the graph and edge objects as edges connecting the graph node objects, mapping the scattered node objects and relationship objects in the variable relationship data structure to a graph structure, thereby forming a topology graph that supports calculations or traversal analysis by electronic design automation software.

[0092] Specifically, such as Figure 4 and Figure 5 As shown, in the variable relationship graph, a graph node object is a node entity in the variable relationship graph. It corresponds to and represents the node objects in the variable relationship data structure, and carries the identification information of the corresponding variable, the scope information of its module, and semantic attribute information. It serves as the basic unit for participating in edge connections in the graph structure. Correspondingly, an edge object is an edge entity in the variable relationship graph used to connect graph node objects. It corresponds to the association object in the variable relationship data structure and is used to represent the signal association relationship and its relationship type between node objects in the graph structure.

[0093] For example, after the variable relationship data structure is constructed, electronic design automation (EDA) software also includes the step of creating a variable relationship graph corresponding to the module scope. Specifically, creating the variable relationship graph corresponding to the module scope includes creating a data structure class VariableGraph in the EDA software.<NodeType, EdgeType> The steps involved are as follows: creating a graph node object management container to manage graph node objects, and creating an edge node object management container to manage edge objects. During the creation of the variable relationship graph, the electronic design automation (EDA) software first queries the graph node object management container in the variable relationship data structure. If no graph node object corresponding to the currently traversed node object exists in the graph node object management container, a new graph node object is created. This creation operation includes adding the node object to the graph node object management container to establish a one-to-one correspondence between graph node objects and node objects. Subsequently, the EDA software traverses the set of association objects in the variable relationship data structure and creates edge objects corresponding to the association objects. After the edge objects are created, the ends of the edge objects are connected to the corresponding graph node objects. Specifically, the edge objects can be connected to the corresponding graph node objects through their ends, so that the two ends of the edge objects point to the corresponding graph node objects respectively. This establishes the connection relationship between graph node objects in the variable relationship graph to represent the signal association relationship between leaf nodes, such as assignment-driven relationships, timing-triggered control relationships, conditional control dependencies, and cross-module port connection relationships between leaf nodes.

[0094] As an example, the process of the electronic design automation software creating a variable relationship graph corresponding to the current module scope in this embodiment is as follows: During the traversal of the abstract syntax tree, when the assignment statement syntax construct reg_q <= data_in is encountered, the electronic design automation software identifies the assignment driving relationship between the right leaf node data_in and the left leaf node reg_q, as well as the non-blocking assignment. The electronic design automation software creates an association object in the variable relationship data structure to represent the above assignment driving relationship, and then creates corresponding edge objects representing the non-blocking assignment relationship in the variable relationship graph based on the association object. When creating the edge objects, the graph node object corresponding to data_in is used as the signal source end graph node object of the edge object, and the graph node object corresponding to reg_q is used as the signal target end graph node object of the edge object. The edge objects are connected to the above two graph node objects through end references to form a directional graph structure edge from data_in to reg_q in the variable relationship graph. Similarly, when a blocking assignment statement `assign a = b` is detected, the graph node object corresponding to the rvalue identifier `b` is used as the signal source node, and the graph node object corresponding to the lvalue identifier `a` is used as the signal target node. In the above manner, edge objects representing the blocking assignment relationship corresponding to the above blocking assignment statement are created, and the graph structure connection is completed.

[0095] Through the above steps, this embodiment further constructs a variable relationship graph corresponding to the module scope based on the constructed variable relationship data structure. The constructed variable relationship graph maps the node objects and association objects in the variable relationship data structure to graph node objects and edge objects, respectively. By connecting the ends of the edge objects to the corresponding graph node objects, a graph structure model with directional connection relationships is formed. This organizes the scattered variable entities and their signal association relationships within the module scope into a structured topological model that conforms to the definition of graph theory. This provides a directly operable basic graph structure model for subsequent electronic design automation software calculations and analyses such as drive load relationship analysis, circuit timing analysis, path search, and signal relationship analysis. It effectively avoids the problem that it is difficult to accurately identify the signal interaction relationships between leaf nodes by relying solely on abstract syntax trees.

[0096] As an optional implementation, the above-mentioned identification of the module scope contained in the abstract syntax tree and the creation of a variable relationship data structure corresponding to the module scope include: creating a node mapping table, which includes key objects, mapping value objects, and key-value pair mapping relationship objects. The key objects or mapping value objects correspond to node objects in the variable relationship data structure. The key-value pair mapping relationship objects are used to indicate that there is a signal association relationship between the key objects and the mapping value objects. The key-value pair mapping relationship objects connect the key objects or mapping value objects that have a signal association relationship to each other to represent the association relationship between the node objects.

[0097] As an implementation manner of the present invention, in addition to presenting the above variable relationship data structure in the form of a variable relationship diagram as shown in Figure 4 this embodiment provides a node mapping table to present the variable relationship data structure. In other words, the variable relationship data structure can be presented in the form of a variable relationship diagram or in the following form of a node mapping table.

[0098] Specifically, in this embodiment, the variable relationship data structure may be a node mapping table. The above node mapping table is a mapping relationship management table provided in a supporting manner for the variable relationship data structure, and is used to centrally manage the corresponding relationships between node objects within the module scope in the form of key-value pairs, so as to represent the association relationship object between node objects in the form of a table structure. Specifically, the node mapping table can provide the variable relationship data structure with the capabilities of querying by key, querying by value, and associative traversal based on key-value pairs, and is used to represent the association relationship object between node objects in the circuit module in the form of key-value pairs.

[0099] The generation process of the above node mapping table is as follows: after the electronic design automation software analyzes the digital circuit design file and generates an abstract syntax tree, first identify the module scope included in the abstract syntax tree. After obtaining the target module scope, create a variable relationship data structure corresponding to the module scope. During the process of creating the variable relationship data structure, the electronic design automation software initializes the node mapping table in the memory, and the node mapping table includes a key object, a mapped value object, and a key-value pair mapping relationship object.

[0100] In this embodiment, the key object is an object used as the mapping primary key in the node mapping table, which corresponds to and references a node object in the variable relationship data structure and is used to identify the starting node object of the signal association relationship; the mapped value object is an object that forms a mapping relationship with the key object in the node mapping table, which corresponds to and references another node object in the variable relationship data structure and is used to identify the target node object having a signal association relationship with the key object; the key-value pair mapping relationship object is an objectified entity used to represent the mapping relationship between the key object and the mapped value object in the node mapping table, which corresponds to the association relationship object in the variable relationship data structure and is used to record the signal association relationship between node objects and its relationship type information. In this embodiment, through the above key-value pair mapping relationship object, a mapping connection is established between the key object and the mapped value object corresponding to different node objects respectively, so as to represent the association relationship object formed based on the syntax structure between node objects at the node mapping table level.

[0101] In some other implementations, the node mapping table can also be in the form of a data table, or a similar data structure equivalent to a data table. The aforementioned data table-style node mapping table can also be used to centrally record node objects created within the current module scope and the associated relationships between these node objects. Specifically, the data table-style node mapping table can include a node object collection container and an edge object collection container. The node object collection container is used to centrally store and manage node object instances created within the current module scope in the variable relationship data structure, to uniformly maintain the node objects corresponding to each variable entity within the module. The edge object container, when the variable relationship data structure is presented as a variable relationship graph, is used to centrally store and manage edge objects in the graph structure, where each edge object connects two associated relationship objects, representing the connection relationship between two graph node objects at the graph structure level.

[0102] Specifically, the steps for creating the node mapping table in the form of the above data table include: after completing the traversal of the variable declaration syntax construction and procedure block syntax construction under the module scope module TOP, the electronic design automation software creates a set of node objects in the variable relationship data structure to represent the variable entities within the module scope, and registers the corresponding node object identifiers in the node mapping table set up in conjunction with the variable relationship data structure.

[0103] Specifically, such as Figure 6 , Figure 7 and Figure 8 As shown, the variable relationship data structure includes a node object collection container, such as the uniqueNodes container, for managing a collection of node objects, and an edge object collection container, such as the edgesManager container, for managing a collection of associated relationship objects. The node object collection container stores node object instances within the current module scope, for example... Figure 6 As shown, the node object collection container can store node objects clk[3:0] and rst[3:0] for representing variable declaration types of multi-bit variable declarations, node objects clk[0] and rst[0] for representing single-bit variables or bit-select references, and node objects 'd1, din_ff1, din_ff2, din_ff3, samp, do_0, etc., for representing constants or internal registers. Furthermore, the variable relation data structure also includes a collection container of associated objects for recording the connection relationships between node objects represented by the relational object, for example... Figure 7The edgesManager container shown in the diagram, when the electronic design automation software identifies the bit selection reference syntax construction clk[0] during the process of traversing the module scope procedural block syntax construction, and establishes an association between it and the corresponding multi-bit variable clk[3:0] in the variable declaration syntax construction based on the bit selection dependent signal association relationship, the electronic design automation software creates an association object in the edge object collection container to represent the signal association relationship between node object clk[3:0] and node object clk[0]. Similarly, when the bit selection reference syntax construction rst[0] is identified, the electronic design automation software creates an association object in the edge object collection container to represent the signal association relationship between node object rst[3:0] and node object rst[0]. It should be noted that the association object created in the above edge object collection container is represented as an edge object in the variable relationship graph. In the edge object collection container, the following information of the association object is recorded: a key object for identifying the starting node object of the signal association relationship, a mapping value object for identifying the target node object of the signal association relationship, and relationship type information for representing the semantic type of the signal association relationship.

[0104] In the node mapping table of the above data table format in this embodiment, edge objects are represented by connectors in the data table. In some other embodiments, edge objects may also be arrow symbols or other symbols, and this application does not impose any restrictions on this. Through the node mapping table of the above data table format, a data structure that can intuitively reflect the signal association relationship between node objects within the module's scope is constructed at the data level. For example, the association relationship between node objects can be represented in the form of "node object A - node object B".

[0105] This embodiment constructs a node mapping table containing key objects, mapped value objects, and key-value pair mapping relationship objects, or uses a node object collection container and an edge object collection container to realize the table-structured or key-value pair presentation of variable relationship data structure. The above-mentioned node mapping table or data container structure provides a unified and efficient data access entry for electronic design automation software, enabling the software to quickly locate node objects and obtain signal association information directly through key query, value query, or traversal of collection containers without traversing complex tree structures. This further improves the efficiency and speed of electronic design automation software in calculating and analyzing signal association relationships within the module scope.

[0106] As an optional implementation, the abstract syntax tree corresponding to the module scope is traversed. During the traversal, the leaf nodes in the abstract syntax tree are determined, and node objects corresponding to the leaf nodes are created in the variable relation data structure. This includes the following steps:

[0107] The module scope contained in the abstract syntax tree includes at least variable declaration syntax constructs and procedural block syntax constructs;

[0108] It iterates through the variable declaration syntax constructs in the module scope, identifies the leaf nodes contained in the variable declaration syntax constructs during the traversal, and creates node objects corresponding to each leaf node in the variable relationship data structure.

[0109] In this embodiment, the abstract syntax tree corresponding to the module scope includes at least variable declaration syntax constructions and procedural block syntax constructions. Specifically, the variable declaration syntax construction is a syntax construction in the abstract syntax tree used to represent the declaration of ports and internal signals within the module. It includes syntax nodes introduced by port declaration keywords and data declaration keywords, used to introduce variable entities within the module scope. Correspondingly, the procedural block syntax construction is a syntax construction in the abstract syntax tree used to represent syntax structures with execution timing or combinational logic behavior. It typically corresponds to the syntax nodes of timing or combinational logic procedural blocks, used to describe the operations, assignments, and control logic between variables. For example, such as Figure 3 As shown, the variable declaration syntax construction in the abstract syntax tree can include port declaration syntax constructions described by input [3:0] clk, input [3:0] rst, input di_0, input en1, inputen2, and output reg do_0, as well as internal signal declaration syntax constructions described by reg din_ff1, reg din_ff2, reg din_ff3, and reg samp. Both the port declaration syntax constructions and internal signal declaration syntax constructions belong to variable declaration syntax constructions. Correspondingly, the procedure block syntax construction usually corresponds to the syntax nodes in the abstract syntax tree used to represent procedure statements such as always and initial. For example, in the abstract syntax tree, always @(posedgeclk[0]or negedge rst[0]) begin ... end can be used to represent a sequential logic procedure block, while two always @(*) begin ... end can represent a combinational logic procedure block.

[0110] The process of constructing variable declaration syntax in the traversal module scope in this embodiment is as follows: First, taking the module scope module TOP as the starting point of traversal, a depth-first traversal is performed only for the variable declaration syntax construction under the module scope module TOP to identify the leaf nodes in the variable declaration syntax construction. The leaf nodes of the above variable declaration syntax construction may include the leaf node corresponding to the identifier clk when traversing to the port declaration input [3:0] clk, and the leaf node corresponding to the identifier din_ff1 when traversing to reg din_ff1. Similarly, common identifiers that are identified as leaf nodes during the traversal process may also include rst, di_0, en1, en2, do_0, din_ff2, din_ff3, samp, etc.

[0111] After identifying the aforementioned leaf nodes, the electronic design automation software creates a corresponding node object for each leaf node in the variable relational data structure. For example, for each leaf node identified during the traversal, node objects corresponding to the leaf nodes are created in the variable relational data structure, such as rst, di_0, en1, en2, do_0, din_ff2, din_ff3, and samp. These node objects are used to represent the leaf nodes in the variable relational data structure in object form. The node objects point to the corresponding leaf nodes in the abstract syntax tree, thus maintaining the correspondence between the variable relational data structure and the abstract syntax tree.

[0112] In the specific implementation process, the creation order of node objects is consistent with the access order of the depth-first traversal of the abstract syntax tree. That is, whenever a leaf node in the variable declaration syntax constructor is identified during the traversal, the corresponding node object is created in the variable relation data structure in sequence according to the traversal order of the leaf node in the abstract syntax tree.

[0113] In some implementations, the node objects created in the variable relationship data structure, in addition to recording the node name or node identifier name information used to represent the corresponding leaf node, further include recording the bit width information or other relevant information of the leaf nodes in the node objects. Specifically, since the Verilog language syntax rules allow users to specify the corresponding bit width range for variables when declaring them, and in subsequent variable assignment, signal driving, and data transmission processes, the matching relationship between variables usually depends on their bit width consistency or bit width relationship, this embodiment, by recording the bit width description information associated with the corresponding leaf node in the node object as described above, can better support subsequent semantic analysis and consistency checks based on variable relationships.

[0114] Furthermore, in some implementations, the node objects created in the variable relational data structure also include pointer information pointing to the corresponding syntax nodes in the abstract syntax tree. This pointer information includes pointers to the leaf nodes in the abstract syntax tree that generated the node object. By recording this pointer information in the node object, a direct association is established between the node object and the specific syntax nodes in the abstract syntax tree, allowing direct access to its position within the abstract syntax tree using the node object as an entry point.

[0115] It should be noted that in the process of constructing and creating node objects using the above traversal variable declaration syntax, only the corresponding node objects for each leaf node are established in the variable relationship data structure. No association objects representing signal-driven or control relationships are yet established between the node objects.

[0116] This embodiment, when traversing the abstract syntax tree corresponding to the module scope, performs traversal at least for the variable declaration syntax constructs contained in the module scope. During the traversal, it identifies the leaf nodes contained in the variable declaration syntax constructs and sequentially creates node objects corresponding to each leaf node in the variable relationship data structure. Thus, while keeping the process and parsing method of parsing digital circuit design documents and generating abstract syntax trees unchanged, it uniformly objectsifies and registers the variable entities introduced by the port declaration syntax constructs and internal signal declaration syntax constructs in the module scope into the variable relationship data structure. Because node objects can point to the corresponding leaf nodes in the abstract syntax tree and maintain consistency with the traversal access order, electronic design automation software can establish a consistent and searchable data entry point for variable entities within the module scope at the variable relationship data structure level. This avoids repeated reliance on the abstract syntax tree for backtracking and locating variable declaration syntax in subsequent processing stages. Furthermore, by recording bit width information and pointer information to the corresponding leaf nodes in the node objects, the variable relationship data structure can provide direct data support for subsequent semantic analysis and consistency checks based on bit width consistency or bit width relationship. It also supports quick access to the position of a node in the abstract syntax tree by using the node object as an entry point, thereby improving the efficiency and accuracy of the electronic design automation software in performing semantic analysis and computation on variable entities within the module scope.

[0117] As an optional implementation, determining the signal association between leaf nodes and creating association objects in the variable relationship data structure based on the signal association between leaf nodes includes: traversing the procedural block syntax construction, identifying the leaf nodes contained in the procedural block syntax construction during the traversal, and creating node objects and association objects corresponding to each leaf node in the variable relationship data structure, wherein the association objects connect the node objects in the procedural block syntax construction with the corresponding node objects in the variable declaration syntax construction based on the signal association between leaf nodes.

[0118] In this embodiment, the process block syntax construction is a syntax construction in the abstract syntax tree used to represent the sequential or combinational logic behavior within a module. It corresponds to the syntax nodes of process statements and is used to describe the operations, assignments, and control relationships between variables. In specific implementation, when the electronic design automation software traverses the abstract syntax tree corresponding to the module scope, it performs a traversal operation on the process block syntax construction. During the traversal, it identifies the leaf nodes contained in the process block syntax construction. The leaf nodes include syntax nodes corresponding to variable identifiers involved in assignment, conditional judgment, event triggering, or expression evaluation. When a leaf node in the process block syntax construction is identified, the electronic design automation software creates a corresponding node object for each leaf node in the variable relationship data structure. If a corresponding node object for a leaf node has already been created during the previous traversal of the variable declaration syntax construction, the existing node object is reused to ensure that the same leaf node corresponds to a unique node object instance in the variable relationship data structure. In further traversal, the electronic design automation software determines whether there is a signal association relationship between the leaf nodes determined by the syntax construction based on the statement structure of the process block syntax construction. In some alternative implementations, signal association relationships include, but are not limited to, assignment-driven relationships formed by assignment statements, timing-triggered control relationships formed by event control statements, conditional control dependency relationships formed by conditional judgment statements, and logical driving relationships between multiple leaf nodes and target leaf nodes formed by combinational logic expressions.

[0119] When the aforementioned signal association relationship is determined to exist between leaf nodes, the electronic design automation software creates an association relationship object corresponding to the signal association relationship in the variable relationship data structure. After creating the association relationship object, the association relationship object connects the node object in the procedure block syntax construction with the corresponding node object in the variable declaration syntax construction based on the signal association relationship between leaf nodes, so as to explicitly represent the signal association relationship between the variable usage behavior in the procedure block syntax construction and the variable definition in the variable declaration syntax construction in the variable relationship data structure.

[0120] This embodiment further performs traversal on the procedural block syntax construction during the process of traversing the abstract syntax tree corresponding to the scope of the traversal module. During the traversal, leaf nodes involved in assignment, condition judgment, event triggering, and expression calculation in the procedural block syntax construction are identified, and corresponding node objects are created or reused for the leaf nodes in the variable relationship data structure. At the same time, based on the signal association relationship determined by the procedural block syntax construction, association relationship objects are created in the variable relationship data structure to represent the signal association relationship between node objects, so that the node objects in the procedural block syntax construction are connected with the corresponding node objects in the variable declaration syntax construction.

[0121] Therefore, while maintaining the process and method of parsing digital circuit design documents and generating abstract syntax trees, the assignment-driven relationships, timing-triggered control relationships, conditional control dependencies, and combinational logic-driven relationships, which are only implicitly present in the abstract syntax tree through hierarchical relationships, can be explicitly mapped and recorded in a variable relationship data structure. This allows the variable relationship data structure to fully reflect the signal associations introduced by the procedure block syntax construction within the module scope. Based on this variable relationship data structure, electronic design automation software can directly calculate and analyze the associations between variable usage behavior and variable declarations in procedure blocks without repeatedly backtracking or performing complex syntax-level parsing of the abstract syntax tree. This improves the efficiency and accuracy of electronic design automation software in analyzing and processing signal associations within the module scope.

[0122] As an optional implementation, the procedural block syntax construction is traversed. During the traversal, leaf nodes contained in the procedural block syntax construction are identified, and node objects and associated relationship objects corresponding to each leaf node are created in the variable relationship data structure. This includes: identifying the timing trigger description in the procedural block syntax construction, where the timing trigger description includes a sensitivity list introduced by event control symbols; when traversing to a leaf node contained in the sensitivity list, a node object of timing trigger reference type corresponding to the leaf node is created in the variable relationship data structure, and a relationship is established between the node object of timing trigger reference type and the node object corresponding to the variable triggered in the procedural block syntax construction triggered by the sensitivity list. Signal association is established by creating association objects in the variable relationship data structure. Among them, the node objects of the timing-triggered reference type include rising edge-triggered reference type node objects and falling edge-triggered reference type node objects. The association object connects the rising edge-triggered reference type node objects or falling edge-triggered reference type node objects with the corresponding node objects in the variable declaration syntax construction. Furthermore, it establishes a connection between the timing-triggered reference type node objects and the node objects corresponding to the triggered variables in the procedure block syntax construction under the sensitivity list that participate in assignment, condition control, or logical operation, so as to represent the timing-triggered signal association relationship between the variables in the sensitivity list and the variables they trigger.

[0123] In this embodiment, the timing trigger description includes leaf nodes of timing trigger reference types. These leaf nodes of timing trigger reference types are leaf nodes in the abstract syntax tree located under the event control syntax construction introduced by the event control symbol "@", used to represent the signal identifiers participating in the triggering conditions of the process block. They represent the syntax units in which the variable is referenced as a trigger source in the timing trigger context. In this embodiment, node objects are created in the variable relation data structure for the leaf nodes of timing trigger reference types to represent the reference semantics of the variable in the timing trigger context. The node objects of timing trigger reference types include node objects representing rising edge triggering reference types and node objects representing falling edge triggering reference types.

[0124] Specifically, during the depth-first traversal of the process block syntax construction, the electronic design automation software first identifies whether the process block syntax construction contains a timing trigger description. The timing trigger description characterizes the triggering condition of the process block, and in the abstract syntax tree, it corresponds to the syntax construction node introduced by event control symbols, such as the event control symbol "@". When traversing to the leaf node corresponding to the timing trigger description, a node object of the timing trigger reference type corresponding to the leaf node is created in the variable relationship data structure. This timing trigger reference type node object characterizes the reference meaning of the variable in the timing trigger context. Depending on the triggering condition, the aforementioned timing trigger reference type node objects include rising edge trigger reference type node objects and falling edge trigger reference type node objects. For example, during the process of traversing the timing-triggered description and searching for leaf nodes, the clock signal leaf node clk[0] in the rising-edge triggered context and the reset signal leaf node rst[0] in the falling-edge triggered context are found. Accordingly, in the variable relation data structure, a rising-edge triggered reference type node object is created for clk[0], and a falling-edge triggered reference type node object is created for rst[0]. Furthermore, based on the signal association relationship between the timing-triggered reference type node object and the corresponding node object in the variable declaration syntax construction, an association relationship object is created in the variable relation data structure to connect the node object in the procedural block syntax construction with the corresponding node object in the variable declaration syntax construction.

[0125] like Figure 4As shown, as an example, the above-mentioned association object connects the rising edge triggered reference type node object or the falling edge triggered reference type node object with the corresponding node object in the variable declaration syntax construction. This includes connecting the rising edge triggered reference type node object clk[0] with the corresponding variable declaration type node object clk[3:0] after creating the above-mentioned timing triggered reference type node objects clk[0] and rst[0].

[0126] This embodiment identifies the timing-triggered descriptions in the procedural block syntax construction during the traversal of the abstract syntax tree corresponding to the module scope. When traversing to the leaf node contained in the timing-triggered description introduced by the event control symbol, a node object of the timing-triggered reference type corresponding to the leaf node is created in the variable relationship data structure. The node object is distinguished as either rising-edge triggered or falling-edge triggered based on the triggering context. At the same time, based on the signal association relationship between the timing-triggered reference type node object and the corresponding node object in the variable declaration syntax construction, an association relationship object is created in the variable relationship data structure to explicitly connect the timing-triggered reference in the procedural block syntax construction with the variable definition in the variable declaration syntax construction.

[0127] Therefore, while maintaining the process and parsing method of parsing digital circuit design documents and generating abstract syntax trees, the timing trigger information that is only implicit in the event control syntax construction in the abstract syntax tree is structurally recorded in the variable relationship data structure in the form of node objects and relational objects. This allows the reference semantics of variables in different timing trigger contexts to be distinguished and preserved, thereby avoiding the problem that it is difficult to accurately associate variable timing trigger attributes by relying solely on the abstract syntax tree. Furthermore, electronic design automation software can directly analyze and calculate the timing trigger relationships within the module scope based on the variable relationship data structure without performing complex backtracking of the abstract syntax tree, thus improving the efficiency and accuracy of timing-related analysis and processing.

[0128] As an optional implementation, the procedural block syntax construction is traversed. During the traversal, leaf nodes contained in the procedural block syntax construction are identified, and node objects and association objects corresponding to each leaf node are created in the variable relationship data structure. This includes: determining the bit selection dependency signal association between the bit selection reference leaf node and its corresponding multi-bit variable declaration leaf node based on the bit selection syntax construction corresponding to the bit selection reference leaf node; and creating an association object in the variable relationship data structure to represent the bit selection dependency relationship based on the bit selection dependency signal association, so as to connect the node object of the bit selection reference type with the node object corresponding to the multi-bit variable declaration.

[0129] In this embodiment, when the leaf node included in the timing trigger description is a bit-selection reference leaf node, the electronic design automation software further identifies the bit-selection syntax construction of the bit-selection reference leaf node to obtain the bit-selection base variable identifier and bit-selection index information. Specifically, for the leaf node clk[0], the electronic design automation software determines from the bit-selection syntax construction that its base variable is clk and the bit-selection index is 0, and retrieves the multi-bit variable declaration leaf node clk[3:0] corresponding to the base variable clk in the variable declaration syntax construction, thereby determining that there is a bit-selection subordinate signal association relationship between clk[0] and clk[3:0]. Accordingly, the electronic design automation software creates an association object in the variable relationship data structure to represent the bit-selection subordinate relationship, and connects the node object clk[0] representing the bit-selection reference with the node object clk[3:0] representing the multi-bit variable declaration; similarly, for the leaf node rst[0], the bit-selection subordinate signal association relationship and the corresponding association object between rst[0] and rst[3:0] are established.

[0130] In some implementations, bitwise dependent signal association is used as a specific type of declaration reference mapping relationship to uniformly map bitwise references to their respective declaration entities under different syntax constructions, so that when performing traversal analysis along the direction of signal association, it can be extended from multi-bit variable declaration node objects to their bitwise reference node objects.

[0131] As an optional implementation, the procedural block syntax construction is traversed. During the traversal, leaf nodes contained in the procedural block syntax construction are identified, and node objects and association objects corresponding to each leaf node are created in the variable relationship data structure. This includes: identifying assignment statement descriptions in the procedural block syntax construction; when traversing to a leaf node contained in an assignment statement description, creating a node object of lvalue reference type or rvalue reference type corresponding to the leaf node in the variable relationship data structure; and based on the assignment reference signal association relationship between the node object of lvalue reference type or rvalue reference type and the corresponding node object in the variable declaration syntax construction, creating an association object in the variable relationship data structure, which connects the node object of lvalue reference type or rvalue reference type to the corresponding node object in the variable declaration syntax construction.

[0132] In this embodiment, the assignment statement description is a syntactic construct description in the abstract syntax tree used to represent the assignment relationship between variables within a procedure block. It corresponds to the syntax node containing the assignment operator and includes both blocking and non-blocking assignment statement descriptions. When traversing the assignment statement description, the electronic design automation software identifies the leaf nodes contained on both sides of the assignment operator and, based on their syntactic position in the assignment statement, creates either an lvalue reference type node object or an rvalue reference type node object in the variable relationship data structure. The lvalue reference type node object represents the variable reference located on the left side of the assignment operator, carrying the semantics of being assigned, while the rvalue reference type node object represents the variable or constant reference located on the right side of the assignment operator, carrying the semantics of the data source. Furthermore, based on the assignment reference signal association between node objects of lvalue reference type or rvalue reference type and the corresponding node objects in the variable declaration syntax construction, the electronic design automation software creates an association object in the variable relationship data structure to represent the syntactic correspondence between variable references and variable declaration entities in the assignment statement description. The association object connects the node objects of lvalue reference type or rvalue reference type with the corresponding node objects in the variable declaration syntax construction, thereby explicitly establishing the connection relationship between variable references and variable declaration entities in the assignment statement description in the variable relationship data structure.

[0133] Specifically, during the depth-first traversal of the process block syntax construction, the electronic design automation software further identifies whether the process block syntax construction contains assignment statement descriptions. Assignment statement descriptions characterize the assignment relationships between variables in the process block, and in the abstract syntax tree, they correspond to syntax construction nodes containing assignment operators. It should be noted that assignment statement descriptions include blocking assignment statement descriptions and non-blocking assignment statement descriptions. Blocking assignment statement descriptions correspond to assignment syntax constructions using the assignment symbol "=", while non-blocking assignment statement descriptions correspond to assignment syntax constructions using the assignment symbol "<=".

[0134] When traversing to the assignment statement description, the electronic design automation (EDA) software further traverses the leaf nodes contained on both sides of the assignment operator in the assignment statement description, and identifies the leaf nodes as variable identifier nodes referenced in the assignment context. Based on the syntactic position of the leaf node in the assignment statement description, the EDA software determines its corresponding assignment reference semantics and creates a reference type node object corresponding to the leaf node in the variable relationship data structure. Specifically, leaf nodes located to the left of the assignment operator are identified as variable identifier nodes carrying lvalue reference semantics, and a corresponding lvalue reference type node object is created; leaf nodes located to the right of the assignment operator are identified as variable identifier nodes or constant nodes carrying rvalue reference semantics, and a corresponding rvalue reference type node object is created. For example, when iterating through the assignment syntax construction corresponding to `din_ff1 <= di_0`, the electronic design automation (EDA) software identifies the leaf node `din_ff1` on the left side of the assignment operator as a leaf node of lvalue reference type and creates a corresponding lvalue reference type node object in the variable relation data structure. Simultaneously, it identifies the leaf node `di_0` on the right side of the assignment operator as a leaf node of rvalue reference type and creates a corresponding rvalue reference type node object. Similarly, when iterating through the assignment statements `din_ff2 <= din_ff1` and `din_ff3 <= din_ff2`, the EDA software creates lvalue reference type node objects corresponding to `din_ff2` and `din_ff3`, and rvalue reference type node objects corresponding to `din_ff1` and `din_ff2`, respectively.

[0135] Furthermore, based on the assignment reference signal association between node objects of lvalue reference type or rvalue reference type and the corresponding node objects in the variable declaration syntax construction, the electronic design automation software creates an association object in the variable relationship data structure to connect the node objects involved in the assignment statement description with the corresponding node objects in the variable declaration syntax construction, so as to represent the syntactic correspondence between variable references and variable declaration entities in the assignment statement description.

[0136] like Figure 5As shown in the example, when iterating to the assignment statement `din_ff2 <= 'd1`, the electronic design automation (EDA) software creates a node object representing the lvalue reference type of the variable `din_ff2`, and a node object representing the rvalue reference type of the constant `'d1`. Then, it determines the node object used to represent the variable `din_ff2` in the variable declaration syntax construction, and creates an association object based on the assignment reference signal association, connecting the lvalue reference type node object with the variable declaration type node object. Similarly, when iterating to the assignment statements `din_ff1 <= di_0`, `din_ff2 <= din_ff1`, and `din_ff3 <= din_ff2`, the EDA software establishes the corresponding association objects in the variable relationship data structure in the same way.

[0137] In the above manner, the syntactic correspondence between the variable reference relationship introduced by the assignment statement description in the process block syntax construction and the variable declaration syntax construction is uniformly displayed and represented in the variable relation data structure, thereby providing data support for the semantic analysis and computational processing related to electronic design automation software and user execution of assignment statements.

[0138] It should be noted that, in this embodiment, the steps of traversing the process block syntax construction and identifying the leaf nodes contained in the process block syntax construction, creating node objects corresponding to each leaf node and association objects in the variable relationship data structure, are applicable not only to the above-mentioned timing trigger description and assignment statement description, but also to the identification and representation of leaf nodes and their signal associations introduced by other types of syntax constructions. Specifically, electronic design automation software can create corresponding association objects in the variable relationship data structure based on the semantic types corresponding to different syntactic constructs in the abstract syntax tree. These semantic types include: association objects of type combination for representing combinational logic dependencies; association objects of type posedge, negedge, or both edge for representing event-triggered control relationships; association objects of type assign for representing data-driven relationships; association objects of type if control or case control for representing conditional control relationships; association objects of type declare or net for representing variable declaration dependency relationships or signal connectivity relationships; and association objects of type gate or buffer for representing gate-level logic or buffered logic signal transmission relationships.

[0139] This embodiment identifies assignment statement descriptions in the procedural block syntax construction during the traversal of the abstract syntax tree corresponding to the module scope. When traversing to the leaf node contained in the assignment statement description that includes the assignment operator, based on the syntactic position of the leaf node on the left and right sides of the assignment operator, node objects of lvalue reference type or rvalue reference type are created in the variable relation data structure, respectively. Based on the assignment reference signal association relationship between the node objects of lvalue reference type or rvalue reference type and the corresponding node objects in the variable declaration syntax construction, an association relationship object is created in the variable relation data structure to explicitly connect the variable reference in the assignment statement description with the variable declaration entity in the variable declaration syntax construction.

[0140] Therefore, while maintaining the process and parsing method of parsing digital circuit design documents and generating abstract syntax trees, the assignment reference relationships that are scattered in different assignment statement descriptions and exist only implicitly in the syntactic hierarchy are structurally recorded in the variable relationship data structure as node objects and associated relationship objects. This allows the lvalue reference semantics and rvalue reference semantics of the same variable in the assignment context to be distinguished and preserved. This avoids the problem that it is difficult to accurately describe the reference role and data source / carrying semantics of variables in assignment statements by relying solely on the abstract syntax tree. Furthermore, it enables electronic design automation software to directly perform semantic analysis and calculation processing related to assignment statements based on the variable relationship data structure without repeatedly backtracking the abstract syntax tree.

[0141] As an optional implementation, the module scope contained in the abstract syntax tree also includes at least one untraversed syntax construct; after completing the traversal of the procedural block syntax construct, the untraversed syntax constructs are traversed one by one. During the traversal, the leaf nodes contained in each syntax construct are identified, and node objects corresponding to the leaf nodes are created in the variable relation data structure. Based on the signal association relationship between each leaf node, an association relationship object representing the signal association relationship between the node objects is created in the variable relation data structure.

[0142] The module scope contained in the abstract syntax tree corresponds to a single module definition in the digital circuit design file. After completing the traversal of the variable declaration syntax construction and at least one procedural block syntax construction corresponding to a single module definition in the abstract syntax tree corresponding to the module scope, the module scope may still include several syntax constructions that have not been traversed. The syntax constructions that have not been traversed include the procedural block syntax construction, the continuous assignment syntax construction, and the module instantiation syntax construction. The above syntax constructions exist as the lower-level syntax constructions of the module scope node in the abstract syntax tree. They further contain several indivisible syntax units, i.e., leaf nodes, such as signal identifier clk[3], port identifier, and instance identifier.

[0143] Therefore, as a preferred implementation, after traversing the grammar construction of the process block, the electronic design automation software, based on the set of grammar constructions maintained in the module scope, filters out grammar constructions that have not yet been traversed, and performs traversal on each untraversed grammar construction one by one. Preferably, a depth-first traversal is used, starting from the root node of each grammar construction in the abstract syntax tree and visiting its lower-level grammar nodes level by level. Specific steps include: when traversing to an indivisible grammar unit contained in each grammar construction, the electronic design automation software identifies it as a leaf node contained in the current grammar construction and queries the variable relation data structure to see if a node object corresponding to the leaf node already exists; if it already exists, the node object is reused; if it does not yet exist, a node object corresponding to the leaf node is created in the variable relation data structure, thereby ensuring that each leaf node appearing in the module scope has a unique corresponding node object in the variable relation data structure. After creating node objects in each untraversed syntax construct, the electronic design automation software further creates association objects representing the signal relationships between node objects in the variable relationship data structure based on the signal relationships between the leaf nodes within each syntax construct, and connects the relevant node objects.

[0144] This embodiment achieves complete coverage of various logic definitions in the digital circuit design file by traversing the syntax construction of the initial process block after completing the traversal of the syntax construction of the initial process block. The syntax constructions that have not been traversed include other process block syntax constructions, continuous assignment syntax constructions, and module instantiation syntax constructions.

[0145] As an optional implementation, after determining the signal association relationships between leaf nodes and creating association relationship objects in the variable relationship data structure based on the signal association relationships between leaf nodes, the following steps are also included:

[0146] Select the target node object in the variable declaration syntax constructor as the starting node;

[0147] In the variable relational data structure, the traversal operation is performed along the direction of the signal relationship represented by the relational object, starting from the starting node, to find the node object that has a signal relationship with the target node object.

[0148] Based on the node objects found during the traversal process that have signal correlation with the target node object, the electronic design automation calculation results used to characterize the target node object are obtained.

[0149] In this embodiment, after the creation of the variable relationship data structure is completed, the electronic design automation software also includes a step of performing electronic design automation calculations based on the variable relationship data structure. First, the node object in the variable relationship data structure corresponding to the circuit object to be queried is determined as the target node object. The target node object refers to the node object selected from the variable declaration syntax construction and used as the query object for signal correlation analysis. It serves as the starting node during the traversal process. For example, in the electronic design automation calculation scenario of driving load analysis, the target node object can be the node object corresponding to the driving end variable waiting to be analyzed. After determining the target node object, the target node object is set as the starting node. Taking the starting node as the traversal starting point, the traversal operation is performed along the direction of the signal correlation represented by the correlation object to find the node object that has a signal correlation with the target node object. The starting node refers to the node object selected in the variable relationship data structure as the starting point of the traversal operation, which is used as the initial node for subsequent traversal analysis along the direction of signal correlation.

[0150] Finally, based on the node objects found during the traversal that have signal correlation with the target node object, the electronic design automation calculation results used to characterize the target node object are obtained. The electronic design automation calculation results refer to the analysis results obtained by the electronic design automation software using the target node object as the starting node, performing a traversal operation along the direction of the signal correlation relationship represented by the correlation relationship object in the variable relationship data structure, and based on the set of node objects found during the traversal that have signal correlation with the target node object.

[0151] The following example of drive load checking in electronic design automation (EDA) calculations illustrates how this embodiment obtains EDA calculation results representing the target node object based on node objects found during the traversal process that have signal relationships with the target node object. Drive load checking refers to the EDA software performing a traversal operation in the variable relationship data structure, using the target node object selected in the variable declaration syntax as the starting node, along the direction of the signal relationships represented by the relationship objects, to find downstream node objects that have signal relationships with the target node object, and then determining whether the target node object has a load in the circuit and its load distribution based on the traversal results.

[0152] In this embodiment, when performing the above-mentioned traversal analysis based on the variable relationship data structure, the traversal direction is determined by the signal association relationship with signal propagation semantics. Specifically, the traversal direction is defined by the assignment-driven relationship and / or port connection relationship, which is used to characterize the direction of signal propagation from the driving end to the referenced end or the controlled end. At the same time, the bit selection dependency relationship and / or declaration reference mapping relationship are used to assist in determining the starting point of the traversal and the range of candidate node objects that can be expanded during the traversal. For example, when using a multi-bit variable declaration node object as the starting node, the electronic design automation software can expand the multi-bit variable declaration node object to its corresponding bit selection reference node object based on the bit selection dependency relationship to determine the candidate reference node objects participating in the subsequent traversal analysis; however, the above-mentioned bit selection dependency relationship itself is not used as the basis for determining the signal-driven propagation direction, and the traversal operation still continues to be executed along the signal propagation direction characterized by the assignment-driven relationship and / or timing-triggered reference relationship.

[0153] First, when the drive load check is performed on the input port variable clk[3:0], the variable declaration node object used to represent clk[3:0] is selected as the starting node, and the node object corresponding to clk[3:0] is the target node object, which is used to determine whether the clock signal is referenced in subsequent logic or timing context, thereby constituting a load.

[0154] In the above-mentioned drive load check, the signal association direction refers to the direction of signal propagation from the driving end to the referenced end, characterized by the assignment drive relationship and / or port connection relationship. It is used to limit the expansion direction of the path in the traversal operation. In this embodiment, during the traversal process, the node object of the input port variable clk[3:0] can be extended to the node object with the bit selection slave signal association relationship, such as clk[0], based on the bit selection slave signal association relationship. Specifically, it includes starting from the node object representing clk[3:0], reaching the node object representing clk[0] through the bit selection slave signal association relationship object, and then further reaching the rising edge triggered reference type node object representing clk[0]. According to the above traversal identification process, the traversal path clk[3:0], clk[0], and the rising edge triggered reference node object of clk[0] are identified as a valid load association path, indicating that there is load for the bit corresponding to clk[0]. Finally, based on the above traversal results, it is shown that only the traversal path corresponding to clk[0] reaches the timing-triggered reference type node object, while clk[1], clk[2], and clk[3] do not reach any load-related path. Therefore, the electronic design automation software can finally obtain and output the above electronic design automation calculation results used to characterize the target node object to the user. In the above example, the above electronic design automation calculation results may be that only the 0th bit of the driver variable clk[3:0] waiting to be analyzed has a load, and the other bit widths do not have a load.

[0155] It should be noted that the electronic design automation calculation based on variable relationship data structure in this embodiment is not only applicable to the above-mentioned drive load check analysis of target node objects, but can also be used for various electronic design automation calculations, including but not limited to: Lint check analysis for analyzing the usage of variables within the module scope to detect unused signals, floating signals, or signal connection relationships that do not conform to coding specifications; structural correlation analysis for characterizing the connection relationship between the drive end and load end of a signal in the circuit to support fan-in and fan-out relationship identification and signal connectivity analysis; cross-clock domain analysis for performing traversal analysis along the signal correlation direction between different clock domains to identify cross-clock domain signal transmission paths, detect potential metastability risks, data loss risks, or multiple data correlation problems; power-related analysis for evaluating and locating power-related behaviors based on signal flip propagation paths and reference relationships; and timing analysis for detecting timing trigger paths, clock signal reference relationships, and their propagation range.

[0156] Through the above technical solution, the present invention can effectively solve the problem that it is difficult to perform signal-level analysis based solely on the abstract syntax tree generated by the Verific parser. Specifically, the parent-child relationship between nodes in the abstract syntax tree is only used to reflect the syntactic subordination structure in the hardware description language source code, and is not used to explicitly represent the signal association relationship between variables, so that variables cannot form a traversable connection path when they appear in different syntactic constructs. For example, the declaration of multiple-bit variables clk[3:0] corresponds to the identifier node in the variable declaration syntax construct, while its bitwise reference clk[0] appears in the subtree corresponding to the event control syntax construct or the assignment statement syntax construct, respectively. The above identifier nodes are only indirectly associated in the abstract syntax tree through their respective syntax construct nodes. There is no explicit connection path in the abstract syntax tree that can directly represent the bitwise subordination relationship between clk[3:0] and clk[0]. Therefore, it is impossible to traverse along the tree structure from the variable declaration node to its trigger reference position, and it is even more impossible to determine whether the reference constitutes load semantics.

[0157] In contrast, this invention constructs a variable relationship data structure on top of an abstract syntax tree, uniformly mapping variable leaf nodes scattered across different syntax constructs to node objects. It also explicitly records the signal relationships between variables through association objects, thus forming a traversable connection path along the signal relationship direction within the variable relationship data structure. Based on this variable relationship data structure, electronic design automation (EDA) software can use the target node object selected in the variable declaration syntax construct as the starting node, perform traversal analysis along the signal relationship direction represented by the association objects, accurately locate node objects with signal relationships to the target node object, and generate EDA calculation results representing the load state of the target node object. This significantly improves the feasibility and accuracy of signal-level analysis.

[0158] Figure 9 A schematic diagram of an electronic device illustrating the module data generation method based on an abstract syntax tree provided in an embodiment of this application is shown. The electronic device includes a processor 101 and a memory 102 storing computer program instructions.

[0159] Specifically, the processor 101 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0160] Memory 102 may include mass storage for data or instructions. For example, and not limitingly, memory 102 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 102 may include removable or non-removable (or fixed) media. In a particular embodiment, memory 102 is a non-volatile solid-state memory.

[0161] Memory 102 may include read-only memory (ROM), flash memory device, random access memory (RAM), disk storage medium device, optical storage medium device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory 102 includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software that may include computer-executable instructions and, when executed (e.g., by one or more processors), is operable to perform the operations described with reference to the methods described above according to the foregoing aspects of this disclosure.

[0162] The processor 101 reads and executes computer program instructions stored in the memory 102 to implement any of the module data generation methods based on abstract syntax trees in the above embodiments.

[0163] In one example, the module data generation electronics based on the abstract syntax tree may further include a communication interface 103 and a bus 310. Wherein, such as Figure 9 As shown, the processor 101, memory 102, and communication interface 103 are connected via bus 310 and communicate with each other.

[0164] The communication interface 103 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0165] Bus 310 includes hardware, software, or both, that couples components of an electronic device to each other using a module data generation method based on an abstract syntax tree. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0166] This electronic device can achieve a combination of modular data generation methods based on abstract syntax trees. Figures 1 to 8 The described method for generating module data based on abstract syntax trees.

[0167] Furthermore, in conjunction with the module data generation method based on abstract syntax trees in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the module data generation methods based on abstract syntax trees in the above embodiments.

[0168] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0169] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0170] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating module data based on abstract syntax trees, characterized in that, Includes the following steps: Obtain digital circuit design files, parse the digital circuit design files, and generate corresponding abstract syntax trees; Identify the module scopes contained in the abstract syntax tree and create a variable relationship data structure corresponding to the module scopes; Create a variable relationship graph, which includes graph node objects and edge objects. The graph node objects correspond to the node objects in the variable relationship data structure, and the edge objects correspond to the association relationship objects in the variable relationship data structure. The ends of the edge objects in the variable relationship graph are connected to the corresponding graph node objects. Traverse the abstract syntax tree corresponding to the module scope, determine the leaf nodes in the abstract syntax tree during the traversal, and create node objects corresponding to the leaf nodes in the variable relationship data structure; The module scope contained in the abstract syntax tree includes at least variable declaration syntax construction and procedural block syntax construction; the variable declaration syntax construction in the module scope is traversed, the leaf nodes contained in the variable declaration syntax construction are identified during the traversal, and the node objects corresponding to each leaf node are created in the variable relationship data structure; Determine the signal association relationships between the leaf nodes, and create association relationship objects in the variable relationship data structure based on the signal association relationships between the leaf nodes.

2. The module data generation method based on abstract syntax tree according to claim 1, characterized in that, The step of identifying the module scope contained in the abstract syntax tree and creating a variable relationship data structure corresponding to the module scope includes: creating a node mapping table, which includes key objects, mapping value objects, and key-value pair mapping relationship objects. The key objects or mapping value objects correspond to the node objects in the variable relationship data structure. The key-value pair mapping relationship objects are used to indicate that there is a signal association relationship between the key objects and the mapping value objects. The key-value pair mapping relationship objects connect the key objects or mapping value objects that have the signal association relationship to each other to characterize the signal association relationship between the node objects.

3. The module data generation method based on abstract syntax tree according to claim 1, characterized in that, The step of determining the signal association relationships between the leaf nodes and creating association relationship objects in the variable relationship data structure based on the signal association relationships between the leaf nodes includes: The process block syntax construction is traversed, and the leaf nodes contained in the process block syntax construction are identified during the traversal. Node objects and association objects corresponding to each leaf node are created in the variable relationship data structure. The association objects connect the node objects in the process block syntax construction with the corresponding node objects in the variable declaration syntax construction based on the signal association relationship between the leaf nodes.

4. The module data generation method based on abstract syntax tree according to claim 3, characterized in that, The step of traversing the process block syntax construction, identifying the leaf nodes contained in the process block syntax construction during the traversal, and creating the node object and the association object corresponding to each leaf node in the variable relationship data structure includes: The timing trigger description in the procedure block syntax construction is identified. When traversing to a leaf node contained in the timing trigger description, a node object of the timing trigger reference type corresponding to the leaf node is created in the variable relationship data structure. Based on the signal association relationship between the node object of the timing trigger reference type and the corresponding node object in the variable declaration syntax construction, an association relationship object is created in the variable relationship data structure. The node object of the timing trigger reference type includes node objects of rising edge trigger reference type and node objects of falling edge trigger reference type. The association relationship object connects the node object of rising edge trigger reference type or the node object of falling edge trigger reference type to the corresponding node object in the variable declaration syntax construction.

5. The module data generation method based on abstract syntax tree according to claim 3, characterized in that, The step of traversing the process block syntax construction, identifying the leaf nodes contained in the process block syntax construction during the traversal, and creating the node object and the association object corresponding to each leaf node in the variable relationship data structure includes: Identify the assignment statement description in the process block syntax construction, and when traversing to the leaf node contained in the assignment statement description, create a node object of lvalue reference type or rvalue reference type corresponding to the leaf node in the variable relationship data structure; Based on the assignment reference signal association relationship between the node object of the lvalue reference type or the node object of the rvalue reference type and the corresponding node object in the variable declaration syntax construction, an association relationship object is created in the variable relationship data structure. The association relationship object connects the node object of the lvalue reference type or the node object of the rvalue reference type with the corresponding node object in the variable declaration syntax construction.

6. The module data generation method based on abstract syntax tree according to claim 3, characterized in that: The module scope contained in the abstract syntax tree also includes at least one untraversed syntax construct; After completing the traversal of the process block syntax construction, the traversal of each of the untraversed syntax constructions continues. During the traversal, the leaf nodes contained in each syntax construction are identified, and node objects corresponding to the leaf nodes are created in the variable relationship data structure. Based on the signal relationship between the leaf nodes, a relationship object representing the signal relationship between the node objects is created in the variable relationship data structure.

7. The module data generation method based on abstract syntax tree according to claim 4, characterized in that, After determining the signal association relationships between the leaf nodes and creating association relationship objects in the variable relationship data structure based on the signal association relationships between the leaf nodes, the following steps are also included: The node object corresponding to the target signal variable declared in the variable declaration syntax construction is selected as the starting node; In the variable relationship data structure, a graph traversal is performed along the signal relationship direction represented by the relationship object, starting from the starting node, to find the load node object corresponding to the target signal variable. Based on the node objects associated with the target signal variable found during the graph traversal, the load state detection result used to characterize the target signal variable is obtained.

8. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions, wherein, when executed by the processor, the processor causes the processor to perform the module data generation method based on an abstract syntax tree according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the module data generation method based on the abstract syntax tree according to any one of claims 1 to 7.

Images