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

We should be using exactly the IEEE representation of 4 state values:
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;

  Why changing this???

Francoise
        '

At 02:41 PM 4/15/2004 -0700, Warmke, Doug wrote:
>Hi Andrzej,
>
>Unfortunately, we disagree with your opinion on this one.
>Please read below to see why...
>
>
> > -----Original Message-----
> > From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> > Sent: Thursday, April 15, 2004 12:46 PM
> > To: Warmke, Doug
> > Cc: sv-cc@eda.org
> > Subject: Re: [sv-cc] Question on LRM E.6.7
> >
> > > 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
> >
> >
> > No, it was not an overlook. DPI had been derived from VCS DirectC.
> > VCS DirectC uses c/d representation instead of aval/bval.
> >
> >
> > Do we want to be compatible with IEEE PLI conventions?
> > I don't think so.
> > First, the canonical representation defined in DPI is not
> > meant for PLI.
> > The representation of unpacked arrays (formerly known as
> > "memories") defined
> > in PLI is unsuitable for SV, see "struct memval", IEEE
> > 1364-1995 section 21.35
> > Fig.21-9.
> > Then, PLI does not define 2-state types.
> > So I think that pretending that the canonical representation
> > is compatible
> > with IEEE PLI would add confusion rather than make things cleaner.
> >
> > The canonical representation in DPI is not IEEE PLI. Period.
>
>Your statements here make sense. However, they apply equally
>well to DirectC. There was never a requirement to be compatible
>with either interface. And interestingly, the LRM actually points
>out that canonical value representation was derived from PLI,
>not DirectC. (See my previous email for the quoted text).
>
>Let's look at what we're hoping to achieve with DPI:
>-> Convert many PLI/VPI users into DPI, especially those with relatively
> simple applications that don't want to go through veriuser_tfs and
> other relatively arcane binding mechanisms present in PLI/VPI.
>
>We claim that having aval/bval representation for 4-state will be
>more intuitive for the bulk of candidate DPI users. They already
>know aval/bval. They may even have libraries of functionality that
>deal with arrays of aval/bval pairs that may be used with PLI/VPI
>calls. Even if they don't have such libraries now, it is likely
>that some advanced users would like to build common utilities
>whenever possible. The possibilities are increased if we try to
>stay at least a little consistent with PLI/VPI in this area.
>
>In general, we feel that we should converge PLI and DPI whenever
>possible, to help intuition of experienced users. PLI is a venerable
>and well-known standard with thousands of users. DirectC is nice,
>but given the choice of being somewhat compatible with it vs. PLI,
>we prefer PLI (It's understandable that your views are different).
>
>Divergence is sometimes OK, as long as there is a sound technical
>reason for doing so. Here we can't think of any, so we favor going
>with PLI/VPI's aval/bval.
>
>Maybe we'll have to get some more discussion from other committee
>members and then put this to a vote.
>
>Thanks and regards,
>Doug
>
> >
> > Besides, there is no issue of legacy PLI C code being
> > transitioned to DPI.
> > There are way too many differences. There is, however, legacy
> > DirectC code.
> > So personally I'm more concerned with DPI/DirectC
> > compatibility than with
> > DPI/PLI compatibility.
> >
> >
> > Regards,
> > Andrzej
> >
> >
> > > 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;
> > >
> > >
> > >
> > >
> > > Thanks and regards,
> > > Doug
> > >
> >
Received on Thu Apr 15 17:23:02 2004