Goedbetaalde tips voor FPGA-ingenieurs die jaarlijks 700 verdienen

Voor FPGA-ingenieurs die een hoog salaris willen verdienen, zijn er verschillende belangrijke strategieën die ze moeten overwegen. Eerst en vooral is het aanscherpen van uw vaardigheden op het gebied van FPGA-ontwerp en -ontwikkeling cruciaal. Door een expert te worden in talen als Verilog en VHDL, en door de FPGA-ontwikkeltools en -platforms onder de knie te krijgen, ben je een waardevolle aanwinst in het veld.

Het is ruim tien jaar geleden dat ik tijdens mijn studententijd voor het eerst met FPGA in aanraking kwam. Ik herinner me nog de opwinding van het voor het eerst voltooien van experimenten zoals digitale stopwatches, quizzoemers en wachtwoordvergrendelingen op het EDA-platform. Op dat moment was ik nog niet blootgesteld aan HDL-hardwarebeschrijvingstalen, dus werden de ontwerpen gebouwd met behulp van logische apparaten uit de 74-serie in de schematische MAX+plus II-omgeving. Later, tijdens mijn postdoctorale studie en daaropvolgende werkzaamheden, gebruikte ik Quartus II, Foundation, ISE en Libero, en leerde ik ook de Verilog HDL-taal. Door dit leerproces begon ik geleidelijk de slimheid van Verilog te waarderen. Ik realiseerde me dat een klein stukje code complexe schematische ontwerpen kon voltooien, en dat de draagbaarheid en bruikbaarheid van de taal veel sterker waren dan die van schematische ontwerpen.

Belang van standaarden in FPGA Logic Design

Vrienden die in de branche hebben gewerkt, weten dat bedrijven de nadruk leggen op standaarden, vooral voor grote ontwerpen (of het nu software of hardware is). Het is bijna onmogelijk om dit te bereiken zonder de normen te volgen. Logisch ontwerp is daarop geen uitzondering: als u de standaarden niet volgt, kunt u een maand later fouten tegenkomen bij het debuggen. Als je terugkijkt op de code die je hebt geschreven, ben je misschien veel signaalfuncties vergeten, laat staan ​​de foutcontrole. Als iemand halverwege een project vertrekt, zal de opvolger waarschijnlijk helemaal opnieuw moeten beginnen met het ontwerp. Als u nieuwe functies aan de originele versie moet toevoegen, zult u hoogstwaarschijnlijk opnieuw moeten beginnen, waardoor het moeilijk wordt om het ontwerp opnieuw te gebruiken.

Qua logica denk ik dat de volgende normen belangrijk zijn:

1. Ontwerpdocumentatie: Ontwerpideeën, gedetailleerde implementaties, enz. moeten in documenten worden geschreven, en pas na strikte beoordeling en goedkeuring kan de volgende werkstap worden uitgevoerd. Deze aanpak kan het project in een beheersbare en haalbare staat houden.
2. Standaardisatie van codes: Standaardiseer de signaalnaamgeving, gebruik kleine letters voor signaalnamen en hoofdletters voor parameters, markeer effectieve signalen op laag niveau met _n aan het einde (bijv. rst_n), en regel poortsignalen met één signaal per lijn voor eenvoudigere foutdetectie bij simulatieverificatie.
3. Beheer van klokdomeinen: Gebruik slechts één klok voor elke module en gebruik een speciale module voor klokdomeinisolatie in ontwerpen met meerdere klokdomeinen, zodat de synthesizer een optimaal resultaat kan synthetiseren.
4. Vermijd combinatorische logica voor grendels: In FPGA-ontwerpen is het verboden om pure combinatorische logica te gebruiken om grendels te genereren. Vergrendelingen met D-flipflops zijn toegestaan, zoals configuratieregisters.
5. Signaalsynchronisatie: Over het algemeen moeten signalen die de FPGA binnenkomen eerst worden gesynchroniseerd om de werkfrequentie van het systeem te verhogen.
6. Registreer alle uitgangen: Alle module-uitgangen moeten worden geregistreerd om de werkfrequentie te verhogen en timingconvergentie in het ontwerp te bereiken.
7. Vermijd afgesloten klokken: Gebruik geen gated clocks, tenzij het een ontwerp met laag vermogen is, aangezien dit de instabiliteit van het ontwerp zal vergroten.
8. Klok inschakelen signalen: Het is verboden om signalen gedeeld door tellers te gebruiken als klokken voor andere modules. Gebruik in plaats daarvan klokinschakelsignalen.

Timingontwerp voor hoge prestaties

Mijn baas heeft een achtergrond bij Huawei en Junlong, dus uiteraard vertelde hij ons over enkele logische ontwerppraktijken bij Huawei en Altera. Onze projectnormen zijn in principe gebaseerd op de praktijken bij Huawei. De diepste indruk op mij van de afgelopen maanden was het gezegde bij Huawei: timing is ontworpen, niet gesimuleerd of verzonnen. In ons bedrijf wordt elk project streng gecontroleerd. Pas nadat de beoordeling is geslaagd, kan de volgende werkstap worden uitgevoerd. Als we logisch ontwerp als voorbeeld nemen, moeten we, in plaats van meteen code te schrijven, eerst het algemene ontwerpplan en het gedetailleerde logica-ontwerpplan schrijven. Nadat deze plannen zijn beoordeeld en haalbaar worden geacht, kan het coderen beginnen. Over het algemeen is de tijd die aan deze taken wordt besteed veel groter dan de tijd die aan coderen wordt besteed.

Het algemene plan omvat voornamelijk de moduleverdeling, interfacesignalen en timing van modules van het eerste en tweede niveau, en hoe het ontwerp in de toekomst kan worden getest. Op dit planniveau is het belangrijk ervoor te zorgen dat de timing convergeert naar de module van het eerste niveau (en uiteindelijk naar de module van het tweede niveau). Wat betekent dit? Wanneer we een gedetailleerd ontwerp maken, zullen we zeker enkele aanpassingen maken aan de timing van sommige signalen. Deze timingaanpassingen kunnen echter hoogstens de module van het eerste niveau beïnvloeden, en niet het hele ontwerp. Ik herinner me dat ik, toen ik op school zat, omdat ik het timingontwerp niet begreep, vaak de timing van andere modulesignalen moest aanpassen omdat de timing van één signaal niet werd gehaald, wat erg frustrerend was.

In het gedetailleerde logica-ontwerpplan hebben we de interfacetiming van elk niveau van modules al ontworpen, en hoe elk niveau van modules wordt geïmplementeerd, wordt in principe bepaald. Omdat we dit hebben bereikt, wordt coderen uiteraard sneller. Het allerbelangrijkste is dat deze aanpak het ontwerp in een beheersbare staat kan houden en kan voorkomen dat het hele ontwerp opnieuw moet worden gestart vanwege fouten op één plek.

Wat zijn de factoren die de werkfrequentie van een circuit beïnvloeden?

De werkfrequentie van het circuit houdt voornamelijk verband met de signaalvoortplantingsvertraging tussen registers en klokscheefheid. Als de klok in de FPGA langs lange lijnen loopt, is de klokafwijking erg klein en kan deze worden genegeerd. Hier worden eenvoudigheidshalve alleen de factoren in aanmerking genomen die de signaalvoortplantingsvertraging beïnvloeden. De signaalvoortplantingsvertraging omvat de openings- en sluitingsvertraging van het register, de routeringsvertraging en de vertraging via de combinatorische logica. Om de werkfrequentie van het circuit te verhogen, moeten we aan deze drie vertragingen werken en ze zo klein mogelijk maken.

1. Verminder vertraging door de route te wijzigen: specificeer de routering van enkele belangrijke signalen, zoals klokken en besturingssignalen, zodat ze door de FPGA zo weinig mogelijk. Dit kan de routeringsvertraging effectief verminderen.
2. Verminder het aantal combinatorische logica: Gebruik zoveel mogelijk opzoektabellen (LUT) in plaats van logische poorten. Bovendien gebruiken sommige mensen gecascadeerde registers om het aantal poorten te verminderen, maar de beste manier is om pipelining te gebruiken om het aantal poorten te verminderen.

Over het algemeen zijn het verminderen van het aantal poorten en het aanpassen van de routing effectieve manieren om de werkfrequentie van het circuit te verhogen. In de praktijk wordt vaak een combinatie van beide toegepast. Dit is echter geen absolute waarheid. In sommige gevallen leidt het aanpassen van de routing niet tot een vermindering van de vertraging, en is het verminderen van het aantal poorten de meest effectieve oplossing.

De uitdagingen van logisch ontwerp: systeemarchitectuur en simulatieverificatie

Toen ik voor het eerst bij het bedrijf kwam, vertelde mijn baas me dat de moeilijkheid van logisch ontwerp niet ligt in het ontwerp van code op RTL-niveau, maar in het ontwerp van de systeemarchitectuur en de simulatieverificatie. Momenteel ligt er in China meer nadruk op synthetiseerbare ontwerpen, maar er lijkt niet veel informatie te zijn over het ontwerp van systeemarchitectuur en simulatieverificatie, wat het relatief lage ontwerpniveau in China zou kunnen weerspiegelen.

Toen ik op school zat, dacht ik altijd dat, zolang de code op RTL-niveau goed werd uitgevoerd, simulatieverificatie slechts een formaliteit was, dus negeerde ik minachtend de syntaxis van HDL-gedragsbeschrijvingen en was ik terughoudend om over testbanken te leren – omdat ik dacht dat het tekenen van golfvormen was handig; Ik wist niets van systeemarchitectuurontwerp. Pas toen ik bij het bedrijf een aantal dingen tegenkwam, besefte ik dat het totaal anders was.

In het buitenland zijn de tijd en mankracht die aan simulatieverificatie worden besteed waarschijnlijk twee keer zo groot als die aan code op RTL-niveau. Nu is simulatieverificatie het cruciale pad voor het ontwerpen van chips met miljoenen poorten.

Simulatieverificatie: modellering en automatisering

De moeilijkheid van simulatieverificatie ligt vooral in de wijze waarop modellen moeten worden gebruikt om de juistheid van het ontwerp volledig en nauwkeurig te verifiëren (voornamelijk om de codedekking te vergroten). In dit proces is ook de verificatiesnelheid van belang.

Verificatie is, in eenvoudige bewoordingen, de manier waarop voldoende dekking van stimulusbronnen kan worden gegenereerd en vervolgens fouten kunnen worden opgespoord. Persoonlijk denk ik dat het meest fundamentele bij simulatieverificatie het bereiken van automatisering van de verificatie is. Dit is ook de reden waarom we testbanken moeten schrijven. In een van mijn huidige ontwerpen duurt het ongeveer een uur voor elke simulatierun (wat eigenlijk een klein ontwerp is). Omdat het tekenen van golfvormen geen automatisering van verificatie kan bewerkstelligen, zal, als we simuleren door golfvormen te tekenen, ten eerste de golfvorm dood worden getrokken (vooral voor ontwerpen met complexe algoritmen en statistische invoerdistributie), ten tweede zal het kijken naar de golfvorm dodelijk zijn, en ten derde zal het kijken naar de golfvorm dodelijk zijn, en ten derde, het foutdetectiepercentage is bijna nul. Dus hoe automatisering te bereiken? Mijn niveau is nog steeds erg beperkt, dus ik kan alleen kort praten over BFM (busfunctiemodel).

Als we het voorbeeld nemen van het maken van een MAC-kern (de backplane is de PCI-bus), hebben we een MAC_BFM, PCI_BFM en PCI_BM (PCI-gedragsmodel) nodig. De belangrijkste functie van MAC_BFM is het genereren van Ethernet-frames (stimulusbronnen), met willekeurige lengtes en frameheaders, en de inhoud is ook willekeurig. Tijdens het verzenden kopieert het het ook naar PCI_BM; de functie van PCI_BFM is om het gedrag van de PCI-bus te simuleren. Wanneer het te testen apparaat bijvoorbeeld een correct frame ontvangt, zal het een verzoek naar de PCI-bus sturen, en PCI_BFM zal hierop reageren en de gegevens binnenbrengen; de belangrijkste functie van PCI_BM is het vergelijken van wat MAC_BFM verzendt met wat PCI_BFM ontvangt. Omdat het de zendinformatie van MAC_BFM en de ontvangstinformatie van PCI_BFM heeft, kan het, zolang het ontwerp redelijk is, altijd automatisch en volledig testen of het te testen apparaat normaal werkt, waardoor automatische detectie wordt bereikt.

Er wordt geschat dat Huawei het relatief goed doet op het gebied van simulatieverificatie in China. Ze hebben een relatief goed verificatieplatform opgezet en het grootste deel van de BFM met betrekking tot communicatie is goed gedaan. Ik hoorde van mijn vriend dat ze nu alleen het te testen apparaat in het testplatform hoeven te plaatsen en de parameters te configureren om automatisch te detecteren of het te testen apparaat correct functioneert.

Taaloverwegingen

