Badania moŻliwoŚci wprowadzenia nowej struktury wewnĘtrznej dla kart NetFPGA.

(1)

Badania mo˙zliwo´sci wprowadzenia nowej struktury

wewn˛etrznej dla kart NetFPGA

Marek Michalski, Tytus Sielach

Politechnika Pozna´nska, Wydział Elektroniki i Telekomunikacji, Katedra Sieci Telekomunikacyjnych i Komputerowych ul. Polanka 3, 60-965 Pozna´n, e-mail: imie.nazwisko@put.poznan.pl, http://netfpga.pl http://nss.et.put.poznan.pl

Streszczenie—W niniejszym artykule przedstawiono skrócony opis istniej ˛acej architektury wewn˛etrznej kart NetFPGA oraz ty-powy sposób jej wykorzystania. Przeprowadzona analiza pozwala stwierdzić, i˙z mo˙zliwe jest wprowadzenie zmian skutkuj ˛acych popraw ˛a niektórych parametrów wydajno´sciowych kart (czas przej´scia przez układ). W celu gł˛ebszej analizy skutków wpro-wadzonych zmian przygotowane zostanie ´srodowisko badawcze i testowe oparte na narz˛edziach symulacyjnych i prototypie rozwi ˛azania. Niniejszy artykuł skupia si˛e na pierwszym elemencie bada ń, którym jest sprz˛etowa generacja ruchu na potrzeby bada ń symulacyjnych i analiza wygenerowanego strumienia ruchu pod k ˛atem zgodno´sci z zało˙zonymi rozkładami i warto´sciami para-metrów.

I. WPROWADZENIE

Karty NetFPGA [1] stanowi ˛a bardzo ciekaw ˛a platform˛e sprz˛etow ˛a do realizacji prototypów urz ˛adzeń sieci Ethernet. Z powodzeniem mog ˛a być wykorzystywane jako realnie działaj ˛ace urz ˛adzenia sieci komputerowych oraz ´srodowisko do badań naukowych. S ˛a to karty rozszerzeń do komputerów PC, ale mog ˛a równie˙z pracować jako niezale˙zne w˛ezły sieci. Ich funkcjonalno´sć jest programowalna, a program jest wykonywany przez bardzo szybkie, programowalne układy FPGA. Karty s ˛a bardzo nowoczesnym produktem z obszaru urz ˛adzeń sieci komputerowych i z powodzeniem stanowi ˛a ekonomicznie korzystn ˛a alternatyw˛e dla rozwi ˛azań typowo komercyjnych. Z uwagi na du˙z ˛a elastyczno´sć s ˛a bardzo popularne w ´srodowiskach naukowych [2], stanowi ˛a podstaw˛e badań [3], dydaktyki [4], a tak˙ze prac dyplomowych [5]. Istnieje wiele podobnych platform tego typu, jednak wy˙zszo´sci ˛a kart NetFPGA jest bardzo pr˛e˙zne i otwarte ´srodowisko ich twórców i deweloperów projektów, które aktywnie wspiera mniej zaawansowanych u˙zytkowników. Dotychczas opracowane zostały karty z interfejsami o przepustowo´sci 1Gbps oraz 10Gbps, trwaj ˛a prace nad kolejnymi, szybszymi, wersjami. W niniejszym artykule przedstawimy istniej ˛ace karty (rozdział II), sposób ich wykorzystania (rozdział III), a przede wszystkim zaproponujemy modyfikacj˛e istniej ˛acej struktury wewn˛etrznej (rozdział IV) i przeanalizujemy proponowane zmiany (rozdział V). Artykuł traktuje głównie o jednym z pierwszych elementów badań nowej struktury, którym jest generator ruchu wykorzystywany do badań symulacyjnych realizowanych sprz˛etowo (rozdział VI). Artykuł kończ ˛a podsumowania i wnioski.

Rysunek 1. Karta NetFPGA z elektrycznymi interfejsami sieciowymi RJ45 o przepustowo´sci 1 Gbps

II. OPIS KARTNETFPGA 1GI10G

