Subject: RE: [sv-cc] Version 2 of DPI LRM] - compatibility, C Layer
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Fri Mar 14 2003 - 12:14:22 PST
Hi Andrzej,
Please see below for some suggestions on your questions.
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Friday, March 14, 2003 8:05 AM
> To: Warmke, Doug; Stickley, John
> Cc: sv-cc@eda.org
> Subject: Re: [sv-cc] Version 2 of DPI LRM] - compatibility, C Layer
>
>
> > > > My understanding was this:
> > > >
> > > > Aplication requires:
> > > >
> > > > svc.h only, no svc_src.h, no vendor_specific.h
> > > > --> Guaranteed binary compatible
> > > >
> > > > svc.h, svc_src.h, no vendor_specific.h
> > > > --> Guaranteed source compatible
> > > >
> > > > svc.h, svc_src.h, vendor_specific.h
> > > > --> No compatibility guaranteed
> > >
> > > Such has been and still is my understanding, too.
> >
> > DOUG: Good - this makes sense.
> > But it was not my understanding.
>
> Doug & JohnS,
>
> Thank you for your comments.
>
> > Can you please enter a table in the LRM, as simply put
> > as John's text here?
>
> OK, such table may make the information stand out. Just
> please advise where to put it. Section "A.3 Portability"
> could seem the best place, but
> the include files are not introduced in this section yet.
> So, Section "A.4 Include files"?
DOUG: My suggestion is to flip the order of A.3 and A.4.
You can always forward-reference Portability when discussing
the reason for the existence of the two include files. Most
of the include file section will be spent on details of the
file contents.
Then, in the following Portability section, you can discuss
the include files and rules in detail without forward reference.
>
> Now, let me quote excerpts from "A.4 Include files".
>
>
> ===== Second and third paragraph of "A.4 Include files":
>
> Binary compatibility of an application depends on the data
> types of the values passed through the interface. If all
> corresponding type definitions can be written in C without
> the need to include an svc_src.h file, then an application is
> binary compatible. If an svc_src.h file is required, then the
> application is not binary compatible and needs to be
> recompiled for each simulator of choice.
DOUG: The above is very clear.
>
> Applications that pass solely C-compatible data types or
> standalone packed arrays (both 2-state and 4-state) require
> only an svc.h file and, therefore, are binary compatible with
> all simulators. Applications that use complex data types
> which are constructed of both SystemVerilog packed arrays and
> C-compatible types, also require an svc_src.h file and,
> therefore, are not binary compatible with all simulators.
> They are source-level compatible, however.
DOUG: The last sentence is what I have an issue with.
I would reword it
"They may be source-level compatible, provide the compatability
constraints discussed in section x.y.z are met."
>
> ===== Last sentence of of "A.4.1 svc.h include file":
>
> Applications which only use svc.h shall be binary-compatible
> with all SystemVerilog simulators.
>
> ===== Last sentence of of "A.4.2 svc_src.h include file":
>
> Applications that require an svc_src.h file are only
> source-level compatible, i.e., they need to be compiled with
> the version of svc_src.h provided for a particular
> implementation of SystemVerilog.
DOUG: Once again, this is too optimistic. Applications that
require svc_src.h *may* be source-level compatible. They will
be source-level compatable if some other constraints are met.
>
> =====
>
> I agree that no vendor_specific.h has been mentioned, so it
> may be not obvious that a program that includes vendor
> specific include file, does depend on a vendor specific
> include file. Seriously, JohnS's table-like form is very
> clear, but I don't know where is the best place for it and
> what to do with then redundant information.
DOUG: My above suggestion to flip A.3 and A.4, then put the
table in the portability section is the only thing I can think of.
It's hard to be perfect in this case, of course.
Thanks and regards,
Doug
>
>
>
> Thanks and regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Fri Mar 14 2003 - 12:15:16 PST