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

I think what may be confusing is that the rules in 1364 sec 12.5 and
12.6 only apply to upwards or hierarchical references. I think we may
need extra language to make this explicitly illegal. Consider this
example; its very similar to the case when you reference a variable in
an imported package, and then try to declare another version of it
within the same scope.


integer X;
module foo;
initial X=1;
integer X;
initial X=2;
endmodule

It should be illegal to have the same identifier reference two different
objects within the same scope.



> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Monday, December 12, 2005 7:05 AM
> To: Vreugdenhil, Gordon; Feldman, Yulik
> Cc: sv-bc@eda.org; Goren, Orly
> Subject: RE: [sv-bc] Named blocks conflicts with existing identifiers
> 
> 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