As Francoise and Steve's recent emails underscore, we need to define the
vendor format of embedded packed types in a clear way that lets the user
specify the address of individual packed arrays as an argument to our
standard utilities.
Given the SystemVerilog construct in example in E.9.4:
"typedef struct {int a; bit [6:1][1:8] b [65:2]; int c;}
triple;"
The current approach and the Item-205 proposal create different kinds of
C code.
1. CURRENT WAY: (object of recent email questions)
typedef struct {
int a;
sv_BIT_PACKED_ARRAY(6*8, b) [64];
int c;
} triple;
Discussion: For &b[i] to be a legal argument to std. utilities, the
macro is presumably
producing something like: "struct {unsigned int i [2];} b". When
paired with the "[64]"
in the source code, this yields "struct {unsigned int i [2];} b [64];"
If this is the case, one
of the array dimensions is hidden, so &b[i] will be the address of an
individual packed array.
2. PROPOSED WAY (Item 205):
typedef struct {
int a;
svBitActual32 b [64] [SV_PACKED_DATA_NELEMS(6*8)];
int c;
} triple;
Discussion:
These macros ultimately produce "unsigned int b [64] [2];"
The C user employs the leftmost dimension to send an individual vector's
address to the
standard utilities; thus "&b[i]" is a valid argument for the utilities.
The rightmost dimension specifies how many std. 'chunks' make up an
individual vector in the
vendor format. The C compiler uses this value to size the struct field
accurately. The standard utilities
can use this dimension value to access chunks but the C user does not
need to do anything with it.
Note: Neither approach uses an additional dimension (whether hidden or
not) to define a "packed dimension"
that has indices corresponding to the packed dimension indices in
SystemVerilog. Such a dimension
does access vendor format chunks (whatever they are), rather than
individual packed bits.
Ralph Duncan
Received on Tue Nov 2 16:40:55 2004
This archive was generated by hypermail 2.1.8 : Tue Nov 02 2004 - 16:40:59 PST