Sem vložte zadání Vaší práce.

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra číslicového návrhu Diplomová práce Hardwarový akcelerátor pro dopočtení chybějících položek v datovém streamu Bc Josef Dvořáček Vedoucí práce: Ing. Jan Schmidt, Ph.D. 11. května 2012

Poděkování Rád bych poděkoval Ing. Janu Schmidtovi, Ph.D. za cenné rady při tvorbě této práce a také Bc. Michalu Prokšovi a jeho HW týmu ze spol RSJ za konzultace v průběhu návrhu.

Prohlášení Prohlašuji, že jsem tuto práci vytvořil samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. 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ý zákonů (autorský zákon), nemám závažný důvod proti užití tohoto školního díla a k užití uděluji svolení. V Praze dne 11. května 2012..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Josef Dvořáček. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Josef Dvořáček. Hardwarový akcelerátor pro dopočtení chybějících položek v datovém streamu: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract This thesis deals with the design of hardware accelerator core which calculates missing items in input stream of pre-processed information on the derivative markets. Implemented was the unit calculating values of Implied IN spread using language VHDL. Keywords VHDL, HW core, Implied IN Abstrakt Tato diplomová práce se zabývá návrhem hardwarového akcelerátoru pro dopočtení chybějících položek v předzpracovaném streamu informací o derivátových trzích. Implementována je jednotka dopočítávající hodnoty impliedů spread IN za použití jazyka VHDL. Klíčová slova VHDL, HW jádro, Implied IN 9

Obsah Úvod 17 1 Popis problému, specifikace cíle 19 1.1 Individual outright orders..................... 19 1.2 Strategie............................... 20 1.3 Implied orders........................... 21 1.4 Cíl práce............................... 24 1.5 Shrnutí kapitoly.......................... 25 2 Analýza a návrh 27 2.1 Studie proveditelnosti....................... 27 2.2 Požadavky na realizaci jednotky................. 29 2.3 Analýza procesů v jednotce.................... 31 2.4 Popis na úrovni bloků....................... 33 2.5 Návrh výpočetního jádra...................... 35 2.6 Shrnutí kapitoly.......................... 37 3 Realizace 39 3.1 Struktura implementace...................... 39 3.2 Výsledky syntézy.......................... 49 4 Testování 51 4.1 Model................................ 51 4.2 Zapojení HW do testbenche.................... 51 4.3 Generátor stimulů......................... 52 4.4 Průběh testu, shrnutí testování.................. 53 5 Diskuze rozšíření stávajícího řešení 55 5.1 Převedení ROM pamětí v jednotkách na RAM......... 55 5.2 Převedení FSM ve výpočetním jádře na mikrokódový řadič.. 55 5.3 Snížení latence v spread_unit................... 56 5.4 Dopočítávání jiných strategií než je spread............ 56 5.5 Počítání více hodnot žebříčku................... 56 5.6 Optimalizace z hlediska využití paměti BRAM......... 57 11

5.7 Dopočítávání více generací..................... 57 5.8 Návrh překladače mikrokódu................... 58 Závěr 59 Literatura 61 A Seznam použitých zkratek 63 B Obsah přiloženého CD 65 12

Seznam obrázků 1.1 tvar grafu strategie butterfly, zdroj [9]................ 20 2.1 zjednodušený model výpočtu..................... 28 2.2 Vývoj množství dat na vstupním zásobníku............. 29 2.3 Návrh algoritmu jednotky....................... 33 2.4 Architektura jednotky......................... 34 2.5 Vstupní a výstupní proměnné algoritmu............... 36 2.6 Algoritmus výpočtu.......................... 36 3.1 Konečný stavový automat řídící I/O operace............ 41 3.2 Architektura INT části......................... 45 3.3 Architektura FP části......................... 46 3.4 činnost řídícího automatu v INT části................ 46 3.5 činnost řídícího automatu v FP části................. 47 3.6 Petriho síť synchronizace automatů.................. 48 5.1 Hloubka závislostí v datové struktuře outrightů........... 58 13

Seznam tabulek 1.1 Příklad výpočtu Implied In do spreadu................ 21 1.2 Výchozí hodnoty pro výpočet butterfly implied IN......... 23 1.3 Výpočet více generací impliedů.................... 24 2.1 význam bitů v datových slovech (vysvětlení zkratek: MS = market side, s = start of message, e = end of message)........... 30 2.2 formát FP................................ 31 2.3 Výskyt instrukcí a jejich očekávané trvání.............. 37 3.1 rozhraní jednotky top......................... 40 3.2 Význam jednotlivých bitů mikrokódu................. 43 3.3 Možnosti podmíněného skoku..................... 43 15

Úvod Finanční prostředí je charakterizováno stále se zvyšujícím tempem shromažďovaných informací, a akcí, které tyto informace implikují. Vysoká rychlost reakce na získaná data je podmínkou pro úspěch na trhu. Toto prostředí tedy stimuluje závody ve zbrojení v informačních technologiích nasazovaných pro řešení těchto problému. [7] Již v devadesátých letech byl zaveden termín Electronic trading (ET)pro obchodování pomocí počítačových sítí oproti klasickým způsobům jako je pošta, telefon, nebo osobní kontakt. Algorithmic trading (AT) už může být definován jako elektronické obchodování při kterém algoritmy dynamicky určují načasování, cenu, množství a směrování zakázek v návaznosti na sledování aktuálních podmínek na trhu. [3] High frequency trading (dále jen HFT) je podmnožinou AT, kde jsou velká množství objednávek zasílána na burzu vysokou rychlostí, s dobou odezvy měřenou v mikrosekundách. [3] Je přirozené, že pro akceleraci výpočtů bývá část algoritmu implementována v hardwaru. Např. [8] uvádí, že řešení založené na FPGA je 20x rychlejší, než obvyklé aplikace běžící výhradně v SW. Má diplomová práce se bude zabývat analýzou podmnožiny výpočtů AT, návrhem algoritmu a implementací modulu pro HFT, konkrétně pro výpočet Implied Orders v reálném čase. 17

KAPITOLA 1 Popis problému, specifikace cíle V této kapitole si představíme instrumenty na finančním trhu a způsob jejich výpočtu důležitý z hlediska návrhu výpočetní jednotky. Přečtením této kapitoly se čtenář seznámí s výchozími informacemi pro návrh algoritmů a implementaci v dalších částech práce. Popis termínů níže odpovídá jejich použití na derivátových burzách. Na jiných můžou mít význam jiný, nebo vůbec neexistují. 1.1 Individual outright orders Jak bylo řečeno v úvodu, AT/HFT používá určité vstupní informace pro generování objednávek na burze. Jednou z nejdůležitějších informací je aktuální pozice jednotlivých trhů (marketů). Tu poznáme podle objednávek, které obchodníci vkládají na trh. Taková objednávka se může týkat buď jednoho instrumentu, nebo jejich kombinaci. Objednávku jednoduchého instrumentu budeme nazývat individual outright order. (OO) Taková objednávka udává cenu, za kterou je zadavatel objednávky (čili nějaký obchodník na burze) ochotný nakoupit nebo prodat určité množství obchodovaného subjektu. Pochopitelně, zájmem obchodníků je draze prodat (SELL side) a levně nakoupit (BUY side). Pokud bychom si rozložili tyto objednávky na osu dle ceny odspodu nahoru, vytvoříme si tím virtuální žebříček, na kterém se nabídky na prodej budou zespodu blížit nabídkám na koupi nahoře. ( K překřížení BUY / SELL stran nedochází, protože dříve proběhne samotný obchod) 19

