Der FPGA-Design-Flow verändert sich

Anbieter zum Thema

Heitec AG

ISH Ingenieursozietät GmbH

Cadlog Group

Lattice Semiconductor Corp.

Es ist somit eine grundlegendere Veränderung im FPGA-Design-Flow erforderlich, so dass Anwender mehrere Implementierungen parallel kompilieren können und die Ergebnisse von zwei Implementierungen nach einem einzelnen Kompilierungsvorgang anstelle von zwei aufeinanderfolgenden Vorgängen vergleichen können. Veränderungen lassen sich dann schnell rückgängig machen oder akzeptieren – und zwar mit begrenzten Auswirkungen auf ihren Terminplan.

Beispiel-Implementierung: Blcok-RAM oder distributed RAM?

Als Beispiel soll ein Szenario dienen, in dem der Anwender die Design-Implementierung von der Nutzung eines Block-RAMs auf Distributed-RAM umstellen muss. Damit wird Block-RAM eingespart. DSP-zentrische Designs benötigen Block-RAM, um die mit den Koeffizienten durchgeführten Operationen abzuspeichern. Block-RAM eignet sich für derartige Operationen ideal, weil es einen schnelleren Durchsatz als Distributed-RAM ermöglicht.

Soll eine solche Veränderung durchgeführt werden, dann sind zwei Durchläufe hintereinander durchzuführen, bevor die Auswirkungen dieser wesentlichen Designveränderung untersuchbar sind. Mit mehreren Implementierungen, die jeweils parallel laufen, lässt sich die Laufzeit auf einen vollen Durchlauf verringern, um die Auswirkungen schneller zu untersuchen.

Ein anderes Beispiel, bei dem der parallele Ablauf mehrerer Implementierungen von Nutzen ist, besteht dann, wenn der Anwender die Architektur des Designs ändert. Ein typischer Fall ergibt sich in schnellen Mobilfunk-Anwendungen, in denen der Wechsel von einer seriellen zu einer parallelen Implementierung für das Management des Datenverkehrs eine der Veränderungen darstellt, die häufig durchgeführt werden. Wenn hierbei der herkömmliche Design-Flow zum Einsatz kommt, sind zwei Compiler-Durchläufe erforderlich, um die Auswirkungen einer solchen Veränderung zu untersuchen. Im Rahmen eines Design-Flows, bei dem parallele Implementierungen möglich sind, ist jedoch nur ein Durchlauf notwendig, um die Auswirkungen zu untersuchen. Hierdurch ergibt sich eine Zeiteinsparung, die dem gesamten zusätzlichen Durchlauf entspricht.

Die Untersuchung des Designs beschleunigen

Ein Beispiel für einen zeitgemäßen Design-Flow lässt sich innerhalb der FPGA-Design-Software Lattice Diamond von Lattice Semiconductor finden, die für Bausteine optimiert ist, welche in kostensensiblen Low-Power-Applikationen zum Einsatz kommen, z.B. die Produktreihen MachXO/XO2 und LatticeECP.

Lattice Diamond enthält eine Funktion namens Run-Manager: Der Anwender kann für ein einziges Design zwei RT-Files haben, die als zwei Implementierungen erfasst sind. Diese beiden RT-Files können parallel laufen. Mit Run-Manager lässt sich die Kompilierungszeit im Vergleich zu einem herkömmlichen Design-Flow verringern und zügig die Ergebnisse der beiden Implementierungen vergleichen. Stimmen die Ergebnisse, kann der Baustein sofort programmiert werden, indem die bessere der beiden Implementierungen gewählt wird. Ist der Anwender mit keiner der Veränderungen zufrieden, kann er neue Implementierungen schaffen und diese wiederum laufen lassen, um ihre Auswirkungen zu untersuchen. Es gibt keine Beschränkungen bezüglich der Anzahl möglicher Implementierungen, die Anwender in einem Durchlauf haben können (Bild 4).

Zwei Beispiele, die mit dem Run-Manager auf zwei unterschiedlichen Bausteinen liefen, zeigen weitere Details: Erstens, ein DSP-zentrisches Design für ein FPGA des Typs LatticeECP3-95EA 1156-8. Es gab für dafür zwei Implementierungen, die auf einer Windows-basierten Maschine mit vier Cores und 4 GByte RAM abliefen. Die Kompilierungszeit für zwei serielle Implementierungen betrug 13 min, während die Zeit bei paralleler Nutzung des Run-Managers für die beiden Implementationen 8 min betrug – eine Gesamtverkürzung um 40%.

Zweites, ein Traffic-Manager-Design für ein FPGA des Typs LatticeECP3-35EA 484-6. Es gab wiederum zwei Implementierungen für dieses Beispiel, das auf einer Windows-basierten Maschine mit vier Cores und 4 GByte RAM ablief. Die Kompilierungszeit für die zwei seriellen Implementationen betrug fast 3 h, während die Kompilierungszeit mit Run-Manager für die beiden parallelen Implementationen 1,5 h betrug, so dass sich eine Zeitersparnis in Höhe von 50% ergab.

* * Ajay Jagtiani ist Senior Product Marketing Manager bei Lattice Semiconductor.

(ID:35800960)