Bruk FPGA som snarvei til bygging av Edge AI-applikasjoner med høy ytelse og lavt energiforbruk

Av Stephen Evanczuk

Bidrag fra DigiKeys nordamerikanske redaktører

Designere som ønsker å implementere algoritmer for kunstig intelligens (AI) på inferensprosessorer på Edge-en (inngangspunktet), er under konstant press for å senke strømforbruket og utviklingstiden, selv når prosesseringskravene øker. Feltprogrammerbare portmatriser (Field-programmable gate arrays – FPGA) tilbyr en spesielt effektiv kombinasjon av hastighet og effekteffektivitet for å implementere inferensmotorene for nevrale nettverk (NN) som kreves for Edge AI. For utviklere som ikke er kjent med FPGA-er, kan konvensjonelle FPGA-utviklingsmetoder virke komplekse, noe som ofte får utviklere til å benytte seg av mindre optimale løsninger.

Denne artikkelen beskriver en enklere tilnærming fra Microchip Technology som lar utviklere omgå tradisjonell FPGA-utvikling for å opprette opplærte NN-er ved hjelp av FPGA-er og et programvareutviklingssett (Software Development Kit – SDK), eller bruke et FPGA-basert videosett for å gå umiddelbart over til utvikling av smarte integrerte maskinsynapplikasjoner.

Derfor brukes AI på Edge-en (inngangspunktet)?

Edge computing gir en rekke fordeler til IoT-applikasjoner (Internet of Things) i segmenter så varierte som industriell automatisering, sikkerhetssystemer, smarte hjem og mer. I en industriell IoT-applikasjon (IIoT) som retter seg mot fabrikkgulvet, kan kantdatabehandling dramatisk forbedre responstiden i prosesskontrollsløyfer ved å eliminere forsinkelser på tur-retur til skybaserte applikasjoner. På samme måte kan et Edge-basert sikkerhetssystem eller en smart hjemmedørslås fortsette å fungere selv når tilkoblingen til skyen går tapt ved et uhell eller med vilje. I mange tilfeller kan bruk av Edge computing i noen av disse applikasjonene bidra til å senke de samlede driftskostnadene ved å redusere produktets avhengighet av skyressurser. I stedet for å møte et uventet behov for ytterligere dyre skyressurser etter hvert som etterspørselen etter produktene deres øker, kan utviklere stole på lokale behandlingsmuligheter som er innebygd i produktene deres for å bidra til å opprettholde mer stabile driftsutgifter.

Den raske aksepten og økte etterspørselen etter maskinlæringsmodeller (ML-modeller) forsterker dramatisk viktigheten av Edge computing. For utviklere bidrar lokal behandling av inferensmodeller til å redusere responslatens (responsforsinkelse) og kostnader til skyressurser som kreves for skybasert inferens. For brukere øker bruken av lokale inferensmodeller tilliten til at produktene deres vil fortsette å fungere til tross for sporadisk tap av Internett-tilkobling eller endringer i produktleverandørens skybaserte tilbud. I tillegg kan bekymringer om sikkerhet og personvern ytterligere drive behovet for lokal behandling og inferens for å begrense mengden sensitiv informasjon som overføres til skyen over det offentlige Internett.

Å utvikle en NN-inferensmodell for maskinsynbasert objektdeteksjon er en flertrinnsprosess som starter med modellopplæring, vanligvis utført på et ML-rammeverk som TensorFlow ved hjelp av offentlig tilgjengelige merkede bilder eller tilpassede merkede bilder. På grunn av prosesseringskravene utføres modellopplæring vanligvis med grafikkprosesseringsenheter (GPU-er) i skyen eller en annen høyytende beregningsplattform. Etter at opplæringen er fullført, konverteres modellen til en inferensmodell som kan kjøre på Edge'n eller tåkedatabehandlingsressurser og levere inferensresultatene som et sett med objektklassesannsynligheter (figur 1).

Bilde av implementering av en inferensmodell for Edge AIFigur 1: Implementering av en inferensmodell for Edge AI ligger på slutten av en flertrinnsprosess som krever opplæring og optimalisering av NN-er på rammer ved hjelp av tilgjengelige eller tilpassede opplæringsdata. (Bildekilde: Microchip Technology)

