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

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

Is it possible to make = operator behave like std_match?

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

On Feb 16, 4:38*am, aleksa <aleks...@gmail.com> wrote:
> 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

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

On Feb 16, 1:38*pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Feb 16, 4:38*am, aleksa <aleks...@gmail.com> wrote:
>
> > 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

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 :)

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

On Feb 16, 4:05*pm, aleksa <aleks...@gmail.com> wrote:
> On Feb 16, 1:38*pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
>
>
>
>
> > On Feb 16, 4:38*am, aleksa <aleks...@gmail.com> wrote:
>
> > > 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
>
> 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) ?

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

On Feb 16, 12:38*pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Feb 16, 4:38*am, aleksa <aleks...@gmail.com> wrote:
>
> > 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

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.

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

On Feb 16, 3:22*pm, aleksa <aleks...@gmail.com> wrote:
> On Feb 16, 4:05*pm, aleksa <aleks...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Feb 16, 1:38*pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > On Feb 16, 4:38*am, aleksa <aleks...@gmail.com> wrote:
>
> > > > 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
>
> > 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) ?

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;

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

On Feb 16, 5:24*pm, Tricky <trickyh...@gmail.com> wrote:
> On Feb 16, 3:22*pm, aleksa <aleks...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 16, 4:05*pm, aleksa <aleks...@gmail.com> wrote:
>
> > > On Feb 16, 1:38*pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > > On Feb 16, 4:38*am, aleksa <aleks...@gmail.com> wrote:
>
> > > > > To achieve correct behavioral simulation, I have to use std_matchwhen
> > > > > 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
>
> > > 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) ?
>
> 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

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

aleksa <aleksazr@gmail.com> wrote:
> 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

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

On Thu, 16 Feb 2012 11:11:26 -0800 (PST)
aleksa <aleksazr@gmail.com> wrote:

> [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?

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

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

KJ wrote:

> 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;".

--
Paul Uiterlinden
www.aimvalley.nl