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

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 14:41:14 2004