Derfor er inferensmodeller beregningsmessig utfordrende

Selv om størrelsen og kompleksiteten er redusert sammenlignet med modellen som brukes under opplæringsprosessen, utgjør en NN-situasjonsmodell fortsatt en beregningsutfordring for prosessorer for generelle formål på grunn av det store antallet beregninger den krever. I sin generiske form omfatter en dyp Nn-modell, bestående av flere lag med nevron-sett. Innenfor hvert lag i et fullt tilkoblet nettverk må hvert nevron nij beregne summen av produkter for hver inngang med en tilhørende vekt wij (figur 2).

Skjema over antall beregninger som kreves for å konkludere med en NN (klikk for å forstørre)Figur 2: Antall beregninger som kreves for å utlede en NN, kan medføre en betydelig beregningsmessig arbeidsbelastning. (Bildekilde: Microchip Technology)

Ikke vist i figur 2 er det ekstra beregningskravet pålagt av aktiveringsfunksjonen som modifiserer utgangen av hvert nevron ved å tilordne negative verdier til null, tilordningsverdier større enn 1 til 1 og lignende funksjoner. Utgangen av aktiveringsfunksjonen for hvert nevron nij fungerer som inngangen til det neste laget i+1, og fortsetter på denne måten for hvert lag. Til slutt produserer utdatalaget i NN-modellen en utdatavektor som representerer sannsynligheten for at den opprinnelige inndatavektoren (eller matrisen) tilsvarer en av klassene (eller etikettene) som brukes under den overvåkede læringsprosessen.

Effektive NN-modeller er bygget med arkitekturer som er mye større og mer komplekse enn den representative generiske NN-arkitekturen som er vist ovenfor. En typisk konvolusjonell NN (CNN) som brukes til å detektere bildeobjekter, anvender for eksempel disse prinsippene på en stykkvis måte ved å skanne over bredden, høyden og fargedybden til et inndatabilde for å produsere en serie funksjonskart som til slutt gir vektoren for utdataforutsigelse (figur 3).

Skjema over CNN-er som brukes til å oppdage bildeobjekterFigur 3: CNN-er som brukes til bildeobjektdeteksjon involverer et stort antall nevroner i mange lag, noe som krever mer på beregningsplattformen. (Bildekilde: Aphex34 CC BY-SA 4.0)

Bruk av FPGA-er for å akselerere NN matte

Selv om en rekke alternativer fortsetter å dukke opp for å utføre inferensmodeller på kanten, er det få alternativer som gir en optimal blanding av fleksibilitet, ytelse og energieffektivitet som er nødvendig for praktisk høyhastighets inferens på Edge'n. Blant lett tilgjengelige alternativer for Edge AI er FPGA-er spesielt effektive fordi de kan gi høyytende maskinvarebasert utførelse av beregningsintensive operasjoner samtidig som de bruker relativt lite strøm.

Til tross for fordelene forbigås FPGA-er noen ganger på grunn av en tradisjonell utviklingsflyt som kan være skremmende for utviklere uten omfattende FPGA-erfaring. For å skape en effektiv FPGA-implementering av en NN-modell generert av et NN-rammeverk, må utvikleren forstå nyansene ved å konvertere modellen til registeroverføringsspråk (register transfer language – RTL), syntetisere utformingen og arbeide gjennom den endelige fysiske utformingsfasen for sted og rute for å produsere en optimalisert implementering (figur 4).

Skjema over å implementere en NN-modell på en FPGA (klikk for å forstørre)Figur 4: For å implementere en NN-modell på en FPGA, har utviklere til nå trengt å forstå hvordan de kan konvertere sine modeller til RTL og arbeide gjennom den tradisjonelle FPGA-flyten. (Bildekilde: Microchip Technology)

Med sine PolarFire FPGA-er, spesialisert programvare og tilhørende immaterielle rettigheter (IP), gir Microchip-teknologien en løsning som gjør høyytende, laveffekt-inferens på Edge'n bredt tilgjengelig for utviklere uten FPGA-erfaring.

