Komplexitätsmanagment

Michael PlatzerSophie 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• “instabile” Modelle• Parallelität• Physikalische Eigenschaften

u. Wechselwirkungen einzelner Bauteile

• Chipgröße vs Transistorenzahl

• Anzahl Umweltparameter

Software• Hohe Anzahl von Aufgaben• Wechselwirkungen

zwischen einzelnen Aufgaben

• Diskrepanz Parallelität vs sequentieller Ausführung

...

(zu) hohe Komplexität

• hohe Entwicklungskostenlange 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

Hardware

• Automatisierung in der Herstellung

• Immer kleinere Bauteile• Immer weiter verringerte

Wartbarkeit (Tradeoff zur Optimierung des Designs)

• Erhöhte Qualitätsansprüche

Zugangsschwelle steigt!

Software

• Immer strengere Trennung zur Harware

• Abstraktionsebene steigt• Wartbarkeit steigt• Verringerte initiale

Qualitätsansprüche

Zugangsschwelle sinkt!

Leitmotiv: Wiederverwendbarkeit von Designs

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/E

WD648.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)