Verification method for counting chip design power consumption

Abstract

The invention relates to the field of chip design, and particularly discloses a verification method for counting chip design power consumption, which comprises the following steps of: optimizing a verification case, confirming that a netlist provided by a back end is consistent with an SDF (Software Development Function) file and a back mark is normal, setting a TT corner for netlist simulation, and establishing an efficient simulation foundation; starting netlist simulation, and checking time sequence information of setuhouse and width after the netlist simulation is finished; the start time of the waveform dump is controlled through a macro switch; intercepting a plurality of waveforms in the same scene, averaging, and clearly marking a time starting point of each waveform; the waveform file and the time parameters are provided for the rear end, the front end checks clock gating and data overturning problems, the rear end checks the LVT cell proportion and memory current problems, and IP power consumption data integrated in the merge stage is supplemented; if the data is abnormal, returning, and if the data is normal, entering the next step; after the chip is manufactured and packaged, actually-measured power consumption data is obtained, the difference between the actually-measured power consumption data and design-stage evaluation power consumption is compared, and front and rear ends jointly output power consumption optimization suggestions.

Description

Technical Field

[0001] This invention relates to the field of chip design, specifically to a method for verifying the power consumption of a statistical chip design. Background Technology

[0002] As chip design scale continues to expand and complexity increases, power consumption has become a core indicator of chip design while ensuring functionality and performance. Low power consumption means longer battery standby time and stronger battery life, which is a key factor affecting product market competitiveness. Some electronic products even use power consumption as an entry threshold. Therefore, power consumption statistics in the chip design stage are crucial.

[0003] However, existing chip power consumption statistics methods have many key flaws and cannot meet actual design requirements, specifically including: Insufficient data authenticity: The statistical period is short and the scenario is singular, which cannot reflect the actual power consumption of the chip; some modules generate high power consumption when they are not working (such as abnormal power consumption when only the clock is turned on and there is no service), and the power consumption data fluctuates greatly in the same scenario, resulting in poor reliability.

[0004] Low process efficiency: When the waveform file generated by netlist simulation is too large, the extraction tool is limited and the extraction time is too long or it fails. The initialization time of some simulation scenarios is long, the overall simulation cycle is long, and the waveform cutting is difficult.

[0005] Data incompleteness and accuracy: Power consumption data for some IPs is not included in the design files (.V files), which can easily lead to omissions when calculating the total power consumption of the chip; moreover, the power consumption data provided by IP vendors is usually optimistic and deviates significantly from the actual test results.

[0006] The backend faces significant time pressure in tape-out: after the backend provides the netlist, tape-out must be completed within one month, which is time-sensitive; moreover, the first version of the netlist often fails to run properly due to setuphold timing issues, further wasting time and exacerbating the time pressure for power consumption analysis.

[0007] Abnormal power consumption in optimization projects: Some optimization projects with no significant changes in architecture and area have experienced inexplicable increases in power consumption, and existing methods are insufficient to pinpoint the cause. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method for verifying the power consumption of a statistical chip design, so as to solve the problems mentioned in the background art.

[0009] This invention provides a method for verifying the power consumption of a statistical chip design, comprising the following steps: Optimize verification test cases, remove redundant delays, wait functions and print information, and split functional functions; confirm that the netlist provided by the backend is consistent with the SDF file and that the back-annotation is normal, set the netlist simulation to use TT corner, and build an efficient simulation foundation. Start the netlist simulation. After it ends, check the timing information of setuphold and width. If there is a timing error, report to the backend to update the netlist and re-simulate. If the timing is normal, proceed to the next step to rule out rework caused by timing issues. The timing of waveform dumping is controlled by a macro switch, and the waveforms at the entire chip level are split and named sequentially; multiple waveforms from the same scene are extracted and averaged, and the start and end points of each waveform are clearly marked. The waveform file and timing parameters are provided to the backend, which uses tools such as ptpx and redhawk to generate power consumption data. Front-end and back-end collaborative troubleshooting: front-end checks for clock gating and data flipping issues, back-end checks for LVT cell ratio and memory current issues, and supplements the power consumption data of IPs integrated during the merge phase; If the data is abnormal, return; if the data is normal, proceed to the next step. After chip manufacturing and packaging, the measured power consumption data is obtained, and the difference between the measured power consumption and the power consumption evaluated during the design phase is compared. The front-end and back-end work together to output power consumption optimization suggestions.

