Højtbetalende tip til FPGA-ingeniører, der tjener 700 årligt

For FPGA-ingeniører, der ønsker at tjene en høj løn, er der flere nøglestrategier at overveje. Først og fremmest er det afgørende at finpudse dine færdigheder inden for FPGA-design og -udvikling. At blive ekspert i sprog som Verilog og VHDL, samt at beherske FPGA-udviklingsværktøjer og -platforme, vil gøre dig til et værdifuldt aktiv på området.

Det er mere end ti år siden, jeg første gang kom i kontakt med FPGA på min universitetstid. Jeg husker stadig spændingen ved at gennemføre eksperimenter såsom digitale stopure, quiz-brummere og adgangskodelåse på EDA-platformen for første gang. På det tidspunkt havde jeg endnu ikke været udsat for HDL-hardwarebeskrivelsessprog, så designerne blev bygget ved hjælp af 74-seriens logiske enheder i MAX+plus II skematiske miljø. Senere, under mine postgraduate studier og efterfølgende arbejde, brugte jeg Quartus II, Foundation, ISE og Libero og lærte også Verilog HDL-sproget. Gennem denne læringsproces satte jeg gradvist pris på Verilogs klogskab. Jeg indså, at et lille stykke kode kunne fuldende komplekse skematiske designs, og sprogets portabilitet og funktionalitet var meget stærkere end skematiske designs.

Vigtigheden af ​​standarder i FPGA Logic Design

Venner, der har arbejdet i branchen, ved, at virksomheder lægger vægt på standarder, især for store designs (uanset om det er software eller hardware). Det er næsten umuligt at opnå uden at følge standarderne. Logisk design er ingen undtagelse: Hvis du ikke følger standarderne, kan du finde fejl ved fejlfinding en måned senere. Når du ser tilbage på den kode du skrev, har du måske glemt mange signalfunktioner, endsige fejlkontrol. Hvis nogen går halvvejs i et projekt, skal efterfølgeren formentlig starte designet fra bunden. Hvis du har brug for at tilføje nye funktioner til den originale version, bliver du højst sandsynligt nødt til at starte forfra, hvilket gør det svært at opnå designgenanvendelighed.

Med hensyn til logik tror jeg, at følgende standarder er vigtige:

1. Design dokumentation: Designideer, detaljerede implementeringer osv. bør skrives ind i dokumenter, og først efter streng gennemgang og godkendelse kan næste trin i arbejdet udføres. Denne tilgang kan holde projektet i en kontrollerbar og opnåelig tilstand.
2. Kodestandardisering: Standardiser signalnavngivning, brug små bogstaver til signalnavne og store bogstaver til parametre, markér effektive signaler på lavt niveau med _n i slutningen (f.eks. rst_n), og arrangere portsignaler med et signal pr. linje for lettere fejldetektion i simuleringsverifikation.
3. Domænestyring af ur: Brug kun ét ur for hvert modul, og brug et dedikeret modul til urdomæneisolering i design, der involverer flere clockdomæner for at give synthesizeren mulighed for at syntetisere et mere optimalt resultat.
4. Undgå kombinatorisk logik for låse: I FPGA-design er det forbudt at bruge ren kombinatorisk logik til at generere latches. Låse med D flip-flops er tilladt, såsom konfigurationsregistre.
5. Signalsynkronisering: Generelt skal signaler, der kommer ind i FPGA'en, synkroniseres først for at øge systemets arbejdsfrekvens.
6. Registrer alle udgange: Alle moduludgange skal registreres for at øge arbejdsfrekvensen og opnå timingkonvergens i designet.
7. Undgå lukkede ure: Medmindre det er et laveffekt design, brug ikke gated ure, da dette vil øge designets ustabilitet.
8. Uraktiveringssignaler: Det er forbudt at bruge signaler divideret med tællere som ure for andre moduler. Brug i stedet uraktiveringssignaler.

Timing Design for høj ydeevne

