When using direct instantiation, allow `architecture_identifier` to be set to `open` to allow a configuation to specify the architecture.
Is your capability/feature request related to a problem?
Currently, when using configuration
, the entire path of the configuration must use component declarations to allow setting of the architecture. This may be fine for single use items, but when you want to change an architecture of an entity inside a dut, that might be a long list of component declarations that require components.
For example - lets say I have a DUT with two entity instances inside it - E1 and E2. If I want to swap out E1 with a simulation model for a given test, I now need to maintain a component for both DUT (in the testbench) and E1 (inside the DUT) purely to allow the swapping of architectures for E1.
(note: I cannot work out if in VHDL 2019 you can use external names in a configuration declaration to get directly to a buried component instantiation - this is not possible in VHDL 2008)
So, currently, the following is required:
configuration test1 of tb is
for tb_arch
for dut_inst : dut
for e1_i : e1
use entity lib.e1(sim_model_arch);
end for;
end for;
end for;
end configuration;
and the maintenance of two components feels burdensome
Describe the solution you'd like
When using direct instantiation, allow the optional (open) that would then allow a configuration to specify the archtiecture. This should be the default if it is not specified. This way the user can still specify where the entity comes from, but allows an easy swap of architectures without maintaining all the components. The compiler would still specify a default binding for the instantiation, as per now, where it uses the last compiled architecture for the entity unless it is overriden if the user does not specify a configuration. So therefor, I could do the following:
architecture dut_arch of dut is
begin
e1_i : entity lib.e1(open)
generic map (...)
port map (...);
end architecture;
and also if external names are allowed in a configuration (which I think they might be)
configuration test1 of tb is
for tb_arch
for dut.e1_i : lib.e1
use architecture lib.e1(sim_model_arch);
end for;
end for;
end configuration