Code processing method and device of integrated circuit, electronic equipment and storage medium

Abstract

The application provides a code processing method and device of an integrated circuit, electronic equipment and a storage medium. The method comprises: obtaining source code, wherein the source code contains parameter information of a sub-module in the integrated circuit, and the source code is register transfer level code; constructing a structured packaging unit tree based on the source code; performing packaging processing on the structured packaging unit tree according to a high-level hardware description language to obtain a structured object; instantiating the structured object to obtain a hardware description language module; and in response to receiving a connection instruction, performing code generation based on the connection instruction and the hardware description language module to obtain connection code, wherein the connection instruction comprises a connection relationship between the sub-modules in the integrated circuit, the connection code indicates a signal transmission path between the sub-modules in the integrated circuit, and the connection code is hardware description language code. Through the application, the efficiency of connecting the signal transmission path between the modules in the integrated circuit design can be improved.

Description

Technical Field

[0001] This application relates to electronic design automation technology, and more particularly to a code processing method, apparatus, electronic device, and storage medium for integrated circuits. Background Technology

[0002] Electronic Design Automation (EDA) is a technology that automates the design process of very large-scale integrated circuits (VLSI) and related electronic systems using computer-aided design (CAD) software. In the EDA flow of related technologies, module connections typically rely on manual writing of hardware description languages ​​(such as Verilog or System Verilog) or the generation assisted by specific tools. With the rapid increase in the scale of integrated circuit design, hardware construction frameworks based on high-level programming languages ​​are gradually becoming a new trend in the design field due to their high level of abstraction and development efficiency.

[0003] However, the current chip design ecosystem still retains a large amount of register-transfer-level (RTL) code. When RTL modules are integrated into high-level language environments for top-level interconnection, they are difficult to directly map to structured objects (such as bundles) in high-level languages. This means that designers must manually write a large amount of black-box encapsulation code to reconstruct the interface structure, which is tedious and repetitive. Secondly, RTL modules from different sources often have inconsistent naming styles, and automated tools struggle to intelligently match these naming differences. As a result, designers still need to write thousands of lines of assignment code for line-by-line connections at the top level, which is not only inefficient but also prone to introducing wiring errors, affecting the efficiency of integrated circuit design. Summary of the Invention

[0004] This application provides a code processing method, apparatus, electronic device, and storage medium for integrated circuits, which can improve the efficiency of signal transmission path connection between modules in integrated circuit design.

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

[0006] This application provides a code processing method for integrated circuits, the method comprising:

[0007] Obtain the source code, wherein the source code contains parameter information of sub-modules in the integrated circuit, and the source code is register transfer level code;

[0008] A structured encapsulation unit tree is constructed based on the source code, wherein the structured encapsulation unit tree includes a root node and child nodes, and the child nodes represent the sub-fields of the port name in the parameter information;

[0009] The structured encapsulation unit tree is encapsulated using a high-level hardware description language to obtain a structured object;

[0010] The structured object is instantiated to obtain a hardware description language module;

[0011] In response to receiving a connection instruction, code is generated based on the connection instruction and a hardware description language module to obtain connection code. The connection instruction includes the connection relationship between the sub-modules in the integrated circuit, the connection code indicates the signal transmission path between the sub-modules in the integrated circuit, and the connection code is hardware description language code.

[0012] This application provides an integrated circuit code processing apparatus, including:

[0013] A data acquisition module is used to acquire source code, wherein the source code contains parameter information of sub-modules in an integrated circuit, and the source code is register transfer level code;

[0014] A code encapsulation module is used to construct a structured encapsulation unit tree based on the source code, wherein the structured encapsulation unit tree includes a root node and child nodes, and the child nodes represent sub-fields of port names in the parameter information; the structured encapsulation unit tree is encapsulated according to a high-level hardware description language to obtain a structured object; the structured object is instantiated to obtain a hardware description language module;

[0015] A code generation module is used to generate connection code based on the received connection instruction and a hardware description language module in response to receiving a connection instruction. The connection instruction includes the connection relationship between the sub-modules in the integrated circuit, and the connection code indicates the signal transmission path between the sub-modules in the integrated circuit. The connection code is hardware description language code.

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

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

[0018] The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the code processing method for the integrated circuit provided in the embodiments of this application.

[0019] This application provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, implement the integrated circuit code processing method provided in this application.

[0020] 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 integrated circuit code processing method provided in this application.

[0021] The embodiments of this application have the following beneficial effects:

[0022] By parsing the subfields of port names in the source code and constructing a structured encapsulation unit tree, the originally discrete port names and other information at the register transfer level are transformed into a structured encapsulation unit tree with logical hierarchical relationships. This allows the underlying physical port information to be recognized and processed by computer programs in a structured form. By using a high-level hardware description language to encapsulate the structured encapsulation unit tree into structured objects, mapping specific physical ports to object attributes in the programming language, hardware interfaces can be processed by manipulating object attributes rather than directly manipulating physical signal lines, thus shielding the underlying physical details such as bit width and direction. By responding to connection commands and combining them with instantiated hardware description language modules, the user-defined connection relationships carried by the connection commands are automatically transformed into specific underlying hardware description language connection code. This replaces the process of manually writing a large number of signal assignment statements, reducing the amount of connection code to be written. The connection code is used to indicate the signal transmission path between sub-modules in the integrated circuit, and since the connection code is hardware description language code, it can be directly read by electronic design automation tools, improving the efficiency of integrated circuit design. Attached Figure Description

[0023] Figure 1 This is a schematic diagram illustrating the application mode of the integrated circuit code processing method provided in the embodiments of this application;

[0024] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0025] Figure 3 This is a first flowchart illustrating the code processing method for integrated circuits provided in this application embodiment;

[0026] Figure 4 This is a second flowchart illustrating the code processing method for integrated circuits provided in this application embodiment;

[0027] Figure 5 This is a third flowchart illustrating the code processing method for integrated circuits provided in this application embodiment;

[0028] Figure 6 This is a schematic diagram of the structured encapsulation unit tree provided in the embodiments of this application;

[0029] Figure 7 This is a visual schematic diagram of the structured encapsulation unit tree provided in the embodiments of this application.

[0030] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0031] 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.

[0032] 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.

[0033] 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.

[0034] It should be noted that the data collection and processing in this application (e.g., user-edited or entered code 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.

[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 herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0037] 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.

[0038] 1) Electronic Design Automation (EDA) is a technology that uses computer-aided design (CAD) software to automate the design process of very large-scale integrated circuits (VLSI) and related electronic systems. EDA supports standardization and intelligentization of the design process, from circuit functional design, logic synthesis, simulation verification to layout. EDA is a fundamental tool for chip design. Simply put, EDA tools can manage billions of transistors on a single chip and enable them to work collaboratively, making it an indispensable key means of completing modern chip design and verification.

