A method, device, electronic device, computer readable storage medium and computer program product for generating a connection code

Abstract

The application provides a connection code generation method and device, electronic equipment, computer readable storage medium and computer program product; the method comprises the following steps: determining a plurality of uniform interface models in the memory for a plurality of source heterogeneous source files corresponding to a plurality of hardware modules; based on each uniform interface model, a hierarchical signal tree is constructed for each hardware module; based on a plurality of signal trees, determine the signal pair to be matched, and determine the bit width topology characteristics of the interface signal in the signal pair to be matched; calculate the similarity between the names of the interface signals in the signal pair to be matched, and the compatibility score of the direction; based on the bit width topology characteristics, the similarity and the compatibility score, determine the consistency score of the signal pair to be matched, and when the consistency score is greater than the score threshold, it is determined that the signal pair to be matched has a connection matching relationship; based on the connection matching relationship, a first connection code is generated. Through the application, the generation accuracy of the connection code of the interface signal can be improved.

Description

Technical Field

[0001] This application relates to integrated circuit design technology, and more particularly to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for generating connection code. Background Technology

[0002] As chip design complexity increases, the integration and connection of hardware modules (IP modules) has become a crucial part of the design process. This step aims to generate correct connection code to accurately connect the interface signals of different hardware modules. However, related technologies suffer from low accuracy in generating connection code for interface signals. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for generating connection codes, which can improve the accuracy of generating connection codes for interface signals.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a method for generating linking code, the method comprising:

[0006] For multiple heterogeneous source files corresponding to multiple hardware modules, multiple unified interface models are determined in memory, wherein the unified interface model includes the name, direction and bit width of the interface signals of the hardware module;

[0007] Based on each of the unified interface models, a hierarchical signal tree is constructed for each of the hardware modules, wherein the signal tree contains multiple hierarchical nodes with parent-child relationships, and each hierarchical node contains at least one interface signal of the hardware module;

[0008] Based on multiple signal trees, a pair of signals to be matched is determined from the interface signals of multiple hardware modules, and based on the bit width, the bit width topology features of the interface signals in the pair of signals to be matched are determined.

[0009] Calculate the similarity between the names of the interface signals in the signal pair to be matched, and determine the compatibility score of the orientation of the interface signals in the signal pair to be matched;

[0010] Based on the bit-width topological features, the similarity, and the compatibility score, the consistency score of the signal pair to be matched is determined, and when the consistency score is greater than the score threshold, a connection matching relationship is determined to exist between the signal pairs to be matched.

[0011] Based on the connection matching relationship, a first connection code is generated to connect the interface signals in the signal pair to be matched.

[0012] This application provides a linking code generation apparatus, comprising:

[0013] The model determination module is used to determine multiple unified interface models in memory for multiple heterogeneous source files corresponding to multiple hardware modules, wherein the unified interface model includes the name, direction and bit width of the interface signals of the hardware module;

[0014] A signal tree construction module is used to construct a hierarchical signal tree for each hardware module based on each unified interface model, wherein the signal tree contains multiple hierarchical nodes with parent-child relationships, and each hierarchical node contains at least one interface signal of the hardware module.

[0015] The signal pair processing module is used to determine a signal pair to be matched from the interface signals of the multiple hardware modules based on multiple signal trees, and to determine the bit width topology features of the interface signals in the signal pair to be matched based on the bit width.

[0016] The index calculation module is used to calculate the similarity between the names of the interface signals in the signal pair to be matched, and to determine the compatibility score of the orientation of the interface signals in the signal pair to be matched.

[0017] The relationship determination module is used to determine the consistency score of the signal pair to be matched based on the bit width topological features, the similarity and the compatibility score, and to determine that there is a connection matching relationship between the signal pair to be matched when the consistency score is greater than the score threshold.

[0018] The code generation module is used to generate a first connection code for connecting the interface signals in the signal pair to be matched, based on the connection matching relationship.

[0019] This application provides an electronic device, the electronic device comprising:

[0020] Memory is used to store executable instructions or computer programs.

[0021] The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the link code generation method provided in the embodiments of this application.

[0022] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implements the link code generation method provided in this application.

[0023] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the linking code generation method provided in this application.

[0024] The embodiments of this application have the following beneficial effects: Multi-source heterogeneous files corresponding to multiple hardware modules are converted into standardized unified interface models in memory, enabling multi-source heterogeneous text to be represented in a unified format in memory. Then, the unified interface model of each hardware module is further reconstructed into a signal tree containing parent-child relationships, thus shielding underlying syntax differences while including relevant information about the logical structure of the interface signals. Based on the signal tree, potential matching signal pairs with connection possibilities are identified from the interface signals of different hardware modules. Multi-dimensional evaluation indicators, including name similarity, direction compatibility, and bit-width topological features, are extracted from the interface signals in the matching signal pairs. The consistency score of the two interface signals is accurately calculated based on these multi-dimensional evaluation indicators, allowing for accurate determination of whether the two interface signals in the matching signal pairs have a connection matching relationship. Based on the connection matching relationship, the first connection code is generated for the two interface signals that truly need to be connected, thereby improving the accuracy of the connection code generation for the interface signals. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the structure of the link code generation system provided in the embodiments of this application;

[0026] Figure 2 This is a schematic diagram of the server structure provided in an embodiment of this application;

[0027] Figure 3 This is a flowchart illustrating the link code generation method provided in the embodiments of this application. Figure 1 ;

[0028] Figure 4 This is a flowchart illustrating the link code generation method provided in the embodiments of this application. Figure 2 ;

[0029] Figure 5 This is a flowchart illustrating the link code generation method provided in the embodiments of this application. Figure 3 ;

[0030] Figure 6 This is a system framework diagram of the intelligent connection provided in the embodiments of this application;

[0031] Figure 7 This is a schematic diagram of the automated connection process provided in the embodiments of this application. Detailed Implementation

[0032] 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. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0034] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0035] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0036] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0037] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0038] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0039] 1) Hardware modules refer to circuit units or subsystems with specific logical functions or computing capabilities in integrated circuit design. As the description object of multi-source heterogeneous source files, they usually contain ports for communication or data interaction with the external environment. In physical implementation, they can be manifested as simple logical combinations or as complex processor cores, controllers or bus interface units.

[0040] 2) A unified interface model refers to a standardized data structure or structured signal set built in memory. It is used to shield the differences in syntax and file format between different hardware description languages. By encapsulating the core attributes extracted from the source file (such as name, direction and bit width), it represents the interface structure of the hardware module in a unified format, thus serving as a common basis for subsequent data processing.

[0041] 3) Interface signals refer to the input / output ports in a hardware module used to carry and transmit data or control commands. They serve as the physical or logical medium for communication between the hardware module and the outside world. Interface signals are the smallest units that need to be identified and processed during the connection code generation process.

[0042] 4) Signal tree refers to a hierarchical topology structure with breadth and depth built on a unified interface model. It maps a flat list of interfaces to hierarchical nodes with parent-child relationships, and intuitively reflects the subordinate and containment relationships of interface signals in hardware modules (such as the relationship between bus and channel, and channel and specific signal) in the form of logical hierarchy, thereby supporting recursive traversal and accurate structural analysis.

[0043] 5) The signal pair to be matched refers to a pair consisting of two interface signals from different sources. This pair represents the potential connection between the two interface signals and is a candidate analysis object for determining whether there is a real connection relationship, performing bit-width topology feature analysis, similarity calculation, and compatibility scoring.

[0044] 6) Connection matching relationship refers to a logical association state recorded in memory after multi-dimensional feature analysis and consistency judgment. This state indicates that the two interface signals are compatible in terms of functional roles and electrical rules, and a data path should be established logically or electrically.

[0045] 7) Connection code refers to the source code snippets generated by connection matching relationships that conform to the syntax specifications of a specific hardware description language (such as Verilog or SystemVerilog). It is used to instantiate or assign values ​​to the interface signals that need to be connected in the circuit design, thereby realizing the physical conduction or logical cascading of the interface signals.

[0046] 8) Bit width conversion logic refers to the adaptation rules or processing strategies determined for interface signals with inconsistent bit widths in the signal pairs to be matched during the process of determining the connection matching relationship, so as to solve the connection problem caused by physical bit width mismatch.

[0047] As chip design complexity increases, the integration and connection of hardware modules (IP modules) has become a crucial part of the design process. This step aims to generate correct connection code to accurately connect the interface signals of different hardware modules. However, the following factors in related technologies can easily affect the generation of connection code.

[0048] First, there is the impact of heterogeneous input from multiple sources. Design environments in related technologies typically include hardware description languages ​​with different levels of abstraction and syntax. However, the lack of a unified framework for understanding these technologies makes it impossible to parse these heterogeneous source files losslessly. Instead, designers must manually rewrite the interface definitions of one language in another to facilitate subsequent interconnection. This approach is highly susceptible to errors or omissions in definitions, leading to inaccurate generated connection code.

[0049] Secondly, at the connection identification mechanism level, most connection methods in related technologies rely solely on string matching or strict type matching. This approach easily leads to the inability to identify semantically similar interface signals. That is, for interface signals with the same function but different naming conventions (such as "wr_data" on the master device and "data_in" on the slave device), they will be treated as irrelevant signals and missed. Simultaneously, this approach cannot handle logical bit-width adaptation. When two logically corresponding but different bit-width interface signals need to be connected, either an error will be directly reported, or the appropriate bit-width adaptation logic (such as truncation or zero padding) cannot be automatically inferred and determined, resulting in an incorrect connection code. Furthermore, related technologies lack verification of the overall structure, relying solely on name matching. This easily leads to the incorrect connection of interface signals with the same or similar names but vastly different functions (e.g., incorrectly connecting the "valid" signal indicating "data valid" to the "address valid" port), thus generating incorrect connection codes.

[0050] Finally, the related technologies lack extension and processing strategies. For interface signals that do not match precisely or are non-standard protocol interface signals, the related technologies can only simply report an error and stop, without a flexible strategy to perform fuzzy matching or invoke the designer's custom rules. This results in the inability of the related technologies to adaptively generate connection code that conforms to specific design intentions when faced with complex and non-standard design requirements, thus leading to low accuracy in the generation of connection code.

[0051] In summary, the related technologies suffer from low accuracy in generating connection codes for interface signals.

[0052] In addition, in related technologies, for multi-source heterogeneous inputs and interface signals with different bit widths, designers have to manually write code to intervene. However, manual code writing is time-consuming, resulting in low efficiency in generating connection code.

[0053] This application provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for generating connection codes, which can improve the accuracy of connection code generation for interface signals. The following describes exemplary applications of the electronic device provided in this application. The electronic device provided in this application can be implemented as various types of terminals such as laptops, tablets, desktop computers, smartphones, and smartwatches, or as a server. The following will describe exemplary applications when the electronic device is implemented as a server.

