Subject: DC-WG: 1/25 meeting minutes
From: Mark Hahn (mhahn@cadence.com)
Date: Mon Jan 31 2000 - 16:15:43 PST
Meeting minutes from the 1/25/00 DC-WG teleconference
-----------------------------------------------------
Attendees:
Mark Hahn, Cadence
Joe Daniels, SEVA
Tom Dewey, Mentor
Bob Dilly, IBM
Jim Engel, IBM
Vassilios Gerousis, Infineon
Kent Moffet, Mentor
John Paul, IBM
New action items:
Who When What
---------- ------ --------
1. Bob 2/1 Work on terms of availability for the
golden DCDL parser
Open action items:
Who When What
---------- ------ --------
1. Mark 11/30 Investigate issue tracking mechanisms for
-> 12/28 the web site
-> 2/15
Closed action items:
Who When What
---------- ------ --------
1. Vikas 11/9 Review derived_waveform and derived_clock
-> 11/30 commands, try to convert Einstimer example
to them
2. Tom 11/30 Complete updates to 0.1.4 spec from review
Next Meeting:
The next meeting will be a teleconference on 2/1/00
from 9-11 am (PDT)
Details:
1. IEEE standardization
We had a lengthy discussion about when it would be
appropriate to start the IEEE standardization process,
initiated by concerns from IBM about possible delays in
support until it reaches IEEE.
The conclusion was that we should
- Focus on defining the basic language constructs and
the syntax for all of the commands in the timing domain,
with limited description of the semantics.
This will form the basis for OVI version 1.0
- Work on defining the syntax and limited semantics for
the power and signal integrity domains
This will form the basis for OVI version 1.1
- While completing OVI version 1.1, start the study
group for the IEEE PAR
- Submit the IEEE PAR around the same time as OVI
version 1.1 is released.
- Complete the semantics for the timing, power, and
signal integrity domains for IEEE version 1.0.
2. Golden parser
We debated various ways to make the IBM parser available
for others, while IBM continues to maintain it. Open
source and community source licensing approaches are
a possibility, which Bob will pursue with IBM legal.
If either of those approaches is adopted, we can make the
parser available on the web site.
A less attractive option would be for IBM to donate the
source code, but who to donate it to is unclear. OVI doesn't
want to support software at all, while SI2 is likely to want
to charge for support.
3. Press release
Kent will be pushing the press release forward, which has been
stalled for some time. He suggested that the content should
include information about the state of the draft spec, the
parser availability (assuming this is resolved), and key endorsements
from additional EDA companies (Avant!, Magama, Monterey),
system houses (Sun), ASIC vendors (IBM), and standards
organizations (VSI, OVI, the ASIC Council).
We also talked about bundling a design, the constraint description,
and the reference parser as part of a complete methodology for
DCDL support. The Sun PicoJava core was mentioned as one possible
choice for the design, since it is publicly available.
4. Physical and analog constraints
Mark gave a high level overview of the current status within
Cadence on planning for support of these constraint domains.
Some discussions have occurred, but the timeframe for actual
work starting hasn't been settled yet.
5. Continuation characters in DCDL comments
We agreed to follow the TCL convention that a continuation
character at the end of a comment line causes the next line
to be interpreted as part of the comment.
6. Unset and reset
We discussed whether these options are really necessary,
particularly since they don't fit well with the general
position that DCDL is declarative rather than executable
in nature.
Mark offered two arguments to support including them
- Unset and reset are needed to remove the effect of general
constraints from specific design objects.
For example, a general multi-cycle constraint might be specified
for all paths between clock1 and clock2. If a particular
pair of registers driven by clock1 and clock2 should transfer
data in a single cycle, the -unset or -reset option is required
to restore the default semantics for that pair.
If we don't provide the -unset or -reset option, then in
every case where a command can change the default semantics,
we need to provide a corresponding command to restore the
default semantics.
- In most tools that provide a TCL scripting environment around
DCDL, the ability to undo a command will be expected. If DCDL
doesn't provide a standard way to do this, each tool will provide
its own way, reducing interoperability even though a general
undo capability is obviously not required for simply declaring
constraints.
7. Inheritance
Mark raised two problems with including support for hierarchical
inheritance in DCDL:
- Most tools that process constraints today don't support
inheritance
- When a design is flattened, usually the relationship between
primitives in the flat design and the hierarchy they came from
is lost. Although the constraints theoreticallly can be flattened
at the same time as the design, it becomes ambiguous which set of
constraints should apply to new logic added later. There are
similar issues with any other type of hierarchy manipulation,
such as physical partitioning and dissolving hierarchy boundaries.
Thanks,
Mark
-- Mark Hahn phone: (408) 428-5399 Senior Architect fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com
This archive was generated by hypermail 2b28 : Mon Jan 31 2000 - 16:18:07 PST