Ethernetový tester pro vysokorychlostní sítě

České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů

Diplomová práce

Ethernetový tester pro vysokorychlostní sítě Bc. Pavel Benáček

Vedoucí práce: Ing. Štěpán Friedl

7. května 2012

Poděkování Rád bych poděkoval svému vedoucímu panu Ing. Štěpánu Friedlovi za cenné připomínky, rady a nápady v průběhu vzniku této diplomové práce. Dále bych chtěl poděkovat lidem z projektu Liberouter, kteří mi umožnili vytvořit tuto práci. Velice rovněž děkuji všem lidem, kteří mě podporovali v dokončení této práce.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené.

V Praze dne 7. května 2012

..................... vii

České vysoké učení technické v Praze Fakulta informačních technologií c

2012 Pavel Benáč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 Pavel Benáček. Ethernetový tester pro vysokorychlostní sítě: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract This thesis shows usage of COMBO-LXT card as an Ethernet tester for speeds above 10 Gb/s. The work describes basics of the Ethernet standard (mainly 802.3ae - 10 Gb/s and 802.3ba - 40/100 Gb/s), an analytical part of the tester design, its implementation for 10 Gb/s network and a discussion about necessary changes for 40/100 Gb/s bitrates. The COMBO-LXT card (containing FPGA Virtex-5) and adapted NetCOPE project were used as the main implementation plafrom. Keywords FPGA, COMBO-LXT, Virtex-5, Ethernet 10 Gb/s, Ethernet 40/100 Gb/s, XGMII, XLGMII

Abstrakt Tato diplomová práce se zabývá využitím COMBO-LXT karty jako ethernetového testeru pro rychlosti vyšší jak 10 Gb/s. Práce diskutuje základy standardu Ethernet (hlavně 802.3ae - 10 Gb/s a 802.3ba - 40/100 Gb/s), analytickou část návrhu testeru, popis implementace pro 10 Gb/s a diskuzi změn pro vyšší rychlosti 40/100 Gb/s. Jako hlavní implementační platforma je využita COMBO-LXT karta (s obvodem FPGA Virtex-5) a upravený projekt NetCOPE. Klíčová slova FPGA, COMBO-LXT, Virtex-5, Ethernet 10 Gb/s, Ethernet 40/100 Gb/s, XGMII, XLGMII

ix

Obsah Úvod

1

1 Analýza a návrh řešení 1.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Architektura Ethernetu . . . . . . . . . . . 1.1.2 XGMII . . . . . . . . . . . . . . . . . . . . 1.1.3 XLGMII/CGMII . . . . . . . . . . . . . . . 1.2 Rodina COMBO karet . . . . . . . . . . . . . . . . 1.3 NetCOPE . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 FrameLink . . . . . . . . . . . . . . . . . . 1.3.2 FrameLinkUnaligned . . . . . . . . . . . . . 1.3.3 MI32 . . . . . . . . . . . . . . . . . . . . . . 1.4 Návrh řešení . . . . . . . . . . . . . . . . . . . . . 1.4.1 Základní návrh zpracování toku a statistik . 1.4.2 Odesílání paketů v definovaných okamžicích 1.4.3 Opakování paketů . . . . . . . . . . . . . . 1.4.4 Analýza času průchodu sítí . . . . . . . . . 1.4.5 Analýza pořadí a ztracených paketů . . . . 1.4.6 Základní statistiky . . . . . . . . . . . . . . 1.4.7 Histogramy . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

3 3 3 7 8 8 10 12 14 15 16 18 18 19 20 21 21 24

2 Realizace 2.1 Návrh testeru pro 10 Gb/s Ethernet . . . . . . 2.1.1 Opakováné odesílání paketu . . . . . . . 2.1.2 Odesílání paketů v přesných okamžicích 2.1.3 Značkování paketů . . . . . . . . . . . . 2.1.4 Analýza pořadí a zpoždění . . . . . . . 2.1.5 Zahazování paketů . . . . . . . . . . . . 2.1.6 Vytváření statistik . . . . . . . . . . . . 2.2 Změny pro rychlosti 40 Gb/s a 100 Gb/s . . . . 2.2.1 Opakování paketů . . . . . . . . . . . . 2.2.2 Výstup na síť . . . . . . . . . . . . . . . 2.2.3 Vstup ze sítě . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

27 27 29 30 31 32 34 35 36 36 38 41

xi

. . . . . . . . . . .

. . . . . . . . . . .

3 Výsledky a testování 3.1 Testování . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Dosažené výsledky . . . . . . . . . . . . . . . . . . . 3.2.1 Ztrátovost paketů . . . . . . . . . . . . . . . 3.2.2 Měření IFG . . . . . . . . . . . . . . . . . . . 3.2.3 Ověřování funkce histogramů . . . . . . . . . 3.2.4 Další statistiky . . . . . . . . . . . . . . . . . 3.2.5 Testování vkládání hlavičky do síťového toku 3.2.6 Zpoždění paketů . . . . . . . . . . . . . . . . 3.2.7 Generování datového toku . . . . . . . . . . . 3.2.8 Odesílání paketů v definovaných intervalech . 3.3 Celkové hodnocení testů . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

43 43 45 45 46 46 48 49 49 50 50 52

Závěr

53

Literatura

55

A Seznam použitých zkratek

57

B Překlad firmwaru a použití 59 B.1 Překlad firmwaru na vývojové infrastruktuře projektu Liberouter 59 B.2 Použití firmwaru . . . . . . . . . . . . . . . . . . . . . . . . . . 59 C Obsah přiloženého CD

61

xii

Seznam obrázků 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13

1.15 1.16 1.17 1.18

ISO/OSI model a základní umístění vrstev Ethernetu . . . . . . . Ethernetový rámec . . . . . . . . . . . . . . . . . . . . . . . . . . . Architektrura Ethernetu . . . . . . . . . . . . . . . . . . . . . . . . Použítí XAUI a XGXS . . . . . . . . . . . . . . . . . . . . . . . . . Datový tok XGMII . . . . . . . . . . . . . . . . . . . . . . . . . . . Karta COMBOv2 LXT155-10G2 (převzato z [4]) . . . . . . . . . . Základní struktura FPGA . . . . . . . . . . . . . . . . . . . . . . . Základní struktura CLB . . . . . . . . . . . . . . . . . . . . . . . . Základní struktura NetCOPE (převzato z [8]) . . . . . . . . . . . . Komunikace na FrameLink protokolu (převzato z [9]) . . . . . . . . Zápis přes MI32 (převzato z [11]) . . . . . . . . . . . . . . . . . . . Čtení přes MI32 (převzato z [11]) . . . . . . . . . . . . . . . . . . . Schématické znázornění průchodu paketu z SW na výstup COMBO karty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schématické znázornění průchodu paketu ze vstupu COMBO karty do SW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formát hlavičky pro nastavení časového zpoždění . . . . . . . . . . Formát hlavičky vkládané do datového toku . . . . . . . . . . . . . Znázornění pozice vložené hlavičky do datového toku paketu . . . Ukázky IFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12

Blokové schéma projektu COMET . . . . . . . . . . . . . . Blokové schéma komponenty FL_REPEATER . . . . . . . Blokové schéma komponenty pro odesílání dle čas dle času . Blokové schéma komponenty PACKET_CHECKER_SEND Blokové schéma komponenty PACKET_CHECKER_REC Blokové schéma komponenty HEAD_EXTRACT . . . . . . Blokové schéma komponenty FRAME_DISCARD . . . . . Blokové schéma pro měření IFG . . . . . . . . . . . . . . . Blokové schéma komponenty HIST_UNIT . . . . . . . . . . Idea realizace opakování . . . . . . . . . . . . . . . . . . . . Návrh realizace obvodu pro kódování do XLGMII . . . . . . Návrh realizace výstupní síťové paměti pro XLGMII . . . .

1.14

xiii

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

4 5 5 6 7 8 9 10 11 14 16 17 18 18 19 20 21 23 28 29 30 31 32 33 34 35 37 37 40 41

3.1 3.2 3.3 3.4

Ukázka GUI pro Spirent AX/4000 . . . . . . . . . . . . . . . . . . Ukázka HTML stránky generované aplikací comstat (převzato z [17]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zpracovaný počet paketů za sekundu na 10Gb/s lince . . . . . . . Ukázka vytvořené mezery na XGMII . . . . . . . . . . . . . . . . .

xiv

44 45 48 51

Seznam tabulek 1.1 1.2 1.3 1.4 1.5 1.6

Názvy MII . . . . . . . . . . Ukázky kódování v PCS . . . Signály FrameLinku . . . . . Signály FrameLinkUnaligned Signály MI32 sběrnice . . . . Základní statistiky . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

6 6 13 15 16 23

3.1 3.2 3.3 3.4 3.5

Spotřeba zdrojů (nástroj XST 13.1;speed grade -2) Výsledky testu ztrátovosti paketů . . . . . . . . . . Nastavení parametrů paketů síťového analyzátoru . Seznam velikostí jednotlivých částí . . . . . . . . . Nastavení rozestupů testovacích dat . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

46 46 48 50 51

xv

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Úvod Moderní síťe nás v současné době provází každý den našeho života. S postupem času se na tento komunikační prostředek kladou větší nároky na stabilitu, bezpečnost, dostupnost a v neposlední řadě také na rychlost přenosové linky. Každá aplikace navíc potřebuje mít splněnu vlastnost komunikační sítě, která závisí na případu použití. V dnešní době se nejvíce setkáváme s mobilními a počítačovými sítěmi. Druhý jmenovaný zástupce je velice dobře finančne dostupný pro domácí i podnikové použití a jeho cena je nejvíce závislá na maximální možné přenosové rychlosti. V domácím prostředí se nejčastěji setkáme s datovými sítěmi, jejichž rychlost se pohybuje kolem 100 Mbit u kabelové verze a 54 Mbit u bezdrátové verze. Poskytovatelé internetových připojení však na své sítě kladou větší požadavky, kterými je zejména vysoká rychlost na páteřních spojích. Typická rychlost se v dnešní době pohybuje kolem 10 Gb/s, kdy se navíc dají rychlosti linek spojovat a vytvoří se tak velice výkonný datový propoj (tato technika se nazývá Channel Bonding). Tento propoj je pak schopen pokrýt i velké nároky v případě videotelefonie nebo datového přenosu k serverům do datového centra. Z výše uvedených důvodů je testování těchto komunikačních cest velice důležité a je také hlavním impulzem pro tvorbu zařízení, která jsou schopna měřit a vizualizovat různorodé parametry sítí. Mezi nejrozšířenější technologii patří Ethernet, jehož první specifikace vznikla v roce 1982, kdy podporoval dnes nedostačující rychlost 10 Mbit a jako přenosové médium bylo využito souosého (koaxiálního) kabelu. S postupem času vznikaly nové specifikace, kde zejména docházelo k narůstání komunikační rychlosti, ale i k výměně fyzického přenosového média. V současné době se za standard považuje rychlost 1 Gb/s na uživatelských stanicích a 10 Gb/s pro páteřní přenosové trasy. Na těchto hlavních linkách se jako komunikační médium používá optické vlákno, které má velice výhodné vlastnosti (vysoká přenosová rychlost, vysoká bezpečnost, žádné vyzařování,atd.). V současné době je 40/100 Gb/s Ethernet na vzestupu. V rámci organizace CESNET vznikl v roce 2003 projekt Liberouter, který se zabýval využitím programovatélného hardwaru v oblasti vysokorychlostních sítí. Velkou výhodou tohoto přístupu je zejména velká schopnost paralelismu, která se zde dá využít pro zpracování vysokých datových toků. V rámci projektu také vznikla rodina COMBO karet, které využívají obvodů FPGA. Tato hardwarově akcelerované zařízení poskytují dostatečno granu1

Úvod laritu na úrovni hradel a registrů, díky kterým je možné realizovat pro daný problém speciální strukturu, a tak dosáhnout maximálního možného výkonu. Pro popis hardwaru je využito jazyka VHDL, který byl jako standard specifikován v roce 1987. V průběhu práce s COMBO kartami se ukázalo, že by bylo výhodné sesbírat všechny dostupné informace na jedno místo a následně provádět jejich vizualizaci. Tímto vznikl nápad na projekt COMET, který využívá jako svůj základ výsledek projektu NetCOPE (architektonický základ firmwaru síťové karty). Výsledkem této diplomové práce by měla být implementace takového testeru, který by využíval karty COMBOv2. Mezi základní funkce by měl patřit sběr informací a generování testovacího provozu, který by měl umožňovat analýzu času přenosu paketu a pořadí. COMET vznikl z předcházejícího projektu, jehož výsledkem bylo zařízení pro odesílání paketů dle časovové značky. Samotný projekt Liberouter byl ukončen v roce 2010. Práci jsem rozdělil do tří základních kapitol. V první kapitole nazvané Analýza a návrh se zabývám popisem problému, analýze jednotlivých případů a v neposlední řadě také specifikování vlastností, které musí jednotlivé bloky podporovat. Nedílnou součástí této kapitoly je také základní popis technologie Ethernet. A to jak 10 Gb/s, tak i 40/100 Gb/s verze. Druhá kapitola je věnována realizaci testeru pro rychlosti 10 Gb/s s popisem implementace jednotlivých bloků. Závěr této kapitoly jsem věnoval diskuzi pro rychlosti 40/100 Gb/s. Třetí kapitola je pak věnována výsledkům, kterých bylo dosaženo během testování. Součástí této kapitoly je i základní popis softwarového prostředí, které bylo pro testování využito.

2

Kapitola

Analýza a návrh řešení Zákony života nám ukládají vyzkoušet všechny možné varianty, abychom se stejně nakonec vrátili k té první. Zdeněk Jirotka, Saturnin

Při návrhu jsem musel nastudovat cílovou implementační platformu. V rámci Liberouteru se k tomuto účelu používá používá platformu NetCOPE, o kterém se zmíním v následující kapitole. Zároveň se zde zmíním o základech standardu Ethernet, které budou v rámci této analýzy potřeba. V další sekci ohledně návrhu rozeberu řešení pro implementaci testeru pro 10 Gb/s.

1.1

Ethernet

starndard Ethernetu byl poprvé definován v roce 1982, kdy Ethernet podporoval rychlost 10 Mbit. V pozdějších dobách byl rozšířen pro podporu rychlosti 100 Mbit (standard 802.3u - rok 1995), 1 Gb/s (standard 802.3ab - rok 1999), 10 Gb/s (standard 802.3ae - rok 2002) a 40/100 Gb/s (standard 802.3ba - rok 2010). Jedná se o nejvíce používanou technologii pro lokální sítě (LAN), ale díky její popularitě se dostala i do metropolitních sítí (MAN). Mezi hlavní výhody patří jednoduchá rozšiřitelnost, cenová dostupnost této technologie a zejména relativně snadné nasazení.

1.1.1

Architektura Ethernetu

Pro účely standardizace byl vypracován takzvaný referenční model ISO/OSI, který se používá jako názorný příklad řešení komunikace v počítačových sítích. Jednotlivé vrstvy jsou na sobě nezávislé, díky čemuž se dají jednodušeji nahrazovat. ISO/OSI model se skládá ze sedmi vrstev. Tento koncept je znázorněn na obrázku 1.1.Pro náš případ je nejzajímavější vrstva číslo jedna (fyzická) 3

1

1. Analýza a návrh řešení

Ethernet

a dva (datová). Tyto dvě vrstvy specifikují standardy IEEE. Ostatní vrstvy jsou již nezávislé na této specifikaci. Například třetí vrstva (síťová) se stará o směrování a adresování v síti. Nejznámější protokol který pracuje na této vrstvě je protokol IP. Na čtvrté vrstvě (transportní) je to dvojice protokolů UDP/TCP. Díky této koncepci je možné tyto protokoly používat i na jiné technologii než je Ethernet. L7

Application

L6

Presentation

L5

Session

L4

Transport

L3

Network

L2

Data link

L1

Physiscal

MAC RECONCILIATION PCS,PMA,PMD

Obrázek 1.1: ISO/OSI model a základní umístění vrstev Ethernetu Data jsou na druhé vrstvě zabalena do takzvaného rámce (anglicky označovaného jako frame). Jeho základní formát je uveden na obrázku 1.2. Preambule se skládá ze dvou částí. První částí je synchronizační struktura (alternující 0 a 1), který slouží zařízení pro detekci začínajícího rámce. Druhou částí je takzvaný SFD (Start of frame delimiter), který slouží pro ukončení synchronizační struktury a samotnému označení začátku dat paketu. Vytvoření této popsané struktury je hlavním úkolem MAC (Media Access Control) vrstvy, která se v ISO/OSI modelu nachází na L2. Minimální možná velikost základního Ethernetového rámce (bez volitelné VLAN části) je rovna velikosti 64 bytů. Maximální velikost paketu je pak rovna hodnotě 1518 bytů, která se jinak označuje jako MTU (Maximum Transmission Unit). Postupem času se však objevily i takzvané Jumbo Ethernet Frames, jejichž hodnota se obvykle pohybuje na velikosti 9000 bytů. Na této úrovni je využíván druh komunikace, který využívá adresace a MAC adres o velikosti 48 bitů. Tyto adresy by měly být v rámci světa zcela unikátní a zapisují se v hexadecimálním formátu, kde jsou jednotlivé oktety odděleny dvojtečkou (například 1c:6f:65:5c:fc:42). První tři oktety jsou přiřazeny výrobci síťových zařízení jako prefix, kterým musí začínat každá MAC adresa. Tento prefix se nazývá Organizationally Unique Identifier (ve zkratce OUI) a je vydáván organizací IANA (Internet Assigned Numbers Authority). Hodnotu dalších tří oktetů poté využívá výrobce dle svého uvážení. 4

1.1. Ethernet Preamble 8B

S F D

Dest. MAC 6B

Sour. MAC 6B

Ether. type 2B

Payload 46-1500B

CRC 4B

802.1Q Tag(VLAN) 4B

Obrázek 1.2: Ethernetový rámec

Na obrázku 1.3 je znázorněna základní architektura technologie Ethernet. Je zde názorně naznačen vztah mezi fyzickou (L1) vrstvou a vyšší datovou vrstvou, do které patří právě již zmiňovaná MAC. Samotná fyzická vrstva je rozdělena do podvrstev. Architektonická struktura je stejná již od standardu, který definoval Ethernet o rychlosti 100Mb/s. Jednotlivým vrstvám se budu podrobněji věnovat v následujícím textu. DATA MAC

Fyzická vrstva (L1)

RECONCILIATION MII PCS PMA PMD MDI MEDIUM

Obrázek 1.3: Architektrura Ethernetu Podvrstva, která se anglicky označuje jako Reconciliation, slouží k propojení fyzické (L1) a datové (L2) vrstvy. Vstupem do L1 je Ethernetový rámec, jehož struktura již byla v předchozím textu popsána. Do spodních podvrstev je propojení realizováno pomocí takzvaného MII (Media Independent Interface), který slouží jako nezávislé rozhraní pro komunikaci. Názvy MII v jednotlivých standardech jsou uvedeny v tabulce 1.1. Později bude v textu podrobněji rozebrán formát MII toku pro případ 10 Gb/s a 40/100 Gb/s. Pro potřeby snadnějšího návrhu plošných spojů je přímo ve standardu, pro 10 Gb/s a vyšší, zakotveno rozhraní, které umožní snížit počet vodičů na desce. Případ použití pro 10 Gb/s Ethernet je možné vidět na obrázku 1.4. Sběrnice je realizována pomocí čtyř párů diferenciálních signálů (pro každý směr), díky čemuž je možné eliminovat přeslechy a rušení jednotlivých linek. Blok s označením XGXS (XGMII Extender Sublayer) zde pak slouží pro převod XGMII na XAUI (Extension interface) a naopak. 5

1. Analýza a návrh řešení Rychlost 100 Mb/s 1 Gb/s 10 Gb/s 40 Gb/s 100 Gb/s

Název MII MII GMII XGMII XLGMII CGMII

IEEE standard 802.3u 802.3ab 802.3ae 802.3ba 802.3ba

Tabulka 1.1: Názvy MII PCS,PMA,PMD

RECONCILIATION XGMII

XGXS

XAUI

XGXS

XGMII

Přenos po desce

Obrázek 1.4: Použítí XAUI a XGXS Rychlost 100 Mb/s 1 Gb/s 10 Gb/s 40 Gb/s 100 Gb/s

Kódování 4B/5B 8B/10B 64B/66B (10GBASE-R), 8B/10B (10GBASE-LX4) 64B/66B 64B/66B Tabulka 1.2: Ukázky kódování v PCS

PCS (Physical Coding Sublayer) podvrstva má za úkol kódování/dekódování dat z/do MII. V této vrstvě se provádí ještě kódování, které má za úkol omezit počet logických 0 nebo logických 1 jdoucích po sobě (pro větší odolnost proti ztrátě synchronizace). V případě 10 Gb/s Ethernetu se například používá kódování 64B/66B, kdy se série 64 bitů nahradí novou sérií o délce 66 bitů. Další ukázka použitých kódování je uvedena v tabulce 1.2. Výstup PCS podvrstvy je poté přiveden do bloku PMA (Physical Medium Attachment), kde se provádí převod paralelního přenosu na sériový. Tento druh přenosu je vhodný pro vysílání na fyzické médium. Zároveň se v PMA vrstvě provádí i opačný postup, kdy se ze sériového přenosu z média vytvoří paralelní tok pro PCS podvrstvu. Poslední popisovanou podvrstvou je PMD (Physical Medium Dependent), ve které jsou definovány detaily vysílání a příjmu jednotlivých bitů na fyzické médium. Mezi specifikované parametry na PMD je možné zařadit časování odesílání, kódování signálu na jednotlivé přenosové cesty, popsané vlastnosti přenosových médií, používané vlnové délky v optických vláknech a podobně. V červnu 2010 byl dokončen poslední standard IEEE 802.3ba, který popisuje Ethernet o rychlosti 40/100 Gb/s. Oproti 10 Gb/s variantě (standard 6

1.1. Ethernet IEEE 802.3ae) je datová šířka reconciliation podvrstvy osm bytů široká. Pro komunikaci do nižších podvrstev je využito protokolu XLGMII (40 Gb/s) nebo CGMII(100 Gb/s). PCS podvrstva je však složitější než tomu bylo u 10 Gb/s. Po provedení kódování 64B/66B a scramblování (tj. randomizaci) se jednotlivé datové bloky distribuují metodou round-robin (cyklické střídání) na nezávislé datové linky, které jsou přivedeny do PMA podvrstvy. V případě 40 Gb/s jsou tyto linky čtyři a pro 100 Gb/s je jich využito dvacet. Pro snadnější propojení komponent na delší vzdálenosti standard definuje XLAUI (40 Gb/s) a CAUI (100 Gb/s). V případě změn v PMD je zajímavé zmínit to, že pro dosažení 40 Gb/s se budou využívat čtyři fyzické linky. V případě 100 Gb/s je doporučeno využívat deset fyzických linek.

1.1.2

XGMII

Je MII pro 10 Gb/s Ethernet (popsáno v IEEE 802.3ae). XGMII se skládá z nezávislých cest pro příjem/odesílání dat z/do nižších vrstev. Každý směr však používá 32 bitovou datovou sběrnici (RX<31-0> a TX<31-0>), 4 bitovou řídící sběrnici (RXC<3-0> a TXC<3-0>) a svůj hodinový signál. Datová sběrnice je rozdělena na čtyři skupiny (lanes), které sdílí hodinový signál a jeden řídící signál. Tedy, každý jeden byte datové sběrnice je přiřazen jednomu bitu kontrolní sběrnice. Kontrolní sběrnice poté specifikuje, zda se přenáší na datové sběrnici příkaz nebo data. Při přenosu se jednotlivé byty mapují na linky metodou round-robin (dochází k cyklickému střídání linek).

IFG

PREAMBLE SFD DATA

EFD

Obrázek 1.5: Datový tok XGMII

Struktura XGMII toku je znázorněna na obrázku 1.5. Inter-frame gap (IFG) je bytová mezera mezi dvěma sousedními rámci. Standardní mezera je minimálně 12 bytů dlouhá, ale může se pohybovat v rozmezí ±3 bytů (tento mechanismus se nazývá DIC - Deficit Idle Counter). U XGMII může ale nastat při příjmu i mezera délky 5 bytů. Při IFG mezeře se neprovádí žádný přenos dat a na datové sběrnici je vložen IDLE příkaz (TXC = 1 a TXD = 0x07). Při datovém přenosu musí být zarovnám SFD na linku 0. Z tohoto důvodu je specifikován DIC, který se snaží udržet průměrnou mezeru 12 bytů. Za tímto účelem čítá počet vložených/odebraných IDLE (vzhledem k minimální mezeře). Může tedy být vložena i kratší mezera, pokud je to výhodné pro zarovnání začátku. Položky Preamble a SFD jsou totožné se stejnojmennými položkami u Ethernetového rámce, který byl popsán v předchozí kapitole. 7

1. Analýza a návrh řešení

1.1.3

XLGMII/CGMII

Je MII pro 40/100 Gb/s Ethernet (popsáno v IEEE 802.3ba). Je téměř totožný s XGMII. Základní rozdíl je ten, že používá širší datové sběrnice. Zde má datová sběrnice šířku 64 bitů a řídící sběrnice má šířku 8 bitů. Narozdíl od XGMII přináší určitou komplikaci ve zpracování datového toku. U XGMII jsme si byli jisti v tom, že konec předchozího a začátek následujícího rámce nezačne zároveň v daném slově. U XLGMII/CGMII však tento jev nastat může. Další rozdíl mezi XGMII a XLGMII/CGMII je také ten, že XGMII je určeno pro fyzickou implementaci komunikace mezi čipy. V případě XLGMII/CGMII tomu tak není.

1.2

Rodina COMBO karet

Tato rodina karet byla vytvořena organizací CESNET a jejími partnery pro strategický projekt nasazení IPv6 protokolu v síti CESNET2. Hlavní součástí, kterou je možné nalézt na každé COMBO kartě, je jeden nebo více programovatelných obvodů FPGA, paměti, IO čipy, napájení, atd. Výhodou těchto karet je zejména jejich flexibilita, kdy se změnou firmwaru může dojít ke změně chování celé karty, a může se tedy velice efektivně používat k různým výzkumným projektům (například HNIC, FlowMon, NIFIC).

Obrázek 1.6: Karta COMBOv2 LXT155-10G2 (převzato z [4]) V rámci této diplomové práce jsem využíval COMBOv2 LXT155-10G2, kterou je možno vidět na obrázku 1.6. Tato karta má modulární architekturu a skládá se ze dvou modulů. Prvním modulem je takzvaná základní karta, na které je obsažen výkonný FPGA čip Virtex5XC5VLX155T, paměti QDRII RAM a konektor SODIMM pro pamět DDR2. Tento modul se též nazývá COMBO-LXT a byl vytvořen jako akcelerační karta pro sběrnici PCI Express x8. Propustnost činí až 28 Gb/s. Mohou být využity jako hardwarové koprocesory, tak i jako síťové adaptéry. Pro druhou variantu je však potřeba druhý modul, který se nazývá 8

1.2. Rodina COMBO karet rozšiřující karta(COMBOI-10G2, COMBOI-1G4). Tento přídavný modul již umožní využívat různá síťová rozhraní a získáme tak hardwarově akcelerovaný síťový adaptér na PCI Express sběrnici. Více informací je možné zjistit ve zdrojích [6] a [7]. Další informace je možné zjistit v technických zprávách [2], [3] a [4]. Programovatelné propojení

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

CLB

Programovatelné vstupní a výstupní bloky

Programovatelný logický blok

Rozhraní pro vysokorychlostní komunikaci s okolím

Obrázek 1.7: Základní struktura FPGA V dnešní době jsou FPGA obvody hojně využívány zejména díky jejich velké flexibilitě a možnosti provádět programování u zákazníka. K jejich programování se používají jazyky HDL (Hardware Description Language). Obvod FPGA obsahuje takzvané programovatelné logické bloky (CLB), které se skládají ze dvou SLICE bloků. Ty slouží jako generátory funkce a z hlediska implementace se dají realizovat pomocí paměti, do které se naprogramuje pravdivostní tabulka realizované funkce. Pro realizaci sekvenčních obvodů obsahuje SLICE ještě klopný obvod typu D. Chování daného SLICE je možné přizpůsobit pomocí multiplexoru. Jeden SLICE blok je tedy schopen realizovat kombinační nebo sekvenční obvod. Jeho zjednodušené schéma je možné vidět na obrázku 1.8. Pro přesnější strukturu SLICE a CLB je však dobré nahlédnout do dokumentace daného obvodu. Od počtu vstupů je možné odvodit počet řádků pravdivostní tabulky, kterých je pro N vstupnů 2N . Nejčastěji jsou dostupné čtyři vstupy do LUT, ale může jich být i více (například šest u Virtex-5). Při větším počtu proměnných realizované funkce se dají jednotlivé LUT řetězit za sebe. Kromě konfiguračních logických bloků mohou obvody FPGA obsahovat již hotové specializované bloky, které se dají z jazyka HDL použít. Díky tomuto je možné minimalizovat spotřeba zdrojů a zároveň zvýšit pracovní frekvenci. Mezi tyto bloky například patří BlockRAM paměti, DSP obvody, procesory (například PowerPC), sčítačky, specializované bloky pro implementaci posuvných registrů nebo bloky pro výpočet kontrolního CRC32 součtu. Dostupné vestavěné bloky se liší podle zvoleného 9

1. Analýza a návrh řešení obvodu FPGA. Každý SLICE navíc může ještě obsahovat úplnou sčítačku, která umožní jednodušší konstrukci vícebitových sčítaček. CLB

SWITCH MATRIX

SLICE

SLICE

4 port memory

SLICE

LUT D Q CLK

Obrázek 1.8: Základní struktura CLB Jednotlivé bloky spolu mohou komunikovat pomocí konfigurovatelné propojovací sítě. Napojení CLB bloku na tuto síť je naznačeno na obrázku 1.8. Pro rozvod hodinového signálu se však používají speciální přenosové cesty, které vykazují velmi malá zpoždění. Tento hodinový rozvod je obvykle ještě připojen do bloků DCM (Digital Clock Manager), který se nejčastěji používá pro změnu frekvence, fáze nebo korekci hodinového signálu. Těchto bloků k úpravě hodinového signálu může být na obvodu více. Pro komunikaci s okolními obvody na desce se používají programovatelné vstupní a výstupní bloky (takzvané IOB buňky), které umožní adaptaci na danou signálovou úroveň vně FPGA. Pro vysokorychlostní komunikaci s okolím využívá FPGA rozhraní RocketIO, GTX, GTP nebo GTH (záleží však na daném obvodu). Zjednodušené blokové schéma programovatelného obvodu je uvedeno na obrázku 1.7.

1.3

NetCOPE

Hlavním cílem NetCOPE je vytvořit dostatečně obecnou platformu pro vývoj síťových aplikací na COMBO kartách. Tato platforma obsahuje základní bloky, které by se v každém projektu používaly stále znova. Mezi tyto základní bloky patří například bloky pro realizaci propojovací infrastruktury (FrameLink, MI32 rozhraní), síťové vyrovnávací paměti, PCI Express bridge, DMA řadičů pro komunikaci ve směru z RAM do COMBO karty, COMBO karty do RAM, atd. Platforma je implementována v jazyce VHDL. Její základní strukturu je možné vidět na obrázku 1.9 v případě NIC projektu. Jsou zde uvedeny tři základní bloky cv2_pci, netcope_ics a network_module. Blok cv2_pci slpuží jako PCI Express endpoint. Navíc slouží jako rozhraní pro Internal Bus. Blok netcope_ics slouží právě k realizaci tohoto propojovacího systému. Obsahuje servisní výstupy (pro ID a MDIO modul) a čtyři hlavní sběrnicové výstupy – Internal bus a tři MI32 rozhraní. Tyto tři MI32 10

1.3. NetCOPE

Obrázek 1.9: Základní struktura NetCOPE (převzato z [8])

sběrnice se používají pro konfiguraci DMA řadiče, síťového modulu (network_module) a také do bloku, kde se může realizovat uživatelská aplikace (na obrázku blok znázorněn jako application). Rozhraní MI32 bude popsáno v kapitole 1.3.3. Další bloky jako ib_endpoint a dma_mod slouží jako koncové body sběrnice Internal Bus a umožňují transakční zpracování(lokální a globální). Výhodou je to, že díky lokálním transakcím mohou spolu komunikovat jednotlivé bloky bez účasti CPU. Globální transakce se používá pro komunikace směrem ven z karty do globálního adresního prostoru (například do RAM paměti). Blok ib_switch slouží jako rozbočovací prvek, který dokáže směrovat komunikaci k adresátu (má tedy stejnou funkci jako switch v přepínaných ethernetových sítích). Internal Bus používá stromovou strukturu, která se skládá z endpointů, switchů, tranformačních prvků a kořenového prvku. Kořenový prvek je součástí PCI bridge. O koncových bodech (ib_endpoint) již zde byla řeč. Při jeho instanciaci se vytvoří adresní dekodér, který má na starosti příchozí/odchozí komunikaci na Internal Bus. Výhodou stromové struktury je to, že jednotlivé koncové body mohou spolu komunikovat nezávisle na sobě pomocí full-duplex přenosu (za předpokladu, že komunikace bude probíhat po vzájemně disjunktních cestách). Dalším typem rozhraní v NetCOPE je tzv. Memory Interface. Jedná se o rozhraní, které je méně náročné na zdroje a využívá se pro komunikaci komponent, které nepotřebují tak velký datový tok. Typickým použitím je vyčítání různých registrů a konfigurace komponent. Toto rozhraní může být zapojeno na Internal Bus pomocí EPI to MI komponenty, která má na starosti převod čtecích/zapisovacích transakcí z/do Internal Bus a obráceně. Samotný způsob komunikace bude popsán v následující kapitole o základních protokolech, které jsou dostupné v aplikaci. Další důležitý blok network_module slouží jako vstupní/výstupní bod z/do samotné sítě. Síťový modul je schopen přijímat na vstupu data z protokolu 11

1. Analýza a návrh řešení FrameLink, který transformuje na rozhraní MII (Media Independet Interface). Toto rozhraní je definováno ve standardu IEEE. Určitým způsobem tedy uživatele odstiňuje od komunikace na nižší úrovni a zjednodušuje tak práci návrháři. Ten pak může pracovat pouze s protokolem FrameLink, který bude popsán v kapitole 1.3.1. Dále je možné pracovat, díky bloku tsu_cv2, s časovými značky, které je možné synchronizovat s různou přesností (například pomocí GPS - pro tento případ musí být přítomna COMBOL-GPS karta). Synchronizace časové značky se provádí pomocí PPS (Pulse per second). V případě nepřítomnosti této rozšiřující karty se generují časové značky, které jsou méně přesné. Jsou podporovány dva formáty, které jsou označovány jako: • TS - 64 bitová časová značka, kde se horních 32 bitů interpretuje jako počet sekund od 1.1.1970 a spodních 32 bitů jako zlomek sekudy. LSB bit má váhu 2−32 , • TS_NS - 64 bitová značka, kde horních 32 bitů má stejný význam jako v případe TS formátu a spodních 32 bitů reprezentuje počet nanosekund aktuální sekundy. LSB bit má váhu 10−9 . Časové rozlišení celého testeru by mělo být dostatečné, protože bude možné jednoznačně přiřadit každému paketu časovou značku. V případě rychlosti 10 Gb/s je potřebný čas na přenos paketu roven 67 ns. U nejrychlejší verze Ethernetu (100 Gb/s) je čas přenosu jednoho paketu roven 6.7 ns. V případě použití formátu TS_NS se v každém hodinovém cyklu MII rozhraní změní časová značka, kterou bude možné označkovat příchozí paket. Přiřazení značky je provádí vstupní síťová vyrovnávací paměť (IBUF), která využívá komponenty PACODAG. Tyto bloky se nachází v síťovém modulu (network_module na obrázku 1.9), kde je mimo jiné umístěn i výstupní síťová vyrovnávací pamět OBUF. Obě síťové vyrovnávací paměti jsou implementací Ethernetové MAC vrstvy. Do bloku application jsou vyvedeny všechny potřebné sběrnice a výstupy modulů, aby návrhář mohl implementovat různorodé aplikace dle potřeby. Při použití NetCOPE tak naše aplikace podědí všechny vlastnosti, které má v sobě implementována tato platforma. V této části rozeberu základní protokoly, které jsou dostupné uživatelské aplikaci a které se budou používat pro propojení jednotlivých komponent v rámci aplikace.

1.3.1

FrameLink

FrameLink je jeden ze základních sběrnicových protokolů, který je možné využívat pro propojení komponent. Jedná se o protokol, který vychází ze specifikace LocalLink od firmy Xilinx. Přenos dat na FrameLinku je rámcově založený a tudíž je vhodný pro přenos síťových paketů mezi komponentami. V 12

1.3. NetCOPE některých aplikacích potřebujeme k datům vložit další dodatečné informace (například časovou značku, velikost paketu, atd.). K tomuto účelu umožňuje FrameLink dělit komunikaci na části jako hlavička, tělo a patička. Nespecifikuje však žádné omezení na jejich počet. Význam všech signálů je uveden v tabulce 1.3. Všechny signály jsou aktivní při úrovni log. 0. Signál CLK SRC_RDY_N DST_SRC_N SOF_N EOF_N SOP_N EOP_N DATA DREM

Popis Hodinový signál na sběrnici Source Ready - zdroj je připraven posílat data Destination ready - cíl je připraven data příjmat Start of frame - indikuje začátek dat rámce (framu) End of frame - indikuje konec rámce (framu) Start of part - indikuje začátek části End of part - indikuje konec části Přenášená data Data reminder - indikuje, pozici bytu patřící do posledního slova (číslováno od 0) Tabulka 1.3: Signály FrameLinku

Data jsou na sběrnici řazena tak, že LSB dat je zařazen na LSB sběrnice a MSB dat je zařazen na MSB sběrnice. Pokud chceme přenést data širší než je šířka slova, tak musí dojít k rozdělení na více přenášených slov. Rozdělení se provádí tak, že se přenáší data postupně od LSB k MSB. Příklad: Máme data, jejichž délka je X bytů, kapacita sběrnice je N bytů, X > N a k = dX N e − 1 . Pak se budou data přenášet v pořadí : <0 – N-1>, . . . Samotná ukázka komunikace je uvedena na obrázku 1.10. Signály na FrameLinku jsou validní pouze v případe, že na signálech SRC_RDY_N a DST_RDY_N je nastavena hodnota log. 0 (tzn. odesílatel i adresát jsou připraveni). přenos rámce začíná tím, že se aktivují signály SRC_RDY_N, DST-_RDY_N, SOP_N a SOF_N. Tímto se vlastně vyjádř skutečnost, že začína přenos rámce (framu) a na sběrnici jsou dostupné validní data. Jednotlivé části jsou ohraničeny signály SOP_N a EOP_N. Na obrázku je takto naznačen přenos tří částí (hlavičky, těla a patičky). Po přenesení dat patičky se s posledním slovem nastaví signály EOP_N a zároveň se s aktivitou tohoto signálu potvrzuje hodnota DREM (potřebujeme znát počet validních dat v posledním slově - v tomto případě jsou to 3B). Po přenosu celé hlavičky je aktivovám signál SOP_N, kterým se naznačuje začátek začátek nové části. Je zde také možné vidět pozastavení přenosu pomocí signálu SRC_RDY_N a DST_RDY_N, kdy se přenos na sběrnici zastaví a na sběrnici se drží data, která nebyla tímto přístupem potvrzena. Samotná část dat je opět ohraničena signálem EOP_N. Přenos patičky se vleze do jednoho slova a zároveň tímto 13

1. Analýza a návrh řešení

Obrázek 1.10: Komunikace na FrameLink protokolu (převzato z [9])

končí celý rámec (frame). Z toho důvodu jsou aktivní signály SOP_N,EOP_N a EOF_N. Opět se potvrzuje hodnota DREM a musí být také připraven odesílatel i příjemce. P

1.3.2

FrameLinkUnaligned

Specifikace tohoto protokolu vznikla začátkem roku 2012, kdy starší FrameLink již nemohl dosáhnout dostatečné rychlosti pro podporu vyšších rychlostí 40/100 Gb/s. Hlavním důvodem výměny byla zejména neefektivita staršího protokolu, kde každý začátek následujícího rámce byl zarovnán. V případě širších sběrnic (256 bitů a více) dochází pak k docela zbytečnému plýtvání místa na sběrnici, pokud se využije z nového sběrnicového slova pouze jeden byte. V případě 256 bitů široké sběrnice se plýtvá 31 byty. U 512 bitů široké sběrnice je tato hodnota rovna 63 bytům. Řešením zmíněného problému je tedy umožnit v tom samém sběrnicovém slově vystavení začátku dalšího paketu, čímž dojde ke zvýšení efektivita přenosu a tím pádem ke zvýšení datové propustnosti. Seznam signálů a jejich význam je uveden v tabulce 1.4. Oproti starší verzi FrameLinku je tu podstatná změna, která se týká aktivní úrovně jednotlivých signálů, která je nyní ekvivalentní pozitivní logice (aktivní při log. 1). Další změnou je zrušení podpory více částí rámce (framu), díky které je možné rámec logicky rozdělit na více částí (například na hlavičku a tělo). Toto dělení mělo 14

1.3. NetCOPE Signál DATA SOP_POS EOP_POS SOP EOP SRC_RDY DST_RDY

Popis Přenášená data Start of packet position - indikuje pozici začátku nového paketu End of packet position - indikuje pozici konce předchozího paketu Start of packet - indikuje začátek paketu End of packet - indikuje konec paketu Source ready - indikuje, že je zdroj připraven odesílat Destination ready - indikuje, že je příjemce připraven Tabulka 1.4: Signály FrameLinkUnaligned

smysl u zarovnaného FrameLinku, kdežto u nezarovnaného tento pojem ztrácí význam. Přesto je možné toto chování implementovat postupem, kdy jedna nezarovnaná část může přenášet hlavičku a druhá nezarovnaná část může přenášet tělo s daty paketu. Pro platnost všech signálů je vyžadována aktivní úroveň signálů SRC_RDY a DST_RDY. Pro platnost signálu EOP_POS je navíc vyžadována aktivní úroveň signálu EOP a stejné pravidlo platí i pro signály, které naznačují začátek nového paketu. Mezi generické parametry patří šířka pásma a šířka sběrnice SOP_POS. Díky této generice je možné přesně specifikovat místo, kde může začít následující (nezarovnaný) rámec. Více o tomto protokolu je možné zjistit z dokumentace [12], kde je mimo jiné uvedena také ukázka komunikace na tomto novém protokolu.

1.3.3

MI32

MI32 je sběrnice používaná zejména pro konfiguraci a komponenty, které nepotřebují tak velkou propustnost sběrnice. Typické použití je zmiňovaná konfigurace komponent, kdy se takto například může zapsat do registru příkaz pro start. Tato sběrnice podporuje stromovou strukturu, kde pro směrování ke koncovým prvkům sběrnice slouží komponenta mi32_splitter. Seznam signálů (MI32 sběrnice) a jejich význam je uveden v tabulce 1.5. Na obrázku 1.11 je znázorněn průběh zapisovací transakce, která je ohraničena signálem WR. Každý zápis je potvrzen pomocí signálu ARDY a je tak možné každý takt zapsat další data. Pokud bychom chtěli zpomalit tuto transakci, tak nastavíme signál ARDY jako neaktivní. Tímto nastavením se provede pozdržení datových a řídících signálů. Jakmile bude možné požadavek zpracovat, tak se provede aktivace signálu ARDY. Od tohoto okamžiku bude pozdržený přenos považován za vyřízený. Zapisovaná data jsou vystavena na sběrnici DWR. Navíc je možné řídit počet přenášených bytů pomocí signálu BE (číslováno od 0). Data budou zapisována na místo určené sběrnicí ADDR. 15

1. Analýza a návrh řešení Signál CLK DWR ADDR BE RD WR ARDY DRD DRDY

Popis Hodinový signál Data to Write - data pro zápis Address - adresa pro zápis/čtení Byte Enable - počet bytů pro zápis/čtení Read - příkaz čtení Write - příkaz zápisu Potvrzovací signál pro příkaz zápis/čtení Data to Read - čtená data Čtená data jsou validní Tabulka 1.5: Signály MI32 sběrnice

Obrázek 1.11: Zápis přes MI32 (převzato z [11])

Čtecí požadavek je znázorněn na obrázku 1.12, kde je celá čtecí transakce ohraničena pomocí signálu RD. Data budou čtena z místa, které určuje sběrnice ADDR. Potvrzení požadavku se opět provádí pomocí signálu ARDY. Opět je podporováno pozastavení celé čtecí transakce. Samotná data jsou vystavena na sběrnici DRD a jejich validita je potvrzena pomocí signálu DRDY.

1.4

Návrh řešení

Paketový tester musí implementovat určité funkce, které by se daly využít pro ladění a testování sítě. Testy mohou být prováděny na různých vrstvách 16

1.4. Návrh řešení

Obrázek 1.12: Čtení přes MI32 (převzato z [11])

ISO/OSI modelu podle toho, na co jsou zaměřeny. Na aplikační vrstvě je například možné analyzovat odezvu aplikace, na transportní vrstvě efektivita přenosu dat pomocí TCP protokolu nebo testování směrovacího procesu na síťové vrstvě. Projekt COMET by měl být schopen analyzovat fyzickou (L1) a datovou (L2) vrstvu. Má hlavní práce se bude zabývat L2 vrstvou, kde budu zejména pracovat s rámci Ethernetu. Analýzu L1 vrstvy může v případě COMBO karty provádět phyter, který se ve formě integrovaného obvodu nachází na desce. Pro metodiku testování síťových zařízení byl vydán dokument RFC 2544 Benchmarking Methodology for Network Interconnect Devices[1], ve kterém jsou specifikovány postupy provádění jednotlivých testů, mezi které například patří test propustnosti, test zpoždění paketu, ztrátovosti paketů, atd. Více informací je možné zjistit v dokumentu [18]. Mnou implementovaná L2 vrstva by měla umět generovat provoz a tento provoz následně analyzovat. Dalším cílem je sběr různorodých statistik, které budu umět ze vstupního toku získat. Mezi cíle bych proto zařadil: 1. Možnost přeposílat pakety s určitým zpožděním (umožní přesné řízení toku), 2. generovat paketový provoz pro plnou saturaci linky, 3. možnost analýzy času, který potřeboval paket na průchod sítí, 4. analýza pořadí paketů, 5. zjistit počet ztracených paketů na síti, 17

1. Analýza a návrh řešení 6. analýza inter-frame gap (bytová mezera mezi pakety) na MII, 7. histogramy zpoždění, mezer mezi pakety a velikostí paketů, 8. výpočet bitrate a základních statistik.

1.4.1

Základní návrh zpracování toku a statistik

Schématické znázornění průchodu paketu z softwarového nástoje na výstup je znázorněn na obrázku 1.13. V případě vstupního směru se kromě zpracování dat paketu provádí také analýza celkového vstupního toku pro vytváření histogramů a dalších statistik (například pro výpočet bitrate, zahozených paketů). Tento průchod paketu ze sítě je znázorněn na obrázku 1.14. Příprava paketu v SW (pcap2sze)

Přidání konfigurační hlavičky(pcap2sze)

DMA - příjem dat Převod na FrameLink

Extrakce konfigurace pro počet opakování

Bufferování a případné opakování paketu

SW

Výstupní směr na síť

Odeslání na síť

Rozšiřování datového toku o hlavičku pro pozdější analýzu

Extrakce konfigurace pro odesílání v přesně definovaných okamžicích

Obrázek 1.13: Schématické znázornění průchodu paketu z SW na výstup COMBO karty

Vstup ze sítě Příjem paketu ze sítě

Extrakce dat rozšiřující Extrakce časové značky hlavičky (dle konfigurace) příchozího paketu Analýza rozšiřujících dat

Zahazování příchozího provozu (dle konfigurace)

Přenos přes DMA do RAM (zaleží na konfiguraci zahazování)

Analýza vstupního toku Vytváření dalších statistik Histogramy velikostí paketů Histogramy mezer mezi pakety Statistická jednotka

Výpočet doby přenosu a analýza pořadí

Pořadí paketů

Histogramy doby přenosu Statistická jednotka

Obrázek 1.14: Schématické znázornění průchodu paketu ze vstupu COMBO karty do SW

1.4.2

Odesílání paketů v definovaných okamžicích

Tato funkce je užitečná, když uživatel potřebuje na síť poslat znovu určitý provoz. Bude využíván soubor ve formátu PCAP, který obsahuje síťové pakety. Jednotlivé pakety budou z aplikace opatřeny hlavičkou, která se poté objeví na FrameLinku v první (hlavičkové) části. Tato hlavička bude poté využita pro nastavení komponenty, která bude vytvářet nastavený rozestup od konce prvního paketu ke konci následujícího paketu. Takto bude realizována funkce, 18

1.4. Návrh řešení kdy můžeme zadat čas odeslání paketu, do kterého se započítá i čas potřebný na přenos. Pro zadávání okamžiků bude vhodné implementovat dva časové módy. Prvním módem bude možno zadávat absolutní časové značky, která udává přesný čas odeslání. Pokud pak bude aktuální časová značka větší nebo rovna časové značce z hlavičky, tak se data na FrameLinku mohou potvrdit a odeslat. Pro větší propustnost využiji funkčnosti síťové výstupní paměti (OBUF), který data začne posílat po příjmu celého rámce (framu). Můžeme tak celý tok pozastavit a vyčkat na čas na odeslání. Odeslání se poté realizuje potvrzením posledního slova na datové sběrnici. Druhým módem bude možno zadávat relativní zpoždění vzhledem k poslednímu paketu. Zde bude výhodnější realizovat zjištění relativního času pomocí čítání hodinových pulzů. Komponenta bude muset pracovat na frekvenci výstupní síťové paměti, která činí 156.25 MHz. Při vyšší frekvenci může dojít ke zmenšení vytvořeného rozestupu, což by vedlo k dřívějšímu odeslání paketu. Hodnota, která se bude přenášet, bude počet taktů zpoždění při již zmiňované frekvenci komponenty OBUF. Formát hlavičky je uveden na obrázku 1.15. První část hlavičky bude mít velikost 8B, kde se bude moci zadat jak absolutní, tak i relativní zpoždění. Velikost 8B byla zvolena proto, protože právě časová značka má takovouto šířku. Třetí část hlavičky bude mít velikost 1B (FrameLink je bytově orientovaný) a bude zde přítomen z důvodu volení absolutního/relativního módu. Význam druhé části hlavičky bude uveden později.

TS / REL. 8B

REPEATS 4B

FLAG 1B

Obrázek 1.15: Formát hlavičky pro nastavení časového zpoždění Tato realizace je možná, protože existuje způsob, jak zadat z softwarové aplikace dodatečná data do protokolu FrameLink. Tímto způsobem je takzvaný SZE2 kanál, který umožňuje posílat data přes DMA řadič umístěného na kartě. Výhodou tohoto řešení bude zejména to, že můžeme zadat doplňující data zpoždění ke každému paketu a každý paket může obsahovat různou hodnotu zpoždění. Nevýhodou by mohla být složitější implementace pro vyšší rychlosti (40/100 Gb/s).

1.4.3

Opakování paketů

Možnost opakování paketů je vhodná funkce pro vygenerování většího datového toku, než je možné dodat přes DMA kanály. Pokud tedy bude možnost jeden paket opakovat vícekrát, tak dáme DMA kanálu čas na přenos dalších paketů, které se budou ukládat do fronty. 19

1. Analýza a návrh řešení Samotná komponenta by měla mít paměť na jeden paket, který se nahraje a poté se bude opakovat. Počet opakování je součástí hlavičky, která je vytvořena v aplikaci pcap2sze. Komponenta tuto informaci extrahuje a použije pro opakování uloženého paketu. Při tomto opakování musí také pozastavit tok na FrameLinku (nastavení signálu DST_RDY_N na neaktivní úroveň). Pro nastavení počtu opakování se využije hlavičky z předchozí části, která se takto rozšíří o pole velikosti čtyř bytů (na obrázku 1.15 uvedeno jako REPEATS). Komponenta může fungovat v interní časové doméně, narozdíl od komponenty na vytváření přesně definovaných rozestupů. Výhodou tohoto umístění bude schopnost generovat rychlejší datový tok do místa přechodu z interní časové domény do síťové časové domény.

1.4.4

Analýza času průchodu sítí

Pro analýzu času, který paket potřeboval na průchod sítí, musíme být schopni zjistit čas odchodu a příchodu paketu. Z takovéto informace bude poté možno spočítat časový rozdíl. Pro přesnější analýzu využiji časových značek (formát TS_NS). Je možné využít toho, že přes protokol FrameLink prochází každý paket, který půjde na síť. Máme tedy výbornou možnost na označkování každého paketu, který se rozšíří o hlavičku, která bude obsahovat dostatek informací potřebných k analýze. Formát navrhované hlavičky je uveden na obrázku 1.16.

ID TS (8B) (5B)

HN HASH (1B) (4B)

Obrázek 1.16: Formát hlavičky vkládané do datového toku

Hlavička obsahuje i jiné údaje, které bude možné využít k další funkci síťového testeru (analýza pořadí), a jejich význam bude popsán později. Nyní stačí zmínit, že pro samotné označení času odeslání použiji políčko s názvem TS. Pro zjištění času příjmu využiji již hotového řešení pro značkování paketů, které bylo nazváno PACODAG. Toto řešení je využíváno již v rámci platformy NetCOPE. PACODAG je komponenta, která umí přidávat k přijímaným paketům další kontrolní data ve formě FrameLinkové hlavičky. Mezi tyto kontrolní data patří také časová značka příjmu. Z těchto extrahovaných značek je poté možné vypočítat čas průchodu přes síťovou infrastrukturu od odesílatele k příjemci. Pro lepší představu pozice vložené hlavičky jsem vytvořil obrázek 1.17, na kterém je možné vidět vložení generovaných dat za originální datový tok, který byl přijat přes DMA. 20

1.4. Návrh řešení Dest. MAC 6B

Sour. MAC 6B

Ether. type 2B

Payload 46-1500B Original data payload

CRC 4B

Inserted header (18B)

Obrázek 1.17: Znázornění pozice vložené hlavičky do datového toku paketu

1.4.5

Analýza pořadí a ztracených paketů

V této části, mimo jiné, zmíním význam zbývajících položek z obrázku 1.16. Položka s názvem ID slouží pro uvedení sériového čísla vysílaného paketu, které se dá využít při analýze. Navíc se může využít i přiložené časové značky, která bude detekovat čerstvost ID položky a umožní tak zjistit přetečení tohoto identifikátoru. Toto však přinese určité komplikace při návrhu, jako například nutnost přítomnosti 64 bitového komparátoru. Na druhou stranu však bude možné detekovat na hardwarové úrovni počet ztracených paketů. Samotnou analýzu pořadí je možné provádět podle pseudokódu 1. Pro svou funkci bude používat políčko TS a ID. Hlavička je také opatřena HASH polem, kde je kontrolní hodnota celé zprávy. Pro její výpočet je použito klasické CRC32, které se zde počítá paralelně pro 128 bitů. Před HASH pole je pak umístěno ještě identifikační číslo (označené jako HN), které je nastaveno na pevnou hodnotu a umožní tak detekovat tuto hlavičku. Na interpretaci paketu musí souhlasit celkem 40 bitů.

1.4.6

Základní statistiky

Ethernetový tester by měl zvládat vytváření základních statistik. Pro tento účel je možné použít již vytvořeného statistického rozhraní, které využívá PACODAG. Tímto je možné získat jednodušší implementaci statistické jednotky. Pokročilejší funkce, jako je měření bytové mezery na XGMII, budou součástí mé práce. Základní měřené statistiky jsou uvedeny v tabulce 1.6. Sloupec s názvem implementace vyjadřuje umístění komponenty, která provádí analýzu dané statistiky. Externí jednotky pak mohou využít rozhraní, kam jsou jednotlivé informace o výsledku vyvedeny. Statistická jednotka pak bude muset obsahovat čítače, komparátory a další části které budou akumulovat jednotlivé výsledky. Tohoto přístupu je možné využít ve většině měřených statistikách. Pro měření bytové mezery na MII rozhraní je opět možné využít signálů IBUFu, které nás informují o začátku příjmu, počtu 4B zarovnání začátku paketu a pozice konce paketu. Měření mezery se zahájí po příjmu prvního paketu. Na XGMII nemůže nastat začátek a konec paketu zároveň a dochází ke střídání konce a začátku paketu. Šířka datové linky XGMII je 8B (32 bitů sběrnice DDR). Samotný bytový rozestup je možné spočítat jako počet 21

1. Analýza a návrh řešení Algoritmus 1: Analýza pořadí paketů

1

2 3 4 5

6 7

8 9 10 11 12

13 14 15

/* Expected_ID -> očekávané ID /* Actual_TS -> aktuální časová značka /* Last_TS -> časová značka posledního přijatého paketu /* Last_ID -> ID posledního přijatého paketu /* Out_order -> čítač paketů mimo pořadí /* In_order -> čítač paketů ve správném pořadí if (Actual_TS > Last_TS) and (Actual_ID = Expected_ID) then /* Dostali jsme očekávaný paket a zvýšíme proto počet In_order paketů In_order ++; Expected_ID = Last_ID = Actual_ID+1; Last_TS = Actual_TS; else /* Nastalo špatné pořadí-> ztracené pakety Expected_ID = Actual_ID+1; if ((Actual_TS > Last_TS) and (Actual_ID < Last_ID)) or ((Actual_TS > Last_TS) and (Actual_ID > Last_ID)) then /* Nějaké se nejspíše ztratily Out_order + +; Lost = Lost + (Actual_ID - Last_ID); Last_TS = Actual_TS; Last_ID = Actual_ID; else /* Dostali jsme starší časovou značku->zmenšíme Out_order čítač Out_order - -; end end

*/ */ */ */ */ */

*/

*/

*/

*/

nevyužitých bytů při aktivním signále konce paketu, přičítáním hodnoty 8 při neaktivním začátku paketu a korekcí nevyužitého místa při aktivním začátku signálu. Příklad: Při indikaci konce paketu máme využity 4B z XGMII linky. Po dobu jednoho taktu se nepřenáší žádná data a v následujícím taktu je indikován začátek paketu s informací, že bylo provedeno jedno 4B zarovnání. Potom bytová mezera bude rovna (8B-4B) + 8B + 4B = 16B. Pokud bylo i v předchozím kroku provedeno zarovnání, tak je naše mezera o 4B větší (kvůli posunu začátku). U XLGMII (40 Gb/s) je možné měřit mezeru stejným způsobem. Je zde však komplikace, kdy může být indikován začátek a konec paketu zároveň (z 22

1.4. Návrh řešení Název statistiky Celkový počet zpracovaných paketů Počet přijatý paketů Počet zahozených paketů Zahozených kvůli přetečení vyr. paměti Zahozených kvůli špatnému CRC Zahozených kvůli špatné MAC Suma velikostí přijatých paketů Počet paketů v sumě Počet paketů pod min. velikost Počet paketů nad MTU Minimální velikost paketu Maximální velikost paketu Minimální XGMII mezera Maximální XGMII mezera Počet 156.25 MHz taktů mezi čteními

Implementace IBUF IBUF IBUF IBUF IBUF IBUF IBUF/Statistická jednotka Statistická jednotka IBUF IBUF IBUF/Statistická jednotka IBUF/Statistická jednotka Statistická jednotka Statistická jednotka Statistická jednotka

Tabulka 1.6: Základní statistiky

hlediska externí komponenty). MII tok může obsahovat IFG i část dalšího paketu. Komponenta tedy musí být schopna pokrýt i tento případ, kdy se začátek a konec paketu může indikovat zároveň. V tomto případě se pak mezera detekuje jako počet bytů k začátku paketu minus počet bytů ke konci předchozího paketu. Pro lepší představu je uvedeno několik ukázek IFG na obrázku 1.18. předchozí paket

EOP

IFG

IFG

IFG

EOP

EOP IFG

EOP

SOP SOP

SOP SOP následující paket

10Gbit(XGMII)

40Gbit(XLGMII)

Obrázek 1.18: Ukázky IFG Výsledek výpočtu IFG se poté může použít nejen na zjištění maxima/minima, ale také na vytváření histogramů, o kterých bude řečeno více v následující kapitole. Pro výpočet bitrate toku je možné využít informace o sumě velikostí přenesených paketů a času, po který se suma vytvářela. Průměrný tok je poté 23

1. Analýza a návrh řešení možné spočítat podle následujícího vzorce, kde N je počet paketů přijatých za čas, který se vypočítá jako součin periody 156.25 MHz a čítače R, který obsahuje počet taktů mezi vyčítáním hodnot. bitrate =

8∗

PN

i=1 packet_sizei [bps] T156.25M Hz ∗ R

(1.1)

Data by měla být z jednotky vyčtena atomicky (všechna v jeden okamžik). Toto ale není při použití MI32 protokolu možné, jelikož šířka datové sběrnice činí 32 bitů. Proto by bylo vhodné implementovat funkci snapshotu, během kterého bude zabezpečena neměnnost dat. Snapshot by měl být uvolněn po přečtení všech potřebných dat (tzn. s poslední čtenou adresou). Pro vyčítání hodnot by bylo vhodné implementovat restart čítače/registru po čtení. Této funkce se dá například výhodně využít při počítání bitrate, kdy se po přečtení sumy velikostí paketů vynuluje registr. Takto se dosáhne informace, která vyjadřuje velikost akumulovaných dat od posledního čtení.

1.4.7

Histogramy

Histogramy jsou v mnoha případech velice užitečné, protože umožňují udržovat určitou historii datového toku. Samotné histogramy se musí vytvářet přímo v hardwaru. Důvodem je zejména přenosová rychlost, která neumožňuje zpracovávat histogramy v počítači. Při návrhu by bylo dobré dbát na to, aby se dala histogramová jednotka používat opakovaně v různých aplikacích a měla by proto umožňovat aktualizaci položek každý takt. Vzhledem ke spotřebě zdrojů by bylo vhodné navrhnout jednotku tak, aby byla co nejvíce šetrná k FPGA. Při použití širších čítačů(např. 64 bitů) může výsledné řešení spotřebovat velkou část dostupných zdrojů a také se může zhoršit časování. Proto při návrhu využiji BlockRAM pamětí, které umožní implementaci i širších čítačů při velice dobrém časování. BlockRAM paměti jsou navíc dvoubranné a umožní tak aktualizaci a čtení dat zároveň (každá operace na jeden port). Při vyčítání histogramu však není možné zaručit atomické čtení hodnot, protože při této technologii je to technicky velice obtížné na realizaci. Při aktualizaci hodnot se negativně projeví latence čtení, která trvá po dobu dvou hodinových taktů. Zápis trvá po dobu jednoho taktu. Navíc si musíme uložit adresu pro aktualizaci, proto není možné tuto BlockRAM paměť použít po dobu tří taktů (čtení + zápis nové hodnoty), což je pro podmínku aktualizace v každém hodinovém pulzu nepřijatelné. Nabízí se však možnost implementace pomocí prokládané paměti, kdy je možné využít více BlockRAM pamětí pro pokrytí aktualizační latence. Bude proto výhodné si realizovat jeden blok histogramu, který bude umět provést aktualizaci hodnoty do tří taktů od zadání. Histogram pak bude muset obsahovat více těchto bloků, které bude možné cyklicky využívat. 24

1.4. Návrh řešení Při vyčítání histogramu se zadá stejný požadavek všem blokům histogramu. Jejich výsledky poté sečteme, protože z principu aktualizace hodnot je v každém bloku obsažena určitá část výsledku. Zároveň by bylo vhodné implementovat funkčnost inicializace hodnoty po čtení. Pro používání bude dobré implementovat možnost nastavení počtu políček a jednotlivých rozsahů histogramu. Bude tak možné realizovat různé stupnice (např. logaritmickou), které budou pro měření daného problému nejvhodnější. Navíc bude možné provést v budoucnu rozšíření o možnost konfigurace z uživatelské aplikace a získáme tak flexibilní a znovupoužitelnou jednotku. Pro konfiguraci (aktivace,inicializace po čtení) a vyčítání histogramu použiji MI32 protokol. Bude však nutné vyřešit čtení vektoru, jehož velikost přesahuje 32 bitů (tzn. šířku datové sběrnice). Proto bych navrhoval omezit velikost na hodnotu větší jak 32 bitů (vzhledem k frekvenci příchozích paketů ze sítě). Přístup k hodnotám histogramu bude ve většině případů sekvenční. Z tohoto důvodu by se mohlo implementovat vyčítání dat, které je podobné přístupu k FIFO frontě. Po vyčtení celé hodnoty by se pak provedlo posunutí ukazatele na následující pole histogramu. Tento přístup také umožní určité zjednodušení návrhu adresního dekodéru za cenu sekvenčního přístupu k jednotlivým položkám histogramu.

25

Kapitola

Realizace V této kapitole přiblížím jednotlivé aspekty návrhu síťového testeru. Budu se věnovat hlavně návrhu pro 10 Gb/s s ohledem na budoucí rozšiřitelnost pro rychlejší sítě. Hlavní důraz bych proto kladl na komponenty, které provádí měření.

2.1

Návrh testeru pro 10 Gb/s Ethernet

Základní blokové znázornění projektu COMET je uvedeno na obrázku 2.1. V obou směrech (vysílací/přijímací) je samotný přenos realizován pomocí DMA řadičů, které umožňují vysokorychlostní přenos z/do RAM paměti počítače. Z pohledu protokolu FrameLink je šířka datové sběrnice 64 bitů při pracovní frekvenci 177MHz. Za DMA řadičem je použita FIFO fronta, která slouží pro vyrovnání přenosové rychlosti DMA řadiče z RAM paměti do COMBO karty. Tato fronta je výhodná v případě užití opakování, kdy si zde můžeme připravit data následujícího paketu. Navíc je možné tímto způsobem zastínit režii DMA přenosu. Všechny vytvořené bloky se čtou a konfigurují přes MI32 protokol, který je možné větvit přes MI32_SPLIT komponentu (ta však pro přehlednost není do blokového schématu zanesena). Tímto způsobem je také rozdělen adresní prostor, kdy se směrování požadavku řídí pomocí adresy na adresní sběrnici. Tato komponenta pro směrování požadavků již v rámci projektu Liberouter vznikla a je používána v řadě projektů. Samotné opakování a vytváření rozestupů mezi pakety je realizováno v bloku s názvem TIME_SENDER. Způsob předání konfigurace byl popsán v předchozí kapitole (viz. 1.4.2 a 1.4.3). V této komponentě je využita i asynchronní FIFO fronta, která slouží pro převedení dat z interní hodinové domény do síťové hodinové domény. FIFO fronta již byla v projektu Liberouter vytvořena a byla tedy dostupná v základní knihovně. Z důvodu zajištění dostatečného toku pro síťovou hodinovou doménu je opakování paketů umístěno do interní hodinové domény a samotné oddělení domén je realizováno pomocí již zmíněné asynchronní fronty. 27

2

2. Realizace COMET

177MHz 156.25MHz TIME_SENDER

FL_FIFO

DMA

FL_REPEATER

ASFIFO

TIME_SENDER CORE

FL_PIPE

FL_TRIMMER

TIME_SENDER FL_REPEATER

ASFIFO

TIME_SENDER CORE

FL_PIPE

FL_TRIMMER

MI32

MI32

FRAME_DISCARD

DMA

MI32

PACKET_CHECKER SEND

STAT_UNIT

MI32

PACODAG interface + stat. interface

10G NETWORK MODULE

MI32

MI32

10G

PACKET_CHECKER RECEIVE

MI32

FRAME_DISCARD

10G NETWORK MODULE

MI32 MI32

MI32

FL_FIFO

PACKET_CHECKER SEND

PACKET_CHECKER RECEIVE

10G

STAT_UNIT PACODAG interface + stat. interface

Obrázek 2.1: Blokové schéma projektu COMET

Blok FL_PIPE slouží pro zkrácení kritické cesty, což pak vede na lepší časování výsledného řešení. V celé datové cestě se využívá FrameLinková hlavička, která přenáší konfiguraci jednotlivých komponent. Před vstupem do síťového modulu se musí tato část odstranit, aby nedocházelo k její odeslání na síť. K tomuto účelu vznikla v rámci projektu komponenta FL_TRIMMER. Odstranění hlavičky je realizováno nastavením SRC_RDY_N na neaktivní úroveň po celou dobu trvání odstraňované části. Poslední komponentou ve výstupním směru je PACKET_CHECKER_SEND, který slouží pro rozšíření dat o hlavičku pro analýzu pořadí a času potřebného pro průchod sítí (viz 1.4.4 a 1.4.5). Síťové statistiky jsou vytvářeny v příchozím směru ze sítě. K tomuto účelu využívá projekt COMET implementovaných částí ve vstupní síťové paměti (IBUF). Tyto statistické signály se pak zpracovávají v komponentě s názvem STAT_UNIT, kde se mimo jiné vytváří histogramy velikostí a mezer mezi pakety na XGMII. Blok s názvem PACKET_CHECKER_RECEIVE slouží pro analýzu pořadí a histogramu času, který potřeboval příchozí paket na průchod sítí. Poslední komponenta ve vstupním směru ze sítě je FRAME_DISCARD. Jejím hlavním úkolem je zahazování paketů ze sítě, protože DMA kanál nemá dostatečnou kapacitu pro příjem všech příchozích paketů, a proto se musí implementovat zahazování a veškerou analýzu provádět již na úrovni FPGA. Podrobnější popis a implementace jednotlivých bloků bude uvedeno v následujícím textu. 28

2.1. Návrh testeru pro 10 Gb/s Ethernet

2.1.1

Opakováné odesílání paketu

Opakování paketů je realizováno pomocí komponenty FL_REPEATER. Na obrázku 2.2 je uvedeno její blokové schéma. Extrahování informace o počtu opakování se provádí pomocí komponenty FL_EXTRACT, která je dostupná v základním balíku komponent fl_tools (byla dříve vytvořena v rámci projektu Liberouter). Toto nastavení se pak použije v automatu, který se stará o samotné řízení zbytku komponent. Důležitou roli plní bloky FL_COMPRESS a FL_DECOMPRESS, které slouží k vytvoření souhrnné informace pro uložení FrameLinkového toku do paměti (datové + řídící signály). Vyjímku tvoří signály SRC_RDY_N a DST_RDY_N, které jsou generovány konečným automatem a slouží k pozastavení příjmu nebo vysílání. mem_dst_rdy_n<=full

DP_MEM

rd_en

reset_frame_cnt_en

frame_sent

frane_cnt_en

tx_src_rdy_n

frame_rec

tx_eof_n tx_eop_n

tx_dst_rdy_n

wr_en mem_dst_rdy_n

rep_cnt

tx_eof_n

tx_eop_n

read_en

LAST DATA_SEND

mem_src_rdy_n

full empty

reset_wr_cnt

reset_wr_cnt reset_rd_cnt

tx_src_rdy_n<=empty

mem_eof_n mem_eop_n

FSM REP_CNT

TX

empty

full

frame_rec

Framelink out

reset_rd_cnt

RD_ADDR

WR_ADDR

frame_sent

FL_DECOMPRESS

FL_EXTRACT

RX

FL_COMPRESS

Framelink in

STATS

FRAME_CNT

Obrázek 2.2: Blokové schéma komponenty FL_REPEATER Registry WR_ADDR a RD_ADDR obsahují čtecí a zapisovací adresy do dvoubranné paměti. Tato paměť se nachází mezi komponentami, které se starají o uložení a extrakci řídících signálů (bloky FL_COMPRESS a FL_DECOMPRESS). Kapacita paměti stačí na jeden paket (který se bude opakovat). Na výstup se kromě opakovaného FrameLinkového rámce ještě dostane informace o aktuálním opakovaném paketu, která může být použita v jiných komponentách. Informace o zbývajícím počtu opakování je uložena v čítači s názvem REP_CNT, který je ovládán konečným automatem a jeho 29

2. Realizace hodnota se s každým opakovaným paketem dekrementuje o jedna. Při posledním průchodu se pak umožní předběžné načítání nových dat, které se pak mohou po dokončení předchozího paketu ihned začít odesílat.

2.1.2

Odesílání paketů v přesných okamžicích

Pro tento účel byla vytvořena speciální komponenta, která podporuje všechny funkce, které byly popsány v kaptitole 1 - Analýza a návrh. Realizace pracuje s protokolem FrameLink, kde se za pomocí řízení RDY_N signálů může provádět pozdržení toku do výstupní síťové paměti (OBUF), která potřebuje pro odeslání kompletní datový rámec. Komponenta umožňuje zadávat zpoždění v absolutním nebo relativním formátu. Absolutní formát pracuje s časovou značkou v nanosekundovém tvaru, zatímco relativní formát pracuje s počtem taktů při frekvenci 156.25MHz. Tato frekvence je totožná s rychlostí výstupní síťové paměti, jelikož by při vyšší frekvenci docházelo ke zmenšování vytvořené mezery. Samotná časová značka s výběrem režimu se přenáší ve FrameLinkové hlavičce, která předchází přenosu dat paketu. RX

FL_EXT_SRC_RDY_N

FL_FIFO

FL_EXTRACT EXT_DATA_VLD

{DATA,DREM,EOP_N,EOF_N,SOF_N,SOP_N}} FL_EXT_DST_RDY_N