[0039] 2) Hardware Description Language (HDL): This is a class of specialized programming languages ​​for digital integrated circuits and system design. Verilog HDL is a hardware description language that describes the structure and behavior of digital system hardware in text form. It can be used to represent logic circuit diagrams, logic expressions, and the logical functions performed by digital logic systems.

[0040] 3) Register Transfer Level (RTL): In digital circuit design, RTL is an abstract model of synchronous digital circuits. This abstract model is determined by the flow of digital signals between logic units such as hardware registers, memories, combinational logic devices, and buses, and their logical algebraic operation. The RTL abstract model is used in hardware description languages ​​such as Verilog and VHDL to create high-level descriptions of actual circuits, from which low-level descriptions or even the actual circuits can be derived. Design at the RTL level is the most typical workflow in digital design. Logic synthesis tools can build lower-level circuit descriptions based on the RTL description.

[0041] 4) Register Transfer Level (RTL) code: refers to code written in hardware description languages ​​(such as Verilog, VHDL) or dedicated DSLs (such as Chisel), which are abstract units with registers as the core. It can clearly describe the transmission path, operation rules and timing triggering conditions of binary data between registers in a digital system.

[0042] 5) Lint tool: A static code analysis tool used to find errors, inconsistent style, and potential program problems in code. It helps improve code quality and maintainability.

[0043] Electronic Design Automation (EDA) is a technology that automates the design process of very large-scale integrated circuits (VLSI) and related electronic systems using computer-aided design (CAD) software. In the EDA flow of related technologies, module connections typically rely on manual writing of hardware description languages ​​(such as Verilog or System Verilog) or the generation assisted by specific tools. With the rapid increase in the scale of integrated circuit design, hardware construction frameworks based on high-level programming languages ​​are gradually becoming a new trend in the design field due to their high level of abstraction and development efficiency.

[0044] However, the current chip design ecosystem still retains a large amount of register-transfer-level (RTL) code. When RTL modules are integrated into high-level language environments for top-level interconnection, they are difficult to directly map to structured objects (such as bundles) in high-level languages. This means that designers must manually write a large amount of black-box encapsulation code to reconstruct the interface structure, which is tedious and repetitive. Secondly, RTL modules from different sources often have inconsistent naming styles, and automated tools struggle to intelligently match these naming differences. As a result, designers still need to write thousands of lines of assignment code for line-by-line connections at the top level, which is not only inefficient but also prone to introducing wiring errors, affecting the efficiency of integrated circuit design.

[0045] This application provides a code processing method for integrated circuits, a code processing device for integrated circuits, an electronic device, a computer-readable storage medium, and a computer program product, which improves the efficiency of signal transmission path connection between modules in integrated circuit design.

[0046] The following describes exemplary applications of the electronic devices provided in the embodiments of this application. These electronic devices can be implemented as terminal devices, such as laptops, tablets, desktop computers, set-top boxes, smart TVs, in-vehicle terminals, virtual reality (VR) devices, augmented reality (AR) devices, and other various types of terminals. They can also be implemented as servers. The following will describe exemplary applications when the electronic device is implemented as a terminal device or a server.

[0047] refer to Figure 1 , Figure 1 This is a schematic diagram illustrating the application mode of the integrated circuit code processing method provided in the embodiments of this application; for example, Figure 1The system involves server 200, network 300, terminal device 400, and database 500. Terminal device 400 is connected to voice recognition server 200 through network 300. Network 300 can be a wide area network, a local area network, or a combination of both.

[0048] For example, server 200 can be a server of an integrated circuit design platform, terminal device 400 is equipped with integrated circuit automated design tools, and database 500 stores a large amount of integrated circuit-related data. The user can be a designer.

[0049] In some embodiments, in the practical field of integrated circuits, users design integrated circuits through terminal device 400, select corresponding source code through the design interface of terminal device 400, request source code from server via network 300, and call the integrated circuit code processing method provided in the embodiments of this application to construct a structured packaging unit tree, and encapsulate and instantiate the structured packaging unit tree to obtain a hardware description language module. Users edit the connection relationship between the sub-modules of the customized integrated circuit through terminal device 400 to form connection instructions. Terminal device 400 calls the hardware description language module and connection instructions to form connection code. The connection code is hardware description language code, which can be directly read by integrated circuit automated design tools, thereby facilitating integrated circuit design.

[0050] In some embodiments, the server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Electronic devices can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, etc., but are not limited to these. Terminal devices and servers can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0051] See Figure 2 , Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may be... Figure 1 400 terminal devices Figure 2The terminal device 400 shown includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the terminal device 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 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 440.

[0052] Processor 410 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.

[0053] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0054] The memory 450 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 450 may optionally include one or more storage devices physically located away from the processor 410.

[0055] The memory 450 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 450 described in this application embodiment is intended to include any suitable type of memory.

[0056] In some embodiments, memory 450 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.

[0057] Operating system 451 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;

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

[0059] Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.).

[0060] The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0061] In some embodiments, the integrated circuit code processing apparatus provided in this application can be implemented in software. Figure 2 A code processing device 455 for an integrated circuit stored in memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a data acquisition module 4551, a packaging module 4552, and a code generation module 4553. These modules are logically sequential and can therefore be arbitrarily combined or further separated according to the functions implemented. Figure 2 For ease of explanation, all the above modules are shown at once, and the functions of each module will be explained below.

[0062] In other embodiments, the integrated circuit code processing device provided in this application can be implemented in hardware. As an example, the integrated circuit code processing device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the integrated circuit code processing 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), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0063] The code processing method for integrated circuits provided in this application will be described in conjunction with exemplary applications and implementations of the terminal devices provided in the embodiments of this application.

[0064] The code processing method for integrated circuits provided in the embodiments of this application will be described below. As mentioned above, the electronic device implementing the code processing method for integrated circuits in the embodiments of this application can be a terminal device or a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0065] It should be noted that the code processing examples below are illustrated using the generation of connection code as an example. Those skilled in the art can apply the integrated circuit code processing method provided in the embodiments of this application to the generation processing of other types of code based on their understanding of the following text.

[0066] See Figure 3 , Figure 3 This is a flowchart illustrating the code processing method for integrated circuits provided in this application embodiment, which will be combined with... Figure 3 The steps shown are explained. Figure 3 The entity responsible for executing the steps is Figure 1 Terminal device 400.

[0067] In step 301, the source code is obtained.

[0068] Here, the source code contains parameter information of submodules in the integrated circuit; the source code is register transfer level code.

[0069] For example, the source code contains register-transfer level (RTL) definitions for each sub-module in the integrated circuit that requires interconnect design, as well as related interface declaration information. The source code can be user-inputted, stored as a source code file on a terminal device, or retrieved from a database by the terminal device 400 via a network.

[0070] For example, the source code can be represented as:

