Uniwersytet Zielonogórski Wydział Elektrotechniki, Informatyki i Telekomunikacji PRACA MAGISTERSKA REALIZACJA KONTROLERÓW O PODWYŻSZONYM STOPNIU BEZPIECZEŃSTWA W FPGA O ARCHITEKTURZE Z WBUDOWANYMI PROCESORAMI inż. Arkadiusz Bukowiec Promotor: dr inż. Marek Węgrzyn Zielona Góra, czerwiec 2003
Streszczenie Prezentowana praca dyplomowa przedstawia realizacje oraz sposób testowania i weryfikacji przykładowej architektury kontrolera o podwyższonym stopniu bezpieczeństwa. Do jego realizacji wykorzystano układy FPGA z osadzonymi mikroprocesorami. Rozwiązanie bazuje na dokonaniu podziału zadań pomiędzy część sprzętową oraz programową, a następnie zrealizowaniu ich z wykorzystaniem języków opisu sprzętu oraz języków programowania. Napisany program realizuje algorytm procesora slave sterownika wraz z przykładowymi blokami funkcyjnymi, natomiast pozostałe moduły wykonane zostały jako część sprzętowa. W trakcie realizacji modelu położono duży nacisk na zaprojektowanie protokołu wymiany danych pomiędzy oboma częściami tak, aby wykorzystywał on w jak największym stopniu możliwości oferowane przez wybrany układ. Testowanie układu podzielone zostało na etapy. Na początku zweryfikowano działanie programu. Do tego celu wykorzystano emulator procesora, na którym ma być wykonywany dany program. Cześć sprzętowa została przesymulowana z wykorzystaniem plików testowych oraz modeli symulacyjnych, realizujących zadania części programowej, napisanych w wybranym języku opisu sprzętu. Symulacji poddano każdy z modułów z osobna jak i cały kontroler. Testy te zostały powtórzone zarówno dla modeli symulacyjnych, po syntezie jaki i do symulacji czasowej. Słowa kluczowe: bezpieczny programowalny sterownik logiczny, PLC, kontroler, język opisu sprzętu, Verilog, układ FPGA, synteza, implementacja, język programowania, asembler, mikroprocesor, procesor, master-slave, blok funkcyjny - i -
Spis treści Spis rysunków... iv Spis tabel... v 1. Wstęp... 1 1.1. Cel pracy... 2 1.2. Struktura pracy... 2 2. Koncepcja architektury sterownika bezpiecznego... 3 2.1. Procesor master... 4 2.2. Procesor slave... 4 2.3. Układ wejściowy... 5 2.4. Układ wyjściowy... 6 2.5. Jednostka sterująca przepływem danych... 7 3. Wprowadzenie do realizacji systemów sprzętowo-programowych w układach FPGA... 8 3.1. Układy Virtex-II PRO z procesorem PowerPC... 8 3.2. Procesor MicroBlaze dla układów Spartan oraz Virtex... 10 3.3. Układy z rodziny Excalibur... 11 3.4. Procesor Nios dla układów firmy Altera... 12 3.5. Układy z rodziny FPSLIC... 13 3.6. Oprogramowanie Seamless... 15 4. Sposoby realizacji układów o dwu procesowej architekturze... 16 4.1. Realizacja procesorów z wykorzystaniem dwóch mikroprocesorów... 16 4.2. Realizacja modułu master-slave z wykorzystaniem struktur programowalnych FPGA... 18 4.3. Realizacja procesorów w konwencji FPGA - mikroprocesor... 19 5. Realizacja i testowanie kontrolera... 22 5.1. Sposób realizacji... 23 5.2. Opracowanie protokołu komunikacyjnego... 24 5.3. Realizacja procesora slave... 27 5.4. Realizacja części sprzętowej... 32 5.4.1. Realizacja jednostki kontrolującej przepływ danych... 33 5.4.1.1. Synteza i implementacja jednostki kontrolującej przepływ danych... 35 5.4.1.2. Symulacja jednostki kontrolującej przepływ danych... 36 5.4.2. Implementacja części sprzętowej kontrolera... 37 5.5. Procedura testowa kontrolera... 37 5.6. Alternatywne sposoby realizacji sterownika bezpiecznego... 40 6. Podsumowanie... 43 - ii -
Literatura... 45 Dodatek A. Lista rozkazów sterownika... 46 Dodatek B. Mapa pamięci sterownika... 47 Dodatek C. Struktura projektu... 48 Dodatek D. Struktura płyty CD-ROM... 49 - iii -
Spis rysunków Rysunek 2.1. Architektura bezpiecznego sterownika logicznego... 3 Rysunek 2.2. Schemat układu wejściowego... 5 Rysunek 2.3. Schemat układu wyjściowego... 6 Rysunek 3.1. Schemat działania oprogramowania Seamless... 15 Rysunek 4.1. Realizacja procesorów master-slave z wykorzystaniem dwóch mikroprocesorów... 16 Rysunek 4.2. Moduł procesora master zbudowany w oparciu o mikroprocesor... 17 Rysunek 4.3. Realizacja modułu master-slave z wykorzystaniem układów FPGA... 19 Rysunek 4.4. Realizacja procesorów w konwencji FPGA-mikroprocesor... 20 Rysunek 4.5. Realizacja układu master-slave z wykorzystaniem układu programowalnego z wbudowanym mikroprocesorem... 20 Rysunek 5.1. Podział kontrolera na układy scalone... 23 Rysunek 5.2. Interfejs komunikacyjny pomiędzy jednostką sterująca a procesorem slave... 24 Rysunek 5.3. Mapa pamięci SRAM... 25 Rysunek 5.4. Algorytm działania procesora slave... 27 Rysunek 5.5. Schemat bloku obsługującego przerwanie... 28 Rysunek 5.6. Realizacja blok funkcyjnego IN_M_CHR... 30 Rysunek 5.7. Realizacja blok funkcyjnego ADD_INT... 30 Rysunek 5.8. Realizacja blok funkcyjnego DFF_CHR... 31 Rysunek 5.9. Realizacja bloku funkcyjnego IN_M_CHR w procesorze slave... 32 Rysunek 5.10. Interfejs jednostki sterującej przepływem danych... 33 Rysunek 5.11. Algorytm działania jednostki sterującej przepływem danych... 34 Rysunek 5.12. Symulacja układu sterującego przepływem danych... 36 Rysunek 5.13. Schemat blokowy programu kontrolera... 38 Rysunek 5.14. Przebieg czasowy symulacji kontrolera... 38 Rysunek 5.15. Analiza symulacji sterownika z wykorzystaniem Code Coverage... 39 Rysunek 5.16. Architektura kontrolera o trzech parach procesorów master-slave... 40 Rysunek A.1. Struktura rozkazów sterownika... 46 Rysunek B.1. Mapa pamięci procesora master... 47 Rysunek C.1. Struktura projektu... 48 - iv -
Spis tabel Tabela 3.1. Układy z rodziny Virtex-II PRO... 9 Tabela 3.2 Układy z rodziny Excalibur... 11 Tabela 3.3. Układy serii AT94... 13 Tabela 5.1. Bloki funkcyjne zaimplementowane w kontrolerze... 29 Tabela 5.2. Zajętość jednostki sterującej w strukturze FPGA... 35 Tabela 5.3. Zajętość kontrolera w strukturach FPGA... 37 Tabela A.1. Lista rozkazów sterownika... 46 - v -
1. Wstęp W ciągu ostatnich lat nastąpił gwałtowny rozwój informatyki i elektroniki. Umożliwiło to projektowanie coraz bardziej złożonych i skomplikowanych układów cyfrowych. Wraz ze złożonością wykonywanych układów coraz większą rolę w ścieżce projektowej zaczęły odgrywać języki opisu sprzętu (np. Verilog, VHDL). Dają one bardzo duże możliwości w modelowaniu układów oraz stanowią potężne narzędzie podczas testowania ich funkcjonalności. Chociaż zastosowanie tych języków umożliwia zaprojektowanie wyspecyfikowanych procesorów, sterowników oraz różnego zastosowania układów cyfrowych, nie są one w stanie wyprzeć klasycznych rozwiązań, do których można zaliczyć mikroprocesor (np. 8051, 80186) wraz z oprogramowaniem. Coraz częściej jednak języki opisu sprzętu są wykorzystywane do tworzenia układów, które wspólnie z klasycznymi procesorami mają tworzyć większe systemy. Rozwiązanie takie przez długi czas wymagało jednak oddzielnego zaprojektowania układu oraz napisania programu dla mikroprocesora. W taki sposób tworzone są systemy na płytce drukowanej (ang. System-On-Board, SoB). Ostatnio jednak pojawiły się na rynku układy scalone, które zawierają jednocześnie procesor, jak i bloki konfigurowalne ASIC. Sytuacja taka dotyczy zarówno układów programowalnych maską jak i układów PLD lub FPGA. Zastosowanie takich układów umożliwia umieszczenia całego systemu w jednym układzie programowalnym (ang. System-On-Chip, SoC; System-On-Programmable- Chip, SoPC). Pojawienie się takich układów spowodowało, że na rynku pojawiło się jednocześnie specjalistyczne oprogramowanie umożliwiające współbieżne projektowanie części sprzętowej oraz programu dla mikroprocesora oraz wspólną ko-weryfikacje obu części. Układy te mogą znaleźć idealne zastosowanie podczas projektowania kontrolerów. Ponieważ obecnie do sterowania procesów technologicznych lub obiektów technicznych coraz częściej stosuje się sterowniki programowalne. Z uwagi na coraz częstsze przypadki zastosowań takich rozwiązań wymagane jest aby kontrolery były w coraz to większym stopniu niezawodne, a w przypadku wystąpienia samo-awarii były w stanie dokonać odpowiedniej sygnalizacji. - 1 -
1.1. Cel pracy Celem tej pracy dyplomowej jest realizacja przykładowej architektury bezpiecznego programowalnego kontrolera logicznego z wykorzystaniem układu programowalnego z osadzonym mikroprocesorem. Ze względu na specyfikę układów programowalnych z wbudowanym procesorem należy w tym przypadku zwrócić szczególną uwagę na odpowiednie zaprojektowanie architektury sterownika, tak aby wykorzystywała ona zalety jakie dają układy o takiej architekturze. Bardzo ważną częścią pracy jest przeprowadzenie ko-weryfikacji działania układu, co umożliwi wykrycie i usunięcie prawdopodobnych usterek jeszcze w fazie projektowej układu. Do tego celu wymagane będzie zastosowanie specjalistycznego oprogramowania. 1.2. Struktura pracy W rozdziale drugim zostanie omówiona architektura kontrolera. Zostaną tam przedstawione podstawowe założenia projektu, które są niezależne od sposobu realizacji. Trzeci rozdział prezentuje zastawienie aktualnie istniejących układów programowalnych z osadzonym mikroprocesorem. Celem tego rozdziału jest przybliżenie architektury i technologii wykonania takich układów oraz ukazania podstawowych różnic między poszczególnymi przedstawicielami tej grupy. W czwartym rozdziale przedstawione zostaną różne sposoby realizacji układu. Dokonane zostanie porównanie zalet i wad poszczególnych rozwiązań oraz możliwości ich realizacji w technologii SoB i SoC. Następną cześć pracy stanowi realizacja sterownika. Zostanie tu omówiony podział zadań pomiędzy część programową oraz sprzętową. Przedstawiona będzie ostateczna architektura kontrolera z uwypukleniem elementów, które wynikają z zastosowania konkretnego układu programowalnego z osadzonym mikroprocesorem. W dalszej części tego rozdziału zostanie ukazany sposób realizacji i ko-weryfikacji układu. - 2 -
2. Koncepcja architektury sterownika bezpiecznego Działanie sterownika [1] [2] [3] oparte jest na dwuprocesorowej budowie master-slave (Rysunek 2.1). Procesor master steruje przepływem danych i inicjuje slave a do wykonywania obliczeń. Slave przetwarza dane, otrzymane z mastera, według algorytmów zapisanych w formie bloków funkcyjnych [5]. W celu wykrywania błędów zastosowano dwie pary takiego układu procesorów, wykonującego ten sam program sterownika. W układzie zastosowano również komparator, który dokonuje porównuje zgodność wszystkich danych z obu par procesorów. Master Master Jednostka sterująca przepływem danych Slave Wyjścia Komparator Komparator Slave Wyjścia Układ wejściowy Zatrzask Zatrzask Układ wyjściowy BImulti BI OK BO Rysunek 2.1. Architektura bezpiecznego sterownika logicznego Sterownik komunikuje się z otoczeniem poprzez porty wejściowe (BI i BImulti) i wyjściowe (BO). Stan wejść jest zapamiętywany na początku każdego cyklu - 3 -
w układzie wejściowym. Odczytu z układu wejściowego dokonują procesory slave na żądanie procesora master. Stany wyjść są przechowywane w buforach wyjściowych wbudowanych do procesorów slave, a na koniec cyklu przepisywane do zatrzasków wyjściowych. Następnie są one porównywane w układzie wyjściowym i udostępniane na zewnątrz sterownika. Układ wyjściowy jednocześnie generuje sygnał statusu pracy OK, a w razie awarii sterownika zapewnia on ustawienie wyjść w stan wyłączenia (bezpieczny stan sterownika). 2.1. Procesor master Program wykonywany przez procesor master napisany jest w specjalnym języku sterownika [1]. Język ten zawiera dwie grupy instrukcji: instrukcje sterujące przepływem danych, instrukcje skoku. Instrukcja sterująca przesyłaniem danych zawiera informacje skąd ma zostać pobrana dana i dokąd ma być wysłana. Natomiast grupa instrukcji skoku jest dość specyficzna, gdyż zawiera tylko jedną, instrukcję skoku warunkowego, która dokonuje skoku pod zadany adres lub pod adres z rejestru NSA procesora. Organizacja rejestrów danych i pamięci w procesorze master jest 8-bitowa. Wiąże się to z rozmiarem wprowadzonych trzech typów danych 8, 16 i 32 bity, czyli jedno, dwa i cztery słowa, umownie zwanych bool, integer oraz long. W architekturze procesora nie przewidziano występowania typów zmiennoprzecinkowych. Procesor master współpracuje z pamięciami ROM i RAM. W pamięci ROM umieszczony jest kod programu oraz stałe i początkowe stany sterownika, natomiast w pamięci RAM umieszczone są zmienne i aktualne stany sterownika. Organizacja pamięci [1] posiada stały podział obszaru danych ze względu na rozmiar i znaczenie danej w programie. 2.2. Procesor slave Procesor master nie wykonuje żadnych obliczeń arytmetyczno-logicznych. Do tego celu wykorzystywany jest moduł slave, który posiada odpowiednie bloki funkcyjne [5] umożliwiające realizacje wymaganych działań. W celu wykonania - 4 -
jakichkolwiek obliczeń master przesyła do procesora slave numer działania, które ma zostać wykonane oraz dane a po zakończeniu obliczeń pobiera wynik. Ponieważ procesor slave nie posiada pamięci stanów wewnętrznych poszczególnych bloków funkcyjnych muszą one zostać przekazane wraz z danymi wejściowymi. Układ slave jest równocześnie odpowiedzialny za ustawienie wartości sygnału wyjściowego (BO). Przechowywana jest ona w rejestrze wyjściowy i bezpośrednio przekazywana do bloku wyjściowego, który po zakończeniu cyklu zapisuje ją w buforze wyjściowym. 2.3. Układ wejściowy Układ wejściowy odpowiedzialny jest za odczyt wartości wejść kontrolera i przechowywanie ich przez cały cykl pracy. 8-bitowa wartość wejścia BI zapamiętywana jest w wewnętrznym rejestrze układu wejściowego (Rysunek 2.2). Natomiast 32 multipleksowane 8-bitow dane przesłane za pomocą wejścia BImulti zapisywane są w wewnętrznej pamięci RAM 32 8. Aby umożliwić niezależny dostęp do tych wartości obu procesorom slave zastosowano dwie pamięci RAM przechowujące te same dane. SLAVE 1 SLAVE 2 Adres Dane Dane Adres Dane Dane Adres (5) Adres (5) Adres (4:0) Adres (4:0) Adres RAM 32x8 RAM 32x8 Adres STEP_CYCLE Jednostka kontrolna Rejestr BI S BImulti BI Rysunek 2.2. Schemat układu wejściowego W celu odczytu poszczególnych danych procesor slave komunikuje się z układem wejściowym za pomocą 6-bitowej magistrali adresowej i 8-bitowej linii - 5 -
danych. W celu odczytu żądanej wartości procesor slave ustawia odpowiedni adres. Najstarszy bit linii adresowej informuje czy odczytana ma być dana z pamięci RAM czy z rejestru wejścia BI. W przypadku odczytu danej z pamięci RAM pozostałe 5 bitów interpretowane jest jako adres komórki w pamięci, natomiast w przypadku odczytu z rejestru bity te są ignorowane. Odczytana dana przesyłana jest do procesora slave za pośrednictwem magistrali danych. 2.4. Układ wyjściowy Układ wyjściowy dokonuje analizy sygnałów informujących o poprawności działania poszczególnych układów kontrolera oraz jest odpowiedzialny za ustawienie stanu wyjścia (BO). W sytuacji, gdy któryś z sygnałów określających stan modułu informuje o jego błędnym działaniu lub wartości wyjść z obu procesorów slave różnią się, układ ustawia sygnał prawności pracy (OK) w stan niski i ustawia wyjścia w stan bezpieczny. Sygnał OK jest generowany poprzez funkcję and wszystkich sygnałów informujących o poprawności działania poszczególnych układów oraz wyników komparatorów (Rysunek 2.3). Sygnał ten jest zatrzaskiwany w specjalnym rejestrze tak, aby w przypadku wykrycia błędu jedynie sygnał zerujący mógł przywrócić stan wysoki. Sygnały poprawności pracy Zatrzask OK HIMA_RESET BO - Slave1 BO - Slave2 = BO Rysunek 2.3. Schemat układu wyjściowego - 6 -
Za stan bezpieczny uważana jest sytuacja gdy wszystkie linie wyjścia znajdują się w stanie niskim. W celu osiągnięcia takiego efektu realizowana jest funkcja and poszczególnych bitów wyjścia z sygnałem OK. 2.5. Jednostka sterująca przepływem danych Zadaniem jednostki sterującej przepływem danych jest synchronizacja pracy obu par procesorów master-slave. Cel ten realizowany jest poprzez oczekiwanie aż oba procesory master wyślą dane do odpowiadających im procesów slave i dopiero następnie przekazanie ich. Synchronizacja taka realizowana jest również w przeciwnym kierunku. Dodatkowym zadaniem jakie realizuje układ sterujący przepływem danych jest przekazywanie wszystkich przechodzących przez niego danych do modułu komparatorów. Komparatory te porównują odpowiadające sobie dane z jednej pary procesorów master-slave z danymi z drugiej pary procesorów. W sytuacji, gdy dane te różnią się między sobą generowany jest sygnał o błędnej pracy układu. Sygnał ten przekazywany jest do układu wyjściowego, który wstrzymuje prace sterownika i ustawia wyjścia w stan bezpieczny. - 7 -
3. Wprowadzenie do realizacji systemów sprzętowo-programowych w układach FPGA W ostatnich latach producenci układów programowalnych kładą duży nacisk na integracje całych systemów w jednym układzie scalonym. Ma to na celu ułatwić projektantom opracowywanie różnorodnych systemów w technologii System-On- Programmable-Chip. Najlepszym tego przykładem jest fakt, że w układach FPGA wbudowywane są już nie tylko pamięci RAM i proste jednostki arytmetyczno-logiczne (ang. arithmetic-logic unit, ALU), ale również mikroprocesory, często bardzo złożone. Aktualnie istnieją dwie metody implementowania procesorów w układach FPGA. Pierwsza polega na osadzeniu na stałe procesora (ang. Hard Core) obok matrycy FPGA w tym samym układzie. Druga metoda polega na zbudowaniu procesora (ang. Soft Core) z osadzonych w układzie FPGA bloków pamięci, jednostek arytmetyczno-logicznych, rejestrów przesuwnych oraz innych wbudowanych peryferii. Wadą tego rozwiązania jest, że zabiera ono zawsze część logiki programowalnej układ FPGA oraz procesory takie są zazwyczaj trochę mniej efektywne niż te wbudowane na stałe. Zaletą natomiast może być fakt, że procesor taki może zostać w pełni skonfigurowany przez użytkownika, co powoduje że jest on mniej złożony i zawiera jedynie niezbędne bloki. Oba rozwiązania wymagają przeprowadzenie złożonej procedury symulacji i testowania. Często nie wystarczające okazuje się oddzielne przesymulowanie części sprzętowej i programu dla mikroprocesora. Spowodowało to, że producenci narzędzi CAD wprowadzili na rynek oprogramowanie umożliwiające przeprowadzenie równoległej ko-weryfikacji części sprzętowej i oprogramowania. 3.1. Układy Virtex-II PRO z procesorem PowerPC Rodzina układów Virtex-II PRO [7] (Tabela 3.1) charakteryzuje się osadzeniem do 4 bloków procesora IBM PowerPC 405 w jednym układzie FPGA. Poza procesorem układy te mają również wbudowane inne urządzenia peryferyjne umożliwiające projektowanie zaawansowanych systemów w technologii System-On- Programmable-Chip. - 8 -
Tabela 3.1. Układy z rodziny Virtex-II PRO Liczba komórek logicznych XC 2VP 2 XC 2VP 4 XC 2VP 7 XC 2VP 20 XC 2VP 30 XC 2VP 40 XC 2VP 50 XC 2VP 70 XC 2VP 100 3168 6768 11088 20880 30816 43632 53136 74448 99216 XC 2VP 125 12513 6 Liczba CLBs 1408 3008 4928 9280 13692 19392 23616 33088 44096 55616 Liczba układów mnożących 12 28 44 88 136 192 232 328 444 556 BRAM (Kb) 216 504 792 1584 2448 3456 4176 5904 7992 10008 Liczba przekaźników Liczba PowerPC 4 4 8 8 8 12 16 20 20 24 0 1 1 2 2 2 2 2 2 4 Matryca FPGA złożona jest z bloków wejścia/wyjścia (ang. Input/Output Block, IOB) oraz konfigurowalnych bloków logicznych (ang. Configurable Logic Block, CLB). Każdy blok wejścia/wyjścia może pracować jako blok wejściowy, blok wyjściowy albo blok dwukierunkowy. Natomiast każda blok logiczny składa się z 2 buforów 3-stanowych oraz 4 identycznych komórek. W skład każdej takiej komórki wchodzą różnego typu układy konfigurowalne, która mogą pracować jako tablice odniesień (ang. Look-up table, LUT), pamięci RAM, rejestry przesuwne, przerzutniki lub zatrzaski, multipleksery oraz układy arytmetyczno-logiczne. Osadzone 32-bitowe procesory PowerPC o architekturze RISC mogą pracować z częstotliwością do 400MHz. Budowa tego procesora, dzięki zastosowaniu osobnych pamięci cache dla danych i rozkazów umożliwia mu wykonywanie jednego rozkazu na cykl. Procesor posiada 4GB przestrzeń adresową zarządzaną przez specjalnie do tego celu przeznaczoną jednostkę zarządzania pamięcią (ang. Memory Management Unit, MMU). Jednostka wykonawcza posiada 32 32-bitowe rejestry ogólnego przeznaczenia oraz jednostkę arytmetyczno-logiczną i jednostkę do wykonywania mnożenia akumulacyjnego (ang. multiply-accumulate, MAC). Dodatkowo procesor posiada 3 zegary przerwań oraz jednostkę pozwalającą na debugowanie poprzez łącze JTAG. W układach z rodziny Virtex-II PRO osadzone są również równoległo-szeregowe i szeregowo-równoległe przekaźniki RocketIO Multi-Gigabit Transceivers, pamięci RAM oraz układy mnożące. Tak rozbudowana architektura układów z rodziny Virtex-II PRO czyni je bardzo dobrymi układami do projektowania zaawansowanych systemów - 9 -
telekomunikacyjnych, sieciowych, audio-video oraz DSP w technologii System-On- Programmable-Chip z wykorzystaniem rdzeni (ang. IP Core). 3.2. Procesor MicroBlaze dla układów Spartan oraz Virtex MicroBlaze [8] jest 32-bitowym procesorem o architekturze RISC, zaprojektowanym jako w pełni konfigurowalny mikroprocesor z możliwością zaimplementowania w układach Spartan i Virtex firmy Xilinx. Procesor ten może pracować z częstotliwością do 150MHz (w zależności od układu w którym zostanie osadzony). Zastosowane architektury Harvard powoduje, że posiada on oddzielne 32-bitowe magistrale dla rozkazów i danych. Magistrale te mogą być wykorzystane zarówno do komunikacji z pamięciami wbudowanymi w układ jak i pamięciami zewnętrznymi. W celu komunikacji z pamięcią BlockRAM wbudowaną w układ dodatkowo wykorzystywana jest lokalna magistrala pamięci (ang. Local Memory Bus, LMB). Procesor posiada 32 32-bitowe rejestry ogólnego przeznaczenia oraz 2 32-bitowe rejestry specjalnego przeznaczenia. Do rejestrów specjalnego przeznaczenia zalicza się licznik programu (PC) i rejestr statusu (MSR). Rejestry ogólnego przeznaczenia w układzie zaimplementowane są z wykorzystaniem tablic odniesień pracujących w trybie pamięci RAM. Procesor może być wyposażony w opcjonalną pamięć cache programu lub danych. Rozmiar tych pamięci może być konfigurowalny od 2KB do 64KB. Procesor poza jednostka arytmetyczno-logiczną, jednostką mnożącą oraz rejestrem przesuwnym wyposażony jest w jednostkę dzielącą, znacznie przyspieszającą wykonywanie działań arytmetycznych oraz w cykliczny rejestr przesuwny (ang. barrel shifter), któremu wykonanie dowolnego przesunięcia zajmuje dwa cykle zegarowe. Procesor ten stanowi alternatywę dla projektantów systemów telekomunikacyjnych, sieciowych, audio-video oraz DSP, którym zależy na redukcji kosztów a nie jest wymagane uzyskanie wysokich częstotliwości działania układu. Należy jednak pamiętać, ze procesor ten nie jest fizycznie osadzony w układzie co powoduje, że jego implementacja zabiera logikę normalnie dostępną projektantowi. Powoduje jednak to również możliwość konfiguracji poszczególnych parametrów procesora i dostosowanie go dokładnie do wymaganych potrzeb. - 10 -
3.3. Układy z rodziny Excalibur Firma Altera opracowała rodzinę układów Excalibur [9] (Tabela 3.2) łącząc w jednym układzie scalonym procesor ARM922T oraz układ FPGA z rodziny Apex 20K. Tabela 3.2 Układy z rodziny Excalibur EPXA1 EPXA4 EPXA10 Liczba bramek logicznych 100K 400K 1M Liczba elementów logicznych (LEs) 4160 16640 38400 Liczba osadzonych bloków systemowych (ESBs) 26 104 160 Liczba bitów pamięci RAM 53248 212992 327680 Maksymalna ilość we/wy FPGA 178 360 521 Wielkość jednoportowej pamięci SRAM (KB) Wielkość dwuportowej pamięci SRAM (KB) 32 128 256 16 64 128 Typ procesora ARM922T ARM922T ARM922T Maksymalna częstotliwość pracy procesora (MHz) 200 200 200 Matryca FPGA zbudowana jest z elementów logicznych (ang. Logic Element, LE) oraz osadzonych bloków systemowych (ang. Embedded System Block, ESB). Element logiczny jest najmniejszą jednostką układów Apex. Każdy taki blok zbudowany jest z 4-wejściowej tablicy odniesień oraz przerzutnika D flip-flop. Dziesięć elementów logicznych tworzy matryce elementów logicznych (ang. Logic Array Block, LAB) między którymi przebiegają magistrale połączeń. Natomiast osadzone bloki systemowe mogą pracować jedynie jako pamięci. W zależności od potrzeb mogą one być skonfigurowane jako synchroniczne dwu- lub jedno- portowe pamięci RAM, ROM, FIFO lub CAM. Procesor ARM922T należy do rodziny ARM9. Jest to 32-bitowy procesor o architekturze RISC zaprojektowany w konwencji Harvard. Posiada on zbiór instrukcji składający się z 32-bitowych instrukcji oraz 16-bitowych instrukcji kluczowych. Skrócenie kodu najczęściej wykorzystywanych instrukcji do 16 bitów powoduje, że kod programu dla tego procesora wykorzystuje mniej pamięci programu. Jest on również wyposażony w jednostkę zarządzania pamięcią umożliwiającą uruchomienie na tym procesorze popularnych systemów operacyjnych oraz dwie 8KB pamięci cache dla danych i rozkazów. - 11 -
Ponadto układ posiada zintegrowany kontroler pamięci SDRAM pozwalający na komunikacje z pamięciami zarówno SDR jak i DDR o rozmiarze do 512KB. Tak więc układy z rodziny Excalibur stanowią kolejną alternatywę dla projektantów systemów przetwarzania danych w technologii System-On-Chip nie przekraczających 1 miliona bramek logicznych. 3.4. Procesor Nios dla układów firmy Altera Procesor Nios [10] jest w pełni konfigurowalnym przez użytkownika 16/32-bitowym procesorem ogólnego przeznaczenia o architekturze RISC. Został on tak zaprojektowany, że może zostać osadzony w dowolnym układzie FPGA firmy Altera oraz zoptymalizowany tak, aby zużywał jak najmniej elementów logicznych. Procesor posiada konfigurowalną jednostkę CPU, która w zależności od potrzeb użytkownika, może zostać skonfigurowana jako 16- lub 32-bitowa. W zależności od typu CPU procesor posiada 16- lub 32-bitowe rejestry ogólnego przeznaczenia, których może być 128, 256 lub 512. 32-bitowy Nios opcjonalnie może być wyposażony w pamięć cache programu lub danych. Pamięć ta budowana jest z bloków dostępnych w układzie FPGA i jej maksymalna wielkość zależy od typu układu w którym będzie implementowany procesor. Posiada on również jednostkę cyklicznego rejestru przesuwnego, która wykonuje wszystkie instrukcje przesunięcia w 2 cyklach zegarowych. Procesor może zostać wyposażony w sprzętową jednostkę wykonująca działanie mnożenia całkowitego. W takiej sytuacji, jednostka ta budowana jest z dostępnych bloków układu FPGA i wykonuje mnożenie w 1 lub 3 cyklach zegarowych, w zależności od tego w jakim układzie implementowany jest procesor. W przypadku gdy procesor nie zostanie wyposażony w taką jednostkę mnożenie wykonywanie jest programowo poprzez jednostkę arytmetyczno-logiczną i rejestr przesuwny. Użytkownik może również przyspieszyć wykonywanie programu, poprzez sprzętowe utworzenie własnych instrukcji. Instrukcje takie, są wtedy realizowane przez jednostkę instrukcji dodatkowych (ang. Custom Instruction Unit, CIU). Rozwiązanie to pozwala na zamknięcie często wykonywanych sekwencji instrukcji w jednej instrukcji i sprzętowej jej realizacji w jednym cyklu zegarowym. - 12 -
Dzięki bardzo rozbudowanej możliwości konfigurowania, procesor ten może znaleźć szerokie zastosowanie praktycznie we wszystkich rodzajach układów cyfrowych, począwszy od sterowników a skończywszy na systemach przeważania danych. 3.5. Układy z rodziny FPSLIC Do rodziny układów FPSLIC [11] wchodzą układy Atmel AT94K i AT94S (Tabela 3.3). Powstały one na bazie popularnych układów FPGA serii AT40K oraz 8-bitowego procesora AVR. Dodatkowo układy serii AT94S zawierają konfigurowalną pamięć z rodziny AT17. Wszystkie układy serii AT94 wykonane są w technologii 0,35µm. Tabela 3.3. Układy serii AT94 AT94x 05AL AT94x 10AL AT94x 40AL Liczba bramek logicznych 5K 10K 40K Liczba bloków logicznych 256 576 2304 Liczba bitów pamięci FPGA SRAM 2048 4096 18432 Liczba przerzutników 436 846 2862 Maksymalna ilość we/wy FPGA 96 144 288 Ilość linii programowych AVR 8 16 16 Liczba bajtów pamięci programu 4 16 K 20 32 K 20 32 K Liczba bajtów pamięci danych 4 16 K 4 16 K 4 16 K Rozmiar pamięci konfigurowalnej (dotyczy tylko układów AT94S xxal) 512 KB 512 KB 1 MB Matryca FPGA zbudowana jest z identycznych bloków logicznych. Sąsiadujące bloki posiadają poziome, pionowe i ukośnie połączenia między sobą. Dodatkowo co cztery bloki przeprowadzone są linie z repeaterami, które przechodzą przez cała matryce FPGA. Na skrzyżowaniach tych linii znajdują się bloki pamięci RAM 32x4. Pamięć ta posiada bardzo szerokie możliwości konfiguracyjne i może pracować zarówno jako jedno- lub dwu-portowa i synchroniczna lub asynchroniczna. Pomiędzy każdymi dwoma komórkami przeprowadzonych jest 5 magistral. Każda taka magistrala posiada jedną linie lokalną i dwie linie ekspresowe. Każda linia lokalna ma zasięg 4 komórek logicznych natomiast linia ekspresowa 8 komórek. Magistrale łączą się miedzy sobą za pomocą repeaterów, umieszczonych co 4 bloki. Każdy blok logiczny ma bezpośrednie połączenia z 8 sąsiednim blokami oraz 5 poziomych i 5 pionowych połączeń z liniami lokalnymi. - 13 -
Każdy blok logiczny składa się z 2 8x1 tablic LUT, 1 przerzutnika D flip-flop oraz zbioru multiplekserów i bramek konfiguracyjnych. Każdy multiplekser oraz każda bramka posiada możliwość niezależnej konfiguracji. Jednocześnie wszystkie kombinacje tych konfiguracji są dopuszczalne w pracy układu, co daje duże możliwości w wyborze trybu pracy bloku logicznego. Osadzony 8-bitowy procesor AVR o architekturze RISC jest zbudowany w konwencji Harvard z oddzielnymi pamięciami i magistralami dla danych i programu. Posiada on 32 rejestry ogólnego przeznaczenia. Wszystkie rejestry posiadają bezpośrednie połączenie z jednostką arytmetyczną co umożliwia jednoczesny dostęp do dwóch rejestrów w trakcie wykonywania jednej instrukcji w jednym cyklu zegarowym. Ponieważ w trakcie wykonywania jednej instrukcji druga już jest pobierana z pamięci, procesor może wykonywać instrukcje w każdym cyklu zegarowy. Procesor ten posiada: 16 linii we/wy ogólnego przeznaczani, licznik czasu rzeczywistego RTC, 3 timery, 2 szeregowe porty asynchroniczne UART. Układy rodziny AT94K posiadają wbudowany interfejs umożliwiający integracje pomiędzy matrycą FPGA a procesorem AVR na jeden z sposobów: Dostęp do współdzielonej 2-portowej pamięci SRAM; Bezpośrednia linia danych; Przerwania procesora AVR generowane przez matryce FPGA; Przeprogramowanie matrycy FPGA poprzez procesor AVR (dynamiczny system rekonfigurowalny). W układzie znajdują się dwa typy pamięci RAM: Wspólna pamięć SRAM dla procesora AVR i układu FPRA oraz pamięci SRAM 32x4 znajdujące się wewnątrz matryce FPGA. W celu ułatwienia projektowania systemów z wykorzystaniem układów serii AT94K firma Atmel opracowała oprogramowanie System Designer. Oprogramowanie to umożliwia symulacje, syntezę oraz implementację kodu w języku VHDL lub Verilog oraz debugowanie programu dla procesora. Jednocześnie oprogramowanie to umożliwia przeprowadzenie ko-symulacji obu tych części. Ze względu na nie duża ilość bramek logicznych w matrycy FPGA oraz zastosowanie prostego 8-bitowego procesora układy te cechują się niską ceną i znajdują szerokie zastosowanie w projektowaniu prostych układów sterujących. - 14 -
3.6. Oprogramowanie Seamless Dużą zaletą powstawania różnego typu układów z wbudowanymi procesorami jest nie tylko możliwość projektowania systemów w technologii SoPC, ale również powstawanie kompleksowego oprogramowania wspomagającego równoległe projektowanie części sprzętowej i programowej systemu cyfrowego. Każdy producent omawianych układów FPGA opracował również zestaw narzędzi, które znacznie przyspieszają proces projektowania systemu z wykorzystaniem tych układów. Jednak prekursorem na rynku oprogramowania wspomagającego równoległe projektowanie sprzętu i oprogramowania jest firma Mentor Graphics, która opracowała narzędzie Seamless [14]. Rozwiązanie to zapewnia synchronizację (Rysunek 3.1) pomiędzy najpopularniejszymi symulatorami języków HDL a emulatorami procesorów umożliwiającymi debugowanie kodu. Emulator procesora (wykonywanie programu) SEAMLESS Symulator języków HDL Synchronizacja Serwer spójnej pamięci Rysunek 3.1. Schemat działania oprogramowania Seamless Poprzez zastosowanie serwera spójnej pamięci (ang. Coherent Memory Server) możliwa jest wymiana danych pomiędzy symulatorem kodu HDL a debugarem oprogramowania. Serwer ten posiada zarówno dostęp do obszaru pamięci, który zaalokował emulator procesora jaki i symulator języka HDL. Do symulowanej części sprzętowej dołączany jest specjalny model symulacyjny emulowanego procesora. Model ten posiada jedynie interfejs danego mikroprocesora oraz rejestry, które mogą ułatwić analizę przeprowadzanej ko-symulacji. Zadaniem serwera spójnej pamięci jest kopiowanie wartości wyjść oraz rejestrów procesora do symulatora sprzętowego oraz pobieranie wartości wejść z symulatora i przekazywanie ich do emulatora. Dodatkowym zadaniem jest synchronizacja czasu symulacji w obu narzędziach. Oprogramowanie Seamless pozwala na emulowanie więcej niż jednego procesora podczas jednej ko-symulacji. - 15 -
4. Sposoby realizacji układów o dwu procesowej architekturze Najbardziej złożonymi modułami w projektowanym sterowniku są procesory master i slave. Procesor slave jest typową jednostką wykonawczą, natomiast procesor master steruje przepływem danych pomiędzy pamięcią kontrolera, wejściami, wyjściami a układem wykonawczym. Dla zwiększenia bezpieczeństwa w omawianej architekturze para takich procesorów została zduplikowana. Najważniejsze jest więc, aby odpowiednio zaprojektować jedną parę tych procesorów. W następnym kroku należy je powielić w celu otrzymania dwóch takich samych par i odpowiednio zaprojektować pozostałe moduły kontrolera tak, aby poprawnie współpracowały z wcześniej zaprojektowanymi procesorami. Odmienna specyfika obu procesorów nakazuje rozważyć wszystkie możliwości ich realizacji z wykorzystaniem układów FPGA jak i mikroprocesorów. W rozdziale tym zostanie ukazana właśnie taka analiza, przedstawione będzie również porównanie tych rozwiązań między sobą. 4.1. Realizacja procesorów z wykorzystaniem dwóch mikroprocesorów Najpopularniejszym znanym sposobem jest zastosowanie dwóch mikroprocesorów [1], gdyż mikroprocesory były znane wcześniej niż układy programowalne FPGA, do zrealizowania modułu master-slave. Pierwszą nasuwającą się wadą takiego rozwiązana jest konieczność realizacji tego system w konwencji SoB (Rysunek 4.1). Wymaga on też programowo-sprzętowego zrealizowania interfejsu wymiany danych pomiędzy oboma procesorami. SoB µp µp Master interfejs wewnętrzny Slave interfejs zewnętrzny Rysunek 4.1. Realizacja procesorów master-slave z wykorzystaniem dwóch mikroprocesorów - 16 -
Problemu natomiast nie powinien stanowić dobór odpowiednich mikroprocesorów. Ze względu na organizacje danych w sterowniku najodpowiedniejszym do tego zastosowania wydaje się 8-bitowy procesor z rodziny 8051. Ponieważ procesor master realizuje program zapisany w specjalnym języku sterownika, niezrozumiałym dla żadnego mikroprocesora, niezbędne jest napisanie specjalnego programu-interpretera. Rozwiązane takie wymaga zatem zastosowanie pamięci dla programu interpretera jaki i programu sterownika (Rysunek 4.2) oraz dla danych obu tych programów. W praktyce program sterownika jest traktowany przez mikroprocesor jako dane programu interpretera, jednak umieszczenie jego w pamięci RAM dla danych nie jest bezpiecznym rozwiązaniem. master DANE µp ROM Program interpreter RAM Dane prog. interpretera ROM Program sterownika RAM Dane i stałe sterownika ADRES Rysunek 4.2. Moduł procesora master zbudowany w oparciu o mikroprocesor Przy takiej budowie modułu mastera mikroprocesor najpierw pobiera ciąg instrukcji programu-interpretera odpowiedzialnych za dokonanie odczytu jednego rozkazu z pamięci programu sterownika. Następnie rozkaz ten jest dekodowany na kod zrozumiały dla danego mikroprocesora i pobierane są dane niezbędne do jego realizacji. Jeden cykl kończy się zapisaniem wyników w pamięci danych sterownika. Realizacja każdego z tych etapów wiąże się pobraniem przynajmniej jednej instrukcji programu interpretera. Jak można zauważyć w celu wykonania jednej instrukcji sterownika mikroprocesor musi wykonać kilkanaście odwołań do różnych pamięci. Sytuacja taka powoduje, że wykonanie takiej instrukcji jest bardzo czasochłonne. Jednocześnie nie jest ona pożądana z punktu widzenia bezpieczeństwa działania układu, gdyż częsta komunikacja z układami zewnętrznymi (pamięci) jest bardziej narażona na zakłócenia. - 17 -
Realizacja procesora slave w takim rozwiązaniu jest dużo prostsze. Ponieważ procesor ten nie realizuje żadnego programu, a jedynie wykonuje algorytmy zapisane w postaci bloków funkcyjnych, należy napisać jedynie program w języku wybranego mikroprocesora. Program taki powinien posiadać interfejs do komunikacji z otoczeniem oraz zbiór funkcji realizujących wymagane bloki funkcyjne. Po otrzymaniu numeru funkcji i danych z procesora master, slave wykonałby odpowiednią funkcje na otrzymanych danych i zwrócił wynik do mastera. Kluczową wadą takiego rozwiązania jest więc realizacja procesora master, która wymaga wykonywania przez mikroprocesor kodu programu-interpretera, co powoduje zbyt częste odwołania do pamięci. 4.2. Realizacja modułu master-slave z wykorzystaniem struktur programowalnych FPGA Drugim sposobem realizacji [3] jest opisanie obu procesorów w językach opisu sprzętu i implementacja ich do struktury programowalnej FPGA. W zależności od wielkości wybranego układu FPGA oba procesory mogą być osadzone w jednym układzie scalonym (SoC) lub w dwóch układach scalonych (Rysunek 4.3). W drugim przypadku wymagane oczywiście jest zaprojektowanie płytki drukowanej (SoB). Oba rozwiązana wymagają zaprojektowania sprzętowego interfejsu komunikacyjnego. Dużą zaletą takiego rozwiązania jest możliwość zaprojektowania procesora master tak, aby było on procesorem dedykowanym do wykonywania instrukcji kontrolera. Powoduje to, że ilość odwołań do pamięci zostanie znacznie zredukowana w stosunku do poprzedniego rozwiązania, ponieważ procesor taki dokonuje jednego odwołania do pamięci w celu odczytu rozkazu i po jednym odwołaniu w celu odczytu lub zapisu słowa danych. Ponieważ procesor ten jest dedykowany jedynie do wykonywania instrukcji sterownika może zostać on zoptymalizowany pod kątem prędkości ich wykonywania. Zauważalna więc jest znaczna przewaga realizacji mastera z wykorzystaniem struktur programowalnych FPGA nad realizacją z wykorzystaniem mikroprocesora. Procesor slave natomiast, realizujący bloki funkcyjne, wymaga zaprojektowania automatu, który będzie pobierał dane i przekazywał je do odpowiednich bloków funkcyjnych. Rozwiązanie takie wymusza sprzętową realizację każdego bloku funkcyjnego. W przypadku gdy - 18 -
procesor musi zostać wyposażony w znaczną ilość bloków funkcyjnych okazuje się, że zajmują one znaczną cześć struktury układu FPGA. Jednocześnie w sytuacji, gdy w danym momencie wykonywany jest tylko jedne blok funkcyjny nasuwa się pytanie, czy ponoszenie takiego kosztu jest sensowne i czy nie lepszym rozwiązaniem jest zastosowanie mikroprocesora, który posiada jedną jednostkę przetwarzającą a wszystkie bloki funkcyjne zapisane są w postaci programu. Za sprzętową realizacją procesora slave może jedynie przemawiać chęć realizacji pary procesorów w technologii SoC. SoB FPGA FPGA Master interfejs wewnętrzny Slave interfejs zewnętrzny a) z wykorzystaniem dwóch układów FPGA SoC FPGA Master interfejs wewnętrzny Slave interfejs zewnętrzny b) z wykorzystaniem jednego układów FPGA Rysunek 4.3. Realizacja modułu master-slave z wykorzystaniem układów FPGA 4.3. Realizacja procesorów w konwencji FPGA - mikroprocesor Analizując poprzednie dwa rozdziały można zauważyć, że najkorzystniejsze byłoby zrealizowanie procesora master jako dedykowany układ w strukturze FPGA natomiast procesora slave z wykorzystaniem mikroprocesora (Rysunek 4.4). Rozwiązanie takie jest bardzo korzystne gdyż opiera się na dedykowanym - 19 -
procesorze master, który szybko realizuje swój algorytm a jednocześnie bloki funkcyjne procesora slave nie zajmują logiki układu FPGA, ponieważ są realizowane programowo przez mikroprocesor. Wadą takiego rozwiązania może być jedynie konieczność realizacji w technologii SoB oraz utrudniony sposób testowania projektowanego systemu [4]. SoB FPGA µp Master interfejs wewnętrzny Slave interfejs zewnętrzny Rysunek 4.4. Realizacja procesorów w konwencji FPGA-mikroprocesor Korzystnym rozwiązaniem może się okazać zastosowani, ostatnio ukazujących się na rynku, układów programowalnych z wbudowanym mikroprocesorem (charakterystyka wybranych układów jest przedstawiona w rozdziale 3). Rozwiązanie takie umożliwiało by wykonanie pary procesorów w technologii SoPC (Rysunek 4.5). SoPC FPGA Master osadzony µp wbudowany interfejs wewnętrzny Slave interfejs zewnętrzny Rysunek 4.5. Realizacja układu master-slave z wykorzystaniem układu programowalnego z wbudowanym mikroprocesorem - 20 -
Dodatkową zaletą tego rozwiązania jest fakt iż układy takie często posiadają wbudowany interfejs do komunikacji pomiędzy procesorem a blokami umieszczonymi w strukturze FPGA. Producenci tych układów również zadbali o projektantów opracowując dedykowane środowiska projektowe umożliwiające programową ko-weryfikacje obu części. Sposób realizacji sterownika z wykorzystaniem takiego typu układu został opisany w rozdziale 5. - 21 -
5. Realizacja i testowanie kontrolera Kontroler o podwyższonym stopniu bezpieczeństwa został zaprojektowany tak, aby mógł być wykonany z wykorzystaniem układów programowalnych z wbudowanymi mikroprocesorami. Do realizacji przykładowej architektury sterownika, bazując na opisie przedstawionym w rozdziale 2, zdecydowano się zastosować układ firmy Atmel z rodziny AT94K. Moduły sterownika, które mają zostać zaimplementowane w strukturach FPGA zostały opisane w języku opisu sprzętu Verilog [6]. Natomiast w celu realizacji części, która ma być realizowana przez mikroprocesor, napisano program w języku asembler [12] dla mikroprocesora AVR [13]. Na podstawie analizy przeprowadzonej w rozdziale 4 założono, że program ten będzie realizował algorytm procesora slave. Wszystkie pozostałe moduły, łącznie z procesorem master, zostaną opisane w języku opisu sprzętu a następnie zaimplementowane w strukturze FPGA. Ponieważ w przypadku awarii układu scalonego, zakłada się, że wszystkie znajdujące się w nim moduły działają niepoprawnie dokonano również dekompozycji sterownika na kilka układów scalonych. Podczas podziału modułów pomiędzy poszczególne układy scalone zwrócono przede wszystkim uwagę na to, aby w przypadku awarii jednego układu scalonego moduły znajdujące się w pozostałych układach wykryły tą awarię. Kierując się tym kryterium moduły kontrolera podzielono pomiędzy 3 układy scalone (Rysunek 5.1). Układy U1 i U2 zawierają dokładnie te same moduły: procesor master i slave oraz moduł sterujący przepływem danych. Mogą one różnić się jedynie numerami wyprowadzeń, na których zostaną umieszczone poszczególne sygnały. Rozwiązanie takie może ułatwić projektowanie płytki drukowanej, na której zostaną umieszczone moduły kontrolera. Układ U3 zawiera pozostałe części kontrolera: układ wejściowy i wyjściowy oraz komparatory i zatrzaski. W prezentowanej architekturze do realizacji układów U1 i U2 zastosowano układy z rodziny FPSLIC AT94K firmy Atmel. Rozwiązanie takie zostało wymuszone poprzez zastosowanie mikroprocesora AVR do realizacji procesora slave oraz specyficznego protokołu wymiany danych pomiędzy procesorami master-slave opartego na interfejsach znajdujących się w tym układzie. Jednak gdy sterownik realizowany jest w innej konwencji, niż obrana, mogą zostać wykorzystane dowolne inne układy programowalne. Natomiast do zrealizowania - 22 -
układu U3, nie zależnie od sposobu realizacji, może zostać wykorzystany dowolny układ FPGA. U1 - FPSLIC U2 - FPSLIC Master A Master B Jednostka sterująca przepływem danych A Jednostka sterująca przepływem danych B Slave A Slave B U3 - FPGA Układ wejściowy Komparatory Rejestr Rejestr Układ wyjściowy BI BImulti OK BO Rysunek 5.1. Podział kontrolera na układy scalone 5.1. Sposób realizacji Do realizacji przedstawionej architektury sterownika zostały wykorzystane różnego rodzaju narzędzia CAD wspomagające projektowanie układów cyfrowych: Narzędzia do projektowania i symulacji języków HDL: Aldec Active-HDL 5.2, Model Technology ModelSim SE 5.6b. Narzędzia do syntezy i implementacji: Synplicity Synplify Pro 7.0, Mentor Graphics LeonardoSpectrum v. 2001, Xilinx Foundation ISE 5.1, Atmel Figaro ids7.6.7. - 23 -
Narzędzia do symulacji programu procesora AVR: Atmel AVR Studio 4 (z pakietu System Designer 3.0). Narzędzia do ko-weryfikacji: Atmel System Designer 3.0. Jednym z ważniejszych zadań, które należało wykonać podczas realizacji projektu kontrolera była symulacja i weryfikacja modułów układu. W pierwszym etapie, symulacji poddano każdy z komponentów z osobna. Dotyczy to zarówno części sprzętowej jak i programowej. Następnie po zweryfikowaniu pojedynczych modułów symulacji poddano część sprzętową. Ostatnią fazą testowania było przeprowadzenie jednoczesnej ko-werfikacji sprzętu i oprogramowania. Po pozytywnym zweryfikowaniu działania układu, sterownik został poddany syntezie i implementacji. Następnie powtórzono proces testowania wykorzystując modele do symulacji czasowej wygenerowane w procesie implementacji. 5.2. Opracowanie protokołu komunikacyjnego Po dokonaniu podziału zadań pomiędzy część sprzętową a programową, oraz wybraniu układu scalonego, w którym będą implementowane moduły kontrolera, a przed przystąpieniem do ich realizacji, opracowano sposób komunikacji pomiędzy częścią sprzętową a częścią programową. W przypadku realizacji sterownika dotyczy to komunikacji jednostki sterującej przepływem danych z procesorem slave oraz procesora slave z układem wejściowym oraz układem wyjściowym. Do realizacji przepływu danych pomiędzy jednostką sterującą a procesorem slave zdecydowano się na wykorzystanie wbudowanej do układów z rodziny FPSLIC, dwu-portowej pamięci SRAM oraz systemu przerwań wewnętrznych mikroprocesora AVR (Rysunek 5.2). IOSELA0 INT Jednostka sterująca przepływem danych (FPGA) Adres WE CLK Dane Dane SRAM Adres WE RE CLK Dane Slave (AVR) Rysunek 5.2. Interfejs komunikacyjny pomiędzy jednostką sterująca a procesorem slave - 24 -
Jednostka sterująca przepływem danych po otrzymaniu identyfikatora funkcji oraz argumentów bloku funkcyjnego zapisuje je w odpowiednich blokach pamięci SRAM (Rysunek 5.3) a następnie generuje przerwanie dla procesora. Procesor po otrzymaniu przerwania dokonuje obliczeń (realizacji odpowiedniego bloku funkcyjnego) a wyniki zapisuje w pamięci SRAM. Zakończenie obliczeń sygnalizowane jest ustawieniem linii IOSELA0. 0FFF 028D 028C SRAM nie używane informacje o ilości we/wy 0091 bloków funkcyjnych 0090 wyjścia 008F nie używane 008E 008D argumenty i wyniki 0062 0061 kopia identyfikatora funkcji 0060 identyfikator funkcji Rysunek 5.3. Mapa pamięci SRAM Na argumenty bloku funkcyjnego i wynik przez niego obliczone zarezerwowano w pamięci 44 słowa. Ilość ta jest całkowicie wystarczająca ponieważ każdy blok funkcyjny może mieć maksymalnie 4 wejścia oraz 1 wyjście. Przyjęto, że może on posiadać jednocześnie maksymalnie 3 stany wewnętrzne, których wartości również muszą być przekazane do, a następnie odebrane z, procesora slave. Powoduje to, że maksymalnie może być przesyłanych 7 argumentów do bloku funkcyjnego a odbieranych 4. Wymagany jest więc obszar dla 11 zmiennych w pamięci. Ponieważ każda zmienna może mieć maksymalnie 4 słowa daje to 44 słowa na jeden blok funkcyjny. W obszarze informacyjnym o blokach funkcyjnych zapisane jest ile słów podawane jest na wejścia danego bloku oraz ile słów odczytane powinno zostać z wyjść danego bloku funkcyjnego. Informacje te są niezbędne dla jednostki kontrolującej przepływ danych i wykorzystywane są do wyliczenia kiedy ma zostać - 25 -
wygenerowane przerwanie dla procesora slave oraz poprawnego odebrania wszystkich wyników. Zdecydowano się na przechowywanie ilości słów a nie ilości zmiennych ponieważ jednostka sterująca przepływem danych przesyła słowa i nie rozróżnia typów danych. Dla jednostki tej przesłanie jednej zmiennej typu int (1 2 słowa) odbywa się w ten sam sposób co przesłanie dwóch zmiennych typu bool (2 1 słowo). W obszarze tym zarezerwowano 508 słów na opis bloków funkcyjnych. Na każdy blok funkcyjny przydzielono 2 słowa: pierwsze informuje o ilości słów wejściowych, natomiast drugie o ilości słów wyjściowych. Ponieważ numery bloków funkcyjnych zawierają się miedzy wartościami 1 (01h) a 254 (FEh) do tego celu wystarczy 508 słow. Pola te są wypełniane przez program mikroprocesora AVR w trakcie restartu układu. Rozwiązanie takie zapewnia, że zmiana (dodanie lub usunięcie) bloków funkcyjnych spowoduje jedynie konieczność wymiany programu dla procesora AVR (modyfikacja funkcji realizującej bloki funkcyjne oraz fragmentu funkcji obsługującej przerwanie zerowania, odpowiedzialnego za wypełnienie bloku informacyjnego) a część sprzętowa sterownika będzie dalej działała poprawnie. Ponieważ układ wejściowy będzie znajdował się w innym układzie scalonym niż procesor slave do celów komunikacji pomiędzy tymi układami zdecydowano się wykorzystać zewnętrzne porty D i E mikroprocesora AVR. Port D, pracujący w trybie wyjścia, będzie wykorzystywany jako linia adresowa (bity od 0 do 5) do adresowania wejścia sterownika, które ma zostać odczytane, oraz jako sygnał poprawności pracy OK procesora slave (bit 6). Natomiast port E, pracujący w trybie wejścia, będzie służył jako linia danych po której układ wejściowy będzie przesyłał wartości poszczególnych wejść do procesora slave. W pierwszym podejściu do komunikacji z układem wejściowym chciano wykorzystać jedynie port D pracujący w trybie dwukierunkowym a port E maił zostać wykorzystany do przesłania wartości wyjścia sterownika do układu wyjściowego. Rozwiązanie takie jednak nie mogło się powieść z powodu braku linii dla sygnału prawności OK oraz dla sygnałów sterujących linią dwukierunkową. Dlatego zdecydowano się wykorzystać oba porty do komunikacji z blokiem wyjściowym a wartość wyjścia zapisywana jest w pamięci SRAM i przekazywana do bloku wyjściowego przez jednostkę sterującą przepływem danych. - 26 -