Min chef har en baggrund som arbejde hos Huawei og Junlong, så naturligvis fortalte han os om nogle logiske designpraksis hos Huawei og Altera. Vores projektstandarder er grundlæggende baseret på praksis hos Huawei. I de sidste par måneders arbejde var det dybeste indtryk på mig talemåden hos Huawei: timing er designet, ikke simuleret eller opdigtet. I vores virksomhed gennemgår hvert projekt en streng gennemgang. Først efter gennemgangen er bestået, kan næste trin i arbejdet udføres. Tager vi logisk design som eksempel, i stedet for at begynde at skrive kode med det samme, skal vi først skrive den overordnede designplan og detaljerede logikdesignplan. Efter at disse planer er gennemgået og anset for gennemførlige, kan kodningen begynde. Generelt set er tiden brugt på disse opgaver meget større end tiden brugt på kodning.

Den overordnede plan involverer hovedsageligt modulopdeling, interfacesignaler og timing af moduler på første niveau og andet niveau, og hvordan man tester designet i fremtiden. I dette planniveau er det vigtigt at sikre, at timingen konvergerer til modulet på første niveau (og endelig til modulet på andet niveau). Hvad betyder det? Når vi laver detaljeret design, vil vi helt sikkert foretage nogle justeringer af timingen af ​​nogle signaler. Disse timingjusteringer kan dog højst påvirke modulet på første niveau, ikke hele designet. Jeg kan huske, da jeg gik i skole, fordi jeg ikke forstod timing design, jeg var ofte nødt til at justere timingen af ​​andre modulsignaler, fordi et signals timing ikke blev overholdt, hvilket var meget frustrerende.

I den detaljerede logikdesignplan har vi allerede designet grænsefladetimingen for hvert niveau af moduler, og hvordan hvert niveau af moduler implementeres er grundlæggende bestemt. Fordi vi har opnået dette, bliver kodning naturligvis hurtigere. Vigtigst af alt kan denne tilgang holde designet i en kontrollerbar tilstand og forhindre behovet for at starte hele designet forfra på grund af fejl ét sted.

Hvad er de faktorer, der påvirker et kredsløbs driftsfrekvens?

Kredsløbets arbejdsfrekvens er hovedsageligt relateret til signaludbredelsesforsinkelsen mellem registre og urskævhed. Hvis uret i FPGA'en kører langs lange linjer, er urskævheden meget lille og kan ignoreres. Her tages der for nemheds skyld kun hensyn til de faktorer, der påvirker signaludbredelsesforsinkelsen. Signaludbredelsesforsinkelsen inkluderer åbnings- og lukningsforsinkelsen af ​​registeret, routingforsinkelsen og forsinkelsen gennem den kombinatoriske logik. For at øge kredsløbets arbejdsfrekvens skal vi arbejde på disse tre forsinkelser og gøre dem så små som muligt.

1. Reducer forsinkelse ved at ændre rute: Angiv ruten for nogle vigtige signaler, såsom ure og kontrolsignaler, for at få dem til at passere gennem FPGA så lidt som muligt. Dette kan effektivt reducere routingforsinkelsen.
2. Reducer antallet af kombinatorisk logik: Brug opslagstabeller (LUT) så meget som muligt i stedet for logiske porte. Derudover bruger nogle mennesker kaskaderegistrerede til at reducere antallet af porte, men den bedste måde er at bruge pipelining til at reducere antallet af porte.

Samlet set er reduktion af antallet af gates og ændring af routing effektive måder at øge kredsløbets arbejdsfrekvens på. I det faktiske design er det ofte en kombination af begge dele. Dette er dog ikke absolut. I nogle tilfælde reducerer ændring af routing muligvis ikke forsinkelsen, og den mest effektive måde er at reducere antallet af gates.

Udfordringerne ved logisk design: Systemarkitektur og simuleringsverifikation