[0071] Module DeviceA(outputs [31:0]data_value, outputs data_valid);

[0072] Module DeviceB(input [31:0]value_data, input vld_data).

[0073] Module DeviceA has a 32-bit output port (data_value) and a 1-bit output port (data_valid). Module DeviceB has a 32-bit input port (value_data) and a 1-bit input port (vld_data).

[0074] In step 302, a structured encapsulation unit tree is constructed based on the source code.

[0075] Here, the structured bundle tree includes a root node and child nodes, with the child nodes representing subfields of the port name in the parameter information.

[0076] For example, the process sequentially performs semantic parsing, data structure (e.g., list or object) generation, node construction, and node connection on the source code to obtain a structured encapsulation unit tree. For easier understanding, please refer to [reference needed]. Figure 6 , Figure 6 This is a schematic diagram of the structured encapsulation unit tree provided in this application embodiment. The structured encapsulation unit tree has at least one root node, and the root node 610 includes child nodes 611, which are connected to tree nodes 620 and 630. The root node 610 includes: a port name subfield, carrying data, a type identifier (isVec), and a vector size (vecSize). The type identifier is used to identify whether the node is a vector node and is used for automatic vector expansion. The vector size is used to measure the size of the vector.

[0077] In some embodiments, reference Figure 4 , Figure 4 This is a second flowchart illustrating the code processing method for integrated circuits provided in this application embodiment; step 302 can be achieved through... Figure 4 Steps 3021 to 3024 are implemented, and the details are explained below.

[0078] In step 3021, the parameter information of the source code is subjected to syntax analysis to obtain structured information.

[0079] Here, the structured information includes: submodule name, port name, interface type, and interface parameters.

[0080] For example, lexical and syntactic analysis techniques are used to parse the input source code. The parsing engine iterates through the code text, removing comments and whitespace, and identifying and extracting structured information. Continuing with the example from the source code above, for instance: the parsed submodule name is DeviceA, the port name is data_value, the output port has a bit width of 32.

[0081] In step 3022, the structured information is converted into a structured list.

[0082] Here, a structured list is an intermediate data structure that can be manipulated in computer memory.

[0083] For example, structured information is discrete and needs to be converted into an intermediate data structure that a computer can directly read, such as a structured list or object. For instance, the structured information above can be organized into a structured list:

[0084] Module name: DeviceA

[0085] Port name: data_value

[0086] Physical properties:

[0087] Direction: Output

[0088] Bit width: 32 bits ([31:0])

[0089] Type: Vector

[0090] In step 3023, the root node of the structured encapsulation unit tree is constructed.

[0091] As an example, the root node is used to connect multiple child nodes, and the root node may not contain a port name subfield. (See reference) Figure 7 , Figure 7 This is a visual schematic diagram of the structured encapsulation unit tree provided in the embodiments of this application. The root node may contain a port name subfield.

[0092] In step 3024, a structured list is invoked, and child nodes are represented by subfields based on port names. A structured encapsulation unit tree is constructed based on the child nodes and the root node.

[0093] For example, analyzing the prefix, suffix, or separator pattern in the port name (e.g., detecting underscores _) yields the subfields of the port name. For instance, `data_value` can be split into subfields `data` and `value`. Subfields represent child nodes. Connecting the root node and child nodes forms a structured encapsulation unit tree.

[0094] In some embodiments, step 3024 is implemented as follows: extracting information of submodules from a structured list, and performing the following processing for each submodule: splitting the port name of the submodule to obtain multiple subfields; treating each subfield as a child node; connecting each child node according to the order of the multiple subfields to obtain the tree path corresponding to the submodule; connecting the starting node of each tree path with the root node to obtain a structured encapsulation unit tree, wherein the starting node is used to represent the first subfield in the port name.

[0095] For example, let's continue with the examples above, such as: [Reference] Figure 7 Multiple tree paths connect to the root node, forming a structured encapsulation unit tree. The port name "data_value" is broken down, constructing the tree path: "root node -> data node -> value node" (root node -> data node -> value node). The port name "data_valid" is broken down, with data as the first subfield and the data node as the starting node, constructing the tree path: "root node -> data node -> valid node" (root node -> data node -> valid node). The port name "value_data" is broken down, constructing the tree path: "root node -> value node -> data node" (root node -> value node -> data node). The port name "vld_data" is broken down, constructing the tree path: "root node -> valid node -> data node" (root node -> vld node -> data node).

[0096] Continue to refer to Figure 3 In step 303, the structured encapsulation unit tree is encapsulated according to the high-level hardware description language to obtain a structured object.

[0097] For example, a structured object is a class instance or data container defined in a high-level hardware description language (such as Spinal HDL). Structured objects encapsulate originally discrete physical ports (such as data_value, data_valid) into programming entities with logical hierarchy and attributes.

[0098] In some embodiments, step 303 can be implemented by: standardizing the structured encapsulation unit tree to obtain a standardized structured encapsulation unit tree; and mapping the port names in the standardized structured encapsulation unit tree to member variables in an object programming language according to a high-level hardware description language to obtain a structured object.

[0099] For example, the standardization process includes: mapping subfields in the structured encapsulation unit tree that do not conform to the high-level hardware description language to standardized subfields that conform to the high-level hardware description language; merging the starting nodes of paths of the same function type; and annotating the subnodes with interface types.

[0100] In some embodiments, standardization can be achieved as follows: matching child nodes of the structured encapsulation unit tree according to a preset bus protocol library, and labeling child nodes based on the matched interface type; determining the function type of the tree path of the structured encapsulation unit tree according to the first sub-field in the port name, merging the starting nodes of tree paths of the same function type, wherein the starting node is used to represent the first sub-field in the port name; determining non-standardized sub-fields in the structured encapsulation unit tree according to preset rules, replacing non-standardized sub-fields with standardized sub-fields; and using the replaced structured encapsulation unit tree as the standardized structured encapsulation unit tree.

[0101] Continuing with the example above, for instance, the structural characteristics of the tree node are matched with predefined bus protocol libraries (such as AXI4 and APB3), and it is checked whether there are key signal combinations under the tree node that conform to a specific protocol. If the match is successful, the node is marked as the corresponding interface type.

[0102] For example, functional attributes are represented by subfields. The subfields of the port name are separated by separators (such as _) or affixes, and each subfield is classified. For example, tx_data and tx_valid have the common prefix tx. The above signals are classified under the type of tx, the tx nodes of these paths are merged into one node, and this tx is connected to the data and valid nodes respectively to form a substructure.

[0103] For example, semantic analysis detects that the node name "vld" is an abbreviation, so a renaming operation is performed, replacing "vld" with the standard name "valid" to align its semantics with DeviceA. The following structured encapsulation unit tree can be obtained: Figure 7 As shown, Figure 7 This is a visual schematic diagram of the structured encapsulation unit tree provided in the embodiments of this application. "Root node -> vld node -> data node" is... Figure 7 In the standardization, it is "root node -> valid node -> data node" ("root node -> valid node -> data node").

