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
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