Architektura koprocesora: architektura systemu wbudowanego do szybkiego prototypowania

Wyniki empiryczne - analiza przypadku dyskretnej transformaty kosinusowej

Wyniki badań empirycznych nie tylko potwierdziły elastyczność, jaką architektura koprocesorowa oferuje projektantom systemów wbudowanych, ale także wykazały możliwości zwiększenia parametrów działania dostępne dzięki nowoczesnym narzędziom bezpośrednio programowalnych macierzy bramek (FPGA). Ulepszenia, jak te wymienione poniżej, mogą nie być dostępne lub mieć mniejszy wpływ na inne architektury sprzętowe. Dyskretna transformata kosinusowa (DCT) została wybrana jako algorytm wymagający dużych nakładów obliczeniowych, a jej przejście z implementacji opartej na języku C do implementacji opartej na języku opisu sprzętu (HDL) stanowiło sedno tych ustaleń. Wybrano transformatę DCT, ponieważ algorytm ten jest wykorzystywany w cyfrowym przetwarzaniu sygnałów do rozpoznawania wzorów i filtrowania [8]. Wyniki empiryczne zostały oparte na ćwiczeniu laboratoryjnym, które zostało wykonane przez autora i współpracowników w celu uzyskania certyfikatu Xilinx Alliance Partner na lata 2020 - 2021.

W tym celu wykorzystano następujące narzędzia i urządzenia:

• Vivado HLS v2019
• Do oceny i symulacji wykorzystano urządzenie xczu7ev-ffvc1156-2-e

Począwszy od implementacji opartej na języku C, algorytm dyskretnej transformaty kosinusowej (DCT) akceptuje dwie tablice 16-bitowych liczb; tablica „a” jest tablicą wejściową dla transformaty DCT, a tablica „b” jest tablicą wyjściową transformaty DCT. Szerokość danych (DW) jest więc zdefiniowana jako 16, a liczba elementów w tablicach (N) wynosi 1024/DW, czyli 64. I wreszcie rozmiar macierzy transformaty DCT (DCT_SIZE) jest ustawiony na 8, co oznacza, że używana jest macierz 8 x 8.

Zgodnie z założeniami tego artykułu, implementacja algorytmu w języku C pozwala projektantowi na szybki rozwój i walidację funkcjonalności algorytmu. Chociaż jest to ważny czynnik, w tej walidacji funkcjonalność jest ważniejsza niż czas wykonania. Takie ważenie jest dozwolone, ponieważ ostateczna implementacja tego algorytmu będzie działać w macierzy bramek FPGA, gdzie akceleracja sprzętowa, rozwijanie pętli i inne techniki są łatwo dostępne.

Ilustracja 8: Przepływ projektu HLS w programie Xilinx Vivado.

Po utworzeniu kodu dyskretnej transformaty kosinusowej (DCT) w narzędziu Vivado HLS jako projektu, kolejnym krokiem jest rozpoczęcie syntezy projektu do implementacji w macierzy FPGA. To właśnie na tym etapie niektóre z najbardziej znaczących korzyści płynących z przeniesienia wykonywania algorytmu z mikrokontrolera MCU do macierzy FPGA stają się bardziej widoczne. Etap ten jest równoważny z etapem zarządzania systemem za pomocą mikrokontrolera omówionym powyżej.

Nowoczesne narzędzia macierzy FPGA pozwalają na użycie zestawu optymalizacji i ulepszeń, które znacznie poprawiają parametry działania złożonych algorytmów. Przed analizą wyników należy zwrócić uwagę na kilka ważnych terminów:

• Latencja - liczba cykli zegara wymagana do wykonania wszystkich iteracji pętli [10]
• Interwał - liczba cykli zegara, zanim następna iteracja pętli zacznie przetwarzać dane [11]
• BRAM - blokowa pamięć o dostępie swobodnym
• DSP48E - blok cyfrowego przetwarzania sygnałów dla architektury UltraScale
• FF - przerzutnik
• LUT - tablicowanie
• URAM - zunifikowana pamięć o dostępie swobodnym (może składać się z jednego tranzystora)

Tabela 1: Wyniki optymalizacji wykonania algorytmu macierzy FPGA (latencja i interwał).

Tabela 2: Wyniki optymalizacji wykonania algorytmu macierzy FPGA (zasoby, środki).

