Prototypenentwickler sollten einer wohldefinierten Methodik folgen

Das bekannte Motto „Ganz oder gar nicht“ ermahnt uns, beim Einsatz von Prototyping auf FPGA-Basis den Prototypenentwicklern dabei zu helfen, ihre Aufgabe auf bestmögliche Weise zu erledigen. Jedes Prototyping-Team geht die Aufgabe auf unterschiedliche Art und Weise an, mit verschiedenen Stärken und Schwächen in ihren Methoden. Durch die Sammlung bewährter Vorgehensweisen in einem von allen Seiten befürworteten Satz von Richtlinien und einer bewährten Methodik können wir die Ergebnisse und den Zeitplan des gesamten IC-Projekts verbessern. Wir nennen diese Richtlinien Design-for-Prototyping.

Bild 1: Die am meisten genannten Vorteile des FPGA-basierten Prototypings.Synopsys

Bild 1 präsentiert die Meinung von Lesern, die das FPMM bereits studiert haben. Auf die Frage nach dem Grund ihrer Prototypenentwicklung nannten die allermeisten die Verifikation des IC-RTL-Codes. Andere klare Vorteile sind die gemeinsame Software- und Hardware-Validierung und die Unterstützung der Embedded-Software-Entwicklung selbst. Obwohl also Prototyping im eigentlichen Kern eine Aufgabe von Hardware-Ingenieuren ist, sind die Software-Ingenieure die hauptsächlichen Nutznießer. Dies macht Prototyping in heutigen Software-dominierten Anwendungen äußerst wichtig.

Was ist Design-for-Prototyping?

Design-for-Prototyping ist die Praxis, den Prototypen bereits frühzeitig im Entwurfsprozess zu berücksichtigen, sowie Vorgehensweisen und Entwurfstechniken zu etablieren, welche die Prototypenentwicklung vereinfachen. Design-for-Prototyping besteht aus zwei Arten von Richtlinien: technische und methodische. Die technischen Richtlinien beinhalten Vorschläge für RTL-Stil- und Entwurfstechniken, um den RTL-Code portierbarer zu halten. Die methodischen Richtlinien empfehlen Wege zur besseren Integration der Prototypenentwickler in das IC-Team. Erfahrene Entwicklerteams, die bereits einen gut dokumentierten und portierbaren Entwurfsstil pflegen, werden einige Richtlinien als offensichtlich oder gar trivial ansehen. Andere Richtlinien sind dagegen weniger intuitiv.

Der Rest dieses Artikels behandelt Beispiele dieser Richtlinien. Vollständige Details hierzu sind im FPMM zu finden. In jedem Fall muss stets bedacht werden, dass es sich um den Entwurf eines ICs handelt und die FPGA-Version lediglich ein temporäres, wenngleich wichtiges Modell darstellt. Aus diesem Grund muss man sicherstellen, dass die Design-for-Prototyping-Richtlinien nicht den endgültigen IC-Entwurf beeinträchtigen. Was das Prototyping unterstützt, muss auch den IC-Entwurf insgesamt unterstützen. Tatsächlich ist Design-for-Prototyping eine Erweiterung der Ent-wurfspraktiken, wie sie im klassischen Reuse-Methodology-Manual aus dem Jahr 2001 definiert sind.

Trennung und Vereinfachung der Taktnetze

IC-Taktnetze sind oft sehr komplex, und es gibt in der IC-Taktgenerierungslogik gewöhnlich viel mehr Optionen, als für den FPGA-Prototyp erforderlich sind. Beispielsweise ist die Skalierung der Taktfrequenz zur Einsparung von Verlustleistung im IC bedeutungslos für den Prototyp, weil FPGAs und der endgültige IC völlig unterschiedliche Verlustleistungsprofile besitzen.

