Xilinx FPGA programavimas ir Vivado dizaino srautas paaiškinti

Xilinx FPGA dizainas reikalauja aiškaus srauto, kuris sujungia HDL rašymą, simuliaciją, apribojimus, sintezę, įgyvendinimą, laikymo analizę ir aparatūros testavimą. Šis straipsnis paaiškina, kaip išmokti FPGA kūrimą naudojant Vivado, rašyti sintezuojamą Verilog, valdyti laikrodžius ir atkūrimus, derinti laikymo problemas ir patvirtinti dizainus realiose Xilinx plokštėse.

Katalogas

Xilinx FPGA pamokų tyrinėjimas

Dirbti su FPGA iš pradžių gali atrodyti psichologiškai sunkiau nei su programine įranga, iš dalies dėl to, kad tikslas nėra vykdyti instrukcijas, o apibūdinti tokias aparatinės įrangos struktūras, kurios veikia vienu metu. Galų gale galvojate apie konkurenciją, laikrodžio taisykles, atkūrimo elgseną ir ar laikymo ataskaitos sutampa su tuo, ką manėte, kad sukūrėte. Kai žmonės anksti pasidaro nusivylę, dažnai tai nėra dėl to, kad trūksta pastangų, o todėl, kad per daug judančių dalių keičiasi tarp bandymų, o nesėkmės priežastis tampa erzinančiai miglota.

Nuolatinis žingsnis į priekį yra pakartoti tą patį srautą, kol jis tampa pakankamai pažįstamas, kad klaidos išsiskirtų. Laikykite vieną gerai palaikomą Xilinx plokštę ant savo stalo, pradėkite nuo mažo HDL dizaino, simuliuokite jį, kol bangosformos taps prasmingos, vykdykite sintezę ir įgyvendinimą Vivado, programuokite įrenginį, o tada patvirtinkite elgseną realiuose kontaktuose. Nors šis procesas gali atrodyti pasikartojantis, jis padeda sumažinti neapibrėžtumą dėl to, ar problemą sukelia dizaino kodas, apribojimai ar plokštės konfigūracija, padarydamas derinimą efektyvesnį.

Kasdieniniame mokymesi, staigus kreivės dalis paprastai susikaupia aplink keletą įgūdžių, kurie stiprina vienas kitą: disciplinuotas Vivado srauto naudojimas, sintezuojamo Verilog rašymas, kuris atitinka tai, kaip tikitės, ir inebevitinių spragų tarp simuliacijos ir fizinės plokštės derinimas su metodu, kuriuo pasitikite. Jei kiekvieną kūrimo etapą traktuosite kaip kontroliuojamą eksperimentą, keisite vieną kintamąjį, stebėsite poveikį ir užrašysite, ką matėte, pastebėsite, kad praleidžiate mažiau laiko spėliodami ir daugiau laiko formuodami patikimus instinktus.

Naudokite Vivado projekto srautą taip, kad jis išliktų stabilus laikui bėgant

Vivado elgiasi ne kaip paprastas kompiliavimo mygtukas, o kaip vamzdyno sistema, kuri paverčia RTL į įdėtą ir nukreiptą dizainą, kuris turi egzistuoti plokštės elektros ir laikymo tikrovėse. Daugelis pradedančiųjų atranda, kartais sunkiai, kad daugumoje teisingumo yra už HDL ribų: apribojimai, laikrodžio apibrėžimai, I/O standartai ir įrankių nustatymai gali tyliai nuspręsti, ar aparatinė įranga veikia taip, kaip pažadėjo simuliacija.

Švarus srautas prasideda nuo projekto nustatymo, kuris yra kuklus ir kartojamas, todėl galite pasakyti, kada tikrai patobulinote dizainą, o kada atsitiktinai pakeitėte aplinką.

Pasirinkite vieną palaikomą plokštę ir laikykitės jos pakankamai ilgai, kad sukurtumėte intuiciją, kurią galėsite vėl naudoti. Plokštės, turinčios tvirtą dokumentaciją ir nuorodų dizainus, paprastai sumažina fono nerimą, nes galite patikrinti savo kontaktus, laikrodžius ir energijos prielaidas, neieškodami neoficialių forumų pranešimų.

Pradėkite nuo viršutinio modulio, kuris greitai generuoja matomą rezultatą. Tas tiesioginis atsiliepimas padeda jums patvirtinti, kad laikrodis veikia, kontaktai yra teisingai sujungti, o bitų srautai generuojami taip, kaip manote, kad jie yra.

Stebimų viršutinio lygio elgsenos pavyzdžiai:

• Mirksi LED

• UART atgarsis

• Skaitiklis vairuojantis GPIO

Praktinis įprotis yra standartizuoti mažą viršutinio lygio šabloną anksti. Pavyzdžiui, laikykite vieną laikrodžio įvestį, vieną atstatymo metodą, kurį suprantate, ir mažą, nuoseklų GPIO rinkinį. Kai atrama išlieka ta pati nuo projekto iki projekto, galite sutelkti dėmesį į naują logiką, o ne vėl iš naujo nagrinėti pagrindus kiekvieną kartą, kas gali jaustis nuobodžiai ir staigiai suklysta.

Apribojimai yra esminė FPGA dizaino dalis, o ne galutinio koregavimo etapas. Daugelis ankstyvųjų aparatinės įrangos problemų atsiranda net tada, kai RTL dizainas yra teisingas, nes laikrodžio apribojimai trūksta arba yra neteisingi, kontaktai priskiriami neteisingai, arba I/O standartai neatitinka realaus plokštės reikalavimų.

Konkretus darbo procesas, kuris išlaiko jūsų sąžiningumą, yra apibrėžti laikrodžius XDC, žemėlapiuoti prievadus naudodami tiekėjo pagrindinį XDC kaip nuorodą, o tada patikrinti I/O standartus pagal plokštės schemą. Tas procesas gali pasirodyti biurokratiškas iš pradžių, tačiau paprastai keičia neaiškų įtarimą į patikrinamus faktus.

Laiko uždarymas taip pat nėra skirtas tik greitiems dizainams. Net logika, kuri atrodo lėta popieriuje, gali elgtis blogai, jei įrankis reikalauja netinkamų laikrodžio santykių arba jei asinchroniniai signalai yra tvarkomi atsitiktinai. Patogiai skaityti laiko ataskaitas anksti gali sumažinti tą nerimą keliantį jausmą „tikiuosi, kad viskas gerai“, kai dizainai didėja.

Vivado nuolat sako, ką jis mano apie jūsų dizainą; skaudžiausia dalis yra ta, kad lengva praleisti įspėjimus ir tada praleisti valandas, trukdant problemą, kuri jau buvo aprašyta konsolėje. Laikui bėgant, greičiau judantys žmonės dažnai būna tie, kurie sukuria ramų įprotį patikrinti ataskaitas po kiekvieno važiavimo, net kai tikisi, kad viskas gerai.

Po kiekvieno sintezės/įgyvendinimo proceso laikykite šias ataskaitų kategorijas kartu savo kontrolinio sąrašo eilutėje:

• Laiko būsena ir kritiniai keliai

• Išteklių naudojimas (LUT/FF/BRAM/DSP) prieš lūkesčius

• Išvesties rezultatai (RAM, DSP blokams ir kitiems numatytiems struktūroms)

Kai įspėjimas buvo nuolat nuo pirmo statybos, jis dažnai išlieka keisčiausiuose gedimuose vėliau. Produktyvi pozicija yra manyti, kad įspėjimai nusipelno dėmesio, kol galite paaiškinti paprastais inžineriniais terminais, kodėl jie yra nekenksmingi jūsų specifiniam dizainui.

Rašykite sintetinamą Verilog, kuris švariai atitinka FPGA aparatinę įrangą

HDL darbas yra arčiau grandinės dizaino nei programų kūrimo, o tas poslinkis gali būti emocionaliai šokiruojantis: galite rašyti galiojantį Verilog, kuris gražiai simuliuoja, tačiau sintezės rezultatas gali būti lėtesnis, didesnis arba tiesiog skirtingas nei jūs įsivaizdavote. Tikslas yra apibūdinti struktūras, kurias FPGA gali įgyvendinti prognozuojamai: flip-flop, LUT logiką, BRAM ir DSP blokus, kad elgesys ir laikas atitiktų jūsų ketinimus.

Kai žemėlapis yra prognozuojamas, šalinimas jaučiasi mažiau kaip ginčijimasis su įrankiu ir daugiau kaip dizaino tobulinimas.

Patogus bazinis lygis daugeliui pradedančiųjų yra vienas laikrodžio domenas su paprasta sinchronine logika. Naudokite laikrodžiais valdomas „always“ blokus sekvenciniam būsenos apdorojimui ir nuolatinius priskyrimus (arba tinkamai parašytus kombinacinius blokus) kombinaciniams takams. „Laikrodžio“ tipo logikos kūrimas tinkle gali veikti nišiniais atvejais, tačiau paprastai sukelia laikrodžio domeno riziką, nebent jūs jau suprantate laikrodžio užrakto, maršruto ir laiko pasekmes.

Atstatymo elgsena yra kita vieta, kur mažos pasirinkimo galimybės gali sukurti staigiai nesuderinamus plokštės rezultatus. Asinchroniniai atstatymai gali būti naudingi, tačiau jie taip pat gali sukelti nutraukimo pavojus arba jautrumą plokštės energijos pateikimo skirtumams. Daugelyje FPGA dizainų naudojami visiškai sinchroniniai atstatymai arba asinchroniniai teigimai su sinchroniniu atleidimu, nes šie metodai padeda sumažinti nesuderinamą paleidimo elgesį paleidimo testavimo metu.

FPGA logika natūraliai linksta į vamzdynus ir lygiagrečias struktūras. Dažna pradedančiųjų nusivylimas yra tikimasi programinės įrangos tipo žingsnis po žingsnio vykdymo, o tada jaučiatės painioje, kai viskas vyksta iš karto. Naudingesnis požiūris yra nuspręsti, kas jums svarbu konkrečiam blokui, o tada aiškiai kurti tam tikrą rezultatą.

Vienos linijos dizaino požiūris efektyvumui ir žemėlapiavimui:

• Pralaidumas (prekės per laikrodį)

• Latencija (ciklai nuo įvesties iki išvesties)

• Ištekliaus žemėlapio prioritetas (LUT vs BRAM vs DSP)

Pavyzdžiui, daugybės kaupimas gali švariai išvesti DSP gabalus, tačiau mažos kodavimo stiliaus pokyčiai gali pakreipti įrankį link LUT pagrindu sukurto aritmetikos. Kai naudojimas nustebina, dažnai verta pristabdyti ir užduoti šiek tiek nepatogų klausimą: ar tikrai apibūdinote hardware struktūrą, kurią norėjote, ar apibūdinote kažką funkciškai lygiavertį, kas kainuoja daugiau išteklių?

Simuliacija mielai priims konstrukcijas, kurių reali aparatinė įranga negali įgyvendinti taip, kaip galite įsivaizduoti. Išlaikydami savo sintetinamą ribą aiškiai sumažinkite klaidingą pasitikėjimą ir padarykite simuliacijos rezultatus labiau perkeliamus į plokštę.

Bendros schemos, kurias verta sugrupuoti vienoje linijoje kaip greitą priminimą:

