Re: [sv-bc] Built-in types are not packed arrays

From: Francoise Martinolle <fm@cadence.com>
Date: Mon Sep 27 2004 - 08:34:25 PDT

My email has not been working very well isince last Friday so I just saw that
thread and I am replying now.

A few more points to consider.

The 1364 standard specifies loosely the required implementation range of the
integer type. It says it must be at least 32 bits.
Apparently this was specified in order to accomodate various computers
which may not be 32 bit computers. In the use of the integer type for example
for declaring loop variables, the exact range did not matter, by using an
integer type, the user knew that it would be large enough.
Verilog XL may have been ported to many platforms and computers and we do
not know if the integer type was always treated as a 32 bit type, like it seems
it is in the implementations we know about. Therefore I don't think we can
change this.
Additionally, the new SV types int, byte, shortint etc are not loosely
defined and the exact number of bits is specified by SV. I think that this
will create problems with C compatibility as the C compiler types int, char,
short etc.. are loosely defined and may differ from platform to platform.
For ex an SV int may not map to a C int on some platforms (this is a DPI
specification problem) .

In 1364-2001, bit select and part selects of integers were defined and allowed
(there were not in 1995), however the range of the integer type remained loosely
defined. Probably this was added because VXL allowed it.

One difference between the integer and packed array types is that you cannot
at all places in the language replace a packed array of logic [31:0] with an
integer type. For example, multi-dimensional packed vectors have to be formed
of explicit ranges, not a mix of ranges and types.

for ex:
  integer [31:0] myvector; is not allowed by SV.
  
One of the reason for disallowing this is that the above line
was generally accepted by VXL and some other simulators but the range [31:0] was
ignored and the definition was equivalent to integer myvector. It would have
created a backwards compatibility issue.

In 2001, even though the language was change to allow bit select and par select
of integers, VPI was not enhanced to support bit iterations from integer
variables, neither to get the left and right range of an integer variable it
only allowed to return a bit selext or part select when such expression was
found in the source code. I talked to Charles Dawson about this and he said that
the enhancement in VPI was not deemed important to make (probably because of the
usage of integer vairables) and that returning
bit select and part select expression of integers was all that was important.

Francoise
    '

>X-Authentication-Warning: server.eda.org: majordom set sender to
owner-sv-bc@eda.org using -f
>From: "Brad Pierce" <Brad.Pierce@synopsys.com>
>To: <sv-bc@eda.org>
>Subject: [sv-bc] Built-in types are not packed arrays
>Date: Fri, 24 Sep 2004 11:32:27 -0700
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>Importance: Normal
>X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a on
server
>X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a on
server
>X-Virus-Status: Clean
>X-Virus-Status: Clean
>X-pstn-levels: (S:38.79978/99.88353 R:95.9108 P:95.9108 M:99.8514 C:83.1967 )
>X-Received: By mailgate2.Cadence.COM as LAA05128 at Fri Sep 24 11:34:16 2004
>
>Erratum 51 http://www.eda.org/svdb/bug_view_page.php?bug_id=51
>asks whether built-in integer types are a form of packed array.
>
>In my opinion, they are not. For example, if J were declared
>as int, then I think
>
> $dimensions(J)
>
>should yield 0, and $left(J) should yield an error. And an
>unpacked array of bytes
>
> byte A[16];
>
>would have one dimension, not two.
>
>Erratum 101 http://www.eda.org/svdb/bug_view_page.php?bug_id=101
>asks whether $dimensions() really returns a 0 for all singular
>objects. I think it does not. Instead it should return 0 only
>for objects that are *not arrays*, because as Paul points out
>a packed array is a singular object.
>
>-- Brad
>
>
Received on Mon Sep 27 08:34:31 2004

This archive was generated by hypermail 2.1.8 : Mon Sep 27 2004 - 08:34:34 PDT