What should be value of the b ( $display (b) ) here

  • Thread starter parag_paul@hotmail.com
  • Start date
P

parag_paul@hotmail.com

Guest
PLease look at the verilog below,
What should be the value of b in the funcitno call,
m1.foo()
it is a hierarchial reference, According to LRM , the default value
should be resolved from the subroutine where the function is declared.


module M1;
parameter int a = 5;

function void foo(int b = a); //CASE 1
//function void foo(int b = M2.a); //CASE 2
//function void foo(int b = M3.a); //CASE 3
$display(b);
endfunction
endmodule

module M2;
parameter int a = 10;

M1 m1();
initial m1.foo();
endmodule

module M3;
parameter int a = 20;
endmodule
 
On Sun, 17 Jun 2007 07:21:52 -0000, "parag_paul@hotmail.com"
<parag_paul@hotmail.com> wrote:

PLease look at the verilog below,
Click to expand...
SystemVerilog, surely?

What should be the value of b in the funcitno call,
m1.foo()
it is a hierarchial reference, According to LRM , the default value
should be resolved from the subroutine where the function is declared.
Click to expand...
Indeed. The relevant LRM statement is

The [default argument] expression is evaluated in the scope
containing the subroutine declaration each time a call
using the default is made.

module M1;
parameter int a = 5;

function void foo(int b = a); //CASE 1
//function void foo(int b = M2.a); //CASE 2
//function void foo(int b = M3.a); //CASE 3
$display(b);
endfunction
endmodule

module M2;
parameter int a = 10;

M1 m1();
initial m1.foo();
endmodule

module M3;
parameter int a = 20;
endmodule
Click to expand...
so, the LRM-mandated result should be...

case 1: b=5 (parameter M1::a)
case 2: b=10 (hierarchical reference to $root.M2.a)
case 3: b=20 (hierarchical reference to $root.M3.a)

Case 2 is OK because M2 is the parent of M1, so the
reference resolves by the usual upwards hierarchical
name mechanism. Case 3 is OK because M3 is a parallel
top-level and the reference M3.a is treated as a
top-level or absolute hierarchical reference.

I think you are probably treading on thin ice here; there
was an extensive, heated and largely inconclusive discussion
of this on the SV-BC email reflector around March 2005 -
see the thread
Serious issue with default expressions for
task and function arguments
which you can find at http://www.eda.org/sv-bc/hm/2734.html

Personally, I would be very careful to avoid any default
argument expression that was not a simple local constant.
I have not tried your example in any tools, and I don't
plan on doing so any time soon.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Jun 17, 3:51 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Sun, 17 Jun 2007 07:21:52 -0000, "parag_p...@hotmail.com"

parag_p...@hotmail.com> wrote:
PLease look at the verilog below,

SystemVerilog, surely?

What should be the value of b in the funcitno call,
m1.foo()
it is a hierarchial reference, According to LRM , the default value
should be resolved from the subroutine where the function is declared.

Indeed. The relevant LRM statement is

The [default argument] expression is evaluated in the scope
containing the subroutine declaration each time a call
using the default is made.



module M1;
parameter int a = 5;

function void foo(int b = a); //CASE 1
//function void foo(int b = M2.a); //CASE 2
//function void foo(int b = M3.a); //CASE 3
$display(b);
endfunction
endmodule

module M2;
parameter int a = 10;

M1 m1();
initial m1.foo();
endmodule

module M3;
parameter int a = 20;
endmodule

so, the LRM-mandated result should be...

case 1: b=5 (parameter M1::a)
case 2: b=10 (hierarchical reference to $root.M2.a)
case 3: b=20 (hierarchical reference to $root.M3.a)

Case 2 is OK because M2 is the parent of M1, so the
reference resolves by the usual upwards hierarchical
name mechanism. Case 3 is OK because M3 is a parallel
top-level and the reference M3.a is treated as a
top-level or absolute hierarchical reference.

I think you are probably treading on thin ice here; there
was an extensive, heated and largely inconclusive discussion
of this on the SV-BC email reflector around March 2005 -
see the thread
Serious issue with default expressions for
task and function arguments
which you can find athttp://www.eda.org/sv-bc/hm/2734.html

Personally, I would be very careful to avoid any default
argument expression that was not a simple local constant.
I have not tried your example in any tools, and I don't
plan on doing so any time soon.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Click to expand...
hi Jonathan
is there any way we can gain access to the SV bc discussions and do a
search on all the topics.
How did just procure one chain of discussions from hundreds
-Parag
 
On Mon, 18 Jun 2007 01:14:39 -0000,
<parag_paul@hotmail.com> wrote:

[Jonathan]
... there
was an extensive, heated and largely inconclusive discussion
of this on the SV-BC email reflector around March 2005 -
see the thread
Serious issue with default expressions for
task and function arguments
which you can find at http://www.eda.org/sv-bc/hm/2734.html
Click to expand...
[Parag]
How did just procure one chain of discussions from hundreds
Click to expand...
Hah! Only because I have been tracking the discussions for
over three years, and I knew roughly what I was looking for.

Anyone can see the entire email archive at
www.eda.org/sv-Xc/hm/
where X is one of a (assertions), b (basic language),
c (C language interface - PLI), or e (extensions -
OOP and testbench). However, searching that archive
is very far from easy. Good luck.....
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top