[0054] See Figure 1 , Figure 1 This is a schematic diagram of the structure of the connection code generation system provided in this application embodiment. To support an application for generating connection codes, in the connection code generation system 100, a terminal 400 (terminals 400-1 and 400-2 are shown as examples) connects to a server 200 via a network 300. The network 300 can be a wide area network (WAN), a local area network (LAN), or a combination of both. The connection code generation system 100 also includes a database 500 for providing data support to the server 200. The database 500 can be configured within the server 200 or can be independent of the server 200. Figure 1 This illustrates the scenario where database 500 is independent of server 200.

[0055] This application embodiment can be implemented collaboratively by a server and a terminal. For example, in response to a user's source file submission operation in a graphical interface (graphical interfaces 400-11 and 400-21 are shown as examples), terminal 400 sends the source file to server 200. After receiving the multi-source heterogeneous source file sent by terminal 400, server 200 determines a first connection code for connecting the interface signals in the signal pair to be matched based on the connection code generation method provided in this application embodiment, and sends the first connection code to terminal 400 so that developers can verify it or proceed with further processing.

[0056] The connection code generation method provided in this application can be applied to various scenarios that require automatic connection of interface signals in different hardware modules, such as top-level integration scenarios of large SoC chips, or mixed development scenarios of new and old development languages.

[0057] 1) Top-level integration scenario of large SoC chips. For example, a mobile phone processor (SoC) chip contains hundreds of hardware modules, such as CPU cores, GPUs, USB controllers, etc. These hardware modules are developed by different suppliers or different teams, resulting in different names for the same hardware model and inconsistent bit widths of interface signals for different hardware models. The server reads the source files of these hardware modules and, based on the connection code generation method provided in the embodiments of this application, automatically identifies the interface signals that should be connected together and generates connection codes for these interface signals, thereby achieving automatic integration.

[0058] 2) Mixed development scenarios using new and old development languages. For example, when designing a new hardware module using SpinalHDL, the new hardware module needs to call a storage controller written in Verilog. The server can read the source files of these storage controllers written in Verilog and, based on the connection code generation method provided in this application, identify the interface signals that should be connected together and generate connection code for these interface signals. Thus, developers can call and connect to the storage controller written in Verilog in the SpinalHDL environment.

[0059] Taking the server mentioned above as an example, which is the electronic device that generates the connection code, see [link / reference]. Figure 2 , Figure 2 This is a schematic diagram of the server structure provided in an embodiment of this application. Figure 2 The server 200 shown includes at least one processor 210, memory 250, and at least one network interface 220. The various components of server 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to implement communication between these components. In addition to a data bus, the bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 240.

[0060] Processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0061] The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 250 may optionally include one or more storage devices physically located away from the processor 210.

[0062] The memory 250 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 250 described in this application embodiment is intended to include any suitable type of memory.

[0063] In some embodiments, memory 250 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0064] Operating system 251 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0065] The network communication module 252 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0066] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A connection code generation device 255 stored in memory 250 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a model determination module 2551, a signal tree construction module 2552, a signal pair processing module 2553, an index calculation module 2554, a relationship determination module 2555, and a code generation module 2556. These modules are logically connected and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0067] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the link code generation method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0068] In some embodiments, an electronic device can implement the link code generation method provided in this application by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be microprogram-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application program, module, or plug-in.

[0069] The following will describe the method for generating connection code provided in this application embodiment, with reference to exemplary applications and implementations of the electronic device provided in this application embodiment. As mentioned above, the electronic device implementing the electronic device provided in this application embodiment can be a terminal, a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0070] See Figure 3 , Figure 3 This is a flowchart illustrating the link code generation method provided in the embodiments of this application. Figure 1 , will combine Figure 3 The steps are explained below. Figure 3 The executing entity is an electronic device.

[0071] Step 101: For the multi-source heterogeneous source files corresponding to multiple hardware modules, determine multiple unified interface models in memory.

[0072] In this embodiment, after obtaining the multi-source heterogeneous source files corresponding to multiple hardware models, the electronic device will parse these source files of different formats and extract the core attributes of the interface signals, namely name, direction and bit width. Then, these core attributes are mapped to a unified data structure predefined in memory to realize the instantiation of the corresponding unified interface model in memory. Thus, the obtained unified interface model includes the name, direction and bit width of the interface signals of the hardware module.

[0073] It should be noted that a hardware module refers to a circuit unit or subsystem with a specific function in an integrated circuit, which typically includes an interface for data interaction with the outside world. In the embodiments of this application, a hardware module can be a simple combination of logic gate circuits, or a complex processor core, memory controller, or bus interface unit, etc.

[0074] Interface signals correspond to the input / output ports of a hardware module. They serve as the medium for communication between the hardware module and the outside world, carrying specific data transmissions or control commands. Key attributes of interface signals include their name, direction, and bit width. The name of the interface signal refers to the identifier assigned to it in the source file, such as clk or data_in. The direction of the interface signal refers to the flow of signal transmission, typically including input, output, and bidirectional (inout). The bit width refers to the number of binary bits contained in the interface signal; for example, a single-bit control signal has a bit width of 1, and a 32-bit data bus has a bit width of 32.

[0075] Multi-source heterogeneous source files refer to source files used to describe the different hardware modules mentioned above and following different syntax specifications. These source files differ in their level of abstraction, syntax structure, and file format, and are therefore multi-source heterogeneous. For example, multi-source heterogeneous source files can be register transfer level (RTL) files written in Verilog or SystemVerilog, high-level abstract description files written in generator languages ​​such as SpinalHDL and Chisel, or interface specification files defined using formats such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML).

[0076] For example, if one hardware module is a memory module described by a Verilog file and another hardware module is a processor module described by a SpinalHDL file, then the Verilog file and the SpinalHDL file can be regarded as multi-source heterogeneous files. In this embodiment, the electronic device will build a unified interface model for these two files in memory. The unified interface model records attributes such as addr (name), Input (direction), and 32 (bit width), but does not retain specific syntax traces such as input[31:0]addr in Verilog or in UInt(32 bits) in SpinalHDL, so that multi-source heterogeneous source files can be represented in memory in a unified format.

[0077] In some embodiments of this application, Figure 3 Step 101, which involves determining multiple unified interface models in memory for the multi-source heterogeneous source files corresponding to multiple hardware modules, can be achieved through the following processing: Parse the multi-source heterogeneous source files separately to obtain the module definitions of multiple hardware modules; extract the port declarations of the interface signals of each hardware module from the module definition of each hardware module, and extract the name, direction, and bit width of the interface signals from the port declarations; create a structured signal set in memory corresponding to the interface structure (i.e., the organization structure of the interface signals) of the hardware modules, and encapsulate the name, direction, and bit width into the structured signal set; the encapsulated structured signal set is determined as the unified interface model.

[0078] It should be noted that a module definition refers to a code block in a multi-source heterogeneous file that defines the boundaries and core attributes of a hardware module. It can be understood as the physical carrier of the hardware model at the source code level, and typically includes the module name, a start and end identifier for the port list, etc. For example, in a Verilog source file, a code segment starting with the keyword `module` and ending with `endmodule` is a module definition; in a SpinalHDL (Scala) source file, a class definition inherited from the `Component` class is a module definition.

[0079] A port declaration is a statement in a module definition that describes the interface between a hardware module and its external environment. It lists all the inputs, outputs, and attributes of the hardware module. For example, the statement `input wire[31:0] data_in` is a port declaration that declares an interface signal named `data_in`, with the direction `input`, and a bit width of 32 bits.

[0080] A structured signal set is a data container created in memory with an organized structure. It is used to encapsulate and store the attributes of interface signals extracted from port declarations, logically organizing interface signals belonging to the same hardware module together. For example, a structured signal set can be understood as an instantiated InterfaceBundle object in memory, which contains a list of elements for storing the name, direction, and bit width data of the interface signals.

[0081] In this embodiment, the electronic device first needs to locate the start and end range of the code describing the hardware module from the source file containing a large amount of code. Then, it processes the code within the start and end range through lexical analysis and syntax analysis to identify specific keywords or syntactic structures used to define the hardware module, thereby obtaining the module definition of the hardware module.

