Re: [sv-bc] setting parameters in configurations

See my responses below:

Gordon Vreugdenhil wrote:
>
> 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 prefer my original syntax leaving the "use_clause" for specific cell 
binding.  But I will concede on this because I have not strong argument 
for my approach other then it is similar syntax to instantiation 
redefinition of parameters.  I like to keep things the same where I 
can.  Maybe someone else has preferences one way or the other here.
>
> I would reserve the syntax you used for possible other semantics in
> the future.
>
>
Each of the following will be added to the write up of my next upload.
> 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...
done
>
>
> 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".
This is addressed.  I was using ".name" substitution.  That is now 
removed from the examples.  I don't want to have .name substitution as 
part of this pass.
> 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
>

-- 
==========================================================
Don Mills
mills@lcdm-eng.com
www.lcdm-eng.com
==========================================================


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