Architektura koprocesora: architektura systemu wbudowanego do szybkiego prototypowania

Uwaga od redakcji: architektura koprocesorowa jest dobrze znana z wydajności i przepustowości przetwarzania cyfrowego, jednak daje projektantom systemów wbudowanych również możliwości wdrażania strategii zarządzania projektami, które poprawiają zarówno koszty rozwoju, jak i czas wprowadzenia produktu na rynek. Niniejszy artykuł, skoncentrowany w szczególności na połączeniu dyskretnego mikrokontrolera (MCU) i dyskretnej bezpośrednio programowalnej macierzy bramek (FPGA), pokazuje przydatność tej architektury do sprawnego i iteracyjnego procesu projektowania. Wykorzystując zbadane źródła, wnioski empiryczne i analizy przypadków, zbadano korzyści płynące z tej architektury i przedstawiono przykładowe zastosowania. Po przeczytaniu tego artykułu projektanci systemów wbudowanych będą lepiej rozmieć, kiedy i jak wdrażać tę wszechstronną architekturę sprzętową.

Wprowadzenie

Projektant systemów wbudowanych znajduje się na styku ograniczeń projektowych, oczekiwań dotyczących parametrów działania, harmonogramu i budżetu. Nawet sprzeczności w modnych słowach i zwrotach związanych z nowoczesnym zarządzaniem projektami jeszcze bardziej podkreślają niepewny charakter tej roli: „szybka porażka”; „zachowaj zwinność”; „przygotuj to na przyszłość” i „przełam schematy!”. Akrobatyka związana z próbą spełnienia tych oczekiwań może być dokuczliwa, a jednak zostały one wypowiedziane i nadal są wzmacniane na całym rynku. Potrzebne jest podejście projektowe, które umożliwia wdrożenie ewolucyjnego procesu iteracyjnego, i tak jak w przypadku większości systemów wbudowanych, zaczyna się od architektury sprzętowej.

Architektura koprocesorowa, czyli architektura sprzętowa znana z łączenia mocnych stron zarówno technologii jednostek mikrokontrolerów (MCU), jak i bezpośrednio programowalnych macierzy bramek (FPGA), może zaoferować projektantom systemów wbudowanych proces zdolny do spełnienia nawet najbardziej wyśrubowanych wymagań, a jednocześnie pozwalający na elastyczność niezbędną do sprostania zarówno znanym, jak i nieznanym wyzwaniom. Mając do dyspozycji sprzęt zdolny do iteracyjnej adaptacji, projektant może zademonstrować postęp, realizować krytyczne etapy i w pełni wykorzystać proces szybkiego prototypowania.

W ramach tego procesu istnieją kluczowe etapy projektu, z których każdy ma swoją własną, unikalną wartość dodaną w działaniach rozwojowych. W całym artykule będą one określane następującymi terminami: etap cyfrowego przetwarzania sygnałów przez mikrokontroler, etap zarządzania systemem przez mikrokontroler oraz etap wdrażania produktu.

W podsumowaniu tego artykułu zostanie wykazane, że elastyczna architektura sprzętowa może być lepiej dostosowana do projektowania nowoczesnych systemów wbudowanych niż bardziej sztywne podejście. Co więcej, takie podejście może skutkować poprawą zarówno kosztów projektu, jak i czasu wprowadzenia na rynek. Do obrony tego punktu widzenia posłuży argumentacja, przykłady i analizy przypadków. Po zwróceniu uwagi na wartość każdego etapu w ramach elastyczności projektowania zapewnianej przez omawianą architekturę, staje się jasne, że adaptacyjna architektura sprzętowa jest potężnym czynnikiem napędzającym rozwój systemów wbudowanych.

Wykorzystanie mocnych stron architektury koprocesorowej: elastyczność projektowania i wysokowydajne przetwarzanie

Częstym zastosowaniem projektów z macierzami FPGA są bezpośrednie interfejsy z szybkimi przetwornikami analogowo-cyfrowymi (ADC). Sygnał jest digitalizowany, wczytywany do macierzy FPGA, a następnie na ten sygnał nakładane są algorytmy cyfrowego procesora sygnałowego (DSP). Na końcu macierz FPGA podejmuje decyzje na podstawie wyników.