[0082] In some embodiments, the electronic device can read multi-source heterogeneous source files line by line, use a preset regular expression library for matching to determine the start line and end line of the module definition, as well as the name of the hardware module, and then extract the content between the start and end lines as the module definition of the hardware module. For example, the electronic device can use the regular expression pattern ^\s*module\s+(\w+)\s*\( to search for the keyword "module" to locate the start line of the module definition and extract the module name; simultaneously, it scans for the keyword "endmodule" to determine the end line. In other embodiments, the electronic device can convert the source file into an abstract syntax tree (AST), then traverse the AST starting from the root node, searching for nodes of specific types, such as ModuleDeclaration or ComponentDef, and then saving references to these nodes as the module definition of the hardware module.

[0083] After obtaining the module definition of each hardware module, the electronic device first identifies the port description statement from the code contained in the module definition. By parsing the port description statement, it determines the name, direction, and bit width of the interface signal.

[0084] In some embodiments, the electronic device can search for keywords such as input, output, and inout in the code contained in the module definition. After locating the declaration statements containing these keywords, it can extract individual declaration statements using semicolons or commas as delimiters. Then, for each individual declaration statement, the electronic device can determine the direction based on the keywords output and input; then it can identify the content within square brackets [...], calculate the numerical difference (e.g., 7-0+1=8) to obtain the bit width; finally, it can identify the remaining identifier string, such as addr, to use as the name.

[0085] In other embodiments, the electronic device can access the PortList child nodes under the nodes representing module definitions in the abstract syntax tree, and traverse each PortDeclaration object in that child node, reading the attribute values ​​stored in the object's member variables to obtain the name, direction, and bit width. For example, accessing the Identifier member variable to obtain the name; accessing the Direction member variable to obtain an enumerated value (such as Input / Output) as the direction; and accessing the Range or Type member variable to obtain the operating range, and then calculating the bit width using that operating range.

[0086] Finally, the electronic device needs to allocate an independent storage space in memory and build a set of structured signals that can reflect the original interface structure of the hardware module in the storage space. Then, the attributes extracted above, namely name, direction and bit width, are assembled into the set of structured signals that are consistent with the original interface module structure to obtain a unified interface model.

[0087] In some embodiments, the electronic device can first define a class named Bundle or InterfaceModel, and then instantiate a container object of this class in memory for each hardware module. This container object is the carrier of the structured signal set. Then, the electronic device declares and instantiates a Signal object for each port, specifying the name, direction, and bit width, and assigns the name, direction, and bit width to the instantiated Signal object respectively. Finally, the electronic device adds all Signal objects belonging to the hardware module to the container object in memory. In this way, it obtains information on all interface signals of the hardware module, as well as a unified structural model whose internal structure strictly corresponds to the module port list in the source file.

[0088] In other embodiments, the electronic device may also create a master hash table (Map), using the unique identifier of the hardware module (such as the module name) as the key of the master hash table, so that the value of the master hash table is the set of structured signals to be constructed; then, for each value in the master hash table, the electronic device initializes an ordered list or dictionary structure, which is used to store the interface signals belonging to the hardware module, thus forming the physical storage space of the interface structure; finally, the electronic device combines the extracted name, direction and bit width into a standard tuple or JSON object, and then appends the combined standard tuple or JSON object to the ordered list or dictionary structure corresponding to the hardware module, and uses the appended ordered list or dictionary structure as a unified interface model that can reflect the interface structure of the hardware module.

[0089] It is understood that in the embodiments of this application, the electronic device extracts the core attributes of interface signals from multi-source heterogeneous source files with different syntaxes, constructs a structured signal set in memory according to the interface structure of the hardware module, and encapsulates these core attributes into the structured signal set as a unified interface model. In this way, multi-source heterogeneous source files can be converted into a unified interface model with consistent memory format, so as to shield the syntactic differences of different hardware description languages, and enable subsequent processing to be based on a unified standard, which helps to improve the accuracy of connection code generation.

[0090] In other embodiments of this application, Figure 3 Step 101, which involves determining multiple unified interface models in memory for multiple heterogeneous source files corresponding to multiple hardware modules, can also be achieved through the following processing: For each heterogeneous source file, the corresponding parser is called to convert the source file into an abstract syntax tree. Then, the abstract syntax tree is traversed to retrieve the specific node type representing the interface. For each interface node, the name literal, direction keyword, and range operator stored in its child nodes are read. Finally, a general list of interface objects is created in memory, and the name, direction, and bit width are determined based on the extracted name literal, direction keyword, and range operator. Finally, the name, direction, and bit width are assigned to the attribute fields of the interface objects to obtain the unified interface model.

[0091] For example, if the source file of the hardware module is a memory module described by a Verilog file, the electronic device can call the Verilog parser to perform lexical and syntactic analysis on the source code in the Verilog file to convert the character stream of the source code into a sequence of tokens. For example, input is identified as the keyword token KW_INPUT; then, according to the syntactic rules of Verilog, the token sequence is assembled into a hierarchical Abstract Syntax Tree (AST); next, the electronic device accesses each node in the AST. When it accesses a node of type PortDeclaration, it directly reads the Name field in the node to obtain the name data_in; then it reads the Direction field in the node and maps it to the enumeration value of the unified interface model, for example, mapping input to Direction.IN; finally, it parses the Range field in the node and calculates the bit width, for example, if the Range is [31:0], then the bit width is 32.

[0092] Step 102: Based on each unified interface model, construct a hierarchical signal tree for each hardware module.

[0093] Although the unified interface model determined in the preceding steps contains the key attributes of the interface signals, these attributes still exist in the form of a flat list or set, thus failing to reflect the hierarchical structure of the interface signals of the hardware modules. Therefore, in this embodiment, after obtaining the unified interface model of each hardware module, the electronic device needs to reorganize these interface signals according to a tree-like topology with breadth and depth, and use the resulting tree structure as a signal tree. The signal tree contains multiple hierarchical nodes with parent-child relationships, and each hierarchical node contains at least one interface signal of the hardware module.

[0094] In other words, a signal tree is a data structure used to represent the logical hierarchy and containment relationship of interface signals of a hardware module. It maps the hardware interface from a flat list of signals to an object model that can be recursively traversed and compared by a computer program. In the embodiments of this application, the root node of the signal tree represents the overall set of interface signals of the hardware module (e.g., the entire bus interface), the branches of the tree represent nested sub-interfaces or substructures (e.g., write channels in the bus), and the leaf nodes of the tree represent specific interface signals (e.g., address signals in a write channel).

[0095] A hierarchical node is the basic unit that constitutes a signal tree. It can be a leaf node representing a single interface signal or an intermediate node (or parent node) representing a set of related signals. The parent-child relationship refers to the logical subordinate relationship between hierarchical nodes, such as a containment relationship. For example, if a hierarchical node named AXI bus is the parent node, it can contain a child hierarchical node named read address channel. The read address channel, as an intermediate hierarchical node, can further contain leaf hierarchical nodes named address signal. Each hierarchical node contains at least one interface signal of the hardware module. If it is a leaf hierarchical node, it directly contains the attributes of that interface signal; if it is an intermediate hierarchical node, it indirectly covers all interface signals under its subtree by recursively containing child hierarchical nodes.

[0096] It should be noted that electronic devices can infer parent-child relationships and construct signal trees by analyzing specific delimiters in interface signals. In some embodiments, the electronic device can obtain the names of all interface signals in a unified interface model, scan whether the names contain preset delimiters, commonly underscores "_" or periods "."; then, for each interface signal name, the electronic device uses the delimiter to split it into a string sequence, for example, splitting the name axi_aw_addr into the sequence [axi,aw,addr]; next, the electronic device checks whether there is a hierarchical node in the signal tree corresponding to the first element of the sequence (such as axi). If not, it is created as a child node of the root node, and then for that hierarchical node, it checks whether there is a child node corresponding to the second element of the sequence (such as aw). If not, it continues to create... The electronic device recursively executes this process until the processing of the last element of the sequence is completed. Finally, the electronic device encapsulates the interface signal attributes corresponding to the last element of the sequence (such as addr), namely bit width and direction, into the finally created leaf hierarchical node, completing the location of the interface signal in the signal tree.

[0097] For example, if a unified interface model contains the following three interface signals: Interface signal 1: Name: spi_0_mosi, Direction: Output, Bit width: 1; Interface signal 2: Name: spi_0_miso, Direction: Input, Bit width: 1; Interface signal 3: Name: spi_0_clk, Direction: Output, Bit width: 1. For interface signal 1, the electronic device reads its name spi_0_mosi, identifies the underscore as a separator, parses it into a path sequence [spi,0,mosi], then creates a parent-level node named spi under the root node, then creates a child-level node named 0 under the spi node, and finally creates a leaf-level node named mosi under the 0 node, storing the direction "output" and bit width "1" here. For interface signal 2, the electronic device reads its name spi_0_miso and parses it to obtain the path sequence [spi,0,miso]. Then, the electronic device finds that an spi node already exists under the root node and enters it directly. Then, it finds that a 0 node already exists under spi and enters it directly. Next, a leaf-level node named miso is created under the 0 node, and the direction "input" and bit width "1" are written. For interface signal 3, the electronic device reads its name spi_0_clk and parses it to obtain the path sequence [spi,0,clk]. Then, it uses the existing spi node and 0 node. Finally, a leaf-level node named clk is created under the 0 node, and the direction "output" and bit width "1" are written. Thus, the resulting signal tree has a root node, a first-level node named spi is attached under the root node, a second-level node named 0 is contained under the spi node, and three third-level nodes (leaf nodes) are contained in parallel under the 0 node, which are mosi, miso and clk tree structures.

[0098] Electronic devices can also utilize pre-defined schema templates to construct signal trees. In other embodiments, various standard interface schema templates can be pre-defined in the memory of the electronic device, such as the Advanced eXtensible Interface (AXI) template, which defines that it must include parent nodes such as read address channels and write address channels, as well as child nodes such as valid and ready under each channel. The electronic device traverses each interface signal in the unified interface model and calculates the matching degree between the name of the interface signal and the node name defined in each template (which can be achieved through regular expression matching), and determines the appropriate schema template based on the matching degree. For example, if a group of interface signals starts with m_axi_ and contains suffixes such as awvalid and wdata, then the electronic device will determine that the group of interface signals is compatible with the AXI interface schema template. Then, based on the matched schema template, the electronic device generates an empty signal tree skeleton with standard parent-child relationships in memory, and then fills the specific interface signals in the unified interface model into the corresponding hierarchical node slots according to the rules defined in the template. For example, the identified m_axi_awvalid signal is filled into the valid child node position under the parent node of the write address channel in the skeleton; for the remaining interface signals that do not conform to any structural template, the electronic device will directly mount them to other (Misc) level nodes under the root node.

[0099] Step 103: Based on multiple signal trees, determine the signal pairs to be matched from the interface signals of multiple hardware modules, and determine the bit width topology features of the interface signals in the signal pairs to be matched based on the bit width.

[0100] The electronic device traverses multiple signal trees, extracting paired interface signals from two different signal trees according to a preset traversal strategy, such as hierarchy-first or reverse matching, to form a signal pair to be matched. Next, for each interface signal in the signal pair to be matched, the electronic device locates its parent level node in the signal tree. Then, using the bit width of all interface signals under that parent level node, it generates a feature vector or label describing the relative role of each interface signal in the signal pair to be matched. This feature serves as the bit width topological feature of the interface signal, facilitating further analysis based on the bit width topological feature to determine whether the signal pair to be matched has a connection matching relationship.

[0101] In other words, in this embodiment, the signal pair to be matched refers to two interface signals selected from two different signal trees that have potential connection possibilities. It's important to note that at this stage, it's not yet determined whether the two interface signals in the signal pair actually have a connection matching relationship; they are merely selected objects that require subsequent consistency analysis. For example, if hardware module A has an output signal m_data and hardware module B has an input signal s_data_in, the electronic device can first combine these two interface signals into a signal pair to be matched.<m_data,s_data_in> This will be used for further analysis later.

[0102] See Figure 4 , Figure 4 This is a flowchart illustrating the link code generation method provided in the embodiments of this application. Figure 2 In some embodiments of this application, Figure 3 Step 103, which involves determining the signal pair to be matched from the interface signals of multiple hardware modules based on multiple signal trees, can be achieved through the following processing:

[0103] Step 1031: Determine the level depth of each level node in the signal tree.

[0104] In integrated circuit design, interface signals with connection matching relationships are usually located at similar levels, such as top-level connections to top-level connections and sub-module connections to sub-modules. Therefore, in this embodiment, the electronic device can determine the layer depth and then effectively filter the signal pairs to be matched based on the layer depth.

[0105] It should be noted that hierarchy depth refers to the distance metric of a hierarchy node relative to the root node of the signal tree. In this embodiment, the electronic device can calculate the vertical position of each hierarchy node in the signal tree by resolving the parent-child relationships between hierarchy nodes, thereby obtaining the hierarchy depth.

[0106] In some embodiments, the electronic device can initiate a depth-first search (DFS) starting from the root node of the signal tree to determine the level depth. For example, the electronic device can first initialize the depth variable Current_Depth of the root node to 0, then traverse all child level nodes of the current level node, setting the depth of the child level node to Current_Depth+1, and then recursively perform the above operation on each child level node until the leaf level node containing the interface signal is reached. In this way, the level depth of each level node is obtained.

[0107] In other embodiments, the electronic device can initialize the depth counter Depth_Count to 0 for each leaf-level node, then obtain the pointer to the parent-level node of that leaf-level node. If the parent-level node exists, Depth_Count is incremented by 1, and the device moves to the parent-level node. This backtracking operation is then repeated until the root node without a parent-level node is reached. The final Depth_Count is then determined as the depth of the leaf-level node. Similarly, non-leaf-level nodes can be processed in the same way to obtain the depth of each level node.

[0108] Step 1032: For the first interface signal in the first signal tree among multiple signal trees, search for the second interface signal in the second signal tree whose difference in layer depth from the layer node where the first interface signal is located is less than the layer threshold, and determine the first interface signal and the second interface signal as a signal pair to be matched.

[0109] For a given first interface signal in a first signal tree, the electronic device reads the level depth of its corresponding node. Then, using this level depth and a level threshold, it determines a valid depth range in a second signal tree. Finally, it combines the second interface signal within this depth range with the first interface signal to obtain a pair of signals to be matched. Here, the second signal tree is a signal tree other than the first signal tree among multiple signal trees.

[0110] It should be noted that the value of the level threshold can be set according to the actual situation, such as setting it to 1 or 3. This application embodiment does not limit it here.

[0111] For example, the first signal tree contains a first interface signal m_data, which is directly attached to the root node of the first signal tree; the second signal tree contains two second interface signals, wherein the level depth of the second interface signal s_data is 2 and the level depth of the second interface signal internal_debug_signal is 4. If the level threshold is 1, then the electronic device will determine the second interface signal s_data and the first interface signal m_data as a signal pair to be matched.

[0112] It is understood that, in the embodiments of this application, the electronic device can introduce the level depth as a filtering condition so that when generating the signal pair to be matched, it can only search at the same level or adjacent level of the two signal trees, thereby filtering out signal pairs with similar names but large differences in the level depth, so as to improve the accuracy of the signal pair to be matched.

[0113] In other embodiments of this application, Figure 3Step 103, which involves determining the signal pairs to be matched from the interface signals of multiple hardware modules based on multiple signal trees, can also be achieved through the following processing: The root node of the first signal tree and the root node of the second signal tree are determined as the initial current parent node pair; for each parent node in the current parent node pair, all first-level hierarchical nodes under it are obtained, and these hierarchical nodes are combined in pairs to obtain preliminary node pairs; if the hierarchical nodes in the preliminary node pair do not contain specific interface signals (i.e., the next level of this hierarchical node is still a hierarchical node), the similarity of the names of the hierarchical nodes in the preliminary node pair is calculated; if the similarity is greater than a preset threshold, the preliminary node pair is determined as a new current parent node pair to continue the above process; if the similarity is less than or equal to the preset threshold, the search within these two hierarchical nodes is stopped; if the hierarchical nodes in the preliminary node pair are all nodes that directly contain interface signals, the interface signals contained in these two hierarchical nodes are directly extracted, and these two interface signals are determined as the signal pairs to be matched.

[0114] For example, if the structure of the first signal tree of hardware module A is root node -> "Write_Ch" (hierarchical node) -> "addr" (hierarchical node containing interface signals), and the structure of the second signal tree of hardware module B is root node -> "W_Channel" (hierarchical node) -> "address" (hierarchical node containing interface signals), the electronic device first matches the root nodes of hardware module A and hardware module B, and then proceeds to the next level. The electronic device extracts the Write_Ch node of hardware module A and the W_Channel node of hardware module B. Since neither of these nodes directly contains interface signals, the electronic device calculates their name similarity. Assuming that the similarity between Write_Ch and "W_Channel" is greater than a preset threshold, the electronic device will continue to extract the addr node of hardware module A and the address node of hardware module B within the scope of Write_Ch and W_Channel. Since both of these nodes directly contain interface signals, the electronic device will determine the addr signal of hardware module A and the address signal of hardware module B as a signal pair to be matched.

[0115] Of course, in other embodiments, the signal pair to be matched can also be specified in a preset connection rule file, that is, two interface signals manually specified by the user can also be used as the signal pair to be matched.

[0116] This completes the determination of the signal pairs to be matched.

[0117] It should be noted that bit-width topology features are used to characterize the relative position of an interface signal within its current hierarchical node. In other words, it can be understood as the relative role of a given interface signal relative to other interface signals within its hierarchical node. Bit-width topology features can include the relative bit-width ranking of the interface signal, i.e., the ranking of the interface signal's bit-width among all interface signals within its hierarchical node; or the relative bit-width proportion of the interface signal, i.e., the proportion of the interface signal's bit-width to the sum of the bit-widths of all interface signals within its hierarchical node.

[0118] In some embodiments of this application, Figure 3 In step 103, determining the bit width topology of the interface signal in the signal pair to be matched based on bit width can be achieved through the following processing: For the interface signal in the signal pair to be matched, determine its parent level node in the signal tree; obtain the bit width of other interface signals under the parent level node, and sort the bit width of the interface signal and the bit width of other interface signals to obtain a bit width sequence; determine the order of the bit width of the interface signal in the signal pair to be matched in the bit width sequence as the bit width topology of the interface signal.

[0119] It should be noted that the electronic device can sort the bit widths of all interface signals under the parent node in descending order or in ascending order; this embodiment of the application does not limit this.

[0120] For example, if a parent node has four interface signals, namely data (64 bits), addr (32 bits), id (8 bits), and valid (1 bit), where addr (32 bits) is the interface signal in the signal pair to be matched, then the electronic device can determine 2 as the bit width topology feature of the interface signal.

[0121] In other embodiments of this application, Figure 3 Step 103, which determines the bit width topology of the interface signal in the signal pair to be matched based on the bit width, can also be achieved through the following processing: For the interface signal in the signal pair to be matched, traverse the bit widths of other interface signals at the same level to determine the maximum bit width; calculate the proportion of the bit width of the interface signal to the maximum bit width, and normalize the proportion; use the obtained normalized value as the bit width topology of the interface signal.

[0122] For example, if a parent node has two interface signals, wdata (128 bits) and wstrb (16 bits), and if the interface signal wstrb (16 bits) is the interface signal in the signal pair to be matched, then the electronic device can use 16 / 128=0.125 as the bit width topology feature of the interface signal.

[0123] In this way, the electronic device can determine the bit-width topological characteristics.

[0124] Step 104: Calculate the similarity between the names of the interface signals in the signal pair to be matched, and determine the compatibility score of the orientation of the interface signals in the signal pair to be matched.

[0125] After identifying the signal pair to be matched, the electronic device needs to compare the names of the two interface signals in the pair based on character sequences, substring overlap, or semantics to determine a normalized score, which is the similarity score. The higher the similarity score, the more relevant the names of the two interface signals are. Simultaneously, the electronic device also needs to analyze the directions of the two interface signals to determine whether they can be effectively connected, i.e., whether their directions are compatible, thus obtaining a compatibility score.

[0126] In some embodiments of this application, Figure 3 The calculation of the similarity between the names of the interface signals in the signal pair to be matched in step 104 can be achieved through the following processing: For the names of the interface signals in the signal pair to be matched, remove the prefix and suffix to obtain two core words corresponding to the signal pair to be matched; calculate the edit distance between the two core words and determine the semantic association between the two core words according to the semantic rules; and calculate the similarity between the names of the interface signals in the signal pair to be matched based on the edit distance and the semantic association.

[0127] The electronic device first identifies non-core descriptive characters (prefixes and candidates) in the name of the interface signal to extract the core part that truly represents the logic of the interface signal. Here, the electronic device can scan the name of the interface signal in the signal pair to be matched from the beginning to determine if the name starts with a prefix from the prefix dictionary; if so, it truncates it. Next, the electronic device scans the remaining string in the name to determine if it matches the suffix dictionary; if so, it truncates that part of the name. Finally, the electronic device identifies the remaining string as the core word.

[0128] Afterwards, the electronic device will calculate the edit distance between the core words of the two interface signals, and at the same time, make a correlation judgment on the two core words according to the preset semantic rules. For example, it will check whether the core words exist in the same thesaurus or abbreviation mapping table. If they exist, it will determine that the two core words have a semantic relationship; otherwise, it will determine that the two core words do not have a semantic relationship.

[0129] Next, the electronic device can determine an association score based on semantic association. For example, a score of 1 is used for semantic association, while a score of 0 is used for semantic association. Then, the association score is weighted and summed with the normalized result of the edit distance, and the sum is determined as the similarity. Alternatively, when there is semantic association, the electronic device can further determine whether the edit distance is less than a distance threshold. If it is less than the distance threshold, a preset maximum similarity score, such as 1, is used as the similarity of the names of the two interface signals. If it is greater than or equal to the distance threshold, a preset intermediate similarity score, such as 0.5, is used as the similarity of the names of the two interface signals. If there is no semantic association, but the edit distance is less than the distance threshold, a preset intermediate similarity score, such as 0.5, is used as the similarity of the names of the two interface signals. If there is no semantic association and the edit distance is greater than or equal to the distance threshold, the similarity is directly set to the lowest similarity score, such as 0.

[0130] It should be noted that the weighting weights mentioned above can be set according to the actual situation, for example, all weights can be set to 0.5, or they can be set to 0.3 and 0.7 respectively; the distance thresholds mentioned above can be set according to the actual situation, for example, they can be set to 1, or to 0.5, etc.

[0131] For example, if the name of interface signal A is m_axi_awaddr and the name of interface signal B is s_w_address_i, the electronic device can remove the prefix m_ and suffix axi_s_ from the name of interface signal A, then denoise the intermediate result awaddr to obtain the core word addr. Similarly, it can remove the prefix s_ and suffix _i from the name of interface signal B to obtain the intermediate result w_address, and further remove the prefix w_ from this intermediate result to obtain address. Then, the electronic device determines that when converting addr to address, the characters e, s, and s need to be inserted, thus setting the edit distance to 3. Simultaneously, the electronic device queries semantic rules and finds that the entries {addr, address} exist in the same mapping group, determining that there is a strong semantic association between the two. If the edit distance is 5, then the similarity between the two names can be determined to be 1.

[0132] It is understood that in this embodiment of the application, the electronic device extracts core words by removing prefixes and suffixes, and analyzes them to focus on the essential logical name of the interface signal, thereby eliminating the influence of modifier characters on similarity. At the same time, the electronic device analyzes the core words in two dimensions: edit distance and semantic association, and combines the analysis results of these two dimensions to make a similarity judgment, thereby further improving the accuracy of similarity calculation.

[0133] In other embodiments of this application, Figure 3 Step 104 in the process of calculating the similarity between the names of the interface signals in the signal pair to be matched can be achieved through the following process: determine the common subsequence of the names of the interface signals in the signal pair to be matched, and count the number of characters in the common subsequence; count the number of characters in the names of the two interface signals in the signal pair to be matched, and accumulate the two counts to obtain the total number; calculate the ratio of twice the number of characters in the common subsequence to the total number, and determine the ratio as the similarity between the names of the interface signals in the signal pair to be matched.

[0134] It should be noted that a common subsequence refers to a character sequence that appears in the names of two interface signals and maintains a relative order, but is not required to be consecutive.

[0135] For example, if the names of the two interface signals in the signal pair to be matched are wr_data_en (length 10) and w_dat_en (length 8), then the common subsequence of these two interface signals can be w_dat_en, which has a length of 8. The electronic device calculates 2*8 / (10+8)=0.89, and this score is the similarity between the names of the two interface signals.

[0136] At this point, the electronic device has completed the similarity calculation.

[0137] In some embodiments of this application, Figure 3 The compatibility score for determining the direction of the interface signal in the signal pair to be matched in step 104 can be achieved by the following process: checking the direction of the interface signal in the signal pair to be matched, and determining the preset highest score as the compatibility score when the two directions are different; if the two interface signals are the same, determining the preset lowest score as the compatibility score.

[0138] In other words, when one interface signal in the signal pair to be matched is output and the other is input, or when one interface signal is input and the other is output, the electronic device can set the highest preset score, such as 1, as the compatibility score for these two interface directions. When one interface signal in the signal pair to be matched is output and the other is also output, or when one interface signal is input and the other is also input, the electronic device will set the lowest preset score, such as 0, as the compatibility score for these two interface directions.

[0139] In some embodiments of this application, Figure 3The process of determining the compatibility score of the direction of the interface signal in the signal pair to be matched in step 104 can also be achieved by the following steps: determining the hierarchical relationship between the two interface signals; and determining the compatibility score of the two interface signals based on the hierarchical relationship and whether the directions of the two interface signals are consistent.

[0140] The hierarchical relationships here include sibling and parent-child relationships. If the two interface signals are siblings, the valid connection should be complementary (output to input). The electronic device determines the compatibility score based on whether the directions of the two interface signals are complementary. If they are complementary, the preset highest score is set as the compatibility score; otherwise, the preset lowest score is set as the compatibility score. If the two interface signals are parent-child, the valid connection should be in the same direction (i.e., the input of the parent interface signal is directly transmitted to the input of the child interface signal, i.e., through-through). Thus, the electronic device can assign a compatibility score based on whether the directions of the two interface signals are in the same direction.

[0141] Step 105: Based on bit-width topological features, similarity and compatibility scores, determine the consistency score of the signal pairs to be matched, and when the consistency score is greater than the score threshold, determine that there is a connection matching relationship between the signal pairs to be matched.

[0142] After obtaining the bit-width topology features, similarity, and compatibility scores, the electronic device combines these three features to score the consistency of the two interface signals in the signal pair to be matched, thus obtaining a consistency score. Next, the electronic device acquires a score threshold and compares the consistency score with the acquired score threshold. If the consistency score is greater than the score threshold, the electronic device determines that the two interface signals in the signal pair should be connected, thus establishing a connection matching relationship between the two interface signals; if the consistency score is less than or equal to the score threshold, the electronic device determines that the two interface signals in the signal pair should not be connected, thus establishing no connection matching relationship between the two interface signals. The connection matching relationship represents a logical association state, indicating that a data path should be established between specific two interface signals.

[0143] It should be noted that the consistency score represents the degree of equivalence of the two interface signals in the signal pair to be matched in terms of their underlying functional roles after factors such as syntax and naming conventions have been removed. In other words, it reflects whether the two interface signals play the same functional role in the context of their respective hardware modules, such as whether they are both the main data channels of the module or both valid bits in the handshake protocol.

[0144] In some embodiments of this application, Figure 3In step 105, the consistency score of the signal pair to be matched is determined based on bit width topological features, similarity, and compatibility score. This can be achieved through the following processing: the absolute difference pairs are calculated based on the relative bit width sorting of the interface signals in the signal pair to be matched, and the calculation results are normalized to obtain the normalized difference score; the normalized difference score, similarity score, and compatibility score are weighted and summed to obtain the consistency score.

[0145] The electronic device first obtains the relative bit-width order of the two interface signals in the signal pair to be matched. The relative bit-width order refers to the position of the interface signal's bit-width within the bit-width sequence of all interface signals at the current level node. Next, the electronic device calculates the absolute difference between the relative bit-width orders of the two interface signals, and then normalizes the result, using the normalized difference score. Finally, the electronic device performs a weighted sum of the normalized difference score, similarity score, and compatibility score to obtain the consistency score.

[0146] It should be noted that the weighting of the normalized difference score, similarity score, and compatibility score can be set according to the actual situation. For example, the weight of the normalized difference score can be set to 0.7, the weight of the similarity score can be set to 0.1, and the weight of the compatibility score can be set to 0.2. This application embodiment does not limit this.

[0147] It is understood that in this embodiment of the application, the electronic device can determine the consistency score by combining features from three different dimensions simultaneously through a weighted summation method, thereby making the consistency score more accurate and thus making the judgment of connection matching relationship more accurate.

[0148] In some embodiments of this application, Figure 3 In step 105, determining the consistency score of the signal pair to be matched based on bit-width topological features, similarity, and compatibility scores can also be achieved through the following process: using a score prediction model, score prediction is performed based on bit-width topological features, similarity, and compatibility scores, and the output of the score prediction model is determined as the consistency score.

[0149] The score prediction model here can be a deep learning model, such as a large language model, or a shallow machine learning model, such as a random forest or support vector machine. The score prediction model can acquire score prediction ability through training. The training template can consist of a bit-width topological feature template, similarity samples and compatibility score samples, and labels representing whether there are real connection matching relationships among these samples.

[0150] Step 106: Based on the connection matching relationship, generate the first connection code for connecting the interface signals in the signal pairs to be matched.

[0151] The electronic device iterates through all signal pairs that have been confirmed to have a connection match. For each signal pair, it generates connection code for the interface signals it contains based on the connection match relationship, thus obtaining the first connection code. Here, the first connection code refers to the generated source code segment that conforms to the syntax specifications of a specific hardware description language. The function of this code segment is to electrically or logically turn on the interface signals with the confirmed connection match relationship.

[0152] In some embodiments, for standard, same-level, and consistent connection matching relationships, the electronic device employs a direct connection strategy for the two interface signals in the corresponding signal pair to be matched. That is, the electronic device first distinguishes the source interface signal and the target interface signal in the signal pair to be matched based on the connection matching relationship, then calls a preset syntax template and fills in the names of the source and target interface signals to obtain the first connection code. For example, if the name of the source interface signal in the signal pair to be matched is u_src_data, the name of the target interface signal is u_tgt_data, and the called syntax template is the Verilog template: assign {target}={source}, then the electronic device will fill in these two names into the syntax template to obtain the first connection code such as assign u_tgt_data=u_src_data.

[0153] In other embodiments, the electronic device will also check the specific attributes of the interface signals in the signal pairs to be matched corresponding to each connection matching relationship to determine whether any special cases have been encountered. If a special case is encountered, the corresponding processing flow will be entered.

[0154] See Figure 5 , Figure 5 This is a flowchart illustrating the link code generation method provided in the embodiments of this application. Figure 3 In some embodiments of this application, Figure 3 Step 106, which involves generating the first connection code to connect the interface signals in the signal pairs to be matched based on the connection matching relationship, can be achieved through the following processing:

[0155] Step 1061: Compare the bit widths of the interface signals in the signal pairs to be matched to obtain the comparison results.

[0156] The electronic device acquires the bit widths of the two interface signals in the signal pair to be matched, compares the bit widths of the two interface signals, and obtains the comparison result. Thus, the comparison result can characterize whether the bit widths of the two interface signals are consistent.

[0157] Step 1062: When the comparison result indicates that the bit widths of the interface signals in the signal pair to be matched are inconsistent, determine the bit width conversion logic of the signal pair to be matched based on the connection matching relationship.

[0158] When the comparison result indicates that the bit widths of the two interface signals in the signal pair to be matched are different, it means that the two interface signals cannot be directly connected physically. Therefore, the electronic device will continue to obtain the connection matching relationship of the signal pair to be matched, and determine the appropriate bit width conversion logic for the two interface signals based on the connection matching relationship, so that the two interface signals can be connected normally through the bit width conversion logic in the future.

[0159] It should be noted that the bit width conversion logic is a processing rule introduced to solve the problem of bit width mismatch between the source interface signal and the target interface signal. This processing rule defines how to map the source interface signal to the bit width space of the target interface signal.

[0160] In some embodiments of this application, Figure 5 The bit width conversion logic for determining the signal pair to be matched based on the connection matching relationship in step 1062 can be implemented through the following processing: Based on the connection matching relationship, the source interface signal and the target interface signal are determined from the signal pair to be matched; when the bit width of the source interface signal is greater than the bit width of the target interface signal, the bit width conversion logic is determined to truncate the low-order signal of the source interface signal according to the bit width of the target interface signal; when the bit width of the source interface signal is less than the bit width of the target interface signal, the bit width conversion logic is determined to align the bit width of the source interface signal with the bit width of the target interface signal by padding the high-order bits with zeros.

[0161] When the driver or data provider of two interface signals is clearly identified in the connection matching relationship, the electronic device will directly use the interface signal that drives the other interface signal or provides data as the source interface signal, and the remaining interface signal as the target interface signal. When the driver or data provider of two interface signals is not clearly identified in the connection matching relationship (in this case, the connection matching relationship only specifies which two interface signals need to be connected), the electronic device also needs to determine the data flow direction based on the direction of these two interface signals, and determine the source interface signal and the target interface signal based on the data flow direction.

[0162] When the bit width of the source interface signal is greater than the bit width of the target interface signal, the electronic device will truncate the lowest N bits of the source interface signal (N is the bit width of the target interface signal) and discard the higher-order bits as the bit width conversion logic. Conversely, when the bit width of the source interface signal is less than the bit width of the target interface signal, the electronic device will pad the higher-order bits of the source interface signal with K zeros (K is the difference between the bit widths of the target and source interfaces), while keeping the lower-order bits unchanged, as the bit width conversion logic. In this way, physical bit width alignment can be achieved.

[0163] For example, if the source interface signal cpu_addr has a bit width of 32 bits and the target interface signal peri_addr has a bit width of 16 bits, the electronic device will truncate bits [15:0] of cpu_addr as the bit width conversion logic. If the source interface signal ctrl_mode has a bit width of 8 bits and the target interface signal status_reg has a bit width of 32 bits, then the electronic device will append 24 zeros to the high bits of ctrl_mode as the bit width processing logic.

[0164] It is understood that in the embodiments of this application, the electronic device can determine the bit width conversion logic by automatically intercepting the low-bit signal or padding the high-bit with zeros, so that when the bit widths of the two interface signals in the signal pair to be matched do not match, the bit widths of the two interface signals can be automatically adapted, thereby improving the generation efficiency of the first connection code.

[0165] In other embodiments of this application, Figure 5 The step 1062 in the process of determining the bit width conversion logic of the signal pair to be matched based on the connection matching relationship can also be implemented by the following process: querying the rule entry corresponding to the signal pair to be matched from the preset connection rule file; and determining the operation method defined by the rule entry as the bit width conversion logic of the signal pair to be matched.

[0166] The preset connection rule file here is provided by the user to define specific interface signals or processing rules for special cases of interface signals. For example, for a signal named "addr," if the bit width is insufficient, the high-bit padding logic is preferentially used. The electronic device indexes the names of the two interface signals in the signal pair to be matched in the preset connection rule file to determine the rule entries, such as cyclic padding, sign bit extension, or constant padding. The operation methods defined by these rule entries are used as the bit width conversion rules.

[0167] Step 1063: Generate the first connection code based on the bit width conversion logic.

[0168] After obtaining the bit-width conversion logic, the electronic device combines the bit-width conversion logic with the syntax of the target hardware description language (such as Verilog) to construct a valid expression or statement, which serves as the first linker code.

[0169] In some embodiments, the bit-width conversion logic truncates the low-order signals. The electronic device can select a bit selection statement from the target hardware description language and embed the bit selection statement and the name of the interface signal into a syntax template to construct the first connection code. For example, if the bit-width conversion logic truncates the low N-bit signals, the electronic device can use the Verilog bit selection statement [N-1:0] and embed it along with the name into assign {target}={source} to obtain, for example, assign target_signal=source_signal[N-1:0].

[0170] In other embodiments, the bit-width conversion logic pads the high-order bits with zeros. The electronic device can select a concatenation statement of the target hardware description language and embed the concatenation statement and the name of the interface signal together into a syntax template to construct the first connection code. For example, if the bit-width conversion logic pads the high-order bits with S zeros, the electronic device can use the Verilog concatenation statement {{K{1'b0}},signal} and embed it along with the name into assign {target}={source} to obtain, for example, assign target_signal={{16{1'b0}},source_signal}.

[0171] It is understood that in the embodiments of this application, the electronic device can automatically compare the bit width of the interface signal and determine the bit width conversion logic, and automatically generate the corresponding first connection code according to the bit width conversion logic. This enables automatic adaptation when the bit width of the interface signal is inconsistent, thereby eliminating the need for designers to manually encode the code and improving the generation efficiency of the first connection code.

[0172] It should be noted that when the two interface signals in the signal pair to be matched reside in different hardware modules, the electronic device also needs to perform cross-layer connection for these two interface signals.

[0173] In some embodiments of this application, Figure 3 Step 106, which is to generate the first connection code for connecting the interface signals in the signal pair to be matched based on the connection matching relationship, can also be implemented through the following processing: based on the connection matching relationship, determine the source interface signal and the target interface signal from the signal pair to be matched; based on the signal tree, determine the hierarchical path from the source interface signal to the target interface signal; when the hierarchical path crosses at least one intermediate hardware module, add a relay port for transmitting signals in the intermediate hardware module, and generate code for cascading the source interface signal, the relay port and the target interface signal as the first connection code.

[0174] An intermediate hardware module refers to a hardware module located between the hardware module to which the source interface signal belongs and the hardware module to which the target interface signal belongs, preventing a direct physical connection between the two. This hardware module is typically a parent or grandparent module of one of these two hardware modules. For example, if hardware module A contains hardware module B, and hardware module B contains interface signal S, then hardware module A is the intermediate hardware module if it is to extend interface signal S to the outside of hardware module A.

[0175] A repeater port is an input or output interface added to an intermediate hardware module. This interface is used to pass signals through, enabling signal transmission across layers. A repeater port can be understood as a "hole" in the intermediate hardware module that allows signals to flow through.

[0176] In this embodiment, the electronic device traverses the signal tree to find the unique path between the source interface signal and the target interface signal based on the tree structure.

[0177] In some embodiments, the electronic device can start from the hierarchical node where the source interface signal is located, trace back upwards along the parent pointer, and record the first list of nodes traversed. Similarly, it can start from the target interface signal and trace back upwards, recording the second list of nodes. Then, it compares the first list of nodes and the second list of nodes to determine the first common hierarchical node encountered by the source interface signal and the target interface signal, which is taken as the common ancestor of the source interface signal and the target interface signal. Afterwards, the electronic device records the path from the source interface signal to the common ancestor and the path from the common ancestor to the target interface signal, and merges these two paths to obtain the hierarchical path.

[0178] In other embodiments, the electronic device acquires the names of the source interface signal and the target interface signal, segments and compares these two names to determine the longest common prefix. The hierarchical node corresponding to this common prefix is ​​the common ancestor. Then, the electronic device records the path from the source interface signal to the common ancestor and the path from the common ancestor to the target interface signal, and merges these two paths to obtain the hierarchical path.

[0179] After determining the hierarchical path, the electronic device traverses each intermediate hardware module along the path. For intermediate hardware modules on the path from the source interface signal to the common ancestor, a relay port with the direction of output is added. For intermediate hardware modules on the path from the common ancestor to the target interface signal, a relay port with the direction of input is added. Then, the electronic device can generate code that concatenates these source interface signals, relay ports, and target interface signals according to the syntax template of the target description language. This code is the first connection code.

[0180] For example, if the source interface signal is located in the hardware module System.CPU.Core and the target interface signal is located in the hardware module System, the hierarchical path determined by the signal tree is: Core -> (upward) -> CPU -> (upward) -> System, thus the intermediate hardware module is CPU. In the CPU hardware module, the electronic device automatically adds a relay port, output wirecore_status_relay, and generates internal connection code to connect the Core's core_status output port to this newly added core_status_relay. In the System hardware module, when the electronic device instantiates the CPU hardware module, it accesses its new port core_status_relay and generates connection code assign led_out = cpu_inst.core_status_relay. This achieves signal pass-through from the bottom-level Core to the top-level System by creating a "hole" in the intermediate CPU module.

[0181] It should be noted that the process of determining the source interface signal and the target interface signal based on the connection matching relationship is similar to the process of determining the source interface signal and the target interface signal based on the connection matching relationship described above, and will not be repeated here.

[0182] It is understood that in this embodiment of the application, the electronic device can automatically complete cross-layer connection by automatically adding a relay port in the intermediate hardware module and automatically generating cascading code, thereby eliminating the need for designers to manually modify the code layer by layer and improving the generation efficiency of the first connection code.

[0183] This completes the generation of the first connection code.

[0184] Understandably, compared to related technologies, there is a problem with low accuracy in generating connection codes for interface signals. In this embodiment, the electronic device first converts the multi-source heterogeneous files corresponding to multiple hardware modules into standardized unified interface models in memory, so that multi-source heterogeneous text can be represented in memory in a unified format. Then, the unified interface model of each hardware module is further reconstructed into a signal tree containing parent-child relationships, so as to include relevant information on the logical structure of the interface signals while shielding the underlying syntax differences. Based on the signal tree, potential matching signal pairs with connection possibilities are determined from the interface signals of different hardware modules. For the interface signals in the matching signal pairs, multi-dimensional evaluation indicators including name similarity, direction compatibility, and bit width topology features are extracted. Based on the multi-dimensional evaluation indicators, the consistency score of the two interface signals is accurately calculated. Thus, based on the consistency score, it can be accurately determined whether the two interface signals in the matching signal pairs have a connection matching relationship. Based on the connection matching relationship, the first connection code is generated for the two interface signals that really need to be connected, thereby improving the accuracy of the connection code generation for interface signals.

[0185] In some embodiments of this application, in Figure 3 After step 102 and before step 106, that is, after constructing a hierarchical signal tree for each hardware module based on each unified interface model, and before generating the first connection code for connecting the interface signals in the signal pairs to be matched based on the connection matching relationship, the method further includes the following processing: parsing the connection instructions from the preset connection rule file; extracting the signal pairs to be matched specified by the connection instructions from the interface signals of multiple hardware modules; and establishing connection matching relationships for the interface signals in the signal pairs to be matched.

[0186] It should be noted that the preset connection rule file refers to an external configuration file containing a series of connection instructions, which is generated by the user. Connection instructions are operation commands that instruct the system to forcibly bind specific source interface signals to specific target interface signals. Connection instructions have a higher execution priority than automated algorithms, and they express the connection intent determined by the designer.

[0187] In this embodiment, the electronic device first reads the connection rule file stored on the disk through a file input / output (I / O) interface and calls the corresponding parser to convert the text stream in the connection rule file into operable instructions in memory, which are the connection instructions. Next, the electronic device searches in the signal tree of the hardware module containing the source interface signal based on the source path string in the connection instruction, and searches in the signal tree of the hardware module containing the target interface signal based on the target path string in the connection instruction, to determine the two interface signals specified by the connection instruction. Then, the electronic device constructs these two interface signals into a pair to be matched and directly determines that a connection matching relationship exists between the two interface signals. Thus, this method can be used to determine the connection matching relationship for any interface signal, such as those for which it is difficult to determine whether a potential connection relationship exists.

[0188] For example, a user writes a connection rule file named design_rules.cfg with the following content: FORCE_CONNECT:Analog_IP.v_sense_p->Dig_Ctrl.adc_in_0. The electronic device retrieves this file, parses the connection instructions, determines the source path string Analog_IP.v_sense_p and the target path string Dig_Ctrl.adc_in_0, then finds the interface signal v_sense_p in the Analog_IP signal tree and the interface signal adc_in_0 in the Dig_Ctrl signal tree, and combines the two into a signal pair to be matched, while establishing a connection matching relationship. In this way, the first connection code containing .adc_in_0 (v_sense_p) can be generated subsequently to reflect the user's design intent.

[0189] It is understood that, in this embodiment of the application, by introducing a preset connection rule file, a rule for manual intervention is opened in addition to the fully automated interface signal matching mechanism. This enables designers to manage the process of connection code generation, thereby further improving the accuracy of connection code generation.

[0190] In some embodiments of this application, in Figure 3After determining the consistency score of the signal pair to be matched based on bit-width topological features, similarity, and compatibility score in step 105, and before step 106, i.e. before generating the first connection code for connecting the interface signals in the signal pair to be matched based on the connection matching relationship, the method may further include the following processing: when the consistency score is less than or equal to the score threshold, determining whether the directions of the interface signals in the signal pair to be matched are complementary, and whether the bit widths of the interface signals in the signal pair to be matched are equal; when the directions are complementary and the bit widths are equal, establishing a connection matching relationship for the interface signals in the signal pair to be matched.

[0191] In other words, when an electronic device determines that the consistency score is less than or equal to the score threshold, it does not directly conclude that there is no connection matching relationship between the interface signals in the signal pair to be matched. Instead, it first compares whether the directions of the two interface signals are complementary and whether the bit widths of the two interface signals are equal. When the directions of the two interface signals are complementary and the bit widths are equal, the electronic device will first establish a connection matching relationship between the two interface signals so that it can attempt to connect the two interface signals in the future.

[0192] For example, if the name of two interface signals 1 is mod_a.out_port_0, the direction is Output, and the bit width is 64, and the name of interface signal 2 is mod_b.data_in_high, the direction is Input, and the bit width is 64, the consistency score is only 0.4 due to the low name similarity, which is less than the threshold of 0.6. In this case, the electronic device will check the direction and bit width of the two interface signals and find that the directions are complementary and the bit widths are relative. Therefore, it will try to establish a connection matching relationship between the two interface signals to facilitate subsequent trial connection.

[0193] It is understood that, in the embodiments of this application, for a pair of signals to be matched with a low consistency score, the electronic device can determine whether the two interface signals have a connection matching relationship simply by whether the directions are complementary and whether the bit widths are equal. This enables the relaxation of conditions for potential signal pairs whose corresponding names do not match semantically but are physically compatible, thereby reducing missed connections and improving the accuracy of connection code generation.

[0194] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0195] This application embodiment is implemented in the intelligent connection scenario of hardware module interfaces (referred to as interface signals). In this application embodiment, source code or rules describing hardware module interfaces from different sources (referred to as multi-source heterogeneous source files) are first converted into a unified, semantically rich internal data model; then, in a connection engine with understanding capabilities, these models are compared, analyzed, and reasoned; finally, based on the reasoning results and user-defined strategies, correct, low-level connection code (referred to as first connection code) is automatically generated.

