3 p íklady konstrukcí v jazyku vhdl

Transkript

Brno Training and Innovation Centre
Jazyk VHDL
a jeho užití pro syntézu íslicových systém
Brno 2005
Doc. Ing. Jaromír Kolouch, CSc.
1 JAZYK VHDL A JEHO UŽITÍ P I SYNTÉZE
ÍSLICOVÝCH SYSTÉM .......... 3
1.1 Úvod ......................................................................................................................................................... 3
1.2 Základní struktura modelu v jazyku VHDL ........................................................................................ 5
1.2.1 Deklarace entity............................................................................................................................... 7
1.2.2 T lo architektury ............................................................................................................................. 7
1.3 Datové objekty ...................................................................................................................................... 11
1.3.1 Typy dat ........................................................................................................................................ 13
1.3.2 Atributy ......................................................................................................................................... 16
1.4 P íkazy jazyka VHDL .......................................................................................................................... 17
1.4.1 Výrazy a operátory ........................................................................................................................ 17
1.4.2 Operace s objekty typu std_logic a std_logic_vector.................................................. 19
1.4.3 Soub žné p íkazy .......................................................................................................................... 22
1.4.4 Sekven ní p íkazy ......................................................................................................................... 25
1.4.5 Modelování pam ových prvk pomocí p íkaz IF-THEN-ELSE............................................. 26
1.5 Vytvá ení hierarchických model v jazyku VHDL ........................................................................... 27
1.6 Prost edky jazyka VHDL pro úsporný zápis kódu ........................................................................... 32
1.7 Funkce.................................................................................................................................................... 35
2 POSTUP VYTVO ENÍ POPISU KONSTRUKCE V JAZYKU VHDL ................ 37
3 P ÍKLADY KONSTRUKCÍ V JAZYKU VHDL .................................................. 40
3.1 Kombina ní obvody.............................................................................................................................. 41
3.1.1 P evodník hexadecimálního kódu na kód sedmisegmentového displeje....................................... 41
3.1.2 P evodník kódu BCD na binární kód ............................................................................................ 42
3.1.3 S íta ka v kódu BCD .................................................................................................................... 43
3.1.4 P evodník binárního kódu na kód BCD ........................................................................................ 45
3.2 Subsystémy se zvláštními typy bran.................................................................................................... 49
3.2.1 Subsystémy s t ístavovými výstupy a s otev eným kolektorem .................................................... 49
3.2.2 Subsystémy s obousm rnými branami .......................................................................................... 50
3.3 Pam ové obvody se zp tnou vazbou.................................................................................................. 51
3.4
íta e ..................................................................................................................................................... 51
3.4.1 Binární íta e ................................................................................................................................ 52
3.4.2
íta e pracující v kódu BCD......................................................................................................... 52
3.5 Stavové automaty.................................................................................................................................. 53
3.5.1 Behaviorální popis s deklarací uživatelského typu pro stav .......................................................... 55
3.5.2 Popis s explicitním kódováním stav ............................................................................................ 57
3.5.3 Synchronní nulování u stavových automat .................................................................................. 58
3.6 P íklady iterativních konstrukcí ......................................................................................................... 59
3.6.1 P evodník binárního kódu na Gray v a naopak ............................................................................ 59
3.6.2 Gray v íta .................................................................................................................................. 61
1
4 DODATEK 1: UŽIVATELSKÝ POPIS ZÁKLADNÍCH OBVOD SPLD ........... 64
4.1 Obvody GAL 16V8 a GAL 20V8......................................................................................................... 64
4.2 Obvod GAL 22V10 a jeho varianty..................................................................................................... 65
5 LITERATURA.................................................................................................... 69
2
1 JAZYK VHDL A JEHO UŽITÍ P I SYNTÉZE
ÍSLICOVÝCH SYSTÉM
1.1 ÚVOD
Název VHDL p edstavuje akronym – VHSIC Hardware Description Language. Samo
ozna ení VHSIC je další akronym p edstavující název projektu, v rámci n hož byl jazyk
VHDL zpracován, a znamená Very High Speed Integrated Circuits. I když vysoká i nízká
rychlost popisovaných obvod není podstatná pro použití jazyka VHDL, uvedené ozna ení se
vžilo a obecn se používá. Jazyk VHDL byl p vodn vyvinut p edevším pro modelování a
simulaci rozsáhlých systém . Na mnoha jeho konstruktech je to znát, n které z nich nemají
pro syntézu v bec význam. Zde se však budeme zabývat p edevším použitím jazyka VHDL
k vytvá ení model ur ených pro syntézu íslicových systém . Simulaci budeme využívat
p edevším pro ov ení správnosti funkce a asových parametr syntetizované konstrukce.
eské termíny budou v prvním výskytu zapsány tu n . asto tyto termíny nejsou ustálené, a
proto budeme uvád t i jejich anglické ekvivalenty, které již v tšinou mají ustálenou podobu.
Anglické termíny a asto užívané fráze jsou v textu uvád ny kurzívou (zpravidla v závorce).
V delších zdrojových textech, které demonstrují probírané jazykové konstrukty, jsou p íslušné
úseky textu pro lepší p ehlednost uvedeny tu n .
Pro popis modelu navrhovaného systému v jazyku VHDL budeme používat termín
zdrojový text nebo stru n ji kód, což odpovídá asto užívanému anglickému termínu code.
Základní vlastnosti jazyka VHDL (krom první z nich jsou to i vlastnosti jazyka ABEL):
∗ Je to otev ený standard (open standard). K jeho použití pro sestavení návrhových systém
není t eba licence jeho vlastníka, jako je tomu u jiných jazyk HDL (nap íklad u jazyka
ABEL). To je jeden z d vod , pro je tento jazyk v návrhových systémech asto používán.
∗ Umož uje pracovat na návrhu, aniž je p edtím zvolen cílový obvod. Ten m že být zvolen až
v okamžiku, kdy jsou známy definitivní požadavky na prost edí, v n mž má navrhovaná
konstrukce pracovat, a je možno cílový obvod m nit podle pot eby p i zachování popisu
v jazyku HDL, p i emž m že být zvolen obvod PLD nebo FPGA. (Device-independent
design.)
∗ Je možno provést simulaci navrženého obvodu na základ téhož zdrojového textu, který pak
bude použit pro syntézu a implementaci v cílovém obvodu. Zdrojový text je možno zpracovávat v r zných simulátorech a v syntetizérech r zných výrobc . Odsimulovaný text m že
být použit v dalších projektech s r znými cílovými obvody, což je podporováno hierarchickou strukturou jazyka. Této vlastnosti jazyka se íká p enositelnost (portability) kódu.
∗ V p ípad úsp šného zavedení výrobku na trh lze popis konstrukce v jazyku VHDL použít
jako podklad pro její implementaci do obvod ASIC vhodných pro velké série.
N které námitky proti VHDL:
∗ Jazyk VHDL je dosti „upovídaný“, jazykové konstrukty nejsou navrženy tak, aby zdrojový
text byl stru ný a p i popisu modelu ur ité konstrukce se setkáme s opakováním blok
stejného zn ní. Ty je však možno snadno vytvá et využitím kopírování a podobných
možností sou asných editor .
∗ V jazyku VHDL je možno vytvo it neefektivní konstrukce, efektivnost nebo její nedostatek
nemusí být na první pohled ze zdrojového textu patrné. To je však vlastnost i jiných jazyk
vyšší úrovn a výsledná efektivnost konstrukce závisí nejen na kvalit programových
3
návrhových prost edk , ale také na zkušenosti konstruktéra (návrhá e). Jak vyzrávají
návrhové systémy, p ebírají na sebe stále v tší díl pot ebné dovednosti a „chytrosti“, d íve
nezbytných u konstruktéra. Tyto vlastnosti samoz ejm bude konstruktér nadále pot ebovat,
budou však nasm rovány pon kud jinak než d íve.
Základní verze jazyka VHDL byla p ijata jako standard IEEE íslo 1076 v roce 1987.
Konstrukty odpovídající tomuto standardu se ozna ují jako konstrukty jazyka VHDL-87.
Podobn jako další standardy IEEE, i tento standard se v pravidelném p tiletém intervalu
akutalizuje. Upravená verze standardu byla p ijata v roce 1993, odkazuje se na ni jako na
standard VHDL-93. Nový standard jazyka z konce 90. let zahrnuje již i možnosti popisu
analogových prvk a je znám pod ozna ením VHDL-AMS (Analog and Mixed Signals).
V tomto textu je popsána p edevším verze VHDL-87. N které dopl ky verze VHDL-93, které
jsou d ležité pro syntézu, jsou uvedeny s pat i ným upozorn ním.
Vedle jazyka VHDL se setkáme také s jazykem Verilog, který má podobné použití. Uvádí
se, že jazyk VHDL je rozší ený zejména v Evrop , zatímco Verilog se používá hlavn
v asijských zemích. V USA se používají oba tyto jazyky.
V dále uvedených zp sobech popisu r zných jazykových konstrukt se n kdy vyskytují
slova a fráze jako „obvykle“, „m l by být“ a podobn . Tím je myšlena skute nost, že
sou asn vyskytující návrhové systémy jsou na r zné úrovni vyzrálosti a inteligence. Systém,
který by bylo možno ozna it jako vysp lý, bude takové konstrukty schopen zpracovat a optimalizovat bez problém . Ne všechny sou asné systémy to však zvládnou. Obecn je možno
íci, že ím blíže odpovídá popis skute né fyzické realizaci popisované struktury v cílovém
obvodu, tím pravd podobn jší je optimální výsledek syntézy. Nap íklad n které zp soby
behaviorálního popisu s algoritmickým charakterem mohou p sobit p i syntéze problémy, i
když jsou syntakticky správné, protože zapojení, které má být výsledkem syntézy, žádný algoritmický charakter ve skute nosti nemá. Za neme-li pracovat s novým systémem, je vhodné
ov it si na jednoduchých p íkladech, zda syntéza probíhá podle o ekávání. N kdy se m že
stát, že zdánliv jasný text je syntetizován do struktury, která obsahuje nadbyte nou logiku,
p ípadn její ást m že být nevhodná (nap íklad s hazardy) nebo úpln nefunk ní. Lze však
ekat, že pr b hem doby budou syntetizéry stále dokonalejší a problém bude ím dál mén .
K p enositelnosti kódu je nutno p ipojit poznámku. Jazyk VHDL je velmi rozsáhlý. Byl
p vodn ur en p edevším pro simulaci velkých íslicových systém . Jeho použití pro syntézu
se za alo rozpracovávat pozd ji a využívá se p i n m jen ást jeho prost edk . V po áte ních
fázích tohoto sm ru využití jazyka VHDL byly vytvá eny jednoduché syntetizéry se zna n
omezeným rozsahem prost edk jazyka, které jimi byly podporovány. Postupn , jak
syntetizéry vyspívaly, tento rozsah se rozši oval. Proto je možno o ekávat, že základní
konstrukty jazyka budou r znými syntetizéry zpracovány stejn , ale neobvyklé zp soby
popisu a n které vyšší jazykové struktury mohou dávat r zné výsledky p i zpracování
r znými syntetizéry. Je také nutno po ítat s tím, že r zné syntetizéry podporují odlišný rozsah
prost edk jazyka. Postupem doby, jak budou syntetizéry vyzrávat, se patrn bude rozši ovat
oblast jazykových konstrukt využitelných v syntéze, které budou dávat výsledky syntézy
skute n nezávislé na použitých návrhových systémech.
Zp soby sestavení modelu:
Postup zdola nahoru (bottom-up): nejprve se vytvo í díl í bloky modelu a ty se pak
skládají do v tších celk . Tento postup byl charakteristický pro sestavování íslicových
konstrukcí z pevn zapojených íslicových obvod , které p edstavovaly bloky nejnižší
úrovn .
4
Postup shora dol (top-down): definuje se funkce navrhovaného systému jako celku.
V n m se vy lení bloky, jejichž funkce se specifikuje spolu s vzájemnou návazností
jednotlivých blok . U velkých konstrukcí mohou jednotlivé bloky detailn zpracovávat r zní
konstrukté i.Tento proces pokra uje tak dlouho, až se na nejnižší úrovni získají dostate n
jednoduché bloky, jejichž funkci je možno popsat prost edky, jako je behaviorální popis
v jazycích HDL. Tímto zp sobem se zpravidla pracuje p i syntéze s použitím moderních
systém CAD, kde starost o podrobné zapojení p ebírají návrhové systémy.
P ístupy zdola nahoru a shora dol m že být ú elné v r zných fázích zpracování ur ité
konstrukce kombinovat. Obvykle však p evažuje tendence uvedená výše.
Model plochého typu (flat) neobsahuje len ní odpovídající výše uvedeným typ m.
P edstavuje konstrukci jako jeden monolitický blok.
První dva zp soby sestavení konstrukce se ozna ují jako hierarchické. Jazyk VHDL
hierarchi nost konstrukcí podporuje. Rozumn zvolená hierarchie usnad uje orientaci
v popisu modelu navrhované konstrukce.
1.2 ZÁKLADNÍ STRUKTURA MODELU V JAZYKU VHDL
Konstrukce (model) v jazyku VHDL má dv základní ásti: deklaraci entity (entity
declaration) a t lo (popis) architektury (architecture body). Deklarace entity popisuje
vstupy a výstupy konstrukce, popis architektury definuje její funkci. Mezery, tabulátory a
znaky nového ádku slouží podobn jako v ABELu jako odd lova e, nemají další význam a
m žeme je používat podle libosti k roz len ní textu tak, aby byl p ehledný.
Jako p íklad uvedeme popis modelu ty bitového komparátoru:
LIBRARY ieee;
-- odkaz na knihovnu
-- TXT1.1
USE ieee.std_logic_1164.ALL; -- odkaz na slohu v knihovn ieee
ENTITY EqComp4 IS
PORT(a,b:
IN std_logic_vector(3 DOWNTO 0); -- vstupy
Equals: OUT std_logic);
-- výstup
END EqComp4;
-------
1
2
3
4
5
6
ARCHITECTURE Dataflow OF EqComp4 IS
BEGIN
Equals <= '1' WHEN (a = b) ELSE '0';
END Dataflow;
-----
7
8
9
10
V p íkladu jsou ádky opat eny vpravo ísly pro usnadn ní odvolávek na ádky.
Vyhrazená (klí ová) slova (reserved words) jsou psána velkými písmeny. Jsou to slova,
jejichž význam je stanoven v definici jazyka VHDL. Význam n kterých dalších vícepísmenových slov je definován dalšími standardy, které rozvíjejí základní definici jazyka VHDL,
užitými knihovnami ( o t ch pojednáme podrobn ji ve stati v nované hierarchii) apod. – zde
nap . std_logic nebo std_logic_vector. Pro n budou užívána malá písmena. Identifikátory (uživatelské symboly) slouží k ozna ení signál , prom nných a podobných objekt .
Volí je návrhá . Identifikátor musí za ínat písmenem anglické abecedy a na dalších pozicích
m že obsahovat písmena, íslice 0 až 9 nebo znak podtržítko. Podtržítko nesmí být posledním
znakem identifikátoru, dv po sob následující podtržítka nejsou p ípustná. Budeme je
zapisovat s velkým po áte ním písmenem. Pokud tyto symboly budou složeny z více ástí,
budou takto vyzna ena jejich po áte ní písmena. Jednopísmenové symboly budeme však psát
malým písmem. Velká a malá písmena se v jazyku VHDL v klí ových slovech a v identifikátorech nerozlišují, v n kterých jiných jazykových konstruktech však mohou být
rozlišována. Zde budou klí ová slova psána velkými písmeny jen pro p ehlednost.
5
Komentá e (comments) v textu VHDL za ínají dv ma poml kami (--) a kon í vždy na konci
ádku; má-li komentá pokra ovat na dalším ádku, musí toto pokra ování op t za ínat dv ma
poml kami. Skupinu poml ek, která, jak poznáme dále, se používá pro vyjád ení
nedefinovaných hodnot (don’t care), dokážou syntetizéry od symbolu komentá e rozeznat.
Deklaraci entity nazvané EqComp p edstavují ádky 3 až 6. Na ádcích 4 a 5 jsou
deklarovány vstupy komparátoru – ty bitové brány a a b, a jednobitový výstup Equals.
Deklarace entity p edstavuje textovou formu ozna ení bloku, který komparátor p edstavuje,
analogickou schématické zna ce pro integrovaný obvod používané ve schématech. Tato
deklarace se pak m že použít pro vložení popisovaného bloku do vyšších hierarchických
blok jako komponenty, jak bude vysv tleno dále. Pokud je popisovaný blok nejvyšší
hierarchickou jednotkou – vrcholovou jednotkou (top unit) nebo pokud hierarchie v konstrukci není zavedena, budou brány p edstavovat signály na vývodech cílového obvodu, do
n hož konstrukce bude vložena.
Apostrofy se používají p i uvád ní jednotlivých znak (characters), uvozovky se pak
užívají pro et zce (strings), které umož ují zápis hodnoty vektor , nap . "0101". Užitím
klí ového slova DOWNTO je definováno po adí bit podle jejich binární váhy, takže zde je bit
a(3) nejvýznamn jší bit (MSB), bit a(0) nejmén významný bit (LSB) vektoru a. P i zápisu
hodnoty vektoru se jednotlivé íslice zapisují v obvyklém po adí, tj. zleva (MSB) doprava
(LSB). N kdy se m žeme setkat i s opa nou definicí pomocí klí ového slova TO, nap .
bit_vector(0 TO 3). Pak má nejvýznamn jší bit index 0.
ádky 7 až 10 – t lo architektury, stru n ji architektura, popisují funkci entity EqComp4.
Podobn jako deklarace entity, i t lo architektury má sv j název, zde Dataflow. Oba názvy
mohou, ale nemusí být totožné. K jedné deklaraci entity m že být p i azeno i více architektur
s r znými jmény. Nap íklad s íta ka m že být sériová (s postupným p enosem) nebo
paralelní, a ob tyto varianty mohou mít spole nou deklaraci entity. Odpovídající architektury
je pak možno odlišit r znými jejich názvy. Možnost p i azení v tšího po tu architektur jedné
entit je podporována obvykle jen p i simulaci, u syntézy bývá uvažována jen jedna
architektura – nap íklad ta, která je zapsaná jako první. P ed klí ovým slovem BEGIN m že
být za azena deklarativní ást (declarative part) architektury, v níž mohou být nap íklad
deklarovány signály, za ním následuje p íkazová ást (statement part).
Deklarace entity, architektura a další kódová uskupení definovaná v jazyku VHDL jako
jsou komponenty, funkce, procedury atd., která mohou být jako celek zkompilována,
uschována v knihovnách a používána v dalších konstrukcích, p edstavují konstruk ní
jednotky (design units) kódu – stru n jim budeme íkat jednotky. Konstruk ní jednotky
vytvá ené uživatelem v jazyku VHDL jsou v po íta i obvykle obsaženy ve form soubor
(files), jeden soubor však m že obsahovat i více jednotek. Detaily p edstavující organizaci
t chto soubor jsou specifické pro každý návrhový systém. Obecn lze íci, že nezáleží na
tom, ve kterém souboru je která konstruk ní jednotka obsažena. Návrhové systémy obvykle
zajiš ují p i azení soubor ur itému projektu pomocí uživatelského rozhraní, v n mž uživatel
soubory pat ící k tomuto projektu vyzna í a pak jsou již všechny jednotky z t chto soubor
pro projekt dostupné. Mezi návrhovými systémy však v tom mohou být ur ité rozdíly.
Deklarace entity spolu s odpovídajícím t lem architektury tvo í konstruk ní entitu (design entity), stru n e eno – entitu. Ta, jak bylo uvedeno, m že p edstavovat bu vrcholovou
jednotku nebo komponentu, která se vkládá do vyšších jednotek hierarchické struktury.
6
1.2.1 Deklarace entity
Brány (ports) jsou v deklaraci entity deklarovány v závorce za klí ovým slovem PORT.
Pat í k datovým objekt m a definují odpovídající signály (o signálech bude e dále). Deklarace brány se skládá ze jména brány, tj. identifikátoru p íslušného signálu, a dále z ur ení
sm ru jejího p enosu (mód – mode) a typu dat, která signál p edstavují. Módy mohou být:
∗ IN – vstup;
∗ OUT – výstup (výstupní signál nem že být použit uvnit konstruk ní entity);
∗ BUFFER – výstup se zp tnou vazbou, z n j signál m že být použit uvnit entity;
∗ INOUT – obousm rný vývod.
Význam mód m žeme dob e ilustrovat nap íklad na zapojení výstupních makrobun k
obvodu GAL 16V8. Módy IN a OUT odpovídají vstup m a výstup m v jednoduchém módu
(simple). Mód OUT m že p edstavovat i t ístavový výstup. Mód INOUT odpovídá výstupu se
zp tnou vazbou vedenou z vývodu obvodu (s t ístavovým výstupním budi em). Brány s módem OUT i INOUT však mohou v jazyku VHDL obecn být i registrové – tato konfigurace
výstup u uvedeného obvodu není. Brány s módem OUT nelze použít nap íklad pro výstupy
íta e, protože jejich signály musí být dostupné uvnit obvodu. Mód BUFFER odpovídá
výstupu se zp tnou vazbou v jednoduchém módu nebo konfiguraci výstup v registrovém
módu. Brána s módem BUFFER je vybavena zp tnovazebním kanálem, tím však nem že být
do obvodu veden signál z vn jšího zdroje.
U n kterých systém se mohou vyskytnout problémy p i kompilaci text obsahující brány
s módem BUFFER. Tyto brány m žeme nahradit pomocí bran s módem OUT, jestliže jim
odpovídající signál deklarujeme jako vnit ní signál (klí ové slovo SIGNAL) pod jiným
identifikátorem, ímž jej u iníme dostupným uvnit obvodu, a p íslušné brán tento vnit ní
signál p i adíme p i azovacím p íkazem. Jinou možností je p i adit jim mód INOUT. Tato
druhá možnost však p edstavuje zbyte nou komplikaci p i simulaci (nutnost vytvo ení
vstupního kanálu), takže se doporu uje dávat p ednost první možnosti.
Typy dat v jazyku VHDL mohou být velmi r znorodé. Nej ast ji se užívají typy, které
jsou p eddefinovány v základních standardech, jako je standard IEEE 1076/87 a jeho dopln ná verze 1076/93, kde je definována tzv. sloha (package) std_logic_1164. Lze ji najít v knihovn IEEE. Zde je deklarován typ dat zvaný std_logic, který m že nabývat devíti hodnot,
jak bude uvedeno dále, s odpovídajícím složeným typem std_logic_vector. Tyto typy jsou
široce používány v textech VHDL psaných pro syntézu i pro simulaci. Chceme-li v kódu
VHDL tyto typy použít, musí zde být na jejich deklaraci odkázáno klauzulemi LIBRARY a USE.
Setkáme se však i s typy definovanými p ímo konstruktérem, jak uvidíme nap íklad v ásti
v nované stavovým automat m. Podrobn ji se k typ m i ke slohám vrátíme pozd ji.
1.2.2 T lo architektury
Architektura m že být popsána r znými styly jazyka VHDL. Pojem stylu není v tomto
jazyku p ímo definován, ale n které jazykové konstrukty ve VHDL mohou být za azeny do
skupin, které tyto styly p edstavují. Nej ast ji se mluví o stylu behaviorálním, o stylu
popisujícím tok dat a o stylu strukturálním.
Pojem behaviorální styl je užíván dv ma zp soby. V literatu e týkající se syntézy se
obvykle tento styl charakterizuje užitím jazykového konstruktu zvaného proces (process).
Výše uvedený ty bitový komparátor m žeme popsat textem zapsaným behaviorálním stylem
s využitím procesu takto:
7
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ENTITY EqComp4 IS
PORT(a,b:
-- výstup
END EqComp4;
-- TXT1.2
ARCHITECTURE Behavioral1 OF EqComp4 IS BEGIN
Comp: PROCESS (a,b) BEGIN
IF a = b THEN Equals <= '1';
ELSE Equals <= '0';
END IF;
END PROCESS Comp;
END Behavioral1;
ádek obsahující slovo PROCESS za íná náv štím (Comp:), které je nepovinné. Po slovu
PROCESS následuje seznam citlivosti (sensitivity list) – lze íci také seznam p sobících
signál , jejichž zm na m že vyvolat zm nu n kterého ze signál , které jsou procesem
definovány (v souvislosti se simulací se íká, že tato zm na spustí provedení procesu). Popis
procesu pak je ohrazen slovy BEGIN a END PROCESS s p íslušným náv štím.
Význa ným rysem procesu je jeho algoritmický charakter, ímž se text procesu podobá
po íta ovým programovacím jazyk m. Tato podoba odpovídá skute nosti, je-li v procesu
zpracovávána tzv. prom nná. Je zde však významná odlišnost, jde-li o zpracovávání signálu
(zatím jsme pracovali jen se signály, podrobnosti o prom nných a o signálech budou uvedeny
pozd ji). Tato odlišnost spo ívá v tom, že jsou-li v procesu uvedeny p íkazy postupn
p i azující jednomu ur itému signálu r zné hodnoty, jsou p i každém tomto p i azení
p edcházející p íkazy p epsány posledním z nich. Po kompilaci je tento signál vytvo en tak,
jak to odpovídá poslednímu p i azovacímu p íkazu v procesu, všechny p edcházející p íkazy
se ignorují. To platí i tehdy, vyskytuje-li se signál, jemuž se p i azuje nová hodnota, mezi
signály, z nichž se nová hodnota po ítá (viz p íklad v textu TXT1.4), p i emž až do ukon ení
procesu má tento signál svou p vodní hodnotu. Proces m žeme chápat jako myšlenkovou
p ípravu na vytvo ení signál v procesu popsaných. To se skute n d je p i innosti
simulátor – v angli tin se p i azení hodnot signál m v procesu íká scheduled assignment,
emuž by mohl v eštin odpovídat název plánované i odložené p i azení, na rozdíl od
p i azení ozna ovaného jako immediate assignment (okamžité i bezprost ední p i azení),
které nastává u p i azovacích p íkaz uvedených mimo proces, a také u zpracování
prom nných v procesu. Tento rozdíl si m žeme si p edstavit tak, že ve skute nosti dojde k
p i azení nových hodnot všem signál m v procesu najednou v okamžiku skon ení procesu
podle posledního p íkazu v myšleném asovém rozvinutí procesu platného pro každý z t chto
signál (odložené p i azení), zatímco p i bezprost edním p i azení nabývá signál i prom nná
nové hodnoty ihned po provedení p íkazu. Odložené p i azení v procesu se u signál zna í
operátorem "<=", zatímco pro p i azení bezprost ední u prom nných se používá symbol ":=".
Podobnost s programem pro po íta je u signál p edevším v tom, že výsledek procesu závisí
na po adí zápisu jednotlivých p íkaz v n m. To z textu TXT1.2 není p íliš patrné, lépe to
uvidíme v textu TXT1.3, který popisuje tentýž komparátor:
ARCHITECTURE Behavioral2 OF EqComp4 IS BEGIN
Comp: PROCESS (a,b) BEGIN
Equals <= '0';
IF a = b THEN Equals <= '1';
END IF;
END PROCESS Comp;
END Behavioral2;
8
-- TXT1.3
Zde se první p íkaz p i azující nulovou hodnotu signálu equals p epíše druhým p íkazem
p i spln ní podmínky a = b, v opa ném p ípad se p íkaz Equals <= '1' neprovede a
z stane v platnosti první. Uv domme si však, že výsledný signál Equals p edstavuje ve
skute nosti kombina ní funkci signál a a b, která m že být zapsána i jinak, nap . pomocí
logického výrazu, a rozvinutí procesu v ase (postupné p episování p i azovacích p íkaz ) je
jen pom cka pro naši p edstavu, která n kdy umož uje stru n jší nebo p ehledn jší zápis než
jiné zp soby vyjád ení.
Jako p íklad syntakticky správného, v cn však chybného textu uvedeme popis modelu
ty vstupového sou inového lenu pomocí smy ky (TXT1.4, syntaxe smy ek bude popsána
pozd ji):
LIBRARY ieee;
ENTITY And4 IS
PORT(a: IN std_logic_vector(3 DOWNTO 0);
x: INOUT std_logic);
END And4;
-- TXT1.4
ARCHITECTURE AndErr OF And4 IS BEGIN
PROCESS (a) BEGIN
x <= '1';
FOR i IN 3 DOWNTO 0 LOOP
x <= a(i) AND x;
END LOOP;
END PROCESS;
END AndErr;
Nezkušený konstruktér by mohl o ekávat, že tak vznikne sou inový len s po tem vstup
daným deklarací a hodnotou zadanou v p íkazu smy ky (zde se ty mi vstupy). Kompilací
však zjistíme, že výsledkem je bez ohledu na ší ku vektoru a zápis x = "a<0>" * x (ve
WebPACKu je tento zápis v reportu fitteru), což odpovídá poslednímu z p íkaz , které
p edstavují rozvinutí smy ky. Náprava m že být v tom, že se v procesu deklaruje prom nná,
se kterou se vykoná p íslušná iterativní operace (smy ka), a na záv r se její hodnota p i adí
signálu x:
ARCHITECTURE AndOK OF And4 IS BEGIN
PROCESS (a)
VARIABLE Xvar: std_logic;
BEGIN
Xvar := '1';
FOR i IN 3 DOWNTO 0 LOOP
Xvar := a(i) AND Xvar;
END LOOP;
x <= Xvar;
END PROCESS;
END AndOK;
-- TXT1.5
Tato architektura pat í ke stejné entit And4, ve které však mód INOUT brány x m že být
nahrazen módem OUT, protože zde není signál x použit jako vstupní signál, jak je tomu ve
smy ce architektury AndErr. Kompilací zjistíme, že vyjád ení pro signál x je nyní správné.
Architektura m že obsahovat více proces , a v tomto p ípad musíme p ijmout p edstavu,
že všechny procesy probíhají soub žn .
asto, zejména v pracích týkajících se simulace íslicových systém – nap íklad v literatu e [2], se m žeme také setkat s užitím pojmu behaviorální styl s pon kud jiným, obecn jším
obsahem: behaviorálním stylem se zde rozumí popis na vysoké úrovni abstrakce, kde nemusí
9
být uvažovány konkrétní hodnoty ší ky datových a adresových sb rnic, kde nejsou
specifikovány hodinové signály a podobn . Nap íklad p i abstraktním modelování po íta e se
operace ADD chápe zc obecn , bez uvažování ur itého zp sobu kódování dat. Tento styl se
používá k simulaci, pro syntézu je nutno úrove abstrakce snížit. O popisu demonstrovaném
výše uvedenými p íklady se pak mluví jako o popisu úrovn RTL (register transfer level).
Toto ozna ení vychází z obecné p edstavy o struktu e íslicového systému, který je možno
rozd lit na kombina ní ást a registr. Modelování systému na úrovni RTL se pak provádí po
blocích s hranicemi vymezenými rozsahem „od registru k registru”, p ípadn jednou z hranic
(nebo i ob ma u kombina ních funkcí) m že být vstup nebo výstup cílového obvodu. Po
takových blocích se pak také obvykle provádí i optimalizace, která zahrnuje algoritmy
analogické minimalizaci známé z obecného kursu íslicové techniky (Karnaughovy mapy),
volbu nejvhodn jšího typu registru (D, T, JK) a podobn . To práv odpovídá uvedeným
p íklad m.
Styl popisující tok dat (dataflow) je ilustrován výše uvedeným textem TXT1.1. asto se
tento styl pokládá za zvláštní p ípad behaviorálního stylu. Vedle prostých p i azovacích
p íkaz se zde používají p íkazy typu podmín ných p i azovacích p íkaz CASE-WHEN nebo
výb rových p i azovacích p íkaz WITH-SELECT-WHEN, tedy tzv. soub žné p íkazy
(podrobnosti budou uvedeny pozd ji), z nichž každý m žeme pokládat za zjednodušený tvar
procesu s vynechanými slovy PROCESS a END PROCESS, na rozdíl od sekven ních p íkaz
používaných v procesech zapsaných úplnou formou. U soub žných p íkaz nezávisí výsledek
na po adí jejich zápisu v textu.
V dalším textu se obvykle budeme p idržovat základního d lení na styl behaviorální, do
n hož budeme zahrnovat i styl popisující tok dat, a na styl strukturální. Tam, kde to bude
pot ebné nebo ú elné, použijeme slovní zp esn ní.
Strukturální popis je t etím význa ným stylem. Spo ívá ve vkládání tzv. komponent
(component) do kódového útvaru zvaného netlist. Podrobnosti o komponentách budou
uvedeny v kapitole Vytvá ení hierarchických model v jazyku VHDL. Strukturální styl se
používá nej ast ji v hierarchickém uspo ádání konstrukce jako popis propojení díl ích blok
nižší úrovn . Náš známý komparátor m že být popsán tímto stylem podle textu TXT1.6:
LIBRARY ieee;
ENTITY EqComp4 IS
PORT(a,b:
-- výstup
END EqComp4;
-- TXT1.6
USE work.Gatespkg.ALL;
ARCHITECTURE Struct OF EqComp4 IS
SIGNAL x: std_logic_vector(0 to 3);
BEGIN
u0: Xnor2 PORT MAP (a(0),b(0),x(0));
u4: And4 PORT MAP (x(0),x(1),x(2),x(3),Equals);
END Struct;
Komponenty použité v textu TXT1.6 nejsou definovány ve standardu VHDL. P edpokládá
se, že komponenty Xnor2 a And4 jsou definovány ve sloze Gatespkg vytvo ené uživatelem a
ta že je zkompilována do knihovny work. Klauzule USE work.Gatespkg.ALL zp ístup uje
tyto komponenty v uvedené architektu e. Klí ové slovo ALL v t chto klauzulích znamená, že
10
jsou zp ístupn ny všechny jednotky (zde komponenty) z p íslušných sloh. (Pokud by v n kolika použitých slohách byly jednotky se stejným jménem, je možno místo slova ALL uvést
jednotku, kterou chceme v p íslušné sloze zp ístupnit, a tak vybrat ur itou z nich.) Funkce
takto popsaného komparátoru spo ívá v porovnání jednotlivých bit bran a a b jednotkou
Xnor2 a ve vytvo ení logického sou inu díl ích výsledk jednotkou And4.
Strukturální styl popisu na rozdíl od jiných styl obvykle nedává mnoho možností pro
optimalizaci p i syntéze, a poskytuje tak konstruktérovi v tší kontrolu nad výsledkem
syntézy. To však nemusí vždy p edstavovat výhodu tohoto stylu, protože se tím nevyužívá
inteligence zabudovaná do návrhového systému. Strukturální styl popisu je také obvykle
mén p ehledný ve srovnání s behaviorálním stylem. Proto se obvykle tam, kde je to možné,
používá rad ji jiných styl . N kdy se však m že stát, že použití behaviorálního stylu vede po
syntéze k jiné struktu e, než bylo p vodn zamýšleno, a již proto, že inteligence systému
není dostate ná, nebo když chceme vytvo it n jakou netypickou strukturu. Pak m že být
strukturální popis vhodným prost edkem k dosažení cíle. asto jsou ur ité komponenty
definovány pro syntézu výrobci obvod PLD a FPGA a jsou optimalizovány tak, aby
odpovídaly struktu e cílových obvod . To umož uje využít specifických vlastností t chto
obvod , p itom se však snižuje nebo odstra uje nezávislost popisu na cílovém obvodu.
Mohou rovn ž vzniknout problémy p i simulaci, protože simulátor nemusí mít k dispozici
stejné modely jako syntetizér. Syntaxe a další podrobnosti budou uvedeny pozd ji p i popisu
hierarchických konstrukcí.
Nyní je na míst se ptát, jestli konstrukce s ur itou danou funkcí bude syntetizérem
implementována do cílového obvodu vždy stejným zp sobem, bude-li popsána r znými styly,
nebo v rámci ur itého stylu r znými zp soby zápisu kódu, kterých bývá obvykle více. Obecn
to nemusí platit, ale ím dokonalejšího nástroje použijeme, tím v tší pravd podobnost bude,
že výsledkem bude optimální implementace nezávislá na stylu a zp sobu popisu, nebo aspo
všechny výsledné implementace budou blízké implementaci optimální. Jak syntetizéry
vyzrávají, získávají stále v tší inteligenci a schopnost optimum najít. Ne vždy však je takové
optimum jednozna né. V n kterých aplikacích se nap íklad klade d raz na ešení, které
spot ebuje co nejmén prost edk (resources) v cílovém obvodu a vede k nejnižší cen , jindy
je d ležit jším kritériem rychlost reakce, op t jindy m že být optimem jistý kompromis.
V praxi m že však být nejd ležit jším kritériem i rychlost nalezení p ijatelného ešení bez
zvláštní optimalizace, která umožní rychlé uvedení výrobku na trh. Zkušený konstruktér
dokáže odhadnout, co lze od ešení ur itého problému za daného stavu technologie o ekávat,
a umí syntetizér p inutit, aby našel ešení, které je optimální pro daný p ípad.
1.3 DATOVÉ OBJEKTY
Jazyk VHDL definuje ty i t ídy (classes) datových objekt : konstanty, signály, prom nné
a soubory. Datové objekty musí být p ed svým užitím deklarovány.
Konstanty (constants) mají hodnotu, která je nem nná. Ta je konstant p i azena p i její
deklaraci. Konstanty zlepšují p ehlednost kódu. Mohou být v textu vícenásobn použity, a
pokud se p i další úprav textu vyskytne pot eba hodnotu konstanty zm nit, sta í to u init
v deklaraci. Nap íklad m že konstanta definovat ší ku registru:
CONSTANT Width: integer := 8;
Signály (signals) jsou datové objekty, které se v realizované konstrukci skute n vyskytují
(obvykle ve form elektrických signál ). Pat í k nim i signály p íslušné branám, jak jsme je
již poznali. Vnit ní signály konstrukce se deklarují užitím syntaxe podle p íkladu:
11
SIGNAL Count: bit_vector(3 DOWNTO 0);
Signál m m že být v deklaraci p i azena po áte ní hodnota podobn jako konstantám. Pro
syntézu toto p i azení nemá význam, je však respektováno p i simulaci. Signály deklarované
jako brány mají definován mód (IN, OUT atd.), signály deklarované klí ovým slovem SIGNAL
mód nemají definován.
Prom nné (variables) nep edstavují skute né signály. Používají se jako pomocné objekty
nap íklad pro po ítání cykl v behaviorálním popisu. Jejich použití v procesech m že pomoci
p i algoritmickém vyjád ení signál (p ipome me, že p i azení prom nných je bezprost ední,
zatímco p i azení signál v procesu je odložené), jak to bylo ukázáno v textech TXT1.4 a
TXT1.5. Používají se asto v textech ur ených k simulaci, a také ve funkcích a v procedurách,
zejména p i konverzi typ dat a podobn . P i psaní zdrojových text ur ených k syntéze je
t eba mít na pam ti, že se z prom nných nevytvá ejí fyzické struktury v cílovém obvodu.
N které sou asné systémy mohou mít s jejich zpracováním problémy. Nejedná-li se o použití,
kde je jejich význam zcela jednozna ný a kde je jejich užití doporu eno v dokumentaci k použitému návrhovému systému, je lepší se jim v textech ur ených k syntéze vyhnout.
Z výše uvedeného nevyplývá, že všechny signály, tj. objekty deklarované v textu jako
SIGNAL, pop ípad PORT v hierarchickém popisu, také budou fyzicky p ítomny ve struktu e
obvodu, která vznikne zpracováním textu systémem. P i tomto zpracování se provádí
optimalizace, p i níž se n které signály mohou ukázat nadbyte nými (nap íklad p edstavuje-li
signál mezivýsledek v kombina ním obvodu, který je možno zjednodušit do dvoustup ové
struktury AND-OR s nevelkým po tem term ), a následn mohou být vypušt ny. Naopak p i
syntéze složit jších kombina ních obvod bývá nutno zavést další signály, které umož ují
automaticky syntetizovat funkce vyžadující v tší po et term než je k dispozici v jednotlivých
makrobu kách obvod PLD (št pení sou t ). Analogicky to platí i u systém používajících
jiných vstupních prost edk (nap íklad jazyk ABEL, schéma a podobn ). Pouze u velmi
jednoduchých systém , jako je easyABEL, se všechny deklarované signály p i zpracovávání
pln zachovají (systém s nimi neumí pracovat jinak než je zjednodušovat), ale systémy
používající jazyk VHDL obvykle již jsou vybaveny inteligencí pot ebnou k automatickému
provedení složit jší optimalizace v etn uvedeného vynechávání nadbyte ných signál ,
pop ípad p idávání dalších p i št pení sou t . Z prom nných se však žádné fyzické struktury
nevytvá ejí. Na vzniku fyzické struktury se prom nná m že podílet pouze tak, že se nap íklad
její hodnota p i adí signálu, který je pak syntetizován, jak je to t eba v textu TXT1.5.
Soubory (files). Význam tohoto ozna ení v jazyku VHDL se shoduje s obvyklým
významem. Soubory se používají nap íklad pro uložení vstupních a výstupních dat p i
simulaci.
Datovým objekt m jsou v deklaracích p i azeny identifikátory. N kdy m že být výhodné
p i adit objekt m více identifikátor , což m žeme zajistit užitím alias . Nap íklad:
SIGNAL Address: std_logic_vector(31 DOWNTO 0);
ALIAS TopAdd: std_logic_vector( 3 DOWNTO 0) IS Address(31 DOWNTO 28);
ALIAS RowAdd: std_logic_vector(11 DOWNTO 0) IS Address(23 DOWNTO 12);
Aliasy se používají obvykle pro ozna ení ur itých skupin signál , které jsou leny vektoru,
jak je to z ejmé z uvedeného p íkladu. asto m že být výhodné naopak sdružovat jednotlivé
signály do v tších skupin. To je možno provést deklarací takové skupiny jako signál a
p i azením jejích len signál m, které chceme sdružit. Viz nap . dále uvedený p íklad
p evodníku kódu (TXT3.1.1).
12
1.3.1 Typy dat
Jazyk VHDL je definován jako p ísn typový (strongly typed), což znamená, že p ed
každým použitím n jakého objektu musí být deklarován jeho typ (type). Ten ur uje, jakých
hodnot m že deklarovaný objekt nabývat, a jaké operace s ním jsou p ípustné. Datové objekty
r zných typ nemohou být vzájemn p i azovány bez konverze. Podobn operátory mohou
být užity jen pro datové typy, pro n ž jsou definovány, není-li uživatelem definováno jejich
p etížení (overloaded operators). eský termín „p etížení“ není zvolen p íliš zda ile, patrn
by bylo výstižn jší slovo rozší ení nebo p edefinování, ale je již vžitý. Nejpoužívan jší typy
jsou definovány p ímo v p íslušných standardech, uživatel si však m že definovat i své
vlastní typy podle pot eby, jak to poznáme nap íklad u stavových automat .
Pro syntézu jsou nejd ležit jší skalární (scalar) a složené (composite) typy dat. Skalární
typy mohou být: vý tové (enumeration), celo íselné (integer), s pohyblivou árkou
(floating) a fyzické (physical). Složené typy jsou pole (array) a záznam (record).
Vý tové typy jsou definovány vý tem hodnot, kterých objekt tohoto typu m že nabývat,
uvedeným v závorce v deklaraci typu. Vý tové typy jsou uspo ádané (ordered). To
znamená, že pro prvky takového typu jsou definovány rela ní operace, tj. operace <, > a
podobn . Po adí, v n mž jsou ve vý tu uvedeny, definuje toto uspo ádání: nejlev jší položka
se pokládá za nejmenší, každá další za v tší než p edchozí. Konstruktér si m že definovat
vlastní vý tové typy; setkáme se s tím p edevším p i modelování stavových automat .
Standard IEEE 1076 definuje dva vý tové typy d ležité pro syntézu: bit a boolean:
TYPE bit IS ('0','1');
TYPE boolean IS (false,true);
Typ bit m že p edstavovat b žné dvouhodnotové signály. Typ boolean lze chápat jako
abstrakci p edchozího typu, kde nejsou zvoleny logické úrovn p i azené p íslušnému signálu.
Standard IEEE 1164 definuje typ std_ulogic:
TYPE std_ulogic IS ('U',
'X',
'0',
'1',
'Z',
'W',
'L',
'H',
'-');
-- Uninitialized
-- Forcing Unknown
-- Forcing 0
-- Forcing 1
-- High Impedance
-- Weak Unknown
-- Weak 0
-- Weak 1
-- Don’t care
Literály jako 'Z', 'L' a další musí zde být psány velkým písmem. Tento typ umož uje nap íklad práci s t ístavovými výstupy a dovoluje také vyjád it hodnotu, na níž nezáleží ('-') a
využít jí ke zjednodušení výsledku syntézy (pokud to ovšem použitý syntetizér podporuje).
Definuje také asto používaný subtyp std_logic, pro n jž je std_ulogic základním typem. Sada hodnot je stejná, ale tento subtyp má navíc p i azenu rozlišovací (vyhodnocovací)
funkci (resolution function) nazvanou resolved. Tato rozlišovací funkce je d ležitá p i simulaci, kde dovoluje pracovat s obvody, které mají propojeny výstupy, jako je to nap . u obvod
s otev eným kolektorem nebo s t ístavovými výstupy. Simulace však p i použití typu s rozlišovací funkcí probíhá pomaleji, protože simulátor tuto funkci musí p i každém zpracování
signálu tohoto typu volat jako podprogram. Proto je p i simulaci rozsáhlých íslicových konstrukcí n kdy vhodn jší použít základní typ, u model ur ených k syntéze však obvykle tato
skute nost nehraje významn jší roli. Podrobn ji je tato problematika popsána nap íklad v [4].
13
Standard IEEE 1076 definuje dále pole std_ulogic_vector a std_logic_vector,
n které další subtypy a také funkce pro p etížení operátor , konverzní funkce a další užite né
pom cky. Chceme-li je použít, musíme p ed deklaraci entity zapsat následující odkazy:
LIBRARY ieee;
S typem std_logic a s odpovídajícím složeným typem std_logic_vector pracujeme p i
syntéze nej ast ji.
Celo íselné typy. Tyto typy a operátory pro rela ní a aritmetické operace s nimi jsou
definovány v základním standardu jazyka VHDL. Nástroje zpracovávající texty v jazyku
VHDL musí podporovat rozsah celých ísel od -(231 - 1) do +(231 - 1). Signál celo íselného
typu, který má být syntetizován, musí být omezen rozsahem (range), z n hož vyplyne
požadavek na po et bit , nap íklad:
SIGNAL a: integer RANGE 0 TO 255;
Subtyp natural obsahuje nulu a kladná celá ísla, subtyp positive jen kladná celá ísla.
Typy pole. Objekt tohoto typu je složen z více prvk téhož typu. Nejb žn jší typy tohoto
druhu jsou definovány ve standardech 1076 a 1164:
TYPE bit_vector IS ARRAY (natural RANGE <>) OF bit;
TYPE std_logic_vector IS ARRAY (natural RANGE <>) OF std_logic;
V závorce uvedené slovo natural zde znamená typ index . Zápis RANGE <> znamená, že jde
o neomezená pole, jejichž rozsah musí být vymezen p i jejich užití v deklaraci (TO, DOWNTO).
P i zápisu hodnot objekt typu pole je možno užívat znakových et zc . Nap íklad je-li
signál a deklarován zápisem:
SIGNAL a: std_logic_vector(7 DOWNTO 0);
je mu možno p i adit hodnotu
a <= "00011011";
V takovém et zci se mohou vyskytovat i jiné prvky dovolené u p íslušného typu, jako
'Z', '-' apod. (viz nap . TXT2.3). Pro pole typu bit_vector lze užít i binárního, oktalového
nebo hexadecimálního formátu. Standard VHDL-93 rozši uje tuto možnost pro všechny typy
polí, které obsahují prvky '0' a '1'. Základ (X – hexadecimální, O – oktalový, B – binární
zápis) se specifikuje takto:
a <= X"1B";
Pokud není základ uveden, je p edpokládán zápis binární. Je-li žádoucí vyzna it v zápisu
bitových vektor pomocí znakových et zc skupiny, je možno k tomu použít podtržítko (_),
které se p i kompilaci ignoruje (n které systémy však použití podtržítka tímto zp sobem
nedovolují). Je také možno využít funkce p evodu ísla typu integer na typ
standard_logic_vector konverzní funkcí, nap . p i použití slohy std_logic_arith:
a <= conv_std_logic_vector(27,8);
nebo se zápisem prvního argumentu jako celého ísla v šestnáctkové soustav
a <= conv_std_logic_vector(16#1B#,8);
- první argument konverzní funkce je p evád né íslo, druhý je po et bit (ší ka) vektoru.
Další možností je zápis ve tvaru agregátu (aggregate), který odpovídá tomu, co v jazyku
ABEL nazýváme slovem sada. Výše uvedená hodnota se ve tvaru agregátu zapíše
14
a <= ('0','0','0','1','1','0','1','1').
V tomto zápisu mohou být i prvky jako 'Z', '-' apod, a také jednobitové signály i
prom nné. Uvedený zápis p edstavuje p i azení pozi ní (positional association), kde jsou
hodnoty uvedené v závorce p i azeny prvk m vektoru na základ jejich po adí ve shod s deklarací p íslušného typu (pozor na možnost sestupné nebo vzestupné deklarace – DOWNTO nebo
TO), m žeme však použít i p i azení vyjmenováním (named association), kde p ed znakem
=> jsou hodnoty index p íslušných prvk :
a <= (4=>'1',3=>'1',1=>'1',0=>'1',OTHERS=>'0').
Klí ové slovo OTHERS m že být uvedeno jen v poslední položce a dovoluje zde použít
stejného zápisu pro vektory s r znou ší kou, která je dána jejich deklarací. I zde mohou být
prvk m p i azeny jednobitové signály a prom nné. Je t eba upozornit na rozdíl od zápisu
vložení komponenty (p íkaz PORT MAP), který je podobný, ale místo hodnot index jsou zde
formální parametry. U n kterých systém ale mohou být problémy, je-li ší ka vektoru dána
genericky, viz TXT3.6.5.
Pokud pot ebujeme z objektu typu pole vybrat jeho ást, m žeme k tomu použít ez
(slices), jak to bylo nazna eno v odstavci o aliasech. Jednotlivé prvky objektu m žeme zapsat
s vyzna ením jeho indexu v závorce, nap . u výše uvedeného signálu a má a(7) hodnotu '0'.
D ležitým pojmem je také subtyp (subtype). Subtyp je odvozen od základního typu
p idáním omezení (constraint). R zné subtypy téhož základního typu mohou vystupovat
v operacích, aniž vznikne chyba p i kompilaci (nesouhlas typ operand ).
Subtypy se nej ast ji používají pro tyto ú ely:
∗ pro zkrácené ozna ení omezení typu,
∗ pro uvoln ní pravidel pro kontrolu typu,
∗ pro p i azení vyhodnocovací funkce k základnímu typu.
První zp sob použití je velmi astý u deklarací polí. Nap íklad typ std_logic_vector je
definován jako neomezený, a vymezením rozsahu index v deklaraci je implicitn definován
jeho subtyp. Takový subtyp se ozna uje za anonymní (anonymous), protože nemá p i azen
sv j vlastní identifikátor.
P i druhém zp sobu použití se využívá toho, že základní typ a jeho subtypy je možno
voln mísit ve výrazech a v p íkazech. Nap íklad lze psát:
SUBTYPE Int03 IS integer RANGE 0 TO 3;
SIGNAL b: Int03;
VARIABLE a: integer;
...
a <= b;
Toto p i azení by bylo nesprávné, kdyby Int03 byl definován jako typ, nap íklad zápisem
TYPE Int03 IS RANGE 0 TO 3;
(místo definice v prvním ádku textu). V tomto p ípad by typ Int03 nem l s typem integer
nic spole ného a výše uvedený zápis by p edstavoval syntaktickou chybu. Je-li však
definován jak je výše uvedeno jako subtyp typu integer, je vše v po ádku. Uvedené
vymezení rozsahu je d ležité p i syntéze, kdy je pot ebné definovat bitovou ší ku
deklarovaného objektu.
P íklad použití subtypu t etím zp sobem – vyhodnocovací funkce s ozna ením resolved
v definici subtypu std_logic – byl uveden výše, podrobn jší údaje jsou nap . v [6].
15
1.3.2 Atributy
Atributy poskytují informaci o jejich nositelích. T mi mohou být typy, vektory, pole a
podobn . Standardn jsou definovány atributy p íslušející p eddefinovaným typ m, uživatel
si však m že vytvo it vlastní atributy pro uživatelsky definované typy. Nej ast ji se setkáme
s následujícími atributy:
'left – nejlev jší hodnota ve vý tu v typu, levá hranice index ;
'right – nejprav jší hodnota ve vý tu v typu, pravá hranice index ;
'low – nejnižší index pole,
'high – nejvyšší index pole.
'length – délka, tj. po et prvk v poli (v e i ast ji ozna ovaný slovem ší ka – width),
'range – rozsah pole, tedy nap íklad 0 TO 7 nebo 7 DOWNTO 0 u osmibitového vektoru.
Apostrof se v angli tin te jako „tick“, tedy tick-left apod.
P íklad: Signál a a typy St, Cnt a Wrd jsou deklarovány zápisem
SIGNAL
TYPE St
TYPE Cnt
TYPE Wrd
a:
IS
IS
IS
bit_vector(7 DOWNTO 0);
(Idl,Prepar,Rd,Wr);
integer RANGE 0 TO 63;
ARRAY(31 DOWNTO 0) OF std_logic;
-- States
-- Count
-- Word
Uvedeme dále výraz s atributem a jeho význam:
a'left
a'right
a'low
a'high
a'length
a'range
7
St'left
0
St'right
0
St'low
7
St'high
8
St'length
7 DOWNTO 0
Idl
Wr
Idl
Wr
4
Cnt'left
Cnt'right
Cnt'low
Cnt'high
Cnt'length
Cnt'range
0
63
0
63
64
0 TO 63
Wrd'left
Wrd'right
Wrd'low
Wrd'high
Wrd'length
Wrd'range
31
0
0
31
32
31 DOWNTO 0
Velmi asto se setkáme s atributem 'event – zm na i událost, dávající hodnotu typu
boolean, která je true v p ípad , že u signálu, k n muž se atribut vztahuje, nastala zm na,
jinak false. Povšimn te si rozdílu mezi klí ovým slovem RANGE a atributem 'range!
Atribut m jsou syntakticky podobné tzv. vymezené výrazy (qualified expressions). Je-li
nap íklad v kódu zapsáno '1', není z tohoto zápisu z ejmé, k jakému typu tato hodnota pat í –
m že to být typ bit nebo std_logic a další. Chceme-li typ explicitn uvést (type casting),
m žeme k tomu užít vymezeného výrazu podle syntaxe:
typ'(literál nebo výraz)
Nap íklad zápis: bit'('1') p edstavuje hodnotu '1' typu bit.
Zde je nutno upozornit na klí ové slovo ATTRIBUTE. Atributy s ním spojené se používají k
ízení kompilátoru a k podobným ú el m jako alternativa k použití r zných p epína
(„options“) v návrhových systémech. Zatímco výše uvedené atributy jsou sou ástí definice
jazyka, atributy spojené s klí ovým slovem ATTRIBUTE jsou spíše sou ástí návrhových
systém a zp sob jejich použití je nutno najít v dokumentaci k t mto systém m. Používají se
nap íklad k p i azení vývod pouzdra signál m, k vyzna ení uzl , které se nemají z
konstrukce eliminovat (nap íklad p i odstra ování hazard zavedením konsensu nebo u
iterativních konstrukcí – viz [1]) a podobn . Jejich výskyt ve zdrojovém textu má asto za
následek omezení jeho p enositelnosti na jiné systémy. Nebývá jich však v textu mnoho,
takže to obvykle nep edstavuje vážný problém p i p echodu na jiný systém.
16
1.4 P ÍKAZY JAZYKA VHDL
V jazyku VHDL mohou mít p íkazy soub žný nebo sekven ní charakter. N které p íkazy
jsou jen jednoho druhu, jiné mohou být obojího druhu. Toto rozlišení se týká toho, ve které
ásti popisu se p íkazy mohou používat. Pro stru nost budeme dále mluvit o soub žných a o
sekven ních p íkazech, i když jde spíše o to, kde se tyto p íkazy nacházejí i mohou nacházet.
Soub žné p íkazy (concurrent statements) se zapisují v textu jazyka mimo procesy,
definice funkcí a procedur. Jsou to tyto druhy p íkaz :
∗ podmín né p i azovací p íkazy s klí ovým slovem WHEN-ELSE;
∗ výb rové p i azovací p íkazy s klí ovými slovy WITH-SELECT-WHEN;
∗ procesy jako celky;
∗ vložené komponenty.
Sekven ní p íkazy (sequential statements) slouží k algoritmickému vyjád ení popisu.
Tyto p íkazy mohou být zapsány jen v procesech, v definicích funkcí a procedur. Pat í k nim:
∗ p i azovací p íkazy pro prom nné (pozor na rozdíl mezi signálem a prom nnou);
∗ p íkazy s klí ovými slovy IF-THEN-ELSE (-ELSIF);
∗ p íkazy s klí ovými slovy CASE-WHEN;
∗ smy ky i s p íkazy užívaných k jejich organizaci (LOOP, NEXT, EXIT, RETURN) a p íkaz NULL.
Soub žný i sekven ní charakter mohou mít p íkazy, které mohou být jak uvnit proces ,
definic funkcí a procedur, tak i mimo n (jejich druh je pak dán tímto umíst ním). Jsou to:
∗ jednoduché p i azovací p íkazy, tj. p íkazy obsahující pouze výrazy;
∗ volání funkcí a procedur;
∗ p íkazy ASSERT (-REPORT).
U soub žných p íkaz nezáleží na po adí jejich zápisu. Výsledek kompilace sekven ních
p íkaz však závisí na po adí jejich zápisu v textu. To je však dáno ani ne tak p íkazy
samotnými, jako spíše zp sobem kompilace proces , funkcí a procedur, v nichž se tyto
p íkazy nacházejí.
Terminologie zde použitá se m že zdát pon kud zavád jící, pokud si neuv domíme, že
výraz „sekven ní p íkazy“ se netýká modelování sekven ních subsystém , jak je známe ze
základního kurzu íslicové techniky. Sekven ní p íkazy mohou být použity v procesech,
funkcích a procedurách pro modelování kombina ních subsystém . Na druhé stran n které
jednoduché sekven ní subsystémy, jako jsou klopné obvody RS a podobn , mohou být modelovány pomocí soub žných p íkaz bez použití proces . Probereme nyní základní jazykové
konstrukty jazyka VHDL, z nichž se p íkazy sestavují, a p íkazy nejpoužívan jší v syntéze.
1.4.1 Výrazy a operátory
Výrazy (expressions) jsou skupiny identifikátor vzájemn propojených operátory (operators), p i emž se pro vyzna ení po adí operací (tam, kde po adí není definováno
standardem nebo kde je pot ebné toto po adí zm nit, p ípadn i jen pro lepší p ehlednost)
užívají závorky. Výrazy mohou obsahovat také funkce. V jazyku VHDL se používají výrazy
s datovými objekty r zných typ , p i emž je nutno rozlišovat, zda jde o výrazy, které mají být
zpracovány syntézou, nebo o výrazy, které nejsou ur eny pro syntézu (výrazy s pomocnými
prom nnými v cyklech, v deklaracích a podobn ), jejichž výb r je bohatší, protože se nemusí
ešit problémy s jejich fyzickou realizací. Operátory uvedené v následujícím vý tu jsou definovány ve standardu VHDL-87 s výjimkou operátor posuvu a rotace, které jsou definovány
standardem VHDL-93. Jejich použití m že být rozší eno p etížením, o n mž bude e dále.
17
Ve výrazech ur ených pro syntézu se používají:
∗ Logické operátory: AND, OR, NAND, NOR, XOR, XNOR a NOT. Mají b žn známý význam. Jsou
definovány pro typy bit nebo boolean a pro jednorozm rná pole tohoto typu. Oba
operandy musí mít tutéž délku (mimo p ípadu negace). Standard IEEE 1164 rozši uje tyto
operátory na typy std_ulogic a std_logic a na jejich jednorozm rná pole. Není mezi nimi
definována precedence, tu je nutno vyzna it závorkami, s výjimkou operátoru NOT; operace
negace má nejvyšší prioritu. Zápis složit jších logických výraz je dosti t žkopádný.
∗ Rela ní operátory: =, /=, <, <=, >, >= s obvyklým významem. První dva jsou definovány
pro všechny typy, ostatní pro skalární typy a pro pole s omezeným rozsahem. Na obou
stranách operátoru musí být data téhož typu, pokud tyto operátory nejsou p etíženy.
Výsledek rela ní operace je typu boolean, tj. true nebo false.
∗ Operátory posuvu a rotace: SLL, SRL (posuv vlevo a vpravo logický), SLA, SRA (posuv
vlevo a vpravo aritmetický), ROL, ROR (rotace vlevo a vpravo) jsou definovány pro stejné
typy jako logické operátory.
∗ Aritmetické operátory: + (s ítání) a - (od ítání nebo negace). Jsou definovány pro
všechny numerické typy (ur ené pro zápis íselných informací). K aritmetickým operátor m
se po ítá také operátor sjednocení (concatenation) zna ený symbolem &.
Ve výrazech, které nejsou ur eny pro syntézu, se mohou používat i další operátory
(v n kterých systémech jsou v omezeném rozsahu podporovány i pro syntézu):
∗ Operátory násobení a d lení: *, /, MOD, REM.
∗ Operátory mocniny a absolutní hodnoty: ** a ABS.
Operace sjednocení se používá pro vytvá ení vícebitových signál z jejich díl ích ástí.
Nap íklad signál "00111100" se ší kou 8 bit m žeme zapsat jako sjednocení dvou
ty bitových signál : "0011" & "1100". Jsou-li ve výrazu použity operátory jen jednoho
druhu, mluvíme o výrazu tohoto druhu, nap . o logickém, rela ním nebo aritmetickém výrazu.
Výrazy ovšem mohou být i smíšené.
Mezi uvedenými skupinami operátor platí priorita: ím níže je skupina uvedena, tím vyšší
prioritu mají její operátory (s výjimkou operátoru NOT). Doporu uje se však používat závorek
pro vyzna ení priority i tam, kde to není nezbytn nutné, m že-li vzniknout pochybnost
o úmyslu konstruktéra. V možnosti použití r zných operátor se jednotlivé návrhové systémy
mohou lišit, zejména pokud jde o možnost použití pro syntézu.
P et žování operátor (operator overloading). Operátory jsou definovány standardem
VHDL pro ur ité typy, p etížení operátor dovoluje používat je ve v tším rozsahu. Operátory
mohou být p etíženy uživatelem definovanými funkcemi. Mnoho t chto funkcí je definováno
ve standardech IEEE 1164 a 1076.3. V systému WebPACK jsou ve sloze
std_logic_unsigned definovány funkce p et žující aritmetické a rela ní operátory tak, že je
možno kombinovat typy std_logic_vector a integer, což dovoluje nap íklad následující
zápis:
LIBRARY ieee;
USE ieee.std_logic_unsigned.ALL;
ENTITY Compare IS PORT(a: IN std_logic_vector(3 DOWNTO 0);
x: OUT std_logic);
END Compare;
ARCHITECTURE ArchCmp OF Compare IS BEGIN
x <= '1' WHEN a = 123 ELSE '0';
END ArchCmp;
18
-- TXT1.7
Bez p etížení operátoru = by došlo k chyb p i kompilaci podmínky v p edposledním
ádku, protože íslo 123 nepat í k typu std_logic_vector. V dalších návrhových systémech
mohou být p íslušné funkce obsaženy v jiných slohách, které bývají optimalizovány pro
podporované cílové obvody, takže je nutno místo slohy std_logic_unsigned užít p íslušnou
slohu podle použitého systému. I když ur itý syntetizér m že být schopen zpracovat kód
slohy jiného výrobce, m že se stát, že výsledek zpracování aritmetických a logických struktur
nebude optimální, protože použitá sloha nebyla optimalizována pro tento systém.
Významné použití nachází princip p et žování operátor u aritmetických operací.
Aritmetické operátory jsou v základní definici jazyka definovány pro typy integer a
floating (tento druhý typ se však pro syntézu nepoužívá). I když je možno pracovat p i
syntéze s typem integer, asto je vhodn jší užít p etížení aritmetických operátor na další
datové typy. Mnoho funkcí pro p etížení operátor je definováno ve standardech IEEE 1164 a
1076.3. Poslední z nich p et žuje operátory + a - (s ítání a od ítání) na páry operand s t mito typy: (unsigned, unsigned), (unsigned, integer), (signed, signed) a (signed,
integer). Jsou definovány ve sloze numeric_std standardu 1076.3. Mnoho firem
produkujících syntetizéry dodává slohy p et žující aritmetické operátory na datové typy
std_logic a std_logic_vector. Ty obvykle definují také p etížení rela ních operátor na
tyto typy, takže syntetizér je zpracovává tyto typy jako ísla bez znaménka nebo jako
n kterou z reprezentací ísel se znaménkem, nej ast ji jako ísla v kódu dvojkového dopl ku.
P i práci s aritmetickými operátory je t eba prostudovat dokumentaci k syntetizéru, který
používáme – pot ebné údaje bývají uvedeny v ásti pojednávající o slohách.
1.4.2 Operace s objekty typu std_logic a std_logic_vector
P i syntéze se nej ast ji používají typy std_logic a std_logic_vector, které jsou
definovány navazujícím standardem IEEE 1164 ve sloze std_logic_1164. Ta bývá ve všech
návrhových systémech zkompilována v knihovn ieee. V této sloze jsou definovány
operátory pro logické operace, nejsou však zde definovány operátory pro aritmetické operace,
protože objekty uvedeného typu je možno interpretovat jako íslo bez znaménka nebo se
znaménkem (p ípadn i jinak) a provedení aritmetických operací je pro r zné tyto interpretace
odlišné.
Operátory pro srovnávání – rela ní operátory (=, /=, >, <, >=, <=) jsou v základní definici
jazyka definovány pro objekty celo íselných a vý tových typ a pro objekty s typem
jednorozm rného pole prvk t chto typ , tj. i pro objekty typu std_logic_vector. Tyto
operátory fungují pro objekty typu pole podle b žných p edstav, tj. s jejich interpretací jako
ísel bez znaménka, jen tehdy, mají-li dvojice porovnávaných objekt stejný po et prvk .
Mají-li tyto dvojice odlišný po et prvk , mohli bychom o ekávat, že p i porovnání bude
kratší pole zleva dopln no nulami. Je nutno zd raznit, že tomu tak není! Popis výsledku
takového porovnání je pon kud komplikovaný a je podrobn uveden nap íklad v [5], s. 428.
Chceme-li provád t porovnání objekt typu std_logic_vector s nestejným po tem prvk ,
m žeme postupovat podobn , jako je popsáno v následujícím odstavci pro aritmetické
operace s použitím sloh std_logic_arith (numeric_std), std_logic_unsigned nebo
std_logic_signed. V t chto slohách je definováno p etížení rela ních operátor dávající
správné výsledky porovnání i v p ípad nestejné délky porovnávaných polí.
Tam, kde je pot ebné provád t aritmetické operace (s ítání, od ítání, násobení) s objekty
typu std_logic_vector, je nutno p íslušné operátory (pop ípad p etížení t chto operátor
pro uvedené typy) definovat ve form funkce. Aby nebylo nutno deklarace t chto funkcí
v každém textu vypisovat, jsou uvedeny ve slohách v knihovn ieee. Sloha, která dovoluje
19
ob uvedené interpretace (tj. jako íslo bez znaménka nebo se znaménkem), je ozna ena
std_logic_arith, pop . numeric_std. V této sloze jsou definovány typy unsigned a
signed a operace s t mito typy, jejichž provedení odpovídá interpretaci dané názvem typu.
P i použití této slohy musíme objekty, s nimiž máme v úmyslu provád t aritmetické operace,
deklarovat jako typ unsigned nebo signed, nebo jsou-li deklarovány jako typ
std_logic_vector, musíme je na p íslušné typy p evést. P evod se nejsnadn ji provede
explicitní konverzí typ – viz dále. Pokud používáme jen jednu z uvedených interpretací,
m žeme jednodušeji provád t aritmetické operace p ímo s objekty typu std_logic_vector
s použitím slohy std_logic_unsigned nebo std_logic_signed. (Uvedená pravidla snad na
první pohled vypadají složit , sta í si však uv domit, že objekt typu std_logic_vector
m že být interpretován jako íslo bez znaménka nebo jako íslo se znaménkem, a uvedeným
výb rem slohy std_logic_unsigned nebo std_logic_signed požadovanou interpretaci
definujeme. P i použití slohy std_logic_arith je však interpretace definována tím, jakého
typu, tj. unsigned nebo signed, jsou operandy, a jsou-li typu std_logic_vector, ji
musíme definovat tím, že operandy p evedeme na typ unsigned nebo signed, p i emž je
patrn nejjednodušší použít explicitní konverze typ , jak uvidíme dále.) Ve všech t ech
uvedených slohách jsou obsažena také p etížení aritmetických operátor tak, aby bylo možno
provád t operace, kde je jeden operand n kterého z uvedených typ a druhý je celo íselný.
Jako p íklad uve me popis modelu s íta ky:
LIBRARY ieee;
ENTITY AddVec IS
PORT(a,b:
IN std_logic_vector(3 DOWNTO 0);
s1,s2: OUT std_logic_vector(3 DOWNTO 0));
END AddVec;
-- TXT1.8
ARCHITECTURE Add4 OF AddVec IS BEGIN
s1 <= a + b;
s2 <= a + 2;
END Add4;
Signály zde mají ší ku jen 4 bity, i když výsledek m že být p tibitový. Operátor + však
dává jako výsledek vektor o ší ce, která odpovídá operandu (s ítanci) s v tší ší kou. To
dovoluje snadné modelování obvyklých binárních íta , u nichž není vytvo en p enosový
bit, zápisem
Cnt <= Cnt + 1;
íta tímto zápisem popsaný p echází ze svého nejvyššího stavu do stavu vynulovaného.
Pokud chceme vytvo it s íta ku s p enosovým bitem, m žeme ji popsat následujícím textem:
LIBRARY ieee;
ENTITY Add_w_ca IS
PORT(a,b: IN std_logic_vector(3 DOWNTO 0);
sum: OUT std_logic_vector(4 DOWNTO 0));
END Add_w_ca;
ARCHITECTURE Add4Ca OF Add_w_ca IS BEGIN
sum <= ('0' & a) + b;
END Add4Ca;
20
-- TXT1.9
Pro konverzi typ je n kdy možno výhodn použít explicitní konverze typ (explicit type
conversion). Jazyk VHDL dovoluje provád t konverzi tzv. blízce p íbuzných (closely
related) typ zápisem názvu požadovaného typu následovaného hodnotou, která má být
p evedena uvedenou v závorce. Dva typy p edstavující pole jsou blízce p íbuzné, obsahují-li
prvky t chže typ , mají-li tentýž po et rozm r a stejné typy index (obvykle integer). Dv
skupiny blízce p íbuzných typ p edstavují i celo íselné typy a typy p edstavující ísla
s pohyblivou árkou. P íklad:
USE ieee.std_logic_1164;
USE ieee.std_logic_arith;
...
Cnt: BUFFER std_logic_vector(7 DOWNTO 0);
...
Cnt <= unsigned(Cnt) + 1;
Zde je signál Cnt explicitn p eveden na typ unsigned. Pro ten je ve sloze
std_logic_arith definována funkce p et žující operátor pro s ítání, p i emž je výsledek
typu std_logic_vector:
FUNCTION "+" (L: unsigned; R: integer) RETURN: std_logic_vector;
Tento text najdeme v deklaraci slohy (package declaration). Je z n j patrný po et a typ
argument a typ výsledku funkce. Pokud pot ebujeme zjistit podrobnosti o funkci, musíme
prostudovat t lo slohy (package body). N kdy je deklarace slohy dopln na stru ným
komentá em, kde jsou tyto podrobnosti uvedeny (p esto však, pot ebujeme-li zjistit p esné
chování funkce, m že být nutné analyzovat t lo slohy). Texty sloh lze zpravidla najít v instala ních adresá ích návrhových systém .
Shrnutí:
Typ std_logic_vector: je vhodný pro b žné ú ely p i syntéze tam, kde není nutno
d lat aritmetické operace s vektory s jejich r znou interpretaci, kde je pot ebné detekovat
hrany signál a kde p ichází v úvahu použití signál typu tristate a open collector. Je možné
provád t bez použití další slohy rela ní operace vektor tohoto typu chápaných jako ísla bez
znaménka stejné délky, ne však vektoru a objektu celo íselného typu nebo vektor s r znou
délkou. Pro rela ní operace s takovými operandy lze použít slohy std_logic_arith
(numeric_std) s konverzí vektoru na typ unsigned nebo signed nebo p ímo (bez
konverze) sloh std_logic_unsigned, std_logic_signed. Rovn ž pro aritmetiku –
inkrementaci a dekrementaci, s ítání, od ítání a násobení vektor a celo íselných operand
lze tento typ použít p i užití sloh, nap . std_logic_arith i numeric_std (s použitím
konverze na typ unsigned nebo signed), nebo sloh std_logic_unsigned,
std_logic_signed. Typy operand a výsledku musí odpovídat typ m uvedeným v deklaraci
p íslušné slohy. Ve slohách std_logic_unsigned, std_logic_signed jsou uvedeny
definice i p etížení operátor pro aritmetické operace vektor typu std_logic_vector (a
také pro operace s operandy smíšených typ ), ve sloze std_logic_arith i numeric_std
je to jen pro typy unsigned nebo signed s výsledkem t chto dvou typ nebo typu
std_logic_vector.
Typy unsigned a signed: jsou definovány ve sloze std_logic_arith jako pole
prvk typu std_logic, a jsou vhodné pro aritmetické operace s ítání, od ítání, násobení,
srovnávání i ve významu ísel s r zným po tem bit a také pro operace s dalším celo íselným
operandem. Použití t chto typ je ast jší v textech ur ených pro simulaci s vyšší úrovní
abstrakce, u model nižší úrovn (zejména ur ených k syntéze) je obvyklejší a vhodn jší
21
použít typ std_logic_vector. P i syntéze se obvykle vytvá ejí postfit (postroute) modely
s typy std_logic_vector, a je-li p vodn objekt deklarován jako typ unsigned nebo
signed, m že se pak stát, že model vytvo ený syntézou nebude zám nný p i p ípadné další
simulaci s modelem, z n hož byla syntéza provedena, a že pro správné provedení asové
simulace s modely vytvo enými p i syntéze bude nutné d lat v textech úpravy.
Praktický záv r pro jednoduchou aritmetiku – pro popis íta , s íta ek apod. s datovými
vstupy a výstupy chápanými nejobvyklejším zp sobem, tj. jako ísla bez znaménka:
∗ vstupy a výstupy t chto obvod lze deklarovat jako typ std_logic_vector a použít slohu
std_logic_unsigned (nejjednodušší a nejpoužívan jší),
∗ nebo p i stejn deklarovaných vstupech a výstupech použít slohu std_logic_arith a
konverzi typu operand (nejlépe explicitní – výhodné zejména tam, kde je nutno používat
ob interpretace objekt typu std_logic_vector, tj. jako íslo bez znaménka i se
znaménkem),
∗ nebo kone n deklarovat vstupy a výstupy jako typ unsigned a použít slohu
std_logic_arith (p i asové simulaci však mohou nastat drobné problémy).
Pro práci s ísly se znaménkem lze u init obdobné záv ry.
Poznámka. V poslední dob se prosazuje doporu ení místo sloh std_logic_unsigned a
používat rad ji slohy std_logic_arith nebo slohy numeric_std, která
je tém shodná s poslední uvedenou slohou. D vodem je údajn nejednozna nost obsahu
prvních dvou sloh. Sloha numeric_std je standardem IEEE, což o slohách
std_logic_unsigned, std_logic_signed a std_logic_arith neplatí a t chto sloh existuje
více verzí od r zných výrobc . Použití slohy std_logic_arith je velmi rozší ené a v sou asné dob není jasné, p evládne-li v budoucnosti užití této slohy nebo slohy numeric_std.
Podrobnosti lze najít nap íklad v literatu e [3]. V mnoha sou asných návrhových systémech
se však asto používají i slohy std_logic_unsigned, std_logic_signed (platí to i pro
systém WebPACK) a z praktického hlediska lze íci, že se jejich údajné nevýhody zatím
neprojevily. Za nejvhodn jší lze patrn pokládat užití sloh doporu ovaných v dokumentaci
k používanému návrhovému systému, a pokud je zde uvedeno více možností, pak by bylo
z ejm vhodné dát p ednost sloze numeric_std, p ípadn sloze std_logic_arith.
std_logic_signed
1.4.3 Soub žné p íkazy
Soub žné p íkazy mohou být zapsány v textu pouze mimo procesy, definice funkcí a
procedur. Krom dále uvedených p íkaz a také proces a vložených komponent zde mohou
být zapsány rovn ž jednoduché p i azovací p íkazy, volání funkcí a procedur a p íkazy
ASSERT (- REPORT).
P íkaz WHEN-ELSE (podmín ný p i azovací p íkaz) se zapisuje podle vzoru:
Jméno_signálu <= Hodnota_a WHEN Podmínka_1 ELSE
Hodnota_b WHEN Podmínka_2 ELSE
... ... ...
... ... ...
ELSE Hodnota_x;
Podmínkou bývá rela ní výraz, jehož vyhodnocením vznikne výsledek typu boolean. Je-li
tento výsledek true, íkáme, že je podmínka spln na. Signálu Jméno_signálu je p i azena ta
z hodnot, která je uvedena v prvním z ádk , v nichž je podmínka spln na. Po adí ádk zde
tedy definuje jejich prioritu. Na rozdíl od výb rového p i azovacího p íkazu, který bude
popsán dále, nejsou kladeny na podmínky v podmín ném p i azovacím p íkazu žádné
dodate né požadavky.
22
Jako p íklad uvedeme popis prioritního enkodéru:
LIBRARY ieee;
ENTITY Priority IS
PORT(a,b,c,d: IN std_logic; -- datové vstupy
w,x,y,z: IN std_logic; -- podmínky
f:
OUT std_logic); -- výstup
END Priority;
-- TXT1.10
ARCHITECTURE ArchPri OF Priority IS BEGIN
f <= a WHEN w = '1' ELSE
b WHEN x = '1' ELSE
c WHEN y = '1' ELSE
d WHEN z = '1' ELSE '0';
END ArchPri;
Pokud se v posledním p íkazu vypustí ást ELSE '0', nehlásí obvykle kompilátory
syntaktickou chybu, ale u n kterých syntetizér to zp sobí vznik záchytného registru,
podobn jako u p íkaz IF-THEN-ELSE (viz dále), u jiných (jako Altera MAX+PLUS II) nemá
tato zm na na výsledek vliv. Aby byl výsledek jednozna ný, lze doporu it, aby záv re né
p i azení (nap . zde zmín né ELSE '0'), k n muž dojde p i nespln ní všech podmínek,
nebylo vypušt no i opomenuto.
P íkaz WITH-SELECT-WHEN (výb rový p i azovací p íkaz) se zapisuje podle vzoru:
WITH Výb rový_výraz SELECT
Jméno_výrazu <= Hodnota_a WHEN Hodnota_1_výb rového_výrazu,
Hodnota_b WHEN Hodnota_2_výb rového_výrazu,
... ... ...
Hodnota_x WHEN Poslední_hodnota_výb rového_výrazu;
Signálu Jméno_signálu je p i azena ta z hodnot, která je uvedena v ádku obsahujícím
aktuální hodnotu výb rového výrazu. V tomto p íkazu musí být uvedeny všechny možné
hodnoty výb rového výrazu. Proto výsledek kompilace nezávisí na po adí ádk v p íkazu a
p íkazem tedy na rozdíl od p íkazu WHEN-ELSE není definována priorita. To m že vést k jednoduššímu výsledku kompilace. Zápis m žeme zestru nit využitím klí ových slov TO a
OTHERS a symbolu | (n které systémy, jako nap íklad ISE nebo MAX+PLUS II, dovolují
použít zde klí ové slovo TO jen pro s typu integer) podle následujícího vzoru:
WITH s SELECT
x <= a WHEN
b WHEN
c WHEN
d WHEN
"0000" TO "0100",
"0101"|"0111",
"1010",
OTHERS;
Klí ovým slovem TO v prvním ádku jsou pokryty hodnoty výb rového výrazu mezi
uvedenými krajními hodnotami, v dalším symbol | teme jako "nebo" (význam je z ejmý).
23
Význam slova OTHERS vysv tlíme v následujícím p íkladu popisu multiplexoru
ty bitových signál :
ty
LIBRARY ieee;
-- TXT1.11
ENTITY Mux IS
PORT(a,b,c,d: IN std_logic_vector(3 DOWNTO 0); -- datové vstupy
s:
IN std_logic_vector(1 DOWNTO 0); -- výb rový vstup
x:
OUT std_logic_vector(3 DOWNTO 0)); -- výstup
END Mux;
ARCHITECTURE ArchMux OF Mux IS BEGIN
WITH s SELECT
x <= a WHEN "00",
b WHEN "01",
c WHEN "10",
d WHEN OTHERS;
END ArchMux;
Vyhrazené slovo OTHERS zde zastupuje všechny ostatní možné hodnoty výb rového
signálu. Není to jen hodnota "11". Syntaxe jazyka vyžaduje, aby byly zastoupeny i další
hodnoty p ípustné u typu std_logic_vector, jako "1X", "UU" a všechny další, celkem tedy
81 hodnot – možných variací dvou hodnot z devíti uvedených ve vý tu v definici typu
std_logic. Pro syntézu má ovšem význam jen hodnota "11" z t chto zastupovaných hodnot.
Vynecháme-li v deklaracích prom nnou d a nahradíme-li poslední ádek t la architektury
textem "----" WHEN OTHERS;, provede se minimalizace s využitím nedefinované hodnoty x
pro tyto hodnoty signálu s ke zjednodušení výsledku (to však platí jen pro systémy, které toto
využití podporují, nap íklad pro WARP).
Dalším zajímavým p íkladem je následující text popisující model detektoru hodnoty
signálu s rozsahem od -8 do +7 kódovaného zápisem v dvojkovém dopl ku:
ENTITY Detector IS
PORT(InSig: IN
bit_vector(3 DOWNTO 0);
Limit: OUT bit);
END Detector;
-- TXT1.12
ARCHITECTURE ArchDet OF Detector IS BEGIN
WITH InSig SELECT
Limit <= '1' WHEN "0110"|"0111"|"1000"|"1011"|"1010",
'0' WHEN OTHERS;
END ArchDet;
N které návrhové systémy dovolují nahradit vý et hodnot signálu InSig zápisem
Signál Limit zde má jedni kovou hodnotu, je-li signál InSig v absolutní hodnot roven íslu 6 nebo v tšímu.
"0110" TO "1010".
Vkládání komponent (component instantiation). Komponenty vložené do textu p i
strukturálním popisu jsou také druhem soub žných p íkaz . P íklad (TXT1.6) byl uveden
v ásti pojednávající o tomto stylu. Další informace budou uvedeny v kapitole pojednávající o
hierarchii.
Procesy jako celky p edstavují také soub žné p íkazy. asto se uvádí, že soub žné
jednoduché p i azovací p íkazy jsou zjednodušeným zp sobem zápisu procesu. Toto tvrzení
vychází z postupu p i simulaci, který je u obou uvedených konstrukt v podstat shodný.
24
1.4.4 Sekven ní p íkazy
Tyto p íkazy se používají v procesech, ve funkcích a v procedurách. P ipome me, že
proces jako celek p edstavuje soub žný p íkaz, tj. nezáleží na po adí, v n mž jsou jednotlivé
procesy a další soub žné p íkazy v kódu uvedeny. P íkazy uvnit procesu však mají sekven ní
charakter a jejich po adí ovliv uje výsledek procesu. Nezam ujte je s modelováním sekvenních obvod ! Pomocí proces je možno modelovat kombina ní i sekven ní subsystémy.
P íkaz IF-THEN-ELSE je sekven ním prot jškem p íkazu WHEN-ELSE. Používá se k výb ru
skupiny p íkaz , která se má vykonat v závislosti na vyhodnocení podmínky, z n kolika
takových skupin. Zapisuje se podle vzoru:
IF
Podmínka_1 THEN Skupina_p íkaz _1
ELSIF Podmínka_2 THEN Skupina_p íkaz _2
ELSIF ...
... ... ... ... ... ...
ELSE
Skupina_p íkaz _n
END IF;
Je-li Podmínka_1 spln na, bude platit Skupina_p íkaz _1. V opa ném p ípad , je-li
spln na Podmínka_2, platí Skupina_p íkaz _2, atd. Syntaxe jazyka dovoluje zapsat tento
p íkaz i s jen jednou podmínkou a s odpovídající skupinou p íkaz , bez ástí ELSIF a ELSE.
Je-li v n které skupin p íkaz v p íkazu IF-THEN-ELSE p i azena ur itému signálu n jaká
hodnota, pak se v jazyku VHDL p edpokládá, že signál má mít tuto hodnotu až do nového
p i azení. Není-li v procesu, v n mž je p íkaz IF-THEN-ELSE zapsán, uvažovanému signálu
p i azena p ed tímto p íkazem jiná hodnota a není-li tomu tak ani v jiné jeho skupin p íkaz ,
vytvo í se syntézou procesu struktura záchytného klopného obvodu nebo registru (latch –
podrobn ji viz dále), jehož zapisovací signál je vytvo en z podmínky. To je významný rozdíl
od jiných jazyk , nap íklad od jazyka ABEL. Této skute nosti se íká implicitní pam .
Vznik záchytného klopného obvodu m že být nežádoucím d sledkem nepromyšlen
zapsaného kódu. K tomu m že snadno dojít, má-li p íkaz IF-THEN-ELSE jen skupinu p íkaz
bez ásti ELSE a není-li v procesu p edtím p i azena signálu n jaká hodnota. Vytvo ení
nežádoucího záchytného registru m žeme snadno zabránit tím, že v procesu p ed p íkazem
IF-THEN-ELSE zapíšeme definici tzv. defaultních hodnot signál , které z stanou v platnosti,
pokud je tento p íkaz nezm ní, viz nap . text TXT1.3, nebo tím, že uvedeme ást ELSE s p i azením opa né hodnoty tomuto signálu (TXT1.2).
P íklad procesu s p íkazem IF-THEN-ELSE – popis modelu multiplexoru:
PROCESS (a,b,c,d,s) BEGIN
IF
s = "00" THEN x <=
ELSIF s = "01" THEN x <=
ELSIF s = "10" THEN x <=
ELSE
x <=
END IF;
END PROCESS;
-- TXT1.13
a;
b;
c;
d;
Tento text by bylo možno p epsat s defaultním p i azením pro signál x takto:
PROCESS (a,b,c,d,s) BEGIN
x <= d;
IF
s = "00" THEN x <= a; ELSIF -- ... atd. po THEN x <= c; END IF;
S p íkazy IF-THEN-ELSE se setkáme velmi asto p edevším p i modelování synchronních
sekven ních subsystém , jako jsou registry, íta e a stavové automaty. P íklady budou
uvedeny v kapitole pojednávající o t chto subsystémech.
25
P íkaz CASE-WHEN je dalším ze sekven ních p íkaz používaných v procesech. Je to
sekven ní prot jšek p íkazu WITH-SELECT-WHEN. Jeho syntaxe je:
CASE Výb rový_výraz IS
WHEN Hodnota_1_výb rového_výrazu => Skupina_p íkaz _1
WHEN Hodnota_2_výb rového_výrazu => Skupina_p íkaz _2
... ... ...
WHEN Hodnota_n_výb rového_výrazu => Skupina_p íkaz _n
Všechny možné hodnoty výb rového výrazu musí být uvedeny, a to jen jednou. P íkazy
CASE-WHEN se používají nej ast ji p i modelování stavových automat . P íklady jejich použití
jsou uvedeny v p íslušné kapitole.
1.4.5 Modelování pam ových prvk pomocí p íkaz IF-THEN-ELSE
Pam ovými prvky rozumíme klopné obvody nebo registry, které mohou být ízeny
staticky nebo hranou ídicího (hodinového) signálu. Registrem se v eském vyjad ování
obvykle ozna uje soubor n kolika klopných obvod se spole nými ídicími signály. Staticky
ízené klopné obvody i registry se v angli tin obvykle ozna ují slovním spojením
transparent latch nebo stru n latch, obvody ízené hranou (jednoduché klopné obvody i
registry) se pak nazývají register. Je zde tedy ur ité p ekrytí významu.
Oba tyto obvody mohou být ze syntaktického hlediska správn popsány více zp soby. U
behaviorálních model ur ených k syntéze je však vhodné používat ur ité standardní zp soby
popisu – šablony (template), pro které jsou ve v tšin návrhových systémech zabudovány
mechanismy rozpoznání (inferencing) t chto blok a které zajistí jejich správnou syntézu a
implementaci. U klopných obvod typu D ízených staticky je p i implementaci t eba bu
použít zvláš k tomu ur ených strukturních prvk vytvo ených na ipu, nebo p i jejich
vytvo ení v programovatelném poli je nezbytné zajistit zachování konsensu (termu
odstra ujícího hazard), což p i jiných zp sobech popisu nemusí být zajišt no. Dob e
zpracovaný systém zajistí vytvo ení správn fungujícího obvodu i bez nutnosti zásahu
konstruktéra pro zachování konsensu. Pro obvody ízené hranou se prakticky používají pouze
speciální strukturní bloky. Proto je d ležité seznámit se s dokumentací systému, který
používáme – zp soby popisu rozpoznávané systémem bývají zpravidla uvedeny jako šablony
nebo v nápov d , takže jsou snadno dostupné p i zapisování kódu.
I když mohou být v rozpoznávání uvedených blok mezi r znými návrhovými systémy
ur ité rozdíly, lze íci, že tém všechny tyto systémy jsou správn schopny zpracovat texty,
které nyní uvedeme. Tyto texty jsou založeny na použití procesu s p íkazem IF-THEN, který
neobsahuje ást ELSE. Není-li v tomto p íkazu spln na podmínka, z stává hodnota signálu i
prom nné v obvodu zachována (implicitní pam ), což je práv požadovaná funkce.
Pro staticky ízený klopný obvod typu D, do n jž se vstupní signál Din zapisuje b hem
jedni kové hodnoty ídicího signálu Gate, m žeme použít následující popis (viz také odst.
3.2.2):
PROCESS (Gate, Din) BEGIN
IF Gate = '1' THEN Dout <= Din;
END IF;
END PROCESS;
Klopný obvod ízený vzestupnou hranou se nej ast ji popisuje s využitím atributu
který p edstavuje zm nu hodnoty signálu. Uvedeme text modelující osmibitový
registr, který se od textu pro jednoduchý klopný obvod liší jen deklarací brány vstupního a
výstupního signálu, p i emž popis architektury je v obou p ípadech stejný:
'event,
26
LIBRARY ieee;
ENTITY Reg_d IS
PORT(d:
IN std_logic_vector(7 DOWNTO 0); -- vstup
q:
OUT std_logic_vector(7 DOWNTO 0); -- výstup
Clk: IN std_logic);
END Reg_d;
ARCHITECTURE AttrEvent OF Reg_d IS BEGIN
PROCESS (Clk) BEGIN
IF (Clk'event AND Clk = '1') THEN
q <= d;
END PROCESS;
END AttrEvent;
-- TXT1.14
END IF;
Popis vychází z p edstavy, že se p i simulaci testuje, zda v sou asném simula ním kroku je
hodnota signálu Clk odlišná od hodnoty v p edcházejícím kroku, a pokud tomu tak je, má
výraz Clk'event jedni kovou hodnotu. Jde-li o vzestupnou hranu, je i hodnota signálu Clk
v tomto kroku jedni ková a podmínka pro p i azení je spln na. Registr ízený sestupnou
hranou se popisuje stejn s tím, že se testuje, zda je hodnota signálu Clk nulová. V seznamu
citlivosti procesu je jen signál Clk, protože ostatní signály (zde d) výstup registru p ímo
neovliv ují.
Má-li registr mít asynchronní vstup (nulovací a podobn ), musí se p íslušný asynchronní
signál objevit v deklaraci entity a do seznamu citlivosti procesu je nutno tento signál doplnit
k hodinovému signálu. Je-li nap íklad asynchronní nulovací signál ozna en identifikátorem
ARst, bude mít za átek popisu architektury zn ní:
ARCHITECTURE AttrEventR OF Reg_d IS BEGIN
PROCESS (Clk,ARst) BEGIN
IF ARst = '1' THEN q <= '0';
ELSIF (Clk'event AND Clk = '1') THEN q <= d; ...
–- žádné ELSE!
P íklad synchronního nulování je uveden v kapitole o stavových automatech.
Jiný používaný zp sob modelování téhož obvodu ízeného hranou spo ívá v použití funkcí
rising_edge nebo falling_edge definovaných ve sloze std_logic_1164. Pracujeme-li se
signály typu std_logic, musíme p ed deklarací entity uvést odkaz na tuto slohu, takže jsou
dostupné i uvedené funkce:
ARCHITECTURE FuncRisingEdge OF Reg_d IS BEGIN
PROCESS (Clk) BEGIN
IF rising_edge(Clk) THEN q <= d; ... –- žádné ELSE!
Zápis IF (Clk'event AND Clk ='1') THEN... je nahrazen textem IF rising_edge(Clk)
THEN..., jinak vše z stává beze zm ny. Z hlediska syntézy jsou oba tyto zp soby popisu
ekvivalentní. Popis využívající atribut 'event nevyžaduje volání funkce a používá se ast ji.
Ob as se setkáme i s jinými zp soby popisu klopných obvod , které patrn byly
vyžadovány n kterými staršími návrhovými systémy. V dnešní dob však p edstavují spíše
výjimky, které nemusí u sou asných systém vést ke správnému výsledku syntézy.
1.5 VYTVÁ ENÍ HIERARCHICKÝCH MODEL V JAZYKU VHDL
Jazyk VHDL poskytuje možnosti pro modelování složitých íslicových systém , které
mají hierarchickou stavbu. P i vytvá ení modelu se takový systém rozd lí na díl í bloky,
jejichž popis je snadn ji zvládnutelný a p ehledn jší, a které m žeme samostatn odladit
(simulovat). Tyto bloky bývá nej ast ji vhodné popsat behaviorálním stylem, není to však
nezbytné. Jejich propojení se pak popíše strukturálním stylem. Tak vznikne hierarchická
27
struktura modelu. Ta bývá v nejjednodušším p ípad dvoustup ová. Není ale vylou eno
použít i více stup
hierarchie, pokud to je ú elné. Pak bývají bloky nejnižší úrovn
modelovány behaviorálním stylem a ve vyšších hierarchických stupních se užívá styl
strukturální. P íliš mnoho hierarchických stup však m že vést k nep ehlednosti modelu.
Jako p íklad uvedeme popis modelu známého zapojení osmibitového asynchronního
binárního íta e, který je vytvo en jako kaskáda klopných obvod typu T, na jejichž vstupy je
p iveden konstantní signál logické jedni ky, takže každý tento obvod d lí sv j hodinový
signál dv ma. Hodinový vstup každého klopného obvodu je p ipojen na výstup
p edcházejícího, hodinový vstup prvního klopného obvodu je vstupem íta e. V tomto
zapojení ítá íta zp t, drobnou úpravu zapojení pro získání íta e ítajícího vp ed
ponecháme jako cvi ení tená i.
Model íta e m že být fyzicky roz len n do dvou soubor , které budou tvo it
dvoustup ovou hierarchickou strukturu. V prvním z nich je behaviorálním stylem popsán
klopný obvod typu T (TXT1.15 – entita T_ff) p edstavující základní prvek íta e jako
nejnižší stupe hierarchie.
LIBRARY ieee;
ENTITY T_ff IS
PORT(Tin,Clk: IN
std_logic;
Qout:
BUFFER std_logic);
END T_ff;
-- TXT1.15
ARCHITECTURE T_ff_arch OF T_ff IS BEGIN
PROCESS (Clk) BEGIN
IF (Tin = '1') THEN Qout <= NOT Qout;
END IF;
END PROCESS;
END T_ff_arch;
END IF;
V textu TXT1.16, který zde p edstavuje druhou (nejvyšší) hierarchickou úrove , je uveden
strukturální popis íta e. V popisu architektury je nejprve deklarována komponenta T_ff. To
je nutné, aby do následujícího strukturálního popisu mohla být tato komponenta n kolikanásobn vložena. Deklarace komponenty je formáln velmi podobná deklaraci p íslušné
entity. Její vložení zajiš ují v textu TXT1.16 p íkazy PORT MAP s navazujícím p i azením
skute ných signál v íta i (a, ClkIn a q(0) až q(6), q(0) až q(7)) signál m lokálním (Tin,
Clk, Qout) vyskytujícím se v popisu komponenty T_ff – klopného obvodu. Vstupním
signálem klopných obvod je zde konstantní signál a. Zp sob p i azení uvedený v p íkladu se
nazývá p i azení vyjmenováním (named association), kdy jsou vyjmenovány signály lokální
a každému je za znakem => p i azen signál skute ný, je však možno použít i stru n jšího
p i azení pozi ního (positional association), u n hož se uvedou jen skute né signály v poadí, v n mž jsou uvedeny v deklaraci komponenty. Má-li komponenta výstupy, které se
nepoužívají v jednotce, do níž je komponenta vložena, ozna í se tyto výstupy místo
skute ných signál , které by jim jinak byly p i azeny, klí ovým slovem OPEN. P íkladem
m že být íta využívaný ve funkci d li e kmito tu, u n hož se využívá jen výstup nejvyššího
bitu. Viz také text TXT3.1.4b.
LIBRARY ieee;
ENTITY AsynCnt IS
PORT(ClkIn: IN
std_logic;
q:
BUFFER std_logic_vector(7 downto 0));
END AsynCnt;
28
-- TXT1.16
ARCHITECTURE AsCntGen OF AsynCnt IS
COMPONENT T_ff
PORT(Tin,Clk: IN
std_logic;
Qout:
BUFFER std_logic);
END COMPONENT;
SIGNAL a: std_logic := '1';
BEGIN
Tff0: T_ff PORT MAP (Tin=>a, Clk=>ClkIn,
Tff1: T_ff PORT MAP (Tin=>a, Clk=>q(0),
... ... ...
END AsCntGen;
Qout=>q(0));
Qout=>q(1));
Qout=>q(2));
Qout=>q(7));
Odlad né a zkompilované bloky, kterými mohou být popisy entit a odpovídajících
architektur, slohy obsahující deklarace komponent, typ a podobn si uživatel m že uschovat
v knihovnách (library). Jazyk VHDL nep edepisuje ur itý zp sob fyzické realizace
knihoven, ten je zvolen až p i každé konkrétní implementaci jazyka v návrhovém systému.
M že to být nap íklad adresá (directory), který obsahuje soubor se seznamem prvk
knihovny a další soubory s t mito prvky.
Každý návrhový systém obsahuje p eddefinovanou knihovnu ozna enou work. Do ní se
ukládají prvky, na nichž uživatel práv pracuje. Tato knihovna je implicitní, tj. pokud se
nespecifikuje práce s jinou knihovnou, pracuje se s touto. Pokud chceme využívat prvky jiné
knihovny, musíme ji u init viditelnou (visible) pomocí klauzule LIBRARY. Tato klauzule
uvedená p ed popisem entity u iní p íslušnou knihovnu viditelnou v tomto popisu a v p idružených popisech architektury. Do knihovny work umis ují návrhové systémy automaticky
n které slohy – nap . WARP tam umístí slohu std_arith a n které další, které umož ují
pracovat s obvody PLD a FPGA firmy Cypress. Tyto další slohy nemusí být fyzicky umíst ny
v adresá i, který je vytvo en vždy p i vytvo ení knihovny work, ale v této knihovn jsou pak
na n dostupné odkazy. Návrhové systémy dále obsahují standardn knihovnu ieee, ve které
je obsažena sloha std_logic_1164 a n které další. Typy std_logic, std_logic_vector
atd. deklarovaných v této sloze m žeme použít, jestliže je zviditelníme klauzulí USE, jak to již
bylo uvedeno ve v tšin p íklad .
Prvky hierarchické struktury nižší úrovn zkompilované v knihovn work nebo nacházející
se ve slohách v jiných knihovnách zviditeln ných klauzulemi LIBRARY a USE pak deklarujeme
v textu popisujícím vyšší hierarchickou úrove modelu jako komponenty, p ípadn tato
deklarace m že být ve sloze, kterou musíme v tomto textu zviditelnit uvedeným zp sobem.
Deklarace komponent popisuje jejich propojovací prost edky – brány, pomocí nichž
propojíme komponenty ve vyšší hierarchické úrovni strukturálním stylem.
Standard VHDL-93 dovoluje zjednodušení zvané p ímé vkládání entity (direct entity
instantiation): p i n m není nutno deklarovat komponentu (v textu TXT1.16 odpadá tu n
psaný úsek mezi slovy COMPONENT a END COMPONENT), a za p edpokladu, že entita T_ff je
zkompilována v knihovn work, m žeme vložení prvního klopného obvodu popsat takto:
Tff0: ENTITY work.T_ff PORT MAP (Tin=>a, Clk=>ClkIn, Qout=>q(0));
a podobn i pro další klopné obvody. Vložení entity je tak formáln zcela analogické
používání podprogram v programovacích jazycích. Klí ové slovo COMPONENT se pak v textu
v bec nevyskytuje. Z d vod návaznosti na standard VHDL-87 se však v anglických textech
i v tomto p ípad
asto setkáme s ozna ením tohoto postupu jako p ímé vkládání
komponenty (direct component instantiation).
29
Prvky propojované do výsledného celku v textu nejvyšší úrovn m žeme do konstrukce
vkládat p ímým vložením entit (to není ješt možné ve standardu VHDL-87) nebo jejich
vložením pomocí komponent. Použití komponent, které je pon kud složit jší, umož uje v tší
variabilitu ve vytvá ení struktury modelu pomocí konfigurací (configurations). Konfigurace
se používají standardn p i simulaci, nejsou však obvykle podporovány nástroji pro syntézu.
Pokud není popis konfigurace modelu explicitn uveden, p edpokládá se platnost tzv.
implicitních pravidel pro vazbu mezi komponentami vloženými do architektury modelu a
entitami, které jsou pro systém k dispozici (tj. zhruba e eno, které jsou popsány v souborech
pat ících k projektu nebo jsou deklarovány zde nebo v knihovnách, které byly zviditeln ny a
jejich zkompilované popisy jsou v knihovnách p ítomny). Implicitní pravidla p i azují
komponent užité v architektu e entitu, která má stejný název a stejné brány.
Popis konfigurace se m že za lenit do architektury, v níž jsou deklarovány p íslušné
komponenty (pak mluvíme o specifikaci konfigurace – configuration specification), nebo
m že p edstavovat samostatnou jednotku, která se za adí do projektu (pak jde o deklaraci
konfigurace – configuration declaration).
Ve strukturálních modelech se jako základní prvky mohou používat zkompilované bloky
dodávané výrobci cílových obvod , které jsou optimalizované pro ur itý obvod ( íká se jim
parametrizované moduly a podobn ). Pro ur itou funkci je možno použít r zné tyto moduly
zam ené na r zné cílové obvody. P i zm n typu cílového obvodu je nutno takový blok
nahradit blokem platným pro nový obvod. To je možno provést úpravou popisu v p íslušné
úrovni hierarchie a novou kompilací celého modelu, nebo zm nou konfigurace a kompilací
jen této konfigurace. Pomocí konfigurace je také možno ur ité deklaraci entity p i adit r zné
popisy její architektury.
Jako p íklad použití konfigurací uvedeme strukturální popis s íta ky vycházející z klasického zapojení dvou p ls íta ek a sou tového lenu, jak je uvád no v u ebnicích íslicové
techniky. Na obr. 1.1(a) je znázorn na entita FullAdd p edstavující s íta ku. P edpokládáme,
že v knihovn work je zkompilována entita HalfAdd p edstavující p ls íta ku – obr. 1.1(b) –
se dv ma p i azenými architekturami, jedna z nichž je ozna ena identifikátorem Behavioral
a druhá Structural. V další knihovn Hradla, která m že být vytvo ena uživatelem nebo
dodána výrobcem obvod PLD, je zkompilována entita Lpo2 s architekturou Beh_Or. Vstupy
a výstup této entity jsou v knihovn Hradla ozna eny i1, i2 a z, jak je nazna eno na obr.
1.1(c). Ta je užita jako komponenta Or_2 v architektu e FullAddArch a ozna ení jejích
vývod zm n no na a, b, c podle obr. 1.1(d) pomocí klauzule PORT MAP. Specifikací
konfigurace je vybrána pro vložení p ls íta ky H1 architektura Behavioral a pro vložení H2
architektura Structural. Výsledné zapojení s íta ky je nakresleno na obr. 1.2.
Pro p ls íta ku HA, obr. 1.1(b) platí:
Sum = a ⊕ b, Cy = a · b.
Není obtížné dokázat, že zapojení podle obr. 1.2 p edstavuje úplnou s íta ku.
Cin
In1
In2
FA
(a)
Sum
a
Cout
b
HA
(b)
Sum
i1
Cy
i2
1
(c)
z
a
1
b
c
(d)
Obr. 1.1. Úplná s íta ka FullAdd (a) a její komponenty – p ls íta ka HalfAdd (b)
a sou tový len Or_2 (c,d)
30
H2
HA
Cin
In1
HA
In2
s1
Sum
s3
1
s2
H1
Cout
O1
Obr. 1.2. Struktura úplné s íta ky FullAdd
Popis s íta ky p edstavuje následující text:
LIBRARY ieee; LIBRARY Hradla;
ENTITY FullAdd IS
PORT(In1,In2,Cin: IN std_logic;
Sum,Cout:
OUT std_logic;
END FullAdd;
-- TXT1.17
ARCHITECTURE FullAddArch OF FullAdd IS
-- deklarace komponent -----COMPONENT HalfAdd
PORT(a,b:
IN std_logic;
Sum,Cy: OUT std_logic;
END COMPONENT;
COMPONENT Or_2
PORT(a,b: IN std_logic;
c:
OUT std_logic);
END COMPONENT;
SIGNAL s1,s2,s3: std_logic;
-- deklarace signál
-- specifikace konfigurace architektury FullAddArch -----FOR H1: HalfAdd USE ENTITY work.HalfAdd(Behavioral);
FOR H2: HalfAdd USE ENTITY work.HalfAdd(Structural);
FOR O1: Or_2 USE ENTITY Hradla.Lpo2(Beh_Or) PORT MAP(i1=>a,i2=>b,z=>c);
-- t lo architektury FullAddArch - vložení komponent -----BEGIN
H1: HalfAdd PORT MAP(a=>In1,b=>In2,Sum=>s1, Cy=>s2);
H2: HalfAdd PORT MAP(a=>Cin,b=>s1, Sum=>Sum,Cy=>s3);
O1: Or_2
PORT MAP(a=>s3, b=>s2, c =>Cout);
END FullAddArch;
Význam jednotlivých ástí specifikace konfigurace:
H1, H2, O1 – náv ští pro vkládané komponenty,
HalfAdd, Or_2 – název vkládané komponenty deklarované v deklarativní ásti architektury,
work, Hradla – knihovna, kde se nachází zkompilovaná entita uvedená za te kou,
HalfAdd, Lpo2 – název entity,
Behavioral, Structural, Beh_Or – použitá architektura.
Tu n vypsanou ást, tj. specifikaci konfigurace architektury FullAddArch, je možno
z jejího popisu vypustit a její konfiguraci popsat deklarací konfigurace, která bude za len na
do projektu jako zvláštní jednotka. Ta m že být samostatn zkompilována a uložena v knihovn , a p i její p ípadné modifikaci není t eba kompilovat jiné jednotky, což je výhodné
zejména p i simulaci rozsáhlých konstrukcí. Deklarace konfigurace tomu odpovídající je
uvedena v následujícím textu, kde je navíc p íkaz pro každou komponentu zakon en klauzulí
END FOR:
31
CONFIGURATION ConfigAdd OF FullAdd IS
-- TXT1.18
FOR FullAddArch
-- identifikátor konfigurované architektury
FOR H1: HalfAdd USE ENTITY work.HalfAdd(Behavioral); END FOR;
FOR H2: HalfAdd USE ENTITY work.HalfAdd(Structural); END FOR;
FOR O1: Or_2 USE ENTITY Hradla.Lpo2(Beh_Or) PORT MAP(i1=>a,i2=>b,z=>c);
END FOR;
END FOR;
END ConfigAdd;
S íta ka popsaná v textu TXT1.17 a TXT1.18 je samoz ejm jen školní p íklad hierarchické
konstrukce. Ve skute nosti se architektura této s íta ky m že v jazyku VHDL popsat
mnohem jednodušším zp sobem, jak to bylo uvedeno nap íklad v textu TXT1.9, který navíc
m že p edstavovat vícebitovou s íta ku.
1.6 PROST EDKY JAZYKA VHDL PRO ÚSPORNÝ ZÁPIS KÓDU
Jazyk VHDL obsahuje prost edky, jejichž využitím je možno zapsat popis modelovaných
subsystém s ur itou obecností a v konkrétních p ípadech zp esnit jejich implementaci
jednoduchým zadáním íselné hodnoty parametr a podobn . Sem pat í konstrukty, které
umož ují vytvo it strukturu v kódu VHDL se stejnou funkcí jako má ur itá posloupnost
p íkaz , kterou je možno vygenerovat n jakým algoritmem. Tato struktura však m že být
zapsána stru n ji a umož uje prakticky libovoln zvolit délku nahrazované posloupnosti
p íkaz pouhým stanovením ur ité íselné konstanty.
P íkazy skupiny GENERATE. Tyto p íkazy se používají pro úsporný zápis soub žných
p íkaz . Formou p íkladu zde uvedeme p íkaz FOR-IN-TO-GENERATE. Tento p íkaz je asto
užite ný p i použití strukturálního stylu, zejména u datových struktur s velkou bitovou ší kou,
kde je nutno vkládat opakovan tytéž komponenty, m že však být použit i jinde.
Text p edstavující vrcholovou úrove popisu asynchronního íta e z p edcházející kapitoly
žeme s využitím p íkazu GENERATE zapsat stru n ji. Zapojení prvního klopného
obvodu se od dalších liší tím, že jeho hodinový vstup p edstavuje vstup íta e, zatímco
hodinové vstupy dalších klopných obvod jsou p ipojeny k výstup m p edcházejících. Proto
bude vložení prvního tohoto obvodu provedeno zvláštním p íkazem, zatímco zbývajících
sedm je popsáno p íkazem FOR-IN-TO-GENERATE s pomocnou prom nnou i. Tu není nutno
zvláš deklarovat, pokud se používá uvedeným zp sobem v p íkazu FOR-IN-TO-GENERATE.
P ed p íkazem GENERATE musí být uvedeno náv ští (g1 v následujícím textu):
(TXT1.16) m
Tff0: T_ff PORT MAP (Tin=>'1', Clk=>ClkIn, Qout=>q(0));
g1: FOR i IN 0 TO 6 GENERATE
Tff: T_ff PORT MAP (Tin=>'1', Clk=>q(i), Qout=>q(i+1));
END GENERATE;
Je zde využito zjednodušení ze standardu VHDL-93, dovolující zapsat v p íkazu PORT MAP
výrazy, tedy i konstanty jako '1', takže není nutno deklarovat signál a. Nepravidelnosti v jednotlivých p íkazech vytvá ených p íkazem FOR-IN-TO-GENERATE mohou být ošet eny
podmín ným p íkazem IF-GENERATE. V uvedeném p íkladu m že být první vložení
komponenty zahrnuto do struktury p íkazu FOR-IN-TO-GENERATE takto:
BEGIN
g: FOR i IN 0 TO 7 GENERATE
g0: IF i = 0 GENERATE
TFF0: T_ff PORT MAP (Tin=>'1', Clk=>ClkIn,
END GENERATE g0;
32
Qout=>q(0));
g1: IF i > 0 GENERATE
Tff: T_ff PORT MAP (Tin=>'1', Clk=>q(i-1), Qout=>q(i));
END GENERATE g1;
END GENERATE g;
END AsCntGen;
Tento zápis sice není stru n jší, je však v n m celý cyklus vytvá ení struktury íta e
zahrnut do smy ky p íkazu FOR-IN-TO-GENERATE, takže m že být ve složit jších p ípadech
p ehledn jší. Výhodné je, že p i zm n bitové ší ky íta e sta í zm nit rozsah v p íkazu
smy ky. Tato výhoda je zvlášt patrná, je-li ší ka definována p íkazem GENERIC, který bude
uveden dále.
P íkaz IF-GENERATE má tvar p ipomínající sekven ní p íkaz IF-THEN-ELSE, je však
vhodné si uv domit, že je to p íkaz vytvá ející soub žnou strukturu. P íkazy GENERATE jsou
soub žnou formou smy ek, které budou popsány dále. Mohou obsahovat jakékoli soub žné
p íkazy, tedy i procesy, vložení komponent, další vno ené p íkazy GENERATE apod. Jsou tedy
obecn jší než smy ky. Podrobnosti lze najít nap . v literatu e [2], [4], [7].
P i zápisu sekven ních p íkaz uvnit proces je asto možné dosáhnout podobné úspory
použitím smy ek (loop). Smy ky mohou být typu for nebo typu while. Mohou, ale nemusí
být ozna eny náv štím, jak uvidíme dále. Jako p íklad si uve me zápis p edstavující
asynchronní nulování pole registr o osmi prvcích, z nichž každý má 9 bit . Pole m že sloužit
nap íklad jako pam ová struktura typu FIFO nebo LIFO (po dopln ní výstupních a ídicích
bran a p íslušných ídicích obvod ):
LIBRARY ieee;
ENTITY RegArray IS
PORT(Clk,Rst: IN std_logic;
D_in:
IN std_logic_vector(8 DOWNTO 0));
END RegArray;
-- TXT1.19
-- vstup
ARCHITECTURE Arch_rarr OF RegArray IS
TYPE RegArr IS ARRAY(7 DOWNTO 0) OF std_logic_vector(8 DOWNTO 0);
SIGNAL Registers: RegArr;
-- pole osmi devítibitových registr
BEGIN
PROCESS (Clk,Rst,D_in) BEGIN
IF Rst = '1' THEN
FOR i IN 1 TO 7 LOOP
RegArr(i) <= (OTHERS => '0');
-- asynchronní nulování
END LOOP;
ELSIF (Clk'event AND Clk = '1') THEN
-- ... ... ... (popis synchronního pln ní a další funkce registr )
END IF;
END PROCESS;
END Arch_rarr;
Podobn jako u p íkazu FOR-IN-TO-GENERATE, prom nná i je deklarována automaticky.
Místo smy ky typu for m žeme použít smy ku typu while:
PROCESS (Clk,Rst,D_in)
VARIABLE i: integer;
BEGIN
i := 0;
IF Rst = '1' THEN
WHILE i < 7 LOOP
i := i + 1;
END LOOP;
33
-- TXT1.20
-- asynchronní nulování
... ... ... (popis synchronního pln ní a další funkce registr )
END IF;
END PROCESS;
--
Zde je nutno prom nnou i deklarovat, inicializovat a inkrementovat. P ipome me, že
p i azovací p íkazy u prom nných mají charakter bezprost edního p i azení (immediate
assignment) na rozdíl od p i azovacích p íkaz užívaných v procesu pro signály (scheduled
assignment), a zna í se také odlišným p i azovacím operátorem (:=). N které systémy jako
WARP vyžadují, aby tato prom nná byla inicializována uvnit p íkazové ásti procesu, tedy
mezi klí ovými slovy BEGIN a END v procesu, jiné dovolují inicializaci v jeho deklara ní ásti
stru n ji zápisem
VARIABLE i: integer := 0;
Nemají-li se p íkazy ve smy ce provést pro všechny hodnoty pomocné prom nné, m žeme
použít k ukon ení ur itého pr b hu smy kou podmín ného p íkazu NEXT:
PROCESS (Clk,Rst,D_in) BEGIN
-- TXT1.21
IF Rst = '1' THEN
NEXT WHEN i = 4;
-- vynech 4. registr
-- ostatní nuluj
END LOOP;
-- ... ... ... (popis synchronního pln ní a další funkce registr )
END IF;
END PROCESS;
Smy ky mohou být vno ovány do sebe (nested). V tomto p ípad je možno jednotlivé
smy ky ozna it náv štím a v p íkazech NEXT, jsou-li použity, pak uvést, která smy ka se jimi
ukon uje:
s1: WHILE i < 10 LOOP
s2: WHILE i < 10 LOOP
-- ... ... ... (p íkazy)
NEXT s2 WHEN i = j;
-- ... ... ... (p íkazy)
END LOOP s2;
END LOOP s1;
Smy ky pat í ke konstrukt m ve VHDL, u nichž se v sou asné dob mohou projevit ur ité
rozdíly p i zpracování r znými systémy. P i jejich použití je proto vhodné ov it si, jak s nimi
nakládá systém, s nímž pracujeme.
K prost edk m pro úsporný zápis kódu m žeme také po ítat tzv. parametrizované
komponenty, u nichž je n který rys (nap íklad bitová ší ka registru) definován parametrem,
jehož íselná hodnota se zadává až p i vložení komponenty do jednotky vyšší hierarchické
úrovn . Popis parametrizované komponenty je podobný popisu jakékoliv jiné komponenty,
pouze s tím rozdílem, že ur itý rys, nap íklad bitová ší ka, je dána parametrem ozna eným
klí ovým slovem GENERIC. V následujícím textu (TXT1.22) je popsáno jako parametrizovaná
komponenta pole ty registr se ší kou zadanou generickým parametrem Width. Signál j
vybírá registr, do n hož se p i aktivní hran hodinového signálu zapisují data D_in a jehož
obsah je veden na výstup D_out. (Takové pole registr by patrn nem lo praktický smysl, ale
nevelké rozší ení, kdy místo jednoho výb rového signálu budou dva, jeden pro vstup a druhý
pro výstup, již smysl tomuto poli dává – ponecháme je na procvi ení tená i.)
34
Komponenty deklarované v popisu architektury jsou p ístupné jen uvnit této architektury.
Hlavní smysl parametrizovaných komponent je však v jejich použití jako stavebních prvk ve
vyšší hierarchické úrovni dalších konstrukcí. Výrobci obvod PLD a FPGA vytvá ejí pak pro
asto používané bloky (registry, íta e apod.) p eddefinované moduly optimalizované pro
p íslušnou strukturu cílových obvod . Deklarace t chto komponent se uvád jí ve slohách.
Jednotky deklarované ve slohách jsou pak p ístupné i pro další konstrukce. Popis architektury
t chto komponent pak m že být výrobcem dodán v knihovnách již ve zkompilovaném tvaru,
takže není pro uživatele p ístupný jinak než pro vložení zkompilované komponenty do
uživatelovy konstrukce.Uživatel tak nemá k dispozici zdrojový text pro tyto komponenty,
ímž si jejich auto i chrání své duševní vlastnictví (intelectual property).
Ve slohách mohou být krom komponent uvedeny i další jednotky, které pak m že
uživatel zp ístupnit klauzulí USE ve svých konstrukcích. Tak jsme se již setkali s definicemi
typ , nap íklad typu std_logic nebo std_logic_vector uvedených v knihovn IEEE ve
sloze std_logic_1164. Rovn ž asto se využívají funkce p edstavující p etížené operátory,
které jsou také obsaženy ve standardních slohách.
1.7 FUNKCE
Funkce v jazyku VHDL pat í ke konstrukt m vyšší úrovn a používají se p edevším v modelech ur ených pro simulaci. V textech dosud uvedených jsme se setkali s funkcemi, které
byly definovány ve slohách, které se dodávají spolu s návrhovým systémem. Byly to
p edevším funkce p et žující operátor s ítání, které jsou v systému WebPACK obsaženy ve
slohách std_logic_arith, std_logic_unsigned a std_logic_signed, umíst né v knihovn ieee (viz TXT1.8, kde je operátor s ítání p vodn definovaný pro signály typu
integer p etížen tak, aby umožnil jeho užití pro signál typu std_logic_vector). To je
nej ast jší použití funkcí v modelech ur ených k syntéze. Další obvyklá možnost použití
funkce byla nazna ena v diskusi k textu TXT1.23, kde šlo o p evod signálu j typu
std_logic_vector na signál Jint typu integer. Místo procesu Slv2int v tomto textu
m žeme v systému WARP použít funkce to_integer, která je obsažena ve sloze std_arith.
V tomto p ípad text uvedeného procesu nahradíme zápisem
Jint <= to_integer(j);
a sou asn do deklarativní ásti p idáme klauzuli
USE work.std_arith.ALL;
(p edpokládáme, že sloha std_arith je zkompilována v knihovn work).
Podívejme se nyní na zjednodušený text funkce to_integer z uvedené slohy. Syntaxe
zápisu funkce je z ejmá, takže se omezíme na poznámky vysv tlující význam jednotlivých
p íkaz .
FUNCTION To_integer (Arg: std_logic_vector) RETURN natural IS -- TXT1.24
CONSTANT Arg_left: integer := Arg'length - 1;
VARIABLE Xarg: std_logic_vector(Arg_left DOWNTO 0);
VARIABLE Result: natural := 0;
BEGIN
FOR i IN Xarg'range LOOP
Result := Result + Result;
IF Xarg(i) = '1' THEN Result := Result + 1;
END IF;
END LOOP;
RETURN Result;
END To_integer;
35
Funkce je uvedena klí ovým slovem FUNCTION následovaným identifikátorem funkce
(uvádíme jej s velkým po áte ním písmenem, protože nejde o p esnou verzi této
funkce z uvedené slohy; ta obsahuje ješt navíc kontrolu, zda argument není prázdný a zda
neobsahuje jiné symboly než 0 a 1). V závorce je pak uveden identifikátor vstupního
parametru Arg, za nímž je uveden jeho typ. Za závorkou následuje klí ové slovo RETURN, za
nímž je uveden typ výsledku. (P ipome me, že natural je subtyp typu integer.) Dále je
definována konstanta Arg_left a prom nná Xarg pomocí atribut vstupního argumentu, aby
funkce mohla zpracovávat argumety r zné délky.
To_integer
Následující text mezi slovy BEGIN a END p edstavuje smy ku pro vlastní p evod. Klí ovým
slovem RETURN je ozna en výsledek funkce, kterým se nahradí její volání p i jejím použití.
Inverzní k popsané funkci je funkce to_std_logic_vector. Krom argumentu
p edstavujícího vstupní íslo obsahuje ješt druhý argument udávající ší ku výsledného
vektoru. Spolu s dále popsanou funkcí pro p etížení operátoru s ítání je tak jako funkce
to_integer obsažena ve sloze std_arith v systému WARP. Podívejme se nyní na p íklad
druhé asté aplikace funkcí v modelech ur ených k syntéze, a to p etížení operátoru s ítání
tak, aby akceptoval sou et signálu typu std_logic_vector a signálu typu natural, který
p edstavuje celé nezáporné íslo. Op t je uvedena funkce ze systému WARP:
FUNCTION "+" (Lft: std_logic_vector; Rgt: natural)
RETURN std_logic_vector IS
BEGIN
RETURN Lft + to_std_logic_vector(Rgt, Lft'length);
END "+";
-- TXT1.25
Zde jsou symbolem Lft a Rgt ozna eny vstupní argumenty. P ed touto funkcí je ve sloze
uvedena další funkce se stejným názvem, tj. "+", která p et žuje operátor s ítání
tak, aby akceptoval jako operandy dva signály typu std_logic_vector. Takto p etížený
operátor s ítání je nyní použit k vytvo ení sou tu operandu Lft a ísla Rgt p evedeného do
typu std_logic_vector funkcí to_std_logic_vector.
std_arith
Naskýtá se otázka, která funkce bude vlastn v konkrétním p ípad použití operátoru +
vyvolána, když více z nich má stejné ozna ení. Odpov zní tak, že p i kompilaci použije
systém tu funkci, která odpovídá nejen ozna ení, ale i operand m, k nimž je použita (pokud je
ovšem p etížení definováno a je-li p íslušná funkce viditelná).
V systému WebPACK jsou konverzní funkce pro p evod argumentu typu unsigned a
signed na typ integer ozna eny conv_integer a jsou obsaženy ve sloze
std_logic_arith, ve slohách std_logic_unsigned a std_logic_signed jsou funkce se
stejným názvem pro p evod argument typu std_logic_vector na typ integer. Pro zp tný
p evod zde slouží funkce conv_std_logic_vector. Na typy unsigned a signed p evád jí
argumenty všech uvedených typ funkce s názvem conv_unsigned a conv_signed. Tyto
funkce mají dva argumenty, jeden p edstavuje p evád ný vektor a druhý, celo íselný, bitovou
ší ku výsledku. Je jich tedy také možno použít ke zm n bitové ší ky prvního argumentu.
Podrobný popis funkcí obsažených v aritmetických slohách (std_logic_arith,
numeric_std) je uveden nap íklad v [3].
P íkladem použití konverzní funkce pro vytvo ení indexu (typ integer) ze vstupního
signálu typu std_logic_vector v systému WebPACK je následující text popisující dekodér
t íbitového vstupního signálu na kód 1 z 8:
36
LIBRARY ieee;
-- TXT1.26
ENTITY Decoder IS
PORT(a,b,c,g: IN std_logic;
-- vstupy
y_n:
OUT std_logic_vector(7 DOWNTO 0)); -- inverzní výstup
END Decoder;
ARCHITECTURE DecodArch OF Decoder IS BEGIN
PROCESS (a,b,c,g) BEGIN
y_n <= (OTHERS => '1');
IF g = '1' THEN y_n(conv_integer(c&b&a)) <= '0'; END IF;
END PROCESS;
END DecodArch;
Funkce mohou mít jen vstupní operandy, tj. operandy nemohou být funkcí modifikovány.
Výsledkem funkce m že být jen jeden výstupní operand uvedený v definici funkce za
klí ovým slovem RETURN. V tomto smyslu m žeme funkci považovat za zobecn ní
p i azovacího p íkazu. V definici funkce nemohou být deklarovány signály, mohou tam však
být deklarovány prom nné. Jejich platnost je omezena na tuto definici. Zobecn ním funkcí
jsou procedury, jejichž popis m že tená najít ve specializované literatu e. P íklad procedury
bude uveden v ásti týkající se testování konstrukcí.
Seznámili jsme se s pravidly pro vytvá ení funkcí. V praxi se však v modelech ur ených
k syntéze používají p edevším funkce, které jsou p eddefinovány ve standardních slohách,
jako jsou std_logic_1164, std_logic_arith a podobn . Neznamená to, že si uživatel
nem že definovat své vlastní funkce, ale syntetizéry a simulátory bývají optimalizovány pro
užití sloh, které jsou dodávány jako ásti systému, a uživatelem definované funkce mohou být
p í inou, že se tato optimalizace mine ú inkem. Proto se doporu uje p ed užitím funkcí
seznámit se s funkcemi, které jsou dodávány jako p íslušenství systému. Bývají popsány
v manuálech spolu se slohami (packages). Vlastní funkci se doporu uje vytvo it v p ípad
pot eby až tehdy, není-li tam pot ebná funkce k dispozici.
2 POSTUP VYTVO ENÍ POPISU KONSTRUKCE
V JAZYKU VHDL
P i ešení úkolu spo ívajícího v návrhu složitého íslicového systému ( i subsystému) –
nap íklad procesoru, pam ového subsystému po íta e a podobn není asto možné celý
systém zpracovávat jako celek, protože jeho složitost se od ur itého stupn vymyká
možnostem konstruktéra podržet si v hlav vše, co je pot eba ke globálnímu a p itom
dostate n podrobnému pohledu na navrhovaný systém. Proto se postupuje obvykle tak, že se
po formulaci zadání snažíme celý systém rozd lit na díl í subsystémy, jejichž zpracování
(návrh, analýza atd.) je již jednodušší. V p ípad pot eby v d lení t chto subsystém na ješt
jednodušší ásti pokra ujeme, až se dostaneme na úrove složitosti, kdy je již podrobný návrh
jednotlivých ástí proveditelný. Vzniká tak hierarchická struktura. To je postup, který jsme
nazvali návrh shora dol , který z metodického hlediska p edstavuje ideální p ístup. Nez ídka
však musíme p i realizaci blok nejnižší úrovn vycházet z možností daných technologií
realizace systému (strukturálními zvláštnostmi použitých cílových obvod ), takže je nutno
výše stojící hierarchické bloky této technologii p izp sobit. Je pak nutno konstrukci procházet
obráceným sm rem – postup zdola nahoru. Promítnutí zm n vynucených zm nami na nízké
úrovni do vyšších úrovní hierarchie se íká zp tná anotace (back annotation).
37
asto se poda í rozd lit systém tak, aby bylo možno popsat bloky nejnižší úrovn
behaviorálním stylem nebo stylem p edstavující popis toku dat. Typickými subsystémy, které
se obvykle popisují behaviorálním stylem, jsou nap íklad:
∗ p evodníky kód , dekodéry, enkodéry,
∗ registry paralelní a sériové, íta e,
∗ jednodušší stavové automaty.
V poslední položce je slovo „jednodušší“ z toho d vodu, že tém všechny dnes používané
íslicové systémy je možno pokládat za stavové automaty a teoreticky je možné ešit je
odpovídajícími zp soby. Je-li však po et možných stav takového automatu v tší než n kolik
desítek, je obvykle p íliš obtížné p istupovat k n mu metodami užívanými pro práci se
stavovými automaty. Takové systémy se pak snažíme rozd lit na jednodušší ásti, jak bylo
popsáno výše.
Bloky popsané behaviorálním stylem je pak nutno vhodn propojit, jak to vyžaduje funkce
systému. Popis propojení takto vytvo ených blok (a samoz ejm nejen jich, ale jakýchkoliv
blok ) umož ují jazyky HDL pomocí strukturálního stylu. Tento popis odpovídá blokovému
schématu a je v podstat jeho textovým vyjád ením. Z hlediska snadnosti pochopení funkce
popisovaného bloku je strukturální styl popisu mnohem mén p ehledný než styl behaviorální,
a nutnost použít jej pro popis propojení ve vyšších úrovních hierarchie je možno v tomto
smyslu považovat za ur ité slabé místo jazyk HDL. Pro dokumentaci m že proto být
výhodné kombinovat textové formy popisu s formami grafickými, tabulkovými, p ípadn
s dalšími, které asto bývají pro popis struktury p ehledn jší než textový popis v jazyku HDL.
V jednodušších návrhových systémech je možno pracovat pouze s textovou formou popisu
a jeho grafickou formu je nutno vytvo it jiným zp sobem – v krajním p ípad ru n , je však
možno použít také r zných editor umož ujících práci s jednoduchými grafickými objekty.
P i zp tné anotaci je pak p irozen nezbytné vrátit se do p íslušného editoru a zde provést
p íslušné zm ny. Moderní složité návrhové systémy mají asto v sob zahrnuty prost edky
pro více r zných zp sob popisu, mezi nimi i pro grafické formy, a ty nejpokro ilejší jsou
schopny provád t automaticky i zp tnou anotaci. P íkladem je systém FPGA Advantage
firmy Mentor Graphics. Podstatné zde je, že takové systémy jsou schopny ke grafické form
popisu automaticky vygenerovat popis textový a naopak. (Je zde ur itá analogie s asemblery a
disasemblery mikropo íta .) Tím je zajišt na p enositelnost kódu (textové formy popisu)
mezi návrhovými systémy, která je dána standardy platnými pro jazyky HDL. Pro
dokumentaci pak mohou být výhodn použity ty formy popisu, které jsou nejp ehledn jší, i
když jejich p enositelnost mezi r znými systémy je omezená.
Typický postup návrhu má tyto fáze:
1. Popis (sub)systému vstupními prost edky návrhového systému, p ípadná kontrola
syntaxe.
2. Syntéza – vytvo ení modelu navrhovaného (sub)systému ve standardizovaném tvaru.
3. Implementace – vytvo ení podrobného popisu konfigurace cílového obvodu tak, aby
fungoval jako navrhovaný (sub)systém.
4. Simulace (sub)systému.
K bodu 1: Nejjednodušším prost edkem pro vytvo ení popisu jsou textové editory.
Návrhové systémy obsahují asto editory s n kterými speciálními vlastnostmi, které
usnad ují zápis zdrojového textu. Takovou vlastností bývá nap íklad zobrazení klí ových
slov a n kterých dalších prvk textu (konstant, komentá a podobn ) jinou barvou než
zobrazení základního textu, což umož uje snadno kontrolovat dodržení n kterých pravidel
38
syntaxe. Zápis textu bývá usnadn n použitím šablon (templates) n kterých jazykových
konstrukt . Pro zápis zdrojového textu je však možno použít prakticky libovolného textového
editoru, který umož uje vytvo ení „holého“ textu, tj. textu bez formátovacích znak , a tento
text pak dále zpracovávat stejn jako texty vytvo ené editorem návrhového systému. Pro
usnadn ní popisu složit jších strukturních prvk bývají asto v návrhových systémech bloky
zvané pr vodci (wizards), které zajiš ují, že vygenerované úseky kódu jazyka HDL jsou v
navazujícím zpracování (syntéza, implementace) správn rozpoznány. P íkladem je Xilinx
Architecture Wizard, který pro obvody FPGA ady Spartan-3 p i požadavku na zahrnutí bloku
DCM (Digital Clock Manager) do konstrukce generuje jeho popis.
Dokonalejší návrhové systémy umož ují užití n kterých grafických zp sob popisu, jako
jsou prost edky pro kreslení stavových diagram , pravdivostních tabulek a další, a poskytují
možnost automatického p evedení t chto zp sob popisu do jazyka HDL, pop ípad i zp tnou
anotaci. Tradi ní zp soby vytvá ení schémat v editorech, jako jsou OrCAD a podobn , jsou
zejména mezi staršími konstruktéry dob e známé a je asto možno využít jich pro p evod do
formátu, který jsou schopny zpracovat návrhové systémy. Výhodou je p edevším, že lze
využít dosavadních znalostí práce s editory schématu. P i simulaci konstrukce tímto
zp sobem popsané však je nutné pracovat se simulátory, které dokážou zpracovávat vstupní
informace v tomto formátu, které již nejsou tak b žné, nebo p evést tyto informace do
formátu (nap íklad do n kterého jazyka HDL), s nimiž mohou pracovat standardní simulátory.
To ovšem pak p edpokládá, že pro lad ní by m l mít konstruktér ur ité znalosti tohoto jazyka.
Jazyky HDL slouží také pro p enos informací mezi r znými návrhovými systémy. Mnoho
firem a dalších organizací proto požaduje po svých partnerech, aby zpracovávali dokumentaci
práv v jazycích HDL, v evropských firmách se žádá obvykle dokumentace v jazyku VHDL.
K bodu 2: Syntézou se rozumí p evod informace ze vstupního tvaru (textového i
grafického) do n kterého z forem, kterou mohou dále zpracovávat implementa ní nástroje.
Tak se vytvo í model navrhovaného (sub)systému, který obsahuje strukturní prvky
p edpokládané skupiny cílových obvod a jejich propojení (netlist). Provádí se programovým
nástrojem, kterému íkáme syntetizér. Velmi asto používaným formátem, v n mž syntetizéry
poskytují výsledky své innosti, je formát EDIF. P i syntéze se obvykle již provádí
optimalizace se zam ením na ur itou technologii, v níž bude dále navrhovaná konstrukce
realizována. Technologií se zde rozumí i struktura ur ité skupiny („rodiny“) cílových obvod ,
které asto obsahují vedle univerzálních struktur (struktury PAL, PLA apod.) i specifické
struktury umož ující zvýšení efektivnosti využití prost edk dostupných v obvodu (nap .
struktury pro alokaci a sdílení tem ) nebo podporující n které typy realizovaných operací
(s íta ky a další aritmetické obvody, komparátory a podobn ).
N kdy se p ed syntézou (nebo jako její sou ást) jako zvláštní krok provádí kompilace,
ímž se rozumí p evod vstupních informací do tvaru, který p edstavuje p edstupe syntézy –
nap íklad do zápisu tvaru SOP (sou et sou in ) a podobn . Také optimalizace se m že
provád t v rámci syntézy nebo jako zvláštní stupe zpracování, p ípadn m že být zahrnuta
do procesu implementace.
K bodu 3: P i implementaci se již vytvá í struktura odpovídající ur itému konkrétnímu
cílovému obvodu, který pat í do skupiny, pro niž byla provedena syntéza. Výsledkem
implementace bývá soubor, který obsahuje údaje pro naprogramování (personifikaci)
struktury cílového obvodu, nap íklad soubor JEDEC pro obvody PLD, i tzv. bitstream pro
obvody FPGA.
K bodu 4: Simulací si konstruktér ov uje, zda vytvo ený model navrhovaného
(sub)systému pracuje podle požadavk zadání.
39
3 P ÍKLADY KONSTRUKCÍ V JAZYKU VHDL
Zdrojové texty v jazyku VHDL byly ov ovány syntézou a simulací v n kolika systémech.
Byly to zejména systémy WARP 2 firmy Cypress, MAX+PLUS II firmy Altera,
ispDesignEXPERT firmy Lattice a WebPACK firmy Xilinx. Formáln se tyto systémy liší
mimo jiné názvem slohy, ve které je definováno p etížení aritmetických operátor pro jejich
použití na typ std_logic_vector: u systém WARP a MAX+PLUS II to je sloha std_arith
uvedená v knihovn ieee, u systém ISPDesignEXPERT a WebPACK se tato sloha nazývá
std_logic_unsigned a je rovn ž v knihovn ieee. Jak bylo uvedeno v ásti týkající se typ
a operátor , prosazuje se v poslední dob
tendence používat místo slohy
std_logic_unsigned, jejíž výskyt je zde nej ast jší, slohu std_logic_arith nebo slohu
numeric_std. Texty používající slohu std_logic_unsigned m žeme upravit na použití
n které z t chto dvou sloh tak, že argumenty typu std_logic_vector v operacích, pro n ž je
sloha pot ebná, p evedeme na typ unsigned nap íklad explicitní konverzí.
Také atributy sloužící k p i azení ísel vývod signál m a k potla ení syntézy signálu (k
rozvinutí zápisu do tvaru SOP s eliminací díl ích signál ) a p ípadn další detaily týkající se
možnosti použití n kterých jazykových konstrukt jsou v r zných systémech r zné. V textech
jsou uvedeny ty varianty, které odpovídaly systém m, na nichž byly texty ov ovány. P i
p echodu k jinému systému je nutno odpovídající ásti textu upravit.
Anotace jednotlivých p íklad
3.1.1 P evodník hexadecimálního kódu na kód sedmisegmentového displeje
Obecný p evodník kódu s náhodným vztahem mezi vstupními a výstupními kódovými slovy.
Hexadecimální zápis vstupních a výstupních signál . Použití atributu k p i azení signál
vývod m pouzdra cílového obvodu (WARP)
3.1.2 P evodník kódu BCD na binární kód
Použití aritmetických operátor . Srovnání výsledk implementace textu s operátory násobení
a textu s rozepsáním této operace na sou ty
3.1.3 S íta ka v kódu BCD
Dekadická korekce výsledku s ítání v binárním kódu. Nesprávné možnosti zápisu p i operaci
s ítání
3.1.4 P evodník binárního kódu na kód BCD
P íklad nesyntetizovatelného behaviorálního popisu p evodníku a jeho popis strukturálním
stylem
3.2.1 Subsystémy s t ístavovými výstupy a s otev eným kolektorem
P íklad multiplexoru s t ístavovým výstupem. Staticky ízený registr s obousm rnou bránou
3.2.2 Subsystémy s obousm rnými branami
P íklad registru se statickým ízením (latch) a s jednou obousm rnou datovou bránou
3.4.1 Binární íta e
Vratný íta s asynchronním i se synchronním nulováním a se synchronním napln ním
3.4.2 íta e pracující v kódu BCD
íta s vynulováním každé dekády nacházející se v nepracovním rozsahu
3.5 Stavové automaty
P íklady behaviorálního popisu a popisu s explicitním kódováním stav , synchronní nulování
40
3.1 KOMBINA NÍ OBVODY
3.1.1 P evodník hexadecimálního kódu na kód sedmisegmentového displeje
Jedna z asto používaných metod popisu kombina ních obvod v jazycích typu ABEL,
pravdivostní tabulka, nemá p ímý ekvivalent v jazyku VHDL. V tomto jazyku je však možno
odpovídající úlohy ešit jinými prost edky. Jednoduchý zp sob p edstavuje použití p íkazu
WITH-SELECT-WHEN. Jako p íklad uvedeme p evodník hexadecimálního kódu na kód
sedmisegmentového displeje:
LIBRARY ieee;
-- TXT3.1.1
ENTITY Hex2Sevn IS PORT
(r,s,t,u:
IN std_logic;
-- datové vstupy
g,f,e,d,c,b,a: OUT std_logic);
-- výstupy
ATTRIBUTE pin_numbers OF Hex2Sevn: ENTITY IS
-- ur eno pro WARP
"r:2 s:3 t:4 u:5 g:17 f:18 e:19 d:20 c:21 b:23 a:24"; -- pro 22v10 PLCC,
END Hex2Sevn;
-- package JC
ARCHITECTURE Truth_tb OF Hex2Sevn IS
SIGNAL InHex: std_logic_vector(3 DOWNTO 0);
SIGNAL OutSvn: std_logic_vector(7 DOWNTO 0);
BEGIN
InHex <= (r & s & t & u);
g <= OutSvn(6); f <= OutSvn(5); e <= OutSvn(4); d <= OutSvn(3);
c <= OutSvn(2); b <= OutSvn(1); a <= OutSvn(0);
WITH InHex SELECT
OutSvn <= X"40" WHEN X"0",
X"00" WHEN X"8",
X"79" WHEN X"1",
X"10" WHEN X"9",
X"24" WHEN X"2",
X"08" WHEN X"A",
X"30" WHEN X"3",
X"03" WHEN X"B",
X"19" WHEN X"4",
X"46" WHEN X"C",
X"12" WHEN X"5",
X"21" WHEN X"D",
X"02" WHEN X"6",
X"06" WHEN X"E",
X"78" WHEN X"7",
X"0E" WHEN OTHERS;
END Truth_tb;
P i azení vývod signál m pomocí atributu pin_numbers odpovídá nap íklad požadavk m
systému WARP. V jiných systémech m že být toto p i azení provedeno jinými prost edky.
Poslední hodnota X"0E" je p i azena všem kombinacím, které nejsou uvedeny d íve. Je to
nutné proto, že p íkaz WITH-SELECT-WHEN vyžaduje, aby byly vy erpány všechny možné
kombinace vstupních signál , a typ std_logic obsahuje krom hodnot '0' a '1' ješt další
hodnoty, jako 'U', 'X' atd. Klí ové slovo OTHERS zahrnuje všechny možné kombinace
složené i z t chto hodnot. Pro syntézu však mají význam jen hodnoty '0' a '1', což odpovídá
o ekávané hodnot X"F".
Aby bylo možno zapsat vstupní a výstupní signály hexadecimálním zápisem, jsou
deklarovány signály InHex a OutSvn. Hexadecimální zápis je možný jen pro skupiny bit ,
jejichž po et je násobkem ty , takže signál OutSvn je osmibitový, a jeho nejvyšší bit není
využit.
Kombinace vstupních signál , pro n ž u neúpln definovaných funkcí není zadána hodnota
na výstupu (v našem p ípad by to bylo p i p evodu kódu BCD na kód zobrazova e), mohou
být v textu uvedeny nap íklad zápisem
"--------" WHEN OTHERS;
41
Tento zápis však neinterpretují všechny návrhové systémy stejným zp sobem. N které
z nich, jako nap íklad WARP, skute n využijí nedefinované vstupní kombinace ke zjednodušení výsledku. Jiné však toto zjednodušení nevyužívají a místo hodnot '-' p i adí výstup m
nuly. Tato druhá interpretace platí u v tšiny sou asn používaných systém . N kdy je možno
uvedeného využití dosáhnout vhodným nastavením syntetizéru pomocí voleb („options“).
Text TXT3.1.1 p edstavuje p íklad zcela obecného p evodníku kódu. Pokud by tento
p evodník byl rozsáhlejší, bylo by snadné ud lat v zápisu chybu, která se pak dosti obtížn
hledá. Proto tam, kde je možno najít vyjád ení pro p evod kódu n jakým algoritmem, je asto
vhodn jší tento algoritmus využít k automatickému generování výstupních hodnot. P íkladem
m že být následující p evodník.
3.1.2 P evodník kódu BCD na binární kód
V následujícím textu (TXT3.1.2a) je popsán tento p evodník s využitím operace násobení.
Tento zp sob popisu je stru ný a lze jej snadno pochopit. M že být použit jak pro syntézu,
tak i pro simulaci. P etížení operátoru násobení pro operandy i pro výsledek typu
std_logic_vector je obsaženo ve sloze std_logic_unsigned. Ve sloze std_logic_arith
je pak definována konverzní funkce conv_std_logic_vector použitá pro úpravu ísla 100 a
10 jako druhého operandu p i násobení. Prom nná Sum je v procesu deklarována s ší kou 11
bit . Je to proto, že v definici p etížení operátoru násobení v uvedené sloze je ší ka výsledku
sou tem ší ek operand . V našem p íkladu se však po ítá s osmibitovým výsledkem, takže
hodnota vstupní veli iny BCDin bude nejvýše 255 (p edpokládá se, že to bude zajišt no
zapojením obvodu generujícího vstupní signály). Nejvyšší t i bity prom nné Sum tedy
m žeme v záv re ném p i azení této prom nné výstupnímu signálu BinOut ignorovat.
LIBRARY ieee;
USE ieee.std_logic_arith.ALL;
ENTITY BCD2Bin IS
PORT (BCDin: IN std_logic_vector(11 DOWNTO 0);
BinOut: OUT std_logic_vector( 7 DOWNTO 0));
END BCD2Bin;
-- TXT3.1.2a
ARCHITECTURE BCD2BinMltArch OF BCD2Bin IS BEGIN
PROCESS (BCDin)
VARIABLE Sum: std_logic_vector(10 DOWNTO 0);
BEGIN
Sum :=
BCDin(11 DOWNTO 8) * conv_std_logic_vector(100,7);
Sum := Sum + (BCDin( 7 DOWNTO 4) * conv_std_logic_vector(10,4));
Sum := Sum + BCDin( 3 DOWNTO 0);
BinOut <= Sum(7 DOWNTO 0);
END PROCESS;
END BCD2BinMltArch;
Nevýhodou tohoto zp sobu popisu je, že pro b žné syntetizéry p edstavuje operace
násobení problém, s nímž se nemusí vypo ádat optimálním zp sobem. V tomto p ípad byl
text zpracováván systémem WebPACK se zam ením na cílové obvody CPLD ady XC
9500XL. I když systém nakonec implementaci úsp šn zvládl, bylo nutno použít cílový
obvod typu XC 95144XL. Jak uvidíme dále (TXT3.1.2b), rozepsáním textu na jednodušší
operace (bez násobení) m žeme tentýž p evodník implementovat do obvodu XC 9572XL,
tedy do obvodu s polovi ní velikostí. Deklarace entity bude stejná jako v p edcházejícím textu
a nebudeme ji tedy znovu uvád t. Není zde pot ebná konverzní funkce jako v p edcházejícím
textu, takže není nutno uvád t odkaz na slohu std_logic_arith.
42
ARCHITECTURE BCD2BinCaseArch OF BCD2Bin IS BEGIN
PROCESS (BCDin)
BEGIN
Sum := X"0" & BCDin(3 DOWNTO 0);
CASE BCDin(7 DOWNTO 4) IS
WHEN X"1" => Sum := Sum + 10;
WHEN X"2" => Sum := Sum + 20;
WHEN X"3" => Sum := Sum + 30;
WHEN X"4" => Sum := Sum + 40;
WHEN X"5" => Sum := Sum + 50;
WHEN X"6" => Sum := Sum + 60;
WHEN X"7" => Sum := Sum + 70;
WHEN X"8" => Sum := Sum + 80;
WHEN X"9" => Sum := Sum + 90;
WHEN OTHERS => Sum := Sum;
END CASE;
CASE BCDin(11 DOWNTO 8) IS
WHEN X"1" => Sum := Sum + 100;
WHEN X"2" => Sum := Sum + 200;
WHEN OTHERS => Sum := Sum;
END CASE;
BinOut <= Sum;
END PROCESS;
END BCD2BinCaseArch;
-- TXT3.1.2b
Tento text je pon kud delší než p edcházející, vede však na úsporn jší implementaci.
Z obou text vyplývá, že pokud nám záleží na dobrém využití cílového obvodu, je zatím
vhodn jší vyhnout se použití operátoru násobení (je však pravd podobné, že další vývoj
syntetizér toto omezení p ekoná).
3.1.3 S íta ka v kódu BCD
Model s íta ky pracující v binárním kódu byl uveden d íve – viz texty TXT1.8 a TXT1.9.
Pro její úpravu na kód BCD použijeme známý algoritmus dekadické korekce používaný asto
u mikropo íta – p i tení šestky k výsledku s ítání v binárním kódu, je-li tento výsledek
v tší než 9:
LIBRARY ieee;
ENTITY AddBCD IS
Sout: OUT std_logic_vector(3 DOWNTO 0);
Cin: IN std_logic;
Cout: OUT std_logic);
END AddBCD;
ARCHITECTURE AddArch OF AddBCD IS
SIGNAL SwC: std_logic_vector(4 DOWNTO
BEGIN
BCDadd: PROCESS (a,b,Cin)
VARIABLE SwCvar: std_logic_vector(4
BEGIN
SwCvar := ("0000" & Cin) + a + b;
IF SwCvar > 9 THEN SwCvar := SwCvar
SwC <= SwCvar;
END PROCESS BCDadd;
Cout <= SwC(4); Sout <= SwC(3 DOWNTO
END AddArch;
43
0); -- Sum with Carry
DOWNTO 0);
+ 6; END IF;
0);
-- TXT3.1.3
Ve sloze std_logic_unsigned jsou p etíženy operátory s ítání tak, aby akceptovaly
operandy typu std_logic_vector a integer, p i emž výsledek je typu logic_vector.
V textu TXT3.1.3 se vyskytují operace sou tu, u nichž se m že za ínající konstruktér
snadno dopustit n kterých na první pohled ne zcela z ejmých chyb. Upozorníme na nej ast jší
z nich. P ipome me, že operátory sou tu a sjednocení mají stejnou prioritu, a že výsledkem
sou tu je vektor s po tem bit , který je roven po tu bit nejširšího s ítance. P enos z nejvyššího bitu se p i sou tu ignoruje. Je-li ve výrazu zapsáno n kolik operací se stejnou
prioritou, provád jí se operace v po adí, jak jsou zapsány zleva doprava. N které možnosti
nesprávného zápisu jsou:
a) SwCvar := a + b + Cin;
Zde je syntaktická chyba: sou et na pravé stran je ty bitový a prom nná SwCvar byla
deklarována jako p tibitová. Chybu automaticky odhalí kompilátor, stupe její nebezpe nosti
je nízký.
b) SwCvar := a + b + "0000" & Cin;
Tento zápis je syntakticky správný, takže implementace se provede bez problém . Není však
zde vyzna ena precedence operací, takže se nejprve se tou vektory a a b, p i emž s ítání je
ty bitové s ignorováním p enosu. K tomuto sou tu se p i te konstantní vektor "0000" (zcela
zbyte n , nic se tím nem ní) a k výsledku se pak zprava p ipojí p enosový bit. Celkový
výsledek je tedy p tibitový, tj. syntakticky správný, ale chybný íseln : p ipojením bitu Cin
se posunou bity sou tu vektor a a b o jednu pozici doleva, takže se sou et ve skute nosti
násobí dv ma, a jak již bylo uvedeno, ignoruje se p enos z tohoto s ítání. Chybu je možno
odhalit pouze simulací.
c) SwCvar := a + b + ("0000" & Cin);
Zápis je op t syntakticky správný. Je však ignorován p enos ze s ítání vektor a a b. Chyba se
projeví jen p i takových hodnotách t chto vektor , jejichž sou et je v tší než 15. P enos Cin
se k sou tu p i ítá správn . Pro odhalení této chyby je nezbytné provést simulaci s takovými
hodnotami vstupních vektor , které dají chybný výsledek. Pokud si p edem neuv domíme, že
se p i hodnotách vstupních vektor blízkých jejich nejv tší možné hodnot m že projevit
chyba, která je skrytá p i menších hodnotách t chto vektor , m že tato chyba snadno ujít
pozornosti. Z tohoto p íkladu je z ejmá d ležitost co nejv tšího pokrytí rozsahu vstupních
hodnot testem.
Z pravidel syntaxe jazyka vyplývá, že ve výrazu pro prom nnou SwCvar v textu TXT3.1.3
nemusí být závorka. Je tam jen pro lepší p ehlednost. Je také vhodné zde upozornit na to, že
mnohé návrhové systémy ignorují p i ítání nuly k jinému operandu, takže u nich není
o ekávaným zp sobem zpracován nap íklad zápis, u n hož se bitová ší ka vytvá í prvním
nulovým operandem:
SwCvar := "00000" + Cin + a + b;
Je z ejmé, že zv tšování bitové ší ky u objekt typu std_logic_vector m že zp sobit
problémy s p enositelností kódu. Dostupné návrhové systémy však zp sob zápisu uvedený
v textu TXT3.1.3 akceptují. Je ale vhodné postupovat opatrn a p i p echodu na jiný systém
tuto skute nost ov it, zejména pokud by mohlo dojít k chybám nezachyceným kontrolou
syntaxe, jak je uvedeno v p íkladech b) a c).
44
3.1.4 P evodník binárního kódu na kód BCD
Na p íkladu p evodníku kódu BCD na binární kód jsme poznali, že použití složit jších
operátor m že zjednodušit popis modelu, jejich syntéza však bývá asto problematická. Ješt
výrazn ji je tato skute nost z ejmá u zp tného p evodníku, tj. u p evodníku binárního kódu na
kód BCD. Uvedeme nejprve zápis využívající aritmetické operace související s d lením. Tyto
operace jsou pro syntézu ješt problemati t jší než operace násobení a sou asné syntetizéry je
nepodporují. (Popisy TXT3.1.4a a TXT3.1.4c byly již uvedeny v kapitole pojednávající o
zkušebních jednotkách, pro lepší návaznost textu je však nyní uvedeme znovu.)
LIBRARY ieee;
-- TXT3.1.4a
ENTITY Bin2BCD IS
PORT(BinIn: IN std_logic_vector( 7 DOWNTO 0); -- vstup
BCDout: OUT std_logic_vector(11 DOWNTO 0)); -- výstup
END Bin2BCD;
ARCHITECTURE NotSynthesizable OF Bin2BCD IS BEGIN
PROCESS (BinIn)
VARIABLE IntBin,InMod10: integer;
BEGIN
IntBin := conv_integer(BinIn);
InMod10 := IntBin MOD 10;
CASE InMod10 IS
WHEN 0 => BCDout((4*i - 1) DOWNTO (4*i – 4))
WHEN OTHERS => NULL;
END CASE;
IntBin := IntBin/10;
END LOOP;
END PROCESS;
END NotSynthesizable;
<=
<=
<=
<=
<=
<=
<=
<=
<=
<=
x"0";
x"1";
x"2";
x"3";
x"4";
x"5";
x"6";
x"7";
x"8";
x"9";
Simulace tohoto modelu ne iní problémy, syntéza však u sou asných návrhových systém
kon í hlášením o tom, že text obsahuje operace, které nejsou podporovány. Jde o operaci
d lení a o operaci vytvá ející zbytek po d lení (MOD).
Rozepsat tyto operace na jednodušší, jako to bylo u p evodníku kódu BCD na binární kód,
není tím nejsnadn jším a patrn ani nejvhodn jším ešením. Ukážeme dva možné p ístupy,
jak vytvo it syntetizovatelný kód. Oba budou spo ívat v postupném p evodu jednotlivých
íslic binárního zápisu do kódu BCD po ínaje nejnižšími ády a jejich p i tení k dosavadnímu
áste nému výsledku v kódu BCD.
Nejprve vytvo íme strukturální model p evodníku. Použijeme p itom s íta ku v kódu BCD
popsanou textem TXT3.1.3. Text strukturálního modelu je mnohem mén p ehledný než
uvedený text behaviorálního modelu TXT3.1.4a, a proto je vhodné p ed jeho sestavením si
nakreslit blokové schéma, jak je uvedeno na obr. 3.1.
45
Aa0
A
Ba0
B
'0'
Cin
AddBCD
Cout
C0out
Sout
S0out
Aa1H
A
Ba1H
B
Ca1H
Cin
Aa1L
A
Ba1L
B
St0
AddBCD
Cout
Sout
BCD1out
St1H
AddBCD
Cout
Aa0 = '0'&Bin(2 DOWNTO O)
Ba0 = Bin(3)&"000"
Aa1H = "000"&Bin(4)
'0'
Ba1H = "000"&C0out
Cin
Sout
BCD0out
St1L
Aa1L = '0'&Bin(4)&Bin(4)&'0'
Obr. 3.1. Blokové schéma p evodníku s p tibitovým vstupem Bin(4 DOWNTO 0)
Nejnižší (nultý) stupe p evodníku bude p edstavovat s íta ka p evád jící ty bitový
binární údaj na kód BCD. Nejnižší t i bity dávají hodnotu 0 až 7, což je již íslo v kódu BCD,
a ty tedy mohou p edstavovat data na jednom vstupu s íta ky – bude to vstup A tohoto stupn
s íta ky. Na druhý vstup s íta ky p ivedeme další bit s váhou 8 – bude-li tento bit nulový,
nezm ní hodnotu výstupu s íta ky, a v opa ném p ípad se k prvnímu vstupu p i te íslo 8.
Výstup s íta ky bude p edstavovat ty bitový sou et v rozsahu 0 až 9. P enosový bit pak
p edstavuje nejnižší bit vyšší íslice. Pokud tato íslice m že mít hodnotu jen 0 nebo 1, není
pro ni pot ebná další s íta ka. Tak zde mohou být zobrazena ísla s rozsahem 0 až 15.
Další, tj. první stupe bude k výsledku nultého stupn p idávat p ísp vek pátého bitu
s váhou 16. Toto íslo se bude p i ítat, bude-li pátý bit jedni kový. Výstup bude mít rozsah 0
až 31, takže zde již budou dv s íta ky, které jako celek tvo í s íta ku pro dv dekády. Na
jeden vstup s íta ky vytvá ející nižší íslici (dále nižší s íta ka) p ivedeme ty bitový výstup
s íta ky nultého stupn , na druhý íslo p edstavující 0, je-li vstupní bit nulový a íslo 6 (nižší
íslice ísla 16) v opa ném p ípad . Na jeden vstup vyšší s íta ky p ivedeme p enosový bit
z nultého stupn a na druhý op t podle hodnoty vstupního bitu s váhou 16 nulu nebo jedni ku.
P irozen musíme propojit výstup p enosu nižší s íta ky prvního stupn se vstupem p enosu
vyšší s íta ky.
Podobným zp sobem bychom mohli p ipojovat bez omezení další stupn p evodníku,
každý další vstupní bit je zpracován dalším stupn m. Pro p evodník osmibitového binárního
ísla na kód BCD bychom tak pot ebovali celkem 5 stup , celkový po et s íta ek by pak byl
10 (v posledním stupni bude t ídekádová s íta ka složená ze t í jednodekádových blok
AddBCD, které budou propojeny podobn jako s íta ka v druhém stupni na obr. 3.1).
Strukturální popis vrcholové jednotky odpovídající blokovému schématu z obr. 3.1 je:
LIBRARY ieee;
ENTITY Bin2BCD2d IS
PORT(Bin:
BCD1out,BCD0out: OUT std_logic_vector(3 DOWNTO 0));
END Bin2BCD2d;
46
-- TXT3.1.4b
ARCHITECTURE Bin2BCD2darch OF Bin2BCD2d IS
COMPONENT AddBCD
Sout: OUT std_logic_vector(3 DOWNTO 0);
Cin: IN std_logic;
Cout: OUT std_logic);
END COMPONENT;
SIGNAL Aa0: std_logic_vector(3 DOWNTO 0);
SIGNAL Ba0: std_logic_vector(3 DOWNTO 0);
SIGNAL Aa1H: std_logic_vector(3 DOWNTO 0);
SIGNAL Ba1H: std_logic_vector(3 DOWNTO 0);
SIGNAL Aa1L: std_logic_vector(3 DOWNTO 0);
SIGNAL Ba1L: std_logic_vector(3 DOWNTO 0);
SIGNAL Ca1H: std_logic;
BEGIN
Aa0 <= '0'&Bin(2 DOWNTO 0); Ba0 <= Bin(3)&"000";
St0: AddBCD PORT MAP(a=>Aa0,b=>Ba0,Cin=>'0',Sout=>Ba1L,Cout=>Ba1H(0));
Aa1H <= "000"&Bin(4); Ba1H(3 DOWNTO 1) <= "000";
Aa1L <= '0'&Bin(4)&Bin(4)&'0';
St1L: AddBCD PORT MAP(a=>Aa1L,b=>Ba1L,Cin=>'0',
Sout=>BCD0out,Cout=>Ca1H);
St1H: AddBCD PORT MAP(a=>Aa1H,b=>Ba1H,Cin=>Ca1H,
Sout=>BCD1out,Cout=>OPEN);
END Bin2BCD2darch;
Zde jsou po deklaraci komponenty AddBCD deklarovány signály propojující jednotlivé
s íta ky nakreslené na obr. 3.1. Následuje p íkazová ást popisu architektury s p i azovacími
p íkazy pro tyto signály a s vložením s íta ek jako komponent. Struktura textu nazna uje, jak
by se provedlo rozší ení p evodníku na v tší po et bit : v deklarativní ásti by byly
deklarovány další signály propojující s íta ky ve vyšších stupních, a v p íkazové ásti by jim
byly p i azeny pat i né hodnoty a byly by vloženy komponenty p edstavující další s íta ky.
P irozen by bylo nutno modifikovat také brány p evodníku v deklaraci entity.
Pozoruhodné je, že i když zapojení pro vícebitový p evodník vypadá na první pohled dosti
složit , je výsledek implementace po optimalizaci jednodušší než podobný výsledek pro výše
uvedený p evodník kódu BCD na binární kód. Je tomu tak z ejm proto, že v tšina s íta ek
zde neprovádí plnohodnotné s ítání, ale pouze p i tení jedné ze dvou možných hodnot k druhému vstupu (a i ten má asto speciální tvar), a použitý systém dokáže tuto skute nost p i
optimalizaci využít ke zjednodušení výsledné struktury. Pro osmibitové vstupní íslo byl
p evodník získaný rozší ením textu TXT3.1.4b implementován systémem WebPACK do
obvodu XC 9536XL, tedy polovi ního proti p evodníku podle textu TXT3.1.2b.
Nep ehlednost strukturálního popisu vedla k vytvo ení grafických systém pro vstup
údaj . V laborato i ÚREL je k dispozici systém FPGA Advantage firmy Mentor Graphics,
v jehož vstupním bloku je možno zakreslit schéma podobné schématu z obr. 3.1, a z n j
automaticky vygenerovat odpovídající kód VHDL. Uvedený systém umož uje velmi
pohodlnou práci a p ehledný zp sob vedení dokumentace, p i emž p enositelnost na jiné
systémy je zajišt na generovaným kódem VHDL. Bližší bude uvedeno na po íta ovém
cvi ení.
Pon kud p ehledn jší formou textového popisu než je TXT3.1.4b nabízí styl p edstavující
p echod mezi behaviorálním stylem a stylem popisu toku dat, který zde uvedeme jako
poslední variantu popisu p evodníku – TXT3.1.4c. Tato varianta popisu op t vychází ze
schématu nakresleného na obr. 3.1, a jde op t o syntetizovatelný popis. Text popisu je zde
rozší en na osmibitový vstupní údaj:
47
LIBRARY ieee;
ENTITY BiBCDbhv IS
PORT(BinIn: IN std_logic_vector(7 DOWNTO 0);
BCDout: OUT std_logic_vector(11 DOWNTO 0));
END BiBCDbhv;
-- TXT3.1.4c
ARCHITECTURE BiBCDbhvArch OF BiBCDbhv IS BEGIN
PROCESS(BinIn)
VARIABLE Sum5:std_logic_vector( 4 DOWNTO 0);
BEGIN
-- BinIn(2 DOWNTO 0) - inicializace ------------------------Sum := X"00" & '0' & BinIn(2 DOWNTO 0);
-- BinIn(3) - 0. stupe : Add 8hex, BCDout max. 15 ----------IF (BinIn(3) = '1') THEN Sum := Sum + 8;
IF Sum > "1001" THEN Sum := Sum + 6; END IF;
END IF;
-- BinIn(4) - 1. stupe : Add 16hex, BCDout max. 31 ---------IF (BinIn(4) = '1') THEN Sum := Sum + X"16";
IF Sum(3 DOWNTO 0) > "1001" THEN Sum := Sum + 6; END IF;
END IF;
-- BinIn(5) - 2. stupe : Add 32hex, BCDout max. 63 ---------IF (BinIn(5) = '1') THEN Sum := Sum + X"32";
END IF;
-- BinIn(6) - 3. stupe : Add 64hex, BCDout max. 127 --------IF (BinIn(6) = '1') THEN Sum := Sum + X"64";
IF Sum(7 DOWNTO 4) > "1001" THEN Sum := Sum + X"60"; END IF;
END IF;
-- BinIn(7) - 4. stupe : Add 128hex, BCDout max. 255 -------IF (BinIn(7) = '1') THEN
Sum5 := ('0'&Sum(3 DOWNTO 0)) + 8; -- výsledek m že být p tibitový
IF Sum5 <= "1001" THEN Sum := Sum + 8; -- LSD z 128
ELSE Sum := Sum + X"E"; END IF;
Sum5 := ('0'&Sum(7 DOWNTO 4)) + 2;
IF Sum5 <= "1001" THEN Sum := Sum + X"120"; -- MSD z 128
ELSE Sum := Sum + X"180"; END IF;
END IF;
BCDout <= Sum;
END PROCESS;
END BiBCDbhvArch;
P ipome me pro snadn jší pochopení algoritmus s ítání ísel v kódu BCD, na n mž je
uvedený text založen: S ítají se íslice jednotlivých dekadických ád po ínaje nejnižším
ádem. Je-li sou et íslic v tší než 9, musí se k n mu p i íst íslo 6. Sou et dvou dekadických
íslic m že n kdy být v tší než 15, takže tento sou et je nezbytné chápat jako p tibitové íslo
(není-li rozsahem s ítanc zajišt no, že je výsledek ty bitový).
S ítání v nultém stupni p evádí nejnižší ty i vstupní bity do kódu BCD. Sta í tedy
testovat, zda je výsledek v tší než 9, a v kladném p ípad k n mu p i íst 6.
Ve prvním stupni se p i ítá íslo 6 (nižší íslice z váhy tvrtého vstupního bitu – 16) k nejnižší dekadické íslici p edstavující jednotky. Protože tato íslice m že být nejvýše 9, je
výsledek s ítání vždy nejvýše ty bitový, takže op t sta í testovat, zda tento výsledek je v tší
než 9. Podobné je to ve druhém stupni, kde se k nejnižší íslici p i ítá íslo 2. Ve všech t chto
stupních nemohla být íslice p edstavující desítky v tší než 9, takže ji nebylo nutno testovat.
48
Ve t etím stupni již m že výsledek mít hodnotu až 127, takže po provedení sou tu je nutno
testovat ob jeho dekadické íslice. Žádná z nich však nem že být v tší než 15 (p i ítají se
ísla 6 a 4), takže op t vysta íme s testem ty bitového výsledku.
V tvrtém stupni se k íslici na pozici jednotek p i ítá íslo 8, takže výsledek m že být
p tibitový. Proto je zde použita prom nná ; pro zjišt ní, zda je tento výsledek v tší než 9, a
v kladném p ípad se místo ísla 8 p i te íslo o 6 v tší. Totéž je zde provedeno pro íslici
p edstavující desítky, což sice není nutné, protože se k této íslici p i ítá jen íslo 2, ale jak
ukazují výsledky syntézy, p i minimalizaci dokáže systém tuto redundanci odstranit. P i
p ípadném dalším rozši ování na v tší po et bit m že takový test být pot ebný a neud láme
chybu, když jej za adíme i tehdy, není-li nezbytný. Ušet íme si tím as a vyhneme se
možnosti opominutí testu, pokud by byl nezbytný. Není však p edem zaru eno, že syntetizér
všechny p ebyte né testy dokáže správn vyhodnotit a vylou it. Zp sob dalšího p ípadného
rozší ení p evodníku na vyšší po et bit je již z ejmý.
Tento p íklad ilustruje skute nost, že pokud známe algoritmus vytvo ení výsledku,
m žeme jej použít pro sestavení popisu behaviorálním stylem pomocí procesu, který je velmi
blízký programování po íta e. Musíme však mít na pam ti, že má-li popis být syntetizován, je
t eba vyhnout se použití jazykových konstrukt , které syntetizéry nedokážou zpracovat.
V sou asné dob mezi n pat í nap íklad operace d lení (s výjimkou d lení mocninou ísla 2,
které je ekvivalentní posuvu o jedno nebo více míst doprava), operace vytvo ení zbytku po
d lení a podobn . V p íkladu p evodníku kódu BCD na binární kód (TXT3.1.2a, TXT3.1.2b)
jsme vid li, že n kdy m že p sobit problémy i operace násobení. Jednotlivé syntetizéry se
mohou vzájemn lišit v rozsahu operací, které jsou schopny zvládnout. Proces uvedený v p íkladu odpovídá schématu z obr. 3.1, což dává dobrý p edpoklad k možnosti jeho syntézy.
Doporu uje se p i zápisu podobného textu myslet na to, zda a jak m že být zapisovaný proces
p eveden do tvaru obvodového zapojení. Pokud použijeme nevhodného, i když syntakticky
správného zápisu, m že se stát, že simulace prob hne bez problém , ale že syntetizér bu
nebude schopen syntézu provést, nebo že vytvo í zapojení mnohem složit jší, než je nutné.
Pak m že být na míst použít popisu nižší úrovn , nap íklad se strukturálním stylem.
3.2 SUBSYSTÉMY SE ZVLÁŠTNÍMI TYPY BRAN
V této kapitole uvedeme zp sob modelování subsystém s t ístavovými výstupy, s otev eným kolektorem a s obousm rnými branami. Podobn jako jsme poznali u modelování
pam ových prvk (odst. 3.4.5), i pro syntézu subsystém s takovými branami je pot ebné u
behaviorálních model používat standardní zp sob popisu – šablonu, kterou systém rozpozná
a vytvo í strukturu s odpovídajícím uspo ádáním výstup nebo obousm rných bran.
3.2.1 Subsystémy s t ístavovými výstupy a s otev eným kolektorem
Uvedeme zde p íklad popisu multiplexoru s t ístavovým výstupem. Vlastní multiplexor
bude mít výstup deklarován jako signál, který bude p iveden na vstup t ístavového zesilova e,
jehož výstup bude p edstavovat bránu celého subsystému. V tšina návrhových systém
rozeznává popis t ístavového výstupu ve tvaru procesu, který modeluje t ístavový výstupní
zesilova .
LIBRARY ieee;
-- TXT3.2.1
ENTITY Mux_3s IS
PORT(a,b,c,d: IN std_logic_vector(3 DOWNTO 0); -- datové vstupy
s:
IN std_logic_vector(1 DOWNTO 0); -- výb rový vstup
Oe:
IN std_logic;
-- ídicí signál výstupu
49
X_3s:
END Mux_3s;
OUT std_logic_vector(3 DOWNTO 0)); -- t ístavový výstup
ARCHITECTURE ArchMux_3s OF Mux_3s IS
SIGNAL x: std_logic_vector(3 DOWNTO 0);
BEGIN
WITH s SELECT
x <= a WHEN "00",
b WHEN "01",
c WHEN "10",
d WHEN OTHERS;
Tristate: PROCESS (Oe,x) BEGIN
IF Oe = '1' THEN X_3s <= x;
ELSE X_3s <= (OTHERS => 'Z');
END IF;
END PROCESS Tristate;
END ArchMux_3s;
-- vnit ní uzel
-- popis 3stavových
-- výstup. zesilova
P ipome me, že konstrukt OTHERS => 'Z' p edstavuje agregát – viz odst. 3.3.1 Typy dat.
Mnoho systém také dovoluje zapsat místo procesu i soub žný p i azovací p íkaz:
X_3s <= x WHEN Oe = '1' ELSE 'Z';
V n kterých knihách se uvádí, že s hodnotou 'Z' lze zacházet podobn jako s obvyklými
hodnotami signál '0' a '1'. Jiní auto i, viz nap íklad [3], doporu ují držet se striktn šablony s procesem, chceme-li zajistit p enositelnost kódu na r zné systémy. Vzhledem k tomu, že
rozdíl mezi ob ma zápisy není velký, bude asi vhodn jší držet se verze s p ísn jšími pravidly.
Výstupy s otev eným kolektorem m žeme modelovat podobným zp sobem. Fyzicky se
obvody PLD nebo FPGA s takovými výstupy vyskytují z ídka, m žeme je však emulovat tím
zp sobem, že u t ístavového výstupního zesilova e p ivedeme vnit ní signál, který má být na
výstupu, na ídicí vstup tohoto zesilova e, a na jeho datový vstup p ivedeme konstantní
hodnotu 0 nebo 1 podle toho, jde-li o zesilova neinvertující i invertující. Behaviorální popis
invertujícího výstupního zesilova e emulující výstup s otev eným kolektorem, na n mž se má
objevit vnit ní signál x, pak m že být:
X_oc <= '0' WHEN x = '1' ELSE 'Z';
Signál x bude podobn jako u uvedeného p íkladu multiplexoru deklarován v deklarativní
ásti popisu architektury a v její p íkazové ásti bude popsán b žnými zp soby.
3.2.2 Subsystémy s obousm rnými branami
Obousm rné brány se uvád jí v deklaraci entity v p íkazu PORT s módem INOUT. Jako
p íklad uve me model registru se statickým ízením (latch):
LIBRARY ieee;
ENTITY RegBidir IS
PORT(q: INOUT std_logic_vector(7 DOWNTO 0);
En: IN
std_logic;
Oe: IN
std_logic);
END RegBidir;
ARCHITECTURE ArchReg OF RegBidir IS
SIGNAL Qa: std_logic_vector(7 DOWNTO 0);
BEGIN
Load: PROCESS (En,q) BEGIN
IF (En = '1') THEN Qa <= q;
END IF;
END PROCESS Load;
50
-- TXT3.2.2
-- obousm rná brána
-- latch enable
-- ídicí signál výstupu
-- vnit ní uzel
-- napln ní
-- implicitní pam
Output: PROCESS (Oe,Qa) BEGIN
IF Oe = '0' THEN q <= (OTHERS => 'Z');
ELSE q <= Qa;
END IF;
END PROCESS Output;
END ArchReg;
-- popis 3stavových
-- výstupních zesilova
Uvedený text je zpracován syntetizérem zpravidla bez problém , obsahuje-li cílový obvod
hardwarové registry se statickým ízením. Není-li tomu tak, dokážou inteligentní syntetizéry
vytvo it registr ve struktu e makrobun k, pokud to ovšem struktura cílového obvodu dovoluje. Nap íklad v obvodu 22V10 nelze vytvo it takový registr s t ístavovými výstupy, protože
se zde zp tná vazba odebírá až za výstupem t ístavových zesilova a uvedou-li se tyto
zesilova e do stavu vysoké impedance, rozpojí se tím smy ka zp tné vazby v registru. ešení
by zde sice bylo ve vytvo ení b žného registru a v použití dalších makrobun k pro t ístavový
zesilova , bylo by to však ešení dosti neekonomické. U syntetizér s menším stupn m inteligence mohou nastat problémy s hazardy, p ípadn m že být výsledek syntézy zcela chybný.
Je proto vhodné zkontrolovat p íslušnou ást hlášení fitteru a provést simulaci postfit modelu.
Možné problémy se však týkají jen pam ové funkce registru, nikoliv jeho t ístavové brány.
3.3 PAM
OVÉ OBVODY SE ZP TNOU VAZBOU
Mezi obvody tohoto druhu, s nimiž se setkáváme v íslicových systémech, po ítáme
asynchronní klopné obvody RS a klopné obvody typu D se statickým ízením (latch). Existují
sice i jiné druhy zp tnovazebních pam ových obvod , ty se však používají prakticky jen ve
zcela speciálních p ípadech a zde o nich nebudeme uvažovat. Klopné obvody typu RS se v jazyku VHDL popisují nejlépe pomocí logických výraz a není zde žádný zvláštní problém.
Staticky ízený klopný obvod typu D je možno popsat procesem – viz TXT3.2.2, ale i
logickými výrazy, jak je z ejmé z následujícího p íkladu:
LIBRARY ieee;
ENTITY Latch IS
PORT(d: IN
std_logic;
q: BUFFER std_logic;
En: IN
std_logic);
END Latch;
-- TXT3.3.1
-- vstup
-- výstup
-- latch enable
ARCHITECTURE LogExpr OF Latch IS BEGIN
q <= (d AND En) OR (q AND NOT En) OR (d AND q);
END LogExpr;
O možných problémech s vynecháním konsensu p i optimalizaci takového textu již byla
diskuse v odst. 1.4.5 a nebudeme ji zde opakovat. Pro tyto problémy se uvedené obvody
popisují zp sobem uvedeným v odst. 1.4.5 zopakovaným v textu TXT3.2.2 a jejich popis
odpovídající textu TXT3.3.1 se obvykle nepoužívá, i když je možno íci, že lépe a jasn ji
vyjad uje chování obvodu.
3.4 ÍTA E
V této kapitole uvedeme základní zp soby realizace nejb žn jších íta . Budeme
uvažovat jen synchronní íta e, které se používají nej ast ji. P íklad modelu asynchronního
íta e byl uveden v kapitole o simulaci.
51
3.4.1 Binární íta e
Binární íta pat í k subsystém m, které se vyskytují velmi asto. Jejich popis v jazyku
VHDL je zcela standardní. Nebudeme se tedy zabývat r znými variantami íta , ale
uvedeme popis ty bitového vratného íta e s asynchronním i se synchronním nulováním,
s možností napln ní obsahem ze vstupní brány a s možností blokování ítání. Není obtížné
v p ípad pot eby p ebyte né funkce vynechat.
LIBRARY ieee;
ENTITY Counter IS
PORT(Clk,Dir,ARst,SRst,Load,CEn,: IN std_logic;
Din:
Count: OUT std_logic_vector(3 DOWNTO 0));
END Counter;
-- TXT3.4.1
ARCHITECTURE CountArch OF Counter IS
SIGNAL CntInt: std_logic_vector(3 DOWNTO 0) := "1010"; -- po át. hodn.
BEGIN
PROCESS (Clk,ARst) BEGIN
IF Rst = '1' THEN CntInt <= "0000";
-- asynchr.reset
-- aktivní hrana Clk
IF SRst = '1' THEN CntInt <= "0000"; -- synchr.reset – max.priorita
ELSIF Load = '1' THEN CntInt <= Din; -- synchr.napln ní
ELSIF CEn = '1' THEN
IF Dir = '1' THEN CntInt <= CntInt + 1; -- inkrement je-li povolen
ELSE CntInt <= CntInt - 1; -- dekrement je-li povolen
END IF;
END IF; -- pro SRst, Load a CEn neaktivni se stav nemeni
END IF;
-- konec ásti ovlivn né aktivní hranou Clk
END PROCESS;
Count <= CntInt;
END CountArch;
P ipome me, že brána s módem OUT m že sloužit jen jako výstup signálu a hodnota jejího
signálu není dostupná uvnit modelu. Proto je zde v deklarativní ásti popisu architektury
deklarován signál CntInt, který je použitý jako sou asná hodnota obsahu íta e p i jeho
inkrementaci a dekrementaci. Posledním p íkazem v popisu architektury soub žným s procesem je jeho hodnota p i azena výstupnímu signálu. Jinou možností by bylo deklarovat
signál Count s módem INOUT. Pak by deklarace signálu CntInt mohla odpadnout a místo signálu CntInt by se v popisu pracovalo p ímo se signálem Count. P i simulaci je však práce s
obousm rnými branami obtížn jší, a proto bývá vhodn jší p ístup uvedený v textu TXT3.4.1.
Po áte ní hodnota íta e uvedená v deklaraci signálu CntInt se p i syntéze ignoruje, je
však akceptována p i simulaci. Tímto zp sobem m žeme jednoduše ov it nap íklad chování
íta s neúplným cyklem v nepracovních stavech.
3.4.2
íta e pracující v kódu BCD
Z velkého množství variant t chto íta , které se vzájemn liší chováním v nepracovních
stavech, uvedeme popis íta e, u n hož se každá dekáda nacházející se v nepracovním rozsahu, tj. v rozsahu 10 až 15, v následujícím taktu nuluje. Text je pro rozsah íta e dvou dekád,
tedy od 0 do 99. Rozší ení na v tší po et dekád bude spo ívat v pot ebném po tu zopakování
a malé modifikaci textu pro desítky (mezi komentá em -- desítky a –- nuluj...) a není
obtížné.
52
LIBRARY ieee;
-- TXT3.4.2
ENTITY BCDCit IS
PORT(Clk:
IN std_logic;
Bcd0,Bcd1: OUT std_logic_vector(3 DOWNTO 0));
END BCDCit;
ARCHITECTURE BCDCitArch OF BCDCit IS
SIGNAL PrSt0: std_logic_vector(3 DOWNTO 0) := "0111";
SIGNAL PrSt1: std_logic_vector(3 DOWNTO 0) := "1010";
SIGNAL NxSt0,NxSt1: std_logic_vector(3 DOWNTO 0);
BEGIN
StComb: PROCESS (PrSt0,PrSt1) BEGIN
-- kombina ní ást
IF PrSt0 < X"9" THEN NxSt0 <= PrSt0 + 1;
-- jednotky
ELSE NxSt0 <= X"0";
END IF;
IF PrSt0 = X"9" THEN
-- desítky
IF PrSt1 < X"9" THEN NxSt1 <= PrSt1 + 1;
ELSE NxSt1 <= X"0";
END IF;
ELSE
NxSt1 <= PrSt1;
END IF;
IF PrSt1 > X"9" THEN NxSt1 <= X"0"; END IF; -- nuluj v neprac.stavech
END PROCESS StComb;
BCDClckd: PROCESS (Clk) BEGIN
-- registr
PrSt0 <= NxSt0;
PrSt1 <= NxSt1;
END IF;
END PROCESS BCDClckd;
Bcd0 <= PrSt0;
-- p i azení vnit ních signál výstup m
Bcd1 <= PrSt1;
END BCDCitArch;
V textu TXT3.4.2 se využívá skute nosti, že p i vícenásobném p i azení signál v procesu
se p edcházející p i azení p epíše následujícím p i azením. U deklarace signál PrSt0 a
PrSt1 jsou uvedeny po áte ní hodnoty t chto signál , které se p i syntéze ignorují, p i
simulaci se však akceptují a dovolují tak ov it chování íta e v nepracovních stavech. P i
uvedených po áte ních hodnotách se v prvním taktu nuluje dekáda desítek, zatímco dekáda
jednotek ítá po ínaje od ísla 7. Dále již íta pokra uje v ítání b žným zp sobem.
3.5 STAVOVÉ AUTOMATY
Stavové automaty p edstavují nejobecn jší íslicové subsystémy zahrnující jak
kombina ní, tak i registrové podbloky. Není proto p ekvapením, že u jejich popisu v jazycích
HDL existuje celá ada variant popisu téhož automatu.
I když se popis stavového automatu stavovým diagramem zdá p ehledný, u složit jších
automat existuje riziko výskytu chyb, které mohou mít jak syntaktický, tak i sémantický
charakter. N které z t chto chyb jsou do jisté míry p edvídatelné, a proto moderní návrhové
systémy mají zabudovánu adu r zných kontrolních mechanism , jak tyto chyby odhalit a
opravit. Proto se i zde asto vyskytují ur ité šablony pro popis, které je vhodné používat,
chceme-li t chto mechanism využít.
Návrhové systémy umož ují popsat stavový automat v r zných úrovních abstrakce.
N které ásti automatu, jako je stavový registr, asto slouží jen k vnit ní funkci automatu a na
53
vývodech se projevují jen zprost edkovan . Popis s vyšší úrovní abstrakce pracuje jen se
vstupními a s výstupními signály automatu a ešení jeho vnit ní struktury ponechává na
systému. Požadavky na konkrétní automaty však bývají velmi r znorodé a ne vždy je možno
tyto požadavky splnit, aniž by bylo nutno dodat systému další informace. Proto návrhové
systémy obsahují mnoho dodate ných ídicích nástroj , které umožní p izp sobit realizaci
popisovaného automatu konkrétnímu zadání. ím vyšší je úrove abstrakce p i popisu
automatu, tím více t chto nástroj je zapot ebí k vytvo ení jeho implementace.
kombina ní
VSTUPY
Clk
Rst
ást A
stavový
registr
STAV
kombina ní
ást B
VÝSTUPY
Vst B
C
Rst
Obr. 3.2. Blokové schéma stavového automatu
Jednodušší stavové automaty svou strukturou odpovídají blokovému schématu
nakreslenému na obr. 3.2. Jsou možné n které modifikace tohoto schématu: v tev vstupních
signál ozna ená VstB nemusí být realizována, totéž m že platit pro kombina ní ást B, nebo
naopak za touto ástí m že být ješt registr a podobn . V p ípad pot eby tyto modifikace
uvedeme slovn . Konkrétní podoba schématu v etn t chto modifiikací mohou ovliv ovat
n které d ležité vlastnosti automatu, jako je nejvyšší p ípustný kmito et hodinového signálu,
zpožd ní výstup za aktivní hranou tohoto signálu, existence hazard ve výstupech a
podobn ..
N které návrhové systémy obsahují také nástroje pro alternativní, nej ast ji grafické
zp soby zadávání vstupních údaj . Jako p íklad lze uvést nástroje obsažené v systému
WebPACK -StateCAD a State Bench umož ující pracovat p ímo s grafickou formou
stavového diagramu. Tyto grafické formy zadání se kompilují p ed dalším zpracováním do
textu v jazycích HDL a m ly by vytvo it spolu s implementa ními nástroji optimální
konfiguraci cílového obvodu podle požadavk zadání. Mezistupe jazyka HDL také zajiš uje
p enositelnost kódu na další systémy. Problém bývá v tom, že asto není snadné porozum t
všem alternativám, které konstruktérovi systém p i vstupu dat nabízí, a m že se také n kdy
stát, že pro dosažení požadovaného výsledku bude nutno na úrovni jazyka HDL provést ur ité
úpravy. Je tedy nutno ov it, zda a nakolik výsledek syntézy a implementace spl uje zadané
požadavky. To je možné jednak simulací, která však nemusí odhalit všechny d ležité
okolnosti, jednak prostudováním výsledk kompilace – vytvo eného textu v jazyku HDL, a
dalších hlášení systému. Proto i p i použití r zných grafických a podobných prost edk pro
popis konstrukce je znalost jazyka HDL pot ebná.
Uvedeme zde n kolik zp sob popisu stavových automat v jazyku VHDL. Nej ast ji tyto
popisy vycházejí z blokového schématu podle obr. 3.2, p i emž se každý blok tohoto schématu popíše zvláštním procesem. Tak vznikne tzv. t íprocesový zp sob popisu. Je-li nap íklad kombina ní ást B jednoduchá, m že být ú elné nahradit proces pro její popis prostým
54
soub žným p íkazem; n kdy tato kombina ní ást m že zcela chyb t – pak jde o dvouprocesový zp sob popisu. U jednoduchých stavových automat m že být celý automat popsán
jedním procesem p edstavujícím stavový registr, jehož p íští stav se popíše jako funkce
sou asného stavu. Nej ast ji se však používá dvou- nebo t íprocesový zp sob popisu. Mimo
toto d lení je možno popisy t ídit podle úrovn abstrakce, pop ípad i podle dalších kritérií.
Ke zp sob m popisu je t eba poznamenat, že r zné syntetizéry a implementa ní nástroje
se s jejich zpracováním mohou vypo ádat s r zným stupn m úsp šnosti a p iblížení k optimálnímu výsledku. Ten asto velmi záleží na tom, zda systém rozpozná v textu n jakou
šablonu, kterou má zabudovánu. Výsledek implementace pak m že odpovídat více této
šablon než doslovnému zn ní p vodního popisu. Rozpoznání stavového automatu v popisu
je zpravidla systémem hlášeno v protokolu zpracování. P edpokládá se, že tená je seznámen
s obecnými vlastnostmi stavových automat aspo v rozsahu odpovídajícím skript m [1]. Pro
vysv tlení nej ast ji používaných zp sob popisu stavových automat v jazyku VHDL
použijeme p íklad detektoru posloupnosti t í jedni kových bit uvedený v t chto skriptech.
3.5.1 Behaviorální popis s deklarací uživatelského typu pro stav
Detektor t í jedni kových bit . Na výstupu detektoru je jedni ka, jsou-li p ijaty t i t sn po
sob následující jedni ky na vstupu detektoru. Je-li p ijata tato posloupnost, objeví se na
výstupu detektoru v následujícím taktu jedni ka a detektor za ne zase od po átku odpo ítávat
novou posloupnost, p i emž až do dokon ení nové trojice p ijatých jedni kových bit je na
výstupu detektoru nula.
ešení: Budeme uvažovat Mealyho verzi automatu s registrovým výstupem – obr. 3.3.
V tomto zp sobu popisu se používá abstraktní uživatelsky deklarovaný typ pro stavový
vektor. Oba registry, stavový i výstupní, jsou v textu TXT3.5.1 popsány v jednom spole ném
procesu StClckd, takže popis m žeme ozna it za dvouprocesový.
LIBRARY ieee;
ENTITY Det3Mea IS
PORT(x,Clk,ARst: IN std_logic;
z:
OUT std_logic);
END Det3Mea;
-- TXT3.5.1
ARCHITECTURE Det3MeaArch OF Det3Mea IS
TYPE StType IS (s0,s1,s2);
-- uživatelský typ
SIGNAL PrSt,NxSt: StType;
SIGNAL Znxt:
std_logic;
BEGIN
StComb: PROCESS (PrSt,x) BEGIN
-- popis kombina ní ásti A a B
CASE PrSt IS
WHEN s0 =>
Znxt <= '0';
IF x = '1' THEN NxSt <= s1; ELSE NxSt <= s0; END IF;
WHEN s1 =>
Znxt <= '0';
IF x = '1' THEN NxSt <= s2; ELSE NxSt <= s0; END IF;
WHEN s2 => NxSt <= s0;
IF x = '1' THEN Znxt <= '1'; ELSE Znxt <= '0'; END IF;
END CASE;
END PROCESS StComb;
StClckd: PROCESS (Clk,ARst) BEGIN
IF ARst = '1' THEN PrSt <= s0; z <= '0'; -- asynchronní reset
PrSt <= NxSt;
-- popis stavového registru
z
<= Znxt;
-- popis výstupního registru
55
END IF;
END PROCESS StClckd;
END Det3MeaArch;
Ve srovnání s jinými texty, psanými dosud na úrovni RTL, využívá uvedený popis
architektury vyšší úrovn abstrakce behaviorálního stylu, která je obvyklá p i popisu
stavových automat . V jeho deklarativní ásti je deklarován typ StType, složený ze t í prvk
p edstavujících stavy automatu, a signály PrSt, NxSt (present state, next state – sou asný a
p íští stav automatu). Tato deklarace typu a stavových signál jsou sou ástí šablony
rozpoznávané systémem jako popis stavového automatu. Na této úrovni abstrakce není
definováno kódování stav ani typ stavového registru. Tyto podrobnosti automaticky
vygeneruje systém p i zpracování textu. Zvolí p itom typ klopných obvod v registru (D, T,
podle zabudované inteligence i jinak) tak, aby p i zvoleném kódování stav byla realizace
automatu co nejjednodušší. Proto signály PrSt, NxSt nemusí odpovídat skute ným kódovým
kombinacím na vstupu a na výstupu stavového registru po syntéze (jsou-li nap íklad n které
klopné obvody, z nichž je stavový registr složen, typu T, je jejich výstupní signál v p íštím
stavu ur en funk ní tabulkou tohoto obvodu a není totožný s jeho vstupním signálem v souasném stavu, jako je tomu u klopných obvod typu D).
x
z
komb.
ást A
Clk
ARst
stavový
registr
NxSt
PrSt
komb.
ást B
Znxt
výstupní
registr
z
x
(a)
Clk
ARst
(b)
ARst/0
Popis v tví:
x / Znxt
Popis stav s1,s2:
stav / z
(c)
1/1
1
s0
0/0
1
s1/0
0/0
s2/0
0/0
Obr. 3.3. Detektor posloupnosti t í jedni kových bit - Mealyho verze s registrovým
výstupem: blokový symbol (a), podrobn jší blokové schéma (b) a stavový diagram (c)
Popis stavového automatu na behaviorální úrovni, jehož p íkladem je text TXT3.5.1,
vyžaduje od konstruktéra minimum dodate ných úvah o zp sobu implementace a je ú elný,
pokud se smí íme s n kterými jeho nevýhodami. K nim pat í zejména nemožnost ur ení, co se
bude dít v nepracovních stavech. Další možnou nevýhodou je, že stavové bity jsou
nep ístupné a není jich možno využít jako výstupních signál , což by mohlo ušet it prost edky
spot ebované na implementaci t chto signál , pokud se poda í zvolit vhodn kódování stav ,
jak je uvedeno ve skriptech [1] v kapitole o kódování stav .
Chceme-li mít lepší kontrolu nad chováním automatu v nepracovních stavech, m žeme
doplnit p vodní stavový diagram o další stavy tak, aby celkový po et stav byl celistvou
mocninou dvou. Zadáme-li systému kódování v binárním kódu, budou všechny možné stavy
diagramem vy erpány a m žeme snadno p edepsat chování automatu v t chto p ídavných
stavech. Tento mechanismus bude fungovat za p edpokladu, že syntetizér kóduje stavy
56
logicky p edpokládaným zp sobem tak, že stav m postupn p i azuje kódové kombinace v
p íslušném kódu tak, jak jsou stavy uvedeny v deklaraci. Tímto zp sobem skute n typické
syntetizéry pracují. Není to však závazn stanoveno, a pokud nám záleží na ošet ení
nepracovních stav , je vhodné p ekontrolovat, zda používaný syntetizér nepat í mezi výjimky
z tohoto pravidla. P i použití kód nevyužívajících všech možných kódových kombinací,
nap íklad kódu 1 z n, tento mechanismus nelze použít.
Následující p íklad p edstavuje pon kud modifikovaný detektor, u n hož bude použit popis
dovolující využití stavových bit jako výstupních signál .
3.5.2 Popis s explicitním kódováním stav
Detektor dvou nebo t í jedni kových bit : P esné chování je op t z ejmé ze stavového
diagramu – obr. 3.4.
ARst
x
z
Clk
s0/0
ARst
(a)
(b)
Popis stav :
stav / z
1
1
s1/0
0
0
1
s2/1
0
1
s3/1
0
Obr. 3.4. Detektor posloupnosti dvou nebo t í jedni kových bit : blokový symbol (a) a
stavový diagram (b)
Zvolíme-li kódování stav tak, aby nap íklad nejvyšší stavový bit byl jedni kový ve
stavech s2 a s3, m žeme tento bit použít p ímo jako výstupní signál z. Tuto skute nost
m žeme využít následujícím zápisem zdrojového textu:
LIBRARY ieee;
ENTITY Det3Expl IS
PORT(x,Clk,ARst: IN std_logic;
z:
OUT std_logic);
END Det3Expl;
-- TXT3.5.2
ARCHITECTURE Det3ExplArch OF Det3Expl IS
SIGNAL State: std_logic_vector(1 DOWNTO 0);
CONSTANT s0: std_logic_vector(1 DOWNTO 0) := "00";
BEGIN
StTrans: PROCESS (Clk,ARst) BEGIN
-- popis stavových p echod
IF ARst = '1' THEN State <= s0;
CASE State IS
WHEN s0
=> IF x = '1' THEN State <= s1; ELSE State <= s0; END
WHEN s1
WHEN s2
WHEN OTHERS => IF x = '1' THEN State <= s1; ELSE State <= s0; END
END CASE;
END IF;
END PROCESS StTrans;
z <= State(1);
-- popis výstupního signálu
END Det3ExplArch;
57
IF;
IF;
IF;
IF;
Použití klí ového slova OTHERS je zde nezbytné, protože typ std_logic_vector signálu
zahrnuje i hodnoty jako 'U', 'X' atd., které musí vý et v p íkazu CASE pokrýt. Tento
popis je p íkladem jednoprocesového popisu stavového automatu.
State
V popisu s explicitním kódováním stav jsou definovány hodnoty stavových signál v jednotlivých stavech.
3.5.3 Synchronní nulování u stavových automat
Synchronní nulování je do stavových automat možno zavést pomocí dalšího vstupního
signálu, p i emž se ke stávajícím p echod m p idají další p echody odpovídající aktivaci
tohoto signálu. P íklad dopln ní automatu z obr. 3.4 je nakreslen na obr. 3.5. Asynchronní
nulování je zde pro jednoduchost vypušt no.
p echody pro SRst = 1:
x
1
z
Clk
s0/0
SRst
(a)
0
1
s1/0
1
0
s2/1
1
0
s3/1
0
Obr. 3.4. Detektor posloupnosti dvou nebo t í jedni kových bit
nulováním: blokový symbol (a) a stavový diagram (b)
p echody pro SRst = 0:
(p ipsána je hodnota x)
(b)
se synchronním
P i p episu stavového diagramu do textu v jazyku HDL odpovídá nákresu na obr. 3.4
p idání nulovacích p echod do popisu všech stav . Tento zp sob nulování koncep n
odpovídá všem dalším synchronním funkcím automatu, je však u rozsáhlejších automat
nepohodlný. Výhodn jší je zavést synchronní nulování p ímo do registru. Nap íklad v textu
TXT3.5.1 by zavedení synchronního resetu místo asynchronního mohlo být vyjád eno
úpravou procesu StClckd popisujícího stavový a výstupní registr:
StClckd: PROCESS (Clk) BEGIN
IF SRst = '1' THEN PrSt <= s0; z <= '0';
ELSE PrSt <= NxSt; z <= Znxt;
END IF;
END IF;
END PROCESS StClckd;
Do stavového diagramu se synchronní nulování obvykle nekreslí, uvede se slovn .
Jinou možností je úprava popisu kombina ní ásti – procesu StComb využívající
skute nosti, že p i vícenásobném p i azení signálu v procesu se uplat uje jen poslední z nich
(u podmín ných p íkaz samoz ejm jen poslední p íkaz z t ch p íkaz , u nichž je p íslušná
podmínka spln na). Sta í tedy mezi p íkazy END CASE a END PROCESS StComb textu
TXT3.5.1 vložit p íkaz:
IF Srst = '1' THEN PrSt <= s0; z <= '0'; END IF;
Jsou ješt další možnosti, jak synchronní nulování zajistit. S uvedenými dv ma však
vysta íme ve v tšin aplikací.
58
3.6 P ÍKLADY ITERATIVNÍCH KONSTRUKCÍ
Jako p íklady iterativních konstrukcí uvedeme p evodníky mezi binárním a Grayovým
kódem a Gray v íta z nich vycházející. Podstata vytvo ení iterativní struktury spo ívá
v ízení syntetizéru tak, aby nerozvinoval popis do zápisu ve tvaru SOP. K tomu je možno
využít bu atributy zapsané ve zdrojovém textu, nebo ídicí prost edky návrhových systém ,
tzv. options. V prvním p ípad sta í p i implementaci konstrukce do cílového obvodu spustit
p íslušný proces v systému (nap . u WebPACKu: Processes for Current Source), a
implementace prob hne bez dalších zásah . Zápis atribut však nemusí být u r zných
návrhových systém stejný a jejich použití omezuje p enositelnost kódu. Ve druhém p ípad
není p enositelnost kódu narušena.
3.6.1 P evodník binárního kódu na Gray v a naopak
Ve skriptech [1] jsou odvozeny výrazy pro p evod binárního kódu na Gray v:
gn-1 = b n-1, g n-2 = b n-2 ⊕ b n-1, ..., g1 = b1 ⊕ b2, g0 = b0 ⊕ b1,
a pro zp tný p evod
b n-1 = g n-1,
b n-2 = g n-2 ⊕ b n-1 = g n-2 ⊕ g n-1,
.............................................
b1 = g1 ⊕ b2 = g1 ⊕ g2 ⊕ ... ⊕ g n-1,
b0 = g0 ⊕ b1 = g0 ⊕ g1 ⊕ ... ⊕ g n-1.
P evodník binárního kódu na kód Gray v je pak pro ty bitovou ší ku popsán textem:
LIBRARY ieee;
ENTITY Bin2Gray IS
PORT(BinCode: IN std_logic_vector(3 DOWNTO 0);
GrayCode: OUT std_logic_vector(3 DOWNTO 0));
END Bin2Gray;
-- TXT3.6.1
ARCHITECTURE ArchBin2Gray OF Bin2Gray IS BEGIN
GrayCode(3) <= BinCode(3);
GrayCode(2 DOWNTO 0) <= BinCode(2 DOWNTO 0) XOR BinCode(3 DOWNTO 1);
END ArchBin2Gray;
P evodník pro zp tný p evod je pak popsán následujícím zápisem:
LIBRARY ieee;
ENTITY Gray2Bin IS
PORT(GrayCode: IN
std_logic_vector(3 DOWNTO 0);
BinCode: BUFFER std_logic_vector(3 DOWNTO 0));
END Gray2Bin;
-- TXT3.6.2
ARCHITECTURE ArchGray2Bin OF Gray2Bin IS
BEGIN
BinCode(3) <= GrayCode(3);
BinCode(2 DOWNTO 0) <= GrayCode(2 DOWNTO 0) XOR BinCode(3 DOWNTO 1);
END ArchGray2Bin;
Text TXT3.6.2 je zapsán podle první z obou verzí, v nichž jsou uvedeny výchozí vztahy.
V této verzi vystupuje na levé i na pravé stran vektor binárního kódu (p esn ji e eno jeho
ást, nazývaná také ez). Proto musí být výstupní brána v módu BUFFER. Nahrazení tohoto
módu módem OUT by zde bylo syntaktickou chybou, protože signál brány s módem OUT není
59
dostupný uvnit p íslušné architektury, a to i p esto, že jak uvidíme dále, p i syntéze m že být
text p eveden na druhou verzi. N které systémy p i takové chyb odmítnou další pokra ování
syntézy, jiné jen vydají upozorn ní a pokra ují dále. Pokud by tímto zp sobem byl vyjád en
zápis skalárního signálu, byla by tak vytvo ena zp tná vazba a vznikl by tak záchytný registr
(latch). Zde je však situace jiná: povšimn me si, že na levé stran je rozsah index (2 DOWNTO
0), zatímco na pravé stran to je (3 DOWNTO 1). Ve výrazu pro každý bit vektoru binárního
kódu je tedy p ítomen vyšší bit téhož kódu, a ne tentýž bit. To je dob e vid t ze zápisu
výchozích výraz , p i zápisu ve vektorovém tvaru však m že tato okolnost uniknout
pozornosti. Pokud je p i syntéze zachována struktura obvodu v souhlasu s textem, tj. pokud na
pravé stran z stane zachován vektor binárního kódu, vznikne iterativní zapojení, dob e
známé z konstrukce s íta ek – vícebitová s íta ka m že být složena z jednobitových
vzájemn propojených p enosovým signálem. Zde zm na bitu GrayCode(3) zm ní hodnotu
bitu BinCode(3), ten je však p ítomen ve vyjád ení bitu BinCode(2), který dále figuruje ve
výrazu pro BinCode(1) a ten ve výrazu pro BinCode(0). Prochází tedy zm na bitu
GrayCode(3) postupn všemi bity a tomu odpovídá doba ustálení výstupu, která je p ímo
úm rná po tu bit p evodníku.
Necháme-li však syntézu prob hnout bez dalších zásah , vytvo í syntetizér automaticky
zapojení odpovídající druhé verzi výchozích vztah , kde jsou za bity vektoru binárního kódu
na pravé stran dosazeny hodnoty již vytvo ených vyšších bit vyjád ených pomocí bit
vektoru Grayova kódu. Jde pak o jednopr chodové zapojení, kde doba ustálení výstupu
nezávisí na po tu bit p evodníku. Výhoda krátké doby ustálení však je zaplacena v tší
obvodovou složitostí p evodníku, protože operace EXCLUSIVE-OR provedená s více bity
vyžaduje zna né množství term , které exponenciáln nar stá s po tem bit v této operaci,
zatímco v iterativním zapojení nezávisí po et term pot ebných pro vytvo ení každého bitu na
po tu bit p evodníku. Rozepsáním výrazu pro bit b0 zjistíme, že u ty bitového p evodníku
je tento bit vyjád en pomocí osmi term , u p tibitového p evodníku by to bylo 16 term a
každý další p idaný bit p evodníku tento po et zdvojnásobuje. Proto je p evodník s jednopr chodovým zapojením možno v obvodech PLD realizovat jen pro malé po ty bit . Obecn se
funkce s v tším po tem term realizují v obvodech PLD technikou št pení sou t , p i níž se
automaticky op t vytvá í struktura s více pr chody. P i syntéze p evodníku s v tším po tem
bit se tedy touto technikou vytvá í také vícepr chodové zapojení. O jednopr chodovém
zapojení lze pak p i p ekro ení ur itého po tu term pot ebných pro jednotlivé bity
p evodníku hovo it jen teoreticky.
Není-li v tší doba ustálení výstup na závadu, m žeme dát syntetizéru pokyn pro
vytvo ení iterativního zapojení. Zp soby, jak toho dosáhneme, mohou být u r zných systém
r zné. Nap íklad u systému WARP se k tomuto ú elu užívá atributu, který se za adí do
deklarativní ásti popisu architektury:
LIBRARY ieee;
ENTITY Gray2Bin IS
PORT(GrayCode: IN std_logic_vector(3 DOWNTO 0);
BinCode: OUT std_logic_vector(3 DOWNTO 0));
END Gray2Bin;
-- TXT3.6.3
ARCHITECTURE ArchGray2Bin OF Gray2Bin IS
SIGNAL BinCd: std_logic_vector(3 DOWNTO 0);
ATTRIBUTE synthesis_off OF BinCd: SIGNAL IS true;
BEGIN
BinCd(3) <= GrayCode(3);
BinCd(2 DOWNTO 0) <= GrayCode(2 DOWNTO 0) XOR BinCd(3 DOWNTO 1);
BinCode <= BinCd
60
END ArchGray2Bin;
V tomto textu m že mít brána BinCode mód OUT, protože její signál je v p íkazové ásti
popisu architektury nahrazen signálem BinCd, který je možno použít na pravé stran p i azovacího p íkazu (p ipome me, že identifikátor BinCode by zde nebylo možno použít, protože
signál brány typu OUT není dostupný v popisu architektury). Zavedení signálu BinCd je nutné
z toho d vodu, že atribut synthesis_off se musí vztahovat k signálu. P i syntéze textu
TXT3.6.3 budou bity brány BinCode vyjád eny p esn podle zápisu v tomto textu, každý tedy
pomocí dvou term , jen identifikátor BinCd bude nahrazen identifikátorem BinCode.
U systému WebPACK má jako atribut synthesis_off obdobný význam atribut
noreduce. V tomto systému je však navíc nutno tento atribut p edtím deklarovat zápisem,
který m že být uveden na ádku p edcházejícím jeho p i azení požadovanému signálu:
ATTRIBUTE noreduce: boolean;
ATTRIBUTE noreduce OF BinCd: SIGNAL IS true;
T mito dv ma ádky se nahradí v textu psaném pro systém WebPACK tu n uvedený
ádek v textu TXT3.6.3.
3.6.2 Gray v íta
S využitím text TXT3.6.1 a TXT3.6.2 sestavíme nyní popis íta e pracujícího v Grayov
kódu. Ten bude založen na následující myšlence: sou asný stav p edstavovaný Grayovým
kódem p evedeme do binárního kódu, ten inkrementujeme dob e známým zp sobem a
p evedeme nazp t do Grayova kódu. Tím se vyhneme pot eb znát vyjád ení bit
následujícího stavu Grayova íta e na základ bit sou asného stavu, které není jednoduché.
Úloha vytvo ení výraz pro následující stav íta e tak p echází na kompilátor. P evody mezi
ob ma kódy budou sou ástí popisu íta e.
LIBRARY ieee;
ENTITY CntGray IS
PORT(Clk:
IN
std_logic;
CntGray: BUFFER std_logic_vector(3 DOWNTO 0));
END CntGray;
-- TXT3.6.4
ARCHITECTURE ArchCntGray OF CntGray IS
SIGNAL BinCode,Added_1: std_logic_vector(3 DOWNTO 0);
BEGIN
-- Gray to Binary conversion: --------------------BinCode(3) <= CntGray(3);
BinCode(2 DOWNTO 0) <= CntGray(2 DOWNTO 0) XOR BinCode(3 DOWNTO 1);
-- Increment -------------------------------------Added_1 <= BinCode + 1;
61
-- Back Binary to Gray conversion, registered ----PROCESS (Clk) BEGIN
IF Clk'EVENT AND Clk = '1' THEN
CntGray(3) <= Added_1(3);
CntGray(2 DOWNTO 0) <= Added_1(2 DOWNTO 0) XOR Added_1(3 DOWNTO 1);
END IF;
END PROCESS;
END ArchCntGray;
Na rozdíl od binárních íta , s nimiž se setkáváme nej ast ji, je zde vytvo ení signálu
p edstavujícího p íští stav íta e složit jší a je rozd leno do uvedených t í ástí: p evod
sou asného stavu kódovaného Grayovým kódem do binárního kódu, inkrement v binárním
kódu a zp tný p evod z binárního kódu na Gray v kód s následujícím zachycením v registru.
Tyto t i ásti zde figurují jako celek místo obvyklého jednop íkazového zápisu inkrementu
u binárního íta e. V popisu posledního p evodu je obsažen registr p edstavující pam ový
blok íta e.
Pokud bychom v textu TXT3.6.4 cht li zm nit po et bit íta e, bylo by nutno ud lat
opravu na mnoha místech. Výhodn jším zp sobem je v p ípad p edpokládané možnosti
zm n po tu bit použít bitové ší ky zadané genericky, jak je to v následujícím textu
TXT3.6.5. Doplníme také íta asynchronní inicializací – napln ním p edem zadaným
obsahem, který v tomto p ípad bude dán konstantou GrInit:
LIBRARY ieee;
-- TXT3.6.5
USE work.std_arith.ALL;
ENTITY CntGray IS
GENERIC(Width: integer := 8);
PORT(Clk,Init: IN
std_logic;
CntGray: BUFFER std_logic_vector(Width-1 DOWNTO 0));
END CntGray;
ARCHITECTURE ArchCntGray OF CntGray IS
CONSTANT GrInit: std_logic_vector(Width-1 DOWNTO 0) := ('1','1',
OTHERS => '0');
SIGNAL BinCode,Added_1: std_logic_vector(Width-1 DOWNTO 0);
BEGIN
-- Gray to Binary conversion: --------------------BinCode(Width-1) <= CntGray(Width-1);
BinCode(Width-2 DOWNTO 0) <= CntGray(Width-2 DOWNTO 0)
XOR BinCode(Width-1 DOWNTO 1);
-- Increment -------------------------------------Added_1 <= BinCode + 1;
-- Back Binary to Gray conversion, registered ----PROCESS (Clk,Init) BEGIN
IF Init = '1' THEN CntGray <= GrInit;
ELSIF Clk'EVENT AND Clk = '1' THEN
CntGray(Width-1) <= Added_1(Width-1);
CntGray(Width-2 DOWNTO 0) <= Added_1(Width-2 DOWNTO 0)
XOR Added_1(Width-1 DOWNTO 1);
END IF;
END PROCESS;
END ArchCntGray;
Po et bit je definován po áte ní hodnotou generické konstanty Width, jejíž hodnota je
zde 8. Pokud bychom cht li zm nit bitovou ší ku íta e, sta í zm nit tuto hodnotu v deklaraci
entity. Podobným zp sobem m žeme také definovat genericky ší ku u p evodník popsaných
v textech TXT3.6.1 až TXT3.6.3.
62
P i asynchronní inicializaci íta e signálem Init získají nejvyšší dva bity hodnotu '1',
ostatní budou nulové. Kdybychom nap íklad cht li, aby p i inicializaci byly nastaveny nap íklad bity CntGray(0) a CntGray(1) a ostatní byly vynulovány, dosáhli bychom toho
nahrazením deklarace konstanty GrInit zápisem s p i azením hodnot bit jejich
vyjmenováním:
CONSTANT GrInit: std_logic_vector(Width-1 DOWNTO 0) :=
(0|1 => '1',OTHERS => '0');
Je však nutno upozornit, že ne všechny systémy jsou schopny zpracovat deklaraci s klí ovým slovem OTHERS, je-li ší ka definována genericky. Nedokáže to nap íklad systém
WebPACK, a konstantu GrInit je zde nutno deklarovat nap íklad formou et zce, který je
nutno p epsat p i zm n parametru Width.
Podobn jako bylo vyloženo pro text TXT3.6.2, vytvo í se p i syntéze bez zvláštních
opat ení z textu TXT3.6.5 vyjád ení bit íta e v p íštím stavu jako funkce t chto bit v souasném stavu ve známém tvaru zápisu SOP (Sum of Products, sou et sou in ). íta se pak
v obvodech PLD realizuje bez problém jen pro nevelké po ty bit , nap íklad v obvodu GAL
22V10 m že být implementován šestibitový íta . Nejv tší po et term je pot ebný pro
nejnižší bit CntGray(0) – u šestibitového íta e je zde pot eba 16 term . P i v tším po tu
bit íta e pot ebný po et term rychle nar stá, a tento r st je exponenciální – p idání dalšího
bitu znamená zdvojnásobení po tu term pro bit CntGray(0). P esv d íme se o tom snadno
ze soubor (report) vytvá ených p i syntéze. Pot ebujeme-li íta s v tším po tem bit ,
m žeme požadavek na po et term snížit tím, že syntetizér p inutíme, aby vytvo il jako díl í
mezivýsledky signál BinCode. U systému WARP toho dosáhneme za azením atributu
synthesis_off do deklarativní ásti architektury za deklaraci signál BinCode a Added_1
(u systému WebPACK je to atribut noreduce, viz poznámku k textu TXT3.6.3):
ATTRIBUTE synthesis_off OF BinCode: SIGNAL IS true;
P evodník Grayova kódu na binární se pak stane samostatnou ástí výsledného obvodu a
bude vytvo en stejn jako p i zpracování textu TXT3.6.3 i co do po tu term . V navazujícím
obvodu provád jícím inkrementaci binárního kódu a zp tný p evod do Grayova kódu je pak
pot ebný po et term nejvyšší pro dva nejvyšší bity íta e a je roven po tu bit íta e. Cenou
za to je v tší zpožd ní kombina ní ásti obvodu, tedy snížení nejvyššího hodinového
kmito tu, a zv tšení po tu makrobun k spot ebovaných pro signál BinCode. Pro v tší po ty
bit íta e, kdy složitost obvodu vytvo eného bez uvedeného atributu rychle roste, se však
stává toto ešení z hlediska nárok na spot ebované prost edky výhodn jším. Hranice
výhodnosti mezi ob ma variantami je podle provedených zkoušek 7 bit . Nap íklad pro
cílový obvod CY7C371I-143 firmy Cypress (nejmenší z ady 370, s 32 makrobu kami) je
sedmibitový íta nejv tší, který lze implementovat bez atributu synthesis_off. Hodinový
kmito et u tohoto íta e m že být p es 80 MHz. S tímto atributem se nejv tší po et bit
zv tší na 14. Pak ale jde o zapojení s 15 pr chody, s nejvyšším hodinovým kmito tem kolem
14 MHz.
Systém WebPACK dokáže bez použití atributu noreduce implementovat v obvodu
XC9536XL íta s 11 bity, s tímto atributem až s 15 bity.
63
4 DODATEK 1: UŽIVATELSKÝ POPIS ZÁKLADNÍCH
OBVOD SPLD
V této ásti jsou popsány vybrané programovatelné logické obvody (jednoduché obvody
PLD – Simple Programmable Logic Devices) tak, aby zde byly soust ed ny údaje pot ebné
pro návrh aplikací t chto obvod , p i emž budou pominuty podrobnosti, které nejsou pro
tento ú el nezbytné. Výb r uvedených obvod bral v úvahu dostupnost t chto obvod i
návrhových prost edk pot ebných pro jejich aplikaci.
Pro návrhá e je rovn ž d ležité znát firmy vyráb jící uvedené obvody. Nejd ležit jší
z t chto firem jsou zde uvedeny zkratkou s následujícím významem: A – Altera, AT – Atmel,
L – Lattice Semiconductor, NS – National Semiconductor, TI – Texas Instruments. Ne
všichni výrobci však uvedené obvody ozna ují názvem, pod nímž jsou zde popsány. V takovém p ípad je tento název uveden v závorce.
4.1 OBVODY GAL 16V8 A GAL 20V8
Uspo ádání t chto obvod a jejich funkce jsou velmi podobné. Z hlediska uživatele jsou
rozdíly pouze v po tu vstupních vývod . To umož uje popsat je spole n .
Oba obvody mají osm výstupních makrobun k, p i emž každé z nich p ísluší osm term .
Obvody mohou být naprogramovány do t í mód : 1 – jednoduchý, 2 – smíšený, 3 – registrový
mód. Na obr. 4.1 a obr. 4.2 jsou vyzna eny vývody obou obvod a jejich funkce v jednotlivých módech. Vývody ozna ené symbolem IN t sn u obrysu obvodu mají ve všech
módech funkci vstup p ivád jících signály do pole AND. Ostatní vývody vyjma napájecích
(VCC a GND) mají v r zných módech r znou funkci, jak je z ejmé z tabulky na obrázcích.
Dva vývody, a to vývod 1 u obou obvod a vývod 11 u GAL 16V8, resp. vývod 13 u GAL
20V8, mají v prvních dvou módech rovn ž funkci vstup do pole AND. V módu 3 plní vývod
1 funkci vstupu hodinového signálu a vývod 11, resp. 13, funkci vstupu OE . Zbývajících osm
vývod je p ipojeno k výstupním makrobu kám. Na obr. 4.3 je vysv tlen význam symbol
p edstavujících funkci t chto vývod . V módu 2 mají všechny jedinou funkci: krajní vývody
(12 a 19, resp. 15 a 22), mají funkci t ístavového výstupu (TS), ostatní fungují jako
kombina ní obousm rné vývody (I/O). Jeden z term vycházejících z pole AND je p itom
v nován ízení t ístavového zesilova e, pro vytvo ení vlastní logické funkce tedy zbývá 7
term . V módu 1 vývody 15 a 16, resp. 18 a 19 plní pouze funkci kombina ního výstupu
(OUT). Všech zbývajících šest vývod m že být v tomto módu vzájemn nezávisle
naprogramováno do funkce vstupu (IN) nebo do funkce kombina ního výstupu se zp tnou
vazbou (OUT/FB). V módu 3 mohou být všechny vývody op t vzájemn nezávisle
nakonfigurovány bu do funkce kombina ních obousm rných vývod (I/O) nebo do funkce
registrových výstup (REG). V registrovém módu máme k dispozici o dva vstupní vývody
mén – jsou to vývody CLK a OE . Zato je u registrových výstup k dispozici plných osm
term pro vytvo ení logické funkce. Zp tná vazba je v tomto módu vedena z výstupu
klopného obvodu, což umož uje nap . innost íta
vytvo ených ve struktu e obvodu
i tehdy, jsou-li výstupní zesilova e ve stavu vysoké impedance.
Výrobce: AT (ATF 16V8, ATF 20V8), L, NS
64
MÓD:
1
(SIMPLE)
2
(COMPLEX)
3
(REGISTERED)
IN
IN
CLK
VCC
1
20
IN
2
19
IN,OUT/FB
TS
I/O,REG
IN
3
18
IN,OUT/FB
I/O
I/O,REG
IN
4
17
IN
5
IN
IN,OUT/FB
I/O
I/O,REG
16
OUT
I/O
I/O,REG
6
15
OUT
I/O
I/O,REG
IN
7
14
IN,OUT/FB
I/O
I/O,REG
IN
8
13
IN,OUT/FB
I/O
I/O,REG
IN
9
12
IN,OUT/FB
TS
I/O,REG
10
11
IN
IN
OE
GND
GAL16V8
Obr. 4.1. Rozložení vývod u obvodu GAL 16V8 a jejich funkce v jednotlivých módech.
Jsou-li uvedeny dv funkce vývod odd lené árkou, lze vybrat nezávisle pro každý vývod
jednu z nich
MÓD:
1
(SIMPLE)
2
(COMPLEX)
3
(REGISTERED)
IN
IN
CLK
1
24
VCC
IN
2
23
IN
IN
3
22
IN,OUT/FB
TS
I/O,REG
IN
4
21
IN,OUT/FB
I/O
I/O,REG
IN
5
20
IN,OUT/FB
I/O
I/O,REG
IN
6
19
OUT
I/O
I/O,REG
IN
7
18
OUT
I/O
I/O,REG
IN
8
17
IN,OUT/FB
I/O
I/O,REG
GAL20V8
IN
9
16
IN,OUT/FB
I/O
I/O,REG
IN
10
15
IN,OUT/FB
TS
I/O,REG
IN
11
14
12
13
IN
IN
OE
GND
IN
Obr. 4.2. Rozložení vývod u obvodu GAL 20V8 a jejich funkce v jednotlivých módech.
Jsou-li uvedeny dv funkce vývod odd lené árkou, lze vybrat nezávisle pro každý vývod
jednu z nich
4.2 OBVOD GAL 22V10 A JEHO VARIANTY
Jak je z ejmé z obr. 4.5, má obvod GAL 22V10 deset vývod p ipojených k výstupním
makrobu kám. Ty mohou být vzájemn nezávisle nakonfigurovány do funkce kombina -
65
pin = IN (vstup):
pole
AND
pin
pin = OUT (jednoduchý kombina ní výstup):
pole
AND
8 term
pin
MÓD 1
pin = OUT/FB (kombina ní výstup se zp tnou vazbou):
pole
AND
8 term
pin
pin = TS (kombina ní t ístavový výstup):
pole
AND
7 term
pin
pin = I/O (kombina ní obousm rný vývod):
pole
AND
7 term
pin
pin = REG (registrový výstup):
CLK
pole
AND
MÓD 2
MÓD 3
TE
8 term
D
pin
C
OE
Obr. 4.3. Možné konfigurace výstupních makrobun k u obvod GAL 16V8 a 20V8.
ozna ené hv zdi kou jsou spole né pro celý obvod
66
ásti
pin = I/O (kombina ní obousm rný vývod):
pole
AND
8-16
term
pin
pin = REG (registrový výstup):
CLK
ar
pole
AND
8-16
term
D
TE
pin
C
AR
SP
sp
Obr. 4.4. Možné konfigurace výstupních makrobun k obvodu GAL 22V10.
ozna ené hv zdi kou jsou spole né pro celý obvod
ásti
ního obousm rného vývodu (I/O) nebo registrového výstupu (REG). Po et term je u jednotlivých makrobun k r zný a pohybuje se od 8 do 16 – tento po et je uveden na obr. 4.5 vedle
67
každého vývodu. Celkový po et term takto využitých je 120. Navíc je pro každou makrobu ku vyhrazen další zvláštní term pro ízení t ístavového zesilova e. Dále jsou pro všechny
makrobu ky k dispozici dva spole né termy, vytvá ející signály ar (asynchronní nulování) a
sp (synchronní nastavení) pro jejich klopné obvody. Celkový po et sou inových term v poli
AND je tedy 132. Hodinové vstupy všech klopných obvod jsou p ipojeny na spole ný
signál CLK z vývodu 1, který m že být sou asn využit jako další vstup do pole AND.
po et
term :
CLK,IN
1
24
VCC
IN
2
23
I/O,REG
8
IN
3
22
I/O,REG
10
IN
4
21
I/O,REG
12
IN
5
20
I/O,REG
14
IN
6
19
I/O,REG
16
IN
7
18
I/O,REG
16
IN
8
17
I/O,REG
14
IN
9
16
I/O,REG
12
IN
10
15
I/O,REG
10
IN
11
14
I/O,REG
8
GND
12
13
IN
GAL22V10
íslování a funkce vývod obvodu
GAL 22V10 v pouzdru PLCC 28:
funkce
CLK,IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
GND
VCC
íslo
2
3
4
5
6
7
9
10
11
12
13
16
14
28
funkce
íslo
po et
term :
I/O,REG
27
8
I/O,REG
26 10
I/O,REG
25 12
I/O,REG
24 14
I/O,REG
23 16
I/O,REG
21 16
I/O,REG
20 14
I/O,REG
19 12
I/O,REG
18 10
I/O,REG
17
8
Ve verzi isp slouží vývody
zde neuvedené k p ivedení
programovacích signál
Obr. 4.5. Rozložení vývod u obvodu GAL 22V10 a jejich funkce
Na rozdíl od obvod GAL 16V8 a GAL 20V8 je zde programovatelný invertor zapojen až
za výstupem klopného obvodu, což má za následek, že p i p ipojení napájecího nap tí je stav
výstupu ur en nakonfigurováním tohoto invertoru. Na n m také závisí, jak se projevuje
ú inek nulování nebo nastavení klopných obvod na vývodech pouzdra. Zapojení vstupních
vývod je shodné s zapojením vstup p edcházejících obvod (obr. 4.3 – pin = IN), výstupy
s funkcí I/O a REG mají strukturu podle obr. 4.4. N kte í výrobci (nap . Lattice) za azují do
struktury integrované rezistory, které jsou zapojeny mezi každým z vývod a p ívodem
napájecího nap tí. Tím je odstran na nutnost p ipojovat tyto rezistory k nevyužitým vývod m
pro definování jejich nap ové úrovn zevn . P esto však se v aplika ních listech obvykle
doporu uje pro zlepšení odolnosti proti rušení p ipojovat nevyužité vstupní vývody a výstupní
vývody ve stavu vysoké impedance k sousedním využitým vstup m nebo k zemnicímu, pop .
k napájecímu p ívodu. Obvod GAL 22V10 pat í v zemích s vysp lou elektronikou k nejoblíben jším obvod m PLD, o emž sv d í velké množství firem vyráb jících jak tento
obvod, tak i jeho r zné modifikace (nap . GAL 18V10, GAL 26CV12 atd.).
Obvod GAL 18V10 je podmnožinou obvodu GAL 22V10. Jeho vnit ní struktura je shodná
s vnit ní strukturou tohoto obvodu, pouze s tím rozdílem, že pro 8 výstupních makrobun k je
k dispozici 8 term a pro dv další 10 term , a celkový po et vstup (v etn zp tnovazebních
vedených z makrobun k) je 18. Pouzd en je v DIL 20. Pro rozsáhlejší aplikace je vyráb n
obvod GAL 26CV12 s 12 makrobu kami shodného provedení jako u základního obvodu.
Osm jeho makrobun k je vybaveno osmi termy, dv desíti a dv dvanácti termy, celkový
po et vstup je 26.
V pouzdru PLCC 28 vyrábí firma Lattice obvod ispGAL 22V10, který je programovatelný
p ímo na desce, na níž je osazen, pouhým po íta em pomocí jednoduchého programovacího
kabelu a p íslušného softwarového vybavení (není zapot ebí zvláštní programovací p ístroj).
68
5 LITERATURA
[1] KOLOUCH, J.: Programovatelné logické obvody – p ednášky. [Skriptum FEKT VUT
v Brn .] Brno, 2002
[2] OTT, D. E. – WILDEROTTER, T. J.: A Designer’s Guide to VHDL. Kluwer Academic
Publishers, 1998
[3] RUSHTON, A.: VHDL for Logic Synthesis. J. Wiley, 2001
[4] SKAHILL, K.: VHDL for Programmable Logic. Addison-Wesley, 1996
[5] WAKERLY, J.: Digital Design – principles and practices. 3rd edition. Prentice Hall,
2001
[6] DEWEY, A.: Analysis and Design of Digital Systems with VHDL. PWS Publishing
Company, 1997
[7] PELLERIN, D. – TAYLOR, D.: VHDL Made Easy. Prentice Hall, 1997
69

3 p íklady konstrukcí v jazyku vhdl

Transkript

Podobné dokumenty

Halloweenské dobroty

ruský slovní přízvuk - Jazyky

zde - Helena Baker

Le temps qui passe - Gymnázium Vysoké Mýto

calendar of activities

sansony.