Takie zastosowanie będzie służyło jako przykład w całym artykule. Ponadto na ilustracji 1 przedstawiono ogólną architekturę koprocesora, w której mikrokontroler MCU i macierz FPGA są połączone poprzez interfejs pamięci zewnętrznej mikrokontrolera MCU. Bezpośrednio programowalna macierz bramek (FPGA) jest traktowana jako zewnętrzna statyczna pamięci o dostępie swobodnym (SRAM). Sygnały wracają z macierzy FPGA do mikrokontrolera MCU i służą jako linie przerwań sprzętowych oraz wskaźniki stanu. Dzięki temu macierz FPGA może sygnalizować mikrokontrolerowi MCU stany krytyczne, takie jak gotowość konwersji analogowo-cyfrowej (ADC), wystąpienie błędu lub innego istotnego zdarzenia.

Ilustracja 1: schemat typowego koprocesora (MCU + FPGA). (Źródło ilustracji: CEPD)

Mocne strony podejścia opartego na koprocesorze są prawdopodobnie najlepiej widoczne w wynikach każdego z wyżej wymienionych etapów. Wartość ocenia się nie tylko poprzez wyszczególnienie osiągnięć zadania lub etapu, lecz także poprzez ocenę możliwości, na jakie pozwalają te osiągnięcia. Odpowiedzi na poniższe pytania pomagają w ocenie ogólnej wartości wyników danego etapu:

• Czy postępy innych członków zespołu mogą teraz przyspieszyć, ponieważ usunięte zostały zależności i wąskie gardła projektu?
• W jaki sposób osiągnięcia tego etapu umożliwiają dalsze prowadzenie projektu równoległymi ścieżkami?

Etap cyfrowego przetwarzania sygnałów za pomocą mikrokontrolera

Ilustracja 2: architektura - cyfrowe przetwarzanie sygnałów za pomocą mikrokontrolera. (Źródło ilustracji: CEPD)

Pierwszy etap rozwoju, na który pozwala ta architektura sprzętowa, umieszcza mikrokontroler MCU na pierwszym planie. Przy tym wszystkim prace rozwojowe nad mikrokontrolerem MCU i oprogramowaniem wykonywalnym są mniej zasobożerne i czasochłonne niż prace nad bezpośrednio programowalną macierzą bramek (FPGA) i językiem opisu sprzętu (HDL). Dzięki temu, rozpoczynając opracowywanie produktu z mikrokontrolerem MCU jako głównym procesorem, można szybciej wdrażać, testować i zatwierdzać algorytmy. Pozwala to na wykrywanie błędów algorytmicznych i logicznych na wczesnym etapie procesu projektowania, a także na przetestowanie i walidację znacznych części łańcucha sygnałowego.

Bezpośrednio programowalna macierz bramek (FPGA) na tym początkowym etapie służy jako szybki interfejs do zbierania danych. Jego zadaniem jest niezawodne przesyłanie danych z szybkiego przetwornika analogowo-cyfrowego (ADC), powiadamianie mikrokontrolera MCU o dostępności danych i prezentowanie tych danych na zewnętrznym interfejsie pamięci mikrokontrolera MCU. Chociaż rola ta nie obejmuje implementacji procesów cyfrowego procesora sygnałowego (DSP) opartych na języku opisu sprzętu (HDL) ani innych algorytmów, jest ona jednak bardzo ważna.

Opracowanie macierzy FPGA przeprowadzone w tej fazie stanowi podstawę ostatecznego sukcesu produktu zarówno w ramach prac rozwojowych, jak i po wprowadzeniu go na rynek. Skupiając się tylko na interfejsie niskiego poziomu, można poświęcić odpowiednią ilość czasu na testowanie istotnych operacji. Dopiero wtedy, gdy macierz FPGA niezawodnie i pewnie wypełnia tę rolę interfejsu, można pewnie zakończyć ten etap.

Kluczowe rezultaty tego początkowego etapu obejmują następujące korzyści:

