Subject: Re: DC-WG: object typing
From: Alexander Suess (ajsuess@vnet.ibm.com)
Date: Fri Jul 21 2000 - 07:27:56 PDT
Mark,
The approach we've taken within the tcl based tools inside of IBM is do
things via explicit options and we specifically moved away from an approach
where any data type is allowed as that added a number of complexities to the
code.
For one thing, instead of letting the tcl parser do the work of parsing the
options we now need to do parsing of the options to figure out if something is
a net/pin/block whatever.
Secondly, in the case where you are not using the default mode your tcl would
be cluttered with net(), instance() such as:
set_false_path -through {net(A) net(B) net(C) net(D)}
could have been more succinct with:
set_false_path -through_net{ A B C D}
This also gets rid of the concern regarding a pin being named pin(A).
-Alex
Mark Hahn wrote:
> In last week's meeting we discussed a problem with
> the current approach of specifying design object types
> using an expanded set of keywords, such as -from_pin,
> -from_port, -from_instance, ...
>
> The issue is that with this approach, it's not clear how
> to express OR-AND semantics for false_path, multi_cycle_path,
> and path_delay. With the OR-AND semantics, we need to be
> able to specify that paths through (pin A OR net B) AND
> then through (pin C OR instance D) are affected.
>
> With the current approach, pin A and net B have to be separated
> into two different options, -through_pin A and -through_net_B,
> as do pin C and instance D. This is inconsistent with the more
> intuitive but untyped -through {A B} -through {C D} syntax allowed
> in several existing constraint languages.
>
> Proposal:
> - Switch to using a C++ casting style for specifying object
> types within design object lists, and define a default
> object type for each option.
>
> Examples:
> - Assume that we choose pin as the default object type for
> the -from/-through/-to options in set_false_path.
> Then the syntax for the example above would be
>
> set_false_path -through {A net(B)} -through {C or instance(D)}
>
> - If there are design objects whose names collide with the
> casting syntax, they must be explicitly typed.
>
> Suppose we instead have an instance named "pin(A)" and a pin
> named "pin(B)". Then the required syntax would be
>
> set_false_path -through {instance(pin(A)) pin(pin(B))}
> -through {C or instance(D)}
>
> Issues:
> - What if we have a pin named "\A)) B"?
> Then the parser could get confused by
>
> set_false_path -through {pin(\A)) B) C}
>
> - Should we allow several names within the cast, as in
>
> set_false_path -through {net(A B)}
>
> 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 : Fri Jul 21 2000 - 07:33:13 PDT