Subject: Re: Packed struct/union amendments proposal
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Jul 22 2002 - 19:08:51 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.
Sorry you didn't like "stored", I'm just seeing it all in terms of C programming,
it's difficult to describe overlays (unions) without some concept of storage.
I'm only worried about which bits line up where for this argument, actual
storage can be something different.
> And aside from this, I don't think the modified text says anything that the
> original text doesn't already cover.
Not quite, it states that the (virtual) storage model is big-endian for all
data types.
> >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.
The first part would possibly be correct if the endianness had been defined, but
it wasn't (my first change fixes that, and makes the statement redundant).
> 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.
If we modify the union:
typedef union packed {
bit [31:0] word;
byte [3:0] byte_slice;
bytes slice;
int b32;
} mem_word;
and then do:
mem_word.b32 = 32h'12345678;
what's the value of slice.byte1?
> 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.
As I said before the reason for wanting this stuff defined is that we have
testbenches that generate data for simulated embedded processors that don't
address their data the same way the simulation host does, and I want to
avoid error prone `ifdef BIG_ENDIAN...`else code.
> 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.
You can do it that way, but it's guaranteed to be less efficient. Also
automatically treating Xs/Zs as 0 seems like a realy bad idea to me.
( Should've proposed striking that paragraph too :-) ).
Kev.
> Steven Sharp
> sharp@cadence.com
This archive was generated by hypermail 2b28 : Mon Jul 22 2002 - 19:20:31 PDT