PrimePower - Synopsys

Details: Last Updated: Saturday, 25 March 2023 04:58; Published: Tuesday, 03 November 2020 18:56; Hits: 2074

PrimePower (PP):

Synopsys PrimePower Product family analyzes power consumption of design at various stages starting from RTL all the way to final PnR netlist. PrimePower provides vector-free and vector-based peak power and averaged power analysis capabilities for RTL and gate-level designs. It calculates the power for a circuit at the cell level and reports the power consumption at the chip, block, and cell levels. Supported power analysis modes include average power, peak power, glitch power, clock network power, dynamic and leakage power, and multivoltage power;

There are 2 flavors of PrimePower:

PrimePower RTL: This measures power consumption at RTL level. PrimePower RTL leverages the Predictive Engine from the RTL Architect tool and synthesis engine to synthesize RTL under the hood and analyze RTL for power.
PrimePower (Gate level): When we say PrimePower only (without RTL), it means PrimePower for gate level power. During implementation and signoff, PrimePower provides accurate gate-level power analysis report based on actual netlist. 2 power analysis modes are supported for gate level - avg mode and time based mode.

Using PrimePower:

PrimePower may be used standalone, or may be invoked from within other Synopsys tool as PrimeTime. Also PT may be invoked from within PP. Both tools share many of the same libraries, databases, and commands, and support power and timing analysis. We need separate licenses of PrimePower and PrimeTime irrespective of which way they are invoked. These are the 2 ways:

PWR_SHELL by Invoking PP: invoke PP by typing pwr_shell on the terminal. From within PP, we can invoke PT too.
- pwr_shell> set power_enable_timing_analysis true => This invokes PT from within PP. Either we can read PT session from some other run, or generate timing data directly.
PT_SHELL by Invoking PT: invoke PT by typing pt_shell on the terminal. Then PP may be invoked from within PT. This keeps timing and power numbers ine one place and eliminates need for PP standalone setup.
- pt_shell> set power_enable_analysis true => This invokes PP from within PT. Either we can read PP session from some other run, or generate Power data directly.

PrimePower (PP) and PrimeTime-PX (PT-PX):

When Synopsys initially came with their Power tool in 2000's, it used the 2nd option above (i.e Power tool was invoked from within PT). They called this tool PT-PX or PT with Power Analysis. Even though it was invoked from within PT_SHELL, it required separate license of PT-PX to run power. This tool calculated power only at gate level. Later they added the capability to calculate power at RTL level. This required power tool to be invoked separately. So, they introduced PrimePower (PP) as a standalone tool for Power analysis. PP could be invoked for both RTL and gate level Power. PT-PX was rebranded as belonging to "PrimePower family". For our purpose, PT-PX is treated same as PP.

Startup File: When PP or PTPX is invoked, we can have an optional synopsys startup file that will be sourced on startup. It's similar to PT startup file:.synopsys_pt.setup

PT-PX combines simulation time window to report power within a window.

All the options and cmds are almost same for PP and PT-PX. Inputs and Outputs are same too.

Inputs:

Library: A cell library containing timing and pwr characterization info for each cell.
Gate level netlist: In verilog, VHDL or Synopsys db format.
Design constraints: An SDC file containing design constraints to calculate the transition time on the primary inputs and to define the clocks.
Switching activity: The design switching activity information which can be specified in an event file in the VCD or FSDB format.
Net parasitics: A parasitics file (SPEF) containing net capacitances for all the nets.

Outputs

Various power reports.

PP:

PP can be invoked for both RTL and Gate. When we say PP, we mean gate level power runs. Only when we say PP-RTL is when we refer to PP running on RTL.

Steps:

Following are the steps to invoke PP:

0. Invoke pwr_shell normally => As you would for PT timing runs

pwr_shell -2012.12-SP3 -f scripts/run_power.tcl | tee logs/run_power.log => can be invoked in gui mode too. run_pwer.tcl has cmds for running power flow, so that we can run in batch mode (i.e automated). If we don't want it automated we can type the cmds on pt_shell too. By default, all cmds processed by tool including those in setup file are dumped in pwr_shell_command.log.

GUI: To start gui, type "gui_start" from pwr_shell window.

1. set library, read gate level verilog netlist and spef file => same as in normal PT flow. pwr is calc for chosen PVT corner.
set search_path "$search_path /db/pdkoa/1533e035/current/diglib/pml48h/synopsys/bin"
set target_library PML48H_W_85_3_CORE.db
set link_library {* PML48H_W_85_3_CORE.db}

read_verilog /db/ATAGO/.../FinalFiles/digtop_final_route.v => read final routed netlist
current_design digtop
link

set_app_var power_limit_extrapolation_range true => By default, PP extrapolates indefinitely if the data point for internal power lookup is out of range. When set to TRUE, the tool limits the extrapolation.this is false. That means that infinite extrapolation

set_operating_conditions

2. Invoke PT or restore PT session

update_timing

restore_session

check_power

read_parasitics /db/ATAGO/.../FinalFiles/digtop_final_route_max.spef => read max spef file

2. set power analysis so that PTPX license is invoked
set power_enable_analysis true => This is what invokes PP from within PT.
set power_analysis_mode averaged | time_based

check_activity

3. Read VCD file from one of the simulation (it needs to be gate level VCD file with back annotation of parasitics)
read_vcd /sim/ATAGO/.../sim1_max.vcd.gz -strip_path digtop_tb/IDUT/spi_regs -time {100489 800552} => strips module of interest so that pwr is reported starting from that module as top level. time is in ns.
#report_switching_activity > reports/power_swtching.rpt => to examine tr/sp (see below) and vcd file syntax

