Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   Ambiguous type in infix expression (http://www.velocityreviews.com/forums/t639905-ambiguous-type-in-infix-expression.html)

jens 10-15-2008 04:22 AM

Ambiguous type in infix expression
 
The code listed below yields the following errors in ModelSim:

Ambiguous type in infix expression; ieee.numeric_std.unsigned or
work.test_package.unsigned8_array.
Illegal type conversion to ieee.numeric_std.signed (operand type is
not known).

The original code does something a little more useful, I just whittled
it down. Commenting out the seemingly unrelated type definition fixes
the problem, as does changing the typedef to a signed array. Moving
the "000" outside of the type conversion also works ("000" &
signed(...)). Various other attempts to remove the error typically
didn't work (including using a type qualifier for the "000").

In the meantime I've avoided the problem by using shift_left, but it
seems like there's nothing ambiguous here and that it should work.
Note that nothing's actually using the typedef. Any ideas?

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

package test_package is

type unsigned8_array is array (natural range <>) of unsigned(7
downto 0); -- here's what causes the error

end package test_package;

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
library work;
use work.test_package.all;

entity test is
port
(
input_unsigned: in unsigned(15 downto 0);
output_signed: out signed(15 downto 0)
);
end entity test;

architecture arch of test is
begin

output_signed <= signed("000" & input_unsigned(15 downto 3)); --
this is the line with the error

end architecture arch;

sandeep 10-15-2008 06:21 AM

Re: Ambiguous type in infix expression
 
On Oct 15, 12:22*pm, jens <ro...@rochester.rr.com> wrote:
> The code listed below yields the following errors in ModelSim:
>
> Ambiguous type in infix expression; ieee.numeric_std.unsigned or
> work.test_package.unsigned8_array.
> Illegal type conversion to ieee.numeric_std.signed (operand type is
> not known).
>
> The original code does something a little more useful, I just whittled
> it down. *Commenting out the seemingly unrelated type definition fixes
> the problem, as does changing the typedef to a signed array. *Moving
> the "000" outside of the type conversion also works ("000" &
> signed(...)). *Various other attempts to remove the error typically
> didn't work (including using a type qualifier for the "000").
>
> In the meantime I've avoided the problem by using shift_left, but it
> seems like there's nothing ambiguous here and that it should work.
> Note that nothing's actually using the typedef. *Any ideas?
>
> library ieee;
> * * use ieee.std_logic_1164.all;
> * * use ieee.numeric_std.all;
>
> package test_package is
>
> * * type unsigned8_array is array (natural range <>) of unsigned(7
> downto 0); -- here's what causes the error
>
> end package test_package;
>
> library ieee;
> * * use ieee.std_logic_1164.all;
> * * use ieee.numeric_std.all;
> library work;
> * * use work.test_package.all;
>
> entity test is
> port
> (
> * * input_unsigned: in *unsigned(15 downto 0);
> * * output_signed: *out signed(15 downto 0)
> );
> end entity test;
>
> architecture arch of test is
> begin
>
> * * output_signed <= signed("000" & input_unsigned(15 downto 3)); --
> this is the line with the error
>
> end architecture arch;


I tried to compile above code and didnot get any errors or warnings. I
am using
Cadence 5.8. And for me code looks ok.

spam@oxfordbromley.plus.com 10-15-2008 07:21 AM

Re: Ambiguous type in infix expression
 
On Oct 15, 5:22 am, jens <ro...@rochester.rr.com> wrote:
> The code listed below yields the following errors in ModelSim:
>
> Ambiguous type in infix expression; ieee.numeric_std.unsigned or
> work.test_package.unsigned8_array.
> Illegal type conversion to ieee.numeric_std.signed (operand type is
> not known).

[...]
> type unsigned8_array is array (natural range <>) of unsigned(7
> downto 0); -- here's what causes the error


I would need to do a bit of digging in the LRM to be totally
sure, but I think Modelsim is probably right here. Your
expression
"000" & input_signed(...)
has the function signature
"&"[UNSIGNED, UNSIGNED] return <something>
and, because it's inside a type conversion, VHDL has
no hints about what "something" might be. So it looks
for all the various forms of "&" it knows about, and
it finds
--- the one you want, and we all know and love
"&"[UNSIGNED, UNSIGNED] return UNSIGNED;
--- an implicit & operator provided by your new
--- array-of-signed type
"&"[UNSIGNED, UNSIGNED] return unsigned8_array;

I'd be happy to be corrected about this; anything
to do with the implicit operators created by a type
definition is a reliable way of confusing me.

If I'm right, the following rather ugly arrangement
should fix it, by forcing the "&" operator to return
UNSIGNED as you require:

output_signed <= signed(
unsigned'(
"000" & input_unsigned(15 downto 3)
)
);

