Re: [sv-cc] Question on LRM E.6.7

I fully support this proposal.
Just one more thing we might want to consider is to use a standard define for a 32 bit integer (sthg. like PLI_INT32) instead of
'unsigned int' within this definition and also for svBitVec32. Possibly sthg. like sv32BitInt_t. I shy away from proposing to use
PLI_INT32 directly, because this would created a (not needed) dependency on the PLI includes.

This would add consistency with other pieces of PLI and might be needed for 64 bit awareness.

-Michael

"Warmke, Doug" wrote:

> 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

--
NOTE: The content of this message may contain personal views
      which are not neccessarily the views of Motorola, unless specifically stated.
         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Software Technologist       Fax: +49-89-92103-680 |( \
    / / | Motorola, Semiconductor Products, System Design   | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@motorola.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \
The information contained in this email has been classified as:
Motorola General Business Information (x)
Motorola Internal Use Only            ( )
Motorola Confidential Proprietary     ( )
*** This note may contain Motorola Confidential Proprietary or
    Motorola Internal Use Only Information and is intended to be
    reviewed by only the individual or organization named above.
    If you are not the intended recipient or an authorized representative
    of the intended recipient, you are hereby notified that any review,
    dissemination or copying of this email and its attachments, if any,
    or the information contained herein is prohibited. If you have received
    this email in error, please immediately notify the sender by
    return email and delete this email from your system.
    Thank you! ***