pdf-Datei mit 72-dpi-Fotos - FG Mikroelektronik, TU Berlin

Technische Universität Berlin
Institut für Mikroelektronik
Lukas Bauer
Dissertation
Perspektiven des modernen ASIC-Designs
Kapitel 4.4
Seite 65
Welche Systemfunktionen sich mit welchem Entwicklungsaufwand realisieren lassen und zu
welchen Mehrkosten an Siliziumfläche sie führen oder ob die Aufteilung der auszuführenden
Systemfunktionen zwischen Hardware und Software sinnvoll gewählt ist, sind Fragen, die vom
Kunden oft nicht alleine beantwortet werden, da ihm das genaue Verständnis der technischen
Möglichkeiten meistens fehlt. Die endgültige Systemkonzeption entsteht daher in der Regel während
der technischen Vorverhandlungen zwischen Kunde und Designer.
Anschließend wird die Spezifikation immer detaillierter ausgearbeitet. Spätestens dann, wenn es
darum geht, z. B. die exakte Funktion einzelner Steuerbits zu definieren, ist aber meist der ASIC-
Designer gefragt, da nur dieser die genaue Anzahl und Bedeutung der zur Steuerung der einzelnen
Funktionen benötigten Registerbits etc. kennt bzw. da diese Details von der von ihm zu findenden
Hardwarelösung abhängig sind. Es ergibt sich somit ein fließender Übergang zwischen der
Spezifikationsphase und der Design-Entry-Phase. Dies gilt insbesondere bei der Verwendung
grafischer HDL-Programme, da bei diesen nicht mehr alle Details verbal, sondern vielfach direkt
in HDL spezifiziert werden.
4.4.2.3 Kontrolle statt ausschließlicher Simulation in der Design-Entry-Phase
Die Design-Entry-Phase ist die kreativste Phase eines ASIC-Designs. Ausgehend von der
Systemkonzeption bzw. der verbalen Spezifikation wird eine geeignete Lösung entworfen und als
Schematic, in Form einer HDL-Datei oder mittels grafischem HDL, also stets in computerlesbarer
Form, eingegeben. Da sich dieser Schritt aufgrund der nicht computerlesbaren Zielvorgaben
einer automatischen Verifikation entzieht, ist der Designer in dieser Phase am stärksten gefordert,
die Korrektheit der eingegebenen Lösungsansätze zu überprüfen.
Das klassische Prüfverfahren stellt hierbei die Simulation der Schaltung dar, bei der Testmuster
erzeugt werden und die Reaktion der Schaltung anhand von grafischen Signalverläufen visuell
begutachtet wird. Da letzteres bei Änderungen und Erweiterungen der Schaltung wiederholt
erforderlich ist (und evtl. mit nachlassender Sorgfalt geschieht), erscheint es vorteilhafter, die
erwarteten Reaktionen der Schaltung als Abfragen in der Simulationsdatei zu formulieren und so
ggf. automatisch Fehlermeldungen zu erhalten. Bei Designs mit integrierter CPU kann dies sogar
in Form von Programmen geschehen, die von der CPU ausgeführt werden. So wurden z. B. die
UARTs in einem universellen Microcontroller simuliert, indem die zwei UARTs in der Simulationsdatei
Chip-extern miteinander verbunden wurden und programmgesteuert Daten zwischen
ihnen übertragen und ausgewertet wurden. Optional können dabei in der Testumgebung künstlich
Übertragungsfehler generiert werden. An die Stelle der wiederholten visuellen Begutachtung von
Kurvenformen tritt so die einmalige (und nicht zu unterschätzende) Prüfung, ob das ausgeführte
Microcontrollerprogramm alle Fehler korrekt melden würde. Gleichzeitig ist menschliches Versagen
bei der Interpretation der Simulationsergebnisse ausgeschlossen.
Jede Simulation ist aber nur so gut, wie sie den Funktionsumfang der Schaltung überdeckt. Hier
wird immer wieder übersehen, dass neben den erwünschten Schaltungsfunktionen auch getestet
werden muss, ob unerwünschte Nebeneffekte auftreten. Soll beispielsweise ein Controller mehrere
komplexe Startbedingungen überprüfen, so reicht es nicht aus, nur diese zu simulieren, da
damit nicht sichergestellt ist, dass der Controller nicht auch startet, wenn eine Startbedingung
unvollständig erfüllt ist. Auch bei Registern wird zwar meist kontrolliert, ob sich ein Register an
der spezifizierten Adresse schreiben und lesen lässt, es wird aber oft darauf verzichtet zu prüfen,
ob es z. B. bei Schreibzugriffen auf falsche Adressen unverändert bleibt.
Um all dies zu simulieren, wäre ein extrem hoher Simulationsaufwand erforderlich. Mit FPGA-
Prototypenboards lässt sich bei solchen Details zwar die zeitraubende Simulation durch Tests in
(evtl. skalierter) Echtzeit ersetzen, es bleibt aber der Aufwand für die Durchführung der einzel-