FőoldalKonstruktőrValósidejű alkalmazásokat Linuxszal, valaki…?
2020. február 17., hétfő ::

Valósidejű alkalmazásokat Linuxszal, valaki…?

A nagyon hangzatos cím a valós tartalom tekintetében alighanem magyarázatra szorul. A valósidejű rendszerekre a megfelelő definíció legegyszerűbb formája, hogy periodikus alapon determinisztikus végrehajtást valósítanak meg. A valósidejűség legalapvetőbb alapkövetelménye a determinisztikusság, hiszen ezek a rendszerek javarészt gépeket vezérelnek, és ugyan ki akarna olyan numerikus vezérlésű fúrógépet a műhelyébe, amelyik ugyanazon az útvonalon A pontból B pontba keddenként 10 ms, szerdánként pedig 20 ms idő alatt jut el? Egy pilóta is azt várja el a repülésirányító rendszertől, hogy minden körülmények között, minden alkalommal ugyanazon az úton vezesse végig

Az 1. ábra egy determinisztikus rendszert ábrázol. A rendszerben periodikus megszakítások keletkeznek, amelyek megszakítási szolgáltatási rutinokat futtatnak időzítéskritikus programkódokkal. Az időzítéskritikus kód végrehajtási idejének determinisztikusnak kell lennie, máskülönben olyan rendszert kapunk, mint a 2. ábrán látható, nem egyenlő végrehajtási időket biztosító változat.

1. ábra. Példa a determinisztikus végrehajtásra

2. ábra. Példa az indeterminisztikus, változó végrehajtási időket szolgáltató végrehajtásra

A determinisztikusság mellett szükség van a Linux gazdagságára és az összes kapcsolódó middleware-hardver vezérlésre is. A Linuxnál szükség van egy memóriamenedzsment-egységre (MMU – Memory Management Unit), amely az alkalmazásfejlesztő számára a fizikai memóriát virtualizálja. Az MMU-t tartalmazó processzorok minden esetben legalább L1-szintű gyorsítótárat tartalmaznak, de manapság legtöbb esetben az L2 második szintű is a fedélzeten van. A gyorsítótár és a determinisztikusság a 3. ábra tanúsága szerint egymásra ortogonális. Az ábrán látható, hogy az L1vagy L2-szintű tévesztések (hiányok) zavart visznek be a végrehajtási láncba. Minél nagyobb a gyorsítótár mérete, annál kisebb a tévesztés/hiány gyakorisága, azonban ennek esélye értelemszerűen tökéletesen nullára így sem csökkenthető.

3. ábra. Az L1- és L2-szintű gyorsítótár-tévesztések hatása a determinisztikusságra

A Linux futtatására alkalmas processzoroknál a végrehajtási zavar egy másik lehetséges forrása az elágazásprediktor. A processzormagok tartalmaznak elágazásprediktort, amely javítja az alkalmazásszintű teljesítményt. Implementációtól függetlenül az elágazásokat a processzor előre jelzi, ami természetesen néha téves eredményt ad. Tévesztés esetén a pipeline kiürítésre kerül, a tévesztés tehát indeterminisztikus végrehajtási viselkedést eredményez. Megszakítási szolgáltatási rutin (ISR – Interrupt Service Routine) közben a prediktorban lévő elágazás előzményi táblázata a fő alkalmazási kódra nézve tartalmaz előzményeket, nem pedig maga az ISR végrehajtási előzményeire. Ez az ISR-en belül pipeline-ürítéseket eredményez, amely ISR-ről ISR-re változó végrehajtási időket jelent. Ha olyan processzorunk van, amelyik lehetővé teszi az elágazásprediktor letiltását a felhasználó számára, akkor az alkalmazásfejlesztő meghatározhatja, hogy a rendszeren belül hol és hogyan legyen determinisztikus a viselkedés. Az alkalmazásszintű determinisztikusság érdekében az elágazásprediktorok akár teljes egészében is letilthatók bizonyos processzoroknál. (Nem szabad elfelejteni, hogy az elágazásprediktorok alapvető célja a teljesítmény javítása, így letiltásuk esetén kisebb feldolgozási teljesítménnyel kell beérnünk.)

Bemutatkozik a RISC-V PolarFire SoC FPGA-architektúra

