Przegląd otwartych narzędzi dla układów FPGA

Przegląd otwartych narzędzi dla układów FPGA
Pobierz PDF Download icon

Otwarte narzędzia, służące do tworzenia oprogramowania dla mikrokontrolerów jednoukładowych, są powszechnie stosowane w projektach komercyjnych od dłuższego czasu. Obecnie jakość kodu generowanego przez kompilatory dla architektury ARM jest na tyle duża, że producentom środowisk programistycznych nie opłaca się tworzyć autorskich rozwiązań. Coraz powszechniejszą praktyką wśród producentów narzędzi komercyjnych jest tworzenie środowiska IDE wraz z odpowiednimi kreatorami, które wewnętrznie wykorzystują kompilator GCC, pozwalając, za pomocą kilku ruchów myszką, wygenerować szkielet projektu dla wybranego mikrokontrolera. Zupełnie inaczej wygląda sytuacja w przypadku narzędzi, służących do projektowania urządzeń, opartych na układach FPGA.

Spis treści

W przypadku układów FPGA do niedawna jedynym rozwiązaniem było skorzystanie z komercyjnych narzędzi, dostarczanych przez producentów.

Narzędzia tego typu, w podstawowej wersji, są zazwyczaj darmowe, jednak nie mamy możliwości wglądu w kod źródłowy, co może być problemem dla niektórych rodzajów projektów. Przygotowanie otwartych narzędzi dla układów FPGA jest zadaniem zdecydowanie bardziej skomplikowanym w porównaniu do kompilatorów, gdzie dostępna jest specyfikacja instrukcji maszynowych procesora oraz ich kody maszynowe. Dzięki dokumentacji ISA niezależni programiści mogą bez większych kłopotów opracować odpowiednie narzędzia jak, kompilator asembler, itd., na bazie dokumentacji dostarczanej przez producenta. W przypadku układów FPGA dokumentacja dla pliku binarnego, służącego do konfiguracji FPGA oraz szczegóły architektoniczne są najczęściej pilnie strzeżoną tajemnicą. Dlatego opracowanie otwartych narzędzi wymaga wcześniejszego zastosowania inżynierii wstecznej, co jest zadaniem czasochłonnym. Należy wziąć pod uwagę, że nie wszystkie zawiłości uda się odkryć tym sposobem, a zatem finalne rezultaty mogą znacząco odbiegać od komercyjnych rozwiązań. Z drugiej strony, producenci oprogramowania, z uwagi na nakład czasu i środków poświęconych na rozwój narzędzi oraz przewagę konkurencyjną, nie mogą sobie pozwolić na publikację kodów źródłowych. Niemniej sytuacja nie jest tak beznadziejna, jak mogłoby się wydawać, ponieważ niektóre typy układów FPGA, wykorzystaniu podstawowej dokumentacji dostarczanej przez producenta oraz inżynierii wstecznej, zostały bardzo dobrze rozpracowane. Miłośnicy otwartych rozwiązań mogą się pokusić o stworzenie własnego sprzętu w pełni wolnego od komercyjnych rozwiązań. Obecnie, z otwartymi narzędziami najlepiej współpracują układy rodziny Lattice ICE40 oraz ECP5. Niektóre układy firmy XILINX udoskonalono pod tym względem, ale do poprawnej pracy nadal konieczne jest użycie narzędzia bitgen pochodzącego z pakietu ISE, więc nie możemy powiedzieć, że na tę chwilę jest to rozwiązanie całkowicie otwarte.

Przegląd narzędzi open source

Zanim przejdziemy do przeglądu dostępnych narzędzi, spójrzmy, jak wygląda synteza projektu w układzie FPGA (tabela 1).

Proces syntezy wygląda podobnie dla większości układów i rozpoczyna się od analizy oraz syntezy pliku źródłowego (najczęściej Verilog, VHDL), w wyniku czego powstaje ogólna lista połączeń, czyli schemat wewnętrzny układu. Lista jest generyczna i na tym etapie nie zawiera cech specyficznych dla topologii konkretnego układu FPGA. W kolejnym kroku „Place and Route” następuje proces rozmieszczenia oraz optymalizacji elementów, z uwzględnieniem topologii i architektury wybranego układu tak, aby długość połączeń wewnętrznych była jak najkrótsza, a liczba użytych elementów LUT jak najmniejsza. Efektem jest lista połączeń, specyficzna dla danego układu, która w kroku asemblacji zamieniana jest na plik bitstream, opisujący sposób połączenia bloków wewnętrznych układu. Plik ten jest dalej wykorzystywany bezpośrednio do konfiguracji FPGA lub do zaprogramowania pamięci konfiguracyjnej.

Odrębnym etapem jest analiza projektu, na który składa się analiza czasowa oraz symulacja logiczno-behawioralna, wykonywana bezpośrednio na komputerze PC, pozwalająca sprawdzić poprawność logiczną utworzonego projektu. W przypadku symulacji i wizualizacji, podobnie jak poprzednio, pliki HDL są syntezowane do ogólnej listy połączeń, zmienianej na model behawioralny, który może być symulowany bezpośrednio na komputerze PC. Efektem symulacji jest plik, zawierający przebiegi czasowe działającego układu, który możemy poddać analizie pod kątem poprawności.

Jeśli chodzi o języki HDL, wspierane przez narzędzia open source, to obecnie wsparcie skupione jest na języku Verilog. VHDL wspierany jest w mniejszym stopniu, głównie w charakterze eksperymentalnym.

Przegląd rozpoczynamy od narzędzi związanych z symulacją oraz wizualizacją projektów, co jest zadaniem prostszym, ponieważ nie wymaga specyficznych danych na temat architektury wybranego układu. Tutaj najbardziej kompleksowym narzędziem jest „Icarus Verilog” (http://iverilog.icarus.com/home), dostępny na licencji GPL. Pakiet ten wspiera Verilog w standardzie 1995/2001/2005 oraz częściowo SystemVerilog. Kompilator zapewnia bardzo dokładną analizę składni i z reguły wykrywa dużo więcej problemów niż narzędzia komercyjne, a zatem świetnie nadaje się na etapie projektowania oraz symulacji. W wyniku działania narzędzia powstaje model behawioralny, który jest kompilowany do kodu pośredniego VVP. Kod pośredni może być uruchamiany za pomocą interpretera VVP, w efekcie czego powstaje plik wynikowy z przebiegami wyjściowymi. Tak powstały plik może być przeglądany za pomocą narzędzia GTKWave, które jest szeroko wykorzystywane przez wszelkiego rodzaju narzędzia symulacyjne. Symulacja działa niezbyt szybko, co jest główną wadą programu, ponieważ wykorzystywany jest kod pośredni, który musi być interpretowany przez maszynę wirtualną VVP.

Innym przydatnym narzędziem podczas symulacji i testowania może być projekt „Verilator” (https://github.com/verilator/verilator), dostępny na licencji LGPL, który również może być używany do symulacji układu na maszynie docelowej. W przeciwieństwie do poprzednio omówionego narzędzia, zamienia on kod Verilog na kod w języku C++, który następnie może być skompilowany z wykorzystaniem dowolnego kompilatora. Dzięki takiemu rozwiązaniu symulacja przebiega dużo szybciej, z uwagi na natywne wykonywanie kodu maszynowego przez procesor. Dodatkowo, do wygenerowanego kodu mogą być dodawane własne elementy programu w języku C++, dzięki czemu układ, który chcemy symulować, możemy połączyć z innym rzeczywistym sprzętem, np. wykorzystując porty GPIO płytki z Linuxem. Innym przykładowym zastosowaniem, w przypadku gdy mamy zaimplementowany jakiś procesor dla FPGA (np. RISCV), jest możliwość uruchamiania kodu dla tego procesora w trybie symulacji.

Rozwiązanie to nie jest pozbawione wad, a największy problem to brak możliwości pisania bezpośrednio kodu testowego „test bench”, ze względu na nieobsługiwane komendy, które nie są syntezowane do bramek logicznych. Dlatego w klasycznych przypadkach dużo lepszym rozwiązaniem będzie wykorzystanie oprogramowania „Icarus Verilog”, który jest typowym narzędziem symulacyjnym.

Jeśli ktoś jest zainteresowany językiem VHDL, to narzędziem godnym uwagi jest GHDL (http://ghdl.free.fr), który podobnie jak Verilator zamienia VHDL bezpośrednio na kod maszynowy, wykorzystując wewnętrzne wywołania kompilatora GCC lub LLVM, do wygenerowania kodu maszynowego, który może być uruchomiony na komputerze. Wynikiem działania programu jest plik wynikowy z przebiegami czasowymi symulacji gHDL, który następnie może być analizowany.

Przejdźmy teraz do narzędzi związanych z syntezą układu w rzeczywistych układach FPGA. Tutaj wybór jest zdecydowanie mniejszy. Do dyspozycji mamy w zasadzie trzy narzędzia:

Dwa ostatnie narzędzia wykorzystywane są głównie w zastosowaniach akademickich oraz do badania różnych algorytmów „Place and Route”, bez konkretnej implementacji dla układów FPGA. W związku z powyższym jedynym wyborem pozostaje Yosys, który zapewnia wsparcie dla układów Xilinx7 oraz Lattice iCE40. Jest to stosunkowo nowe narzędzie, napisane w nowoczesny sposób, z wykorzystaniem języka C++. Jego główna zaleta to uywanie z bibliotek dedykowanych bloków dla układów FPGA, np. jeżeli w konkretnym układzie będziemy mieli zintegrowany komponent BLOCK RAM, yosys umożliwi nam skorzystanie z niego. Głównym ograniczeniem narzędzia jest to, że obecnie wspierany jest jedynie Verilog, ale w przyszłości planowane jest dodanie wsparcia dla VHDL.

Przejdźmy teraz do narzędzi związanych z rozmieszczaniem bloków oraz trasowaniem połączeń, umożliwiających przejście od ogólnej listy połączeń do netlisty, specyficznej dla danego układu. Na działanie tego typu narzędzi składają się następujące kroki: zgrupowanie elementów w większe bloki; rozmieszczenie poszczególnych bloków w układzie FPGA tak, aby znajdowały się jak najbliżej siebie; połączenie bloków jak najkrótszymi ścieżkami tak, aby osiągnąć jak największą częstotliwość pracy układu. Programy realizujące takie zadania to:

VPR jest wykorzystywany głównie w środowisku naukowym, do badania algorytmów „Place and Route” i nie znajduje zastosowań praktycznych. Kolejne narzędzie ArachnePNR jest narzędziem specyficznym dla układów Lattice iCE40. Obecnie, wsparcie dla niego zostało zarzucone, choć po dzień dzisiejszy jest powszechnie wykorzystywany w niektórych projektach. Wadą jest również to, że nie działa optymalnie.

Współcześnie polecanym narzędziem jest program NextPNR, który jest narzędziem niezależnym od układu. Aktualnie wspiera rodziny układów firmy Lattice: iCE40 oraz ECP5. Trwają prace nad wsparciem dla układów firmy Xilinx. Dzięki modułowej budowie w łatwy sposób może być rozszerzany o wsparcie dla kolejnych rodzin układów. NextPNR zawiera również edytor graficzny, umożliwiając ręczne rozmieszczenie i trasowanie najbardziej krytycznych czasowo elementów (rysunek 1).

Rysunek 1. Edytor graficzny NextPNR

Ostatnim elementem potrzebnym do przygotowania projektu dla FPGA jest proces asemblacji, przekształcający listę komponentów specyficzną dla danego układu na bitstream, umożliwiający konfigurację układu docelowego. Jest to jeden z najpilniej strzeżonych przez producentów układów fragment specyfikacji. Z tej przyczyny format pliku konfiguracyjnego bitstream w otwartych narzędziach jest odtwarzany za pomocą inżynierii wstecznej. Do realizacji tego zadania w zasadzie jedynym dostępnym otwartym narzędziem jest oprogramowanie IceStorm, współpracujące z rodziną układów iCE40.

Artykuł ukazał się w
Elektronika Praktyczna
wrzesień 2020
DO POBRANIA
Pobierz PDF Download icon

Elektronika Praktyczna Plus lipiec - grudzień 2012

Elektronika Praktyczna Plus

Monograficzne wydania specjalne

Elektronik kwiecień 2024

Elektronik

Magazyn elektroniki profesjonalnej

Raspberry Pi 2015

Raspberry Pi

Wykorzystaj wszystkie możliwości wyjątkowego minikomputera

Świat Radio marzec - kwiecień 2024

Świat Radio

Magazyn krótkofalowców i amatorów CB

Automatyka, Podzespoły, Aplikacje marzec 2024

Automatyka, Podzespoły, Aplikacje

Technika i rynek systemów automatyki

Elektronika Praktyczna kwiecień 2024

Elektronika Praktyczna

Międzynarodowy magazyn elektroników konstruktorów

Elektronika dla Wszystkich kwiecień 2024

Elektronika dla Wszystkich

Interesująca elektronika dla pasjonatów