[0010] Furthermore, the optimized verification test cases involve removing redundant delays, wait functions, and print information, and splitting functional functions. Specifically, when implementing the optimized verification test cases, the delay statements in the test cases are first reviewed, and delays that are not necessary for chip function verification are identified and removed. Then, wait functions are investigated, and wait loops that are unrelated to business logic execution are filtered and removed. Next, print information is organized, retaining only key error messages and functional status confirmation content, and removing redundant prints for temporary debugging. Finally, the integrated functional functions are split according to the functional boundaries of different business modules of the chip. The split functions can be called individually or loaded in parallel to accelerate the netlist simulation progress.

[0011] Furthermore, the process involves confirming that the netlist provided by the backend is consistent with the SDF file and that the back-annotation is normal. Netlist simulation is then set to use the TT corner to establish an efficient simulation foundation. Specifically, this involves: obtaining the netlist to be verified and the corresponding SDF timing file from the backend; verifying that the project identifier, version number, and key module port information of both are consistent; back-annotating the SDF timing data to the netlist; checking the tool logs to confirm no errors; and verifying that the back-annotation is normal using simulation tools; specifying the process library for the TT process corner in the configuration file; loading the corresponding voltage and temperature parameters; collecting simulation dependency files; and compiling and testing to confirm that there are no missing or incorrect files, thus establishing an efficient simulation foundation.

[0012] Furthermore, the netlist simulation is initiated, and after completion, the setuphold and width timing information are checked. If timing anomalies are found, feedback is sent to the backend to update the netlist and re-simulate. If timing is normal, the next step is taken to eliminate rework caused by timing issues. Specifically, after setting up the simulation environment, the netlist simulation is initiated and monitored in real time to ensure stable operation. After the simulation ends, a timing violation report is generated and viewed using tools, while asynchronous signal-related violations and assertion timing checks are performed. If timing violations are found, the issues are compiled and feedback is sent to the backend to update the netlist, and then the simulation and timing checks are repeated. If timing is normal, the data is archived and the backend is notified to enter the power consumption analysis stage, thereby eliminating rework caused by timing issues and ensuring the efficient progress of the power consumption statistics process.

[0013] Furthermore, the waveform dumping initiation timing is controlled by a macro switch, and the waveforms at the entire chip level are split and named sequentially. Multiple waveforms from the same scenario are extracted and averaged, with the start and end times of each waveform clearly marked. Specifically, this involves: analyzing the simulation initialization process for different chip scenarios to determine valid business nodes; writing macro switch control statements in the verification test cases to trigger waveform dumping when the simulation reaches a node, avoiding invalid data; configuring the waveform file size and naming them sequentially according to rules to ensure distinguishability; extracting multiple valid waveforms for each scenario, submitting them to the backend for statistics, and averaging them to reduce fluctuation errors; recording the start and end times when generating waveforms and establishing a corresponding table to ensure the backend accurately obtains time parameters.

[0014] Furthermore, the waveform file and timing parameters are provided to the backend, which uses PTPX and Redhawk tools to generate power consumption data. Specifically, the split waveform file and corresponding timing parameter table are packaged and sent to the backend. After checking the file integrity, the backend opens the PTPX tool, loads the netlist, SDF file, waveform file, corresponding parameters, and process library, sets the parameters, and generates preliminary power consumption data. Then, the Redhawk tool is used to import the power network topology file, preliminary power consumption data, and related files, and sets the analysis dimensions for refined analysis. Errors are handled during the process, and finally, the key power consumption data is compiled into a standardized table for front-end and back-end collaborative troubleshooting.

[0015] Furthermore, the front-end and back-end collaborative troubleshooting involves: the front-end checking for clock gating and data flipping issues, and the back-end checking for LVT cell ratio and memory current issues, supplementing the IP power consumption data integrated during the merge phase; if the data is abnormal, the process returns; if the data is normal, the process proceeds to the next step, specifically: the front-end checks for clock gating and data flipping, obtains module power consumption and focuses on inactive modules, checks and optimizes clock gating logic and signal flipping; the back-end checks for LVT cell ratio and memory current, calculates the LVT cell ratio and adjusts the selection, analyzes memory current and optimizes the circuit; both parties jointly review and supplement the IP power consumption data integrated during the merge phase; the data is verified, and if abnormalities are found, the simulation is re-run; if normal, a report is prepared and the process proceeds to the next step.

[0016] Furthermore, after the chip is manufactured and packaged, measured power consumption data is acquired, and the difference between this data and the power consumption evaluated during the design phase is compared. The front-end and back-end jointly output power consumption optimization suggestions. Specifically, after chip manufacturing and packaging, a measured power consumption data acquisition environment is first set up, and a measured scenario is set according to the design phase scenario. The chip is then started and data is recorded. Next, the power consumption data evaluated during the design phase is organized. Then, the difference between the measured and evaluated power consumption is compared. Afterwards, the front-end and back-end jointly analyze the reasons for the difference. Finally, optimization suggestions are output and compiled into a standardized report containing the difference data, reasons, and measures, providing a reference for subsequent chip power consumption design.

[0017] The beneficial effects of this invention are: This application addresses the two core pain points of "tight timeframe" and "accurate data" through targeted process optimization and collaboration mechanisms. Its technical effectiveness focuses on "supporting deployment decisions" and "guiding subsequent design," which can be summarized in three points: 1. Significantly shorten the power consumption analysis cycle to support backend tape-out decisions. By "optimizing the simulation environment (removing redundant delays / printing, splitting function functions) + automated scripts (controlling netlist simulation and data analysis) + flexible waveform management (splitting small-capacity waveform files, macro switches controlling waveform dump timing)," we can provide standard-compliant netlist simulation waveforms and parameters in the shortest possible time within the tight one-month backend tape-out window. This avoids wasting time due to inefficient processes or timing issues and directly provides key data support for "whether to start tape-out," resolving the core contradiction of "tight time and slow process" in the background. 2. Improve the rationality and accuracy of power consumption data to avoid decision-making bias, and compensate for the data deficiencies of existing methods through multi-dimensional measures: Complete the data: Proactively supplement the "IP power consumption data that is not included in the design documents and is only integrated in the merge stage" to solve the problem of missing IP power consumption. Reduce fluctuations: Take the average of multiple waveforms from the same scene to alleviate the problem of large fluctuations in power consumption data; Collaborative verification: Front-end and back-end engineers work together to troubleshoot (front-end checks for clock gating / data flipping issues, back-end checks for LVT cell ratio / memory current issues) to ensure that power consumption nodes are normal and avoid data distortion such as "high power consumption even when the module is not working" or "abnormal power consumption in the optimization project", so that the output power consumption data is closer to the real scenario. 3. Forming a closed-loop optimization to guide subsequent project design: After chip manufacturing and packaging, through "difference analysis between measured power consumption and power consumption evaluated in the design stage", front-end and back-end engineers jointly output power consumption optimization suggestions, providing reusable experience for the power consumption design of subsequent chips. This breaks through the limitation of existing methods that "only serve the current project and have no long-term guiding value", forming a closed loop of "design-verification-testing-optimization". Attached Figure Description

[0018] Figure 1 Flowchart of the method for verifying the power consumption of a statistical chip design according to the present invention. Detailed Implementation

[0019] In practical implementation, this application discloses a method for verifying the power consumption of a statistical chip design, such as... Figure 1 The method for verifying the power consumption of the statistical chip design includes the following steps: Optimize verification test cases, remove redundant delays, wait functions and print information, and split functional functions; confirm that the netlist provided by the backend is consistent with the SDF file and that the back-annotation is normal, set the netlist simulation to use TT corner, and build an efficient simulation foundation. Start the netlist simulation. After it ends, check the timing information of setuphold and width. If there is a timing error, report to the backend to update the netlist and re-simulate. If the timing is normal, proceed to the next step to rule out rework caused by timing issues. The timing of waveform dumping is controlled by a macro switch, and the waveforms at the entire chip level are split and named sequentially; multiple waveforms from the same scene are extracted and averaged, and the start and end points of each waveform are clearly marked. The waveform file and timing parameters are provided to the backend, which uses tools such as ptpx and redhawk to generate power consumption data. Front-end and back-end collaborative troubleshooting: front-end checks for clock gating and data flipping issues, back-end checks for LVT cell ratio and memory current issues, and supplements the power consumption data of IPs integrated during the merge phase; If the data is abnormal, return; if the data is normal, proceed to the next step. After chip manufacturing and packaging, the measured power consumption data is obtained, and the difference between the measured power consumption and the power consumption evaluated during the design phase is compared. The front-end and back-end work together to output power consumption optimization suggestions.

