Flexible Methode zur Verifikation von FPGA-Prototypen-Boards beweist ihre Praxistauglichkeit

Komplette Systeme per RTL-Simulation zu verifizieren, sie von der SoC-Hardware über das Betriebssystem bis hinein in die Applikation zu untersuchen, fordert eine ganze Menge Rechenleistung. Die Simulation sollte möglichst rasch ablaufen – wenn ein Prozessor-Kern im SoC aber erst ein komplexes Betriebssystem booten soll, bis sich mögliche Bugs zeigen, dann fordert das enorme Geduld beim Entwickler. Stundenlang warten auf ein Ereignis, das im fertigen System binnen Sekunden eintritt, erlaubt kein effizientes Arbeiten.

Ein FPGA-basierter Prototyp des Systems sorgt hingegen für sehr realistische Geschwindigkeiten, oft identisch mit dem fertigen Chip. Haben die Entwickler aber einen Fehler gefunden, dann müssen sie erst mühsam die Quelle aufspüren. Ähnlich wie ein Software-Entwickler, der Debug-Ausgaben manuell in sein Programm einfügt und es neu übersetzt, kann der Hardware-Inge­nieur die interessanten Signale an einzelne FPGA-Pins herausführen und dort zum Beispiel mit einem Oszilloskop aufnehmen. Deutlich besser sind In-Circuit-Emulatoren. Aber auch hier dauert das Definieren der Signale lange und ihre Anzahl ist begrenzt. Außer­dem fehlt der Rückschluss von den Signalen in den FPGA-Gates auf die vertraute RTL-Ebene.

Springsoft hat mit dem hauseigenen Produkt Verdi und dem neuen Protolink Probe Visualizer (Bild 4) eine Lösung im Programm, die jedes FPGA-Board mit einem 64 Bit breiten Bus an eine Interface-Karte anbindet, bei Bedarf tausende Signale aufzeichnet und sie direkt in der RTL-Umgebung anzeigt (Bild 1). Sogar das Einführen neuer Messpunkte ist in Minuten erledigt.

Androiden von innen

Wie gut diese Technik in der Praxis funktioniert, untersuchte Springsoft gemeinsam mit dem taiwanesischen Industrial Technology Research In­stitute (ITRI). Das Institut unterstützt die taiwanesische Industrie bei der Erforschung und Entwicklung neuer Technologien und Methoden auf dem Gebiet des IC-Designs und beschäftigt sich dabei mit FPGA-basierten Plattformen für die Verifikation von SoCs. Dem ITRI ist es gelungen, die Verifikationseffizienz eines kundenspezifischen FPGA-basierten Protoypen-Boards durch die Automatisierung der bestehenden In-Circuit-Emulation erheblich zu steigern und mehr Signale des FPGAs sichtbar zu machen.

Bei dem betreffenden SoC-Design handelt es sich um eine zu Android kompatible Hochleistungsmultimediaplattform, die AXI-, AHB- und APB-Busse für die Kommunikation nutzt (siehe Bild 5). Von ITRI entwickelte High-Performance-IPs, wie PACDSPs, EMDMA und DDR2-Con­troller nutzen den AXI-Bus und dienen als Multimedia-Beschleuniger (zum Beispiel H.264-Video-Codec). Einige Schaltungsblöcke, wie ARM, SDRAM, DMA, SRAM, Ethernet und LCD, sind mit dem AHB-Bus vernetzt und werden von der eigentlichen Applikation genutzt. Schließlich gehören zum SoC niederfrequente Schaltungsteile, wie UART, ART, Timer, I2S, I2C und Watchdog, die am APB-Bus angeschlossen sind.

Auf der Suche nach der Störquelle

Bei den Tests stellt sich heraus, dass die Audiofunktionen (Aufnahme und Wiedergabe) zunächst problemlos auf dem FPGA-Prototypen-Board funktionierteen, allerdings nur, bis das Betriebssystem gebootet wurde. Solche Probleme sind in FPGA-Prototyping-Umgebungen schwierig zu beheben, da die traditionelle Debug-Methode nur eine eingeschränkte Sicht auf die Signale im FPGA gewährt und das auch nur für eine begrenzte Zyklenzahl. So gesammelte Informa­tionen reichen nicht aus, um das Problem zu lokalisieren. Auch eine RTL-Simulation ist kein gangbarer Weg, da das simulierte Booten des Betriebssystems (hier: Linux) ohne FPGA-Leistung sehr lange dauern würde. Da der beschriebene Fehler sowohl durch die Software, als auch die Hardware oder die Treiber ausgelöst worden sein kann, ist vorab kaum zu klären, wer die Verantwortung für die Fehlerbehebung übernehmen sollte (Bild 3). Es ist also eine Verifikationsmethode von Nöten, die das Debuggen vereinfacht.

Anfänglich befürchtete das ITRI, dass das eingesetzte kundenspezifische Prototypen-Board die Voraussetzungen für den Anschluss des Protolink Probe Visualizer nicht erfüllen würde. Nach einigen schnellen Tests konnte Springsoft nachweisen, dass sich der J-Stecker des Boards für den Anschluss des Visualizers eignet. Es musste nur ein PLL auf dem Board installiert werden, der den Abtastimpuls liefert. Der Setup-Prozess war schnell in die bestehenden Skripte eingebaut. Etwa 100 Messpunkte wurden eingerichtet – sechsmal mehr Signale, als sich der Anwender in der Vergangenheit anzeigen lassen konnte –, wobei das Prototpyen-Board mit 24 MHz getaktet wird. Die erfassten Daten werden nun in einem externen Speicher (2 GByte) abgelegt, um keine FPGA-Ressourcen zu verschwenden. Dadurch nimmt die zusätzliche Messpunkt-Logik auch nur zwei Prozent des FPGAs in Anspruch.

Gedächtnisleistung

Dank des externen Speichers können die Inge­nieure die Signale über ausreichend viele Zyklen hinweg aufzeichnen und die Zusammenhänge zwischen Software, Hardware und Treiber nachvollziehen. Nach einigen Debug-Durchläufen wurden denn auch zwei Fehler gefunden. Zum einen sperrte der USB-Interrupt den ARM über längere Zeit, so dass der I2S-FIFO leer war, was zum beobachteten Fehlerbild führte. Zum anderen hatte der Timer-Interrupt eine höhere Priorität als der DMA-Interrupt, was ebenfalls bewirkte, dass der I2S-FIFO leer war – nur ein Fehlerbild, aber zwei verschiedene Ursachen mit unterschiedlichem Hintergrund (Bild 2).

Howard Mao ist der verantwortliche Senior Director für die Produktfamilie Protolink von Springsoft.Springsoft

Mit Verdi in der RTL-Domäne debuggen zu können (Bild 1), ist einer der zentralen Vorteile. Anwender können die Tracing-Funktionen nutzen, um die Fehlerursache wie gewohnt im vertrauten RTL-Code zu ermitteln. Während des Debuggens stoßen Anwender eigentlich immer auf kritische Signale, die sie untersuchen wollen, die aber nicht in der ursprünglichen Liste der Messpunkte enthalten sind. Probe Visualizer ECO hilft dem Anwender dabei, die Liste zur Lösung des Problems schnell um zusätzliche Messpunkte oder Signale zu erweitern. Im geschilderten Fall hatten die Ingenieure zehn zusätzliche Signale in nur zehn Minuten hinzugefügt. Dies bedeutet eine große Zeitersparnis gegenüber der traditionellen Debug-Methode, bei der Anwender erst für die Überwachung vorgesehene Signale im RTL-Code definieren und anschließend das System neu synthetisieren, platzieren und routen muss. Beim ITRI-SoC-Design hätten Synthese und Place&Route etwa zwei bis drei Stunden gedauert. Die Springsoft-Lösung arbeitet wesentlich schneller und ermöglicht mehrere Debug-Iterationen pro Tag.

Zeitersparnis

Nach erfolgreicher Behebung des Problems und Übergabe des Designs an die Fertigung wurde analysiert, wie viel Zeit die einzelnen Phasen des Projekts in Anspruch genommen hatten. Ungefähr zwei Monate dauerten das RTL-Design, die Simulation, die Verifikation des Protokolls und die FPGA-Implementierung. Wesentlich weniger Zeit – etwa zwei Wochen – wurden auf das Portieren des Treibers und dessen Verifikation verwendet. In der Vergangenheit hatten sich die Ingenieure schon einmal einem Audio-Problem zwei Monate gewidmet, wobei sie einen Logikanalysator für die Überprüfung der FPGA-internen Signale nutzten und Prüfpunkte in den Treiber einbauten, um so eine Korrelation herzustellen und den Fehler zu finden (Bild 3). Trotz des hohen Aufwands blieb dieser Ansatz erfolglos. Das frustrierende Debuggen des FPGAs nahm fast genauso viel Zeit in Anspruch wie die Schaltungsentwicklung. Nach einer Einarbeitungszeit von etwa einer Woche und mit Unterstützung durch Springsoft, konnten die Ingenieure die zwei oben beschriebenen Fehlerursachen mit dem Probe Visualizer innerhalb von nur einer Woche abklären.

Vext Chen, Technical Deputy Manager beim Taiwanesischen Industrial Technology Research Institute (ITRI) in der für die Design-Flow-Entwicklung zuständigen Abteilung.Springsoft

Anwender sind mit dem Protolink Probe Visualizer nicht mehr auf konventionelle Verfahren zum Debuggen von Software angewiesen, die bei Echtzeitapplikationen zu Problemen an anderer Stelle führen könnten. Da bei dem neuen Verfahren die Software nicht verändert werden muss und wesentlich mehr Signale des auf das FPGA gemappten Designs über viele Millionen Taktzyklen hinweg beobachtet werden können, erhalten Anwender einen deutlich tieferen Einblick in das Designverhalten und können Fragestellungen merklich schneller klären.

Probe Visualizer ECO reduziert zudem die Setup-Zeit, die sonst beim Einfügen zusätzlicher Signale anfällt. Anwender können zusätzliche Signale direkt von Verdi via Drag&Drop in den Probe Visualizer ziehen und haben die Signalverläufe der zusätzlichen Signale innerhalb von Minuten zur Verfügung. Wenn das Design Schaltungsblöcke einschließt, für die nur die EDIF-Beschreibung vorliegt, aber nicht der originale RTL-Code, kann Probe Visualizer ECO auch mit EDIF arbeiten, so dass die Ingenieure auch Signale in Black-Box-IP überwachen können.

Verifikation erleichtert

Der Probe Visualizer gewährt eine umfassende Echtzeitsicht auf das Design. Mit der Leistungsfähigkeit von Verdi ergeben sich völlig neue Möglichkeiten bei der Prototypen-Verifikation. Der Zeitaufwand für das Debuggen eines Prototyps reduziert sich gegenüber traditionellen Ansätzen auf die Hälfte. Die erhöhte Debugproduktivität und Verifikationseffizienz erlaubt es Unternehmen, FPGA-basierte Prototypen früher im SoC-Entwicklungsprozess einzusetzen und schnell auf die nächste Generation der Prototypen-Boards umzusteigen, die mit den jeweils aktuellen und größten FPGAs ausgestattet sind. 

(lei)