Digitale Hardware/ Software-Systeme- P3 pptx

Eine wichtige Eigenschaft f¨ur das oben beschriebene Software-System ist beispielsweise, dass sich niemals zwei Prozesse gleichzeitig im kritischen Bereich befinden.. 32 1 EinleitungEin

30 1 Einleitung

in eine Funktionstabelle oder die Werte der Funktionstabelle in eine Funktionsbe-schreibung umgewandelt werden Hier wird letztere M¨oglichkeit gezeigt

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

cout (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) sowie die ¨Aquivalenz zwischen Gleichung (1.2) und Gleichung (1.4) gezeigt werden Hier wird 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 Voll-addierer implementierte Berechnung des Summenbits ¨aquivalent zur Spezifikation

Software-Eigenschaftspr ¨ufung

Betrachtet wird ein Software-System bestehend aus zwei Prozessen Da die Prozesse auf 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 Prozess das beanspruchte Semaphor nicht, so muss dieser warten und kann die Ressource nicht belegen Erh¨alt der Prozess das Semaphor, so kann er die Ressource belegen Man sagt, er betritt den kritischen Bereich Nach Verlassen des kritischen Bereichs muss der Prozess das Semaphor wieder freigeben Ein Zustandsmodell f¨ur einen ausf¨uhrungsbereiten Prozess ist in Abb 1.18a) dargestellt

Ein ausf¨uhrungsbereiter Prozess startet im Zustand N Sobald dieser einen kriti-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

1.4 Beispiele 31

b) a)

s?

s!

N

W

K

N1K2 W1W2

K1N2

N1N2

Abb 1.18 a) Zustandsmodell eines ausf¨uhrungsbereiten Prozesses und b) Zustandsmodell f¨ur

zwei Prozesse

K kann der Prozess nach Zuteilung des Semaphors (s!) betreten Den kritischen Be-reich verl¨asst der Prozess, indem er in den Zustand N zur¨uck wechselt Dabei wird

das Semaphor frei gegeben Die Verwaltung des Semaphors und deren exklusive Zu-teilung an Prozesse ist in Abb 1.18a) nicht dargestellt und wird typischerweise von einem Betriebssystem kontrolliert

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

for-mal zu beschreiben Wenn z B K1und K2die kritischen Bereiche zweier Prozesse darstellen, 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 Eigenschaft gelten soll So k¨onnte es unterschiedliche Interpretationen geben, wie z B.:

”Diese Eigenschaft gilt irgendwann“ oder

”Es ist m¨oglich, dass die Eigenschaft irgendwann gilt“

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

¬(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

32 1 Einleitung

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

”Eine Anfrage, den kritischen Bereich zu betreten, wird irgendwann erf¨ullt“ Auch hier ist wiederum die Aussa-genlogik nicht m¨achtig genug, um zeitliche und modale Effekte auszudr¨ucken Die entsprechende 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 Weiterhin muss diese Bedingung zu jedem Berechnungszeitpunkt (G) und f¨ur alle beliebigen Ausf¨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 beide Prozesse 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 je-weils wartende Prozess den kritischen Bereich betreten Die beiden Folgezust¨ande

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 Bereich sind, nicht erreicht wird Hierf¨ur sorgt das Betriebssystem, welches ein Semaphor immer nur exklusiv vergibt und somit den jeweils anderen Prozess am Eintritt in den kritischen 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→ W1 W2→

W1K2→ W1N2repr¨asentiert eine g¨ultige Ausf¨uhrungsreihenfolge und stellt somit ein Gegenbeispiel dar, in dem der wartende Prozess 1 niemals den kritischen Bereich betritt 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 sein kann, 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¨oglicher Ausf¨uhrungsreihenfolgen mit Systemzust¨anden, wie in Abb 1.18b), w¨urde schon bei 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 nichtfunktionaler Eigenschaften eingebetteter Systeme ein wichtiges Thema Hier spielt insbesondere die ¨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¨uhrt wird, 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 dBC und langsamsten Ausf¨uhrungszeit dWC Auf der I/O-Einheit nimmt Prozess p3die Daten zur Weiterverarbeitung entgegen

