Re: [sv-bc] Using multiple clauses of configuration for elaborating an instance

I agree that the LRM is unclear on this (and other aspects of configurations).
Multiple clauses can be applicable, per one written rule (quoted below), plus
lots of common sense to keep things sane from being completely insane.

Config rules have a selector clause (cell or instance) and an action clause (use or liblist).
Multiple selector clauses might match any given instance (as written). The selected actions
will either compound somehow, or one will override the other. The precedent for overriding
is that any rule whose selector matches an instance overrides the default rule.
We also have the precedent that more-specific instance paths override any less-specific instance (that
gives only a prefix of the more-specific path) - this is one way of thinking about liblist inheritance:
absent a specific instance selector, take the liblist of the nearest direct ancestor.

Liblist and use clauses are almost orthogonal, so they could compound additively (both action semantics implemented).
Overriding would then happen independently for each action category, except that use lib.cellname perforce
overrides any liblist. Since omitting the lib there is said to mean the parent cell's library is referenced,
it must be that any  use with a cellname overrides any liblist. A use giving only
parameter settings probably does not suppress the prevailing liblist action.

The LRM says: "The use clause has no effect on the current value of the library list. It can be common in practice to specify
multiple config rule statements, one of which specifies a binding and the other of which specifies a library list." Which
leaves the question if I have a binding, what would I go searching for? Recall: omitted library == parent's library!

I think we can also generalize the specificity principle to rank selectors so that an instantiation
in design D, written as: mod ST(); would match the first of the following selectors that guarded some action:

1. instance D.parent.ST
2. cell lib.mod          // caveat: whether the library matches may involve a chain.
   
3. cell mod
4. instance D.parent
5. instance D
6. default

Compounding of properties, such as using D.parent's liblist to discover that mod is to be found in lib,
and thus matching cell lib.mod represents, I think, one of the few ways that config rules can be said to
chain. I do not think more aggressive chaining is sensible, in fact it seems harmful. There are two cases worth
arguing about:

Swapping:
    cell A use Z;
  cell Z use A;
I'd prefer this to allow you to swap two module definitions, rather than hang the compiler in an infinite loop of rules.

Library chaining:  I find it unnecessary to say cell clause matching can be chained
    cell lib.mod use something.DIFFERENT;
  cell mod liblist lib;
Since the same effect can always be had directly:
    cell mod use something.DIFFERENT;

It seems that some chaining may be intended to happen, from instance liblist L1 L2 L3; to cell L2.modname ...;
Here, though, I am at a loss to say whether the cell clause matches if there is no modname in L2.
Would it match if modname was in L3?, how about L1? Does the existence of a rule at a given library location
satisfy a library search? 

Greg

On 5/10/2013 2:27 AM, Datta, Kausik wrote: