Power consumption evaluation method and device, electronic equipment, storage medium and program product

Abstract

The invention relates to a power consumption evaluation method and device, electronic equipment, a storage medium and a program product, and belongs to the field of computers. The power consumption evaluation method comprises the steps that a plurality of function coverage bins in one-to-one correspondence with different values are defined in a simulation environment for different values of key power consumption attributes in a current version designed for an RTL to be evaluated, the key power consumption attributes are attributes which can be monitored in simulation, and the values of the key power consumption attributes are related to RTL power consumption; operating the target test scene in the simulation environment, and counting the hit times of each function coverage bin in the whole simulation operation stage; and evaluating the average power consumption in the target test scene according to pre-acquired reference power consumption values of the key power consumption attributes under different values and the hit times of the functional coverage bins. According to the method, the average power consumption of the to-be-evaluated RTL design in various scenes can be estimated in an earlier design stage (such as an RTL stage), so that timely optimization can be realized in the RTL stage, and time and cost are greatly saved.

Description

Technical Field

[0001] This application belongs to the field of computer science, and specifically relates to a power consumption assessment method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] Register Transfer Level (RTL) is the core description level of hardware design and a crucial stage for power prediction and optimization. Conducting power assessment at this stage allows for early identification of power hotspots with greater design flexibility and lower modification costs, and effectively reduces dynamic power consumption through RTL-level optimization techniques (such as pipelining and gating). Conversely, postponing power assessment and optimization to the gate-level netlist or physical design stage significantly limits optimization space and increases optimization costs considerably.

[0003] Currently, the main methods used in the industry for power consumption assessment during the RTL stage include: methods based on simulation waveforms (power analysis is performed by mapping RTL simulation waveforms to the netlist after logic synthesis), static power analysis, and early power estimators. While these methods each have their own characteristics, they still have significant limitations in practical applications: they either rely on backend netlists and cannot achieve truly early assessments, or they lack the accuracy to support fine-grained optimization.

[0004] Therefore, existing power consumption assessment methods still face significant challenges in balancing timeliness and accuracy with efficiency. The industry urgently needs a new RTL power consumption assessment method that can be implemented at an earlier design stage and possesses both good engineering practical accuracy and efficient iterative capabilities to better support rapid architecture exploration and agile design optimization. Summary of the Invention

[0005] Therefore, the purpose of this application is to provide a power consumption assessment method, apparatus, electronic device, storage medium, and program product that can estimate the average power consumption of the RTL design to be evaluated in various scenarios at an earlier design stage (such as the RTL stage), so as to enable timely optimization at the RTL stage and greatly save time and cost.

[0006] The embodiments of this application are implemented as follows: In a first aspect, embodiments of this application provide a power consumption evaluation method, comprising: defining multiple functional coverage modules in a simulation environment corresponding one-to-one with different values ​​of key power consumption attributes in the current version of the RTL design to be evaluated, wherein the key power consumption attributes are attributes that can be monitored in the simulation and whose values ​​are related to the power consumption of the RTL; running a target test scenario in the simulation environment and counting the number of hits of each functional coverage module during the entire simulation run phase; and evaluating the average power consumption under the target test scenario based on the pre-acquired baseline power consumption values ​​of the key power consumption attributes under different values ​​and the number of hits of each functional coverage module.

[0007] In the above implementation scheme, the statistical method based on functional coverage shown in this application for evaluating power consumption does not require a gate-level netlist. It only requires defining multiple functional coverage bins (bins) corresponding one-to-one for different key power consumption attribute values ​​in the simulation environment. Then, the target test scenario is run in the simulation environment, and the hit count of each functional coverage bin is counted throughout the simulation run. Combined with the pre-obtained baseline power consumption values ​​of the key power consumption attributes under different values, the average power consumption in the target test scenario can be quickly evaluated. When evaluating power consumption using the above statistical method based on functional coverage, since the baseline power consumption values ​​of the key power consumption attributes under different values ​​have been obtained in advance, only all bins need to be defined subsequently to evaluate the average power consumption of various scenarios. Compared with other evaluation methods, this method has a higher level of abstraction, can evaluate earlier, and also has good engineering practical accuracy.

[0008] In one possible implementation of the first aspect embodiment, the method further includes: simulating the target RTL design to obtain an RTL simulation waveform; mapping the RTL simulation waveform to a netlist obtained after logic synthesis of the target RTL design; and performing power consumption analysis based on the mapped netlist to obtain and store the baseline power consumption values ​​of each key power consumption attribute related to RTL power consumption under different values.

[0009] In the above implementation scheme, by obtaining and storing the baseline power consumption values ​​of each key power consumption attribute related to RTL power consumption under specific values ​​in advance, this step can be skipped when performing power consumption evaluation later, thereby shortening the simulation time and enabling power consumption evaluation to be performed at an earlier design stage (such as the RTL stage).

