{Disarmed} RE: [sv-cc] Uploaded DPI-OO proposal 1.0.4

Hi Vitaly,

   I have some follow-up comments based on your feedback. I am inlining them below to avoid

uploading another version of the doc. Our previous comments are provided below. My new comments

are with ARNAB prefix and are in red below.

Thanks

Arnab

Section 35.7.1.2 Class arguments

The following rules apply to the pass-by-copy operation on the SystemVerilog side:

Allocation of a new object shall not invoke the object’s constructor or execute any variable
 initialization assignments.

—[AS1] [AS2]

ARNAB: When such a class is implicitly created eg input argument for an import tf, is the class created by calling malloc ? If the imported class is declared in C++ with virtual inheritance, how will that work ?

Section 35.12 Parameterized classes

// Below are different forms of explicit instantiation of the
// Stack specializations

typedef Stack #(byte) ByteStack;

Stack[AS3] [AS4] #(cell) dummy_variable_1;

ARNAB: I don’t understand this part of the comment “Each module instance creates a new type instance and it cannot be mapped to the C++ intermediate layer”. In my example the stack class is defined in the package which the module imports. The module instance then creates a specialization for the class. In this case, does the user need to specify all possible specialization of such a class that will be used in context of DPI-OO a design in the package as typedefs, or tf formal args or as variable declaration ?

Section 36 Pragma directives

Those pragmas are permitted in every scope where the corresponding export or import declaration is visible. [AS5] [AS6] T

ARNAB: From you comment, can I conclude that such pragmas are permitted only in a package or a compilation unit scope ? It was not obvious to me if that is the case. Can you please clarify this in the proposal. Also, based on the previous comment about specialization of parameterized classes, if all such specialization has to be explicitly declared in the package, why does the header generation need to wait till the end of elaboration since all the specialization should be know while compiling the package. What am I missing here ?

The optional dpi_oo_foreign_language_specification allows specifying different pragmas for the same SystemVerilog classes targeted for inter-language calls with different foreign languages.[AS7] [AS8]

ARNAB; I would like to see this defined to avoid inconsistencies across vendors. One vendor may decide Sysc as the language string for SystemC while another may choose “SC” or “SystemC” or any other variation. I don’t see this changing much in the future, so I don’t understand the motivation behind not defining it.

Section H 7.9.2

Unpacked arrays formed from packed arrays are represented by double pointers. [AS9] [AS10] For example:

ARNAB: I agree with what you are saying, but this is another one of those things that will cause inconsistency between DPI-C and DPI-OO and unless there is a strong reason for this inconsistency, I would like to avoid it.

Section H 7.9.4

Unpacked SystemVerilog structures shall be represented by proxy C++ structs. The struct members are mapped to the types described in ‎H.7.9.1, ‎H.7.9.2, and ‎H.7.9.3 with the only exception – the sizes of the linearized unpacked dimensions are explicitly specified in the corresponding member variable declarations.

[AS11]

[AS12]

ARNAB: Here is another case that causes inconsistency with DPI-C and within DPI-OO. Unpacked arrays have different representation when used standalone vs when embedded in a struct. I would prefer to be consistent and represent it in the canonical form.

Section H7.11 C++ intermediate layer namespaces and header files

A SystemVerilog package or a compilation unit scope, containing a class, or a typedef, or an enumerated type, or a subprogram definition, declared as an export DPI-OO, is mapped to the corresponding C++ language namespace of the intermediate layer[AS13] [AS14] . The

ARNAB: Packages don’t have dpi_cpp_name. Were you referring to the scope pragma to override the namespace name ? I don’t see any other way to override the package name in case it is not a valid C++ name.

Section H8.8 Inout and output arguments

An inout array argument in DPI-OO shall be handled as having two distinct values: an input directed value and an output directed value. In order to enable effective memory allocation and deallocation, the input directed and the output directed values shall be allocated separately. If the type of the inout argument requires memory allocation (an array, a structure, a DPI copy class), the callee shall allocate the output directed value rather than reuse the memory allocated by the caller for the input-directed value. The caller shall deallocate (according to the argument type) the input-directed and the output directed values both. The callee shall assume that the caller always deallocates the output directed values.[AS15] [AS16]

ARNAB: In this case, why not require the callee to write in the memory allocated and passed to the callee by the caller as actual arguments to the call ? In that case, there will be only one memory location which can be deallocated by the caller. Again this causes inconsistencies which is why I am opposed to it.

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Vitaly Yankelevich
Sent: Monday, September 26, 2011 1:42 PM
To: sv-cc@eda.org
Cc: Arturo.Saltz@synopsys.com
Subject: [sv-cc] Uploaded DPI-OO proposal 1.0.4

I uploaded two files:

IEEE P1800 3087 DPI-OO 1 0 3-arnab-vitaly.doc contains the feedback to Arnab’s comments (thanks!). One issue (of representing sized packed arrays by classes is currently in work, driven by Arnab)

IEEE P1800 3087 DPI-OO 1 0 4.doc contains the most recent updated version according to Arnab’s and Jim’s comments.

Regards,

Vitaly

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is 
believed to be clean. 
________________________________
 [AS1]Is this still applicable with copy classes as classes in C++ ?
 [AS2]Yes
 [AS3]Is something like this valid
 
module #(type T = int) mod();
import P::*;
Stack #(T) st;
endmodule
 
How will the C++ proxy look like for this ? I can’t think of a good way to represent such class templates in the C++ side, specially if the  class methods have input, output and inout arguments of the bit and logic vectors and the small types like int, short and classes. Also some examples here of the C++ proxies will be useful..
 [AS4]I think support of the explicit instantiations should be limited to packages and compilation unit scopes only. Each module instance creates a new type instance and it cannot be mapped to the C++ intermediate layer. I can add the explicit note about this. 
The examples of the C++ proxies for the parameterized classes can be found in H7.12. 
 [AS5]What does visible mean here? Does it mean a scope like module or interface that imports the package are permitted to have these pragmas ? If so, when is the header file generated – while compiling the module and what is the name of the header? We would prefer to keep things simpler and only permit pragmas in scopes where exports or imports are actually declared. Are there any downsides to that?
 [AS6]Ideally, the header file dhall be generated after elaboration - for example, in order to find all parameterzided class instances.
The downside of limiting pragmas to the same scopes where the DPI-OO declarations are located is that in such case the user cannot add pragmas non-intrusively,for example  in a separate package. Keeping pragmas in a sepatare package would enable using different pragmas in different integrated environments, without changing the core code.
 [AS7]All the legal foreign language strings should be defined; for example “C++” and “e” and “SC”.
 [AS8]I don't think that the standard shall limit the legal strings.  
 [AS9]Why is this treated specially ? 
Should be DPI-OO::BitVecValT*
 [AS10]The proposal is that de-referencing an unpacked array of packed arrays one will receive a pointer to one dimension, which is a packed array. In this case, we would like it to be consistent with the argument of a packed array type
 [AS11]Why this distinction ? Representing it in array syntax is more user friendly but less efficient. If   DPI_OO::LogicValT is represented as a class, size can be provided.
 [AS12]I didn't understand why it's less efficient. Making every sized array to be an object will cost additional memory management overhead.
 [AS13]What name should be chosen if the package name is not a valid C++ identifier ?
 [AS14]According yo the dpi_cpp_name property.
 [AS15]What is the advantage of keep two values ?
 [AS16]The semantics of inout-directed arguments allows the callee to return an array, class etc. other than the actual argument. If we don't keep two separate pointers on the caller side, then the caller will not be able to deallocate the input directed value and that can cause a memory leak.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.