Mark
----
The behavior of complex blocks in a design will often be
highly state-dependent. For example, the internal operations
performed by microprocessors and DSP cores can be radically
different depending on the instructions they execute. Even
a simple RAM will have different behavior depending on whether
data is being read or written.
This state-dependence affects not only the functional behavior
of the block, but also its timing. Traditionally, the timing of
primitives has been modeled as if the primitive were a black box,
with combinational delay arcs from inputs to outputs, and timing
check arcs relating data inputs to clock inputs.
In some cases such as XORs, the combinational delays were sensitive
enough to the logic values on the input pins that people created a
separate description of the delay for different input combinations.
In other cases, such as tri-state buffers and level-sensitive latches,
the state of one of the inputs controls whether a transition on an
input will propagate through to an output, effectively enabling or
disabling certain timing arcs associated with the input. A simple
extension is to model blocks as having some internal state variables
which affect the timing, as well as the logic values on the input pins.
In general, state-dependent modeling is robust, but it suffers from
a potential explosion in the number of states. Since each state
is identified through a set of logic values on input pins or internal
state variables, it is relatively hard for a user to understand and
what the states of the block are and how the states affect the timing.
When doing simulation, this isn't generally an issue, because the
simulator will take care of assessing what the current state of the
block is and modeling the timing behavior accordingly.
However, for static timing analysis the user is much more likely
to have to specify something about the relevant states of the block.
The reason for this is that there will generally be a number of complex
blocks in a large design, each with a number of states. Since these
blocks interact with each other through various protocols, it is likely
that the protocols will make it impossible for certain combinations
of states across all of the blocks to ever occur. In simulation,
those combinations are never exercised, but in most static timing
analysis tools there aren't currently ways to automatically determine
which combinations of states are valid and which are not. Not taking
these combinations into account would make the timing analysis excessively
pessimistic.
This leaves it up to the user to specify which combinations of states
should be analyzed. Doing so in terms of the logic values and internal
states for every block would be very cumbersome and error prone. Modes
are a way to simplify this process, although they don't help to resolve
the state-space explosion. The idea is to assign a mnemonic label (the
"component mode") to each of the states of a block, then use that label
when specifying valid combinations of states involving several blocks.
Each combination of states can have a label as well (a "design mode",
so that it is possible to define all of the combinations up front, then
do analysis for a particular combination by simply setting a current
design mode.
Specifying the combinations of states is a basic type of constraint
capability, as is setting the current combination. In addition to
these, it is useful to recognize that each design mode corresponds
to a particular way in which the protocols in the design are being
exercised. This can lead to many other kinds of mode-dependent
constraints, where the common theme is that constraints and/or
environment conditions can be specified more precisely or tightly
for a given mode than across all modes as a worst case. The simplest
case is in setting the control signals which select a mode to constant
values. In addition to ensuring consistency with the modes of the
complex blocks, setting constant values can reduce pessimism in delay
calculation when there are state-dependent delays in primitives.
-- Mark Hahn phone: (408) 428-5399 Architect, Deep Submicron Business Unit fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com