Date: Tue Oct 11 2011 - 06:34:23 PDT
Arturo, I wanted to add a bit more to what Vitaly says in the exchange listed below. I agree with you that we need one proxy for each object exported by C++ and used by SV (and for the sake of this discussion, we can call that an "SV proxy"). And for each object exported by SV and used by C++, we need another proxy object (and for now we can call that a "C++ proxy"). But it looks to me like our view differs from yours in that we don't see the "SV proxy" as being implemented in SystemVerilog, but rather as implemented in C++. We also see the implementation of the "SV proxy" in C++ as being distinct from, but mapped to, the implementation of the object exported by the C++ user code.
The advantages of having the two separate C++ implementations are
-- The same "SV proxy" implemented in C++ can now be used as a "SystemC proxy" for the same exported C++ object.
-- Similarly, the same "C++ proxy" for an object exported by SystemVerilog can also be used as a "SystemC proxy," again without change of implementation.
-- Once again, this provides a separation of implementation so that each exporting language needs only one implementation per class, as does each importing language.
The apparent asymmetry exists only because we have chosen to use C++ both as the proxy implementation language and as the sample "other language" within the proposal. The use of proxies is symmetric among communicating languages, but it happens that we have chosen to specify implementation of the proxies in the particular language C++, since it is a well-defined and mature object-oriented language.
Regards,
Jim Vellenga
- Asymmetry between C++ and SV. Generally, a proxy class is needed in both languages: a C++ proxy that handles method calls from C++ to an export SV object, and an SV proxy to handle method calls from SV to an imported C++ object. In the first case, the actual object is an SV class hence a proxy is needed in the C++ side; in the latter case, the actual object is a C++ class and the proxy is needed in the SV side. The proposal seems to only discuss C++ proxies, which makes the whole proposal very confusing.
[Vitaly] The proxies are the implementation artifact, not a part of the user view. They constitute the DPI-OO API, implemented in the object-oriented representation. An alternative could be to "flatten" the API and implement it in C. In that case there would be no use of the term "proxy" in the proposal.
Given the above, there is a need only for one language to implement the OO API and there is no need for SystemVerilog proxies. You probably got confused by the fact that C++ is the most obvious end user foreign language, and at the same time it's an implementation language. However, this coincidence of the languages has nothing to do with the design of the solution.
The end user is expected to operate with her/his own classes, not with the proxies.
Jim Vellenga | Member of Consulting Staff | Cadence
P: 978.262.6015 F: 978.262.6636 www.cadence.com<http://www.cadence.com>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
