Configuration declarations

The utility of configurations is the ability to create multiple designs from the same entity/architecture with different configurations. Let's look at an example use of a configuration. Consider the following design of a full adder with two architectures. The architecture monitored contains assertions which check that the inputs satisfy some minimum hold time requirements. The normal architecture is the same without these assertions. The test entity and test_arch provides a test design that uses the full adder that can be configured with the configuration declarations. Notice that the configuration specification indicates that the component fa is open. This means the binding of that component will be specified in a configuration declaration. Since it is open, that also means we can not simulate test/test_arch directly because fa needs to be bound to some design unit in order to simulate it. However, we can use the configuration declaration to create a configured design unit, which can be simulated.

Consider first, the following configuration declaration. The first line gives a name to the configuration (test_normal), and indicates the entity that is being configured (test). The first thing inside the configuration declaration is called a block configuration. It begins with the keyword for and ends with end for;. The first line of the block configuration indicates the name of the architecture that is being configured (test_arch). Inside the block configuration is a list of one or more component configurations. The component configuration also begins with the keyword for and ends with end for;. The first line specifies the instances being configured in this case, the fa_1 instance of the fa component. Inside the component configuration is a binding specification just like that for component specifications (section ).

The result of this first example is a configuration named test_normal that is the same as the test/test_arch design where the fa_1 has been configured as shown in the configuration declaration. That is fa_1 is implemented by the fa/normal design. Now suppose we wanted a different version of test/test_arch that is configured differently. All we need to do is create a new configuration declaration.

This is an example of a second configuration of the test/test_arch design. It specifies that we want to bind the fa_1 instance to the fa/monitored design and configures the value of the min_hold generic of fa to 5ns. Now we have two configurations of the same design that can be used as the implementation of a component with an instantiation like or simulated. See section for information on how to use the linker to simulate configurations.

The formal syntax for the configuration declaration is given by the following rules:

component-configuration : 
    FOR instantiation-list ":" name(component)
      binding-specification ";"
    END FOR ";"
block-configuration :
    FOR name(architecture)
      { component-configuration }
    END FOR ";"
configuration-declaration :
    CONFIGURATION name OF name(entity) IS
      block-configuration
    END [CONFIGURATION] [name] ";"