Korkeapalkkaisia ​​vinkkejä FPGA-insinööreille, jotka ansaitsevat 700 XNUMX vuodessa

FPGA-insinööreille, jotka haluavat ansaita korkeaa palkkaa, on harkittava useita keskeisiä strategioita. Ensinnäkin FPGA-suunnittelun ja -kehityksen taitosi hiominen on ratkaisevan tärkeää. Verilogin ja VHDL:n kaltaisten kielten asiantuntijaksi tuleminen sekä FPGA-kehitystyökalujen ja -alustojen hallitseminen tekee sinusta arvokkaan voimavaran alalla.

Siitä on yli kymmenen vuotta, kun olin ensimmäistä kertaa kosketuksissa FPGA:n kanssa yliopistopäivieni aikana. Muistan vieläkin jännityksen, joka oli saatu aikaan kokeiden, kuten digitaalisten sekuntikellojen, tietokilpailusummerien ja salasanalukkojen suorittamisessa EDA-alustalla ensimmäistä kertaa. Tuolloin en ollut vielä tutustunut HDL-laitteiston kuvauskieliin, joten suunnitelmat tehtiin 74-sarjan logiikkalaitteilla MAX+plus II -kaavioympäristössä. Myöhemmin jatko-opintojeni ja myöhempien töiden aikana käytin Quartus II:ta, Foundationia, ISE:tä ja Liberoa ja opin myös Verilog HDL -kielen. Tämän oppimisprosessin kautta arvostin vähitellen Verilogin älykkyyttä. Ymmärsin, että pieni koodinpätkä voisi täydentää monimutkaisia ​​kaavamaisia ​​suunnitelmia, ja kielen siirrettävyys ja käytettävyys olivat paljon vahvempia kuin kaaviomaiset.

Standardien merkitys FPGA-logiikkasuunnittelussa

Alalla työskennelleet ystävät tietävät, että yritykset korostavat standardeja, erityisesti suurissa suunnitelmissa (oli sitten ohjelmisto tai laitteisto). Se on lähes mahdotonta saavuttaa noudattamatta standardeja. Logiikkasuunnittelu ei ole poikkeus: jos et noudata standardeja, saatat löytää virheitä virheenkorjauksessa kuukauden kuluttua. Kun katsot kirjoittamaasi koodia, olet saattanut unohtaa monia signaalitoimintoja, saati virheentarkistuksen. Jos joku lähtee projektin puolivälissä, seuraajan on todennäköisesti aloitettava suunnittelu tyhjästä. Jos alkuperäiseen versioon on lisättävä uusia ominaisuuksia, joudut todennäköisesti aloittamaan alusta, jolloin suunnittelun uudelleenkäytettävyyden saavuttaminen on vaikeaa.

Logiikan kannalta seuraavat standardit ovat mielestäni tärkeitä:

1. Suunnittelun dokumentaatio: Suunnitteluideat, yksityiskohtaiset toteutukset jne. tulee kirjoittaa asiakirjoihin, ja vasta tarkan tarkastelun ja hyväksynnän jälkeen voidaan tehdä seuraava työvaihe. Tämä lähestymistapa voi pitää projektin hallittavissa ja saavutettavissa olevassa tilassa.
2. Koodin standardointi: Standardoi signaalien nimeäminen, käytä pieniä kirjaimia signaalien nimissä ja isoja parametreissa, merkitse matalan tason tehokkaat signaalit _n lopussa (esim. rst_n) ja järjestä porttisignaalit yhdellä signaalilla linjaa kohti helpottaaksesi virheiden havaitsemista simulaatiotarkistuksessa.
3. Kellon verkkotunnuksen hallinta: Käytä vain yhtä kelloa kullekin moduulille ja käytä erillistä moduulia kelloalueen eristämiseen malleissa, joissa on useita kelloalueita, jotta syntetisaattori voi syntetisoida optimaalisemman tuloksen.
4. Vältä salpojen kombinatorista logiikkaa: FPGA-malleissa on kiellettyä käyttää puhdasta kombinatorista logiikkaa salpojen luomiseen. Salvat, joissa on D-kiikut, ovat sallittuja, kuten konfigurointirekisterit.
5. Signaalin synkronointi: Yleensä FPGA:han tulevat signaalit on ensin synkronoitava järjestelmän toimintataajuuden lisäämiseksi.
6. Rekisteröi kaikki lähdöt: Kaikki moduulin lähdöt tulee rekisteröidä työtaajuuden lisäämiseksi ja ajoituksen konvergenssin saavuttamiseksi suunnittelussa.
7. Vältä aidattuja kelloja: Ellei kyseessä ole vähän virtaa kuluttava malli, älä käytä aidattuja kelloja, koska tämä lisää suunnittelun epävakautta.
8. Kellon käyttöönoton signaalit: On kiellettyä käyttää laskureilla jaettuja signaaleja muiden moduulien kellona. Käytä sen sijaan kellon aktivointisignaaleja.

Ajoitussuunnittelu korkealle suorituskyvylle

Esimieheni on työskennellyt Huaweilla ja Junlongilla, joten luonnollisesti hän kertoi meille joistakin Huawein ja Alteran logiikan suunnittelukäytännöistä. Projektistandardimme perustuvat pohjimmiltaan Huawein käytäntöihin. Viime kuukausina työskennellessäni syvän vaikutuksen minuun teki Huawein sanonta: ajoitus on suunniteltu, ei simuloitu tai keksitty. Yrityksessämme jokainen projekti käy läpi tiukan tarkastuksen. Vasta tarkastelun jälkeen voidaan tehdä seuraava työvaihe. Esimerkkinä logiikkasuunnittelusta, sen sijaan, että aloitamme heti koodin kirjoittamisen, meidän on ensin kirjoitettava yleinen suunnittelusuunnitelma ja yksityiskohtainen logiikkasuunnittelusuunnitelma. Kun nämä suunnitelmat on tarkistettu ja todettu toteuttamiskelpoisiksi, koodaus voi alkaa. Yleisesti ottaen näihin tehtäviin käytetty aika on paljon enemmän kuin koodaukseen käytetty aika.

Kokonaissuunnitelmaan kuuluu pääasiassa moduulijako, liitäntäsignaalit ja ensimmäisen ja toisen tason moduulien ajoitus sekä suunnittelun testaus tulevaisuudessa. Tällä suunnitelmatasolla on tärkeää varmistaa, että ajoitus konvergoi ensimmäisen tason moduuliin (ja lopuksi toisen tason moduuliin). Mitä tämä tarkoittaa? Kun teemme yksityiskohtaista suunnittelua, teemme varmasti joitain muutoksia joidenkin signaalien ajoitukseen. Nämä ajoitussäädöt voivat kuitenkin vaikuttaa korkeintaan ensimmäisen tason moduuliin, eivät koko suunnitteluun. Muistan, kun olin koulussa, koska en ymmärtänyt ajoitussuunnittelua, jouduin usein säätämään muiden moduulien signaalien ajoitusta, koska yhden signaalin ajoitus ei täyttynyt, mikä oli erittäin turhauttavaa.

Yksityiskohtaisessa logiikkasuunnittelusuunnitelmassa olemme jo suunnitelleet kunkin moduulitason rajapinta-ajoituksen ja periaatteessa määräytyy kunkin tason moduulien toteutus. Koska olemme saavuttaneet tämän, koodauksesta tulee luonnollisesti nopeampaa. Mikä tärkeintä, tämä lähestymistapa voi pitää suunnittelun hallittavassa tilassa ja estää koko suunnittelun aloittamisen alusta virheiden vuoksi yhdestä paikasta.

Mitkä tekijät vaikuttavat piirin toimintataajuuteen?

