Project

General

Profile

[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
  Voneline
  WFH
General Info
  Papers

Issue #1384

File-extension language option not consistently applied

Added by Al Grant 9 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Invoking/Options
% Done:

0%


Description

Suppose you have a Verilog (not SystemVerilog) file testdo1.v:
module testdo1(input do);
endmodule
This uses 'do' as a signal name, so you use +1364-1995ext+v to force .v files to be compiled a Verilog. This generates a SYMRSVDWORD warning but that's ok. Now suppose you have testdo2.v and compile with +1364-1995ext+v:
module testdo2(input do);
  testdo3 m(do);
endmodule
which automatically pulls in testdo3.v:
module testdo3(input do);
endmodule
This is now faulted with
%Error: testdo3.v:1: Unexpected "do": "do" is a SystemVerilog keyword misused as an identifier.
It looks like the language override is only being applied to explicitly named source files and not to other sources. This isn't specific to the name "do", it affects other words like "byte".

This isn't a mixed-language design, it's pure Verilog, but it seems there is no way to get Verilator to compile as pure Verilog.

History

#1 Updated by Wilson Snyder 9 months ago

  • Status changed from New to AskedReporter

I don't see anything immediately obviously wrong, but certainly wouldn't surprise me if there are issues.

Could you provide a self-test in verilator test_regress format showing the problem?

Also perhaps attempt a patch? V3Options::fileLanguage would be a good place to start looking.

#2 Updated by Al Grant 8 months ago

It looks like the extension-to-keywords mapping is being applied too early.

When Verilator needs to get a definition for another module, it calls V3ParseImp::parseFile() with 'modfilename' set to the bare module name, and that then calls V3PreShell::preprocOpen(), which calls V3Options::filePath() to turn the module name into a file name. But by that time the `begin_keywords line has already been stacked up on the input and the actual file extension isn't checked.

So in the above example it calls parseFile("testdo3"), generates `begin_keywords "1800-2017", and then later on testdo3.v is found and parsed as SystemVerilog.

I guess this could be fixed simply by moving the file extension check to preprocOpen(), but maybe the language determination belongs in V3Options.

#3 Updated by Wilson Snyder 8 months ago

Good debugging, that sort of fix makes sense; I'd probably pass the default file type into preprocOpen though am open to alternatives, would you like to send a fix and test?

#4 Updated by Wilson Snyder 6 months ago

  • Category set to Invoking/Options
  • Status changed from AskedReporter to Resolved
  • Assignee set to Wilson Snyder

Fixed in git towards 4.012.

#5 Updated by Wilson Snyder 6 months ago

  • Status changed from Resolved to Closed

In 4.012.

Also available in: Atom