Digitale Hardware/ Software-Systeme- P17 pot

6.3 Formale Verifikation von Prozessoren 313 W ¨ ahrend der Berechnung wird festgestellt, ob der konditionale Sprung erfolgen sollte, was durch das Signal TakeBranch angezeigt wird. Weiterhin wird der n ¨ achste Wert f ¨ ur von PC (TargetPC) bestimmt. Die Berechnung von TakeBranch und Tar- getPC ist in Abb. 6.56 nicht gezeigt. Aus diesen Werten k ¨ onnen zwei F ¨ alle, in denen die Sprungvorhersage falsch war, abgeleitet werden: • Fehlvorhersage MP1: Hier k ¨ onnen drei F ¨ alle eintreten. 1. Die Instruktion war ein konditionaler Sprung (MEM B) und der Sprung wurde durchgef ¨ uhrt (MEM TB), was auch vorhergesagt wurde (MEM PTB). Al- lerdings wurde das Sprungziel falsch geraten (MEM PT = MEM AT (engl. Actual Target)). 2. Die Instruktion war ein konditionaler Sprung (MEM B) und der Sprung wurde durchgef ¨ uhrt (MEM TB), was nicht vorhergesagt wurde (MEM PTB). 3. Die Instruktion war ein nicht konditionaler Sprung (MEM J) und das Sprung- ziel wurde falsch geraten (MEM PT = MEM ATC). • Fehlvorhersage MP2: Die Instruktion war ein konditionaler Sprung (MEM B) und es wurde ein Sprung vorhergesagt (MEM PTB), welcher nicht durchgef ¨ uhrt wurde (MEM TB). Alle Fehlvorhersagen f ¨ uhren dazu, dass bereits falsche Instruktionen geladen und decodiert wurden. Zur Korrektur muss entsprechend ein Flushing der Pipeline und das Laden des korrekten Wert f ¨ ur PC durchgef ¨ uhrt werden. Hierdurch wird sichergestellt, dass nachdem der PC spekulativ ge ¨ andert wurde und die Sprungvorhersage falsch war, der Prozessor i n der Lage ist, diesen Fehler zu korrigieren. Man beachte dabei, dass die Verwendung von uninterpretierten Funktionen garantiert, dass jede konkrete Implementierung der Sprungvorhersage korrekt ist, sofern die Verifikation mit den uninterpretierten Funktionen und Pr ¨ adikaten erfolgreich war. 6.3.3 ¨ Aquivalenzpr ¨ ufung f ¨ ur Prozessoren mit dynamischer Instruktionsablaufplanung Um einen h ¨ oheren Durchsatz zu erreichen, verwenden superskalare Prozessoren mehrere, parallel arbeitende Funktionseinheiten. Auf diesen Funktionseinheiten k ¨ onnen Instruktionen potentiell parallel abgearbeitet werden. H ¨ angt allerdings eine In- struktion von einer anderen Instruktion ab, d. h. ben ¨ otigt diese das Ergebnis einer anderen Instruktion, muss diese warten, bis das Ergebnis vorliegt. Durch Warten werden eine oder im Allgemeinen mehrere Funktionseinheiten keine Instruktion berechnen k ¨ onnen. Bestehen solche Abh ¨ angigkeiten allerdings nicht, k ¨ onnen Instruktionen in der Tat parallel berechnet werden. Hierf ¨ ur ist eine dynamische Ablaufplanung der Instruktionen notwendig, die von der sequentiellen Reihenfolge in der Instruktionen auftreten abweichen kann (engl. out of order execution). Diese Ausf ¨ uhrung muss die verf ¨ ugbaren Funktionseinheiten sowie die Abh ¨ angigkeiten von Instruktionen unter- einander ber ¨ ucksichtigen. 314 6 Hardware-Verifikation Beispiel 6.3.7. Gegeben ist folgender Programmabschnitt: i1: r0 := r0 * r1 i2: r0 := r0 * r1 i3: r1 := r1 + r1 In diesem Beispiel h ¨ angt Instruktion i2 von dem Ergebnis von Instruktion i1 ab. Allerdings braucht i3 weder auf i1 noch auf i2 warten. Dies bedeutet, dass i3 parallel zu i1 und i2 berechnet werden kann. Enth ¨ alt der Datenpfad Multizyklen-Funktionseinheiten und wurde i3 parallel mit i1 gestartet, kann es sein, dass i3 vor i1 die Berechnung beendet, da im All- gemeinen eine Addition schneller berechnet werden kann als eine Multiplikation. In diesem Fall wird r1 mit einem neuen Wert ¨ uberschrieben und die Instruktion i2 w ¨ urde mit einem falschen Wert aus Register r1 rechnen. Dies wird als engl. (write before read) hazard bezeichnet. Um die oben beschriebenen Hazards zu vermeiden, kann der Algorithmus von Toma sulo eingesetzt werden. Die Idee ist, Instruktionen der Reihe nach zuerst in einem reservierten Bereich, die sog. engl. reservation stations, zwischenzuspeichern. Eine Instruktion in dem reservierten Bereich kann einer freien Funktionseinheit zu- gewiesen werden, sobald alle Operanden berechnet sind. Um Hazards zu vermeiden, werden im Algorithmus von Tomasulo zwei weitere Mechanismen umgesetzt: 1. Neben der Instruktion selbst, werden auch die Operanden in dem reservierten Bereich gespeichert. Sollte der Wert eines Operanden noch nicht berechnet sein, ist dies entsprechend gekennzeichnet und ein Zeiger auf denjenigen Eintrag in dem reservierten Bereich gespeichert, der den Wert berechnen wird. 2. In der Speicherphase der Pipeline werden Ergebnisse nicht nur in die Register zur ¨ uck geschrieben, sondern auch ein Aktualisierung der Operanden im reservierten Bereich vorgenommen, sofern notwendig. Eine Mikroarchitektur mit dynamischer Instruktionsablaufplanung nach dem Algo- rithmus von Tomasulo ist in Abb. 6.57 zu sehen. Die einzelnen Speicherpl ¨ atze im reservierten Bereich sind mit s1, , s4 beschriftet. Durch die Verwendung eines Busses zwischen den ALUs und dem Registersatz kann immer nur eine Instruktion in jedem Taktzyklus beendet werden. Abstraktionsmechanismen Zur ¨ Aquivalenzpr ¨ ufung von Mikroarchitekturen mit dynamischer Instruktionsab- laufplanung mit deren Instruktionssatzarchitektur schlagen Berezin et al. [40] einen Ansatz basierend auf symbolischer Modellpr ¨ ufung vor. Hierf ¨ ur diskutieren sie drei m ¨ ogliche symbolische Repr ¨ asentation des Problems. Die Mikroarchitektur mit dynamischer Instruktionsablaufplanung kann durch einen endlichen Automaten modelliert werden. Dabei wird die Anzahl der Zust ¨ ande allerdings sehr groß. 6.3 Formale Verifikation von Prozessoren 315 ALU 2ALU 1 s4 s3 s2 s1 i1 i4 i3 i2 i5 r4 r3 r2 r1 Bus Abb. 6.57. Mikroarchitektur mit dynamischer Instruktionsablaufplanung [40] Beispiel 6.3.8. Unter der Annahme, dass die Mikroarchitektur r Register mit je w Bit und der reservierte Bereich s Speicherpl ¨ atze enth ¨ alt, ergibt sich eine Gesamtspei- chergr ¨ oße von mindestens w · (r + 2s). Dies ergibt sich aus dem Fakt, dass jeder Speicherplatz im reservierten Bereich mindestens zwei Operanden speichern muss. Zur Codierung des entsprechenden Zustandsraums werden somit mindestens n := w · (r + 2s) Bits ben ¨ otigt. F ¨ ur einen Prozessor mit w = 32, r = 16 und s = 12 ergibt sich n ≥ 32 · (16 +24)=960. Eine Verbesserung kann durch die Verwendung uninterpretierter Funktionen erreicht werden. Beispiel 6.3.9. Die Verwendung uninterpretierter Funktionen ist in Abb. 6.58 zu sehen. Der Prozessor besitzt zwei Register und das Programm besteht aus zwei In- struktionen. Zu Beginn (Abb. 6.58a)) sind die beiden Register mit den symbolischen Werten r 1 und r 2 initialisiert. Die erste Instruktion i1 addiert die Registerinhalte von r1 und r2 und speichert das Ergebnis in r1. Der resultierende symbolische Wert ergibt sich zu r 1 +r 2 in Abb. 6.58b). In der zweiten Instruktion wird der Registerinhalt von r1 mit dem Inhalt von Register r2 multipliziert. Das Ergebnis ((r 1 + r 2 ) ∗ r 2 ) wird in r2 gespeichert. Instruktion i3 beendet das Programm. Man beachte, dass die Funktionssymbole + und ∗ nicht ausgewertet werden. Zur Codierung wird zu Beginn mit jedem Register eine Symbol assoziiert. Wird eine endliche Anzahl an Instruktionen ausgef ¨ uhrt, so ist auch die Anzahl der symbolischen Ausdr ¨ ucke, die w ¨ ahrend der symbolischen Simulation entstehen, endlich. Allerdings f ¨ uhrt eine Codierung der symbolischen Ausdr ¨ ucke zu einer exponentiel- 316 6 Hardware-Verifikation i3 i3 i1 i1 i2i2 r1:=r1+r2 r2:=r1*r2 PC PC PC a) b) c) finished finished finished r1:=r1+r2 r2:=r1*r2 r2:=r1*r2 r1:=r1+r2 r2 r 2 r 1 r1 r1 r2 r2 r1r 1 + r 2 r 2 (r 1 + r 2 ) ∗r 2 r 1 + r 2 finished r1:=r1+r2 r2:=r1*r2 Abb. 6.58. Abstraktion durch uninterpretierte Funktionen [40] len Anzahl an Bits, die zur Codierung ben ¨ otigt werden. Aus diesem Grund schlagen Berezin et al. [40] ein anderes Codierungsverfahren vor. Um zu einer kompakteren Codierung zu gelangen, kann man zwei Tatsachen ausnutzen: 1) In einem einzelnen symbolischen Simulationslauf werden nicht alle m ¨ oglichen Ausdr ¨ ucke auftreten und 2) die selben Ausdr ¨ ucke werden oftmals in un- terschiedlichen Registern referenziert. So wird z. B. in Abb. 6.58c) der Ausdruck r 1 + r 2 in den beiden Registern r1 und r2 verwendet. Eine kompaktere Codierung basiert auf einer sog. Referenzdatei. Register enthalten entweder konstante Symbole oder verweisen auf Eintr ¨ age in der Referenzdatei. Jeder Eintrag in der Referenzda- tei enth ¨ alt die Anwendung einer uninterpretierten Funktion. Dabei ist jeder Operand entweder ein Register oder ein Zeiger auf einen anderen Eintrag in der Referenzdatei. Beispiel 6.3.10. Betrachtet wird wiederum das Programm aus Abb. 6.58. Die sel- be Ausf ¨ uhrung unter Verwendung einer Referenzdatei ist in Abb. 6.59 zu sehen. Zu Beginn sind die Register auf die konstanten Symbole r 1 und r 2 initialisiert (Abb. 6.59a)). Nach Ausf ¨ uhrung der ersten Instruktion i1 wird die Anwendung des Funktionssymbols + auf die Operanden r 1 und r 2 in der Referenzdatei unter dem Eintrag p 1 gespeichert. Das Register r1 verweist auf diesen Eintrag (siehe Abb. 6.59b)). Das Ergebnis der Ausf ¨ uhrung der zweiten Instruktion i2 ist in Abb. 6.59c) zu sehen. Die Anwendung des Funktionssymbols ∗ auf die Operanden p 1 und r 2 ist in der Referenzdatei an Position p 2 gespeichert. Man beachte, dass der Ausdruck aus der Referenzdatei an Position p 1 hierbei wiederverwendet wird. Das Register r2 verweist auf den Eintrag p 2 in der Referenzdatei. Die Ausf ¨ uhrung der dritten Instruktion i3 beendet das Programm. Vergleicht man Abb. 6.58 und Abb. 6.59, so sieht man, dass bei der Verwen- dung der Referenzdatei keine Ausdr ¨ ucke mehr in den Registern gespeichert werden. Register enthalten nur noch konstante Symbole oder Zeiger auf Eintr ¨ age in der Refe- renzdatei. Neue Eintr ¨ age in der Referenzdatei werden nach jeder Anwendung einer uninterpretierten Funktion angelegt. Dasjenige Register, welches das Ergebnis speichern soll, wird mit einem Zeiger auf diesen Eintrag i n der Referenzdatei gef ¨ ullt. Die Berechnung der symbolischen Ausdr ¨ ucke, die mit einem Register assoziiert werden, l ¨ asst sich einfach durch Dereferenzierung der Zeiger durchf ¨ uhren. 6.3 Formale Verifikation von Prozessoren 317 i3 i3 i1 i1 i2i2 r1:=r1+r2 r2:=r1*r2 PC PC PC a) b) c) finished finished finished r1:=r1+r2 r2:=r1*r2 r2:=r1*r2 r1:=r1+r2 r1 r2 r 2 r 1 r 2 r2 r1 r2 r1 p 1 p1 p2 r 1 + r 2 p1 p2 r 1 + r 2 p1 p2 p 1 p 1 ∗ r 2 p 2 finished r1:=r1+r2 r2:=r1*r2 Abb. 6.59. Abstraktion durch uninterpretierte Funktionen und Referenzdatei [40] Die Verwendung der Codierung basierend auf Referenzdateien f ¨ ur die Model- lierung von Mikroarchitekturen mit dynamischer Instruktionsablaufplanung, die den Algorithmus von Tomasulo implementieren, wird anhand eines Beispiels beschrieben. Beispiel 6.3.11. Betrachtet wird ein Prozessor mit drei Registern, drei Speicher- pl ¨ atzen im reservierten Bereich und zwei Funktionseinheiten. Das betrachtete Pro- gramm lautet: i1: r1 := r1 + r2 i2: r2 := r1 * r2 i3: r3 := r1 / r3 Die Abarbeitung des Programms auf einer Mikroarchitektur mit dynamischer In- struktionsablaufplanung, die den Algorithmus von Tomasulo implementiert, ist in Abb. 6.60 zu sehen. Zu Beginn sind die Register r1, r2 und r3 mit den konstanten Symbolen r 1 , r 2 und r 3 initialisiert. In einem ersten Schritt wird die Instruktion i1 in den reservierten Bereich auf Speicherplatz s1 gespeichert (engl. dispatch (D)). Da der richtige Registerinhalt von r1 von dieser Instruktion abh ¨ angt, wird eine Referenz s 1 auf den Speicherplatz s1 im reservierten Bereich in diesem Register gespeichert. Im zweiten Schritt wird die Instruktion i1 auf der Funktionseinheit f1 zur Ausf ¨ uhrung (engl. execute (X)) gebracht. Gleichzeitig wird die Instruktion i2 im reservierten Bereich an Position s2 gespeichert. Hierdurch wird Register r2 mit der Referenz s 2 auf diese Position aktualisiert. Weiterhin wird in der gespeicherten In- struktion ein Verweis auf die Instruktion an Position s1 eingetragen, da erst nach Beendigung der dort gespeicherten Instruktion die Instruktion i2 zur Ausf ¨ uhrung kommen kann. Im dritten Schritt wird die Berechnung von Instruktion i1 auf Funktionseinheit f1 beendet und das Ergebnis in Register r1 (engl. write back (W)) gespeichert. Der resultierende symbolische Ausdruck r 1 + r 2 wird jedoch nicht im Register, sondern in der Referenzdatei an Position p1 abgelegt. Das Register r1 wird mit dem Zeiger p 1 auf die Position aktualisiert. Ebenfalls aktualisiert wird der Inhalt in Position s2 318 6 Hardware-Verifikation i1 i2 i3 i4 r 3 r 2 r 1 DXW DXW DXW DXW DXW DXW p3 p2 p1 s3 s2 s1 f2 f1 Register Referenz- datei reservierter Bereich Funktions- einheiten r1:=r1+r2 r2:=r1*r2 r3:=r0/r3 finish r3 r2 r1 r 3 s 1 s 1 p 1 p 1 p 1 p 1 r 2 s 2 s 2 s 2 s 2 p 2 r 3 s 3 s 3 p 3 p 3 r 1 + r 2 r 1 + r 2 s 1 ∗ r 2 p 1 ∗ r 2 p 1 ∗ r 2 p 1 /r 3 p 1 /r 3 r 1 + r 2 r 1 + r 2 r 1 + r 2 r 1 + r 2 r 1 + r 2 p 1 /r 3 p 1 /r 3 p 1 ∗ r 2 p 1 /r 3 p 1 ∗ r 2 Abb. 6.60. Ausf ¨ uhrung des Programms aus Beispiel 6.3.11 [40] des reservierten Bereichs, da die entsprechende Instruktion auf das Ergebnis (nun an Position p1) gewartet hat. Da das Ergebnis aber erst nach Abschluss dieses Taktzy- klus in dem Register vorliegt, kann die Instruktion i2 in diesem Takt nicht ausgef ¨ uhrt werden. Parallel wird noch die Instruktion i3 im reservierten Bereich an Position s3 gespeichert. Auch hier wird die Referenz auf den Inhalt in Register r1 aktualisiert. Im vierten Schritt kommen die Instruktionen i2 und i3 parallel auf den beiden Funktionseinheiten zur Ausf ¨ uhrung. Dies ist m ¨ oglich, da beide Instruktionen von- einander unabh ¨ angig sind. Im f ¨ unften Schritt werden die Ergebnisse in die Register gespeichert. Da in diesem Modell nur eine Instruktion pro Taktzyklus abgeschlos- sen werden kann, wird lediglich das Ergebnis der Instruktion i3 in das Register r3 geschrieben. Hierbei wird wiederum die Referenzdatei zur effizienteren Codierung verwendet. Im sechsten Schritt wird schließlich auch das Ergebnis von Instruktion i2 gespeichert. Die ¨ Aquivalenzpr ¨ ufung Die ¨ Aquivalenzpr ¨ ufung von Mikroarchitektur mit dynamischer Instruktionsablauf- planung und Instruktionssatzarchitektur, i mplementiert als sequenzielle Mikroarchi- tektur, erfolgt durch den Beweis einer Lebendigkeits- und einer Gefahrlosigkeitsei- genschaft. Die Lebendigkeitseigenschaft besagt, dass die Mikroarchitektur bei der Abarbeitung einer endlichen Sequenz von Instruktionen irgendwann die Berechnung 6.3 Formale Verifikation von Prozessoren 319 beendet. Die Gefahrlosigkeitseigenschaft besagt, dass die Abarbeitung einer belie- bigen, endlichen Sequenz an Instruktionen auf der sequentiellen Mikroarchitektur und der Mikroarchitektur mit dynamischer Instruktionsablaufplanung zu dem selben Ergebnis f ¨ uhrt. Damit diese Aussagen f ¨ ur beliebig lange Sequenzen gelten, wird ein Indukti- onsbeweis ¨ uber die L ¨ ange der Instruktionssequenz durchgef ¨ uhrt. Dabei m ¨ ussen die Zust ¨ ande der sequentiellen Mikroarchitektur mit den Zust ¨ anden der Mikroarchitek- tur mit dynamischer Instruktionsablaufplanung verglichen werden. Im Folgenden bezeichnen p und q Zust ¨ ande der Mikroarchitektur mit dynamischer Instruktions- ablaufplanung und s und t Zust ¨ ande der sequentiellen Mikroarchitektur. Wie in Ab- schnitt 6.3.1 beschrieben, sind zwei Zust ¨ ande p und s ¨ aquivalent, wenn das Flushing der Mikroarchitektur mit Fließbandverarbeitung im Zustand p zum selben f ¨ ur den Programmierer sichtbaren Zustand s der sequentiellen Mikroarchitektur f ¨ uhrt (siehe auch das kommutative Diagramm in Abb. 6.46 auf Seite 296). Bei einer Mikroarchitektur mit dynamischer Instruktionsablaufplanung bedeutet Flushing, dass alle Instruktionen im reservierten Bereich zur Ausf ¨ uhrung gebracht und zu Ende berechnet werden, ohne neue Instruktionen in den reservierten Bereich zu kopieren. Der Induktionsbeweis ¨ uber die L ¨ ange n der Instruktionsse- quenz i =  ,i n−1 ,i n ,i n+1 ,  erfolgt, beginnend in ¨ aquivalenten Zust ¨ anden p und s, durch Kopieren der Instruktion i n in den reservierten Bereich der Mikroarchitek- tur mit dynamischer Instruktionsablaufplanung und Ausf ¨ uhren der selben Instruk- tion auf der sequentiellen Mikroarchitektur. Die sich ergebenden Zust ¨ ande q und t m ¨ ussen wiederum ¨ aquivalent sein. Dies wird im Folgenden formal ausgedr ¨ uckt: Sei exec(s,i) eine Funktion, welche die Instruktion i in Zustand s auf der sequentiellen Mikroarchitektur ausf ¨ uhrt. Entsprechend kopiert disp(p,i) die Instruktion i in den reservierten Bereich der Mikroarchitektur mit dynamischer Instruktionsablaufplanung im Zustand p. Schließlich f ¨ uhrt flush(p) ein Flushing der Mikroarchitektur durch. Man beachte dabei, dass disp und flush ¨ uber mehrere Taktzyklen laufen k ¨ onnen. Dies ist in Abb. 6.61 zu sehen. Dabei ist OOO die Mikroarchitektur mit dynamischer Instruktionsablaufplanung und SEQ die sequentielle Mikroarchitektur. Im Folgenden wird der Beweis aus [40] skizziert: Die Induktionsannahme ¨ uber die Sequenzl ¨ ange n l ¨ asst sich in folgendem Theorem formulieren: Theorem 6.3.1. F ¨ ur jede Instruktionssequenz i 1 , ,i n  und die zugeh ¨ origen Zu- standssequenzen p 0 , p 1 , ,p n  und s 0 ,s 1 , ,s n  mit p k+1 := disp(p k ,i k ) und s k+1 := exec(s k ,i k ) gilt: (s 0 = flush(p 0 )) ⇒ (s n = flush(p n )) Der Induktionsanfang mit n = 0 ist trivial. Der Induktionsschritt basiert auf folgender Annahme: ∀p,i : exec(flush(p),i)=flush(disp(p,i)) (6.17) Wenn die Korrektheit von Gleichung (6.17) gezeigt werden kann, ist der Beweis von Theorem 6.3.1 einfach. Allerdings ist dieser Korrektheitsbeweis nicht trivial und tats ¨ achlich der schwierigste Teil in der Verifikation. 320 6 Hardware-Verifikation SEQOOO ps tq disp(p,i n ) disp(o,i n−1 ) o r schritt Induktion- exec(r,i n−1 ) exec(s, i n ) flush(q) flush(p) disp(q,i n+1 ) exec(t,i n+1 ) Abb. 6.61. Induktionsbeweis [40] Eine Beobachtung ist, dass die Anzahl an Instruktionen, die in der Prozessorim- plementierung zu einem Zeitpunkt gespeichert ist, endlich und meistens sehr klein ist. Besitzt der reservierte Bereich j Speicherpl ¨ atze, so k ¨ onnen j + 1 Funktionssym- bole (inklusive der Instruktion die gerade neu gespeichert wird) in der Abstraktion verwendet werden. Register enthalten anfangs konstante Symbole, aus denen mit Hilfe von uninterpretierten Funktionen neue symbolische Ausdr ¨ ucken konstruiert werden. Der Zusammenhang zwischen symbolischen Ausdr ¨ ucken und dem Prozes- sorzustand sei durch die semantische Funktion [[·]] gegeben. Die Beweisidee l ¨ asst sich dann wie in Abb. 6.62 dargestellt skizzieren. Im Folgenden stellen die Variablen p  ,q  ,s  ,t  und i  symbolische Zust ¨ ande und symbolische Instruktionen dar. F ¨ ur den Beweis ist es ausreichend zu zeigen, dass das abstrakte Diagramm (mit den Eckpunkten p  ,q  ,s  ,t  in Abb. 6.62) kommutativ ist, und eine geeignete semantische Funktion [[·]] zur Verf ¨ ugung zustellen. Dies zeigt in der Tat die Kommutativit ¨ at des konkreten Diagramms (mit den Eckpunkten p,q,s,t in Abb. 6.62) f ¨ ur die Mikroarchitektur mit dynamischer Instruktionsablaufplanung. Die Kommutativit ¨ at f ¨ ur das abstrakte Diagramm l ¨ asst sich wie folgt formulieren. ∀p,i : exec(flush(p  ),i)  = flush(disp(p  ,i  )) (6.18) 6.3 Formale Verifikation von Prozessoren 321 sp flush(p) disp(p,i) qt flush(q) exec(s, i) p  q  exec(s  ,i  ) flush(q  ) t  s  [[q  ]] [[s  ]][[p  ]] [[t  ]] flush(p  ) disp(p  ,i  ) Abb. 6.62. Kommutatives Diagramm f ¨ ur einen konkreten und abstrakten Prozessor sowie deren Zusammenhang [40] Eine geeignete semantische Funktion l ¨ asst sich wie folgt finden: Sei [[·]] eine Ab- bildung von Symbolen der abstrakten Definitionsbereich auf die Funktionssymbole und konstanten Symbole der Mikroarchitektur, so dass ∀p  ,i  :disp([[p  ]],[[i  ]]) = [[disp(p  ,i  )]] und ∀s  ,i  : exec([[s  ]],[[i  ]]) = [[exec(s  ,i  )]] gilt. Gilt weiterhin, dass ∀p  ,i  : exec(flush(p  ),i  )=flush(disp(p  ,i  )), so gilt ∀p  ,i  : exec(flush([[p  ]]),[[i  ]]) = flush(disp([[p  ]],[[i  ]])). (6.19) Gleichung (6.18) beschreibt die Kommutativit ¨ at des abstrakten Diagramms in Abb. 6.62. Gleichung (6.19) beschreibt die Eigenschaften einer geeigneten semanti- schen Funktion [[·]], die garantiert, dass das konkrete Diagramm in Abb. 6.62 kommutativ ist. Ist die G ¨ ultigkeit von Gleichung (6.18) und (6.19) gezeigt, folgt die G ¨ ultigkeit von Gleichung (6.17). Was schließlich die G ¨ ultigkeit von Theorem 6.3.1 impliziert. Berezin et al. [40] beweisen Gleichungen (6.17) und (6.19) sowie Theorem 6.3.1 mit Hilfe eines Theorembeweisers. Gleichung (6.18) kann mit Hilfe eines CTL- Modellpr ¨ ufers bewiesen werden. Die CTL-Formel lautet: AG (OOO. f inished ∧SEQ. f inished ⇒ OOO.regfile = SEQ.regfile ∧OOO.reffile = SEQ.reffile) Dabei ist OOO die Mikroarchitektur mit dynamischer Instruktionsablaufplanung und SEQ die sequentielle Mikroarchitektur (Instruktionssatzarchitektur). regfile bzw. 322 6 Hardware-Verifikation reffile beschreiben den Zustand des Registersatzes bzw. der Referenzdateien. Durch die zus ¨ atzliche Lebendigkeitseigenschaft AF OOO.finished wird sichergestellt, dass das Flushing der Mikroarchitektur terminiert. Optimierungen Um reale Prozessoren verifizieren zu k ¨ onnen, bedarf es weiterer Optimierungen der oben beschriebenen ¨ Aquivalenzpr ¨ ufung. • Symmetriereduktion f ¨ ur Funktionseinheiten: In dem oben beschriebenen Mo- dell ist es lediglich m ¨ oglich, dass eine Funktionseinheit zu jedem Zeitpunkt ihr Ergebnis zur ¨ uck in den Registersatz schreibt. Nimmt man an, dass alle Funk- tionseinheiten alle Instruktionen ausf ¨ uhren k ¨ onnen, kann man aus Symmetrie- gr ¨ unden davon ausgehen, dass alle bis auf eine Funktionseinheit inaktiv sein werden. Sie k ¨ onnen daher eliminiert werden. • Entkoppelte Simulation der Mikroarchitekturen: Der obige Ansatz zur ¨ Aqui- valenzpr ¨ ufung verlangt, dass beide Mikroarchitekturen, die sequentielle und die mit dynamischer Instruktionsablaufplanung, parallel gepr ¨ uft werden. Ausgehend von ¨ aquivalenten Zust ¨ anden werden also zwei unabh ¨ angige Modelle parallel gepr ¨ uft. Eine signifikante Effizienzsteigerung kann erzielt werden, wenn zun ¨ achst eine Mikroarchitektur und anschließend die zweite Mikroarchitektur gepr ¨ uft wird. • Partialordnungsreduktion des reservierten Bereichs: Das Modell der Mi- kroarchitektur mit dynamischer Instruktionsablaufplanung ist unabh ¨ angig von den Positionen im reservierten Bereich. Dies bedeutet, dass eine Permutation der Positionen im reservierten Bereich zu dem selben Ergebnis f ¨ uhrt. Solch eine Permutation ist in Abb. 6.63 zu sehen. Eine Reduktion der Zust ¨ ande kann erreicht werden, wenn die Referenzen, die im reservierten Bereich verwendet werden, immer auf Positionen mit niedrigerem Index zeigen (siehe rechte Seite in Abb. 6.63). Weiterhin k ¨ onnen alle belegten Positionen im reservierten Bereich auf Positionen mit niedrigem Index geschoben werden, so dass die Position mit hohem Index frei bleiben. Dies kann auch dynamisch erfolgen. s1 s2 s3 r1 + s1 s3 s2 s1 s1+r2 r2 + r1 s1 + r2 r2+r1 r1+s2 Abb. 6.63. Zustandsraumreduktion durch Permutation der Positionen im reservierten Bereich [40] . parallel arbeitende Funktionseinheiten. Auf diesen Funktionseinheiten k ¨ onnen Instruktionen potentiell parallel abgearbeitet werden. H ¨ angt allerdings eine In- struktion von einer anderen