Da jeg først kom til virksomheden, fortalte min chef mig, at vanskeligheden ved logisk design ikke ligger i design af kode på RTL-niveau, men i systemarkitekturdesign og simuleringsverifikation. I øjeblikket er der i Kina mere vægt på syntetiserbare designs, men der synes ikke at være meget information om systemarkitekturdesign og simuleringsverifikation, hvilket kan afspejle det relativt lave niveau af design i Kina.

Da jeg gik i skole, troede jeg altid, at så længe koden på RTL-niveau blev udført godt, var simuleringsbekræftelse kun en formalitet, så jeg ignorerede foragtende syntaksen i HDL-adfærdsbeskrivelsen og var tilbageholdende med at lære om testbenches – fordi jeg troede at tegne bølgeformer var praktisk; Jeg vidste intet om systemarkitekturdesign. Det var først, da jeg stødte på nogle ting i virksomheden, at jeg indså, at det var helt anderledes.

Faktisk er den tid og arbejdskraft, der bruges på simuleringsverifikation, i udlandet sandsynligvis det dobbelte af, hvad der bruges på kode på RTL-niveau. Nu er simuleringsverifikation den kritiske vej til at designe million-gate-chips.

Simuleringsverifikation: Modellering og automatisering

Vanskeligheden ved simuleringsverifikation ligger hovedsageligt i, hvordan man modellerer for fuldstændigt og præcist at verificere rigtigheden af ​​designet (hovedsageligt for at øge kodedækningen). I denne proces er verifikationshastigheden også vigtig.

Verifikation er i enkle vendinger, hvordan man genererer tilstrækkelig dækning af stimuluskilder og derefter opdager fejl. Personligt tror jeg, at i simuleringsverifikation er det mest basale at opnå automatisering af verifikation. Det er også derfor, vi skal skrive testbenches. I et af mine nuværende designs tager det omkring en time for hver simuleringskørsel (som faktisk er et lille design). Da tegning af bølgeformer ikke kan opnå verifikationsautomatisering, hvis vi simulerer ved at tegne bølgeformer, vil bølgeformen for det første blive trukket ihjel (især for design med komplekse algoritmer og input statistisk fordeling), for det andet vil det at se på bølgeformen være dødbringende, og for det tredje er fejldetektionsraten næsten nul. Så hvordan opnår man automatisering? Mit niveau er stadig meget begrænset, så jeg kan kun kort tale om BFM (busfunktionsmodel).

Tager vi eksemplet med at lave en MAC-kerne (bagplanet er PCI-bussen), har vi brug for en MAC_BFM, PCI_BFM og PCI_BM (PCI-adfærdsmodel). Hovedfunktionen af ​​MAC_BFM er at generere Ethernet-rammer (stimulus-kilder), med tilfældige længder og frame-headers, og indholdet er også tilfældigt. Mens den sender, kopierer den det også til PCI_BM; funktionen af ​​PCI_BFM er at simulere adfærden af ​​PCI-bussen, for eksempel, når enheden under test modtager en korrekt ramme, vil den sende en anmodning til PCI-bussen, og PCI_BFM vil svare på den og bringe dataene ind; PCI_BMs hovedfunktion er at sammenligne, hvad MAC_BFM sender ud med, hvad PCI_BFM modtager. Da den har afsendelsesinformationen fra MAC_BFM og modtageinformationen fra PCI_BFM, så længe designet er rimelig, kan den altid automatisk og fuldstændig teste, om enheden under test fungerer normalt, og dermed opnå automatisk detektion.

Det vurderes, at Huawei klarer sig relativt godt i simuleringsverifikation i Kina. De har etableret en forholdsvis god verifikationsplatform, og det meste af BFM relateret til kommunikation er veludført. Jeg hørte fra min ven, at de nu kun skal sætte enheden under test i testplatformen og konfigurere parametrene til automatisk at detektere, om enheden, der testes, fungerer korrekt.

Sproglige overvejelser

