Systemdesign / embedded-Test-Design Abstraktion als Explorationskatalysator

Mit der verteilten Natur moderner eingebetteter Elektronik wird es wesentlich, eine astronomische Anzahl von Realisierungsmöglichkeiten einer Aufgabe zu implementieren und zu evaluieren. Wir sprachen mit Prof. Dr. Andy Pimentel von der Universität Amsterdam über das geeignete Abstraktionsniveau.

DESIGN&ELEKTRONIK: Weshalb sollte man bei eingebetteten Systemen den Designraum erkunden?

Prof. Dr. Andy Pimentel: Im industriellen embedded-Segment herrschen viele unterschiedliche Designattribute. Vor allem, da solche Systeme oft batteriebetrieben ohne aktive Kühlung laufen müssen, aber gleichzeitig
viele unterschiedliche Anwendungen und Standards unterstützen sollen.

Dann ist aber auch Verlässlichkeit und Flexibilität gefordert. Dazu müssen Systeme hochgradig programmierbar sein, aus Performanz, Energieeffizienz und Kostengründen wesentliche Funktionen direkt in Hardware implementiert werden. Daher beinhalten moderne Embeddedsysteme heterogene Vielkern-SoCs, deren Prozessoren von voll programmierfähig, bis hin zu reiner Hardware für zeitkritische Aufgaben variieren. Um der Komplexität solcher Designs Herr zu werden, hat sich innerhalb der letzten zwei Dekaden der Elektronikentwurf auf Systemebene etabliert, der letztendlich Abstraktion einer Komponente auf unterschiedlichen
Verhaltensebenen meint.

Da höhere Abstraktion mit einer Simulationsbeschleunigung einhergeht, eignet sich die Systemsimulation zur Erkundung des Designraumes. Mit diesem Vorwissen kann die Frage beantwortet werden: Ein Task auf Serviceebene kann in einem eingebetteten System auf unterschiedliche Arten realisiert werden. Es ist Aufgabe des Designers zu prüfen, welche dieser Realisierungen seinen Nebenbedingungen am ehesten entspricht.


D&E: Auf der mathematischen Seite?

AP: Das Abfahren aller dieser unterschiedlichen Realisierungen fällt ebenso wie das Problem des Handlungsreisenden in die Kategorie NP-hart. Wenn Sie so wollen, können Sie für alle Nebenbedingungen wie Performanz, Energieeffizienz oder Kosten eine eigene Scorefunktion definieren und diese zu einem Gesamtscore kombinieren.

Der Gesamtscore kann dann auf unterschiedliche Arten maximiert werden, ein hoch-performantes Vielkern-SoC ist eventuell formal genauso gut, wie ein langsamer aber wesentlich günstiger Kandidat.Sie könnten auf dem Lösungsraum nach einer Ordnung suchen, in dem Sinne, dass alle Einzelscorefunktionen sukzessiver Lösungen monoton verlaufen. Dieses Schema trennt aber den Lösungsraum in disjunkte Bereiche. Interessant ist dabei die sogenannte Paretofront, d.h. eine Lösungsmenge die sich nicht derart ordnen lässt. Über den hinreichend besten Lösungspunkt entscheidet dann der Designer.

Generell sollten Sie in der Lage sein, den Gesamtscore einer Lösung zu evaluieren und eine Suchstrategie für weitere Lösungen anzugeben. Dies wächst selbst zum Optimierungsproblem Auflösung vs. Explorationsgeschwindigkeit. Manchmal wird dabei Abdeckung gegenüber Auflösung bevorzugt.