Entwurfsmethoden für eingebettete Systeme
(Robert Günzel, Wolfgang Klingauf, Christian Schröder)

englische Seite
     

Ziel unserer Forschung war die Erweiterung der Hardware-Software-Entwurfssprache SystemC, um die Kommunikations-Modellierung für System-on-Chip zu erleichtern und um die Austauschbarkeit der Modelle zwischen verschiedenen Tools zu vereinfachen:

  • IP-Cores verschiedener Hersteller sollen beliebig gemischt werden können, ohne dass hierzu aufwändige Kommunikationsadapter entwickelt werden müssen (GreenSocket/GreenBus).
  • Eine Middleware für Modellierungswerkzeuge (GreenControl) soll mit den beiden Plug-ins GreenConfig und GreenAV den Entwurf vereinfachen und durch das Einsetzen und Simulieren eines Modells in Tools verschiedener Hersteller vor allem die Konfigurations-Interoperabilität erhöhen.
  • Aktuelle Transaction-Level-Modellierungsstandards beziehen sich lediglich auf hohe Abstraktionsebenen. Es wird untersucht, wie ein Standard für taktgenaues Transaction-Level-Modeling aussehen kann.
     

GreenSocket/GreenBus - Interoperabilitäts-Standards für SystemC
(Wolfgang Klingauf, Robert Günzel, Christian Schröder)

     

Mit GreenBus erarbeiteten wir im Rahmen der GreenSocs-Initiative einen offenen Standard für die Kommunikationsmodellierung mit SystemC. Ziel des Projekts war eine industrieweit akzeptierte SystemC-Schnittstelle für IP-Cores, so dass IP-Cores verschiedener Hersteller unabhängig von den verwendeten Kommunikationsprotokollen zu einem System-on-Chip-Modell zusammengesetzt werden können.

Die Entwicklung erfolgte in enger Abstimmung mit namhaften Partnern aus Industrie und Forschung. Erste Ergebnisse wurden der Open SystemC Initiative (OSCI) Ende 2005 vorgestellt. Im November 2007 wurde der TLM-2.0-Standard für SystemC verabschiedet, der auf den Basiskonzepten von GreenBus aufbaut. Im Rahmen unserer Zusammenarbeit mit der OCP-IP flossen sie darüber hinaus in die OCP-Implementierung für SystemC ein.

Die GreenBus-Open-Source-Bibliothek bietet ein Simulations-Framework für verschiedene Busse und Networks-on-Chip und ermöglicht die Mixed-Mode-Simulation von heterogenen IP-Cores auf unterschiedlichen Abstraktionsebenen. Unter anderem wurde in Zusammenarbeit mit Intel ein Simulator für PCI-Express entwickelt.

2008 wurde die GreenBus-Open-Source-Bibliothek so modifiziert, dass sie vollständig den TLM-2.0 Standard unterstützt (GreenSocket und GreenRouter). Die Erkenntnisse und Erfahrungen, die dabei gewonnen wurden, flossen wiederum in die Weiterentwicklung des TLM-2.0 Standards ein, z.B. wirkte die Abteilung E.I.S. aktiv an der Überführung des OSCI-TLM-2.0-Standards in einen IEEE Standard mit. So wurde 2009 als Teil von TLM-2.0.1 das TLM-2.0-Language-Reference-Manual (LRM) als Vorstufe zur IEEE-Standardisierung veröffentlicht, an dessen Entwicklung die Abteilung E.I.S. aktiv mitwirkte.

GreenBus
Bild 1: TLM-2.0-basierte Simulation mit GreenSockets und GreenRouter

Bild 1 zeigt den Aufbau einer Simulation mit zwei IP-Cores (Producer und Consumer). Das zugrunde liegende Konzept entstammt der Forschung an GreenBus. Die inkompatiblen Kommunikations-Schnittstellen PLB und PCI der beiden IP-Cores werden durch die Protokollschicht (GreenSocket-basierte User-APIs) in das standardisierte TLM-2.0-Protokoll umgesetzt, sodass GreenRouter vollständig TLM-2.0-kompatibel arbeitet. Auf diese Weise wird eine zuverlässige Kommunikationsverbindung etabliert, und in der Verbindungsschicht können verschiedene Busse und Network-on-Chip-Varianten simuliert und bzgl. ihrer Performance in dem untersuchten System-on-Chip-Modell verglichen werden. Auf der Verbindungsschicht werden TLM-2.0-Interfaces verwendet.

     

