Design information generation method and device of intellectual property core, electronic equipment and medium

Abstract

The invention discloses a design information generation method and device of an intellectual property core, electronic equipment and a medium. The method comprises the steps that input design associated information of the intellectual property core is acquired; determining a current design direction type according to the design association information; according to the design direction type and a port signal naming rule of a preset template library, a standardized top-layer code is generated, and the standardized top-layer code comprises standardized signal code information, a standardized time sequence constraint file and a standardized power domain constraint file. According to the embodiment of the invention, based on a design direction type and a port signal naming rule of a preset template library, port naming standardization is automatically carried out on top-layer codes: signal code information, a time sequence constraint file and a power domain constraint file, so that the problem that design information such as top-layer HDL codes, instantiation codes and SDC, UPF and the like of a current digital IP needs to be written manually is solved; time and labor are consumed, efficiency is low, and errors are prone to occurring.

Description

Technical Field

[0001] This application relates to the field of integrated circuit design technology, and in particular to methods, apparatus, electronic devices, and media for generating design information for intellectual property cores. Background Technology

[0002] In digital integrated circuit design, the reuse of IP (Intellectual Property Core) is crucial for improving development efficiency. However, currently, the top-level HDL (Hardware Description Language) code, instantiation code, and corresponding SDC (Synopsys Design Constraints) and UPF (Unified Power Format) design information for digital IPs typically need to be written manually. This is not only time-consuming, labor-intensive, inefficient, and error-prone, but also prone to problems such as human error or inconsistent naming of clock, reset, and bus signals among different IPs, as well as inconsistent interfaces. These issues lead to manual adaptation during integration, cumbersome instantiation code generation, and the disconnect between HDL design and physical implementation due to manual writing of timing constraints (SDC) and power management files (UPF). This severely impacts the collaboration efficiency of system design, verification, and back-end implementation, increasing the risk of design errors. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and medium for generating design information for intellectual property cores, in order to at least solve the problems in related technologies where manually writing design information for intellectual property cores is time-consuming, labor-intensive, inefficient, and prone to errors, and seriously affects the collaborative efficiency of system design, verification, and back-end implementation, thereby increasing the risk of design errors.

[0004] This application provides a method for generating design information for an intellectual property core, the method comprising:

[0005] Obtain the design-related information of the input intellectual property core;

[0006] Determine the current design direction type based on design-related information;

[0007] Based on the design direction type and the port signal naming rules of the preset template library, a standardized top-level code is generated. The standardized top-level code includes standardized signal code information, standardized timing constraint files, and standardized power domain constraint files.

[0008] As an optional embodiment, this application also provides an apparatus for generating design information for an intellectual property core, comprising:

[0009] The acquisition module is used to acquire the design-related information of the input intellectual property core;

[0010] The determination module is used to determine the current design direction type based on design-related information.

[0011] The generation module is used to generate standardized top-level code based on the design direction type and the port signal naming rules of the preset template library. The standardized top-level code includes standardized signal code information, standardized timing constraint files, and standardized power domain constraint files.

[0012] As an optional embodiment, this application also provides an electronic device, including:

[0013] Memory, used to store computer programs;

[0014] A processor is used to implement the steps of the design information generation method for any of the above-mentioned intellectual property cores when executing a computer program.

[0015] As an optional embodiment, this application also provides a computer-readable storage medium, comprising:

[0016] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above-mentioned intellectual property core design information generation methods.

[0017] In this embodiment, the design association information of the input intellectual property core is obtained; the current design direction type is determined based on the design association information; and standardized top-level code is generated according to the design direction type and the port signal naming rules of the preset template library. The standardized top-level code includes standardized signal code information, standardized timing constraint files, and standardized power domain constraint files. Therefore, this embodiment automatically standardizes the port naming of the top-level code (signal code information, timing constraint files, and power domain constraint files) based on the design direction type and the port signal naming rules of the preset template library. This solves the problem that currently, the top-level HDL code, instantiation code, and design information such as SDC and UPF of digital IPs often need to be manually written, which is not only time-consuming, labor-intensive, inefficient, and error-prone, but also suffers from problems such as non-standard naming of clock, reset, and bus signals between IPs and inconsistent interfaces, which seriously affect the collaboration efficiency of system design, verification, and back-end implementation, and increase the risk of design errors. Attached Figure Description

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

[0019] Figure 1 A schematic flowchart of a method for generating design information for an intellectual property core is provided for an embodiment of this application;

[0020] Figure 2 A complete flowchart illustrating another method for generating design information for intellectual property cores provided in this application embodiment;

[0021] Figure 3 This is a block diagram of a design information generation system for intellectual property cores provided in an embodiment of this application;

[0022] Figure 4 This is a block diagram of a design information generation device for an intellectual property core provided in an embodiment of this application;

[0023] Figure 5 A block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0025] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0026] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] In digital integrated circuit design, IP module reuse is crucial for improving development efficiency. However, currently, the top-level HDL code, instantiation code, and design information such as SDC and UPF for digital IPs often need to be written manually. This is not only time-consuming, labor-intensive, inefficient, and prone to errors, but also suffers from human factors and issues such as inconsistent naming of clock, reset, and bus signals between IPs, and inconsistent interfaces. This leads to manual adaptation during integration and cumbersome instantiation code generation. Furthermore, the traditional method of manually writing timing constraints (SDC) and power management files (UPF) also disconnects HDL design from physical implementation. In addition, for the integration of third-party IPs, the naming and definition of their interface signals may be inconsistent with the company's internal standards, and the meaning of external IP interface signals is not transparent. Additional encapsulation layers are required to adapt to the internal toolchain, and the verification platform also needs to repeatedly develop interface logic for different bus protocols (such as AXI and JTAG), resulting in high protocol adaptation costs. These problems seriously affect the collaborative efficiency of system design, verification, and back-end implementation, increasing the risk of design errors.

