12 Generic Constants

The difference between this and the simpler rule we have seen before is the inclusion of the optional generic interface list before the port interface list. The generic interface list is like any other interface list, but with the restriction that we can only include constant-class objects, which must be of mode in. Since these are the defaults for a generic interface list, we can use a simplified syntax rule:!

A simple example of an entity declaration including a generic interface list is

This entity includes one generic constant, Tpd, of the predefined type time. The value of this generic constant may be used within the entity statements and any architecture body corresponding to the entity. In this example the intention is that the generic constant specify the propagation delay for the module, so the value should be used in a signal assignment statement as the delay. An architecture body that does this is

The visibility of a generic constant extends from the end of the generic interface list to the end of the entity declaration and extends into any architecture body corresponding to the entity declaration.

A generic constant is given an actual value when the entity is used in a component instantiation statement. We do this by including a generic map, as shown by the extended syntax rule for component instantiations:

The generic association list is like other forms of association lists, but since generic constants are always of class constant, the actual arguments we supply must be expressions. Thus the simplified syntax rule for a generic association list is

To illustrate this, let us look at a component instantiation statement that uses the and2 entity shown above:

The generic map specifies that this instance of the and2 module uses the value 2 ns for the generic constant Tpd; that is, the instance has a propagation delay of 2 ns. We might include another component instantiation statement using and2 in the same design but with a different actual value for Tpd in its generic map, for example:

When the design is elaborated we have two processes, one corresponding to the instance gate1 of and2, which uses the value 2 ns for Tpd, and another corresponding to the instance gate2 of and2, which uses the value 3 ns.

EXAMPLE    

As the syntax rule for the generic interface list shows, we may define a number of generic constants of different types and include default values for them. A more involved example is shown in Figure 12-1. In this example, the generic interface list includes a list of two generic constants that parameterize the propagation delay of the module and a Boolean generic constant, debug, with a default value of false. The intention of this last generic constant is to allow a design that instantiates this entity to activate some debugging operation. This operation might take the form of report statements within if statements that test the value of debug.

FIGURE 12-1 An entity declaration for a block of sequential control logic, including generic constants that parameterize its behavior.

We have the same flexibility in writing a generic map as we have in other association lists. We can use positional association, named association or a combination of both. We can omit actual values for generic constants that have default expressions, or we may explicitly use the default value by writing the keyword open in the generic map. To illustrate these possibilities, here are three different ways of writing a generic map for the control_unit entity:

FIGURE 12-2 An entity and architecture body for a D-flipflop. The entity declaration includes generic constants for specifying timing characteristics. These are used within the architecture body.

The entity might be instantiated as follows, with actual values specified in the generic map for the generic constants:

12.2 Parameterizing Structure

The second main use of generic constants in entities is to parameterize their structure. We can use the value of a generic constant to specify the size of an array port. To see why this is useful, let us look at an entity declaration for a register. A register entity that uses an unconstrained array type for its input and output ports can be declared as

While this is a perfectly legal entity declaration, it does not include the constraint that the input and output ports d and q should be of the same size. Thus we could write a component instantiation as follows:

The model is analyzed and elaborated without the error being detected. It is only when the register tries to assign a small bit vector to a target bit vector of a larger size that the error is detected. We can avoid this problem by including a generic constant in the entity declaration to parameterize the size of the ports. We use the generic constant in constraints in the port declarations. To illustrate, here is the register entity declaration rewritten:

In this declaration we require that the user of the register specify the desired port width for each instance. The entity then uses the width value as a constraint on both the input and output ports, rather than allowing their size to be determined by the signals associated with the ports. A component instantiation using this entity might appear as follows:

If the signals used as actual ports in the instantiation were of different sizes, the analyzer would signal the error early in the design process, making it easier to correct. As a matter of style, whenever the sizes of different array ports of an entity are related, generic constants should be considered to enforce the constraint.

FIGURE 12-3 An entity and architecture body for a register with parameterized port size.

We can create instances of the register entity in a design, each possibly having different-sized ports. For example:

creates an instance with 32-bit-wide ports. In the same design, we might include another instance, as follows:

This register instance has five-bit-wide ports, wide enough to store values of the subtype state_vector.