Reputation: 330
I am getting this error in my VHDL code : found '0' definitions of operator "=", cannot determine exact overloaded matching definition for "="
Here is my code:
library IEEE;
Use IEEE.STD_LOGIC_1164.ALL;
entity simpleMux is
Port ( i0 : in STD_LOGIC;
i1 : in STD_LOGIC;
i2 : in STD_LOGIC;
i3 : in STD_LOGIC;
s : in STD_LOGIC_VECTOR(1 downto 0);
o : out STD_LOGIC);
end simpleMux;
architecture Behavioral of simpleMux is
begin
o <= i0 when (s = "00") else
i1 when (s = "01") else
i2 when (s = "02") else
i3 when (s = "03");
end Behavioral;
Where exactly is the problem?
Upvotes: 0
Views: 5659
Reputation:
This was intended to add an alternative to anderswb's answer and demonstrate that you can do comparison between an array type representing a binary value and a numerical literal representing a value expression in that array type.
It also offers the opportunity to point out something about evaluating expressions in a type with an element base type that has more values than '9' and '1'.
It's possible to modify your design and compare numerical values to s
:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity simplemux is
port (
i0: in std_logic;
i1: in std_logic;
i2: in std_logic;
i3: in std_logic;
s: in std_logic_vector(1 downto 0);
o: out std_logic
);
end entity simplemux;
architecture foo of simplemux is
begin
o <= i0 when unsigned(s) = 0 else
i1 when unsigned(s) = 1 else
i2 when unsigned(s) = 2 else
i3 when unsigned(s) = 3 else
'X';
end architecture;
This relies on type conversion of s
to type unsigned. You could also supply s
as an unsigned in the port declaration avoiding the type conversions, and do type conversion in the association list instead (the port map where simplemux is instantiated).
In package numeric_std there is an "=" function defined for overload of the equality operator with a signature of [unsigned, natural return boolean].
This allows comparison between numeric values appropriate for an unsigned number to be compared to an unsigned.
This will analyze, elaborate and simulate. Notice I threw an extra else on the end to deal with metavalues. Why can be demonstrated with a simple test bench that doesn't initialize the value of any input to simplemux:
library ieee;
use ieee.std_logic_1164.all;
entity tb_simplemux is
end entity;
architecture fum of tb_simplemux is
signal i0, i1, i2, i3: std_logic; -- default value = 'U'
signal s: std_logic_vector (1 downto 0); -- default "UU"
signal o: std_logic;
begin
DUT:
entity work.simplemux
port map (
i0 => i0,
i1 => i1,
i2 => i2,
i3 => i3,
s => s,
o => o
);
MONITOR:
process
begin
wait on o;
report "o = " & std_logic'image(o);
end process;
STIMULUS:
process
begin
wait;
end process;
end architecture;
If we analyze and elaborate then run the testbench:
ghdl -r tb_simplemux
../../../src/ieee/numeric_std-body.v93:1710:7:@0ms:(assertion warning): NUMERIC_STD."=": metavalue detected, returning FALSE
../../../src/ieee/numeric_std-body.v93:1710:7:@0ms:(assertion warning): NUMERIC_STD."=": metavalue detected, returning FALSE
../../../src/ieee/numeric_std-body.v93:1710:7:@0ms:(assertion warning): NUMERIC_STD."=": metavalue detected, returning FALSE
../../../src/ieee/numeric_std-body.v93:1710:7:@0ms:(assertion warning): NUMERIC_STD."=": metavalue detected, returning FALSE
simplemux.vhdl:50:9:@0ms:(report note): o = 'X'
The wait on o;
in the MONITOR process eliminates the default value of o (which would be 'U') from showing up. Comment it out and adding a sensitivity list with s
and you'd see:
...
simplemux.vhdl:49:9:@0ms:(report note): o = 'U'
simplemux.vhdl:49:9:@0ms:(report note): o = 'X'
The default value for o
shows up as well.
With a metavalue on s
your simplemux wouldn't actually assign any value to o
during simulation but would synthesize just fine (where only binary representing values are considered).
The 'X' is informative that there's a metavalue on s
for simulation purposes.
We could in the STIMULUS process in the testbench assign distinct values to i0
, i1
, i2
and i3
(say '9', '1', 'L' and 'H', the latter two map to binary values in synthesis), then march through the binary values of the vector s
with delay between assignments and demonstrate simplemux is functional. You could also set one input value different from the others and strobe through the binary values of s
to show the correct input is selected, doing this for every input.
The whole point of this is that std_ulogic, the base type of std_logic, and the base type of the element type of std_logic_vector or unsigned is a multilevel value logic signal, providing more than just binary information for simulation purposes and we can use the additional information in troubleshooting.
We can write simulation models that tell us information about what the model is doing (like the assertion warnings from the "=") while still synthesizing correctly.
Upvotes: 2
Reputation: 492
The signal s is of the type std_logic_vector, which is just an array of the type std_logic. Remember that std_logic can only assume the values of 0 and 1 (and a few others such a undefined). So you can only have values in a std_logic_vector such as "00", "10" etc. You are comparing to the values "02" and "03", which are not valid.
Instead your expression should have been:
o <= i0 when (s = "00") else
i1 when (s = "01") else
i2 when (s = "10") else
i3 when (s = "11");
Upvotes: 2