UNIT 2

BASIC STRUCTURES OF VHDL

TOPICS
| Entities and Architectures
| Coding Styles

| Identifiers, Spaces, Comments, and Headers

| Signals and Data Types

| Operators
DESIGN UNIT
| It is a VHDL construct that can be separately
compiled and stored in a design library
| It consists of a context clause followed by a
library unit.
y A context clause consists of a library clause and a
use clause
y Example of a context clause:
library ieee;
use ieee.std_logic_1164.all;
LIBRARY UNIT
| It is the compilation of specific design units
| It has 5 kinds:
y Entity declaration
y Architecture body
y Package declaration
y Package body
y Configuration declaration
DESIGN ENTITY
| It is the basic unit of a hardware design.
| It has at least one pair of:
y An entity declaration that defines the inputs and
outputs—the ports—of this design; and
y An architecture body that defines what the design
actually does, using a single concurrent assignment.
 Design Entity
DESIGN ENTITY

Entity Declaration
(external view)

Architecture Body
(internal function)
ENTITY DECLARATION
| It defines the entity’s name and its interface.
| It includes the ff.:
y Entity name
y Port statement/list
| Port names
| Direction (either in, out, or inout)

| Type

| Generic list (optional)

ENTITY DECLARATION
| Syntax:
entity entity_name is
port(port_name : direction type);
end entity [entity_name];

| Example:
entity Full_Adder is
port(A, B, Cin : in std_logic;
Sum, Cout : out std_logic);
end Full_Adder ;
PORT MODES
| A port’s mode specifies its direction of
information transfer.
| There are 5 modes, namely:
y in
y out
y inout
y buffer
y linkage (removed)
| If no mode is specified, default is in.
PORT MODES
ENTITY DIAGRAM

Inputs
entity Outputs

(architecture)
ARCHITECTURE BODY
| The architecture describes the actual function—
or contents—of the entity to which it is bound.
| It includes the ff.:
y Declarative part wherein the components and signals
are being declared
y Statement part wherein the component instantiation
statements, signal assignments, and behavioral
constructs (such as process statements) are stated
ARCHITECTURE BODY
| Syntax:
architecture arch_name of entity_name is
declarative part
begin
statement part
end architecture arch_name;
ARCHITECTURE BODY
| Example:
architecture Structural of Full_Adder is
component Half_Adder is
Port ( A, B : in STD_LOGIC;
Sum, Cout : out STD_LOGIC);
end component;
signal sumsig, coutsig1, coutsig2 : STD_LOGIC;
begin
HA1: Half_Adder port map ( A, B, sumsig, coutsig1 );
HA2: Half_Adder port map ( A => sumsig,
B => Cin,
Sum => Sum,
Cout => coutsig2);
Cout <= coutsig1 or coutsig2;
end Structural;
CODING STYLES
| Architectures can be written in any of the ff:
y Dataflow
| Uses only concurrent signal assignments
| For low-level (very basic) design entities

y Behavioral
| Uses only process statements
| For systems whose function is algorithmic

y Structural
| Uses only component instantiation statements
| Appropriate for design entities comprised of several low-

level design entities

y Mixed
EXAMPLE OF DATAFLOW STYLE
architecture Dataflow of Full_Adder is
begin
Sum <= A xor (B xor Cin);
Cout <= (A and B) or (A and (B xor Cin));
end Dataflow;
EXAMPLE OF BEHAVIORAL STYLE
architecture Behavioral of Full_Adder is
begin
process (A, B, Cin)
begin
if A = '1' then
Sum <= B xnor Cin;
Cout <= B or Cin;
else
Sum <= B xor Cin;
Cout <= B and Cin;
end if;
end process;
end Behavioral;
EXAMPLE OF STRUCTURAL STYLE
architecture Structural of Full_Adder is
component Half_Adder is
Port ( A, B : in STD_LOGIC;
Sum, Cout : out STD_LOGIC);
end component;
signal sumsig, coutsig1, coutsig2 : STD_LOGIC;
begin
HA1: Half_Adder port map ( A, B, sumsig, coutsig1 );
HA2: Half_Adder port map ( A => sumsig,
B => Cin,
Sum => Sum,
Cout => coutsig2);
Cout <= coutsig1 or coutsig2;
end Structural;
PORT MAP
| A port map indicates how a design entity is
connected in a structural architecture.
| Each port is associated with either
y Signal in the enclosing architecture
y An expression
y Keyword open to indicate no connection
| An input port may be left open only if a default value has
been specified in its entity declaration
| Two ways
y Named association
y Positional association
PORT MAP
| Positional Association
y Signals are associated based on their relative
positions as specified in the entity’s declaration
y More concise and applicable for simple systems

| Named Association
y Each association is explicit and the listing order is of
no concern
y More readable and less error prone
SEATWORK 2-1
A B C X Y 1. Given the following
0 0 0 0 1 truth table:
0 0 1 1 0 a. Write a canonical
0 1 0 1 1 sum-of-products
0 1 1 0 0 Boolean equation for
1 0 0 1 0 each output.
1 0 1 0 0 b. Write a complete
1 1 0 0 0 dataflow VHDL
description of the
1 1 1 1 1
design entity that
accomplishes the
function defined by
the truth table.
SEATWORK 2-1

2. Write a structural VHDL description of the

