VHDL : How is this statement resolved: type foo is range -(2**30) to 2**30;?

Question

I am having an issue processing the following type declaration:

type foo is range -(2**30) to 2**30;

For the exponentiation, there are two possible interpretations to consider:

function "**"(universal_integer, integer) return universal_integer;

function "**"(integer, integer) return integer;

(There are interpretations using reals, but we can easily reject those since the first argument is integral.)

Since the second operand of the exponentiation must be integer, use of either alternative requires an implicit conversion. For this reason, we cannot disqualify either choice on the grounds that an implicit conversion is required.

The bounds of a type declaration must be of some integral type, but they need not be the same type. Absent any further constraints, I reject this type declaration as being ambiguous.

This seems to be a quirk with exponentiation. If I had instead:

type foo is range 0 to 2 * 30;

Then again you have two alternatives for "*". However:

function "*"(universal_integer,universal_integer) return universal_integer;

does not require an implicit conversion, so we can use that and reject the other.

Furthermore:

constant K: integer := 2 ** 30;

also works fine due to the additional constraint that the result type must be integer.

But the combination of type definition and exponentiation deprives us of enough information to make a selection.

Since this type definition works in other implementations, what am I missing?

On behalf of my implementor .. Ken

Answer 1

For

type foo is range -(2**30) to 2**30;

There are two eligible "**" functions implementing the exponentiation operator.

9.2.8 Miscellaneous operators

The exponentiating operator ** is predefined for each integer type and for each floating-point type. In either case the right operand, called the exponent, is of the predefined type INTEGER.

Exponentiation with an integer exponent is equivalent to repeated multiplication of the left operand by itself for a number of times indicated by the absolute value of the exponent and from left to right; if the exponent is negative, then the result is the reciprocal of that obtained with the absolute value of the exponent. Exponentiation with a negative exponent is only allowed for a left operand of a floating-point type. Exponentiation by a zero exponent results in the value one. Exponentiation of a value of a floating-point type is approximate.

Predefined operators for predefined types are shown as comments in package STANDARD. The two applicable here:

16.3 Package STANDARD

-- function "**" (anonymous: universal_integer; anonymous: INTEGER)
-- return universal_integer;

-- function "**" (anonymous: INTEGER; anonymous: INTEGER) -- return INTEGER;

Note the right operand type is INTEGER. The right operand is subject to implicit type conversion.

The reason there are two is found in 5.2.3 Integer types, 5.2.3.1 General:

Each bound of a range constraint that is used in an integer type definition shall be a locally static expression of some integer type, but the two bounds need not have the same integer type. (Negative bounds are allowed.)

Integer literals are the literals of an anonymous predefined type that is called universal_integer in this standard. Other integer types have no literals. However, for each integer type there exists an implicit conversion that converts a value of type universal_integer into the corresponding value (if any) of the integer type (see 9.3.6).

The bounds are required to be some integer type and that can include universal_integer.

Which of those two are selected by The context of overload resolution is based on semantics found in 9.3.6 Type conversions:

In certain cases, an implicit type conversion will be performed. An implicit conversion of an operand of type universal_integer to another integer type, or of an operand of type universal_real to another floating-point type, can only be applied if the operand is either a numeric literal or an attribute, or if the operand is an expression consisting of the division of a value of a physical type by a value of the same type; such an operand is called a convertible universal operand. An implicit conversion of a convertible universal operand is applied if and only if the innermost complete context determines a unique (numeric) target type for the implicit conversion, and there is no legal interpretation of this context without this conversion.

You only implicitly convert from universal_integer to another integer type if there is no other legal interpretation. This is the mechanism to prevent two possible choices here in the context of overload resolution.

For 2 ** 30 do you have to implicitly convert the left operand? No. Do you have to implicitly convert the right operand? Yes, both choices require the type be INTEGER. Further there's no requirement the result be a different integer type than universal_integer required by the semantics of integer type definition (5.2.3.1).

Looking at 9.5 Universal expressions, there's one additional limitation on the definition of an integer type here:

For the evaluation of an operation of a universal expression, the following rules apply. If the result is of type universal_integer, then the values of the operands and the result shall lie within the range of the integer type with the widest range provided by the implementation, excluding type universal_integer itself. If the result is of type universal_real, then the values of the operands and the result shall lie within the range of the floating-point type with the widest range provided by the implementation, excluding type universal_real itself.

There's no way for you to use literals to describe an integer type with a value range greater than that of type INTEGER, the only predefined integer type (5.2.3.2).

There's also the limitation of integer literals of the anonymous type universal_integer whose value range is unknowable.

12.5 The context of overload resolution

When considering possible interpretations of a complete context, the only rules considered are the syntax rules, the scope and visibility rules, and the rules of the form as follows:

a) ...
e) The rules given for the resolution of overloaded subprogram calls; for the implicit conversions of universal expressions; for the interpretation of discrete ranges with bounds having a universal type; for the interpretation of an expanded name whose prefix denotes a subprogram; and for a subprogram named in a subprogram instantiation declaration to denote an uninstantiated subprogram.
f) ...

Where we can see both the semantics of implicit conversion found in 9.3.6 and the limitations on range found in 9.5 are embraced.

For purposes of knowing how to select between the two candidate functions providing operator overload the key is found in 9.3.6.

Both operands of of the exponentiation operator in

constant K: integer := 2 ** 30;

can be implicitly type converted to another integer type (INTEGER) while the otherwise universal expression 2 ** 30 can't be implicitly converted, not meeting the requirements of 9.3.6 (the operands aren't values of a physical type and operator isn't the multiplying operator /).

The overload for that is also alluded to in package STANDARD:

-- function "**" (anonymous: INTEGER; anonymous: INTEGER) -- return INTEGER;

Chuck Swart (the last ISAC chair) described this behavior in Issue Report 2073 (IR2073.txt) as forcing implicit type conversion to the leaves of an abstract syntax tree. In his words "This clause implies that implicit conversions occur as far down as possible in the expression tree." Note that 9.3.6 was 7.3.5 before Accellera VHDL -2006 was re-written to conform to the IEEE-SA's format for a standard.

The universal_integer to to another integer type conversion can be forced away from the leaves by using explicit type conversion:

constant K: integer := integer(2 ** 30);

Noting the right operand of "**" the integer literal 30 would still be implicitly type converted to type INTEGER, while the left operand and result are of type universal_integer.