Using SV DPI-C to model with OpenCV or DPI-C and pointers an

[fpgabuilder]

Hi,

In trying to create an image processing modeling environment, I
decided to leverage the DPI-C and OpenCV. One of the key aspects of
OpenCV is to be able to pass around a pointer (IplImage*) to a data-
structure that holds and describes an image. I am wondering if there
is a way for me to directly call the routines that create and
reference this structure over DPI-C. And if so how? So far I have been
unsuccessful with Modelsim.

In the code snippet below, cvLoadImage() creates the data-structure
and returns a pointer to it (IplImage*). In SV, I use chandle to
receive that pointer and pass it around to other routines. But I see
in Modelsim that the value of chandle is never updated. What do I have
wrong? My experience with DPI is pretty low.

import "DPI-C" function int cvNamedWindow (string name, int flags);
import "DPI-C" function chandle cvLoadImage (string name, int
iscolor);
import "DPI-C" function void cvShowImage (string name, chandle image);

chandle ldImg;
int ret;
initial
begin
ret = cvNamedWindow ("Test Win", 1);
ldImg = cvLoadImage("img_0.tif", 6); //4 = ANY_COLOR, 2 =
ANY_DEPTH
$display("Error loading Image %p", ldImg);
cvShowImage ("Test Win", ldImg);

end


The function prototype of cvLoadImage() in C is -

CVAPI(IplImage*) cvLoadImage( const char* filename, int iscolor
CV_DEFAULT(CV_LOAD_IMAGE_COLOR));


I appreciate any insights.

 

[Jonathan Bromley]

On Fri, 27 Aug 2010 10:03:38 -0700 (PDT), fpgabuilder wrote:

In the code snippet below, cvLoadImage() creates the data-structure
and returns a pointer to it (IplImage*). In SV, I use chandle to
receive that pointer and pass it around to other routines.

All sounds good so far. That's exactly what chandle variables
are supposed to do.

in Modelsim that the value of chandle is never updated.

I'm not exactly sure how you know this. In particular,
I am not at all sure that the result of displaying a chandle
with %p is well-defined.

import "DPI-C" function int cvNamedWindow (string name, int flags);
import "DPI-C" function chandle cvLoadImage (string name, int
iscolor);
import "DPI-C" function void cvShowImage (string name, chandle image);

chandle ldImg;
int ret;
initial
begin
ret = cvNamedWindow ("Test Win", 1);

Did that function return with a "success" code?

ldImg = cvLoadImage("img_0.tif", 6);
$display("Error loading Image %p", ldImg);

