Hardware / Software Codesign

Hardware Software
CoDesign
Einführung
Optimierung
A. Steininger
Vorstellungen zur LVA
Was ist überhaupt HW/SW Codesign?
Was lerne ich in dieser LVA?
Wofür brauche ich das Wissen später?
2 A
A. Steininger TU Vienna
Was ist HW/SW Codesign?
paralleler Entwurf HW/SW



schneller
Bugs früher sichtbar
höherer Abstraktionsgrad
Partitionierung HW/SW

übergreifende Optimierung
Integration v. Systemen aus/mittels HW/SW


3
systematische Schnittstellendefinition
Komplexitätsbewältigung
A. Steininger TU Vienna
Embedded Systems: Challenges
„An exploding number of embedded reactive
heterogeneous components in mass-market products“
„Massive seamless integration of heterogeneous
components in a real-world environment“
„Building systems of guaranteed functionality and
quality at an acceptable cost is a major technological
and scientific challenge“
[Joseph Sifakis, Workshop on Strategies for Embedded Systems 2005]
4
A. Steininger TU Vienna
The Constraints
Dependability

safety, security, availability
[Joseph Sifakis,
Workshop on Strategies for Embedded
Systems 2005]
Autonomy

no humans in the loop
Low resource consumption

memory, power, energy
Physical constraints

weight size, heat dissipation, …
Market positioning

5
optimal cost/quality, time to market
A. Steininger TU Vienna
The System-Centric Approach
Joint Design (HW, SW,
Environment) to determine
cost / quality tradeoffs
Requires a combination of
competencies in SW, automation, networks, electronics,
man-machine interfaces
=> training, education
[Joseph Sifakis, Workshop on Strategies for
Embedded Systems 2005]
6
A. Steininger TU Vienna
The Current State
no unified theory to
predict the dynamic
properties of a SW
running on a given
execution platform
complex systems are
built through a succession of incremental
developments
exploding validation
costs
7
[Joseph Sifakis, Workshop on Strategies for
Embedded Systems 2005]
A. Steininger TU Vienna
Anwendungsbeispiele
Consumer-Products
unglaubliche Features
kleiner Preis, kleine Größe,
lange Akku-Lebensdauer
Mobiltelefonie
zusätzlich Mixed-Signal Design
Automotive
extreme Anforderungen
bezügl. Sicherheit & Preis
8
A. Steininger TU Vienna
Die Herausforderungen
Miniaturisierung

mixed signal, dynamische Rekonfiguration,
Energiebudget

Rekonfiguration, power management,…
Komplexität

Interfaces, formale Verifikation
Produktivität / Time to market

Abstraktionsebenen, Automatisierung
Fehlertoleranz
9
A. Steininger TU Vienna
Das zentrale Problem
globale Optimierung der Gesamtlösung


optimale SW + optimale HW ist zu wenig!
=> optimale Aufteilung (Partitioning) ist nötig
Abhängigkeit von den Randbedingungen
hier gibt es derzeit keinen Tool-Support





10
Tools optimieren nur HW bzw. SW allein
Problem ist extrem komplex (Lösungsraum!)
Wie formuliere ich Optimalität überhaupt?
Interfaces zwischen Tools ungeeignet
viele Entscheidungen (Partitioning!) trifft ein Entwickler aus
Erfahrung
A. Steininger TU Vienna
Ziel der VO + LU
Bewusst-Machen der Problematik
Analysieren der Trade-offs
Verständnis für den Optimierungsprozess,
dessen Kriterien und Randbedingungen
Vermitteln erster eigener Erfahrungen
Non-Target: Kennenlernen bestehender Tools
11
A. Steininger TU Vienna
Prinzip einer Optimierung
Mittels eines Algorithmus soll
eine Kostenfunktion minimiert oder
eine Nutzenfunktion maximiert werden
und zwar unter
Einhaltung von Randbedingungen
Als Voraussetzung müssen daher
Kosten / Nutzen meßbar und
alle Randbedingungen bekannt sein
12
A. Steininger TU Vienna
Erfassen der Eigenschaften
die relevante Eigenschaften müssen erfasst
werden


quantitativ, hinreichend genau
schon früh im Design Flow
Ist das realistisch möglich?

Tools erstellen Schätzungen auf Basis von


13
vereinfachten Modellen
Heuristiken
A. Steininger TU Vienna
Diskussion  Vor-Auswahl
Wählen Sie für die folgende Diskussion eine
der Anwendungen (je Gruppe eines)






14
Einspritzelektronik im Auto
Herzschrittmacher
Fließbandsteuerung
Bildkompression für Raumsonde
MP3-Player
Bankomat
A. Steininger TU Vienna
Diskussion Fragen
Welche Anforderungen an das Produkt
(= Embedded System, nicht Gesamtprodukt)
bestehen?



Was fällt in die Klasse „Kosten“/“Nutzen“ ?
Was fällt in die Klasse Randbedingung ?
Was ist speziell an Ihrem Anwendungsbereich?
Wie kann man sie zum Zeitpunkt des
Partitioning quantitativ erfassen?
15
A. Steininger TU Vienna
Optimaler Tradeoff
Wie vergleicht man quantitativ




16
Speicherverbrauch
physikalische Größe
Performance
Preis
A. Steininger TU Vienna
Gegebene Plattform
Typisches Szenario


gegeben ist Prozessor
FPGA für Spezialfunktionen
=> SW
=> HW
Reales Problem



17
optimale Nutzung des vorh. Prozessors
(„Einsparen“ bringt keinen Gewinn!)
optimale Nutzung des FPGA
Es geht um ein „optimales“ Verschieben von
Tasks zwischen FPGA und Prozessor
A. Steininger TU Vienna
Multicore
eleganter Work-Around um die Design-Crisis
Problemverschiebung in die SW (= auf höhere Ebene)
ABER: hohe Parallelität ist in SW nicht üblich
in ca. 10 Jahren werden Prozessoren 128 cores haben


läßt sich dafür eine SW schreiben, die deren volles Potenzial
nutzt?
wie weit lassen sich Tasks sinnvoll partitionieren?
Das Kommunikationsnetz spielt eine zentrale Rolle in
diesen Architekturen
18
A. Steininger TU Vienna
Network on Chip (NoC)
Chip umfasst reguläres Array von „Knoten“
dazwischen fixer Interconnect (NoC),
oft mit Router
Beispiel:
K
R
derzeit intensive Forschung auf NoC
19
A. Steininger TU Vienna
Die Hardware der Zukunft (?)
Chip mit Vielzahl (einfacher) CPU Cores
Pool von Special Function Units
(Multiply, FFT, …)
Pool von programmierbarer „glue logic“
Hierarchische Strukturierung für bessere Effizienz
(z.B. 4 Cores teilen Gruppe von SFUs und Logic
Blocks)
programmierbare Verbindungen
zentraler Takt (?) , GALS ?
Grenze HW/SW verschwimmt zunehmend
20
A. Steininger TU Vienna
Non-Functional Requirements
Trend zu Spezifikation/Entwurf auf hoher
Abstraktionsebene
Dort ist Funktion im Zentrum, keine „Details“
In Embedded Systems geht es aber
wesentlich um




21
Leistungsaufnahme/Energieverbrauch („pJ/instr“)
Physikalische Größe
Preis
Echtzeitverhalten, …
A. Steininger TU Vienna
Synchrones Design
erlaubt Abstraktion des Zeitverhaltens


22
synchrone HW: „Zustand“ statt Zeitverlauf
Sicherstellung: statische Timing-Analyse
TT-Architecture: „Zustand“ statt Folgen von Events
Sicherstellung: Worst-Case Execution Time Analyse
bringt entscheidende Vereinfachung des Design
einfacher, übersichtlicher „contract“ zwischen allen
Modulen
ABER: für diesen contract werden zusätzliche (Zeit-)
Bedingungen eingeführt
… und sind auch einzuhalten !
A. Steininger TU Vienna
Assumption Coverage
Jedes Design fußt auf Voraussetzungen





ASIC: Temperaturbereich, VCC
synchrone HW: Taktperiode ist ausreichend
SW: Prozessor-HW funktioniert
TT-Systems: WCET wird eingehalten
…
Was passiert bei deren Verletzung?
Je weniger Annahmen, desto robuster das Design!
23
A. Steininger TU Vienna
Robustes Design
Beherrschung von „ungeplanten“ bzw. nicht exakt
planbaren Einflüssen ( Fehlertoleranz: Fehlermodell!)



Umgebungsbedingungen (Bsp. Energy Harvesting…)
Bauteilparametern
Eingaben …
Motivation:


nm-Technologien: Parametervariationen, Fertigungsdefekte
Systeme: hohe Komplexität
Wege:

24
sorgfältige Berücksichtigung im Design (wenig Annahmen,
robuste Auslegung von Schaltung, Algorithmus, Regler, …)
A. Steininger TU Vienna
Quelle der Parametervariationen
Parameter:
▪ Schwellwert
▪ Treiberstärke
▪ Geschwindigkeit
▪ Stromverbrauch
Ungenauigkeiten von
▪ Masken & Ausrichtung
z.B.: Dl/DT Maske = 50nm/K
▪ Zusammensetzung Chemie
▪ Verarbeitungszeit
Auswirkungen werden für kleinere Feature-size
zunehmend stärker
bei 45nm Technologien bis zu 30% Variationen!
25
A. Steininger TU Vienna
Formale Verifikation
Problem:




moderne Designs sind „von Hand“ nicht überprüfbar
zu komplex, zu viele Zustände/Inputs
zu viele Parameter
übliche TEST Methoden beziehen sich auf HW-Defekte
Lösung: formale Verifikation

Model-Checking (entspricht gegebene Implementierung
einem gegebenen funktionalen Modell, z.B. executable Spec?)


Theorem Proving (formale Bedingungen für das Funktionieren
eines geg. Alg. auf einer Plattform)

26
fixe Parametrierung
Variable zulässig, aber oft unhandliche Gleichungen…
A. Steininger TU Vienna