Re: [sv-bc] RE: E-mail Ballot Due Dec 17 8AM PST

From: Steven Sharp <sharp_at_.....>
Date: Mon Dec 17 2007 - 08:42:13 PST
Don,

My concerns have gotten stronger with further thought.

Now I am concerned with even non-hierarchical names in the overrides, as
you can get circularities even with local references.  In the HDL, you
cannot get a circularity with a local reference, because a parameter
value expression cannot make a forward reference to a parameter declared
later (except via an illegal hierarchical name).  But your proposal would
allow a parameter value to be defined in terms of one declared later in
the same module (which could have a value defined in terms of the first).
This is an inherent problem of bringing these overrides in from outside
the normal source language order.

I have also gotten more concerned with the hierarchical names.  There
do already exist situations that allow circularities (such as upward
defparams).  These should never have been allowed in the first place,
and the situation should not be worsened by allowing more such situations.
This new situation would be even worse, since it would add a whole new
layer of overriding on top of the existing ones, greatly increasing the
complexity of interactions.

By far the worst form of these circularities occur when they interact
with generates.  These could result in generating different hierarchies
for the same design, all equally valid, depending on exactly how the
resolution is done.  Extra restrictions were placed on upward flow of
parameter values across generates to prevent this.  I don't see that
protection in this config proposal.

The only quick fix I can see for this is to disallow any reference to
design parameters in the values provided by the config.  I assume that
the enhancement would be of very little use with this restriction.  More
design work is needed to come up with a version of this enhancement that
gives the desired functionality while avoiding these problems.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Dec 17 08:42:37 2007

This archive was generated by hypermail 2.1.8 : Mon Dec 17 2007 - 08:42:46 PST