[sv-cc] Comments on: Proposal uploaded for handling IP Encryption

Comments on proposal for #345:

26.3.5

"an boolean constant" --> "a boolean constant"

In the last sentence, vpiType and vpiIsProtected should be represented 
in bold face.
----------

26.6.19

To me, "shall allow iteration over the vpiArgument relationship" begs a 
lot of questions.  What can one do with the resulting returned objects, 
since they presumably are in a protected region, and therefore, "access 
to object relationships and properties shall be an error"?  Strictly 
speaking, that means that we can at most (a) count them, (b) find their 
vpiType, and (c) find out that they're protected.

Also, if it's important to allow access of some sort to the arguments, 
should we also allow access to the user systf?
----------

27.19

"If a scope at any level of the searched hierarchy is protected" is 
ambiguous.  One could interpret "the searched hierarchy" to be the 
whole design (if _scope_ is NULL) or the whole tree rooted at _scope_.  
Under that interpretation, if any scope in the searched tree is 
protected, you couldn't return a handle by name for any object anywhere 
in the tree, even if all the scopes from the object to the root were 
unprotected.  Did you intend that, or did you intend to prevent access 
only to objects that are themselves either protected or inferior to 
protected scopes?

Also, if the named object is not a scope but is protected, and if all 
the (superior?) scopes are unprotected, vpi_handle_by_name returns the 
named object.  What happens if the named object is a protected scope 
but all the (superior?) scopes are unprotected?
----------

"unless otherwise specified"

The proposal uses "unless otherwise specified" in every routine that 
could be applied to a reference handle.  It appears that the only 
routines that have any exceptions specified at the current time are 
vpi_get and vpi_iterate.  What is the reason for including the 
exception phrase in all the others?
----------

General philosophy:

It appears that the general approach has been to allow relationships 
that point a protected object or objects to succeed, but then to hide 
further information about the objects -- other than their vpiType.  
Thus, most of the "vpi_" routines fail if the reference handle is 
protected, but not if the returned object (if any) is protected.

An exception to this is the vpi_handle_by_name routine, which fails 
either if the reference scope is protected or if any scope in the path 
name is protected.  However, it will not fail if all the scopes in the 
path are unprotected but the named object is protected.

Is that it?

Perhaps a NOTE on the general philosophy would be helpful in 26.3.5.

Regards,
Jim Vellenga

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd 
Chelmsford, MA 01824-4179 
"We all work with partial information." 
---------------------------------------------------------- 
  
 

] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
] Behalf Of Steven Dovich
] Sent: Monday, April 11, 2005 12:10 PM
] To: sv-cc@eda.org
] Subject: [sv-cc] Proposal uploaded for handling IP Encryption
] 
] Mantis #345 has a draft proposal attached.
] 
] /sjd
] 
]