• Venkite vėlavimų (#) sintetinamose logikose

• Nesiremkite inicializacija, nebent patvirtinote įrenginio/įrankio elgesį

• Stebėkite nepageidaujamus užraktus iš nepilnų kombinacinių priskyrimų

• Naudokite tinkamus sinchronizatorius laikrodžio domenuose

Įprotis, kuris linkęs atsipirkti, yra rašyti mažas savikontroliuojančias testavimo platformas, kurios patvirtina prielaidas, kurioms esate emociškai linkę lengvabūdiškai priimti: atstatymo elgesys, skaitiklio apvažiavimas, rankų paspaudimo protokolai ir kampinės sąlygos. Augant projektams, šie testai tampa labiau ne papildomai darbą, o daugiau dalykas, kuris neleidžia jums nuolat abejoti viskuo.

Sistematiškai derinkite su simuliacija ir On-Chip matomumu (ILA)

Net ir puiki simuliacija negarantuoja teisingo plokštės elgesio. Tikrasis aparatas sukelia laikrodžio dreifą, I/O atidėjimus, nežinomas pradines būsenas ir asinchroninius įvestis, kurie nepadoriai neatitinka jūsų laikrodžio krašto. Greičiausi derintojai paprastai nėra tie, kurie daro atsitiktinius redagavimus, jie yra tie, kurie siaurina problemą struktūrizuota observacija ir gali paaiškinti, kokios įrodymų pasikeitė jų nuomonę.

Stiprus testavimo platforma tikrina elgesį per daugybę ciklų ir vengia nemalonių scenarijų. Jei modeliuojate realistiškus stimulusus, simuliacija tampa vieta, kurioje gaujate pasitikėjimą, o ne tik vieta, kur stebite signalą keistis ir tikitės, kad tai kažką reiškia.

Realistiški stimulai, kurie linkę atskleisti trapią logiką:

• Mygtuko dreifas

• UART struktūros klaidos

• Atgalinė slėgio įtampa srautiniuose sąsajuose

• Atstatymo sekos su nepatogiu laiko tarpu

Taip pat naudinga atskirti klaidas į dvi dėžes, kad nepavyktų persekioti netinkamo tipo taisymą:

• Funkcinės klaidos: RTL logika yra neteisinga

• Integravimo klaidos: RTL yra gerai, bet laikrodžiai/atstatymai/kontraintai/I/O prielaidos yra neteisingos

Simuliacija puikiai atskleidžia funkcinės klaidas; plokštės testavimas linkęs atskleisti integravimo klaidas, kuriomis nenorėjote tikėti, kad yra įmanomos.

Kai aparatūros elgesys nesutampa su jūsų testavimo platforma, Integruotas logikos analizatorius (ILA) dažnai yra tiesiausias būdas pakeisti spekuliacijas stebėjimu, kurį galite studijuoti. Iškaskite signalus, kurie atspindi sprendimus ir ribas viduje dizaino, tada užfiksuokite momentą, kai dalykai išsiskiria, ir palyginkite su numatytu simuliacijos bangos formu.

Signalai, kurie linkę būti didelės vertės zondai:

• FSM būsenų kodavimai

• galiojantys/paruošti rankų paspaudimai

• FIFO pilni/tušti ženklai

• atstatymo sinchronizatorių išėjimai

Praktinis darbo eiga yra pradėti su mažiau zondų ir platesniu užfiksavimo langu. Kai sužinote, kur gyvena nesėkmė, galite stiprinti triggrą ir pridėti detalių. Per daug įrankių gali sumažinti laiko rezervą ir sudėtingėti statybą, todėl dažnai sveikiau laikyti ILA inserciją kaip orientacinį matavimo žingsnį, o ne kažką, ką turite tik tuo atveju.

Kai kurios iš labiausiai edukacinių nesėkmių atsiranda, kai simuliacija atrodo nepriekaištingai, o plokštė yra nestabili. Tas neatitikimas gali būti demotyvuojantis, tačiau tai taip pat yra vieta, kur FPGA intuicija aštrėja, nes taisymas paprastai yra laikymų, apribojimų ar signalo higienos klausimas, o ne algoritmo.

Dažni simuliacijos/plokštės divergencijos priežastys:

• Trūksta arba neteisingi laikrodžio apribojimai

• Metastabilumas iš nesinchronizuotų įvesties

• Atstatymo paleidimo laiko variacija visame lustyje

• CDC problemos tarp kelių laikrodžių domenuose

• Pradinės sąlygos skirtumai

Perspektyva, kuri linkusi pagreitinti mokymąsi, yra laikyti laikymą ir stebimumą kaip savybes, kurias sąmoningai kuriate projekte. Kai jūsų maži projektai aiškiai apibrėžia laikrodžius, apriboja I/O, sinchronizuoja perėjimus ir atskleidžia vidinius signalus matavimui, praleidžiate mažiau laiko tikėdamiesi, kad tai veikia, ir daugiau laiko darydami kontroliuojamus, paaiškinamus patobulinimus. Tokia mąstysena natūraliai skalė nuo mirksinčios LED iki didesnių vamzdynų, sąsajų ir įtaisų toje pačioje įrangoje.

Xilinx (AMD) vs. Altera (Intel) FPG

Xilinx (AMD) ir Intel (Altera) abu tiekiami FPGA šeimas, kurios atrodo palyginamos popieriuje, ir lengva jaustis pasitikėti greitu duomenų lapų peržiūra. Nuotaika paprastai keičiasi vėliau, kai kasdienių inžinerijos realybė pradeda leisti tempą: įrankių elgesys jūsų tiksliame įrenginyje ir greičio klasėje, ar IP, kurį manote, kad galite naudoti, iš tiesų yra licencijuojamas jūsų organizacijoje, ar nuorodos dizainas tikrai atitinka jūsų laikrodžius ir atstatymus, ir ar laiko uždarymas išlieka stabilus, kai dizainas tampa gamybiniu.

Pasirinkimo procesas geriau laikosi, kai laikote FPGA kaip pristatymo sistemą, prietaisas + įrankiai + IP + plokštės + dokumentacija + ilgalaikė palaikymo, nes čia komandos arba įgauna pagreitį (ir miego), arba kaupia tylų tvarkaraščio nerimą.

Funkcija	Xilinx (AMD)	Intel (Altera)
Rinkos pozicija	Istoriškai rinkos lyderis, žinomas dėl plataus produktų portfelio ir pirmasis atvykęs į rinką su naujomis technologijomis.	Stiprus konkurentas, ypač galingas duomenų centrų ir tinklų taikymuose, pasinaudojantis Intel gamybos gebėjimais.
Pagrindinė architektūra	Logika daugiausia remiasi 6 įėjimų ieškos lentelėmis (LUT), siūlančiomis didelį granuliškumą ir lankstumą.	Naudoja pritaikomus logikos modulius (ALM), kurie yra sudėtingesni ir gali būti konfigūruojami kaip didesnės LUT, potencialiai gerinant logikos tankį tam tikriems dizainams.
Programinės įrangos rinkinys	Vivado dizaino rinkinys ir Vitis Unified Software Platform. Dažnai giriamas už patogią naudotojo sąsają patyrusiems kūrėjams.	Quartus Prime dizaino rinkinys. Kai kurie vartotojai mano, kad jo GUI yra labiau intuityvus pradedantiesiems, ir jis žinomas dėl greitesnių kompiliavimo laikų tam tikrose situacijose.
Aukštos klasės šeimos	Versal ACAPs (Pritaikomos kompiuterių pagreitimo platformos), jungiančios skalarinius, pritaikomus ir intelektualius variklius.	Agilex FPGA, žinomi dėl didelio našumo ir energijos efektyvumo, su kai kuriais etalonais, rodančiais našumo ir energijos santykio privalumą.
Ekosistemos fokusas	Tvirtas dėmesys procesoriaus ir FPGA integravimui, kaip matyti Zynq šeimoje. Populiarios programų kūrimui.	Gerai tinkamos sistemų-on-chip dizainams ir pramoninėms taikomoms, turinčioms stiprų IP portfelį tinklams ir RF.

Apibrėžkite pasirinkimą naudodami tikrinamus apribojimus, o ne prekės ženklų lūkesčius

Pradėkite nuo reikalavimų, kuriuos galite ištestuoti anksti, o ne nuo ankstesnių projektų įspūdžių. Tikslas - sumažinti „nustebimus dešimtąją savaitę“, nes būtent čia paprastai kaupiasi nusivylimas ir perdirbimas.

Apribojimų kontrolinis sąrašas:

• Logikos išteklių: LUT/ALM, registrai, maršrutizavimo prieinamumas ir laukiamas naudojimo lubas

• DSP išteklių: blokų skaičius, tikslumo režimai, išankstiniai priedai, kaskadiniai/topologiniai pasirinkimai ir matematikos branduolių žemėlapio elgsena

• On-chip atmintis: BRAM/URAM (ar M20K atitikmenys), bendra talpa, prievadų režimai, pralaidumas per laikrodį ir konkurencijos modeliai

• Didelio greičio I/O: SERDES klasė, takelių skaičius, maksimalus linijos greitis, nuorodos laikrodžio parinktys ir protokolo palaikymas, susijęs su jūsų naudojimo atveju

• Išorinė atmintis: DDR3/DDR4/LPDDR variantai, valdiklio brandumas, kalibravimo elgsena ir lentos lygio SI maržos prielaidos

• Latencija ir deterministinis veikimas: galutinis tikslas, biudžetas per etapus, svyravimo tolerancija ir CDC strategija (įskaitant tai, kaip atstatymai kerta domenus)

• Energijos/šilumos spektras: blogiausio atvejo perjungimų įvertinimai, keitiklio energijos režimai, šilumos šalinimo prielaidos ir aplinkos diapazonas

Realiuose FPGA projektuose dažnai parodoma, kad tilpimas į prietaisą negarantuoja patikimos didelio greičio veiklos. Dizainai, kurie atrodo priimtini 70–80% naudojimo, gali tapti nestabilūs po to, kai pridedami derinimo logika, CDC apsauga, FIFO, klaidų tvarkymas ir laikymo marža, reikalinga praktiškai veiklai.

Jei jūsų komanda kada nors prarado savaitę dėl maršrutizavimo spūstyse, lengva suprasti, kodėl norima pereiti prie didesnio prietaiso. Kainų keitimo dažniausiai nėra linijinis: šiek tiek didesnis komponentas gali suteikti ramų laiką, mažiau įrankių iteracijų ir mažiau vėlai vakaro perstatymų.

Traktuokite įrankių srautą kaip reikalavimą, kurio negalite išvengti

Įrankių srautas dažnai būna paslėptas skirtumas tarp tvirto plano ir nuolat slenkančio plano. Žmonės dažnai nesupranta, kiek emocinės energijos sudeginama dėl lėtų ar nenuspėjamų iteracijų, ypač kai statymas trunka valandas, o nesėkmės būdas yra neaiškus.

Įrankių srauto vertinimo kontrolinis sąrašas:

• Iteracijos greitis: sintezė + vieta/maršrutas + bitstream laikas jūsų CI aparatinėje įrangoje, o ne tiekėjo demonstracinėje mašinoje

• Laiko uždarymo elgsena: QoR tendencijos, stabilumas per sėklas ir jautrumas nedideliems apribojimų pokyčiams

• Apribojimai ir stebimumas: SDC/XDC aiškumas, laikrodžių modeliavimas, klaidingų kelių/multiciklinis tvarkymas ir kaip debuguoti pažeidimus

• Derinimo instrumentacijos: logikos analizatoriaus įterpimo srautas, zondų lankstumas, trigerio gylis ir kaip dažnai turite kompiliuoti, kad stebėtumėte signalus

• Aplinka: palaikomos operacinės sistemos versijos, be galvos statymai, licencijavimo trintis ir kaip gerai tai atitinka jūsų komandos darbo eigą

• CI/VCS draugiškumas: reprodukuojamumas, deterministiniai išvestiniai rezultatai (kiek įrankiai leidžia), skriptavimo galimybės ir atnaujinimo skausmas

Prieš įsipareigodami, atlikite laiko uždarymo bandymą su kuo nors reprezentatyviu (ne žaislu). Įtraukite savo realius laikrodžius, bent vieną išorinės atminties sąsają ir bent vieną didelio greičio I/O bloką. Sekite:

• Laikrodžio kompiliavimo laikas už iteraciją

• Įtempimo stabilumas per kelias sėklas

• Kaip greitai inžinierius gali diagnozuoti pirmas tris laiko problemas be gentinės žinių

Tas eksperimentas linkęs sukurti aiškumą, kurio funkcijų kontroliniai sąrašai nesukuria. Jis taip pat atskleidžia, ar jūsų komanda jausis stabiliai, ar nuolat bus įsitempusi integracijos etape.

IP prieinamumas ir licencijavimas: kur grafikai paprastai sutrumpėja

Net kai žali FPGA ištekliai atrodo panašūs, grafikai dažnai priklauso nuo IP realijų. Būtent čia komandos gali jaustis apakintos: branduolys egzistuoja, tačiau licencijos modelis, integravimo pastangos ar dokumentacijos kokybė paverčia tai lėtu procesu.

IP ir licencijavimo kontrolinis sąrašas:

• Protokolo krūvos: PCIe, Ethernet MAC/PCS, JESD204, DDR valdikliai ir bet kokie nišiniai sąsajos, kurių jums reikia

• Licencijos sąlygos: kamieno užrakinta vs keičiamoji, papildomos funkcijos, statybos serverio/CI pasekmės ir bet kokios vykdymo ar diegimo apribojimų

• Nuorodų dizainai: eilučių skaičius, laikrodžių planas, iš naujo nustatyti seką, DMA architektūra ir ar jis atitinka jūsų sistemos ribas

• Paramos horizontas: ilgalaikės priežiūros lūkesčiai, pataisų dažnis ir kaip problemos yra vertinamos

Subtilus punktas, kurį komandos išmoksta sunkiai: prieinamas IP nėra tas pats, kas drop-in IP. Laboratorijos demonstracijos gali paslėpti integravimo darbą, reikalingą norint pasiekti jūsų delsimo, buferio ir laikrodžių tikslus. Išankstinis planavimas patikrinimui ir pirmenybė IP su tiesiogine dokumentacija ir žinomais gerais pavyzdžiais dažnai sumažina streso lygį vėliau, net jei pradinė vertinimo dalis atrodo lėtesnė.

Valdybos ekosistema, pristatymo rizika ir žinomų-gerų platformų patogumas

FPGA pasirinkimas yra susijęs su valdybos realybe. Pristatymo metu laikas paprastai dingsta į platformos neaiškumą, o ne RTL: viena praleista laikrodžio sąlyga, resetavimo priklausomybė, kuri nebuvo akivaizdi, arba perdavimo kanalas, kuris yra marginalus tik tam tikroje temperatūroje.

Valdybos ir platformos kontrolinis sąrašas

• Vertinimo plokštės ir nuorodų platformos: prieinamumas, revizijų stabilumas ir ar dizainas plačiai naudojamas lauke

• Energijos tiekimo rekomendacijos: PDN tikslai, atskyrimo metodas, bėgių sekimo lūkesčiai ir tolerancijos pakopų prielaidos

• Didelio greičio išdėstymo nuorodos: perdavimo maršruto rekomendacijos, atitikties pastabos ir patikrinti krūviai

• Klaidos prieiga: JTAG stabilumas, paleidimo/config režimai, konfigūravimo šviesos palaikymas ir matomumas bėgiams/laikrodžiams

• Paramos reagavimas: tiekėjų kanalai, bendruomenės signalų ir triukšmo santykis, ir atsakymo laikas į įrankių/IP problemas

Naudojant plačiai priimtą platformą su įrodytais nuorodų dizainais, sistemos pristatymas gali tapti struktūrizuotesnis ir prognozuojamesnis. Šis metodas padeda trikdžių sprendimams pereiti nuo plačios neaiškumo prie žingsnis po žingsnio išmatuojamo patikrinimo, gerinant kūrimo efektyvumą.

Laiko uždarymas

Laiko uždarymas yra vieta, kur tiekėjų skirtumai tampa apčiuopiami, ypač kai naudojimas kyla ir daugybė laikrodžių domenų sąveikauja. Šiame etape dizaino pažanga gali arba išlikti stabili ir prognozuojama, arba tapti sudėtinga, kai nedideli pakeitimai sukelia didelius laikų svyravimus.

• Perkrovos mastas: kaip maršruto spaudimas didėja, kai naudojimas kyla, ir kur jis pradeda šokti

• Fmax prognozuojamumas: kaip dažnai vidutiniai apribojimai priveda prie artimumo, priešingai reikalaujant sunkiųjų rankinių reguliavimų

• Ataskaitų kokybė: ar laikrodžių ataskaitos nurodo įgyvendinamus pataisymus, o ne tik ilgas pažeidimų sąrašas

• Patvarumas: elgesys per PVT variaciją ir per įgyvendinimo sėklas

Paprastai saugiau manyti, kad uždarymo pastangos auga nelinijiniu būdu su tankiu. Praėjus tam tikram slenksčiui, nedidelis RTL pasikeitimas gali apversti laisvumą nuo sveiko iki trapio. Architektūrinis laisvumas, vamzdynai, selektyvus grindų planavimas ir prietaiso pasirinkimas su erdve kvėpuoti dažnai viršija heroišką apribojimų reguliavimą, kurio niekas nenori palaikyti.

Palyginkite tikslią dalį

Specifikacijos keičiasi per kartas ir vienoje šeimoje. Dvi dalys su panašiais pavadinimais gali elgtis pakankamai skirtingai, kad sutrikdytų planą, ypač kai į pakavimą, greičio klasę ir įrankių brandumą įtraukiate vaizdą.

• Greičio klasė: pasiekiamas Fmax, perdavimo maržos elgsena ir laikrodžių modelių skirtumai

• Pakuotė: I/O skaičius, banko vieta, SI poveikis, šiluminė elgsena ir surinkimo apribojimai

• SKU funkcijų apribojimai: išjungti blokai, sumažinta perdavimo galimybė, atminties santykiai arba protokolo apribojimai tam tikroms variacijoms

• Įrankių brandumas: prietaiso palaikymo lygis, leidimo dažnis ir ar jūsų komanda gali standartizuoti stabilios įrankių versijos

Praktinis palyginimo metodas:

• Tiekėjų laikrodžių modeliai pritaikyti jūsų faktiniams laikrodžiams ir sąsajoms

• Energijos vertinimas naudojant realistiškus perjungimo dažnius, darbo ciklus ir perdavimo nustatymus

• Pinout/banko apribojimai suderinti su jūsų valdybos reikalavimais ir jungiklio žemėlapiu

• Įrankių versijos, su kuriomis jūsų organizacija gali išgyventi visą produkto gyvavimo laiką (įskaitant CI)

Sprendimų sistema, kuri linkusi laikytis, kai dalykai tampa įtempti

Kai tvarkaraščio spaudimas kyla, matavimais pagrįsta sistema padeda išvengti apgailestaujančių pokyčių. Ji taip pat padeda komandai jaustis labiau stabiliai, nes sprendimai turi dokumentų taką, susietą su pastebėtais rezultatais, o ne optimizmu.

Subalansuotas pasirinkimo tvarka:

1) Užfiksuokite išmatuojamus reikalavimus: išteklius, I/O, atmintį, vėlinimą ir energijos/šilumos biudžetą.

2) Sukurkite prototipą sunkiausiai sub-sistemai kiekviename kandidatuose: laiko elgesys + derinimo darbo eiga + kūrimo/CI ciklas.

3) Įvertinkite IP brandumą ir licencijavimą atsižvelgdami į savo integracijos planą, o ne į marketingo santraukas.

4) Pasirinkite variantą su rezervu ir labiausiai prognozuojamu iteracijos ciklu, o ne tą, kuris vos atitinka minimalius reikalavimus.

Pagrindinė žinia yra ta, kad geriausias FPGA retai būna tas, kurio statistiniai duomenys yra įspūdingiausi. Komandos paprastai juda greičiau ir su mažiau dvejonių, kai platforma palaiko stabilų suartėjimą, pakartotinai vykdomas statybas ir prižiūrimas sprendimus viso produkto gyvavimo laikotarpiu.

Pagrindinė įrankių grandinė

Vivado vaidmuo FPGA darbo eigoje

Vivado paprastai tampa operaciniu centru Xilinx FPGA projekte, ne todėl, kad jis būtų įspūdingas, bet todėl, kad jame kiekviena prielaida galiausiai yra išbandoma pagal įrankio realybę. Jis priima HDL ir apribojimus, sukuria tinklo sąrašą, vykdo vietą ir maršrutizavimą, derindamas laiką ir fizinio dizaino taisykles, o tada generuoja bitų srautą, kuris programuoja įrenginį.

Praktinis būdas suprasti Vivado yra laikyti jį dviem susijusiomis sistemomis: RTL į tinklo sąrašą konvertavimo sistema ir fizinio įgyvendinimo optimizatorius. Tai paaiškina, kodėl logiškai teisingas RTL vis tiek gali duoti nestabilius ar nekonsekventiškus rezultatus, kai apribojimai nėra baigti, laikrodžių apibrėžimai nėra tikslūs arba dizaino struktūra sukelia maršrutizavimo ir laiko sunkumų.

Dauguma projektų seka pažįstamą vamzdyną, net kai detalės skiriasi priklausomai nuo įrenginio šeimos ir srauto stiliaus.

• Sintezė: verčia RTL į vartų lygio reprezentaciją ir išveda įrenginiui tinkamus struktūras.

• Įgyvendinimas: vykdo vietos, maršrutizavimo ir laiko valdomą optimizavimą pagal fizinius apribojimus.

• Bitų srauto generavimas: išleidžia konfigūracijos vaizdą ir kryžiaus tikrina įgyvendintus rezultatus pagal apribojimus ir įrankių taisykles.

Tvarkaraštis paprastai tampa įtemptas ne tada, kai bitų srautas yra pagaminamas vieną kartą, bet kai komandai reikia, kad bitų srautas elgtųsi kaip patikimas išėjimas: panašūs rezultatai per rekonstrukcijas, laiko ribos, kurios išlieka tiksliniame greičio lygyje, ir stabilumas, kai atliekami nedideli RTL redagavimai funkciniams pataisymams. Čia "suprato vakar" nustoja būti paguoda.

Komandos, kurios laikui bėgant juda greičiau, paprastai nustoja vertinti ataskaitas kaip popierius ir pradeda vertinti jas kaip inžinerinius įrodymus. Kai statybos artefaktai nuosekliai renkami, dizaino diskusijos tampa mažiau emocionalios ir konkretesnės, kas yra palengvinimas, kai terminai artėja.

• Sintezės/įgyvendinimo ataskaitos: naudojimas, numatyti primityvai, įspėjimai ir struktūrinės santraukos.

• Laiko išėjimai: WNS/TNS, nepanaudoti galai, išsamesni keliai ir laikrodžių sąveikos santraukos.

• XDC apribojimai: laikrodžiai, I/O taisyklės, išimtys ir fiziniai korespondencijos priskyrimai.

• Įgyvendinti patikros taškai (DCP): reprodukuojami momentiniai vaizdai, kurie palaiko greitą iteravimą ir valdomus eksperimentus.

Modelis, kuris pasirodo realiame darbe, yra tas, kad tvarkinga, viduje nuosekli ataskaitų rinkinys dažnai prognozuoja sklandesnį progresą nei vienas žalias "PRAEINA" banneris. Banner'is gali paslėpti trapumą; ataskaitos paprastai to nedaro.

Įdiegimas ir aplinkos nustatymas

Nustatymas, kuris tiesiog paleidžia GUI, yra lengva švęsti ir vėliau lengva apgailestauti. Nustatymai, kuriais komandos pasitiki, yra nuobodūs gerąja prasme: jie elgiasi taip pat automatizacijos metu, jie yra nuoseklūs per mašinas ir jie nenustebina po įrankio atnaujinimo.

Pasirinkite Vivado ML leidimą, kuris atitinka jūsų įrenginių tikslus, tada įgalinkite tik tas įrenginių šeimas, kurias tikrai planuojate statyti. Tai sumažina disko naudojimą ir indeksavimo laiką, taip pat sumažina nelaimingų atsitikimų tarp šeimų konfigūracijos klaidų, kurios gali iššvaistyti popietę, tikimybę.

Daugiaeidžiamų plokščių kūrimo komandose palaikyti apibrėžtą palaikomų įrenginių sąrašą kiekvienam projektui padeda išlaikyti kūrimą labiau kontroliuojamą ir nuoseklų nei pasikliauti bet kokiais įrankiais ar dalimis, kurios gali būti įdiegtos.

Vivado išėjimai gali skirtis tarp versijų, nes vieta, maršrutizavimas ir laiko algoritmai vystosi, o klaidos taisomos (arba pakeičiamos kitomis klaidomis). Dauguma komandų gauna ramiau veikiančias statybas prisirišdami prie vieno įrankio versijos kiekviename išleidimo šakoje ir atnaujindami suplanuotais žingsniais, o ne nuolat plaukdamos.

Bandantys naujos versijos, komandos dažnai palygina įrankio sveikatingumo praktinius signalus prieš priimdamos ją kaip naują bazinę: laikymo maržos, naudojimo pokyčiai, įspėjimų delta ir bet kokie nauji apribojimų aprėpties pranešimai. Laikas, praleistas atliekant tą palyginimą, paprastai yra lengvesnis nei ginčytis vėlai cikle dėl to, ar laikymas staiga pablogėjo be jokios priežasties.

Komandų eilutės kūrimuose, CI sistemose ir bendrose kūrimo serveriuose, kūrimo aplinka turi elgtis nuosekliai visose sistemose, o ne priklausyti nuo atskirų mašinų konfigūracijų.

• Nustatymų skriptai: šaltinis tinkami įrankių nustatymai, kad keliai, bibliotekos ir vykdymo priklausomybės būtų nuosekliai išspręstos.

• Tcl pagrindu valdomi srautai: teikti pirmenybę skriptuotiems kūrimams, kad būtų galima pakartoti bėgimus, vienodą ataskaitų teikimą ir CI integraciją.

• Kūrimo sąsajos disciplino: išlaikyti įvestis ir išvestis stabilias, kad pokyčiai būtų tyčiniai ir peržiūrimi.

Dažnas kūrimo darbo procesas yra pirmiausia užbaigti stabilų GUI kūrimą, kad būtų patvirtintas dizainas, tada pereiti prie Tcl pagrįsto srauto, kad kūrimo procesas daugiau nepriklausytų nuo GUI nustatymų, talpykloje esančių duomenų ar skirtumų tarp kūrimo mašinų.

Ataskaitos, kurias norėsite perskaityti kaip diagnostiką

Dauguma dizaino nesėkmių momentų nėra paslaptingi ilgai, jei ataskaitos skaitomos kaip istorija to, kuo įrankis tikėjo. Įspėjimai, apribojimų aprėptis ir laikymo keliai paprastai dokumentuoja nesėkmės režimą atvira akimi, nors ne visada pačioje draugiškiausioje tvarkoje.

Komandos greičiausiai tobulėja, kai traktuoja Vivado išvestis kaip kasdienę grįžtamąją informaciją, o ne kaip kažką, ką atidarote tik tada, kai statyba sugriūna.

Šios ataskaitos dažnai yra pirmas vietas, kur intencijų nukrypimas tampa matomas, ir tai gali būti keistai ramina: bent jau problema yra konkreti.

• Ištekliai naudojami: LUT, FF, BRAM, DSP, URAM prieš įrenginio ribas ir laisvę.

• Išvedimo patikrinimai: netikėti RAM stiliai, trūkstama DSP išvestis, stebinantis pirminis žemėlapis.

• Struktūriniai raudoni vėliavėlės: didelio ventiliacijos tinklai, platus muxing, ilgos kombinacinės grandinės.

• Įspėjimai: latch išvestis, nebaigtas jautrumo tvarkymas, ne prijungta arba supjaustyta logika.

Latch išvestis ir nenorimos ilgos kombinacinės grandinės pasirodo dažnai praktikoje. Įrankis jas įgyvendins be skundų, ir tai gali jaustis apgaulingai, kai laikymas vėliau atsisako bendradarbiauti tokiais būdais, kurie atrodo atsitiktiniai, kol nėra perskaitytos kelio ataskaitos.

Laikymo uždarymas tampa mažiau stresuojantis, kai komanda žino, ką įrankis optimizuoja ir kodėl jis pasirinko tam tikras kompromisus.

• Slack signalai: WNS kaip blogiausias vienas pažeidimas; TNS kaip bendras pažeidimų išplitimas.

• Kelio suskirstymas: kur kaupiasi delsimas (logikos gylis, maršrutizavimas, laikrodžių darymas ar apribojimų prielaidos).

• Laikrodžių modeliavimas: ar keliai analizuojami kaip numatyta, ignoruojami ar grupuojami neteisingai.

Vienas niuansuotas pamokas, kurį įsisavina patyrusios komandos, yra tas, kad laikymo skausmas dažnai yra apribojimų modeliavimo problemos pirmiausia ir RTL problemos antra. Kai laikrodžio modelis yra neteisingas, jis gali praleisti dienas optimizuojant neteisingus galinius taškus ir vis tiek jaustis tarsi įrankis neklausytų.

Apribojimų spragos yra pakartotiniai nusikaltimai, iš dalies dėl to, kad jos visada neatrodo dramatiškai tol, kol projektas yra pažengęs.

• Laikrodžių apibrėžimo spragos: trūkstami arba neteisingi pirminiai laikrodžiai.

• Generuoti laikrodžių spragos: padalinti/multiplikuoti/persiųsti laikrodžiai nebuvo paskelbti, verčiant įrankį spėlioti.

• I/O apibrėžimo spragos: trūkstami I/O apribojimai, kurie lemia optimistines prielaidas ir vėliau lentos lygio staigmenas.

• Išimčių netinkamas naudojimas: trūkstamos išimtys arba išimtys, kurios yra per plačios, kad būtų patikimos.

Pragmatiška praktika yra laikyti XDC kaip gyvą specifikaciją, o ne kaip pataisos failą. Kai bus įvestos išimtys, komandos, kurios miega geriau, paprastai linkusios jas išlaikyti siauras, paaiškinamas ir susietas su tikru laikymo santykiu, o ne jas naudoti, kad nuramintų pažeidimus, kurie nusipelno peržiūros.

XDC apribojimų strategija

XDC failas yra vieta, kur dizaino ketinimas yra verčiamas būti aiškus. Kai jis yra šiek tiek neteisingas, gaunama laikymo elgsena gali atrodyti chaotiška, nors įrankis visiškai deterministinis.

Aiškiai apibrėžkite laikrodžius, tada patikrinkite, ar įrankis juos propagavo taip, kaip tikėtės. Laikrodžių modelio problemos dažnai būna lengviau ištaisyti nei giliau architektūrinių laikymo problemų, todėl jas paprasčiau išspręsti laikymo analizės ir derinimo metu.

• Pirminiai laikrodžiai: apibrėžti iš pinų arba iš MMCM/PLL išvesties.

• Generuoti laikrodžiai: apibrėžti padalintiems, padaugintiems arba perduotiems domenams.

• Asinchroniniai ryšiai: paskelbti per laikrodžių grupes ar aiškius ryšius.

Tikruose lentose vienas praleistas generuotas laikrodis gali sukurti klaidingą laikymo vaizdą, kuris užima dienas, ypač kai įrankis optimizuoja link galinių taškų, kurie niekada nebuvo skirti analizuoti kartu.

I/O apribojimai formuoja elektrinius ir laikymo prielaidas, kurias naudoja įrankis, ir tai gali tyliai nuspręsti, ar laboratorijos sėkmė virsta „sistemos sėkme“.

• Elektros standartai: I/O standartai ir įtampų suderinimas su plokštės dizainu.

• Pin'ų disciplina: užrakinti pin'ų vietas, kai žemėlapis stabilizuojasi, kad būtų išvengta pasikeitimų.

• Sąsajos laikymas: įėjimo/išėjimo vėlavimai, atspindintys išorinį įrenginį, o ne įrankio numatytuosius nustatymus.

Įprasta vėlyvo etapo nusivylimas yra: jis atitiko laiką statybos metu, tačiau sąsaja nepavyksta realioje eismo situacijoje. Šis rezultatas dažnai susijęs su numatytais I/O prielaidomis, kurios niekada nebuvo atnaujintos, kad atitiktų plokštės ir išorinio įrenginio laikymo biudžetą.

Išimtys gali patikslinti ketinimus, o jos taip pat gali sukurti trapų pažangos įspūdį, jei jos išgyvena savo pirminę pateisinimą.

• Klaidingi keliai: naudojami tik kai kelias iš tikrųjų nėra funkcinio laikymo dalis.

• Daugiasluoksniai keliai: naudojami tik kai užfiksavimo santykis tikrai apima kelis ciklus ir yra dokumentuotas.

• Išimčių higiena: laikyti rinkinį mažą, peržiūrėti jį po didelių RTL/pipeline pokyčių ir pašalinti senas įrašus.

Kai kurie iš brangiausių laikymo klaidų kyla iš išimčių, kurios buvo tikslūs vieną kartą, tada tyliai tapo netikslūs po pipeline pokyčio. Įrankis laikysis, nesiskųsdamas, kas būtent daro šį gedimo režimą tokiu nemaloniu.

Tipiniai gedimų modeliai ir kaip juos efektyviai išspręsti

Tam tikros problemos kartojasi per projektus, nepriklausomai nuo to, ar taikymas yra tinklavardis, vizija, kontrolė, ar pagreitėjimas. Ankstyvas šablono atpažinimas paprastai sumažina emocinę debuginimo naštą, nes komanda gali pereiti nuo „kodėl tai įvyksta“ prie „kuri strategija taikoma“.

Ši situacija dažnai atrodo, kad įrankis yra užsispyręs, tačiau šaknies priežastys paprastai yra atsekamos.

• Kombinacinis gylis: ilgi keliai, kuriuos sukelia trūkstamas ar nepakankamas pipeline'ingas.

• Ventiliacijos spaudimas: didelio ventiliacijos kontrolės tinklai, kurie gali pasinaudoti replika, buferizavimu ar pertvarkymu.

• Apribojimų modeliavimas: laikrodžio apibrėžimai ar santykiai, kurie netinkamai charakterizuoja, ką reikia analizuoti.

Sekos, kuri dažnai veikia gerai, yra: patvirtinti laikymo modelį (laikrodžiai ir santykiai), pirmiausia sutelkti dėmesį į blogiausius nesėkmės taškus, tada plėsti architektūrinius pokyčius tik jei kelio įrodymai tai palaiko.

Tai yra viena iš demoralizuojančių patirčių FPGA darbuose, daugiausia todėl, kad atrodo, jog realybė elgiasi nesąžiningai. Paprastai, tai tiesiog, kad simulacija nesugebėjo pabrėžti tų pačių gedimų režimų.

• CDC/atstatymo elgsena: atstatymo sekos ir laikrodžio srities kirtimų, kurių simuliacija retai realistškai išbando.

• I/O prielaidos: neapriboti ar neteisingai apriboti I/O, kurie gamina marginalias realias sąsajas.

• Iniciavimo elgsena: priklausomybė nuo pradiniu reikšmių, kurios nesusiję su įrenginio energijos įjungimo elgsena.

Komandos, kurios tampa tvirtesnės, jau anksti įtraukia CDC ir atstatymo strategiją į dizaino diskusiją, vertindamos juos kaip dizaino architektūros dalį, o ne užbaigimo etapą po „tikros logikos“ pabaigos.

Ši problema yra paplitusi, nes vieta ir maršrutas ryškiai reaguoja į netlito struktūros pokyčius, net kai funkcinis pokytis atrodo nedidelis.

• Netlito jautrumas: mažos pertvarkos gali pakeisti pakavimo, vietos sprendimus ir maršruto užimtumą.

• Apribojimų nuokrypis: mažos XDC pakeitimai (arba trūkstama aprėptis) gali sustiprinti laikymo svyravimus.

