Lines 7 through 10 describe what our entity, eqcomp4, does. This is called the architecture of our entity; it begins on line 7 with the keyword ARCHITECTURE and ends with "END dataflow;" at line 10. In line 7, we give the architecture a name, dataflow, and identify the entity that it describes:
"OF eqcomp4." (The name that we gave the architecture was our choice. We chose dataflow because the architecture falls into the class of dataflow descriptions. We'll explore this and other classes of architectural descriptions later in the chapter.) Line 8, obviously enough, begins the architecture description with the keyword BEGIN, and line 9 is where the digital logic is described. This simple architecture includes one equality comparator. Line 9 states that when the value of bus a is equal to the value of bus b, then equals gets' I' , otherwise equals gets '0'. Read from left to right: "equals gets' I' when a equals b, else '0'." The <= symbol is an operator that can be read "gets" or "is assigned to." For brevity, we'll often use "gets," despite its being jargon. The comparison is bitwise from left to right (i.e., a(3) is compared to b(3), a(2) is compared to b(2), etc.). The most significant bits (MSB) for a and b are the leftmost bits a(3) and b(3). For clarity, we will typically order the bits from "x downto 0" in order that the most significant bit is the one with the highest index.
Entity and Architecture Pairs
Entities
56
The design example above illustrates that a VHDL design consists of an entity and an architecture pair: The entity describes the design 110 and the architecture describes the contents of the design.
Now that we have worked through an example to give you an idea of how designs are put together, we'll start looking at the details of VHDL design syntax and semantics. We'll begin by examining the syntax used to describe entities, after which we will describe the classes of architecture.
We could start with a detailed discussion of identifiers, data objects, and data types. However, we believe that you'll benefit more by first gaining a broad understanding of how VHDL designs are put together before delving into the details of data. If you prefer, read the section later in this chapter on identifiers, data objects, and data types before returning here.
A VHDL entity describes the inputs and outputs (110) of a design. This could be the 110 of a component in a larger, hierarchical design, or-if the VHDL entity is a device-level description-the 110 of a device. The entity is analogous to a schematic symbol, which describes a component's connections to the rest ~f a design. A schematic symbol for a 4-bit adder (add4) is shown in Figure 3-2. You can see that the 4-bit adder has a name (add4), two 4-bit inputs (a and b), a carry-in input (ci), a 4-bit output (sum), and a carry-out output (co). These items are also contained in an entity:
entity add4 is port(
a, b: in std_logic_vector(3 downto 0);
end add4;
Ports
ci:
sum:
co:
in std_logic;
out std_logic_vector(3 downto 0);
out std_logic);
SUM[3:0]
Figure 3-2 Symbol equivalent of entity ADD4
Each I/O signal in an entity is referred to as a port, which is analogous to a pin in a schematic symbol. (A port is a data object in VHDL. Like other data objects, it can be assigned values, which can be used in expressions. We'll investigate other data objefts in the next section ofthe chapter.) The set of ports that you define in your entity is referred to as a port declaration. Each port that you declare must have a name, a direction (or mode), and a data type. The first part of the declaration, the port name, is self-explanatory. Legal VHDL identifiers (names) are described on page 70.
Modes
The mode describes the direction in which data is transferred through a port. The mode can be one of four values: IN, OUT, INOUT, or BUFFER. A port that is declared as mode IN describes a port in which data flows only into the entity. The driver for a port of mode IN is external to the entity. A port that is declared as mode OUT describes a port in which data flows only from its source to the output port (or "pin") ofthe entity. The driver for a port of mode OUT is from within the entity.
Mode OUT does not allow for feedback within the associated architecture. For internal feedback (i.e., to use this port as a driver within the architecture), you'll need to declare a port as mode BUFFER or mode INOUT. A port that is declared as mode BUFFER is similar to a port that is declared as mode OUT, except that it does allow for internal feedback. Mode BUFFER does not allow for bidirectional ports, however, because it does not permit the signal to be driven from outside of the entity. An additional caveat for the use of the mode BUFFER will be explained in chapter 6,
"The Design of a 100BASE-T4 Network Repeater." For bidirectional signals, you must declare a port as mode INOUT. This mode describes a port in which data can flow into or out of the entity. In other words, the signal driver can be inside or outside of the entity. Mode INOUT also allows for internal feedback. Mode INOUT can be used anywhere that mode BUFFER is used; that is, everywhere that mode BUFFER is used in a design could be replaced with mode INOUT. However, doing so may complicate the reading of large design listings, making it difficult to discern the source of the signals. If the mode of a port is not specified, then the port is of the default mode IN.
Mode IN is primarily used for clock inputs, control inputs (like load, reset, enable), or unidirectional data inputs. Mode OUT is used for outputs such as a terminal count output (a terminal count is asserted when the value of a counter reaches a predefined value). Mode BUFFER is used for ports
57
58
such as the counter itself (the present state of a counter must be used to determine its next state, so it's value must be in the feedback loop, thereby necessitating a mode other than just OUT). Mode INOUT could be used for all of the ports mentioned so far: the dedicated inputs, the terminal count, and the counter outputs. Although using one mode, INOUT, for all signals would be legal, it reduces the readability of the code. A more appropriate use for mode INOUT is for signals that require feedback (like the counter) or that are truly bi-directional such as the multiplexed address/data bus of a DMA controller. Figure 3-3 illustrates the classification of modes.
MOD [ • MOD [ .
i n
out
i n
b u f f s ! '
out
Oft 2
in 0 u t
i n
Figure 3-3 Modes and their signal sources
Types
In addition to specifying identifiers (names) and modes for ports, you must also declare the ports' data types. The most useful and well-supported types provided by the IEEE std_logic_1164 package are the types std_ulogic, std_Iogic, and arrays of these types. As the names imply, "standard logic" is intended to be a standard type used to describe circuits for synthesis and simulation. For simulation and synthesis software to process these types, their declarations must be made visible to the entity by way of a USE clause. The most useful and well-supported types provided by the IEEE 1076/93 standard and which are applicable to synthesis are the data types boolean, bit, bie vector, and integer.
Many of the examples throughout this book will use the std_Iogic type to reinforce the idea that it is
a standard. However, you should be aware that you are not restricted from using other types. We'll defer a more detailed discussion of data types to page 72.
Architectures
Every architecture is associated with an entity. An architecture describes the contents of an entity;
that is, it describes what an entity does. If the entity is viewed as the engineer's "black box" (for which the inputs and outputs are known, but not the details of what is inside the box), then the architecture is the internal view of the black box. VHDL allows you to write your designs using different "styles" of architecture and to mix and match these styles as you see fit. Depending on the style, an architecture is classified as a behavioral or structural description, or a combination of the two. The name given to the architecture classification is not important, and often the style or class of design description that you use for synthesis is not important. However, the terms "behavioral" and
"structural" will give us a common vocabulary that we can use when discussing these different classes of design description.
Listing 2-2 Behavioral architecture description for eqcomp4.
Listing 2-2 is an example of a behavioral description, as is Listing 2-1. Why is it "behavioral," or rather what makes it "behavioral?" After reading the code listing, you may already have an idea.
Simply put, it's because of the algorithmic way in which the architecture is described. Behavioral descriptions are sometimes referred to as "" descriptions because of the resemblance to high-level programming languages. Rather than specifying the structure or netlist of a circuit, you specify signal assignments, or circuit "behavior." The advantage to high-level descriptions is that you don't need to focus on the gate-level implementation of a design; instead, you can focus your efforts on describing how the circuit is to "behave."
Lines I through 4 declare the entity and ports (I/O) for a 4-bit comparator. Line 6 declares the architecture that begins on line 7. Lines 8 through 15 embody the algorithm for this comparator.
Processes are one ofVHDL's design constructs for embodying algorithms. Lines 10 through 14 use a comparison operator and the IF-THEN-ELSE construct to indicate that equals should be asserted when a is equal to h.
59