ISAC: New IR 2132 Method to allow functions that return arrays to have knowledge of the arry bounds

We will almost certainly defer discussion on this until after VHDL200X 
is finished.
Chuck Swart


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


VHDL Issue Number:        2132

Language_Version          VHDL-2002
Classification            Language Modeling Enhancement or Deficiency
Summary                   Method to allow functions that return arrays to have knowledge of the array bounds
Relevant_LRM_Sections     
Related_Issues            I believe Jonathon Bromley submitted an enhancement request addressing the 
                          same type of problem but suggesting use of function overrides of the assignment 
                          operator.
Key_Words_and_Phrases     
Authors_Name              Kevin Jennings
Authors_Phone_Number      734-737-4268
Authors_Fax_Number        
Authors_Email_Address     Kevin.Jennings@Unisys.com
Authors_Affiliation       Unisys Corp.
Authors_Address1          41100 Plymouth Road
Authors_Address2          Plymouth, Michigan 48170
Authors_Address3          

Current Status:           Submitted

Superseded By:

------------------------
Date Submitted:           18 June 2008
Date Analyzed:
Author of Analysis:
Revision Number:          0
Date Last Revised:

Description of Problem
----------------------

Functions that return arrays occasionally need knowledge of the array
bounds to which they are going to be assigned in order to operate
properly.  In order to provide this information today, a function must
provide additional arguments that are typically attributes of the
signal/variable being assigned to.

One class example involving numeric_std is:

     x <: to_unsigned(1, x'length);
    
Another involving fixed_pkg is resize

    x <= resize(a, x);
    
In both instances the argument 'x' is supplied as an input to a
function solely for the purposes of allowing the function to have
knowledge of some attribute(s) of the intended recipient of the
function.  In the case of 'to_unsigned' the 'length attribute is
needed; in the case of 'resize' the 'left and 'right attributes are
needed.
    
When working with real designs this can lead to latent design errors
if the argument put into the function is inadvertently different than
the actual assigned object.
    
Furthermore, the clarity of the code is compromised with the addition of these parameters.  Example:

    A: x <= to_unsigned(1)
    B: x <= to_unsigned(1, 8);
    
In 'A', it is abundantly clear that all that is being done is to
convert the integer '1' into an unsigned signal 'x'.  In 'B', it is
not so obvious because of the '8' parameter.  Granted most developers
already 'know' that 'B' is converting the integer '1' into an 8 bit
unsigned, but as can be seen by the recent development of the
'fixed_pkg' set of functions there can be a lot more functions that
could make use of the knowledge of attributes of the intended target
and using those functions start getting ugly really quickly because of
the need to pass in attributes of the target.

Proposed Resolution
-------------------

A function already has some knowledge of the target in that it knows
the type of the target.  What is missing for array types is simply
knowledge of the array attributes that can be important as mentioned
previously.  One solution is to provide a new keyword (I'll call it
'constrained') that is part of the function declaration and another
keyword (I'll call it 'that') that a function can access to obtain the
array attributes.  A given function can be overloaded either
containing the 'constrained' keyword or not; the compiler would
determine which function to call based on whether the target has known
size (call the 'constrained' version) or if it does not (call the
typical version of the function).  As an example, 'to_unsigned' could
be defined as follows:
    
    function to_unsigned(x:
    unsigned) return constrained unsigned is
    begin
      return(to_unsigned(x, that'length));
    end function to_unsigned;
    
This would allow for the following usage:

    x <:     to_unsigned(1);
    
as well as code clarity improvements to how fixed_pkg and possibly
other packages get used in real designs.
    
Another solution would be to provide overrides to the assignment
operators (i.e. '<=' and ':=').  In order to accomplish these
overrides, it's likely that these override functions would need access
to the same type of magical new 'that' as demonstrated above so the
addition of something like the new keyword 'that' in order to access
attributes would be equivalent.  Providing overrides of the assignment
operators though would likely cause more language issues than simply
providing for a new override of a function that would be called only
when the target type has a defined range.

VASG-ISAC Analysis & Rationale
------------------------------
TBD

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

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