PolarFire-FPGA-ene er produsert i en avansert ikke-flyktig prosessteknologi, og er designet for å maksimere fleksibilitet og ytelse samtidig som strømforbruket minimeres. Sammen med et omfattende utvalg av høyhastighetsgrensesnitt for kommunikasjon og inndata/utdata (I/O), har de et dypt FPGA-struktur som kan støtte avansert funksjonalitet ved hjelp av myke IP-kjerner, inkludert RISC-V-prosessorer, avanserte minnestyringer og andre undersystemer med standardgrensesnitt (figur 5).

Skjema over Microchip teknologier og PolarFire-er (klikk på for å forstørre)Figur 5: Microchip-teknologien PolarFire-arkitekturen gir en dypt struktur, designet for å støtte designkrav for høyytelse, inkludert dataintensiv inferensmodellimplementering. (Bildekilde: Microchip Technology)

PolarFire FPGA-strukturen gir et omfattende sett med logiske elementer og spesialiserte blokker, støttet i en rekke kapasiteter av forskjellige medlemmer av PolarFire FPGA-familien, inkludert MPF100T, MPF200T, MPF300T og MPF500T-serien (tabell 1).

FPGA-strukturfunksjoner MPF100T MPF200T MPF300T MPF500T
Logiske elementer som hver omfatter en 4-variablers oppslagstabell (lookup table – LUT) med en D-type flipflop (DFF) 109 000 192 000 300 000 481 000
Matematikkblokker med 18 x 18 MAC-blokker (multiplisere-akkumulere) 336 588 924 1480
20 kilobit (Kbit) store statiske LSRAM-blokker (large static random access memory) 352 616 952 1520
Liten (64 ord x 12 biter) distribuert mikro-SRAM (distributed micro static random access memory) 1008 1764 2772 4440
Totalt RAM-minne (random access memory) 7,6 Mbit 13,3 Mbit 20,6 Mbit 33,0 Mbit
µPROM (Micro programmable read-only memory) 297 Mbit 297 Mbit 459 Mbit 513 Mbit
PLL-er (phase-lock loops) og DLL-er (delay-lock loops) 8 8 8 8

Tabell 1: En rekke FPGA-strukturfunksjoner og kapasiteter er tilgjengelige i PolarFire-serien. (Tabellkilde: DigiKey, basert på Microchip Technology PolarFire datablad)

Blant funksjonene av spesiell interesse for inferensakselerasjon, inkluderer PolarFire-arkitekturen en dedikert matematikkblokk som gir en 18 × 18-bits signert MAC-funksjon (multiplisere-akkumulere) med en pre-adderer. En innebygd punktproduktmodus bruker en enkelt matteblokk til å utføre to 8-bits multiplikasjonsoperasjoner, noe som gir en mekanisme for å øke kapasiteten ved å utnytte den ubetydelige virkningen av modellkvantisering på nøyaktigheten.

I tillegg til å akselerere de matematiske operasjonene, bidrar PolarFire-arkitekturen til å lindre den typen minneoverbelastning som oppstår ved implementering av inferensmodeller på generelle formålsarkitekturer, for eksempel små distribuerte minner for lagring av mellomliggende resultater opprettet under utførelse av NN-algoritmer. En NN-modell sine vekter og biasverdier kan også lagres i et skrivebeskyttet 16-bits og 18-bits koeffisientminne (ROM) bygget av logiske elementer i nærheten av matteblokken.

Sammen med andre PolarFire FPGA-strukturfunksjoner, danner matteblokker grunnlaget for CoreVectorBlox-IP på høyere nivå fra Microchip Technology. Dette fungerer som en fleksibel NN-motor som kan utføre forskjellige typer NN-er. Sammen med et sett kontrollregistre inkluderer CoreVectorBlox IP tre viktige funksjonsblokker:

  • Mikrokontroller: En enkel RISC-V-myk prosessor som leser Microchips firmware-BLOB (binary large object) og brukerens spesifikke NN-blokkfil fra ekstern lagring. Den kontrollerer overordnede CoreVectorBlox-operasjoner ved å utføre instruksjoner fra firmware BLOB-en.
  • Matriseprosessor (Matrix processor – MXP): Myk prosessor som omfatter åtte 32-biters aritmetiske logiske enheter (ALU) og er utformet for å utføre parallelle operasjoner på datavektorer ved hjelp av elementære tensoroperasjoner, inkludert add, sub, xor, shift, mul, dotprod og andre, ved hjelp av blandet 8-bits, 16-bits og 32-bits presisjon, etter behov.
  • CNN-akselerator: Akselererer MXP-operasjoner ved hjelp av en todimensjonal matrise av MAC-funksjoner implementert ved hjelp av matteblokker og drift med 8-bits presisjon.

Et komplett NN-behandlingssystem vil kombinere en CoreVectorBlox IP-blokk, minne, minnekontroller og en vertsprosessor, for eksempel Microsoft RISC-V (Mi-V) -prosessorkjerne (figur 6).

Skjema over Microchip CoreVectorBlox IP-blokk (klikk for å forstørre)Figur 6: CoreVectorBlox IP-blokk fungerer med en vertsprosessor som Microchips Mi-V RISC-V-mikrokontroller for å implementere en NN-inferensmodell. (Bildekilde: Microchip Technology)

I en videosystemimplementering vil vertsprosessoren laste inn firmware- og nettverks-BLOB-er fra systemflashminnet og kopiere dem til DDR-RAM-minne (double data rate random access memory) for bruk av CoreVectorBlox-blokken. Når videorammer kommer, skriver vertsprosessoren dem inn i DDR-RAM og signaliserer CoreVectorBlox-blokken for å begynne å behandle bildet. Etter at den kjører inferensmodellen definert i nettverks-BLOB-en, skriver CoreVectorBlox-blokken resultatene, inkludert bildeklassifisering, tilbake til DDR-RAM for bruk av målapplikasjonen.

Utviklingsflyt forenkler NN FPGA-implementering

Microchip beskytter utviklere mot kompleksiteten ved å implementere en NN-situasjonsmodell på PolarFire FPGA-er. I stedet for å håndtere detaljene i den tradisjonelle FPGA-flyten, arbeider NN-modellutviklere med sine NN-rammer som vanlig og laster den resulterende modellen inn i Microchip Technologys VectorBlox Accelerator Software Development Kit (SDK). SDK genererer det nødvendige settet med filer, inkludert de som er nødvendige for den normale FPGA-utviklingsflyten og firmware- og nettverks-BLOB-filene nevnt tidligere (figur 7).

Skjema over Microchip VectorBlox Accelerator SDK (klikk for å forstørre)Figur 7: VectorBlox Accelerator SDK administrerer detaljene i å implementere en NN-modell på en FPGA, og genererer automatisk filer som er nødvendige for å designe og kjøre den FPGA-baserte inferensmodellen. (Bildekilde: Microchip Technology)

Fordi VectorBlox Accelerator SDK-flyten legger NN-designen over på NN-motoren implementert i FPGA, kan forskjellige NN-er kjøre på samme FPGA-design uten å måtte gjøre om FPGA-designsyntesestrømmen. Utviklere oppretter kode i C/C++ for det resulterende systemet og er i stand til å bytte modeller i systemet i farten eller kjøre modeller samtidig ved hjelp av tidsdeling.

VectorBlox Accelerator SDK kombinerer Microchip Technology Libero FPGA-designpakken med et omfattende sett med funksjoner for utvikling av NN-situasjonsmodeller. Sammen med modelloptimaliserings-, kvantiserings- og kalibreringstjenester tilbyr SDK en NN-simulator som lar utviklere bruke de samme BLOKKFILENE til å evaluere modellen før de brukes i FPGA-maskinvareimplementeringen (figur 8).

Skjema over Microchip VectorBlox Accelerator SDK-tjenesteneFigur 8: VectorBlox Accelerator SDK gir et omfattende sett med tjenester designet for å optimalisere FPGA-implementering av rammegenererte inferensmodeller. (Bildekilde: Microchip Technology)

VectorBlox Accelerator SDK støtter modeller i Open Neural Network Exchange (ONNX) -format samt modeller fra en rekke rammer, inkludert TensorFlow, Caffe, Chainer, PyTorch og MXNET. Støttede CNN-arkitekturer inkluderer MNIST, MobileNet-versjoner, ResNet-50, Tiny Yolo V2 og Tiny Yolo V3. Microchip jobber med å utvide støtten til å inkludere de fleste nettverk i OpenVINO-verktøykassen med åpen modell av forhåndstrente modeller, inkludert Yolo V3, Yolo V4, RetinaNet og SSD-MobileNet, blant mange andre.

