Subject: DC-WG: object typing redux
From: Mark Hahn (mhahn@cadence.com)
Date: Tue Aug 01 2000 - 00:21:27 PDT
In previous discussions about semantics for the -through_object_type
options of the timing exceptions (false, multi-cycle, and combinational paths),
we've explored alternate approaches for specifying design object types.
To recap the issue, in several existing constraint formats, users can
specify that a timing exception applies to a set of paths that pass through
1. a single design object
2. a series of design objects (ordered from source to target)
3. any of a set of design objects
followed by any of another set of design objects
followed by any of another set of design objects ...
For cases 1 and 2, the existing syntactical approaches in DCDL are
sufficient. For example,
1. false_path -through_pin {I1/Y}
2. false_path -through_pin {I1/Y} -through_net {N1} -through_pin {I3/B}
In discussing case 3, we've referred to it as the OR-AND semantics,
because the paths affected are those that go through
(element 1 of the first set OR element 2 of the first set OR ...)
AND then go through
(element 1 of the second set OR element 2 of the second set OR ...)
AND then go through
(element 1 of the third set OR element 2 of the third set OR ...)
The prevailing convention is to have
- one -through option for each of the sets,
- the value for each option be a list of the elements in the corresponding
set, and
- the -through options be specified in order from source to target.
This convention works well as long as all of the elements in a given set
are the same design object type. However, when a set contains different
design object types, this approach breaks down when combined with the
DCDL approach to specifying design object types as part of the option
name. We can't have nets and pins mixed in the same set, because for
a given -through_object_type option, we must either choose the type to be
pins or nets.
Subsequent discussion has identified two divergent approaches:
- Abandon the approach of encoding the object type in option names
in favor of a different syntax
- Define a special syntax for the timing exceptions to accommodate
the OR-AND semantics without changing the way in which object types
are specified.
The latter approach has been tentatively discussed, but no proposal
had been made previously for the syntax.
Proposal:
- Follow the prevailing convention when each of the sets contains
only one type of design object, using the -through_object_type
approach to specify the type.
- Add a -or option to the timing exception commands to group several
different -through_object_type options to form a combined set of
objects with different types.
- Add a -and option to separate -through_object_type options into
different sets.
- If no -or or -and options are specified, the effect is the same
as if a -and option was specified between each pair of -through_object_type
options.
For example, if I want to specify that the set of paths that go through
(pin A OR net B) AND then through (pin C or NET D) are false, I would use
false_path \
-through_pin {A} -or -through_net {B} \
-and \
-through_pin {C} -or -through_net {D}
If B and D were pins instead of nets, I could specify (succinctly)
false_path -through_pin {A B} -through_pin {C D}
or (more explicitly),
false_path -through_pin {A B} -and -through_pin {C D}
or (very explicitly)
false_path \
-through_pin {A} -or -through_pin {B} \
-and \
-through_pin {C} -or -through_pin {D}
After reviewing the tradeoffs between this approach and an
explicit casting syntax, I believe that this one is much better.
Thanks,
Mark
-- Mark Hahn phone: (408) 428-5399 Senior Architect fax: (408) 894-3479 Cadence Design Systems email: mhahn@cadence.com
This archive was generated by hypermail 2b28 : Tue Aug 01 2000 - 00:27:05 PDT