WithDrawn: Functions Know Output Subtype

Proposal Information

• Who Updates:
• Date Proposed: April 4, 2013 twiki
• Date Last Updated: 27 Feb 2014
• Priority:
• Complexity:
• Focus:
• Status: WithDrawn

Tracking proposal for ISAC IR IR2132

Summary: This proposal does not address the interests of the author of IR2132, so it has been withdrawn.

Related Issues: None = General

Competing Issues: None at this time

Use cases

It would be convenient in many cases to have access to the output or destination subtype. For example, the fixed-point resize has to pass in the output.

   signal a : sfixed(0 downto -7);
   signal b : sfixed(0 downto -7);
   signal c : sfixed(-1 downto -3);
   ...
   c <= resize(a + b, c);  -- old syntax
   c <= resize(a + b);     -- new syntax

But how do you handle chains of operators?

   signal d : sfixed(1 downto -4);
   signal e : sfixed(-1 downto -6);
   ...
   c <= resize(d + resize(e * resize(a + b)));
   -- what is the output subtype of the inner resize?

-- JimLewis - 2014-04-10:

One of the crown jewels of VHDL is early error detection. In the following example, the assignments to C_uv8 and D_uv9 make sense, however, E_uv7 should never be ok. If we are going to add something of this nature, it needs to detect these sort of errors. For functions that have "ADA" style post conditions that specify sizing rules, we may be able to make something like this work.

   signal A_uv8, B_uv8 : unsigned(7 downto 0) ; 
   signal C_uv8 : unsigned(7 downto 0) ; 
   signal D_uv9 : unsigned(8 downto 0) ; 
   signal E_uv7 : unsigned(6 downto 0) ;
   ...
   C_uv8 <= A_uv8 + B_uv8 ;   -- Same as rules in unsigned and signed
   D_uv9 <= A_uv8 + B_uv8 ;   -- Similar to rules for ufixed and sfixed
   E_uv7 <= A_uv8 + B_uv8 ;   -- Incorrect math, must remain a compile time error.

Language impact

This proposal has an enormous potential impact.

Arguments FOR

Arguments AGAINST

From a mathematical point of view, this proposal is utterly unacceptable. A function is defined in terms of its inputs. Adding a dependency on the output opens the door for paradoxes, race conditions, etc.

From a practical point of view, how do you define the output of a function that is used as an (unconstrained) input to another function?

-- RyanHinton - 2013-10-24

Currently the subtypes in a function are the subtypes of the formals, not the actuals.

-- PeterFlake - 2014-10-02

Discussion

Reply

One difference is that inputs have actuals when the function is called. The output of a function may be the input to another function -- in general to any expression. Here is a silly but valid example. Say both "resize" and "to_unsigned" are defined using this proposal. Then how big is the intermediate result in

resize(to_unsigned(15), 3)

? This example is silly, but the fixed-point operations change vector lengths for most arithmetic operations. So maybe a better example is

a + to_sfixed(-1.562)

What should be the index range for the to_sfixed output?

We don't have an actual for the output, so we can't in general try to access attributes like 'length.

-- RyanHinton - 2013-04-12

Next thread

Defining constants

I understand the desire here. Several times recently I have wanted to know the size of the output in order to size the result of a function. However, I constantly use function return values to set the dimensions on unconstrained arrays. I want to keep this feature. But I don't like using overloading to determine whether a function can access the output size.

So I would like for this problem to be solved, but I don't like the solution yet. I would like it if

• I can still use the return subtype to constrain constant declarations, and
• I don't have to use overloading to handle both known and unknown cases.

-- Ryan Hinton -2013-04-10

Non-supporters

Add your signature here to indicate non-support for this proposal.

-- RyanHinton - 2013-10-24

-- JimLewis - 2014-04-10

-- PeterFlake - 2014-10-02

Supporters

Add your signature here to indicate support for this proposal.