Analyzátor sbě rnice CAN

Č ESKÉ VYSOKÉ UČ ENÍ TECHNICKÉ Fakulta elektrotechnická Analyzátor sbě rnice CAN diplomová práce Roman Knížek PRAHA 2002

Souhlasím s využitím výsledků Diplomové práce Fakultou elektrotechnickou ČVUT a zároveň prohlašuji, že jsem předloženou Diplomovou práci včetně příloh vypracoval samostatně a uvedl v ní veškerou použitou literaturu. V Praze, dne 25. 1. 2002 Roman Knížek

Děkuji Ing. Jiřímu Novákovi, PhD. za pomoc a čas věnovaný vedení mé diplomové práce a své rodině za podporu při studiu.

Controler Area Network (CAN) is serial communacation protocol, which was originally developed by the company BOSH for automobil industry. It is projected to enable to provide distributed control of systems in the real time at the speed of 1 Mbit/s with high security from error transmisson. This thesis deals with an analyzer project for the monitoring of the proces on the bus CAN at level of the link protocol according to CAN specification 2.0B. The analyzer is based on hardware support of Programmable Logic Device (PLD) and communication with controlling computer (PC) by means of perspective interface Universal Serial Bus (USB).

Controller Area Network (CAN) je sériový komunikační protokol, který byl původně vyvinut firmou BOSCH pro nasazení v automobilovém průmyslu. Je navržen tak, aby umožnil provádět distribuované řízení systémů v reálném čase s přenosovou rychlostí do 1 Mbit/s, s vysokým zabezpečením přenosu proti chybám. Tato Diplomová práce se zabývá návrhem analyzátoru pro monitorování dějů na sběrnici CAN na úrovni linkového protokolu podle CAN specifikace 2.0B. Analyzátor je založen na hardwarové podpoře hradlovým polem a komunikaci s řídícím počítačem (PC) pomocí perspektivního rozhraní Universal Serial Bus (USB).

OBSAH 1. Úvod 1 1.1 Motivace 2 1.2 Očekávané vlastnosti analyzátoru 2 1.3 Uspořádání kapitol 3 1.4 Konvence 3 2. Sběrnice CAN a další 5 2.1 Controller Area Network (CAN) 6 2.1.1 Základní vlastnosti 6 2.1.2 Fyzická vrstva 6 2.1.3 Linková vrstva 7 2.1.4 Způsoby zabezpečení a detekce chyb 7 2.1.5 Signalizace chyb 8 2.1.6 Zprávy linkového protokolu 8 2.2 Hradlová pole 11 2.2.1 Základní časové parametry 11 2.2.2 Architektura hradlového pole ACEX 1K 12 2.3 Integrované návrhové prostředí EMAX+plus II a jazyk AHDL 13 2.4 Rozhraní Universal Serial Bus (USB) 15 2.4.1 Topologie USB 15 2.4.2 Přenos dat 16 2.4.3 Napájení funkčních jednotek 17 2.4.4 Přenosová rychlost USB 17 2.4.5 Připojení funkční jednotky ke sběrnici. 17 3. Design analyzátoru v hradlovém poli 18 3.1 Blokové schéma 19 3.1.1 Výhody hierarchického přístupu 19 3.1.2 Dekompozice CAN analyzátoru 20 3.2 Funkce obvodů CAN analyzátoru 20 3.2.1 Obvod Bit Destuffing (BDE) 20 3.2.2 Obvod Cyclic Redundancy Check (CRC) 23 3.2.3 Obvod Main Timer (MTR) 25 3.2.4 Obvod Real Time Counter (RTC) 28 3.2.5 Obvod Bit Counter (BIC) 29 3.2.6 Obvod Bus Idle (BID) 30 3.2.7 Obvod Data Read Unit (DRU) 32 3.2.8 Obvod CAN Main Loop (CML) 35 3.2.9 Obvod CAN End Loop (CEL) 40 3.2.10 Obvod CAN Err Loop (CRL) 42 3.2.11 Obvod Main Counter (MCT) 45 3.2.12 Obvod Main Start Unit (MSU) 51 3.2.13 Obvod SYNC 57 3.2.14 Obvod Input Trigger (INT) 57 3.2.15 Obvod Startup Unit (SUU) 59

OBSAH 3.2.16 Obvod Output Trigger (OUT) 62 3.2.17 Obvod Write To FIFO (WTF) 63 3.3 CAN analyzátor jako virtuální součástka 68 3.3.1 Schéma zapojení CAN analyzátoru 68 3.3.2 Realizace drátového součtu hradlovým polem 70 3.3.3 Popis signálů CAN analyzátoru 70 3.3.4 Pracovní model CAN analyzátoru 71 3.4 Periferie CAN analyzátoru 72 3.4.1 Obvod pro řízení paměti DRAM driver (DRD) 73 3.4.2 Obvod Intercom (ITC) 80 3.5 Závěrečná podoba návrhu v hradlovém poli 82 4. Hardwarový návrh analyzátoru 83 4.1 Implementace v hradlovém poli 84 4.1.1 Rámcový výběr obvodu 84 4.1.2 Zlepšování časových parametrů návrhu 84 4.1.3 Návrh analyzátoru 85 4.1.4 Programovatelné pole ACEX EP1K50-208-1 85 4.1.5 Programování obvodu ACEX 1K 85 4.2 Obvody pro řízení a komunikaci 86 4.2.1 Jednočipový mikropočítač SCENIX SX52BD 86 4.2.2 Jednočipový mikropočítač AT89C52 87 4.2.3 PDIUSBD12 zařízení rozhraní USB 88 4.3 Blokové uspořádání hardware analyzátoru 88 4.3.1 Blok zdrojů 89 4.3.2 Konfigurační přepínače 90 4.3.3 Budič sběrnice CAN 90 4.3.4 Blok vstupního a výstupního triggeru 90 4.3.5 Blok signalizace 90 4.3.6 SX52BD 91 4.3.7 AT89C52 91 4.3.8 Konfigurační svorkovnice 91 4.3.9 Blok programování obvodu ACEX 92 4.3.10 Blok rozhraní USB 92 4.3.11 Zdroje hodinového kmitočtu 92 4.4 Deska plošných spojů 92 5. Software 93 5.1 Ovladač zařízení USB s obvodem PDIUSBD12 94 5.2 Firmware procesoru AT89C52 94 5.3 Firmware procesoru SX52BD 96 6. Datové toky v CAN analyzátoru 97 6.1 Datový tok naměřených dat 98 6.2 Zápis do vnitřní vyrovnávací paměti CAN analyzátoru 99

OBSAH 6.3 Zápis do paměti DRAM 99 6.4 Přenos dat z paměti DRAM do PC 100 7. Závěr 101 8. Literatura 103 Příloha A 105 Příloha B Příloha C Příloha D Příloha E II II II II

ANALYZÁTOR SBĚ RNICE CAN Kapitola 1 Úvod Kapitola 1 předkládá základní přehled o předmětu diplomové práce, důvody které vedly k jejímu zadání a některé souvislosti, které jejímu zadání předcházely. Jsou zde nastíněny vlastnosti, které bychom od analyzátoru sběrnice očekávali. V závěru je uvedeno rozvržení kapitol a konvence. 1. Úvod

ÚVOD 1.1 Motivace Myšlenka na konstrukci analyzátoru sběrnice CAN vznikla na Katedře měření před téměř dvěma roky. Hlavním důvodem je, že průmyslově vyráběné řadiče sběrnice CAN jsou konstruovány jako inteligentní a umožňují pouze omezenou signalizaci chybových stavů, a tedy i omezené sledování sběrnice na úrovni linkového protokolu. Přibližně ve stejné době začíná tehdejší firma Scenix Semiconductors, Inc. (dnešní Ubicom, Inc.) nabízet nový levný jednočipový mikropočítač SCENIX s architekturou s redukovanou instrukční sadou (RISC) a výkonem až 50 MIPS (miliónů instrukcí za sekundu). Byl zadán semestrální projekt, jehož cílem byla realizace analyzátoru ve formě zásuvné ISA karty pro PC, pouze na bázi výše zmíněného procesoru. Výsledkem projektu byl funkční analyzátor, který umožňoval stavovou analýzu sběrnice CAN na úrovni linkového protokolu až do přenosové rychlosti 250 kbit/s. Měření reálného času, přidělování časových značek událostem, resynchronizace a možnost sledovat bitové rychlosti nad 250 kbit/s již překračovaly možnosti použitého procesoru. Závěrem tedy bylo, že realizace analyzátoru v souladu se specifikací CAN 2.0B čistě softwarovou cestou není s použitým procesorem možná a bude nutné využít hardwarové podpory. Na základě výše uvedených poznatků bylo formulováno zadání této Diplomové práce. 1.2 Očekávané vlastnosti analyzátoru Základní filozofie analyzátoru je velmi jednoduchá a je patrná z obrázku Obr. 1. Jedná se o zařízení, které se v libovolném místě a v libovolném okamžiku (tzn. nejsou kladeny žádné požadavky na stav sběrnice před připojením analyzátoru) připojí na sběrnici CAN, monitoruje veškeré děje a předává výsledky ke zpracování do počítače typu PC. Formát předávaných dat je takový, aby bylo možno zrekonstruovat provoz na sběrnici včetně časových souvislostí. Jako komunikační kanál mezi analyzátorem a PC bylo vybráno perspektivní rozhraní Universal Serial Bus (USB), které je kompromisem mezi mobilitou celého zařízení a požadavky na přenosovou rychlost. Požadavky na vlastnosti analyzátoru lze shrnout do následujících bodů: Schopnost připojení na sběrnici za plného provozu Úplná implementace linkového protokolu podle CAN specifikace 2.0B [1] 2

ÚVOD Hodiny reálného času schopné generovat časové značky k událostem (chyby, triggery a další relevantní informace důležité pro analýzu) Detekce všech stavových chyb a chyb synchronizace Asynchronní vstupní trigger (vloží do naměřeného souboru dat časovou značku vnějšího trig. pulsu) Programovatelný výstupní trigger (při naprogramované události generuje na výstupu puls např. pro spuštění osciloskopu nebo log. analyzátoru) Provoz v režimu reálného času (Real-Time), kdy jsou naměřená data ihned přenášena do PC a vyhodnocována Provoz v režimu ukládání dat do vyrovnávací paměti Zařízení 1 Zařízení 2 Zařízení 3 Zařízení n Sběrnice CAN RZ RZ CAN analyzátor USB PC Obr. 1: Filozofie CAN analyzátoru 1.3 Uspořádání kapitol Nejnutnější obecné informace nutné pro praktický návrh analyzátoru jsou uvedeny v kapitole 2 (sběrnice CAN, architektura hradlových polí, vývojové prostředí a sběrnice USB). Vlastním návrhem se zabývá nejrozsáhlejší kapitola 3. V následující kapitole je pak popsán hardware analyzátoru a závěrečná kapitola se věnuje programovému vybavení. 1.4 Konvence Pokud je to možné a vhodné, názvy použitých signálů, stavů, procedur a proměnných odpovídají stejným názvům použitých ve zdrojových souborech. 3

ÚVOD Specifikace sběrnice CAN definuje dvě navzájem komplementární logické úrovně (kapitola 2.1.2), které nazývá dominant a recessive. Bez újmy na obecnosti zaveďme pro účely různé formy popisu a zobrazení úrovní signálů následující rovnosti: dominant = dominantní = log 0 = 0 = GND recessive = recesivní = log 1 = 1 = Vcc Schematické značky obvodů CAN analyzátoru v kapitole 3, mají na levé straně vždy vstupní signály a výstupní signály na straně pravé. Příklad je na obrázku Obr. 1. VSTUP 1 VSTUP 2 VÝSTUP 1 VÝSTUP 2 VSTUP 3 PRIKLAD_ OBVODU Obr. 2: Příklad umístění vstupních a výstupních signálů ve schematické značce obvodu 4

ANALYZÁTOR SBĚ RNICE CAN Kapitola 2 Sběrnice CAN a další V kapitole 2 jsou uvedeny všechny potřebné pojmy, které je nezbytné uvést dříve, než se pustíme do vlastního návrhu CAN analyzátoru. První část je věnována sběrnici CAN, zejména vlastnímu linkovému protokolu. V další části je přiblížena architektura programovatelných logických polí. Následuje představení prostředí EMAX+plus II a jazyka AHDL, použitého pro návrh. Závěr je věnován rozhraní USB. 2. Sběrnice CAN a další

SBĚ RNICE CAN A DALŠÍ 2.1 Controller Area Network (CAN) CAN je sériový komunikační protokol, který byl původně vyvinut firmou Bosch pro nasazení v automobilovém průmyslu. Vzhledem ke svým dobrým vlastnostem, mezi které patří především spolehlivost, vysoká přenosová rychlost, snadná rozšiřitelnost a nízká cena, dochází k stále častějšímu využívání tohoto protokolu i v jiných průmyslových aplikacích. Specifikace CAN 2.0A popisuje pouze linkovou vrstvu protokolu CAN. Je ale součástí normy ISO 11898, která již fyzickou vrstvu popisuje. Aplikační vrstva je definována v několika standardech (CANopen, DeviceNet), které jsou vzájemně nekompatibilní. Později došlo k rozšíření původní specifikace vzniká tak Specifikace CAN 2.0B, která je předmětem této Diplomové práce. 2.1.1 Základní vlastnosti CAN umožňuje distribuované řízení systémů v reálném čase s přenosovou rychlostí do 1Mbit/s a vysokým stupněm zabezpečení přenosu proti chybám. Jedná se o protokol typu multi-master, kde každý uzel sběrnice může být master a řídit tak chování jiných uzlů. Zvyšuje se tím spolehlivost (při poruše jednoho uzlu může zbytek sítě pracovat dál). Pro řízení přístupu k médiu je použita sběrnice s náhodným přístupem, která řeší kolize na základě prioritního rozhodování. Zprávy přenášející informace po sběrnici jsou uvozeny identifikátorem, který udává význam zprávy a její prioritu. Neobsahují tedy žádnou adresu cílového uzlu a jsou přijímány všemi uzly, které jsou připojeny ke sběrnici. Nejvyšší prioritu má zpráva s identifikátorem 0. V případě kolize zpráv je přednostně doručena zpráva s vyšší prioritou. Na základě identifikátoru je možné zajistit filtrování zpráv a uzel tak bude přijímat pouze ty zprávy, které se ho týkají. 2.1.2 Fyzická vrstva CAN specifikace 2.0B neklade žádné konkrétní požadavky na fyzickou vrstvu. Definuje pouze dvě vzájemně komplementární hodnoty bitů na sběrnici dominant a recessive, které představují obecné ekvivalenty logických úrovní. Hodnoty těchto úrovní nejsou určeny a záleží na konkrétní realizaci fyzické vrstvy. Pro úroveň na sběrnici platí tato pravidla: Jestliže všechny uzly vysílají hodnotu recessive, je na sběrnici hodnota recessive. Jestliže alespoň jeden z uzlů vysílá hodnotu dominant, je na sběrnici hodnota dominant. Více o fyzické vrstvě například v [15]. 6

SBĚ RNICE CAN A DALŠÍ 2.1.3 Linková vrstva Linková vrstva protokolu je definována Specifikací CAN 2.0B a je tvořena dvěma podvrstvami: MAC (Medium Access Control) zajišťuje přístup k fyzické vrstvě (provádí kódování dat, řízení přístupu s rozlišením priorit zpráv, vkládání bitů, detekce a hlášení chyb a potvrzování korektně přijatých zpráv). LLC (Logical Link Control) provádí filtrování přijatých zpráv a hlášení o přetíženích. 2.1.4 Způsoby zabezpečení a detekce chyb Protokol CAN definuje několik mechanismů, které zabezpečují přenos dat po sběrnici. Tyto mechanismy jsou v činnosti současně. Monitorování sběrnice. Vysílající uzel porovnává hodnotu právě vysílaného bitu se skutečnou úrovní na sběrnici. Jsou-li hodnoty rozdílné, vygeneruje chybovou zprávu. Neplatí to ve dvou částech vysílaného rámce. První je oblast identifikátoru (Arbitration Field), kde probíhá řízení přístupu na sběrnici. V tomto případě, detekuje-li vysílající uzel na sběrnici jinou hodnotu než vysílá (to může být pouze tehdy, vysílá-li recessive a na sběrnici je dominant), musí okamžitě přerušit vysílání znamená to, že na sběrnici vysílá jiný uzel správu s vyšší prioritou (ta tím nebude vzhledem k vlastnostem fyzické vrstvy nijak poškozena). Druhá oblast je potvrzení přijetí zprávy (ACK bit). CRC kód. Každá zpráva obsahuje na konci 15 bitový CRC kód, který je generován ze všech předchozích bitů zprávy. Jestliže libovolný uzel detekuje chybu CRC, je generována chybová zpráva. Vkládání bitů (Bitstuffing). Jestliže se vysílá na sběrnici po sobě 5 bitů stejné úrovně, je vložen (navíc) bit úrovně opačné. Tento mechanismus slouží nejen k detekci chyb, ale i k synchronizaci jednotlivých uzlů. Jestliže je porušeno pravidlo vkládání bitů, je generován chybový rámec. Formální kontrola zprávy. Kontroluje se, zda vysílaná zpráva má formát shodný se specifikací. Jestliže je na nějakém bitu detekována nesprávná hodnota, je vygenerován chybový rámec. Potvrzení přijetí zprávy (Acknowledge) je-li zpráva korektně přijata libovolným uzlem, je to potvrzeno změnou hodnoty jednoho bitu (ACK) zprávy. Vysílač vždy na tomto bitu vysílá recesivní úroveň a detekuje-li dominantní úroveň, je vše v pořádku. V opačném případě vysílá chybový rámec. Potvrzování přijetí zprávy je prováděno všemi uzly připojenými ke sběrnici. 7

SBĚ RNICE CAN A DALŠÍ 2.1.5 Signalizace chyb Každý uzel interně počítá množství chyb při příjmu a vysílání. Podle množství těchto chyb pak uzel může být: Aktivní (Error Active) může se aktivně podílet na komunikaci na sběrnici a v případě detekce libovolné chyby vysílá aktivní příznak chyby (6 dominantních bitů, které poruší pravidlo vkládání bitů a poškodí přenášenou zprávu). Pasivní (Error Passive)- také se podílí na komunikaci, ale v případě detekce chyby vysílají pouze pasivní příznak chyby (6 recesivních bitů, které přenášenou zprávu neporuší) Odpojené (Bus-off) tyto uzly sběrnici nijak neovlivňují. Uzel může být přepnut do stavu Bus-off, pokud generuje příliš mnoho chyb. 2.1.6 Zprávy linkového protokolu Specifikace CAN 2.0B definuje 4 typy zpráv (rámců). Dvě jsou určeny pro datovou komunikaci (datová zpráva a žádost o data) a dvě k jejímu řízení (chybová zpráva a žádost o prodlevu v komunikaci). Datová zpráva (Data Frame) Má dvě varianty standardní (Standard Frame) a rozšířená (Extended Frame). Podstatný rozdíl je pouze v identifikátoru, kdy pro Standard Frame má délku 11 bitů a pro Extended Frame 29 bitů. Vysílání datové zprávy může začít pouze tehdy, je-li sběrnice volná. Pak může libovolný uzel začít vysílat. Jestli získá sběrnici pro sebe záleží na prioritě identifikátoru zprávy, kterou vysílá (viz. monitorování sběrnice). Standardní datový rámec Volná sběrnice Řízení přístupu na sběrnici Řídící oblast Datová oblast CRC Potvrzení SOF Identifikátor zprávy 11 bitů RTR IDE R0 Délka datové oblasti 0-8 bajtů dat CRC součet 15 bitů ERC ACK ACD Konec rámce Mezera mezi rámci Rozšířený datový rámec Volná sběrnice Řízení přístupu na sběrnici Řídící oblast Datová oblast SOF Identifikátor zprávy 11 bitů SRR IDE Identifikátor zprávy 11 bitů RTR R1 R0 Délka datové oblasti Obr. 3: Standardní a rozšířený datový rámec 8

SBĚ RNICE CAN A DALŠÍ Na obrázku Obr. 3 jsou znázorněny oba dva typy datových rámců. Rozšířený rámec je zobrazen pouze zčásti, neboť od délky datové oblasti je shodný se standardním. Význam bitů je následující: SOF (Start Of Frame) - začátek rámce, 1 dominantní bit. Standardní identifikátor zprávy ID11 11 bitů, udává význam přenášené zprávy. 1. bit je nejvýznamnější. Rozšířený identifikátor zprávy ID18 18 bitů, méně významných 18 bitů (z celkem 29) identifikátoru rozšířeného rámce. RTR/SRR (Remote Request / Substitute Remote Request) po ID11 1 bit. Bit následující po standardním identifikátoru má dva významy. Ve standardním rámci jej označujeme RTR a je příznakem, zda se jedná o datovou zprávu (dominantní hodnota), nebo o žádost o vyslání dat (recesivní hodnota). V rozšířeném rámci je označen jako SRR a má vždy recesivní hodnotu. Tím je zajištěno, že při vzájemné kolizi standardního a rozšířeného rámce se stejným 11 bitovým identifikátorem, získá přednost standardní rámec. Bit RTR udávající, zda se jedná o datovou zprávu nebo o žádost o data, je v rozšířeném rámci přesunut až za konec druhé části identifikátoru. IDE (Idetifier Extended) 1 bit, dominantní pro standardní rámec, recesivní pro rozšířený rámec. R1, R0 rezervované bity. Podle specifikace by měly být vysílány jako dominantní, ale při příjmu akceptovány v obou úrovních. Délka datové oblasti (Data Field) 4 bity, počet přenášených datových bajtů ve zprávě. Povolené hodnoty jsou 0-8. Datová oblast (Data Field) nejméně 0 a nejvýše 8 datových bajtů. Jsou vysílány od nejvíce významného bitu. CRC kód 15 bitů CRC součtu. CRC součtem je zajištěna celá oblast od SOF až po poslední datový bit. ERC oddělovač CRC součtu 1 dominantní bit. ACK bit potvrzení, 1 bit (viz. 2.1.4). ACD oddělovač potvrzení ACK 1 recesivní bit. Konec rámce (End Of Frame) 7 recesivních bitů. Mezera mezi rámci (Interframe Space, IF) slouží k oddělení zpráv, 3 recesivní bity. V případě, že uzel čeká na vyslání zprávy protože se právě vysílá jiný rámec, mů- 9

