«

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

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

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