Jeśli przejrzysz projekty HDMI na stronie takiej jak hackaday , przekonasz się, że prawie każdy z nich wymaga FPGA. Nie sądzę, że widziałem jakikolwiek projekt DIY z wyjściem HDMI, który nie korzystałby z FPGA.
Ale dlaczego? Z tego co wiem, układy FPGA są drogie, około 70-100 $. Porównaj to z Raspberry Pi za 35 USD, które mogą robić znacznie bardziej skomplikowane rzeczy i generować wyjście HDMI. Dlaczego nie stosuje się ARM? A może nawet tańszy mikrokontroler?
W przypadku aktualizacji wideo na starych systemach do gier logika nie powinna być bardziej skomplikowana , jaką poradzi sobie tani mikrokontroler , ale wciąż postrzegam HDMI jako niemożliwą przeszkodę, którą rozwiązują tylko układy FPGA.
Odpowiedzi:
Zasadniczo żaden mikrokontroler, nawet Raspberry Pi, nie jest wystarczająco szybki. Raspberry pi ma wbudowany procesor graficzny, który generuje wyjście HDMI. Poza tym możliwości wejścia / wyjścia Raspberry Pi są niewiarygodnie ograniczone - najwyższy interfejs oprócz HDMI to USB. Wiele projektów konwersji HDMI wymaga wzięcia kolejnego strumienia wideo w dziwnym formacie i przerobienia go na coś, co można wysłać do standardowego telewizora HD przez HDMI. Wymaga to pewnej niestandardowej logiki interfejsu do odczytu sygnału wideo, logiki przetwarzania sygnału w celu przeformatowania go, logiki kodowania HDMI TMDS, a następnie szybkich serializatorów do faktycznego sterowania portem HDMI.
Praca z przesyłaniem strumieniowym, nieskompresowanym wideo w wysokiej rozdzielczości wymaga przetworzenia ogromnej ilości danych, co jest niemożliwe w przypadku procesora ogólnego przeznaczenia. Sygnał wideo 1080p przy 30 klatkach na sekundę ma około 62 milionów pikseli na sekundę. Raspberry pi działa z częstotliwością 700 MHz, więc masz 11 instrukcji na piksel. I to jest 11 instrukcji, które należy czytać w formacie dziwnego wideo w czasie rzeczywistym, przeskalować itd. Itd. Niemożliwe. Kropka.
Na FPGA możliwe jest wygenerowanie długiego potoku przetwarzania, który może przetwarzać jeden lub więcej pikseli na cykl zegara i robi to w wysoce deterministyczny sposób (bez przerw lub przełączania zadań!), Dzięki czemu dane pikseli są gotowe do transmisji przez HDMI we właściwym czasie. Jeśli intensywnie pracujesz z procesorami ogólnego przeznaczenia z dowolnym systemem operacyjnym, będziesz wiedział, że uzyskanie dokładnego pomiaru czasu na poziomie milisekund jest mniej więcej wykonalne, ale na poziomie mikrosekundy jest prawie niemożliwe. W przypadku HDMI potrzebna jest precyzja w skali nanosekundowej. Nie można tego zrobić na procesorze ogólnego przeznaczenia. Zobacz także projekt audio / wideo HDMI dla neo-geo. Ten musi nie tylko przeskalować wideo, ale także przeskalować dźwięk i wstawić go do strumienia wideo HDMI.
I to nadal nie uwzględnia niestandardowej logiki wymaganej do odczytu w dowolnym formacie danych wejściowych. Będziesz potrzebował niestandardowego sprzętu, aby to zinterpretować. Oprogramowanie nie jest wystarczająco szybkie lub wystarczająco deterministyczne. Być może będziesz mógł, na przykład, sformatować go do jakiegoś strumienia opartego na USB, ale to i tak będzie wymagało niestandardowej logiki cyfrowej, więc równie dobrze możesz po prostu bezpośrednio wyprowadzić HDMI.
Aby wdrożyć to wszystko, cyfrowa logika jest naprawdę jedynym wykonalnym rozwiązaniem. A jeśli zajmujesz się logiką cyfrową, FPGA to jedyne możliwe rozwiązanie, ponieważ jest zbyt szybkie i zbyt skomplikowane dla dyskretnej logiki 7400, a układy ASIC są, no cóż, kilka rzędów wielkości droższe.
Kolejnym wymaganym komponentem są rzeczywiste serializatory dużych prędkości i sterowniki różnicowe do generowania równoległych szeregowych strumieni danych, które są przesyłane kablem. Nie jest możliwe przesyłanie danych szeregowych bit-bang rzędu gigabitów na sekundę z procesora ogólnego przeznaczenia, wymaga to specjalistycznego sprzętu. Raspberry pi ma wbudowany procesor graficzny, który to robi, ale jest ograniczony pod względem możliwości GPU, nie wspominając o tym, co jest udokumentowane. Większość układów FPGA zawiera co najmniej niezbędne sterowniki różnicowe i przerzutniki DDR wystarczające do obsługi wideo o niskiej rozdzielczości, a jest też całkiem sporo układów FPGA zawierających niezbędne serializatory (np. Bloki OSERDES Xilinx) do generowania strumieni Full HD. Nie zapominaj, że strumień szeregowy nie jest „pasmem podstawowym” jak normalny port szeregowy, na którym rzeczywiste dane są przesyłane dosłownie z pewnymi informacjami o ramkach, ale dane są w rzeczywistości kodowane za pomocą TMDS (różnicowa sygnalizacja różnicowa zminimalizowana przy przejściu), aby nadać sygnałowi pewne właściwości elektryczne. Oprócz rzeczywistych szybkich serializatorów wymagana jest odrobina logiki. Wszystko to jest stosunkowo łatwe do zrobienia w czystej logice cyfrowej (no cóż, mimo wszystko kodowanie - serialzery są prawdopodobnie analogowe lub przynajmniej mieszane) na ASIC lub FPGA.
To naprawdę bardzo ważna część całego procesu projektowania cyfrowego / wbudowanego systemu, aby dowiedzieć się, które części systemu można zaimplementować w oprogramowaniu, a które wymagają sprzętu, albo w postaci gotowych specjalistycznych układów, układów FPGA, niestandardowych Układy ASIC, twarde lub miękkie IP (HDL, listy sieciowe, GDSII) itp. W tym przypadku jest to wyraźne: generowanie sygnału wideo wymaga specjalistycznego sprzętu, czy to GPU w połączeniu z procesorem ogólnego przeznaczenia, FPGA ze zintegrowanym twardym lub miękki rdzeń procesora lub w połączeniu z zewnętrznym procesorem lub coś bardziej wyspecjalizowanego.
Edycja: Właśnie zdałem sobie sprawę, że strona fpga4fun i projekt wideo neo-geo działają w rozdzielczości 640x480 zamiast full HD. Jednak tak naprawdę nie czyni tego znacznie prostszym. Minimalny zegar pikseli wynosi 25 MHz, a bitowy zegar 250 MHz. Oznacza to, że FPGA tak naprawdę nie wymaga serializatorów do przesyłania HDMI, a jedynie przerzutniki DDR. Jednak nadal nie zmniejsza to problemu odczytu danych wideo. Jeśli chcesz to zrobić na Raspberry Pi bez pomocy sprzętowej, musisz czytać z GPIO w sposób ciągły przy 25 MHz. Który czyta się co 175 instrukcji. Wchodzisz w sferę możliwości, ale jedynym sposobem, abyś mógł to zrobić, jest na czystym metalu (bez Linuksa) z ręcznie kodowanym asemblerem.
źródło