Karta NetFPGA jest produktem ko´ncowym projektu Net-FPGA.org [1]. Został on zało˙zony przez grup˛e naukowców ze Stanford University [6] pod kierownictwem prof. Nicka McKeowna [7]. Aktualnie projekt jest prowadzony wspólnie z analogiczn ˛a grup ˛a z University of Cambridge [8] pod kierownictwem Andrew W. Moore’a [9]. Wszelkie informacje s ˛a dost˛epne na stronie projektu [1], s ˛a organizowane liczne wydarzenia promuj ˛ace efekty prac grupy [10], ostatnio, w maju 2013, w Poznaniu odbyły si˛e pi˛eciodniowe warsztaty z programowania tych kart [11].

Na pocz ˛atku opracowana i udost˛epniona została karta Net-FPGA z portami o przepustowo´sci 1 Gbps (przedstawiona na rys. 1) [12], od niedawna dost˛epna jest nowsza wersja z portami o przepustowo´sci 10G (rys. 2). Aktualnie dost˛epne i szeroko u˙zywane s ˛a obie wersje kart NetFPGA. Obie s ˛a bardzo podobne, w przypadku ka˙zdej z nich mamy do czy-nienia z kart ˛a rozszerze´n PC. Ka˙zda ma 4 porty ethernetowe, jednak, jak sugeruj ˛a nazwy, maj ˛a porty o ró˙znej maksymalnej przepustowo´sci. W przypadku karty 1G do dyspozycji s ˛a cztery porty elektryczne (RJ45), natomiast w przypadku karty 10G dost˛epne s ˛a 4 gniazda na wkładki SFP+. Ró˙zne s ˛a te˙z magistrale, którymi ł ˛acz ˛a si˛e z PC - s ˛a to odpowiednio PCI oraz PCIe. Ich wewn˛etrzna budowa, na pewnym poziomie abstrakcji, jest bardzo podobna. Aktualnie uko´nczone s ˛a prace

(2)

Rysunek 2. Karta NetFPGA z uniwersalnymi interfejsami sieciowymi SFP+ o przepustowo´sci 10 Gbps

nad kart ˛a z interfejsami o przepustowo´sciach 10Gbps oraz 100Gbps [13], b˛edzie ona dost˛epna od grudnia 2014 [1].

Karta 1G jest produkowana przez firm˛e Digilient [14], natomiast karta z portami 10G jest dost˛epna w ofercie firmy Hightech Global [15]. Obie wersje s ˛a osi ˛agalne jako darowizny w ramach Xilinx University Program [16], którego nasza kate-dra jest beneficjentem - otrzymali´smy pi˛eć egzemplarzy karty z interfejsami 10G. Aktualnie nasza laboratoryjna sieć kart NetFPGA [17] składa si˛e z 12 kart 1G i pi˛eciu kart 10G oraz wielu dodatkowych urz ˛adzeń sieciowych, które umo˙zliwiaj ˛a im funkcjonowanie oraz tworzenie elastycznych topologii i wykorzystanie ró˙znorodnych mechanizmów sieciowych.

Platforma sprz˛etowa to jedno, równie istotne jest oprogra-mowanie tych kart, szczególnie, ˙ze praktycznie pełn ˛a funk-cjonalno´sć kart nale˙zy samemu zaprogramować. Na szcz˛e´scie mo˙zna skorzystać z udost˛epnionych przykładowych projektów referencyjnych. S ˛a one dost˛epne zarówno jako kody ´zródłowe, jak i gotowe do uruchomienia pliki. Do kompilacji kodu ´zródłowego konieczne jest posiadanie rozbudowanego ´srodo-wiska uruchomieniowego firmy Xilinx [18], pełne informacje o wymaganiach i sposobie konfiguracji dost˛epne s ˛a na stronie projektu [1]. Zaprogramowanie karty NetFPGA to jeden z kroków koniecznych do jej wykorzystania. Karta mo˙ze pra-cować samodzielnie, jednak aby mogła ona współdziałać z systemem operacyjnym komputera, nale˙zy zainstalować w nim odpowiedni sterownik. Jego kody ´zródłowe dost˛epne s ˛a w standardowym zestawie oprogramowania dla kart NetFPGA, nale˙zy go skompilować i uruchomić według dostarczonej procedury. Po poprawnym wykonaniu wszystkich wymaga-nych czynno´sci interfejsy karty s ˛a widoczne w systemie jak standardowe interfejsy sieciowe, natomiast oprogramowanie do samej karty mo˙ze być wgrane w zale˙zno´sci od wersji karty: w przypadku karty 1G - przez systemow ˛a magistral˛e PCI i dostarczony program (nf_download) lub w przypadku

