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