Digitale Hardware/ Software-Systeme- P2 docx

Drei Arten der Pr¨ufung in der Verifikation 1.3 Eine kurze Geschichte der Verifikation Zur Verifikation wird neben der Spezifikation und der Implementierung auch eine leistungsf¨ahige Ve

Dabei ist das Zeitverhalten der Hardware stark durch die gew¨ahlte Technologie einflusst: Die Gatterlaufzeiten bestimmen den kritischen Pfad in einem System undsomit die Taktrate bzw die Tiefe der Pipeline Diese Effekte sind nicht auf die Logi-kebene beschr¨ankt, sondern sind auch auf Architekturebene und sogar Systemebene

be-zu ber¨ucksichtigen

Im Bereich der Software-Verifikation trifft man auf ¨ahnliche Aufgaben wie inder Hardware-Verifikation Auf Blockebene liegt die Implementierung in Form einesAssemblerprogramms f¨ur den gew¨ahlten Prozessor vor Die Spezifikation ist in ei-ner Hochsprache verfasst, h¨aufig in eingebetteten Systemen C/C++ Auch auf dieserEbene kann es wichtig sein, die ¨Aquivalenz von Programmen zu zeigen, da geradeeingebettete Software stark optimiert wird, um den Speicher- und Geschwindigkeits-anforderungen zu gen¨ugen Da eingebettete Systeme und deren Software auch h¨aufig

in sicherheitskritischen Bereichen eingesetzt werden, ergibt sich aber auch als tere Verifikationsaufgabe zu zeigen, ob ein Programm gewisse funktionale Eigen-schaften besitzt So sollte eine Steuerungs-Software nicht verklemmen und korrektauf Anfragen reagieren

wei-Daneben hat die Mikroarchitektur des Prozessors einen großen Einfluss auf dieAbarbeitungsgeschwindigkeit von Instruktionen, d h unterschiedliche Mikroarchi-tekturen k¨onnen die selbe Instruktionssatzarchitektur implementieren, aber ein un-terschiedliches zeitliches Verhalten besitzen Dies hat Einfluss auf die Ausf¨uhrungs-zeiten nicht nur einzelner Instruktionen, sondern auf ganze Programme Die ¨Uber-pr¨ufung der Einhaltung der Zeitanforderung ist somit eine Verifikationsaufgabe so-wohl auf Block- als auch auf Modulebene

Auf Systemebene ist die ¨Uberpr¨ufung von Eigenschaften der Implementierungnoch vordergr¨undiger Aufgrund der Komplexit¨at von Spezifikation und Implemen-tierung ist eine vollst¨andige Pr¨ufung nicht mehr praktikabel Das Verhalten auf Sys-temebene wird oftmals durch ein Modell kommunizierender Prozesse beschrieben.Das in der Implementierung verwendete Strukturmodell ist h¨aufig eine Netzliste ausProzessoren, Speichern, Bussen und Hardware-Beschleunigern Bei der Verifikationwird dabei eine Fokussierung auf die Interaktion der Komponenten untereinander

durch Transaktionen vorgenommen Neben der ¨Uberpr¨ufung des Verhaltens ist aberauch das Einhalten von Zeiteigenschaften von großer Bedeutung

Das X-Diagramm der Verifikation

Analog zu dem X-Diagramm f¨ur den Entwurf (Abb 1.12) wird nun ein X-Diagrammf¨ur die Verifikation entwickelt Dieses ist in Abb 1.14 zu sehen Es dient zur Formu-lierung der grundlegenden Verifikationsaufgaben bei der Entwicklung eingebetteterSysteme

In Abb 1.14a) sieht man graphisch dargestellt, dass die Verifikation die mentierung gegen ihre Spezifikation pr¨uft Die gleiche Verfeinerung wie im Entwurf

Imple-in Abb 1.12b) ist f¨ur die Verifikation vorgenommen worden (Abb 1.14b)) EImple-ine zifikation besteht aus einem Verhaltensmodell und Anforderungen Eine Implemen-tierung besteht aus einer Strukturbeschreibung und den Qualit¨atsmerkmalen, die f¨urdie Implementierung ermittelbar sind Die Verifikation besteht aus zwei Schritten:

Spe-1.2 Der Verifikationsprozess 21b)

Abb 1.14 X-Diagramm der Verifikation

Abstraktion und Pr¨ufung Die Abstraktion kann notwendig sein, da im

Entwurfspro-zess gegen¨uber dem Verhaltensmodell Verfeinerungsinformationen im

Strukturmo-dell aufgenommen worden sind Die Pr¨ufung h¨angt von der Verifikationsaufgabe ab.

Aus dem X-Diagramm lassen sich im Wesentlichen drei grundlegende aufgaben ableiten, die im Folgenden unterschieden werden Diese sind unabh¨angigvon der Abstraktionsebene definiert:

Verifikations-1 ¨ Aquivalenzpr¨ufung: Bei der ¨Aquivalenzpr¨ufung wird das Strukturmodell mitdem Verhaltensmodell auf ¨Aquivalenz ¨uberpr¨uft, d h es wird versucht, die Fra-

ge zu beantworten, ob unter allen Umst¨anden das Strukturmodell das selbe halten wie das Verhaltensmodell der Spezifikation aufweist (siehe Abb 1.15a))

Ver-2 Pr¨ufung funktionaler Eigenschaften: In der funktionalen Eigenschaftspr¨ufung

wird das Strukturmodell der Implementierung dahingehend ¨uberpr¨uft, ob es diefunktionalen Eigenschaften in den Anforderungen erf¨ullt (siehe Abb 1.15b)).Dies k¨onnen z B Gefahrlosigkeitseigenschaften oder Lebendigkeitseigenschaf-ten sein

3 Pr¨ufung nichtfunktionaler Eigenschaften: In der nichtfunktionalen

Eigenschafts-pr¨ufung werden die Anforderungen an die Qualit¨atsmerkmale der rung ¨uberpr¨uft Es wird also gepr¨uft, ob die Merkmale den Anforderungen derSpezifikation gen¨ugen (siehe Abb 1.15c)) Die Schwierigkeit besteht darin, dassdie Qualit¨atsmerkmale auf niedrigen Abstraktionsebenen ermittelt werden unddurch geeignete Kompositionen von Absch¨atzungen auf h¨oheren Ebenen durch-gef¨uhrt werden m¨ussen, wo die Anforderungen spezifiziert sind

Implementie-Funktionale und nichtfunktionale Eigenschaften sind typischerweise nicht h¨angig voneinander So kann beispielsweise die Verletzung einer Zeitanforderungeine Gefahrensituation ausl ¨osen, oder anders herum

unab-Die grundlegenden Verifikationsaufgaben sind noch einmal in Abb 1.15 phisch dargestellt Jede der drei Aufgaben kann auf jeder Abstraktionsebene zumEinsatz kommen Allerdings bekommen die Eigenschaftspr¨ufungen auf hohen Ab-

gra-straktionsebenen eine gr¨oßere Bedeutung, w¨ahrend die ¨Aquivalenzpr¨ufung im sentlichen auf tieferen Abstraktionsebenen eingesetzt wird.

We-a)

Verhalten Anforderungen

pr¨ufung Eigenschafts- funktionale Abstraktion &

¨ Aquivalenz- pr¨ufung Abstraktion &

Qualit¨ats-merkmale

Anforderungen

Abstraktion &

pr¨ufung Eigenschafts- funktionale nicht-

Abb 1.15 Drei Arten der Pr¨ufung in der Verifikation

1.3 Eine kurze Geschichte der Verifikation

Zur Verifikation wird neben der Spezifikation und der Implementierung auch eine

leistungsf¨ahige Verifikationsmethode ben¨otigt Grob lassen sich

Verifikationsmetho-den in formale und simulative MethoVerifikationsmetho-den klassifizieren Die Entwicklung von kationsmethoden hat eine lange Geschichte Insbesondere formale Methoden basie-ren auf mathematischen Beweisverfahren, die teilweise Jahrhunderte vor der Erfin-dung des Computer entwickelt wurden Im Gegensatz dazu wurden viele simulativeVerfahren erst mit dem Vorhandensein von leistungsf¨ahigen Computern erm¨oglicht

Verifi-In diesem Abschnitt wird eine kurze geschichtliche ¨Ubersicht zu der Entwicklungvon Verifikationsmethoden gegeben Eine ausf¨uhrliche Darstellung findet man in[390] Ein ¨Uberblick ¨uber die Geschichte der Logik kann [413] entnommen werden

Der Begriff Verifikation leitet sich vom lateinischen Wort veritas, die Wahrheit,

ab Verifikation ist der Nachweis bzw der Prozess des Nachweisens, dass ein muteter oder behaupteter Sachverhalt wahr ist Zentral f¨ur die Verifikation ist der

ver-Begriff der Logik Bereits Aristoteles (384 v Chr – 322 v Chr.) entwickelte eine

ers-te formale Logik mit dem Ziel, Gesetze des menschlichen Denkens zu finden Dabei

entwickelte er Schemata zur Repr¨asentation g¨ultiger Schl¨usse, sog Syllogismen Ein

g¨ultiger Schluss ist eine Konfiguration der Form [413]:

Pr¨amissen Folgerung

1.3 Eine kurze Geschichte der Verifikation 23

Hierbei wird ausgehend von einer endlichen Anzahl an Pr¨amissen eine Folgerung

geschlossen Als Beispiel diene die Folgerung:

Alle P sind Q ,a ist P

a ist Q Unabh¨angig von der konkreten Interpretation von P und Q ist die Folgerung richtig Man kann z B f¨ur P das Pr¨adikat Mensch, f¨ur Q das Pr¨adikat sterblich und f¨ur a das Individuum Sokrates w¨ahlen Hierdurch entsteht eine ber¨uhmte Instanz der obigen

Folgerung:

Alle Menschen sind sterblich, Sokrates ist ein Mensch

Sokrates ist sterblich

Die Richtigkeit dieser Folgerung ist bereits bewiesen

2000 Jahre sp¨ater, im Jahr 1686, entwickelte Gottfried Wilhelm Leibniz in

sei-nem Werk Generales Inquisitiones de Analysi Notionum et Veritatum (Allgemeine

Untersuchungen ¨uber die Zerlegung der Begriffe und Wahrheiten) eine erste

moder-ne Logik, aufgebaut in eimoder-ner mathematischen Sprache, der Kalk¨ulform Nahezu zwei Jahrhunderte sp¨ater ver¨offentlicht George Boole 1847 in The Mathematical Analysis

of Logic: Being an Essay towards a Calculus of Deductive Reasoning das erste gebraische Logikkalk¨ul und begr¨undet darin die heutige Aussagenlogik In der Aus- sagenlogik werden ausgehend von atomaren Aussagen A ,B,C, , welche die Werte

al-wahr (T) oder nicht wahr (F) annehmen k¨onnen, mit Hilfe der Junktoren ¬ (nicht),

∨ (oder), ∧ (und) und ⇒ (impliziert) neue Aussagen gebildet Ein Kalk¨ul der sagenlogik basiert auf einer endlichen Anzahl an Axiomen, mit deren Hilfe g¨ultige

Aus-Aussagen unabh¨angig vom Wahrheitsgehalt der atomaren Aus-Aussagen gefolgert den k¨onnen Beispiele hierf¨ur sind [413]:

wer-A ∨ ¬A

T

A ,A ⇒ B B Die Pr¨adikatenlogik erster Ordnung wird erstmals von Gottlob Frege in sei- nem Buch Begriffsschrift – Eine der arithmetischen nachgebildete Formelsprache des reinen Denkens im Jahr 1879 beschrieben Die Pr¨adikatenlogik erster Ordnung erweitert die Aussagenlogik um Funktionen, Pr¨adikate und Quantoren Mit Hilfe

mehrstelliger Pr¨adikate oder Relationen werden atomare Aussagen gebildet Diesek¨onnen wie in der Aussagenlogik durch Junktoren zu neuen Aussagen zusammen-