TX TX_DST_RDY_N

MI32

EXT_DATA

TX_SRC_RDY_N<=FSM_OUT_SRC_RDY MI32 in/out

REL_TIME

EXT_TS_REG MUX_MODE_DATA

LAST_FRAME_TS

FL_EXT_SRC_RDY_N

FSM_OUIT_SRC_RDY_N

TX_DST_RDY_N

FSM

FL_EXT_DST_RDY_N

MUX_MODE

REL_TIME

EXT_EOP_N EXT_EOF_N

TS

TS

MI32

CMP_MODE_MUX

A

CMP A>=B

B

TIME_SENDER DEBUG Framelink signals, FSM state

Obrázek 2.3: Blokové schéma komponenty pro odesílání dle čas dle času Konfigurace je exportována za pomocí komponenty FL_EXTRACT, která umožňuje provádět extrakci dat na pevném umístění, což je v případě přenosu konfigurace zaručeno. Tato data se poté použijí k nastavení jednotky a konečného automatu, který celý proces vytváření mezery řídí. Komponenta je průtoková a její latence je tudíž nulová. Pro účel hledání chyb jsem také implementoval podpůrné registry, které umožňují vyčítat informace, mezi které patří čas odeslání posledního paketu, vyčítání relativního posunu od posledního odeslaného paketu, nastavenou konfiguraci z hlavičky atd. Všechny informace jsou dostupné přes MI32. Blokové schéma popisované komponenty je 30