1. Przetestowanie i zweryfikowanie pełnej ścieżki sygnałowej - wszystkich wzmocnień, tłumień i konwersji.
2. Redukcja czasu i wysiłku związanego z opracowaniem projektu dzięki wstępnej implementacji algorytmów w oprogramowaniu (C/C++). Ma to znaczną wartość dla kierownictwa i innych zainteresowanych stron, które muszą przekonać się o wykonalności tego projektu przed zatwierdzeniem przyszłych faz projektowania.
3. Możliwość bezpośredniego przeniesienia wniosków wyciągniętych z implementacji algorytmów w C/C++ na implementacje w języku opisu sprzętu (HDL) dzięki zastosowaniu narzędzi software-to-HDL, takich jak np. Xilinx HLS.

Etap zarządzania systemem za pomocą mikrokontrolera

Ilustracja 3: architektura - zarządzanie systemem za pomocą mikrokontrolera. (Źródło ilustracji: CEPD)

Drugi etap rozwoju możliwy dzięki podejściu koprocesorowemu, jest definiowany przez przeniesienie procesów cyfrowego procesora sygnałowego (DSP) i implementacji algorytmów z mikrokontrolera MCU do bezpośrednio programowalnej macierzy bramek (FPGA). Macierz FPGA jest nadal odpowiedzialna za szybki interfejs przetwornika analogowo-cyfrowego (ADC), jednak dzięki przejęciu innych ról, szybkość i równoległość oferowana przez macierz FPGA jest w pełni wykorzystana. Co więcej, w przeciwieństwie do mikrokontrolera MCU, można jednocześnie zaimplementować i uruchomić wiele wystąpień procesów cyfrowego procesora sygnałowego (DSP) i kanałów algorytmów.

Bazując na doświadczeniach zdobytych podczas wdrażania mikrokontrolerów MCU, projektant przenosi tę pewność na kolejny etap. Narzędzia, takie jak wspomniane wcześniej Vivado HLS firmy Xilinx, zapewniają funkcjonalną translację z wykonywalnego kodu C/C++ na syntezowalny język opisu sprzętu (HDL). Teraz trzeba jeszcze zdefiniować i zaimplementować ograniczenia czasowe, parametry procesu i inne preferencje użytkownika, jednak podstawowa funkcjonalność jest zachowana i przeniesiona na strukturę macierzy FPGA.

Na tym etapie mikrokontroler MCU pełni rolę menedżera systemu. Rejestry stanu i sterowania są monitorowane, aktualizowane i zgłaszane przez mikrokontroler MCU. Ponadto mikrokontroler MCU zarządza interfejsem użytkownika. Interfejs użytkownika może mieć formę serwera internetowego dostępnego przez połączenie Ethernet lub Wi-Fi, lub może to być przemysłowy interfejs dotykowy dający dostęp użytkownikom w miejscu użytkowania. Kluczową kwestią dotyczącą nowej, bardziej wyrafinowanej roli mikrokontrolera MCU jest to, że dzięki odciążeniu od zadań wymagających intensywnych obliczeń, zarówno mikrokontroler MCU, jak i macierz FPGA są teraz wykorzystywane w zadaniach, do których są dobrze przystosowane.

Na tym etapie powstają też kluczowe wyniki, które dają również następujące korzyści:

1. Macierz FPGA zapewnia szybką, równoległą realizację procesów DSP i implementację algorytmów.Mikrokontroler MCU zapewnia responsywny i usprawniony interfejs użytkownika oraz zarządza procesami produktu.
2. Ponieważ ryzyka algorytmiczne zostały najpierw opracowane i ocenione w obrębie mikrokontrolera MCU, zostały one złagodzone, a działania łagodzące zostały przekształcone na syntezowalny język HDL. Narzędzia, takie jak Vivado HLS, ułatwiają przeprowadzenie takiego przekształcenia. Co więcej, ryzyka specyficzne dla macierzy FPGA mogą zostać zminimalizowane poprzez zintegrowane narzędzia symulacyjne, takie jak pakiet projektowy Vivado.
3. Interesariusze nie są narażeni na znaczące ryzyko poprzez przeniesienie procesów do macierzy FPGA. Wręcz przeciwnie, mają oni okazję zobaczyć i cieszyć się korzyściami, jakie zapewnia szybkość i równoległość działania macierzy FPGA. Zaobserwowano wymierną poprawę wydajności i można teraz skupić się na przygotowaniu projektu do produkcji.

