REALIZACJA KONTROLERÓW

Transkrypt

1 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

2

3 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 -

4 Spis treści Spis rysunków... iv Spis tabel... v 1. Wstęp Cel pracy Struktura pracy Koncepcja architektury sterownika bezpiecznego Procesor master Procesor slave Układ wejściowy Układ wyjściowy Jednostka sterująca przepływem danych Wprowadzenie do realizacji systemów sprzętowo-programowych w układach FPGA Układy Virtex-II PRO z procesorem PowerPC Procesor MicroBlaze dla układów Spartan oraz Virtex Układy z rodziny Excalibur Procesor Nios dla układów firmy Altera Układy z rodziny FPSLIC Oprogramowanie Seamless Sposoby realizacji układów o dwu procesowej architekturze Realizacja procesorów z wykorzystaniem dwóch mikroprocesorów Realizacja modułu master-slave z wykorzystaniem struktur programowalnych FPGA Realizacja procesorów w konwencji FPGA - mikroprocesor Realizacja i testowanie kontrolera Sposób realizacji Opracowanie protokołu komunikacyjnego Realizacja procesora slave Realizacja części sprzętowej Realizacja jednostki kontrolującej przepływ danych Synteza i implementacja jednostki kontrolującej przepływ danych Symulacja jednostki kontrolującej przepływ danych Implementacja części sprzętowej kontrolera Procedura testowa kontrolera Alternatywne sposoby realizacji sterownika bezpiecznego Podsumowanie ii -

5 Literatura Dodatek A. Lista rozkazów sterownika Dodatek B. Mapa pamięci sterownika Dodatek C. Struktura projektu Dodatek D. Struktura płyty CD-ROM iii -

6 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 Rysunek 4.1. Realizacja procesorów master-slave z wykorzystaniem dwóch mikroprocesorów Rysunek 4.2. Moduł procesora master zbudowany w oparciu o mikroprocesor Rysunek 4.3. Realizacja modułu master-slave z wykorzystaniem układów FPGA Rysunek 4.4. Realizacja procesorów w konwencji FPGA-mikroprocesor Rysunek 4.5. Realizacja układu master-slave z wykorzystaniem układu programowalnego z wbudowanym mikroprocesorem Rysunek 5.1. Podział kontrolera na układy scalone Rysunek 5.2. Interfejs komunikacyjny pomiędzy jednostką sterująca a procesorem slave Rysunek 5.3. Mapa pamięci SRAM Rysunek 5.4. Algorytm działania procesora slave Rysunek 5.5. Schemat bloku obsługującego przerwanie Rysunek 5.6. Realizacja blok funkcyjnego IN_M_CHR Rysunek 5.7. Realizacja blok funkcyjnego ADD_INT Rysunek 5.8. Realizacja blok funkcyjnego DFF_CHR Rysunek 5.9. Realizacja bloku funkcyjnego IN_M_CHR w procesorze slave Rysunek Interfejs jednostki sterującej przepływem danych Rysunek Algorytm działania jednostki sterującej przepływem danych Rysunek Symulacja układu sterującego przepływem danych Rysunek Schemat blokowy programu kontrolera Rysunek Przebieg czasowy symulacji kontrolera Rysunek Analiza symulacji sterownika z wykorzystaniem Code Coverage Rysunek Architektura kontrolera o trzech parach procesorów master-slave Rysunek A.1. Struktura rozkazów sterownika Rysunek B.1. Mapa pamięci procesora master Rysunek C.1. Struktura projektu iv -

7 Spis tabel Tabela 3.1. Układy z rodziny Virtex-II PRO... 9 Tabela 3.2 Układy z rodziny Excalibur Tabela 3.3. Układy serii AT Tabela 5.1. Bloki funkcyjne zaimplementowane w kontrolerze Tabela 5.2. Zajętość jednostki sterującej w strukturze FPGA Tabela 5.3. Zajętość kontrolera w strukturach FPGA Tabela A.1. Lista rozkazów sterownika v -

8 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

9 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 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

10 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 -

11 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) 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 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 -

12 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 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 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 -

13 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 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 -

14 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 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

15 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 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

16 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 XC 2VP Liczba CLBs Liczba układów mnożących BRAM (Kb) Liczba przekaźników Liczba PowerPC 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 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 -

17 telekomunikacyjnych, sieciowych, audio-video oraz DSP w technologii System-On- Programmable-Chip z wykorzystaniem rdzeni (ang. IP Core) 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 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

18 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) Liczba osadzonych bloków systemowych (ESBs) Liczba bitów pamięci RAM Maksymalna ilość we/wy FPGA Wielkość jednoportowej pamięci SRAM (KB) Wielkość dwuportowej pamięci SRAM (KB) Typ procesora ARM922T ARM922T ARM922T Maksymalna częstotliwość pracy procesora (MHz) 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

19 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 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 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

20 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 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 Liczba bitów pamięci FPGA SRAM Liczba przerzutników Maksymalna ilość we/wy FPGA Ilość linii programowych AVR Liczba bajtów pamięci programu 4 16 K K 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

21 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

22 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

23 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ą 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

24 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 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

25 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 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

26 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

27 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

28 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

29 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

30 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 ids

31 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 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

32 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 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ć

33 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