CPU w FPGA

Konkurencja na rynku między wiodącymi producentami FPGA i ich dążenie do jak największej oszczędności czasu projektantów sprawiły, że dostępna jest szeroka oferta gotowych rozwiązań. Duża różnorodność pozwala wybierać, poczynając od najprostszych 8-bitowych rdzeni, aż po konstrukcje 32-bitowe zawierające sprzętowe bloki DSP.

Mogą to być implementacje oparte na popularnej architekturze takiej jak ARM, bądź autorskie rozwiązanie producenta układu programowalnego, czego przykład stanowią procesory Nios i MicroBlaze. Wybór architektury, oprócz wpływu na wydajność i zużycie zasobów, wpływa także na sposób implementacji oraz determinuje, jakie narzędzia diagnostyczne będą dostępne.

Projekty wykorzystujące układ programowalny z obecnym w jego strukturze procesorem stały się popularne do tego stopnia, że producenci mają w swojej ofercie nawet rozwiązania zawierające sprzętowe ("twarde") rdzenie. Jest to znaczące ułatwienie pozwalające uniknąć wielu problemów z syntezą i testowaniem "miękkiego" procesora.

Specyfika procesora w strukturze FPGA

Rys. 1. Rdzeń Nios ewoluował z prostego kontrolera w pełnoprawny procesor wyposażony w zaawansowane bloki sprzętowe

Układy programowalne na przestrzeni lat przeszły znaczącą ewolucję. Wczesne ich wersje były na tyle ograniczone, że niewielkie zasoby logiczne były wystarczające do realizacji niezbyt złożonych zadań, takich jak kontroler magistrali, czy realizacja funkcji boolowskich.

Wraz z rozwojem technologii produkcji półprzewodników możliwe stało się zwiększenie zasobów logicznych. Z czasem ich liczba wzrosła do poziomu pozwalającego myśleć o opisie i osadzeniu prostego procesora. Początkowo nawet 4-bitowe jednostki stanowiły satysfakcjonującą realizację tego zagadnienia. Przy okazji zaczęły się ujawniać pierwsze trudności i ograniczenia związane z rdzeniami syntezowanymi z zasobów logicznych FPGA.

Pierwszym tego przejawem była znacząco mniejsza wydajność niż standardowych mikroprocesorów. Wynikało to bezpośrednio z niemożności stosowania technik dostępnych jedynie podczas opracowywania układu scalonego od podstaw - zapewniających większą wydajność przy mniejszym zajęciu powierzchni półprzewodnika.

Przykład tego typu technik stanowią bufory trójstanowe niedostępne w układach programowalnych. Również wykorzystanie szybkich rejestrów wieloportowych wymaganych przez jednostkę centralną znacznie podnosi wydajność przetwarzania. Elementy te potrafią zapewnić równoległy dostęp kilku blokom przetwarzania jednocześnie. Wspiera to w znacznym stopniu przetwarzanie potokowe, gdyż możliwe staje się obliczanie adresu, wykonywanie obliczenia i zapis wyników w jednym cyklu zegara.

W FPGA tablice LUT (look-up table) oraz pamięć RAM, wykorzystywane do tego celu, nie zapewniają same z siebie jednoczesnego dostępu do kilku bloków funkcjonalnych. Konieczne jest opracowanie układu arbitrażu w ramach dostępnych zasobów logicznych odpowiedzialnego za emulację wielodostępu do rejestrów.

Moduł ten, syntezowany i umieszczany wewnątrz FPGA, będzie spełniał swoją funkcję, ale związana z nim nadmiarowość przyczyni się do obniżenia maksymalnej częstotliwości taktowania rdzenia. Optymalizacja CPU sprowadza się do znaczącej reorganizacji pracy potoku tak, aby maksymalnie ograniczyć wykorzystanie rejestrów wieloportowych w rdzeniu.

Powszechnym problemem napotykanym podczas opisu procesora jest tzw. ścieżka krytyczna. Stanowi ona najdłuższe połączenie pod względem czasu propagacji sygnału. Tym samym wyznacza maksymalną częstotliwość taktowania układu, dla jakiej sygnał zdąży się na takiej ścieżce ustabilizować przed wystąpieniem zbocza sygnału zegarowego.

