Mecanisme de comunicare PPU - SPU

Scopul acestui laborator este familiarizarea cu mecanismele de comunicare intre PPU - SPU si, respectiv, intre SPU - SPU.

Pentru fiecare SPU, MFC-ul asociat gestioneaza canale SPU si registrii MMIO asociati acestora pentru a asigura comunicatia SPU-ului respectiv cu exteriorul (solicitarea si monitorizarea transferurilor DMA, monitorizarea evenimentelor SPU, comunicatia inter-procesor prin mailbox si notificare prin semnale, accesarea resurselor auxiliare etc.). [3.1]

Intre PPE si SPE existra trei mecanisme principale de comunicare:

  1. transferul DMA: folosit pentru a trimite date intre spatiul principal de stocare si memoria locala. SPE-urile folosesc transfer DMA asincron pentru a ascunde latenta memoriei si overhead-ul, ocupandu-se in paralel de calcule.
  2. mailbox-urile: folosite pentru comunicatia de control intre un SPE si PPE sau alte dispozitive, prin mesaje de 32 de biti.
  3. notificarea prin semnale: folosita pentru comunicatia de control intre PPE si alte dispozitive, prin registrii de 32 de biti, care pot fi configurati (in termeni de expeditor-destinatar) ca unu-la-unu sau multi-la-unu.


Mailbox

Comunicarea prin mailbox-uri

Mailbox-urile ofera un mecanism simplu de comunicare, folosit in general de PPE pentru a trimite comenzi scurte la SPE si pentru a primi inapoi statusul efectuarii comenzii [1] . Totusi, practic, permit si comunicarea intre SPE-uri sau intre SPE-uri si alte dispozitive.

Fiecare SPE are acces la trei mailbox-uri (directiile sunt date relativ la SPE):

  1. Inbound mailbox: coada cu o capacitate de 4 mesaje de 32 de biti, in care PPE (sau alte SPE-uri sau dispozitive) scriu mesaje pentru SPU
  2. Outbound mailbox: 'coada' cu o capacitate de 1 mesaj de 32 de biti, in care SPU scrie mesaje pentru PPE sau alte dispozitive
  3. Outbound interrupt mailbox: 'coada' cu o capacitate 1 un mesaj de 32 de biti, in care SPU scrie mesaje pentru PPE sau alte dispozitive, cu intrerupere pentru acestea (vezi sectiunea pentru mai multe detalii).

Termenul de mailbox insa poate referi colectiv toate elementele care asigura acest mecanism: registrii MMIO, canale, stari, intreruperi, cozi si evenimente. [1]


Accesul la mailbox: blocant pentru SPU, non-blocant pentru PPE

SPU acceseaza mailbox-urile, gestionate de MFC-ul sau, prin canale proprii, unul pentru fiecare mailbox. Aceste canale sunt blocante: SPU va astepta daca i se cere sa scrie intr-un outbound mailbox plin (interrupt sau nu) sau sa citeasca dintr-un inbound mailbox gol. Comportamentul blocant pentru SPU al mailbox-urilor este folosit pentru sincronizare.

PPE si alte dispozitive acceseaza mailbox-urile si statusul lor prin registrii MMIO asociati. Acest acces nu este blocant. In cazul in care PPE vrea sa scrie intr-un inbound mailbox plin, se va suprascrie cea mai recenta intrare (e.g. daca PPE scrie de cinci ori inainte ca SPE sa citeasca, mailbox-ul va contine mesajele cu indicii 1, 2, 3 si 5; mesajul cu indice 4 s-a pierdut). [3.1]

Acesta este comportamentul uzual, insa se poate imprima caracter blocant sau non-blocant atat SPU cat si PPE. Pe langa operatiile de citire/scriere in sine, mai sunt disponibile si operatii de interogare a contorului fiecarui mailbox in parte (de 'count'). Aceste operatii nu sunt blocante. Astfel, daca se doreste prevenirea blocarii SPU, se pot folosi astfel de operatii pentru a vedea daca este cazul sa se faca o citire/scriere. La capatul celalat, functiile de acces ale PPU la inbound mailbox si la outbound interrupt mailbox au parametrul 'behavior' care poate fi setat pe blocant.

