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.comReceived on Mon Dec 12 07:04:57 2005
This archive was generated by hypermail 2.1.8 : Mon Dec 12 2005 - 07:05:02 PST