Re: [sv-bc] packed array question

Françoise,
   Steve is /not/ proposing that typedef should be able to use
a declarative syntax which is illegal when used anonymously.

typedef integer [7:0] i;  // Still illegal

   He is just recounting the "workaround" we discussed long ago:

typedef integer my_int;
my_int [7:0] ANONYMOUSLY;  // 8 integers packed in a vector.

   Of course there's no technical impediment to packing integers
into vectors.  I think you'll agree with this without exception.
As a veteran of other standards, I'll note that inviting different
users to dream up synonyms for "integer" is divergent, not convergent.

Seeing "typedef integer integer" would be enough signal to me that
the RTL source is not legacy code... but it seems like nasty magic, so
I wouldn't seriously propose it, and I resist commandeering more keywords.

Greg Jaxon


francoise martinolle wrote:
>  
> Steve,
> 
> I agree with what you say except that whatever you can declare as a typedef
> would
> not be able to appear as an anonymous type for a variable declaration.
> 
> Francoise
>     '
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Steven
> Sharp
> Sent: Friday, December 16, 2005 1:58 PM
> To: Dave_Rich@mentor.com; fm; sv-bc@eda.org
> Subject: RE: [sv-bc] packed array question
> 
> As I understood it, the only reason that packed arrays of integer were not
> allowed was fear of backward incompatibility with legacy code that used
> declarations like
> 
>   integer [7:0] i;
>   
> This was illegal, but Verilog-XL accepted it and ignored the range.  If this
> were allowed in SystemVerilog, but with a different meaning, it would change
> the meaning of this legacy (illegal) code.
> 
> Since a typedef for integer could never appear in legacy code, I don't see
> how this problem applies in that case.  And since the predefined integer
> types are all packed types, I don't see any other technical reasons why it
> should not be legal to use them as elements in packed arrays.
> 
> Steven Sharp
> sharp@cadence.com
> 
>