Hochbezahlte Tipps für FPGA-Ingenieure, die 700 jährlich verdienen

Für FPGA-Ingenieure, die ein hohes Gehalt verdienen möchten, müssen mehrere Schlüsselstrategien in Betracht gezogen werden. In erster Linie ist es von entscheidender Bedeutung, Ihre Fähigkeiten im FPGA-Design und in der Entwicklung zu verbessern. Wenn Sie ein Experte für Sprachen wie Verilog und VHDL werden und FPGA-Entwicklungstools und -plattformen beherrschen, werden Sie zu einer wertvollen Bereicherung auf diesem Gebiet.

Es ist mehr als zehn Jahre her, dass ich während meiner Studienzeit zum ersten Mal mit FPGA in Kontakt kam. Ich erinnere mich noch an die Aufregung, als ich zum ersten Mal Experimente wie digitale Stoppuhren, Quiz-Summer und Passwortsperren auf der EDA-Plattform durchführte. Zu diesem Zeitpunkt war ich noch nicht mit den HDL-Hardwarebeschreibungssprachen vertraut, daher wurden die Entwürfe mit Logikbausteinen der 74er-Serie in der Schaltplanumgebung MAX+plus II erstellt. Später, während meines Aufbaustudiums und der anschließenden Arbeit, verwendete ich Quartus II, Foundation, ISE und Libero und lernte auch die Sprache Verilog HDL. Durch diesen Lernprozess lernte ich nach und nach die Cleverness von Verilog kennen. Mir wurde klar, dass ein kleines Stück Code komplexe Schaltplanentwürfe vervollständigen konnte und dass die Portabilität und Bedienbarkeit der Sprache viel besser war als die von Schaltplanentwürfen.

Bedeutung von Standards im FPGA-Logikdesign

Freunde, die in der Branche gearbeitet haben, wissen, dass Unternehmen Wert auf Standards legen, insbesondere bei großen Designs (ob Software oder Hardware). Es ist fast unmöglich, dies zu erreichen, ohne die Standards zu befolgen. Das Logikdesign bildet da keine Ausnahme: Wenn Sie sich nicht an die Standards halten, kann es sein, dass Sie einen Monat später beim Debuggen Fehler finden. Wenn Sie auf den Code zurückblicken, den Sie geschrieben haben, haben Sie möglicherweise viele Signalfunktionen vergessen, ganz zu schweigen von der Fehlerprüfung. Wenn jemand mitten in einem Projekt abreist, muss der Nachfolger wahrscheinlich mit dem Entwurf ganz von vorne beginnen. Wenn Sie der Originalversion neue Funktionen hinzufügen müssen, müssen Sie höchstwahrscheinlich von vorne beginnen, was die Wiederverwendbarkeit des Designs erschwert.

Aus logischer Sicht halte ich folgende Standards für wichtig:

1. Designdokumentation: Designideen, detaillierte Umsetzungen usw. sollten in Dokumenten festgehalten werden und erst nach strenger Prüfung und Genehmigung kann der nächste Arbeitsschritt durchgeführt werden. Dieser Ansatz kann das Projekt in einem kontrollierbaren und erreichbaren Zustand halten.
2. Code-Standardisierung: Signalbenennung standardisieren, Kleinbuchstaben für Signalnamen und Großbuchstaben für Parameter verwenden, effektive Signale mit niedrigem Pegel markieren _n am Ende (z. B. rst_n) und ordnen Sie Portsignale mit einem Signal pro Leitung an, um die Fehlererkennung bei der Simulationsverifizierung zu erleichtern.
3. Clock-Domain-Management: Verwenden Sie nur einen Takt für jedes Modul und verwenden Sie ein dediziertes Modul zur Taktdomänenisolierung in Designs mit mehreren Taktdomänen, damit der Synthesizer ein optimaleres Ergebnis synthetisieren kann.
4. Vermeiden Sie kombinatorische Logik für Latches: In FPGA-Designs ist es verboten, reine kombinatorische Logik zum Generieren von Latches zu verwenden. Latches mit D-Flip-Flops sind zulässig, beispielsweise Konfigurationsregister.
5. Signalsynchronisation: Im Allgemeinen müssen Signale, die in den FPGA gelangen, zuerst synchronisiert werden, um die Arbeitsfrequenz des Systems zu erhöhen.
6. Registrieren Sie alle Ausgänge: Alle Modulausgänge sollten registriert werden, um die Arbeitsfrequenz zu erhöhen und eine zeitliche Konvergenz im Design zu erreichen.
7. Vermeiden Sie geschlossene UhrenHinweis: Sofern es sich nicht um ein Design mit geringem Stromverbrauch handelt, sollten Sie keine getakteten Takte verwenden, da dies die Instabilität des Designs erhöht.
8. Taktaktivierungssignale: Es ist verboten, durch Zähler geteilte Signale als Takte für andere Module zu verwenden. Verwenden Sie stattdessen Taktaktivierungssignale.

