C++ Object life cycle through SV DPI

S

Shenli

Guest
Hi all,

I have a C++ Object life cycle through SV DPI problem.

For example, I have a C++ reference model class named ALU. Only one
public function revealed to client (e.g. ALU::ALU_EXEC) and was
encapsulated in DPI(ALU_EXEC_DPI) . And there are two types of ALU
commands was entered to ALU::ALU_EXEC. One is setup ALU parameters
(i.e. setup the ALU class private member) , the other is calculating
the result.

The question is when I leave DPI, the ALU object is eliminated and all
the setup parameter is cleared, right? So can I keep a C++ Object even
after I leave DPI (i.e. is the C++ Object life cycle only as long as
DPI call life cycle).

My friend suggest me to return all the ALU parameter out to SV and re-
enter these parameters to ALU through ALU_EXEC_DPI when I call the ALU
reference model. But it may break the model encapsulation :(

May be my question is not very clear and any suggestions are welcome!
Davy
 
On 16 May 2007 20:10:40 -0700, Shenli <zhushenli@gmail.com> wrote:

Hi all,

I have a C++ Object life cycle through SV DPI problem.
Click to expand...
That's what the "chandle" data type in SystemVerilog is
intended to deal with. You should be able to create an
object in your C freestore, get a pointer to it, and pass
that pointer back from C to SV as a "chandle" argument.
SystemVerilog permits you to store and copy a value of
chandle data type, but you can't do anything with it
so there's no risk of the pointer getting damaged.
Next time you call out to the DPI, pass the chandle
value to your C function and you have a reference to
your stored object all over again.

Obviously, all this needs managing with some care in
C++ because of the whole name mangling and calling
convention business, but judicious use of "extern C"
directives in your C++ code should do the trick.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On May 17, 4:09 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On 16 May 2007 20:10:40 -0700, Shenli <zhushe...@gmail.com> wrote:

Hi all,

I have a C++ Object life cycle through SV DPI problem.

That's what the "chandle" data type in SystemVerilog is
intended to deal with. You should be able to create an
object in your C freestore, get a pointer to it, and pass
that pointer back from C to SV as a "chandle" argument.
SystemVerilog permits you to store and copy a value of
chandle data type, but you can't do anything with it
so there's no risk of the pointer getting damaged.
Next time you call out to the DPI, pass the chandle
value to your C function and you have a reference to
your stored object all over again.

Obviously, all this needs managing with some care in
C++ because of the whole name mangling and calling
convention business, but judicious use of "extern C"
directives in your C++ code should do the trick.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Click to expand...
Hi Jonathan,

Thank you so much :)

I am curious about how will the simulator deal with Chandle. I guess
if I declear Chandle outside the DPI function, the memory space that
Chandle point to will be kept even we return from DPI function (and
the DPI function stack is cleared at the same time), right?

I found it hard to understand Cadence tools note:
Cited from Cadence IUS SystemVerilog Document:
Note: A chandle pointer cannot be relocated by the simulator, because
it points directly into
user memory. When you restart a snapshot, chandle pointers restore the
value they had
when the snapshot was last saved. This might cause unexpected behavior
if your DPI code
tries to deference a chandle pointer after a restore operation,
because the chandle pointer
might have changed since the last save operation. A warning message is
issued when you
try to restore a snapshot that contains chandle pointers.

I wonder "the pointer cannot be relocated by the simulator" mean your
"simulator cannot manipulate the pointer directly", right?
But what's "the chandle pointer might have changed since the last save
operation" mean? It can only be changed by DPI C/C++ code, right?

Best regards,
Davy
 
On 17 May 2007 19:30:01 -0700,
Shenli <zhushenli@gmail.com> wrote:

I am curious about how will the simulator deal with Chandle. I guess
if I declear Chandle outside the DPI function, the memory space that
Chandle point to will be kept even we return from DPI function (and
the DPI function stack is cleared at the same time), right?
Click to expand...
I think that is a reasonable summary, yes. The simulator will
do *nothing* to the chandle. It's just a way to get the Verilog
code to remember a pointer value that the C code will need
the next time it runs.

But what's "the chandle pointer might have changed since the last save
operation" mean? It can only be changed by DPI C/C++ code, right?
Click to expand...
I think the idea is this: If you use the simulator's checkpoint
and restore feature, it reliably saves and restores all state
of the simulation, but it does NOT reliably save and restore the
state of external DPI code. So, any chandle variables will be
given the exact same value (address) that they had on the
earlier, saved run; but, of course, there is no reason why
that pointer should now be pointing to anything sensible.

Maybe someone who is more expert than I with the DPI can
comment further, but I think that's roughly the deal.

Note that when you use the VPI or PLI, your C code can
be automatically informed about simulator start/stop/save/restore
activity through PLI callbacks. In this way it's easy to write
a PLI application that will correctly put itself back together
after a restore. I'm not sure how you can get the same effect
using the DPI, if you have used chandles to save pointers to
persistent objects in C.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Jonathan Bromley wrote:
On 17 May 2007 19:30:01 -0700,
Shenli <zhushenli@gmail.com> wrote:

But what's "the chandle pointer might have changed since the last save
operation" mean? It can only be changed by DPI C/C++ code, right?

I think the idea is this: If you use the simulator's checkpoint
and restore feature, it reliably saves and restores all state
of the simulation, but it does NOT reliably save and restore the
state of external DPI code. So, any chandle variables will be
given the exact same value (address) that they had on the
earlier, saved run; but, of course, there is no reason why
that pointer should now be pointing to anything sensible.
Click to expand...
Yes, Jonathan has it exactly right.

Note that this NC-Verilog documentation is not intended to teach the
SystemVerilog language, such as how chandles work in general. It
assumes that you know the language, and just need to know tool-
specific things, like how the save/restart mechanism interacts with
chandles.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top