• Sušvelninimo įpročiai: palaipsniui vykdoma įgyvendinimas, selektyvinis hierarchijos išsaugojimas ir stabilūs apribojimai.

Kai komandos priima šiuos sušvelninimo įpročius, iteracija dažnai jaučiasi labiau nuspėjama, o tai sumažina pagundą užšaldyti dizainą per anksti dėl baimės dar kartą sugadinti laikymą.

Licencijavimo apsvarstymai

Licencijavimo klausimas paprastai tampa diskusija, kai projektas susiduria su įrenginio aprėpties ribomis arba kai tam tikram darbo eigai reikia pažangių funkcijų.

• Standartas: dažnai suderinamas su įėjimo ir vidutinio lygio mokymosi plokštėmis ir pagrindiniais srautais.

• Enterprise: dažnai suderinamas su platesne įrenginio parama ir pažangiomis galimybėmis.

Komandoms plaukiojančios licencijos, palaikomos licencijų serveriu, dažnai lengviau keisti nei mazgo užrakintos licencijos, ypač kai statybos vyksta bendro naudojimo mašinose, skirtuose statybos serveriuose ar CI bėgikų. Daugelis komandų labiau mėgsta iš anksto suderinti licencijavimą su įrenginio kelrodžiu, nes licencijavimo staigmenos turi paplitimą, kai canviuojant įrenginius jau būna brangu ir politiškai sudėtinga.

Nuoseklus inžinerinis ciklas paprastai prognozuoja nuoseklesnį pažangą nei bet koks vienas gudrus optimizavimas: laikykite apribojimus suderintus su realybe, reguliariai skaitykite ataskaitas (net kai norėtumėte to nedaryti), taisykite esmines priežastis vietoj simptomų slopinimo ir užtikrinkite, kad statymai būtų atkuriami. Kai šis ciklas yra sukurtas, Vivado jaučiasi mažiau kaip juodoji dėžutė ir labiau kaip instrumentų pultas, o laiko uždarymas pereina iš paskutinės minutės įtampos į kažką, ką komanda gali valdyti sąmoningai.

Xilinx portfelis ir ekosistema

Pasirinkimas tarp Xilinx prietaisų paprastai vyksta sklandžiau, kai pradinis taškas yra aplinkinis integravimas (procesoriai, atminties sąsajos, paleidimo kelias ir plokštės lygio priklausomybės), o ne tik šių prietaisų žaliųjų LUT bendrųjų palyginimas. Tas rėmas paprastai atitinka tai, kaip realūs grafikai ir realūs pavojai pasirodo.

Discretinis FPGA paprastai tinka, kai komanda nori visiškos plokštės architektūros nuosavybės ir darbo krūvis linksta į determinuotą aparatūros elgseną su minimaliu programinės įrangos paviršiumi. Zynq klasės SoC paprastai tinka, kai projektas gauna naudą iš CPU, kuris yra arti pagreitimo logikos, todėl valdymas ir duomenų kelias gali vystytis kartu, nekeliant plokštės į multi-čipo derybas. Kria SOM stiliaus modulis paprastai tinka, kai planas yra veikti greitai ir apriboti plokštės paleidimo neaiškumą, laikant skaičiavimus, atmintį ir paleidimo saugyklą kaip iš anksto patvirtintą statybinį bloką.

Discrete FPGA paprastai tinka:

• maksimali plokštės dizaino kontrolė

• determinuoti tiekimo kanalai su ribota programinės įrangos priklausomybė

Zynq SoC paprastai tinka:

• glaudus CPU + pagreitintuvo sujungimas

• suvienyta skaičiavimo / kontrolės funkcija viename įrenginyje

• iteratyvi HW/SW raida

Kria SOM paprastai tinka:

• trumpesnis laikas iki produkto

• sumažinta plokštės lygio ekspozicija naudojant patvirtintą skaičiavimo subsistemą

Paprasti FPGA dažnai gerai pasirodo, kai problema atsiranda dėl laiko uždarymo spaudimo, neįprastų I/O poreikių arba srauto kanalų, kurie geriausiai veikia kaip fiksuota aparatūra. Prognozuojama latencija ir struktūrizuoti duomenų keliai dažnai pagerina valdymą, patvirtinimą ir derinimą, ypač kai architektūra lieka gerai organizuota.

Savarankiški įrenginiai dažnai pasirodo:

• jutiklių interfacing

• variklių valdymas

• vidutinio greičio paketo apdorojimas

• protokolo tiltas

Lauke, pasikartojanti frustracija nėra RTL pati, o aplinkos plokštės įsipareigojimai, kurie tyliai pasirodo ir po to užima kritinę kelią. Energijos geležinkeliai, konfigūracija ir paleidimo strategija, laikrodžio generavimas, išorinės atminties išdėstymas (kai jis yra), ir derinimo prieiga gali tapti apribojimais, kurie formuoja visą produktą. Vienas praktinis taisyklės patarimas yra tas, kad kuo paprastesnė išorinės atminties istorija ir kuo mažiau didelės spartos prijungimų dalyvauja, tuo labiau patenkinama savarankiško FPGA patirtis. Kai tik išorinė DDR ir daugiasluoksnės paleidimo srautai tampa neišvengiami, SoC ar modulio integravimo apeliacija pradeda jaustis mažiau kaip funkcija ir labiau kaip palengvinimas.

Kainų optimizuotos šeimos paprastai siekia išmatuoto LUT, BRAM ir DSP derinio pagal apribotus energijos biudžetus. Jos dažnai pasirodo produktuose, kur inžinierių komanda nori tinkamos galimybės, nesumokėdama už plokštės ir šilumos mokesčius, kurie kyla dėl ekstremalių sąsajų.

Dažnos nusileidimo zonos apima:

• įmontuotas valdymas

• vidutinio lygio I/O agregacija

• vidutinio greičio signalų apdorojimas

Privalumas yra ne tik vieneto kaina, komandos dažnai įvertina, kad šios dalys palengvina būti energetiniuose ribose, nesikreipiant į agresyvų šilumos išsklaidymą, ir jos gali išlaikyti PCB nuo eskalacijos į didelės spartos išdėstymo projektą. Tuo pačiu metu lauko statymai reguliariai moko šiek tiek nepatogią pamoką: mažesnės kainos įrenginys gali sukelti didesnes bendras išlaidas, jei jis priverčia vėlyvos stadijos dizaino kompromisus. Kai laiko rezervas yra plonas, nedideli koregavimai, I/O standartų pokyčiai, laikrodžio maršruto koregavimas, grindų plano pokyčiai gali išsiveržti į patvirtinimą, derinimą ir grafiko nerimą. Šiems įrenginiams komandos paprastai sutaupo laiko anksti nustatydamos laikrodžių domeno planavimą, CDC strategiją ir iš naujo nustatyti elgesį, o ne tikėdamiesi, kad vėlyvos mikro-optimizacijos išgelbės planą.

Zynq SoCs

Zynq įrenginiai sujungia ARM apdorojimą su programuojama logika, kas leidžia dizainui pasidalinti į kontrolės lygio programinę įrangą ir duomenų lygio pagreitį taip, kaip tai atrodo natūralu daugeliui produktų komandų. Tai ne tik pagerina patogumą, bet ir formuoja darbo eigą. Komandos gali pradėti nuo programinės įrangos pirmosios nuorodos funkcinio pasitikėjimo, o tada migracijai karštosiomis keliais į aparatinę įrangą, kai pralaidumo ir latencijos reikalavimai tampa mažiau derinami.

Gerai senstantys diegimuose CPU retai „pakeičia“ aparatūrą, ji paprastai stabilizuoja produktą. Procesorius dažnai rūpinasi konfigūracija, telemetrija, lauko atnaujinimais, saugumo politika ir kraštine jungtimi, tuo tarpu audinys vykdo deterministinius vamzdynus. Tas atskyrimas gali būti emocinškai ramus priežiūros specialistams: programinė įranga sugeria pokyčius, aparatinė įranga lieka stabili, o leidimai atrodo mažiau lyg lošimas.

CPU paprastai apima:

• konfigūracija

• telemetrija

• atnaujinimai

• saugumo politika

• kraštinė jungtis

Audinys paprastai apima:

• deterministiniai srautiniai vamzdynai

• stabilūs akceleratoriai

• latenciją jautrūs duomenų keliai

Auštinant kompiuterinės galios tankį ir reikalavimus sąsajoms, Zynq UltraScale+ estilo dalys sumažina plokštės ir sistemos sudėtingumą, priartindamos CPU šerdys, DDR valdiklius ir didelės pralaidumo jungtis arčiau audinio. Tai tampa patrauklu dizainuose, kuriems reikia tiek realaus laiko determinizmo, tiek pajėgios programinės įrangos aplinkos, ypač kai darbo krūvis yra mišrus, o ne vienas švarus branduolys.

Dažni naudojimo atvejai apima:

• kraštinės analizės

• daugiajutiklinis susiliejimas

• mišrūs realaus laiko ir AI vamzdynai

Detalė, kurią patyrę komandos išmoksta gerbti, yra ta, kad „daugiau audinio“ automatiškai nesukelia „daugiau teikiamos veiklos“. Projektai dažnai susiduria su atminties pralaidumo lubomis, prieš išnaudodami DSP ar LUT. Dizainai, kurie anksti pasirenka DMA topologiją, buferizavimo strategiją ir kešavimo nuoseklumo lūkesčius, paprastai pasiekia stabilų našumą su mažesniu sukrėtimu nei dizainai, kurie atideda duomenų judėjimo sprendimus iki vėlyvos integracijos.