Wzrost złożoności układu sprawia, że zwiększa się liczba elementów logicznych, przez jakie propagowany jest sygnał, co wydłuża czas stabilizacji sygnału. Rozwiązanie stanowi optymalizacja opisu sprzętu i jego upraszczanie poprzez zmianę stosowanych konstrukcji i/lub wykorzystanie przetwarzania potokowego.

Problem ścieżki krytycznej stał się szczególnie dotkliwy, gdy projektanci rozpoczęli implementację bardziej złożonych rdzeni, takich jak np. ARM. Pojawiło się przekonanie, że procesory osadzone w strukturze FPGA są wolne, zużywają znaczne ilości energii i wykorzystują dużą ilość zasobów logicznych. W zaistniałej sytuacji implementacja CPU straciła na atrakcyjności.

W odpowiedzi na taki stan rzeczy Altera podjęła się opracowania procesora od podstaw z uwzględnieniem całej specyfiki układów programowalnych. W wyniku stosowania konstrukcji i technik naturalnych dla układów programowalnych oraz silnej optymalizacji opisów sprzętu powstał procesor Nios. Pomimo ograniczeń spełnia on swoją funkcję w większości typowych zastosowań.

Podobną strategię, opartą ma własnym, starannie zaprojektowanym rdzeniu, przyjął Xilinx, udostępniając projektantom procesor MicroBlaze z autorską architekturą. Do grona tego dołączyły także niezależne firmy oferujące gotowe rozwiązania oparte na ARM czy MIPS zaadaptowane dla potrzeb układów programowalnych.

Zastosowania

Rys. 2. Procesor MicroBlaze jest połączony z otoczeniem za pośrednictwem magistrali AXI (Advanced Extensible Interface)

W kontekście implementacji procesora w FPGA często pada pytanie o celowość takiego podejścia. Jest ono tym bardziej zasadne, że cena samodzielnego procesora może być niższa niż cena nawet najtańszych układów programowalnych. Pomimo tej oczywistości szacunki Altery wskazują, że w 30% sprzedawanych przez nią układów programowalnych umieszczany jest rdzeń Nios.

Niekiedy na taką decyzję wpływ mają przeprowadzone analizy wskazujące, że rezygnacja z zewnętrznego mikrokontrolera bądź procesora przyczyni się do oszczędności pieniędzy. Może to być spowodowane niemożliwością zdefiniowania wymaganego rozkładu wyprowadzeń procesora, co w przypadku FPGA pozwala zachować dużą elastyczność.

Ostateczna decyzja o wyprowadzeniach może być podjęta znacznie później i w razie potrzeby można ją zmienić, np. gdy urządzenia ma realizować nowe zadania. Osadzenie procesora bywa rozważane także w sytuacji, gdy dostępne w układzie programowalnym zasoby miałyby pozostać niewykorzystane, a dzięki obecności CPU możliwe jest uproszczenie i przyspieszenie pracy.

Okazuje się, że procesor stanowi najczęściej uzupełnienie dla zaimplementowanych bloków logicznych. Jako przykład można tu podać obsługę układów peryferyjnych (I²C, USART, przetworniki), nadzór nad poprawną pracą układów logicznych, realizację funkcji koprocesora w środowisku wieloprocesorowym lub w roli układu DSP. Ponadto obsługa interfejsów komunikacyjnych takich jak Ethernet, USB, SPI, USART jest łatwiejsza z wykorzystaniem CPU.

Niekiedy procesor może być użyty jako automat wielostanowy. Szeroki obszar zastosowań rdzenia Nios sprawił, że producent wzbogacił go o szereg dodatkowych funkcjonalności wspomagających jego pracę oraz moduł debugowania - rysunek 1. CPU dostępne jest w wariantach zoptymalizowanym pod kątem ekonomicznego zużycia zasobów bądź zwiększonej wydajności.

Warto wspomnieć o generatorze instrukcji umożliwiającym dodawanie nowych, samodzielnie zdefiniowanych rozkazów do listy tych już obsługiwanych. Najbardziej złożone aplikacje mogą zostać uruchomione w środowisku systemu operacyjnego Linux, w oparciu na dystrybucji przeznaczonej dla procesora Nios.