Etap wdrażania produktu

Dzięki temu, że intensywne obliczeniowo przetwarzanie odbywa się w bezpośrednio programowalnej macierzy bramek (FPGA), a mikrokontroler MCU zajmuje się zarządzaniem systemem i obsługą interfejsu użytkownika, produkt jest gotowy do wdrożenia. Niniejszy artykuł nie zaleca omijania wersji alfa i beta, jednak nacisk na tym etapie położono na możliwości, jakie architektura koprocesora zapewnia przy wdrażaniu produktu.

Zarówno mikrokontroler MCU jak i macierz FPGA są urządzeniami, które można aktualizować w terenie. Dokonano szeregu postępów, aby aktualizacje macierzy FPGA były tak samo dostępne, jak aktualizacje oprogramowania. Ponadto, ponieważ macierz FPGA znajduje się w przestrzeni adresowalnej pamięci mikrokontrolera MCU, może on służyć jako punkt dostępu dla całego systemu, odbierając aktualizacje zarówno dla siebie, jak i dla macierzy FPGA. Aktualizacje mogą być warunkowo planowane, dystrybuowane i dostosowywane do poszczególnych użytkowników końcowych. Można również prowadzić pliki dzienników użytkowników i przypadków użycia i kojarzyć je z konkretnymi implementacjami kompilacji. Na podstawie tych zbiorów danych można udoskonalać i poprawiać parametry działania nawet po tym, jak produkt znajdzie się w terenie.

Być może zalety tej całościowej możliwości aktualizacji są najlepiej widoczne w zastosowaniach kosmicznych. Po wprowadzeniu produktu na rynek konserwacja i aktualizacje muszą być przeprowadzane zdalnie. Może to być tak proste, jak zmiana warunków logicznych, lub tak skomplikowane, jak aktualizacja schematu modulacji komunikacji. Możliwości programowania oferowane przez technologie FPGA i architekturę koprocesorową mogą pomieścić cały ten zakres możliwości, oferując jednocześnie wybór komponentów odpornych na promieniowanie.

Ostatnią kluczową kwestią na tym etapie jest stopniowa redukcja kosztów. Na tym etapie może wystąpić również redukcja kosztów, zmiany w wykazie materiałów (BOM) i inne optymalizacje. Podczas wdrożeń w terenie może się okazać, że produkt może działać równie dobrze z tańszym mikrokontrolerem MCU lub mniej wydajną macierzą FPGA. Dzięki koprocesorowi projektanci architektury nie są skazani na używanie komponentów, których możliwości przekraczają potrzeby aplikacji. Ponadto, jeśli któryś z komponentów przestanie być dostępny, projektowana architektura pozwala na zintegrowanie nowych komponentów. Nie jest tak w przypadku architektury jednoukładowej, układu SoC, czy też wysokowydajnego procesora DSP lub mikrokontrolera MCU, który próbuje obsłużyć całe przetwarzanie produktu. Architektura koprocesora stanowi dobre połączenie możliwości i elastyczności, dając projektantowi więcej możliwości wyboru i swobody zarówno w fazie rozwoju, jak i po wprowadzeniu na rynek.

Badania wspierające i powiązane analizy przypadków

Przykład komunikacji satelitarnej

W skrócie, wartość koprocesora polega na odciążeniu głównej jednostki obliczeniowej tak, aby zadania były wykonywane sprzętowo, w czym można wykorzystać przyspieszenia i usprawnienia. Zaletą wyboru takiego projektu jest wzrost netto szybkości obliczeniowej i możliwości oraz - jak dowodzi ten artykuł - redukcja kosztów i czasu rozwoju. Być może jednym z najbardziej przekonujących obszarów zastosowania tych zalet jest obszar systemów komunikacji kosmicznej.

