Method, device, equipment and medium for multi-IP comparison
By automatically generating multiple IP use cases and synthesizing them in the top-level module, the problems of high process repetition and scattered results in multi-IP design are solved, thereby improving the efficiency and accuracy of chip design.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-17
- Publication Date
- 2026-04-10
AI Technical Summary
In digital integrated circuit design, when performing synthesis processes on multiple IPs, there are problems such as high process repetition, linear accumulation of waiting time, and scattered results, which leads to slow chip design iteration speed.
By automatically generating multiple IP use cases and embedding them into the top-level module, determining the connection relationship and configuring the clock, performing synthesis, and extracting logic level and resource usage data, the comparison of multiple IPs can be achieved.
It reduces repetitive synthesis steps, saves time, avoids clock confusion across IP use cases, improves the overall efficiency of digital integrated circuit design, and assists designers in efficiently evaluating the timing characteristics of each IP.
Smart Images
Figure CN121835531A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of digital integrated circuit design, in particular to a method, device, equipment and medium for multi-IP comparison. BACKGROUND
[0002] In the process of digital integrated circuit design, the logic level number and resource comparison of intellectual property (IP) is a key link for evaluating the design, ensuring the performance and cost adaptation of the chip. The logic level number reflects the logic gate level that the signal goes through from input to output, and the resource covers logic gates, registers, memories and other hardware units, which are directly related to the timing, power consumption and manufacturing cost of the chip. With the increasing complexity of chip functions, the number of IPs integrated in a single chip is increasing. For example, in a system on chip (Soc) design, multiple IPs are often integrated to handle different functions.
[0003] In the related art, the synthesis process is performed on multiple IPs in sequence, which has high process repetition, linearly accumulated waiting time and scattered results. SUMMARY
[0004] The present application provides a method, device, equipment and medium for multi-IP comparison to solve the problem of high process repetition, linearly accumulated waiting time and scattered results in the synthesis process performed on multiple IPs in sequence.
[0005] In a first aspect, the present application provides a method for multi-IP comparison, the method comprising: obtaining configuration parameters of a target IP and a value range of the configuration parameters, generating multiple IP use cases based on the configuration parameters and the value range; embedding the multiple IP use cases in a top-level module, determining the connection relationship between the IP use cases and the top-level module, configuring a clock corresponding to each IP use case for each IP use case, and generating a target top-level module integrating the multiple IP use cases; synthesizing the target top-level module, extracting the logic level number and / or resource occupation data of the multiple IP use cases in the synthesis result, and comparing the multiple IP use cases based on the extracted data.
[0006] In an optional implementation, the generating multiple IP use cases based on the configuration parameters and the value range comprises: generating different configuration parameter combinations within the value range based on the configuration parameters and the value range; constructing an IP generation framework including placeholders, calling a target unit in a primitive library based on the configuration parameter combinations, embedding the target unit in the corresponding position of the IP generation framework, and replacing the placeholders based on the parameters in the configuration parameter combinations to obtain the IP use cases.
[0007] In one optional implementation, embedding the plurality of IP use cases into a top-level module and determining the connection relationship between the IP use cases and the top-level module includes: generating an IP instantiation module in the top-level module based on the IP use cases; performing port connections between the IP instantiation module and the top-level module based on predefined rules; and configuring a clock corresponding to each IP use case for each IP use case when the port connections are correct.
[0008] In one optional implementation, configuring a clock corresponding to each of the IP use cases includes: configuring a clock network for each of the IP use cases; and configuring port delay parameters for the non-clock interfaces in each of the IP use cases.
[0009] In one optional implementation, the extraction of the logical levels and / or resource usage data of the multiple IP use cases in the synthesis results includes: extracting the logical levels and / or resource usage data of the multiple IP use cases in the synthesis results based on different clocks.
[0010] In one optional implementation, obtaining the configuration parameters of the target IP and the value range of the configuration parameters includes: obtaining a test case table, and extracting the configuration parameters of the target IP and the value range of the configuration parameters based on the test case table.
[0011] In one optional implementation, generating different combinations of configuration parameters within the value range based on the configuration parameters and the value range includes: randomly generating different combinations of configuration parameters within the value range based on the configuration parameters and the value range.
[0012] Secondly, this application provides an apparatus for multi-IP comparison, the apparatus comprising: an acquisition module, configured to acquire configuration parameters of a target IP and the value range of the configuration parameters, and generate multiple IP use cases based on the configuration parameters and the value range; a generation module, configured to embed the multiple IP use cases into a top-level module, determine the connection relationship between the IP use cases and the top-level module, configure a clock corresponding to each IP use case, and generate a target top-level module integrating the multiple IP use cases; and a synthesis module, configured to synthesize the target top-level module, extract the logical level and / or resource usage data of the multiple IP use cases from the synthesis result, and compare the multiple IP use cases based on the extracted data.
[0013] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the method for multi-IP comparison described in the first aspect or any corresponding embodiment.
[0014] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to perform the method for multi-IP comparison described in the first aspect or any corresponding embodiment thereof.
[0015] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to execute the method for multi-IP comparison described in the first aspect or any corresponding embodiment thereof.
[0016] The method, apparatus, device, and medium for multi-IP comparison provided in this embodiment automatically generate multiple IP use cases and encapsulate them into a top-level module. This eliminates the need to create a separate project for each IP, reducing repetitive synthesis steps, saving synthesis time, and solving the problem of low efficiency in synthesizing individual IP cores. Furthermore, independent clock binding for each IP use case avoids clock confusion across IP use cases. In addition, comparing the logic levels of multiple IPs in a unified environment helps designers efficiently evaluate the timing characteristics of each IP, improving the overall efficiency of digital integrated circuit design. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0018] Figure 1 A flowchart illustrating a method for multi-IP comparison according to an embodiment of this application is shown; Figure 2 Another flowchart illustrating the method for multi-IP comparison according to an embodiment of this application is shown; Figure 3 A schematic diagram illustrating the top-level module's comprehensive execution flow according to an embodiment of this application is shown; Figure 4 An architecture diagram of a method for multi-IP comparison according to an embodiment of this application is shown; Figure 5 A schematic diagram of the apparatus for multi-IP comparison according to an embodiment of this application is shown; Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.
[0021] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.
[0022] In the digital integrated circuit design flow, comparing the logic levels of multiple IPs is a crucial step in evaluating IP design suitability and ensuring system timing performance. In related technologies, comparing the logic levels and resources of IPs commonly involves running a synthesis process independently for each individual IP.
[0023] In real-world projects, when it is necessary to evaluate the logic levels (e.g., reflecting signal transmission delay and affecting chip timing performance) and resource consumption (e.g., the usage of hardware resources such as registers or lookup tables, which are related to chip area and cost) of different IPs in multiple scenarios, performing the synthesis process separately for each IP has the following drawbacks: On the one hand, the synthesis process for a single IP involves multiple time-consuming steps such as syntax parsing, logic optimization, and mapping to a specific process library, which requires a large amount of computing resources and time; on the other hand, performing the aforementioned synthesis process sequentially for multiple IPs results in high process repetition, linearly accumulating waiting time, and scattered results. Digital integrated circuit designers need to integrate and compare the results of multiple IPs, which is inefficient and greatly slows down the pace of chip design iteration.
[0024] Especially in scenarios with a large number of IPs and the need for frequent iterations and optimizations, the methods in related technologies can lead to extended development cycles, making it difficult to quickly obtain multi-IP comparison data to support design decisions, which is not conducive to rapid optimization in the early stages of design.
[0025] According to an embodiment of this application, a method embodiment for multi-IP comparison is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0026] This embodiment provides a method for comparing multiple IP addresses, which can be used in terminal devices, such as desktop computers or laptops. Figure 1 A flowchart illustrating a method for multi-IP comparison according to an embodiment of this application is shown, as follows: Figure 1 As shown, the process includes the following steps: Step S201: Obtain the configuration parameters of the target IP and the value range of the configuration parameters. Based on the configuration parameters and the value range, generate multiple IP use cases.
[0027] In this step, the target IP is used to represent the IP core to be compared in terms of logical levels and / or resource consumption. Configuration parameters are used to represent the configurable attributes of the target IP, including but not limited to functional and performance parameters. The value range of the configuration parameters is used to represent the dependencies or constraints between configuration parameters, which can avoid invalid configurations. IP use cases are used to represent IP core instances with actual functionality generated based on different configuration parameters. For example, each IP use case corresponds to a set of configuration parameter combinations.
[0028] In step S201, based on the planned test scenario, the configurable parameters and constraint information (i.e., parameter limitations) of the target IP can be obtained. Then, based on this information, multiple IP instances with different combinations of configuration parameters can be generated. The generated IP test cases conform to the parameter limitations, which can avoid invalid configurations. Specifically, for Block RAM IP, IP test cases with a depth of 8 bits × 512, 16 bits × 1024, or 32 bits × 512 can be generated.
[0029] Step S202: Embed multiple IP use cases into the top-level module, determine the connection relationship between the IP use cases and the top-level module, configure the clock corresponding to each IP use case, and generate a target top-level module that integrates multiple IP use cases.
[0030] In this step, the top-level module defines the system's external interfaces, integrates all sub-modules (e.g., IP use cases), manages multiple IP cores uniformly, and builds a unified synthesis environment. The top-level module is the hub for logical hierarchy or resource comparison. After automatically generating the target IP core, the system's overall scheduling and data comparison can significantly reduce the time cost of synthesis. The target top-level module represents the top-level module after embedding multiple IP use cases and completing signal connections and clock configuration.
[0031] Specifically, the multiple IP use cases generated in step S201 are embedded into the top-level module, the signal connection relationship between the IP and the top-level module is automatically determined, and an independent clock is configured for each IP use case to obtain the target top-level module that integrates all IP use cases.
[0032] Step S203: Synthesize the target top-level module, extract the logical level and / or resource usage data of multiple IP use cases from the synthesis results, and compare the multiple IP use cases based on the extracted data.
[0033] In this step, synthesis is used to characterize logic synthesis. It involves using Electronic Design Automation (EDA) tools to convert Hardware Description Language (RTL) code—the functional description of the target top-level module—into a process-dependent gate-level netlist, simultaneously outputting resource usage and timing data. The number of logic levels characterizes the number of logic gates a signal passes through from IP input to output, reflecting the IP's timing performance; fewer levels indicate lower latency. Resource usage data characterizes the hardware resources used by the IP core.
[0034] Specifically, logical synthesis is performed on the target top-level module. The logical level of each IP use case is extracted from the synthesis result, or the resource consumption data of each IP use case is extracted from the synthesis result, or the logical level and resource consumption data of each IP use case are extracted from the synthesis result. Then, a horizontal comparison of different IP use cases is completed based on these data.
[0035] The method for multi-IP comparison provided in this embodiment automatically generates multiple IP use cases and encapsulates them into a top-level module. This eliminates the need to create a separate project for each IP, reducing repetitive synthesis steps, saving synthesis time, and solving the problem of low efficiency in synthesizing individual IP cores. Furthermore, independent clock binding for each IP use case avoids clock confusion across IP use cases. In addition, comparing the logic levels of multiple IPs in a unified environment helps designers efficiently evaluate the timing characteristics of each IP, improving the overall efficiency of digital integrated circuit design.
[0036] This embodiment provides a method for multi-IP comparison, which can be used in the aforementioned terminal devices. Figure 2 Another flowchart illustrating the method for multi-IP comparison according to an embodiment of this application is shown, such as... Figure 2 As shown, the process includes the following steps: Step S301: Obtain the configuration parameters of the target IP and the value range of the configuration parameters. Based on the configuration parameters and the value range, generate multiple IP use cases.
[0037] Specifically, step S301 includes: Step S3011: Based on the configuration parameters and their value range, determine the value range of the configuration parameters, and generate different combinations of configuration parameters within the value range.
[0038] In this step, the value range of the configuration parameters includes the set of legal values for each configuration parameter, which can be determined after filtering by the constraint information between the parameters. The configuration parameter combination is used to represent the legal combination of multiple parameters selected from the value range.
[0039] Specifically, the value range of each configuration parameter can be determined through a script, and then combinations of configuration parameters that do not violate the constraints can be selected from the value range. A unique identifier can be assigned to each combination. For example, for a BRAM IP, the constraint is that when the bit width is 32 bits, the depth is ≤1024. The value range is bit width [8, 16, 32] and depth [256, 512, 1024]. After removing 32 bits + 2048 depth, six combinations can be generated.
[0040] Step S3012: Construct an IP generation framework including placeholders, call the target unit in the primitive library based on the configuration parameter combination, embed the target unit into the corresponding position of the IP generation framework, replace the placeholders based on the parameters in the configuration parameter combination, and obtain the IP use case.
[0041] In this step, placeholders represent configuration parameters or logical placeholders embedded in the IP generation framework, which are used to replace specific values or functional logic later. For example, placeholders can correspond to configurable parameters such as data bit width or interface mode. The IP generation framework is used to represent a pre-built general code framework containing placeholders that separates the general logical framework of the IP from configurable parameters. The IP generation framework includes generation logic and template files, and is the core logic for automatically generating IP cores. It can automatically generate the hardware implementation code and constraint files of the IP core based on the combination of configuration parameters.
[0042] Parameterized timing and physical constraints can be defined in a manner similar to separating the general logical framework and configurable parameters of an IP. In this architecture, only timing constraints are applied, and delays are applied to each structure. A generator script serves as an intermediate driving layer, responsible for parsing the configuration parameters input by the user. Through template engines or toolchain commands, the parameters are replaced into placeholders in the template. Finally, synthesizable code and constraint files adapted to specific configurations are output, thereby enabling rapid instantiation of the same IP core under different parameters, avoiding redundant development and ensuring code consistency.
[0043] Each primitive in the primitive library corresponds to a behavioral model. These behavioral models use a hardware description language (Verilog HDL, or Verilog for short) to describe the function and behavior of different primitives in logic circuits. A primitive is the smallest functional unit in a Field-Programmable Gate Array (FPGA) chip and can be directly mapped to hardware resources. Primitives are a series of low-level logic functional units provided by the FPGA software integration development environment, used to implement basic operations and functions in digital logic circuits. Target units are used to represent primitives selected from the primitive library that match the current combination of configuration parameters. During the automated generation of IP cores, by calling and combining these basic module behavioral models, complex IP core logic functions are constructed, providing the basic building blocks for the implementation of IP core functions.
[0044] Specifically, the IP generation framework is pre-configured, and then the corresponding target unit is selected from the primitive library according to a certain combination of configuration parameters and embedded in the specified position of the IP generation framework. Finally, the placeholders in the IP generation framework are replaced with the specific parameters of the combination to generate a complete IP use case.
[0045] Step S302 involves embedding multiple IP use cases into the top-level module, determining the connection relationship between the IP use cases and the top-level module, configuring a clock corresponding to each IP use case, and generating a target top-level module integrating multiple IP use cases. For details, please refer to [link to relevant documentation]. Figure 1 Step S202 of the illustrated embodiment will not be described again here.
[0046] Step S303: Synthesize the target top-level module, extract the logical levels and / or resource usage data of multiple IP use cases from the synthesis results, and compare the multiple IP use cases based on the extracted data. For details, please refer to [link to details]. Figure 1 Step S203 of the illustrated embodiment will not be described again here.
[0047] The method for multi-IP comparison provided in this embodiment can generate multiple IP test cases at once through automated script parsing and constraint verification. This reduces the time testers spend manually configuring IP cores, decreases manpower burden, and improves configuration accuracy. At the same time, all IP test cases are based on a unified IP generation framework, with consistent code structure and port definitions, differing only in parameters and target units. The target units come from a unified primitive library, and the underlying logic mapping rules are consistent, ensuring a unified statistical benchmark for resource consumption and logic levels during subsequent synthesis, thereby improving the reliability of the comparison results.
[0048] In some optional implementations, multiple IP use cases are embedded in the top-level module, and the connection relationship between the IP use cases and the top-level module is determined, including: generating an IP instantiation module in the top-level module based on the IP use cases, and making port connections between the IP instantiation module and the top-level module based on predefined rules; and configuring a clock corresponding to each IP use case for each IP use case when the port connection is correct.
[0049] In this implementation, the IP instantiation module represents the instantiated code snippet embedded in the top-level module, generated based on the IP use case. This includes the module name, parameter configuration, or port interface of the IP use case, and represents the actual entity running the IP use case within the top-level module. Predefined rules represent the pre-defined port connection specifications between the IP and the top-level module, serving as the basis for standardized connections and avoiding the randomness of manual wiring. Port connections represent establishing a one-to-one mapping between the input or output ports of the IP instantiation module and the corresponding signals of the top-level module. The clock corresponding to the IP use case represents a dedicated clock signal allocated individually to each IP use case, with each IP corresponding to a unique clock port (e.g., clk_ip_0 corresponds to the first IP), thus avoiding clock domain confusion.
[0050] Figure 3 A schematic diagram illustrating the synthesis process of the top-level module in an embodiment of this application is shown. Figure 3 As shown, the top-level module executes the synthesis process, including: Step S401, reading the multi-IP core top-level instantiation file; Step S402, parsing the multi-IP core top-level instantiation file to obtain module name, parameter configuration, and interface definition data, etc.; Step S403, generating an IP instantiation module library based on the parsed data; Step S404, automatically generating top-level connection logic based on the IP instantiation module library; Step S405, verifying whether the port connection is correct. If incorrect, proceed to Step S406; if correct, proceed to Step S407; Step S406, reporting and marking errors; Step S407, processing the clock of each IP core individually; Step S408, establishing a unified synthesis environment.
[0051] like Figure 3As shown, the top-level module pre-reads the automatically generated top-level instantiation file of the IP cores, automatically identifying key information of all instantiated IP cores, such as module names, parameter configurations, and interface connection relationships, replacing the inefficiency and error-proneness of manual sorting. Based on this information, it automatically generates instantiation modules for each IP core at the top level and performs wiring connections to ensure the correctness of IP core input / output port connections. Individual clock connection processing is performed for each IP core, establishing a mapping relationship between the IP core and the integrated resources, avoiding result deviations due to environmental differences, and providing a consistent benchmark for subsequent resource comparisons. Through process standardization and automation, the top-level module transforms the traditional inefficient method of distributing multiple IP cores and manually sorting and comparing them into a highly efficient solution that achieves full coverage in a single integration.
[0052] Specifically, a script tool can read the metadata of each IP use case, call the IP instantiation module to automatically replace the placeholders with the actual information of the IP use case, and embed the generated instantiation code snippet into the IP instance reserved area of the top-level module. The script reads the rule base and the identifiers of the IP use cases, automatically matches the ports of the IP instantiation module with the top-level signals, populates the port list of the IP instantiation module, and completes the signal mapping.
[0053] Check if the port bit width matches; check if the port types are consistent. If there is an error, report the error and mark it. If there is no error, proceed to the next step, namely, process the clock separately and establish a unified integrated environment.
[0054] In this way, by automatically generating instantiated modules through scripts and connecting ports according to predefined rules, errors caused by manual connection can be eliminated, improving generation efficiency. At the same time, the port connection verification step intercepts problems such as bit mismatch and type conflict in advance, which can prevent these errors from entering the synthesis process and significantly save computing resources and time.
[0055] In some optional implementations, a clock corresponding to each IP use case is configured for each IP use case, including: configuring a clock network for each IP use case; and configuring port delay parameters for non-clock interfaces in each IP use case.
[0056] In this implementation, the timing constraints for IP cores are achieved by constructing independent timing domains for different IP cores and applying unified delay rules. Constructing independent timing domains for heterogeneous IP cores maintains consistency in timing values and reduces the impact of different environments. For non-clock interfaces within the IP cores, fixed delay constraints are added, allowing synthesis tools to more accurately simulate signal transmission delays in actual circuits, ensuring the correctness of timing analysis and logic levels.
[0057] Specifically, a unique clock input port can be assigned to each IP use case in the top-level module. The port name can be standardized according to the IP identifier and clock identifier. These ports can also be declared in the top-level module code. Then, according to the timing requirements of the IP use case, the clock port of each IP is bound to the corresponding clock source via a script.
[0058] In this way, timing constraint modules are automatically generated for each IP use case, and clock network and port delay parameters are configured, which can ensure the independence of timing analysis. At the same time, separate clock connection processing is performed for each IP core to establish a mapping relationship between IP cores and comprehensive resources, avoiding result deviations caused by environmental differences and providing a consistent benchmark for subsequent resource comparisons.
[0059] In some optional implementations, the logical levels and / or resource usage data of multiple IP use cases in the synthesis results are extracted, including: extracting the logical levels and / or resource usage data of multiple IP use cases in the synthesis results based on different clocks.
[0060] In this implementation, a script reads the clock configuration file, extracts the clock identifier, and generates a mapping table between clocks and IP use cases. After synthesis, an EDA tool outputs a timing report and a resource report, with data recorded in the reports based on clock domain classification. The script can call the EDA tool's API or directly parse the report to extract the gate hierarchy number of the critical path for each IP use case and the amount of resources consumed independently by each IP use case under each clock domain. The mapping table between clocks and IP use cases is traversed, and the data corresponding to the clocks in the synthesis report is filtered. The filtered clock data is then bound to the IP use case identifier and configuration parameters, and the binding results are presented.
[0061] The synthesized logic levels and resources are automatically integrated, clearly presenting the synthesized results of multiple IP cores. The logic levels of each IP core are split according to the different clock domains configured, and the resource report naturally follows the IP core instance hierarchy statistics, forming a correlation with the logic levels. The resource report integrates data from various IP cores, facilitating researchers to quickly locate timing bottlenecks and resource waste points in individual modules. It provides quantitative evidence for researchers' decisions throughout the entire process from IP core optimization to system architecture adjustment, improving design efficiency, reducing optimization costs, and accelerating design convergence.
[0062] In this way, a separate clock domain is constructed for the instantiated IP cores, avoiding cross-IP core clock domain confusion and ensuring that timing reports can be filtered by IP dimension. At the same time, the logic level and resource comparison reports are automatically integrated, making the final results clearer and easier for researchers to locate logic level anomalies and resource waste in IP cores. In addition, it provides researchers with efficient and accurate decision support for design optimization and architecture adjustment in multi-IP core integration scenarios, significantly shortening the cycle from design iteration to result verification, and reducing errors caused by manual operation through standardized processes.
[0063] In some optional implementations, obtaining the configuration parameters of the target IP and the range of values for the configuration parameters includes: obtaining a test case table, and extracting the configuration parameters of the target IP and the range of values for the configuration parameters based on the test case table.
[0064] In this embodiment, the test case table includes descriptive information related to the target IP. Configuration parameters, such as IP type, bit width, or depth, can be extracted from the test case table. The table can also be used to extract the possible values of these configuration parameters and the constraints between them. Furthermore, a parameterized configuration space can be constructed based on the configuration parameters and their value ranges. Subsequently, combinations of configuration parameters can be determined based on this parameterized configuration space. The IP type includes basic information such as the IP core name, version, and description, clearly defining the functional category of the required IP.
[0065] Configuration parameters may also include the test case name and initialization configuration data. The test case name identifies the filename of the test case to be tested. The initialization configuration data includes the range of configurable parameters, such as data bit width, clock frequency, and functional mode. Specifically, for BRAM storage IPs, the bit width and depth define the IP core's data processing capability and storage capacity, while the clock frequency defines its operating clock conditions. For each IP core to be generated, there is a corresponding line of data in the IP core definition and configuration file, used to automatically generate the target IP core. The target IP core can be generated and instantiated within the given parameter values and constraints.
[0066] In this way, by reading the test case table, the target IP desired by the user can be automatically generated, which greatly reduces the time testers spend manually configuring IP cores, reduces the manpower burden, improves the correctness of configuration, improves the efficiency of IP core testing, and solves the problems of many IP core parameters, cumbersome configuration, and easy errors in manual configuration.
[0067] Figure 4 An architecture diagram of a method for multi-IP comparison according to an embodiment of this application is shown. Figure 4As shown, the architecture of the method for multi-IP comparison in this application embodiment includes: an extraction module 501, which obtains a test case table; based on the test case table, it extracts the configuration parameters of the target IP, as well as the possible values of the parameters and the mutual constraint information between the parameters, and constructs a parameterized configuration space. The configuration parameters of the target IP include: IP type, bit width, depth, etc. An instantiation module 502, which parses the IP test case requirements, automatically generates multi-scenario IP test cases, and automatically generates timing constraints corresponding to the IP test cases. A top-level synthesis control module 503, which automatically embeds the top-level synthesis control module according to the instantiated IP core instantiation template, completes signal connection and bus mapping based on predefined rules, automatically generates a timing constraint module for each top-level instantiated IP core, configures clock network and port delay parameters, and ensures the independence of timing analysis. A synthesis execution module 504, which executes a single synthesis process, automatically parses the synthesis results, and extracts the logic level and resource usage data of the target IP core. The results generation module 505 generates a comparison report based on the logical levels and resource usage data of the target IP core.
[0068] In this way, multi-IP scenarios for test cases are generated through automated scripts, a unified top-level file is designed for scenario instantiation, a shared resource detection layer is built, and corresponding timing constraints are formed. After the synthesis is completed, the logical levels and resource usage data of multiple IPs are extracted and classified from the synthesis report to generate a multi-IP comparison report.
[0069] In some optional implementations, different combinations of configuration parameters are generated within the value range based on the configuration parameters and the value range, including: randomly generating different combinations of configuration parameters within the value range based on the configuration parameters and the value range.
[0070] In this implementation, configuration parameters and their value ranges can be read using a script. For each configuration parameter, valid values are filtered based on the constraint information between parameters to obtain the mapping relationship between configuration parameters and valid values. Based on the script, values are randomly extracted according to parameter dimensions to generate configuration parameter combinations.
[0071] In this way, random generation without human intervention can evenly cover all scenarios within the legal range; at the same time, all combinations are generated based on the same legal value range and the same constraint rules, and subsequent IP use case generation and synthesis are based on a unified framework. The randomness of the combination only affects the scenario coverage and does not change the comparison benchmark. The final extracted logical levels and resource data still have fair comparability.
[0072] This embodiment also provides an apparatus for multi-IP comparison, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0073] This embodiment provides a device for multi-IP comparison. Figure 5 A schematic diagram of the apparatus for multi-IP comparison according to an embodiment of this application is shown, such as... Figure 5 As shown, it includes: The acquisition module 601 is used to acquire the configuration parameters of the target IP and the range of values for the configuration parameters, and to generate multiple IP test cases based on the configuration parameters and the range of values.
[0074] The generation module 602 is used to embed multiple IP use cases into the top-level module, determine the connection relationship between the IP use cases and the top-level module, configure the clock corresponding to each IP use case, and generate a target top-level module that integrates multiple IP use cases.
[0075] The synthesis module 603 is used to synthesize the target top-level module, extract the logical level and / or resource usage data of multiple IP use cases from the synthesis results, and compare multiple IP use cases based on the extracted data.
[0076] In some alternative implementations, the acquisition module 601 includes: The first unit of the acquisition module is used to generate different combinations of configuration parameters within the value range based on configuration parameters and value range; construct an IP generation framework including placeholders; call the target unit in the primitive library based on the configuration parameter combination; embed the target unit into the corresponding position of the IP generation framework; replace the placeholders based on the parameters in the configuration parameter combination to obtain IP use cases.
[0077] In some alternative implementations, the generation module 602 includes: The first unit of the generation module is used to generate IP instantiation modules in the top-level module based on IP use cases, and to establish port connections between the IP instantiation modules and the top-level module based on predefined rules; if the port connections are correct, it configures the clock corresponding to each IP use case.
[0078] In some alternative implementations, the generation module 602 further includes: The second unit of the generation module is used to configure the clock network for each IP use case and to configure port delay parameters for the non-clock interfaces in each IP use case.
[0079] In some alternative implementations, the integration module 603 includes: The first unit of the synthesis module is used to extract the logic level and / or resource usage data of multi-IP use cases from the synthesis results based on different clocks.
[0080] In some optional implementations, the acquisition module 601 further includes: The second unit of the acquisition module is used to acquire the test case table, and based on the test case table, extract the configuration parameters of the target IP and the value range of the configuration parameters.
[0081] In some optional implementations, the first unit of the acquisition module includes: The first subunit of the first unit of the module is used to randomly generate different combinations of configuration parameters within the value range based on the configuration parameters and the value range.
[0082] The apparatus for multi-IP comparison provided in this application can execute the method for multi-IP comparison provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.
[0083] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application.
[0084] The following is a detailed reference. Figure 6 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 701, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 702 or a program loaded from memory 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the electronic device. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.
[0085] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 6Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.
[0086] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 709, or installed from memory 708, or installed from ROM 702. When the computer program is executed by processor 701, it performs the functions defined in the method for multi-IP comparison of embodiments of this application.
[0087] Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0088] This application also provides a computer-readable storage medium. The methods described above according to this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the method for multi-IP comparison shown in the above embodiments is implemented.
[0089] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.
[0090] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.
Claims
1. A method for comparing multiple IPs, characterized in that, The method includes: Obtain the configuration parameters of the target IP and the value range of the configuration parameters, and generate multiple IP use cases based on the configuration parameters and the value range; The multiple IP use cases are embedded into the top-level module, the connection relationship between the IP use cases and the top-level module is determined, a clock corresponding to each IP use case is configured, and a target top-level module integrating the multiple IP use cases is generated. The target top-level module is integrated, and the logical level and / or resource usage data of the multiple IP use cases in the integration result are extracted. The multiple IP use cases are compared based on the extracted data.
2. The method according to claim 1, characterized in that, Based on the configuration parameters and the value range, multiple IP use cases are generated, including: Based on the configuration parameters and the value range, different combinations of configuration parameters are generated within the value range; An IP generation framework including placeholders is constructed. The target unit in the primitive library is called based on the configuration parameter combination. The target unit is embedded in the corresponding position of the IP generation framework. The placeholder is replaced based on the parameters in the configuration parameter combination to obtain the IP use case.
3. The method according to claim 1, characterized in that, The step of embedding the multiple IP use cases into the top-level module and determining the connection relationship between the IP use cases and the top-level module includes: Based on the IP use case, an IP instantiation module is generated in the top-level module, and port connections between the IP instantiation module and the top-level module are made based on predefined rules. If the port connection is correct, configure a clock corresponding to each IP use case.
4. The method according to claim 1, characterized in that, The step of configuring a clock corresponding to each of the IP use cases includes: Configure a clock network for each of the described IP use cases; Configure port delay parameters for the non-clocked interfaces in each of the described IP use cases.
5. The method according to claim 1, characterized in that, The logical levels and / or resource usage data of the multiple IP use cases extracted from the comprehensive results include: Based on different clocks, extract the logic levels and / or resource usage data of the multiple IP use cases mentioned in the synthesis results.
6. The method according to claim 1, characterized in that, The configuration parameters for obtaining the target IP and the range of values for the configuration parameters include: Obtain the test case table, and based on the test case table, extract the configuration parameters of the target IP and the value range of the configuration parameters.
7. The method according to claim 2, characterized in that, The step of generating different combinations of configuration parameters within the value range based on the configuration parameters and the value range includes: Based on the configuration parameters and the value range, different combinations of configuration parameters are randomly generated within the value range.
8. An apparatus for multi-IP comparison, characterized in that, The device includes: The acquisition module is used to acquire the configuration parameters of the target IP and the value range of the configuration parameters, and generate multiple IP use cases based on the configuration parameters and the value range; A generation module is used to embed the multiple IP use cases into a top-level module, determine the connection relationship between the IP use cases and the top-level module, configure a clock corresponding to each IP use case, and generate a target top-level module that integrates the multiple IP use cases. The synthesis module is used to synthesize the target top-level module, extract the logical level and / or resource usage data of the multiple IP use cases in the synthesis result, and compare the multiple IP use cases based on the extracted data.
9. An electronic device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method for multi-IP comparison as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method for multi-IP comparison as described in any one of claims 1 to 7.