Taktgenaue Bus-Simulation mit der Transaction-Level-Modellierung
(Robert Günzel)

     
 

Für die abstrakte Kommunikations-Modellierung wurden mit GreenBus und der auch daraus hervorgehenden TLM-2.0 große Erfolge in der Standardisierung der TLM erzielt. Für weniger abstrakte Modellierung existiert so ein Standard noch nicht. Da TLM tendenziell eine abstrakte Modellierung sein soll, drängt sich jedoch die Frage auf, ob weniger abstrakte oder gar taktgenaue TLM überhaupt notwendig ist. Dafür sollen hier die zwei wichtigsten Gründe angeführt werden.

Erstens kann es sich bei einer abstrakten Systemmodellierung und -analyse herausstellen, dass es für eine bestimmte Hardware-Komponente keinen fertigen IP-Block gibt, so dass dieser neu entwickelt werden muss. Ausgehend vom vorhandenen abstrakten Modell wird dann der fehlende Block schrittweise solange verfeinert, bis eine klassische Hardware-Synthese möglich ist. Diese Synthese-Vorgabe ist natürlich deutlich weniger abstrakt, im schlimmsten Falle entspricht sie dem Register-Transfer-Level. Die Überführung der am wenigsten abstrakten, noch standardisierten TLM-Darstellung in eine synthetisierbare ist in einem Schritt für nicht-triviale Funktionsblöcke kaum machbar. Das Verlassen der TLM-Welt, also der Übergang von relativ einfachen Schnittstellen hin zu RTL-Schnittstellen mit hunderten von Signalen sollte aber möglichst spät im Entwurf passieren, nur leider gibt es keinen weniger abstrakten TLM-Standard. Der Entwickler muss entweder zwei wahrscheinlich verschiedene TLM-Modellierungen beherrschen (die standardisierte abstrakte und eine proprietäre taktgenaue), oder das Modell muss an einen Experten für die taktgenaue Modellierung übergeben werden. Der erste Fall stellt eine große Belastung des Entwicklers dar, insbesondere wenn bei der taktgenauen TLM wieder mehrere grundverschiedene proprietäre TLM-Schnittstellen existieren. Der zweite Fall ist teuer und birgt das Risiko von Missverständnissen, die bei der Übergabe der Modelle passieren.

Der zweite Hauptgrund für den Bedarf an taktgenauem TLM besteht darin, dass die Ergebnisse einer abstrakten TLM-Simulation für diverse Fragestellungen nicht ausreichen. Während im abstrakten Modell die Aussage genügen mag: „Circa 100 MHz liefern eine ausreichende Antwortzeit“, kann beispielsweise bei einem mobilen Gerät die Entscheidung zwischen 95 oder 100 MHz den entscheidenden Marktvorteil einer längeren Akkulaufzeit bedeuten. Dann benötigt man eine präzise Aussage, ob 95 MHz ausreichen. Während solche Vorhersagen mit Register-Transfer-Modellen berechnet werden können, ist die Performance solcher RTL-Simulationen im Vergleich zur abstrakten TLM sehr gering. Ideal wäre daher ein abstraktes TLM-Modell, das trotzdem wesentliche Aussagen des präzisen RTL-Modells effizient liefert.

Taktgenaue TLM ist folglich notwendig. Gäbe es dafür einen Standard, würden sich für die IP- und Werkzeughersteller Aufwand und Kosten reduzieren, da nicht eine Vielzahl von proprietären taktgenauen „Standards“ unterstützt werden müssen. Falls ein solcher bisher fehlender Standard für taktgenaues TLM darüber hinaus auf den Mechanismen des vorhandenen abstrakten Standards TLM-2.0 aufbauen würde, falls also die Standards nahe beieinander liegen würden, müssten Entwickler nur wenig hinzulernen, um sowohl abstrakt als auch taktgenau modellieren zu können.

Aus diesem Grund forschten wir an einem Vorschlag für ein Standard-Interface für taktgenaue TLM von Funktionsblöcken und Kommunikationsstrukturen mit memory-mapped Bus-Interfaces in Analogie zum vorhandenen TLM-2.0. Wie erwähnt sollte ein taktgenaues TLM-Modell möglichst viel abstrahieren und immer noch gewünschte Aussagen liefern. Beides musste präzisierbar sein: Wovon wird abstrahiert? Welche Aussagen sind trotzdem möglich? Daher haben wir die taktgenaue TLM-Simulation genauer untersucht und Möglichkeiten zur Abstraktion gefunden, die die Taktgenauigkeit der gewünschten Simulationsaussagen nicht gefährden.