In diesem Beispiel wird angenommen, dass auf der CPU ein Betriebssystem mit einer 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 dWC.

t

d WC

b) Buslast

d BC

CPU

Bus

a)

p6

p5

p4

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

34 1 Einleitung

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

Im Folgenden wird angenommen, dass auf dem Bus eine First Come, First Ser-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-schen Prozess p4 und p5 interferiert Interessant hierbei ist der Aspekt, dass eine

Ausf¨uhrung des Prozesses p2mit der schnellsten Ausf¨uhrungszeit dBCzu einer

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

1.5 Ausblick

Basierend auf den in diesem Kapitel eingef¨uhrten Verifikationsaufgaben werden im Folgenden 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¨oglichkeiten zur formalen oder ausf¨uhrbaren Spezifikation pr¨asentiert werden Kapitel 3 gibt eine detaillierte Klassifikation von Verifikationsans¨atzen nach Verifikationsaufgabe, Veri-fikationsmethode und Verifikationsziel

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

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

Im Anschluss an die Einf¨uhrung in modellbasierte Verifikationsans¨atze werden spezielle Verfahren zur Hardware-Verifikation (Kapitel 6), zur Software-Verifikation (Kapitel 7) und Systemverifikation (Kapitel 8) vorgestellt Anhang A bis C enth¨alt grundlegende 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 es weitere Modelle, die den Entwurf von eingebetteten Systemen beschreiben So kann

1.6 Literaturhinweise 35

das Doppeldachmodell als Erweiterung des Y-Diagramms nach Gajski und Kuhn

[170] mit einer expliziten Trennung von Hardware- und Software-Entwurfsprozess verstanden werden Dabei verzichtet das Doppeldachmodell auf ein zus¨atzliches

Layout-Dach, welches eine physikalische Sicht auf den Entwurf bieten w¨urde.

W¨ahrend traditionell Layout-Informationen auf der Systemebene eine

untergeordne-te Rolle gespielt haben, werden diese zunehmend auch auf dieser Ebene eingesetzt,

um r¨aumliche Effekte wie sog engl hot spots [477] oder durch Leitungsl¨angen

ver-ursachte Verz¨ogerungszeiten [354] zu ber¨ucksichtigen

Das X-Diagramm ist ausf¨uhrlich in [182] beschrieben und gibt einen ¨Uberblick

¨uber Methoden zur Systemsynthese Es kombiniert zwei unterschiedliche Aspekte: Die Synthese mit dem Strukturmodell als Ausgabe und die Bewertung einer Im-plementierung in Form von Qualit¨atsmaßen Diese beiden Aspekte wurden bereits fr¨uher durch zwei entsprechende Y-Diagramme getrennt behandelt: Der Synthesea-spekt wurde im bereits erw¨ahnten Y-Diagramm nach Gajski und Kuhn [170] vor-gestellt und sp¨ater in eine entsprechend Entwurfsmethodik [171] umgesetzt Der Bewertungsaspekt wurde erstmals durch Kienhuis et al in [258] als Y-Diagramm pr¨asentiert

Spezifikation digitaler Systeme

Dieses Kapitel stellt wichtige Ans¨atze zur formalen und ausf¨uhrbaren Spezifikation digitaler Hardware/Software-Systeme vor

2.1 Wie spezifiziert man ein System?

Im Doppeldachmodell in Abb 1.10 und 1.13 auf Seite 14 bzw 19 beschreibt das

obere Dach die Spezifikation des Systems auf unterschiedlichen

Abstraktionsebe-nen Die Erstellung der Spezifikation auf Systemebene stellt einen zentralen Schritt vor dem Systementwurf und somit der Systemverifikation dar Typischerweise wird

eine Spezifikation anhand von Anforderungen (engl requirements) erstellt Zwei

we-sentliche Bestandteile einer Spezifikation sind dabei immer eine Beschreibung des

gew¨unschten Verhaltens und der geforderten Eigenschaften an die Implementierung

des Systems

Definition 2.1.1 (Spezifikation) Eine Spezifikation eines Systems besteht aus einer

pr¨azisen Beschreibung des Verhaltens des Systems und einer pr¨azisen Beschreibung der geforderten Eigenschaften an die Implementierung des Systems.

Eine Spezifikation beschreibt somit, was ein System unter welchen Bedingungen tun soll Dabei sollte die Spezifikation m¨oglichst abstrakt sein, also unn¨otige Details vermeiden, und generell sein, um resistent gegen sp¨atere ¨Anderungen der

Anforde-rungen zu sein Spezifikationen k¨onnen dabei informal oder formal sein Eine

forma-le Spezifikation basiert auf Beschreibungen mit klar definierter formaforma-ler Semantik.

Formale Spezifikationen basieren somit auf formalen Verhaltensmodellen sowie for-malen Anforderungsbeschreibungen Dies kann es erm¨oglichen, Konsequenzen zu berechnen, die sich aus der Spezifikation ergeben

Somit stellt sich aber die Frage, wie ein System zu spezifizieren ist? Wie in Abb 1.3 auf Seite 4 dargestellt, startet der Entwurfsfluss mit einer Idee Diese wird typischerweise nicht direkt in eine formale Spezifikation umgesetzt Vielmehr

be-ginnen die meisten Entwicklungen mit einer informalen Spezifikation Diese kann in

C Haubelt, J Teich, Digitale Hardware/Software-Systeme, eXamen.press,

DOI 10.1007/978-3-642-05356-6 2, c Springer-Verlag Berlin Heidelberg 2010

38 2 Spezifikation digitaler Systeme

Form von nat¨urlicher Sprache, Skizzen oder anderen unvollst¨andigen Beschreibun-gen mit informaler Semantik erfolBeschreibun-gen Informale Spezifikationen leiden oft darunter, dass sie [272]:

• mehrdeutig und

• unvollst¨andig sowie

• schlecht strukturiert und somit schwer zu analysieren und formalisieren sind.

Um die Qualit¨at eines Systems zu verbessern, ist es somit notwendig, eine infor-male Spezifikation in eine forinfor-male Spezifikation zu ¨uberf¨uhren Dies ist sowohl im Entwurf [426] als auch in der Verifikation von Vorteil Wie kann also eine formale Spezifikation aus einer informalen Beschreibung gewonnen werden, so dass diese

korrekt, eindeutig und vollst¨andig ist sowie alle wesentlichen Aspekte abdeckt?

Die ¨Uberpr¨ufung, ob eine Spezifikation korrekt ist, wird als Validierung

bezeich-net F¨ur formale Spezifikationen k¨onnen hierzu oftmals Plausibilit¨atstests oder

Kon-sistenzpr¨ufungen durchgef¨uhrt werden Ist eine Spezifikation ausf¨uhrbar, d h

ba-siert diese auf einer ausf¨uhrbaren Verhaltensbeschreibung, so kann diese zum Zwe-cke der Validierung simuliert werden Obwohl einige der in diesem Buch vorgestell-ten Methoden auch zur Validierung einer Spezifikation Anwendung finden k¨onnen, ist der Prozess der Validierung nicht Gegenstand dieses Buches Dennoch sei betont, dass die Validierung der Korrektheit einer Spezifikation entscheidend f¨ur die Qualit¨at eines zu entwickelnden Produktes ist Dies liegt insbesondere daran, dass

unentdeck-te Spezifikationsfehler zu Produktfehlern f¨uhren k¨onnen, da die Verifikation nur die Korrektheit bez¨uglich einer Spezifikation zeigen kann

Die Probleme bei der Erstellung einer formalen Spezifikation aus einer informa-len Beschreibung werden im nachfolgenden Beispiel illustriert Das Beispiel stammt aus [272]

Beispiel 2.1.1 Betrachtet wird das System aus Abb 2.1.

out

din

dout s

4

Abb 2.1 Seriell-Parallel-Wandler [272]

Weiterhin ist die folgende Spezifikation gegeben: Der Eingang din verarbeitet

ei-ne Sequenz aus Bits Der Ausgang dout emittiert die selbe Sequenz mit eiei-ner Verz¨oge-rung von vier Taktzyklen Der Bus out ist vier Bit breit Falls der Eingang s den Wert

