Digital chip IP integration method

Abstract

The invention discloses a digital chip IP integration method. The method comprises the following steps: configuring an IP integration event table; reading port description of an original IP file through a matching rule based on configuration in the IP integration event table, and extracting input and output signals and bit width information; generating a standardized packaging file according to a matching result of the matching rule; and storing the standardized packaging file and the associated IP integration event table into an IP pool for reuse. According to the digital chip IP integration method provided by the invention, manual operation is replaced by the IP integration event table and the automatic tool, the IP integration period is shortened, the efficiency of design and product opening is improved, and the technical problems of low efficiency, high error rate and difficulty in reuse in the prior art are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of large-scale integrated circuit design, and in particular to a digital chip IP integration method. Background Art

[0002] With the development of integrated circuits, especially the popularity of large-scale and ultra-large-scale integrated circuits, digital IP, as a core component of chip design, can significantly shorten the development cycle through standardized reuse. However, with the increasing complexity of IP (such as including hundreds of functional ports) and the prevalence of chiplet architecture, traditional manual integration methods have exposed the following problems: Inefficient integration: Designers must parse the top-level IP code (such as Verilog files) port by port, manually completing signal naming, bit width matching, and timing constraint configuration. For example, for an IP with 200 ports, a single integration takes approximately 20-30 hours, requiring repeated debugging.

[0003] Frequent human errors: Signal mapping deviations (such as missing interrupt signals) or missing timing constraints (such as not setting clock jitter parameters) lead to functional abnormalities. According to industry statistics, such problems account for more than 35% of SoC verification defects, requiring an additional 15%-20% of the R&D cycle to locate and repair them.

[0004] High reuse costs: There is a lack of unified standards for signal naming conventions, bus protocols (such as AXI4, AHB3, and Wishbone), and process library adaptation (such as the differences between 5nm and 7nm PAD models) for different IPs. Cross-project reuse requires the redevelopment of adaptation layers, resulting in a reuse efficiency of only about 50% of the theoretical value.

[0005] Therefore, providing a full-process IP integration method based on parameterized configuration, automated processing and secure reuse to solve the problems of low efficiency, high error rate and difficulty in reuse in existing technologies has become a technical problem that the industry urgently needs to solve. Summary of the Invention

[0006] In view of the above-mentioned deficiencies in the current field of integrated circuit design, the present invention provides a digital chip IP integration method that can solve the technical problems of low efficiency, high error rate and difficulty in reuse in the prior art.

[0007] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: A digital chip IP integration method, comprising: Configure IP integration event table; Based on the configuration in the IP integration event table, read the port description of the original IP file through matching rules to extract input and output signals and bit width information; Generate a standardized package file according to the matching result of the matching rule; The standardized encapsulation file and the associated IP integration event table are stored in an IP pool for reuse.

[0008] According to one aspect of the present invention, the digital chip IP integration method includes realizing data interaction and system integration between multiple standardized package files through a package reuse module. According to one aspect of the present invention, the IP integration event table at least includes a user-defined integration name field, a bus field, a user-defined signal enable field, a signal interface switch field, and a port keyword field.

[0009] According to one aspect of the present invention, the bus field defines multiple bus interfaces in the format of "protocol_version_number".

[0010] According to one aspect of the present invention, the user-defined signal enable field controls whether to generate a register read / write function port for the user-defined signal.

[0011] According to one aspect of the present invention, in the process of reading the port description of the original IP file by matching rules, the matching rules are to match the naming rules of the ports by regular expressions, and the naming rules of the ports are: In the bus port, the AXI protocol control part is prefixed with aw, and the AHB protocol is prefixed with H; Interrupt ports are prefixed with int; IO ports are suffixed with IO; Unconventional ports are matched using the port keyword field in the IP integration event table.

[0012] According to one aspect of the present invention, the step of reading the port description of the original IP file by matching rules based on the configuration in the IP integration event table to extract the input and output signals and bit width information includes: Parse the original IP design file; Load IP integration event table; Perform multi-level pattern matching; Extract bit width information and perform parameterized representation.

