ISAC Minutes of meeting held 03 March 2005

I'm attaching the minutes. They are also available on the website.

Chuck



Minutes of ISAC meeting held via telecom on 
03 March 2005

Present: Peter Ashenden, Larry Soule, Chuck Swart, Ajay Varikat

Absent: Jim Lewis, Deepak Pant

Next Meeting: Wednesday April 06 2005, 8 pm Pacific Daylight Time 
             (Thursday April 07 2005, 3 am GMT)

NOTE: Meeting day change from Thursday to Wednesday!

TOPIC: IR 2058 Does USE of type name make operators and literals visible?

Some new issues were raised.

A. Visibility of enumeration subtypes

Consider:

    PACKAGE p1 IS
		TYPE enum1 IS (A,B,C,D);
        SUBTYPE enum2 is enum1 RANGE B TO C;
    END PACKAGE p1;

    USE work.p1.enum2;

According to the proposed solution all enum literals would become
visible.  An alternate proposal is to make only the enums identified
by the subtype declaration, B and C, visible.

Subtype declarations use subtype indications which are very
general. For example, the following subtype declaration is legal (in
the context of the above example).

        SUBTYPE enum2 is enum1 range A to general_function(1);

If you were to USE enum2, the analyzer hasn't enough information to
restrict the visibility of enumeration literals from enum1.

So, in general it seems most reasonable to ignore the constraint
of the subtype in determining visibility.

A counterproposal is to restrict visibility of enumeration subtypes if
the subtype indication is sufficiently limited. It seems that a
locally static range would suffice.

B. Subtypes declared in a different package from the base type.

Consider:

    PACKAGE p1 IS
		TYPE enum1 is (A,B,C,D);
    END PACKAGE p1;

    USE work.p1.ALL;
    PACKAGE p2 IS
        SUBTYPE enum2 is enum1 range B to C;
        -- overload the "=" operator from P1;
        FUNCTION "="(left,right:enum2) return BOOLEAN; 
    END PACKAGE p2;

    USE work.p2.enum2;
    ENTITY e IS...

What names/operators should be visible in entity e?  The general
consensus is that

    enum2 and the overloaded "=" operator declared in

package p2 should be visible.  This preserves the idea/principle that

    USE p.x makes (potentially) visible a subset of USE p.ALL;

The currently proposed solution will need to be slightly revised to
reflect this.

C. IF a subtype is USEd should the base type become visible?

Consider:

    PACKAGE p1 IS
		TYPE enum1 is (A,B,C,D);
        SUBTYPE enum2 is enum1;
    END PACKAGE p1;

    USE.work.p1.enum2;

When enum2 is USED should enum1 also become visible?

Argument in favor: The fundamental proposal for this IR is to make the
predefined operators visible when the type or subtype is USED. The
parameters to these operators are of the base type.  It is confusing to
have operators visible, but to have the types involved in the operator
not visible.

Argument against: Extra visible names pollute the name space. If you
want the type to be visible then USE the type.  Also, what about

      TYPE int1 IS RANGE 1 TO 10;
      SUBTYPE int2 IS int1 RANGE 2 TO 5;
....
      USE int2;

In this case the base type is anonymous, but do you make the declared
"first named subtype" int1 visible? If so, this might lead to a
complicated set of rules determining which subtypes to make visible.

ACTION: Chuck to submit this issue for an ISAC vote.

Then Chuck to update the IR reflecting the vote.  The final IR will
mention these alternative for consideration by the VASG.

ITEM: IR2062 Range staticness

The test case reports that the expression

   sub: for i in a'range generate

where "a" is a generic, is illegal.

It is true that the current LRM rules disallow this.  Consensus was
reached that it would be a good idea to allow this, and that simple
changes in clause 7.4.2 to the definition of globally static range
could be added, something like "A globally static range is either ...
whose prefix denotes either a globally static subtype or an object
that is of a globally static subtype " add "or is a globally static
object".

A side question was raised:

Why is the following illegal, where fcn is an impure function:

    sub: for i in 0 to fcn(1) generate

when the following is legal

   generic g1:int := fcn(1);

   ...

   sub: for i in 0 to g1 generate

Answer: (Added after meeting)
12.3.1.3 states:

"Elaboration of a range constraint consists of the evaluation of the
range.  The evaluation of a range defines the bounds and direction of
the range." The LRM does not specify an order for these calculations.
Thus an expression like:

    sub: for i in fcn(1) to fcn(2) generate

could produce different values depending on the order of evaluation of
the impure function fcn.

This analysis shows that the requirement that the range be static is a
reasonable one.

ACTION: Larry to analyze the main issue.

ITEM: IR2063 Unconstrained array formals should not get subtype from actuals

It was agreed that the LRM is not consistent in describing index
ranges for actuals, sometimes referring to subtypes other times to
index ranges.

The general question arose: why don't all expressions have subtypes?
One reason is that too much type/subtype inference would be involved,
and some of this could not be done in the analyzer. The existing model
is that many operations occur using the base type along with subtype
checks in identified places.

Peter pointed out that clauses 2.1.1.1 and 2.1.1.2 will be extensively
rewritten to implement Fast Track item FT14 records of unconstrained
type.

So it was agreed to forward this issue to VHDL200x fast track.

ACTION: Chuck to forward.

ITEM: IR2042 Architecture as a block causes problems

Peter mentioned that the rewrite of this is very complicated.
Therefore, he would like to have the IR ISAC and VASG approved
with regard to intent before putting in the significant effort involved.

ACTION: All to vote on.

ITEM: IR2048 Miscellaneous errors

This is ready for an ISAC vote.

ACTION: All to vote on.

ITEM: IR2051 Path_name and instance_name do not allow for protected types

This is ready for an ISAC vote.

ACTION: All to vote on.


ITEM: IR2061 Default actions on severity flags is different between simulators

This was approved.

ACTION: Chuck to forward to VASG.