[0010] In one possible implementation of the first aspect embodiment, the method further includes: during the iteration of the RTL design to be evaluated from the current version to the next version, obtaining a new target test scenario, wherein the new target test scenario is constructed according to the architecture and requirements of the next version; obtaining the number and proportion of each key power consumption attribute in the new target test scenario; and evaluating the expected average power consumption of the next version under the new target test scenario based on the pre-obtained baseline power consumption values ​​of each key power consumption attribute and the number and proportion of each key power consumption attribute in the new target test scenario.

[0011] In the above implementation scheme, when iterating from the current version (e.g., V1.x) to the next version (e.g., V2.x), a new target test scenario can be built based on the architecture and requirements of the next version. Then, the number and proportion of each key power consumption attribute in the new target test scenario can be obtained. Combined with the baseline power consumption values ​​of each key power consumption attribute obtained previously, the expected average power consumption of the next version in the new target test scenario can be evaluated. This allows the relevant power consumption data to be roughly calculated during the architecture exploration phase of the next version, and timely optimization can be achieved during the RTL implementation phase, greatly saving time and costs.

[0012] In one possible implementation of the first aspect embodiment, the key power consumption attribute includes instruction type; defining the function coverage module includes: defining the key power consumption attribute value corresponding to a high power consumption instruction as a high power consumption instruction module; defining the key power consumption attribute value corresponding to an idle instruction as an idle instruction module; defining the key power consumption attribute value corresponding to a low power consumption instruction as a low power consumption instruction module, wherein the low power consumption instruction includes all other instructions except the high power consumption instruction and the idle instruction.

[0013] In the above implementation scheme, since there are many types of instructions, a coarse-grained division can be made, dividing the instruction types into high-power instructions, low-power instructions, and idle instructions, and establishing corresponding bins for each. This can speed up the simulation efficiency and simplify the simulation process.

[0014] In a possible implementation of the first aspect embodiment, the method further includes: during the operation of the target test scenario in the simulation environment, dividing the simulation into multiple simulation time periods based on key signals identifying different operating stages; collecting functional coverage data in each simulation time period; obtaining power consumption evaluation results for the corresponding stage based on the number of hits of each functional coverage module in the functional coverage data collected in different time periods, and based on the baseline power consumption values ​​of the key power consumption attributes obtained in advance under different values; wherein, each simulation time period includes at least two of the following: ramp-up stage, continuous full load stage, and shutdown stage.

[0015] In the above implementation scheme, by obtaining the number of hits of each functional coverage module in the functional coverage data collected in different time periods, and the baseline power consumption value under different values ​​of the key power consumption attributes obtained in advance, the power consumption assessment results of the corresponding stage can be obtained. These data are also crucial for the analysis of some specific needs, such as providing important data support for the backend analysis of dynamic voltage drop (IR Drop) and current change rate (di / dt), and providing in-depth insights into the analysis of system performance bottlenecks and energy efficiency distribution.

[0016] In one possible implementation of the first aspect embodiment, the key power consumption attribute includes at least one of instruction type, data type, and module type.

[0017] In the above implementation scheme, since different attributes correspond to different power consumption, this application identifies and quantifies the specific impact of key power consumption attributes such as instruction type, data type, and module type on the power consumption of RTL design, providing direct data basis and optimization guidance for accurate and efficient optimization of RTL code.

[0018] In one possible implementation of the first aspect embodiment, if the object of the RTL design to be evaluated is a processor core, the key power consumption attribute is the instruction type; if the object of the RTL design to be evaluated is a computing module, the key power consumption attribute is the data type; if the object of the RTL design to be evaluated is a SOC chip, the key power consumption attribute is the module type in the SOC chip.

[0019] In the above implementation scheme, by adaptively selecting the most relevant key power consumption attributes based on the different evaluation objects—for example, specifying instruction type, data type, and module type as the most critical power consumption analysis attributes for three different levels of evaluation objects, such as processor cores, computing modules, and SoC (System on Chip) chips—the accuracy and scientific rigor of power consumption evaluation can be improved. This targeted analysis method avoids the errors caused by using single, general attributes, making the evaluation results closer to the actual hardware behavior, thus providing a reliable basis for subsequent precise optimization.

[0020] Secondly, embodiments of this application also provide a power consumption evaluation device, including: a custom module, a simulation module, and an evaluation module; the custom module is used to define multiple functional coverage modules in a simulation environment corresponding one-to-one with different values ​​of key power consumption attributes in the current version of the RTL design to be evaluated, wherein the key power consumption attributes are attributes that can be monitored in the simulation and whose values ​​are related to the power consumption of the RTL; the simulation module is used to run a target test scenario in the simulation environment and count the number of hits of each functional coverage module during the entire simulation run phase; the evaluation module is used to evaluate the average power consumption under the target test scenario based on the pre-acquired baseline power consumption values ​​of the key power consumption attributes under different values ​​and the number of hits of each functional coverage module.

[0021] Thirdly, embodiments of this application also provide an electronic device, including: a memory and a processor, the processor being connected to the memory; the memory being used to store a program; the processor being used to invoke the program stored in the memory to perform a method provided as described in the first aspect embodiments and / or any possible implementation in conjunction with the first aspect embodiments.

[0022] Fourthly, embodiments of this application also provide a computer-readable storage medium, characterized in that a computer program is stored thereon, which, when executed by a processor, performs the method provided by any possible implementation of the first aspect embodiments and / or in combination with the first aspect embodiments.

[0023] Fifthly, embodiments of this application also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the method provided by any possible implementation of the first aspect embodiment and / or in combination with the first aspect embodiment.

[0024] The technical effects of any of the implementation methods in the second to fifth aspects can be referred to the technical effects of the same or similar implementation methods in the first aspect, and will not be repeated here.

[0025] Other features and advantages of this application will be set forth in the following description. The objectives and other advantages of this application can be realized and obtained through the structures specifically pointed out in the written description and the accompanying drawings. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are only some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings. The above and other objects, features, and advantages of this application will become clearer through the accompanying drawings.

[0027] Figure 1 A flowchart illustrating a power consumption evaluation method provided in an embodiment of this application is shown.

[0028] Figure 2 This illustration shows a schematic diagram of the principle of obtaining a reference power consumption value according to an embodiment of this application.

[0029] Figure 3 The diagram illustrates a power distribution under a high-power, full-load scenario, as provided in an embodiment of this application.

[0030] Figure 4 A schematic diagram illustrating the principle of a power consumption evaluation method provided in an embodiment of this application is shown.

[0031] Figure 5 A schematic diagram of a power consumption evaluation device provided in an embodiment of this application is shown.

[0032] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The following embodiments are provided as examples to more clearly illustrate the technical solutions of this application, and should not be used to limit the scope of protection of this application. Those skilled in the art will understand that, without conflict, the following embodiments and features can be combined with each other.

[0034] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, relational terms such as "first," "second," etc., in the description of this application are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, 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.

[0035] Furthermore, the term "and / or" in this application is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0036] In the description of the embodiments of this application, unless otherwise expressly specified and limited, the technical term "connection" can be a direct connection or an indirect connection through an intermediate medium.

[0037] Current power consumption assessment methods still face significant challenges in balancing timeliness and accuracy with efficiency. For example, methods based on simulation waveforms require running RTL simulations to obtain the waveforms, which can be very time-consuming for large designs and generate huge waveform files (leading to significant storage and processing overhead). Furthermore, logic synthesis is required to obtain the netlist, making independent implementation impossible in earlier architecture or pure RTL stages. While static power analysis and early power estimators do not rely on RTL simulations, their assessment accuracy is low, limiting their reference value. This application provides a novel RTL power consumption assessment method that can be implemented at earlier design stages (such as the RTL stage) and combines good engineering practical accuracy with efficient iterative capabilities. The following section discusses... Figure 1 The power consumption evaluation method provided in the embodiments of this application will be described. The method shown in this application can be applied to electronic devices, which execute the power consumption evaluation method provided in the embodiments of this application in response to user test operations.

[0038] S1: Define multiple functional coverage modules in the simulation environment that correspond one-to-one with the different values ​​of key power consumption attributes in the current version of the RTL design to be evaluated.

[0039] The key power consumption attributes in this application are those that can be monitored in simulation and whose values ​​are related to RTL power consumption. In response to user configuration operations, multiple functional coverage bins (bins) can be defined in the simulation environment, each corresponding to a different value of the key power consumption attribute in the current version of the RTL design to be evaluated. This facilitates subsequent functional coverage statistics. In functional coverage statistics, a bin is the basic unit used to measure the testing status of design attributes. Each bin represents a specific value or a continuous range of values ​​for the key power consumption attribute. These bins can be automatically generated (automatically divided by the simulation tool based on the signal bit width) or user-defined. By counting the number or proportion of times each bin is "hit" (i.e., the attribute value represented by that bin appears) during simulation, the coverage of the key attribute in the test can be quantified. It should be noted that the value of the key power consumption attribute in this application can be a specific value or a range.

[0040] The key power consumption attributes in this application include at least one of the following: instruction type, data type, and module type. Different instruction types correspond to different power consumption; similarly, different data types correspond to different computational power consumption; similarly, different module types correspond to different power consumption. It is understood that for different types of design modules, key power consumption attributes include, but are not limited to, the above three types. Specific attributes need to be extracted based on the specific design module. For example, key power consumption attributes can also be other RTL power consumption-related attributes. When the value of this attribute differs, it will significantly affect the power consumption value. By obtaining the power consumption-related attributes of a certain RTL and statistically analyzing the functional coverage when the attribute has different values ​​under heavy load or typical scenarios, the average power consumption under that scenario can be calculated.

