FPGA-Debugging mit Mixed-Signal-Oszilloskopen
Fortsetzung des Artikels von Teil 2
FPGA-Debugging mit Mixed-Signal-Oszilloskopen
Die komplette Rüstzeit – bevor man die ersten Messungen durchführen kann – beträgt also etwa 2,5 Stunden. Will man die nächste Signalgruppe prüfen, braucht man etwa die gleiche Zeit, wobei man mit wachsender Routine das MSO immer schneller einstellen wird. Um alle Signale zu messen, dauert es nahezu 10 Stunden. Ein typisches Design braucht 10 bis 20 Durchgänge, bis es fehlerfrei ist. Die Zeit, die man allein für das Heraus-Routen der Signale braucht, kann man also in Tagen messen. Dazu kommt, dass man durch die ständigen Änderungen des Designs zum Heraus-Routen der Testsignale möglicherweise das Timing des ursprünglichen Entwurfs ändert, so dass man sich damit wieder eine Reihe von Problemen einhandelt.
Jobangebote+ passend zum Thema
Debugging mit Debugging-Kern
Indem man zum Debugging einen Debugging-Kern verwendet, spart mal viel Zeit und nutzt die fürs Debugging reservierten zwölf FPGA-Pins optimal aus. Debugging-Kerne für MSOs arbeiten im Multiplexverfahren. Ein Entwicklungsingenieur legt fest, welche Sätze von Signalen er gerne gleichzeitig messen möchte. Jeder Satz besteht aus so vielen Signalen, wie Pins für Debug-Zwecke zu Verfügung stehen. Eine spezielle Software namens „FPGA dynamic probe“ steuert den Debugging-Kern und überträgt die Namensdateien vom CAD-System in das MSO.
Xilinx und Agilent haben den Debugging-Kern ATC2 (Agilent Trace Core der 2. Generation) gemeinsam entwickelt. Das Designteam kann den Kern parametrieren, um die verfügbaren Ressourcen möglichst effizient zu nutzen. Im vorliegenden Fall benötigt man einen ATC2-Kern mit vier Eingangssignalgruppen zu je zwölf Einzelsignalen.
Wie lange braucht man nun für die Konfiguration und den Einbau eines ATC2-Kerns? Der Anwender stellt die Parameter für den Kern ein und ordnet die Pins und das I/O zu. Dafür braucht er etwa fünf Minuten. Um die Signale auszusuchen, braucht man etwa weitere 15 Minuten, zusammen also etwa 20 Minuten. Der Kern wird dann in den normalen Designablauf eingebracht, und zwar nach der Synthese vor dem eigentlichen Routing. Das bedeutet, dass man den Debugging-Kern hinzufügen oder wieder herausnehmen kann, ohne die originale HDL modifizieren zu müssen. Die FPGA-Design-Tools verschmelzen den Debugging-Kern mit dem ursprünglichen Design unter Erhalt der Design-Spezifikationen.
Die Schritte im einzelnen:
- Das Design synthetisieren (15 Minuten).
- Den Debugging-Kern parametrieren – wie viele Pins, welches I/O, welcher Standard? (5 Minuten)
- 12 Signale pro Signalgruppe auswählen (15 Minuten).
- Das FPGA mithilfe der vom Hersteller bereitgestellten Software routen (1 Stunde).
- Die Konfigurationsdatei in das FPGA laden.
- Die Datei mit den Signalnamen vom FPGA-Tool in das MSO laden (10 Sekunden).
- Die PGA-Pins automatisch den Digitalkanälen des MSO zuordnen (15 Sekunden).
- Signalgruppe auswählen (5 Sekunden).
Die komplette Rüstzeit liegt hier bei etwa 1,5 Stunden. 20 Minuten davon sind auf den Einbau des ATC2-Kerns zurückzuführen. Das Team wird diese Zeit (und mehr) bei den eigentlichen Messungen mit dem MSO wieder einsparen. Der Anwender wählt über eine JTAG-Verbindung aus, welche der vier Signalgruppen er an den Digitalkanälen des MSO angelegt haben möchte (Bild 3). Man kann binnen weniger Sekunden eine andere Signalgruppe anwählen. Der ATC2 rekonfiguriert sich dann selbst und erlaubt eine Messung der nächsten Signalgruppe. Viele FPGA-Designs brauchen 10 bis 20 Design-Durchläufe, bis das Design fertig ist. Wenn man für das Debugging einen Debugging-Kern einsetzt, spart das im ganzen Verlauf einige Tage Arbeitszeit.
Mit einem MSO kann man auf einfache Weise gleichzeitig sowohl die Analog- als auch die Digitalseite des DAC betrachten (Bild 4). Im Beispiel findet sich am Hochpunkt der analogen Kurve ein Glitch. Allein mit den Analogkanälen des Oszilloskops wäre man diesem Fehler nicht auf die Spur gekommen. Mit Hilfe des Debugging-Kerns hat der Entwickler schnell herausgefunden, dass der Prozessor dort einen falschen Sinuswert aus dem ROM lädt.
Ein Großteil der heutigen Embedded-System-Designs besteht aus FPGAs und einer großen Vielfalt anderer Bauteile, die an das FPGA angekoppelt sind – z.B. Analogschaltungen oder serielle und parallele Bus-Interfaces. Herkömmliche Oszilloskope arbeiten gut in der analogen Welt oder dann, wenn nicht mehr als vier Digitalkanäle gebraucht werden. Viele Steuersignale, Zustände von endlichen Automaten oder den Datenfluss auf einem parallelen Bus aber können sie weder messen noch darauf triggern.
Was die reinen Oszilloskop-Fähigkeiten anbelangt, bieten Mixed-Signal-Oszilloskope sämtliche Möglichkeiten digitaler Speicheroszilloskope und sind somit hervorragend geeignet, analoge Signale zu validieren (Bild 1). Im Folgenden wird ein Digital-Analog-Wandler-Subsystem untersucht, bestehend aus einem FPGA des Typs Spartan-3E von Xilinx und einem Digital-Analog-Wandler-Chip. Das Design wurde mit einem Spartan-3E-Protypen-Entwicklungssystem aufgebaut. Das FPGA enthält einen PicoBlaze-Prozessor, der mit 50 MHz läuft und Sinus-Theta-Werte erzeugt, die an den DAC ausgegeben werden.
Zwölf Pins des FPGA reservierte das Entwicklerteam für Debugging-Zwecke, zwölf Digitalkanäle des MSO wurden dort angeschlossen (Bild 2). Das hier verwendete MSO 6000 von Agilent bietet 16 digitale Kanäle mit einer maximalen Abtastrate von 2 GS/s, somit bleiben in dieser Applikation vier digitale Kanäle und die analogen Kanäle noch frei, um eventuell andere Signale darzustellen.
Nach einer Überprüfung der FPGA-Simulation wird das Design der realen Validierung unterzogen. Zur Validierung dieses Subsystems muss man insgesamt 45 Signale betrachten:
- die PicoBlaze-Sinus-Theta-Werte,
- die PicoBlaze-Addresse,
- asynchrone Interrupts infolge von Tasten- oder Schalterbetätigung durch den Anwender,
- 8-kHz-Ereignis-Updates,
- einen 8-bit-Aufwärtszähler,
- eine SPI-Schnittstelle.
- FPGA-Debugging mit Mixed-Signal-Oszilloskopen
- FPGA-Debugging mit Mixed-Signal-Oszilloskopen
- FPGA-Debugging mit Mixed-Signal-Oszilloskopen
- Herkömmlicher Ansatz: Heraus-Routen der Testsignale
