ISAC: Minutes from meeting on 05 June 2008

The next meeting is 12 June at the regular time.
Again, please try to attend. The more input we get,
the better quality of our solutions. Also, we are
very close to the end game--there are only a handful
of open issues (although the ieee ballot will probably
produce a few more).

Next week we would like to go over encryption issues.



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


Minutes of ISAC meeting held via telecom on 05 June 2008

Present: Peter Ashenden, Chuck Swart, Ajay Verikat

Absent: Jim Lewis, Larry soule, Lance Thompson

Next meeting:  Thursday, June 12, 2008, 8 pm Pacific Daylight time.
              (Friday, June 13, 2008, 3 am GMT)


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


ACTION: Chuck will propose new wording for "lost" sentence.

TOPIC: Bugzilla 230 float_pkg

The committee sees no strong reason to add or change the package
as proposed. Developers are free to use their own version of the
packages and a new standard might come out of that effort. The
committee did consider changing the name of the package from
float_pkg to float_754_pkg--there are mixed opinions on this issue.

ACTION: Chuck to contact Dave Bishop for his opinion on the potential
package name change.

TOPIC: Bugzilla 213 Can a force signal assignment update ports of mode IN?

There are two kinds of VHPI forces driving-value forces and
effective-value forces. Both are necessary for VHPI functionality and
the simple force assignment statement should reflect this requirement.
So the requirements and/or wording for updating need to be revised.
One possibility is to consider that a force is not an update: another
possibility is to redefine the meaning of update to allow forces on
input ports.

It was suggested that the wording on page 383 which states:
"It is an error if a VHPI program updates the value of a formal parameter of
mode IN." was inapplicable because it only deals with formal parameters.

This issue is still open.

ACTION: All to work on.

TOPIC: Bugzilla 214 Semantics of some READ procedures are not complete

The proposed solution is accepted.

ACTION: Chuck to assign to LRM writer.

TOPIC: Bugzilla 215 Problem with deallocation of lines in textio. 

The reported problem is accepted. Best solution is to add a general
paragraph describing the general behavior of the various READ procedures
and stating that deallocation may occur.

ACTION: Chuck to assign to LRM writer.

TOPIC: Bugzilla 222 condition expression should be boolean

The basic proposal is rejected. Some thought that the italicized
<boolean_>expression was not meant to imply an implicit conversion.
In addition, the production "condition" is retained, even though
it syntactically is just an expression. "Condition" carries sufficient
implication of a boolean value.

However it was proposed and suggested that the term "guard expression" should
be replaced by "guard condition" to reflect the same boolean implication.

ACTION: Chuck to assign to LRM writer.

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

We were unable to accurately track the complete origin of this requirement.
It comes from FT-19, but there is a reference to FT-19-1, which we couldn't find.
It appears that the submitter is saying that if the analyzer is expected to detect
certain error conditions associated with process( all ) semantics, then certain
analysis order dependencies are implied. 

The committee response is that there is no expectation that these errors be
detected in the analyzer--the discovery of the error condition might not occur until
elaboration time or even at (the start of) simulation. 

A similar issue exists with external names--in general their legality cannot be
established until (the end of) elaboration.

More study of this issue is needed.

ACTION: Chuck to contact John Riese (an author of this requirement) for feedback.