kart 10G - przez zewn˛etrzny programator USB i narz˛edzie z pakietu oprogramowania firmy Xilinx - program Impact. Poprawnie uruchomiona karta mo˙ze być wykorzystywana jak zwykła karta sieciowa lub nale˙zy dla niej przygotować do-datkowe oprogramowanie, które jest specyficzne i zale˙zne od realizowanych funkcjonalno´sci.

III. PRZEPŁYW DANYCH W ´SRODOWISKUNETFPGA Ramki ethernetowe odbierane s ˛a z fizycznych portów przez odpowiednie układy i umieszczane w postaci ci ˛agu bitów w buforach wej´sciowych. Ka˙zdy port posiada swój bufor (na rysunku 3 oznaczone s ˛a jasnozielonym kolorem, na rysunku 4 dodatkowo podpisane s ˛a jako MAC0 - MAC3). Dane z ramek dzielone s ˛a na słowa o stałej długo´sci, 64 bitowe słowa wyst˛epuj ˛a w całym projekcie karty NetFPGA 1G, natomiast w przypadku karty 10G długo´sć słowa to 256 bitów. Nale˙zy zwrócić uwag˛e, ˙ze ramki wysyłane przez procesor do sieci, zanim przejd ˛a przez kart˛e, s ˛a traktowane jak ramki do niej przychodz ˛ace i s ˛a umieszczane w jej buforach wej´sciowych powi ˛azanych z procesorem. Te bufory zaznaczono na rysunku 3 kolorem jasnoniebieskim, natomiast na rysunku 4 dodatkowo podpisano jako CPU. Tym oto sposobem do karty wchodzi 8 strumieni danych, po cztery od strony portów fizycznych i po cztery od strony procesora. Z punktu widzenia przetwarzania danych s ˛a one równorz˛edne i mog ˛a być traktowane jedno-rodnie lub unikatowo w zale˙zno´sci od zamierzeń programisty. Analogiczna sytuacja ma miejsce z buforami wyj´sciowymi -je´sli ramka ma być wysłana na port fizyczny - jest umieszczana w buforze wyj´sciowym powi ˛azanym z odpowiednim portem (ciemnozielony port MAC), je´sli natomiast ma trafić do sys-temu operacyjnego - jest umieszczana w kolejce oznaczonej kolorem ciemnoniebieskim (CPU). Jak łatwo zauwa˙zyć, na rysunkach przyj˛eto konwencj˛e, ˙ze bufory zwi ˛azane z portami fizycznymi s ˛a oznaczone kolorem zielonym, natomiast do procesora - niebieskim. Bufory na wej´sciu do karty oznaczono jasnym odcieniem odpowiedniego koloru, natomiast na wyj-´sciu - ciemnym kolorem. Takie dodatkowe oznaczenie ułatwia studentom szybkie i intuicyjne odnalezienie si˛e w ´srodowisku karty NetFPGA.

A. Obsługa ramki ethernetowej nios ˛acej zapytanie ARP przez system z kart ˛a sieciow ˛a NetFPGA

Poni˙zej zostanie przeanalizowana procedura obsługi zapyta-nia protokołu ARP w celu przedstawiezapyta-nia typowego sposobu obsługi ramki ethernetowej w karcie NetFPGA. Załó˙zmy, ˙ze do karty jest wgrane oprogramowanie, które czyni z niej typow ˛a kart˛e sieciow ˛a. Załó˙zmy równie˙z, ˙ze ramka nios ˛aca zapytanie ARP została odebrana na porcie eth0. Zostanie wi˛ec ona umieszczona w buforze MAC0 na wej´sciu do karty (jasnozielony). Nast˛epnie modułInput Arbiter w odpowiednim