[0104] For example, mapping port names in a standardized structured encapsulation unit tree to member variables in an object-oriented programming language can be achieved by defining a class template (ClassTemplate) in a high-level language (such as Scala / Spinal HDL). The class template inherits from the hardware interface base class (such as Bundle), traverses the child nodes of the structured encapsulation unit tree in memory, reads the port name and attributes (name, bit width, direction) corresponding to the traversed child node, and dynamically generates a corresponding line of member variable definition code in the class template based on the read content to form a structured object. For example, converting it to a structured object Bundle in the high-level hardware description language SpinalHDL would be represented in the following form:

[0105] Define the interface class DeviceABundle as inheriting from the generic interface base class Bundle;

[0106] Define the member variable data_value as a 32-bit unsigned integer and map it to the physical port data_value;

[0107] Define a member variable data_valid: of type boolean (1 bit), mapped to the physical port data_valid.

[0108] In step 304, the structured object is instantiated to obtain the hardware description language module.

[0109] For example, instantiation refers to the process of creating a concrete, independent entity (object or instance) in the system based on an abstract template (class or module definition). A hardware description language module refers to a module instance that exists in memory, used for wiring, simulation, or code generation.

[0110] In some embodiments, step 304 can be implemented as follows: import the hardware description primitive library and standard hardware library into the runtime environment of the high-level hardware description language, and define hardware module classes based on the hardware description primitive library and standard hardware library; in the hardware module classes, create module instance objects of each sub-module in the integrated circuit based on structured objects; construct the connection between the module instance objects according to the high-level hardware description language to form a hardware description language module.

[0111] For example, the connections between module instance objects are bidirectional. Continuing with the example above, consider instantiating a structured object `Bundle` from the high-level hardware description language `Spinal HDL` to form a top-level module in the high-level language, represented as follows:

[0112] Import all classes, objects, and functions from the spinal.core package to include the hardware description primitives library for Spinal HDL.

[0113] Import all classes, objects, and functions from the spinal.lib package to include the standard hardware library for Spinal HDL.

[0114] Define a top-level hardware module class named MyTopLevel.

[0115] Define a top-level component class MyTopLevel, which inherits from the hardware component base class (Component):

[0116] Instantiating submodules (Scala):

[0117] Create an object DeviceA as an instance of module DeviceA;

[0118] Create an object DeviceB as an instance of module DeviceB;

[0119] Create an object u_mul as an instance of the multiplier module;

[0120] Connect all I / O interfaces of DeviceA to all I / O interfaces of DeviceB in a batch bidirectional manner.

[0121] The phrase "batch bidirectional interconnection of all IO interfaces of DeviceA with all IO interfaces of DeviceB" is represented as DeviceA.io<>DeviceB.io. The <> operator is a unique bidirectional automatic connection operator in Spinal HDL. Its function is to automatically match signals in DeviceA.io and DeviceB.io that have identical names, bit widths, and directions, and then perform bidirectional interconnection on the matched signals. For example, input → output and output → input can be bound accordingly.

[0122] In step 305, in response to receiving a connection instruction, code is generated based on the connection instruction and the hardware description language module to obtain connection code.

[0123] Here, the connection instructions include the connection relationships between sub-modules in the integrated circuit, the connection code indicates the signal transmission path between sub-modules in the integrated circuit, and the connection code is hardware description language code.

[0124] In some embodiments, prior to step 305, the method further includes: displaying a schematic diagram of a structured encapsulation unit tree; and in response to an input operation, acquiring a connection instruction input by the input operation, wherein the connection instruction is generated based on the schematic diagram of the structured encapsulation unit tree.

[0125] For example, the connection instructions are represented as a script file, and the schematic diagram of the structured package unit tree can be displayed directly on the terminal device screen or printed out as a paper document. Users can analyze the visualized structured package unit tree and write custom script files, receiving user-input script files. Based on the visualized tree structure and design requirements, users write script files that specify the connection rules, describing the signal transmission paths between specific signal nodes at different module interface levels in the integrated circuit design. For example, the user-input script file content might be: DeviceA.io.data.value->DeviceB.io.value.data. This will be explained below.

[0126] In some embodiments, step 305 can be implemented as follows: converting the script file carried by the connection instruction to obtain the connection relationship in the form of hardware description language; determining the signal transmission path between the ports of the sub-modules in the integrated circuit based on the connection relationship; and calling the hardware description language module to generate connection code according to the signal transmission path and assignment keywords.

[0127] Continuing with the example above, for instance, the content of the script file entered by the user could be:

[0128] The expression `DeviceA.io.data.value->DeviceB.io.value.data` means connecting the value signal in the data group of the DeviceA interface to the data signal in the value group of the DeviceB interface. This can be represented in the script file as Spinal HDL code: `DeviceA.io.data.value<>DeviceB.io.value.data`.

[0129] DeviceA.io->DeviceB.io indicates that the top-level interface DeviceA.io of module A is connected to the top-level interface DeviceB.io of module B. The script file can be represented as Spinal HDL code: DeviceA.io<>DeviceB.io.

[0130] Continuing with the examples above, for instance:

[0131] For DeviceA.io.data.value<>DeviceB.io.value.data, determine if the bit widths of the source and target are consistent. If they are consistent, determine that the target signal is driven by the source signal, establish a connection, and generate the following code:

[0132] The code `assign DeviceB.value_data=DeviceA.data_value` is Verilog HDL code. `assign` is a keyword in Verilog HDL used to define continuous assignment. The generated code means that the data signal `data_value` output by DeviceA is assigned to the input port `value_data` of DeviceB.

[0133] For DeviceA.io->DeviceB.io, it is identified as a batch connection instruction between top-level interface I / Os, and all child nodes under DeviceA.io and DeviceB.io are traversed; if data_value and value_data have matching bit widths in the remaining signals, a connection is established; if data_valid and valid_data have semantic consistency, a connection is established. The generated code is:

[0134] assign DeviceB.value_data=DeviceA.data_value;

[0135] `assign DeviceB.valid_data=DeviceA.data_valid;` is Verilog code that generates code to directly assign the 32-bit data signal `data_value` output from DeviceA to the 32-bit input port `value_data` of DeviceB. It also assigns the control signal `data_valid` output from DeviceA to the control input port `valid_data` of DeviceB.

