MCU a FPGA ve vestavném počítači

Úvod

Ve vestavném počítači je často potřeba současně provádět jednoduché, ale časově kritické a často se opakující úlohy a k tomu relativně komplikované úlohy, které nejsou časově kritické a/ nebo jejich četnost je relativně nízká. Je to například obsluha častých událostí na I/O portech a práce se soubory nebo komunikačními relacemi (protokoly). V těchto případech je výhodné paralelní zpracování úloh rozdělit mezi procesor (MCU) a programovatelný logický obvod (CPLD nebo FPGA). Moderní FPGA obsahují zabudované funkční bloky, jako jsou např. dvouportové paměti RAM, FIFO, různé mega-bloky, ale hlavně jsou programovatelné, takže je možné je „nabootovat“ aktuální aplikací. MCU pak může řešit časově ne příliš kritické, ale velmi složité úlohy realizované programem.

V našich aplikacích se často setkáváme s požadavky na souběžné úlohy, od rychlých funkcí na úrovni kombinační logiky přes složité sekvenční obvody, jako jsou obousměrné či programovatelné čítače pro sledování polohy, detektory úrovní a změn, komunikační řadiče atd. až po systémové funkce na nejvyšší úrovni, na něž už jsme zvyklí při práci na PC připojeném k internetu, jako správu souborů na disku, připojení k internetu se vzdálenými aplikacemi jako php, sql a běh celého operačního systému se správou paměti a dalších prostředků vestavného počítače.

Tyto systémové funkce je schopen provádět jen počítač třídy PC („embedded PC“) s moderním operačním systémem typu Windows, ale tyto OS zase ne zcela dobře fungují na nízké úrovni, zejména nespolupracují s průmyslovými vstupy a výstupy a nezaručují odezvu na vnější události v řádu mikrosekund. Pro rychlé aplikace je nutno použít jednočipové řadiče, ale ty zase zpravidla nemají souborové a internetové funkce. Perspektivní jsou operační systémy reálného času běžící na platformách ARM, MIPS a dalších, kdy se aplikace píše v jazyce C, nezávisle na typu procesoru. Sub-mikrosekundové rychlosti však dosahuje jen programovatelná logika.

Proto jsme zkombinovali procesor s jádrem ARM9, operační systém reálného času Linux a programovatelný logický obvod FPGA Xilinx řady Spartan3, který jsme připojili na rychlou 32bitovou datovou sběrnici procesoru. Obvod FPGA je založen na technologii RAM, programuje se po zapnutí, takže se „bootuje“ ze souboru stejně jako programové vybavení procesoru. Výsledná sada čipů je buď integrována do desky plošného spoje, anebo je ve formě „supersoučástky“ nasunuta do konektoru v aplikační desce. Ta může být navržena „výkonově“, se širokými vodivými cestami a mezerami, s málo vrstvami, a tedy být poměrně levná.

Uvedené řešení bylo například použito při řízení manipulátoru s několika osami a s pohonem nebo pro paralelní zpracování vícenásobných telemetrických spojení mapovaných protokolem V.110 z jednotlivých dohledů drážních vozidel přes GSM-R síť do portu E1. Komunikační řadiče V.110 nejsou na trhu a jediná možnost byla napsat jejich protokol v jazyce VHDL do logického pole. Při vývoji byl použit člen řady SPARTAN- 6 XC3SLX400 v pouzdru TQ144 s rezervou výkonu. Pro výrobu bude možno použít nejmenšího členu XC6SLX4 ve stejném pouzdru, protože oba obvody jsou z hlediska rozmístění pinů kompatibilní.

Blok rozhraní E1 je v aplikaci obsažen dvakrát pro obsluhu každého směru. Sestává z 30 instancí v každém kanálovém intervalu (time-slotu) pro příjem a vysílání multirámců, které pro danou přenosovou rychlost odpovídají sériové lince V.24 . Jedná se tedy jak ve vysílacím, tak přijímacím směru o sério-paralelní převodník (rozšířený UART) a paměť FIFO. Oba směry mají společný generátor přenosové rychlosti. Kromě toho řadič zajišťuje synchronizaci a signalizaci na E1 podle euroISDN (SS7).

Sestavené rámce V.110 jsou ve formě datových rámců předávány do/z procesoru přes systém „mailboxů“ řízených ukazateli v rozhraní FPGA na sběrnici procesoru. MCU tedy „vidí“ FPGA a jeho datové struktury v okně svého paměťového prostoru. Kromě toho vede do FPGA ještě jeden kanál SPI.

Z datových rámců z/do mailboxů jsou v CPU skládány zprávy na úrovni databázových záznamů, které jsou komunikovány se síťovým úložištěm na lokální ethernetové síti. Celá jednotka a jednotky na sousedních portech tedy fungují jako redundantní systém s dynamickým přepínáním úloh.

Vzhledem k charakteru zakázky jako „europrojektu“ byl od začátku kladen důraz na dodržení norem ETSI/ITU-T a dalších sjednocených požadavků, aby byl možný pohyb např. lokomotiv s dohledem z EU po naší síti a naopak.

