The typ entry is somewhat ill-defined, due to slew merging
issues. For the min and max entries, it is possible to select
the worst case slews reaching a pin and use those to calculate
the delay values. For the typical entry it isn't as clear which
slew should be used, and some timing engines do not even propagate
a typical slew.
These problems are compounded by correlated and uncorrelated
variation due to operating conditions. When analysis is done at
a single operating point, variation in delays is due solely to
slew merging effects, assuming that a single value is used for
each environment condition (input slews and output loads).
When analysis is done for correlated (intra-die) variation, the min
and max slews and delays should be co-mingled (the max delay should
be computed as the worst case resulting from either the min slew or
the max slew). When delay is monotonically decreasing as a function
of slew, the min slew will yield a larger delay value.
When analysis is done for uncorrelated variation, the min and max
slews and delays should not be co-mingled (the max delay should be
computed strictly from the max slew).
Often designers want to do analysis at a "typical" operating point,
which is the intent of the typ entry in SDF. This suggests that we
should support specifying a typical value for all of the environment
conditions.
However, doing so would lead to the question of how slew merging should
be done. One approach requires a separate slot for typical delays and
slews. The typical values specified for environment conditions are used
directly in doing delay calculation on interface nets. During propagation,
at each pin the average of the typical slews reaching the pin is taken.
Another approach that can be used when doing analysis of correlated
variation is to take the average of the min and max slews. This approach
doesn't require an additional slot, but it also doesn't reflect the
typical values specified for the environment conditions on the boundary.
It can't be used when doing analysis of uncorrelated variation, because
taking the average of uncorrelated slews isn't physically meaningful.
In summary, for some tools including typical values for environment
conditions in DCDL is appropriate and provides backwards compatibility
in generating SDF with typical values. For other tools, supporting
typical values in DCDL for SDF generation would require fundamental
changes.
Proposal:
- Include typical values in DCDL
- Document the semantics associated with typical values and their
use in generating SDF
- Allow tools to be DCDL-compliant if they read DCDL containing
typical values but ignore those values in generating SDF without
typical entries
Thanks,
Mark
-- Mark Hahn phone: (408) 428-5399 Senior Architect fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com