1. Popis problému, specifikace cíle Obrázek 1.1: tvar grafu strategie butterfly, zdroj [9] Jednotlivé nabídky jsou indexovány od virtuálního středu. Při číslování od jedničky, nejnižší nabídka SELL má index 1, další vyšší nabídka má index 2 atd. Na strany BUY je to obráceně. Index 1 má nejvyšší nabídka a s klesající cenou index roste. Nejvíce pohybů na trhu se děje okolo virtuálního středu, kde dochází k vypořádávání objednávek, tato oblast je tedy pro analýzu trhu nejdůležitější. Zadáním bylo specifikováno, že pro výpočty jsou relevantní první dva indexy BUY a první dva indexy SELL. Ostatní indexy budou ignorovány, jejich případné využití bude diskutováno v kapitole Analýza a návrh. Jedna pozice na žebříčku je tedy definována tzv market side - tj, jestli obchodník chce nakupovat, nebo prodávat, dále cenou a množstvím. Seřazením objednávek vzestupně dle ceny dostaneme žebříček. 1.2 Strategie Na finančního trhu se používají i pokročilejší instrumenty. Jejich cílem je obvykle optimalizovat zisk investora, nicméně konkrétní účely a způsoby jejich využití nespadají do zadání této práce, proto se tady zmíním pouze o dvou typech strategií. Pro zápis strategie budu používat velká písmena pro identifikaci marketu (produktu) a znaménka pro operaci - žádné znaménko, popř plus znamená nákup, minus je prodej. A-B-2C tedy znamená nákup A, prodej B a dvojnásobné množství C. 20

1.3. Implied orders V1 Bid Qty Bid Price Offer Price Offer Qty 5 996 1008 3 V2 Bid Qty Bid Price Offer Price Offer Qty 7 503 520 9 V1 - V2 Bid Qty Bid Price Offer Price Offer Qty 5 476 505 3 Tabulka 1.1: Příklad výpočtu Implied In do spreadu Strategie spread Spread může být označení pro rozdíl mezi cenou nabídky a poptávky na konkrétním trhu, například, pokud prodávající žádá 1.5 M USD ale nabídka je pouze 1.2 M USD, spread bude 300 000 USD. [6] Je to však také název strategie, při které se současně nakupují a prodávají dva outrighty [10]. Zkráceně tedy A B. Speciálním případem spreadu je tzv. calendar spread, kdy se obchoduje s jedním kontraktem, ale s různou dobou expirace. Strategie butterfly Složitější strategie, je nazvána butterfly, podle výsledného tvaru grafu 1.1, který snad připomíná motýla [9]. Strategie spočívá v nákupu ve množství n jednoho (M), prodeji 2*n druhého(u), a n třetího produktu(z) [4], zkráceně M 2U +Z. A protože platí výraz 1.1, jedná se o strategii ekvivalentní spreadu dvou spreadů.. (M U) (U Z) = (M U U + Z) = (M 2U + Z) (1.1) 1.3 Implied orders Pokud známe žebříčky výchozích marketů, dokážeme si dopočítat hodnoty na žebříčku strategie, která je nad nimi založena. Protože položky na žebříčku strategie nebudou skutečné, ale jen dopočtené, označují se jako Implied orders. 21

1. Popis problému, specifikace cíle Implied IN vs Implied OUT Pokud známe všechny outright orders které tvoří strategii, dokážeme tedy dopočítat implied orders této strategie. Tyto implied objednávky se pak nazývají implied IN. Obráceně, známe-li objednávky na žebříčku strategie, a všechny outrighty které ji tvoří kromě jednoho, dokážeme z nich zpětně dopočítat Implied OUT objednávky do chybějícího marketu. Dopočítávání Implied IN do strategie spread Implied IN se do spreadu počítá v BUY (Bid) side dle vzorce 1.2, pro výpočet SELL (Offer) side dle vzorce 1.3. Příklad výpočtu spread OUT je v tabulce 1.1. Dopočítávaná je poslední část tabulky V1 - V2. (V 1 V 2) BidP rice = V 1 BidP rice V 2 OfferP rice (1.2) (V 1 V 2) OfferP rice = V 1 OfferP rice V 2 BidP rice (1.3) Pro množství (Qty) platí vztahy 1.4 a 1.5. (V 1 V 2) BidQty = Min(V 1 BidQty, V 2 OfferQty ) (1.4) (V 1 V 2) OfferQty = Min(V 1 OfferQty, V 2 BidQty ) (1.5) Příklad výpočtu je v tabulce 1.1. Pokud je na vstupním žebříčku více hodnot(indexů), i na žebříčku kontraktu do kterého impliedy dopočítáváme bude hodnot více. Způsob dopočtení více hodnot je na diagramu 2.6. Dopočítávání Implied OUT ze strategie spread Tak jak se dá vypočítat implied in do strategie spread, tj rozdílu, dopočet lze provést obráceně. Pokud znám outrighty V1 a outrighty spreadu V1-V2, mohu dopočítat implieds do V2: V 2 BidP rice = (V 1 V 2) BidP rice V 1 OfferP rice (1.6) V 2 BidQty = Min((V 1 V 2) BidQty, V 1 OfferQty ) (1.7) V 2 OfferP rice = V 1 OfferP rice (V 1 V 2) OfferP rice (1.8) V 2 OfferQty = Min(V 1 OfferQty, (V 1 V 2) OfferQty ) (1.9) 22

1.3. Implied orders index / market side M8 U8 Z8 2 / BID 2@15 1@1 1 / BID 1@20 1@2 1 / ASK 5@5 2 / ASK 4@6 Tabulka 1.2: Výchozí hodnoty pro výpočet butterfly implied IN Analogicky bude probíhat výpočet V1 z outrightů spreadu V1-V2 a V2: V 1 BidP rice = V 2 BidP rice + (V 1 V 2) BidP rice (1.10) V 1 BidQty = Min(V 2 BidQty + (V 1 V 2) BidQty ) (1.11) V 1 OfferP rice = V 2 OfferP rice + (V 1 V 2) OfferP rice (1.12) V 1 OfferQty = Min(V 2 OfferQty + (V 1 V 2) OfferQty ) (1.13) Bid a BUY side, stejně tak Offer a SELL side jsou ekvivalentními výrazy pro označení jedné či druhé strany marketu. Dopočítávání Implied IN do strategie butterfly Strategie butterfly může být vybudována nad třemi individuálními outrighty, nebo dvěma individuálními outrighty a jedním spreadem, nebo nad dvěma spready. Vzorce by byly velmi podobné těm výše, proto provedu rovnou ukázku výpočtu. Výchozími hodnotami je žebříček marketů M8, U8, Z8 v tabulce 1.2. Pro zkrácení zápisu je v tabulce použit formát (množství)@(cena). Budeme počítat BUY (Bid) stranu marketu. Postup výpočtu: 1. Začneme na nejnižším indexu. Víme že pro výpočet butterfly potřebujeme celistvý násobek M 2U +2. Na nejnižších indexech máme: 1 M8, 5 U8 a 1 Z8. Z toho můžeme vypočítat jeden implied. Qty na prvním indexu bude 1. 2. Price vypočítáme jako 20 + 2 (2 5) = 12. 23

