Diese Seite ist die fünfte und letzte in einer Reihe von Seiten darüber, wie du ein professioneller FPGA-Designer wirst. Anders als die vorherigen geht es hier nicht um technische Dinge. Stattdessen steht im Mittelpunkt, was uns als Menschen ausmacht und welche Eigenschaften das Leben eines FPGA-Designers einfacher und besser machen.
Das ist tatsächlich wichtig
Es mag seltsam erscheinen, über die Persönlichkeit und die Haltung von FPGA-Designern zu sprechen, insbesondere auf einer Website, die sich auf technische Themen konzentriert. In einem Leitfaden für einen angehenden FPGA-Designer finde ich es jedoch passend, auch die menschlichen Eigenschaften und Verhaltensweisen zu besprechen, die den Unterschied ausmachen zwischen „alles unter Kontrolle“ und „Arbeiten im kompletten Chaos“.
Für praktisch jeden Beruf gibt es eine passende Persönlichkeit: Es ist schwer, Autoverkäufer zu sein, wenn man nicht gut mit Menschen umgehen kann, und man wird kein guter Lehrer, wenn man Kinder nicht mag. Ebenso gibt es bestimmte Persönlichkeitsmerkmale, die dir als FPGA-Ingenieur helfen, und solche, die es nicht tun.
Ich predige nicht, und ich versuche auch nicht, jemanden abzuschrecken. Ich komme auch nicht mit „du musst hart arbeiten“. Im Gegenteil: Die Absicht ist, Dinge richtig zu machen und Ziele mit weniger Aufwand zu erreichen.
Auf dieser Seite versuche ich zu beschreiben, was es braucht, um ein erfolgreicher FPGA-Designer zu sein, zusätzlich zu diesem oder jenem Fachwissen, um mit diesem Beruf in Frieden leben zu können. Diese Seite handelt von der Persönlichkeit des Ingenieurs. Es wird niemanden überraschen, dass es besser ist, Selbstdisziplin und Selbstkontrolle zu haben und der genaue Typ zu sein. Eine leichte Besessenheit für Details schadet ebenfalls nicht.
Aber verwechsle das nicht mit irgendeiner Vorstellung von Leiden im Leben oder von Arbeit bis zum Umfallen. Es ist genau umgekehrt: Wenn du die Fähigkeit hast, auf eine bestimmte Weise zu arbeiten, wirst du schneller und leichter fertig. Es wird Spaß machen und erfüllend sein. Es beim ersten Versuch richtig hinzubekommen ist das Ideal, und es ist erreichbar.
Wenn du andererseits das Gefühl hast, dass du nicht zu meinen Beschreibungen des idealen FPGA-Designers unten passt, nicht einmal im Entferntesten, hmmm, wie soll ich es sagen? Denk vielleicht noch einmal über die ganze Idee nach?
„Es funktioniert“ ist nicht gut genug
In der Softwarewelt, insbesondere bei Websites und Apps, ist es üblich, etwas hinzuschreiben, es auszuprobieren, das zu beheben, was falsch ist, und es erneut zu versuchen. Mit KI wird sogar die Phase des Hinschreibens von Code übersprungen, und eine Maschine erledigt sowohl das Codieren als auch das Testen und übernimmt das Ergebnis schließlich in das Git-Repository.
Die zugrunde liegende Idee ist: Wenn der Code die Tests besteht, ist die Arbeit erledigt. Wenn es noch einen Bug gibt, wird die Qualitätssicherung ihn finden, oder die Beschwerde eines Nutzers wird bald eintreffen. In diesem Fall wird routinemäßig eine Anforderung zur Behebung ausgegeben. Dann wird der Bug behoben. Eine ganze Menge Softwareteams ist genau so strukturiert.
Ob diese Praxis für die Softwareentwicklung geeignet ist oder nicht, ist eine separate Diskussion. Was ich klar sagen möchte, ist, dass sie für professionelles FPGA-Design zutiefst falsch ist. „Es funktioniert“ ist bei Weitem nicht gut genug für ein FPGA-Projekt. Vielleicht für Hobbyisten, aber definitiv nicht für ein Projekt, das in die echte Produktion geht. Es ist verlockend, in diese Falle zu tappen, insbesondere wenn man froh ist, dass nach einer langen Debugging-Sitzung endlich etwas funktioniert, und dann Feierabend zu machen.
Das mag wie puristische Predigt klingen, aber es ist die einfache Wahrheit: Der einzige Weg zu einem zuverlässigen FPGA-Design ist, sich selbst ein für alle Mal zu beweisen, dass das, was du entworfen hast, garantiert funktioniert. Du schließt eine Aufgabe nicht ab, wenn das Design alle Tests besteht, sondern erst, wenn du dich davon überzeugen kannst, dass es unmöglich fehlschlagen kann.
Ich vergleiche das mit einem mathematischen Theorem: Du sagst nicht, dass es korrekt ist, weil du es ein paar Mal mit Zahlen ausprobiert hast und es jedes Mal korrekt war. Du betrachtest die Gleichung als korrekt, wenn du einen mathematischen Beweis hast.
In der Praxis bedeutet das, dass jede Zeile in einer Verilog-Datei wie eine Gleichung in einer mathematischen Herleitung behandelt wird, und dasselbe gilt für die Timing-Vorgaben (timing constraints) und andere zugehörige Quelldateien. Das mag etwas extrem klingen, aber diese Sorgfalt zahlt sich langfristig aus.
Dasselbe gilt für die Verbindungen des FPGA zu anderen elektronischen Komponenten: Du gehst nicht davon aus, dass die elektrische Schnittstelle in Ordnung ist, nur weil sie funktioniert. Du beweist dir selbst, dass die Anforderungen in den Datenblättern erfüllt sind: sowohl die im Datenblatt des FPGA als auch die in denen der anderen Komponenten. Sind die Spannungspegel korrekt? Stellt das FPGA-Design sicher, dass alle Timing-Anforderungen auf beiden Seiten erfüllt sind?
Heißt das, dass meine Designs immer frei von Bugs sind? Natürlich nicht. Ich bin ein Mensch, und ich mache Fehler. Genauso wie ich einen mathematischen Beweis nicht zu 100 % korrekt hinbekomme, selbst wenn ich es versuche. Ich könnte vergessen, Randfälle zu prüfen, ich könnte ein Plus mit einem Minus vertauschen und mich allgemein vertun.
Aber das Schöne an diesem rigorosen Ansatz ist, dass die wenigen Bugs, die am Ende übrig bleiben, üblicherweise offensichtlich und relativ leicht zu beheben sind. Und sobald sie behoben sind, funktioniert das Design einfach. Keine Bugs, keine Rätsel, keine Hexerei. Ein solide funktionierendes Stück Elektronik.
Es ist der langsame Weg, um das Ziel schnell zu erreichen.
Arbeiten die Leute wirklich so streng?
Kurze Antwort: Definitiv nicht. Das weiß ich insbesondere aus meiner Zeit als Freiberufler. Meine erste Aufgabe bei jedem neuen Kunden war, das FPGA-Projekt zu stabilisieren. Das war ein bisschen wie das Stabilisieren eines Patienten im Notfallraum durch Ärzte. Und die für das Projekt verantwortlichen Ingenieure schienen oft selbst eine Art Stabilisierung zu brauchen, nach langer Zeit voller Stress und Frustration.
Die Haltung „erst hinschreiben, dann debuggen“ ist leider auch in der FPGA-Branche verbreitet. Kein Wunder, denn der Simulator wird in Verilog-Kursen oft im selben Geist präsentiert wie ein Debugger in der Softwarewelt. Die dahinterstehende Anregung ist oft, das gewünschte Ergebnis durch Ausprobieren zu erreichen. Simuliere, bis es auf dem Computer funktioniert, und synthetisiere und repariere es dann, bis es auch auf der Hardware funktioniert.
Um es noch schlimmer zu machen, gibt es Manager, die diese Art der Arbeitsweise fördern. Sie sind ungeduldig, Ergebnisse zu sehen, und sobald sie etwas sehen, das in Ordnung zu sein scheint, erwarten sie, dass du zur nächsten Aufgabe übergehst. Der Zeitplan drängt, und „die Bugs beheben wir später“.
Als Ergebnis dieses Ansatzes ist es schwierig und manchmal unmöglich, ein wirklich zuverlässiges FPGA-Design zu bekommen. Das wird durch umfangreiche Regressionstests in der Simulation sowie umfangreiche Tests mit Hardware kompensiert. Manche Unternehmen führen Temperaturtests an jeder gefertigten Platine durch, bevor sie die Produktionslinie verlässt, wenn sich ein FPGA darauf befindet. Das Testen der Hardware vor der Auslieferung wird zu einer eigenen Abteilung mit eigener Hardware und Software, die nur einen Zweck hat: sicherzustellen, dass das FPGA wirklich das tut, was es tun soll.
Dahinter stehen sehr gestresste FPGA-Ingenieure, die hinter dem Zeitplan zurückliegen, während sie hektisch Bugs nachjagen, die auf mysteriöse Weise auftauchen und verschwinden.
Es ist nicht immer so schlimm. Wenn das FPGA bei einer relativ niedrigen Frequenz arbeitet, wenn die Anforderungen einfach sind und wenn sporadische Ausfälle keine so große Sache sind, kann die Trial-and-Error-Haltung ganz gut funktionieren.
Außerdem sind die meisten Leute, die mit FPGAs arbeiten, in der Realität irgendwo in der Mitte der Skala: nicht am Extrem, Verilog als mathematische Gleichungen zu betrachten, aber mit einem erhöhten Maß an Geduld, Selbstdisziplin und Respekt für Genauigkeit. So schaffen sie es, die Arbeit in diesem Feld zu erledigen.
Wisse, was du tust
Wenn ich dich davon überzeugt habe, dass Trial and Error nicht der richtige Weg bei FPGAs ist, ist klar, dass ein rigoroserer und genauerer Weg erforderlich ist. Aber das allein reicht nicht. Eine rigorose Haltung hilft nicht, wenn du nicht genau verstehst, was du tust.
Zum Beispiel sieht man ziemlich häufig asynchrone Resets (asynchronous resets) in Verilog-Code (das habe ich auch auf früheren Seiten erwähnt). Das ist eine legitime Methode zum Zurücksetzen von Logik, aber nur, wenn sie korrekt angewendet wird. In der überwiegenden Mehrheit der Fälle wird dieser Reset falsch verwendet und garantiert daher nicht, dass sich die Logik wie erwartet verhält. In der Realität funktioniert aber alles einwandfrei. Normalerweise. Zu diesem Thema gibt es eine separate Seite.
Der Grund für diese falsche Verwendung des asynchronen Resets ist wahrscheinlich, dass Leute Verilog-Code aus anderen Quellen in ihren eigenen kopieren und einfügen. Das Codemuster ist so vertraut und offensichtlich, dass die Leute nicht innehalten, um darüber nachzudenken, was es tatsächlich bedeutet. Und in diesem Fall, was es nicht bedeutet und nicht garantiert.
Zu wissen, was man tut, ist eine Voraussetzung dafür, sich selbst beweisen zu können, dass das Design garantiert funktioniert. Das bedeutet, genau zu verstehen, was jeder Verilog-Ausdruck bedeutet und wie der Synthesizer (synthesizer) ihn möglicherweise interpretiert. Dasselbe Prinzip gilt für Timing-Vorgaben (timing constraints) und andere Informationen, die die Entwicklungswerkzeuge im Zusammenhang mit dem FPGA-Design verarbeiten.
Aber wie ich bereits zugegeben habe, sind die meisten FPGA-Designer nicht rigoros genug, um zu beweisen, dass das Design funktioniert. Die genaue Bedeutung dessen zu kennen, was man eintippt, ist trotzdem ein Schritt in die richtige Richtung.
Denke abstrakt
Wenn du einen akademischen Kurs in Informatik belegt hast, hast du vielleicht gesehen, wie abstrakte Wesen zum Zweck der Beschreibung von Software erfunden werden. Zum Beispiel Datenstrukturen, die immer auf eine bestimmte Weise organisiert sind, Klassen und Objekte, Datenströme und Invarianten, die nach jeder Iteration einer Schleife erhalten bleiben, und so weiter. In der Informatik werden ständig imaginäre Wesen erfunden, damit wir Menschen über die kleinen Details im Inneren hinwegsehen und uns stattdessen auf eine einfachere Darstellung beziehen können. Das reduziert die Last für unser Gehirn und macht es möglich, komplizierte Softwaredesigns zu verstehen. Das nennen wir Abstraktion.
Auf der anderen Seite der Abstraktion haben wir die konkrete Denkweise. Oder soll ich sie „Geschichtenerzählen“ nennen? Bei dieser Haltung wird ein Computerprogramm wie eine Geschichte behandelt. Zuerst machen wir dies, und dann machen wir das, und wenn dies wahr ist, machen wir dies, sonst das. Folge einfach der Abfolge der Ereignisse mit einem Finger, der durch den Code wandert, und du verstehst alles.
Geschichtenerzählen funktioniert gut für die Entwicklung einfacher Skripte (scripts), Websites, mobiler Apps und anderer einfacher Software. Wenn der Nutzer diesen Knopf drückt, gehe zu diesem Bildschirm oder dieser Webseite, und mach von dort aus weiter. Die Software schreitet in einem einfachen Ausführungsstrang voran und kann in einem Gedankenstrang verstanden werden.
Ich möchte den Unterschied zwischen den beiden Denkweisen an einem Beispiel demonstrieren. Schauen wir uns diese in C geschriebene Funktion an, die n! berechnet, die Fakultät von n:
unsigned int factorial(unsigned int n) {
if (n == 0)
return 1;
return n * factorial(n - 1);
}
Das ist das klassische Beispiel für Rekursion. Wie verstehst du den obigen Code?
Die Art des Geschichtenerzählens ist, „es auszuprobieren“. Es klingt ungefähr so: „Angenommen, die Funktion wurde mit n=3 aufgerufen. Sie ruft sich selbst mit n=2 auf, dann mit n=1 und dann mit n=0. Jetzt entrollen wir: Sie gibt also 1 für den Aufruf mit n=0 zurück, dann 1*1, dann gibt sie 2*1 zurück, und schließlich 3*2, was 6 ist, und das ist die richtige Antwort. Großartig, es funktioniert.“ Vielleicht wird dieser Gedankengang mit einem Debugger und Einzelschritt-Ausführung durchgeführt.
Die andere Art ähnelt einem Beweis durch vollständige Induktion. Wir nehmen an, dass die Funktion tatsächlich die Fakultät von n zurückgibt, und bestätigen, dass sie, wenn sie für n-1 funktioniert, auch für n funktioniert. Schließlich bestätigen wir, dass sie den korrekten Wert für n=0 liefert und dass die Rekursion immer bei n=0 endet. Die Reihenfolge der Ausführung ist irrelevant, da die Funktion als ein abstraktes Wesen behandelt wird, das einfach seinen Zweck erfüllt.
Und du magst fragen: Warum die Dinge kompliziert machen? Das Geschichtenerzählen hat es doch ganz gut erklärt. Darauf antworte ich: Ja, aber es hat nur funktioniert, weil das Beispiel einfach ist.
Und jetzt komme ich endlich zum Punkt: Wenn du beim Verstehen von Software auf das Geschichtenerzählen beschränkt bist, wird das ein Hindernis für dich als FPGA-Designer sein. Der erste und offensichtliche Grund ist, dass in einem FPGA alles gleichzeitig passiert. Sehr wenig in einem FPGA lässt sich mit „zuerst dies, dann das“ beschreiben.
Der zweite und wichtigere Grund ist, dass FPGA-Designs oft komplex sind. Oft ist Abstraktion nötig, damit du geistig fähig bist, zu erfassen, was vor sich geht. Zum Beispiel ist es eine gute Angewohnheit, ein Verilog-Modul so zu definieren, dass seine Funktionalität in ein paar Sätzen und ohne zu viele Details beschrieben werden kann. Auch die Schnittstellen zu seinen Ports sollten einfach zu beschreiben sein. Wenn es möglich ist, einen komplizierten Logikblock auf ein paar einfache Ideen zu reduzieren, ist die Chance auf einen menschlichen Fehler kleiner. Dieses Prinzip gilt auch für Software, ist dort aber nicht immer so entscheidend.
Der dritte Grund für abstraktes Denken hängt mit der Fähigkeit zusammen, sich selbst die Korrektheit zu beweisen. Mit dem Geschichtenerzählen deckst du nur die Szenarien ab, an die du denken kannst. Ein echter Beweis deckt alles ab.
Bei der Bewältigung komplizierter Aufgaben kann es nötig sein, neue theoretische Wesen zu erfinden, bevor man eine einzige Zeile Verilog schreibt. Wenn du zum Beispiel ein Modul brauchst, das Datenpakete sowohl ein- als auch ausgibt, kann es helfen, N als die Anzahl der Pakete zu definieren, die gerade in seinem Speicherpuffer liegen. Damit kannst du beweisen, dass der Puffer niemals voll wird. Das mag nicht nach viel klingen, aber diesen Schritt zum mathematischen Denken zu machen, kann sehr helfen. Es kann sehr gut sein, dass die gesamte Logik im Modul irgendwie damit zusammenhängt, dieses N innerhalb der richtigen Grenzen zu halten.
Der Trick ist, die richtigen abstrakten Wesen zu finden, die wirklich helfen, die Logik richtig hinzubekommen. Das kann bedeuten, ein paar Tage lang keine einzige Zeile Verilog zu schreiben und dann plötzlich ein kurzes Verilog-Modul sehr schnell geschrieben zu haben. Auf diese Weise ersonnener Code ist oft kurz, elegant, leicht verständlich und funktioniert beim ersten Versuch und für immer danach.
Das funktioniert jedoch möglicherweise nicht so gut, wenn dein Chef dich jeden Tag fragt, was du machst: Ein paar Tage lang gibt es nichts zu zeigen, und wenn dir schließlich etwas einfällt, könnte die Reaktion „das ist alles, was du hast, dieses triviale Modul?“ sein.
Also noch einmal: Rein mathematisch an FPGA-Design heranzugehen, ist nicht unbedingt der Weg für jeden. Aber ich schlage trotzdem vor, die Angewohnheit des Geschichtenerzählens loszuwerden, wenn du sie hast.
Vertraue den Werkzeugen nicht
Oder genauer gesagt: Die Entwicklungswerkzeuge werden dich nicht davon abhalten, schreckliche Fehler zu machen. Sie warnen dich vielleicht nicht einmal.
Kein Software-Compiler der Welt wird jemals ausführbaren Code erzeugen, der etwas anderes tut als das, was der Quellcode verlangt. Wenn doch, melde einen Bug. Ein Synthesizer (synthesizer) hingegen kann sehr wohl Logik erzeugen, die nicht das Verhalten erfüllt, das der Verilog-Code verlangt. Wenn du Glück hast, gibt es eine Warnung dazu. Wenn du noch mehr Glück hast, bemerkst du diese Warnung unter den Hunderten anderer harmloser Meldungen und Warnungen, die der Synthesizer ausspuckt.
Auch die anderen Teile der FPGA-Entwicklungssuite können böse Streiche spielen. Das Offensichtlichste ist, dass die meisten von ihnen einen Bitstrom (bitstream) erzeugen, den du in das FPGA laden kannst, selbst wenn die Timing-Vorgaben (timing constraints) nicht eingehalten werden. Das bedeutet, dass das FPGA so funktionieren kann, wie der Synthesizer es gemeint hat, oder auch nicht. Oder es funktioniert vielleicht ein bisschen und dann nicht mehr. Du bekommst eine Warnung oder sogar eine kritische Warnung (critical warning). Aber würde ein Software-Compiler eine Kompilierung abschließen und eine ausführbare Datei liefern, die möglicherweise nicht funktioniert?
Es gibt endlose andere Wege, ein FPGA-Design zu vermasseln, ohne dass die Werkzeuge dich aufhalten. Das ist gewissermaßen eine kulturelle Sache. Es ist, als ob jemand absichtlich will, dass der Umgang mit FPGAs schwierig ist.
Ich habe mit mehreren verschiedenen FPGA-Herstellern und mit ziemlich vielen Entwicklungswerkzeugen für FPGAs gearbeitet. Es ist ziemlich verblüffend, dass sie alle dieselbe Neigung haben, die Dinge schwierig zu machen, und dass Sicherheitsnetze etwas sind, das man sich wünschen muss. Es ist nicht ein bestimmter, billiger und böser FPGA-Hersteller. Es sind alle.
Zu allem Überfluss ist es nicht selten, dass FPGA-Entwicklungswerkzeuge Bugs haben. Wenn du Glück hast, stürzen sie beim Versuch ab, das Projekt zu bauen, sodass dies zumindest kein Bug ist, der dein Design fehlerhaft funktionieren lässt. Bugs, die zu einem Fehler im Bitstrom (bitstream) führen, kommen jedoch vor, auch wenn nicht allzu oft. Es ist schlimmer, wenn eine neue Design-Suite veröffentlicht wird. In der FPGA-Welt bedeutet „am neuesten“ nicht unbedingt „am besten“, um es milde auszudrücken.
Nach all dem: Verdächtige die Werkzeuge nicht, wenn dein Design nicht funktioniert, insbesondere nicht, wenn du neu in diesem Feld bist. Und wenn du glaubst, dass die Werkzeuge versagt haben, finde den rauchenden Colt. Finde die Logikzelle im FPGA, bei der es hätte etwas sein sollen, es sich aber als etwas anderes herausstellte. Überzeuge dich selbst davon, dass es wirklich die Schuld der Werkzeuge ist, dass es so gekommen ist. Es reicht nicht, dass du das Gefühl hast, die Werkzeuge seien verrückt. Es gibt fast immer eine einfachere Erklärung für das, was so aussieht.
Und insbesondere: Wenn du etwas Unzusammenhängendes in deinem Verilog-Code änderst und ein Bug verschwindet, heißt das nicht, dass es einen Bug in den Werkzeugen gibt. Dieses Verhalten ist typischer für schlecht definierte Timing-Vorgaben (timing constraints) und andere ähnliche Fehler.
Der Schlüssel zum Umgang mit diesem Problem bei den Entwicklungswerkzeugen ist, auf die Gefahr hin, mich zu wiederholen, zu wissen, was du tust. Speziell für dieses Thema: die Warnungen und Meldungen zu lesen, die die Werkzeuge ausgeben, und zu verstehen, was sie bedeuten, oder zumindest ungefähr, womit sie zusammenhängen. Es ist eine Frage der Erfahrung zu lernen, welche Warnungen harmlos sind, immer erscheinen und ignoriert werden können und sollten. Und was die Frage angeht, warum die Werkzeuge Version für Version viele nutzlose Warnungen ausgeben – habe ich Kultur erwähnt?
Es ist daher eine gute Angewohnheit, ab und zu alle Warnungen zu überfliegen und zu sehen, ob etwas auffällt. Tu das sogar, und insbesondere, wenn alles perfekt funktioniert. Nicht nur, weil „es funktioniert“ nicht gut genug ist, sondern auch als eine Möglichkeit zu lernen, welche Warnungen harmlos sind.
Und tatsächlich sind manche Warnungen ein Hinweis darauf, dass du die Dinge richtig gemacht hast. Wenn eine Warnung zum Beispiel besagt, dass ein Register aus dem Design entfernt wurde, weil es einen konstanten Wert hat oder einem anderen Register entspricht, ist das eine Gelegenheit, für einen Moment innezuhalten und darüber nachzudenken, ob das im Kontext Sinn ergibt. Ziemlich oft helfen dir solche Warnungen, interessante Tatsachen über deinen eigenen Code zu erkennen.
Von der Anforderung zum Design
Wenn du Software schreibst, gibt es üblicherweise eine ziemlich geradlinige Verbindung zwischen der Anforderung und dem, was du schreiben musst. Das gilt insbesondere für einfache Software (zum Beispiel Websites und mobile Apps).
Beim FPGA-Design ist es möglicherweise nicht so einfach. Die Anforderung für ein FPGA klingt oft eher nach „Hier sind die Komponenten, wir wollen, dass es sich so verhält“.
Der Aufbau kann zum Beispiel eine Platine mit einem Kamerasensor, einem FPGA und Drähten sein, die zu einer anderen Einheit führen. Die Aufgabe ist, das Bild vom Kamerasensor zu holen, eine grundlegende Signalverarbeitung an den Pixeln durchzuführen und die Ausgabe an die andere Einheit zu senden, und dabei dem spezifischen Format deines Arbeitgebers für die Übertragung von Videodaten zu folgen.
Du weißt alles über FIFOs, Zustandsautomaten (state machines), Pipelines (pipeline) und RTL-Design. Wie erstellst du das, wonach du gefragt wirst? Niemand sagt dir „schreibe einen Zustandsautomaten“. Es wird erwartet, dass du etwas erstellst, das funktioniert.
Wenn du Glück hast, ähneln die Anforderungen vielen früheren Projekten. Kopiere das Blockdiagramm, ahme die Logik nach und kopiere vielleicht ein paar Teile. Aber ziemlich oft gibt es etwas an den Anforderungen für dein Projekt, das eine solche Nachahmung unvernünftig macht.
Dann wirst du auch zum FPGA-Architekten. Du entscheidest, wie die Aufgabe in funktionale Einheiten aufgeteilt wird, was jede von ihnen tut und wie sie miteinander interagieren. Je besser du das ganz am Anfang des Projekts machst, desto leichter wird es sein, das Projekt zu schreiben und zu pflegen. Allzu oft wird das Blockdiagramm eines bestehenden Projekts einem neuen Projekt aufgezwungen, weil nichts Besseres da ist. Diese Abkürzung hat ihren Preis.
Wie wirst du also ein guter Architekt? Viel davon kommt aus Erfahrung und auch daraus, Lösungen zu beobachten, die in anderen Projekten gewählt wurden. Ich habe früher die Abstraktion erwähnt: Ein Design, ob dein eigenes oder das eines anderen, in abstrakten Begriffen zu verstehen, hilft dir, das nächste Projekt besser zu bauen. Wenn du Verilog-Module als funktionale Blöcke siehst, die eine Aufgabe erfüllen, für die du einen kurzen Namen hast, hast du eine Palette, die du für dein eigenes Projekt nutzen kannst. Wenn du siehst, wie mehrere Drähte zwei Module verbinden, und dem, wie die Module durch diese Drähte interagieren, einen Namen geben kannst, bist du in einer besseren Position, um zu entscheiden, wie die verschiedenen Teile deines neuen Projekts interagieren. Je besser du darin bist, die theoretischen Wesen in einem bestehenden Design zu erkennen, desto besser wirst du darin sein, ein neues zu bauen.
Wenn der Teil mit dem FPGA-Architekten schwierig klingt, lass mich ein kleines Geheimnis teilen: Er ist es wirklich. Ich habe das ein paar Mal gemacht, und es kostet sowohl eine ganze Menge Zeit als auch Reue. Jeder kleine Fehler in dieser Anfangsphase hat erhebliche Konsequenzen.
Aber denke daran, dass du wahrscheinlich kein Projekt von Grund auf neu entwerfen musst, und schon gar nicht als jemand, der neu bei FPGAs ist. Diese Aufgabe wird üblicherweise dem erfahrensten FPGA-Ingenieur im Team gegeben. Du hast also wahrscheinlich noch etwas Zeit, bevor du den Hut des Systemarchitekten aufsetzt. Und selbst wenn du als einziger FPGA-Ingenieur im Team eingestellt wirst, ist die Wahrscheinlichkeit hoch, dass du bestehenden Code pflegst oder ein neues Projekt auf Basis eines bestehenden entwickelst.
Aber es ist nie zu früh, sich auf diese Aufgabe vorzubereiten.
Zusammenfassung
In vielerlei Hinsicht war das Hauptthema dieser Seite Selbstdisziplin in verschiedenen Formen. Es ist die Fähigkeit, das zu überwinden, was oft als menschliches Verhalten gilt: Dinge ungenau und ohne vorheriges Durchdenken zu tun (insbesondere Verilog-Code und Timing-Vorgaben zu schreiben) und dann die Fehler zu beheben (Simulation und Debugging auf der Hardware). Froh zu sein, dass etwas funktioniert, und begierig zu sein, zur nächsten Aufgabe überzugehen („es funktioniert“ ist nicht gut genug). Sich selbst die Dinge auf eine einfache und natürliche Weise (Geschichtenerzählen) zu erklären, anstatt nach den abstrakten Ideen dahinter zu suchen. Kleine und langweilige Details zu überspringen, wie zum Beispiel die Warnungen, die die Werkzeuge ausgeben.
Unsere menschliche Natur ist leider ein Feind für uns als FPGA-Designer. Aber beachte, dass ich nichts über hartes Arbeiten gesagt habe. Nach weniger Arbeit zu streben, ist keine Faulheit, wenn du die Arbeit erledigt bekommst. Das Ziel ist tatsächlich, weniger zu arbeiten und trotzdem ein besseres Ergebnis zu bekommen. Und das ist möglich, wenn du es richtig machst.
Es geht auch nicht darum, ein Roboter zu werden. Es geht um Selbstkontrolle und Genauigkeit im Arbeitsleben, aber definitiv nicht darum, wie eine Maschine zu arbeiten. Wir brauchen unsere menschlichen Gehirne. Ein Roboter kann viele Stunden arbeiten, aber unsere Gehirne werden müde. Selbstkontrolle bedeutet manchmal, den Schreibtisch zu verlassen und sich nach einem langen und langweiligen Tag etwas auszuruhen. Selbst wenn dieser Bug noch da ist.
Und um diese ganze Seitenreihe zusammenzufassen – wie inzwischen deutlich geworden sein sollte, ist FPGA-Design nicht der einfachste aller Berufe, und ich habe eine ganze Reihe von Gründen dafür aufgezählt. Wenn du es nicht magst, ständig neue Dinge über Elektronik zu lernen, ist das vielleicht nichts für dich. Wenn du nicht glaubst, die Selbstdisziplin zu haben, Dinge gründlich und genau zu erledigen, ist das ein weiterer Grund, noch einmal darüber nachzudenken.
Und wenn ich es bisher nicht geschafft habe, dich abzuschrecken, heiße ich dich im Club willkommen und wünsche dir viel Glück und Geschick. Und mehr als alles andere hoffe ich, dass du diese Wahl genauso genießen wirst wie ich.