Bei unserem Vorschlag für einen taktgenauen TLM-Standard wurde nachgewiesen, dass die bereits in TLM-2.0 vorhandenen Mechanismen im Wesentlichen ausreichen, jedoch wurden einige Erweiterungen und Änderungen von TLM-2.0 nötig. Neben diesen generischen Änderungen von TLM-2.0 wurden auch Regeln bestimmt, wie spezielle memory-mapped Bus-Interfaces auf den um Taktgenauigkeit erweiterten TLM-2.0-Standard abgebildet werden können. Zusätzlich haben wir auch noch untersucht, wie der verwendete SystemC-Simulator für taktgenaue Modelle wesentlich optimiert werden kann.

Nicht zuletzt auch aufgrund unserer Expertise im Bereich der taktgenauen Modellierung war die Abteilung E.I.S. im Rahmen unserer Mitarbeit in der Open-Source-Initiative GreenSocs auch in die OCP-IP (Open Core Protocol - International Partnership) eingebunden. Gemeinsam mit CoWare, Nokia, Sonics und Texas Instruments arbeiteten wir in der System-Level-Design Working-Group und haben dazu beigetragen, die SystemC-Implementierung der OCP-TLM-Kanäle zu verbessern und neuartige, GreenBus-basierte OCP-TLM-Kanäle zu entwickeln und zu untersuchen. Die GreenSocs-Initiative wurde in 2007 mit dem Titel "OCP-IP Contributor of the Year" ausgezeichnet.

Mit Hilfe der Ergebnisse der oben genannten Untersuchungen wurde das OCP-TLM-Paket komplett auf den neuen TLM-2.0 Standard umgestellt. Die Möglichkeit, mit diesen neuen OCP-TLM-Kanälen taktgenaue TLM-Modelle zu erstellen, geht weit über den Rahmen des TLM-2.0-Standards hinaus, welcher ursprünglich für höhere Abstraktionsebenen entworfen wurde. Damit wurden unsere Forschungsergebnisse bezüglich taktgenauer TLM in industriellem Umfeld erprobt und angewendet.

     

Konfigurations-Interoperabilität von Hardware-Software-Modellen in SystemC
(Christian Schröder)

     

Zum Bewältigen der steigenden Komplexität bei der Plattformentwicklung wird im modernen ESL-Design eine hohe Abstraktion bei der Simulation der Systeme gewählt. Im Zuge dessen hat sich die Systembeschreibungssprache SystemC durchgesetzt. Die verschiedenen High-Level-Modelle eines Systems werden von unterschiedlichen IP-Herstellern zur Verfügung gestellt. Für die Architektur-Exploration muss der Designer in der Lage sein, die Modelle schnell und ohne viel Aufwand zusammen mit selbst erstellten Modellen in der jeweils gewünschten Entwicklungsumgebung integrieren zu können. Das bedeutet, dass die Modelle mit wenig Aufwand interoperabel sein müssen. Mit dem OSCI-TLM-2.0-Standard ist die Interoperatibilitäts-Ebene für die Kommunikation von SystemC-Modellen auf hoher Abstraktion standardisiert worden, taktgenaues Transaction-Level-Modeling wird an der Abteilung E.I.S. erforscht. Damit sind nun Modelle verschiedener Hersteller – unter bestimmten Voraussetzungen – funktionell interoperabel. Wir definieren dies als Real-Interoperabilität. Sie deckt diejenigen Elemente eines Modells ab, die für die (optionale) Realisierung in Hard- oder Software bestimmt sind.

Eine weitere – vom OSCI-Standard nicht behandelte – Interoperabilitäts-Ebene ist die der Tools. Modell-Hersteller entwickeln ihre SystemC-Modelle mit unterschiedlichen Entwicklungsumgebungen. Diese verwenden jeweils unterschiedliche Mechanismen zum Konfigurieren und Kontrollieren der Modelle. Die Mechanismen adressieren jeweils verschiedene Schwerpunkte und sind für das jeweilige Einsatzgebiet bewährt, allerdings inkompatibel zueinander. Auch wenn die Modelle aufgrund des Kommunikations-Standards funktional kompatibel sind, muss der Plattform-Entwickler sich beispielsweise mit den unterschiedlichen Konfigurationsmechanismen beschäftigen. Diese über die Real-Interoperabilität hinausgehende, auf Tools abzielende Interoperabilität nennen wir Meta-Interoperabilität.

