RE: [sv-bc] packed array question

Someday, maybe long after we've all retired, we'll figure out a way to
represent an integer without having to implement it as binary bit
vector. But perhaps we'll have another HDL language by then. (In 1995, I
would never have thought Verilog and VHDL would still be around in 2005)

In any case, I think Greg's statement is the best reason for not
allowing typedefs.

You can still do

bit [4:0][31:0] i;

Which I think it the most descriptive way of declaring the layout of the
variable you want to use.

> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Friday, December 16, 2005 4:18 PM
> To: fm@cadence.com; sv-bc@eda.org; Rich, Dave
> Subject: RE: [sv-bc] packed array question
> 
> 
> >From: "Rich, Dave" <Dave_Rich@mentor.com>
> 
> >Yes, that was part of the reason. Another reason was, at one time,
int,
> integer
> and char did not have a totally fixed size; they were fixed for a
platform
> or OS
> implementation. (char could be 8 or 16 bits depending if it was
> representing
> ASCII or Unicode).
> 
> Even when that was true, it only meant that it would not be good
practice
> to define fixed hardware in terms of them.  There might still have
been
> reasonable uses.  And it isn't true for most of the types any longer.
> 
> 
> >Another reason is to not think of these types a bit vectors, they are
> variables
> that hold values.
> 
> I'm sorry, but I don't see the distinction.  A bit vector is a
variable
> that holds values.  An integer variable is represented as a bit
vector.
> You can apply any operation to an integer variable that you can apply
to
> a bit vector (including bit and part selects), and vice versa.  What
is
> this distinction you are trying to make?
> 
> The only differences I am aware of are the different treatment by DPI
> (for which there is good reason), and this different treatment in
packed
> array declarations (for which I have yet to hear any).
> 
> This isn't a particularly important issue, but the restriction seems
to
> be arbitrary.
> 
> Steven Sharp
> sharp@cadence.com