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

Abstract

The invention provides a code processing method and device of an integrated circuit, electronic equipment and a storage medium. The method comprises the steps that a source code is obtained, the source code comprises parameter information of a sub-module in the integrated circuit, and the source code is a register transfer level code; constructing a structured encapsulation unit tree based on the source code; packaging 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 the received connection instruction, code generation is performed based on the connection instruction and the hardware description language module to obtain a connection code, 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 a hardware description language code. According to the invention, the connection efficiency of signal transmission paths between modules in an integrated circuit design can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic design automation, and in particular to a code processing method and device for integrated circuits, an electronic device, and a storage medium. BACKGROUND

[0002] Electronic design automation (EDA) is a technology for automatically processing the design process of very large scale integrated circuits (VLSI) and related electronic systems by using computer-aided design (CAD) software. In the electronic design automation process of the related art, module connection usually depends on manual writing or auxiliary generation by a specific tool of a hardware description language (such as Verilog or System Verilog). With the rapid expansion of the scale of integrated circuit design, a hardware construction framework based on a high-level programming language has gradually become a new trend in the design field due to its high degree of abstraction and development efficiency.

[0003] However, a large number of register transfer level (RTL) codes are still retained in the current chip design ecosystem. When RTL modules are integrated into a high-level language environment for top-level interconnection, it is difficult to directly map them to structured objects (such as Bundle) in the high-level language. This means that designers must manually write a large amount of BlackBox packaging code to rebuild the interface structure, which is tedious and repetitive. In addition, different sources of RTL modules often have inconsistent naming styles, and automatic tools cannot intelligently match across these naming differences, resulting in the need for designers to write thousands of lines of assignment code for line-by-line connection at the top level. This not only reduces efficiency, but also easily introduces connection errors, affecting the efficiency of integrated circuit design. SUMMARY

[0004] Embodiments of the present application provide a code processing method and device for integrated circuits, an electronic device, and a storage medium, which can improve the efficiency of connecting signal transmission paths between modules in integrated circuit design.

[0005] The technical solutions of the embodiments of the present application are as follows: The embodiments of the present application provide a code processing method for integrated circuits, which comprises the following steps: Obtaining source code, wherein the source code contains parameter information of a sub-module in an integrated circuit, and the source code is a register transfer level code; Constructing a structured packaging unit tree based on the source code, wherein the structured packaging unit tree comprises a root node and a child node, and the child node represents a sub-field of a port name in the parameter information; 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. In response to receiving the connection instruction, code generation is performed 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.

[0006] The embodiment of the present application provides a code processing apparatus of an integrated circuit, which comprises: a data acquisition module configured to acquire source code, wherein the source code comprises parameter information of sub-modules in an integrated circuit, and the source code is register transfer level code; a code encapsulation module configured to construct a structured encapsulation unit tree based on the source code, wherein the structured encapsulation unit tree comprises a root node and a child node, the child node represents a sub-field of a port name in the parameter information; encapsulate the structured encapsulation unit tree according to a high-level hardware description language, to obtain a structured object; and instantiate the structured object, to obtain a hardware description language module; a code generation module configured to, in response to receiving a connection instruction, perform 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.

[0007] The embodiment of the present application provides an electronic device, which comprises: a memory configured to store computer executable instructions or computer programs; a processor configured to execute the computer executable instructions or computer programs stored in the memory, to implement the code processing method of the integrated circuit provided by the embodiment of the present application.

[0008] The embodiment of the present application provides a computer readable storage medium, which stores computer executable instructions or computer programs, and is configured to be executed by a processor to implement the code processing method of the integrated circuit provided by the embodiment of the present application.

[0009] The embodiment of the present application provides a computer program product, which comprises a computer program or computer executable instructions, and the computer program or computer executable instructions are executed by a processor to implement the code processing method of the integrated circuit provided by the embodiment of the present application.