F hat, dann entspricht das 4-Bit Wort an out den letzten vier Bit am Eingang din Falls s gleich T ist, dann ist das Wort an out gleich 0, d h [F,F,F,F].

Obwohl die Spezifikation sehr detailliert f¨ur ein solch kleines System wirkt, ist sie

2.1 Wie spezifiziert man ein System? 39

1 ungenau: Enthalten die letzten vier Bit des Eingangs auch das momentane Bit?

2 unvollst¨andig: Auf welchen Wert wird der Ausgang dout in den ersten drei

Takt-zyklen gesetzt?

3 nicht analysierbar: Die Spezifikation ist umgangssprachlich und unstrukturiert

und somit nicht automatisch verarbeitbar

Zun¨achst wird aus der informalen eine formale Spezifikation erstellt Dabei wird die Zeit als nat¨urliche Zahlτ∈ N modelliert.

∀τ∈ N : dout(τ) = din(τ− 4)

out(τ) =



[din(τ− 4),din(τ− 3),din(τ− 2),din(τ− 1)] sonst

Betrachtet man diese formale Spezifikation etwas genauer, f¨allt auf, dass die

Wer-te f¨ur dout in den ersWer-ten drei Taktzyklen weiWer-terhin unspezifiziert sind Da hier die Zeit lediglich ¨uber die nat¨urlichen Zahlen definiert ist, ist unklar, ob der Wert din(−1),

din(−2) und din(−3) definiert vorliegt Dieses Problem kann mit der folgenden

An-nahme, dass dout die ersten drei Takt den WertF tr¨agt, behoben werden

∀τ∈ N : dout(τ) =



F ifτ< 4

din(τ− 4) else

out(τ) =



[din(τ− 4),din(τ− 3),din(τ− 2),din(τ− 1)] sonst

Nun ist das Verhalten zwar vollst¨andig spezifiziert, fraglich ist jedoch, ob dieses Ver-halten von der informalen Spezifikation beabsichtigt war Eine alternative formale Spezifikation, die ohne eine zus¨atzliche Annahme auskommt, k¨onnte wie folgt aus-sehen

∀τ∈ N : dout(τ+ 4) = din(τ) ∧

out(τ+ 4) =



[din(τ),din(τ+ 1),din(τ+ 2),din(τ+ 3)] sonst Obwohl das obige Beispiel zeigt, dass die Erstellung einer formalen Spezifikation nicht einfach ist, hat diese einen erheblichen Vorteil: Bereits durch die Erstellung ei-ner formalen Spezifikation k¨onnen viele Fehler im Entwurfsprozess vermieden wer-den, sogar ohne dass die Spezifikation f¨ur die Verifikation verwendet wird

Jede formale Spezifikation basiert auf ihrem formalen Verhaltensmodell, wel-ches mathematisch fundiert ist Die Ausdruckskraft eines Verhaltensmodells wird als

Berechnungsmodell (engl Model of Computation, MoC) bezeichnet

Berechnungs-modelle mit einer hohen Ausdruckskraft sind schwieriger zu analysieren, als Be-rechnungsmodelle mit einer geringeren Ausdruckskraft Bestimmte Fragestellungen lassen sich somit nicht f¨ur alle Berechnungsmodelle beantworten

Formale Verhaltensmodelle besitzen oftmals keine Ausf¨uhrungssemantik und sind somit nicht simulierbar Eine ausf¨uhrbare Spezifikation hingegen besitzt die

Ei-genschaft, dass diese auf einem ausf¨uhrbaren Verhaltensmodell basiert H¨aufig wer-den zum Zweck der Erstellung von ausf¨uhrbaren Verhaltensmodellen Programmier-sprachen eingesetzt Es sollte hier betont werden, dass ProgrammierProgrammier-sprachen (wie

40 2 Spezifikation digitaler Systeme

z B C/C++, VHDL/SystemVerilog, SystemC, Esterel) im Allgemeinen

