ISAC: Minutes from meeting on 09 December 2004

From: Chuck Swart <cswart@model.com>
Date: Tue Dec 14 2004 - 10:35:41 PST

Attached are:
Minutes from ISAC meeting held on 09 December 2004
Preliminary analysis of IR 2048
List of active IRs.

Minutes of ISAC meeting held via telecom on
09 December 2004.

Present: Peter Ashenden, Deepak Pant, Chuck Swart, Ajay Varikat
Absent: Jim Lewis, Larry Soule

Next Meeting: Thursday 06 January 2005 7pm Pacific Time.

TOPIC IR2040: Problems with OTHERS in aggregates

Peter suggested some wording changes which removed redundant
clauses which could cause misinterpretations. Ajay accepted
these changes.

Chuck pointed out that section 7.3.2.2 mentions the subtype of
an aggregate and the index subtype of an aggregate.
These are technically incorrect. Aggregates have ranges, but
not subtypes.

ACTION: Ajay to incorporate Peter's suggestions.
Chuck to issue a separate IR on subtypes in aggregates.
All: to vote on Ajay's next revision.

TOPIC: IR 2048 Miscellaneous errors

Twelve issues were raised by the IR and extensive discussion occurred.
See the attached analysis of this IR for details.
Note: Chuck performed the first pass of the analysis. Someone else needs
to take this over.

ACTION: ALL to review, someone to continue analysis.

TOPIC: IR 2015 Generics should be able to incorporate other generics

Chuck check Ada 95 and discovered that Ada does not allow the proposed
extension (incorporated into the analysis of the IR). This entire
issue is part of an effort to enhance generics as part of Fast Track.

ACTION: ALL to vote on forwarding this to Fast Track

TOPIC: IR 2018 Variable IN parameter should be no different than constant

Parameters of access type were discussed. It was mentioned that if a
parameter of class VARIABLE mode IN were of an access type, then the
designated value is still of class VARIABLE, hence is modifiable. So
the correct semantics of such a parameter is that you can't change the
access value, but you can change the designated value. It might be
useful to adopt a notation to deal with this (similar to the multiple
locations of CONST in C++).

In any event, the basic issue which the IR proposes is rejected: There is
merit in both constants and variables of mode IN.

ACTION: ALL to vote on approving this IR.

TOPIC: IR 2019 Reading outputs from within architecture

This is Fast Track Issue 12.

ACTION: ALL to vote on forwarding this IR to Fast Track

TOPIC: IR 2020 keyword REPORT is over-used

The submitter has a vailid point in that the addition or deletion of a single
";" produces two legal but very different sequences of statements. However, there
is no realistic way to repair this without breaking backward compatibility.

ACTION: ALL to vote on approving this IR.

TOPIC: IR 2021 Dynamic hardware construct

As part of the discussion it was stated (by Chuck) that we will
eventually need some way to factor designs into a "hardware" section
and a "testbench" section with relaxed semantics for testbenches.

This particular IR needs considerable refinement to gather requirements, and
should be forwarded to the 200X subcommittee.

ACTION: ALL to vote on forwarding this IR to 200X SC

TOPIC: IR 2022 Elements of constant composite to be locally static

This request should be part of Fast Track 22.

ACTION: Chuck to analyze/edit.
ALL to vote on forwarding this IR to FT 22.

TOPIC: IR 2023 Add predefined array types for integer, boolean, real and time

The obvious vector types to add are:

REAL_VECTOR (which is in the 1076.1 package STANDARD)
BOOLEAN_VECTOR
INTEGER_VECTOR
TIME_VECTOR

The major question here is that of backward compatibility. Packages currently
define these types would have to be modified. The ISAC members do not have
enough information to judge how serious this impact would be.
NOTE: I (Chuck) spoke with VASG chair about this. His recommendation is that
we try to get information from various sources such as comp.lang.vhdl and
the 200X mail group, then make our best educated guess about the solution.

ACTION: Someone (any volunteers?) needs to contact various public forums about
this issue.

-------------BEGINNING OF IR----------------

VHDL Issue Number: 2048

Language_Version: VHDL-2002
Classification: Language Definition Problem
Summary: Miscellaneous errors
Relevant_LRM_Sections: various
Related_Issues:
Key_Words_and_Phrases:
Authors_Name: Tristan Gingold
                        (by Peter Ashenden on behalf of submitter)
Authors_Phone_Number:
Authors_Fax_Number:
Authors_Email_Address: tgingold@free.fr
Authors_Affiliation:
Authors_Address1:
Authors_Address2:
Authors_Address3:

Current Status: Submitted