Léteznek olyan processzorok, amelyek Linux futtatására alkalmasak, determinisztikus kódvégrehajtásra azonban nem, és vice versa olyan processzorok is vannak, amelyek tudják a determinisztikus kódvégrehajtást, de nem Linux-kompatibilisek. Nem lenne jó vajon egy olyan beágyazott architektúra, amely mindkettőt támogatja? A Microchip szerint igen, éppen ezért nemrég jelentette be a cég a RISC-V-alapú SoC FPGA-architektúráját a PolarFire rendszerchipcsalád számára, amely éppen ezt hivatott teljesíteni.

4. ábra. A PolarFire SoC-architektúra

A 4. ábrán látható rendszerben 4 db 64 bites, RISC-V-alapú, Linux futtatására alkalmas RV6GC processzormag található, míg a szimpla RV64IMAC processzormag Linux futtatására nem alkalmas. Más szavakkal: az RV64IMAC nem tartalmaz memóriamenedzsment-egységet, míg a négy RV64GC típusú mag vele ellentétben igen. Az RV64IMAC és RV64GC processzormagok utasításkészletei közötti különbség nyilvánvaló, hiszen az RV64GC tartalmaz kétszeres pontosságú lebegőpontos egységet is. Az architektúrán belüli determinisztikusság javítása érdekében a felhasználó bármely magban letilthatja az elágazásprediktort, akár a processzormag felélesztése, akár megszakítási szolgáltatási rutin futása közben. Jellemző továbbá, hogy sorrendi pipeline-nal rendelkezik mind az öt processzormag a determinisztikusság javítása, illetve a Spectre és Meltdown típusú támadások elkerülése érdekében.
A determinisztikusságról eddig csak a CPU magok vonatkozásában beszéltünk, de mivel a programkód a memóriából betöltve kerül végrehajtásra, nézzük most meg a PolarFire rendszerchipek memória-alrendszerét is! Először is, a PolarFire SoC-k teljes memóriaterülete koherens, amely koherencia ebben az esetben annyit tesz, hogy bármely memória, amely több adatmásolattal rendelkezik, a koherenciamenedzser irányítása alatt áll, és bármely memória, amely egyetleneggyel, alaptermészetéből kifolyólag koherensnek tekinthető, mivel a komplett memóriahierarchiában nem létezik további másolat. A PolarFire SoC-k három memória-alrendszerrel rendelkeznek: az első szintű L1-gyel, a második szintű L2-vel, illetve a harmadik szintű L3-mal. Az L3 memória-alrendszer egy megerősített LPDDR3/LPDDR4 és egy DDR3/DDR4 szabványú, 36 bites vezérlőt tartalmaz. A kiegészítő 4 bit az egybites hibajavítás/kétbites hibadetektálás (SECDED – Simple Error Correct Double Error Detect) kompatibilitás érdekében került be az L3 gyorsítótár számára.

Az L1 memória-alrendszer

A négy RV64GC alkalmazástechnikai processzormag egyenként rendelkezik egy 8-utas asszociatív, 32 KiB-os I$TIM-mel, illetve egy egy 8-utas asszociatív, 32 KiB-os D$TIM-mel. [Az I$ arra utal, hogy utasítások számára kijelölt gyorsítótárról van szó, a D$ adatokra vonatkozó memóriát jelent, míg a TIM szorosan összeintegrált memóriát (TIM – Tightly Integrated Memory) szimbolizál.] Az I$TIM és a D$TIM felhasználó által konfigurálható azzal a követelménnyel, hogy legalább egy útra mindig szüksége van az I$TIM-nek és egyre a D$TIM-nek. Az RV64IMAC monitormag rendelkezik egy 16 KiB-os, kétutas asszociatív I$TIM-mel és 8 KiB DTIM-mel. A DTIM egy adatok számára rendelkezésre álló, gyors munkaterület (ún. scratch-pad memória), amelyből kód végrehajtásra kerülhet. Valamennyi első szintű TIM-funkcionalitás rövid késleltetésű, determinisztikus hozzáférést biztosít, és mindannyian SECDED-kompatibilisek.

Az L2 memória-alrendszer