In considerarea metodei de acces trebuie avute in vedere si criterii de performanta. Pentru SPU accesul la mailbox este 'intern' si cu o latenta foarte mica: cel mult 6 ciclii de ceas pentru acces non-blocant 2. Insa pentru PPE si alte SPE-uri, accesul la mailbox trebuie facut prin intermediul EIB, are o latenta mai mare si duce la incarcarea magistralei.

Pentru mai multe detalii in privinta accesului blocant si non-blocant pe SPU si PPE consultati Fig.2 din sectiunea 1.5 Mailbox la nivel de cod


Scenarii de folosire

Concepute in principal pentru trimiterea de flaguri si stari de program, mailbox-urile, cu cei 32 de biti per mesaj ai lor, pot fi folosite inclusiv pentru a trimite adrese de memorie, parametrii de functii, comenzi etc.

  1. Un exemplu de folosire a mailbox-urilor se regaseste in cazul unei aplicatii SPU bazate pe comenzi. SPU se gaseste in asteptare pana la primirea unei comenzi de la PPE prin intermediul inbound mailbox. Dupa ce termina operatiunea, trimite un cod de raspuns prin outbound interrupt mailbox si intra in asteptare pana la o noua comanda. [1]
  2. O alta maniera de abordare presupune activarea mecanismului de intreruperi la nivelul programului SPE, pentru a raspunde la evenimente asociate unui mailbox. La citirea din outbound mailbox si scrierea in inbound mailbox, PPE poate seta un astfel eveniment SPE, asa cum la scrierea in outbound interrupt mailbox, SPU poate solicita intrerupere la nivelul PPU. [3.1] Pentru mai multe detalii consultati sectiunea 2.5.1
  3. Mailbox-urile sunt folosite, de asemenea, cand un SPE trimite rezultate in memoria principala prin DMA: SPE solicita transferul si asteapta terminarea acestuia, dupa care comunica PPE acest lucru printr-un outbound mailbox. PPE poate atunci sa lanseze comanda lwsync pentru a verifica incheierea cu succes a operatiunii in memoria principala si a folosi datele. Alternativ, SPE poate notifica PPE ca a finalizat operatiunea scriind notificarea direct in memoria principala prin DMA, de unde PPE o poate citi [1],[3.1]
  4. Mailbox-urile pot fi folosite si pentru comunicarea intre SPE-uri, prin transferul DMA al datelor de catre un SPE direct in mailbox-ul unui alt SPE. Pentru aceasta, software privilegiat trebuie sa permita accesul unui SPE la registrul mailbox al unui alt SPE mapand zona de registrii problem-state a SPE-ului tinta in spatiul Effective Address al SPE-ului sursa. Daca acest lucru nu este permis din software, atunci pentru comunicarea intre SPE-uri se pot folosi doar operatii atomice si semnale de notificare. [1],[3.1] Redbook pp 144


Mailbox la nivel de cod

La nivel de cod, exista instructiuni specifice SPU si instructiuni specifice PPU, pentru fiecare din cele trei tipuri de mailbox-uri, atat pentru citire, cat si pentru scriere (i.e. 6 instructiuni pentru SPU si 6 instructiuni pentru PPU):

  • Un program SPU poate accesa mailbox-urile locale prin functii de forma spu_*_mbox, definite in spu_mfcio.h
  • Un program PPU poate accesa mailbox-urile unui SPE prin functii de forma spe_*_mbox_*, definite in libspe2.h
  • Pe langa acestea, un program SPU poate accesa mailbox-urile unui alt SPE prin functii DMA definite in spu_mfcio.h, daca acestea sunt mapate in problem state-ul local al SPU-ului. [3.2]

Mai multe informatii despre spu_mfcio.h gasiti in [3.3] (IBM C/C++ Language Extensions for Cell Broadband Engine Architecture) - capitolul “SPU mailboxes”, iar despre libspe2.h in [3.4] (IBM SPE Runtime Management Library) - capitolul “SPE mailbox functions”.

Fig 1. Functii de acces la mailbox

Cod SPU: SPU intrinsics

Intr-un program SPE, scrierea in mailbox-urile outbound si outbound interrupt se poate face prin instructiunea de scriere write-channel (in assembler wrch), iar citirea dintr-un mailbox inbound cu instructiunea de citire read-channel (in assembler rdch) [3.2] . In C:

  • (uint32_t) spu_read_in_mbox (void), implementare spu_readch(SPU_RdInMbox)
    • citeste urmatorul mesaj din inbound mailbox, SPU intra in asteptare daca mailboxul este gol
    • data este definita in mod particular aplicatiei
  • (uint32_t) spu_stat_in_mbox (void), implementare spu_readchcnt(SPU_RdInMbox)
    • returneaza numarul de mesaje din inbound mailbox, daca este diferit de zero atunci mailbox-ul contine date necitite de SPU
  • (void) spu_write_out_mbox (uint32_t data), implementare spu_writech(SPU_WrOutMbox, data)
    • scrie date in outbound mailbox, SPU intra in asteptare daca mailboxul este plin
    • data este definita in mod particular aplicatiei
  • (uint32_t) spu_stat_out_mbox (void), implementare spu_readchcnt(SPU_WrOutMbox)
    • intoarce capacitatea disponibila a outbound mailbox, rezultat zero arata ca mailbox-ul este plin
  • (void) spu_write_out_intr_mbox (uint32_t data), implementare spu_writech(SPU_WrOutIntrMbox, data)
    • scrie date in outbound interrupt mailbox, SPU intra in asteptare daca mailboxul este plin
    • data este definita in mod particular aplicatiei
  • (uint32_t) spu_stat_out_intr_mbox (void), implementare spu_readchcnt(SPU_WrOutIntrMbox)
    • intoarce capacitatea disponibila a outbound interrupt mailbox, rezultat zero arata ca mailbox-ul este plin

Pentru un exemplu foarte util de folosire parcurgeti Mailbox Hands-on, precum si capitolele 19.6.5 si 19.6.6 din [3.2]

Cod PPU: API disponibil pentru PPE

Urmatoarele functii sunt definite in libspe2.h:

  • int spe_out_mbox_read(spe_context_ptr_t spe, unsigned int *mbox_data, int count)
    • citeste maxim count mesaje din outbound mailbox corespunzator SPE-ului dat de spe
    • daca nu sunt disponibile count mesaje, va citi cate sunt disponibile
  • int spe_out_mbox_status(spe_context_ptr_t spe)
    • citeste statusul lui outbound mailbox corespunzator SPE-ului dat de spe
  • int spe_in_mbox_write(spe_context_ptr_t spe, unsigned int *mbox_data, int count, unsigned int behavior)
    • scrie pana la count mesaje in inbound mailbox
    • poate fi blocant sau non-blocant in functie de valoarea lui behavior:
      • SPE_MBOX_ALL_BLOCKING
      • SPE_MBOX_ANY_BLOCKING
      • SPE_MBOX_ANY_NONBLOCKING
    • versiunea blocanta este utila pentru a trimite o secventa de mesaje, iar cea non-blocanta cand se folosesc evenimente
  • int spe_in_mbox_status(spe_context_ptr_t spe)
    • citeste statusul lui inbound mailbox corespunzator SPE-ului dat de spe
  • int spe_out_intr_mbox_read(spe_context_ptr_t spe, unsigned int *mbox_data, int count, unsigne dint behavior)
  • int spe_out_intr_mbox_status(spe_context_ptr_t spe)

Fig.2: Mailbox blocant vs. non-blocant

Pentru un exemplu foarte util de folosire parcurgeti Mailbox Hands-on, precum si capitolele 19.6.5 si 19.6.6 din [3.2]


Lucrul cu evenimente

Evenimentele se refera la un mecanism SPE care permite codului rulat pe SPU sa anunte evenimente ale rularii programului. In contextul acestui laborator suntem interesati in primul rand de evenimentele declansate de scrierea sau citirea in mailbox si in registrii de notificare prin semnale.