[0136] In this embodiment, by parsing the subfields of port names in the source code and constructing a structured encapsulation unit tree, the originally discrete register transfer level port names and other information are converted into a structured encapsulation unit tree with logical hierarchical relationships. This allows the underlying physical port information to be recognized and processed by the computer program in a structured form. By using a high-level hardware description language to encapsulate the structured encapsulation unit tree into structured objects, and mapping specific physical ports to object attributes in the programming language, hardware interfaces can be processed by manipulating object attributes rather than directly manipulating physical signal lines, thus shielding underlying physical details such as bit width and direction. By responding to connection commands and combining them with instantiated hardware description language modules, the user-defined connection relationships carried by the connection commands are automatically converted into specific underlying hardware description language connection code. This replaces the process of manually writing a large number of signal assignment statements, reducing the amount of connection code to be written. The connection code is used to indicate the signal transmission path between sub-modules in the integrated circuit, and since the connection code is hardware description language code, it can be directly read by electronic design automation tools, improving the efficiency of integrated circuit design.

[0137] The following will describe an exemplary application of the integrated circuit code processing method of this application embodiment in a practical application scenario.

[0138] As the scale of integrated circuit chips continues to increase, the design complexity of system-on-a-chip (SoC) has risen sharply, and the interconnection design between modules has become a key factor affecting development efficiency. In the electronic design automation (EDA) process of related technologies, module connections usually rely on manual writing of hardware description languages ​​(such as Verilog or System Verilog) or the assistance of specific tools for generation.

[0139] However, the connection technology of related technologies has the following limitations in practical applications:

[0140] First, the EDA tools for related technologies lack sufficient semantic understanding of signal names. Current tools primarily rely on static table configurations or predefined standard formats (such as IP-XACT tables) to describe interfaces. These tools cannot automatically parse the structured information implicit in RTL port signal names and fail to fully utilize character features such as prefixes, suffixes, or separators in signal names. This results in a disconnect between design intent and tool implementation, even though engineers may express logical hierarchy or functional attributes through character features in naming.

[0141] Second, the related technologies lack flexibility in protocol adaptation. Traditional EDA tools typically require module interfaces to strictly adhere to predefined bus protocols (such as AXI4) to achieve automated grouping and connection. For custom interfaces not predefined in the tool library or ordinary discrete port signals, the tools cannot adaptively mine their structured characteristics, making it difficult to achieve automated signal aggregation and processing.

[0142] Third, the connection methods of related technologies are labor-intensive and difficult to maintain. Due to the lack of intelligent identification and aggregation capabilities for non-standard signals, technicians often need to manually establish one-to-one mapping relationships between signals. In designs involving a large number of signals or complex hierarchies, this manual connection method is not only time-consuming and inefficient, but also highly susceptible to human errors such as spelling mistakes or bit-width mismatches. Furthermore, when module definitions change, manually maintaining a large amount of top-level connection code is costly and affects processing efficiency.

[0143] The integrated circuit code processing method provided in this application addresses the problem in related technologies where signal connections rely on manually predefined structured bundles of signal sets or require one-to-one connections. By mining the structured information of port signals in Register Transfer Level (RTL) code, it improves the connection efficiency between modules. It uses an integrated circuit combined with Spinal Hardware Description Language (HDL) to achieve automatic signal connection between modules. By integrating the meta-programming capabilities of Spinal HDL and the construction of a structured bundle tree of signal sets, it can automatically extract structured connection rules from the original RTL port names and generate hardware code that can be directly integrated into the Spinal HDL design flow. This method is particularly suitable for scenarios that utilize the implicit structural information in RTL signal names to simplify the interconnection of multiple modules.

[0144] See Figure 5 , Figure 5 This is a flowchart illustrating the code processing method for integrated circuits provided in this application embodiment, which will be combined with... Figure 5 The steps shown are explained. Figure 5 The entity responsible for executing the steps is Figure 1 Terminal device 400.

[0145] In step 501, the source code file is obtained.

[0146] For example, the system reads a source code file, receiving a System Verilog (SV) or Verilog (V) source code file as input data. The source code file contains the register-transfer level (RTL) definitions of the various sub-modules (modules) in the integrated circuit that require interconnect design, as well as related interface declaration information. Since the source code file is based on the register-transfer level, which is a circuit description level, the goal of this embodiment is to convert the source code file into a hardware description language so that EDA tools can understand it.

[0147] For example, the source code can be represented as:

[0148] Module DeviceA(outputs [31:0]data_value, outputs data_valid);

[0149] Module DeviceB(input [31:0]value_data, input vld_data).

[0150] Module DeviceA has a 32-bit output port (data_value) and a 1-bit output port (data_valid). Module DeviceB has a 32-bit input port (value_data) and a 1-bit input port (vld_data).

[0151] In step 502, the source code is decomposed and analyzed to obtain structured information.

[0152] For example, lexical and syntactic analysis techniques are used to parse the input source code. The parsing engine traverses the code text, stripping away comments and whitespace, and identifies and extracts structured information, including: module name, port list (including port name, width, and direction), parameter definitions, and interface instantiation, among other key structured information. For example: module name DeviceA, port name data_value, output port, width is 32.

[0153] In step 503, the module-level interface is called to generate the data structure.

[0154] For example, converting extracted discrete structured information into an operable intermediate data structure in computer memory can be achieved in the following way: organizing the structured information into a structured list or structured object, explicitly recording the module affiliation and physical attributes of each port, providing a data foundation for subsequent hierarchical processing. For example, organizing the structured information above into a structured list:

[0155] Module name: Device A

[0156] Port name: data_value (data_value)

[0157] Physical properties:

[0158] Direction: Output

[0159] Bit width: 32 bits ([31:0])

[0160] Type: Vector

[0161] In step 504, a structured encapsulation unit tree is constructed.

[0162] For example, an empty tree-structured container is created using a Tree Node manager, and the generated intermediate data structures are traversed. By analyzing prefixes, suffixes, or separator patterns in port names (e.g., detecting underscores _), the port list is recursively clustered to construct a structured bundle tree that reflects the design logic hierarchy.

[0163] refer to Figure 6 , Figure 6 This is a schematic diagram of the structured encapsulation unit tree provided in this application embodiment. The structured encapsulation unit tree has at least one root node, and the root node 610 includes child nodes 611, which are connected to tree nodes 620 and 630. The root node 610 includes: a port name subfield, carrying data, a type identifier (isVec), and a vector size (vecSize). The type identifier is used to identify whether the node is a vector node and is used for automatic vector expansion. The vector size is used to measure the size of the vector.

[0164] Continuing with the examples above, for instance: (Refer to...) Figure 7Multiple tree paths connect to the root node, forming a structured encapsulation unit tree. The port name "data_value" is broken down, constructing the tree path: "root node -> data node -> value node" (root node -> data node -> value node), corresponding to device A. The port name "data_valid" is broken down, with data as the first subfield and the data node as the starting node, constructing the tree path: "root node -> data node -> valid node" (root node -> data node -> valid node), corresponding to device A. The port name "value_data" is broken down, constructing the tree path: "root node -> value node -> data node" (root node -> value node -> data node), corresponding to device B. The port name "vld_data" is broken down, constructing the tree path: "root node -> valid node -> data node" (root node -> vld node -> data node), corresponding to device B.