verschiede-ne Berechnungsmodelle repr¨asentieren k¨onverschiede-nen und dass ein Berechnungsmodell in mehreren Sprachen ausgedr¨uckt werden kann

Ausf¨uhrbare Verhaltensmodelle besitzen den Vorteil, dass diese eindeutig sind Kommen Fragen w¨ahrend des Entwurfs des Systems auf, wird die Spezifikation f¨ur den fraglichen Fall simuliert und liefert die entsprechende Antwort Auf der anderen Seite sind ausf¨uhrbare Verhaltensmodelle h¨aufig ¨uberspezifiziert, d h diese spezifi-zieren nicht nur das gew¨unschte Verhalten der Implementierung, sondern geben be-reits Implementierungsentscheidungen vor Dies kann dazu f¨uhren, dass Optimierun-gen an dem System w¨ahrend des Entwurfs nicht mehr vorOptimierun-genommen werden k¨onnen,

da diese die Spezifikation verletzen Somit k¨onnen suboptimale Implementierungen entstehen Ein weiterer Nachteil bei der Verwendung von Programmiersprachen zur Spezifikation ist die Detektion eingeschr¨ankter Berechnungsmodelle Programmier-sprachen sind h¨aufig berechnungsuniversell Welches konkrete Berechnungsmodell

in einem Programm gemeint war, l¨asst sich dann nur schwer oder gar nicht fest-stellen Da allerdings formale Verifikationsmethoden auf eingeschr¨ankten Berech-nungsmodellen basieren, ist deren Anwendung somit nicht direkt m¨oglich, da die Spezifikation nicht restriktiv genug ist

Betrachtet man Abb 1.12 auf Seite 17, so sieht man, dass eine Spezifikation

neben dem Verhaltensmodell weitere Anforderungen enth¨alt W¨ahrend das

Verhal-tensmodell beschreibt, was ein System tun soll, schr¨anken die Anforderungen die Implementierungsm¨oglichkeiten ein, d h sie stellen Bedingungen an die Qualit¨ats-merkmale einer Implementierung dar Wie bei der Spezifikation des Verhaltens, ist

es auch bei der Spezifikation der Anforderungen vorteilhaft, diese formal zu

er-stellen Anforderungen k¨onnen in funktionale und nichtfunktionale Anforderungen eingeteilt werden Funktionale Anforderungen beschr¨anken funktionale Eigenschaf-ten des Systems Wichtige funktionale EigenschafEigenschaf-ten f¨ur eingebettete Systeme sind Gefahrlosigkeits- (engl safety) und Lebendigkeitseigenschaften (engl liveness pro-perties) Gefahrlosigkeit dr¨uckt dabei aus, dass ein System niemals einen f¨ur sich

oder die Umwelt gef¨ahrlichen Zustand einnehmen wird Lebendigkeit beschreibt die Eigenschaft, dass ein System irgendwann in der Zukunft

”etwas“ tut.

Nichtfunktionale Anforderungen formulieren Ziele f¨ur nichtfunktionale Eigen-schaften eines eingebetteten Systems Beispiele f¨ur nichtfunktionale EigenEigen-schaften

eingebetteter Systeme sind vielf¨altig Wichtige Vertreter sind die Reaktionszeit, der Durchsatz, das Gewicht, die Zuverl¨assigkeit etc Da eingebettete Systeme f¨ur

speziel-le Aufgaben entwickelt werden, sind nichtfunktionaspeziel-le Anforderungen, wie

maxima-le Antwortzeit, minimamaxima-le Durchsatz, maximamaxima-les Gewicht, minimamaxima-le Zuverl¨assigkeit etc., in diesem Bereich sehr wichtig Die Messung oder Absch¨atzung funktionaler und nichtfunktionaler Eigenschaften erfolgt mittels geeigneter Qualit¨atsmaße Ob-wohl das Einhalten verschiedenster nichtfunktionaler Anforderungen essentiell f¨ur eingebettete Systeme ist, und somit alle diese Anforderungen erf¨ullt sein m¨ussen, wird in dem vorliegenden Buch lediglich die ¨Uberpr¨ufung zeitlicher Anforderungen behandelt