Xilinx opracował i udostępnił własny procesor MicroBlaze, który wpisuje się w trend zapewniania projektantom zoptymalizowanej jednostki CPU. Pakiet narzędzi EDK (Embedded Development Kit) jest zintegrowanym środowiskiem pozwalającym skonfigurować procesor i jego otoczenie oraz dodać potrzebne układy peryferyjne. Większość rzeczy można zrobić za pomocą kreatorów z graficznym interfejsem użytkownika, m.in.: wskazać, jakie moduły mają zostać dołączone, ustalić ich adres w przestrzeni adresowej.

Udostępniony kompilator języka C i debugger pozwalają tworzyć oprogramowanie szybciej i łatwiej, bez konieczności sięgania po dodatkowe narzędzia. Projektanci mają możliwość wykorzystania bloków sprzętowych opracowanych przez producenta, wśród których można wymienić liczniki, porty GPIO, port szeregowy, kontroler Ethernet, kontroler pamięci DDR, jednostki zmiennoprzecinkowe czy układy zarządzające pamięcią MMU. Podobnie jak dla Nios, również dla MicroBlaze dostępna jest dystrybucja Linuxa.

Warto wspomnieć, że Xilinx wprowadził na rynek układy z rodziny Zynq integrujące w sobie logikę programowalną oraz niezależny, sprzętowy procesor ARM Cortex-A9. Projektanci mają do dyspozycji wydajny, sprzętowy rdzeń procesora, dzięki czemu częstotliwość taktowania jest znacząco wyższa, a zasoby logiczne mogą zostać wykorzystane w innym celu.

Oferta Microsemi (dawniej Actel) obejmuje układy SoC (System on Chip) z rodziny SmartFusion wyposażone w blok logiki programowalnej, sprzętowy rdzeń Cortex-M3 oraz programowalne układy analogowe: ADC, DAC, komparator itp. Udostępniono także syntezowalne rdzenie oparte na architekturze 8051, Cortex-M1 oraz Leon. Ostatni z wymienionych jest przeznaczony do zastosowań militarnych.

Inny, liczący się na rynku producent układów programowalnych, jakim jest Lattice Semiconductor, opracował procesor oparty na rdzeniu LatticeMico32. Jest to autorska 32-bitowa architektura harwardzka z rozdzielonymi magistralami danych i programu. Jest ona funkcjonalnie zbliżona do wielu współczesnych rozwiązań i oferuje 5-stopniowy potok przetwarzania rozkazów, obsługę szybkiej pamięci RAM oraz pamięci cache, a układy peryferyjne mają postać bloków IP.

Na tle konkurencji wyróżniającą cechą LatticeMico32 jest otwarty dostęp do kodu źródłowego jednostki centralnej i niektórych bloków peryferyjnych. Również narzędzia przeznaczone dla tej jednostki są oparte na wolnych rozwiązaniach bazujących na GNU GPL (GCC, Eclipse). Procesor z tego względu można osadzić w układach programowalnych dowolnego producenta. Konsekwencją takiego podejścia jest mniejsza optymalizacja rdzenia, niemniej projektanci mając dostęp do źródeł, mogą się z nimi zapoznać, zmienić i dostosować do własnych potrzeb.

LatticeMico znajduje zastosowanie głównie podczas realizacji złożonych zadań niewymagających dużej szybkości, czego przykład stanowi komunikacja z otoczeniem (zewnętrzne układy scalone, interfejs użytkownika itp.). Również zarządzanie układem programowalnym i jego otoczeniem może być z powodzeniem zrealizowane przez ten procesor, warto tu wskazać zwłaszcza na bieżące monitorowanie zasilania, ocenę wydajności przetwarzania czy monitorowanie bezpieczeństwa.

System połączeń

Rys. 3. Środowisko Xilinx Platform Studio wykorzystywane do szybkiego budowania projektów bazujących na procesorze MicroBlaze

Bez względu na przeznaczenie czy rodzaj procesora konieczne jest rozwiązanie problemu magistral i dostępu do pamięci. Istnieje wiele sposobów zapewnienia wymiany danych między poszczególnymi blokami systemu mikroprocesorowego, począwszy od autorskich rozwiązań jak Avalon w układach Nios, a skończywszy na coraz bardziej powszechnym rozwiązaniu spotykanym w rosnącej grupie produktów AXI (Advanced eXtensible Interconnect) opracowanym przez ARM (wykorzystuje go m.in. MicroBlaze - rys. 2).

W obecnych czasach "goły" rdzeń to za mało, aby usatysfakcjonować projektantów, którzy oczekują pełnego i funkcjonalnego środowiska do szybkiego budowania działającego ekosystemu procesorowego. Narzędzie takie powinno oferować możliwość łatwego wskazywania, jakie elementy (pamięci, układy peryferyjne, kontrolery pamięci) mają wejść w skład systemu i zostać automatycznie podłączone.

Główne okno pakietu EDK udostępnionego przez firmę Xilinx i przeznaczonego do procesora MicroBlaze pokazuje rysunek 3. Kreatory pozwalają stworzyć docelowy system za pomocą graficznego interfejsu w którym można określić szczegółowo, co ma wejść w skład projektu. Możliwe jest wybranie z listy i dołączenie układów peryferyjnych (kontroler pamięci DDR, port szeregowy, pamięć cache, liczniki, system przerwań, etc.) oraz konfiguracja samego MicroBlaze (sprzętowa jednostka zmiennoprzecinkowa, układ MMU na potrzeby Linuxa, etc.). Połączenia pomiędzy poszczególnymi blokami wygeneruje EDK, ale możliwa jest ich zmiana lub dodawanie nowych. Pakiet SDK (Soft ware Development Kit) zawiera kompilator języka C/C++ oraz debugger z możliwością pracy krokowej i podglądu zmiennych.

Microsemi również udostępnia pakiet narzędzi z graficznym interfejsem użytkownika zapewniający projektantom możliwość wybierania bloków funkcjonalnych, pamięci, układów peryferyjnych i łączenie ich z CPU poprzez magistralą AHB (Advanced Highperformance Bus).

Lattice zdecydowało się postawić na magistralę Wishbone dostępną z otwartym kodem źródłowym, podobnie jak i sam rdzeń. Jest ona zbliżona do magistrali Avalon, jednakże różnice są na tyle znaczące, że wykluczają wzajemną kompatybilność. Lattice oferuje graficzne narzędzia do generowania plików RTL na podstawie schematu blokowego.

Ograniczenia narzucane przez pamięć

Rys. 4. Pełne testowanie systemu procesorowego w FPGA wymaga złożonego testowania z wykorzystaniem specjalizowanych bloków IP wymuszających testowane stany

Rozmiar pamięci RAM dla syntezowanych procesorów nie jest problemem, gdyż współczesne układy FPGA są wyposażone w pamięć blokową. Pojemność takiej pamięci może sięgać kilkudziesięciu megabitów w najbardziej rozbudowanych układach. Sytuacja komplikuje się jednak, gdy należy zapewnić sprawną wymianę danych między rdzeniem a pamięcią. Bezpośredni dostęp do RAM wprowadza opóźnienia w wykonywaniu instrukcji przez procesor.

Współcześnie procesory wyposażone są w pamięć podręczną, której zadanie polega na zmniejszeniu liczby odwołań do głównej pamięci i tym samym przyspieszeniu wykonania instrukcji. Warto zauważyć, że jej rozmiar, w procesorach przewidzianych do uruchamiania systemu operacyjnego, jest duży. Inaczej sytuacja wygląda, gdy CPU ma wykonywać relatywnie statyczne operacje - w takim przypadku często wystarczająca okazuje się prostsza pamięć podręczna z mapowaniem bezpośrednim bądź pamięć TCM (patrz ramka).

Microsemi w układach rodziny Smart-Fusion zapewnia dwa, wydzielone bloki pamięci SRAM o rozmiarze 32 kB na potrzeby rdzenia Cortex-M3, który zawiera własne, wbudowane mechanizmy zarządzające i obsługujące pamięć (w tym cache). Inaczej sytuacja wygląda, gdy wykorzystywany jest procesor oparty na Corteksie-M1, w którym pamięć podręczna nie jest obsługiwana. Projektantom pozostawiono możliwość włączenie do projektu pamięci TCM za pomocą udostępnionych narzędzi.

W produktach Xilinx implementacja pamięci cache odbywa się przy wykorzystaniu pamięci blokowej RAM lub pamięci syntezowanej z rejestrów. Cache jest najczęściej mapowany bezpośrednio, jednakże przewidziano możliwość zastosowania pamięci asocjacyjnej (znajdzie to jednak odzwierciedlenie w obniżeniu maksymalnej częstotliwości taktowania CPU wskutek wzrostu złożoności projektu).

