A. Steininger TU Vienna 1 Multicore eleganter Work-Around um die Design-Crisis Problemverschiebung in die SW (= auf höhere Ebene) ABER: hohe Parallelität.

Präsentation zum Thema: "A. Steininger TU Vienna 1 Multicore eleganter Work-Around um die Design-Crisis Problemverschiebung in die SW (= auf höhere Ebene) ABER: hohe Parallelität."—  Präsentation transkript:

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

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

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

4 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 Leistungsaufnahme/Energieverbrauch („pJ/instr“) Physikalische Größe Preis Echtzeitverhalten, … A. Steininger TU Vienna 4

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

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

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

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

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