elaborating a function call

[Mike]

Hi,

In my small example below, I get an error when trying to call function
f(). However, if I comment out the line indicated below, then I get no
errors.

According to the 1364-1995 spec, section 3.11 Name Spaces, I did not
violate any rule when defining wire "f' in module "b" because function
"f" is defined in a different module. Also, the declaration of wire
"f" is later in the source than the call to function "f". So, is there
something that I am missing about how the call to function "f" in
module "b" is elaborated?

Thanks in advance,
Mike
---------------------
module a;
b b();
function f;
input i;
f = i;
endfunction
endmodule

module b;
wire w = f(1'b0);
wire f = 1'h1; // no error if this line commented out
initial
$display("%b", w);
endmodule
-------------------------
Compiling source file "0.v"

Error! Identifier (f) not a task or function
[Verilog-INOTF]
"0.v", 10: f(1'b0);

Error! Identifier (f) not a task or function
[Verilog-INOTF]
"0.v", 10: f(1'b0);
2 errors
End of Tool: VERILOG-XL 05.70.001-s Aug 14, 2006 22:53:04

 

[Ajeetha]

Mike,
Verilog has this scope resolution mechanism which is little
involved, I don't claim to have digested the whole thing. But briefly:

1. If function "f" is not resolved in current scope, go one level above
and look for it (and keep continuing till you reach top most level).
2. In your case, since your module b has a local "f" declared and is
not a function/task as expected by your "wire w = f(1'h0)" line, the
error.

FWIW - SystemVerilog tried cleaning this with $root and $unit.

Does that help?

Regards
Ajeetha, CVC
www.noveldv.com
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
http://www.systemverilog.us/
* SystemVerilog Assertions Handbook
* Using PSL/Sugar

Mike wrote:
> Hi,

 

[EdA]

Right, I was able to get it to compile this way:

wire w = a.f(1'b0);

Yet if I moved the function definition to module b then my compiler
complained that 'f' was previously declared as a wire.

/Ed

Ajeetha wrote:

Mike,
Verilog has this scope resolution mechanism which is little
involved, I don't claim to have digested the whole thing. But briefly:

1. If function "f" is not resolved in current scope, go one level above
and look for it (and keep continuing till you reach top most level).
2. In your case, since your module b has a local "f" declared and is
not a function/task as expected by your "wire w = f(1'h0)" line, the
error.

FWIW - SystemVerilog tried cleaning this with $root and $unit.

Does that help?

Regards
Ajeetha, CVC
www.noveldv.com
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
http://www.systemverilog.us/
* SystemVerilog Assertions Handbook
* Using PSL/Sugar

Mike wrote:
Hi,

 

[Mike]

Let me clarify a little. I am writing a compiler for an
internal tool, so I am not interested in making my example
compile, but I am more interested in knowing why
my example does not compile on verilog-xl.

In my example
it seems that the function call is elaborated more like a
hierarchical reference. I say this because at the point
in the source where the function call is made, the wire
"f" is not declared yet, so, I though the compiler would
search up the scope tree to find function"f" in
module "a'. Then later, wire "f" is declared, which should
be fine because these two "f"'s are in different scopes.

But it looks like the whole scope tree is formed with
all of its variable declarations (like my wire "f") first,
and then later the function call is looked up like
a hierarchical reference, finds the id "f" at the current
scope, and then realizes that this "f" is a wire and complains.

Ajeetha wrote:

Mike,
Verilog has this scope resolution mechanism which is little
involved, I don't claim to have digested the whole thing. But briefly:

1. If function "f" is not resolved in current scope, go one level above
and look for it (and keep continuing till you reach top most level).
2. In your case, since your module b has a local "f" declared and is
not a function/task as expected by your "wire w = f(1'h0)" line, the
error.

FWIW - SystemVerilog tried cleaning this with $root and $unit.

Does that help?

Regards
Ajeetha, CVC
www.noveldv.com
* A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
http://www.systemverilog.us/
* SystemVerilog Assertions Handbook
* Using PSL/Sugar

Mike wrote:
Hi,

 

[Ajeetha]

Mike,

But it looks like the whole scope tree is formed with
all of its variable declarations (like my wire "f") first,
and then later the function call is looked up like
a hierarchical reference, finds the id "f" at the current
scope, and then realizes that this "f" is a wire and complains.

AFAIK elab is a step after compile/parse and hence your
observation is valid and that also means that your original assumption
is invalid.

Reagrds
Ajeetha

Mike wrote:

Let me clarify a little. I am writing a compiler for an
internal tool, so I am not interested in making my example
compile, but I am more interested in knowing why
my example does not compile on verilog-xl.

In my example
it seems that the function call is elaborated more like a
hierarchical reference. I say this because at the point
in the source where the function call is made, the wire
"f" is not declared yet, so, I though the compiler would
search up the scope tree to find function"f" in
module "a'. Then later, wire "f" is declared, which should
be fine because these two "f"'s are in different scopes.

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike wrote:

But it looks like the whole scope tree is formed with
all of its variable declarations (like my wire "f") first,
and then later the function call is looked up like
a hierarchical reference, finds the id "f" at the current
scope, and then realizes that this "f" is a wire and complains.

That is right. The implications are that you can reference
symbols declared anywhere in the module. You'll have to go through
the passes.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE4iOFrPt1Sc2b3ikRAkPpAJ9o5O+2pASIpCiJkF+aEv2SzgtnqgCfeIcz
TVeNoET+TJ5/UMcpWRUCJys=
=AlwK
-----END PGP SIGNATURE-----

 

Mike wrote:

In my example
it seems that the function call is elaborated more like a
hierarchical reference.

Yes, an unresolved task or function call is treated exactly
like a hierarchical reference. This appears to have been
an attempt to give behavior much like packages, allowing
commonly used tasks and functions to be put into a top-level
module and used with simple names from anywhere in the
design. Some people mistakenly think that Verilog allows
forward references to tasks and functions declared later in
the module, but this is just a side-effect of the resolution
of the hierarchical reference in the local module first.

I say this because at the point
in the source where the function call is made, the wire
"f" is not declared yet, so, I though the compiler would
search up the scope tree to find function"f" in
module "a'.

It cannot do this, since the hierarchy is not elaborated
yet. Also, the resolution could be different for different
instances of the module. This is clearer in tools other
than Verilog-XL, which make compiling and elaborating
separate steps.

But it looks like the whole scope tree is formed with
all of its variable declarations (like my wire "f") first,
and then later the function call is looked up like
a hierarchical reference, finds the id "f" at the current
scope, and then realizes that this "f" is a wire and complains.

You are exactly right.