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

On 3/24/2011 3:03 PM, Brad Pierce wrote:
> 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

There are. But I'm not sure that there would be vendor
agreement on the definition since some of the other
implications (such as the type and $bits cases, etc) have
more interesting vendor specific aspects. We could see
if we can reach agreement on what we might want
to allow and then fit a model around that.

I don't think that I'd be prepared to give a full description
of Questa's interpretation and handling of these
issues. But if we agree to a "what's in, what's out"
set of functionality, I suspect that we could find ways
of describing that which wouldn't conflict with
implementation specifics.

For example, I'd be very happy with (some variant of)
the following:
     A hierarchical reference to a parameter is considered
     to be a constant expression if:
       a) the reference resolves in upwards manner or
       b) no downwards component of the name crosses a
            generate construct or arrayed instance.

Some tools may allow more than this and/or allow
more in certain scenarios, but I think/hope that the above
would be a reasonably flexible definition that allows all
(old) legacy assumptions to work (no generates!) and which
is conceptually consistent with upwards defparam rules.

Gord.

> -----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.