[0041] Taking the key power consumption attribute as the instruction type as an example, different values ​​can represent different instruction types. Among them, the instruction type can be a multiplication instruction, a division instruction, an addition / subtraction instruction, a logic instruction, a memory access instruction, a control instruction, a no instruction, etc., and different instruction types can be represented by different signal values.

[0042] Due to the large variety of instruction types, to accelerate simulation efficiency and simplify the simulation process, in some possible implementations, a coarse-grained classification can be performed, dividing instruction types into high-power instructions, low-power instructions, and idle instructions. For example, instructions with power consumption greater than a preset threshold (configurable) can be categorized as high-power instructions, and all other instructions besides idle and high-power instructions can be categorized as low-power instructions. That is, low-power instructions include all other instructions except for high-power and idle instructions. Taking the key power consumption attribute as an example, the above-described functional coverage bins can include: defining the key power consumption attribute value corresponding to high-power instructions as a high-power instruction bin; defining the key power consumption attribute value corresponding to idle instructions as an idle instruction bin; and defining the key power consumption attribute value corresponding to low-power instructions as a low-power instruction bin. Since there may be a certain type or category of instructions with very high power consumption in the simulation, while the power consumption values ​​of other instructions are relatively lower and tend to be within a certain range, the instructions can be classified, and instruction functional coverage statistics can be performed in the simulation environment. A bin can be created for high-power instructions, another bin for idle instructions, and another bin for all other instructions.

[0043] In some possible implementations, if the RTL design to be evaluated is a processor core, the key power consumption attribute is the instruction type. For example, instruction types include high-power instructions, low-power instructions, and idle instructions. Different values ​​of the key power consumption attribute represent different instruction types; for example, an attribute value of 1 represents a high-power instruction, an attribute value of 2 represents an idle instruction, and an attribute value of 3 represents a low-power instruction. By defining different function coverage bins for different values, the types of instructions can be identified by detecting different signal values ​​during function coverage statistics. Since different instruction types correspond to different power consumptions, the power consumption can be evaluated.

[0044] When the object of the RTL design to be evaluated is a computing module, the key power consumption attribute is the data type. For example, data types include FP32 (floating-point single precision), FP64 (floating-point double precision), I32 (fixed-point integer), and IP32 (fixed-point decimal). Different values ​​of the key power consumption attribute represent different data types. For example, in the RTL code, these correspond to signals such as Gran=0 for FP32, Gran=1 for FP64, Gran=2 for I32, and Gran=3 for IP32. By defining different functional coverage modules for different values, the data types can be identified by detecting different signal values ​​during functional coverage statistics. Since different data types correspond to different power consumptions, the power consumption can be evaluated.

[0045] When the object of the RTL design to be evaluated is a SOC chip, the key power consumption attribute is the module type in the SOC chip. In this case, the key power consumption attribute can be various functional modules in the SOC chip, such as core, DDR (Double Data Rate) controller, DDR PHY, interface, etc. The corresponding signals in the RTL code can be the enable signals of various modules. Different values ​​of the key power consumption attribute represent the enable signals of different modules. By defining different functional coverage boxes for different values, when performing functional coverage statistics, it is possible to know which modules are in use by detecting whether the enable signals of these modules are effective. Since different modules have different power consumption, the overall power consumption can be evaluated.

[0046] The above example illustrates a single type of binning method. More refined binning methods can be developed by combining various key power consumption attributes, leading to more accurate power consumption assessments. For instance, multiply-accumulate instructions currently have the highest power consumption, while other computational instructions have lower power consumption. However, the expected power consumption varies depending on the data type within the multiply-accumulate instruction. Therefore, for multiply-accumulate instructions, four more bins can be created based on data type, and more detailed data can be obtained through simulation functional coverage statistics.

[0047] The simulation environment includes simulation tools, which are the core components and implementation means of the simulation environment. In addition, the simulation environment also includes a test platform, configuration files required for testing, etc. The simulation tools can integrate functional coverage statistics tools, which can collect and statistically analyze the number of hits for each functional coverage module throughout the entire simulation run.

[0048] S2: Run the target test scenario in the simulation environment and count the number of hits for each functional coverage module during the entire simulation run.

[0049] Given different values ​​for key power consumption attributes in the current version of the RTL design to be evaluated, and after defining multiple functional coverage modules in the simulation environment, the target test scenario can be run in the simulation environment (including simulation tools). The hit count of each functional coverage module during the entire simulation run can be collected and counted using a functional coverage statistics tool. The functional coverage statistics tool can be integrated into the simulation tools.

[0050] For example, after creating a bin for high-power instructions, a bin for idle instructions, and a bin for all other instructions, functional coverage data is collected by running typical application scenarios or full-load high-load scenarios. Based on the functional coverage data, the number of hits in each bin during the entire operation is calculated. In other words, the proportion of high-power instructions, low-power instructions, and idle instructions in the entire process can be obtained by the number of hits in each bin.

[0051] The target test scenario is a set of simulation test conditions constructed to evaluate the power consumption of an RTL design and to simulate the behavior and state of the corresponding chip or module in actual operation. This set includes specific input stimulus sequences, initial state configurations, and environmental conditions. Existing methods in related technologies can be used to construct the target test scenario, which will not be described further in this application.

[0052] The target test scenario can be set according to the test needs. For example, it can be a typical application scenario or a full-load high-load scenario. For example, making all computing modules run at full load can accurately simulate the complete process of the module from sleep to activation, from low load to full load, and then from full load back to idle.

[0053] S3: Based on the baseline power consumption values ​​of key power consumption attributes obtained in advance under different values, and the number of hits of each functional coverage module, evaluate the average power consumption in the target test scenario.

[0054] After calculating the number of hits for each functional coverage module during the entire simulation run, the proportion of each key power consumption attribute under different values ​​(i.e., each functional coverage module) can be calculated. Combined with the pre-obtained baseline power consumption values ​​for these key power consumption attributes under different values, the average power consumption in the target test scenario can be evaluated. For example, if a total of 1000 clock cycles are monitored during the entire program run, and after functional coverage statistics, if the NOP instruction (idle instruction) is executed 100 times, the multiplication instruction (high-power instruction) is executed 600 times, and the remaining instructions (low-power instructions) are executed 300 times; if the power consumption statistics (baseline power consumption value) for the NOP instruction is X watts (W), the power consumption statistics (baseline power consumption value) for the multiplication instruction is approximately Y watts, and the power consumption statistics (baseline power consumption value) for the remaining instructions is approximately Z watts, then the average power consumption (expressed as Power) for the entire simulation run is equal to: Power = (X × 100 + Y × 600 + Z × 300) / 1000W. The longer the running time and the longer the statistical time, the closer the evaluated power consumption is to the actual average power consumption.

[0055] The baseline power consumption values ​​for the aforementioned key power consumption attributes under different values ​​need to be obtained through prior testing. Taking instruction type as an example, the baseline power consumption values ​​for high-power instructions, low-power instructions, and idle instructions need to be obtained in advance. These baseline power consumption values ​​can be obtained and stored in advance, such as in a database, hard disk, or memory, and can be retrieved directly when needed later.

[0056] In one possible implementation, the power consumption evaluation method described above may further include: simulating the target RTL design to obtain an RTL simulation waveform (pre-simulation waveform); mapping the RTL simulation waveform to a netlist obtained after logic synthesis of the target RTL design; and performing power consumption analysis based on the mapped netlist (i.e., the aforementioned method based on the simulation waveform) to obtain and store baseline power consumption values ​​for each key power consumption attribute related to RTL power consumption under different values. Here, the target RTL design is an RTL design different from the RTL design to be evaluated. Currently mainstream RTL power consumption evaluation methods can be used to simulate the target RTL design to obtain a pre-simulation waveform, then map the pre-simulation waveform to a netlist, and perform accurate power consumption analysis using EDA (Electronic Design Automation) tools based on the mapped netlist to obtain baseline power consumption values ​​for each key power consumption attribute related to RTL power consumption under different values.

[0057] When simulating the target RTL design, programs under different key power consumption attribute scenarios can be run to obtain different pre-simulation waveforms. Waveforms at full load in different pre-simulation waveforms are extracted and mapped to a netlist. Power analysis is then performed based on the mapped netlist to obtain baseline power consumption values ​​for key power consumption attributes under different values. The principle is as follows: Figure 2 As shown. For example, taking the key power consumption attribute as the instruction type, scenario 1 can be a scenario where high-power instructions are mainly executed, and scenario 2 can be a scenario where low-power instructions are mainly executed.

[0058] Based on the above analysis, it is evident that the method of using simulation waveforms requires mapping the RTL simulation waveform to the netlist after logic synthesis before performing power analysis. For large-scale designs, RTL simulation can be very time-consuming and necessitates at least logic synthesis to obtain the netlist, making it impossible to perform independently in earlier architecture or pure RTL stages. Therefore, this application obtains and stores the baseline power values ​​of key power attributes related to RTL power consumption under specific values ​​in advance. This allows for skipping this step during subsequent power evaluation, thereby shortening the simulation time and enabling power evaluation to be performed at an earlier design stage (such as the RTL stage).

