Structural Modeling

In structural style of modeling, an entity is modeled as a set of components connected by signals, that is, as a netlist.

The behavior of the entity is not explicitly apparent from its model. The component instantiation statement is the primary mechanism used for describing such a model of an entity.

Eg.,

Fig.1: Circuit generating control signals

library IEEE;

use IEEE.std_logic_1164.all;

entity GATING is

port (A, CK, MR, DIN: in BIT; RDY, CTRLA: out BIT);

end GATING;

architecture STRUCTURE_VIEW of GATING is

component AND2

port (X, Y: in BIT; Z: out BIT);

end component;

component DFF

port (D, CLOCK: in BIT; Q, QBAR: out BIT);

end component;

component NOR2

port (A, B: in BIT; Z: out BIT);

end component;

signal SI, S2: BIT;

begin

D1: DFF port map (A, CK, SI, S2);

A1: AND2 port map (S2, DIN, CTRLA);

N1: NOR2 port map (SI, MR, RDY);

end STRUCTURE_VIEW;

library IEEE;

use IEEE.std_logic_1164.all;

entity AND2 is

port (X, Y: in BIT; Z: out BIT);

end AND2;

architecture DATAFLOW of AND2 is

begin

Z<=X and Y;

end DATAFLOW;

library IEEE;

use IEEE.std_logic_1164.all;

entity NOR2 is

port (A, B: in BIT; Z: out BIT);

end NOR2;

architecture DATAFLOW of NOR2 is

begin

Z<=A nor B;

end DATAFLOW;

library IEEE;

use IEEE.std_logic_1164.all;

entity DFF is

port (D, CLOCK: in BIT; Q, QBAR: out BIT);

end DFF;

architecture BEHAVIORAL of DFF is

begin

process(D<CLOCK)

begin

if(CLOCK=’1’ and CLOCK’ event) then

Q<=D;

QBAR<=not D;

else

Q<=Q;

QBAR<=QBAR;

end if;

end process;

end DATAFLOW;

Three components, AND2, DFF, and NOR2, are declared, which are instantiated in the architecture body via three component instantiation statements, and the instantiated components are connected to each other via signals SI and S2.

The component instantiation statements are concurrent statements, and therefore, their order of appearance in the architecture body is not important.

A component can, in general, be instantiated any number of times. However, each instantiation must have a unique component label; as an example, A1 is the component label for the AND2 component instantiation.

Component Declaration

A component instantiated in a structural description must first be declared using a component declaration. A component declaration declares the name and the interface of a component. The interface specifies the mode and the type of ports.

The syntax of a simple form of component declaration is

component component-name

port ( list-of-interface-ports ) ;

end component;

The component-name may or may not refer to the name of an already existing entity in a library. If it does not, it must be explicitly bound to an entity; otherwise, the model cannot be simulated. This is done using a configuration.

The list-of-interface-ports specify the name, mode, and type for each port of the component in a manner similar to that specified in an entity declaration.

component NAND2

port (A, B: in MVL;

Z: out MVL);

end component;

component MP

port (CK, RESET, RON, WRN: in BIT;

DATA_BUS: inout INTEGER range 0 to 255;

ADDR_BUS: in BIT_VECTOR(15 downto 0));

end component;

component RX

port (CK, RESET, ENABLE, DATAIN, RD: in BIT;

DATA_OUT: out INTEGER range 0 to (2**8 - 1);

PARITY_ERROR, FRAME_ERROR,

OVERRUN_ERROR: out BOOLEAN);

end component;

Component declarations appear in the declarations part of an architecture body. Alternately, they may also appear in a package declaration. Items declared in this package can then be made visible within any architecture body by using the library and use context clauses.

Eg., consider a package created to hold the component declarations.

package COMP_LIST is

component AND2

port (X, Y: in BIT: Z: out BIT):

end component;

component DFF

port (D, CLOCK: in BIT; Q, QBAR: out BIT);

end component;

component NOR2

port (A, B: in BIT; Z: out BIT);

end component;

end COMP_LIST;

Assuming that this package has been compiled into design library DES_LIB, the architecture body can be rewritten as

library DES_LIB;

use DES_LIB.COMP_LIST.all;

architecture STRUCTURE_VIEW of GATING is

signal S1, S2: BIT;

-- No need for specifying component declarations here, as they are        

