Le Field Programmable Gate Arrays, o FPGAs, sono diventati onnipresenti nei sistemi digitali ad alta velocità e in tempo reale. Possono essere utilizzati per applicazioni critiche in termini di tempo, elaborazione del segnale digitale o persino mining di criptovalute. La loro efficienza in termini di velocità e consumo energetico li rende perfetti per applicazioni riutilizzabili ad alta velocità. La velocità con cui operano gli FPGAs continua ad aumentare a un ritmo vertiginoso, ma la loro adozione nei pipeline di integrazione continua (CI) non sembra seguire altrettanto velocemente. In questo articolo esamineremo il concetto di pipeline CI, la loro applicazione agli FPGAs e vedremo esempi su come configurarle.
Se non lo avete ancora notato, praticamente mangio, dormo e respiro Integrazione Continua. Che si tratti di CI per la progettazione di PCB o di CI per sistemi embedded, sono sempre alla ricerca di modi per migliorare e automatizzare continuamente i build per qualsiasi tipo di sistema. Alcuni feedback recenti che ho ricevuto da persone indicano che non è stato fatto molto progresso con gli FPGAs e i sistemi CI. Il vero principio dietro CI e FPGAs segue la stessa logica di tutti gli altri sistemi CI: creare un ambiente di build ripetibile che possa svolgere tutto il lavoro pesante per noi. In un sistema CI basato su FPGA vedremmo tipicamente le seguenti tre fasi:
Figura 1: Fasi di un pipeline CI per FPGA
Ogni fase è importante di per sé e richiede una propria configurazione. Esaminiamo ciascuna fase per capire cosa rappresenta e come implementarla.
La simulazione è una parte integrante della progettazione di FPGA. La creazione di un'immagine FPGA da caricare su un target può richiedere molto tempo. Piuttosto che scrivere codice, costruire e testare l'hardware, la simulazione ci dà la possibilità di testare rapidamente il nostro codice, o Register-Transfer Level (RTL), all'interno di un ambiente che simula il comportamento di un FPGA. Generalmente ciò avviene a livello dell'utente, ma sta diventando sempre più comune integrare la simulazione FPGA nei pipeline CI. Questo significa che qualcuno spingerebbe il proprio codice nel repository e un pipeline partirebbe per eseguire la simulazione (auto-controllata) da qualche parte nel cloud. Per farlo davvero "da qualche parte nel cloud", è necessario creare un ambiente che possa essere incapsulato, o containerizzato, in un ambiente autosufficiente. Lo facciamo usando qualcosa chiamato contenitori Docker. Questi agiscono quasi come macchine virtuali che possono essere eseguite ovunque. Questo particolare contenitore Docker, ad esempio, crea un ambiente containerizzato che consente a un utente di eseguire Icarus Verilog all'interno di qualsiasi sistema Linux. Quindi prendiamo quel contenitore e lo utilizziamo per creare il nostro pipeline di simulazione FPGA. In questo esempio puoi vedere un semplice pipeline “Hello World” eseguito nel cloud utilizzando Icarus Verilog. Si noti che questo può essere fatto con qualsiasi strumento di simulazione FPGA.
Figura 2: Esecuzione del pipeline di simulazione FPGA utilizzando GItlab CI
Drugim, również bardzo ważnym, etapem w ramach pipeline’u FPGA jest etap kompilacji. Chcemy być w stanie syntezować, rozmieszczać i trasować oraz generować strumień bitów dla naszego projektu FPGA. Zazwyczaj użytkownicy wykonują to w narzędziu dostarczonym przez producenta (np. Xilinx, Intel, Microchip itp.). Zamiast wykonywać tę kompilację lokalnie, chcielibyśmy, aby kompilacja odbywała się gdzie indziej. Może to być jednak nieco skomplikowane, ponieważ narzędzia FPGA są zazwyczaj bardzo duże. Jednym z podejść, które stosuje wielu użytkowników, jest posiadanie dedykowanej „maszyny do kompilacji”, która uruchamia wszystkie pipeline’y kompilacyjne. To podejście nie jest złe, ale również nie skaluje się dobrze i może stać się pojedynczym punktem awarii. Inni próbowali kontenerować narzędzia FPGA, ale te obrazy mogą przekraczać 100 GB, co czyni je praktycznie nieużywalnymi w aplikacjach chmurowych. Środkową drogą, którą odkryłem, że działa dobrze, jest metoda instalacji sieciowej. Jako przykład stworzyłem kontener, który uruchamia Vivado 2019.1, ale samo narzędzie nie jest zainstalowane na obrazie (dzięki czemu jego rozmiar wynosi mniej niż 300 MB). Co zrobiłem, to zainstalowałem Vivado na dysku sieciowym (w tym przypadku na EFS w AWS) i zamontowałem go w moim kontenerze Docker. Ponieważ uruchamiam pipeline w AWS, opóźnienie między EFS a instancją EC2 (węzeł Kubernetes) jest znikome.
W tym przykładzie używam urządzenia Arty A7 od Digilent do stworzenia filtra cyfrowego. Używam automatycznego skryptu kompilacyjnego do wygenerowania pliku strumienia bitów dla mojego urządzenia przy każdym wprowadzeniu zmian do mojego repozytorium. Jak widać w wynikach, z powodzeniem wywołuję Vivado, mimo że nie istnieje ono w kontenerze Docker (tj. jest zamontowane jako zewnętrzny dysk).
Rysunek 3: Uruchamianie pipeline’u kompilacji FPGA przy użyciu GItlab CI
Faza testowania zależy od każdego użytkownika i projektu. Celem testowania w ramach pipeline’u CI jest automatyzacja jak największej liczby procesów. Tak jak zautomatyzowałem mój przykład DSP dla Arduino przy użyciu Analog Discovery 2, mogę to samo zrobić tutaj. Omówienie zautomatyzowanego rozwiązania testowego dla FPGA wykraczałoby nieco poza zakres tego artykułu. Główną zasadą tutaj jest zapewnienie, że proces testowania może być powtarzalny i uruchamiany w środowisku kapsułkowanym lub kontenerowym. Ważne jest, aby pamiętać, że testowanie jest istotnym elementem pipeline’u CI i powinno być implementowane na poziomie, który użytkownik może obsłużyć.
W tym artykule omówiliśmy koncepcję pipeline’ów CI dla FPGA. Przeanalizowaliśmy trzy krytyczne etapy, które składają się na pipeline FPGA: symulacja, kompilacja i testowanie. Zobaczyliśmy przykłady pipeline’ów symulacji i kompilacji oraz omówiliśmy znaczenie testowania. Po zapoznaniu się z tym artykułem i przykładami użytkownik powinien być w stanie zrozumieć podstawowe elementy niezbędne do stworzenia pipeline’u CI opartego na FPGA.
Kiedy będziesz gotowy do zbudowania swojej własnej niestandardowej płytki FPGA wspierającej system wbudowany, skorzystaj z pełnego zestawu funkcji do projektowania i rozmieszczenia PCB dostępnych w Altium Designer®. Kiedy skończysz projekt PCB i będziesz gotowy do podzielenia się swoimi projektami z współpracownikami lub producentem, możesz udostępnić swoje gotowe projekty za pośrednictwem platformy Altium 365™. Wszystko, czego potrzebujesz do zaprojektowania i produkcji zaawansowanej elektroniki, znajdziesz w jednym pakiecie oprogramowania.
Zaledwie powierzchownie dotknęliśmy tego, co można zrobić z Altium Designer na platformie Altium 365. Rozpocznij darmowy okres próbny Altium Designer + Altium 365 już dziś.