Part 2: Key features of the PA static verification library, plus best static verification practices.
In Part 1 of this series on power aware (PA) verification, we examined the foundations and verification features of PA static checks. In Part 2, we will discuss the features of the static verification library and describe best static verification practices.
Library for Static Verifications
Cell-level and pin-level attributes from Liberty are mandatorily required for accurate PA-Static verification at the GL-netlist (post-synthesis) and PG-netlist (post P&R) levels of the design. Recalling the generic or specific examples of Liberty level shifter (LS) cells from the LRM, the following are known as special cell-level attributes that categorize this particular cell as a level shifter.
Example 1 – Liberty Cell-Level Attributes for LS
is_level_shifter: true, level_shifter_type: HL_LH, input_voltage_range, output_voltage_range.
The PA-Static checker searches for these attributes to identify the cell as LS as well as the operating voltage ranges of the LS.
All other remaining attributes are termed as pin-level attributes. The PA-Static checker tool collects the primary power and ground (as well bias) pin or port information from pg_pin and pg_type attributes together. The ‘related_power/ground_pin’ or ‘related_bias_pin’ provides the related power, ground, or bias supply connectivity information for each input or output logical port or pin of the cell. Related supply is augmented with pg_pin and pg_type attributes that indicate the functionality of the supply whether it is primary power, primary ground, or an N or P-WELL bias pin, as shown below.
Example 2 – Related Power, Ground or Bias Pin of LS
pg_pin(VNW) {pg_type : nwell;
pg_pin(VPW) {pg_type : pwell;
pg_pin(VDDO){pg_type : primary_power ;
pg_pin(VSS) {pg_type : primary_ground ;
pg_pin(VDD) {pg_type : primary_power ;
std_cell_main_rail : true ;
....
pin(A) {
related_power/ground_pin : VDD/VSS ;
related_bias_pin : “VNW VPW";
level_shifter_data_pin : true ;
....
Hence, for multi-rail cells, specifically the multi-voltage (MV) and macro cells — like the LS in Figure 1 (which is a MV cell) — this is usually possesses different related supplies for the input, which is pin (A) with related supplies (VDD/VSS), and the output, which is pin (Y) with related supplies (VDDO/VSS).
Figure 1: Level-shifter with related PG-pin information.
The ‘std_cell_main_rail’ attribute defines the primary power pin (VDD) that will be considered as the main rail, a power supply connectivity parameter which is required when the cell is placed and routed at the post P&R level. However, at the GL-netlist, the PA-Static checker utilizes this information for analyzing the main or primary power of the MV or Macro cells. The std_cell_main_rail checks are done based on the following Liberty attributes.
Example 3 – Liberty Syntax for std_cell_main_rail
pg_pin(VDD) {
voltage_name : VDD;
pg_type : primary_power;
std_cell_main_rail : true;
}
pg_pin(VDDO) {voltage_name : VDDO;
pg_type : primary_power;
}
The std_cell_main_rail attribute is defined in a primary_power power pin. When the attribute is set to True, the pg_pin is used to determine which power pin is the main rail in the cell. This is VDD in Example 3. Actually the implementation (synthesis) tool looks at the std_cell_main_rail (not the voltage_name) specifically for LS (and Macro), and connects or inserts LS accordingly in the design.
Example 4 shows the snippet of the results for std_cell_main_rail analysis from PA-Static verification.
Example 4 – Snippet of PA-Static Verification Result for std_cell_main_rail
VDD std_cell_main_rail: true, File: ls.lib (15) pg_type: primary_power, File: ls.lib (13) VDDL pg_type: primary_power, File: ls.lib (18) VSS pg_type: primary_ground, File: ls.lib (22)
Although, it is categorically mentioned that the PA Sim-model library requirements are optional for a PA-Static tool for conducting verification and are used only for compilation purposes. However, the PA-Static tool conducts consistency checks between the PA Sim-model libraries and its corresponding counterpart in the Liberty library to ascertain whether the Sim-model library is power aware. The consistency checks compare the power supply port and the net or pin names for all the power, ground, related, and bias pins.
The PA-Static checker further reveals the logic pin equivalency between these two libraries since related power and ground information are relevant to the logic ports. If the supply and logic ports or pins for both the libraries are matching, the simulation model library is regarded as power aware (or PA Sim-model library). However, the power_down_function are not compared between Sim-model and Liberty libraries, as the corruption semantics through the model or Liberty power_down_function is exclusively driven by PA-SIM.
Static Verification Practices
The PA verification fundamentals are already discussed and a persuasive foundation of PA-Sim and PA-Static verification platforms are established through previous sections. It is revealing that PA methodologies and techniques impose enormous challenges in functional and structural paradigms of the design under verification.
However, it is observed that a clear perception of the design and power specification, power intent, adopted verification techniques, inherent tool features, and subtle methodologies qualifies for the successful accomplishment of power aware verification. Even though the structural issues affect a design physically in architectural and microarchitectural aspects, however the following standpoints simplifies the PA-Static verification procedures in such perspective.
List 1 – Simplified PA-Static Verification Standpoints
Evidently these aspects will ensure the achievement of clean PA design in terms of architectural and microarchitectural perspective.
Unlike the Questa PA-SIM which requires three-step flow for dynamic verification (compile, elaborate/optimize and simulate), the PA-Static verification tool procedure is based on only two-steps: compile and optimize.
Since the compilation criterion of a design under verification is exactly the same for both PA-SIM and PA-Static, as well the optimization is the phase for both PA verification tools, where the power aware objects (e.g. Power Domain, Power Supply, Power Strategies etc.) are articulated throughout the compiled design from the UPF.
Obviously, testbenches are unnecessary during compilation of design targeted for PA-Static verification. Also it is important to note that here are certain PA-Static specific tool procedures available at the optimization phase. These procedures ensure appropriate extraction and accumulation of power information from the UPF, Liberty, and design to conduct internal analysis and impose built-in or user-specified external MV or PA rules on the design accordingly. The PA-Static related special commands and options are based on several aspects as follows:
List 2 – Fundamental Aspects to Drive PA-Static Verification
These are almost similar to PA-SIM, only the inclusion of “Debugging capabilities” are redundant for PA-Static, since the results of static verification are available at the optimization phase. However, there are different result reporting verbosity levels for PA-Static that are generated in the optimization phase and are discussed in succeeding sections.
The design entry requirements for PA-Static are also exactly the same as for the PA-SIM. PA-Static also requires a complete HDL representation of the design in Verilog, SystemVerilog, VHDL, or any mix combination of these languages. Though it is highly recommended that the HDL design entries are in synthesizable RTL, Gate-Level netlist, PG-netlist, or any combination of these forms. The first step is to compile the design through vlog or vcom commands for Verilog & SystemVerilog and for VHDL respectively.
The next phase, optimizing the compiled design through the vopt command is the most crucial part for static verification. Similar to PA-SIM, vopt for PA-Static processes the UPF power intent specifications, Liberty libraries and accepts all other power-related verification commands and options as an arguments. The Questa PA-Static typical commands and options format is shown below.
Example 5 – Typical Command Format for Standard PA-Static Flow
Compile: vlog -work work -f design_rtl.v
Optimize:
vopt –work work \ –pa_upf test.upf \ –pa_top “top/dut” \ –o Opt_design \ -pa_checks=s \ <Other PA commands>
To note, for the vopt procedure, -pa_checks=s, here “s” stands for all the possible and available static checks within the PA-Static tool. However, fine-grain control options allows conducting or disabling any particular checks, like conducting only ISO relevant checks, are possible through the following tool procedures at vopt.
Example 6 – Controlling and Conducting Specific PA-Static Checks for ISO Only
Compile: No Change
Optimization: vopt- requires to add “vopt -pa_checks=smi, sri, sii, svi, sni, sdi, si”, along with all other commands and options as required.
Similarly for conducting PA-Static verification on a GL-netlist and PG-netlist, the following tool procedures are required.
Example 7 – Conducting PA-Static Checks on GL-netlist
Compile: No Change
Optimization: vopt- requires to add “vopt -pa_checks=s+gls_checks”.
Example 8 – Conducting PA-Static Checks on PG-netlist
Compile: No Change
Optimization: vopt- requires to add “vopt -pa_enable=pgconn”, along with “vopt -pa_checks=s+gls_checks” and all other commands and options as required.
As mentioned earlier, the Liberty or (.lib) file is mandatory for PA-Static checks, specifically from the GL-netlist up to the PG-netlist, or even for mixed-RTL. Fortunately, the tool procedures for Liberty processing during PA-Sim are exactly the same for PA-Static.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply