ISAC: Minutes from meeting on 12 April 2007 REVISED

I cheated a little, by updating the minutes to incorporate an
email from Larry Soule. He had previously sent me a status
report, which I inadvertantly failed to mention in the meeting. So I 
updated my records,
assigned more IRs for Larry to review, and reflected these
facts in the minutes.

I'm probably violating the Official Secrets Act and the
Sarbanes Oxley Act, but I'm willing to forfeit a percentage
of  money IEEE pays me in order to keep our records straight.

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 telecom on 12 April 2007
Revised on 13 April to include input from Larry Soule

Present: Peter Ashenden, Chuck Swart, Ajay Verikat

Absent: Jim Lewis, Larry Soule, Lance Thompson 

Next Meeting (tentative) Wednesday May 2, 2007, 8 pm Pacific Daylight Time
                        (Thursday, May 3, 2007, 2 am GMT )

TOPIC: IR 1000 Accumulated typographical and terminology errors

Several minor issues were discussed and resolved. We agreed to refer
to the draft standard as P1076-2007-D3.0. It was also discovered that
there were differences between the hard copy of VHDL-2002 and the pdf
version.

ACTION: Peter to make final revisions (done) then ISAC to vote.

TOPIC: IR 1070 VPI Issue 14 -- Prefixes in USE clauses

The issue concerns legality of a package, pkg, that contains a type
named "work" along with

use work.pkg.all,work.definework;

The issue is whether work.definework is legal here because of the
possibility that "work" now refers to the type in the package.

Peter's initial analysis was that the example is legal because the
visibility associated with the use clause takes effect at the end of
the use clause.  However, this analysis implies that

use work.pkg.all;
use work.definework;

would be illegal. Chuck argued that the second example is also
legal. The clause use.work.pkg.all makes the type "work" potentially
visible. However, it does not become directly visible because the type
"work" is a homograph of the visible library name "work".

Discussion also revealed some issues with clause 11.2, Design libraries.

The LRM states: "...each logical name defined by the library clause is
directly visible, except where hidden in an inner declarative region
by a homograph of the logical name according the the rules of 10.3"

10.3 defines "homograph", but 10.4 gives the rules for USE clauses, so
it probably makes sense to refer to both 10.3 and 10.4.

Also, homographs apply only to declarations and library names are not
(technically) declarations. Wording should be added to treat library
logical names as declarations for purposes of overload resolution.

ACTION: Peter to revise his analysis.

TOPIC: IR  2110 Implicit subtype conversions not defined

Clause 7.3.5, Type conversions only deals with explicit conversions
(and implicit conversions involving universal arithmetic types, which
are not relevant for this issue). It would be good to expand this
clause to refer to implicit type conversions as well.

Analysis of this issue uncovered that fact that the semantics of array
signal and variable assignments utilize the subtype of the array
variable or signal.  Although the intent is clear, and implementations
do the right thing, there are at least two problematic cases. First, a
slice does not have a subtype, although assignment to a slice is
legal. Second, a formal parameter of an unconstrained type has a
subtype (which is unconstrained), but the implicit conversion needs to
use the index range of the actual.

One possibility is to rewrite the rules for "sliding" in array
assignments so that they don't use subtypes. Another possibility is to
create some sort of implicit subtype for the relevant cases, and then
to add implicit type conversions to clause 7.3.5.

It was noted that Ada faced the same issue, but resolved it by adding
a great deal of technical machinery (views, actual subtypes, nominal
subtypes, etc). It is hoped that we can resolve these issues without
adding as much to the language.

ACTION: Chuck to analyze.

TOPIC: IR 2111 Unknown term used:  selector

Chuck's analysis is accepted. 

ACTION: All to vote.

TOPIC: IR 2112 Can attributes be applied to a signal on the entity
within the architecture for that entity?

Peter's analysis is accepted. It was observed that the attribute
decorates the entity decl, not the entity instance.

ACTION: All to vote.]

TOPIC: IR 2099 Alias declarations introduce homographs

There appears to be one remaining open issue related to EXAMPLE 5:

Consider:

  package p1 is
     function "=" (a,b: ieee.std_logic_1164.std_logic ) return boolean;
     ...
   end package p1;
 
   package p_test is
     use work.p1.all;
     ...
     alias std_logic is ieee.std_logic_1164.std_logic;
     -- implicit "="
     -- alias "=" is ieee.stdlogic_1164."=" (a,b: std_logic) 
 return boolean;
   end package p_test;
 
 
In a declarative region you:

   use p_test.all;


Which, if any, "=" operator for std_logic is visible in that
declarative region?

It shouldn't be the overloaded "=" from p1, since visibility isn't
transitive through packages. It seemed to Chuck to be strange that the
implicitly declared "=" would be visible, since that operator isn't
visible within the package p_test.

Peter pointed out that the implicitly declared "=" operator is visible
in p_test, although its not directly visible.  So p_test."=" refers to
the implicitly declared operator.

ACTION: Chuck to consult with John Ries and to update analysis as appropriate.

TOPIC: Review of IRs incorporated into D3.0

2081   2006-040  Larry OK  
2082   2006-046  Larry OK
2083   2006-042  Lance 
2084   2006-043  Lance 
2086   2006-047  Lance 
2087   2006-044  Ajay  OK 
2090   2006-045  Ajay  OK
2092   2006-048  Ajay  OK
2093   2006-049  Chuck OK 
2094   2006-050  Chuck OK  
2095   2006-051  Chuck OK 

ACTION: IRs to be examined for next meeting:

2083   2006-042  Lance 
2084   2006-043  Lance 
2086   2006-047  Lance 
 

TOPIC: Review of Pre-2002 IRs

1055    Larry   All Issues Resolved
1056    Larry   Open Issues
1057    Lance
1058    Lance
1059    Ajay    Open Issues
1060    Ajay    Open Issues
1062    Chuck   Open Issues
1063    Chuck   All Issues Resolved
1064    Peter   Open Issues
1066    Peter   Open Issues
1069    Peter   Open Issues
1070    Peter   Open Issues

ACTION: Pre-2002 IRs to be examined for next meeting:

1057    Lance
1058    Lance
1071    Ajay
1072    Ajay
1074    Ajay
1075    Chuck
1076    Chuck
1077    Chuck
1079    Peter
1081    Peter
1082    Peter
1085    Larry
1086    Larry
1088    Larry