Videosett demonstrerer FPGAs inferens

For å hjelpe utviklere med å gå raskt over til utvikling av smarte innebygde maskinsynapplikasjoner, gir Microchip Technology et omfattende prøveprogram utviklet for å kjøre på selskapets MPF300-VIDEO-KIT PolarFire FPGA Video and Imaging Kit og referansedesign.

Basert på Microchip MPF300T PolarFire FPGA kombinerer settets kort en dobbel kamerasensor, dobbel datahastighet 4 (DDR4) RAM, flashminne, strømstyring og en rekke forskjellige tilkoblinger (figur 9).

Bilde av Microchip MPF300-VIDEO-KIT PolarFire FPGA Video and Imaging KitFigur 9: MPF300-VIDEO-KIT PolarFire FPGA Video and Imaging Kit og tilhørende programvare gir utviklere en rask start på FPGA-basert inferens i smarte innebygde maskinsynapplikasjoner. (Bildekilde: Microchip Technology)

Settet leveres med et komplett Libero-designprosjekt som brukes til å generere firmware- og nettverks-BLOB-filene. Etter å ha programmert BLOB-filene inn i hurtigminnet om bord, klikker utviklerne på kjøreknappen i Libero for å starte demonstrasjonen, som behandler videobilder fra kamerasensoren og viser slutningsresultater på en skjerm (figur 10).

Skjema over Microchip Technology PolarFire FPGA Video and Imaging Kit (klikk på for å forstørre)Figur 10: Microchip-teknologien PolarFire FPGA Video and Imaging Kit demonstrerer hvordan du designer og bruker en FPGA-implementering av et smart innebygd maskinsynsystem bygget rundt Microchip CoreVectorBlox NN-motoren. (Bildekilde: Microchip Technology)

For hver inndatavideoramme utfører det FPGA-baserte systemet følgende trinn (med trinntall som stemmer overens med figur 10):

  1. Last inn en ramme fra kameraet
  2. Lagre rammen i RAM
  3. Les rammen fra RAM
  4. Konverter det rå bildet til RGB, flat-RGB og lagrer resultatet i RAM
  5. Mi-V myk RISC-V-prosessor starter CoreVectorBlox-motoren, som henter bildet fra RAM, utfører inferens og lagrer klassifiseringssannsynlighetsresultatene tilbake til RAM
  6. Mi-V bruker resultatene til å opprette en overleggsramme med grensebokser, klassifiseringsresultater og andre metadata og lagrer rammen i RAM
  7. Den opprinnelige rammen blandes med overleggsrammen og skrives til HDMI-skjermen

Demonstrasjonen støtter akselerasjon av Tiny Yolo V3- og MobileNet V2-modeller, men utviklere kan kjøre andre SDK-støttede modeller ved hjelp av metodene beskrevet tidligere ved å gjøre en liten kodeendring for å legge til modellnavnet og metadata til den eksisterende listen som inneholder de to standardmodellene.

Konklusjon

AI-algoritmer som NN-modeller pålegger vanligvis beregningsintensive arbeidsbelastninger som krever mer robuste beregningsressurser enn tilgjengelige med prosessorer for generelle formål. Mens FPGA-er er godt utstyrt for å oppfylle ytelseskravene og kravene til lav effekt ved utførelse av inferensmodeller, kan konvensjonelle FPGA-utviklingsmetoder virke komplekse, noe som ofte får utviklere til å benytte seg av suboptimale løsninger.

Som vist, ved hjelp av spesialisert IP og programvare fra Microchip Technology, kan utviklere uten FPGA-erfaring implementere inference-baserte design bedre i stand til å oppfylle krav til ytelse, strøm og designtidsplan.

DigiKey logo

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of DigiKey or official policies of DigiKey.

Om skribenten

Image of Stephen Evanczuk

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

Om denne utgiveren

DigiKeys nordamerikanske redaktører