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.Received on Tue Apr 6 18:51:23 2010
This archive was generated by hypermail 2.1.8 : Tue Apr 06 2010 - 18:51:44 PDT