ievgenii drozdov

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.

Key words: SoC, VHDL, UART, Wishbone, Bus, Interface, Transmission, Speed,

Scatter-gather.

Życiorys

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

4.2.1. Schemat blokowy.........................................................................................264.2.2. Opis interfejsów...........................................................................................284.2.3. Pamięć komend............................................................................................284.2.4. Pamięć danych..............................................................................................284.2.5. Zestaw rejestrów..........................................................................................284.2.6. Rdzeń UCS...................................................................................................28

4.3. Zasady działania...................................................................................................294.3.1. Konfiguracja.................................................................................................294.3.2. Uruchomienie przetwarzania........................................................................304.3.3. Zakończenie przetwarzania..........................................................................31

4.4. Weryfikacja funkcjonalna....................................................................................324.5. Synteza.................................................................................................................35

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 A.1. Porty sterujące..........................................................................................59Aneks A.2. Porty Interfejsu Wishbone Slave..............................................................59Aneks A.3. Porty Interfejsu Wishbone Master............................................................60Aneks A.4. Porty Interfejsu WSGM...........................................................................61

Aneks B. God Mode.......................................................................................................63Aneks C. Interfejs programowy UCS..........................................................................65

Aneks C.1. Mapa rejestrów.........................................................................................65Aneks C.1.1. FLAGS – Flags (0h).........................................................................66Aneks C.1.2. DOORBELL – Doorbell (1h)...........................................................68Aneks C.1.3. CS0 – Command Set 0 (2h)..............................................................70Aneks C.1.4. CS1 – Command Set 1 (3h)..............................................................70

Strona 7

Aneks C.1.5. CS2 – Command Set 2 (4h)..............................................................71Aneks C.1.6. CS3 – Command Set 3 (5h)..............................................................71Aneks C.1.7. CS4 – Command Set 4 (6h)..............................................................72Aneks C.1.8. CS5 – Command Set 5 (7h)..............................................................72Aneks C.1.9. CS6 – Command Set 6 (8h)..............................................................73Aneks C.1.10. CS7 – Command Set 7 (9h)............................................................73Aneks C.1.11. CUMA – Command Unit Memory Address (Ah)..........................74Aneks C.1.12. CUO – Command Unit Options (Bh).............................................75Aneks C.1.13. CUAC – Command Unit Address/Count (Ch)...............................76Aneks C.1.14. CUDC – Command Unit Data/Count (Dh)....................................77Aneks C.1.15. DMD – Data Memory Data (Eh)....................................................77

Aneks C.2. Deskryptor CU.........................................................................................78Aneks C.3. Deskryptor CCU......................................................................................79

Aneks D. Cykle operacyjne Wishbone.........................................................................81Aneks D.1. Reset.........................................................................................................81Aneks D.2. Pojedynczy odczyt...................................................................................82Aneks D.3. Pojedynczy zapis......................................................................................86

Strona 8

1. Akronimy i spis oznaczeń

Spis oznaczeń stosowanych w pracy oraz akronimy są przedstawione

odpowiednio w Tablicy 1-1 oraz Tablicy 1-2.

• Wszystkie szesnastkowe liczby są oznaczone małą literą „h” na końcu

(Przykład: 40h). Nieistotne cyfry w liczbach szesnastkowych są zastąpione przez

wielką literę „X” (Przykład: 4Xh).

• Wszystkie dziesiątkowe liczby nie są oznaczone przez żadną literę.

• Wszystkie dwójkowe liczby są oznaczone przez małą literę „b” na końcu

(Przykład: 0101_0101b). Nieistotne cyfry w liczbach dwójkowych są zastąpione

przez małą literę „x” (Przykład: 0x01_010xb).

• Interfejs typu „Master” magistrali jest oznaczony wielką literą „M”.

• Interfejs typu „Slave” magistrali jest oznaczony wielką literą „S”.

• Interfejs typu „Slave” dla trybu „God Mode” jest oznaczony wielkimi literami

„S_GM”.

Tablica 1-1: Spis oznaczeń

Oznaczenie Opis

Master Moduł który inicjuje transakcję na magistrali

Slave Moduł który przyjmuje transakcję na magistrali

Bajt Wartość 8-bitowa

Słowo Wartość 8-bitowa

Host System sterujący

Tablica 1-2: Akronimy

Akronim Opis

FPGA Field-Programmable Gate Array

SoC System on Chip

DMA Direct Memory Access

xHCI Extensible Host Controller Interface

USB Universal Serial Bus

UCS Universal Command Scheduler

UART Universal Asynchronous Receiver/Transmitter

Strona 9

Akronim Opis

PHY PHYsical layer

GPIO General-Purpose Input/Output

MM2S Memory-Mapped to Stream

FIFO First In, First Out

xHC Extensible Host Controller

CD Command Descriptor

TRB Transfer Request Block

CCE Command Completion Event

PCS Producer Cycle State

CCS Consumer Cycle State

CRCR Command Ring Control Register

VHDLVery high speed integrated circuit Hardware Description Language

AXI Advanced eXtensible Interface

OCP Open Core Protocol

WSGM Wishbone Slave for God Mode

CU Command Unit

CS Command Set

CCU Control Command Unit

ptr pointer

LUT Look-Up Table

BRAM Block Random Access Memory

LED Light-Emitting Diode

Strona 10

2. Wstęp

Rozwiązania typu System on Chip (SoC) są szeroko stosowane do gromadzenia,

przetwarzania i przesyłania danych. Przykładowe zastosowanie tych systemów to:

inteligentne domy, centra danych, stacje meteo, centra rozrywki, itp. Taka złożoność

wymaga sprawnego połączenia między różnymi podsystemami. Na przykład: stacja

meteo wymaga podsystemu zbierania danych z czujników, podsystemu

przetwarzającego dane do postaci czytelnej dla użytkownika oraz do dalszej analizy.

Połączenie nie zawsze może być wewnętrzne (w jednym układzie scalonym), ponieważ

podsystemy mogą zostać umieszczone w pewnej odległości od siebie. W tym przypadku

interfejs zewnętrzny (ścieżka na płytce drukowanej, kabel) może stać się wąskim

gardłem i ograniczyć przepustowość. W większości przypadków cały system staje się

tak wolny jak najwolniejszy podsystem.

W przypadku działania systemu w jednej domenie zegarowej wewnętrzna

magistrala lub połączenie w układzie scalonym jest znacznie szybsze niż zewnętrzny

interfejs. Jednym z rozwiązań zwiększających wydajność jest przekazanie największej

części pracy blokom wewnętrznym i korzystanie z interfejsu zewnętrznego głównie do

zbierania danych. Nie jest to nowa koncepcja: dobrym przykładem jest wymiana danych

pomiędzy procesorem i blokiem, który musi wykonać pewne operacje na pamięci. Aby

zmniejszyć obciążenie procesora jest używana technologia Direct Memory Access

(DMA). Nie zmniejsza ona ilości informacji przesyłanej przez magistralę, ale pozwala

procesorowi wykonać dodatkową pracę podczas przesyłania danych z pamięci do bloku

funkcjonalnego.

Obecnie stał się popularny specjalny typ DMA – scatter-gather DMA. Pozwala on

na przeniesienie dużej ilości danych między pamięcią i blokami funkcjonalnymi i nie

wymaga przerwania procesora na końcu każdego bloku danych. Jest to zrobione za