[0020] The optimized verification test cases involve removing redundant delays, wait functions, and print messages, and splitting functional functions. Specifically, this involves first reviewing existing delay statements in the verification test cases, identifying delays not essential for chip functional verification (e.g., fixed delays used only for debugging), and removing these redundant delays. Next, wait functions in the verification test cases are examined, filtering out wait loops unrelated to business logic execution (e.g., unnecessary empty wait functions). Then, print messages in the verification test cases are organized, retaining only key error messages and functional status confirmations, and removing redundant print messages used for temporary debugging. Finally, the functional functions in the verification test cases are split, according to the functional boundaries of different business modules of the chip, separating integrated functional functions into independent units, such as separating the data receiving and processing function from the clock synchronization control function. The split functions can be called individually or loaded in parallel, further accelerating the netlist simulation progress.

[0021] The process involves confirming that the netlist provided by the backend is consistent with the SDF file and that back-annotation is normal. Netlist simulation is then set to use TTcorner to build an efficient simulation foundation. Specifically, the process involves first obtaining the netlist file to be verified and the corresponding SDF timing file from the backend, and verifying the project identifiers and version numbers of the netlist file and SDF file one by one to ensure complete consistency. The port names and quantities of key functional modules in the netlist are checked to ensure they match the port information of the corresponding modules in the SDF file. The timing data from the SDF file is then back-annotated to the netlist, initiating the back-annotation process. During the back-annotation process, the tool output logs are monitored in real time to confirm the absence of errors such as port mismatches or missing timing data. After back-annotation is complete, the association status between the netlist and the SDF file is verified using the simulation tool's check commands to ensure normal back-annotation. The simulation environment configuration file specifies the process library file corresponding to the TT process corner, and the voltage and temperature parameters of the TT process corner are loaded to ensure the simulation environment uses the TT corner's process conditions. The necessary dependency files for simulation are collected, including the TT process library model file and basic simulation scripts. The entire simulation environment is compiled and tested to confirm the absence of missing files and compilation errors, ensuring that the established simulation foundation can efficiently support subsequent netlist simulations.

[0022] The process involves initiating a netlist simulation and then checking the setuphold and width timing information. If timing anomalies are found, the backend is notified to update the netlist and the simulation is re-run. If timing is normal, the process proceeds to the next step, eliminating rework caused by timing issues. Specifically, after the simulation environment is set up, the netlist simulation task is initiated. Real-time monitoring is maintained during the simulation, paying attention to simulation log output and the status of key signals to ensure stable and uninterrupted simulation operation. After the simulation, the timing check function of the simulation tool is immediately used to generate and view timing violation reports such as setuphold and width. The report should include the start and end points of the violation path, the violation value, clock domain information, and related timing margins. Simultaneously, recovery and removal violations related to asynchronous signals are checked to ensure comprehensive timing constraint coverage. The results of timing checks included in assertions must also be confirmed.

[0023] If timing violations are found in the report, the violation path, relevant waveform screenshots, and violation details should be compiled into a problem list and promptly reported to the backend engineers for analysis and repair. After the backend updates the netlist, the netlist simulation and timing check steps should be repeated until the timing violations are completely eliminated.

[0024] If the timing report is clean, with no violations or only a small margin that meets design requirements, the timing is considered normal. At this point, the complete simulation log, timing report, waveform files, and related parameters are archived together, and the backend engineers are notified to proceed to the power consumption analysis phase. This effectively eliminates subsequent rework caused by timing issues and ensures the efficient progress of the entire power consumption statistics process.