[0028] The existing IP-XACT (Intellectual Property Exchange), also known as the IEEE 1685 standard, is used for IP metadata encapsulation, but it lacks dynamic naming rules and protocol mapping capabilities, and does not address SDC and UPF adaptation. Traditional script-based code generation tools, based on Python / Perl scripts, require manual template maintenance and cannot adapt to multiple protocols and user rules. Some commercial EDA tools support IP configuration, but interface naming rules are fixed and cannot be customized. Existing traditional technologies do not achieve deep binding between protocol characteristics and signal naming (e.g., AXI's awaddr signal is automatically named axi_awaddr_master_o), generally lack user-editable rule engines, are difficult to adapt to different companies' coding standards, and do not support the automatic generation of instantiated code and constraint files, nor can they reverse-parse non-standard code and provide a standardized upper-layer shell.

[0029] To address the aforementioned problems, embodiments of this application provide a method for generating design information for intellectual property cores, such as... Figure 1 As shown, Figure 1 This is a flowchart illustrating a method for generating design information for an intellectual property core, provided as an embodiment of this application. This method can be applied to intellectual property cores, and the specific process is as follows:

[0030] Step S101: Obtain the design association information of the input intellectual property core.

[0031] Optionally, in the embodiments of this application, it is necessary to first input the design association information of the intellectual property core for subsequent operations. Here, the methods for inputting the design association information of the intellectual property core include, but are not limited to: inputting through Excel (spreadsheet) / GUI (Graphical User Interface), etc., and the types of association information input include, but are not limited to: HDL type, module name and port signal classification configuration, physical implementation requirement information, wherein the physical implementation requirement information includes SDC and UPF.

[0032] Step S102: Determine the current design direction type based on the design association information.

[0033] Optionally, in this embodiment, the corresponding design direction type can be determined based on the currently input design association information. Here, the design direction type includes two types: forward design and reverse resolution.

[0034] Forward design is the process of creating an IP core from scratch, based on clearly defined functional requirements and performance metrics. Reverse engineering, also known as reverse analysis, involves disassembling and analyzing existing chips or IP cores to obtain their design information, including circuit structure, logic functions, and design concepts, such as analyzing existing HDL code.

[0035] Step S103: Generate standardized top-level code according to the design direction type and the port signal naming rules of the preset template library. The standardized top-level code includes standardized signal code information, standardized timing constraint file, and standardized power domain constraint file.

[0036] Optionally, after determining the current design direction type (i.e., forward design or reverse parsing), it is also necessary to obtain the port signal naming rules from a pre-defined template library. Since port signal configuration information is included regardless of whether the current design direction type is forward design or reverse parsing, at this time, it is only necessary to name the port signal configuration information according to the port signal naming rules of the pre-defined template library to generate standardized top-level code.

[0037] It should be noted that the port signal configuration information includes clock signals, reset signals, bus protocol signals, timing constraint files, and power domain constraint files. Among these, clock signals, reset signals, and bus protocol signals can be collectively referred to as signal code information.

[0038] Since the port signal naming rules of the preset template library are standardized port naming rules, the generated top-level code is also standardized code. Similarly, the signal code information, timing constraint files, and power domain constraint files included in the standardized top-level code are also standardized.

[0039] In this embodiment, the design association information of the input intellectual property core is obtained; the current design direction type is determined based on the design association information; and standardized top-level code is generated according to the design direction type and the port signal naming rules of the preset template library. The standardized top-level code includes standardized signal code information, standardized timing constraint files, and standardized power domain constraint files. Therefore, this embodiment automatically standardizes the port naming of the top-level code (signal code information, timing constraint files, and power domain constraint files) based on the design direction type and the port signal naming rules of the preset template library. This solves the problem that currently, the top-level HDL code, instantiation code, and design information such as SDC and UPF of digital IPs often need to be manually written, which is not only time-consuming, labor-intensive, inefficient, and error-prone, but also suffers from problems such as non-standard naming of clock, reset, and bus signals between IPs and inconsistent interfaces, which seriously affect the collaboration efficiency of system design, verification, and back-end implementation, and increase the risk of design errors.

[0040] As an optional embodiment, determining the current design direction type based on design association information includes:

[0041] When the design-related information includes the type of the first hardware description language, the name of the first module, the types of multiple first port signals, and the first physical implementation requirements, the design direction type is determined to be the forward design type.

[0042] When designing hardware description language code with associated information in a non-preset format, the design direction type is determined to be the reverse parsing design type.

[0043] Alternatively, in the case of a forward design, the user enters the following information through a pre-defined method (including but not limited to Excel / GUI):

[0044] (1) First HDL type (e.g., Verilog / VHDL / SystemVerilog) and first module name;

[0045] (2) Port signal classification configuration (including multiple first port signal types: such as clock, reset, custom signals, bus protocol signals); users need to fill in the main field of the signal name according to the classification and select the corresponding protocol. The signal classification includes clock signals, reset signals, internal bus signals, external bus signals, and custom signals. Among them, clock signals, reset signals, and custom signals require filling in the main field of the signal name and selecting input or output attributes. Internal bus signals and external bus signals require selecting the protocol and version. The protocols that can be selected for internal bus are AXI (Advanced eXtensible Interface), AHB (Advanced High-performance Bus), APB (Advanced Peripheral Bus), PLB (Processor Local Bus), NSP (Network Service Processor), etc. The protocols that can be selected for external bus signals are JTAG (Joint Test Action Group), IIC (Inter-Integrated Circuit), I3C (Improved Inter-Integrated Circuit), SPI (Serial Peripheral Circuit), etc. Interface (serial peripheral interface), UART (Universal Asynchronous Receiver / Transmitter), etc.;

[0046] (3) First physical implementation requirements: clock cycle, power domain configuration, etc.

[0047] If the existing signal command module or IP code is not standardized, then it needs to be resolved in reverse (i.e., reverse resolution):

[0048] The reverse parsing process is based on checking whether the current input is non-standard (i.e., non-compliant) HDL code. If so, the reverse parsing process begins.

[0049] In this embodiment, standardized top-level code is generated through forward design, eliminating the need for manual processing and coding. This quickly achieves interface standardization, saves integration and shell code generation time, and reduces the error rate. Reverse parsing enables rapid integration of third-party IPs, effectively solving the problem of non-standard code adaptation. Standardized interfaces are compatible with any verification platform, improving reusability.

[0050] As an optional embodiment, when the design direction type is a forward design type, standardized top-level code is generated according to the design direction type and the port signal naming rules of the preset template library in the preset database, including:

[0051] The first signal parameter in the first port signal type is matched with the port signal naming rules in the preset template library to obtain the matched first target port signal naming rules.

[0052] The first signal parameters are processed according to the first target port signal naming rules to generate standardized first signal code information;

[0053] Add the type of the first hardware description language and the name of the first module to the first signal code information to obtain the second signal code information;

[0054] Generate a standardized first timing constraint file and a first power domain constraint file based on the first physical realization requirements;

[0055] The first timing constraint file and the first power domain constraint file are added to the second signal code information, and combined with the design behavior logic code to obtain the standardized top-level code.

[0056] Optionally, the port signal naming rules of the preset template library are as follows:

[0057] Clock signal: Generates [main field]_clk_[I / O] (e.g., sys_clk_i).

[0058] Reset signal: Generates [main field]_rst[polarity] (e.g., sys_rst_n).

[0059] Bus protocol signals: Generate [protocol]_[function]_[master / slave role]_[I / O] (e.g., axi_awaddr_master_o) according to the protocol library.

[0060] The unified rules involved in this application embodiment (rules are editable, can be added, and extended; clock signal name is: user-filled field + _clk + _IO attribute (input is i, output is o); reset signal name is: user-filled field + _rst + polarity (active low is _n, active high is none); custom signal name is: {custom prefix} + user-filled field + {custom suffix} + _IO attribute (input is i, output is o); the names of internal bus signals and external bus signals are pre-set in a preset template library according to the protocol and its version, using a unified naming rule (such as {signal name + protocol + bit width + master / slave mode + IO attribute}), and are directly called by the IP system based on user input.

[0061] After learning the port signal naming rules of the preset template library, if the current design is forward, the first signal parameters (all signal parameters corresponding to the clock signal, all signal parameters corresponding to the reset signal, and all signal parameters corresponding to the bus protocol signal) in the first port signal type are matched with the port signal naming rules in the preset template library to obtain the matched first target port signal naming rules.

[0062] Using the matching first target port signal naming rule as a benchmark, the first signal parameters are replaced based on the first target port signal naming rule to generate standardized first signal code information.

[0063] For example, in a specific implementation of a forward design, the process of input configuration → rule matching → code generation is implemented:

[0064] Step 1: Input configuration

[0065] User input:

[0066] HDL type: Verilog.

[0067] Module name: axi_master_top.

[0068] Port signal configuration:

[0069] Internal bus signals: Select protocol AXI4, master mode, 32-bit width.

[0070] Clock signal: Enter sys in the main field, with the direction as input and a period of 10ns.

[0071] Reset signal: Enter sys in the main field, and the polarity is active low.

[0072] Configure power domain vdd_core

[0073] Step 2: Rule Matching

[0074] Protocol driver naming:

[0075] AXI4 main interface signals are generated according to protocol rules:

[0076] awaddr→axi_awaddr_master_o[31:0].

[0077] awkward→axi_awready_slave_i.

[0078] wdata→axi_wdata_master_o[31:0].

[0079] Clock signal naming convention: sys_clk_i.

[0080] Reset signal naming convention: sys_rst_n.

[0081] Therefore, standardized first signal code information can be generated.

[0082] 3. Code generation

[0083] Generate standardized top-level code:

[0084] module axi_master_top(

[0085] / / Clock and Reset

[0086] input sys_clk_i,

[0087] input sys_rst_n,

[0088] / / AXI4 main interface

[0089] output wire[31:0]axi_awaddr_master_o,

[0090] input wireaxi_awready_slave_i,

[0091] output wire[31:0]axi_wdata_master_o, );

[0093] endmodule

[0094] Generate an instantiation template based on the syntax of the first hardware description language type:

[0095] axi_master_topu_axi_master(

[0096] .sys_clk_i(clk),

[0097] .sys_rst_n(rst_n),

[0098] .axi_awaddr_master_o(awaddr),

[0099] .axi_awready_slave_i(awready),

[0100] .axi_wdata_master_o(wdata), );

[0102] At the same time, the type of the first hardware description language, Verilog, and the first module name, axi_master_top, need to be added to the first signal code information to obtain the second signal code information.

[0103] Then, based on the first physical implementation requirements, a standardized first timing constraint file is generated, including constraints on clock cycles and timing exceptions, as well as a first power domain constraint file, which generates power switches and isolation units based on the power domain configuration.

[0104] Generate the first timing constraint file:

[0105] create_clock-period 10[get_portssys_clk_i]

[0106] set_input_delay 2-clock[get_clockssys_clk_i][get_portsaxi_awaddr*]

[0107] The following is the process of generating the first timing constraint file:

[0108] 1. Create clock constraints:

[0109] The `create_clock` command tells synthesis tools (such as Vivado and Quartus) that the input port `sys_clk_i` is a clock signal with a period of 10ns (frequency 100MHz).

[0110] The tool will write this constraint to a .sdc (Synopsys Design Constraint) file, such as timing_constraints.sdc.

[0111] 2. Set input delay:

[0112] The `set_input_delay` command specifies a 2ns delay for external signals (such as the axi_awaddr address bus) from the clock edge to stability.

[0113] This compensates for delays in the chip's external logic and wiring, ensuring accurate internal timing analysis.

[0114] 3. Final generated file

[0115] Generate the first power domain constraint file:

[0116] create_power_domain PD_CORE-elements{axi_top}

[0117] create_supply_port VDD_CORE

[0118] The following is the process of generating the first power domain constraint file:

[0119] 1. Create a power domain:

[0120] The `create_power_domain` command defines a power domain named `PD_CORE`, which contains the top-level module `axi_top` and all its sub-modules.

[0121] This is used for subsequent low-power designs (such as power gating, multi-voltage domain).

[0122] 2. Define the power port:

[0123] The `create_supply_port` command creates a power supply port `VDD_CORE` for the power domain `PD_CORE`, which can then be connected to an actual power network.

[0124] 3. The final generated file.

[0125] The generated first timing constraint file and first power domain constraint file are then added to the second signal code information to obtain the standardized top-level code. In this embodiment, the forward design used to automatically generate the top-level code generates interface signals and instantiation templates with unified naming conventions. The entire process requires no manual data processing or analysis, nor manual code writing, achieving interface standardization. Unified naming rules reduce communication costs for design, verification, and backend teams (e.g., an estimated 30% saving in integration time), reduce the error rate of manually writing instantiation code, and improve efficiency. Shell code generation time is reduced, for example, from 2 person-days to 10 minutes.

[0126] As an optional embodiment, the first timing constraint file and the first power domain constraint file are added to the second signal code information to obtain the standardized top-level code, including:

[0127] Add the second signal code information to the first timing constraint file and the first power domain constraint file to obtain the third signal code information;

[0128] Generate the empty space for the first design behavior logic;

[0129] The acquired first design behavior logic code is written into the empty position and combined with the third signal code information to generate the standardized top-level code.

[0130] Optionally, during forward code generation, empty spaces need to be reserved for the IP core design. For example, if chip routing, circuit hierarchy, etc., still need to be designed, empty spaces need to be reserved to fill in the relevant design information. In this embodiment, the design to be written at the current empty space is called the first design behavior logic.

[0131] Therefore, in this embodiment of the application, after adding the first timing constraint file and the first power domain constraint file to the second signal code information to obtain the third signal code information, it is also necessary to write the first design behavior logic code that needs to be executed to the reserved empty position. Then, the first design behavior logic code written to the empty position is combined with the third signal code information to generate the standardized top-level code.

[0132] For example: Generating standardized top-level code:

[0133]

[0134] In this embodiment of the application, when generating top-level code through forward design, design slots can be reserved for designers. The designer's design behavior logic code is written in the slots and then combined with the previous code to generate top-level code. This ensures the standardization of the basic architecture through forward code generation and allows for flexible adjustments in professional fields (such as physical design) by reserving slots. Ultimately, this achieves efficient collaboration, reduces error rates, and supports the automation and standardization of the entire chip design process.

[0135] As an optional embodiment, when the design direction type is a reverse parsing design type, standardized top-level code is generated according to the design direction type and the port signal naming rules of the preset template library, including:

[0136] Parse the port signals of the hardware description language code in a non-preset format to obtain the type of the second hardware description language or the name of the second module corresponding to the hardware description language code in the non-preset format.

[0137] Based on the type of the second hardware description language or the name of the second module, match the type of the historical hardware description language or the name of the historical module in the preset template library;

[0138] If no second hardware description language type or second module name is matched in the preset template library, the description information contained in the hardware description language code under the non-preset format is extracted.

[0139] A format object is generated based on the description information, whereby the format object is used to represent the description information;

[0140] Retrieve supplementary information to fill in the format object, and obtain the target format object;

[0141] Retrieve the second port signal type contained in the target format object;

[0142] Based on the second signal parameters in the second port signal type, the port signal naming rules in the preset template library are matched to obtain the matched second target port signal naming rules;

[0143] The second signal parameters are processed according to the second target port signal naming rules to generate standardized fourth signal code information;

[0144] Add the type of the second hardware description language and the name of the second module to the fourth signal code information to obtain the fifth signal code information;

[0145] Extract the second physical implementation requirements from the hardware description language code in a non-preset format;

[0146] Based on the second physical realization requirements, a standardized second timing constraint file and a second power domain constraint file are generated.

[0147] The second timing constraint file and the second power domain constraint file are added to the fifth signal code information to obtain the normalized top-level code.

[0148] Optionally, the naming rules for port signals in the preset template library have been described in detail above and will not be repeated here.

[0149] Based on the user-input type of the second hardware description language or the second module name, a match is performed in a preset template library. If no match is found in the template library, descriptive information contained in the hardware description language code under a non-preset format is extracted. This descriptive information is signal metadata, used to generate subsequent format objects, including but not limited to IO attributes, protocols, versions, and signal classifications. A format object is then generated based on the descriptive information. The format object describes the descriptive information and is a representation of it, including but not limited to tables, lists, forms, and matrices. The user can fill in information in the generated format object to obtain the target format object. Therefore, the difference between a format object and a target format object is that the target format object is a format object for which the user has filled in information.

[0150] After generating the target format object, you can obtain the second port signal type contained in the target format object, namely clock, reset, custom signal, and bus protocol signal.

[0151] After learning the port signal naming rules of the preset template library, if the current process is reverse parsing, the second parameter in the second port signal type (all signal parameters corresponding to the clock signal, all signal parameters corresponding to the reset signal, and all signal parameters corresponding to the bus protocol signal) is matched with the port signal naming rules in the preset template library to obtain the matched second target port signal naming rules.

[0152] Using the matching second target port signal naming rule as a benchmark, the second signal parameters are replaced based on the second target port signal naming rule to generate standardized fourth signal code information.

[0153] For example, in a specific implementation of reverse DNS lookup, the process of reverse DNS lookup → user-supplemented information → rule matching → code generation is implemented:

[0154] Step 1: Reverse DNS lookup

[0155] Enter non-standard code:

[0156] module legacy_jtag(

[0157] input TCK,

[0158] input TMS,

[0159] output TDO );

[0161] / / Original implementation code

[0162] endmodule

[0163] The existing template does not include this, therefore the parsed output table is:

[0164] signal name IO properties Signal classification protocol Version TCK enter Uncategorized none none TMS enter Uncategorized none none TDO Output Uncategorized none none

[0165] Step 2: User provides additional information

[0166] Table Supplement:

[0167] signal name IO properties Signal classification protocol Version TCK enter external bus signals JTAG IEEE 1149.1 TMS enter external bus signals JTAG IEEE 1149.1 TDO Output external bus signals JTAG IEEE 1149.1

[0168] Step 4: Rule Matching

[0169] Protocol-driven naming (JTAG rules):

[0170] TCK→jtag_tck_i.

[0171] TMS→jtag_tms_i.

[0172] TDO→jtag_tdo_o.

[0173] Step 5: Code Generation

[0174] Generate standardized encapsulation code:

[0175]

[0176] At the same time, the type of the second hardware description language, such as Verilog, and the second module name, such as axi_master_top, need to be added to the fourth signal code information to obtain the fifth signal code information.

[0177] Based on the second physical implementation requirements, a standardized second timing constraint file and a second power domain constraint file are generated. The generation process for the second timing constraint file and the second power domain constraint file is the same as that described in the previous embodiment and will not be repeated here.

[0178] The generated second timing constraint file and second power domain constraint file are added to the fifth signal code information to obtain the standardized top-level code. In this embodiment, through reverse parsing and standardized encapsulation, rapid integration of third-party IP can be achieved, solving the problem of adapting non-standard code to automated verification platforms. The standardized interface can be adapted to any verification platform, and the test case reusability rate is improved by 50%.

[0179] As an optional embodiment, the second timing constraint file and the second power domain constraint file are added to the fifth signal code information to obtain the normalized top-level code, including:

[0180] Add the second timing constraint file and the second power domain constraint file to the fifth signal code information to obtain the sixth signal code information;

[0181] Call the second design behavior logic code;

[0182] The second design behavior logic code is combined with the sixth signal code information to generate standardized top-level code.

[0183] Optionally, since the current process involves reverse parsing non-standard HDL code, the generation of standardized top-level code does not involve changing the designer's second-line calling logic. Therefore, the second-line logic code can simply be called directly for current use.

[0184] It should be noted that calling behavioral logic code achieves orderly operation, functional reuse, and logical encapsulation of complex systems through modular decomposition, process control, and cross-entity interaction, which helps improve the system's reusability.

[0185] Therefore, in this embodiment of the application, after adding the second timing constraint file and the second power domain constraint file to the fifth signal code information to obtain the sixth signal code information, it is also necessary to combine the second design behavior logic code with the sixth signal code information after calling the second design behavior logic code to generate standardized top-level code.

[0186] When generating top-level code through reverse parsing, the second design behavior logic code can also be called. After calling the second design behavior logic code, the second design behavior logic code is combined with the sixth signal code information to generate standardized top-level code. This enables modular decomposition, process control, and cross-entity interaction, achieving orderly operation, functional reuse, and logical encapsulation of complex systems, which is beneficial to improving the system's reusability.

[0187] As an optional embodiment, after matching the type or historical module name of a historical hardware description language in a preset template library based on the type or second module name of the second hardware description language, the method further includes:

[0188] If the type of the second hardware description language or the name of the second module is matched in the preset template library, the type of the third port signal corresponding to the hardware description language code in the non-preset format is obtained according to the type of the second hardware description language or the name of the second module.

[0189] Based on the third signal parameters in the third port signal type, the port signal naming rules in the preset template library are matched to obtain the matched third target port signal naming rules;

[0190] The third signal parameters are processed according to the third target port signal naming rules to generate standardized seventh signal code information;

[0191] Add the type of the second hardware description language and the name of the second module to the seventh signal code information to obtain the eighth signal code information;

[0192] Extract the third physical implementation requirements from the hardware description language code in a non-preset format;

[0193] Based on the third physical implementation requirements, standardized third-sequence constraint files and third-power domain constraint files are generated.

[0194] The third timing constraint file and the third power domain constraint file are added to the eighth signal code information to obtain the standardized top-level code.

[0195] Optionally, the naming rules for port signals in the preset template library have been described in detail above and will not be repeated here.

[0196] Based on the type of the second hardware description language or the second module name input by the user, a match is made in the preset template library. If a match is successfully made in the template library, rule matching is performed.

[0197] After learning the port signal naming rules of the preset template library, if the current process is reverse parsing, the third parameter in the third port signal type (all signal parameters corresponding to the clock signal, all signal parameters corresponding to the reset signal, and all signal parameters corresponding to the bus protocol signal) is matched with the port signal naming rules in the preset template library to obtain the matched third target port signal naming rules.

[0198] Using the matched third target port signal naming rule as a benchmark, the third signal parameters are replaced based on the third target port signal naming rule to generate standardized seventh signal code information.

[0199] For example, in a specific implementation of reverse parsing, the process of reverse parsing → rule matching → code generation is achieved:

[0200] Step 1: Reverse DNS lookup

[0201] Enter non-standard code:

[0202]

[0203] Step 4: Rule Matching

[0204] Protocol-driven naming (JTAG rules):

[0205] TCK→jtag_tck_i.

[0206] TMS→jtag_tms_i.

[0207] TDO→jtag_tdo_o.

[0208] Step 5: Code Generation

[0209] Generate standardized encapsulation code:

[0210]

[0211]

[0212] At the same time, the type of the second hardware description language, such as Verilog, and the second module name, such as axi_master_top, need to be added to the seventh signal code information to obtain the eighth signal code information.

[0213] Then, based on the third physical implementation requirements, a standardized third timing constraint file is generated, including constraints on clock cycles and timing exceptions, as well as a third power domain constraint file, which generates power switches and isolation units based on the power domain configuration.

[0214] The generation process for the third timing constraint file and the third power domain constraint file is the same as that in the above embodiments, and will not be described again.

[0215] The generated third timing constraint file and third power domain constraint file are added to the eighth signal code information to obtain the normalized top-level code.

[0216] In this embodiment, through reverse parsing and standardized encapsulation, rapid integration of third-party IP can be achieved, solving the problem of adapting non-standard code to automated verification platforms. The standardized interface can be adapted to any verification platform, and the test case reuse rate is increased by 50%.

[0217] As an optional embodiment, the third timing constraint file and the third power domain constraint file are added to the eighth signal code information, and combined with the design behavior logic code to obtain the standardized top-level code, including:

[0218] Add the third timing constraint file and the third power domain constraint file to the eighth signal code information to obtain the ninth sub-code information;

[0219] Call the third design behavior logic code;

[0220] The third design behavior logic code is combined with the ninth sub-code information to generate standardized top-level code.

[0221] Therefore, in this embodiment, after adding the third timing constraint file and the third power domain constraint file to the eighth signal code information to obtain the ninth signal code information, it is necessary to combine the third design behavior logic code with the ninth signal code information after calling the third design behavior logic code to generate standardized top-level code. The third design behavior logic code and the second design behavior logic code are conceptually the same; both can be directly called during reverse parsing to generate standardized top-level code, and will not be elaborated further.

[0222] In this embodiment of the application, when generating the top-level code through reverse parsing, the third design behavior logic code can also be called. After calling the third design behavior logic code, the third design behavior logic code is combined with the ninth signal code information to generate standardized top-level code. This realizes modular decomposition, process control and cross-entity interaction, enabling the orderly operation, function reuse and logic encapsulation of complex systems, which is conducive to improving the reusability of the system.

[0223] As an optional embodiment, the method further includes:

[0224] Write the target format object into the preset template library to obtain the preset template library with the target format object added.

[0225] Optionally, for example: in a specific embodiment of reverse parsing, after the user supplements the information, the preset template library will update itself to achieve self-learning.

[0226] For example, the preset template library updates automatically:

[0227] Added IP address: legacy_jtag and its corresponding signal information;

[0228] A new JTAG protocol has been added. Subsequent projects will automatically use the jtag_[t*]_[i / o] naming convention when generating JTAG signals.

[0229] In this embodiment, by adding a self-learning function to the preset template library, the template's scalability is achieved, supporting user-defined protocols and HDL syntax to adapt to technological evolution (such as the addition of the CXL protocol). The template library is optimized through reverse data parsing, enabling automated learning and upgrades, improving the accuracy of subsequent code generation (e.g., reducing the number of times users need to supplement classification); this facilitates end-to-end integration, with a strong correlation between the SDC constraint file and the physical implementation, reducing later timing convergence time; and automatic generation of UPF files, ensuring consistency between power management and RTL (Register-Transfer Level) design.

[0230] As an alternative embodiment, such as Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the complete process of a method for generating design information for an intellectual property core, provided in an embodiment of this application. The specific process is as follows:

[0231] The user will first perform an optional input operation:

[0232] If the user provides configuration input, such as inputting HDL type, module name, port signal classification configuration, and physical implementation requirements (clock cycle, power domain configuration) through Excel / GUI, then it is a forward design.

[0233] During forward design, the corresponding port signal matching preset template library is configured based on the input port signal classification, and rule matching is performed; then code with empty slots in the behavioral logic is generated, and finally, upper-level instantiation sample code, SDC constraint file and UPF file are generated.

[0234] If the user inputs non-standard HDL code, reverse parsing will be performed.

[0235] During the reverse lookup operation, the input information is pre-queried against a preset template library. The input information is matched with the IP information in the preset template library. If no match is found, the IP information, port signals and IO attributes, and output format file are extracted. Then, in the output format file, the user adds signal classification and protocol information, physical implementation requirements (clock cycle, power domain configuration). The template library automatically records the IP information, supplements and improves the template, and realizes template self-learning and updating. Then, the port signals are matched against the preset template library to perform rule matching, generate code that instantiates the lower-level non-standard IP / module and completes the connection between the port signals and the top-level signals of the module. At the same time, the existing behavioral logic is called, and finally, the upper-level instantiated sample code, SDC constraint file and UPF file are generated.

[0236] If the input information matches the IP information in the preset template library, then the corresponding port signal matching preset template library is configured based on the input port signal classification, and rule matching is performed to generate code that instantiates the lower-level non-standard IP / module and completes the connection between the port signal and the top-level signal of the module. At the same time, the existing behavioral logic code is called, and finally the upper-level instantiated sample code, SDC constraint file and UPF file are generated.

[0237] It should be noted that when matching port signals with a preset template library, performing rule matching, generating code that includes instantiated lower-level non-standard IPs / modules and completes the connection between port signals and the top-level signals of the module, the specific approach is as follows: call the template of the corresponding HDL language in the template library (the system pre-stores code templates of different HDL languages) and automatically generate the top-level code based on the signal information input by the user.

[0238] Specifically, the requirements for different HDL languages ​​are as follows:

[0239] Verilog and SystemVerilog: Generate module structures containing the keywords `module` and `endmodule`, with the following intermediate parts:

[0240] Port signal declaration (defining input and output signals);

[0241] Behavioral description (can be left blank, or include instantiation code for modules and IPs);

[0242] VHDL: Generates more complex structures, including:

[0243] Package description;

[0244] Entity definition (including port definition);

[0245] The structure (architecture) part.

[0246] Generate instantiated template code to support calls from upper-level modules; specifically, instantiate the module name and port signals one by one according to the syntax of the corresponding HDL; Verilog uses the form .portname(), while VHDL uses the port map keyword.

[0247] This application also provides a design information generation system for intellectual property cores, such as... Figure 3 As shown, Figure 3 This is a block diagram of a design information generation system for intellectual property cores provided in an embodiment of this application. The system includes: an input module, a reverse parser, a template library, a rule engine, and a code generator. The input module and the reverse parser are connected to the template library, which contains the rule engine. The template library is also connected to the code generator.

[0248] Furthermore, the input module is used for users to input HDL types and port signal classification information; then the user input information is matched with protocol templates in the template library, and the port signal naming is modified according to the rule engine; finally, the code generator generates standardized top-level code.

[0249] The reverse parser is used to extract port signals from non-standard code, input the port signals of non-standard code into the template library for matching, and generate a table file for users to supplement information if the existing template library does not contain them; the port signal naming is modified according to the rule engine; and then the code generator generates standardized top-level code.

[0250] The template library supports adding, removing, expanding, and editing, as well as automatic system updates. It includes protocol templates, HDL syntax templates, and constraint rules. The protocol templates have pre-defined naming rules for protocols such as AXI, APB, and JTAG, and support users to add new protocols (such as PCIe and USB4). The HDL syntax templates support Verilog, VHDL, and SystemVerilog, and can be extended to emerging languages ​​such as Chisel. The constraint rules automatically generate SDC constraints (such as clock cycle and input delay) and UPF power domain definitions based on signal classification.

[0251] The rules engine supports dynamic editing of naming rules (prefix / suffix / connector) and protocol mapping relationships, allowing users to edit naming rules.

[0252] Code Generator: Dynamically combines templates and rules to generate code. It calls templates from the template library corresponding to the HDL language, generates top-level code based on user-input signals, including module declarations and port definitions, and simultaneously generates example code for instantiating the module at the upper level. Specifically, it instantiates the module name and port signals one by one according to the corresponding HDL syntax; it also generates SDC timing constraint files and UPF power management file samples.

[0253] This embodiment also provides a design information generation device for intellectual property cores, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0254] This embodiment provides a device for generating design information for intellectual property cores, such as... Figure 4 As shown, it includes:

[0255] The acquisition module 401 is used to acquire the design association information of the input intellectual property core;

[0256] Module 402 is used to determine the current design direction type based on design association information;

[0257] The generation module 403 is used to generate standardized top-level code according to the design direction type and the port signal naming rules of the preset template library. The standardized top-level code includes standardized signal code information, standardized timing constraint files, and standardized power domain constraint files.

[0258] In some alternative implementations, the determining module 402 includes:

[0259] The first determining submodule is used to determine the design direction type as a forward design type when the design-related information includes the type of the first hardware description language, the name of the first module, the types of multiple first port signals, and the first physical implementation requirements.

[0260] The second determination submodule is used to determine the design direction type as reverse parsing design type when the design-related information is hardware description language code in a non-preset format.

[0261] In some optional implementations, when the design direction type is a forward design type, the generation module 403 includes:

[0262] The first matching submodule is used to match the first signal parameter in the first port signal type with the port signal naming rules in the preset template library to obtain the matched first target port signal naming rules.

[0263] The first generation submodule is used to process the first signal parameters according to the first target port signal naming rules and generate standardized first signal code information.

[0264] The first addition submodule is used to add the type of the first hardware description language and the name of the first module to the first signal code information to obtain the second signal code information;

[0265] The second generation submodule is used to generate a standardized first timing constraint file and a first power domain constraint file based on the first physical implementation requirements.

[0266] The second addition submodule is used to add the second signal code information to the first timing constraint file and the first power domain constraint file to obtain the standardized top-level code.

[0267] In some alternative implementations, the second joining submodule includes:

[0268] The first addition unit is used to add the first timing constraint file and the first power domain constraint file to the second signal code information to obtain the third signal code information;

[0269] The first generation unit is used to generate the empty positions of the first design behavior logic;

[0270] The second generation unit is used to write the acquired first design behavior logic code into the empty position and combine it with the third signal code information to generate the standardized top-level code.

[0271] In some optional implementations, when the design direction type is a reverse parsing design type, the generation module 403 includes:

[0272] The first acquisition submodule is used to parse the port signals of the hardware description language code in a non-preset format and obtain the type of the second hardware description language or the name of the second module corresponding to the hardware description language code in a non-preset format.

[0273] The second matching submodule is used to match the type of a historical hardware description language or the name of a historical module in a preset template library based on the type of the second hardware description language or the name of the second module.

[0274] The first extraction submodule is used to extract the description information contained in the hardware description language code in a non-preset format if the type of the second hardware description language or the name of the second module is not matched in the preset template library.

[0275] The third generation submodule is used to generate a format object based on the description information, where the format object is used to represent the description information;

[0276] The second acquisition submodule is used to acquire supplementary information to fill in the format object and obtain the target format object;

[0277] The third acquisition submodule is used to acquire the second port signal type contained in the target format object;

[0278] The third matching submodule is used to match the second signal parameters in the second port signal type with the port signal naming rules in the preset template library to obtain the matched second target port signal naming rules.

[0279] The fourth generation submodule is used to process the second signal parameters according to the second target port signal naming rules and generate standardized fourth signal code information.

[0280] The third submodule is used to add the type of the second hardware description language and the name of the second module to the fourth signal code information to obtain the fifth signal code information.

[0281] The second extraction submodule is used to extract the second physical implementation requirements from the hardware description language code in a non-preset format.

[0282] The fifth generation submodule is used to generate standardized second timing constraint files and second power domain constraint files based on the second physical implementation requirements;

[0283] The fourth submodule is used to add the second timing constraint file and the second power domain constraint file to the fifth signal code information to obtain the standardized top-level code.

[0284] In some alternative implementations, the fourth addition submodule further includes:

[0285] The second addition unit is used to add the second timing constraint file and the second power domain constraint file to the fifth signal code information to obtain the sixth signal code information;

[0286] The first calling unit is used to call the second design behavior logic code;

[0287] The third generation unit is used to combine the second design behavior logic code with the sixth signal code information to generate standardized top-level code.

[0288] In some alternative implementations, the method further includes:

[0289] The fourth acquisition submodule is used to obtain the third port signal type corresponding to the hardware description language code in the non-preset format after matching the type or name of the historical hardware description language in the preset template library based on the type or name of the second hardware description language. If the type or name of the second hardware description language is matched in the preset template library, the third port signal type is obtained according to the type or name of the second hardware description language.

[0290] The fourth matching submodule is used to match the third signal parameters in the third port signal type with the port signal naming rules in the preset template library to obtain the matched third target port signal naming rules.

[0291] The sixth generation submodule is used to process the third signal parameters according to the third target port signal naming rules and generate standardized seventh signal code information;

[0292] The fifth submodule is used to add the type of the second hardware description language and the name of the second module to the seventh signal code information to obtain the eighth signal code information;

[0293] The third extraction submodule is used to extract the third physical implementation requirements from the hardware description language code in a non-preset format.

[0294] The seventh generation submodule is used to generate standardized third-time constraint files and third-power domain constraint files based on the third physical implementation requirements;

[0295] The fifth addition submodule is used to add the third timing constraint file and the third power domain constraint file to the eighth signal code information to obtain the standardized top-level code.

[0296] In some alternative implementations, the fifth addition submodule further includes:

[0297] The third addition unit is used to add the third timing constraint file and the third power domain constraint file to the eighth signal code information to obtain the ninth sub-code information;

[0298] The second calling unit is used to call the third design behavior logic code;

[0299] The fourth generation unit is used to combine the third design behavior logic code with the ninth sub-code information to generate standardized top-level code.

[0300] In some alternative implementations, the method further includes:

[0301] An additional module is added to write the target format object into the preset template library, resulting in the preset template library after the target format object has been added.

[0302] The intellectual property core design information generation apparatus provided in this disclosure can execute the intellectual property core design information generation method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the method. Further functional descriptions of the above modules and units are the same as in the corresponding embodiments described above, and will not be repeated here.

[0303] Embodiments of this application also provide an electronic device, such as... Figure 5 As shown, the computer device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement all the steps mentioned in the first aspect of this application.

[0304] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements all the steps mentioned in the first aspect of this application.

[0305] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0306] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0307] The foregoing has provided a detailed description of the method, apparatus, electronic device, and medium for generating design information for an intellectual property core. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for generating design information for an intellectual property core, characterized in that, The method includes: Obtain the design-related information of the input intellectual property core; The current design direction type is determined based on the design association information; Based on the design direction type and the port signal naming rules of the preset template library, a standardized top-level code is generated, wherein the standardized top-level code includes standardized signal code information, standardized timing constraint files, and standardized power domain constraint files.

