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

../V3Ast.cpp:481: Node has no back, already unlinked? -- interfaces, modport, unpacked array badness #1135

Closed
veripoolbot opened this issue Mar 11, 2017 · 7 comments
Assignees
Labels
resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: John (Pete) Stevenson
Original Redmine Issue: 1135 from https://www.veripool.org

Original Assignee: Wilson Snyder (@wsnyder)


The attached code works fine with one mux instantiated, but with two muxes instantiated it emits a strange error message:

The issue might be a bad interaction between interfaces, modports, and unpacked arrays.

Using the attached 5 files, command line and stdout:

> verilator --lint-only Testbench.sv
%Error: Internal Error: ThingMuxOH.sv:7: ../V3Ast.cpp:481: Node has no back, already unlinked?
%Error: Internal Error: See the manual and http://www.veripool.org/verilator for more assistance.
%Error: Command Failed .../Desktop/VeriBug/ver/v3install/bin/verilator_bin --lint-only Testbench.sv

Testbench.sv:

`include "pkg.sv"

import pkg::*;

module top(
  input logic clk,
  input logic reset
  );

  localparam M = 5;
  localparam N = 2;

  unique_id_t uids[0:N-1];

  the_intf #(.M(M)) thing_inp();
  the_intf #(.M(M)) thing_out();

  Thinker #(
     .M        ( M         ),
     .N        ( N         )) thinker(
     .clk      ( clk       ),
     .reset    ( reset     ),
     .uids     ( uids      ),
     .thing_inp( thing_inp ),
     .thing_out( thing_out ));
endmodule

Thinker.sv:

import pkg::*;

module Thinker #(
  parameter M = 5,
  parameter N = 2)(
  input logic clk,
  input logic reset,
  input unique_id_t uids[0:N-1],
  the_intf.t thing_inp,
  the_intf.i thing_out
  );

  the_intf #(.M(M)) curr_things [N-1:0] ();
  the_intf #(.M(M)) prev_things [N-1:0] ();
  the_intf #(.M(M)) curr_thing ();
  the_intf #(.M(M)) prev_thing ();

  logic [N-1:0] select_oh;

  // 1st mux:
  ThingMuxOH #(
     .NTHINGS  ( N           ),
     .M        ( M           )) curr_thing_mux(
     .select_oh( select_oh   ),
     .things_in( curr_things ),
     .thing_out( curr_thing  ));

  // 2nd mux, comment this out and no problem:
  ThingMuxOH #(
     .NTHINGS  ( N           ),
     .M        ( M           )) prev_thing_mux(
     .select_oh( select_oh   ),
     .things_in( prev_things ),
     .thing_out( prev_thing  ));

endmodule

ThingMuxOH.sv:

import pkg::*;

module ThingMuxOH #(
  parameter NTHINGS = 1,
  parameter       M = 5 )(
  input logic [NTHINGS-1:0] select_oh,
  the_intf.t things_in [NTHINGS-1:0],
  the_intf.i thing_out
  );
endmodule

the_intf.sv:

import pkg::*;

interface the_intf #(parameter M=5);
     outer_thing_t [M-1:0] things;
     logic                 valid;

     modport i(
       output things,
       output valid
     );

     modport t(
       input things,
       input valid
     );
endinterface

pkg.sv:

package pkg;

typedef logic [31:0] unique_id_t;

typedef struct packed {
     unique_id_t foo;
} inner_thing_t;

typedef struct packed {
     inner_thing_t bar;
     inner_thing_t baz;
} outer_thing_t;

endpackage

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-03-16T00:05:06Z


Thanks for the test.

Fixed in git towards 3.902.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Johan Bjork
Original Date: 2017-03-20T19:52:33Z


Wilson Snyder wrote:

Thanks for the test.

Fixed in git towards 3.902.

This change breaks all our designs. I haven't been able to debug why yet except that it crashes in V3Inline.cpp:518, pinNewVarp is NULL.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-03-21T22:22:38Z


Reopening... Johan, if you can please make an example or patch, as it's not obvious why the previous clone failed.

BTW at V3Inline.cpp line 513 I added in trunk:
if (!pinNewVarp) pinOldVarp->v3fatalSrc("Cloning failed");

but obviously that just makes a slightly nicer message rather than fixing anything.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Johan Bjork
Original Date: 2017-03-22T15:02:43Z


Wilson Snyder wrote:

Reopening... Johan, if you can please make an example or patch, as it's not obvious why the previous clone failed.

BTW at V3Inline.cpp line 513 I added in trunk:
if (!pinNewVarp) pinOldVarp->v3fatalSrc("Cloning failed");

but obviously that just makes a slightly nicer message rather than fixing anything.

Curiously enough our code that was pretty much identical to the example John posted.
I found two ways to make John's example fail in the same way

  1. Create the interfaces using a non-default value for it's parameter (ie, change parameter M=5 in the interface declaration to something else and leave everything else as is)
  2. Instantiate the two ThingMuxOH modules using different values of N (and adjust interfaces accordingly)

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Johan Bjork
Original Date: 2017-03-22T16:24:40Z


Johan Bjork wrote:

Wilson Snyder wrote:

Reopening... Johan, if you can please make an example or patch, as it's not obvious why the previous clone failed.

BTW at V3Inline.cpp line 513 I added in trunk:
if (!pinNewVarp) pinOldVarp->v3fatalSrc("Cloning failed");

but obviously that just makes a slightly nicer message rather than fixing anything.

Curiously enough our code that was pretty much identical to the example John posted.
I found two ways to make John's example fail in the same way

  1. Create the interfaces using a non-default value for it's parameter (ie, change parameter M=5 in the interface declaration to something else and leave everything else as is)
  2. Instantiate the two ThingMuxOH modules using different values of N (and adjust interfaces accordingly)

Attached patch.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-03-22T21:35:17Z


Great, thanks, patch pushed. Let's give this another try.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2017-04-02T12:52:02Z


In 3.902.

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