Re: [sv-bc] A question regarding the proposal for issue # 91

Another argument for Dave's erratum 27

     http://www.eda.org/svdb/bug_view_page.php?bug_id=0000027

that $typeof() should only allow simple_types, not arbitrary
data_types, is that, although $typeof(phrase) == $typeof(phrase)
when phrase is a simple_type, if phrase is a data_type, then
sometimes $typeof(phrase) != $typeof(phrase).

For example, if

      struct {byte f, g;} a, b;
      struct {byte f, g;} x, y;

then

      $typeof(a) == $typeof(b);
      $typeof(x) == $typeof(y);

but

      $typeof(a) != $typeof(x).

Similarly,

      $typeof(struct {byte f, g;}) != $typeof(struct {byte f, g;})

A new type is created by each struct declaration.

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Rich,
Dave
Sent: Wednesday, October 06, 2004 12:45 PM
To: sv-bc@eda.org
Subject: RE: [sv-bc] A question regarding the proposal for issue # 91

 I agree. The general rule should be that a packed or unpacked range should
not be allowed unless there is an identifier that it can relate to. So that
should restrict them to declarations (or prototypes)

Dave

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Paul
Graham
Sent: Wednesday, October 06, 2004 12:35 PM
To: sv-bc@eda.org
Subject: Re: [sv-bc] A question regarding the proposal for issue # 91

Dave Rich wrote:

> I think the suggestion was to make them accept a simple_type, so
> $bits(integer) is OK, but $dimensions(reg[10:0]); is not legal.
> At least one reason for not allowing (reg[10:0]) is that it is
> visually ambiguous as to whether it is a packed or unpacked array.

I assume the same reasoning applies to parameterized types. If you
have:

    sub #(.t(reg[10:0])) u1();

then it's equally unclear whether you are parameterizing type t of module
sub with a packed or unpacked array of bits.

Paul
Received on Sun Nov 7 09:30:22 2004