momencie wybierze z kolejki wej´sciowej t˛e ramk˛e do obsługi i przeka˙ze j ˛a do Modułu U˙zytkownika i dalej do Output Port Lookup. Głównym zadaniem modułów w obr˛ebie karty

NetFP-GA jest przekazanie ramek na odpowiednie porty wyj´sciowe, przekazanie takie odbywa si˛e przez ustawienie odpowiednich zmiennych steruj ˛acych oznaczaj ˛acych bufor wyj´sciowy. Na podstawie tych danych kolejny moduł (Output Queues)

umie-´sci ramk˛e w odpowiednim buforze wyjumie-´sciowym. W tym przy-padku funkcjonalno´s´c protokołu ARP wymusza przekazanie tej ramki do systemu operacyjnego przez interfejs nf0, dlatego te˙z ramka ta zostanie umieszczona w ciemnoniebieskim bufo-rze na wyj´sciu, czyli w kolejce do nf0 (CPU0). W tym momen-cie ramk˛e przejmuje system operacyjny i odpowiedni proces

(3)

PCI/PCIe driver eth1 eth0 eth3 eth2 nf 1 nf0 nf2 nf3 FPGA chip Operating System Input Arbiter Output Queues Moduł użytkownika Output Port Lookup

NetFPGA

Rysunek 3. Najwa˙zniejsze elementy budowy karty NetFPGA

sieciowy (o ile taki jest uruchomiony na danym komputerze) przeanalizuje zapytanie ARP i odpowiednio na nie zareaguje. Załó˙zmy, ˙ze analizowana ramka niesie zapytanie o adres MAC naszego komputera, wi˛ec, zgodnie z funkcjonalno´sci ˛a ARP, ten komputer odpowie na ni ˛a odpowiednim komunikatem ARP. Ten komunikat zostanie wygenerowany przez proces sieciowy w systemie operacyjnym i wysłany przez port nf0 do sieci. Wysłanie ramki przez interfejs nf0 polega na umiesz-czeniu jej w buforze wej´sciowym do karty NetFPGA, w tym przypadku ramka do karty przychodzi od strony procesora (przez interfejs obecny w systemie operacyjnym), czyli b˛edzie umieszczona w jasnoniebieskim (wej´sciowym) buforze ozna-czonym jako CPU0. ModułInput Arbiter odbierze t˛e ramk˛e, a

kolejne moduły zadecyduj ˛a o przesłaniu jej na port wyj´sciowy eth0, czyli umieszcz ˛a j ˛a w ciemnozielonej kolejce wyj´sciowej MAC0, stamt ˛ad odpowiednie mechanizmy j ˛a odczytaj ˛a i wy´sl ˛a do ł ˛acza przez port eth0.

Obsługa ramek (podstawowa wersja) w głównej ko´sci FPGA karty NetFPGA polega na przyj˛eciu ramki do kolejki na wej´sciu, zadecydowaniu o przeznaczeniu danej ramki, odpowiednim jego oznaczeniu i umieszczeniu ramki w od-powiedniej kolejce wyj´sciowej. Powy˙zszy przykład przedsta-wił obsług˛e ramki przy współudziale procesora komputera i systemu operacyjnego, taka ramka przeszła przez kart˛e dwa razy. O wiele ciekawsza jest sytuacja, gdy do obsługi ramki wystarczy funkcjonalno´s´c zakodowana w ko´sci FPGA i nie jest konieczna interakcja z systemem operacyjnym. Gdy karta samodzielnie obsługuje ruch, wydajno´s´c przetwarzania danych jest o wiele wy˙zsza, gdy˙z pomijane jest dwukrotne przej´scie danych przez magistral˛e i obsługa przez procesor.

CPU

0 MAC0 CPU1 MAC1 CPU2 MAC2 CPU3 MAC3

Input Arbiter - wybór obsługiwanej kolejki wejściowej

