Attendees:
Mark Hahn, Cadence (Chair)
Tom Dewey, Mentor Graphics
Steve Grouts, Sematech
Enrico Malavasi, Cadence
Dan Moritz, LSI Logic
Greg Schulte, Ambit
Jim Swift, IBM
New action items:
Who When What
---------- ------ --------
1. Jim 9/15 Investigate IBM strawman possibility
2. Greg 9/15 Add description of min/max delay constraints,
boundary conditions specified on internal pins
to taxonomy
Open action items:
Who When What
---------- ------ --------
1. Jin, Jim 8/25 Discuss PVT-dependent constraints and relationship
to conceptual model
-> Need to reassign
Completed action items:
Who When What
---------- ------ --------
1. Greg 6/22 Write up an extended description of how tags work
-> 8/4
-> 8/18
-> 8/25
2. Jim 6/22 Write up an extended description of how operating
-> 7/21 conditions work
-> 8/4
-> 8/18
-> 8/25
3. Mark 8/18 Merge the taxonomy documents
-> 8/25
4. Steve 8/25 Update the parasitics boundary conditions
Next Meeting:
The next meeting will be a teleconference on
Tuesday, 9/15/98, from 9-11 am PST.
Details:
1. New items
Jin-sheng Shyr has taken a new job in a different company,
and as a result he will be unable to continue participating
in DC-WG. Any volunteers to take on the Co-Chair position
will be welcomed.
Jim Swift indicated that there may be a possibility that
IBM would be willing to provide the constraint commands for
Einstimer as a second strawman. He will follow up with other
people within IBM.
2. Review timing boundary conditions section in the taxonomy document
Since Jin-sheng was unable to attend, we made some guesses about
what he intended in his description.
For arrival times, we agreed that
- There should be an option to control whether the values specified
for the arrival time are to be interpreted as an offset from the
implicit reference point in time, or as an offset from the related
clock edge (which itself has an offset from the implicit reference
point).
- The rise-time-range and fall-time-range should be split into the
four individual values, to allow each of the values to be specified
or not specified independently.
- The description should account for tags
In discussing this, we agreed that several other things are missing in
other areas:
- The relationship between base and derived clocks
- Specification of units for values. For slew, we agreed that we
should follow the OLA definitions, because there has been a lot of
recent debate about the relative merits of slew as time, dv/dt,
or dt/dv.
- Voltage thresholds. Dan mentioned that LSI sees a need for specifying
separate thresholds for rise and for fall. There may be different
thresholds for each voltage used in the design, and we need to
decide whether the values represent absolute voltage values or
percentages.
For required times, we agreed that corresponding changes should be
made as for arrival times.
For both arrival and required times, we agreed that it should be possible
to phrase the constraints either from an internal view or an external
view. The external view is the traditional approach, where the arrival
time and required time values directly represent delays in the
environment
around a block. The internal view is isomorphic, mapping the effect of
delays in the environment around a block into the effect on the delays
within the block. The internal view is useful for budgeting and because
it allows the constraints on the block to be directly transformed into
a timing model for the block, where the timing model reflects the worst
case delays which are allowed. Ambit provides both internal and external
views of when transitions must occur at an output pin, but only the
external
view of when transitions will occur at an input pin.
For external delays, it wasn't clear whether the semantics were intended
to correspond to GCF or Ambit. In the GCF semantics, external delays are
used as offsets to min/max combinational delay constraints. In the Ambit
semantics, external delay refers to the external view of when transitions
must occur at an output pin. We agreed that
- The ability to specify offsets to min/max combinational delay
constraints
is required.
- These offsets should not be related to a waveform.
- They should be allowed on ports and internal pins, and on both
inputs and outputs.
For driver specifications on input ports, we agreed that they
need to be tag-specific. We also discussed the question of
whether this information should be included in the timing boundary
conditions. In particular for soft and firm IP blocks, there is a
concern that specifying boundary conditions like this in the IP block
deliverables is inappropriate, because they describe characteristic of
particular instantiations of the block across different designs, not
characteristics common to all instantiations. We debated this at length,
and several points were made:
- Boundary conditions like driver specifications are required for
delay calculation and timing analysis on a particular block in
isolation
- The boundary conditions should not be included in the IP block
deliverables. Instead, the specification of the boundary conditions
should be deferred until the context for a particular instantiation
of the block is known.
- The constraints common to all instances of a block may need to
be a function of parameters determined from the actual environment for
a particular instance. However, allowing constraints to be phrased in
terms of general functions like this would greatly increase the overall
complexity of the standard. We talked about the common constraints as
"fixed", and instance-specific constraints as "variable".
We talked about several additional topics which should be included in
the conceptual model, including
- What happens to hierarchical constraints when the design is flattened,
particularly those specified relative to hierarchical module ports.
- Coalescing constraints from multiple instances of a block into one or
more sets, where each set is suitable to drive the implementation of
a master associated with several similar instances.
- Deferred versus bundled constraints for IP blocks
We also agreed that we need to make progress on the glossary within
the taxonomy, to clarify the definitions of assertions, constraints, and
boundary conditions.
Finally, we thought that description of the use model for each constraint
should be included in the detailed semantics description.
3. Review Greg's extended description of how tags work
The example helped illustrate the use of tags, but a more formal
specification is needed. We talked about several extensions to the
concept, including
- When tags overlap in their effect, there needs to be a description of
the behavior (which takes precedence?)
- Conditional tags would be useful, where at some intermediate point
in the circuit a second tag would start propagating if a first tag
arrived at that point.
- Symmetrical tags would be useful to complete the internal and external
views of the arrival/required time constraints. The current form of
tags is based on forward propagation; corresponding capabilities based
on reverse propagation could be valuable.
4. Review Jim's extended description of how operating conditions work
Jim went over part of his document. Most of the discussion was on
the relationship between the K factors used for PVT derating and the
environment specifications in constraints.
We talked about there being three different types of information:
- User-specified process, voltage, and temperature values to be
used in analysis and optimization. These are the environment
specifications.
- The derating functions (K factors) included in libraries. These
are functions which convert the user-specified process, voltage, and
temperature values into multipliers which adjust the nominal delay
and power values to reflect the effect of the environment conditions
being better or worse than the nominal environment conditions for which
the library was characterized.
- Constraints on allowable derating functions, for library developers.
The idea here is that a library developer has to ensure that all of the
cells in the library will provide reasonable performance over a range
of environment conditions. These constraints would mostly be useful
for structured custom design methodologies.
We agreed that the third type is not within the DC-WG scope. The user
specifications have to be part of the constraint description language,
and the relationship between the user specifications and the library
derating functions needs to be part of the conceptual model.
We also discussed voltage-sensitive constraints as a special case of
environment-dependent constraints. The concern here is that there may
be different constraints which apply to 3 volt and 5 volt implementations
of an IP block. We talked about whether to model this in terms of
discrete
sets of constraints for each target voltage, or in terms of
constraints which
are phrased as a function of voltage. There were some concerns about the
latter approach, where it might be possible for a user to define a
constraint
function which isn't monotonic across the target voltage range; this
would
cause problems for optimization tools.
We didn't have time to get to the remaining items, including
5. Review Jin-sheng and Enrico's revisions to the conceptual model
6. Discuss schedule
7. Plan future face-to-face meetings (ICCAD, ...)
Thanks,
Mark