[0025] The process involves controlling the waveform dump startup timing via a macro switch, splitting the full-chip-level waveforms and naming them sequentially; averaging multiple waveforms from the same scenario, and clearly marking the start and end points of each waveform; specifically, in implementation, the simulation initialization process for different chip operating scenarios is first analyzed to determine the node where effective services begin running in each scenario, such as the moment when data transmission starts or the core module is activated.

[0026] For these nodes, macro switch control statements are written in the verification test cases. When the simulation runs to the preset valid service node, the macro switch automatically triggers the waveform dump function to avoid generating invalid waveform data during the initialization phase. Next, the waveform file capacity parameter is configured. Based on the processing limit of commonly used waveform extraction tools, the capacity of a single full-chip level waveform file is set between 200M and 500M.

[0027] Name the waveform files sequentially according to the rule "Project Identifier_Scenario Name_Waveform Sequence Number", such as chip_design_scenario2_wave3, to ensure that the file names are clear and distinguishable. Then process the waveforms from the same scenario.

[0028] For each work scenario, continuously capture 3 to 5 valid waveform files, and keep the business runtime of each waveform file consistent, for example, 8ms.

[0029] These waveform files are submitted to the backend for power consumption statistics. After obtaining multiple sets of power consumption data, the average value is calculated to reduce errors caused by fluctuations in individual waveform data. Finally, the start and end points of the waveforms are recorded and marked. When each waveform file is generated, its corresponding simulation start and end point is recorded synchronously, accurate to the microsecond level. A mapping table between waveform files and time parameters is established, containing information such as waveform file name, scene number, start and end point, ensuring that backend engineers can accurately obtain the corresponding time parameters when using waveform files for power consumption analysis.

[0030] The process involves providing waveform files and timing parameters to the backend, which then uses PTPX and Redhawk tools to generate power consumption data. Specifically, this involves first organizing all the split waveform files and their corresponding timing parameter tables, ensuring that each waveform file has a matching start and end point in the table. The organized waveform files and timing parameter tables are then packaged and transmitted to the backend engineers via the project's internal shared server. Upon receiving the file, the backend engineers check its integrity, confirming no missing or corrupted files and that the information in the timing parameter tables accurately corresponds to the waveform file names. The backend engineers then open the PTPX tool and load the previously confirmed netlist and SDF files. They import the packaged waveform files and associate them with the corresponding timing parameter tables, ensuring the tool can identify the simulation time period for each waveform file. The process library file corresponding to the TT process corner is loaded to match the process conditions used in the netlist simulation. Basic power consumption statistics parameters, including voltage and temperature values, are set in the PTPX tool, ensuring consistency with the TT corner parameters. The power consumption calculation process in the PTPX tool is then initiated, and the tool is allowed to complete and generate preliminary power consumption data. Finally, the backend engineers open the Redhawk tool. Import the chip's power network topology file into the Redhawk tool. Import the preliminary power consumption data generated by the PTPX tool into Redhawk, and re-associate the waveform file and timing parameters. Set the analysis dimensions for dynamic and static power consumption in Redhawk, including the power consumption percentage statistics for each functional module. Start the refined power consumption analysis workflow in Redhawk to further verify the accuracy of the power consumption data.

[0031] During the operation of both tools, backend engineers monitored the tool output logs in real time. If file import failures or parameter mismatches occurred, they promptly communicated with verification engineers to confirm and resolve the issues. After both tools completed their runs, the backend engineers collected the power consumption data reports generated by the tools. Key data from the reports, including the total power consumption of the entire chip and the power consumption values ​​of each module, were compiled into standardized tables to prepare for subsequent frontend and backend collaborative troubleshooting.

