ISAC: new IR2126

We can discuss this at our next meeting, on January 9.
I have some email correspondence regarding this issue which
I will forward as soon as I get permission from the correspondent.

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:           Submitted

Superseded By:

------------------------
Date Submitted:           11 December 2007
Date Analyzed:
Author of Analysis:
Revision Number:          0
Date Last Revised:

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
------------------------------
TBD

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
TBD

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
TBD