Warning: NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0

[alb]

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.

 

[HT-Lab]

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.

 

[alb]

Hi Hans,

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

 

[HT-Lab]

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

 

[alb]

Hi Allan,

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

 

[Andy]

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

 

[alb]

Hi Andy,

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

 

[Andy]

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