Re: [sv-cc] another directC question - var, immediate propagation


Subject: Re: [sv-cc] another directC question - var, immediate propagation
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Feb 13 2003 - 12:39:13 PST


At 11:49 AM 2/13/2003 -0800, Kevin Cameron x3251 wrote:
> > From owner-sv-cc@server.eda.org Thu Feb 13 10:27:15 2003
> > From: "Andrzej Litwiniuk" <Andrzej.Litwiniuk@synopsys.com>
> > Subject: Re: [sv-cc] another directC question - var, immediate
> > propagation
> > To: fm@cadence.com
> > cc: sv-cc@server.eda.org
> >
> > > Supporting the equivalent of a var qualifier in a call to C would
> create a
> > > technical problem:
> > > we need to ensure that if the C code modifies a var argument, the new
> > > value of the modified object
> > > is immediately visible to C or Verilog (fanout needs to be
> propagated).
> > > The new value can no longer be updated after the function returns.
> > > What do you think?
> > > Francoise
> >
> >
> > I think that I don't understand the propagation issue.
> > External functions are assumed to execute in 0 simulation time.
> > In a sense, an external function is like a new, possibly complex,
> arithmetical
> > operation (user defined) that computes its result(s) instantly.
> > ---------
> >
> > Therefore a propagation after return seems to be semantically equivalent to
> > the immediate propagation.
> >
>
>I think the problem is the same as with array access: if you access things
>directly through pointers it's inefficient to work out what has changed and
>needs to be propagated unless you do writes through an API.
>
>If you use an API you can get blocking assignment behavior as you would in
>SV, if you don't you'll need to do a comparison of data on return and do
>an unordered propagation (if you do any at all) - the lack of order makes
>it semantically different.
>
>V "var" argument can be just passed as a PLI/VPI handle instead of a pointer
>too, so you only get to access the data indirectly.
>
>Kev.
>
> >
> > Consider the following example:
> >
> > assign a = b;
> > initial begin
> > b = 0;
> > #0
> > // a is 0
> > b = 1;
> > // a continues to be 0
> > c = a;
> > // c is 0
> > #0
> > // only now a is 1
> > end
> >
> > (I hope I got the semantics right.)
> > For me, an external call and a complete execution of C function
> > is not different from the uninterruptable sequence 'b = 1;c = a;',
> where 'c' is
> > assigned the old value of 'a' because the new value of 'b' hasn't
> propagated
> > yet. Do you agree?
> >

Yes you could say that but this will be different from the behaviour of
Verilog function
of which one argument is passed as var.

> >
> > You are right with the immediate visibility of the new value of an argument
> > passed by ref, though it may create problems (for C) with aliases, if
> > the same object is passed by var for two formal arguments.

Exactly:
extern void myCfunc(var logic a, var logic b);

and you call in SV:
reg r;
initial
begin
   r = 1'b0;
   myCfunc(r, r);
endinitial

You cannot truly have var arguments of simulation objects in C code.

> >
> > Andrzej
> >
> >



This archive was generated by hypermail 2b28 : Thu Feb 13 2003 - 12:39:58 PST