Add dependency scanning of configurations

[imd1]

When I use the python script method for a VHDL testbench, sometimes it compiles, sometimes it errors, both starting from the same clean and identical directory conditions!

Any clues why?

[kraigher]

Could you provide some more details such as command line output? run.py contents?

[kraigher]

Also which commit on the master branch are you using?

[imd1]

I'm using release 0.14.0
I don't have access to the code a the moment so I cannot post anything in detail, but in general terms I have modules of VHDL and a standard looking run.py from the examples, and sometimes itcompiles, runs and the tests pass, and changing nothing and starting from exactly the same conditions, the code fails to compile due to not finding items in the library, as if the code is being compiled in the wrong order.
I was wondering how the python could randomly behave differently with the same input environment? Is a race condition possible?

[kraigher]

Could you try 0.15.0 which I just added.
Also could you give me the result of running run.py with --log-level=debug both after --clean as well as after it worked and after it failed.

[imd1]

When I have access to the code next week, I will follow your instructions

[imd1]

I have made some progress on this.
I've upgraded to 0.18.0 with no effect.
The intermittent behaviour is due to an incomplete dependency tree i.e. the compilation order is not fully defined, so sometimes the order is correct by chance, other times not.
The dependency problem involves VHDL containing configurations - I wonder whether VUnit supports configurations fully?
The work around is to refactor the use of configurations in order to ensure a correct compilation order.
I can submit some configuration patterns that I've had to change if you want

[kraigher]

The dependency scanner does not yet support configurations. If you post examples spanning your different usage of configurations I can add support for it.

[imd1]

I cannot easily post specific examples, but all forms of configuration are used in my code, namely:

1. Configuration declaration (primary library unit) - whole hierarchy using "use entity" clauses.
2. As 1, except using a tree of configurations, each one corresponding to a point in the hierarchy.
3. Configuration specification (used in architecture) - using a "use entity" clause
4. As 3, except using "use configuration" clause

I hope that helps

[imd1]

An alternative approach would be for VUnit running a --clean build to have an additional option to create a compile order based on the order of library additions. I currently perform clean builds on a Jenkins box and am retro-fitting VUnit to unit tests based on .do scripts with a complete and ordered set of vcom/vlib/vmap statements. Allowing VUnit to mimic this would be a great feature and would mean that dependency scanning issues are not relevant.

[kraigher]

@imd1 I will prioritize adding support for configurations. A second feature request issue candidate would be to allow the user to manually specify dependencies. Having support for configurations would make that unnecessary though.

Would you still need support for manual compile order if the dependency scanner had support for configurations? A manual compile order as you suggest does not work as well with incremental compilation as having manual dependencies would. With a manual compile order VUnit's best shot at incremental compilation would be to re-compile every file in the list below the highest file that changed which would cause a lot of unnecessary re-compilation.

[imd1]

My compile order suggestion was an alternative to configuration scanning - happy if only the scanner is upgraded. Agree with your comments.

[kraigher]

@imd1 I have added support for scanning "configuration declarations" and "block configurations":

configuration declarations

-- Injects dependency between 'cfg' and entity 'ent'
-- as well as all architectures of 'ent'.
configuration cfg of ent is
  ...
end configuration;

block configurations:

-- Injects dependency on this file with lib.ent 
for foo : bar use entity lib.ent

-- Injects dependency on this file with lib.ent and lib.ent.a 
-- (.a needed by GHDL)
for foo : bar use entity lib.ent(a)

-- Injects dependency on this file with lib.cfg 
for foo : bar use configuration lib.cfg

Could you try it and report back? I will wait on closing this issue until you report sucess.

[imd1]

Thank you for the prompt response. Just to clarify, do you think the upgrade will support more complicated combinations, for example?:

--injects dependency between cfg with lib.ent (all architectures) AND lib.ent2
configuration cfg of ent is
..
for foo : bar use entity lib.ent2;
..
end configuration

[kraigher]

@imd1 yes it will handle that case as well.

[imd1]

Is there a new release to try?

[kraigher]

Just use the latest master to try it. I make a release after you verified it works.

[kraigher]

@imd1 did the dependency scanner update solve your problem?

[imd1]

I've just completed Jenkins soak testing on the 3 modules I've chosen to prototype VUnit with, and they always pass unit tests, both individually and as a group, so I'm happy

I have a number of other modules waiting for a VUnit upgrade that use configurations more extensively, but it will take time to do this, so I suggest closing this issue and creating a new release

[kraigher]

I just created a new release including this