Several issues have been cleaned up a little since our last meeting. I am attaching several documents (they are also available on the website): List of Active IRs. (The following IRs have had changes, all in the Status field: 2004, 2013, 2032, 2042, 2045, 2068) New IR: 2069 Minutes from 2005-06-17 I will send proposed agenda for tomorrow's meeting in a separate email. Chuck Swart Revised 20 July 2005 No Status Responsible Description Notes Active IRs 2038 Submitted Minor semantic errors 2043 Analyzed Deepak Numeric VALUE attribute parameter can't have sign 2054 Submitted Larry Individ. assoc. rules for array formal are not valid 2062 Analyzed Ajay Range staticness 2064 Analyzed Larry Type conversion of unconstrained output in a port map 2065 Submitted Chuck OTHERS in aggregates too restrictive 2069 Submitted Visibility of generics in block configurations 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 ISAC-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 ISAC-Approved Clarify simulation cycle. 2029 ISAC-Approved Non-relevant words and paragraph. 2030 VASG-Approved What signature does a method have 2031 ISAC-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 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 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 ISAC-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 ISAC-Approved Minor Typos in VHDL 2002 part 2 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 ISAC-Approved Upper/lower case character mapping is not clear 2060 Forwarded Include truth table for multi-input/multi-output logic. 2061 ISAC-Approved Default actions on severity flags is different between simulators 2063 Forwarded Unconstrained array formals should not get subtype from actuals 2066 Forwarded Multidimensional array in IEEE Std 1076.6-2004 2067 Forwarded Enhancement: Logical link interface abstraction 2068 ISAC-Approved Entity instantiation with space before the entity name -------------BEGINNING OF IR---------------- VHDL Issue Number: 2069 Language_Version VHDL-2002 Classification Language Definition Problem Summary Visibility of generics in block configurations Relevant_LRM_Sections Sec 1.3.1, 10.2, 10.3 Related_Issues Key_Words_and_Phrases Authors_Name Nitin Khurana Authors_Phone_Number +91-120-2562842 extn 4142 Authors_Fax_Number Authors_Email_Address nkhurana@cadence.com Authors_Affiliation Cadence Design Systems Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Submitted Superseded By: ------------------------ Date Submitted: 19 July 2005 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- Please see the following VHDL descriptions. entity bug3 is generic ( Dwidth3 : integer :: 0 ); end bug3; architecture rtl_bug3 of bug3 is begin end rtl_bug3; entity bug2 is end bug2; architecture rtl_bug2 of bug2 is component virtual_bug3 generic ( Dwidth3 : integer := 0 ); end component; begin U1 : virtual_bug3; end rtl_bug2; entity bug is generic ( Dwidth : integer ); end bug; architecture rtl_bug of bug is component virtual_bug2 end component; begin U1 : virtual_bug2; end rtl_bug; configuration bug_cfg of bug is for rtl_bug for U1 : virtual_bug2 use entity work.bug2(rtl_bug2); for rtl_bug2 for U1: virtual_bug3 use entity work.bug3(rtl_bug3) generic map( DWidth3 => DWidth -- Problem ); end for; end for; end for; end for; end bug_cfg; The line in the configuration with the comment "--problem" maps a generic of component bug3 to a generic of entity bug. This mapping skips the intermediate entity bug2. Is this legal VHDL? Different tools appear to interpret this differently. According to my interpretation of section 1.3.1 of the LRM, the generics of entity bug are not visible at this point, and hence it is illegal. However, others quote section 10.2 and 10.3 to claim that it is legal. Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR---------------- Minutes of ISAC meeting help via telecom on 17 June 2005 Present: Peter Ashenden, Jim Lewis, Chuck Swart, Larry Soule Absent: Deepak Pant, Ajay Verikat Next Meeting: Thursday July 7 2005, 8 pm Pacific Daylight Time (Friday July 8 2005, 3 am GMT) TOPIC: Review ballots on difficult issue reports. See included document. Note: The proposed review documents are included instead of being attached, so that they will provide useful minutes. Separate documents will be sent to the ISAC for review and critique. ACTION: Described in included document. TOPIC: IR2068 Entity instantiation with space before the entity name Peter's analysis is accepted. Entity instantiations may have a space before the entity name. ACTION: IR2068 is ISAC approved, subject to review by Deepak and Ajay. DOCUMENT response_difficult.txt: This is the response document to the ballots for the Difficult ISAC-Approved Issue Reports. The following IRs were submitted for ballot: 2004, 2013, 2032, 2042, 2045 All IRs were approved. IRs Approved Without Comments: 2013, 2032 IRs which received comments: 2004 Definition of SLA doesn't make sense In an informative affirmative ballot, a reviewer strongly supports the decision that no change is necessary in the definition of SLA CONCLUSION: IR2004 is VASG-approved. 2042 Architecture as a block causes problems In an affirmative ballot, a reviewer asks if it is necessary add a new annex or clause in the 2002 LRM to inform users of these issues. RESPONSE: The ISAC will mention this possibility to the VASG. However, the effort involved in making any official change to the 2002 LRM is virtually the same as re-balloting the LRM. Also, the ISAC knows of no implementation which has treated the architecture as a separate block, so in practice, this should not be a problem. In a negative ballot, a reviewer states two issues (quoted in full): "1. The analysis does not seem to take into consideration the use of path names from the point of view of pre-elaboration tools. The standard should provide one set of rules for path interpretation that can be used within the language and within VHDL tools. Since the entity/architecture relationship is one to many, it is necessary to be able to distinguish between declarations of one architecture from another of the same entity. Thus, support for E.A1.C and E.A2.C (entity E, architectures A1 and A2, constant C in each architecture) should also be a requirement for a proper solution." RESPONSE: The names discussed in the analysis are expanded names (see LRM clause 6.3), not path names. Specifically, the names Work.E.C, E.C, and A.C can only be used within the declarative region where C is declared. This form of name is distinct from path names (either pre- or post-elaboration), which address an item from an external view, that is, from a root name space external to the enclosing construct. Formation of paths names is a separate issue from that addressed in IR2042. Path names are addressed elsewhere, including: - VHPI: A pre-elaboration path name for the constant C in the example would be Work.E:A.C - Cross-Module Reference (XMR) proposal described in VHDL-200x-FT proposal FT07 - PSL There is an ongoing discussion to unify the form of path names among these specifications, the 'path_name and 'instance_name specifications, and expanded names. See http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft32_pathname.pdf and http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft32_pathname_issue_roll up.html. "2. If E.C is allowed, it must be restricted to use only within the architecture body, or there must be some rules introduced to require that every architecture of E have compatible declarations of C." RESPONSE: Since C is declared within the architecture body, it cannot be referenced within the entity declaration. The scope and visibility rules (LRM clauses 10.2 and 10.3) specify that the scope of the declaration of C starts at the declaration and extends to the end of the architecture body. In this case, C is only visible within its scope, which does not extend to the entity declaration. So the existing rules already address the commenter's requirement. CONCLUSION: IR2042 is VASG-approved. 2045 Add the ability to comment an entire block of code In one affirmative ballot and one informative negative ballot, two reviewers state that nested block comments should be allowed. In an informative affirmative ballot, a reviewer supports the prohibition on nested block comments. RESPONSE: Some nesting of comments is allowed, since -- comments can be present within a block comment. Since the affirmative vote was for a construct in which nested block comments are not allowed, there is no change to the existing issue solution. Notice however, that if it is later determined that nested block comments should be allowed, this capability can be added without affecting backward compatibility. In a negative ballot, a reviewer supports the solution but states that the ISAC should not be adding language constructs. RESPONSE: The ISAC is technically not adding language constructs. The ISAC has made a recommendation to the VASG, which can accept, reject, or modify the recommendation. Also, historically, the ISAC has made proposals for language changes, particularly in areas which require careful language analysis. For this particular issue it was decided that the fastest way to resolve it was to make a specific recommendation. CONCLUSION: IR2045 is VASG-approved.Received on Wed Jul 20 16:16:45 2005
This archive was generated by hypermail 2.1.8 : Wed Jul 20 2005 - 16:16:46 PDT