[0059] In some possible implementations, the above-mentioned power consumption simulation method further includes: during the operation of the target test scenario in the simulation environment, dividing the simulation into multiple simulation time periods based on key signals identifying different operating stages; collecting functional coverage data in each simulation time period; obtaining the power consumption evaluation result for the corresponding stage based on the hit count of each functional coverage module in the functional coverage data collected in different time periods, and the baseline power consumption value of the key power consumption attribute under different values ​​obtained in advance; wherein, each simulation time period includes at least two of the following: ramp-up stage, continuous full load stage, and shutdown stage. This application can also calculate the power consumption of the continuous full load stage, the power consumption of the ramp-up stage from idle (IDLE) to full load, and the power consumption of the shutdown stage from full load to idle based on the functional coverage data collected at different times or stages, combined with the baseline power consumption value of the key power consumption attribute corresponding to each functional coverage module obtained in advance; and the confirmation of each time and stage can also be monitored based on the values ​​of some key signals.

[0060] For example, if the RTL design being evaluated is a processor core, the status register of the entire core and the enable signals of the compute modules can be monitored to distinguish different time periods. A status register of 1 indicates an idle state, a status register of 0 indicates core startup, and all compute module enable signals are 1, indicating a high-power, full-load state. That is, if the time when the status register changes from 1 to 0 is the start time t0, and the time when all compute module enable signals are 1 is the full-load start time t1, then Tp (Tp = t1 - t0) is the ramp-up phase from idle to full load. Continuously monitoring the compute module enable signals, the time when the enable signal of a compute module starts to change to 0 is the start time of the shutdown phase t2, then Tc (Tc = t2 - t1) is the continuous full-load phase. If the time when all compute modules are disabled and the status register changes from 0 to 1 is t3, then Tg (Tg = t3 - t2) is the shutdown phase from full load to IDLE.

[0061] This application can also distinguish different time periods by acquiring other key signals, such as monitoring the status signal used to indicate whether the core is enabled and the compute module's enable signal (compute_en).

[0062] For example, Figure 3 This diagram shows the power consumption distribution under a high-power, full-load scenario. Figure 3In the diagram, `instr0` represents instructions with relatively low power consumption, and `instr1` represents instructions with high power consumption. `t0` is the start of the simulation, at which point no valid instructions are being executed. The `t0~t1` phase represents the power consumption from idle state to near full load of low-power instructions. `t1~t2` represents the power consumption from zero to full load of high-power instructions. `t2~t3` represents the power consumption during the sustained full load phase of high-power instructions. `t3~t4` represents the shutdown phase from full load to idle state for high-power instructions. The values ​​of `t0`, `t1`, `t2`, `t3`, and `t4` in the diagram can all be obtained by monitoring specific values ​​of key signals within the RTL.

[0063] The power consumption of instr0 and instr1 can be collected separately using simulation tools. By monitoring the number of times instr0 and instr1 are monitored within a certain time period, the average power consumption during that period can be calculated. By statistically analyzing the values ​​and duration of each key power consumption attribute at different stages, different data can be obtained. This data is crucial for analyzing certain specific needs, such as providing important data support for backend analysis of dynamic voltage drop (IR Drop) and current change rate (di / dt), and providing in-depth insights into analyzing system performance bottlenecks and energy efficiency distribution.

[0064] In some possible implementations, the power consumption assessment method described above further includes: during the iteration process of the RTL design to be evaluated from the current version to the next version, obtaining a new target test scenario, wherein the new target test scenario is constructed according to the architecture and requirements of the next version; obtaining the quantity and proportion of each key power consumption attribute in the new target test scenario; and evaluating the expected average power consumption of the next version under the new target test scenario based on the pre-obtained baseline power consumption values ​​of each key power consumption attribute and the quantity and proportion of each key power consumption attribute in the new target test scenario. For example, when iterating from the current version (e.g., version V1.x, where x is an integer) to the next version (e.g., version V2.x), a new target test scenario can be constructed according to the architecture and requirements of the next version. Then, the quantity and proportion of each key power consumption attribute in the new target test scenario can be obtained, and combined with the previously obtained baseline power consumption values ​​of each key power consumption attribute, the expected average power consumption of the next version under the new target test scenario can be evaluated. This allows the relevant power consumption data to be roughly calculated during the architecture exploration phase of the next version, enabling timely optimization during the RTL implementation phase, greatly saving time and costs.