Superseded By:

------------------------
Date Submitted: 29 November 2004
Date Analyzed: 10 December 2004
Author of Analysis: Chuck Swart
Revision Number: 1
Date Last Revised: 10 December 2004

Description of Problem
----------------------

1) The return type of a function can be a file type.
   However, it is of course not possible to write a correct body for such
   a declaration.

   Proposition: The return type of a function must denote neither a file type
   nor a protected type.

VASG-ISAC Analysis & Rationale:

   Functions return values.Since neither files nor objects of
   protected types have defined values, it doesn't make sense to allow
   them.

   The submitter's proposed solution is accepted.

VASG-ISAC Recommendation for IEEE Std 1076-2002

   No change.

VASG-ISAC Recommendation for Future Revisions

   Add to section 2.1 the statement:

   "It is an error if the return type of a function denotes either an
   access type or a protected type."

   In section 3.5.1, change the sentence which reads:

   "Additionally, in the case of a function subprogram, the return
   type of the function must not be of an access type or file type;"

   to:

   "Additionally, in the case of a function subprogram, the return type
   of the function must not be of an access type;"

   Change part of the note at the end of section 3.5.1 which reads:

   "Such subprograms may have parameters and (in the case of
   functions) return types that are or contain access and file types."

   to:

   "Such subprograms may have parameters that are or contain access
   or file types and (in the case of functions) return types that are
   or contain access types."

2) An alias of a physical type is not possible, although described in the LRM.
   Indeed, a physical type is always an anonymous type. Only physical
   subtypes can be aliased.

   Proposition: Are non-object aliases really used ? Non-object aliases were
   added to be able to re-export declarations, but they cannot be used for
   this purpose.

VASG-ISAC Analysis & Rationale:

   This issue has already been identified in IR 2038 "Minor semantic errors".

VASG-ISAC Recommendation for IEEE Std 1076-2002

   Superseded by IR 2038.

VASG-ISAC Recommendation for Future Revisions

   Superseded by IR 2038.

3) Character literal can be decorated through an attribute specification,
   but the 'decoration' cannot be referenced (because the prefix of an
   attribute cannot be a character).

VASG-ISAC Analysis & Rationale:

   It is true that attributed literals cannot be referenced from
   within VHDL, but these attributes can be used by other tools, which
   is one of the reasons for using attributes.

VASG-ISAC Recommendation for IEEE Std 1076-2002

   No change.

VASG-ISAC Recommendation for Future Revisions

   If there is sufficient benefit, consider allowing attributes on
   literals to be referenced. However, note that this might make
   language parsing much more difficult.

4) It is possible to write pure functions that do not return the same value:
   type string_acc is access string;

   pure function alloc (str : string) return string_acc is
   begin
      return new string'(str);
   end alloc;

   Proposition: forbid allocators in pure functions (directly or indirectly)
   as well as calls to the implicit deallocate procedures.

VASG-ISAC Analysis & Rationale:

   There is an issue here, and the submitter's proposal makes sense.
   The question was raised whether the restrictions should be added to
   impure functions. It was noted that pure functions cannot reference
   a file object or a shared variable.(see section 2.2).

VASG-ISAC Recommendation for IEEE Std 1076-2002

   Interpret the LRM as forbidding allocators in pure functions.

VASG-ISAC Recommendation for Future Revisions

   Forbid allocators (directly or indirectly) in pure functions.
   Alternately, forbid references to access types in pure functions.

5) Some trivial expressions are not valid:
      constant c : integer := -3;
   The expression is ambiguous, since the "-" can either that of the integer
   type or that of the universal integer type.
   For sure, in this example the result is the same, but what about:
     function "-" (v : integer) return integer is begin return 0; end;
     constant c : integer := -3;

   Proposition: Do like Ada: preference for universal operators.

VASG-ISAC Analysis & Rationale:

   The submitter is mistaken. The expression

      constant c : integer := -3;

   is not ambiguous. Section 7.3.5 states:

   "An implicit conversion of an operand of type universal-integer to
   another integer type, or of an operand of type universal_real to
   another floating point type, can only be applied if the operand is
   either a numeric literal or an attribute, or if the operand is an
   expression consisting of the division of a value of a physical type
   by a value of the same type."

   So the only valid interpretation of -3 is that 3 is converted to
   type INTEGER and the - operator is that of type INTEGER.

   There are some very subtle ambiguity problems with universal types,
   but they are very esoteric and don't occur in real designs. See IR
   0088 "Overloaded convertible operands make type analysis very
   difficult".

VASG-ISAC Recommendation for IEEE Std 1076-2002

   No change.