Timing-Design für hohe Leistung

Mein Chef hat zuvor bei Huawei und Junlong gearbeitet, daher erzählte er uns natürlich von einigen Logikdesignpraktiken bei Huawei und Altera. Unsere Projektstandards basieren grundsätzlich auf den Praktiken bei Huawei. In den letzten Monaten meiner Arbeit hat mich vor allem das Sprichwort bei Huawei am tiefsten beeindruckt: Timing wird entworfen, nicht simuliert oder erfunden. Bei uns wird jedes Projekt einer strengen Prüfung unterzogen. Erst nach bestandener Prüfung kann der nächste Arbeitsschritt durchgeführt werden. Am Beispiel des Logikdesigns müssen wir zunächst den Gesamtentwurfsplan und den detaillierten Logikentwurfsplan schreiben, anstatt sofort mit dem Schreiben von Code zu beginnen. Nachdem diese Pläne überprüft und für machbar befunden wurden, kann mit der Codierung begonnen werden. Im Allgemeinen ist der Zeitaufwand für diese Aufgaben viel größer als der Zeitaufwand für das Codieren.

Der Gesamtplan umfasst hauptsächlich die Modulaufteilung, Schnittstellensignale und das Timing der Module der ersten und zweiten Ebene sowie die Frage, wie das Design in Zukunft getestet werden soll. Bei dieser Planungsebene ist es wichtig sicherzustellen, dass die Zeitplanung mit dem Modul der ersten Ebene (und schließlich mit dem Modul der zweiten Ebene) übereinstimmt. Was bedeutet das? Wenn wir das detaillierte Design erstellen, werden wir auf jeden Fall einige Anpassungen am Timing einiger Signale vornehmen. Allerdings können sich diese Timing-Anpassungen höchstens auf das Modul der ersten Ebene auswirken, nicht auf das gesamte Design. Ich erinnere mich, dass ich während meiner Schulzeit oft das Timing anderer Modulsignale anpassen musste, weil ich das Timing-Design nicht verstand, weil das Timing eines Signals nicht eingehalten wurde, was sehr frustrierend war.

Im detaillierten Logikentwurfsplan haben wir bereits das Schnittstellen-Timing jeder Modulebene entworfen und festgelegt, wie jede Modulebene implementiert wird. Da wir dies erreicht haben, wird die Codierung natürlich schneller. Am wichtigsten ist, dass dieser Ansatz den Entwurf in einem kontrollierbaren Zustand halten und verhindern kann, dass aufgrund von Fehlern an einer Stelle der gesamte Entwurf von vorne begonnen werden muss.

Welche Faktoren beeinflussen die Betriebsfrequenz einer Schaltung?

Die Arbeitsfrequenz der Schaltung hängt hauptsächlich mit der Signalausbreitungsverzögerung zwischen Registern und dem Taktversatz zusammen. Wenn der Takt im FPGA über lange Leitungen läuft, ist der Taktversatz sehr gering und kann ignoriert werden. Der Einfachheit halber werden hier nur die Faktoren berücksichtigt, die die Signallaufzeit beeinflussen. Die Signalausbreitungsverzögerung umfasst die Öffnungs- und Schließverzögerung des Registers, die Routing-Verzögerung und die Verzögerung durch die kombinatorische Logik. Um die Arbeitsfrequenz der Schaltung zu erhöhen, müssen wir an diesen drei Verzögerungen arbeiten und sie so klein wie möglich machen.

1. Reduzieren Sie Verzögerungen, indem Sie das Routing ändern: Geben Sie das Routing einiger wichtiger Signale wie Takte und Steuersignale an, damit diese durch die FPGA so wenig wie möglich. Dadurch kann die Routingverzögerung effektiv reduziert werden.
2. Reduzieren Sie die Anzahl der kombinatorischen Logik: Verwenden Sie so weit wie möglich Nachschlagetabellen (LUT) anstelle von Logikgattern. Darüber hinaus verwenden einige Leute kaskadierte Register, um die Anzahl der Gatter zu reduzieren. Der beste Weg ist jedoch die Verwendung von Pipelining, um die Anzahl der Gatter zu reduzieren.

Im Allgemeinen sind die Reduzierung der Gatteranzahl und die Änderung der Leiterbahnführung effektive Methoden zur Erhöhung der Arbeitsfrequenz einer Schaltung. In der Praxis ist oft eine Kombination aus beidem erforderlich. Dies ist jedoch nicht absolut. In manchen Fällen führt eine Änderung der Leiterbahnführung nicht zu einer Verringerung der Verzögerung, und die Reduzierung der Gatteranzahl ist dann die effektivste Methode.

Die Herausforderungen des Logikdesigns: Systemarchitektur und Simulationsverifizierung

Als ich zum ersten Mal in das Unternehmen eintrat, sagte mir mein Chef, dass die Schwierigkeit des Logikdesigns nicht im Design von Code auf RTL-Ebene liege, sondern im Design der Systemarchitektur und der Simulationsüberprüfung. Derzeit wird in China mehr Wert auf synthetisierbare Designs gelegt, aber es scheint nicht viele Informationen über Systemarchitekturdesign und Simulationsverifizierung zu geben, was möglicherweise das relativ niedrige Designniveau in China widerspiegelt.

Als ich in der Schule war, dachte ich immer, dass die Simulationsüberprüfung nur eine Formsache sei, solange der Code auf RTL-Ebene gut gemacht sei. Deshalb ignorierte ich die Syntax der HDL-Verhaltensbeschreibung verächtlich und zögerte, etwas über Testbenches zu lernen – weil ich dachte Das Zeichnen von Wellenformen war praktisch. Ich wusste nichts über Systemarchitekturdesign. Erst als ich in der Firma auf einige Dinge stieß, wurde mir klar, dass es völlig anders war.

Tatsächlich ist der Zeit- und Arbeitsaufwand für die Simulationsverifizierung im Ausland wahrscheinlich doppelt so hoch wie der für Code auf RTL-Ebene. Heutzutage ist die Simulationsverifizierung der entscheidende Weg für die Entwicklung von Millionen-Gate-Chips.

Simulationsverifizierung: Modellierung und Automatisierung

Die Schwierigkeit der Simulationsüberprüfung liegt hauptsächlich darin, wie man modelliert, um die Korrektheit des Entwurfs vollständig und genau zu überprüfen (hauptsächlich, um die Codeabdeckung zu erhöhen). Dabei ist auch die Verifizierungsgeschwindigkeit wichtig.

Vereinfacht ausgedrückt geht es bei der Verifizierung darum, eine ausreichende Abdeckung von Reizquellen zu generieren und dann Fehler zu erkennen. Persönlich denke ich, dass es bei der Simulationsverifizierung am grundlegendsten ist, eine Automatisierung der Verifizierung zu erreichen. Aus diesem Grund müssen wir auch Testbenches schreiben. In einem meiner aktuellen Designs dauert jeder Simulationsdurchlauf etwa eine Stunde (was eigentlich ein kleines Design ist). Da das Zeichnen von Wellenformen keine Verifizierungsautomatisierung erreichen kann, wird bei der Simulation durch Zeichnen von Wellenformen erstens die Wellenform zu Tode gezeichnet (insbesondere bei Designs mit komplexen Algorithmen und statistischer Eingabeverteilung), zweitens ist das Betrachten der Wellenform tödlich und drittens die Fehlererkennungsrate liegt nahezu bei Null. Wie erreicht man also eine Automatisierung? Da mein Niveau noch sehr begrenzt ist, kann ich nur kurz auf BFM (Bus-Funktionsmodell) eingehen.

Am Beispiel der Herstellung eines MAC-Kerns (die Rückwandplatine ist der PCI-Bus) benötigen wir MAC_BFM, PCI_BFM und PCI_BM (PCI-Verhaltensmodell). Die Hauptfunktion von MAC_BFM besteht darin, Ethernet-Frames (Stimulusquellen) mit zufälligen Längen und Frame-Headern zu generieren, und der Inhalt ist ebenfalls zufällig. Beim Senden wird es auch nach PCI_BM kopiert; Die Funktion von PCI_BFM besteht darin, das Verhalten des PCI-Busses zu simulieren. Wenn das zu testende Gerät beispielsweise einen korrekten Frame empfängt, sendet es eine Anfrage an den PCI-Bus, und PCI_BFM antwortet darauf und bringt die Daten ein. Die Hauptfunktion von PCI_BM besteht darin, zu vergleichen, was MAC_BFM aussendet, mit dem, was PCI_BFM empfängt. Da es über die Sendeinformationen von MAC_BFM und die Empfangsinformationen von PCI_BFM verfügt, kann es bei angemessenem Design immer automatisch und vollständig testen, ob das zu testende Gerät normal funktioniert, und so eine automatische Erkennung erreichen.

Es wird geschätzt, dass Huawei bei der Simulationsverifizierung in China relativ gut abschneidet. Sie haben eine relativ gute Verifizierungsplattform eingerichtet und die meisten BFM im Zusammenhang mit der Kommunikation sind gut gemacht. Ich habe von meinem Freund gehört, dass sie jetzt nur noch das zu testende Gerät in die Testplattform stellen und die Parameter konfigurieren müssen, um automatisch zu erkennen, ob das zu testende Gerät ordnungsgemäß funktioniert.

Überlegungen zur Sprache

In Bezug auf HDL-Sprachen streiten viele Menschen in China darüber, welches zwischen VHDL und Verilog besser ist. Tatsächlich denke ich persönlich, dass dies nicht sehr aussagekräftig ist. Die meisten großen Unternehmen außerhalb verwenden grundsätzlich Verilog für RTL-Level-Code, daher empfehle ich dennoch jedem, so viel wie möglich Verilog zu lernen. Im Hinblick auf die Simulation gibt es nur sehr wenige Simulationsmodelle, die mit VHDL erstellt wurden, da VHDL bei der Verhaltensmodellierung schwächer als Verilog ist. Natürlich ist Verilog auch nicht perfekt. Tatsächlich sind auch die Fähigkeiten von Verilog zur komplexen Verhaltensmodellierung begrenzt. Beispielsweise werden Arrays noch nicht unterstützt. In manchen komplexen Algorithmenentwürfen werden Hochsprachen zur Abstraktion benötigt, um Verhaltensmodelle zu beschreiben. Im Ausland werden viele Simulationsmodelle in den Sprachen SystemC und E erstellt, und die Verwendung von Verilog gilt als veraltet. Die Verifizierungsplattform von Huawei in China scheint in SystemC geschrieben zu sein.

Zukunftsperspektiven

