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

Import statement not recognized #1115

Closed
veripoolbot opened this issue Nov 26, 2016 · 3 comments
Closed

Import statement not recognized #1115

veripoolbot opened this issue Nov 26, 2016 · 3 comments
Labels
resolution: no fix needed Closed; no fix required (not a bug)

Comments

@veripoolbot
Copy link
Contributor


Author Name: Robert Baruch (@RobertBaruch)
Original Redmine Issue: 1115 from https://www.veripool.org


I'm using Verilator built from head (11/26/2016), and 1800-2012 SystemVerilog.

=== file common.v ===

package common;

typedef enum { NONE, RST, INC, LOAD } microaddr_cmd;

endpackage: common

=== file microaddr_counter.v ===

module microaddr_counter
     import common::*;

(input wire clk,
     input common::microaddr_cmd cmd,
     input wire [9:0] load_addr,
     output reg [9:0] addr);

always_ff @(posedge clk) begin
     unique case(cmd)
         NONE: ;
         RST: addr <= 0;
         INC: addr <= addr + 1;
         LOAD: addr <= load_addr;
     endcase
end

endmodule

Command: verilator -Wall -I. --debug -cc microaddr_counter.v

Output:

	/usr/local/bin/verilator_bin_dbg -Wall -I. --debug -cc microaddr_counter.v
Starting Verilator 3.890 2016-11-25 rev verilator_3_890
- V3Os.cpp:54:        export SYSTEMC_ARCH=linux # From sysname 'linux'
- V3File.cpp:190:        --check-times failed: no input obj_dir/Vmicroaddr_counter__verFiles.dat
- V3GraphTest.cpp:356:test: 
- V3ParseImp.cpp:97:  parseFile: microaddr_counter
  Preprocessing microaddr_counter.v
- V3PreShell.cpp:133:     Reading microaddr_counter.v
- V3ParseImp.cpp:162: Lexing microaddr_counter.v
%Error: microaddr_counter.v:2: syntax error, unexpected IDENTIFIER, expecting PACKAGE-IDENTIFIER
%Error: microaddr_counter.v:5: syntax error, unexpected input, expecting IDENTIFIER or do or final
%Error: microaddr_counter.v:7: syntax error, unexpected output, expecting IDENTIFIER or do or final
%Error: microaddr_counter.v:7: syntax error, unexpected ')', expecting ',' or ';'
%Error: Exiting due to 4 error(s)
- V3Ast.cpp:1035:     Dumping obj_dir/Vmicroaddr_counter_990_final.tree
- V3StatsReport.cpp:207:statsReport: 
%Error: Aborting since under --debug
%Error: export VERILATOR_ROOT=/usr/local
%Error: /usr/local/bin/verilator_bin_dbg -Wall -I. --debug -cc microaddr_counter.v
%Error: Command Failed /usr/local/bin/verilator_bin_dbg -Wall -I. --debug -cc microaddr_counter.v

It seems to me that Verilator needs to know that "common" is a package identifier and not a plain old identifier, but I'm not sure how to tell it. I thought that it would be able to figure it out since "common" comes right after the import keyword.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-11-27T13:23:23Z


SystemVerilog specification requires you to declare all packages before you use them. Either put common.v on the command line before microaddr_counter.v, or turn common.v into an include file with appropriate guards and `include it in microaddr_counter.v (and perhaps rename it .vh). FWIW the standard in my company is both - name it .vh, include it, and put it on the command line.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Robert Baruch (@RobertBaruch)
Original Date: 2016-11-27T16:49:38Z


Well that's the thing -- I did originally put it on the command line (albeit accidentally) via *.v. I also tried:

verilator -Wall -cc common.v microaddr_counter.v

When I checked the obj_dir directory, I found a lot of VCommon* files, but nothing else. I see nothing having to do with the microaddr_counter module. (In fact, by grepping the code for microaddr, it seems it is there, just not with a filename I expected).

In addition, the wiki's arg summary shows this command line:

 verilator --cc [options] [top_level.v]...

Which led me to believe that verilator wants all your top level files, but not any supporting files, and that it would find the supporting files from references in the top level files, via a search path. If that's not true, maybe the wiki needs to be updated :)

I also found a syntax for files from this forum post: http://www.veripool.org/boards/2/topics/1906-Verilator-Meeded-to-understand-the-reason-for-fatal-warnings

 verilator --cc [options] {file1.v, file2.v, ...}

I didn't see that in the wiki either.

I suppose this bug has morphed to a plea to change the documentation?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-11-27T21:38:12Z


I've updated the documentation in git.

The name of the files in obj_dir will be based on the first file, but will properly implement the top module. Other flags can be used to change the name of the generated files if you desire.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: no fix needed Closed; no fix required (not a bug)
Projects
None yet
Development

No branches or pull requests

1 participant