Re: [vhdl-200x] implicit conversions

Hello,

The conversions from UNSIGNED to NATURAL and from SIGNED to INTEGER
are somehow safe as soon as the vector sizes are less than (or equal
to) the number of bits required to store the number value. This rule
is more restrictive for cross-conversions from UNSIGNED to INTEGER and
from SIGNED to NATURAL. An other discussion was started about
extending the integer sizes. This extension would relax the above
constraints and conversions from bigger vectors would become possible.

About overload resolutions, you're right. It will cause conflicts for
subprograms that accept operands of different types. Such overload
subprograms are commonly used for operator overloading. If the
implicit conversions become valid, many operator subprograms would
become superfluous since they perform explicit conversions when their
execution begins.

Best Regards,

- Florent

Peter Ashenden <peter@ashenden.com.au> a écrit :
> Florent,
>
> Seems like a reasonable and useful idea. I would add two refinements:
>
> * Also consider conversion from IEEE.NUMERIC_STD.UNSIGNED and
> IEEE.NUMERIC_BIT.UNSIGNED, BIT_VECTOR and STD_LOGIC_VECTOR using
> the standard package TO_INTEGER functions for these types.
> * Need to make sure the overload resolution rules are still
> workable. So the implicit conversion could only be applied when
> the only legal interpretation of the expression is of type INTEGER
> and without the conversion there is no legal interpretation of the
> expression. This is similar to what we specify for implicit
> conversion to BOOLEAN in conditions.
>
> Cheers,
>
> PA
>
> On 7/04/2010 05:15, Florent Ouchet wrote:
>> Dear list,
>>
>> VHDL v2008 added a lot of implicit conversions, especially for
>> conditions. The condition can be of either BOOLEAN, BIT or
>> STD_ULOGIC type. I would like to go one step further and to allow
>> implicit conversions for integer types. When an expression type is
>> determined by the context to be an INTEGER, the language should
>> accept expressions of IEEE.NUMERIC_STD.SIGNED and
>> IEEE.NUMERIC_BIT.SIGNED types.
>>
>> For instance, lets consider the following statements:
>>
>> signal some_index: unsigned(7 downto 0);
>> signal some_vector: std_logic_vector(255 downto 0);
>> signal some_output: std_logic;
>>
>> Presently, the designer has to call either
>> IEEE.NUMERIC_STD.TO_INTEGER or IEEE.NUMERIC_BIT.TO_INTEGER.
>> However, these function calls are transparent at hardware level:
>>
>> some_output <= some_vector(to_integer(some_index));
>>
>> I would like to make this statement valid:
>>
>> Some_output <= some_vector(some_index);
>>
>> Of course, the behaviour of the implicit conversions shall be the
>> same as the behaviour of TO_INTEGER functions. These implicit
>> conversions shall be allowed every time the context expects some
>> expression of type integer.
>>
>> Best regards,
>>
>>
>
> --
> Dr. Peter J. Ashenden peter@ashenden.com.au
> Ashenden Designs Pty. Ltd. www.ashenden.com.au
> PO Box 640 Phone: +61 8 7127 0078
> Stirling, SA 5152 Mobile: +61 414 70 9106
> Australia
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

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