2. The method according to claim 1, characterized in that, Determining the current design direction type based on the design association information includes: When the design-related information includes the type of the first hardware description language, the first module name, multiple first port signal types, and the first physical implementation requirements, the design direction type is determined to be a forward design type. When the design-related information is hardware description language code in a non-preset format, the design direction type is determined to be a reverse parsing design type.

3. The method according to claim 2, characterized in that, When the design direction type is a forward design type, the step of generating standardized top-level code according to the design direction type and the port signal naming rules of the preset template library includes: The first signal parameter in the first port signal type is matched with the port signal naming rules in the preset template library to obtain the matched first target port signal naming rules. The first signal parameters are processed according to the first target port signal naming rules to generate standardized first signal code information; Add the type of the first hardware description language and the name of the first module to the first signal code information to obtain the second signal code information; Generate a standardized first timing constraint file and a first power domain constraint file based on the first physical implementation requirements; The first timing constraint file and the first power domain constraint file are added to the second signal code information to obtain the standardized top-level code.

4. The method according to claim 3, characterized in that, The step of adding the first timing constraint file and the first power domain constraint file to the second signal code information to obtain the normalized top-level code includes: The first timing constraint file and the first power domain constraint file are added to the second signal code information to obtain the third signal code information; Generate the empty space for the first design behavior logic; The acquired first design behavior logic code is written into the empty position and combined with the third signal code information to generate the standardized top-level code.