[0165] In step 505, semantic enhancement and standardization processing are performed on the nodes of the structured encapsulation unit tree.

[0166] For example, the structural characteristics of tree nodes are matched with predefined bus protocol libraries (such as AXI4, APB3); related signals are grouped according to functional attributes; and non-standard port names are renamed to standard semantic names according to preset rules or regular expressions to eliminate naming differences between different modules. Step 505 can be implemented using taggers.

[0167] Continuing with the example above, for instance, the structural characteristics of the tree node are matched with predefined bus protocol libraries (such as AXI4 and APB3), and it is checked whether there are key signal combinations under the tree node that conform to a specific protocol. If the match is successful, the node is marked as the corresponding interface type.

[0168] For example, functional attributes are represented by subfields. The subfields of the port name are separated by separators (such as _) or affixes, and each subfield is classified. For example, tx_data and tx_valid have the common prefix tx. The above signals are classified under the type of tx, the tx nodes of these paths are merged into one node, and this tx is connected to the data and valid nodes respectively to form a substructure.

[0169] For example, semantic analysis detects that the node name "vld" is an abbreviation, so a renaming operation is performed, replacing "vld" with the standard name "valid" to align its semantics with Device A. The following structured encapsulation unit tree can be obtained: Figure 7 As shown, Figure 7 This is a visual schematic diagram of the structured encapsulation unit tree provided in the embodiments of this application. "Root node -> vld node -> data node" is... Figure 7 In the standardization, it is "root node -> valid node -> data node" (root node -> valid node -> data node).

[0170] After step 505, step 506 is executed to display the processed structured encapsulation unit tree.

[0171] For example, the structured encapsulation unit tree can be displayed as a graphical interface or a text log, or it can be printed as a paper document using a computer-connected printing device. The visualization of the structured encapsulation unit tree intuitively shows designers the logical hierarchy of the module interfaces, serving as a reference for designers to confirm the parsing results and write connection scripts.

[0172] Step 507 is executed after step 505 to generate a high-level language structure.

[0173] For example, the structured encapsulation unit tree is converted into a structured object (Bundle) in a high-level hardware description language (such as Spinal HDL), a corresponding interface class definition is generated for each module, and physical ports are mapped to member variables in an object-oriented programming language, thereby encapsulating the structure using the type system of the high-level language.

[0174] Continuing with the examples above, for instance: Figure 7 The structured encapsulation unit tree in the code is converted into a structured object Bundle in the high-level hardware description language Spinal HDL, represented in the following form:

[0175] Define the interface class DeviceABundle as inheriting from the generic interface base class Bundle;

[0176] Define the member variable data_value as a 32-bit unsigned integer and map it to the physical port data_value;

[0177] Define a member variable data_valid: of type boolean (1 bit), mapped to the physical port data_valid.

[0178] In some embodiments, step 507 can be implemented using the Spinal HDL compiler, which has a built-in Lint tool that can be used to check for errors in the generated code. The Lint tool is a static code analysis tool used to find errors, inconsistent styles, and potential program problems in the code, helping to improve code quality and maintainability. For example, when automatically generating linker code, if the user's script logic incorrectly connects Signal_A to Signal_B while simultaneously connecting Signal_B back to Signal_A (with no intermediate registers), the Lint tool will report an error before code generation, preventing such dangerous circuitry. If the user attempts to directly connect a signal belonging to the clk_100m domain to a port belonging to the clk_48m domain, the Lint tool will detect a frequency mismatch, issue a warning or error, and prompt the user to insert a synchronization processing module, thereby avoiding the potential risk of chip failure.

[0179] After step 507, step 508 is executed to generate a high-level language top-level module based on the high-level language structure.

[0180] For example, building a top-level design container (a top-level module of a high-level language) in the runtime environment of a high-level hardware description language is achieved by instantiating structured objects and establishing a top-level design (Top Level Component) framework, which can be used to provide a context for subsequent module interconnection.

[0181] Continuing with the example above, consider instantiating a structured object Bundle from the high-level hardware description language Spinal HDL to form a top-level module of the high-level language, represented as follows:

[0182] Import all classes, objects, and functions from the spinal.core package to include the hardware description primitives library for Spinal HDL.

[0183] Import all classes, objects, and functions from the spinal.lib package to include the standard hardware library for Spinal HDL.

[0184] Define a top-level hardware module class named MyTopLevel.

[0185] Define a top-level component class MyTopLevel, which inherits from the hardware component base class (Component):

[0186] Instantiating submodules (Scala):

[0187] Create an object DeviceA as an instance of module DeviceA;

[0188] Create an object DeviceB as an instance of module DeviceB;

[0189] Create an object u_mul as an instance of the multiplier module;

[0190] Connect all I / O interfaces of DeviceA to all I / O interfaces of DeviceB in a batch bidirectional manner.

[0191] The phrase "batch bidirectional interconnection of all IO interfaces of DeviceA with all IO interfaces of DeviceB" is represented as DeviceA.io<>DeviceB.io. The <> operator is a unique bidirectional automatic connection operator in Spinal HDL. Its function is to automatically match signals in DeviceA.io and DeviceB.io that have identical names, bit widths, and directions, and then perform bidirectional interconnection on the matched signals. For example, input → output and output → input can be bound accordingly.

[0192] After step 506, proceed to step 509 to obtain the user-defined script file.

[0193] For example, users can analyze a visualized structured package tree and write custom script files, receiving user-input script files. Based on the visualized tree structure and design requirements, users write script files that specify connection rules. These rules describe the signal transmission paths between specific signal nodes at different module interface levels in the integrated circuit design. For example, the user-input script file might contain: DeviceA.io.data.value->DeviceB.io.value.data. This will be explained below.

[0194] After step 509, step 510 is executed to parse the script file based on the script language rules of the structured encapsulation unit tree path.

[0195] For example, based on the path description in the script file, the specific node object is located in the structured encapsulation unit tree, and the validity of the connection (such as bit width matching and direction matching) is verified. This process converts abstract path connection instructions into concrete signal-driven logic. Parsing the script file can be achieved by converting it into the high-level hardware description language Spinal HDL. The parsed script file can then be used as instructions to trigger the generation of top-level code for inter-module connections.

[0196] Continuing with the example above, for instance, the content of the script file entered by the user could be:

[0197] The expression `DeviceA.io.data.value->DeviceB.io.value.data` means connecting the value signal in the data group of the DeviceA interface to the data signal in the value group of the DeviceB interface. This can be represented in the script file as Spinal HDL code: `DeviceA.io.data.value<>DeviceB.io.value.data`.