pomocą techniki adresacji wektorowej, która jest oparta na deskryptorach. Technika ta

może być stosowana nie tylko dla surowych danych, ale również dla poleceń.

Przykładem takiego wykorzystania jest kolejka Command Ring w interfejsie extensible

Host Controller Interface (xHCI) dla magistrali Universal Serial Bus 3.0 (USB3.0).

Nie ma dostępnych uniwersalnych otwartych rozwiązań podobnego problemu.

Problem staje się jeszcze bardziej istotny, gdy liczba bloków funkcjonalnych w systemie

SoC rośnie. Każdy blok musi być inicjalizowany oraz uczestniczyć w wymianie

Strona 11

danych. Istnieje potrzeba uniwersalnego rozwiązania, które można łatwo modyfikować i

łatwo zintegrować w układzie. W pracy przedstawiono konfigurowalne i elastyczne

rozwiązanie problemu opisanego powyżej – Universal Command Scheduler (UCS).

Strona 12

3. Przegląd zagadnienia

3.1. Opis problemu

Większość płyt dostarczanych przez producentów układów FPGA zawiera kilka

domen zegarowych. Niektóre interfejsy zewnętrzne działają znacznie szybciej niż zegar

systemowy (Ethernet, USB, itd.), a inne – wolniej (Universal Asynchronous

Receiver/Transmitter – UART).

Jednym z przykładów jest płyta Spartan-3AN Starter Kit firmy Xilinx która ma

następujące charakterystyki:

• Zegar systemowy: 50 MHz [1].

• Ethernet w trybie 100Base-TX: 100 Mb/s [1].

• RS-232 (UART): do 20 Kb/s według standardu [2].

Wszystkie interfejsy w podobnych płytach są dostarczane razem ze zintegrowaną

warstwą Physical layer (PHY).

W przypadku interfejsu wolniejszego od zegara systemowego ograniczeniem

szybkości jest najniższa warstwa – PHY. Jednym z rozwiązań problemu jest

wykorzystanie interfejsu tylko dla inicjalizacji i zbierania danych. W tym przypadku

niezbędne jest buforowanie komend w pamięci systemowej.

Interfejs szybszy niż zegar systemowy jest zależny od powyższych warstw

sprzętowych, które są taktowane przez ten zegar. W tym przypadku ograniczeniem jest

sterownik interfejsu w systemie. Jednym z rozwiązań tego problemu jest

zrównoleglenie zadań na poziomie sterownika lub samego systemu. Wąskim gardłem w

podobnych SoC jest magistrala systemowa. Jednym z rozwiązań problemu jest użycie

kilku magistral systemowych obsługą których zajmuję się osobny moduł – arbiter.

Rozwiązanie zaproponowane pracy pozwoli na zwiększenie szybkości działania

systemu w obu wymienionych przypadkach.

Strona 13

3.2. Studia literaturowe

3.2.1. Analiza sekwencji programowych

Firma Xilinx udostępnia dobrze udokumentowaną bibliotekę modułów do

tworzenia systemów SoC którą można wykorzystać do analizy najczęściej używanych

sekwencji komend. Do analizy zostały wybrane trzy kategorie modułów:

1. Interfejsy:

◦ Kontroler portów General-Purpose Input/Output (GPIO).

◦ Sterownik magistrali USB2.0.

2. Kontrolery pamięci:

◦ DMA.

3. Inne

◦ Monitor systemowy.

◦ Zegar / licznik.

Oznaczenia przedstawione w Tablicy 3-1 są stosowane do opisu komend.

Tablica 3-1: Oznaczenie do opisu komend

Oznaczenie Opis

OUT Zapis danych pod adresem docelowym

IN Odczyt danych z adresu źródłowego

CMPPorównanie dwóch wartości (ustawia flagę „zero” jeśli są równe)

JNZ Przejście jeśli flaga „zero” nie jest ustawiona

$REGISTER Adres rejestru

data Adres albo dane (zmienna lokalna)

Nie ma potrzeby analizy procesu inicjalizacji, ponieważ jest on wykonywany

tylko na początku pracy modułu i rzadko się powtarza (po resecie albo zmianie

konfiguracji). Sekwencje opisane poniżej są głównie operacjami odczytu/zapisu przez

interfejsy, rozpoczęcia transferu danych przez magistralę, rozpoczęcia monitorowania i

odczytu danych. We wszystkich przypadkach przerwania nie są wykorzystywane.

Strona 14

W Tablicach 3-2 i 3-3 pokazane są najczęściej używane komendy przy sterowaniu

kontrolerem GPIO.

Tablica 3-2: Sterowanie kontrolerem GPIO. Porty w trybie wejściowym [3]

OUT $GPIOx_TRI, 1IN data, $GPIOx_DATA

Tablica 3-3: Sterowanie kontrolerem GPIO. Porty w trybie wyjściowym [3]

OUT $GPIOx_TRI, 0OUT $GPIOx_DATA, data

W Tablicach 3-4 i 3-5 pokazane są najczęściej używane komendy przy sterowaniu

kontrolerem USB2.0.

Tablica 3-4: Sterowanie kontrolerem USB2.0. Obsługa transakcji IN typu Bulk/Isochronous [4]

OUT dpram_addr, in_packetOUT $BUFFER_COUNT, packet_countOUT $BUFFER_READY, 1WAIT:IN AX, $BUFFER_READYCMP AX, 0JNZ WAIT

Tablica 3-5: Sterowanie kontrolerem USB2.0. Obsługa transakcji OUT typu Bulk/Isochronous [4]

WAIT:IN AX, $BUFFER_COMPLETECMP AX, 1JNZ WAITIN AX, $PACKET_COUNT_RECEIVEDIN BX, $PACKET_COUNTCMP AX, BXJNZ WAITIN out_packet, dpram_addressOUT $BUFFER_READY, 1

Strona 15

W Tablicach 3-6 i 3-7 pokazane są najczęściej używane komendy do inicjalizacji i

uruchomienia kanału Memory-Mapped to Stream (MM2S) przy sterowaniu kontrolerem

DMA.

Tablica 3-6: Sterowanie kontrolerem DMA. Tryb klasyczny [5]

OUT $MM2S_DMACR.RS, 1OUT $MM2S_SA, source_addressOUT $MM2S_LENGTH, bytes_number

Tablica 3-7: Sterowanie kontrolerem DMA. Tryb scatter-gather [5]

OUT $CURRENT_DESCRIPTOR, address_startOUT $MM2S_DMACR.RS, 1OUT $TAIL_DESCRIPTOR, address_tail

Tablica 3-8 pokazuje najczęściej używane komendy przy sterowaniu monitorem

systemowym (cykliczne działanie w trybie sekwencyjnym).

Tablica 3-8: Sterowanie monitorem systemowym [6]

IN on_chip_temperature, $C_BASEADDR + 0x200IN v_ccint, $CBASEADDR + 0x204IN v_ccaux, $CBASEADDR + 0x208

W Tablicach 3-9 i 3-10 pokazane są najczęściej używane komendy przy

sterowaniu 64-bitowym zegarem/licznikiem odpowiednio w trybie generacji i

klasycznym.

Tablica 3-9: Sterowanie zegarem/licznikiem. Tryb generacji [7]

OUT $TCSR0, 0OUT $TCSR1, 0OUT $TLR0, lower_loadOUT $TLR1, higher_loadOUT $TCSR0.CASC, 1OUT $TCSR0.EN, 1

