Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

%Error: Internal Error: ...: ../V3AstNodes.h:453: Unexpected Call #393

Closed
veripoolbot opened this issue Sep 20, 2011 · 9 comments
Closed
Assignees
Labels
resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Alex Solomatnikov
Original Redmine Issue: 393 from https://www.veripool.org
Original Date: 2011-09-20
Original Assignee: Wilson Snyder (@wsnyder)


verilator_bin_dbg -sv -CFLAGS "-DMC_UNIT_LEVEL_TEST -DVERILATOR -std=c++0x -g -I.. -I.../common/test/env -I/tools/local/include -DWAVES -DTRACE" --trace-max-width 512 --trace-max-array 128 -Wno-fatal --trace +define+TRACE --assert +define+HC_ASSERTION --sp --top-module env_site_mc_top --prefix env_site_mc_top --Mdir obj_dir -f env_site_mc_top_flags.f -f env_site_mc_top_files.f env_site_mc_top.v --debug | & tee verilator.log

Last phase before failure:

dot -Tps -o ~/a.ps obj_dir/env_site_mc_top_34_gate_simp.dot
%Error: ../../rtl/site_mc_top.v:231: Internal: Unexpected Call
-node: 0x6a910c0
%Error: Internal Error: ../../rtl/site_mc_top.v:231: ../V3AstNodes.h:453: Unexpected Call
-node: 0x6a910c0
- V3StatsReport.cpp:208:statsReport: 
%Error: Internal Error: Aborting since under --debug
Abort

Attaching full log file and the last few files generated in obj_dir.

Verilator version 3.820+ (after bug 374 was fixed).

Verilog line where verilator fails:

    input logic                       oct_rzqin          [`MC_NUM_CHANNELS-1:0],

...

    genvar                            ch;
    generate
       for( ch=0; ch<`MC_NUM_CHANNELS; ch++ ) begin : GEN_CHANNELS

...

          site_mc_channel_ddr3 #(.channel_id(ch)) mc_channel(// DRAM interface
                                          .mem_a      (mem_a      [ch]),
                                          .mem_ba     (mem_ba     [ch]),
                                          .mem_cas_n  (mem_cas_n  [ch]),
                                          .mem_ck     (mem_ck     [ch]),
                                          .mem_ck_n   (mem_ck_n   [ch]),
                                          .mem_cke    (mem_cke    [ch]),
                                          .mem_cs_n   (mem_cs_n   [ch]),
                                          .mem_dm     (mem_dm     [ch]),
                                          .mem_odt    (mem_odt    [ch]),
                                          .mem_ras_n  (mem_ras_n  [ch]),
                                          .mem_reset_n(mem_reset_n[ch]),
                                          .mem_we_n   (mem_we_n   [ch]),
                                          .mem_dq     (mem_dq     [ch*72 +: 72]),
                                          .mem_dqs    (mem_dqs    [ch*9  +: 9 ]),
                                          .mem_dqs_n  (mem_dqs_n  [ch*9  +: 9 ]),

*                                         .oct_rzqin  (oct_rzqin  [ch]),
*

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-09-21T00:39:25Z


In propagating constants between gates, there's some array (oct_rzqin?) that is constant in some way it has never encountered before.

Assuming nothing obvious comes to your mind, please attach the highest number .tree file, thanks.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2011-09-21T00:57:01Z


Yes, oct_rzqin is an array pin, that is unconnected few levels below in the hierarchy.
The design uses multiple Altera's DDR3 controllers, and each DDR3 controller requires separate
oct_rzqin pin at the top. However, verilator could not compile DDR3 RTL, which was substituted
by the behavioral model and oct_rzqin pins were left unconnected.

I did save a couple of .tree files before and after failing step, however, both are ~10 MB and
the web-site does not let to attached them.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2011-09-21T01:08:28Z


Please, let me know how to send you those .tree files.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2011-09-21T01:31:26Z


Attached gziped files.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-09-21T11:37:04Z


This assignment

 1:2:2:2:2: ASSIGNW 0x5b92ad0 <e540369> {231} w1
 1:2:2:2:2:1: ARRAYSEL 0x6a910c0 <e493720> {231} w1 [start:0] [length:1]
 1:2:2:2:2:1:1: CONST 0x70daaa0 <e552932#> {289} w1  1'h0
 1:2:2:2:2:1:2: CONST 0x6a91270 <e194515> {191} w1  1'h0

is causing the error; the ARRAYSEL should be a SEL.

I suspect the error is with inlining related to the generate; can you send the *_link.tree
and *_begin.tree.gz files? Thanks.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-09-21T11:37:51Z


BTW a work around would probably be to simply tie the pin to zero

                                      .oct_rzqin  (1'b0),

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2011-09-21T22:05:45Z


Yes, we used this workaround.

It turns out there was a bug in Verilog and that was the reason verilator was failing.

Chandan reduced the test case to the following code:

module suba(input logic clk, input logic foo);
     always @(posedge clk)
         $display("%b", foo);
endmodule


module dut
     #(parameter W = 1)
     (input logic clk, input logic foo[W-1:0]);

     genvar i;
     generate
         for (i = 0; i < W; i++) begin
             suba ua(.clk(clk), .foo(foo[i]));
         end
     endgenerate

endmodule


module top(input logic clk);

     logic foo = 0;

     dut #(.W(4)) udut(.*);
endmodule

P.S. I can still send you by email gziped tar ball of .tree files of the original code but it is large ~15 MB
and we do not want to post it on the web-site.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Chandan Egbert
Original Date: 2011-09-21T23:30:44Z


To clarify, the RTL bug is that the signal "foo" in module "top" in the test case should be arrayed but is not.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-01-20T17:59:31Z


Error for the bad array code added in git towards 3.845.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants