Wykonanie ćwiczenia laboratoryjnego pt. „Łącze fizyczne USB” wymagać będzie użycia zestawu modułów laboratoryjnych SML3 wskazanych instrukcją (patrz załącznik „ŁĄCZE FIZYCZNE USB”), wyposażonych w układy o parametrach umożliwiających sprzętową implementację protokołu USB, oraz predefiniowanego bloku funkcjonalnego implementującego poziom logiczny interfejsu w układzie FPGA. W niniejszym rozdziale przedstawione zostaną warianty rozwiązań, które były brane pod uwagę w trakcie koncepcyjnej fazy projektu tego ćwiczenia.
Obecnie wykorzystuję się kilka możliwych wariantów implementacji protokołu USB. Zdecydowanie najpopularniejszym z nich jest rozwiązanie, w którym właściwą warstwę protokołu obsługuje dedykowany układ mikrokontrolera komunikujący się z urządzeniem końcowym, np. za pomocą interfejsu równoległego. Jest to jednak rozwiązanie nie nadające się do modyfikacji – nie ma możliwości ingerencji w mechanizmy wspierające działanie interfejsu - zatem nie znajdzie zastosowanie w niniejszej pracy.
Protokół uniwersalnej magistrali szeregowej to zaawansowany protokół komunikacyjny. Ze względu na jego wielowarstwowość oraz stopień skomplikowania samodzielna jego implementacja w strukturze układu FPGA byłaby zadaniem bardzo pracochłonnym i zdecydowanie wykraczającym poza zakres niniejszej pracy. Przyjęto zatem rozwiązanie polegające na modyfikacji wybranych elementów gotowego projektu w postaci szablonu. Szablon ten powstanie na bazie projektu opisanego językiem HDL i udostępnionego przez jego autora w internecie.
Na rynku dostępne są moduły implementujące różne wersje interfejsu uniwersalnej magistrali szeregowej, tzw. moduły IP Core. W niniejszej pracy zdecydowano się na zastosowanie modułu IP Core zgodnego ze standardem uniwersalnej magistrali szeregowej w wersji 1.1. Decyzja ta znajduje swoje uzasadnienie w charakterze ćwiczenia „Łącze fizyczne USB”, którego celem jest zapoznanie studenta z prostymi mechanizmami wykorzystywanymi w układzie obsługi linii szeregowej. Zatem, nie dostępna prędkość transmisji, a prostota rozwiązania jest najistotniejszym czynnikiem z punktu widzenia ćwiczenia. Moduły implementujące standard 2.0 są znacznie bardziej rozbudowane od tych
19 implementujących standard 1.1, a pełne wykorzystanie ich możliwości w ramach zajęć laboratoryjnych przedmiotu UZINT jest w zasadzie niemożliwe. Poniżej przedstawiono wybrane moduły będące sprzętową implementacją protokołu USB 1.1.
Jednym z modułów IP Core, dostępnym odpłatnie za pośrednictwem strony Altery jest oferowany przez firmę SLS moduł USB Function Controller, oznaczony nazwą USB11SR [10]. Standardowo moduł USB Function Controller wspiera transmisję w trybie FULL SPEED, opcjonalnie jednak może być rozszerzony o możliwość transmisji w trybie LOW SPEED. Modyfikacja ta realizowana jest na specjalne życzenie zamawiającego i podlega dodatkowej opłacie. Moduł USB Function Controller wykorzystuje pamięć typu RAM oraz wspiera trzy prekonfigurowane punkty końcowe: punkt końcowy transmisji sterującej , transmisji masowej typu IN oraz transmisji masowej typu OUT. Na życzenie klienta może on posiadać do 15 punktów końcowych, z których każdy posiada kontroler wspierający transfer pilny, masowy oraz izochroniczny. Moduł został zoptymalizowany pod kątem układów FPGA firmy Altera, a jego funkcjonalność została zweryfikowana z wykorzystaniem oprogramowania EDA Altera Quartus II. Wraz z modułem USB Function Controller dostępna jest prekompilowana biblioteka projektu ModelSim umożliwiająca symulację i weryfikację pracy modułu. Moduł USB Function Controller zaprojektowany jest w języku Verilog. Komunikacja z urządzeniem wykonawczym odbywa się za pomocą interfejsu AVALON (szyny systemowej oferowanej przez oprogramowanie Quartus w układach firmy Altera). Wraz z modułem dostarczany jest komplet dokumentacji oraz oprogramowanie umożliwiające wykorzystanie wszelkich jego możliwości.
Moduł USB11SR udostępniany jest w formie zabezpieczonej przed modyfikacją, natomiast specyfika realizowanego ćwiczenia laboratoryjnego wymaga, aby możliwe było wprowadzenie zmian do wykorzystanego oprogramowania. Z tej przyczyny moduł ten nie może być wykorzystany na potrzeby projektowanego ćwiczenia.
Alternatywą dla płatnych modułów IP Core są bezpłatne moduły Open Core.
Wykorzystanie w projekcie oprogramowania opartego na Licencji Wolnego Oprogramowania ma równie wiele wad jak i wiele zalet. Do wad zaliczyć należy brak wsparcia ze strony producenta oprogramowania - moduły Open Core powstają przeważnie jako efekt pracy osób prywatnych, a nie specjalistycznych pracowni projektowych. Często problem stanowi także niejasna dokumentacja bądź jej brak. Istnieje co prawda możliwość kontaktu z autorem drogą mailową lub z innymi użytkownikami poprzez specjalistyczne
20 fora dyskusyjne, jednak może być to niewygodne oraz mało skuteczne. Zaletą tego rozwiązania jest natomiast to, że moduły dostępne na licencji wolnego oprogramowania można bezpłatnie wykorzystywać i modyfikować, nie naruszając prawa autorskiego.
Na szczególną uwagę zasługuje moduł USBHostSlave autorstwa Steve’a Fielding’a dostępny na stronie internetowej opencores.org, który zyskał pozytywną opinię użytkowników [9]. Projekt USBHostSlave implementuje zarówno mechanizmy odpowiedzialne za układ hosta jak i za układ funkcji USB. Moduł USBHostSlave komunikuje się z urządzeniem końcowym za pomocą interfejsu Wishbone, który jest odpowiednikiem interfejsu AVALON zastosowanego w module USB Function Controller firmy SLS. Zaletą modułu jest fakt, że jest to wersja stabilna projektu, natomiast wadą szczątkowa dokumentacja techniczna.
Warto również zwrócić uwagę na moduły Open Core stworzone przez Rudolf’a Usselmann’a. Autor, w proponowanej przez siebie sprzętowej implementacji protokołu uniwersalnej magistrali szeregowej przewiduje wykorzystanie dwóch oddzielnych modułów, usb_phy [15] oraz usb1_funct [14] (patrz rysunek 4.1).
Rysunek 4.1 Schemat blokowy rozwiązania proponowanego przez Rudolf’a Usselmann’a Pierwszy z nich odpowiada za niskopoziomowe mechanizmy protokołu USB, a w jego strukturach zaimplementowano obsługę konwersji szeregowo równoległej, wstawianie i usuwanie bitów zero oraz kodowanie i dekodowanie NRZI. Moduł usb1_funct natomiast stanowi modyfikację modułu „usb” implementującego protokół w wersji 2.0. tego samego autora. Usunięto z niego fragmenty odpowiedzialne za transmisję w trybie FULL SPEED oraz zrezygnowano z pamięci dzielonej na rzecz kolejek FIFO. W podstawowej konfiguracji moduł zawiera 6 punktów końcowych, w tym jeden do transmisji sterującej, jeden do izochronicznej wyjściowej, po jednym do transmisji masowej wejściowej oraz wyjściowej oraz jeden do wejściowej transmisji pilnej. Podobnie jak USBHostSlave, oba moduły napisane są w języku Verilog. Moduły komunikują się ze sobą za pomocą uproszczonego interfejsu UTMI. Rozwiązanie to pozawala na oddzielne wykorzystanie modułu usb_phy, np. w konfiguracji z układem mikroprogramowalnym. Do
21 znanych wad modułów należy natomiast zaliczyć brak walidacji transmisji w module odpowiedzialnym za transmisję odbiorczą.
Po dokonaniu analizy dostępnych rozwiązań zdecydowano się wykorzystać, na potrzeby niniejszej pracy, moduł USBHostSlave autorstwa Steve’a Fieldinga. W tym miejscu warto zauważyć, że wybór stosownego modułu projektowego nie jest decyzją nieodwracalną. W razie zaistnienia takiej potrzeby możliwa jest wymiana zastosowanego modułu IP Core na inny, np. zgodny ze standardem USB 2.0.
22