1. Popis problému, specifikace cíle krok popis A A-B B B-C C 1 výchozí stav 1 4 2 2 2 2 2 4 2 2 2 3 z A-B a B mohu vypočíst 1, 2i 2 0 2 2 implied 1. gen. 4 1, 2i 2 0 2 2 5 z B-C a C mohu vypočíst 1, 2i 2 0,2i 0 0 implied 1. gen. 6. 1, 2i 2 0,2i 0 0 7 z A-B a B mohu vypočíst 1, 2i, 0 0,0i 0 0 implied 2. gen. 2ii Tabulka 1.3: Výpočet více generací impliedů 3. Přejdeme k vyššímu indexu. V M8 máme hodnotu s nejnižším indexem na indexu 2, to samé u Z8. Na U8 zbyla nabídka 3@5 na indexu 1. Qty na druhém indexu bude tedy také 1. 4. Price vypočítáme podobně jako u prvního indexu, 15 + 1 (2 5) = 6 Dopočítání druhé strany žebříčku by proběhlo analogicky. Počítání druhé a další generace impliedů První generace impliedů, které jsme počítali výše vycházejí z existujících outrightů na marketu. Impliedy je však možné počítat z již existujících impliedů, tj. k počítání další generace. Princip výpočtu je úplně stejný, postup jsem krok za krokem znázornil na příkladu v tabulce 1.3. Mějme kontrakty (markety) A, B, C, spread A B a spread B C. Impliedy první generace budu značit jedním písmenem i, impliedy druhé generace dvěma písmeny - ii. Pokud nějaký outright spotřebuji na implied, v dalších krocích ho již neuvádím. Pro přehlednost je v tabulce jen parametr množství, cena by se počítala stejně jako ve výpočtech výše. Budeme se snažit vypočítat všechny možné impliedy do kontraktu A. 1.4 Cíl práce Nejen výše uvedené instrumenty může obchodník získávat přímo z burzy, nebo, pokud nejsou dostupné, si je musí dopočítat sám. V současnosti jsou obvyklá softwarová i hardwarová řešení. Nejen HFT vyžaduje aktuální data co nejrychleji, proto jsou hardwarově akcelerovaná řešení považována za lepší. [8] 24

1.5. Shrnutí kapitoly Cílem práce tedy bude navrhnout HW jednotku která výpočte implied orders pro strategii spread z outright orders v reálném čase. Jednotka by měla splňovat následující podmínky: Požadavky na funkcionalitu jednotky sledovaná data se budou dočasně ukládat v jednotce automatická detekce všech možných výpočtů v daném časovém úseku po aktualizaci na vstupu následuje nový výpočet rychlost jednotky odpovídající příchozímu streamu dat možnost rozšíření o nové typy implied orders transparentní chování k existujícím datům - ta nesmí být modifikována postačí dopočítat pouze první dva indexy na daném marketu funkcionalita jednotky bude ilustrována na výpočtu spreadu IN Implementační podmínky návrhu návrh by měl používat syntetizovatelné VHDL kód by měl být přenositelný mezi HW platformami různých výrobců vnitřní škálovatelnost - tj. mělo by být možné zvýšit propustnost jednotky pro vybrané operace / markety na vstupu i na výstupu musí být použito specifikované rozhraní 1.5 Shrnutí kapitoly Dozvěděli jsme se co je to market, co jsou to impliedy a konkrétně, jak se počítá spread. Definovali jsme si požadavky na funkcionalitu i implementační podmínky návrhu. 25

KAPITOLA 2 Analýza a návrh V této kapitole bude předvedena studie proveditelnosti, následně bude analyzován algoritmus a navržena architektura jednotky. 2.1 Studie proveditelnosti Před návrhem jednotky bylo potřeba zjistit, jaké budou nároky na výslednou jednotku a to zejména v časové oblasti. Zadavatelskou firmou byly poskytnuty vzorové logy z jednotlivých serverů, zpracovávajících stejné objemy dat, které by měla zvládnout navrhovaná jednotka. Pro tyto účely byl navržen zjednodušený obecný sériový model jednotky: 2.1. Ten se skládá z vstupní fronty, paměti BRAM, výpočetní jednotky a výstupu. Model má tři operační módy: Výchozí stav: příchozí data se posílají transparentně na výstup. Když je detekován konec jedné zprávy (sady updatů) přechází se do režimu výpočet. Výpočet: data se hromadí ve vstupní frontě, výpočetní jednotka provádí výpočet. Po dokončení výpočtu se přejde do stavu vyčítání Vyčítání: Data se z výpočetní jednotky posílají na výstup, další stav je výchozí stav Tento model je dostatečně výstižný a současně dosti obecný, takže simuluje chování většiny možných řešení. 2.1.1 Implementace modelu Model byl implementován v jazyce Java, který byl zvolen zejména kvůli mým předchozím zkušenostem s tímto jazykem a také kvůli dostatku funkcí pro 27

2. Analýza a návrh Obrázek 2.1: zjednodušený model výpočtu práci se soubory. Hodinový signál a komunikace mezi jednotlivými jednotkami byly simulovány pomocí pomocí jednotlivých proměnných, latence jednotek tvořily for cykly. Vstupem jednotky byl textový soubor obsahující updaty z burzy opatřené timestampy. Vzhledem k charakteru dat bylo nutné provést některá zjednodušení - např. za ucelenou zprávu jsem považoval sadu dat s jednotným timestampem. Asymptoticky je však toto stejné. 2.1.2 Popis simulace Hlavní otázkou, kterou simulace měla zodpovědět, byla realizovatelnost jednotky a maximální čas, který máme k dispozici k výpočtu impliedů. Tento parametr může být v modelu dobře sledován tak, že ve výpočetní jednotce měníme parametr délky výpočtu a poté modelem necháme zpracovat zkušební data. Sledujeme poté velikost vstupního zásobníku. Simulační krok byl nastaven tak, že jeden tik hodin trvá 0.0000001 s. Frekvence hodin tedy odpovídá 10 Mhz Na grafu zde 2.2 jsou zaneseny výsledky simulace pro délku výpočtu trvající 10,100 (totožné výsledky), 1000, 10000, 100000 a 1000000 taktů. Na svislé ose je množství updatů na zásobníku, na vodorovné ose jsou změny na zásobníku. (tj. ne simulační čas!) 1 1 Pokud by byl na vodorovné ose simulační čas, mohlo by dojít k ztrátě špičkových hodnot během které by mohly vzniknout při více updatech s jedním timestampem. Pokud bychom chtěli graf převést do časové oblasti, došlo by pouze k horizontálnímu roztažení/stáhnutí, tj. námi požadovaný parametr, stav obsazenosti zásobníku se nijak neovlivní. 28

