RE: [sv-bc] packed integer arrays

Steven,

Your suggestion for DPI's treatment of small sized vectors
is not possible.  The reason being is that it would be impossible
to write generic C code that could handle any width of 2- or 4-state
vector.

Consider:

// SV Code
module m;
   parameter W = 40;
   import "DPI-C" function void f (input bit [W-1:0] i);
   initial f();
endmodule

// C Code

// Should this be:
void f(const svBitVecVal* i)
{
   ...
}

// Or should it be:
void f(<your choice of long long, int, short, char> i)
{
   ...
}

This was debated at length in SV-CC during P1800 development
and is tracked in Mantis #274 and associated mail threads
on the SV-CC reflector.

Personally I don't think that the construct suggested is
something that would be widely useful.  An easy workaround
is to simply create a multiply dimensioned packed array, as in

   bit [7:0][3:0] b;

Regards,
Doug


> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com] 
> Sent: Monday, April 25, 2005 10:58 AM
> To: Warmke, Doug; pgraham@cadence.com
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] packed integer arrays
> 
> 
> >I'm not interested in bounding the predefined integer types.
> >I'm interested in creating a packed array of predefined
> >integer types:
> >
> >    typedef byte [3:0] word;
> >
> >which is currently not allowed.
> 
> Exactly.  Other packed types can be used as an element type in a
> packed array declaration.  Why is there this obscure difference
> for the predefined integer types?  I can define my own byte type
> that is equivalent to the predefined byte type in all other ways
> within SystemVerilog code.  Why should it behave differently in
> this one way?
> 
> Note that the DPI could define that any 8-bit 2-state type will
> map into a char, not just the predefined byte type.  It could
> define that any 2-state vector type will map into the next larger
> C type, and only vectors wider than long long would have to use
> the clumsier access mechanism.
> 
> Steven Sharp
> sharp@cadence.com
> 
>