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.