How to apply the "3-step flow" using Questa

[jfrensch]

Hi all,

my understanding is, that the VUnit framework (always?) uses the "2-step flow" (-> vcom & vsim) of Questa, where the 'vopt' step is automatically applied during 'vsim'. Unfortunaly, I need some intermediate result of the vopt step to be able to use the 'Visuallizer' to analyze the results of a simulation:

  "vopt -debug -designfile design.bin -o tb_opt tb" 

not only provides an optimized design 'tb_opt' of the original testbench 'tb' for faster simulation, but also a database (-> design.bin) required by the 'Visualizer' to correlate the simulation results from 'tb_opt' to the design being simulated.

How can/should I apply that 3rd step (vopt) within the VUnit framework?

Many thanks for advice Jochen

[tasgomes]

This 3-step flow would also solve this issue https://github.com/VUnit/vunit/issues/877

[LarsAsplund]

Good news today is that Siemens decided to support VUnit with Questa licenses such that issues like this be solved.

[LarsAsplund]

I started to prototype on this and there is a first iteration to try out where I simply run vopt before calling vsim. I'm only using a few options in the vopt call, most importantly is probably -floatgenerics which is applied recursively on the simulation top-level. The runner_cfg generic needs to be floating since it has no default value. Is there a need to control that more selectively to enable optimization for any custom generics added to the testbench?

In this iteration, optimization is not a proper step before the simulation step. This means that vopt is called before starting the simulation of each test in a testbench. This is a problem as noted in #877.

# ** Note: (vsim-3812) Design is being optimized...
# ** Warning: (vopt-6) -- Waiting for lock by "larsa@LAPTOP-B6KUINVE, pid = 25780
# ". Lockfile is "C:/github/vunit/examples/vhdl/three_step_flow/vunit_out/modelsim/libraries/lib/_lock".
# ** Error: (vopt-2261) 'lib.opt_libtbexampletb' is already an optimized design.
# Optimization failed

This error is not suppressible so this doesn't help (I've added support for setting vopt options, both in batch mode and in gui mode)

vu.set_sim_option("modelsim.vopt_flags", ["-suppress", "2261"])

If I run the tests after one another this doesn't seem to be a concern. vopt is simply skipped if the design is already optimized:

# Incremental compilation check found no design-units have changed.

Making optimization a proper step executed before starting the simulation step is probably the solution to this.

Until then, please give it a try for your other use cases.

[LarsAsplund]

Btw, there is a small example that you can start playing with in https://github.com/VUnit/vunit/tree/three-step-flow/examples/vhdl/three_step_flow

[xkvkraoSICKAG]

I tried the three-step-flow branch and it will cause errors when running with multiple threads. The vopt call will need to be thread safe, you cannot run vopt in parallel with the same output destination apparently.

It can be solved either by:

1. Adding a thread unique suffix to each vopt output destination
2. Calling vopt directly from Python protected by a mutex/lock. There would be dictionary of locks with the top level name as the key so that vopt of a given top level test bench is only done once and not in parallel with simulation.

The benefit of 2 is that it only runs vopt once for a top level and not for every simulation which could save time.

[xkvkraoSICKAG]

I have made a prototype of solution 1. described above and it works without problems in multi threading. This is really the simplest solution to get it working as separating the vopt step and using a Python-lock on it would require a lot of restructuring of modelsim.py vs vsim_simulator_mixin.py.

PS: Apparently it still has a probability to fail when using multi-threading. It seems even when using unique vopt artifacts per thread the common files in the library is also mutated by Questa.

[xkvkraoSICKAG]

Note also that I found problems with the floatgenerics argument. It caused vopt to hang indefinitely on some of my test benches. By removing the dot from the end of -floatgenerics+top. to -floatgenerics+top it no longer hanged.

My understanding from the manual is that the trailing dot causes the generics of all lower instances to also be floating. For the purpose of VUnit it should be enough that the top level test bench generics are floating as changing the generic of a deeper instance is not required or supported. I would assume a floating top level generic coupled to a lower instance generic would also cause it to be floating anyway without the trailing dot.

[xkvkraoSICKAG]

It seems running vopt will mutate the common files in the library folder even if multiple threads use different vopt output targets. I have verified this by diffing all md5sum of all files in the library folder before and after running vopt. However just running vsim on an already created vopt folder does not seem to change any md5sum at all.

This makes me think a solution needs to ensure all vopt calls for a single library needs to happen before any simulation starts. Even between two test benches within the same library the vopt calls cannot run in parallel it seems.

PS: Another alternativ would be to just duplicate the library folders with one copy per thread. That would avoid any potential concurrency problem within the simulator itself.