Anbieter zum Thema
Mit dem Tool „System Console“ adressiert Altera die Debug- und Monitoring-Anforderungen der Entwickler auf Systemebene. System Console setzt sich zusammen aus einem Kommunikationsblock, der in einem Qsys-Design instanziiert ist, und einem Software-Stack, der auf einem Host-Computer läuft. Damit werden der Soft-Core und die eigene Befehlssprache im Grunde ersetzt. System Console ist in drei Ebenen (Layer) aufgeteilt (Bild 1).
Hardware-IP-Blöcke für mehr Flexibilität
Um den benötigten Service bereitzustellen, stehen im Datentransport-Layer verschiedene Hardware-IP-Blöcke zur Verfügung, wodurch der Entwickler in der Übertragungstechnik flexibler ist. Derzeit sind JTAG, Ethernet (TCP/IP) und PLI verfügbar.
Der Presentation-Layer wiederum bietet verschiedene APIs (Application Programming Interfaces) zur Interaktion mit dem Design. Dazu zählen beispielsweise im Speicher abgebildete Transaktionen oder das Senden und Empfangen von Bytes aus einem Byte-Stream-Baustein. Alle Services auf diesem Layer sind agnostisch zum darunterliegenden Transportprotokoll und erlauben somit eine größere Flexibilität bei der Implementierung.
Der Application-Layer hat seinen eigenen Satz an APIs, um die Welt der Signale und Transaktionen in etwas zu übersetzen, das man auch verstehen kann. Dieser Layer beinhaltet eine Dashboard-API und eine Monitor-API. Mit der Dashboard-API kann der Entwickler GUI-Anwendungen erzeugen. Die GUIs können sehr einfach sein und nur den Stromwert oder eine Adresse anzeigen, sie können aber auch wirklich komplex ausfallen wie beispielsweise das EMIF-Toolkit (EMIF: External Memory Interface) von Altera. Die Monitor-API wiederum bietet einen effizienten Weg, um einen periodischen Zugang zu einer Reihe von Speicheradressen zu erzeugen.
Simulation der Applikation in System Console
Nachdem die Funktionalität auf dem Application-Layer unabhängig vom Transport-Layer ist, ist es möglich, einfach von einem Transportmechanismus zu einem anderen zu wechseln. Wenn der Designer dazu übergeht, das System zu simulieren, ersetzen die Tools automatisch den JTAG/Ethernet-Transport mit dem PLI-Transport, so dass die gleiche Applikation in System Console problemlos simuliert werden kann.
Für Systeme, die mit einem Soft-Core ausgestattet sind, kann System Console auf alle im Speicher abgebildeten Slaves zugreifen, auf die auch der Prozessor zugreifen kann. Wenn kein Prozessor implementiert ist, kann der Systementwickler sein Design mit einer Kommunikationsbrücke wie beispielsweise einem JTAG-to-Avalon-Interface-Master ergänzen. Damit erhält System Console Zugang auf alle im Speicher abgebildeten Slaves, auf die der Master zugreifen kann. Der Entwickler muss die Hardware nicht neu kompilieren, um Zugriff auf ein anderes Signal zu erhalten. Solange der Status über die Adress-Map des Slaves sichtbar ist, ist er auch für System Console sichtbar.
Durchgehendes Konzept für Wiederverwendbarkeit
Die APIs des Application-Layers werden mithilfe der im FPGA-Entwicklungs-Flow durchaus gängigen Standardprogrammiersprache Tcl implementiert. Dadurch steht eine bekannte fortschrittliche, programmierbare Entwicklungsumgebung zur Verfügung, mit der die Programmierung von einfachen Scripts bis hin zu ausgeklügelten GUI-Applikationen möglich ist. Mit dieser Programmierumgebung zum Debuggen können einzelne Signale, aber auch Transaktionsinteraktionen mit dem System analysiert werden. On Top zu den Transaktionen und den Tcl-Prozeduren können die Designer das Abstraktionsniveau aber noch weiter erhöhen und beispielsweise Paket-Header beim Router-Durchlauf oder einen Bild-Block, wenn er in der Video-Pipeline verarbeitet wird, debuggen.
Altera nutzt die Möglichkeiten der System Console-Plattform, wenn das Unternehmen neue Debugging-Tools entwickelt. Ein Beispiel ist das External Memory Interface Toolkit, das mit der System-Console-Plattform erzeugt wurde. Es liefert detaillierte Laufzeit-Informationen über das System-Interface zu externen Speichern.
* * Craig Davis... ist Product Marketing Manager bei Altera Europe.
(ID:30605640)