VASG-ISAC Recommendation for Future Revisions

   No change.

6) Does a generate statement have a declarative part ?
   No, according to grammar from 9.7, but some of the block_declarative_item
   are specifications which are valid only inside declarative part...

   Proposition: Replace "{ block_declarative_item }" with
   "block_declarative_part".

VASG-ISAC Analysis & Rationale:

   The submitter is correct and his proposal is accepted.

VASG-ISAC Recommendation for IEEE Std 1076-2002

   View the LRM as if it read as the proposer suggests.

VASG-ISAC Recommendation for Future Revisions

   Rewrite the LRM as proposed.

7) What is the meaning of:
   type t is array (boolean) of bit;
   signal s : t;
   ...
   wait on s (time < 10 ns);

   Suppose the wait statement starts to execute at 9 ns, and there is an
   event at 11 ns on s (true). Does the wait statement finish ?
   This bug is due to the fact that globally static expression are not static.

   Proposition: why the time function is pure ?

VASG-ISAC Analysis & Rationale:

   It appears that the submitter means "NOW" where he uses "time". If
   so, then this issue has been addressed in IR 2032: Function "NOW"
   is not pure

VASG-ISAC Recommendation for IEEE Std 1076-2002

   Superseded by IR 2032.

VASG-ISAC Recommendation for Future Revisions
   Superseded by IR 2032.

8) What is the meaning of 'signature' in 'INSTANCE_NAME and 'PATH_NAME ?
   What is the signature of function f return natural ? [return natural] or
   [return integer]. At least, the use of these attributes is nonportable.

VASG-ISAC Analysis & Rationale:

   There is a genuine issue here. Probably, the best solution is to
   generate the profile using the same type marks as the corresponding
   subprogram declaration. It was also noted that the LRM does not
   give any meaning to a signature in an instance or path name
   (although there is an obvious intent.)

VASG-ISAC Recommendation for IEEE Std 1076-2002

   Clean this up.

VASG-ISAC Recommendation for Future Revisions

   Clean this up.

9) The default entity aspect is ambiguous, because rules a) and c) or b) and c)
   of 5.2.2 can results in two visible entity declaration.
   Proposition: Remove rules a) and b), that are neither intuitive
   nor understandable.

VASG-ISAC Analysis & Rationale:

   Rules a), b) and c) in section 5.2.2 are supposed to be applied in
   order, although the LRM isn't clear about this. The submitter's
   proposal to drop rules a) and b) would not be backward compatible.

VASG-ISAC Recommendation for IEEE Std 1076-2002

Treat rules a), b) and c) of section 5.2.2 as if there were an implied
ordering.

VASG-ISAC Recommendation for Future Revisions

Rewrite section 5.2.2 to reflect the intended ordering.

10) Constant parameter of access types are implicitly allowed:
      type line is access string;
    seems to implicitly define:
      function "=" (constant <anon> : line; constant <anon> : line)
        return boolean;
    These functions (if they really exist) are of course not overloadable.
    The restriction (constant parameter cannot be of access type) was not
    well considered (remember the endline function of std.textio).
    Although this is not explained, I suppose the reason why this restriction
    exists is because it prevents from defining pure function that returns
    different values when called with the same parameters.

    Proposition:
     1) allow constant parameter of access types for procedures and impure
        functions.
     2) Allow constant parameter of access types for pure functions but forbid
        to dereference such parameters in pure functions.

VASG-ISAC Analysis & Rationale:

    There is a genuine issue here, and the proposed solutions are
    reasonable. Here are some ideas for consideration. LRM 3.3: "An
    object declared to be of an access type must be an object of class
    variable. An object designated by an access value is always an
    object of class variable." So it seems to be illegal to pass an
    access type as a function parameter (The declaration of the formal
    as a constant of an access type should fail). Ada 95 has an extended
    notation which is as follows (simplified for VHDL semantics):

    access_type_definition ::= ACCESS [general_access_modifier] subtype_indication

    general_access_modifier ::= ALL | CONSTANT

    Declarations with ALL or no general_access_modifier then the
    access is an access to variable and can be updated. Ir the
    general_access_modifier is CONSTANT the a designated object cannot
    be updated through a value of such a type.

VASG-ISAC Recommendation for IEEE Std 1076-2002

   To be determined.

VASG-ISAC Recommendation for Future Revisions

   To be determined.

Extra bugs:
11a) There is a missing ';' in example of E'PATH_NAME after the generic clause
    of component BComp declared inside architecture top of top.

VASG-ISAC Analysis & Rationale:

   Yes, the ';' is missing.

VASG-ISAC Recommendation for IEEE Std 1076-2002

   Interpret the example as if the ';' were present.

VASG-ISAC Recommendation for Future Revisions

   Add the missing ';' to the example.

11b) There is a missing ':' before gbottom'path_name.

VASG-ISAC Analysis & Rationale:

   Yes, the ':' is missing.

VASG-ISAC Recommendation for IEEE Std 1076-2002

   Interpret the example as if the ':' were present.

VASG-ISAC Recommendation for Future Revisions

   Interpret the example as if the ':' were present.

12) Names of protected type examples in 3.5.1 and 3.5.2 do not match:
  VariableSizedBitArray vs VariableSizeBitArray.
 
VASG-ISAC Analysis & Rationale:

   This is item 18. of IR 2039 "Minor typos"

VASG-ISAC Recommendation for IEEE Std 1076-2002

   Superseded by IR 2039.

VASG-ISAC Recommendation for Future Revisions

   Superseded by IR 2039.
   

Proposed Resolution
-------------------

   As above
 
VASG-ISAC Analysis & Rationale
------------------------------

   As above

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

   As above

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

   As above

-------------END OF IR----------------

Active IRs:

No Status Responsible Description Notes
Summary
2004 Analyzed Chuck Definition of SLA doesn't make sense
2013 Analyzed Chuck Exact subtype "matching" for port associations
2015 Analyzed Peter Generics should be able to incorporate other generics
2018 Analyzed Peter Variable IN parameter should be no different than constant
2019 Analyzed Peter Reading outputs from within architecture
2020 Analyzed Peter keyword REPORT is over-used
2021 Analyzed Peter Dynamic hardware construct
2022 Submitted Elements of constant composite to be locally static
2023 Analyzed Peter Add predefined array types for integer, boolean, real and time
2024 Analyzed Peter VHDL needs encryption support
2025 Analyzed Peter "Generate" for sequential code
2026 Analyzed Peter Upward propagating parameters
2028 Analyzed Peter Clarify simulation cycle.
2038 Submitted Minor semantic errors
2040 Analyzed Ajay Problems with OTHERS in aggregates
2041 Analyzed Chuck Association of members is too restricted
2042 Analyzed Peter Architecture as a block causes problems
2043 Submitted Deepak? Numeric VALUE attribute parameter can't have sign
2044 Analyzed Chuck Deprecation of linkage ports affects boundary scan description language
2048 Submitted Miscellaneous errors

Recent Inactive IRs
1044 ISAC-Approved Definition of 'HIGH and 'LOW in a null range
2000 ISAC-Approved Where may/must deferred constant declaration appear
2001 ISAC-Approved Resize not working in numeric_std.vhd (1076.3
2002 ISAC-Approved Resize(R.2) function in numeric_std.vhd does improper array length check
2003 Forwarded Specification of multi-cycle paths
2005 Duplicate sla operator behavior does not match typical hardware behavior
2006 Forwarded "else" in "if generate"?
2007 Forwarded VHDL needs to be enhanced to allow the modeling of switches.
2008 ISAC-Approved Source value of undriven, non-sourced INOUT, OUT or BUFFER port
2009 Forwarded New std package, containing compiler and target identification information
2010 ISAC-Approved The description of type/subtype relationship could be better
2011 Forwarded A package body should be able to consist of several files
2012 Forwarded VHDL lacks inherent statements to describe the most basic hardware design equations
2014 Forwarded Allowance of the keyword "all" in place of a sensitivity list is desirable
2016 Duplicate Allowance of the keyword "all" in place of a sensitivity list is desirable
2017 Duplicate Generics should be able to incorporate other generics
2027 Forwarded When loop index is static, drivers are created for each element of array
2029 ISAC-Approved Non-relevant words and paragraph.
2030 ISAC-Approved What signature does a method have
2031 ISAC-Approved "mod" function needed for TIME
2032 ISAC-Approved Function "now" is not pure
2033 Forwarded Incremental operator and auto subtype boundary wrap
2034 Forwarded Introduce history attribute on signals to auto infer registers
2035 Forwarded new function "stages" automates pipelining
2036 ISAC-Approved protected_type_declarative_item includes subprogram_specification
2037 ISAC-Approved Typo wrt now in the index
2039 ISAC-Approved Minor typos
2045 ISAC-Approved Add the ability to comment an entire block of code
2046 Forwarded Type independent ports and subprogram parameters
2047 ISAC-Approved Backslash in extended identifiers
Received on Tue Dec 14 10:35:57 2004

This archive was generated by hypermail 2.1.8 : Tue Dec 14 2004 - 10:35:57 PST