[0198] DeviceA.io->DeviceB.io indicates that the top-level interface DeviceA.io of module A is connected to the top-level interface DeviceB.io of module B. The script file can be represented as Spinal HDL code: DeviceA.io<>DeviceB.io.

[0199] In step 511, the top-level code for inter-module connections is generated.

[0200] For example, based on the connection logic in the parsed script file from step 510 and the high-level language top-level module generated in step 508, a standard System Verilog or Verilog top-level code file is automatically generated. The top-level code file contains the module instantiation statements and the assignment statements for all wires. The top-level code file is code that can be recognized by EDA tools (such as Vivado, Quartus, and Design Compiler), and can be directly used in subsequent EDA synthesis and simulation processes, thus realizing the automated conversion from non-standard named RTL code to standardized top-level connection code.

[0201] Continuing with the examples above, for instance:

[0202] For DeviceA.io.data.value<>DeviceB.io.value.data, determine if the bit widths of the source and target are consistent. If they are consistent, determine that the target signal is driven by the source signal, establish a connection, and generate the following code:

[0203] The code `assign DeviceB.value_data=DeviceA.data_value` is Verilog HDL code. `assign` is a keyword in Verilog HDL used to define continuous assignment. The generated code means that the data signal `data_value` output by DeviceA is assigned to the input port `value_data` of DeviceB.

[0204] For DeviceA.io->DeviceB.io, it is identified as a batch connection instruction between top-level interface I / Os, and all child nodes under DeviceA.io and DeviceB.io are traversed; if data_value and value_data have matching bit widths in the remaining signals, a connection is established; if data_valid and valid_data have semantic consistency, a connection is established. The generated code is:

[0205] assign DeviceB.value_data=DeviceA.data_value;

[0206] `assign DeviceB.valid_data=DeviceA.data_valid;` is Verilog code that generates code to directly assign the 32-bit data signal `data_value` output from DeviceA to the 32-bit input port `value_data` of DeviceB. It also assigns the control signal `data_valid` output from DeviceA to the control input port `valid_data` of DeviceB.

[0207] In this embodiment, the Spinal HDL language is used and a standard library (such as AxiLite4) is called. Compared with related technologies, it does not require redefining the interface, supports dynamic bit width of the interface, and performs static checking at compile time.

[0208] The integrated circuit code processing method provided in this application has the following beneficial effects: (1) Simplifying the number of connections: By parsing the structural features of port names and constructing a hierarchical tree structure (Bundle Tree), the discrete and flat physical signals in the original code are aggregated into signal groups with logical associations. Designers can perform batch operations based on tree node paths, thereby reducing the hundreds of line-by-line connection instructions that need to be manually written in the traditional method to a small number of logical path descriptions, reducing manual connection entries, and reducing the complexity of integration work. (2) Improving protocol compatibility: Using a tag processor (Taggers) to perform feature analysis and semantic remapping on tree nodes. The tag processor can automatically identify and bind bus protocols (such as AXI4 and APB3) in the Spinal HDL standard library based on pattern matching; on the other hand, by supporting custom extension rules, it can adaptively handle non-standard naming or legacy interfaces, so that the design process can achieve interconnection between modules with different protocols or naming styles without modifying the original RTL code, reducing protocol adaptation code. (3) Providing visual assistance: The constructed hierarchical tree structure is visualized in graphical or textual form. The internal hierarchy and logical relationship of the module interface are intuitively displayed, enabling designers to quickly and accurately locate node paths when writing connection scripts, thus reducing the difficulty of script writing. (4) Reduce design error rate: Combine the tree-path-based script description with the compiler's static checking technology. The tree-path-based connection method ensures the consistency of signal group connections and avoids missing individual signal lines. The Lint tool built into the Spinal HDL compiler is used to detect combinational logic loops, cross-clock domain violations, and bit width mismatches in advance during the code generation stage, ensuring the accuracy of the final generated top-level connection code.

[0209] The following description continues to illustrate the exemplary structure of the integrated circuit code processing device 455 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules in the code processing device 455 of the integrated circuit stored in the memory 450 may include:

[0210] Data acquisition module 4551 is used to acquire source code, wherein the source code contains parameter information of sub-modules in the integrated circuit, and the source code is register-transfer level code; encapsulation module 4552 is used to construct a structured encapsulation unit tree based on the source code, wherein the structured encapsulation unit tree includes a root node and child nodes, and the child nodes represent sub-fields of port names in the parameter information; encapsulate the structured encapsulation unit tree according to a high-level hardware description language to obtain a structured object; instantiate the structured object to obtain a hardware description language module; code generation module 4553 is used to generate code based on the connection instruction and the hardware description language module in response to receiving a connection instruction to obtain connection code, wherein the connection instruction includes the connection relationship between the sub-modules in the integrated circuit, the connection code indicates the signal transmission path between the sub-modules in the integrated circuit, and the connection code is hardware description language code.

[0211] In some embodiments, the encapsulation module 4552 is used to perform syntactic analysis on the parameter information of the source code to obtain structured information, wherein the structured information includes: submodule name, port name, interface type, and interface parameters; convert the structured information into a structured list, wherein the structured list is an operable intermediate data structure in computer memory; construct the root node of the structured encapsulation unit tree; represent child nodes based on the subfields of the port name, and construct the structured encapsulation unit tree based on the child nodes and the root node.

[0212] In some embodiments, the encapsulation module 4552 is configured to extract information of sub-modules from the structured list and perform the following processing for each sub-module: splitting the port name of the sub-module to obtain multiple sub-fields; treating each sub-field as a child node; connecting each child node according to the order of the multiple sub-fields to obtain a tree path corresponding to the sub-module; connecting the starting node of each tree path with the root node to obtain the structured encapsulation unit tree, wherein the starting node is used to represent the first sub-field in the port name.

[0213] In some embodiments, the encapsulation module 4552 is used to standardize the structured encapsulation unit tree to obtain a standardized structured encapsulation unit tree; and to map the port names in the standardized structured encapsulation unit tree to member variables in an object programming language according to a high-level hardware description language to obtain a structured object.

[0214] In some embodiments, the encapsulation module 4552 is configured to: match the child nodes of the structured encapsulation unit tree according to a preset bus protocol library, and label the child nodes based on the matched interface type; determine the function type of the tree path of the structured encapsulation unit tree according to the first sub-field in the port name, merge the starting nodes of the tree paths of the same function type, wherein the starting node is used to represent the first sub-field in the port name; determine the non-standardized sub-fields in the structured encapsulation unit tree according to preset rules, replace the non-standardized sub-fields with standardized sub-fields; and use the replaced structured encapsulation unit tree as the standardized structured encapsulation unit tree.

