Part I of this article provided a consolidated approach to understand verification tools and methodologies that applies a set of pre-defined power aware (PA) or multi-voltage (MV) rules based on the power requirements, statically on the structures of the design. More precisely, the rule sets are applied on the physical structure, architecture, and microarchitecture of the design, in conjunction with the UPF specification but without the requirements of any external stimulus or testbenches. This actually makes the PA-Static tool simpler and a popular choice to verify various features of UPF strategies (e.g., UPF strategy definitions are correct, incorrect, missing, or redundant, MV cells are correct, incorrect, missing, or redundant, UPF strategies are present but cells are missing, or vice versa).
Part I also explained that PA-Static checks work beyond UPF strategies. Part 1: List 2, Essential PA-Static Checks at Different Design Abstraction Level, is the best reference for a complete list of PA-Static checks. In addition, Part 1: List 4, Summary of Information Analyzed by PA-Static Tool, showed that the tool may be deployed to conduct verification as early as the RTL with the first five of the listed information (i.e., power domains, power domain boundary, power domain crossings, and power states). The last two, the cell and pin-level attributes, are mandatory information for the GL-netlist and PG-netlist levels of the design. As well it also revisits the library requirements and processing techniques for PA-Static tools. In Part II of the article, we conclude this discussion with a real example to analyze PA-Static results and reporting, as well as efficient debugging PA-Static anomalies.
PA STATIC CHECKS: STATIC CHECKER RESULTS AND DEBUGGING TECHNIQUES
PA-Static verification reporting of results are very straightforward and widely differ from PA-SIM in terms of format, contents, and representation. PA-Static reporting is mostly text based; however, visual representations of PA relevant logics and relevant UPF objects on schematic viewers often adds advantages for pin-pointing bugs and fixing them quickly.
PA-Static verification are mainly UPF strategy oriented, like PSW, ISO, ELS, LS, RFF, and RTP, etc. These are defined within the UPF explicitly through different UPF strategy commands, like set_isolation, set_level_shifter, etc. and their association with different power domains are validated through their definition and add_power_state or PST states, as discussed in Part I.
As the PA-Static tool conducts internal analysis on these UPF definitions and objects and formalizes the source-sink communication models, it is required to represent this information in an organized and simple searchable format.
While reviewing the PA-Static reports and results to pursue structural anomalies efficiently, it is required to fully comprehend the contents and context of these reports, the source of the contents, organization format, special terminologies, relevancy, and correlation between the represented information, and so on. Based on the discussion in earlier sections of Part I of this article it is clear that PA-Static checks are originated and relevant to the following different resources.
List 1 – UPF and Design Object Resources Relevant to PA-Static Checks
- Power Domains, Domain Boundary, Domain Interface, HighConn, and LowConn side of ports, Domain Crossings, Source-Sink Communication Model
- The relevant Power States for Supply Sets, Supply Ports, and Supply Nets
- Power States from add_power_state or PSTs
- Design abstraction levels (RTL, GL-netlist, PG-netlist, etc.)
- Tool built-in MV and PA rules
- Cell and Pin-level Attributes from Liberty
These resources are for presenting quality PA-Static results, and they are very generic as well as comprehensive for any PA-Static verification environment. The organization chart of reports and results further depends on the analytical approaches and processing capabilities of the tool which can be best summarized as follows.
List 2 – UPF and Design Objects Resources Relevant to PA-Static Result Representation
- Syntax and Semantics of UPF definition — Revealing syntactic and semantic correctness of power intent in UPF files through referencing appropriate revision and release of UPF LRM
- UPF Strategy vs. MV Cell – Revealing correct, incorrect, missing, redundant, and not analyzed cells or strategies
- UPF Strategy and MV Cell Mix – Revealing location, type, control signal polarity, library consistency, and PG-pin connectivity of the MV cells
- Power Supplies – Revealing MV cell relevant supply set, supply port, supply net
- Design Attributes – Revealing design control signals (like scan control), clock, reset, combinational logic path, etc. are safe for deployment of UPF strategy or MV Cells
Considering the exhaustive lists of resources and reporting organization approaches mentioned above, it is required to represent PA-Static results according to design abstraction levels and on the basis of UPF, Liberty, and design analysis. It is also evident that static verification reporting is overly mediated through UPF strategies and corresponding MV cells. Hence, PA-Static verification tools are often considered as ISO, ELS, LS, PSW, RFF, and RPT, etc. checkers. Though the consideration is not wrong, the scope of the PA-Static verification are generally extended beyond checking only UPF strategies. The checker also validates UPF semantics and Liberty library consistency.
Thus reflecting all the facts and features about PA-Static verification discussed so far, it is evident that a standard PA-Static tool prevails at the minimum following set of reports for efficient debugging to fully leverage structurally clean design.
List 3 – Minimum Requirements of PA-Static Reports for Efficient Debugging
Power Intent and UPF Consistency Reports
- Power Domains (PDs)
- Hierarchical path of the created scope
- Primary power ground of PDs
- Supply set handles associated with PDs
- Reference ground of supply set
UPF Strategy Reports (considering ISO as an example)
- ISO strategy name and Relevant UPF file name
- ISO supplies
- ISO control, sense, clamp value
- Isolated signals
PA Design Elements Reports
- PA Static Reports (Contents may vary depending on design at RTL, GL-netlist, or PG-netlist)
- MV and Macro Cell Reports
- MV and Macro Cell Connection Reports
- Power States and PST Analysis Reports
The examples below show the practical UPF ISO strategy and sample results or reports for the ISO strategy (CAM_iso) checks.
Example 1: Sample of PA-Static Reporting for ISO Checks — Snippet of UPF file for ISO Strategies
Explanation of UPF Strategies: The snippet UPF code contains the definition of the ISO strategy name CAM_iso. The ISO cell is an AND type (clamp_value 0) and is located on the parent domain of PD_camera.
Example 2: Snippet of PA Architecture Report File for CAM_iso Checks
Explanation of PA Architecture Report: The snippet shows all PA architecture information, like PD, relevant UPF file, hierarchical instance scope of PDs, ISO supply, ISO control, type, strategy deployed locations, and instance lists of already inserted ISO cells that may be essential to debug ISO issues later reported in a static report file.
Example 3: Snippet of PA Design Element Report File
Explanation of PA Design Element Report: The design elements paths are listed in this report which are relevant to the scope of instantiated ISO cells.
Example 4: Snippet of MV and Macro Cell Connectivity Report File
Explanation of MV and Macro Cell Connectivity Report: The reports in this file are extracted from the Liberty of corresponding MV (ISO in this example) and Macro cells.
Example 5: Snippet of PA Static Report File
Explanation of PA Static Report: This is the key report that summarizes the results of static checks specifically on MV cells. However, when there are issues and anomalies, the corresponding issues are clearly explained in detail in several subsections.
For example, the results report ISO_CTRL_REACH_DATA with severity Warning, which requires the reports to be addressed and issues possibly corrected. The ISOLATION Cells subsection provides every possible detail of information relevant to the issues for the cell with the following sub header:
CHECK TYPE: ISO_CTRL_REACH_DATA
It is clear that the issue occurred for a cell, which is Isolation cell, Library cell name is ISO_LO, strategy name CAM_iso, relevant power domain is PD_camera. It also provides the source and sink port names, which are ~/camera_instance/out_data and ~/iso_cm_o/Z respectively.
As well it identifies the source-sink communication models, which are (PD_camera) => (PD_mobile_top). Hence in order to resolve the issue, it is required to understand the inherent meaning of the “Mnemonic Identifier” ISO_CTRL_REACH_DATA. Literally and technically this mnemonic refers that a valid isolation strategy and cell are present from (SRC PD) => (SINK PD). However, ISO enable signal for UPF strategy reaches the data pin of the cell.
The succeeding report files actually facilitate pursuing the static issues and are equally important in the debugging phases.
Example 6: Snippet of UPF, HDL and Liberty Connectivity Report File
Explanation of UPF, HDL and Liberty Connectivity Report File: This file facilitates identifying that the isolation_signal which is a control port [UPFCP1] defined in UPF file name “mobile_top.upf” line number 65, is connected to HDL [HDL1] port “is_camera_sleep_or_off_tb” of design instance “/tb”, specifically (/tb/ is_camera_sleep_or_off_tb).
Checking the “mobile_top.upf” line 65 reveals the following information:
Line 65 of mobile_top.upf:
set_isolation_control CAM_iso -domain PD_camera -isolation_signal /tb/is_camera_sleep_or_off_tb -isolation_sense high -location parent
However, checking the actual HDL design, where the ISO cell “ISO_LO” is instantiated with instance name “iso_cm_o”, is as follows:
ISO_LO iso_cm_o ( .I(camera_out_data),
.ISO_EN (is_camera_sleep_or_off), .Z(camera_out_data_
As well this is also prominent from the information provided on the PA Static Report File, where the sink port is as follows:
SINK PORT: ~/iso_cm_o/Z (PD: /tb/PD_mobile_top)
Since the ISO strategy is applied at the output of PD_camera (~/camera_instance), and cell location is specified to be parents from the UPF file, as well as “ISO_EN” is the enable port for the ISO cell, as noted in Example 4 – Snippet of MV and Macro Cell Connectivity Report File, hence it is required to modify the HDL instance .ISO_EN (is_camera_sleep_or_off) to correct the ISO_CTRL_REACH_DATA Warning.
Once corrected, it is required to rerun the design and confirm that the ISO_EN or isolation control signal is connected to the proper HDL port or net.
Example 7: Snippet of PST Analysis Report File
Explanation of PST Analysis Report File: PST analysis reports either from PST states or from add_power_states provide the logical proposition of UPF strategy requirements as shown above. Here VDD_cm and VDD are power supplies for source and sink respectively, and there is a state where VDD_cm requires to go OFF while VDD is still ON. Hence ISO requirements are marked adjacent to the tabular format. Though this may appear insignificant for a small number of power domains and combinations of their states, but for a large number, this analysis report appears to be an accommodating resource.
In addition, although the verification provides different severity levels, like Error, Warning, Info or Note, there are different schemes to handle the severity levels. Primarily Error and Warnings are subject to be properly addressed and fixed, while there are certain classes of Warnings which may be waived, suppressed, or downgraded to Info or Notes depending on the sources of the issues. As well they are usually resolved on a case by case basis. These classes of Warnings may broadly originate from DFT, Scan insertion, ECO, etc., since they are often performed after synthesis or after major MV cell physical insertion processes.
The primary objective of any verification environment is to achieve a bug-free design for implementation. Similarly, PA-Static verification requires to ensure that the design is physically correct in terms of power architecture and microarchitecture. It is evident that efficient debugging and fixing of issues, bugs, and anomalies are dependent on clear perceptions of the design specification, power specification, tool techniques, and methodologies, as well as comprehensive understanding of the reporting mechanism. Although UPF imposes an extra layer of physical complexity on PA design but static verification does not require a testbench, stimulus as well, input requirements are simple and straightforward. The PA-Static verification is mandatory along with PA-SIM throughout the entire DVIF.
- 1. P. Khondkar, “Low-Power Design and Power-Aware Verification”, Springer, October, 2017.
- 2. P. Khondkar, P. Yeung, et al., “Free Yourself from the Tyranny of Power State Tables with Incrementally Refinable UPF”, February-March, DVCon 2017.
- 3. Design Automation Standards Committee of the IEEE Computer Society, “IEEE Standard for Design and Verification of Low-Power, Energy-Aware Electronic Systems”, IEEE Std 1801-2015, 5 December 2015.
- 4. P. Khondkar, P. Yeung, D. Prasad, G. Chidolue, M. Bhargava, “Crafting Power Aware Coverage: Verification Closure with UPF IEEE 1801”, Journal of VLSI Design and Verification, pp.6-17, Vol. 1, November 2017.
- 5. P. Khondkar and M. Bhargava, "The Fundamental Power States: The Core of UPF Modeling and Power Aware Verification", Whitepaper at Mentor.com, December 2016.
Back to Top