gesetzt werden Zus¨atzlich kann durch die Existenz- ( ∃) bzw Allquantifizierung (∀) gepr¨uft werden, ob eine Aussage auf mindestens eine bzw auf alle Variablen zutrifft.

Neue Axiome der Pr¨adikatenlogik, die ¨uber die Axiome der Aussagenlogik gehen, sind beispielsweise [413]:

T

A (x)

∀x : A(x)

1929 beweist Kurt G¨odel die Vollst¨andigkeit der Pr¨adikatenlogik erster Ordnung,

d h alle logisch g¨ultigen Aussagen sind herleitbar im System der Pr¨adikatenlogik

erster Ordnung Zwei Jahre sp¨ater, 1931, ver¨offentlichte Kurt G¨odel in [198] den

G¨odelschen Unvollst¨andigkeitssatz, der Grenzen f¨ur formale Systeme aufzeigt Er

besagt beispielsweise, dass in der Arithmetik nicht alle Aussagen formal bewiesenoder widerlegt werden k¨onnen Die zentrale Aussage des Satzes lautet:

”Jedes

hin-reichend m¨achtige formale System ist entweder widerspr¨uchlich oder unvollst¨andig“.

Obwohl die Aussage des Unvollst¨andigkeitssatzes eine negative ist, ist sie eine derzentralen Erkenntnisse des vergangenen Jahrhunderts und hat nachhaltig die Frage-stellungen der Forschung in eine neue und fruchtbare Richtung bewegt

Im Jahr 1937 ver¨offentlichte Alan Turing eine grundlegende Arbeit [444], inder er die Ergebnisse Kurt G¨odels neu formulierte Dabei ersetzte er die forma-

len Systeme G¨odels durch eine einfache Maschine, die nach ihm benannte Maschine Eine Turing-Maschine ist eine hypothetische

Turing-”Rechenmaschine“ Sie steht aus einem Band, welches unendlich lang ist Dieses ist in einzelne Felder un-terteilt In einem Feld k¨onnen Symbole aus einem endlichen Alphabet stehen EinLese-/Schreibkopf steht zu jedem Zeitpunkt genau auf einem Feld Neben dem Spei-cher auf dem Band besitzt eine Turing-Maschine noch interne Zust¨ande In einemRechenschritt liest die Turing-Maschine das Symbol auf dem Band, ¨andert seineninternen Zustand, schreibt an die selbe Position auf dem Band ein neues (evtl identi-sches) Symbol und bewegt den Lese-/Schreibkopf um eine Position nach links oderrechts, oder bleibt gleich Die Eingaben zur Berechnung m¨ussen vorher auf das Bandgeschrieben werden Ist die Berechnung abgeschlossen, so befindet sich die Turing-Maschine in einem ausgezeichneten Haltezustand und das Ergebnis der Berechnungsteht auf dem Band

be-Turing konnte beweisen, dass eine be-Turing-Maschine in der Lage ist,

”jedes

vor-stellbare mathematische Problem zu l¨osen, sofern dieses auch durch einen mus gel¨ost werden kann“ Hiermit bewies Turing, dass das Halteproblem mit Hilfe

Algorith-der Turing-Maschine nicht entscheidbar ist Die Unentscheidbarkeit des

Haltepro-blems kann wie folgt formuliert werden: Es gibt keinen Algorithmus A1, der f¨ur einen beliebigen Algorithmus A2und beliebige Eingabe E entscheidet, ob A2mit der Eingabe E terminiert.

Turings Werk ist zentral f¨ur die Theoretische Informatik und wird manchmal gar als Geburtsstunde der gesamten Informatik bezeichnet Dies liegt nicht zuletztdaran, dass Turings Ideen einen wesentlichen Einfluss auf den Bau digitaler Com-puter aus¨ubte Die Bedeutung von Turings (und somit G¨odels) Arbeiten kann manfassen, wenn man sich vor Augen f¨uhrt, dass sie die Grenzen der Verifikation aufzei-gen Mit anderen Worten: Es gibt Verifikationsprobleme, die sich nicht beantwortenlassen, da das zugrundeliegende Problem nicht entscheidbar ist Somit haben dieseArbeiten Auswirkungen, die in diesem Buch ber¨ucksichtigt werden m¨ussen.Neben der Aussagenlogik und Pr¨adikatenlogik erster Ordnung gibt es viele wei-tere f¨ur die Verifikation wichtige Logiken Ein Beispiel f¨ur eine ganze Klasse sol-

so-cher weiteren Logiken sind die sog Modallogiken Modallogiken erweitern die

bis-her vorgestellten Logiken um die Konzepte

”notwendig“ und”m¨oglich “ Die

Ide-en gehIde-en wiederum auf Aristoteles zur¨uck Ende der 1950er Jahre ver¨offIde-entlichteSaul Kripke aufsehenerregende Arbeiten zur Modallogik [268] Die Bedeutung derModallogik und der Arbeiten von Kripke wird klar, wenn man sich ihr Anwendungs-

1.3 Eine kurze Geschichte der Verifikation 25feld, die ¨Uberpr¨ufung funktionaler Eigenschaften von digitalen Systemen, vor Augenf¨uhrt Dies wird an dem folgenden Beispiel aus [413] verdeutlicht:

Gegeben sei das folgende Programm, welches die Sequenz der Primzahlen druckt:

Modallogik k¨onnen nun Aussagen wie

”Es ist notwendig, dass im Zustand (2,y1 ,y2)

gilt, dass y1prim ist“ formuliert werden.

1977 schl¨agt Pnueli eine Erweiterung von Modallogiken um temporale

Opera-toren vor, so dass auch die zeitliche Ordnung beim Auftreten von Eigenschaftenber¨ucksichtigt werden kann [364] Dabei werden Operatoren verwendet, um anzu-zeigen, ob beispielsweise eine Eigenschaft irgendwann oder immer in der Zukunftgilt

Neben der Entscheidbarkeit von Problemen stellt sich die Frage nach der zienz, mit der Verifikationsprobleme l¨osbar sind Diese Frage untersuchte StephenCook in seinem 1971 ver¨offentlichten Werk [116] Auf seinen ¨Uberlegungen basiert

