Warning message

T

trescot@gmail.com

Guest
Hi guys

When I run my test-bench I get a message in my console as

"ASSERT/WARNING (time 107247 NS) from package ieee.STD_LOGIC_ARITH,
this builtin function called from process
:nT0:NANO:HIF:rBlk:$PROCESS_012 (architecture worklib.nT_RAM_Blk:RTL)
Built-in relational argument contains a ('U', 'X', 'W', 'Z', '-') in an
operand".

What does it mean and how to get rid of it.

Thanks
 
First since it references "STD_LOGIC_ARITH" it means you are
using a non-standard math package and you ought to switch
to numeric_std.

Also it means that the input to a math operation in the
design "nT_RAM_Blk" has an X on the input. In general,
when your design has not entered reset yet, it is ok.

In your case however, I am guessing that at time,
107247 NS, you are out of reset so you need to further
think about your design. Why is an input an X at this
point in time?

Is it a register that should have been reset? This you
need to fix.

Is it an internal, buried node that does not propagate
to an output until it contains something valid? In this
case you are ok. I have a UART in one of my designs in which
the internally divide down UART clock will produce this message
until the divider register is loaded. On a test where I don't
use the UART and forget to initialize the divider register, it
will create spew like this, however, since the UART is not
being used, it is not meaningful.

In general you do not want messages like these. If you
want to be sure you are safe without having to do the
analysis, then initialize the registers that cause this issue.
If you want the block to be easily be re-used, you don't want
messages like this coming out.

Cheers,
Jim Lewis
SynthWorks VHDL Training


Hi guys

When I run my test-bench I get a message in my console as

"ASSERT/WARNING (time 107247 NS) from package ieee.STD_LOGIC_ARITH,
this builtin function called from process
:nT0:NANO:HIF:rBlk:$PROCESS_012 (architecture worklib.nT_RAM_Blk:RTL)
Built-in relational argument contains a ('U', 'X', 'W', 'Z', '-') in an
operand".

What does it mean and how to get rid of it.

Thanks
Click to expand...
 
Well its a part of my test-bench and I am not its owner. I am using
this vhdl test-bench to run my verilog rtl.
So I really dont have that great idea about its low level blocks. There
is a signal called Din_Ram which is the data_input to a ram_block which
may be the reason.

But the test-bench works fine with my rtl and I have no problem wih it
so I dont want to touch it.
But only the issue is, its very difficult to look for any message on
the console of my simulator as I get whole bunch of this warning. So I
was thinking whether its possible to get rid of this kind of warning.

I am using NC tools and I really dont know whether I can mask this kind
of warning through this tool.


thanks


Jim Lewis wrote:
First since it references "STD_LOGIC_ARITH" it means you are
using a non-standard math package and you ought to switch
to numeric_std.

Also it means that the input to a math operation in the
design "nT_RAM_Blk" has an X on the input. In general,
when your design has not entered reset yet, it is ok.

In your case however, I am guessing that at time,
107247 NS, you are out of reset so you need to further
think about your design. Why is an input an X at this
point in time?

Is it a register that should have been reset? This you
need to fix.

Is it an internal, buried node that does not propagate
to an output until it contains something valid? In this
case you are ok. I have a UART in one of my designs in which
the internally divide down UART clock will produce this message
until the divider register is loaded. On a test where I don't
use the UART and forget to initialize the divider register, it
will create spew like this, however, since the UART is not
being used, it is not meaningful.

In general you do not want messages like these. If you
want to be sure you are safe without having to do the
analysis, then initialize the registers that cause this issue.
If you want the block to be easily be re-used, you don't want
messages like this coming out.

Cheers,
Jim Lewis
SynthWorks VHDL Training


Hi guys

When I run my test-bench I get a message in my console as