2.1. Návrh testeru pro 10 Gb/s Ethernet možné vidět na obrázku 2.3. Komponenta FL_FIFO byla v rámci projektu Liberouter vytvořena dříve a je dostupná v základním balíku fl_tools.

2.1.3

Značkování paketů

Pro značkování paketů byla vyvinuta komponenta PACKET_CHECKER, jejíž blokové schéma je uvedeno na obrázku 2.4.

HASH

Framelink in

HASH

TS_STAMP

ID

ID_INSERT ID_INSERT

(sop_n,sof_n,src/dst_rdy)

TS ID+HN

(sop_n,sof_n,src/dst_rdy)

DATA_DISTIBUTION

(sop_n,sof_n,src/dst_rdy)

HASH

HASH_INSERT

Framelink out

conf_en{start/stop} reset_en RESET

sw_reset RESET_GEN

MI32

MI32 in/out

Obrázek 2.4: Blokové schéma komponenty PACKET_CHECKER_SEND Hlavním úkolem této komponenty je vytvoření a vložení hlavičky, která byla uvedena v kapitole 1.4.4 na obrázku 1.16. Na blokovém schématu 2.4 je možné vidět postup výpočtu. Jedná se o postupné vkládání políček hlavičky v pořadí časová značka (TS), identifikační číslo paketu (ID), konstantní identifikátor vkládané hlavičky (HN) a jako poslední se vkládá kontrolní součet. Poslední dvě jmenovaná políčka jsou vložena v částí označené jako HASH_INSERT. Kontrolní součet se počítá na začátku celého procesu vkládání. Výpočet má latenci jedné periody hodin a pro určení hodnoty je využito CRC32. Všechny vkládané hodnoty (ID, TS, HASH) jsou poté distribuovány na jednotlivé vkládací bloky přes DATA_DISTRIBUTION, který je implementován jako série registrů s podmíněnými zápisy tak, aby byla informace dostupná s začátkem FrameLinkového rámce. Jednotka se dá konfigurovat přes MI32 rozhraní. Ovládání je realizováno zápisem do konfiguračního registru (například spuštění vkládání). Mezi hlavní příkazy patří možnost zapnutí vkládání a restartu jednotky. Samotné komponenty na vkládání dat jsou svou architekturou velice podobné. Hlavní částí jsou multiplexory, které vytváří různé posunutí vkládaných dat. V případě 64 bitové sběrnice může být konec rámce na osmi místech. 31

