packed vs unpacked

[very_very_log]

The following operations can be performed on packed arrays, but not on
unpacked arrays.
The examples provided with these rules assume that A is an array.
-- Assignment from an integer, e.g., A = 8'b11111111;
-- Treatment as an integer in an expression, e.g., (A + 3)

Why so ?
I found the LRM a little unclear on the above.
Can somebody explain ?

 

[Jonathan Bromley]

On Sat, 29 Dec 2007 04:21:22 -0800 (PST), very_very_log
<sgiitnewid@gmail.com> wrote:

The following operations can be performed on packed arrays, but not on
unpacked arrays.
The examples provided with these rules assume that A is an array.
-- Assignment from an integer, e.g., A = 8'b11111111;
-- Treatment as an integer in an expression, e.g., (A + 3)

Why so ?

A packed array is a way to describe the internal structure
of a row of bits. Regardless of any internal structure
that it may have, such a row of bits can always be treated
as an integral value (signed or unsigned according to its
declaration). When an unpacked array is treated as an
integral value in this way, the mapping of bits in the
integral value to bits of the packed array is completely
well-defined and straightforward.

An unpacked array is a way to describe a collection of
distinct elements, all of the same data type - just like
an array in any conventional programming language. In
C, for example, the following makes little sense:

int I;
char C[4]; // or "byte C[4]" in SystemVerilog
....
I = C; // yes, you can do this in C, but it doesn't
// copy the array at all!!!!
C = I; // illegal in C

Although the compiler's response would be somewhat different,
the same idea would be equally illegal (and silly) in
SystemVerilog.

If you really need to see an entire unpacked array as
a single row of bits in SystemVerilog, you can use a
bit-stream cast.

This is an area where I believe SystemVerilog really
got it right. The unpacked/packed mechanism provides
a remarkably good compromise between type-safety and
flexibility - and the user (programmer) is fully in
control of that compromise, every step of the way.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On Sat, 29 Dec 2007 13:06:30 +0000,
Jonathan Bromley wrote:

TYPO, sorry for any confusion:

A packed array is a way to describe the internal structure
of a row of bits. Regardless of any internal structure
that it may have, such a row of bits can always be treated
as an integral value (signed or unsigned according to its
declaration). When an unpacked array is treated as an
integral value in this way,

This paragraph was talking purely about PACKED arrays, so
the last phrase should have been

When a PACKED array is treated as an
integral value in this way,

thanks
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[very_very_log]

Still confused...
I have done lots of programming in C, C++, Java and Tcl
So am comfortable with arrays, vectors, maps and associated arrays.

From the description you have given, it seems to me that
System Verilog unpacked arrays are analogous to C++ vectors (STL
vectors if it clarifies more )
Is it so ?
Or is unpacked array analogous to linked list ?

Also, can you give an example of a situation where the use of unpacked
arrays
is necessary ? i.e some example where unpacked arrays make the obvious
choice over the packed arrays.

To me it seems, that packed arrays just have some more functions
defined for them.




Jonathan Bromley wrote:

On Sat, 29 Dec 2007 04:21:22 -0800 (PST), very_very_log
sgiitnewid@gmail.com> wrote:

The following operations can be performed on packed arrays, but not on
unpacked arrays.
The examples provided with these rules assume that A is an array.
-- Assignment from an integer, e.g., A = 8'b11111111;
-- Treatment as an integer in an expression, e.g., (A + 3)

Why so ?

A packed array is a way to describe the internal structure
of a row of bits. Regardless of any internal structure
that it may have, such a row of bits can always be treated
as an integral value (signed or unsigned according to its
declaration). When an unpacked array is treated as an
integral value in this way, the mapping of bits in the
integral value to bits of the packed array is completely
well-defined and straightforward.

An unpacked array is a way to describe a collection of
distinct elements, all of the same data type - just like
an array in any conventional programming language. In
C, for example, the following makes little sense:

int I;
char C[4]; // or "byte C[4]" in SystemVerilog
....
I = C; // yes, you can do this in C, but it doesn't
// copy the array at all!!!!
C = I; // illegal in C

Although the compiler's response would be somewhat different,
the same idea would be equally illegal (and silly) in
SystemVerilog.

If you really need to see an entire unpacked array as
a single row of bits in SystemVerilog, you can use a
bit-stream cast.

