Power Analysis Inputs

Power Analysis

 Inputs For power Analysis

1. Netlist
2. Constraints
3. Upf
4. Liblist
5. Vcd name
6. Tb_top_instance
7. Ptpx_clock_period
8. Rail Names 
9. Sdf (Optional)
10. Spef (Optional)
11. Mapping file

Netlist: - 

-We should Provide the flat netlist otherwise should miss the interface information

-We should mention the Netlist of ram's because who libs don't have the Power information

-We should mention the Top-level Netlist and black level Netlists

Liblist:

-Give all the standard cells and memories Libs which will have the power information

Spef

-Spef contains the wire capacitance

Constraints

-From this file, we can read the transition of the Pin (If you have already flat constraints, you can use it otherwise use hierarchical constraints because we are not considering the False path, multi cycle paths, and Half cycle paths

UPF:

-Where you have the Power connectivity and voltage, Rail information

VCD:

-We can get the Activity information from this File

TB_top_instance:

-For which black do you want to do the power analysis this will indicate that hm

PTPx_clk_period:

-We can take the Dominant clock, clock period for ptpx because it will reach the maximum percentage of the flops

Rails:

-Rail names we can get them from the UPF file

SDF

-Where we have the exact interconnect and Call delays are present

Placements checks

• Congestion
• If the congestion is there in your design first check in which region you got the congestion hotspot
• If it is with cell density use partial blockage , how much percentage you gave to clear the congestion hotspot 
• If it is due to pin density , Use cell padding /keep_out_margin ,how much padding number you gave and for which cell/instance/module
• If congestion is there at Macro pins , think about how to resolve the issue 
• First check is there any sufficient Blockage or not if it is not there give proper blockage
• keep out margin will also helps 
• You may see the shorts on macro pins with routing blockage on it ,so you should reduce the route blockage area on macro 
• Check the channel spacing is there or not otherwise you may see the congestion
• Remember in which metal layer, you got the congestion 
• Timing
• You should take care about the setup time violations not for Hold time violations but it should be under control
• why we did not check the hold time violations at this stage means clock is not yet build, the delay or not real these delays are estimated delays
• If you get the setup time violations check about the flop location, if it is too far use bounds
• Even though setup time is not fixed ,Get the all nets which are there in that path and  you can route it in top metal layer by using specify_net_weight
• Use net guides also you fix the setup time violations set_net_priority which metal layers are used to route first
• If the combinational delay  is more than the clock period you should inform to RTL Team, based on there guidelines use multi_cycle paths
• what is the uncertainty, how much value is there for setup and hold uncertainty 
• What is latency,how much value you gave for both source and network latency
• If data to data to data check is required for a particular module or module ports 
• Density
• check Placement Density
• If the pin density is more ,you have to check the don't touch or don't use attribute on the cells ,If these attributes are not specified tool may use those cells 

PowerPlan checks

• Power nets  opens
• Power nets shorts
• No of stripes
• Set to set distance
• Ring width
• Which metal layers are used for power route (For ring and stripes)
• Power hook up was done are not 
• Early rail analysis
• Electro migration and IR drop analysis only for power nets 

Floor plan cheeks

Sanity checks were done after that

• Utilization
• Aspect ratio
• IO clearance
• block size
• Area
• pin/port placement
• Macro placement
• offset value
• Macro orientation
• channel spacing between macros
• Placement blockages
• keep_out margin for macros

ICC commands frequently used at CTS stage

• get_clocks
• get_property [get_clocks clock_name] period
• get_property [get_clocks clock_name] uncertainty
• get_property [get_clocks clock_name] latency
• sizeof_collections [get_clocks]
• report_clock_tree
• report_clock_tree -exceptions
• report_clock_tree -level_info
• report_clock_tree -summary
• report_clock_tree -type latency
• report_clock_tree -local_skew
• get_utilization
• get_buffers  *CLK* 
• set_dont_touch [get_lib_cells */*DLY*] false
• set_dont_touch [get_lib_cells */*CLKBUF*] false
• set_dont_touch [get_lib_cells */*CLKINV*] false
• report_clock_tree_power
• report_clock_tree -interclock_timing
• report_clock_timing -type latency

Report_timing

 Report_timing Switches

• report_timing -late
• report_timing -early
• report_timing -from u123/y -to u124/b
• report_timing -from u123/y -through u124/b -to reg/D
• report_timing -path_type max -path_group r2r 
• report_timing -max_paths 50 -nworst 500
• report_timing -slack_lessor_than 0 -delay_type max
• report_timing -slack_greater_than 0 -delay_type min
• report_timing -format {cell arc instance slack startPoint endPoint}
• report_timing -collection [get_clocks clock_name]

Virtual clock

 Virtual clock 

• Virtual clock is a clock it is doesn't associated with any clock pin or Port of the design
• it will be used to validate the input to output timing paths
• It is reference to static timing analysis to validate the reg2out ,in2out paths or in2reg paths