2.2. Požadavky na realizaci jednotky Obrázek 2.2: Vývoj množství dat na vstupním zásobníku 2.1.3 Výsledky měření Ze simulace vyplývá, výpočet začíná být vzhledem k odsimulovaným vstupním datům neúnosně dlouhý až když trvá déle, než je 100000 taktů při frekvenci 10Mhz. Převedením tohoto grafu do časové oblasti bychom dostali okamžitou délku latence pro různé doby výpočtu, nicméně vzhledem k hrubosti modelu toto provádět nebudeme a tyto časy budeme měřit až ve VHDL implementaci. Během návrhu HW vyšlo najevo, že jednotka poběží bez problému s frekvencí hodin 250 Mhz, neúnosná délka výpočtu tedy je až 2,5 M taktů. 2.1.4 Interpretace měření Budeme-li předpokládat výpočet spread IN, který má za vstup 8 celočíselných hodnot, 8 čísel v plovoucí řádové čárce a výstupem jsou 4+4 hodnoty, můžeme s přihlédnutím do první kapitoly odhadnout potřebný výpočetní čas. Výpočet spreadu se bude skládat z cca 5 celočíselných operací (á 2 takty), cca 5 floatingpoint operací (á 7 taktů) a cca 24 in/out operací (á 1 takt) výpočet by tedy mohl trvat řádově 100 taktů. Máme-li k dispozici na výpočet 100000 taktů, můžeme provést jen s jednou výpočetní jednotkou 1000 výpočtů spread na jeden update, což je uspokojivá hodnota. Proveditelnost řešení je tedy ověřena. 2.2 Požadavky na realizaci jednotky Požadavky si můžeme rozdělit na kritéria obslužné logiky a samotného výpočetního jádra. 29

2. Analýza a návrh n včetně řídících bitů 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 n bez řídících bitů 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 položky hlavičky msg ID počet následujících slov UNIT ID expl. price update 0 0 0 0 1 0 počet updatů 0 0 0 0 0 0 implied price update 0 0 0 0 1 1 počet updatů 0 0 0 0 0 0 update ceny +/- Exponent Mantisa (horních 9b) update množství Množství - Integer - horních 18b timestamp Timestamp - horních 18b n včetně řídících bitů 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 n bez řídících bitů 13 12 11 10 9 8 7 6 5 4 3 2 1 0 3 2 1 0 položky hlavičky specifický obsah zprávy s e - - expl. price update Market ID MS - - - - - s e - - implied price update Market ID MS 1. index s e - - update ceny Mantisa (zbylých 14b) s e - - update množství Množství - Integer - zbylých 14b s e - - timestamp Timestamp- zbylých 14b s e - - Tabulka 2.1: význam bitů v datových slovech (vysvětlení zkratek: MS = market side, s = start of message, e = end of message) Obslužná logika by měla zajišťovat tuto funkcionalitu: Transparentní chování vůči datům, která nás nezajímají Zajištění rovnoměrného vytížení výpočetního jádra Škálovatelnost na úrovni jader, možnost přidání dalších výpočetních jader dle potřeby Řízení výstupu dat Výpočetní jádro by mělo splňovat tyto kritéria: Autonomie jádra - po přivedení vstupních hodnot by jádro mělo provést výpočet samo - důležité kvůli případnému škálování počtu jader Rychlost výpočtu - na rychlosti výpočtu jádra bude záviset latence celé jednotky Variabilita - jádro by mělo být konfigurovatelné na jiný druh výpočtu Jedním z kritérií na obslužnou logiku je i rozhraní, které bylo specifikováno zadavatelem. 2.2.1 Specifikace vstupního a výstupního interface Komunikace s okolím probíhá po tzv. stream interface. Naše jednotka bude mít jedno vstupní a jedno výstupní. Komunikace probíhá paralelně po jednotlivých 30

2.3. Analýza procesů v jednotce Bit Význam 0-22 mantisa (skrytá jednička) 23-30 exponent (bias=127) 31 znaménko, 0=kladné, 1=záporné číslo Tabulka 2.2: formát FP zprávách, a to s 32 datovými bity a 4 bity řídícími. Zprávy můžou obsahovat více slov. Slovo je široké právě 36 bitů, což je šířka sběrnice. První slovo každé zprávy obsahuje hlavičku, která nese informaci o případných dalších slovech zprávy. Řídicí bity Řídící bity jsou pro nás zajímavé pouze bit 3 - SOM - start of message, nastaven na 1 v prvním slově zprávy a 2 - EOM - end of message, nastaven na 1 v posledním slově zprávy. Datové bity Datových bitů je 32 a jejich využití se mění. Pro nás jsou důležité zprávy typu Explicit Price Update, které budeme přijímat a Implicit Price Update, které budeme na výstupu generovat. Oba tyto druhy zpráv obsahují parametr N, který udává počet následujících updatů. Pro získání počtu datových slov musíme tuto hodnotu vynásobit dvěma, každý update se totiž skládá ze dvou zpráv - 32 bitový integer - parametr množství a 32 bitový float - parametr cena. Bližší struktura je v tab??. Reprezentace FP je v souladu s IEE754 [11] jakožto single precision float: 2.2. Vztah mezi číslem a jeho obrazem je X F P = ( 1) s 2 exp bias (1 + m), kde s je znaménkový bit, exp je exponent, bias je 127 a m mantisa. V mantise se počítá se skrytou jedničkou. 2.3 Analýza procesů v jednotce Nejdříve je zadání analyzováno na úrovni jednotlivých procesů, které budou v jednotce probíhat. U každého procesu budou zmíněna kritéria, podle kterých budeme uvažovat způsob implementace. 2.3.1 Přijetí a detekce zprávy Na vstupním rozhraní se mohou obecně vyskytovat jakékoliv zprávy, tj. nejen Explicit Price Update. Jakékoliv přijaté zprávy nesmí být nijak měněny a musí 31

2. Analýza a návrh být poslány dále. Jediná povolená operace se vstupním tokem je jeho pozastavení po dobu výpočtu, případné vložení vlastních, nových zpráv. Manipulace s existujícími zprávami je nepřípustná. Po přijetí zprávy detekujeme typ a dle něj ji buď pouze předáme na výstup, nebo ji uložíme pro další zpracování. Možná kritéria latence zpracování - co nejmenší rekonfigurovatelnost - není nutná (formát zpráv se nebude měnit často) 2.3.2 Cachování explicitních updatů Pro výpočet impliedů na obou marketside potřebujeme stejně velký žebříček indexů na explicitních hodnot. Tyto hodnoty (tj. cena a množství) budeme udržovat v cache, aby po příchodu update byly okamžitě k dispozici všechny výchozí hodnoty pro výpočet impliedů. Přijde-li do jednotky nový update, je jeho hodnotou přepsána minulá hodnota v cache. Možná kritéria malá plocha na čipu - paměti jsou obvykle náročné vhodný formát zápisu i čtení rychlost zápisu i čtení 2.3.3 Detekce možného výpočtu Výpočet může proběhnout pouze za přítomnosti všech vstupních hodnot. Např. pro výpočet obou marketside impliedů do spread in potřebujeme obě strany žebříčku obou vstupních hodnot. Potřebujeme tedy detekci přítomnosti všech proměnných v cache pro daný výpočet. Možná kritéria rekonfigurovatelnost - občas může dojít ke změně počítaných impliedů 2.3.4 Vlastní výpočet V prototypu implied IN do spread - z dostupných proměnných vypočítat požadovanou hodnotu. Popisu procesů v této jednotce se věnuje samostatná sekce této kapitoly dále. 32

