[sv-bc] mantis issue 1809

From: Francoise Martinolle <fm_at_.....>
Date: Fri Mar 14 2008 - 12:43:52 PDT
Here is an updated proposal for Mantis 1809. I will upload to Mantis
database.

I will be on line this week end if there are comments and will try to
fix the proposal for Monday's meeting.

 

Francoise

   

 

All references are based on P1800-2008 draft 4

 

In 25.3

 

CHANGE:

 

A wildcard import allows all identifiers declared within a package to be
imported provided the identifier is

not otherwise defined in the importing scope:

 

    import ComplexPkg::*;

 

A wildcard import makes each identifier within the package a candidate
for import. Each such identifier is

imported only when it is referenced in the importing scope and it is
neither declared nor explicitly imported

into the scope. Similarly, a wildcard import of an identifier is
overridden by a subsequent declaration of the

same identifier in the same scope. If the same identifier is wildcard
imported into a scope from two different packages, the identifier shall
be undefined within that scope, and an error results if the identifier
is used.

 

TO:



A wildcard import is of the following form: 

import ComplexPkg::*;

For the purpose of describing how names resolve to wildcard imported
declarations we define what is a locally visible and potentially locally
visible name.

Locally visible names are the names of locally visible declarations.

A name is locally visible at some point, P, in a scope, S, if one of the
following holds:

1.     the name denotes a scope within S

2.     the name is declared within S before point P

 3.  the name is visible from an import select occurring within S before
point P

           A name is potentially locally visible at some point, P, in a
scope, S, if :

                      there exist a wildcard import of a package within
scope S and the package contains a declaration of that name.

Additionally a potentially locally visible symbol from a wild card
import may become locally visible if 

no locally visible symbol is found and the resolution of an identifier
causes the potentially locally visible name

to become locally visible. 

The following paragraph describes how identifiers can be resolved to
wildcard imported declarations.

A wildcard import makes all identifiers declared within a package
potential locally visible symbols in the importing scope, S .

A potentially locally visible symbol may become locally visible during
name resolution of an identifier appearing

in a scope S,  in accordance to the following rules:

If  the identifier is not a function or task call,

the following search algorithm is repeated for each scope S in the
nested lexical scopes until a declaration is found which matches the
identifier name or there is no more upper lexical scopes. The
compilation unit scope being the final scope searched.

A.1 - the locally visible declarations in current scope S are first
searched for a match, if a match is found the identifier is bound to
that declaration

A.2- else if no locally visible symbol match, then the potentially
locally visible symbols in the scope S, lexically preceding the
identifier name are searched for a match. If a match is found, the
symbol from the package is imported in scope S and becomes a locally
visible declaration in scope S, that declaration  is bound to the
identifier.

A.3- else current scope S is set to its upper scope

If there is no more lexical scopes, and the identifier cannot be bound,
an undeclared symbol error shall be issued.

If the identifier is a function or task call, the rules are slightly
different and follow upwards hierarchical name resolution (section
22.7).

  B.1- First the entire scope S (all the declarations of locally visible
names up to the end of the scope) is searched for a matching
declaration, if a match, the identifier is resolved to that declaration,

  B.2- else if no match is found, the potentially locally visible
symbols from wildcard imports in current scope S, lexically preceding
the identifier name are searched for a match, 

if a match is found, the potential visible symbol becomes locally
visible, is imported in current scope S and bound to that identifier,

 B.3- else if no match is found, current scope S is set to upper scope
and steps B.1, B.2, B.3  are repeated including when S is the
compilation unit scope.

B.4. else if no match, steps b and c of the upwards name resolution are
executed (the function and task name are searched up the instance
hierarchy).

 If the same name is potentially locally visible from more than one
wildcard imported package in scope S, and those wildcard imports are
lexically preceding an identifier of that name,  the identifier shall be
undefined within that scope. 

 

Example 1:

package p;
    int x;
endpackage

module top;
    import p::*; // line 1

     if (1) begin : b
         initial x = 1; // line 2
         int x; // line 3
         initial x = 1; // line 4
     end
     int x; // line 5
endmodule

 

The reference in line 2 causes the potentially locally visible x from
wildcard import p::* ( p::x ) to become locally visible in scope top and
line 2 initializes p::x.  Line 4 initializes top.b.x. Line 5 is illegal
since it conflicts with the name x imported from p which had become a
locally visible declaration.

Example 2:

package p;
      int x;
endpackage

package p2;
      int x;
endpackage

module top;
      import p::*; // line 1
      if (1) begin : b
          initial x = 1; // line 2
          import p2::*; // line 3
      end
endmodule

Line 2 causes the import of p::x in scope "top" because the wildcard
import p::* is in the outer scope "top" and precedes the occurrence of
x. The declaration x from package p becomes locally visible in scope
"top".

 Example  3:

package p;
    function int f(); 
        return 1; 
    endfunction
endpackage

module top;
    int x;
    if (1) begin : b
        initial x = f(); // line 2
        import p::*; // line 3

    end

    function int f();
        return 1;
    endfunction
endmodule

"f()" binds to top.f and not to p::f since the import is after the
function reference. 

Example 4:

package p;
    function int f();
        return 1; 
    endfunction
endpackage

package p2;
    function int f();
        return 1; 
    endfunction
endpackage

module top;
    import p::*;
    int x;
    if (1) begin : b
        initial x = f(); // line 1
    end
    import p2::*;
endmodule

 

Since "f" is not found in scope b, the rules require inspection   of
all wildcard imports in the parent scope.  There are two wildcard
imports, but p::* occurs before the occurrence of f(). In this case "f"
binds  to p::f since the enclosing scope's reference occurs before the
p2::* import.

 

In 3.10.1:

 

CHANGE:

 

a) All files on a given compilation command line make a single
compilation unit (in which case the declarations within those files are
accessible anywhere else within the constructs defined within those
files).

 

TO:

 

a) All files on a given compilation command line make a single
compilation unit (in which case the declarations within those files are
accessible following normal visibility rules throughout the entire  set
of files anywhere else within the constructs defined within those
files). 

 

 

 

CHANGE:

 

When an identifier is referenced within a scope:

- First, the nested scope is searched (see 22.7) (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 22.6).

TO:

When an identifier is referenced within a scope:

- First, the nested scope is searched (see 22.7) (including nested
module declarations), including any identifiers made available through
package import declarations.

- Next, the portion of the compilation-unit scope defined prior to the
reference is searched (including any identifiers made available through
package import declarations).

- Finally, if the identifier follows hierarchical name resolution rules,
the instance hierarchy is searched (see 22.6 and 22.7).

 

 

 

 

CHANGE:

 

For example:

bit b;

task foo;

int b;

b = 5 + $unit::b; // $unit::b is the one outside

endtask

 

TO:

For example:

bit b;

task foo t;

int b;

b = 5 + $unit::b; // $unit::b is the one outside

endtask

 

Other than for task and function names (see 22.7.1), references shall
only be made to names already defined in the compilation unit. The use
of an explicit $unit:: prefix only provides for name disambiguation and
does not add the ability to refer to later compilation unit items.

 

For example:

task t;

     int x;

x = 5 + b;           // illegal - "b" is defined later

x = 5 + $unit::b;    // illegal - $unit adds no special forward
referencing

endtask

bit b;

 

 

Add the following to the end of Clause 13:

 

13.7 Task and Function names

 

Task and function names are resolved following slightly different rules
than other references.  Even when used as a simple name, a task or
function name follows a modified form of the upwards hierarchical name
resolution rules.  This means that "forward" references to a task or
function defined later in the same or an enclosing scope can be
resolved.  See Section 22.7.1 for the rules that govern task and
function name resolution.

 

Add the following to the end of Section 22.7:

 

22.7.1 Task and Function name resolution

 

Task and function names are resolved following slightly different rules
than other references.  Task and function name resolution follows the
rules for upwards hierarchical name resolution as described in 22.7,
step (a).  Then, before proceeding with step (b), an implementation
shall look in the complete compilation unit of the reference.  If a task
or function with a matching name is found there, the name resolves to
that task or function.  Only then does the resolution proceed with step
(b) and iterate as normal.  The special matching within the compilation
unit shall only take place the first time through the iteration through
steps (a)-(c);  a task or function name shall never match a task or
function in a compilation unit other than the compilation unit enclosing
the reference.

 

Example:

 

task t;

     int x;

x = f(1);            // valid reference to function f in $unit scope

endtask

function int f(int y);

     return y+1;

endfunction

 

 

Example:

 

package p;

  function void f();

    $display("p::f");

  endfunction

endpackage

 

module top;

  import p::*;

 

  if (1) begin : b         // generate block

     initial f();          // reference to "f"

     function void f();

       $display("top.b.f");

     endfunction

  end

endmodule

 

The resolution of the name f follows the hierarchical rules and
therefore is resolved to the function top.b.f.  The output of the
example would be the output of the string "top.b.f".

 

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Mar 14 12:45:26 2008

This archive was generated by hypermail 2.1.8 : Fri Mar 14 2008 - 12:46:00 PDT