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

Vitaly,

   Some more comments with ARNAB2 prefix in purple. I am also attaching a slightly modified

version of the array interface classes. I have fixed the include guards and changed the name of

the bit and part select functions, to mixed case name matching DPI-C.

-Arnab

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Vitaly Yankelevich
Sent: Tuesday, September 27, 2011 9:06 AM
To: Saha, Arnab; sv-cc@eda.org
Cc: Arturo.Saltz@synopsys.com
Subject: {Disarmed} RE: {Disarmed} RE: [sv-cc] Uploaded DPI-OO proposal 1.0.4

More comments with [Vitaly2] below:

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Saha, Arnab
Sent: Tuesday, September 27, 2011 6:45 PM
To: Vitaly Yankelevich; sv-cc@eda.org
Cc: Arturo.Saltz@synopsys.com
Subject: {Disarmed} RE: {Disarmed} RE: [sv-cc] Uploaded DPI-OO proposal 1.0.4

Vitaly,

    More comments in GREEN below with ARNAB prefix.

-Arnab

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Vitaly Yankelevich
Sent: Tuesday, September 27, 2011 8:07 AM
To: Saha, Arnab; sv-cc@eda.org
Cc: Arturo.Saltz@synopsys.com
Subject: {Disarmed} RE: [sv-cc] Uploaded DPI-OO proposal 1.0.4

Hi Arnab,

Thanks for your comments.

Assuming that we converge on representing all arrays as classes, would you agree that the items addressed by your comments AS9, AS11 and AS15 need to be re-considered anyway? If we represent arrays by classes then the question of consistency with DPI-C is relevant only for the class methods but not for the classes and operations with them. Would you agree with that?

ARNAB: Yes, but I have some comments related to this below.

Please see the rest of my comments below, prefixed with [Vitaly]:

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Saha, Arnab
Sent: Tuesday, September 27, 2011 11:47 AM
To: Vitaly Yankelevich; sv-cc@eda.org
Cc: Arturo.Saltz@synopsys.com
Subject: {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 ?

[Vitaly] Yes

If the imported class is declared in C++ with virtual inheritance, how will that work ?

[Vitaly] Not sure what problem with virtual inheritance. Are you asking about mapping the C++ classes with virtual inheritance
(e.g. class A: public virtual B {…};) to SystemVerilog. IMO the virtual inheritance is used normally together with multiple inheritance.We don’t support multiple inheritance for now. Please clarify I misunderstand your question.

ARNAB: My concern was with implicit creation of a copy class using malloc when the class is a non-POD class with virtual inheritance. You have to create such classes with new otherwise their virtual table won’t get created correctly.

[Vitaly2] I was talking about the SystemVerilog copy classes and their constructors. Proxies for copy classes will have empty constructors so they can be invoked. Also, on the somewhat unrelated note, copy class proxies should not use virtual inheritance because they have no methods.

ARNAB2: ok , I need to check this again and get back to you.

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 ?

[Vitaly] Let’s consider such use case:

Package P;

  Class C#(type T = int);

   …

  endclass

endpackage

module M;

  class X; .. endclass

  C#(X) var;

endmodule

In the above case, type X is defined in the module. That means, there is a different class X per module instance. Consequently, there is a type C#(X) per module instance. We cannot map such types to the C++ intermediate layer. That’s why I propose to limit the support of parameterized classes only to those class instances which are defined in packages and compilation unit scopes.

ARNAB: If X is declared in some other package say “P2”, would it be allowed in that case ? My case will still be valid then as long as the type T in my example is a type defined in a package and not in a module scope ? Say if the module “mod” in my example was instantiated as

import P2::*;

mod i_mod #(P2::X) ();

[Vitaly2] I suggest to support only the instances of the parameterized classes which appear in the packages and the compilation units. Otherwise, the user view is rather complicated: we’ll need to explain that all instances are supported except those which are parameterized by the types defined in a module. If you feel strongly in favor of the supporting instances in the modules – I can agree with that too.

ARNAB2: I would like to allow that but since we don’t have enough time to think about all the implications, I am fine with postponing this for the next rev. I would also like to see this spelled out somewhere.

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.

[Vitaly] OK

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 ?

[Vitaly] I accept your observation. I would prefer still to allow pragmas in the scopes other than the scopes of the DPI-OO declarations. IMO, it’s very important for development of reusable SystemVerilog code to keep the C++/foreign code configurationproperties separately from the SystemVerilog declarations. Something like this:

package P;

  Export “DPI-OO” “ref” class C;

endpackage

package Conf;

  import P::*;

`pragma DPI-OO export class=C exclude=(f1,f2);

endpackage

ARNAB: In the above case, we should be able to generate the header while compiling package Conf.

[Vitaly2] I would prefer that.

I will wait for you comment on “parameterized class” section above to further comment on this.

ARNAB2: This is ok.

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.

[Vitaly] I see your point. The problem for me is that if we standardize the strings we limit the vendors from connecting SystemVerilog to other languages (for example, Java or matlab or anything else)

ARNAB: IMO we should standardize the strings we know of now. Vendors wishing to extend this to languages other than what is standardized, can still do so. We can come back in the future pars and get those added as they show up.

[Vitaly2] OK, agreed.

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.

[Vitaly] See my comment at the top of the email.

ARNAB: I agree, although it should be a pointer to the container class not a double pointer.

[Vitaly2] Agreed

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.

[Vitaly] Same as above

ARNAB: I agree

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.

[Vitaly] dpi_cpp_name syntax is [dpi_cpp_namespace_identifier::]identifier. So it can be used for example as follows:

Package STD;

  import “DPI-OO” “ref” class C dpi_cpp_name=SVSTD::C;

endpackage

This way the user can avoid conflicts of the namespace identifiers.

ARNAB: if the package above is named “\mypack $$“ or some other identifier that is not a legal C++ id, you will have to use dpi_cpp_name for every DPI-OO declaration in that package ? That does not look very user friendly to me. We should probably disallow package names that are illegal C++ identifiers ?

[Vitaly2] My preference is to put less limitations. I’m more concerned about the name collisions (when the SystemVerilog package name is a legal C++ id but it conflicts with some other C++ name (like std for STL). Specifying the namespace for each declaration is a lesser evil than prohibiting a package completely.

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.

[Vitaly] See my comment at the top of the email.

ARNAB: This applies to all data types passed as inout ports, not just arrays, so I am not sure if your comment about converting arrys to class representation covers this.

[Vitaly2] Scalar types don’t require deallocation, hence double asterisks are not needed for them. Concerning the classes: it should not be a conflict with DPI-C because the latter does not support classes anyway.

ARNAB2: So the above paragraph needs to exclude struct and arrays and should only include classes ? I would prefer to exclude classes as well, to have consistent semantics, but would be ok with different semantics for classes if you have a strong opinion.

Thanks,

Vitaly

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. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is 
believed to be clean. 
________________________________
 Is this still applicable with copy classes as classes in C++ ?
 Yes
 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..
 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. 
 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?
 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.
 All the legal foreign language strings should be defined; for example “C++” and “e” and “SC”.
 I don't think that the standard shall limit the legal strings.  
 Why is this treated specially ? 
Should be DPI-OO::BitVecValT*
 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
 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.
 I didn't understand why it's less efficient. Making every sized array to be an object will cost additional memory management overhead.
 What name should be chosen if the package name is not a valid C++ identifier ?
 According yo the dpi_cpp_name property.
 What is the advantage of keep two values ?
 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.