"ASSERT/WARNING (time 107247 NS) from package ieee.STD_LOGIC_ARITH,
this builtin function called from process
:nT0:NANO:HIF:rBlk:$PROCESS_012 (architecture worklib.nT_RAM_Blk:RTL)
Built-in relational argument contains a ('U', 'X', 'W', 'Z', '-') in an
operand".

What does it mean and how to get rid of it.

Thanks
Click to expand...
 
trescot@gmail.com wrote:
Well its a part of my test-bench and I am not its owner. I am using
this vhdl test-bench to run my verilog rtl.
So I really dont have that great idea about its low level blocks. There
is a signal called Din_Ram which is the data_input to a ram_block which
may be the reason.

But the test-bench works fine with my rtl and I have no problem wih it
so I dont want to touch it.
But only the issue is, its very difficult to look for any message on
the console of my simulator as I get whole bunch of this warning. So I
was thinking whether its possible to get rid of this kind of warning.

I am using NC tools and I really dont know whether I can mask this kind
of warning through this tool.

Before you try to mask it, it's worth the effort to first find out the
Click to expand...
real cause, sometimes warnings like these are the first indication of a
real problem. That way you'll be making an informed decision about
whether this really is a spurious message or not. I'd suggest the
following approach:

- Have your testbench stop on 'warnings' level asserts. That will take
you right to the offending line of code. Since you'll be inside the
std_logic_arith package when it happens that by itself won't be
terribly useful but knowing the exact hierarchy path to that assert
will be useful. As mentioned in the earlier post you'll find that some
signal that is the input to an arithmetic function is an unknown at the
time of the assert. From that point you can probably single step to
get to the line of design code that is causing the problem and get a
signal name.

- Based on what general area of the design that failed, try to figure
out what the testbench is NOT doing that it should in order to get that
signal initialized. Presumably there is some register or input
signal(s) somewhere that are not being exercised that, if they were,
would get that signal into a known state. Many times one can figure
this out even without being terribly knowledgable about the detailed
design just the overall functionality. If you can't figure it out
though, then find out from the owner of the code (or open a service
request if it's outside IP that you've paid for support on) for some
support and an answer on just what it is that the testbench is not
doing that is preventing the signal from becoming known. In any case,
the answer will likely fall into one of the following general
categories:
1. You find that your testbench is somewhat deficient in that you're
not doing something that you really should....so fix your testbench.
2. The owner of the code does not identify any problem with your
testbench, the assertion is valid and there is a design issue.....so
the owner needs to fix the design.
3. Your testbench is not using the design in a way that this unknown
signal is of any concern. This would be like Jim's UART example, if
his particular testbench-du-jour doesn't care about UART functionality

Two of those three possibilities are reasons for concern (hence the
recommendation to investigate before ignoring).

- If all else fails and you're really adverse to commenting out the
assert then check your tool for how to disable certain classes of
assert messages from making it to the console. I don't know about NC
but Modelsim has a dialog box where you can tell it to ignore
'warnings' (or 'error' or any other assert). The problem with this
approach, is that it will nuke all messages from any warning, not just
the one that you're seeing....this is the reason that commenting out
the assert would be preferable since it is targetting the one specific
message that you'd like to get rid of....but again, you only want to
perform this step after you've verified that the root cause for the
assert is reason #3 and not #1 or #2.

KJ
 
Hi,
NC used to support a TCL way of turning it off, IIRC it is:

set pack_assert_off {std_logic_arith}

Type that inside ncsim prompt (or add to a tcl script etc.)

HTH
Ajeetha, CVC
www.noveldv.com
 
Jim Lewis schrieb:

First since it references "STD_LOGIC_ARITH" it means you are
using a non-standard math package and you ought to switch
to numeric_std.
....
In general you do not want messages like these.
Click to expand...
Let me add: Use the function TO_01 from Numeric_std (input/ouput may be
signed or unsigned vectors) to eliminate these warnings - iff you are
really shure that 'X' and the other unknown states are no harm.

Ralf
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top