Piirin toimintataajuus liittyy pääasiassa signaalin etenemisviiveeseen rekisterien välillä ja kellon vinoon. Jos FPGA:n kello kulkee pitkiä linjoja, kellon vinouma on hyvin pieni ja voidaan jättää huomiotta. Tässä otetaan yksinkertaisuuden vuoksi huomioon vain signaalin etenemisviiveeseen vaikuttavat tekijät. Signaalin etenemisviive sisältää rekisterin avautumis- ja sulkemisviiveen, reititysviiveen sekä kombinatorisen logiikan kautta tapahtuvan viiveen. Piirin toimintataajuuden lisäämiseksi meidän on työstettävä näitä kolmea viivettä ja tehtävä niistä mahdollisimman pieniä.

1. Vähennä viivettä muuttamalla reititystä: Määritä joidenkin tärkeiden signaalien, kuten kellojen ja ohjaussignaalien, reititys, jotta ne kulkevat FPGA mahdollisimman vähän. Tämä voi tehokkaasti vähentää reititysviivettä.
2. Vähennä kombinatorisen logiikan määrää: Käytä hakutaulukoita (LUT) mahdollisimman paljon logiikkaporttien sijaan. Lisäksi jotkut ihmiset käyttävät peräkkäisiä rekistereitä vähentääkseen porttien määrää, mutta paras tapa on käyttää liukuhihnaa porttien määrän vähentämiseen.

Kaiken kaikkiaan porttien määrän vähentäminen ja reitityksen muuttaminen ovat tehokkaita tapoja lisätä piirin toimintataajuutta. Käytännössä kyse on usein molempien yhdistelmästä. Tämä ei kuitenkaan ole ehdotonta. Joissakin tapauksissa reitityksen muuttaminen ei välttämättä vähennä viivettä, ja tehokkain tapa on vähentää porttien määrää.

Logiikkasuunnittelun haasteet: Järjestelmäarkkitehtuuri ja simulaatioiden todentaminen

Ensimmäistä kertaa yritykseen tullessani pomoni kertoi minulle, että logiikkasuunnittelun vaikeus ei ole RTL-tason koodin suunnittelussa, vaan järjestelmäarkkitehtuurin suunnittelussa ja simulaation verifioinnissa. Tällä hetkellä Kiinassa painotetaan enemmän syntetisoitavia malleja, mutta järjestelmäarkkitehtuurin suunnittelusta ja simulaatioiden todentamisesta ei näytä olevan paljon tietoa, mikä saattaa heijastaa Kiinan suhteellisen alhaista suunnittelua.

Kun olin koulussa, ajattelin aina, että niin kauan kuin RTL-tason koodi oli tehty hyvin, simulaatiovahvistus oli vain muodollisuus, joten jätin halveksivasti huomioimatta HDL-käyttäytymiskuvauksen syntaksin ja olin haluton oppimaan testipenkeistä – koska ajattelin, että aaltomuotojen piirtäminen oli kätevää; En tiennyt mitään järjestelmäarkkitehtuurin suunnittelusta. Vasta kun törmäsin joihinkin asioihin yrityksessä, tajusin, että se oli täysin erilainen.

Itse asiassa ulkomailla simulaatioiden todentamiseen käytetty aika ja työvoima on luultavasti kaksinkertainen RTL-tason koodiin verrattuna. Nyt simulaatiovahvistus on kriittinen polku miljoonan portin sirujen suunnittelussa.

Simulaatiovahvistus: mallinnus ja automaatio

Simulaatioverifioinnin vaikeus piilee pääasiassa siinä, kuinka mallintaa täydellisesti ja tarkasti suunnittelun oikeellisuuden varmistamiseksi (lähinnä koodin peiton lisäämiseksi). Tässä prosessissa varmennusnopeus on myös tärkeä.

Yksinkertaisesti sanottuna todentaminen on sitä, kuinka luoda riittävä kattavuus ärsykelähteille ja sitten havaita virheet. Itse olen sitä mieltä, että simulaatioverifioinnissa alkeellisinta on saavuttaa todentamisen automatisointi. Tästä syystä meidän on myös kirjoitettava testipenkkejä. Yhdessä nykyisessä mallissani jokaiseen simulointiajoon kuluu noin tunti (joka on itse asiassa pieni malli). Koska aaltomuotojen piirtämisellä ei saavuteta todennusautomaatiota, jos simuloimme piirtämällä aaltomuotoja, ensinnäkin aaltomuoto piirretään kuoliaaksi (erityisesti suunnitelmissa, joissa on monimutkaisia ​​algoritmeja ja syötetilastollinen jakautuminen), toiseksi aaltomuodon katsominen on tappavaa, ja kolmanneksi virheiden havaitsemisprosentti on lähes nolla. Joten kuinka saavuttaa automaatio? Tasoni on edelleen hyvin rajallinen, joten voin puhua vain lyhyesti BFM:stä (väylätoimintomalli).

Esimerkkinä MAC-ytimen tekeminen (taustalevy on PCI-väylä), tarvitsemme MAC_BFM-, PCI_BFM- ja PCI_BM (PCI-käyttäytymismalli). MAC_BFM:n päätehtävä on tuottaa Ethernet-kehyksiä (ärsykelähteitä), joissa on satunnainen pituus ja kehysotsikot, ja sisältö on myös satunnaista. Lähetyksen aikana se myös kopioi sen PCI_BM:ään; PCI_BFM:n tehtävänä on simuloida PCI-väylän käyttäytymistä, esimerkiksi kun testattava laite vastaanottaa oikean kehyksen, se lähettää pyynnön PCI-väylään ja PCI_BFM vastaa siihen ja tuo datan sisään; PCI_BM:n päätehtävä on verrata sitä, mitä MAC_BFM lähettää ja mitä PCI_BFM vastaanottaa. Koska sillä on MAC_BFM:n lähetystiedot ja PCI_BFM:n vastaanottotiedot, niin niin kauan kuin suunnittelu on järkevä, se voi aina automaattisesti ja täydellisesti testata, toimiiko testattava laite normaalisti, jolloin saavutetaan automaattinen tunnistus.

Huawein arvioidaan menestyvän suhteellisen hyvin simulaatioiden todentamisessa Kiinassa. He ovat perustaneet suhteellisen hyvän varmennusalustan, ja suurin osa viestintään liittyvästä BFM:stä on hyvin tehty. Ystävältäni kuulin, että nyt heidän tarvitsee vain laittaa laite testattavaksi testialustaan ​​ja konfiguroida parametrit niin, että se havaitsee automaattisesti, toimiiko testattava laite oikein.

Kielinäkökohdat

HDL-kielistä monet kiinalaiset kiistelevät siitä, kumpi on parempi VHDL:n ja Verilogin välillä. Itse asiassa olen henkilökohtaisesti sitä mieltä, että tämä ei ole kovin merkityksellistä. Useimmat ulkopuoliset suuret yritykset käyttävät periaatteessa Verilogia RTL-tason koodiin, joten suosittelen silti kaikille oppimaan Verilogia niin paljon kuin mahdollista. Simuloinnin kannalta, koska VHDL on heikompi kuin Verilog käyttäytymismallinnuksessa, VHDL:llä tehtyjä simulaatiomalleja on hyvin vähän. Verilog ei tietenkään ole täydellinen. Itse asiassa Verilogin kyky monimutkaisessa käyttäytymismallinnuksessa on myös rajallinen. Se ei esimerkiksi vielä tue taulukoita. Joissakin monimutkaisissa algoritmisuunnitelmissa tarvitaan korkean tason kieliä abstraktiota varten käyttäytymismallien kuvaamiseksi. Ulkomailla monet simulaatiomallit tehdään SystemC- ja E-kielillä, ja Verilogin käyttöä pidetään vanhentuneena. Huawein Kiinan varmennusalusta näyttää olevan kirjoitettu SystemC:llä.

Tulevaisuuden näkymät

Järjestelmäarkkitehtuurin suunnittelun suhteen minulla ei ole vielä paljon kokemusta, koska suunnittelemani suunnittelu ei ole tarpeeksi suuri. Minusta tuntuu, että minulla on oltava jonkin verran tietoa tietokonejärjestelmän arkkitehtuurista. Jaon ensisijainen perusta on toiminnallisuus, jonka jälkeen valitaan sopiva väylärakenne, tallennusrakenne ja prosessoriarkkitehtuuri. Järjestelmäarkkitehtuurin jaon tulisi tehdä jokaisesta toiminnallisesta moduulista selkeä ja helppo toteuttaa. Luulen, että jaan joitain oivalluksia, kun minulla on vähän kokemusta tästä osasta jonkin aikaa, joten en johda teitä harhaan toistaiseksi.

Henkilökohtaisia ​​oivalluksia

Lopuksi haluan tehdä lyhyen yhteenvedon. Kaikki johtuu enemmän harjoittelusta, enemmän ajattelusta ja enemmän kyseenalaistamista. Harjoitus tekee mestarin. On parempi harjoitella sitä itse kuin lukea muiden ratkaisuja sata kertaa. Motivaatio harjoitteluun tulee osittain kiinnostuksesta ja osittain paineesta. Itse pidän jälkimmäistä tärkeämpänä. Vaatimukset luovat helposti painetta, eli on parasta harjoitella varsinaisessa projektikehityksessä kuin opiskella opiskelun vuoksi.

Harjoittelun aikana kannattaa miettiä enemmän ja pohtia ongelmien syitä. Kun olet ratkaissut ongelmat, kysy miksi vielä muutaman kerran. Tämä on myös kokemusten keräämisprosessi. Jos sinulla on tapana kirjoittaa projektilokeja, se on vielä parempi. Kirjoita muistiin siihen liittyvät ongelmat, syyt, ratkaisut ja menetelmät. Lopuksi kysy lisää. Jos et pysty ratkaisemaan ongelmaa harkittuasi, kysy. Loppujen lopuksi yksilölliset kyvyt ovat rajallisia. Kysy luokkakavereilta, kollegoilta, hakukoneilta ja nettimiehiltä. Artikkeli tai ystävien opas voivat auttaa sinua ratkaisemaan ongelmia nopeasti.

Yhteenveto

Funktionaalisen simulaation jälkeen, koska suunnittelemme FPGA:lla, RTL-tason koodin periaatteessa taataan olevan yhdenmukaisia ​​synteesituloksen ja toiminnallisen simulaation tuloksen kanssa suunnittelun aikana. Niin kauan kuin synteesiasettelun jälkeistä staattista ajoitusraporttia ei varoiteta ajoitusrajoitusten rikkomisesta, voimme jatkaa virheenkorjausta levyllä. Itse asiassa Huawei ja ZTE eivät myöskään tee ajoitussimulaatiota suunnitellessaan FPGA:ta, koska ajoitussimulointi vie paljon aikaa ja vaikutus ei välttämättä ole parempi kuin staattisen ajoitusanalyysin raportin katsominen.

Tietysti, jos se on ASIC-suunnittelua, simulaation todentamisen työmäärä on suurempi. Kun siihen liittyy usean kellon verkkotunnuksen suunnittelu, jälkisimulaatio tehdään yleensä. Ennen jälkisimuloinnin suorittamista käytetään kuitenkin yleensä muodollisia varmennustyökaluja, ja staattisen ajoituksen analyysiraporttia käytetään suunnitteluvaatimusten rikkomusten tarkistamiseen. Tämän jälkeen jälkisimuloinnin työmäärä voi olla paljon pienempi.

Jos tämä vaatimus vaikuttaa hankintaan tai tuotantoon, vertaa sitä elektroniikkakomponenttien hankintaan ja pintakäsittelyn vertailuun ennen lopullisten tiedostojen lähettämistä tarkastettavaksi.