W publikacji "FPGA based hardware as coprocessor" (Urządzenia oparte na macierzy bramek FPGA jako koprocesor), G. Prasad i N. Vasantha opisują, w jaki sposób przetwarzanie danych w macierzy FPGA łączy potrzeby obliczeniowe systemów komunikacji satelitarnej bez wysokich jednorazowych kosztów projektowych (NRE) specjalizowanych układów scalonych (ASIC) lub specyficznych ograniczeń procesora o nieelastycznej architekturze. Podobnie jak to opisano na etapie cyfrowego przetwarzania sygnałów przez mikrokontroler, ich projektowanie rozpoczyna się od procesora aplikacyjnego wykonującego większość intensywnych obliczeniowo algorytmów. W tym punkcie początkowym zidentyfikowano kluczowe części oprogramowania, które zużywają większość cykli zegara procesora (CPU) i przenieśli te części do implementacji języka opisu sprzętu (HDL). Graficzna reprezentacja jest bardzo podobna do przedstawionej wcześniej, jednak zdecydowano się na reprezentację programu aplikacyjnego jako niezależnego bloku, ponieważ może on być realizowany zarówno przez hosta (procesor), jak i urządzenie oparte na macierzy bramek FPGA.

Ilustracja 4: program aplikacyjny, procesor hosta i sprzęt oparty na macierzy FPGA - przykład zastosowania w komunikacji satelitarnej.

Dzięki wykorzystaniu interfejsu komponentów peryferyjnych (PCI)oraz bezpośredniego dostępu do pamięci (DMA) procesora hosta parametry działania urządzeń peryferyjnych znacznie wzrastają. Jest to najczęściej widoczne w ramach poprawek na potrzeby procesu derandomizacji. Kiedy proces ten był wykonywany w oprogramowaniu procesora hosta, widoczne było wąskie gardło w reakcji systemu w czasie rzeczywistym. Jednak po przeniesieniu na macierz FPGA zaobserwowano następujące korzyści:

• Proces derandomizacji wykonywany w czasie rzeczywistym bez powodowania zatorów
• Obciążenie obliczeniowe procesora głównego zostało znacznie zredukowane i mógł on lepiej spełniać pożądaną funkcję rejestrowania.
• Poprawiono ogólne parametry działania całego systemu.

Wszystko to udało się osiągnąć bez kosztów związanych ze specjalizowanym układem scalonym ASIC, przy jednoczesnym korzystaniu z elastyczności programowalnych układów logicznych [5]. Komunikacja satelitarna wiąże się ze znacznymi wyzwaniami, a to podejście może w sposób sprawdzony spełnić jej wymagania i nadal zapewniać elastyczność projektową.

Przykład samochodowego systemu inforozrywki

Systemy rozrywki w samochodach są cechami wyróżniającymi dla wymagających konsumentów. W przeciwieństwie do większości elektroniki samochodowej, urządzenia te są bardzo widoczne i oczekuje się od nich wyjątkowego czasu reakcji i wydajności. Jednak projektanci często są pod presją bieżących potrzeb projektu i elastyczności, której będą wymagać przyszłe funkcje. W tym przykładzie potrzeby implementacji przetwarzania sygnałów i komunikacji bezprzewodowej zostaną wykorzystane do podkreślenia mocnych stron architektury sprzętowej koprocesora.

Jedna z głównych architektur samochodowych systemów rozrywkowych została opublikowana przez korporację Delphi Delco Electronics Systems. W architekturze tej zastosowano mikrokontroler MCU SH-4 z towarzyszącym mu specjalizowanym układem scalonym (ASIC), peryferyjnym układem Amanda HD64404 firmy Hitachi. Architektura ta zaspokajała ponad 75% podstawowych potrzeb rynku motoryzacyjnego w zakresie rozrywki, jednak brakowało jej możliwości obsługi wideo i komunikacji bezprzewodowej. Poprzez włączenie macierzy bramek FPGA do istniejącej architektury, można jeszcze bardziej zwiększyć elastyczność i możliwości do tego już istniejącego podejścia projektowego.

Ilustracja 5: architektura koprocesorowa z macierzą bramek FPGA dla systemu inforozrywki - przykład 1.

Architektura na ilustracji 5 nadaje się zarówno do przetwarzania wideo, jak i do zarządzania komunikacją bezprzewodową. Dzięki przesunięciu funkcji cyfrowego procesora sygnałowego (DSP) do bezpośrednio programowanej macierzy bramek FPGA, procesor Amanda może pełnić funkcję zarządzania systemem i jest uwolniony od konieczności implementacji stosu komunikacji bezprzewodowej. Ponieważ zarówno procesor Amanda, jak i macierz FPGA mają dostęp do pamięci zewnętrznej, dane mogą być szybko wymieniane pomiędzy procesorami i komponentami systemu.

