Digitale Hardware/ Software-Systeme- P2 pptx

Hierbei wird eine Spezifikation im Entwurf in eine Implementierung trans-formiert.. Ein wesentlicher Aspekt ist, dass die Spezifikation meistens in einer Form vorliegt, die nicht direkt

reicher und heterogener werden Die Schwierigkeit besteht in der Verzahnung funk-tionaler und nichtfunkfunk-tionaler Eigenschaften, in der sich auch die Durchmischung der Komplexit¨aten von Anwendung und Implementierung widerspiegelt So ist es nicht verwunderlich, dass ein großer Teil des Aufwands einer Produktentwicklung in die Verifikation fließt Eine detaillierte Fallstudie [156] zeigt, dass der Verifikations-aufwand den EntwurfsVerifikations-aufwand sogar ¨ubersteigt Dennoch l¨asst es die Komplexit¨at heutiger Systeme nicht zu, dass diese nach dem heutigen Stand der Technik nach wirtschaftlichen Aspekten fehlerfrei entwickelt werden k¨onnen

Dies wird im Entwurfsdreieck in Abb 1.5 dargestellt Mit jeder Ecke des

Drei-ecks ist ein Qualit¨atsmaß assoziiert, namentlich Qualit¨at, Kosten und Zeit, wobei Qualit¨at f¨ur die Produktqualit¨at, Zeit f¨ur die Zeit bis zur Markteinf¨uhrung und Kos-ten f¨ur die EntwicklungskosKos-ten stehen sollen Bei einer Produktplanung kann man die Vorstellungen f¨ur dieses Produkt in das Entwurfsdreieck eintragen, wobei ein Qualit¨atsmaß als um so besser gilt, je n¨aher der Punkt an der entsprechenden Ecke steht Das Entwurfsdreieck zeigt graphisch die Abh¨angigkeiten der drei Qualit¨ats-maße: Es ist nicht m¨oglich, ein Produkt mit h¨ochster Produktqualit¨at zu geringsten Entwicklungskosten in k¨urzester Zeit auf den Markt zu bringen Es ist aber z B m¨oglich, ein Produkt m¨oglichst kosteng¨unstig zu entwickeln Dies geht dann aber zu Lasten der Qualit¨at und der Zeit bis zur Markteinf¨uhrung

Kosten

Zeit

×

×

qualitativ hochwertige,

zeit- und kostenintensive zu einem hohen Preis

Qualit¨at

zu Lasten der Qalit¨at schnelle Markteinf¨uhrung

L¨osung

Abb 1.5 Entwurfsdreieck

Verifikation ist ein qualit¨atssteigernder Prozess in der Entwicklung eingebetteter Systeme Mit dem Wissen ¨uber das Entwurfsdreieck muss man allerdings immer wieder kritisch hinterfragen, ob die gew¨unschte Qualit¨at erreicht ist, bzw wie viel Verifikation noch n¨otig und wirtschaftlich vertretbar ist Dabei darf man allerdings nie aus den Augen verlieren, dass ein Fehlverhalten oder Ausfall im Betrieb enorme Kosten nach sich ziehen und sogar einen Reputationsverlust f¨ur das Unternehmens bedeuten kann

1.2 Der Verifikationsprozess

Verifikation ist der Prozess, die Fehlerfreiheit einer Implementierung bez¨uglich der Spezifikation zu zeigen Mit anderen Worten: Es soll ¨uberpr¨uft werden, ob ein Entwurfs- oder Syntheseschritt das korrekte Ergebnis liefert Dies wird durch das

sog Rekonvergenzmodell (engl reconvergence model) [41] in Abb 1.6 ausgedr¨uckt.

Das Rekonvergenzmodell ist eine konzeptionelle Darstellung des Verifikationspro-zesses Hierbei wird eine Spezifikation im Entwurf in eine Implementierung trans-formiert Die Korrektheit des Ergebnisses wird in der Verifikation ¨uberpr¨uft

Entwurf

Verifikation

Abb 1.6 Das Rekonvergenzmodell [41]

Der in Abb 1.6 gezeigte Ablauf ist allerdings stark vereinfacht dargestellt Ein wesentlicher Aspekt ist, dass die Spezifikation meistens in einer Form vorliegt, die nicht direkt in eine Implementierung transformierbar ist Dies bedeutet, dass ein Ent-wickler zun¨achst die Spezifikation aufbereiten muss, bevor Entwurfsentscheidungen getroffen werden k¨onnen Genau diese Aufbereitung verlangt aber, dass die Spezi-fikation interpretiert wird Dies liegt unter anderem daran, dass SpeziSpezi-fikationen oft-mals unvollst¨andig, mehrdeutig oder sogar widerspr¨uchlich sind Die Erweiterung des Rekonvergenzmodells um diesen Aspekt ist in Abb 1.7 dargestellt

Einen Schwachpunkt kann man allerdings sofort in Abb 1.7 erkennen: Ist es bei der Interpretation der Spezifikation notwendig, Unvollst¨andigkeiten, Mehrdeu-tigkeiten oder Widerspr¨uche aufzul¨osen, und werden diese Modifikationen nicht in der Spezifikation festgehalten, so wird die Implementierung sp¨ater nicht gegen die Spezifikation, sondern gegen die Interpretation der Spezifikation verifiziert Die In-terpretation existiert dabei nur als Bild der Spezifikation im Kopf des Entwicklers Ist die Interpretation selbst fehlerhaft, kann dies nicht durch Verifikation erkannt wer-den

Um diesen Sachverhalt aufzul¨osen, sollte die Implementierung stets gegen die Spezifikation gepr¨uft werden Hier zeigt sich aber ein zweites Problem: Wie beim Entwurf ist die Spezifikation oftmals nicht f¨ur einen direkten Einsatz im Verifikati-onsprozess einsetzbar Dies bedeutet, dass ebenfalls eine Interpretation der Spezifika-tion f¨ur die VerifikaSpezifika-tion notwendig wird Um dem Fall zu begegnen, dass fehlerhafte

Bild der Spezifikation

Implementierung Entwurf

Interpretation

Verifikation

Abb 1.7 Interpretation und Rekonvergenzmodell

Interpretationen die Qualit¨at eines Entwurfs mindern, sollte deshalb nach M¨oglich-keit stets darauf geachtet werden, dass ein nicht am Entwurf beteiligter Entwickler die Verifikation ¨ubernimmt Somit ist wahrscheinlich, dass immer zwei Bilder der Spezifikation durch Interpretation entstehen Damit wird auch die Wahrscheinlich-keit gemindert, dass beide Bilder die selben Fehler enthalten Dies ist in Abb 1.8 dargestellt

Bild der

Spezifikation

Verifikation

Entwurf

Bild der Spezifikation

Abb 1.8 Getrennte Interpretation zum Entwurf und zur Verifikation

1.2.1 Das V-Modell

Das Rekonvergenzmodell (siehe Abb 1.6) stellt sowohl den Entwurf als auch die Verifikation jeweils als einen einzelnen Schritt dar Dies ist f¨ur heutige Systeme nicht realistisch Die Komplexit¨at heutiger digitaler Hardware/Software-Systeme verlangt, dass man einen hierarchischen Entwurfsprozess einsetzt Dies bedeutet, dass man, etwa nach einem Divide&Conquer-Ansatz, die Systemkomplexit¨at zerlegt und den Entwurf somit auf verschiedenen Abstraktionsebenen durchf¨uhrt (siehe auch [426])

Diesem Aspekt wird durch das V-Modell Rechnung getragen (siehe Abb 1.9).

entwurf

System- Komponenten-entwurf

Komponenten- System-verifikation

verifikation Implementierung

Zeit

Abb 1.9 Das V-Modell

Das V-Modell tr¨agt seinen Namen aufgrund seiner Darstellung als

” V“-f¨ormi-ges Diagramm Die linke Seite des V entspricht dem Entwurfsprozess Entsprechend beschreibt die rechte Seite den Verifikationsprozess Der Ber¨uhrungspunkt der

bei-den Prozesse ist die Implementierung Die Entwurfsphase startet oben links mit der

Analyse der Anforderungen Diese werden in dem Systementwurf umgesetzt Dabei erfolgt auch die Aufteilung in Hardware- und Software-Komponenten Diese wer-den im Komponentenentwurf entwickelt Damit endet der Entwurf und es folgt die Implementierung Die Verifikationsphase beginnt unten auf der anderen Seite des V mit der Verifikation der einzelnen Komponenten Dieser Schritt ist gefolgt von der Systemverifikation und der anschließenden Inbetriebnahme

In einem fehlerfreien Entwurf schreitet die Zeit von links nach recht fort und es wird zun¨achst die eine Seite des V herabgestiegen und anschließend die andere Seite wieder heraufgestiegen Das Ab- und Aufsteigen entspricht dabei den Wechsel der Abstraktionsebenen In der Entwurfsphase wird die Implementierung immer detail-lierter In der Verifikation abstrahiert man von bereits verifizierten Komponenten

In einem realen Systementwurf wird man aber die Abstraktionsebenen hin- und herspringen, da z B bereits Teile der Implementierung auf niedrigen Abstrakti-onsebenen vorliegen Daneben wird auch zwischen den Seiten des V gesprungen Wird beispielsweise in der Komponentenverifikation ein Fehler aufgedeckt, wird

man nicht zur Systemverifikation ¨ubergehen, sondern zun¨achst die fehlerhafte Kom-ponente korrigieren

Das V-Modell gibt es in verschiedensten Versionen mit unterschiedlich vie-len Abstraktionsebenen Dementsprechend gibt es auch spezialisierte Varianten f¨ur den Hardware-Entwurf oder f¨ur den Software-Entwurf Dies stellt zugleich einen großen Nachteil des V-Modells heraus: Es gibt keine Varianten, die gleichzeitig zwischen dem Hardware- und dem Software-Entwurf und deren Verifikationspha-sen und Interaktionen unterscheiden k¨onnen Aus diesem Grund werden im folgen-den Abschnitt Modelle f¨ur folgen-den Entwurfs- und folgen-den Verifikationsprozess von digitalen Hardware/Software-Systemen vorgestellt

1.2.2 Das Doppeldachmodell des Entwurfsprozesses

Die Verifikation eines Systems beschreibt die ¨Uberpr¨ufung der korrekten Implemen-tierung einer Spezifikation Um den Verifikationsprozess zu verstehen, ist es not-wendig, zun¨achst den Entwurfsprozess detaillierter zu betrachten Da

eingebette-te Syseingebette-teme h¨aufig aus ineingebette-teragierenden Hardware- und Software-Komponeneingebette-ten be-stehen, muss der Entwurf beider Bestandteile sowie die Interaktion zwischen die-sen im Entwurfsprozess ber¨ucksichtigt werden Der idealisierte Entwurf f¨ur

digi-tale Hardware/Software-Systeme ist in Abb 1.10 als Doppeldachmodell dargestellt

[425, 426]

System

Logik

Implementierung

Spezifikation

Architektur Modul

Block

Abb 1.10 Doppeldachmodell f¨ur den Entwurf von digitalen Hardware/Software-Systemen

Die linke Seite des Daches entspricht dem Software-Entwurfsprozess, w¨ahrend die rechte Seite dem Hardware-Entwurfsprozess zugeordnet ist Jede Seite ist dabei

in unterschiedliche Abstraktionsebenen organisiert F¨ur den Software-Entwurfspro-zess sind h¨aufig die Block- und Modulebene von Interesse Im Hardware-Entwurfs-prozess findet man im Allgemeinen die Logik- und Architekturebene In der Mitte des

Doppeldachmodells findet man eine gemeinsame Abstraktionsebene, die sog Syste-mebene (engl Electronic System Level, ESL) Auf dieser Abstraktionsebene wird

nicht zwischen Hardware und Software unterschieden

Auf jeder Abstraktionsebene wird durch einen Syntheseschritt eine Spezifikation

in eine Implementierung transformiert Der Syntheseschritt wird auf jeder

Abstrakti-onsebene als vertikaler Pfeil im Doppeldachmodell dargestellt Im Rekonvergenzmo-dell aus Abb 1.6 waren alle diese Schritte zu einem Schritt (Entwurf) zusammen ge-fasst Horizontale Pfeile beschreiben die Wiederverwendung individueller Elemente einer Implementierung als Spezifikation auf der n¨achst tieferen Abstraktionsebene Der durch das Doppeldachmodell beschriebene Entwurfsprozess beginnt typi-scherweise auf der Systemebene Hier besteht die Spezifikation beispielsweise aus einem Prozessgraphen, der das gew¨unschte Verhalten des Systems als ¨uber Kan¨ale kommunizierende Prozesse beschreibt Daneben gibt es meistens eine Menge an Abbildungs- und Implementierungsbeschr¨ankungen in der Form von maximalen Fl¨achenanforderungen, minimale zu erreichendem Durchsatz etc Die Implementie-rung auf der Systemebene wird auch als Hardware/Software-Architektur bezeich-net und wird in Form von strukturellen Modellen bestehend aus Prozessoren, Bus-sen, Speichern, Hardware-Beschleunigern und Klassendiagrammen beschrieben Die

Aufgabe der Systemsynthese besteht darin, eine geeignete

Implementierungsplatt-form auszuw¨ahlen, Prozesse und Kan¨ale auf diese PlattImplementierungsplatt-form abzubilden und eine zeitliche Ordnung der Abarbeitung der Prozesse und der Kommunikation zu bestim-men Hierdurch entsteht ein verfeinertes Modell, welches alle Entwurfsentscheidun-gen, die auf dieser Ebene getroffen wurden, beinhaltet Die einzelnen Komponenten dieses verfeinerten Modells dienen anschließend als Eingabe f¨ur den Entwurfspro-zess auf der n¨achst tieferen Abstraktionsebene

Die Synthese auf tieferen Abstraktionsebenen ¨ahnelt der Systemsynthese dahin-gehend, dass stets ein Verhaltensmodell in eine strukturelle Implementierung trans-formiert wird [426] Dabei unterscheidet sich allerdings die Granularit¨at der

betrach-teten Objekte Auf der Modulebene werden typischerweise Prozesse, die auf den

selben Prozessor abgebildet sind, zeitlich geplant Dies geschieht h¨aufig unter

Zu-hilfenahme eines Betriebssystems Auf der Blockebene m¨ussen Prozesse auf den Instruktionssatz des Prozessors (engl Instruction Set Architecture, ISA) abgebildet

werden Hierf¨ur werden in der Regel Compiler und Linker eingesetzt

Auf Architekturebene im Hardware-Entwurf werden Prozesse, welche als Hard-ware-Beschleuniger implementiert werden, in Beschreibungen auf der Registertrans-ferebene (engl Register Transfer Level, RTL) synthetisiert RTL-Beschreibungen

bestehen aus einem Controller zur Steuerung eines Datenpfads, der wiederum aus Funktionseinheiten, Registern und Verbindungen besteht Dieser Syntheseschritt

wird als Verhaltenssynthese (engl behavioral synthesis bzw high-level synthesis) oder Architektursynthese bezeichnet Auf Logikebene werden Boolesche Funktionen oder Automatenmodelle durch Gatter und Flip-Flops implementiert.

Es sei angemerkt, dass der im Doppeldachmodell angedeutete Top-Down-Ent-wurfsprozess auf Systemebene auf der Verf¨ugbarkeit von EntTop-Down-Ent-wurfsprozessen auf Modul- und Architekturebene basiert Dies heißt, dass tiefere Abstraktionsebenen

einen Zugang zum Entwurfsprozess, entweder durch ein Syntheseverfahren oder

durch vordefinierte Module (engl IP modules), bieten muss.

Synthese

Zentral f¨ur den Entwurfsprozess ist die Synthese Die Synthese transformiert eine Spezifikation in eine Implementierung Dies geschieht auf verschiedenen Abstrak-tionsebenen, was der heutigen Systemkomplexit¨at Rechnung tr¨agt Dabei wird auf jeder Abstraktionsebene eine Verhaltensbeschreibung, die Teil der Spezifikation ist,

in eine Strukturbeschreibung transformiert (siehe Abb 1.11)

Spezifikation

f

Implementierung

Synthese

f1

f2

f3

Abb 1.11 Die Synthese transformiert eine Verhaltensbeschreibung, die Teil der Spezifikation

ist, in eine Strukturbeschreibung

In Abb 1.11 ist das Verhalten der Spezifikation durch die Funktion f beschrie-ben Die Funktion y : = f (x) transformiert den Eingang x in den Ausgang y Um hieraus eine Strukturbeschreibung zu erzeugen, muss zun¨achst die Funktion f in Teilfunktionen, hier f1, f2 und f3, zerlegt werden Damit die resultierende Imple-mentierung aber das in der Spezifikation vorgegebene Verhalten implementiert, muss zus¨atzlich angegeben werden, wie die Teilfunktionen zusammenarbeiten, d h

deren Zusammenwirken Da die Teilfunktionen f1, f2, f3selbst wieder Verhaltensbe-schreibungen sind, k¨onnen diese gegebenenfalls in weitere Strukturmodelle verfei-nert werden

Neben der Transformation der Verhaltensbeschreibung in eine Strukturbeschrei-bung spielt bei der Synthese aber auch die Einhaltung der Anforderungen an das System eine zentrale Rolle Die abstrakte Sicht auf den Syntheseschritt kann mit

Hilfe des X-Diagramms verfeinert werden (Abb 1.12) Eine Spezifikation besteht aus einem Verhaltensmodell und Anforderungen Das Verhaltensmodell beschreibt

die geforderte Funktionalit¨at des Systems Seine Expressivit¨at und Analysierbarkeit

wird als Berechnungsmodell (engl Model of Computation, MoC) angegeben [298].

Verhaltensmodelle werden h¨aufig in Programmiersprachen, wie C/C++ oder Java, Hardware-Beschreibungssprachen, wie SystemVerilog oder VHDL, oder Systembe-schreibungssprachen, wie beispielsweise SystemC oder SpecC, geschrieben

Entwurfsent-scheidungen &

Verfeinerung

Qualit¨ats-merkmale

a)

Synthese Spezifikation

Implementierung

Abb 1.12 X-Diagramm der Synthese

Die Anforderungen (engl requirements) umfassen oftmals implizit oder explizit ein Plattformmodell, welches die Vielfalt m¨oglicher struktureller Implementierungen

einschr¨ankt, etwa durch Vorgabe verf¨ugbarer Ressourcen, deren Dienste und deren Verbindungen Beispiele hierf¨ur sind verf¨ugbare Prozessoren mit deren Instruktions-satz, Speicher und Prozessorbusse Auf Systemebene sind typische

Plattformmodel-le beispielsweise Einprozessorsysteme, Hardware/Software-Prozessor/Coprozessor-Systeme, homogene, symmetrische oder heterogene, asymmetrische Multiprozessor-systeme [466] Neben dem Plattformmodell existieren in den Anforderungen dar¨uber hinaus oftmals Abbildungsbeschr¨ankungen f¨ur Teile des Verhaltensmodells sowie zus¨atzliche Anforderungen an nichtfunktionale Eigenschaften, wie maximale Ant-wortzeit, minimaler Durchsatz, maximale Leistungsaufnahme etc

Eine Implementierung besteht aus einem Strukturmodell sowie einer Menge von Qualit¨atsmerkmalen Das Strukturmodell ist ein verfeinertes Modell des

Verhaltens-modells unter Ber¨ucksichtigung der Anforderungen aus der Spezifikation Zus¨atzlich

zu implementierungsunabh¨angigen Informationen im Verhaltensmodell enth¨alt das Strukturmodell Informationen ¨uber die Umsetzung von Entwurfsentscheidungen aus dem vorhergegangenen Syntheseschritt Ein Beispiel hierf¨ur ist die Abbildung des Verhaltensmodells auf Elemente des Plattformmodells

Qualit¨atsmerkmale sind gesch¨atzte Eigenschaften einer Implementierung und werden in einem geeigneten Qualit¨atsmaß quantifiziert, z B Antwortzeit,

Durch-satz, Latenz, Fl¨achen- oder Leistungsbedarf Qualit¨atsmerkmale quantifizieren funk-tionale oder nichtfunkfunk-tionale Eigenschaften eines Systems Zur Absch¨atzung dienen

entweder das Strukturmodell oder geeignete Bewertungsmodelle, die, je nach

Ab-straktionsebene und Umsetzung, unterschiedlich gute Absch¨atzungen liefern Bei-spiele f¨ur Bewertungsmodelle f¨ur zeitliche Qualit¨atsmaße sind Instruktionssatz- oder Hardware-Simulationsmodelle

Die Synthese transformiert eine Spezifikation in eine Implementierung Die zen-tralen Aufgaben dabei sind das Treffen von Entwurfsentscheidungen und die Verfei-nerung eines Verhaltensmodells in ein Strukturmodell (Abb 1.12) Auf jeder

Ab-straktionsebene f¨uhrt die Synthese dabei eine Abbildung der Elemente im Verhal-tensmodell in Raum und Zeit durch Das Treffen von Entwurfsentscheidungen ist

somit die Allokation von Ressourcen aus dem Plattformmodell, die (r¨aumliche) Bin-dung von Elemente des Verhaltensmodells und deren (zeitliche) Ablaufplanung, um Ressourcenkonflikte aufzul¨osen Verfeinerung ist der Prozess, die

Entwurfsentschei-dungen in das Verhaltensmodell zu integrieren Das Ergebnis ist ein Strukturmodell

der Implementierung Daneben k¨onnen mit den Entwurfsentscheidungen die Qua-lit¨atsmerkmale abgesch¨atzt werden.

Da die Menge m¨oglicher Entwurfsentscheidungen typischerweise sehr groß sein

kann, wird h¨aufig als Teil der Synthese eine Entwurfsraumexploration zur

Be-stimmung optimaler (oder nahezu optimaler) Implementierungen durchgef¨uhrt Die

Entwurfsraumexploration ist ein Mehrzieloptimierungsproblem, welches in der Re-gel nicht nur eine einzelne, sondern eine Menge sog Pareto-optimaler L¨osungen

bestimmt Somit kann die Entwurfsraumexploration als Mehrzieloptimierungspro-blem der Synthese bez¨ugliche der zu optimierenden Qualit¨atsmaße aufgefasst wer-den Die Aufgaben und Methoden zum Entwurf und zur Optimierung digitaler Hardware/Software-Systeme sind ausf¨uhrlich in [426] dargestellt

1.2.3 Das Doppeldachmodell des Verifikationsprozesses

Wie im Entwurfsprozess digitaler Hardware/Software-Systeme, muss auch im Ve-rifikationsprozess die Verifikation von Hardware, von Software und von Systemen unterst¨utzt werden Außerdem muss auf jeder Abstraktionsebene verifiziert werden,

d h es muss ¨uberpr¨uft werden, ob die jeweilige Spezifikation korrekt in eine

Imple-mentierung umgesetzt wurde Das Doppeldachmodell f¨ur den Verifikationsprozess in

Abb 1.13 enth¨alt sowohl die Hardware-, die Software- als auch die Systemverifika-tion Die vertikalen Pfeile stellen Verifikationsschritte dar, w¨ahrend die horizontalen Pfeile die Komposition einzelner Komponenten beschreiben Man beachte, dass die Pfeile im Doppeldachmodell f¨ur den Verifikationsprozess gegen¨uber dem Doppel-dachmodell f¨ur den Entwurfsprozess entgegengesetzt verlaufen

Auf jeder Abstraktionsebene haben sich eigenst¨andige Ans¨atze zur automati-schen Verifikation etabliert, wobei diese oftmals Gemeinsamkeiten zeigen Wichtige Ans¨atze zur automatischen Verifikation von Hardware, Software und Systemen wer-den in diesem Buch in einer einheitlichen Notation dargestellt Es wird gezeigt, dass sich viele der vorgestellten Ans¨atze gleichermaßen auf Hardware, Software oder teil-weise auch auf Hardware/Software-Systeme anwenden lassen Da die beschriebenen Ans¨atze aber in einem bestimmten Kontext entwickelt wurden, werden sie in dem vorliegenden Buch auch in diesem Zusammenhang vorgestellt

Auch wenn die Verifikationsans¨atze viele Gemeinsamkeiten aufweisen, unter-scheiden sich diese auf den einzelnen Abstraktionsebenen erheblich Auf der Logi-kebene gilt es beispielsweise zu zeigen, dass eine Funktion korrekt in ein Schaltnetz bzw ein Schaltwerk umgesetzt wurde Die Spezifikation (die geforderte Funktion) ist dabei ein System Boolescher Funktionen, die Implementierung eine Netzliste aus Gattern Die Herausforderung besteht darin, zu zeigen, dass die Wahl einer bestimm-ten Technologie (Gattertypen) und somit des Basissystems und die daraus

System

Logik

Implementierung

Spezifikation

Architektur Modul

Block

Abb 1.13 Doppeldachmodell f¨ur den Verifikationsprozess digitaler

Hardware/Software-Systeme

renden Transformationen, die gew¨unschte Funktion, beispielsweise eines Multiple-xers oder Volladdierers, nicht verf¨alscht hat Auf h¨oherer Abstraktionsebene (der Architekturebene) kann diese Frage auch so formuliert werden: Berechnet ein Ad-dierer/Multiplizierer tats¨achlich die Summe/das Produkt der beiden Operanden? Einen Spezialfall auf dieser Ebene stellt die Prozessorverifikation dar Als Spe-zifikation dient dabei die Instruktionssatzarchitektur des Prozessors, der als eine se-quentielle Implementierung des Prozessors verstanden werden kann, d h die In-struktionssatzarchitektur beschreibt, wie die Ausf¨uhrung einer Instruktion den Zu-stand der f¨ur den Programmierer sichtbaren Register ¨andert Die Mikroarchitektur des Prozessors hingegen ist eine Hardware-Implementierung auf Registertransfere-bene und typischerweise hoch optimiert So erfolgt die Abarbeitung von

Instruktio-nen h¨aufig verschr¨ankt, d h die Mikroarchitektur implementiert eine sog Pipeline

mit unterschiedlichen Stufen der Abarbeitung von Instruktionen Hierdurch k¨onnen mehrere Instruktionen gleichzeitig in Bearbeitung sein Andere Optimierungen, die darauf zielen, den Durchsatz des Prozessors zu erh¨ohen, sind Sprungvorhersage mit spekulativer Ausf¨uhrung oder parallel arbeitende Funktionseinheiten, die eine dy-namische Ablaufplanung der Instruktionen in Abh¨angigkeit der Verf¨ugbarkeit von Ressourcen erm¨oglicht Zu zeigen, dass eine so optimierte Mikroarchitektur den In-struktionssatz korrekt implementiert, ist eine zentrale Aufgabe auf der Architekture-bene

Auf h¨oheren Abstraktionsebenen werden in der Hardware-Verifikation zuneh-mend nicht nur die ¨Ubereinstimmung des spezifizierten Verhaltens mit dem imple-mentierten Verhalten verglichen, sondern auch zus¨atzlich Eigenschaften der Imple-mentierung ¨uberpr¨uft Hierzu geh¨oren beispielsweise Eigenschaften, die garantieren, dass die Hardware in keinen ungew¨unschten oder gef¨ahrlichen Zustand ¨ubergeht bzw garantiert in einer vorgegebenen Zeitspanne eine gew¨unschte Reaktion zeigt