Subject: Re: [sv-ec] clarifications needed on the passing by reference argument
From: Dave Rich (David.Rich@synopsys.com)
Date: Fri Feb 21 2003 - 08:57:23 PST
Francoise,
Propagation happens exactly as if you had assigned the hierarchical
reference directly in the task. So if you want to block the task and
execute continuous assigns, you are free to do so.
Dave
Francoise Martinolle wrote:
> Dave,
>
> thank you for the rational behind this.
> It turns out from your explanation that not just testbench would
> benefit from passing by reference.
>
> What about my question about when does propagation happen?
> Can the behavioural code of the task be interrupted and execution of
> the continuous assignment occurs instead ?
>
> If you have the following:
>
> module m
> reg v,c,w;
> wire w;
> assign w = c;
> initial
> c = 0;
> v = 1;
> check(v, c);
> endinitial
>
>
>> task check(ref bit v, ref bit c);
>> c = v;
>
> $display(c);
> $display(v);
> c = 0;
> $display(c);
> $display(v);
>
>> endtask
>> endmodule
>
>
>
>
> At 06:45 PM 2/18/2003 -0800, Dave Rich wrote:
>
>> 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
>>
>>
>
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Fri Feb 21 2003 - 08:58:35 PST