Subject: Re: [sv-cc] another directC question - var, immediate propagation
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Feb 13 2003 - 11:49:28 PST
> 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?
>
>
> 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.
>
> Andrzej
>
>
This archive was generated by hypermail 2b28 : Thu Feb 13 2003 - 11:50:06 PST