Wat HDL-talen betreft, maken veel mensen in China ruzie over wat beter is tussen VHDL en Verilog. Persoonlijk denk ik dat dit niet erg zinvol is. De meeste grote bedrijven daarbuiten gebruiken Verilog in principe voor code op RTL-niveau, dus ik raad iedereen nog steeds aan om Verilog zoveel mogelijk te leren. In termen van simulatie: omdat VHDL zwakker is dan Verilog op het gebied van gedragsmodellering, zijn er zeer weinig simulatiemodellen gedaan met VHDL. Natuurlijk is Verilog ook niet perfect. In feite is het vermogen van Verilog op het gebied van complexe gedragsmodellering ook beperkt. Het ondersteunt bijvoorbeeld nog geen arrays. Bij sommige complexe algoritmeontwerpen zijn talen op hoog niveau nodig voor abstractie om gedragsmodellen te beschrijven. In het buitenland worden veel simulatiemodellen gemaakt met behulp van de SystemC- en E-taal, en het gebruik van Verilog wordt als verouderd beschouwd. Het verificatieplatform van Huawei in China lijkt in SystemC geschreven.

Toekomstperspectieven

Op het gebied van systeemarchitectuurontwerp heb ik nog niet veel ervaring, omdat het ontwerp waaraan ik werk niet groot genoeg is. Ik heb gewoon het gevoel dat ik enige kennis moet hebben van de architectuur van computersystemen. De primaire basis voor de indeling is functionaliteit, gevolgd door het selecteren van de juiste busstructuur, opslagstructuur en processorarchitectuur. De indeling van de systeemarchitectuur moet ervoor zorgen dat elke functionele module duidelijk en eenvoudig te implementeren is. Ik denk dat ik enkele inzichten zal delen nadat ik over een tijdje wat ervaring heb met dit deel, dus ik zal je voorlopig niet misleiden.

Persoonlijke inzichten

Laat ik tot slot een korte samenvatting geven. Het komt allemaal neer op meer oefenen, meer nadenken en meer vragen stellen. Oefening baart kunst. Het is beter om het zelf te oefenen dan honderd keer de oplossingen van anderen te lezen. De motivatie om te oefenen komt deels voort uit interesse en deels uit druk. Persoonlijk vind ik dat laatste belangrijker. Het hebben van vereisten zal gemakkelijk druk creëren, dat wil zeggen dat het het beste is om te oefenen in daadwerkelijke projectontwikkeling in plaats van te studeren om het studeren.

Tijdens het oefenen moet je meer nadenken en nadenken over de redenen voor de problemen. Nadat je de problemen hebt opgelost, vraag je nog een paar keer waarom. Dit is ook een proces van het vergaren van ervaring. Als je de gewoonte hebt om projectlogboeken te schrijven, is dat nog beter. Schrijf de problemen, redenen, oplossingen en methoden op die erin zijn opgelost. Stel ten slotte nog meer vragen. Als je een probleem niet kunt oplossen nadat je erover hebt nagedacht, vraag het dan. De individuele mogelijkheden zijn immers beperkt. Vraag het aan klasgenoten, collega's, zoekmachines en internetgebruikers. Een artikel of de richtlijnen van vrienden kunnen u helpen problemen snel op te lossen.

Conclusie

Na functionele simulatie, aangezien we in FPGA ontwerpen, is de code op RTL-niveau in principe gegarandeerd consistent met het syntheseresultaat en het functionele simulatieresultaat tijdens het ontwerp. Zolang het statische timingrapport na de synthese-indeling niet wordt gewaarschuwd tegen het overtreden van de timingbeperkingen, kunnen we doorgaan met debuggen op het bord. Sterker nog, bij Huawei en ZTE doen ze ook geen timingsimulatie bij het ontwerpen van FPGA, omdat timingsimulatie veel tijd kost en het effect niet noodzakelijkerwijs beter is dan kijken naar het statische timinganalyserapport.

Als het om een ​​ASIC-ontwerp gaat, is de werklast van de simulatieverificatie uiteraard groter. Als het gaat om domeinontwerp met meerdere klokken, wordt doorgaans nasimulatie uitgevoerd. Voordat er echter post-simulatie wordt uitgevoerd, worden meestal formele verificatietools gebruikt en wordt het statische timinganalyserapport gebruikt om te controleren op eventuele overtredingen van ontwerpvereisten. Nadat u dit hebt gedaan, kan de werklast van de post-simulatie veel kleiner zijn.

Als deze eis van invloed is op de inkoop of de productievrijgave, vergelijk deze dan met de inkoop van elektronische componenten en de oppervlakteafwerking voordat u de definitieve bestanden ter beoordeling verzendt.