SBĚ RNICE CAN A DALŠÍ že zahájit přístup ke sběrnici nejdříve po druhém bitu Interframe Space. Třetí IF bit tedy již může být SOF. Žádost o data (Remote Frame) Formát žádosti o data je obdobný jako formát datové zprávy. Žádost o data je signalizována recesivní úrovní příslušného bitu RTR (viz. předchozí odstavec) a chybí datová oblast. Identifikátor udává typ zprávy, jejíž zaslání je požadováno. Bit RTR v datové zprávě má dominantní úroveň. Datová zpráva se stejným identifikátorem jako žádost o data má tedy vyšší prioritu. To je výhodné v situaci, kdy jeden uzel žádá o data s nějakým identifikátorem a jiný uzel je zrovna vysílá. Chybová zpráva (Error Frame) Chybový rámec (Obr. 4) generuje libovolný uzel ihned, jakmile detekuje v přenášené zprávě nějakou chybu (chyba vkládání bitů, chyba rámce, chyba CRC). Příznak chyby může být buď pasivní nebo aktivní (viz. kapitola 2.1.5). Při generování aktivního příznaku chyby (6 dominantních bitů) je přenášená zpráva poškozena (je porušeno pravidlo vkládání bitů), a tedy i ostatní uzly začnou vysílat chybové zprávy. Výsledný chybový rámec je potom dán superpozicí všech chybových příznaků, které vysílají jednotlivé uzly. Délka této oblasti může být 6 12 bitů. Chybová zpráva Datový rámec nebo Oddělovač chyb nebo Oddělovač zprávy o přetížení Chybový příznak Chybový oddělovač Mezera mezi rámci nebo zpráva o přetížení Superpozice chybových příznaků Obr. 4: Chybový rámec Po vyslání svého chybového příznaku vysílá každá stanice na sběrnici recesivní bity a zároveň detekuje stav sběrnice. Jakmile najde první bit na sběrnici také recesivní, vysílá dalších 7 recesivních bitů jako chybový oddělovač. Zpráva žádosti o přetížení (Overload Frame) Tato zpráva slouží k oddálení vyslání další datové zprávy nebo žádosti o data. Tento způsob využívají zařízení, která nejsou schopna kvůli svému vytížení přijímat a zpracovávat další zprávy. Struktura zprávy je formálně stejná jako struktura chybového rámce z obrázku Obr. 4. Místo chybového příznaku máme příznak přetížení (6 dominantních bitů), místo superpozice chybových příznaků superpozici příznaků přetížení 10

SBĚ RNICE CAN A DALŠÍ (pokud jsou generovány více uzly současně) a chybový oddělovač bude nahrazen oddělovačem zprávy o přetížení (8 recesivních bitů). Úplný popis Specifikace CAN 2.0B je v [1]. 2.2 Hradlová pole Použití hradlových polí přináší celou řadu výhod. Mezi nejpodstatnější patří flexibilita (s absencí diskrétních součástek spočívá změna v návrhu pouze ve změně programu jedné součástky), výkon (integrování více obvodů do jednoho), cena (zvláště u složitých systémů) a v neposlední řadě vývojové prostředky (integrovaná návrhová prostředí zjednodušují práci při návrhu jedno takové je popsáno v kapitole 2.3). 2.2.1 Základní časové parametry Jedním z nejdůležitějších kritérií při výběru programovatelného pole pro návrh systému jsou časové parametry. Na obrázku Obr. 5: Časové parametry programovatelných obvodů jsou shrnuty základní časové parametry důležité při praktickém návrhu. Jejich význam je uveden v tabulce Tab. 1. Vstup ts th Hodinový signál tco Signály D > Q Kombinační logika D Q > Registrovaný výstup Hodiny tscs tpd Kombinační výstup Obr. 5: Časové parametry programovatelných obvodů Parametr Název Popis t PD Propagation delay Zpoždění mezi vstupem a výstupem způsobené kombi- nační logikou. t S Setup time Minimální doba ustáleného signálu na vstupu registru před příchodem hrany hodinového signálu. t H Hold time Minimální doba ustáleného signálu na vstupu registru po příchodu hrany hodinového signálu. t CO Clock-to-output-delay Zpoždění platné hodnoty na registrovaném výstupním pinu součástky za hranou hodinového signálu (výstup registru je přímo připojen na výstupní pin) t SCS System clock to clock delay Doba šíření signálu z výstupu jednoho registru na vstup druhého registru. Převrácená hodnota určuje maximální použitelný hodinový kmitočet. Tab. 1: Časové parametry programovatelných obvodů 11

SBĚ RNICE CAN A DALŠÍ Obr. 6: Architektura obvodu ACEX 1K 2.2.2 Architektura hradlového pole ACEX 1K Architektura obvodu ACEX 1K je znázorněna na obrázku Obr. 6 (zdroj obrázku: [5]). Programovatelný obvod ACEX obsahuje velké množství logických elementů (Logic Element, LE). Jejich konkrétní počet závisí na typu součástky. Logické elementy jsou uspořádány do větších logických bloků (Logic Array Block, LAB). Logické bloky jsou uspořádány do řádků a sloupců. Každý řádek obsahuje také jedno zabudované pole RAM (Embedded Array Block, EAB) o kapacitě 4096 bitů, které je možné využít k implementaci mnoha typů pamětí (RAM, ROM, FIFO atd), ale i kombinační logiky. Logické bloky a zabudovaná pole RAM jsou mezi sebou propojena soustavou propojovacích kanálů (FastTrack Interconnect). Propojovací kanály rozdělují vnitřní strukturu na řádky (Row Interconnect) a sloupce (Column Interconnect). Jednotlivé signálové cesty jsou mezi sebou propojeny multiplexy. I/O elementy (IOE) jsou umístěny na jejich koncích. Každý obsahuje programovatelný registr, pomocí kterého je možné dosáhnout krátkých výstupních časů t CO. Součástka je vybavena 6 vyhrazenými vstupy. Tyto vstupy jsou určeny pro globální signály jako CLK, RESET, ENABLE apod. V propojovací struktuře je jim vyhrazena speciální vrstva, ve které je zaručeno minimální zpoždění. 12

SBĚ RNICE CAN A DALŠÍ Logické elementy (LE) Je to nejmenší prvek pro implementaci logické funkce. Každý logický element obsahuje tzv. LUT (Look-up Table). LUT umožňuje realizovat jakoukoliv funkci se 4 vstupy. Dále obsahuje pomocné prvky pro aritmetické a logické operace, které využívají speciální komunikační kanály mezi logickými elementy stejného logického bloku (viz. dále). Jedná se o tzv. Carry-chain, podporující implementaci vysokorychlostních čítačů a sčítaček a Cascade-chain umožňující implementaci mnohovstupých logických funkcí s minimálním zpožděním. Logické bloky (LAB) Oproti standardní architektuře typu FPGA nejsou jednotlivé logické elementy propojeny přímo, ale jsou sdruženy po osmi do logických bloků. Tím se zlepšují časové parametry a snižují potíže s přímým propojováním mnoha elementů. Logické elementy jsou v logickém bloku propojeny lokálním propojovacím polem (Local Interconnect). Logické bloky jsou propojeny pouze řádkovým kanálem. Z toho plyne, že v situaci, kdy je třeba propojit logické elementy z rozdílných řad, dochází k velkému zpoždění signálu. Více o hradlových polích ACEX v [5]. 2.3 Integrované návrhové prostředí EMAX+plus II a jazyk AHDL EMAX+plus II EMAX+plus II je komplexní vývojové prostředí od firmy Altera pro návrh všech rodin programovatelných logických obvodů této firmy. Jeho nejpodstatnější vlastnosti lze shrnout do následujících bodů: Podpora hierarchického návrhu. Možnost návrhu designu několika metodami (jazyk AHDL, VHDL, pomocí grafického rozhraní). Možnost funkční i časové simulace. Takto je možné provést prakticky celý návrh pouze na papíře Obsahuje tzv. Floorplan Editor, který umožňuje provádět ručně změny prostorového uspořádání návrhu v konkrétním hradlovém poli. Součástí je i Timing Analyser, který umožňuje výpočet maximálního použitelného hodinového kmitočtu pro konkrétní návrh a konkrétní hradlové pole a výpočet zpoždění signálových cest. 13

