ISAC: Minutes from meeting 19 June 2008

Please review these minutes carefully. There were many items discussed 
and I tried not to miss any.

Also, Peter has made several revisions. Lets meet this week to discuss them.



-- 
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 19 June 2008

Present: Peter Ashenden, Chuck Swart, Ajay Verikat

Absent: Jim Lewis, Larry Soule, Lance Thompson

Next meeting: Wednesday, July 2, 2008, 8 pm Pacific Daylight time
              (Thursday, July 3, 2008, 3 am GMT)

NOTE: No meeting next week. Next meeting in two weeks. Also, day
change from Thursday to Wednesday because of July 4 Holiday in U.S.

TOPIC: IEEE Ballot

So far there have been 11 votes received, all affirmative, no
abstentions, no negative for an 18% response rate. No substantive new
comments have been submitted. Chuck will check with Jim to see if
IEC has been notified of this ballot.

ACTION: Chuck to contact Jim about IEC contacts.

TOPIC: IR 2132 Method to allow functions that return arrays to have
knowledge of the array bounds

This is related to IR 2130 and deals with the difficulty of setting
size correctly when using arithmetic operations. These issues are
quite technical and we will defer discussion of them until after the
current version is approved.

TOPIC: Bugzilla 217 Confusing/contradictory requirements for viewport objects

This issue is resolved/fixed

ACTION: None.

TOPIC: Bugzilla 218 Permitted access into encrypted code unclear

Changes for VHDL200X have been made. Longer term changes require
feedback from Working Group P1735, so the status remains Open.
Question added in review: Shouldn't we change the resolution to LATER?

ACTION: Chuck to reassign to vhdl-lrm.

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

It was noted that expanded names were removed from draft D2 of the
2002 version,in response to a comment from Paul Graham who pointed out
that the prefix of an expanded name is not a signal. However, the
solution of dropping the phrase, was not correct, since a signal can
be indicated by means of an expanded name. Instead the phrase "An
expanded name whose prefix denotes a signal..."  should be changed to
"An expanded name that denotes a signal..."

ACTION: Chuck to update Bugz then assign to Peter.

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

This has been resolved, fixed.

ACTION: None.

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

Peter's analysis given in his email is accepted. Peter wants to use
Bugzilla to track this.

TOPIC: Interaction with VHPI experts.

So far John Shields has been the only VHPI expert to comment on any
of the related issues. It was agreed that Chuck will continue to seek
their response on issues which affect them.

ACTION: Chuck will issue a Bugz on this, copy Peter's email to the
Bugz and assign to Peter(Bugz number 233).

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

It was agreed that we need to allow forces, put_values and releases on
ports of mode IN. The most straightforward way is to relax the
restrictions on updates of mode IN objects to allow these but to
continue to forbid the "usual" ways of updating via signal
assignments. Perhaps add a note stating how ports of mode IN can be
updated.

ACTION: Chuck to update Bugz, assign to Peter.

TOPIC: Bugzilla 220 Inconsistent use of vhpiIntT and int

Calls to vhpi_get can return vhpiUndefined which is -1.  This is
inconsistent with one representation of vhpiIntT (see Bugz 229).  The
most consistent solution is to change the return values to int, which
is what is used everywhere else.

ACTION: Chuck to update Bugz, assign to Peter.

TOPIC: Bugzilla 229 Is type vhpiIntT signed or unsigned?

It was agreed that vhpiIntT and vhpiLongIntT should be signed. This is
consistent with the description in 22.2.3.

It was also noted that vhpiCharT should be unsigned to be consistent
with 22.2.4. As it is in the header file, it is just char, which may
be signed or unsigned depending on the implementation. Changed to
unsigned char.

Further, vhpSmallPhysT is changed to signed, to be consistent with
22.2.6.

The revised declarations are:

typedef int32_t vhpiIntT;
typedef int64_t vhpiLongIntT;
typedef unsigned char vhpiCharT;
...
typedef int32_t vhpiSmallPhysT;   




it was agreed that vhpiIntT and vhpiLongIntT should be signed. This is
consistent with the description in 22.2.3.

It was also noted that vhpiCharT should be unsigned to be consistent
with 22.2.4. As it is in the header file, it is just char, which may
be signed or unsigned depending on the implementation. Changed to
unsigned char.

Further, vhpSmallPhysT is changed to signed, to be consistent with
22.2.6.

The revised declarations are:

typedef int32_t vhpiIntT;
typedef int64_t vhpiLongIntT;
typedef unsigned char vhpiCharT;
...
typedef int32_t vhpiSmallPhysT;  

ACTION: Chuck to update Bugz (done by Peter).

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

comments from Peter: Results of checking for consistency between
associations in the info model and the definitions of vhpiOneToOneT
and vhpiOneToManyT:

In vhpiOneToOneT, the following do not correspond to any associations
and should be deprecated:

  vhpiBasicSignal
  vhpiCurEqProcess
  vhpiDecl
  vhpiIterScheme
  vhpiName
  vhpiOperator
  vhpiParamExpr

In vhpiOneToOneT, enum values for the following 1-1 associations are missing:

  Signal
  LibraryDecl
  SimNet
  AliasedName
  CompDecl
  ProtectedTypeInst
  GenIndex

In vhpiOneToManyT, the following do not correspond to any associations
and should be deprecated:

  vhpiCondExprs
  vhpiContributors
  vhpiEntityClassEntrys
  vhpiSensitivitys
  vhpiSpecNames

In vhpiOneToManyT, enum values for the following 1-many associations
are missing:

  GenerateStmts
  LocalContributors
  OptimizedContributors
  ParamExprs
  EqProcessStmts
  EntityClassEntries
  Sensitivity

I'd suggest the association Sensitivity be renamed to Sensitivities so
that it is plural, consistent with naming for other 1-many
associations.

For tracking purposes we will make this a Bugzilla issue.

ACTION: Chuck to transfer information to Bugzilla (number 233)

TOPIC: vhpiBootstrapFctT

This is in the vhpi.h file but is otherwise undocumented.

ACTION: Chuck to issue Bugzilla (actually issued by Peter, number 238)

TOPIC: Is vhpiTimeT signed or unsigned?

Type vhpiTimeT is described as unsigned, but objects of type TIME
may be negative. A Bugzilla will be issued on this.

ACTION: Chuck to issue Bugzilla (actually issued by Peter, number 237).

TOPIC: Backward incompatibility issue with package std_logic_textio\

Under the proposed standard this package contains no declarations,
with the statement that the declarations that used to appear in this
package have been moved to package STD_LOGIC_1164. The intent of the
empty package is to provide backward compatibility with designs that
used to have code like:

use ieee.std_logic_1164.all;
use ieee.std_logic_textio.all;

However code which references a declaration in std_logic_textio by a
selected name such as

... ieee.std_logic_textio.hread(...)...

will no longer compile.

This problem can be remedied by putting alias declarations in the new
version of std_logic_textio.vhd such as

alias hread is ieee.std_logic_1164.rising_edge;

The definition of homographs has been revised to make such
declarations practical and this solution has already been adopted when
the rising_edge and falling_edge functions were moved from package
numeric_bit to package standard.

ACTION: Chuck to issue Bugzilla and to poll VASG about this change.
(Bugzilla actually issued by Peter, 234).