Digitale Hardware/ Software-Systeme- P2 pptx

10 1 Einleitung reicher und heterogener werden. Die Schwierigkeit besteht in der Verzahnung funk- tionaler und nichtfunktionaler Eigenschaften, in der sich auch die Durchmischung der Komplexit ¨ aten von Anwendung und Implementierung widerspiegelt. So ist es nicht verwunderlich, dass ein großer Teil des Aufwands einer Produktentwicklung in die Verifikation fließt. Eine detaillierte Fallstudie [156] zeigt, dass der Verifikations- aufwand den Entwurfsaufwand sogar ¨ ubersteigt. Dennoch l ¨ asst es die Komplexit ¨ at heutiger Systeme nicht zu, dass diese nach dem heutigen Stand der Technik nach wirtschaftlichen Aspekten fehlerfrei entwickelt werden k ¨ onnen. Dies wird im Entwurfsdreieck in Abb. 1.5 dargestellt. Mit jeder Ecke des Drei- ecks ist ein Qualit ¨ atsmaß assoziiert, namentlich Qualit ¨ at, Kosten und Zeit, wobei Qualit ¨ at f ¨ ur die Produktqualit ¨ at, Zeit f ¨ ur die Zeit bis zur Markteinf ¨ uhrung und Kos- ten f ¨ ur die Entwicklungskosten stehen sollen. Bei einer Produktplanung kann man die Vorstellungen f ¨ ur dieses Produkt in das Entwurfsdreieck eintragen, wobei ein Qualit ¨ atsmaß als um so besser gilt, je n ¨ aher der Punkt an der entsprechenden Ecke steht. Das Entwurfsdreieck zeigt graphisch die Abh ¨ angigkeiten der drei Qualit ¨ ats- maße: Es ist nicht m ¨ oglich, ein Produkt mit h ¨ ochster Produktqualit ¨ at zu geringsten Entwicklungskosten in k ¨ urzester Zeit auf den Markt zu bringen. Es ist aber z. B. m ¨ oglich, ein Produkt m ¨ oglichst kosteng ¨ unstig zu entwickeln. Dies geht dann aber zu Lasten der Qualit ¨ at und der Zeit bis zur Markteinf ¨ uhrung. Kosten Zeit × × qualitativ hochwertige, zeit- und kostenintensive zu einem hohen Preis Qualit ¨ at zu Lasten der Qalit ¨ at schnelle Markteinf ¨ uhrung L ¨ osung Abb. 1.5. Entwurfsdreieck Verifikation ist ein qualit ¨ atssteigernder Prozess in der Entwicklung eingebetteter Systeme. Mit dem Wissen ¨ uber das Entwurfsdreieck muss man allerdings immer wieder kritisch hinterfragen, ob die gew ¨ unschte Qualit ¨ at erreicht ist, bzw. wie viel Verifikation noch n ¨ otig und wirtschaftlich vertretbar ist. Dabei darf man allerdings nie aus den Augen verlieren, dass ein Fehlverhalten oder Ausfall im Betrieb enorme Kosten nach sich ziehen und sogar einen Reputationsverlust f ¨ ur das Unternehmens bedeuten kann. 1.2 Der Verifikationsprozess 11 1.2 Der Verifikationsprozess Verifikation ist der Prozess, die Fehlerfreiheit einer Implementierung bez ¨ uglich der Spezifikation zu zeigen. Mit anderen Worten: Es soll ¨ uberpr ¨ uft werden, ob ein Entwurfs- oder Syntheseschritt das korrekte Ergebnis liefert. Dies wird durch das sog. Rekonvergenzmodell (engl. reconvergence model) [41] in Abb. 1.6 ausgedr ¨ uckt. Das Rekonvergenzmodell ist eine konzeptionelle Darstellung des Verifikationspro- zesses. Hierbei wird eine Spezifikation im Entwurf in eine Implementierung trans- formiert. Die Korrektheit des Ergebnisses wird in der Verifikation ¨ uberpr ¨ uft. Spezifikation Implementierung Entwurf Verifikation Abb. 1.6. Das Rekonvergenzmodell [41] Der i n Abb. 1.6 gezeigte Ablauf ist allerdings stark vereinfacht dargestellt. Ein wesentlicher Aspekt ist, dass die Spezifikation meistens in einer Form vorliegt, die nicht direkt in eine Implementierung transformierbar ist. Dies bedeutet, dass ein Ent- wickler zun ¨ achst die Spezifikation aufbereiten muss, bevor Entwurfsentscheidungen getroffen werden k ¨ onnen. Genau diese Aufbereitung verlangt aber, dass die Spezi- fikation interpretiert wird. Dies liegt unter anderem daran, dass Spezifikationen oft- mals unvollst ¨ andig, mehrdeutig oder sogar widerspr ¨ uchlich sind. Die Erweiterung des Rekonvergenzmodells um diesen Aspekt ist in Abb. 1.7 dargestellt. Einen Schwachpunkt kann man allerdings sofort in Abb. 1.7 erkennen: Ist es bei der Interpretation der Spezifikation notwendig, Unvollst ¨ andigkeiten, Mehrdeu- tigkeiten oder Widerspr ¨ uche aufzul ¨ osen, und werden diese Modifikationen nicht in der Spezifikation festgehalten, so wird die Implementierung sp ¨ ater nicht gegen die Spezifikation, sondern gegen die Interpretation der Spezifikation verifiziert. Die In- terpretation existiert dabei nur als Bild der Spezifikation im Kopf des Entwicklers. Ist die Interpretation selbst fehlerhaft, kann dies nicht durch Verifikation erkannt wer- den. Um diesen Sachverhalt aufzul ¨ osen, sollte die Implementierung stets gegen die Spezifikation gepr ¨ uft werden. Hier zeigt sich aber ein zweites Problem: Wie beim Entwurf ist die Spezifikation oftmals nicht f ¨ ur einen direkten Einsatz im Verifikati- onsprozess einsetzbar. Dies bedeutet, dass ebenfalls eine Interpretation der Spezifika- tion f ¨ ur die Verifikation notwendig wird. Um dem Fall zu begegnen, dass fehlerhafte 12 1 Einleitung Spezifikation Bild der Spezifikation Implementierung Entwurf Interpretation Verifikation Abb. 1.7. Interpretation und Rekonvergenzmodell Interpretationen die Qualit ¨ at eines Entwurfs mindern, sollte deshalb nach M ¨ oglich- keit stets darauf geachtet werden, dass ein nicht am Entwurf beteiligter Entwickler die Verifikation ¨ ubernimmt. Somit ist wahrscheinlich, dass immer zwei Bilder der Spezifikation durch Interpretation entstehen. Damit wird auch die Wahrscheinlich- keit gemindert, dass beide Bilder die selben Fehler enthalten. Dies ist in Abb. 1.8 dargestellt. Bild der Spezifikation Implementierung Spezifikation Interpretation Interpretation Verifikation Entwurf Bild der Spezifikation Abb. 1.8. Getrennte Interpretation zum Entwurf und zur Verifikation 1.2 Der Verifikationsprozess 13 1.2.1 Das V-Modell Das Rekonvergenzmodell (siehe Abb. 1.6) stellt sowohl den Entwurf als auch die Verifikation jeweils als einen einzelnen Schritt dar. Dies ist f ¨ ur heutige Systeme nicht realistisch. Die Komplexit ¨ at heutiger digitaler Hardware/Software-Systeme verlangt, dass man einen hierarchischen Entwurfsprozess einsetzt. Dies bedeutet, dass man, etwa nach einem Divide&Conquer-Ansatz, die Systemkomplexit ¨ at zerlegt und den Entwurf somit auf verschiedenen Abstraktionsebenen durchf ¨ uhrt (siehe auch [426]). Diesem Aspekt wird durch das V-Modell Rechnung getragen (siehe Abb. 1.9). Anforderungs- analyse Inbetriebnahme entwurf System- Komponenten- entwurf Komponenten- System- verifikation verifikation Implementierung Zeit Abb. 1.9. Das V-Modell Das V-Modell tr ¨ agt seinen Namen aufgrund seiner Darstellung als ” V“ -f ¨ ormi- ges Diagramm. Die linke Seite des V entspricht dem Entwurfsprozess. Entsprechend beschreibt die rechte Seite den Verifikationsprozess. Der Ber ¨ uhrungspunkt der bei- den Prozesse ist die Implementierung. Die Entwurfsphase startet oben links mit der Analyse der Anforderungen. Diese werden in dem Systementwurf umgesetzt. Dabei erfolgt auch die Aufteilung in Hardware- und Software-Komponenten. Diese wer- den im Komponentenentwurf entwickelt. Damit endet der Entwurf und es folgt die Implementierung. Die Verifikationsphase beginnt unten auf der anderen Seite des V mit der Verifikation der einzelnen Komponenten. Dieser Schritt ist gefolgt von der Systemverifikation und der anschließenden Inbetriebnahme. In einem fehlerfreien Entwurf schreitet die Zeit von links nach recht fort und es wird zun ¨ achst die eine Seite des V herabgestiegen und anschließend die andere Seite wieder heraufgestiegen. Das Ab- und Aufsteigen entspricht dabei den Wechsel der Abstraktionsebenen. In der Entwurfsphase wird die Implementierung immer detail- lierter. In der Verifikation abstrahiert man von bereits verifizierten Komponenten. In einem realen Systementwurf wird man aber die Abstraktionsebenen hin- und herspringen, da z. B. bereits Teile der Implementierung auf niedrigen Abstrakti- onsebenen vorliegen. Daneben wird auch zwischen den Seiten des V gesprungen. Wird beispielsweise i n der Komponentenverifikation ein Fehler aufgedeckt, wird 14 1 Einleitung man nicht zur Systemverifikation ¨ ubergehen, sondern zun ¨ achst die fehlerhafte Kom- ponente korrigieren. Das V-Modell gibt es in verschiedensten Versionen mit unterschiedlich vie- len Abstraktionsebenen. Dementsprechend gibt es auch spezialisierte Varianten f ¨ ur den Hardware-Entwurf oder f ¨ ur den Software-Entwurf. Dies stellt zugleich einen großen Nachteil des V-Modells heraus: Es gibt keine Varianten, die gleichzeitig zwischen dem Hardware- und dem Software-Entwurf und deren Verifikationspha- sen und Interaktionen unterscheiden k ¨ onnen. Aus diesem Grund werden im folgen- den Abschnitt Modelle f ¨ ur den Entwurfs- und den Verifikationsprozess von digitalen Hardware/Software-Systemen vorgestellt. 1.2.2 Das Doppeldachmodell des Entwurfsprozesses Die Verifikation eines Systems beschreibt die ¨ Uberpr ¨ ufung der korrekten Implemen- tierung einer Spezifikation. Um den Verifikationsprozess zu verstehen, ist es not- wendig, zun ¨ achst den Entwurfsprozess detaillierter zu betrachten. Da eingebette- te Systeme h ¨ aufig aus interagierenden Hardware- und Software-Komponenten be- stehen, muss der Entwurf beider Bestandteile sowie die Interaktion zwischen die- sen im Entwurfsprozess ber ¨ ucksichtigt werden. Der idealisierte Entwurf f ¨ ur digi- tale Hardware/Software-Systeme ist in Abb. 1.10 als Doppeldachmodell dargestellt [425, 426]. System Logik Software Hardware Implementierung Spezifikation ArchitekturModul Block Abb. 1.10. Doppeldachmodell f ¨ ur den Entwurf von digitalen Hardware/Software-Systemen Die linke Seite des Daches entspricht dem Software-Entwurfsprozess,w ¨ ahrend die rechte Seite dem Hardware-Entwurfsprozess zugeordnet ist. Jede Seite ist dabei in unterschiedliche Abstraktionsebenen organisiert. F ¨ ur den Software-Entwurfspro- zess sind h ¨ aufig die Block- und Modulebene von Interesse. Im Hardware-Entwurfs- prozess findet man im Allgemeinen die Logik- und Architekturebene. In der Mitte des 1.2 Der Verifikationsprozess 15 Doppeldachmodells findet man eine gemeinsame Abstraktionsebene, die sog. Syste- mebene (engl. Electronic System Level, ESL). Auf dieser Abstraktionsebene wird nicht zwischen Hardware und Software unterschieden. Auf jeder Abstraktionsebene wird durch einen Syntheseschritt eine Spezifikation in eine Implementierung transformiert. Der Syntheseschritt wird auf jeder Abstrakti- onsebene als vertikaler Pfeil im Doppeldachmodell dargestellt. Im Rekonvergenzmo- dell aus Abb. 1.6 waren alle diese Schritte zu einem Schritt (Entwurf) zusammen ge- fasst. Horizontale Pfeile beschreiben die Wiederverwendung individueller Elemente einer Implementierung als Spezifikation auf der n ¨ achst tieferen Abstraktionsebene. Der durch das Doppeldachmodell beschriebene Entwurfsprozess beginnt typi- scherweise auf der Systemebene. Hier besteht die Spezifikation beispielsweise aus einem Prozessgraphen, der das gew ¨ unschte Verhalten des Systems als ¨ uber Kan ¨ ale kommunizierende Prozesse beschreibt. Daneben gibt es meistens eine Menge an Abbildungs- und Implementierungsbeschr ¨ ankungen in der Form von maximalen Fl ¨ achenanforderungen, minimale zu erreichendem Durchsatz etc. Die Implementie- rung auf der Systemebene wird auch als Hardware/Software-Architektur bezeich- net und wird in Form von strukturellen Modellen bestehend aus Prozessoren, Bus- sen, Speichern, Hardware-Beschleunigern und Klassendiagrammen beschrieben. Die Aufgabe der Systemsynthese besteht darin, eine geeignete Implementierungsplatt- form auszuw ¨ ahlen, Prozesse und Kan ¨ ale auf diese Plattform abzubilden und eine zeitliche Ordnung der Abarbeitung der Prozesse und der Kommunikation zu bestim- men. Hierdurch entsteht ein verfeinertes Modell, welches alle Entwurfsentscheidun- gen, die auf dieser Ebene getroffen wurden, beinhaltet. Die einzelnen Komponenten dieses verfeinerten Modells dienen anschließend als Eingabe f ¨ ur den Entwurfspro- zess auf der n ¨ achst tieferen Abstraktionsebene. Die Synthese auf tieferen Abstraktionsebenen ¨ ahnelt der Systemsynthese dahin- gehend, dass stets ein Verhaltensmodell in eine strukturelle Implementierung trans- formiert wird [426]. Dabei unterscheidet sich allerdings die Granularit ¨ at der betrach- teten Objekte. Auf der Modulebene werden typischerweise Prozesse, die auf den selben Prozessor abgebildet sind, zeitlich geplant. Dies geschieht h ¨ aufig unter Zu- hilfenahme eines Betriebssystems. Auf der Blockebene m ¨ ussen Prozesse auf den Instruktionssatz des Prozessors (engl. Instruction Set Architecture, ISA) abgebildet werden. Hierf ¨ ur werden in der Regel Compiler und Linker eingesetzt. Auf Architekturebene im Hardware-Entwurf werden Prozesse, welche als Hard- ware-Beschleuniger implementiert werden, in Beschreibungen auf der Registertrans- ferebene (engl. Register Transfer Level, RTL) synthetisiert. RTL-Beschreibungen bestehen aus einem Controller zur Steuerung eines Datenpfads, der wiederum aus Funktionseinheiten, Registern und Verbindungen besteht. Dieser Syntheseschritt wird als Verhaltenssynthese (engl. behavioral synthesis bzw. high-level synthesis) oder Architektursynthese bezeichnet. Auf Logikebene werden Boolesche Funktionen oder Automatenmodelle durch Gatter und Flip-Flops implementiert. Es sei angemerkt, dass der im Doppeldachmodell angedeutete Top-Down-Ent- wurfsprozess auf Systemebene auf der Verf ¨ ugbarkeit von Entwurfsprozessen auf Modul- und Architekturebene basiert. Dies heißt, dass tiefere Abstraktionsebenen 16 1 Einleitung einen Zugang zum Entwurfsprozess, entweder durch ein Syntheseverfahren oder durch vordefinierte Module (engl. IP modules), bieten muss. Synthese Zentral f ¨ ur den Entwurfsprozess ist die Synthese. Die Synthese transformiert eine Spezifikation in eine Implementierung. Dies geschieht auf verschiedenen Abstrak- tionsebenen, was der heutigen Systemkomplexit ¨ at Rechnung tr ¨ agt. Dabei wird auf jeder Abstraktionsebene eine Verhaltensbeschreibung, die Teil der Spezifikation ist, in eine Strukturbeschreibung transformiert (siehe Abb. 1.11). Spezifikation f xyxy Implementierung Synthese f 1 f 2 f 3 Abb. 1.11. Die Synthese transformiert eine Verhaltensbeschreibung, die Teil der Spezifikation ist, in eine Strukturbeschreibung In Abb. 1.11 ist das Verhalten der Spezifikation durch die Funktion f beschrie- ben. Die Funktion y := f (x) transformiert den Eingang x in den Ausgang y.Um hieraus eine Strukturbeschreibung zu erzeugen, muss zun ¨ achst die Funktion f in Teilfunktionen, hier f 1 , f 2 und f 3 , zerlegt werden. Damit die resultierende Imple- mentierung aber das in der Spezifikation vorgegebene Verhalten implementiert, muss zus ¨ atzlich angegeben werden, wie die Teilfunktionen zusammenarbeiten, d. h. y = f 3 ( f 1 (x), f 2 (x)). Somit besteht eine Strukturbeschreibung aus Teilfunktionen und deren Zusammenwirken. Da die Teilfunktionen f 1 , f 2 , f 3 selbst wieder Verhaltensbe- schreibungen sind, k ¨ onnen diese gegebenenfalls in weitere Strukturmodelle verfei- nert werden. Neben der Transformation der Verhaltensbeschreibung in eine Strukturbeschrei- bung spielt bei der Synthese aber auch die Einhaltung der Anforderungen an das System eine zentrale Rolle. Die abstrakte Sicht auf den Syntheseschritt kann mit Hilfe des X-Diagramms verfeinert werden (Abb. 1.12). Eine Spezifikation besteht aus einem Verhaltensmodell und Anforderungen. Das Verhaltensmodell beschreibt die geforderte Funktionalit ¨ at des Systems. Seine Expressivit ¨ at und Analysierbarkeit wird als Berechnungsmodell (engl. Model of Computation, MoC) angegeben [298]. Verhaltensmodelle werden h ¨ aufig in Programmiersprachen, wie C/C++ oder Java, Hardware-Beschreibungssprachen, wie SystemVerilog oder VHDL, oder Systembe- schreibungssprachen, wie beispielsweise SystemC oder SpecC, geschrieben. 1.2 Der Verifikationsprozess 17 b) Entwurfsent- scheidungen & Verfeinerung Struktur Qualit ¨ ats- merkmale Verhalten Anforderungen a) Synthese Spezifikation Implementierung Abb. 1.12. X-Diagramm der Synthese Die Anforderungen (engl. requirements) umfassen oftmals implizit oder explizit ein Plattformmodell, welches die Vielfalt m ¨ oglicher struktureller Implementierungen einschr ¨ ankt, etwa durch Vorgabe verf ¨ ugbarer Ressourcen, deren Dienste und deren Verbindungen. Beispiele hierf ¨ ur sind verf ¨ ugbare Prozessoren mit deren Instruktions- satz, Speicher und Prozessorbusse. Auf Systemebene sind typische Plattformmodel- le beispielsweise Einprozessorsysteme, Hardware/Software-Prozessor/Coprozessor- Systeme, homogene, symmetrische oder heterogene, asymmetrische Multiprozessor- systeme [466]. Neben dem Plattformmodell existieren in den Anforderungen dar ¨ uber hinaus oftmals Abbildungsbeschr ¨ ankungen f ¨ ur Teile des Verhaltensmodells sowie zus ¨ atzliche Anforderungen an nichtfunktionale Eigenschaften, wie maximale Ant- wortzeit, minimaler Durchsatz, maximale Leistungsaufnahme etc. Eine Implementierung besteht aus einem Strukturmodell sowie einer Menge von Qualit ¨ atsmerkmalen. Das Strukturmodell ist ein verfeinertes Modell des Verhaltens- modells unter Ber ¨ ucksichtigung der Anforderungen aus der Spezifikation. Zus ¨ atzlich zu implementierungsunabh ¨ angigen Informationen im Verhaltensmodell enth ¨ alt das Strukturmodell Informationen ¨ uber die Umsetzung von Entwurfsentscheidungen aus dem vorhergegangenen Syntheseschritt. Ein Beispiel hierf ¨ ur ist die Abbildung des Verhaltensmodells auf Elemente des Plattformmodells. Qualit ¨ atsmerkmale sind gesch ¨ atzte Eigenschaften einer Implementierung und werden in einem geeigneten Qualit ¨ atsmaß quantifiziert, z. B. Antwortzeit, Durch- satz, Latenz, Fl ¨ achen- oder Leistungsbedarf. Qualit ¨ atsmerkmale quantifizieren funk- tionale oder nichtfunktionale Eigenschaften eines Systems. Zur Absch ¨ atzung dienen entweder das Strukturmodell oder geeignete Bewertungsmodelle, die, je nach Ab- straktionsebene und Umsetzung, unterschiedlich gute Absch ¨ atzungen liefern. Bei- spiele f ¨ ur Bewertungsmodelle f ¨ ur zeitliche Qualit ¨ atsmaße sind Instruktionssatz- oder Hardware-Simulationsmodelle. Die Synthese transformiert eine Spezifikation in eine Implementierung. Die zen- tralen Aufgaben dabei sind das Treffen von Entwurfsentscheidungen und die Ve rf ei- nerung eines Verhaltensmodells in ein Strukturmodell (Abb. 1.12). Auf jeder Ab- 18 1 Einleitung straktionsebene f ¨ uhrt die Synthese dabei eine Abbildung der Elemente im Verhal- tensmodell in Raum und Zeit durch. Das Treffen von Entwurfsentscheidungen ist somit die Allokation von Ressourcen aus dem Plattformmodell, die (r ¨ aumliche) Bin- dung von Elemente des Verhaltensmodells und deren (zeitliche) Ablaufplanung,um Ressourcenkonflikte aufzul ¨ osen. Verfeinerung ist der Prozess, die Entwurfsentschei- dungen in das Verhaltensmodell zu integrieren. Das Ergebnis ist ein Strukturmodell der Implementierung. Daneben k ¨ onnen mit den Entwurfsentscheidungen die Qua- lit ¨ atsmerkmale abgesch ¨ atzt werden. Da die Menge m ¨ oglicher Entwurfsentscheidungen typischerweise sehr groß sein kann, wird h ¨ aufig als Teil der Synthese eine Entwurfsraumexploration zur Be- stimmung optimaler (oder nahezu optimaler) Implementierungen durchgef ¨ uhrt. Die Entwurfsraumexploration ist ein Mehrzieloptimierungsproblem, welches in der Re- gel nicht nur eine einzelne, sondern eine Menge sog. Pareto-optimaler L ¨ osungen bestimmt. Somit kann die Entwurfsraumexploration als Mehrzieloptimierungspro- blem der Synthese bez ¨ ugliche der zu optimierenden Qualit ¨ atsmaße aufgefasst wer- den. Die Aufgaben und Methoden zum Entwurf und zur Optimierung digitaler Hardware/Software-Systeme sind ausf ¨ uhrlich in [426] dargestellt. 1.2.3 Das Doppeldachmodell des Verifikationsprozesses Wie im Entwurfsprozess digitaler Hardware/Software-Systeme, muss auch im Ve- rifikationsprozess die Verifikation von Hardware, von Software und von Systemen unterst ¨ utzt werden. Außerdem muss auf jeder Abstraktionsebene verifiziert werden, d. h. es muss ¨ uberpr ¨ uft werden, ob die jeweilige Spezifikation korrekt in eine Imple- mentierung umgesetzt wurde. Das Doppeldachmodell f ¨ ur den Verifikationsprozess in Abb. 1.13 enth ¨ alt sowohl die Hardware-, die Software- als auch die Systemverifika- tion. Die vertikalen Pfeile stellen Verifikationsschritte dar, w ¨ ahrend die horizontalen Pfeile die Komposition einzelner Komponenten beschreiben. Man beachte, dass die Pfeile im Doppeldachmodell f ¨ ur den Verifikationsprozess gegen ¨ uber dem Doppel- dachmodell f ¨ ur den Entwurfsprozess entgegengesetzt verlaufen. Auf jeder Abstraktionsebene haben sich eigenst ¨ andige Ans ¨ atze zur automati- schen Verifikation etabliert, wobei diese oftmals Gemeinsamkeiten zeigen. Wichtige Ans ¨ atze zur automatischen Verifikation von Hardware, Software und Systemen wer- den in diesem Buch in einer einheitlichen Notation dargestellt. Es wird gezeigt, dass sich viele der vorgestellten Ans ¨ atze gleichermaßen auf Hardware, Software oder teil- weise auch auf Hardware/Software-Systeme anwenden lassen. Da die beschriebenen Ans ¨ atze aber in einem bestimmten Kontext entwickelt wurden, werden sie in dem vorliegenden Buch auch in diesem Zusammenhang vorgestellt. Auch wenn die Verifikationsans ¨ atze viele Gemeinsamkeiten aufweisen, unter- scheiden sich diese auf den einzelnen Abstraktionsebenen erheblich. Auf der Logi- kebene gilt es beispielsweise zu zeigen, dass eine Funktion korrekt in ein Schaltnetz bzw. ein Schaltwerk umgesetzt wurde. Die Spezifikation (die geforderte Funktion) ist dabei ein System Boolescher Funktionen, die Implementierung eine Netzliste aus Gattern. Die Herausforderung besteht darin, zu zeigen, dass die Wahl einer bestimm- ten Technologie (Gattertypen) und somit des Basissystems und die daraus resultie- 1.2 Der Verifikationsprozess 19 System Logik Software Hardware Implementierung Spezifikation ArchitekturModul Block Abb. 1.13. Doppeldachmodell f ¨ ur den Verifikationsprozess digitaler Hardware/Software- Systeme renden Transformationen, die gew ¨ unschte Funktion, beispielsweise eines Multiple- xers oder Volladdierers, nicht verf ¨ alscht hat. Auf h ¨ oherer Abstraktionsebene (der Architekturebene) kann diese Frage auch so formuliert werden: Berechnet ein Ad- dierer/Multiplizierer tats ¨ achlich die Summe/das Produkt der beiden Operanden? Einen Spezialfall auf dieser Ebene stellt die Prozessorverifikation dar. Als Spe- zifikation dient dabei die Instruktionssatzarchitektur des Prozessors, der als eine se- quentielle Implementierung des Prozessors verstanden werden kann, d. h. die In- struktionssatzarchitektur beschreibt, wie die Ausf ¨ uhrung einer Instruktion den Zu- stand der f ¨ ur den Programmierer sichtbaren Register ¨ andert. Die Mikroarchitektur des Prozessors hingegen ist eine Hardware-Implementierung auf Registertransfere- bene und typischerweise hoch optimiert. So erfolgt die Abarbeitung von Instruktio- nen h ¨ aufig verschr ¨ ankt, d. h. die Mikroarchitektur implementiert eine sog. Pipeline mit unterschiedlichen Stufen der Abarbeitung von Instruktionen. Hierdurch k ¨ onnen mehrere Instruktionen gleichzeitig in Bearbeitung sein. Andere Optimierungen, die darauf zielen, den Durchsatz des Prozessors zu erh ¨ ohen, sind Sprungvorhersage mit spekulativer Ausf ¨ uhrung oder parallel arbeitende Funktionseinheiten, die eine dy- namische Ablaufplanung der Instruktionen in Abh ¨ angigkeit der Verf ¨ ugbarkeit von Ressourcen erm ¨ oglicht. Zu zeigen, dass eine so optimierte Mikroarchitektur den In- struktionssatz korrekt implementiert, ist eine zentrale Aufgabe auf der Architekture- bene. Auf h ¨ oheren Abstraktionsebenen werden in der Hardware-Verifikation zuneh- mend nicht nur die ¨ Ubereinstimmung des spezifizierten Verhaltens mit dem imple- mentierten Verhalten verglichen, sondern auch zus ¨ atzlich Eigenschaften der Imple- mentierung ¨ uberpr ¨ uft. Hierzu geh ¨ oren beispielsweise Eigenschaften, die garantieren, dass die Hardware in keinen ungew ¨ unschten oder gef ¨ ahrlichen Zustand ¨ ubergeht bzw. garantiert in einer vorgegebenen Zeitspanne eine gew ¨ unschte Reaktion zeigt. [...]... f¨ r die Theoretische Informatik und wird manchmal sou gar als Geburtsstunde der gesamten Informatik bezeichnet Dies liegt nicht zuletzt daran, dass Turings Ideen einen wesentlichen Einfluss auf den Bau digitaler Computer aus¨ bte Die Bedeutung von Turings (und somit G¨ dels) Arbeiten kann man u o fassen, wenn man sich vor Augen f¨ hrt, dass sie die Grenzen der Verifikation aufzeiu gen Mit anderen Worten:... [268] Die Bedeutung der Modallogik und der Arbeiten von Kripke wird klar, wenn man sich ihr Anwendungs- 1.3 Eine kurze Geschichte der Verifikation 25 ¨ feld, die Uberpr¨ fung funktionaler Eigenschaften von digitalen Systemen, vor Augen u f¨ hrt Dies wird an dem folgenden Beispiel aus [413] verdeutlicht: u Gegeben sei das folgende Programm, welches die Sequenz der Primzahlen ausdruckt: 1 a := 2 2 print(a)... Das Ergebnis sind sog Systembeschreibungssprachen, etwa SystemC [207, 236] oder SpecC [172] Insbesondere SystemC hat sich mittlerweile zu einem Defacto-Standard in der ausf¨ hrbaren Spezifikau tion von Hardware/Software-Systemen entwickelt Simulative Verifikationsans¨ tze a f¨ r SystemC werden im Rahmen der SCV (engl SystemC Verification Library) unu terst¨ tzt [424] Dar¨ ber hinaus definiert SystemC-TLM . zur Optimierung digitaler Hardware/Software-Systeme sind ausf ¨ uhrlich in [426] dargestellt. 1.2.3 Das Doppeldachmodell des Verifikationsprozesses Wie im Entwurfsprozess digitaler Hardware/Software-Systeme,. werden im folgen- den Abschnitt Modelle f ¨ ur den Entwurfs- und den Verifikationsprozess von digitalen Hardware/Software-Systemen vorgestellt. 1.2.2 Das Doppeldachmodell des Entwurfsprozesses Die. Hardware Implementierung Spezifikation ArchitekturModul Block Abb. 1.10. Doppeldachmodell f ¨ ur den Entwurf von digitalen Hardware/Software-Systemen Die linke Seite des Daches entspricht dem Software-Entwurfsprozess,w ¨ ahrend die