Med hensyn til HDL-sprog skændes mange mennesker i Kina om, hvad der er bedst mellem VHDL og Verilog. Faktisk synes jeg personligt, at dette ikke er særlig meningsfuldt. De fleste store virksomheder udenfor bruger grundlæggende Verilog til kode på RTL-niveau, så jeg anbefaler stadig alle at lære Verilog så meget som muligt. Med hensyn til simulering, fordi VHDL er svagere end Verilog i adfærdsmodellering, er der meget få simuleringsmodeller udført med VHDL. Selvfølgelig er Verilog heller ikke perfekt. Faktisk er Verilogs evne til kompleks adfærdsmodellering også begrænset. For eksempel understøtter den endnu ikke arrays. I nogle komplekse algoritmedesign er der behov for sprog på højt niveau til abstraktion for at beskrive adfærdsmodeller. I udlandet udføres mange simuleringsmodeller ved hjælp af SystemC og E sprog, og brug af Verilog anses for at være forældet. Huaweis verifikationsplatform i Kina ser ud til at være skrevet i SystemC.

Fremtidsperspektiver

Med hensyn til systemarkitekturdesign, fordi det design, jeg arbejder på, ikke er stort nok, har jeg ikke meget erfaring endnu. Jeg føler bare, at jeg skal have en vis viden om computersystemarkitektur. Det primære grundlag for opdeling er funktionalitet, efterfulgt af valg af passende busstruktur, lagerstruktur og processorarkitektur. Opdelingen af ​​systemarkitektur bør gøre hvert funktionsmodul overskueligt og nemt at implementere. Jeg tror, ​​jeg vil dele nogle indsigter, når jeg har lidt erfaring med denne del om et stykke tid, så jeg vil ikke vildlede dig lige nu.

Personlig indsigt

Lad mig til sidst kort opsummere. Det hele kommer ned til mere øvelse, mere tænkning og mere spørgsmål. Øvelse gør mester. Det er bedre at øve sig i det selv end at læse andres løsninger hundrede gange. Motivationen for praksis kommer dels fra interesse og dels fra pres. Jeg synes personligt, at det sidste er vigtigere. At have krav vil nemt skabe pres, det vil sige, at det er bedst at øve sig i egentlig projektudvikling frem for at studere for studiets skyld.

I øvelsesprocessen bør du tænke mere og tænke over årsagerne til problemerne. Efter at have løst problemerne, spørg hvorfor et par gange mere. Dette er også en proces med akkumulering af erfaringer. Hvis du har for vane at skrive projektlogfiler, er det endnu bedre. Skriv ned de problemer, årsager, løsninger og metoder, der er løst i den. Stil endelig flere spørgsmål. Hvis du ikke kan løse et problem efter at have tænkt over det, så spørg. De individuelle muligheder er trods alt begrænsede. Spørg klassekammerater, kolleger, søgemaskiner og netbrugere. En artikel eller venners vejledning kan hjælpe dig med at løse problemer hurtigt.

Konklusion

Efter funktionel simulering, da vi designer i FPGA, er RTL-niveaukoden grundlæggende garanteret at være i overensstemmelse med synteseresultatet og det funktionelle simuleringsresultat under design. Så længe den statiske timingrapport efter synteselayout ikke advares mod at overtræde timingbegrænsningerne, kan vi fortsætte med at fejlsøge på tavlen. Faktisk laver de hos Huawei og ZTE heller ikke timingsimulering, når de designer FPGA, fordi timingsimulering tager meget tid, og effekten ikke nødvendigvis er bedre end at se på den statiske timinganalyserapport.

Selvfølgelig, hvis det er ASIC-design, er arbejdsbyrden ved simuleringsverifikation større. Når det involverer multi-clock domænedesign, udføres postsimulering generelt. Men før der udføres post-simulering, bruges formelle verifikationsværktøjer normalt, og den statiske timinganalyserapport bruges til at kontrollere for eventuelle overtrædelser af designkrav. Efter at have gjort dette, kan arbejdsbyrden ved postsimulering være meget mindre.

Hvis dette krav påvirker sourcing eller produktionsfrigivelse, skal det sammenlignes med sourcing af elektroniske komponenter og sammenligning af overfladefinish inden de endelige filer sendes til gennemgang.