Hardware / Software Codesign

Präsentation zum Thema: "Hardware / Software Codesign"—  Präsentation transkript:

1 Hardware / Software Codesign
Trends

2 Diskussion  Vor-Auswahl
Wählen Sie für die folgende Diskussion einen der Anwendungsbereiche (jede Gruppe eines) Automotive Telekom Industrie-Automation Raumfahrt Multimedia (MP3, Camcorder,…) Telebanking A. Steininger TU Vienna

3 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? A. Steininger TU Vienna

4 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. A. Steininger TU Vienna

5 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) A. Steininger TU Vienna

6 Design Reuse Integrieren fertiger Module in das Design (HW od. SW)
eigene Entwicklungen aus anderen Projekten oder IP von Dritten 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

7 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: Was ist wesentlich? Worauf können wir bauen? A. Steininger TU Vienna

8 Ein bildhafter Vergleich
Wenn das Design auf einer gegebenen Abstraktions-ebene 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! Abstraktionsgrad A. Steininger TU Vienna

9 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: 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

10 Beispiel Software vorausgesetzt werden darf zu betrachten ist Probleme
Funktion des Prozessors (Befehlssatz) Funktion des Speichers = Fundament ohne wenn und aber! zu betrachten ist sequenzielle Abfolge von Befehlen Programmfluss Probleme Interaktionen und Programmfluss sind u.U. sehr komplex bei Multiprocessing auch parallele Abläufe (Ordering!) A. Steininger TU Vienna

11 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? High-level Design Entry Programmierbare HW auf Basis vieler Prozessoren anstelle von LUTs, mit fixen Routing-Kanälen A. Steininger TU Vienna

12 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 A. Steininger TU Vienna

13 Network on Chip (NoC) Chip umfasst reguläres Array von „Knoten“
dazwischen fixer Interconnect (NoC), oft mit Router Beispiel: derzeit intensive Forschung auf NoC K R A. Steininger TU Vienna

14 Synchrones Design erlaubt Abstraktion des Zeitverhaltens
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

15 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! A. Steininger TU Vienna

16 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: sorgfältige Berücksichtigung im Design (wenig Annahmen, robuste Auslegung von Schaltung, Algorithmus, Regler, …) A. Steininger TU Vienna

17 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! A. Steininger TU Vienna

18 Formale Verifikation Problem: Lösung: formale Verifikation
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?) fixe Parametrierung Theorem Proving (formale Bedingungen für das Funktionieren eines geg. Alg. auf einer Plattform) Variable zulässig, aber oft unhandliche Gleichungen… A. Steininger TU Vienna

19 Die alte Test-Diskussion…
Ist HW wirklich leichter zu testen als SW ? Argumentation: niemand testet HW einfach durch simples Ausprobieren gibt‘s bei SW andere Ansätze als „Probieren“?? (z.B. struktureller Test) Woran liegt das? A. Steininger TU Vienna

20 Globale Optimierung beste HW + beste SW = bestes System? NEIN!
aber: bei Suche nach globalem Optimum explodiert der Lösungsraum! was ist fix, was optimierbar Suchstrategie? Gewichte? … => Heuristiken und Schätzungen A. Steininger TU Vienna