In Bezug auf das Design der Systemarchitektur habe ich noch nicht viel Erfahrung, da das Design, an dem ich arbeite, nicht groß genug ist. Ich habe einfach das Gefühl, dass ich über gewisse Kenntnisse der Computersystemarchitektur verfügen muss. Die primäre Grundlage für die Aufteilung ist die Funktionalität, gefolgt von der Auswahl der geeigneten Busstruktur, Speicherstruktur und Prozessorarchitektur. Durch die Aufteilung der Systemarchitektur sollte jedes Funktionsmodul klar und einfach zu implementieren sein. Ich denke, ich werde einige Erkenntnisse weitergeben, nachdem ich in einiger Zeit ein wenig Erfahrung in diesem Teil gesammelt habe, damit ich Sie vorerst nicht in die Irre führe.

Persönliche Einblicke

Lassen Sie mich abschließend kurz zusammenfassen. Es kommt auf mehr Übung, mehr Nachdenken und mehr Fragen an. Übung macht den Meister. Es ist besser, es selbst zu üben, als die Lösungen anderer hundertmal zu lesen. Die Motivation zum Üben entsteht teils aus Interesse, teils aus Druck. Ich persönlich halte Letzteres für wichtiger. Wenn Sie Anforderungen haben, entsteht leicht Druck. Das heißt, es ist am besten, in der tatsächlichen Projektentwicklung zu üben, anstatt nur um des Lernens willen zu studieren.

Im Laufe der Praxis sollten Sie mehr darüber nachdenken und über die Gründe für die Probleme nachdenken. Nachdem Sie die Probleme gelöst haben, fragen Sie noch ein paar Mal nach dem Warum. Dies ist auch ein Prozess des Sammelns von Erfahrungen. Wenn Sie die Angewohnheit haben, Projektprotokolle zu schreiben, ist es sogar noch besser. Schreiben Sie die darin gelösten Probleme, Gründe, Lösungen und Methoden auf. Stellen Sie abschließend weitere Fragen. Wenn Sie ein Problem nicht lösen können, nachdem Sie darüber nachgedacht haben, fragen Sie. Schließlich sind die individuellen Fähigkeiten begrenzt. Fragen Sie Klassenkameraden, Kollegen, Suchmaschinen und Internetnutzer. Ein Artikel oder die Anleitung von Freunden können Ihnen helfen, Probleme schnell zu lösen.

Fazit

Da wir nach der Funktionssimulation im FPGA entwerfen, ist grundsätzlich garantiert, dass der Code auf RTL-Ebene mit dem Syntheseergebnis und dem Ergebnis der Funktionssimulation während des Entwurfs übereinstimmt. Solange der statische Timing-Bericht nach dem Syntheselayout nicht vor einer Verletzung der Timing-Einschränkungen warnt, können wir mit dem Debuggen auf der Platine fortfahren. Tatsächlich führen Huawei und ZTE beim Entwurf von FPGAs auch keine Timing-Simulation durch, da die Timing-Simulation viel Zeit in Anspruch nimmt und der Effekt nicht unbedingt besser ist als der Blick auf den statischen Timing-Analysebericht.

Wenn es sich um ein ASIC-Design handelt, ist der Arbeitsaufwand für die Simulationsverifizierung natürlich größer. Wenn es um das Multi-Clock-Domain-Design geht, erfolgt im Allgemeinen eine Nachsimulation. Vor der Nachsimulation werden jedoch in der Regel formale Verifizierungstools verwendet und der statische Timing-Analysebericht wird verwendet, um auf etwaige Verstöße gegen Designanforderungen zu prüfen. Danach kann der Arbeitsaufwand für die Nachsimulation deutlich geringer sein.

Falls diese Anforderung Auswirkungen auf die Beschaffung oder die Produktionsfreigabe hat, vergleichen Sie sie mit der Beschaffung elektronischer Bauteile und dem Oberflächenvergleich, bevor Sie die endgültigen Dateien zur Überprüfung senden.