Skirstymas retai būna apie tai, ar kažkas gali būti pagreitinta, daugiau apie tai, ar pagreitimas atsiperka atsižvelgiant į patikros pastangas, tvarkyklės ir vykdymo sudėtingumą, bei kaip dažnai tikimasi, kad logika keisis. Komandos dažnai jaučia „sukimo gale“: per daug stumiant į aparatūrą gali sulėtinti iteraciją, tuo tarpu palikus per daug CPU gali likti per mažai pralaidumo tikslai nuolat beveik pasiekiami.

Darbo krūviai, kurie dažnai lieka CPU ilgiau nei tikėtasi, apima:

• greitai kintančią logiką

• sudėtingą analizės intensyvumą

• bruožus su greitais iteracijos ciklais

Darbo krūviai, kurie dažnai atlygina ankstyvą audinio akceleraciją, apima:

• stabilūs algoritmai

• kompiuterinės galios tankūs branduoliai

• srautui palankūs duomenų keliai

Pragmatiškas modelis yra pradėti nuo mažo, nuo galo iki galo, dažnai paprasto DMA loopback su minimaliais akceleratoriais, prieš statant visą funkcijų rinkinį. Tas ribotas prototipas paprastai atskleidžia integracijos problemas, kurios kitaip pasirodytų vėlai ir brangiai: pertraukimo elgesys, buferio derinimas, kešavimo priežiūros sąnaudos ir pralaidumo lubos, kurios atsiranda tik esant nuolatiniams apkrovimams.

Kria SOM ir modulių stiliaus platformos

Kria SOM supakuoja kompiuterį, atmintį ir paleidimo kaupiklį į paruoštą subsistemą, nukreipdamos pastangas nuo plokštės paruošimo į programinės įrangos inžineriją. Komandos dažnai mėgsta šį požiūrį, nes jis sumažina neapibrėžtumą: signalo vientisumas, DDR maršrutizavimas, energijos sekos tvarka ir paleidimo patikimumas jau yra patvirtinti, todėl ankstyvos demonstracijos gali pasirodyti mažiau trapios, o planavimas atrodo mažiau spekuliatyvus.

Šis požiūris paprastai veikia ypač gerai, kai diferenciacija egzistuoja algoritmuose, I/O topologijoje ir diegimo patikimumo, o ne pagal individualų kompiuterinės aparatinės įrangos plokštę. Jis taip pat gali sumažinti komandos trintį: aparatūros, programinės įrangos ir programų darbas gali vykti lygiagrečiai su mažiau „blokuojami paruošimo“ akimirkų.

Patvirtinta SOM integracija dažnai apima:

• signalo vientisumas

• DDR maršrutizavimas

• energijos sekos tvarka

• paleidimo patikimumas

Komandos gali sutelkti pastangas į:

• nešimo plokštės diferenciaciją

• programinės įrangos integraciją

• programų elgesį

• diegimo grūdinimą

SOM dažnai turi didesnę vieneto kainą nei visiškai suasmeninta plokštė, tačiau viso programos kaina vis dar gali sumažėti, kai grafikai yra griežti arba gamybos derlius yra nepatogus. Mažiau akivaizdus pelnas yra gyvenimo ciklo prognozavimas: su moduliu kompiuteris kartais gali būti laikomas keičiamu elementu tarp produktų variantų, mažinant perdarymo apyvartą, kai reikalavimai keičiasi viduryje.

Ramiamiausias žingsnis yra anksti patvirtinti, kad SOM šilumos rezervas, I/O ekspozicija ir atminties pralaidumas tikrai atitinka numatomą darbo krūvį, o ne pasitikėti specifikacijos lapo apžvalga. Jei programa pasirodo esanti apribota pralaidumu, vėlyvos stadijos derinimas paprastai jaučiasi kaip stumti užrakintą duris, nes akceleratoriaus poreikis ir modulio atminties subsąjunga paprasčiausiai dominuoja.

Ankstyvi tinkamumo patikrinimai paprastai apima:

• šilumos apvalkalas

• eksponuojamas I/O

• nuolatinis atminties pralaidumas prieš darbo krūvio paklausą

AI diegimas ekosistemoje

Vitis AI padeda konvertuoti išmokytus modelius į FPGA pagrindu veikiančius inferencijos dizainus, naudodama mažesnės tikslumo formas, dažnai INT8, ir juos kompiliuodama DPU stiliaus architektūroms. Tai greitai patvirtina, ar modelis gali veikti FPGA platformoje. Tačiau tikrasis našumas dažnai labai priklauso nuo aplinkos sistemos dizaino, ypač duomenų judėjimo ir atminties tvarkymo.

Eilučių-per-eilutes pralaidumą paprastai lemia, kaip nuosekliai sistema gali tiekti DPU. Grupavimo strategija, tenzoriaus išdėstymas, DMA tvarkaraštis, dvigubas buferis ir atminties išdėstymas dažnai lemia pristatytą FPS daugiau nei skaičiavimo antraštė. Komandos, kurios traktuoja DPU kaip nuolatinį srautinio vartotojo, su kruopščiai paruoštais buferiais, linkusios išvengti įprasto nusivylimo įspūdingais teoriniais TOPS, bet nepatenkinamais sistemos lygio rezultatais.

Našumo formavimo valdikliai paprastai apima:

• grupavimo strategija

• tenzoriaus išdėstymas

• DMA tvarkaraštis

• dvigubas buferis

• atminties išdėstymas

Įdiegimuose, smulkūs įgyvendinimo pasirinkimai kaupiasi būdais, kuriuos gali būti sunku numatyti iš laboratorinių mikrotestų. Nesuderinti buferiai gali tyliai sumažinti efektyvų pralaidumą. Per didelis talpyklos priežiūra gali išnaudoti CPU laiką ir sukurti Jitter. Daug kopijų reikalaujančios vamzdynų sistemos gali sunaikinti didelę dalį naudos, gautos iš kvantizacijos. Pagrindinis požiūris yra matuoti pralaidumą ir vėlavimą kiekviename riboženklyje, o tada koncentruoti pastangas ten, kur šiuo metu yra didžiausia įtampa.

Naudingi matavimo riboženklių apibrėžimai apima:

• jutiklis iki DDR

• DDR iki akceleratoriaus

• akceleratorius iki po apdorojimo

Naudingas proto modelis yra vertinti AI vamzdyną kaip ribotą srauto tinklą. Su šiuo įrėminimu įrenginio pasirinkimas tampa mažiau apie didžiausio skaičiavimo skaičiaus siekimą ir labiau apie pasirinkimą, kuris atlaisvina dominuojančią siaurąją vietą ir išlaiko vamzdyno elgseną prognozuojamą.

Ekosistema ir įgalinimas

Xilinx ekosistema plečiasi už silicio ribų, į aplinkos galimybes, kurios padeda komandoms judėti: įrankių grandinės, IP, nuorodos dizainai, partnerių plokštės ir mokymo ištekliai. Akademinėse aplinkose Universiteto programa dažnai vertinama, nes ji sumažina nuolatines nustatymo problemas, priėjimą prie įrankių, plokščių prieinamumą ir laboratorijos struktūrą, todėl ankstyvas progresas mažiau tikėtina sustoti dėl aplinkos problemų, o ne dėl mokymosi tikrojo inžinerijos.

Ekosistemos komponentai apima:

• įrankių grandinės (Vivado, Vitis)

• IP katalogai

• nuorodų dizainai

• partnerių plokštės

• mokymo programos

• Universiteto programos ištekliai

Kai prisijungimo trukdžiai sumažinami, mokymosi proceso dalyviai gali investuoti savo energiją į įpročius, kurie tiesiogiai verčia į profesionalią darbą: laiko uždarymo rutinos, vamzdynų disciplina, patikrinimo strategija ir aparatūros/programinės įrangos bendro dizaino vertinimas. Šios įgūdžių tendencijos demonstruoja savo vertę integracijos metu, kai rezultatus labiau formuoja kartojimo greitis ir sistemos vientisumas nei izoliuotas branduolio vertinimas.

Perkeliami įgūdžiai apima:

• laiko uždarymo įpročius

• vamzdynų discipliną

• patikrinimo strategiją

• aparatūros/programinės įrangos bendrą dizainą

Pasirinkimo principas, kuris išlieka nuoseklus visoje linijoje

Patikimas pasirinkimo požiūris prasideda nuo sisteminių apribojimų, o ne nuo rinkodaros lygių. Komandoms paprastai nesunku priimti aiškius sprendimus, kai jos išdėsto veikimo tikslus ir projekto realybę iš anksto, tada pasirenka integracijos lygį, FPGA, Zynq SoC ar SOM, kuris sumažina didžiausius neaiškumo šaltinius jų konkrečiam programai. Tai dažnai sukelia pasirinkimus, kurie jaučiasi geriau po kelių mėnesių, kai integracija ir kartojimo greitis yra svarbesni nei paviršutiniškai lyginamas komponentas.

Ankstyviems apibrėžimams priskiriami:

• vėlavimo tikslai

• nuolatinio pralaidumo poreikiai

• sąsajos reikalavimai

• šilumos ribos

• atnaujinimo dažnis

• patikrinimo biudžetas

Daugelyje programų pasirinkimas, kuris išlaiko duomenų judėjimą paprastą ir plėtros ciklą glaustą, pasirodo esantis tas, kuris ilgainiui laikosi geriausiai, net jei jo vieneto kaina iš pirmo žvilgsnio nėra patraukliausia.

Išvada

