A Compact Overview P: Recommended Books: Recommended Books

Recommended Books:
VHDL John F. Wakerlyy

— Digital design (3rd edition)
Prentice Hall, 2001
A Compact
p Overview Peter J. Ashenden
Th designer’s
The d i ’ guide
id to VHDL (2nd
(2 d edition)
di i )
Morgan Kaufmann, 2001
Peter J. Ashenden
The student
student’ss guide to VHDL
Morgan Kaufmann, 1998
James R. Armstrong and F. Gail Gray
VHDL design: Representation and synthesis (2nd edition)
Prentice Hall, 2000
Paolo.Ienne@epfl.ch Jacques Weber et Maurice Meaudre
EPFL – I&C – LAP VHDL: Du langage
g g au circuit,, du circuit au langage
g g
Masson, 1997
Roland Airiau, Jean-Michel Bergé, Vincent Olive et Jacques Rouillard
VHDL: Langage, modélisation, synthèse (2ème édition)
PPUR 1998
PPUR,
2 VHDL — A Compact Overview © Sanchez, Ienne, Kluter 2007
1 Example: A Traffic Light
System Outputs System Input (A)

Control Box
button
G button
Int od ction
Introduction %
RO O
A simple traffic-light controller

R
Finite-State
Machine
3 VHDL — A Compact Overview © Sanchez, Ienne, Kluter 2007 4 VHDL — A Compact Overview © Sanchez, Ienne, Kluter 2007
Control Box Classic Approach
Button Next Green Orange Red

