Subject: RE: DirectC: C layer
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Dec 17 2002 - 08:08:59 PST
my comments in blue.
\At 10:29 AM 12/15/2002 -0800, Kevin Cameron wrote:
> > From: "Warmke, Doug" <doug_warmke@mentorg.com>
> >
> >
> > Team,
> >
> > Some more discussion regarding the update of
> > output arguments is embedded. Please read below.
> >
> > Regarding Joao's discussion of our original goals,
> > I totally agree - we need to optimize convenience
> > and performance. Here is yet another way to think
> > about the goals of our SVC interface:
> >
> > The user's code on the C-side should look as much as possible
> > like a natural C function. In natural C functions, one doesn't
> > need to call special system-provided API's to propagate output
> > values to their destinations. Same with natural SV functions
> > for that matter. Our SVC standard should try to meet
> > this "naturalness" requirement as much as possible.
> > Otherwise, why not just stick with PLI?
>
>PLI/VPI is an abstract access method. It's all you can do when
>the simulator data is not mapped to memory in a consistent manner.
>
>The logical step forward is to move to a C++ based coding style
>for the VPI/PLI functionality so the interface can stay abstract
>but be handled more efficiently and (C++) users will understand
>it easily.
>
>There are too many legacy simulators around that are too difficult
>to re-engineer to make using a direct memory interface practical.
A direct memory interface may also restrict the optimizations on the SV side
since it reveals the internal memory layout which will need to stay stable.
>If I was going to write a simulator from scratch I would certainly
>endevor to provide as many direct interfaces as possible. However,
>having a standard that is only implemented by one or two vendors
>is not useful, it needs to be implementable by everyone (in reasonable
>time).
>
> > Note that this "naturalness" is inherent in the current mixed
> > VHDL/Vlog implementations in use today. I like sticking with
> > that established language-mixing use model as much as possible.
>
>Which standard is that?
There is no standard for mixed language
> > Futher, note that one of the main spirits of the 17 points is
> > that SV call sites of C functions should obey natural SV
> > syntax and semantics as well.
>
>It would be good to be able to call standard C library functions
>without (major) rewrites of all the header files, so I think the
>interface definition needs to support both styles (as much as
>possible).
>
>Kev.
>
>
> > I hope these arguments and this plea for "naturalness" sound
> > reasonable to most on the committee. I think we can achieve
> > this goal and still meet other concerns satisfactorily.
> >
> > More below...
> >
> > -----Original Message-----
> > From: Stickley, John
> > To: Francoise Martinolle
> > Cc: Andrzej Litwiniuk; sv-cc@server.eda.org
> > Sent: 12/13/2002 5:07 PM
> > Subject: Re: DirectC: C layer
> >
> > Francoise,
> >
> > Francoise Martinolle wrote:
> > > Andrzej,
> > >
> > > It was very difficult today to place any word during the meeting so
> > I am
> > > gathering my issues/comments in this email.
> > >
> > > I have 3 main issues with the proposal.
> > >
> > > The first one has to do with passing by reference the simulation
> > object
> > > value and that
> > > value be modified by the directC interface. When and how is the
> > > propagation of that value
> > > done? Wires and regs have fan out and updates to their values
> > should cause
> > > propagation and fanout. When does this happen? What about if there
> > is a
> > > force in effect on that
> > > object? Would the value be updated by the C code?
> >
> > johnS:
> > I don't think this would be a problem. While in the C function,
> > we've all agreed time advance is 0-time, correct ? So what would
> > happen is that the calling of the C function would be an instantaneous
> > call somewhere in the process activation phase of the SV simulation
> > cycle that would essentially block the kernel for the duration of
> > the call, much as PLI callbacks do today.
> >
> > DOUG: While the 0-time constraint does make things easier, it is
> > still not out of the question for an implementation to handle
> > output argument updates for time consuming functions in the future.
> > It is difficult, but essentially at each suspension point, the
> > temporaries used to store the current value of output arguments
> > would need to be flushed through into the system. (Exact same
> > actions as need to be taken when a 0-time function terminates
> > and returns to caller).
> >
> > The generated code representing the SV process that makes the function
> > call (I'm talking about an SV-to-C call now) will make the call which,
> > upon return, would update the output argument which could,
> > in turn, update the value of the nets as if the value had been
> > directly assigned with local, conventional blocking assign statement.
> > To me that's the easiest semantic to describe and understand.
> > Effectively the function acts as a combinatorial argument
> > transformation such one would see with direct blocking assignment.
> > If non-blocking semantics are desired, the function return or
> > output argument could simply become the source expression of a
> > non-blocking assignment on the SV side.
> >
> > Example:
> >
> > Continuous assignment:
> >
> > wire dest;
> > dest = my_ret_func( source );
> >
> > Blocking and non-blocking assignment w/ void function that has output
> > arg:
> >
> > reg dest;
> >
> > always @(posedge clk) begin
> > ...
> > my_void_func( source, dest ); // Blocking assign semantics to
> > dest
> > nb_dest <= dest; // Non-blocking assign of arg to nb_dest
> >
> > Blocking, assignment w/ non-void function that returns arg:
> >
> > reg dest;
> >
> > always @(posedge clk) begin
> > ...
> > dest = my_ret_func( source ); // Blocking assign semantics to
> > dest
> >
> >
> > Non-blocking, assignment w/ non-void function that returns arg:
> >
> > reg dest;
> >
> > always @(posedge clk) begin
> > ...
> > nb_dest <= my_ret_func( source ); // Non-blocking assign
> > semantics
> >
> >
> > So, unless I'm missing something, I don't see where the
> > pass-by-reference
> > semantic makes a difference here for the case of the void function
> > with an output arg. And for return args, the implication is always
> > return-by-value.
> >
> > DOUG: John - you've shown the easiest cases here.
> > In which the natural SV language mechanisms are used
> > to propagate output values into the system.
> > It is more difficult for implementations to handle
> > the void function with output argument case. In that
> > scenario, extra code would have to be generated that
> > would automatically update any nets to which the output
> > arguments are connected. IMO this is slightly troublesome
> > for implementations, but highly convenient for users.
> > Since the only alternative is to have the user explicitly
> > make API calls to propagate output values. And then we
> > are basically back at the inconvenience level of PLI/VPI,
> > whether or not we choose to use functions from those API's
> > or our own (as Kevin has suggested).
> >
> >
> > <rest of mail thread is snipped>
> >
> > Thanks and regards,
> > Doug
> >
This archive was generated by hypermail 2b28 : Tue Dec 17 2002 - 08:22:06 PST