Acest articol descrie un scenariu care nu este explicat foarte clar în standardul FlexRay, situație care poate fi înșelătoare și poate complica crearea unui cluster de FlexRay funcțional. Va fi descrisă diferența de implementare între două IP-uri FlexRay, unul dezvoltat de către Bosch și unul de NXP.
Implementarea Bosch a IP-ului de FlexRay în arhitectura microcontrolerului poate fi privită ca un periferic care conține FlexRay Communication Controller (CC), setul de regiștri, Protocol Engine (PE) și, de asemenea, memoria încorporată RAM necesară pentru Message Buffers (MB). Figura 1 descrie arhitectura simplă a unui sistem dual core. Accesul făcut de CPU la setul de regiștri și buffers (alocate în memoria încorporată RAM) este făcut prin intermediul Host Interface (HI, numita și CHI). Acest lucru poate fi observat în Figura 2. Dimensiunea memorie incorporate RAM este fixă, ca și numărul de MB. Această implementare este robustă și nu oferă o flexibilitate legată de dimensionarea memorie RAM necesară MB.
Figura 1: Arhitectura unui sistem cu FlexRay Bosch IP încorporat
Figura 2: Schema bloc a Bosch FlexRay IP
NXP a avut o abordare diferită pentru arhitectura sa în care memoria RAM a sistemului este folosită pentru alocarea de FlexRay MB. Astfel se obține un anumit grad de flexibilitate, utilizatorul putând să asigneze doar o parte din MB, reușind să reducă dimensiunea memorie RAM folosită. Memoria RAM încorporată valorificată în implementarea Bosch nu mai este necesară. În acest mod se poate reduce dimensiunea siliciului necesară pentru acest periferic.
Pe de altă parte, această implementare este mai greu de înțeles din cauza complexității. FlexRay CC este implementat ca un master în sistem, capabil să facă accese în RAM prin crossbar ca orice alt CPU din sistem. De fiecare dată când FlexRay CC va citi sau scrie MB (care sunt localizate în RAM-ul sistemului) va lua parte la arbitrarea de la nivelul crossbar (dacă în același moment mai mult de un master vrea să acceseze aceeași resursă).
Setul de regiștri (împreună cu CHI) și PE sunt parte a zonei de periferice, accesibil de către CPU prin peripheral bridge, similar cu restul modulelor. După cum a fost deja menționat, MB sunt parte a memoriei de sistem RAM și pot fi alocate la zona de adrese dorită.
În figura de mai jos, poate fi observată implementarea NXP a modulului de FlexRay. Din unele puncte de vedere poate fi privită similar cu implementarea eDMA, care are, de asemenea, un set de regiștri pentru configurare și status, conectați la busul de periferice și accesați de CPU în timpul execuției rutinei de configurare. După ce configurarea și declanșarea eDMA acționează în sistem ca un master (conectat la master bus), care accesează diferite zone de memorie prin crossbar.
Figura 3: Arhitectura de sistem Freescale cu FlexRay încorporat
Figura 4 descrie schema bloc a modulului încorporat FlexRay în implementarea NXP. Se poate observa ușor că memoria de sistem RAM este accesată prin interfața master bus (BMIF) și setul de regiștri este accesat prin intermediul Periperal Bridge și CHI de către CPU (core-ul care execută codul aplicației).
Este important de menționat ca accesul pentru configurarea MB, regiștri de control și status se face prin intermediul CHI, în timp ce formatul și datele unui mesaj sunt parte a memoriei de sistem RAM a microcontrolerului. FlexRay CC trebuie să facă accesele de citire și scriere în memoria de sistem RAM astfel încât să poată citi sau să actualizeze un MB.
Figura 4: Diagrama bloc a modulului de FlexRay în implementarea NXP
Când FlexRay CC accesează un MB de transmisie pentru a-l actualiza se consideră că acel MB este blocat. PE nu poate folosi conținutul de date al acestui MB (datele conținute nu sunt valide pe timpul blocării) pentru a realiza o transmisie corectă. Ținând cont ca FlexRay este un protocol de comunicație deterministic, în segmentul static, pentru fiecare slot alocat pentru transmisie, nodul trebuie să trimită "ceva" chiar dacă MB este blocat, pentru ca celelalte noduri să vadă că este "viu" și pentru a garanta ca frame-ul de sincronizare este trimis. Din acest motiv frame-ul NULL a fost introdus.
Procesul în cazul unui MB de transmisie blocat pentru actualizare este simplu:
MB de transmisie este blocat;
Datele sunt actualizate;
Figura 5: Accesul CPU și PE către MB
O întrebare poate totuși să apară: ce se întâmplă dacă PE încearcă să transmită datele dintr-un MB blocat? Răspunsul e simplu: PE transmite un NULL frame. Un NULL frame este de fapt un frame cu datele egal cu zero și marcat ca atare de către bitul indicator NULL frame, așa cum poate fi observat în figura 6. Un NULL frame mai poate fi transmis și în cazul în care un nod este configurat nod de sincronizare, dar nici un MB trimis în sloturile asignate lui nu este marcat ca mesaj de sincronizare, sau în timpul inițializării comunicației până la sincronizarea nodurilor.
Figura 6 : NULL frame
Toate acestea sunt acoperite de către standardul de FlexRay, dar un scenariu care se aplică implementării NXP nu este foarte clar descris și poate să inducă în eroare. A fost observat că, dacă accesul FlexRay CC către memoria sistem RAM este blocat de către Unitatea De Protectie a Memoriei (SMPU), accesul este terminat cu un răspuns de eroare către Controllerul de FlexRay. În acest scenariu, PE nu interpretează ca MB ar fi blocat, și în această situație un NULL frame nu este transmis, chiar dacă din punct de vedere al protocolului de FlexRay nodul trebuie să transmită "ceva" în fiecare slot static de transmisie asignat. În cazul în care accesul la buffer nu este posibil, nodul de FlexRay ar trebui să transmită un NULL frame. Scenariul poate fi observat în figura 7 și 8. Figura 7 prezintă un cluster de FlexRay fără restricții către memoria de sistem RAM, în timp ce figura 8 prezintă același cluster, dar cu accesul FlexRay la memoria sistem RAM blocat.
Figura 7: FlexRay cluster cu SMPU oprit
Figura 8: FlexRay cluster cu SMPU pornit și fără NULL frames
Explicația pentru acest scenariu este că pentru a trimite un NULL frame, sunt necesare câteva informații ce trebuie citite din MB - (chiar și în situația în care MB este blocat). De exemplu, informații legate de CRC. Dacă accesul către memoria de sistem RAM este blocat complet pentru FlexRay, aceste date nu pot fi citite și un NULL frame nu poate fi transmis.
În final, comportamentul este unul așteptat, deoarece controllerul de FlexRay va provoca un acces ilegal în busul de sistem. Cum slotul "key" este alocat în slotul 1, acesta va fi transmis, deoarece pentru transmisia unui frame "key" nu este nevoie de interacțiune cu memoria de sistem RAM. Totuși, pentru acest frame, este lansat un acces la memoria de sistem (acces ilegal). Astfel, viitoarele accese către memoria de sistem RAM nu mai sunt efectuate în acel ciclu de comunicație. Acest scenariu se repetă cu următorul ciclu, până când accesul la memoria de sistem RAM este posibil, oprind protecția hardware.
Pentru implementarea Bosch, acest scenariu nu poate fi reprodus din moment ce accesul către MB este un acces intern către memoria încorporată RAM, conținută de modului FlexRay și care nu poate fi blocat printr-o configurare de sistem.
Comportamentul NULL frame-ului în cele două implementări este o consecință directă a soluției hardware aleasă de cei doi producători.
[1]FlexRay Communication System Protocol Specification, Version 2.1a
[2]FRCC2100 Integration Guide - IPextreme, Inc.
[4]http://www.automotivedesignline.com/177104918;jsessionid=WBZLNY3PWQEFIQSNDBOCKHSCJUMEKJVN?printableArtic... 14.02.2006
[5]PowerTM Architecture and FlexRay in the x-by-Wire SPARC Vehicles, Manfred Thanner, Mathias Rausch, Freecale Halbleiter Deutschland
de Andra Chicoș
de Iulia Creta , Bogdan Barza
