Wie Sie verhindern, dass FPGA-basierte Projekte in die Irre gehen

Im Laufe meiner Karriere war ich an der Entwicklung einer Reihe von FPGA-Designs für einige wirklich interessante Projekte beteiligt. Leider war ich auch an der Rettung mehrerer FPGA-Designs beteiligt, die stark in die Irre gegangen sind. Als ich an diesen Problemdesigns arbeitete, wurde klar, dass die Designs – obwohl die Zielanwendungen und die Mitglieder der Entwicklungsteams unterschiedlich waren – einige gemeinsame Punkte aufwiesen, die sie zum Scheitern verurteilten, bevor der erste Ingenieur sich überhaupt hinsetzte, um die erste Zeile zu schreiben des HDL-Codes.

Vor diesem Hintergrund dachte ich, ich würde fünf häufige Probleme durchgehen, die ich bei der Rettung dieser Projekte beobachtet habe. Diese Probleme sind wie folgt:

#1: Die erste Sorge bezieht sich nicht nur auf die FPGA-basierte Entwicklung, sondern auf das Engineering im Allgemeinen. Das Problem besteht darin, dass Sie beim Start keine stabile Basislinie für die Anforderungen haben. Es besteht immer der Wunsch, mit dem Projekt zu beginnen, während die Anforderungen noch reifen, auf der Grundlage, dass Fortschritte nachgewiesen werden müssen. Wenn wir jedoch einspringen und mit der Entwicklung beginnen, ohne die Anforderungen vollständig zu verstehen, erweisen sich alle anfänglichen Fortschritte allzu oft als falsch, und die Durchführung nachgelagerter Korrekturen führt zu zusätzlichen Verzögerungen und Kosten. Was zu früh beginnt, ist tatsächlich ein Risiko in die Entwicklung einzubringen, und dieses Risiko muss gemindert werden. Ich schätze, dass die Tiefe und Detailliertheit der Anforderungen je nach Anwendung skalieren kann. Ich würde viel mehr und detailliertere Anforderungen für ein SIL4-System erwarten als für ein kommerzielles System. Aber kurz und knapp:Wenn die Anforderungen nicht von Anfang an abgestimmt und festgelegt werden, kommt es zu einem Scope Creep. Obwohl das Design mit einer vernünftigen Architektur für die verstandenen Anforderungen begonnen haben mag, wird es immer komplizierter, wenn die Entwickler versuchen, neue Funktionen zu integrieren, wenn die Basislinie reift. Bald geht etwas kaputt.

#2: Nachdem die Anforderungssituation verstanden wurde, muss jedes Teammitglied den Plan zur Entwicklung des FPGA verstehen. Daher ist es eine gute Idee, einen Plan zu haben, der den Ansatz definiert, der vom Kick-off bis zur Auslieferung verfolgt wird, wobei die wichtigsten Schritte und die Engineering-Review-Gates identifiziert werden, die während des Entwicklungsprozesses angewendet werden. Zusammen mit dem Plan müssen wir auch die Architektur und das Design dokumentieren, jede der Hauptfunktionen identifizieren, entscheiden, welche Funktionen neu entwickelt werden sollen und welche, um IP von Drittanbietern zu nutzen oder bestehendes IP wiederzuverwenden (mehr dazu später). Diese kombinierte Plan-, Architektur- und Entwurfsbeschreibungsdokumentation ermöglicht es dem Ingenieursteam, die anstehende Aufgabe klar zu verstehen. Wir können auch alle Funktionen bis zum Anforderungssatz zurückverfolgen, um sicherzustellen, dass der vorgeschlagene Ansatz alle übergeordneten Anforderungen erfüllt.

#3: Das Entwerfen der Module und des gesamten FPGA wird einige Zeit in Anspruch nehmen; was jedoch länger dauert, ist die Überprüfung des Designs und die Sicherstellung, dass es seinen Anforderungen entspricht. Diese Überprüfung muss nicht nur logisch-funktional, sondern muss auch über alle möglichen Betriebsbedingungen des Geräts hinweg durchgeführt werden. Dies wiederum bedeutet, dass eine klare Verifikationsstrategie für das Design entwickelt werden muss; Es geht nicht mehr darum, nur den Code zu schreiben, ein paar Simulationen durchzuführen und dann das Design auf die Hardware zu werfen.

#4: Manchmal kommen wir alle so nah an die Dinge heran und sind in unseren Gedanken versunken, dass es schwer wird zu sehen, wenn wir etwas verpasst haben. Dafür wurden Konstruktionsprüfungen erfunden. Durch diese Überprüfungen können wir sicherstellen, dass wir gute technische Praktiken befolgen und interne Entwicklungsstandards einhalten. Bedeutsamerweise bieten sie auch unabhängigen Ingenieuren die Möglichkeit, sich das Design – seine Architektur und Implementierung – anzusehen, um sicherzustellen, dass es die erforderliche Funktionalität bietet. Wenn wir das Design im Laufe des Fortschritts nicht überprüfen, werden wir keine Qualität aufbauen und wir werden alle nachgelagerten Integrationsprobleme erhöhen.

#5: Bisher haben Sie vielleicht bemerkt, dass die meisten Punkte, die ich angesprochen habe, sich auf Prozess- und allgemeine technische Aspekte beziehen und nicht auf die Codierung des Designs selbst. Natürlich ist die Entwicklung des Codes wichtig, aber es ist auch wichtig sicherzustellen, dass wir das geistige Eigentum Dritter nutzen und internes geistiges Eigentum wiederverwenden. Idealerweise sollten wir so viele bestehende IP-Blöcke aus unserer Bibliothek wie möglich wiederverwenden. Wo dies nicht möglich ist, müssen wir natürlich neue Module entwickeln. In diesem Fall sollte es uns im Vordergrund stehen, diese neuen Module so zu gestalten, dass sie in zukünftigen Projekten wiederverwendet werden können. Um uns bei der Erstellung dieser neuen Blöcke zu helfen, sollten wir die Verwendung von High Level Synthesis (HLS)-Tools in Betracht ziehen. Indem es uns ermöglicht, auf einer höheren Abstraktionsebene zu arbeiten, bieten diese Tools die Möglichkeit, den Lösungsraum einfacher zu erkunden und Risiken, Entwicklungszeit und Kosten zu reduzieren.

Die oben aufgeführten Punkte sind nur einige der Dinge, die mir bei der Rettung von FPGA-Designs aufgefallen sind. Es würde mich sehr interessieren, Ihre Meinung zu Projekten zu hören, die fehlgeschlagen sind.