next up previous contents
Next: 9.4 Generics Up: 9. Structural Descriptions Previous: 9.2 Use of Packages

9.3 Configurations

One of the useful features in VHDL is that it allows different architecture realizations of an entity. This enables the design process to be more efficient through the following steps:


- Step-by-step top-down refinement (from the black-box behavior down to the structure);
- Investigation of alternatives;
- Support of versions.

In structural descriptions, configurations assign specific architectures to the components. A configuration specification may be employed in two places:

1. within an architecture:
in form of a configuration assignment.

Syntax:
for label: entity_name
        use entity
[lib_name.]entity_name(architecture_name);
If an explicit configuration is not specified, the last (with respect to time) analyzed architecture, known as a null configuration, is used.

Example:
entity XR2 is                     entity
declaration
  port (X, Y: in bit; Z: out bit);
end XR2;

architecture SLOW of XR2 is   
the first architecture
begin
  Z <= X xor Y after 1.0 ns;
end SLOW;

architecture FAST of XR2 is   
alternative architecture
begin
  Z <= X xor Y after 0.5 ns;
end FAST;

-- use of XR2 in COMPARE --
architecture U of COMPARE is
  for U0: XR2 use entity WORK.XR2(FAST);
                               
configuration for XR2
  signal I: bit;
begin
  U0: XR2 port map (A, B, I);   
explicit configuration
  U1: INV port map (I, C);    
implicit configuration
end U;

2. outside an architecture:
Different architectures may be selected with a configuration statement. In this case a configuration is treated as a separate design unit which can be analyzed and simulated. Following arrangements using the configuration statement are used:
Architecture -- Entity

When an entity has several architectures defined for it, the desired architecture to be used in the simulation of a design can be selected.

Syntax:
configuration configuration_name of entity_name is
  for architecture_name
  end for;
end configuration_name;
The example shows two configurations, CFG_ONE and CFG_TWO, describing the XOR gate. For the simulation of XOR the desired architecture (FAST or SLOW) may be chosen.

Example:
configuration CFG_ONE of XR2 is    ONE
selects FAST
  for FAST
  end for;
end CFG_ONE;

configuration CFG_TWO of XR2 is    TWO
selects SLOW
  for SLOW
  end for;
end CFG_TWO;

Architecture -- Component

In this case, the selection of an appropriate architecture is made during the description of the hierarchy. When a design is structurally described ( $ \Rightarrow$ Hierarchy) and for the instantiated components there are several corresponding architectures, a configuration statement may be used to specify which architecture should be associated with a particular instantiation.

Syntax:
configuration configuration_name of entity_name is
  for architecture_name
    for label
|others|all: comp_entity_name use
      entity
[lib_name.]comp_entity_name(comp_arch_name); |
      configuration
[lib_name.]configuration_name;
    end for;
    ...
  end for;
  ...
end configuration_name;
In the following example, MCOMP is a circuit where different instances of XR2 and INV are used.

Example:
configuration CFG_TRY1 of MCOMP is
  for STRUCT
    for U0: XR2 use entity WORK.XR2(FAST);
    end for;
    
    
-- or --
    for U0: XR2 use configuration WORK.ONE;
    end for;
    
    for others: XR2 use configuration WORK.TWO;
    end for;
    
    for all: INV use configuration WORK.INV(FAST);
    end for;
  end for;
end CFG_TRY1;
Note:
Most of the VHDL simulators allow simulation of an entity, which instantiates components, only through the configuration. Therefore, it is necessary to include a configuration statement also in those cases, where for each component of a (hierarchical) design there exist only one architecture.

This is normally the case when a test environment references the actual design during the simulation. It is sufficient to include the default configuration statement.

Syntax:
configuration configuration_name of entity_name is
  for architecture_name
  end for;
end configuration_name;

Configurations also allow to map ports of the component declaration (locals) to the ports of the underlying design (formals). Normally, the port declaration in the component declaration is a copy of the port declaration in the submoduls' entity. In this case a port map in the configuration is not required. However, in some cases it is more efficient to map ports in the configuration section.


next up previous contents
Next: 9.4 Generics Up: 9. Structural Descriptions Previous: 9.2 Use of Packages
Richard Geissler
1998-10-07