[0032] The front-end and back-end collaborative troubleshooting involves: the front-end checking for clock gating and data toggle issues, and the back-end checking for LVT cell ratio and memory current issues, supplementing the IP power consumption data integrated during the merge phase; if data is abnormal, the process returns; otherwise, it proceeds to the next step. Specifically, in implementation, front-end engineers first obtain the power consumption data of each module output from the back-end, focusing on the power consumption values ​​of inactive modules. For inactive modules with abnormal power consumption, they examine their clock signal waveforms to confirm whether the clock gating unit is properly enabled. If the clock gating unit is not triggered, they check the clock gating control logic in the RTL code, troubleshooting for gating failures caused by logic errors, and then examine the internal signal waveforms of the inactive modules to calculate the signal toggle frequency during idle periods. If the toggle frequency is too high, they analyze the data latching and signal driving logic in the RTL code to identify and optimize the code segments causing invalid toggles. Back-end engineers open the chip physical implementation file and extract the LVT cell usage list. Count the total number of LVT cells, calculate their proportion of the total number of logic cells in the chip, compare with the maximum allowable proportion of LVT cells in the design specifications, and if the proportion exceeds the limit, adjust the cell selection and increase the use of HVT or RVT cells.

[0033] Simultaneously, power analysis tools were used to examine the memory power switching timing waveforms, extracting the peak current at the moment of power-off and power-on. The peak current was compared to the maximum withstand current in the memory datasheet. If the withstand value was exceeded, the memory power management circuitry was optimized, and the switching control timing was adjusted to reduce the instantaneous current. Front-end and back-end engineers jointly reviewed the list of Hard IPs integrated during the merge phase, confirming that these IPs were not included in the initial power consumption statistics. The IP vendors were contacted to obtain the measured power consumption data for each IP. If measured data was unavailable, the power consumption value of the IP in the current design was calculated based on the IP datasheet parameters and the actual operating scenario of the chip. This IP power consumption data was then separately tallied and added to the total chip power consumption data.

[0034] Front-end and back-end engineers jointly verify the optimized power consumption data. If abnormal module power consumption, excessive LVT cell ratio, memory current overshoot, or incomplete IP power consumption still exist, a problem report is compiled and fed back to the corresponding engineer for rectification. After rectification, the netlist simulation step is returned to re-execute the simulation and timing verification until the power consumption data meets the design requirements. If all power consumption data is normal, a collaborative troubleshooting report is compiled, including the troubleshooting process, optimization measures, and final power consumption data, and then the next step is initiated.

[0035] After the chip is manufactured and packaged, measured power consumption data is acquired and compared with the power consumption estimated during the design phase. The front-end and back-end work together to output power consumption optimization suggestions. Specifically, in implementation, a data acquisition environment for the measured power consumption of the chip is first established. A high-precision power consumption tester is selected and connected to the power and signal pins of the packaged chip, ensuring stable contact in the test circuitry.

[0036] Based on the working scenarios defined in the chip design phase, set up actual test scenarios, including standby scenarios, high-load data processing scenarios, and core module independent operation scenarios.

[0037] For each test scenario, the chip is started and the data recording function of the power consumption tester is enabled. The recorded data includes the chip's operating voltage, operating current, and real-time power consumption in that scenario. The data sampling interval is set to microseconds to ensure that instantaneous power consumption changes are captured. Each scenario is tested 3 to 5 times consecutively, and the average power consumption value of each test is taken as the final measured power consumption data for that scenario.

[0038] Next, the power consumption data from the design phase was organized, and the total power consumption of the whole chip and the power consumption of each functional module for each corresponding scenario in the design phase were extracted from the project archive files to ensure that the scenario definitions of the evaluation data and the actual measurement data are consistent.

[0039] Then, a power consumption difference comparison analysis is performed, comparing the measured total power consumption of the entire chip with the total power consumption of the entire chip evaluated during the design phase, and calculating the percentage difference. Next, the measured power consumption and evaluated power consumption of each functional module are compared separately to identify modules whose differences exceed a preset threshold, which can be set to 10%.

[0040] At the same time, compare the power consumption difference trends under different scenarios, such as the small difference in standby scenarios and the large difference in high load scenarios, and record the specific difference data and corresponding scenario information.

[0041] Following this, front-end and back-end engineers collaborated to analyze the reasons for the discrepancies. Front-end engineers reviewed the clock gating logic implementation of the module with the measured discrepancies, based on the RTL design document, to confirm whether there were any clock leakage issues that had not been considered in the design. They examined the measured data flip-flop rate of the module and compared it with the estimated flip-flop rate during the design phase to determine if the increased power consumption was due to a higher-than-expected data flip-flop rate. Back-end engineers retrieved the physical implementation file of the module with the discrepancies and checked whether the actual usage ratio of the LVT cell was consistent with the planned ratio during the design phase. They analyzed the power switching current curve of the memory in the actual measurements to confirm whether there was any current overshoot exceeding the design estimate at the moment of power-off and power-on.

