CASE1: Does LRM defines rules on how tool should behave if reference to an identifier which is unknown at this point of source code. Idetnifier is delcared later in code (case1). LRM specifies that both single pass parser and multi pass parser may be used for parsing SV code (LRM:" Implementations may execute compilation in one or more passes") It is obvious that single pass compiler will fail on case like below, while mutli pass can handle with that. So this should be tool dependend if CASE would pass compilation? 2nd case is connected - what should happend if in current scope and in higher scope there is an identifier declared. But in current scope declaration is place in code after reference - so which one should be printed by case2. Is it defined or tool dependend? LRM:22.9 says:"If an identifier is referenced directly (without a hierarchical path) within a task, function, named block, or generate block, it shall be declared either within the task, function, named block, or generate block locally or within a module, interface, program, task, function, named block, or generate block that is higher in the same branch of the name tree that contains the task, function, named block, or generate block. If it is declared locally, then the local item shall be used; if not, the search shall continue upward until an item by that name is found or until a module, interface, or program boundary is encountered." So imho in both cases "2" should be displayed CASE1: module top; class nested; function new (); $display(i); // displaying "i" - this should be a failure - as i is unkcnown since here, or 2 shoudl be displayed? endfunction int i = 2; // local member "i" endclass nested n_inst = new(); endmodule CASE2: module top; bit [2:0] i = 0; // static member "i" class nested; function new (); $display(i); // displaying "i" - which i would be displayed - ??????????????? endfunction int i = 2; // local member "i" endclass nested n_inst = new(); endmodule DANiel -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Sep 4 02:53:26 2008
This archive was generated by hypermail 2.1.8 : Thu Sep 04 2008 - 02:54:21 PDT