diagram shown. Use named association in the
port maps. Assume that components ANDgate,
Orgate, and NOTgate already exist.
IDENTIFIERS
| A VHDL identifier is used to identify various
VHDL objects: design entities, signals,
procedures, functions, processes, etc.
| Rules:
y Case insensitive
y Can only be made up of alphabetic, numeric, and
underscore characters
y Must not be a keyword
y First character must be a letter (alphabet)
y Two underscores in succession is not allowed
IDENTIFIERS
| Usual programming rules for identifiers:
y Meaningful non-cryptic names should be used (based
on English words)
y Use mixed-case consistently
y Avoid using excessively long identifiers
y Avoid confusing identifiers
y Extended identifiers may consist of any character as
long as it is enclosed in backslashes (‘\’)
y Strings in extended identifiers are case sensitive and
must be used with extreme caution
KEYWORDS
SPACES, COMMENTS, & HEADERS
| There’s no difference between one whitespace
(space, carriage return) character or many
| Two hyphens (‘—’) are used to indicate line
comments. There are no block comments.
| Each VHDL should include a header, that
contains the ff:
y the name(s) of the design units in the file;
y file name;
y a description of the code;
y limitations and known errors;
y any operating system and tool dependencies;
y the author(s), including a full address;
y a revision list, including dates.
EXAMPLE OF A HEADER
-- Design unit : FullAdder (Entity and Architecture)
--
-- File name : FAdder.vhd
--
-- Description : Dataflow model of full adder circuit. Inputs of type
-- STD_LOGIC.
--
-- Limitations : None
--
-- System : VHDL’93
--
-- Author : Christine Bandalan
-- : Department of Computer Engineering
-- : University of San Carlos
-- : Cebu City
--
-- Revision : Version 1.0 07/12/05
OBJECTS
| Object is a named item that has a value of a
specified type
| An object’s class represents the nature of the
object and how it is used.
| VHDL classes:
y Signal – an object with a current and projected
value
y Constant – an object whose value is fix
y Variable – an object with only a current value
y File – an object that consists of a sequence of values
of a specified time
OBJECTS
| An object’s type defines the set of values the
object can assume and the set of operations that
can be performed on those values.
| Object types:
y Scalar – has a single indivisible value (either
numeric or enumerated)
y Composite – consists of a collection of elements each
with a value
y Access – provides access to objects of a given type
(like pointers)
y File – provides access to objects containing asequence
of values of a given type (such as disk files)
y Protected – provides atomic and exclusive access to
variables accessible to multiple processes (global)
SIGNALS
| Signals are objects that are used to connect
concurrent elements (such as components,
processes and concurrent assignments).
| It can be declared globally in an external package
or locally within an architecture, block or other
declarative region.
| Uses the assignment operator <= in passing
value of one signal to another
| Uses the assignment operator := in assigning
initial values
PREDEFINED bit

SCALAR TYPES boolean

character
Enumeration
Severity_level

discrete File_open_kind

File_open_status
Scalar

Integer Integer

numeric Physical time

Floating real
STD_ULOGIC
Value State Strength
U uninitialized none
X unknown forcing
0 0 forcing
1 1 forcing
Z none high impedance
W unknown weak
L 0 weak
H 1 weak
- don’t care none
STD_ULOGIC
• It is an unresolved type.
• The state value denotes its logic level.
• The strength denotes the electrical
characteristics of the source that drives the
signal. These driving strengths are:
• Forcing – signals driven by active output drivers
(such as that of a CMOS circuit)
• Weak – are used to represent signals from resistive
drivers (such as pull-up resistor, or pull-down
resistor outputs, or pass transistors)
• High impedance – represents the output of a 3-
state buffer when it is not enabled
STD_ULOGIC
• The uninitialized value is the default value
given to all std_ulogic signals before the start of
simulation.
• The unknown value is used to represent a
signal that is being driven, but whose value
cannot be determined to be a 0 or a 1.
• Don’t care is interpreted by a synthesis tool as
representing common don’t care condition used in
logic design.
RESOLVED TYPE
| A resolved type is a type declared with a
resolution function.
| A resolution function is a function that defines
the resulting (resolved) value of a signal.
| Std_logic is a subtype of std_ulogic declared in
STD_LOGIC_1164.
RESOLUTION TABLE FOR STD_LOGIC
U X 0 1 Z W L H -
U U U U U U U U U U
X U X X X X X X X X
0 U X 0 X 0 0 0 0 X
1 U X X 1 1 1 1 1 X
Z U X 0 1 Z W L H X
W U X 0 1 W W W W X
L U X 0 1 L W L W X
H U X 0 1 H W W H X
- U X X X X X X X X
USE OF STD_LOGIC VS STD_ULOGIC
| A disadvantage of using std_logic instead of
std_ulogic is that signals that ate unintentionally
multiply driven will not be detected as an eror
during compilation.
| IEEE recommends use of std_logic for the reason
that the standard expects simulator vendors to
design their simulators to optimize the
simulation of models using the resolved subtype,
but they need to optimize the simulation of
models using the unresolved types
SCALAR LITERALS
| A literal is a value that is expressed as itself
| It can be directly assigned to a signal or used in
an expression that determines the value assigned
to a signal
| Literals don’t have an explicit type

| Only the ff. literals can be used in synthesizable

descriptions:
y Character
y Enumeration
y String
y Numeric
SCALAR CONSTANTS
| A constant is an object that is assigned a value
only once, normally during declaration.
| Visibility rules are the same as for signals.

| Uses the keyword constant and the assignment

operator :=
| For example:
constant high_impedance : std_logic := ‘Z’
 Composite
COMPOSITE TYPES types

Array types Record types

Unconstrained constrained

Bit_vector string
COMPOSITE TYPE
| A composite type consists of a collection of
related elements that form either an array or a
record.
| It may contain elements that are scalar,
composite, or access type.
SOURCE
| VHDL for Engineers, Kenneth Short, Pearson
Education, Inc., 2009

| VHDL Modular Design and Synthesis of Cores

and Systems, Zainalabedin Navabi, Mc-Graw-
Hill Companies, 2007