Feature Request: Compile Files in Chunks

[bwabbersen]

I am currently up against a fatal error when using VUnit in conjunction with Riviera_Pro (2024.10). It's definitely their fault and they have promised a patch. However, it has exposed a potential hole in VUnit functionality that could be important for other reasons.

To quickly summarize (feel free to skip this part if only interested in the actual feature request), apparently you trigger a nondescript fatal error if you call a function within a systemverilog interface. This apparently only happens if the function takes input arguments. This also only happens on the Linux version. We were also able to show that the problem goes away if you pass both the interface definition file and the calling file to the Riviera compiler in a single command. It seems that VUnit always sends the files to be compiled one at a time.

So the feature request would be some way to force certain files to be compiled together in the same command. A quick search through VUnit docs didn't show this as being an option, but I'm no expert so feel free to chime in if this already exists somewhere. I'm envisioning this going one of two ways:

1. You could do this at the library level. So all the files in a library get sent together in the same compile command. This would put some restrictions on compile options. You'd have to restrict yourself to handle options at the library level, and no file-specific options. This could be self-enforced, and VUnit could just pile any options that have been placed on files into a single set and do some dumb overriding where conflicts exist.

2. You could implement something similar to the add_dependency_on() method. So some new kind of dependency relationship where any files grouped with this new notional command have to be compiled together. Same options handling as described above, just dumb set unity and overrides.

I realize this kind of flies in the face of proper dependency hierarchy. Sadly, I've been seeing this pop up more and more in the verification world. For example, many UVM cookbooks now have examples which explicitly include circular dependencies. The only way to get them to work is to compile the offending files together in a single command. While mixing UVM and VUnit is still not exactly mainstream, it's how I prefer to do things. Of course people shouldn't be creating these circular dependency problems in the first place, but regardless it would be nice to have a workaround in VUnit for cases where untangling the source files is intractable. And to clarify, my particular problem with Riviera is not a true circular dependency problem, just a limitation of the vendor tools.

[LarsAsplund]

This has been discussed a number of times. Dealing with circular dependencies is one use case. Speeding up clean compilations is another. What I have been thinking about is to introduce a compile/file group concept. There will probably some sort of hard/soft attribute on these groups. Hard group files will always be compiled together while soft groups is a way to improve compilation performance when many files need compilation. When few files need to be compile, incremental compilation performs better and the soft groups would dissolve.