[0065] In some possible implementations, the principle of the power consumption evaluation method described above can be as follows: Figure 3 As shown. Based on Figure 2The method shown obtains baseline power consumption values ​​for different key power consumption attributes. When evaluating power consumption, it first determines whether it's a power consumption iteration of the current version (e.g., V1.x). If it is, such as iterating from V1.1 to V1.2 or from V1.2 to V1.3, multiple bins corresponding to different key power consumption attribute values ​​are defined in the simulation environment. Simulation is then performed in the target test scenario to obtain functional coverage data. Based on this data, the hit count and percentage of each key power consumption attribute value are obtained. Combined with the baseline power consumption values ​​for different key power consumption attributes, the average power consumption can be evaluated. If it's not an iteration of the current version, but rather an iteration from the current version (e.g., V1.x) to the next version (e.g., V2.x), a new target test scenario is constructed based on the architecture and requirements of the next version. The number and percentage of each key power consumption attribute in the new target test scenario are then obtained. Combined with the previously obtained baseline power consumption values ​​for each key power consumption attribute, the expected average power consumption of the next version in the new target test scenario can be evaluated.

[0066] The functional coverage-based statistical method presented in this application evaluates power consumption without requiring a gate-level netlist. Once all bins are defined in the simulation tool, the average power consumption for various scenarios can be evaluated, allowing for earlier assessment. Furthermore, compared to other evaluation methods, this approach has a higher level of abstraction. It only requires obtaining baseline power consumption values ​​for specific attributes using high-precision power analysis tools in the early stages. Subsequent statistical analysis of power consumption and performance under various scenarios can be performed using the method presented in this application. Moreover, during version iteration of a project, if the baseline power consumption values ​​of key power attributes for the current version are known, relevant power consumption data can be calculated during the architecture exploration phase of the next version, enabling timely optimization during the RTL implementation phase, significantly saving time and costs.

[0067] This application embodiment also provides a power consumption evaluation device 100, such as... Figure 5 As shown, the power consumption evaluation device 100 includes: a custom module 110, a simulation module 120, and an evaluation module 130.

[0068] Custom module 110 is used to define multiple functional coverage modules in the simulation environment that correspond one-to-one with different values ​​of key power consumption attributes in the current version of the RTL design to be evaluated. The key power consumption attributes are those that can be monitored in the simulation and whose values ​​are related to the power consumption of the RTL.

[0069] The simulation module 120 is used to run the target test scenario in the simulation environment and count the number of hits of each functional coverage module during the entire simulation operation phase.

[0070] The evaluation module 130 is used to evaluate the average power consumption in the target test scenario based on the baseline power consumption values ​​of the key power consumption attributes under different values ​​obtained in advance, and the number of hits of each of the functional coverage modules.

[0071] Optionally, the simulation module 120 is also used to simulate the target RTL design to obtain the RTL simulation waveform; map the RTL simulation waveform to the netlist obtained after logic synthesis of the target RTL design; and perform power consumption analysis based on the mapped netlist to obtain and store the reference power consumption values ​​of each key power consumption attribute related to RTL power consumption under different values.

[0072] Optionally, the evaluation module 130 is further configured to: obtain a new target test scenario during the iteration of the RTL design to be evaluated from the current version to the next version, wherein the new target test scenario is constructed according to the architecture and requirements of the next version; obtain the number and proportion of each key power consumption attribute in the new target test scenario; and evaluate the expected average power consumption of the next version under the new target test scenario based on the pre-obtained baseline power consumption values ​​of each key power consumption attribute and the number and proportion of each key power consumption attribute in the new target test scenario.

[0073] The key power consumption attribute includes the instruction type. The custom module 110 is specifically used to define the key power consumption attribute value corresponding to the high power consumption instruction as a high power consumption instruction library; define the key power consumption attribute value corresponding to the idle instruction as an idle instruction library; and define the key power consumption attribute value corresponding to the low power consumption instruction as a low power consumption instruction library. The low power consumption instruction includes all other instructions except for the high power consumption instruction and the idle instruction.

[0074] Optionally, the simulation module 120 is further configured to divide the target test scenario in the simulation environment into multiple simulation time periods based on key signals that identify different operating stages; collect functional coverage data in each simulation time period; correspondingly, the evaluation module 130 is further configured to obtain the power consumption evaluation result of the corresponding stage based on the number of hits of each functional coverage module in the functional coverage data collected in different time periods, and the baseline power consumption value of the key power consumption attribute under different values ​​obtained in advance, wherein each simulation time period includes at least two of the following: ramp-up stage, continuous full load stage, and shutdown stage.

[0075] The power consumption evaluation device 100 provided in this application embodiment has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment. like Figure 6 As shown, Figure 6This diagram illustrates a structural block diagram of an electronic device 200 provided in an embodiment of this application. The electronic device 200 includes: a transceiver 210, a memory 220, a communication bus 230, and a processor 240. The transceiver 210, memory 220, and processor 240 are electrically connected directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses 230 or signal lines. The transceiver 210 is used to send and receive data. The memory 220 is used to store computer programs, such as... Figure 5 The software functional module shown is the power consumption assessment device 100. The power consumption assessment device 100 includes at least one software functional module that can be stored as software or firmware in the memory 220 or embedded in the operating system (OS) of the electronic device 200. The processor 240 is used to execute executable modules stored in the memory 220, such as the software functional module or computer program included in the power consumption assessment device 100. For example, the processor 240 is used to execute the power consumption assessment method described above.

[0076] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0077] Processor 240 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), Network Processor (NP), Graphics Processing Unit (GPU), Accelerated Processing Unit (ACCU), Multimedia Application Processor (MAP), microprocessor, etc.; it can also be a Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. Alternatively, processor 240 can also be any conventional processor.

[0078] The electronic device 200 provided in this application embodiment may include, but is not limited to, a computer, a server, a testing platform, etc.

[0079] This application embodiment also provides a non-volatile computer-readable storage medium (hereinafter referred to as the storage medium) storing a computer program, which is executed by a computer such as the electronic device 200 described above to perform the power consumption evaluation method described above.

[0080] This application also provides a computer program product, which includes a computer program that, when executed by a computer, performs the power consumption evaluation method described above.

[0081] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0082] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0083] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0084] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, laptop, server, or electronic device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0085] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A power consumption evaluation method, characterized in that, include: To evaluate the different values ​​of key power consumption attributes in the current version of the RTL design, multiple functional coverage modules are defined in the simulation environment, each corresponding to a different value. The key power consumption attributes are those that can be monitored in the simulation and whose values ​​are related to the power consumption of the RTL. Run the target test scenario in the simulation environment and count the number of hits for each functional coverage module during the entire simulation run phase; Based on the baseline power consumption values ​​of the key power consumption attributes obtained in advance under different values, and the number of hits of each of the functional coverage modules, the average power consumption under the target test scenario is evaluated.

2. The method according to claim 1, characterized in that, The method further includes: Simulate the target RTL design to obtain the RTL simulation waveform; The RTL simulation waveform is mapped to the netlist obtained after logic synthesis of the target RTL design, and power consumption analysis is performed based on the mapped netlist to obtain and store the baseline power consumption values ​​of each key power consumption attribute related to RTL power consumption under different values.

3. The method according to claim 1, characterized in that, The method further includes: During the iteration process of the RTL design to be evaluated from the current version to the next version, a new target test scenario is obtained, wherein the new target test scenario is constructed according to the architecture and requirements of the next version; Obtain the quantity and proportion of each key power consumption attribute in the new target test scenario; Based on the baseline power consumption values ​​of each key power consumption attribute obtained in advance, and the number and proportion of each key power consumption attribute in the new target test scenario, the expected average power consumption of the next version in the new target test scenario is evaluated.

4. The method according to claim 1, characterized in that, The key power consumption attributes include instruction type; the functional coverage module is defined, including: Define the key power consumption attribute values ​​corresponding to high-power instructions as a high-power instruction block; Define the key power consumption attribute value corresponding to the idle instruction as an idle instruction block; The key power consumption attribute values ​​corresponding to the low power instructions are defined as a low power instruction library, wherein the low power instructions include all other instructions except for the high power instructions and the idle instructions.

5. The method according to claim 1, characterized in that, The method further includes: During the execution of the target test scenario in the simulation environment, multiple simulation time periods are divided based on key signals that identify different stages of the operation. Functional coverage data were collected at each simulation time period. Based on the number of hits of each function coverage module in the function coverage data collected in different time periods, and based on the baseline power consumption values ​​of the key power consumption attributes obtained in advance under different values, the power consumption evaluation results of the corresponding stage are obtained. The simulation time periods include at least two of the following: ramp-up phase, continuous full-load phase, and shutdown phase.

6. The method according to claim 1, characterized in that, The key power consumption attributes include at least one of the following: instruction type, data type, and module type.

7. The method according to claim 6, characterized in that, If the object of the RTL design to be evaluated is a processor core, the key power consumption attribute is the instruction type; If the object of the RTL design to be evaluated is a computing module, the key power consumption attribute is a data type; If the object of the RTL design to be evaluated is a SOC chip, the key power consumption attribute is the module type in the SOC chip.

8. A power consumption evaluation device, characterized in that, include: A custom module is used to define multiple functional coverage modules in the simulation environment that correspond one-to-one with different values ​​of key power consumption attributes in the current version of the RTL design to be evaluated. The key power consumption attributes are those that can be monitored in the simulation and whose values ​​are related to the power consumption of the RTL. The simulation module is used to run the target test scenario in the simulation environment and count the number of hits of each functional coverage module during the entire simulation run phase. The evaluation module is used to evaluate the average power consumption in the target test scenario based on the baseline power consumption values ​​of the key power consumption attributes under different values ​​obtained in advance, and the number of hits of each of the functional coverage modules.

9. An electronic device, characterized in that, include: A memory and a processor, wherein the processor is connected to the memory; The memory is used to store programs; The processor is configured to invoke a program stored in the memory to execute the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, performs the method as described in any one of claims 1-7.

11. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

Images