Output Queues - Rozdział na kolejki wyjściowe Moduł użytkownika (dodany)

Output Port Lookup – ustalenie kolejki wyjściowej

CPU 0 MAC 0 CPU 1 MAC 1 CPU 2 MAC 2 CPU 3 MAC 3

Rysunek 4. Dotychczasowy sposób organizacji przepływu danych w kartach NetFPGA

IV. NOWE PODEJ ´SCIE DO PRZETWARZANIA DANYCH

A. Słabo´sci dotychczasowego rozwi ˛azania

W dotychczasowym podej´sciu do obsługi ramek w głów-nym module projektu, zaproponowagłów-nym we wszystkich pro-jektach referencyjnych, wykorzystywany jest moduł, który w danym momencie wybiera jedn ˛a ramk˛e spo´sród oczekuj ˛acych i przekazuje j ˛a do obsługi przez jeden, wspólnie wykorzy-stywany pipeline. Dzi˛eki wewn˛etrznemu przyspieszeniu nie ma problemu z obsług ˛a ruchu z o´smiu kolejek wej´sciowych przez pojedyncze moduły i układy funkcyjne. Ka˙zdy moduł analizuje nagłówek i po zakończeniu jego analizy przetwarza (zazwyczaj transmituje przezroczy´scie) dalsz ˛a cz˛e´sć ramki. Takie podej´scie wymusza na kolejnych ramkach oczekiwanie na pełne zakończenie obsługi poprzedniej ramki. Powoduje to pewne opó´znienia, których mo˙zna unikn ˛ać poprzez reor-ganizacj˛e procesu przetwarzania danych. Pierwotne podej´scie do ka˙zdej ramki sprowadza si˛e do rozbicia funkcji analizy nagłówka ramki i jej transmisji do dwóch grup stanów FSM, które s ˛a realizowane w tej samej maszynie, czyli system albo analizuje nagłówek, albo przesyła cz˛e´sć danych, tzn, w danym momencie wykonywana jest tylko jedna z tych funkcjonalno-´sci. Oznacza to, ˙ze w danym momencie obsługiwana jest tylko jedna ramka przez jedn ˛a z dwóch funkcjonalno´sci.

B. Zało˙zenia nowej struktury wewn˛etrznej

Przeanalizowali´smy charakterystyk˛e czasow ˛a oraz wzajem-ne umiejscowienie w czasie poszczególnych operacji (operacje te to analiza nagłówka w celu wybrania portu wyj´sciowego (1) i transmisja ramki przez moduł(2)) wykonywanych podczas obsługi wielu ramek przez układ wykorzystuj ˛acy dotychczaso-w ˛a i now ˛a architektur˛e. Zakładamy, ˙ze w najgorszym przypad-ku wszystkie bufory wej´sciowe oczeprzypad-kuj ˛a, ˙ze ich ramka b˛edzie

(4)