Unsere Forschung beschäftigt sich mit dieser bisher fehlenden Meta-Interoperabilität mit Schwerpunkt auf der Modell-Konfiguration, worunter das Setzen und Auslesen von Eigenschaften eines Modells vor oder während der Simulation verstanden wird. Dabei wurden zwei Ansätze verfolgt: Einerseits wurde ein flexibler Konfigurationsmechanismus entwickelt, der in der Lage ist, verschiedene andere z.B. kommerzielle Mechanismen miteinander zu verbinden und eine einheitliche API zur Verfügung stellt. Andererseits haben wir in der OSCI-Arbeitsgruppe Configuration, Control & Inspection (CCI) an der Standardisierung mitgearbeitet.

     

Modell-Middleware GreenControl, Konfiguration mit GreenConfig und Analyse mit GreenAV
(Christian Schröder)

     

GreenControl ist eine Middleware-Plattform für Modellierungswerkzeuge. Sie soll mit den beiden Plug-ins GreenConfig und GreenAV den Entwurf von SystemC-Modellen vereinfachen und das Simulieren der Modelle in Tools verschiedener Hersteller erleichtern und damit die Austauschbarkeit erhöhen.

GreenControl und die Plug-ins sind zusammen mit GreenSocs und bekannten Firmen wie beispielsweise Intel und Texas Instruments im Zeitraum 2007 bis 2011 entstanden. Unterschiedliche Dienste können als Plug-ins geladen werden, und "User-APIs" ermöglichen den Zugriff auf die Plug-in-Funktionen mit unterschiedlichen Programmierschnittstellen (Bild 1).

Middleware
Bild 1: Schematischer Aufbau der Middleware GreenControl mit Konfigurations-Plug-in GreenConfig und konfigurierbarem Modell

Der Konfigurationsmechanismus GreenConfig stellt konfigurierbare Parameter bereit, die auf verschiedene Weise vor und während der Simulation konfiguriert werden können. Es gibt verschiedene APIs für Skriptsprachen und Adapter zu Konfigurationsmechanismen kommerzieller Entwicklungswerkzeuge. Die Modell-Middleware GreenControl stellt eine flexible Anbindung für Adapter zu den Mechanismen zur Verfügung. Bild 2 stellt ein Beispiel-Scenario dar. Es gibt zwei Integrationsrichtungen:

  1. Ein mit einem herstellerspezifischen Konfigurationsmechanismus erstelltes Modell kann an den universellen Mechanismus GreenConfig angeschlossen und damit konfiguriert werden (vgl. Bild 2 rechts).
  2. Ein herstellerspezifischer Konfigurationsmechanismus (Tool) kann an das universelle Framework angeschlossen werden, sodass die Konfiguration von herstellerfremden Modulen innerhalb des Tools möglich wird (vgl. Bild 2 links).

Konfigurations-Interoperabilität
Bild 2: Interoperable Konfiguration

Experimente zeigen erfolgreiche Integrationen in beide Richtungen z.B. in den Tools CoWare Platform Architect und Synopsys Innovator.

Der Dienst GreenAV erlaubt die Analyse und Visualisierung von Daten, die zu Debug-Zwecken vom Entwickler beobachtet werden sollen.

Das Projekt GreenReg (2008-2009) ist ein Register-Framework, das ein Anwendungsfall für die Integration von GreenConfig-Parametern ist, sodass modellierte Register mit allen Möglichkeiten des GreenConfig-Frameworks konfiguriert werden können.

Die Projekte sind bei GreenSocs als Open-Source unter freier Lizenz verfügbar und werden von Firmen wie Intel und TI verwendet.

     

SystemC-Remote-Service-Interface (SCRSI)
(Christian Schröder, Robert Günzel)

     

Das SystemC-Remote-Service-Interface (SCRSI) ist ein grafisches Front-End für die Dienste von GreenControl, das in verschiedenen studentischen Arbeiten zwischen 2008 und 2011 entstanden ist. Es bietet eine interaktive Simulationssteuerung (Kontrolle des Simualtionsablaufs), das Konfigurieren, Lesen und Beobachten von GreenConfig-Parametern sowie das Erzeugen von aus Parametern zusammengesetzten Formeln und konditionale Breakpoints. Die während der Simulation laufend aktualisierten Berechnungsergebnisse können grafisch angezeigt werden (siehe Bild 3).

SCRSI Screenshot
Bild 3: SCRSI-Fenster mit live dargestelltem Parameterverlauf

     

Mitwirkung am Konfigurations-Standard CCI
(Christian Schröder)

     

Die Ergebnisse aus der Forschung an der Konfiguration von Modellen sind in die OSCI-Arbeitsgruppe Configuration, Control & Inspection (CCI) eingeflossen. Die Abteilung E.I.S. war zwischen 2009 und 2011 als Mitglied der GreenSocs-Initiative maßgeblich an der Entwicklung des Standards und eines Prototypen beteiligt.

     

TRAIN - Synthese von System-on-Chip-Kommunikationsarchitekturen
(Wolfgang Klingauf)

 


Ziel des Forschungsprojekts TRAIN (Transaction Interchange) ist, abstrakt modellierte Kommunikation wie in Bild 1 automatisch in eine geeignete Hardware-Software-Kommunikation abzubilden. Aus einem SystemC-Modell werden dazu die benötigten Daten mit GreenControl extrahiert und in ein GreenBus -basiertes Systemmodell umgesetzt (Bild 2).

High-Level-Kommunikation durch Methodenaufruf

Bild 1: High-Level-Kommunikation durch Methodenaufruf

TrainRPC-Kommunikation über GreenBus

Bild 2: TrainRPC-Kommunikation über GreenBus

Das Beispiel zeigt zwei Proxy-Module, die den Methodenaufruf getPixel() auf das GreenBus-Protokoll abbilden. Verschiedene Kommunikationsarchitekturen können nun mit Hilfe der GreenBus-Bibliothek simuliert und miteinander verglichen werden, um eine optimale Systemkonfiguration zu finden.

Synthetisiertes Hardware-Software-System mit PLB-Bus und Train-Kommunikationsadaptern

Bild 3: Synthetisiertes Hardware-Software-System mit PLB-Bus und Train-Kommunikationsadaptern

Abschließend kann die Hardware verfeinert und mit einem Synthesewerkzeug in ein Gatternetz für den endgültigen Chip umgewandelt werden. Die Kommunikationsverbindung zwischen Hardware und Software über Busse oder ein Network-on-Chip soll dabei komplett automatisch erzeugt werden. Bild 4 zeigt dies an dem endgültigen Hardware-Software-System für das getPixel()-Beispiel. Das Hardware-Modul wurde mit einer Open-Core-Protokoll-Schnittstelle (OCP) ausgestattet. Durch Kommunikationsadapter kann das Hardware-Modul nun an verschiedene Busarchitekturen angebunden werden.

Auf der Software-Seite wurde ein Hardware-Abstraction-Layer generiert und der Prozessor mit einem CPU-Adapter ausgestattet. Dieser Kommunikations-Coprozessor stellt die Verbindung mit dem Hardware-Moduls und schließt so die Brücke zwischen Hardware und Software.

Ziel unserer Forschungsarbeiten ist die automatische Generierung aller benötigten Kommunikationsadapter, sowohl für Hardware als auch für Software (Bild 4). Aktuell werden zwei Prozessoren, der IBM PowerPC-405 und der Xilinx MicroBlaze unterstützt. Mit diesen Adaptern wurde das Verfahren erfolgreich an einem Video-Prozessor zur Echtzeit-Erkennung von Körpergesten erprobt.

2008 wurde ein Verfahren zur automatischen Integration von IP-Cores entwickelt. Hierzu wurde eine IP-Schnittstellen-Beschreibungssprache definiert und ein Tool geschaffen, das Kommunikationsadapter automatisch aus IP-Schnittstellenbeschreibungen generiert. Die Ergebnisse dieser Arbeit wurden im Dezember 2008 auf der IEEE International Conference on Embedded and Ubiquitous Computing in Shanghai präsentiert.

TRAIN Kommunikationsarchitektur-Synthese

Bild 4: TRAIN Kommunikationsarchitektur-Synthese