cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
257 Views
Registered: ‎11-14-2019

0 definitions of '=' for enumeration declared in package

Jump to solution

I've come across strange error '0 definitions of operator "=" match here' during the RTL analysis of my code. I am using Vivado 2019.2 and this error may be reproduced with such code:

package foo_pkg is
	type foo_t is (first, second, third, fourth); -- type definition
end foo_pkg;

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

use work.foo_pkg; -- make foo_pkg visible

entity foo_ent is
end foo_ent;

architecture Behavioral of foo_ent is
	signal foo : foo_pkg.foo_t; -- signal definition of type foo_t works ok
	signal bar : std_logic;
begin
	process (foo)
	begin
		if foo = foo_pkg.first then -- this is the line where the error message appears
			bar <= '1';
		else
			bar <= '0';
		end if;
	end process;
end Behavioral;

I use work.foo_pkg without .all intentionally because in my actual project making all items visible may lead to name duplications so I prefer to work witout it and refer to all items from foo_pkg explicitly like in signal foo : foo_pkg.foo_t.

And it works in all places except for the '=' operator. I use Vivado 2019.2. Is there an error in my code? I am really confused because I've checked it in good old XISE 14.7 and works there. Additionally, if I replace the if statement with case statement such as:

process (foo)
begin
	case foo is
		when foo_pkg.first => bar <= '1';
		when others => bar <= '0';
	end case;
end process;

then everything works OK so there is a work-around but I am just curious what is going on.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
240 Views
Registered: ‎08-01-2012

Re: 0 definitions of '=' for enumeration declared in package

Jump to solution

This is because you didnt include the "=" function.

In VHDL, "=" is implicitly declared for all types, and they exist in the package that the type is declared in. Becase you didnt include .all , then there is no visibility of the "=" function for your type.

You will either need to include it, either with .all or explicitly:

use work.foo_pkg."=";

or explicitly reference it when you call it:

if foo foo_pkg."=" foo_pkg.first then

Is there any reason you're not using .all?

View solution in original post

6 Replies
Highlighted
Scholar
Scholar
241 Views
Registered: ‎08-01-2012

Re: 0 definitions of '=' for enumeration declared in package

Jump to solution

This is because you didnt include the "=" function.

In VHDL, "=" is implicitly declared for all types, and they exist in the package that the type is declared in. Becase you didnt include .all , then there is no visibility of the "=" function for your type.

You will either need to include it, either with .all or explicitly:

use work.foo_pkg."=";

or explicitly reference it when you call it:

if foo foo_pkg."=" foo_pkg.first then

Is there any reason you're not using .all?

View solution in original post

Highlighted
234 Views
Registered: ‎11-14-2019

Re: 0 definitions of '=' for enumeration declared in package

Jump to solution
Thank you for the explanation. That makes sense now.
Yes, there is a reason for not using .all in my project because of the fact, that I use several packages in it. The project was not managed very well and for example some type names are duplicated in those packages. To avoid ambiguity or errors I decided not to use .all.
0 Kudos
Highlighted
Scholar
Scholar
232 Views
Registered: ‎08-01-2012

Re: 0 definitions of '=' for enumeration declared in package

Jump to solution

If you have type name clash, you can always be explicit with type names when declaring objects. It should then understand what function signatures to use from the context. Using (non-standard) std_logic_arith and numeric_std is the classic example:

-- both define unsigned/signed types
use ieee.std_logic_arith.all;
use ieee.numeric_std.all;

-- error, because types are hidden:
signal a : unsigned(7 downto 0);

-- be explicit and it works.
signal a : ieee.numeric_std.unsigned(7 downto 0);
signal b : ieee.numeric_std.unsigned(7 downto 0);

-- should work because it now knows what the types are:
op <= a + b;
0 Kudos
Highlighted
185 Views
Registered: ‎11-14-2019

Re: 0 definitions of '=' for enumeration declared in package

Jump to solution

Thank you for your reply, it was the most helpful. I think I was more afraid of the name clash of enumeration value names. For example if I had two packages:

 

package foo_pkg is
	type foo_t is (first, second, third, fourth); -- type definition
end foo_pkg;

package bar_pkg is
	type bar_t is (second, third, last);
end bar_pkg;
use work.foo_pkg.all;
use work.bar_pkg.all;
...
signal bar : bar_t;
...
bar <= second;

I was unsure what will happen if I had both packages used with .all and if I wanted to use signals of types foo_t and bar_t. I was unable to find a source which explains such situation but now I made some test with simple code and I think everything works ok and for example assigning "second" to signal of type foo_t is not influenced by the existence of "second" value in bar_t. Am I right?

 

0 Kudos
Highlighted
Scholar
Scholar
180 Views
Registered: ‎08-01-2012

Re: 0 definitions of '=' for enumeration declared in package

Jump to solution

VHDL works based on context. It will always take the only available option.If there is more than one option, you get a compile error forcing you to be explicit.

so in your case, foo_t and bar_t are completly different types.And "=" functions are implicitly declared for both:

function "=" (l, r : foo_t) return boolean;
function "=" (l, r : bar_t) return boolean;

so when it sees this:

if foo_sig = second then

There is only one possible option, and second must be from the foo_t type. If you think about it, you do this all the time:

if std_logic_sig = '1' then

'1' can be any of the types bit, std_logic or character. but because no "=" functions exist to compare between types, then it knows what you mean.

However, if you were to explicitly decalre this:

function "=" (l : foo_t; r : bar_t) return boolean;

Then the compiler would be confused, because it doesnt know which "=" function to use, or what type "second" is. you would either need to be explicity about which "=" function to use, or qualify what type "second" is with the ' qualification:

if foo_sig = foo_t'(second) then

you've probably done this in testbenches before, when you need to qualify a string in the write function:

write( my_line, string'("Hello World"));

You need to qualifty here, because there are several write functions that accept a string/binary string, namly for bit_vector and string, (and in VHDL 2008, std_logic_vector, signed and unsigned too)

Highlighted
127 Views
Registered: ‎11-14-2019

Re: 0 definitions of '=' for enumeration declared in package

Jump to solution
Thank you. That clarifies my doubts.
0 Kudos