Verilator

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

To solve bug76 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.

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.

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

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

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?

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.

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

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?

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?

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.