Subject: Re: [sv-ec] clarifications needed on the passing by reference argument
From: Dave Rich (David.Rich@synopsys.com)
Date: Tue Feb 18 2003 - 18:45:49 PST
Hi Francoise,
I am answering this for Arturo because I just had a similar exchange
with someone on this very topic.
The primary goal of adding pass by reference to SystemVerilog is so
that tasks can block waiting for a change on one of its arguments, and
so that tasks can change one of its arguments before returning. A side
benefit of this is that you can perform non-blocking assigns to
arguments of a task.
Think of pass by reference as passing a hierarchical reference (XMR,
OOMR, NID) to the task/function. The semantics are the same as if you
had used the hierarchical reference directly from within the
task/function. The alternative is to create different version of a task
for each task call as show in this example:
module top; // SystemVerilog version (clocking detail omitted)
reg a,b,c1,c2;
initial begin
check(a,c1,0);
check(b,c1,1);
check(b,c2,0);
end
task check(ref bit v, ref bit c, reg w);
@(posedege c) v<=w;
@(posedege c) $display(v);
endtask
endmodule
module top; // Verilog expansion
reg a,b,c1,c2;
initial begin
check_a_c1(0);
check_b_c1(1);
check_b_c2(0);
end
task check_a_c1(reg w);
@(posedege top.c1) top.a<=w;
@(posedege top.c1) $display(top.b);
endtask
task check_b_c1(reg w);
@(posedege top.c1) top.b<=w;
@(posedege top.c1) $display(top.b);
endtask
task check_b_c2(reg w);
@(posedege top.c2) top.b<=w;
@(posedege top.c2) $display(top.b);
endtask
endmodule
Regarding the BNF, the SV-BC has already passed changes that merge
task/function argument productions. There should no longer be any
difference in the arguments for a task or function. I will take the
action to provide a merged BNF proposal for pass by name and default
argument value features.
Dave
Francoise Martinolle wrote:
>Arturo,
>
>We had some discussion today in the sv-cc committee about the new passing by
>reference mechanism for tasks, functions and modules. We are trying to
>determine if we need to support SV directC foreign functions which
>SV extern declarations have passing by reference parameters.
>The EC committee brought into SV3.1 the capability of passing by reference
>so I need to clarify a few things:
> 1. what was the primary goal of adding this to Verilog which
> is basically passed by copy? Why is this needed for the testbench?
> 2. A few people actually read the section in 3.1 about passing by
> reference and still have some questions about the semantics of
> passing by reference. We need to clarify the semantics of passing
> by reference with respect to 1) when does the object value is updated
> and 2)when does the fanout propagation occurs.
> The paragraph which relates to this is:
> "When the argument is passed by reference, both the caller and the callee subroutine share the same representation
> of the argument, so any changes made to the argument either within the caller or the callee subroutine will be visible to each other."
>
> I am looking for a detailed description of when the changes are made
> visible and when does the propagation occurs.
>
>
> 3. I see some inconsistency in the bnf of the task and functions. In
> In particular, I don't see the default value arguments neither in the
> function declaration or in the function prototype.
> I also do not see that the task_enable bnf allows passing by name.
> I think that the bnf adjustment to EC have been postponed to a later
> time however the bnf for task and functions is quite important for the
> directC interface as the C function declaration will be built upon the
> extern function verilog declaration.
> The cc committee is hoping to be able to build this upon the function
> prototype, this is the reason why we would like to see asap the bnf for
> function declarations, prototype and function enable settled.
> Can someone in the ec committee provide the actual bnf?
>
>
>Thanks in advance,
>
>Francoise
> '
>
>
>
>
>
>
>
>
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Tue Feb 18 2003 - 18:51:35 PST