PPE poate intercepta o parte din aceste evenimente, sincron sau asincron:

  • sincron:
    • blocant: citirea statusului evenimentului blocheaza programul pana la aparitia unui eveniment
    • non-blocant: interogarea evenimentelor disponibile se face intr-o bucla
  • asincron:
    • se seteaza un handler care raspunde intreruperii setate de eveniment.


Pentru exemple practice urmariti tutorialele de pe pagina Mailbox Hands-On


Transfer DMA

Prin design, un SPU poate accesa in mod direct doar memoria sa locala (local store). Orice operatie de citire/scriere de date in spatiul principal de stocare (main storage) se face de catre MFC, prin transfer DMA. Optimizarea acestor transferuri joaca un rol crucial in scrierea de programe eficiente pentru Cell. In acest laborator vom discuta concepte de baza pentru intelegerea mecanismului DMA, urmand ca in laboratorul urmator sa discutam mecansime avansate de folosire DMA (e.g. double-buffering).

Marimea unui transfer DMA este limitata la 16 KB.


Roluri: sender si receiver

Directia transferului DMA este numita din perspectiva SPU:

  • pentru transfer de date la SPU, adica din spatiul principal de stocare in memoria locala, se folosesc comenzi de tip get
  • pentru transfer de date de la SPU, adica din memoria locala in spatiul principal de stocare, se folosesc comenzi de tip put

Cu toate acestea, din punctul de vedere al MFC, atat SPU asociat, cat si PPU sau alte SPE-uri pot initia transferul DMA. MFC gestioneaza doua cozi pentru comenzile fara caracter imediat: MFC SPU command queue (cu 16 intrari) pentru comenzi venite de la SPU asociat si MFC proxy command queue (cu 8 intrari) pentru comenzi venite de la PPU sau alte SPE-uri.

In concluzie, atentie la directia de transfer (e.g. daca PPU cere date de la un SPU va folosi comanda de tip put).


Ordonarea transferurilor: fence si barrier

Foarte important! comenzile DMA pot fi procesate nu neaparat in ordine FIFO. De aceea, daca situatia o cere, este important sa se foloseasca forme speciale ale comenzilor get si put (e.g. getf, putb etc.) care utilizeaza mecanisme de sincronizare (fence sau barrier). Mai mult decat atat, MFC dispune de comenzi de sincronizare (e.g. barrier, mfceieio, mfcsync etc.).

Pentru realizarea sincronizarii se foloseste conceptul de tag group. Fiecarei comenzi MFC care intra in coada de comenzi ii este asociat un tag group ID de 5 biti. Tag group-urile sunt independente de la o coada la alta (MFC proxy command queue vs. MFC SPU command queue). In implementarea de Linux a libspe2, tag group id poate lua valori intre 0 si 15.

Comenzi get si put cu fence sau barrier

Comenzile cu sufix ce indica fence impun completarea in prealabil a tuturor comenzilor DMA din acelasi tag group initiate inaintea comenzii curente. Astfel, o comanda initiata ulterior comenzii cu flag-ul fence se poate executa inaintea acesteia din urma.

Comenzile cu sufix ce indica barrier impun completarea in prealabil a tuturor comenzilor DMA din acelasi tag group.

Comenzi de sincronizare

Comanda barrier (functia mfc_barrier pe SPU, indisponibila pe PPU), in contrast cu formele cu bariera ale comenzilor get si put, impune finalizarea tuturor comenzilor MFC din coada de comanda DMA (DMA command queue) lansate in prealabil, indiferent de tag group. Comanda barrier nu are efect asupra comenzilor DMA cu caracter imediat: getllar, putllc, putlluc, care nu pot apartine unui tag group.

Comanda mfcsync (functia mfc_sync pe SPU, intrinsic __sync pe PPU) asigura completarea operatiilor get si put din tag group-ul specificat inaintea altor unitati de procesare si mecanisme din sistem.

