RE: [sv-bc] Named blocks conflicts with existing identifiers

Hi Gord,

I think you can not perform the search during the "initial parse" stage
in V2K, since the presence of generate constructs may affect the name
binding. You have to resolve the generate constructs in the whole design
before you can start binding the other references, to avoid incorrect
binding. When you start binding the other references in that second
pass, you have already parsed all declarations, including those that
follow the references to them.

However, aside this implementation point, which is not discussed in the
LRMs, I can't also find any reference in the LRMs (V95, V2K and SV) that
would suggest that a use before declaration is illegal or that the name
lookup should not consider the following local declaration in this
special case (a use before declaration). Since it is not mentioned that
any special rule applies, I think a proper interpretation of the
standard would be that the general rule should apply; the one that says
that the local declaration should be bound first (whether it precedes
the use or not).

Of course, if you claim that the LRM is just wrong (for whatever
reason), then it looks it should be captured in a Mantis ticket.

--Yulik.

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Monday, December 12, 2005 5:42 PM
To: Bresticker, Shalom
Cc: Feldman, Yulik; sv-bc@eda.org; Goren, Orly
Subject: Re: [sv-bc] Named blocks conflicts with existing identifiers

Ah, but *when* does the search occur?  If the search occurs
upon reference (during initial parse), then my interpretation
is valid.  If one must defer the search until everything is
complete, then you are correct.

If your interpretation is correct, we have a backwards
compatibility issues with 1364-1995.  Consider:

    module top;
       assign q = 1;
       wire q;
    endmodule

In 1995, the second "q" causes an error since the first "q"
creates an implicit net.  By your interpretation that is
incorrect and the first reference should resolve to the
declaration of "q".

The description in 19.3 is also (mostly) incorrect in that
it claims that the instance hierarchy is searched.  This is
not true for simple identifiers; for historical reasons
task and function calls work in this manner, but other simple
identifier references do not; if they don't resolve at compile
time, it is an error.

There are significant issues in the current name lookup
rules both in 1800 19.3 and in the hierarchical resolution rules
in 1364 Clause 12.6.  Even worse, there are some fairly nasty
interactions with class and selected name rules that haven't
been addressed at all.

This is on my list of things about which we need to have much
wider discussion.

For the time being, I stand by my interpretation.

Gord.


Bresticker, Shalom wrote:

> Gord,
> 
> What about the following?
> 
> 19.3 ("Compilation-unit support") says,
> 
> "When an identifier is referenced within a scope, SystemVerilog
follows
> the Verilog name search rules:
> - First, the nested scope is searched (see 12.6 of IEEE Std 1364)
> (including nested module declarations), including any identifiers made
> available through package import declarations.
> - Next, the compilation-unit scope is searched (including any
> identifiers made available through package import declarations).
> - Finally, the instance hierarchy is searched (see 12.5 of IEEE Std
> 1364)."
> 
> So I think it is pretty clear that when the compiler finds the first
> reference to the identifier, it checks whether the identifier has been
> locally declared. Since it has, the reference is illegal syntax here.
> And it does not matter that the declaration only occurs afterwards.
> 
> Shalom
> 
> 
>>-----Original Message-----
>>From: Gordon Vreugdenhil [mailto:gordonv@model.com]
>>Sent: Monday, December 12, 2005 5:00 PM
>>To: Feldman, Yulik
>>Cc: sv-bc@eda.org; Bresticker, Shalom; Goren, Orly
>>Subject: Re: [sv-bc] Named blocks conflicts with existing
>>identifiers
>>
>>
>>I think that the correct behavior is for the reference
>>in the "for" to bind to the $unit parameter.  The
>>reason is that the name "IO_SECONDARY_RO_INSTANCES"
>>in the module doesn't exist at the time that the reference
>>is made.  This falls into the normally expected definition
>>before use rules.
>>
>>In the given case, moving the parameter definition inside the
>>module yields an error since there is now a name conflict in
>>the module.
>>
>>A similar example is as follows:
>>
>>integer x;
>>
>>module top ();
>>  wire [31:0] y = x;
>>  integer x ;
>>
>>  initial begin
>>     x = 6;
>>     #0 $display (x,,y,,$unit::x);
>>     $unit::x = 7;
>>     #0 $display (x,,y,,$unit::x);
>>  end
>>
>>endmodule
>>
>>
>>In this case the continuous assign to y is based on $unit::x so
>>the $displays produce
>>           6          x           x
>>           6          7           7
>>respectively.
>>
>>
>>Gord.
>>
>>
>>Feldman, Yulik wrote:
>>
>>>Hi,
>>>
>>>
>>>
>>>What do you think should be the behavior of the example
>>
>>below? To what
>>
>>>declaration the expression in red should be bound? It looks
>>
>>that it
>>
>>>should be bound to the named block inside and eventually
>>
>>result in an error.
>>
>>>
>>>
>>>parameter IO_SECONDARY_RO_INSTANCES   = 1;
>>>
>>>module ptpcioregs ();
>>>
>>>genvar i;
>>>
>>>generate
>>>
>>>for (i = 0; i < IO_SECONDARY_RO_INSTANCES; i++) begin :
>>>IO_SECONDARY_RO_INSTANCES
>>>
>>>end
>>>
>>>endgenerate
>>>
>>>endmodule
>>>
>>>
>>>
>>>Can somebody confirm that, please? Shalom told me that he
>>
>>remembers
>>
>>>something similar that was discussed on sv-bc, but he is
>>
>>unsure about
>>
>>>the outcome of that discussion.
>>>
>>>
>>>
>>>--Yulik.
>>>
>>
>>--
>>---------------------------------------------------------------
>>-----
>>Gordon Vreugdenhil                                503-685-0808
>>Model Technology (Mentor Graphics)
>>gordonv@model.com
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com