SBĚ RNICE CAN A DALŠÍ Jazyk AHDL Pro návrh byl zvolen jazyk AHDL. AHDL (Altera Hardware Description Language) je modulární jazyk, plně integrovaný v prostředí EMAX+ plus II. Je vhodný zejména pro návrh komplexních kombinačních funkcí a stavových automatů. Návrháři dává k dispozici množství konstrukcí potřebných pro popis chování složitých systémů. Struktura programu vytvářeného v jazyce AHDL je obdobná struktuře jiných vyšších programovacích jazyků (Pascal, C apod.). Základní rámcová struktura každého návrhu vypadá takto: include "design.inc"; SubDesign name -- připojení modulu nebo funkce -- název designu ( signaly : typ; -- definice vstupů a výstupů návrhu ) Variable datovy objekt : typ; Begin -- definice promennych -- začátek výkonné části programu konstrukce kombinacni logiky; konstrukce sekvencni logiky; End; -- konec výkonné části programu Datový objekt. Jazyk AHDL nabízí celou řadu (několik desítek) datových objektů, které nazývá Primitive. Ty představují základní stavební kameny celého návrhu. Jedná se například o různé klopné obvody (DFF, DFFE, JKFF, SRFF), základní logické struktury (AND, OR, NAND ), třístavové buffery (TRI) apod. Megafunkce. Jsou velmi silným nástrojem jazyka AHDL. Do návrhu se vkládají direktivou INCLUDE a představují nový datový typ. Prakticky představují zapouzdřené komplexní logické bloky realizující definovanou funkci. Altera nabízí celou řadu funkcí, které jsou součástí instalace. Takto je možné přímo vložit do návrhu různé paměti (FIFO, RAM, ROM), složité kombinační obvody (komparátory, multiplexery, násobičky) apod. Vlastní návrh těchto obvodů zůstává pro programátora skryt a přistupuje k nim pouze pomocí jejich vstupů a výstupů. Konstrukce kombinační logiky. Prvky pro konstrukci kombinační logiky jsou obdobné jiným programovacím jazykům jedná se zejména o prosté přiřazení (proměnná = hodnota) a podmínkové konstrukce if then else a case is when.jazyk také podporuje vytváření kombinační logiky pomocí pravdivostních tabulek. Konstrukce sekvenční logiky. Nejvýznamnějším nástrojem (a v návrhu analyzátoru hojně používaným) jsou stavové automaty. Struktura stavového automatu vypadá takto: 14

SBĚ RNICE CAN A DALŠÍ case var_automatu is when stav_1 => konstrukce kombinacni logiky; when stav_2 =>... konstrukce kombinacni logiky; when stav_n => end case; konstrukce kombinacni logiky; Úplný popis jazyka AHDL a vývojového prostředí EMAX+plus II lze nalézt například v [2] a [10]. 2.4 Rozhraní Universal Serial Bus (USB) USB je sériový komunikační protokol s přenosovou rychlostí do 12 Mb/s a s možností připojení až 127 zařízení. Jeho významnou předností je fakt, že je v současné době prakticky standardním vybavení počítačů typu PC. Jedná se o protokol typu master-slave, kdy se počítač (USB host) periodicky (1 ms) dotazuje jednotlivých USB zařízení, zda mají nějaká data k přenosu nebo zda mohou nějaká data přijmout. 2.4.1 Topologie USB USB vytváří několikaúrovňovou hvězdicovou strukturu. Středem každého hvězdicového propojení je rozdělovač (Hub) a jednotlivé propojovací segmenty. Ty mohou spojovat buď počítač (USB host), který obsahuje centrální rozdělovač s funkčními jednotkami (myš, klávesnice, modem) a rozdělovači na vyšší úrovni, nebo rozdělovač s funkčními jednotkami a rozdělovači na nižší úrovni. Celá situace je znázorněna na obrázku Obr. 7. Každé USB zařízení má svojí USB adresu a podporuje několik koncových jednotek HOST HUB 1 Vrstva 1 HUB 2 F.J. F.J. Vrstva 2 HUB 3 HUB 4 F.J. F.J. Vrstva 3 F.J. F.J. F.J. F.J. Vrstva 4 Obr. 7: Topologie USB 15

SBĚ RNICE CAN A DALŠÍ (Endpoints). Endpoint s číslem 0 musí mít každé zařízení a je určené pro kontrolní přenosy (viz. dále). Prakticky to znamená, že USB zařízení může komunikovat s PC po několika nezávislých duplexních kanálech. 2.4.2 Přenos dat Pro veškerou komunikaci mezi počítačem a funkční jednotkou jsou k dispozici tři typy paketů. Výměna začíná tím, že počítač vyšle tzv. token packet, který obsahuje informace o typu a směru výměny dat, adresu USB zařízení a číslo endpointu. Velikost (ve smyslu datové kapacity) příslušného endpointu udává maximální počet dat, které je možné přenést v rámci jedné datové výměny. Potom příslušné oslovené zařízení, které má vysílat data, vyšle datový paket nebo signalizuje, že žádná data nemá k dispozici. Přijímací strana na závěr vyšle tzv. handshake packet, kterým informuje, zda přenos proběhl úspěšně. USB rozeznává 4 typy datových přenosů: Kontrolní přenosy (Control Transfers). Tyto přenosy jsou využívány pro konfiguraci funkčních jednotek při jejich prvním připojení. Jedná se o zabezpečený přenos a data mají definovanou strukturu. Za tímto účelem je využíván endpoint 0 připojené funkční jednotky, který je pro tyto účely vyhrazen. Po připojení je počítačem (USB host) vyčten deskriptor funkční jednotky a je tak získán její úplný popis (počet endpointů, jejich velikost, typ funkční jednotky atd.). BULK přenosy (Bulk Transfers). Tento typ přenosů je určen pro relativně velké objemy přenášených dat. Jedná se o zabezpečený přenos a data mají definovanou strukturu. Prostor věnovaný BULK přenosům je ale závislý na dalších přenosech, a není tak zaručen čas potřebný pro přenos. Velikost bulk endpointu může být 8, 16, 32 nebo 64 bajtů. Přenosy s přerušením (Interrupt Transfers). Jsou určeny pro přenos malých objemů dat (typicky několik bajtů), které jsou periodicky vysílány (změna polohy myši). Přenos je zabezpečený, data mají definovanou strukturu a čas pro přenos je zaručený. Perioda může být v rozsahu 1 255 ms. Maximální velikost interrupt endpoint může být 64 bajtů Izochronní přenosy (Isochronous Transfer). Jedná se o čistý tok dat, jejichž struktura není definována. Přenos těchto dat není zabezpečen. Maximální velikost izochronního endpointu může být 1023 bajtů. Pro kódování dat je použit kód NRZI, jedná-li se o zabezpečený přenos, je jištěn CRC součtem a vkládáním bitů. 16

SBĚ RNICE CAN A DALŠÍ 2.4.3 Napájení funkčních jednotek USB může s komunikací zajišťovat i napájení funkčních jednotek. S následujícími parametry: Jedná-li se o výkonové připojení (High-Power-Port), může funkční jednotka odebírat proud až 500 ma (ovšem ne bezprostředně po připojení, nýbrž až poté, co proběhla její konfigurace do té doby pro ní platí následující pravidla) V případě běžného připojení (Low-Power-Port) může funkční jednotka odebírat maximálně 100 ma. Dále musí platit, že zařízení napájená z USB musí podporovat režimy se sníženou spotřebou. V takovém režimu mohou odebírat ze sběrnice maximálně 0.5 ma. Pokud zařízení tyto požadavky nesplňuje, musí být vybaveno vlastním zdrojem. 2.4.4 Přenosová rychlost USB Jsou definovány dvě verze. High Speed s přenosovou rychlostí do 12 Mbit/s a Low Speed s rychlostí do 1,5 Mbit/s. Obě verze se liší propojovacími kabely. Kabely jsou čtyřvodičové (D+, D-, +5V a GND), pro 12Mbit/s musí být vodiče zkrouceny, kabel musí být stíněný a jeho max. délka je 5 m. Pro 5 Mbit vodiče zkrouceny být nemusí, kabel nemusí být stíněný a maximální délka je 3 m. Při uvažování maximální přenosové rychlosti je třeba vzít v úvahu, že jedno připojení sdílí více periferií současně, takže reálná přenosová rychlost bude nižší. Navíc je zde ještě omezení, že žádné zařízení nesmí překročit přenosovou rychlost 6 Mbit/s. Této rychlosti lze také využít pouze tehdy, pokud součty přenosových rychlostí všech ostatních zařízení nepřesáhnou také 6Mbit/s. 2.4.5 Připojení funkční jednotky ke sběrnici. Rozhraní funkčních jednotek jsou doplněna zakončovacími odpory. Vodiče D+ (pro High Speed) a D- (pro Low Speed) jsou přivedeny přes rezistory 1,5 kω na napětí 3,6V. Při připojení a odpojení kabelu vzniká na příslušné svorce (podle typu zařízení) odpovídající přechodový děj, na základě kterého je identifikováno připojení nebo odpojení USB zařízení a jeho typ (z hlediska přenosové rychlosti). Více o sběrnici USB například v [8] a [14]. 17

