Chip design method based on digital chip IP integration

Abstract

The invention discloses a chip design method based on digital chip IP integration. The method comprises the following steps: setting specifications; architecture design: designing a chip structure according to the specification; the writing module is used for performing RTL writing based on a chip structure, the RTL writing comprises digital IP integration, and specifically, an IP integration event table is configured; 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; storing the standardized packaging file and the associated IP integration event table into an IP pool for multiplexing; function simulation: verifying a chip function; and logic synthesis: physically synthesizing the verified chip. According to the chip design method based on digital chip IP integration, manual operation is replaced with the IP integration event table and the automatic tool, the efficiency of design and product opening is improved, and the technical problems that in the prior art, efficiency is low, the error rate is high and reuse is difficult are solved.

Description

TECHNICAL FIELD

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

[0002] With the increasing complexity of chip design, digital IP integration has become a key link in modern SoC development.

[0003] However, the traditional IP integration method has significant defects: first, the interface naming, protocol standards and parameter definitions of IP from different suppliers differ greatly, resulting in low efficiency and errors in manual adaptation; second, there is a lack of unified IP packaging and reuse mechanism, making cross-project reuse difficult and prolonging the design cycle; in addition, data interaction between heterogeneous IPs usually relies on manual writing of protocol conversion logic, increasing the complexity of system integration.

[0004] In the prior art, although some tools support automatic packaging of IP, they still cannot realize standardized integration from specification setting to logic synthesis, especially in terms of multi-protocol compatibility, parameterized configuration and testability design. SUMMARY

[0005] In view of the above problems in the field of integrated circuit design, the present application provides an efficient and scalable digital chip design method to solve the problems of standardization, automation and reusability in IP integration, thereby improving the efficiency and quality of chip development.

[0006] To achieve the above-mentioned purpose, the embodiments of the present application adopt the following technical solutions:

[0007] A method for designing a digital chip, comprising:

[0008] specification setting;

[0009] architecture design, designing a chip structure according to the specification;

[0010] module writing, writing RTL based on the chip structure, the RTL writing including digital IP integration, specifically, configuring an IP integration event table; based on the configuration in the IP integration event table, reading port descriptions of original IP files through matching rules, extracting input and output signals and bit width information; generating a standardized packaging file according to the matching results of the matching rules; storing the standardized packaging file and the associated IP integration event table in an IP pool for reuse;

[0011] function simulation, verifying the function of the chip;

[0012] logic synthesis, performing physical synthesis on the verified chip.

[0013] According to one aspect of the present application, the RTL writing includes realizing data interaction and system integration among multiple standardized package files through a package multiplexing module.

[0014] According to one aspect of the present application, the realizing data interaction and system integration among multiple standardized package files through a package multiplexing module includes:

[0015] collecting IP_wrapper port information;

[0016] constructing a multiplexer logic;

[0017] processing protocol conversion.

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

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

[0020] According to one aspect of the present application, the user custom signal enable field controls whether to generate a register read-write function port for a user custom signal.

[0021] According to one aspect of the present application, in the process of reading port description of an original IP file through matching rules, the matching rules are matching naming rules of ports through regular expressions, and the naming rules of the ports are:

[0022] In a bus port, an AXI protocol control part is prefixed with "aw", and an AHB protocol is prefixed with "H";

[0023] An interrupt port is prefixed with "int";

[0024] An IO port is suffixed with "IO";

[0025] An irregular port is matched through the port keyword field in the IP integration event table.

[0026] According to one aspect of the present application, based on the configuration in the IP integration event table, reading port description of an original IP file through matching rules, and extracting input and output signals and bit width information include:

[0027] parsing an original IP design file;

[0028] loading an IP integration event table;

[0029] performing multi-level pattern matching;

[0030] Extracting bit width information and parameterizing representation;

[0031] According to one aspect of the present application, the generating a standardized package file according to the matching result comprises:

[0032] Port classification and signal mapping;

[0033] Bit width parameterization processing;

[0034] Port standardization reconstruction;