przesłana do bufora wyj´sciowego. Na rys. 6 schematycznie przedstawiono cztery ramki dost˛epne w buforach wej´sciowych i oczekuj ˛ace na ich transmisj˛e do buforów wyj´sciowych. Dotychczasowe podej´scie zakłada pełn ˛a obsług˛e ramek z kolejno wybieranych buforów (sposób podejmowania decy-zji nie jest istotny dla prezentowanych tutaj rozwa˙zań), tzn. przed przej´sciem do kolejnej ramki, poprzednia ramka musi opu´scić moduł. Uproszczon ˛a charakterystyk˛e takiej sytuacji przedstawiono na rys. 7, gdzie wyra´znie widać, ˙ze transmisja kolejnej ramki nast˛epuje dopiero po całkowitej obsłudze ramki poprzedniej. Innymi słowy, układ obsługuje nagłówek albo pola danych, ale nigdy nie robi tego jednocze´snie. Bior ˛ac pod uwag˛e działanie układu, poszczególne bloki s ˛a wykorzystywa-ne naprzemiennie. Doszli´smy do wniosku, ˙ze gdyby mo˙zna było wykonywać te operacje jednocze´snie, to cała kolejna ramka nie musiałaby czekać na obsług˛e do czasu zakończenia obsługi poprzedniej (tak jak to jest pokazane na rysunku 7). Sprowadza si˛e to do tego, ˙ze gdy funkcjonalno´sć zwi ˛azana z analiz ˛a nagłówka ju˙z podejmie decyzj˛e o sposobie transmisji ramki, mo˙ze wykorzystać te informacje jako sygnały steruj ˛ace polem komutacyjnym, uruchomić transmisj˛e ramki w taki spo-sób, ˙ze nie blokuje ona analizy nagłówka kolejnej ramki i co najwa˙zniejsze - przej´sć do analizy kolejnej ramki. Dzi˛eki temu analiza nagłówka mo˙ze odbywać si˛e podczas transmisji ramek, których nagłówki ju˙z zostały przeanalizowane. Takie podej´scie mo˙ze być zrealizowane w strukturze z rysunku 5. Funkcjonal-no´sć analizy działa przez krótki czas, a nast˛epnie aktywowana jest funkcjonalno´sć transmisji ramki do odpowiedniego bufora wyj´sciowego. Zaraz po zakończeniu analizy jednej ramki (i rozpocz˛eciu jej transmisji przez pole), układ steruj ˛acy mo˙ze przej´sć do analizy nagłówka kolejnej ramki (jednocze´snie realizuj ˛ac transmisji ramek ju˙z przeanalizowanych). Oznacza to, ˙ze mo˙ze odbywać si˛e jednoczesna transmisja do 8 ra-mek. Charakterystyka czasowa takiej realizacji obsługi danych przedstawiona jest na rys. 8. Od razu widać znaczne skrócenie czasu całkowitego przetwarzania, czyli czasu, który upływa od momentu pojawienia si˛e ramek w buforach wej´sciowych do momentu ich pojawienia si˛e w buforach wyj´sciowych.

C. Wady i zalety nowej struktury wewn˛etrznej

Proponowane zmiany powoduj ˛a zauwa˙zalny wzrost skom-plikowania projektu i zaburzaj ˛a dotychczasowe podej´scie za-kładaj ˛ace niezale˙zno´sć modułów. W przypadku niektórych projektów mo˙ze to być utrudnieniem i zmuszać projektanta do realizacji kilku dodatkowych funkcjonalno´sci lub zaplanowa-na funkcjozaplanowa-nalno´sć b˛edzie musiała uwzgl˛ednić zrównoleglenie realizowane w module steruj ˛acym. Modyfikacje te mo˙zna potraktować jako realizacj˛e kilku funkcjonalno´sci w jednym, bardziej rozbudowanym, module, który efektywniej realizuje zadania osobnych i niezale˙znych modułów.

Dzi˛eki temu uzyskujemy mo˙zliwo´sć o wiele bardziej efek-tywnego wykorzystania przepustowo´sci układu i jednoczesnej transmisji kilku ramek, co znacznie skróci całkowity czas ich obsługi. Nale˙zy zwrócić uwag˛e, ˙ze nie wzro´snie przepusto-wo´sć, lecz jedynie spadnie czas przebywania poszczególnych

CPU 0 MAC 0 CPU 1 MAC 1 CPU 2 MAC 2 CPU 3 MAC 3 CPU 0 MAC 0 CPU 1 MAC 1 CPU 2 MAC 2 CPU 3 MAC 3 Nieblokowalne pole komutacyjne 8x8

Zmodyfikowany moduł sterowania

Rysunek 5. Nowa struktura przetwarzania danych w kartach NetFPGA

Cykle poświęcone na nagłówek Cykle poświęcone na ładunek

Rysunek 6. Cztery ramki jednocze´snie dost˛epne na wej´sciu do układu

Rysunek 7. Czasowa charakterystyka obsługi czterech ramek wg pierwotnej architektury przez pojedynczy pipeline

Rysunek 8. Czasowa charakterystyka obsługi czterech ramek wg nowej architektury przez zrównoleglony pipeline

(5)

Rysunek 9. Rozkład równomierny

ramek w układzie, co ma bezpo´srednie przeło˙zenie na opó´z-nienie ich transmisji.