Wenn der Block zur Taktgenerierung und -verteilung des ICs vom Rest des Designs getrennt gehalten wird, ist es leichter, ihn an das FPGA anzupassen oder ihn durch ein FPGA-Äquivalent zu ersetzen. Auf jeden Fall sollte Logik ohne oder mit lediglich geringem Bezug zur Taktgenerierung außerhalb des Taktgenerierungsblocks angeordnet werden.

Selbst wenn die IC-Taktstruktur sorgfältig dokumentiert ist, kann es schwierig sein, sie im FPGA zu implementieren, weshalb im Prototyp manchmal nur eine Untermenge aller Taktungsoptionen vorgesehen wird. Dies kann bereits in einem frühen Stadium des IC-Projekts entschieden werden.

Einsatz von ATPG statt manueller Testlogik

Dem IC wird Logik hinzugefügt, um seinen Test zu unterstützen. Dazu gehören Scan-Ketten und Takt-Multiplexer, welche die Komplexität des Taktnetzes erhöhen. Außerdem gibt es praktisch keinen Grund, diese Strukturen in einen FPGA-Prototyp zu integrieren, zumal dies unnötige Anforderungen an die FPGA-Taktressourcen stellen würde. Daher sollte die Prototypenentwicklung auf dem RTL-Code basieren, welcher keine Testlogik enthält.

Wenn Testlogik im RTL-Code manuell instanziiert wird, kann ihre Beseitigung eine komplizierte und fehleranfällige Aufgabe sein. Wird die Testlogik dagegen automatisch eingefügt, kann sie auf einfache Weise gelöscht oder deaktiviert werden.

Verwendung von Makros zur Generierung Technologie-spezifischer Logik

IC-RTL-Code-Entwickler sollten die Verilog-Konstrukte ‚define und ‚ifdef (bzw. die Anweisungen if . . . generate in VHDL) verwenden, um notwendige Speziallogik für die jeweilige Zieltechnologie zu erzeugen. Die Makro-Variable ist in lediglich einer globalen Header-Datei definiert und erhält einen offensichtlichen Namen wie „fpga“ oder „proto“. Diese wird dann global referenziert, um die Synthese zu steuern. Damit kann die Expansion des RTL-Codes auf die FPGA-Synthese beschränkt werden, während die vollständige Komplexität für die IC-Synthese erhalten bleibt.

Einsatz von Wrappern zur Speicher-Isolation

In einem IC gibt es viele Instanziierungen von Bibliothekselementen für ein spezifisches Element der Zieltechnologie. Instanziierungen von Speicherblöcken sind ein gängiges Beispiel. Ein Speicherelement direkt im RTL-Code zu instanziieren ist schlechte Praxis, da es auf diese Weise die gesamte RTL-Datei auf diese eine Ausprägung festlegt. Dies wiederum macht keinen Sinn, selbst wenn das Design lediglich auf eine andere Silizium-Bibliothek portiert wird. Es ist weitaus besser, eine generische Instanziierung für die Speicherfunktion, bezeichnet als Wrapper, vorzunehmen.

Bild 2: Wrapper zur besseren Portierbarkeit von Designs.Synopsys

Ein Wrapper erzeugt eine tiefere Hierarchieebene, welche den technologie-spezifischen Speicher enthält. Bild 2 zeigt einen Wrapper, welcher während der IC-Implementierung mit einer RTL-Datei ausgefüllt wird, die den IC-spezifischen Speicher enthält. Zur Prototypenentwicklung wird diese RTL-Datei dann durch das FPGA-Äquivalent ersetzt, evtl. sogar durch eine Datei, welche einen externen Speicherbaustein auf dem Board spezifiziert. EDA-Tools wie Certify erlauben die Verwendung externer Speicher ohne weitere Änderungen am RTL-Code.

Durch Einführung eines firmenweiten Standards für Wrapper-Namen und -Schnittstellen können Prototypenentwickler eine Speicherbibliothek erstellen, durch die sich jene in allen IC-Designs ersetzen lassen. Die beschriebene Wrapper-Methode erleichtert auch die Arbeit in dem Fall, dass eine zukünftige Version des ICs einen anderen Speicherblock enthalten soll.

Gute Dokumentation und Revisionskontrolle

Entwickler sollten immer danach streben, einen klaren und selbst-dokumentierenden Code zu schreiben. Dennoch gibt es in einem umfangreichen Entwurf immer auch Details, die für den Entwickler selbst offensichtlich sein mögen, jedoch im Rahmen der Prototypenentwicklung schwierig zu interpretieren sind. In diesen Fällen helfen einige Zeilen Kommentar, unnötigen Aufwand aufgrund von Mehrdeutigkeiten oder fehlender Klarheit zu vermeiden.

Außerdem kann die Verwendung eines bestimmten Kommentarstils hilfreich sein, beispielsweise die Angabe eines leicht erkennbaren Hinweises am Anfang einer Kommentarzeile wie . . .

//proto: This ram to be mapped to external DDR memory in prototype.

Prototypenentwickler können dann, selbst wenn keine vollständige Dokumentation vorliegt, leicht alle Dateien nach dem „//proto“-String durchsuchen. Dokumentation ist genauso wichtig für Korrekturen am Entwurf wie für Änderungen durch das Prototyping-Team. Daher sollte beides mit der gleichen Disziplin und im selben Revision-Control-System (RCS) aufgezeichnet werden wie der Rest des IC-Projekts.

Integration der Prototypenentwickler in das IC-Team

Design-for-Prototyping erhöht die Prototyping-Produktivität. Wenn es in vergangenen Projekten zu lange dauerte, Prototypen zu erstellen, lag die wirkliche Ursache nicht notwendigerweise bei den Entwicklern, sondern eher im IC-Entwurfsstil oder im Projektmanagement.

Die Entscheidung, Prototyping auf FPGA-Basis zum Chip-De-signflow hinzuzunehmen, sollte als Methodenänderung gegenüber vorherigen Praktiken angesehen werden, nicht aber als zusätzlicher Schritt. Prototypenentwickler sollten in alle entscheidenden Phasen des IC-Projekts eingebunden werden, um in relevanten Fragen wie IP-Auswahl, Top-Level-Topologie, Taktkomplexität, interne Überlastung des Designs, etc. beratend mitzuwirken. Selbst wenn das Design nicht vollständig FPGA-freundlich gestaltet werden kann, sind die Prototypenentwickler bereits im Voraus auf die Probleme vorbereitet und können entsprechend planen.

Es muss vermieden werden, dass die Prototypenentwickler vom Rest des IC-Teams wie „die Hacker mit den FPGA-Boards“ angesehen werden. Prototypenentwickler sollten einer wohldefinierten Methodik folgen und ebenso diszipliniert sein wie IC-Entwickler und Verifikationsingenieure.

Top-5-Empfehlungen für besseres Prototyping

• Die Entwicklung eines FPGA-Prototyps ist ein Schlüsselelement des gesamten IC-Entwurfsprojekts und muss daher in den Arbeits- und Zeitplänen berücksichtigt werden.
• Das RTL-Design hat nach einem robusten Codierungsstil zu erfolgen, um sowohl FPGA- als auch IC-Technologie in effizienter Weise zu repräsentieren, und zwar im ersten Codierungsansatz wie auch in späteren Verfeinerungen. Von der resultierenden Qualität der RTL-Definition wird das Design während seiner gesamten Lebensdauer profitieren.
• Der Codierungsstil sollte modular sein und eine saubere Trennung prototyp-spezifischer Komponenten vom Rest des Designs, einen unabhängigen Datenfluss sowie isolierte Taktbereiche vorsehen.
• Die Entwurfsdokumentation sollte erweitert werden, um dem Prototypenteam zu ermöglichen, kritische Teile des Designs so früh wie möglich zu identifizieren.
• Das IC-Team müsste sich leicht umorientieren, um Prototyping in seine Prozesse und Mitarbeiterprofile zu integrieren.

(jj)