2.4. Popis na úrovni bloků Obrázek 2.3: Návrh algoritmu jednotky Možná kritéria rekonfigurovatelnost - občas může dojít ke změně počítaných impliedů rychlost - na výkonu této části závisí propustnost celé jednotky 2.3.5 Generování výstupních zpráv Posledním procesem je sběr dat z výpočtu a sestavení výstupní zprávy dle specifikace. Možná kritéria rychlost - střední Celkový algoritmus můžeme popsat tímto způsobem: Přijímajíce nová data je cache periodicky kontrolována, zda neobsahuje hodnoty, ze kterých můžeme vypočítat nějaký explicit. Obsahuje-li, pozastavíme příjem nových updatů (ty se hromadí ve frontě před naší jednotkou), provede se výpočet, výsledná data se pošlou na výstupní rozhraní a cyklus pokračuje dále od začátku přijmutím nových updatů. Překresleno do diagramu: 2.3. 2.4 Popis na úrovni bloků V této části popíšu obslužnou logiku na úrovni bloků, jejich chování a propojení. Jejich konkrétní implementace bude probrána v další kapitole. Propojení je naznačeno na obr 2.4. 33

2. Analýza a návrh Obrázek 2.4: Architektura jednotky In/out řadič Tento blok zachytí data na vstupu, detekuje typ zprávy a dle něho s ní naloží. Implicit updaty pošle na vstup bloku implicit cache, ostatní jen přepošle na výstup. Blok zajišťuje logiku zamykání vstupu - je li výpočetní jednotka v činnosti, In/out řadič se zamkne a čeká na dokončení výpočtu, převezme vypočtená data, a až poté spustí příjem dalších dat. Tímto je zajištěna konzistence dat na výstupu, Explicitní markety následují vždy implicitní data která je vyvolala. Implicit cache V implicit cache se shromažďují vždy dvě strany z každé market side implicitního marketu. Updaty jsou jednoznačně identifikovány pomocí market ID. Implicit cache je také schopná zjistit zda byl daný market od počátku činnosti jednotky vůbec updatován - tj. zda je připraven na výpočet. Výpočetní jádro Výpočetní jádro je obecná jednotka, mající za vstup implicitní markety a vypočítávající z nich markety explicitní. Jednotka bude autonomní, tzn. není 34

2.5. Návrh výpočetního jádra potřeba žádné vnější řízení a v jejím rozhraní jsou zahrnuty signály signalizující její připravenost, nebo stav probíhajícího výpočtu. Vyčítací jednotka Vyčítací jednotka komunikuje s výpočetním jádrem/jádry, a z jejich výstupů je schopná sestavit validní zprávy dle specifikace, a odeslat je na výstup prostřednictvím in/out řadiče. Řadič výpočetních jednotek Jedna z nejdůležitějších částí celého designu, kontroluje Implicit cache na nachystané implicit markety. Jsou-li v Implicit cache připravena data pro alespoň jeden výpočet, řadič zajistí předání vstupních parametrů do výpočetního jádra a jeho spuštění. 2.5 Návrh výpočetního jádra V zadáním práce byla realizace výpočtu impliedu spread IN. Vlastní výpočet probíhá ve výpočetním jádru, které který dokáže z dat dvou vstupních marketů A, B vypočítat implied spread C = A - B. Nejdříve si představíme vstupy a výstupy jednotky. 2.5.1 Vstupní a výstupní proměnné Na obrázku 2.5 jsou znázorněny všechny vstupní a výstupní proměnné. Názvy proměnných jsou označeny tučným písmem. Jmenná konvence registrů je následující: písmeno 1.. P/Q = cena(p) / množství(q) písmeno 2.. A/B/C = A, B je označení vstupních proměnných, C je výstupní proměnná. číslo.. číslování viz obrázek 2.5 - dle indexu. Na obrázku je znázorněn vztah mezi indexem na žebříčku a názvy proměnných. 2.5.2 Algoritmus výpočtu První část algoritmu proběhne vždy nezávisle na vstupních proměnných, a to výpočet Pc2 = Pa2 - Pb3 a Pc3 = Pa3 - Pb2. Další výpočty jsou již podmíněné vstupními hodnotami a proto bude jejich výpočet jasnější z diagramu 2.6. Na něm je zobrazena pouze polovina žebříčku (!) - a to výpočet Qc1, Qc2 a Pc1. Proměnné Qc4. Qc3 a Pc4 se vypočtou analogickým postupem. 35

2. Analýza a návrh Obrázek 2.5: Vstupní a výstupní proměnné algoritmu Obrázek 2.6: Algoritmus výpočtu 36

2.6. Shrnutí kapitoly typ operace délka trvání výskyt celkem load / store 1 takt[13] 24x 24 taktů celočíselné porovnávání 1 takt max 4x 4 takty celočíselné odčítání 1 takt max 2x 2 takty FP odčítání 7 takt[1] 4x 28 taktů celkový odhad doby trvání 58 taktů Tabulka 2.3: Výskyt instrukcí a jejich očekávané trvání 2.5.3 Operace prováděné během výpočtu, jejich četnost a předpokládaná časová náročnost Budeme-li počítat nejhorší možný případ - řetězení všech operací za sebe bez jakékoliv paralelizace, bude celý výpočet trvat 58 taktů. Více v tabulce 2.3 Ze simulace v Javě víme, že ještě délka výpočtu do 100000 taktů je ještě bezpečná. V daném počtu 100 000 taktů stihneme 2000 výpočtů spreadu, což je dostatečný počet. Pokusíme se ovšem využít toho, že výpočet ceny a množství je naprosto nezávislý a musí probíhat na různých jednotkách (celočíselná vs. floating point). Tohoto přirozeného paralelismu využijeme. 2.6 Shrnutí kapitoly Ověřili jsme si, že zadání je teoreticky realizovatelné, analyzovali jsme procesy v jednotce, a navrhli jsme strukturu jednotky na úrovni bloků a specifikovali jejich chování. 37

