= to behave like std_match? (don't care)

[aleksa]

To achieve correct behavioral simulation, I have to use std_match when
comparing '-' bits.

Is it possible to make = operator behave like std_match?

 

[KJ]

To achieve correct behavioral simulation, I have to use std_match when
comparing '-' bits.

Is it possible to make = operator behave like std_match?

You can override the default operators with a function, in this case
'='.

So you could create a function like this...

function "=" (L, R: std_logic_vector) return Boolean is
begin
return(std_match(L, R));
end function "=";

While I've overridden operators to create new interface functionality,
I haven't tried overriding to create something that has the same
interface but different function as would be the case here. I suspect
that you will run into an issue doing this because there would be
nothing for the compiler to choose between the two implementations of
'='. In other words, when it runs across

if (a = b) then -- a, b are both std_logic_vector

How does the compiler know whether it should choose the '=' function
that is part of the standard packages or the new '=' that you define?
The answer is that it can't since both forms of '=' take the same
parameter types and return the same type. In that situation, the
compiler usually complains that there are multiple functions that can
be used here so the usage is ambiguous.

The workaround to that is to explicitly call your '=' function...but
that uglies up the code even more. Best to just not bother changing
the behavior of existing functions, tis better to create something new
that isn't ambiguous.

Kevin Jennings

 

[aleksa]

You can override the default operators with a function, in this case
'='.

So you could create a function like this...

function "=" (L, R: std_logic_vector) return Boolean is
begin
  return(std_match(L, R));
end function "=";

While I've overridden operators to create new interface functionality,
I haven't tried overriding to create something that has the same
interface but different function as would be the case here.  I suspect
that you will run into an issue doing this because there would be
nothing for the compiler to choose between the two implementations of
'='.  In other words, when it runs across

if (a = b) then -- a, b are both std_logic_vector

How does the compiler know whether it should choose the '=' function
that is part of the standard packages or the new '=' that you define?
The answer is that it can't since both forms of '=' take the same
parameter types and return the same type.  In that situation, the
compiler usually complains that there are multiple functions that can
be used here so the usage is ambiguous.

The workaround to that is to explicitly call your '=' function...but
that uglies up the code even more.  Best to just not bother changing
the behavior of existing functions, tis better to create something new
that isn't ambiguous.

Kevin Jennings

Thank you very much for the response!
Perhaps is better not to change '=', but to create '=='.

'==' is not used in VHDL, right?

I'm very far from a expert in VHDL, but I'll give it a try (after
lunch

 

[aleksa]

Thank you very much for the response!
Perhaps is better not to change '=', but to create '=='.

'==' is not used in VHDL, right?

I'm very far from a expert in VHDL, but I'll give it a try (after
lunch

Wait a sec...
I still won't be able to write a==b, but ==(a,b) ?

 

[Tricky]

You can override the default operators with a function, in this case
'='.

So you could create a function like this...

function "=" (L, R: std_logic_vector) return Boolean is
begin
  return(std_match(L, R));
end function "=";

While I've overridden operators to create new interface functionality,
I haven't tried overriding to create something that has the same
interface but different function as would be the case here.  I suspect
that you will run into an issue doing this because there would be
nothing for the compiler to choose between the two implementations of
'='.  In other words, when it runs across

if (a = b) then -- a, b are both std_logic_vector

How does the compiler know whether it should choose the '=' function
that is part of the standard packages or the new '=' that you define?
The answer is that it can't since both forms of '=' take the same
parameter types and return the same type.  In that situation, the
compiler usually complains that there are multiple functions that can
be used here so the usage is ambiguous.

The workaround to that is to explicitly call your '=' function...but
that uglies up the code even more.  Best to just not bother changing
the behavior of existing functions, tis better to create something new
that isn't ambiguous.

Kevin Jennings

It depends on scope. If you define the "=" function locally, this then
overloads the package definition one. So you would have to specify
every time you want the normal "=".
But if they are both in packages, then you have to specify.

 

[Tricky]

Wait a sec...
I still won't be able to write a==b, but ==(a,b) ?

a == b is fine - thats how all the = functions (not to mention all
the +s, -s, * etc) is defined. VHDL allows you to define operator
functions with l (left) and r (right) parameters. The function name
needs to be enclosed in double quotes:

function "==" (l, r : std_logic_vector) return boolean is
begin
return (std_match(l, r) );
end function;

 

[aleksa]

a == b  is fine - thats how all the = functions (not to mention all
the +s, -s, * etc) is defined. VHDL allows you to define operator
functions with l (left) and r (right) parameters. The function name
needs to be enclosed in double quotes:

function "==" (l, r : std_logic_vector) return boolean is
begin
  return (std_match(l, r) );
end function;

I need more help with this...

First of all, I couldn't make it with "==", so I've created "equ"
instead.

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

package common is

function equ (l, r : std_logic_vector) return boolean;

end common;

package body common is

function equ (l, r : std_logic_vector) return boolean is
begin
return (std_match(l, r) );
end function;

end common;


-- this works
wea <= '1' when (a='1' and b=c) else '0';

-- this also works
wea <= '1' when (a='1' and equ (b,c)) else '0';

-- this fails
wea <= '1' when (a='1' and b equ c) else '0';

...and can not have such operands in this context.
...parse error, unexpected IDENTIFIER, expecting COMMA or CLOSEPAR

-- this also fails
wea <= '1' when (a='1' and (b equ c)) else '0';

...parse error, unexpected IDENTIFIER, expecting COMMA or CLOSEPAR

 

[Enrik Berkhan]

Thank you very much for the response!
Perhaps is better not to change '=', but to create '=='.

'==' is not used in VHDL, right?

I'm very far from a expert in VHDL, but I'll give it a try (after
lunch

You can't create operators in VHDL, just overload existing ones.
'==' is not a VHDL operator symbol.

Enrik

 

[Rob Gaddi]

[snip]
I need more help with this...

First of all, I couldn't make it with "==", so I've created "equ"
instead.

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

package common is

function equ (l, r : std_logic_vector) return boolean;

end common;

package body common is

function equ (l, r : std_logic_vector) return boolean is
begin
return (std_match(l, r) );
end function;

end common;


-- this works
wea <= '1' when (a='1' and b=c) else '0';

-- this also works
wea <= '1' when (a='1' and equ (b,c)) else '0';

-- this fails
wea <= '1' when (a='1' and b equ c) else '0';

..and can not have such operands in this context.
..parse error, unexpected IDENTIFIER, expecting COMMA or CLOSEPAR

-- this also fails
wea <= '1' when (a='1' and (b equ c)) else '0';

..parse error, unexpected IDENTIFIER, expecting COMMA or CLOSEPAR

I'm not actually sure that VHDL lets you define new operators, only
overload existing ones.

It seems like you're really just trying to save typing out std_match
every time. Any decent editor has plenty of ways to autocomplete
and/or templatize such things. Is this really worth the effort you're
expending?

 

[Paul Uiterlinden]

How does the compiler know whether it should choose the '=' function
that is part of the standard packages or the new '=' that you define?
The answer is that it can't since both forms of '=' take the same
parameter types and return the same type. In that situation, the
compiler usually complains that there are multiple functions that can
be used here so the usage is ambiguous.

And that is exactly why the ModelSim has the -explicit compile option and
the "Explicit = 1" setting in modelsim.ini. If that is in effect, it will
use the explicitly defined operator for that type (in contrast to the
implicit operator that came with the type definition itself), even if the
operator is defined in another package than the type. If I recall
correctly, this violates the LRM. It only allows to (re-)define an operator
for a type in the same package where the type is defined.

(So that's yet another reason why not to use the ieee.std_logic_(un)signed
packages: they redefine operators for std_logic_vector are defined in
ieee.std_logic_1164 and by doing so violate the LRM.)

If you want to define operators that honors '-' as don't care, the best way
is to create your own type and define operators for that to your heart's
content. Exactly how it is done for e.g. signed and unsigned in
ieee.numeric_std.

TYPE slv_dc IS ARRAY(natural RANGE <>) of std_logic;
FUNCTION "=" (L, R: slv_dc) RETURN boolean;
etc....

Of course, just as with (un)signed and std_logic_vector, you can't assign
one to the other, because they are types. You'll need conversion like
std_logic_vector(my_slv_dc) and slv_dc(my_slv), where the type of my_slv_dc
is slv_dc and the type of my_slv is std_logic_vector.

On the other hand: why bother and just use the std_match function from
numeric_std, or your own defined function. OK, you'll lose the coolness of
the operator style of writing and can't write "IF a=b THEN ... END IF;".

 

[JimLewis]

You could turn on the VHDL-2008 switch and use the
new ?= operator.

?= returns a std_ulogic value and simplifies the logic
you showed above to:
wea <= a and b ?= c;

If you intend to use this for RTL, make sure your synthesis
tools also support it. Given you intended application, I
might be inclined to have it return std_ulogic also.

Best,
Jim