This is an area where I believe SystemVerilog really
got it right. The unpacked/packed mechanism provides
a remarkably good compromise between type-safety and
flexibility - and the user (programmer) is fully in
control of that compromise, every step of the way.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On Sun, 30 Dec 2007 01:00:17 -0800 (PST),
very_very_log <sgiitnewid@gmail.com> wrote:

From the description you have given, it seems to me that
System Verilog unpacked arrays are analogous to C++ vectors (STL
vectors if it clarifies more )
Is it so ?

I'm not familiar enough with the STL to answer that intelligently.

Or is unpacked array analogous to linked list ?

No, not at all. As I said, an unpacked array is like an
array in any conventional programming language: a collection
of items, all of the same data type, identified by a subscript.

There are some similarities between SystemVerilog queues and
doubly-linked lists, but so many differences that it's not a
good idea to push the analogy.

Also, can you give an example of a situation where the use of unpacked
arrays
is necessary ? i.e some example where unpacked arrays make the obvious
choice over the packed arrays.

Unpacked arrays (and structs, and unions) give some level of
type-safety. For example, the two arrays
int A[10];
int B[5][2];
are clearly somewhat different. Because they're unpacked,
they have distinct and incompatible types. By contrast,
the two arrays

logic [9:0] L;
logic [4:0] [1:0] M;

are both packed arrays of 10 bits, and can be copied
on to one another. Both behaviours are useful, in different
circumstances. It's good to be able to distinguish them.

Also, it makes no sense to have an associative or dynamic
packed array, does it?

To me it seems, that packed arrays just have some more functions
defined for them.

I don't really understand this. Packed objects can be treated
as integral values, because they are simply a row of bits and
that's what Verilog thinks an integral value looks like.
Otherwise, packed things are probably *less* flexible than
unpacked.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Petter Gustad]

very_very_log <sgiitnewid@gmail.com> writes:

I have done lots of programming in C, C++, Java and Tcl
So am comfortable with arrays, vectors, maps and associated arrays.

Being exposed to union/bitfields in C, common blocks/equivalence in
FORTRAN, and packed in Pascal is helpful to understand the advantages
and limitation of packed arrays in SV.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Chris F Clark]

very_very_log <sgiitnewid@gmail.com> writes:

Still confused...
I have done lots of programming in C, C++, Java and Tcl
So am comfortable with arrays, vectors, maps and associated arrays.

From the description you have given, it seems to me that
System Verilog unpacked arrays are analogous to C++ vectors (STL
vectors if it clarifies more )
Is it so ?
Or is unpacked array analogous to linked list ?

Also, can you give an example of a situation where the use of unpacked
arrays
is necessary ? i.e some example where unpacked arrays make the obvious
choice over the packed arrays.

To me it seems, that packed arrays just have some more functions
defined for them.

No, an unpacked array is not like an STL vector. The difference is
more akin to bit-fields in C (or as mentioned packed arrays in
Pascal).

struct { int x:1; int y:1; } // similar to a packed array
struct { int x; int y; } // similar to an unpacked array

In a packed array the excess filler bits are removed from between the
inidivdual array elements and the bits are sequential. Thus, you can
tread the whole entity as a long bit string. In an unpacked array,
there may be filler gaps between the bits (and there usually are as I
will explain in a moment). Thus, you cannot treat the whole collection
as a stream of bits (without doing a lot of work to deal with where
the filler bits are).

The filler gaps are allowed in an unpacked array because on most
hardware, it is more efficient to deal with data aligned on some
"natural boundary" and not just one bit somewhere in the middle of a
word (or byte). Thus, on an x86 machine (or most any byte addressible
machine), one might see each "bit" in a unpacked array use up an
entire byte (wasting 7 filler bits (more on this below)). On a
machine where items are actually aligned to 32 bit words (relatively
common when Verilog was young), the ratio is far worse. The trade-off
is generally in execution speed. Accesses to properly aligned data
usually occur at the full rated speed of the machine, because one
instruction will usually successfully read or write one entry. Access
to packed data can take several times that long per item. If you do a
lot of twiddling single items, this can be a noticeable penalty.