KAPITOLA 3 Realizace Návrh proběhl v jazyce VHDL ve vývojovém prostředí Xilinx ISE. Cílovou platformou pro implementaci zařízení je Virtex 6, HX380T-3, nicméně z důvodu licenčního omezení ISE byla syntéza prováděna pro VLX75T-3. Jako syntézní nástroj byl zvolen XST, který je součástí vývojového prostředí Xilinx ISE. Při návrhu nebylo použito knihovních prvků od fy Xilinx, takže design by měl být přenositelný i na platformy jiných výrobců. 3.1 Struktura implementace U každého bloku je dokumentováno jeho rozhraní a funkcionalita. Ve zdrojovém kódu nejsou zobrazovány komentáře. Pro zobrazení VHDL kódu je použita výborná Latex package Listings [2]. Komentovány jsou jen důležité signály rozhraní. 3.1.1 top Je vrchní jednotkou celého návrhu. Implementuje logiku přijímání a přeposílání datových zpráv a propojuje všechny ostatní jednotky. 3.1.1.1 Interface ENTITY top IS PORT( c l k : IN STD_LOGIC; r s t : IN STD_LOGIC; timestamp : IN STD_LOGIC_VECTOR(TSWIDTH 1 DOWNTO 0 ) ; infifo_empty : IN STD_LOGIC; 39

3. Realizace Port clk rst timestamp infifo_empty infifo_rd_enable infifo_rd_data outfifo_wr_enable outfifo_wr_data outfifo_full Význam hodinový signál @250Mhz reset jednotky aktuální čas, potřeba pro generování nových datových zpráv vstupní fronta je prázdná clock enable pro čtení vstupní fronty výstupní data ze vstupní fronty clock enable pro zápis výstupní fronty vstupní data do výstupní fronty výstupní fronta je plná Tabulka 3.1: rozhraní jednotky top i n f i f o _ r d _ e n a b l e : OUT STD_LOGIC; infifo_rd_data : IN STD_LOGIC_VECTOR(MSGWIDTH 1 DOWNTO 0 ) ; outfifo_wr_enable : OUT STD_LOGIC; outfifo_ wr_ data : OUT STD_LOGIC_VECTOR(MSGWIDTH 1 DOWNTO 0 ) ; o u t f i f o _ f u l l : IN STD_LOGIC ) ; END top ; Komunikace odpovídá specifikacím z předchozí kapitoly. Propojení fronty je synchronní se signálem clk, platná data nám tedy fronta vystaví po nastavení infifo_rd_enable a na náběžnou hranu signálu clk. Stejně tak výstupní fronta zapíše data při nastaveném signálu outfifo_wr_enable a náběžné hraně clk. Komunikaci s okolím řídí konečný stavový automat dle přechodového diagramu 3.1. Dle coding style specifikací zadavatele byla použita dvojprocesová implementace stavového automatu. Po načtení dat z vstupní fronty je market ID převedeno pomocí id_to_addr_converter na adresu v RAM, a jsou na ni uloženy updaty ceny i množství. Automat přejde do stavu "locked"a který spustí mikrokódový řadič výpočetní jednotky. Ve stavu locked zůstane po celou dobu trvání výpočtů explicit updatů. Po dokončení výpočtu běží cyklus od začátku. 3.1.2 id_to_addr_converter Tato jednotka zajišťuje mapování ID marketu, které může být obecně jakékoliv 8bitové číslo, na fyzickou adresu v implicit_cache. V současné verzi překlad neprobíhá, protože není předem známé množství marketů se kterými bude jednotka počítat. Když bude tato hodnota známa, 40

3.1. Struktura implementace Obrázek 3.1: Konečný stavový automat řídící I/O operace 41

3. Realizace bude možné omezit kapacitu explicit_cache a v id_to_addr_converter provést mapování bitů tak, aby docházelo k přístupům pouze do platného adresního prostoru. Jednotka je umístěna mezi vstupem a cache, dále mezi microcode_driver a cache. 3.1.3 implicit_cache Zde se cachují došlé updaty. Od každého marketu, jednoznačně určeného adresou, se ukládají dva indexy obsahující cenu a množství. Zápis do implicit_cache probíhá po jednotlivých 32bitových datových slovech, naopak výstup je 256bitový a obsahuje všechny dostupné= updaty jednoho marketu. V implicit_cache tedy probíhá jakási deserializace vstupních dat. V modulu je také vestavěna ochrana proti čtení neinicializované paměti. Dokud se poprvé nezapíše na obě market side, při nastavení adresy daného marketu port r_flag tuto situaci signalizuje nulovou hodnotou. 3.1.4 microcode_driver Microcode_driver řídí výpočetní jednotku/y definuje jejich vstupní a výstupní data. Tuto jednotku bylo možné implementovat pomocí dvojprocesového konečného stavového automatu. Oproti jiným místům v designu v tomto místě může docházet ke změnám. proto bylo přistoupeno k návrhu horizontálního mikrokódového řadiče, u kterého jsou změny algoritmu snáze proveditelné. Význam bitů v mikroinstrukcích je v tabulce 3.2. Strukturálně je mikrořadič navrhnut jako ROM paměť, jejíž část výstupů je vyhrazena pro ovládání signálů, a část je adresou další instrukce. Instrukci v ROM paměti reprezentuje jedno slovo. Implementačně je mikrokód zapsán přímo do VHDL zdrojového kódu a je bohatě okomentován. V závěru kapitoly budu diskutovat případné rozšíření. Podmíněné skoky jsou řešené změnou bitu 1 a 0 adresy následující instrukce(pc+1). Pokud je bity 16-18 nastaven nějaký typ podmíněného skoku, bit 0 adresy další instrukce je pevně nastaven na 1, bit 1 je nastaven podle vstupní podmínky. Přehled všech možných podmíněných skoků je v tabulce 3.3. Skok je tedy řešen přepnutím multiplexeru. V hodnotě 000 je jako příští instrukce zvolena část slova v paměti. 42 Po resetu je PC registr nastaven na adresu 0000 (HEX).

3.1. Struktura implementace Bity mikroinstrukce Význam 0-15 adresa následující instrukce (PC+1) 16-18 výběr podmíněného skoku 19-26 id v implicit_cache 27 uložení operandu A do vybrané výpočetní jednotky 28 uložení operandu B do vybrané výpočetní jednotky 29 uložení market_id do vybrané výpočetní jednotky 30 start vybrané výpočetní jednotky 31 odemčení TOP fsm (=obnovení načítání ze vstupního fifa) 32-39 nevyužité 40-47 výběr výpočetní jednotky 48-55 nastavení market_id u aktuální výpočetní jednotky Tabulka 3.2: Význam jednotlivých bitů mikrokódu Bity 18,17,16 v mikroinstrukci Bit 1 v PC+1 000 odpovídá PC+1 v mikroinstrukci 001 1, pokud jsou data v implicit_cache připravena 010 1, pokud vyčítací jednotka dokončila svoji práci 011 1, pokud na dané adrese v explicit_memory jsou inicializovaná data ostatní nevyužito Tabulka 3.3: Možnosti podmíněného skoku 3.1.5 reader_unit Tato jednotka kontroluje připojený výpočetní jádra (v DP pouze spread_unit) jestli nemají nějaká data připravená k odeslání. Jestliže mají, data jsou serializována a poslána na výstupní fifo. Tato serializace probíhá v lock stavu hlavního fsm. Samotná jednotka v sobě obsahuje také konečný stavový automat, nicméně není zajímavý a jeho přechody pouze periodicky vyčítají výstupní registry výpočetního jádra. 3.1.6 spread_unit Jednotka spread_unit vypočítá z předaných parametrů hodnotu implied_in do spreadu. Požadavky na spread_unit Algoritmus výpočtu implieds spočívá pouze v následujících operacích: 43

3. Realizace odčítání INT čísel a uložení na výstup porovnání INT čísel odčítání FP čísel a uložení na výstup načtení čísla ze vstupu a jeho uložení na výstup + větvení algoritmu, cykly Diskuse možností návrhu Přes relativně malý počet požadovaných operací jsem zvažoval implementaci několika způsoby: Síťová architektura - v případě požadované rekonfigurovatelnosti pravidelná, jinak nepravidelná přímá síť 2, kde uzly by byly jednotlivé aritmetické jednotky, přepínače pak větvení a předávání hodnot v pipeline) Využití existujícího softcore mikroprocesoru 3 Navržení architektury na míru využívající více či méně univerzálních registrů a výpočetních jednotek. Síťová architektura Mezi klady této varianty patří vysoký výkon, mezi zápory mnoho zabraného místa. Softcore mikroprocesor - Picoblaze Picoblaze je embedded mikrokontrolér, uvolněný jako Open-Source. Pro PicoBlaze existuje assembler jak pro Windows, tak linuxové prostředí. Nicméně dle dokumentace [12] je aritmetická jednotka pouze 1 Byte široká, takže tento mikrokontrolér by šlo použít pouze jako řídící jednotku pro FPU jádro. Proti tomuto využití však hovoří zpracování instrukcí po dvou taktech bez pipeliningu. Vlastní architektura řízená FSM FSM se obecně vyznačují vysokou rychlostí při běhu, avšak pomalou implementací algoritmu při návrhu. Výhody vlastní architektury jsou zejména maximální přizpůsobení řešenému problému a také možnost snadné paralelizace bez zbytečného nárůstu zabrané plochy. Zvolena byla poslední možnost, a to návrh architektury na míru. 2 Přímá síť je taková síť, u které je každý přepínač připojen alespoň k jednomu uzlu 3 Procesor implementovaný pomocí syntézy v programovatelné součástce 44

