type conversion and concatenation

[Ralf Hildebrandt]

Hi VHDL-guys!


I've noticed some special behavior. I use:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL,IEEE.Numeric_STD.ALL;


Three signals are defined as follows:

signal c : std_ulogic;
signal d : signed(2 downto 0);
signal dummy : std_ulogic_vector(2 downto 0);


The following concatenation and type conversion works fine:

dummy<="00" & c;
d<=signed(dummy);



But this way fails:

d<=signed("00" & c);
^
"operand of type conversion is ambiguous"


What is the difference, that makes the conversion function fail with the
2nd code fragment?
If the concatenation "00" & c does not procude a std_(U)logic_vector,
why I can assignd it to signal dummy?


Ralf

 

[MK]

The reason is that type conversion operand must be determinable
independent of the context (lhs of an assignment and type_mark). Ambiguous
is because operand can be std_ulogic_vector or signed, so the are 2 possible
"&" operators. When type conversion is missing, type for "&" operator is
given directly from lhs (type of dummy signal).

Try use qualified_expression:

d <= signed'("00" & c);

should works.

regards,
MK.

"Ralf Hildebrandt" <Ralf-Hildebrandt@gmx.de> wrote in message
news:bfmlrn$gji8i$1@ID-8609.news.uni-berlin.de...

Hi VHDL-guys!


I've noticed some special behavior. I use:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL,IEEE.Numeric_STD.ALL;


Three signals are defined as follows:

signal c : std_ulogic;
signal d : signed(2 downto 0);
signal dummy : std_ulogic_vector(2 downto 0);


The following concatenation and type conversion works fine:

dummy<="00" & c;
d<=signed(dummy);



But this way fails:

d<=signed("00" & c);
^
"operand of type conversion is ambiguous"


What is the difference, that makes the conversion function fail with the
2nd code fragment?
If the concatenation "00" & c does not procude a std_(U)logic_vector,
why I can assignd it to signal dummy?


Ralf

 

[Ralf Hildebrandt]

Hi MK!

The reason is that type conversion operand must be determinable
independent of the context (lhs of an assignment and type_mark). Ambiguous
is because operand can be std_ulogic_vector or signed, so the are 2 possible
"&" operators. When type conversion is missing, type for "&" operator is
given directly from lhs (type of dummy signal).

Try use qualified_expression:

d <= signed'("00" & c);

should works.

Ok, I got it. There are (at least) two functions for &-concatenation.
They do the same, but each function accepts one type as input.

But with this knowledge I wrote this minimal example.

-------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL,IEEE.Numeric_STD.ALL;

entity test is
end test;

architecture behavior of test is
signal a : std_ulogic;
signal b : signed(2 downto 0);
signal c : std_ulogic_vector(2 downto 0);
signal e,f,g : unsigned(2 downto 0);
begin


e<=unsigned("00" & a) + 1; -- ERROR: operand of type conversion is
-- ambiguous
f<=unsigned'("00" & a) + 1; -- good
g<=("00" & a) + 1; -- good

-- -> ("00" & a) is already of tye unsigned (Why?)

-- o.k., let's try the other possibilities:
b<=("00" & a) - 1; -- good
c<=("00" & a); -- good

end behavior;
-------------

The error with signal e can be explained as you did.

-> &-Concatenation already procudes a vector of the _needed_ type. (In
the case of signal g beeing target: unsigned.)

So my question ist: How can the &-Operator decide, which destination
type is needed?

Is the &-concatenation a function or something different?

Ralf

 

[MK]

Hi,

The only difference with expression with type conversion and without is
"context type". Operand of type conversion is self-determined, so
destination type is not known. When we have expression without type
conversion you have always destination type (from lhs in assignments, or
from formal in association lists).

Let's see your statement with question "why":

g<=("00" & a) + 1; -- good -- -> ("00" & a) is already of tye unsigned
(Why?)

g is of UNSIGNED type, so compiler looking for operators "+", which return
UNSIGNED type - found one:
function "+" (L: UNSIGNED; R: NATURAL) return UNSIGNED;

left operand of this operator is of UNSIGNED type (right of NATURAL), so
expression ("00" & a) is of type UNSIGNED - that's all!

if second operator "+" returning UNSIGNED type exists - for example:
function "+" (L: SIGNED; R: NATURAL) return UNSIGNED;

ambiguous should be detected.

nice day,
MK.


"Ralf Hildebrandt" <Ralf-Hildebrandt@gmx.de> wrote in message
news:bfr9th$i1so0$2@ID-8609.news.uni-berlin.de...

Hi MK!


The reason is that type conversion operand must be determinable
independent of the context (lhs of an assignment and type_mark).
Ambiguous
is because operand can be std_ulogic_vector or signed, so the are 2
possible
"&" operators. When type conversion is missing, type for "&" operator is
given directly from lhs (type of dummy signal).

Try use qualified_expression:

d <= signed'("00" & c);

should works.


Ok, I got it. There are (at least) two functions for &-concatenation.
They do the same, but each function accepts one type as input.

But with this knowledge I wrote this minimal example.

-------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL,IEEE.Numeric_STD.ALL;

entity test is
end test;

architecture behavior of test is
signal a : std_ulogic;
signal b : signed(2 downto 0);
signal c : std_ulogic_vector(2 downto 0);
signal e,f,g : unsigned(2 downto 0);
begin


e<=unsigned("00" & a) + 1; -- ERROR: operand of type conversion is
-- ambiguous
f<=unsigned'("00" & a) + 1; -- good
g<=("00" & a) + 1; -- good

-- -> ("00" & a) is already of tye unsigned (Why?)

-- o.k., let's try the other possibilities:
b<=("00" & a) - 1; -- good
c<=("00" & a); -- good

end behavior;
-------------

The error with signal e can be explained as you did.

-> &-Concatenation already procudes a vector of the _needed_ type. (In
the case of signal g beeing target: unsigned.)

So my question ist: How can the &-Operator decide, which destination
type is needed?

Is the &-concatenation a function or something different?

Ralf