Strona 16

Tablica 3-10: Sterowanie zegarem/licznikiem. Tryb klasyczny [7]

IN AX, $TCR1REPEAT:IN BX, $TCR0IN DX, $TCR1CMP AX, DXJNZ REPEAT

Analizując przedstawione powyżej sekwencje komend możemy zrobić listę

najczęściej używanych operacji w kolejności malejącej:

1. Operacja zapisu wartości do rejestru.

2. Operacja odczytu wartości z rejestru.

3. Oczekiwanie zakończenia operacji (monitorowanie flag).

W celu minimalizacji czasu wysyłania powyższych sekwencji komend przez

zewnętrzny interfejs z zachowaniem funkcjonalności można posłużyć się następującymi

metodami:

1. Buforowanie komend (wykorzystując metodę First In, First Out – FIFO) –

eliminuje potrzebę oczekiwania na koniec wykonania komendy.

2. Metoda scatter-gather – zapewnia automatyczne pobieranie komend z pamięci

za pomocą deskryptorów.

3. Buforowanie wyników – umożliwia zbieranie danych wyjściowych z modułów

do pamięci, a potem odczyt pamięci systemem sterującym.

4. Uniwersalny rejestr flag – wykorzystuje dodatkowy moduł z wewnętrznym

rejestrem flag. Zbiera on wszystkie flagi (status, zakończenie operacji) z innych

modułów. W tym przypadku system sterujący musi monitorować tylko jeden

rejestr zamiast wielu.

W pracy zostały zaimplementowane sposoby 2 i 3, co pozwoliło zminimalizować

nie tylko czas wykonania najczęściej używanych sekwencji komend, ale również czas

wykonania inicjalizacji oraz każdej komendy.

3.2.2. USB 3.0 Command Ring

USB3.0 jest jednym z najbardziej skomplikowanych współczesnych standardów

interfejsu komunikacyjnego. Do analizy technik używanych do wysyłania i buforowania

komend wybrane zostały wyłącznie sekwencje komunikacyjne pomiędzy

Strona 17

oprogramowaniem i sprzętem (konfiguracja, transfer danych, obsługa przerwań, itd.).

Opis można znaleźć w standardach USB2.0, USB3.1 oraz specyfikacji interfejsu Intel

xHCI [8].

Dla zarządzania kontrolerem xHC i urządzeniami podłączonych do niego,

standard xHC zapewnia niezależny interfejs Command Ring będący kołową kolejką

struktur danych. Jednostką działania w kolejce Command Ring jest deskryptor

Command Descriptor (CD). Działanie kolejki Command Ring jest podobne do działania

kolejki Transfer Ring, który zarządza transferami danych. Oprogramowanie inicjuje

komendę kontrolera xHC umieszczając deskryptor CD do kolejki Command Ring i

ustawiając odpowiednią flagę w rejestrze Doorbell. Rozmiar kolejki Command Ring

może być zmodyfikowany za pomocą mechanizmu Transfer Request Block (TRB),

który też jest wykorzystywany dla kolejki Transfer Ring.

Wszystkie komendy powodują wprowadzenie deskryptora Command Completion

Event (CCE) do kolejki Event Ring, w którym jest zgłoszony stan zakończenia

wykonania komendy.

Komendy są wykonywane przez kontroler xHC w takiej kolejności, w jakiej

zostały umieszczone w kolejce Command Ring. Oprogramowanie systemowe może

dodawać deskryptory CD do kolejki Command Ring podczas działania, ale wykonanie

deskryptora CD musi być przerwane jeżeli oprogramowanie żąda wykasowania albo

zmiany kolejności (na przykład podwyższenie priorytetu) zaplanowanych deskryptorów

CD. Specjalne kontrolne komendy w kolejce Command Ring pozwalają na zatrzymanie

lub przerwanie pracy.

W dalszej części tego rozdziału opisany został algorytm zarządzania kolejką

Transfer Ring w kontrolerze xHC. Działanie kolejki Command Ring jest analogiczne do

działania kolejki Transfer Ring z pewnymi wyjątkami.

Rysunek 3-1 przedstawia schemat zarządzanie wskaźnikami kolejki Transfer

Ring. System sterujący (host), wprowadza elementy do kolejki Transfer Ring z pomocą

wskaźnika Enqueue Pointer, a odbiornik (kontroler xHC) usuwa elementy z kolejki

Transfer Ring z pomocą wskaźnika Dequeue Pointer.

Strona 18

Zmiana wartości pola bitowego Cycle w strukturze TRB wskazuje na lokalizację

wskaźnika Enqueue Pointer w kolejce Transfer Ring, eliminując potrzebę definiowania

dodatkowego fizycznego rejestru Enqueue Pointer. Oprogramowanie wykorzystuje i

utrzymuje własne kopie wskaźników Enqueue Pointer i Dequeue Pointer dla każdej

kolejki Transfer Ring .

Na początku inicjalizacji wskaźniki Enqueue Pointer i Dequeue Pointer wskazują

na adres pierwszej struktury TRB w kolejce Transfer Ring. Wskaźnik Enqueue Pointer

określa lokalizację następnego elementu roboczego w kolejce Transfer Ring.

Oprogramowanie przesuwa swoją kopię wskaźnika Enqueue Pointer przez zwiększenie

o wielkość struktury TRB.

Kontroler xHC również utrzymuje własne kopie wskaźników Enqueue Pointer i

Dequeue Pointer dla każdej kolejki Transfer Ring. Kontroler wykorzystuje wskaźnik

Dequeue Pointer, żeby określić skąd pobrać następny element roboczy z kolejki

Transfer Ring. Kontroler xHC przesuwa swoją kopię wskaźnika Dequeue Pointer przez

zwiększenie o wielkość struktury TRB.

Kontroler xHC stosuje kolejkę Event Ring dla zgłoszenia aktualnej wartości

wskaźnika Dequeue Pointer do oprogramowania systemowego. Każde zdarzenie

Strona 19

Rysunek 3-1: Zarządzanie wskaźnikami kolejki Transfer Ring [8]

transferu umieszczonego w kolejce Event Ring wskazuje na strukturę TRB, która go

wygenerowała. Oprogramowanie interpretuje wartość wskaźnika z najpóźniejszego

zdarzenia transferu jako wartość bieżącą Dequeue Pointer.

Kontroler xHC wykorzystuje wskaźnik Enqueue Pointer żeby określić czy kolejka

Transfer Ring jest pusta. Po pobraniu struktury TRB z kolejki Transfer Ring kontroler

xHC sprawdza, czy bit Cycle został zmieniony. Jeśli wykryto przejście od „0” do „1”

albo od „1” do „0” – kolejka Transfer Ring jest pusta.

Oprogramowanie wykorzystuje wskaźnik Dequeue Pointer żeby określić kiedy

kolejka Transfer Ring jest pełna. Po obróbce zdarzenia transferu kopia wskaźnika

Dequeue Pointer zostaje aktualizowana wartością pola wskaźnika w strukturze TRB

zdarzenia transferu. Jeśli następny wskaźnik Enqueue Pointer będzie równy Dequeue

Pointer to znaczy że kolejka Transfer Ring jest pełna i oprogramowanie musi czekać na

zdarzenie transferu które przesunie wskaźnik Dequeue Pointer.

Wskaźnik Enqueue Pointer jest zarządzany przez producenta (oprogramowanie), a

