A digital chip IP integration method

Abstract

The application discloses a digital chip IP integration method, comprising: configuring an IP integration event table; reading port description of an original IP file through a matching rule based on the configuration in the IP integration event table, extracting input and output signals and bit width information; generating a standardized packaging file according to the matching result of the matching rule; and storing the standardized packaging file and the associated IP integration event table in an IP pool for reuse. The digital chip IP integration method provided by the application replaces manual operation with an IP integration event table and an automatic tool, shortens the IP integration period, improves the design and product opening efficiency, and solves the technical problems of low efficiency, high error rate and reuse difficulty in the prior art.

Description

Technical Field

[0001] This invention relates to the field of large-scale integrated circuit design technology, and in particular to a method for integrating digital chip IP. Background Technology

[0002] With the development of integrated circuits, especially the widespread adoption of large-scale and very-large-scale integrated circuits, digital IP, as a core component of chip design, can significantly shorten development cycles through standardized reuse. However, with the increasing complexity of IP (e.g., containing hundreds of functional ports) and the prevalence of chiplet architecture, traditional manual integration methods have exposed the following problems:

[0003] Integration is inefficient: Designers need to parse the top-level IP code (such as Verilog files) port by port and manually complete signal naming mapping, bit width matching, and timing constraint configuration. Taking an IP with 200 ports as an example, a single integration takes about 20-30 hours and requires repeated debugging.

[0004] Frequent human errors: Signal mapping deviations (such as missing interrupt signals) or lack of 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 fix them.

[0005] High reuse cost: There is a lack of unified standards for signal naming conventions, bus protocols (such as AXI4, AHB3, Wishbone) and process library adaptation (such as the difference between 5nm and 7nm PAD models) of different IPs. When reusing across projects, the adaptation layer needs to be redeveloped, resulting in a reuse efficiency of only about 50% of the theoretical value.

[0006] 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 an urgent technical problem to be solved in the industry. Summary of the Invention

[0007] In view of the above-mentioned shortcomings 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.

[0008] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0009] A method for integrating digital chip IP, comprising:

[0010] Configure the IP integration event table;

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

[0012] A standardized encapsulation file is generated based on the matching results of the matching rules;

[0013] The standardized encapsulation file and the associated IP integration event table are stored in the IP pool for reuse.

[0014] According to one aspect of the present invention, the digital chip IP integration method includes realizing data interaction and system integration among multiple standardized package files through a package reuse module.

[0015] According to one aspect of the present invention, the IP integration event table includes at least a custom integration name field, a bus field, a user-defined signal enable field, a signal interface switch field, and a port keyword field.

[0016] According to one aspect of the invention, the bus field defines multiple bus interfaces in the format of "protocol_version_quantity".

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

[0018] 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 regular expressions used to match the port naming rules, wherein the port naming rules are:

[0019] In the bus ports, the AXI protocol control section is prefixed with aw, and the AHB protocol is prefixed with H;

[0020] Interrupt ports are prefixed with int;

[0021] IO ports are prefixed with "IO".

[0022] Unconventional ports are matched using the port keyword field in the IP integration event table.

[0023] According to one aspect of the present invention, the step of reading the port description of the original IP file and extracting input / output signals and bit width information based on the configuration in the IP integration event table by matching rules includes:

[0024] Parse the original IP design file;

[0025] Load the IP integration event table;

[0026] Perform multi-level pattern matching;

[0027] Extract the bit width information and represent it parametrically.

[0028] According to one aspect of the present invention, generating a standardized encapsulation file based on the matching result includes:

[0029] Port classification and signal mapping;

[0030] Bit-width parameterization;

[0031] Port standardization and reconstruction;

[0032] Generate standardized package files.

[0033] According to one aspect of the present invention, the data transmission between multiple IP files via the encapsulation and reuse module includes:

[0034] Collect IP_wrapper port information;

[0035] Construct the multiplexer logic;

[0036] Handle protocol conversion.

[0037] 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 maintains consistency with the bit width and direction of the top-level signals.

[0038] The advantages of this invention are as follows: First, by replacing manual operations with an IP integration event table and automated tools, the IP integration cycle is shortened, improving the efficiency of design and product development, with a more significant efficiency improvement in complex IP integration. Second, standardized port classification and bit-width verification mechanisms avoid signal mapping deviations and timing omissions, greatly reducing product defects caused by integration stage errors and improving design reliability. Third, centralized routing of inter-IP data is achieved through wrapper_mux, reducing communication complexity, resulting in a clear and maintainable architecture that adapts to diverse project management needs. Finally, the processed IPs are stored in an IP pool, supporting direct cross-project calls and prohibiting manual modification, ensuring design consistency and reducing redundant development costs. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This is a flowchart illustrating a digital chip IP integration method according to the present invention.

[0041] Figure 2 This is a schematic diagram illustrating the generation of a standardized encapsulation file from the original IP file as described in this invention;

[0042] Figure 3 This is a diagram illustrating the data transmission between multiple IP files as described in this invention. Detailed Implementation

[0043] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0044] Figure 1 A flowchart illustrating a digital chip IP integration method according to this application is shown. The digital chip IP integration method includes the following steps:

[0045] Step S1: Configure the IP integration event table.

[0046] In this embodiment of the invention, the IP integration event table includes at least the following fields:

[0047] The wrapper name field (wrapper_name) supports custom configuration;

[0048] Bus field: This field includes information such as the type and quantity of communication buses. To facilitate regular expression matching, in this embodiment, the bus field is defined in the format of "protocol_version_quantity", such as AXI_4_2 and AHB_3_1, which respectively indicate that the IP has two sets of AXI4 interfaces and one set of AHB3 interfaces;

[0049] User-defined signal enable field (user): This field controls whether to generate register read / write function ports for user-defined signals.

[0050] Signal Interface Switch Field (YoN): The IP can enable or disable the relevant signal interface according to the specific configuration of this field;

[0051] Port Keyword Field (SING): This field defines the keyword for various types of ports in an IP address.

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

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

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

[0055] It is understandable that, for the convenience of defining and matching regular expressions, port naming needs to follow certain rules. The specific naming rules in this embodiment of the invention are as follows:

[0056] 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 the prefix or suffix, but they need to be unique to facilitate pattern matching.

[0057] Interrupt ports are prefixed with int;

[0058] IO ports are prefixed with "IO".

[0059] Unconventional ports (interfaces that do not follow a pattern) are matched using the port keyword field (SING) in the IP integration event table.

[0060] The specific process of reading the port description of the raw IP file and extracting input / output signals and bit width information based on the IP integrated event table includes the following steps:

[0061] Step S21: Parse the original IP design file.

[0062] The original IP design files are all defined using hardware description languages. The automated scripts will parse the original IP hardware description files (such as Verilog .v files or VHDL .vhdl files).

[0063] When parsing port declarations, for statements like `input [31:0] awaddr`, the script can accurately identify that the direction of the signal `awaddr` is input and its bit width is 32 bits (`[31:0]`). For parameter definitions, such as `parameterWIDTH = 32`, the script can also obtain the value of the bit width parameter `WIDTH`. This process can comprehensively and completely obtain the original information of the direction and bit width of all signals in the original IP file, providing basic data for subsequent consistent encapsulation.

[0064] In this embodiment of the invention, the parsing process includes extracting the port list (including signal name, direction, and bit width information) from the module declaration, for example:

[0065] module legacy_ip (

[0066] input [31:0] HADDR, / / AHB address bus

[0067] output [1:0] int_err, / / Interrupt signal

[0068] inout sdio_IO / / IO port );

[0070] Step S22: Load the IP integration event table.

[0071] In this embodiment, the loading process specifically involves parsing the key fields in the CSV-formatted IP integration event table and saving the configuration information of those fields, for example:

[0072] bus = “AHB_3_1”: A set of AHB3 interfaces;

[0073] SIGN = “err=interrupt; io=IO”: Custom signal mapping rule

[0074] YoN = “TEST=OFF”: Disable test port generation.

[0075] Step S23: Perform multi-level pattern matching.

[0076] Different patterns can be used to match the content of different fields. For protocol fields, regular expressions can be defined for matching, while the SIGN keyword can be forcibly matched.

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

[0078] Port type Matching rules Instance signal Matching results bus AHB*:^H[AZ]+ HADDR Bus address port Interruption ^int[a-z0-9_]* Int_err Interrupt port IO .*IO$ sdio_IO IO ports

[0079] Of course, for some abnormal ports, if regular expressions and forced matching still fail, designers can perform a rematch after adding SIGN rules.

[0080] Step S24: Extract bit width information and perform parameterized representation.

[0081] Specifically, it parses the bit width definition in the port declaration (e.g., [31:0] represents a bit width of 32) and converts it into a parameterized variable template, for example:

[0082] / / Original signal

[0083] output [7:0] status_IO;

[0084] / / Generate the parameterized form in IP_wrapper

[0085] output [IO_WIDTH-1:0] status_io_o; / / Orientation standardization

[0086] / / Define parameters in the module header

[0087] parameter IO_WIDTH = 8;

[0088] Step S3: Generate a standardized encapsulation file based on the matching results.

[0089] The specific process of generating standardized package files includes the following steps:

[0090] Step S31: Port classification and signal mapping.

[0091] Based on the port keyword (SING) field in the IP integration event table and the protocol naming rules, IP top-level ports are divided into the following six categories:

[0092] Bus ports: such as AXI's awaddr and AHB's HADDR;

[0093] Test port: DFT related signals;

[0094] Interrupt ports: Signals that begin with "int";

[0095] User-defined port: Register read / write interface enabled by the user flag;

[0096] I / O ports: Signals ending with I / O;

[0097] PAD port: chip physical layer interface.

[0098] By using a unified port classification and signal mapping, it is possible to ensure that the port types of different types of raw IPs are consistent with those of the ports in the generated standardized encapsulation file. This can unify the interface by shielding the underlying differences between different IPs.

[0099] For example, by grouping signals from different IPs (such as AXI4's awaddr and AHB's HADDR) into the same port category, designers do not need to concern themselves with specific protocol details; they can simply interconnect them through standardized interfaces. This process elevates IP integration from "code-level adaptation" to "functional-level interfacing," significantly reducing learning costs and integration difficulty.

[0100] Step S32: Bit width parameterization processing.

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

[0102] Simultaneously, the bit width can be dynamically configured within the encapsulation module using macro definitions or parameter passing. For example, this can be implemented using Verilog syntax as follows:

[0103] module IP_wrapper #(

[0104] parameter AXI_ADDR_WIDTH = 64,

[0105] parameter USER_DATA_WIDTH = 32 (...)

[0107] Step S33: Port standardization and reconstruction.

[0108] First, rename the ports according to their categories to ensure consistency in naming rules for ports of the same type. For example, rename all bus write address ports to wr_addr.

[0109] At the same time, the direction of the ports is uniformly adjusted. For example, the input port is given the suffix _i, and the output port is given the suffix _o (intr_i, data_o).

[0110] Step S34: Generate standardized package file.

[0111] like Figure 2 As shown, the module is named according to the integration name field (wrapper_name) in the IP integration event table (e.g., "axi_ip_wrapper"), and the IP_wrapper.v file is automatically generated. At this point, it is necessary to ensure that the filename of the generated standardized wrapper file is related to the name of the original IP file. This means that the wrapper relationship between the two should be clearly reflected, and the original IP file and the standardized wrapper file should be directly identifiable by their filenames for project management purposes.

[0112] At the same time, it is necessary to ensure that the direction of the matched signal (input / output) is consistent with the signal direction in 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 still be in the input direction in the generated standardized encapsulation file.

[0113] It should be noted that the IP_wrapper.v file generated here is the core carrier of IP pool reuse. Because its port type, naming rules and parameter definitions are completely standardized, different projects only need to modify the configuration in the event table (such as enabling / disabling certain signal categories) when calling it, without having to touch the internal IP code, thus achieving the effect of "encapsulation once, reuse multiple times".

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

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

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

[0117] Other supporting documents include bit width parameter files, process constraint files, and automatically generated documents (such as port list reports and register mapping tables). All of these files need to be stored in the IP pool for subsequent reuse.

[0118] The IP pool is a physical storage object. In this embodiment of the invention, it can be a regular 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, which allows for more granular version management of files.

[0119] The IP pool is the infrastructure for IP reuse in this invention. Through centralized storage, standardized management, and parameterized adaptation, it solves the pain points of "low efficiency, error-proneness, and difficulty in reuse" in traditional IP integration. It transforms IP from a one-time development resource into a reusable strategic asset, thereby providing a sustainable and optimized ecosystem for complex chip designs such as SoCs and Chiplet.

[0120] It is important to note that the original IP addresses in this embodiment of the invention are still stored in a separate library, and the IP pool only manages their standardized interface descriptions. This design satisfies the confidentiality requirements of IP vendors while enabling plug-and-play integration.

[0121] Step S5: Data transfer between multiple standardized encapsulated files is achieved through encapsulation and reuse modules.

[0122] like Figure 3The method of achieving data transmission between multiple standardized encapsulated files through the encapsulation and reuse module specifically includes the following steps:

[0123] Step S51: Collect IP_wrapper port information.

[0124] In summary, the embodiments of the present invention can use automated scripts to read the port list of each IP_wrapper file, focusing on extracting the bus signals, including address, data, and control signals, and identifying the protocol type followed by these bus signals, such as whether it is the AXI4 protocol or the AHB3 protocol.

[0125] Step S52: Construct the multiplexer logic.

[0126] Based on the number and type of buses defined in the bus field of the IP integration event table, signal routing logic is generated. Regarding bus aggregation, bus requests from multiple master devices (such as CPUs, DMA controllers, etc.) are integrated onto a single bus. Taking address mapping as an example, an address decoder maps the address space of the master device to the corresponding slave device (such as UART, SPI, etc.).

[0127] If the transmission of signals across clock domains is involved, such as when different IP modules use clocks of different frequencies, a clock domain crossover (CDC) unit, such as an asynchronous FIFO, needs to be inserted to ensure the correct transmission of data between different clock domains.

[0128] Step S53: Process protocol conversion.

[0129] When IPs with different protocols need to be interconnected, such as when an IP with the AXI4 protocol communicates with an IP with the AHB3 protocol, protocol conversion logic is automatically generated.

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

[0131] On the other hand, timing conversion is completed to achieve the conversion between burst transmission and single-cycle transmission modes between different protocols.

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

[0133] The advantages of this invention are as follows: First, by replacing manual operations with event tables and automation tools, the IP integration cycle is shortened, improving the efficiency of design and product development, with a more significant efficiency improvement in complex IP integration. Second, the standardized port classification and bit-width verification mechanism avoids signal mapping deviations and timing omissions, greatly reducing product defects caused by integration stage errors and improving design reliability. Third, the wrapper_mux enables centralized routing of data between IPs, reducing communication complexity, resulting in a clear and maintainable architecture that adapts to diverse project management needs. Finally, the processed IPs are stored in an IP pool, supporting direct cross-project calls and prohibiting manual modification, ensuring design consistency and reducing redundant development costs. In summary, the digital chip IP integration method of this application solves the problems of low efficiency, high error rate, and difficulty in reuse in existing technologies, and has value for industrial application.

[0134] 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 variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for integrating digital chip IP, characterized in that, include: Configure the IP integration event table, which includes at least a custom integration name field, a bus field, a user-defined signal enable field, a signal interface switch field, and a port keyword field. Based on the configuration in the IP integration event table, the port description of the original IP file is read through multi-level pattern matching rules, the input and output signals and bit width information are extracted, and converted into parameterized variable templates; The multi-level pattern matching rules include: matching port naming rules using defined regular expressions, and performing forced matching on the content of port keyword fields; and for abnormal ports that still fail to match using regular expressions and forced matching, re-matching is performed after supplementing the port keyword rules; the port naming rules are as follows: for bus ports, the AXI protocol control part is prefixed with aw, the AHB protocol is prefixed with H; interrupt ports are prefixed with int; and IO ports are suffixed with IO. Based on the matching results of the matching rules, the ports are standardized and reconstructed, including port renaming, direction standardization and bit width parameterization, to generate standardized encapsulation files; The standardized encapsulation file and the associated IP integration event table are stored in the 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 achieving data interaction and system integration between multiple standardized package files through a package reuse module.

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

4. The digital chip IP integration method according to claim 1, characterized in that, The user-defined signal enable field controls whether to generate register read / write function ports for user-defined signals.

5. The digital chip IP integration method according to claim 1, characterized in that, The process of reading the port description of the original IP file and extracting input / output signals and bit width information based on the configuration in the IP integration event table includes: Parse the original IP design file; Load the IP integration event table; Perform multi-level pattern matching; Extract the bit width information and represent it parametrically.

6. The digital chip IP integration method according to claim 1, characterized in that, The standardized package file generated based on the matching results includes: Port classification and signal mapping; Bit-width parameterization; Port standardization and reconstruction; Generate standardized package files.

7. The digital chip IP integration method according to claim 2, characterized in that, The process of achieving data interaction and system integration among multiple standardized encapsulated files through the encapsulation and reuse module includes: Collect IP_wrapper port information; Construct the multiplexer logic; Handle protocol conversion.

8. The digital chip IP integration method according to any one of claims 1 to 7, 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 maintains consistency with the bit width and direction of the top-level signals.

Images