ANALYZÁTOR SBĚ RNICE CAN Kapitola 3 Design analyzátoru v hradlovém poli Tato kapitola postupně popisuje hierarchický design CAN analyzátoru v hradlovém poli a tvoří stěžejní část Diplomové práce. V úvodu je představeno orientační blokové schéma CAN analyzátoru. Jednotlivé bloky tohoto schématu jsou definovány a podrobně popsány jako samostatné dílčí obvody. Tyto obvody jsou poté propojeny a je představeno detailní schéma CAN analyzátoru v kontrastu s hrubým blokovým schématem načrtnutým v úvodu. Vzniká tak zapouzdřená fiktivní součástka, kterou nazveme CAN analyzátor. V závěru je CAN analyzátor doplněn ještě o dvě periferie - Řízení paměti DRAM a Komunikační rozhraní. Propojením těchto obvodů je návrh analyzátoru v hradlovém poli ukončen. 3. Design analyzátoru v hradlovém poli

DESIGN ANALYZÁTORU V HRADLOVÉM POLI 3.1 Blokové schéma V souladu s úvodníkem k této kapitole zaveďme nejdříve konvenci, že pokud nebude výslovně uvedeno jinak, budeme termínem CAN analyzátor označovat strukturu definovanou na obrázku Obr. 8. Připomeňme také odkaz na značení logických úrovní v kapitole 1.4. CLK ENABLE MAIN COUNTER BUS IDLE REAL TIME COUNTER BIT COUNTER RESET CAN MAIN LOOP D STARTUP UNIT MAIN START UNIT DATA READ UNIT WRITE TO FIFO Q CAN END LOOP INPUT TRIGGER MAIN TIMER CAN ERR LOOP OUTPUT TRIGGER INTRIG OUTTRIG CLK SYNC INPUT BIT DESTUFFING CYCLIC REDUNDANCY CHECK CAN_BUS Obr. 8: Blokové schéma CAN analyzátoru 3.1.1 Výhody hierarchického přístupu Dekompozice problému na jednotlivé logicky oddělené dílčí části, jejich samostatné řešení a následná syntéza do konečného jednotného celku jsou základní prvky používané při hierarchickém návrhu, což je přirozený proces pro lidské myšlení při řešení složitých problémů. Rozdělení CAN analyzátoru do jednotlivých bloků vede k přehlednosti celého návrhu. Umožňuje rovněž snadnější odhalení chybného chování a pružnější testování a simulaci. V neposlední řadě nelze opominout ani dobu potřebnou pro překlad celého designu a simulaci, která při rozsáhlejších projektech i při výkonech dnešních počítačů zabere několik minut. 19

DESIGN ANALYZÁTORU V HRADLOVÉM POLI 3.1.2 Dekompozice CAN analyzátoru Na obrázku Obr. 8 je zobrazeno blokové schéma CAN analyzátoru, ve kterém jsou, zatím pouze v hrubých rysech, patrné signálové toky mezi jednotlivými obvody. Bílá šipka představuje synchronizovaný signál sběrnice CAN a šipka černá signál reprezentující odebraný vzorek bitu pro stavovou analýzu. Všechny obvody CAN analyzátoru jsou synchronizovány globálním signálem CLK nebo signály z něho odvozenými, což je nezbytná podmínka pro jejich korektní spolupráci. Kromě zmíněného vstupu CLK jsou dalšími vstupy globální signály RESET a ENABLE sloužící pro restart a povolení funkce CAN analyzátoru. Dále signál vlastní analyzované sběrnice CAN a signál vstupního triggeru INTRIG. Pro zápis do konfiguračních registrů je k dispozici osmibitový datový vstup (do obvodu STARTUP UNIT) s příslušnými řídícími signály. Výstupy představuje osmibitový datový výstup pro předávání výsledků analýzy (z obvodu WRITE TO FIFO) s příslušnými řídícími signály a signál výstupního triggeru OUTTRIG. Pohled na CAN analyzátor z hlediska jeho vstupů a výstupů představuje nejvyšší stupeň v hierarchii návrhu, postavený na nižších stupních tvořených jednotlivými obvody a jejich částmi. Na každý takový obvod budeme pohlížet jako na samostatný funkční celek a přiřadíme mu schematickou značku znázorňující jeho vývody. Tyto značky pak v závěru využijeme k sestavení detailního schématu celého CAN analyzátoru. Nyní si jednotlivé obvody popišme. 3.2 Funkce obvodů CAN analyzátoru 3.2.1 Obvod Bit Destuffing (BDE) Jeden z mechanismů zabezpečení přenosu dat na sběrnici CAN je mechanismus vkládání bitů (Bitstuffing), který zajišťuje, že na sběrnici se může vyskytnout nejvýše pět bitů po sobě jdoucích stejné logické úrovně a poté musí následovat šestý, vložený, bit úrovně opačné. Není-li šestý bit opačné úrovně než pět předchozích, jedná se o chybu bitstuffingu (viz. kapitola 2.1.4). Obvod BDE generuje na svých výstupech signály definující stav právě přijatého bitu z pohledu mechanismu vkládání bitů: zda se jedná o bit vložený nebo zda se jedná o chybu bitstuffingu a v jaké logické úrovni. Stavový automat obvodu BDE Funkce obvodu BDE je realizována stavovým automatem, jehož přechodový graf je na obrázku Obr. 9. Činnost automatu lze shrnou v následujících bodech: 20

DESIGN ANALYZÁTORU V HRADLOVÉM POLI 1 BDRES start 0 0 BD11 1 BD01 1 0 BD12 0 1 BD02 1 0 BD13 0 1 BD03 1 0 1 0 BD14 BD04 1 1 0 1 0 0 BD15 0 BD06 BD16 1 BD05 1 0 BDSER stop STUFF_BIT BDSED stop RECESSIVE_ERR DOMINANT_ERR Obr. 9: Přechodový graf stavového automatu obvodu BDE Po restartu obvodu se automat nachází ve stavu BDRES. Je-li následující bit recesivní, automat přechází do stavu BD11 v levé větvi grafu (analogicky pro dominantní bit přejde automat do stavu BD01 v prvé části grafu). Pro následující čtyři recesivní, resp. dominantní, bity prochází automat postupně stavy BD12 - BD15, resp. stavy BD02 - BD05. Bude-li některý z těchto čtyř bitů dominantní, resp. recesivní, přejde automat do stavu BD01 v pravé větvi grafu, resp. BD11 v levé větvi. Obdrží-li automat ve stavu BD15, resp. BD05, recesivní, resp. dominantní, bit, přechází do stavu BDSER, resp. BDSED a signalizuje chybu vkládání bitů v recesivní, resp. dominantní, úrovni. Tyto stavy jsou konečné a automat (obvod BDE) musí být pro další činnost restartován. 21

