Subject: DC-WG: 2/22 meeting minutes
From: Mark Hahn (mhahn@cadence.com)
Date: Mon Feb 28 2000 - 12:08:54 PST
Meeting minutes from the 2/22/00 DC-WG teleconference
-----------------------------------------------------
Attendees:
Mark Hahn, Cadence
Tom Dewey, Mentor
Bob Dilly, IBM
John Paul, IBM
Vikas Sharma, IBM
New action items:
Who When What
---------- ------ --------
1. Tom 2/29 Update the spec with changes
2. Mark 2/29 Talk with Lynn Horobin about OVI
booth space at DAC
3. Bob 2/29 Test behavior of relative includes
(source) in TCL, along with handling
of embedded spaces in the file name
for PC compatibility
Next Meeting:
The next meeting will be a teleconference on 2/29/00
from 9-11 am (PDT)
Details:
1. Review status of golden parser
John Paul is almost ready to ship an updated version of
the parser. The header comments will roughly reflect the
desired state for how it will be licensed. Keeping these
header comments will probably be sufficient; we won't need
tools that use the parser to display an IBM copyright notice.
Bob convinced the IBM lawyers that the open source license
for the Jikes compiler is a good precedent, and that the parser
itself won't contain any IBM intellectual property. It will
probably take 8-10 weeks to go through the legal process.
2. DAC planning
We talked a lot about what worked for DAC '99 and what didn't.
Everyone agreed that although proving that DCDL works through
a complete flow is valuable, actually demonstrating the entire
flow took too long and was too repetitive.
We agreed that it makes sense to spend more time with the first
tool in the flow, showing what the constraints look like in
DCDL and how they're interpreted by the tool. The complete
flow would be covered separately in material (a custom CD?)
distributed at the show or downloadable from the web site.
We agreed that getting both FPGA and ASIC flows to work again
is important, as is translation to and from Synopsys SDCs. We
still need to choose a design; the January issue of ISD Magazine
has an article where they used the PicoJava design.
3. Review include command
We talked a lot about the include command and whether we
want DCDL to have a distinct command or simply emulate the
command name and behavior of the TCL source command. The
main issues are in error handling, interpretation of relative
file names, and handling of special characters in the file
name.
We agreed that the DCDL standard should be clear in certain
cases on what constitutes an error versus a warning, but that
DCDL should not specify the tool behavior in response to an
error. Some tools may choose to take a compiler-like approach,
trying to continue parsing the DCDL file to find as many errors
as possible in one shot, while others may want to ensure that
no invalid constraints are applied to the design.
It's desirable to interpret relative file names with respect to
the directory containing the DCDL file that is doing the include/
source, not with respect to the current working directory of the
tool. This simplifies copying groups of constraint files. We
weren't sure which way the TCL source command worked.
In a TCL script, special characters probably can be used in a
sourced file name using either double quotes or curly braces.
But normal file names wouldn't require quoting. In DCDL we
need to be precise on whether quoting is allowed or required,
and what to say about variable expansion if it's allowed.
3. Review design_name_space command
We agreed that we don't need the -keywords option, since
DCDL will have well-defined positions in which design object
names or lists of design objects can appear.
We talked about differences between VHDL 88 and 93, and agreed
to have a -version option that takes a string. Having a string
instead of a keyword reduces synchronization problems between
the DCDL standard and other standards.
There is a problem with the -escape option, which doesn't
currently support SDF style character-by-character escaping.
There is a related problem with the use of the backslash
character in the -escape option string; when this string is
handled first by a TCL interpreter, the interpreter will
expect two backslashes instead of one.
We agreed that the design_name_space command should be
scoped with respect to the DCDL file, not with respect to
the design hierarchy. This raised the question of whether
defining a design_name_space within an included file would
affect the design_name_space used for subsequent commands in
the parent file. On the one hand, this is undesirable for
cases where the include files mirror the design hierarchy;
on the other hand, it's desirable for cases where you want
to put just the design_name_space definition in a small
include file and then reuse it multiple times. This is
very similar to the distinction between sourcing a C shell
script and invoking it. We talked about adding an option
to the include/source command to allow both.
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 Feb 28 2000 - 12:12:26 PST