[0010] The embodiment of the present application has the following beneficial effects: By parsing the sub-fields of the port name in the source code and constructing the structured packaging unit tree, the originally discrete register transfer level port name information and the like is converted into the structured packaging unit tree with logical belonging relationship, so that the underlying physical port information can be recognized and processed by the computer program in a structured form. By encapsulating the structured packaging unit tree into a structured object by using the high-level hardware description language, the specific physical port is mapped to the object attribute in the programming language, and the hardware interface can be processed by operating the object attribute instead of directly operating the physical signal line, thereby shielding the underlying bit width, direction and other physical details. By responding to the connection instruction and combining the instantiated hardware description language module, the user-defined connection relationship carried by the connection instruction is automatically converted into specific underlying hardware description language connection code, replacing the process of manually writing a large number of signal assignment statements, reducing the number of connection code writing, and the connection code is used to indicate the signal transmission path between the sub-modules in the integrated circuit, and the connection code is the hardware description language code, which can be directly read by the electronic design automation tool, thereby improving the integrated circuit design efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0011] Figure 1 is an application mode schematic diagram of the code processing method of the integrated circuit provided by the embodiments of the present application; Figure 2 is a structural schematic diagram of an electronic device provided by the embodiments of the present application; Figure 3 is a first flow schematic diagram of the code processing method of the integrated circuit provided by the embodiments of the present application; Figure 4 is a second flow schematic diagram of the code processing method of the integrated circuit provided by the embodiments of the present application; Figure 5 is a third flow schematic diagram of the code processing method of the integrated circuit provided by the embodiments of the present application; Figure 6 is a structural schematic diagram of the structured packaging unit tree provided by the embodiments of the present application; Figure 7 is a visual schematic diagram of the structured packaging unit tree provided by the embodiments of the present application.

[0012] It should be pointed out that the "first" and "second" above are only used to distinguish different schemes, and do not represent the degree of superiority or priority in the implementation process. DETAILED DESCRIPTION

[0013] In order to make the purposes, technical solutions and advantages of the present application clearer, the following further describes the present application in conjunction with the accompanying drawings, the described embodiments should not be regarded as limitations to the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0014] In the following description, "some embodiments" are referred to, which describe a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0015] In the following description, the terms "first\second\third" are only distinguished from similar objects, and do not represent a specific order of the objects, and it can be understood that "first\second\third" can be interchanged in a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the relevant data collection and processing (for example: code data edited or input by the user) in the present application should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and within the scope of authorization of laws and regulations and the personal information subject, carry out subsequent data use and processing behavior.

[0017] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the functions of the module or unit.

[0018] 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 the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0019] Before further detailing the embodiments of the present application, the terms and terms involved in the embodiments of the present application are explained, the terms and terms involved in the embodiments of the present application are applicable to the following explanations.

[0020] 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. Electronic design automation supports various aspects of the design process, from circuit function design, logic synthesis, simulation verification to layout, achieving standardization and intelligentization of the design process. EDA is a fundamental tool for chip design. Simply put, EDA tools can manage and coordinate the work of hundreds of billions of transistors on a chip, and are essential for modern chip design and verification.

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

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

[0023] 4)Register Transfer Level (RTL) code: refers to an abstract unit centered on registers, written in hardware description languages (such as Verilog, VHDL) or specialized DSLs (such as Chisel), which can explicitly describe the transmission path, operation rules and timing trigger conditions of binary data between registers in digital systems.

[0024] 5)Lint tool: A static code analysis tool that finds errors, inconsistent styles, and potential program problems in code. It helps improve code quality and maintainability.

[0025] 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. In the electronic design automation process of the related art, module connection usually depends on manual writing of a hardware description language (such as Verilog or System Verilog) or assisted generation by a specific tool. With the rapid expansion of the scale of integrated circuit design, a hardware construction framework based on a high-level programming language has gradually become a new trend in the design field due to its high degree of abstraction and development efficiency.

[0026] However, a large number of register transfer level (RTL) codes are still retained in the current chip design ecosystem. When RTL modules are integrated into a high-level language environment for top-level interconnection, it is difficult to directly map them to structured objects (such as Bundle) in the high-level language. This means that designers must manually write a large amount of BlackBox packaging code to rebuild the interface structure, which is tedious and repetitive. Secondly, different sources of RTL modules often have inconsistent naming styles, and automated tools have difficulty in intelligently matching across these naming differences, resulting in designers still needing to write thousands of lines of assignment code for line-by-line connection at the top level, which not only is inefficient, but also easily introduces connection errors, affecting the efficiency of integrated circuit design.

[0027] Embodiments of the present application provide a code processing method of an integrated circuit, a code processing apparatus of an integrated circuit, an electronic device, and a computer readable storage medium and computer program product, which improve the efficiency of connecting signal transmission paths between modules in integrated circuit design.

[0028] The following describes an exemplary application of the electronic device provided by the embodiments of the present application. The electronic device provided by the embodiments of the present application can implement a terminal device, such as a notebook computer, a tablet computer, a desktop computer, a set-top box, a smart television, a vehicle-mounted terminal, a virtual reality (VR) device, an augmented reality (AR) device, and various types of terminals, or can be implemented as a server. The following describes exemplary applications when the electronic device is implemented as a terminal device or a server.

[0029] Reference Figure 1 , Figure 1 is an application mode schematic diagram of the code processing method of the integrated circuit provided by the embodiments of the present application; in an example, Figure 1 The server 200, the network 300, the terminal device 400, and the database 500 are involved in the example. The terminal device 400 connects the speech recognition server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0030] For example, the server 200 can be a server of an integrated circuit design platform, the terminal device 400 can be installed with an integrated circuit automatic design tool, the database 500 can store a large amount of integrated circuit related data, and the user can be a designer.

[0031] In some embodiments, in the field of integrated circuits, a user designs an integrated circuit through the terminal device 400, selects a corresponding source code through a design interface in the terminal device 400, and requests the server to obtain the source code through the network 300. The terminal device 400 calls the code processing method of the integrated circuit provided in the embodiments of the present application, constructs a structured packaging unit tree, and packages and instantiates the structured packaging unit tree to obtain a hardware description language module. The user edits the connection relationship between the sub-modules of the customized integrated circuit through the terminal device 400 to form a connection instruction, and the terminal device 400 calls the hardware description language module and the connection instruction to form a connection code. The connection code is a hardware description language code and can be directly read by an integrated circuit automatic design tool, thereby facilitating integrated circuit design.

[0032] In some embodiments, the server can be a standalone physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and basic cloud computing services such as big data and artificial intelligence platforms. The electronic device can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto. The terminal device and the server can be directly or indirectly connected through wired or wireless communication, which is not limited in the embodiments of the present application.

[0033] Referring to Figure 2 , Figure 2 is a structural schematic diagram of an electronic device provided in the embodiments of the present application. The electronic device can be Figure 1 a terminal device 400, Figure 2 The terminal device 400 shown in FIG. 1 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 through a bus system 440. It can be understood that the bus system 440 is used to realize the connection and communication between the components. In addition to the data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, all the buses are marked as the bus system 440 in Figure 2 .

[0034] The processor 410 can be an integrated circuit chip that has the processing capability of signals, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor.

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

[0036] The memory 450 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The memory 450 optionally includes one or more storage devices physically located in proximity to the processor 410.

[0037] The memory 450 includes volatile memory or non-volatile memory, and can also include both volatile and non-volatile memory. Non-volatile memory can be read only memory (ROM), and volatile memory can be random access memory (RAM). The memory 450 described in embodiments of the present application is intended to include any suitable type of memory.

[0038] In some embodiments, the memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or a subset or superset thereof, which are exemplarily illustrated below.

[0039] The operating system 451 includes system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks; The network communication module 452 is used to communicate with other electronic devices via one or more (wired or wireless) network interfaces 420, examples of which include Bluetooth, wireless compatibility authentication (WiFi), and universal serial bus (USB), etc. The presentation module 453 is used to enable presentation of information via one or more output devices 431 associated with the user interface 430 (e.g., display screen, speaker, etc.), such as a user interface for operating peripheral devices and displaying content and information. The input processing module 454 is configured to detect one or more user inputs or interactions from one or more input devices 432 and translate the detected inputs or interactions.

[0040] In some embodiments, the code processing apparatus of the integrated circuit provided by the embodiments of the present application can be implemented in software, Figure 2 The code processing apparatus 455 of the integrated circuit stored in the memory 450 is shown, which can be software in the form of programs and plug-ins, etc., including the following software modules: a data acquisition module 4551, a packaging module 4552, and a code generation module 4553. These modules are logical, and thus can be combined or further split according to the implemented functions. In Figure 2 For convenience of expression, all the above modules are shown at one time, and the functions of the individual modules will be described below.

[0041] In some embodiments, the code processing apparatus of the integrated circuit provided by the embodiments of the present application can be implemented in software,

[0042] The code processing method of the integrated circuit provided by the embodiments of the present application will be described in combination with exemplary applications and implementations of the terminal device provided by the embodiments of the present application.

[0043] The code processing method of the integrated circuit provided by the embodiments of the present application will be described below. As described above, the electronic device implementing the code processing method of the integrated circuit provided by the embodiments of the present application can be a terminal device or a server, or a combination of the two. Therefore, the execution subject of each step will not be repeated in the following description.

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

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

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

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

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

