Warning interpretation ?

M

Marios Barlas

Guest
Hello,

I am getting a warning on my code like :
# ** Warning: NUMERIC_STD.">=": metavalue detected, returning FALSE
# Time: 0 ns Iteration: 0 Region: /sqroot_comb_tb/DUV/STAGES(3)
# ** Warning: NUMERIC_STD."<=": metavalue detected, returning FALSE

*********************************************
# ** Warning: NUMERIC_STD."<=": metavalue detected, returning FALSE
# Time: 0 ns Iteration: 4 Region: /sqroot_comb_tb/DUV/STAGES(3)

My code implements the calculation of an integer square root in 4 stages in dataflow. It doesn't seem to have a negative effect on the computation or on the synthesis phase. I am using Modelsim for coding/simulation and Synopsis for synthesis.

I suspect it comes from the fact that I introduce an array of vectors like this :
type r_size is array (0 to NBITS/2) of unsigned(NBITS-1 downto 0);
signal sqroot2 : r_size;
signal delta : r_size;
signal res : r_size;

and I initialize only the 1st element

res(0) <= unsigned(arg);

with my input vector.

In the algorithm however I have an assignment like :

res(i+1) <= res(i);

Can I circumvent the problem or should I just leave it like that?

Thanks in advance!
Marios Barlas
 
Hi Marios,
At startup all std_logic family has a 'U' by default. When the math functions, such as relationals (>=, <=, ...) see a 'U' (or string of them), they return FALSE.

As long as this is happening before your circuit becomes active, it is ok. If it is happening later in simulation, you need to research why it is getting a 'U'.

Cheers,
Jim
 
On 11/16/2014 10:51 AM, Marios Barlas wrote:
Hello,

I am getting a warning on my code like :
# ** Warning: NUMERIC_STD.">=": metavalue detected, returning FALSE
# Time: 0 ns Iteration: 0 Region: /sqroot_comb_tb/DUV/STAGES(3)
# ** Warning: NUMERIC_STD."<=": metavalue detected, returning FALSE

*********************************************
# ** Warning: NUMERIC_STD."<=": metavalue detected, returning FALSE
# Time: 0 ns Iteration: 4 Region: /sqroot_comb_tb/DUV/STAGES(3)

My code implements the calculation of an integer square root in 4 stages in dataflow. It doesn't seem to have a negative effect on the computation or on the synthesis phase. I am using Modelsim for coding/simulation and Synopsis for synthesis.

I suspect it comes from the fact that I introduce an array of vectors like this :
type r_size is array (0 to NBITS/2) of unsigned(NBITS-1 downto 0);
signal sqroot2 : r_size;
signal delta : r_size;
signal res : r_size;

and I initialize only the 1st element

res(0) <= unsigned(arg);

with my input vector.

In the algorithm however I have an assignment like :

res(i+1) <= res(i);

Can I circumvent the problem or should I just leave it like that?

This is like exploring the cold dusty areas of my mind. The problems
you are having are ones I had a long time ago and have learned to simply
step around. lol

If I remember correctly, this warning is because the comparison
operators >= and <= are seeing an input which is not all '1's and '0's
(and possibly 'H's and 'L's). While it is not likely of consequence at
time 0 you can easily code around it by making sure your signals and
variables are initialized.

Your assignment res(i+1) <= res(i); is fine assuming you start with an
initialized value. It is the comparisons that are biting you.

I recommend that you fix your code to get rid of warnings. Otherwise
you become inured to them and eventually they will cause you to miss a
valid warning that you need to pay attention to. Just initialize the
full array to something that isn't a letter... ;)

--

Rick
 
Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]
I recommend that you fix your code to get rid of warnings. Otherwise
you become inured to them and eventually they will cause you to miss a
valid warning that you need to pay attention to. Just initialize the
full array to something that isn't a letter... ;)

This is a sound suggestion, but I won't initialize those objects in the
vhdl code since is error prone (you may suddenly forget to reset an
added object and still get valid data).

I usually get around this with the following lines in my .do file:

set StdArithNoWarnings 1
set NumericStdNoWarnings 1
run 0 ns;
set StdArithNoWarnings 0
set NumericStdNoWarnings 0

run -all

HTH,

Al
 
On 11/28/2014 4:01 AM, alb wrote:
Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]
I recommend that you fix your code to get rid of warnings. Otherwise
you become inured to them and eventually they will cause you to miss a
valid warning that you need to pay attention to. Just initialize the
full array to something that isn't a letter... ;)

This is a sound suggestion, but I won't initialize those objects in the
vhdl code since is error prone (you may suddenly forget to reset an
added object and still get valid data).

I don't understand. If you forget to reset a signal, how will that
create a problem? The type of warning the OP is talking about happens
because the signal is *not* initialized and is a useful flag for that
condition. It is not assured to catch all uninitialized signals, but
how is intentionally not initializing them better?


I usually get around this with the following lines in my .do file:

set StdArithNoWarnings 1
set NumericStdNoWarnings 1
run 0 ns;
set StdArithNoWarnings 0
set NumericStdNoWarnings 0

run -all

HTH,

Al

--

Rick
 
Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]
This is a sound suggestion, but I won't initialize those objects in the
vhdl code since is error prone (you may suddenly forget to reset an
added object and still get valid data).

I don't understand. If you forget to reset a signal, how will that
create a problem? The type of warning the OP is talking about happens
because the signal is *not* initialized and is a useful flag for that
condition. It is not assured to catch all uninitialized signals, but
how is intentionally not initializing them better?

assume the following code:

<code>
signal a: std_logic_vector := x"0123";
signal b: std_logic_vector := x"4567";

....

process (rst, clk)
begin
if rst = '1' then
a <= '0000';
elsif rising_edge(clk) then
-- do something comparing a and b
end if;
end process;

</code>

The code above 'depends' on the initialization in the signals
declaration and your simulation may differ from the behavior after
synthesis, unless your target (and the toolchain) supports explicit
initializations.

My suggestion is to properly *reset* every register in your logic
because this is how you control what is going to happen when your fpga
will be doing *after* reset. You can safely disregard all signal
initializations and handle those warnings at time 0 with the workaround
posted.

Al
 
On 11/29/2014 6:31 PM, alb wrote:
Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]
This is a sound suggestion, but I won't initialize those objects in the
vhdl code since is error prone (you may suddenly forget to reset an
added object and still get valid data).

I don't understand. If you forget to reset a signal, how will that
create a problem? The type of warning the OP is talking about happens
because the signal is *not* initialized and is a useful flag for that
condition. It is not assured to catch all uninitialized signals, but
how is intentionally not initializing them better?

assume the following code:

code
signal a: std_logic_vector := x"0123";
signal b: std_logic_vector := x"4567";

....

process (rst, clk)
begin
if rst = '1' then
a <= '0000';
elsif rising_edge(clk) then
-- do something comparing a and b
end if;
end process;

/code

The code above 'depends' on the initialization in the signals
declaration and your simulation may differ from the behavior after
synthesis, unless your target (and the toolchain) supports explicit
initializations.

My suggestion is to properly *reset* every register in your logic
because this is how you control what is going to happen when your fpga
will be doing *after* reset. You can safely disregard all signal
initializations and handle those warnings at time 0 with the workaround
posted.

If resetting a signal in your design is a requirement, it should have a
way of verifying that it was reset. Every requirement should be
verified. I would do that in the test bench.

--

Rick
 

Welcome to EDABoard.com

Sponsor

Back
Top