Komplexitätsmanagment Michael Platzer Sophie Therese Radschek

Was ist Komplexität?

Maße für Komplexität Transistoren pro Chip, Gesamt-Länge des Interconnect bei NoC, … Lines of Code, Personentage in der Entwicklung, McCabe, Halstead,… Komplexitätsklasse des zu lösenden Problems

Gründe für Komplexität Hardware Software “instabile” Modelle Parallelität Physikalische Eigenschaften u. Wechselwirkungen einzelner Bauteile Chipgröße vs Transistorenzahl Anzahl Umweltparameter Hohe Anzahl von Aufgaben Wechselwirkungen zwischen einzelnen Aufgaben Diskrepanz Parallelität vs sequentieller Ausführung

...

(zu) hohe Komplexität hohe Entwicklungskosten lange Entwicklungsdauer Fehleranfälligkeit Design Crisis Verification Crisis

Abstraktion (Lösungen-1) Annahme: Komplexität “darunter liegender” Abstraktionsschichten beeinflusst Komplexität “höherer” Abstraktionsschichten nicht Steigert Produktivität -> komplexere Aufgaben können gelöst werden Trade-off Optimierungspotential?

? Assembler vs Hochsprache EER-Diagramm vs SQL-Statements VHDL vs einzelne Transistoren ?

Reuse / Aufteilung (Lösungen-2) IP-Module / Libraries Divide and Conquer Kapselung der Komplexität einzelner Aufgaben in vorgefertigte Lösungen Einfluss auf Productivity Gap?

Automation (Lösungen-3) “Abstraktion des Design-Prozesses” High-level Beschreibung des WAS Standardisierte-Routinen für das WIE

Automatisierte Verifikation (Lösungen-4) Verifikation größter Teil des Entwicklungsprozesses (HW) -> Größtes Einsparungspotential durch Automatisierung Verification Gap?

Reduktion (Lösungen-5) Einschränkung des Designprozesses (Standardisierung der verwendeten Routinen) Einschränkung der möglichen resultierenden Designs (Eigenschaften zur Vereinfachung der Verifikation, Minimierung von Wechselwirkungen, …)

Offene Punkte (Lösungen-6) Wo “echte” Reduktion / Vermeidung der Komplexität möglich? (Stichwort: “Verschieben der Komplexität”) Großes Restrisiko in der Entwicklung (wenn Komplexität nicht reduziert werden kann)

Entwicklung des Designprozesses Leitmotiv: Wiederverwendbarkeit von Designs Hardware Software Automatisierung in der Herstellung Immer kleinere Bauteile Immer weiter verringerte Wartbarkeit (Tradeoff zur Optimierung des Designs) Erhöhte Qualitätsansprüche  Zugangsschwelle steigt! Immer strengere Trennung zur Harware Abstraktionsebene steigt Wartbarkeit steigt Verringerte initiale Qualitätsansprüche  Zugangsschwelle sinkt!

Relevanz für HW/SW Codesign Komplexität eines System kann sich durch Zusammenspiel HW/SW ändern Beeinflusst Partitioning! (Nicht jedes Problem ist in HW und SW gleich komplex! – Z.B.: parallel vs sequentiell)

Referenzen http://www.eetimes.com/document.asp?doc_id=1215507 https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD648.html http://www.casa.ucl.ac.uk/cupumecid_site/download/Woodward.pdf http://www.itrs.net/Links/2013ITRS/Summary2013.htm https://www12.informatik.uni-erlangen.de/publications/pub2009/ghstskl09systemc-test.pdf http://embedded.eecs.berkeley.edu/Alumni/pinhong/ee244/10-2-design-verif.PDF http://www.ebiztutors.com/index.php/?p=313 (Abb. 1) http://www.eetimes.com/document.asp?doc_id=1217606 (Abb. 2)