Digitale Hardware/ Software-Systeme- P17 pot

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 schnel

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

wur-de durchgef¨uhrt (MEM TB), was auch vorhergesagt wurwur-de (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

wur-de durchgef¨uhrt (MEM TB), was nicht vorhergesagt wurwur-de (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 sicher-gestellt, dass nachdem der PC spekulativ ge¨andert wurde und die Sprungvorhersage falsch war, der Prozessor in 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¨on-nen Instruktiok¨on-nen potentiell parallel abgearbeitet werden H¨angt allerdings eine In-struktion von einer anderen InIn-struktion ab, d h ben¨otigt diese das Ergebnis einer anderen Instruktion, muss diese warten, bis das Ergebnis vorliegt Durch Warten wer-den eine oder im Allgemeinen mehrere Funktionseinheiten keine Instruktion berech-nen k¨onberech-nen Bestehen solche Abh¨angigkeiten allerdings nicht, k¨onberech-nen Instruktioberech-nen

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

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 Tomasulo eingesetzt werden Die Idee ist, Instruktionen der Reihe nach zuerst in ei-nem 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 reser-vierten 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ß

ALU 2 ALU 1

s4 s3 s2 s1

i1

i4 i3 i2

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

je-der 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 er-reicht werden

Beispiel 6.3.9 Die Verwendung uninterpretierter Funktionen ist in Abb 6.58 zu

se-hen 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 r1und r2initialisiert Die erste Instruktion i1 addiert die Registerinhalte von r1 und r2 und speichert das Ergebnis in r1 Der resultierende symbolische Wert

er-gibt sich zu r1+r2in Abb 6.58b) In der zweiten Instruktion wird der Registerinhalt von r1 mit dem Inhalt von Register r2 multipliziert Das Ergebnis ((r1+ r2) ∗ r2) 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 sym-bolischen Ausdr¨ucke, die w¨ahrend der symsym-bolischen Simulation entstehen, endlich Allerdings f¨uhrt eine Codierung der symbolischen Ausdr¨ucke zu einer

exponentiel-i3 i3

i2 i2

r1:=r1+r2

r2:=r1*r2 PC

PC

PC

r1:=r1+r2

r1:=r1+r2

r1

r1

r1+ r2

r1+ r2

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

r1+ r2in 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 r1 und r2 initialisiert (Abb 6.59a)) Nach Ausf¨uhrung der ersten Instruktion i1 wird die Anwendung des Funktionssymbols + auf die Operanden r1 und r2 in der Referenzdatei unter

dem Eintrag p1 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 p1 und r2 ist

in der Referenzdatei an Position p2gespeichert Man beachte, dass der Ausdruck

aus der Referenzdatei an Position p1 hierbei wiederverwendet wird Das Register

r2 verweist auf den Eintrag p2 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 spei-chern soll, wird mit einem Zeiger auf diesen Eintrag in 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

i3 i3

i2 i2

r1:=r1+r2

r2:=r1*r2 PC

PC

PC

r1:=r1+r2

r1:=r1+r2

r1

r1

r2

r2 r1

r2 r1

p1

p1

p2

r1+ r2

p1

p2

r1+ r2

p1

p2

p1

p1∗ r2

p2

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 beschrie-ben

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 r1, r2und r3initialisiert 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

s1auf 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 s2auf diese Position aktualisiert Weiterhin wird in der gespeicherten In-struktion ein Verweis auf die InIn-struktion 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 r1+ r2wird jedoch nicht im Register, sondern

in der Referenzdatei an Position p1 abgelegt Das Register r1 wird mit dem Zeiger

p auf die Position aktualisiert Ebenfalls aktualisiert wird der Inhalt in Position s2

i2

i3

i4

r3

r2

r1

D X W D X W D X W D X W D X W D X W

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

r3

r1+ r2 r1+ r2

s1∗ r2 p1∗ r2 p1∗ r2

p1/r3 p1/r3

r1+ r2

r1+ r2 r1+ r2 r1+ r2 r1+ r2

p1/r3 p1/r3

p1∗ r2

p1/r3

p1∗ r2

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, implementiert 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

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 bedeu-tet Flushing, dass alle Instruktionen im reservierten Bereich zur Ausf¨uhrung ge-bracht und zu Ende berechnet werden, ohne neue Instruktionen in den

reservier-ten 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 nin 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

re-servierten 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 i1, ,i n  und die zugeh¨origen Zu-standssequenzen p0, p1, , p n  und s0,s1, ,s n  mit p k+1 := disp(p k ,i k ) und

s k+1:= exec(sk ,i k ) gilt:

(s0= flush(p0)) ⇒ (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

SEQ OOO

t q

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)

p flush(p)

disp(p,i)

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

de-ren 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

kom-mutativ 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 finished ∧ SEQ finished ⇒

OOO.regfile = SEQ.regfile ∧ OOO.reffile = SEQ.reffile) Dabei ist OOO die Mikroarchitektur mit dynamischer Instruktionsablaufplanung und SEQ die sequentielle Mikroarchitektur (Instruktionssatzarchitektur) regfile bzw.

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 ge-pr¨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

ei-ne Permutation ist in Abb 6.63 zu sehen Eiei-ne 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]