Subject: Re: Packed struct/union amendments proposal
From: Steven Sharp (sharp@cadence.com)
Date: Mon Jul 22 2002 - 15:53:02 PDT
>Section 3.7
>
>Structs -
>
>1. Change "The first member specified is the most significant" to
> "The first bit of the first member specified is the most significant when
the struct
> is treated as a whole. All data types are bit-aligned so that there is no
automatic
> padding, and are stored with the most significant bit first.".
I don't think it should say anything about how it is stored. It is up to
the standard to specify the behavior. It is up to the implementation to
decide how it wants to store things, as long as it abides by the specified
behavior. It can even store things with padding, as long as it assembles
it into a contiguous vector when necessary so the user doesn't see padding.
If we get a C interface that is intended to be able to access these packed
data types in a consistent way, then we can worry about storage layout.
And aside from this, I don't think the modified text says anything that the
original text doesn't already cover.
>Unions -
>
>2. Strike "Note that writing one member and reading another is independent of
the
> byte ordering of the machine, unlike a normal union of normal structures,
which
> are C-compatible and have members in ascending address order", and add
> "Since the memory layout of 4-value types is implementation dependent, it
is not
> allowed to overlay 2-value data fields with 4-value data fields."
The first part of what you are proposing to strike is still correct, and
should not be stricken. As long as the union is only written and read from
SystemVerilog code, the behavior is fully defined and independent of the
byte ordering of the machine. Which member is most significant and which
bit of each member is most significant are defined.
If I define
typedef struct packed {
byte byte1;
byte byte2;
byte byte3;
byte byte4;
} bytes;
typedef union packed {
bit [31:0] word;
byte [3:0] byte_slice;
bytes slice;
} mem_word;
then byte[3] and slice.byte1 correspond to word[31:24], because those are
all the most significant in each member. And byte[0] and slice.byte4
correspond to word[7:0], because those are all the least significant in
each member. So it is well defined how they overlay and how access to the
different fields will work within SystemVerilog. This may be sufficient
for what you want, and is the point I was trying to stress during the
meeting.
The only thing that is not defined is exactly how this is stored in memory.
That is only visible if you have another way of accessing the storage aside
from HDL constructs. For example, if you can access the data structure
directly from C code.
The second part of what you are proposing to strike specifies the memory
layout of unpacked unions of unpacked structures. Without a C interface,
this should not be specified and should be left up to the implementation.
Let us assume a C interface that can directly access SystemVerilog data
types. Then it makes sense for the unpacked types to have a specified
storage layout which matches what C code expects. Meanwhile, if packed types
are intended only for use by the HDL, with no intent that C be able to read
them consistently, there is no reason to specify the storage layout.
I'm not sure what should be said about overlaying 2-state and 4-state
members. The standard states that if any member is 4-state, the whole
union is 4-state. It is not clear whether this means that each 2-state
member is also treated as 4-state. This seems to be implied by the text
for structs (the text that refers to "masked" and "unmasked"). If so,
then the point becomes moot, because you are effectively overlaying 4-state
members. I assume that this was the idea. The behavior is again defined
within the HDL. It is not defined for a C interface because none of the
4-state representation is defined for it.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Mon Jul 22 2002 - 15:54:40 PDT