[0196] Figure 6 This is a system framework diagram of the smart connection provided in the embodiments of this application. See also... Figure 6 The system framework diagram includes the following core processing units and data flows: SpinalHDL native files 6-1, SV / Verilog files 6-2, user-defined Tcl files 6-3, SV / Verilog conversion 6-4, DSL conversion 6-5, SpinalHDL automated linker library 6-6, top-level module generation 6-7, and code generation 6-8.

[0197] Among them, SpinalHDL native file 6-1 directly contains source files for the high-level hardware abstraction description.

[0198] SV / Verilog file 6-2 is a register transfer level (RTL) design file written using standard Verilog or SystemVerilog.

[0199] User-defined Tcl files 6-3 (called preset connection rule files), i.e., user-defined format files / Tcl files with extended language features: files containing user-defined rules or domain-specific language (DSL) scripts to guide automated connections.

[0200] SV / Verilog Conversion 6-4 involves processing the input SV / Verilog file using a dedicated SV / Verilog parser. This includes: syntax parsing: recognizing module definitions; interface extraction: extracting the input, output, and inout port declarations of the hardware module, including signal names, directions, and bit width information; and generating an intermediate representation (called a unified interface module): based on the extracted information, creating a functionally equivalent module interface representation in memory. This representation does not directly generate SpinalHDL source code, but rather constructs a data model in memory that is isomorphic to the SpinalHDL component interface (i.e., a Bundle structure containing the same signal names, directions, and bit widths). This allows the SV / Verilog module to be recognized and manipulated in the SpinalHDL design environment in a "black box" manner.

