Compiling verilated code with MSVC
|Assignee:||Wilson Snyder||% Done:|
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
- verilated.cpp line 385 changed
string msg = string("%%Error: Unknown _vl_vsformat code: ")+pos+"\n";to
string msg = string("%%Error: Unknown _vl_vsformat code: ").append(1,pos).append("\n");
- SpTraceVcdC.cpp line 141 removed
O_NONBLOCKwhich is undefined on MSVC
<stdint.h>is missing on MSVC
uint32_tis defined as
unsigned inton verilatedos.h but as
unsigned longin SpCommon.h
- 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_SIGmacros) 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.
#1 Updated by Wilson Snyder almost 4 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 almost 4 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 almost 4 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.
#5 Updated by Wilson Snyder almost 4 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.