Once an entity has had its interface specified in an entity declaration, one or more implementations of the entity can be described in architecture bodies. Each architecture body can describe a different view of the entity. For example, one architecture body may purely describe the behaviour using the facilities covered in Chapters 2 and 4, whereas others may describe the structure of the entity as a hierarchically composed collection of components. In this section, we will only cover structural descriptions, deferring behaviour descriptions until Chapter 4.
An architecture body is declared using the syntax:
architecture_body ::=
architecture identifier of
entity_name is
architecture_declarative_part
begin
architecture_statement_part
end [ architecture_simple_name
] ;
architecture_declarative_part ::= { block_declarative_item }
architecture_statement_part ::= { concurrent_statement }
block_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| signal_declaration
| alias_declaration
| component_declaration
| configuration_specification
| use_clause
concurrent_statement ::=
block_statement
| component_instantiation_statement
The declarations in the architecture body define items that will be used to construct the design description. In particular, signals and components may be declared here and used to construct a structural description in terms of component instances, as illustrated in Section 1.4. These are discussed in more detail in the next sections.
Signals are used to connect submodules in a design. They are declared using the syntax:
signal_declaration ::=
signal identifier_list : subtype_indication
[ signal_kind ] [ := expression ] ;
signal_kind ::= register | bus
Use of the signal kind specification is covered in Section 6.2. Omitting the signal kind results in an ordinary signal of the subtype specified. The expression in the declaration is used to give the signal an initial value during the initialization phase of simulation. If the expression is omitted, a default initial value will be assigned.
One important point to note is that ports of an object are treated exactly as signals within that object.
The submodules in an architecture body can be described as blocks. A block is a unit of module structure, with its own interface, connected to other blocks or ports by signals. A block is specified using the syntax:
block_statement ::=
block_label :
block
[ ( guard_expression ) ]
block_header
block_declarative_part
begin
block_statement_part
end
block [ block_label ] ;
block_header ::=
[ generic_clause
[ generic_map_aspect ; ] ]
[ port_clause
[ port_map_aspect ; ] ]
generic_map_aspect ::= generic map ( generic_association_list )
port_map_aspect ::= port map ( port_association_list )
block_declarative_part ::= { block_declarative_item }
block_statement_part ::= { concurrent_statement }
The guard expression is not covered in this booklet, and may be omitted. The block header defines the interface to the block in much the same way as an entity header defines the interface to an entity. The generic association list specifies values for the generic constants, evaluated in the context of the enclosing block or architecture body. The port map association list specifies which actual signals or ports from the enclosing block or architecture body are connected to the block's ports. Note that a block statement part may also contain block statements, so a design can be composed of a hierarchy of blocks, with behavioural descriptions at the bottom level of the hierarchy.
As an example, suppose we want to describe a structural architecture of the processor entity example in Section 3.1. If we separate the processor into a control unit and a data path section, we can write a description as a pair of interconnected blocks, as shown in Figure 3-2.
The control unit block has ports clk, bus_control and bus_ready, which are connected to the processor entity ports. It also has an output port for controlling the data path, which is connected to a signal declared in the architecture. That signal is also connected to a control port on the data path block. The address and data ports of the data path block are connected to the corresponding entity ports. The advantage of this modular decomposition is that each of the blocks can then be developed independently, with the only effects on other blocks being well defined through their interfaces.
architecture block_structure of processor is
type data_path_control is ...;
signal internal_control : data_path_control;
begin
control_unit : block
port
(clk : in bit;
bus_control
: out proc_control;
bus_ready
: in bit;
control
: out data_path_control);
port
map (clk => clock,
bus_control
=> control, bus_ready => ready;
control
=> internal_control);
declarations
for control_unit
begin
statements
for control_unit
end block control_unit;
data_path : block
port
(address : out integer;
data
: inout word_32;
control
: in data_path_control);
port
map (address => address, data => data,
control
=> internal_control);
declarations
for data_path
begin
statements
for data_path
end block data_path;
end block_structure;
Figure 3-2. Structural architecture of processor example.
An architecture body can also make use of other entities described separately and placed in design libraries. In order to do this, the architecture must declare a component, which can be thought of as a template defining a virtual design entity, to be instantiated within the architecture. Later, a configuration specification (see Section 3.3) can be used to specify a matching library entity to use. The syntax of a component declaration is:
component_declaration ::=
component identifier
[
local_generic_clause ]
[
local_port_clause ]
end component ;
Some examples of component declarations:
component nand3
generic (Tpd : Time := 1 ns);
port (a, b, c : in logic_level;
y
: out logic_level);
end component;
component read_only_memory
generic (data_bits, addr_bits
: positive);
port (en : in bit;
addr
: in bit_vector(depth 1 downto 0);
data
: out bit_vector(width 1 downto 0) );
end component;
The first example declares a three-input gate with a generic parameter specifying its propagation delay. Different instances can later be used with possibly different propagation delays. The second example declares a read-only memory component with address depth and data width dependent on generic constants. This component could act as a template for the ROM entity described in Section 3.1.
A component defined in an architecture may be instantiated using the syntax:
component_instantiation_statement ::=
instantiation_label :
component_name
[
generic_map_aspect ]
[
port_map_aspect ] ;
This indicates that the architecture contains an instance of the named component, with actual values specified for generic constants, and with the component ports connected to actual signals or entity ports.
The example components declared in the previous section might be instantiated as:
enable_gate: nand3
port map (a => en1, b =>
en2, c => int_req, y => interrupt);
parameter_rom: read_only_memory
generic map (data_bits => 16,
addr_bits => 8);
port map (en => rom_sel, data
=> param, addr => a(7 downto 0);
In the first instance, no generic map specification is given, so the default value for the generic constant Tpd is used. In the second instance, values are specified for the address and data port sizes. Note that the actual signal associated with the port addr is a slice of an array signal. This illustrates that a port which is an array can be connected to part of a signal which is a larger array, a very common practice with bus signals.