These are all in the website. Peter, did you analyze any additional IRs with numbers 1xxx? Also, Peter, could you analyze IR2012. I believe that its straightforward (Model Tech is wrong!) but I would like to have "vendor spats" resolved by "disinterested" parties. Also, there are several issues with respect to IR2099 which need to be resolved. Finally, our next meeting is April 12, not the usual April 5. Chuck Swart -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. VHDL Issue Number: 1070 Language Version: VHDL-2002 Classification: Language Definition Problem Summary: VPI Issue 14 -- Prefixes in USE clauses Related Issues: 0190 Relevant LRM Sections: TBD Key Words and Phrases: TBD ----------------------- Author of Submission: J. R. Armstrong (edited by Bill Paulsen) Author's Affiliation: Virginia Polytechnic Institute and State University Author's Post Address: Bradley Department of Electrical Engineering Virginia Polytechnic Institute and State University Blacksburg, VA 24061 Author's Phone Number: (703) 231-4723 Author's Fax Number: N/A Author's Net Address: JRA@VTVM1.CC.VT.EDU Current Status: Analyzed Superseded By: N/A ------------------------ Date Submitted: 1991/03/15 Date Analyzed: 6 March 2007 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 6 March 2007 Description of Problem ---------------------- (This IR supersedes IR 0190.) Can the same prefix be used in multiple selected_names in a USE clause? For example, is "use work.definework.all, work.definework;" allowed? Test File: CH10/S04/01010104.vhd Comments: (from MCC) The line "use work.definework.all,work.definework;" is in error since the first part of the clause "use work.definework.all" causes the name WORK to become not directly visible. Thus, the sec- ond part of this clause "use work.definework" is invalid since the name WORK is now not directly visible. MCC sug- gests changing the line to read "use work.definework, definework.all;" -- ##A4001114281FFA400121A400231********************************************** --+ File: [SUITE.CH10.S04]01010104.VHD -- --+ Copyright (c) 1987, 1988 by CAD Language Systems, Inc. All rights reserve -- --+ LRM_version: IEEE Std. 1076-1987 -- --+ Subsets: -- --+ Description: -- --+ Test_point - (100400_010101) "A use clause achieves direct visibility of -- declarations that are visible by selection." -- --+ Test_objective -(4) Test that when a declaration existing outside the scope -- of the immediate design region is needed, that a use clause can make that -- declaration visible. In addition, the library section of the LRM (section -- 11.2) states that the use clauses: -- library STD, WORK; use STD.STANDARD.all -- should be implicit. This test should succeed. -- --+ References: Secondary LRM Coverage: (100400_010201) -- (100400_020301) -- --+ Instructions: None -- --+ Keywords: use clause, declaration, library, visibility -- --+ Test_Results: Expect_success. Output_Checked. -- --+ Test_Type: Locally Static Semantic -- --+ History: Created MAT/CLSI 08-30-88 -- Corrected KSC/VT 12-22-89 -- Corrected CHC/VT 5-4-90 -- --+ Comments: CLSI-FILE: [000000.SCOPE.USECLAUSE]08 -- MCC claimed that the order of selected names in the -- use clause is significant. -- This will be sent to VASG for clarification. -- -- *************************************************************************** package definework is type work is array(0 to 31) of BIT; end definework; use work.definework.all,work.definework; entity E is port (P : in bit); end E; architecture D3 of E is use work.definework; begin process (P) -- This succeeds because type work is defined in package definework, -- there is no conflict with library "work" variable doit : definework.work ; -- No_failure_here begin end process; end D3; Proposed Resolution ------------------- TBD VASG-ISAC Analysis & Rationale ------------------------------ In the submitter's example, the use clause makes the name WORK potentially visible. The submitter asks whether that name hides the library name WORK mentioned in the prefix of the second selected name in the use clause. Subclause 10.4 defines the scope of a use clause, and specifies that it starts immediately after the use clause. Potentially visible declarations are only considered in the scope of the use clause. Thus, in the submitter's example, the declaration WORK.DEFINEWORK.WORK is not potentially visible at the place of the second selected name in the use clause, since that place is not after the use clause. The comment from MCC is incorrect. Note, in passing, that the name in the use clause in architecture D3 is incorrect. Since the use clause in the context clause of the entity makes the name WORK.DEFINEWORK.WORK directly visible in the entity and the architecture, the prefix of the selected name in the use clause in D3 refers to the array declared in the package. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No change. VHDL Issue Number: 2010 Language_Version: VHDL-2002 Classification: LRM Terminology, Grammar and Typographical Errors Summary: The description of type/subtype relationship could be better Relevant_LRM_Sections: Chapter 3 of 1076-1993, sections 3.1, 3.2, and 3.3 Related_Issues: Key_Words_and_Phrases: types subtypes Authors_Name: Dale Martin Authors_Phone_Number: (513) 771-3751 Authors_Fax_Number: (513) 563-4693 Authors_Email_Address: dmartin@clifton-labs.com Authors_Affiliation: Clifton Labs, Inc. Authors_Address1: 10265 Spartan Dr, Suite N Authors_Address2: Cincinnati, OH 45215 Authors_Address3: Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 7 December 2000 Date Analyzed: 29-Oct-04 Author of Analysis: Peter Ashenden Revision Number: 2 Date Last Revised: 05 May 2005 Description of Problem ---------------------- In 3.1.1, the first sentence is "An enumeration type definition defines an enumeration type." It says nothing about a subtype being defined as well. Conversely, lines 119 and 157, pg 36 and pg 37, respectively, say for physical and integer types that a type and a subtype are created. For unconstrained array types, there is a similar lack of explicitness about the subtype creation. Proposed Resolution ------------------- Peter Ashenden made this comment about it: The same issue arose in the definition of Ada. They solved it by saying explicitly that a type definition defines an anonymous base type and a *first subtype* of the base type. Thus base types never have an explicit name in Ada, only subtypes do. Thus, the Ada standard always talks about subtype names, and where it's important, qualifies the discussion by referring to a first subtype name. VASG-ISAC Analysis & Rationale ------------------------------ An enumeration type explicitly defines the set of values for the type. An implementation must be able to represent all values of the type. Compare this with an integer, physical and floating point type, for which an implementation may choose a range for representation, provided it includes the range specified in the type definition. This is reflected in the language by having an integer, physical or floating point type definition define an anonymous type whose range is implementation defined, and a named subtype constrained by the range in the type definition. Clause 3, page 33, states: A type is a subtype of itself; such a subtype is said to be unconstrained (it corresponds to a condition that imposes no restriction). Thus, for an enumeration type definition, the defined enumeration type also serves as a subtype. No distinction need be made between the type as a type and the type as a subtype. In relation to unconstrained array types, 3.2.1, page 41, states: An unconstrained array definition defines an array type and a name denoting that type. Thus, for an unconstrained array type definition, the defined array type also serves as a subtype. While it might be possible to review and redefine the specification of types and subtypes using the notion of first subtypes from Ada, to do so would be a major undertaking. It would subsequently entail verification by tool implementers that their tools conform to the revised rules. The benefit of such an exercise would be small for the LRM maintainers and tool implementers, and negligible for users. Thus, it is not warranted. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No change. -------------END OF IR---------------- VHDL Issue Number: 2011 Language_Version: VHDL-2002 Classification: Language Modeling Enhancement or Deficiency Summary: A package body should be able to consist of several files Relevant_LRM_Sections: 2.6 Package bodies Related_Issues: Key_Words_and_Phrases: package, body, design unit Authors_Name: Volker Hetzer Authors_Phone_Number: +49 (821) 804 4741 Authors_Fax_Number: +49 (821) 804 2910 Authors_Email_Address: volker.hetzer@fujitsu-siemens.com Authors_Affiliation: ECAD Support/SW development Authors_Address1: Buergermeister Ulrich Str. 100 Authors_Address2: 86199 Augsburg Authors_Address3: Federal Republic of Germany Current Status: Forwarded Superseded By: ------------------------ Date Submitted: 26 February 2001 Date Analyzed: 29-Oct-04 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 29-Oct-04 Description of Problem ---------------------- The problem we've got is that we have large hierarchical designs, consisting of several (more than 100) large modules instantiating each other. Now, when we try to use more than one design as building block for a project it can happen that two different versions of a sub component go into the same project. The obvious solution is to have one package per design (when used as building block for another design) with just the top entity comprising the package entity. However, as our designs get large, they have to be reread in full whenever one component in the package changes, leading to overly long turnaround times. Proposed Resolution ------------------- I would like to suggest that everything that can go into a package body does not need to be in one file. As an example, consider a entity/architecture pair and a hypothetical new keyword "go_into_package": use IEEE.std_logic_1164.all; go_into_package MyDesign; entity subcomponent ...end subcomponent; architecture x of subcomponent is ... end x; VASG-ISAC Analysis & Rationale ------------------------------ The submitter appears to be confusing a number of VHDL terms, specifically, "entity", "component", "package" and "library". This makes it hard to determine the real problem experienced by the submitter and to understand his proposed resolution. Notwithstanding that, it appears that the submitter is requesting a new language feature to improve productivity. That lies within the scope of the VHDL-200x Modeling and Productivity group. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Forward the submitter's request to the VHDL-200x Modeling and Productivity group, with a suggestion that they contact the submitter to seek clarification of his problem and proposed resolution. -------------END OF IR---------------- VHDL Issue Number: 2012 Language_Version: VHDL-2002 Classification: Language Definition Problem Summary: VHDL lacks inherent statements to describe the most basic hardware design equations Relevant_LRM_Sections: Related_Issues: Key_Words_and_Phrases: Authors_Name: Weng Tianxiang Authors_Phone_Number: 818-998-0070 Authors_Fax_Number: 818-998-4459 Authors_Email_Address: wtx@umem.com Authors_Affiliation: Micro Memory Inc Authors_Address1: 9540 Vassar, Chatsworth CA 91311 Authors_Address2: Authors_Address3: Current Status: Forwarded Superseded By: ------------------------ Date Submitted: 6 April 2001 Date Analyzed: 29-Oct-04 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 03-December-2004 Description of Problem ---------------------- The most basic equation in hardware design: OutBus <= a * ABus + b * BBus + c * CBus + d * DBus + e * EBus; One statement structure in serial mode: if(a = '1') then OutBus <= ABus; elsif( b = '1') then OutBus <= BBus; elsif(c = '1') then OutBus <= CBus; elsif(d = '1') then OutBus <= DBus; elsif(e = '1') then OutBus <= EBus; end if; or in another equal form: if(a = '1') then OutBus <= ABus; end if; if(b = '1') then OutBus <= BBus; end if; if(c = '1') then OutBus <= CBus; end if; if(d = '1') then OutBus <= DBus; end if; if(e = '1') then OutBus <= EBus; end if; In concurrent mode: OutBus <= ABus when a = '1' else BBus when b = '1' else CBus when c = '1' else DBus when d = '1' else EBus; In those above 3 situations, a superfluous condition is posed on the equation, it means a priority tree is implied in all three situations. Actually most of time when dealing with main data flow, all above conditions are mutually exclusive, no need to pose the extra conditions on the final equation. The following is a resulting equation generated from a commercial software: OutBus <= (!d & !e & (CBus # !c)) & (c # b & BBus # !b & ABus) # (d & e & DBus) # e & EBus; When those conditions contained in the above equation are multi-items, the logic become much more complex and finally in my design for PCI core it become critical paths. In another words, due to using VHDL, users have to linguish the impest pattern to write the most basic equation. Finally I wrote a function like BoolAndVector(x: bool, y: std_logic_vector) return std_logic_vector; to do a * ABus; But finally it cannot resolve my problem either. The following real example from my design shows real difficulty I have seen facing and many VHDL users facing: SetLowAD_O1 : process(nRESET, CLK66M) begin if(nRESET = '0') then AD_O1(31 downto 0)<= (others=>'0'); elsif(CLK66M'event and CLK66M = '1') then if(TConfigReadEnable) then case ConfigPtr(7 downto 2) is when CONFIG_VENDOR_ID => -- 0x00 AD_O1(15 downto 0) <= VENDOR_ID; AD_O1(31 downto 16) <= DEVICE_ID; when CONFIG_COMMAND => -- 0x04 AD_O1(15 downto 0) <= ConfigCommand; AD_O1(31 downto 16) <= ConfigStatus; .... end case; elsif(TDMAPtrReadEnable) then AD_O1(2 downto 0) <= B"000"; case TDMAPtr(6 downto 3) is when DMA_BATTERY_MAGIC =>-- 0x00 AD_O1(7 downto 0) <= CSRMAGIC_NUMBER; AD_O1(31 downto 8) <= (others=>'0'); when DMA_EDC_LED => -- 0x08 AD_O1(7 downto 0) <= CSRLEDControl; AD_O1(31 downto 8) <= (others=>'0'); ... end case; end if; ... In the above example, all conditions are known to be mutually exclusive, and VHDL lacks a statement structure to handle the situation in a very simple way: either use the simplest way to express your idea as above, but get a very complex logic equations that would surprise its author, or you write it in very complex form to achieve the simplest equation you have in mind. Proposed Resolution ------------------- My suggestion to this problem is to introduce two new statement structures as follows: 1. for serial sector: IF conditionA THEN Statements; ELSOR conditionB THEN Statements; ELSOR conditionC THEN Statements; ELSE Statements; END IF; The resulting equation will be: OutBus <= ConditionA * AValue + ConditionB * BValue + ConditionC*CValue + not(ConditionA+ConditionB+...)*LastValue; The similar statement structure is for concurrent sector: OutBus <= ABus WHEN a ELSOR BBus WHEN b ELSOR CBus WHEN c ELSE DBus; The resulting equation will be OutBus <= a * ABus + b * BBus + c * CBus + not(a+b+c)* DBus; VASG-ISAC Analysis & Rationale ------------------------------ The submitter's requirement to be able to use scalar values to gate vector values is largely met by the VHDL-200x Fast Track proposal FT-3. In that proposal, logical operators will be provided with one operand being a scalar bit, boolean or standard-logic value and the other being a vector of the corresponding element type. Thus, the submitter's equation OutBus <= a * ABus + b * BBus + c * CBus + d * DBus + e * EBus; will be representable directly as the statement OutBus <= a and ABus or b and BBus or c and CBus or d and DBus or e and EBus; Beyond that, the submitter identifies a more general requirement to select among a number of sequential-statement lists based on general Boolean conditions that are known (or assumed or asserted) to be mutually exclusive. The VHDL-200x Modeling and Productivity group has a placeholder for a proposal to address this issue. As of the date of this analysis, no work has been done in that group on preparing a proposal. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Forward the submitter's request to the VHDL-200x Modeling and Productivity group for consideration. -------------END OF IR---------------- Revised 30 March 2007 Number Status Responsible Description Notes Active IRs 1070 Analyzed Peter VPI Issue 14 -- Prefixes in USE clauses 2099 Analyzed Chuck Alias declarations introduce homographs 2110 Submitted Implicit subtype conversions not defined 2111 Submitted Unknown term used: selector 2112 Submitted Can attributes be applied to a signal on the entity within the architecture for that entity? Resolved IRs 1044 VASG-Approved Definition of 'HIGH and 'LOW in a null range 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 ISAC-Approved Error is ambiguous 2097 ISAC-Approved Operations with Array aggregates 2098 ISAC-Approved Ambiguity in definition of T'VAL for Physical types 2100 Forwarded Operator overloading for protected type methods 2101 ISAC-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 ISAC-Approved Using a configuration to leave a design unbound 2105 ISAC-Approved Can't declare an alias of a character literal without using expanded name 2106 Forwarded Desire preprocessor (macro/ifdef) support in VHDL 2107 ISAC-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 unnecessarilyReceived on Fri Mar 30 17:43:29 2007
This archive was generated by hypermail 2.1.8 : Fri Mar 30 2007 - 17:43:31 PDT