[GHDL] run.py --elaborate should not execute the design

[umarcor]

Coming from #465.

@umarcor:
If I execute python3 run.py -v --elaborate, the application (main) is executed, but GHDL is skipped, so the check fails. I would expect the binary not to be executed at all.

@kraigher:
Regarding '--elaborate' the GHDL binary must be called for elaboration to be performed.

I'm not sure about this. This might be true for the mcode backend, since elaboration and run are merged in a single stage. This is because mcode does not save a binary to disk; it is created and executed in memory. However, it should not be true for GCC and LLVM backends, where elaboration generates a binary file and run does actually execute it. Precisely, with GCC and LLVM backends ghdl -r is equivalent to calling the binary directly.

• See hints at https://ghdl.readthedocs.io/en/latest/using/QuickStartGuide.html#the-hello-world-program
• https://ghdl.readthedocs.io/en/latest/using/InvokingGHDL.html#design-building-commands
• https://ghdl.readthedocs.io/en/latest/using/Simulation.html#cmdoption-ghdl-no-run

@kraigher:
I guess in this example since you are wrapping the GHDL main function with data generation and checking you need to check the ARGV and skip data generation and checking unless the run flag was given.

I would expect --elaborate to be equivalent to GHDL's own -e, but this is not the case. VUnit assumes that elaboration is part of execution, so --elab-run is used instead of -e: https://github.com/VUnit/vunit/blob/master/vunit/ghdl_interface.py#L189. As a result: --elaborate == --elab-run --no-run.

Overall, yes, I can work around this by adding some logic to the main function. But I think it is sensible to improve VUnit, so that it is possible to use it as a build tool for GHDL design that outputs a binary.

The fix I suggest is to modify https://github.com/VUnit/vunit/blob/master/vunit/ghdl_interface.py#L227 so that --elab-run is replaced with -e, instead of adding --no-run. This will probably require to modify _get_sim_command too, in order to ignore sim arguments if elaborate_only.

[kraigher]

I am not that knowledgeable about GHDL internals but it sounds like your fix of using the -e flag might work. Does the -e flag accept setting generics via -G flag?

[umarcor]

I am not that knowledgeable about GHDL internals but it sounds like your fix of using the -e flag might work. Does the -e flag accept setting generics via -G flag?

That's a very pertinent and somehow tricky question. Generics are a runtime option, not supported for elaboration yet. Please, see:

• Add reference to -gGENERIC=value in the docs ghdl/ghdl#608 (comment)
• Add reference to -gGENERIC=value in the docs ghdl/ghdl#608 (comment)

/cc @tgingold

[kraigher]

The goal of --elaborate is to run elaboration of the design hiearchy which requires top level generics to be defined. Maybe --elab-run --no-run did not achive this either.

[umarcor]

The goal of --elaborate is to run elaboration of the design hiearchy which requires top level generics to be defined. Maybe --elab-run --no-run did not achive this either.

I think that GHDL is able to elaborate a design without knowing the actual values of the top level generics. It needs them to be defined (to have a name and a known type), but AFAIK it does not actually resolve them; all options are considered/compiled. However, this might not be valid for synthesis, so that's why @tgingold commented that it will be an elaboration option only, in the future.