Feldman, Yulik wrote: > 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. Yulik, Any "deferred" bindings in Verilog 2005 are treated in the same manner as hierarchical references and must have dotted names. Any undotted name can be resolved directly (other than the function/task/scope name issues that have already been noted). This has been substantially clarified in the 1364-2005 rules by the rules related to "directly nested conditionals" and rules regarding generate loops. In 1364-2001 the rules would allow names to come into existence in a parent scope; this posed so many headaches that the 2005 rules made that impossible. Under 2005 it is now clear when and how direct identifiers bind and the final elaboration doesn't modify the lexical binding (only the *instance* of the bound id). > 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. Yes. As I noted in my previous mail, this is something that needs to be addressed more widely in any case due to additional interactions with other SV constructs. Gord. > --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.comReceived on Mon Dec 12 09:21:43 2005
This archive was generated by hypermail 2.1.8 : Mon Dec 12 2005 - 09:21:54 PST