Overload Assignment ":="

Proposal Information

• Who Updates: JimLewis, Needs Champion
• Date Proposed: 2013-10-11
• Date Last Updated: 2013-10-31
• Priority:
• Complexity:
• Focus: General Language

Tracking proposal for ISAC IR IR2130

http://www.eda.org/isac/IRs-VHDL-2002/IR2130.txt

Also see Bugzilla 239

Summary

This is a generalized implicit conversion that is applied at the highest level of any expression as it is applied to initializations (constant, variable, and signal), variable assignment, signal assignment, parameter map, port map, conditional expressions,...

Like the "??" operator, this is only able to be applied at the highest level of an expression.

While the IR visualizes this as a procedure, I think it would be better as a function.

It could potentially subsume the VHDL-2008 "??" operation.

?Should we alternately consider an implicit cast?

Related Issues: None = General

Competing Issues: None at this time

Use cases

CASE 1: Implicit Conversions to Integer

Based on my memory of old emails, I suspect this is one thing Jonathan had in mind.

    function ":=" (A: unsigned) return integer is 
    begin
      return ieee.numeric_std.to_integer (A) ; 
    end function ":=" ;

   . . . 

   signal ReadIndex : unsigned(5 downto 0) ; 

   type RegBankType is array (63 downto 0) of std_logic_vector(15 downto 0) ; 
   signal RegBank : RegBankType ;
    . . .
    ReadData <= RegBank( ReadIndex ) ;  

Currently what we have to do is:

ReadData <= RegBank( to_integer(ReadIndex) ) ;  

CASE 2: Subsume VHDL-2008 "??" operator

CASE 3: Assigning constants

variable x : unsigned(7 downto 0) := 42;

Language impact

Initially got an OMG from vendors. Not sure it is worth the effort. While case 1 is nice, it does not occur with a high frequency (like conditionals and the "??" operator does). I think we need either a high frequency use case or many other use cases.

The problem of using functions

-- BertDeJong - 2013-10-31 There is a problem in using functions for overloading the assignment operator: When the tool has to choose which overloaded version of a function it should use, it does this based on the types of the arguments and not on the return type. This would mean that the assignment operator could only be overloaded once for each right hand side type.
Using procedures instead of functions solves this problem. Another advantage of using procedures is that you can get attribute properties of the target type.

-- JimLewis - 2014-10-14 @Bert, function overloading uses return values for overload resolution. See section 4.5.1, p27, of 1076-2008. Or alternately look at the non-standard std_logic_arith, for unsigned operations (such as "+"), it provides both unsigned and std_logic_vector for the result types.

-- BrianDrummond - 2013-12-16 Another advantage of procedures is that "Set(X,Y)" already works with no language changes.

-- DanielKho - 2014-12-18 I find myself doing lots of explicit type conversions like these, and it will be very helpful if some of these conversions can be made implicit. @Brian, @Bert, can you provide examples on how you would use procedures with the above Cases 1 & 3? Like Jim mentioned, don't we need return values in these cases, which can now only be provided with functions?

Non-supporters

Add your signature here to indicate support for this proposal.

-- JimLewis - 2013-10-11 - I am on the fence, but really need to see other use cases.

-- BrianDrummond - 2013-12-05 - I am in the "Assignment is NOT an operator" camp.

-- ErnstChristen - 2015-01-21 - Agreed, assignment is different from an operator.

Supporters

Add your signature here to indicate support for this proposal.

-- BertDeJong - 2013-10-31 - If done with procedure

-- DanielKho - 2014-12-18

-- PatrickLehmann - 2016-02-19