There are actually two different approaches in the implementation
of the IBM EDA tools. Often, there are explicit -pins, -ports and
-nets flags which are followed by a list of names. Alternatively
there are a few cases where the command actually vary, i.e. there
might be 2 or 3 variants of a command for each type of object.
Probably half the EinsTimer commands we are mapping the DCD
subset to contain flags of this nature. In talking with the
developers, they pointed out that new commands will tend to merge
the -pins and -ports function into just -pins (with, perhaps,
-ports functioning as a "alias" for -pins). For example, the
EinsTimer 3.1 syntax is:
set_arrival
{ -time double }
required
{ -ports list of strings + -nets list of strings + -pins list of strings }
required
{ -clock string | -phase string }
required
[ -rise + -fall ]
[ -min + -max + -early + -late ]
[ -inverted | -no_inverted ]
[ -clk_phase | -no_clk_phase ]
If not in this release, then soon its likely that lists for
-pins and -port will, in effect be combined and processed
the same way.
One other observation about a nubmer of the statements, such as
data_arrival_time, data_required_time, slew_time and
external_capacitance- they have multiple parameters which are
specified without flags. I know its slightly more verbose, but
I would prefer to limit parameters without a flag to one per
command. When more than one is permitted (or required) then
parameter sequence becomes critical, and to me less clear to
the new user.
Based on our experience with various tools, we've been trying
not to make any assumptions about the ordering of flags and
parameters. That is, we are assuming that flags may be before
or after parameters or anywhere in between, and may be in any
order. When you mix this multiple unflagged parms, you end up
with lots of permutations, some of which are hard to read
visually!
Any thoughts on the relevance to DCD or the DAC subset?
Regards..... Bob
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- IBM Microelectronics Division ASIC Synthesis and Timing Team -------------------------------- -------------------------------- Bob Dilly 802-769-7786 dilly@btv.ibm.com IBM - Dept G46V - MS 863K Essex Junction, VT 05452-4299 tie 446-7786 / dilly@btv.vnet
. . . > 3. Arrival times > > dcd::data_arrival_time > ?-waveform <waveform_name>? > ?-lead | -trail? > ?-early | -late? > ?-rise | -fall? > <time_value> > <pin_list> > > When any of the options -early, -late, -rise, or -fall are specified, > <time_value> must be a single value, and it applies to all of the > value slots implied by the combination of the options. > > When none of those options are specified, <time_value> can either be > a single value that applies to all four value slots, or a list of four > values, one for each slot: > { <early_rise> <late_rise> <early_fall> <late_fall> } > > Asterisks can be used for one or more of the four values, to indicate > that the value is unspecified by this statement (the value slot is left > unchanged). If there are previous statements that specify a value for > the same slot, the old value will be preserved. Later, we'll add > a -reset option to each command to support eliminating an existing value > from a slot. > > This approach has the advantage of preserving the common usage for > initial entry, while also providing a more compact syntax for advanced > users and for interchange. . . . . >-- >Mark Hahn phone: (408) 428-5399 >Senior Architect fax: (408) 428-5959 >Cadence Design Systems email: mhahn@cadence.com >