AppNote Decap Handling in RedHawk-SC
AppNote Decap Handling in RedHawk-SC
Version: 2020.03.29
Table of Contents
1. Introduction........................................................................................................................................... 1
2. Decap stamping ..................................................................................................................................... 1
3. Decap reporting in RedHawk-SC........................................................................................................... 2
1. Introduction
Considering the impact of decoupling capacitance is very important in dynamic analysis as it has a
significant impact on the final dynamic voltage drop of leaf instances. The decap contribution in dynamic
simulation can come from various sources like PG or signal wire caps, intrinsic cell caps or intentional
decoupling capacitor cells. Decaps help in improving the dynamic voltage drop on the neighboring
switching instances, by augmenting the instantaneous current demand. Hence it improves the local
dynamic voltage drop. Also, it is important to model on-chip capacitance accurately for system-level
analysis, i.e. CPM (Chip power model) generation.
2. Decap stamping
Broadly, we can classify DIE capacitances are used in the dynamic simulation and CPM generation into
two types, they are:
1. PG grid capacitance: Wire capacitance extracted from the PG grid.
2. Capacitance contributed from leaf level instances: Again, this can be classified into 3 groups:
a. Intentional device capacitance: This capacitance is contributed by on-chip intentional
decap devices. These are provided in APL Cdev (.cdev) format to RedHawk-SC.
b. Intrinsic/Device capacitance of functional instances: This is the capacitance contributed
by internal nodes of the functional instances. APL Cdev models will have intrinsic
capacitance (ESC) information, which is passed to RedHawk-SC through liberty-view.
c. Load Capacitance connected to the output pin of the instance: In CMOS based designs,
when instance is not switching, load will be directly connected to Power/ground pin
through ‘Ron’ resistance and this acts like a decap for other neighboring switching
instances. Total ‘load-cap’ is equal to sum of ‘net-cap’ and the ‘receiver instance input pin
This app-note will explain how the device/load caps are stamped in dynamic simulation in RedHawk-SC.
For intentional decap instances, their intrinsic cap will be always connected to grid are replaced with series
ESC and ESR network during the simulation. The functional cells consume the current only when they are
switching. For the rest of the time they act as decoupling capacitances. The intrinsic cap of these non-
switching instances will be connected to the grid through effective series resistance (ESR). RedHawk-SC
uses the methodology described below for stamping the load capacitance.
RedHawk-SC assumes load capacitances are coupled 50% to power and 50% to ground during the
transient analysis, hence the factor of load cap is stamped to VDD and GND nets and it is computed using
a following formula:
quiet_ratio = 1 – (total_transition_time/total_time)
Load_factor_cap = (Cload/2) * quiet_ratio
Here, ‘total_transition_time’ is the time during simulation that the instance is transitioning from 0→1 and
1→0 and is computed using slew and load of that instance.
VDD
GND
VDD
ESR Ron
GND
And second part shows the circuit representation of the same which goes to the transient analysis. Here,
the intrinsic cap ESC (Effective Series Capacitance) is connected to the grid through ESR (Effective Series
Resistance) and this circuit is in parallel with the load cap factor which is connected to the grid through
series ‘Ron’ resistance.
>>> <AnalysisView>.get_decap_stats()
Example:
>>> av.get_decap_stats()
Typical output looks like:
{'VDD': {'num_instances': 1000,
'num_instances_with_decap': 999,
'total_decap': 6.493843344540603e-08,
'total_intrinsic_cap': 7.987977807451808e-08,
'total_pg_route_cap': 1.898468582339774e-08,
'total_pin_load_cap': 3.1149608088928624e-08,
'total_signal_load_cap': 9.220013386564688e-08},
'GND': {'num_instances': 1000,
'num_instances_with_decap': 999,
'total_decap': 6.493843344540603e-08,
'total_intrinsic_cap': 7.987977807451808e-08,
'total_pg_route_cap': 1.898468582339774e-08,
'total_pin_load_cap': 3.1149608088928624e-08,
'total_signal_load_cap': 9.220013386564688e-08},
'total': {'average_instance_coverage': 0.999149583838286,
'cdie': 1.489970840253679e-07,
'total_decap': 3.151667488160064e-08,
'total_intrinsic_cap': 4.315952683403479e-08,
'total_pg_route_cap': 8.746573199152142e-09,
'total_pin_load_cap': 1.6263880521223528e-08,
'total_signal_load_cap': 4.93104285893568e-08}}
This command also returns the decap statistics per domain basis. It also reports the total decap
statistics with different components break-down. In the above output,
‘total_load_cap’ is sum of ‘total_pin_load_cap’ (This represents receiver pin caps) and
‘total_signal_load_cap’ (This represents the only signal routing capacitance).
‘total_decap’: the intentional decap’s cap contribution.
‘total_intrinsic_cap’: Intrinsic cap of other functional instances.
‘cdie’ represents total on-chip capacitance (at low frequency, almost at DC point).
‘cdie’ = ‘total_decap’ + ‘total_intrinsic_cap’ + ‘total_pg_route_cap’ + ‘total_pin_load_cap’ +
‘total_signal_load_cap’;
The final ‘total’ values of the decap represents the effective decap between
Same information we can also get from the GUI as well, by selecting instance and right click on
the selected instance then click on Print attribute and select ‘decap’ under ‘AnalysisView’ section
which will print the decap stats as shown in figure 3.1