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

Hi all,

I still fully agree with Doug.

Furthermore
 - name compatibility is important because it is more intuitive to use the same names. You also might want to use the same utility
functions for determining the logic value of a bit for both, PLI and DPI I/F. Using different names is boring here and just causes
confusion.
 - order compatibility is also important. Utility functions that are dependent on this order can be reused and there is no need for
sorting it in one or the other order within a simulator, which might be a performance drawback for one or the other interface.

Besides that, this discussion sound to me like a discussion of 'being closer to IEEE 1364' vs. 'being closer to VCS DirectC'. When
you ask me to choose between those two, the answer is more than obvious, at least for me...

Best regards,
-Michael

"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
> > >
> >

--
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! ***