[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  SystemPerl
  Voneline
  WFH
General Info
  Papers

Issue #405

generate-conditional always succeeds

Added by Jeremy Bennett over 1 year ago. Updated over 1 year ago.

Status:Closed Start date:10/26/2011
Priority:Normal Due date:
Assignee:Wilson Snyder % Done:

0%

Category:Unsupported
Target version:-

Description

The tests in a generate conditional block always appear to succeed. The attached example modulegen.v contains two such conditional blocks, only the first of which should be generated. In fact both are generated, leading to an error due to a missing module.

module foobar
  #( parameter
     FOO_START = 0,
     FOO_NUM = 2,
     FOO_TYPE = 0  // This means we should instatiate foo0
     )
    (
    input wire[FOO_NUM-1:0] foo, 
    output wire[FOO_NUM-1:0] bar);

   generate
      begin: g
         genvar j;
         for (j = FOO_START; j < FOO_NUM+FOO_START; j = j + 1)
           begin: foo_inst;
              if (FOO_TYPE == 0)
                begin: foo_0
                   // instatiate foo0
                   foo0 i_foo(.x(foo[j]), .y(bar[j]));
                end
              if (FOO_TYPE == 1)
                begin: foo_1
                   // instatiate foo1
                   foo1 i_foo(.x(foo[j]), .y(bar[j]));
                end
           end // block: foo_inst;
      end // block: g
   endgenerate
endmodule // foobar

module foo0(input wire x, output wire y);

   assign y = ~x;

endmodule

We build with verilator:

verilator -cc --language 1364-2001 --top-module foobar modulegen.v

The error message is:

$ verilator -cc --language 1364-2001 --top-module foobar modulegen.v
%Error: modulegen.v:31: Cannot find file containing module: foo1
%Error: modulegen.v:31: Looked in:
%Error: modulegen.v:31:       foo1
%Error: modulegen.v:31:       foo1.v
%Error: modulegen.v:31:       foo1.sv
%Error: modulegen.v:31:       obj_dir/foo1
%Error: modulegen.v:31:       obj_dir/foo1.v
%Error: modulegen.v:31:       obj_dir/foo1.sv
%Error: Exiting due to 8 warning(s)
%Error: Command Failed $VERILATOR_ROOT/verilator_bin -cc --language 1364-2001 --top-module foobar modulegen.v

This shows that the second conditional block has been generated, which it should not, because FOO_TYPE is 0.

Found with Verilator 3.824.

modulegen.v - Verilog file demonstrating the problem (1.1 kB) Jeremy Bennett, 10/26/2011 11:54 am

History

Updated by Wilson Snyder over 1 year ago

  • Category set to Unsupported
  • Status changed from New to Feature

It doesn't always succeed, it just requires the other module to be resolvable and parseable, but will not use the code inside it. For example, having a "module foo1; endmodule" is sufficient, it won't complain about the pins mismatching as the instantiation is not done.

I believe this is compliant with the spec. One possibility would to be to delay module reading until the if completes, but this cannot be easily changed without requiring all of the filenames to be listed on the command line. (Which is how at least two other simulators get around the problem, but a method I despise on usability grounds.) Another possibility is to delay the not found error until it's determined that the module is really needed, which is probably not too bad.

Updated by Wilson Snyder over 1 year ago

P.S. if you could provide examples in verilator test format (see BUGS in the docs) it would be helpful, and I think it will make your running it easier for you too, thanks!

Updated by Wilson Snyder over 1 year ago

Actually I tried an experiment and the pins do need to match up, as it does the interconnection linting before parameter trimming. Perhaps a misfeature.

Updated by Wilson Snyder over 1 year ago

  • Status changed from Feature to Resolved
  • Assignee set to Wilson Snyder

It now reports missing module after parameters are resolved. This isn't perfect, but was easy.

In git towards 3.825.

Updated by Wilson Snyder over 1 year ago

  • Status changed from Resolved to Closed

In 3.830.

Also available in: Atom