PDF-Ausgabe herunterladen (38.4 MB) - elektronik industrie

Embedded-Systeme
sourcen 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 Technologiespezifischer
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.
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 FP-
GA-Ä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.
Compiler Debugger Checker
Vertrieb und Support in Deutschland
Power Architecture
Freescale S12Z
ARM Cortex M3/M4
fragen Sie uns!
0711 90 Rohrackerstrasse 70329 Stuttgart www.COSMIC-Software.de sales@COSMIC-Software.de
COSMIC Software GmbH 68/ 73 11 97 90
Top-5-Empfehlungen für besseres Prototyping
■ Die Entwicklung eines FPGA-Prototyps ist ein Schlüsselelement
■
■
■
■
Info-Kasten
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 erfol-
gen, um sowohl FPGA- als auch IC-Technologie in effi zienter Weise
zu repräsentieren, und zwar im ersten Codierungsansatz wie
auch in späteren Verfeinerungen. Von der resultierenden Qualität
der RTL-Defi nition wird das Design während seiner gesamten Lebensdauer
profi tieren.
Der Codierungsstil sollte modular sein und eine saubere Trennung
prototyp-spezifi scher Komponenten vom Rest des Designs, einen
unabhängigen Datenfl uss sowie isolierte Taktbereiche vorsehen.
Die Entwurfsdokumentation sollte erweitert werden, um dem Pro-
totypenteam zu ermöglichen, kritische Teile des Designs so früh
wie möglich zu identifi zieren.
Das IC-Team müsste sich leicht umorientieren, um Prototyping in
seine Prozesse und Mitarbeiterprofi le zu integrieren.
Gute Dokumentation und Revisionskontrolle
Entwickler sollten immer danach streben, einen klaren und selbstdokumentierenden
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-Designflow
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. (jj)
■
Der Autor: Doug Amos ist Business Development Manager, Solutions
58 elektronik industrie 03 / 2012
www.elektronik-industrie.de