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.comReceived on Mon Dec 12 07:41:49 2005
This archive was generated by hypermail 2.1.8 : Mon Dec 12 2005 - 07:41:55 PST