Pentru o lista completa a comenzilor de sincronizare consultati [2] pagina 119


DMA la nivel de cod

Atat SPU, cat si PPU au functii ce mapeaza comenzi de tip get si put (* indica posibilitatea de adaugare de sufixe):

  • Un program SPU poate apela functii definite in spu_mfcio.h de tipul:
    • mfc_put*
    • mfc_get*
  • Un program PPU poate apela functii definite in libspe2.h de tipul:
    • spe_mfcio_put*
    • spe_mfcio_get*

Mai multe informatii despre spu_mfcio.h gasiti in [3.3] (IBM C/C++ Language Extensions for Cell Broadband Engine Architecture), iar despre libspe2.h in [3.4] (IBM SPE Runtime Management Library). SDK 3.0 defineste si un nou set de functii pentru DMA in cbe_mfc.h, care nu sunt foarte clar descrise, dar sunt considerate mai performante.

Atat comenzile get, cat si cele put au mai multe forme, prin adaugarea de sufixe (e.g. mfc_get, spe_mfcio_getf, mfc_putlf etc.). Sufixele au urmatoarele semnificatii:

Atentie! Nu toate combinatiile de sufixe formeaza instructiuni valide. Pentru o lista completa a comenzilor consultati [2] , paginile 113-115.

Sa luam, spre exemplu, o instructiune de SPU si una pentru PPU (celelalte se trateaza in mod asemanator):

(void) mfc_get(volatile void *ls, uint64_t ea, uint32_t size, uint32_t tag, uint32_t tid, uint32_t rid)

implementare:

spu_mfcdma64(ls, mfc_ea2h(ea), mfc_ea2l(ea), size, tag, ( (tid«24)|(rid«16)|MFC_GET_CMD) )

respectiv:

int spe_mfcio_put (spe_context_ptr_t spe, unsigned int lsa, void *ea, unsigned int size, unsigned int tag, unsigned int tid, unsigned int rid)

Din punct de vedere al parametrilor este important de remarcat ca locatia din spatiu principal de stocare este data de parametrul ea (effective address), iar cea din memoria locala de parametrul ls/lsa (local store address). Intre ceilalti parametrii mai recunoastem size (dimensiunea datelor transmise) si tag (care reprezinta tag group id-ul ales). Functia pentru PPU are in plus, evident, parametrul spe (prin care se alege SPU cu care se comunica).

In mod explicit am amintit doar de o parte din functiile MFC disponibile pentru lucrul cu DMA. Acestea sunt numeroase si apar clasificate in:

  • tag manager (e.g. mfc_tag_reserve, mfc_tag_release)
  • comenzi DMA (e.g. mfc_put, mfc_get)
  • comenzi pentru liste DMA (e.g. mfc_putl, mfc_getl)
  • operatii atomice (e.g. mfc_getllar, mfc_putllc)
  • comenzi de sincronizare (e.g. mfc_barrier)
  • comenzi pentru statusul DMA (e.g. mfc_stat_cmd_queue, mfc_read_tag_status) etc.

Pentru o referinta completa recomandam [2] , sectiunea 4: Programming Support for MFC Input and Output.


Reguli pentru transferurile DMA

Daca dimensiunea transferului > = 16 bytes
  1. Size must be multiple of 16 bytes
  2. Source and destination addresses must be 16-byte aligned (128-byte for best performance)
  3. Size must be < = 16384 (=2^14)

Daca dimensiunea transferului: 1, 2, 4, 8 bytes

  1. Source and destination addresses must be a multiple of the transfer size
  2. Source and destination addresses must have the same low 4 bits. For example, you can transfer 2 bytes from address 0x123406 to address 0x4506, but not to address 0x4500, 0x4502 etc.

Sfaturi pentru performanta

SPE-urile folosesc transfer DMA asincron pentru a ascunde latenta memoriei si overhead-ul transferului, ocupandu-se in paralel de calcule (mai multe pe aceasta tema in laboratorul urmator).

Performanta unui transfer DMA (mai mare de 128 de octeti) este maxima atunci cand adresele sursa si destinatie sunt aliniate la dimensiunea liniei de cache.

