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

Compiling verilated code with MSVC #209

Closed
veripoolbot opened this issue Jan 20, 2010 · 6 comments
Closed

Compiling verilated code with MSVC #209

veripoolbot opened this issue Jan 20, 2010 · 6 comments
Assignees
Labels
area: configure/compiling Issue involves configuring or compilating Verilator itself resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Amir Gonnen
Original Redmine Issue: 209 from https://www.veripool.org
Original Date: 2010-01-20
Original Assignee: Wilson Snyder (@wsnyder)


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

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-20T11:51:32Z


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.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Amir Gonnen
Original Date: 2010-01-20T15:10:41Z


  • 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.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-20T15:42:38Z


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.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Amir Gonnen
Original Date: 2010-01-20T16:13:14Z


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).

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-01-24T12:57:26Z


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.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-02-07T12:42:23Z


In 3.800.

@veripoolbot veripoolbot added area: configure/compiling Issue involves configuring or compilating Verilator itself resolution: fixed Closed; fixed labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: configure/compiling Issue involves configuring or compilating Verilator itself resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants