RE: [sv-bc] Search order for functions/tasks in modules, $unit and packages

Steven,

The upward reverence rule is in the 1364 standard. See section 12.7.

"If the item is a variable, it shall stop at a module boundary; if the
item is a task, function, named block or generate block, it continues to
search higher-level modules until found. This fact means that tasks and
functions can use and modify the variables within the containing module
by name, without going through their ports."

Dave


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Steven
> Sharp
> Sent: Monday, August 29, 2005 4:56 PM
> To: Vreugdenhil, Gordon
> Cc: Mark.Hartoog@synopsys.com; sv-bc@eda.org
> Subject: Re: [sv-bc] Search order for functions/tasks in modules,
$unit
> and packages
> 
> BTW, I don't think that the ability to refer to tasks and functions
that
> have not been declared yet is due to a special "forward reference"
rule.
> I think it is due to a special and nonstandard "upward reference"
rule.
> 
> Verilog-XL allows references to tasks and functions that have not been
> declared in the module, and treats them as if they were hierarchical
> names, searching upward for them in the design hierarchy.  This allows
> tasks and functions to be declared in a top-level module, but used
with
> simple names, giving much the same effect as a package.  This is not
> specified in the 1364 LRM, but many tools support it because XL does.
> I believe that the "forward reference" case probably just falls out
from
> this.  If there is a reference to a task or function that is declared
> later, then it is treated as if it is not declared in the module.
Then
> the upward search in the design hierarchy starts with the current
scope,
> and finds the declaration in the current module.
> 
> This special "forward reference" case is causing problems with the
search
> order, and the full general "upward reference" case would cause even
more.
> 
> If you want to stick to the letter of the standard, then tasks and
> functions
> can't be used before being declared, exactly like parameters and
> variables.
> This makes their search order the same as parameters and variables.
It
> also means that a lot of legacy Verilog code that relies on forward
> references won't work in a SystemVerilog tool that uses the standard
> search order.
> 
> If you want to accept the de facto standard of full "upward
reference",
> then you have to figure out where that falls in the search order too.
> That could get messy.  However, this is the only way to get
compatibility
> with legacy code that might rely on "upward reference".
> 
> What people have been discussing so far has effectively accepted the
> nonstandard "forward reference" special case, without the general case
> that it comes from.  There is some merit to this, since the "forward
> reference" case is probably a lot more common than full "upward
> reference."
> However, taking this approach means that the rules being discussed are
> not compatible with either the official or the de facto Verilog
standards.
> 
> Steven Sharp
> sharp@cadence.com