Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-04-23T00:56:43Z

This may be related to #�. Are you using the release version or the git
version? Please try the git version if not.

Original Redmine Comment
Author Name: Dimitris Nalbantis
Original Date: 2009-04-23T08:11:34Z

To solve #� I couldn't download the git version behind our secure network so you send me some mods to do to the source code myself. The version I am using does include these changes. Are there any more changes in the git version that need to be incorporated? If yes, then I will see if I can find an alternative way of accessing the git version.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-04-23T09:51:28Z

The patches should have what matters in the git version.

Unfortunately the backtrace doesn't include the filename. Try "verilator --gdb --debug ..." then the "run" and "bt". The --debug should have it load the symbols so we can see the error line.

Original Redmine Comment
Author Name: Dimitris Nalbantis
Original Date: 2009-04-23T10:40:04Z

Before I received your latest email I downloaded the git version but while making the installation I came across the compile error shown in file #�.

As far as the --gdb option the response is shown in file #�.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-04-23T12:59:27Z

The first error "DTVERSION_rev" is because I think you got a earlier error message from git. There's probably something wrong with your git install, anyhow just put into src/config_rev.h

static const char* DTVERSION_rev = "UNKNOWN_REV (mod)";

I'll make it handle the error better in the next version.

As for the real problem, I didn't see a backtrace. Use

gdb /home/dimitris/verilator-3.702/verilator_bin_dbg --debug --cc ../verilog/gaincntrl.v ../verilog/gtf_rtl_rev2.v ../verilog/pdetgain.v ../verilog/pdetga_rtl.v ../verilog/pwrcntrl_rtl_rev2.v ../verilog/timer.v ../verilog/vgagain.v  ../verilog/gaincntrl_top.v --top-module gaincntrl --Wno-lint --Wno-WIDTHCONCAT -Mdir ../cpp

run
bt

Note the _dbg on verilator_bin

Original Redmine Comment
Author Name: Dimitris Nalbantis
Original Date: 2009-04-23T14:05:06Z

Thanks. That worked. Here is the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000414b9c in AstNode::fileline (this=0x0) at ../V3Ast.h:664
664 FileLine* fileline() const { return m_fileline; }
(gdb) bt
#0 0x0000000000414b9c in AstNode::fileline (this=0x0) at ../V3Ast.h:664
#1 0x0000000000524988 in V3LinkLevel::wrapTop (netlistp=0x7dcb00) at ../V3LinkLevel.cpp:87
#2 0x00000000004420d3 in process () at ../Verilator.cpp:181
#3 0x00000000004455b4 in main (argc=17, argv=0x7fbfffdf78, env=0x7fbfffe008) at ../Verilator.cpp:571

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-04-24T01:44:37Z

I believe the error is because at that point there's no modules left to process.
I'm not sure why one of several earlier errors didn't fire. Perhaps you can isolate it further.
Maybe you are specifying a top module that doesn't exist, or a library cell that doesn't exist, or
a module with nothing in it?

Original Redmine Comment
Author Name: Dimitris Nalbantis
Original Date: 2009-04-24T07:46:03Z

I guess the clue must be that the module itself can be verilated but the instance of that module in the higher level wrapper crashes. I tried the same with the submodules i.e. the submodules themselves can be verilated but when they are instantiated in a similar wrapper the translation crashes. The same submodules when they are instantiated in the top level module are fine since the top level module itself with instances of the submodules can be verilated fine. The wrapper module is as simple as can be with no inputs, and just an instance with inputs tied to 0 and outputs connected to wires.

Original Redmine Comment
Author Name: Dimitris Nalbantis
Original Date: 2009-04-24T08:25:17Z

The problem was indeed in the wrapper schematic. I was not specifying the top-module correctly:) Now it's fine.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-04-24T11:12:34Z

Glad you found it. I did have a test for the error message when --top-module isn't specified, so it wasn't just that - can you tell me what to do to hit this?

Original Redmine Comment
Author Name: Dimitris Nalbantis
Original Date: 2009-04-24T13:53:02Z

I can see the error message when the top-module specification is missing all-together. I did specify a top-module and it was an existing module only it wasn't the actual top module in my design. My top module A had submodules B, C, and D. I was accidentally specifying submodule B as a top-module. Does that make sense?

Original Redmine Comment
Author Name: Dimitris Nalbantis
Original Date: 2009-04-24T13:59:42Z

To be more exact I had module A_top which was instantiating module A (which in turn instantiated B, C, and D) and I was specifying top-module to be A instead of A_top. I tried to simplify the problem in my earlier response and I don't expect it to make a difference but this is the exact setup I was working with.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-04-24T14:32:19Z

Ok, got it reproduced. The git version now gives:

%Error: Specified --top-module 'a' isn't at the top level, it's under another cell.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-05-02T11:57:51Z

In 3.703.