[0013] According to one aspect of the present invention, generating a standardized package file according to the matching result includes: Port classification and signal mapping; Bit width parameterization; Port standardization reconstruction; Generate standardized packaging files.

[0014] According to one aspect of the present invention, the data transmission between multiple IP files through the encapsulation and multiplexing module includes: Collect IP_wrapper port information; Build multiplexer logic; Handles protocol conversion.

[0015] According to one aspect of the present invention, the standardized encapsulation file uniformly classifies IP ports into bus ports, test ports, interrupt ports, user-defined ports, IO ports and PAD ports, and keeps the bit width and direction consistent with the top-level signals.

[0016] Advantages of the implementation of the present invention: First, by replacing manual operations with IP integration event tables and automated tools, the IP integration cycle is shortened, the efficiency of design and product development is improved, and the efficiency improvement is more obvious when integrating complex IPs. Secondly, the standardized port classification and bit width verification mechanism avoids signal mapping deviations and timing omissions, greatly reducing product defects caused by errors in the integration phase and improving design reliability. Thirdly, through wrapper_mux, data routing between IPs is achieved, which reduces communication complexity, has a clear and easy-to-maintain architecture, and adapts to diverse project management needs. Finally, the processed IP is stored in the IP pool, supports direct calls across projects, and prohibits manual modifications, ensuring design consistency and reducing duplicate development costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 A schematic flow chart of a digital chip IP integration method according to the present invention; Figure 2 This is a schematic diagram of generating a standardized encapsulation file from an original IP file according to the present invention; Figure 3 This is a diagram illustrating data transmission between multiple IP files according to the present invention. DETAILED DESCRIPTION

[0019] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0020] Figure 1A flow chart of a digital chip IP integration method of the present application is shown, and the digital chip IP integration method includes the following steps: Step S1: Configure the IP integration event table.

[0021] In the embodiment of the present invention, the IP integration event table includes at least the following fields: Integration name field (wrapper_name): This field supports custom configuration; Bus field (bus): This field contains information such as the communication bus type and number. To facilitate regular expression matching, in this embodiment, the bus field is defined in the form of "protocol_version_number". For example, AXI_4_2 and AHB_3_1 indicate that the IP has two AXI4 interfaces and one AHB3 interface respectively. User-defined signal enable field (user): This field controls whether to generate register read and write function ports for user-defined signals.

[0022] Signal interface switch field (YoN): The IP can open or close the relevant signal interface according to the specific configuration of this field; Port keyword field (SING): This field defines the keywords for various types of ports in IP.

[0023] In the embodiment of the present invention, the IP integration event table is a table file in csv format. Of course, it can also be stored in other formats as long as the relevant tools support the format.

[0024] Step S2: Based on the configuration in the IP integration event table, the port description of the original IP file is read through the matching rules to extract the input and output signals and bit width information.

[0025] In the embodiment of the present invention, after reading the port description information of the original IP file, the relevant configuration information can be obtained by performing keyword matching through regular expressions according to the naming rules of the port field.

[0026] It is understood that to facilitate the definition and matching of regular expressions, the naming of ports needs to follow certain rules. The naming rules in the embodiment of the present invention are specifically as follows: In the bus port, the AXI protocol control part is prefixed with aw, such as awaddr for write address and awsize for write size; the AHB protocol is prefixed with H, such as HADDR for address; other types of protocols also use the same method to set prefixes or suffixes, but they need to be unique to facilitate pattern matching; Interrupt ports are prefixed with int; IO ports are suffixed with IO; Unconventional ports (interfaces that do not conform to the rules) are matched using the port keyword field (SING) in the IP integration event table.

[0027] The specific process of reading the port description of the original IP file and extracting the input and output signals and bit width information based on the IP integration event table includes the following steps: Step S21: Parse the original IP design file.

[0028] The original IP design files are defined in hardware description language, and the automated script will parse the original IP hardware description files (such as Verilog .v files or VHDL .vhdl files).