Domyślnie

Domyślne ustawienia optymalizacji pochodzą z niezmienionego wyniku translacji algorytmu opartego na języku C do syntezowalnego języka opisu sprzętu (HDL). Żadne optymalizacje nie są włączone i można ten stan wykorzystać jako odniesienie parametrów działania, aby lepiej zrozumieć inne optymalizacje.

Wewnętrzna pętla potoku

Polecenie PIPELINE nakazuje Vivado HLS rozwinąć wewnętrzne pętle, tak aby umożliwić rozpoczęcie przetwarzania nowych danych w czasie gdy istniejące dane są nadal w potoku. Dzięki temu nie ma konieczności oczekiwania z rozpoczęciem przetwarzania nowych danych, aż istniejące dane zostaną ukończone.

Zewnętrzna pętla potoku

Dzięki zastosowaniu polecenia PIPELINE do pętli zewnętrznej operacje pętli zewnętrznej są teraz wykonywane w trybie potokowym. Jednak operacje w pętlach wewnętrznych są teraz wykonywane równocześnie. Zarówno czas latencji, jak i interwału są zredukowane o połowę poprzez zastosowanie bezpośrednio do pętli zewnętrznej.

Partycja macierzowa

To polecenie mapuje zawartość pętli do tablic i w ten sposób spłaszcza cały dostęp do pamięci do pojedynczych elementów w tych tablicach. W ten sposób zużywana jest większa ilość pamięci RAM, ale czas wykonania tego algorytmu jest skrócony o połowę.

Przepływ danych

To polecenie pozwala projektantowi określić docelową liczbę cykli zegara pomiędzy każdym z odczytów wejściowych. To polecenie jest obsługiwane tylko w przypadku funkcji najwyższego poziomu. Tylko pętle i funkcje dostępne na tym poziome mogą odnieść korzyść z tego polecenia.

Liniowo

Polecenie INLINE spłaszcza wszystkie pętle, zarówno wewnętrzne, jak i zewnętrzne. Zarówno procesy wierszy, jak i kolumn mogą być teraz wykonywane współbieżnie. Liczba wymaganych cykli zegara jest ograniczona do minimum, nawet jeśli zużywa to więcej zasobów macierzy bramek FPGA.

Podsumowanie

Architektura sprzętowa koprocesora zapewnia projektantom urządzeń wbudowanych wysokowydajną platformę, która zachowuje elastyczność projektowania przez cały okres rozwoju produktu i po jego udostępnieniu. Dzięki wstępnej walidacji algorytmów w języku C lub C++, można stosunkowo szybko zweryfikować procesy, ścieżki danych i sygnałów oraz krytyczną funkcjonalność. Następnie, dzięki przełożeniu algorytmów intensywnie wykorzystujących procesor do układu macierzy bramek FPGA koprocesora, projektant może cieszyć się korzyściami płynącymi z akceleracji sprzętowej i bardziej modułowej konstrukcji.

Jeśli części staną się przestarzałe lub wymagane będą optymalizacje, ta sama architektura może umożliwić wprowadzenie zmian. Do projektu można dopasować nowe mikrokontrolery MCU i nowe macierze bramek FPGA, podczas gdy interfejsy mogą pozostać względnie nienaruszone. Ponadto zarówno mikrokontrolery MCU, jak i bezpośrednio programowalne macierze bramek (FPGA)można aktualizować w terenie, dlatego zmiany i optymalizacje specyficzne dla użytkownika można wprowadzać w terenie i zdalnie.

Podsumowując, architektura ta łączy szybkość rozwoju i dostępność mikrokontrolera MCU z wydajnością i możliwościami rozbudowy macierzy FPGA. Dzięki optymalizacjom i poprawie parametrów działania dostępnym na każdym etapie rozwoju, architektura koprocesorowa może sprostać nawet najbardziej wyśrubowanym wymaganiom, zarówno w przypadku dzisiejszych projektów, jak i tych, które dopiero powstaną.

Autor: Noah Madinger, Colorado Electronic Product Design (CEPD)

Źródło ©: www.digikey.pl

Kontakt w Polsce

Arkadiusz Rataj

Sales Manager Central Eastern Europe & Turkey

Digi-Key Electronics Germany

0048 696 307 330

arkadiusz.rataj@digikey.com

poland.support@digikey.pl