Attendees:
Mark Hahn, Cadence (Chair)
Tom Dewey, Mentor
Bob Dilly, IBM
Jeff Handong, Cadence
Ed Martinage, Cadence
Greg Schulte, Cadence
Vikas Sharma, IBM
New action items:
Who When What
---------- ------ --------
1. Vikas 5/11 Send a description of the Einstimer cmds
for operating conditions
2. Mark 5/11 Close on whether it is possible for Cadence
to make their TCL functions available as a
starting point
Open action items:
Who When What
---------- ------ --------
1. Mark 4/20 Close on DAC demo participation from
-> 5/4 Synplicity, Altera
-> 5/11
2. Bob 4/20 Determine whether an NDA is required for the
-> 4/27 library data
-> 5/11
3. Mark 3/2 Add operating conditions to the taxonomy
-> 3/30
-> 4/13
-> 5/4
-> 5/25
4. Mark 4/27 Send example of how the DAC demo subset
-> 5/4 would be extended with typical values
-> 5/11
5. Mark 5/4 Work with Jeff and Ed to come up with
-> 5/11 the golden DCDL script for the demo
-> 5/18
Next Meeting:
The next meeting will be a teleconference on 5/11
from 9-11 am (PDT).
Details:
1. Review action items
No progress on closing on the
proceeding with the assumption that no NDA is required.
2. Discuss namespaces
There was general agreement with Mark's proposal to not
include namespaces in the DCDL standard itself, while describing
how to use them appropriately in an app note on DCDL/TCL
interoperability.
3. Discuss wildcards (*, ?, and/or regular expressions)
The objective of including wildcards would be to reduce the
size of files containing pure DCDL for tool interchange.
Users will already be able to use wildcards in many application-
specific scripts.
The downside is that some tools do not support wildcards today,
so adoption of the standards would be more difficult. And there
are some semantic questions about the interpretation of wildcards.
Ed brought up the case of "false_path -from {instance/*}", where
the asterisk would normally be interpreted as all of the pins on
the instance, but because it's in the -from option it should only
refer to certain of those pins (either outputs or clock pins,
depending on the details of the semantics).
No firm resolution on this; Ed and Mark felt that it will be
required, based on Cadence's experiences with constraint
translation.
A related issue is how to specify the type of the object that
is intended, to avoid ambiguities when names collide. One
tentative proposal for this is to have a default object type
(usually pin or port) for each command, then have an explicit
syntax using nested lists to override the default. For example,
false_path -from {pin1} -to {pin2}
versus
false_path -from {{waveform wf1}} -to {{waveform wf2}}
where the first entry in the nested list indicates the type of
object in that list. This is a bit cumbersome, but there is
a more serious issue: we've talked about using strict quoting
for list entries to cover embedded spaces in object names.
In that case, there wouldn't be any way to distinguish
between cases where a designer meant to refer to a pin
named "waveform wf1" instead of a waveform.
Ed. note: two other possible syntaxes are
false_path -from {waveform(wf1)} -to {waveform(wf2)}
false_path -from [waveform wf1] -to [waveform wf2]
where the first one treats waveform like a mathematical
operator, and the second one invokes a waveform command.
4. Discuss the DAC demo
IBM has transferred the TLF file for SA27 and it's working
successfully with Pearl. The first pass of the Einstimer
DCDL interpreter is complete, now in testing phase.
IBM is interested in exploring a change to the
operating_conditions statement, to first define a set of
conditions then refer to them by name. Vikas will send
Mark a description of the relevant Einstimer cmds.
We talked about the hardware/OS platform for the design.
Except for Synplicity, everyone favors Unix; Cadence
prefers Solaris.
Jeff already added false_path -through statements for reset
pins to the sample DCDL script. We still need to find
suitable logic for multi_cycle_path constraints.
Ed has updated the Pearl DCDL interpreter to match the
second draft of the subset.
We talked about the remaining work for the demo:
- How big should the constraint file be? We can have
different values for arrival/required constraints on
each pin, different combinations of flags. We agreed
the constraint file should look fairly complex.
- How robust should the interpreters be? We could
make the constraint file exhaustively exercise the
subset and verify error checking. We agreed that
this shouldn't be the focus of the demo.
- What's the flow? We agreed to make this an agenda
item for 5/11, after getting final closure on the
participants.
Thanks,
Mark
-- Mark Hahn phone: (408) 428-5399 Senior Architect fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com