Understand what PA-Static reports are telling you for efficient debugging.
In Part 1 of this three article series on power aware (PA) verification, we examined the foundations and verification features of PA static checks. In Part 2, we discussed the features of the static verification library and described best static verification practices.
Part 3 concludes this series with details of static PA verification tool procedures using a real example to analyze PA-Static results and reporting, as well as efficient debugging PA-Static anomalies.
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 logic and relevant UPF objects on schematic viewers often adds advantages for pinpointing bugs and fixing them quickly.
PA-Static verification is mainly UPF-strategy oriented, such as PSW, ISO, ELS, LS, RFF, and RTP etc. These are defined within the UPF explicitly through different UPF strategy commands (for example, set_isolation, and set_level_shifter), and their association with different power domains are validated through their definition and the add_power_state or PST states, as discussed in Part 1 and Part 2.
As the PA-Static tool conducts internal analysis on these UPF definitions and objects and formalizes the source-sink communication models, you must represent this information in an organized and simple searchable format.
While reviewing the PA-Static reports and results to pursue structural anomalies efficiently, you must fully comprehend the contents and context of these reports, the source of the contents, the organizational format, special terminologies, relevancy, and correlation between the represented information, and so on. PA-Static checks are originated and relevant to the following resources.
List 1 – UPF and Design Object Resources Relevant to PA-Static Checks
These resources are for presenting quality PA-Static results, and they are 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
Considering these two exhaustive lists of resources and reporting organization approaches, it is necessary 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 checkers. Though this consideration is not wrong, the scope of PA-Static verification is 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, a standard PA-Static tool must provide, at a minimum, the following set of reports to achieve efficient debugging and to fully leverage structurally clean designs.
List 3 – Minimum Requirements of PA-Static Reports for Efficient Debugging
The examples on the following pages 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)
set_isolation CAM_iso -domain PD_camera \
-isolation_power_net VDD_cm \
-isolation_ground_net VGD \
-elements {mid_1/mt_1/camera_instance} \
-clamp_value 0 -applies_to outputs
set_isolation_control CAM_iso -domain PD_camera \
-isolation_signal /tb/is_camera_sleep_or_off_tb \
-isolation_sense high \
-location parent
map_isolation_cell CAM_iso -domain PD_camera -lib_cells {ISO_LO}
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
Power Domain: PD_camera, File: ./mobile_top.upf(7).
Creation Scope: /tb
Extents:
1. Instance : ~/camera_instance
Isolation Strategy: CAM_iso, File: ./mobile_top.upf(64).
Isolation Supplies:
power : /tb/VDD_cm
ground : /tb/VGD
Isolation Control (/tb/is_camera_sleep_or_off_tb), Isolation Sense (HIGH), Clamp Value (0), Location (parent)
Signals with default isolation cells:
1. Signal : ~/camera_instance/out_data, isolation cell : ~/out_data_UPF_ISO
Signals with -instance isolation cells:
1. Signal : ~/camera_instance/out_data, isolation cell : ~/iso_cm_o
2. Signal : ~/camera_instance/camera_state[0], isolation cell : ~/iso_cm_s0
3. Signal : ~/camera_instance/camera_state[1], isolation cell : ~/iso_cm_s1
Explanation of PA Architecture Report: The snippet shows all PA architecture information. These include PD, relevant UPF file, hierarchical instance scope of PD, 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
PD_camera.CAM_iso-instance: {Path7} = scope ~/iso_cm_s1
PD_camera.CAM_iso-instance: {Path8} = scope ~/iso_cm_s0
PD_camera.CAM_iso-instance: {Path9} = scope ~/iso_cm_o
PD_camera.CAM_iso-instance: {Path7}/Z
PD_camera.CAM_iso-instance: {Path8}/Z
PD_camera.CAM_iso-instance: {Path9}/Z
Explanation of PA Design Element Report: The design element paths that are relevant to the scope of instantiated ISO cells are listed in this report.
Example 4 – Snippet of MV and Macro Cell Connectivity Report File
Verification Model File : isolation.v(4)
Liberty Model File : isolation.lib(7)
is_isolation_cell : true, File : isolation.lib(7)
Ports :
ISO_EN, File : isolation.v(4)
direction : input
related_power_pin : VDD, File : isolation.lib(27)
related_ground_pin : VSS, File : isolation.lib(26)
isolation_cell_enable_pin : true, File : isolation.lib(25)
I, File : isolation.v(4)
direction : input
related_power_pin : VDD, File : isolation.lib(21)
related_ground_pin : VSS, File : isolation.lib(20)
isolation_cell_data_pin : true, File : isolation.lib(19)
Z, File : isolation.v(4)
direction : output
functionality : ((~ISO_EN) & I), File : isolation.lib(32)
power_down_function : ((~VDD) | VSS), File : isolation.lib(31)
related_power_pin : VDD, File : isolation.lib(34)
related_ground_pin : VSS, File : isolation.lib(33)
VDD, File : isolation.lib(9)
direction : input, File : isolation.lib(9)
pg_type : primary_power, File : isolation.lib(10)
VSS, File : isolation.lib(13)
direction : input, File : isolation.lib(13)
pg_type : primary_ground, File : isolation.lib(14)
Explanation of MV and Macro Cell Connectivity Report: The report in this file is extracted from the Liberty library of the corresponding MV (ISO in this example) and Macro cells.
Example 5 – Snippet of PA Static Report File
+==============================================================================================+ || Domain Crossing Checks Summary report +==============================================================================================+ Check-ID Count Severity Description ----------------------------------------------------------------------------------------------- ISO_VALID 7 Note Valid isolation cells ----------------------------------------------------------------------------------------------- +===============================================================================================+ || GLS Checks Summary report +===============================================================================================+ Check-ID Count Severity Description ------------------------------------------------------------------------------------------------ ISO_VALID_CELL_WITH_STRATEGY 7 Note Valid Isolation cell and strategy ------------------------------------------------------------------------------------------------- ISO_VALID_STRATEGY_NO_CELL 1 Note Isolation strategy with NO cell ------------------------------------------------------------------------------------------------- ISO_CTRL_REACH_DATA 3 Warning Isolation cell with control reaching data ------------------------------------------------------------------------------------------------ +===============================================================================================+ || Domain Crossing wise static Checks Detailed report +===============================================================================================+ --------------------------------------------------------------------- 2. Source power domain: PD_camera to Sink power domain: PD_mobile_top. Total 4(1*) Valid isolation cells 2.1. Source port: ~/camera_instance/camera_state[0] [LowConn] to Sink port: ~/iso_cm_s0/Z [LowConn], width:1 Total 1 Valid isolation cells 2.1.1. Inferred type: ISO_VALID, count: 1 Candidate Port: ~/camera_instance/camera_state[0], Isolation Cell: ~/iso_cm_s0(ISO_LO), Strategy: CAM_iso, Domain: PD_camera Possible reason: 'Isolation is required and is present from (PD_camera) => (PD_mobile_top)' Analysis link: [PD1_to_PD2] +===============================================================================================+ || GLS Checks Detailed report ================================================================================================+ +.............................................................................+ || ---- ISOLATION CELLS ---- || +.............................................................................+ +---------------------------------------------------+ || DESIGN CELL : ~/iso_mem_s1(ISO_LO) || +---------------------------------------------------+ CELL TYPE : Isolation Cell LIBERTY INFO : Model : ISO_LO, Verification Model File: ~/libraries/isolation/isolation.v(4), Liberty Model File : ~/libraries/isolation/isolation.lib(7) CHECK TYPE: ISO_CTRL_REACH_DATA STRATEGY : MEM_iso, File: ./mobile_top.upf(68) POWER DOMAIN : /tb/PD_memory, File: ./mobile_top.upf(8) SOURCE PORT : ~/internal_memory/mem_ls_lh3/I (PD: /tb/PD_memory) SINK PORT : ~/iso_mem_s1/Z (PD: /tb/PD_mobile_top) ANALYSIS REASON : Isolation is required and is present from (PD_memory) => (PD_mobile_top). However ISO enable signal for UPF strategy reaches the data pin of the cell +-----------------------+ || MISSING DESIGN CELL || +-----------------------+ CHECK TYPE : ISO_VALID_STRATEGY_NO_CELL STRATEGY : CAM_iso, File: ./mobile_top.upf(64) POWER DOMAIN : /tb/PD_camera, File: ./mobile_top.upf(7) SOURCE PORT : ~/camera_instance/out_data (PD: /tb/PD_camera) SINK PORT : ~/camera_instance/out_data (PD: /tb/PD_mobile_top) ANALYSIS REASON : Isolation is required and is present from (PD_camera) => (PD_mobile_top). However corresponding cell is not found, hence inferred
Explanation of PA Static Report: This is the key report that summarizes the results of static checks on MV cells, specifically. 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 report 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 an Isolation cell, the Library cell name is ISO_LO, the strategy name CAM_iso, and the 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, you must understand the inherent meaning of the “Mnemonic Identifier” ISO_CTRL_REACH_DATA. Literally and technically, this mnemonic indicates that a valid isolation strategy and cell are present from (SRC PD) => (SINK PD). However, a ISO enable signal for the 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
-- This is the report of connections between UPF, HDL and -- liberty files. -- Format : -- Hierarchical path of net/port [UNIQUE ID] <=/<=> Hierarchical path of net/port [UNIQUE ID] -- where : -- UNIQUE ID : Unique id for UPF/HDL/Liberty nets/ports -- UPFSN# ==> UPF supply net -- UPFSP# ==> UPF supply port -- UPFCP# ==> UPF control port -- UPFAP# ==> UPF acknowledge port -- UPFLP# ==> UPF logic port -- UPFLN# ==> UPF logic net -- HDL# ==> HDL port/net -- LIB# ==> LIBERTY port/net -- <= : LHS net/port is driven by RHS net/port -- <=> : Inout connection -- LHS VCT : VCT used for LHS side of connection -- RHS VCT : VCT used for RHS side of connection ---------------------------------------------------------- /tb/PD_camera.CAM_iso.PWR [UPFSP2] <= /tb/VDD_cm [UPFSN2]. ./mobile_top.upf(64) /tb/PD_camera.CAM_iso.GND [UPFSP5] <= /tb/VGD [UPFSN3]. ./mobile_top.upf(64) /tb/PD_camera.CAM_iso.isolation_signal [UPFCP1] <= /tb/is_camera_sleep_or_off_tb [HDL1]. ./mobile_top.upf(65)
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 the UPF file named “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, 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_isolated) );
As well, this is 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 the cell location is specified to be parents from the UPF file, and “ISO_EN” is the enable port for the ISO cell (as noted in Example 4 – Snippet of MV and Macro Cell Connectivity Report File) 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
3. PD_camera -> PD_mobile_top [PD1_to_PD2]:
Isolation: Required
Level shifter: Not Required
Maximum voltage difference: 0.00 V
Details:
Analysis between supplies:
Source Supply: VDD_cm, drives PD_camera.primary.power
Source Supply: VSS, drives PD_camera.primary.ground
Sink Supply: VDD, drives PD_mobile_top.primary.power
Sink Supply: VSS, drives PD_mobile_top.primary.ground
Reason: Same source and sink GROUND supplies.
PST used for analysis: /tb/top_pst
+-------------+-------------------+
| State(s) | VDD_cm | VDD |
| | {Source} | {Sink} |
+-------------+-------------------+
| {ON} | ON_1_0 | ON_1_0 |
| {SLEEP,OFF} | OFF | ON_1_0 |Iso
+-------------+-------------------+
Explanation of PST Analysis Report File: PST analysis reports, from either 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 is required 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, for a large number this analysis report is 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 Warning are subject to be properly addressed and fixed, while there are certain classes of Warning 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 Warning may broadly originate from DFT, scan insertion, ECO, and the like, 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 ensuring 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 mechanisms. Although UPF imposes an extra layer of physical complexity on PA design, static verification does not require a testbench; as well, input requirements are simple and straightforward. The PA-Static verification is mandatory along with PA-SIM throughout the entire DVIF.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply