Subject: DC-WG: 6/13 meeting minutes
From: Mark Hahn (mhahn@cadence.com)
Date: Mon Jun 19 2000 - 14:39:12 PDT
Meeting minutes from the 6/13/00 DC-WG teleconference
-----------------------------------------------------
Attendees:
Mark Hahn, Cadence
Paul Bonnel, Cadence
Tom Dewey, Mentor
Bob Dilly, IBM
New action items:
Who When What
---------- ------ --------
1. Mark 6/20 Check on semantics for clock waveforms with
edges shifted by one or more cycles from equivalent
minimum edge times
2. Bob 6/20 Prepare waveform diagrams for waveform and
derived_waveform
3. Mark 6/20 Check on phase shift in derived_waveform
(effect on ideal edge position versus effective
edge position)
4. Mark 6/20 Check whether derived_waveform frequency adjustments
can be real numbers
Next Meeting:
The next meeting will be a teleconference on 6/20/00
from 10-12 am (PDT)
Details:
1. DAC reports
We didn't have much input from attendees yet. Tom will
follow up with Dennis Brophy and Kent Moffet, Bob with Karla Reynolds.
2. Review changes to waveform, derived_waveform
We discussed semantics for derived_edges and agreed that
since we're restricting clock waveforms to just two edges,
it is unnecessary to have a separate option for edge-specific
phase shifts. This is covered by the existing -phase_shift
option.
Mark raised several ambiguities and took action items to
clarify them.
3. Discuss clock_arrival_time, clock_required_time
We talked about terminology distinctions between
- assertions
- constraints
- directives
- annotations
Tom agreed to expand the Basic Terminalogy section to
define these. clock_required_time is a constraint, while
clock_arrival_time is an assertion; otherwise they are very
similar.
We discussed whether it should be an error for clock_required_time
to be specified on a port or pin that isn't reachable from a clock
root. In general, this must be the case, or it isn't possible to
compute whether the constraint is satisfied.
Mark raised concerns about the current spec's coverage of
modes and case analysis issues, and how that affects what should be
treated as an error. If the regular clock and test clock are muxed
together, and in the functional_mode currently in effect only the
test clock is enabled (through setting constants), then the
clock_required_time may not appear to be downstream of a clock, even
though it is downstream of the regular clock in a different mode.
The general solution to this is to support specifying all possible
modes in DCDL and have tools analyze and optimize with respect to all
of the modes simultaneously. However, this isn't supported by most
tools today.
One way to support specifying all modes in DCDL is to modify
the functional_mode command to have file scoping semantics.
If one or more functional_mode commands are given, then each
command would delimit a portion of the DCDL file for which all
constraint commands affect just the most recently defined mode.
Any constraint commands appearing before the first functional_mode
command would apply to the default mode. We agreed this was a cleaner
approach than adding a -mode option to each command, but stopped
short of committing to include this semantics in DCDL.
Thanks,
Mark
-- Mark Hahn phone: (408) 428-5399 Senior Architect fax: (408) 894-3479 Cadence Design Systems email: mhahn@cadence.com
This archive was generated by hypermail 2b28 : Mon Jun 19 2000 - 14:46:01 PDT