Subject: Re: [sv-cc] SV-CC LRM Version 0.8
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Mar 31 2003 - 12:26:56 PST
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. I think we should write that this is possible if a C
language layer is preserved.
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.
we need to mention this.
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:
section 1.4.1.2:
don't need to say are "undetermined and implementation -dependent".
Undetermined is sufficient.
Section 1.4.4
"Such declarations are referred to as import declarations." or make the
sentence singular.
top of page 6 : Thesignature
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).
Section A.6.3: typos
Standalone I think that should be 2 words stand alone?
iif the element type is
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?]
Section A.8.2 title says "imported and export functions"
paragraph below says the same.
should be import and export functions
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.
Are we saying that the context brought by the import function gets passed
to the export
function? But what about if the export function declarative context was
different that the context
of the import function? Is the export call going to work?
Shouldn't we say that before calling the export function, one must change
the context to be
the context of the export function?
It looks like the way we say it, it is okay behaviour. I don't think it is.
Section A.8.3:
The formatting of the paragraphs in this section is varying.
The paragraph talks about extern function rather import functions.
Note that we are missing the cname identifiers limitations that it can be
an escaped keyword.
I have not reviewed the assertion and coverage API but will do shortly.
francoise
'
This archive was generated by hypermail 2b28 : Mon Mar 31 2003 - 12:27:36 PST