Warning message

Discussion in 'VHDL' started by trescot@gmail.com, Dec 19, 2006.

  1. 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
     
    , Dec 19, 2006
    #1
    1. Advertising

  2. Jim Lewis Guest

    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
    >
     
    Jim Lewis, Dec 20, 2006
    #2
    1. Advertising

  3. Guest

    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
    > >
     
    , Dec 20, 2006
    #3
  4. KJ Guest

    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
    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
     
    KJ, Dec 20, 2006
    #4
  5. Ajeetha Guest

    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
     
    Ajeetha, Dec 22, 2006
    #5
  6. 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.


    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
     
    Ralf Hildebrandt, Dec 27, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    6
    Views:
    4,461
    Douglas Sykora
    Feb 11, 2005
  2. Pete Becker
    Replies:
    0
    Views:
    1,405
    Pete Becker
    Feb 10, 2005
  3. B. Williams

    warning C4267 and warning C4996

    B. Williams, Oct 26, 2006, in forum: C++
    Replies:
    17
    Views:
    2,677
  4. WARNING! Prosoftstore.com is a SCAM! WARNING!

    , Jul 8, 2007, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    345
  5. Julian Mehnle
    Replies:
    17
    Views:
    951
    Julian Mehnle
    May 18, 2006
Loading...

Share This Page