Altera kwestię pamięci podręcznej w procesorach rodziny Nios pozostawiła do decyzji projektantów. Kontroler pamięci cache jest syntezowalny i wykorzystuje zasoby pamięci RAM układu FPGA. Może on być typu asocjacyjnego i według zapewnień producenta ma to niewielki wpływ na maksymalną częstotliwość pracy układu, niemniej odczuwalny wzrost wydajności przetwarzania jest uzależniony w dużej mierze od sposobu napisania samego kodu.

Specjalizowane bloki funkcjonalne

Korzyścią wynikająca z budowy systemów opartych na logice programowalnej i osadzonego w niej procesora jest możliwość wykorzystania sprzętowych akceleratorów. Są to bloki funkcjonalne opracowane w celu realizacji wyspecjalizowanych zadań bez angażowania mocy obliczeniowej CPU, często w jednym cyklu zegara. Należy podkreślić, że są to zwykle jednostki wysoce zoptymalizowane pod kątem użycia w konkretnym projekcie. Znaczna przewaga wydajności wynika również z możliwości zrównoleglenia pracy - w FPGA może być więcej niż jeden sprzętowy akcelerator.

Integracja własnego bloku sprzętowego z rdzeniem procesora przebiega w każdej rodzinie układów programowalnych nieco inaczej, niemniej producenci starają się zapewnić szybki i wygodny sposób realizacji tego zadania. W układach Nios istnieje możliwość definiowania własnych instrukcji i dodawania ich do standardowej listy rozkazów procesora.

Udostępnione narzędzia odpowiadają za wprowadzenie niezbędnych zmian w opisie sprzętowym, które uwzględnią cykl dekodowania i wykonania nowych rozkazów, tak aby były one akceptowane przez potok przetwarzający (pipeline). Rozbudowa zestawu instrukcji jest przydatna w sytuacji, gdy celowe jest przeciwdziałanie obniżeniu wydajność pracy CPU na skutek wykonywania określonych zadań.

Xilinx oferuje dwa sposoby dołączenia sprzętowych akceleratorów. Pierwszy jest oparty na magistrali AXI, do której można dołączyć własne bloki peryferyjne. Staną się one wtedy dostępne w przestrzeni adresowej procesora i możliwa będzie wymiana danych między CPU a układem peryferyjnym. Mechanizm ten jest powszechnie wykorzystywany w systemach opartych na standardowych procesorach i z punktu widzenia programisty jest on wygodny na etapie pisania kodu.

W przypadku mniej skomplikowanych bloków funkcjonalnych (np. filtrów cyfrowy) możliwe jest ich bezpośrednie zintegrowanie z rdzeniem procesora.

Weryfikacja projektu

Rys. 5. Pamięć podręczna mapowana bezpośrednio oraz 2-drożna

Weryfikacja projektów zawierających osadzony rdzeń procesora nastręcza szereg trudności. Na pierwszym etapie weryfikowana jest poprawność samego rdzenia - zarówno pod kątem współpracy z otoczeniem, jak i braku błędów w programie. Wykorzystanie CPU pochodzących od producentów FPGA, w wersji sprzętowej bądź syntezowanej, może okazać się najłatwiejszym i najszybszym rozwiązaniem.

Producenci zapewniają o gruntownym przetestowaniu i zweryfikowaniu poprawności dostarczonych implementacji razem z dołączonymi blokami IP. Ponadto dokładają oni wszelkich starań, aby projekt zbudowany na bazie takich komponentów był poprawny również w ujęciu całościowym, tzn. jako pełny system złożony z procesora i jego otoczenia.

Sprawa komplikuje się, gdy wykorzystywany jest rdzeń od zewnętrznych dostawców albo po wprowadzeniu przez projektantów własnych modyfikacji. Konieczna staje się ścisła kontrola projektu, gdyż nawet firmowe pakiety narzędzi producenta FPGA nie zawsze są w stanie wykryć wszystkie potencjalne problemy i właściwie przełożyć na język opisu sprzętu wprowadzone zmiany.

Podstawę stanowi bieżące monitorowanie zużycia zasobów logicznych oraz weryfikacja wyników syntezy na podstawie analizy schematu RTL i symulacji. Wszelkie nieoptymalne konstrukcje zawarte w opisie sprzętu najczęściej zwiększą zużycie zasobów logicznych i wydłużą ścieżkę krytyczną, w efekcie czego zmniejszy się dopuszczalna częstotliwość taktowania układu.