#write_activity_waveforms => generates activity waveforms from the activity file.

4. report power
#check_power -verbose => prior to analysis, verifies that analysis i/p are valid
#update_power => This is needed for RTL VCD or when no vcd provided to propagate activity to nets/registers not annotated from RTL VCD file.
#report_switching_activity => to examine propagated values of tr/sp
#create_power_waveforms -cycle_accurate => to show pwr waveform
report_power > ./reports/power_summary.rpt
report_power -hier > ./reports/power_hierarchy.rpt
#report_power -cell -flat -net -hier -verbose -nosplit > power_detail.rpt

save_session =>
exit

PT-PX:

When Synopsys initially came with their Power tool in 2000's, it used the 2nd option above (i.e Power tool was invoked from within PT). It called this tool PT-PX or PT with Power Analysis. Even though it invoked from within PT_SHELL, it required separate license of PT-PX. PT-PX combines simulation time window to report power within a window.

Steps:

Following are the steps to invoke PT-PX:

0. Invoke pt_shell normally => As you would for PT timing runs

pt_shell -2012.12-SP3 -f scripts/run_power.tcl |tee logs/run_power.log => can be invoked in gui mode too. run_pwer.tcl has cmds for running power flow, so that we can run in batch mode (i.e automated). If we don't want it automated we can type the cmds on pt_shell too.

run_power.tcl script above has following cmds:

read_verilog /db/ATAGO/.../FinalFiles/digtop_final_route.v => read final routed netlist
current_design digtop
link

read_parasitics /db/ATAGO/.../FinalFiles/digtop_final_route_max.spef => read max spef file

2. set power analysis so that PP license is invoked
set_app_var power_enable_analysis true => This is what enables Power Analysis from within PT.
set power_analysis_mode averaged

PP:

Report: power summary report:

1. static power: Cell Leakage power. It's leakage in the cell from VDD to VSS when cell i/p is at 0 or 1 (subthreshold lkg from src to drn since gates never turn off completely). It includes gate lkg also (gate lkg is captured only for i/p pins for each transistor, as o/p pin will finally connect to i/p pin of some other transistor. gate lkg is just the current flowing into the gate when i/p of gate is 0 or 1). cell lkg pwr number comes from *.lib file. Pwr(lkg)=V*I(subthreshold_lkg)+V*I(gate_lkg).
It has a default lkg pwr number for each cell, as well as different lkg pwr numbers depending on diff i/p values. ex:
cell (AN210_3V) {
cell_leakage_power : 1.731915E+00; => default lkg pwr
leakage_power () { => we can have many of these conditions for each cell
value : 1.718650E+00; => lkg pwr = 1.7pW when A=1 and B=0. pwr unit defined as pw by "leakage_power_unit : "1pW";" in .lib file
when : "A&!B";
}

2. dynamic power: 2 components to this:

A. internal pwr: This includes short ckt pwr when cell o/p is switching, as well as pwr due to charging of internal nodes in the cell (due to src/drn cap on all o/p nodes and gate cap on internal nodes). cell int pwr number comes from *.lib file. Pwr(int)=Eint*Tr where Tr=number of toggles/time.
Just like timing() section, we have internal_power() section for o/p pin. It shows int pwr for each combination of i/p values (as pwr will change due to short ckt current, drn/src cap changing). ex:
cell (AN210_3V) {
pin (Y) { => pwr is always for o/p pin, since i/p pin pwr is calcualted separately as switching pwr.
internal_power () { => pwr unit is in pJ = power unit(pW) * time_unit(s) (it's energy, not power).
related_pin : "A"; => this is when o/p changes due to i/p pin A changing
rise_power (outputpower_cap4_trans5) { ... 34.39 .. } => pwr under diff cap load on o/p pin, and diff slew on i/p pin
fall_power (outputpower_cap4_trans5) { ... 34.39 .. } => fall_power is when o/p pin falls due to pin A rising/falling
}
internal_power () {
related_pin : "B"; => this is when o/p changes due to i/p pin B changing
rise_power (outputpower_cap4_trans5) { ... 34.39 .. } => rise_power is when o/p pin rises due to pin B rising/falling
fall_power (outputpower_cap4_trans5) { ... 40 .. } => 40pJ energy per toggle. Since time is in ns, pwr=mw??
}
}
}

B. switching pwr: This is due to charging/discharging of all the o/p load in design. This includes wire cap and gate cap on i/p pins which switch whenever o/p pin of any gate switches. Pwr(sw)=0.5*C*V^2*Tr. Tr=number of toggles/time.

Total_pwr = Pwr(lkg) + Pwr(int) + Pwr(sw) = Pwr(lkg) + Eint*Tr + 0.5*C*V^2*Tr (Pwr(lkg) and Eint come from.lib).
To calc avg pwr, static probability (Sp) is calcualted for all the nodes to be at 1 or 0. This is then used to calc lkg pwr for each cell. Toggle rate is caluclated for each node to calc dynamic pwr.
To calc peak pwr, vcd file is required to analyze events. It's useful for dynamic IR drop. If vcd file not provided, then tool doesn't know the seq of events. Merely toggle rate doesn't tell it whether all nodes toggle at same time or not.
When VCd file is not provided, default Tr/Sp is applied to starting points (PI, black box o/p). default Tr/Sp can be modified using (power_default_toggle_rate, power_default_static_probability)

Nav view search

Navigation

Search

PrimePower - Synopsys