[0201] DSL Conversion 6-5 refers to the processing of input user-defined format files or Tcl files by a custom DSL parsing engine. This process includes: parsing smart connectors: the engine reads and parses the connection instructions defined in the file. These connection instructions are connection intentions written by the user in declarative syntax, such as connect-from. master.data-to slave.data_in or check_similarity if1 if2; Interpret connection relationships: Understand the connection relationships expressed by these connection instructions (i.e., signal A should be connected to signal B, or interfaces C and D should undergo similarity checks); Convert to connection library calls: The engine converts the parsed connection relationships into a series of call commands and parameters for specific functions in the SpinalHDL automated connection library. This step does not directly generate SpinalHDL source code, but rather generates a connection plan (called connection matching relationship) that can be executed by the connection library.

[0202] SpinalHDL Automated Connectivity Library 6-6, the core of intelligent connectivity, provides the following key capabilities: Intelligent Bit Width Handling 6-61: When connecting two logically corresponding signals but with different physical bit widths, the library can automatically insert adaptation logic. For example, when connecting a 32-bit master signal to a 16-bit slave signal, it automatically generates truncation logic to take the lower 16 bits; otherwise, it performs zero-padding expansion. Here, when connecting from a smaller bit width to a larger bit width, zero-padding is used by default for expansion. For high-level data loss caused by truncation, the system will generate a warning message, which the designer must confirm to see if it meets expectations; Cross-level signal retrieval 6-62: When it is necessary to connect the internal signals of deep submodules to the top level or other modules at the same level, the library can automatically generate the necessary relay logic path between the original level and the target level of the signal, thereby logically realizing the signal retrieval without manually modifying the module port; Structural consistency check 6-63: Perform multi-dimensional similarity analysis on two interfaces (Bundles) to be connected, including signal name similarity (based on the comparison of edit distance and semantic rules), direction compatibility, and bit width topological equivalence (analyzing whether the relative roles of the signals in their respective interface structures are consistent); Intelligent handling of unmatched signals 6-64: For signals that cannot be automatically matched after checking, the library will handle them according to preset or user-defined strategies, such as generating a report, attempting heuristic matching, or ignoring them.