Effi-die sog Komplexit¨atstheorie Es stellte sich heraus, dass einige Probleme in

Polyno-mialzeit l¨osbar sind, d h die Laufzeit des Algorithmus zur L¨osung kann als Polynommit Abh¨angigkeit von den Eingabedaten des Problems abgesch¨atzt werden Proble-

me, die diese Eigenschaft besitzen, geh¨oren zur Komplexit¨atsklasseP Daneben gibt

es viele Probleme, f¨ur die ein solcher Zusammenhang nicht gefunden werden kann,sondern bei denen die Laufzeit vielmehr exponentiell in der Gr¨oße der Eingabedatenw¨achst F¨ur viele praktische Probleme jedoch gilt, dass, wenn erst mal eine L¨osunggefunden ist, diese in polynomieller Zeit auf ihre G¨ultigkeit ¨uberpr¨uft werden kann.Solche Probleme, werden alsN P-vollst¨andige Probleme (nichtdeterministisch poly- nomial) bezeichnet Cook beweist, dass das Boolesche Erf¨ullbarkeitsproblem (engl Satisfiability, SAT) N P-vollst¨andig ist Das Boolesche Erf¨ullbarkeitsproblem kann wie folgt formuliert werden: Gegeben sei eine aussagenlogische Formel Finde ei-

ne Zuweisung der Werte T und F an die atomaren Aussagen, so dass die Formel zu

wahr evaluiert Dabei wirft er die bis heute unbeantwortete Frage auf, ob die

Kom-plexit¨atsklassenP und N P ¨aquivalent sind (siehe Anhang C).

Nachdem die ersten Computer verf¨ugbar waren, entwickelte sich schnell die

neue Forschungsrichtung des automatischen Theorembeweisens Der erste

automa-tische Beweis durch eine Maschine gelang im Jahr 1954, wobei bewiesen wurde,dass die Summe zweier gerader Zahlen wieder gerade ist Im Laufe der Zeit wur-

den die Implementierungen der automatischen Beweistechniken immer weiter bessert Im Jahr 1962 publizierten Davis et al [128] eine neue Beweisprozedurzur L¨osung des Booleschen Erf¨ullbarkeitsproblems Es handelt sich hierbei um den

ver-DPLL-Algorithmus (nach deren Entwicklern Martin Davis, Hilary Putnam, George

Logemann und Donald W Loveland), der im Grunde noch heute in nahezu allen

Programmen zum L¨osen des Booleschen Erf¨ullbarkeitsproblems, sog SAT-Solvern,

implementiert wird

Mitte der 1990er Jahre gab es große Fortschritte in der Implementierung vonSAT-Solvern Daneben wurden diese Programme auch immer h¨aufiger erfolgreichmit anderen Theoriel¨osern kombiniert [392], mit dem Ziel, entscheidbare Variantender Pr¨adikatenlogik erster Ordnung auf Erf¨ullbarkeit zu pr¨ufen Dabei wird eine For-mel nicht hinsichtlich aller m¨oglichen Interpretationen auf Erf¨ullbarkeit ¨uberpr¨uft,

sondern lediglich bez¨uglich einer sog Hintergrundtheorie Deshalb spricht man auch h¨aufig von Erf¨ullbarkeit modulo Theorien (engl Satisfiability Modulo Theories, SMT) Untersuchte Theorien sind u a ¨Aquivalenz und uninterpretierte Funktionen,Lineare Arithmetik ¨uber reelle und ganze Zahlen, Divergenzlogik, Bitvektor-Theorieund Array-Theorie

Ein großes Interesse an der Anwendung des Theorembeweisens lag schon fr¨uh in

der Programmverifikation Die fr¨uhesten Arbeiten gehen auf Floyd [166] und Hoare [221] zur¨uck Das zentrale Element des Hoare-Kalk¨uls ist das sog Hoare-Tripel, das beschreibt, wie ein Programmteil P den Zustand einer Berechnung ver¨andert SeiΦ

eine Vorbedingung undΨ eine Nachbedingung Das Hoare-Tripel

{Φ}P{Ψ}

besagt, dass wenn die VorbedingungΦ gilt, dann das Programm P gestartet wird

und terminiert, so ist die NachbedingungΨerf¨ullt Besonders interessant in diesemZusammenhang ist die folgende Regel f¨ur while-Schleifen

Φ⇒ΦI,{ΦI∧C}P{ΦI},ΦI∧ ¬C ⇒Ψ

{Φ}while C do P end{Ψ} Hierbei stellt P den Schleifenrumpf und ¬C die Abbruchbedingung f¨ur die Schleife

dar.ΦIist die Schleifeninvariante, da diese vor der Ausf¨uhrung der Schleife als auch

nach deren Ausf¨uhrung gilt Ein großes Problem ist allerdings, dass die Bestimmungder Schleifeninvarianten oftmals nicht einfach m¨oglich ist Eine M¨oglichkeit hierzu

bilden Fixpunktalgorithmen.

Fixpunktalgorithmen spielen auch bei den Beweisverfahren f¨ur temporale sagenlogiken eine entscheidende Rolle Dabei wird die geforderte funktionale Eigen-schaft eines Systems mit Hilfe einer temporallogischen Formel ausgedr¨uckt F¨ur dasSystem selbst wird ein Modell ben¨otigt Aus diesem Grund werden die entsprechen-

Aus-den Beweisverfahren auch als Modellpr¨ufung bezeichnet Erste

Modellpr¨ufungs-ans¨atze sind in den fr¨uhen 1980er Jahren entstanden [369, 97, 304, 449]

Diese Modellpr¨ufungsverfahren basierten auf einer expliziten Aufz¨ahlung der reichbaren Zust¨ande F¨ur Systeme mit kleiner Anzahl an Zust¨anden, stellt dies keinProblem dar Allerdings f¨ur Systeme, wie sie in der Praxis vorkommen, sind diese

er-1.3 Eine kurze Geschichte der Verifikation 27Ans¨atze meist nicht praktikabel 1987 erkannte McMillan [74, 316], dass durch einesymbolische Repr¨asentation des Zustandsraums sehr viel gr¨oßere Systeme automa-tisch verifiziert werden k¨onnen Die symbolische Repr¨asentation basierte dabei auf

