0% found this document useful (0 votes)
113 views5 pages

AppNote Decap Handling in RedHawk-SC

The document discusses decap handling in RedHawk-SC dynamic analysis. It explains how decap contributions are modeled from various sources and stamped in simulations. It also provides methods to report decap statistics at both total design and per-instance levels, including breakdown of decap components and resistances.

Uploaded by

icmoneystars
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
113 views5 pages

AppNote Decap Handling in RedHawk-SC

The document discusses decap handling in RedHawk-SC dynamic analysis. It explains how decap contributions are modeled from various sources and stamped in simulations. It also provides methods to report decap statistics at both total design and per-instance levels, including breakdown of decap components and resistances.

Uploaded by

icmoneystars
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

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

© 2020 ANSYS Inc Page | 1


cap’. Mostly the SPEF file will be used to derive the ‘net cap’ and is passed to RedHawk-
SC through create_extract_view_from_files() view, if the SPEF-files are not available then
RedHawk-SC can extract the same. The receiver input cap will be computed using liberty
files.

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.

© 2020 ANSYS Inc Page | 2


To explain the decap stamping in better way, let us consider a buffer driving the load (Cload) with the
series resistance ‘Ron’ as shown in the figure 2.1. Where ‘Ron’ is the net parasitic resistance computed
from the ‘extraction view’. The first part of the figure represents the schematic view of the buffer.

VDD

Ron (Cload/2) * quiet_ratio

(Cload/2) * quiet_ratio = Load factor cap

GND

VDD

ESR Ron

ESC Load factor cap

GND

Figure 2.1 Schematic to circuit representation of decap stamping.

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.

© 2020 ANSYS Inc Page | 3


3. Decap Reporting
1. The total decaps statistics of the design which is used for the dynamic simulation can be reported
using following command:

>>> <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

© 2020 ANSYS Inc Page | 4


2. Per instance decap statistics can be obtained from following command. This command returns
the load capacitance and intrinsic cap of the instance along with their respective series resistances
which are stamped in the transient simulation for that instance.

>>> <AnalysisView>.get_attribute(<Instance object>)


Example:
>>> av.get_decap_stats(Instance(‘Xbuff1’))
Typical output looks like:
{'decap': {Pin('VDD'): {'driver_res': 1626.16,
'driver_total_cap': 2.014e-13,
'intrinsic_cap': 7.775e-15,
'intrinsic_res': 35.95},
Pin('VSS'): {'driver_res': 1626.16,
'driver_total_cap': 2.014e-13,
'intrinsic_cap': 9.129e-15,
'intrinsic_res': 77.03}}}

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

Figure 3.1 Printing decap attributes from the GUI

© 2020 ANSYS Inc Page | 5

You might also like