wskaźnik Dequeue Pointer – przez konsumenta (kontroler xHC). Producent zachowuje

flagę Producer Cycle State (PCS), która oznacza wartość przeznaczoną do zapisania do

bitu Cycle w strukturze TRB. Konsument zachowuje flagę Consumer Cycle State

(CCS), którą porównuje do bitu Cycle w strukturze TRB pobieranego z pamięci. Jeśli

flaga CCS jest równa wartości bitu Cycle w strukturze TRB to konsument ma prawo

przetwarzać strukturę TRB na którą wskazuje Dequeue Pointer. Jeśli flaga CCS nie jest

równa wartości bitu Cycle w strukturze TRB to konsument musi zatrzymać

przetwarzanie struktury TRB i czekać na następne uruchomienie przetwarzania.

Wyjątki dla kolejki Command Ring:

• Jeśli rejestr Command Ring Control Register (CRCR) jest zapisywany podczas

gdy kolejka Command Ring jest zatrzymana, kontroler xHC musi inicjalizować

wskaźnik Dequeue Pointer dla kolejki Command Ring wartością pola wskaźnika

Command Ring Pointer.

• Gdy rejestr Doorbell jest zapisywany oprogramowaniem systemowym, kontroler

xHC musi zacząć przetwarzać strukturę Command TRB na którą wskazuje

wskaźnik Dequeue Pointer. Kontroler xHC przetwarza strukturę Command TRB

inkrementując wskaźnik Dequeue Pointer do momentu gdy kolejka Command

Ring jest pusta.

Strona 20

• Położenie wskaźnika Dequeue Pointer dla kolejki Command Ring jest zgłaszane

przez kolejkę Event Ring.

Pozostałe aspekty zarządzania kolejką Command Ring są identyczne z tymi, które

są opisane dla kolejki Transfer Ring.

Krótki opis struktury TRB jest pokazany na Rysunku 3-2.

Struktura TRB składa się z 3 podstawowych elementów: Parameter, Status i

Control.

Transmisja pakietów pomiędzy hostem, a urządzeniem odbywa się za

pośrednictwem warstwy Link Layer [8].

3.3. Opis rozwiązania

UCS jest osobnym modułem typu „master” który może być stosowany w

systemach SoC do zapisu oraz odczytu danych do/z rejestrów wewnętrznych modułów

typu „slave” (wysyłanie komend z modułu UCS). Może być zastosowany do

zmniejszenia obciążenia interfejsu zewnętrznego w systemie.

Zaplanowane komendy są zapisywane do pamięci przez sterownik interfejsu.

Następnie sterownik interfejsu inicjuje wysyłanie poleceń do kolejnych modułów slave.

Po zakończeniu operacji UCS pozostaje w stanie nieaktywnym do momentu, gdy

sterownik interfejsu zainicjuje kolejną sesję lub stworzy nową.

Mechanizm jest podobny do scatter-gather lub wektorowego DMA.

Typowe bloki funkcjonalne w systemie SoC to: magistrala systemowa, moduły

slave i master, sterowniki interfejsów oraz zewnętrzny interfejs który jest podłączony do

innego systemu wysyłającego komendy, dane oraz odbierającego i analizującego

otrzymane informacje.

System z kilkoma modułami master jest pokazany na Rysunku 3-3. Blok

Wishbone Serial Bus musi zawierać dekoder adresu oraz arbiter dla pracy z kilkoma

Strona 21

Rysunek 3-2: Szablon struktury TRB [8]

modułami master. W tym przypadku moduł UCS może zapisywać oraz odczytywać

dane z rejestrów dwóch kontrolerów GPIO jak również działać w systemie z innym

modułem master – kontrolerem DMA. Komendy są wysyłane do Pamięci komend w

module UCS przez zewnętrzny system za pośrednictwem interfejsu UART, który jest

podłączony do sterownika UART z interfejsem Wishbone Master.

Inny przykład systemu z module UCS jest pokazany na Rysunku 3-4 . W tym

przypadku moduł UCS jest wykorzystywany jako most pomiędzy dwoma magistralami

Wishbone. Dwie magistrale mogą operować jednocześnie (przykład: sterownik Ethernet

wysyła komendę do sterownika USB i jednocześnie moduł UCS wysyła komendę do

jednego z kontrolerów GPIO). W takim zastosowaniu działanie jest podobne do

systemów wieloprocesorowych, ale główną różnicą jest to że moduł UCS zajmuje mniej

zasobów w układzie FPGA niż rdzeń procesora.

Strona 22

Rysunek 3-3: Przykład systemu z modułem UCS

Metoda scatter-gather która jest wykorzystana w sposobie działania modułu UCS

jest bardzo elastyczna. Pozwala ona nie tylko zdefiniować sekwencje często używanych

komend, ale również cały algorytm pracy poprzez różne kombinację wskaźników w

Zestawie rejestrów.

Strona 23

Rysunek 3-4: Moduł UCS jako most

Strona 24

4. Implementacja rozwiązania

Moduł UCS został zaprojektowany i opisany w języku opisu sprzętu VHDL.

Techniki które wykorzystano przy projektowaniu to:

• Opis behawioralny każdego podmodułu.

• Opis strukturalny całego modułu UCS.

• Weryfikacja funkcjonalna w środowisku testowym napisanym w języku VHDL.

Symulację układu przeprowadzono z pomocą symulatorów ModelSim oraz

ISim.

• Weryfikacja sprzętowa za pomocą płyt Xilinx Spartan-3AN Starter Kit oraz

Atlys Spartan-6 Design Platform.

Projektowanie odbywało się ramach podejścia top-bottom (najpierw został

zaimplementowany moduł główny, a później poszczególne podmoduły).

4.1. Wybór interfejsów

Przed implementacją przeprowadzono badanie najbardziej popularnych

dostępnych standardów magistrali, które mogą być wykorzystane w module UCS. Do

zbadania zostały wybrane 3 magistrale:

1. Advanced Extensible Interface 4.0 (AXI4.0) [9].

2. Open Core Protocol 3.0 (OCP3.0) [10].

3. Wishbone [11].

Wszystkie 3 standardy są dobrze udokumentowane.

Zaletą standardów OCP i AXI jest to, że są one wspierane i rozwijane przez firmy

Accelera i ARM, co zapewnia zwiększenie funkcjonalności i ułatwienie implementacji.

Wadą jest to, że są to standardy zamknięte i dostęp do dokumentacji jest ograniczony.

Zaletą standardu Wishbone jest to, że on jest otwarty i dokumentacja jest dostępna

bez żadnych ograniczeń. Standard jest rozwijany przez organizację OpenCores

wykorzystywany w dużej liczbie projektów związanych z systemami SoC.

Z powodów wymienionych powyżej wszystkie interfejsy komunikacyjne modułu

UCS zostały zaprojektowane zgodnie ze standardem Wishbone.

W systemie z interfejsami innymi niż Wishbone, moduł UCS można podłączyć za

pomocą wrapperów. Rysunek 4-1 pokazuje, jak sterownik Ethernet z interfejsem OCP

może komunikować się z magistralą systemową AXI za pośrednictwem modułu UCS z

Strona 25

interfejsami Wishbone.

4.2. Model sprzętowy

4.2.1. Schemat blokowy

Schemat blokowy modułu UCS jest pokazany na Rysunku 4-2.

Moduł UCS zawiera 7 bloków funkcjonalnych: Interfejs Wishbone Slave, Interfejs