2. Realizace Datový tok na FrameLink protokolu je možné rozšířit o jedno slovo sběrnice. Podle velikosti vkládaných dat mohou nastat dvě situace. První situace je taková, že se rozšíření vleze do aktuálního sběrnicového cyklu a je tedy splněno, že rem + ins_size + 1 <= bus_8 size , kde ins_size odpovídá velikosti vkládaných dat a rem je aktuální hodnota, která vyjadřuje počet platných bytů z posledního slova sběrnice (počítáno od 0). Druhá situace nastane, když se do aktuálního sběrnicového cyklu vleze pouze část dat a zbytek se musí přenést do dalšího přenosového cyklu sběrnice. Tento případ tedy nastane, když rem + ins_size + 1 > bus_8 size . V každém uvedeném případu se navíc musí správně upravit hodnotu na sběrnici REM. Také se musí správně řídit signály EOP_N a EOF_N (aby nebyl porušen protokol FrameLink).

2.1.4

Analýza pořadí a zpoždění

Pro analýzu pořadí a zpoždění se využívá vložené hlavičky (jak bylo popisováno v kapitole 1 - Analýza a návrh). Pro analýzu času potřebujeme dvě hodnoty a to čas příchodu a odchodu paketu. Z těchto dvou hodnot je možné spočítat hodnotu zpoždění. Pro tento výpočet musíme být schopní extrahovat tyto veličiny z příchozích dat. Za tímto účelem byla vytvořena komponenta, která umožňuje extrahovat určitý počet bytů z konce datového rámce. Z těchto vyjmutých dat je pak můžné využít jakýkoliv blok hlavičky k další analýze (pořadí, zpoždění paketu). checker_data_vld

VLD

EXT_DATA

MI32 in/out

MI32

HASH NUM

NUM_CMP

HASH

HASH_CMP

CONFIG

ORDER_CHECK

ID TS

Framelink in

HEAD_EXTRACT PACODAG_TS

HEAD_EXTRACT CHECKER_HEAD

Framelink out

HEAD_TS REG

TS_REG

Packet_delay

TS_SUB checker_data_vld

OUT_DELAY REGS

Packet_delay_vld

Obrázek 2.5: Blokové schéma komponenty PACKET_CHECKER_REC 32

2.1. Návrh testeru pro 10 Gb/s Ethernet Pro výpočet zpoždění není možné, v případě formátu TS_NS (nanosekundový formát), provést pouhé odečtení, protože může přetéct/podtéct nanosekundová část (spodních 32 bitů). Proto se musí korigovat sekundová část výsledku (horních 32 bitů). Pro zlepšení časování a procesu propojení se využije výstupního registru. Výsledek zpoždění je opět zachován v předchozím prezentovaném formátu. Zároveň se druhým výstupem potvrdí jeho validita. Analýza pořadí paketů se provádí pomocí konečného automatu, který implementuje pseudokód 1, který byl popsán v kapitole 1.4.5. Automat provádí řízení čítačů, které se poté dají vyčítat a resetovat přes MI32 rozhraní. Pro realizaci všech popsaných úkonů byla vytvořena komponenta, kterou jsem nazval jako PACKET_CHECKER_REC. Její blokové schéma je možné vidět na obrázku 2.5. rx_src_rdy_n rx_dst_rdy_n rx_eop_n rx_eof_n

frame_part_reset

CNT_PACKET_NO

A

rx_src_rdy_n rx_dst_rdy_n rx_eop_n

frame_part_cnt_en

FRAME_PART CNT

COMP A=B

B

HW_EXT_EN

ext_en

part_offset_reset

A rx_src_rdy_n rx_dst_rdy_n

part_offset_cnt_en

OUTPUT_HW_HEAD_VLD

HW_HEAD_SIZE

BYTE_OFFSET CNT

COMP A<=B

B

H E A D

S H I F T R E G I S T E R

OUTPUT_HW_HEAD E X T R A C T rx_data

{rx_data; rx_src_rdy_n; rx_dst_rdy_n}

rx_src_rdy_n rx_dst_rdy_n rx_eop_n

rx_rem

rx_src_rdy_n rx_dst_rdy_n rx_eop_n

RX

TX

FRAMELINK

FRAMELINK

Obrázek 2.6: Blokové schéma komponenty HEAD_EXTRACT Extrahování vložených dat provádí komponenta HEAD_EXTRACT, která je znázorněna na obrázku 2.6. Samotná realizace je rozdělena do dvou částí, kterými jsou detekce a export dat. Hlavním úkolem detekčního obvodu je nalézt okamžik, kdy jsou k dispozici všechna potřebná data. Tento okamžik se pozná tak, že jsme načetli dostatečné množství dat (udává čítač byte offset), je indikován konec FrameLink rámce a zároveň se provádí extrakce dat ze správné části (hlavička nebo tělo). Poté stojíme již před problémem správného výběru dat z shift registru, který je možné jednoduše vyřešit tím, že je znám konec rámce (informace je obsažena na sběrnici REM). Musíme si proto vytvořit různé posuvy dat, které se přivedou do multiplexoru, jehož výstup je podmíněn hodnotou na sběrnici REM. Tento krok je naznačen 33

2. Realizace blokem HEAD_EXTRACT (kam vstupují posunutá data a aktuální data ze sběrnice). Nastavení hodnot pro extrahování dat je realizováno jako generický parametr při překladu a povolování extrakce se provádí nastavením vstupu HW_EXT_EN do aktivní úrovně (log. 1).

2.1.5

Zahazování paketů

Možnost zahazovat pakety bylo implementovánou pro dosažení maximální rychlosti vstupního směru. Na pomalejší odebírání vstupních dat bude vstupní síťová paměť reagovat zahazováním paketů. V původní implementaci NetCOPE byla vstupní síťová paměť přímo napojena na DMA kanál, který však není schopen přenést všechny příchozí data při plné rychlosti. Na obrázku 2.7 je možné vidět blokové schéma. Vstupem a výstupem z komponenty je protokol FrameLink. Ve výchozím nastavení (tj. po resetu) jednotka zahazuje všechen příchozí provoz. Tohoto dosáhne nastavením signálu DST_RDY_N do aktivní úrovně (log. 0), kterým dává najevo, že je schopna přijímat data. Výstupní signál SRC_RDY_N je pak nastaven na neaktivní úroveň (log. 1), kterým ve výsledku zneplatní veškerý datový tok a DMA řadič tak nebude posílat do RAM paměti žádná data. RX

TX

FRAMELINK(SOP_N,SOF_N,EOP_N,EOF_N,DREM,DATA)

SOF_N

SRC_RDY_N

SOP_N

FSM

DST_RDY_N

SRC_RDY_N DST_RDY_N

config

MI32

MI32 in/out

Obrázek 2.7: Blokové schéma komponenty FRAME_DISCARD Zahazování dat je tedy možné ovládat příslušným nastavením platnosti/neplatnosti RDY_N signálů. Měl by být také uvažován stav, kdy se nastavení zahazování/kopírování může nastat i v průběhu přenosu validního FrameLink rámce. Proto se s tímto musí počítat a zahazování/kopírování provádět až s následujícím validním FrameLink rámcem. Veškerá logika proto byla implementována do konečného automatu, který obstará všechny akce spojené s tímto problémem. Ostatní signály jako DATA, REM, SOP_N, SOF_N, EOP_N a EOF_N mohou být přímo kopírovány na výstup, jelikož je jejich validita podmíněna stavem RDY_N signálů. Jednotka je konfigurovatelná přes MI32 rozhraní. Konfigurace je zapisována do registru, který je na obrázku označen jako config. Mezi další operace je 34

2.1. Návrh testeru pro 10 Gb/s Ethernet možné zařadit schopnost softwarového resetu a vyčítání aktuální konfigurace.

2.1.6

Vytváření statistik

EOP

SOP

EOP_POS

EOP

SOP

SOP_ALIGN

SOP

Jedním z hlavních důvodů vzniku projektu COMET je vytváření statistických informací, pro které se dá využít již implementovaných součástí v NetCOPE. Většina těchto informací je dostupná ze statistického rozhraní pro komponentu PACODAG. Pro část sledovaných veličin jsem proto mohl vytvořit pouze záchytné registry, do kterých jsem podmínil zápis dle aktuálních hodnot signálů (například při hledání maxim a minim). Za použití komparátorů a sčítaček jsem tak mohl implementovat většinu sledovaných veličin, které jsou popsány v tabulce 1.6, která se nachází v předchozí kapitole 1 - Analýza a návrh. Pro funkci měření bytové mezery (IFG) jsem však musel implementovat speciální měřící komponentu, jejíž blokové schéma je uvedeno na obrázku 2.8. Při implementaci této komponenty jsem opět využil statistických signálů síťové paměti (IBUF), které umožňují signalizovat začátek příjmu paketu (SOP), počet zarovnání (SOP_ALIGN), konec paketu (EOP) a jeho pozici (EOP_POS).

<<4

IFG_CNT

-

0

1

IFG

OUT_REG

OUT_REG_DV IFG_DV

+

EOP

IFG_SOP

SOP_ALIGN

SOP

SOP_EOP_PIPE IFG_SOP_EOP

SOP_ALIGN_REG