Ilustracja 6: architektura koprocesorowa z macierzą bramek FPGA dla systemu inforozrywki - przykład 2.

Drugi system inforozrywki na ilustracji 6 podkreśla zdolność macierzy bramek FPGA do obsługi zarówno przychodzących szybkich danych analogowych, jak i kompresji i kodowania potrzebnych w zastosowaniach wideo. W rzeczywistości cała ta funkcjonalność może być przesunięta do macierzy FPGA, a dzięki zastosowaniu przetwarzania równoległego, wszystkie te funkcje mogą być realizowane w czasie rzeczywistym.

Włączając macierz bramek FPGA do istniejącej architektury sprzętowej, sprawdzone parametry działania istniejących urządzeń można połączyć z elastycznością i zabezpieczeniem na przyszłość. Nawet w ramach istniejących systemów architektura koprocesorowa zapewnia projektantom opcje, które w innym przypadku nie byłyby dostępne [6].

Zalety szybkiego prototypowania

W swojej istocie proces szybkiego prototypowania dąży do objęcia znacznej części obszaru rozwoju produktu poprzez równoległe wykonywanie zadań, szybką identyfikację „błędów” i problemów projektowych oraz walidację danych i ścieżek sygnałowych, szczególnie tych, które leżą w obrębie ścieżki krytycznej projektu. Aby jednak ten proces rzeczywiście przyniósł optymalne i efektywne rezultaty, musi istnieć wystarczająca wiedza specjalistyczna w wymaganych obszarach projektu.

Tradycyjnie oznacza to, że w zespole musi być inżynier sprzętowy, inżynier oprogramowania wbudowanego lub cyfrowych procesorów sygnałowych (DSP) oraz inżynier języka opisu sprzętu (HDL). Jest mnóstwo specjalistów interdyscyplinarnych, którzy mogą być w stanie spełnić wiele ról, jednak koordynacja tych wysiłków w projekcie wymaga znacznych nakładów.

W swojej pracy pt. „FPGA based rapid prototyping platform for wavelet coprocessors” (Platforma prototypowania oparta na macierzy bramek FPGA do koprocesorów falkowych), autorzy promują koncepcję, że użycie architektury koprocesorowej pozwala pojedynczemu inżynierowi DSP wydajnie i skutecznie wypełnić wszystkie te funkcje. Na potrzeby tej analizy zespół rozpoczął projektowanie i symulację żądanych funkcji cyfrowego procesora sygnałowego (DSP)SP w narzędziu Simulink programu MATLAB. Spełniło to dwie podstawowe funkcje: 1) zweryfikowało pożądane osiągi poprzez symulację oraz 2) posłużyło jako punkt odniesienia, z którym można porównywać przyszłe wybory projektowe.

Po przeprowadzeniu symulacji zidentyfikowano krytyczne funkcje i podzielono je pomiędzy poszczególne rdzenie - są to komponenty miękkich rdzeni i procesory, które mogą być syntetyzowane w ramach macierzy FPGA. Najważniejszą czynnością podczas tych prac było zdefiniowanie interfejsu pomiędzy rdzeniami i komponentami oraz porównanie wydajności wymiany danych z żądaną, symulowaną wydajnością. Omawiany proces projektowania jest ściśle dopasowany do przepływu projektowania systemów wbudowanych firmy Xilinx i jest przedstawiony na ilustracji 7 poniżej.

Ilustracja 7: przepływ projektu wdrożeniowego.

Dzięki podzieleniu systemu na syntezowalne części, inżynier DSP może skupić się na najbardziej krytycznych aspektach łańcucha przetwarzania sygnału. Nie musi on być ekspertem w dziedzinie sprzętu lub języka opisu sprzętu (HDL), aby modyfikować, trasować lub implementować różne procesory z miękkimi rdzeniami lub komponenty w macierzy bramek FPGA. Dopóki projektant jest świadomy interfejsu i formatów danych, ma pełną kontrolę nad ścieżkami sygnału i może udoskonalać parametry działania systemu.

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