ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 147
Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 94
Abonament PDF

Comportamentul NullFrame în diferite implementări FlexRay

Flaviu Nistor
Hardware Development Engineer @ Continental Sibiu



PROGRAMARE

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:

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.

Referințe:

[1]FlexRay Communication System Protocol Specification, Version 2.1a

[2]FRCC2100 Integration Guide - IPextreme, Inc.

[3]http://www.bosch-semiconductors.de/media/pdf_1/ipmodules_1/flexray/WhitePaper_Upgrading_Bosch_E-Ray_FlexRay_IP-Module_for_Pretended_Networking_Support.pdf

[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

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects