ENG6090 Reconfigurable Computing Systems Hardware Description Languages Part 6: Configurations

Topics Associating architectures to entities Associating architectures to entities Default Binding Default Binding Configuration Specification Configuration Specification Configuration Declaration Configuration Declaration

Configurations So far, we have seen that there are different ways in which to model the operation of digital circuit utilizing –Data flow –Behavioral –Structural If you have different representations of one digital circuit (i.e. half adder or full adder). –Which architecture for the half adder should be used? Is there a mechanism in VHDL to accomplish this?

Configurations A design entity can have multiple alternative architectures A configuration specifies the architecture that is to be used to implement a design entity architecture-3 architecture-2 architecture-1 entity binding configuration

Configuration Techniques The VHDL language provides configurations for explicitly associating an architecture description with each component in a structural model. binding –This process of association is referred to as binding an instance of the component to an architecture. default binding –In the absence of any programmer-supplied configuration information, default binding rules apply. There are several ways in which configuration can be provided: –Configuration specification –Configuration declaration.

Component Binding We are concerned with configuring the architecture and not the entity Enhances sharing of designs: simply change the configuration

Default Binding Rules If no configuration information is provided, then we can find a default architecture as follows: –If the entity name is the same as the component name, then this entity is bound to the component. –If there are multiple architectures for the entity, then in this case we use the last compiled architecture for the entity. deferred If no such entity with the same name is visible to the VHDL environment, then the binding is said to be deferred: that is no binding takes place now, but information will be forthcoming later. –This is akin to going ahead with wiring the rest of the circuit and hoping that your partner comes up with the right chips before you are ready to run the experiment!!

Configuration Specification Configuration specifications are used in the architecture body to identify the relationships between the components and the entity – architecture pairs used to model each component. If we use a laboratory analogy, consider how we might specify the chips to be used for a component that we have declared. –We might specify the chip name and location, for example, in the box labeled half adders in the grey cabinet. How can we similarly define the exact location of an entity – architecture pair?

Configuration Specification We can do so by naming the design library within which it is located and the name of the design unit within which such pairs are stored. architecture structural of full_adder is -- --declare components here signal s1, s2, s3: std_logic; configuration specification for H1: half_adder use entity WORK.half_adder (behavioral); for H2: half_adder use entity WORK.half_adder (structural); for O1: or_2 use entity POWER.lpo2 (behavioral) generic map (gate_delay => gate_delay) port map (I1 => a, I2 => b, Z=>c); begin -- component instantiation statements H1: half_adder port map (a =>In1, b => In2, sum => s1, carry=> s2); H2: half_adder port map (a => s1, b => c_in, sum => sum, carry => s2); O1: or_2 port map (a => s2, b => s3, c => c_out); end structural; library name entity name architecture name

Configuration Declaration Configuration specifications is part of the architecture: hence, we must be placing it within the architecture body. Modification of our choice of models to implement a component requires editing the architecture and recompiling the model!! A configuration declaration enables us to provide the same configuration information, but as a separate design unit and, if desired, in a separate file. Suppose we take all of the configuration information provided in the previous slide, name it, and refer to it by its name. This unit now becomes the configuration declaration and is a distinct design unit (like an entity, or architecture)

Configuration declaration A configuration is a design unit like entity, package etc. Hence, it can be declared by itself. configuration_declaration <= configuration id of entity_name is for architecture_name { for component_specification binding_indication; end for; } end for; end [ configuration ] id ; component_specification <= ( instantiation_label {, … } | others | all ) : component_name; binding_indication <= use entity entity_name [ ( architecture_id ) ]

Configuration Declaration Written as a separate design unit Can be written to span a design hierarchy Use of the “for all” clause configuration Config_A of full_adder is -- name the configuration -- for the entity for structural -- name of the architecture being configured for H1: half_adder use entity WORK.half_adder (behavioral); end for; -- for H2: half_adder use entity WORK.half_adder (structural); end for; -- for O1: or_2 use entity POWER.lpo2 (behavioral) generic map(gate_delay => gate_delay) port map (I1 => a, I2 => b, Z=>c); end for; -- end for; end Config_A;

Example configuration reg4_gate_level of reg4 is for struct for bit0,bit1 : ff use entity flipflop(behavior); end for; for others : ff use entity flipflop(struct); end for; end; Default binding for ports

Design flow 1.Partition design into sub-parts. 2.Define the interface between various sub-parts. 3.Construct components to specify the sub-parts. 4.Design actual implementations for the components. 5.Use configuration to integrate and simulate.

Summary The key issue to be understood here is that –Configurations are the language mechanism that specifies a particular implementation when a myriad of alternative models is available for the constituent components. –The use of configurations is motivated in part by the need to be able to reuse models and share models among developers