Platformy oraz języki HLL dla systemów HPRC Katedra Elektroniki – Seminarium

Plan prezentacji Systemy HPRC Platformy Języki HLL Język Impulse C Podsumowanie Przykłady aplikacji

Wprowadzenie GPGPUs Floating Point FPGAs Non-Floating Point Many-core CPUs Command & Control

Systemy HPRC - High Performance Reconfigurable Computing Interface  P memory  P memory... PP PP I/O Interface FPGA memory FPGA memory... FPGA... I/O Microprocessor systemReconfigurable system

Systemy HPRC - High Performance Reconfigurable Computing Droga energia elektryczna Rosnące zasoby układów FPGA Wzrost dominacji obliczeń równoległych Arbitralnie dobierana precyzja obliczeń (Approximate computing) Czas odpowiedzi systemu jest dominujący np. HFT (algorithmic trading), Software- define networking

HPRC – platformy P rocessor + FPGA: FPGA on a peripheral card FPGA ↔ CPU point2point FPGA ↔ CPU via memory 6

Platformy HPRC

SGI RASC

PICO-M503 pico-v6 server –M-503 board –2 x Virtex-6 LX240 –2 x 4 GB DDR3 SODIMM –x8 Gen2 PCI-E 10

DRC AC2020 DRC server –AC2020 model –Virtex-5 LX220 –2 GB DDR2 –LGA 1207 –HyperTransport Bus komunikacja poprzez HT Bus lub pamięć 11

Parallela – klaster Obecnie brak możliwość zamówienia.

Parallela – klaster

Profilowanie kodu

Wyzwania HPRC System modeling Design partitioning (HW/SW hand-off) Software development (embedded S/W tools) Hardware development (HDL tools) Validation (S/W and H/W tools) Interfaces frozen Software complete Prototype complete Product complete High-level specification Problem 2: Hardware development is a bottleneck Problem 1: HW/SW interfaces must be frozen before hardware design can begin

The Co-Design Approach System modeling Design partitioning Software development (embedded S/W tools) Hardware development (C-to-hardware and HDL tools) Design refinement and testing (S/W and H/W tools) Interfaces frozen Software complete Prototype complete Product complete High-level specification Use software-to-hardware tools along with hardware/software co-design methods The result: Faster time to a working prototype, more time available for design optimization and performance improvements. Wyzwania HPRC

Dlaczego języki HDL nie nadają się dla HPRC  Czasochłonny proces projektowania i debuggowania zaawansowanych systemów  Place-and-route jest często liczony w godzinach dla prostych systemów  Utrudniona przenośność pomiędzy platformami  Przeniesienie może nie być optymalne  Optymalizacja projektu wymaga znajomości odpowiednich technik  Utrudnione porównanie wyników implementacji sprzętowej z oryginalnymi  Pisanie środowiska testowego (testbecha) może zająć więcej niż projektowanie systemu  Programiści HPRC to najczęściej informatycy, którzy nie znają języków opisu sprzętu

18 HLL/HLS Handel-C Catapult C SystemC Języki HLL OpenCL

Język impulse C  Oparty na standardzie ANSI-C  Dostępne jest wiele wzorców projektowych  Połączenie kompilatora gcc oraz Impulse C  Znajduje równoległości w kodzie  Zrównoleglenie pętli i wrowadzenie do nich potokowość  Kompilator Impulse C generuje syntezowalny kod HDL  Generacja interfejsów sprzętowo/programowych (PSP)  Przenośność pomiędzy platformami  Podłączanie zewnętrznych modułów HDL C language applications HDL files HDL files Generate accelerator hardware Generate hardware interfaces Generate software interfaces C software libraries C software libraries FPGA device or platform

Dostępne warianty projektowe w Impulse C Generated Hardware Module Host processor or cluster 1 Embedded Hardware Accelerators Embedde d CPU Core Create a hardware module Accelerate an embedded CPU Accelerate an external/host CPU or computing cluster UsageOption 2 Usage 3 Generated hardware module Generated hardware accelerator FPGA FPGA coprocessor

Genealogia: dr. Maya Gokhale (Los Alamos National Laboratories), lata 90. XX. wieku, na bazie kompilatora Streams-C. Teraźniejszość: Impulse Accelerated Technologies (Bellevue, Washington), 2002 r., Wykorzystuje kompilator SUIF (Stanford Universal Intermediate Format), Ostatnia wersja – 3.70.e Język impulse C

Dlaczego Impulse C? Wsparcie w postaci PSP (Platform Support Package): ALPHA DATA, CRAY, DIGILENT, THE DINI GROUP, DRC COMPUTER, Język impulse C

Wsparcie w postaci PSP (Platform Support Package):

Impulse C – model programistyczny

Model programistyczny Model oparty na procesach Płynna migracja pomiędzy częścią sprzętową oraz programową w ramach zdefiniowanego procesu (pod warunkiem odpowiedniego kodowania) Procesy komunikują się z sobą (np. poprzez strumienie) Każdy proces może być postrzegany jako osobny program (funkcja) Równoległe obliczenia w ramach procesu Zalecana jest minimalizacja liczby cykli dostępu do pamięci zewnętrznej (korzystanie z pamięci lokalnej) Intensywne wykorzystanie strumieni (FIFO), bardziej niż pamięci Wydajność aplikacji zależy w dużym stopniu od kosztów dostępu do pamięci (zagadnienie podziału algorytmu na część programową oraz sprzętową) 25

Model programistyczny Źródło: Dokumentacja CoDeveloper IDE Przykładowy system zbudowany w Impulse C 26

Struktury języka – Process Procesy nie współdzielą pamięci (ale mogą - w gestii programisty) Nie ma możliwości dynamicznej alokacji procesów Na programiście spoczywa konieczność zapewnienia synchronizacji między-procesowej Brak sygnału zegarowego z kodzie Impulse C (untimed), ale w przypadku dołączania zewnętrznych modułów HDL niezbędne jest dostosowanie się do protokołu (uwzględniając sygnał zegarowy) 27

Struktury języka – Process void process_name (first_stream_name, second_stream_name...) {..... } void process_name (first_stream_name, second_stream_name, memory_name...) { int i, offset; uint32 *memData; for ( i = 0; i < MEMORY_SIZE; i++ ) { memData[i] = (co_int32)i;} offset = 0; co_memory_writeblock(mem0, offset, memData, MEMORY_SIZE * sizeof(co_int32)); printf("Running...\n"); co_signal_post(insignal, 0); } Przykład procesu programowego, który realizuje zapis do pamięci. 28

Struktury języka – Process Proces musi zostać osadzony w ramach funkcji konfigurującej. 29

Struktury języka – Stream Implementowane w formie FIFO Jednokierunkowe Podłączane do 2 procesów (tylko!) Strumienie muszą być zamknięte i otwarte przez oba procesy (nie spełnienie tego warunku powoduje zawieszenie działania aplikacji) Proces Strumień Proces

Struktury języka – Stream wyjściowy wejściowy Tworzenie strumienia 31

Struktury języka – Stream Strumienie – zatrzaśnięcie (deadlock): Nieskończone oczekiwanie na dane w procesie Brak mechanizmów analizujących (w gestii programisty) Funkcja co_stream_read_nb odporna na zatrzaśnięcie (cyklicznie sprawdza wyjście → większy koszt czasowy takiej operacji) Stosowanie potokowości (#pragma pipeline) może prowadzić do zatrzaśnięcia, które nie jest wykrywalne podczas symulacji programowej (potokowość nie jest emulowana programowo) 32

Inne struktury języka – Signal Służą zasadniczo do synchronizacji międzyprocesowej (przesyłanie komunikatów) Funkcja nadawcza co_signal_post (nie jest blokowana) Funkcja odbiorcza co_signal_wait (blokowana – oczekuje na dostarczenie informacji), tylko jeden proces może odczytać informacje 33

Inne struktury języka – Register Połączenie bezpośrednie (niebuforowane wyjście) Prawie zawsze stosowane w przypadku implementacji sprzętowej Brak synchronizacji (można zapewnić zewnętrzną np. za pomocą sygnałów) 34

Inne struktury języka – Memory Współdzielona pamięć Obsługa dostępu do pamięci zewnętrznej oraz wewnętrznej Brak automatycznej synchronizacji (może być zrealizowana za pomocą sygnałów) Implementacja pamięci zewnętrznej i jej organizacja zależy od konkretnej platformy obliczeniowej 35

Typy danych Preferowany typ int Dostępne są typy danych o arbitralnie definiowanej szerokości np. co_int32, co_int7 Brak wbudowanego typu zmiennoprzecinkowego (istnieje dedykowana biblioteka – możliwość jej wykorzystania zależy od stosowanej platformy – PSP) Podczas symulacji dane są mapowana na typy obsługiwane przez procesor lokalny (możliwe różne wyniki H-S) Aby zapewnić wierne wyniki symulacji (tożsame z implementacją sprzętową) należy stosować makra (np. UADD5(a,b)), działają one na zasadzie obcięcia wyniku (po wykonaniu rządnej operacji w większej precyzji, dostępnej w ramach danego GPP) 36

Typy danych 37

Funkcje Wymagana jest klauzula co primitive lub co implementation umieszczona na górze ciała funkcji Typem zwracanym może być: – int – FP – void Jako parametr funkcji może zostać podany: – int – FP – wskaźnik do int lub FP – tablica int lub FP Każdy wskaźnik jest traktowany jako we/wy, nawet jeśli jest wykorzystywane w funkcji tylko w jednym trybie – np. zapisu Dostęp do tablic z wykorzystaniem zmiennych globalnych nie jest dozwolony 38

Funkcje Wykorzystanie pragmy CO FLATTEN Standardowa implementacja - FSM (2 clk) Implementacja z wykorzystaniem dyrektywy flatten – generowana jest logika kombinacyjna (1 clk) 39

Funkcje Dołączanie zewnętrznych funkcji sprzętowych Istnieje możliwość dołączania własnych modułów napisanych w VHDL lub Verilog, jak również specjalizowanych IP- core’ów (wygenerowanych poprzez zewnętrzne narzędzia) Zastosowanie klauzuli co implementation informuje kompilator, że kod HDL opisujący daną funkcję zostanie podany z zewnątrz i nie ma potrzeby jego generacji (zostanie on osadzony) Własne moduły należy umieścić w katalogu „userip” 40

Funkcje Kompilator Impulse C wspiera trzy typy zewnętrznie dołączanych funkcji: Kombinacyjne #pragma CO implementation myfunction logic Asynchroniczne (z niedeterministycznym opóźnieniem potokowym) #pragma CO implementation myfunction async Potokowe (o znanej latencji) #pragma CO implementation myfunction pipeline latency=2 Należy znać charakter podłączanego modułu i go podać explicite w definiowanej funkcji sprzętowej. Trzeba zadbać o zgodność szerokości bitowych deklarowanych sygnałów w modułach HDL, jak również o zgodność nazw modułów w C i HDL. 41

Funkcje Przykład – funkcja kombinacyjna: 42

Funkcje Przykład – funkcja kombinacyjna (wyk. wskaźnika): 43

Funkcje W przypadku funkcji potokowych następujące kryteria muszą zostać spełnione: Moduł w HDL musi zostać wyposażony w sygnały: – Reset – Clk – Ce – Zdeklarowane w ramach funkcji wejścia oraz wyjścia Dane wejściowe są dostarczane co takt zegara Dane wyjściowe są dostępne dokładnie po N clk, gdzie N jest wartością opóźnienia potokowego 44

Funkcje Przykład – funkcja potokowa 45

Funkcje Dozwolona jest statyczna rekurencja, pod warunkiem, że liczba zagnieżdżeń może zostać zdeterminowana w czasie kompilacji. 46

Funkcje 47

Możliwości i ograniczenia języka Przykład : 48

Optymalizacja kodu Rozwijanie pętli (pragma unroll) Potokowość (pragma pipeline) Instrukcja bezpośrednia co_int32 hash[4]; co_array_config(hash,co_kind,"register"); Powstają 4 rejestry Instrukcja co_par_break() co set stageDelay 32 ……. 49

Optymalizacja kodu Informacje „Stage Master Explorer” o charakterze logiki: Block type: sequential (logika kombinacyjna) pipeline (logika sekwencyjna) Latency: opóźnienie potokowe całego bloku Rate: przepustowość (ilość cykli zegara/wynik) Max. Unit Delay: maksymalne szacowane opóźnienie pojedynczego etapu potoku (ilość poziomów logiki kombinacyjnej) Effective Rate: (Max. Unit Delay)x(Rate) – może być monitorowane w zakładce „Pipeline Graph” i regulowane poprzez: co_par_break(), #pragma CO set stagedelay 32, #pragma co set defaultdelay im mniejsza wartość (Max. Unit Delay)x(Rate) tym większa efektywna przepustowość Rate x (Max.Unit Delay) = Rate/fclk = efektywna przepustowość 50

Przykłady projektów realizowanych oraz wykonanych w Impulse C Implementacja algorytmu DES Implementacja algorytmu TF-IDF Implementacja generatora liczb pseudolosowych RANLUX Implementacja modułu oceny jakości Video

metryka efektu blokowości metryka stopnia ekspozycji detekcja zaniku obrazu metryka występowania przeplotu

Implementacja modułu oceny jakości Video

Zielona linia wyznacz czas wymagany do działania modułu w czasie rzeczywistym (przy założeniu, że wideo odtwarzane jest z liczbą klatek na sekundę równą 30).

Implementacja modułu oceny jakości Video Korelacja: , softwarowa(czerwony) i hardwarowa (niebieski)

Podsumowanie 57 Dostępne jest obecnie wiele platform HPRC Wykorzystanie języków HLL do projektowania systemów dla HPRC ma szereg zalet Szybkość projektowania Łatwość debuggowania Przenośność kodu

Dziękuje!

Przyczyny powstania HLL – przykład z życia 60 Projekt ORBITAL