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

Úvod

V praxi je velké množství zadání, kdy je potřeba zpracovávat na jedné straně relativně jednoduché úlohy, které jsou časově kritické a často se opakují, na druhé straně relativně komplikované úlohy, které nejsou časově kritické a jejich četnost je relativně nízká. V těchto případech je výhodné zpracování úloh rozdělit mezi FPGA a MCU. Jelikož obvody FPGA umožňují paralelní zpracování, jsou vhodné pro časově kritické úlohy. Moderní FPGA obsahují zabudované funkční bloky jako např. dvouportové paměti RAM, paměti FIFO, bloky DSP pro digitální zpracování, řadiče sběrnic jako PCI Express, vysokorychlostní komunikační obvody apod. Je výhodné tyto bloky využívat, neboť usnadňují návrh, šetří zdroje a zvyšují rychlost zpracování. Je příjemné, že tyto zabudované bloky jsou součástí i těch obvodů FPGA, které jsou určeny do aplikací, kde je vyžadována nízká cena. 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 programovatelné čítače, sledování polohy, detektory 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 java 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 „přestrojený“ počítač třídy PC („embedded PC“) s moderním operačním systémem typu Windows, Linux apod., ale tyto OS zase nepodporují funkce 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. Submikrosekundové rychlosti však dosahuje jen programovatelná logika.

Proto jsme zkombinovali procesor s jádrem ARM9 nebo MIPS, operační systém reálného času Linux a programovatelný logický obvod FPGA Xilinx řady Spartan, 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ě „super-součástky“ zasunuta do konektoru v aplikační desce. Tato deska plošných spojů může být „výkonová“, se širokými vodivými cestami a mezerami, s málo vrstvami, a tedy poměrně levná.

Uvedené řešení bylo například použito při mapování čtyř sériových linek RS-485 do rámců ethernetu a naopak, kdy šlo o obousměrný datový tok se zprávami. Kritickým činitelem zde byla doba přenosu zprávy. Aby se minimalizovala doba tvorby rámce, přenáší se v jednom rámci pouze několik znaků ze vstupní fronty, v krajním případě pouze jeden. Přenos je značně neefektivní, ale fyzické rozhraní 100BASE-FX toto řešení umožňuje. Při přenosové rychlosti 115 200 bits/s a čtyřech sériových RS-485 linkách je rychlost přenosu rámců v přijímacím nebo vysílacím směru zhruba 46 000 rámců/s. Z těchto důvodů bylo sestavování a rozebírání rámců realizováno v FPGA. Z hlediska FPGA je toto proces relativně pomalý, postačuje taktovací signál MII rozhraní o frekvenci 25 MHz. Při vývoji byl použit druhý nejmenší člen řady SPARTAN-6 XC6SLX9 v pouzdru TQG144. Je pravděpodobné, že pro sériovou výrobu bude možno použít nejmenší člen XC6SLX4 ve stejném pouzdru. Oba obvody jsou z hlediska rozmístění pinů kompatibilní.

Celá aplikace se skládá z následujících bloků:

– Blok sériového rozhraní RS485 je v aplikaci obsažen 4×. Sestává ve vysílacím směru ze sério-paralelního převodníku (rozšířeného přijímače UART) a paměti FIFO, v přijímacím směru naopak z paměti FIFO a paralelně- sériového převodníku (vysílač UART s rozšířením). Oba směry mají společný generátor přenosové rychlosti. Volitelnými parametry jsou délka znaku 8 nebo 9 bitů, přenosová rychlost a počet znaků přenášených v rámci ethernetu.

– Blok generování rámce ethernetu sestává z paměti FIFO s šířkou brány pro zápis 16 bitů a šířkou brány pro čtení 4 bity, generátoru CRC-32 a řadiče obsluhy bloků sériového rozhraní ve vysílacím směru. Pokud je přijat zvolený počet znaků nebo je mezi znaky více než jeden stop-bit, je okamžitě generován rámec ethernetu. Data jsou zapisována do paměti FIFO, kde zároveň dochází ke konverzi z 16 bitů na 4, což je šířka dat rozhraní MII. Na výstupu rozhraní MII jsou data k dispozici již při prvním zápisu do paměti FIFO. Volitelnými parametry jsou cílová a zdrojová MAC adresa.

– Blok rozebírání rámce sestává z převodníku šířky ze 4bitového rozhraní MII na 16 bitů, generátoru CRC-32, komparátoru cílové MAC adresy a paměti FIFO. Pokud souhlasí cílová adresa s předpokládanou a rámec je označen jako datový, dochází k rozebírání rámce. Znaky jsou vyjímány a ukládány do paměti FIFO. Pokud je rámec neporušen, jsou data z paměti FIFO přenesena do paměti příslušného bloku sériového rozhraní. V opačném případě je paměť FIFO vyprázdněna, data jsou zahozena, přirozeně k žádnému kopírování dat nedochází. Volitelným parametrem je cílová MAC adresa.

– Blok rozhraní SPI sestává z S/P a P/S převodníků, generátoru adres a sady interních, výstupních a vstupních 32bitových registrů. V interních registrech jsou programem uloženy volitelné parametry výše uvedených bloků a z nich se vyčítají diagnostická data (počet porušených rámců). Přes výstupní registry jsou ovládány výstupní piny, do vstupních registrů se kopírují hodnoty na vstupních pinech.

V této aplikaci je komunikace MCU s FPGA přes rozhraní SPI. FPGA se konfiguruje z paměti flash přes jednobitové rozhraní SPI. Při konfigurační rychlosti 33 Mbits/s je obvod nakonfigurován zhruba za 0,2 sekundy. Po nahrání parametrů pro jednotlivé bloky je vše připraveno k činnosti. Tvorba i rozebírání ethernetovských rámců probíhá bez účasti MCU. Na obr. 1 je ideové blokové schéma systému.

Obr. 1 Blokové schéma

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. Nedávno v [1] vyšel článek, v němž jsou podobné zásady doporučeny a diskutovány. My jsme je ještě doplnili o sledování FPGA.

– Po zapnutí by se měl provést test celé paměti RAM a dalších hardwarových prostředků.

– Paměť ROM 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ěhemhlavní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ř. DONE).

– Při běhu aplikace by měl být kontrolován zásobník, tedy obsah stack-pointeru, a rovněž dalších ukazatelů na dynamické datové struktury a jejich vrchol. Č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 případných podřízených procesorů, 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 „utility“ procesorem. Obsluha „hlazení“ watch-doga musí být prováděna hlavní smyčkou programu, tou, co má nejnižší prioritu. Pokud se hlavní program z jakékoli příčiny „zasekne“, přestane „hladit“ psa, ten se probudí a systém resetuje. 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í v síti 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, 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 resety, výpadky napájení, chyby komunikace, navázání a ukončení spojení, zavírání souborů a jiné singulární situace.

Závěr

Jsme přesvědčeni vlastní zkušeností, že 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.

Odkaz:

[1] Beningo, J.: 7 Tips for creating a reliable embedded system. www.EDN.com, Feb. 24, 2015.