Témakör: Tervezés
Kártyaszámítógép, extrával – 2. rész
Megjelent: 2018. május 08.
Áprilisi lapszámunkban elkezdtük egy olyan demonstrációs eszköz bemutatását, amely ránézésre alig különbözik a manapság számos forrásból elérhető hobbi-kártyaszámítógépektől, mégis olyan tulajdonságokat hordoz, amelyekkel a felhasználó betekintést nyerhet a nagy teljesítményű jel- és adatfeldolgozásban és számos más területen is egyre szélesebb körben tért hódító FPGA-elemek világába is. Az első rész hardver-áttekintése után a szoftvervonatkozásokból adunk ízelítőt.
Bevezető
Az EBV Elektronik Kft. AVNET alkatrészdisztribútor a szokásos kereskedelmi funkcióin kívül jelentős súlyt helyez arra is, hogy a felhasználók új technológiákat ismerhessenek meg, és ezeket könnyen – és „szervesen” – építhessék be új konstrukcióikba. E törekvés „tárgyi bizonyítékai” azok a demonstrációs eszközök, amelyekkel az AVNET Engineering Services a XILINX FPGA-gyártó vállalat termékeivel kapcsolatos ismeretekbe igyekszik bevezetni az érdeklődőket. A zedboard.org weblapon különböző „súlycsoportba” (és árkategóriába) tartozó termékneveket látunk. Ezek közül a „legkönnyebbek” egyike a MiniZed, amelyet azért választottunk vizsgálatunk tárgyául, mert számos szempontból talán ez áll a legközelebb a közismert Raspberry PI hobbiszámítógép-kártyákhoz. Ám ha nem lenne több a piacon kapható „Raspberry-utánérzéseknél”, nem is érdemelne különösebb figyelmet. Mint arra az előző részben is kitértünk, az igazi „extrát” a processzorfunkciót ellátó központi rendszercsip egyik perifériájának is tekinthető FPGA-szegmens jelenti. A kártya – a rendszercsip ARM Cortex-A9 processzormagjával és a nem törlődő memóriába telepített Linux operációs rendszerrel – természetesen használható „Raspberry-módra” enélkül is, de az olyan, mintha a gyerekünket úthengerrel vinnénk az óvodába: megtehetjük, csak éppen a jármű fő attrakcióját nem használtuk ki. Erre a célra a gyártó számos szoftverfejlesztő környezetet (Software Development Environment – SDE) ajánl, amelyek használatához nem kell több speciális ismeret, mint bármely grafikus felhasználói felületen használható C/C++ fejlesztői környezethez, mondjuk az Arduino- vagy a Raspberry Pi-ökoszisztémában. Egy véges terjedelmű cikkben nem tűzhettük ki célul a szoftvermunka minden részletének alapos bemutatását. Helyette inkább arra helyezzük a súlyt, hogy olyan lehetőségeket villantsunk fel – legalább „mintavételesen” –, amelyek új megoldásválasztékot adnak a beágyazott elektronikát fejlesztők kezébe.
1. ábra Nyílt forráskódú full HD videokamera Xilinx Zynq-alapú fejlesztőkártyával (projekt: https://www.apertus.org/axiom-beta)
Milyen többletet várhatunk az FPGA-perifériától?
Amint arra a cikk első részében is utaltunk, az FPGA lényegében egy „huzalozott logikával” megvalósított digitális feldolgozó célberendezésnek tekinthető azzal a többlettel, hogy a benne foglalt logikai alapelemek közötti huzalozás szoftverszerű fejlesztési módszerekkel újradefiniálható. Ezt a Xilinx-dokumentációk PL (Programmable Logic) rövidítéssel jelölik. Egy logikai céláramkör (függetlenül attól, hogy „véglegesen huzalozott” vagy „programozható”) gyorsabb működésű, mint egy „számítógépszerűen” működő, szekvenciálisan végrehajtódó program, ezért az FPGA felhasználásának előnye elsősorban a feldolgozás sebességének növekedésében nyilvánul meg. Fontos továbbá, hogy – amennyiben a logikai céláramkört egy szokásos mikroprocesszor (vagy ahogy ez a Xilinx-dokumentációiban megjelenik: Processor System – PS) „társáramköreként”, megosztottan használjuk ugyanazon komplex feladat különböző részleteinek végrehajtására – a céláramkörrel megvalósított részfeladat (ennek általános rövidítése: Intellectual Property – IP) nem igényel saját „programterületet”, amely ezáltal kisebb memóriakapacitású – következésképpen olcsóbb – mikrovezérlővel is megoldható. Ezt az előnyt elhanyagolható mértékben csökkentheti, ha – mint a MiniZed esetében is – az IP „huzalozási programját” is a szekvenciális processzor tölti be. A MiniZed-be épített PL kétféle feladatot láthat el aszerint, hogy a benne megvalósított IP honnan kapja a bemeneti információit és hova küldi a feldolgozott adatokat. Ha a be- és a kimenet egyaránt maga a PS (illetve a benne futó alkalmazás), akkor „gyorsítóként”, koprocesszorként tekinthetünk a PL-ben megvalósított feladatrészre. Ha viszont a bemenet a külső alkalmazási környezetből jön, a kimenet pedig a PS-ben futó folyamatba továbbítódik vagy fordítva, a PL-ben realizált IP a szokásos értelemben vett célperifériaként viselkedve bővíti a rendszercsipbe épített szokásos mikrovezérlő-perifériakészletet. Mindkét funkcióhoz léteznek a Xilinx által előállított, „könyvtári” IP-k, de nincs akadálya annak sem, hogy a felhasználó a saját elképzeléseit valósítsa meg. Természetesen a gyorsító és a perifériális IP-k használata nem zárja ki egymást, mint ahogy a „könyvtári” vagy egyedi IP-k alkalmazása sem, a korlátozást egyedül az FPGA logikai alapelemeinek, illetve a processzor vagy a tokozat csatlakozópontjai felé vezető csatornák véges mennyisége jelenti. Itt jegyezzük meg, hogy a Xilinx már az FPGA-k egy korábbi generációja, a Spartan-6 óta rendelkezik egy olyan IP-vel, amely egy teljes processzormagot realizál a PL-térben, és ez a MiniZed-be épített rendszercsipbe épített Artix-7 FPGA-rendszerben is elérhető. Ez az ún. MicroBlaze „szoftprocesszor” IP, amely a felhasználó által konfigurálható, feladathoz optimalizálható és egyszerre akár több példányban is futhat a PL-ben. A teljesítőképessége nem lebecsülendő: 32 bites processzormagja az alkalmas környezettel együtt akár egy 200 MHz-es órajelű, 1,1 DMIPS/MHz számítási teljesítményű mikrovezérlőt, egy 160 MHz/1,3 DMIPS/MHz-es valós idejű processzort vagy 120 MHz/1,4 DMIPS/MHz teljesítményű alkalmazásprocesszort is megvalósíthat, integrált analóg perifériákkal, biztonsági funkciókkal (adattitkosítással, „babrálás” elleni védelemmel stb.), DDR-memória és Ethernet-csatlakozással stb. Csak hogy ennek a jelentőségét érzékeltessük, ezzel egy Raspberry Pi méretű és annál alig drágább kártyán akár egy többprocesszoros párhuzamos adatfeldolgozás is megvalósítható a SIMO (Single Instruction Multiple Data) vagy MIMO (Multiple Instruction Multiple Data) modell szerint (képfeldolgozás, mesterséges intelligencia, mintafelismerés, tanuló algoritmusok stb.), de akár egy, a csipre integrált processzorhálózat csomópontjaiként is működtethetők, esetleg pl. három processzormagon azonos programot, azonos adatokon futtatva, a kimeneteket összehasonlítva és az esetleges eltérések esetén közülük „többségi szavazással” választva lehet fokozni a programfutás biztonságát. Emellett arról sem feledkezzünk meg, hogy számos hardver-továbbfejlesztési projektet azért kell elindítani, mert kevés a végtermék előző verziójába eredetileg beépített adatfeldolgozási kapacitás. Az FPGA-alkalmazások lehetőségeit kihasználó hardver viszont – az FPGA kihasználásának növelésével – több termékgenerációnyi továbbfejlesztési igényt kiszolgálhat a hardver tényleges újratervezése nélkül.
A szoftverfejlesztés munkafolyamata
Ezúttal nem foglalkozunk azzal a „fapados” lehetőséggel, hogy a MiniZed-ben hogyan lehet olyan alkalmazásokat fejleszteni, amely nem használja ki a PL adta lehetőségeket. Eszerint már a munkafolyamat elején foglalkoznunk kell a hardver definiálásának problémájával. Erre az ingyenesen elérhető Vivado fejlesztőkörnyezet jelenti a megoldást, amelynek segítségével előállítható
- a hardverleíró fájl XML-formátumban,
- az FPGA felprogramozásához szükséges bitszekvencia, valamint
- az a memóriatérkép, amely a PL-szekcióban telepített memóriát osztja fel és rendeli hozzá a PL-ben futó IP-khez,
beleértve a PS-konfigurációt, a PS perifériacsatlakozási térképét és a PL működését és be/kimeneti csatlakozásait leíró adatfájlokat. Sok fejlesztőt az tart vissza az FPGA használatától, hogy nem szívesen lép ki a jól ismert, „otthonos”, hagyományos szoftverfejlesztési „komfortzónából”, ahol C/C++ nyelvi környezetben, bőséges könyvtári támogatással tud problémákat megoldani, és tart a „huzalozott logika” fejlesztésével járó többletfeladatok bonyolultságának és mennyiségének megnövekedésétől (például a VHDL, Verilog stb. hardverleíró nyelvek megismerésétől). A Vivado-környezet oly módon veszi fel a harcot az előbbi előítéletekkel, hogy ezekre a létező, jól ismert módszerekre építve kínál megoldást egy „vezetett” munkafolyamat keretében. Ebben a feladat megfogalmazása, modulokra bontása, particionálása tehát a szokásos C/C++ nyelvi környezetben történik. Akik hagyományos mikroprocesszoros szoftverfejlesztési technikák keretében próbálkoztak a feladat optimalizálásával az adatfeldolgozás sebessége szempontjából, gyakran használnak olyan programelemző eszközöket, amelyek statisztikát tudnak készíteni arról, a futásidő hány százalékát tölti a program a különböző modulok végrehajtásával. Mindezt annak érdekében, hogy kideríthessék, melyek a program leginkább időkritikus részletei, melyeket érdemes elsősorban optimalizálni ahhoz, hogy az egész program hatékonysága növekedjék. A különböző modulokban töltött futásidők közt néha meglepően nagyok az eltérések, nem ritkán egy (vagy néhány) modul „falja fel” a futásidő túlnyomó részét. A hagyományos szoftverfejlesztési munkában ekkor kezdődik az ilyen időkritikus modul(ok) újraírása assembly nyelven, és a rendkívül munkaigényes kézi optimalizálás, a „harc a gépi ciklusokért”, aminek gyakori eredménye egy „karbantarthatatlan”, és továbbfejlesztésre sem alkalmas tárgykódú modul, és az ilyen erőfeszítéssel „csodát tenni” amúgy is ritkán lehet. A Vivado segítségével a Zynq környezetben (az olvasó most figyeljen: a cikk talán legfontosabb mondata következik!) ez rendkívül egyszerűvé válik: a programozó a futásidő legnagyobb részét felemésztő programmodult „drag&drop” módszerrel egyszerűen „áthúzza” a PL-területre, és a szoftver elvégzi a programkód automatikus IP-vé fordítását és feltöltését a rendszercsip flashmemóriájába. A PS-ben futó alkalmazás tárgykódjából tehát eltűnik a hardveres gyorsítófunkcióvá változtatott programkód, és egyben megjelenik abban a hardverleíró XML-kódban, amely egyebek közt az FPGA-ba betöltendő IP-ket definiáló szekvenciát meghatározza. Megismételjük: ez utóbbi nem „programkód” a szó szoros értelmében, ugyanis egyetlenegyszer, az FPGA-konfiguráló fájl betöltésekor „fut le”, az időkritikus programrész feladatát a nála – minden bizonnyal – sokszorta gyorsabb IP, mint „célhardver” (koprocesszor) foglalja el, amellyel az alkalmazásprocesszor csak az IP bemeneti adatainak előállítását és a kimeneti adatok átvételét szolgáló kommunikáció formájában foglalkozik.
2. ábra Mesterséges intelligenciával vezérelt, autonóm repülésre alkalmas drón vezérlésének vázlata
A processzormag szoftvertámogatása
Egy pillanatra tekintsünk el a MiniZed rendszercsipjének FPGA-lehetőségétől, és vizsgáljuk meg, milyen szoftverháttérrel használható maga az ARM Cortex-A9 processzormag. A MiniZed – a cikk első részében leírt – „gyári” kivitelének firmware-je a Xilinx saját Linux-disztribúcióját, a PetaLinux-ot tartalmazza. Ez is egy gesztus azoknak a fejlesztőknek, akik ebben a méret- és árkategóriában elvárnak valamilyen közismert, elfogadott operációs rendszertámogatást (ez a Raspberry Pi megjelenése óta „alapértelmezett” követelménynek számít). Ezenkívül számos más szoftverplatformra is létezik támogatás: a MiniZed processzormagjára – a teljesség igénye nélkül – létezik háromféle Linux disztribúció, továbbá a FreeRTOS, LynxOS és QNX valós idejű operációs rendszerek, az Android, a Windows Embedded, a Mentor Graphics Nucleus. (Itt jegyezzük meg, hogy a PetaLinux, a FreeRTOS és a Nucleus a MicroBlaze szoftprocesszoron is futtatható.) És végül, de nem utolsósorban az „erősen beágyazott”, felügyelet nélküli termékek fejlesztői a „csupasz vason”, operációsrendszer-támogatás nélkül is futtathatnak kódméretre és futásidőre optimalizált egyedi alkalmazásokat (a MicroBlaze szoftprocesszoron éppúgy, mint a Cortex A9-en). A Linux-támogatás igénybevételéhez a MiniZed panelen található „boot mode” kapcsolót kell a Linux betöltéséhez szükséges kombinációba állítani – ez esetben a QSPI és eMMC memóriákból a szokásos módon betöltődik a Linux firmware, és az alkalmazásnak kell gondoskodnia arról, hogy a Vivado segítségével kifejlesztett PL-konfiguráló adatok betöltődjenek, és az FPGA-ban létrehozzák a feladat megoldásában részt vevő célhardvert. Mindehhez a MiniZed kártyán kívül egy MicroUSB-kábellel csatlakoztatott PC-re (és az azon futó soros terminál emulációra), WiFi-csatlakozásra és egy USB pendrive-ra van szükség. Az alapkísérletekhez szükséges image-fájlok a dobozból kicsomagolt kártyán eleve rendelkezésre állnak, de ha a fejlesztő úgy véli, hogy korlátozza a kísérletezésben a gyári konfiguráció, nyugodtan szabadjára engedheti a fantáziáját, és megváltoztathatja, mivel a gyári image a webről letölthető és helyreállítható.
Könnyű migráció az egyszerűbb platformokról
Nem először emlegetjük a cikk során a MiniZed és a Raspberry Pi közötti hasonlóságokat és különbségeket. Könnyen elképzelhető ugyanis egy olyan szituáció a fejlesztés folyamatában, hogy a tervező kicsi, olcsó és „konyhakész” terméket keres valamilyen beágyazott vezérlési feladat megoldására. A Raspberry Pi – közismertsége révén, a beépített Linux operációs rendszerével, flash-háttértárával, grafikus és kommunikációs képességeivel – szinte „adja magát”, hogy vele végezze el a fejlesztő az első kísérleteit. Aztán a szoftveralkalmazás elkészül, meglehet, „funkcionálisan” rendben is lenne, de a teljesítményadatai elégtelenek, vagy az igények növekedtével a feladat „kinövi” a kereteket. A MiniZed választásával és a feladat teljesítménykritikus részleteinek IP-vé alakításával – és ezáltal hardveres gyorsításával – nagyságrendileg hasonló árfekvésű, méretű és teljesítményigényű hardverrel is megmaradhatunk abban a méret-, energiafogyasztás- és ártartományban, amit a Raspberry Pi-ben szeretünk, miközben a teljesítmény megsokszorozódik, a végtermék pedig „jövőbiztosabbá” – a hardver újratervezése nélkül is – továbbfejleszthetővé válik. Mindezt anélkül, hogy a fejlesztőnek túlságosan messze kellene távolodnia a számára megszokott, kényelmes szoftveres alkalmazásfejlesztési módszerektől. A leírt példa nem kitalált „tanmese”, ugyanis – mint azt az EBV (az Avnet Engineering Services egyik magyarországi képviselete) támogatómérnökétől tudom – magyarországi példa is van arra, hogy a Raspberry Pi-alapon indított projekt az Avnet MiniZed termékére való – sem bonyolultnak, sem időigényesnek, sem költségesnek nem nevezhető – migrációs folyamattal került közelebb a megvalósíthatósághoz.
3. ábra A Xilinx FPGA termékein alapuló termékcsalád (az árarányok a legolcsóbbak többszöröseként vannak feltüntetve)
Mire elég az FPGA-többlet?
A cikken végigvonuló „Raspberry Pi párhuzamot” folytatva azzal kezdem: az FPGA-funkció nélkül nincs lényeges különbség a két kártyaszámítógép között. Ha azonban kihasználjuk a PL-ben rejlő lehetőségeket, akkor a gyorsítófunkciókkal – feladattól és a tervező által „jó érzékkel” elvégzett feladatmegosztástól, particionálástól függően, a teljes megoldásra vonatkoztatva – sokszoros a számításiteljesítmény-növekedés, a PL-ben definiált szoftperifériák alkalmazásával pedig a flexibilitás jelentős növekedése érhető el. Ezek a különbségek nem csak bizonyos feladatok hatékonyabb megoldását, hanem a kereskedelmi forgalomból ismert kártyaszámítógépekkel megoldhatatlan problémák tartományába való belépést is jelenthetik. Néhány ízelítő a Xilinx Zynq rendszercsipekkel reálisan kezelhető problématípusokból:
- valós idejű jelfeldolgozás,
- alakfelismerés,
- komplex mechatronikai vezérlés,
- gépi tanulás,
- „nyílt forráskódú” full HD videokamera, (1. ábra)
- mesterséges intelligenciával irányított, autonóm drón. (2. ábra)