Projekt oprogramowania układowego FPGA: Jak duży jest za duży?

Mam szczególnie dużą transformację przetwarzania sygnału, którą należy przenieść z Matlaba na VHDL. To zdecydowanie wymaga pewnego rodzaju udostępniania zasobów. Trochę obliczeń dało mi następujące informacje:

• 512 fft 64-punktowych
• 41210 operacji wielokrotnego dodawania

Biorąc pod uwagę, że największy Virtex 6 FPGA ma ~ 2000 bloków DSP48E, wiem, że mogę współdzielić zasoby, aby wielokrotnie korzystać z zasobów. Czas wykonania nie jest tak naprawdę problemem, czas przetwarzania może potrwać stosunkowo długo w kategoriach FPGA.

Patrząc na wykorzystanie zasobów, użycie architektury radix-2 lite daje mi bloki 4dsp / FFT = 2048 bloków DSP, w sumie ~ 43k. największy Virtex FPGA ma 2k bloków, czyli 20 operacji / multiplekser.

Oczywiście uwzględnienie tak dużych miksów w tkaninie również zajmie plastry. Gdzie znajdę górną granicę tego limitu? Nie mogę w nieskończoność udostępniać zasobów FPGA. Czy mnożniki 41210 są za duże? Jak obliczyć, co jest za duże?

Przyjrzałem się także innym zasobom (plastry, stłuczki itp.). Radix-2 Lite daje również 4 x 18k Brams / fft = 2048 Brams, największy Xilinx FPGA zawiera 2128 Brams. bardzo granica. Obawiam się, że mój projekt jest po prostu za duży.

AKTUALIZACJA:

Więcej informacji na temat samego projektu. Nie mogę wdawać się w szczegóły, ale oto, co mogę dać:

Initial conditions -> 512 ffts -> 40k multipliers ---------|----> output data to host 

                 ^------re-calculate initial conditions----|

wyjściowa specyfikacja danych: „szybciej niż symulacja Matlaba”

obliczenia mądre, oto gdzie jestem:

Etap FFT: łatwy. Mogę wdrożyć FFT 1/2/4/8, zapisać wyniki w pamięci SDRAM i uzyskać dostęp później. Stosunkowo mały, nawet jeśli zajmuje dużo czasu, jest w porządku. używając radix-2 lite mogę uzyskać 2 DSP48E i 2 18k BRAMS / FFT. Streaming daje 6 DSP48Es 0BRAMS / FFT. w obu przypadkach 64-punktowy FFT jest niewielki pod względem zasobów FPGA.

Mnożniki : to mój problem. Dane wejściowe do mnożenia są pobierane z tabel odnośników lub danych FFT. To naprawdę jest cała masa wielokrotnych dodań. Nie ma wiele do optymalizacji. Nie filtr, ale ma cechy podobne do filtra.

Biorąc pod uwagę współdzielenie zasobów na FPGA, matematyka działa w następujący sposób: Jeden LUT-6 może być używany jako multipleks 4-kierunkowy. Wzór na multipleks M-bitowy N-way jest następujący:

N*M/3 = number of luts, or N*M/12 = slices (4 LUTS/slice).

chrupanie liczb dla mojej implementacji nie daje dobrych rezultatów. 90% z rodziny virtix-6 nie ma wystarczającej liczby wycinków, aby dzielić zasoby DSP w celu wykonania 40 000 operacji.

Zastanawiam się, czy istnieje inny sposób spojrzenia na problem?

Odgrywasz swoją ocenę 512 operacji FFT (po 64 punkty) i 42k operacji MAC ... Zakładam, że to jest potrzebne do jednego przejścia przez algorytm?

Teraz znalazłeś rdzeń FFT przy użyciu 4 jednostek DSP ... ale ile cykli zegara potrzeba na FFT? (przepustowość, a nie opóźnienie)? Powiedzmy 64 lub 1 cykl na punkt. Następnie musisz wykonać te 42k operacje Maca w 64 cyklach - być może 1k MAC na cykl, przy czym każda operacja MAC obsługuje 42 operacje.

Teraz nadszedł czas, aby przyjrzeć się szczegółowo pozostałemu algorytmowi: zidentyfikuj nie MAC, ale operacje na wyższym poziomie (filtrowanie, korelacja, cokolwiek), które można ponownie wykorzystać. Zbuduj rdzenie dla każdej z tych operacji, z możliwością wielokrotnego użytku (np. Filtry z różnymi zestawami współczynników do wyboru), a wkrótce może się okazać, że pomiędzy stosunkowo dużymi rdzeniami może być potrzebnych stosunkowo niewiele multiplekserów ...

Czy możliwe jest także zmniejszenie siły? Miałem kilka przypadków, w których mnożenie w pętlach było wymagane do generowania kwadratów (i wyższych). Rozwijając je, mogłem iteracyjnie generować je bez mnożenia: byłem całkiem zadowolony z siebie w dniu, w którym zbudowałem silnik różnicowy na FPGA!

Bez znajomości aplikacji nie mogę podać więcej szczegółów, ale niektóre z takich analiz prawdopodobnie spowodują znaczne uproszczenia.

Ponadto - ponieważ brzmi to tak, jakbyś nie miał na myśli określonej platformy - zastanów się, czy możesz dzielić na wiele układów FPGA ... spójrz na tę płytkę lub tę, która oferuje wiele układów FPGA na wygodnej platformie. Mają też płytę ze 100 urządzeniami Spartan-3 ...

(ps Byłem rozczarowany, gdy faceci oprogramowania zamknęli to drugie pytanie - myślę, że jest to co najmniej tak właściwe)

Edycja: ponownie edytuj - Myślę, że zaczynasz się tam dostać. Jeśli wszystkie wejścia multiplikatora są albo wyjściami FFT, albo współczynnikami „bez filtrowania”, zaczynasz widzieć rodzaj prawidłowości, którą musisz wykorzystać. Jedno wejście do każdego multiplikatora łączy się z wyjściem FFT, drugie wejście do współczynnika ROM (BlockRam zaimplementowany jako stała tablica).

Sekwencjonowanie różnych operacji FFT za pomocą tej samej jednostki FFT spowoduje automatyczne sekwencjonowanie wyników FFT za tym multiplikatorem. Sekwencjonowanie poprawnych współczynników do innych danych wejściowych MPY jest teraz „jedynie” kwestią zorganizowania prawidłowych adresów ROM we właściwym czasie: problem organizacyjny, a nie ogromny ból głowy MUX.

Jeśli chodzi o wydajność: myślę, że Dave Tweed był niepotrzebnie pesymistyczny - FFT biorąc n * log (n) operacji, ale możesz wybrać O (n) jednostki motylkowe i O (logN) lub O (logN) jednostki i O ( n) cykle lub inne kombinacje odpowiadające twoim celom w zakresie zasobów i prędkości. Jedna taka kombinacja może znacznie uprościć strukturę mnożenia po FFT niż inne ...

Jeśli ten problem nie ma ścisłych ograniczeń w czasie rzeczywistym, i wygląda na to, że tak nie jest - po prostu chcesz, aby działał „szybciej”, wydaje się, że może być całkiem podatny na przyspieszenie na jednym lub kilku procesorach graficznych. Istnieje kilka bibliotek oprogramowania, które sprawiają, że jest to stosunkowo prosta propozycja, a byłoby to o rząd wielkości łatwiejsze niż przejście na niestandardowy sprzęt FPGA.

Aby rozpocząć, wystarczy Google dla „biblioteki obsługującej GPU” lub „biblioteki akcelerowanej przez GPU”.

Możliwe jest użycie specjalistycznego sprzętu lub układu FPGA (lub nawet CPLD), aby znacznie przyspieszyć niektóre rodzaje operacji matematycznych. Kluczową rzeczą, o której należy pamiętać przy projektowaniu sprzętu (obwodów lub układów FPGA) w celu przyspieszenia operacji matematycznych, jest ustalenie, jakie dane zamówienia będą musiały wchodzić i wychodzić z urządzenia. Urządzenie z wydajnym układem we / wy może oferować znacznie lepszą wydajność niż urządzenie z niewydajnym układem, nawet jeśli to drugie urządzenie wymaga znacznie więcej obwodów.

Nie próbowałem opracować projektu wspomagania sprzętowego dla FFT, ale przyjrzałem się pomocy sprzętowej dla dużych operacji zwielokrotnienia (które mogą być użyte do szyfrowania RSA). Wiele mikrokontrolerów, nawet tych ze specjalnym sprzętem do szybkiego zwielokrotniania, nie jest strasznie wydajne w takich operacjach, ponieważ wymagają dużego tasowania rejestrów. Sprzęt, który został zaprojektowany w celu zminimalizowania zamiany rejestrów, może osiągnąć znacznie lepszą wydajność przy operacjach zwielokrotniania z dużą precyzją, nawet jeśli sam sprzęt nie był tak zaawansowany. Na przykład sprzęt, który może wykonać multipleksowanie potokowe 16xN po dwa bity na raz (przesunięcie o dwa dolne bity multiplikatora i przesunięcie o dwa górne bity wyniku) może osiągnąć lepszą wydajność niż sprzęt, który może wykonać multiplikację 8x8 w jednym cyklu, nawet jeśli te pierwsze mogą wymagać mniejszej liczby obwodów (i ze względu na potokowanie mają krótszą ścieżkę danych krytycznych). Kluczem jest dowiedzieć się, jak będzie wyglądać „wewnętrzna pętla” niezbędnego kodu i dowiedzieć się, czy istnieją jakieś nieefektywności, które można łatwo wyeliminować.

Jak mało problemu nam czas wykonania?

To naprawdę wygląda na sytuację, w której powinieneś naprawdę zaimplementować soft-MCU, FPGA ze zintegrowanym hard-MCU, a nawet oddzielne urządzenie MCU i serializować wszystkie swoje operacje.

Zakładając, że masz czas wykonania, wykonywanie FFT w oprogramowaniu będzie zarówno o wiele łatwiejsze do debugowania, jak i prawdopodobnie o wiele łatwiejsze do zaprojektowania.