Riviera: Don't compile every file into a separate compilation unit about edalize HOT 7 CLOSED

This is the way the ModelSim backend works too. I hadn't noticed until I started working on the SweRV core where I had to introduce a hack to get around this. I think it would be good to offer support for multi compilation units, but I'm not sure about all the details. One particular example is how to handle VHDL and mixed-language designs. Perhaps that is the only issue and can be easily solved but I don't know enough at this point. A compromise could perhaps be to introduce a backend option for riviera and modelsim.

I wonder a bit also about the examples you brought up with defines. I haven't used Riviera all that much but from memory it would pick up defines from `include files just fine. Is what you describe only an issue when you define things directly in the source files?

from edalize.

This came up in lowRISC/ibex#566. Effectively, we did the following:

• A file prim_assert.sv contains multiple defines.
• This file is passed to the tool as a normal SV file (not using is_include_file)

Now:

• If we compile everything into one compilation unit: Since all cores depend on the core providing prim_assert.sv, this file is compiled first and defines are available without any include prim_assert.sv statements in the source code.
• If we don't compile everything into one compilation unit, all of that doesn't work.

I'm not saying that what we had was "correct" or "solid", so we're fixing that in our source code. But we should still try to make edalize behave the same for all simulators, and that means: decide for a behavior (separate compilation units, or a single one), and implement that behavior consistently.

from edalize.

LRM (IEEE1800-2017) defines that 2 types of compilation unit scope (CUS) need to be supported:

• one CUS per compiled file
• one CUS per compilation command (that is vlog/alog for RVR)
  In edalize for RVR now each file is compiled separately - bunch of vlog command are generated.
  Each vlog creates separate CUS - no chance too see defines from previous vlog (unless you include it in all files)
  How to split files into separate compilation is interesting question. If you compile all together I think that you will avoid many issues. On the other hand separate compilation can save you time when recompiling and allow to split project into libraries.

from edalize.

Hi all,

I was looking at adding support for this in the modelsim backend a couple of days ago as I had a project that was built assuming mfcu mode. Pretty much the same thing as @imphil reported with some types and defines that weren't explicitly included in the files that needed them. I didn't manage to get it working properly though. I can't remember the details now but there were some things that needed to be taken into consideration. So yes, we should definitely look at how to implement this for the riviera and modelsim backends, but if it's just a global defines file, perhaps the following hack can work in the meantime. It is written for modelsim but since riviera is intentionally very similar it might work there too

1. Use copyto : mydefines.sv to put the global include files in a known place relative to the work root
2. Add -mfcu mydefines.sv to vlog_options to forcibly build each (system)verilog file with the defines file included.

Look at the hack I mentioned earlier for SweRVolf

from edalize.

In Riviera Single Vlog command invocation Compilation Unit (SVCU) is default. I suppose that this (more or less) is what questa has under -mfcu. So we can say that we have mfcu already turn on for RVR.
In SVCU visibility of defines and other CU items depends on how you divide files into compilation command invocation. So you can include header once per vlog command.
In single fie compilation unit (SFCU) it does not matter how files are divided into compilation commands - CU items always will be visible per file. You need to include header in all files for which it is needed.

Have you looked at pull request #99? Can it be merged in? Both case (having all files compiled in single vlog command invocation or all files in separate invocation) have pros and cons. Adding a switch allowing user to choose the one he wants is usefull feature, I would say that common compilation is ussually safest choice (so it PR it is default).
In future you can even go one step further and allow to define files sets which are compiled in single compilation command.

from edalize.

I believe we can close this one now, with the added option for both compilation scopes in Riviera-PRO. Please reopen if I'm wrong

from edalize.

You are right. I was about to ask you to close this one.
Thank you for merging this.

from edalize.