Při „bootování“ systému ve FPGA se využívá sériové komunikace z MCU po programovacím rozhraní. (FPGA se však umí konfigurovat několika dalšími způsoby: z paměti flash přes SPI a paralelně.) Po inicializaci (po správném počtu přenesených bitů odpoví signál DONE) a nahrání parametrů pro jednotlivé bloky je vše připraveno k činnosti. Tvorba i rozebírání rámců E1 probíhá bez účasti MCU. Na obr. 1 je ideové blokové schéma systému MCU-FPGA.

Chybové situace a stabilita systému

Jelikož činnost FPGA probíhá relativně nezávisle na procesoru, vzniká otázka, jestli za všech myslitelných situací celý systém dokáže „ustát“ případné chybové události a jejich kombinace. Zde je několik opatření, která jsme provedli pro zajištění stability celého systému, včetně jeho připojení k internetu pro diagnostiku. V článku [1] jsou podobné zásady doporučeny a diskutovány. My jsme je ještě doplnili o sledování FPGA a dálkovou aktualizaci softwaru.

• Po zapnutí (studeném startu) by se měl provést test celé paměti RAM a dalších hardwarových prostředků. (Při teplém startu je naopak požadováno zjistit příčinu resetu a co nejrychlejší uvedení systému do provozu.) Zjištěné chyby se poznamenají do příznaků nebo logu.
• Paměť ROM (NAND Flash) by měla mít známý obsah (včetně nepoužité části) a měla by být chráněna kontrolním součtem. Během hlavního programu by se tato kontrola měla periodicky opakovat.
• Samotná aplikace po nabootování z ROM / flash disku by se měla sama zkontrolovat a validovat. V aplikaci by neměly být nadbytečné kusy kódu, které se nepoužívají, ale jsou potenciálně nebezpečné.
• Programování FPGA by mělo kontrolovat programovací data (kontrolní součet) a jejich počet vůči stavovým signálům programovacího rozhraní (např. signál DONE).
• Při běhu aplikace by měl být kontrolován zásobník proti přetečení, tedy obsah stack-pointeru, a rovněž dalších ukazatelů na limity dynamických datových struktur v paměti. Článek [1] radí vůbec nepoužívat dynamické datové struktury, ale podle našich zkušeností u internetových aplikací to prostě nejde splnit.
• Stejně tak by měl být monitorován stav FPGA a dalších podřízených řadičů, například jestli nedochází k nebezpečnému přiblížení ke konci časového „okna“ přiděleného běhu periodicky spouštěné úlohy. Doporučuje se periodicky sbírat a zaznamenávat diagnostická data, například o relativní chybovosti.
• Činnost hlavního procesoru by měla být monitorována obvodem watch- -dog nebo dohledovým procesorem. Obsluha dohledu či „hlazení“ watch doga musí být prováděny hlavní smyčkou programu, která má nejnižší prioritu. Pokud se hlavní program z jakékoli příčiny „zasekne“, přestane „hladit“ psa, ten se probudí a systém zakousne (resetuje do teplého startu). Obvod dohledu musí být robustní, necitlivý na stejné vlivy jako hlavní procesor.
• Všechny vstupy musejí být ošetřeny. Nepoužívané signálové či přerušovací vstupy musejí být spolehlivě přitaženy do neaktivní úrovně. Vlna přepětí nebo atmosférický výboj může jinak spustit nečekanou reakci. Imunitu proti těmto rušením je třeba ověřit.
• Jednou z příčin chyb je i výpadek napájení, který nastane nečekaně. U nezálohovaných systémů je třeba mít časný detektor výpadku napájení, který umožní pod nemaskovatelným přerušením „uklidit“ všechny důležité informace (na disk/flash), zavřít soubory a zastavit systém v očekávání resetu od výpadku napájení anebo od watch doga.
• Doporučuje se zálohovat připojení k internetu ještě lokální pamětí nezávislou na napájení, například flash diskem, a do této paměti zapisovat stavové informace při významných událostech v životě systému, například poslední resety, zjištěné diagnostické výsledky, výpadky napájení, chyby komunikace, navázání a ukončení spojení, zavírání souborů a jiné singulární situace.
• Je dobré mít nějakou možnost aktualizace programového vybavení „v poli“, nejlépe po internetovém připojení. Pak je ale nutno mít nějaké zabezpečení, že přenesená data jsou opravdu správná.
• Pro hodnocení výkonnosti systému po aktualizaci softwaru je dobré stanovit si nějaký „benchmark“, srovnávací test, vyčíslitelný nebo jinak hodnotitelný.

Závěr

Aplikace těchto pravidel dá programátorům mnohem víc práce, než se na počátku vývoje zdá, ale tato práce se rozhodně vyplatí. Co se může pokazit, to se určitě pokazí a dvojnásob to platí u internetových aplikací. Poslední pravidlo zní KISS: Keep it simple and stupid.