Czy FPGA jest wykonalna dla takiego projektu?

Obecnie pracuję nad Super OSD - projektem wyświetlania na ekranie. http://code.google.com/p/super-osd ma wszystkie szczegóły.

W tej chwili używam MCU dsPIC do wykonania zadania. Jest to bardzo potężny procesor DSP (40 MIPS przy 80 MHz, operacje jednotaktowe z trzema rejestrami i jednostka MAC) i, co ważne, jest dostarczany w pakiecie DIP (ponieważ używam płyty kontrolnej do prototypowania.) Naprawdę czerpię z tego każdą ostatnią wydajność, uruchamiając OSD - układ ma około 200ns lub 10 cykli na piksel na etapie wyjściowym, więc kod musi być bardzo zoptymalizowany w tej części (z tego powodu zawsze będzie napisany w montaż.)

Teraz zastanawiałem się nad użyciem do tego FPGA, ponieważ ze względu na równoległą architekturę takiego układu możliwe jest posiadanie prostego programu logicznego z OSD. Rzeczy takie jak rysowanie linii i kod algorytmiczny byłyby obsługiwane przez MCU, ale rzeczywiste dane wyjściowe byłyby wykonywane za pomocą FPGA. I kilka prostych rzeczy, takich jak ustawianie pikseli lub rysowanie linii poziomych i pionowych, które chciałbym zintegrować z FPGA, aby poprawić szybkość.

Mam parę pytań:

1. Czy będzie to kosztować znacznie więcej? Najtańsze FPGA, które znalazłem, wynosiły ~ 5 £ każda, a dsPIC wynosi 3 £ każda. Będzie to kosztowało więcej, ale o ile?
2. DsPIC mieści się w pakiecie SO28. Nie chciałbym być większy niż SO28 lub TQFP44. Większość układów FPGA, które widziałem, występuje w pakietach BGA lub TQFP> 100, które obecnie nie są opcją ze względu na rozmiar ścinania i trudność samodzielnego ich lutowania.
3. Ile prądu zużywa FPGA? Rozwiązanie dsPIC zużywa obecnie około 55 mA +/- 10 mA, co jest w tej chwili w porządku. Czy FPGA zużyłoby mniej więcej? Czy jest zmienny, czy raczej dość statyczny, jak dsPIC?
4. Potrzebuję co najmniej 12 KB pamięci graficznej do przechowywania grafiki OSD. Czy układy FPGA mają taką pamięć dostępną w układzie, czy jest ona dostępna tylko w przypadku układów zewnętrznych?

Zasadniczo jest to dobry kandydat do projektowania opartego na FPGA. Jeśli chodzi o twoje wymagania:

ad 1. FPGA najprawdopodobniej będzie droższy, o ile zależy to od wybranego urządzenia. Na pierwszy rzut oka najmniejszy Spartan 3 od Xilinx (XC3S50AN) będzie wystarczający do wykonania tego zadania (~ 10 £ od Farnell). Myślę, że możesz założyć, że jest to górna granica kosztu (ma 56kB RAM w środku, więc jest więcej niż potrzebujesz). Możesz znaleźć tańsze urządzenie z oferty Xilinx lub ich konkurentów Altera i Lattice.

ad 2. Pakiet to trudny problem, nie widziałem też FPGA o mniejszej powierzchni. Być może jednak możesz użyć urządzenia CPLD (dla uproszczenia CPLD to małe FPGA), które mogą być w mniejszym pakiecie (PLCC lub QFN). Plusy będą tańsze (nawet pojedyncze $) po stronie negatywnej, najprawdopodobniej nie będą miały pamięci RAM. Z CPLD prawdopodobnie potrzebujesz zewnętrznego układu SRAM.

ad 3. Pobór prądu przez układy FPGA i CPLD w dużym stopniu zależy od zaprogramowanej konstrukcji. Istnieje jednak duża szansa, że ​​układy FPGA, a zwłaszcza CPLD, zużyją mniej niż obecne rozwiązanie.

ad 4. FPGA mają taką pamięć w środku, CPLD z pewnością nie. Można to rozwiązać za pomocą zewnętrznego układu sram (lub dwóch). Na przykład:

| SRAM 1 | <--> | CPLD | <--> | uC |
| SRAM 2 | <-->

W takim układzie, gdy uC pisze do SRAM 1, CPLD wyświetla dane z SRAM 2. CPLD powinien być w stanie obsłużyć oba zadania jednocześnie.

Oczywiście możesz rozwiązać ten problem również na inne sposoby:
1) użyj szybszego kontrolera uController (na przykład ARM)
2) użyj urządzenia z pewną programowalną tkaniną i uC wewnątrz (na przykład FPSLIC z Atmel, jednak nigdy nie korzystałem z takich urządzeń i wiem bardzo trochę o nich)

Standardowe zrzeczenie się odpowiedzialności -> ponieważ projekty są otwartymi problemami, z wieloma ograniczeniami i możliwymi rozwiązaniami, cokolwiek napisałem powyżej, może nie być prawdziwe w twoim przypadku. Uważam jednak, że warto sprawdzić tę opcję.

Możesz użyć CPLD zamiast FPGA, na przykład jednej z części Altera MAX II. Są one dostępne w pakietach QFP44, w przeciwieństwie do układów FPGA. W rzeczywistości są to małe układy FPGA, ale Altera pomija ten aspekt. Przewody CPLD mają przewagę nad większością układów FPGA, ponieważ mają wbudowaną pamięć konfiguracji, układy FPGA zazwyczaj wymagają zewnętrznego układu pamięci flash. Są oczywiście inne CPLD, ale podoba mi się MAX II.

Nie można powiedzieć, jaki będzie bieżący pobór prądu, ponieważ zależy to od częstotliwości zegara i ilości aktualnie używanej logiki.

FPGA zwykle mają ograniczoną ilość pamięci na chipie, z której można korzystać, ale będziesz potrzebować pamięci zewnętrznej z CPLD.

Inną opcją byłby układ XMOS , ale najmniejszy (XS1-L1) znajduje się w pakiecie QFP64. Ma dużo wbudowanej pamięci RAM - 64k.

1) Tak, FPGA będzie droższa. Sam procesor jest nie tylko droższy, ale będziesz potrzebować pamięci Flash do przechowywania programów. FPGA + Flash to prawdopodobnie 3-krotny koszt samego dsPIC ... około 10 USD za mały FPGA i 3 USD za mały Flash.

2) Mogą istnieć, ale tak naprawdę nie jestem świadomy żadnego FPGA, który nie jest montowany na powierzchni. Większość z nich to prawdopodobnie QFP lub BGA.

3) FPGA prawdopodobnie pobierze około 3-krotnie prąd, który robi dsPIC, ale może wzrosnąć lub zmniejszyć w zależności od używanych funkcji. Układy FPGA mają wiele funkcji, które mogą zwiększyć pobór mocy. Ale spodziewaj się co najmniej 150 mA.

4) FPGA zwykle mają w sobie blok RAM. Wszystkie oprócz najmniejszych układów FPGA powinny mieć tyle pamięci.

Inni wspominają CPLD. Jeśli ostrożnie podzielisz swój projekt, prawdopodobnie mógłbyś przenieść kilka małych, ale kosztownych operacji do CPLD. To byłoby jak mini koprocesor.

Najtańszym rozwiązaniem o najniższej krzywej uczenia się byłoby przejście na procesor o wyższej mocy, najprawdopodobniej ARM.

Programowanie FPGA / CPLD w VHDL / Verilog to dość stroma krzywa uczenia się pochodząca z C dla wielu osób. Nie są też zbyt tanimi częściami.

Korzystając z przyzwoitego ARM, może LPC1769? (kora-M3) prawdopodobnie byłbyś w stanie wymienić PIC18 w swoim projekcie.

Jeśli chodzi o problem z otworem przelotowym, o ile można uzyskać SoC w pakiecie typu QFP z odsłoniętym pinem, wystarczy pobrać niektóre z tych adapterów, aby uzyskać potrzebną pin do prototypowania.

Moją skłonnością byłoby użycie czegoś do buforowania czasu między procesorem a wyświetlaczem. Posiadanie sprzętu, który może wyświetlać całą klatkę wideo bez interwencji procesora, może być przyjemny, ale może przesadzić. Sugerowałbym, że najlepszym kompromisem pomiędzy złożonością sprzętową i programową byłoby prawdopodobnie stworzenie czegoś z dwoma lub trzema niezależnymi 1024-bitowymi rejestrami przesuwnymi (dwa bity na piksel, aby umożliwić czarny, biały, szary lub przezroczysty), i środek przełączania się między nimi. Niech PIC załaduje rejestr przesuwny, a następnie sprzęt zacznie go przesuwać podczas ustawiania flagi, aby PIC mógł załadować następny. W przypadku dwóch rejestrów przesuwnych PIC miałby 64us między czasem, w którym powiedziano, że rejestr przesuwny jest dostępny a czasem, kiedy wszystkie dane muszą zostać przesunięte. Dzięki trzem rejestrom zmianowym

Zauważ, że podczas gdy 1024-bitowy FIFO byłby tak dobry jak dwa 1024-bitowe rejestry przesuwne, a w CPLD FIFO kosztuje tylko jeden makrokomórkę na bit, plus pewną logikę sterowania, w większości innych rodzajów logiki dwa bity rejestru przesuwnego będzie tańszy niż jeden kawałek FIFO.

Alternatywnym podejściem byłoby podłączenie CPLD do SRAM i stworzenie z nim prostego podsystemu wideo. Pod względem estetycznym podoba mi się generowanie wideo w locie, a jeśli ktoś stworzyłby tanie, tanie 1024-bitowe układy z przesuwnym rejestrem, preferuję takie podejście, ale korzystanie z zewnętrznej pamięci SRAM może być tańsze niż korzystanie z FPGA z wystarczającą ilością zasobów, aby wykonaj wiele 1024-bitowych rejestrów przesuwnych. W celu uzyskania rozdzielczości wyjściowej konieczne będzie wyrejestrowanie danych z szybkością 12 mln pikseli / s lub 3 MB / s. Powinno być możliwe zaaranżowanie rzeczy tak, aby dane mogły być taktowane z prędkością do 10 Mb / s bez większych trudności dzięki przeplataniu cykli pamięci; największą sztuczką byłoby zapobieganie uszkodzeniu danych, jeśli puls synchronizacji nie nadejdzie w spodziewanym momencie.