[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
  Schedule::Load
  SVN::S4
  Synopsys-modes
  SystemPerl
  Verilog-Pli
  Voneline
  Vregs
General Info
  Papers

Issue #209

Compiling verilated code with MSVC

Added by Amir Gonnen over 2 years ago. Updated over 2 years ago.

Status:Closed Start date:01/20/2010
Priority:Normal Due date:
Assignee:Wilson Snyder % Done:

0%
Category:Configure/Make/Compiling
Target version:-

Description

verilator-3.720, Visual Studio 2003. Compiled verilator with MinGW, and ran: verilator.exe -Wno-lint -Wno-UNOPTFLAT -language 1364-2001 --trace --compiler msvc --cc top.v

There are some small issues that were easy to solve:
  • verilated.cpp line 385 changed string msg = string("%%Error: Unknown _vl_vsformat code: ")+pos[0]+"\n"; to string msg = string("%%Error: Unknown _vl_vsformat code: ").append(1,pos[0]).append("\n");
  • SpTraceVcdC.cpp line 141 removed O_NONBLOCK which is undefined on MSVC
  • SpCommon.h: <stdint.h> is missing on MSVC
  • uint32_t is defined as unsigned int on verilatedos.h but as unsigned long in SpCommon.h
However there are two bigger issues:
  • On my module there is a signal called "int" (that's legal on Verilog 2001). This conflicts with the C native type int. A simple solution could be perfixing signal names to avoid conflict.
  • Apperantly there's a bug in MSVC related to a large number of class members with very long names. On the top module, all signals apprear (VL_SIG macros) with very long names related to the signal depth (with __DOT__ instead of "."). When trying to compile top.cpp I get a false "undeclared identifier" error reported on some very long signals. A possible solution could be defining sub structs for each hierarchy level instead of using DOT. Another solution could be truncating these names somehow and adding some unique suffix.

In the meantime I was able to work around these two issues by modifying the Verilog files and the cpp files generated by Verilator. However, it would be easier and cleaner having these problem fixed in Verilator.

Thanks,

Amir

History

#1
Updated by Wilson Snyder over 2 years ago

The "int" conflicts should only be reported on top level ports, not internal nets. I'm reluctant to rename top ports as people use scripts that assume one-to-one naming, and "int" has been reserved now for 5 years.

Other users have used MSVC++, but I think they are using newer versions. Can you try a more recent release, esp for the long identifiers? I'm sure there will still be some issues I'll be happy to fix.

#2
Updated by Amir Gonnen over 2 years ago

  • The "int" problem in the general case is every C/C++ reserved word. What if someone used "double" or "for" as a port name? Does it make sense to limit names on the top level because they conflict with some C/C++ reserved word?
  • The long identifiers problem was not reproduced when compiling with MSVC 2008. In my case I need the verilated code to compile as part of a very large project based on MSVC 2003. In the future we plan to migrate to a more recent version but currently we are stuck with MSVC 2003.
  • There are tons of warnings, mainly related to type conversions. Some examples are C4146, C4244, C4319, C4800.

#3
Updated by Wilson Snyder over 2 years ago

Well "double" is also SystemVerilog reserved, and "for" a Verilog keyword, but anyhow I think I might have been confused as to what you needed. Assuming you are getting the SYMRSVDWORD error message, you can just turn off that error and it should work - it'll rename the ports.

For the compiler issues, please checkout the git version (as there's lots of changes since the last release - a major release is coming in a week) and report what needs changing, or even better attempt fixing them and attach the "git diff origin/master" output.

Since recent MSVC versions work OK, I unfortunately don't have the time to fix the long identifiers, especially as it'll break some warning messages (verilator assumes you can map the long symbol back to the original name). However if you'd like to make a fix for your project, I'll take the patch back. V3Name is the place to do it; make a map<> to rename signal over a specified length to something short. Then add code to V3Options around line 778 when given "--compiler msvc-2003" to set that maximum length to whatever crazy limits the MSVC people came up with. If you need more help let me know.

#4
Updated by Amir Gonnen over 2 years ago

Ok, Thanks. I'll try to find time in the future to make the fix for the long names. In the meanwhile I was able to work around these problems (by processing the generated H file and adding a #define for each long name into a short name).

#5
Updated by Wilson Snyder over 2 years ago

  • Category set to Configure/Make/Compiling
  • Status changed from New to Resolved
  • Assignee set to Wilson Snyder

The git versions of SystemPerl and Verilator output now contain your fixes plus some to compile on MSVC++ 2008. If you have patches you want for an earlier version send them along.

#6
Updated by Wilson Snyder over 2 years ago

  • Status changed from Resolved to Closed

In 3.800.

Also available in: Atom