[0042] Front-end and back-end engineers jointly checked the measured power consumption of the Hard IP integrated during the merge phase, compared it with the power consumption parameters of the IP used in the design phase, and determined whether the overall power consumption difference was caused by the deviation in the IP parameter estimation.

[0043] Finally, power consumption optimization recommendations were output. Based on the analyzed causes of the differences, front-end engineers proposed specific RTL optimization suggestions, such as optimizing the timing of clock gating control signals, reducing invalid clock supplies, adjusting data processing logic, and reducing unnecessary data flips. Back-end engineers proposed physical implementation optimization suggestions, such as adjusting the LVT cell usage ratio of the differing modules, replacing some LVT cells with HVT cells, optimizing memory power management circuit parameters, and slowing down current overshoot. The power consumption design improvement directions for subsequent projects were also clarified, including confirming measured power consumption data with the IP vendor at the beginning of the project rather than relying on optimistic parameters, and adding multi-scenario simulation verification for high-power-risk modules during the netlist simulation phase. All optimization recommendations were compiled into a standardized report, which included difference data, cause analysis, specific optimization measures, and subsequent improvement directions, providing an actionable reference for subsequent chip power consumption design.

[0044] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0045] The above are all preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape and principle of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A method for verifying the power consumption of a statistical chip design, characterized in that, Including the following steps: Optimize verification test cases, remove redundant delays, wait functions and print information, and split functional functions; confirm that the netlist provided by the backend is consistent with the SDF file and that the back-annotation is normal, set the netlist simulation to use TT corner, and build an efficient simulation foundation. Start the netlist simulation, and check the timing information of setuphold and width after it ends; If a timing anomaly occurs, the backend is notified to update the netlist and re-simulate; If the timing is normal, proceed to the next step and rule out rework caused by timing issues; The timing of waveform dumping is controlled by a macro switch, and the waveforms at the entire chip level are split and named sequentially; multiple waveforms from the same scene are extracted and averaged, and the start and end points of each waveform are clearly marked. The waveform file and timing parameters are provided to the backend, which uses tools such as ptpx and redhawk to generate power consumption data. Front-end and back-end collaborative troubleshooting: front-end checks for clock gating and data flipping issues, back-end checks for LVT cell ratio and memory current issues, and supplements the power consumption data of IPs integrated during the merge phase; If the data is abnormal, return; if the data is normal, proceed to the next step. After chip manufacturing and packaging, the measured power consumption data is obtained, and the difference between the measured power consumption and the power consumption evaluated during the design phase is compared. The front-end and back-end work together to output power consumption optimization suggestions.

2. The method for verifying the power consumption of a statistical chip design according to claim 1, characterized in that, The optimized verification test cases involve removing redundant delays, wait functions, and print information, and splitting functional functions. Specifically, during the implementation of the optimized verification test cases, the delay statements in the test cases are first reviewed, and delays that are not necessary for chip functional verification are identified and removed. Then, wait functions are investigated, and wait loops that are unrelated to the execution of business logic are filtered and removed. Next, print information is organized, retaining only key error messages and functional status confirmation content, and removing redundant prints for temporary debugging. Finally, the integrated functional functions are split according to the functional boundaries of different business modules of the chip. The split functions can be called individually or loaded in parallel to accelerate the netlist simulation progress.

3. The method for verifying the power consumption of a statistical chip design according to claim 1, characterized in that, The process involves confirming that the netlist provided by the backend is consistent with the SDF file and that the back-annotation is normal. The netlist simulation is set to use TT corner to build an efficient simulation foundation. Specifically, the process is as follows: obtain the netlist to be verified and the corresponding SDF timing file from the backend, and verify that the project identifier, version number and key module port information of the two are consistent; back-annotate the SDF timing data to the netlist, check the tool log to confirm that there are no errors, and use the simulation tool to verify that the back-annotation is normal. In the configuration file, specify the process library for the TT process corner, load the corresponding voltage and temperature parameters, collect simulation dependency files, compile and test to confirm that there are no missing or error files, so as to build an efficient simulation foundation.

4. The method for verifying the power consumption of a statistical chip design according to claim 1, characterized in that, The process begins with initiating netlist simulation. After completion, the setuphold and width timing information are checked. If timing anomalies are found, the backend is notified to update the netlist and re-simulate. If timing is normal, the process proceeds to the next step, eliminating rework caused by timing issues. Specifically, this involves: setting up the simulation environment, initiating netlist simulation, and monitoring in real time to ensure stable operation; after simulation, a timing violation report is generated and viewed using tools, while simultaneously checking for asynchronous signal-related violations and assertion timing checks; if timing violations are found, the issues are compiled and reported to the backend to update the netlist, followed by repeated simulation and timing checks; if timing is normal, the data is archived and the backend is notified to proceed to the power consumption analysis stage. This process eliminates rework caused by timing issues and ensures the efficient progress of the power consumption statistics process.

5. The method for verifying the power consumption of a statistical chip design according to claim 1, characterized in that, The process involves controlling the waveform dump startup timing via a macro switch, splitting and sequentially naming the waveforms across the entire chip, averaging multiple waveforms from the same scenario, and clearly marking the start and end points of each waveform. Specifically, this involves: analyzing the simulation initialization process for different chip scenarios to determine valid business nodes; writing macro switch control statements in the verification test cases to trigger waveform dumping when the simulation reaches a node to avoid invalid data; configuring the waveform file size and naming them sequentially according to rules to ensure distinguishability; averaging multiple valid waveforms for each scenario after submission to the backend for statistics to reduce fluctuation errors; recording the start and end points of the waveforms during generation and establishing a corresponding table to ensure the backend accurately obtains time parameters.

6. The method for verifying the power consumption of a statistical chip design according to claim 1, characterized in that, The process involves providing waveform files and timing parameters to the backend, which then uses PTPX and Redhawk tools to generate power consumption data. Specifically, the split waveform files and corresponding timing parameter tables are packaged and sent to the backend. After checking the file integrity, the backend opens the PTPX tool, loads the netlist, SDF file, waveform files, corresponding parameters, and process library, sets the parameters, and generates preliminary power consumption data. Then, the Redhawk tool is used to import the power network topology file, preliminary power consumption data, and related files, and sets the analysis dimensions for refined analysis. Errors are handled during the process, and finally, key power consumption data is compiled into a standardized table for frontend and backend collaborative troubleshooting.

7. The method for verifying the power consumption of a statistical chip design according to claim 1, characterized in that, The front-end and back-end collaborative troubleshooting involves: the front-end checking for clock gating and data toggle issues, and the back-end checking for LVT cell ratio and memory current issues, supplementing the power consumption data of the IP integrated during the merge phase; if the data is abnormal, the process returns; if the data is normal, the process proceeds to the next step, specifically: the front-end checks clock gating and data toggle, obtains module power consumption and focuses on inactive modules, checks and optimizes clock gating logic and signal toggle behavior; the back-end checks LVT cell ratio and memory current, calculates the LVT cell ratio and adjusts the selection, analyzes memory current and optimizes the circuit; both parties jointly review and supplement the power consumption data of the IP integrated during the merge phase; the data is verified, and if abnormalities are found, the simulation is re-run; if normal, a report is prepared and the process proceeds to the next step.

8. The method for verifying the power consumption of a statistical chip design according to claim 1, characterized in that, After the chip is manufactured and packaged, measured power consumption data is acquired and compared with the power consumption evaluated during the design phase. The front-end and back-end jointly output power consumption optimization suggestions. Specifically, after chip manufacturing and packaging, a measured power consumption data acquisition environment is first set up, and the measured scenario is set according to the design phase scenario. The chip is started and the data is recorded. Then, the power consumption data evaluated during the design phase is organized. Then, the difference between the measured and evaluated power consumption is compared. After that, the front-end and back-end jointly analyze the reasons for the difference. Finally, optimization suggestions are output and organized into a standardized report containing the difference data, reasons, and measures to provide a reference for subsequent chip power consumption design.

Images