hmmm. My first stept would be to build a C wrapper
around each function, and call that (rather than the
bare library function) from DPI. If you #include the
usual Verilog "veriuser.h" file in it, you can use
the io_printf function to get some diagnostics
from your C code on to the simulator console -
in particular, check the arguments you got from
SystemVerilog look sensible, and display any
IplImage* argument or result as an integer.
And the wrapper could cast the IplImage* result
to void*, which would make me a little bit more
comfortable about putting it into a chandle
(although I suspect that's not really relevant).

Otherwise I don't really see what might be wrong,
but I don't know your image processing library
at all so I can't comment on whether you're
using it correctly or not.

Good luck
--
Jonathan Bromley

 

[fpgabuilder]

On Aug 29, 1:29 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

On Fri, 27 Aug 2010 10:03:38 -0700 (PDT), fpgabuilder wrote:
In the code snippet below, cvLoadImage() creates the data-structure
and returns a pointer to it (IplImage*). In SV, I use chandle to
receive that pointer and pass it around to other routines.

All sounds good so far.  That's exactly what chandle variables
are supposed to do.

in Modelsim that the value of chandle is never updated.

I'm not exactly sure how you know this.  In particular,
I am not at all sure that the result of displaying a chandle
with %p is well-defined.

import "DPI-C" function int cvNamedWindow (string name, int flags);
import "DPI-C" function chandle cvLoadImage (string name, int
iscolor);
import "DPI-C" function void cvShowImage (string name, chandle image);

 chandle ldImg;
 int ret;
 initial
   begin
     ret = cvNamedWindow ("Test Win", 1);

Did that function return with a "success" code?
Yes!

     ldImg = cvLoadImage("img_0.tif", 6);
     $display("Error loading Image %p", ldImg);

hmmm.  My first stept would be to build a C wrapper
around each function, and call that (rather than the
bare library function) from DPI.  If you #include the
usual Verilog "veriuser.h" file in it, you can use
the io_printf function to get some diagnostics
from your C code on to the simulator console -
in particular, check the arguments you got from
SystemVerilog look sensible, and display any
IplImage* argument or result  as an integer.
And the wrapper could cast the IplImage* result
to void*, which would make me a little bit more
comfortable about putting it into a chandle
(although I suspect that's not really relevant).

Otherwise I don't really see what might be wrong,
but I don't know your image processing library
at all so I can't comment on whether you're
using it correctly or not.

Good luck
--
Jonathan Bromley

Thanks for the insights Jonathan. I guess my post was a little bit
premature. Because, the problem was indeed with the image processing
library... it isn't able to read in a 32bit floating point grayscale
image in tiff format. I changed the image to a 16bit unsigned and the
code works as expected. i.e. chandle can receive and hold the pointer
and pass it to other functions. The display function displays a
pointer value. Good point about writing wrappers for diagnostic
information. Maybe that is what we will have to do... nevertheless,
I'd rather not because there are about 500 functions in the library
today. Besides, if I can access the data pointed to by the chandle
then I am good. I suspect, I would not need any diag information.
Which brings me to another doubt... is it possible that the simulator
can stomp on the data structure pointed to by chandle? SV does not
have any type information of the pointer. So how does it know that
the structure is 32KB and not 32B? Could it claim any space as
unoccupied that really is being used by the C function?

 

[Jonathan Bromley]

On Mon, 30 Aug 2010 10:23:50 -0700 (PDT), fpgabuilder wrote:

Which brings me to another doubt... is it possible that the simulator
can stomp on the data structure pointed to by chandle? SV does not
have any type information of the pointer. So how does it know that
the structure is 32KB and not 32B?

It doesn't, but I don't see why that should matter. SV itself
never makes use of a chandle as a pointer ; it merely remembers
the chandle so that it can be given back to another C function
some time later. The structure your chandle points to is on the
heap, and SV has no idea where it is; any memory that SV claims
will be allocated somewhere else. So I don't think you have
anything to worry about from SV.

What your C code does with its own pointer arithmetic,
of course, is a matter between you and your conscience

Point taken about not wanting to write wrappers for
a zillion different library functions. I was thinking
more about "desperation diagnostics". I sincerely hope
your image processing library never sends anything to
stdout, because the fate of such output is pretty
uncertain in the DPI environment!

By the way, thanks for giving us the heads-up on OpenCV.
I wasn't aware of it, and it looks like a nice thing to
have in the toolbag. Now, who's up for writing a set of
Tcl/Tk bindings for it???

cheers
--
Jonathan Bromley

 

[fpgabuilder]

On Aug 30, 1:10 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

On Mon, 30 Aug 2010 10:23:50 -0700 (PDT), fpgabuilder wrote:
Which brings me to another doubt... is it possible that the simulator
can stomp on the data structure pointed to by chandle?  SV does not
have any type information of the pointer.   So how does it know that
the structure is 32KB and not 32B?

It doesn't, but I don't see why that should matter.  SV itself
never makes use of a chandle as a pointer ; it merely remembers
the chandle so that it can be given back to another C function
some time later.  The structure your chandle points to is on the
heap, and SV has no idea where it is; any memory that SV claims
will be allocated somewhere else.  So I don't think you have
anything to worry about from SV.

What your C code does with its own pointer arithmetic,
of course, is a matter between you and your conscience

Point taken about not wanting to write wrappers for
a zillion different library functions.  I was thinking
more about "desperation diagnostics".  I sincerely hope
your image processing library never sends anything to
stdout, because the fate of such output is pretty
uncertain in the DPI environment!

By the way, thanks for giving us the heads-up on OpenCV.
I wasn't aware of it, and it looks like a nice thing to
have in the toolbag.  Now, who's up for writing a set of
Tcl/Tk bindings for it???

cheers
--
Jonathan Bromley

Thanks again.
Most (atleast the ones that I deal with) of the functions in OpenCV
manipulate images, matrix and array manipulators. And these functions
return a status value or flag which can be queried again separately
using another function for an error message. There are a few
functions such as cvLoadImage() that only return a null pointer on
fail.

Don't think there is one for TCL yet. There is a Python binding for
it... http://opencv.willowgarage.com/documentation/python/introduction.html