Nale˙zy równie˙z zwrócić uwag˛e, ˙ze układ steruj ˛acy, mimo, ˙ze steruje nieblokowalnym polem komutacyjnym (tzn. takim, które mo˙ze zrealizować dowolne poł ˛aczenie mi˛edzy wolnym wej´sciem i wolnym wyj´sciem), poprzez odpowiednie planowa-nie i wykorzystaplanowa-nie poszczególnych kierunków transmisji (np. poprzez chwilowe jej wstrzymanie) musi rozwi ˛azać ewentual-ny konflikt w dost˛epnie do wyj´scia, czyli nie mo˙ze dopu´scić do sytuacji, gdy do jednego bufora wyj´sciowego jednocze´snie b˛edzie transmitowana ramka z wi˛ecej ni˙z z jednego bufora wej´sciowego. Ten problem jest znany pod poj˛eciem blokady zewn˛etrznej, jej gł˛ebsza analiza wykracza poza zakres tego artykułu, ale jest brana pod uwag˛e podczas projektowania układu steruj ˛acego.

V. SYMULACJA

Do przeprowadzenia analizy mo˙zliwo´sci proponowanej ar-chitektury i porównania jej z istniej ˛ac ˛a przewidziano badania symulacyjne. W celu jak najszybszego jej wykonania zostanie ona zrealizowana na układzie FPGA. W ten sposób przetwa-rzanie danych w symulacji zostanie maksymalnie zrównole-glone.

Podstawowym elementem ka˙zdej symulacji s ˛a generatory liczb pseudolosowych. W naszym przypadku b˛edzie potrzebny generator pseudolosowy o równomiernym rozkładzie praw-dopodobie´nstwa (w celu wyznaczania długo´sci pakietu) oraz generator o rozkładzie wykładniczym, w celu wyznaczania czasu pomi˛edzy nadej´sciem 2 kolejnych pakietów. Dla spraw-nego działania symulatora generatory powinny by´c zdolne podawania nowych liczb pseudolosowych co takt zegara sys-temowego. Rysunek 10. LFSR

A. Generator o rozkładzie równomiernym

Został utworzony moduł zawieraj ˛acy rejestr przesuwny LFSR o długo´sci 128 bitów bazuj ˛acy na wielomianie pierwot-nym 10. Pobierane s ˛a z niego najmniej znacz ˛ace 32 bity jako liczba pseudo losowa. Przeprowadzono badanie generatora na 4000 wygenerowanych liczb, uzyskano histogram odpo-wiadaj ˛acy równomiernemu rozkładowi prawdopodobie´nstwa przedstawionym na rysunku 9.

Niestety, tak tworzone kolejne liczby pseudolosowe s ˛a skorelowane ze sob ˛a. Im wi˛eksza odległo´sć pomi˛edzy licz-bami tym ich powi ˛azanie ze sob ˛a mniejsze. Dlatego w celu uzyskania dobrych wła´sciwo´sci losowych nale˙zy pobierać, na przykład, co 32 wygenerowan ˛a liczb˛e. W tym przypadku nale˙załoby czekać 32 cykle zegara, a to zbyt długo. Czas ten mo˙zna skrócić przez wykorzystanie odpowiednich funkcji logicznych.

(6)

Rysunek 11. Odwrócony rozkład wykładniczy

B. Generator o rozkładzie wykładniczym

Architektura układu FPGA znacz ˛aco ułatwia utworzenie generatora pseudolosowego o rozkładzie równomiernym, lecz utworzenie generatora o rozkładzie wykładniczym jest znacz-nie trudznacz-niejsz ˛a kwesti ˛a. Generowanie liczb losowych o rozkła-dzie wykładniczym bazuje na rozkłarozkła-dzie równomiernym [19] oraz funkcji logarytmicznej 1:

U = −ln(1 − x)/λ, (1)