A SECDED-kompatibilis L2 gyorsítótár mérete 2 MiB, és háromféle különböző üzemmódba programozható: egy 16-utas asszociatív gyorsítótárba, egy lazán integrált memóriaterületre (LIM – Loosely Integrated Memory), illetve egy gyors munkaterületre (scratch-pad memóriára). A LIM egy processzorhoz köthető, és a gyorsítótárnál megszokott módon méretezhető, vagyis felépíthető 128 KiB-os darabokból (utakból), amelyekhez egy-egy processzor számára kizárólagos hozzáférés adható. A LIM-ként konfigurált L2 gyorsítótár memória-alrendszer determinisztikus hozzáférést ad a hozzárendelt processzormag számára, továbbá koherens, mivel sem az L1-, sem az L3-szintű gyorsítótárral közös másolatok nem léteznek a rendszerben. A LIM ideális választás determinisztikus kódfuttatásra a fő alkalmazásban és a megszakítási szolgáltatási rutinokban is. Az 5. ábra egy determinisztikus rendszert ábrázol LIM-ként konfigurált L2 második szintű gyorsítótár és TIM-ként konfigurált L1-szintű gyorsítótár esetén.

5. ábra. Determinisztikus végrehajtás LIM-ekkel és TIM-ekkel

Sajnálatos módon az elágazásprediktorok tévesztési lehetősége miatt a megszakítási szolgáltatási rutinok végrehajtási ideje változhat még akkor is, ha az L2 második szintű gyorsítótárat LIM-ként konfiguráljuk. A 6. ábra egy olyan alkalmazásról mutat képet, amelyben az L1 első szintű gyorsítótárat TIM-ként, míg az L2 második szintű gyorsítótárat LIM-ként konfigurálták. A vízszintes tengelyen a megszakítások vannak szerepeltetve, a függőleges tengely a megszakítási szolgáltatási rutinon belüli ciklusidőt jelöli. Ahogy látható, a megszakítási szolgáltatási rutinok végrehajtási ideje az időben nem állandó, hanem változékonyságot mutat.

6. ábra. Az elágazásprediktor hatása a determinisztikusságra

A 7. ábrán látható esetben az elágazásprediktorokat letiltottuk, és ennek megfelelően megkaptuk a determinisztikusságot.

7. ábra. A végrehajtási idő állandósága determinisztikus viselkedés mellett

A LIM-hez hasonlóan a gyors munkaterület (scratch-pad memória) is konfigurálható 128 KiB méretű darabokra (utakra), amelyek CPU magokhoz hozzárendelhetőek. A gyors munkaterület ideálisan töltheti be a megosztott memóriaterület szerepét a LIM-ből kódot futtató processzor és az L1/L2 és L3 memória-alrendszerből kódot futtató (Linuxnál tipikus eset) processzor között. Ha az RV64IMAC által futtatott alkalmazás adatot ír a gyors munkaterületre, és ennek a memóriatartalomnak egy másolata valahol máshol is létezik az L1/L2/L3 gyorsítótárakban, a koherenciamenedzser garantálja a komplett memória-alrendszer koherenciáját. Ily módon a valósidejű alkalmazások koherens módon tudnak adatot megosztani a Linux felhasználói terében futó alkalmazásokkal.
A 8. ábra a PolarFire SoC mikroprocesszoros alrendszer egy lehetséges konfigurációját ábrázolja. Ebben a konfigurációban az RV64IMAC processzormag látja el a valósidejű feladatokat, míg a négy RV64GC processzormag futtatja a Linuxot. Ha a valósidejű funkcionalitáshoz lebegőpontos számítási teljesítményre van szükség, az RV64GC processzormagokra lehet számítani, mivel az elágazásprediktorok kikapcsolhatók, és az L1 első szintű gyorsítótár TIM-ként konfigurálható.

8. ábra. Koherens üzenettovábbítás

Összefoglalás

A determinisztikusság a valósidejű rendszerek alapkövetelménye, azonban a piacon sok olyan processzor van kereskedelmi forgalomban, amelyek Linux futtatására képesek, de determinisztkus kódvégrehajtásra nem, ami fordítva is igaz: olyan példányok is vannak, amelyek ismerik a determinisztikus kódvégrehajtást, de Linux-kompatibilitást nem kínálnak. A Microchip-féle PolarFire rendszerchipek egyedi kialakítású, rugalmas memória-alrendszerű megoldások, amelyek támogatják a konkrétan valósidejű alkalmazásokat és a Linux-platformot egyidejűleg, egy flexibilis, koherens rendszerben. Kezdje meg PolarFire-alapú fejlesztését most!

A Microsemi honlapjaA Microsemi honlapja

A Microchip Technology honlapja

Tudomány / Alapkutatás

tudomany

CAD/CAM

cad

Járműelektronika

jarmuelektronika

Rendezvények / Kiállítások

Mostanában nincsenek események
Nincs megjeleníthető esemény