Karty NetFPGA w procesie dydaktycznym Marek Michalski Politechnika Poznańska, Wydział Elektroniki i Telekomunikacji, Katedra Sieci Telekomunikacyjnych i Komputerowych ul. Polanka, 6-965 Poznań, e-mail: imie.nazwisko@put.poznan.pl, http://netfpga.pl http://nss.et.put.poznan.pl Streszczenie W artykule przedstawiono karty NetFPGA. Sa to karty rozszerzeń do PC. Występuja w dwóch wersjach - z portami o przepustowości Gbps oraz Gbps. Ich funkcjonalność jest programowalna w bardzo szerokim zakresie, przykładowy kod jest dostępny na licencji BSD. Karty sa wykorzystywane zarówno do pracy w charakterze prototypowych urzadzeń sieciowych jak i otwartej platformy edukacyjnej. W artykule przedstawiono budowę kart, budowę i zasadę funkcjonowania zestawu oprogramowania typowych urzadzeń sieciowych zrealizowanych na kartach NetFPGA oraz sposób wykorzystania w dydaktyce. I. WPROWADZENIE Współczesny świat oczekuje szybkiej reakcji na swe potrzeby. Nie tylko wielkim korporacjom chodzi o szybkie wprowadzenie produktów na rynek, również naukowcy chcą jak nakrócej oczekiwać na odpowiedzi na swe pytania, jak najszybciej otrzymywać rezultaty swych badań, jak najszybciej realizować projekty. Nie chodzi tu wcale o realizację idei "czas to pieniądz", ale o możliwość jak najefektywniejszego wykorzystania czasu, który jest zasobem krytycznym. Współczesne technologie dają mozliwości, które kilka lat temu były w sferze science fiction. Przykładem techologii, na której skupię się w niniejszym artykule, są programowalne układy cyfrowe. Jednym z przedstawicieli szerokiej rodziny takich technologii są układy FPGA (ang. Field Programmable Gate Array). Współczesne układy FPGA oferują ogromne możliwości w wielu wymiarach - można w nich realizować rozbudowaną funkcjonalność logiczną, mogą posiadać w sobie dedykowane bloki różnego rodzaju układów specjalizowanych (przetwornik AC/CA, procesory, pamięci, rozmaite czujniki; np przyspieszenia, światła itp.). Są również bardzo szybkie. Bardzo ważną ich cechą jest możliwość wielokrotnego programowania bez utraty wydajności. Wszystkie te właściwości czynią z nich idealne układy do realizacj zadań protypowych, badawczych i naukowych. Odpowiednio przygotowany program może być wgrany do pojedynczego układu lub uruchomiony w wielu kopiach, dzięki temu ta technologia jest idealna zarówno do wykorzystania w przemyśle wielkiej skali oraz w pojedynczych urządzeniach. Karta NetFPGA jest bardzo dobrym przykładem, który wykorzystuje wszystkie wspomniane cechy charakterystyczne układów FPGA - jej główny układ to przedstawiciel właśnie tej technologii. II. OPIS KART NETFPGA G I G Karta NetFPGA jest produktem końcowym projektu Net- FPGA.org []. Został on założony przez grupę naukowców ze Stanford University [] pod kierownictwem prof. Nicka McKeowna []. Aktualnie projekt jest prowadzony wspólnie z analogiczną grupą z University of Cambridge [4] pod Rysunek. Karta NetFPGA z elektrycznymi interfejsami sieciowymi RJ45 o przepustowości Gbps kierownictwem Andrew W. Moore a [5]. Wszelkie informacje są dostępne na stronie projektu [], są organizowane liczne wydarzenia promujące efekty prac grupy [6], ostatnio, w maju, w Poznaniu odbyły się pięciodniowe warsztaty z programowania tych kart [7]. Na początku opracowana i udostępniona została karta Net- FPGA z portami o przepustowości Gbps (przedstawiona na rys. ) [8], od niedawna dostępna jest nowsza wersja z portami o przepustowości G (rys. ). Aktualnie dostępne i szeroko używane są obie wersje kart NetFPGA. Obie są bardzo podobne, w przypadku każdej z nich mamy do czynienia z kartą rozszerzeń PC. Każda ma 4 porty ethernetowe, jednak, jak sugerują nazwy, mają porty o różnej maksymalnej przepustowości. W przypadku karty G do dysposycji są cztery porty elektryczne (RJ45), natomiast w przypadku karty G dostępne są 4 gniazda na wkładki SFP+. Różne są też magistrale, którymi łączą się z PC- są to odpowiednio PCI oraz PCIe. Ich wewnętrzna budowa, na pewnym poziomie abstrakcji, jest bardzo podobna. Karta G jest produkowana przez firmę Digilient [9], natomiast karta z portami G jest dostępna w ofercie firmy Hightech Global []. Obie wersje są osiągalne jako darowizny w ramach Xilinx University Program [], którego nasza katedra jest beneficjentem - otrzymaliśmy pięć egzemplarzy karty z interfejsami G. Aktualnie nasza laboratoryjna sieć kart NetFPGA [] składa się z kart G i pięciu kart G oraz wielu dodatkowych urządzeń sieciowych, które umożliwiają 6 XVII Poznańskie Warsztaty Telekomunikacyjne
Rysunek. Karta NetFPGA z uniwersalnymi interfejsami sieciowymi SFP+ o przepustowości Gbps im funkcjonowanie oraz tworzenie elastycznych topologii i wykorzystanie różnorodnych mechanizmów sieciowych. Platforma sprzętowa to jedno, równie istotne jest oprogramowanie tych kart, szczególnie, że praktycznie pełną funkcjonalność kart należy samemu zaprogramować. Na szczęście można skorzystać z udostępnionych przykładowych projektów referencyjnych. Są one dostępne zarówno jako kody źródłowe, jak i gotowe do uruchomienia pliki. Do kompilacji kodu źródłowego konieczne jest posiadanie rozbudowanego środowiska uruchomieniowego firmy Xilinx [], pełne informacje o wymaganiach i sposobie konfiuguracji dostępne są na stronie projektu []. Zaprogramowanie karty NetFPGA to jeden z kroków koniecznych do jej wykorzystania. Karta może pracować samodzielnie, jednak aby mogła ona współdziałać z systemem operacyjnym komputera, należy zainstalować w nim odpowiedni sterownik. Jego kody źródłowe dostępne są w standardowym zestawie oprogramowania dla kart NetFPGA, należy go skompilować i uruchomić według dostarczonej procedury. Po poprawnym wykonaniu wszystkich wymaganych czynności interfejsy karty są widoczne w systemie jak standardowe interfejsy sieciowe, natomiast oprogramowanie do samej karty może być wgrane w zależności od wersji karty: w przypadku karty G - przez systemową magistralę PCI i dostarczony program (nf_download) lub w przypadku kart G - przez zewnętrzny programator USB i narzędzie z pakietu oprogramowania firmy Xilinx - program Impact. Poprawnie uruchomiona karta może być wykorzystywana jak zwykła karta sieciowa lub należy dla niej przygotować dodatkowe oprogramowanie, które jest specyficzne i zależne od realizowanych funkcjonalności. III. PRZEPŁYW DANYCH W ŚRODOWISKU NETFPGA Ramki ethernetowe odbierane są z fizycznych portów przez odpowiednie układy i umieszczane w postaci ciągu bitów w buforach wejściowych. Każdy port posiada swój bufor (na rysunku oznaczone są jasnozielonym kolorem, na rysunku 4 dodatkowo podpisane są jako - ). Dane z ramek dzielone są na słowa o stałej długości, 64 bitowe słowa występują w całym projekcie karty NetFPGA G, natomiast w przypadku karty G długość słowa to 56 bitów. Zawartość poszczególnych słów i położenie w nich elementów ramki ethernetowej w przypadku karty NetFPGA G przedstawiono na rysunku 5. Należy zwrócić uwagę, że ramki wysyłane przez procesor do sieci, zanim przejdą przez kartę, są traktowane jak ramki do niej przychodzące i są umieszczane w jej buforach wejściowych powiązanych z procesorem. Te bufory zaznaczono na rysunku kolorem jasnoniebieskim, natomiast na rysunku 4 dodatkowo podpisano jako. 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ą one równorzędne i mogą być traktowane jednorodnie lub unikatowo w zależności od zamierzeń programisty. Analogiczna sytuacja ma miejsce z buforami wyjściowymi - jeśli ramka ma być wysłana na port fizyczny - jest umieszczana w buforze wyjściowym powiązanym z odpowiednim portem (ciemnozielony port ), jeśli natomiast ma trafić do systemu operacyjnego - jest umieszczana w kolejce oznaczonej kolorem ciemnoniebieskim (). Jak łatwo zauważyć, na rysunkach przyjęto konwencję, że bufory związane z portami fizycznymi są oznaczone kolorem zielonym, natomiast do procesora - niebieskim. Bufory na wejściu do karty oznaczono jasnym odcieniem odpowiedniego koloru, natomiast na wyjściu - ciemnym kolorem. Takie dodatkowe oznaczenie ułatwia studentom szybkie i intuicyjne odnalezienie się w środowisku karty NetFPGA. A. Obsługa ramki ethernetowej niosacej zapytanie ARP przez system z karta sieciowa NetFPGA Poniżej zostanie przeanalizowana procedura obsługi zapytania protokołu ARP w celu przedstawienia typowego sposobu obsługi ramki ethernetowej w karcie NetFPGA. Załóżmy, że do karty jest wgrane oprogramowanie, które czyni z niej typową kartę sieciową. Załóżmy również, że ramka niosąca zapytanie ARP została odebrana na porcie eth. Zostanie więc ona umieszczona w buforze na wejściu do karty (jasnozielony). Następnie moduł Input Arbiter w odpowiednim momencie wybierze z kolejki wejściowej tę ramkę do obsługi i przekaże ją domodułu Użytkownika i dalej do Output Port Lookup. Głównym zadaniem modułów w obrębie karty NetFP- GA jest przekazanie ramek na odpowiednie porty wyjściowe, przekazanie takie odbywa się przez ustawienie odpowiednich zmiennych sterujących oznaczających bufor wyjściowy. Na podstawie tych danych kolejny moduł (Output Queues) umieści ramkę w odpowiednim buforze wyjściowym. W tym przypadku funkcjonalność prorokołu ARP wymusza przekazanie tej ramki do systemu operacyjnego przez interfejs nf, dlatego też ramka ta zostanie umieszczona w ciemnoniebieskim buforze na wyjściu, czyli w kolejce do nf (). W tym momencie ramkę przejmuje system operacyjny i odpowiedni proces sieciowy (o ile taki jest uruchomiony na danym komputerze) przeanalizuje zapytanie ARP i odpowiednio na nie zareaguje. Załóżmy, że analizowana ramka niesie zapytanie o adres naszego komputera, więc, zgodnie z funkcjonalnością ARP, ten komputer odpowie na nią odpowiednim komunikatem ARP. Ten komunikat zostanie wygenerowany przez proces sieciowy w systemie operacyjnym i wysłany przez port nf do sieci. Wysłanie ramki przez interfejs nf polega na umiesz- PWT - Poznań - grudnia 7
eth eth eth eth Input Arbiter Moduł użytkownika Output Port Lookup Output Queues Input Arbiter - wybór obsługiwanej kolejki wejściowej Moduł użytkownika (dodany) Output Port Lookup ustalenie kolejki wyjściowej NetFPGA FPGA chip PCI/PCIe driver Output Queues - Rozdział na kolejki wyjściowe Operating System nf nf nf nf Rysunek. Najważniejsze elementy budowy karty NetFPGA Rysunek 4. Sposób organizacji przepływu danych w kartach NetFPGA G czeniu jej w buforze wejściowym do karty NetFPGA, w tym przypadku ramka do karty przychodzi od strony procesora (przez interfejs obecny w systemie operacyjnym), czyli będzie umieszczona w jasnoniebieskim (wejściowym) buforze oznaczonym jako. Moduł Input Arbiter odbierze tę ramkę, a kolejne moduły zadecydują o przesłaniu jej na port wyjściowy eth, czyli umieszczą ją w ciemnozielonej kolejce wyjściowej, stamtąd odpowiednie mechanizmy ją odczytająiwyślą do łącza przez port eth. Obsługa ramek (podstawowa wersja) w głównej kości FPGA karty NetFPGA polega na przyjęciu ramki do kolejki na wejściu, zadecydowaniu o przeznaczeniu danej ramki, odpowiednim jego oznaczeniu i umieszczeniu ramki w odpowiedniej kolejce wyjściowej. Powyższy przykład przedstawił obsługę ramki przy współudziale procesora komputera i systemu operacyjnego, taka ramka przeszła przez kartę dwa razy. O wiele ciekawsza jest sytuacja, gdy do obsługi ramki wystarczy funkcjonalność zakodowana w kości FPGA i nie jest konieczna interakcja z systemem operacyjnym. Gdy karta samodzielnie obsługuje ruch, wydajność przetwarzania danych jest o wiele wyższa, gdyż pomijane jest dwukrotne przejście danych przez magistralę i obsługa przez procesor. Typowa taka sytuacja przedstawiona zostanie w kolejnym podrozdziale. B. Obsługa ramki ethernetowej przez przełacznik zrealizowany na karcie NetFPGA Załóżmy, że do karty NetFPGA zostało wgrane oprogramowanie pozwalające jej pracować jako przełącznik sieci Ethernet. Charakterystyczną cechą takiego przełącznika jest to, że potrafi on rozpoznać położenie adresata ramki (port, do którego jest on podłączony) i ograniczyć rozgłaszanie ruchu tylko do segmentów, w których znajduje się adresat ramek. Decyzję o porcie docelowym przełącznik podejmuje na podstawie zawartości swej tablic wiążącej adresy i numery portów, natomiast jej zawartość to efekt analizy ruchu przychodzącego (a dokładnie adresów nadawcy ramek) na konkretnych portach (ten mechanizm bywa określany jako proces uczenia się przełącznika). Jeśli do karty NetFPGA przygodzi ramka ethernetowa (załóżmy, że na port eth), jest ona umieszczana w buforze wejściowym. Gdy najdejdzie jej kolej, jest ona pobierana do obsługi przez Input Arbiter i przekazywana do dalszej analizy. W tym przypadku analiza ramki przez przełącznik sieciowy (karta NetFPGA pracuje jako przełącznik) sprowadza się do dwóch głównych czynności: ) przełącznik uczy się, że nadawca tej ramki (host o adresie takim jak źródłowy) jest podłączony do portu eth (gdyż to właśnie z tego portu przyszła od niego ramka); ) przełącznik wysyła ramkę na port, na którym (wg jego aktualnej wiedzy) jest podłączony adresat tej ramki (host, o adresie obecnym w ramce w polu docelowy), przy czym, jeśli zna położenie adresata, to ramka jest wysyłana na jeden konkretny port, a jeśli nie ma wiedzy o położeniu adresata ramki, taka ramka jest rozgłaszana na wszystkie porty poza tym, z którego przyszła. W tym momencie porty wyjściowe dla ramki są wybrane (są to porty związane z fizycznymi interfejsami, czyli mogą tobyć, lub - odpada, bo portem eth ta ramka przyszła) i ramka może być umieszczona w docelowych kolejkach wyjściowych (ciemnozielonych) i przesłana na zewnątrz karty. Całe zadanie karty (pracującej jako przełącznik sieci Ethernet) zostało w pełni zrealizowane. Należy zwrócić uwagę, że ramka weszła do karty i wyszła z niej bez udziału proceosora i systemu operacyjnego. To właśnie takie podejście stanowi wartość kart NetFPGA - w pełni sprzętowe przetwarzanie danych. 8 XVII Poznańskie Warsztaty Telekomunikacyjne
Rysunek 5. Położenie poszczególnych elementów ramki ethernetowej w jednostkach danych w karcie NetFPGA IV. OPIS PRZYKŁADOWYCH PROJEKTÓW Jednym z elementów pakietu instalacyjnego są kody przykładowych projektów. Są one w pełni kompletne, można je wykorzystać zarówno przez samodzielne skompilowanie dostarczonego kodu źródłowego bądź też użycie dostarczonego pliku bit. Poniżej zostaną omówione trzy projekty typowych urządzeń sieciowych (karta sieciowa, przełącznik oraz router) oraz projekt będący praktycznym ćwiczeniem w przygotowywaniu własnej aplikacji na kartę NetFPGA. A. Reference NIC Nazwa NIC pochodzi z angielskiego akronimu Network Interface Card. Poprawnie zainstalowania w systemie operacyjnym karta sieciowa występuje w dwóch postaciach. Pierwsza z nich to jej reprezentacja w uruchomionym oprogramowaniu komputera. Dzięki odpowiedniemu sterownikowi każdy port jest widoczny w systemie jako aktywny interfejs w sieciowy. Druga postać karty to jej fizyczna realizacja, czyli fizyczne porty (np. gniazda RJ45), do których mogą być podłączone przewody sieci Ethernet. Zadaniem karty jest odbieranie przychodzących ramek ethernetowych z portów fizycznych i przekazywanie ich do reprezentacji tych portów w systemie operacyjnym oraz odbieranie ramek wychodzących przez inferfejsy reprezentowane w systemie operacyjnym i wysyłanie ich przez porty fizyczne. Ramka odebrana na porcie ethx będzie przesłana do portu nfx, natomiast ramka wygenerowana przez system operacyjny na porcie nfy będzie wysłana do sieci przez port ethy. Te operacje bardzo łatwo można zobrazować na przykładzie rysunku. B. Reference switch Jednym z dostarczonych przykładowych projektów na kartę NetFPGA jest Reference switch, czyli kod przełącznika sieci Ethernet. Podstawowe działanie takiego przełącznika polega na odbieraniu ramek i przesyłaniu ich na wybrane porty, jego szczegóły przedstawiono w poprzednim rozdziale. Wśród dostępnych kodów źródłowych jest kod programu, który pozwala analizować zawartość tablicy przełącznika oraz zbierać statystyki ruchu do poszczególnych adresatów (adresów ). Bardzo cennym z punktu widzenia dydaktyki elementem tego kodu jest dostarczenie i przykładowe wykorzystanie pamięci TCAM (Ternary Content Addressable Memory). C. Reference router Ruter IP ma dwa główne zadania: określić adres następnego skoku (interfejs wyjściowy) oraz dokonać przełączenia (przesłania) pakietu na wybrany interfejs. Realizacja przełączenia odbywa się na zasadzie analogicznej jak w przypadku przełącznika - na podstawie odpowiednich bitów w słowie sterującym ramka ethernetowa z pakietem IP jest umieszczana w kolejce powiązanej odpowiednim portem wyjściowym. Należy pamiętać o wykonaniu operacji typowych dla rutingu (zmiana TTL) oraz przejściu do innego segmentu drugiej warstwy (czyli zmiana adresu źródłowego na adres interfejsu wychodzącego i ustawienie adresu docelowego na adres interfejsu przychodzącego w sąsiednim węźle). D. Crypto NIC Crypto_NIC to rozszerzona wersja reference NIC. Rozszerzenie polega na dodaniu jednego modułu do pipeline. Jest to moduł Crypto_NIC. Jego zadaniem jest szyfrowania i deszyfrowanie danych wychodzących i przychodzących. Zarówno szyfrowanie jak i deszyfrowanie polega na wykonaniu operacji XOR na danych i kluczu. Z uwagi na odwracalność operacji XOR, operacja szyfrowania i deszyfrowania jest realizowana tak samo. V. ELEMENTY PROJEKTU Twórcy środowiska do programowania kart NetFPGA wykonali ogromną pracę uruchamiając je i przygotowując demonstracyjne projekty. Na ich podstawie można przygotować projekty własnych urządzeń sieciowych. Można samodzielnie zaprojektować całe rozwiązanie, ale bez wątpienia warto skorzystać z dostarczonych szkieletów projektów. Każdy projekt powinien posiadać bufory wejściowe i wyjściowe (rysunek 4), standardowe elementy sterowania przetwarzaniem danych (Input Arbiter,Output Port Lookup, Output Queues) oraz własną funkcjonalność. Dzięki modułowości kodu wystarczy w odpowiednim miejscu dodać własny moduł, który odpowiednio wpasuje się w strukturę kodu i zapewni pożądaną funkcjonalność. Kod źródłowy na projekt karty obejmuje bardzo dużo plików, ale podstawowe wykorzystanie nie wymaga ich znajomości, a tym bardziej modyfikacji. Projekt NetFPGA od samego początku miał charakter dydaktyczny i wiele mechanizmów zostało tak zaprojektowanych, aby użytkownik nie musiał ich modyfikować. VI. MECHANIZMY PRZYGOTOWANIA I WERYFIKOWANIA POPRAWNOŚCI PROJEKTU A. Przygotowanie projektu Jak wspomniano wcześniej, możliwe jest całkowicie samodzielne przygotwanie oprogramowania karty NetFPGA. Jednak wymaga to dużo czasu, a przede wszystkim, ogromnej wiedzy i doświadczenia. Dlatego też nawet doświadczeni deweloperzy chętnie korzystają z wzorców dostarczonych przez twórców kart NetFPGA. W takim przypadku przygotowanie PWT - Poznań - grudnia 9
własnego projektu sprowadza się do dodania pustego własnego modułu i zaprogramowania jego funkcjonalności. Takie podejście wydaje się dużo prostsze. I takie jest. Ale prostsze nie oznacza proste. Nadal należy pamiętać o wielu rzeczach: o odpowiedniej interakcji z innymi modułami, o zachowaniu odpowiedniej konwencji nazewnictwa zmiennych (aby nie doprowadzić do konfliktu nazw), o zaimplementowaniu poprawnego sterowania itp. Własny moduł należy zdefiniować w Verilogu, jego definicję umieścić w odpowiednim miejscu w drzewie plików projektu, powiązać go z innymi modułami oraz uzupełnić informację o powiązaniach z nim w pliku projektu. Czynności, które należy wykonać mogą się nieco różnić w zależności od wersji kodu, z którą pracujemy. Na stronie projektu są dostępne opisy poszczególnych etapów, najwięcej praktycznej wiedzy z tego zakresu można zdobyć podczas warsztatów z programownia tych kart [6], [7]. Bardzo często jest tak, że kod naszego projektu wymaga fragmentów, które objęte są zewnętrzną licencją (np. IP Core, T, itp). Co więcej, kod źródłowy, który wystarczy do kompilacji, nie stanowi całości poprawnego projektu. Aby być pewnym poprawności projektu należy przygotować również pliku testów, które pozwolą automatycznie zweyryfikować poprawność projektu. B. Testowanie Analiza funkcjonalności nawet podstawowych projektów na kartę NetFPGA jest bardzo złożona. Aby ją ułatwić, a wręcz umożliwość i urealnić, opracowano mechanizm testów. Polega on na wygenerowaniu testowego ruchu (przy pomocy bibloteki Scapy napisanej w Perlu) i przepuszczeniu go przez symulator (ModelSim [4] lub ISim [5]). Każda funkcjonalność powinna być testowana pojedynczo, tzn. należy przygotować bardzo dużo testów, przy czym każdy test skupia się na pojedynczym mechanizmie, a jego wynik jest dwuwartościowy - PASS lub FAIL. Nawet wykonanie wszystkich testów z wynikiem pozytywnym nie oznacza poprawności całego projektu, gdyż nie ma pewności, że przygotowane testy pokrywają wszystkie funkcjonalności. Niestety, nawet jeden wynik negatywny oznacza niepoprawność i konieczność poprawiania kodu źródłowego. Należy zwrócić uwagę, że błędy mogą być zarówno w kodzie projektu, jak i w kodzie testów. Niestety, możliwe są wyniki fałszywie pozytywne oraz fałszywie negatywne. Jak widać, testowanie projektów jest bardzo złożonym, żmudnym i pracochłonnym procesem, ale i bardzo potrzebnym. Testowanie sprowadza się do przygotowania pierwotnej reprezentacji ruchu ethernetowego (ramek) dla każdego portu, które będą wysyłane do symulatora działania kodu oraz reprezentacji ruchu, który spodziewamy się otrzymać na poszczególnych portach. Ruch pierwotny jest wysyłany do symulatora, a to co z niego wyjdzie jest porównywane z ruchem spodziewanym. Porównanie może dać wynik pełnej zgodności (wówczas test jest zaliczany) lub nie (wówczas test nie jest zaliczany). Przykładowe testowanie kodu karty sieciowej sprowadza się do przygotowania zawartości testowej ramki ethernetowej (jako tablicy bajtów) i wysłanie jej na port np. eth. W Rysunek 6. Kod w języky Python - fragment odpowiedzialny za testowanie karty sieciowej - przygowanie pakietu, wysłanie go na cztery interfejsy i oczekiwanie na jego niezmodyfikowaną kopię na czterech wyjściach przypadku karty sieciowej dokładnie te same dane (bez modyfikacji) są oczekiwane na wyjściu bufora. W przypadku testowania przełącznika należy zwrócić uwagę na stan jego pamięci (tablicy ) i numery portów, na których pojawia się ruch po przejściu przez symulator. Błędy mogą polegać na tym, że ramki po przejściu przez symulator będą inne niż spodziewane, że ramki nie dotrą do portów, na których ich się spodziewamy lub też ramki pojawią się na portach, na których ich nie oczekujemy. W przypadku testowania rutera należy zwrócić uwagę na poprawność adresów IP oraz oczekiwać zmienionego pakietu IP ze zmniejszoną wartością TTL oraz zmienionymi adresami warstwy (). Fragment przykładowego kodu do testowania funkcjonalnosci karty sieciowej przedstawiono na rysunku 6. Definicja testu zawiera dokładny opis sytuacji na wejściu i na wyjściu. Symulator generuje rezultaty po przejściu przez zaprogramowaną funckcjonalność, a następnie mechanizm testów porównuje opis sytuacji wygenerowanej przez sumulator z opisem spodziewanej sytuacji zadeklarowanym testach. Pełna zgodność oznacza zaliczenie testu, choć jedna rozbieżność powoduje niezaliczenie testu. Takie podejście pozwala zautomatyzować testy. Mechanizm można opisywać bardzo szeroko, ale nie jest to głównym celem tego artykułu. Możliwa jest również analiza sytuacji wewnątrz poszczególnych modułów. Do tego celu wykorzystywane jest odpowiednie oprogramowanie (ModelSim lub ISim). Fragmentu przykładowego widoku okna programu ModelSim podczas analizy w trybie graficznym przedstawiono na rysunku 7. Warto zwrócić uwagę, że w przedstawionym przykładzie pojawiają się parametry (dwa adresy, EthType) ustawione w kodzie z rysunku 6. C. Przygotowanie kodu uruchomieniowego Gdy wszyskie przeprowadzone testy pozwolą założyć, że przygotowany kod jest poprawny, można przystąpić do syntezy. Jest to proces wieloetapowy i bardzo złożony. Bardzo często zajmuje ponad godzinę nawet na współcześnie wydajnych komputerach. Dlatego też istotne jest, aby syntezie poddawać wyłącznie przetestowane projekty. Efektem poprawnie zakończonej syntezy jest plik z rozszerzeniem bit, który można wgrać do karty NetFPGA i uruchomić własny projekt. Do sterowania takim projektem można użyć dodatkowego oprogramowania, które otczytuje i ustawia wartość odpowiednich rejestrów w karcie NetFPGA. XVII Poznańskie Warsztaty Telekomunikacyjne
Rysunek 7. Graficzne przedstawienie efektów pracy symulatora (fragment okna Wave programu ModelSim) VII. WYKORZYSTANIA KART W PROCESIE DYDAKTYCZNYM Pierwsza styczność studentów z kartami sprowadza się do teoretycznego wykładu na ich temat. Następnie demonstrowany jest przebieg przygotowania przykładowego oraz własnego projektu. Podkreślone są czynności, których nie można pominąć. Podczas laboratorium studenci pracują na odpowiednio przygotowanych maszynach virtualnych, które zostały przygotowane tak, aby skupić się na najważniejszych elementach. Pliki maszyn wirutalnych są udostępnianie zainteresowanym studentom, dzięki temu samodzielnie mogą poszerzać doświadczenie i ugruntowywać wiedzę zdobytą na zajęciach. Do pełnego wykorzystania narzędzi konieczne są licencje, które udostępniane są w ramach programu Europractice [6]. Dzięki odpowiednim połączeniom VPN studenci mogą na nich pracować również w domu. Podczas zajęć studenci dogłębnie poznają budowę sprzętu sieciowego, a także towarzyszącego jemu oprogramowania (sterowniki), w praktyczny sposób spotykają się również z profesjonalnym oprogramowaniem szeroko wykorzystywanym na skalę przemysłową. VIII. PODSUMOWANIE Karta NetFPGA, zarówno w wersji z portami G i G, jest wszechstronnym narzędniem badawczym, naukowym oraz edukacyjnym. Dzięki niej można realizować między innymi prototypowe urządzenia sieciowe realizujące niestandardowe protokoły sieciowe. Dzięki otwaremu kodowi źródłowemu, zarówno dla części sprzętowej jaki i sterownika programowego, stanowi ona nieocenioną pomoc dydaktyczną, szczególnie tak bliską rzeczywistym urządzeniom sieciowym. IX. PODZIEKOWANIA Projekt został sfinansowany ze środków Narodowego Centrum Nauki przyznanych na podstawie decyzji numer DEC- //B/ST7/959 LITERATURA [] Główna strona projektu NetFPGA http://netfpga.org. [] Strona informacyjna grupy NetFPGA http://yuba.stanford.edu/. [] Strona informacyjna - Nick McKeown http://yuba.stanford.edu/~nickm/. [4] Główna strona www Computer Laboratory, Faculty of Computer Science and Technology, University of Cambridge http://www.cl.cam.ac.uk/. [5] Strona informacyjna - Andrew W. Moore www.cl.cam.ac.uk/~awm/. [6] Wydarzenia w ramach projektu NetFPGA http://netfpga.org/events. [7] Strona informacyja warsztatów NetFPGA http://www.netfpga.pl. [8] Glen Gibb, John W. Lockwood, Jad Naous, Paul Hartke, and Nick McKeown NetFPGA Open Platform for Teaching How to Build Gigabitrate Network Switches and Routers IEEE Trans. on Education, 8. [9] Strona produktu NetFPGA G http://www.digilentinc.com/products/ Detail.cfm?Prod=NETFPGA. [] Strona produktu NetFPGA G http://www.hitechglobal.com/boards/ PCIExpress_SFP+.htm. [] Xilinx University Program http://xilinx.com/university/. [] Strona projektu Środowisko testowe protokołów sieciowych na bazie systemu OpenFlow http://openflow.et.put.poznan.pl. [] Główna strona www firmy Xilinx http://xilinx.com/. [4] ModelSim - strona produktu http://mentor.com/products/fv/modelsim [5] ISim - strona produktu http://www.xilinx.com/tools/isim.htm. [6] EUROPRACTICE Software Service http://www.europractice.stfc.ac.uk. PWT - Poznań - grudnia