która jest bardzo trudna do zaimplementowania w logice układu FPGA. Wymaga ona równie˙z du˙zych zasobów sprz˛e-towych, szczególnie je´sli ma by´c wykonywana szybko (mak-symalnie kilka cykli zegara). Wyj ˛atkiem jest logarytm o pod-stawie 2. W zwi ˛azku z tym, w celu sprawdzenia mo˙zliwo´sci takiego układu, zastosowano zmodyﬁkowany wzór 2:

U= log₂(x). (2)

Pozwoliło to uzyska´c ci ˛ag liczb, którego histogram prezento-wany jest na rysunku 11.

VI. PODSUMOWANIE

W niniejszym artykule przedstawiono propozycj˛e zmian istniej ˛acej architektury wewn˛etrznej karty NetFPGA. Taka zmiana pozwoli skróci´c czas oczekiwania ramek w układzie na ich analiz˛e i przetwarzanie, co przeło˙zy si˛e na mniejsze

opó´znienie ich transmisji. Do zweryfikowania zało˙zeń przy-gotowane zostanie ´srodowisko badawcze oparte na sprz˛etowej symulacji. Artykuł opisuje wykorzystany sprz˛etowy generator liczb losowych. Dalsze badania b˛ed ˛a weryfikowały pochodne tego generatora oraz pozostałe elementy systemu.

Nale˙zy zwróci´c uwag˛e, ˙ze proponowana modyﬁkacja nie podniesie przepustowo´sci układu, lecz zmniejszy opó´znienia przej´scia transmitowanych ramek.

VII. PODZI ˛EKOWANIA

Projekt został sﬁnansowany z dotacji Ministerstwa Nauki i Szkolnictwa Wy˙zszego na rok 2014.

LITERATURA

[1] Główna strona projektuNetFPGA http://netfpga.org.

[2] Podstrona z aktualn ˛a list ˛a publikacji zwi ˛azanych z kartami NetFPGA: http://netfpga.org/2014/#/publications/

[3] M. Michalski: "The System for Delay Measurement in Ethernet Networks on NetFPGA Cards", IEEE 15th International Conference on High Performance Switching and Routing, Vancouver, Canada, 1-4 czerwca 2014.

[4] M. Michalski: "Karty NetFPGA w procesie dydaktycznym", Pozna´nskie Warsztaty Telekomunikacyjne, Pozna´n, 13 grudnia 2013.

[5] Tytus Sielach, Praca dyplomowa magisterska pt. "OpenFlow Switch with xDPD on NetFPGA card", Politechnika Pozna´nska, Wydział Elektroniki i Telekomunikacji, Pozna´n 2014.

[6] Strona informacyjna grupy NetFPGA http://yuba.stanford.edu/. [7] Strona informacyjna - Nick McKeown http://yuba.stanford.edu/~nickm/. [8] Główna strona www Computer Laboratory, Faculty of Computer Science

and Technology, University of Cambridge http://www.cl.cam.ac.uk/. [9] Strona informacyjna - Andrew W. Moore www.cl.cam.ac.uk/~awm22/. [10] Wydarzenia w ramach projektu NetFPGA http://netfpga.org/events. [11] Strona informacyja warsztatów NetFPGA http://www.netfpga.pl. [12] Glen Gibb, John W. Lockwood, Jad Naous, Paul Hartke, and Nick

McKeownNetFPGA – Open Platform for Teaching How to Build Gigabit-rate Network Switches and Routers IEEE Trans. on Education, 2008. [13] Zilberman, N., Audzevich, Y., Covington, A., Moore, A.W. . "NetFPGA

SUME: Toward Research Commodity 100Gb/s", IEEE Micro, Sep-Oct 2014.

[14] Strona produktu NetFPGA 1G http://www.digilentinc.com/Products/ Detail.cfm?Prod=NETFPGA.

[15] Strona produktu NetFPGA 10G http://www.hitechglobal.com/boards/ PCIExpress_SFP+.htm.

[16] Xilinx University Program http://Xilinx.com/university/.

[17] Strona projektu„ ´Srodowisko testowe protokołów sieciowych na bazie systemu OpenFlow” http://openﬂow.et.put.poznan.pl.

[18] Główna strona www ﬁrmyXilinx http://Xilinx.com/.