eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Diplomová práce
Modelování transakcí Bc. Filip Mike²
Vedoucí práce:
Doc. Ing. Ji°í Dou²a, CSc.
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský
Obor: Výpo£etní technika
10. kv¥tna 2012
iv
v
Pod¥kování Na tomto míst¥ bych rád pod¥koval Doc. Ing. Ji°ímu Dou²ovi, CSc. za vedení práce a také za jeho trp¥livost, rady k dané problematice a v¥novaný £as p°i konzultacích k této diplomové práci.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Praze dne 10. 5. 2012
.............................................................
viii
Abstract
The goal of this work is to study current possibilities of simulation platforms for digital design engineering on TLM (Transaction level modeling). Main insistence is provided to simulation tool SystemC, which is detailed described how to create TLM and RTL models, even re ning this model from TLM to RTL. One part of this work includes also a set of particular samples clarifying new concepts on particular examples. At the end of the work are brie y mentioned ability to create TLM models in currently most used HDLs (VHDL, Verilog).
Abstrakt
Cílem této práce je prostudovat sou£asné moºnosti simula£ních program· £íslicových obvod· na úrovni TLM (Transaction level modeling). Hlavní d·raz je zde v¥nován simula£nímu nástroji SystemC, který je podrobn¥ji popsán jak z hlediska vytvá°ení TLM a RTL model·, tak v moºnosti postupného p°echodu mezi t¥mito modely. Sou£ástí práce je také °ada praktických ukázek, které ilustrují vysv¥tlované pojmy na konkrétních p°íkladech. V záv¥ru jsou stru£n¥ zmín¥ny moºnosti vytvá°ení model· na TLM úrovni v sou£asnosti b¥ºných HDL jazycích (VHDL, Verilog).
ix
x
Obsah
1 Úvod
1
1.1
Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 RTL modelování v SystemC
5
2.1
Pro£ SystemC místo C++?
2.2
Tradi£ní HDL jazyky versus SystemC . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Historie vývoje
6
2.4
Prvky jazyka SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4.1
Moduly
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4.2
Prom¥nné a datové typy . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4.3
Porty a rozhraní
2.4.4
Procesy
2.4.5
Kanály . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4.6
Hierarchický popis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.7
Veri kace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.8
len¥ní programového kódu do soubor·
2.4.9
Nastavení £asu
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
. . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4.10 Elaborace a simulace modelu 2.5
5
. . . . . . . . . . . . . . . . . . . . . . .
15
. . . . . . . . . . . . . . . . . . . . . . . . .
16
2.5.1
Modul polovi£ní s£íta£ky . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.5.2
Modul úplné s£íta£ky . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.5.3
Veri kace návrhu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.5.4
Vstupní bod programu . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.5.5
P°eklad programu a zobrazení pr·b¥h· . . . . . . . . . . . . . . . . . .
27
Vzor hierarchického RTL modelu
3 Modelování na úrovni transakcí
29
3.1
len¥ní kapitoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Od TLM-1 k TLM-2.0.1
3.3
Typy blok·
3.4
Abstraktní modely 3.4.1
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Untimed functional modely
. . . . . . . . . . . . . . . . . . . . . . . .
xi
31 32
xii
OBSAH
3.5
3.4.2
Loosely-timed modely (LT modely) . . . . . . . . . . . . . . . . . . . .
3.4.3
Approximately-timed modely (AT modely)
3.4.4
Shrnutí
3.6
3.7
33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Komunikace mezi moduly 3.5.1
33
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Transportní rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.5.1.1
Blokující rozhraní
. . . . . . . . . . . . . . . . . . . . . . . .
35
3.5.1.2
Neblokující rozhraní . . . . . . . . . . . . . . . . . . . . . . .
36
3.5.1.3
Shrnutí
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.5.2
Rozhraní pro p°ímý p°ístup do pam¥ti . . . . . . . . . . . . . . . . . .
42
3.5.3
Ladící rozhraní
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Generic Payload
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.6.1
Atributy a metody . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.6.2
Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.6.3
Address
45
3.6.4
Data pointer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.6.5
Data length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.6.6
Byte enable pointer
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.6.7
Byte enable length . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.6.8
Streaming width
46
3.6.9
DMI allowed
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.6.10 Response status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
Sockety
47
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 TLM modely
49
4.1
len¥ní kapitoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.2
Základní loosely-timed model
. . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.2.1
Zdrojový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.2.2
Cílový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.2.3
Propojení modul·
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.2.4
Vstupní bod programu . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.2.5
Shrnutí
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
Pokro£ilej²í loosely-timed model . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.3.1
Zdrojový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.3.2
Cílový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.3.3
Shrnutí
4.3
4.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
Approximately-timed model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.4.1
Zdrojový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.4.2
Cílový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.4.3
Shrnutí
75
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Up°es¬ování modelu
77
5.1
Postup up°es¬ování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.2
P°íklad p°echodu mezi modely . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.2.1
TLM model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.2.1.1
80
Výpo£etní modul . . . . . . . . . . . . . . . . . . . . . . . . .
xiii
OBSAH
5.2.2 5.3
5.2.1.2
Blok Generator . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.2.1.3
Blok Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
Zjemn¥ný (up°esn¥ný) model
Shrnutí
. . . . . . . . . . . . . . . . . . . . . . .
85
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
6 Podpora TL modelování v ostatních HDL jazycích 6.1
6.2
6.3
91
VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.1.1
Stru£ná historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.1.2
Podpora TLM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
Verilog a SystemVerilog 6.2.1
Stru£ná historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
6.2.2
Podpora TLM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
Shrnutí
7 Záv¥r
97
A Seznam pouºitých zkratek
103
B P°eklad p°íklad·, instalace SystemC a TLM knihovny B.1
Instalace SystemC a TLM knihovny
B.2
P°eklad p°íklad·
105
. . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C Obsah p°iloºeného CD
109
xiv
OBSAH
Seznam obrázk·
1.1
Uplatn¥ní jazyk· v r·zných úrovních implementace modelu [2]
. . . . . . . .
2.1
Schéma zapojení polovi£ní s£íta£ky . . . . . . . . . . . . . . . . . . . . . . . .
17
2.2
Schéma zapojení úplné s£íta£ky . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3
Schéma zapojení testbenche úplné s£íta£ky . . . . . . . . . . . . . . . . . . . .
23
2.4
Pr·b¥h kompilace SystemC programu [2] . . . . . . . . . . . . . . . . . . . . .
28
2.5
Pr·b¥hu signálu ze souboru (k zobrazení pouºit program GTKwave)
. . . . .
28
3.1
Terminologie abstraktních model· [2] . . . . . . . . . . . . . . . . . . . . . . .
32
3.2
Znázorn¥ní mechanism· pouºívaných v LT a AT modelech [10]
. . . . . . . .
34
3.3
Schéma komunikace pro LT modely . . . . . . . . . . . . . . . . . . . . . . . .
34
3.4
asový pr·b¥h dvou transakcí realizovaných p°es blokující rozhraní . . . . . .
37
3.5
asový diagram transakce zp¥tného volání . . . . . . . . . . . . . . . . . . . .
38
3.6
asový diagram transakce s vyuºitím návratové hodnoty . . . . . . . . . . . .
39
3.7
asový diagram transakce s vyuºitím rychlého dokon£ení . . . . . . . . . . . .
40
3.8
Diagram ilustrující získání a pouºití DMI ukazatele . . . . . . . . . . . . . . .
43
4.1
Blokové schéma základního loosely-timed modelu . . . . . . . . . . . . . . . .
50
4.2
Blokové schéma pokro£ilej²ího loosely-timed modelu
59
. . . . . . . . . . . . . .
thread_process )
2
4.3
Vývojový diagram zápisu do cílového modulu (metoda
4.4
Blokové schéma approximately-timed modelu
. . . .
60
. . . . . . . . . . . . . . . . . .
67
4.5
P°echody mezi fázemi v approximately-timed modelu . . . . . . . . . . . . . .
67
4.6
asový diagram transakce zp¥tného volání z p°íkladu Approximately-timed
.
68
4.7
Vývojový diagram metody
. . . . . . . . . . . .
71
cílového modulu . . . . . . . . . . . . . .
75
4.8
peq_cb() Vývojový diagram metody peq_cb()
5.1
P°echod z vy²²í úrovn¥ abstrakce na niº²í
5.2
Blokové schéma modelu s adaptéry v RTL modelu
. . . . . . . . . . . . . . .
79
5.3
Blokové schéma modelu s adaptéry v TLM modelu
. . . . . . . . . . . . . . .
80
5.4
Schéma vzorového TLM modelu . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.5
Schéma bloku
81
5.6
Schéma vzorového RTL modelu . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.7
Schéma bloku
86
Full_adder_TLM
zdrojového modulu
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
Full_adder_wrapper
. . . . . . . . . . . . . . . . . . . . . . . .
xv
78
xvi
SEZNAM OBRÁZK
Seznam tabulek
2.1
Historie vývoje SystemuC
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
N¥které roz²i°ující datové typy
. . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
Simula£ní náro£nost datových typ· . . . . . . . . . . . . . . . . . . . . . . . .
10
2.4
asové jednotky
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5
Pravdivostní tabulka polovi£ní s£íta£ky . . . . . . . . . . . . . . . . . . . . . .
17
2.6
Pravdivostní tabulka úplné s£íta£ky . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1
Základní fáze transakce de nované t°ídou
. . . . . . . . . . . . . .
41
3.2
Návratové hodnoty neblokujícího rozhraní
. . . . . . . . . . . . . . . . . . . .
41
3.3
Návratové hodnoty transportní t°ídy generic payload . . . . . . . . . . . . . .
47
6.1
Verze standardu jazyka VHDL [30] . . . . . . . . . . . . . . . . . . . . . . . .
92
6.2
Verze standardu jazyka Verilog/SystemVerilog [29]
94
xvii
tlm_phase
. . . . . . . . . . . . . . .
6
xviii
SEZNAM TABULEK
Kapitola 1 Úvod
SystemC je ozna£ení pro knihovnu C++ obsahující t°ídy a makra, která stejn¥ jako VHDL
1 jazyky, tedy jazyky pro popis hardwaru. Lze tedy
£i Verilog, slouºí jako takzvané HDL
modelovat paralelní chování hardwarových komponent, vým¥nu dat mezi komponentami pomocí signál· a mnoho dal²ích £inností charakteristických pro HDL jazyky. Sémantika se vyzna£uje o n¥co komplikovan¥j²ími konstrukty pro popis na RTL úrovni. Na druhou stranu umoº¬uje vyuºívat programové konstrukty a datové typy jazyka C++, £ímº se usnad¬uje modelování algoritm· a obecn¥ chování jednotlivých komponent. Hlavní odli²ností SystemuC je fakt, ºe zatímco VHDL a Verilog se pouºívají pro popis chování obvodu na úrovni RTL, SystemC je primárn¥ ur£en pro simulaci obvod· na vy²²í úrovni abstrakce. Tato vy²²í úrove¬ modeluje komunikaci mezi jednotlivými £ástmi návrhu na úrovni transakcí. Z tohoto d·vodu
2
se vytvá°ení takovýchto model· nazývá modelování na úrovni transakcí (TLM ). Jak jiº bylo zmín¥no, SystemC umoº¬uje simulovat obvody také na úrovni RTL. To lze s výhodou vyuºít p°i postupu, kdy je nejprve navrºen a veri kován obvod na úrovni TLM a následn¥ je jeho speci kace up°es¬ována. Výsledkem pak m·ºe být navrºený RTL obvod, který je moºné veri kovat stejným veri ka£ním testem jako model v TLM. Výhodou tohoto postupu je, ºe oba modely, veri ka£ní program (testbench) i jednotlivé kroky up°es¬ování modelu, jsou provedeny ve stejném jazyce. 1
Hardware Description Language
2
Transaction Level Modeling
1
2
KAPITOLA 1.
ÚVOD
Dal²í motivací pro vývoj SystemuC je sjednocení návrhu pod spole£ný jazyk. A tím uleh£it sou£asný vývoj hardwarových a softwarových sou£ástí systému. Ostatní jazyky se p°eváºn¥ snaºí zacílit sv·j potenciál na pouºití ve speci ckých oblastech. Samotné C/C++ je ur£eno p°edev²ím pro nízkoúrov¬ové programování. Podpora pro hardwarový návrh v n¥m jiº chybí. Java je jazyk aº p°íli² vysokoúrov¬ový na pouºití pro návrh hardware a podpora zde také chybí. I kdyº jisté pokusy o roz²í°ení Javy v tomto sm¥ru také existují (viz. nap°íklad JHDL [22]). VHDL a Verilog byly od po£átku navrºeny pro simulaci a syntézu digitálních obvod·. Chybí ale podpora algoritmických popis· chování model·. Vera je jazyk pro funk£ní veri kaci komplexních ASIC obvod·. SystemVerilog je roz²í°ení Verilogu, které roz²i°uje moºnosti o celou °adu veri ka£ních moºností. Obrázek 1.1 ukazuje uplatn¥ní jednotlivých jazyk· v r·zných úrovních implementace modelu.
Obrázek 1.1: Uplatn¥ní jazyk· v r·zných úrovních implementace modelu [2]
I p°es tyto jednozna£né výhody SystemuC lze nalézt i nevýhodu. Tou je dosud nep°íli² roz²í°ená podpora p°ímé syntézy model·. Existuje sice n¥kolik nástroj· jako Catapult C [14] od rmy Mentor Graphics, £i n¥které dal²í (hlavn¥ akademické nástroje), které syntézu umoº¬ují. Nicmén¥ v¥t²ina t¥chto nástroj· nesyntetizuje modely p°ímo, ale pouze p°es generování RTL kódu ve VHDL nebo Verilogu. V budoucnu by ale i tento nedostatek m¥l zmizet. V pracovní verzi se uº nachází návrh na standardizaci syntetizovatelné podmnoºiny
1.1.
3
MOTIVACE
jazyka [12], který by v budoucnu m¥l usnadnit vývoj softwarových produkt· umoº¬ujících p°ímou syntézu.
O rozvoj a propagaci SystemuC se do prosince lo¬ského roku starala nezisková organizace OSCI, Open SystemC Initiative. Od po£átku tohoto roku p°e²la starost o vývoj standardu pod organizaci Accellera, která zahrnuje °adu rem a organizací zam¥°ujících se na návrh a veri kaci digitálních obvod·. Cílem organizace je nejenom rozvoj samotného SystemuC jako takového, ale také podpora vývoje nových nástroj· a zavád¥ní metodologií. Standard jazyka byl pod dozorem OSCI schválen jako IEEE 1666-2005 pod názvem SystemC Language Reference Manual [6] a je voln¥ k dispozici.
1.1 Motivace RTL úrove¬ návrhu £íslicových systém· znamená návrh hardwarových modul·, které zahrnují dv¥ zákládní sou£ásti datovou cestu a °adi£. Datová cesta je strukturní zapojení pam¥´ových modul· (registry, pam¥ti), funk£ních blok· (ALU, MUX,
. . .)
a samotných datových cest
(propojení). adi£ popisuje chování, tedy jak data putují z pam¥´ových modul· do funk£ních blok· a zp¥t, dále popisuje které výpo£ty budou provedeny a celkov¥ jak bude datová cesta v pr·b¥hu výpo£tu vyuºita. V¥t²ina dne²ních b¥ºn¥ pouºivaných HDL jazyk· a nástroj· je práv¥ zam¥°ena na návrh £íslicových obvod· na této úrovni.
Vy²²í úrovn¥ abstrakce jsou obecn¥ ozna£ovány jako systémové (system levels). Nepanuje obecná shoda na jaký po£et podúrovní je vhodné d¥lit systémovou úrove¬. Na £em v²ak shoda existuje je fakt, ºe je výhodné de novat transak£ní úrove¬ v rámci úrovn¥ systémové [11]. Tato transak£ní úrove¬ pracuje s pojmem £asových závislostí, nede nuje je v²ak aº na úrove¬ hodinových takt·. To jí p°edur£uje k pouºití ve výkonnostních analýzách, v prvních fázích vývoje a tzv. golden test patterns generation, kde je p·vodní model pouºit pro veri kaci následn¥ vyvíjených model·. Pouºití této úrovn¥ v sob¥ skrývá potenciál zrychlení vývoje a sníºení nárok· na simulaci.
SystemC je jazyk, který umoº¬uje modelování jak na b¥ºné RTL úrovni, tak na úrovni transak£ní, kterou je²t¥ dále zjem¬uje na dal²í úrovn¥. Cílem tohoto jazyka je poskytnout
4
KAPITOLA 1.
ÚVOD
moºnost modelovat £íslicové obvody v rámci jediného jazyka na více úrovních abstrakce a plynule mezi nimi p°echázet [11].
1.2 Cíl práce Cílem této práce je prostudovat a popsat p°ístup k modelování a simulaci hardware na tzv. transak£ní úrovni. Jako hlavní jazyk, kterému bude v¥nována v¥t²ina vysv¥tlovaných pojm· a demonstra£ních p°íklad·, byl vybrán SystemC, který má velký potenciál v této oblasti. A to hlavn¥ z toho d·vodu, ºe je pln¥ kompatibilní se syntaxí jazyka C++. Krom¥ princip· TLM modelování jsou samoz°ejm¥ popsány i konstrukty jazyka slouºící pro vytvá°ení model· na úrovni RTL, £ehoº je dále vyuºito v dal²í £ásti práce, která se zabývá p°echodem mezi modely z úrovn¥ TLM na úrove¬ RTL. Dále jsou v práci uvedeny moºnosti vytvá°ení TLM model· v dal²ích dnes b¥ºných HDL jazycích, jejich srovnání a p°edpokládáný budoucí vývoj.
1.3 Struktura práce Práce je rozd¥lena do sedmi kapitol. V úvodní kapitole je £tená° seznámen s problematikou, které se práce v¥nuje a jsou zde uvedeny n¥které vysv¥tlující pojmy. Následuje kapitola popisující základní syntaxi jazyka SystemC s d·razem na konstrukty pouºívané v RTL modelování. T°etí kapitola je v¥nována problematice vytvá°ení TL model·, které jsou zde detailn¥ popsány po formální stránce. V následující kapitole jsou jiº na demonstra£ních p°íkladech ukázány d°íve vysv¥tlené pojmy. Kapitola p¥t se zabývá postupným zjem¬ováním TL model· na úrove¬ RTL a veri kací t¥chto model·. Následuje ²está kapitola, kde jsou stru£n¥ zmín¥ny jazyky VHDL a Verilog a jejich moºnosti vytvá°ení model· na vy²²ích úrovních abstrakce. V záv¥re£né kapitole jsou pak shrnuty poznatky získané v pr·b¥hu práce a její p°ínosy.
Kapitola 2 RTL modelování v SystemC
V této kapitole jsou uvedeny rozdíly jak oproti klasickým programovacím jazyk·m, tak i proti HDL jazyk·m. Je stru£n¥ zmín¥na historie vývoje SystemuC a dále budou popsány základní konstrukty jazyka umoº¬ující vytvá°ení RTL model· obdobných jako ve VHDL £i ve Verilogu. Po obecném seznámení bude v²e demonstrováno na vzorovém p°íkladu.
2.1 Pro£ SystemC místo C++? Klasické programovací jazyky jako C++ se vyzna£ují sekven£ním provád¥ním programového kódu. Z tohoto d·vodu není C++ sám o sob¥ vhodný pro modelování paralelního chování charakteristického pro hardwarové komponenty. Dále je oby£ejn¥ nutné v rámci modelování pouºívat £asové spoºd¥ní, hodinový signál a obecn¥ pracovat s £asovými závislostmi. Komunikace pomocí port· a signál·, £i datové typy pouºívané v jazycích pro popis hardwaru jsou také v C++ z hlediska pouºitelnosti nedostate£né. V²echny tyto nedostatky se SystemC snaºí odstranit.
2.2 Tradi£ní HDL jazyky versus SystemC SystemC má spoustu, hlavn¥ sémantických vlastností, spole£ných s tradi£ními HDL jazyky a spolu s dal²ími vlastnostmi týkajících se skute£nosti, ºe jazyk je roz²í°ením jazyka C++ se jedná o mocný nástroj. T¥mito roz²i°ujícími vlastnostmi oproti nap°íklad Verilogu £i
5
6
KAPITOLA 2.
RTL MODELOVÁNÍ V SYSTEMC
VHDL je moºnost pouºití ²ablon t°íd £i v¥t²í volnost v tvorb¥ sloºit¥j²ích výraz·. I p°esto, ºe SystemC p°ímo vychází z C++ (k p°ekladu zdrojových kód· je pouºit stejný kompilátor), nej£ast¥ji se o n¥m mluví jako o samostatném jazyku pat°ící do skupiny HDL jazyk· spo-
1 návrh a veri kace
jovaném s pojmy vy²²í abstrakce návrhu digitálních obvod· jako je ESL nebo TLM[2].
Co se tý£e porovnání simula£ního výkonu tradi£ních HDL jazyk· se SystememC na úrovni RTL modelování, zpravidla se uvádí, ºe výkon komer£ních implementací VHDL i Verilogu je optimáln¥j²í, tudíº výkon¥j²í neº samotný SystemC.
2.3 Historie vývoje Zaloºení Open SystemC Initiative bylo oznámeno na konci roku 1999, vydání první verze SystemuC se uskute£nilo jiº na za£átku roku 2000. První verze obsahovala základní funk£nost jako je hierarchické £len¥ní modul·, jejich propojení, de nici £asových závislostí v£etn¥ mechanismu delta cykl·, více stavovou logiku a de nici n¥kterých rezolu£ních funkcí. Od verze 2 se vývoj zam¥°il na vy²²í úrove¬ abstrakce model·. Byla tedy p°idána podpora pro TLM, která je postupn¥ dále roz²i°ována.
9/1999
oznámeno zaloºení OSCI
3/2000
vydána verze SystemC 0.91
4/2000
vydána verze SystemC 1.0
2/2001
vydána speci kace SystemC 2.0
6/2003
vydán Language reference manual pro SystemC 2.0.1
6/2005
vydán Language reference manual pro SystemC 2.1 a standard pro TLM 1.0
12/2005
IEEE schválilo standard jako SystemC jako IEEE 16662005
4/2007
vydána verze SystemC 2.2
6/2008
vydán standard pro TLM 2.0.0
7/2009
vydáno LRM pro TLM 2.0.0
Tabulka 2.1: Historie vývoje SystemuC 1
Electronic system level
2.4.
7
PRVKY JAZYKA SYSTEMC
2.4 Prvky jazyka SystemC Jak jiº bylo d°íve zmín¥no, SystemC je knihovna roz²i°ující moºnosti jazyka C++ o nové datové typy b¥ºn¥ pouºívané pro hardwarový návrh jako jsou bitové nebo vektorové datové typy. Dal²ím roz²í°ením jsou moduly, procesy, události nebo kanály. Tato roz²í°ení jsou obdobou entit, proces·, citlivostních seznam· a signál· pouºívanými ve VHDL. Rozdíl je hlavn¥ v terminologii a syntaktickém zápisu, který se pokusím ve zbytku kapitoly £tená°i oz°ejmit.
2.4.1 Moduly Modul v SystemuC je ekvivalentní modulu ve Verilogu £i entit¥ ve VHDL. Jedná se o základ hierarchického popisu a v zásad¥ o základní stavební blok ze kterého jsou modely sestaveny. Umoº¬ují návrhá°i rozd¥lit návrh do men²ích £ástí a skrýt p°ed okolními moduly implementaci jeho funkce. V terminologii jazyka C++ je modul t°ídou, která d¥dí z existující t°ídy
sc_module.
Moduly mezi sebou komunikují pomocí kanál· a port·. Oby£ejn¥ modul
obsahuje n¥kolik proces·, které modelují jeho poºadované chování. Dále se v t¥le modulu provádí deklarace port·, proces·, kanál· a instanciace submodul·. Deklaraci modulu je moºné provést dv¥ma zp·soby:
1. Pomocí makra SC_MODULE.
2. Pouºitím d¥di£nosti ze t°ídy
sc_module
po vzoru C++.
První moºnost je vhodné pouºít v situaci, kdy konstruktor obsahuje pouze jeden parametr a to jméno modulu. V opa£ném p°ípad¥ jsme nuceni pouºít druhý zp·sob, který nám dává v¥t²í volnost. Nejsme omezeni pouze jedním parametrem v konstruktoru, ale parametr· lze pouºít libovolné mnoºství. Nevýhodou je ale nutnost modul explicitn¥ registrovat p°íkazem
SC_HAS_PROCESS( NazevModulu ) lad deklarace modulu pomocí
a celkov¥ del²í zápis, který sniºuje p°ehlednost. P°ík-
SC_MODULE
je ve výpisu 2.1, pomocí d¥di£nosti ve výpisu
2.2. Oba zápisy jsou z hlediska sémantiky shodné. V druhém p°ípad¥ je vid¥t del²í zápis, kterému se v²ak v n¥kterých p°ípadech nevyhneme.
8
KAPITOLA 2.
Listing 2.1: Deklarace modulu pomocí SC_MODULE
1
2
3
SC_MODULE ( NazevModulu ) { public : SC_CTOR ( NazevModulu )
4
{
5
// t¥lo konstruktoru
6
}
7
8
};
Listing 2.2: Deklarace modulu pomocí d¥di£nosti
1
2
3
class NazevModulu : public sc_module { public : SC_HAS_PROCESS ( NazevModulu );
4
NazevModulu ( sc_module_name name ) : sc_module ( name )
5
{
6
// t¥lo konstruktoru
7
}
8
9
RTL MODELOVÁNÍ V SYSTEMC
};
2.4.2 Prom¥nné a datové typy Datové typy poskytované jazykem C++ jsou zpravidla 8, 16, 32 nebo 64-bitové. To je obvykle aº p°íli² omezující pro modelování v HDL jazycích. Proto SystemC zavádí roz²i°ující datové typy ur£ené k lep²ímu p°ízp·sobení nap°íklad z hlediska po£tu bit·, které zabírá v pam¥ti nebo pro lep²í práci s bitovými nebo vícehodnotovými vektory. Mezi nov¥ zavád¥nými datovými typy jsou jak integerové typy s voliteln¥ de novanou bitovou délkou a p°idanými pomocnými funkcemi, tak datové typy pracující v pohyblivé °ádové £árce. Samoz°ejmostí je implementace vícehodnotových datových typ·. Ve výpisu 2.3 je ukázka deklarace prom¥nné 8-bitového dvouhodnotového vektoru v SystemuC.
2.4.
1
9
PRVKY JAZYKA SYSTEMC
Listing 2.3: Deklarace prom¥nné typu sc_bv (SystemC bit vector)
sc_bv <8 > bus ;
V tabulce 2.2 jsou uvedeny nejb¥ºn¥j²í datové typy pouºívané v HDL jazycích. Kompletní seznam datových typ· je dostupný v o ciální dokumentaci SystemuC[6]. Datové typy pouºívané v C++ je moºné pouºívat sou£asn¥ s t¥mito speciálními typy, dokonce je jejich pouºití výhodn¥j²í v p°ípadech, kde nejsou speciální typy poºadovány z d·vodu men²í pam¥´ové potaºmo simula£ní náro£nosti. V tabulce 2.3 jsou uvedeny datové typy a doporu£ení pro jejich pouºití v závislosti na potenciálním zpomalení simulace. azení je provedeno od nejmén¥ náro£ných typ· po nejnáro£n¥j²í.
datový typ
význam
sc_bit
dvouhodnotová logika
sc_logic
£ty°hodnotová logika (0, 1, X, Z)
sc_bv
vektor N prvk· typu sc_bit
sc_lv
vektor N prvk· typu sc_logic
sc_int<W>
W-bitový integer, (W
sc_uint<W>
W-bitový kladný integer, (W
sc_bigint<W>
W-bitový integer
sc_biguint<W>
W-bitový kladný integer
sc_ xed<W>
W-bitové £íslo v pevné °ádové £árce
sc_u xed<W>
kladné W-bitové £íslo v pevné °ádové £árce
≤
64)
≤
64)
Tabulka 2.2: N¥které roz²i°ující datové typy
2.4.3 Porty a rozhraní Porty slouºí k propojení a ke komunikaci modulu s okolím. Z d·vodu jejich dostupnosti z vn¥ musí být deklarovány v modulu v bloku vaných port· jako
public.
SystemC podporuje °adu p°edde no-
sc_in<>, sc_out<>, sc_inout<> a dal²í. Samoz°ejmostí je také moºnost
vytvá°et vlastní porty. To je moºné pomocí obecné t°ídy sc_port<> a takzvaných tozhraní.
10
KAPITOLA 2.
výkonnost datového typu rychlý
RTL MODELOVÁNÍ V SYSTEMC
datový typ nativní C/C++ datové typy sc_int nebo sc_uint sc_logic nebo sc_lv sc_bigint nebo sc_biguint
pomalý
p°idané xed-point typy
Tabulka 2.3: Simula£ní náro£nost datových typ·
Rozhraní slouºí pro de nici funkce portu, který toto rozhraní vyuºívá. Kaºdý port implementuje práv¥ jedno rozhraní. Rozhraní je £ist¥ deklara£ní (obsahuje pouze virtuální funkce) a neobsahuje funk£ní implementaci, která je provedena p°ímo v komunika£ním kanále. Kanál (viz. 2.4.5) musí implementovat v²echny metody de nované v rozhraní. P°íklad deklarace portu je ve výpisu 2.4.
Listing 2.4: Deklarace portu
1
2
sc_in < bool > clk
// deklarace p°eddefinovaného portu sc_in<>
sc_port < sc_signal_in_if < bool > , 1 > clk ;
// vlastní port
V prvním zápisu je pouºit p°edde novaný port, druhý je pak sémanticky shodný jen je vyuºita obecná t°ída
sc_port<> a rozhraní sc_signal_in_if<>. Rozhranní sc_signal_in_if<>
de nuje sadu operací, které je moºné s portem provád¥t. Nap°íklad funkce
read()
nebo
de-
fault_event() jsou de novány pomocí rozhraní sc_signal_in_if<> [6, str. 103]. Parametr ve ²pi£atých závorkách ur£uje datový typ pouºitelný ke komunikaci a posledním parametrem je maximální po£et kanál· které mohou být k portu p°ipojeny. Typicky jde o hodnotu jedna, pokud pouºijeme hodnotu vy²²í, mluvíme o multiportu. Posledním parametrem m·ºe být de nice pravidel pro p°ipojování port· (ve výpisu 2.4 není uveden). Podrobn¥ji v [6, str. 71].
2.4.4 Procesy Procesy slouºí k popisu chování modelu £i jako generátory stimul· pro testovaný obvod. Jedná se o klasickou funkci jak jí známe z C++, kterou registrujeme jako proces. Registrací
2.4.
11
PRVKY JAZYKA SYSTEMC
ur£íme typ procesu p°ípadn¥ de nujeme citlivostní seznam. Lze de novat t°i typy proces·:
SC_METHOD Nejb¥ºn¥ji pouºívaný proces. Jeho spu²t¥ní je naplánováno po události na signálu, který de nujeme v citlivostním seznamu. Lze ho spou²t¥t opakovan¥ b¥hem simulace. Nelze do n¥j vkládat £ekací p°íkazy
wait().
SC_THREAD Oproti SC_METHOD se v zásad¥ li²í ve dvou v¥cech. První je, ºe tento proces je spu²t¥n a b¥ºí po celou dobu simulace (podobn¥ jako ve Verilogu). Druhou je pak moºnost pouºít p°íkaz
wait()
always
proces
a tím sám sebe uspat na
stanovený okamºik nebo událost na signálu. Z této vlastnosti také vyplívá, ºe syntéza tohoto procesu není moºná a proto se pouºívá k tvorb¥ stimul· pro testovaný obvod.
SC_CTHREAD Jedná se o speciální p°ípad procesu SC_THREAD. Pouºívá se jako proces citlivý na hodinové signály. Nicmén¥ stejn¥ dob°e poslouºí i proces SC_THREAD. Od jeho pouºívání se nyní spí²e ustupuje.
Proces SC_METHOD je tedy spu²t¥n pokud je v daném delta cyklu zaznamenána aktivita na signálu uvedeném v citlivostním seznamu. SC_THREAD oby£ejn¥ obsahuje ve svém t¥le nekone£ný cyklus, který se provádí periodicky po celou dobu simulace. V tomto procesu je moºné generovat hodinový signál £i sekvenci stimul·. Procesy SC_THREAD jsou oproti proces·m SC_METHOD náro£n¥j²í p°i vykonávání a p°epínání mezi procesy, proto je vhodné preferovat procesy SC_METHOD v situacích kdy je moºné pouºít oba. Deklarace se provádí v konstruktoru modulu, kde pouºíváme proces. Procesy nejsou hierarchické a proto není moºné vytvá°et procesy uvnit° jiných proces·. P°íklady registrace proces· budou dále uvedeny v sekci 2.5.
2.4.5 Kanály V realném sv¥t¥ komunikuje hardware p°es piny nebo porty, ve VHDL komunikují procesy a entity skrze signály. Ve Verilogu je to podobné, komunikace probíhá p°es dráty (wires). Ani SystemC se v tomto ohledu p°íli² neli²í, Komunikace probíhá p°es kanály bu¤ p°ímo, pokud komunikace probíhá v rámci jednoho modulu nebo pokud se jedná o komunikaci mimo modul, p°ipojí se p°es porty modulu.
12
KAPITOLA 2.
RTL MODELOVÁNÍ V SYSTEMC
Kanály lze rozd¥lit do dvou kategorií:
1. Primitivní kanály
2. Hierarchické kanály
Hlavním rozdílem je rozsah poskytovaných funkcí. Primitivní kanály poskytují základní a rychlou moºnost komunikace, která v²ak dosta£uje poºadavk·m prosté vým¥ny dat mezi moduly. Naproti tomu hierarchické kanály mohou, jak název napovídá obsahovat hierarchii proces· £ímº se ve své podstat¥ podobají modul·m. Jejich vyuºití je ur£eno pro modelování komplexních komunika£ních sb¥rnic jako jsou PCI, HyperTransport, AMBAnebo AXI[2]. Mezi primitivní kanály pat°í nap°íklad nikaci. Dále to jsou kanály
sc_mutex
a
sc_signal
a
sc_ fo, které zaji²´ují prostou komu-
sc_semaphore
slouºící jako komunika£ní primitiva
zaji²´ující výlu£ný p°ístup. SystemC také umoº¬uje vytvá°ení vlastních kanál· coº se m·ºe v °ad¥ p°ípad· hodit. Moºnost vytvá°et vlastní kanály (signály nebo dráty) není v HDL jazycích úpln¥ b¥ºná.
2.4.6 Hierarchický popis Hierarchie znamená takové uspo°ádání, ve kterém je kaºdý prvek (modul) krom¥ nejvy²²ího pod°ízen práv¥ jednomu nad°ízenému. Schéma hierarchie tak tvo°í strom ze kterého je toto uspo°ádání jednozna£né. Toto je velice d·leºitá vlastnost jak SystemuC, tak i jiných HDL jazyk·. Dovoluje nám logické rozd¥lení funkce do jednotlivých modul·, které lze do nad°azených modul· p°idávat jako hotové funk£ní bloky. To usnad¬uje celou °adu krok· ve vývoji modelu. Tímto se jednak zvý²í p°ehlednost a zlep²í moºnosti dal²ího vyuºití funk£ních blok· v dal²ích návrzích. P°íklad hierarchického popisu je na obrázku 2.2, kde je znovu pouºit model
half_adder
ve dvou instancích v nad°azeném modelu
full_adder.
2.4.7 Veri kace Po vytvo°ení modelu je samoz°ejm¥ nutné námi vytvo°ený model veri kovat, tzn. ov¥°it jeho správnou funkci. To lze v zásad¥ provést dv¥ma zp·soby.
2.4.
13
PRVKY JAZYKA SYSTEMC
1. Vytvo°ením dvou modul·, kde první bude vytvá°et stimuly pro testovaný obvod v£etn¥ hodinového signálu. Druhý bude odezvu obvodu zachytávat a porovnávat výstupy s o£ekávanou odezvou. Vstupy a výstupy je samoz°ejm¥ nutné p°edem de novat v externím souboru. Celý proces veri kace je následn¥ automaticky provád¥n bez nutnosti zásahu uºivatele.
2. Druhou moºností je vytvo°it pouze jeden modul, který bude slouºit k vytvá°ení stimul·. V hlavní funkci
sc_main
pak vytvo°it soubor, který bude slouºit k ukládání stimul· a
odezev. K tomuto ú£elu existují p°edde nované konstrukty a funkce, které se postarají
2
o správné formátování souboru do formátu VCD , aby mohl být následn¥ zobrazen pomocí standardních nástroj· dostupných na ruzných platformách jako je nap°íklad program GTKWave.
První varianta je vhodná pro automatickou kontrolu výstup·. Je moºné de novat pravidla, která se automaticky kontrolují a v p°ípad¥ poru²ení je vypsáno chybové hlá²ení. Druhá varianta je vhodná pokud chceme pozorovat chování jednotlivých vstup· a výstup· v p°ehledné form¥ podobn¥ jako VHDL modely nap°íklad v programu Modelsim.
2.4.8 len¥ní programového kódu do soubor· V C++ existuje konvence podle které je doporu£eno programy d¥lit do hlavi£kových a implementa£ních soubor·. V hlavi£kových souborech je uvedena pouze deklarace funkcí, zatímco v implementa£ních pak následuje de nice v²ech funkcí. Podobnou konvenci je vhodné pouºít i ve zdrojových souborech SystemC. Pouºití sice není nezbytné a tak je moºné v²e psát pouze do jednoho souboru, ale rozd¥lením do dvou soubor· se zlep²í £itelnost kódu. Nap°íklad v [2] jsou uvedeny dv¥ varianty zápisu hlavi£kového a implementa£ního souboru. Jeden ozna£ený jako tradi£ní uvádím ve výpisu 2.5 resp. 2.6. Tento zp·sob budu také ve zdrojových kódech vyuºívat. Druhý tzv. alternativní se li²í v tom, ºe konstruktor je p°esunut z hlavi£kového do implementa£ního souboru. V této druhé variant¥ je více detail· p°ed uºivatelem skryto v implementa£ním souboru.
2
Value Change Dump
14
KAPITOLA 2.
Listing 2.5: Tradi£ní forma hlavi£kového souboru v SystemC
1
2
3
4
# ifndef NAME_H # define NAME_H # include " submodule .h " SC_MODULE ( NAME ) { // deklarace port·
5
// instanciace kanál·/submodul·
6
// deklarace funkcí/proces· (nap°. Process, Helper...)
7
SC_CTOR ( NAME )
8
: inicializace
9
{
10
// propojení
11
// registrace proces·
12
}
13
// destruktor
14
15
16
}; # endif
1
2
3
4
RTL MODELOVÁNÍ V SYSTEMC
Listing 2.6: Tradi£ní forma implementa£ního souboru v SystemC
# include < systemc > # include " NAME . h" NAME :: Process { implementace } NAME :: Helper { implementace }
2.4.9 Nastavení £asu SystemC pouºívá k vyjád°ení £asu t°ídu
sc_time.
Tato t°ída reprezentuje 64bitovou hod-
notu, která je na za£átku simulace vynulováná a následn¥ slouºí pro ur£ení aktuálního £asu. Nastavení simula£ní jednotky ve které bude £as m¥°en je nutné je²t¥ p°ed samotnou simulací, v tzv. elabora£ní fázi. Defaultní hodnota je 1 pikosekunda, ale je samoz°ejm¥ moºné tuto jednotku nastavit jinak a to od jedné femtosekundy aº po jednu sekundu. Intern¥ je
2.4.
15
PRVKY JAZYKA SYSTEMC
tedy v SystemuC £as reprezentován celo£íselnou hodnotou násobenou nastavenou simula£ní jednotkou. V pr·b¥hu simulace je samoz°ejm¥ moºné £as zji²´ovat a dále s ním pracovat. Ve výpisu 2.7 je ukázka nastavení simula£ního kroku (jednotky) na 1 ns a zji²t¥ní aktuálního £asu. Dále jsou v tabulce 2.4 uvedeny jednotky pro práci s £asem a jejich zápis, který je nutné pouºít.
Listing 2.7: Funkce pro práci s £asem
1
2
sc_set_time_resolution (1 , SC_NS ); // nastavení simula£ního kroku sc_time_stamp (); // vrací aktuální £as
vý£tový typ
jednotka
vyjád°ení
SC_FS
femtosekunda
10−15
SC_PS
pikosekunda
10−12
SC_NS
nanosekunda
10−9
SC_US
mikrosekunda
10−6
SC_MS
milisekunda
10−3
SC_SEC
sekunda
1
Tabulka 2.4: asové jednotky
2.4.10 Elaborace a simulace modelu Lze uvaºovat dv¥ hlavní fáze vytvo°eného programu (modelu):
1. Elaborace
2. Simulace
N¥kdy je je²t¥ uvád¥na t°etí post simula£ní fáze, kdy jsou uvoln¥ny p°ípadn¥ dynamicky alokované pam¥´ové prost°edky. Z programového hlediska je elabora£ní fáze ta, kdy se vytvá°ejí datové konstrukty a moduly provád¥jí kód konstruktoru. To znamená registrují procesy, propojují submoduly a
16
KAPITOLA 2.
RTL MODELOVÁNÍ V SYSTEMC
procesy £i dal²í operace typické pro sestavení modelu. Prakticky tato fáze trvá od spu²t¥ní zkompilovaného programu aº po okamºik neº je zavolána funkce
sc_start().
Simula£ní fáze
je následn¥ kontrolována simula£ním jádrem, které zaji²´uje pseudo-paralelní provád¥ní programu.
2.5 Vzor hierarchického RTL modelu V kapitole 2.4 byli popsány jednotlivé konstrukty jazyka SystemC pouºívané pro popis modelovaného obvodu. V této £ásti bude uveden praktický p°íklad návrhu v SystemuC, který se pokusí oz°ejmit v²echny nové pojmy na praktickém p°íkladu.
Celý p°íklad p°edstavuje nejprve návrh polovi£ní s£íta£ky, která bude následn¥ pouºita v hierarchickém popisu pro vytvo°ení úplné s£íta£ky. Posledním krokem je veri kace návrhu, tzn. vytvo°ení vstupních stimul· p°ipojených na vstup testovaného obvodu a následné zobrazení pr·b¥hu t¥chto vstupních stimul· a výstupního signálu.
2.5.1 Modul polovi£ní s£íta£ky Polovi£ní s£íta£ka jak uº název napovídá je obvod, který je schopen £áste£n¥ provád¥t sou£et. Tato £áste£nost spo£ívá v tom, ºe vstupem jsou pouze dv¥ binární hodnoty a výstupem jiné dv¥ binární hodnoty, které p°edstavují hodnotu sou£tu signál· na vstupu. To je ale pro s£ítání vícebitových operand· nedostate£né, protoºe nelze tuto s£íta£ku zapojit do kaskády pro s£ítání vícebitových operand·. Kv·li této vlastnosti se s£íta£ce °íká polovi£ní (
angl. half
adder ). Pravdivostní tabulka 2.5 p°edstavuje její funkci.
Z pravdivostní tabulky lze pozorovat, ºe výstup
sum
se nachází v logické jedni£ce pokud
jsou vstupy r·zné. Tomuto chování odpovídá logická funkce XOR. Výstup
carry
nabývá
logické jedni£ky pouze pokud jsou oba vstupy aktivní, tzn. logické funkci AND. Schéma zapojení z logických hradel je na obrázku 2.1.
2.5.
17
VZOR HIERARCHICKÉHO RTL MODELU
a
b
sum
carry
0
0
0
0
0
1
1
0
1
0
1
0
1
1
0
1
Tabulka 2.5: Pravdivostní tabulka polovi£ní s£íta£ky
Obrázek 2.1: Schéma zapojení polovi£ní s£íta£ky
Ze schématu zapojení je vid¥t, ºe se jedná o velice jednoduchý obvod. Jak jiº bylo uvedeno v kapitole 2.4.8 jsou v²echny modely modul· rozd¥leny do dvou soubor·, hlavi£kového a implementa£ního. Hlavi£kový soubor je uveden ve výpisu 2.8.
1
2
Listing 2.8: Hlavi£kový soubor polovi£ní s£íta£ky
# ifndef HALF_ADDER_H # define HALF_ADDER_H
3
4
# include " systemc . h"
5
6
7
8
SC_MODULE ( half_adder ) { sc_in < bool > a , b ;
// deklarace port·
sc_out < bool > sum , carry ;
9
10
11
void prc_half_adder ();
// modul má jedinou metodu
18
KAPITOLA 2.
SC_CTOR ( half_adder ) {
12
SC_METHOD ( prc_half_adder ); // registrace metody
13
sensitive << a << b;
14
17
// citlivostní seznam
}
15
16
RTL MODELOVÁNÍ V SYSTEMC
}; # endif
Soubor za£íná a kon£í direktivou pro p°eklada£ b¥ºn¥ pouºívanou v jazyce C. Tato direktiva zajistí ºe pokud je hlavi£kový soubor vkládán ve více souborech, nepovede tato akce k chyb¥, ale pouze k ignorování opakovaného vloºení hlavi£kového souboru. Na °ádku 4 je samoz°ejm¥ vloºen hlavi£kový soubor
systemc.h,
který nám umoºní pouºívat simula£ní
kernel, makra, datové typy a dal²í konstrukty jazyka. Na dal²ích °ádcích poté následuje deklarace modulu a vstupních a výstupních port· polovi£ní s£íta£ky. Deklarace modulu byla zmín¥na jiº v kapitole 2.4.1. Zde je pouºita deklarace pomocí makra SC_MODULE, protoºe je jednodu²²í a není zde pot°eba v konstruktoru modulu nutn¥ pouºít dal²í parametry krom¥ jeho názvu. Pro porty jsou pouºity p°edde nované porty
bool.
p°i°adit datový typ
sc_in<>
Na °ádku 10 následuje deklarace funkce
a
sc_out<>, kterým lze
prc_half_adder,
která re-
alizuje celou funkci polovi£ní s£íta£ky. Následuje de nice konstruktoru ve kterém je funkce
prc_half_adder
zaregistrována jako paralelní proces pomocí makra SC_METHOD a ur£ení
citlivostního seznamu pro tento proces.
1
Listing 2.9: Implementa£ní soubor polovi£ní s£íta£ky
# include " half_adder . h"
2
3
void half_adder :: prc_half_adder () { sum = a ^ b;
4
carry = a & b;
5
6
}
V implementa£ním souboru se nachází pouze deklarace metod de novaných v p°íslu²ném
hlavi£kovém souboru. A protoºe je v hlavi£kovém souboru de nována pouze jedna funkce, je implementa£ní soubor velice stru£ný. Na °ádku 1 je vloºen hlavi£kový soubor, který de n-
2.5.
19
VZOR HIERARCHICKÉHO RTL MODELU
uje pouze hlavi£ky metod, které budeme de novat. V na²em p°ípad¥ se jedná o soubor
half_adder.h jenº je uveden ve výpisu 2.8. Jedinou funkcí, kterou je nutné de novat je funkce prc_half_adder(),
která reprezentuje logická hradla XOR na £tvrtém °ádku a hradlo AND
na °ádku p¥t z obrázku 2.1. Tím je polovi£ní s£íta£ka hotová, testovat jí zatím nebudeme a pokro£íme k dal²ímu kroku implementaci úplné s£íta£ky.
2.5.2 Modul úplné s£íta£ky Úplná s£íta£ka je roz²í°ením s£íta£ky polovi£ní. Roz²i°uje její funk£nost a je moºné °et¥zením úplných s£íta£ek s£ítat vícebitové operandy. Toto je umoºn¥no díky p°idáním jednoho vstupu, který slouºí pro p°ípadný p°enos z niº²ího °ádu v p°ípad¥ °et¥zení s£íta£ek. Po£et výstup· z·stává zachován. V tabulce 2.6 je uvedena pravdivostní tabulka funkce, kterou realizuje úplná s£íta£ka.
a
b
cin
sum
carry
0
0
0
0
0
0
0
1
1
0
0
1
0
1
0
0
1
1
0
1
1
0
0
1
0
1
0
1
0
1
1
1
0
0
1
1
1
1
1
1
Tabulka 2.6: Pravdivostní tabulka úplné s£íta£ky
Pravdivostní tabulka úplné s£íta£ky je velice podobná s£íta£ce polovi£ní. Proto existují dva p°ístupy jak jí realizovat. První moºností by bylo obdobná realizace jako polovi£ní s£íta£ky ze základních logických hradel. V rámci tohoto p°ístupu existuje celá °ada zapojení, které lze pouºít. Tato implementace by se v podstat¥ od polovi£ní s£íta£ky li²ila pouze v po£tu vstupních port· a deklaraci paralelního procesu pouºitého v implementa£ním souboru. Proto je zde uveden druhý p°ístup, ve kterém je pouºita jiº vytvo°ená polovi£ní s£íta£ka ve dvou
20
KAPITOLA 2.
RTL MODELOVÁNÍ V SYSTEMC
instancích a jedno logické hradlo OR. Schéma zapojení této varianty je na obrázku 2.2.
Obrázek 2.2: Schéma zapojení úplné s£íta£ky
Výpis 2.10 je výpisem hlavi£kového souboru úplné s£íta£ky. Na první pohled je z°ejmé, ºe popis je o n¥co komplikovan¥j²í neº v p°ípad¥ polovi£ní s£íta£ky. To je z d·vodu vyuºití instanciace dvou polovi£ních s£íta£ek a tím vytvo°ení hierarchického popisu.
Listing 2.10: Hlavi£kový soubor úplné s£íta£ky
1
2
# ifndef FULL_ADDER_H # define FULL_ADDER_H
3
4
5
# include " systemc . h" # include " half_adder . h"
6
7
8
9
10
11
SC_MODULE ( full_adder ) { public : sc_in < bool > a , b , carry_in ;
// deklarace port·
sc_out < bool > sum , carry_out ; sc_signal < bool > c1 , s1 , c2 ;
12
13
void prc_or ();
// modul má jedinou metodu
14
15
16
half_adder * ha1_ptr , * ha2_ptr ; // vytvo°ení ukazatel·
2.5.
21
VZOR HIERARCHICKÉHO RTL MODELU
SC_CTOR ( full_adder ) {
17
ha1_ptr = new half_adder ( " ha1 " );
18
ha2_ptr = new half_adder ( " ha2 " );
19
20
ha1_ptr ->a (a );
21
// jmennné mapovaní
ha1_ptr ->b (b );
22
ha1_ptr -> sum ( s1 );
23
ha1_ptr -> carry ( c1 );
24
25
(* ha2_ptr ) (s1 , carry_in , sum , c2 ); // pozi£ní mapovaní
26
27
28
29
SC_METHOD ( prc_or );
// registrace metody
sensitive << c1 << c2 ;
// citlivostní seznam
}
30
31
~ full_adder () {
32
delete ha1_ptr ;
33
delete ha2_ptr ;
34
}
35
36
37
// destruktor
}; # endif
Stejn¥ jako hlavi£kový soubor polovi£ní s£íta£ky za£íná direktivou pro p°eklada£ a vloºením pot°ebných hlavi£kových soubor·, tak i zde je situace stejná. Jen s tím rozdílem, ºe nyní je navíc nutné vloºit i hlavi£kový soubor polovi£ní s£íta£ky. Dále následuje jiº tradi£ní deklarace modulu a vstupních a výstupních port·. Zde si ale jiº nevysta£íme pouze s porty modulu, ale je nutné de novat pomocné signály slouºící jako propojovací vodi£e mezi polovi£ními s£íta£kami a dále s hradlem OR. K tomuto ú£elu vyuºijeme p°edde nované kanály
3
sc_signal.
Na °ádku 13 je deklarována metoda p°edstavující logické hradlo OR, její de nice bude uve3
V terminologii SystemuC se pojem komunika£ní kanál pouºívá jako ekvivalent signálu ve VHDL.
22
KAPITOLA 2.
RTL MODELOVÁNÍ V SYSTEMC
dena v implementa£ním souboru. Dále jsou de novány dva ukazatele na instance polovi£ní s£íta£ky
ha1_ptr
a
ha2_ptr.
s£íta£ek pojmenované
ha1
a
V konstruktoru jsou následn¥ vytvo°eny instance polovi£ních
ha2. Dále je nutné správn¥ propojit porty polovi£ních s£íta£ek.
To je moºné realizovat dv¥ma zp·soby: jmenným £i pozi£ním mapováním. Na °ádcích 21 aº 24 výpisu 2.10 je uvedeno jmenné mapování pro instanci polovi£ní s£íta£ky i£ní mapováním je následn¥ propojena druhá instance
prc_or
ha2
ha1_ptr.
Poz-
na °ádku 26. Registrací metody
jako paralelního procesu a de nice jeho citlivostního seznamu kon£í t¥lo konstruk-
toru. Poslední metodou je destruktor modulu, který na konci uvolní alokovanou pam¥´.
1
Listing 2.11: Implementa£ní soubor úplné s£íta£ky
# include " full_adder . h"
2
3
void full_adder :: prc_or () { carry_out = c1 | c2 ;
4
5
}
Implementa£ní soubor úplné s£íta£ky je je²t¥ krat²í neº s£íta£ky polovi£ní. Zde je pouze
nutné ur£it direktivou
#include v jakém souboru jsou de nice soubor·, které budeme deklarovat.
Následn¥ je pak na²e jediná funkce z hlavi£kového souboru implementována. V tomto p°ípad¥ se jedná o logický sou£et dvou vnit°ních signál·. Tím je s£íta£ka hotova, dále je vhodné veri kovat návrh zda spl¬uje speci kaci úplné s£íta£ky.
2.5.3 Veri kace návrhu Veri kace je provedena tzv. testbench modulem. V tomto modulu ur£íme stimuli, tedy vstupní signály, kterými budeme budit vstupy testovaného obvodu. Na výstupu pak bude moºné pozorovat odezvy, které m·ºeme pouze vypisovat nebo je zapisovat do souboru a dále je podrobn¥ji analyzovat. Na obrázku 2.3 je schématicky znázorn¥no zapojení testované úplné s£íta£ky v£etn¥ procesu generujícího stimuli. Hlavi£kový soubor testbenche je uveden v následujícím výpisu 2.12:
2.5.
23
VZOR HIERARCHICKÉHO RTL MODELU
Obrázek 2.3: Schéma zapojení testbenche úplné s£íta£ky
1
2
Listing 2.12: Hlavi£kový soubor testbenche
# ifndef TESTBENCH_H # define TESTBENCH_H
3
4
5
# include " systemc . h" # include " full_adder . h"
6
7
8
9
10
SC_MODULE ( testbench ) { public : sc_signal < bool > a_sig , b_sig , cin_sig ; sc_signal < bool > sum_sig , carry_out_sig ;
11
12
full_adder * uut_ptr ;
// vytvo°ení ukazatele
void stimuli ();
//metoda modulu
SC_CTOR ( testbench )
{
13
14
15
16
17
uut_ptr = new full_adder ( " uut " );
18
19
uut_ptr ->a( a_sig );
// jmenné mapovaní
24
KAPITOLA 2.
RTL MODELOVÁNÍ V SYSTEMC
uut_ptr ->b( b_sig );
20
uut_ptr -> carry_in ( cin_sig );
21
uut_ptr -> sum ( sum_sig );
22
uut_ptr -> carry_out ( carry_out_sig );
23
24
SC_THREAD ( stimuli );
25
}
26
27
~ testbench () {
28
delete uut_ptr ;
29
}
30
31
32
// destruktor
}; # endif
Struktura souboru je uº z p°edchozích p°íklad· z°ejmá. Direktivu pro p°eklada£ následuje vloºení souboru, který testujeme tedy hlavi£kový soubor úplné s£íta£ky. Dále de nice vstup· a výstup· podle schématu 2.3 vytvo°ení ukazatele na entitu úplné s£íta£ky a de nice metody pro vytvá°ení stimul·. V konstrukturu je pak následn¥ vytvo°ena instance úplné s£íta£ky, namapována na p°íslu²né signály a metoda zaregistrována jako proces. V destruktoru je pak jako vºdy uvoln¥ní d°íve alokované pam¥ti.
Listing 2.13: Implementa£ní soubor testbenche
1
# include " testbench .h "
2
3
4
void testbench :: stimuli () { sc_uint <3 > pattern ;
5
6
pattern = 0;
7
8
9
while (1) { a_sig = pattern [0];
2.5.
25
VZOR HIERARCHICKÉHO RTL MODELU
b_sig = pattern [1];
10
cin_sig = pattern [2];
11
12
wait (5 , SC_NS );
13
pattern ++;
14
}
15
16
}
V implementa£ním souboru je pouze de nice metody
Metoda de nuje t°íbitový signál
a_sig, b_sig
a
cin_sig
stimuli() zaregistrované jako proces.
pattern, který následn¥ vytvá°í stimuli na jednobitové signály
a tím vytvo°í kompletní mnoºinu vstupních vzor· p°ivedených na
vstup úplné s£íta£ky. Tímto je kompletn¥ hotov model úplné s£íta£ky v£etn¥ testování. Stejn¥ ale jako ve standardním jazyce C, kde je první spou²t¥nou metodou metoda
main,
je i zde nutné jasn¥
de novala vstupní bod programu. To provedeme obdobn¥, de nicí funkce
sc_main()
pop-
sanou dále.
2.5.4 Vstupní bod programu Vstupním bodem kaºdého programu v SystemC je funkce pojmenovaná
sc_main(). Obsahuje
elabora£ní £ást vykonávání programu a dal²í de nice a nastavení týkající se sestavení a provád¥ní simulace. Funkce
sc_main()
pro otestování funkce úplné s£íta£ky je uvedena ve
výpisu 2.14. Funkce je realizována tak, aby zaznamenávala vstupy a výstupy do souboru ve formátu VCD, kde je moºné následn¥ pomocí externích program· prohlíºet pr·b¥h v²ech signál·.
1
Listing 2.14: Vstupní funkce
sc_main()
modelu úplné s£íta£ky
# include " testbench .h "
2
3
int sc_main ( int argc , char * argv []) {
4
5
sc_set_time_resolution (1 , SC_NS );
26
KAPITOLA 2.
RTL MODELOVÁNÍ V SYSTEMC
6
testbench verif_env (" verif_env " );
7
8
sc_trace_file * tf ;
9
tf = sc_create_vcd_trace_file (" trace " );
10
11
sc_trace ( tf , verif_env . a_sig , " a_sig " );
12
sc_trace ( tf , verif_env . b_sig , " b_sig " );
13
sc_trace ( tf , verif_env . cin_sig , " cin_sig " );
14
sc_trace ( tf , verif_env . sum_sig , " sum_sig " );
15
sc_trace ( tf , verif_env . carry_out_sig , " carry_out_sig " );
16
17
sc_start (1000 , SC_NS );
18
sc_close_vcd_trace_file ( tf );
19
20
return (0);
21
22
}
Struktura souboru je následující: po zahrnutí hlavi£kového souboru testbenche od kterého
budeme ve vstupní funkci
sc_main() vytvá°et instanci jiº následuje samotná vstupní funkce.
Zde po vzoru klasické funkce
main()
obsahuje dva vstupní parametry p°íkazové °ádky, které
zde v²ak nejsou pouºity. Na °ádku 5 je nastaveno rozli²ení pro jednotlivé kroky simulace na jednu nanosekundu. Na °ádku 7 je poté vytvo°ena instance testbenche nazvaná
verif_env.
Dále je nutné vytvo°it ukazatel na soubor, do kterého budeme pr·b¥hy zaznamenávat a následn¥ samotný soubor na °ádce 10 vytvo°it. ádek 12 aº 16 p°edstavuje registraci signál·, které se mají do souboru zaznamenávat. Metoda
sc_trace
obsahuje t°i parametry s následu-
jícím významem:
1. Název ukzatele na soubor do kterého chceme hodnotu zaznamenat. Ve v¥t²in¥ p°ípad· se vytvá°í pouze jeden soubor jako v na²em p°ípad¥, ale i tak je nutné název uvést.
2. Druhým parametrem je co chceme zaznamenat. To znamená z kterého modulu a jak
2.5.
27
VZOR HIERARCHICKÉHO RTL MODELU
se zaznamenávaný signál v modulu jmenuje.
3. Posledním je pak název, který bude signálu p°id¥len ve vytvo°eném souboru.
Po registraci signál· je moºné p°ejít z elabora£ní fáze do fáze simula£ní p°íkazem
sc_start(),
který simulaci odstartuje a maximální dobu provád¥ní stanoví na 1000 nanosekund. Pokud do této doby není sama simulace ukon£ena simula£ní jádro jí samo ukon£í a provede dal²í instrukce. V tomto p°ípad¥ je to uzav°ení souboru a vrácení navratové hodnoty.
2.5.5 P°eklad programu a zobrazení pr·b¥h· K p°ekladu programu je samoz°ejm¥ nutné mít správn¥ nainstalovaný SystemC, který lze po zaregistrování stáhnout z domovských stránek projektu . Pr·vodce instalací je sou£ástí instala£ního archivu. Po instalaci je jiº moºné zdrojové soubory p°eloºit. Na obrázku 2.4 je znázorn¥n postup kompilace z jednotlivých zdrojových soubor·. Nejprve jsou v²echny soubory pomocí p°eklada£e g++ (lze pouºít i jíný, viz. pr·vodce instalací) zkompilovány do objektových soubor· a následn¥ je pomocí linkeru spolu s pot°ebnými knihovnami sestaven spustitelný binární soubor. S výhodou lze zde pouºít Make l·, kde v²e pot°ebné deklarujeme v souboru Make le a následn¥ pouze p°íkazem make zkompilujeme v²e pot°ebné. Make le tohoto projektu je p°iloºen v adresá°i / les/FullAdder spolu se zdrojovými soubory. Po spu²t¥ní spustitelného souboru se do konzole vypí²e základní informace o aktuální instalaci SystemuC a provede samotná simulace. V tomto p°ípad¥ je vytvo°en soubor
trace.vcd,
který obsahuje zaznamenané pr·b¥hy vstup· a výstup·. Na obrázku 2.5 je zobrazen vý°ez ve kterém je zobrazen pr·b¥h pomocí programu GTKwave.
28
KAPITOLA 2.
RTL MODELOVÁNÍ V SYSTEMC
Obrázek 2.4: Pr·b¥h kompilace SystemC programu [2]
Obrázek 2.5: Pr·b¥hu signálu ze souboru (k zobrazení pouºit program GTKwave)
Kapitola 3 Modelování na úrovni transakcí
Modelování na úrovni transakcí neboli Transaction-level modeling (TLM) je p°ístup k £íslicovému návrhu, který se snaºí odd¥lit detaily komunikace mezi výpo£etními bloky od detail· funk£ní implementace jednotlivých blok·. Komunikace probíhá p°es rozhraní socket·, které jasn¥ de nují mnoºinu komunika£ních funkcí a p°es které jednotlivé bloky návrhu komunikují. Tyto funkce nespeci kují p°esnou implementaci nízkoúrov¬ové komunikace na úrovni jednotlivých pin·, ale slouºí pouze pro samotný p°enos dat ze zdroje k cíli. Vhodným p°íkladem, kde lze návrh na transak£ní úrovni s výhodou pouºít jsou tzv. systémy na £ipu (SoC) obsahující jednu nebo více sb¥rnic na kterou jsou p°ipojeny výpo£etní bloky jako procesory, pam¥ti a dal²í funk£ní bloky. Popis t¥chto blok· m·ºe být v po£áte£ní fázi návrhu proveden algoritmicky bez nutnosti detailn¥ de novat fyzické uspo°ádání uvnit° jednotlivých modul·. P°i modelování na úrovni transakcí se tedy primárn¥ zajímáme o tok dat, tzn. odkud a kam se data posílají. Zajímají nás tedy hlavn¥ transakce, coº v tomto slova smyslu znamená komunikaci mezi £ástmi systému. Tento p°ístup dovoluje m¥nit p°ipojené bloky a testovat jejich funk£nost spolu s °ádov¥ vy²²í rychlostí simulace neº která je dosahována p°i simulaci na RTL úrovni.
K vytvo°ení model· bude vyuºita poslední verze knihovny TLM a to konkrétn¥ TLM-
1
2.0.1 voln¥ dostupná na stránkách OSCI . A£ je moºné, stejn¥ jako v p°ípad¥ SystemuC, se v mnoha publikacích do£íst o této knihovn¥ jako o jazyku, jedná se skute£n¥ o knihovnu, 1
Open SystemC Initiative (www.accellera.org)
29
30
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
která p°ímo navazuje na samotný SystemC a roz²i°uje jeho moºnosti. Nutnou podmínkou pro pouºití TLM je tedy správn¥ nainstalovaný SystemC v jeho základní verzi.
3.1 len¥ní kapitoly V úvodu této kapitoly bude zmín¥n p°edch·dce sou£asného standardu TLM-2.0, dále bude £tená° nejprve seznámen s principy modelování na úrovni transakcí. Následn¥ budou hloub¥ji zmín¥ny hlavní dva p°ístupy vytvá°ení model·, jejich vzájemné rozdíly a programové konstrukty v nich pouºívané. Poté bude vysv¥tlena problematika komunikace mezi funk£ními bloky a dal²í prvky knihovny TLM, které slouºí jako stavební prvky transakcí a zaji²´ují vzájemnou kompatibilitu model·.
3.2 Od TLM-1 k TLM-2.0.1 Sou£asná verze standardu nese ozna£ení TLM-2.0.1. Jedná se o verzi TLM-1 vylep²enou v mnoha ohledech. Odstra¬uje chyby p·vodní verze, usnad¬uje práci s modely a hlavn¥ zlep²uje moºnosti v oblasti integrace model· z r·zných zdroj· a jejich skládání ve v¥t²í celky tzv. interoperabilitu. Nový standard nap°íklad zavádí standardizaci transakcí pomocí standardního protokolu. Dodrºení tohoto standardního protokolu zaru£uje kompatibilitu model· nap°í£ r·znými návrhy. D°íve byla implementace transakcí ponechána na návrhá°i, takºe vyuºití model· z r·zných zdroj· bylo dosti komplikované a ve v¥t²in¥ p°ípad· vyºadovalo úpravu modelu. A to tak aby jak modul, který komunikaci iniciuje, tak cílový modul, komunikovaly p°es stejné rozhraní a data si posílaly pomocí shodných objekt·. V tento okamºik je ale jiº nutné zasahovat do cizích modul·, které chceme v návrhu pouºít. Kv·li tomuto je v nové verzi vyuºívána t°ída transak£ního objektu
tlm_generic_payload,
která se stará jak
o samotná data p°ená²ená v rámci transakce, tak o dal²í parametry. Dal²ím vylep²ením v rámci TLM-2.0 je p°idání £asových anotací p°ímo do volání metod transakcí, coº zlep²uje rychlost simulace a p°ehlednost.
3.3.
31
TYPY BLOK
3.3 Typy blok· Jako bloky (moduly) jsou ozna£ovány jednotlivé £ásti systému, které mezi sebou mohou komunikovat. Transakce v TLM-2.0.1 je vºdy provád¥na mezi tzv. zdrojem a cílem. Zdrojem je modul, který zahajuje komunikaci, tzn. nastavuje komunika£ní parametry p°es transak£ní objekt a následn¥ vyvolá transakci. Cílem je analogicky ozna£en modul £ekající na p°ichozí transakci a podle obsahu transak£ního objektu na ní reaguje. V praxi to znamená, ºe v závislosti na p°íkazu bu¤ uloºí posílaná data do obsahu své pam¥ti nebo p°epo²le obsah své pam¥ti zp¥t do zdrojového modulu. Komunikace mezi zdrojem a cílem nemusí probíhat p°ímo, ale je moºné mezi tyto bloky vloºit propojovací bloky, které se vyzna£ují tím, ºe mohou transakce sm¥rovat a tím fungovat jako routery usm¥r¬ující komunikaci. V²echny tyto názvy pro bloky, tedy zdroje, cíle a propojovací bloky jsou relevantní práv¥ pro konkrétní transakci. V rámci celého modelu je samoz°ejm¥ b¥ºné, ºe v pr·b¥hu simulace nap°íklad komunikaci iniciuje nejprve jeden blok a získá data ze zdroje. Následn¥ se situace obrátí a zdroj se stává cílem a naopak. Tyto pojmy je tedy nutné vztahovat vºdy ke konkrétní transakci.
3.4 Abstraktní modely Pod pojemem abstraktní modely (v originále také jako
coding styles )
v TLM jsou chá-
pany p°ístupy a prost°edky, které jsou z celého standardu pouºity. Jedná se v podstat¥ o de nici protokolu na obecné úrovni, tzn. nejsou zde explicitn¥ de novány detaily komunikace v podob¥ nap°íklad formátu p°edávaných dat, ale pouze uvedeno jak bude komunikace probíhat. Modely lze rozd¥lit dle úrovn¥ abstrakce do t¥chto t°í kategorií:
1. Untimed functional models (UT)
2. Loosely-timed models (LT)
3. Approximately-timed models (AT)
Jak je z anglických názv· patrné, rozdíly mezi modely jsou práv¥ v implementaci transakcí jednotlivých model·. Ze kterých následn¥ vyplývají tzv. styly kódování. Tyto styly kódování de nují mnoºinu funkcí, které je vhodné pouºít pro komunikaci pro daný model. Na obrázku
32
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
3.1 jsou znázorn¥ny r·zné varianty pouºití model·. Z tohoto obrázku lze vy£íst, ºe modely lze rozli²ovat jak podle úrovn¥ abstrakce z hlediska implementace funkcionality, tak i na úrovni abstrakce mezimodulové resp. meziprocesové komunikace [2]. Funk£ní implementace m·ºe být realizována od nejobecn¥j²ího algoritmického popisu aº po RTL popis popsaný v kapitole 2. Mezimodulová komunikace zahrnuje práv¥ transakce TLM popisované v aktuální kapitole. Detailn¥j²í popis pouºívaných metod bude proveden v následujících podkapitolách.
Obrázek 3.1: Terminologie abstraktních model· [2]
3.4.1 Untimed functional modely Untimed functional model neboli model bez £asování (n¥kdy taky ozna£ován jako algoritmický model) je realizován pomocí procesu bez £asových anotací, který provádí celou funk£nost modelu. Z tohoto d·vodu je v literatu°e uvád¥n jako základní model, který ov²em stojí na pomezí TLM model· a oby£ejných algoritmických program·. V referen£ním manuálu knihovny TLM [10] je tento model uveden jako nepodporovaný v sou£asné verzi TLM-2.0.1 a proto nebude dále uvaºován.
3.4.
33
ABSTRAKTNÍ MODELY
3.4.2 Loosely-timed modely (LT modely) blocking transport).
Loosely-timed modely pouºívají ke komunikaci blokovací p°enosy (
Tyto p°enosy se vyzna£ují dvoufázovými transakcemi. Kaºdá transakce je rozd¥lena na dop°ednou £ast, kterou je zahájována komunikace - ºádost(request) a zp¥tnou odezvu, kterou je transakce ukon£ena - odpov¥¤(response). P°i ºádosti jsou cílovému modulu poslána p°ená²ená data, adresa a dal²í informace o vlastnostech zdrojového modulu. Tato operace je realizována voláním funkce
b_transport(tlm_generic_payload*, sc_time),
která zp·sobí zahá-
jení samotné transakce. Detailn¥ji je funkce popsána v 3.5.1.1. K samotnému p°enosu slouºí transak£ní objekt t°ídy
tlm_generic_payload,
který slouºí jako nosi£ informace transakce a
zaji²tuje univerzálnost (interopereabilitu) r·zných model·.
3.4.3 Approximately-timed modely (AT modely) Detailn¥j²í popis transakcí, který se více blíºí skute£nému protokolu pouºívaného ke komunikaci, lze modelovat pomocí model· ozna£ovaných jako approximately-timed. Transakce je zde rozd¥lena, stejn¥ jako v p°ípad¥ LT model·, na n¥kolik fází. Po£et fází jiº není pevn¥ ur£en, ale je moºné podle zvoleného protokolu m¥nit po£et a význam jednotlivých fází. Tímto zp·sobem je moºné modelovat komunikaci na detailn¥j²í úrovni neº v p°ípad¥ loosely-timed model·, ale zárove¬ nezacházet do úplných detail· protokolu na úrovni signál·, které by bylo nutné °e²it na úrovni RTL. Ke komunikaci se zde na rozdíl od loosely-timed model· pouºívají neblokovací p°enosy (
non-blocking transport), kde není volající modul pozastaven aº do
okamºiku p°ijetí odpov¥di, ale vykonává sv·j kód dál a ne£eká na úplné dokon£ení transakce.
3.4.4 Shrnutí Jak jiº bylo d°íve zmín¥no, pouºité modely se v zásad¥ li²í pouze v pouºitých metodách a z nich následn¥ vycházejících postup· tvorby modelu. Proto jsou tyto modely £asto ozna£ovány také jako styly kódování (
coding styles ). Na obrázku 3.2 jsou znázorn¥ny mechanismy, které
se typicky pouºívají v modelech loosely-timed a approximately-timed. Na obrázku 3.3 je zobrazen zákládní pr·b¥h transakce. U obou model· za£íná ºádostí (voláním funkce
b_transport()
resp.
nb_transport() ),
která je vysláná bu¤ p°ímo cílovému
34
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
Obrázek 3.2: Znázorn¥ní mechanism· pouºívaných v LT a AT modelech [10]
modulu nebo p°es propojovací komponenty, které ºádost doru£í. Cílový modul reaguje na ºádost od zdroje a odpoví stejnou formou zdrojovému modulu. V LT modelech je touto odpov¥dí transakce ukon£ena, zatímco v AT modelech je tento krok podle standardního protokolu pouze ukon£ení fáze ºádosti (jako v p°íklad¥ na obrázku 3.6) nebo p°ípadn¥ pouze ukon£ení za£átku ºádosti (p°íklad na obrázku 3.5) v závislosti na zvolené strategii.
Obrázek 3.3: Schéma komunikace pro LT modely
3.5.
35
KOMUNIKACE MEZI MODULY
3.5 Komunikace mezi moduly Samotná komunikace probíhá pomocí rozhraní (interface). Tato rozhraní standardizují pouºití komunika£ních kanál· v modelech a zvy²ují tím znovupouºitelnost modul· a testovacích program·. Pouºitelnými rozhraními jsou jednak d°íve zmín¥ná rozhraní komunika£ní blokující a neblokující. Dal²ími dopl¬kovými rozhraními usnad¬ujícími návrh a zrychlujícími simulaci jsou rozhraní pro p°ímý p°ístup do pam¥ti (DMI) a ladící rozhraní (debug interface).
3.5.1 Transportní rozhraní Transportní rozhraní jsou základním typem rozhraní p°es které bloky komunikují. Jsou dvou typ· blokující a neblokující.
3.5.1.1 Blokující rozhraní Blokující rozhraní je ur£eno pro Loosely-timed modely. Jedinými synchroniza£ními body v p°ípad¥ pouºití tohoto rozhraní jsou za£átek a konec transakce. Jedná se tedy v podstat¥ o variantu, kdy iniciátor zahájí transakci pomocí volání funkce
b_transport()
(za£átek
transakce). Poté £eká na odpov¥¤ a neprovádí nic jiného je blokován. K jeho odblokování dojde aº po p°ijetí odpov¥di od cílového bloku (konec transakce). Transakce je provedena v rámci jediného volání funkce
b_transport().
Blokující rozhraní je reprezentováno t°ídou
tlm_blocking_transport_if. Protoºe se jedná o
virtuální t°ídu není moºné ji p°ímo pouºít, ale je moºné její metody pomocí d¥di£nosti zd¥dit. Takto jsou nap°íklad implementovány t°ídy
simple_target_socket a simple_initiator_socket,
které také budou dále v textu pouºity v p°íkladech. Blokující rozhraní je vhodné pouºít v p°ípad¥, ºe chceme provést celou transakci v rámci jediného volání metody
b_transport().
Vyuºívá totiº pouze takzvan¥ dop°ednou cestu, p°i které je transakce vyvolána modulem za£ínající komunikaci a zp¥tný p°enos dat (v p°ípad¥ £tecí transakce) je realizován pomocí transak£ního objektu t°ídy
generic payload.
Výhodou tohoto p°ístupu je relativní jednodu-
chost celého pr·b¥hu transakce. Samotné volání blokující transakce je realizováno pomocí metody
delay),
kde parametr
*trans
b_transport(*trans,
reprezentuje ukazatel na transak£ní objekt (viz. sekce 3.6) a
36
KAPITOLA 3.
parametr
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
delay ur£uje trvání transakce. Transak£ní objektem je zpravidla t°ída tlm_generic_payload,
obsahující informace o transakci a ukazatel na p°ená²ená data. Ve výpisu 3.1 je ukázka deklarace socketu, p°es který je následn¥ vyvolána blokující transakce.
Listing 3.1: Volání blokující transportní metody ve zdrojovém bloku
1
2
tlm_utils :: simple_initiator_socket < Initiator > socket ; socket -> b_transport (* trans , delay ); // blokující transportní metoda
Na obrázku 3.4 je ukázán p°íklad ve kterém jsou znázorn¥ny £asové pr·b¥hy dvou transakcí. Ob¥ transakce iniciuje první modul ozna£ený jako Initiator. První transakce obsahuje ukazatel
GP
na objekt t°ídy
Generic payload
nesoucí datové poloºky a vlast-
nosti transakce. Druhým parametrem je deklarované zpoºd¥ní transakce. V tomto p°ípad¥ je zpoºd¥ní nastavano na nulovou hodnotu. Druhá transakce je analogií první pouze s rozdílným £asovým parametrem. P°i volání druhé transakce je moºné vid¥t reáln¥j²í chování transakce, kde £asový okamºik volání a zp¥tného doru£ení odpov¥di má nenulové zpoºd¥ní. Druhá £ast transakce tzv. odpov¥¤ je realizována p°es zm¥nu hodnoty jednoho z parametr· transportního objektu
generic payload,
kde p·vodn¥ nastavená hodnota (zpravidla nastaven status
TLM_INCOMPLETE_RESPONSE )
je p°enastavena podle odpov¥di cílového modulu na
jednu z de novaných hodnot podle tabulky 3.3. Spolu s touto hodnotou je moºné p°ená²et data pomocí ukazatele na data, který je sou£ástí transportní t°ídy
generic payload
viz. kapi-
tola 3.6.
3.5.1.2 Neblokující rozhraní Neblokující rozhraní je ur£eno pro Approximately-timed modely. Jeho pouºití je vhodné zejména v p°ípadech, kde je poºadován detailn¥j²í popis komunikace v rámci jedné transakce. Tento popis je rozd¥len do n¥kolika díl£ích fází, kde je kaºdá fáze synchronizována v ur£ený £asový okamºik. To tedy znamená, ºe jiº není celá transakce provedena v rámci jediného volání jako v p°ípad¥ blokujícího rozhraní, ale jsou zde v podstat¥ simulovány p°echody mezi jejími fázemi od pokusu o navázání spojení aº po ukon£ení komunikace. V pr·b¥hu kaºdé fáze lze provád¥t libovolné operace, synchronizace je provád¥na jen p°i p°echodech mezi fázemi. Mezi t¥mito fázemi lze p°echázet v zásad¥ podle t°í strategií, které zde budou popsány.
3.5.
37
KOMUNIKACE MEZI MODULY
Obrázek 3.4: asový pr·b¥h dvou transakcí realizovaných p°es blokující rozhraní
Rozd¥lení na fáze je libovolné, ale v zájmu zachování znovupouºitelnosti (interoperability)
base protocol )
model· je vhodné se drºet standardního protokolu (
obsahujícího £ty°i fáze
(viz. tabulka 3.1). K vyjád°ení v jaké fázi se transakce nachází slouºí t°ída
tlm_phase, která
de nuje práv¥ tyto fáze standardního protokolu. V p°ípad¥ nutnosti není problém po£et t¥chto fází roz²í°it, jak bude dále ukázáno v kapitole 4.4, ale je nutné po£ítat se ztrátou interoperability s ostatními moduly vytvo°enými na základ¥ tohoto standardního protokolu. Strategii p°echodu mezi fázemi lze rozd¥lit na tyto t°i varianty:
1. P°echod mezi fázemi je vºdy realizován voláním metody
nb_transport() v obou sm¥rech
komunikace strategie zp¥tného volání.
Strategie zp¥tného volání
spo£ívá v tom, ºe zm¥na fáze ve které se transakce
nachází je provedena voláním neblokující metody (a´ uº dop°edné nebo zp¥tné
nb_transport_bw() ).
nb_transport_fw()
To znamená, ºe po£et fází na které je transakce
rozd¥lena odpovídá po£tu volání neblokující metody v rámci jedné transakce. Na obrázku 3.5 je uveden p°íklad transakce rozd¥lené na £ty°í základní fáze (podle t°ídy
tlm_phase ). Za pov²imnutí zde stojí, ºe transakci zahajuje modul ozna£ený jako Initia-
38
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
Obrázek 3.5: asový diagram transakce zp¥tného volání
tor pomocí dop°edného volání neblokující metody. Následují dv¥ zp¥tná volání od modulu Target a transakce je zakon£ena op¥t odpov¥dí modulu Initiator. Jako návratová hodnota je ve v²ech £ty°ech p°íkladech vrácen status
TLM_ACCEPTED
ozna£ující
nezm¥n¥ný transak£ní objekt. Dal²í platné návratové statusy jsou uvedeny v tabulce 3.2 a budou vyuºity v dal²ích metodách.
2. P°echod mezi fázemi je realizován voláním metody
nb_transport() v dop°edném sm¥ru
(ze zdroje do cíle) i návratovou hodnotou vrácenou z této funkce strategie návratové hodnoty.
Strategie návratové hodnoty
se jiº p°i prvním pohledu na £asový diagram na
obrázku 3.6 li²í od p°edchozí sekvence volání. Hlavním rozdílem je sníºení po£tu volání neblokujících metod na polovinu. Toto sníºení je umoºn¥no díky návratové hodnot¥
TLM_UPDATED
(viz. tabulka 3.2), která ozna£uje pozm¥n¥ní transak£ního objektu
p°ípadn¥ fáze transak£ního objektu p°i návratu. Pomocí této návratové hodnoty je vola-
3.5.
39
KOMUNIKACE MEZI MODULY
Obrázek 3.6: asový diagram transakce s vyuºitím návratové hodnoty
jící modul schopen identi kovat zm¥nu v obsahu transak£ního objektu a aktualizovat si aktuální fázi. Sníºení po£tu volání neblokujících metod v obecné rovin¥ simulaci zrychlí, na druhou stranu zde jiº není p°echod mezi fázemi realizován pouhým voláním, ale je navíc provád¥n návratovou hodnotou na takzvané zp¥tné cest¥. Dale je vhodné zmínit, ºe p°i této strategii se vytvo°í mezi n¥kterými fázemi náznak blokujícího charakteru. Jedná se vºdy o ty fáze, které kon£í p°ijetím návratové hodnoty.
3. P°echod mezi fázemi není nutné uvaºovat. Transakce je dokon£ena v rámci jediného volání funkce
nb_transport
strategie rychlého dokon£ení.
Strategie rychlého dokon£ení
vyuºívá toho, ºe cílový modul jako návratovou hod-
notu neblokující metody vrací status
TLM_COMPLETED (viz. tabulka 3.2). Tato hod-
nota ozna£uje ukon£ení celé transakce. V p°ípad¥ pouºití této nejtriviáln¥j²í strategie jako na obrázku 3.7 je metoda ekvivalentní s voláním blokující metody.
40
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
Obrázek 3.7: asový diagram transakce s vyuºitím rychlého dokon£ení
V²echny t°i tyto strategie je moºné pouºít ve spojitosti s Approximately-timed modely. Jedná se pouze o p°ípustné varianty standardního protokolu [10]. P°ípadné pouºití kombinovaných variant, ale není doporu£eno a to zejména z hlediska znovupouºitelnosti v jiných návrzích. Nejb¥ºn¥ji pouºívanou strategií je zde první uvedená zp¥tné volání. Proto bude dále v textu v kontextu Approximately model· brána v úvahu práv¥ strategie zp¥tného volání. Neblokující rozhraní je, obdobn¥ jako blokující, reprezentováno virtuální t°ídou. v tomto p°ípad¥ jiº v²ak nejde pouze o jedinou t°ídu, ale konkrétn¥ se jedná o t°ídu
_transport_if
a t°ídu
tlm_fw_nonblocking-
tlm_bw_nonblocking_transport_if. Pouºití dvou typ· rozhraní je zde
z d·vodu, ºe neblokující metoda je volána jak na stran¥ modulu za£ínajícího komunikaci (iniciátor), tak v cílovém modulu. Konkrétní identi kace v jaké fázi se transakce nachází je sou£ástí parametr· volané metody. Volání blokující metody je realizováno metodou
nb_transport_fw(*trans, phase, delay),
odpov¥¤ s pozm¥n¥nou fází je poté volána metodou
nb_transport_bw(*trans, phase, delay).
Parametry obou metod
*trans
a
delay
p°esn¥ odpovídají parametr·m pouºitých p°i volání
3.5.
41
KOMUNIKACE MEZI MODULY
neblokující metody popsané v 3.5.1.1. Navíc je p°idán parametr
phase, ozna£ující fázi, která
práv¥ za£íná voláním neblokující metody. Ve výpisu 3.2 je ukázka vytvo°ení socketu a na dal²ím °ádku je socket pouºit pro volání neblokující metody.
Listing 3.2: Volání neblokující transportní metody ve zdrojovém bloku
1
2
tlm_utils :: simple_initiator_socket < Initiator > socket ; socket -> nb_transport_fw (* trans , phase , delay );
Fáze
Volající blok
UNINITIALIZED_PHASE BEGIN_REQ
iniciátor
Význam Neinicializováno (standardn¥ nepouºito) Za£átek poºadavku
END_REQ
cíl
Konec poºadavku
BEGIN_RESP
cíl
Za£átek odpov¥di
END_RESP
iniciátor
Konec odpov¥di
Tabulka 3.1: Základní fáze transakce de nované t°ídou
tlm_phase
Návratová hodnota
Význam
TLM_ACCEPTED
Volaný nepozm¥nil transak£ní objekt
TLM_UPDATED
Transak£ní objekt pozm¥n¥n
TLM_COMPLETED
Transak£ní objekt pozm¥n¥n, transakce dokon£ena
Tabulka 3.2: Návratové hodnoty neblokujícího rozhraní
3.5.1.3 Shrnutí Blokující a neblokující transportní rozhraní jsou jen prost°edkem, jak realizovat transakci. V p°ípad¥ blokujícího rozhraní mluvíme pouze o dvou synchroniza£ních bodech transakce za£átek a konec. To je realizováno v rámci jediného volání blokující metody. Neblokující rozhraní p°iná²í moºnost jak celý proces zjemnit a rozd¥lit transakci na men²í £ásti. To samoz°ejm¥ klade vy²²í nároky jak na £as simulace, tak i na pracnost vytvo°ení celého modelu. Principiáln¥ je moºné v jednom modulu pouºít oba typy transportních rozhraní p°es
42
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
jeden komunika£ní socket. Motivace k tomuto bývá zachování maximální univerzálnosti a znovupouºitelnosti návrhu v r·zným systémech [10, str. 10].
3.5.2 Rozhraní pro p°ímý p°ístup do pam¥ti Rozhraní pro p°ímý p°ístup do pam¥ti neboli DMI
2 je typ rozhraní, umo¬ující zdrojovému
modulu získat p°ístup do pam¥ti cílového modulu bez nutnosti pouºít komunika£ní rozhraní a obejít tedy transportní rozhraní zmín¥ná d°íve. Celý proces komunikace p°es transportní rozhraní je pom¥rn¥ £asov¥ náro£ný. Motivace tohoto p°ístupu tedy spo£ívá v urychlení £tení £i zápisu a tudíº celé simulace. Hlavní vyuºití najde toto rozhraní v pam¥´ov¥ orientovaných návrzích jako jednoduchý zp·sob pro kontrolní výpisy obsahu pam¥ti. K získání ukazatele je pouºita op¥t transportní t°ída generic payload, samotný ukazatel je pak sou£ástí t°ídy
tlm_dmi.
Objekt t°ídy
tlm_dmi
navrací ukazatel pro p°ímý p°ístup,
rozsah pam¥ti do které lze takto p°istupovat a £asové zpoºd¥ní £tecích a zápisových operací. Postup získání p°ímého ukazatele a jeho pouºití se snaºí ilustrovat diagram na obrázku 3.8. V diagramu je zmín¥na funkce
get_direct_mem_ptr(), která je volána zdrojovým mod-
ulem v p°ípad¥, ºe cílový modul tento p°ístup podporuje. Naopak zneplat¬ující funkce
validate_direct_mem_ptr()
in-
je volána cílovým modulem a jak jiº bylo zmín¥no, slouºí jako
prost°edek pro ukon£ení platnosti d°íve p°id¥leného ukazatele.
3.5.3 Ladící rozhraní Ladící rozhraní (debug interface) je dopl¬kové rozhraní velice podobné transportním rozhraním. Dokonce vyuºívá i stejnou cestu pouºitou v n¥kterém z transportních rozhraní p°es kterou komunikuje s cílovým modulem. Jediný rozdíle spo£ívá v tom, ºe komunikace nezp·sobuje ºádné zpoºd¥ní £i £ekání spojená s komunikací p°es transportní rozhraní. Lze ho tedy s výhodou pouºít pro otestování správného propojení modul· (zejména pro sloºit¥j²í propojení nebo p°i p°ekladu adres) nebo pro rychlé vypsání prom¥nné bloku tam kde není podporován p°ímý p°ístup. Pro p°enos se jiº tradi£n¥ pouºívá transportní objekt t°ídy op¥t ukázano na p°íkladu v sekci 4.3. 2
Direct Memory Interface
generic payload,
pouºití je
3.6.
43
GENERIC PAYLOAD
Obrázek 3.8: Diagram ilustrující získání a pouºití DMI ukazatele
3.6 Generic Payload T°ída
tlm_generic_payload
je také ozna£ována jako transportní t°ída. Tento název vyplývá
z jejího pouºití jako prost°edku, který vyuºívají v²echny komunika£ní rozhraní pro p°enos dat jak ze zdrojového modulu do cílového, tak naopak. Tento objekt v²ak neobsahuje pouze p°ená²ená data, ale také atributy a p°íznaky týkající se komunikace. Jedná se v podstat¥ o standardizovanou ²ablonu. D·vod jejího pouºití v komunikaci mezi moduly je p°edev²ím to, ºe zlep²uje znovupouºitelnost vytvo°ených model· a de nuje standard komunikace.
3.6.1 Atributy a metody T°ída
tlm_generic_payload
obsahuje sadu atribut·, které je moºné p°es metody nastavovat
nebo £íst a tím realizovat p°enos dat. Skladba atribut· se snaºí zahrnout b¥ºné signály £i
44
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
stavy pouºívané v komunika£ních sb¥rnicích. Nastavení atribut· je provád¥no p°es volání
xxx, kde xxx
funkce set_
xxx.
funkce get_
je nahrazeno za název atributu. tení se analogicky provádí pomocí
Zde je seznam atribut· t°ídy
tlm_generic_payload,
jejich detailn¥j²í popis
následuje v dal²ích sekcích.
Command (command ) Address (address )
p°íkaz pro cílový modul (£tení nebo zápis)
adresa £tení/zápisu (adresa v pam¥ti)
Data pointer (data_ptr )
ukazatel na p°ená²ená data (fyzicky uloºená jako pole
byt·)
Data length (data_length )
délka p°ená²ených dat
Byte enable pointer (byte_enable_ptr )
pomocný ukazatel (platnosti dat)
Byte enable length (byte_enable_length ) Streaming width (streaming_width ) DMI allowed (dmi_allowed )
délka pomocného ukazatele
atribut
streaming burst
reºimu
indikace p°ímého p°ístupu
Response status (response_status )
status odpov¥¤i (signalizace zda transakce
skon£ila úsp¥²n¥ £i p°í£inu chyby viz. tabulka 3.3)
Extension pointers
speciální parametr umoº¬ující p°idat dal²í parametry pro
roz²í°ení standardní p°enosové t°ídy generic payload a zárove¬ zachování stejného p°enosového formátu [10, str. 94].
V¥t²ina parametr· je nastavena modulem za£ínající transakci a nem¥la by být m¥n¥na propojovacími bloky nebo blokem cílovým. Pouze parametry
sponse status a extension pointers Transak£ní objekt
generic payload
Address, DMI allowed, re-
mohou být propojovacími £i cílovým blokem pozm¥n¥ny. je vhodný pro celou °adu pam¥´ových rozhraní a pro-
tokol·. Tam kde by neposta£ovaly standardní atributy, je moºné vyuºít roz²í°ení pomocí mechanismu extension pointers. Samoz°ejm¥ ne v²echny parametry je nutné pouºít, nebo je naopak moºné jejich význam prizp·sobit zvolenému protokolu. Detailn¥j²í popis jednotlivých parametr· a jejich typický význam bude popsán v následujících sekcích.
3.6.
45
GENERIC PAYLOAD
3.6.2 Command Atribut
command
de nuje typ operace, kterou daná transakce provádí. V zásad¥ se jedná o
p°íkaz pro cílový modul aby vykonala £tení nebo zápis dat. Nastavení se provádí metodou
set_command(), £tení pomocí metody get_command(). P°ípustnými parametry p°i°azenými do tohoto atributu je bu¤
TLM_WRITE_COMMAND, TLM_READ_COMMAND
nebo
TLM_IGNORE_COMMAND pro nespeci kováno operaci. Pro otestování hodnoty v cílovém bloku lze pouºít metody
is_read()
p°ípadn¥
is_write(), které tento parametr testují.
3.6.3 Address Atribut
address
lze intuitivn¥ interpretovat jako adresu za£átku £tecí nebo zápisové oper-
ace v cílovém modulu. Adresa je zpravidla nastavena zdrojovým modulem, je v²ak moºné ji pozm¥nit propojovacím blokem (nap°íklad v p°ípad¥ p°ekladu adres propojovacím modulem). Defaultní hodnota atributu je 0. Nastavení a £tení atributu je realizováno metodami
set_address()
a
get_address().
3.6.4 Data pointer Data pointer
reprezentuje ukazatel na fyzicky uloºená data uvnit° bloku jako pole byt·.
Jedná se tedy bu¤ o data ur£ená k p°enosu (zápis) nebo alokované místo pro uloºení dat (£tení). K nastavení slouºí metoda
set_data_ptr(),
naopak k získání pouºijeme metodu
get_data_ptr(). Zdrojový blok je vºdy zodpov¥dný za alokování pot°ebného mnoºství pam¥ti v tomto ukazateli. Nastavení tohoto parametru na hodnotu
null
zp·sobí chybu p°i vyvolání
transakce.
3.6.5 Data length Atribut
data length ur£uje po£et byt·, které budou zapsány do pole na které ukazuje ukazatel
data pointer
v p°ípad¥ zápisové operace. Resp. opa£n¥ v p°ípad¥ operace £tení. K tomuto
ú£elu jsou ur£eny metody
set_data_length() a get_data_length(). Tato hodnota je zpravidla
nastavena zdrojovým modulem a není cílem ani propojovacími moduly m¥n¥na.
46
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
3.6.6 Byte enable pointer Tento atribut obsahuje odkaz na pole byt·, které p°edstavuje masku pro p°edávaná data ur£ená atributem
data pointer.
Je tedy moºné pomocí tohoto mechanismu rozhodovat na
úrovni jednotlivých byt·, zda jsou konkrétní data platná £i nikoliv a podle toho zápis (£tení) konkrétního bytu provést £i vynechat. Nastavení se provádí metodou získání aktuální hodnoty pak metodou
set_byte_enable_ptr(),
get_byte_enable_ptr().
3.6.7 Byte enable length Význam tohoto pole je jednoduchý ur£uje po£et element· v poli na které odkazuje atribut
byte enable pointer. Délka masky je volitelná, ale v zásad¥ p°ipadají v úvahu dv¥ moºnosti. V první je maska stejn¥ dlouhá jako p°ená²ená data. V tomto p°ípad¥ maska p°esn¥ odpovídá a aplikace masky je provedena triviáln¥. V druhém uvaºovaném p°ípad¥ je maska krat²í. Zde platí pravidlo, ºe je skládána za sebe aº do dosaºení délky p°ená²ených dat.
3.6.8 Streaming width Atribut v tzv.
streaming width
streaming burst
je moºné pouºít v p°ípad¥, ºe je poºadováno provedení transakce
reºimu. Tento reºim se skládá z n¥kolika sekvencí datových p°enos·
jdoucích po sob¥. Atribut ur£uje po£et byt· v jedné sekvenci. To znamená, ºe po£et p°enos· v jedné sekvenci je roven podílu atributu
data lenght
a práv¥ tohoto atributu
Z tohoto vztahu také vyplývá pravidlo, ºe pokud nechceme reºim nastavíme hodnotu tohoto atributu stejnou jako provádí metodou
data length
streaming width.
streaming burst
pouºít
(p°ípadn¥ vy²²í). Nastavení se
set_streaming_width(), £tení metodou get_streaming_width().
3.6.9 DMI allowed Tento atribut poskytuje informaci zdrojovému modulu o tom, zda cíl poskytuje moºnost p°ímého p°ístupu do pam¥ti. Ú£el tedy spo£ívá v tom, ºe cílový modul m·ºe nastavit tento
true
a zdroj poté m·ºe ºádat o povolení p°ímého p°ístupu. Metodu pro nastavení
je moºné volat
set_dmi_allowed(true), pro otestování se pouºívá metoda is_dmi_allowed().
atribut na
Defaultní hodnotou je
false.
3.7.
47
SOCKETY
3.6.10 Response status Atribut
response status
(statusu odpov¥di generovaný cílovým modulem) lze s výhodou
pouºít jak pro signalizaci správn¥ dokon£ené operace, tak pro signalizaci chyby. V tabulce 3.3 jsou vypsány p°ípustné navratové hodnoty. Pouºití t¥chto hodnot je zejména vhodné v LT modelech, kde volající modul £eká p°ímo na odpov¥¤ od cílového modulu.
Návratové hodnoty odpov¥dí
Obvyklý význam odpov¥di
TLM_OK_RESPONSE
Cíl je schopen provést poºadovanou operaci
TLM_INCOMPLETE_RESPONSE
Nedokon£ená operace
TLM_ADDRESS_ERROR_RESPONSE
Nelze £íst/zapisovat danou adresu (obvykle mimo rozsah)
TLM_COMMAND_ERROR_RESPONSE
Nelze
provést
poºadovanou
operaci
(nepodporovaný p°íkaz) TLM_BURST_ERROR_RESPONSE
Nelze provést akci z d·vodu chybné délky dat
TLM_BYTE_ENABLE_ERROR_RESPONSE
Cíl nepodporuje bytový p°ístup
TLM_GENERIC_ERROR_RESPONSE
Jiná chyba
Tabulka 3.3: Návratové hodnoty transportní t°ídy generic payload
3.7 Sockety Pro propojení modul· se v TLM-2.0.1 pouºívají takzvané sockety. Jedná se o objekty p°edde novaných t°íd, které implementují rozhraní popsaná v kapitole 3.5.1. Tyto objekty obsahují metody pro operace s transakcemi, £ímº umoº¬ují komunikovat s okolními moduly a zajistí v²e pot°ebné pro komunikaci. Zdrojový modul komunikuje p°es zdrojový socket (
ini-
tiator socket ), zatímco cílový modul p°es cílový socket (target socket ). Lze uvaºovat i moduly, které slouºí pouze jako propojovací na cest¥ mezi zdrojem a cílem, ty zpravidla obsahují oba typy socket·. Klasický p°ístup k tvorb¥ komunika£ních rozhraní umoº¬uje návrhá°i reali-
48
KAPITOLA 3.
MODELOVÁNÍ NA ÚROVNI TRANSAKCÍ
zovat vlastní typy socket· uzp·sobené poºadavk·m vytvá°ených model· pomocí d¥di£nosti ze standardních socket·. Tento p°ístup je univerzální, ale vyºaduje jiº pokro£ilej²í znalost problematiky. Pro snadné pouºití socket· a propojení modul· je moºné vyuºít takzvané
venience sockets,
con-
které jsou jiº p°edde nované a jejich pouºití je tedy jednoduché. T¥chto
socket· bude také dále v p°íkladech vyuºíváno. Jedná se konkrétn¥ o objekty t°íd
ple_initiator_socket
pro zdrojový modul a
simple_target_socket
sim-
pro cílový modul. Jejich
deklarace je uvedena ve výpisu 3.3 a 3.4.
Listing 3.3: Deklarace zdrojového socketu
1
2
# include " tlm_utils / simple_initiator_socket .h" tlm_utils :: simple_initiator_socket < Initiator > socket ;
Listing 3.4: Deklarace cílového socketu
1
2
# include " tlm_utils / simple_target_socket .h" tlm_utils :: simple_target_socket < Target > socket ;
Se sockety dále souvisí dal²í pojem, kterým je registrace metod. Touto registrací se rozumí provázání p°íchozích volání p°es sockety s obsluºnými metodami v rámci modulu. Je to tedy p°i°azení obsluºných metod p°íchozím voláním blokujících nebo neblokujících transakcí. P°íklad takovéto registrace blokujícího voláni je ve výpisu 3.5, kde je blokující metod¥ na p°íchozím socketu
1
socket1
registrována metoda s názvem
b_transport_local.
Listing 3.5: Registrace obsluºné metody pro p°íchozí volání
socket1 . register_b_transport ( this , & Target :: b_transport_local );
Kapitola 4 TLM modely
V této kapitole budou uvedeny a podrobn¥ji rozebrány realizace TLM model· na kterých se pokusím ilustrovat vlastnosti model· a rozdíl mezi loosely-timed a approximately-timed modely. Kapitola p°ímo navazuje na p°edchozí kapitolu 3 a ilustruje v ní pouºitou teorii na praktických p°íkladech. Také se zde vyskytují programové konstrukty popsané v kapitole 2 zabývající se RTL modelováním, strukturou programu stejn¥ jako hierarchickým popisem.
4.1 len¥ní kapitoly V této kapitole budou uvedeny celkem t°i p°íklady TLM model·, na kterých budu ilustrovat d°íve vysv¥tlené principy. P°íklady byly vytvá°eny s cílem ilustrovat principy a praktické moºnosti TLM modelování. Zdrojové kódy zde uvád¥né, jsou v textu s ohledem na £itelnost zkráceny. Jejich kompletní výpis je sou£ástí p°iloºeného CD spolu s kompila£ními skripty. V p°ípad¥ nejasností doporu£uji nahlédnout do kompletních kód· ze kterých mohou být n¥které £ásti výkladu srozumiteln¥j²í. P°i tvorb¥ p°íklad· bylo £erpáno jak z o ciální dokumentace TLM [10], tak z dal²ích zdroj· uvedených v literatu°e na konci práce [16, 2, 5].
4.2 Základní loosely-timed model Jako první bude vhodné uvést p°íklad modelu loosely-timed, který vyuºívá ke komunikaci jen a pouze blokující rozhraní. Ostatní pomocné a pokro£ilé techniky (DMI p°ímý p°ístup do
49
50
KAPITOLA 4.
TLM MODELY
pam¥ti £i ladící rozhraní) budou pouºity v dal²ím p°íkladu. P°íklad je obsaºen na p°iloºeném CD v adresá°i
les
pod názvem
TLM_loosely_time_model.
Intiutivn¥ si lze tento p°íklad p°edstavit jako komunikaci mezi procesorem a pam¥tí. Procesor pot°ebuje £íst a zapsat data externí pam¥ti, je tedy v roli iniciátora transakce. Pam¥´ v tomto p°ípad¥ p°edstavuje cílový modul. Protokol jakým si vym¥ní data zde není de nován, jen budou data p°enesena z pam¥ti do procesoru (a naopak) za pomoci n¥kolika transakcí. Tento základní loosely-timed model obsahuje tedy pouze dva moduly Initiator (zdroj) a Target (cíl). Ú£elem tohoto modelu bude provést sérii transakcí, kterou zapo£ne zdrojový modul. Cílový modul bude na p°íchozí transakce reagovat provedením zápisu dat (která budou sou£ástí transakce) do své lokální pam¥ti a odesláním odpov¥di zdrojovému modulu o pr·b¥hu a skon£ení transakce. Výsledkem transakce bude zm¥na dat v pam¥ti cílového modulu. Na obrázku 4.1 jsou znázorn¥ny oba moduly spole£n¥ s metodami (obdélníky se zaoblenými rohy), které obsluhují transak£ní zpracování.
Obrázek 4.1: Blokové schéma základního loosely-timed modelu
Kaºdý modul obsahuje jednu metodu. Metoda
initiator_socket
thread_process zdrojového modulu vyuºívá
k zahájení transakce. Naproti tomu je v cílovém bloku metoda
registrována jako obsluha p°íchozích blokujících transakcí.
4.2.1 Zdrojový modul V následujícím výpisu 4.1 je uveden hlavi£kový soubor bloku Initiator:
b_transport
4.2.
Listing 4.1: Hlavi£kový soubor bloku Initiator (základní loosely-timed model)
1
2
3
4
5
6
51
ZÁKLADNÍ LOOSELY-TIMED MODEL
# ifndef INITIATOR_H # define INITIATOR_H # define SC_INCLUDE_DYNAMIC_PROCESSES # include " systemc . h" # include " tlm .h " # include " tlm_utils / simple_initiator_socket .h"
7
8
9
10
// Modul "Initiator" generuje transakce SC_MODULE ( Initiator )
// deklarace zdrojového modulu
{ // TLM-2 socket - deklarace zdrojového (výstupního) portu
11
tlm_utils :: simple_initiator_socket < Initiator > socket ;
12
int data ;
13
// místo pro data transakce
void thread_process (); // metoda zdrojového modulu
14
15
SC_CTOR ( Initiator )
16
: socket ( " socket ") // vytvo° a pojmenuj socket
17
{
18
SC_THREAD ( thread_process ); // registrace metody jako procesu
19
}
20
21
22
// konstruktor
}; # endif
Zdrojový modul stejn¥ jako vzorový RTL model uvedený v kapitole 2.5 nejprve obsahuje na za£átku a na konci zdrojového textu direktivu pro p°eklada£, která zamezí chyb¥ p°i p°ekladu v p°ípad¥ pouºití
Initiator
delu. Dále je pot°eba de novat makro
modulu ve více souborech v rámci jednoho mo-
SC_INCLUDE_DYNAMIC_PROCESSES
je²t¥ p°ed
vloºením (pouºitím direktivy #include) knihoven SystemC a knihovny TLM. A to z d·vodu, ºe sou£asná implementace pouºitého komunika£ního rozhraní
simple_socket vyuºívá dynami-
cké procesy, které je nutné explicitn¥ povolit touto direktivou [10, str. 128]. Na dal²ích t°ech
52
KAPITOLA 4.
TLM MODELY
°ádcích jsou pak jiº standardn¥ vloºeny hlavi£kové soubory pouºitých knihoven. Deklarace za£átku modulu za£íná klí£ovým slovem
SC_MODULE, kde jako parametr v závorce je uve-
deno jméno modulu. V t¥le modulu na °ádku 12 je pak zadeklarován komunika£ní socket. Konkrétn¥ se jedná o socket
simple_initiator_socket,
modulu iniciujícího transakce. Jedná se o takzvaný rozhraní
tlm_initiator_socket
resp.
který je vhodné pouºít na stran¥
convenience socket,
tlm_target_socket
který implementuje
a usnad¬uje pouºití a propojení mo-
dul·. Deklarace prom¥nné p°edstavující p°ená²ená data je uvedena na °ádku 13. Deklarace jediné t°ídní metody neboli metody pouºité v modulu je provedena na 14. °ádku. V konstruktoru modulu je následn¥ metoda zaregistrována jako proces typu umoºní do metody vkládat £ekací p°íkazy
SC_THREAD,
coº
wait(). Proces bude pouºit pro generování sekvence
transakcí. Implementa£ní soubor
Initiator.cpp
obsahuje pouze t¥lo metody
thread_process(). Frag-
ment t¥la metody je uveden v následujcím výpisu 4.2:
1
2
3
4
5
6
7
8
9
10
11
Listing 4.2: De nice funkce thread_process() (základní loosely-timed model)
void Initiator :: thread_process () { tlm :: tlm_generic_payload * trans = new tlm :: tlm_generic_payload ; sc_time delay = sc_time (10 , SC_NS ); tlm :: tlm_command cmd ; int counter = 0; // následuje cyklus pro generování transakcí for ( int i = 0; i < TEST_RANGE / 2; i += 4) { counter ++; // následuje nastavení parametr· transakce cmd = tlm :: TLM_WRITE_COMMAND ; // p°íkaz zápisu data = 0 xFF000000 + counter ;
// data transakce
12
13
14
15
16
trans - > set_command ( cmd ); // £tecí p°íkaz transakce trans - > set_address (i );
// nastavení adresy
trans - > set_data_ptr (( char *) (& data )); // nastavení ukazatele trans - > set_data_length (4); // nastavení délky dat (4B)
4.2.
trans -> set_byte_enable_ptr (( char *) ( TLM_BYTE_DISABLED ));
17
trans -> set_streaming_width (4);
18
trans -> set_dmi_allowed ( false ); // DMI nepouºito
19
trans -> set_response_status ( tlm :: TLM_INCOMPLETE_RESPONSE );
20
// následuje p°íkaz provedení transakce
21
socket -> b_transport (* trans , delay ); // blokovací metoda
22
// následuje kontrola statusu odpov¥di
23
if ( trans - > is_response_error ()) { // je odpov¥d v po°ádku?
24
SC_REPORT_ERROR (" TLM -2 " , " Error b_transport " );
25
}
26
wait (2* delay ); // prodlení mezi transakcemi
27
}
28
29
53
ZÁKLADNÍ LOOSELY-TIMED MODEL
}
V úvodu metody je inicializována instance t°ídy
tlm_generic_payload, slouºící jako trans-
portní objekt pro transakce (viz. 3.6). Následuje de nice £asové prom¥nné pouºitá pro rozestup mezi generováním jednotlivých transakcí. Na °ádku 4 pak je deklarována prom¥nná ozna£ující provád¥nou operaci následována na dal²ím °ádku celo£íselnou prom¥nnou
counter
slouºící jako £íta£ transakcí. Po bloku deklarací prom¥nných následuje for cyklus iterujicí práv¥ tolikrát na kolik je nastavena prom¥nná
TEST_RANGE. V t¥le cyklu je nejprve zvý²en
£íta£ transakcí a následn¥ nastaven p°íkaz operace na zápis. Následuje p°ipravení p°ená²ených dat zde kombinace xní hodnoty s £íta£em transakcí. Na °ádcích 13 aº 20 je pak realizováno napln¥ní instance transak£ního objektu
trans
hodnotami. Na °ádku 22 je volána
blokující transak£ní metoda s dv¥ma parametry, kde prvním je transak£ní objekt a druhým £asová prom¥nná, ze které m·ºe cílový modul odvodit celkovou dobu trvání transakce. Po volání metody blokujícího volání je volající metoda zablokována aº do p°ijetí odpov¥di z cílového modulu. Status odpov¥di musí cílový modul v kaºdém p°ípad¥ nastavit a tak je vhodné ho okamºit¥ po p°ijetí odpov¥di zkontrolovat. Kontrola se provede pomocí funkce
is_response_error()
resp.
is_response_ok(). Jedná se o metody testující chybové (p°ípadn¥
bezchybné) provedení transakcí bez nutnosti testovat textové hodnoty vý£tového typu, které standardn¥ vrací metoda
get_response_string. Posledním krokem je jiº jen vy£kání stanove-
54
KAPITOLA 4.
nou dobu mezi jednotlivými transakce pomocí metody
wait(2*delay)
TLM MODELY
dvojnásobek hodnoty
£asové prom¥nné, tedy 20 ns.
4.2.2 Cílový modul Cílový modul reprezentuje model jednoduché pam¥ti. Konkrétn¥ to znamená, ºe modul provede p°ijetí poºadavku transakce, provede akci speci kovanou v t¥le transak£ního objektu a za²le informaci o výsledku. Hlavi£kový soubor je uveden v následujícím výpisu 4.3:
1
2
3
4
5
6
7
Listing 4.3: Hlavi£kový soubor bloku Target (základní loosely-timed model)
# ifndef TARGET_H # define TARGET_H # define SC_INCLUDE_DYNAMIC_PROCESSES # define SIZE 512 # include " systemc . h" # include " tlm .h " # include " tlm_utils / simple_target_socket .h"
8
9
10
11
12
13
SC_MODULE ( Target )
// deklarace cílového modulu
{ // TLM-2 socket - deklarace cílového (vstupního) portu tlm_utils :: simple_target_socket < Target > socket ; int mem [ SIZE ];
// deklarace pam¥ti
14
15
16
17
18
19
20
21
22
SC_CTOR ( Target )
// konstruktor
: socket ( " socket ") { // registrace metody jako obsluhu p°íchozích blokujících transakcí socket . register_b_transport ( this , & Target :: b_transport ); int counter = 0; // následuje cyklus pro p°ednastavení obsahu pam¥ti for ( int i = 0; i < SIZE ; i ++) { counter ++;
4.2.
mem [i ] = 0 xAA000000 + counter ;
23
}
24
}
25
void b_transport ( tlm :: tlm_generic_payload & trans ,
26
sc_time & delay ); // obsluºná metoda transakcí
27
28
29
55
ZÁKLADNÍ LOOSELY-TIMED MODEL
}; # endif
Na za£átku jsou jako v ostatních p°íkladech pouºity standardní direktivy p°eklada£e. Za pov²imnutí zde stojí na °ádku 7 zahrnutí socketu socketu nahradil
simple_target_socket.h,
který v cílovém
tlm_initiator_socket. V konstruktoru je analogicky se zdrojovým modulem
vytvo°en socket pro p°íchozí transak£ní ºádosti. Následuje vytvo°ení pam¥´ového prostoru cílového modulu. V konstruktoru je nejprve nutné na p°íchozím socketu registrovat obsluºnou metodu pro p°íchozí blokující transakce. To je provedeno na °ádku 18, kde je pro tento ú£el ur£ena funkce
b_transport, která je sou£ástí cílového modulu Target. Sou£ástí konstruktoru
je také inicializace pam¥ti, která je napln¥na p°edde novaným obsahem pomocí for cyklu mezi °ádky 21 aº 24. Toto p°ednastavení je provedeno £ist¥ z testovacích ú£el·, aby bylo moºné zkontrolovat rozdíl p°ed a po provedení série zápisových transakcí. Na konci výpisu je pak uvedena deklarace obsluºné metody p°íchozí transakce. Implementace této metody je uvedena v následujícím výpisu 4.4. Výpis implementa£ního souboru
Target.cpp
je zde
zkrácen, kompletní soubor je sou£ástí p°iloºeného CD.
1
Listing 4.4: De nice obsluºné metody p°íchozí transakce (základní loosely-timed model)
void Target :: b_transport ( tlm :: tlm_generic_payload & trans , sc_time & delay ) {
2
3
wait ( delay ); // zpoºd¥ní odpov¥di bloku - doba trvání transakce
4
5
6
7
8
tlm :: tlm_command
cmd = trans . get_command ();
sc_dt :: uint64
adr = trans . get_address () / 4;
unsigned char *
ptr = trans . get_data_ptr ();
unsigned int
len = trans . get_data_length ();
56
9
10
KAPITOLA 4.
TLM MODELY
unsigned char *
byt = trans . get_byte_enable_ptr ();
unsigned int
wid = trans . get_streaming_width ();
11
if ( adr >= sc_dt :: uint64 ( SIZE ) || adr < 0)
12
SC_REPORT_ERROR (" TLM -2 " , " Address is out of range " );
13
if ( byt != TLM_BYTE_DISABLED )
14
SC_REPORT_ERROR (" TLM -2 " , " Byte addressing is disabled " );
15
// provedení £tení p°ípadn¥ zápisu dat
16
if ( cmd == tlm :: TLM_READ_COMMAND )
17
memcpy ( ptr , & mem [ adr ] , len );
18
else if ( cmd == tlm :: TLM_WRITE_COMMAND )
19
memcpy (& mem [ adr ], ptr , len );
20
21
trans . set_response_status ( tlm :: TLM_OK_RESPONSE );
22
23
}
Obsluºná metoda
b_transport
nejprve simuluje zpoºd¥ní cílového bloku. Následn¥ jsou z
transportního objektu získány informace o transakci, které jsou následn¥ uloºeny do vytvo°ených datových prom¥nných. Sou£ástí metody je také kontrola podporovaných parametr· transakce cílovým blokem. Dále jsou v závislosti na poºadované operaci data £tena nebo zapsána do lokální pam¥ti. Poslední provedenou akcí je nastavení transak£nímu objektu návratový status transakce na °ádku 22. Skon£ením obsluºné metody je blokující volání ukon£eno. Transak£ní objekt je uvoln¥n volajícímu bloku (Initiator) k provedení kontroly nastavených p°íznak·.
4.2.3 Propojení modul· K propojení modul· je nutné vytvo°it dal²í tzv. top-level modul, který zdrojový a cílový modul propojí. To je provedeno v souboru
1
2
Top.cpp, který je uveden ve výpisu 4.5.
Listing 4.5: Propojení modul· (základní loosely-timed model)
# include " Initiator .h " # include " Target .h "
4.2.
3
SC_MODULE ( Top ) { // zastre²ující modul Initiator * initiator ;
4
Target * target ;
5
SC_CTOR ( Top ) { // deklarace konstruktoru
6
initiator = new Initiator (" initiator " );
7
target = new Target ( " target " );
8
// propojení socket· v bloku Initiator a Target
9
initiator -> socket . bind ( target - > socket );
10
//target->socket.bind(initiator->socket); // ekvivalentní varianta
11
}
12
13
57
ZÁKLADNÍ LOOSELY-TIMED MODEL
};
Po nezbytném zahrnutí propojovaných blok· direktivou
#include
jsou v t¥le modulu
deklarovány objekty zdrojového modulu, které jsou následn¥ v konstruktoru vytvo°eny. Propojení je provedeno metodou Metodu
bind(*simple_socket)
bind(*simple_socket)
na posledním °ádku konstruktoru.
je moºné volat jak na socket bloku Initiator (jako v tomto
p°ípad¥) nebo na socket v cílovém bloku. Ob¥ p°i°azení jsou ekvivalentní a mají za následek stejné propojení.
4.2.4 Vstupní bod programu Stejn¥ jako kaºdý
C++
program musí obsahovat
novat. Metoda je pouze roz²í°ena o pre x
sc_
main()
metodu i zde je povinnost jí de -
jinak je standardní. V t¥le metody je nutné
vytvo°it instanci Top modulu a simulaci spustit. De nice výstupního souboru pro uloºení pr·b¥h· (viz. 2.5.4) zde není vyuºita. A to z toho d·vodu, ºe pro modely na této úrovni abstrakce nepracujeme s konkrétními signály.
1
Listing 4.6: Main funkce (základní loosely-timed model)
# include " Top . cpp "
2
3
4
int sc_main ( int argc , char * argv []) { Top top (" top " );
// vytvo°eni Top modulu
58
sc_start ();
5
TLM MODELY
// spu²t¥ní simulace
return 0;
6
7
KAPITOLA 4.
}
4.2.5 Shrnutí Na p°íkladu je ilustrováno základní pouºití blokovacího transak£ního rozhranní v loosely-time modelech. Pro p°enos transak£ních dat je pouºit transak£ní objekt a £asová prom¥nná pro simulaci trvání celé transakce. Zde uvedené výpisy kódu jsou z d·vodu zlep²ení £itelnosti v mnoha p°ípadech zkráceny, z tohoto d·vodu odkazuji na kompletní modely, které jsou sou£ástí p°iloºeného CD.
4.3 Pokro£ilej²í loosely-timed model Tento model bude stejn¥ jako p°edchozí obsahovat dva moduly Initiator a Target. Ú£elem modelu bude také pomocí blokujích transak£ních volání zapsat do cílového modulu data. Rozdíl bude v²ak ve zp·sobu jakým toho bude docíleno. V p°íkladu bude pouºito principu DMI, tedy takzvaného p°ímého p°ístupu do pam¥ti. Dále je zde vedle komunika£ního rozhraní také pouºito ladící rozhraní pro kontrolu výpisu obsahu pam¥ti po skon£ení v²ech zápisových transakcí. Ladicí rozhraní lze s výhodou pouºít p°i sledování zm¥n obsahu pam¥ti v pr·b¥hu simulace zatímco p°ímý p°ístup do pam¥ti (DMI) slouºí k urychlení simulace. Tohoto urychlení je docíleno nahrazením transakcí v podob¥ blokujících volání
b_transport
p°ímým zápisem £i £tením pam¥ti cílového modulu pomocí ukazatele. Ve zdrojových kódech jiº budou uvedeny jen zm¥ny provedené oproti p°edchozímu p°íkladu s d·razem na srozumitelnost a £itelnost celého textu. P°ípadné nejasnosti bude nejlep²í srovnat s kompletním p°íkladem obsaºeném na CD v adresá°i
les pod názvem TLM_loosely_time_model_advance.
Na obrázku 4.2 je znázorn¥no komunika£ní schéma tohoto modelu. Oproti p°edchozímu modelu p°ibyl ve zdrojovém modulu ukazatel
dmi_mem
p°es který je realizován p°ímý
p°ístup do pam¥ti cílového modulu a dal²í funkce pro zneplatn¥ní tohoto ukazatele. V cílovém modulu jsou obdobn¥ p°idány také obsluºné funkce pro DMI a ladicí rozhraní. Jejich registrace je uvedena v konstruktoru cílového modulu ve výpisu 4.9.
4.3.
POKROILEJÍ LOOSELY-TIMED MODEL
59
Obrázek 4.2: Blokové schéma pokro£ilej²ího loosely-timed modelu
4.3.1 Zdrojový modul Výpis 4.7 obsahuje pozm¥n¥nou £ást základního loosely-timed modelu.
1
2
Listing 4.7: Hlavi£kový soubor bloku Initiator (pokro£ilý loosely-timed model)
bool dmi_ptr_valid ; // p°íznak platnosti p°ímého ukazatele tlm :: tlm_dmi dmi_data ; // p°ímý ukazatel do pam¥ti
3
4
SC_CTOR ( Initiator ) : // konstruktor modulu socket (" socket "),
5
dmi_ptr_valid ( false )
6
7
{ // registrace metody jako obsluhy zneplat¬ující p°ímý p°ístup
8
socket . register_invalidate_direct_mem_ptr ( this ,
9
& Initiator :: invalidate_direct_mem_ptr );
10
SC_THREAD ( thread_process );
11
12
13
14
15
} void thread_process (); // proces pro popis chování modulu void invalidate_direct_mem_ptr ( sc_dt :: uint64 start , sc_dt :: uint64 end ) {
60
KAPITOLA 4.
dmi_ptr_valid = false ; // zneplatn¥ní p°ímého p°ístupu
16
17
TLM MODELY
}
Oproti p·vodní verzi jsou zde de novány dv¥ nové prom¥nné. V první bude uchovávána informace o platnosti ukazatele do pam¥ti cílového modulu, v druhém pak samotný ukazatel. V konstruktoru je zaji²t¥na neplatnost prom¥nné
invalidate_direct_mem_ptr
dmi_ptr_valid
a také registrace metody
jako metody, která bude mít na starost obsluhu p°ípadného
poºadavku cílového modulu o zru²ení p°ímého p°ístupu do pam¥ti cílového modulu. Toto zru²ení p°ímého p°ístupu spo£ívá pouze ve zneplatn¥ní prom¥nné trace a deklarace metody
thread_process
dmi_ptr_valid.
Regis-
je provedena stejným zp·sobem jako v p°edchozím
p°íkladu.
Obrázek 4.3: Vývojový diagram zápisu do cílového modulu (metoda
T¥lo metody
thread_process
thread_process )
je jiº s ohledem na vyuºití p°ímého p°ístupu pozm¥n¥no.
Cílem DMI je zrychlit celou simulaci a nahradit transakci prostou operací zápisu nebo £tení. K tomuto zp·sobu komunikace ale musí dát také souhlas cílový modul. Na obrázku 4.3 je
4.3.
61
POKROILEJÍ LOOSELY-TIMED MODEL
vývojový diagram zápisové transakce (nebo p°ímého zápisu) do cílového modulu. Z diagramu je patrné, ºe je nejprve zkontrolována platnost ukazatele do cílové pam¥ti. Pokud není platný, je provedena transakce b¥ºným zp·sobem pomocí blokovací metody
b_transport. Jejím cílem
je získat informaci o moºnosti p°ímého p°ístupu. V p°ípad¥ kladného výsledku se zdrojový modul pokusí získat p°ímý ukazatel. Od kaºdého následujícího pokusu o komunikaci lze uvaºovat dva p°ípady (odpovídající dvou v¥tvím v diagramu na obrázku 4.3):
cílový modul nepodporuje DMI
cílový modul podporuje DMI
Pokud je ukazatel získán (cílový modul podporuje DMI), je vyuºit p°ímý p°ístup. Pokud do zvolené £ásti pam¥ti není p°ímý zápis povolen, je komunikace realizována pomocí blokovací funkce
b_transport.
V následujícím výpisu 4.8 je zjednodu²ená £ást kódu odpovídající vývojovému diagramu na obrázku 4.3 spolu s následným výpisem obsahu pam¥ti pomocí ladícího rozhraní.
1
2
3
4
5
6
Listing 4.8: Zápis do cílového modulu (pokro£ilý loosely-timed model)
if ( dmi_ptr_valid ) { memcpy ( dmi_data . get_dmi_ptr () + i , & data , 4); // p°ímý zápis } else { // následuje standardní provedení transakce // Inicializace instance generic payload (trans) - VYNECHÁNO // standardní blokující volání - p°íkaz provedení transakce socket -> b_transport (* trans , delay );
7
8
9
if ( trans - > is_response_error ()) SC_REPORT_ERROR (" TLM -2 " , " Response error " );
10
11
12
13
14
if ( trans - > is_dmi_allowed ()) { // test zda je podporováno DMI dmi_data . init (); // inicializace objektu dmi ukazatele // následuje nastavení p°ímého ukazatele a p°íznaku platnosti voláním // metody modulu Target
62
KAPITOLA 4.
dmi_ptr_valid = socket -> get_direct_mem_ptr (* trans , dmi_data );
15
}
16
17
} // po p°edchozím zápisu následuje provedení £tení pomocí debug interface
18
unsigned char * data_debug = new unsigned char [2 * TEST_RANGE ];
19
trans - > set_address (0); // nastavení adresy
20
trans - > set_read (); // nastavení operace
21
trans - > set_data_length (2 * TEST_RANGE ); // nastavení rozsahu
22
trans - > set_data_ptr ( data_debug ); // nastavení alokovaného místa
23
// následuje p°enos obsahu pam¥ti pro kontrolní ú£ely
24
unsigned int nr_of_bytes = socket - > transport_dbg (* trans );
25
// následuje kontrolní výpis pam¥´i
26
for ( unsigned int i = 0; i < nr_of_bytes ; i += 4) {
27
cout << "M [" << i << " ] = "
28
<< ( unsigned int *) (& data_debug [ i ])) << endl ;
29
30
TLM MODELY
}
První dva °ádky p°edstavují p°ímý zápis. Ten je realizován funkcí pravé v¥tvi ve výjovém diagramu na obrázku 4.3. Kód v £ásti
memcpy()
a odpovídá
else provádí komunikaci pomocí
blokující metody za ú£elem provedení transakce v p°ípad¥, ºe není platný ukazatel p°ímého p°ístupu. Cílem transakce je získat p°ímý p°ístup pokud je cílem povolen. Za pov²imnutí také stojí realizace výpisu pam¥ti, která je zde provedena pomocí ladícího rozhraní. Ladící rozhraní pouºívá, stejn¥ jako ostatní rozhraní, transportní t°ídu
generic_payload
k p°enosu
dat. Je zde ale nutné nastavit pouze £ty°i parametry uvedené na °ádcích 20 aº 23. Samotný p°enos je realizován pomocí funkce
socket->transport_dbg(*trans), která vrací po£et £tených
byt·. Metoda zkopíruje vybraný obsah pam¥ti jediným p°íkazem. Toho lze s výhodou vyuºít v p°ípad¥, ºe chceme v pr·b¥hu simulace sledovat zm¥ny v pam¥ti v r·zných £asových okamºicích. Na záv¥r je
for
cyklem celý obsah pam¥ti vypsán.
4.3.
POKROILEJÍ LOOSELY-TIMED MODEL
63
4.3.2 Cílový modul Cílový modul zde také jako v p°íkladu základního loosely-timed modelu p°edstavuje model pam¥ti. Zde ale je jiº nutné s ohledem na pouºití metody p°ímého zápisu do pam¥ti a ladícího rozhraní také zaregistrovat metody, které budou tuto funkci zaji²´ovat. Dále je zde také metoda
invalidation_process(), která v pravidelných intervalech zneplatní ukazatel pro
p°ímý p°ístup do pam¥ti a ilustruje pouºití metody
invalidate_direct_mem_ptr() zdrojového
modulu. Toto zneplatn¥ní má pouze ilustra£ní charakter a je zde provád¥no v pravidelných intervalech 40 nanosekund. V následujícím výpisu 4.9 je uveden hlavi£kový soubor cílového modulu.
Listing 4.9: Hlavi£kový soubor bloku Target (pokro£ilý loosely-timed model)
1
2
3
SC_MODULE ( Target ) { tlm_utils :: simple_target_socket < Target > socket ; int mem [ SIZE ];
4
5
SC_CTOR ( Target ) : socket ( " socket ") { socket . register_b_transport ( this , & Target :: b_transport );
6
socket . register_get_direct_mem_ptr ( this ,
7
& Target :: get_direct_mem_ptr );
8
socket . register_transport_dbg ( this ,& Target :: transport_dbg );
9
int counter = 0;
10
// následuje cyklus pro p°ednastavení obsahu pam¥ti
11
for ( int i = 0; i < SIZE ; i ++) {
12
counter ++;
13
mem [i ] = 0 xAA000000 + counter ;
14
}
15
// chování cílového modulu - zneplat¬ující proces
16
SC_THREAD ( invalidation_process );
17
18
19
20
} // hlavi£ky funkcí pouºitých v bloku void b_transport (& trans , sc_time & delay );
64
TLM MODELY
bool get_direct_mem_ptr (& trans , tlm :: tlm_dmi & dmi_data );
21
unsigned int transport_dbg ( tlm :: tlm_generic_payload & trans );
22
void invalidation_process ();
23
24
KAPITOLA 4.
};
Cílový modul je roz²í°en v konstruktoru o registraci dvou metod první metodou je
get_direct_mem_ptr,
druhou pak metoda
transport_dbg.
Tato registrace zajistí spárování
p°íchozího poºadavku o získání p°ímého ukazatele do pam¥ti (resp. p°ístup p°es ladící rozhraní) se skute£nou realizací metody uvnit° modulu. De nice obou t¥chto metod a zneplat¬ující metoda je v následujícím výpisu 4.10.
1
Listing 4.10: De nice obsluºných metod cílového modulu (advance loosely-timed model)
bool Target :: get_direct_mem_ptr ( tlm :: tlm_generic_payload & trans , tlm :: tlm_dmi & dmi_data ) {
2
dmi_data . allow_read_write (); // povolení £tení i zápisu p°es DMI
3
sc_time delay = sc_time (5 , SC_NS ); // definice zpoºd¥ní
4
// po£áte£ní adresa pam¥´ového bloku
5
dmi_data . set_dmi_ptr (( unsigned char *) (& mem [0]));
6
dmi_data . set_start_address (0); // po£áte£ní adresa pro DMI
7
dmi_data . set_end_address ( SIZE ); // koncová adresa pro DMI
8
dmi_data . set_read_latency ( delay ); // parametr £tecího zpoºd¥ní
9
dmi_data . set_write_latency (2 * delay ); // parametr zápisového sp.
10
return true ;
11
12
}
13
14
15
16
17
18
19
unsigned int Target :: transport_dbg ( tlm_generic_payload & trans ) { tlm :: tlm_command cmd = trans . get_command (); // £tecí p°íkaz sc_dt :: uint64
adr = trans . get_address () / 4; // adresa
unsigned char *
ptr = trans . get_data_ptr (); // nast. ukazatele
unsigned int
len = trans . get_data_length (); // nast. délky
4.3.
65
POKROILEJÍ LOOSELY-TIMED MODEL
if ( cmd == tlm :: TLM_READ_COMMAND )
20
memcpy ( ptr , & mem [ adr ] , len ); // £tení bloku délky "len"
21
22
return len ;
23
24
}
25
26
void Target :: invalidation_process () { sc_time delay = sc_time (10 , SC_NS ); // deklarace spoºd¥ní
27
for ( int i = 0; i < 4; i ++) {
28
wait ( delay * 4); // zpoºd¥ní mezi jednotlivými zneplatn¥ními
29
// zneplatn¥ní moºnosti p°ímého p°ístupu
30
socket -> invalidate_direct_mem_ptr (0 , SIZE - 1);
31
}
32
33
}
Vstupními parametry metody
jekt t°ídy
get_direct_mem_ptr()
tlm_dmi. T°ída tlm_dmi
je transak£ní objekt
trans
a ob-
slouºí jako objekt obsluhující DMI p°ístup. Metoda nas-
taví rozsah platnosti p°ímého ukazatele (p°ímý p°ístup nemusí být povolen do celé pam¥ti), zpoºd¥ní a samotný ukazatel. Metoda objektu
trans
a pomocí funkce
transport_dbg zjistí parametry vstupního transak£ního
memcpy()
provede zkopírování zvolené £ásti pam¥ti. Návra-
tovou hodnotou této funkce je po£et zkopírovaných byt·. Poslední funkcí je funkce
tion_process(),
invalida-
která v pravidelných cyklech (zde £ty°i cykly s odstupem 40 nanosekund),
provede zneplatn¥ní ukazatele pro p°ímý p°ístup. To zp·sobí, ºe zdrojový modul musí nejprve provést blokující volání a aº poté se op¥t pokusit získat p°ímý p°ístup do pam¥ti. V tomto p°ípad¥ se jedná pouze o ilustraci pouºití, kde je zneplatn¥ní pouºito po uplynutí zvoleného £asového okamºiku. Samoz°ejm¥ je moºné pouºít zneplatn¥ní p°i nastalé události nebo po zvoleném po£tu zápis· atd.
4.3.3 Shrnutí Propojení zdrojového a cílového modulu i vstupní funkce
sc_main()
je realizována naprosto
stejným zp·sobem jako v p°edchozím p°íkladu 4.2 a proto je zde vynecháno.
66
KAPITOLA 4.
TLM MODELY
P°íklad ilustruje pouºití pokro£ilej²ích technik loosely-timed model·. Je zde ukázána technika p°ímého p°ístupu do pam¥ti a komunikace p°es ladící rozhraní. V p°íkladu je ukázáno jak komunikující modely upravit pro tento ú£el, jak registrovat obsluºné metody i to jak jiº alokovaný p°ímý p°ístup zneplatnit.
4.4 Approximately-timed model Takzvané approximately-timed modely se z hlediska abstrakce li²í od loosely-timed model· zp°esn¥ním komunika£ního rozhraní. Jedná se v podstat¥ o p°esn¥j²í popis mezimodulové komunikace oproti untimed nebo loosely-timed model·m. Proto jsou takto modelované moduly zpravidla znateln¥ simula£n¥ náro£n¥j²í neº LT, ale stále rychlej²í neº moduly na úrovni RTL. K vyvolání transakce jsou pouºívany neblokující komunika£ní metody
nb_transport().
V této sekci bude popsán p°íklad approximately-timed modelu. D·raz bude kladen na co moºná nejsrozumiteln¥j²í ilustraci rozdíl· oproti loosely-timed model·m. P°íklad v sekci 4.2 byl pro lep²í p°edstavu p°irovnán ke zp·sobu komunikace procesoru s pam¥tí. Zde je moºné p°íklad interpretovat jako komunikaci procesoru s externím výpo£etním modulem, který provádí kontrolní sou£et nad de novanou mnoºinou dat. Transakce je zahájena ºádostí o komunikaci a p°edáním dat (adresy za£átku a konce poºadovaných dat). Na tuto ºádost výpo£etní blok odpoví p°ijetím ºádosti a provede výpo£et. Po ukon£ení výpo£tu je výsledek zaslán zp¥t procesoru, který svojí odpov¥¤í ukon£í transakci. Stejn¥ jako v p°edchozích p°íkladech i zde budou komunikovat dva moduly
tor
a
Target.
Initia-
V podkapitole 3.5.1.2 byly uvedeny zákládní schémata volání neblokujících
transportních metod. Zde uvedený p°íklad bude vyuºívat komunika£ní schéma odpovídající £asovému diagramu zp¥tného volání (viz. obrázek 3.5). Základní protokol o £ty°ech fázích (tabulka 3.1) zde bude pro ilustraci roz²í°en o jednu fázi nazvanou
internal_ph.
V této fázi
bude provedena poºadovaná operace, tedy £tení nabo zápis dat. Výb¥r p°íkladu s pouºitím zp¥tného volání byl zvolen z d·vodu, ºe se jedná o nejkomplexn¥j²í komunika£ní schéma z d°íve uvád¥ných. Struktura a propojení blok· modelu zde pouºitého je na obrázku 4.4. Z obrázku 4.4 je patrné, ºe kaºdý modul obsahuje £ty°i procesy (metody), které obsluhují komunikaci. Rozd¥lení na práv¥ £ty°i procesy jsem volil, aby p°echody mezi fázemi zaji²´oval
4.4.
67
APPROXIMATELY-TIMED MODEL
Obrázek 4.4: Blokové schéma approximately-timed modelu
Obrázek 4.5: P°echody mezi fázemi v approximately-timed modelu
pokaºdé jiný proces. ipkami sm¥°ujících vºdy od procesu £i rozhraní je nazna£eno který proces volá dal²í metodu svého bloku nebo komunikuje p°es komunika£ní kanál s druhým blokem. Pro lep²í ilustraci funkce je na obrázku 4.5 zobrazena posloupnost p°echodu mezi fázemi a metody, které tento p°echod zaji²´ují. ísla u ²ipek na obou obrázcích ozna£ují fázi ve kterém se práv¥ probíhající transakce nachazí s tímto významem:
jedni£ka ozna£uje fázi BEGIN REQUEST (za£átek ºádosti) metoda zapo£ne transakci voláním
thread_process
nb_transport_fw
dvojka ozna£uje fázi END REQUEST (konec ºádosti) metoda
send_end_req
ukon£í
fázi ºádosti transakce.
trojka ozna£uje fázi BEGIN RESPONSE (za£átek odpov¥di) metoda
send_response
68
KAPITOLA 4.
TLM MODELY
zapo£ne ukon£ování transakce zahájením fáze begin response
£ty°ka ozna£uje fázi END RESPONSE (konec odpov¥di) metoda
peq_cb zdrojového
modulu ukon£í transakci p°echodem do poslední fáze transakce.
Tyto £ty°i základní fáze základního protokolu jiº byli zmín¥ny d°íve v kapitole 3.5.1.2 a princip ukázán na obrázku 3.5. V tomto p°íklad¥ je po£et fází roz²í°en o vnit°ní fázi cílového bloku
internal_ph.
Obrázek 4.6: asový diagram transakce zp¥tného volání z p°íkladu Approximately-timed
Na obrázku 4.6 je znázorn¥n komunika£ní diagram vytvo°eného modelu. Zárove¬ s voláním neblokujících transak£ních metod jsou zde vyzna£eny i ty metody, které toto volání provádí. Spolu s nimi je analogicky v prot¥j²ím modulu vyzna£ena metoda, která zpracovává p°íchozí volání. Po°adí ve kterém jsou metody volány odpovídá £íslování podle obrázku 4.4. Z n¥j je také moºné vy£íst to, která metoda toto volání provádí. Dále je patrné, ºe p°íchozí volání je vºdy zpracováno v cílovém modulu metodou
nb_tansport_fw, resp. metodou
4.4.
69
APPROXIMATELY-TIMED MODEL
nb_tansport_bw
ve zdrojovém modulu. Ostatní metody zaji²´ují p°echody mezi fázemi
transakce. Za pov²imnutí dále stojí metoda
peq_cb
(payload event queue callback), která
je obsaºená jak ve zdrojovém, tak v cílovém modulu a která ur£uje podobu protokolu rozhodováním o p°echodech mezi fázemi. V kaºdém modulu je její implementace rozdílná, její význam je ale stejný obsluha fronty událostí. Z obrázku 4.4 je vid¥t, ºe po p°ijetí neblokujícího volání je toto volání zpracováno metodou resp.
nb_transport_bw
v modulu Target
v modulu Initiator. Následn¥ je poºadavek (v podob¥ volání metody)
p°edán front¥ událostí reprezentovanou objektem provede kód metody
nb_transport_fw
peq_cb.
m_peq, která vºdy po nastaveném zpoºd¥ní
Tím je zaji²t¥no provedení zpoºd¥ní ur£ité £ásti transakce s
p°edepsaným zpoºd¥ním bez blokování b¥hu celého programu.
4.4.1 Zdrojový modul V následujícím výpisu 4.11 je uveden hlavi£kový soubor bloku Initiator:
1
2
Listing 4.11: Hlavi£kový soubor bloku Initiator (approximately-timed model)
# ifndef INITIATOR_H # define INITIATOR_H
3
4
5
6
7
# include " systemc " # include " tlm .h " # include " tlm_utils / simple_initiator_socket .h" # include " tlm_utils / peq_with_cb_and_phase .h "
8
9
10
11
12
13
14
15
16
SC_MODULE ( Initiator ) { // TLM-2 socket - p°es který probíhá komunikace tlm_utils :: simple_initiator_socket < Initiator > socket ; // posílaná data int data ; // aktualní transakce tlm :: tlm_generic_payload * request_in_progress ;
70
KAPITOLA 4.
TLM MODELY
// detekce ukon£ení první fáze transakce - REQUEST
17
sc_event end_request_event ;
18
// fronta p°íchozích volání nb_transport
19
tlm_utils :: peq_with_cb_and_phase < Initiator > m_peq ;
20
21
void thread_process ();
22
// deklarace obsluºné metody p°íchozí nb_transport metody
23
tlm :: tlm_sync_enum nb_transport_bw ( tlm :: tlm_generic_payload &
24
trans , tlm :: tlm_phase & phase , sc_time & delay );
25
// metoda pro obsluhu fronty údálostí
26
void peq_cb ( tlm :: tlm_generic_payload & trans ,
27
const tlm :: tlm_phase & phase );
28
// metoda volaná ke kontrole po provedení fáze BEGIN_RESP
29
void check_transaction ( tlm :: tlm_generic_payload & trans );
30
31
SC_CTOR ( Initiator )
32
: socket ( " socket ")
33
, request_in_progress (0)
34
, m_peq ( this , & Initiator :: peq_cb ) {
35
// registrace metody pro zp¥tné volání
36
socket . register_nb_transport_bw ( this ,
37
& Initiator :: nb_transport_bw );
38
39
SC_THREAD ( thread_process );
40
}
41
42
43
}; # endif
Na za£átku jsou jiº tradi£n¥ pouºity direktivy pro preprocesor za nimiº následuje vloºení nezbytných hlavi£ek. Oproti p°íkladu loosely-timed modelu uvedeném v sekci 4.2 zde p°ibyla hlavi£ka souboru vytvá°ející frontu událostí. Klí£ovým slovem
SC_MODULE
je ozna£en za-
4.4.
71
APPROXIMATELY-TIMED MODEL
£átek t¥la modulu. V n¥m jsou postupn¥ vytvá°eny objekty, které bude zdrojový modul vyuºívat. Konkrétn¥ se jedná o komunika£ní socket, prom¥nnou pro data, ukazatel na aktuální transak£ní objekt, pomocný objekt události a jako poslední je deklarována fronta událostí. Dále následují hlavi£ky £ty° metod jiº d°íve zmín¥ných na obrázku 4.4. Jejich úlohu jsem se snaºil oz°ejmit v komentá°ích ve výpisu kódu a je také nazna£ena na obrázku 4.6, kde je ke kaºdé fázi transakce p°i°azena metoda, která se stará o p°echod k dal²í fázi. Na obrázku 4.7 je nazna£en vývojový diagram obsluºné metody
peq_cb
zdrojového modulu,
která rozhoduje o pr·b¥hu komunika£ného protokolu na stran¥ zdrojového modulu.
Obrázek 4.7: Vývojový diagram metody
peq_cb()
zdrojového modulu
4.4.2 Cílový modul Sou£ástí cílového modulu jsou £ty°i metody jak je nazna£eno na obrázku 4.4. Výpis 4.12 je výpisem hlavi£kového souboru cílového modulu.
72
KAPITOLA 4.
TLM MODELY
Listing 4.12: Hlavi£kový soubor bloku Target (approximately-timed model)
1
2
3
# ifndef TARGET_H # define TARGET_H # define SIZE 512
4
5
6
7
8
# include " systemc " # include " tlm .h " # include " tlm_utils / simple_target_socket .h" # include " tlm_utils / peq_with_cb_and_phase .h "
9
10
DECLARE_EXTENDED_PHASE ( internal_ph ); // p°idaní fáze protokolu
11
12
13
14
15
16
17
18
19
SC_MODULE ( Target ) { // TLM-2 socket - p°es který probíhá komunikace tlm_utils :: simple_target_socket < Target > socket ; // vytvo°ení místa pro pam¥´ int mem [ SIZE ]; // fronta p°íchozích volání nb_transport tlm_utils :: peq_with_cb_and_phase < Target > m_peq ;
20
21
22
23
// deklarace metody pro obsluhu volaní transportní metody tlm :: tlm_sync_enum nb_transport_fw ( tlm :: tlm_generic_payload & trans , tlm :: tlm_phase & phase , sc_time & delay );
24
25
26
27
28
29
// metoda pro obsluhu fronty údálostí void peq_cb ( tlm :: tlm_generic_payload & trans , const tlm :: tlm_phase & phase ); // metoda posílá ukon£ení (p°ijeti) ºádosti zdrojovému modulu tlm :: tlm_sync_enum send_end_req ( tlm_generic_payload & trans );
4.4.
73
APPROXIMATELY-TIMED MODEL
// metoda zahajuje odpov¥¤ a posílá data
30
void send_response ( tlm :: tlm_generic_payload & trans );
31
32
SC_CTOR ( Target )
33
: socket ( " socket ")
34
, m_peq ( this , & Target :: peq_cb ) {
35
// registrace metody pro obsluhu p°íchozích transakcí
36
socket . register_nb_transport_fw ( this ,
37
& Target :: nb_transport_fw );
38
// Inicializace pam¥ti cílového modulu do definovaného stavu
39
for ( int i = 0; i < SIZE ; i ++) {
40
mem [i ] = 0 xAA000000 + i ;
41
}
42
}
43
44
45
}; # endif
Na °ádku 10 je pomocí klí£ového slova
DECLARE_EXTENDED_PHASE
roz²i°ující fáze základního protokolu pojmenovaná jako
de nována
internal_ph. Tato fáze je vyzna£ena
na obrázku 4.6 jako prost°ední z celkem p¥ti fází transakce na stran¥ cílového modulu. V rámci této fáze je provedena operace £tení nebo zápisu. Fáze
internal_ph
v rámci cílového modulu a není p°i ní volána transak£ní funkce
je de nována jen
nb_transport, coº znamená,
ºe se jedná o interní fázi cílového modulu. V t¥le modulu je dále de nován komunika£ní socket, místo pro datové poloºky a fronta p°íchozích transak£ních volání. Za nimi následují hlavi£ky obsluºných metod modulu. V konstruktoru je jiº jen zaregistrována obsluºná metoda p°íchozího volání a obsah pam¥ti je inicializován na p°edde novanou hodnotu.
Výpis jednotlivých metod je pom¥rn¥ obsáhlý, proto zde uvedu pouze dv¥ ve výpisu 4.13 a 4.14. Ob¥ tyto metody zaji²´ují p°echody mezi fázemi transakce. Metoda pak obsluhuje p°íchozí neblokující volání a metoda
nb_transport_fw()
peq_cb() °ídí pr·b¥h transakce, její funkce
je zobrazena ve vývojovém diagramu na obrázku 4.8.
74
1
KAPITOLA 4.
Listing 4.13: De nice metody
send_end_req()
TLM MODELY
(approximately-timed model)
tlm_sync_enum Target :: send_end_req ( tlm_generic_payload & trans ) { tlm :: tlm_phase bw_phase = tlm :: END_REQ ; // nastav konec ºádosti
2
sc_time delay = sc_time (2000 , SC_PS ); // nastavení zpoºd¥ní
3
// volání metody nb_transport - p°echod do fáze end request
4
tlm :: tlm_sync_enum status = socket - > nb_transport_bw ( trans ,
5
bw_phase , delay );
6
// nastavení následující fáze
7
tlm :: tlm_phase int_phase = internal_ph ;
8
// vloºení do fronty událostí pro provedení vnit°ní fáze
9
m_peq . notify ( trans , int_phase , delay );
10
11
return status ;
12
13
}
1
Listing 4.14: De nice metody
send_response()
(approximately-timed model)
void Target :: send_response ( tlm :: tlm_generic_payload & trans ) { tlm :: tlm_phase bw_phase = tlm :: BEGIN_RESP ; // nastav fázi
2
sc_time delay = sc_time (3000 , SC_PS ); // specifikace spoºd¥ní
3
// volání metody nb_transport - p°echod do fáze begin response
4
socket -> nb_transport_bw ( trans , bw_phase , delay );
5
6
}
Metoda
peq_cb()
je volána vºdy po uvoln¥ní transakce z fronty
m_peq. Na základ¥ toho
v jaké fázi se transakce nachází je provedena akce. Z obrázku 4.8 je tedy vid¥t ºe pokud je transakce aktuáln¥ ve fázi zavolána metoda
BEGIN_REQ
(zdrojový modul poprvé volá cílový modul), je
send_end_req(trans), která zajistí akceptování p°íchozího volání a p°echod
do dal²í fáze po de novaném spoºd¥ní. Naproti tomu fáze
END_RESP
je jiº poslední v rámci
transakce a proto je zde jiº pouze nutné po transakci ukon£it platnost transportního objektu. Dv¥ fáze
END_REQ
a
BEGIN_RESP, pokud by jí funkce zpracovávala, vyvolají chybu. To
z d·vodu, ºe ob¥ mají být zpracovány zdrojovým modulem (viz. obrázek 4.6) a tudíº není
4.4.
75
APPROXIMATELY-TIMED MODEL
Obrázek 4.8: Vývojový diagram metody
peq_cb()
cílového modulu
p°ípustné tuto fázi zpracovat zde v cílovém modulu. Poslední fází v diagramu (ne v²ak podle po°adí v protokolu) je fáze
internal_ph.
V ní jsou provedeny kopírovací operace a výpis na
standardní výpis spolu s p°echodem do dal²í fáze.
4.4.3 Shrnutí Propojení modul· je ekvivalentní s p°íkladem uvedeném v sekci 4.2.3, a proto zde na tuto sekci odkazuji. V¥t²ina výpis· je z d·vodu p°ehlednosti zkrácena a proto p°i p°ípadných nejasnostech doporu£uji projít kompletní zdrojové kódy na p°iloºeném CD. V p°íkladu je ukázáno podrobn¥j²í modelování transakcí pomocí p°ístupu pouºívaných v
76
KAPITOLA 4.
TLM MODELY
approximately-timed modelech. Samotná operace £tení a zápisu je zde provedena v p°idané vnit°ní fázi
internal_ph,
zatímco ostatní fáze nejsou vyuºity pro samotné provedení oper-
ace, ale slouºí jako standardní model komunika£ního protokolu. To samoz°ejm¥ z hlediska prakti£nosti pouºití nemusí být optimální, ale jako ilustrace jak approximately-timed modely fungují se mi tato volba jevila jako vhodná.
Kapitola 5 Up°es¬ování modelu
Moºnost up°es¬ování model· je jednou z klí£ových vlastností knihovny SystemC. Jedná se o moºnost nejprve namodelovat funk£nost navrhovaných blok· systému obecn¥ji pomocí vy²²ího programovacího jazyka
C/C + +,
kde lze výpo£etní operace provád¥t oby£ejným al-
goritmickým zápisem. Dále jsou do t¥chto funk£ních blok· zakomponovány £asové závislosti a komunika£ní rozhraní z knihovny SystemC. Tento p°ístup p°iná²í °adu výhod. Jednou z nich je krat²í doba nutná pro vývoj výpo£etních blok· v ranné £ásti vývoje. Není nutné se zabývat podrobným návrhem syntetizovatelných funk£ních blok·, ale sta£í tyto bloky navrhnout na vy²²í úrovni abstrakce. Poté doladit celý systém a následný p°evod do syntetizovatelné podoby m·ºe být proveden aº v dal²í fázi vývoje. S tím také souvisí moºnost znovu pouºít testovací programy pro vy²²í úrove¬ abstrakce v syntetizovatelných modelech a tím veri kovat funk£nost. V této kapitole bude nejprve obecn¥ uveden princip a doporu£ený postup zjem¬ování model· tzv. re ning. Následn¥ bude tento princip ilustrován na p°íkladu.
5.1 Postup up°es¬ování Princip up°es¬ování spo£ívá ve vytvo°ení výpo£etních model· na vy²²ích úrovních abstrakce a následném zp°es¬ování aº na úrove¬ syntetizovatelných model·. Tento princip si lze nap°íklad p°edstavit na výpo£etním bloku aritmeticko-logické jednotky, která krom¥ základních operací s£ítání, od£ítaní, d¥lení a násobení podporuje i sloºit¥j²í operace jako m·ºe být
77
78
KAPITOLA 5.
UPESOVÁNÍ MODELU
nap°íklad výpo£et kontrolních sou£t· CRC nebo r·zných pomocných hodnot pro ²ifrovací operace (nap°. multiplikativní modulární inverzi atd.). Jist¥ je z°ejmé, ºe pomocí knihovny SystemC (spolu s
C + +)
je jednodu²²í a hlavn¥ rychlej²í namodelovat jednotku, která
jako vstup dostane vstupní hodnoty a symbol operace. Tato jednotka následn¥ algoritmicky provede výpo£et (se£tení, výpo£et modulární inverze,
. . .) a tento výsledek zapí²e na výstup.
V tomto p°ípad¥ se jedná v podstat¥ o funk£ní model jednotky bez ohledu na její implementaci, který nám dále m·ºe slouºit jako referen£ní pro dal²í krok a na kterém je moºné otestovat funk£nost i komunikaci s ostatními bloky systému. Dal²ím krokem bude zjemn¥ní modelu na takovou úrove¬ aby bylo moºné model syntetizovat p°ípadn¥ provést dal²í analýzu.
Obrázek 5.1: P°echod z vy²²í úrovn¥ abstrakce na niº²í
Obecný postup zjem¬ování modelu lze shrnout do t¥chto bod·:
1. Speci kace funk£ního modelu a de nování rozhraní na úrovni TLM a jeho veri kace.
2. Vytvo°ení adapter·.
(a) Pomocí samostatných blok·. (b) Pomocí proces· p°idruºených do jiného bloku.
3. Vytvo°ení RTL modelu, jeho náhrada za TLM model a veri kace funkce.
Vºdy je nutné si na za£átku návrhu uv¥domit rozsah modelovaného bloku. Není totiº vhodné modelovat p°íli² sloºité obvody, které v algoritmickém zápisu sice lze modelovat rel-
5.1.
POSTUP UPESOVÁNÍ
79
ativn¥ jednodu²e, ale pro hardwarový výpo£et by p°edpokládaný model byl p°íli² rozsáhlý. Takovéto moduly je doporu£eno dekomponovat na díl£í moduly a ty pak modelovat samostatn¥. Prvním bodem je tedy speci kace funkce modelu spolu s de nicí komunika£ního rozhraní jak mezimodulové komunikace, tak rozhraní pro vstup testovacích vektor·. Jedním z p°ínos· tohoto p°ístupu je moºnost vyuºít stejné testovací programy de nované pro model na vy²²í úrovni abstrakce pro detailn¥j²í modely. To sebou samoz°ejm¥ nese nutnost p°izp·sobit komunikaci v závislosti na tom, jaký model je práv¥ v návrhu pouºit. K tomuto p°izp·sobení slouºí takzvané adaptéry. Funkce adaptér· je jednoduchá transformovat abstraktní operace (transakce) na hodnoty signál· (pro RTL model) a naopak (pro modul Monitor). V zásad¥ lze uvaºovat tyto dv¥ varianty:
1. Pouºít adaptéry aº v RTL modelu, tzn. nechat jejich implementaci aº pro zjemn¥ný model (
doporu£eno).
2. Pouºít adaptéry jiº v TLM modelu u blok· Generator a Monitor.
Blokový diagram podle bodu jedna je na obrázku 5.2. D·vodem pro£ je tento p°ístup doporu£ený je skute£nost, ºe není nutné zasahovat do jiº vytvo°eného testovacího modulu pro TLM model. Naproti tomu na obrázku 5.3 je blokový diagram druhého zp·sobu realizace, kdy jsou adaptéry sou£ástí generátoru (monitoru). Zde jsou adaptéry p°idány do testovacích blok· a propojení modul· je realizováno jiº na úrovni signál·.
Obrázek 5.2: Blokové schéma modelu s adaptéry v RTL modelu
V po°adí druhým krokem je samotná implementace komunika£ních adapter·. Adaptérem m·ºe být samostatný modul p°ípadn¥ proces uvnit° modulu. Samotná funk£nost se nebude
80
KAPITOLA 5.
UPESOVÁNÍ MODELU
Obrázek 5.3: Blokové schéma modelu s adaptéry v TLM modelu
m¥nit v závislosti na výb¥ru implementa£ní varianty. Jediným aspektem, který se bude li²it je implementované rozhraní propojující jednotlivé bloky. Po implementaci adaptér· jiº nic nebrání propojení vytvo°eného RTL modelu s testovacími moduly a tím veri kovat funk£nost modulu za pouºití d°íve vytvo°ených testovacích program·.
5.2 P°íklad p°echodu mezi modely P°íklad pouºití na kterém bude ilustrován proces up°es¬ování modelu bude ur£it¥ mnohem p°ínosn¥j²í neº dlouhý vý£et v²ech variant implementace adaptér· a dal²ích detail· p°echodu z jednoho model· na druhý. Pro praktickou ilustraci postupu zjem¬ování modelu jsem si zde pro jednoduchost a srozumitelnost zvolil aritmeticko-logickou jednotku podporující v základní variant¥ pouze operaci s£ítání.
5.2.1 TLM model 5.2.1.1 Výpo£etní modul Model na úrovni TLM bude v tomto p°ípad¥ velice jednoduchý. Jedná se totiº pouze o modul, který na sv·j vstup dostane dv¥ celo£íselné hodnoty, které se£te a výsledek umístí na svém výstupu. Sou£ástí testovacího programu jsou dva moduly slouºící pro generování resp. £tení stimul·. Prvním z nich je
Monitor,
Generator, který vytvá°í testovací vstupy, druhým pak
který zpracovává a ov¥°uje výstup testovaného modulu. K propojení jednotlivých
blok· jsou pouºity dva primitivní kanály
sc_ fo.
Do první fronty se vkládají objekty t°ídy
5.2.
81
PÍKLAD PECHODU MEZI MODELY
InputData,
která obsahuje jako datové poloºky dva operandy a p°íznak provád¥né operace.
Druhá fronta je pln¥na jiº výslednými hodnotami typu jsou obaleny hlavním modulem
integer. V²echny tyto zmi¬ované bloky
Testbench, který se stará o propojení a instalaci jednotlivých
blok·. Schéma uspo°ádání blok· je na obrázku 5.4.
Obrázek 5.4: Schéma vzorového TLM modelu
Testovaný modul uprost°ed schématu ozna£ený jako primitivního kanálu
Full_adder_TLM
sc_ fo. Identi kátor InputData
p°ijímá vstup od
ur£uje datový typ vstupu
modulu. Jde o uºivatelsky de novanou t°ídu obsahující dva vstupní operandy a p°íznak operace. Výstupní kanál
sc_ fo poskytuje modulu Monitor
rozhraní a struktura bloku
Full_adder_TLM
výsledky operací. Detailn¥ji je
zobrazena na obrázku 5.5 ze kterého je patrné,
ºe modul obsahuje pouze jedinou metodu provád¥jící výpo£et.
Obrázek 5.5: Schéma bloku
Full_adder_TLM
Hlavi£kový soubor výpo£etního modulu je v následujícím výpisu 5.1, implementace pak ve výpisu 5.2.
82
KAPITOLA 5.
Listing 5.1: Hlavi£kový soubor TLM modelu
1
2
3
4
5
6
UPESOVÁNÍ MODELU
# ifndef FULL_ADDER_TLM_H # define FULL_ADDER_TLM_H # include " systemc . h" # include " InputData .h " SC_MODULE ( Full_adder_TLM ) { public : sc_port < sc_fifo_in_if < InputData > > in ; // vstupní fronta modulu
7
sc_port < sc_fifo_out_if < int > > out ; // výstupní fronta modulu
8
9
void doCount (); // metoda popisující chování modulu
10
11
SC_CTOR ( Full_adder_TLM ) { // konstruktor modulu
12
SC_THREAD ( doCount ); // registrace metody jako procesu
13
}
14
15
16
}; # endif
Listing 5.2: Implementa£ní soubor TLM modelu
1
2
3
4
5
# include " Full_adder_TLM . h" # include " InputData .h " void Full_adder_TLM :: doCount () { InputData temp_InDa ; // deklarace objektu vstupních hodnot int temp = 0;
6
7
8
9
10
while ( true ) { temp_InDa = in -> read (); // £tení vstup· z fronty if ( temp_InDa . getOperation == 0) { // operace s£ítání temp = temp_InDa . getFirstOperand () + temp_InDa . getSecondOperand (); // sou£et obou operand·
11
12
}
5.2.
else if ( temp_InDa . getOperation ... // test na dal²í operace . . .
13
14
out -> write ( temp ); // zápis p°es výstupní port do fronty
15
}
16
17
83
PÍKLAD PECHODU MEZI MODELY
}
Metoda
doCount()
je v hlavi£kovém souboru de nována jako metoda typu
SC_THREAD,
coº zajistí její provedení po inicializi a po zm¥n¥ n¥kterého vstupu (p°idání do vstupní fronty). V t¥le je totiº nekone£ná smy£ka, která umoºní neustálé p°ijímání dat ze vstupního kanálu. Protoºe je ve výpisu 5.2 na °ádku 8 pouºita metoda vstupního
fo
kanálu, jeº je blokovací,
je zaji²t¥no ºe nebude nekone£ná smy£ka probíhat stále, ale pouze pokud bude moºné £íst ze vstupní fronty (bude obsahovat data). V t¥le cyklu jsou pak jen se£teny vstupní operandy na úrovni celo£íselných hodnot a výsledek je zapsán do výstupního kanálu.
5.2.1.2 Blok Generator Blok
Generator
vytvá°í testovanému bloku posloupnost vstupních transakcí v£etn¥ opera£-
ního znaku. Tato sada generovaných výstup· bloku
Generator
není závislá na tom jaký blok
je aktuáln¥ testován. To znamená, ºe není nutné pozm¥¬ovat jeho chování p°i zm¥n¥ testovaného bloku. Blok obsahuje pouze jedinou metodu generující vstupy pro testovaný obvod. Její de nice je ve výpisu 5.3.
1
2
3
4
5
6
7
8
9
Listing 5.3: T¥lo metody pro generování vstup· pro testovaný modul
void Generator :: gen_func () { int op = 0; // typ operace pro s£ítání for ( int i = 0; i < 256; i ++) { for ( int j = 0; j < 256; j ++) { // zápis do výstupního kanálu typu fronta out -> write ( InputData (i , j , op )); // výstup hodnoty operand· na standartní výstup cout << sc_time_stamp () << ": " << i << " + " << j; wait (1 , SC_NS );
84
KAPITOLA 5.
}
10
}
11
12
UPESOVÁNÍ MODELU
}
Metoda provadí ve dvou vno°ených
InputData
T°ída
for
cyklech generování vstupní dvojice operand·.
obsahuje jako £lenskou prom¥nnou krom¥ dvou celo£íselných operand·
je²t¥ p°íznak operace pro pozd¥j²í moºnost roz²í°ení jednotky. Hodnota
0
byla zde zvolena
jako p°íznak s£ítání a je proto na za£átku funkce nastavena. Jako £asový rozestup mezi jednotlivými vstupy byl zde napevno de nován £ekací interval na hodnotu 1 ns pomocí funkce
wait(1, SC_NS).
5.2.1.3 Blok Monitor Na výstup testovaného bloku je p°ipojen blok nazvaný
Monitor.
Jeho ú£elem je sledovat
odezvu testovaného bloku. Tato odezva TLM modelu je bu¤ p°ímo porovnána s výstupem RTL modelu nebo m·ºe být zaznamenána a porovnání provedeno pozd¥ji. Zde je pouºit druhý p°ístup. Tedy uloºení a pozd¥j²í porovnání. V praxi to znamená nejprve provést simulaci s TLM modelem, kde budou referen£ní odezvy zapsány do souboru. Následn¥ bude TLM model nahrazen RTL modelem, který své odezvy stejným zp·sobem zapí²e do výstupního souboru. Posledním krokem je porovnání t¥chto dvou soubor·. tedy tohoto práv¥ získaného s referen£ním. P°ípadné rozdíly budou nahlá²eny jako chyba výstupu. Blok jako
1
2
3
4
5
6
7
8
Generator
Monitor
stejn¥
obsahuje jedinou metodu. Její zkrácená verze de nice je ve výpisu 5.4.
Listing 5.4: T¥lo metody pro sledování odezvy testovaného modulu
void Monitor :: mon_func () { outputFile . open (" outputFile . dat " ); int temp = 0; // aktuální výsledek int temp_prev = 0; // p°edchozí výsledek sc_time prev = sc_time ( -1 , SC_NS ); // p°edchozí £as sc_time curr = sc_time (0 , SC_NS ); // aktuální £as while ( true ) { in -> read ( temp ); // £tení výsledku testovaného obvodu
5.2.
curr = sc_time_stamp (); // získání aktuálního simula£ního £asu
9
if ( curr != prev )
10
outputFile << temp_prev << endl ; // zápis do souboru
11
prev = curr ;
12
temp_prev = temp ;
13
cout << " = " << temp << endl ; // výpis výsledku
14
}
15
16
85
PÍKLAD PECHODU MEZI MODELY
}
Funkce
mon_func()
bloku
Monitor
je de nována jako proces typu
SC_THREAD.
B¥ºí
tedy po celou dobu simulace a je vºdy uspána v p°ípad¥, ºe vstupní fo neobsahuje ºádná data. Jinak na£ítá vstup a zapisuje ho do souboru. V inicializa£ní fázi funkce otev°e soubor pro ukládání výsledk· a vytvo°í prom¥nné pro uloºení aktuální a p°edchozí hodnoty simula£ního £asu a výsledku. Zbytek metody je v nekone£né smy£ce
while
ze vstupního kanálu
fo
ve které je nejprve pomocí blokující metody
read
p°e£tena hodnota
a následn¥ získán aktuální simula£ní £as. Dále je zapsána p°edchozí
hodnota výsledku do výstupního souboru výsledk·, ale pouze v p°ípad¥ ºe p°edchozí simula£ní £as se li²í od aktuálního. Tento v podstat¥ opoºd¥ný zápis je nutné aplikovat z d·vodu, ºe po nahrazení TLM modelu zjemn¥ným modelem jsou generovány na výstupu v²echny odezvy v£etn¥ t¥ch zp·sobených tzv. delta cykly. Z tohoto d·vodu je jako platná hodnota vºdy vyhodnocena hodnota poslední p°ed zm¥nou simula£ního £asu, která je také zapsána do souboru výsledk·. Poslední t°i °ádky metody pak aktualizují prom¥nné £asu i výsledku a provedou zápis na standardní výstup.
5.2.2 Zjemn¥ný (up°esn¥ný) model P°i detailn¥j²í de nici modelu je zapot°ebí postupovat v duchu up°es¬ujících zm¥n pouze u testovaného modulu. Bloky
Generator i Monitor
budou ponechány beze zm¥ny. Na obrázku
5.6 je vid¥t schéma zápojení jednotlivých blok·. Jediným rozdílem oproti d°íve uvedenému schématu na obrázku 5.4 je zám¥na bloku
Full_adder_TLM
za blok
Full_adder_wrapper.
Zjemn¥ný modul s£íta£ky komunikuje p°es stejné rozhraní jako její p°edchozí TLM model
86
KAPITOLA 5.
UPESOVÁNÍ MODELU
Obrázek 5.6: Schéma vzorového RTL modelu
a proto je jeho náhrada v zapojení otázkou zm¥ny jediného °ádku ve zdrojovém kódu bloku
Testbench.
P°ivád¥né testovací vstupy pomocí kanálu
sc_ fo
je v²ak samoz°ejm¥ nutné za
pomocí adaptér· p°evést na jednotlivé signály s kterými bude dále RTL model pracovat. Adaptéry jsou v tomto p°ípad¥ sou£ástí zjemn¥ného modelu. Konkrétn¥ se jedná o dva procesy
generator_prc()
a
monitor_prc(). První p°evádí celo£íselné vstupy do binární podoby,
druhý analogicky provádí zp¥tný p°evod na výstupu. Schématický obsah propojení bloku
Full_adder_wrapper
je na obrázku 5.7.
Obrázek 5.7: Schéma bloku
Full_adder_wrapper
Krom¥ zmín¥ných adaptér· je sou£ástí bloku také dal²í hierarchický modul, který p°edstavuje samotný RTL model
n-bitové
s£íta£ky. Zde je konkrétn¥ sestavena z
n
úplných s£í-
ta£ek, které jsou dále skládány ze s£íta£ek polovi£ních. Rozsah vstupních celo£íselných hodnot je samoz°ejm¥ nutné p°izp·sobit ²í°ce s£íta£ky. Její ²í°ka je ur£ena konstantou
WIDTH
5.2.
v souboru a
87
PÍKLAD PECHODU MEZI MODELY
constants.h.
W IDT H ∈ N.
Její hodnota musí odpovídat vztahu
Prom¥nná
X
W IDT H > log2 X ,
kde
X∈N
reprezentuje hodnotu obou vstupních operand·. Hlavi£kový
soubor tohoto modelu je ve výpisu 5.5.
Listing 5.5: Hlavi£kový soubor RTL modelu
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SC_MODULE ( Full_adder_wrapper ) { protected : // deklarace vstup· a výstup· sc_signal < bool > a_sig [ WIDTH ], b_sig [ WIDTH ], cin_sig ; sc_signal < bool > sum_sig [ WIDTH ], carry_out_sig ; n_bit_adder * uut_ptr ; // deklarace ukazatele na n-bitovou s£íta£ku void generator_prc (); void monitor_prc (); public : sc_port < sc_fifo_in_if < InputData > > in ; // deklarace vstup. portu sc_port < sc_fifo_out_if < int > > out ; // deklarace výstupního portu SC_CTOR ( Full_adder_wrapper ) { uut_ptr = new n_bit_adder (" uut " ); // vytvo°ení ALU SC_METHOD ( monitor_prc ); //reg. metody jako paralelního procesu for ( int i = 0; i < WIDTH ; i ++) { sensitive << sum_sig [i ];
16
17
18
} sensitive << carry_out_sig ;
19
20
SC_THREAD ( generator_prc ); //reg. metody jako paralel. procesu
21
22
for ( int i = 0; i < WIDTH ; i ++) { // propojení v²ech signál· uut_ptr ->a[ i ]( a_sig [ i ]);
23
uut_ptr ->b[ i ]( b_sig [ i ]);
24
uut_ptr -> sum [i ]( sum_sig [i ]);
25
26
}
88
KAPITOLA 5.
uut_ptr -> carry_in ( cin_sig );
27
uut_ptr -> carry_out ( carry_out_sig );
28
}
29
~ Full_adder_wrapper () { // destruktor
30
delete uut_ptr ;
31
}
32
33
UPESOVÁNÍ MODELU
};
V modulu jsou nejprve vytvo°eny v²echny pot°ebné instance propojovacích signál· a
ukazatel na instanci s£íta£ky a samoz°ejm¥ i rozhraní ke kterým je moºné p°ipojit vstupní a výstupní
fo
kanály. Dále jsou uvedeny hlavi£ky funkcí adaptér·
generator_prc()
a
monitor_prc(). V konstruktoru je jako první instalována instance s£íta£ky, následuje zaregistrování metod adapter· jako procesy. Metoda
monitor_prc()
je typu
SC_METHOD,
coº
jí umoº¬uje zaregistrovat signály do citlivostního seznamu na jejichº zm¥nu bude proces reagovat svým spu²t¥ním. Tato registrace je provedena pomocí klí£ového slova Metoda
sensitive.
generator_prc() je také zaregistrována jako paralelní proces, tentokrát ale jako typu
SC_THREAD.
V záv¥ru konstruktoru je pak je²t¥ provedeno mapování signál· modulu na
instanci úplné s£íta£ky. Hlavi£kový soubor kon£í uvedením destruktoru, který ru²í platnost aktuální instance
1
2
3
4
5
6
7
8
9
10
n_bit_adder. T¥la metod adaptér· jsou uvedena ve výpisech 5.6 a 5.7. Listing 5.6: T¥lo metody adaptéru
generator_prc()
void Full_adder_wrapper :: generator_prc () { InputData temp_InDa ; // deklarace vstupního objektu sc_uint < WIDTH > firstOperand = 0; // bitová reprezentace 1. op. sc_uint < WIDTH > secondOperand = 0; // bitová reprezentace 2. op. while ( true ) { // blokující £tení ze vstupní fronty temp_InDa = in -> read (); // získání obou operand· a následná konverze na bit. vektor firstOperand = temp_InDa . getFirstOperand (); secondOperand = temp_InDa . getSecondOperand ();
5.3.
//propojení bitové hodnoty vstup· na jednotlivé bity RTL modelu ALU
11
for ( int i = 0; i < WIDTH ; i ++) {
12
a_sig [i ] = firstOperand [ i ];
13
b_sig [i ] = secondOperand [i ];
14
}
15
cin_sig = false ;
16
}
17
18
89
SHRNUTÍ
}
Listing 5.7: T¥lo metody adaptéru
1
void Full_adder_wrapper :: monitor_prc () { sc_uint < WIDTH + 1 > sum = 0;
2
for ( int i = 0; i < WIDTH ; i ++) {
3
sum [i ] = sum_sig [i ];
4
}
5
sum [ WIDTH ] = carry_out_sig ;
6
out -> write ( sum ); // zápis výsledku do fronty
7
8
monitor_prc()
}
Princip p°evodu celo£íselné hodnoty na vektor signál· a naopak je u obou metod shodný.
Je vytvo°ena pomocná (pomocné) prom¥nné
sc_uint. Jedná se roz²i°ující datový typ kladné
celo£íselné hodnoty o de nované ²í°ce (viz. tabulka 2.2). Tento typ umoº¬uje p°ímou konverzi se standardním typem
sc_uint
int £ehoº je zde vyuºito a je nejprve typ int p°i°azen do prom¥nné typu
a následn¥ po jednotlivých bitech je hodnota p°evedena do formy signál· spojených
jiº s testovaným modulem. P°esn¥ opa£ný princip je proveden v metod¥
monitor_prc().
5.3 Shrnutí V této kapitole byl zmín¥n princip up°es¬ování modelu. Zmín¥né postupy jsou doporu£ením [2, 5], kterých samoz°ejm¥ není nutné se za v²ech okolností p°esn¥ drºet, ale jejich dodrºení p°iná²í mnoho výhod a pomáhá p°i nahrazování p·vodního modelu modelem zp°esn¥ným.
90
KAPITOLA 5.
UPESOVÁNÍ MODELU
Hlavní výhodou je rychlý vývoj model· na úrovni TLM oproti RTL model·m. TLM modely jsou také díky speci kaci mén¥ detail· rychleji simulovatelné. V neposlední °ad¥ je nutné uvést, ºe obvykle TLM model slouºí jako referen£ní model jehoº výstup veri kuje funk£nost zjemn¥ného modelu. Pro ilustraci byl vybrán jednoduchý p°íklad ne snad z d·vodu, ºe by byl tím nejlep²ím kandidátem pro tento postup, ale práv¥ pro jeho jednoduchost. Jednotlivé kroky jsou proto více srozumitelné a p°iloºený kód není zbyte£n¥ obsáhlý. I p°es snahu zahrnout do textu co nejvíce ze zdrojových kód· jsou zde uvedené kódy zkráceny s d·razem na srozumitelnost. Kompletní p°íklad je sou£ástí p°iloºeného CD.
Kapitola 6 Podpora TL modelování v ostatních HDL jazycích
V p°edchozích kapitolách byla zmín¥na motivace a vysv¥tleny principy návrhu model· na úrovni TLM. V této kapitole se pokusím ve stru£nosti zmínit jak na tom jsou s podporou
1 ostatní jazyky zam¥°ené na modelování hardwaru. Za-
návrh· na vy²²í úrovni abstrakce
m¥°ím se zejména na nejroz²í°en¥j²í jazyky VHDL a Verilog.
6.1 VHDL Prvním jazykem který bude vhodné zmínit je jazyk VHDL. Stru£ná zmínka o VHDL v£etn¥ nastín¥ní n¥kterých odli²ností byla uvedena jiº v kapitole 2.
6.1.1 Stru£ná historie V tabulce 6.1 jsou uvedeny vydané verze standardu jazyka. Samotný jazyk VHDL ve své p·vodní speci kaci vychází z jazyku Ada ze kterého do jisté míry p°ebíral syntaxi i dal²í vlastnosti jako je nap°íklad silná typová kontrola. Od první verze vydané v roce 1987 bylo VHDL plnohodným jazykem pro modelování hardware. Druhé revidování standardu v roce 1
Vy²²í úrovní abstrakce jsou v tomto kontextu my²leny úrovn¥ abstraktních model· vy²²ích neº je úrove¬
RTL.
91
92
KAPITOLA 6.
PODPORA TL MODELOVÁNÍ V OSTATNÍCH HDL JAZYCÍCH
1994 vylep²ovalo pouºitelnost zejména v práci s logickými operátory a uleh£ovalo konverzi mezi datovými typy. Dal²í dv¥ vydání v roce 2000 a 2002 p°iná²ejí jen drobné zm¥ny. Asi nejv¥t²í bylo zavedení takzvaných
protected
prom¥nných, které umoºnily vymezit funk£nost
takto ozna£ené prom¥nné pro zvolenné procesy. Tato zm¥na m¥la p°inést p°iblíºení se konceptu t°íd v objektov¥ orientovaných jazycích [30]. Poslední standard je nazván VHDL 2008, p°ina²í více jak 90 vylep²ení. T¥mi nejzásadn¥j²ími je moºnost zápisu signál· pomocí hierarchických jmen pro simulaci £i p°idání podpory pro veri kaci v podob¥
Language
Property Speci cation
(PSL). Jedná se roz²í°ení kontroly speci kace pomocí tzv. assertion výraz·, které
kontrolují odezvu obvodu a v p°ípad¥ nesrovnalostí oproti o£ekávanému chování jsou provedeny zvolené kroky. Dal²ím vylep²ením je roz²í°ení moºnosti pouºít generické parametry nejenom v rámci entit, ale i v subprogramech a package instancích. Tyto generické parametry nemusí jiº být pouze konstanty, ale m·ºe se jednat i o funkce nebo sloºené datové typy [16].
1987
publikován IEEE standard jazyka VHDL
1994
vydána verze VHDL 1076-1993
2000
vydána verze VHDL 1076 2000
2002
vydána verze VHDL 1076-2002
2009
vydána verze VHDL 1076-2008
Tabulka 6.1: Verze standardu jazyka VHDL [30]
6.1.2 Podpora TLM Z p°edchozí sekce, kde byla uvedena stru£ná historie jazyka lze vypozorovat ur£itou snahu o integraci princip· objektov¥ orientovaných jazyk·. A´ uº se jedná o p°idání podpory pro
protected
prom¥nné £i podporu hierarchických jmen signál·. Sou£asné moºnosti jazyka za-
tím nejsou vhodné pro vytvá°ení TLM model·. Je zde °ada moºností jak n¥které chyb¥jící konstrukty napodobit, ty ale sebou p°iná²í jiné problémy a v kone£ném d·sledku mohou návrh naopak zpomalit.
6.1.
93
VHDL
Budoucí vývoj bude krom¥ vylep²enení sou£asných moºností jazyka ur£it¥ sm¥°ovat i k vývoji takových konstrukt·, které budou umoº¬ovat rychlej²í vývoj komplexních model·. Toho ale bude moºné dosáhnout pouze pokud nebude stoupat sloºitost návrhu. Udrºet tuto sloºitost na rozumné úrovni by m¥lo být moºné pový²ením abstrakce z úrovn¥ RTL na transak£ní. Vývoj na transak£ní úrovni by zaji²´oval rychlý vývoj model· slouºící pro otestování speci kace a tvorb¥ vysokoúrov¬ových funk£ních veri kací. Po odlad¥ní v²ech sou£ástí systému by jiº mohly být bloky implementovány. Ideál by v tomto p°ípad¥ p°edstavovala p°ímá syntéza do hradel, která samoz°ejm¥ není triviální a vºdy bude naráºet na limity syntézních nástroj·. Pokud by tato moºnost p°ímé syntézy nebyla dostupná, stále by bylo moºné s výhodou znovu pouºít bu¤ d°íve vyvinuté IP bloky nebo tento vývoj provést následn¥ svépomocí. Tento krok v podob¥ roz²í°ení jazyka o moºnost popisu na TL úrove¬ je logický a s postupným rozvojem technologických moºností zárove¬ pravd¥podobn¥ nevyhnutelný. Navrhované roz²í°ení, které se jiº postupn¥ za£ínájí diskutovat [9] s ohledem k dal²ímu vydání standardu jazyka jsou:
podpora objektového návrhu
Objektov¥ orientovaný návrh je základem pro
komplexn¥j²í datové struktury a transak£ní zpracování. Jeho absence je hlavní brzdou roz²í°ení jazyka sm¥rem k TL úrovni.
podpora náhodných testovacích vektor· a funk£ního pokrytí test·
Pod-
pora náhodných testovacích vektor· je zejména vhodná v p°ípad¥ testování celého návrhu, kde je testovaný prostor p°íli² velký pro provedení kompletní simulace. Náhodné pokrytí spolu s logikou funk£ního pokrytí by pomohlo zvý²it spolehlivost návrhu.
podpora p°ímých volání ostatních jazyk· (C/C++, Verilog/SystemVerilog,
. . .)
P°ímo volané funkce vyvinuté v jiných jazycích by uleh£ily de nici funk£nosti
na TL úrovni. Bylo by moºné jednodu²e p°ebírat funk£ní celky a zakomponovat je do navrhovaných TL blok·.
Tyto nové vlastnosti by VHDL umoºnily vytvá°ení model· na TL úrovni. Zárove¬ by tyto kroky vedly k tomu, ºe z p·vodního HDL jazyka by se stal tzv. HDVL (Hardware Design
94
KAPITOLA 6.
PODPORA TL MODELOVÁNÍ V OSTATNÍCH HDL JAZYCÍCH
and Veri cation Language). To by m¥lo výrazn¥ pozitivní vliv pro uºivatele. Zejména z toho d·vodu, ºe by ve²kerý vývoj od p·vodní TL speci kace mohl být proveden v rámci jediného jazyka a nebylo by nutné (av²ak moºné), pro TL popis a veri kaci pouºívat jiné jazyky jako Vera, SystemC nebo SystemVerilog [9].
6.2 Verilog a SystemVerilog 6.2.1 Stru£ná historie
Historie jazyka Verilog sahá aº do první poloviny osmdesátých let minulého století. V té dob¥ se jednalo o první HDL jazyk. Verilog se snaºil syntaxí p°iblíºit ²iroce p°ijímanému jazyku C a zárove¬ zavést nové konstrukty typické pro hardwarový návrh. Prvotní ideou byl pouze návrh jazyka, který by slouºil pro simulaci. Aº následným vývojem byla p°idána podpora pro syntézu. Jako datum vzniku se sice úvádí rok 1984, ale od tohoto data aº do roku 1995 to byl jazyk bez otev°eného standardu. Toho se Verilog do£kal práv¥ v roce 1995 v podob¥ IEEE 1364-1995, který byl reakcí na vzestup popularity konkuren£ního VHDL. Dal²í dv¥ verze z roku 2001 a 2005 p°inesly vylep²ení zejména v oblasti usnadn¥ní aritmetických operací a vyjasn¥n¥ní n¥kterých speci kací jazyka. Zatím poslední verze z roku 2009 p°inesla sjednocení standardu Verilogu a SystemVerilogu pod jediný s ozna£ením IEEE 1800-2009 [29]. V tabulce 6.2 je shrnut stru£ný vývoj jednotlivých verzí jazyka Verilog.
1984
vytvo°ena první verze jazyka
1995
publikován IEEE standard jazyka Verilog 1364-1995 (Verilog-95)
2001
vydána verze Verilogu IEEE 1364-2001 (známa jako Verilog-2001)
2005
vydána verze Verilogu IEEE 1364-2005 (známa jako Verilog-2005)
2009
slou£eno se standardem SystemVerilog IEEE 1800-2009
Tabulka 6.2: Verze standardu jazyka Verilog/SystemVerilog [29]
6.2.
95
VERILOG A SYSTEMVERILOG
6.2.2 Podpora TLM Samotný Verilog je jiº od své poslední verze sou£ástí komplexn¥j²ího SystemVerilogu. Z tohoto d·vodu bude v této krátké zmínce o TL modelování brán v úvahu práv¥ SystemVerilog.
SystemVerilogu se jiº do ur£ité míry poda°ilo o co se pravd¥podobn¥ bude VHDL snaºit v budoucích verzích standardu (viz. sekce 6.1.2). A to integrovat pod jeden standard jak syntetizovatelnou podmnoºinu jazyka, tak zárove¬ vytvo°it komplexní nástroj pro veri kaci návrhu. P·vodní Verilog samoz°ejm¥ obsahoval moºnosti jak ov¥°it funk£nost návrhu (directed testbenches), SystemVerilog ale p°iná²í podstatné roz²í°ení jako jsou:
podpora objektov¥ orientovaného programování
je moºné vytvá°et t°ídy,
které podporují princip zapouzd°ení a £áste£n¥ i d¥di£nost.
podpora náhodn¥ generovaných testovacích vektor·
moºnost parametrizace
zvolených signál·, které na základ¥ de novaných omezení generují pseudonáhodné vektory.
podpora funk£ního pokrytí test· na základ¥ provedené simulace je moºné ur£it zda bylo pokryto dostate£né mnoºství vstupních stimul· nebo vnit°ních stav· automatu.
podpora p°ímých volání jazyka C/C++
SystemVerilog podporuje tzv. DPI
(Direct Programming Interface), které umoº¬uje p°ímé volání funkcí napsaných v jiných jazycích.
Zejména díky podpo°e objektov¥ orientovaného návrhu je SystemVerilog v sou£asné verzi standardu mnohem vhodn¥j²í pro TL modelování neº d°íve uvád¥ný VHDL. SystemVerilog je tedy stejn¥ vhodný pro vytvá°ení TL model· jako SystemC. Jeho mírnou nevýhodou je fakt, ºe SystemC je z principu zcela kompatibilní s jazykem C++ (zatímco SystemVerilog vyuºívá DPI), naopak výhodou je ur£it¥ to, ºe je ²iroce p°ijímán a podporován v rámci velkých rem [29, 28, 7].
96
KAPITOLA 6.
PODPORA TL MODELOVÁNÍ V OSTATNÍCH HDL JAZYCÍCH
6.3 Shrnutí SystemVerilog jiº nyní obsahuje v podstat¥ v²echna roz²í°ení, které jsou uvaºována pro budoucí vydání standardu VHDL. V tomto ohledu lze ozna£it SystemVerilog za pokro£ilej²í neº VHDL. V sou£asné dob¥ jsou v²echny t°i standardy jazyk· vyvíjeny pod dohledem stan-
2
dardiza£ní organizace Accellera , coº pravd¥podobn¥ bude v budoucnu p°iná²et dal²í snahu snadného p°echodu mezi modely psanými v r·zných jazycích.
2
www.accellera.org
Kapitola 7 Záv¥r
Práce se snaºí být základním, ale uceleným vhledem do problematiky vytvá°ení TLM model· v SystemuC. V ºádném p°ípad¥ se nesnaºí být referen£ní p°íru£kou. Knihy zabývající se metodologií TLM model· obsahují mnoho teorie. Bohuºel praktické pouºití je spí²e vyjímkou neº pravidlem. V¥°ím, ºe zde uvedené p°íklady mohou být kvalitním vodítkem p°i prvních krocích p°i seznamování se s tímto jazykem.
Cílem práce bylo prostudovat principy modelování digitálních obvod· na vy²²í úrovni abstrakce. Jako ilustra£ní jazyk byl po dohod¥ s vedoucím práce zvolen SystemC, který díky provázanosti s jazykem
C + + a jeho moºnostmi v této oblasti se jevil jako vhodný k tomuto
ú£elu.
Za£átek práce je v¥nován základním pojm·m a konstrukt·m jazyka vyuºívaných p°i vytvá°ení model· na RTL úrovni. Pojmy jsem se zde snaºil vysv¥tlit na jednoduchém p°íkladu úplné s£íta£ky, který mi p°i²el vhodný pro tento ilustra£ní ú£el. P°ehled, jak vytvo°it jednoduchý RTL model v SystemuC, je z mého pohledu nezbytný pro dal²í výklad a proto byl vy£len¥n do samostatné kapitoly.
Následující dv¥ kapitoly se v¥nují jiº samotnému modelování transakcí v SystemuC, kde v první z nich jsou nazna£eny principy a teorie ohledn¥ TLM model·. V druhé jsou jiº tyto principy aplikovány na konkrétních p°íkladech. Zde jsem se snaºil volit p°íklady co nejvíce srozumitelné i pro £tená°e neznalého problematiky a v¥°ím, ºe se mi to povedlo.
97
98
KAPITOLA 7.
ZÁV
R
Dal²í kapitola se v¥nuje p°echodu z model· na vy²²í úrovni abstrakce k RTL model·m. Jako ilustra£ní p°íklad jsem zvolil model aritmeticko-logické jednotky. Ve své podstat¥ se jedná o jednoduchý p°íklad, na kterém je d·leºitá zejména tvorba adaptér·, které jsou p°i tomto up°es¬ování pot°eba a princip znovu pouºitelnosti testovacích program· na modely v r·zné úrovni implementace. P°edposlední kapitola jiº jen stru£n¥ zmi¬uje jak si v podpo°e vytvá°ení TL model· stojí dal²í b¥ºn¥ pouºívané HDL jazyky. Konkrétn¥ jsou zde zmín¥ny jazyk VHDL a Verilog (SystemVerilog). Je zde uvedena historie a diskutován dal²í moºný vývoj t¥chto jazyk· v budoucnosti. Jako hlavní p°ínos této práce spat°uji, krom¥ popisu loso e, také v sad¥ p°íklad·, na kterých jsou principy vysv¥tleny a které jsou podle mého názoru nezbytné pro seznámení se s tímto návrhovým prost°edkem a principy v n¥m pouºívaných. Jak jiº bylo v pr·b¥hu práce n¥kolikrát zd·raz¬ováno, snaºil jsem se i v textu obsáhnout fragmenty kódu z t¥chto p°íklad·. Ne vºdy se povedlo zachovat úpln¥ p°ehledný zápis a proto p°i neporozum¥ní n¥kterým £ástem výkladu doporu£uji kompletní p°íklady na p°iloºeném CD.
Literatura
[1] BHASKER, J.
A SystemC Primer.
Star Galaxy Publishing, 1058 Treeline drive, Allen-
town, PA 18113, USA : Star Galaxy Publishing, 2nd edition, 2004.
[2] BLACK, D. C. et al.
SystemC: From the Ground Up.
1. Springer Science+Business
Media, LLC, 233 Spring Street, New York, NY 10013, USA : Springer Science, 2nd edition, 2010.
[3] FURA, D. A. SOMANI, A. C.
Transaction-Level Speci cation of VHDL Design
Models. 1995.
[4] GHENASSIA, F.
Transaction-level modeling with SystemC. Springer, P.O. Box 17, 3300
AA Dordrecht, The Netherlands : Springer, 2nd edition, 2005.
[5] GROETKER, T. et al.
System design with SystemC.
Kluwer academic publishing,
Hingham, MA, USA : Kluwer academic publishing, 2002.
[6]
IEEE Standard SystemC Language Reference Manual.
IEEE Computer Society, Park
Avenue 3, New York, USA, March 2006.
[7]
IEEE Standard for SystemVerilog - Uni ed Hardware Design, Speci cation, and Veri cation Language.
IEEE Computer Society, Park Avenue 3, New York, USA, December
2009.
[8] KEATING, M. BRICAUD, P.
Reuse methodology manual.
Kluwer academic publish-
ing, Hingham, MA, USA : Kluwer Academic Publishers, 3rd edition, 2002.
[9] LEWIS, J. SynthWorks What's Next in VHDL.
http://www.synthworks.com/papers/next_vhdl_date_2007.pdf.
99
100
LITERATURA
[10]
TLM-2.0 LANGUAGE REFERENCE MANUAL.
[11]
From VHDL Register Transfer Level to SystemC Transaction Level Modeling: a Com-
OSCI, ja32 edition, July 2009.
parative Case Study, 2003. Pontifícia Universidade Católica do Rio Grande do Sul. [12]
SystemC Synthesizable Subset.
Synthesis Working Group of Open SystemC Initiative,
1.3 draft edition, June 2009.
[13] SýKORA, J. Metody extrakce modelu z jazyka SystemC. diplomová práce, eske vysoké u£ení technické v Praze, kv¥ten 2009.
[14] web:CatapultC. Menthor Graphics Syntézní nástroj Catapult C home page.
http://www.mentor.com/esl/catapult/overview. [15] web:cstug. CSTUG
CSTEX
Users Group hlavní stránka.
http://www.cstug.cz/. [16] web:doulus. Doulos KnowHow, Free Technical Resources.
http://www.doulos.com/knowhow/. [17] web:emb. EMBECOSM Building a Loosely Timed SoC Model with OSCI TLM 2.0.
http://www.embecosm.com/appnotes/ean1.html. [18] web:forte. FORTE design system training.
http://www.forteds.com/systemc/training/. [19] web:info. K336 Info.
http://info336.felk.cvut.cz. [20] web:infodp. K336 Info pokyny pro psaní diplomových prací.
https://info336.felk.cvut.cz/clanek.php?id=400. [21] web:installGuide. Guide for getting started with SystemC development.
http://www.dti.dk/_root/media/SystemC_Getting_Started_artikel.pdf. [22] web:JHDL. JHDL home page.
http://www.jhdl.org/.
101
LITERATURA
AT X online manuál. [23] web:latexdocweb. L E
http://www.cstug.cz/latex/lm/frames.html. AT X. [24] web:latexwiki. Wiki Books L E
http://en.wikibooks.org/wiki/LaTeX/. [25] web:ovp. OVP Open virtual platforms.
http://www.ovpworld.org/. [26] web:SystemC. SystemC home page.
http://www.systemc.org/
(do 4.12.2011)
http://www.accellera.org/
(od 5.12.2011).
[27] web:tlmCentral. TLMCentral web portal about TLM modelling.
http://www.tlmcentral.com. [28] web:VerilogTLM.
Synopsys Transaction-Level Modeling: SystemC and/or Sys-
temVerilog.
http://www.soccentral.com/results.asp?EntryID=18241. [29] web:wikiVerilog. Wikipedia Verilog.
http://en.wikipedia.org/wiki/Verilog,
stav z 10. 4. 2012.
[30] web:wikiVHDL. Wikipedia VHDL.
http://en.wikipedia.org/wiki/VHDL,
stav ze 6. 4. 2012.
102
LITERATURA
P°íloha A Seznam pouºitých zkratek
ALU AT
Arithmetical-Logical Unit
Approximately-Timed Model
BFM
Bus Functional Model
CRC
Cyclic Redundancy Check
DMI
Direct Memory Interface
DPI
Direct Programming Interface
DUT
Design Under Test
FPGA
Field Programmable Gate Array
HAL
Hardware Abstraction Layer
HDL
Hardware Description Language
HDVL HW IP
Hardware Design and Veri cation Language
Hardware
Intellectual Property
ISA
Instruction Set Architecture
103
104
PÍLOHA A.
ISS LT
Instruction Set Simulator
Loosely-Timed Model
MUX OO
Multiplexer
Object Oriented
OOPS PCA
Object Oriented Programming Structure
Pin and Cycle Accurate
PSL
Property Speci cation Language
RTL
Register Transfer Level
SAM SoC TL
System-On-Chip
Transaction-Level
TLM UT
System Architecture Model
Transaction-Level Modeling
Untimed Functional Model
UUT
Unit Under Test
VCD
Value Change Dump
SEZNAM POUITÝCH ZKRATEK
P°íloha B P°eklad p°íklad·, instalace SystemC a TLM knihovny
B.1 Instalace SystemC a TLM knihovny Instalace samotného SystemuC je moºná jak na po£íta£ích s opera£ním systémem Windows, tak i Linux. Prvním spole£ným krokem je staºení obou knihoven z o ciálních stránek Sys-
1
temC . Stahované soubory se nacházejí pod záloºkami
Downloads→Accellera Systems
Initiative Standards→SystemC 2.2. Kde v tabulce Current Releases
je moºné nalézt ak-
tuální verze SystemuC i TLM knihovny. Ke staºení je nutné se p°ihlásit p°ípadn¥ registrovat.
Linux Knihovna SystemC Instalace byla otestována v opera£ním systému Linux (konkrétn¥ Ubuntu 11.04 64bit). P°ed za£átkem instalace je nutné zjistit pouºívanou verzi p°eklada£e
$ g++ -v 1
http://www.accellera.org/home/
105
g++ p°íkazem:
106PÍLOHA B. PEKLAD PÍKLAD, INSTALACE SYSTEMC A TLM KNIHOVNY
Pokud pouºíváte verzi 3 a niº²í, je v²e v po°ádku a není nutné provád¥t ºádné zm¥ny. V p°ípad¥ verze 4.x.x. je zapot°ebí v pr·b¥hu instalace p°ed provedením kompilace balí£k· (make) p°idat do souboru
/home/<user>2 /systemc-2.2.0/src/sysc/utils/sc_utils_ids.cpp
odkazy na tyto dva hlavi£kové soubory:
#include "string.h" a #include "cstdlib" Nyní jiº samotný postup instalace:
1. rozbalit archiv
TLM-2.0.1.tgz
do domovské sloºky (p°ípadn¥ jinam dle uváºení):
$ tar xzf systemc-2.2.0.tgz -C /home/<user>/ 2. vytvo°it adresá°
objdir
v rozbaleném adresá°i
$ mkdir /home/<user>/systemc-2.2.0/objdir 3. p°ejít do nov¥ vytvo°eného adresá°e:
$ cd /home/<user>/systemc-2.2.0/objdir 4. kon gurovat balí£ky pro vá² systém:
$ ../configure 5. kompilovat balí£ky:
$ make 6. instalovat balí£ky:
$ make install
Tímto posledním krokem se knihovna nainstalovala do:
/home/<user>/systemc-2.2.0/lib-linux64/libsystemc.a Pro ov¥°ení funk£nosti je je²t¥ moºné provést p°íkaz:
$ make check 2
Tuto £ást nahradit za jméno aktuálního uºivatele
B.2.
107
PEKLAD PÍKLAD
Knihovna TLM Knihovnu TLM není nutné instalovat. K rozbalení komprimovaného archivu je moºné pouºít tento p°íkaz:
$ tar xzf TLM-2.0.1.tgz -C /home/<user>/ Rozbalený adresá° bude umíst¥n v domovském adresá°i uºivatele.
Windows Instalace knihoven SystemuC a TLM ve Windows je z velké £ásti klikací záleºitostí. Z toho d·vodu zde nebudu uvád¥t konkrétní postup instalace, ale omezím se pouze na konstatování, ºe lze SystemC nainstalovat t¥mito dv¥ma postupy: 1. s vyuºitím nástroj· pod GPL/GNU licencí jako Netbeans a Cygwin 2. za pomoci Microsoft Visual Studia Oba postupy jsou popsány v o ciální dokumentaci ke knihovnám, p°ípadn¥ je moºné pouºít tutoriál Dánského technologického institutu [21].
B.2 P°eklad p°íklad· Sou£ástí v²ech p°iloºených p°íklad· je kompila£ní script utility adresá°i je nutné nastavit v souboru
Make le
Make le.
V poºadovaném
cesty ke knihovnám a správnou architekturu
pro p°eklad. Konkrétn¥ se jedná se o tyto parametry:
DEFAULT_TARGET_ARCH cílová architektura (linux32, linux64, win32, . . . )
DEFAULT_SYSTEMC_HOME adresá° s instalovanou knihovnou SystemC
DEFAULT_TLM_HOME adresá° s knihovnou TLM
K následnému p°ekladu se pouºije p°íkaz:
$ make Pro smazání zkompilovaných soubor· je moºné poté pouºít p°íkaz:
$ make clean
108PÍLOHA B. PEKLAD PÍKLAD, INSTALACE SYSTEMC A TLM KNIHOVNY
P°íloha C Obsah p°iloºeného CD
. |-- files/ |
|-- FullAdder/
|
|-- FullAdderNBits/
|
|-- FullAdderRefinement/
|
|-- TLM_approximately_time_model/
|
|-- TLM_loosely_time_model/
|
|-- TLM_loosely_time_model_advance/
|
|-- README.txt
|-- text/ |
|-- source/
|
|-- mikesfi1-thesis.pdf
|-- README.txt files
Zdrojové kódy p°íklad· probíraných v práci a kompila£ní skripty.
text Adresá° s textem práce v PDF formátu a zdrojovým textem ve formátu LATEX. README.txt
Podrobn¥j²í popis struktury a obsahu CD.
109