Obrázek 2.8: Blokové schéma pro měření IFG Výpočet IFG je prováděn v několika fázích. V první fázi je vytvořen dočasný výsledek v čítači IFG_CNT, který se poté musí opravit ve druhé fázi o velikost zarovnání začátku nového paketu. Důvodem této opravy je to, že si IBUF provádí zarovnání na začátek kvůli dalšímu jednoduššímu zpracování. Na obrázku 2.8 je tato oprava znázorněna přičtením/odečtením hodnoty SOP_ALIGN, která je vynásobena konstantou čtyři. Multiplexor na výstupu poté slouží na výběr výsledku, protože mohla nastat i situace, kdy je indikován konec starého a začátek nového paketu zároveň. Tuto variantu je tedy nutné 35

2. Realizace detekovat a reagovat na ni pozměněním výpočtu. Registr SOP_ALIGN_REG slouží pro zapamatování velikosti zarovnání tak, aby mohla tato informace být později použita pro korekci výsledku. Pro zlepšení časování jsou použity výstupní registry. Validita výstupní hodnoty IFG je podmíněna aktivním signálem IFG_DV. V první fázi výpočtu se postupuje tak, že se určí počet nevyužitých bytů v aktuálním slově a poté se bude inkrementovat o hodnotu, která se rovná kapacitě MII linky (v případě XGMII je rovna osmi). Další implementovaná komponenta slouží na vytváření histogramů a její blokové schéma je uvedeno na obrázku 2.9. Pro větší šetření zdroji v FPGA jsem využil dostupných BlockRAM pamětí, které tvoří paměť s prokládaným zápisem vzhledem k latenci aktualizace hodnoty v bloce s názvem HIST_BLOCK_BRAM. Toto primitivum je základním stavebním kamenem, který umožňuje inkrementovat hodnotu čítače v paměti. Jednotlivé bloky se cyklicky střídají a umožní tak v každém taktu vydávat jeden příkaz pro aktualizaci. Adresa pro inkrementaci se vytváří z přivedených dat v bloce s názvem UPDATE_ADDR, který může být konfigurovatelný a umožní tak vytvářet statistiky s různým rozložením (lineární rozdělení, exponenciální rozdělení a další). O cyklické střídání aktualizací se stará blok UPDATE_EN, který přesměrovává povolovací požadavek na jednotlivé bloky. Při vyčítání hodnoty histogramu se poté musí z těchto bloků složit sumární informace. Tento krok je možné realizovat jako sečtení jednotlivých hodnot, které jsou pro lepší časování odděleny registry. Jedním z výstupu základního bloku je i signál, který nás informuje o validitě výstupu. S použitím logického součinu je možné z těchto hodnot získat sumární informaci o validitě výstupních dat. Histogramová jednotka také podporuje inicializaci čítače při čtení, kdy může nastat požadavek čtení a aktualizace zároveň. Tuto funkci je možné realizovat díky dostupnosti druhé brány, kdy se při vyčtení provede zároveň aktualizace hodnoty. Souběh těchto signálů je možné vyřešit pomocí generiky READ_FIRST, kterou umožňuje BlockRAM nastavit při její instanciaci v jazyce VHDL.

2.2

Změny pro rychlosti 40 Gb/s a 100 Gb/s

V této části bych se chtěl věnovat diskuzi o rozšíření na vyšší rychlosti, které by do budoucna mohl projekt COMET také podporovat.

2.2.1

Opakování paketů

Jednou z nejvíce důležitých částí bude funkce opakování paketů, aby bylo možné vytvářet rozestupy o velikosti 12 bytů a zároveň byl vytvořen dostatečný datový tok. Z tohoto důvodu je nutné použít protokol, který umožňuje přenášet data s větší efektivitou (než je tomu u protokolu FrameLink). Tento fakt vedl ke vzniku nezarovnané verze již jmenovaného protokolu, který je znám pod jménem FrameLinkUnaligned (dále jako FLU). Specifikace již byla popsána dříve v kapitole 1.3.2 a jeho velkou výhodou je zejména vlastnost, které umož36

HISTOGRAM UNIT

+

AND

REG

REG

+

REG

+

vld(3)

mi32_rd

MI32

cnt_en

READ_CNT

OUT_VLD

RESET

OUT

RAR_EN

CONFIG

READ_DET

REG

MI32 in/out

RESET

READ_EN

RESET

READ_ADDR

REG

RESET

vld(2)

HIST_BLOCK BRAM vld(3)

HIST_BLOCK BRAM vld(1)

vld(0)

vld(2)

HIST_BLOCK BRAM

HIST_BLOCK BRAM

UPDATE_EN

vld(1)

UPDATE_ADDR

vld(0)

DATA

UPDATE_EN

2.2. Změny pro rychlosti 40 Gb/s a 100 Gb/s

Obrázek 2.9: Blokové schéma komponenty HIST_UNIT

ňuje přenášet konec starého a začátek nového paketu v tom samém slově sběrnice. Tímto způsobem, spolu s větší šířkou sběrnice, bude možné vytvořit dostatečně velký datový tok pro sítě o rychlosti 40 Gb/s a 100 Gb/s. FLU config: SOP_POS_WIDTH=1,DATA_WIDTH=n FLU transaction 1

SOP

EOP

Write address

0x0

SOP FLU transaction 1

0x1

010101010101 0x1

010101010101 0x2

0x2

0x0

010101010101 0x4

0x3

0x1

0x2 EOP

EOP SOP FLU transaction 2

FLU Frame Mem. addresses 1 0x0,0x1,0x2 2 0x3,0x4

0x3

0x2

0x1

0x0

RAM MEMORY 2 read x 2 write ports 010101010101 0x0 Item size: n/2

Read address

FLU transaction 3

FLU transtaction 2

SOP

FLU transaction 3

FLU transaction 4

Obrázek 2.10: Idea realizace opakování Samotnou ideu opakování paketů je možné vidět na obrázku 2.10, kde je 37

2. Realizace vyobrazen postup pro konfiguraci FLU o šířce n bitů a možnosti začátku následujícího paketu na dvou místech. FLU transakce se rozloží na stavební bloky, jejichž velikost záleží na počtu možných pozic začátků. Při dvou možných začátcích má stavební blok velikost n2 , v případě čtyř možných začátků má stavební blok velikost n4 a tak dále. Tyto stavební bloky se ukládají do paměti za sebe, díky čemuž je možné začít s přenosem dat následujícího paketu dříve. Tímto způsobem se navíc lépe využije dostupných vlastností protokolu FLU. Je však také nutné realizovat paměť, která bude mít více čtecích a zapisovacích portů, kde každý má šířku jednoho stavebního bloku (aby bylo možné datový tok rozložit a složit zpět). Těchto portů navíc musí být tolik, kolik je možných začátků paketu. V uvedené ukázce se využívá paměť, která má dva čtecí a dva zapisovací porty o šířce n2 . Samotné skládání výstupního toku pak spočívá v adresování jednotlivých bloků paměti. Na obrázku 2.10 je možné vidět uložení dvou FLU rámců za sebe. Při vyčítání se pak první paket dvakrát opakuje a poté se pokračuje částí dat nového paketu. Je zde možné pozorovat i čtecí/zapisovací sled adres, které by se přivedly na jednotlivé porty.

2.2.2

Výstup na síť

V době vývoje projektu COMET nebyla implementována žádná komponenta, která by byla schopna provádět kódování do XLGMII (40 Gb/s varianta) nebo CGMII (100 Gb/s varianta). Z tohoto důvodu je tedy nutné provést implementaci těchto MII variant tak, aby byl COMET v budoucnu schopen podporovat i tyto vyšší rychlosti. Zároveň se zde otevírá i možnost využití jiných přístupů k řešení síťového testeru. Nabízí se tedy dvě varianty. První varianta počítá se stávající architekturou, která by však pracovala s nezarovnanou verzí FrameLinku. Postupně by tedy docházelo k opakování paketů, vkládání testovací hlavičky, odesílání paketů dle časového údaje a jako poslední krok by se provedlo kódování do XLGMII/CGMII. S tímto přístupem by se musely jednotlivé komponenty na FrameLink protokol upravit tak, aby se mohly použít v případě nezarovnané verze. Výhodou tohoto přístupu by bylo zejména to, že by vznikly nové komponenty, které by se daly využít i v jiných projektech. Druhá varianta počítá s trochu jiným přístupem přenosu dat uvnitř firmwaru. Data by se hned po příchodu skrze DMA převedla do podoby XLGMII/CGMII, která by se pak používala po celou trasu od DMA k výstupu. Tímto přístupem je možné eliminovat výstupní síťovou paměť, ale mimo jiné by se takto dal obejít i samotný FrameLinkUnaligned. Určitá nevýhoda by však spočívala v manipulaci s datovým tokem, kdy by se musely splnit všechny předpoklady, které jsou na XLGMII/CGMII kladeny (například pozice začátku paketu, vytvoření mezipaketové mezery). Jedním z možných řešení by spočívalo ve vkládání dat tak, aby byla vždy zaručena pozice začátku paketu (zarovnáváním na velikost osmi bytů). Tento způsob vytváření mezery je však 38

2.2. Změny pro rychlosti 40 Gb/s a 100 Gb/s značně neefektivní a může vést na velké plýtvání dostupným pásmem. Z tohoto důvodu je ve standardu zakotven princip DIC (Deficit Idle Count), o kterém jsem se již zmínil v kapitole s analýzou problému. Při návrhu komponenty pro převod bude možné využít modifikovaného postupu z předchozí kapitoly. Celý postup uvedu pro variantu s XLGMII. Výstupní rozhraní ve VHDL je specifikováno jako datová sběrnice o šířce 256 bitů, ke které je přiřazena řídící sběrnice o šířce 32 bitů. Každý bit na řídící sběrnici pak odpovídá jednomu bytu na datové sběrnici. Začátek paketu může být celkem na čtyřech pozicích (vždy posun o velikost osmi bytům). Datový tok je tedy můžné rozložit na čtyři nezávislých datových linek o šířce 64 bitů, které se budou ukládat do paměti o čtyřech nezávislých zapisovacích a čtecích portech. Tento přístup má několik výhod. První výhoda spočívá v tom, že získáme vyrovnávací paměť, do které se mohou předčasně uložit data následujícího paketu. Druhá výhoda spočívá v jednoduché realizaci posunu jednotlivých bloků, které v tomto případě budou spočívat pouze v ovládání adres čtecích portů. Pakety jsou do paměti zapisovány za sebe, a tak přesně známe adresu začátku následujícího paketu. Navíc zde musí být implementována určitá predikce ohledně pozice konce paketu (potřebujeme znát poslední blok a pozici posledních dat v tomto bloku). BlockRAM paměť má při čtení latenci jednoho hodinového cyklu. Je tedy nutné na tuto situaci reagovat a případně připravit data následujícího paketu. Do výstupního datového toku se navíc musí vložit preambule, značka začátku paketu (též označována jako SFD), data paketu, kontrolní CRC32, značka konce paketu (též známo jako EFD) a v neposlední řadě také mezera mezi pakety. Minimální hodnota této mezery je rovna velikosti dvanácti bytům. Tato hodnota se však může měnit díky metodě DIC, která byla popsána v kapitole 1. Vkládání CRC32, mezer mezi pakety a preambule se může realizovat pomocí multiplexorů, kdy se provede výběr z možných variant výstupu. Tato soustava však bude potřebovat určité řízení, které se dá realizovat pomocí konečného automatu typu Mealey (na výstupu je vyžadována reakce v tom samém hodinovém cyklu). Tento automat bude muset provádět řízení čtení z paměti a ovládání výstupních multiplexorů tak, aby byl generován platný XLGMII provoz. Určitá nevýhoda může spočívat v možné větší složitosti realizace tohoto řídícího obvodu (je nutné pokrýt všechny možnosti začátku paketu, řízení DIC, vkládání mezipaketové mezery). V obou dvou variantách se bude muset počítat CRC32 po vložení všech potřebných dat. K tomuto výpočtu se dá použít již vzniklých komponent, které byly v průběhu projektu Liberouter vytvořeny. Ukázku možné realizace tohoto obvodu je možné vidět na obrázku 2.11. Tato ukázka má na svém vstupu nezarovnaný protokol FrameLinkUnaligned, který je dekódován v bloce s názvem FLU DECODER. Výstup tohoto bloku je poté přiveden do jednotky PACKET WRITER, která se stará o zápis dat do paměti. Zapisovaná data obsahují kromě dat i indikaci konce a začátku paketu, ale mimo jiné i počet platných bytů v rámci posledního datového bloku. Tyto informace se poté dají využít v konečném automatu (blok FSM) 39

2. Realizace k řízení výstupních multiplexorů. Informace ohledně začátku a konce rámce jsou předávány jeden hodinový cyklus předem. Důvodem tohoto přístupu je situace, kdy XLGMII slovo obsahuje data předchozího paketu, mezipaketovou mezeru, preambuli a data následujícího paketu. Tímto přístupem je možné eliminovat čtecí latenci o velikosti jedné hodinové periody a zpřístupnit tak data v okamžik jejich použití. Výstupní multiplexory pak slouží ke vložení preambule, mezipaketové mezery, hodnoty CRC32 a v neposlední řadě také dat vysílaného paketu. DATA1

Write ports

64

EOP_POS1

69

DATA1_SOP

PORT1

DATA1_EOP DATA1_EOP_POS

F L U

DATA2

D E C O D E R

64

DATA2_SOP DATA2_EOP DATA2_EOP_POS

FLU

3

DATA3

3 64

DATA3_SOP DATA3_EOP DATA3_EOP_POS

DATA4

3 64

69

IDLES & EFD IDLES

64 PORT2

P2_SEL DATA DATA & CRC

PORT2

W R I T E R

IDLES & EFD & CRC IDLES & EFD IDLES

EOP_POS3

69

64 PORT3

DATA2_CHANGE_SEL

XLGMII_TXD(127 downto 64) PREAMBLE

EOP2

4PORT RAM

P3_SEL DATA DATA & CRC

PORT3

DATA3_CHANGE_SEL

XLGMII_TXD(191 downto 127) IDLES & EFD & CRC

PREAMBLE

EOP3

IDLES & EFD IDLES

EOP_POS4

69 PORT4

P4_SEL

64

PORT4

DATA DATA & CRC

PREAMBLE

EOP4

EOP_POS1

CRC_REG

CRC_VAL

DATA4_CHANGE_SEL

XLGMII_TXD(255 downto 192)

3

FIFO

DATA1_CHANGE_SEL

IDLES & EFD & CRC

PREAMBLE

EOP_POS2

WR_EN

CRC_UNIT

DATA DATA & CRC

XLGMII_TXD(63 downto 0)

P A C K E T

DATA4_SOP

DATA

P1_SEL

64

PORT1

EOP1

DATA4_EOP DATA4_EOP_POS

Read ports

IDLES & EFD & CRC IDLES & EFD IDLES

EOP1 & EOP2 & EOP3 & EOP4

EOP_POS2 EOP_POS3 EOP_POS4

DATA#_CHANGE_SEL

DOWN RESET EOP#

UP

P#_SEL

PACKET COUNTER

XLGMII_TXC FSM VALUE

Obrázek 2.11: Návrh realizace obvodu pro kódování do XLGMII Na obrázku 2.12 je naznačena možná realizace výstupní síťové paměti, kterou je možné využít pro generování výstupního toku. Vstupním protokolem by byl standardní FrameLink, který se používá pro přenos dat z DMA. V datovém toku by došlo k alokaci místa pro značku, která by se vkládala později na XLGMII (z důvodu větší přesnosti). Hodnota CRC32 by se opět počítala z XLGMII toku, kam by následně byla vložena. Tímto přístupem by mělo být možné vygenerovat validní výstupní tok. Výstupní síťová paměť by navíc měla podporovat možnost opakování paketů, ale také odesílání podle specifikovaných časových značek. Rozpracovaná verze výstupní síťové paměti bude součástí přiloženého CD. V průběhu implementace jsem však také zjistil fakt, že nebude možné použít stejného přístupu ke generování CLGMII (100 Gb/s). Důvodem je to, že již nebude nejspíše možné realizovat řídící automat tak, aby byla dosažena minimální pracovní frekvence 156.25 MHz. Bude proto nutné přistoupit k jiné realizaci, díky které bude možné tento problém vyřešit. Tímto novým přístupem by mohla být realizace pomocí registrů, ve kterých 40

2.2. Změny pro rychlosti 40 Gb/s a 100 Gb/s CRC XLGMII FraneLink in

FL STAMP ALOC.

FL --> FLU

FLU

XLGMII_ENC

XLGMII STAMP

XLGMII CRC

CRC

XLGMII CRC INSERT

XLGMII

STAMP GEN.

TS

ID

Obrázek 2.12: Návrh realizace výstupní síťové paměti pro XLGMII

by se uschovala data, která se nedostala do aktuálního výstupního datového toku. Vyrovnávací paměť, která je realizována pomocí BlockRAM, by se zachovala, aby bylo možné předčasně uložit více paketů k odeslání. Došlo by tak i ke zkrácení kritické cesty, což by vedlo k lepší výsledné frekvenci. XLGMII tok by se samozřejmě dal zkonstruovat z aktuálních a uložených dat (uschovaných v registrech). Řídící logika (podobná té, která je již realizována pro XLGMII) by se poté musela postarat o vložení preambule, paketové mezery a v neposlední řadě také místa pro vložení CRC32.

2.2.3

Vstup ze sítě