[0029] When parsing port declarations, for statements like "input [31:0] awaddr," the script accurately identifies the direction of the signal "awaddr" as input and its bit width as 32 bits ([31:0]). For parameter definitions, such as "parameterWIDTH = 32," the script also retrieves the value of the bit width parameter "WIDTH." This process comprehensively and without omission obtains the original information on the direction and bit width of all signals in the original IP file, providing essential data for subsequent consistent packaging.

[0030] In the embodiment of the present invention, the parsing process includes extracting the port list (including information such as signal name, direction, and bit width) in the module declaration, for example: module legacy_ip ( input [31:0] HADDR, / / AHB address bus output [1:0] int_err, / / interrupt signal inout sdio_IO / / IO port ); Step S22: Load the IP integration event table.

[0031] For this embodiment, the loading process specifically involves parsing the key fields in the CSV format IP integration event table and saving the configuration information of the fields, for example: bus = "AHB_3_1": a set of AHB3 interfaces; SIGN = "err=interrupt; io=IO": custom signal mapping rules YoN = "TEST=OFF": Turn off test port generation Step S23: Perform multi-level pattern matching.

[0032] Different patterns are matched on the contents of different fields. For protocol fields, regular expressions can be defined for matching, and for SIGN keywords, forced matching can be performed.

[0033] For example, in the following table: for a bus with an AHB port type, the regular expression used for matching can be "^H[AZ]+".

[0034] Port Type Matching rules Instance Signal Matching results bus AHB*:^H[AZ]+ HADDR Bus address port Interrupt ^int[a-z0-9_]* Int_err Interrupt port IO .*IO$ sdio_IO IO ports Of course, for some abnormal ports, if regular expressions and forced matching are still unsuccessful, designers can re-match after adding SIGN rules.

[0035] Step S24: extracting the bit width information and performing parameterized representation.

[0036] Specifically, the bit width definition in the port declaration is parsed (e.g. [31:0] indicates a bit width of 32) and converted into a parameterized variable template, for example: / / Original signal output [7:0] status_IO; / / Generate parameterized form in IP_wrapper output [IO_WIDTH-1:0] status_io_o; / / Direction standardization / / Define parameters in the module header parameter IO_WIDTH = 8; Step S3: Generate a standardized packaging file based on the matching results.

[0037] The specific process of generating standardized packaging files includes the following steps: Step S31: Port classification and signal mapping.

[0038] Based on the port keyword field (SING) in the IP integration event table and the protocol naming rules, IP top-level ports are divided into the following six categories: Bus port: such as awaddr of AXI and HADDR of AHB; Test port: DFT related signal; Interrupt port: signal starting with int; User-defined port: register read and write interface enabled by the user flag; IO port: a signal ending with IO; PAD port: chip physical layer interface.

[0039] Through unified port classification and signal mapping, the type consistency of ports in different types of original IP and the generated standardized encapsulation files can be ensured, which can unify the interface by shielding the underlying differences between different IPs.

[0040] For example, by grouping signals from different IPs (such as AXI4's awaddr and AHB's HADDR) into the same port category, designers no longer need to worry about specific protocol details and can simply connect through standardized interfaces. This process elevates IP integration from "code-level adaptation" to "function-level docking," significantly reducing learning costs and integration difficulty.

[0041] Step S32: bit width parameterization processing.

[0042] Manage the bit width uniformly by declaring function parameter variables. For example, declare parameter BUS_WIDTH = 32.

[0043] At the same time, the bit width is dynamically configured in the encapsulation module by using macro definition or parameter passing. For example, it can be implemented as follows using Verilog syntax: module IP_wrapper #( parameter AXI_ADDR_WIDTH = 64, parameter USER_DATA_WIDTH = 32 )(...) Step S33: Port standardization reconstruction.

[0044] First, rename the ports according to their types to ensure consistent naming conventions for ports of the same type. For example, rename all bus write address ports to wr_addr.

[0045] At the same time, the directions of the ports are uniformly adjusted. For example, the input port is suffixed with _i, and the output port is suffixed with _o (intr_i, data_o).

[0046] Step S34: Generate a standardized packaging file.

[0047] like Figure 2 As shown, the module is named according to the integration name field (wrapper_name) in the IP integration event table (for example, "axi_ip_wrapper") and the IP_wrapper.v file is automatically generated. At this point, it is important to ensure that the name of the generated standardized wrapper file matches the name of the original IP file. This ensures that the encapsulation relationship between the two is clearly visible and that the original IP file and the standardized wrapper file can be directly identified based on the file name for easier project management.

[0048] Also, ensure that the direction (input / output) of the matched signal remains consistent with that of the original IP file. Manual modification is prohibited unless otherwise specified in the IP integration event table. For example, a signal defined as input clk in the original IP file must remain input in the generated standardized wrapper file.

[0049] It should be noted that the IP_wrapper.v file generated here is the core carrier of IP pool reuse. Since its port type, naming rules, and parameter definitions are completely standardized, when calling different projects, you only need to modify the configuration in the event table (such as enabling / disabling certain signal categories) without touching the internal code of the IP, thus achieving the effect of "one-time packaging, multiple reuse".

[0050] Step S4: storing the generated standardized encapsulation file and the associated IP integration event table into the IP pool for reuse.

[0051] In the embodiment of the present invention, the generated standardized encapsulated module file (IP_wrapper) contains key information such as uniformly classified ports, bit width definitions, and timing logic.

[0052] At the same time, the IP integration event table is a CSV format configuration file that records parameters such as the IP's bus type, signal enable status, and custom keywords.

[0053] Other supporting files, including bit width parameter files, process constraint files, and automatically generated documents (such as port list reports, register mapping tables), etc. These files need to be stored in the IP pool so that they can be reused later.

[0054] The IP pool is a physical storage object. In this embodiment, it can be a standard file system, a database storage solution (such as MySQL), an enterprise-level document management system (such as SharePoint / Confluence), or a cloud storage solution (such as AWS S3 / Azure Blob). Of course, a version control system (such as Git / GitLab) can also be used to provide more detailed version management for files.

[0055] The IP pool is the infrastructure for IP reuse in this invention. Through centralized storage, standardized management, and parameterized adaptation, it addresses the pain points of traditional IP integration: low efficiency, prone to errors, and difficulty in reuse. It transforms IP from a one-time development resource into a reusable strategic asset, providing a sustainable and optimized ecosystem for complex chip designs such as SoCs and chiplets.

[0056] It should be noted that the original IP in the embodiment of the present invention is still stored in an independent library, and the IP pool only manages its standardized interface description. This design not only meets the confidentiality requirements of the IP supplier, but also enables plug-and-play integration.

[0057] Step S5: realizing data transmission between multiple standardized encapsulated files through the encapsulation and multiplexing module.

[0058] like Figure 3 The method of implementing data transmission between multiple standardized encapsulated files through the encapsulation and multiplexing module specifically includes the following steps: Step S51: Collect IP_wrapper port information.

[0059] In summary, the embodiment of the present invention can read the port list of each IP_wrapper file through an automated script, focus on extracting the bus type signals therein, including address, data, control signals, etc., and identify the protocol type followed by these bus signals, such as AXI4 protocol or AHB3 protocol.

[0060] Step S52: Construct multiplexer logic.

[0061] Signal routing logic is generated based on the number and type of buses defined in the bus field in the IP integration event table. Bus aggregation consolidates bus requests from multiple master devices (such as CPUs and DMA controllers) onto a single bus. For example, address mapping uses an address decoder to map the address space of a master device to the corresponding slave device (such as a UART or SPI).

[0062] If cross-clock domain signal transmission is involved, for example, different IP modules use clocks of different frequencies, a clock domain crossing (CDC) unit, such as an asynchronous FIFO, needs to be inserted to ensure the correct transmission of data between different clock domains.

[0063] Step S53: Processing protocol conversion.

