Configurations

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.

Let's review default binding before we go any further. In default binding, the chip socket (component declaration) carries a chip (design entity) of the same name (say, AOI) as we've already seen. The chip is inserted into the socket courtesy of a component instantiation and a configuration declaration. If we omit the configuration or if we use a default configuration, the socket and chip must have the same name.

If we want to choose a particular die (architecture) for our chip, we must specify the architecture in the configuration.
Now. Suppose we want to create a general-purpose socket and at some later time, we want to specify which chip will be plugged into the socket. To do this requires a late-binding configuration declaration.

 

Late binding
 

The syntax is really no different than before except that we choose a different chip name for the bound design entity, it does not have to be the same as the component declaration. Let us suppose that a spec. change (happens too often, doesn't it?) is required. The spec change requires a 4-input AND gate rather than a 2-input multiplexer. One way to tackle this requirement is to use late binding. This requires no change to the MUX2 at all except in the configuration. So, in a hardware sense, we're extracting the AOI gate from its socket and inserting a 4-input AND gate.
 

Late-binding configuration of MUX2
 

use WORK.all;

configuration AND4_CFG of MUX2 is
  for STRUCTURE
    for G2 : AOI
      use entity work.AND4(quick_fix);
      -- architecture quick_fix of AND4 specified for AOI component
    end for;
  end for;
end AND4_CFG;

Copyright 2018 Campera Electronic Systems Srl | All rights reserved | P.IVA 01780710495