Wishbone Master, Interfejs Wishbone Slave dla God Mode (WSGM), Rdzeń UCS,

Zestaw rejestrów, Pamięć komend i Pamięć danych.

Strona 26

Rysunek 4-1: Wrappery w systemie z UCS

Interfejs Wishbone Slave, Master i WSGM są zgodne ze standardem magistrali

Wishbone (wersja B4) [11].

Rdzeń UCS jest głównym blokiem operacyjnym który zarządza przetwarzaniem

komend, inicjalizacją i działaniem po resecie. Blok ten zarządza także ścieżką danych

od interfejsu slave do master przy działaniu w trybie God Mode.

Zestaw rejestrów zawiera flagi i niezbędne dane dla inicjalizacji i działania.

Pamięć komend zawiera deskryptory Command Unit (CU) które muszą być

wysłane do interfejsu master.

Pamięć danych zawiera dane które zostały otrzymane od modułów slave podczas

przetwarzania deskryptora CU z komendą odczytu.

Strona 27

Rysunek 4-2: Schemat blokowy modułu UCS

4.2.2. Opis interfejsów

Charakterystyki Interfejsu Wishbone Slave oraz Interfejsu WSGM:

• 8-bitowa linia danych.

• 8-bitowa linia adresu.

• Operacje pojedynczego zapisu i pojedynczego odczytu.

• Reset synchroniczny.

Charakterystyki Interfejsu Wishbone Master:

• 8-bitowa linia danych.

• 8-bitowa linia adresu.

• Operacje pojedynczego zapisu i pojedynczego odczytu.

• Reset synchroniczny.

• Brak rozwiązywania przy blokadzie linii ack przez moduł slave (ustawienie

stałego wartości „1” na linii).

4.2.3. Pamięć komend

Moduł UCS ma 96-bajtową Pamięć komend która może zawierać 32 deskryptory

CU (3 bajty każdy). Dostęp do pamięci zapewniają pola rejestrowe CUMA.CUMA,

CUO.CUO, CUAC.CUAC. CUDC.CUDC i flagi FLAGS.WCMD, FLAGS.RCMD.

4.2.4. Pamięć danych

Pamięć danych w module UCS jest zaimplementowana w formie kolejki FIFO i

może zawierać 32 8-bitowe słowa danych. Danę mogą być przeczytane po kolei z pola

rejestrowego DMD.DMD.

4.2.5. Zestaw rejestrów

Moduł UCS zawiera 15-bajtowy Zestaw rejestrów z 15 8-bitowymi rejestrami.

Dostęp do rejestrów zapewnia Interfejs Wishbone Slave.

4.2.6. Rdzeń UCS

Rdzeń UCS wykonuje przetwarzanie zbiorów deskryptorów CU – Command

Set (CS).

Strona 28

4.3. Zasady działania

4.3.1. Konfiguracja

Konfiguracja modułu UCS składa się z zapisu zestawów deskryptorów CS do

Pamięci komend i zapisu adresów bazowych zestawów deskryptorów CS do

odpowiednich rejestrów CSx (tworzenie przestrzeni wektorowej CS), jak jest pokazane

na Rysunku 4-3.

Zapis deskryptorów CU do Pamięci komend składa się z następujących etapów:

1. Zapis adresu deskryptora CU w Pamięci komend do rejestru CUMA.

2. Zapis pola OPTIONS w deskryptorze CU do rejestru CUO.

3. Zapis adresu rejestru wewnętrznego modułu slave (pole ADDRESS w

deskryptorze CU) do rejestru CUAC.

Strona 29

Rysunek 4-3: Konfiguracja modułu UCS

4. Zapis danych które muszą być wysłane w przypadku komendy zapisu do

modułu slave (pole DATA w deskryptorze CU) do rejestru CUDC.

5. Ustawienie flagi FLAGS.WCMD i oczekiwanie na moment zanegowania flagi

przez sprzęt. Kiedy flaga zostaje zanegowana to znaczy, że komenda zapisu

deskryptora do Pamięci komend została wykonana.

Zapis deskryptorów Control CU (CCU) do Pamięci komend składa się z

następujących etapów:

1. Zapis adresu deskryptora CCU w Pamięci komend do rejestru CUMA.

2. Zapis pola OPTIONS w deskryptorze CCU do rejestru CUO.

3. Zapis dolnych 8 bitów licznika CS (pole COUNT0 w deskryptorze CCU) do

rejestru CUAC.

4. Zapis górnych 8 bitów licznika CS (pole COUNT1 w deskryptorze CCU) do

rejestru CUDC.

5. Ustawienie flagi FLAGS.WCMD i oczekiwanie na moment zanegowania flagi

przez sprzęt. Kiedy flaga zostaje zanegowana to znaczy, że komenda zapisu

deskryptora do Pamięci komend została wykonana.

Uwaga: Każdy zestaw deskryptorów CS musi mieć deskryptor CCU pod ostatnim

adresem. Wskazuje on na koniec iteracji przetwarzania zestawu CS.

Kiedy wszystkie zestawy CS zostały załadowane do Pamięci komend, adres

bazowy zestawu CS musi być zapisany do odpowiedniego rejestru Csx.

4.3.2. Uruchomienie przetwarzania

Po zakończeniu etapu inicjalizacji (Pamięć komend została uzupełniona

deskryptorami i wektor adresów bazowych zestawów deskryptorów CS został

skonfigurowany) przetwarzanie może być uruchomione.

Rysunek 4-4 przedstawia przykład uruchamiania przetwarzania zestawu

deskryptorów CS.

Przetwarzanie zaczyna się od ustawiania odpowiedniej flagi DOORBELL.CSBx.

Każda flaga DOORBELL odpowiada adresowi bazowemu zestawu CS w rejestrach

CSx (przykład: ustawienie flagi DOORBELL.CSB7 uruchamia przetwarzanie zestawu

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

rejestrów GPIO_TRI każdego modułu GPIO)

Program emuluje podwójny licznik modulo 16 (dwa liczniki modulo 16) zapisując

do rejestru GPIO_DATA każdego modułu GPIO wartości od 0 do 15.

5.2. Obliczenia teoretyczne

Obliczenia zostały przeprowadzone w środowisku Matlab.

f =50 MHz – częstotliwość zegara systemowego.

t rw – czas operacji zapisu/odczytu (4 cykle zegara) na magistrali Wishbone.

t rw=4f

(5-1)

Strona 38

f uart=115200 bit /s – szybkość transmisji danych.

tuart – czas transmisji 10 bitów danych przez port UART (1 start-bit, 8 bitów danych,

1 stop-bit).

tuart=10f uart

(5-2)

t reg – czas zapisu/odczytu 8-bitowego rejestru z 8-bitowym adresem (2 cykle

zapisu/odczytu, 2 cykle transmisji – adres oraz dane)

t reg=2(trw+t uart) (5-3)

t noucsteor – czas wykonania jednego cyklu dwóch liczników modulo 16 (2 zapisy do

rejestrów przy inicjalizacji oraz 32 zapisy wartości do portów wyjściowych GPIO).

N – liczba cykli podwójnego licznika modulo 16.

t noucsteor=32 t reg⋅N+2t reg (5-4)

Ustawienie modułu UCS w tryb God Mode pomijany jest przy obliczeniach

czasu, aby oszacować czas działania systemu bez modułu UCS.

Podstawienie wartości:

Do (5-1): t rw=4

50000000=8⋅10−8

(s)

Do (5-2): tuart=10

115200≈8.68⋅10−5

(s)

Do (5-3): t reg=2(8⋅10−8+8,68⋅10−5

)=1,74⋅10−4(s)

Do (5-4): t noucsteor=32⋅1,74⋅10−4⋅N+2⋅1,74⋅10−4

=5,57⋅10−3⋅N+3,48⋅10−4

Jak widać ze wzoru (5-4) czas wykonania programu liniowo narasta w zależności

od liczby cykli podwójnego licznika.

Dla obliczenia czasu trwania testów z modułem UCS w trybie z wyłączonym God

Mode jest potrzebny czas zapisu deskryptorów komend ( t cmd ) do Pamięci komend.

Dla zapisu deskryptora CU do Pamięci komend jest potrzebne 5 zapisów do rejestrów:

1. Zapis do rejestru CUMA.

2. Zapis do rejestru CUO.

3. Zapis do rejestru CUAC.

4. Zapis do rejestru CUDC.

Strona 39

5. Ustawienie flagi FLAGS.WCMD na „1”.

t cmd=5 t reg (5-5)

Żeby oszacować czas jednej iteracji testu ( tucsteor ) trzeba dodać czas trwania 6

zapisów do rejestrów ( t reg ), 33 zapisów do Pamięci komend ( t cmd ) (włącznie z

zapisem deskryptora CCU na końcu zestawu CS) oraz czas 32⋅N operacji zapisu na

magistrali systemowej ( t rw ).

tucsteor=32t rw⋅N+6 treg+33 t cmd (5-6)


Do (5-5): t cmd=5⋅1,74⋅10−4=8,67⋅10−4

(s )

Do (5-6): tucsteor=32⋅8⋅10−8⋅N+6⋅1,74⋅10−4

+33⋅8,7⋅10−4=2,56⋅10−6

⋅N+2,98⋅10−2

Jak widać ze wzoru (5-6) czas wykonania programu liniowo narasta w zależności

od liczby cykli podwójnego licznika.

Porównując teoretyczny czas przy działaniu systemu z modułem UCS oraz bez:

μteor=t noucsteor

t ucsteor

=5,57⋅10−3

⋅N+3,48⋅10−4

2,56⋅10−6⋅N+2,98⋅10−2 (5-7)

Powyższy wzór (5-7) dla μteor świadczy o tym, że wraz ze zwiększeniem liczby

powtarzających się operacji szybkość działania wzrasta prawie liniowo.

5.3. Porównanie wyników

Na Rysunku 5-2 są pokazane zmierzone eksperymentalne wartości czasu

wykonania 100 testów z liczbą cykli podwójnego licznika od 1 do 100. Niebieską linią

jest zaznaczony czas działania zmierzony w systemie bez modułuUCS ( t noucs ).

Czerwoną linią – czas zmierzony przy przeprowadzeniu testu w systemie z modułem

UCS ( tucs ).

Strona 40

Na wykresie prawie nie widać nachylenia linii wykresu czasu działania systemu z

modułem UCS. Jest to spowodowane tym, że czas operacji zapisu na magistrali

systemowej ( t rw ) jest znacznie mniejszy od czasu transmisji danych przez port

UART.

Można zauważyć, że przy wartościach N od 1 do 5 konfiguracja systemu z

modułem UCS działa wolniej. Jest to spowodowane tym, że zapisów do rejestrów przez

port UART (czas których jest stosunkowo duży) jest więcej dla konfiguracji z modułem

UCS dla tych wartości N .

Strona 41

Rysunek 5-2: Porównanie wyników w systemie bez modułu UCS oraz z modułem UCS

Na Rysunku 5-3 jest pokazana zależność zwiększenia szybkości od liczby iteracji

N . Niebieską linią jest pokazana charakterystyka teoretyczna, czerwoną – zmierzona

w sprzęcie.

W Tablicy 5-2 są pokazane wybrane wartości dla porównania zwiększenia

szybkości w zależności od liczby iteracji.

Strona 42

Rysunek 5-3: Zależności zwiększenia szybkości działania systemu od liczby iteracji w systemie z portemUART

Tablica 5-2: Porównanie zwiększenia szybkości dla wybranych wartości liczby iteracji

N μteor μexp

1 0,21 0,21

10 1,89 1,84

20 3,76 4,04

30 5,62 6,09

40 7,48 7,65

50 9,34 9,65

60 11,19 11,19

70 13,04 12,77

80 14,89 15,18

90 16,74 17,27

100 18,58 20,05

Im większa liczba iteracji tym większy stosunek czasu działania systemu bez

modułu UCS do czasu działania systemu z modułem UCS.

Strona 43

Strona 44

6. Testowanie z portem Ethernet

6.1. Opis systemu testowego

Na Rysunku 6-1 jest pokazany system testowy. System był syntezowany na płycie

Atlys Spartan-6 Design Platform [14].

Do testowania zostały przeanalizowane dwa sterowniki interfejsu Ethernet:

„fade”, opisany w [15] oraz IPbus opisany w [16]. Został wybrany sterownik IPbus ze

względu na wygodę użycia.

System testowy ma na celu sprawdzić działanie UCS przy sterowaniu systemu

przez magistralę szeregową szybszą od zegara systemowego.

Strona 45

Strona 46

Rysunek 6-1: Układ testowy wykorzystujący port Ethernet

Opis systemu testowego z portem Ethernet:

• Częstotliwość zegara systemowego – 125 MHz.

• Moduł Wishbone Interconnect 1 z dekoderem adresu dla maksymalnie czterech

modułów slave, do którego są podłączone:

◦ Moduł slave GPIO0 z 8-bitowymi rejestrami podłączony do czterech diod

LED.

◦ Sterownik Ethernet IPbus jako master. Szybkość transmisji – 1 Gbit/s.

◦ Moduł UCS podłączony przez Interfejs Wishbone slave oraz WSGM.

• Moduł Wishbone Interconnect 2 z dekoderem adresu dla maksymalnie czterech

modułów slave, do którego są podłączone:

◦ Moduł slave GPIO1 z 8-bitowymi rejestrami podłączony do czterech diod

LED.

◦ Moduł UCS jako master.

Mapy adresowe są pokazane w Tablicy 6-1 oraz 6-2. Struktura modułu Wishbone

Interconnect jest opisana w [11].

Tablica 6-1: Mapa adresowa dekodera adresu modułu Wishbone Interconnect 1

Moduł Slave Adres

GPIO0 00h – 01h

UCS (interfejs Wishbone slave) 10h – 1Eh

UCS (interfejs WSGM) 20h

Tablica 6-2: Mapa adresowa dekodera adresu modułu Wishbone Interconnect 2

Moduł Slave Adres

GPIO1 00h – 01h

Program sterujący został napisany języku C++ z pomocą bibliotek

uHAL v2.3.3 [17], skompilowany 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

rejestrów GPIO_TRI każdego modułu GPIO)

Strona 47

Program emuluje podwójny licznik modulo 16 (dwa liczniki modulo 16) zapisując

do rejestru GPIO_DATA każdego modułu GPIO wartości od 0 do 15.

6.2. Obliczenia teoretyczne

Ze względu na to, że program testujący jest napisany w języku C++, który

wspiera wielowątkowość oraz wykorzystywany standard do transmisji danych, który

zawiera kilka warstw protokołu, trudno jest szacować dokładny czas teoretyczny pracy

systemu z modułem UCS oraz bez.

Żeby wyeliminować maksymalną liczbę błędów oceniono zwiększenie szybkości

wykonania w zależności od liczby iteracji N .

Obliczenia zostały przeprowadzone w środowisku Matlab.

f =125 MHz – częstotliwość zegara systemowego.

t reg – czas operacji zapisu/odczytu (4 cykle zegara) na magistrali Wishbone oraz

IPbus.

t reg=4f

(6-1)

Ustawienie modułu UCS w tryb God Mode jest pomijane przy obliczeniach czasu,

aby oszacować czas działania systemu bez UCS.

t noucsteor – czas wykonania jednego cyklu dwóch liczników modulo 16 (4 zapisy do

rejestrów przy inicjalizacji oraz 32 zapisy wartości do portów wyjściowych kontrolera

GPIO) w systemie bez modułu UCS.

t noucsteor=32 t reg⋅N+2t reg (6-2)

t cmd – czas zapisu deskryptorów komend do Pamięci komend.

t cmd=5 t reg (6-3)

tucsteor – czas wykonania jednego cyklu dwóch liczników modulo 16 (6 zapisów do

rejestrów przy inicjalizacji, 16 zapisów deskryptorów CU do Pamięci komend, 1 zapis

deskryptora CCU do Pamięci komend oraz32⋅N

2zapisów wartości (2 równoległe

cykli licznika) do portów wyjściowych kontrolera GPIO w systemie z modułem UCS.

Strona 48

tucsteor=6 treg+17 t cmd+(16 t reg+16 t reg

2)⋅N=16 treg⋅N+91 t reg (6-4)

μteor – zwiększenie szybkości działania w zależności od liczby iteracji N .

μteor=t noucsteor

t ucsteor

=32 t reg⋅N+2t reg

16 t reg⋅N+91t reg(6-5)


Do (6-1): t reg=4

150⋅106=3,2⋅10−8

Do (6-5): μ teor=32⋅3,2⋅10−8

⋅N+2⋅3,2⋅10−8

16⋅3,2⋅10−8⋅N+91⋅3,2⋅10−8 =

102,4⋅N+6,451,2⋅N+291,2

6.3. Porównanie wyników

Na Rysunku 6-2 są pokazane zmierzone eksperymentalne wartości czasu

wykonania 1000 iteracji z liczbą cykli podwójnego licznika od 1 do 1000. Niebieską

linią jest zaznaczony czas działania zmierzony w systemie bez modułu UCS ( t noucs ).

Czerwoną linią – czas zmierzony przy przeprowadzeniu testu w systemie z UCS

( tucs ).

Strona 49

Na Rysunku 6-3 są pokazane zależności zwiększenia szybkości działania systemu

od liczby iteracji. Niebieską linią jest pokazana charakterystyka teoretyczna,

czerwoną – zmierzona w sprzęcie.

Strona 50

Rysunek 6-2: Zmierzone eksperymentalne wartości czasu wykonania w systemie z portem Ethernet

Ze względu na to że przy wywołaniu funkcji systemowych oraz bibliotek dla

pracy z portem Ethernet system operacyjny przeprowadza optymalizację

(wielowątkowość, przetwarzanie pakietów) na Rysunku 6-2 oraz 6-3 widać skoki.

W Tablicy 6-3 są pokazane wybrane wartości dla porównania zwiększenia

szybkości w zależności od liczby iteracji.

Strona 51

Rysunek 6-3: Zależności zwiększenia szybkości działania systemu od liczby iteracji w systemie z portemEthernet

Tablica 6-3: Porównanie zwiększenia szybkości dla wybranych wartości liczby iteracji

N μ teor μexp

1 0,32 0,4

100 1,89 2,1

200 1,95 1,9

300 1,96 2,44

400 1,97 2,09

500 1,98 1,94

600 1,98 2,63

700 1,98 1,84

800 1,98 1,3

900 1,99 1,5

1000 1,99 1,84

Przy małej liczbie iteracji eksperymentalne zwiększenie szybkości jest mniejsze

niż jeden. Spowodowane jest to większą liczbą operacji inicjalizacji (włączenie i

wyłączenie trybu God Mode, zapis deskryptorów do Pamięci komend) w systemie z

modułem UCS, niż w systemie bez modułu UCS.

Przy większej liczbie iteracji zwiększenie szybkości osiąga stałą wartość i zależy

od poziomu zrównoleglenia (liczby równoległych procesów) w systemie.

Strona 52

7. Kierunki dalszych prac

Przedstawiona w pracy wersja modułu UCS ma kilka wad, które można poprawić

za pomocą następujących metod:

1. Rozszerzenie szerokości słowa do 32 bitów (linia adresu oraz danych, słowa

Pamięci komend i Pamięci danych, długość rejestrów).

Pozwoli to na zwiększenie wektora adresów CSx oraz na dodatkowe możliwości

zmniejszenia czasu zapisu/odczytu deskryptorów z Pamięci komend.

2. Implementacja trybu Burst w Interfejsie Wishbone Slave [11].

Przy wykonaniu komend odczytów rejestrów modułów slave jest niezbędne

odczytanie jednego rejestru DMD, co nie powoduje zwiększenia szybkości wykonania

operacji odczytu. Tryb Burst w Interfejsie Wishbone Slave pozwoli na odczytanie całej

Pamięci danych naraz.

Tryb ten jest też korzystny dla szybkiego zapisywania/odczytywania

deskryptorów CU z Pamięci komend, inicjalizacji wektora adresów CSx w Zestawie

rejestrów.

3. Implementacja trybu Burst w Interfejsie Wishbone Master [11].

Pozwoli na wczytanie dużej ilości danych do Pamięci danych z modułów slave,

które wspierają tryb Burst.

4. Używanie mechanizmu Tag w Interfejsie Wishbone Slave [11].

Wyeliminuje potrzebę używania Interfejsu WSGM oraz potrzebę zarezerwowania

dodatkowego adresu w systemie dla modułu UCS podłączonego przez Interfejs WSGM.

5. Używanie mechanizmów kompresji/dekompresji.

Pozwoli na dodatkowe zmniejszenie ilości informacji przesyłanej przez

zewnętrzny interfejs.

6. Optymalizacja wykorzystania zasobów układu FPGA.

Pozwoli na zmniejszenie zużycia zasobów przez moduł UCS w układzie FPGA.

Strona 53

Strona 54

8. Podsumowanie

W pracy przeprowadzono badanie systemów sterowanych przez interfejs

zewnętrzny. Zbadano najczęściej używane komendy wysyłane do popularnych

modułów systemowych w układach FPGA oraz jedno z rozwiązań w kontrolerze

USB3.1 – xHC.

Dla zwiększenia szybkości wysyłania komend do modułów zrealizowanych w

układach FPGA zostało zaproponowane rozwiązanie uniwersalnego modułu

funkcjonalnego – UCS. Zaprojektowano całą syntezowalną architekturę urządzenia oraz

sprawdzono poprawność jego działania za pomocą weryfikacji funkcjonalnej. Testy

przeprowadzone za pomocą symulatorów ModelSim oraz ISim zapewniają maksymalne

pokrycie funkcjonalności modułu UCS. Testy w symulatorach nie wykazały błędów.

Zaprojektowano systemy testowe które zostały zrealizowane w układzie FPGA:

system z interfejsem zewnętrznym wolniejszym od zegara systemowego oraz system z

interfejsem szybszym od zegara systemowego. Dla przykładowych systemów obliczono

teoretyczną funkcję zwiększenia czasu działania w zależności od różnych wartości

liczby iteracji. Następnie przeprowadzono testowanie systemów w sprzęcie za pomocą

płyty Spartan-3AN Starter Kit oraz Atlys Spartan-6 Design Platform i porównano

wyniki z teoretycznymi. Porównanie to pokazuje, że obliczenia teoretyczne

przeprowadzono poprawnie.

Zastosowanie modułu UCS w systemach przynosi następujące korzyści:

• Zmniejszenie czasu wykonania często powtarzających się operacji.

• Możliwość zbierania danych do pamięci FIFO i odczytanie ich z tylko jednego

rejestru, a nie z wielu rejestrów modułów w systemie (znacznie upraszcza

program sterujący).

• Możliwość planowania operacji z pomocą wektorów adresowych i ich

kombinacji (metoda scatter-gather).

• Możliwość dynamicznego wyłączenia modułu UCS z pomocą trybu God Mode

(przy wykonaniu rzadko powtarzających się komend).

Teoretyczne obliczenia dają podstawy, aby stwierdzić że przy zwiększeniu liczby

powtarzających się operacji zwiększenie szybkości pracy będzie liniowe dla

przykładowego systemu z interfejsem wolniejszym od zegara systemowego. Udało się

osiągnąć zmniejszenie czasu działania w sprzęcie systemu 20,05 razy dla 100 iteracji.

Strona 55

Dla przykładowego systemu z interfejsem szybszym od zegara systemowego

przy zwiększeniu liczby powtarzających się operacji zwiększenie szybkości pracy

będzie stałe. Udało się osiągnąć zmniejszenie czasu działania w sprzęcie

przykładowego systemu 1,89 razy dla 1000 iteracji z pomocą zrównoleglenia zadań

sterownikiem interfejsu oraz modułem UCS.

Dla obu typów interfejsów zewnętrznych udało się zwiększyć szybkość działania

systemu, co pozwala stwierdzić, że cel pracy został osiągnięty.

Strona 56

9. Bibliografia

[1] Spartan-3A/3AN FPGA Starter Kit Board User Guide, Xilinx 2008.

[2] EIA standard RS-232-C: Interface between Data Terminal Equipment and Data

Communication Equipment Employing Serial Binary Data Interchange, Electronic

Industries Association. Engineering Dept. 1969.

[3] LogiCORE IP AXI GPIO v2.0 Product Guide, Xilinx 2014.

[4] AXI Universal Serial Bus (USB) 2.0 Device v5.0 LogiCORE IP Product Guide,

Xilinx 2014.

[5] LogiCORE IP AXI DMA v7.1 Product Guide, Xilinx 2014.

[6] LogiCORE IP AXI SYSMON ADC v2.00a, Xilinx 2011.

[7] LogiCORE IP AXI Timer v2.0 Product Guide, Xilinx 2014.

[8] eXtensible Host Controller Interface for Universal Serial Bus (xHCI) rev1.1, Intel

2013.

[9] AMBA 4 AXI and ACE protocol specification, ARM 2011.

[10] Open Core Protocol v3.0 Specification, Accellera 2009.

[11] WISHBONE SoC Interconnection Architecture for Portable IP Cores vB4,

OpenCores 2010.

[12] VHDL Testbench Techniques that Leapfrog SystemVerilog, SynthWorks 2013.

[13] Peter Bennett: VHDL UART, https://github.com/pabennett/uart, czerwiec 2013.

[14] Atlys Board Reference Manual, Digilent 2013.

[15] Wojciech M. Zabołotny: Optimized Ethernet transmission of acquired data from

FPGA to embedded system, http://opencores.org/project,fade_ether_protocol,

październik 2013.

[16] C. Ghabrous Larrea, K. Harder, D. Newbold, D. Sankey, A. Rose, A. Thea and

T. Williams: IPbus, a flexible Ethernet-based control system for xTCA hardware,

doi:10.1088/1748-0221/10/02/C02019, luty 2015.

[17] CERN uHAL v2.3.3, https://svnweb.cern.ch/trac/cactus, październik 2014.

Strona 57

Strona 58

Aneks A. Opis portów modułu UCS

Aneks A.1. Porty sterujące

Porty sterujące są pokazane w Tablicy A-1.

Tablicа A-1: Porty sterujące modułu UCS

Nazwaportu

KierunekDługość(bitów)

Stanaktywny

Opis

rst_i wejście 1 wysoki Reset synchroniczny.

clk_i wejście 1zbocze

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


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


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


Wishbone Master która jest pokazana w Tablicy A-3.

Tablicа A-3: Porty Interfejsu Wishbone Master [11]

Nazwaportu


Stanaktywny

Opis

adr_o_m wyjście 8 wysoki

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


Stanaktywny

Opis

cyc_o_m wyjście 1 wysoki


Aneks A.4. Porty Interfejsu WSGM


WSGM która jest pokazana w Tablicy A-4.

Tablicа A-4: Porty Interfejsu WSGM [11]

Nazwaportu


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


Stanaktywny

Opis

cyc_i_s_gm wejście 1 wysoki


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



5 CSB5 W1HC



4 CSB4 W1HC



Strona 68

Numerbitów

Nazwapola

Typdostępu

Opis

3 CSB3 W1HC



2 CSB2 W1HC



1 CSB1 W1HC



0 CSB0 W1HC



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.


7 6 5 4 3 2 1 0

CSA1



Numerbitów

Nazwapola

Typdostępu

Opis

[8:0] CSA1 RW



Strona 70


7 6 5 4 3 2 1 0

CSA2



Numerbitów

Nazwapola

Typdostępu

Opis

[8:0] CSA2 RW




7 6 5 4 3 2 1 0

CSA3



Numerbitów

Nazwapola

Typdostępu

Opis

[8:0] CSA3 RW



Strona 71


7 6 5 4 3 2 1 0

CSA4



Numerbitów

Nazwapola

Typdostępu

Opis

[8:0] CSA4 RW




7 6 5 4 3 2 1 0

CSA5



Numerbitów

Nazwapola

Typdostępu

Opis

[8:0] CSA5 RW



Strona 72


7 6 5 4 3 2 1 0

CSA6



Numerbitów

Nazwapola

Typdostępu

Opis

[8:0] CSA6 RW




7 6 5 4 3 2 1 0

CSA7



Numerbitów

Nazwapola

Typdostępu

Opis

[8:0] CSA7 RW



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.


• 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.


• 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


Interfejsie Wishbone Slave w module UCS. Główne etapy:


• 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.


• 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]


• 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”.


Interfejsie WSGM w module UCS. Główne etapy:


• 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]



• 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.


• 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.


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:


• 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.


• 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,


• Moduł UCS sprawdza linie ack_i_m i przygotowuje się do zakończenia cyklu.


• 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


Interfejsie Wishbone Slave w module UCS. Główne etapy:


• 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.



• 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,


• 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]


• 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”.


Interfejsie WSGM w module UCS. Główne etapy:


• 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]



• 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.


• 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.


stb_i_s_gm na „0”.

Strona 89

Rуsunek D-7: Cykl pojedynczego zapisu na Interfejsie WSGM w module UCS [11]

Strona 90

ievgenii drozdov

Documents