Adding reference into a record type

[Tricky]

I have an image type declared:

type image_int_1D_t is
array(integer range <>) of natural range 0 to 255;

and a type containing image dimensions:

type image_dimensions_t is
record
width : natural;
height : natural;
end record image_dimensions_t;

Is there anyway I can add a reference to the image data in the record.
Obviously the problem is I cant size the array until it is actually
used, so I cannot constrain the array in the record type
"image_dimensions_t".

I thought I could use an access type to point to an "image_int_1D_t"
as an element in the record, but then I have problems 2 fold:

How can I actually access data in the array via the pointer?
I already have functions based on the type, rather than an access
type, so i would have to copy them to use an access type as a
parameter. If I could access the data via the pointer, this would not
be needed?

Or am I going past the scope of access types in VHDL, and thinking too
much like C?

A second question: which standard of VHDL allows unconstrained 2D
arrays (unconstrained in both dimensions). My Modelsim (altera 6.1g)
only seems to allow up to VHDL 2002, and either it doesnt allow them
or I am declaring the types wrong (I expect the former, and can work
around it). Could someone explain, as an image is naturally a 2D
array.

Thanks for any help

 

[Tricky]

PS. This is all testbenching stuff, so not worries about synthesis.

 

[KJ]

I have an image type declared:

type image_int_1D_t is
    array(integer range <>) of natural range 0 to 255;

and a type containing image dimensions:

type image_dimensions_t is
    record
      width   : natural;
      height  : natural;
    end record image_dimensions_t;

Is there anyway I can add a reference to the image data in the record.

The straight forward way would be to define a new type and then add
the new record element...
type image_dimensions_t is
record
ptrdata : t_ptr_image_data;
width : natural;
height : natural;
end record image_dimensions_t;

Where the new type might be defined as a pointer...
Example: type t_ptr_image_data is access arr_t_pixels;

to an array of pixels defined as...
Example: type arr_t_pixels is array(natural range <>) of t_pixels;

And maybe the pixels are a subtype of integer, or perhaps it's own RGB
structure, however it is you want to represent pixels.
Example: subbypte t_pixels is integer range 0 to 255

Obviously the problem is I cant size the array until it is actually
used, so I cannot constrain the array in the record type
"image_dimensions_t".

By defining new types you won't need to constrain any dimensions.

I thought I could use an access type to point to an "image_int_1D_t"
as an element in the record, but then I have problems 2 fold:

How can I actually access data in the array via the pointer?

x.ptrdata(5) (to access element '5' from the above mentioned 1d array.

Obviously you would want some functions to compute the 1d offset from
a pixel (x,y) position to make your code a bit more readable, but that
shouldn't be difficult.

I already have functions based on the type, rather than an access
type, so i would have to copy them to use an access type as a
parameter. If I could access the data via the pointer, this would not
be needed?

I'm not exactly sure what you mean here, but the syntax for accessing
an element of an array is the same whether you have a constrained
array or a pointer (see above example). The difference is 'hidden' in
that you've defined new types so all the old stuff would need to be
recompiled, but it *should* be fairly easy to convert.

Since you're using this for a testbench you might also consider using
protected types. This allows you to hide a lot of the gory details
and simply expose method functions. In your case perhaps methods like
'get_pixel', 'set_pixel', would be useful. Making that leap though
can ripple into a bit more rework of your existing stuff so it might
not be appropriate, just thought I'd mention it.

Kevin Jennings

 

[Tricky]

Unfortnalty, Ive just reaslised that the image and dimension types I
have declared are more likely to be than variables, which rules out
pointers. (They are mainly to be used for UUT stimulus). Although
having protected types would encapsulate it neatly and give a sensible
control mechanism, it is not worth the effort of having 2 versions of
everything Ive done already, as they are already pretty straight
forward.

I'm not exactly sure what you mean here, but the syntax for accessing
an element of an array is the same whether you have a constrained
array or a pointer (see above example). The difference is 'hidden' in
that you've defined new types so all the old stuff would need to be
recompiled, but it *should* be fairly easy to convert.

Here I meant that I want to pass the entire array into a function
rather than single elements. I have declared the function to use the
actual type rather than a pointer to it, so I would have to have 2
copies of the same function for access and direct versions.

I like the idea of indexing functions though (to index the 1D array as
if it were 2D). Ill have a look.

Thanks for your quick response KJ

 

[KJ]

Unfortnalty, Ive just reaslised that the image and dimension types I
have declared are more likely to be than variables, which rules out
pointers. (They are mainly to be used for UUT stimulus).

I'm not sure I follow that at all. Whenever either of the image
dimensions change, you would have to simply deallocate the current
image pointer (if not null already) and then allocate a new one with
'new'.

Here I meant that I want to pass the entire array into a function
rather than single elements. I have declared the function to use the
actual type rather than a pointer to it,

The only thing that would need to change those is the type defined on
the interface to the functions. The actual body of the functions
where you actually access something wouldn't change at all so that's
one change per function. Plus, if your functions are working with the
record type now they wouldn't need to change at all (but I gather that
this is probably not the case).

so I would have to have 2
copies of the same function for access and direct versions.

I would look at it, that the new 'pointerized' versions would be the
only thing I would use going forward so while technically there would
be 'two' versions, the older 'direct' one would only be used to
quickly create the new pointer version, I wouldn't bother using the
'direct' ones anymore. It does what it does, it still can be used by
any already working legacy code, new stuff though wouldn't use it.

Depending on what your testbench is testing, records containing
'image' data can get pretty large, pretty quickly. As you pass
variables containing such record types into functions you can find
yourself crashing because you run out of stack space for your
simulator. By using a pointer in the record, you avoid that problem.
Granted, most testbenches work and verify just fine with tiny images,
but that's not always the case.

KJ