I posed a key review concern about disclosed names and VPI, DPI, and CLI . I have had some feedback and we have done some analysis in house. My proposed resolution for DPI is to allow a disclosed name to be properly recognized. It is based on the P1735 visibility concept of preserving model fidelity and staying true to the default expectation of protection for the IP author.

Summary of the rationale

The summary is that the need for this is intended by the IP author in important, widely understood use cases and DPI does not create an opportunity for malicious discovery of protected information. In order to appreciate this, you need to understand DPI and what you can and cannot do with it. You also need to understand the nature of its use cases. I would generalize this in our P1735 visibility clause and describe the high level intent for disclosed names and their visibility as well as needed restrictions. I think getting your understanding is where to start to justify this proposal.

Details

One use case is for a testbench that uses verification IP and has System C or other behavioral C reference models that it must interact with. Verification IP is reusable technology that has high value and its authors want to use P1735 protection for it. It is equally true in a virtual prototype for an SOC, which has high performance models for various system components. Consider the common use of an ISS for the software component, always written in C/C++. The mechanism that links such components written in C with SV code is DPI. The general statement is that DPI is a necessary language feature and we have to define how it can be used with protected IP. It did not exist when IP protection was added to 1364, only VPI did. It is very relevant that P1735 takes a position with respect to our default expectation. Fortunately, DPI does not provide a mechanism for discovery of protected information like VPI and this will make it reasonable to allow it.

It will be difficult to provide a deep understanding of DPI in an email and the LRM itself is a significant read. My goal here is to pick out the essential features and make some assertions about what they imply in the context of IP protection.

DPI is used to call C routines from SV code (import DPI functions) as well as to call SV code from C code (export DPI functions). DPI code exchanges its data by parameter passing. It has no mechanism to navigate an information model and obtain access to other objects. Only VPI can do that. There is the concept of a context import DPI function. It associates the DPI function with an instance in the design hierarchy, providing an execution context. It enables two important features. First, the function can save some private data with the instance and retrieve it. Second, it allows exported DPI functions to be called. It enables a third feature, the ability to use VPI within the DPI function, but there is no linkage between them per se. The DPI context is not a VPI context, nor does it give a mechanism to obtain one. As a result, the issue of what can be done with VPI in a protected region remains orthogonal. It does not matter that VPI could be called from a DPI function.

In order for a protected IP to call imported DPI functions or export SV functions to be called, its SV code must be compiled with appropriate import and export declarations. What is essential here is the IP author is a party to enabling DPI to be used by the use of these declarations and for imports, making the actual call to the imported foreign routine. There is no malicious path for an IP user to enable unintended import or export DPI with a protected IP. Having a clear expression of intent by the IP author to use DPI, allowing DPI to work properly preserves model fidelity.

As was stated, the foreign code written for a DPI function exchanges its data by parameter passing. The interface at the parameters of a DPI function do not allow pass by reference. There is no exposure to protected information available to the IP user from DPI except what can be passed by value from a call inside a protected IP made by the IP author. There is a large body of detail related to argument handling in the LRM, but it has no impact on IP protection issues.

There is a set of utility routines provided for context import functions to use. They establish and query the DPI execution context and provide mechanism to put/get private, instance specific data. There are 7 functions and this is the area where P1735 default expectation must be interpreted, where disclosed names have an important role. You can look in the LRM in Appendix H, the (normative) DPI C layer for details. The 7 routines are:

1. svScope svGetScope();
2. svScope svSetScope(const svScope scope);
3. const char* svGetNameFromScope(const svScope);
4. svScope svGetScopeFromName(const char* scopeName);
5. int svPutUserData(const svScope scope, void userKey, void userData);
6. void* svGetUserData(const svScope scope, void* userKey);
7. int svGetCallerInfo(const char **fileName, int *lineNumber);

(4.) is a key function required to establish the context for an import DPI function and it enables the use of 2, 5, 6. This is what provides the important features I noted above and which are essential to the use cases I noted. (4.) requires a scope name, which is a pathname to a instance. In order to use this for protected IP, the disclosed name of that path must be allowed to obtain the scope. This is as close to elaboration linkage as DPI can get. (3.) and (7.) should be effectively disallowed in a protected context and required to return meaningless data. (1.) is fine to use, but is not sufficient.

What happens today is that the IP author has to leave their IP or aspects of it unprotected with disjoint envelopes. That is needless exposure and risks portability. There is a possible argument that could be made for yet another explicit mechanism to declare intent to use DPI. It is a bad argument, whether it is using a modified form of the viewport pragma or some new, common right. The fact is, the IP author has already expressed clear, unambiguous intent that DPI be used. If it was in their interest to protect IP authors from themselves by disallowing DPI, that might justify it. There is just nothing further to protect. My proposed resolution for DPI is to allow a disclosed name to be properly recognized and that the high level intent is for DPI to be usable with protected IP.

Related Concerns

This is already a long email. I believe VPI is ill defined with respect to IP protection, but there was an intent to make it as useful as it can be in protected regions without risking exposure. The result falls short of what is possible and has some inconsistencies. The framers of IP protection did not have the time to get it right, and they did they not start with a good definition of what would be right. I believe we could allow or disallow disclosed names in vpi_handle_by_name and make good, but pedantic arguments either way. If that is all we did, VPI would remain as useful as it currently is in protected regions, no matter what we decided about disclosed names. My opinion is that it is not useful in protected regions ( at best, very narrowly useful.) There is just a solid barrier to malicious discovery of protected information. That is why the fact that a context import DPI routine can use VPI is of no concern for a protected region. My plan is keep all of the VPI issues in Annex C as unresolved in this version of P1735.

I will address VPI and CLI with respect to disclosed names in more detail separately.

Regards, John

-- JohnShields - 2014-02-21