Subject: Re: [sv-cc] DirectC: supporting references in DirectC
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Feb 28 2003 - 12:11:23 PST
I also agree with Andrzej of not supporting passed by reference in C
foreign functions.
I asked the EC committee what was the motivation. It was not performance
but rather
providing an easier modelling style for tasks.
It appears to me that providing pass by reference in tasks, allows someone to
write a piece of Verilog code which can be embedded in a task and which
can be reused in several pieces of the hierarchy.
The approach without the pass by reference requires code with hierarhical
references
to objects which prevent reuse.
Here is the exact response from Dave Rich to my questions submitted to the EC.
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
For our purpose, passing objects by reference to C odes not buy us anything
since
the C function cannot wait and executes in 0 time.
Rather passing by reference is going to cause us problems if two actual
parameters of the
functions are exactly the same object passed by reference, because a C
assignment
to the first one should be reflected to the second one immediately and
should be visible
in the C code.
Francoise
'
At 10:54 AM 2/28/2003 -0500, Andrzej Litwiniuk wrote:
> > I have heard nobody in favor of supporting references (besides Kevin,
> and I am even not sure here), therefore I have already asked
> > Swapnajit/Ghassan to start a poll on this. We should get closure on
> this as soon as possilbe, because it relates to other
> > committees, which might make the stuff even more complicated.
> >
> > -Michael
>
> > > I'm hoping we can get closure on references pretty soon,
> > > i.e. don't support them. Depending on how that turns out,
> > > you probably need to communicate that in your requirements
> > > to sv-ec, Joao.
> > >
> > > Doug
>
>
>1. I'm against supporting references (formal args qualified as 'ref')
> for DirectC.
> The decision whether to support 'ref' is not isolated one.
> If 'ref' is decided to be supported, C Layer will have to be re-worked.
>
>2. I can only guess the motivation and rationale for 'ref' in SV.
>
> Most obvious is the performance, but this is already addressed with
> our C Layer solution, which actually uses passing by references
> whenever it matters.
>
> There are also some semantical consequences of using 'ref' instead
> of inout, visible mainly for aliases. But IMO this is very bad programming
> style that should be discouraged rather than endorsed by providing
> explicit support.
>
>Regards,
>Andrzej
This archive was generated by hypermail 2b28 : Fri Feb 28 2003 - 12:13:33 PST