The concept of configuration in VHDL allows an entity to have multiple associated architectures. The role of the configuration declaration is to define a unique system description from the various design units.
In this case, the generation of a configuration declaration is very simple. The only information which the configuration has to include is the choice of one architecture for the given entity. This binding is established by naming the entity architecture pair as follows:
Syntax:
configuration configuration_name of entity_name is
for architecture_name
end for;
end configuration_name;
The configuration_name can be any name. It is allowed to have
more than one configuration for one entity such that for every
architecture an appropriate configuration exists.
For the behavioral descriptions of the full adder two configurations are specified:
Example:
configuration CFG_ONE of FULLADDER is
for CONCURRENT
end for;
end CFG_ONE;
configuration CFG_TWO of FULLADDER is
for SEQUENTIAL
end for;
end CFG_TWO;
The first configuration CFG_ONE binds the concurrent behavioral description CONCURRENT to the entity FULLADDER. The second configuration CFG_TWO selects the sequential behavioral description SEQUENTIAL.
If the configuration binds a structural description to an entity then further information about the instantiated components is required. Due to the fact that the name of a component in the component declaration needs not be the same as the entity name of the instantiated component, their binding must be done by the configuration. Furthermore, the binding of the component's entity and architecture must be established by the configuration.
The following example illustrates the use of configuration statements
in a structural description. It refers to the architecture STRUCTURAL of the full-adder circuit in Section
2.3.3, page .
Assuming that the entities HALFADDER and XOR2D1 exist for
the instantiated components HA and XOR respectively, and
that the architecture CONCURRENT is provided for each of these
entities, then the configuration may look like the following:
Example:
configuration THREE of FULLADDER is
for STRUCTURAL
for INST_HA1, INST_HA2: HA
use entity WORK.HALFADDER(CONCURRENT);
end for;
for INST_XOR: XOR
use entity WORK.XOR2D1(CONCURRENT);
end for;
end for;
end THREE;
The first and second line contain the configuration name and the binding of the entity and architecture. Since the architecture STRUCTURAL is a structural description, the components HA and XOR have to be configured. This is done by the two inner for-loops. The first loop specifies that for the two instances INST_HA1 and INST_HA2 of the component HA an entity HALFADDER with its architecture CONCURRENT has to be used. In addition, it is stated that the HALFADDER is taken from the library WORK (more about libraries in Section 2.7).
In general, a configuration declaration belonging to an architecture with instantiated components is of the form:
Syntax:
configuration configuration_name of entity_name is
for architecture_name
for label|others|all: comp_name
use entity [lib_name.]comp_entity_name(comp_arch_name) |
use configuration [lib_name.]comp_configuration_name
[generic map (...)]
[port map (...)] ;
end for;
...
end for;
end configuration_name;
If there exists a configuration for the entity of the instantiated component, then the binding of the entity and architecture is already done by this configuration. Therefore, it is possible to refer to the configuration of the submodule by using the statement use configuration ... instead of defining the entity-architecture pair explicitly. Furthermore, the mapping of generic and port names between the component declaration (so-called locals)and the entity declaration of the submodule (so-called formals)can be done by the generic map and port map statements. This can be useful if the order of the ports or generics is different or rearranging the order on purpose or locals and formals are different.