[sv-cc] Question on LRM E.6.7

Hi Team,

In SV 3.1a E.6.7, there is a discussion of canonical value
representation.
The following statement appears:

The Direct Programming Interface defines the canonical representation of
packed 2-state (type svBitVec32)
and 4-state arrays (type svLogicVec32). This canonical representation is
derived from on the Verilog legacy
PLI's avalue/bvalue representation of 4-state vectors.

Next, table E.2 and the associated typedef in svdpi.h:

Table E-2: Encoding of bits in svLogicVec32

c d Value
0 0 0
0 1 1
1 0 z
1 1 x

typedef struct { unsigned int c; unsigned int d;} svLogicVec32; /* (a
chunk of) packed logic array */

Now, here is an excerpt IEEE 1364-2001c's VPI section 27.14:

Figure 178-The s_vpi_value structure definition

typedef struct t_vpi_vecval
{
/* following fields are repeated enough times to contain vector */
PLI_INT32 aval, bval; /* bit encoding: ab: 00=0, 10=1, 11=X, 01=Z */
} s_vpi_vecval, *p_vpi_vecval;

You can see that the DPI 4-state canonical encoding is reversed from
PLI's aval/bval representation.
To be compatable with IEEE PLI, we should name those fields a and b
rather than c and d,
and we should reverse their order in the typedef struct.

We would like to be compatible with Verilog legacy IEEE 1364 conventions
in this case,
as is stated in the blue text above. Somehow we all must have
overlooked the technical
incompatibility identified in this mail. Let's discuss on email and
then propose an errata
on this issue.

Thanks and regards,
Doug
Received on Thu Apr 15 11:31:52 2004