Sunt de preferat transferurile initiate de SPE celor initiate de PPE, deoarece: sunt de 8 ori mai multe SPE-uri, intr-un MFC coada de comenzi pentru SPU este de doua ori mai mare decat cea pentru PPE si celelalte SPE-uri (16 intrari fata de 8), transferurile initiate de 'consumatori' sunt mai usor de sincronizat etc. [3.2]

Pentru a ne face o idee cu privire la costul unui transfer: un thread ruland pe SPU poate face o cerere DMA in 10 ciclii de ceas (in conditii de incarcare optima). Pentru fiecare dintre cei cinci parametrii ai unei comenzi cum ar fi mfc_get se scriu date pe un canal SPU (latenta instructiunilor pentru canale SPU este de 2 ciclii de ceas). Latenta de la emiterea comenzii de catre DMA si pana la ajungerea acesteia in EIB este de aproximativ 30 de ciclii (daca se cere aducerea unui element al unei liste se pot adauga alti 20 de ciclii). [1] Faza de comanda a transferului necesita o verificare a elementelor de pe magistrala si are nevoie de circa 50 de ciclii magistrala (100 de ciclii SPU). Pentru operatii get, se mai adauga latenta de aducere a datelor din memoria off-chip la controller-ul de memorie, apoi pe magistrala la SPE, dupa care se scriu in Local Store. Pentru operatii put, latenta DMA include doar transmiterea datelor pana la controller-ul de memorie, fara transferul acestora pe memoria off-chip. [1]


Pentru exemple practice urmariti tutorialele de pe pagina DMA 101


Notificare prin semnale

Notificarea prin semnale este un mecanism foarte usor de folosit, care permite PPU si SPU sa trimita semnale unui (alt) SPE folosind registrii de 32 de biti.

Ca si in cazul mailbox, atunci cand sursa este un SPU, el poate poate trimite semnale altor SPE. Atentie la aceasta distinctie, este vorba despre SPU local, adica cel aflat pe acelasi SPE cu registrul de notificare in discutie.


Accesarea registrilor pentru notificarea cu semnale.

Fiecare SPU are doi registrii identici pentru notificarea cu semnale. Acestia, locali unui SPU, sunt folositi exclusiv pentru primirea de semnale de la alte elemente (PPU, SPE).

Programele pot accesa acesti registri astfel:

  • SPU local citeste notificarea prin canale proprii
  • PPU trimite semnal unui SPU scriind pe interfata MMIO corespunzatoare.
  • SPU trimite semnal unui alt SPE folosind comenzi de semnalizare (sndsig, sndsigf, sndsigb) care practic se mapeaza la comenzi DMA (e.g. put)

La citirea registrului de catre SPU local, registrul se reseteaza.


Moduri: many-to-one si one-to-one

Scrierile multiple intr-un registru de notificare pot fi gestionate in unul din doua moduri: 2

  • OR mode (many-to-one): MFC aduna mai multe semnale prin operatie logica OR
  • Overwrite mode (one-to-one): orice actiune de scriere produce pierderea informatiei vechi

Configurarea modului de lucru poate fi precizata de PPU la crearea contextului SPE corespunzator, setand un flag (e.g. SPE_CFG_SIGNOTIFY1_OR) pe functia spe_context_create (pe care am mai vazut-o in capitolele precedente).


Acces blocant vs. non-blocant

Accesul la registrii de notificare a semnalelor se face: 2

  • pentru PPU: non-blocant (vezi si modul de scriere mai sus)
  • pentru SPU care scrie: similar cu comanda DMA put (se blocheaza doar daca coada MFC este plina)
  • pentru SPU care citeste: blocant pana la aparitia unui eveniment.


Notificare prin semnale la nivel de cod