[0215] In some embodiments, the encapsulation module 4552 is used to import a hardware description primitive library and a standard hardware library into the runtime environment of a high-level hardware description language, and define a hardware module class based on the hardware description primitive library and the standard hardware library; in the hardware module class, module instance objects of each sub-module in the integrated circuit are created based on the structured object; and the connection between the module instance objects is constructed according to the high-level hardware description language to form the hardware description language module.

[0216] In some embodiments, the code generation module 4553 is used to convert the script file carried by the connection instruction to obtain the connection relationship in the form of a hardware description language; based on the connection relationship, determine the signal transmission path between the ports of the sub-modules in the integrated circuit; and call the hardware description language module to generate the connection code according to the signal transmission path and the assignment keyword.

[0217] This application provides a computer program product, which includes a computer program or computer-executable instructions. A processor executes the computer program or computer-executable instructions to implement the integrated circuit code processing method described above in this application.

[0218] 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 code processing method of the integrated circuit provided in this application. For example, ... Figure 3 The code processing method for the integrated circuit is shown.

[0219] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, 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.

[0220] 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.

[0221] 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 HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0222] 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.

[0223] In summary, through the embodiments of this application, by parsing the subfields of port names in the source code and constructing a structured encapsulation unit tree, the originally discrete port names and other information at the register transfer level are transformed into a structured encapsulation unit tree with logical hierarchical relationships. This allows the underlying physical port information to be recognized and processed by computer programs in a structured form. By using a high-level hardware description language to encapsulate the structured encapsulation unit tree into structured objects, and mapping specific physical ports to object attributes in the programming language, hardware interfaces can be processed by manipulating object attributes rather than directly manipulating physical signal lines, thus shielding underlying physical details such as bit width and direction. By responding to connection commands and combining them with instantiated hardware description language modules, the user-defined connection relationships carried by the connection commands are automatically transformed into specific underlying hardware description language connection code. This replaces the process of manually writing a large number of signal assignment statements, reducing the amount of connection code to be written. The connection code is used to indicate the signal transmission path between sub-modules in the integrated circuit, and since the connection code is hardware description language code, it can be directly read by electronic design automation tools, improving the efficiency of integrated circuit design.

[0224] 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 code processing method for integrated circuits, characterized in that, The method includes: Obtain the source code, wherein the source code contains parameter information of sub-modules in the integrated circuit, and the source code is register transfer level code; Syntax analysis is performed on the parameter information of the source code to obtain structured information, wherein the structured information includes: submodule name, port name, interface type, and interface parameters; The structured information is converted into a structured list, wherein the structured list is an operable intermediate data structure in computer memory; Construct the root node of the structured encapsulation unit tree; Extract information about the submodules from the structured list, and perform the following processing for each submodule: The port name of the submodule is split to obtain multiple subfields; Each of the aforementioned subfields is treated as a child node; Based on the order of the multiple sub-fields, each sub-node is connected to obtain the tree path corresponding to the sub-module; Connect the starting node of each tree path to the root node to obtain the structured encapsulation unit tree, wherein the starting node is used to represent the first sub-field in the port name; The structured encapsulation unit tree is encapsulated using a high-level hardware description language to obtain a structured object; The structured object is instantiated to obtain a hardware description language module; In response to receiving a connection instruction, code is generated based on the connection instruction and a hardware description language module to obtain connection code. The connection instruction includes the connection relationship between the sub-modules in the integrated circuit, the connection code indicates the signal transmission path between the sub-modules in the integrated circuit, and the connection code is hardware description language code.

2. The method according to claim 1, characterized in that, The process of encapsulating the structured encapsulation unit tree according to a high-level hardware description language to obtain a structured object includes: The structured encapsulation unit tree is standardized to obtain a standardized structured encapsulation unit tree; Based on a high-level hardware description language, the port names in the standardized structured encapsulation unit tree are mapped to member variables in an object programming language to obtain structured objects.

3. The method according to claim 2, characterized in that, The standardization process of the structured encapsulation unit tree to obtain the standardized structured encapsulation unit tree includes: According to the preset bus protocol library, the child nodes of the structured encapsulation unit tree are matched, and the child nodes are labeled based on the matched interface type; The function type of the tree path of the structured encapsulation unit tree is determined based on the first subfield in the port name, and the starting nodes of the tree paths of the same function type are merged, wherein the starting node is used to represent the first subfield in the port name; According to preset rules, non-standardized subfields in the structured encapsulation unit tree are determined, and the non-standardized subfields are replaced with standardized subfields. The replaced structured encapsulation unit tree is used as the standardized structured encapsulation unit tree.

4. The method according to claim 1, characterized in that, The instantiation of the structured object to obtain the hardware description language module includes: Import the hardware description primitive library and standard hardware library into the runtime environment of the high-level hardware description language, and define hardware module classes based on the hardware description primitive library and the standard hardware library; In the hardware module class, module instance objects of each sub-module in the integrated circuit are created based on the structured object; The hardware description language module is formed by constructing connections between the module instance objects based on the high-level hardware description language.

5. The method according to claim 1, characterized in that, In response to receiving a connection command, code generation is performed based on the connection command and the hardware description language module to obtain connection code, including: The script file carried by the connection instruction is converted to obtain the connection relationship in the form of hardware description language; Based on the connection relationship, the signal transmission path between the ports of the sub-modules in the integrated circuit is determined; Based on the signal transmission path and assignment keywords, the hardware description language module is invoked to generate the connection code.

6. A code processing device for an integrated circuit, characterized in that, The device includes: A data acquisition module is used to acquire source code, wherein the source code contains parameter information of sub-modules in an integrated circuit, and the source code is register transfer level code; The code encapsulation module is used to perform syntax analysis on the parameter information of the source code to obtain structured information, wherein the structured information includes: submodule name, port name, interface type, and interface parameters; The structured information is converted into a structured list, wherein the structured list is an operable intermediate data structure in computer memory; Construct the root node of the structured encapsulation unit tree; Extract information about the submodules from the structured list, and perform the following processing for each submodule: The port name of the submodule is split to obtain multiple subfields; Each of the aforementioned subfields is treated as a child node; Based on the order of the multiple sub-fields, each sub-node is connected to obtain the tree path corresponding to the sub-module; Connect the starting node of each tree path to the root node to obtain the structured encapsulation unit tree, wherein the starting node is used to represent the first subfield in the port name; encapsulate the structured encapsulation unit tree according to the high-level hardware description language to obtain a structured object; instantiate the structured object to obtain a hardware description language module; A code generation module is used to generate connection code based on the received connection instruction and a hardware description language module in response to receiving a connection instruction. The connection instruction includes the connection relationship between the sub-modules in the integrated circuit, and the connection code indicates the signal transmission path between the sub-modules in the integrated circuit. The connection code is hardware description language code.

7. 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 code processing method of the integrated circuit according to any one of claims 1 to 5.

8. 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 code processing method for the integrated circuit according to any one of claims 1 to 5.

Images