Z důvodu existence vstupního síťové paměti (IBUF) pro XLGMII bych využil přístup, který je použit v projektu COMET nyní. Na výstupu síťového paměti jsou přijatá data vysílána protokolem FrameLinkUnaligned, který by se pak používal k práci s daty v následujících komponentách. V průběhu vývoje vstupní síťové paměti se provedly určité změny v signalizaci začátku a konce paketu (ty jsou využity k analýze mezery mezi pakety). Kvůli této signalizaci se bude muset upravit statistická jednotka, která se vytvářela v době, kdy byla vstupní síťová pamět pro XLGMII ve fázi návrhu. Po prostudování tohoto nového bloku bych navrhoval realizovat počítání síťových statistik za pomocí signalizace, které se bude dát získat z části dekódování XLGMII provozu. Charakterem je tato signalizace velice podobná protokolu FrameLinkUnaligned, a proto by se měly dát přesně zjistit pozice konce a začátku paketu. Realizace ostatních statistik bude závislá na tom, jak návrháři implementují statistické rozhraní vstupní síťové paměti. Určité změny se však budou muset také realizovat v jednotce, která slouží pro analýzu vkládané hlavičky. Hlavní změna by se týkala výměny komunikačního protokolu z FrameLinku na FrameLinkUnaligned. Určitá komplikace se zde však skrývá v tom, že komponenta PACODAG nemůže provádět značkování tak, jak prováděla doposud. Hlavní příčinou je to, že FrameLinkUnaligned neumožňuje vytváření částí tak, jak to bylo možné u zarovnané verze protokolu FrameLink. Z tohoto důvodu se budou nejspíše data distribuovat přes nezávislou cestu do jednotlivých komponent. Postup extrakce dat z toku by se však nemělo žádným zásadním způsobem měnit. Jediné změny by zde mohly nastat v pravidlech, kterými se řídí kontrolní logika. Způsob ukládání 41

2. Realizace a posuvu slov se však měnit nemusí. Další změny se budou muset realizovat v jednotce pro zahazování toku (kvůli rychlosti DMA kanálu, který nedosahuje takové přijímací rychlosti). Hlavní změna by se týkala schopnosti vymaskovat signál, který slouží k signalizaci začátku následujícího paketu. Tento přístup by se použil, pokud by v průběhu přenosu paketu po FLU došlo k zapnutí zahazování paketů. Jednotka by v tomto případě měla dokončit přenos aktuálního paketu (tzn. nemaskovat signál konce rámce) a nepovolit přenos následujícího paketu (tzn. maskovat signál začátku rámce), který může nastat v tom samém slově. V době vzniku této práce jsem již započal s úpravy všech potřebných komponent ve vstupním směru, které jsem ověřil v simulačním nástroji Modelsim. Určité změny, oproti původní verzi, jsem musel provést v komponentě vstupního bloku, který jsem označil jako PACKET_CHECKER. Časová značka příchozího paketu, která se použije dále pro výpočet zpoždění, se musí vystavit s začátkem FLU rámce. Co nejpřesnější časovou značku příchozího paketu je možné odvodit z vnitřních signálu vstupní síťové paměti. Tato značka se poté přenese do interní hodinové domény pomocí asynchronní FIFO fronty. Další možnost by spočívala v odvození časové značky za síťovou pamětí. Nevýhodou tohoto řešení by byla menší časová přesnost příchozího paketu. Upravené komponenty pro rychlejší verzi testeru budou součástí přiloženého CD.

42

Kapitola

Výsledky a testování 3.1

Testování

Samotné testování vytvořených částí probíhalo v menších blocích, kde bylo pro každou komponentu vytvořeno behaviorální simulační prostředí. Tento přístup umožnil, v případě úpravy, rychle otestovat funkčnost obvodu. Při této simulaci byly využity komponenty pro generování a příjem provozu na jednotlivých sběrnicích jako je FrameLink nebo MI32. Výhodou jejich použití je zejména to, že se v simulacích na projektu Liberouter používají delší dobu. Dá se tedy předpokládat, že s jejich použitím je možné objevit různorodé chyby již v části návrhu. Komponenty umožňují odesílání/příjem dat z/do souboru, který je možné využít pro porovnání výsledků simulace. Realizace testeru je dostatečně parametrizovatelná z vkládaných VHDL souborů, kde je mimo jiné možné aktivovat mód pro hledání chyb. Tento mód spočívá v tom, že se do návrhu vloží logický analyzátor, který se v prostředí Xilinx nazývá ChipScope Pro. Sondy (ILA) a řadič (ICON) se dají vygenerovat v nástroji Coregen, který je dosutpný u vývojového prostředí pro FPGA od firmy Xilinx. Při samotném použití je dovoleno mít v návrhu jeden řadič (ICON), na který je možné napojit více logických sond (ILA). Do těchto sond jsou přivedeny sledované signály. Aplikace ChipScope Pro nám pak slouží k nastavení spouštěcích podmínek, prezentování výsledku měření, exportování zachycených dat a jejich následné analýze v prostředí Modelsim atd. Díky této metodě bylo možné sledovat co se děje na fyzické úrovni, díky čemuž se mohla lépe lokalizovat chyba. Navíc je tímto způsobem možné ověřit to, že daná implementace měří správně všechny sledované statistiky (například IFG). Generování dat pro testy v kartě COMBOv2 LXT155-10G2 bylo potřeba otestovat výstup a vstup paketů. V případě testování výstupu byl použit program pcap2sze, který byl vytvořen Bc. Tomášem Čejkou. Tento nástroj vznikl v průběhu práce na projektu COMET a umožňuje odesílání dat ze zachycených nebo generovaných pcap souborů přes SZE2 kanál. Navíc vkládá konfigurační hlavičku, která byla popsána v kapitole 1 - Analýza a návrh řešení. Ve výs43

3

3. Výsledky a testování tupním směru se navíc mohou vkládat dodatečná data, která mohou být následně analyzována logickým analyzátorem ChipScope Pro nebo síťovým analyzátorem od firmy Spirent Communications. Tento analyzátor má bohaté nastavení pro generování, analyzování a řízení síťového toku. V době vývoje byly na projektu dostupné dva analyzátory s podporou 10 Gb/s sítě. Jedná se zařízení AX/4000 a TestCenter 2000 (zkráceně TC2000). Více informací je možné nalézt na stránkách výrobce zde [13] (AX/4000) a zde [14] (TC2000). Na obrázku 3.1 je možné vidět ukázku ovládacího softwaru pro AX/4000 s jedním rezervovaným 10 Gb/s rozhraním.

Obrázek 3.1: Ukázka GUI pro Spirent AX/4000 V rámci projektu se také pracovalo na softwaru, který se nazývá comstat a jeho autorem je Bc. Tomáš Čejka, který podrobně pojednává o této části ve své diplomové práci [17]. Mezi základní funkce aplikace patří vyčítání, konfigurace a prezentace výsledků přes webové rozhraní, které je dostatečně nastavitelné pomocí XML souboru. V tomto konfiguračním souboru se hlavně zadává adresní rozsah jednotlivých komponent, které jsem v rámci projektu vytvořil. Díky tomuto je možné jednoduše deklarovat nové konfigurační registry, pole hodnot, popisky těchto hodnot na webové stránce, atd. Aplikace provádí export do HTML kódu. Také umožňuje volání knihovních funkcí pro ovládání MI32 sběrnice nebo SZE2 kanálu. Navíc může být využívána z webového prohlížeče a nemusí se proto provádět instalace žádné speciální aplikace do uživatelova operačního systému. Ukázku z této aplikace je možné vidět na obrázku 3.2, kde je vyobrazeno ovládání modulu pro vytváření základních statistik. 44

3.2. Dosažené výsledky

Obrázek 3.2: Ukázka HTML stránky generované aplikací comstat (převzato z [17])

Pro testování nejnovějších funkcí, které nebyly v tu dobu podporovány aplikací comstat, jsem vytvořil sadu testovacích skriptů, které využívají externí aplikace csbus. Tato aplikace vznikla na projektu již dříve a umožňuje nám iniciovat čtecí a zapisovací operace přes MI32 sběrnici, která je využita pro nastavování a vyčítání jednotlivých komponent. Všechny funkce těchto skriptů jsou však již v současné aplikaci comstat podporovány a pro ovládání nejsou tedy podstatné. Je však dobré je použít v případech, kdy nemáme přístup k webové stránce a potřebujeme provádět analýzu testeru z terminálu vývojového serveru.

3.2

Dosažené výsledky

V této kapitole se budu zabývat způsobem testování a dosažených výsledků projektu COMET. V následující tabulce 3.1 je uvedena spotřeba zdrojů pro programovatelný obvod FPGA Virtex-5 (typové označení XC5VLX155T) a pro ukázku i na novější obvod Virtex-6. Tabulka také obsahuje odhad pracovních frekvencí, na kterých by mělo být možné jednotlivé domény připojit. V kapitole 2 bylo uvedeno, že návrh obsahuje dvě hodinové domény. Výsledky interní hodinové domény jsou uvedeny v řádku s názvem fclk_in . Teoretické rychlosti pro síťovou hodinovou doménu je možné vidět v řádku s názvem fclk_out . Všechny uvedené frekvence odpovídají odhadům po syntéze.

3.2.1

Ztrátovost paketů

Při měření tohoto chování bylo zjištěno, že nedochází k zahazování paketů. Data byla generována analyzátorem TestCenter 2000. Generoval jsem pakety o velikosti 64, 65, 127, 128, 512, 513, 768, 1023, 1024, 1280 a 1518 bytů, vždy 45

3. Výsledky a testování Čip LUT Registers BlockRAM fclk_in fclk_out

Virtex-5 LX155T 18517 13286 40 240.409 MHz 201.401 MHz

Virtex-6 VHX565T 17512 13257 42 263.145 MHz 231.024 MHz

Tabulka 3.1: Spotřeba zdrojů (nástroj XST 13.1;speed grade -2) Velikost paketu 64 65 127 128 512

Ztraceno 0 0 0 0 0

Velikost paketu 513 768 1024 1280 1518

Ztraceno 0 0 0 0 0

Tabulka 3.2: Výsledky testu ztrátovosti paketů

s dobou trvání dvou minut (při plném datovém toku linky). Při testování jsem využil zkušeností testerů, kteří se na projektu Liberouter podíleli. Tímto testem prošel projekt COMET již dříve. Výsledky tohoto testu jsou uvedeny v tabulce 3.2. Projekt COMET je tedy schopen zpracovat večkerý příchozí provoz při plné rychlosti linky 10Gb/s. Za celou dobu testu bylo celkem přijato 6698907058 paketů.

3.2.2

Měření IFG

Při měření tohoto parametru jsem opět vycházel ze zkušeností testerů. Jednotlivé hodnoty IFG jsem zkoumal pomocí ChipScope Pro s výsledkem, že měřené mezery odpovídají hodnotám zobrazených v programu comstat. Jednu z ukázek měření je možné vidět na obrázku 3.4, jehož vysvětlení je uvedeno v kapitole 3.2.8.

3.2.3

Ověřování funkce histogramů

Zde jsem hlavně prováděl testování toho, že histogramová jednotka je schopna zvládnout zpracovat veškeré příchozí požadavky. V COMBO kartě se i tato jednotka chovala dle simulace a zpracovala všechny příchozí požadavky. I při delším běhu se počet přijatých paketů shodoval nejen s hodnotou v příchozí síťové vyrovnávací paměti (IBUF), ale i s hodnotou odeslaných paketů z analyzátoru Spirent. Z tohoto výsledku jsem usoudil, že nebude nutné provádět testy funkce dalších histogramů, protože všechny tyto jednotky jsou totožné. Prezentované výsledky z histogramové jednotky budou proto závislé na nas46

3.2. Dosažené výsledky tavení jednotlivých rozsahů a správnosti hodnot, ze kterých se histogram vytváří. Po úspěšném provedení této fáze bylo možné přistoupit k otestování měřených veličin. Při testování histogramu velikosti paketů jsem postupně generoval pakety velikostí 64, 128, 256, 512, 1024, 1280, 1518 (podle dokumentu [1]). K těmto hodnotám jsem navíc přidal velikost 888. Pakety vždy byly generovány maximální možnou rychlostí linky. V tabulce 3.3 jsou uvedeny počty generovaných paketů v závislosti na velikosti. Ve výpisu, který následuje po tabulce 3.3, je možné vidět výstup skriptu, který jsem užíval pro vyčtení výsledků z jednotky. Z naměřených výsledků je možné vidět, že celkový počet paketů, který je uveden v tabulce, byl také zpracován. Z výpisu je také možné pozorovat, že docházelo k inkrementaci hodnot ve správných rozsazích. Z grafu 3.3 je pak možné vidět porovnání teoretické hodnoty počtu příchozích paketů s počtem reálně zpracovaných paketů (pro případ 10Gb/s linky). Výstup histogramu velikostí paketů Histogram data: 1 : 0 - 63 :--> 0 2 : 64 - 127 :--> 1804852234 3 : 128 - 191 :--> 1019883993 4 : 192 - 255 :--> 0 5 : 256 - 319 :--> 550529795 6 : 320 - 383 :--> 0 7 : 384 - 447 :--> 0 8 : 448 - 511 :--> 0 9 : 512 - 575 :--> 287005313 10 : 576 - 639 :--> 0 11 : 640 - 703 :--> 0 12 : 704 - 767 :--> 0 13 : 768 - 831 :--> 0 14 : 832 - 895 :--> 167576169 15 : 896 - 959 :--> 0 16 : 960 - 1023 :--> 0 17 : 1024 - others :--> 362155637 ---------------------------------------------------------Received packets: 4192003141 Duration: 0h:10min:49sec = 649sec Testování měření mezer mezi pakety jsem ověřil v simulaci a pomocí nástroje ChipScope Pro, protože jsem v nastavení analyzátoru TC2000 nenalezl možnost vytváření přesně definovaných mezer. V tomto případě také používám ověřenou jednotku na vytváření histogramů. Je tedy možné předpokládat, že při správném nastavení jednotky by mělo docházet k inkrementaci nastavených rozsahů podle aktuální vstupní hodnoty naměřené mezery. 47

3. Výsledky a testování Generovaná velikost paketu 64 128 256 512 888 1024 1280 1518 Paketů celkem

Generovaný počet paketů 1804852234 1019883993 550529795 287005313 167576169 145638744 117412308 99104585 4192003141

Tabulka 3.3: Nastavení parametrů paketů síťového analyzátoru

Obrázek 3.3: Zpracovaný počet paketů za sekundu na 10Gb/s lince

3.2.4

Další statistiky

Další statistiky, jako jsou čítače paketů s větším MTU a velikostí pod 64B, jsem ověřoval pomocí speciálního nastavení jednotky IBUF. Jedním z možných nastavení je právě stanovení horní meze velikosti paketu. Jednotce IBUF jsem nastavil MTU na hodnotu 64B. Síťový analyzátor celkem odeslal 937778116 paketů o velikosti 146 bytů. Můžu tedy předpokládat, že veškerý tok ze sítě 48

3.2. Dosažené výsledky bude v jednotce IBUF zahozen. Statistická jednotka naměřila 937778116 příchozích paketů, které velikostí překročily nastavené MTU. Podobným postupem je možné ověřit i počet paketů, jejichž velikost byla pod minimální velikost paketu. V síťovém analyzátoru jsem generoval 1112182658 paketů s velikostí 58 bytů. Opět jsem tedy mohl předpokládat, že veškerý vstupní tok bude zahozen. Statistická jednotka naměřila celkem 1112182658, které velikostí neodpovídaly minimální možné hodnotě paketu. Měření statistiky chybných CRC32 bylo možné otestovat za použití analyzátoru TC2000 od firmy Spirent Communications. Jedním z nastavení generování síťového toku je mimo jiné i vkládání chyb. Celkem jsem generoval 1177576538 paketů, do kterých jsem nechal vkládat chyby. Z celkového počtu bylo odesláno 603315 paketů s chybným obsahem. Statistická jednotka naměřila stejný počet 603315 chybných paketů. Hodnota chybných paketů byla také kontrolována s čítačem, který je umístěn v jednotce IBUF.

3.2.5

Testování vkládání hlavičky do síťového toku

Tuto funkci jsem ověřoval ve dvou fázích. V první fázi jsem sledoval datový tok na síťovém analyzátoru, kde jsem mohl přesně určit polohu a obsah vkládané hlavičky. V druhé fázi testování jsem využil komponent, které s touto hlavičkou pracují, a přes vytvořenou zpětnou smyčku z výstupu na vstup jsem mohl ověřit validitu těchto vkládaných dat. I v tomto případě jsem přes vytvořený skript vyčetl odpovídající počet paketů, které hlavičku obsahovaly. Následující data byla zachycena síťovým analyzátorem Spirent AX/4000, kde jsou vyznačena vložená data z aplikace. Prvních vyznačených osm bytů odpovídá vložené časové značce, dalších pět bytů odpovídá vložené informaci o pořadí paketu a posledních pět označených bytů odpovídá vložené konstantě a CRC32. 00 00 00 00 B4 79

00 2E 01 00 53 0E

01 FF 00 00 42

00 FF 00 00 4F

00 00 00 00 0F

01 00 00 00 27

00 FF 00 00 01

10 FD 00 00 00

94 39 00 00 00

00 7A 00 00 C0

00 C0 00 00 4B

02 55 00 00 5C

08 01 00 0F A2

00 02 00 05 02

45 C0 00 29 AC

00 00 00 37 71

Naznačení pozice vkládaných informací bylo uvedeno již dříve v textu. Pro připomenutí se jedná o obrázek 1.17 v kapitole 1 - Analýza a návrh.

3.2.6

Zpoždění paketů

