Warning: NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0

Discussion in 'VHDL' started by alb, Mar 24, 2014.

  1. alb

    alb Guest

    Hi everyone,

    it seems the above warning is filed when some of my signals/variables
    are not initialized and therefore some metavalue is either propagated
    or, as in this case, forced to some value.

    These warnings happens only at time 0 and do not bother me too much in
    general, but I hate discarding these long list of warnings everytime I
    run a sim. Any option to force vsim to *not* report warnings is not
    acceptable since I want to be able to see other potential problems.

    Any idea on how to get rid of those? AFAIK assigning default
    signal/variable values at declaration is not good habit since it may
    lead to a mismatch between pre-synth and post-synth behavior.

    BTW I also receive the same type of warning but filed from
    std_logic_arith: Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
    arithmetic operand, the result will be 'X'(es)

    the funny thing is that I'm not using std_logic_arith in my design (I do
    have std_logic_unsigned though[1])! Does this make any sense?

    Any comment is appreciated.

    Al

    [1] and yes, I know I shouldn't be using std_logic_unsigned since is not
    standard but the code is verified and I do not want to break something
    that has been delivered to us only because of the library.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    alb, Mar 24, 2014
    #1
    1. Advertising

  2. alb

    HT-Lab Guest

    Re: Warning: NUMERIC_STD.TO_INTEGER: metavalue detected, returning0

    On 24/03/2014 12:55, alb wrote:
    > Hi everyone,
    >
    > it seems the above warning is filed when some of my signals/variables
    > are not initialized and therefore some metavalue is either propagated
    > or, as in this case, forced to some value.
    >
    > These warnings happens only at time 0 and do not bother me too much in
    > general, but I hate discarding these long list of warnings everytime I
    > run a sim. Any option to force vsim to *not* report warnings is not
    > acceptable since I want to be able to see other potential problems.
    >
    > Any idea on how to get rid of those?


    This is what I use in the beginning of my .do files,

    set StdArithNoWarnings 1
    run 0 ns;
    set StdArithNoWarnings 0


    Regards,
    Hans.
    www.ht-lab.com



    AFAIK assigning default
    > signal/variable values at declaration is not good habit since it may
    > lead to a mismatch between pre-synth and post-synth behavior.
    >
    > BTW I also receive the same type of warning but filed from
    > std_logic_arith: Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
    > arithmetic operand, the result will be 'X'(es)
    >
    > the funny thing is that I'm not using std_logic_arith in my design (I do
    > have std_logic_unsigned though[1])! Does this make any sense?
    >
    > Any comment is appreciated.
    >
    > Al
    >
    > [1] and yes, I know I shouldn't be using std_logic_unsigned since is not
    > standard but the code is verified and I do not want to break something
    > that has been delivered to us only because of the library.
    >
     
    HT-Lab, Mar 24, 2014
    #2
    1. Advertising

  3. alb

    alb Guest

    Hi Hans,

    HT-Lab <> wrote:
    []
    >> These warnings happens only at time 0 and do not bother me too much in
    >> general, but I hate discarding these long list of warnings everytime I
    >> run a sim. Any option to force vsim to *not* report warnings is not
    >> acceptable since I want to be able to see other potential problems.
    >>
    >> Any idea on how to get rid of those?

    >
    > This is what I use in the beginning of my .do files,
    >
    > set StdArithNoWarnings 1
    > run 0 ns;
    > set StdArithNoWarnings 0
    >


    Thanks a lot! This works indeed and I suppose I can do the very same
    trick for the numeric_std package (NumericStdNoWarnings 1/0).

    []
    >> BTW I also receive the same type of warning but filed from
    >> std_logic_arith: Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
    >> arithmetic operand, the result will be 'X'(es)
    >>
    >> the funny thing is that I'm not using std_logic_arith in my design (I do
    >> have std_logic_unsigned though[1])! Does this make any sense?


    any idea instead about the above mentioned unexpected behavior?

    Al
     
    alb, Mar 24, 2014
    #3
  4. alb

    HT-Lab Guest

    Re: Warning: NUMERIC_STD.TO_INTEGER: metavalue detected, returning0

    On 24/03/2014 14:35, alb wrote:
    > Hi Hans,

    ...
    >
    > []
    >>> BTW I also receive the same type of warning but filed from
    >>> std_logic_arith: Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an
    >>> arithmetic operand, the result will be 'X'(es)
    >>>
    >>> the funny thing is that I'm not using std_logic_arith in my design (I do
    >>> have std_logic_unsigned though[1])! Does this make any sense?

    >
    > any idea instead about the above mentioned unexpected behavior?


    Hi Al,

    Looks like std_logic_arith is being references in package
    std_logic_unsigned,

    library IEEE;
    use IEEE.std_logic_1164.all;
    use IEEE.std_logic_arith.all;

    package STD_LOGIC_UNSIGNED is
    .....
    end STD_LOGIC_UNSIGNED;

    Regards,
    Hans
    www.ht-lab.com


    >
    > Al
    >
     
    HT-Lab, Mar 24, 2014
    #4
  5. alb

    alb Guest

    Hi Allan,
    Allan Herriman <> wrote:
    >> it seems the above warning is filed when some of my signals/variables
    >> are not initialized and therefore some metavalue is either propagated
    >> or, as in this case, forced to some value.

    [...]
    >
    > Consider the following:
    >
    > signal sig1 : std_logic := '1';
    > signal sig2 : std_logic;
    >
    > ...
    >
    > statement1 : sig2 <= sig1;
    >
    >
    > Note that a signal declaration without an initialiser is equivalent to a
    > declaration with an initialiser of the leftmost value of the type, in
    > this case 'U'.
    >
    > At the start of simulation, sig1 has the value '1', and sig2 has the
    > value 'U'.
    > The implicit process associated with the assignment in statement1 then
    > runs, and 1 delta cycle later, (the driver of) sig2 gets the value '1'.
    >
    > So, sig2 starts with the value 'U', then 1 delta later (but still at time
    > 0 ns) it gets the value '1'.
    >
    > If you had a process which had sig2 in its sensitivity list, it would run
    > once at the start of simultion, when sig2 was 'U', then once more when
    > sig2 has the value '1'.


    Thanks for the explanation, it helped clarifying some doubts I had on the
    beginning of the whole simulation process.

    IMHO though, initialization might be rather dangerous since you may rely
    on the initial values for proper operation. Eventually the hardware will
    have its own initial values (AFAIK synthesis does ignore initial values)
    and your logic go completely nuts because of wrong intial assumptions.

    I do prefer to verify that my 'U' are correctly assigned by some
    controlled flow before the signal is used.

    > My guess is that in your code you have something like this:
    >
    > signal u1 : unsigned(1 downto 0); -- no initialiser
    >
    > signal u2 : unsigned(1 downto 0) := (others => '0');
    >
    > signal u3 : unsigned(1 downto 0);
    >
    > ...
    >
    > statement2 : u1 <= u2;
    >
    > statement3 : u3 <= u1 + 1;
    >
    > Initial: u1 is "UU', u2 is "00", u2 is "UU"


    I have indeed several initialized declarations as well as uninitialized
    ones, I did not bother to check the sequence of calling though. In the
    end the OP was about making the initial warnings 'silent' because they
    are /expected/. I should have added that my design does work as is and
    I'm not going to break it because of this reason ;-)

    []
    >
    > Now consider what would happen if you'd given u1 an initialiser.
    >
    > You should be able to join the dots from there.


    Are you inferring that I should initialize every signal/variable
    during declaration? I guess I have missed your point.

    Al
     
    alb, Mar 25, 2014
    #5
  6. alb

    Andy Guest

    The warning indicates that you are attempting to interpret the numerical representation of a variable/signal when such interpretation is not valid.

    I usually try to avoid the warning by managing when the function is called. I try to call it from a clocked process (after reset), perhaps when a flag or state machine indicates the data (e.g. from an external interface) should be valid.

    Calling the function in an concurrent assignment is just begging for the warning.

    This isn't always practical, but drastically reduces the number of occurrences.

    Andy
     
    Andy, Mar 25, 2014
    #6
  7. alb

    alb Guest

    Hi Andy,

    Andy <> wrote:
    []
    > I usually try to avoid the warning by managing when the function is
    > called. I try to call it from a clocked process (after reset), perhaps
    > when a flag or state machine indicates the data (e.g. from an external
    > interface) should be valid.


    There are still cases where is not really possible to avoid metavalues
    until the wires are driven (I can thing of a non pipelined ALU). In
    these cases the data path will propagate its metavalues as needed.

    If these wires are driven internally through registers they will have a
    metavalues at time 0 since their process will trigger first when the
    reset signal is still 'U', am I wrong? I should do a simple test to
    verify my statement... :-/

    > Calling the function in an concurrent assignment is just begging for
    > the warning.


    As usually happens, you inherit this type of code at a stage where
    changing these aspects will simply be a too big effort to be worth it.
    Hans's solution for the time being provides a sufficiently good patch to
    this issue.

    Al
     
    alb, Mar 26, 2014
    #7
  8. alb

    Andy Guest

    Unfortunately I know all too well of the problems associated with inheritedcode. This is but the tip of the iceberg.

    When called from a clocked process, to_integer() will only execute when either reset is active or a rising edge is detected on the clock. The former is unlikely since a reset assignment using a conversion of another (unknown valued) signal is probably a design/code bug that would not synthesize anyway.

    If your simulation starts the clock with the reset inactive or undefined, well, you'll still get the warnings... I would script the simulation to disable warnings until reset is first active. I usually initialize the reset signal to active in the testbench, to make sure it is active before edges occur on the clock.

    Andy
     
    Andy, Mar 27, 2014
    #8
    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. Mike Treseler

    Re: Quartus warning in NUMERIC_STD.vhd

    Mike Treseler, Jul 11, 2003, in forum: VHDL
    Replies:
    2
    Views:
    1,852
    Clyde R. Shappee
    Jul 13, 2003
  2. Panic
    Replies:
    6
    Views:
    1,009
    Panic
    Sep 28, 2003
  3. A. Kong
    Replies:
    3
    Views:
    17,589
    Alan Fitch
    Oct 11, 2004
  4. G Iveco
    Replies:
    2
    Views:
    5,205
    David Bishop
    Sep 16, 2007
  5. Olaf
    Replies:
    1
    Views:
    4,717
    Tricky
    Dec 5, 2008
Loading...

Share This Page