Configurations: Part 1

On the page “Plugging Chips into Sockets” it was suggested (in the default binding section) that an instantiation of a design entity need not have a component declaration of the same name to be legal VHDL, providing we use a configuration to change the default binding. In the case of Plugging Chips into Sockets, the emphasis was on establishing the relationships between component declaration, design entity (particularly its entity declaration) and component instantiation.

Remember that the design entity (chip package) consists of both an entity declaration (chip pins) and architecture body (chip die). In Part 1 of Configurations, we will look at selecting one architecture from many architectures of one design entity for instantiation (essentially specifying which die goes in the package of the chip that will be plugged into the PCB to maintain our analogy) and in Part 2, we will look at choosing from amongst different design entities for instantiation (essentially specifying which chip to plug into the socket).

Configuration

A VHDL description may consist of many design entites, each with several architectures, and organized into a design hierarchy. The configuration does the job of specifying the exact set of entities and architectures used in a particular simulation or synthesis run.

A configuration does two things. Firstly, a configuration specifies the design entity used in place of each component instance (i.e., it plugs the chip into the chip socket and then the socket-chip assembly into the PCB). Secondly, a configuration specifies the architecture to be used for each design entity (i.e., which die).

Default configuration

Shown below is a minimal configuration for the top level entity MUX2. This configuration selects the architecture to be used (there is only one, STRUCTURE). By default, all components inside the architecture will be configured to use a design entity of the same name as the component (i.e., AOI), and the most recently analyzed architecture of each design entity.

We’ll tackle the concept of the most recently analyzed architecture in the next but one article in this series. Suffice to say that in this example we will take v2 to be the most recently analyzed, by virtue of the fact that we compiled the v1 version of AOI first and then compiled the v2 version of our AOI design entity a few minutes later (let’s say).

Configuration declaration

The configuration declaration is yet another one of those VHDL design units. Remember the entity declaration is a design unit as is the architecture body. In the configuration declaration, for the architecture that we want to configure, we can specify exactly which components make up the final design entity. In the example below, for the G2 instance inside our STRUCTURE architecture, we use the V1 architecture of the AOI gate. There will be absolutely no doubt as to which architecture has been chosen for simulation because we have specified v1 in the configuration. In the MUX2_default_CFG configuration, we could change the AOI architecture for simulation by simply re-compiling v1 after v2 — hardly a robust mechanism for design description! Note, that you only need to be concerned with configurations of multiple architectures when you have more than one architecture per design entity in the first place.

Default configuration of MUX2

use WORK.all;

configuration MUX2_default_CFG of MUX2 is
  for STRUCTURE
    -- Components inside STRUCTURE configured by default
    -- let’s say v2 architecture for AOI
  end for;
end MUX2_default_CFG;

Specified configuration of MUX2

use WORK.all;

configuration MUX2_specified_CFG of MUX2 is
  for STRUCTURE
    for G2 : AOI
      use entity work.AOI(v1);
      -- architecture v1 specified for AOI design entity
    end for;
  end for;
end MUX2_specified_CFG;

Once again, let’s break the VHDL code down fragment by fragment, using the specified configuration. Leaving aside the use clause for now, the first line specifies what we are configuring, configuration is a VHDL keyword and is followed by the name we wish to give the configuration. After the of keyword we specify the design entity we are configuring; is is also a keyword. Bracketed with this first line is the last end configuration_name line. Hence,

configuration MUX2_specified_CFG of MUX2 is
  -- block configuration
end MUX2_specified_CFG;

Configurations usually consist of nested configuration items, bracketed with end for; statements. The first item is the architecture specification,

  for architecture_name
  -- thus,  for STRUCTURE

the second is the instance specification,

  for instance_label : component_name
  -- thus,  for G2 : AOI

and finally the binding indication,

  use entity library_name.entity_name(architecture_name)
  -- thus,  use entity work.AOI(v1);

Now, what about that use clause? Let’s say the AOI design entity is compiled into the working library WORK by default. Thus in order for the component_name to be visible we need a use clause, hence use WORK.all; is required.

Doulos Training Courses
Return to Hardware Engineer’s Guide Contents

Doulos Home Page

We welcome your e-mail comments. Please contact us at: webmaster@doulos.co.uk