Red Light State B
State light light light
B 00b
State
u Update (memory)
Button 00b 0b 00b 1b 0b 0b
Output
t Process
G=00b Process 00b 1b 01b 1b 0b 0b
t
(
(combinatorial
bi t i l 11b 01b
logic) O=01b (combinatorial Orange Light
R=10b logic) 01b X 10b 0b 1b 0b
o
n RO=11b
10b 10b X 11b 0b 0b 1b
11b X 00b 0b 1b 1b
Green Light
INPUTS FSM OUTPUTS Update Output

process process
Gate Level Implementation Signal Flow
B
B Red Light u S1
Red Light
S1
u t
t t
S0
Orange Light
o
t Orange Light n
o S0 Green Light
n Clock
Green Light Button
State 00 01 10 11 00
State B Next state Green Light Button

Orange LightButton
Red Light Button Button Next state 00 01 10 11 00
00 0 00 1 0 0 S1 S1 Red light
00 1 01 1 S1 0 S1 S10 S1 S1 S1 Orange light
S0 1
0 1
0 Green light
01 X 10 S00 0 11 1 00 S0 0 0 0 0
time
10 X 11 0 0 1 S0 0
1 0
1 Flip flop delay Undefined state Gate delay
11 X 00 S00 1 01 0 11 S0 1 1 0 1 due to cascaded
logic gates
Is This the Way to Go? Design Flow
Design engineers used this method until Hardware flow Software flow
about 1985
For simple designs this method works, but
as complexity increases new
? C++ or Java
methodologies are required Synthesizer Compiler

C
Compare gate-level
t l l designing
d i i with ith writing
iti
programs in assembly language
Gate level Assembly
We are not going to use gate-level design
methods for 1 billion transistors!
Very High-Speed Integrated Circuits (VHSIC)
?=VHDL Hardware Description Language History
Formal language for specifying digital systems,

systems equally 1980:
good at structural as behavioral level Beginning of the project, financed by DoD (400M $US)
Usage: 1982:
System description
Contracts for Intermetrics, IBM et Texas
Simulation
Conceptual modeling 1985:
Documentation Version 7.2 released public domain
Main characteristics: 1987:
Hierarchical Standard IEEE 1076 (VHDL-87)
Event-driven simulation 1993:
Modular
New version of the standard (VHDL-93)
Extensible
General language, strongly typed, similar to Ada 2001:
N
New version
i off th
the standard
t d d (VHDL
(VHDL-2001)
2001)
In This Course…
Course Simulation vs.
vs Synthesis
VHDL is a very rich language and provides Simulation: It is the process of verifying the
syntactical elements for describing: proper functionality of the VHDL description of a
Synthesizable digital systems system (similar to executing a program in C++
Functional description of complex components or Java)
(processors DSPs
(processors, DSPs, etc
etc.))
Description of libraries of elementary gates with
internal delays rise and fall times,
times etc.
etc y
Synthesis: It is the p
process of translating
g the
… VHDL description of a system into simple gates
We will only use a subset,
subset namely the (similar
(s a to
o co
compiling
p g a program
p og a in C++
C or
o
description of synthesizable zero-delay digital Java)
systems
Traffic Light in VHDL Traffic Light in VHDL

By using VHDL we can “forget”
forget Boolean algebra, we can describe The outputs are a function of only the current state (Moore FSM)
the functionality
In our FSM, next_state is a function of state and button output_process : PROCESS (state)
BEGIN
IF (state = green) THEN Green_Light <= ‘1’;
update_process : PROCESS(state,button)
Button ELSE Green_Light <= ‘0’; Button
END IF;
BEGIN
G G
IF (state = orange OR
IF (state = green) THEN
IF (button = ‘1’) THEN next_state <= orange;
Button state = red_orange) THEN Orange_Light <= ‘1’;
ELSE Orange_Light <= ‘0’;
Button
END IF;
ELSE next_state <= green;
END IF; RO O
IF (state = red OR
state = red_orange) THEN Red_Light <= ‘1’;
RO O
ELSIF (state = orange) THEN next_state <= red; ELSE Red_Light <= ‘0’;
ELSIF (state = red) THEN next_state
next state <= red_orange;
red orange; END IF;
ELSE next_state <= green; R END PROCESS output_process;
R
END IF;
END PROCESS update_process;
State State
Update (memory) Output Update (memory) Output
Process Process Process Process
(combinatorial (combinatorial (combinatorial (combinatorial
logic) logic) logic) logic)
Traffic Light in VHDL Basic Syntactical Rules
And finally, the “memory”
memory of the state has to be modelled VHDL is a case insensitive language
Note that the new state only depends on next_state and clk
VHDL has a free formatting
B tt
Button
Each command sequence should be
G
terminated by a “;”
state_process : PROCESS (clk, next_state)
Button
BEGIN
IF (clk’event AND clk=‘1’) THEN state <= next_state;
END IF;
RO O Remarks can be placed by using “--” in front
of the remark
END PROCESS state_process;
A remark terminates at the end of the line
State
Update (memory) Output
Process Process
(combinatorial (combinatorial
logic) logic)
Entity Syntax of the Entity
INPUTS FSM OUTPUTS Each ENTITY must have a library definition

B
u Red Light We will always use the ones described here
((similar to #include <stdlib.h> in C/C++)
/ )
t
t O
Orange Light
Li h
o
n Green Light LIBRARY ieee;
USE ieee
ieee.std_logic_1164.all;
std logic 1164 all;
USE ieee.std_logic_arith.all;
The “black box” is The signals going into, or coming ENTITY <entity_name> IS
called ENTITY in from the ENTITY are called ports
ports, and PORT ( … );
END <entity_name>;
VHDL are described in the PORT section
ENTITY fsm IS
PORT ( B : IN std_logic; -- Button input
RL : OUT std_logic; -- Red light output
OL : OUT std_logic; -- Orange light output Each ENTITY may have Each ENTITY requires a
GL : OUT std_logic); -- Green light output a port section unique name
END fsm;
Syntax of the Port Section (Signal) Types in VHDL
VHDL knows various types, like:
Each PORT requires a unique name Each PORT requires a signal type
Real
We will seldom (or never…)
Integer use standard types
PORT ( <port
<port_name>
name> : <port_type>
<port type> <signal_type>;
<signal type>;
Time
i
<port_name> : <port_type> <signal_type>;
. …
In this course we are only going to use the following VHDL types:
.
<port name> : <port_type>
<port_name> <port type> <signal type>;
<signal_type>; IMPORTANT NOTE:
<port_name> : <port_type> <signal_type> The last port in the PORT section STD_LOGIC Æ This is the type holds a one bit quantity (see it as being
is not terminated by a ;
);
one wire)
STD LOGIC VECTOR ((n-1) DOWNTO 0) Æ This type holds a set of
STD_LOGIC_VECTOR
Each
PORT requires a type, which can be: n-bits (see it as being a collection of n wires)
IN => The port is an input port (Read Only)
OUT => The pport is an output
p port
p ((Write Only)
y)
Furthermore we are going to use own defined types, which can
INOUT => The port is bidirectional (Read and Write) come in
i handy
h d ini FSMs
FSM ((as we will
ill later
l t see):
)
TYPE state_type IS (Green, Orange, Red, RedOrange)
TYPE hex_type
_ IS (1,2,3,4,5,6,7,8,9,A,B,C,D,E,F)
We will seldom (maybe
never…) use INOUT ports
STD LOGIC and STD_LOGIC_VECTOR

STD_LOGIC STD LOGIC VECTOR Our Entity
The STD_LOGIC
STD LOGIC and each element (“bit”)
( bit ) of the We of course need also a clock input
STD_LOGIC_VECTOR can hold nine values: for our memory elements
‘U’ = uninitialized LIBRARY ieee;

‘X’ = forcing unknown USE ieee.std_logic_1164.all;
‘0’ = forcing 0
‘1’
1 = forcing 1 ENTITY fsm IS
PORT ( CLK : IN std_logic; -- Clock input
‘Z’ = high impedance Button : IN std_logic;
‘W’ = weak unknown
Red_Light : OUT std_logic;
Orange_Light : OUT std_logic;
‘L’ = weakk 0 (pull-down)
( ll d ) Green_Light : OUT std_logic);
END fsm;
‘H’ = weak 1 (pull-up)
‘-’ = don’t care
In this course we will ONLY use and consider the values
‘U’, ‘X’, ‘0’, ‘1’ and ‘Z’ ! BUT: Where is the functionality of this black-box?
Functionality Architecture
ARCHITECTURE functional_level OF fsm IS state_process : PROCESS (clk, next_state)
RL
BEGIN
TYPE fsm_state_t IS (green,orange,red,red_orange); IF (clk’event AND clk=‘1’) THEN state <= next_state;
SIGNAL state : fsm_state_t; END IF; State
SIGNAL next_state : fsm_state_t; END PROCESS state_process; Update (memory) Output
Process G=00b
BEGIN END functional_level; B (combinatorial
Process
update_process : PROCESS(state,button)
logic)
O 01b
O=01 (combinatorial OL
BEGIN R=10b logic)
IF (state = green) THEN RO=11b
IF (button = ‘1’) THEN next_state <= orange;
ELSE next_state <= green;
END IF;
ELSIF (state = orange) THEN next_state <= red;
GL
ELSIF (state = red) THEN next_state <= red_orange;
ELSE next_state <= green; The functionality of the black box
END IF;
is described in VHDL in the The ports are defined in the
END PROCESS update_process;
ARCHITECTURE
C C section PORT section of the ENTITY declaration,
declaration
output_process : PROCESS (state)
BEGIN and are therefore inherently known in the
IF (state = green) THEN Green_Light <= ‘1’;
State ARCHITECTURE
ELSE Green_Light <= ‘0’; Update (memory) Output
END IF;
Process Process
P ARCHITECTURE implementation_1
implementation 1 OF fsm IS
IF (state = orange OR
state = red_orange) THEN Orange_Light <= ‘1’; (combinatorial (combinatorial …
ELSE Orange_Light <= ‘0’; logic) logic)
END IF;
BEGIN
IF (state = red OR …
state = red
red_orange)
orange) THEN Red
Red_Light
Light <= ‘1’;
1 ; END implementation_1;
implementation 1;
ELSE Red_Light <= ‘0’;
END IF;
END PROCESS output_process;
Architecture and Entity

Relationship Syntax of the Architecture
Each ARCHITECTURE section

Each ARCHITECTURE definition
is referenced to it’s corresponding
ENTITY can contain declarations
(Similar: int loop; in C++)
ENTITY definition by the name
Each ENTITY has at least one of this ENTITY
functional description
(ARCHITECTURE)…
ARCHITECTURE <implementation
p _name> OF <entity
y_name> IS
[Declaration Section]
BEGIN
ARCHITECTURE ARCHITECTURE ARCHITECTURE [Body]
implementation_2 implementation_1 implementation_3 END <implementation_name>;
The body of the ARCHITECTURE Each ARCHITECTURE section has

But each ENTITY can have contains the actual functionality it’s own unique implementation name
multiple functional descriptions
(ARCHITECTURE)
Declaration Section Body of an Architecture
The declaration section of an ARCHITECTURE can contain: The body of an architecture consists of:
SIGNAL declarations. Signals are the “wires” or “state” of the Implicit processes
circuit. Explicit processes
CONSTANT definitions.
d fi iti Constants
C t t are fixed
fi d value
l “wires”
“ i ” or fixed
fi d Component
C instantiations
i i i
value “state” within the circuit. Each of these topics will be used in this course and will be
COMPONENT declarations. Components give us the possibility to introduced later on
d i hierarchical.
design hi hi l
Each of these parts execute in parallel (in contrast with software
FUNCTION definitions. Functions can be used for actions which
programming languages where instructions are executed
are often required in the functional description
sequentially!)
PROCEDURE definitions. Similar to Functions also procedures
can be used.
In this course we will only use the signal,
signal constant,
constant and State
eventually the component. Update
Process
(memory) Output
Process
p will be defined later on in this course.
Each of this topics (combinatorial
logic)
g )
(combinatorial
logic)
Creation of the Body Structure Summary

Most VHDL code written and used nowadays by designers is written Each ENTITY has at
following the RTL (=Register Transfer Level) principle. In this course ENTITY least one functional
description
LIBRARY ieee; (ARCHITECTURE)…
we will only design using this principle. USE ieee.std_logic_1164.all;
The RTL principle consists of separating the sequential processes (e.g.,
memory, flip-flops and latches) from the combinatorial processes. Finally we ENTITY <entity_name> IS
PORT ( <port_name> : <port_type> <signal_type>;
ARCHITECTURE
2
ARCHITECTURE
1
ARCHITECTURE
3
connect the different processes by wires. <port_name> : <port_type> <signal_type>;
.
How do we do this: . But each ENTITY can
Identify the combinatorial and sequential elements. <port_name> : <port_type> <signal_type>; have multiple
functional descriptions
<port_name> : <port_type> <signal_type> (ARCHITECTURE)
Write the VHDL code for all these elements. );
Control that no memory action is introduced in the combinatorial elements
END <entity
y_name>;
(to be elaborated later on in this course). ARCHITECTURE <implementation_name> OF <entity_name> IS

Connect the elements by using wires (e.g., signals). [Declaration Section]
State BEGIN
Update (memory) Output [Body]
Process Process END <implementation_name>;
(combinatorial (combinatorial
logic) l i )
logic)
2 Remember RTL
We will divide each system (ARCHITECTURE) into:
Combinatorial elements
The body of an ARCHITECTURE Elementary sequential elements (memory, flip-flop and/or latches)
Interconnects ((wires)
i )
Each combinatorial and sequential element form a PROCESS inside
the ARCHITECTURE and all execute in parallel
p
Signals as wires
INPUTS SYSTEM OUTPUTS
Operators
State State
Statements (memory,
(memory
flip-flops combinatorial
(memory,
(memory
flip-flops
or or
logic
Events latches) latches)
Implicit processes State

(memory,
combinatorial flip-flops combinatorial
or
logic latches) logic
In this lecture we will concentrate on the combinatorial elements

Combinatorial Element: The Full

Adder Signal Syntax
The Full Adder is a typical example of combinatorial logic Each SIGNAL has Each SIGNAL has a signal type
its own unique name (see the previous lecture on these types)
SUM = A XOR B XOR Cin
A SUM
The SIGNAL
connects PORT Each connection (wire) SIGNAL <signal_name>[, <signal_name>,…] : <signal_type>;
and/or B corresponds to
operators a SIGNAL
Cin Cout And all SIGNAL’s are defined in the It is good practice, but not required,
declaration section of the ARCHITECTURE to prefix all signal names with “s_”
Cout = A.B+Cin.(A XOR B)
Remember how the entity is defined:

LIBRARY ieee; ARCHITECTURE <implementation_name> OF <entity_name> IS
USE ieee.std_logic_1164.all;
USE ieee
ieee.std_logic_arith.all;
std logic arith all;
[Declaration Section]
ENTITY full_adder IS
PORT ( A : IN std_logic; -- A input
B : IN std_logic; -- B input
BEGIN
Cin : IN std_logic; -- Carry input [Body]
SUM : OUT std_logic; -- Sum output END <implementation_name>;
Cout : OUT std_logic); -- Carry output
END full_adder;
Signal Properties Constant Signal Assignments
Each SIGNAL mayy and must be assigned g only
y once. Compare
p with an We can assign
g a constant value to a signal
g of type
yp std_logic
g byy using
g
electrical wire, if we connect a wire to two outputs, we create a short circuit <signal_name> <= ’<value>’;
and “blow the fuse” Examples
s_a <= ’0’;
A SIGNAL is assigned a value by s_a <= ’1’
’1’;
s_a <= ’X’;
<signal_name> <= <source>; s_a <= ’Z’;
Each SIGNAL can be used multiple times.times We can connect a wire to one
We can assign a constant value to a signal of type std_logic_vector by
or multiple loads, of course using <signal_name> <= ”<value>”;
Each SIGNAL is global to its and only its ARCHITECTURE Examples
A SIGNAL whichhi h is
i assigned
i d with
ith a constant
t t value,
l can be
b declared
d l d ini the
th s_vect
t <
<= ”0101”
”0101”; -- Assign
A i bi
binary value
l
declaration section of the ARCHITECTURE as a CONSTANT s_vect <= X”F”; -- Assign hexadecimal value
s_vect <= to_stdlogicvector(-3,4); -- Assign integer –3 in 4
CONSTANT <constant_name> : <signal
g _type>
yp := <value>; -- bit representation
We can use the macro OTHERS for signals of type std_logic_vector
Example
s_vect <= ”0000”; equals s_vect <= (OTHERS => ’0’);
It is good practice
practice, but not required
required, Some synthesizers do not allow for
to prefix all constant names with “c_” constant declaration, and thus
we will seldom use the constant
Signals and Ports Ports: A Typical Mistake

Each connection that is used in the bodyy of the ARCHITECTURE,, is
called a SIGNAL
PORT’s are defined in the ENTITY and can be used in the body of A SUM
the ARCHITECTURE
B Cpropagate
PORT’s have a slightly odd behavior:
Input PORT’s can only be read, but they cannot be assigned a value Cin Cout
Output PORT’s
PORT s can only be assigned a value,
value but they cannot be
read
The SIGNALS
SUM <= A XOR B XOR Cin;

s_x8 <= (A AND B) OR (Cin AND (A XOR B));
A SUM Cout <= (A AND B) OR (Cin AND (A XOR B));
Cout <= s_x8;
Cpropagate <= Cin AND Cout;
Cpropagate <= s_x8 AND Cin;
B Cpropagate
NO
Cin Cout As Cout is an output port, it cannot We have to introduce an explicit signal s_x8,
be read! Hence this is not a correct to make a correct implementation
implementation
The PORTS
Different Implementations Operators
Extensive signal
g usage:
g “Merging”
g g of signals:
g To model the functionality of the system, VHDL provides several
s_x1
s_x2
<=
<=
A;
B; operators:
Logical:
s_x3 <= Cin;
s_x4 <= s_x1 XOR s_x2;
s_x5 <= s_x4 XOR s_x3; and or nand nor xor xnor not
SUM <= s_x5; SUM <= A XOR B XOR Cin;
Comparison:
s_x6 <= s_x1 AND s_x2; These operators we will use
s_x7 <= s_x3 AND s_x4; = /= < <= > >=
s_x8 <= s_x6 OR s_x7; s_x8 <= (A AND B) OR (Cin AND (A XOR B));
Cout <= s
s_x8;
x8; Cout <= s
s_x8;
x8; Concatenation:
s_x9 <= s_x8 AND s_x3; &
Cpropagate <= s_x9; Cpropagate <= s_x8 AND Cin;
Arithmetic: We will only use + and – of this set
+ - * / mod rem of operators
Shifting: These operators “make no sense” in

A s_x4 SUM
s_x1 s_x5 std_logic and std_logic_vector types,
sll srl sla sra rol ror
s_x9 as we can use the concatenation
B Cpropagate
s x8 must stay
s_x8 stay, Sign:
s x2
s_x2
s_x7 as it has the output + -
s_x8
PORT cannot be These operators we will not use
Cin
s_x3 s_x6
Cout Diverse:
read! abs **
Sizes and Concatenation Signed and Unsigned

An operator can only work on signals of the same size The types std_logic
std logic and std_logic_vector
std logic vector can hold signed,
SIGNAL
SIGNAL
s_x1
s_x2
:
:
std_logic_vector(3
std_logic_vector(3
DOWNTO
DOWNTO
0);
0);
but also unsigned values, the synthesizer has no information on this
SIGNAL
SIGNAL
s_x3
s_x4
:
:
std_logic_vector(3
std_logic_vector(3
DOWNTO
DOWNTO
0);
0); To make clear to the synthesizer what implementation we want
SIGNAL
SIGNAL
s
s_x5
x5
s_x6
:
:
std
std_logic_vector(1
logic vector(1
std_logic;
DOWNTO 0);
when
h we use arithmetic
ith ti operators,
t we can use the
th type
t castt
s_x3 <= s_x1 XOR s_x2; --This is correct as s_x1,s_x2 and s_x3 all contain 4 bits (wires)
signed(<signal_name>) or unsigned(<signal_name>) in
s_x4 <= s_x1 OR s_x5; --This is incorrect as s_x5 only contains 2 bits, whilst s_x1 and s_x4 contain 4
s_x6 <= s_x3 OR s_x4; --This is incorrect as the result of s_x3 OR s_x4 is 4 bits, each operator does
the <source> section (we cannot mix them!)
Examples
--a bitwise operation (similar to | in C++; || does not exist in VHDL)
We can increase the size of a signal by using the concatenation Correct:

operator
p &, or the wire selection operation
p () s_signed_add
_ _ <= signed( s_in1
_ ) + signed( s_in2);
_
s_unsigned_add <= unsigned( s_in3 ) + unsigned( s_in4 );
SIGNAL s_x1 : std_logic_vector(3 DOWNTO 0); s_signed_multiply <= signed( s_in1 ) * signed( s_in2);
SIGNAL s_x2 : std_logic_vector(3 DOWNTO 0);
SIGNAL s_x3 : std_logic_vector(3 DOWNTO 0);
s_unsigned_multiply <= unsigned( s_in3 ) * unsigned( s_in4 );
SIGNAL s_x4 : std_logic
g _vector(3
( DOWNTO 0);
)
SIGNAL s_x5 : std_logic_vector(1 DOWNTO 0); NOT TO BE USED:
SIGNAL s_x6 : std_logic;
s_mixed_add <= signed( s_in1 ) + unsigned( s_in3 );
s_x3 <= s_x1 XOR s_x2; --This is correct as s_x1, s_x2 and s_x3 all contain 4 bits (wires) s_mixed_multiply <= signed( s_in1 ) * unsigned( s_in3 );
s_x4 <= s_x1 OR (”00” & s_x5); --This is correct as (“00” & s_x5), s_x1 and s_x4 all contain 4 bits
s x6 <= s
s_x6 s_x3(0)
x3(0) OR s
s_x4(2);
x4(2); --This
This is correct as s
s_x6,
x6 ss_x3(0)
x3(0) and s
s_x4(2)
x4(2) all contain 1 bit
Special Operations Back to the Full Adder
We can perform shifting by using concatenation LIBRARY ieee;
; LIBRARY ieee;
;
USE ieee.std_logic_1164.all; USE ieee.std_logic_1164.all;
SIGNAL s_x1 : std_logic_vector( 3 DOWNTO 0 ); USE ieee.std_logic_arith.all; USE ieee.std_logic_arith.all;
SIGNAL s_x2 : std_logic_vector( 3 DOWNTO 0 );
SIGNAL s_x3 : std_logic_vector( 3 DOWNTO 0 ); ENTITY full_adder IS ENTITY full_adder IS
PORT ( A : IN std_logic; -- A input PORT ( A : IN std_logic; -- A input
s_x1
s x1 <
<= s
s_x2(
x2( 2 DOWNTO 0 ) & ”0”; -- s
s_x1
x1 is s
s_x2
x2 << 1; hence s
s_x1
x1 = s
s_x2*2…
x2*2 B : IN std
std_logic;
logic; -- B input B : IN std
std_logic;
logic; -- B input
s_x3 <= s_x2(3) & s_x2( 3 DOWNTO 1 ); -- s_x3 is signed(s_x2) >> 1; hence s_x3 = s_x2/2… Cin : IN std_logic; -- Carry input Cin : IN std_logic; -- Carry input
SUM : OUT std_logic; -- Sum output SUM : OUT std_logic; -- Sum output
We can use concatenation to extract the carry out Cprop: OUT std_logic; -- Carry propagate Cprop: OUT std_logic; -- Carry propagate
Cout : OUT
END full_adder;
std_logic); -- Carry output
? Cout : OUT
END full_adder;
std_logic); -- Carry output
=
SIGNAL s
s_a
a : std
std_logic;
logic;
SIGNAL s_b : std_logic;
ARCHITECTURE implementation_1 OF full_adder IS ARCHITECTURE implementation_1 OF full_adder IS
SIGNAL s_add : std_logic_vector( 1 DOWNTO 0 );
SIGNAL s_sum : std_logic;
SIGNAL s_x8 : std_logic; SIGNAL s_x8 : std_logic;
SIGNAL s_cout: std_logic;
BEGIN BEGIN
s_add <= unsigned(”0” & s_a) + unsigned(”0” & s_b);
SUM <= A XOR B XOR Cin; Cprop <= s_x8 AND Cin;
s_sum <= s_add(0);
s_x8 <= (A AND B) OR (Cin AND (A XOR B)); SUM <= A XOR B XOR Cin;
s_cout <= s_add(1);
Cout <= s_x8; Cout <= s_x8;
Cprop <= s_x8 AND Cin; s_x8 <= (A AND B) OR (Cin AND (A XOR B));
Important
p note: END implementation_1; END implementation_1;
For the operators + and -, the synthesizer does not know if a

Remember that by definition: YES, both full_adder’s are equal!
std_logic_vector is in a signed, or an unsigned representation
All elements in the body of an As all PROCESS’es and COMPONENT’s execute
We use the typecasts unsigned(<std_logic_vector>) and ARCHITECTURE are either in pparallel,, their order does not matter!
signed(<std_logic_vector>) to tell the synthesizer the representation PROCESS’s or COMPONENT’s. Note: For Java and C++ this is different,
This architecture thus contains 4 as they execute all lines sequentially!
(implicit) PROCESS’es
Back to the Full Adder Sensitivity and Trigger

LIBRARY ieee;
;
A process is said to be sensitive to a wire, if and only if the output
USE ieee.std_logic_arith.all; of the process can change in case the wire changes its value
ENTITY full_adder IS Process 1 is sensitive to A,B and Cin Process 5 is
PORT ( A : IN std_logic; -- A input sensitive to s_x8,
but also to s_x9!
B : IN std
std_logic;
logic; -- B input
Cin : IN std_logic; -- Carry input A SUM
SUM : OUT std_logic; -- Sum output
Process 1
Cprop: OUT std_logic; -- Carry propagate
A P1 OSC
Cout : OUT std_logic); -- Carry output B Process Cprop P5 s_x9
END full_adder; 4 B SUM Process 3 is
ARCHITECTURE implementation_1 OF full_adder IS Process 2 P.
s_x8 s_x8 sensitive to s_x8
Cin 3 Cout P2 Cout
SIGNAL s_x8 : std_logic; P3
BEGIN
Cp op
Cprop
Cin P4
Cout <= s_x8;
Cprop <= s_x8 AND Cin;
END implementation_1;
Process 2 is sensitive to A,B and Cin Process 4 is sensitive to s_x8 and Cin
Intuition:
All elements in hardware will execute A process is triggered if one or more wires, to which the process is
in parallel, hence the processes must
also
l execute t in
i parallel
ll l sensitive change its/their value
sensitive,
Delta Delta
Assume that every PROCESS has an input to output delay of δ We assumed the input and output delay to be δ, but in reality δ Æ 0
If A, B, and/or Cin change(s) at time t1, this is how simulation goes Delta is defined as the number of δ steps we need to take until all
s_x9 PROCESS’es produce a stable output (no process is triggered):
Note:
A P1 P5 OSC δ does not PROCESS 1 and d 2 produce
d a stable
t bl output
t t after
ft DDelta
lt = 1
B SUM include the gate PROCESS 3 and 4 produce a stable output after Delta = 2
s_x8 delays, as we are
P2
P3
3 Cout working with a PROCESS 5 does not p produce a stable output,
p , as it is triggered
gg over
zero delay model! and over again
Cin P4 Cprop
An ARCHITECTURE which does not produce a stable output on all
its PROCESS
PROCESS’eses, after a finite number of δ steps,
steps is called instable,
instable
And this continues
The change on A triggers A and cannot be simulated.
process 1 and process 2 B infinitely
Cin We will only use stable ARCHITECTURE’s,
After one δ process 1 and
OSC h
hence Delta
D l isi finite
fi i Notes:
SUM 1. We can of course model oscillators (instable
process 2 produce a After two δ process 3 and
s_x8 architectures), by also modeling the gate delay,
stable output, and trigger 4 produce stable outputs,
Cout but process 5 is triggered
but this is outside the scope
p of this course
processes 3
3, 4 and 5
Cprop by s_x9
2. Instable architectures can be implemented in
t1
hardware, and are thus synthesizable
Processes and Components Implicit Processes

Each “element” or “box” in our ARCHITECTURE BODY is a process:
p We
e have
a e see
seen PROCESS’es
OC SS es in tthe
e form:
o
<process_name> : PROCESS ([Sensitivity List])
[Declaration Section] Explicit form <signal_name> <= <source>;
BEGIN
[Process description] This are so called implicit PROCESS’s
END PROCESS <process_name>;
Implicit form Implicit PROCESS’es are by definition sensitive to all
SIGNAL’s ’ listed
li t d in
i the
th <source>, andd thus
th are
<signal_name> <= <source>;
triggered by a change on these signals
Implicit PROCESS
PROCESS’es es are not embedded into a PROCESS
Or a component: container
In implicit PROCESS’es the <source> consists of
<component_reference>
<component reference> : <component_name>
<component name>
GENERIC MAP ( [generic mappings] )
signals and operators
PORT MAP ( [Port connections] ); There exists a special implicit PROCESS, the WHEN …
ELSE …; construct
Implicit Constructs Summary
Syntax: The ELSE part must always be present, as otherwise

the SIGNAL is not always assigned a value!
The SIGNAL
SIGNAL’ss in the body of an ARCHITECTURE
represent the wires of the system connecting the PORT’s
p
and the operators
<signal_name> <= <source1> WHEN <condition> ELSE
<source2>;
<signal_name> <= <source1> WHEN <condition1> ELSE
<source2> WHEN <condition2> ELSE
<sourcen>;
…
The operators define the functionality of the system
Question:
Example: What is the hardware representing this construct?
SIGNAL’s may only be assigned once
Answer:
next_state <= green WHEN state = red_orange OR <source1> 1
(state = green AND
button /= ‘1’) ELSE
<signal_name> Each element in the body of an ARCHITECTURE is a
PROCESS or a COMPONENT
<source2> 0
orange WHEN state = green AND
button = ‘1’ ELSE
red WHEN state = orange ELSE <condition>
es and COMPONENT
COMPONENT’ss execute in parallel
red_orange;
PROCESS
PROCESS’es
3 Reminder
Processes and Components
Each “element” or “box” in our ARCHITECTURE BODY is a process:

p
<process_name> : PROCESS ([Sensitivity List])
Sequential Logic [Declaration Section] Explicit form
BEGIN
[Process description]
END PROCESS <process_name>;
Implicit form
Explicit processes
Latches <signal_name> <= <source>;
Flip flops and Registers
Flip-flops
Or a component:
Components
<component_reference>
<component reference> : <component_name>
<component name>
GENERIC MAP ( [generic mappings] )
PORT MAP ( [Port connections] );
Explicit Process Explicit Process Syntax
A PROCESS which is not implicit is called an Each PROCESS has a Each PROCESS can have
explicit PROCESS unique name a sensitivity list
An explicit PROCESS can be converted to one or

multiple implicit one(s) if and only if it contains <process_name> : PROCESS ([Sensitivity List])
only
l combinatorial
bi t i l logic
l i [Declaration Section]
An explicit PROCESS is not inherently sensible BEGIN

[Process body]
to its inputs END PROCESS <process_name>;
The body of an explicit PROCESS executes in

program order Each PROCESS has Each PROCESS can have
a body a declaration section
Note:
We can also just write END PROCESS;
Sensitivity List Declaration Section

Explicit
p PROCESS’s are not inherentlyy sensitive to their inputs,
p , to make the The declaration section of an explicit PROCESS can
PROCESS sensitive to (and thus trigger on a change of) a SIGNAL, the
name of this SIGNAL can be put in the sensitivity list: contain VARIABLE instantiations
example_process : PROCESS ( <signal_name>, … , <signal_name> )

The declaration section of an explicit PROCESS can
Example, a two input NAND gate:
contain SIGNAL instantiations, which are local to this
We will ALWAYS put all signals which appear after
PROCESS
SIGNAL s_a : std_logic; all assignment commands (<= and :=) in the
SIGNAL s_b
_ : std_logic;
_ sensitivity list of an explicit process
SIGNAL s_q : std_logic; The
Th declaration
d l ti section
ti off an explicit
li it PROCESS can
Nand_gate1 : PROCESS ( s_a , s_b ) Nand_gate2 : PROCESS ( s_a ) contain CONSTANT instantiations, which are local to this
BEGIN ? BEGIN PROCESS
=
s_q <= s_a NAND s_b; s_q <= s_a NAND s_b;
END PROCESS nand_gate1; END PROCESS nand_gate2;
In hardware both are equal, but NOT in simulation!

nand_gate2 will only be triggered by a change on s_a, and not by a change on s_b!
The synthesizer will issue a warning when it encounters such a construct
Variables Back to the Full Adder
VARIABLE’ss have a similar syntax as SIGNAL

VARIABLE SIGNAL’ss U i implicit
Using i li it PROCESS’es:
’ U i one explicit
Using li it PROCESS:
LIBRARY ieee;
VARIABLE <variable_name>[, <variable_name>,…] : <signal_type>; USE ieee.std_logic_1164.all;
LIBRARY ieee;
USE ieee
ieee.std_logic_arith.all;
std logic arith all;
It is good practice, but not required, ENTITY full_adder IS
to prefix all variable names with “v_” PORT ( A : IN std_logic; -- A input
Cin : IN std_logic; -- Carry input
Cin : IN std_logic; -- Carry input
SUM : OUT std_logic;
g ; -- Sum output
p
VARIABLE’s can only exist inside an explicit PROCESS,
SUM : OUT std_logic;
td l i -- S
Sum output
t t
and are local to this PROCESS
END full_adder;
END full_adder;
ARCHITECTURE implementation_1 OF full_adder IS
=
ARCHITECTURE implementation
p _2 OF full_adder IS
SIGNAL s_x8 : std_logic;
BEGIN
VARIABLE’s can be assigned a value by using BEGIN

adder : PROCESS( A , B , Cin )
VARIABLE v_x8 : std_logic;
BEGIN
Cout <= s_x8;
v_x8 := (A AND B) OR (Cin AND (A XOR B));
Cprop <= s_x8 AND Cin;
Cout <= v_x8;
<variable_name> := <source>; END implementation_1;
Cprop <= v_x8 AND Cin;
END PROCESS adder;
Note: END implementation_2;
We need := and not <=
Back to the Full Adder Statements and Signals
With implicit PROCESS

PROCESS’ss, we have seen that: Note that the <
<= has a different meaning in an implicit PROCESS,
BEGIN BEGIN and when used in a statement
Using <= in an implicit process means assign immediately
SUM <= A XOR B XOR Cin; Cprop <= s_x8 AND Cin;
=
s_x8 <= (A AND B) OR (Cin AND (A XOR B)); SUM <= A XOR B XOR Cin;
Using <
<= in a statement means schedule an assignment
Cout <= s_x8; Cout <= s_x8;
Cprop <= s_x8 AND Cin; s_x8 <= (A AND B) OR (Cin AND (A XOR B));
END implementation_1; END implementation_1;
The explicit process has some “strange” behavior when it comes to
What about the explicit
p PROCESS’s: signals
g The process “fixes”
fixes the values of the signals when
BEGIN BEGIN
adder : PROCESS( A , B , Cin ) adder : PROCESS( A , B , Cin ) it is triggered
?
example : PROCESS( A , B , C )
The statements within the process schedule
VARIABLE v_x8 : std_logic; VARIABLE v_x8 : std_logic;
BEGIN BEGIN BEGIN
C <= A OR B; new assignments to a signal
=
SUM <= A XOR B XOR Cin; Cprop <= v_x8 AND Cin;
v_x8 := (A AND B) OR (Cin AND (A XOR B)); SUM <= A XOR B XOR Cin; IF (A AND B) = ’1’ THEN
Cout <= v_x8; Cout <= v_x8; C <= ’0’; The process assigns the new values of the signals
when it is finished
Cprop <= v_x8 AND Cin; v_x8 := (A AND B) OR (Cin AND (A XOR B)); END IF;
END PROCESS adder; END PROCESS adder; X2 <= C;
END PROCESS example;
END implementation_2; END implementation_2;
Hence, X2 is assigned the old value of C
Th
These two
t implementations
i l t ti are nott equal!
l!
Note further that X2 and C are only assigned once a value,
Due to the fact that these are now inside the body of the process, they are namely at the end of the PROCESS
not any longer separate processes,
processes but statements.
statements And statements
execute in program order inside the body of an explicit process, and not
in parallel! We will go into more detail
Statements and Variables Explicit Constructs
It
It’ss getting even more “strange”
strange , as VARIABLE’ss are Similar to the WHEN … ELSE …;
; construct,
construct we have the
assigned immediately in explicit PROCESS’es, hence := IF … END IF; construct in an explicit process:
means assign g immediately y
Thus IMPORTANT:
:= can ONLY be used with variables! IF <condition> THEN [Statement(s)]; This version should only be used
END IF; to model sequential logic
example : PROCESS( A , B , C )
(
(we will
ill see more in
i the
th nextt lecture)
l t )
VARIABLE v_x : std_logic; IF <condition> THEN [Statement(s)];
BEGIN ELSE [Statement(s)];
v_x := A OR B; END IF;
IF (A AND B) = ’1’
1 THEN The difference with Signals and Variables,
Variables is that
v_x := ’0’; v_x is now assigned immediately a value, and not IF <condition> THEN [Statement(s)]; Each of these sections should
END IF; just scheduled a new assignment! ELSIF <condition2> THEN [Statement(s)];
X2 <= v_x; contain at least one, but can
ELSE [Statement(s)]; contain multiple statements
c <= v_x;; END IF;
END PROCESS example;
Explicit Constructs Size Macros

Nested IF … END IF; constructs can be replaced by Assume following code
the CASE … END CASE; construct: s_bitwise_and(0) <= s_input_vector(0) AND s_bit;
s_bitwise_and(1) <= s_input_vector(1) AND s_bit;
The <case_variable> can be a s_bitwise_and(2) <= s_input_vector(2) AND s_bit;
PORT or a VARIABLE
SIGNAL PORT,
SIGNAL, s_bitwise_and(3)
bit i d(3) <=
< s_input_vector(3)
i t t (3) AND s_bit;
bit
Each of these sections should

We can simplify this code by using a macro
CASE <case_variable> IS
WHEN <value1> => [Statement(s)]; contain at least one, but can For implicit process usage
WHEN <value2> => [Statement(s)]; contain
t i multiple
lti l statements
t t t
Bitwise_and : FOR n IN 3 DOWNTO 0 GENERATE
WHEN <value3> => [Statement(s)];
s_bitwise_and(n) <= s_input_vector(n) AND s_bit;
… Note:
WHEN OTHERS => [Statement(s)]; The OTHERS case covers for all END GENERATE;
These macros do not equal
situations
it ti nott covered
dbby the
th to a for loop as used in
END CASE;
previous WHEN lines (similar For explicit process usage
C++, they merely
default: in C++). FOR n IN 3 DOWNTO 0 LOOP help us to compact our
It is not required, but highly s_bitwise_and(n) <= s_input_vector(n) AND s_bit; code
recommended to use! END LOOP;
Note, the CASE … END CASE; construct has no Syntax

equivalent implicit form!
FOR <variable> IN <value1> DOWNTO <value2> LOOP <id> : FOR <variable> IN <value1> DOWNTO <value2> GENERATE
[Statement(s)] [Statement(s)]
END LOOP; END GENERATE;
Explicit Process usage Implicit Process usage

A SUM
Summary Summary B Cprop
Cin s_x8
Cout
We now have all the tools to create combinatorial logic:

LIBRARY ieee;
All processes are USE ieee.std_logic_1164.all;
SIGNAL’s Æ the wires of the system defined in the body of
Operators Æ to model the functionality of the system the architecture ENTITY full_adder
full adder IS
PROCESS’es Æ which execute in parallel, and can be of two B : IN
Cin : IN
std_logic;
std_logic;
--
--
B input
Carry input
forms SUM : OUT
Cprop: OUT
std_logic;
std_logic;
--
--
Sum output
Carry propagate
Implicit: These processes are not contained in a PROCESS container Cout : OUT std_logic); -- Carry output
and are in the form <signal_name> <= <source> END full_adder;
Explicit: These processes are in a PROCESS container, and the ARCHITECTURE implementation_1 OF full_adder IS We have three
The order of the process implicit processes
statements in these pprocesses execute in program
p g order (implicit and explicit) SIGNAL s
s_x8
x8 : std
std_logic;
logic;
Statements Æ help to express conditional logic (= does not matter as they BEGIN
multiplexing) execute in parallel
Implicit usage only: The WHEN … ELSE … construct Cout <= s_x8;
Explicit usage only: The IF … END IF; and CASE … END CASE;
C
Cprop <
<= s_x8
8 AND Ci
Cin;
constructs make_s8 : PROCESS( A , B , Cin )

BEGIN
Size Macros Æ helps to compact our code s_x8 <= (A AND B) OR (Cin AND (A XOR B));
END PROCESS make_s8;
_ We have one
IImplicit
li it usage: The
Th GENERATE
G macro explicit process
Explicit usage: The LOOP macro
END implementation_1;
Latches Latches
Let
Let’ss look at the simulation behavior
latch : PROCESS ( clock , d )
BEGIN d q
IF (
(clock = ’1’)
) THEN BEGIN d q
q <= d; IF (clock = ’1’) THEN
END IF; q <= d;
clock END IF;
END PROCESS latch;
END PROCESS latch; clock
The latch is transparent The latch is transparent

If clock equals 1, q will be scheduled to be the value of d. At the clock
end of the PROCESS,
PROCESS q will be assigned the value of d d
q
If clock equals 0, q will not be scheduled any value because the
IF statement is skipped. Therefore at the end of the PROCESS, q WX X X X XY Z Z Z ZW X X X
will keep its previous value! W clock triggers the PROCESS and clock = 1 Æ q takes the value of d
X an event on d triggers the PROCESS and clock = 1 Æ q takes the value of d
Y an event on clock triggers the PROCESS and clock = 0 Æ q keeps its previous value
We described a memory element, namely a latch Z an event on d triggers the PROCESS and clock = 0 Æ q keeps its previous value
Latches vs
vs. Muxes Combinatorial or Sequential?
Both latches and multiplexers
p are described through
g IF statements latch : PROCESS ( clock , d ) mux : PROCESS ( s , in0 , in1 )
BEGIN
BEGIN IF (s = ’1’) THEN
latch : PROCESS ( clock , d ) mux : PROCESS ( s , in0 , in1 ) IF (clock = ’1’) THEN out <= in1;
q <= d; ELSE
BEGIN BEGIN out <= in0;
IF (clock = ’1’)
1 ) THEN IF (s = ’1’)
1 ) THEN END IF;
END IF;
q <= d; out <= in1; END PROCESS latch; END PROCESS mux;
END IF; ELSE
END PROCESS latch; out <= in0; start start
END IF;
END PROCESS mux;
d q clock ? S ?
in0
out
in1 assign q assign out assign out
clock
s
The important difference is that in muxes there is always a new end end
value assigned to signals or variables, whereas in latches
At least one path between start and end of the All paths between start and end of the process
sometimes nothingg is assigned
g and theyy keepp their old value process contains no assignment to q contain at least one assignment to out
(Æ memory!) Î q is the output of a Î out is the output a
sequential element combinatorial element
Testing for Edges Flip-flops and Registers

A signal
g with an ’EVENT modifier evaluates to true if there has
been a high to low or low to high transition
flipflop : PROCESS ( clock , d )
BEGIN d q
IF (
(clock’EVENT and clock = ’1’)
) THEN
IF (<signal
(<signal_name>’EVENT
name>’EVENT AND <signal_name>
<signal name> = ’1’) THEN
q <= d;
…
END IF;
END IF;
END PROCESS flipflop;
If there is a transition and after it clock equals 1, q will be

IF (<signal_name>’EVENT AND <signal_name> = ’0’) THEN
…
END IF;
; scheduled to be the value of d, and at the end of the PROCESS, q
will be assigned the value of d
An EVENT should always be used in combination with a test for the If there is no transition or clock equals 0, q will not be scheduled
current level,
level because
beca se the
there
eeexists
ists no hardware component any value
l because
b the
h IF statement is skipped.
k d Therefore
h f at the
h
which is triggered by both transitions end of the PROCESS, q will keep its previous value!
IF <signal
g _name>’EVENT THEN
…
END IF;
? We also described a memory element, but this time it is a flip-flop
Flip-flops and Registers A Bad Idea for a Flip-Flop
Let
Let’ss look at the simulation behavior One could think of exploiting the sensitivity list…
list
flipflop : PROCESS ( clock , d ) flipflop : PROCESS ( clock , d )

BEGIN d q BEGIN d q
IF (clock’EVENT
( l k and
d clock
l k = ’1’)
1 ) THEN IF (clock’EVENT and clock = ’1’) THEN
q <= d; q <= d;
END IF; END IF;
END PROCESS flipflop; END PROCESS flipflop;
By the way, this is useless but not wrong…

This looks like a latch…
clock d q Simulators
d
q
bad_flipflop : PROCESS ( clock )
BEGIN
NO understand
this…
…but most
IF (clock = ’1’)
1 ) THEN synthesizers
WX X X X XY Z Z Z ZWX X X q <= d; ignore
W clock triggers the PROCESS and there is a raising edge Æ q takes the value of d END IF; d q sensitivity
X an event on d triggers the PROCESS but there is no event on clock Æ q keeps its previous value END PROCESS bad_flipflop; lists and
Y an event on clock triggers the PROCESS but it is not a raising edge Æ q keeps its previous value understand
Z an event on d triggers the PROCESS but there is no event on clock Æ q keeps its previous value …but it is only executed if clock changes! clock this!
(normally a latch has d too here…)
Reset Registers Signals,

Registers, Signals and Ordering
A register does not have an initial state, and therefore needs a reset Delay_line : PROCESS ( clock , reset , d ,
s_q1 , s_q2 )
Delay_line : PROCESS ( clock , reset , d ,
s_q1 , s_q2 )
Two types of reset Note: We will always use registers with a reset, either
BEGIN BEGIN
?
IF (clock’EVENT AND clock = ’1’) THEN IF (clock’EVENT AND clock = ’1’) THEN
synchronous or asynchronous
Synchronous reset IF (reset = ’1’) THEN s_q1 <= ’0’; IF (reset = ‘1’) THEN s_q1 <= ’0’;
reset
=
s_q
q2 <= ’0’;
; s_q
q2 <= ’0’;
;
flipflop : PROCESS ( clock , reset , d ) q3 <= ’0’; q3 <= ’0’;
BEGIN ELSE q3 <= s_q2; ELSE s_q1 <= d;
IF (clock’EVENT and clock = ’1’) THEN 0 s_q2 <= s_q1; s_q2 <= s_q1;
IF (reset = ’1’) THEN q <= ’0’; d q s_q1 <= d; q3 <= s_q2;
ELSE q <= d; END IF; END IF;
END IF; END IF; END IF;
END IF; END PROCESS Delay_line; END PROCESS Delay_line;
YES!
The two processes are identical
Asynchronous reset reset
0 0 0
flipflop : PROCESS ( clock , reset , d )
d D Q D Q D Q q3
BEGIN q s_q1 s_q2
IF (reset = ’1’) THEN q <= ’0’; d
ELSIF (clock’EVENT and clock = ’1’) THEN
q <= d; reset
END IF;
clock
Registers Variables,
Registers, Variables and Ordering Components
Delay_line : PROCESS ( clock , reset , d , Delay_line : PROCESS ( clock , reset , d ,
s_q
q1 )
VARIABLE v_q2 : std_logic;
s_q
q1 )
VARIABLE v_q2 : std_logic;
We can introduce a hierarchy by using COMPONENT
COMPONENT’ss
BEGIN BEGIN
A COMPONENT is a reference to an ENTITY
?
IF (clock’EVENT AND clock = ’1’) THEN IF (clock’EVENT AND clock = ’1’) THEN
IF (reset = ’1’) THEN s_q1 <= ’0’; IF (reset = ’1’) THEN s_q1 <= ’0’;
v q2 := ’0’;
v_q2
q3
0 ;
<= ’0’; =
v q2 := ’0’;
v_q2
q3
0 ;
<= ’0’;
The syntax of a COMPONENT is
ELSE q3 <= v_q2; ELSE s_q1 <= d;
v_q2 := s_q1; v_q2 := s_q1;
s_q1 <= d; q3 <= v_q2; Each COMPONENT requires
q a
END IF; END IF;
END IF; END IF;
COMPONENT <entity_name>
PORT ( … );
reference to the corresponding
END PROCESS Delay_line; END PROCESS Delay_line;
END COMPONENT; ENTITY
NO!
The two processes are different!
Each COMPONENT has the same
reset reset
0 0
port section as it’s corresponding ENTITY
0 0 0
D Q s_q1 D Q v_q2 D Q q3 D Q s_q1 D Q q3
The COMPONENT is defined in the declaration section of

d d
clock
an ARCHITECTURE
clock
Summary
Usage of Components Signals Variables,
Signals, Variables and Parallelism
LIBRARY ieee;
LIBRARY ieee;
For a SIGNAL, the <
<= has a different meaning in an implicit
ENTITY adder IS
PROCESS, and when used in a statement (explicit PROCESS)
PORT ( A
B
:
:
IN
IN
std_logic_vector( 3 DOWNTO 0);
std_logic_vector( 3 DOWNTO 0);
Using <= in an implicit PROCESS means assign immediately
B : IN
Cin : IN
std
std_logic;
logic;
std_logic;
--
--
B input
Carry input
Cin :
SUM :
IN
OUT
std
std_logic;
logic;
std_logic_vector( 3 DOWNTO 0); Using <
<= in an explicit PROCESS means schedule an assignment
SUM : OUT std_logic; -- Sum output Cout : OUT std_logic);
Cout : OUT std_logic); -- Carry output END adder;
A VARIABLE can only exist in an explicit PROCESS, and is assigned

END full_adder;
ARCHITECTURE implementation OF adder IS
a value by using :=, where

ARCHITECTURE implementation
i l t ti OF full_adder
f ll dd IS COMPONENT full_adder
f ll dd
BEGIN PORT ( A : IN std_logic; -- A input
SUM <= A XOR B XOR Cin; Cin : IN std_logic; -- Carry input Using := means assign immediately
Cout <= (A AND B) OR (Cin AND (A XOR B)); SUM : OUT std_logic; -- Sum output
Cout : OUT std_logic);
g -- Carry
y output
p
END implementation; END COMPONENT;
Implicit and explicit PROCESS’es are defined inside the body of the
The reference to the ENTITY full_adder with SIGNAL s_carries : std_logic_vector( 4 DOWNTO 0);
the same PORT section

BEGIN
s_carries(0) <= Cin;
ARCHITECTURE, and execute in parallel
fas : FOR n IN 3 DOWNTO 0 GENERATE
Each COMPONENT needs fa : full_adder
a unique identifier
PORT MAP ( A
B
=> A(n),
=> B(n), Statements are defined inside the body of an explicit PROCESS, and
And here we connect the PORT
PORT’ss of the
Cin => s_carries(n),
SUN => SUM(n), execute in program order
Cout => s_carries(n+1) );
component with the SIGNAL’s to form the new END GENERATE fas;
functionality END implementation;
Summary
Sequential Components
Sequential elements can only be made by using an explicit PROCESS
Memory elements can only be introduced in case the PROCESS

contains a non-assigned
non assigned path
path, otherwise a multiplexer is described
There are two kinds of memory elements:

Latches:
BEGIN
IF (clock = ’1’) THEN d q
q <= d;
END IF;
END PROCESS latch;
clock
Flip-flops:
p p
flipflop : PROCESS ( clock , d )
BEGIN
IF (clock’EVENT and clock = ’1’) THEN d q
q <= d;
END IF;
;
85 VHDL — A Compact Overview © Sanchez, Ienne, Kluter 2007

A Compact Overview P: Recommended Books: Recommended Books

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A Compact Overview P: Recommended Books: Recommended Books

Enviado por

Direitos autorais:

Formatos disponíveis

Recommended Books:

VHDL  John F. Wakerlyy

2 VHDL — A Compact Overview © Sanchez, Ienne, Kluter 2007

1 Example: A Traffic Light

System Outputs System Input (A)

A simple traffic-light controller

Button Next Green Orange Red

INPUTS FSM OUTPUTS Update Output

Gate Level Implementation Signal Flow

State B Next state Green Light Button

methodologies are required Synthesizer Compiler

Very High-Speed Integrated Circuits (VHSIC)

?=VHDL Hardware Description Language History

 Formal language for specifying digital systems,

Traffic Light in VHDL Traffic Light in VHDL

A remark terminates at the end of the line

Entity Syntax of the Entity

INPUTS FSM OUTPUTS Each ENTITY must have a library definition

STD LOGIC and STD_LOGIC_VECTOR

 ‘U’ = uninitialized LIBRARY ieee;

Architecture and Entity

Each ARCHITECTURE section

The body of the ARCHITECTURE Each ARCHITECTURE section has

Creation of the Body Structure Summary

(to be elaborated later on in this course). ARCHITECTURE <implementation_name> OF <entity_name> IS

Implicit processes State

In this lecture we will concentrate on the combinatorial elements

Combinatorial Element: The Full

 Remember how the entity is defined:

Signals and Ports Ports: A Typical Mistake

SUM <= A XOR B XOR Cin;

 Shifting: These operators “make no sense” in

Sizes and Concatenation Signed and Unsigned

 We can increase the size of a signal by using the concatenation Correct:

 For the operators + and -, the synthesizer does not know if a

Back to the Full Adder Sensitivity and Trigger

Processes and Components Implicit Processes

[Declaration Section] Explicit form <signal_name> <= <source>;

 Syntax: The ELSE part must always be present, as otherwise

 Each “element” or “box” in our ARCHITECTURE BODY is a process:

Sequential Logic [Declaration Section] Explicit form

An explicit PROCESS can be converted to one or

An explicit PROCESS is not inherently sensible BEGIN

The body of an explicit PROCESS executes in

Sensitivity List Declaration Section

example_process : PROCESS ( <signal_name>, … , <signal_name> )

In hardware both are equal, but NOT in simulation!

VARIABLE’ss have a similar syntax as SIGNAL

 VARIABLE’s can be assigned a value by using BEGIN

We need := and not <=

Back to the Full Adder Statements and Signals

With implicit PROCESS

Explicit Constructs Size Macros

Each of these sections should

 Note, the CASE … END CASE; construct has no  Syntax

Explicit Process usage Implicit Process usage

Summary Summary B Cprop

 We now have all the tools to create combinatorial logic:

constructs make_s8 : PROCESS( A , B , Cin )

The latch is transparent The latch is transparent

Testing for Edges Flip-flops and Registers

 If there is a transition and after it clock equals 1, q will be

flipflop : PROCESS ( clock , d ) flipflop : PROCESS ( clock , d )

VHDL John F. Wakerlyy

Formal language for specifying digital systems,

A remark terminates at the end of the line

‘U’ = uninitialized LIBRARY ieee;

Remember how the entity is defined:

Shifting: These operators “make no sense” in

We can increase the size of a signal by using the concatenation Correct:

For the operators + and -, the synthesizer does not know if a

Syntax: The ELSE part must always be present, as otherwise

Each “element” or “box” in our ARCHITECTURE BODY is a process:

An explicit PROCESS can be converted to one or

An explicit PROCESS is not inherently sensible BEGIN

The body of an explicit PROCESS executes in

VARIABLE’s can be assigned a value by using BEGIN

Note, the CASE … END CASE; construct has no Syntax

We now have all the tools to create combinatorial logic:

If there is a transition and after it clock equals 1, q will be

The COMPONENT is defined in the declaration section of

A VARIABLE can only exist in an explicit PROCESS, and is assigned

Memory elements can only be introduced in case the PROCESS

There are two kinds of memory elements: