Hardware / Software Codesign
Trends
Diskussion  Vor-Auswahl
Wählen Sie für die folgende Diskussion einen
der Anwendungsbereiche (jede Gruppe eines)






2
Automotive
Telekom
Industrie-Automation
Raumfahrt
Multimedia (MP3, Camcorder,…)
Telebanking
A. Steininger TU Vienna
Diskussion Fragen
Welche Anforderungen an das Produkt
(= Embedded System, nicht Gesamtprodukt)
bestehen?



Was fällt in die Klasse „Kosten“ ?
Was fällt in die Klasse „Nutzen“ ?
Was ist speziell an Ihrem Anwendungsbereich?
Wie kann man sie zum Zeitpunkt des
Partitioning quantitativ erfassen?
3
A. Steininger TU Vienna
Umsetzung Designmaßnahmen
Überarbeiten Sie die Liste der
Kriterien für Ihren Anwendungsfall
Welche Maßnahmen kann man setzen,
um das Design entsprechend zu
optimieren?
bis zum 20.5.
4
A. Steininger TU Vienna
Design Crisis
Moores Law: Wir können zunehmend
komplexere Systeme realisieren
ABER: Können wir sie auch designen?
menschl. Auffassungsgabe ist begrenzt
Tools werden nicht so schnell besser
Teamgröße ist begrenzt (Kommunikation)
5
A. Steininger TU Vienna
Design Reuse
Integrieren fertiger Module in das Design (HW od.
SW)
eigene Entwicklungen aus anderen Projekten oder IP
von Dritten




6
fertige, verifizierte, getestete, bewährte Module
steigert Effizienz, hilft Design-Crisis zu lindern
ABER: Probleme bei Schnittstellen
ABER: Probleme beim Systemtest
A. Steininger TU Vienna
Die Macht der Abstraktion
Reduktion der (komplexen) Realität auf das
wesentliche




vereinfacht Modellierung
Design einfacher, rascher, fehlerfreier
für den Menschen erfassbar
für den Computer in „endlicher“ Zeit berechenbar
ABER:


7
Was ist wesentlich?
Worauf können wir bauen?
A. Steininger TU Vienna
Ein bildhafter Vergleich
Abstraktionsgrad
8
Wenn das Design auf einer
gegebenen Abstraktionsebene zu komplex wird, d.h.
viele Elemente umfasst, wird
der Abstraktionsgrad erhöht
(weglassen von Details)
Auf der höheren Ebene kann
wieder effizient entwickelt
werden, bis auch dort die
Komplexität zu hoch ist.
Bei der Abstraktion dürfen
natürlich nur irrelevante
Details verworfen werden!
A. Steininger TU Vienna
Beispiel Hardware (ASIC)
vorausgesetzt werden darf



spezifizierte Funktion der Zellen (nur bei CBIC!)
Modelle/Abstraktionen für das Verhalten der Leitungen
beides abhängig von Temp., VCC, Last,…
zu betrachten ist

(parallele) Interaktion der diversen Elemente (Modelle)
Probleme:




9
VCC und Temp sind nicht auf ganzem Chip gleich/konstant
Routing ist erst sehr spät im Flow bekannt
Parametervariationen durch Fertigung, Alterung etc.
„einfache“ Modelle stimmen für nm-Technologien kaum mehr
A. Steininger TU Vienna
Beispiel Software
vorausgesetzt werden darf


Funktion des Prozessors (Befehlssatz)
Funktion des Speichers
= Fundament ohne wenn und aber!
zu betrachten ist


sequenzielle Abfolge von Befehlen
Programmfluss
Probleme


10
Interaktionen und Programmfluss sind u.U. sehr komplex
bei Multiprocessing auch parallele Abläufe (Ordering!)
A. Steininger TU Vienna
Vergleich
SW wird auf höherer Abstraktionsebene erstellt



Design-Process ist effizienter
Lösung ist weniger effizient
(„Abstraktion verschenkt Optimierungspotenzial“)
getroffene Annahmen „halten“ besser
Wie kann HW hier aufholen?


11
High-level Design Entry
Programmierbare HW auf Basis vieler Prozessoren anstelle
von LUTs, mit fixen Routing-Kanälen
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
12
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
13
A. Steininger TU Vienna
Synchrones Design
erlaubt Abstraktion des Zeitverhaltens


14
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!
15
A. Steininger TU Vienna
Robustes Design
Beherrschung von „ungeplanten“ bzw. nicht exakt
planbaren Einflüssen ( Fehlertoleranz: Fehlermodell!)



Umgebungsbedingungen
Bauteilparametern
Eingaben …
Motivation:


nm-Technologien: Parametervariationen, Fertigungsdefekte
Systeme: hohe Komplexität
Wege:

16
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!
17
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)

18
fixe Parametrierung
Variable zulässig, aber oft unhandliche Gleichungen…
A. Steininger TU Vienna
Die alte Test-Diskussion…
Ist HW wirklich leichter zu testen als SW ?
Argumentation: niemand testet HW
einfach durch simples Ausprobieren


19
gibt‘s bei SW andere Ansätze als „Probieren“??
(z.B. struktureller Test)
Woran liegt das?
A. Steininger TU Vienna
Globale Optimierung
beste HW + beste SW = bestes
System?
NEIN!
aber: bei Suche nach globalem Optimum
explodiert der Lösungsraum!



20
was ist fix, was optimierbar
Suchstrategie? Gewichte? …
=> Heuristiken und Schätzungen
A. Steininger TU Vienna

Hardware / Software Codesign