DESIGN ANALYZÁTORU V HRADLOVÉM POLI Jestliže bude bit ve stavu BD15, resp. BD05, dominantní, resp. recesivní, přechází automat do stavu BD06, resp. BD16, a signalizuje vložený bit. Ze stavu BD06 přechází automat v případě recesivního bitu do stavu BD11, v případě dominantního do stavu BD02 (stav BD06 zde supluje stav BD01). Ze stavu BD16 pro dominantní bit přejde automat do stavu BD01 a pro recesivní do stavu BD12 (v tomto případě supluje stav BD16 stav BD11). CLK_RUN RESET CAN_DATA STUFF_BIT RECESSIVE_ERR DOMINANT_ERR BD04 BD05 BD16 BD01 BD02 BD03 BD04 BD05 BDSED BDSED BDRES Obr. 10: Příklad činnosti automatu obvodu BDE Na obrázku Obr. 10 se automat právě nachází ve stavu BD04. Znamená to, že na sběrnici je čtvrtý dominantní bit v řadě. Protože i pátý bit je dominantní, musí být šestý vložený, opačné úrovně. Splnění této podmínky indikuje signál STUFF_BIT (stav BD16). Následuje pět dominantních bitů (stavy BD01 BD05). Šestý bit je ale také dominantní, což znamená chybu vkládání bitů v dominantní úrovni a automat přechází do stavu BDSED, kde setrvá až do restartu obvodu. Tento stav indikuje signál DOMINANT_ERR. Popis signálů obvodu BDE Schematická značka obvodu BDE je na obrázku Obr. 11 a význam jednotlivých vývodů se zdroji signálů je uveden v tabulce Tab. 2. RESET ENABLE ENA2 STUFF_BIT RECESSIVE_ERR DOMINANT_ERR CLK_RUN CAN_DATA BIT_DESTUFFING Obr. 11: Schematická značka obvodu BDE 22

DESIGN ANALYZÁTORU V HRADLOVÉM POLI Název vývodu Aktivní úroveň Zdroj signálu Popis RESET Vcc MSU, Vnější Nastaví obvod do výchozího stavu. Nutný pro znovuspuštění stavového automatu po detekci chyby vkládání bitů. ENABLE Vcc Vnější Pro povolení funkce obvodu musí být aktivní i ENA2 ENA2 Vcc MSU Pro povolení funkce obvodu musí být aktivní i ENABLE CLK_RUN Náběžná hrana MTR Hodiny pro stavový automat s periodou rovnou bitové rychlosti CANu. Udávají platnost vzorku sběrnice CAN_DATA pro vyhodnocení CAN_DATA - MCT Navzorkovaný bit odebraný z CAN sběrnice v okamžiku SAMPLE_POINT (kap. 3.2.11) - musí být platný před příchodem náběžné hrany CLK_RUN STUFF_BIT Vcc Výstup Signál, že právě vyhodnocený bit je bit vložený. Generuje puls o šířce rovné jedné periodě CLK_RUN RECESSIVE_ERR Vcc Výstup Signál chyby vkládání bitů v recesivní úrovni. Šířka pulsu je daná dobou do restartu obvodu DOMINANT_ERR Vcc Výstup Signál chyby vkládání bitů v dominantní úrovni. Šířka pulsu je daná dobou do restartu obvodu Tab. 2: Popis vývodů obvodu BDE 3.2.2 Obvod Cyclic Redundancy Check (CRC) Výpočet cyklického redundandního kódu patří mezi další způsoby zabezpečení přenosu dat na sběrnici CAN. Obvod CRC provádí výpočet CRC podle algoritmu uvedeném v [1]. Za tímto účelem zavádí 15-ti bitový posuvný registr CRC_RG[14..0] pro vlastní výpočet CRC a jednobitový pomocný registr CRCNXT. Registr CRC_RG[14..0] také představuje jediný výstup obvodu. RESET CRC[14...0] ENABLE ENA2 CLK RUN CAN_DATA CYCLIC_REDUNDANCY_CHECK Obr. 12: Schematická značka obvodu CRC 23

DESIGN ANALYZÁTORU V HRADLOVÉM POLI Celý algoritmus řeší jednoduchý stavový automat. Výpočet (včetně testu na platnost navzorkovaných dat) trvá 4 T CLK (periody hodinového synchronizačního signálu). Schematická značka obvodu je na obrázku Obr. 12, algoritmus činnosti obvodu na obrázku Obr. 13 a tabulka s popisem vývodů a zdroji signálů pro obvod CRC je tabulka Tab. 3. NE RUN RUN Jsou navzorkována data? ANO CAN_DATA CAN_DATA CRCNXT = CAN_DATA XOR CRC_RG[14]; CRC_RG[14..1] = CRC_RG[13..0]; CRC_RG[0] = 0; NE Je rovno CRCNXT jedné? ANO CRC_RG[14..0] = CRC_RG[14..0] XOR H"4599"; CRC[14..0] CRC[14..0] Obr. 13: Algoritmus činnosti obvodu CRC Název vývodu Aktivní úroveň Zdroj signálu Popis RESET Vcc MSU, Vnější Nastaví obvod do výchozího stavu. ENABLE Vcc Vnější Pro povolení funkce obvodu musí být aktivní i ENA2 ENA2 Vcc MSU Pro povolení funkce obvodu musí být aktivní i ENABLE CLK Náběžná hrana Vnější Hodinový synchronizační signál s periodou T CLK = 20ns RUN Vcc MTR Příznak platnosti vzorku CAN_DATA (spuštění výpo- čtu CRC pro navzorkovaný bit) CAN_DATA - MCT Navzorkovaný bit dat z CAN sběrnice CRC[14..0] - Výstup 15 bitů aktuálního stavu výpočtu CRC (výstup regist- ru CRC_RG[14..0] Tab. 3: Popis vývodů obvodu CRC 24

DESIGN ANALYZÁTORU V HRADLOVÉM POLI 3.2.3 Obvod Main Timer (MTR) Protože všechny obvody v CAN analyzátoru pracují paralelně, je třeba zajistit, že úlohy, které mají být kauzálně spojeny (i přesto, že příslušné obvody spolu nijak propojeny nejsou) budou vykonány ve správném pořadí. Typickým příkladem je posloupnost odebrání vzorku dat ze sběrnice, test na vkládání bitů (obvod BDE), výpočet CRC (obvod CRC) a stavová analýza odebraného vzorku (obvod CML). Aby nemusely být tyto obvody vzájemně propojeny a testovat svoje stavy, a zejména z důvodů přehlednějšího a pružnějšího návrhu, byl navržen obvod MTR. Funkcí obvodu MTR je generovat spouštěcí signály pro vybrané obvody CAN analyzátoru v definovaném pořadí a s definovaným zpožděním tak, aby všechny požadované operace byly vykonány ve správném sledu. Obvod MTR také zaručuje dostatečný předstih dat na vstupech obvodů před příchodem hrany hodinového pulsu například dostatečný předstih signálu CAN_DATA před jeho vyhodnocením v obvodu BDE (kapitola 3.2.1). Název vývodu Aktivní úroveň Zdroj signálu Popis RESET Vcc MSU, Vnější Nastaví obvod do výchozího stavu. V případě detekce chyby vkládání bitů je nutno obvod pro obnovení činnosti restarto- vat. ENABLE Vcc Vnější Pro povolení funkce obvodu musí být aktivní i ENA2 ENA2 Vcc MSU Pro povolení funkce obvodu musí být aktivní i ENABLE CLK Náběžná hrana Vnější Hodinový synchronizační signál s periodou T CLK (20ns.) RUN Vcc MCT Spouštěcí signál tohoto obvodu MTR. Časově je totožný s okamžikem odebrání vzorku dat CAN_DATA (puls o šířce 1 T CLK ). CAN_DATA - MCT Navzorkovaný bit dat z CAN sběrnice STUFF_BIT Vcc BDE Příznak, že právě hodnocený bit je bit vložený RECESSIVER_ERR Vcc BDE Příznak, že právě hodnocený bit vyvolal chybu vkládání bitů v recesivní úrovni DOMINANT_ERR Vcc BDE Příznak, že právě hodnocený bit vyvolal chybu vkládání bitů v dominantní úrovni RUN_BIT_ DESTUFFING_UNIT Vcc Výstup Hodiny automatu obvodu BDE spustí test na vkládání bitů RUN_CRC_UNIT Vcc Výstup Spouštěcí signál pro obvod (puls o šířce 1 T CLK ) RUN_CAN_MAIN_LOOP Vcc Výstup Spouštěcí signál pro obvod CML (puls o šířce 1 T CLK ) Tab. 4: Popis vývodů obvodu MTR 25

DESIGN ANALYZÁTORU V HRADLOVÉM POLI NE Byla navzorkována data? ANO RUN Generuj spouštěcí signál pro obvod BDE Zpoždění 1Tclk Zpoždění (DFF) 1Tclk (DFF) RUN_BIT DESTUFFING_UNIT Zpoždění 1Tclk RECESSIVE_ERR OR Nastala chyba vkládání bitů? ANO STOP čekej na restart DOMINANT_ERR NE Jedná se o vložený bit? ANO NE STUFF_BIT Generuj spouštěcí signál pro obvod CRC RUN_CRC_UNIT Zpoždění 1Tclk Zpoždění (DFF) 1Tclk (DFF) Zpoždění 4 Tclk Generuj spouštěcí signál pro obvod CML RUN_CAN_MAIN_LOOP_UNIT Zpoždění 1Tclk Zpoždění 1Tclk Obr. 14: Algoritmus činnosti obvodu MTR 26

DESIGN ANALYZÁTORU V HRADLOVÉM POLI Činnost obvodu je znázorněna na obrázku Obr. 14. Prakticky jí realizuje stavový automat, který je (stejně jako všechny ostatní automaty v návrhu CAN analyzátoru) synchronizován globálním signálem CLK. Takto lze snadno realizovat zpoždění o velikosti n T CLK pouhým přechodem z jednoho stavu do n stavů dalších, ve kterých se jinak nevykonávají žádné funkce. CLK CLK DFF RUN_BIT_DESTUFFING_UNIT STUFF_BIT RECESSIVE_ERR DOMINANT_ERR Stavový automat DFF CLK CLK RUN_CRC_UNIT DFF RUN_CAN_MAIN_LOOP Obr. 15: Struktura obvodu MTR Z uspořádání obvodu na obrázku Obr. 15 je patrné, že spouštěcí signály jsou synchronizovány klopným obvodem typu D (DFF), který způsobuje, že signály jsou od okamžiku generování automatem zpožděny na výstupu o 1 T CLK. Obvod začíná svou činnost čekáním na spouštěcí signál, který obdrží ve stejném okamžiku, kdy je odebrán ze sběrnice CAN vzorek bitu pro analýzu tzv. Sample Point. Od tohoto okamžiku začíná stavová analýza právě navzorkovaného bitu. Obvod MTR nejdříve vygeneruje spouštěcí signál pro obvod BDE (bude zpožděný o T CLK ) a čeká další T CLK na dokončení činnosti tohoto obvodu. V případě, že obvod BDE zjistí chybu vkládání bitů, stavový automat obvodu končí svoji činnost a čeká na restart (další obvody stavové analýzy nejsou spuštěny). Detekuje-li BDE vložený bit, přechází automat do výchozího stavu a čeká na vzorek dalšího bitu. Pokud ani jedna z uvedených podmínek nenastane, znamená to, že je bit platný a MTR vygeneruje signál pro spuštění obvodu CRC (ten bude opět zpožděný o T CLK ). Následující 4 T CLK čeká na dokončení výpočtu CRC. Po jeho dokončení vygeneruje řídící signál pro obvod CML, který realizuje vlastní stavovou analýzu zpráv sběrnice CAN (kapitola 3.2.8). Schematická značka obvodu je na obrázku Obr. 16 a popis vývodů a zdrojů signálů v tabulce Tab. 4. 27

DESIGN ANALYZÁTORU V HRADLOVÉM POLI RESET ENABLE ENA2 CLK RUN STUFF_BIT RECESSIVE_ERR DOMINANT_ERR RUN_BIT_DESTUFFING_UNIT RUN_CRC_UNIT RUN_CAN_MAIN_LOOP_UNIT MAIN_TIMER Obr. 16: Schematická značka obvodu MTR 3.2.4 Obvod Real Time Counter (RTC) Jednou z požadovaných vlastností analyzátoru, tak jak jsme je definovali v kapitole 1.2, je schopnost měření reálného času. Tuto funkci zastává obvod RTC, jehož struktura je na obrázku Obr. 17. CLK 2 32 32x DFF Komparátor OVERLOAD Sčítačka 1 Obr. 17: Uspořádání obvodu RTC Prakticky ji tvoří 32 bitový volně běžící čítač (signál povolení není implementován protože absolutní hodnoty času pro nás nejsou důležité), který je vytvořen pomocí klopných obvodů typu D (DFF) a sčítačky. S každou náběžnou hranou hodinového signálu CLK je obsah čítače inkrementován (zvětšen o jedničku). Čítač čítá od 0 až do hodnoty 2 32-1, poté dojde k přetečení a čítá znovu od nuly. Po dosažení komparační hodnoty 2 32 vygeneruje komparátor puls o šířce 1 T CLK (signál OVERLOAD) jako příznak přetečení čítače. Signál OVERLOAD je potom využit pro zápis této události do vyrovnávací paměti CAN analyzátoru (viz. kapitola 3.2.17). Pro hodinový kmitočet f CLK = 50 MHz dostáváme dobu do přetečení čítače přibližně 85 sekund s rozlišením 20 ns. 28

DESIGN ANALYZÁTORU V HRADLOVÉM POLI Schematická značka obvodu je na obrázku Obr. 18 a popis vývodů a zdrojů signálů v tabulce Tab. 5. RESET CLK RTIME[31...0] OVERLOAD REAL_TIME_COUNTER Obr. 18: Schematická značka obvodu RTC Název vývodu Aktivní úroveň Zdroj signálu Popis RESET Vcc MSU, Vnější Vynuluje čítač RTC CLK Náběžná hrana Vnější Hodinový synchronizační signál s periodou T CLK (20ns) OVERLOAD - Výstup Signál přetečení čítače RTC puls o šířce 1 T CLK RTIME[31..0] - Výstup 32 bitů aktuálního stavu čítače RTC Tab. 5: Popis vývodů obvodu RTC 3.2.5 Obvod Bit Counter (BIC) Kromě časových značek, které nám ve finále umožní generovat obvod RTC popsaný v kapitole 3.2.4, bude třeba pro doplnění informace k některým zprávám přidat ještě číslo bitu, ve kterém příslušná událost nastala. Počítání bitů v jednotlivých datových rámcích od začátku SOF (jak je definuje kapitola 2.1) je úkolem obvodu BIC, jehož schematická značka je na obrázku Obr. 19. Z návrhového hlediska má obvod obdobnou strukturu jako výše popsaný obvod RTC, signály a jejich zdroje jsou zcela odlišné. Čítač je pouze osmibitový, protože nejdelší datový rámec sběrnice CAN nebude mít délku větší než 160 bitů. Obvod nemá komparátor. Hodinový vstup čítače tvoří signál odvozený od okamžiku snímání vzorku bitu ze sběrnice (Sample Point). Čítač je tedy inkrementován a bit započítán v okamžiku, kdy je vzorkován. Popis signálů a jejich zdrojů je v tabulce Tab. 6. RESET COUNT_OF_BITS[7...0] ENABLE ENA2 CLK_RUN BIT_COUNTER Obr. 19: Schematická značka obvodu BIC 29