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.


    [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.
    alb, Mar 24, 2014
    1. Advertisements

  2. alb

    HT-Lab Guest

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

    set StdArithNoWarnings 1
    run 0 ns;
    set StdArithNoWarnings 0


    AFAIK assigning default
    HT-Lab, Mar 24, 2014
    1. Advertisements

  3. alb

    alb Guest

    Hi Hans,

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

    any idea instead about the above mentioned unexpected behavior?

    alb, Mar 24, 2014
  4. alb

    HT-Lab Guest

    Hi Al,

    Looks like std_logic_arith is being references in package

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

    package STD_LOGIC_UNSIGNED is

    HT-Lab, Mar 24, 2014
  5. alb

    alb Guest

    Hi Allan,
    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.
    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 ;-)

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

    alb, Mar 25, 2014
  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, Mar 25, 2014
  7. alb

    alb Guest

    Hi Andy,

    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... :-/
    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.

    alb, Mar 26, 2014
  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, Mar 27, 2014
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.