Also are included:
revised IR2004
list of active IRs
Minutes of ISAC meeting held via telecom on
04 November 2004.
Present: Peter Ashenden, Jim Lewis, Chuck Swart, Ajay Varikat
Absent: Deepak Pant
Next Meeting:23 November 2004 7pm Pacific Time
NOTE: This meeting is scheduled on Tuesday(West coast, USA) instead
of the usual Thursday.
TOPIC: email list.
We will use the list isac@eda.org from now on. This will make it
easier to filter our isac emails.
TOPIC: Web-based IR repository.
We are looking into using Mentor equipment to support bugzilla for an
ISAC/VASG database.
TOPIC: IR2046: Type independent ports and subprogram parameters
This fits in nicely with DTA work on type generics. A good example
of the utility of this is a general multiplexer.
ACTION: Peter to send Chuck examples (done). Chuck to incorporate
examples into IR and forward to DTA.
TOPIC: IR2040: Problems with OTHERS in aggregates
A few minor typos were found. A question arose about the
term "static" was needed or wanted in the sentence:
"2) The formal designator is a slice that has a static name"
Note added: 4.3.2.2. states:
"Each association element that associates a slice or subelement (or
slice thereof) of an interface object must identify the formal with a
locally static name."
So I (Chuck) suggest that we either drop the "static" or replace it
with "locally static."
ACTION: Ajay to fix minor typos (done). All to review and vote on at
next meeting.
TOPIC: IR2000: Where may/must deferred constant declaration appear
A minor typo was found.
ACTION: Chuck to update(done). All to vote electronically.
TOPIC: IR2001: Resize not working in numeric_std.vhd (1076.3)
The code and documentation are correct. The submitter misunderstood
the problem. ISAC approved
ACTION: Chuck to forward to VASG.
TOPIC: IR2002: Resize(R.2) function in numeric_std.vhd does improper array length check
The code and documentation are correct. The submitter misunderstood
the problem. ISAC approved
ACTION: Chuck to forward to VASG.
TOPIC: IR2004: Definition of SLA doesn't make sense
The analysis gives the reason why certain decisions were made. The
ISAC Recommendation for Future Revisions needs to reflect the
possibility that the shift operators may be extended to a wider class
of types. There may be trade offs between the desire for uniform
semantics and the requirement for backward compatibility.
ACTION: Chuck to update(done).
TOPIC: IR2006: "else" in "if generate"
It was agreed to send this issue to M+P. However, a number of problems
were uncovered. What is the exact syntax for this? Are there labels
for each generate part? If so, where are they specified. How are "if
generate".."else" constructs dealt with in block configurations in
configuration declarations?
ACTION: Peter to update, then Chuck to send to VASG.
TOPIC: IR2007: VHDL needs to be enhanced to allow the modeling of switches.
It was agreed to send this issue to M+P.
ACTION: Chuck to forward to VASG.
TOPIC: IR2008: Source value of undriven, non-sourced INOUT, OUT or BUFFER port
Peter's analysis seems correct. Since this is a non-trivial issue we'll review
it and vote on it at our next meeting.
ACTION: All to review. Vote at next meeting.
Active IRs:
No Status Responsible Description Notes
Summary
2000 Analyzed Chuck Where may/must deferred constant declaration appear
2004 Analyzed Chuck Definition of SLA doesn't make sense
2008 Analyzed Peter Source value of undriven, non-sourced INOUT, OUT or BUFFER port
2009 Analyzed Peter New std package, containing compiler and target identification information
2010 Analyzed Peter The description of type/subtype relationship could be better
2011 Analyzed Peter A package body should be able to consist of several files
2012 Analyzed Peter VHDL lacks inherent statements to describe the most basic hardware design equations
2013 Submitted Exact subtype "matching" for port associations
2014 Analyzed Peter Allowance of the keyword "all" in place of a sensitivity list is desirable
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
Recent Inactive IRs
1044 ISAC-Approved Definition of 'HIGH and 'LOW in a null range
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.
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
-------------BEGINNING OF IR----------------
VHDL Issue Number: 2004
Language_Version: VHDL-2002
Classification: Language Definition Problem
Summary: Definition of SLA doesn't make sense
Relevant_LRM_Sections: 7.2.3
Related_Issues:
Key_Words_and_Phrases: SLA
Authors_Name: Paul Graham
Authors_Phone_Number:
Authors_Fax_Number:
Authors_Email_Address: pgraham@cadence.com
Authors_Affiliation:
Authors_Address1:
Authors_Address2:
Authors_Address3:
Current Status: Submitted
Superseded By:
------------------------
Date Submitted: 04 August 2000
Date Analyzed: 28 October 2004
Author of Analysis: Chuck Swart
Revision Number: 2
Date Last Revised: 05 November 2004
Description of Problem
----------------------
The definition of sla in the 1993 LRM is kind of weird. It basically
preserves the parity bit of the left input:
1 sla 1 == 3
etc. I have never seen a computer opcode which implements this
function, though sll, srl, and sra opcodes are ubiquitous. ?
Proposed Resolution
-------------------
Why not just define sla to be the same as sll (as in Verilog)
VASG-ISAC Analysis & Rationale
------------------------------
The SLA operator was added to provide a symmetric set of left and
right shift operators. As currently defined, these operators make no
assumptions about whether the left bit of a bit vector or the right
bit is signed. Notice that these operators are only defined for
vectors of type bit or of type boolean. The intent is that all shift
operators can be overloaded to achieve any desired semantic
interpretation.
VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change is needed for the current version.
VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
No change is needed for future versions. However, there are currently
attempts to extend the shift operators to a larger class of types. If
these extended definitions treat the predefined SLA operator for these
types in a different way than the existing LRM states, then there will
be a conflict between the need for uniform semantics for the
predefined operators and the requirement for backward compatibility.
-------------END OF IR----------------
Received on Mon Nov 8 09:56:23 2004
This archive was generated by hypermail 2.1.8 : Mon Nov 08 2004 - 09:56:24 PST