-- made visible to architecture body using the context clauses.

begin

-- The component instantiations here.

end STRUCTURE_VIEW;

The advantage of this approach is that the package can now be shared by other design units and the component declarations need not be specified inside every design unit.

Component Instantiation

A component instantiation statement defines a subcomponent of the entity in which it appears. It associates the signals in the entity with the ports of that subcomponent.

A format of a component instantiation statement is

component-label: component-name port map ( association-list) ',

The component-label can be any legal identifier and can be considered as the name of the instance.

The component-name must be the name of a component declared earlier using a component declaration.

The association-list associates signals in the entity, called actuals, with the ports of a component, called locals. An actual must be an object of class signal. Expressions or objects of class variable or constant are not allowed. An actual may also be the keyword open to indicate a port that is not connected.

There are two ways to perform the association of locals with actuals:

1. positional association,

2. named association.

In positional association, an association-list is of the form

actuali, actualg, actual3, . . ., actual

Each actual in the component instantiation is mapped by position with each port in the component declaration, i.e., the first port in the component declaration corresponds to the first actual in the component instantiation, the second with the second, and so on.

Consider an instance of a NAND2 component.

-- Component declaration:

component NAND2

port (A, B: in BIT; Z: out BIT);

end component;

-- Component instantiation:

N1: NAND2 port map (S1, S2, S3);

N1 is the component label for the current instantiation of the NAND2 component. Signal S1 (which is an actual) is associated with port A (which is a local) of the NAND2 component, S2 is associated with port B of the NAND2 component, and S3 is associated with port Z. Signals S1 and S2 thus provide the two input values to the NAND2 component and signal S3 receives the output value from the component. The ordering of the actuals is important.

If a port in a component instantiation is not connected to any signal, the keyword open can be used to signify that the port is not connected.

Eg.,

N3: NAND2 port map (S1, open, S3);

The second input port of the NAND2 component is not connected to any signal. An input port may be left open only if its declaration specifies an initial value.

For the previous component instantiation statement to be legal, a component declaration for NAND2 may appear like

component NAND2

port (A, B: in BIT := '0'; Z: out BIT);

-- Both A and B have an initial value of '0'; however, only

-- the initial value of B is necessary in this case.

end component;

A port of any other mode may be left unconnected as long as it is not an unconstrained array.

In named association, an association-list is of the form

locale => actual1, local2 => actual2, ..., localn => actualn

Eg.,

N1: NOR2 port map (B=>MR, Z=>RDY, A=>S1);

In this case, the signal MR (an actual), that is declared in the entity port list, is associated with the second port (port B, a local) of the NOR2 gate, signal RDY is associated with the third port (port Z) and signal S1 is associated with the first port (port A) of the NOR2 gate.

In named association, the ordering of the associations is not important since the mapping between the actuals and locals are explicitly specified.

Note:

The scope of the locals is restricted to be within the port map part of the instantiation for that component; Eg., the locals A, B, and Z of component NOR2 are relevant only within the port map of instantiation of component NOR2.

Rules for either type of association:

1.   The types of the local and the actual being associated must be the same.

2.   The modes of the ports must conform to the rule that if the local is readable, so must the actual and if the local is writable, so must the actual. Since a signal locally declared is considered to be both readable and writable, such a signal may be associated with a local of any mode. If an actual is a port of mode in, it may not be associated with a local of mode out or inout; if the actual is a port of mode out, it may not be associated with a local of mode in or inout; if the actual is a port of mode inout, it may be associated with a local of mode in, out, or inout.

Note:

an actual of mode out or inout indicates the presence of a source for that signal, and therefore, must be resolved if that signal is multiply driven.

A buffer port can never have more than one source; therefore, the only kind of actual that can be associated with a buffer port is another buffer port or a signal that has at most one source.

Eg.,

M1: MICRO port map (UDIN(3 downto 0), WRN, RDN, STATUS(0), STATUS(1 ), UDOUT(0 to 7), TXDATA);

The first actual of the port map refers to a slice of the vectored UDIN signal, WRN and RDN are 1-bit signals, STATUS(0) and STATUS(1) refer to the 0th and 1st element of the STATUS array, UDOUT(0 tp 7) refers to a slice of the UDOUT vector and TXDATA refers to an entire vector signal.

The signals used to interconnect components can also be slices, vectors, or, array elements.