[0049] For example, the source code can be represented as: Module DeviceA(outputs [31:0]data_value, outputs data_valid); Module DeviceB(input [31:0]value_data, input vld_data).

[0050] 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).

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

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

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

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

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

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

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

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

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

[0060] 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: Module name: DeviceA Port name: data_value Physical properties: Direction: Output Bit width: 32 bits ([31:0]) Type: Vector In step 3023, the root node of the structured encapsulation unit tree is constructed.

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

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

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

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

[0065] 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).

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

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

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

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

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

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

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

[0073] 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").

[0074] 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: Define the interface class DeviceABundle as inheriting from the generic interface base class Bundle; Define the member variable data_value as a 32-bit unsigned integer and map it to the physical port data_value; Define a member variable data_valid: of type boolean (1 bit), mapped to the physical port data_valid.

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

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

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

[0078] 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: Import all classes, objects, and functions from the spinal.core package to include the hardware description primitives library for Spinal HDL. Import all classes, objects, and functions from the spinal.lib package to include the standard hardware library for Spinal HDL. Define a top-level hardware module class named MyTopLevel. Define a top-level component class MyTopLevel, which inherits from the hardware component base class (Component): Instantiating submodules (Scala): Create an object DeviceA as an instance of module DeviceA; Create an object DeviceB as an instance of module DeviceB; Create an object u_mul as an instance of the multiplier module; Connect all I / O interfaces of DeviceA to all I / O interfaces of DeviceB in a batch bidirectional manner.

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

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

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

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

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

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

[0085] Continuing with the example above, for instance, the content of the script file entered by the user could be: 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`.

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

[0087] Continuing with the examples above, for instance: 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: 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.

[0088] 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: assign DeviceB.value_data=DeviceA.data_value; `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.

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

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

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

[0092] However, the connection technology of related technologies has the following limitations in practical applications: 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.

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

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

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

[0096] 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 5The steps shown are explained. Figure 5 The entity responsible for executing the steps is Figure 1 Terminal device 400.

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

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

[0099] For example, the source code can be represented as: Module DeviceA(outputs [31:0]data_value, outputs data_valid); Module DeviceB(input [31:0]value_data, input vld_data).

[0100] 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).

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

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

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

[0104] 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: Module name: Device A Port name: data_value (data_value) Physical properties: Direction: Output Bit width: 32 bits ([31:0]) Type: Vector In step 504, a structured encapsulation unit tree is constructed.

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

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

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

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

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

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

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

[0112] 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).

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

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

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

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

[0117] 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: Define the interface class DeviceABundle as inheriting from the generic interface base class Bundle; Define the member variable data_value as a 32-bit unsigned integer and map it to the physical port data_value; Define a member variable data_valid: of type boolean (1 bit), mapped to the physical port data_valid.

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

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

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

[0121] 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: Import all classes, objects, and functions from the spinal.core package to include the hardware description primitives library for Spinal HDL. Import all classes, objects, and functions from the spinal.lib package to include the standard hardware library for Spinal HDL. Define a top-level hardware module class named MyTopLevel. Define a top-level component class MyTopLevel, which inherits from the hardware component base class (Component): Instantiating submodules (Scala): Create an object DeviceA as an instance of module DeviceA; Create an object DeviceB as an instance of module DeviceB; Create an object u_mul as an instance of the multiplier module; Connect all I / O interfaces of DeviceA to all I / O interfaces of DeviceB in a batch bidirectional manner.

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

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

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

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

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

[0127] Continuing with the example above, for instance, the content of the script file entered by the user could be: 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`.

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

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

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

[0131] Continuing with the examples above, for instance: 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: 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.

[0132] 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: assign DeviceB.value_data=DeviceA.data_value; `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.

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

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

[0135] 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: 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.

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

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

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

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

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

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

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

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

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

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

[0146] 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).

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

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

[0149] 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 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; 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; 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 construction of the structured encapsulation unit tree based on the source code includes: 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; The structured list is invoked, and child nodes are represented by subfields based on the port name. The structured encapsulation unit tree is constructed based on the child nodes and the root node.

3. The method according to claim 2, characterized in that, The process of calling the structured list, representing child nodes based on subfields of the port name, and constructing the structured encapsulation unit tree based on the child nodes and the root node includes: 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; Connecting the starting node of each tree path to the root node yields the structured encapsulation unit tree, wherein the starting node represents the first sub-field in the port name.

4. 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.

5. The method according to claim 4, 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.

6. 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.

7. 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.

8. 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; 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; 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.

9. 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 7.

10. 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 7.

Images