I want to build rocket chip rtl. I modified the build.sc of rocke chip hope the firtool would generate verilog instead of systemverilog, but it failed. What should I do to generate verilog instead of systemverilog. It’s so annoying. My project is based on verilog, so I need verilog. It feels like firtool seems not to be that easy to use, it’s like a toy rather than a practical and useful tool. I spent so much time to figure out how to use and how to generate the exact format that I want. Maybe I’m just so stupid to figure it out. Could anyone give me some hint please, I’m going mad lol.
Can you clarify more on exactly what constructs you have in your output which you would not like to see?
Chisel, pedantically, has constructs which cannot be represented by normal Verilog (95 or 2001). Specifically, Chisel has assert, assume, and cover APIs. Those APIs map to SystemVerilog asserts/assumes/covers. This immediately means that Chisel cannot be mapped to Verilog (unless we invent ways to representing these in Verilog).
We’ve made a conscious decision to produce pretty basic “SystemVerilog” that is supported by proprietary and open source tools. However, there’s a tension as to do anything productive with hardware you likely can’t get by with just Verilog-95 or Verilog-2001.
Most of the available lowering options are documented here (Verilog and SystemVerilog Generation - CIRCT) with suggestions on which options to use for which tools you are targeting. If there is something that you are missing please let us know!
Because my rtl environment is based on verilog, all the systemverilog related grammar is expected not to be seen. For example, there are many “logic” declaration in the file, but I think I can only cancel “automatic logic”, I don’t know how to avoid generating “logic” declaration. It is OK if the file is systemverilog but all the grammar is verilog. I don’t know if there are other systemverilog stuff in the file, because I’m not familiar with systemverilog and VCS only report this one message as shown below.
And I’m a little confused. In April this year, I built Rocket Chip core, and I got verilog code.
Now I generate again, but I can only get systemverilog
It seems it updates frequently without considering compatibility and consistency? In April the tool was called firrtl maybe, and now it’s firtool? I’m not familiar with the Chisel stuff, I just want to get a Verilog IP core
If you are using VCS, is it possible to just use system verilog feature? (by adding -sverilog to compiler option). Currently there is no option to emit logic as reg/wire so maybe we can provide an option if there is no way.
It works. Thank you. But I still want to generate only verilog codes.
I’m glad it works! Do you mind if you could explain why you want to generate “pure” verilog? Even though CIRCT emits SystemVerilog, we only use basic subset of SystemVerilog so that most of EDA tools can consume the generate verilog. There are also a lot of LoweringOptions by which you can control emission styles.
I think in the industry, most companies use verilog to develop their hardware, and systemverilog is mainly used in UVM or something? Our developing env is all based on verilog, including the sim env, syn env, lint env etc. So if the IP core is written in systemverilog, it’s not compatible with the current environment, and it is not suitable to change the whole environment because it may affect other members, so you can only modify it locally and temporarily.
I think it’s more nuanced than Verilog vs. System Verilog. Each vendor has a suite of tools, which all implement parts of the Verilog and potentially System Verilog spec, sometimes in frustratingly contradictory ways. It really comes down to exactly what constructs from the spec you want to use with your specific tool (e.g., VCS with or without --sverilog).
CIRCT and firtool produce output that is practically useful in real vendor tools used in industry, and the output is used successfully in real production flows. But to support this, we don’t have a big switch that says “Verilog or System Verilog”, since the tools’ support is not that simple. As mentioned before, CIRCT’s output tends to use constructs that are supported in both Verilog and System Verilog specs, and we have the LoweringOptions to control this.
For example, you should be able to use disallowLocalVariables=true to avoid emitting logic, so I’m a little surprised to see logic in your output. It may be a bug, or it may be the case that we do require the -sverilog flag with VCS. We have a guide for what LoweringOptions are recommended for each tool, and we could add a section about VCS to make this explicit: Verilog and SystemVerilog Generation - CIRCT. VCS is certainly a supported backend tool.
Well, I understand that you can’t just add a option of emitting verilog or systemverilog in the tool just because a user mentioned it, maybe it’s not an easy work to do. I’m just saying and hopelessly expecting maybe you could consider it…
BTW, based on my actual use of the tool, disallowLocalVariables can only avoid emitting “automatic logic” .
The feedback is welcome, but for the reasons we mentioned above, we won’t have just one option; it is really a suite of options to toggle with respect to their defaults. What I’m taking away from this discussion is we should add to the documentation in our Verilog and SystemVerilog Generation page to clearly document what options to set if you want the most basic Verilog CIRCT can emit.