[0035] Generating a standardized package file.

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

[0037] Advantages of the present application: first, by replacing manual operation with IP integration event table and automation tools, the IP integration period is shortened, the design and product development efficiency is improved, and the efficiency is improved more obviously in complex IP integration. Second, the standardized port classification and bit width checking mechanism avoids signal mapping deviation and timing omission, greatly reduces product defect problems caused by integration stage errors, and improves design reliability. Third, the wrapper_mux realizes IP data centralized routing, reduces communication complexity, and the architecture is clear and easy to maintain, which adapts to diversified project management needs. Finally, the processed IP is stored in the IP pool, supports direct calling across projects, and prohibits manual modification, which ensures design consistency and reduces repeated development cost. BRIEF DESCRIPTION OF DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments, the drawings needed to be used in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0039] Figure 1 The flowchart of the writing module described in the present application;

[0040] Figure 2 The schematic diagram of generating a standardized package file from an original IP file described in the present application;

[0041] Figure 3 The data transmission view between multiple IP files described in the present application;

[0042] Figure 4A flowchart of a chip design method based on digital chip IP integration according to the present application;

[0043] Figure 5 A multi-scene reuse method flowchart of a chip design method based on digital chip IP integration according to the present application;

[0044] Figure 6 A detailed flowchart of a multi-scene reuse method of a chip design method based on digital chip IP integration according to the present application. DETAILED DESCRIPTION

[0045] The technical solutions in the embodiments will be described clearly and completely below with reference to the drawings in the embodiments. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0046] Embodiment one

[0047] As shown in the flowchart of a chip design method based on digital chip IP integration according to the present application, the following steps are included: Figure 4

[0048] Step S1: specification setting;

[0049] Step S11: market-driven specification decomposition: using the QFD (quality function deployment) method to convert market demand into technical parameters;

[0050] Step S12: IP selection constraint library: in the embodiment, a process-IP association matrix is established to automatically filter incompatible options:

[0051]

[0052] Step S13: testability requirement injection: in the embodiment, DFT golden rules are defined in the specification stage:

[0053]

[0054] Step S2: architecture design;

[0055] Step S21: topology automatic generation: in the embodiment, Kahn algorithm is used for task-level pipeline design:

[0056]

[0057]

[0058] ​Output: Generate SystemC TLM model to verify bandwidth matching

[0059] Step S22: Intelligent division of power consumption domain: In this embodiment, a clustering algorithm is used to analyze signal activity:

[0060] from sklearn.cluster import KMeans

[0061] kmeans=KMeans(n_clusters=3).fit(power_profile)

[0062] power_domains=kmeans.labels_

[0063] Step S23: Pre-synthesis of clock tree: In this embodiment, a virtual clock buffer is inserted in the architecture stage:

[0064] generate if(CLK_DOMAIN=="high_speed")begin

[0065] clk_buffer#(.FANOUT(16))u_buf(clk_in,clk_out);

[0066] end endgenerate

[0067] Step S3: Writing a module;

[0068] Figure 1 A flowchart of a chip design method based on digital chip IP integration according to the present application is shown, which includes the following steps of writing a module, writing RTL based on chip structure:

[0069] Step S31: Configuring an IP integration event table.

[0070] In this embodiment, the IP integration event table at least contains the following fields:

[0071] The wrapper_name field: This field supports custom configuration;

[0072] The bus field: This field includes information such as communication bus type and quantity. In order to facilitate regular expression matching, in this embodiment, the bus field is defined in the form of "protocol_version_quantity", such as AXI_4_2 and AHB_3_1, which respectively represent two sets of AXI4 interfaces and one set of AHB3 interfaces of the IP;

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

[0074] Signal interface switch field (YoN): The IP can open or close the relevant signal interface according to the specific configuration of this field;

[0075] Port keyword field (SING): This field defines the keywords of various types of ports in the IP.

[0076] In the embodiment, 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 related tools support the format.

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

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

[0079] It can be understood that, for the convenience of definition and matching of regular expressions, the naming of the port needs to follow certain rules. In the embodiment, the naming rules are as follows:

[0080] In the bus port, the AXI protocol control part is prefixed with aw, such as awaddr indicating write address and awsize indicating write size; the AHB protocol is prefixed with H, such as HADDR indicating address; other types of protocols also use the same way to set prefix or suffix, but need to meet the uniqueness to facilitate pattern matching;

[0081] The interrupt port is prefixed with int;

[0082] The IO port is suffixed with IO;

[0083] The irregular port (interface not conforming to the rule) is matched through the port keyword field (SING) in the IP integration event table.

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

[0085] Step S321: Analyze the original IP design file.

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

[0087] 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 `parameter WIDTH = 32`, the script can also obtain the value of the bit width parameter `WIDTH`. This process comprehensively and completely obtains the original information on the direction and bit width of all signals in the original IP file, providing foundational data for subsequent consistent encapsulation.

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

[0089]

[0090] Step S322: Load the IP integration event table.

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

[0092] bus="AHB_3_1": A set of AHB3 interfaces;

[0093] SIGN="err = interrupt; io = IO": Custom signal mapping rule

[0094] YoN="TEST="OFF": Disable test port generation

[0095] Step S323: Perform multi-level pattern matching.

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

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

[0098] Port type Match rule Instance signal Match result Bus AHB: :H[A-Z]+ HADDR Bus address port Interrupt ^int[a-z0-9_]+ Int_err Interrupt port IO .*IO$ sdio_IO IO port

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

[0100] Step S324: Extract bit width information and parameterize representation.

[0101] Specifically, the bit width definition in the port declaration (such as [31:0] representing bit width 32) is parsed and converted into a parameterized variable template, for example:

[0102] / / original signal

[0103] output[7:0] status_IO;

[0104] / / generate parameterized form in IP_wrapper

[0105] output[IO_WIDTH-1:0] status_io_o; / / direction normalization

[0106] / / define parameters in module header

[0107] parameter IO_WIDTH = 8;

[0108] Step S33: Generate standardized packaging file according to matching result.

[0109] The specific process of generating a standardized packaging file includes the following steps:

[0110] Step S331: Port classification and signal mapping.

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

[0112] Bus port: such as awaddr of AXI, HADDR of AHB;

[0113] Test port: DFT related signals;

[0114] Interrupt port: signals starting with int;

[0115] User-defined port: register read-write interface enabled by the user flag;

[0116] IO port: signals ending with IO;

[0117] PAD port: chip physical layer interface.

[0118] Through unified port classification and signal mapping, the consistency of the types of ports in the original IP of different types and the generated standardized packaging file can be ensured, so that the underlying differences of different IPs can be shielded to unify the interface.

[0119] For example, by classifying different IP signals (such as awaddr of AXI4 and HADDR of AHB) under the same category port, designers do not need to pay attention to specific protocol details, and only need to complete interconnection through a standardized interface. This process upgrades IP integration from "code-level adaptation" to "function-level docking", greatly reducing learning cost and integration difficulty.

[0120] Step S332: bit width parameterization processing.

[0121] The bit width is uniformly managed by declaring a function parameter variable. For example, parameter BUS_WIDTH = 32 is declared.

[0122] Meanwhile, the bit width is dynamically configured in the packaging module by using macro definition or parameter passing. For example, the following is achieved by Verilog syntax:

[0123]

[0124]

[0125] Step S333: port standardization reconstruction.

[0126] First, the ports are renamed according to the categories of the ports, to ensure that the naming rules of the same category ports are consistent. For example, all bus write address ports are uniformly named as wr_addr.

[0127] Meanwhile, the direction of the port is uniformly adjusted, for example, the input port is added with suffix _i, and the output port is added with suffix _o (intr_i, data_o).

[0128] Step S334: generating a standardized packaging file.

[0129] As shown in Figure 2 , the module is named according to the integration name field (wrapper_name) field (such as "axi_ip_wrapper") in the IP integration event table, and the IP_wrapper.v file is automatically generated. At this time, it is necessary to ensure that the file name of the generated standardized packaging file and the name of the original IP file are related, that is, it can reflect the packaging relationship between the two, and the IP original file and the standardized packaging file can be directly identified according to the file name, so as to facilitate project management.

[0130] Meanwhile, it is necessary to ensure that the direction (input / output) of the matched signal is consistent with the direction of the signal in the original IP file. If there is no special configuration in the IP integration event table, manual modification is prohibited. For example, the signal defined as input clk in the original IP file must still be in the input direction in the generated standardized packaging file.

[0131] Note that the IP_wrapper.v file generated here is the core carrier of IP pool reuse. Since its port type, naming rules, and parameter definition are fully standardized, different projects only need to modify the configuration in the event table (such as enabling / disabling certain signal categories) when calling, without touching the IP internal code, thereby achieving the effect of "one encapsulation, multiple reuse".

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

[0133] In this embodiment, the generated standardized encapsulation module file (IP_wrapper) contains unified classified ports, bit width definition, and timing logic, etc.

[0134] Meanwhile, the IP integration event table is a CSV format configuration file, which records the bus type, signal enable state, and custom keywords, etc. parameters of the IP.

[0135] Other supporting files, including bit width parameter files, process constraint files, and automatically generated documents (such as port list reports, register mapping tables), etc. Such files need to be stored in the IP pool, so that subsequent reuse can be performed.

[0136] The IP pool is a physical storage object. In this embodiment, it can be a normal 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 selected, which can provide more detailed version management for files.

[0137] The IP pool is the infrastructure for IP reuse in the present application. Through centralized storage, standardized management, and parameterized adaptation, it solves the pain points of "low efficiency, easy to make mistakes, and difficult to reuse" in traditional IP integration. It converts IP from a one-time development resource into a reusable strategic asset, thereby providing a sustainable optimization ecosystem for complex chip design such as SoC and Chiplet.

[0138] Note that in this embodiment, the original IP itself is still stored in an independent library, and the IP pool only manages its standardized interface description. This design meets the confidentiality requirements of IP suppliers and enables plug-and-play integration.

[0139] Step S35: Realize data transmission between multiple standardized encapsulation files through encapsulation and reuse modules.

[0140] For example, Figure 3The data transmission between multiple standardized packaging files is achieved by the encapsulation multiplexing module, and the method comprises the following steps.

[0141] Step S351: Collect IP_wrapper port information.

[0142] In the embodiment of the application, the port list of each IP_wrapper file can be read by an automatic script, and bus type signals such as address, data and control signals are extracted, and the protocol types of the bus signals are identified, such as AXI4 protocol or AHB3 protocol.

[0143] Step S352: Build a multiplexer logic.

[0144] According to the number and type of buses defined in the IP integration event table, signal routing logic is generated. In terms of bus convergence, bus requests of multiple master devices (such as CPU, DMA controller, etc.) are integrated into one bus. Taking address mapping as an example, the address space of the master device is mapped to the corresponding slave device (such as UART, SPI, etc.) through an address decoder.

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

[0146] Step S353: Process protocol conversion.

[0147] When different protocol IPs need to be interconnected, for example, AXI4 protocol IP and AHB3 protocol IP communicate, protocol conversion logic is automatically generated.

[0148] 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 the corresponding signals (such as HADDR, HSIZE) of the AHB protocol.

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

[0150] The above steps realize efficient and reliable data transmission between multiple IP files through a series of operations such as standardized packaging, building interconnection modules and parameterized configuration multiplexing.

[0151] Step S4: Functional simulation;

[0152] Step S41: Coverage-driven verification: In this embodiment, a UVM test scenario is automatically generated:

[0153]

[0154] Real-time monitoring of coverage convergence curve;

[0155] Step S42: Formal Verification: In this embodiment, SVA assertions are used to check the protocol integrity:

[0156] assert property(@(posedge clk)

[0157] axi.arvalid|->##[1:8]axi.arready)

[0158] else $error("ARREADY response timed out");

[0159] Step S43: Power consumption simulation linkage: In this embodiment, dynamic power consumption analysis is performed using VCS+Verdi;

[0160] Step S5: Logic synthesis;

[0161] Step S51: Constraint hierarchical management: automatic loading of process-related constraints and parameterization of design constraints;

[0162] Step S52: Physical Awareness Integration: In this embodiment, congestion optimization is based on pre-layout:

[0163] set_congestion_options-max_util 0.85

[0164] compile_ultra-timing_high_effort-no_autoungroup

[0165] Step S53: ECO Automation: In this embodiment, violations are automatically repaired using Tcl scripts.

[0166] The advantages of this invention are as follows: This embodiment achieves precise transformation from requirements to technology through market-driven specification decomposition, intelligent IP selection constraint library, and pre-injection of testability requirements; it significantly improves architecture design efficiency by employing automated topology generation, power domain clustering, and clock tree pre-synthesis techniques; it solves the challenge of heterogeneous IP integration through a standardized IP process based on multi-level pattern matching and parameterized encapsulation; it ensures functional reliability through coverage-driven verification, formal assertions, and dynamic power consumption simulation; and finally, it achieves a balance between design convergence speed and quality by combining physical sensing synthesis and automated ECO repair. The entire process deeply integrates automation and standardization methods, shortening the traditional chip development cycle by more than 40% while ensuring design quality.

[0167] Embodiment Two

[0168] As shown in Figure 5 , Figure 6 , a flowchart of a chip design method based on digital chip IP integration according to the present application is shown, which includes the following steps:

[0169] Step B1: original IP generates standardized wrapper IP (“IP / module processing -> wrapper generation”);

[0170] Step B11: after the original IP is stored in the warehouse, the wrapper_ip is generated after processing, and the IP integration event table is configured:

[0171] wrapper_name: uart_ctrl_wrapper / / custom wrapper name

[0172] bus: "APB_2_1" / / 1 set of APB2 bus

[0173] user: "ON" / / turn on user-defined port

[0174] SIGN: "tx = data; rx = data" / / match non-standard port

[0175] Step B12: port extraction and matching;

[0176] Regularly match the original port

[0177] ^ int_.* -> interrupt port based on digital chip IP integration chip design method (such as int_tx_done) based on digital chip IP integration chip design method

[0178] .*_IO$ -> IO port based on digital chip IP integration chip design method (such as data_IO)

[0179] Force match the SIGN field

[0180] tx -> mapped to user-defined data port based on digital chip IP integration chip design method

[0181] rx -> mapped to user-defined data port

[0182] Step B13: generate a standardized wrapper file.

[0183] Step B2: IP pool calling and cross-project reuse (“processed IP stored in IP pool for calling”);

[0184] Step B21: store the standardized file;

[0185] Files stored in IP pool:

[0186] uart_ctrl_wrapper.v (standardized wrapper file);

[0187] uart_ctrl_events.csv (associated event table);

[0188] Storage method (example step S34): chip design method based on digital chip IP integration Git repository / IP pool directory chip design method based on digital chip IP integration (path: / ip_pool / communication / );

[0189] Step B22: cross-project reuse rules;

[0190] Prohibit modification of wrapper file, new project calls step:

[0191] / / New project top module directly calls

[0192]

[0193] Step B3: wrapper_mux multi-IP collaborative transplantation ("speed up multi-IP transplantation of same type of chip");

[0194] wrapper_mux realizes multi-IP parallel transplantation, improving design speed.

[0195] Scenario: simultaneously transplanting 4 APB UART IPs based on chip design method based on digital chip IP integration into a unified AXI bus system based on chip design method based on digital chip IP integration;

[0196] Step B31: Collect port information;

[0197] Read the bus field of each IP (all APB_2_1), extract signals such as paddr, prdata;

[0198] Step B32: Build a multiplexer;

[0199] Generate a 4-to-1 address decoder: allocate address offset 0x1000 / IP;

[0200] Step B33: protocol conversion;

[0201] APB→AXI conversion: paddr→awaddr, prdata→rdata;

[0202] Step B34: CDC processing; for asynchronous clock domain IP insertion, two-level synchronizer;

[0203] Step B35: Output: Generate the unified interface uart_mux.sv, reduce the top-level interconnection signals.

[0204] Advantages of the implementation of the present application: By the chip design method based on digital chip IP integration, the interface protocol is uniformly defined based on the chip design method based on digital chip IP integration (such as bus: "APB_2_1"), and the original IP is converted into a highly unified encapsulation module based on the chip design method based on digital chip IP integration (such as uart_ctrl_wrapper.v) by combining the chip design method based on digital chip IP integration regular rules, the chip design method based on digital chip IP integration (int_.*→ interrupt port), and the chip design method based on digital chip IP integration SIGN forced matching chip design method based on digital chip IP integration (tx→ data port). This process fully complies with the port classification standard (bus / interrupt / user-defined, etc.) of claim 7 / 10, ensuring that the top-level interface naming, bit width, and direction of different IPs are completely consistent; after the encapsulation file and event table are stored in the Git repository / IP pool based on the chip design method based on digital chip IP integration (path / ip_pool / communication / ), the new project based on the chip design method based on digital chip IP integration directly calls and parameterizes the configuration based on the chip design method based on digital chip IP integration (such as DATA_WIDTH(8)), while the chip design method based on digital chip IP integration prohibits manual modification of the file based on digital chip IP integration. This mechanism shortens the IP reuse period from several weeks to several hours and avoids design deviations caused by manual adaptation; for multi-IP transplantation scenarios, wrapper_mux realizes efficient integration of multiple IPs.

[0205] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, any skilled person in the art can easily think of changes or replacements within the scope of the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method of digital chip design, characterized by, The method comprises the following steps: specification setting; designing a chip structure according to the specification; writing an RTL based on the chip structure, which comprises digital IP integration, specifically, configuring an IP integration event table; reading port descriptions of original IP files through matching rules 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 results of the matching rules; and storing the standardized packaging file and the associated IP integration event table in an IP pool for reuse; function simulation, verifying the function of the chip; logic synthesis, physically synthesizing the verified chip.

2. The chip design method based on digital chip IP integration according to claim 1, characterized in that, The RTL writing comprises realizing data interaction and system integration among multiple standardized packaging files through a packaging reuse module.

3. The chip design method based on digital chip IP integration according to claim 2, characterized in that, The data interaction and system integration among multiple standardized packaging files through the packaging reuse module comprises the following steps: collecting IP_wrapper port information; constructing a multiplexer logic; processing protocol conversion.

4. The chip design method based on digital chip IP integration according to claim 1, characterized in that, The IP integration event table at least contains a self-defined integration name field, a bus field, a user-defined signal enable field, a signal interface switch field and a port keyword field.

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

6. The chip design method based on digital chip IP integration according to claim 4, characterized in that, The user-defined signal enable field controls whether to generate a register read-write function port for user-defined signals.

7. The chip design method based on digital chip IP integration of claim 1, wherein, In the process of reading port descriptions of original IP files through matching rules, the matching rules are to match the naming rules of ports through regular expressions, and the naming rules of ports are as follows: In bus ports, 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; irregular ports are matched through the port keyword field in the IP integration event table.

8. The chip design method based on digital chip IP integration of claim 1, wherein, The process of reading port descriptions of original IP files through matching rules based on the configuration in the IP integration event table, and extracting input and output signals and bit width information comprises the following steps: parsing original IP design files; loading the IP integration event table; performing multi-level pattern matching; extracting bit width information and parameterizing it.

9. The chip design method based on digital chip IP integration according to claim 1, characterized in that, The process of generating a standardized packaging file according to the matching results comprises the following steps: port classification and signal mapping; bit width parameterization processing; port standardized reconstruction; generating a standardized packaging file.

10. The chip design method based on digital chip IP integration of claim 1, wherein, The standardized packaging 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