Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Systemów Elektronicznych IEVGENII DROZDOV 255353 Praca Magisterska OPTYMALIZACJA KOMUNIKACJI PRZEZ INTERFEJS SZEREGOWY Z BLOKAMI FUNKCJONALNYMI ZREALIZOWANYMI W UKŁADACH FPGA Praca wykonana pod kierunkiem: dra inż. Wojciecha Zabołotnego Warszawa, 2015
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Instytut Systemów Elektronicznych
IEVGENII DROZDOV255353
Praca Magisterska
OPTYMALIZACJA KOMUNIKACJI PRZEZ
INTERFEJS SZEREGOWY Z BLOKAMI
FUNKCJONALNYMI ZREALIZOWANYMI
W UKŁADACH FPGA
Praca wykonana pod kierunkiem:
dra inż. Wojciecha Zabołotnego
Warszawa, 2015
OPTYMALIZACJA KOMUNIKACJI PRZEZ INTERFEJS SZEREGOWY Z
BLOKAMI FUNKCJONALNYMI ZREALIZOWANYMI W UKŁADACH FPGA
Praca obejmuje opracowanie metody i implementację modułu opisanego w języku
VHDL służącego do optymalizacji komunikacji przez interfejs szeregowy z blokami
funkcjonalnymi zrealizowanymi w układach FPGA. Dodatkowo opisane są testy układu
przeprowadzone z pomocą symulatora oraz w sprzęcie.
Słowa kluczowe: SoC, VHDL, UART, Wishbone, Magistrala, Interfejs, Transmisja,
Szybkość, Scatter-gather.
OPTIMIZATION OF THE COMMUNICATION VIA SERIAL INTERFACE
WITH FUNCTIONAL BLOCKS THAT ARE IMPLEMENTED IN FPGA
DEVICES
This thesis covers a description of the method and implementation of the module
described in VHDL language for optimization of communication via serial interface
with functional blocks that are implemented in FPGA devices. Additionally it contains a
description of the tests performed with the help of simulator and in hardware.
Urodziłem się 25 stycznia 1991 roku w Kijowie, gdzie
mieszkałem potem przez dwadzieścia lat. Tam też w latach
2004 – 2008 uczęszczałem do liceum „Intelekt” w klasie o
profilu matematyczno-fizycznym.
W roku 2008 rozpocząłem studia na Wydziale
Elektroniki Politechniki Kijowskiej. Po czwartym roku
studiów obroniłem pracę inżynierską zatytułowaną
„Implementacja urządzenia zdalnego sterowania systemem
Inteligentny Dom” z wyróżnieniem.
W roku 2012 rozpocząłem studia na Wydziale Elektroniki i Technik
Informacyjnych Politechniki Warszawskiej.
Jestem współautorem publikacji „Tworzenie interfejsu wymiany danych
pomiędzy dwoma procesami symulatora języka Verilog”, Kijów 2012.
W marcu 2014 roku rozpocząłem pracę w firmie Cadence Design Systems.
Zajmuję się implementacją środowisk weryfikacyjnych oraz architektur IP-Core.
Pragnę serdecznie podziękować
promotorowi, Panu doktorowi Wojciechowi
Zabołotnemu za wsparcie w ciągu całych moich
studiów w Polsce.
Jednocześnie składam serdeczne
podziękowania Tomaszowi Wojciechowskiemu
za pomoc w trakcie redagowania pracy
dyplomowej.
Spis treści
1. Akronimy i spis oznaczeń............................................................................................92. Wstęp...........................................................................................................................113. Przegląd zagadnienia.................................................................................................13
3.1. Opis problemu......................................................................................................133.2. Studia literaturowe...............................................................................................14
3.2.1. Analiza sekwencji programowych...............................................................143.2.2. USB 3.0 Command Ring..............................................................................17
3.3. Opis rozwiązania..................................................................................................214. Implementacja rozwiązania......................................................................................25
4.1. Wybór interfejsów................................................................................................254.2. Model sprzętowy..................................................................................................26
5. Testowanie z portem UART......................................................................................375.1. Opis systemu testowego.......................................................................................375.2. Obliczenia teoretyczne.........................................................................................385.3. Porównanie wyników...........................................................................................40
6. Testowanie z portem Ethernet..................................................................................456.1. Opis systemu testowego.......................................................................................456.2. Obliczenia teoretyczne.........................................................................................486.3. Porównanie wyników...........................................................................................49
7. Kierunki dalszych prac.............................................................................................538. Podsumowanie...........................................................................................................559. Bibliografia.................................................................................................................57Aneks A. Opis portów modułu UCS.............................................................................59
Aneks B. God Mode.......................................................................................................63Aneks C. Interfejs programowy UCS..........................................................................65
CS z adresem bazowym CS7.CSA7). Pobieranie komend zaczyna się od adresu
bazowego zestawu deskryptorów CS do deskryptora CCU (ostatni adres każdego CS) i
Strona 30
powtarza się COUNT razy (w deskryptorach CCU COUNT – konkatenacja pól
COUNT1 i COUNT0).
Jeśli kilka flag DOORBELL jest jednocześnie ustawionych to przetwarzanie
zaczyna się od młodszej do starszej flagi.
W celu odczytania danych zebranych w Pamięci danych podczas przetwarzania
deskryptora CU z bitem OPTIONS.RW równym „0” w deskryptorze (komenda
odczytu) wykorzystuje się rejestr DMD. Dane są odczytywane po kolei po 8 bitów
zaczynając od pierwszych odebranych (kolejka FIFO). Dane muszą być odczytane
zanim zostanie ustawiona flaga FLAGS.DF, ponieważ moduł UCS będzie wstrzymany
przed następną komendą odczytu (kolejka FIFO jest pełna). Aby zignorować flagę
FLAGS.DF musi być ustawiona flaga FLAGS.DO, w tym przypadku stare dane zostaną
pominięte i będą zastąpione nowymi (stosuje się w systemach czasu rzeczywistego).
4.3.3. Zakończenie przetwarzania
Przetwarzanie kończy się, kiedy każdy zestaw deskryptorów CS zostanie
wykonany COUNT razy (w deskryptorach CCU COUNT – konkatenacja pól COUNT1
i COUNT0).
Strona 31
Rysunek 4-4: Przykład uruchamiania przetwarzania zestawów deskryptorów CS
Kiedy przetwarzanie zestawu CS jest zakończone, odpowiednia flaga
DOORBELL zostaje ustawiona na „0” przez sprzęt.
Przetwarzanie wszystkich zestawów CS jest zakończone, kiedy wszystkie flagi
DOORBELL są ustawione na „0”.
4.4. Weryfikacja funkcjonalna
Weryfikacja funkcjonalna modułu UCS została przeprowadzona w środowisku
weryfikacyjnym w języku VHDL z pomocą techniki zaproponowanej przez organizacją
Synthworks w [12]. Do tworzenia wirtualnych interfejsów dla pobudzenia portów
modułu UCS zostały wykorzystane bufory trójstanowe.
Głównym kryterium dla implementacji środowiska było pokrycie jak największej
części funkcjonalności modułu UCS.
W Tablicy 4-1 jest pokazane 12 testów, które sprawdzają poprawność działania
modułu UCS.
Tablica 4-1: Testy modułu UCS w środowisku weryfikacyjnym
Nazwa testu Opis
rw_reg_testSprawdzenie poprawności zapisu i odczytu z rejestrów typu RW.
illegal_reg_testSprawdzenie odczytu wartości 0000_0000b z rejestrów z nieprawidłowym adresem (powyżej Eh).
rst_reg_testSprawdzenie wartości wszystkich rejestrów w Zestawie rejestrów po resecie.
rw_cmd_test
Sprawdzenie zapisu i odczytu deskryptorów CU z Pamięci komend oraz sprawdzenie zapisu i odczytu deskryptorów z nieprawidłowych adresów (powyżej 20h). Po odczycie deskryptora CU z nieprawidłowych adresów musi być zwrócony deskryptor z ustalonym polem OPTIONS.VALID na „0”.
fetch_cmd_test
Sprawdzenie poprawności działania mechanizmu przetwarzania zestawów deskryptorów CS, cyklu zapisu/odczytu na Interfejsie Wishbone Master oraz przetwarzania deskryptorów CCU na końcu każdego zaestawu CS.
Strona 32
Nazwa testu Opis
fetch_cmd_count_test
Sprawdzenie poprawności działania mechanizmu przetwarzania zestawów deskryptorów CS, cyklu zapisu/odczytu na Interfejsie Wishbone Master w przypadkucyklicznego powtarzania działania z pomocą licznika w deskryptorze CCU (konkatenacja CCU.COUNT1 i CCU.COUNT0).
overload_cmd_test
Sprawdzenie poprawności działania mechanizmu przetwarzania zestawów deskryptorów CS, cyklu zapisu/odczytu na Interfejsie Wishbone Master bez deskryptora CCU na końcu zestawu CS. W tym przypadku moduł UCS musi zostać zatrzymany przy wyjściu poza zakres adresowy Pamięci komend (pole OPTIONS.VALID deskryptora CU ustawione na „0”).
rw_datmem_testSprawdzenie poprawności zapisu/odczytu danych z Pamięcidanych przy przetwarzaniu deskryptora CU z polem OPTIONS.RW ustawionym na „0” (komenda odczytu).
overflow_datmem_testSprawdzenie zatrzymania modułu UCS przy wypełnieniu Pamięci danych przy fladze FLAGS.DO ustawionej na „0” (nadpisywanie danych zabronione).
overwrite_datmem_testSprawdzenie mechanizmu nadpisywania starych danych przy wypełnieniu Pamięci danych przy fladze FLAGS.DO ustawionej na „1” (nadpisywanie danych aktywowane).
gm_path_testSprawdzenie poprawności przejścia sygnałów z Interfejsu Wishbone Slave do Wishbone Master w trybie God Mode (flaga FLAGS.GM ustawiona na „1”).
gm_off_testSprawdzenie mechanizmu wyłączenia trybu God Mode przez Interfejs WSGM.
Strona 33
Na Rysunku 4-5 jest pokazane środowisko weryfikacyjne oraz połączenia testów
do interfejsów modułu UCS.
Po przeprowadzeniu testowania modułu UCS za pomocą wszystkich testów
wymienionych powyżej zostały wyeliminowane błędy generowane przez asercje oraz
warunki poprawności.
Strona 34
Rysunek 4-5: Schemat blokowy środowiska weryfikacyjnego
4.5. Synteza
Synteza układu została przeprowadzona za pomocą narzędzia Xilinx ISE 14.7 dla
układów FPGA Spartan-3AN oraz Spartan-6. Synteza zakończyła się bez błędów, jej
wyniki przedstawione są w Tablicach 4-2 i 4-3.
Tablica 4-2: Zużycie zasobów w układzie FPGA Spartan-3AN
Zasoby FPGA Liczba Zużycie
Slice Reg 1024 8,7 %
LUT 1436 12,2 %
Slice 1168 19,8 %
BRAM 1 5 %
Tablica 4-3: Zużycie zasobów w układzie FPGA Spartan-6
Zasoby FPGA Liczba Zużycie
Slice Reg 976 1,8 %
LUT 820 3 %
Slice 455 6,7 %
BRAM 1 0,4 %
W Tablicach 4-2 i 4-3:
• Slice Reg – logika sekwencyjna w układzie FPGA (przerzutniki).
• Look-Up Table (LUT) – logika kombinacyjna w układzie FPGA.
• Slice – bloki zawierające w sobie rejestry Slice Reg oraz logikę LUT.
• Block Random Access Memory (BRAM) – blok pamięci w układzie FPGA.
Strona 35
Strona 36
5. Testowanie z portem UART
5.1. Opis systemu testowego
Na Rysunku 5-1 jest pokazany system testowy. System był syntezowany na płycie
Spartan-3AN Starter Kit.
System testowy ma na celu sprawdzenie działania modułu UCS przy sterowaniu
systemu przez magistralę szeregową wolniejszą od zegara systemowego.
Opis systemu testowego z portem UART:
• Częstotliwość zegara systemowego – 50 MHz.
Strona 37
Rysunek 5-1: Układ testowy wykorzystujący port UART
• Dwa moduły slave GPIO z 8-bitowymi rejestrami podłączone do czterech diod
LED każdy.
• Moduł Wishbone Interconnect z dekoderem adresu dla maksymalnie czterech
modułów slave. Mapa adresowa jest pokazana w Tablicy 5-1. Struktura modułu
Wishbone Interconnect jest opisana w [11].
• Moduł UCS jako jedyny master w systemie.
• Sterownik UART dostępny w [13] z otwartą licencją. Szybkość transmisji –
115200 (bit/s).
Tablica 5-1: Mapa adresowa w systemie testowym
Moduł Slave Adres
GPIO0 00h – 01h
GPIO1 10h – 11h
UCS (interfejs WSGM) 30h
Program sterujący został napisany w środowisku Matlab i uruchomiony w
systemie operacyjnym Linux.
Inicjalizacja systemu składa się z następujących etapów:
1. Przeprowadzenie modułu UCS w tryb God Mode.
2. Ustawienie portów kontrolera GPIO w tryb wyjściowy (zapis wartości 00h do
narastająceZegar główny modułu UCS, wyzwala wszystkie podbloki.
Aneks A.2. Porty Interfejsu Wishbone Slave
W module UCS jest zaimplementowana minimalna konfiguracja Interfejsu
Wishbone Slave, która jest pokazana w Tablicy A-2.
Tablicа A-2: Porty Interfejsu Wishbone Slave [11]
Nazwaportu
KierunekDługość(bitów)
Stanaktywny
Opis
adr_i_s wejście 8 wysokiWejściowy port adresu służy do przekazywania adresu binarnego rejestru w Zestawie rejestrów.
dat_i_s wejście 8 wysokiWejściowy port danych używany do przekazywania danych binarnych z rejestru w Zestawie rejestrów.
dat_o_s wyjście 8 wysoki
Wyjściowy port danych służy do przekazywania danych binarnych, które muszą być zapisane do rejestruw Zestawie rejestrów.
we_i_s wejście 1 wysoki
Wskazuje na typ cyklu obecny na magistrali. Sygnał jest ustawiony na „1” podczas cyklu zapisu lub na „0” podczas cyklu odczytu.
stb_i_s wejście 1 wysokiWskazuje na to, że moduł UCS jest wybrany dla operacji na magistrali.
ack_o_s wyjście 1 wysokiSygnał wyjściowy ustawiony na „1” oznacza zakończenie cyklu na magistrali.
Strona 59
Nazwaportu
KierunekDługość(bitów)
Stanaktywny
Opis
cyc_i_s wejście 1 wysoki
Sygnał ustawiony na „1” wskazuje, że na magistrali wykonuje się ważnycykl. Sygnał jest ustawiony na „1” podczas wszystkich cykli na magistrali od pierwszej transmisji danych do ostatniej.
Aneks A.3. Porty Interfejsu Wishbone Master
W module UCS jest zaimplementowana minimalna konfiguracja Interfejsu
Wishbone Master która jest pokazana w Tablicy A-3.
Wyjściowy port adresu służy do przekazywania adresu binarnego do magistrali z Pamięci komend (pole ADDRESS w deskryptorze CU).
dat_i_m wejście 8 wysokiWejściowy port danych służy do odczytania danych z magistrali do Pamięci danych.
dat_o_m wyjście 8 wysoki
Wyjściowy port danych używany do przekazywania danych binarnych z Pamięci komend (pole DATA w deskryptorze CU).
we_o_m wyjście 1 wysoki
Wskazuje na to jaki typ cyklu jest obecny na magistrali. Sygnał jest ustawiony na „1” podczas cyklu zapisu lub na „0” podczas cyklu odczytu.
stb_o_m wyjście 1 wysoki
Wskazuje na ważny cykl transmisji. Jest stosowany żeby zakwalifikowaćinne sygnały w interfejsie. Moduł slave musi ustawić na „1” sygnał ACK jako odpowiedź na każde ustawienie na „1” sygnału stb_o_m.
ack_i_m wejście 1 wysokiSygnał wejściowy ustawiony na „1” oznacza zakończenie cyklu na magistrali.
Strona 60
Nazwaportu
KierunekDługość(bitów)
Stanaktywny
Opis
cyc_o_m wyjście 1 wysoki
Sygnał ustawiony na „1” wskazuje, że na magistrali wykonuje się ważnycykl. Sygnał jest ustawiony na „1” podczas wszystkich cykli na magistrali od pierwszej transmisji danych do ostatniej.
Aneks A.4. Porty Interfejsu WSGM
W module UCS jest zaimplementowana minimalna konfiguracja Interfejsu
WSGM która jest pokazana w Tablicy A-4.
Tablicа A-4: Porty Interfejsu WSGM [11]
Nazwaportu
KierunekDługość(bitów)
Stanaktywny
Opis
adr_i_s_gm wejście 8 wysokiWyjściowy port adresu służy do przekazywania adresu binarnego rejestru FLAGS (0h).
dat_i_s_gm wejście 8 wysokiWejściowy port danych służy do odczytania wartości flagi FLAGS.GM.
dat_o_s_gm wyjście 8 wysoki
Wyjściowy port danych służy do przekazywania danych binarnych które muszą być zapisane do pola FLAGS.GM w rejestrze FLAGS.
we_i_s_gm wejście 1 wysoki
Wskazuje na to jaki typ cyklu jest obecny na magistrali. Sygnał jest ustawiony na „1” podczas cyklu zapisu lub na „0” podczas cyklu odczytu.
stb_i_s_gm wejście 1 wysokiWskazuje na to że moduł UCS jest wybrany dla operacji na magistrali.
ack_o_s_gm wyjście 1 wysokiSygnał wyjściowy ustawiony na „1” oznacza zakończenie cyklu na magistrali.
Strona 61
Nazwaportu
KierunekDługość(bitów)
Stanaktywny
Opis
cyc_i_s_gm wejście 1 wysoki
Sygnał ustawiony na „1” wskazuje, że na magistrali wykonuje się ważnycykl. Sygnał jest ustawiony na „1” podczas wszystkich cykli na magistrali od pierwszej transmisji danych do ostatniej.
Strona 62
Aneks B. God Mode
W trybie God Mode Interfejs Wishbone Master jest podłączony do Interfejsu
Wishbone Slave w sposób pokazany na Rysunku B-1.
Kiedy flaga FLAGS.GM jest ustawiona na „1” Zestaw rejestrów nie jest dostępny
i działanie modułu UCS jest wstrzymane.
Wyłączyć God Mode można tylko przez Interfejs WSGM. Wspomniany interfejs
musi być podłączony do magistrali systemowej i działa jak osobny moduł slave ze
swoim unikalnym adresem, który dekoder adresu systemu musi zarezerwować.
Wspomniany wirtualny moduł slave zawiera tylko rejestr FLAGS (pod adresem 0h), w
którym tylko flaga GM jest widoczna ze strony oprogramowania.
Strona 63
Rуsunek B-1: Połączenie interfejsów w God Mode
Strona 64
Aneks C. Interfejs programowy UCS
Aneks C.1. Mapa rejestrów
Mapa rejestrów jest pokazana w Tablicy C-1.
Tablicа C-1: Mapa rejestrów UCS
Nazwa rejestru Adres
FLAGS 0h
DOORBELL 1h
CS0 2h
CS1 3h
CS2 4h
CS3 5h
CS4 6h
CS5 7h
CS6 8h
CS7 9h
CUMA Ah
CUO Bh
CUAC Ch
CUDC Dh
DMD Eh
W Tablicy C-2 przedstawiono typy dostępu do rejestrów zaimplementowane w
module UCS.
Tablicа C-2: Typy dostępu do rejestrów
Typ dostępu Opis
RW Read/Write – zapis oraz odczyt.
RO Read Only – tylko odczyt.
W1HCWrite „1” Hardware Clear – zapis „1” przez oprogramowanie,ustawienie „0” przez sprzęt. Zapis „0” przez oprogramowanie jestignorowany.
RWHLRead/Write Hardware Load – zapis oraz odczyt. Nadpisanie danychprzez sprzęt.
Strona 65
Typ dostępu Opis
ROHLRead Only Hardware Load – tylko odczyt. Zapis danych przezsprzęt.
Aneks C.1.1. FLAGS – Flags (0h)
7 6 5 4 3 2 1 0
Reserved DO DF DE RCMD WCMD GM
Pola bitowe rejestru FLAGS są przedstawione w Tablicy C-3.
Tablicа C-3: Pola bitowe rejestru FLAGS
Numerbitów
Nazwapola
Typdostępu
Opis
5 DO RW
DO – Data Overwrite
Flaga pozwala na nadpisywanie starych danych w Pamięci danych na nowe.„1” – Nadpisywanie danych aktywowane„0” – Nadpisywanie danych zabronione
W przypadku gdy nadpisywanie danych jest zabronione oraz Pamięć danych jest pełna przetwarzanie komend jest zawieszone. W tym przypadku moduł UCS czeka na odczyt danych przez oprogramowanie z rejestru DMD.
4 DF ROHL
DF – Data Full
„1” wskazuje na to że Pamięć danych jest pełna.
Po ustawieniu na „1” oraz kiedy FLAGS.DO jest ”0” przetwarzanie komend jest zawieszone do momentu, gdy oprogramowanie odczytuje dane z rejestru DMD.
3 DE ROHL
DE – Data Empty
„1” wskazuje na to że Pamięć danych jest pusta i dane w rejestrze DMD są nieważne.
Strona 66
Numerbitów
Nazwapola
Typdostępu
Opis
2 RCMD W1HC
RCMD – Read Command
Zapis „1” powoduje odczyt deskryptora CU z Pamięci komend z adresem umieszczonym w rejestrze CUMA do następujących rejestrów:CUO <= CU.OPTIONSCUAC <= CU.ADDRESS/COUNT0CUDC <= CU.DATA/COUNT1
Sprzęt automatycznie ustawia ten bit na „0” po zakończeniu operacji odczytu z Pamięci komend.
1 WCMD W1HC
WCMD – Write Command
Ustawienie na „1” powoduje zapis deskryptora CU który składa się z pól w rejestrach CUO (CU.OPTIONS), CUAC (CU.ADDRESS/COUNT0) i CUDC (CU.DATA/COUNT1) do komórki Pamięci komend z adresem w rejestrze CUMA.
Sprzęt automatycznie ustawia ten bit na „0” po zakończeniu operacji zapisu do Pamięci komend.
0 GM RW
GM – God Mode
Flaga która aktywuje God Mode.„1” – God Mode jest aktywowany„0” – God Mode jest wyłączony
Aktywacja God Mode powoduje przekazanie wszystkich danych wprost od Interfejsu Wishbone Master do Interfejsu Wishbone Slave. W tym trybie Zestaw rejestrów nie jest dostępny.Żeby wyłączyć God Mode trzeba ustawić flagę FLAGS.GM na „0” przez Interfejs WSGM.Tylko flaga FLAGS.GM jest dostępna przez Interfejs WSGM.
Strona 67
Aneks C.1.2. DOORBELL – Doorbell (1h)
7 6 5 4 3 2 1 0
CSB7 CSB6 CSB5 CSB4 CSB3 CSB2 CSB1 CSB0
Pola bitowe rejestru DOORBELL są przedstawione w Tablicy C-4.
Tablicа C-4: Pola bitowe rejestru DOORBELL
Numerbitów
Nazwapola
Typdostępu
Opis
7 CSB7 W1HC
CSB7 – Command Set Bell 7
Zapis „1” powoduje uruchomienie przetwarzania zestawu deskryptorów CS z adresem bazowym w rejestrze CS7.Sprzęt automatycznie ustawia flagę na „0” po zakończeniu przetwarzania zestawu deskryptorów CS.
6 CSB6 W1HC
CSB6 – Command Set Bell 6
Zapis „1” powoduje uruchomienie przetwarzania zestawu deskryptorów CS z adresem bazowym w rejestrze CS6.Sprzęt automatycznie ustawia flagę na „0” po zakończeniu przetwarzania zestawu deskryptorów CS.
5 CSB5 W1HC
CSB5 – Command Set Bell 5
Zapis „1” powoduje uruchomienie przetwarzania zestawu deskryptorów CS z adresem bazowym w rejestrze CS5.Sprzęt automatycznie ustawia flagę na „0” po zakończeniu przetwarzania zestawu deskryptorów CS.
4 CSB4 W1HC
CSB4 – Command Set Bell 4
Zapis „1” powoduje uruchomienie przetwarzania zestawu deskryptorów CS z adresem bazowym w rejestrze CS4.Sprzęt automatycznie ustawia flagę na „0” po zakończeniu przetwarzania zestawu deskryptorów CS.
Strona 68
Numerbitów
Nazwapola
Typdostępu
Opis
3 CSB3 W1HC
CSB3 – Command Set Bell 3
Zapis „1” powoduje uruchomienie przetwarzania zestawu deskryptorów CS z adresem bazowym w rejestrze CS3.Sprzęt automatycznie ustawia flagę na „0” po zakończeniu przetwarzania zestawu deskryptorów CS.
2 CSB2 W1HC
CSB2 – Command Set Bell 2
Zapis „1” powoduje uruchomienie przetwarzania zestawu deskryptorów CS z adresem bazowym w rejestrze CS2.Sprzęt automatycznie ustawia flagę na „0” po zakończeniu przetwarzania zestawu deskryptorów CS.
1 CSB1 W1HC
CSB1 – Command Set Bell 1
Zapis „1” powoduje uruchomienie przetwarzania zestawu deskryptorów CS z adresem bazowym w rejestrze CS1.Sprzęt automatycznie ustawia flagę na „0” po zakończeniu przetwarzania zestawu deskryptorów CS.
0 CSB0 W1HC
CSB0 – Command Set Bell 0
Zapis „1” powoduje uruchomienie przetwarzania zestawu deskryptorów CS z adresem bazowym w rejestrze CS0.Sprzęt automatycznie ustawia flagę na „0” po zakończeniu przetwarzania zestawu deskryptorów CS.
Strona 69
Aneks C.1.3. CS0 – Command Set 0 (2h)
7 6 5 4 3 2 1 0
CSA0
Pola bitowe rejestru CS0 są przedstawione w Tablicy C-5.
Tablicа C-5: Pola bitowe rejestru CS0
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CSA0 RW
CSA0 – Command Set Address 0
Adres bazowy zestawu deskryptorów CS, przetwarzanie którego uruchamia się przez ustawienie na „1” flagi DOORBELL.CSB0.
Aneks C.1.4. CS1 – Command Set 1 (3h)
7 6 5 4 3 2 1 0
CSA1
Pola bitowe rejestru CS1 są przedstawione w Tablicy C-6.
Tablicа C-6: Pola bitowe rejestru CS1
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CSA1 RW
CSA1 – Command Set Address 1
Adres bazowy zestawu deskryptorów CS, przetwarzanie którego uruchamia się przez ustawienie na „1” flagi DOORBELL.CSB1.
Strona 70
Aneks C.1.5. CS2 – Command Set 2 (4h)
7 6 5 4 3 2 1 0
CSA2
Pola bitowe rejestru CS2 są przedstawione w Tablicy C-7.
Tablicа C-7: Pola bitowe rejestru CS2
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CSA2 RW
CSA2 – Command Set Address 2
Adres bazowy zestawu deskryptorów CS, przetwarzanie którego uruchamia się przez ustawienie na „1” flagi DOORBELL.CSB2.
Aneks C.1.6. CS3 – Command Set 3 (5h)
7 6 5 4 3 2 1 0
CSA3
Pola bitowe rejestru CS3 są przedstawione w Tablicy C-8.
Tablicа C-8: Pola bitowe rejestru CS3
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CSA3 RW
CSA3 – Command Set Address 3
Adres bazowy zestawu deskryptorów CS, przetwarzanie którego uruchamia się przez ustawienie na „1” flagi DOORBELL.CSB3.
Strona 71
Aneks C.1.7. CS4 – Command Set 4 (6h)
7 6 5 4 3 2 1 0
CSA4
Pola bitowe rejestru CS4 są przedstawione w Tablicy C-9.
Tablicа C-9: Pola bitowe rejestru CS4
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CSA4 RW
CSA4 – Command Set Address 4
Adres bazowy zestawu deskryptorów CS, przetwarzanie którego uruchamia się przez ustawienie na „1” flagi DOORBELL.CSB4.
Aneks C.1.8. CS5 – Command Set 5 (7h)
7 6 5 4 3 2 1 0
CSA5
Pola bitowe rejestru CS5 są przedstawione w Tablicy C-10.
Tablicа C-10: Pola bitowe rejestru CS5
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CSA5 RW
CSA5 – Command Set Address 5
Adres bazowy zestawu deskryptorów CS, przetwarzanie którego uruchamia się przez ustawienie na „1” flagi DOORBELL.CSB5.
Strona 72
Aneks C.1.9. CS6 – Command Set 6 (8h)
7 6 5 4 3 2 1 0
CSA6
Pola bitowe rejestru CS6 są przedstawione w Tablicy C-11.
Tablicа C-11: Pola bitowe rejestru CS6
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CSA6 RW
CSA6 – Command Set Address 6
Adres bazowy zestawu deskryptorów CS, przetwarzanie którego uruchamia się przez ustawienie na „1” flagi DOORBELL.CSB6.
Aneks C.1.10. CS7 – Command Set 7 (9h)
7 6 5 4 3 2 1 0
CSA7
Pola bitowe rejestru CS7 są przedstawione w Tablicy C-12.
Tablicа C-12: Pola bitowe rejestru CS7
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CSA7 RW
CSA7 – Command Set Address 7
Adres bazowy zestawu deskryptorów CS, przetwarzanie którego uruchamia się przez ustawienie na „1” flagi DOORBELL.CSB7.
Strona 73
Aneks C.1.11. CUMA – Command Unit Memory Address (Ah)
7 6 5 4 3 2 1 0
CUMA
Pola bitowe rejestru CUMA są przedstawione w Tablicy C-13.
Tablicа C-13: Pola bitowe rejestru CUMA
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CUMA RW
CUMA – Command Unit Memory Address
Adres deskryptora CU lub CCU, który może być odczytany z Pamięci komend po ustawieniu na „1” flagi FLAGS.RCMD.CU.OPTIONS => CUOCU.ADDRESS/COUNT0 => CUACCU.DATA/COUNT1 => CUDC
Adres deskryptora CU lub CCU, który może być zapisany do Pamięci komend po ustawieniu na „1” flagi FLAGS.WCMD.CUO => CU.OPTIONSCUAC => CU.ADDRESS/COUNT0CUDC => CU.DATA/COUNT1
Strona 74
Aneks C.1.12. CUO – Command Unit Options (Bh)
7 6 5 4 3 2 1 0
CUO
Pola bitowe rejestru CUO są przedstawione w Tablicy C-14.
Tablicа C-14: Pola bitowe rejestru CUO
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CUO RWHL
CUO – Command Unit Options
Zawiera pole OPTIONS deskryptora CU oraz CCU, które po ustawieniu flagi FLAGS.RCMD na„1”, jest odczytywane z komórki Pamięci komend zadresem w rejestrze CUMA.
Zawiera pole OPTIONS deskryptora CU oraz CCU, które po ustawieniu flagi FLAGS.WCMD na„1”, jest zapisywane do komórki Pamięci komend zadresem w rejestrze CUMA.
Strona 75
Aneks C.1.13. CUAC – Command Unit Address/Count (Ch)
7 6 5 4 3 2 1 0
CUAC
Pola bitowe rejestru CUAC są przedstawione w Tablicy C-15.
Tablicа C-15: Pola bitowe rejestru CUAC
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CUAC RWHL
CUAC – Command Unit Address/Count
Zawiera pole ADDRESS deskryptora CU lub COUNT0 deskryptora CCU, które po ustawieniu flagi FLAGS.RCMD na „1”, jest odczytywane z komórki Pamięci komend z adresem w rejestrze CUMA.
Zawiera pole ADDRESS deskryptora CU lub COUNT0 deskryptora CCU, które po ustawieniu flagi FLAGS.WCMD na „1”, jest zapisywane do komórki Pamięci komend z adresem w rejestrze CUMA.
Strona 76
Aneks C.1.14. CUDC – Command Unit Data/Count (Dh)
7 6 5 4 3 2 1 0
CUDC
Pola bitowe rejestru CUDC są przedstawione w Tablicy C-16.
Tablicа C-16: Pola bitowe rejestru CUDC
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] CUDC RWHL
CUDC – Command Unit Data/Count
Zawiera pole DATA deskryptora CU lub COUNT1 deskryptora CCU, które po ustawieniu flagi FLAGS.RCMD na „1”, jest odczytywane z komórki Pamięci komend z adresem w rejestrze CUMA.
Zawiera pole DATA deskryptora CU lub COUNT1 deskryptora CCU, które po ustawieniu flagi FLAGS.WCMD na „1”, jest zapisywane do komórki Pamięci komend z adresem w rejestrze CUMA.
Aneks C.1.15. DMD – Data Memory Data (Eh)
7 6 5 4 3 2 1 0
DMD
Pola bitowe rejestru DMD są przedstawione w Tablicy C-17.
Tablicа C-17: Pola bitowe rejestru DMD
Numerbitów
Nazwapola
Typdostępu
Opis
[8:0] DMD ROHL
DMD – Data Memory Data
Rejestr zawiera najstarsze dane które zostały zapisane do Pamięci danych. Podczas odczytu rejestru dane są usuwane z Pamięci danych (kolejka FIFO).Pole nie jest ważne, gdy flaga FLAGS.DE jest ustawiona na „1”.
Strona 77
Aneks C.2. Deskryptor CU
Deskryptor CU określa operację, która musi być wykonana na Interfejsie
Wishbone Master. Deskryptor składa się z trzech pól 8-bitowych: OPTIONS,
ADDRESS i DATA jak pokazano na Rysunku C-1.
7 6 5 4 3 2 1 0
OPTIONS
ADDRESS
DATA
Rуsunek C-1: Deskryptor CU
Pole OPTIONS – zawiera flagi pokazane na Rysunku C-2 które są niezbędne do
poprawnego przetwarzania deskryptora CU.
Pole ADDRESS – adres wewnętrznego rejestru modułu slave podłączonego do
magistrali systemowej.
Pole DATA – dane które muszą być wystawione na magistrali dla zapisu do
wewnętrznego rejestru modułu slave podłączonego do magistrali systemowej. Jeśli
flaga OPTIONS.RW jest ustawiona na „0” (komenda odczytu) to pole jest ignorowane
przez sprzęt.
7 6 5 4 3 2 1 0
RW CTRL VALID Reserved
Rуsunek C-2: Flagi pola OPTIONS w deskryptorze CU
Flaga OPTIONS.RW – wskazuje na typ komendy:
• „1” – komenda zapisu
• „0” – komenda odczytu
Flaga OPTIONS.CTRL – musi być ustawiona na „0” dla deskryptora CU.
Strona 78
Flaga OPTIONS.VALID – wskazuje na to czy deskryptor jest ważny:
• „1” – deskryptor jest ważny
• „0” – deskryptor jest nieważny. W tym przypadku deskryptor będzie
zignorowany, a przetwarzanie zestawu deskryptorów CS – przerwane.
Uwaga: pola „Reserved” są ignorowane przez sprzęt.
Aneks C.3. Deskryptor CCU
Deskryptor CCU musi być na końcu każdego zestawu deskryptorów CS. Zawiera
trzy 8-bitowe pola: OPTIONS, COUNT0 oraz COUNT1 jak pokazano na Rysunku C-3.
7 6 5 4 3 2 1 0
OPTIONS
COUNT0
COUNT1
Rуsunek C-3: Deskryptor CCU
Pole OPTIONS – zawiera flagi pokazane na Rysunku C-4, które są niezbędne do
poprawnego przetwarzania deskryptora CCU.
Pole COUNT0 – dolne 8 bitów 16-bitowego licznika, który określa ile razy
zestaw deskryptorów CS musi być wykonany zaczynając od adresu bazowego.
Pole COUNT1 – górne 8 bitów 16-bitowego licznika, który określa ile razy
zestaw deskryptorów CS musi być wykonany zaczynając od adresu bazowego.
7 6 5 4 3 2 1 0
Reserved CTRL VALID Reserved
Rуsunek C-4: Flagi pola OPTIONS w deskryptorze CCU
Flaga OPTIONS.CTRL – musi być ustawiona na „1” dla deskryptora CCU.
Strona 79
Flaga OPTIONS.VALID – wskazuje na to czy deskryptor CCU jest ważny:
• „1” – deskryptor jest ważny
• „0” – deskryptor jest nieważny. W tym przypadku deskryptor będzie
zignorowany, a przetwarzanie zestawu deskryptorów CS – przerwane.
Uwaga: pola „Reserved” są ignorowane przez sprzęt.
Strona 80
Aneks D. Cykle operacyjne Wishbone
Aneks D.1. Reset
Podczas resetu wszystkie sprzętowe interfejsy są inicjalizowane do początkowego
stanu. Jest to realizowane ustawieniem linii rst_i na „1”. Ustawienie jest możliwe w
dowolnym momencie. Cykl resetu jest pokazany na Rysunku D-1.
Wszystkie interfejsy Wishbone są inicjalizowane podczas narastającego zbocza
sygnału clk_i po ustawieniu sygnału rst_i na „1”. Interfejsy pozostają w początkowym
stanie do ustawienia rst_i na „0” podczas narastającego zbocza clk_i. rst_i musi być
ustawiony na „1” przez co najmniej jeden takt zegara.
Następujące sygnały Interfejsu Wishbone Master są ustawione na „0” po resecie:
stb_o_m, cyc_o_m. Wartości wszystkich innych sygnałów interfejsów po resecie są
niezdefiniowane.
Dane z Zestawu rejestrów oraz Pamięci danych są usuwane po resecie.
Uwaga: Dane z Pamięci komend są zachowane po resecie.
Strona 81
Rуsunek D-1: Cykl resetu [11]
Aneks D.2. Pojedynczy odczyt
Pojedynczy odczyt wykonuje jeden transfer danych naraz.
Rysunek D-2 pokazuje diagram czasowy dla cyklu pojedynczego odczytu na
Interfejsie Wishbone Master w module UCS. Główne etapy:
Narastające zbocze zegara 0:
• Moduł UCS ustawia ważny adres na linii adr_o_m.
• Moduł UCS ustawia na „0” sygnał we_o_m, co wskazuje na cykl odczytu.
• Moduł UCS ustawia na „1” sygnał cyc_o_m, co wskazuje na początek cyklu.
• Moduł UCS ustawia na „1” sygnał stb_o_m, co wskazuje na początek fazy.
Narastające zbocze zegara 1:
• Moduł slave dekoduje wejścia.
• Moduł slave ustawia ważne dane na linii dat_i_m.
• Moduł slave ustawia na „1” sygnał ack_i_m jako odpowiedź na sygnał stb_o_m,
co wskazuje na ważne dane.
• Moduł UCS sprawdza linie ack_i_m i przygotowuje się do zatrzaskiwania
danych na linii dat_i_m.
Narastające zbocze zegara 2:
• Moduł UCS zatrzaskuje dane na linii dat_i_m.
• Moduł UCS ustawia na „0” sygnał stb_o_m oraz cyc_o_m, co wskazuje na
zakończenie cyklu.
• Moduł slave ustawia sygnał ack_i_m na „0” jako odpowiedź na ustawienie
stb_o_m na „0”.
Strona 82
Rysunek D-3 pokazuje diagram czasowy dla cyklu pojedynczego odczytu na
Interfejsie Wishbone Slave w module UCS. Główne etapy:
Narastające zbocze zegara 0:
• Moduł master ustawia ważny adres na linii adr_i_s.
• Moduł master ustawia na „0” sygnał we_i_s, co wskazuje na cykl odczytu.
• Moduł master ustawia na „1” sygnał cyc_i_s, co wskazuje na początek cyklu.
• Moduł master ustawia na „1” sygnał stb_i_s, co wskazuje na początek fazy.
Narastające zbocze zegara 1:
• Moduł UCS dekoduje wejścia.
• Moduł UCS ustawia ważne dane na linii data_o_s.
• Moduł UCS ustawia sygnał ack_o_s na „1” jako odpowiedź na ustawienie na
„1” sygnału stb_i_s, co wskazuje na ważność danych.
• Moduł master sprawdza linie ack_o_s i przygotowuje się do zatrzaskiwania
danych na linii dat_o_s.
Strona 83
Rуsunek D-2: Cykl pojedynczego odczytu na Interfejsie Wishbone Master w module UCS [11]
Narastające zbocze zegara 2:
• Moduł master zatrzaskuje dane na linii dat_o_s.
• Moduł master ustawia na „0” sygnał stb_i_s oraz cyc_i_s, co wskazuje na
zakończenie cyklu.
• Moduł UCS ustawia sygnał ack_o_s na „0” jako odpowiedź na ustawienie
stb_i_s na „0”.
Rysunek D-4 pokazuje diagram czasowy dla cyklu pojedynczego odczytu na
Interfejsie WSGM w module UCS. Główne etapy:
Narastające zbocze zegara 0:
• Moduł master ustawia ważny adres na linii adr_i_s_gm.
• Moduł master ustawia na „0” sygnał we_i_s_gm, co wskazuje na cykl odczytu.
• Moduł master ustawia na „1” sygnał cyc_i_s_gm, co wskazuje na początek
cyklu.
• Moduł master ustawia na „1” sygnał stb_i_s_gm, co wskazuje na początek fazy.
Strona 84
Rуsunek D-3: Cykl pojedynczego odczytu na Interfejsie Wishbone Slave w module UCS [11]
Narastające zbocze zegara 1:
• Moduł UCS dekoduje wejścia.
• Moduł UCS ustawia ważne dane na linii data_o_s_gm.
• Moduł UCS ustawia sygnał ack_o_s_gm na „1” jako odpowiedź na ustawienie
na „1” sygnału stb_i_s_gm, co wskazuje na ważność danych.
• Moduł master sprawdza linie ack_o_s_gm i przygotowuje się do zatrzaskiwania
danych na linii dat_o_s_gm.
Narastające zbocze zegara 2:
• Moduł master zatrzaskuje dane na linii dat_o_s_gm.
• Moduł master ustawia na „0” sygnał stb_i_s_gm oraz cyc_i_s_gm, co wskazuje
na zakończenie cyklu.
• Moduł UCS ustawia sygnał ack_o_s_gm na „0” jako odpowiedź na ustawienie
stb_i_s_gm na „0”.
Strona 85
Rуsunek D-4: Cykl pojedynczego odczytu na Interfejsie WSGM w UCS [11]
Aneks D.3. Pojedynczy zapis
Pojedynczy zapis wykonuje jeden transfer danych naraz.
Rysunek D-5 pokazuje diagram czasowy dla cyklu pojedynczego zapisu na
Interfejsie Wishbone Master w module UCS. Główne etapy:
Narastające zbocze zegara 0:
• Moduł UCS ustawia ważny adres na linii adr_o_m.
• Moduł UCS ustawia ważne dane na linii dat_o_m.
• Moduł UCS ustawia na „1” sygnał we_o_m, co wskazuje na cykl zapisu.
• Moduł UCS ustawia na „1” sygnał cyc_o_m, co wskazuje na początek cyklu.
• Moduł UCS ustawia na „1” sygnał stb_o_m, co wskazuje na początek fazy.
Narastające zbocze zegara 1:
• Moduł slave dekoduje wejścia.
• Moduł slave przygotowuje się do zatrzaskiwania danych na linii dat_o_m.
• Moduł slave ustawia na „1” sygnał ack_i_m jako odpowiedź na sygnał stb_o_m,
co wskazuje na ważne dane.
• Moduł UCS sprawdza linie ack_i_m i przygotowuje się do zakończenia cyklu.
Narastające zbocze zegara 2:
• Moduł slave zatrzaskuje dane na linii dat_o_m.
• Moduł UCS ustawia na „0” sygnał stb_o_m oraz cyc_o_m, co wskazuje na
zakończenie cyklu.
• Moduł slave ustawia sygnał ack_i_m na „0” jako odpowiedź na ustawienie
stb_o_m na „0”.
Strona 86
Rysunek D-6 pokazuje diagram czasowy dla cyklu pojedynczego zapisu na
Interfejsie Wishbone Slave w module UCS. Główne etapy:
Narastające zbocze zegara 0:
• Moduł master ustawia ważny adres na linii adr_i_s.
• Moduł master ustawia ważne dane na linii dat_i_s.
• Moduł master ustawia na „1” sygnał we_i_s, co wskazuje na cykl zapisu.
• Moduł master ustawia na „1” sygnał cyc_i_s, co wskazuje na początek cyklu.
• Moduł master ustawia na „1” sygnał stb_i_s, co wskazuje na początek fazy.
Narastające zbocze zegara 1:
• Moduł UCS dekoduje wejścia.
• Moduł UCS przygotowuje się do zatrzaskiwania danych na linii dat_i_s.
• Moduł UCS ustawia na „1” sygnał ack_o_s jako odpowiedź na sygnał stb_i_s,
co wskazuje na ważne dane.
• Moduł master sprawdza linie ack_o_s i przygotowuje się do zakończenia cyklu.
Strona 87
Rуsunek D-5: Cykl pojedynczego zapisu na Interfejsie Wishbone Master w module UCS [11]
Narastające zbocze zegara 2:
• Moduł UCS zatrzaskuje dane na linii dat_i_s.
• Moduł master ustawia na „0” sygnał stb_i_s oraz cyc_i_s, co wskazuje na
zakończenie cyklu.
• Moduł UCS ustawia sygnał ack_o_s na „0” jako odpowiedź na ustawienie
stb_i_s na „0”.
Rysunek D-7 pokazuje diagram czasowy dla cyklu pojedynczego zapisu na
Interfejsie WSGM w module UCS. Główne etapy:
Narastające zbocze zegara 0:
• Moduł master ustawia ważny adres na linii adr_i_s_gm.
• Moduł master ustawia ważne dane na linii dat_i_s_gm.
• Moduł master ustawia na „1” sygnał we_i_s_gm, co wskazuje na cykl zapisu.
• Moduł master ustawia na „1” sygnał cyc_i_s_gm, co wskazuje na początek
cyklu.
• Moduł master ustawia na „1” sygnał stb_i_s_gm, co wskazuje na początek fazy.
Strona 88
Rуsunek D-6: Cykl pojedynczego zapisu na Interfejsie Wishbone Slave w UCS [11]
Narastające zbocze zegara 1:
• Moduł UCS dekoduje wejścia.
• Moduł UCS przygotowuje się do zatrzaskiwania danych na linii dat_i_s_gm.
• Moduł UCS ustawia na „1” sygnał ack_o_s_gm jako odpowiedź na sygnał
stb_i_s_gm, co wskazuje na ważne dane.
• Moduł master sprawdza linie ack_o_s_gm i przygotowuje się do zakończenia
cyklu.
Narastające zbocze zegara 2:
• Moduł UCS zatrzaskuje dane na linii dat_i_s_gm.
• Moduł master ustawia na „0” sygnał stb_i_s_gm oraz cyc_i_s_gm, co wskazuje
na zakończenie cyklu.
• Moduł UCS ustawia sygnał ack_o_s_gm na „0” jako odpowiedź na ustawienie
stb_i_s_gm na „0”.
Strona 89
Rуsunek D-7: Cykl pojedynczego zapisu na Interfejsie WSGM w module UCS [11]