sog bin¨aren Entscheidungsdiagrammen (engl Binary Decision Diagrams, BDDs)

[62] Bin¨are Entscheidungsdiagramme sind Repr¨asentationen von Booleschen tionen und oftmals kompakter als andere Repr¨asentationen, etwa Funktionstabellen.Weiterhin existieren effiziente Algorithmen zu deren Manipulation Mit der symbo-lischen Modellpr¨ufung wurde es m¨oglich, Systeme mit mehr als 10120Zust¨anden

Funk-zu verifizieren [72, 73] Basierend auf den Ergebnissen der symbolischen

Modell-pr¨ufung entwickelten sich auch schnell neue Verfahren zur formalen ¨ pr¨ufung von Hardware [58].

Aquivalenz-All den formalen Ans¨atzen gemein ist allerdings, dass diese f¨ur reale Systemesehr viel Speicher ben¨otigen Gl¨ucklicherweise zeigten die 1990er Jahre, wie obenbeschrieben, enorme Fortschritte im Entwurf von SAT-Solvern 1999 stellten Biere et

al eine symbolische Modellpr¨ufung vor, die anstelle von BDDs SAT-Solver

verwen-det [48, 49] Die SAT-basierte Modellpr¨ufung f¨uhrt dabei zun¨achst keine

vollst¨andi-ge Verifikation durch, sondern betrachtet das Systeme lediglich ¨uber k Zeitschritte.

Hierdurch ist es nicht mehr direkt m¨oglich, zu zeigen, dass das System eine derte Eigenschaft erf¨ullt Statt dessen wird ein

gefor-”Fehlerfall“ gefunden, in dem dieEigenschaft nicht erf¨ullt wird

Mit der Verf¨ugbarkeit von Computern hat sich noch eine weitere Richtung von

Verifikationsverfahren entwickelt Diese Verfahren basieren auf der Simulation des

Systems Wie bei der SAT-basierten Modellpr¨ufung kann hierbei lediglich die senheit von Fehlern gezeigt werden, sofern ein Fehlerfall gefunden wird Um einensimulativen Beweis f¨ur Korrektheit zu f¨uhren, w¨are es notwendig, das System mitallen m¨oglichen Testfalleingaben zu stimulieren und die Systemantwort zu bewer-ten Dies ist bei heutigen Systemen kein realistischer Ansatz Dennoch haben sichsimulative Verifikationsans¨atze, insbesondere im industriellen Einsatz, etabliert EinGrund hierf¨ur liegt in der im Gegensatz zu formalen Methoden einfacheren Handha-bung F¨ur simulative Verifikationsverfahren werden die zu pr¨ufenden Eigenschaftendirekt im Quelltext des Programms formuliert In der Praxis hat sich gezeigt, dass

Anwe-das Einf¨ugen von Zusicherungen (engl assertions) direkt in den Quelltext w¨ahrend

des Programmierens sehr effizient und effektiv ist, um Fehler fr¨uhzeitig zu finden

Bereits eine der ersten Hochsprachen, die Sprache C [257], welche in den fr¨uhen

1970er Jahren entwickelt wurde, verf¨ugt daf¨ur ¨uber spezielle assert-Befehle Auchdie in den 1980er entwickelte Hardware-Beschreibungssprache VHDL [20, 233] hatbereits das Konzept von Zusicherungen aufgegriffen

Allerdings waren die in den sequenziellen Programmiersprachen entwickeltenZusicherungen nicht ausreichend, um zeitliche Zusammenh¨ange zwischen Annah-men und Zusicherungen zu formulieren Erst Anfang der 2000er Jahre wurdendie Prinzipien temporaler Logiken adaptiert und in Simulationsbibliotheken zurVerf¨ugung gestellt [234, 235] Als Ergebnis etablierte sich im industriellen Um-

feld eine simulative Modellpr¨ufung Durch die formale Spezifikation der

funktio-nalen Eigenschaften kann die simulative Modellpr¨ufung aber auch durch formale

Modellpr¨ufungsverfahren unterst¨utzt werden Dies wird als zusicherungsbasierte genschaftspr¨ufung (engl Assertion-Based Verification, ABV) bezeichnet.

Ei-Zur selben Zeit entstanden auch neue Programmiersprachen, welche die torientierung von sequentiellen Programmiersprachen und die Nebenl¨aufigkeit aus

Objek-Hardware-Beschreibungssprachen kombinierten Das Ergebnis sind sog schreibungssprachen, etwa SystemC [207, 236] oder SpecC [172] Insbesondere Sys-

Systembe-temC hat sich mittlerweile zu einem Defacto-Standard in der ausf¨uhrbaren tion von Hardware/Software-Systemen entwickelt Simulative Verifikationsans¨atze

Spezifika-f¨ur SystemC werden im Rahmen der SCV (engl SystemC Verification Library)

un-terst¨utzt [424] Dar¨uber hinaus definiert SystemC-TLM einen Standard zur

Beschrei-bung von sog Transaktionsebenenmodellen [352], welche zunehmend als

Struktur-modelle auf Systemebene Verwendung finden

Große Verbreitung hat SystemC-TLM im Bereich der simulativen Verifikationdes Zeitverhaltens Aufgrund der hohen Abstraktionsebene ist die Simulation deut-lich schneller als auf niedrigeren Abstraktionsebenen Da in SystemC aber die Mo-dellierung von Ressourcenbeschr¨ankungen m¨oglich ist, k¨onnen die simulierten Zei-ten dennoch recht exakt sein Simulative Ans¨atze im Bereich der Zeitanalyse ha-ben allerdings das selbe Problem wie simulative Ans¨atze zur funktionalen Eigen-schaftspr¨ufung: Sie k¨onnen nicht die Abwesenheit von Fehler beweisen In der Ve-rifikation des Zeitverhaltens bedeutet dies, dass das beste oder schlechteste Zeit-verhalten des Systems per Simulation nicht mit Sicherheit bestimmbar ist In denvergangenen zehn Jahren wurden aus diesem Grund neue formale Ans¨atze zur Veri-fikation des Zeitverhaltens entwickelt, die ganze Systeme, bestehend aus mehrerenProzessoren, ber¨ucksichtigen k¨onnen

