I have the action item to prepare a proposal on this,
based on earlier work I did for the GCF 2.0 specification.
I've started it but haven't completed it yet; it's a bit
tricky to come up with a user-friendly syntax.
> (2) We are starting to go through the assertions for the
> processor demo and were grappling with whether we should
> be coding "dcd::" as a prefix to all our assertions.
This is a very interesting question. We certainly need
a way to avoid conflicts between the DCDL commands and
any existing commands within an application, which was
my intent in using the dcd:: prefix. When in a TCL-based
environment, the prefix would be interpreted as a
namespace qualifier, but it would be part of the DCDL
standard itself, not specific to TCL.
If all of the functions in the dcd namespace are imported
to the global namespace, then the namespace qualifier isn't
necessary, as you noted. However, I'm reluctant to rely
solely on this, because it would make conflicts unavoidable.
Another approach is to make use of the "namespace eval"
capability in TCL. This would look like
namespace eval dcd {
waveform ...
clock ...
data_arrival_time ...
}
or
namespace eval dcd {
source constraints.dcd
}
Assuming that the application-specific commands like
find are either declared in the global namespace or
imported into it, they can be used within the context
of the "namespace eval".
So, here's what I suggest:
1. Define DCDL without namespace qualifiers, which
makes the language less "TCL-ish" and more declarative.
Using a namespace qualifier would not be legal DCDL,
and applications must not require it.
2. Prepare an application note describing how DCDL is
intended to interact with TCL, which we've discussed
previously. In that app note, describe ways for TCL-based
applications to set up support for DCDL using a dcd namespace,
and for designers to use that namespace.
3. Encourage TCL-based applications to use the namespace.
Mark
-- Mark Hahn phone: (408) 428-5399 Senior Architect fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com