Mecanismul de notificare prin semnale poate fi utilizat foarte usor cu ajutorul functiilor MFC: 2

  • SPU local poate citi registrii sai folosind spu_read_signal* si starea lor cu spu_stat_signal* din spu_mfcio.h
  • PPU poate trimite semnale unui SPU cu spe_signal_write din libspe2.h
  • alte SPU pot trimite semnale unui SPU cu mfc_sndsig* din spu_mfcio.h
    • pentru a folosi aceasta abordare, in prealabil: PPU mapeaza zona de semnale in spatiul principal de stocare cu spe_ps_area_get, setand flagul SPE_SIG_NOTIFY_x_AREA, iar PPE transmite SPU sursa adresa de baza a zonei de semnale.

Asteriscul denota optiunile 'f' (fence), 'b' (barrier) sau nimic.

Mai multe informatii despre spu_mfcio.h gasiti in 3.3 (IBM C/C++ Language Extensions for Cell Broadband Engine Architecture) capitolul SPU Signal Notification, iar despre libspe2.h in 3.4 (IBM SPE Runtime Management Library) capitolul SPE SPU signal notification functions.


Activitate practica - folosirea mailbox si DMA

  1. Parcurgeti exemplele de la Mailbox Hands-On
    1. Transformati ultimul exemplu in asa fel incat numarul SPU sa le fie comunicat prin mailbox
  2. Parcurgeti exemplele de la DMA 101
    1. Modificati programele pentru a folosi toate SPU
      1. Pentru transferul initiat de SPU faceti ca toate SPU-urile sa completeze 'formularul'
      2. Pentru transferul initiat de PPU cereti un 'eseu' de la toate SPU-urile
  3. Combinati programul de transfer DMA initiat de SPU cu cel de mailbox de la PPU la SPU, in asa fel incat: PPU trimite SPE-urilor id-urile prin mailbox, iar fiecare SPU modifica stringul luat de la PPU personalizat in functie de acest id.
  4. Optional: PPU joaca cu SPU-urile sale un joc de 'Ghiceste numarul': PPU alege un numar intre 0 si 1000000, iar SPU incearca sa il ghiceasca intreband PPU daca numarul ales de ele este corect; PPU raspunde doar cu mai mic, mai mare, sau Ai ghicit! moment in care jocul se termina
    1. pentru varianta simpla: fiecare SPU este pe cont propriu; comunicarea se face doar prin mailbox
    2. pentru varianta complicata: SPU colaboreaza; pe langa interogarea PPU prin mailbox, ele isi impart cunostintele prin transfer DMA in doua variabile din main storage, care retin limita minima si limita maxima descoperita pana acum

Glosar

  • MFC (memory flow controller): asigura conectarea SPU cu EIB si ofera suport pentru transferuri DMA intre spatiul principal de stocare si memoria locala a SPU asociat; fiecare SPU are asociat un MFC care este privit ca un co-procesor specializat 3.2
  • MMIO (memory mapped I/O registers): registrii folositi de PPE si alte dispozitive (inclusiv alte SPE-uri) pentru a comunica cu MFC-ul asociat unui SPU [3.1]
  • Canal SPU: mecanism al SPU ce consta din registrii unidirectionali, cozi si logica aferenta, folosit pentru comunicatia cu propriul MFC [3.1]
  • MFC proxy command queue vs. MFC SPU command queue: cozi de comenzi mentinute de fiecare MFC in parte (16 intrari pentru MFC SPU si 8 intrari pentru MFC proxy) in care se stocheaza comenzile pana la procesare: in MFC SPU command queue se stocheaza comenzi venite de la SPU asociat (cu exceptia comenzilor imediate), iar in MFC proxy command queue se stocheaza comenzi venite de la PPE sau alte dispozitive. 3.2
  • DMA (direct memory access): functionalitate oferita de MFC pentru transferul datelor intre memoria locala a SPU asociat si spatiul principal de stocare


Linkuri utile

  1. Koranne, S. - “Practical Computing on the Cell Broadband Engine”, Springer, 2009, pp. 49-71
  2. Arevalo, A. et al. - “Programming the Cell Broadband Engine Examples and Best Practices”, IBM Redbooks, 2008, pp. 188-198
asc/lab8/index.txt · Last modified: 2013/02/07 12:41 (external edit)
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0