Temat: Implementacja układu w tech. FPGA versus MCU
FPGA się nie nadaje do układów automatyki - to jakim cudem za granicą rozpisują się o ich użyciu choćby tu:
http://www.ecerg.com/iesres/data/Course_Florin_Birlean... czy tu:
http://ieeexplore.ieee.org/document/6843603/ czy nawet tu:
https://www.researchgate.net/publication/4173960_FPGA_I.... Niech się ten konstruktor trochę zastanowi nad tym co gada. FPGA czy w ogóle układy programowalne w końcu z założenia mają być do tworzenia jakichkolwiek układów cyfrowych wszelkiego zastosowania (w tym do sterowania czymkolwiek, choć z pewnym wyjątkiem o czym dalej).
Co do zalet implementacji w FPGA: na pewno nikt ci nie narzuca odgórnych rozwiązań, tylko sam sobie tworzysz cokolwiek jak ci wygodnie (czyli tworzysz układ dedykowany w praktyce). Z tego wynika szybkość tworzenia (nie tracisz czasu na czytanie manuali i innych dokumentów żeby poznać to jak kto sobie pewne rozwiązania wymyślił tak jak w mikroprocesorach). Ponadto zaleta taka, że taki układ możesz w każdej chwili gruntownie przebudować czy rozbudować i to dosłownie
pod względem struktury (mikroprocesor to wiadome, że to już gotowy układ i jego struktury nie zmienisz - co najwyżej możesz zmieniać wartości w rejestrach takiego układu i tylko manipulować instrukcjami, żeby przyspieszyć jego działanie - tylko to też wymaga czasu i poznania takiego układu i znów tracisz masę czasu na zapoznawanie się z działaniem układu). Do tego jeszcze możesz manipulować łatwiej opóźnieniami w FPGA niż w mikroprocesorze (w mikroprocesorze wszystko stałe to i ścieżek nie zmienisz, żeby zejść na czasach propagacji - w FPGA starczy pin planner, przeniesienie elementów i masz już zaoszczędzone piko czy nanosekundy). A i pewnych rzeczy po prostu na mikroprocesorze nie zrobisz (np: precyzyjnej linii opóźniającej o danej rozdzielczości do zastosowań metrologicznych czy w ogóle wszystkiego co związane jest z metrologią czasu w układach cyfrowych, a co ma zastosowanie w przypadku telekomunikacji i synchronizacji przesyłanych sygnałów - tu potrzebna pikosekundowa precyzja, której mikroprocesor ci nie zapewni). Oczywiście też w przypadku FPGA uniezależniasz się od myślenia instrukcjami, które ślesz do mikroprocesora (po prostu - coś nie pasuje, albo instrukcja za długo się wykonuje to w FPGA samemu se piszesz tak jak ci pasi, żeby też działało to wszystko w miarę szybko).
Wady: w zasadzie to są głównie związane z tym, że o ile w mikroprocesorze pewien problem rozwiążesz w paru linijkach w języku C to w FPGA ten sam problem zabierze ci więcej linijek czy to w VHDL-u czy Verilogu czy SystemVerilogu (np: taki odczyt danych z karty SD bazując na systemie plików FAT32 - w mikroprocesorach masz biblioteki, parę linijek i masz załatwiony odczyt, w FPGA natomiast pisać musisz maszynę stanów i myśleć sprzętowo, a nie programistycznie). Inna wada: do takich STM32 czy innych mikroprocesorów od razu ci dają bajery typu przetworniki, układy szyfrujące czy do obsługi SPI, które są od razu w nich (w FPGA już tak nie ma - stąd montaż komponentów podłączonych do układów, które jednak krocie kosztują i stąd płytki z FPGA są droższe niż te z mikroprocesorami, a tym samym implementacja robi się droższa). Ewentualnie problemem może być to, że FPGA obsługują sygnały do jakiegoś wybranego pułapu częstotliwości (np: Cyclone II, którego mam do dzisią obsłuży ci sygnały max. do 450 MHz, a więc nie ma mowy o budowie na tym procesora, który będzie ci działał z taktowaniem 1 GHz - więc i tu wszystkiego nie zbudujesz jednak, podczas gdy są mikroprocesory, które mogą na takim taktowaniu działać) oraz to, że ciężej jest tu robić optymalizację energii, żeby układ był możliwie energooszczędny (łatwiej to paradoksalnie robić w przypadku mikroprocesorów).
I tyle :)
пропозиції роботи
