Odd Simulator Error

Discussion in 'VHDL' started by rickman, Mar 31, 2011.

  1. rickman

    rickman Guest

    I am working on a test bench for a design that is working ok. The
    code for the design is not changing, just the test bench code.
    Occasionally when I compile in the Aldec ActiveHDL simulator I get a
    very odd error that I've never seen before.

    # Error: DAGGEN_0007: mulaw.vhd : (0, 0): Error during conversion c:
    \Arius\Boards\IRIG-B-Testbed\FPGA\FullTest\FullTest\compile
    \muLaw_RTL.dag to c:\Arius\Boards\IRIG-B-Testbed\FPGA\FullTest\FullTest
    \compile\muLaw_RTL._x86.bin

    The file that this occurs on is random. It can happen on multiple
    files as well. If I recompile it usually goes away although sometimes
    I have to recompile more than once.

    I thought maybe it was a memory issue but closing it and restarting
    doesn't really fix the issue. It just seems to be totally random
    failing perhaps two times out of five.

    Any idea what this is about?

    Rick
     
    rickman, Mar 31, 2011
    #1
    1. Advertising

  2. On Mar 31, 8:03 am, rickman wrote:

    > # Error: DAGGEN_0007: mulaw.vhd : (0, 0): Error during conversion c:
    > \Arius\Boards\IRIG-B-Testbed\FPGA\FullTest\FullTest\compile
    > \muLaw_RTL.dag to c:\Arius\Boards\IRIG-B-Testbed\FPGA\FullTest\FullTest
    > \compile\muLaw_RTL._x86.bin
    >
    > The file that this occurs on is random.  It can happen on multiple
    > files as well.  If I recompile it usually goes away although sometimes
    > I have to recompile more than once.
    >
    > I thought maybe it was a memory issue but closing it and restarting
    > doesn't really fix the issue.  It just seems to be totally random
    > failing perhaps two times out of five.
    >
    > Any idea what this is about?


    It's pretty clear that this is a tool bug. DAG = Directed Acyclic
    Graph, I would guess - the tree representation of your code that's
    created internally by the compiler.

    I cannot imagine why it should come and go on the same set of source
    code, unless there's some random seeding going on for the internal
    optimizations.

    Support case for Aldec, I'm afraid. A tool crash, or a tool failing
    on some internal operation, is NEVER your fault. If the tool can't
    report the problem back to something in your source code, it's the
    tool that's broken. Before anyone takes this the wrong way, let's
    point out that the name "Aldec" here is a placeholder for "any company
    whose tool misbehaves in such a way" - it's happened to me with tools
    from much bigger companies than Aldec :)
    --
    Jonathan Bromley
     
    Jonathan Bromley, Mar 31, 2011
    #2
    1. Advertising

  3. On Thu, 31 Mar 2011 02:25:32 -0700, Jonathan Bromley wrote:

    > On Mar 31, 8:03 am, rickman wrote:
    >
    >> # Error: DAGGEN_0007: mulaw.vhd : (0, 0): Error during conversion c:
    >> \Arius\Boards\IRIG-B-Testbed\FPGA\FullTest\FullTest\compile
    >> \muLaw_RTL.dag to c:\Arius\Boards\IRIG-B-Testbed\FPGA\FullTest\FullTest
    >> \compile\muLaw_RTL._x86.bin
    >>
    >> The file that this occurs on is random.  It can happen on multiple
    >> files as well.  If I recompile it usually goes away although sometimes
    >> I have to recompile more than once.
    >>
    >> I thought maybe it was a memory issue but closing it and restarting
    >> doesn't really fix the issue.  It just seems to be totally random
    >> failing perhaps two times out of five.
    >>
    >> Any idea what this is about?

    >
    > It's pretty clear that this is a tool bug. DAG = Directed Acyclic
    > Graph, I would guess - the tree representation of your code that's
    > created internally by the compiler.
    >


    I agree, but even if it's a tool bug ...

    You can't just stop and wait until the tool supplier fixes it,
    unfortunately.

    What to do next?

    My experience with tool bugs is that often they have remained hidden
    because you are exercising some corner case ... possibly faulty VHDL that
    (another) tool bug allowed through the parser.
    In which case:
    (a) try building the project in other available systems (pref Modelsim,
    possibly Xilinx free ISIM or XST from Webpack, etc) and note any warnings
    or syntax errors.

    (b) go back to a previous version before the failure started (if there
    was one), and bisect until you find the suspect file. Not so easy if the
    failure is intermittent

    (c) comment out or rewrite to avoid any new VHDL tricks or constructs you
    are trying for the first time to see if there is a workaround.

    This way, you can often (a) carry on working in the absence of a fix, (b)
    localise the error to improve the bug report and (c) submit a tiny test
    case instead of having to hand over your whole project.

    If possible, it is better to report "Xilinx ISIM 10.1 exits suddenly with
    a Segment Violation when you return an access type (e.g. Line = access
    string) from a function" than "it crashed".

    Apologies to Rick if this is all old hat to him; however it may be useful
    to somebody else.

    - Brian
     
    Brian Drummond, Mar 31, 2011
    #3
    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. john

    simulator Error

    john, Feb 5, 2007, in forum: VHDL
    Replies:
    4
    Views:
    712
    SKeffect
    Feb 6, 2007
  2. Michael Speer

    Odd behavior with odd code

    Michael Speer, Feb 16, 2007, in forum: C Programming
    Replies:
    33
    Views:
    1,137
    Richard Heathfield
    Feb 18, 2007
  3. july
    Replies:
    2
    Views:
    470
  4. Mihovil Frater

    xilinx simulator error

    Mihovil Frater, Feb 27, 2008, in forum: VHDL
    Replies:
    0
    Views:
    946
    Mihovil Frater
    Feb 27, 2008
  5. Daku
    Replies:
    11
    Views:
    2,273
Loading...

Share This Page