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

Discussion in 'VHDL' started by aleksa, Feb 16, 2012.

  1. aleksa

    aleksa Guest

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

    Is it possible to make = operator behave like std_match?
    aleksa, Feb 16, 2012
    #1
    1. Advertising

  2. aleksa

    KJ Guest

    On Feb 16, 4:38 am, aleksa <> 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
    KJ, Feb 16, 2012
    #2
    1. Advertising

  3. aleksa

    aleksa Guest

    On Feb 16, 1:38 pm, KJ <> wrote:
    > On Feb 16, 4:38 am, aleksa <> 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 :)
    aleksa, Feb 16, 2012
    #3
  4. aleksa

    aleksa Guest

    On Feb 16, 4:05 pm, aleksa <> wrote:
    > On Feb 16, 1:38 pm, KJ <> wrote:
    >
    >
    >
    >
    >
    > > On Feb 16, 4:38 am, aleksa <> 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) ?
    aleksa, Feb 16, 2012
    #4
  5. aleksa

    Tricky Guest

    On Feb 16, 12:38 pm, KJ <> wrote:
    > On Feb 16, 4:38 am, aleksa <> 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.
    Tricky, Feb 16, 2012
    #5
  6. aleksa

    Tricky Guest

    On Feb 16, 3:22 pm, aleksa <> wrote:
    > On Feb 16, 4:05 pm, aleksa <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Feb 16, 1:38 pm, KJ <> wrote:

    >
    > > > On Feb 16, 4:38 am, aleksa <> 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;
    Tricky, Feb 16, 2012
    #6
  7. aleksa

    aleksa Guest

    On Feb 16, 5:24 pm, Tricky <> wrote:
    > On Feb 16, 3:22 pm, aleksa <> wrote:
    >
    >
    >
    >
    >
    > > On Feb 16, 4:05 pm, aleksa <> wrote:

    >
    > > > On Feb 16, 1:38 pm, KJ <> wrote:

    >
    > > > > On Feb 16, 4:38 am, aleksa <> 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
    aleksa, Feb 16, 2012
    #7
  8. aleksa <> 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
    Enrik Berkhan, Feb 16, 2012
    #8
  9. aleksa

    Rob Gaddi Guest

    On Thu, 16 Feb 2012 11:11:26 -0800 (PST)
    aleksa <> 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.
    Rob Gaddi, Feb 16, 2012
    #9
  10. 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
    Paul Uiterlinden, Feb 21, 2012
    #10
  11. aleksa

    JimLewis Guest

    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
    JimLewis, Feb 29, 2012
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gregory Huffman

    How to include don't care minterms

    Gregory Huffman, Jan 26, 2004, in forum: VHDL
    Replies:
    3
    Views:
    7,395
    Gregory Huffman
    Jan 28, 2004
  2. bittor

    Don't care signals

    bittor, Feb 14, 2005, in forum: VHDL
    Replies:
    1
    Views:
    5,331
    Tim Hubberstey
    Feb 14, 2005
  3. Andrew Greensted

    Don't care and optimization

    Andrew Greensted, Jan 10, 2006, in forum: VHDL
    Replies:
    3
    Views:
    3,126
    Andrew Greensted
    Jan 11, 2006
  4. loris

    std_match function

    loris, Oct 15, 2008, in forum: VHDL
    Replies:
    0
    Views:
    3,321
    loris
    Oct 15, 2008
  5. Sriram Srinivasan
    Replies:
    13
    Views:
    538
    Benjamin Kaplan
    Nov 12, 2009
Loading...

Share This Page