Realizacja operacji nadzoru wizyjnego w czasie rzeczywistym jest zadaniem skomplikowa-nym, które wymaga obróbki du ˙zej ilo´sci danych obrazowych w krótkim czasie. Wykony-wanie tego zadania w w˛e´zle sieci wielokamerowej wymaga skonfigurowania wysokowy-dajnej obliczeniowo i oszcz˛ednej energetycznie architektury potoku przetwarzaj ˛acego. Aby sprosta´c tym przeciwstawnym wymaganiom opracowana została architektura kamery in-teligentnej opartej o układ FPGA Xilinx Zynq. Omawiana architektura jest uniwersalna poniewa ˙z mo ˙ze stanowi´c platform˛e ramow ˛a umo ˙zliwiaj ˛ac ˛a dostosowanie kamery do kon-kretnych potrzeb realizowanego zadania. W rozprawie wybrano algorytmy dla z ró ˙znych poziomów przetwarzania obrazu i zaimplementowano je z wykorzystaniem przedstawionej architektury.
Przeciwstawne oczekiwania du ˙zej mocy obliczeniowej i niskiego zapotrzebowania na energi˛e zasilania sprawiaj ˛a, ˙ze wybór platformy obliczeniowej dla kamery inteligentnej jest skomplikowanym zadaniem. W przeprowadzonych wcze´sniej pracach [105], [80] szereg
algorytmów przetwarzania obrazów zaimplementowano w układach FPGA z rodzin Spar-tan 6 oraz Virtex 6. We wspominanych projektach wykorzystywano logik˛e programowaln ˛a celem znacznego przyspieszenia operacji przetwarzania obrazu, podczas gdy operacje zwi ˛ a-zane z komunikacj ˛a i kontrol ˛a przepływu zrealizowano na osadzonym w logice mikropro-cesorze MicroBlaze. Ta cz˛e´s´c zada ´n, która była trudna do implementacji sprz˛etowej w logice reprogramowalnej została rozdzielona pomi˛edzy kilka rdzeni MicroBlaze. W zwi ˛azku z ograniczon ˛a wydajno´sci ˛a obliczeniow ˛a rdzeni nale ˙zało u ˙zy´c kilka takich jednostek, co wpły-wało znacz ˛aco na zu ˙zycie zasobów logicznych układu FPGA.
Pojawianie si˛e układów Xilinx Zynq, w których na stałe osadzono dwa wysokowydajne rdzenie ARM Cortex A9 (szczegółowo opisane w rozdziale 3) pozwoliło na opracowanie efektywnych, mieszanych, heterogenicznych architektur. W rozwi ˛azaniach opartych o te układy akceleratory sprz˛etowe pracuj ˛a współbie ˙znie z procesorami ogólnego przeznacze-nia (GPCPU). Rozwi ˛azanie zaprezentowane w niniejszej pracy doktorskiej charakteryzuje si˛e na takim podej´sciem. Odznacza si˛e ono istotnymi zaletami wzgl˛edem rozwi ˛aza ´n zapre-zentowanych w 2.2.4, jako, ˙ze integracja CPU oraz akceleratorów sprz˛etowych w jednym układzie scalonym umo ˙zliwia szybk ˛a i wydajn ˛a komunikacji pomi˛edzy nimi. Nale ˙zy jed-nak zauwa ˙zy´c, ˙ze rozwi ˛azanie takie, mimo swoich zalet jest trudne w implementacji. Głów-nym celem rozprawy jest zaprojektowanie architektury ułatwiaj ˛acej implementacj˛e poprzez zaoferowanie systemu uniwersalnych modułów umo ˙zliwiaj ˛acych łatw ˛a integracj˛e nowych funkcjonalno´sci kamery.
Przedstawione rozwi ˛azanie jest ogólnym (ramowym) systemem wła´sciwym dla hete-rogenicznych układów firmy Xilinx, gdy ˙z pozwala na łatw ˛a integracj˛e sprz˛etowych akce-leratorów z algorytmami wysokiego poziomu (np. wykorzystuj ˛acymi takie biblioteki jak OpenCV), wykonywanymi na rdzeniach ARM Cortex A9. W przedstawionej architektu-rze wyst˛epuj ˛a moduły odpowiedzialne za transport danych do przetworzenia pomi˛edzy elementami systemu, a tak ˙ze do/z pami˛eci zewn˛etrznej. W architekturze wyst˛epuje uni-wersalny interfejs umo ˙zliwiaj ˛acy prost ˛a reparametryzacj˛e wykorzystywanych akcelerato-rów sprz˛etowych. Schemat blokowy architektury przedstawiono na obrazie 5.1.
Przyj˛eto podstawowy paradygmat, ˙ze zadania kosztowne obliczeniowo powinny by´c realizowane przez dedykowane i zoptymalizowane akceleratory zaimplementowane sprz˛e-towo w cz˛e´sci układu okre´slonej jako logika reprogramowalna. Podej´scie to pozwala uzy-skiwa´c rozwi ˛azania o niskim zu ˙zyciu energii przy zachowaniu wymaganej szybko´sci wy-konywania zadania. Wysoka wydajno´s´c jest uzyskiwana dzi˛eki szerokiemu zastosowaniu zrównoleglania oblicze ´n. Niestety, nie wszystkie algorytmy analizy obrazu s ˛a podatne na zrównoleglanie, szczególnie gdy wymagaj ˛a losowego dost˛epu do pami˛eci (instrukcje wa-runkowe), a nie operowania na strumieniu danych. Przykładowy system zaprezentowany na schemacie 5.1 pobiera wej´sciowe dane obrazowe bezpo´srednio z sensora wizyjnego, a nast˛epnie przekazuje je do pierwszego dedykowanego koprocesora strumieniowego. To pozwala wykorzysta´c ró ˙zne moduły zapewniaj ˛ace dane wej´sciowe w postaci strumienia jak np. kamery IP GigE Vision, podł ˛aczone bezpo´srednio do interfejsu Ethernet, czy dane za-warte w pami˛eci zewn˛etrznej. W ka ˙zdym z tych przypadków wymagana jest jedynie kon-wersja pikseli do standardowego interfejsu AXI4-Stream. Tak zorganizowane dane mog ˛a
Rysunek 5.1: Schemat blokowy proponowanej architektury procesora wizyjnego
by´c podane do jednego lub wielu jednostek wykonawczych równocze´snie. Ka ˙zda z jedno-stek zawiera logik˛e kontroln ˛a oraz procesor strumieniowy. Szczegółowa budowa jednostki wykonawczej została zaprezentowana na obrazie 5.2.
Dane wej´sciowe s ˛a dostarczane zgodnie ze specyfikacj ˛a formatu AXI4-Stream i dodat-kowo buforowane za pomoc ˛a wej´sciowej oraz wyj´sciowej kolejki FIFO. Procesor strumie-niowy wykonuje operacje tylko wtedy, gdy dost˛epne s ˛a dane wej´sciowe (zbuforowane w wej´sciowym FIFO), a wyj´sciowa kolejka FIFO nie jest pełna. Podej´scie takie pozwala na stosowanie ró ˙znych cz˛estotliwo´sci taktowania poszczególnych elementów tego modułu, co mo ˙ze by´c przydatne, gdy np. dane s ˛a dostarczane jako wektory 256-bitowe, a koproce-sor strumieniowy operuje na pojedynczych pikselach (dane o rozmiarze 8-bitów). Mo ˙zliwe wówczas jest taktowanie procesora strumieniowego z kilkukrotnie wy ˙zsz ˛a cz˛estotliwo´sci ˛a w celu zapewnienia przetwarzania danych z pr˛edko´sci ˛a z jak ˛a s ˛a dostarczane. Przedsta-wiony na schemacie moduł kontrolny jest uniwersalnym elementem, który umo ˙zliwia ła-twe przesyłanie parametrów konfiguracyjnych do procesora strumieniowego. Umo ˙zliwia to u ˙zytkownikowi skupienie si˛e na projektowaniu istotnego algorytmu przetwarzania
ob-Rysunek 5.2: Schemat blokowy pojedynczej jednostki wykonawczej
razów jako procesora strumieniowego, bez potrzeby zapewnienia mu odpowiednich mo ˙z-liwo´sci komunikacyjnych. Interfejsem komunikacyjnym wykorzystywanym przez uniwer-salny kontroler jest standardowy interfejs AXI4-Lite.
Jak przedstawiono na rysunku 5.1, jednostki wykonawcze mog ˛a by´c ł ˛aczone mi˛edzy sob ˛a pod warunkiem, ˙ze wyj´scie bloku poprzedzaj ˛acego jest kompatybilne z wej´sciem ko-lejnego modułu. Podej´scie to mo ˙ze by´c zastosowane np. w kolejnych operacjach filtracji, czy operacjach morfologicznych lub w poł ˛aczeniu detektora cech punktowych z deskryp-torem tych cech, bez konieczno´sci przechowywania danych tymczasowych w zewn˛etrznej pami˛eci. W ka ˙zdym przypadku, ko ´ncowy rezultat działania takiej kaskady procesorów jest zapisywany w pami˛eci zewn˛etrznej przy u ˙zyciu jednostek DMA, czyli z wykorzystaniem bezpo´sredniego dost˛epu do pami˛eci. Operacja ta jest wykonywana przez moduł sprz˛etowy, bez u ˙zycia procesora po´srednicz ˛acego. Podej´scie to jest korzystne z punktu widzenia wy-dajno´sci całego systemu jako, ˙ze zapewnia, ˙ze wszystkie transfery do/z jednostek wyko-nawczych s ˛a realizowane wył ˛acznie przez kontroler pami˛eci. Tak zapisane dane mog ˛a by´c w nast˛epnych etapach pobrane przez inne jednostki wykonawcze lub programy działaj ˛ace na rdzeniach procesorowych (GPCPU). Przy takim podej´sciu tym mo ˙zna traktowa´c rdzenie CPU równie ˙z jako jednostki wykonawcze. Nale ˙zy jednak mie´c na uwadze, ˙ze s ˛a one na stałe
osadzone jako dwa rdzenie i nie ma mo ˙zliwo´sci ich dodatkowego zreplikowania. W przy-padku wykorzystania architektury w kamerze inteligentnej cz˛e´s´c procesorowa jest równie ˙z wykorzystywana do obsługi interfejsów komunikacyjnych takich jak Ethernet czy WiFi, a tak ˙ze do sterowania innymi jednostkami wykonawczymi.
Zaprezentowana architektura kamery inteligentnej mo ˙ze by´c przydatna w takich zasto-sowaniach jak automatyczny nadzór wizyjny, czy inspekcja produktów na linii produkcyj-nej. W ka ˙zdym z tych przypadków proces projektowania powinien by´c rozpocz˛ety od przy-gotowania w pełni programowej implementacji systemu, a nast˛epnie na przeniesieniu ob-liczeniowo zło ˙zonych elementów do logiki programowalnej, w której zaimplementowano akceleratory sprz˛etowe. Algorytmy wykonuj ˛ace operacje na poziomie pojedynczych pikseli lub pewnego regionu (zbioru s ˛asiaduj ˛acych pikseli) s ˛a szczególnie predysponowane, jako,
˙ze mog ˛a by´c umieszczone bezpo´srednio za modułem akwizycji danych z kamery. Propo-nowane rozwi ˛azanie oparte o uniwersalne koprocesory upraszcza proces sprz˛etowej imple-mentacji i ukrywa przed u ˙zytkownikiem szczegóły zwi ˛azane z komunikacj ˛a. Algorytmy wysokiego poziomu jak np. rozpoznawanie obiektów mog ˛a, je´sli to mo ˙zliwe zosta´c za-implementowane jako procesory sprz˛etowe, lub, gdy nie jest to mo ˙zliwe, wykonywane na rdzeniach procesorowych. Zastosowane w układzie Xilinx Zynq rdzenie ARM Cortex A9 umo ˙zliwiaj ˛a zastosowanie systemu operacyjnego Linux, a tym samym dost˛ep do wielu bi-bliotek programowych, jak np. OpenCV. Modułowa architektura prezentowanego rozwi ˛ a-zania sprawia, ˙ze oparte o ni ˛a systemy mog ˛a w łatwy sposób by´c dopasowane do potrzeb re-alizowanego zadania poprzez replikacj˛e elementów wykonawczych w celu uzyskania wi˛ek-szego stopnia zrównoleglenia. Wartym odnotowania jest fakt, ˙ze o ile architektura jest de-dykowana dla kamer inteligentnych, to jej ogólny i modułowy charakter umo ˙zliwił inne zastosowania np. w projekcie dedykowanego akceleratora dla serwerowni. Rozwi ˛azanie to ł ˛aczyło akcelerator oparty o opisan ˛a architektur˛e z serwerem poprzez interfejs PCIe [107].