Eine Zusammenfassung der wichtigen geschichtlichen Ereignisse im Bereich derVerifikation des vergangenen und dieses Jahrhunderts findet sich in Abb 1.16

1.4 Beispiele 29

1.4 Beispiele

Zum Abschluss dieses Kapitels werden einige Beispiele zu ¨Aquivalenzpr¨ufung wie funktionaler und nichtfunktionaler Eigenschaftspr¨ufung auf unterschiedlichenAbstraktionsebenen pr¨asentiert

so-Hardware- ¨ Aquivalenzpr ¨ufung

Die ¨Aquivalenzpr¨ufung f¨ur Hardware wird anhand eines Addierers skizziert

Hard-ware-Addierer lassen sich aus sog Volladdierern entwickeln Das Blockschaltbild

eines Volladdierer ist in Abb 1.17a) zu sehen Der Volladdierer hat drei Eing¨ange

c in , a, b und zwei Ausg¨ange s und c out, wobei alle diese Signale einzelne Bits sind,

d h c in ,a,b,s,c out ∈ {F,T}.

F F T T F T F T

F

T F T

F T

F T F

T

F

T

F F T T

F

T

F

T T T F F F

T

F

T

F T F T

Abb 1.17 a) Volladdierer und b) Funktionstabelle

Die Ausg¨ange lassen sich als Boolesche Funktionen der Eing¨ange beschreiben:

Die Gleichungen (1.1) und (1.2) sind Verhaltensmodelle auf der Logikebene

Ob das Strukturmodell der Implementierung (abstrahiert durch das Blockschaltbild

in Abb 1.17a)) die selben Funktionen implementiert, kann durch Simulation

ge-zeigt werden Die drei Eing¨ange c in , a und b k¨onnen je einen der WerteF oder T

annehmen Dies bedeutet, es gibt acht m¨ogliche Belegungen f¨ur die Eing¨ange desVolladdierers Legt man jede der m¨oglichen acht Belegungen nacheinander an dieEing¨ange des Volladdierers an, so erh¨alt man an den Ausg¨angen die Werte, die in derFunktionstabelle in Abb 1.17b) zu sehen sind

Um zu zeigen, dass die Ausgaben in Abb 1.17b) ¨aquivalent zu der zifikation in Gleichung (1.1) und (1.2) ist, m¨ussen entweder die Verhaltensmodelle

Verhaltensspe-in eVerhaltensspe-ine Funktionstabelle oder die Werte der Funktionstabelle Verhaltensspe-in eVerhaltensspe-ine schreibung umgewandelt werden Hier wird letztere M¨oglichkeit gezeigt.

Funktionsbe-Die Funktionstabelle in Abb 1.17b) l¨asst sich durch eine Boolesche Funktion in

disjunktiver Normalform darstellen Diese codiert die Einsstellen der entsprechenden Funktion F¨ur die beiden Funktionen s (cin ,a,b) und c out (cin ,a,b) ergibt sich:

s (cin ,a,b) = (¬a∧b∧¬c in)∨(a∧¬b∧¬cin)∨(¬a∧¬b∧cin)∨(a∧b∧cin) (1.3)

und

c out (cin ,a,b) = (a ∧ b ∧ ¬c in) ∨ (¬a ∧ b ∧ cin) ∨ (a ∧ ¬b ∧ cin) ∨ (a ∧ b ∧ cin) (1.4)

Nun muss noch die ¨Aquivalenz zwischen Gleichung (1.1) und Gleichung (1.3) sowiedie ¨Aquivalenz zwischen Gleichung (1.2) und Gleichung (1.4) gezeigt werden Hierwird lediglich die ¨Aquivalenz f¨ur die Berechnung der Summenbits gezeigt

Mit der Definition der Exklusiv-Oder-Funktion x1⊕x2:= (¬x1 ∧x2)∨(x1∨¬x2)

ergibt sich f¨ur Gleichung (1.1):

s (cin ,a,b) = (¬((¬a ∧ b) ∨ (a ∧ ¬b)) ∧ c in) ∨ (((¬a ∧ b) ∨ (a ∧ ¬b)) ∧ ¬cin) (1.5)

Gleichung (1.5) kann mittels der De Morganschen Gesetze ¬(x1∨ x2) = ¬x1∧ ¬x2

und¬(x1∧ x2) = ¬x1∨ ¬x2umgeformt werden:

s (cin ,a,b) = ((a ∨ ¬b) ∧ (¬a ∨ b) ∧ c in) ∨ (((¬a ∧ b) ∨ (a ∧ ¬b)) ∧ ¬cin) (1.6)

Durch Anwendung des Distributivgesetzes x1∧(x2∨x3) = (x1∧x2)∨(x1∧x3) kann

Gleichung (1.6) umgeformt werden zu:

s (cin ,a,b) = (a∧b∧c in)∨(¬a∧¬b∧cin)∨(¬a∧b∧¬cin)∨(a∧¬b∧¬cin) (1.7)

Durch Umsortieren der Terme erh¨alt man Gleichung (1.1) Somit ist die vom addierer implementierte Berechnung des Summenbits ¨aquivalent zur Spezifikation

Voll-Software-Eigenschaftspr ¨ufung

Betrachtet wird ein Software-System bestehend aus zwei Prozessen Da die Prozesseauf einem einzelnen Prozessor ausgef¨uhrt werden, gibt es beschr¨ankte Ressourcen,die nur exklusiv von einem Prozess belegt werden d¨urfen Um dies zu realisieren,

werden beispielsweise sog Semaphore verwendet Ein Prozess, der eine Ressource

exklusiv belegt, beansprucht zun¨achst das zugeh¨orige Semaphor Erh¨alt der Prozessdas beanspruchte Semaphor nicht, so muss dieser warten und kann die Ressourcenicht belegen Erh¨alt der Prozess das Semaphor, so kann er die Ressource belegen.Man sagt, er betritt den kritischen Bereich Nach Verlassen des kritischen Bereichsmuss der Prozess das Semaphor wieder freigeben Ein Zustandsmodell f¨ur einenausf¨uhrungsbereiten Prozess ist in Abb 1.18a) dargestellt

Ein ausf¨uhrungsbereiter Prozess startet im Zustand N Sobald dieser einen schen Bereich (Zustand K) betreten m¨ochte, muss er zun¨achst das zugeh¨orige Sema- phor anfordern (s?) und in den Wartezustand W ¨ubergehen Den kritischen Bereich

kriti-1.4 Beispiele 31b)

Zu-F¨ur die funktionale Eigenschaftspr¨ufung m¨ussen neben dem System selbst auchdie zu ¨uberpr¨ufenden Eigenschaften formuliert werden Eine wichtige Eigenschaftf¨ur das oben beschriebene Software-System ist beispielsweise, dass sich niemalszwei Prozesse gleichzeitig im kritischen Bereich befinden Um solche Eigenschaf-ten automatisiert ¨uberpr¨ufen zu k¨onnen, reicht es allerdings nicht, die Eigenschaftumgangssprachlich auszudr¨ucken Vielmehr ist es notwendig, die Eigenschaft for-

mal zu beschreiben Wenn z B K1und K2die kritischen Bereiche zweier Prozessedarstellen, so k¨onnte ein erster Versuch, obige Eigenschaft zu formalisieren, auf Ba-sis der Aussagenlogik erfolgen, d h als Formel¬(K1∧ K2) Die Aussagenlogik ist

allerdings nicht ausreichend expressiv, um auszudr¨ucken, wann diese Eigenschaftgelten soll So k¨onnte es unterschiedliche Interpretationen geben, wie z B.:

”DieseEigenschaft gilt irgendwann“ oder

”Es ist m¨oglich, dass die Eigenschaft irgendwanngilt“

Um diese Mehrdeutigkeit aufzul¨osen, kann beispielsweise die temporale genlogik zum Einsatz kommen In dieser kann spezifiziert werden, dass die Aussage

Aussa-¬(K1∧ K2) zu jedem Berechnungszeitpunkt (G) und f¨ur jede

Ausf¨uhrungsreihenfol-ge (A) der beiden Prozesse gilt Die obiAusf¨uhrungsreihenfol-ge EiAusf¨uhrungsreihenfol-genschaft l¨asst sich somit als

formulieren

Ein weiteres Beispiel f¨ur eine Eigenschaft w¨are:

”Eine Anfrage, den kritischenBereich zu betreten, wird irgendwann erf¨ullt“ Auch hier ist wiederum die Aussa-genlogik nicht m¨achtig genug, um zeitliche und modale Effekte auszudr¨ucken Dieentsprechende temporallogische Formel lautet:

Diese besagt, dass auf allen Berechnungspfaden (A) und zu einem beliebigen

Be-rechnungszeitpunkt in der Zukunft (F), nachdem Prozess 1 den Wartezustand W1

ein-genommen hat, dieser auch in den kritischen Bereich K1wechseln kann Weiterhinmuss diese Bedingung zu jedem Berechnungszeitpunkt (G) und f¨ur alle beliebigenAusf¨uhrungsreihenfolgen (A) der Prozesse gelten

Die ¨Uberpr¨ufung der Eigenschaften (1.8) und (1.9) kann beispielsweise erfolgen,

in dem alle m¨oglichen Ausf¨uhrungsreihenfolgen der Prozesse betrachtet werden F¨ur

zwei Prozesse ist dies in Abb 1.18b) dargestellt Im Anfangszustand N1N2sind beideProzesse ausf¨uhrungsbereit Jeder der beiden Prozesse kann nun das einzige Sema-phor im System anfordern, wenn er ausgef¨uhrt wird Hierdurch sind zwei m¨ogliche

Folgezust¨ande denkbar, d h W1N2oder N1W2 Fordert nun der andere Prozess

eben-falls das Semaphor an, so resultiert dies im Zustand W1W2 Alternativ kann der weils wartende Prozess den kritischen Bereich betreten Die beiden Folgezust¨ande

je-lauten in diesem Fall K1N2und N1K2

Ohne die weiteren m¨oglichen Zust¨ande in Abb 1.18b) n¨aher zu beschreiben, sei

hier festgestellt, dass ein Zustand K1K2, in dem beide Prozesse im kritischen Bereichsind, nicht erreicht wird Hierf¨ur sorgt das Betriebssystem, welches ein Semaphorimmer nur exklusiv vergibt und somit den jeweils anderen Prozess am Eintritt in denkritischen Bereich hindert Somit ist auch offensichtlich, dass die Eigenschaft (1.8)f¨ur dieses System erf¨ullt ist

Weiterhin kann man durch genaues ¨Uberlegen erkennen, dass die Eigenschaft

(1.9) nicht erf¨ullt ist Die unendliche Wiederholung des Zyklus W1N2→ W1W2→

W1K2→ W1N2repr¨asentiert eine g¨ultige Ausf¨uhrungsreihenfolge und stellt somit einGegenbeispiel dar, in dem der wartende Prozess 1 niemals den kritischen Bereichbetritt Dies liegt an der unfairen Ablaufplanung der Prozesse, die den Prozess 1

”verhungern“ l¨asst.

An diesem kleinen Software-System sieht man bereits, wie schwierig es seinkann, die geforderten Eigenschaften korrekt zu formulieren und dass es nicht im-mer trivial sein muss, zu entscheiden, ob eine Eigenschaft erf¨ullt ist oder nicht.Ein wesentlicher Grund f¨ur diese Schwierigkeit liegt auch in der Gr¨oße der Sys-teme begr¨undet, die heutzutage betrachtet werden Eine Modellierung m¨oglicherAusf¨uhrungsreihenfolgen mit Systemzust¨anden, wie in Abb 1.18b), w¨urde schonbei vier und mehr Prozessen nicht mehr auf einer Seite darstellbar sein Bei heutzu-tage typischen Systemen mit mehreren hundert Prozessen f¨uhrt dies zwangsl¨aufig in

das sog Zustandsexplosionsproblem (engl state explosion), was auch die

