Subject: Re: [sv-cc] SV-CC LRM Version 0.8
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Apr 01 2003 - 10:16:22 PST
> FRANCOISE:
>
> Comments on the document:
>
> general comment on section 1.2:
> -------------------------------------------------
> The DPI interface was primarily designed as a C foreign language interface.
> The document
> make readers believe that any foreign language can be hooked through DPI to
> systemVerilog.
... provided that implementation supports it.
And we never said "any foreign language". We said: different languages.
> I think we should write that this is possible if a C
> language layer is preserved.
Why? I can imagine C++ layer. Possibly Java layer. VHDL?
> For example the foreign language in question may not support all C data types
> and this may create more restrictions on the data types of the Verilog objects
> you want to pass to the foreign language and get back from the foreign
> language.
Not really. IMO this is solely a matter of efficiency. C types can be 'unpacked'
and interpreted as other types and/or mapped onto other types.
> we need to mention this.
Added some explanation to 1.2, something in the spirit of "implementation rather
than magic".
> I think that the Annex A state this very well in this sentence: We may want
> to repeat this sentence in the first section
> The SystemVerilog Direct Programming Interface (DPI) allows direct
> inter-language function calls between
> SystemVerilog and any foreign programming language with a C function call
> protocol and linking model:
IMO this is a matter of implementation rather than semantics or language
definition. Yeah, linkage via global unique symbols is a part of semantics.
Function call protocol is not.
SV layer is as good as any other language definition and per se it requires
no specific implementation. Interpreter implemented as a virtual stack based
machine? Why not?
C layer is a different story. By a sheer fact of defining it, SV 3.1 requires
that every SV implementation shall support C protocol. But it does not prohibit
the implementations to support alternative protocols as well!
> section 1.4.1.2:
> don't need to say are "undetermined and implementation -dependent".
> Undetermined is sufficient.
done.
> Section 1.4.4
> "Such declarations are referred to as import declarations." or make the
> sentence singular.
done.
> top of page 6 : Thesignature
done.
> section 1.6:
> export a function that
???
> Section A.5: I would completely remove this section it is redundant with
> section 1. Most of
> it qualifies the semantics of the arguments passed to DPI functions in SV.
> Annex A should only contain the C side: data type duality, utility
> functions, include files.
> Remove everything that talks about how import/export functions should be
> declared
> and the semantics of the argument models. It also bothers me that some of
> the sections in
> A.5 also cross reference the exact same section in section 1 (which is an
> exact copy).
I agree to some extent. IMO there should be as little references to SV in
the C layer as possible. Ideally, Annex A should contain solely plain C stuff.
Exaggerating a bit, readers of Annex A may be absolutely unfamiliar with SV; they are only required to understand C.
On the other hand, I wanted C layer to be maximaly self contained (again:
do not force its readers to refer to SV documents, they are C programmers and
they don't care about SV!) and hence a number of repetitions or redundant
copied phrases (may they be copied truely!).
> Section A.6.3: typos
done. ["do not contain=ed= packed elements" - corrected after sending pdf]
> Standalone I think that should be 2 words stand alone?
I'm not absolutely sure, yet believe that 'standalone" is fine.
> iif the element type is
done.
> Section A.7.7:
> There is still an issue to be resolved: The text is stating this question:
> bit (i.e., 2-state) packed arrays up to 64 [previously 32] -bit (canonical
> representation shall be used, like
> for a function result).
> [There is a problem here: 'int' is the same as svBitVec32, long long is not
> the same as svBitVec32[2],
> so how to return a value in the canonical representation as a function
> result, if this value is between
> 33 and 64 bits?]
done.
> Section A.8.2 title says "imported and export functions"
> paragraph below says the same.
> should be import and export functions
done.
> Section A.8.2:
> I have a technical issue with the following sentence:
>
> Note that context is transitive through imported and export context
> functions. That is, if an imported function
> is running in a certain context, and if it in turn calls an exported
> function, the exported function will inherit the
> context from the imported function.
done; used Doug's wordings.
> Section A.8.3:
> The formatting of the paragraphs in this section is varying.
>
> The paragraph talks about extern function rather import functions.
haven't done anything here
> Note that we are missing the cname identifiers limitations that it can be
> an escaped keyword.
I corrected this in SV layer. Somewhere else?
Regards (and thanks for your feedback!),
Andrzej
This archive was generated by hypermail 2b28 : Tue Apr 01 2003 - 10:17:44 PST