Tuto funkci jsem ověřoval zejména v simulačním prostředí Modelsim. Nicméně je možné i tuto měřenou veličinu sledovat pomocí ChipScope Pro. K analýze zpoždění se využívá časové značky, která je vložena do datového toku. Tuto 49

3. Výsledky a testování časovou značku je možné vidět na výpisu v předchozí části, kde je uveden hexadecimální výpis jednoho ze zachycených paketů. Jeden z provedených testů je uveden v následujícím textu v kapitole 3.2.8.

3.2.7

Generování datového toku

Výpočet teoretické hodnoty počtu paketů za sekundu je možné provést dosazením do vzorce 3.1 za jednotlivé proměnné, kde velikost_paketu odpovídá součtu velikostí preambule, SFD, zdrojové a cílové MAC, typu, datové části a CRC32. Proměnná IFG pak odpovídá bytové mezeře mezi pakety. Tabulka 3.4 pak obsahuje výsledky pro minimální a maximální velikosti paketu, kde je také započítána preambule a mezipaketová mezera o velikosti dvanácti bytů. Tato mezera se však může měnit pomocí principu DIC. Z naměřených dat mohu usoudit, že aplikace umožňuje generovat dostatečný datový tok pro pokrytí teoretických hodnot, které jsou uvedeny v tabulce. počet paketů = d

rychlost_linky e (velikost_paketu + IF G) ∗ 8

Část přenosu IFG Preambule a SFD Zdrojová a cílová MAC Typ Datová část CRC32 Velikost paketu s IFG Počet paketů za 1s (10 Gb/s) Naměřená hodnota (AX/4000)

Min. velikost 12 B 8B 12 B 2B 46 B 4B 84 B 14880953 14881094

[f /s]

(3.1)

Max. velikost 12 B 8B 12 B 2B 1500 B 4B 1538 B 812744 812754

Tabulka 3.4: Seznam velikostí jednotlivých částí

3.2.8

Odesílání paketů v definovaných intervalech

Základní ověření vytvářených mezer jsem prováděl v prostředí ChipScope Pro. Na obrázku 3.4 je uvedena ukázka pro nastavenou mezeru 80 ns. Část číslo jedna odpovídá řídící sběrnici, po které se přenáší význam dat na datové sběrnici (na obrázku označena číslem dvě). Na určité místo je tedy vložen IDLE, pokud se na datové sběrnici objeví hodnota 0x07 a na řídící sběrnici je vložena logická 1. Na obrázku je tedy vlevo ukončen paket a následně jsou vloženy IDLE pro vytvoření rozestupu. Je však důležité poznamenat, že mezera je vytvářena od konce předchozího ke konci následujícího paketu (do vytvářeného rozestupu se tedy započítává i přenos dat). Na obrázku 3.4 je 50

3.2. Dosažené výsledky naznačen počet taktů v jednotlivých částech přenosu. Celkový součet taktů je roven hodnotě 14 a celkový čas od jednoho konce do druhého (včetně) je rovna hodnotě 89 ns. Tato větší prodleva je způsobena komponentou pro odesílání v definovaných intervalech, kde musel být zaveden pipelinovaný komparátor (z důvodu dosažení lepšího časování). Toto zpoždění by se však dalo kompenzovat pomocí konstanty, která by odpovídala jedné periodě hodinového signálu. Pro další verzi testeru COMET bude tato oprava zakomponována v nové jednotce pro odesílání paketů v definovaných intervalech. 1 2 Konec paketu 4

6

3

Konec paketu 1

Obrázek 3.4: Ukázka vytvořené mezery na XGMII Druhá fáze testování spočívala ve vytvoření loopbacku, který bude veškeré odeslané pakety přeposílat na vstup. Takto bude možné vložit do generovaného výstupního toku kontrolní hlavičku, která slouží k testování zpoždění na síti. Použité testovací parametry jsou uvedeny v tabulce 3.5. Nastavený rozestup 2.5 ms 400 µs 80 µs 10 µs 2 µs Celkem

Počet odeslaných paketů 48010 300010 1500010 12000010 60000010 73848050

Tabulka 3.5: Nastavení rozestupů testovacích dat V následující části textu je výstup jednoho z testovacích skriptů, kde je uveden výsledek experimentu. Celkem bylo provedeno pět testovacích měření, při kterých se využilo implementovaného odesílání dle časového údaje obsaženého ve FrameLinkové hlavičce. Výstupem testovacího skriptu jsou obsahy jednotlivých polí histogramu, které reprezentují počet výskytů vypočtených hodnot z příchozích paketů. Z výsledků a přiložené tabulky 3.5 je možné vidět, že docházelo k inkrementacím ve správných rozsazích hodnot. Při relativním režimu odesílání se může stát, že první paket je odeslán okamžitě. Důvod tohoto chování je to, že se relativní čas počítá od posledního odeslaného paketu. Proto je zde započteno pět paketů v rozsahu < 0 − 1µs). Mezi zbývajícími pakety se poté vytvoří konstantní rozestup, a tak dojde k inkrementaci na intervalech, které spadají do jednotlivých rozsahů. Celkový počet všech zpracovaných hodnot se shoduje s počtem odeslaných paketů, kterých je v tomto 51

3. Výsledky a testování případě 73848050. Jednotka na histogramy tedy neztratila ani jeden příchozí požadavek. Výstup histogramu zpoždění Histogram data: 1 : <0 - 1us) :--> 5 2 : <1us - 1.2us) :--> 0 3 : <1.2us - 1.5us) :--> 0 4 : <1.5us - 1.9us) :--> 0 5 : <1.9us - 3.9us) :--> 60000009 6 : <3.8us - 7.8us) :--> 0 7 : <7.8us - 15us) :--> 12000009 8 : <15us - 31.2us) :--> 0 9 : <31.2us - 62us) :--> 0 10 : <62us - 125us) :--> 1500009 11 : <125us - 250us) :--> 0 12 : <250us - 500us) :--> 300009 13 : <500us - 1ms) :--> 0 14 : <1ms - 2ms) :--> 0 15 : <2ms - 3ms) :--> 48009 16 : <3ms - others) :--> 0

3.3

Celkové hodnocení testů

Výsledky provedených testů naznačují, že implementace 10 Gb/s verze Ethernetového testeru COMET je funkční a naměřené hodnoty se shodovaly s teoretickými předpoklady. Velice důležitý parametr je hlavně nulová ztrátovost paketů a schopnost testeru zpracovat veškerý příchozí síťový provoz. O tomto výsledku vypovídají zejména histogramy, které tento fakt názorně prezentují ve výpisu z testovacího skriptu.

52

Závěr Úkolem této diplomové práce bylo implementovat základní Ethernetový tester pro síť 10 Gb/s a zároveň diskutovat změny pro dosáhnutí vyšších přenosových rychlostí (40/100 Gb/s). Během vzniku jsem se podrobněji seznámil se standardem IEEE 802.3ae (10 Gb/s), IEEE 802.3ba (40/100 Gb/s), ale také s pokročilejším návrhem akcelerovaných algoritmů pomocí programovatelného hardware. V první části byla provedena teoretická analýza problému, na jejímž základě probíhala implementace pro 10 Gb/s verzi. Zároveň byla v této části stručne popsána cílová platforma, ale také VHDL základ síťových aplikací zvaný NetCOPE. Při návrhu 10 Gb/s verze jsem kladl důraz na modularitu, která by vedla na jednodušší rozšiřitelnost v budoucnu (například přidání nových funkcí, výměna bloků pro měření statistik). Jednotlivé stavební bloky byly simulovány, aby se zkontrolovala funkčnost a zároveň se eliminovalo co nejvíce možných chyb. Byl také vytvořen návrh hlavičky protokolu, který slouží pro základní analýzu pořadí a výpočtu času, který potřebuje paket pro průchod sítí. Postup testování se skládal z několika fází. První fáze byla založena na simulacích v prostředí Modelsim, kde se dala ověřit základní funkčnost celého řešení. Po úspěšném absolvování předešlé fáze bylo možné přejít na testování v COMBO-LXT kartě, která je vybavena FPGA obvodem s typovým označením Virtex-5. Části, které byly zaměřeny na měření síťových parametrů, se také ověřovaly pomocí logického analyzátoru Chipscope Pro, který umožňuje ladit celý firmware pomocí JTAG rozhraní. Pro generování testovacího provozu se dalo využít síťového testeru od firmy Spirent Communications, který je dostatečně konfigurovatelný. Sloužil také jako určitý referenční bod při testech zaměřených na sběr statistik. Pro testování nových funkcí, v té době bez softwarové podpory, byla vytvořena sada skriptů, které využívaly již vzniklých nástrojů v rámci projektu Liberouter. Projekt COMET prošel jednotlivými testy s dobrými výsledky a naměřená data odpovídala teoretickým předpokladům. Při návrhu testeru se tedy základní VHDL platforma NetCOPE osvědčila, protože mi umožnila zrychlit vývoj celého projektu COMET.

53

Závěr

Budoucí práce Implementovaný prototypEEthernetového testeru pro 10 Gb/s síť bych v budoucnu rád rozšířil o podporu vyšších rychlostí. Z tohoto důvodu bude nutné implementovat kódování do XLGMII (40 Gb/s) a CGMII(100 Gb/s) pro podporu odesílání na těchto rychlostech. S prací na kódování do XLGMII jsem začal již v době psaní této práce. Výsledná implementace je součástí přiloženého CD. Určitého zlepšení by se dalo také dosáhnout tím, že by se místo FrameLink a FrameLinkUnaligned mohl po celé datové cestě využívat protokol XGMII(pro 10 Gb/s), XLGMII(pro 40 Gb/s) a konečně také CGMII(pro 100 Gb/s). Hlavním přínosem tohoto přístupu by byla eliminace výstupní síťové paměti (OBUF), kdy by se vytvořený provoz od DMA mohl rovnou vysílat na síťovou linku. Dalším možným vylepšením by bylo rozšíření o možnost sledování dalších síťových parametrů, možnost uživatelsky konfigurovatelných rozsahů histogramů a optimalizace již vzniklého řešení.

54

Literatura [1]

Bradner, S.; McQuaid, J.: Benchmarking Methodology for Network Interconnect Devices. RFC 2544, RFC Editor, Květen 1999. Dostupné z WWW:

[2]

CESNET z.s.p.o.: Programovatelný hardware [online]. 2008 [cit. 7. května 2012]. Dostupné z WWW:

[3]

CESNET z.s.p.o.: Programovatelný hardware [online]. 2009 [cit. 7. května 2012]. Dostupné z WWW:

[4]

CESNET z.s.p.o.: Programovatelný hardware [online]. 2010 [cit. 7. května 2012]. Dostupné z WWW:

[5]

Cisco: Bandwidth, Packets Per Seconds, and Other Network Performance Metrics [online]. 2012 [cit. 7. května 2012]. Dostupné z WWW:

[6]

INVEA-TECH a.s.: COMBO FPGA karty [online]. 2012 [cit. 7. května 2012]. Dostupné z WWW:

[7]

Liberouter: Description of COMBO cards [online]. 2008 [cit. 7. května 2012]. Dostupné z WWW:

[8]

Liberouter: NetCOPE Firmware Guide. 2011 [cit. 7. května 2012]. Dostupné z WWW:

[9]

Liberouter: FrameLink. 2011 [cit. 7. května 2012]. Dostupné z WWW: 55

Literatura [10] Liberouter: FrameLink [online]. 2011 [cit. 7. května 2012]. Dostupné z WWW: [11] Liberouter: Interconnection system [online]. 2011 [cit. 7. května 2012]. Dostupné z WWW: [12] Liberouter: FrameLinkUnaligned Specification [online]. 2012 [cit. 7. května 2012]. Dostupné z WWW: [13] Spirent Communications: AX/4000 [online]. 2012 [cit. 7. května 2012]. Dostupné z WWW: [14] Spirent Communications: Spirent TestCenter [online]. 2012 [cit. 7. května 2012]. Dostupné z WWW: [15] The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA: Part 3:Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. 2002, IEEE Std 802.3aeTM -2010 , ISBN 0-7381-3288-8. [16] The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA: Part 3:Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. 2010, IEEE Std 802.3baTM -2010 , ISBN 978-0-7381-6322-2. [17] Tomáš Čejka: Control software for the COMbo Ethernet Tester and its integration into the Netopeer configuration system. Diplomová práce, České vysoké učení technické, Fakulta informačních technologií, 2012 [cit. 7. května 2012]. [18] VYKOPAL, J.: Metody testování výkonu prvků síťové infrastruktury [online]. Bakalářská práce, Masarykova univerzita, Fakulta informatiky, 2006 [cit. 2012-04-30]. Dostupné z WWW: [19] Xilinx: Virtex-5 FPGA User Guide. květen 2010. Dostupné z WWW: <www.xilinx.com/support/documentation/user_guides/ug190.pdf> [20] Štěpán Friedl, Jiří Novotný, Ladislav Lhotka: Study of 40/100GE card implementation. 2010 [cit. 7. května 2012].

56

Příloha

Seznam použitých zkratek CD Compact Disc COMET COMbo Ethernet Tester CRC Cyclic Redundancy Check DDR Double Data Rate DIC Deficit Idle Count DMA Direct Memory Access FIFO First in, First out FLU FrameLinkUnaligned FL FrameLink FPGA Field-programmable Gate Array FSM Finite-State Machine HTML HyperText Markup Language IEEE Institute of Electrical and Electronics Engineers IFG Interframe Gap LSB Least Significant Bit MAC Media Access Control MII Media Independent Interface MSB Most Significant Bit MTU Maximum Transmission Unit 57

A

A. Seznam použitých zkratek PDF Portable Document Format RAM Random Access Memory VHDL VHSIC Hardware Description Language VHSIC Very-High-Speed Integrated Circuits XGMII 10 Gigabit Media Independent Interface XLGMII 40 Gigabit Media Independent Interface XML Extensible Markup Language

58

Příloha

Překlad firmwaru a použití B.1

Překlad firmwaru na vývojové infrastruktuře projektu Liberouter

Projekt COMET byl již od začátku koncipován jako plugin do platformy NetCOPE. Součástí přiloženého CD jsou tedy zdrojové kódy, které jsem vytvořil v rámci této diplomové práce. Současně jsem přiložil i soubory NetCOPE, které jsem modifikoval. Pro překlad firmwaru z VHDL souborů je nutné mít zprovozněn překladový systém, který byl vytvořen v rámci projektu Liberouter. Tento překladový systém využívá skriptovací jazyk Tcl a syntézní nástroj XST. Samotný překlad 10Gb/s verze se tedy sestává z následujících kroků: 1. Překopírování složky application do složky top/combov2/ platformy NetCOPE 2. Náhrada modifikovaných souborů platfromy NetCOPE z přiložené složky upravene_soboury_NetCOPE 3. Spuštění příkazu make ve složce top/combov2 platformy NetCOPE V rámci této diplomové práce jsem měl přístup k vývojovým serverům projektu Liberouter, kde byl dostupný syntézní (XST) a simulační nástroj (Modelsim). Navíc jsou na těchto serverech umístěny i jiné soubory, které jsou při překladu potřebné. Z tohoto důvodu je součástí přiloženého CD přeložený firmware, který je možné nahrát do COMBO-LXT karty.

B.2

Použití firmwaru

Pro použití firmwaru je nutné provést následující kroky: 59

B

B. Překlad firmwaru a použití 1. Přihlásit se přes SSH tunel na server, který má nainstalovanou COMBOLXT kartu 2. Pomocí nástroje scp přenést firmware karty 3. Nahrát firmware do karty pomocí příkazu csboot -f0 combov2_core.mcs 4. Ověřit identifikaci firmwaru pomocí příkazu csid -s 5. Zprovoznit softwarovou část projektu COMET (více informací v diplomové práci Bc. Tomáše Čejky [17]) Ukázka výstupu nástroje csid -s Built at : n/a Board : combo Subtype : LXT155 S/N : 8100329 Speedgr. : 1 Addon0 : 10G1 Chip0 : n/a S/N0 : 8100375 Addon1 : 10G1 Chip1 : n/a S/N1 : 8100375 Channels : 2/2 (RX/TX) Firmware : ok SW : 0xc0330100 HW : 0x00010000 Text : COMET_CV2_10G2 Caps : 0x0000000e ID ver. : 0x0103 NetCope : 0x0201 PCI brver: 6d05.01.04 (2009/06/10 14:24) Driver [combov2] szedata2: active (0x41c10504-0x41c105ff) {} (0x41f10101-0x41f101ff) {} (0xf1010300-0xf10105ff) {} (0xa41c0101-0xa41c02ff) {} (0xc0330100-0xc03301ff) {} Po provedení všech předepsaných kroků by měl být projekt COMET připraven k používání. Předepsané softwarové nástroje byly na projektu Liberouter vytvořeny již dříve a nebyly předmětem této diplomové práce.

60

Příloha

Obsah přiloženého CD / Dokumentace firmy Xilinx k FPGA Virtex-5 a nástroji XST IEEE_802.3 ...... Standard IEEE 802.3 Text LaTeX.........Zdrojové soubory textu diplomové práce pro LATEX PDF...........Elektronická verze diplomová práce ve formátu PDF LightScribe..Potisk přiloženého CD Zdrojove_kody...Zdrojové soubory v jazyce VHDL 10Gb..........VHDL zdrojové kódy 10Gb/s pluginu COMET VHDL zdrojové kódy komponent pro 40Gb/s verzi 40Gb.......... pluginu COMET Skripty..........Vytvořené shell skripty pro vyčítání jednotek Doc_Xilinx ......

61

C