Automati-sierung vieler Ans¨atze f¨ur solche Systeme verhindert

1.4 Beispiele 33

Pr ¨ufung nichtfunktionaler Systemeigenschaften

Neben der Pr¨ufung funktionaler Eigenschaften ist die ¨Uberpr¨ufung nichtfunktionalerEigenschaften eingebetteter Systeme ein wichtiges Thema Hier spielt insbesonderedie ¨Uberpr¨ufung des Zeitverhaltens eine entscheidende Rolle Die Komplexit¨at die-ses Problems wird anhand eines Beispiels auf Systemebene aus [435] beschrieben.Gegeben sei die Architektur und die Prozessbindung aus Abb 1.19a) Ein Sen-

sor sendet periodisch Daten an die CPU Der Prozess p1, der auf der CPU ausgef¨uhrtwird, ist daf¨ur verantwortlich, die Sensordaten in den lokalen Speicher zu speichern

Ein zweiter Prozess p2verarbeitet diese Daten und versendet sie ¨uber den

gemein-samen Bus an eine I/O-Einheit Die Ausf¨uhrungszeit des Prozesses p2variiert

zwi-schen der schnellsten Ausf¨uhrungszeit d BC und langsamsten Ausf¨uhrungszeit d WC

Auf der I/O-Einheit nimmt Prozess p3die Daten zur Weiterverarbeitung entgegen

In diesem Beispiel wird angenommen, dass auf der CPU ein Betriebssystem miteiner priorit¨atsbasierten, pr¨aemptiven Ablaufplanung unter Verwendung statischer

Priorit¨aten l¨auft Dabei hat Prozess p1eine h¨ohere Priorit¨at als der Prozess p2 Die

maximale Auslastung der CPU ergibt sich f¨ur den Fall, dass Prozess p2bei der

Be-arbeitung stets die l¨angste Ausf¨uhrungszeit ben¨otigt, d h d WC

t dWC

Abb 1.19 Interferenz zweier Anwendungen auf einem gemeinsam genutzten Bus [435]

Neben der oben beschriebenen Anwendung gibt es eine weitere Anwendung, die

in Abb 1.19a) dargestellt ist Diese Anwendungen erh¨alt ¨uber das Interface Input

periodisch Echtzeitdaten, welche durch den Prozess p4 ¨uber den gemeinsamen Bus

an den Prozess p5, der auf dem Digitalen Signal Prozessor (DSP) im System l¨auft,

sendet Der Prozess p speichert die Daten im lokalen Speicher des DSP Aus diesem

Speicher liest der Prozess p6die Daten periodisch wieder aus und gibt sie an eineweitere lokale Komponente, z B die Audiowiedergabeeinheit.

Im Folgenden wird angenommen, dass auf dem Bus eine First Come, First ved-Arbitrierung verwendet wird Unter dieser Annahme sieht man, dass die Da- ten¨ubertragung von Prozess p2zu Prozess p3 mit der ¨Ubertragung der Daten zwi-

Ser-schen Prozess p4 und p5 interferiert Interessant hierbei ist der Aspekt, dass eine

Ausf¨uhrung des Prozesses p2mit der schnellsten Ausf¨uhrungszeit d BCzu einer

ho-hen Buslast, eine Ausf¨uhrung mit der langsamsten Ausf¨uhrungszeit d WC zu einergeringen Buslast f¨uhrt (siehe Abb 1.19b)) Somit geht eine hohe Auslastung derCPU mit einer geringen Buslast einher, sowie eine geringe CPU-Auslastung mit ei-ner hohen Buslast Entscheidend ist allerdings, dass diese Varianz in der Buslastdazu f¨uhren kann, dass es im lokalen Speicher des DSP zu Unter- bzw ¨Uberl¨aufenkommen kann Allein durch die Verwendung des gemeinsamen Busses ist das Zeit-verhalten der beiden ansonsten unabh¨angigen Anwendungen voneinander abh¨angiggeworden

1.5 Ausblick

Basierend auf den in diesem Kapitel eingef¨uhrten Verifikationsaufgaben werden imFolgenden Ans¨atze zur Verifikation von digitalen Hardware/Software-Systemen vor-gestellt Zun¨achst werden modellbasierte Ans¨atze beschrieben Die zugrundeliegen-den Modelle sind dabei Teil der Spezifikation, weshalb in Kapitel 2 M¨oglichkeitenzur formalen oder ausf¨uhrbaren Spezifikation pr¨asentiert werden Kapitel 3 gibt einedetaillierte Klassifikation von Verifikationsans¨atzen nach Verifikationsaufgabe, Veri-fikationsmethode und Verifikationsziel

Bei den modellbasierten Ans¨atzen werden zun¨achst Verfahren zur ¨pr¨ufung vorgestellt (Kapitel 4) Obwohl diese nur eine Spezialform der allgemei-neren Eigenschaftspr¨ufung (Kapitel 5) darstellen, eignen sie sich besonders gut zurEinf¨uhrung in die Verifikationsproblematik Die in diesem Buch vorgestellten mo-dellbasierten Verfahren lassen sich sowohl zur Verifikation von Hardware- als auchvon Software-Komponenten einsetzen Hierbei muss man allerdings die notwendi-

Aquivalenz-ge Abstraktion kritisch betrachten Mit anderen Worten: Es eignen sich nicht allemodellbasierten Verfahren gleich gut zur Verifikation von Hardware und Software

Im Anschluss an die Einf¨uhrung in modellbasierte Verifikationsans¨atze werdenspezielle Verfahren zur Hardware-Verifikation (Kapitel 6), zur Software-Verifikation(Kapitel 7) und Systemverifikation (Kapitel 8) vorgestellt Anhang A bis C enth¨altgrundlegende Definitionen, Datenstrukturen und Algorithmen

1.6 Literaturhinweise

Das Doppeldachmodell sowie der Entwurfsprozess f¨ur digitale

Hardware/Software-Systeme ist ausf¨uhrlich in [426] beschrieben Neben dem Doppeldachmodell gibt esweitere Modelle, die den Entwurf von eingebetteten Systemen beschreiben So kann