Digitale Hardware/ Software-Systeme- P11 potx

30 268 0
Digitale Hardware/ Software-Systeme- P11 potx

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

6.3 Formale Verifikation von Prozessoren 293 bestimmt. Alternativ kann ein Operand auch direkt als Konstante in der Instruktion gespeichert sein. In der ALU wird anschließend die durch der Instruktion codierte Operation be- rechnet. Das berechnete Ergebnis der ALU kann entweder als Adresse zum Laden oder Speichern von Daten aus bzw. in den Hauptspeicher dienen oder im Register- satz gespeichert werden. Alternativ zu ALU-Operationen kann ¨ uber einen Addierer (ADD) eine neue Sprungadresse f ¨ ur den PC, also die Adresse der n ¨ achsten Instruk- tion, berechnet werden. Die Instruktionssatzarchitektur des Prozessors ist durch die Operationen der ALU (typischerweise Addition, Subtraktion und logische Vergleiche), den Lade- und Speicherbefehlen und den implementierten Sprungbefehlen gegeben. Auf der Mikroarchitektur in Abb. 6.44 muss zun ¨ achst die Berechnung einer Instruktion ab- geschlossen sein, bevor mit Hilfe des PC eine neue Instruktion geladen wird. Arbeitet die Mikroarchitektur wie die ISA sequentiell, so kann die Verifikation als Automaten ¨ aquivalenz formuliert werden. Die Implementierungen von Prozes- soren sind allerdings immer komplexer geworden. Die Mikroarchitektur eines mo- dernen Prozessors besteht heutzutage aus mehreren parallelen Pipelines mit Multi- zyklen-Funktionseinheiten, Sprungvorhersage, spekulativer Ausf ¨ uhrung und sogar dynamischer Ablaufplanung von Instruktionen (engl. out-of-order execution, OOO). Diese Optimierungen an der Mikroarchitektur zielen darauf ab, den Instruktions- durchsatz des Prozessors zu erh ¨ ohen. Mit der zunehmenden Komplexit ¨ at von Prozessoren werden zuverl ¨ assige Veri- fikationsans ¨ atze ben ¨ otigt, die es erlauben, die ¨ Aquivalenz von ISA und optimierter Mikroarchitektur zu beweisen. Im Folgenden werden einige wichtige Ans ¨ atze zur ¨ Aquivalenzpr ¨ ufung von Prozessoren n ¨ aher diskutiert. Zun ¨ achst werden Verifikati- onsans ¨ atze f ¨ ur Prozessoren mit Fließbandverarbeitung (engl. pipelining) diskutiert. Anschließend werden Erweiterungen f ¨ ur Prozessoren mit Funktionseinheiten, deren Berechnungen mehrere Takte dauern, sog. Multizyklen-Funktionseinheiten, Mikroar- chitekturen mit Ausnahmebehandlung und Mikroarchitekturen mit Sprungvorhersa- ge betrachtet. Daneben wird in modernen Prozessoren auch st ¨ andig die Parallelit ¨ at der Mikroarchitekturen erh ¨ oht. Erweiterungen zur Verifikation von sog. superska- laren Mikroarchitekturen, also Architekturen, welche die gleichzeitige Bearbeitung mehrerer Instruktionen erlauben, und Mikroarchitekturen, die eine dynamische Ab- laufplanung von Instruktionen erlauben, werden zum Schluss behandelt. 6.3.1 ¨ Aquivalenzpr ¨ ufung f ¨ ur Prozessoren mit Fließbandverarbeitung Das Verhaltensmodell der Spezifikation eines Prozessors entspricht einem funktio- nalen Modell des Prozessors, wie er von einem Programmierer gesehen wird, d. h. die einzelnen Instruktionen sind in der sog. Instruktionssatzarchitektur zusammen- gefasst. Es handelt sich hierbei um eine Beschreibung, der die Ausf ¨ uhrung von In- struktionen einzeln und nacheinander zugrunde liegt Die Prozessorimplementierung muss allerdings nicht zwangsl ¨ aufig alle Instruk- tionen sequenziell ausf ¨ uhren. Es ist denkbar und g ¨ angige Praxis, dass die Ausf ¨ uhrung 294 6 Hardware-Verifikation von Instruktionen verschr ¨ ankt erfolgt. Dies wird mit Hilfe einer sog. Fließbandver- arbeitung realisiert. Beispiel 6.3.2. Betrachtet wird der Prozessor aus Beispiel 6.3.1 in Abb. 6.44. Ei- ne Mikroarchitektur, die eine f ¨ unfstufige Pipeline implementiert ist in Abb. 6.45 zu sehen. Die einzelnen Pipeline-Stufen sind durch Pipeline-Register (graue Bl ¨ ocke) voneinander getrennt. In der ersten Stufe erfolgt das Laden einer neuen Instruktion (engl. instruction fetch, IF). In der zweiten Stufe wird die Instruktion decodiert (engl. instruction decode, ID). Die eigentliche Berechnung erfolgt in Stufe drei (engl. exe- cute, EX). Stufe vier ist den Speicherzugriffen (engl. memory, MEM) vorbehalten. Hier werden die entsprechenden Lade- und Speicherbefehle (engl. load/store) durch- gef ¨ uhrt. In der f ¨ unften Stufe wird schließlich das Zur ¨ uckschreiben (engl. write back, WB) des Ergebnisses in den Registersatz ausgef ¨ uhrt. Der ¨ Ubersichtlichkeit halber wurde wiederum der Kontrollpfad des Prozessors nicht dargestellt. read data 1 data 2 read ALU ADD read data Instruction Memory ADD Memory Data read register 2 write register read register 1 address address 4 Register File IF/ID ID/EX EX/MEM MEM/WB PC MUX MUX MUX write data write data Abb. 6.45. Mikroarchitektur mit f ¨ unfstufiger Pipeline des Prozessors aus Abb. 6.44 [355] Die Aufgabe einer formalen ¨ Aquivalenzpr ¨ ufung zwischen Instruktionssatzarchi- tektur und Prozessorimplementierung ist, zu zeigen, dass beide die selben Ergebnisse berechnen. Dies unterscheidet sich von der ¨ Aquivalenzpr ¨ ufung f ¨ ur endliche Automa- ten, da die Mikroarchitektur mit Fließbandverarbeitung mehr Zust ¨ ande besitzt als die sequentielle Instruktionssatzarchitektur. Deshalb ist es notwendig, beide Architektu- ren lediglich bez ¨ uglich des f ¨ ur den Programmierer sichtbaren Zustands zu verglei- chen. Dies wird in der Literatur auch als ¨ Ubereinstimmungsproblem bezeichnet. 6.3 Formale Verifikation von Prozessoren 295 ¨ Aquivalenzpr ¨ ufung mit Gleichheit und uninterpretierten Funktionen Viele Entwurfsfehler bei Prozessoren mit Fließbandverarbeitung entstehen in der Steuerungseinheit des Prozessors. Aus diesem Grund werden im Folgenden aus- schließlich Verfahren betrachtet, die diese Art von Entwurfsfehlern aufdecken k ¨ on- nen. Dies bedeutet, dass davon ausgegangen wird, dass die kombinatorische Logik, die den Datenpfad des Prozessors realisiert (also die eigentlichen Berechnungen durchf ¨ uhrt), fehlerfrei ist. Zur Abstraktion des Datenpfads f ¨ uhren Burch und Dill die Theorie der ” Gleichheit und uninterpretierte Funktionen“ (engl. Equality and Uninterpreted Functions, EUF) ein [75]. Korrektheitskriterium Der Verifikationsprozess geht von einer Verhaltensbeschreibung in der Spezifika- tion (Instruktionssatzarchitektur) und einer Strukturbeschreibung der Implementie- rung (Mikroarchitektur) aus. Die Instruktionssatzarchitektur beschreibt, wie sich der f ¨ ur den Programmierer sichtbare Zustand des Prozessors durch die Ausf ¨ uhrung einer Instruktion ¨ andert. Dies kann durch eine sequentielle Mikroarchitektur mit Zustands- raum S u und Eingabealphabet I modelliert werden. Die I mplementierung basiert auf dem selben Eingabealphabet I und f ¨ ur den Programmierer sichtbaren Zustandsraum S u .Dar ¨ uber hinaus besitzt eine Mikroarchitektur mit Fließbandverarbeitung auch Pipeline-Register, deren Zustandsraum durch S p modelliert wird. Sowohl die sequentielle Mikroarchitektur als auch die Mikroarchitektur mit Fließbandverarbeitung lassen sich in ¨ Ubergangsfunktionen f spec bzw. f impl ¨ uberset- zen. Beide ¨ Ubergangsfunktionen erhalten als erstes Argument den aktuellen Zustand und als zweites Argument die momentane Eingabe (Instruktion). Die R ¨ uckgabewert der Funktionen ist der Folgezustand, d. h. f spec : S u × I → S u , f impl : (S u × S p ) ×I → (S u × S p ). Um die ¨ Aquivalenz von Mikroarchitektur und ISA zu beweisen, muss gezeigt werden, dass, ausgehend von einem beliebigen Paar ¨ aquivalenter Zust ¨ ande aus der Spezifikation und Implementierung, die Ausf ¨ uhrung einer beliebigen Instruktion zu dem selben Ergebnis f ¨ uhrt. Anschließend m ¨ ussen sich Spezifikation und Implemen- tierung zus ¨ atzlich in ¨ aquivalenten Zust ¨ anden befinden. Dies kann durch ein kommu- tatives Diagramm dargestellt werden (siehe Abb. 6.46). Dabei wird die Abstraktion von dem momentanen Zustand der Mikroarchitektur (Prozessorzustand) auf den f ¨ ur den Programmierer sichtbaren Zustand durch die Funktion abs : (S u × S p ) → S u be- rechnet. Die Anfangszust ¨ ande von ISA und Mikroarchitektur sind per definitionem ¨ aquivalent. Um zu ¨ uberpr ¨ ufen, ob sich Spezifikation und Implementierung in ¨ aquivalenten Zust ¨ anden befinden, bietet es sich an, ein Flushing der Pipeline durchzuf ¨ uhren. Na- hezu alle Prozessoren besitzen spezielle Instruktionen, die eine Weiterverarbeitung von Instruktionen in der Pipeline erlauben, ohne dass neue Instruktionen initiiert 296 6 Hardware-Verifikation f spec (s,i)f impl (q,i) q  qs s  Abstraktion Abstraktion Abb. 6.46. Kommutatives Diagramm zur Visualisierung der ¨ Aquivalenzpr ¨ ufung von Prozes- soren [451] werden. Eine solche spezielle Instruktion i stall wird als engl. stalling bezeich- net, d. h. f impl (q,i stall ) berechnet den Folgezustand des Prozessors bei einmaliger Ausf ¨ uhrung von i stall im Zustand q. Durch eine hinreichende Wiederholung dieser Instruktion k ¨ onnen alle Instruktionen in der Pipeline abgearbeitet werden. Dies wird als engl. Flushing der Pipeline bezeichnet. Diese Idee f ¨ uhrt zu dem kommutativen Diagramm in Abb. 6.47. s s  f impl (q,i) q 1 q n q  1 q  n q  q f spec (s,i) f impl (q  n−1 ,i stall ) proj(q  n ) f impl (q n−1 ,i stall ) proj(q n )f impl (q,i stall ) f impl (q 1 ,i stall ) f impl (q  ,i stall ) f impl (q  1 ,i stall ) Abb. 6.47. Kommutatives Diagramm mit Flushing der Pipeline [75] In diesem kommutativen Diagramm wird davon ausgegangen, dass sich der Pro- zessor in einem beliebigen Zustand q befindet. Um den f ¨ ur den Programmierer sicht- baren Zustand zu extrahieren, wird zun ¨ achst ein Flushing der Pipeline durchgef ¨ uhrt. Sind keine Instruktionen mehr zur Verarbeitung in der Pipeline, kann von dem Pro- zessorzustand q n durch Projektion (Ausblenden des Zustands der Pipeline-Register) auf den f ¨ ur den Programmierer sichtbaren Zustand s geschlossen werden, d. h. es existiert eine Projektionsfunktion proj : (S u ×S p ) → S u . Ausgehend von s kann durch Ausf ¨ uhrung der Instruktion i der Folgezustand s  in der Spezifikation bestimmt wer- den. Der selbe Zustand s  muss als f ¨ ur den Programmierer sichtbaren Zustand erreicht werden, wenn sich der Prozessor im Zustand q befindet, die Instruktion i ausgef ¨ uhrt, und eine Flushing der Pipeline durchgef ¨ uhrt wird. Nach Ausf ¨ uhrung von i und dem Flushing der Pipeline befindet sich der Prozessor im Zustand q  n . Durch Projektion wird der Zustand s  in der ISA erreicht. Vergleicht man dies mit Abb. 6.46, so ergibt 6.3 Formale Verifikation von Prozessoren 297 sich: abs(s u ,s p ) := proj( f + impl ((s u ,s p ), i stall , ,i stall     )) l (6.10) wobei l die Anzahl der Pipeline-Stufen und f + impl die erweiterte ¨ Ubergangsfunktion f ¨ ur die Implementierung nach Gleichung (4.3) auf Seite 142 ist. Hiermit kann das Korrektheitskriterium nach Abb. 6.46 wie folgt definiert werden: ∀s u ,s p ,i : abs( f impl (s u ,s p ,i)) ? ≡ f spec (abs(s u ,s p ),i) (6.11) Dabei ist i eine beliebige Instruktion aus dem Instruktionssatz des Prozessors. Korrektheitsbeweis Um zu zeigen, dass die Implementierung eines Prozessors ¨ aquivalent zu dessen Spe- zifikation ist, muss gezeigt werden, dass f impl (q,i) und f spec (s,i) ¨ aquivalent f ¨ ur ein beliebiges Paar ¨ aquivalenter Zust ¨ ande (q,s) und eine beliebige Instruktion i sind (siehe Gleichung (6.11)). Beide Funktionen k ¨ onnen jeweils als Vektor symbolischer Ausdr ¨ ucke repr ¨ asentiert werden. Jedes Element eines Vektors entspricht dabei ei- ner f ¨ ur den Programmierer sichtbaren Zustandsvariablen. Die Ausdr ¨ ucke k ¨ onnen nacheinander z. B. durch symbolische Simulation der Spezifikation bzw. der Imple- mentierung gewonnen werden. Dabei muss die Implementierung mehrfach stimuliert werden, um das Flushing der Pipeline zu simulieren. Seien (q 1 , ,q n ) und (s 1 , ,s n ) Vektoren von Ausdr ¨ ucken. Um die ¨ Aquivalenz der Funktionen f impl und f spec zu zeigen, muss die Gleichheit der Ausdr ¨ ucke q k und s k f ¨ ur alle k gezeigt werden, d. h. ∀1 ≤ k ≤ n : q k = s k gelten. Zur Abstraktion vom Datenpfad des Prozessors werden die Ausdr ¨ ucke q k und s k mit Hilfe der Theorie ” Gleichheit und Uninterpretierte Funktionen“(engl. Equa- lity with Uninterpreted Functions, EUF) gebildet. In EUF werden Funktionen nicht ausgewertet, sondern lediglich durch Funktionssymbole repr ¨ asentiert. Die einzige Annahme, die ¨ uber Funktionen in EUF getroffen wird, lautet: (x 1 = y 1 ) ∧(x 2 = y 2 ) ⇒ f (x 1 ,x 2 )= f (y 1 ,y 2 ) Dies bedeutet, dass Funktionen, die durch das selbe Funktionssymbol f repr ¨ asen- tiert werden, und die mit ¨ aquivalenten Argumenten aufgerufen werden, das gleiche Ergebnis liefern. Beispiel 6.3.3. Betrachtet wird der Prozessor aus Beispiel 6.3.2 in Abb. 6.45. Die Einheit zum Inkrement des PC, der Addierer zur Berechnung von Sprungzielen und die ALU k ¨ onnen jeweils durch die Funktionssymbole f inc , f add bzw. f alu abstrahiert werden. Ebenfalls kann der Instruktionsspeicher durch ein Funktionssymbol f im re- pr ¨ asentiert werden, da dieser niemals modifiziert wird. Dies ist in Abb. 6.48 zu sehen. EUF kann durch die folgende Syntax repr ¨ asentiert werden: 298 6 Hardware-Verifikation read data 1 data 2 read read data Memory Data read register 2 write register read register 1 address Register File IF/ID ID/EX EX/MEM MEM/WB f inc f add f alu f im PC MUX MUX MUX write data write data Abb. 6.48. Mikroarchitektur des Prozessors aus Abb. 6.45 mit Funktionssymbolen term ::= ITE( formula,term,term) | f unction symbol(term, ,term) formula ::= F | T |¬formula | ( formula∧ formula) | ( formula∨ formula) | (term = term) | predicate symbol(term, ,term) In EUF tragen Formeln ( formula) entweder den Wert F (falsch) oder T (wahr). Ter- me (term)k ¨ onnen beliebige Werte tragen und werden aus uninterpretierten Funk- tionssymbolen und der Anwendung des ITE-Operators (engl. if-then-else) gebildet. Der ITE-Operator w ¨ ahlt dabei zwischen zwei Termen aus, basierend auf dem Wert einer Steuerungsvariablen, d. h. ITE(F,x 1 ,x 2 ) ergibt x 2 ,w ¨ ahrend ITE(T,x 1 ,x 2 ) das Ergebnis x 1 liefert. Formeln werden gebildet, indem zwei Terme auf Gleichheit ¨ uberpr ¨ uft, ein un- interpretiertes Pr ¨ adikatensymbol (predicate symbol) auf eine Liste von Termen an- gewendet, oder Formeln mit Hilfe aussagenlogischer Operatoren (∧, ∨) verkn ¨ upft werden. Eine Formel, die zwei Terme auf Gleichheit ¨ uberpr ¨ uft, wird als Gleichung bezeichnet. Der Begriff Ausdruck bezeichnet im Folgenden sowohl Terme als auch Formeln. Zu jedem Funktionssymbol f gibt es eine sog. Ordnung ord( f ), welche die An- zahl der Argumente angibt. Funktionssymbole mit Ordnung null werden als Varia- blen betrachtet. In diesem Fall wird anstatt von v() auch die kurze Schreibweise v verwendet. Ebenfalls besitzen Pr ¨ adikatensymbole p eine Ordnung ord(p).Pr ¨ adika- tensymbole der Ordnung null werden als aussagenlogische Variablen bezeichnet. In diesem Fall wird a anstelle von a() geschrieben. 6.3 Formale Verifikation von Prozessoren 299 Der Wahrheitsgehalt einer Formel wird relativ zu einer nichtleeren Definitions- menge D und einer Interpretation I der Funktions- und Pr ¨ adikatensymbole definiert. Eine Interpretation I weist jedem Funktionssymbol der Ordnung k eine Funktion von D k nach D und jedem Pr ¨ adikatensymbol der Ordnung k eine Funktion von D k nach {F,T} zu. Im Sonderfall der Ordnung null wird dem Funktionssymbol (Pr ¨ adikaten- symbol) eine Variable aus der Definitionsmenge (der Menge {F, T}) zugewiesen. Gegeben sei eine Interpretation I sowie ein Ausdruck E. Die Bewertung von E unter der Interpretation I, geschrieben als I[E], kann rekursiv entsprechend Tabel- le 6.5 erfolgen. Tabelle 6.5. Bewertung von EUF Formeln und Termen [67] Ausdruck E Bewertung I[E] F F T T ¬F ¬I[F] F 1 ∧ F 2 I[F 1 ] ∧I[F 2 ] p(T 1 , ,T k ) I(p)(I[T 1 ], ,I[T k ]) T 1 = T 2 I[T 1 ]=I[T 2 ] ITE(F,T 1 ,T 2 ) ITE(I[F],I[T 1 ],I[T 2 ]) f (T 1 , ,T k ) I( f )(I[T 1 ], ,I[T k ]) Falls I[F]=T gilt, so sagt man, dass die Formel F unter der Interpretation I g ¨ ultig ist. Eine Formel ist g ¨ ultig in der Dom ¨ ane D, falls sie f ¨ ur alle Interpretationen ¨ uber D g ¨ ultig ist. Schließlich heißt die Formel F allgemeing ¨ ultig, falls sie ¨ uber al- le Definitionsbereiche D g ¨ ultig ist. Es ist bekannt, dass eine gegebene Formel ¨ uber dem Definitionsbereich D g ¨ ultig ist, genau dann, wenn sie ¨ uber alle anderen Defini- tionsbereichen mit der selben Kardinalit ¨ at g ¨ ultig ist. Weiterhin gilt, dass wenn eine gegebene Formel f ¨ ur eine angemessen große Definitionsmenge g ¨ ultig ist, so ist sie allgemeing ¨ ultig [2]. Reduktion von EUF auf Aussagenlogik Eine M ¨ oglichkeit EUF-Formeln auf ihre G ¨ ultigkeit zu ¨ uberpr ¨ ufen besteht darin, die EUF-Formeln auf aussagenlogische Formeln zu reduzieren. Hierzu m ¨ ussen die Funktions- und Pr ¨ adikatensymbole eliminiert werden. Grundlegende Arbeiten zur Elimination von Funktionssymbolen mit Ordnung eins und h ¨ oher sind in [2] zu fin- den. Dabei wird jeder Term, der eine Anwendung eines Funktionssymbol beinhaltet, durch eine neue Definitionsbereichsvariable ersetzt und zus ¨ atzlich Beschr ¨ ankungen zu der Formel hinzugef ¨ ugt, um funktionale Konsistenz zu erreichen. Ein alternativer Ansatz ist in [67] beschrieben, bei dem jede Anwendung eines Funktionssymbols durch einen ITE-Operator ersetzt wird. Die Idee dabei ist, dass ¨ uber alle Funktions- und Pr ¨ adikatensymbole mit Ordnung eins oder h ¨ oher iteriert wird, und dabei jedes Auftreten des Symbols durch eine ITE-Operation eliminiert wird. Ohne den Algorithmus aus [67] zu wiederholen, wird das Prinzip anhand eines Beispiels demonstriert. 300 6 Hardware-Verifikation Beispiel 6.3.4. Gegeben ist die EUF-Formel: ¬(x = y) ∨ (h(g(x),g(g(x))) = h(g(y),g(g(x)))) (6.12) Schematisch l ¨ asst sich Gleichung (6.12) wie in Abb. 6.49 dargestellt repr ¨ asentie- ren. Definitionsbereichsvariablen werden dabei als Eing ¨ ange dargestellt. Werte des Definitionsbereichs werden als durchgezogene Linien dargestellt. Aussagenlogische Variablen werden als gestrichelte Linien gezeichnet. Der Ausgang repr ¨ asentiert die gesamte EUF-Formel. xy ∨ = h h ¬= g g g Abb. 6.49. Schematische Repr ¨ asentation von Gleichung (6.12) [67] Um die Funktionssymbole i n Gleichung (6.12) durch ITE-Operationen zu erset- zen, m ¨ ussen die Funktionssymbole nacheinander betrachtet werden. Zun ¨ achst wird das Funktionssymbol g betrachtet. Insgesamt wird dieses in drei Termen in Glei- chung (6.12) verwendet: g(x),g(y) und g(g(x)). Diese drei Terme werden durch die Bezeichner T 1 , T 2 und T 3 identifiziert. Weiterhin werden drei neue Definitionsbe- reichsvariablen v g1 , v g2 und v g3 eingef ¨ uhrt. Der Term T 1 ergibt sich dann wie folgt: T 1 := v g1 (6.13) Dies bedeutet, dass die Anwendung des Funktionssymbols g auf das Argument x mit einer neuen Variablen v g1 repr ¨ asentiert wird. Die Anwendung des Funktionssymbols g auf das Argument y kann auf ¨ ahnliche Art durch die Variable v g2 repr ¨ asentiert werden. Allerdings kann man an dieser Stelle bereits den Sonderfall x = y mit g(x)= g(y) ber ¨ ucksichtigen. Dies ergibt die folgende Definition des Terms T 2 : T 2 := ITE(x = y,v g1 ,v g2 ) (6.14) Schließlich wird der Term T 3 , der den Ausdruck g(g(x)) repr ¨ asentiert, betrach- tet. An dieser Stelle muss die Variable v g1 , die den Ausdruck g(x ) repr ¨ asentiert, wie- derverwendet werden. Im Allgemeinen m ¨ ussen verschachtelte Anwendungen von Funktionssymbolen stets von Innen nach Außen aufgel ¨ ost werden. Wie im Fall von 6.3 Formale Verifikation von Prozessoren 301 T 2 in Gleichung (6.14), muss bei T 3 eine Fallunterscheidung vorgenommen werden. Diese ist aber geschachtelt: T 3 := ITE(v g1 = x,v g1 ,ITE(v g1 = y,v g2 ,v g3 )) (6.15) Mit anderen Worten: Ist der Funktionswert von g(x)=x, so muss der Funktionswert von g(g(x)) ebenfalls x sein. Falls dies nicht zutrifft, der Funktionswert von g(x) aber gleich y ist, so muss das Ergebnis von g(g(x)) = g(y) sein. Dies wurde bereits in Gleichung (6.14) definiert. Mit der Nebenbedingung, dass g(x) = x ist, ergibt dies v g2 . In allen anderen F ¨ allen k ¨ onnen keine weiteren Annahmen ¨ uber den Funktions- wert f ¨ ur den Term T 3 getroffen werden, d. h. der Funktionswert wird durch eine neue Variable v g3 repr ¨ asentiert. Schematisch l ¨ asst sich die Elimination des Funktionssymbols g durch ITE- Operationen in dem DAG aus Abb. 6.49 einzeichnen. Verwendet man zur Re- pr ¨ asentation des ITE-Operators Multiplexer, so kommt man zu der Darstellung in Abb. 6.50a). Man beachte, dass ¨ uber die Variablen v g1 , v g2 und v g3 keinerlei Annah- men getroffen wurden, weshalb die Reduktion allgemeing ¨ ultig ist. Die Elimination des Funktionssymbols h erfolgt analog mit Hilfe der Definiti- onsbereichsvariablen v h1 und v h2 . Dabei wird die erste Anwendung des Funktions- symbols durch die Variable v h1 ersetzt und die zweite Anwendung durch eine ITE- Operation, welche die Argumente der beiden Funktionsaufrufe vergleicht. Falls diese identisch sind, m ¨ ussen auch die Funktionswerte identisch sein. Andernfalls muss der neue (unbekannte) Funktionswert durch eine neue Variable v h2 repr ¨ asentiert werden. Das Ergebnis ist in Abb. 6.50b) zu sehen. Nach der Elimination von Funktions- und Pr ¨ adikatensymbolen m ¨ ussen die De- finitionsbereichsvariablen noch geeignet codiert werden, um zu einer aussagenlogi- schen Formel zu gelangen. Dies wird hier nicht weiter betrachtet. Effiziente Speichermodellierung Bei der Prozessorverifikation m ¨ ussen typischerweise Speicherzugriffe ber ¨ ucksichtigt werden. Der Adressraum wird dabei als unendlich angenommen. Kann die ¨ Aqui- valenz unter dieser Annahme gezeigt werden, so gilt diese auch unter der Annah- me eines endlichen Speichers (Registersatz und Hauptspeicher). Mit der oben be- schriebenen Theorie zur ” Gleichheit und uninterpretierte Funktionen“ lassen sich unter bestimmten Konventionen Speicherzugriffe modellieren. Dies erfolgt durch ei- ne Verschachtelung von ITE-Operatoren zur Repr ¨ asentation von Lesezugriffen auf den Speicher. In dieser Verschachtelung ist die Historie aller Schreibzugriffe erfasst, d. h. nach k Schreiboperationen an die Adressen a 1 , ,a k mit den Daten d 1 , ,d k kann der Effekt einer Leseoperation auf Adresse a wie folgt modelliert werden: ITE(a = a k ,d k ,ITE(a = a k−1 ,d k−1 , ,ITE(a = a 1 ,d 1 , f init (a)) )) Dabei beschreibt f init (a) eine uninterpretierte Funktion, die den Anfangswert an der Adresse a repr ¨ asentiert. 302 6 Hardware-Verifikation a) b) v g1 = = = = = = T F T F T F T F T F T F ¬ ¬ = = h h ∧ T F = = ∨ ∨ v g3 v g2 yx v g3 v h2 v h3 xy v g2 v g1 Abb. 6.50. Elimination des a) Funktionssymbols g und b) des Funktionssymbols h [67] Oftmals ist es jedoch effektiver zwei spezielle Funktionen f read und f write zu ver- wenden. Die Funktion f write (mem,addr,val) besitzt drei Argumente: den momenta- nen Speicherinhalt mem, die Schreibadresse addr und das Datum val. Sie gibt den aktualisierten Speicherinhalt zur ¨ uck. Die Funktion f read (mem,addr) besitztzweiAr- gumente: den Speicherinhalt mem und die Leseadresse addr. Die Funktion gibt den an der Adresse addr gespeicherten Wert zur ¨ uck, wobei die folgende Konvention ein- gehalten wird: f read ( f write (mem,addr1,val),addr2)=  val falls addr1 = addr2 f read (mem,addr2) sonst Einen anderen Ansatz verfolgen Bryant und Velev durch die Einf ¨ uhrung eines effizienten Speichermodells [68] (siehe auch Abschnitt 6.4.2). F ¨ ur die symbolische

Ngày đăng: 02/07/2014, 14:20

Từ khóa liên quan

Mục lục

  • Cover

  • Digitale Hardware/ Software-Systeme

  • ISBN 978-3-642-05355-9

  • Vorwort

  • Inhaltsverzeichnis

  • 1 Einleitung

    • 1.1 Motivation

    • 1.2 Der Verifikationsprozess

      • 1.2.1 Das V-Modell

      • 1.2.2 Das Doppeldachmodell des Entwurfsprozesses

      • 1.2.3 Das Doppeldachmodell des Verifikationsprozesses

      • 1.3 Eine kurze Geschichte der Verifikation

      • 1.4 Beispiele

      • 1.5 Ausblick

      • 1.6 Literaturhinweise

      • 2 Spezifikation digitaler Systeme

        • 2.1 Wie spezifiziert man ein System?

        • 2.2 Formale Verhaltensmodelle

          • 2.2.1 Petri-Netze

          • 2.2.2 Endliche Automaten

          • 2.2.3 Datenflussgraphen

          • 2.2.4 Heterogene Modelle

          • 2.3 Ausführbare Verhaltensmodelle

            • 2.3.1 SystemC

            • 2.3.2 SysteMoC

Tài liệu cùng người dùng

Tài liệu liên quan