RE: [sv-bc] Hierarchical references in #(...) instantiations and $bits() constant function calls (1224 and 2856)

I remember once bring up the fact that module instance overrides were not constant expressions in the BNF. I think Steven said that the intent always was that they should be constant expressions, although VerilogXL allowed hierarchical references in module instance overrides and many other tools allow it for VerilogXL compatibility.

This is the issue brought up in a number of the mantis items under 3055, so we are allowed to work on this issue.

Gord and I discussed this some at DVCON. I believe we should change the LRM to simply say that module instance overrides must be constant expressions, and have been thinking about writing up a proposal to make that change.

If we decide to go the other way and say hierarchical reference are allowed in module instance overrides, then it is clear that any arbitrary hierarchical reference cannot be allowed, as Gord has pointed out below. The committee added rules in the LRM concerning the interaction between defparams and generate, but it did not do it for hierarchical references in overrides. I think this was not an oversight. It was because the committee did not consider hierarchical references were allowed in overrides.

If we are allowing hierarchical references to parameters, then do we allow hierarchical references to type parameters in type parameter overrides? Do we allow hierarchical constant function calls? Hierarchical references in overrides are very similar to defparams, which we have deprecated. Why would we clarify the LRM to make them clearly legal when we deprecated defparams?

I think allowing hierarchical references in overrides would create more issues than it solves. Changing the LRM to say that overrides must be constant expressions now does not preclude the committee from relaxing that in some future LRM.

Many tools currently support this with some set of restriction. I don't expect any tools to stop supporting it because the LRM is changed.

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad Pierce
Sent: Thursday, March 24, 2011 3:04 PM
To: sv-bc@eda.org
Subject: RE: [sv-bc] Hierarchical references in #(...) instantiations and $bits() constant function calls (1224 and 2856)

Gord,

Is there a way to characterize non-messy SV topological specifications? If we could define that, we could declare that all other specifications have tool-dependent solutions and that any conforming tool must detect and report when the user has crossed over into the twilight zone.

-- Brad

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Thursday, March 24, 2011 1:18 PM
To: Brad Pierce
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Hierarchical references in #(...) instantiations and $bits() constant function calls (1224 and 2856)

Brad,

If you think about parameters and other "topological shape"
items in legacy Verilog (pre-2001), it is fairly easy to figure out
how to solve such systems. With generates, things became
pretty messy. So, for example, the following extrapolation
of your example would likely be a problem (even for an
implementation trying to preserve legacy behavior):

     module top;
        child #(inst.gb.p) inst();
     endmodule

     module child #(P = 32);
        bit v[P];
        if (1) begin:gb
          parameter p = P;
        end
      endmodule

The reason is that the "downwards" instantiation reference is
really semi-equivalent to an illegal upwards defparam across
a generate boundary and one can create structural
contradictions in such situations.

SV has made things even worse by including variables and not
just parameters in the computation via type, $typename, etc.

It probably should be made illegal to have hierarchical names
in module instance parameters due to the existing issues,
but I would also fully expect that implementations will
continue to support that extension as well as other similar
interpretations. If we really want to define a common
set of behavior, we shouldn't make things illegal, we should
do the hard work of defining a model that indicates why
and how certain things will compose or won't.

Gord.

On 3/24/2011 1:06 PM, Brad Pierce wrote:
> But why should that restriction apply to the constant $-function calls if it doesn't apply to #() in instantiations? If the following xref is legal, why not xrefs in constant $-function calls, too?
>
> module top;
> child #(inst.P-1) inst();
> endmodule
>
> module child #(P = 32);
> bit v[P];
> endmodule
>
> -- Brad
>
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Thursday, March 24, 2011 1:01 PM
> To: Brad Pierce
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] Hierarchical references in #(...) instantiations and $bits() constant function calls (1224 and 2856)
>
> Note that for $typename, the following explicit restriction applies:
> When used as an elaboration time constant, the expression shall not
> contain any hierarchical references or references to elements of
> dynamic objects.
>
> That restriction should likely apply to all query systfs.
>
> Note as well that there are some other very strange situations that
> can expose these issues as well.
>
> foreach (a.b.c[i]) begin:blk
> reg [$bits(i):0] some_reg;
> type(i) some_other_reg;
> end
>
> Such a block also relies on type and queries functions on
> hierarchical names, but indirectly through the induction
> variable. Even the $typename restriction wouldn't directly
> restrict it unless you apply some transitivity to the reasoning.
>
> Gord.
>
> On 3/24/2011 11:06 AM, Brad Pierce wrote:
>> According to the comments on http://www.eda.org/svdb/view.php?id=1224 , hierarchical references are allowed in the parameter value assignments in module instantiations, hence the use of param_expression instead of constant_param_expression in A.4.1.1 .

>>
>> In http://www.eda.org/svdb/view.php?id=2856 , Françoise gives an example of the dangers of allowing hierarchical references in $bits() constant function calls. I think the following is equivalent
>>
>> module top;
>> child #($bits(inst.v)-1) inst();
>> endmodule
>>
>> module child #(P = 32);
>> bit v[P];
>> endmodule
>>
>> or simply
>>
>> module top;
>> child #(inst.P-1) inst();
>> endmodule
>>
>> module child #(P = 32);
>> bit v[P];
>> endmodule
>>
>> If hierarchical references are legal within the #(), yet the final example is illegal, then maybe whichever rule makes it illegal could be applied to the $bits() call in Françoise's example.
>>
>> -- Brad
>>
>>
>>

-- 
--------------------------------------------------------------------
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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.