5. The method according to claim 2, characterized in that, When the design direction type is a reverse parsing design type, the step of generating standardized top-level code based on the design direction type and the port signal naming rules of the preset template library includes: The port signals of the hardware description language code in the non-preset format are parsed to obtain the type of the second hardware description language or the second module name corresponding to the hardware description language code in the non-preset format. Based on the type of the second hardware description language or the name of the second module, match the type of the historical hardware description language or the name of the historical module in the preset template library; If the type of the second hardware description language or the name of the second module is not matched in the preset template library, the description information contained in the hardware description language code under the non-preset format is extracted. A format object is generated based on the description information, wherein the format object is used to characterize the description information; Obtain supplementary information to fill in the format object, thus obtaining the target format object; Obtain the second port signal type contained in the target format object; Based on the second signal parameters in the second port signal type, they are matched with the port signal naming rules in the preset template library to obtain the matched second target port signal naming rules; The second signal parameters are processed according to the second target port signal naming rules to generate standardized fourth signal code information; The type of the second hardware description language and the name of the second module are added to the fourth signal code information to obtain the fifth signal code information; Extract the second physical implementation requirements from the hardware description language code in the non-preset format; Based on the second physical implementation requirements, a standardized second timing constraint file and a second power domain constraint file are generated. The second timing constraint file and the second power domain constraint file are added to the fifth signal code information to obtain the standardized top-level code.