Wyzwanie stanowi również konieczność analizy projektu na poziomie dużo bardziej złożonym niż proste uruchomienie projektu na platformie sprzętowej i sprawdzenie, czy działa zgodnie z oczekiwaniami. Złożoność tego typu projektów wymusza użycie modeli czasowych oraz modeli symulacyjnych poszczególnych bloków funkcjonalnych. Nieodzowne często okazują się specjalizowane bloki IP przeprowadzające testy na wybranych elementach systemu - rysunek 4.

Problemy napotykane na etapie weryfikacji całego sytemu sprawiają, że projektanci często wolą rozpocząć pracę w oparciu o sprawdzony projekt referencyjny. Po uruchomieniu i zapoznaniu się z jego specyfiką następuje etap wprowadzania zmian i przystosowywania całości do wymagań projektowanej aplikacji.

Ograniczona zostaje tym samym złożoność procesu weryfikacji i większa jest szansa na poprawną pracę od razu po uruchomieniu, choćby w ograniczonym zakresie funkcjonalności. Metoda ta jest chętnie wybierana zwłaszcza przez osoby, które nie chcą zagłębiać się w analizę na poziomie schematu RTL i każdorazowo po wprowadzeniu drobnych modyfikacji testują działanie projektu na platformie sprzętowej.

Osobną kwestię stanowią błędy w oprogramowaniu procesora. Sytuacja jest o tyle korzystna, że jednostki osadzone w strukturze FPGA mogą być wspierane przez debuggery. Przykładowo układy SoC z rodziny Zynq-7000 (Xilinx) wyposażone w rdzeń Cortex-A9 mają moduł CoreSight opracowany przez ARM.

Pozwala on śledzić wykonanie programu, wstrzymywać go i tym samym ułatwia wyszukiwanie błędów i weryfikowanie poprawności oprogramowania. MicroBlaze ma port JTAG umożliwiający zastawianie pułapek (breakpoints) oraz krokowe wykonywanie programu. Podobnie rdzenie Nios oraz LatticeMico udostępniają mechanizmy umożliwiające pracę z debuggerem i ułatwiają tym samym wyszukiwanie błędów.

Szczegółowa analiza pracy całego urządzenia najczęściej wymaga włączenia do projektu bloku testującego. Blok taki, umieszczony w FPGA, może odpowiadać za wymuszanie bądź symulowanie konkretnych działań ze strony części sprzętowej. Wadę stanowi duża ilość czasu tracona na syntezę projektu, co jest szczególnie zauważalne dla dużych układach programowalnych z zajętą sporą częścią zasobów.

Alternatywę stanowią narzędzia diagnostyczne udostępniane przez producentów. Przykład stanowi ChipScope dostarczany przez Xilinxa dla produkowanych przez niego układów FPGA. Umożliwia on monitorowanie sygnałów wewnątrz układu programowalnego - możliwe staje się obserwowanie zmian rejestrów, magistral procesora, stanów automatów, itd.

Podsumowanie

Obecnie projektanci decydujący się wykorzystać procesor umieszczony w strukturze FPGA dysponują szerokim wyborem architektury oraz struktury całego systemu. Istnieje wybór pomiędzy jednostkami syntezowanymi z zasobów logicznych i sprzętowymi rdzeniami umieszczonymi razem z układem programowalnym w jednej obudowie.

Szeroka oferta pochodząca od producentów FPGA i niezależnych dostawców sprawia, że procesor może zostać dobrany adekwatnie do potrzeb - począwszy od prostych obliczeń i zarządzania pracą urządzenia, poprzez obsługę złożonych protokołów komunikacyjnych, a skończywszy na uruchamianiu kompletnego systemu operacyjnego takiego jak Linux.

Najczęstszym problemem staje się w takiej sytuacji wzrost złożoności projektu i utrudniona, wieloaspektowa weryfikacja obejmująca sprzęt, implementację w układzie programowalnym oraz debugowania oprogramowania. Niezbędny staje się opracowanie właściwego planu testowania, który obejmie wszystkie aspekty wymagane do poprawnego funkcjonowania całego systemu.

Jakub Borzdyński