In PDEF, there is a notion of a power domain, where each power
domain has a unique name, which can be specified as attributes
or through explicit constructs on pins, nodes, nets, clusters, cells,
and spare cells.
"A power domain is the portion of an integrated circuit powered
by a particular power supply and power buses. It is common design
practice to isolate power domains for analog circuitry from digital,
IO pad cells from core cells, etc. Different domains may be of the
same or different supply voltages."
I don't think adopting the term "domain" in the PDEF sense for DCDL
is a good idea, because it will cause too much confusion with the
existing usage for distinguishing between different classes of
constraints. Instead, I suggest the term "regime".
In the Cadence place & route tools, the physical power structure is
inferred from a combination of attributes on pins from the physical
library and user-specified names for power nets. Multiple voltage
islands that use the same physical cell types aren't supported.
I think that the following proposal is a superset of Jim Engel's,
although the information is organized quite differently.
Proposal:
---------
power_regime
?-name "string"?
?-logical_rail "string"?
?-physical_rail "string"?
?-base_voltage double?
?-min_voltage min_limit?
?-max_voltage max_limit?
?-cell { cell_name ... }?
?-instance { instance_name ... }?
?-port { port_name ... }?
?-pin { pin_name ... }?
-logical_rail gives the OLA rail name
-physical_rail would usually given the physical net name, but
the physical design system might map the physical rail name into
several physical nets (particularly when the physical design
is done hierarchically).
-base_voltage can be specified if the library doesn't describe
power rails. It may be synonymous with -typ in operating_voltage,
but I'm not sure. The question is whether we need to distinguish
between the intended base voltage and the typical voltage actually
distributed to each primitive under the current operating assumptions.
I think we probably do.
-min_voltage and -max_voltage give the design-specific limits across
all calculation modes, corresponding to (and lying within) the library
limits given by dpcmGetRailVoltageRange.
-cell gives cell types that should be analyzed using the
logical rail and connected to the physical rail. Usually
this would be inferred, but might be necessary for libraries
without power pin information.
-instance gives particular instances that should be analyzed
using the logical rail and connected to the physical rail.
If the instance is of a hierarchical cell, it applies to
entire hierarchy under that instance, unless overridden by
a lower level instance.
-port is used with -cell to distinguish between several power ports
on the same cell (which will be common for large IP blocks).
-pin is used for the same reason, instead of -cell or -instance.
If neither -cell or -instance is specified, the regime applies to
the current instance. Multiple power_regime commands are additive.
temperature_regime
?-name "string"?
?-cell { cell_name ... }?
?-instance { instance_name ... }?
/* options to select a physical area are probably more appropriate */
A temperature regime corresponds to a portion of the chip, within
which temperature variations are assumed to be correlated.
operating_range
?-library library_name?
?-name "string"?
Specifies a default range of operating conditions (process,
voltage, and temperature) that should be assumed for the design
or the portion of the design that is implemented using a particular
library. Overridden by operating_voltage, operating_voltage,
and operating_process.
The operating range is intended to model different library
characterizations such as military versus commercial, and
it corresponds to appGetCurrentOpRange() in P1481/OLA.
operating_variation
?-correlated?
?-uncorrelated?
Operating variation specifies whether early and late delays
and slews should be computed assuming that variations in process,
voltage, and temperature are correlated (on-chip) or uncorrelated
(between chips).
The interpretation of min, typ, and max values specified with
operating_process, operating_voltage, and operating_temperature
depends on operating_variation.
- For correlated variation, min and max values for voltage and
temperature represent the largest on-chip difference that should
be assumed within a power or temperature regime. Min and max
values cannot be specified for process under correlated variation.
Typical values aren't very useful in this case, but might need to
be allowed for SDF generation.
- For uncorrelated variation, min, typ, and max values for process,
voltage, and temperature represent best-case, nominal, and worst-case
analysis points for different chip samples.
operating_variation corresponds to the OLA DCM_ProcessVariations
enum. The application would set the PROCESS_VARIATION field in the
standard structure to DCM_MinEarly_MaxLate for correlated variation,
and to DCM_NoVariation for uncorrelated variation. I don't understand
why an application would ever choose DCM_MaxEarly_MinLate, so hopefully
Archie or Jay can explain this.
operating_process
?-min | -typ | -max?
?-value double?
?-library library_name?
?-operating_point "string"?
Specifies the process point(s) to be used. The process
points can be
- specified explicitly as a floating point number using -value,
or
- selected using -operating_point, which refers to the process
point associated with a particular operating point defined in
a library
or
- selected using -min, -typ, or -max alone, which refer to the
default best-case, nominal, and worst-case process points defined
in a library. These correspond to the points chosen by setting
the CALC_MODE in P1481.
When operating_variation is uncorrelated, three process points
can be specified using multiple operating_process statements,
each of which specifies -min, -typ, or -max, and each of which
may specify -value or -operating_point. Alternatively, a single
process point can be specified by omitting -min, -typ, and -max.
When operating_variation is correlated, only one process point
can be specified. -min, -typ, and -max cannot be used with -value
or -operating_point in this case, but one of them may be used alone.
operating_voltage
?-power_regime "string"?
?-min | -typ | -max?
?-value voltage?
?-library library_name?
?-operating_point "string"?
/* might want -instance and -pin here for annotated values */
Specifies the voltage values to be used for the given power regime,
which can be
- specified explicitly using -value,
or
- selected using -operating_point, which refers to the rail voltage
associated with a particular operating point defined in a library
Three different values can be specified when operating_variation
is uncorrelated. These correspond to the best-case, nominal,
and worst-case analysis assumptions.
Three different values can be specified when operating_variation is
correlated. These correspond to the minimum, maximum, and typical
voltages expected throughout the power distribution network for the
power regime on a single chip in a particular environment, where
the range of voltages is due to IR drop.
operating_temperature
?-temperature_regime "string"?
?-min | -typ | -max?
?-value temperature?
?-library library_name?
?-operating_point "string"?
/* might want -instance here for annotated values */
Specifies the temperature values to be used for the given temperature
regime, which can be
- specified explicitly using -value,
or
- selected using -operating_point, which refers to the temperature
associated with a particular operating point defined in a library
Three different values can be specified when operating_variation
is uncorrelated. These correspond to the best-case, nominal,
and worst-case analysis assumptions across different chips and
environments.
Three different values can be specified when operating_variation is
correlated. These correspond to the effective minimum, maximum, and
typical ambient temperatures expected within the temperature regime on
a single chip in a particular environment, where the range of temperatures
is due to localized self-heating.
/* We might also want to model on-chip temperature variation more
directly through junction temperatures. ASIC libraries wouldn't
support this, but it could be valuable for Spice analysis.
Comments? */
Mark
-- Mark Hahn phone: (408) 428-5399 Senior Architect fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com