3.1. Struktura implementace Obrázek 3.2: Architektura INT části Návrh architektury spread_unit Vzhledem k požadovaným vlastnostem byla jednotka rozdělena na FP a INT část. Mezi těmito dvěma segmenty nedochází k výměně dat, pouze řídících informací. Navržena tedy byla struktura z obr 3.2 a 3.3. Data jsou přivedena paralelně na vstupní porty, vyčítána mohou být také paralelně. Je rozdělena do dvou samostatných částí, celočíselné (INT), a části pro zpracování dat v plovoucí (FP) řádové čárce. INT část obsahuje vstupní registry, výstupní registry, komparátor a odčítačku, FP část obsahuje pouze registry a odčítačku. Dalších jednotek není potřeba. Nepřítomnost registrů na výstupu FP odčítačky je způsobena tím, že tyto jsou přímo součástí odčítačky. Na nákresu jsou pro přehlednost zobrazeny jen datové cesty, nikoliv řídící. Šířka sběrnic je naznačena. FP i INT část je řízena dvěma automaty. Algoritmus je na obrázcích 3.4 a 3.5. Oba jsou synchronizovány ve třech bodech: Při startu, dokončení porovnání v INT a po dokončení všech výpočtů. Princip synchronizace je na Petriho síti 3.6. Protože výpočet obou stran žebříčku je identický, je po dokončení výpočtu jedné strany automat spuštěn znovu, avšak s nastaveným registrem 45

3. Realizace Obrázek 3.3: Architektura FP části Obrázek 3.4: činnost řídícího automatu v INT části second_run. Tento způsobí, že je zpracovávána druhá polovina žebříčku. Tímto došlo ke zmenšení stavů, ale hlavně ke zpřehlednění kódu automatu. První testovací implementace obsahovala pouze jeden FSM. Tento však obsahoval 107 stavů a i když výsledná posloupnost změn na výstupních signálech byla stejná, případné úpravy automatu vývojářem by byly extrémně nepohodlné. Ze zadání se však přímo nabízí rozdělit řízení stejně, jako jsou rozděleny výkonné jednotky, totiž na FP část a INT část. Díky tomu mohly být vylou- 46

3.1. Struktura implementace Obrázek 3.5: činnost řídícího automatu v FP části čeny stavy, které řídily INT jednotku když FP čeká na latenci odčítačky a obráceně. Čekání na latence tak mohlo být převedeno na pomocný čítač, a došlo k výraznému zjednodušení kódu. Celočíselná odčítačka je triviálně popsaná ve VHDL pomocí paralelního přiřazení, algoritmus výpočtu totiž vylučuje odčítání většího čísla od menšího, a protože se jedná o množství, vždy se jedná o nezáporná čísla. Oproti tomu operandy FP odčítačky nejsou blíže specifikovány, obecně to mohou být jakákoliv FP čísla. Od zadavatele bylo specifikováno, že v designu celého plánovaného zařízení je již FP jednotka naimplementována, pouze pro mé testovací účely jsem tedy použil již hotové FP jádro od Jidana Al-Eryani z opencores.org [1]. Toto jádro podporuje daleko více operací než bylo pro můj návrh potřeba, nepotřebné moduly byly pro úsporu místa a zvýšení syntézy deaktivovány. Není bez zajímavosti, že současná kritická cesta po syntéze vede právě přes tuto odčítačku. Jedním z pokračováních této práce tedy bude vestavění odčítačky od zadavatele a vyhodnocení výsledků nové syntézy. Rozhraní spread unit ENTITY spread_ unit IS PORT( c l k : IN STD_LOGIC; r s t : IN STD_LOGIC; data_in : IN STD_LOGIC_VECTOR ( ( 8 WIDTH) 1 DOWNTO 0 ) ; data_out : OUT STD_LOGIC_VECTOR ( ( 8 WIDTH) 1 DOWNTO 0 ) ; 47

3. Realizace Obrázek 3.6: Petriho síť synchronizace automatů save_a : IN STD_LOGIC; save_b : IN STD_LOGIC; market_id_in : IN STD_LOGIC_VECTOR( 7 DOWNTO 0 ) ; market_id_ce : IN STD_LOGIC; market_id_out : OUT STD_LOGIC_VECTOR( 7 DOWNTO 0 ) ; s t a r t : IN STD_LOGIC; data_ready : OUT STD_LOGIC ) ; END; Vstupními daty jednotky je žebříček marketu A B. Výstupem jednotky jsou implieds do žebříčku A-B. Jednotka komunikuje s explicit_cache pomocí jednoduchého protokolu, který umožňuje nahrání relevantních informací z cache v jednom kroku. Vstup na data_in jsou přivedena zřetězená data od nejvyššího bitu Q1, Q2, Q3, Q4, P1, P2, P3, P4. Každá proměnná má 32 bitů. Je použita notace z 2.5. Je-li při náběžné hraně hodinového signálu aktivní save_a, je tento market považován za operand A, analogický význam má save_b. Vyčítání je řešeno autonomně vyčítací jednotkou, je tedy potřeba jí předat ID marketu, který počítáme. Proto je součástí spread_unit prostý re- 48

3.2. Výsledky syntézy gistr market_id, připojený na příslušně pojmenované vstupy a výstupy, do kterého mikrokódová řídící jednotka uloží ID výstupního marketu. Toto ID bude použito při vytváření zprávy vyčítací jednotkou a bude jí předáno přes market_id_out. Spuštění jednotky provede signál start. Výstupní data jsou připravena při aktivním signálu data_ready a to na portu data_out ve stejně zřetězené podobě, jako na vstupu, tj od nejvyššího bitu Q1, Q2, Q3, Q4, P1, P2, P3, P4. Data jsou na výstupu tak dlouho, dokud nejsou přepsána novým výpočtem. Signál data_ready je aktivní právě jeden hodinový takt. 3.2 Výsledky syntézy Primitive and Black Box Usage: ------------------------------ # BELS : 1821 # GND : 1 # INV : 2 # LUT1 : 24 # LUT2 : 69 # LUT3 : 120 # LUT4 : 179 # LUT5 : 405 # LUT6 : 693 # MUXCY : 135 # MUXF7 : 99 # VCC : 1 # XORCY : 93 # FlipFlops/Latches : 1414 # FD : 333 # FDC : 13 # FDE : 790 # FDR : 13 # FDRE : 265 # RAMS : 8 # RAMB18E1 : 8 # Shift Registers : 7 # SRLC16E : 7 # Clock Buffers : 1 # BUFGP : 1 # IO Buffers : 109 49

