Why is compiling object-oriented SystemVerilog code so slow?

0
votes

Why do commercial SystemVerilog compilers have to re-compile everything every time? In this question, I'm referring only to non-synthesizable object-oriented SystemVerilog code.

For example, SystemVerilog UVM library is used by many projects. Every time I compile, my simulator parses and compiles the UVM library, including the 95% of it that is not needed for my simulation. Why can't I have a pre-compiled version ready to go that I can use for every simulation?

In contrast, other languages do not need to compile code that has already been compiled and did not change. For example:

  • C++ compiles the .cpp files once, and then links them into the executable
  • Java compiles all files into .class files, which are dynamically loaded with a class loader during execution
1
classcompilationsystem-verilog
When compiling C++ files, you have to explicitly choose to not recompile files that were not changed by using something like Make or CMake. I'm not aware of GCC being able to do it by itself. Don't know about any other compiler, though. – Tudor Timi

1 Answers

2
votes

All of the simulators I have used provide an incremental compilation option. This means that if you change one file, only the package that includes that file and any subsequent packages/modules that import that package will be recompiled.

One of the big 3 simulator actually does provide you with a pre-compiled version of UVM (DPI included) that you can directly use. The problem with that is that it wasn't compiled with `UVM_NO_DEPRECATED. If you want to use that define, then you can compile it yourself (including DPI code and their debug features) optionally using incremental compilation (the switch was something like -incr).

Another one of the big 3 simulators I have used has incremental compilation turned on by default.