Mokymasis Xilinx FPGA dizaino tampa lengvesnis, kai kiekvienas projektas vyksta pagal stabilų ir pakartojamą procesą. Stiprūs rezultatai priklauso nuo švaraus HDL, teisingų apribojimų, kruopštaus laiko patikrinimo, modeliavimų ir tikro aparatinės įrangos patvirtinimo. Pradėdami nuo paprastų dizainų ir formuodami gerus derinimo įpročius, pradedantieji gali išvystyti patikimus FPGA įgūdžius sudėtingesnėms skaitmeninėms sistemoms.

Dažnai užduodami klausimai [DUK]

1. Kodėl FPGA pradedantieji dažnai susiduria su sunkumais, net kai jų HDL kodas atrodo logiškai teisingas modeliavime?

Daugeliui ankstyvųjų FPGA problemų priežastis nėra pats RTL, bet atotrūkis tarp simuliacijos prielaidų ir fizinio aparatinės įrangos elgesio. Simuliacija dažnai slepia problemas, susijusias su laikrodžių ribojimais, atstatymo sinchronizavimu, I/O standartais, metastabilumu ir laiką uždarančia. Dizainas gali simuliuotis puikiai, tačiau vis tiek nesuveikti aparatinėje įrangoje, nes FPGA įrankiai interpretuoja laikrodžius kitaip, ribojimai yra neišsamūs arba asynchroniniai įėjimai yra neteisingai tvarkomi.

2. Kodėl laiko ribojimai laikomi pagrindine FPGA dizaino dalimi, o ne galutine optimizavimo žingsniu?

Laiko ribojimai apibrėžia, kaip FPGA įrankiai interpretuoja laikrodžius, I/O laikinius santykius, generuojamus laikrodžius ir asynchronines sritis. Be tikslių ribojimų, Vivado gali optimizuoti dizainą, naudodamas neteisingas prielaidas, kas lemia klaidinančius laikų ataskaitas ir nestabilų aparatinės įrangos elgesį. Daug FPGA gedimų įvyksta net tuomet, kai logika pati yra teisinga, nes laikrodžiai nebuvo teisingai deklaruoti, I/O laikas buvo ignoruotas, arba išimtys buvo taikomos pernelyg plačiai. Praktikoje, ribojimai tarnauja kaip oficialus dizaino ketinimų aprašymas, leidžiantis įrankiams sukurti aparatinę įrangą, kuri atitinka realų elektrinį elgesį.

3. Kodėl FPGA derinimas dažnai reikalauja tiek simuliacijų, tiek įranginio įrankių kaip ILA?

Simuliacija yra labai efektyvi funkcioninių klaidų aptikimui, tačiau negali visiškai atkurti realaus pasaulio aparatinės įrangos efektų, tokių kaip drebėjimas, asynchroniniai įėjimai, plokštelės lygio vėlavimai, metastabilumas ir įsijungimo variacijos. Įranginiai derinimo įrankiai, tokie kaip Integruotas Logikos Analizatorius (ILA), suteikia matomumą į vidinius FPGA signalus, kai sistema veikia realiomis sąlygomis. Tai leidžia fiksuoti tikrąsias būsenų pereigas, FIFO elgseną, rankenų perdavimus ir laikinius santykius tiesiai viduje prietaiso. Simuliacijos derinimas su ILA derinimu sukuria išsamesnį supratimą apie tai, kodėl aparatinė įranga skiriasi nuo tikėtino elgesio.

4. Kodėl patyrę FPGA inžinieriai teikia pirmenybę disciplinuotiems, kartojamiems darbo procesams, o ne nuolat keičiamoms projekto nustatymams?

Kartojami darbo procesai mažina neapibrėžtumą ir palengvina klaidų izoliuojimą. Naudojant tą patį kūrimo valdybą, laikrodžių struktūrą, atstatymo strategiją ir projekto šabloną, inžinieriai gali sutelkti dėmesį į kuriamą logiką, o ne nuolat derinti pačią aplinką. FPGA projektai apima daug tarpusavyje susijusių kintamųjų, įskaitant ribojimus, laikrodžius, sintezės elgseną ir plokštelės lygio konfigūraciją. Kai per daug kintamųjų keičiasi vienu metu, derinimas tampa neprognozuojamas ir emociškai varginantis. Stabilūs darbo procesai didina pasitikėjimą, nes pokyčius galima priskirti konkretiems dizaino sprendimams, o ne nežinomoms aplinkos skirtumams.

5. Kodėl FPGA aparatinės įrangos dizainas yra fundamentaliai skirtingas nuo tradicinio programavimo?

Programinė įranga vykdo instrukcijas sekos tvarka, tuo tarpu FPGA aparatinė įranga veikia per tuo pačiu metu veikiančias loginės struktūras. HDL aprašo fizinės aparatinės įrangos elgesį, o ne procedūrinį vykdymo srautą. Pradedantieji dažnai tikisi programinės įrangos tipo elgesio, o tada pasimeta, kai keli aparatinės įrangos blokai reaguoja tuo pačiu laikrodžio lygio momentu paraleliai. Todėl FPGA dizainas pabrėžia vamzdynus, laikinius santykius, sinchronizavimą, išteklių žemėlapiavimą ir laikrodžių srities elgesį, o ne tik instrukcijų tvarką. Suvokti konkurenciją yra vienas iš svarbiausių proto posūkių FPGA inžinerijoje.

6. Kodėl maži RTL pokyčiai gali staiga sukelti didelius laikų uždarymo problemas FPGA projektuose?

FPGA laikų elgesys labai priklauso nuo vietos, maršruto perkrovos, šakos, laikrodžių santykių ir fizinių resursų naudojimo. Net ir maži RTL pakeitimai gali pakeisti, kaip sintezės ir maršruto įrankiai žemėlapiuoja logiką per prietaisą. Rodosi nekaltas pokytis gali padidinti maršruto slėgį, pailginti kombinacinių kelių ilgį arba paveikti vietos sprendimus taip, kad žymiai sumažintų laikų rezervą. Ši jautrumas dar labiau didėja augant panaudojimui, ypač kai dizainai artėja prie maršruto ar laikrodžių ribų.

7. Kodėl FPGA projektai dažnai tampa apriboti plokštelės lygio realijomis, o ne tik RTL sudėtingumu?

Augant FPGA sistemoms, iššūkiai, susiję su energijos sekos valdymu, DDR išdėstymu, laikrodžių generavimu, terminėmis savybėmis, signalų vientisumu ir perdavimo maršrutizavimu, dažnai dominuoja kūrimo laiką. RTL gali veikti teisingai, tuo tarpu aplinkinė aparatinės įrangos infrastruktūra sukelia nestabilumą arba integracijos gedimus. Inžinieriai dažnai atranda, kad plokštelės dizaino sprendimai, atstatymo sekos valdymas ir atminties sąsajos elgesys formuoja bendrą projekto sėkmę labiau nei pats HDL. Tai ypač tiesa, kai kalbama apie didelio greičio sistemas su išorine DDR atmintimi ir SERDES sąsajomis.

8. Kodėl daugelyje FPGA komandų įrankių grandinės vertinama taip pat rimtai, kaip pati FPGA aparatinė įranga?

FPGA įrankių grandinė tiesiogiai veikia kompiliavimo laiką, uždarymo stabilumą, derinimo efektyvumą, CI integraciją ir bendrą inžinerinę produktyvumo lygį. Lėti arba nesuderinti įgyvendinimo rezultatai gali dramatiškai padidinti iteracijos laiką ir tvarkaraščio spaudimą. Komandos dažnai vertina sintezės kokybę, laikino ataskaitų aiškumą, derinimo instrumentavimą ir reprodukuojamumą prieš įsipareigodamos platformai. Tikroje kūrimo aplinkoje nuspėjamos versijos ir stabilus uždarymas dažnai yra svarbesni nei izoliuoti pagrindiniai FPGA specifikacijos.

9. Kodėl Zynq SoC ir Kria SOM platformos sumažina integracijos sudėtingumą, palyginti su atskirais FPGA?

Zynq SoC derina ARM procesorius ir programuojamą logiką viename įrenginyje, supaprastindama komunikaciją tarp programinės ir aparatinės įrangos spartinimo. Kria SOM dar labiau tobulina, integruodama atmintį, paleidimo saugyklą, energijos sekos valdymą ir patvirtintą aparatūrą į iš anksto kvalifikuotą modulį. Šie metodai sumažina riziką, susijusią su DDR maršrutizavimu, paleidimo patikimumu, energijos tiekimo dizainu ir plokštės paleidimu. Dėl to komandos gali labiau koncentruotis į programų elgseną ir mažiau į žemo lygio aparatūros integravimo iššūkius.

10. Kodėl sėkmingas FPGA pagrindu veikiančių AI diegimas labai priklauso nuo duomenų judėjimo, o ne vien tik nuo spartintuvo našumo?

AI spartintuvai, tokie kaip DPU, gali suteikti didelį teorinį skaičiavimo pralaidumą, tačiau realaus pasaulio našumą dažnai riboja atminties pralaidumas, DMA tvarkymas, buferių valdymas ir tenzorių judėjimo efektyvumas. Prastai optimizuoti duomenų kanalai gali bado spartintuvą ir dramatiškai sumažinti efektyvų FPS, nepaisant galingos skaičiavimo galimybės. Todėl sėkmingi FPGA AI sistemose daugiausia dėmesio skiriama dvigubam buferiavimui, DMA topologijai, grupavimo strategijai, atminties išdėstymui ir nuolatiniam duomenų srautui tarp jutiklių, DDR atminties, spartintuvų ir po apdorojimo etapų.