Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Hardware / Software Codesign Trends. A. Steininger TU Vienna 2 Diskussion Vor-Auswahl Wählen Sie für die folgende Diskussion einen der Anwendungsbereiche.

Ähnliche Präsentationen


Präsentation zum Thema: "Hardware / Software Codesign Trends. A. Steininger TU Vienna 2 Diskussion Vor-Auswahl Wählen Sie für die folgende Diskussion einen der Anwendungsbereiche."—  Präsentation transkript:

1 Hardware / Software Codesign Trends

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

3 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?

4 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.

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)

6 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

7 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?

8 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

9 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

10 A. Steininger TU Vienna 10 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 Interaktionen und Programmfluss sind u.U. sehr komplex bei Multiprocessing auch parallele Abläufe (Ordering!)

11 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

12 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

13 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 R K

14 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 !

15 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!

16 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, …)

17 A. Steininger TU Vienna 17 Quelle der Parametervariationen Parameter: Schwellwert Treiberstärke Geschwindigkeit Stromverbrauch Ungenauigkeiten von Masken & Ausrichtung z.B.: l/ T Maske = 50nm/K Zusammensetzung Chemie Verarbeitungszeit Auswirkungen werden für kleinere Feature-size zunehmend stärker bei 45nm Technologien bis zu 30% Variationen!

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

19 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 gibts bei SW andere Ansätze als Probieren?? (z.B. struktureller Test) Woran liegt das?

20 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


Herunterladen ppt "Hardware / Software Codesign Trends. A. Steininger TU Vienna 2 Diskussion Vor-Auswahl Wählen Sie für die folgende Diskussion einen der Anwendungsbereiche."

Ähnliche Präsentationen


Google-Anzeigen