VHDL circular dependency when an architecture maps to another architecture using the same entity

[rugebiker]

Hi,
I have an error of circular dependency when two architectures use the same entity, and one of them maps to the other one. Attached is a small example testbench where I get this error.

Description of files:
run.py : Simple, just adds files and launches the test
tb_circular_dependency : Empty test, just for example. Maps to entity(architecture1).
entity_architecture1.vhd : This file contains an entity and an architecture of that entity.
architecture2.vhd : This file contains a second architecture of the same entity provided in the previous mentioned file.
architecture1 (the one on the first file) contains a direct declaration of a component which is entity(architecture2).

The error I get is:

  ERROR - Found circular dependency:
~/Projects/circular_dependency/entity_architecture1.vhd ->
~/Projects/circular_dependency/architecture2.vhd ->
~/Projects/circular_dependency/entity_architecture1.vhd

Expected behaviour: There is no real VHDL circular dependency here. Both ModelSim (standalone simulation) and Vivado (Simulation and Synthesis) work correctly.

Example project:
circular_dependency.tar.gz
just run:
python run.py

[eine]

I think there is a circular dependecy between files, indeed. File entity_architecture1.vhd requires architecture2.vhd to be analyzed first, and viceversa. You might argue that VUnit could identify the units in the files, and try to break the circle by considering entity_architecture1.vhd to be two separate units/files. But VUnit does not split/merge/reorganize the VHDL code. Doing so would require to keep track of which original files were split.

The expected structure is:

• Split entity_architecture1.vhd to entity.vhd and architecture1.vhd.
• Or, interchange architectures, so you get entity_architecture2.vhd and architecture1.vhd.

Any of these approaches should avoid the error.

[go2sh]

That might not true. There is no real circular dependency. The architecture of the instantiation is only evaluated during elaboration, I guess.

[eine]

That might not true. There is no real circular dependency. The architecture of the instantiation is only evaluated during elaboration, I guess.

You are correct, from a VHDL point of view. Precisely, none of the simulators fail. @rugebiker tested it with ModelSim and Vivado, and I tested it with GHDL (although I had to fix tb_circular_dependecy.vhd). Thus, my previous comment is about how VUnit handles dependecy, which is "per file", not "per VHDL unit".

[go2sh]

AFAIK vunit uses the dependency scanner to generate the compile order. In the presented case, the compile order can be solved.

• entity_architecture1.vhd
• architecture2.vhd
• tb_circular_dependency.vhd

[eine]

See https://github.com/VUnit/vunit/blob/master/vunit/dependency_graph.py#L65-L71. I think that it raises an exception as soon as it visits a node twice, where a node is a file.

[go2sh]

Yes, the problematic code is also in here. I need to think about the implications of the problem on the code. Maybe the dependency graph has to be rewritten in such cases or the generation of the file list.
Not trivial at all.

[rugebiker]

Indeed. Maybe it is an idea to completely split the entities and architectures into different trees, but I can imagine it would be a lot of redesign.

[kraigher]

Is it really legal for entity_architecture1.vhd to reference architecture2 before it has been analyzed?
Normally when you reference an architecture explicitly we have seen that you need to compile it first which is why we add a dependency when an entity instantiation references an architecture explicitly. Maybe some simulators handle the resolving of this at the elaboration stage and some in the compile stage?

[eine]

Maybe some simulators handle the resolving of this at the elaboration stage and some in the compile stage?

I am not sure about what you mean with 'compile stage'. I'd say, correct me if not, that 'compile' is the term used by some vendors (e.g. Mentor's vcom) as a common entrypoint for 'analysis', 'elaboration', or 'both of them'. In ModelSim/QuestaSim's manual we find:

•-bindAtCompile(optional) Forces ModelSim to perform default binding at compile time rather than at load time. Refer to “Default Binding” for more information. You can change the permanent default by editing the BindAtCompile variable in the modelsim.ini.
•-bindAtLoad(optional) Forces ModelSim to perform default binding at load time rather than at compile time. (Default)

Hence, vcom -bindAtLoad (which is the default) does not require arch2 to be analyzed/compiled before entity_arch1. However, vcom -bindAtCompile would fail. Might the issues you remember be related to bindAtCompile being set (in)directly in some environments?

Regarding GHDL, I believe you can analize sources in any order, and it will generate an internal index. Then, during elaboration, it will find and bind all the instances.

[kraigher]

Maybe we can remove this dependency. I just vaguely remember that we added the dependency due to a problem we found. Maybe it was when an architecture is referenced explicitly in a configuration.