[0203] Top-level module generation 6-7: Input the SpinalHDL file, the SV / Verilog module interface model generated above, and the obtained connection relationships into the automatic connection top-level module generator. This generator is used to: instantiate all modules; automatically generate all connection statements between modules (including direct connections and connections through bit-width adaptation) based on the verified connection relationships; and output a complete SpinalHDL module description file named SpinalHDL Automatic Connection Top-Level (Top.scala).

[0204] Code generation steps 6-8 involve automatically linking the generated SpinalHDL top-level file and feeding it into a standard SpinalHDL compiler and Verilog / SystemVerilog code generator. The final output is fully synthesizable, automatically integrated Verilog or SystemVerilog RTL code.

[0205] Figure 7 This is a schematic diagram of the automated connection process provided in an embodiment of this application. See also... Figure 7 The automated process includes: acquiring DSL input files 7-1, signal type determination 7-2, intelligent bundle matching 7-3, intelligent BaseType signal matching 7-4, connecting matched signals 7-5, connecting unmatched nodes 7-6, and other post-processing steps 7-7. Specifically, intelligent bundle matching 7-3 includes: constructing the signal tree structure 7-31, i.e., the SignalTree, and checking the consistency of the bundle signal tree structure 7-32.

[0206] The following two examples illustrate the automated connection process.

[0207] Example 1: Connect a 32-bit AXI master device written in Verilog to a 16-bit AXI slave device controller written in SpinalHDL;

[0208] Input files: axi_master.v: AXI master module in Verilog format; slave_adapter.tcl: DSL rule file;

[0209] Connection steps:

[0210] 1) Convert Verilog: Read axi_master.v, the parser extracts its AXI main interface signals (such as awaddr[31:0], wdata[31:0]), and creates the interface model M_AXI in memory;

[0211] 2) Parse the DSL and application connection library: Read in slave_adapter.tcl, assuming one of the rules is: check_and_connect top.M_AXI The DSL engine interprets top.S_AXI with a threshold of 85 as: performing a structural consistency check (similarity threshold of 85%) on interfaces M_AXI and S_AXI, and automatically connecting matching signals;

[0212] 3) Structural Consistency Check (Core Function of the Link Library): Signal Naming Similarity Analysis: Calculate the similarity between M_AXI.awaddr and S_AXI.axi_awaddr. Here, by removing prefixes / suffixes and matching the core word "addr", a high degree of similarity is determined. Bit Width Topology (called bit width topology feature) Equivalence Determination: In both interfaces, awaddr and axi_awaddr are the signals with the largest bit width in their respective write address channels, i.e., they are role equivalent (both are main address lines). Therefore, they are determined to be bit width topologically equivalent, meaning that the two signals occupy the same logical position and role in their respective interface tree structure (called the signal tree), rather than having equal numerical values. Comprehensive Score: Weighted calculation is performed on multiple dimensions such as naming, type, and bit width topology to obtain a total score of 92% (called the consistency score).

[0213] 4) Intelligent connection execution: Since the total score passes the threshold (called the score threshold) and the bit width difference is identified, bit width truncation logic (called bit width conversion logic) is generated: S_AXI.axi_awaddr:=M_AXI.awaddr(15 downto 0). This logic directly takes the lower 16 bits of the source signal (called the source interface signal), and the high bits [31:16] are discarded in this connection path;

[0214] 5) Integrate all modules and the above connection logic, and finally the compiler outputs the integrated Verilog code.

[0215] Example 2: Using DSL to quickly define a specific connection relationship from SPI to I2C

[0216] DSL rule file content:

[0217] # Parse custom smart connectors

[0218] force_connect spi.sck-> i2c.scl

[0219] smart_connect spi.mosi spi.miso-> i2c.sda with strategy guess.

[0220] Processing flow:

[0221] 1) Obtain the Verilog file (.v) for the SPI module and the SpinalHDL file (.scala) for the I2C module, as well as the aforementioned DSL file (.tcl);

[0222] 2) The DSL engine parses two rules: one is to force a connection from SCK to SCL; and the other is to intelligently connect MOSI and MISO to SDA.

[0223] 3) For the two BaseType signals sck and scl, the connection is established directly according to the BaseType signal intelligent connection process.

[0224] 4) For SPI interface bundles containing MOSI and MISO and I2C interface bundles containing SDA, process them according to the bundle smart connection procedure, i.e., perform the following processing:

[0225] Constructing a SignalTree: Converting the interface structures of SPI and I2C into tree-like data structures for systematic analysis; here, constructing a signal tree is to map the hierarchical hardware interfaces into an object model that can be recursively traversed and precisely compared.

[0226] Structural consistency check: The two signal trees are compared. Due to different protocols, the similarity score between mosi / miso and sda is very low.

[0227] Connect all matching nodes: In this example, only the forced-connect sck-scl pairs match.

[0228] Unmatched connection signal: According to the "with strategy guess" strategy in DSL, a heuristic connection was attempted (such as guessing based on the signal direction), but it was abandoned due to low confidence and was selected as an unmatched signal;

[0229] Post-processing: Generate a report indicating unsuccessfully matched signal pairs.

[0230] It is understood that in the embodiments of this application, user information, such as rule files and other related data, is involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0231] The following description continues to illustrate the exemplary structure of the link code generation device 255 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software module in the link code generation device 255 stored in the memory 250 may include:

[0232] The model determination module 2551 is used to determine multiple unified interface models in memory for multiple heterogeneous source files corresponding to multiple hardware modules, wherein the unified interface model includes the name, direction and bit width of the interface signals of the hardware module;

[0233] The signal tree construction module 2552 is used to construct a hierarchical signal tree for each hardware module based on each unified interface model, wherein the signal tree contains multiple hierarchical nodes with parent-child relationships, and each hierarchical node contains at least one interface signal of the hardware module.

[0234] The signal pair processing module 2553 is used to determine a signal pair to be matched from the interface signals of the multiple hardware modules based on multiple signal trees, and to determine the bit width topology features of the interface signals in the signal pair to be matched based on the bit width.

[0235] The index calculation module 2554 is used to calculate the similarity between the names of the interface signals in the signal pair to be matched, and to determine the compatibility score of the orientation of the interface signals in the signal pair to be matched.

[0236] The relationship determination module 2555 is used to determine the consistency score of the signal pair to be matched based on the bit width topological features, the similarity and the compatibility score, and to determine that there is a connection matching relationship between the signal pair to be matched when the consistency score is greater than the score threshold.

[0237] The code generation module 2556 is used to generate a first connection code for connecting the interface signals in the signal pair to be matched, based on the connection matching relationship.

[0238] In the above scheme, the code generation module 2556 is further configured to compare the bit widths of the interface signals in the signal pair to be matched to obtain a comparison result; when the comparison result indicates that the bit widths of the interface signals in the signal pair to be matched are inconsistent, the bit width conversion logic of the signal pair to be matched is determined based on the connection matching relationship; and the first connection code is generated based on the bit width conversion logic.

[0239] In the above scheme, the code generation module 2556 is further configured to determine the source interface signal and the target interface signal from the signal pair to be matched based on the connection matching relationship; when the bit width of the source interface signal is greater than the bit width of the target interface signal, the bit width conversion logic is determined to truncate the low-order signal of the source interface signal according to the bit width of the target interface signal; when the bit width of the source interface signal is less than the bit width of the target interface signal, the bit width conversion logic is determined to align the bit width of the source interface signal with the bit width of the target interface signal by padding the high-order bits with zeros.

[0240] In the above scheme, the code generation module 2556 is further configured to determine the source interface signal and the target interface signal from the signal pair to be matched based on the connection matching relationship; determine the hierarchical path from the source interface signal to the target interface signal based on the signal tree; when the hierarchical path crosses at least one intermediate hardware module, add a relay port for transmitting signals in the intermediate hardware module, and generate code for cascading the source interface signal, the relay port and the target interface signal as the first connection code.

[0241] In the above scheme, the relationship determination module 2555 is further configured to parse a connection instruction from a preset connection rule file; extract the pair of signals to be matched specified by the connection instruction from the interface signals of the multiple hardware modules; and establish the connection matching relationship for the interface signals in the pair of signals to be matched.

[0242] In the above scheme, the model determination module 2551 is further configured to parse the multi-source heterogeneous source files respectively to obtain module definitions of multiple hardware modules; extract the port declaration of the interface signal of each hardware module from the module definition of each hardware module, and extract the name, direction and bit width of the interface signal from the port declaration; create a structured signal set corresponding to the interface structure of the hardware module in the memory, and encapsulate the name, direction and bit width into the structured signal set, and determine the encapsulated structured signal set as the unified interface model.

[0243] In the above scheme, the index calculation module 2554 is further configured to remove the prefix and suffix of the name of the interface signal in the signal pair to be matched, to obtain two core words corresponding to the signal pair to be matched; calculate the edit distance between the two core words, and determine the semantic association between the two core words according to semantic rules; and calculate the similarity of the name of the interface signal in the signal pair to be matched based on the edit distance and the semantic association.

[0244] In the above scheme, the bit width topology features include: the relative bit width sorting of the interface signals; the relationship determination module 2555 is further used to calculate the absolute difference of the relative bit width sorting of the interface signals in the signal pair to be matched, and normalize the calculation result to obtain a normalized difference score; the normalized difference score, the similarity and the compatibility score are weighted and summed to obtain the consistency score.

[0245] In the above scheme, the relationship determination module 2555 is further configured to determine whether the directions of the interface signals in the signal pair to be matched are complementary and whether the bit widths of the interface signals in the signal pair to be matched are equal when the consistency score is less than or equal to the score threshold; when the directions are complementary and the bit widths are equal, the connection matching relationship is established for the interface signals in the signal pair to be matched.

[0246] In the above scheme, the signal pair processing module 2553 is further configured to determine the level depth of the level node in each of the signal trees; for the first interface signal in the first signal tree among the multiple signal trees, search in the second signal tree for a second interface signal whose difference from the level depth of the level node where the first interface signal is located is less than a level threshold, and determine the first interface signal and the second interface signal as the signal pair to be matched; wherein, the second signal tree is a signal tree other than the first signal tree among the multiple signal trees.

[0247] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the link code generation method described above in this application.

[0248] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the linking code generation method provided in this application. For example, ... Figure 3 The method for generating the connection code is shown.

[0249] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0250] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0251] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0252] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0253] In summary, through the embodiments of this application, multi-source heterogeneous files corresponding to multiple hardware modules are converted into standardized unified interface models in memory, enabling multi-source heterogeneous text to be represented in memory in a unified format. Then, the unified interface model of each hardware module is further reconstructed into a signal tree containing parent-child relationships, which, while masking underlying syntactic differences, includes relevant information about the logical structure of the interface signals. Based on the signal tree, potential matching signal pairs with connection possibilities are identified from the interface signals of different hardware modules. Multi-dimensional evaluation indicators, including name similarity, direction compatibility, and bit-width topological features, are extracted from the interface signals in the matching signal pairs. The consistency score of the two interface signals is accurately calculated based on these multi-dimensional evaluation indicators, thereby accurately determining whether the two interface signals in the matching signal pair have a connection matching relationship. Based on the connection matching relationship, the first connection code is generated for the two interface signals that truly need to be connected, thus improving the accuracy of the connection code generation for the interface signals.

[0254] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for generating connection code, characterized in that, The method includes: For multiple heterogeneous source files corresponding to multiple hardware modules, multiple unified interface models are determined in memory, wherein the unified interface model includes the name, direction and bit width of the interface signals of the hardware module; Based on each of the unified interface models, a hierarchical signal tree is constructed for each of the hardware modules, wherein the signal tree contains multiple hierarchical nodes with parent-child relationships, and each hierarchical node contains at least one interface signal of the hardware module; Based on multiple signal trees, a pair of signals to be matched is determined from the interface signals of multiple hardware modules, and based on the bit width, the bit width topology features of the interface signals in the pair of signals to be matched are determined, wherein the bit width topology features include: the relative bit width order of the interface signals; Calculate the similarity between the names of the interface signals in the signal pair to be matched, and determine the compatibility score of the orientation of the interface signals in the signal pair to be matched; Based on the bit-width topological features, the similarity, and the compatibility score, the consistency score of the signal pair to be matched is determined, and when the consistency score is greater than the score threshold, a connection matching relationship is determined to exist between the signal pairs to be matched. Based on the connection matching relationship, a first connection code is generated to connect the interface signals in the signal pair to be matched.

2. The method according to claim 1, characterized in that, The step of generating first connection code based on the connection matching relationship to connect the interface signals in the signal pair to be matched includes: The bit widths of the interface signals in the signal pair to be matched are compared to obtain a comparison result; When the comparison result indicates that the bit widths of the interface signals in the signal pair to be matched are inconsistent, the bit width conversion logic of the signal pair to be matched is determined based on the connection matching relationship. Based on the bit-width conversion logic, the first connection code is generated.

3. The method according to claim 2, characterized in that, The bit-width conversion logic for determining the signal pair to be matched based on the connection matching relationship includes: Based on the connection matching relationship, the source interface signal and the target interface signal are determined from the signal pairs to be matched; When the bit width of the source interface signal is greater than the bit width of the target interface signal, the bit width conversion logic is determined to truncate the low-order bit signal of the source interface signal according to the bit width of the target interface signal; When the bit width of the source interface signal is smaller than the bit width of the target interface signal, the bit width conversion logic is determined to align the bit width of the source interface signal with the bit width of the target interface signal by padding the high bits with zeros.

4. The method according to any one of claims 1 to 3, characterized in that, The step of generating first connection code based on the connection matching relationship to connect the interface signals in the signal pair to be matched includes: Based on the connection matching relationship, the source interface signal and the target interface signal are determined from the signal pairs to be matched; Based on the signal tree, determine the hierarchical path from the source interface signal to the target interface signal; When the hierarchical path crosses at least one intermediate hardware module, a relay port for transmitting signals is added to the intermediate hardware module, and code for cascading the source interface signal, the relay port, and the target interface signal is generated as the first connection code.

5. The method according to any one of claims 1 to 3, characterized in that, After constructing a hierarchical signal tree for each hardware module based on each unified interface model, and before generating first connection code for connecting the interface signals in the signal pairs to be matched based on the connection matching relationship, the method further includes: The connection instructions are parsed from the preset connection rule file; Extract the pair of signals to be matched specified by the connection instruction from the interface signals of the multiple hardware modules; The connection matching relationship is established for the interface signals in the signal pair to be matched.

6. The method according to any one of claims 1 to 3, characterized in that, The determination of multiple unified interface models in memory for the multi-source heterogeneous source files corresponding to multiple hardware modules includes: The multi-source heterogeneous source files are parsed to obtain the module definitions of multiple hardware modules; From the module definition of each hardware module, extract the port declaration of the interface signal of each hardware module, and extract the name, direction and bit width of the interface signal from the port declaration; A structured signal set corresponding to the interface structure of the hardware module is created in the memory, and the name, direction and bit width are encapsulated into the structured signal set. The encapsulated structured signal set is then determined as the unified interface model.

7. The method according to any one of claims 1 to 3, characterized in that, The calculation of the similarity between the names of the interface signals in the signal pair to be matched includes: For the name of the interface signal in the signal pair to be matched, remove the prefix and suffix to obtain two core words corresponding to the signal pair to be matched; Calculate the edit distance between the two core words, and determine the semantic association between the two core words according to semantic rules; Based on the edit distance and the semantic association, the similarity of the names of the interface signals in the signal pair to be matched is calculated.

8. The method according to any one of claims 1 to 3, characterized in that, The determination of the consistency score of the signal pair to be matched based on the bit-width topological features, the similarity, and the compatibility score includes: The absolute difference is calculated for the relative bit width sorting of the interface signals in the signal pair to be matched, and the calculation result is normalized to obtain the normalized difference score. The consistency score is obtained by weighted summation of the normalized difference score, the similarity score, and the compatibility score.

9. The method according to any one of claims 1 to 3, characterized in that, After determining the consistency score of the signal pair to be matched based on the bit-width topological features, the similarity, and the compatibility score, and before generating the first connection code for connecting the interface signals in the signal pair to be matched based on the connection matching relationship, the method further includes: When the consistency score is less than or equal to the score threshold, it is determined whether the directions of the interface signals in the signal pair to be matched are complementary, and whether the bit widths of the interface signals in the signal pair to be matched are equal. When the directions are complementary and the bit widths are equal, the connection matching relationship is established for the interface signals in the signal pair to be matched.

10. The method according to any one of claims 1 to 3, characterized in that, The step of determining the signal pair to be matched from the interface signals of the multiple hardware modules based on multiple signal trees includes: Determine the level depth of each level node in the signal tree; For a first interface signal in a first signal tree among multiple signal trees, a second interface signal is searched in a second signal tree whose difference in level depth from the level node where the first interface signal is located is less than a level threshold, and the first interface signal and the second interface signal are determined as the signal pair to be matched; wherein, the second signal tree is a signal tree other than the first signal tree among multiple signal trees.

11. A device for generating connection codes, characterized in that, The device includes: The model determination module is used to determine multiple unified interface models in memory for multiple heterogeneous source files corresponding to multiple hardware modules, wherein the unified interface model includes the name, direction and bit width of the interface signals of the hardware module; A signal tree construction module is used to construct a hierarchical signal tree for each hardware module based on each unified interface model, wherein the signal tree contains multiple hierarchical nodes with parent-child relationships, and each hierarchical node contains at least one interface signal of the hardware module. A signal pair processing module is configured to determine a pair of signals to be matched from the interface signals of the multiple hardware modules based on multiple signal trees, and to determine the bit width topology features of the interface signals in the pair of signals to be matched based on the bit width, wherein the bit width topology features include: the relative bit width order of the interface signals; The index calculation module is used to calculate the similarity between the names of the interface signals in the signal pair to be matched, and to determine the compatibility score of the orientation of the interface signals in the signal pair to be matched. The relationship determination module is used to determine the consistency score of the signal pair to be matched based on the bit width topological features, the similarity and the compatibility score, and to determine that there is a connection matching relationship between the signal pair to be matched when the consistency score is greater than the score threshold. The code generation module is used to generate a first connection code for connecting the interface signals in the signal pair to be matched, based on the connection matching relationship.

12. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 10.

13. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method described in any one of claims 1 to 10.

14. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method according to any one of claims 1 to 10.

Images