3. Basic Structure of a VHDL file
A digital system in VHDL consists of a design entity that can contain other entities that are then considered components of the top-level entity. Each entity is modeled by an entity declaration and an architecture body. One can consider the entity declaration as the interface to the outside world that defines the input and output signals, while the architecture body contains the description of the entity and is composed of interconnected entities, processes and components, all operating concurrently, as schematically shown in Figure 3 below. In a typical design there will be many such entities connected together to perform the desired function.
Figure 3: A VHDL entity consisting of an interface (entity declaration) and a body (architectural description).
VHDL uses reserved keywords that cannot be used as signal names or identifiers. Keywords and user-defined identifiers are case insensitive. Lines with comments start with two adjacent hyphens (–) and will be ignored by the compiler. VHDL also ignores line breaks and extra spaces. VHDL is a strongly typed language which implies that one has always to declare the type of every object that can have a value, such as signals, constants and variables.
- Entity Declaration
The entity declaration defines the NAME of the entity and lists the input and output ports. The general form is as follows,
entity NAME_OF_ENTITY is [ generic generic_declarations);]
port (signal_names: mode type;
signal_names: mode type;
:
signal_names: mode type);
end [NAME_OF_ENTITY] ;
An entity always starts with the keyword entity, followed by its name and the keyword is. Next are the port declarations using the keyword port. An entity declaration always ends with the keyword end, optionally [] followed by the name of the entity.
- The NAME_OF_ENTITY is a user-selected identifier
- signal_names consists of a comma separated list of one or more user-selected identifiers that specify external interface signals.
- mode: is one of the reserved words to indicate the signal direction:
- o in – indicates that the signal is an input
- o out – indicates that the signal is an output of the entity whose value can only be read by other entities that use it.
- o buffer – indicates that the signal is an output of the entity whose value can be read inside the entity’s architecture
- o inout – the signal can be an input or an output.
- type: a built-in or user-defined signal type. Examples of types are bit, bit_vector, Boolean, character, std_logic, and std_ulogic.
- o bit – can have the value 0 and 1
- o bit_vector – is a vector of bit values (e.g. bit_vector (0 to 7)
- o std_logic, std_ulogic, std_logic_vector, std_ulogic_vector: can have 9 values to indicate the value and strength of a signal. Std_ulogic and std_logic are preferred over the bit or bit_vector types.
- o boolean – can have the value TRUE and FALSE
- o integer – can have a range of integer values
- o real – can have a range of real values
- o character – any printing character
- o time – to indicate time
- generic: generic declarations are optional and determine the local constants used for timing and sizing (e.g. bus widths) the entity. A generic can have a default value. The syntax for a generic follows,
generic (
constant_name: type [:=value] ;
constant_name: type [:=value] ;
:
constant_name: type [:=value] );
For the example of Figure 2 above, the entity declaration looks as follows.
— comments: example of the buzzer circuit of fig. 2 entity BUZZER is port (DOOR, IGNITION, SBELT: in std_logic; WARNING: out std_logic); end BUZZER;
|
The entity is called BUZZER and has three input ports, DOOR, IGNITION and SBELT and one output port, WARNING. Notice the use and placement of semicolons! The name BUZZER is an identifier. Inputs are denoted by the keyword in, and outputs by the keyword out. Since VHDL is a strongly typed language, each port has a defined type. In this case, we specified the std_logic type. This is the preferred type of digital signals. In contrast to the bit type that can only have the values ‘1’ and ‘0’, the std_logic and std_ulogic types can have nine values. This is important to describe a digital system accurately including the binary values 0 and 1, as well as the unknown value X, the uninitialized value U, “-” for don’t care, Z for high impedance, and several symbols to indicate the signal strength (e.g. L for weak 0, H for weak 1, W for weak unknown – see section on Enumerated Types). The std_logic type is defined in the std_logic_1164 package of the IEEE library. The type defines the set of values an object can have. This has the advantage that it helps with the creation of models and helps reduce errors. For instance, if one tries to assign an illegal value to an object, the compiler will flag the error.
A few other examples of entity declarations follow
Four-to-one multiplexer of which each input is an 8-bit word.
entity mux4_to_1 is
port (I0,I1,I2,I3: in std_logic_vector(7 downto 0);
SEL: in std_logic_vector (1 downto 0);
OUT1: out std_logic_vector(7 downto 0));
end mux4_to_1;
An example of the entity declaration of a D flip-flop with set and reset inputs is
entity dff_sr is
port (D,CLK,S,R: in std_logic;
Q,Qnot: out std_logic);
end dff_sr;
- Architecture body
The architecture body specifies how the circuit operates and how it is implemented. As discussed earlier, an entity or circuit can be specified in a variety of ways, such as behavioral, structural (interconnected components), or a combination of the above.
The architecture body looks as follows,
architecture architecture_name of NAME_OF_ENTITY is
— Declarations
— components declarations
— signal declarations
— constant declarations
— function declarations
— procedure declarations
— type declarations
:
begin
— Statements
:
end architecture_name;
Behavioral model
The architecture body for the example of Figure 2, described at the behavioral level, is given below,
architecture behavioral of BUZZER is
begin
WARNING <= (not DOOR and IGNITION) or (not SBELT and IGNITION);
end behavioral;
The header line of the architecture body defines the architecture name, e.g. behavioral, and associates it with the entity, BUZZER. The architecture name can be any legal identifier. The main body of the architecture starts with the keyword begin and gives the Boolean expression of the function. We will see later that a behavioral model can be described in several other ways. The “<= ” symbol represents an assignment operator and assigns the value of the expression on the right to the signal on the left. The architecture body ends with an end keyword followed by the architecture name.
A few other examples follow. The behavioral description of a two-input AND gate is shown below.
entity AND2 is
port (in1, in2: in std_logic;
out1: out std_logic);
end AND2;
architecture behavioral_2 of AND2 is
begin
out1 <= in1 and in2;
end behavioral_2;
An example of a two-input XNOR gate is shown below.
entity XNOR2 is
port (A, B: in std_logic;
Z: out std_logic);
end XNOR2;
architecture behavioral_xnor of XNOR2 is
— signal declaration (of internal signals X, Y)
signal X, Y: std_logic;
begin
X <= A and B;
Y <= (not A) and (not B);
Z <= X or Y;
End behavioral_xnor;
The statements in the body of the architecture make use of logic operators. Logic operators that are allowed are: and, or, nand, nor, xor, xnor and not. In addition, other types of operators including relational, shift, arithmetic are allowed as well (see section on Operators). For more information on behavioral modeling see section on Behavioral Modeling.
Concurrency
It is worth pointing out that the signal assignments in the above examples are concurrent statements. This implies that the statements are executed when one or more of the signals on the right hand side change their value (i.e. an event occurs on one of the signals). For instance, when the input A changes, the internal signals X and Y change values that in turn causes the last statement to update the output Z. There may be a propagation delay associated with this change. Digital systems are basically data-driven and an event which occurs on one signal will lead to an event on another signal, etc. The execution of the statements is determined by the flow of signal values. As a result, the order in which these statements are given does not matter (i.e., moving the statement for the output Z ahead of that for X and Y does not change the outcome). This is in contrast to conventional, software programs that execute the statements in a sequential or procedural manner.
Structural description
The circuit of Figure 2 can also be described using a structural model that specifies what gates are used and how they are interconnected. The following example illustrates it.
architecture structural of BUZZER is
— Declarations
component AND2
port (in1, in2: in std_logic;
out1: out std_logic);
end component;
component OR2
port (in1, in2: in std_logic;
out1: out std_logic);
end component;
component NOT1
port (in1: in std_logic;
out1: out std_logic);
end component;
— declaration of signals used to interconnect gates
signal DOOR_NOT, SBELT_NOT, B1, B2: std_logic;
begin
— Component instantiations statements
U0: NOT1 port map (DOOR, DOOR_NOT);
U1: NOT1 port map (SBELT, SBELT_NOT);
U2: AND2 port map (IGNITION, DOOR_NOT, B1);
U3: AND2 port map (IGNITION, SBELT_NOT, B2);
U4: OR2 port map (B1, B2, WARNING);
end structural;
Following the header is the declarative part that gives the components (gates) that are going to be used in the description of the circuits. In our example, we use a two- input AND gate, two-input OR gate and an inverter. These gates have to be defined first, i.e. they will need an entity declaration and architecture body (as shown in the previous example). These can be stored in one of the packages one refers to in the header of the file (see Library and Packages below). The declarations for the components give the inputs (e.g. in1, in2) and the output (e.g. out1). Next, one has to define internal nets (signal names). In our example these signals are called DOOR_NOT, SBELT_NOT, B1, B2 (see Figure 2). Notice that one always has to declare the type of the signal.
The statements after the begin keyword gives the instantiations of the components and describes how these are interconnected. A component instantiation statement creates a new level of hierarchy. Each line starts with an instance name (e.g. U0) followed by a colon and a component name and the keyword port map. This keyword defines how the components are connected. In the example above, this is done through positional association: DOOR corresponds to the input, in1 of the NOT1 gate and DOOR_NOT to the output. Similarly, for the AND2 gate where the first two signals (IGNITION and DOOR_NOT) correspond to the inputs in1 and in2, respectively, and the signal B1 to the output out1. An alternative way is to use explicit association between the ports, as shown below.
label: component-name port map (port1=>signal1, port2=> signal2,… port3=>signaln);
U0: NOT1 port map (in1 => DOOR, out1 => DOOR_NOT);
U1: NOT1 port map (in1 => SBELT, out1 => SBELT_NOT);
U2: AND2 port map (in1 => IGNITION, in2 => DOOR_NOT, out1 => B1);
U3: AND2 port map (in1 => IGNITION, in2 => SBELT_NOT, B2);
U4: OR2 port map (in1 => B1, in2 => B2, out1 => WARNING);
Notice that the order in which these statements are written has no bearing on the execution since these statements are concurrent and therefore executed in parallel. Indeed, the schematic that is described by these statements is the same independent of the order of the statements.
Structural modeling of design lends itself to hierarchical design, in which one can define components of units that are used over and over again. Once these components are defined they can be used as blocks, cells or macros in a higher level entity. This can significantly reduce the complexity of large designs. Hierarchical design approaches are always preferred over flat designs. We will illustrate the use of a hierarchical design approach for a 4-bit adder, shown in Figure 4 below. Each full adder can be described by the Boolean expressions for the sum and carry out signals,
sum = (A Å B) Å C
carry = AB + C(A Å B)
Figure 4: Schematic of a 4-bit adder consisting of full adder modules.
In the VHDL file, we have defined a component for the full adder first. We used several instantiations of the full adder to build the structure of the 4-bit adder. We have included the library and use clause as well as the entity declarations.
Four Bit Adder – Illustrating a hierarchical VHDL model |
— Example of a four bit adder
library ieee; use ieee.std_logic_1164.all; — definition of a full adder entity FULLADDER is port (a, b, c: in std_logic; sum, carry: out std_logic); end FULLADDER; architecture fulladder_behav of FULLADDER is begin sum <= (a xor b) xor c ; carry <= (a and b) or (c and (a xor b)); end fulladder_behav;
— 4-bit adder library ieee; use ieee.std_logic_1164.all;
entity FOURBITADD is port (a, b: in std_logic_vector(3 downto 0); Cin : in std_logic; sum: out std_logic_vector (3 downto 0); Cout, V: out std_logic); end FOURBITADD;
architecture fouradder_structure of FOURBITADD is signal c: std_logic_vector (4 downto 0); component FULLADDER port(a, b, c: in std_logic; sum, carry: out std_logic); end component; begin FA0: FULLADDER port map (a(0), b(0), Cin, sum(0), c(1)); FA1: FULLADDER port map (a(1), b(1), C(1), sum(1), c(2)); FA2: FULLADDER port map (a(2), b(2), C(2), sum(2), c(3)); FA3: FULLADDER port map (a(3), b(3), C(3), sum(3), c(4)); V <= c(3) xor c(4); Cout <= c(4); end fouradder_structure;
|
Notice that the same input names a and b for the ports of the full adder and the 4-bit adder were used. This does not pose a problem in VHDL since they refer to different levels. However, for readability, it may be easier to use different names. We needed to define the internal signals c(4:0) to indicate the nets that connect the output carry to the input carry of the next full adder. For the first input we used the input signal Cin. For the last carry we defined c(4) as an internal signal since the last carry is needed as the input to the xor gate. We could not use the output signal Cout since VHDL does not allow the use of outputs as internal signals! For this reason we had to define the internal carry c(4) and assign c(4) to the output carry signal Cout.
See also the section on Structural Modeling.
- Library and Packages: library and use keywords
A library can be considered as a place where the compiler stores information about a design project. A VHDL package is a file or module that contains declarations of commonly used objects, data type, component declarations, signal, procedures and functions that can be shared among different VHDL models.
We mentioned earlier that std_logic is defined in the package ieee.std_logic_1164 in the ieee library. In order to use the std_logic one needs to specify the library and package. This is done at the beginning of the VHDL file using the library and the use keywords as follows:
library ieee;
use ieee.std_logic_1164.all;
The .all extension indicates to use all of the ieee.std_logic_1164 package.
The Xilinx Foundation Express comes with several packages.
ieee Library:
- std_logic_1164 package: defines the standard datatypes
- std_logic_arith package: provides arithmetic, conversion and comparison functions for the signed, unsigned, integer, std_ulogic, std_logic and std_logic_vector types
- std_logic_unsigned
- std_logic_misc package: defines supplemental types, subtypes, constants and functions for the std_logic_1164 package.
To use any of these one must include the library and use clause:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
In addition, the synopsis library has the attributes package:
library SYNOPSYS;
use SYNOPSYS.attributes.all;
One can add other libraries and packages. The syntax to declare a package is as follows:
— Package declaration
package name_of_package is
package declarations
end package name_of_package;
— Package body declarations
package body name_of_package is
package body declarations
end package body name_of_package;
For instance, the basic functions of the AND2, OR2, NAND2, NOR2, XOR2, etc. components need to be defined before one can use them. This can be done in a package, e.g. basic_func for each of these components, as follows:
— Package declaration
library ieee;
use ieee.std_logic_1164.all;
package basic_func is
— AND2 declaration
component AND2
generic (DELAY: time :=5ns);
port (in1, in2: in std_logic; out1: out std_logic);
end component;
— OR2 declaration
component OR2
generic (DELAY: time :=5ns);
port (in1, in2: in std_logic; out1: out std_logic);
end component;
end package basic_func;
— Package body declarations
library ieee;
use ieee.std_logic_1164.all;
package body basic_func is
— 2 input AND gate
entity AND2 is
generic (DELAY: time);
port (in1, in2: in std_logic; out1: out std_logic);
end AND2;
architecture model_conc of AND2 is
begin
out1 <= in1 and in2 after DELAY;
end model_conc;
— 2 input OR gate
entity OR2 is
generic (DELAY: time);
port (in1, in2: in std_logic; out1: out std_logic);
end OR2;
architecture model_conc2 of AND2 is
begin
out1 <= in1 or in2 after DELAY;
end model_conc2;
end package body basic_func;
Notice that we included a delay of 5 ns. However, it should be noticed that delay specifications are ignored by the Foundation synthesis tool. We made use of the predefined type std_logic that is declared in the package std_logic_1164. We have included the library and use clause for this package. This package needs to be compiled and placed in a library. Lets call this library my_func. To use the components of this package one has to declare it using the library and use clause:
library ieee, my_func;
use ieee.std_logic_1164.all, my_func.basic_func.all;
One can concatenate a series of names separated by periods to select a package. The library and use statements are connected to the subsequent entity statement. The library and use statements have to be repeated for each entity declaration.
One has to include the library and use clause for each entity as shown for the example of the four-bit adder above.