Metavalue warnings from Numeric_std
djsi...@my-deja.com
During simulation of my design, modelsim gives me warnings like this:
*Warning: Numeric_std. metavalue detected, returning FALSE!
Time: 700ns Iteration: 0 Instance: <instancename>
There were a lot of these during simulation of my individual components
but they all occured only at zero ns, so I thought it was a startup
thing. Now that I'm simulating the top level design, these warnings pop
up on each clock edge. What causes them? Is it something to do with my
use of "unsigned"?
Thanks,
Dan
Sent via Deja.com http://www.deja.com/
Before you buy.
Ray Andraka
1's and 0's. For example if you use to_integer(unsigned_vector), you'll get
this warning if any bits of the vector are unknowns.
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com or http://www.fpga-guru.com
Charles Elias
djsi...@my-deja.com wrote:
> Hello:
>
> During simulation of my design, modelsim gives me warnings like this:
>
> *Warning: Numeric_std. metavalue detected, returning FALSE!
> Time: 700ns Iteration: 0 Instance: <instancename>
>
> There were a lot of these during simulation of my individual
components
> but they all occured only at zero ns, so I thought it was a startup
> thing. Now that I'm simulating the top level design, these warnings
pop
> up on each clock edge. What causes them? Is it something to do with
my
> use of "unsigned"?
>
> Thanks,
>
> Dan
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Ray, as usual, has it right. I get the same thing using Aldec Active-
HDL. I have found that I can reduce or eliminate this by assigning
initial values to all of my input signals in the testbench. For
example,
signal foo : std_logic := '0';
I give this example only because I don't know if I am using the correct
terminology here. I want to differentiate between this and signal
assignments after "begin".
Best regards,
Charles
--
What we hope ever to do with ease, we must first learn to do with
diligence." -- Johnson (1709-1784)
Chris Clegg
zero ns are due to start-up, when variables haven't yet been assigned
initial values. However, I found that ones further on into the
simulation run can cause problems. The issue is with 'X' propagation:
if you have code such as:
signal <= '1' when could_be_X = value else '0';
then signal will always be '1' or '0'. If could_be_X contains an
unknown (one of U, X, W, Z, -) then the equals comparison will return
false, as specified in the simulation warning. signal will then be
assigned '0', and you won't get X propagation from could_be_X through to
signal.
The way to solve this, if X propagation is required, is to use the
function Is_X from numeric_std package:
signal <= 'X' when Is_X(could_be_X)
else '1' when could_be_X = value else '0';
Of course, it may be that you don't need X propagation. It does stop
all the warnings during simulation though.
[Note: the Verilog equivalent code:
assign signal = (could_be_X == value) ? 1'b1 : 1'b0;
handles X propagation automatically. But then VHDL is much more
explicit than Verilog in just about all things.]
Chris
e...@riverside-machines.com.nospam
wrote:
>The way to solve this, if X propagation is required, is to use the
>function Is_X from numeric_std package:
>
> signal <= 'X' when Is_X(could_be_X)
> else '1' when could_be_X = value else '0';
>
It's not obvious (to me) what you're trying to do here, but it looks
like you're just doing strength-stripping, in which case this would be
more compact:
signal <= to_X(could_be_X);
This works with std_(u)logic and std_(u)logic_vector. BTW, is_X and
to_X are in std_logic_1164, not numeric_std.
Evan
Chris Clegg
The example was meant to implement a simple mux, but maybe I simplified
it a bit too much. Let's try again:
could_be_X: in std_logic;
choice1 : in std_logic;
choice2 : in std_logic;
signal : out std_logic;
signal <= 'X' when Is_X(could_be_X)
else choice1 when could_be_X = '1' else choice2;
This time, this is a simple mux, for which could_be_X input selects
which of choice1 or choice2 is set as the output signal. If could_be_X
was 'X' then, without the Is_X function, signal would be set to choice2
as could_be_X isn't = '1'. This is what I meant by 'X' propagation.
For this you do need Is_X.
Obviously this example is still very simple, and can be extended by
using std_(u)logic_vectors or having more choices.
And yes, you're right, Is_X is in std_logic_1164. My mistake.
Chris
Mike Treseler
>
> signal <= to_X(could_be_X);
>
> This works with std_(u)logic and std_(u)logic_vector. BTW, is_X and
> to_X are in std_logic_1164, not numeric_std.
>
> Evan
I can't find a "to_X" function.
In package NUMERIC_STD I see:
function TO_01 (S: UNSIGNED; XMAP: STD_LOGIC := '0') return UNSIGNED;
In package std_logic_1164 I see:
FUNCTION To_X01 ( s : std_logic_vector ) RETURN std_logic_vector;
J. Bhasker
> I also had a large number of these warnings. The ones that occur at
> zero ns are due to start-up, when variables haven't yet been assigned
> initial values. However, I found that ones further on into the
> simulation run can cause problems. The issue is with 'X' propagation:
> if you have code such as:
>
> signal <= '1' when could_be_X = value else '0';
>
> then signal will always be '1' or '0'. If could_be_X contains an
> unknown (one of U, X, W, Z, -) then the equals comparison will return
> false, as specified in the simulation warning. signal will then be
> assigned '0', and you won't get X propagation from could_be_X through to
> signal.
>
> The way to solve this, if X propagation is required, is to use the
> function Is_X from numeric_std package:
>
> signal <= 'X' when Is_X(could_be_X)
> else '1' when could_be_X = value else '0';
>
> Of course, it may be that you don't need X propagation. It does stop
> all the warnings during simulation though.
>
> [Note: the Verilog equivalent code:
>
> assign signal = (could_be_X == value) ? 1'b1 : 1'b0;
>
> handles X propagation automatically. But then VHDL is much more
> explicit than Verilog in just about all things.]
>
> Chris
>
> djsi...@my-deja.com wrote:
> >
> > Hello:
> >
> > During simulation of my design, modelsim gives me warnings like this:
> >
> > *Warning: Numeric_std. metavalue detected, returning FALSE!
> > Time: 700ns Iteration: 0 Instance: <instancename>
> >
> > There were a lot of these during simulation of my individual components
> > but they all occured only at zero ns, so I thought it was a startup
> > thing. Now that I'm simulating the top level design, these warnings pop
> > up on each clock edge. What causes them? Is it something to do with my
> > use of "unsigned"?
> >
> > Thanks,
> >
> > Dan
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
This is for your info.
From section 7.1 of the 1076.3-1997 standard, a constant NO_WARNING
has been defined in the package body of the NUMERIC packages. You can set
this constant to
true IF you want to suppress all warnings produced by the NUMERIC package -
edit the package
body and recompile.
- j.bhasker
Srinivasan Venkataramanan
"J. Bhasker" <jbha...@cadence.com> wrote in message
news:39A6BCFE...@cadence.com...
>
> This is for your info.
>
> From section 7.1 of the 1076.3-1997 standard, a constant NO_WARNING
> has been defined in the package body of the NUMERIC packages. You can set
> this constant to
> true IF you want to suppress all warnings produced by the NUMERIC
package -
> edit the package
> body and recompile.
>
A better way would be to do it in the simulator itself (Then you won't need
to re-compile, re-map the library etc..) There is a variable (atleast this
works in CADENCE env.) called "assert_report_level" which you can
"configure" to whatever you like (from NOTE | WARNING | ERROR | SEVERITY).
Regards,
Srini
> - j.bhasker
>
>
Joel Kolstad
in message news:8o6hoe$ib9$1...@porthos.nl.uu.net...
> > has been defined in the package body of the NUMERIC packages. You can
set
> > this constant to
> > true IF you want to suppress all warnings produced by the NUMERIC
> package -
> > edit the package
> > body and recompile.
This is what I've been doing for awhile now. Works like a charm.
> A better way would be to do it in the simulator itself (Then you won't
need
> to re-compile, re-map the library etc..)
Yes, for simulators that suppot it. Aldec's ActiveHDL, for instance, knows
about suppresing some of these warning messages (and can get rid of them by
checking a box), but not specifically those from Numeric_Std. Oh well...
recompiling is still an effective alternative, I think.
---Joel Kolstad