Envisia HDL Modeling Reference

VHDL Modeling Style

Hierarchical VHDL Designs

This section describes hierarchical VHDL designs.

Component Instantiations and Bindings

BuildGates synthesis supports several types of component instantiations in hierarchical

VHDL designs. Consider an entity BOTTOM that has two architectures: A1 and A2. The following example illustrates the various ways in which entity BOTTOM can be instantiated for synthesis and bound to a specific entity architecture pair for implementation:

entity BOTTOM is ...

architecture A1 of BOTTOM is ...

architecture A2 of BOTTOM is ...

configuration BOTTOM_CONF of BOTTOM is ...

for A2

end for;

end configuration BOTTOM_CONF;

entity TOP is .....

architecture A of TOP is

component BOTTOM .....

component COMP .....

for I2 : COMP use entity work.BOTTOM;

for I3 : COMP use entity work.BOTTOM (A1);

for I4 : COMP use configuration work.BOTTOM_CONF;

begin

--instantiate component BOTTOM, default architecture I1 : BOTTOM ...

--instantiate component COMP bound to entity BOTTOM I2 : COMP ...

I3 : COMP ...

I4 : COMP ...

- instantiate entity BOTTOM, default architecture I5 : entity work.BOTTOM ...

--instantiate entity BOTTOM, architecture A1

I6 : entity work.BOTTOM(A1) ...

--instantiate entity/architecture in BOTTOM_CONF I7 : configuration work.BOTTOM_CONF ...

--instantiate component,binding in configuration

--declaration

Envisia HDL Modeling Reference

VHDL Modeling Style

I8 : COMP ...

I9 : COMP ...

end architecture A; configuration TOP_CONF of TOP is

for A

for I8 : COMP use entity work.BOTTOM(A1);

for I9 : COMP use configuration work.BOTTOM_CONF; end for;

end configuration TOP_CONF

Instances I1, I2, I3, and I4 are examples of component instantiations that refer to component declarations. Instance I1 of component BOTTOM relies on a default binding to entity BOTTOM. Default architecture (the most recently analyzed) A2 is selected for implementing I1. The configuration specification for I2 binds the component COMP to entity BOTTOM, default architecture A2. The configuration specification for instance I3 binds COMP explicitly to entity BOTTOM and its architecture A1. The configuration specification for I4 references the configuration BOTTOM_CONF, which binds I4 to entity BOTTOM and architecture A2.

Instances I5 and I6 are examples of entity instantiations, where the entity being instantiated is directly referred to in the instantiation. Since no architecture is specified in instantiation I5, default architecture A2 is used for implementing this component instance. Instance I6 instantiates entity BOTTOM and implements with architecture A1.

Instance I7 is an instantiation that uses a configuration to indicate the entity and architecture that is used to implement the instance.

Instances I8 and I9 illustrate that the binding for component instances are specified as component configurations in a configuration declaration. Instance I8 of COMP is bound to entity BOTTOM and architecture A1, while instance I9 is bound to the entity BOTTOM and architecture A2 specified in configuration BOTTOM_CONF.

Block configurations in configuration declarations are used only to configure architectures. Component configurations must not have any generic maps or port maps. In other words, even though the component declaration COMP may be bound to entity BOTTOM, the generics and ports of the component declaration must match that of the entity it is bound to.

Restrictions on Entities with Multiple Architectures

In VHDL, an entity may have multiple architectures (one for synthesis and one for simulation).

Although you can analyze an entity that has multiple architectures, the tool restricts an entity to be bound to exactly one architecture in a single session of synthesis. In other words, if once

Envisia HDL Modeling Reference

VHDL Modeling Style

an entity is bound to a specific architecture, it must be bound to that same architecture everywhere in the design.

The design below is not synthesizable because instances I1 and I2 bind component COMP to different architectures of entity BOTTOM.

entity TOP is .....

architecture A of TOP is

component COMP is ...

for I1 : COMP use entity work.BOTTOM (A1);

for I2 : COMP use entity work.BOTTOM (A2);

begin

I1 : COMP ...

I2 : COMP ...

end architecture A;

The following design shows restrictions on entities with multiple architectures:

entity BOTTOM is ...

architecture A1 of BOTTOM is ...

architecture A2 of BOTTOM is ...

configuration BOTTOM_CONF of BOTTOM is

for A1

end for;

end configuration BOTTOM_CONF;

entity TOP is ...

architecture A of TOP is begin

I1 : entity work.BOTTOM(A2); end architecture A;

For the design above, the following command synthesizes the entity TOP and consequently entity BOTTOM while processing instance I1. The entity BOTTOM is bound to architecture A2 specified in the entity instantiation.

ac_shell[4]> do_build_generic -module TOP

However, the following two commands result in an error since the first do_build_generic binds BOTTOM to architecture A1 specified in configuration BOTTOM_CONF, while the second do_build_generic encounters a conflicting binding when processing the entity instantiation I1 (where BOTTOM is bound to A2):

ac_shell[4]> do_build_generic -module BOTTOM

ac_shell[5]> do_build_generic -module TOP