PrimePower - Synopsys

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:

  1. 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.
  2. 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:

  1. 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.
  2. 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 in 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". Synopsys confirmed that PP is actually a superset of PT-PX, so PP should be used going forward (Do NOT use PT-PX anymore as of 2025). For our purpose, PT-PX is treated same as PP in notes below (as the notes are from 2023, when I was still using PT-PX). 

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

PP/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.

 2 Imp terms in Power:

  • Static probability (SP) => This is the probabilty of a signal to be at logic 0 (SP0) or logic 1 (SP1). If SP1=0.7, it implies that the signal is at logic 1 for 70% of the time. By default, SP0 and SP1 are 0.5, implying logic is 1 for one half the time.
  • Toggle rate (TR) => This is the number of 0-to-1 and 1-to-0 logic transitions of a design object per unit of time, such as a net, a pin, or a port.
  • Switching activity => This consists of both the SP and TR.

 

 


 

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 => 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. PP can be invoked in gui mode too by using -gui option (pwr_shell -gui). In gui mode, it's easy to enter further cmds as it's just selecting required items from menu list. 

GUI: To start gu from within shell (if not invoked at startup), type "gui_start" from pwr_shell window.

1. PT run: set library, read gate level verilog netlist and spef file => same as in normal PT flow. pwr is calc for chosen PVT corner.

### I. Below cmds are for regular PT runs
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}

set_operating_conditions ...

read_verilog /db/MYCHIP/.../FinalFiles/digtop_final_route.v => read final routed netlist

load_upf /.../digtop_final.upf => if UPF is available
current_design digtop
link_design

read_parasitics /db/MYCHIP/.../FinalFiles/digtop_final_route_max.spef => read max spef file (this has parasitics, i.e R,C for all nets)

read_sdc /../digtop.sdc => has all constraints as clk defn, False paths, etc. This is needed for PT runs (not for PP)

#update_timing

check_timing

report_timing

2. PP run: set power analysis so that PTPX license is invoked

### II. Below cmds are for PP/PTPX runs

set power_enable_analysis true => This is what invokes PP from within PT.
set power_analysis_mode averaged | time_based

#set_power_derate => This can be sued to set derating factor for power rails or on specific cells, where the power is adjusted by a factor when calculating it. This allows us to adjust power as needed to match silicon power more closely (similar to how we use derating for timing).

check_activity

3. Read VCD or FSDB file from one of the simulation (it needs to be gate level VCD file with back annotation of parasitics)
read_vcd /sim/MYCHIP/.../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

 

### 2. Now we start the powr runs (PP)

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 (default value is FALSE). When set to TRUE, the tool limits the extrapolation. That is needed for more accurate pwr values when there are many high fanout nets as clks, reset in design.

 

2. Invoke PT or restore PT session

 

restore_session

check_power


 

PT-PX:

This is the flow when we want to invoke PT, and then from within PT, we invoke PT-PX.

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:


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

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. This cmd is needed, else PT-PX won't run.
set power_analysis_mode averaged

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

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
exit

 


 

Restoring pt_shell:

We sometimes want to restore pt_Shell/pp_shell to do some debug work or to get more data on specific parts of design. We can restore pt_shell and then run below cmds:

pt_shell> report_power -cell_power [get_cells top/i_and2] => reports pwr components for given cell

                       Internal  Switching Leakage   Total
Cell                    Power     Power     Power     Power    (     %)   Attrs
--------------------------------------------------------------------------------
top/i_and2        0.0020    0.0300 1.426e-10 0.032 (100.00%)
--------------------------------------------------------------------------------
Totals (1 cell)    0.0020    0.0300 1.426e-10 0.032 (100.0%)

If we are writing a script to gather these numbers, then we can use "get_att" cmd to get pwr attr
pt_shell> list_attributes -application -class cell -nosplit => This lists all attr for cells. We see *power* attr

pt_shell> get_att [get_cells top/i_and2] internal_power => gives internal power. Similarly for switching_power, leakage_power and total_power. Also gives other pwr as dynamic_power, glitch_power, peak_power, etc.

 


 

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/discharging 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 slew rate and o/p cap load (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 calculated 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)