VHDL Cookbook

The
VHDL
Cookbook
Fi rst Edi ti on
Peter J . Ashenden
The VHDL Cookbook
Fi rst Edi ti on
Jul y, 1990
Peter J. Ashenden
Dept. Computer Sci ence
Uni versi ty of Adel ai de
South Austr al i a
1990, Peter J. Ashenden

Contents i i i
Contents
1. I ntr oducti on ............................................................................ 1-1
1.1. Descr i bi ng Str uctur e ....................................................... 1-2
1.2. Descr i bi ng Behavi our ...................................................... 1-2
1.3. Di screte Event Ti me Model ............................................... 1-3
1.4. A Qui ck Exampl e............................................................ 1-3
2. VHDL i s Li ke a Pr ogr ammi ng Language ................................... 2-1
2.1. Lexi cal El ements ............................................................ 2-1
2.1.1. Comments .......................................................... 2-1
2.1.2. I denti fi er s........................................................... 2-1
2.1.3. Number s ............................................................ 2-1
2.1.4. Char acter s.......................................................... 2-2
2.1.5. Str i ngs ............................................................... 2-2
2.1.6. Bi t Str i ngs........................................................... 2-2
2.2. Data Types and Objects .................................................... 2-2
2.2.1. I nteger Types ...................................................... 2-3
2.2.2. Physi cal Types..................................................... 2-3
2.2.3. Fl oati ng Poi nt Types............................................. 2-4
2.2.4. Enumer ati on Types.............................................. 2-4
2.2.5. Ar r ays................................................................ 2-5
2.2.6. Recor ds .............................................................. 2-7
2.2.7. Subtypes ............................................................. 2-7
2.2.8. Object Decl arati ons .............................................. 2-8
2.2.9. Attri butes ........................................................... 2-8
2.3. Expr essi ons and Oper ator s .............................................. 2-9
2.4. Sequenti al Statements ....................................................2-10
2.4.1. Var i abl e Assi gnment..........................................2-10
2.4.2. I f Statement .......................................................2-11
2.4.3. Case Statement...................................................2-11
2.4.4. Loop Statements .................................................2-12
2.4.5. Nul l Statement ...................................................2-13
2.4.6. Asser ti ons .........................................................2-13
2.5. Subpr ogr ams and Packages ............................................2-13
2.5.1. Pr ocedur es and Functi ons ...................................2-14
2.5.2. Over l oadi ng .......................................................2-16
2.5.3. Package and Package Body Decl arati ons ...............2-17
2.5.4. Package Use and Name Vi si bi l i ty .........................2-18
i v The VHDL Cookbook
Contents (cont'd)
3. VHDL Descr i bes Str uctur e ........................................................3-1
3.1. Enti ty Decl arati ons ..........................................................3-1
3.2. Ar chi tectur e Decl ar ati ons ................................................3-3
3.2.1. Si gnal Decl ar ati ons ..............................................3-3
3.2.2. Bl ocks .................................................................3-4
3.2.3. Component Decl ar ati ons .......................................3-5
3.2.4. Component I nstanti ati on ......................................3-6
4. VHDL Descr i bes Behavi our .......................................................4-1
4.1. Si gnal Assi gnment..........................................................4-1
4.2. Processes and the Wai t Statement .....................................4-2
4.3. Concur r ent Si gnal Assi gnment Statements........................4-4
4.3.1. Condi ti onal Si gnal Assi gnment .............................4-5
4.3.2. Sel ected Si gnal Assi gnment ..................................4-6
5. Model Or gani sati on ..................................................................5-1
5.1. Desi gn Uni ts and Li br ar i es...............................................5-1
5.2. Confi gur ati ons ................................................................5-2
5.3. Compl ete Desi gn Exampl e................................................5-5
6. Advanced VHDL ......................................................................6-1
6.1. Si gnal Resol uti on and Buses .............................................6-1
6.2. Nul l Tr ansacti ons ...........................................................6-2
6.3. Gener ate Statements........................................................6-2
6.4. Concur r ent Asser ti ons and Pr ocedur e Cal l s.......................6-3
6.5. Enti ty Statements ............................................................6-4
7. Sampl e Model s: The DP32 Processor ...........................................7-1
7.1. I nstr ucti on Set Ar chi tectur e.............................................7-1
7.2. Bus Ar chi tectur e.............................................................7-4
7.3. Types and Enti ty ..............................................................7-6
7.4. Behavi our al Descr i pti on ...................................................7-9
7.5. Test Bench .................................................................... 7-18
7.6. Regi ster Tr ansfer Ar chi tectur e....................................... 7-24
7.6.1. Mul ti pl exor ....................................................... 7-25
7.6.2. Tr anspar ent Latch ............................................. 7-25
7.6.3. Buffer ............................................................... 7-26
7.6.4. Si gn Extendi ng Buffer ......................................... 7-28
7.6.5. Latchi ng Buffer .................................................. 7-28
7.6.6. Pr ogr am Counter Regi ster .................................. 7-28
7.6.7. Regi ster Fi l e ...................................................... 7-29
Contents v
Contents (cont'd)
7.6.8. Ari thmeti c & Logi c Uni t ......................................7-30
7.6.9. Condi ti on Code Compar ator .................................7-34
7.6.10. Structural Archi tecture of the DP32 ......................7-34
1-1
1. Introduction
VHDL i s a l anguage for descr i bi ng di gi tal el ectr oni c systems. I t ar ose
out of the Uni ted States Governments Very Hi gh Speed I ntegrated Ci rcui ts
(VHSI C) program, i ni ti ated i n 1980. I n the course of thi s program, i t
became cl ear that there was a need for a standard l anguage for descri bi ng
the str uctur e and functi on of i ntegr ated ci r cui ts (I Cs). Hence the VHSI C
Har dwar e Descr i pti on Language (VHDL) was devel oped, and subsequentl y
adopted as a standard by the I nsti tute of El ectri cal and El ectroni c
Engi neers (I EEE) i n the US.
VHDL i s desi gned to fi l l a number of needs i n the desi gn process.
Fi rstl y, i t al l ows descri pti on of the structure of a desi gn, that i s how i t i s
decomposed i nto sub-desi gns, and how those sub-desi gns ar e
i nterconnected. Secondl y, i t al l ows the speci fi cati on of the functi on of
desi gns usi ng fami l i ar pr ogr ammi ng l anguage for ms. Thi r dl y, as a
resul t, i t al l ows a desi gn to be si mul ated before bei ng manufactured, so that
desi gner s can qui ckl y compar e al ter nati ves and test for cor r ectness wi thout
the del ay and expense of hardware prototypi ng.
The purpose of thi s bookl et i s to gi ve you a qui ck i ntroducti on to VHDL.
Thi s i s done by i nformal l y descri bi ng the faci l i ti es provi ded by the
l anguage, and usi ng exampl es to i l l ustrate them. Thi s bookl et does not
ful l y descri be every aspect of the l anguage. For such fi ne detai l s, you
shoul d consul t the I EEE Standard VHDL Language Reference Manual.
However, be warned: the standard i s l i ke a l egal document, and i s very
di ffi cul t to read unl ess you are al ready fami l i ar wi th the l anguage. Thi s
bookl et does cover enough of the l anguage for substanti al model wri ti ng. I t
assumes you know how to wr i te computer pr ogr ams usi ng a conventi onal
pr ogr ammi ng l anguage such as Pascal , C or Ada.
The remai ni ng chapters of thi s bookl et descri be the vari ous aspects of
VHDL i n a bottom-up manner. Chapter2 descri bes the faci l i ti es of VHDL
whi ch most r esembl e nor mal sequenti al pr ogr ammi ng l anguages. These
i ncl ude data types, var i abl es, expr essi ons, sequenti al statements and
subpr ogr ams. Chapter 3 then exami nes the faci l i ti es for descr i bi ng the
structure of a modul e and how i t i t decomposed i nto sub-modul es.
Chapter4 covers aspects of VHDL that i ntegrate the programmi ng
l anguage features wi th a di screte event ti mi ng model to al l ow si mul ati on of
behavi our. Chapter5 i s a key chapter that shows how al l these faci l i ti es are
combi ned to form a compl ete model of a system. Then Chapter6 i s a pot-
pour r i of mor e advanced featur es whi ch you may fi nd useful for model i ng
mor e compl ex systems.
Throughout thi s bookl et, the syntax of l anguage features i s presented i n
Backus-Naur For m (BNF). The syntax speci fi cati ons ar e dr awn fr om the
I EEE VHDL Standard. Concrete exampl es are al so gi ven to i l l ustrate the
l anguage featur es. I n some cases, some al ter nati ves ar e omi tted fr om BNF
1-2 The VHDL Cookbook
A
B
Y
F
A
B
Y
G
A
B
Y
H
A
B
Y
I
F
A
B
Y
(a)
(b)
Figure1-1. Example of a structural description.
producti ons where they are not di rectl y rel evant to the context. For thi s
r eason, the ful l syntax i s i ncl uded i n Appendi xA, and shoul d be consul ted
as a r efer ence.
1.1. Describing Structure
A di gi tal el ectroni c system can be descri bed as a modul e wi th i nputs
and/or outputs. The el ectri cal val ues on the outputs are some functi on of
the val ues on the i nputs. Fi gure1-1(a) shows an exampl e of thi s vi ew of a
di gi tal system. The modul e F has two i nputs, A and B, and an output Y.
Usi ng VHDL termi nol ogy, we cal l the modul e F a desi gn entity, and the
i nputs and outputs are cal l ed ports.
One way of descri bi ng the functi on of a modul e i s to descri be how i t i s
composed of sub-modul es. Each of the sub-modul es i s an instance of some
enti ty, and the ports of the i nstances are connected usi ng signals.
Fi gure1-1(b) shows how the enti ty F mi ght be composed of i nstances of
enti ti es G, H and I. Thi s ki nd of descri pti on i s cal l ed a structural
descri pti on. Note that each of the enti ti es G, H and I mi ght al so have a
str uctur al descr i pti on.
1.2. Describing Behaviour
I n many cases, i t i s not appropri ate to descri be a modul e structural l y.
One such case i s a modul e whi ch i s at the bottom of the hi erarchy of some
other str uctur al descr i pti on. For exampl e, i f you ar e desi gni ng a system
usi ng I C packages bought from an I C shop, you do not need to descri be the
i nter nal str uctur e of an I C. I n such cases, a descr i pti on of the functi on
performed by the modul e i s requi red, wi thout reference to i ts actual
i nternal structure. Such a descri pti on i s cal l ed a functional or behavioural
descr i pti on.
To i l l ustrate thi s, suppose that the functi on of the enti ty F i n
Fi gure1-1(a) i s the excl usi ve-or functi on. Then a behavi oural descri pti on of
F coul d be the Bool ean functi on
Y = A . B + A . B
More compl ex behavi ours cannot be descri bed purel y as a functi on of
i nputs. I n systems wi th feedback, the outputs are al so a functi on of ti me.
VHDL sol ves thi s probl em by al l owi ng descri pti on of behavi our i n the form
1. I ntroduction 1-3
of an executabl e pr ogr am. Chapter s2 and4 descr i be the pr ogr ammi ng
l anguage faci l i ti es.
1.3. Discrete Event Time Model
Once the structure and behavi our of a modul e have been speci fi ed, i t i s
possi bl e to si mul ate the modul e by executi ng i ts bevi oural descri pti on. Thi s
i s done by si mul ati ng the passage of ti me i n di screte steps. At some
si mul ati on ti me, a modul e i nput may be sti mul ated by changi ng the val ue
on an i nput port. The modul e reacts by runni ng the code of i ts behavi oural
descri pti on and schedul i ng new val ues to be pl aced on the si gnal s
connected to i ts output ports at some l ater si mul ated ti me. Thi s i s cal l ed
schedul i ng a transaction on that si gnal . I f the new val ue i s di fferent from
the previ ous val ue on the si gnal , an event occur s, and other modul es wi th
i nput ports connected to the si gnal may be acti vated.
The si mul ati on starts wi th an initialisation phase, and then proceeds by
r epeati ng a two-stage simulation cycle. I n the i ni ti al i sati on phase, al l
si gnal s are gi ven i ni ti al val ues, the si mul ati on ti me i s set to zero, and each
modul es behavi our pr ogr am i s executed. Thi s usual l y r esul ts i n
tr ansacti ons bei ng schedul ed on output si gnal s for some l ater ti me.
I n the fi rst stage of a si mul ati on cycl e, the si mul ated ti me i s advanced to
the earl i est ti me at whi ch a transacti on has been schedul ed. Al l
tr ansacti ons schedul ed for that ti me ar e executed, and thi s may cause
events to occur on some si gnal s.
I n the second stage, al l modul es whi ch r eact to events occur r i ng i n the
fi r st stage have thei r behavi our pr ogr am executed. These pr ogr ams wi l l
usual l y schedul e fur ther tr ansacti ons on thei r output si gnal s. When al l of
the behavi our pr ogr ams have fi ni shed executi ng, the si mul ati on cycl e
r epeats. I f ther e ar e no mor e schedul ed tr ansacti ons, the whol e si mul ati on
i s compl eted.
The purpose of the si mul ati on i s to gather i nformati on about the
changes i n system state over ti me. Thi s can be done by runni ng the
si mul ati on under the contr ol of a simulation monitor. The moni tor al l ows
si gnal s and other state i nformati on to be vi ewed or stored i n a trace fi l e for
l ater anal ysi s. I t may al so al l ow i nteracti ve steppi ng of the si mul ati on
pr ocess, much l i ke an i nter acti ve pr ogr am debugger .
1.4. A Quick Example
I n thi s secti on we wi l l l ook at a smal l exampl e of a VHDL descri pti on of
a two-bi t counter to gi ve you a feel for the l anguage and how i t i s used. We
start the descri pti on of an enti ty by speci fyi ng i ts external i nterface, whi ch
i ncl udes a descri pti on of i ts ports. So the counter mi ght be defi ned as:
entity count2 is
generic (prop_delay : Time := 10 ns);
port (clock : in bit;
q1, q0 : out bit);
end count2;
Thi s speci fi es that the enti ty count2 has one i nput and two outputs, al l of
whi ch are bi t val ues, that i s, they can take on the val ues '0' or '1'. I t al so
defi nes a generi c constant cal l ed prop_delay whi ch can be used to control the
operati on of the enti ty (i n thi s case i ts propagati on del ay). I f no val ue i s
T_FLIPFLOP
CK Q
INVERTER
A Y
T_FLIPFLOP
CK Q
COUNT2
CLOCK Q0
Q1
FF1
FF0
INV_FF0
BIT_0
BIT_1
INV
Figure1-2. Structure of count2.
expl i ci tl y gi ven for thi s val ue when the enti ty i s used i n a desi gn, the defaul t
val ue of 10ns wi l l be used.
An i mpl ementati on of the enti ty i s descri bed i n an archi tecture body.
There may be more than one archi tecture body correspondi ng to a si ngl e
enti ty speci fi cati on, each of whi ch descri bes a di fferent vi ew of the enti ty.
For exampl e, a behavi oural descri pti on of the counter coul d be wri tten as:
architecture behaviour of count2 is
begi n
count_up: process (clock)
variable count_value : natural := 0;
begi n
if clock = '1' then
count_value := (count_value + 1) mod 4;
q0 <= bit'val(count_value mod 2) after prop_delay;
q1 <= bit'val(count_value / 2) after prop_delay;
end if;
end process count_up;
end behaviour;
I n thi s descri pti on of the counter, the behavi our i s i mpl emented by a
process cal l ed count_up, whi ch i s sensi ti ve to the i nput clock. A process i s a
body of code whi ch i s executed whenever any of the si gnal s i t i s sensi ti ve to
changes val ue. Thi s process has a vari abl e cal l ed count_value to store the
current state of the counter. The vari abl e i s i ni ti al i zed to zero at the start of
si mul ati on, and retai ns i ts val ue between acti vati ons of the process. When
the clock i nput changes from '0' to '1', the state vari abl e i s i ncremented, and
transacti ons are schedul ed on the two output ports based on the new val ue.
The assi gnments use the gener i c constant prop_delay to determi ne how l ong
after the cl ock change the transacti on shoul d be schedul ed. When control
reaches the end of the process body, the process i s suspended unti l another
change occur s on clock.
The two-bi t counter mi ght al so be descri bed as a ci rcui t composed of two
T-fl i p-fl ops and an i nverter, as shown i n Fi gure1-2. Thi s can be wri tten i n
VHDL as:
1. I ntroduction 1-5
architecture structure of count2 is
component t_flipflop
port (ck : in bit; q : out bit);
end component;
component inverter
port (a : in bit; y : out bit);
end component;
signal ff0, ff1, inv_ff0 : bit;
begi n
bit_0 : t_flipflop port map (ck => clock, q => ff0);
inv : inverter port map (a => ff0, y => inv_ff0);
bit_1 : t_flipflop port map (ck => inv_ff0, q => ff1);
q0 <= ff0;
q1 <= ff1;
end structure;
I n thi s ar chi tectur e, two component types ar e decl ar ed, t_flipflop and
inverter, and three i nternal si gnal s are decl ared. Each of the components i s
then i nstanti ated, and the ports of the i nstances are mapped onto si gnal s
and ports of the enti ty. For exampl e, bit_0 i s an i nstance of the t_flipflop
component, wi th i ts ck port connected to the clock port of the count2 enti ty,
and i ts q port connected to the i nternal si gnal ff0. The l ast two si gnal
assi gnments update the enti ty ports whenever the val ues on the i nternal
si gnal s change.
2-1
2. VHDL is Like a Programming Language
As menti oned i n Secti on 1.2, the behavi our of a modul e may be descri bed
i n pr ogr ammi ng l anguage for m. Thi s chapter descr i bes the faci l i ti es i n
VHDL whi ch ar e dr awn fr om the fami l i ar pr ogr ammi ng l anguage
r eper toi r e. I f you ar e fami l i ar wi th the Ada pr ogr ammi ng l anguage, you
wi l l noti ce the si mi l ari ty wi th that l anguage. Thi s i s both a conveni ence
and a nui sance. The conveni ence i s that you dont have much to l earn to
use these VHDL faci l i ti es. The probl em i s that the faci l i ti es are not as
comprehensi ve as those of Ada, though they are certai nl y adequate for most
model i ng pur poses.
2.1. Lexical Elements
2.1.1. Comments
Comments i n VHDL start wi th two adjacent hyphens (--) and extend to
the end of the l i ne. They have no part i n the meani ng of a VHDL
descr i pti on.
2.1.2. Identifiers
I denti fi er s i n VHDL ar e used as r eser ved wor ds and as pr ogr ammer
defi ned names. They must confor m to the r ul e:
i denti fi er ::= l etter { [ under l i ne ] l etter _or _di gi t }
Note that case of l etters i s not consi dered si gni fi cant, so the i denti fi ers cat
and Cat ar e the same. Under l i ne char acter s i n i denti fi er s ar e si gni fi cant,
so This_Name and ThisName are di fferent i denti fi ers.
2.1.3. Numbers
Li teral numbers may be expressed ei ther i n deci mal or i n a base
between two and si xteen. I f the l i teral i ncl udes a poi nt, i t represents a real
number , other wi se i t r epr esents an i nteger . Deci mal l i ter al s ar e defi ned
by:
deci mal _l i ter al ::= i nteger [ . i nteger ] [ exponent ]
i nteger ::= di gi t { [ underl i ne ] di gi t }
exponent ::= E [ + ] i nteger | E - i nteger
Some exampl es ar e:
0 1 123_456_789 987E6 -- integer literals
0.0 0.5 2.718_28 12.4E-9 -- real literals
Based l i teral numbers are defi ned by:
based_l i teral ::= base #based_i nteger [ . based_i nteger ] #[ exponent ]
base ::= i nteger
based_i nteger ::= extended_di gi t { [ under l i ne ] extended_di gi t }
extended_di gi t ::= di gi t | l etter
The base and the exponent are expressed i n deci mal . The exponent
i ndi cates the power of the base by whi ch the l i teral i s mul ti pl i ed. The
l etters A to F (upper or l ower case) are used as extended di gi ts to represent
10 to 15. Some exampl es:
2#1100_0100# 16#C4# 4#301#E1 -- the integer 196
2#1.1111_1111_111#E+11 16#F.FF#E2 -- the real number 4095.0
2.1.4. Characters
Li ter al char acter s ar e for med by encl osi ng an ASCI I char acter i n
si ngl e-quote mar ks. For exampl e:
'A' '*' ''' ' '
2.1.5. Strings
Li ter al str i ngs of char acter s ar e for med by encl osi ng the char acter s i n
doubl e-quote marks. To i ncl ude a doubl e-quote mark i tsel f i n a stri ng, a
pai r of doubl e-quote marks must be put together. A stri ng can be used as a
val ue for an object whi ch i s an ar r ay of char acter s. Exampl es of str i ngs:
"A string"
"" -- empty string
"A string in a string: ""A string"". " -- contains quote marks
2.1.6. Bit Strings
VHDL provi des a conveni ent way of speci fyi ng l i teral val ues for arrays of
type bit ('0's and '1's, see Secti on 2.2.5). The syntax i s:
bi t_str i ng_l i ter al ::= base_speci fi er " bi t_val ue "
base_speci fi er ::= B | O | X
bi t_val ue ::= extended_di gi t { [ under l i ne ] extended_di gi t }
Base speci fi er B stands for bi nary, O for octal and X for hexadeci mal . Some
exampl es:
B"1010110" -- length is 7
O"126" -- length is 9, equivalent to B"001_010_110"
X"56" -- length is 8, equivalent to B"0101_0110"
2.2. Data Types and Objects
VHDL provi des a number of basi c, or scalar, types, and a means of
for mi ng composite types. The scal ar types i ncl ude number s, physi cal
quanti ti es, and enumer ati ons (i ncl udi ng enumer ati ons of char acter s), and
there are a number of standard predefi ned basi c types. The composi te types
provi ded are arrays and records. VHDL al so provi des access types
(poi nters) and files, al though these wi l l not be ful l y descri bed i n thi s bookl et.
A data type can be defi ned by a type decl arati on:
ful l _type_decl ar ati on ::= type i denti fi er is type_defi ni ti on ;
type_defi ni ti on ::=
scal ar _type_defi ni ti on
| composi te_type_defi ni ti on
| access_type_defi ni ti on
| fi l e_type_defi ni ti on
scal ar _type_defi ni ti on ::=
enumer ati on_type_defi ni ti on | i nteger _type_defi ni ti on
| fl oati ng_type_defi ni ti on | physi cal _type_defi ni ti on
2. VHDL is Like a Programming Language 2-3
composi te_type_defi ni ti on ::=
ar r ay_type_defi ni ti on
| r ecor d_type_defi ni ti on
Exampl es of di fferent ki nds of type decl arati ons are gi ven i n the fol l owi ng
secti ons.
2.2.1. Integer Types
An i nteger type i s a range of i nteger val ues wi thi n a speci fi ed range.
The syntax for speci fyi ng i nteger types i s:
i nteger _type_defi ni ti on ::= r ange_constr ai nt
r ange_constr ai nt ::= range r ange
r ange ::= si mpl e_expr essi on di r ecti on si mpl e_expr essi on
di recti on ::= to | downto
The expressi ons that speci fy the range must of course eval uate to i nteger
number s. Types decl ar ed wi th the keywor d to are cal l ed ascending r anges,
and those decl ar ed wi th the keywor d downto are cal l ed descending r anges.
The VHDL standard al l ows an i mpl ementati on to restri ct the range, but
requi res that i t must at l east al l ow the range 2147483647 to +2147483647.
Some exampl es of i nteger type decl ar ati ons:
type byte_int is range 0 to 255;
type signed_word_int is range 32768 to 32767;
type bit_index is range 31 downto 0;
There i s a predefi ned i nteger type cal l ed integer. The range of thi s type i s
i mpl ementati on defi ned, though i t i s guaranteed to i ncl ude 2147483647 to
+2147483647.
2.2.2. Physical Types
A physi cal type i s a numer i c type for r epr esenti ng some physi cal
quanti ty, such as mass, l ength, ti me or vol tage. The decl arati on of a
physi cal type i ncl udes the speci fi cati on of a base uni t, and possi bl y a
number of secondary uni ts, bei ng mul ti pl es of the base uni t. The syntax for
decl ar i ng physi cal types i s:
physi cal _type_defi ni ti on ::=
r ange_constr ai nt
units
base_uni t_decl ar ati on
{ secondar y_uni t_decl ar ati on }
end units
base_uni t_decl ar ati on ::= i denti fi er ;
secondar y_uni t_decl ar ati on ::= i denti fi er = physi cal _l i ter al ;
physi cal _l i ter al ::= [ abstr act_l i ter al ] unit_name
Some exampl es of physi cal type decl ar ati ons:
type length is range 0 to 1E9
units
um;
mm = 1000 um;
cm = 10 mm;
m = 1000 mm;
in = 25.4 mm;
ft = 12 in;
yd = 3 ft;
rod = 198 in;
chain = 22 yd;
furlong = 10 chain;
end units;
type resistance is range 0 to 1E8
units
ohms;
kohms = 1000 ohms;
Mohms = 1E6 ohms;
end units;
The predefi ned physi cal type time i s i mportant i n VHDL, as i t i s used
extensi vel y to speci fy del ays i n si mul ati ons. I ts defi ni ti on i s:
type time is range implementation_defined
units
fs;
ps = 1000 fs;
ns = 1000 ps;
us = 1000 ns;
ms = 1000 us;
sec = 1000 ms;
min = 60 sec;
hr = 60 min;
end units;
To wri te a val ue of some physi cal type, you wri te the number fol l owed by
the uni t. For exampl e:
10 mm 1 rod 1200 ohm 23 ns
2.2.3. Floating Point Types
A fl oati ng poi nt type i s a di screte approxi mati on to the set of real
number s i n a speci fi ed r ange. The pr eci si on of the appr oxi mati on i s not
defi ned by the VHDL l anguage standard, but must be at l east si x deci mal
di gi ts. The range must i ncl ude at l east 1E38 to +1E38. A fl oati ng poi nt
type i s decl ared usi ng the syntax:
fl oati ng_type_defi ni ti on := r ange_constr ai nt
type signal_level is range 10.00 to +10.00;
type probability is range 0.0 to 1.0;
There i s a predefi ned fl oati ng poi nt type cal l ed real. The range of thi s
type i s i mpl ementati on defi ned, though i t i s guaranteed to i ncl ude 1E38 to
+1E38.
2.2.4. Enumeration Types
An enumerati on type i s an ordered set of i denti fi ers or characters. The
i denti fi er s and char acter s wi thi n a si ngl e enumer ati on type must be
di sti nct, however they may be reused i n several di fferent enumerati on
types.
The syntax for decl ar i ng an enumer ati on type i s:
enumer ati on_type_defi ni ti on ::= ( enumer ati on_l i ter al { , enumer ati on_l i ter al } )
enumer ati on_l i ter al ::= i denti fi er | char acter _l i ter al
type logic_level is (unknown, low, undriven, high);
type alu_function is (disable, pass, add, subtract, multiply, divide);
type octal_digit is ('0', '1', '2', '3', '4', '5', '6', '7');
Ther e ar e a number of pr edefi ned enumer ati on types, defi ned as fol l ows:
type severity_level is (note, warning, error, failure);
type boolean is (false, true);
type bit is ('0', '1');
type character is (
NUL, SOH, STX, ETX, EOT, ENQ, ACK, BEL,
BS, HT, LF, VT, FF, CR, SO, SI,
DLE, DC1, DC2, DC3, DC4, NAK, SYN, ETB,
CAN, EM, SUB, ESC, FSP, GSP, RSP, USP,
' ', '!', '"', '#', '$', '%', '&', ''',
'(', ')', '*', '+', ',', '-', '.', '/',
'0', '1', '2', '3', '4', '5', '6', '7',
'8', '9', ':', ';', '<', '=', '>', '?',
'@', 'A', 'B', 'C', 'D', 'E', 'F', 'G',
'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O',
'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
'X', 'Y', 'Z', '[', '\', ']', '^', '_',
'`', 'a', 'b', 'c', 'd', 'e', 'f', 'g',
'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
'x', 'y', 'z', '{', '|', '}', '~', DEL);
Note that type character i s an exampl e of an enumerati on type contai ni ng a
mi xtur e of i denti fi er s and char acter s. Al so, the char acter s '0' and '1' ar e
member s of both bit and character . Where '0' or '1' occur i n a program, the
context wi l l be used to determi ne whi ch type i s bei ng used.
2.2.5. Arrays
An array i n VHDL i s an i ndexed col l ecti on of el ements al l of the same
type. Arrays may be one-di mensi onal (wi th one i ndex) or mul ti -
di mensi onal (wi th a number of i ndi ces). I n addi ti on, an array type may be
constr ai ned, i n whi ch the bounds for an i ndex ar e establ i shed when the
type i s defi ned, or unconstrai ned, i n whi ch the bounds are establ i shed
subsequentl y.
The syntax for decl ari ng an array type i s:
ar r ay_type_defi ni ti on ::=
unconstr ai ned_ar r ay_defi ni ti on | constr ai ned_ar r ay_defi ni ti on
unconstr ai ned_ar r ay_defi ni ti on ::=
array ( i ndex_subtype_defi ni ti on { , i ndex_subtype_defi ni ti on } )
of element_subtype_i ndi cati on
constr ai ned_ar r ay_defi ni ti on ::=
array i ndex_constr ai nt of element_subtype_i ndi cati on
i ndex_subtype_defi ni ti on ::= type_mar k range <>
i ndex_constr ai nt ::= ( di scr ete_r ange { , di scr ete_r ange } )
di scr ete_r ange ::= discrete_subtype_i ndi cati on | r ange
Subtypes, referred to i n thi s syntax speci fi cati on, wi l l be di scussed i n detai l
i n Secti on2.2.7.
Some exampl es of constr ai ned ar r ay type decl ar ati ons:
type word is array (31 downto 0) of bit;
type memory is array (address) of word;
type transform is array (1 to 4, 1 to 4) of real;
type register_bank is array (byte range 0 to 132) of integer;
An exampl e of an unconstr ai ned ar r ay type decl ar ati on:
type vector is array (integer range <>) of real;
The symbol <> (cal l ed a box) can be thought of as a pl ace-hol der for the
i ndex range, whi ch wi l l be fi l l ed i n l ater when the array type i s used. For
exampl e, an object mi ght be decl ared to be a vector of 20 el ements by gi vi ng
i ts type as:
vector(1 to 20)
There are two predefi ned array types, both of whi ch are unconstrai ned.
They are defi ned as:
type string is array (positive range <>) of character;
type bit_vector is array (natural range <>) of bit;
The types positive and natural are subtypes of integer, defi ned i n Secti on2.2.7
bel ow. The type bit_vector i s parti cul arl y useful i n model i ng bi nary coded
r epr esentati ons of val ues i n si mul ati ons of di gi tal systems.
An el ement of an array object can referred to by i ndexi ng the name of
the object. For exampl e, suppose a and b are one- and two-di mensi onal
array objects respecti vel y. Then the i ndexed names a(1) and b(1, 1) refer to
el ements of these ar r ays. Fur ther mor e, a conti guous sl i ce of a one-
di mensi onal array can be referred to by usi ng a range as an i ndex. For
exampl e a(8 to 15) i s an ei ght-el ement ar r ay whi ch i s par t of the ar r ay a.
Someti mes you may need to wri te a l i teral val ue of an array type. Thi s
can be done usi ng an array aggregate, whi ch i s a l i st of el ement val ues.
Suppose we have an array type decl ared as:
type a is array (1 to 4) of character;
and we want to wr i te a val ue of thi s type contai ni ng the el ements 'f', 'o', 'o',
'd' i n that order. We coul d wri te an aggregate wi th positional associ ati on
as fol l ows:
('f', 'o', 'o', 'd')
i n whi ch the el ements are l i sted i n the order of the i ndex range, starti ng
wi th the l eft bound of the range. Al ternati vel y, we coul d wri te an aggregate
wi th named associ ati on:
(1 => 'f', 3 => 'o', 4 => 'd', 2 => 'o')
I n thi s case, the i ndex for each el ement i s expl i ci tl y gi ven, so the el ements
can be i n any order. Posi ti onal and named associ ati on can be mi xed wi thi n
an aggr egate, pr ovi ded al l the posi ti onal associ ati ons come fi r st. Al so, the
wor d others can be used i n pl ace of an i ndex i n a named associ ati on,
i ndi cati ng a val ue to be used for al l el ements not expl i ci tl y menti oned. For
exampl e, the same val ue as above coul d be wri tten as:
('f', 4 => 'd', others => 'o')
2.2.6. Records
VHDL pr ovi des basi c faci l i ti es for r ecor ds, whi ch ar e col l ecti ons of
named el ements of possi bl y di fferent types. The syntax for decl ari ng record
types i s:
r ecor d_type_defi ni ti on ::=
record
el ement_decl ar ati on
{ el ement_decl ar ati on }
end record
el ement_decl ar ati on ::= i denti fi er _l i st : el ement_subtype_defi ni ti on ;
i denti fi er _l i st ::= i denti fi er { , i denti fi er )
el ement_subtype_defi ni ti on ::= subtype_i ndi cati on
An exampl e r ecor d type decl ar ati on:
type instruction is
record
op_code : processor_op;
address_mode : mode;
operand1, operand2: integer range 0 to 15;
end record;
When you need to refer to a fi el d of a record object, you use a sel ected
name. For exampl e, suppose that r i s a record object contai ni ng a fi el d
cal l ed f. Then the name r.f refers to that fi el d.
As for arrays, aggregates can be used to wri te l i teral val ues for records.
Both posi ti onal and named associ ati on can be used, and the same rul es
appl y, wi th r ecor d fi el d names bei ng used i n pl ace of ar r ay i ndex names.
2.2.7. Subtypes
The use of a subtype al l ows the val ues taken on by an object to be
restri cted or constrai ned subset of some base type. The syntax for decl ari ng
a subtype i s:
subtype_decl arati on ::= subtype i denti fi er is subtype_i ndi cati on ;
subtype_i ndi cati on ::= [ resolution_function_name ] type_mar k [ constr ai nt ]
type_mar k ::= type_name | subtype_name
constr ai nt ::= r ange_constr ai nt | i ndex_constr ai nt
There are two cases of subtypes. Fi rstl y a subtype may constrai n val ues
from a scal ar type to be wi thi n a speci fi ed range (a range constrai nt). For
exampl e:
subtype pin_count is integer range 0 to 400;
subtype digits is character range '0' to '9';
Secondl y, a subtype may constr ai n an other wi se unconstr ai ned ar r ay
type by speci fyi ng bounds for the i ndi ces. For exampl e:
subtype id is string(1 to 20);
subtype word is bit_vector(31 downto 0);
Ther e ar e two pr edefi ned numer i c subtypes, defi ned as:
subtype natural is integer range 0 to highest_integer
subtype positive is integer range 1 to highest_integer
2.2.8. Object Declarations
An object i s a named i tem i n a VHDL descri pti on whi ch has a val ue of a
speci fi ed type. There are three cl asses of objects: constants, vari abl es and
si gnal s. Onl y the fi rst two wi l l be di scusses i n thi s secti on; si gnal s wi l l be
covered i n Secti on3.2.1. Decl arati on and use of constants and vari abl es i s
ver y much l i ke thei r use i n pr ogr ammi ng l anguages.
A constant i s an object whi ch i s i ni ti al i sed to a speci fi ed val ue when i t i s
created, and whi ch may not be subsequentl y modi fi ed. The syntax of a
constant decl ar ati on i s:
constant_decl ar ati on ::=
constant i denti fi er_l i st : subtype_i ndi cati on [ := expressi on ] ;
Constant decl ar ati ons wi th the i ni ti al i si ng expr essi on mi ssi ng ar e cal l ed
defer r ed constants, and may onl y appear i n package decl ar ati ons (see
Secti on2.5.3). The i ni ti al val ue must be gi ven i n the correspondi ng package
body. Some exampl es:
constant e : real := 2.71828;
constant delay : Time := 5 ns;
constant max_size : natural;
A vari abl e i s an object whose val ue may be changed after i t i s created.
The syntax for decl ar i ng var i abl es i s:
var i abl e_decl ar ati on ::=
variable i denti fi er _l i st : subtype_i ndi cati on [ := expr essi on ] ;
The i ni ti al val ue expressi on, i f present, i s eval uated and assi gned to the
vari abl e when i t i s created. I f the expressi on i s absent, a defaul t val ue i s
assi gned when the vari abl e i s created. The defaul t val ue for scal ar types i s
the l eftmost val ue for the type, that i s the fi rst i n the l i st of an enumerati on
type, the l owest i n an ascendi ng range, or the hi ghest i n a descendi ng
range. I f the vari abl e i s a composi te type, the defaul t val ue i s the
composi ti on of the defaul t val ues for each el ement, based on the el ement
types.
Some exampl es of var i abl e decl ar ati ons:
variable count : natural := 0;
variable trace : trace_array;
Assumi ng the type trace_array i s an array of boolean, then the i ni ti al val ue of
the vari abl e trace i s an array wi th al l el ements havi ng the val ue false.
Gi ven an exi sti ng object, i t i s possi bl e to gi ve an al ternate name to the
object or part of i t. Thi s i s done usi ng and al i as decl arati on. The syntax i s:
al i as_decl ar ati on ::= alias i denti fi er : subtype_i ndi cati on is name ;
A reference to an al i as i s i nterpreted as a reference to the object or part
cor r espondi ng to the al i as. For exampl e:
variable instr : bit_vector(31 downto 0);
alias op_code : bit_vector(7 downto 0) is instr(31 downto 24);
decl ares the name op_code to be an al i as for the l eft-most ei ght bi ts of instr.
2.2.9. Attributes
Types and objects decl ared i n a VHDL descri pti on can have addi ti onal
i nfor mati on, cal l ed attr i butes, associ ated wi th them. Ther e ar e a number
of standard pre-defi ned attri butes, and some of those for types and arrays
ar e di scussed her e. An attr i bute i s r efer enced usi ng the ' notati on. For
exampl e,
thing'attr
refers to the attri bute attr of the type or object thing.
Fi rstl y, for any scal ar type or subtype T, the fol l owi ng attri butes can be
used:
Attri bute Resul t
T'l eft Left bound of T
T'r i ght Ri ght bound of T
T'l ow Lower bound of T
T'hi gh Upper bound of T
For an ascendi ng r ange, T'l eft = T'l ow, and T'r i ght = T'hi gh. For a
descendi ng r ange, T'l eft = T'hi gh, and T'r i ght = T'l ow.
Secondl y, for any di screte or physi cal type or subtype T, X a member of T,
and N an i nteger, the fol l owi ng attri butes can be used:
Attri bute Resul t
T'pos(X) Posi ti on number of X i n T
T'val (N) Val ue at posi ti on N i n T
T'l eftof(X) Val ue i n T whi ch i s one posi ti on l eft fr om X
T'r i ghtof(X) Val ue i n T whi ch i s one posi ti on r i ght fr om X
T'pr ed(X) Val ue i n T whi ch i s one posi ti on l ower than X
T'succ(X) Val ue i n T whi ch i s one posi ti on hi gher than X
For an ascendi ng r ange, T'l eftof(X) = T'pr ed(X), and T'r i ghtof(X) =
T'succ(X). For a descendi ng r ange, T'l eftof(X) = T'succ(X), and T'r i ghtof(X)
= T'pr ed(X).
Thi rdl y, for any array type or object A, and N an i nteger between 1 and
the number of di mensi ons of A, the fol l owi ng attri butes can be used:
Attri bute Resul t
A'l eft(N) Left bound of i ndex range of di mn N of A
A'r i ght(N) Ri ght bound of i ndex range of di mn N of A
A'l ow(N) Lower bound of i ndex range of di mn N of A
A'hi gh(N) Upper bound of i ndex range of di mn N of A
A'r ange(N) I ndex r ange of di mn N of A
A'r ever se_r ange(N) Reverse of i ndex range of di mn N of A
A'l ength(N) Length of i ndex r ange of di mn N of A
2.3. Expressions and Operators
Expr essi ons i n VHDL ar e much l i ke expr essi ons i n other pr ogr ammi ng
l anguages. An expr essi on i s a for mul a combi ni ng pr i mar i es wi th
oper ator s. Pr i mar i es i ncl ude names of objects, l i ter al s, functi on cal l s and
parenthesi zed expressi ons. Operators are l i sted i n Tabl e 2-1 i n order of
decr easi ng pr ecedence.
The l ogi cal oper ator s and, or, nand, nor, xor and not oper ate on val ues of
type bit or boolean, and al so on one-di mensi onal arrays of these types. For
ar r ay oper ands, the oper ati on i s appl i ed between cor r espondi ng el ements of
each array, yi el di ng an array of the same l ength as the resul t. For bit and
Hi ghest pr ecedence: **
abs not
* /
mod rem
+ (si gn) (si gn)
+ &
= /= < <= > >=
Lowest pr ecedence:
and or nand nor xor
Table 7-1. Operators and precedence.
boolean oper ands, and, or, nand, and nor ar e shor t-ci r cui t oper ator s, that
i s they onl y eval uate thei r ri ght operand i f the l eft operand does not
determi ne the resul t. So and and nand onl y eval uate the ri ght operand i f
the l eft operand i s true or '1', and or and nor onl y eval uate the ri ght
operand i f the l eft operand i s fal se or '0'.
The rel ati onal operators =, /=, <, <=, > and >= must have both operands
of the same type, and yi el d boolean resul ts. The equal i ty operators (= and /=)
can have operands of any type. For composi te types, two val ues are equal i f
al l of thei r cor r espondi ng el ements ar e equal . The r emai ni ng oper ator s
must have oper ands whi ch ar e scal ar types or one-di mensi onal ar r ays of
di screte types.
The si gn operators (+ and ) and the addi ti on (+) and subtracti on ()
oper ator s have thei r usual meani ng on numer i c oper ands. The
concatenati on operator (&) operates on one-di mensi onal arrays to form a
new array wi th the contents of the ri ght operand fol l owi ng the contents of
the l eft operand. I t can al so concatenate a si ngl e new el ement to an array,
or two i ndi vi dual el ements to form an array. The concatenati on operator i s
most commonl y used wi th str i ngs.
The mul ti pl i cati on (*) and di vi si on (/) operators work on i nteger, fl oati ng
poi nt and physi cal types types. The modul us (mod) and remai nder (rem)
operators onl y work on i nteger types. The absol ute val ue (abs) operator
works on any numeri c type. Fi nal l y, the exponenti ati on (**) operator can
have an i nteger or fl oati ng poi nt l eft operand, but must have an i nteger
ri ght operand. A negati ve ri ght operand i s onl y al l owed i f the l eft operand
i s a fl oati ng poi nt number .
2.4. Sequential Statements
VHDL contai ns a number of faci l i ti es for modi fyi ng the state of objects
and control l i ng the fl ow of executi on of model s. These are di scussed i n thi s
secti on.
2.4.1. Variable Assignment
As i n other pr ogr ammi ng l anguages, a var i abl e i s gi ven a new val ue
usi ng an assi gnment statement. The syntax i s:
var i abl e_assi gnment_statement ::= tar get := expr essi on ;
tar get ::= name | aggr egate
I n the si mpl est case, the target of the assi gnment i s an object name, and
the val ue of the expressi on i s gi ven to the named object. The object and the
val ue must have the same base type.
I f the target of the assi gnment i s an aggregate, then the el ements l i sted
must be object names, and the val ue of the expressi on must be a composi te
val ue of the same type as the aggregate. Fi rstl y, al l the names i n the
aggregate are eval uated, then the expressi on i s eval uated, and l astl y the
components of the expressi on val ue are assi gned to the named vari abl es.
Thi s i s effecti vel y a paral l el assi gnment. For exampl e, i f a vari abl e r i s a
record wi th two fi el ds a and b, then they coul d be exchanged by wri ti ng
(a => r.b, b => r.a) := r
(Note that thi s i s an exampl e to i l l ustrate how such an assi gnment works;
i t i s not an exampl e of good pr ogr ammi ng pr acti ce!)
2.4.2. If Statement
The i f statement al l ows sel ecti on of statements to execute dependi ng on
one or more condi ti ons. The syntax i s:
i f_statement ::=
if condi ti on then
sequence_of_statements
{ elsif condi ti on then
sequence_of_statements }
[ else
sequence_of_statements ]
end if ;
The condi ti ons ar e expr essi ons r esul ti ng i n bool ean val ues. The
condi ti ons are eval uated successi vel y unti l one found that yi el ds the val ue
true. I n that case the correspondi ng statement l i st i s executed. Otherwi se,
i f the el se cl ause i s present, i ts statement l i st i s executed.
2.4.3. Case Statement
The case statement al l ows sel ecti on of statements to execute dependi ng
on the val ue of a sel ecti on expressi on. The syntax i s:
case_statement ::=
case expressi on i s
case_statement_al ter nati ve
{ case_statement_al ter nati ve }
end case ;
case_statement_al ter nati ve ::=
when choi ces =>
choi ces ::= choi ce { | choi ce }
choi ce ::=
si mpl e_expr essi on
| di scr ete_r ange
| element_si mpl e_name
| others
The sel ecti on expressi on must resul t i n ei ther a di screte type, or a one-
di mensi onal ar r ay of char acter s. The al ter nati ve whose choi ce l i st
i ncl udes the val ue of the expressi on i s sel ected and the statement l i st
executed. Note that al l the choi ces must be di sti nct, that i s, no val ue may be
dupl i cated. Fur ther mor e, al l val ues must be r epr esented i n the choi ce
l i sts, or the speci al choi ce others must be i ncl uded as the l ast al ternati ve. I f
no choi ce l i st i ncl udes the val ue of the expressi on, the others al ternati ve i s
sel ected. I f the expressi on resul ts i n an array, then the choi ces may be
str i ngs or bi t str i ngs.
Some exampl es of case statements:
case element_colour of
when red =>
statements for red;
when green | blue =>
statements for green or blue;
when orange to turquoise =>
statements for these colours;
end case;
case opcode of
when X"00" => perform_add;
when X"01" => perform_subtract;
when others => signal_illegal_opcode;
end case;
2.4.4. Loop Statements
VHDL has a basi c l oop statement, whi ch can be augmented to form the
usual whi l e and for l oops seen i n other pr ogr ammi ng l anguages. The
syntax of the l oop statement i s:
l oop_statement ::=
[ loop_l abel : ]
[ i terati on_scheme ] loop
end loop [ l oop_l abel ] ;
i ter ati on_scheme ::=
while condi ti on
| for loop_par ameter _speci fi cati on
par ameter _speci fi cati on ::=
i denti fi er in di scr ete_r ange
I f the i terati on scheme i s omi tted, we get a l oop whi ch wi l l repeat the
encl osed statements i ndefi ni tel y. An exampl e of such a basi c l oop i s:
l oop
do_something;
end loop;
The whi l e i terati on scheme al l ows a test condi ti on to be eval uated before
each i terati on. The i terati on onl y proceeds i f the test eval uates to true. I f
the test i s fal se, the l oop statement termi nates. An exampl e:
while index < length and str(index) /= ' ' loop
index := index + 1;
end loop;
The for i terati on scheme al l ows a speci fi ed number of i terati ons. The
l oop par ameter speci fi cati on decl ar es an object whi ch takes on successi ve
val ues from the gi ven range for each i terati on of the l oop. Wi thi n the
statements encl osed i n the l oop, the object i s treated as a constant, and so
may not be assi gned to. The object does not exi st beyond executi on of the
l oop statement. An exampl e:
for item in 1 to last_item loop
table(item) := 0;
end loop;
There are two addi ti onal statements whi ch can be used i nsi de a l oop to
modi fy the basi c pattern of i terati on. The next statement termi nates
executi on of the current i terati on and starts the subsequent i terati on. The
exi t statement ter mi nates executi on of the cur r ent i ter ati on and
termi nates the l oop. The syntax of these statements i s:
next_statement ::= next [ l oop_l abel ] [ when condi ti on ] ;
exi t_statement ::= exit [ l oop_l abel ] [ when condi ti on ] ;
I f the l oop l abel i s omi tted, the statement appl i es to the i nner-most
encl osi ng l oop, otherwi se i t appl i es to the named l oop. I f the when cl ause i s
present but the condi ti on i s fal se, the i terati on conti nues normal l y. Some
exampl es:
for i in 1 to max_str_len loop
a(i) := buf(i);
exit when buf(i) = NUL;
end loop;
outer_loop : loop
inner_loop : loop
do_something;
next outer_loop when temp = 0;
do_something_else;
end loop inner_loop;
end loop outer_loop;
2.4.5. Null Statement
The nul l statement has no effect. I t may be used to expl i ci tl y show that
no acti on i s requi red i n certai n cases. I t i s most often used i n case
statements, where al l possi bl e val ues of the sel ecti on expressi on must be
l i sted as choi ces, but for some choi ces no acti on i s requi red. For exampl e:
case controller_command is
when forward => engage_motor_forward;
when reverse => engage_motor_reverse;
when idle => null;
end case;
2.4.6. Assertions
An asserti on statement i s used to veri fy a speci fi ed condi ti on and to
report i f the condi ti on i s vi ol ated. The syntax i s:
asser ti on_statement ::=
assert condi ti on
[ report expression ]
[ severity expressi on ] ;
I f the report cl ause i s present, the resul t of the expressi on must be a stri ng.
Thi s i s a message whi ch wi l l be reported i f the condi ti on i s fal se. I f i t i s
omi tted, the defaul t message i s "Asserti on vi ol ati on". I f the severi ty cl ause
i s present the expressi on must be of the type severity_level. I f i t i s omi tted,
the defaul t i s error. A si mul ator may termi nate executi on i f an asserti on
vi ol ati on occurs and the severi ty val ue i s greater than some
i mpl ementati on dependent thr eshol d. Usual l y the thr eshol d wi l l be under
user contr ol .
2.5. Subprograms and Packages
Li ke other pr ogr ammi ng l anguages, VHDL pr ovi des subpr ogr am
faci l i ti es i n the form of procedures and functi ons. VHDL al so provi ded a
package faci l i ty for col l ecti ng decl ar ati ons and objects i nto modul ar uni ts.
Packages al so pr ovi de a measur e of data abstr acti on and i nfor mati on
hi di ng.
2.5.1. Procedures and Functions
Pr ocedur e and functi on subpr ogr ams ar e decl ar ed usi ng the syntax:
subpr ogr am_decl ar ati on ::= subpr ogr am_speci fi cati on ;
subpr ogr am_speci fi cati on ::=
procedure desi gnator [ ( formal _parameter_l i st ) ]
| function desi gnator [ ( formal _parameter_l i st ) ] return type_mark
A subpr ogr am decl ar ati on i n thi s for m si mpl y names the subpr ogr am and
speci fi es the parameters requi red. The body of statements defi ni ng the
behavi our of the subpr ogr am i s defer r ed. For functi on subpr ogr ams, the
decl arati on al so speci fi es the type of the resul t returned when the functi on
i s cal l ed. Thi s for m of subpr ogr am decl ar ati on i s typi cal l y used i n package
speci fi cati ons (see Secti on 2.5.3), where the subprogram body i s gi ven i n the
package body, or to defi ne mutual l y r ecur si ve pr ocedur es.
The syntax for speci fyi ng the for mal par ameter s of a subpr ogr am i s:
for mal _par ameter _l i st ::= parameter_i nter face_l i st
i nter face_l i st ::= i nter face_el ement { ; i nter face_el ement }
i nter face_el ement ::= i nter face_decl ar ati on
i nter face_decl ar ati on ::=
i nter face_constant_decl ar ati on
| i nter face_si gnal _decl ar ati on
| i nter face_var i abl e_decl ar ati on
i nter face_constant_decl ar ati on ::=
[ constant ] i denti fi er_l i st : [ in ] subtype_i ndi cati on [ := static_expressi on ]
i nter face_var i abl e_decl ar ati on ::=
[ variable ] i denti fi er_l i st : [ mode ] subtype_i ndi cati on [ := static_expressi on ]
For now we wi l l onl y consi der constant and var i abl e par ameter s, al though
si gnal s can al so be used(see Chapter3). Some exampl es wi l l cl ari fy thi s
syntax. Fi r stl y, a si mpl e exampl e of a pr ocedur e wi th no par ameter s:
procedure reset;
Thi s si mpl y defi nes reset as a pr ocedur e wi th no par ameter s, whose
statement body wi l l be gi ven subsequentl y i n the VHDL program. A
procedure cal l to reset woul d be:
reset;
Secondl y, her e i s a decl ar ati on of a pr ocedur e wi th some par ameter s:
procedure increment_reg(variable reg : inout word_32;
constant incr : in integer := 1);
I n thi s exampl e, the pr ocedur e increment_reg has two par ameter s, the
fi rst cal l ed reg and the second cal l ed incr. Reg i s a vari abl e parameter,
whi ch means that i n the subprogram body, i t i s treated as a vari abl e object
and may be assi gned to. Thi s means that when the procedure i s cal l ed, the
actual parameter associ ated wi th reg must i tsel f be a vari abl e. The mode of
reg i s inout, whi ch means that reg can be both read and assi gned to. Other
possi bl e modes for subpr ogr am par ameter s ar e in, whi ch means that the
parameter may onl y be read, and out, whi ch means that the par ameter
may onl y be assi gned to. I f the mode i s inout or out, then the word variable
can be omi tted and i s assumed.
The second par ameter , incr, i s a constant par ameter , whi ch means that
i t i s treated as a constant object i n the subprogram statement body, and may
not be assi gned to. The actual parameter associ ated wi th incr when the
procedure i s cal l ed must be an expressi on. Gi ven the mode of the
par ameter , in, the word constant coul d be omi tted and assumed. The
expr essi on after the assi gnment oper ator i s a defaul t expr essi on, whi ch i s
used i f no actual parameter i s associ ated wi th incr i n a cal l to the procedure.
A cal l to a subprogram i ncl udes a l i st of actual parameters to be
associ ated wi th the for mal par ameter s. Thi s associ ati on l i st can be
posi ti on, named, or a combi nati on of both. (Compare thi s wi th the format of
aggregates for val ues of composi te types.) A cal l wi th posi ti onal associ ati on
l i sts the actual par ameter s i n the same or der as the for mal s. For exampl e:
increment_reg(index_reg, offset2); -- add value to index_reg
increment_reg(prog_counter); -- add 1 (default) to prog_counter
A cal l wi th named associ ati on expl i ci tl y gi ves the for mal par ameter name
to be associ ated wi th each actual parameter, so the parameters can be i n
any or der . For exampl e:
increment_reg(incr => offset2, reg => index_reg);
increment_reg(reg => prog_counter);
Note that the second cal l i n each exampl e does not gi ve a val ue for the
for mal par ameter incr, so the defaul t val ue i s used.
Thi r dl y, her e i s an exampl e of functi on subpr ogr am decl ar ati on:
function byte_to_int(byte : word_8) return integer;
The functi on has one par ameter . For functi ons, the par ameter mode must
be in, and thi s i s assumed i f not expl i ci tl y speci fi ed. I f the parameter cl ass
i s not speci fi ed i t i s assumed to be constant. The val ue returned by the body
of thi s functi on must be an i nteger.
When the body of a subprogram i s speci fi ed, the syntax used i s:
subpr ogr am_body ::=
subpr ogr am_speci fi cati on is
subpr ogr am_decl ar ati ve_par t
begin
subpr ogr am_statement_par t
end [ desi gnator ] ;
subpr ogr am_decl ar ati ve_par t ::= { subpr ogr am_decl ar ati ve_i tem }
subpr ogr am_statement_par t ::= { sequenti al _statement }
subpr ogr am_decl ar ati ve_i tem ::=
subpr ogr am_decl ar ati on
| subpr ogr am_body
| type_decl ar ati on
| subtype_decl ar ati on
| constant_decl ar ati on
| var i abl e_decl ar ati on
| al i as_decl ar ati on
The decl ar ati ve i tems l i sted after the subpr ogr am speci fi cati on decl ar e
thi ngs whi ch are to be used l ocal l y wi thi n the subprogram body. The
names of these i tems are not vi si bl e outsi de of the subprogram, but are
vi si bl e i nsi de l ocal l y decl ar ed subpr ogr ams. Fur ther mor e, these i tems
shadow any thi ngs wi th the same names decl ar ed outsi de the subpr ogr am.
When the subprogram i s cal l ed, the statements i n the body are executed
unti l ei ther the end of the statement l i st i s encountered, or a return
statement i s executed. The syntax of a return statement i s:
return_statement ::= return [ expressi on ] ;
I f a return statement occurs i n a procedure body, i t must not i ncl ude an
expressi on. There must be at l east one return statement i n a functi on body,
i t must have an expressi on, and the functi on must compl ete by executi ng a
return statement. The val ue of the expressi on i s the val ued returned to the
functi on cal l .
Another poi nt to note about functi on subprograms i s that they may not
have any si de-effects. Thi s means that no vi si bl e vari abl e decl ared outsi de
the functi on body may be assi gned to or al tered by the functi on. Thi s
i ncl udes passi ng a non-l ocal vari abl e to a procedure as a vari abl e
par ameter wi th mode out or inout. The i mportant resul t of thi s rul e i s that
functi ons can be cal l ed wi thout them havi ng any effect on the envi ronment
of the cal l .
An exampl e of a functi on body:
function byte_to_int(byte : word_8) return integer is
variable result : integer := 0;
begi n
for index in 0 to 7 loop
result := result*2 + bit'pos(byte(index));
end loop;
return result;
end byte_to_int;
2.5.2. Overloading
VHDL al l ows two subprograms to have the same name, provi ded the
number or base types of par ameter s di ffer s. The subpr ogr am name i s then
sai d to be overl oaded. When a subprogram cal l i s made usi ng an
over l oaded name, the number of actual par ameter s, thei r or der , thei r base
types and the cor r espondi ng for mal par ameter names (i f named
associ ati on i s used) ar e used to deter mi ne whi ch subpr ogr am i s meant. I f
the cal l i s a functi on cal l , the resul t type i s al so used. For exampl e, suppose
we decl ar ed the two subpr ogr ams:
function check_limit(value : integer) return boolean;
function check_limit(value : word_32) return boolean;
Then whi ch of the two functi ons i s cal l ed depends on whether a val ue of
type integer or word_8 i s used as the actual parameter. So
test := check_limit(4095)
woul d cal l the fi r st functi on, and
test := check_limit(X"0000_0FFF")
woul d cal l the second functi on.
The desi gnator used to defi ne a subprogram can be ei ther an i denti fi er
or a stri ng representi ng any of the operator symbol s l i sted i n Secti on2.3.
The l atter case al l ows extra operand types to be defi ned for those operators.
For exampl e, the addi ti on operator mi ght be overl oaded to add word_32
oper ands by decl ar i ng a functi on:
function "+" (a, b : word_32) return word_32 is
begi n
return int_to_word_32( word_32_to_int(a) + word_32_to_int(b) );
end "+";
Wi thi n the body of thi s functi on, the addi ti on operator i s used to add
i nteger s, si nce i ts oper ands ar e both i nteger s. However , i n the expr essi on:
X"1000_0010" + X"0000_FFD0"
the newl y decl ared functi on i s cal l ed, si nce the operands to the addi ti on
operator are both of type word_32. Note that i t i s al so possi bl e to cal l
oper ator s usi ng the pr efi x notati on used for or di nar y subpr ogr am cal l s, for
exampl e:
"+" (X"1000_0010", X"0000_FFD0")
2.5.3. Package and Package Body Declarations
A package i s a col l ecti on of types, constants, subpr ogr ams and possi bl y
other thi ngs, usual l y i ntended to i mpl ement some par ti cul ar ser vi ce or to
i sol ate a group of rel ated i tems. I n parti cul ar, the detai l s of constant val ues
and subpr ogr am bodi es can be hi dden fr om user s of a package, wi th onl y
thei r i nter faces made vi si bl e.
A package may be spl i t i nto two parts: a package decl arati on, whi ch
defi nes i ts i nterface, and a package body, whi ch defi nes the deferred
detai l s. The body part may be omi tted i f there are no deferred detai l s. The
syntax of a package decl arati on i s:
package_decl ar ati on ::=
package i denti fi er is
package_decl ar ati ve_par t
end [ package_si mpl e_name ] ;
package_decl ar ati ve_par t ::= { package_decl ar ati ve_i tem }
package_decl ar ati ve_i tem ::=
| use_cl ause
The decl arati ons defi ne thi ngs whi ch are to be vi si bl e to users of the
package, and whi ch are al so vi si bl e i nsi de the package body. (There are
al so other ki nds of decl arati ons whi ch can be i ncl uded, but they are not
di scussed her e.)
An exampl e of a package decl ar ati on:
package data_types is
subtype address is bit_vector(24 downto 0);
subtype data is bit_vector(15 downto 0);
constant vector_table_loc : address;
function data_to_int(value : data) return integer;
function int_to_data(value : integer) return data;
end data_types;
I n thi s exampl e, the val ue of the constant vector_table_loc and the bodi es of
the two functi ons are deferred, so a package body needs to be gi ven.
The syntax for a package body i s:
package_body ::=
package body package_si mpl e_name is
package_body_decl ar ati ve_par t
end [ package_si mpl e_name ] ;
package_body_decl ar ati ve_par t ::= { package_body_decl ar ati ve_i tem }
package_body_decl ar ati ve_i tem ::=
| subpr ogr am_body
| use_cl ause
Note that subprogram bodi es may be i ncl uded i n a package body, whereas
onl y subpr ogr am i nter face decl ar ati ons may be i ncl uded i n the package
i nter face decl ar ati on.
The body for the package data_types shown above mi ght be wri tten as:
package body data_types is
constant vector_table_loc : address := X"FFFF00";
function data_to_int(value : data) return integer is
body of data_to_int
end data_to_int;
function int_to_data(value : integer) return data is
body of int_to_data
end int_to_data;
end data_types;
I n thi s package body, the val ue for the constant i s speci fi ed, and the
functi on bodi es are gi ven. The subtype decl arati ons are not repeated, as
those i n the package decl arati ons are vi si bl e i n the package body.
2.5.4. Package Use and Name Visibility
Once a package has been decl ared, i tems decl ared wi thi n i t can be used
by prefi xi ng thei r names wi th the package name. For exampl e, gi ven the
package decl arati on i n Secti on2.4.3 above, the i tems decl ared mi ght be used
as fol l ows:
variable PC : data_types.address;
int_vector_loc := data_types.vector_table_loc + 4*int_level;
offset := data_types.data_to_int(offset_reg);
Often i t i s conveni ent to be abl e to refer to names from a package wi thout
havi ng to qual i fy each use wi th the package name. Thi s may be done usi ng
a use cl ause i n a decl arati on regi on. The syntax i s:
use_cl ause ::= use sel ected_name { , sel ected_name } ;
sel ected_name ::= pr efi x . suffi x
The effect of the use cl ause i s that al l of the l i sted names can subsequentl y
be used wi thout havi ng to prefi x them. I f al l of the decl ared names i n a
package are to be used i n thi s way, you can use the speci al suffi x all, for
exampl e:
use data_types.all;
3-1
3. VHDL Describes Structure
I n Secti on 1.1 we i ntr oduced some ter mi nol ogy for descr i bi ng the
structure of a di gi tal system. I n thi s chapter, we wi l l l ook at how structure
i s descr i bed i n VHDL.
3.1. Entity Declarations
A di gi tal system i s usual l y desi gned as a hi er ar chi cal col l ecti on of
modul es. Each modul e has a set of ports whi ch consti tute i ts i nterface to
the outsi de worl d. I n VHDL, an entity i s such a modul e whi ch may be used
as a component i n a desi gn, or whi ch may be the top l evel modul e of the
desi gn.
The syntax for decl ari ng an enti ty i s:
enti ty_decl ar ati on ::=
entity i denti fi er is
enti ty_header
enti ty_decl ar ati ve_par t
[ begin
enti ty_statement_part ]
end [ entity_si mpl e_name ] ;
enti ty_header ::=
[ formal _gener i c_cl ause ]
[ formal_por t_cl ause ]
gener i c_cl ause ::= generic ( gener i c_l i st ) ;
gener i c_l i st ::= generi c_i nter face_l i st
port_cl ause ::= port ( port_l i st ) ;
por t_l i st ::= port_i nter face_l i st
enti ty_decl ar ati ve_par t ::= { enti ty_decl ar ati ve_i tem }
The enti ty decl arati ve part may be used to decl are i tems whi ch are to be
used i n the i mpl ementati on of the enti ty. Usual l y such decl arati ons wi l l be
i ncl uded i n the i mpl ementati on i tsel f, so they are onl y menti oned here for
compl eteness. Al so, the opti onal statements i n the enti ty decl arati on may
be used to defi ne some speci al behavi our for moni tori ng operati on of the
enti ty. Di scussi on of these wi l l be deferred unti l Secti on6.5.
The enti ty header i s the most i mportant part of the enti ty decl arati on. I t
may i ncl ude speci fi cati on of generic constants, whi ch can be used to contr ol
the structure and behavi our of the enti ty, and ports, whi ch channel
i nformati on i nto and out of the enti ty.
The gener i c constants ar e speci fi ed usi ng an i nter face l i st si mi l ar to
that of a subprogram decl arati on. Al l of the i tems must be of cl ass
constant. As a r emi nder , the syntax of an i nter face constant decl ar ati on i s:
i nter face_constant_decl ar ati on ::=
[ constant ] i denti fi er_l i st : [ in ] subtype_i ndi cati on [ := static_expressi on ]
A
B
Y
Z
DUT
Y
Z
A
B
TG
TEST_BENCH
Figure 3-1. Test bench circuit.
The actual val ue for each generi c constant i s passed i n when the enti ty i s
used as a component i n a desi gn.
The enti ty ports are al so speci fi ed usi ng an i nterface l i st, but the i tems
i n the l i st must al l be of cl ass si gnal . Thi s i s a new ki nd of i nterface i tem
not previ ousl y di scussed. The syntax i s:
i nter face_si gnal _decl ar ati on ::=
[ signal ] i denti fi er_l i st : [ mode ] subtype_i ndi cati on [ bus ]
[ := static_expr essi on ]
Si nce the cl ass must be si gnal , the word signal can be omi tted and i s
assumed. The word bus may be used i f the port i s to be connected to more
than one output (see Secti ons 6.1 and 6.2). As wi th generi c constants the
actual si gnal s to be connected to the ports are speci fi ed when the enti ty i s
used as a component i n a desi gn.
To cl ar i fy thi s di scussi on, her e ar e some exampl es of enti ty
decl ar ati ons:
entity processor is
generic (max_clock_freq : frequency := 30 MHz);
address : out integer;
data : inout word_32;
control : out proc_control;
ready : in bit);
end processor;
I n thi s case, the generi c constant max_clock_freq i s used to speci fy the ti mi ng
behavi our of the enti ty. The code descri bi ng the enti ty's behavi our woul d
use thi s val ue to deter mi ne del ays i n changi ng si gnal val ues.
Next, an exampl e showi ng how gener i c par ameter s can be used to
speci fy a cl ass of enti ti es wi th varyi ng structure:
entity ROM is
generic (width, depth : positive);
port (enable : in bit;
address : in bit_vector(depth1 downto 0);
data : out bit_vector(width1 downto 0) );
end ROM;
Here, the two generi c constants are used to speci fy the number of data bi ts
and address bi ts respecti vel y for the read-onl y memory. Note that no
defaul t val ue i s gi ven for ei ther of these constants. Thi s means that when
the enti ty i s used as a component, actual val ues must be suppl i ed for them.
Fi nal l y an exampl e of an enti ty decl arati on wi th no generi c constants or
3. VHDL Describes Structure 3-3
por ts:
entity test_bench is
end test_bench;
Though thi s mi ght at fi rst seem to be a poi ntl ess exampl e, i n fact i t
i l l ustrates a common use of enti ti es, shown i n Fi gure3-1. A top-l evel enti ty
for a desi gn under test (DUT) i s used as a component i n a test bench ci rcui t
wi th another enti ty (TG) whose purpose i s to generate test val ues. The
val ues on si gnal s can be tr aced usi ng a si mul ati on moni tor , or checked
di rectl y by the test generator. No external connecti ons from the test bench
are needed, hence i t has no ports.
3.2. Architecture Declarations
Once an enti ty has had i ts i nterface speci fi ed i n an enti ty decl arati on,
one or more i mpl ementati ons of the enti ty can be descri bed i n architecture
bodi es. Each archi tecture body can descri be a di fferent vi ew of the enti ty.
For exampl e, one archi tecture body may purel y descri be the behavi our
usi ng the faci l i ti es covered i n Chapters 2 and 4, whereas others may
descri be the structure of the enti ty as a hi erarchi cal l y composed col l ecti on
of components. I n thi s secti on, we wi l l onl y cover str uctur al descr i pti ons,
defer r i ng behavi our descr i pti ons unti l Chapter 4.
An ar chi tectur e body i s decl ar ed usi ng the syntax:
ar chi tectur e_body ::=
architecture i denti fi er of entity_name is
ar chi tectur e_decl ar ati ve_par t
begin
ar chi tectur e_statement_par t
end [ architecture_si mpl e_name ] ;
ar chi tectur e_decl ar ati ve_par t ::= { bl ock_decl ar ati ve_i tem }
ar chi tectur e_statement_par t ::= { concur r ent_statement }
bl ock_decl ar ati ve_i tem ::=
| subpr ogr am_body
| si gnal _decl ar ati on
| component_decl ar ati on
| confi gur ati on_speci fi cati on
| use_cl ause
concur r ent_statement ::=
bl ock_statement
| component_i nstanti ati on_statement
The decl arati ons i n the archi tecture body defi ne i tems that wi l l be used to
constr uct the desi gn descr i pti on. I n par ti cul ar , si gnal s and components
may be decl ared here and used to construct a structural descri pti on i n
terms of component i nstances, as i l l ustrated i n Secti on1.4. These are
di scussed i n mor e detai l i n the next secti ons.
3.2.1. Signal Declarations
Si gnal s are used to connect submodul es i n a desi gn. They are decl ared
usi ng the syntax:
si gnal _decl ar ati on ::=
signal i denti fi er _l i st : subtype_i ndi cati on [ si gnal _ki nd ] [ := expr essi on ] ;
si gnal _ki nd ::= register | bus
Use of the si gnal ki nd speci fi cati on i s covered i n Secti on6.2. Omi tti ng the
si gnal ki nd resul ts i n an ordi nary si gnal of the subtype speci fi ed. The
expressi on i n the decl arati on i s used to gi ve the si gnal an i ni ti al val ue
dur i ng the i ni ti al i zati on phase of si mul ati on. I f the expr essi on i s omi tted,
a defaul t i ni ti al val ue wi l l be assi gned.
One i mportant poi nt to note i s that ports of an object are treated exactl y
as si gnal s wi thi n that object.
3.2.2. Blocks
The submodul es i n an archi tecture body can be descri bed as bl ocks. A
bl ock i s a uni t of modul e structure, wi th i ts own i nterface, connected to
other bl ocks or ports by si gnal s. A bl ock i s speci fi ed usi ng the syntax:
bl ock_statement ::=
bl ock_l abel :
block [ ( guard_expressi on ) ]
bl ock_header
bl ock_decl ar ati ve_par t
begin
bl ock_statement_par t
end block [ block_l abel ] ;
bl ock_header ::=
[ gener i c_cl ause
[ generi c_map_aspect ; ] ]
[ port_cl ause
[ port_map_aspect ; ] ]
gener i c_map_aspect ::= generic map ( generic_associ ati on_l i st )
port_map_aspect ::= port map ( port_associ ati on_l i st )
bl ock_decl ar ati ve_par t ::= { bl ock_decl ar ati ve_i tem }
bl ock_statement_par t ::= { concur r ent_statement }
The guard expressi on i s not covered i n thi s bookl et, and may be omi tted.
The bl ock header defi nes the i nterface to the bl ock i n much the same way as
an enti ty header defi nes the i nterface to an enti ty. The generi c associ ati on
l i st speci fi es val ues for the generi c constants, eval uated i n the context of the
encl osi ng bl ock or archi tecture body. The port map associ ati on l i st speci fi es
whi ch actual si gnal s or por ts fr om the encl osi ng bl ock or ar chi tectur e body
are connected to the bl ocks ports. Note that a bl ock statement part may al so
contai n bl ock statements, so a desi gn can be composed of a hi erarchy of
bl ocks, wi th behavi oural descri pti ons at the bottom l evel of the hi erarchy.
As an exampl e, suppose we want to descr i be a str uctur al ar chi tectur e of
the processor enti ty exampl e i n Secti on3.1. I f we separate the processor
i nto a control uni t and a data path secti on, we can wri te a descri pti on as a
pai r of i nter connected bl ocks, as shown i n Fi gur e3-2.
The control uni t bl ock has ports clk, bus_control and bus_ready, whi ch are
connected to the processor enti ty ports. I t al so has an output port for
control l i ng the data path, whi ch i s connected to a si gnal decl ared i n the
archi tecture. That si gnal i s al so connected to a control port on the data
path bl ock. The address and data ports of the data path bl ock are connected
to the correspondi ng enti ty ports. The advantage of thi s modul ar
decomposi ti on i s that each of the bl ocks can then be devel oped
3. VHDL Describes Structure 3-5
architecture block_structure of processor is
type data_path_control is ;
signal internal_control : data_path_control;
begi n
control_unit : block
port (clk : in bit;
bus_control : out proc_control;
bus_ready : in bit;
control : out data_path_control);
port map (clk => clock,
bus_control => control, bus_ready => ready;
control => internal_control);
declarations for control_unit
begi n
statements for control_unit
end block control_unit;
data_path : block
port (address : out integer;
data : inout word_32;
control : in data_path_control);
port map (address => address, data => data,
control => internal_control);
declarations for data_path
begi n
statements for data_path
end block data_path;
end block_structure;
Figure3-2. Structural architecture of processor example.
i ndependentl y, wi th the onl y effects on other bl ocks bei ng wel l defi ned
thr ough thei r i nter faces.
3.2.3. Component Declarations
An archi tecture body can al so make use of other enti ti es descri bed
separatel y and pl aced i n desi gn l i brari es. I n order to do thi s, the
ar chi tectur e must decl ar e a component, whi ch can be thought of as a
templ ate defi ni ng a vi rtual desi gn enti ty, to be i nstanti ated wi thi n the
archi tecture. Later, a confi gurati on speci fi cati on (see Secti on3.3) can be
used to speci fy a matchi ng l i brary enti ty to use. The syntax of a component
decl ar ati on i s:
component_decl ar ati on ::=
component i denti fi er
[ l ocal _gener i c_cl ause ]
[ local_por t_cl ause ]
end component ;
Some exampl es of component decl ar ati ons:
component nand3
generic (Tpd : Time := 1 ns);
port (a, b, c : in logic_level;
y : out logic_level);
end component;
component read_only_memory
generic (data_bits, addr_bits : positive);
port (en : in bit;
addr : in bit_vector(depth1 downto 0);
data : out bit_vector(width1 downto 0) );
end component;
The fi r st exampl e decl ar es a thr ee-i nput gate wi th a gener i c par ameter
speci fyi ng i ts propagati on del ay. Di fferent i nstances can l ater be used wi th
possi bl y di fferent propagati on del ays. The second exampl e decl ares a read-
onl y memory component wi th address depth and data wi dth dependent on
generi c constants. Thi s component coul d act as a templ ate for the ROM
enti ty descri bed i n Secti on3.1.
3.2.4. Component Instantiation
A component defi ned i n an ar chi tectur e may be i nstanti ated usi ng the
syntax:
component_i nstanti ati on_statement ::=
i nstanti ati on_l abel :
component_n ame
[ gener i c_map_aspect ]
[ port_map_aspect ] ;
Thi s i ndi cates that the archi tecture contai ns an i nstance of the named
component, wi th actual val ues speci fi ed for gener i c constants, and wi th the
component ports connected to actual si gnal s or enti ty ports.
The exampl e components decl ar ed i n the pr evi ous secti on mi ght be
i nstanti ated as:
enable_gate: nand3
port map (a => en1, b => en2, c => int_req, y => interrupt);
parameter_rom: read_only_memory
generic map (data_bits => 16, addr_bits => 8);
port map (en => rom_sel, data => param, addr => a(7 downto 0);
I n the fi r st i nstance, no gener i c map speci fi cati on i s gi ven, so the defaul t
val ue for the generi c constant Tpd i s used. I n the second i nstance, val ues
are speci fi ed for the address and data port si zes. Note that the actual si gnal
associ ated wi th the port addr i s a sl i ce of an array si gnal . Thi s i l l ustrates
that a port whi ch i s an array can be connected to part of a si gnal whi ch i s a
l ar ger ar r ay, a ver y common pr acti ce wi th bus si gnal s.
4-1
4. VHDL Describes Behaviour
I n Secti on 1.2 we stated that the behavi our of a di gi tal system coul d be
descr i bed i n ter ms of pr ogr ammi ng l anguage notati on. The fami l i ar
sequenti al pr ogr ammi ng l anguage aspects of VHDL wer e cover ed i n detai l
i n Chapter 2. I n thi s chapter, we descri be how these are extended to
i ncl ude statements for modi fyi ng val ues on si gnal s, and means of
r espondi ng to the changi ng si gnal val ues.
4.1. Signal Assignment
A si gnal assi gnment schedul es one or mor e tr ansacti ons to a si gnal (or
port). The syntax of a si gnal assi gnment i s:
si gnal _assi gnment_statement ::= target <= [ transport ] waveform ;
tar get ::= name | aggr egate
wavefor m ::= wavefor m_el ement { , wavefor m_el ement }
wavefor m_el ement ::=
value_expressi on [ after time_expr essi on ]
| null [ after time_expressi on ]
The target must represent a si gnal , or be an aggregate of si gnal s (see al so
vari abl e assi gnments, Secti on 2.4.1). I f the ti me expressi on for the del ay i s
omi tted, i t defaul ts to 0 fs. Thi s means that the transacti on wi l l be
schedul ed for the same ti me as the assi gnment i s executed, but duri ng the
next si mul ati on cycl e.
Each si gnal has associ ated wi th i t a projected output waveform, whi ch
i s a l i st of transacti ons gi vi ng future val ues for the si gnal . A si gnal
assi gnment adds tr ansacti ons to thi s wavefor m. So, for exampl e, the
si gnal assi gnment:
s <= '0' after 10 ns;
wi l l cause the si gnal enabl e to assume the val ue true 10 ns after the
assi gnment i s executed. We can represent the projected output waveform
graphi cal l y by showi ng the transacti ons al ong a ti me axi s. So i f the above
assi gnment were executed at ti me 5 ns, the projected waveform woul d be:
15ns
'0'
When si mul ati on ti me r eaches 15 ns, thi s tr ansacti on wi l l be pr ocessed and
the si gnal updated.
Suppose then at ti me 16 ns, the assi gnment:
s <= '1' after 4 ns, '0' after 20 ns;
were executed. The two new transacti ons are added to the projected output
wavefor m:
20ns
'1'
36ns
'0'
Note that when mul ti pl e tr ansacti ons ar e l i sted i n a si gnal assi gnment, the
del ay ti mes speci fi ed must be i n ascendi ng or der .
I f a si gnal assi gnment i s executed, and ther e ar e al r eady ol d
tr ansacti ons fr om a pr evi ous assi gnmenton the pr ojected output wavefor m,
then some of the ol d transacti ons may be del eted. The way thi s i s done
depends on whether the wor d transport i s i ncl uded i n the new assi gnment.
I f i t i s i ncl uded, the assi gnment i s sai d to use transport delay. I n thi s case,
al l ol d transacti ons schedul ed to occur after the fi rst new transacti on are
del eted before the new transacti ons are added. I t i s as though the new
transacti ons supercede the ol d ones. So gi ven the projected output
wavefor m shown i mmedi atel y above, i f the assi gnment:
s <= transport 'Z' after 10 ns;
were executed at ti me 18 ns, then the transacti on schedul ed for 36 ns woul d
be del eted, and the projected output waveform woul d become:
20ns
'1'
28ns
'Z'
The second ki nd of del ay, inertial delay, i s used to model devi ces whi ch
do not respond to i nput pul ses shorter than thei r output del ay. An i nterti al
del ay i s speci fi ed by omi tti ng the word transport from the si gnal
assi gnment. When an i nerti al del ay transacti on i s added to a projected
output waveform, fi rstl y al l ol d transacti ons schedul ed to occur after the
new transacti on are del eted, and the new transacti on i s added, as i n the
case of transport del ay. Next, al l ol d transacti ons schedul ed to occur before
the new transacti on are exami ned. I f there are any wi th a di fferent val ue
from the new transacti on, then al l transacti ons up to the l ast one wi th a
di ffer ent val ue ar e del eted. The r emai ni ng tr ansacti ons wi th the same
val ue are l eft.
To i l l ustrate thi s, suppose the projected output waveform at ti me 0 ns i s:
10ns
'1'
15ns
'0'
20ns
'1'
30ns
'Z'
and the assi gnment:
s <= '1' after 25 ns;
i s executed al so at 0 ns. Then the new projected ouptut waveform i s:
20ns
'1'
25ns
'1'
When a si gnal assi gnment wi th mul ti pl e wavefor m el ements i s
speci fi ed wi th i nterti al del ay, onl y the fi rst transacti on uses i nerti al del ay;
the rest are treated as bei ng transport del ay transacti ons.
4.2. Processes and the Wait Statement
The pr i mar y uni t of behavi our al descr i pti on i n VHDL i s the process. A
process i s a sequenti al body of code whi ch can be acti vated i n response to
changes i n state. When more than one process i s acti vated at the same
4. VHDL Describes Behaviour 4-3
ti me, they execute concur r entl y. A pr ocess i s speci fi ed i n a pr ocess
statement, wi th the syntax:
pr ocess_statement ::=
[ process_l abel : ]
process [ ( sensi ti vi ty_l i st ) ]
pr ocess_decl ar ati ve_par t
begin
pr ocess_statement_par t
end process [ process_l abel ] ;
pr ocess_decl ar ati ve_par t ::= { pr ocess_decl ar ati ve_i tem }
pr ocess_decl ar ati ve_i tem ::=
| subpr ogr am_body
| var i abl e_decl ar ati on
| use_cl ause
pr ocess_statement_par t ::= { sequenti al _statement }
sequenti al _statement ::=
wai t_statement
| asser ti on_statement
| si gnal _assi gnment_statement
| var i abl e_assi gnment_statement
| pr ocedur e_cal l _statement
| i f_statement
| case_statement
| l oop_statement
| next_statement
| exi t_statement
| return_statement
| nul l _statement
A pr ocess statement i s a concur r ent statement whi ch can be used i n an
archi tecture body or bl ock. The decl arati ons defi ne i tems whi ch can be
used l ocal l y wi thi n the process. Note that vari abl es may be defi ned here
and used to store state i n a model .
A pr ocess may contai n a number of si gnal assi gnment statements for a
gi ven si gnal , whi ch together for m a driver for the si gnal . Nor mal l y ther e
may onl y be one dri ver for a si gnal , and so the code whi ch determi nes a
si gnal s val ue i s confi ned to one pr ocess.
A process i s acti vated i ni ti al l y duri ng the i ni ti al i sati on phase of
si mul ati on. I t executes al l of the sequenti al statements, and then repeats,
starti ng agai n wi th the fi rst statement. A process may suspended i tsel f by
executi ng a wai t statement. Thi s i s of the form:
wai t_statement ::=
wait [ sensi ti vi ty_cl ause ] [ condi ti on_cl ause ] [ ti meout_cl ause ] ;
sensi ti vi ty_cl ause ::= on sensi ti vi ty_l i st
sensi ti vi ty_l i st ::= si gnal _name { , si gnal _name }
condi ti on_cl ause ::= until condi ti on
ti meout_cl ause ::= for time_expr essi on
The sensi ti vi ty l i st of the wai t statement speci fi es a set of si gnal s to
whi ch the process i s sensi ti ve whi l e i t i s suspended. When an event occurs
on any of these si gnal s (that i s, the val ue of the si gnal changes), the process
resumes and eval uates the condi ti on. I f i t i s true or i f the condi ti on i s
omi tted, executi on procedes wi th the next statement, otherwi se the process
resuspends. I f the sensi ti vi ty cl ause i s omi tted, then the process i s
sensi ti ve to al l of the si gnal s menti oned i n the condi ti on expressi on. The
ti meout expressi on must eval uate to a posi ti ve durati on, and i ndi cates the
maxi mum ti me for whi ch the pr ocess wi l l wai t. I f i t i s omi tted, the pr ocess
may wai t i ndefi ni tel y.
I f a sensi ti vi ty l i st i s i ncl uded i n the header of a process statement, then
the process i s assumed to have an i mpl i ci t wai t statement at the end of i ts
statement part. The sensi ti vi ty l i st of thi s i mpl i ci t wai t statement i s the
same as that i n the process header. I n thi s case the process may not
contai n any expl i ci t wai t statements.
An exampl e of a process statements wi th a sensi ti vi ty l i st:
process (reset, clock)
variable state : bit := false;
begi n
if reset then
state := false;
elsif clock = true then
state := not state;
end if;
q <= state after prop_delay;
-- implicit wait on reset, clock
end process;
Duri ng the i ni ti al i zati on phase of si mul ati on, the process i s acti vated and
assi gns the i ni ti al val ue of state to the si gnal q. I t then suspends at the
i mpl i ci t wai t statement i ndi cated i n the comment. When ei ther reset or
clock change val ue, the pr ocess i s r esumed, and executi on r epeats fr om the
begi nni ng.
The next exampl e descri bes the behavi our of a synchroni zati on devi ce
cal l ed a Mul l er -C el ement used to constr uct asynchr onous l ogi c. The
output of the devi ce starts at the val ue '0', and stays at thi s val ue unti l both
i nputs are '1', at whi ch ti me the output changes to '1'. The output then
stays '1' unti l both i nputs are '0', at whi ch ti me the output changes back to
'0'.
muller_c_2 : process
begi n
wait until a = '1' and b = '1';
q <= '1';
wait until a = '0' and b = '0';
q <= '0';
end process muller_c_2 ;
Thi s process does not i ncl ude a sensi ti vi ty l i st, so expl i ci t wai t statements
are used to control the suspensi on and acti vati on of the process. I n both
wai t statements, the sensi ti vi ty l i st i s the set of si gnal s a and b, determi ned
fr om the condi ti on expr essi on.
4.3. Concurrent Signal Assignment Statements
Often a process descri bi ng a dri ver for a si gnal contai ns onl y one si gnal
assi gnment statement. VHDL pr ovi des a conveni ent shor t-hand notati on,
cal l ed a concur r ent si gnal assi gnment statement, for expr essi ng such
pr ocesses. The syntax i s:
concur r ent_si gnal _assi gnment_statement ::=
[ l abel : ] condi ti onal _si gnal _assi gnment
| [ l abel : ] sel ected_si gnal _assi gnment
For each ki nd of concur r ent si gnal assi gnment, ther e i s a
cor r espondi ng pr ocess statement wi th the same meani ng.
4.3.1. Conditional Signal Assignment
A condi ti onal si gnal assi gnment statement i s a shor thand for a pr ocess
contai ni ng si gnal assi gnments i n an i f statement. The syntax i s:
condi ti onal _si gnal _assi gnment ::= tar get <= opti ons condi ti onal _wavefor ms ;
options ::= [ guarded ] [ transport ]
condi ti onal _wavefor ms ::=
{ waveform when condi ti on else }
wavefor m
Use of the word guarded i s not covered i n thi s bookl et. I f the word transport
i s i ncl uded, then the si gnal assi gnments i n the equi val ent pr ocess use
tr anspor t del ay.
Suppose we have a condi ti onal si gnal assi gnment:
s <= waveform_1 when condition_1 else
waveform_2 when condition_2 else
waveform_n;
Then the equi val ent process i s:
process
if condition_1 then
s <= waveform_1;
elsif condition_2 then
s <= waveform_2;
elsif
el se
s <= waveform_n;
wait [ sensitivity_clause ];
end process;
I f none of the wavefor m val ue expr essi ons or condi ti ons contai ns a
reference to a si gnal , then the wai t statement at the end of the equi val ent
process has no sensi ti vi ty cl ause. Thi s means that after the assi gnment i s
made, the pr ocess suspends i ndefi ni tel y. For exampl e, the condi ti onal
assi gnment:
reset <= '1', '0' after 10 ns when short_pulse_required else
'1', '0' after 50 ns;
schedul es two transacti ons on the si gnal reset, then suspends for the rest of
the si mul ati on.
On the other hand, i f there are references to si gnal s i n the waveform
val ue expressi ons or condi ti ons, then the wai t statement has a sensi ti vi ty
l i st consi sti ng of al l of the si gnal s referenced. So the condi ti onal
assi gnment:
mux_out <= 'Z' after Tpd when en = '0' else
in_0 after Tpd when sel = '0' else
in_1 after Tpd;
i s sensi ti ve to the si gnal s en and sel. The process i s acti vated duri ng the
i ni ti al i zati on phase, and thereafter whenever ei ther of en or sel changes
val ue.
The degener ate case of a condi ti onal si gnal assi gnment, contai ni ng no
condi ti onal parts, i s equi val ent to a process contai ni ng just a si gnal
assi gnment statement. So:
s <= waveform;
i s equi val ent to:
process
s <= waveform;
end process;
4.3.2. Selected Signal Assignment
A sel ected si gnal assi gnment statement i s a shor thand for a pr ocess
contai ni ng si gnal assi gnments i n a case statement. The syntax i s:
sel ected_si gnal _assi gnment ::=
with expressi on select
tar get <= opti ons sel ected_wavefor ms ;
sel ected_wavefor ms ::=
{ waveform when choi ces , }
waveform when choi ces
choi ces ::= choi ce { | choi ce }
The opti ons part i s the same as for a condi ti onal si gnal assi gnment. So i f
the wor d transport i s i ncl uded, then the si gnal assi gnments i n the
equi val ent process use transport del ay.
Suppose we have a sel ected si gnal assi gnment:
with expression select
s <= waveform_1 when choice_list_1,
waveform_2 when choice_list_2,
waveform_n when choice_list_n;

Then the equi val ent process i s:
process
case expression is
when choice_list_1=>
s <= waveform_1;
when choice_list_2=>
s <= waveform_2;
when choice_list_n=>
s <= waveform_n;
end case;
end process;
The sensi ti vi ty l i st for the wai t statement i s determi ned i n the same way as
for a condi ti onal si gnal assi gnment. That i s, i f no si gnal s ar e r efer enced i n
the sel ected si gnal assi gnment expr essi on or wavefor ms, the wai t
statement has no sensi ti vi ty cl ause. Otherwi se the sensi ti vi ty cl ause
contai ns al l the si gnal s r efer enced i n the expr essi on and wavefor ms.
An exampl e of a sel ected si gnal assi gnment statement:
with alu_function select
alu_result <= op1 + op2 when alu_add | alu_incr,
op1 op2 when alu_subtract,
op1 and op2 when alu_and,
op1 or op2 when alu_or,
op1 and not op2 when alu_mask;
I n thi s exampl e, the val ue of the si gnal alu_function i s used to sel ect whi ch
si gnal assi gnment to alu_result to execute. The statement i s sensi ti ve to the
si gnal s alu_function, op1 and op2, so whenever any of these change val ue, the
sel ected si gnal assi gnment i s r esumed.
5-1
5. Model Organisation
The previ ous chapters have descri bed the vari ous faci l i ti es of VHDL
somewhat i n i sol ati on. The purpose of thi s chapter i s to show how they are
al l ti ed together to form a compl ete VHDL descri pti on of a di gi tal system.
5.1. Design Units and Libraries
When you wri te VHDL descri pti ons, you wri te them i n a design file,
then i nvoke a compi l er to anal yse them and i nsert them i nto a design
library. A number of VHDL constructs may be separatel y anal ysed for
i ncl usi on i n a desi gn l i br ar y. These constr ucts ar e cal l ed library units.
The primary l i br ar y uni ts ar e enti ty decl ar ati ons, package decl ar ati ons and
confi gur ati on decl ar ati ons (see Secti on 5.2). The secondary l i brary uni ts
are archi tecture bodi es and package bodi es. These l i brary uni ts depend on
the speci fi cati on of thei r i nter face i n a cor r espondi ng pr i mar y l i br ar y uni t,
so the pr i mar y uni t must be anal ysed befor e any cor r espondi ng secondar y
uni t.
A desi gn fi l e may contai n a number of l i brary uni ts. The structure of a
desi gn fi l e can be speci fi ed by the syntax:
desi gn_fi l e ::= desi gn_uni t { desi gn_uni t }
desi gn_uni t ::= context_cl ause l i br ar y_uni t
context_cl ause ::= { context_i tem }
context_i tem ::= l i br ar y_cl ause | use_cl ause
l i br ar y_cl ause ::= library l ogi cal _name_l i st ;
l ogi cal _name_l i st ::= l ogi cal _name { , l ogi cal _name }
l i br ar y_uni t ::= pr i mar y_uni t | secondar y_uni t
pr i mar y_uni t ::=
enti ty_decl ar ati on | confi gur ati on_decl ar ati on | package_decl ar ati on
secondar y_uni t ::= ar chi tectur e_body | package_body
Li br ar i es ar e r efer r ed to usi ng i denti fi er s cal l ed l ogi cal names. Thi s
name must be transl ated by the host operati ng system i nto an
i mpl ementati on dependent stor age name. For exampl e, desi gn l i br ar i es
may be i mpl emented as database fi l es, and the l ogi cal name mi ght be used
to determi ne the database fi l e name. Li brary uni ts i n a gi ven l i brary can be
referred to by prefi xi ng thei r name wi th the l i brary l ogi cal name. So for
exampl e, ttl_lib.ttl_10 woul d refer to the uni t ttl_10 i n l i brary ttl_lib.
The context cl ause pr ecedi ng each l i br ar y uni t speci fi es whi ch other
l i brari es i t references and whi ch packages i t uses. The scope of the names
made vi si bl e by the context cl ause extends unti l the end of the desi gn uni t.
There are two speci al l i brari es whi ch are i mpl i ci tl y avai l abl e to al l
desi gn uni ts, and so do not need to be named i n a l i brary cl ause. The fi rst of
these i s cal l ed work, and refers to the worki ng desi gn l i brary i nto whi ch the
current desi gn uni ts wi l l be pl aced by the anal yser. Hence i n a desi gn uni t,
the previ ousl y anal ysed desi gn uni ts i n a desi gn fi l e can be referred to
usi ng the l i br ar y name work.
The second speci al l i bary i s cal l ed std, and contai ns the packages
standard and textio. Standard contai ns al l of the predefi ned types and
functi ons. Al l of the i tems i n thi s package are i mpl i ci tl y vi si bl e, so no use
cl ause i s necessar y to access them.
5.2. Configurations
I n Secti ons 3.2.3 and 3.2.4 we showed how a structural descri pti on can
decl ar e a component speci fi cati on and cr eate i nstances of components. We
menti oned that a component decl ared can be thought of as a templ ate for a
desi gn enti ty. The bi ndi ng of an enti ty to thi s templ ate i s achi eved through
a confi gurati on decl arati on. Thi s decl arati on can al so be used to speci fy
actual gener i c constants for components and bl ocks. So the confi gur ati on
decl ar ati on pl ays a pi votal r ol e i n or gani si ng a desi gn descr i pti on i n
pr epar ati on for si mul ati on or other pr ocessi ng.
The syntax of a confi gur ati on decl ar ati on i s:
confi gur ati on_decl ar ati on ::=
configuration i denti fi er of entity_name is
confi gur ati on_decl ar ati ve_par t
bl ock _confi gur ati on
end [ configuration_si mpl e_name ] ;
confi gur ati on_decl ar ati ve_par t ::= { confi gur ati on_decl ar ati ve_i tem }
confi gur ati on_decl ar ati ve_i tem ::= use_cl ause
bl ock_confi gur ati on ::=
for bl ock_speci fi cati on
{ use_cl ause }
{ confi gur ati on_i tem }
end for ;
bl ock_speci fi cati on ::= archi tecture_name | block_statement_l abel
confi gur ati on_i tem ::= bl ock_confi gur ati on | component_confi gur ati on
component_confi gur ati on ::=
for component_speci fi cati on
[ use bi ndi ng_i ndi cati on ; ]
[ bl ock_confi gur ati on ]
end for ;
component_speci fi cati on ::= i nstanti ati on_l i st : component_name
i nstanti ati on_l i st ::=
instantiation_l abel { , instantiation_l abel )
| others
| all
bi ndi ng_i ndi cati on ::=
enti ty_aspect
[ gener i c_map_aspect ]
[ port_map_aspect ]
enti ty_aspect ::=
entity entity_name [ ( architecture_i denti fi er ) ]
| configuration configuration_name
| open
gener i c_map_aspect ::= generic map ( generic_associ ati on_l i st )
5. Model Organisation 5-3
entity processor is
generic (max_clock_speed : frequency := 30 MHz);
port ( port list );
end processor;
architecture block_structure of processor is
declarations
begi n
control_unit : block
port ( port list );
port map ( association list );
declarations for control_unit
begi n
statements for control_unit
end block control_unit;
data_path : block
port ( port list );
declarations for data_path
begi n
statements for data_path
end block_structure;
Figure 5-1. Example processor entity and architecture body.
port_map_aspect ::= port map ( port_associ ati on_l i st )
The decl arati ve part of the confi gurati on decl arati on al l ows the
confi gur ati on to use i tems fr om l i br ar i es and packages. The outer most
bl ock confi gur ati on i n the confi gur ati on decl ar ati on defi nes the
confi gur ati on for an ar chi tectur e of the named enti ty. For exampl e, i n
Chapter 3 we had an exampl e of a processor enti ty and archi tecture,
outl i ned agai n i n Fi gure5-1. The overal l structure of a confi gurati on
decl ar ati on for thi s ar chi tectur e mi ght be:
configuration test_config of processor is
use work.processor_types.all
for block_structure
configuration items
end for;
end test_config;
I n thi s exampl e, the contents of a package cal l ed processor_types i n the
cur r ent wor ki ng l i br ar y ar e made vi si bl e, and the bl ock confi gur ati on
refers to the archi tecture block_structure of the enti ty processor.
Wi thi n the bl ock confi gurati on for the archi tecture, the submodul es of
the ar chi tectur e may be confi gur ed. These submodul es i ncl ude bl ocks and
component i nstances. A bl ock i s confi gured wi th a nested bl ock
confi gurati on. For exampl e, the bl ocks i n the above archi tecture can be
confi gur ed as shown i n Fi gur e5-2.
Wher e a submodul e i s an i nstance of a component, a component
confi gurati on i s used to bi nd an enti ty to the component i nstance. To
i l l ustrate, suppose the data_path bl ock i n the above exampl e contai ned an
configuration test_config of processor is
use work.processor_types.all
for block_structure
for control_unit
configuration items
end for;
for data_path
configuration items
end for;
end for;
end test_config;
Figure5-2. Configuration of processor example.
data_path : block
port ( port list );
component alu
port (function : in alu_function;
op1, op2 : in bit_vector_32;
result : out bit_vector_32);
end component;
other declarations for data_path
begi n
data_alu : alu
port map (function => alu_fn, op1 => b1, op2 => b2, result => alu_r);
other statements for data_path
Figure5-3. Structure of processor data-path block.
i nstance of the component alu, decl ared as shown i n Fi gure5-3. Suppose
al so that a l i brary project_cells contai ns an enti ty cal l ed alu_cell defi ned as:
entity alu_cell is
generic (width : positive);
port (function_code : in alu_function;
operand1, operand2 : in bit_vector(width-1 downto 0);
result : out bit_vector(width-1 downto 0);
flags : out alu_flags);
end alu_cell;
wi th an archi tecture cal l ed behaviour. Thi s enti ty matches the alu
component templ ate, si nce i ts oper and and r esul t por ts can be constr ai ned
to match those of the component, and the fl ags port can be l eft unconnected.
A bl ock confi gurati on for data_path coul d be speci fi ed as shown i n
Fi gur e5-4.
Al ternati vel y, i f the l i brary al so contai ned a confi gurati on cal l ed
alu_struct for an archi tecture structure of the enti ty alu_cell, then the bl ock
confi gur ati on coul d use thi s, as shown i n Fi gur e5-5.
for data_path
for data_alu : alu
use entity project_cells.alu_cell(behaviour)
generic map (width => 32)
port map (function_code => function, operand1 => op1, operand2 => op2,
result => result, flags => open);
end for;
other configuration items
end for;
Figure5-4. Block configuration using library entity.
for data_path
for data_alu : alu
use configuration project_cells.alu_struct
port map (function_code => function, operand1 => op1, operand2 => op2,
result => result, flags => open);
end for;
other configuration items
end for;
Figure5-5. Block configuration using another configuration.
5.3. Complete Design Example
To i l l ustrate the overal l structure of a desi gn descri pti on, a compl ete
desi gn fi l e for the exampl e i n Secti on1.4 i s shown i n Fi gure5-6. The desi gn
fi l e contai ns a number of desi gn uni ts whi ch ar e anal ysed i n or der . The
fi rst desi gn uni t i s the enti ty decl arati on of count2. Fol l owi ng i t are two
secondary uni ts, archi tectures of the count2 enti ty. These must fol l ow the
enti ty decl arati on, as they are dependent on i t. Next i s another enti ty
decl arati on, thi s bei ng a test bench for the counter. I t i s fol l owed by a
secondary uni t dependent on i t, a structural descri pti on of the test bench.
Fol l owi ng thi s i s a confi gurati on decl arati on for the test bench. I t refers to
the previ ousl y defi ned l i brary uni ts i n the worki ng l i brary, so no l i brary
cl ause i s needed. Noti ce that the count2 enti ty i s referred to i n the
confi gur ati on as work.count2, usi ng the l i brary name. Lastl y, there i s a
confi gur ati on decl ar ati on for the test bench usi ng the str uctur al
archi tecture of count2. I t uses two l i brary uni ts from a separate reference
l i brary, misc. Hence a l i brary cl ause i s i ncl uded before the confi gurati on
decl arati on. The l i brary uni ts from thi s l i brary are referred to i n the
confi gurati on as misc.t_flipflop and misc.inverter.
Thi s desi gn descri pti on i ncl udes al l of the desi gn uni ts i n one fi l e. I t i s
equal l y possi bl e to separate them i nto a number of fi l es, wi th the opposi te
extreme bei ng one desi gn uni t per fi l e. I f mul ti pl e fi l es are used, you need
to take care that you compi l e the fi l es i n the correct order, and re-compi l e
dependent fi l es i f changes are made to one desi gn uni t. Source code control
systems can be of use i n automati ng thi s process.
-- primary unit: entity declaration of count2
entity count2 is
generic (prop_delay : Time := 10 ns);
q1, q0 : out bit);
end count2;
-- secondary unit: a behavioural architecture body of count2
architecture behaviour of count2 is
begi n
count_up: process (clock)
variable count_value : natural := 0;
begi n
if clock = '1' then
count_value := (count_value + 1) mod 4;
q0 <= bit'val(count_value mod 2) after prop_delay;
q1 <= bit'val(count_value / 2) after prop_delay;
end if;
end process count_up;
end behaviour;
-- secondary unit: a structural architecture body of count2
architecture structure of count2 is
component t_flipflop
port (ck : in bit; q : out bit);
end component;
component inverter
port (a : in bit; y : out bit);
end component;
signal ff0, ff1, inv_ff0 : bit;
begi n
bit_0 : t_flipflop port map (ck => clock, q => ff0);
inv : inverter port map (a => ff0, y => inv_ff0);
bit_1 : t_flipflop port map (ck => inv_ff0, q => ff1);
q0 <= ff0;
q1 <= ff1;
end structure;
Figure5-6. Complete design file.
-- primary unit: entity declaration of test bench
entity test_count2 is
end test_count2;
-- secondary unit: structural architecture body of test bench
architecture structure of test_count2 is
signal clock, q0, q1 : bit;
component count2
q1, q0 : out bit);
end component;
begi n
counter : count2
port map (clock => clock, q0 => q0, q1 => q1);
clock_driver : process
begi n
clock <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_driver;
end structure;
-- primary unit: configuration using behavioural architecture
configuration test_count2_behaviour of test_count2 is
for structure -- of test_count2
for counter : count2
use entity work.count2(behaviour);
end for;
end for;
end test_count2_behaviour;
-- primary unit: configuration using structural architecture
library misc;
configuration test_count2_structure of test_count2 is
for structure -- of test_count2
for counter : count2
use entity work.count2(structure);
for structure -- of count_2
for all : t_flipflop
use entity misc.t_flipflop(behaviour);
end for;
for all : inverter
use entity misc.inverter(behaviour);
end for;
end for;
end for;
end for;
end test_count2_structure;
Figure5-6 (continued).
6-1
6. Advanced VHDL
Thi s chapter descr i bes some mor e advanced faci l i ti es offer ed i n VHDL.
Al though you can wr i te many model s usi ng just the par ts of the l anguage
covered i n the previ ous chapters, you wi l l fi nd the features descri bed here
wi l l si gni fi cantl y extend your model wr i ti ng abi l i ti es.
6.1. Signal Resolution and Buses
I n many di gi tal sytems, buses are used to connect a number of output
dr i ver s to a common si gnal . For exampl e, i f open-col l ector or open-dr ai n
output dri vers are used wi th a pul l -up l oad on a si gnal , the si gnal can be
pul l ed l ow by any dri ver, and i s onl y pul l ed hi gh by the l oad when al l
dri vers are off. Thi s i s cal l ed a wired-or or wired-and connecti on. On the
other hand, i f tri -state dri vers are used, at most one dri ver may be acti ve at
a ti me, and i t determi nes the si gnal val ue.
VHDL normal l y al l ows onl y one dri ver for a si gnal . (Recal l that a dri ver
i s defi ned by the si gnal assi gnments i n a process.) I n order to model
si gnal s wi th mul ti pl e dri vers, VHDL uses the noti on of resolved types for
si gnal s. A resol ved type i ncl udes i n i ts defi ni ti on a resol uti on functi on,
whi ch takes the val ues of al l the dri vers contri buti ng to a si gnal , and
combi nes them to deter mi ne the fi nal si gnal val ue.
A resol ved type for a si gnal i s decl ared usi ng the syntax for a subtype:
subtype_i ndi cati on ::= [ resolution_function_name ] type_mar k [ constr ai nt ]
The r esol uti on functi on name i s the name of a functi on pr evi ousl y defi ned.
The functi on must take a par ameter whi ch i s an unconstr ai ned ar r ay of
val ues of the si gnal subtype, and must return a resul t of that subtype. To
i l l ustr ate, consi der the decl ar ati ons:
type logic_level is (L, Z, H);
type logic_array is array (integer range <>) of logic_level;
function resolve_logic (drivers : in logic_array) return logic_level;
subtype resolved_level is resolve_logic logic_level;
I n thi s exampl e, the type logic_level represents three possi bl e states for a
di gi tal si gnal : l ow (L), hi gh-i mpedance (Z) and hi gh (H). The subtype
resolved_level can be used to decl are a resol ved si gnal of thi s type. The
r esol uti on functi on mi ght be i mpl emented as shown i n Fi gur e6-1.
Thi s functi on i terates over the array of dri vers, and i f any i s found to have
the val ue L, the functi on returns L. Otherwi se the functi on returns H, si nce
al l dri vers are ei ther Z or H. Thi s model s a wi red-or si gnal wi th a pul l -up.
Note that i n some cases a resol uti on functi on may be cal l ed wi th an empty
array as the parameter, and shoul d handl e that case appropri atel y. The
exampl e above handl es i t by returni ng the val ue H, the pul l ed-up val ue.
function resolve_logic (drivers : in logic_array) return logic_level;
begi n
for index in drivers'range loop
if drivers(index) = L then
return L;
end if;
end loop;
return H;
end resolve_logic;
Figure 7-1. Resolution function for three-state logic
6.2. Null Transactions
VHDL provi des a faci l i ty to model outputs whi ch may be turned off (for
exampl e tri -state dri vers). A si gnal assi gnment may speci fy that no val ue
i s to be assi gned to a resol ved si gnal , that i s, that the dri ver shoul d be
di sconnected. Thi s i s done wi th a nul l waveform el ement. Recal l that the
syntax for a wavefor m el ement i s:
wavefor m_el ement ::=
value_expressi on [ after time_expr essi on ]
| null [ after time_expressi on ]
So an exampl e of such a si gnal assi gnment i s:
d_out <= null after Toz;
I f al l of the dri vers of a resol ved si gnal are di sconnected, the questi on of
the r esul ti ng si gnal val ue ar i ses. Ther e ar e two possi bi l i ti es, dependi ng on
whether the si gnal was decl ar ed wi th si gnal ki nd register or bus. For
r egi ster ki nd si gnal s, the most r ecentl y deter mi ned val ue r emai ns on the
si gnal . Thi s can be used to model charge storage nodes i n MOS l ogi c
fami l i es. For bus ki nd si gnal s, the r esol uti on functi on must deter mi ne the
val ue for the si gnal when no dri vers are contri buti ng to i t. Thi s i s how tri -
state, open-col l ector and open-drai n buses woul d typi cal l y be model ed.
6.3. Generate Statements
VHDL has an addi ti onal concur r ent statement whi ch can be used i n
ar chi tectur e bodi es to descr i be r egul ar str uctur es, such as ar r ays of bl ocks,
component i nstances or pr ocesses. The syntax i s:
gener ate_statement ::=
generate_l abel :
generati on_scheme generate
{ concur r ent_statement }
end generate [ generate_l abel ] ;
gener ati on_scheme ::=
for generate_par ameter _speci fi cati on
| if condi ti on
The for gener ati on scheme descr i bes str uctur es whi ch have a r epeati ng
pattern. The i f generati on scheme i s usual l y used to handl e excepti on
cases wi thi n the structure, such as occur at the boundari es. Thi s i s best
i l l ustrated by exampl e. Suppose we want to descri be the structure of an
6. Advanced VHDL 6-3
adder : for i in 0 to width-1 generate
ls_bit : if i = 0 generate
ls_cell : half_adder port map (a(0), b(0), sum(0), c_in(1));
end generate lsbit;
middle_bit : if i > 0 and i < width-1 generate
middle_cell : full_adder port map (a(i), b(i), c_in(i), sum(i), c_in(i+1));
end generate middle_bit;
ms_bit : if i = width-1 generate
ms_cell : full_adder port map (a(i), b(i), c_in(i), sum(i), carry);
end generate ms_bit;
end generate adder;
Figure6-2. Generate statement for adder.
adder constructed out of ful l -adder cel l s, wi th the excepti on of the l east
si gni fi cant bi t, whi ch i s consi sts of a hal f-adder. A generate statement to
achi eve thi s i s shown i n Fi gure6-2.
The outer generate statement i terates wi th i taki ng on val ues from 0 to
width-1. For the l east si gni fi cant bi t (i=0), an i nstance of a hal f adder
component i s generated. The i nput bi ts are connected to the l east
si gni fi cant bi ts of a and b, the output bi t i s connected to the l east si gni fi cant
bi t of sum, and the carry bi t i s connectected to the carry i n of the next stage.
For i ntermedi ate bi ts, an i nstance of a ful l adder component i s generated
wi th i nputs and outputs connected si mi l arl y to the fi rst stage. For the most
si gni fi cant bi t (i=width-1), an i nstance of the hal f adder i s al so generated, but
i ts carry output bi t i s connected to the si gnal carry.
6.4. Concurrent Assertions and Procedure Calls
There are two ki nds of concurrent statement whi ch were not covered i n
pr evi ous chapter s: concur r ent asser ti ons and concur r ent pr ocedur e cal l s.
A concur r ent asser ti on statement i s equi val ent to a pr ocess contai ni ng onl y
an asserti on statement fol l owed by a wai t statement. The syntax i s:
concur r ent_asser ti on_statement ::= [ l abel : ] asser ti on_statement
The concur r ent si gnal asser ti on:
L : assert condition report error_string severity severity_value;
i s equi val ent to the process:
L : process
begi n
assert condition report error_string severity severity_value;
wait [ sensitivity_clause ] ;
end process L;
The sensi ti vi ty cl ause i ncl udes al l the si gnal s whi ch ar e r efer r ed to i n
the condi ti on expr essi on. I f no si gnal s ar e r efer enced, the pr ocess i s
acti vated once at si mul ati on i ni ti al i sati on, checks the condi ti on, and then
suspends i ndefi ni tel y.
The other concur r ent statement, the concur r ent pr ocedur e cal l , i s
equi val ent to a process contai ni ng onl y a procedure cal l fol l owed by a wai t
statement. The syntax i s:
concur r ent_pr ocedur e_cal l ::= [ l abel : ] pr ocedur e_cal l _statement
The pr ocedur e may not have any for mal par ameter s of cl ass variable,
si nce i t i s not possi bl e for a vari abl e to be vi si bl e at any pl ace where a
concurrent statement may be used. The sensi ti vi ty l i st of the wai t
statement i n the pr ocess i ncl udes al l the si gnal s whi ch ar e actual
par ameter s of mode in or inout i n the procedure cal l . These are the onl y
si gnal s whi ch can be r ead by the cal l ed pr ocedur e.
Concur r ent pr ocedur e cal l s ar e useful for defi ni ng pr ocess behavi our
that may be reused i n several pl aces or i n di fferent model s. For exampl e,
suppose a package bit_vect_arith decl ar es the pr ocedur e:
procedure add(signal a, b : in bit_vector; signal result : out bit_vector);
Then an exampl e of a concur r ent pr ocedur e cal l usi ng thi s pr ocedur e i s:
adder : bit_vect_arith.add (sample, old_accum, new_accum);
Thi s woul d be equi val ent to the process:
adder : process
begi n
bit_vect_arith.add (sample, old_accum, new_accum);
wait on sample, old_accum;
end process adder;
6.5. Entity Statements
I n Secti on3.1, i t was menti oned that an enti ty decl arati on may i ncl ude
statements for moni tori ng operati on of the enti ty. Recal l that the syntax for
an enti ty decl arati on i s:
enti ty_decl ar ati on ::=
entity i denti fi er is
enti ty_header
enti ty_decl ar ati ve_par t
[ begin
enti ty_statement_part ]
end [ entity_si mpl e_name ] ;
The syntax for the statement part i s:
enti ty_statement_part ::= { enti ty_statement }
enti ty_statement ::=
concur r ent_asser ti on_statement
| passive_concur r ent_pr ocedur e_cal l
| passive_pr ocess_statement
The concurrent statement that are al l owed i n an enti ty decl arati on must
be passive, that i s, they may not contai n any si gnal assi gnments. (Thi s
i ncl udes si gnal assi gnments i nsi de nested pr ocedur es of a pr ocess.) A
resul t of thi s rul e i s that such processes cannot modi fy the state of the
enti ty, or any ci rcui t the enti ty may be used i n. However, they can ful l y
moni tor the state, and so may be used to report erroneous operati ng
condi ti ons, or to trace the behavi or of the desi gn.
7-1
31 0
31 0
31 0
R0
R255
PC
V N Z
CC
Figure 7-1. DP32 registers.
7. Sample Models: The DP32 Processor
Thi s chapter contai ns an extended exampl e, a descr i pti on of a
hypotheti cal processor cal l ed the DP32. The processor i nstructi on set and
bus ar chi tectur es ar e fi r st descr i bed, and then a behavi our al descr i pti on i s
gi ven. A test bench model i s constructed, and the model checked wi th a
smal l test pr ogr am. Next, the pr ocessor i s decomposed i nto components at
the regi ster transfer l evel . A number of components are descri bed, and a
str uctur al descr i pti on of the pr ocessor i s constr ucted usi ng these
components. The same test bench i s used, but thi s ti me wi th the structural
ar chi tectur e.
7.1. Instruction Set Architecture
The DP32 i s a 32-bi t processor wi th a si mpl e i nstructi on set. I t has a
number of regi sters, shown i n Fi gure 7-1. There are 256 general purpose
r egi ster s (R0R255), a pr ogr am counter (PC) and a condi ti on code r egi ster
(CC). The gener al pur pose r egi ster s ar e addr essabl e by softwar e, wher eas
the PC and CC regi sters are not.
On reset, the PC i s i ni ti al i sed to zero, and al l other regi sters are
undefi ned. By conventi on, R0 i s read-onl y and contai ns zero. Thi s i s not
enforced by hardware, and the zero val ue must be l oaded by software after
r eset.
The memory accessi bl e to the DP32 consi sts of 32-bi t words, addressed by
a 32-bi t word-address. I nstructi ons are al l mul ti pl es of 32-bi t words, and
are stored i n thi s memory. The PC regi ster contai ns the address of the next
i nstructi on to be executed. After each i nstructi on word i s fetched, the PC i s
i ncremented by one to poi nt to the next word.
The three CC regi ster bi ts are updated after each ari thmeti c or l ogi cal
i nstructi on. The Z (zero) bi t i s set i f the resul t i s zero. The N (negati ve) bi t
i s set i f the resul t of an ari thmeti c i nstructi on i s negati ve, and i s undefi ned
after l ogi cal i nstructi ons. The V(overfl ow) bi t i s set i f the resul t of an
ar i thmeti c i nstr ucti on exceeds the bounds of r epr esentabl e i nteger s, and i s
I nstr ucti on Name Functi on opcode
Add add
r3 r1 + r2
X00
Sub subtr act
r3 r1 r2
X01
Mu l mul ti pl y
r3 r1 r2
X02
Div di vi de
r3 r1 r2
X03
Addq add qui ck
r3 r1 + i 8
X10
Subq subtract qui ck
r3 r1 i 8
X11
Mul q mul ti pl y qui ck
r3 r1 i 8
X12
Divq di vi de qui ck
r3 r1 i 8
X13
Land l ogi cal and
r3 r1 & r2
X04
Lor l ogi cal or
r3 r1 | r2
X05
Lxor l ogi cal excl usi ve or
r3 r1 r2
X06
Lmask l ogi cal mask
r3 r1 & ~r2
X07
Table7-1. DP32 arithmetic and logic instructions.
undefi ned after l ogi cal i nstr ucti ons.
The DP32 i nstructi on set i s di vi ded i nto a number of encodi ng formats.
Fi rstl y, ari thmeti c and l ogi cal i nstructi ons are al l one 32-bi t word l ong,
for matted as fol l ows:
op r3 r1 r2/i8 (Addr):
31 24 23 16 15 8 7 0
The op fi el d i s the op-code, r3 i s the desti nati on regi ster address, r1 and r2
ar e sour ce r egi ster addr esses, and i 8 i s an i mmedi ate two-compl i ment
i nteger oper and. The ar i thmeti c and l ogi cal i nstr ucti ons ar e l i sted i n
Tabl e7-1.
Memor y l oad and stor e i nstr ucti ons have two for mats, dependi ng on
whether a l ong or short di spl acement val ue i s used. The format for a l ong
di spl acement i s:
op r3 r1 ignored (Addr):
31 24 23 16 15 8 7 0
(Addr+1):
disp
The for mat for a shor t di spl acement i s:
op r3 r1 i8 (Addr):
31 24 23 16 15 8 7 0
The op fi el d i s the op-code, r3 speci fi es the regi ster to be l oaded or stored, r1
i s used as an i ndex r egi ster , di sp i s a l ong i mmedi ate di spl acement, and i 8
i s a shor t i mmedi ate di spl acement. The l oad and stor e i nstr ucti ons ar e
l i sted i n Tabl e7-2.
7. Sample Models: The DP32 Processor 7-3
Ld l oad
r3 M[r1 + di sp32]
X20
St stor e
M[r1 + di sp32] r3
X21
Ldq l oad qui ck
r3 M[r1 + i 8]
X30
Stq store qui ck
M[r1 + i 8] r3
X31
Table7-2. DP32 load and store instructions.
Br -ivnz br anch i f cond then
PC PC + di sp32
X40
Brq-ivnz br anch qui ck i f cond then
PC PC + i 8
X51
Bi -ivnz br anch i ndexed i f cond then
PC r1 + di sp32
X41
Bi q-ivnz br anch i ndexed
qui ck
i f cond then
PC r1 + i 8
X51
Table7-3. DP32 load and store instructions.
Fi nal l y, there are four branch i nstructi ons, l i sted i n Tabl e7-3, each wi th
a sl i ghtl y di fferent format. The format of the ordi nary brach i s:
op xxxx (Addr):
31 24 23 16 15 8 7 0
(Addr+1):
disp
ivnz xxxx
20 19
xxxx
The format of a qui ck branch i s:
op (Addr):
31 24 23 16 15 8 7 0
ivnz xxxx
20 19
xxxx i8
The for mat of an i ndexed br anch
op r1 xxxx (Addr):
31 24 23 16 15 8 7 0
(Addr+1):
disp
ivnz xxxx
20 19
The format of a qui ck i ndexed branch
op (Addr):
31 24 23 16 15 8 7 0
ivnz xxxx
20 19
i8 r1
The op fi el d i s the op-code, di sp i s a l ong i mmedi ate di spl acement, i 8 i s a
shor t i mmedi ate di spl acement, r 1 i s used as an i ndex r egi ster , and i vnz i s
a the condi ti on mask. The branch i s taken i f
cond ((V & v) | (N & n) | (Z & z)) = i .
PHI1
PHI2
RESET
FETCH
READ
WRITE
A_BUS
D_BUS
READY
DP32
Figure7-2. DP32 port diagram.
phi1
phi2
Figure7-3. DP32 clock waveforms.
7.2. Bus Architecture
The DP32 pr ocessor communi cates wi th i ts memor y over synchr onous
32-bi t address and data buses. The external ports of the DP32 are shown i n
Fi gur e7-2.
The two cl ock i nputs, phi1 and phi2, pr ovi de a two-phase non-over l appi ng
cl ock for the pr ocessor . The cl ock wavefor ms ar e shown i n Fi gur e7-3.
Each cycl e of the phi1 cl ock defi nes a bus state, one of Ti (i dl e), T1 or T2. Bus
transacti ons consi st of a T1 state fol l owed by one or more T2 states, wi th Ti
states between transacti ons.
The port a_bus i s a 32-bi t address bus, and d_bus i s a 32-bi t bi di recti on
data bus. The read and write ports control bus read and wri te transacti ons.
The fetch port i s a status si gnal i ndi cati ng that a bus read i n progress i s an
i nstructi on fetch. The ready i nput i s used by a memory devi ce to i ndi cate
that read data i s avai l abl e or wri te data has been accepted.
The ti mi ng for a bus read transacti on i s show i n Fi gure7-4. Duri ng an
i dl e state, Ti , the processor pl aces the memory address on the address bus
to start the transacti on. The next state i s a T1 state. After the l eadi ng edge
of the phi1 cl ock, the processor asserts the read contr ol si gnal , i ndi cati ng
that the address i s val i d and the memory shoul d start the read transacti on.
The processor al so asserts the fetch si gnal i f i t i s readi ng i nstructi ons. I t
al ways l eaves the write si gnal negated duri ng read transacti ons. Duri ng the
T1 state and the fol l owi ng T2 state, the memory accesses the requested data,
and pl aces i t on the data bus. I f i t has compl eted the data access by the end
of the T2 state, i t asserts ready. The processor accepts the data, and
compl etes the transacti on. On the other hand, i f the memory has not yet
suppl i ed the data by the end of the T2 state, i t l eaves ready fal se. The
processor then repeats T2 states unti l i t detects ready true. By thi s means, a
sl ow memory can extend the transacti on unti l i t has read the data. At the
end of the transacti on, the processor returns i ts control outputs to thei r
defaul t val ues, and the memory negates ready and removes the data from
the data bus. The processor conti nues wi th i dl e states unti l the next
tr ansacti on i s r equi r ed.
The ti mi ng for a bus wri te transacti on i s show i n Fi gure7-5. Here al so,
the transacti on starts wi th the processor pl aci ng the address on the address
bus duri ng a Ti state. After the l eadi ng edge of phi1 duri ng the subsequent
T1 state, the processor negates fetch and asserts write. The read si gnal
remai ns fal se for the whol e transacti on. Duri ng the T1 state, the processor
al so makes the data to be wri tten avai l abl e on the data bus. The memory
phi1
phi2
valid address
a_bus
read
valid data in
d_bus
ready
Ti T1 T2 Ti
fetch
write
valid fetch
Figure7-4. DP32 bus read transaction.
phi1
phi2
valid address
a_bus
write
d_bus
ready
Ti T1 T2 Ti
valid data out
read
fetch
Figure7-5. DP32 bus write transaction.
package dp32_types is
constant unit_delay : Time := 1 ns;
type bool_to_bit_table is array (boolean) of bit;
constant bool_to_bit : bool_to_bit_table;
subtype bit_32 is bit_vector(31 downto 0);
type bit_32_array is array (integer range <>) of bit_32;
function resolve_bit_32 (driver : in bit_32_array) return bit_32;
subtype bus_bit_32 is resolve_bit_32 bit_32;
subtype bit_8 is bit_vector(7 downto 0);
subtype CC_bits is bit_vector(2 downto 0);
subtype cm_bits is bit_vector(3 downto 0);
constant op_add : bit_8 := X"00";
constant op_sub : bit_8 := X"01";
constant op_mul : bit_8 := X"02";
constant op_div : bit_8 := X"03";
constant op_addq : bit_8 := X"10";
constant op_subq : bit_8 := X"11";
constant op_mulq : bit_8 := X"12";
constant op_divq : bit_8 := X"13";
constant op_land : bit_8 := X"04";
constant op_lor : bit_8 := X"05";
constant op_lxor : bit_8 := X"06";
constant op_lmask : bit_8 := X"07";
constant op_ld : bit_8 := X"20";
constant op_st : bit_8 := X"21";
constant op_ldq : bit_8 := X"30";
constant op_stq : bit_8 := X"31";
constant op_br : bit_8 := X"40";
constant op_brq : bit_8 := X"50";
constant op_bi : bit_8 := X"41";
constant op_biq : bit_8 := X"51";
function bits_to_int (bits : in bit_vector) return integer;
function bits_to_natural (bits : in bit_vector) return natural;
procedure int_to_bits (int : in integer; bits : out bit_vector);
end dp32_types;
Figure7-6. Package declaration for dp32_types.
can accept thi s data duri ng the T1 and subsequent T2 states. I f i t has
compl eted the wri te by the end of the T2 state, i t asserts ready. The
processor then compl etes the transacti on and conti nutes wi th Ti states, and
the memory removes the data from the data bus and negates ready. I f the
memory has not had ti me to compl ete the wri te by the end of the T2 state, i t
l eaves ready fal se. The processor wi l l then repeat T2 states unti l i t detects
ready true.
7.3. Types and Entity
We start the descri pti on of the DP32 processor by defi ni ng a package
contai ni ng the data types to be used i n the model , and some useful
operati ons on those types. The package decl arati on of dp32_types i s l i sted i n
Fi gur e7-6.
package body dp32_types is
constant bool_to_bit : bool_to_bit_table :=
(false => '0', true => '1');
function resolve_bit_32 (driver : in bit_32_array) return bit_32 is
constant float_value : bit_32 := X"0000_0000";
variable result : bit_32 := float_value;
begi n
for i in driver'range loop
result := result or driver(i);
end loop;
return result;
end resolve_bit_32;
Figure7-7. Package body for dp32_types.
The constant unit_delay i s used as the defaul t del ay ti me through-out the
DP32 descr i pti on. Thi s appr oach i s common when wr i ti ng model s to
descri be the functi on of a di gi tal system, before devel opi ng a detai l ed ti mi ng
model .
The constant bool_to_bit i s a l ookup tabl e for converti ng between bool ean
condi ti ons and the type bit. Exampl es of i ts use wi l l be seen l ater. Note that
i t i s a deferred constant, so i ts val ue wi l l be gi ven i n the package body.
The next decl arati ons defi ne the basi c 32-bi t word used i n the DP32
model . The functi on resolve_bit_32 i s a resol uti on functi on used to
determi ne the val ue on a 32-bi t bus wi th mul ti pl e dri vers. Such a bus i s
decl ared wi th the subtype bus_bit_32, a resol ved type.
The subtype bit_8 i s part of a 32-bi t word used as an op-code or regi ster
address. CC_bits i s the type for condi ti on codes, and cm_bits i s the type for
the condi ti on mask i n a br anch op-code.
The next set of constant decl arati ons defi ne the op-code bi t patterns for
val i d op-codes. These symbol i c names are used as a matter of good codi ng
styl e, enabl i ng the op-code val ues to be changed wi thout havi ng to modi fy
the model code i n numer ous pl aces.
Fi nal l y, a col l ecti on of conversi on functi ons between bi t-vector val ues
and numer i c val ues i s defi ned. The bodi es for these subpr ogr ams ar e
hi dden i n the package body.
The body of the dp32_types package i s l i sted i n Fi gure7-7. Fi rstl y the
val ue for the deferred constant bool_to_bit i s gi ven: false transl ates to '0' and
true transl ates to '1'. An exampl e of the use of thi s tabl e i s:
flag_bit <= bool_to_bit(flag_condition);
Next, the body of the resol uti on functi on for 32-bi t buses i s defi ned. The
functi on takes as i ts par ameter an unconstr ai ned ar r ay of bit_32 val ues,
and produces as a resul t the bi t-wi de l ogi cal -or of the val ues. Note that the
functi on cannot assume that the l ength of the array wi l l be greater than
one. I f no dri vers are acti ve on the bus, an empty array wi l l be passed to the
resol uti on functi on. I n thi s case, the defaul t val ue of al l '0' bi ts (float_value)
i s used as the resul t.
function bits_to_int (bits : in bit_vector) return integer is
variable temp : bit_vector(bits'range);
variable result : integer := 0;
begi n
if bits(bits'left) = '1' then -- negative number
temp := not bits;
el se
temp := bits;
end if;
for index in bits'range loop -- sign bit of temp = '0'
result := result * 2 + bit'pos(temp(index));
end loop;
if bits(bits'left) = '1' then
result := (-result) - 1;
end if;
return result;
end bits_to_int;
function bits_to_natural (bits : in bit_vector) return natural is
variable result : natural := 0;
begi n
for index in bits'range loop
result := result * 2 + bit'pos(bits(index));
end loop;
return result;
end bits_to_natural;
procedure int_to_bits (int : in integer; bits : out bit_vector) is
variable temp : integer;
variable result : bit_vector(bits'range);
begi n
if int < 0 then
temp := -(int+1);
el se
temp := int;
end if;
for index in bits'reverse_range loop
result(index) := bit'val(temp rem 2);
temp := temp / 2;
end loop;
if int < 0 then
result := not result;
result(bits'left) := '1';
end if;
bits := result;
end int_to_bits;
end dp32_types;
The functi on bits_to_int converts a bi t vector representi ng a twos-
compl i ment si gned i nteger i nto an i nteger type val ue. The l ocal vari abl e
temp i s decl ared to be a bi t vector of the same si ze and i ndex range as the
parameter bi ts. The vari abl e resul t i s i ni ti al i sed to zero when the functi on
i s i nvoked, and subsequentl y used to accumul ate the wei ghted bi t val ues i n
use work.dp32_types.all;
entity dp32 is
generic (Tpd : Time := unit_delay);
port (d_bus : inout bus_bit_32 bus;
a_bus : out bit_32;
read, write : out bit;
fetch : out bit;
ready : in bit;
phi1, phi2 : in bit;
reset : in bit);
end dp32;
Figure7-8. Entity declaration for dp32.
the for l oop. The functi on bits_to_natural performs a si mi l ar functi on to
bits_to_int, but does not need to do any speci al processi ng for negati ve
numbers. Fi nal l y, the functi on int_to_bits performs the i nverse of bits_to_int.
The enti ty decl arati on of the DP32 processor i s shown i n Fi gure7-8. The
l i brary uni t i s preceded by a use cl ause referenci ng al l the i tems i n the
package dp32_types. The enti ty has a generi c constant Tpd used to speci fy
the propagati on del ays between i nput events and output si gnal changes.
The defaul t val ue i s the uni t del ay speci fi ed i n the dp32_types package.
There are a number of ports correspondi ng to those shown i n Fi gure7-2.
The reset, cl ocks, and bus control si gnal s are represented by val ues of type
bit. The address bus output i s a si mpl e bi t-vector type, as the processor i s
the onl y modul e dri vi ng that bus. On the other hand, the data bus i s a
resol ved bi t-vector type, as i t may be dri ven by both the processor and a
memory modul e. The word bus i n the port decl arati on i ndi cates that al l
dri vers for the data bus may be di sconnected at the same ti me (i e, none of
them i s dri vi ng the bus).
7.4. Behavioural Description
I n thi s secti on a behavi oural model of the DP32 processor wi l l be
presented. Thi s model can be used to run test programs i n the DP32
i nstructi on set by connecti ng i t to a si mul ated memory model . The
archi tecture body for the behavi oural descri pti on i s l i sted i n Fi gure7-9.
The decl arati on secti on for the archi tecture body contai ns the
decl arati on for the DP32 regi ster fi l e type, and array of 32-bi t words, i ndexed
by a natural number constrai ned to be i n the range 0 to 255.
The ar chi tectur e body contai ns onl y one concur r ent statement, namel y
an anonymous pr ocess whi ch i mpl ements the behavi our as a sequenti al
al gor i thm. Thi s pr ocess decl ar es a number of var i abl es whi ch r epr esent
the i nternal state of the processor: the regi ster fi l e (reg), the program
counter (PC), and the cur r ent i nstr ucti on r egi ster (current_instr). A number
of wor ki ng var i abl es and al i ases ar e al so decl ar ed.
The procedure memory_read i mpl ements the behavi oural model of a
memor y r ead tr ansacti on. The par ameter s ar e the memor y addr ess to r ead
fr om, a fl ag i ndi cati ng whether the r ead i s an i nstr ucti on fetch, and a
resul t parameter returni ng the data read. The procedure refers to the
architecture behaviour of dp32 is
subtype reg_addr is natural range 0 to 255;
type reg_array is array (reg_addr) of bit_32;
begin -- behaviour of dp32
process
variable reg : reg_array;
variable PC : bit_32;
variable current_instr : bit_32;
variable op: bit_8;
variable r3, r1, r2 : reg_addr;
variable i8 : integer;
alias cm_i : bit is current_instr(19);
alias cm_V : bit is current_instr(18);
alias cm_N : bit is current_instr(17);
alias cm_Z : bit is current_instr(16);
variable cc_V, cc_N, cc_Z : bit;
variable temp_V, temp_N, temp_Z : bit;
variable displacement, effective_addr : bit_32;
Figure7-9. Behavioural architecture body for dp32.
enti ty ports, whi ch are vi si bl e because they are decl ared i n the parent of the
pr ocedur e.
The memory_read model fi rstl y dri ves the address and fetch bi t ports, and
then wai ts unti l the next l eadi ng edge of phi1, i ndi cati ng the start of the next
cl ock cycl e. (The wai t statement i s sensi ti ve to a change from '0' to '1' on
phi1.) When that event occurs, the model checks the state of the reset i nput
port, and i f i t i s set, i mmedi atel y returns wi thout further acti on. I f reset i s
cl ear, the model starts a T1 state by asserti ng the read bi t port a propagati on
del ay ti me after the cl ock edge. I t then wai ts agai n unti l the next phi1
l eadi ng edge, i ndi cati ng the start of the next cl ock cycl e. Agai n, i t checks
reset and di sconti nues i f reset i s set. The model then starts a l oop executi ng
T2 states. I t wai ts unti l phi2 changes from '1' to '0' (at the end of the cycl e),
and then checks reset agai n, returni ng i f i t i s set. Otherwi se i t checks the
ready bi t i nput port, and i f set, accepts the data from the data bus port and
exi ts the l oop. I f ready i s not set, the l oop repeats, addi ng another T2 state to
the transacti on. After the l oop, the model wai ts for the next cl ock edge
i ndi cati ng the start of the Ti state at the end of the transacti on. After
checki ng reset agai n, the model cl ears ready to compl ete the transacti on,
and returns to the parent process.
The pr ocedur e memory_write i s si mi l ar , i mpl ementi ng the model for a
memor y wr i te tr ansacti on. The par ameter s ar e si mpl y the memor y
address to wri te to, and the data to wri te. The model si mi l arl y has reset
checks after each wai t poi nt. One di fference i s that at the end of the
transacti on, there i s a nul l si gnal assi gnment to the data bus port. Thi s
model s the bahavi our of the processor di sconnecti ng from the data bus, that
i s, at thi s poi nt i t stops dri vi ng the port.
procedure memory_read (addr : in bit_32;
fetch_cycle : in boolean;
result : out bit_32) is
begi n
-- start bus cycle with address output
a_bus <= addr after Tpd;
fetch <= bool_to_bit(fetch_cycle) after Tpd;
wait until phi1 = '1';
if reset = '1' then
return;
end if;
--
-- T1 phase
--
read <= '1' after Tpd;
if reset = '1' then
return;
end if;
--
-- T2 phase
--
l oop
if reset = '1' then
return;
end if;
-- end of T2
if ready = '1' then
result := d_bus;
exit;
end if;
end loop;
if reset = '1' then
return;
end if;
--
-- Ti phase at end of cycle
--
end memory_read;
procedure memory_write (addr : in bit_32;
data : in bit_32) is
begi n
-- start bus cycle with address output
a_bus <= addr after Tpd;
fetch <= '0' after Tpd;
if reset = '1' then
return;
end if;
--
-- T1 phase
--
write <= '1' after Tpd;
d_bus <= data after Tpd;
if reset = '1' then
return;
end if;
--
-- T2 phase
--
l oop
if reset = '1' then
return;
end if;
-- end of T2
exit when ready = '1';
end loop;
if reset = '1' then
return;
end if;
--
-- Ti phase at end of cycle
--
d_bus <= null after Tpd;
end memory_write;
procedure add (result : inout bit_32;
op1, op2 : in integer;
V, N, Z : out bit) is
begi n
if op2 > 0 and op1 > integer'high-op2 then -- positive overflow
int_to_bits(((integer'low+op1)+op2)-integer'high-1, result);
V := '1';
elsif op2 < 0 and op1 < integer'low-op2 then -- negative overflow
int_to_bits(((integer'high+op1)+op2)-integer'low+1, result);
V := '1';
el se
int_to_bits(op1 + op2, result);
V := '0';
end if;
N := result(31);
Z := bool_to_bit(result = X"0000_0000");
end add;
procedure subtract (result : inout bit_32;
begi n
if op2 < 0 and op1 > integer'high+op2 then -- positive overflow
int_to_bits(((integer'low+op1)-op2)-integer'high-1, result);
V := '1';
elsif op2 > 0 and op1 < integer'low+op2 then -- negative overflow
int_to_bits(((integer'high+op1)-op2)-integer'low+1, result);
V := '1';
el se
int_to_bits(op1 - op2, result);
V := '0';
end if;
N := result(31);
end subtract;
The next four pr ocedur es, add, subtract, multiply and divide, i mpl ement the
ar i thmeti c oper ati ons on 32-bi t wor ds r epr esenti ng twos-compl ement
si gned i ntegers. They each take two i nteger operands, and produce a 32-bi t
word resul t and the three condi ti on code fl ags V (overfl ow), N (negati ve)
and Z (zero). The resul t parameter i s of mode inout because the test for
negati ve and zero resul ts read i ts val ue after i t has been wri tten. Each
procedure i s careful l y coded to avoi d causi ng an i nteger overfl ow on the
host machi ne executi ng the model (assumi ng that machi ne uses 32-bi t
i ntegers). The add and subtract pr ocedur es wr ap ar ound i f over fl ow occur s,
and multiply and divide return the l argest or smal l est i nteger.
Fol l owi ng these pr ocedur es i s the body of the pr ocess whi ch i mpl ements
the DP32 behavi oural model . Thi s process i s acti vated duri ng the
i ni ti al i sati on phase of a si mul ati on. I t consi sts of thr ee secti ons whi ch ar e
r epeated sequenti al l y: r eset pr ocessi ng, i nstr ucti on fetch, and i nstr ucti on
executi on.
procedure multiply (result : inout bit_32;
begi n
if ((op1>0 and op2>0) or (op1<0 and op2<0)) -- result positive
and (abs op1 > integer'high / abs op2) then -- positive overflow
int_to_bits(integer'high, result);
V := '1';
elsif ((op1>0 and op2<0) or (op1<0 and op2>0)) -- result negative
and ((- abs op1) < integer'low / abs op2) then -- negative overflow
int_to_bits(integer'low, result);
V := '1';
el se
int_to_bits(op1 * op2, result);
V := '0';
end if;
N := result(31);
end multiply;
procedure divide (result : inout bit_32;
begi n
if op2=0 then
if op1>=0 then -- positive overflow
int_to_bits(integer'high, result);
el se
int_to_bits(integer'low, result);
end if;
V := '1';
el se
int_to_bits(op1 / op2, result);
V := '0';
end if;
N := result(31);
end divide;
When the reset i nput i s asserted, al l of the control ports are returned to
thei r i ni ti al states, the data bus dri ver i s di sconnected, and the PC regi ster
i s cl eared. The model then wai ts unti l reset i s negated before proceedi ng.
Throughout the rest of the model , the reset i nput i s checked after each bus
transacti on. I f the transacti on was aborted by reset bei ng asserted, no
fur ther acti on i s taken i n fetchi ng or executi ng an i nstr ucti on, and contr ol
fal l s through to the reset handl i ng code.
The i nstructi on fetch part i s si mpl y a cal l to the memory read
procedure. The PC regi ster i s used to provi de the address, the fetch fl ag i s
true, and the resul t i s returned i nto the current i nstructi on regi ster. The
PC r egi ster i s then i ncr emented by one usi ng the ar i thmeti c pr ocedur e
pr evi ousl y defi ned.
The fetched i nstructi on i s next decoded i nto i ts component parts: the op-
code, the sour ce and desti nati on r egi ster addr esses and an i mmedi ate
constant fi el d. The op-code i s then used as the sel ector for a case statement
begi n
--
-- check for reset active
--
if reset = '1' then
PC := X"0000_0000";
wait until reset = '0';
end if;
--
-- fetch next instruction
--
memory_read(PC, true, current_instr);
if reset /= '1' then
add(PC, bits_to_int(PC), 1, temp_V, temp_N, temp_Z);
--
-- decode & execute
--
op := current_instr(31 downto 24);
r3 := bits_to_natural(current_instr(23 downto 16));
i8 := bits_to_int(current_instr(7 downto 0));
whi ch codes the i nstr ucti on executi on. For the ar i thmeti c i nstr ucti ons
(i ncl udi ng the qui ck for ms), the ar i thmeti c pr ocedur es pr evi ousl y defi ned
are i nvoked. For the l ogi cal i nstructi ons, the regi ster bi t-vector val ues are
used i n VHDL l ogi cal expressi ons to determi ne the bi t-vector resul t. The
condi ti on code Z fl ag i s set i f the resul t i s a bi t-vector of al l '0' bi ts.
The model executes a l oad i nstructi on by fi rstl y readi ng the
di spl acement fr om memor y and i ncr ementi ng the PC r egi ster . The
di spl acement i s added to the val ue of the i ndex regi ster to form the effecti ve
address. Thi s i s then used i n a memory read to l oad the data i nto the resul t
regi ster. A qui ck l oad i s executed si mi l arl y, except that no memory read i s
needed to fetch the di spl acement; the vari abl e i 8 decoded from the
i nstructi on i s used. The store and qui ck store i nstructi ons paral l el the l oad
i nstructi ons, wi th the memory data read bei ng repl aced by a memory data
wr i te.
Executi on of a branch i nstructi on starts wi th a memory read to fetch the
di spl acement, and an add to i ncrement the PC regi ster by one. The
di spl acement i s added to the val ue of the PC regi ster to form the effecti ve
addr ess. Next, the condi ti on expr essi on i s eval uated, compar i ng the
condi ti on code bi ts wi th the condi ti on mask i n the i nstructi on, to determi ne
whether the branch i s taken. I f i t i s, the PC regi ster takes on the effecti ve
addr ess val ue. The br anch i ndexed i nstr ucti on i s si mi l ar , wi th the i ndex
regi ster val ue repl aci ng the PC val ue to form the effecti ve address. The
qui ck br anch for ms ar e al so si mi l ar , wi th the i mmedi ate constant bei ng
used for the di spl acement i nstead of a val ue fetched from memory.
case op is
when op_add =>
add(reg(r3), bits_to_int(reg(r1)), bits_to_int(reg(r2)),
cc_V, cc_N, cc_Z);
when op_addq =>
add(reg(r3), bits_to_int(reg(r1)), i8, cc_V, cc_N, cc_Z);
when op_sub =>
subtract(reg(r3), bits_to_int(reg(r1)), bits_to_int(reg(r2)),
cc_V, cc_N, cc_Z);
when op_subq =>
subtract(reg(r3), bits_to_int(reg(r1)), i8, cc_V, cc_N, cc_Z);
when op_mul =>
multiply(reg(r3), bits_to_int(reg(r1)), bits_to_int(reg(r2)),
cc_V, cc_N, cc_Z);
when op_mulq =>
multiply(reg(r3), bits_to_int(reg(r1)), i8, cc_V, cc_N, cc_Z);
when op_div =>
divide(reg(r3), bits_to_int(reg(r1)), bits_to_int(reg(r2)),
cc_V, cc_N, cc_Z);
when op_divq =>
divide(reg(r3), bits_to_int(reg(r1)), i8, cc_V, cc_N, cc_Z);
when op_land =>
reg(r3) := reg(r1) and reg(r2);
cc_Z := bool_to_bit(reg(r3) = X"0000_0000");
when op_lor =>
reg(r3) := reg(r1) or reg(r2);
when op_lxor =>
reg(r3) := reg(r1) xor reg(r2);
when op_lmask =>
reg(r3) := reg(r1) and not reg(r2);
when op_ld =>
memory_read(PC, true, displacement);
add(effective_addr,
bits_to_int(reg(r1)), bits_to_int(displacement),
temp_V, temp_N, temp_Z);
memory_read(effective_addr, false, reg(r3));
end if;
when op_ldq =>
add(effective_addr,
bits_to_int(reg(r1)), i8,
memory_read(effective_addr, false, reg(r3));
when op_st =>
add(effective_addr,
memory_write(effective_addr, reg(r3));
end if;
when op_stq =>
add(effective_addr,
memory_write(effective_addr, reg(r3));
when op_br =>
add(effective_addr,
bits_to_int(PC), bits_to_int(displacement),
if ((cm_V and cc_V) or (cm_N and cc_N) or (cm_Z and cc_Z))
= cm_i then
PC := effective_addr;
end if;
end if;
when op_bi =>
add(effective_addr,
= cm_i then
end if;
end if;
when op_brq =>
add(effective_addr,
bits_to_int(PC), i8,
= cm_i then
end if;
when op_biq =>
add(effective_addr,
= cm_i then
end if;
when others =>
assert false report "illegal instruction" severity warning;
end case;
end if; -- reset /= '1'
end process;
end behaviour;
PHI1
PHI2
RESET
FETCH
READ
WRITE
A_BUS
D_BUS
READY
DP32
PHI1
PHI2
RESET
CLOCK_GEN
FETCH
READ
WRITE
A_BUS
D_BUS
READY
MEMORY
Figure7-10. Test bench circuit for DP32.
entity clock_gen is
generic (Tpw : Time; -- clock pulse width
Tps : Time); -- pulse separation between phases
port (phi1, phi2 : out bit;
reset : out bit);
end clock_gen;
architecture behaviour of clock_gen is
constant clock_period : Time := 2*(Tpw+Tps);
begi n
reset_driver :
reset <= '1', '0' after 2*clock_period+Tpw;
clock_driver : process
begi n
phi1 <= '1', '0' after Tpw;
phi2 <= '1' after Tpw+Tps, '0' after Tpw+Tps+Tpw;
wait for clock_period;
end process clock_driver;
end behaviour;
Figure7-11. Description of clock_gen driver.
7.5. Test Bench
One way of testi ng the behavi oural model of the DP32 processor i s to
connect i t i n a test bench ci rcui t, shown i n Fi gure7-10. The clock_gen
component generates the two-phase cl ock and the reset si gnal to dri ve the
processor. The memory stores a test program and data. We wri te
behavi our al model s for these two components, and connect them i n a
structural descri pti on of the test bench.
Fi gure7-11 l i sts the enti ty decl arati on and behavi oural archi tecture of
the cl ock generator. The clock_gen enti ty has two formal generi c constants.
Tpw i s the pul se wi dth for each of phi1 and phi2, that i s, the ti me for whi ch
each cl ock i s '1'. Tps i s the pul se separati on, that i s, the ti me between one
cl ock si gnal changi ng to '0' and the other cl ock si gnal changi ng to '1'.
Based on these val ues, the cl ock peri od i s twi ce the sum of the pul se wi dth
and the separ ati on.
The ar chi tectur e of the cl ock gener ator consi sts of two concur r ent
statements, one to dri ve the reset si gnal and the other to dri ve the cl ock
si gnal s. The reset dri ver schedul es a '1' val ue on reset when i t i s acti vated
at si mul ati on i ni ti al i sati on, fol l owed by a '0' a l i ttl e after two cl ock peri ods
l ater. Thi s concurrent statement i s never subsequentl y reacti vated, si nce
i ts waveform l i st does not refer to any si gnal s. The cl ock dri ver process,
when acti vated, schedul es a pul se on phi1 i mmedi atel y, fol l owed by a pul se
on phi2, and then suspends for a cl ock peri od. When i t resumes, i t repeats,
schedul i ng the next cl ock cycl e.
The enti ty decl arati on and behavi oural archi tecture of the memory
modul e are shown i n Fi gure7-12. The archi tecture body consi sts of one
pr ocess to i mpl ement the behavi our . The pr ocess contai ns an ar r ay
vari abl e to represent the storage of the memory. When the process i s
acti vated, i t pl aces the output ports i n an i ni ti al state: the data bus
di sconnected and the ready bi t negated. I t then wai ts for ei ther a read or
wr i te command. When one of these occur s, the addr ess i s sampl ed and
converted from a bi t-vector to a number. I f i t i s wi thi n the address bounds
of the memor y, the command i s acted upon.
For a wri te command, the ready bi t i s asserted after a del ay representi ng
the wri te access ti me of the memory, and then the model wai ts unti l the end
of the wri te cycl e. At that ti me, the val ue on the data bus from a
propagati on del ay beforehand i s sampl ed and wri tten i nto the memory
array. The use of thi s del ayed val ue model s the fact that memory devi ces
actual l y store the data that was val i d a setup-ti me before the tri ggeri ng edge
of the command bi t.
For a r ead command, the data fr om the memor y ar r ay i s accessed and
pl aced on the data bus after a del ay. Thi s del ay represents the read access
ti me of the memory. The ready bi t i s al so asserted after the del ay, i ndi cati ng
that the processor may conti nue. The memory then wai ts unti l the end of
the read cycl e.
At the end of a memory cycl e, the process repeats, setti ng the data bus
and ready bi t dri vers to thei r i ni ti al state, and wai ti ng for the next
command.
Fi gure7-13 shows the enti ty decl arati on and structural archi tecture of
the test bench ci rcui t. The enti ty contai ns no ports, si nce there are no
external connecti ons to the test bench. The archi tecture body contai ns
component decl ar ati ons for the cl ock dr i ver , the memor y and the pr ocessor .
The ports i n these component decl arati ons correspond exactl y to those of the
enti ty decl ar ati ons. Ther e ar e no for mal gener i c constants, so the actual s
for the generi cs i n the enti ty decl arati ons wi l l be speci fi ed i n a
confi gur ati on. The ar chi tectur e body next decl ar es the si gnal s whi ch ar e
used to connect the components together. These si gnal s may be traced by a
si mul ati on moni tor when the si mul ati on i s r un. The concur r ent
statements of the archi tecture body consi st of the three component
i nstances.
entity memory is
a_bus : in bit_32;
read, write : in bit;
ready : out bit);
end memory;
architecture behaviour of memory is
begi n
process
constant low_address : integer := 0;
constant high_address : integer := 65535;
type memory_array is
array (integer range low_address to high_address) of bit_32;
variable mem : memory_array;
variable address : integer;
begi n
--
-- put d_bus and reply into initial state
--
ready <= '0' after Tpd;
--
-- wait for a command
--
wait until (read = '1') or (write = '1');
--
-- dispatch read or write cycle
--
address := bits_to_int(a_bus);
if address >= low_address and address <= high_address then
-- address match for this memory
if write = '1' then
wait until write = '0'; -- wait until end of write cycle
mem(address) := d_bus'delayed(Tpd); -- sample data from Tpd ago
else -- read = '1'
d_bus <= mem(address) after Tpd; -- fetch data
wait until read = '0'; -- hold for read cycle
end if;
end if;
end process;
end behaviour;
Figure7-12. Description of memory module.
entity dp32_test is
end dp32_test;
architecture structure of dp32_test is
component clock_gen
port (phi1, phi2 : out bit;
reset : out bit);
end component;
component dp32
a_bus : out bit_32;
read, write : out bit;
fetch : out bit;
ready : in bit;
phi1, phi2 : in bit;
reset : in bit);
end component;
component memory
a_bus : in bit_32;
read, write : in bit;
ready : out bit);
end component;
signal d_bus : bus_bit_32 bus;
signal a_bus : bit_32;
signal read, write : bit;
signal fetch : bit;
signal ready : bit;
signal phi1, phi2 : bit;
signal reset : bit;
begi n
cg : clock_gen
port map (phi1 => phi1, phi2 => phi2, reset => reset);
proc : dp32
port map (d_bus => d_bus, a_bus => a_bus,
read => read, write => write, fetch => fetch,
ready => ready,
phi1 => phi1, phi2 => phi2, reset => reset);
mem : memory
port map (d_bus => d_bus, a_bus => a_bus,
read => read, write => write, ready => ready);
end structure;
Figure7-13. Description of test bench circuit.
configuration dp32_behaviour_test of dp32_test is
for structure
for cg : clock_gen
use entity work.clock_gen(behaviour)
generic map (Tpw => 8 ns, Tps => 2 ns);
end for;
for mem : memory
use entity work.memory(behaviour);
end for;
for proc : dp32
use entity work.dp32(behaviour);
end for;
end for;
end dp32_behaviour_test;
Figure7-14. Configuration of test bench using behaviour of DP32.
Lastl y, a confi gurati on for the test bench, usi ng the behavi oural
descri pti on of the DP32 processor, i s l i sted i n Fi gure7-14. The
confi gur ati on speci fi es that each of the components i n the str uctur e
archi tecture of the test bench shoul d use the behavi our archi tecture of the
cor r espondi ng enti ty. Actual gener i c constants ar e speci fi ed for the cl ock
generator, gi vi ng a cl ock peri od of 20ns. The defaul t val ues for the generi c
constants of the other enti ti es are used.
I n order to run the test bench model , a si mul ati on moni tor i s i nvoked
and a test program l oaded i nto the array vari abl e i n the memory model .
The author used the Zycad System VHDL
si mul ati on system for thi s

purpose. Fi gure7-15 i s an extract from the l i sti ng produced by an
assembl er created for the DP32 processor. The test program i ni ti al i zes R0
to zero (the assembl er macro initr0 generates an lmask i nstr ucti on), and
then l oops i ncr ementi ng a counter i n memor y. The val ues i n par entheses
ar e the i nstr ucti on addr esses, and the hexadeci mal val ues i n squar e
br ackets ar e the assembl ed i nstr ucti ons.
Zycad System VHDL i s a tr ademar k of Zycad Cor por ati on.

1. include dp32.inc $
2.
3. !!! conventions:
4. !!! r0 = 0
5. !!! r1 scratch
6.
7. begin
8. ( 0) [07000000 ] initr0
9. start:
10. ( 1) [10020000 ] addq(r2, r0, 0) ! r2 := 0
11. loop:
12. ( 2) [21020000 00000008] sta(r2, counter) ! counter := r2
13. ( 4) [10020201 ] addq(r2, r2, 1) ! increment r2
14. ( 5) [1101020A ] subq(r1, r2, 10) ! if r2 = 10 then
15. ( 6) [500900FA ] brzq(start) ! restart
16. ( 7) [500000FA ] braq(loop) ! else next loop
17.
18. counter:
19. ( 8) [00000000 ] data(0)
20. end
Figure7-15. Assembler listing of a test program.
Control
Addr
Op1 Bus
R Bus
Op2 Bus
A Bus
D Bus
Bus Command
Bus Reply
CC
op r3 r1 r2
CC
comp
A2
A1
A3
Register
File
Q1 Q2 D3
A1 A2 A3
A1 A2 A3
Res
PC
Disp
Figure7-16. DP32 data paths block diagram.
7.6. Register Transfer Architecture
The previ ous descri pti ons of the DP32 speci fi ed i ts behavi our wi thout
reference to the i nternal structure of the processor. Such a descri pti on i s
i nval uabl e, as i t al l ows the computer archi tect to eval uate the i nstructi on
set and compar e i t wi th al ter nati ves befor e commi ti ng expensi ve r esour ces
to detai l ed desi gn and i mpl ementati on.
Once thi s abstract archi tecture has been settl ed on, the next l evel of
archi tecture can be desi gned. Fi gure7-16 i s a bl ock di agram of a si mpl e
archi tecture to i mpl ement the DP32 i nstrcucti on set. (Most control si gnal s
are not shown.) I t consi sts mai nl y of a col l ecti on of regi sters and an
ari thmeti c and l ogi c uni t (ALU), connected by a number of buses. There
ar e al so buffer s for i nter faci ng to the pr ocessor -memor y bus, and a contr ol
uni t for sequenci ng oper ati on of the pr ocessor .
The softwar e addr essabl e r egi ster s ar e i mpl emented usi ng a thr ee-por t
regi ster fi l e. Ports1 and2 suppl y source operands onto the op1 and op2
buses respecti vel y. The address for port2 i s normal l y taken from the r2
fi el d of the current i nstructi on, but a mul ti pl exor i s i ncl uded to al l ow the r3
fi el d to be used when a store i nstructi on i s executed. The op1 and op2 buses
entity mux2 is
generic (width : positive;
Tpd : Time := unit_delay);
port (i0, i1 : in bit_vector(width-1 downto 0);
y : out bit_vector(width-1 downto 0);
sel : in bit);
end mux2;
architecture behaviour of mux2 is
begi n
with sel select
y <= i0 after Tpd when '0',
i1 after Tpd when '1';
end behaviour;
Figure7-17. Description of 2-input multiplexor.
are connected to the ALU i nputs, and the ALU output dri ves the resul t bus.
The resul t can be l atched for wri ti ng back to the regi ster fi l e usi ng port3.
The program counter (PC) regi ster al so suppl i es the op1 bus, and can be
l oaded from the resul t bus. The ALU condi ti on fl ags are l atched i nto the
condi ti on code (CC) regi ster, and from there can be compared wi th the
condi ti on mask fr om the cur r ent i nstr ucti on. The memor y bus i nter face
i ncl udes an address l atch to dri ve the address bus, a data output buffer
dri ven from the op2 bus, a data i nput buffer dri vi ng the resul t bus, and a
di spl acement l atch dr i vi ng the op2 bus. An i nstr ucti on fetched fr om
memory i s stored i n current i nstructi on regi ster. The r1, r2 and r3 fi el ds
are used as regi ster fi l e addresses. The r2 fi el d i s al so used as an
i mmedi ate constant and may be si gn extended onto the op2 bus. Four bi ts
from the r3 fi el d are used as the condi ti on mask, and the opcode fi el d i s
used by the control uni t.
I n thi s secti on, descri pti ons wi l l be gi ven for each of the sub-modul es i n
thi s archi tecture, and then they wi l l be used i n a structural archi tecture
body of the DP32 enti ty.
7.6.1. Multiplexor
An enti ty decl arati on and archi tecture body for a 2-i nput mul ti pl exor i s
l i sted i n Fi gure7-17. The enti ty has a sel ect i nput bi t, two bi t-vector i nputs
i0 and i1, and a bi t-vector output y. The si ze of the bi t-vector ports i s
determi ned by the generi c constant width, whi ch must be speci fi ed when the
enti ty i s used i n a structural descri pti on. The archi tecture body contai ns a
concur r ent sel ected si gnal assi gnment, whi ch uses the val ue of the sel ect
i nput to determi ne whi ch of the two bi t-vector i nputs i s passed through to
the output. The assi gnment i s sensi ti ve to al l of the i nput si gnal s, so when
any of them changes, the assi gnment wi l l be r esumed.
7.6.2. Transparent Latch
An enti ty decl arati on and archi tecture body for a l atch i s l i sted i n
Fi gure7-18. The enti ty has an enabl e i nput bi t, a bi t-vector i nput d, and a
bi t-vector output q. The si ze of the bi t-vector ports i s determi ned by the
gener i c constant width, whi ch must be speci fi ed when the enti ty i s used i n a
str uctur al descr i pti on. The ar chi tectur e body contai ns a pr ocess whi ch i s
entity latch is
generic (width : positive;
Tpd : Time := unit_delay);
port (d : in bit_vector(width-1 downto 0);
q : out bit_vector(width-1 downto 0);
en : in bit);
end latch;
architecture behaviour of latch is
begi n
process (d, en)
begi n
if en = '1' then
q <= d after Tpd;
end if;
end process;
end behaviour;
Figure7-18. Description of a transparent latch.
sensi ti ve to the d and en i nputs. The behavi our of the l atch i s such that
when en i s '1', changes on d ar e tr ansmi tted thr ough to q. However , when
en changes to '0', any new val ue on d i s i gnored, and the current val ue on q
i s mai ntai ned. I n the model shown i n Fi gure7-18, the l atch storage i s
provi ded by the output port, i n that i f no new val ue i s assi gned to i t, the
cur r ent val ue does not change.
7.6.3. Buffer
An enti ty decl arati on and archi tecture body for a buffer i s l i sted i n
Fi gure7-19. The enti ty has an enabl e i nput bi t en, a bi t-vector i nput a, and a
resol ved bi t-vector bus output b. I t i s not possi bl e to make thi s enti ty generi c
wi th respect to i nput and output port wi dth, because of a l i mi tati on i mposed
by the VHDL l anguage semanti cs. The output port needs to be a resol ved
si gnal , so a bus resol uti on functi on i s speci fi ed i n the defi ni ti on of the port
type. Thi s functi on takes a par ameter whi ch i s an unconstr ai ned ar r ay.
I n order to make the buffer port wi dth generi c, we woul d need to speci fy a
bus r esol uti on functi on whi ch took as a par ameter an unconstr ai ned ar r ay
of bi t-vector el ements whose l ength i s not known. VHDL does not al l ow the
el ement type of an unconstrai ned array to be an unconstrai ned array, so
thi s approach i s not possi bl e. For thi s reason, we defi ne a buffer enti ty wi th
fi xed port wi dths of 32bi ts.
The behavi our of the buffer i s i mpl emented by a process sensi ti ve to the
en and a i nputs. I f en i s '1', the a i nput i s transmi tted through to the b
output. I f en i s '0', the dri ver for b i s di sconnected, and the val ue on a i s
i gnor ed.
entity buffer_32 is
port (a : in bit_32;
b : out bus_bit_32 bus;
en : in bit);
end buffer_32;
architecture behaviour of buffer_32 is
begi n
b_driver: process (en, a)
begi n
if en = '1' then
b <= a after Tpd;
el se
b <= null after Tpd;
end if;
end process b_driver;
end behaviour;
Figure7-19. Description of a buffer.
entity signext_8_32 is
port (a : in bit_8;
en : in bit);
end signext_8_32;
architecture behaviour of signext_8_32 is
begi n
b_driver: process (en, a)
begi n
if en = '1' then
b(7 downto 0) <= a after Tpd;
if a(7) = '1' then
b(31 downto 8) <= X"FFFF_FF" after Tpd;
el se
b(31 downto 8) <= X"0000_00" after Tpd;
end if;
el se
b <= null after Tpd;
end if;
end process b_driver;
end behaviour;
Figure7-20. Description of the sign extending buffer.
entity latch_buffer_32 is
port (d : in bit_32;
q : out bus_bit_32 bus;
latch_en : in bit;
out_en : in bit);
end latch_buffer_32;
architecture behaviour of latch_buffer_32 is
begi n
process (d, latch_en, out_en)
variable latched_value : bit_32;
begi n
if latch_en = '1' then
latched_value := d;
end if;
if out_en = '1' then
q <= latched_value after Tpd;
el se
q <= null after Tpd;
end if;
end process;
end behaviour;
Figure7-21. Description of a latching buffer.
7.6.4. Sign Extending Buffer
The si gn-extendi ng buffer shown i n Fi gure7-20 i s al most i denti cal to the
pl ai n buffer, except that i t has an 8-bi t i nput. Thi s i nput i s treated as a
twos-compl ement si gned i nteger, and the output i s the same i nteger, but
extended to 32bi ts. The extensi on i s achi eved by repl i cati ng the si gn bi t i nto
bi ts8 to31 of the output.
7.6.5. Latching Buffer
Fi gure7-21 l i sts an enti ty decl arati on an archi tecture body for a l atchi ng
buffer. Thi s model i s a combi nati on of those for the pl ai n l atch and buffer.
When latch_en i s '1', changes on d are stored i n the l atch, and may be
tr ansmi tted thr ough to q. However, when latch_en changes to '0', any new
val ue on d i s i gnored, and the currentl y stored val ue i s mai ntai ned. The
out_en i nput control s whether the stored val ue i s tranmi tted to the output.
Unl i ke the pl ai n l atch, expl i ci t storage must be provi ded (i n the form of the
vari abl e latched_value), si nce the output dri ver may be di sconnected when a
new val ue i s to be stored.
7.6.6. Program Counter Register
The enti ty decl arati on and archi tecture body of the PC regi ster are l i sted
i n Fi gure7-22. The PC regi ster i s a master/sl ave type regi ster, whi ch can
be reset to al l zeros by asserti ng the reset i nput. When reset i s negated, the
l atch operates normal l y. Wi th latch_en at '1', the val ue of the d i nput i s
stored i n the vari abl e master_PC, but the output (i f enabl ed) i s dri ven from
the previ ousl y stored val ue i n slave_PC. Then when latch_en changes fr om
entity PC_reg is
latch_en : in bit;
out_en : in bit;
reset : in bit);
end PC_reg;
architecture behaviour of PC_reg is
begi n
process (d, latch_en, out_en, reset)
variable master_PC, slave_PC : bit_32;
begi n
if reset = '1' then
slave_PC := X"0000_0000";
elsif latch_en = '1' then
master_PC := d;
el se
slave_PC := master_PC;
end if;
if out_en = '1' then
q <= slave_PC after Tpd;
el se
q <= null after Tpd;
end if;
end process;
end behaviour;
Figure7-22. Description of the PC register.
'1' to '0', the sl ave val ue i s update from the master val ue, and any
subsequent changes i n the d i nput are i gnored. Thi s behavi our means that
the PC regi ster output can be used to deri ve a new val ue, and the new val ue
wri tten back at the same ti me. I f an ordi nary transparent l atch were used,
a race condi ti on woul d be created, si nce the new val ue woul d be transmi tted
through to the output i n pl ace of the ol d val ue, affecti ng the cal cul ati on of
the new val ue.
7.6.7. Register File
Fi gure7-23 l i sts the descri pti on of the 3-port regi ster fi l e, wi th two read
ports and one wri te port. Each port has an address i nput (a1, a2 and a3)
and an enabl e i nput (en1, en2 and en3). The read ports have data bus
outputs (q1 and q2), and the wri te port has a data i nput (d3). The number
bi ts i n the port addresses i s determi ned by the generi c constant depth. The
behavi our of the enti ty i s i mpl emented by the process reg_file. I t decl ares a
numeri c type used to i ndex the regi ster fi l e, and an array for the regi ster
fi l e storage. When any of the i nputs change, fi rstl y the wri te port enabl e i s
checked, and i f asserted, the addressed regi ster i s updated. Then each of
the read port enabl es i s checked. I f asserted, the addressed data i s fetched
and dri ven onto the correspondi ng data output bus. I f the port i s di sabl ed,
the data output bus dri ver i s di sconnected.
entity reg_file_32_rrw is
generic (depth : positive; -- number of address bits
Tpd : Time := unit_delay;
Tac : Time := unit_delay);
port (a1 : in bit_vector(depth-1 downto 0);
q1 : out bus_bit_32 bus;
en1 : in bit;
a2 : in bit_vector(depth-1 downto 0);
en2 : in bit;
d3 : in bit_32;
en3 : in bit);
end reg_file_32_rrw;
architecture behaviour of reg_file_32_rrw is
begi n
reg_file: process (a1, en1, a2, en2, a3, d3, en3)
subtype reg_addr is natural range 0 to depth-1;
type register_array is array (reg_addr) of bit_32;
variable registers : register_array;
begi n
if en3 = '1' then
registers(bits_to_natural(a3)) := d3;
end if;
if en1 = '1' then
q1 <= registers(bits_to_natural(a1)) after Tac;
el se
q1 <= null after Tpd;
end if;
if en2 = '1' then
q2 <= registers(bits_to_natural(a2)) after Tac;
el se
q2 <= null after Tpd;
end if;
end process reg_file;
end behaviour;
Figure7-23. Description of the 3-port register file.
7.6.8. Arithmetic & Logic Unit
The descri pti on of the ALU i s l i sted i n Fi gure7-24. The package
ALU_32_types defi nes an enumerated type for speci fyi ng the ALU functi on.
Thi s must be pl aced i n a package, si nce i t i s requi red for both the ALU
descri pti on and for enti ti es that make use of the ALU. There i s no
correspondi ng package body, si nce the type i s ful l y defi ned i n the package
speci fi cati on.
The ALU enti ty decl arati on uses the ALU_32_types package as wel l as the
general dp32_types package. I t has two operand i nput ports, a resul t output
and condi ti on code output ports, and a command i nput port. Thi s l ast port
i s an exampl e of a port whi ch i s of an enumerated type, si nce at thi s stage
package ALU_32_types is
type ALU_command is (disable, pass1, incr1,
add, subtract, multiply, divide,
log_and, log_or, log_xor, log_mask);
end ALU_32_types;
use work.dp32_types.all, work.ALU_32_types.all;
entity ALU_32 is
port (operand1 : in bit_32;
operand2 : in bit_32;
result : out bus_bit_32 bus;
cond_code : out CC_bits;
command : in ALU_command);
end ALU_32;
Figure7-24. Description of the Arithmetic and Logic Unit.
of desi gn, no encodi ng i s known or speci fi ed for the ALU functi on
command.
The ALU behavi our i s i mpl emented by the process ALU_function, sensi ti ve
to changes on the operand and command i nput ports. I f the command to be
performed i s an ari thmeti c operati on, the model fi rstl y converts the
operands to i ntegers. Thi s i s fol l owed by a case statement di spatchi ng on
the command. For the disable command, no oper ati on i s per for med, and for
the pass1 command, the resul t i s operand1 unchanged. The r esul t for l ogi c
commands i s der i ved by appl yi ng the cor r espondi ng VHDL l ogi cal
operati ons to the bi t-vector operands. For ari thmeti c commands the resul t
i s computed the same was as i t was i n the behavi oural model of the DP32
presented i n Secti on7.4. Al so, the overfl ow condi ti on code bi t (cc_V), whi ch
i s onl y defi ned for ar i thmeti c oper ati ons, i s assi gned her e. Fi nal l y, the
resul t and remai ni ng condi ti on code bi ts are assi gned. The resul t output i s
onl y dri ven i f the command i s not disable, other wi se i t i s di sconnected.
architecture behaviour of ALU_32 is
alias cc_V : bit is cond_code(2);
alias cc_N : bit is cond_code(1);
alias cc_Z : bit is cond_code(0);
begi n
ALU_function: process (operand1, operand2, command)
variable a, b : integer;
variable temp_result : bit_32;
begi n
case command is
when add | subtract | multiply | divide =>
a := bits_to_int(operand1);
b := bits_to_int(operand2);
when incr1 =>
a := bits_to_int(operand1);
b := 1;
when others =>
null;
end case;
case command is
when disable =>
null;
when pass1 =>
temp_result := operand1;
when log_and =>
temp_result := operand1 and operand2;
when log_or =>
temp_result := operand1 or operand2;
when log_xor =>
temp_result := operand1 xor operand2;
when log_mask =>
temp_result := operand1 and not operand2;
when add | incr1 =>
if b > 0 and a > integer'high-b then -- positive overflow
int_to_bits(((integer'low+a)+b)-integer'high-1, temp_result);
cc_V <= '1' after Tpd;
elsif b < 0 and a < integer'low-b then -- negative overflow
int_to_bits(((integer'high+a)+b)-integer'low+1, temp_result);
el se
int_to_bits(a + b, temp_result);
end if;
when subtract =>
if b < 0 and a > integer'high+b then -- positive overflow
int_to_bits(((integer'low+a)-b)-integer'high-1, temp_result);
elsif b > 0 and a < integer'low+b then -- negative overflow
int_to_bits(((integer'high+a)-b)-integer'low+1, temp_result);
el se
int_to_bits(a - b, temp_result);
end if;
when multiply =>
if ((a>0 and b>0) or (a<0 and b<0)) -- result positive
and (abs a > integer'high / abs b) then
-- positive overflow
int_to_bits(integer'high, temp_result);
elsif ((a>0 and b<0) or (a<0 and b>0)) -- result negative
and ((- abs a) < integer'low / abs b) then
-- negative overflow
int_to_bits(integer'low, temp_result);
el se
int_to_bits(a * b, temp_result);
end if;
when divide =>
if b=0 then
if a>=0 then -- positive overflow
int_to_bits(integer'high, temp_result);
el se
int_to_bits(integer'low, temp_result);
end if;
el se
int_to_bits(a / b, temp_result);
end if;
end case;
if command /= disable then
result <= temp_result after Tpd;
el se
result <= null after Tpd;
end if;
cc_Z <= bool_to_bit(temp_result = X"00000000") after Tpd;
cc_N <= bool_to_bit(temp_result(31) = '1') after Tpd;
end process ALU_function;
end behaviour;
entity cond_code_comparator is
port (cc : in CC_bits;
cm : in cm_bits;
result : out bit);
end cond_code_comparator;
architecture behaviour of cond_code_comparator is
alias cc_V : bit is cc(2);
alias cc_N : bit is cc(1);
alias cc_Z : bit is cc(0);
alias cm_i : bit is cm(3);
alias cm_V : bit is cm(2);
alias cm_N : bit is cm(1);
alias cm_Z : bit is cm(0);
begi n
result <= bool_to_bit(((cm_V and cc_V)
or (cm_N and cc_N)
or (cm_Z and cc_Z)) = cm_i) after Tpd;
end behaviour;
Figure7-25. Description of the condition code comparator.
7.6.9. Condition Code Comparator
The descri pti on of the condi ti on code comparator i s l i sted i n Fi gure7-25.
The cc i nput port contai ns the three condi ti on code bi ts V, N and Z, and the
cm i nput contai ns the four condi ti on mask bi ts deri ved from a DP32
i nstructi on. Al i ases for each of these bi ts are decl ared i n the archi tecture
body. The behavi our i s i mpl emented by a si ngl e concurrent si gnal
assi gnment statement, whi ch i s sensi ti ve to al l of the i nput bi ts. Whenever
any of the bi ts changes val ue, the assi gnment wi l l be resumed and a new
resul t bi t computed.
7.6.10. Structural Architecture of the DP32
I n thi s secti on, a structural archi tecture body for the DP32 processor,
correspondi ng to Fi gure7-16, wi l l be descri bed. See Fi gure7-26 for a l i sti ng
of the archi tecture body.
use work.dp32_types.all, work.ALU_32_types.all;
architecture RTL of dp32 is
component reg_file_32_rrw
generic (depth : positive);
port (a1 : in bit_vector(depth-1 downto 0);
en1 : in bit;
en2 : in bit;
d3 : in bit_32;
en3 : in bit);
end component;
component mux2
port (i0, i1 : in bit_vector(width-1 downto 0);
y : out bit_vector(width-1 downto 0);
sel : in bit);
end component;
component PC_reg
latch_en : in bit;
out_en : in bit;
reset : in bit);
end component;
component ALU_32
port (operand1 : in bit_32;
operand2 : in bit_32;
result : out bus_bit_32 bus;
cond_code : out CC_bits;
command : in ALU_command);
end component;
component cond_code_comparator
port (cc : in CC_bits;
cm : in cm_bits;
result : out bit);
end component;
component buffer_32
port (a : in bit_32;
en : in bit);
end component;
component latch
port (d : in bit_vector(width-1 downto 0);
q : out bit_vector(width-1 downto 0);
en : in bit);
end component;
Figure7-26. Structural description of the DP32 processor.
component latch_buffer_32
latch_en : in bit;
out_en : in bit);
end component;
component signext_8_32
port (a : in bit_8;
en : in bit);
end component;
signal op1_bus : bus_bit_32;
signal op2_bus : bus_bit_32;
signal r_bus : bus_bit_32;
signal ALU_CC : CC_bits;
signal CC : CC_bits;
signal current_instr : bit_32;
alias instr_a1 : bit_8 is current_instr(15 downto 8);
alias instr_op : bit_8 is current_instr(31 downto 24);
alias instr_cm : cm_bits is current_instr(19 downto 16);
signal reg_a2 : bit_8;
signal reg_result : bit_32;
signal addr_latch_en : bit;
signal disp_latch_en : bit;
signal disp_out_en : bit;
signal d2_en : bit;
signal dr_en : bit;
signal instr_latch_en : bit;
signal immed_signext_en : bit;
signal ALU_op : ALU_command;
signal CC_latch_en : bit;
signal CC_comp_result : bit;
signal PC_latch_en : bit;
signal PC_out_en : bit;
signal reg_port1_en : bit;
signal reg_port2_mux_sel : bit;
signal reg_res_latch_en : bit;
begin -- architecture RTL of dp32
reg_file : reg_file_32_RRW
generic map (depth => 8)
port map (a1 => instr_a1, q1 => op1_bus, en1 => reg_port1_en,
a2 => reg_a2, q2 => op2_bus, en2 => reg_port2_en,
a3 => instr_a3, d3 => reg_result, en3 => reg_port3_en);
reg_port2_mux : mux2
port map (i0 => instr_a2, i1 => instr_a3, y => reg_a2,
sel => reg_port2_mux_sel);
reg_res_latch : latch
port map (d => r_bus, q => reg_result, en => reg_res_latch_en);
PC : PC_reg
port map (d => r_bus, q => op1_bus,
latch_en => PC_latch_en, out_en => PC_out_en,
reset => reset);
ALU : ALU_32
port map (operand1 => op1_bus, operand2 => op2_bus,
result => r_bus, cond_code => ALU_CC,
command => ALU_op);
CC_reg : latch
port map (d => ALU_CC, q => CC, en => CC_latch_en);
CC_comp : cond_code_comparator
port map (cc => CC, cm => instr_cm, result => CC_comp_result);
dr_buffer : buffer_32
port map (a => d_bus, b => r_bus, en => dr_en);
d2_buffer : buffer_32
port map (a => op2_bus, b => d_bus, en => d2_en);
disp_latch : latch_buffer_32
port map (d => d_bus, q => op2_bus,
latch_en => disp_latch_en, out_en => disp_out_en);
addr_latch : latch
port map (d => r_bus, q => a_bus, en => addr_latch_en);
instr_latch : latch
port map (d => r_bus, q => current_instr, en => instr_latch_en);
immed_signext : signext_8_32
port map (a => instr_a2, b => op2_bus, en => immed_signext_en);
The archi tecture refers to the i tems decl ared i n the packages dp32_types
and ALU_32_types, so a use cl ause for these packages i s i ncl uded. The
decl ar ati on secti on of the ar chi tectur e contai ns a number of component
decl arati ons, correspondi ng to the enti ty decl arati ons l i sted i n Secti ons7.6.1
to7.6.9. I nstances of these components are subsequentl y used to construct
the pr ocessor ar chi tectur e.
Next, a number of si gnal s ar e decl ar ed, cor r espondi ng to the buses
i l l ustrated i n Fi gure7-16. These are fol l owed by further si gnal decl arati ons
for control si gnal s not shown i n the fi gure. The control si gnal s are used to
connect the data path component i nstances wi th the control uni t
i mpl emented i n the bl ock cal l ed controller.
controller : block
port (phi1, phi2 : in bit;
reset : in bit;
opcode : in bit_8;
read, write, fetch : out bit;
ready : in bit;
addr_latch_en : out bit;
disp_latch_en : out bit;
disp_out_en : out bit;
d2_en : out bit;
dr_en : out bit;
instr_latch_en : out bit;
immed_signext_en : out bit;
ALU_op : out ALU_command;
CC_latch_en : out bit;
CC_comp_result : in bit;
PC_latch_en : out bit;
PC_out_en : out bit;
reg_port1_en : out bit;
reg_port2_mux_sel : out bit;
reg_res_latch_en : out bit);
port map (phi1 => phi1, phi2 => phi2,
reset => reset,
opcode => instr_op,
read => read, write => write, fetch => fetch,
ready => ready,
addr_latch_en => addr_latch_en,
disp_latch_en => disp_latch_en,
disp_out_en => disp_out_en,
d2_en => d2_en,
dr_en => dr_en,
instr_latch_en => instr_latch_en,
immed_signext_en => immed_signext_en,
ALU_op => ALU_op,
CC_latch_en => CC_latch_en,
CC_comp_result => CC_comp_result,
PC_latch_en => PC_latch_en, PC_out_en => PC_out_en,
reg_port1_en => reg_port1_en,
reg_port2_mux_sel => reg_port2_mux_sel,
reg_res_latch_en => reg_res_latch_en);
begi n -- block controller
state_machine: process
type controller_state is
(resetting, fetch_0, fetch_1, fetch_2, decode,
disp_fetch_0, disp_fetch_1, disp_fetch_2,
execute_0, execute_1, execute_2);
variable state, next_state : controller_state;
variable write_back_pending : boolean;
type ALU_op_select_table is
array (natural range 0 to 255) of ALU_command;
constant ALU_op_select : ALU_op_select_table :=
(16#00# => add,
16#01# => subtract,
16#02# => multiply,
16#03# => divide,
16#10# => add,
16#11# => subtract,
16#12# => multiply,
16#13# => divide,
16#04# => log_and,
16#05# => log_or,
16#06# => log_xor,
16#07# => log_mask,
others => disable);
The control uni t i s a state machi ne, whose behavi our i s descri bed by a
si ngl e pr ocess cal l ed state_machine. The contr ol l er sequences thr ough the
states l i sted i n the decl arati on of the type controller_state to fetch, decode and
execute i nstructi ons. The vari abl e state hol ds the control l er state for the
current cl ock cycl e, and next_state i s set to determi ne the state for the next
cl ock cycl e. Write_back_pending i s a fl ag used to schedul e a regi ster wri te
operati on for the next cl ock cycl e. The constant ALU_op_select i s a l ookup
tabl e used to determi ne the ALU functi on from the i nstructi on op-code.
begi n -- process state_machine
--
-- start of clock cycle
--
--
-- check for reset
--
if reset = '1' then
state := resetting;
--
-- reset external bus signals
--
--
-- reset dp32 internal control signals
--
addr_latch_en <= '0' after Tpd;
disp_latch_en <= '0' after Tpd;
disp_out_en <= '0' after Tpd;
d2_en <= '0' after Tpd;
dr_en <= '0' after Tpd;
instr_latch_en <= '0' after Tpd;
immed_signext_en <= '0' after Tpd;
ALU_op <= disable after Tpd;
CC_latch_en <= '0' after Tpd;
PC_latch_en <= '0' after Tpd;
PC_out_en <= '0' after Tpd;
reg_port1_en <= '0' after Tpd;
reg_port2_mux_sel <= '0' after Tpd;
reg_res_latch_en <= '0' after Tpd;
--
-- clear write-back flag
--
write_back_pending := false;
--
else -- reset = '0'
state := next_state;
end if;
The body of the state machi ne process starts by wai ti ng for the l eadi ng
edge of the phi1 cl ock, i ndi cati ng the start of a cl ock cycl e. When thi s
occurs, the reset si gnal i s checked, and i f i t i s asserted the control l er state i s
set to resetting and al l control outputs are negated. On the other hand, i f
reset i s negated, the control l er state i s updated to the previ ousl y computed
next state.
--
-- dispatch action for current state
--
case state is
when resetting =>
--
-- check for reset going inactive at end of clock cycle
--
if reset = '0' then
next_state := fetch_0;
el se
next_state := resetting;
end if;
--
when fetch_0 =>
--
-- clean up after previous execute cycles
--
dr_en <= '0' after Tpd;
d2_en <= '0' after Tpd;
--
-- handle pending register write-back
--
if write_back_pending then
end if;
--
-- enable PC via ALU to address latch
--
PC_out_en <= '1' after Tpd; -- enable PC onto op1_bus
ALU_op <= pass1 after Tpd; -- pass PC to r_bus
--
addr_latch_en <= '1' after Tpd; -- latch instr address
--
--
The remai nder of the state machi ne body i s a case statement usi ng the
current state to determi ne the acti on to be performed for thi s cl ock cycl e. I f
the processor i s bei ng reset (i n the resetting state), i t wai ts unti l the trai l i ng
edge of phi2 at the end of the cl ock cycl e, and checks the reset si gnal agai n.
I f reset has been negated, the processor can start fetchi ng i nstructi ons, so
the next state i s set to fetch_0, otherwi se i t i s i s set to resetting agai n.
when fetch_1 =>
--
-- clear pending register write-back
--
if write_back_pending then
write_back_pending := false;
end if;
--
-- increment PC & start bus read
--
ALU_op <= incr1 after Tpd; -- increment PC onto r_bus
--
PC_latch_en <= '1' after Tpd; -- latch incremented PC
--
--
when fetch_2 =>
--
-- cleanup after previous fetch_1
--
PC_out_en <= '0' after Tpd; -- disable PC from op1_bus
ALU_op <= disable after Tpd; -- disable ALU from r_bus
--
-- latch current instruction
--
dr_en <= '1' after Tpd; -- enable fetched instr onto r_bus
--
instr_latch_en <= '1' after Tpd; -- latch fetched instr from r_bus
instr_latch_en <= '0' after Tpd;
--
if ready = '1' then
next_state := decode;
el se
next_state := fetch_2; -- extend bus read
end if;
The pr ocessor fetches an i nstr ucti on fr om memor y by sequenci ng
through the states fetch_0, fetch_1 and fetch_2 on successi ve cl ock cycl es.
Fi gur e7-27 shows the ti mi ng of contr ol si gnal s for an i nstr ucti on fetch.
The fetch_0 processor cycl e corresponds to a Ti cycl e on the memory bus.
Duri ng thi s cycl e, the PC regi ster output i s enabl ed onto the op1 bus, and
the ALU functi on set to pass1. The ALU passes the PC val ue through to the
resul t bus, and i t i s l atched i nto the memory address regi ster duri ng the
second hal f of the cycl e. The PC val ue i s thus set up on the memory address
bus. The fetch_1 cycl e corresponds to a memory bus T1 cycl e. The control l er
starts the memory transacti on by asserti ng fetch and read. At the same
ti me, i t changes the ALU functi on code to incr1, causi ng the ALU to pl ace
phi1
phi2
valid address
a_bus
fetch
d_bus
ready
valid data in
fetch_0 fetch_1 fetch_2 decode
PC_out_en
addr_latch_en
PC_latch_en
ALU_op
pass1 incr1 disable
read
dr_en
instr_latch_en
Figure7-27. Timing for DP32 instruction fetch.
the i ncremented PC val ue on the resul t bus. Thi s i s then l atched back i nto
the PC regi ster duri ng the second hal f of the cycl e. The fetch_2 pr ocessor
cycl e cor r esponds to the memor y bus T2 cycl e, dur i ng whi ch data i s
returned to the processor from the memory. The control l er di sabl es the PC
from the op1 bus and the ALU from the resul t bus, and enabl es the data
i nput buffer to accept memory data onto the resul t bus. Thi s data i s l atched
i nto the current i nstructi on regi ster duri ng the second hal f of the cycl e. I f
ready i s fal se, the processor repeats the F2 cycl e, otherwi se i t compl etes the
bus transacti on and moves to the decode state, correspondi ng to a bus Ti
cycl e.
Returni ng to the VHDL descri pti on, we see that the fetch_0 branch of the
case statement i mpl ements the fi rst cycl e of an i nstructi on fetch. Fi rstl y,
any si gnal s l eft asserted from previ ous cycl e are negated agai n. Next, any
r egi ster wr i te schedul ed fr om the pr evi ousl y executed i nstr ucti on i s
when decode =>
--
-- terminate bus read from previous fetch_2
--
dr_en <= '0' after Tpd; -- disable fetched instr from r_bus
--
-- delay to allow decode logic to settle
--
--
-- next state based on opcode of currect instruction
--
case opcode is
when op_add | op_sub | op_mul | op_div
| op_addq | op_subq | op_mulq | op_divq
| op_land | op_lor | op_lxor | op_lmask
| op_ldq | op_stq =>
next_state := execute_0;
when op_ld | op_st =>
next_state := disp_fetch_0; -- fetch offset
when op_br | op_bi =>
if CC_comp_result = '1' then -- if branch taken
next_state := disp_fetch_0; -- fetch displacement
el se -- else
next_state := execute_0; -- increment PC
-- past displacement
end if;
when op_brq | op_biq =>
if CC_comp_result = '1' then -- if branch taken
next_state := execute_0; -- add immed
-- displacement to PC
el se -- else
next_state := fetch_0; -- no action needed
end if;
when others =>
assert false report "illegal instruction" severity warning;
next_state := fetch_0; -- ignore and carry on
end case; -- op
--
handl ed. (Thi s wi l l be descri bed ful l y bel ow.) Then the PC regi ster output
i s enabl ed and the ALU functi on set, as descri bed above. The process then
wai ts unti l the l eadi ng edge of phi2, by whi ch ti me the PC shoul d be val i d on
the resul t bus. I t pul ses the address l atch enabl e si gnal by asserti ng i t,
wai ti ng unti l the trai l i ng edge of phi2, then negati ng the si gnal . Fi nal l y,
the next state vari abl e i s set to fetch_1, so that when the process resumes i n
the next cycl e, i t wi l l move to thi s state.
When the process i s i n state fetch_1, i t starts the cycl e by termi nati ng any
regi ster wri te back that may have been pendi ng. I t then changes the ALU
functi on code to i ncrement the PC val ue, and starts the bus transacti on. I n
the second hal f of the cycl e, when phi2 i s asserted, the PC l atch enabl e i s
asserted to store the i ncremented PC val ue. The next state i s then set to
fetch_2.
The l ast cycl e of the i nstructi on fetch i s state fetch_2. The control l er
di sabl es the PC regi ster and ALU outputs, and enabl es the buffer between
the memory data bus and the resul t bus. Duri ng the second hal f of the
cycl e, i t asserts the i nstructi on regi ster l atch enabl e. At the end of the
cycl e, when phi2 has returned to '0', the ready i nput i s checked. I f i t i s
asserted, the state machi ne can conti nue to the decode state i n the next
cycl e, otherwi se the fetch_2 state must be repeated.
I n the decode state, the control l er termi nates the previ ous bus
transacti on and di sabl es the bus i nput buffer. I t then del ays for the rest of
the cycl e, model i ng the ti me requi red for decode l ogi c to anal yse the current
i nstructi on and for the condi ti on code comparator to stabi l i ze. The op-code
part of the i nstructi on i s then exami ned to determi ne the next state. For
ar i thmeti c, l ogi cal and qui ck l oad/stor e i nstr ucti ons, the next state i s
execute_0, i n whi ch the i nstructi on i s i nterpreted. For l oad/store
i nstr ucti ons wi th a l ong di spl acement, a bus tr ansacti on must be
performed to read the di spl acement, so the next state i s disp_fetch_0. For
br anch i nstr ucti ons wi th a l ong di spl acement, the fetch i s onl y r equi r ed i f
the branch i s to be taken, i n whi ch case the next state i s disp_fetch_0.
Otherwi se the next state i s execute_0, i n whi ch the PC wi l l be i ncremented
past the di spl acement stor ed i n memor y. For br anch qui ck i nstr ucti ons,
the di spl acement i s encoded i n the i nstructi on. I f the branch i s taken, the
next state i s execute_0 to update the PC. Otherwi se no further acti on i s
needed to i nterpret the i nstructi on, so the next state i s fetch_0. I f any other
op-code i s detected, an asserti on i s used to report the i l l egal i nstructi on.
The i nstr ucti on i s i gnor ed and executi on conti nues wi th the next
i nstructi on, so the next state i s fetch_0.
when disp_fetch_0 =>
--
-- enable PC via ALU to address latch
--
PC_out_en <= '1' after Tpd; -- enable PC onto op1_bus
ALU_op <= pass1 after Tpd; -- pass PC to r_bus
--
addr_latch_en <= '1' after Tpd; -- latch displacement address
--
next_state := disp_fetch_1;
--
--
-- increment PC & start bus read
--
ALU_op <= incr1 after Tpd; -- increment PC onto r_bus
--
--
next_state := disp_fetch_2;
--
--
-- cleanup after previous disp_fetch_1
--
PC_out_en <= '0' after Tpd; -- disable PC from op1_bus
ALU_op <= disable after Tpd; -- disable ALU from r_bus
--
-- latch displacement
--
disp_latch_en <= '1' after Tpd; -- latch fetched disp from r_bus
disp_latch_en <= '0' after Tpd;
--
if ready = '1' then
el se
next_state := disp_fetch_2; -- extend bus read
end if;
phi1
phi2
disp_
fetch_0
ALU_op
addr_latch_en
disp address
a_bus
fetch
d_bus
ready
valid data in
read
disp_latch_en
execute_0
PC_out_en
PC_latch_en
pass1 incr1 disable
disp_
fetch_1
disp_
fetch_2
Figure7-28. Timing for DP32 displacement fetch.
The sequence for fetchi ng a di spl acement fr om memor y i s si mi l ar to
that for fetchi ng the i nstructi on word. The onl y di fference i s that i nstead of
the read word bei ng enabl ed onto the resul t bus and l atched i nto the
i nstr ucti on r egi ster , the wor d i s si mpl y l atched fr om the memor y data bus
i nto the di spl acement l atch. The ti mi ng for a di spl acement fetch i s shown
i n Fi gure7-28. The sequence consi sts of the processor states disp_fetch_0,
disp_fetch_1 and one or more repeti ti ons of disp_fetch_2, correspondi ng to bus
states Ti , T1 and T2 respecti vel y. Thi s sequence i s al ways fol l owed by the
fi rst execute state, correspondi ng to the bus Ti state at the end of the bus
tr ansacti on. I n the VHDL descr i pti on, the case br anches for disp_fetch_0,
disp_fetch_1 and disp_fetch_2 i mpl ement thi s behavi our .
when execute_0 =>
--
-- terminate bus read from previous disp_fetch_2
--
--
case opcode is
when op_add | op_sub | op_mul | op_div
| op_addq | op_subq | op_mulq | op_divq
| op_land | op_lor | op_lxor | op_lmask =>
-- enable r1 onto op1_bus
if opcode = op_addq or opcode = op_subq
or opcode = op_mulq or opcode = op_divq then
-- enable i8 onto op2_bus
el se
-- select a2 as port2 address
-- enable r2 onto op2_bus
end if;
-- select ALU operation
ALU_op <= ALU_op_select(bits_to_int(opcode)) after Tpd;
--
-- latch cond codes from ALU
-- latch result for reg write
--
next_state := fetch_0; -- execution complete
write_back_pending := true; -- register write_back required
--
when op_ld | op_st | op_ldq | op_stq =>
-- enable r1 to op1_bus
if opcode = op_ld or opcode = op_st then
-- enable displacement to op2_bus
el se
-- enable i8 to op2_bus
end if;
ALU_op <= add after Tpd; -- effective address to r_bus
--
addr_latch_en <= '1' after Tpd; -- latch effective address
--
--
phi1
phi2
execute_0 fetch_0
reg_port1_en
reg_port2_en
reg_port3_en
reg_port2_
mux_sel
ALU_op
op
CC_latch_en
reg_res_
latch_en
Figure7-29. Execution of register/ register operations.
Executi on of i nstructi ons starts i n state execute_0. The fi rst acti on i s to
negate the bus control si gnal s that may have been acti ve from a previ ous
di spl acement fetch sequence. Subsequent acti on depends on the i nstructi on
bei ng executed, so a nested case statement i s used, wi th the op-code as the
sel ecti on expr essi on.
Ari thmeti c and l ogi c i nstructi ons onl y requi re one cycl e to exectute. The
pr ocessor ti mi ng for the case wher e both oper ands ar e i n r egi ster s i s shown
i n Fi gure7-29. The address for regi ster port1 i s deri ved from the r1 fi el d of
the current i nstructi on, and thi s port output i s enabl ed onto the op1 bus.
The mul ti pl exor for the address for regi ster port2 i s set to sel ect fi el d r2 of
the current i nstructi on, and thi s port output i s enabl ed onto the op2 bus.
The ALU functi on code i s set accordi ng to the op-code of the current
i nstructi on, and the ALU output i s pl aced on the resul t bus. Duri ng the
second hal f of the cycl e, when the ALU resul t and condi ti on codes are
stabl e, the regi ster resul t l atch and condi ti on code l atch are enabl ed,
capturi ng the resul ts of the operati on. I n the next cycl e, the regi ster read
ports and the l atches are are di sabl ed, and the regi ster wri te port i s enabl ed
to wri te the resul t back i nto the desti nati on regi ster. Thi s wri te back
operati on overl aps the fi rst cycl e of the next i nstructi on fetch. The resul t
regi ster address, deri ved from the r3 fi el d of the current i nstructi on, i s not
overwri tten unti l the end of the next i nstructi on fetch, so the wri te back i s
per for med to the cor r ect r egi ster .
when op_br | op_bi | op_brq | op_biq =>
if CC_comp_result = '1' then
if opcode = op_br then
elsif opcode = op_bi then
elsif opcode = op_brq then
else -- opcode = op_biq
end if;
ALU_op <= add after Tpd;
el se
assert opcode = op_br or opcode = op_bi
report "reached state execute_0 "
& "when brq or biq not taken"
severity error;
ALU_op <= incr1 after Tpd;
end if;
--
--
--
when others =>
null;
end case; -- op
--
The ti mi ng for ar i thmeti c and l ogi cal i nstr ucti ons wher e the second
operand i s an i mmedi ate constant i s shown i n Fi gure7-30. The di fference
i s that regi ster port2 i s not enabl ed; i nstead, the si gn extensi on buffer i s
enabl ed. Thi s converts the 8-bi t si gned i 8 fi el d of the current i nstructi on to a
32-bi t si gned i nteger on the op2 bus.
Looki ng agai n at the exectute_0 branch of the state machi ne, the nested
case statement contai ns a br anch for ar i thmeti c and l ogi cal i nstr ucti ons.
I t fi rstl y enabl es port1 of the regi ster fi l e, and then enabl es ei ther port2 or
the si gn extensi on buffer, dependi ng on the op-code. The l ookup tabl e
ALU_op_select i s i ndexed by the op-code to determi ne the ALU functi on code.
The process then wai ts unti l the l eadi ng edge of phi2, and asserts the
r egi ster r esul t and condi ti on code l atch enabl es whi l e phi2 i s '1'. At the end
of the cycl e, the next state i s set to fetch_0, and the wri te back pendi ng fl ag i s
set. Duri ng the subsequent i nstructi on fetch, thi s fl ag i s checked (i n the
fetch_0 branch of the outer case statement). The regi ster port3 wri te enabl e
control si gnal i s asserted duri ng the fetch_0 state, and then at the begi nni ng
of the fetch_1 state i t i s negated and the fl ag cl eared.
phi1
phi2
reg_port1_en
reg_port3_en
ALU_op
op
CC_latch_en
reg_res_
latch_en
immed_
signext_en
execute_0 fetch_0
Figure7-30. Execution of register/ immed operations.
phi1
phi2
execute_0
PC_out_en
ALU_op
add
PC_latch_en
immed_
signext_en
phi1
phi2
execute_0
reg_port1_en
ALU_op
add
PC_latch_en
immed_
signext_en
(a) (b)
Figure7-31. Execution of quick branch with branch taken.
when execute_1 =>
--
-- opcode is load or store instruction.
-- cleanup after previous execute_0
--
if opcode = op_ld or opcode = op_st then
-- disable displacement from op2_bus
el se
-- disable i8 from op2_bus
end if;
ALU_op <= add after Tpd; -- disable ALU from r_bus
--
-- start bus cycle
--
if opcode = op_ld or opcode = op_ldq then
fetch <= '0' after Tpd; -- start bus read
else -- opcode = op_st or opcode = op_stq
reg_port2_mux_sel <= '1' after Tpd; -- address a3 to port2
reg_port2_en <= '1' after Tpd; -- reg port2 to op2_bus
d2_en <= '1' after Tpd; -- enable op2_bus to d_bus buffer
write <= '1' after Tpd; -- start bus write
end if;
--
--
when execute_2 =>
--
-- opcode is load or store instruction.
-- for load, enable read data onto r_bus
--
if opcode = op_ld or opcode = op_ldq then
dr_en <= '1' after Tpd; -- enable data to r_bus
-- latch data in reg result latch
write_back_pending := true; -- write-back pending
end if;
--
--
end case; -- state
end process state_machine;
end block controller;
end RTL;
phi1
phi2
execute_0
PC_out_en
ALU_op
incr1
PC_latch_en
Figure7-32. Execution of branch with branch not taken.
phi1
phi2
ALU_op
execute_0
PC_out_en
PC_latch_en
add
disp_out_en
phi1
phi2
ALU_op
execute_0
reg_port1_en
PC_latch_en
add
disp_out_en
(a) (b)
Figure7-33. Execution of branch with branch taken.
We now move on to the executi on of branch i nstructi ons. We saw
previ ousl y that for qui ck branches, when the branch i s not taken executi on
compl etes after the decode state. When the branch i s taken a si ngl e execute
cycl e i s requi red to update the PC wi th the effecti ve address. The ti mi ng for
thi s case i s shown i n Fi gure7-31. Fi gure7-31(a) shows an ordi nary qui ck
branch, i n whi ch the PC i s enabl ed onto the op1 bus. Fi gure7-31(b) shows
an i ndexed qui ck br anch, i n whi ch the i ndex r egi ster , r ead fr om r egi ster
fi l e port1 i s enabl ed onto the op1 bus. The si gn extensi on buffer i s enabl ed
to pl ace the i mmedi ate di spl acement on the op2 bus, and the ALU functi on
code i s set to add the two val ues, formi ng the effecti ve address of the branch
on the resul t bus. Thi s i s l atched back i nto the PC regi ster duri ng the
second hal f of the executi on cycl e.
For br anches wi th a l ong di spl acement, a si ngl e executi on cycl e i s
al ways requi red. I f the branch i s not taken, the PC must be i ncremented to
poi nt to the i nstructi on after the di spl acment. The ti mi ng for thi s i s shown
i n Fi gure7-32. The PC i s enabl ed onto the op1 bus, and the ALU functi on i s
set to incr1. Thi s i ncrements the val ue and pl aces i t on the resul t bus. Then
duri ng the second hal f of the cycl e, the new val ue i s l atched back i nto the
PC r egi ster .
For l ong di spl acement br anches wher e the br anch i s taken, the PC must
be updated wi th the effecti ve address. Fi gure7-33(a) shows the ti mi ng for
an ordi nary branch, i n whi ch the PC i s enabl ed onto the op1 bus.
Fi gure7-33(b) shows the ti mi ng for an i ndexed branch, i n whi ch the i ndex
regi ster i s enabl ed from regi ster port1 onto the op1 bus. The di spl acement
regi ster output i s enabl ed onto the op2 bus, and the ALU functi on i s set to
add, to add the di spl acement to the base address, formi ng the effecti ve
address on the resul t bus. Thi s i s l atched back i nto the PC regi ster duri ng
the second hal f of the cycl e.
The VHDL descr i pti on i mpl ements the executi on of a br anch i nstr ucti on
as part of the nested case statement for the execute_0 state. The process
checks the resul t bi t from the condi ti on code comparator. I f i t i s set, the
branch i s taken, so the base address and di spl acement are enabl ed
(dependi ng on the type of branch), and the ALU functi on code set to add.
Other wi se, i f the condi ti on code compar ator r esul t i s cl ear , the br anch i s
not taken. Thi s shoul d onl y be the case for l ong branches, si nce qui ck
branches shoul d never get to the execute_0 state. An asserti on statement i s
used to veri fy thi s condi ti on. For l ong branches whi ch are not taken, the PC
i s enabl ed onto the op1 bus and the ALU functi on code set to incr1 to
i ncrement the val ue past the di spl acement i n memory. The PC l atch
enabl e si gnal i s then pul sed when phi2 changes to '1'. Fi nal l y, the next
state i s set to fetch_0, so the processor wi l l conti nue wi th the next
i nstr ucti on.
The remai ni ng i nstructi ons to be consi dered are the l oad and store
i nstructi ons. These al l take three cycl es to execute, si nce a bus transacti on
i s requi red to transfer the data to or from the memory. For l ong
di spl acement l oads and stor es, the di spl acement has been pr evi ousl y
fetched i nto the di spl acement regi ster. For the qui ck forms, the i mmedi ate
di spl acement i n the i nstr ucti on wor d i s used.
Fi gure7-34 shows the ti mi ng for executi on of l oad and qui ck l oad
i nstructi ons. The base address regi ster i s read from regi ster fi l e port1 and
enabl ed onto the op1 bus. For l ong di spl acement l oads, the previ ousl y
fetched di spl acement i s enabl ed onto the op2 bus, and for qui ck l oads, the
si gn extended i mmedi ate di spl acement i s enabl ed onto the op2 bus. The
ALU functi on code i s set to add, to form the effecti ve address on the resul t
bus, and thi s i s l atched i nto the memory bus address regi ster duri ng the
second hal f of the fi rst execute cycl e. Duri ng the next two cycl es the
contr ol l er per for ms a memor y r ead tr ansacti on, wi th the fetch si gnal hel d
negated. The data from the data bus i s enabl ed onto the resul t bus through
the connecti ng buffer, and l atched i nto the regi ster resul t l atch. Thi s val ue
i s then wri tten back to the regi ster fi l e duri ng the fi rst cycl e of the
subsequent i nstr ucti on fetch.
phi1
phi2
reg_port1_en
reg_port3_en
ALU_op
addr_latch_en
reg_res_
latch_en
a_bus
fetch
d_bus
ready
read
execute_0
add
disp_out_en
or immed_
signext_en
load address
disable
dr_en
valid data in
execute_1 execute_2 fetch_0
Figure7-34. Execution of load instructions.
The ti mi ng for executi on of store and qui ck store i nstructi ons i s shown
i n Fi gure7-35. As wi th l oad i nstructi ons, the base address and
di spl acement are added, and the effecti ve address i s l atched i n the memory
bus address regi ster. Duri ng the next two cycl es the control l er performs a
bus wri te transacti on. The mul ti pl exor for the regi ster fi l e port2 address i s
set to sel ect the r3 fi el d of the i nstructi on, whi ch speci fi es the regi ster to be
stored, and the port2 output i s enabl ed onto the op2 bus. The buffer between
the op2 bus and the memory data bus i s enabl ed to transmi t the data to the
memory. Executi on of the i nstructi on compl etes at the end of the bus
tr ansacti on.
Returni ng to the VHDL descri pti on, the fi rst cycl e of executi on of l oad
and store i nstructi ons i s i ncl uded as a branch of the nested case i n the
execute_0 state. The base address regi ster output port i s enabl ed, and ei ther
the di spl acement l atch output or the si gn extensi on buffer i s enabl ed,
dependi ng on the i nstructi on type. The ALU functi on code i s set to add the
two to form the effecti ve address. The process then wai ts unti l phi2 changes
to '1', i ndi cati ng the second hal f of the cycl e, and pul ses the address l atch
enabl e. The next state i s then set to execute_1 to conti nue executi on of the
i nstr ucti on.
I n state execute_1, the process fi rstl y removes the base address,
di spl acement and effecti ve address from the DP32 i nternal buses, then
starts a memory bus transacti on. For l oad i nstructi ons, the fetch si gnal i s
negated and the read si gnal i s asserted. For store i nstructi ons, the source
regi ster val ue i s enabl ed onto the op2 bus, the memory data bus output
buffer i s enabl ed, and the write si gnal i s aserted. The next state vari abl e i s
then set to execute_2 for the next cycl e.
I n state execute_2, for l oad i nstructi ons, the memory data bus i nput
buffer i s enabl ed to transmi t the data onto the resul t bus. The process then
wai ts unti l phi2 i s '1', i n the second hal f of the cycl e, and pul ses the enabl e
for the regi ster resul t l atch. The wri te back pendi ng fl ag i s then set to
schedul e the desti nati on r egi ster wr i te dur i ng the next i nstr ucti on fetch
cycl e. For both l oad and store i nstructi ons, the next state i s fetch_0. Al l
control si gnal s set duri ng the execute_1 state wi l l be returned to thei r
negated val ues i n the fetch_0 state.
The test bench descri bed i n Secti on7.5 can be used to test the regi ster
transfer archi tecture of the DP32. Thi s i s done usi ng an al ternate
confi gur ati on, r epl aci ng the behavi our al ar chi tectur e i n the test bench wi th
the r egi ster tr ansfer ar chi tectur e. Fi gur e7-36 shows such a confi gur ati on.
The enti ty bi ndi ngs for the cl ock generator and memory are the same,
usi ng the behavi our al ar chi tectur es, but the pr ocessor component i nstance
uses the rtl archi tecture of the dp32 enti ty. Thi s bi ndi ng i ndi cati on i s
fol l owed by a confi gurati on for that archi tecture, bi ndi ng the enti ti es
descri bed i n Secti ons7.6.17.6.9 to the component i nstances contai ned i n
the ar chi tectur e. The newl y confi gur ed descr i pti on can be si mul ated usi ng
the same test programs as before, and the resul ts compared to veri fy that
they i mpl ement the same behavi our .
phi1
phi2
reg_port1_en
ALU_op
addr_latch_en
a_bus
d_bus
ready
read
execute_0
add
disp_out_en
or immed_
signext_en
store address
disable
valid data out
reg_port2_
mux_sel
reg_port2_en
d2_en
fetch
write
execute_1 execute_2
Figure7-35. Execution of store instructions.
configuration dp32_rtl_test of dp32_test is
for structure
for cg : clock_gen
use entity work.clock_gen(behaviour)
generic map (Tpw => 8 ns, Tps => 2 ns);
end for;
for mem : memory
use entity work.memory(behaviour);
end for;
for proc : dp32
use entity work.dp32(rtl);
for rtl
for all : reg_file_32_rrw
use entity work.reg_file_32_rrw(behaviour);
end for;
for all : mux2
use entity work.mux2(behaviour);
end for;
for all : latch
use entity work.latch(behaviour);
end for;
for all : PC_reg
use entity work.PC_reg(behaviour);
end for;
for all : ALU_32
use entity work.ALU_32(behaviour);
end for;
for all : cond_code_comparator
use entity work.cond_code_comparator(behaviour);
end for;
for all : buffer_32
use entity work.buffer_32(behaviour);
end for;
for all : latch_buffer_32
use entity work.latch_buffer_32(behaviour);
end for;
for all : signext_8_32
use entity work.signext_8_32(behaviour);
end for;
end for;
end for;
end for;
end dp32_rtl_test;
Figure7-36. Configuration using register transfer architecture of DP32.

VHDL Cookbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VHDL Cookbook

Uploaded by

Copyright:

Available Formats

The

waveform_n when choice_list_n;

si mul ati on system for thi s

Zycad System VHDL i s a tr ademar k of Zycad Cor por ati on.

You might also like