=============================================================================== 1076.1 Ballot Resolution Commitee Comment Resolution Report ------------------------------------------------------------------------------- CRR Number: 13 Topic Addressed: Subprograms Related CRs: 20 (Mark Zwolinski, Univ. Southampton, affirmative) 66 (Garland J. Bayley, Analogy, negative) 110 (Alain Vachoux, EPFL, affirmative) Relevant LRM Sections: 2.1, 4.3.2, 7.3.3, 8.6, 9.3 Resolution Status: In review by balloters =============================================================================== Comment Reports Summary ~~~~~~~~~~~~~~~~~~~~~~~ ---------------------------------------------------------------------- CR020 According to 4.3, "there are six classes of objects: constants, signals, variables, quantities, terminals and files". Quantity and terminal parameters have not been defined (2.1.1.2). It is unclear from the LRM whether such parameters are possible, or whether they have been deliberately excluded. I am happy that, for various reasons such parameters have been excluded, but I think this should be explicitly stated. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ 2.1.1.2 Quantity and terminal parameters should be defined to be illegal (or add a new section 2.1.1.4 that states this). 4.3.3 Lines 738-739 (of 4.3.3.1) comment on how the rules for aliases apply to terminals. Quantities and terminals are not mentioned in lines 699-700. By implication, quantity and terminal aliases are not legal. I can see no reason why that need be so, thus they should be listed at the top of 4.3.3.+ ---------------------------------------------------------------------- CR066 ----- Interface quantities in line 947 are not specified to appear as anything but a port. They are not specified to be parameters as are interface signals. This is reinforced by the absence of quantities in line 1008 and 1009 about parameter interface lists. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Signals are allowed as interface parameters with special handling determined by their mode. It would seem that interface parameters could be allowed with special handling determined by their mode in the style of assignments and references to quantities are handled in procedurals. ---------------------------------------------------------------------- CR110 ----- It seems that parameters of class quantity are not allowed in a function specification. A consequence is that it is not possible to write expressions in a simple simultaneous statement that involve user-defined functions with quantity parameters. Another, more serious consequence is that the definition of the equivalent form of a simultaneous procedural statement uses a function that has quantity parameters. Proposed Resolution ~~~~~~~~~~~~~~~~~~~ Add definitions in section 2.1.1 to allow quantity parameters to functions only. =============================================================================== Analysis and Action Taken ~~~~~~~~~~~~~~~~~~~~~~~~~ We have summarized the reasons why there are no formals of class quantity or terminal in subprogram declarations. The summary is included below. ====================================================================== Subprograms in VHDL 1076.1 ====================================================================== Several balloters observed and documented in the comments attached to their IEEE ballots that section 2 of the draft LRM does not mention quantities and terminals in the context of subprograms. Some concluded, based on the fact that signals are mentioned in this section, that there was either an oversight in the documentation or a deficiency in the language. This note aims at explaining this issue, which is neither an oversight nor a deficiency. The relevant portions of section 2 of the LRM specify the declaration and definition of subprograms. The subprogram specification, which is part of both a subprogram declaration and a subprogram definition, includes a formal parameter list that specifies name, class and type of each formal parameter of the subprogram. The class of the formal parameters can be constant, variable, signal, or file. When a subprogram gets called (a function call, section 7.3.3, or a procedure call, sections 8.6 and 9.3) each formal parameter is associated with an actual parameter. Unless the formal is a constant, the class of the actual must match the class of the formal (2.1.1). For a formal that is a constant the actual must be an expression. These rules support the following associations involving quantities: formal actual constant any expression, including expressions in which quantity names appear, anywhere in a block variable the name of a quantity in a simultaneous procedural statement only (because there the name of the quantity denotes a variable in the equivalent function) Why is there a formal of class signal but none of class quantity? ----------------------------------------------------------------- There are two main reasons for formals of class signal. The first is that a signal assignment statement may appear in a procedure body (but not in a function body); such a procedure can only be called (either directly or in a nested call) from a process. The driver of the signal is created when the process is elaborated. A pointer to the driver is passed to the subprogram at the time of call. A signal assignment statement inside a procedure modifies the driver indirectly. A parallel can be drawn between a signal assignment statement and a simultaneous statement: its characteristic expression is analogous to a driver in one important respect. A signal assignment in a process creates a driver for each subelement of the signal, and a simultaneous statement creates a characteristic expression for each subelement of its expressions. The number of drivers and the number of characteristic expressions both must be static. To make sense of a simultaneous statement inside a subprogram, we would need to define semantics that leave the number of characteristic expressions invariant in an arbitrary sequence of calls to the subprogram. It is not obvious how to do that nor why it is interesting to try. The function call in an expression of the simultaneous statement (with quantities and other objects as actuals) provides all the necessary power. The second reason for formals of class signal is to access some of their attributes in the subprogram body. However, the definitions restrict such access to attributes that do not denote objects (2.1.1.2); all such attributes are functions. The reason for this restriction is the requirement that the number of objects be static. The same restriction must therefore apply to formals of class quantity, were they allowed. However, the only attribute of a quantity that does not denote an object is Q'Tolerance. We could not find any reason for a subprogram to need access to Q'Tolerance, given that simultaneous statements are not allowed in subprogram bodies. Why are there no formals or actuals of class terminal? ------------------------------------------------------ This question has a simple answer: terminals have no value, and only value-bearing objects can be passed to subprograms. For a model with conservation semantics the model writer must therefore call a subprogram with either a branch quantity or one of the quantities T'Reference of T'Contribution as actuals. Summary ------- As this investigation shows, the LDC has found no need for extending the language definition to allow formals of subprograms to be of class quantity (or terminal). Therefore, the portions of section 2 related to subprogram declarations and definitions remain almost untouched. =============================================================================== Revised Definitions ~~~~~~~~~~~~~~~~~~~ None. ===============================================================================