[0064] When IPs of different protocols need to be interconnected, for example, when IPs of AXI4 protocol communicate with IPs of AHB3 protocol, protocol conversion logic is automatically generated.

[0065] On the one hand, signal mapping is performed to convert the write address channel signals in the AXI4 protocol (such as awaddr, awlen, etc.) into signals corresponding to the AHB protocol (such as HADDR, HSIZE).

[0066] On the other hand, the timing conversion is completed to realize the conversion between burst transmission (Burst) and single-cycle transmission mode between different protocols.

[0067] The above steps achieve efficient and reliable data transmission between multiple IP files through a series of operations such as standardized packaging, building interconnected modules, and parameterized configuration reuse.

[0068] The advantages of the implementation of the present invention are as follows: First, by replacing manual operations with event tables and automated tools, the IP integration cycle is shortened, the efficiency of design and product development is improved, and the efficiency improvement is more obvious when complex IPs are integrated. Secondly, the standardized port classification and bit width verification mechanism avoids signal mapping deviations and timing omissions, greatly reduces product defects caused by errors in the integration phase, and improves design reliability. Thirdly, through wrapper_mux, data between IPs is centrally routed, communication complexity is reduced, the architecture is clear and easy to maintain, and it adapts to diverse project management needs. Finally, the processed IP is stored in the IP pool, which supports direct calls across projects and prohibits manual modifications, ensuring design consistency and reducing repeated development costs. In short, the digital chip IP integration method of the present application solves the problems of low efficiency, high error rate and difficulty in reuse in the prior art, and has the value of industrial application.

[0069] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A digital chip IP integration method, characterized in that: include: Configure IP integration event table; Based on the configuration in the IP integration event table, read the port description of the original IP file through matching rules to extract input and output signals and bit width information; Generate a standardized package file according to the matching result of the matching rule; The standardized encapsulation file and the associated IP integration event table are stored in an IP pool for reuse.

2. The digital chip IP integration method according to claim 1, characterized in that: The digital chip IP integration method includes realizing data interaction and system integration among a plurality of the standardized packaging files through a packaging and reuse module.

3. The digital chip IP integration method according to claim 1, characterized in that: The IP integration event table at least includes a custom integration name field, a bus field, a user-defined signal enable field, a signal interface switch field, and a port keyword field.

4. The digital chip IP integration method according to claim 3, characterized in that: The bus field defines multiple bus interfaces in the format of "protocol_version_number".

5. The digital chip IP integration method according to claim 3, characterized in that: The user-defined signal enable field controls whether to generate a register read and write function port for the user-defined signal.

6. The digital chip IP integration method according to claim 1, characterized in that: In the process of reading the port description of the original IP file by matching rules, the matching rules are to match the port naming rules by regular expressions, and the port naming rules are: In the bus port, the AXI protocol control part is prefixed with aw, and the AHB protocol is prefixed with H; Interrupt ports are prefixed with int; IO ports are suffixed with IO; Unconventional ports are matched using the port keyword field in the IP integration event table.

7. The digital chip IP integration method according to claim 1, characterized in that: The step of reading the port description of the original IP file based on the configuration in the IP integration event table by matching rules and extracting the input and output signals and bit width information includes: Parse the original IP design file; Load IP integration event table; Perform multi-level pattern matching; Extract bit width information and perform parameterized representation.

8. The digital chip IP integration method according to claim 1, characterized in that: Generating a standardized package file according to the matching result includes: Port classification and signal mapping; Bit width parameterization; Port standardization reconstruction; Generate standardized packaging files.

9. The digital chip IP integration method according to claim 2, characterized in that: The data interaction and system integration between the plurality of standardized encapsulation files achieved through the encapsulation and reuse module includes: Collect IP_wrapper port information; Build multiplexer logic; Handles protocol conversion.

10. The digital chip IP integration method according to any one of claims 1 to 9, characterized in that: The standardized encapsulation file uniformly classifies IP ports into bus ports, test ports, interrupt ports, user-defined ports, IO ports, and PAD ports, and keeps the bit width and direction consistent with the top-level signals.

Images