3. Realizace # IBUF : 71 # OBUF : 38 Slice Logic Utilization: Number of Slice Registers: 1382 out of 93120 1% Number of Slice LUTs: 1499 out of 46560 3% Number used as Logic: 1492 out of 46560 3% Number used as Memory: 7 out of 16720 0% Number used as SRL: 7 Clock period: 3.954ns (frequency: 252.935MHz) Pozn. jedná se spíše o odhad, syntéza byla prováděna bez UCF souboru. 50

KAPITOLA 4 Testování Během návrhu probíhalo mnoho různých drobných testů. Na závěr byla provedena verifikace celé jednotky, o čemž bude tato kapitola. 4.1 Model Z důvodu neexistence formální specifikace chování jednotky od zadavatele byl jako základ modelu pro testování použit popis algoritmu z druhé kapitoly této práce. Z důvodu dobrých zkušeností s modelováním chování jednotky v jazyce JAVA ve studii proveditelnosti, bylo opět přistoupeno k implementaci modelu v tomto programovacím jazyce. Tentokrát bylo implementováno detailní chování jednotky včetně výpočtů, ukládání do cache apod. Vstup dat je simulován čtením textového souboru, výstup zapisováním do druhého. Stejně jako v HW jednotce jsou data po načtení zkontrolována, zda obsahují zájmové hodnoty (tj. updaty explicitů) a tyto jsou poté buď uloženy do pole, nebo pouze poslány na výstup. Po přijmutí zprávy proběhne sekvenční kontrola pole, zda obsahuje hodnoty potřebné k výpočtu zadaných impliedů, které jsou poté vypočítány a poslány na výstup. 4.2 Zapojení HW do testbenche 4.2.1 Wrapper pro jednotku Ze zadání vyplývá, že jednotka bude pracovat mezi dvěma frontami. Součástí testování tedy bylo zapojení do této kombinace tak, abychom s jednotkou mohli zacházet jako s monolitickým blokem. Výsledný VHDL modul top_wrapper má následující rozhraní: 51

4. Testování ENTITY top_wrapper IS PORT( c l k : IN s t d _ l o g i c ; r e s e t : IN s t d _ l o g i c ; data_in : IN s t d_logic_vector (35 downto 0 ) ; data_out : OUT s t d_logic_vector (35 downto 0 ) ; i n f i f o _ w r i t e _ e n a b l e : IN s t d _ l o g i c ; outfifo_read_enable : IN s t d _ l o g i c ; outfifo_empty : OUT s t d _ l o g i c ) ; END; názvy portů odpovídají jejich významu. Nad tímto modulem už mohly být prováděny testy. Nastavení výstupní a vstupní fronty Dle zadání bude jednotka zapojena mezi dvě fronty. Tyto dvě fronty jsou tedy ve wrapperu zapojeny před, a za jednotku. Použita byla implementace front od zadavatele s těmito změnami ve výchozí konfiguraci: Šířka fronty nastavena na 36 (=šířka slova 32 bitů + 4 bity kontrolní) parametr FALL_THROUGH nastaven jako false Ostatní parametry jsou ponechány ve výchozím stavu. Signály almost_* nejsou využity. Více informací o implementaci front je v interní dokumentaci zadavatele. 4.2.2 Testbench modul Testbench modul tb_top_wrapper nahrává vstupní soubor, a naplní vstupní frontu jednotky. Jednotka samotná již sama detekuje neprázdnou vstupní frontu a začne zpracovávat vstupní data. Ta jsou odesílána na výstup, kam je připojena další fronta, která je v testbench modulu vyčítána do výstupního souboru. Pro návrh funkcionality čtení souborů byly použité lehce upravené funkce z [5]. Tyto funkce provádí převod mezi datovým typem string a proměnou typu std_logic_vector. 4.3 Generátor stimulů Další otázkou, kterou bylo nutné vyřešit byly vhodné stimuly pro test. Pro tento účel byl navržen generátor stimulů, který dokáže vygenerovat vstupní soubor obsahující fingované vstupní zprávy. 52

4.4. Průběh testu, shrnutí testování 4.3.1 Code coverage Z hlediska code coverage testů můžeme design rozdělit do dvou částí: Obslužná logika Chod obslužné logiky je závislý na vstupních datech pouze omezeně, a to konkrétně na počtu slov v příchozí zprávě. Nastávají tři možnosti: počet updatů ve zprávě = 2 - stimuly v souboru input.txt počet updatů ve zprávě < 2 - stimuly v souboru input1,txt počet updatů ve zprávě > 2 - stimuly v souboru input3.txt Spread_unit Další závislost na vstupních datech je v spread_unit, algoritmus se větví na základě poměrů následujících vstupních dat: (QA 2, QB 3 ) (QA 3, QB 2 ) Varianty těchto poměrů jsou testovány vždy prvními 12 stimuly v testu, které jsou na toto zaměřené. FPU sub Součástí designu je i FPU odčítačka od třetí strany. Protože výhledově bude v designu nahrazena odčítačkou od zadavatele, nebyla tato odčítačka plně otestována. 4.4 Průběh testu, shrnutí testování Vlastní testování probíhalo vygenerováním stimulů pomocí generátoru. Dále bylo provedeno jejich zpracování JAVA modelem. Samotná jednotka byla simulována v nástroji ISIM, který je součástí Xilinx ISE a probíhá spuštěním simulátoru nad souborem tb_top_wrapper, který načte stimuly z v kódu specifikovaného souboru a výsledky zapíše do souboru výstupního. Názvy souborů je možné měnit v kódu testbenche. Vzniklá data, tj. výstupní soubor z modelu a výstupní soubor z testbenche již lze triviálně zpracovat pomocí unixové utility diff. Pokud test proběhl správně, výstupní data z modelu a výstupní data z testbenche se nemění. 53

KAPITOLA 5 Diskuze rozšíření stávajícího řešení Během návrhu byly objeveny další možnosti vylepšení designu jednotky, které však přesahují rámec zadání a většinou by vyžadovaly úpravu specifikací komunikace jednotky s okolím. 5.1 Převedení ROM pamětí v jednotkách na RAM V designu se dvakrát používá analogie ROM paměti - zejména v id_to_addr_converter, kde každému ID marketu je přiděleno právě jedna adresa. Rozšíření by mohlo spočívat ve vytvoření (B)RAM paměti, které by se inicializovala při startu jednotky servisní zprávou. Mezi výhodou tohoto řešení by bylo odstranění nutnosti nové syntézy jednotky při změnách vstupních dat, naopak mezi nevýhody můžeme řadit nutnost inicializace jednotky po každém resetu. Programovatelná BRAM paměť by byla vhodná i pro microcode_driver, řídící výpočetní jádra. Výhody a nevýhody zůstávají stejné. 5.2 Převedení FSM ve výpočetním jádře na mikrokódový řadič Nyní je jednotka počítající spread IN pevně zadrátovaná pomocí dvou dvojprocesových konečných automatů. Alternativou k tomuto řešení by bylo využití mikrokódového řadiče, nebo řadičů. Výhodou řešení pomocí FSM je větší volnost pro syntézu, která si sama může zvolit optimální kódování stavů, atd., zatímco při využití mikrokódového řadiče jsou přechody a výstupy syntetizovány dopředu, a budí se až na základě obsahu ROM/RAM paměti. 55