6. The method according to claim 5, characterized in that, The step of adding the second timing constraint file and the second power domain constraint file to the fifth signal code information to obtain the normalized top-level code includes: The second timing constraint file and the second power domain constraint file are added to the fifth signal code information to obtain the sixth signal code information; Call the second design behavior logic code; The second design behavior logic code is combined with the sixth signal code information to generate standardized top-level code.

7. The method according to claim 5, characterized in that, After matching the type or module name of a historical hardware description language in a preset template library based on the type or module name of the second hardware description language, the method further includes: If the type of the second hardware description language or the name of the second module is matched in the preset template library, then the third port signal type corresponding to the hardware description language code in the non-preset format is obtained according to the type of the second hardware description language or the name of the second module. Based on the third signal parameters in the third port signal type, they are matched with the port signal naming rules in the preset template library to obtain the matched third target port signal naming rules; The third signal parameters are processed according to the third target port signal naming rules to generate standardized seventh signal code information; The type of the second hardware description language and the name of the second module are added to the seventh signal code information to obtain the eighth signal code information; Extract the third physical implementation requirements from the hardware description language code in the non-preset format; Based on the aforementioned third physical implementation requirements, a standardized third timing constraint file and a third power domain constraint file are generated. The third timing constraint file and the third power domain constraint file are added to the eighth signal code information to obtain the standardized top-level code.

8. The method according to claim 7, characterized in that, The step of adding the third timing constraint file and the third power domain constraint file to the eighth signal code information to obtain the normalized top-level code includes: The third timing constraint file and the third power domain constraint file are added to the eighth signal code information to obtain the ninth sub-code information; Call the third design behavior logic code; The third design behavior logic code is combined with the ninth sub-code information to generate standardized top-level code.

9. The method according to claim 5, characterized in that, The method further includes: The target format object is written into the preset template library to obtain the preset template library with the target format object added.

10. A device for generating design information for intellectual property cores, characterized in that, include: The acquisition module is used to acquire the design-related information of the input intellectual property core; The determination module is used to determine the current design direction type based on the design association information; The generation module is used to generate standardized top-level code according to the design direction type and the port signal naming rules of the preset template library. The standardized top-level code includes standardized signal code information, standardized timing constraint files, and standardized power domain constraint files.

11. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the steps of the design information generation method for intellectual property cores as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the design information generation method for intellectual property cores as described in any one of claims 1 to 9.

Images