Re: [sv-bc] mantis item 3608

Francoise,

I think this should be illegal based on the current LRM rules.

The rules for a dotted name say that the first name resolves as a
bare identifier. If it isn't found, the dotted name becomes a
hierarchical reference. But a hierarchical reference must start
with a scope name, not a variable name. So the hierarchical
resolution should fail. If you preceded the name with the
module name then it would be legal (as would any
"forward" variable reference in that case) as the first name
would then be a scope name.

Gord.

On 6/14/2011 8:26 AM, Francoise Martinolle wrote:
> Both are issues.
> The first one is that the dotted name resolution only talks about variables. It should
> also apply to parameters and nets.
> The description in that section does not specify which declarations a dotted name can bound to.
> It is not clear if the text allows forward references for variables.
>
> For example, is this legal?
> Ex1: fwd decl of variables
> module top;
> typedef struct {int m; } S;
>
> logic [31:0] v = w.m;
> S w;
>
> endmodule
>
> In Verilog no forward references where allowed for any data object.
> With the introduction of type parameters, resolving a name or a dotted name defers the resolution until
> elaboration. At that point, the symbol tables are filled in and a simple look up mechanism may
> find declarations after use.
>
> Ex2: fwd declaration of variables
> module top;
> typedef struct {int m; } S;
> parameter type T = S;
> logic [31:0] v = w.m;
> T w;
> endmodule
>
> If we allow fwd references then in the example below p.m would resolve to the variable p in g1
> instead of parameter p in top.
> Ex3:
> ------------------------------------------------------------
> module top;
> typedef struct packed {int m; } S;
> parameter S p = '{1};
>
> generate
> if (1) begin : g1
> var v2 = p.m; // does p resolves to top.p or g1.p?
> var S p;
> end
> endgenerate
> endmodule
> --------------------------------------------------------------
>
> Ex4: Class testcase:
> Type parameters delay the name resolution until the type parameter is resolved.
> The simple name lookup will find the member p in class D which is declared after the reference to p.m
>
> package pkg;
> class C;
> int p;
> endclass
>
> endpackage
>
> module top;
> import pkg::*;
> parameter type T = C;
> typedef struct packed {int m; } S;
> class D extends T;
> login [31:0] v = p.m; // Does p resolves to p in C or p in D?
> S p;
> endclass
> endmodule
>
>
> Francoise
> '
>
>
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Tuesday, June 14, 2011 7:55 AM
> To: brad_pierce@acm.org; Francoise Martinolle
> Cc: SV-BC
> Subject: RE: [sv-bc] mantis item 3608
>
> See also Mantis 1235.
>
> Also, looking at the notes in 3608, is the issue member selects or is it forward references?
>
> Regards,
> Shalom
>
>> -----Original Message-----
>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
>> Brad Pierce
>> Sent: Monday, June 13, 2011 6:24 PM
>> To: Francoise Martinolle
>> Cc: SV-BC
>> Subject: Re: [sv-bc] mantis item 3608
>>
>> Can we say instead 'data object'? According to 6.2, "A data object is
>> a named entity that has a data value and a data type associated with
>> it, such as a parameter, a variable, or a net."
>>
>> -- Brad
>>
>> On Mon, Jun 13, 2011 at 6:34 AM, Francoise Martinolle<fm@cadence.com>
>> wrote:
>>> I created a mantis item and put a proposal for 3608.
>>>
>>> Can this mantis item be added to the next meeting agenda.
>>> Francoise
>>> '
>>> --
>>> 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.
>>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>

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