Digitale Hardware/ Software-Systeme- P3 pptx

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(c in ,a,b) und c out (c in ,a, b) ergibt sich: s(c in ,a, b)=(¬a ∧b ∧¬c in ) ∨(a ∧¬b ∧¬c in ) ∨(¬a ∧¬b ∧c in ) ∨(a ∧b ∧c in ) (1.3) und c out (c in ,a, b)=(a ∧b ∧¬c in ) ∨(¬a ∧b ∧ c in ) ∨(a ∧¬b ∧c in ) ∨(a ∧b ∧ c in ) (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 x 1 ⊕x 2 :=(¬x 1 ∧x 2 )∨(x 1 ∨¬x 2 ) ergibt sich f ¨ ur Gleichung (1.1): s(c in ,a, b)=(¬((¬a ∧b) ∨ (a ∧¬b))∧c in ) ∨(((¬a ∧b) ∨ (a ∧¬b))∧¬c in ) (1.5) Gleichung (1.5) kann mittels der De Morganschen Gesetze ¬(x 1 ∨ x 2 )=¬x 1 ∧¬x 2 und ¬(x 1 ∧ x 2 )=¬x 1 ∨¬x 2 umgeformt werden: s(c in ,a, b)=((a ∨¬b)∧(¬a ∨ b)∧c in ) ∨(((¬a ∧b) ∨ (a ∧¬b))∧¬c in ) (1.6) Durch Anwendung des Distributivgesetzes x 1 ∧(x 2 ∨x 3 )=(x 1 ∧x 2 )∨(x 1 ∧x 3 ) kann Gleichung (1.6) umgeformt werden zu: s(c in ,a, b)=(a ∧b ∧c in ) ∨(¬a ∧¬b ∧c in ) ∨(¬a ∧b ∧¬c in ) ∨(a ∧¬b ∧¬c in ) (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, s o 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 K 1 W 2 W 1 K 2 N 1 K 2 W 1 W 2 K 1 N 2 W 1 N 2 N 1 W 2 N 1 N 2 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. K 1 und K 2 die 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 ¬(K 1 ∧ K 2 ). 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 ¬(K 1 ∧ K 2 ) zu jedem Berechnungszeitpunkt (G) und f ¨ ur jede Ausf ¨ uhrungsreihenfol- ge (A) der beiden Prozesse gilt. Die obige Eigenschaft l ¨ asst sich somit als AG ¬(K 1 ∧ K 2 ) (1.8) 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: AG (W 1 ⇒ AF K 1 ) (1.9) Diese besagt, dass auf allen Berechnungspfaden (A) und zu einem beliebigen Be- rechnungszeitpunkt in der Zukunft (F), nachdem Prozess 1 den Wartezustand W 1 ein- genommen hat, dieser auch in den kritischen Bereich K 1 wechseln 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 N 1 N 2 sind 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. W 1 N 2 oder N 1 W 2 . Fordert nun der andere Prozess eben- falls das Semaphor an, so resultiert dies im Zustand W 1 W 2 . Alternativ kann der je- weils wartende Prozess den kritischen Bereich betreten. Die beiden Folgezust ¨ ande lauten in diesem Fall K 1 N 2 und N 1 K 2 . Ohne die weiteren m ¨ oglichen Zust ¨ ande in Abb. 1.18b) n ¨ aher zu beschreiben, sei hier festgestellt, dass ein Zustand K 1 K 2 , 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 W 1 N 2 → W 1 W 2 → W 1 K 2 → W 1 N 2 repr ¨ 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 p 1 , der auf der CPU ausgef ¨ uhrt wird, ist daf ¨ ur verantwortlich, die Sensordaten in den lokalen Speicher zu speichern. Ein zweiter Prozess p 2 verarbeitet diese Daten und versendet sie ¨ uber den gemein- samen Bus an eine I/O-Einheit. Die Ausf ¨ uhrungszeit des Prozesses p 2 variiert zwi- schen der schnellsten Ausf ¨ uhrungszeit d BC und langsamsten Ausf ¨ uhrungszeit d WC . Auf der I/O-Einheit nimmt Prozess p 3 die 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 p 1 eine h ¨ ohere Priorit ¨ at als der Prozess p 2 .Die maximale Auslastung der CPU ergibt sich f ¨ ur den Fall, dass Prozess p 2 bei der Be- arbeitung stets die l ¨ angste Ausf ¨ uhrungszeit ben ¨ otigt, d. h. d WC . t d WC b) Buslast d BC CPUSensor Speicher I/O Bus Input DSP Speicher a) p 1 p 2 p 3 p 6 p 5 p 4 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 p 4 ¨ uber den gemeinsamen Bus an den Prozess p 5 , der auf dem Digitalen Signal Prozessor (DSP) im System l ¨ auft, sendet. Der Prozess p 5 speichert die Daten im lokalen Speicher des DSP. Aus diesem 34 1 Einleitung Speicher liest der Prozess p 6 die 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 s ieht man, dass die Da- ten ¨ ubertragung von Prozess p 2 zu Prozess p 3 mit der ¨ Ubertragung der Daten zwi- schen Prozess p 4 und p 5 interferiert. I nteressant hierbei ist der Aspekt, dass eine Ausf ¨ uhrung des Prozesses p 2 mit der schnellsten Ausf ¨ uhrungszeit d BC zu einer ho- hen Buslast, eine Ausf ¨ uhrung mit der langsamsten Ausf ¨ uhrungszeit d WC 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 s owohl 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. 2 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 formaler 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 erfolgen. 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 formale 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 einer 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( τ )=  [F,F, F,F] falls s( τ )=T [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 ersten drei Taktzyklen weiterhin 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 Wert F tr ¨ agt, behoben werden. ∀ τ ∈ N : dout( τ )=  F if τ < 4 din( τ − 4) else out( τ )=  [F,F, F,F] falls s( τ )=T [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)=  [F,F, F,F] falls s( τ )=T [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 Programmiersprachen (wie 40 2 Spezifikation digitaler Systeme z. B. C/C++, VHDL/SystemVerilog, SystemC, Esterel) im Allgemeinen verschiede- ne Berechnungsmodelle repr ¨ asentieren k ¨ onnen 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 vorgenommen 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 Eigenschaften 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 Eigenschaften 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 nichtfunktionale Anforderungen, wie maxima- le Antwortzeit, minimale Durchsatz, maximales Gewicht, minimale 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. [...]... = { p0 , p1 , p2 , p3 } T = {t0 ,t1 ,t2 } F = { f0 , f1 , f2 , f3 , f4 , f5 , f 6 , f7 , f8 , f9 } f 0 = (p0 ,t0 ), f1 = (t0 , p1 ), f2 = (p0 ,t2 ), f3 = (t0 , p2 ), f4 = (p1 ,t1 ), f5 = (t1 , p1 ), f6 = (p2 ,t1 ), f7 = (t2 , p2 ), f8 = (t1 , p3 ), f9 = (p3 ,t2 ) M0 (p0 ) = 2, M0 (p1 ) = 0, M0 (p2 ) = 0, M0 (p3 ) = 1 p1 t1 t0 p0 p3 p2 •t0 = { p0 } •t1 = { p1 , p2 } •t2 = { p0 , p3 } t2 t0 • = { p1... funktionalen und nichtfunktionalen Anforderuna gen im Bereich eingebetteter Hardware/Software-Systeme vorgestellt 2.2 Formale Verhaltensmodelle Eine M¨ glichkeit, das gew¨ nschte Systemverhalten pr¨ zise zu beschreiben, besteht o u a in der Erstellung eines formalen Verhaltensmodells Geeignete Modelle zur Verhaltensmodellierung von digitalen Hardware/Software-Systemen wurden bereits in [426] vorgestellt Hier... als Pfeile notiert Im Zusammenhang mit einem Netzknoten x hat man h¨ ufig mit zwei a bestimmten Mengen von Nachbarknoten zu tun Dies ist zum einen der Vorbereich •x = {y | (y, x) ∈ F}, 42 2 Spezifikation digitaler Systeme also die Menge aller direkten Vorg¨ nger von x (z B Eingangsstellen, falls x Transia tion ist) Zum anderen ist dies der Nachbereich x• = {y | (x, y) ∈ F}, also die Menge aller direkten... (t2 , p2 ), f8 = (t1 , p3 ), f9 = (p3 ,t2 ) M0 (p0 ) = 2, M0 (p1 ) = 0, M0 (p2 ) = 0, M0 (p3 ) = 1 p1 t1 t0 p0 p3 p2 •t0 = { p0 } •t1 = { p1 , p2 } •t2 = { p0 , p3 } t2 t0 • = { p1 , p2 } t1 • = { p1 , p3 } t2 • = { p2 } Abb 2.2 Beispiel eines Petri-Netzes G Marken sind Attribute von Stellen und zirkulieren im Petri-Netz Der Zustand ¨ eines Netzes wird uber die Markierungsfunktion M : P → Z≥0 (im Weiteren... Ausgangsstellen der Transition erfolgt simultan Beispiel 2.2.2 In dem Petri-Netz in Abb 2.2 ist Transition t2 schaltbereit Nach Feuern von t2 ist die neue Markierung M mit M (p0 ) = M (p2 ) = 1 und M (p1 ) = M (p3 ) = 0 Petri-Netze sind zur Modellierung dynamischer, zustandsdiskreter Systeme weit verbreitet Zun¨ chst werden nur Petri-Netze mit unbeschr¨ nkter Kapazit¨ t und Eina a a heitsgewichten (∀p ∈ P : K(p)... Konflikt, wenn M[ti und M[t j , aber nicht M[{ti ,t j } Dabei bezeichne a M[{t0 ,t1 , , tn−1 } die gleichzeitige, nebenl¨ ufige Schaltbereitschaft aller Transitionen t0 ,t1 , ,tn−1 44 2 Spezifikation digitaler Systeme Funktionale Eigenschaften von Petri-Netzen Im Folgenden werden funktionale Eigenschaften von Petri-Netzen definiert Diese Eigenschaften erlauben die Einordnung bekannter Modelle als Teilklassen... beschreiben Zus¨ tzlich a wird eine Zeitstruktur T : T → T × (T ∪ {∞}) ben¨ tigt, die jeder Transition t ∈ T o a einen fr¨ hesten τl (t) und sp¨ testens Startzeitpunkt τu (t) zuordnet u 46 2 Spezifikation digitaler Systeme Definition 2.2.12 (Schaltbereitschaft) Eine Transition t0 ∈ T eines zeitbehafteten Petri-Netzes G(P, T, F, K,W, M0 , B) heißt schaltbereit unter der Markierung M und der Zeitstruktur T... I × O) die Ausgaberelation Ein endlicher Automat heißt deterministisch (engl Deterministic Finite Automaton, DFA), wenn |R| = 1 und f sowie g Funktionen sind mit f : (S × I) → S und 48 2 Spezifikation digitaler Systeme ¨ g : (S × I) → O Die Funktionen f und g werden dann als Ubergangsfunktion bzw Ausgabefunktion bezeichnet Ein DFA heißt vollst¨ ndig spezifiziert, wenn f und g a Funktionen sind, also... tzlich die Werte ν (c) der Zeitvariablen u a c ∈ C ber¨ cksichtigt werden Die Ausf¨ hrungssemantik eines zeitbehafteten Autou u maten ergibt sich aus zwei Arten von Zustands¨ nderungen: a 50 2 Spezifikation digitaler Systeme 1 Zustands¨ nderung aufgrund eines Zeitfortschritts δ ∈ T: a δ ∈T (s, ν ) −→ (s, ν ) mit ∀c ∈ C : ν (c) := ν (c) + δ Dabei muss f¨ r alle 0 ≤ δ ≤ δ und alle c ∈ C gelten, dass ν (c) + . Y-Diagramm pr ¨ asentiert. 2 Spezifikation digitaler Systeme Dieses Kapitel stellt wichtige Ans ¨ atze zur formalen und ausf ¨ uhrbaren Spezifikation digitaler Hardware/Software-Systeme vor. 2.1 Wie. 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. 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.