Note the inner type QUALIFICATION, not conversion.

However, I would have thought that this version would
probably be nicer, and closer to your intent:

output_signed <= signed (
resize (
input_unsigned(15 downto 3),
output_signed'length
)
);

Or maybe something with a shift operator:

output_signed <= signed ( input_unsigned srl 3 );

Finally, a custom conversion function would probably
be best of all, especially if you're using it in more
than one place; hide away all the ugliness inside a
function with a nice sensible name!
Obviously, it depends on the details of what you're
really doing.

HTH
--
Jonathan Bromley

James Unterburger 10-15-2008 07:38 AM

Re: Ambiguous type in infix expression
 
If Cadence compiled this, then they are not LRM compliant.

The problem is with the type conversion expression:
signed("000" & input_unsigned(15 downto 3))

Well actually, since we can't use the target type of the conversion
when determining the type of the operand of the type conversion,
the problem is with the operand, which is the concatenation expression,
the infix expression mentioned in the error message from
ModelSim:

"000" & input_unsigned(15 downto 3)


Any compliant compiler must choose which "&" operator to use
from the overloading rules, which allow only types (not
subtypes) to be considered.

Since the slice of input_unsigned is of type unsigned, there
are two "&" operators which could be used, hence the error
since this is ambiguous:

"&"[unsigned, unsigned RETURN unsigned]
"&"[unsigned, unsigned RETURN unsigned8_array]

So the concatenation is either an [array&array=>longer array]
concatenation, or a [elem&elem=>2-element array] concatenation
(which would be an error in this example since neither element
is an 8-element array). Again, only types, not subtypes are
allowed when attempting to disambiguate overloaded operators
and/or functions.

Use a qualified expression to tell the compiler the type
of the result of the concatenation:

output_signed <= signed(unsigned'("000" & input_unsigned(15 downto 3)));

In the above, the "&" operator is being "told", via the qualified
expression, what its return type must be, so the array-of-array
implicit "&" operator is no longer considered.

This will also work:

output_signed <= ("000" & signed(input_unsigned(15 downto 3)));

In the above, the type conversion of input_unsigned to type signed
removes the array-of-array type's implicit "&" operators from
consideration (since the element type is unsigned, not signed),
so the ambiguity disappears.


sandeep wrote:
> On Oct 15, 12:22 pm, jens <ro...@rochester.rr.com> wrote:
>
>>The code listed below yields the following errors in ModelSim:
>>
>>Ambiguous type in infix expression; ieee.numeric_std.unsigned or
>>work.test_package.unsigned8_array.
>>Illegal type conversion to ieee.numeric_std.signed (operand type is
>>not known).
>>
>>The original code does something a little more useful, I just whittled
>>it down. Commenting out the seemingly unrelated type definition fixes
>>the problem, as does changing the typedef to a signed array. Moving
>>the "000" outside of the type conversion also works ("000" &
>>signed(...)). Various other attempts to remove the error typically
>>didn't work (including using a type qualifier for the "000").
>>
>>In the meantime I've avoided the problem by using shift_left, but it
>>seems like there's nothing ambiguous here and that it should work.
>>Note that nothing's actually using the typedef. Any ideas?
>>
>>library ieee;
>> use ieee.std_logic_1164.all;
>> use ieee.numeric_std.all;
>>
>>package test_package is
>>
>> type unsigned8_array is array (natural range <>) of unsigned(7
>>downto 0); -- here's what causes the error
>>
>>end package test_package;
>>
>>library ieee;
>> use ieee.std_logic_1164.all;
>> use ieee.numeric_std.all;
>>library work;
>> use work.test_package.all;
>>
>>entity test is
>>port
>>(
>> input_unsigned: in unsigned(15 downto 0);
>> output_signed: out signed(15 downto 0)
>>);
>>end entity test;
>>
>>architecture arch of test is
>>begin
>>
>> output_signed <= signed("000" & input_unsigned(15 downto 3)); --
>>this is the line with the error
>>
>>end architecture arch;

>
>
> I tried to compile above code and didnot get any errors or warnings. I
> am using
> Cadence 5.8. And for me code looks ok.


Mike Treseler 10-15-2008 11:59 AM

Re: Ambiguous type in infix expression
 
jens wrote:

> Ambiguous type in infix expression; ieee.numeric_std.unsigned or
> work.test_package.unsigned8_array.
> Illegal type conversion to ieee.numeric_std.signed (operand type is
> not known).


See also:
http://groups.google.com/group/comp....clare+subtypes

-- Mike Treseler


All times are GMT. The time now is 05:53 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.