However, in practice, the speed concern (due to packing arrays) for
Verilog programs is not as relevant as one would assume. Many Verilog
programs have very large memory footprints and don't fit in cache (and
often not even in main memory, requiring paging just to deal with the
data). As a result, the speed of accessing any single item is
dominated by cache and paging costs and not by the instructions used
to manipulate it. Therefore, packing arrays can actually result in
faster execution due to a smaller memory footprint, even though the
individual element access requires more instructions (but those
instructions will be dominated by one cache miss or page fault).
Unfortunately, even packing arrays won't necessarily have a large
impact on the memory footprint, because the footprint is primarily a
result of the sheer number of discrete elements in a design--
particularly, if one is talking about a post-synthesis model.

Now, a word about the filler bits. In Verilog each bit can take on 4
states: 0, 1, x, and z. Thus, a Verilog bit cannot be stored in 1
hardware bit, but will generally take 2 bits (and if I understand
correctly it may even take more hardware bits if it is a wire with
strengths). Thus, an array of bits will actually use 2 bits per
element and waste "only" 6 if aligned on byte boundaries.

 

[very_very_log]

On Dec 31, 9:40 am, Chris F Clark <c...@shell01.TheWorld.com> wrote:

very_very_log <sgiitne...@gmail.com> writes:
Still confused...
I have done lots of programming in C, C++, Java and Tcl
So am comfortable with arrays, vectors, maps and associated arrays.

From the description you have given, it seems to me that
System Verilog unpacked arrays are analogous to C++ vectors (STL
vectors if it clarifies more )
Is it so ?
Or is unpacked array analogous to linked list ?

Also, can you give an example of a situation where the use of unpacked
arrays
is necessary ? i.e some example where unpacked arrays make the obvious
choice over the packed arrays.

To me it seems, that packed arrays just have some more functions
defined for them.

No, an unpacked array is not like an STL vector. The difference is
more akin to bit-fields in C (or as mentioned packed arrays in
Pascal).

struct { int x:1; int y:1; } // similar to a packed array
struct { int x; int y; } // similar to an unpacked array

In a packed array the excess filler bits are removed from between the
inidivdual array elements and the bits are sequential. Thus, you can
tread the whole entity as a long bit string. In an unpacked array,
there may be filler gaps between the bits (and there usually are as I
will explain in a moment). Thus, you cannot treat the whole collection
as a stream of bits (without doing a lot of work to deal with where
the filler bits are).

The filler gaps are allowed in an unpacked array because on most
hardware, it is more efficient to deal with data aligned on some
"natural boundary" and not just one bit somewhere in the middle of a
word (or byte). Thus, on an x86 machine (or most any byte addressible
machine), one might see each "bit" in a unpacked array use up an
entire byte (wasting 7 filler bits (more on this below)). On a
machine where items are actually aligned to 32 bit words (relatively
common when Verilog was young), the ratio is far worse. The trade-off
is generally in execution speed. Accesses to properly aligned data
usually occur at the full rated speed of the machine, because one
instruction will usually successfully read or write one entry. Access
to packed data can take several times that long per item. If you do a
lot of twiddling single items, this can be a noticeable penalty.

However, in practice, the speed concern (due to packing arrays) for
Verilog programs is not as relevant as one would assume. Many Verilog
programs have very large memory footprints and don't fit in cache (and
often not even in main memory, requiring paging just to deal with the
data). As a result, the speed of accessing any single item is
dominated by cache and paging costs and not by the instructions used
to manipulate it. Therefore, packing arrays can actually result in
faster execution due to a smaller memory footprint, even though the
individual element access requires more instructions (but those
instructions will be dominated by one cache miss or page fault).
Unfortunately, even packing arrays won't necessarily have a large
impact on the memory footprint, because the footprint is primarily a
result of the sheer number of discrete elements in a design--
particularly, if one is talking about a post-synthesis model.

Now, a word about the filler bits. In Verilog each bit can take on 4
states: 0, 1, x, and z. Thus, a Verilog bit cannot be stored in 1
hardware bit, but will generally take 2 bits (and if I understand
correctly it may even take more hardware bits if it is a wire with
strengths). Thus, an array of bits will actually use 2 bits per
element and waste "only" 6 if aligned on byte boundaries.

Wow !!
That was a great reply !
You were able to explain the smallest details with clarity.
Good work
Thanks !