Attendees:
Mark Hahn, Cadence
Tom Dewey, Mentor
Bob Dilly, IBM
Jim Engel, IBM
Kerim Kalafala, IBM
Vikas Sharma, IBM
New action items:
Who When What
---------- ------ --------
1. Mark 11/9 Send the GCF 1.4 spec to Bob and Tom
2. All 11/9 Review pages 19-21, 25-32 in the spec
3. Vikas 11/9 Review derived_waveform and derived_clock
Open action items:
Who When What
---------- ------ --------
1. Mark 7/27 Prepare Microsoft Project schedule for the
-> 11/9 second half of '99.
2. Tom 10/12 Try to get permission to use diagrams from the
Velocity documentation
Closed action items:
Who When What
---------- ------ --------
1. Tom 10/12 Prepare skeleton for the DCDL spec
-> 10/15
2. Mark 10/26 Revise the operating conditions proposal
Next Meeting:
The next meeting will be a teleconference on 10/26
from 9-11 am (PDT).
Details:
1. Review action items
Tom completed the "skeleton" document, far exceeding
everyone's expectations! It's a terrific start that goes
well beyond just being a skeleton to be a strong basis for
completing the spec quickly. It's now available on the web
site.
2. Discuss skeleton document
We talked about several general language issues and agreed that
- Positional parameters should be allowed anywhere in the argument
list (before, after, or in the midst of the -keyword <value> options).
- Besides the command names themselves, DCDL doesn't need to define
any reserved words. Collisions between DCDL command names and other
existing commands in an application can be handled in several ways,
and there is a placeholder section in the spec which will be
elaborated to describe the approaches.
- Abbreviations for commands and arguments will not be part of DCDL
itself. TCL automatically handles command abbreviations, so
users can choose to enter their constraints using abbreviations,
but this makes the constraint script application-specific, not true
DCDL. Reading the same script in a different tool may cause the
abbreviations to be expanded differently, to application-specific
commands instead of DCDL commands. Therefore, applications that
write out DCDL must not use abbreviations.
Tom agreed to own updates to the spec for the time being. We agreed
to use change bars to reflect differences between consecutive revisions.
If it's necessary to look at differences across multiple revisions,
we can use the Frame diff capability. [Ed. note: we can also use
a tool called psdiff which compares two Postscript files and outputs
a third Postscript file with the changes highlighted.]
3. Discuss updated operating conditions proposal
Mark sent an updated proposal for operating conditions
to the reflector. We discussed this briefly and tentatively
agreed that with the new approach for specifying -min_best,
-max_best, -min_worst, -max_worst, etc., explicitly specifying
whether the operating variation is correlated or uncorrelated
is no longer required. Therefore, the operating_variation
command should be dropped.
4. Discuss user defined tests for asynchronous interfaces
Vikas had sent a description of user defined tests to the
reflector. The basic idea is to specify additional setup
and hold-like checks between arbitrary pins selected by the
user. We didn't discuss this in detail, but in principle
we agreed that it would be a reasonable thing to add to DCDL.
5. Discuss derived clocks
Vikas had sent a description of phase/clock renames and
adjust signals, which are IBM terminology for commands that
seem to have the same intent as what we've been calling
derived waveforms and clocks in DCDL.
We talked about this enough to agree that it's the same
type of thing, but not enough to be sure that the capabilities
of the DCDL commands satisfy all of the IBM requirements.
Vikas will review the existing derived_waveform and derived_clock
commands in the draft, and Tom will look at the GCF 1.4 spec,
which includes some additional semantics relevant to derived_waveform.
Thanks,
Mark
-- Mark Hahn phone: (408) 428-5399 Senior Architect fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com