IR 2124 has been approved with no changes, following Ajay's email. IR2126 has three small changes: 1)The last paragraph of the analysis now correctly refers to clause 7.2.4 instead of clause 7.2.3. 2) the first paragraph under "VASG-ISAC Recommendation for Future Revisions notes that there may be additional changes for VHDL-200X. 3) The new list of complete contexts in Clause 10.5 changed "the expression in a generate specification (D4.0)" to "The expression in a generate statement label used in an external name (D4.0)" which is accurate with respect to D4.0, but might need a slight rewording for the final IEEE version. With approval of these IRs, the only thing on the ISAC plate for VHDL-200X is to finish IR 2123, which we expect to do within a few days. Chuck Swart -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. VHDL Issue Number: 2126 Language_Version VHDL-2002 Classification Language Definition Problem Summary Concatenation ambiguity Relevant_LRM_Sections Clause 7.2.4 Adding Operators (specifically concatenation) Clause 7.3.5 Type Conversions Related_Issues Key_Words_and_Phrases concatenation, type conversion Authors_Name Tim McBrayer Authors_Phone_Number 508-647-4229 Authors_Fax_Number Authors_Email_Address tim_mcbrayer@ieee.org Authors_Affiliation The MathWorks Authors_Address1 3 Apple Hill Dr. Authors_Address2 Natick, MA 01760 Authors_Address3 Current Status: ISAC-Approved Superseded By: ------------------------ Date Submitted: 11 December 2007 Date Analyzed: 07 February 2008 Author of Analysis: Chuck Swart Revision Number: $ Date Last Revised: 26 March 2008 Description of Problem ---------------------- I have encountered an issue where commercially available VHDL simulators differ as to the correctness of a certain concatenation, when the concat is contained inside a type conversion statement. Two commercial parsers reject this concatenation as ambiguous; six other commercial and research parsers consider this construct valid. My study of the LRM leads me to believe that it is valid. The vendor for one of the parsers that consider the construct ambiguous suggested I submit this to P1076 WG ISAC. Here is my specific example: LIBRARY ieee; USE ieee.std_logic_1164.all; USE ieee.numeric_std.all; ENTITY concatissue IS PORT ( in_0, in_1, in_2 : IN unsigned(1 DOWNTO 0); out1 : OUT std_logic_vector(5 DOWNTO 0)); END concatissue; ARCHITECTURE arch OF concatissue IS -- This type declaration causes some parsers to flag the concat as ambiguous TYPE bad_type IS ARRAY (0 to 99) of unsigned(1 to 1000); BEGIN out1 <: std_logic_vector(in_0 & in_1 & in_2); -- is this ambiguous or not? END arch; The primary question lies with the resolution of the first concat processed of the two that comprise the operand of the type conversion. Is the result of the concat of type unsigned, or is it of type bad_type? First, it is relevant to note that the expression inside a type conversion must be able to have its type unambiguously determined. This is stated in Clause 7.3.5, Type conversions, page 111, IEEE Std. 1076-2002. "The type of the operand of a type conversion must be determinable independent of the context (in particular, independent of the target type)." For the concatenation expression: any type (unsigned, in my specific case) has defined implicitly for it 4 different versions of the concat operator with different signatures, as expressed in the table in Clause 7.2.4, page 102. They can be summarized based on their argument and return types as: 1. &(T, T) return T 2. &(T, element_type of T) return T 3. &(element_type of T, T) return T 4. &(element_type of T, element_type of T) return T The ambiguity seen here by some parsers is between cases 1 and 4; 2 and 3 are not relevant in this case. In Clause 7.2.4, Adding operators, page 102, after the table there are three mutually exclusive cases listed. Case c) is the point on which I believe there is a difference of interpretation. "c) If both operands are of the same type and it is the element type of some one-dimensional array type, the type of the result must be known from the context and is this one-dimensional array type. In this case, each operand is treated as the one element of an implicit array, and the result of the concatenation is determined as in case a). The bounds and direction of the index subtypes of the implicit arrays are determined as in the case of the implicit array in case b)." My understanding of this language, piece by piece, is: "If both operands are of the same type and it is the element type of some one-dimensional array type,..." This is true in this case. The operands are of type unsigned and unsigned is the element type of bad_type, a 1-D array of unsigned. "...the type of the result must be known from the context and is this one-dimensional array type." I contend this statement is not true. The result cannot be known from the context, because the expression in a type conversion explicitly does not provide any context. The type of the conversion expression (in this case the concatenation) must be determined by itself. Since case c) for concats requires the type be known from the context, and since the context cannot provide type information in this case, case c) is not valid for determining the type of the concat expression in the example. Case b) in 7.2.4 is not relevant, as it concerns the concat of a 1-D array and the appropriate element_type. Thus b) is not valid for determining the return type of the concat expression in this example. This leaves a) as the only mutually exclusive choice left. Thus, the type of the concat expression is the same array type (unsigned) as both the left and right operands. This implies the example code is legal VHDL. This logic is clearly open to another interpretation, since two vendors' tools claim the concatenation is ambiguous between bad_type and unsigned. The LRM even addresses this specific possibility of ambiguity in note 2, 7.2.4, page 104. Proposed Resolution ------------------- I believe that the example code in this case is not ambiguous; neither do I believe that the LRM wording is ambiguous. My only suggestion at this time would be to explicitly reference this specific case in an example, if the construct is decided to be unambiguous. If the construct is determined to be ambiguous, I propose removing the phrase "mutually exclusive" from 7.2.4, as it is possible to have one concatenation expression that meets the requirements of both a) and c). If this is the case the text of note 2 should be given a more prominent position. VASG-ISAC Analysis & Rationale ------------------------------ The major area describing the issues raised by this IR is Clause 10.5, The context of overload resolution. This clause describes the following general procedure: A syntactic region of the design is identified, called an "innermost complete context". Certain rules are applied to potentially ambiguous names, operations, etc. to determine which interpretation is intended. After a unique interpretation is selected, further semantic checking may occur. However, in some cases not all of the rules of 10.5 are applied to the entire complete context. A good example of this can be found in rules for sequential case statements. The LRM states that "Each choice in a case statement alternative must be of the same type as the (case) expression." This rule could be used to resolve the type of the case expression, since Clause 10.5 states that we must consider "a) Any rule that requires a name or expression ... to have the same type as another name or expression." However, the original language designers decided against this. Instead they decided that the type of the case expression should be determined independently of the case choices. Once this type is determined then a semantic check is performed to make sure that the case alternatives are of the same type as the case expression. The ISAC believes that the intent is that the type of the case expression be determined without examining the innermost complete context outside of the case expression but by applying the rules of 10.5 to the case expression. However, the LRM wording is: "This type (of the case expression) must be determined independently of the context in which the expression occurs, but using the fact that ...". Unfortunately, the expression "independently of the context" is not completely clear. It could be interpreted as the ISAC believes was intended, but it could also be interpreted as "There is no applicable context for the case expression." the word "context" might mean the innermost complete context or it might refer to the application of all the rules of 10.5. The use of the word "context" in the title of Clause 10.5 "The context of overload resolution" is not formally defined. In fact, throughout the LRM the word "context" is used freely and somewhat loosely. Some implementations interpret "independent of context" in an informal way. Since its not completely clear just what is meant by "context" it is even less clear what is intended by phrases like "independent of context". The ISAC believes that this situation is best remedied by removing the references to context independence and by making the intent more explicit. According to the ISAC interpretation the concatenation expression in question is ambiguous. The VHDL-2002 LRM has three areas which state that certain types must be determined independent of context. These areas are: 1) Discrete ranges defined by a range in constrained array definitions, iteration schemes or generation schemes (Clause 3.2.1.1), 2) Type conversions (7.3.5), and 3) Case statements (8.8). In addition VHDL-200X version D4.0 states in Clause 6.7, External names, that the static expression used with generate statement labels in external pathnames "shall be determined independently of the context." It also states in Clause 9.7, Generate statements, that the type of the case expression "shall be determinable independently of the context in which the expression occurs..." Concerning the wording of the concatenation section, Clause 7.1, Expressions, states: "The type of an expression depends only upon the types of its operands and on the operators applied; for an overloaded operand or operator, the determination of the operand type, or the identification of the overloaded operator, depends on the context (see 10.5)" With this in mind, paragraph c) of clause 7.2.4 should remove the reference "the type of the result must be known from the context" since it is redundant and it seems to imply that different rules are used for resolving case c) than for cases a) and b). VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the LRM as if the Recommendation for Future Revisions were in place. However, it is recognized that not all implementations conform to this interpretation. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Make the following changes to VHDL-2002 (Note that there may be additional changes needed for the final version of VHDL-200X): Clause 3.2.1.1 Index constraints and discrete ranges Change the paragraph reading: "For a discrete range used in a constrained array definition ... Otherwise, both bounds must be of the same discrete type, other than universal_integer; this type must be determined independently of the context but using the fact that the type must be discrete and that both bounds must have the same type...." To: "For a discrete range used in a constrained array definition ... Otherwise, the type of the range must be determined by applying the rules of Clause 10.5 to the range, considered as a complete context, using the rules that that this type must be discrete and that both bounds must have the same type...." Clause 7.2.4 Adding operators Change the paragraph reading: "c) If both operands are of the same type and it is the element type of some one-dimensional array type, the type of the result must be known from the context and is this one-dimensional array type..." To: "c) If both operands are of the same type and it is the element type of some one-dimensional array type, the type of the result is this one-dimensional array type..." Clause 7.3.5 Type conversions Change the paragraph reading: "The target type of a type conversion is the base type of the type mark. The type of the operand of a type conversion must be determinable independent of the context (in particular, independent of the target type)..." To: "The target type of a type conversion is the base type of the type mark. The type of the operand of a type conversion must be determined by applying the rules of Clause 10.5 to the operand considered as a complete context. (In particular, the type of the operand must be determinable independent of the target type)... Clause 8.8 Case statement Change the paragraph reading: "The expression must be of a discrete type, or of a one-dimensional array type whose element base type is a character type. This type must be determinable independently of the context in which the expression occurs, but using the fact that the expression must be of a discrete type or a one-dimensional character array type...." To: "The expression must be of a discrete type, or of a one-dimensional array type whose element base type is a character type. This type must be determined by applying the rules of Clause 10.5 to the expression considered as a complete context, using the rule that the expression must be of a discrete type or a one-dimensional character array type. (In particular, the type of the case expression must be determinable independent of the type of the case statement choices.)...." Clause 10.5 The context of overload resolution Change the paragraph reading: "... a <complete context> is either a declaration, a specification, or a statement." To: "Each of the following constructs is a complete context: * A declaration * A specification * A statement * A discrete range used in a constrained array definition, a generate parameter specification or a loop parameter specification * The expression of a type conversion * The expression of a case statement or a case generate statement (D4.0) * The expression in a generate statement label used in an external name (D4.0) Make the following changes to VHDL-200X LRM version D4.0: Clause 6.7, External names Change the paragraph reading: "5) For a generate statement label,...the type of the expression shall be determined independently of the context, but using the fact that the type shall be discrete..." To: "5) For a generate statement label,...the type of the expression shall be determined by applying the rules of Clause 10.5 to the expression considered as a complete context, using the rule that the type shall be discrete..." VHDL-200X LRM version D4.0 Clause 9.7 Generate statements Change the paragraph reading: "For a case generate statement, the expression shall be globally static, and shall be of a discrete type, or of a one-dimensional array type whose element base type is a character type. This type shall be determinable independently of the context in which the expression occurs, but using the fact that the expression shall be of a discrete type or a one-dimensional character array type..." To: "For a case generate statement, the expression shall be globally static, and shall be of a discrete type, or of a one-dimensional array type whose element base type is a character type. This type shall be determined by applying the rules of Clause 10.5 to the expression considered as a complete context, using the fact that the expression shall be of a discrete type or a one-dimensional character array type..." VHDL Issue Number: 2124 Language_Version IEEE Draft VHDL-2007 (VHDL + VHPI) Classification Language Definition Problem Summary Ordering of process execution and callbacks Relevant_LRM_Sections 12.6.4.2 Related_Issues Key_Words_and_Phrases process resumption, VHPI callback Authors_Name Peter Ashenden Authors_Phone_Number +61 8 7127 0078 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Authors_Address1 Authors_Address2 Authors_Address3 Current Status: ISAC-Approved Superseded By: ------------------------ Date Submitted: 27 September 2007 Date Analyzed: 15 March 2008 Author of Analysis: Peter Ashenden Revision Number: 2 Date Last Revised: 26 March 2008 Description of Problem ---------------------- The LRM specifies an ordering of steps in the simulation cycle that may be overly restrictive. In 1076-2002, 12.6.4, process execution in the simulation cycle was specified as: d) For each process, P, if P is currently sensitive to a signal, S, and if an event has occurred on S in this simulation cycle, then P resumes. e) Each nonpostponed process that has resumed in the current simulation cycle is executed until it suspends. This allows interleaved execution of the resumed processes. In 1076c-2007, this was changed to incorporate execution of callbacks. The revised text in 12.6.4.2 is: 2) For each process, P, if P is currently sensitive to a signal, S, and if an event has occurred on S in this simulation cycle, then P resumes. 3) For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbResume callback associated with P is executed. 4) Each nonpostponed process that has resumed in the current simulation cycle is executed until it suspends, and each registered and enabled vhpiCbTimeOut and vhpiCbRepTimeOut callback whose triggering condition is met is executed. 5) For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbSuspend callback associated with P is executed. This specifies that all of the vhpiCbResume callbacks are executed, then the resumed processes and timeout callbacks are executed, then the vhpiCbSuspend callbacks are executed. The division into three steps constrains the available parallelism in a way that may not have been intended. Moreover, it may prevent certain optimizations of the way in which processes and callbacks are executed. An alternative and less constraining approach would be to allow interleaving of process and callback execution, provided, for each process that has resumed, any associated vhpiCbResume callback is executed before the process is executed and any associated vhpiCbSuspend callback is executed after the process suspends. Apart from the difference in potential parallelism between these two approaches, the difference may be exposed to the callback routines. As the LRM currently stands, the resumption callbacks are guaranteed that no processes or suspension callbacks have started execution. Similarly, the suspension callbacks are guaranteed that all resumption callbacks have completed and all processes have suspended. A VHPI program may be written in a way that depends on these assumptions. Should the ordering be relaxed, the assumptions would no longer hold. Proposed Resolution ------------------- Input is sought from the VHPI task force whether the relaxed ordering is permissible or desirable. If the VHPI task force recommends adoption of the relaxed ordering, the ISAC can revise the LRM to implement that intent. VASG-ISAC Analysis & Rationale ------------------------------ The issue presented in this report originated in the Accellera VHDL-TC LRM-SC as part of issue #150 (see https://bugzilla.mentor.com/show_bug.cgi?id=150). It was not clear whether the strict ordering implied by the current specification was intended, and so the issue was forwarded to the VHPI Task Force for advice. Their recommendation, together with some clarifying correspondence, is attached to the ISAC email at http://www.eda.org/isac/hm/0482.html. The recommendation is that the LRM be revised to allow the relaxed ordering. The relative ordering of processes and resume/suspend callbacks is specified in two places. First, in initialization (12.6.4.1 of D4.0), the relevant steps are: i) Each nonpostponed process in the model is executed until it suspends. Each registered and enabled vhpiCbSuspend callback associated with a nonpostponed process is executed. ... m) Each postponed process in the model is executed until it suspends. n) Each registered and enabled vhpiCbSuspend callback associated with a postponed process is executed. These steps can be revised as follows: i) For each nonpostponed process P in the model, the following actions occur in the indicated order: 1) The process executes until it suspends. 2) Each registered and enabled vhpiCbSuspend callback associated with P is executed. ... m) For each postponed process P in the model, the following actions occur in the indicated order: 1) The process executes until it suspends. 2) Each registered and enabled vhpiCbSuspend callback associated with P is executed. n) [old step o) renumbered] Second, in the simulation cycle (12.6.4.2 of D4.0), the relevant steps are: h) 2) For each process, P, if P is currently sensitive to a signal, S, and if an event has occurred on S in this simulation cycle, then P resumes. 3) For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbResume callback associated with P is executed. 4) Each nonpostponed process that has resumed in the current simulation cycle is executed until it suspends, and each registered and enabled vhpiCbTimeOut and vhpiCbRepTimeOut callback whose triggering condition is met is executed. 5) For each nonpostponed process P that has resumed in the current simulation cycle, each registered and enabled vhpiCbSuspend callback associated with P is executed. Substeps 3) to 5) can be revised as follows: h) 3) For each nonpostponed process P that has resumed in the current simulation cycle, the following actions occur in the indicated order: -- Each registered and enabled vhpiCbResume callback associated with P is executed. -- The process executes until it suspends. -- Each registered and enabled vhpiCbSuspend callback associated with P is executed. 4) Each registered and enabled vhpiCbTimeOut and vhpiCbRepTimeOut callback whose triggering condition is met is executed. 5) [old step 6) renumbered] Further steps in the simulation cycle (12.6.4.2 of D4.0) for postponed processes are: j) 4) For each postponed process P, if P has resumed but has not been executed since its last resumption, then each registered and enabled vhpiCbResume callback associated with P is executed. 5) Each postponed process that has resumed but has not been executed since its last resumption is executed until it suspends. 6) For each postponed process P, if P has executed in the previous step, then each registered and enabled vhpiCbSuspend callback associated with P is executed. These steps can be revised as follows: j) 4) For each postponed process P, if P has resumed but has not been executed since its last resumption, the following actions occur in the indicated order: -- Each registered and enabled vhpiCbResume callback associated with P is executed. -- The process executes until it suspends. -- Each registered and enabled vhpiCbSuspend callback associated with P is executed. 5) [old step 7) renumbered] 6) [old step 8) renumbered] VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the standard as though the Recommendation for Future Revisions were incorporated. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Revise 12.6.4.1 and 12.6.4.2 of P1076-2008/D4.0 as described in the preceding analysis. Revised 26 March 2008 Number Status Responsible Description Notes Active IRs 2123 Analyzed Peter Process resumption and callbacks Resolved IRs 1000 VASG-Approved Accumulated typographical and terminology errors. 1044 VASG-Approved Definition of 'HIGH and 'LOW in a null range 1070 VASG-Approved VPI Issue 14 -- Prefixes in USE clauses 2000 VASG-Approved Where may/must deferred constant declaration appear 2001 VASG-Approved Resize not working in numeric_std.vhd (1076.3 2002 VASG-Approved Resize(R.2) function in numeric_std.vhd does improper array length check 2003 Forwarded Specification of multi-cycle paths 2004 VASG-Approved Definition of SLA doesn't make sense 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 VASG-Approved Source value of undriven, non-sourced INOUT, OUT or BUFFER port 2009 Forwarded New std package, containing compiler and target identification information 2010 VASG-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 2013 VASG-Approved Exact subtype "matching" for port associations 2014 Forwarded Allowance of the keyword "all" in place of a sensitivity list is desirable 2015 Forwarded Generics should be able to incorporate other generics 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 2018 VASG-Approved Variable IN parameter should be no different than constant 2019 Forwarded Reading outputs from within architecture 2020 VASG-Approved Keyword REPORT is over-used 2021 Forwarded Dynamic hardware construct 2022 Forwarded Elements of constant composite to be locally static 2023 VASG-Approved Add predefined array types for integer, boolean, real and time 2024 Forwarded VHDL needs encryption support 2025 Forwarded "Generate" for sequential code 2026 Forwarded Upward propagating parameters 2027 Forwarded When loop index is static, drivers are created for each element of array 2028 VASG-Approved Clarify simulation cycle. 2029 VASG-Approved Non-relevant words and paragraph. 2030 VASG-Approved What signature does a method have 2031 VASG-Approved "mod" function needed for TIME 2032 VASG-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 VASG-Approved protected_type_declarative_item includes subprogram_specification 2037 VASG-Approved Typo wrt now in the index 2038 VASG-Approved Minor semantic errors 2039 VASG-Approved Minor typos 2040 VASG-Approved Problems with OTHERS in aggregates 2041 Forwarded Association of members is too restricted 2042 VASG-Approved Architecture as a block causes problems 2043 VASG-Approved Numeric VALUE attribute parameter can't have sign 2044 VASG-Approved Deprecation of linkage ports affects boundary scan description language 2045 VASG-Approved Add the ability to comment an entire block of code 2046 Forwarded Type independent ports and subprogram parameters 2047 VASG-Approved Backslash in extended identifiers 2048 VASG-Approved Miscellaneous errors 2049 VASG-Approved Circular definition of an event on a signal 2050 VASG-Approved Definition of S'Last_Value was apparently broken in 1993 2051 VASG-Approved Path_name and instance_name do not allow for protected types 2052 VASG-Approved Path_name and instance_name don't deal with operator symbols 2053 VASG-Approved Minor Typos in VHDL 2002 part 2 2054 Superseded Individual assoc. rules for array formal are not valid 2055 VASG-Approved Prohibition on assignment of protected types not normative 2056 VASG-Approved Can an attribute name that denotes a function be used where a name is required? 2057 VASG-Approved Access-typed parameters to predefined "=" and "/=" 2058 VASG-Approved Does USE of type name make operators and literals visible? 2059 VASG-Approved Upper/lower case character mapping is not clear 2060 Forwarded Include truth table for multi-input/multi-output logic. 2061 VASG-Approved Default actions on severity flags is different between simulators 2062 VASG-Approved Range staticness 2063 Forwarded Unconstrained array formals should not get subtype from actuals 2064 VASG-Approved Type conversion of unconstrained output in a port map 2065 Forwarded OTHERS in aggregates too restrictive 2066 Forwarded Multidimensional array in IEEE Std 1076.6-2004 2067 Forwarded Enhancement: Logical link interface abstraction 2068 VASG-Approved Entity instantiation with space before the entity name 2069 VASG-Approved Visibility of generics in block configurations 2070 VASG-Approved Support for floating point denormal numbers 2071 VASG-Approved Indexed name in case expression 2072 Forwarded Allow static operations on "ranges" 2073 VASG-Approved Index constraints and discrete range conversions from universal_integer 2074 VASG-Approved Problem with direct/select visibility in formal part 2075 VASG-Approved Arrays with numeric and enumeration index types are not closely related 2076 Forwarded A member attribute for records 2077 VASG-Approved Incorrect wording on some language constructs 2078 VASG-Approved Allow attribute declaration/specification in package body 2079 VASG-Approved Is TIME a locally static type? 2080 VASG-Approved Case expression should include parenthesized expression 2081 VASG-Approved The term ancestor is used where parent is meant 2082 VASG-Approved Elaboration of unconstrained interface objects 2083 VASG-Approved Generate index specification should be of same subtype as generate parameter 2084 VASG-Approved A record "element" is not called a "field" 2085 VASG-Approved What happens when a parameter of mode out is not assigned in a procedure? 2086 VASG-Approved Incorrect description of type mark in disconnection specification 2087 VASG-Approved Ambiguous rule for type of an alias declaration 2088 forwarded Formatted I/O 2089 Forwarded Directional records 2090 VASG-Approved Signature in alias declaration for "not" wrong 2091 VASG-Approved Translation between std_logic_vector based types and std_ulogic_vector 2092 VASG-Approved Type conversions don't allow for null arrays 2093 VASG-Approved Static type conversions and qualified expressions 2094 VASG-Approved Attribute specifications of overloaded subprograms is limited 2095 VASG-Approved What is the entity class of an enumeration literal? 2096 VASG-Approved Error is ambiguous 2097 VASG-Approved Operations with Array aggregates 2098 VASG-Approved Ambiguity in definition of T'VAL for Physical types 2099 VASG-Approved Alias declarations introduce homographs 2100 Forwarded Operator overloading for protected type methods 2101 VASG-Approved Type conversion - implicit refers to section 8.1.2 which doesn't exist 2102 Duplicate Typo in Section 3.2.1. Example 2103 Forwarded Dynamic/run-time creation and destruction of components and connectivity 2104 VASG-Approved Using a configuration to leave a design unbound 2105 VASG-Approved Can't declare an alias of a character literal without using expanded name 2106 Forwarded Desire preprocessor (macro/ifdef) support in VHDL 2107 VASG-Approved Editorial process dropped a \ from extended identifier example 2108 Forwarded Behavior of "wait" when condition is already true 2109 Forwarded Inter-process communication can hang unnecessarily 2110 Superseded Implicit subtype conversions not defined 2111 VASG-Approved Unknown term used: selector 2112 Forwarded Can attributes be applied to a signal on the entity within the architecture for that entity? 2113 Forwarded FILE Input and ROM Inference 2114 Forwarded 1076.6-2004 section 8.6.5 Slice names is too restrictive. 2115 VASG-Approved Binding specification should be binding indication 2116 VASG-Approved What is the direction of std_logic_vector & '0' 2117 Forwarded Block comment is not there in vhdl 2118 Duplicate Typo in 9.2 Note 2 2119 Forwarded Can't declare a protected type and object of that type in a single package 2120 VASG-Approved How to access objects in higher level nested protected type 2121 Forwarded Allow for vectors to have assigns and opens in the port map 2122 VASG-Approved Protected method has implied object parameter? 2124 ISAC-Approved Ordering of process execution and callbacks 2125 Forwarded Resolved for std_ulogic is broken for '-' 2126 ISAC-Approved Concatenation ambiguity 2127 ISAC-Approved Possible LRM interpretation pitfall related to the predefined STANDARD package 2128 ISAC-Approved Shared Variable declarations in generate? 2129 ISAC-Approved Bad requirements to check exprs with access type sub exprsReceived on Wed Mar 26 15:54:54 2008
This archive was generated by hypermail 2.1.8 : Wed Mar 26 2008 - 15:54:56 PDT