Re: [sv-bc] setting parameters in configurations

Don Mills wrote:
 > I have opened a mantis item on this subject #2037 and uploaded my first
 > draft of the new section.  For those of you who have looked at my
 > preliminary draft earlier today - you will find the uploaded draft to be
 > much more verbose.
 >


Don,

I think the general intent of the proposal is reasonable but I
have some issues with the current form.

First, I don't like:
    instance top.a1 #(1,2);

Normally, the change part of an instance clause is either
in a lib_list or a use_clause.  I would fold this into
the "use_clause" part and have something like:
     instance top.a1 use #(1,2);

I would reserve the syntax you used for possible other semantics in
the future.


I would make (at least) the following restrictions:
   1) a localparam in a configuration shall only be set to a literal value
   2) index expressions in a hierarchical name shall only refer to
      literals or localparams of the configuration
   3) if a reference to a name in the target instance context is used
      in an override, it shall be the only term in the expression.
   4) a hierarchical name in a parameter override shall be resolved
      starting in the context of the configured instance.  If a hierarchical
      name is used, it must be the only term in the expression.  (i.e you can't have
      a.b.c + 7).
   4) a parameter override in a configuration shall not refer to a
      constant function other than a predefined constant system functions

The above are likely enough though I need to think about it some more.

This basically boils down to either having a simple name to name
remapping of a parameter or having a value that can be determined
as a literal at the time the configuration is compiled.  That avoids
most of the hard issues that Mark was beginning to raise in terms of the
context of the evaluation of the parameter override expression.  I
think (from a quick look) that all the examples you have are still
legal given this set of restrictions.


I would reword:
     When an instantiation has parameter overrides and the configuration
     instance does not specificy parameter overrides...
to be:
     When an instantiation has parameter overrides and the configuration
     instance does not have a parameter override list...


There also seems to be a contradictory approach.  You say:
    instance top.a1 #();  // set all parameters in instance a1 back to their default
but when you have at least one override, the rest don't go back to
their defaults, they are unmodified.

I would prefer to say that #() means "everything goes back to default"
and #(.name) means "use the existing instance's value for .name".

The overall proposal is still somewhat informal, but if we
can get consensus on a viable rule set, that shouldn't be too
hard to fix.

Gord

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.