Platformy oraz języki HLL dla systemów HPRC Katedra Elektroniki – Seminarium www.agh.edu.pl.

Prezentacja na temat: "Platformy oraz języki HLL dla systemów HPRC Katedra Elektroniki – Seminarium www.agh.edu.pl."— Zapis prezentacji:

1 Platformy oraz języki HLL dla systemów HPRC Katedra Elektroniki – Seminarium www.agh.edu.pl

2 Plan prezentacji Systemy HPRC Platformy Języki HLL Język Impulse C Podsumowanie Przykłady aplikacji www.agh.edu.pl

3 Wprowadzenie www.agh.edu.pl GPGPUs Floating Point FPGAs Non-Floating Point Many-core CPUs Command & Control

4 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

5 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

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

7 Platformy HPRC

8 SGI RASC

9

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

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

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

13 Parallela – klaster

14 Profilowanie kodu

15 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

16 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

17 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 18 HLL/HLS Handel-C Catapult C SystemC Języki HLL OpenCL

19 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

20 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

21 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.13. 21 Język impulse C

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

23 Wsparcie w postaci PSP (Platform Support Package):

24 Impulse C – model programistyczny

25 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

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

27 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

28 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

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

30 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

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

32 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

33 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

34 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

35 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

36 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

37 Typy danych 37

38 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

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

40 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

41 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

42 Funkcje Przykład – funkcja kombinacyjna: 42

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

44 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

45 Funkcje Przykład – funkcja potokowa 45

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

47 Funkcje 47

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

49 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

50 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

51 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

52

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

54 Implementacja modułu oceny jakości Video

55 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).

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

57 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

58 Dziękuje!

59

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