ISAC: Minutes from meeting on 12 June 2008

These minutes are also available at the website.

Chuck Swart


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


Minutes of ISAC meeting held via telecon on 12 June 2008

Present: Peter Ashenden, Larry Soule, N.S. Subramanian, Chuck Swart, Ajay Verikat

Absent: Jim Lewis, Lance Thompson

Next meeting: Thursday, June 19, 2008, 8 pm Pacific Daylight time
              (Friday, June 20, 2008, 3 am GMT)

TOPIC: IEEE Ballot

LRM version 4.2 is now being balloted. Several votes (positive) have
been cast. Peter voted affirmative with a comment that open Bugzilla
issues need to be addressed.

TOPIC: Bugz 231 process( all ) -- compiler cannot infer the sensitivity list

It has always been recognized that error checking for process( all)
semantics cannot be completed by the analyzer.

ACTION: Chuck to update Bugz, Peter to add note to LRM to this effect.

TOPIC: Bugz 230 float_pkg

It was agreed to not change the package at this time. We can add
another package if and when fpga vendors agree on a common form.

ACTION: Chuck to update Bugz.

TOPIC: Bugz 217 Confusing/contradictory requirements for viewport objects

When a protect comment is found in the source text of an encryption
envelope it is removed from the source text and placed in an
unspecified location in the decryption envelope. The term "source
text" is used before it is formally defined.  One way to resolve this
is to change the misleading sentence on line 19 page 435 of the clean
text which reads:"An encryption envelope is a portion of the
description that is to be encrypted, and a decryption envelope is a
portion of the decryption containing previously encrypted text to be
decrypted."  To something like: "An encryption envelope contains
protect directives and a portion of the description, called the source
text, that is to be encrypted. A decryption envelope contains protect
directives and a portion of the description containing previously
encrypted text to be decrypted."

Note that there is an unrelated typo in this sentence: "a portion of
the decryption" should be "a portion of the description".

ACTION: Chuck to update Bugz and assign to Peter.

TOPIC: Bugz 218 		Permitted access into encrypted code unclear

There is general agreement that access to protected regions should not
be given to command line execution, VHPI, etc. except through
viewports. Its not so clear whether access to such regions should be
given to VHDL source code, whether encrypted or not. An example would
be the use of hierarchical references.  One problem is that if access
is granted to encrypted code but not to unencrypted code, then the
perpetrator could simply encrypt his code.  If this is to be allowed,
then some restrictions are probably needed, such as requiring that
VHDL code which accesses an encrypted region must be encrypted by the
same user.  In any event, some verifiable process is needed. It was
pointed out that fine granularity of access is not currently used in
practice. So for this version of VHDL, we will only allow access to
encrypted VHDL code from the same protected envelope.  We will
reexamine this issue as part of ongoing review and also will
communicate with the IEEE working group that deals with encryption
issues.

ACTION: Chuck to contact working group, Peter to add restriction to LRM.

TOPIC: Bugz 219 		What directives can appear in encrypted source text and ...

The questions raised are already adequately covered by the LRM.
License directives and viewport directives are encrypted. The
decrypting tool decrypts them just as it does any data stream. After
they have been decrypted, the analyzer can perform error checks and
consistency tests. No special knowledge is required by the
encrypting/decrypting tools since the checks are performed on
decrypted code.

Also, the questions about nesting protect comments in VHDL comments
and vice versa are already covered. The key observation is that token
processing includes processing comments.  So a VHDL comment embedded
in any 'protect directive (including a comment) would be viewed as
data related to the directive (often producing an error
case). Similarly, a 'protect directive inside a VHDL comment would be
treated as part of the comment and ignored.

ACTION: Chuck to close.

TOPIC: IR2131 Vhpi_user.h requires enum types contents update/completion

We will discuss this along with other VHPI issues at next
meeting. Meanwhile, Peter will look into mechanisms to automatically
generate enumeration values for "terminal" (non-abstract) classes.

ACTION: Peter to look into this.

TOPIC: Bugz 227  glossary entry for expanded name has incorrect reference

ACTION: Chuck to work on better wording.