Digitale Hardware/ Software-Systeme- P19 ppt

6.5 Zeitanalyse 353 v 0 v 1 v 2 1 11 1 v 3 i α (v i ) 10 1 2 3 1 1 0 Abb. 6.81. LIS-Graph zu dem latenzinsensitiven System aus Abb. 6.80 mit minimalen Queues [309] Im Folgenden wird ein System zu diskreten Zeitpunkten betrachtet, d. h. T = Z ≥0 . Das Verhalten eines einzelnen Moduls v i ∈ V l ¨ asst sich dann als Sequenz ˜s i = s i (0),s i (1),s i (2),  von Zust ¨ anden s i ( τ ) des Moduls zu Zeitpunkten τ ∈ T beschreiben. Dabei gilt: s i ( τ ) := ⎧ ⎨ ⎩ α (v i ) f ¨ ur τ = 1 s i ( τ − 1) f ¨ ur τ > 1 und v i h ¨ alt zum Zeitpunkt τ an s i ( τ − 1)+1 sonst (6.26) Mit anderen Worten: s i ( τ ) entspricht der Anzahl produzierter informativer Daten bis zum Zeitpunkt τ . Entsprechend produziert eine Hardware-Komponente zum Zeit- punkt τ = 1 ein Datum ( α (v i )=1), w ¨ ahrend eine Relais-Station kein Datum produziert ( α (v i )=0). Bei allen Modulen erh ¨ oht sich die Anzahl produzierter informativer Daten mit jedem Takt, solange das Modul nicht anh ¨ alt. Hiermit lassen sich die in einer Queue (v i ,v j ) gespeicherten Daten f i, j zum Zeit- punkt τ in Abh ¨ angigkeit von den Zust ¨ anden der Module v i und v j berechnen: f i, j ( τ ) :=  ∅ falls s i ( τ )=s j ( τ ) − α (v j ) {s i ( τ ),s i ( τ ) − 1, ,s j (t)− α (v j )+1} sonst Die Anzahl | f i, j ( τ )| der gespeicherten informativen Daten f i, j ( τ ) in einer Queue (v i ,v j ) zum Zeitpunkt τ ist somit: | f i, j ( τ )| = s i ( τ ) − s j ( τ )+ α (v j ) ≤ q(v i ,v j )+1 (6.27) Diese muss kleiner der Kapazit ¨ at der Queue plus eins sein, d. h. der Kanal kann keine weiteren informativen Daten speichern und das Modul v i m ¨ ochte informative Daten produzieren. Mit anderen Worten: Der Kanal ist voll, wenn die Kapazit ¨ at der Queue um eins ¨ uberschritten wurde. Basierend auf obiger Zustandsdefinition und den Kanalbeschr ¨ ankungen in Glei- chung (6.27) k ¨ onnen nun die Zustands ¨ anderungen in einem latenzinsensitiven Sys- tem beschrieben werden. Betrachtet wird das Modul v i mit Eingangskanal (v j ,v i ). Falls Kanal (v j ,v i ) nicht gen ¨ ugend informative Daten bereit h ¨ alt, h ¨ alt Modul v i an. In diesem Fall gilt | f j,i ( τ )| = s j ( τ ) − s i ( τ )+ α (v i )=0, d. h. s i ( τ + 1)=s i ( τ )= 354 6 Hardware-Verifikation s j ( τ )+ α (v i ). Falls der Kanal allerdings nicht leer ist, gilt | f j,i ( τ )| = s j ( τ ) − s i ( τ )+ α (v i ) ≥ 0 und somit s i ( τ +1)=s i ( τ )+1 und s i ( τ +1) ≤ s j ( τ )+ α (v i ). Zusammen- gefasst ergibt dies: s i ( τ + 1) ≤ s j ( τ )+ α (v i ).Dadiesf ¨ ur alle Eingangskan ¨ ale gelten muss, bestimmt der langsamste Kanal, ob das Modul v i anh ¨ alt, d. h. s i ( τ + 1) ≤ min (v j ,v i )∈E {s j ( τ )+ α (v i )} (6.28) Betrachtet wird das Modul v i und der Ausgangskanal (v i ,v j ). Ist der Kanal (v i ,v j ) voll, so kann das Modul v i keine weiteren informativen Daten produzieren und h ¨ alt an, d. h.: s i ( τ + 1)=s i ( τ )=| f i, j ( τ )| + s j ( τ ) − α (v j )=s j ( τ )+q(v i ,v j )+1 − α (v j ) Falls der Kanal allerdings nicht voll ist, gilt: s i ( τ + 1)=s i ( τ )+1. Dies kann h ¨ ochstens dazu f ¨ uhren, dass anschließend der Kanal voll ist, d. h. s i ( τ )+1 ≤ s j ( τ )+q(v i ,v j )+1 − α (v j ). Fasst man nun beide F ¨ alle zusammen erh ¨ alt man: s i ( τ + 1) ≤ s j ( τ )+q(v i ,v j )+1 − α (v j ), da hierbei alle Ausgangskan ¨ ale betrachtet werden m ¨ ussen, ist der langsamste Kanal ausschlaggebend: s i ( τ ) ≤ min (v i ,v j )∈E {s j ( τ )+q(v i ,v j )+1 − α (v j )} (6.29) Unter Verwendung der Max-Plus-Algebra (R∪{∞},min,+) (siehe auch Seite 230) und des Vektors s( τ )=(s 0 ( τ ), ,s |V |−1 ( τ ))  lassen sich die Gleichungen (6.28) und (6.29) f ¨ ur alle s i ( τ ) zusammenfassen: s( τ + 1) ≤ A LIS ⊗ s( τ ) (6.30) Dabei ist ⊗ die Multiplikation der Max-Plus-Algebra mit a ⊗ b := min{a,b}.Die Matrix A LIS ist f ¨ ur einen gegebenen LIS-Graphen G LIS wie folgt definiert: a i, j := ⎧ ⎪ ⎪ ⎨ ⎪ ⎪ ⎩ α (v i ) falls (v j ,v i ) ∈ E q(v i ,v j )+1 − α (v j ) falls (v i ,v j ) ∈ E ∧ (v j ,v i ) ∈ E 1 falls i = j ∞ sonst (6.31) Beispiel 6.5.4. Betrachtet wird wiederum das latenzinsensitive System aus Abb. 6.80 auf Seite 351 mit dem zugeh ¨ origen LIS-Graphen G LIS aus Abb. 6.81. Die Matrix A LIS ergibt sich zu: A LIS = ⎛ ⎜ ⎜ ⎝ 11∞ 2 111∞ ∞ 111 0 ∞ 11 ⎞ ⎟ ⎟ ⎠ Zeitanalyse Die Bestimmung des Durchsatzes eines latenzinsensitiven Systems erfolgt ¨ uber die Bestimmung des Durchsatzes eines einzelnen Moduls. Der Durchsatz eines Moduls 6.5 Zeitanalyse 355 v i ∈ V ist definiert zu Θ (v i ) := lim τ →∞ s i ( τ ) τ . Um zu dem Durchsatz des Systems zu gelangen, werden nun zwei verbundene Module v i und v j mit (v i ,v j ) ∈ E betrachtet. Man beachte, dass das Module v j lediglich Daten lesen kann, die bereits von v i produziert worden sind, d. h. s i ( τ ) ≥ s j ( τ )− α (v j ). Mit Gleichung (6.27) ergibt dies: s j ( τ ) − α (v j ) ≤ s i ( τ ) ≤ s j ( τ )+q(v i ,v j )+1 − α (v j ) F ¨ ur den Durchsatz der beiden Module bedeutet dies: Θ (v j ) := lim τ →∞ s j ( τ ) − α (v j ) τ ≤ Θ (v i ) ≤ lim τ →∞ s j ( τ )+q(v i ,v j )+1 − α (v j ) τ = Θ (v j ) Mit anderen Worten: Der Durchsatz der beiden Module i st identisch, d. h. Θ (v i )= Θ (v j ). Somit gilt f ¨ ur alle Module eines latenzinsensitiven Systems, dass der Durch- satz aller Module gleich ist, sofern der LIS-Graph G LIS zusammenh ¨ angend ist. Die Berechnung des maximalen Durchsatzes, also desjenige Durchsatzes, der erzielt werden kann, wenn auf keine externen Eingaben gewartet werden muss, kann auf Basis des folgenden Theorems [309] berechnet werden: Theorem 6.5.1. Sei G LIS =(V,E,q, α ) ein LIS-Graph mit Matrix A LIS . Der maxima- le Durchsatz ist Θ (G LIS )= λ , wobei λ der Eigenwert der Matrix A LIS ist. Das obige Ergebnis beruht auf folgendem Theorem [112]: Theorem 6.5.2. Sei X ∈ R n×n die Adjazenzmatrix eines stark zusammenh ¨ angenden markierten Graphen G, dann gilt ∃q, p : ∀k ≥ q : X ⊗ k+p = λ ⊗ p ⊗ X ⊗ p Dies bedeutet, dass die Sequenz X ⊗ 1 ,X ⊗ 2 ,  zyklisch mit einer Periode p ist. Beispiel 6.5.5. Betrachtet wird das latenzinsensitive Systeme aus Abb. 6.80 auf Sei- te 351. Die zugeh ¨ orige Matrix A LIS wurde bereits in Beispiel 6.5.4 bestimmt. Be- stimmt man A ⊗ k LIS f ¨ ur k = 1, 2, , so s ieht man, dass A ⊗ 6 LIS = 3 ⊗ A ⊗ 2 LIS ist. Mit Theo- rem 6.5.2 erh ¨ alt man: A ⊗ k+4 LIS = A ⊗ 6 LIS ⊗ A ⊗ k−2 LIS = 3 ⊗ A ⊗ 2 LIS ⊗ A ⊗ k−2 LIS = 3 ⊗ A ⊗ k LIS f ¨ ur k > 2 Damit ergibt sich λ ⊗ 4 = 3 und somit λ = Θ (G LIS )= 3 4 als maximaler Durchsatz. Zur Interpretation des Ergebnisses bietet es sich an, die Matrix A LIS als einen markierten Graphen darzustellen. Der zu dem in Abb. 6.80 auf Seite 351 dargestell- ten latenzinsensitiven System mit minimalen Queues ¨ aquivalente markierte Graph ist in Abb. 6.82 dargestellt. Dieser wurde direkt aus der Matrix A LIS aus Beispiel 6.5.4 konstruiert. Die Verz ¨ ogerungszeiten der Aktoren a ∈ A sind mit δ (a) := 1 ange- nommen. Es handelt sich um eine synchrone Schaltung. Darin sieht man, dass jede Verbindung im Originalsystem gepuffert ist und entsprechend im markierten Graph 356 6 Hardware-Verifikation v 0 v 1 v 2 v 3 Abb. 6.82. Markierter Graph f ¨ ur das latenzinsensitive System in Abb. 6.80 mit minimalen Queues anfangs mit einer Marke belegt ist. Die Relais-Station f ¨ ugt allerdings keine zus ¨ atz- liche Verz ¨ ogerung ein, weshalb die entsprechende Kante (v 0 ,v 3 ) nicht markiert ist. Weiterhin sieht man, dass jede Hardware-Komponente und jede Relais-Station erst eine Berechnung beenden muss, um die n ¨ achste Berechnung zu starten. Dies ist durch die Selbstschleifen mit je einer Anfangsmarkierung im markierten Graphen dargestellt. Schließlich sind die beschr ¨ ankten Kan ¨ ale durch R ¨ uckkanten modelliert. Somit kann ein latenzinsensitives System auch als die Implementierung eines markierten Graphen mit beschr ¨ ankten Kanalkapazit ¨ aten gesehen werden. Sobald das latenzinsensitive System als markierter Graph modelliert ist, l ¨ asst sich der Durchsatz auch ¨ uber Theorem 5.4.1 auf Seite 231 ermitteln. 6.6 Literaturhinweise Die ¨ Aquivalenzpr ¨ ufung kombinatorischer und sequentieller Schaltungen ist ausf ¨ uhrlich in dem Buch von Molitor und Mohnke [329] diskutiert. Entscheidungsdiagram- me f ¨ ur implizite ¨ Aquivalenzpr ¨ ufung auf der Logikebene sind in [135] beschrieben. Einen methodischen Vergleich von Entscheidungsdiagrammen findet man in [35]. Die implizite ¨ Aquivalenzpr ¨ ufung zwischen Architektur- und Logikebene wird in [65, 66] vorgestellt. Eine hierzu alternative Methode der R ¨ uckw ¨ artstraversierung wurde in [214] pr ¨ asentiert. Einen ¨ Uberblick ¨ uber Entscheidungsdiagramme und deren Einsatz zur impliziten ¨ Aquivalenzpr ¨ ufung auf Architekturebene findet sich in [224]. Verfahren zur expliziten ¨ Aquivalenzpr ¨ ufung werden h ¨ aufig auf der Logikebe- ne eingesetzt. Hierbei kommen zwei verwandte Verfahren, die automatische Test- fallgenerierung (engl. Automatic Test Pattern Generation, ATPG) oder SAT-Solver zum Einsatz. Der Hauptunterschied beider Verfahren liegt darin, dass SAT-Solver ¨ uberwiegend auf aussagenlogischen Formeln in konjunktiver Normalform arbeiten, w ¨ ahrend ATPG-Ans ¨ atze Boolesche Netzwerke als Datenstruktur verwenden. 6.6 Literaturhinweise 357 Weiterhin wurden SAT-Solver vor dem Hintergrund des automatischen Theorem- Beweisens entwickelt [129, 128], w ¨ ahrend ATPG-Ans ¨ atze im Kontext von Tests f ¨ ur die Chipfabrikation entstanden sind [1]. Ein Vergleich und eine ¨ Ubersicht beider Verfahren findet sich in [50, 137]. Der Einsatz von symbolischer Simulation zur Verifikation auf Logikebene ist ausf ¨ uhrlich in [45] beschrieben. Symbolische Simulation wurde erstmals im Jahr 1976 vorgestellt [260]. Obwohl zun ¨ achst zur Analyse von Software-Programmen gedacht, wurde das Potential f ¨ ur die Logiksimulation schnell erkannt. 1979 pr ¨ asen- tierte IBM den ersten symbolischen Simulator f ¨ ur Hardware [86], mit dem Ziel Mi- krocode f ¨ ur ihre Prozessoren zu verifizieren. Der erste symbolische Simulator mit Namen MOSSYM basierend auf einer eigenen Repr ¨ asentation f ¨ ur Boolesche Aus- dr ¨ ucke. MOSSYM wurde Mitte der 1980er Jahre von Bryant vorgestellt [61]. 1987 wurde eine Erweiterung von MOSSYM mit Namen COSMOS vorgestellt [64]. COS- MOS ist der erste symbolische Simulator der auf BDD-Repr ¨ asentationen arbeitet. In [117] wurde schließlich ein Verfahren vorgestellt, wie die Booleschen Formeln, die w ¨ ahrend der symbolischen Simulation hergeleitet wurden, direkt verwendet werden k ¨ onnen, um die Erreichbarkeitsmenge in sequentiellen Schaltungen zu bestimmen. Zur Speicherung der Erreichbarkeitsmenge werden typischerweise BDDs verwendet. Diese k ¨ onnen allerdings sehr groß werden, weshalb Verfahren entwickelt wurden, um die Gr ¨ oße der BDDs zu beschr ¨ anken [371, 81] und die Komplexit ¨ at der Bildberechnung zu reduzieren [80, 331]. Ein Verfahren, welches direkt auf Bitvekto- ren arbeitet und somit ohne rechenintensive Konstruktion von BDDs auskommt, ist in [199] vorgestellt. Die Ausnutzung struktureller ¨ Ahnlichkeiten w ¨ ahrend der ¨ Aquivalenzpr ¨ ufung auf der Logikebene basiert auf dem dekompositionalen Verfahren von Berman und Tre- villyan [43]. In diesem Verfahren werden interne Signale auf ihre ¨ Aquivalenz gepr ¨ uft. In [58] ist ein Verfahren zur Reduktion der Miter-Schaltung durch Signalsub- stitution vorgestellt. Bei diesem Verfahren geht durch die Signal-Substitution keine Information verloren. Dies gilt allerdings nicht bei der Schaltungspartitionierung, welche auf der Verwendung von Schnittpunkten als Eing ¨ ange basiert [273, 274]. Die Wahl der Schnittpunkte ist dabei nicht trivial [314, 145]. Verfahren zur strukturellen sequenziellen ¨ Aquivalenzpr ¨ ufung sind in [411, 146, 412] beschrieben. Eine Prozessorverifikation auf Basis der Theorie ” Gleichheit und uninterpretierte Funktionen“(engl. Equality and Uninterpreted Functions, EUF) wurde erstmals in [75] vorgestellt. Die Erweiterung auf die Theorie ” Positive Gleichheit und uninterpretierte Funktionen“(engl. Positive EUF, PEUF ) wird in [67] ausgiebig diskutiert. Hierbei wird eine Unterscheidung von Gleichungen in positive und generelle Glei- chungen vorgenommen. Positive Gleichungen d ¨ urfen nicht negiert auftreten, d. h. sie d ¨ urfen insbesondere nicht als Bedingung in ITE-Operationen auftreten. Positi- ve Gleichungen lassen sich bei der Reduktion auf Aussagenlogik speziell behandeln und f ¨ uhren zu einfacheren Strukturen der aussagenlogischen Formeln, was in der Verifikation ausgenutzt werden kann. Die Verifikation superskalarer Prozessoren ist in [71] beschrieben. Die grundle- gende Idee ist die Dekomposition des kommutativen Diagramms in drei kommutati- ve Diagramme, was es erleichtert, die symbolische Simulation der Implementierung 358 6 Hardware-Verifikation und Spezifikation aufeinander abzustimmen. Weiterf ¨ uhrende Arbeiten zur ¨ Aquiva- lenzpr ¨ ufung superskalarer Prozessoren mit [453] und ohne Sprungvorhersage [452] basieren auf PEUF. Die Verwendung eines effizienten Speichermodells in [68] erlaubt es, die ¨ Aquivalenz anhand von Speicherzugriffen der Mikroarchitektur und der ISA in der symbolischen Simulation zu pr ¨ ufen. Die Erweiterung, diese Speichermo- delle auch f ¨ ur die funktionalen Einheiten zu verwenden, ist in [451] vorgestellt. In [403] ist die Erweiterung des Ansatzes aus [75] f ¨ ur Mikroarchitekturen mit dynamischer Instruktionsablaufplanung beschrieben. Ein weitergehender Ansatz, der in [40] beschrieben ist, basiert auf Modellpr ¨ ufung. Dieser Ansatz verwendet Ergebnisse aus [319] zur Verifikation des Algorithmus von Tomasulo. Funktionale Eigenschaftspr ¨ ufung f ¨ ur Hardware ist heutzutage ¨ uberwiegend simulativ oder SAT-basiert. Die Synthese von Monitoren aus PSL-Zusicherungen f ¨ ur die Hardware-Verifikation ist in [333] f ¨ ur die schwachen PSL-Operatoren und in [335] f ¨ ur die starken PSL-Operatoren beschrieben. In letzterem Ansatz erfolgt auch die Strukturierung eines elementaren PSL-Monitors in einen Block zur Zeitfenster- generierung und einen Block f ¨ ur die Evaluierung. Dabei zeigen die Autoren die Kor- rektheit des Ansatzes mittels eines Theorembeweisers. Einen alternativen Ansatz, basierend auf sog. Sequenzautomaten, haben Boul ´ e und Zilic in [53, 55] beschrieben. Sequenzautomaten k ¨ onnen, im Gegensatz zu herk ¨ ommlichen endlichen Automaten, ebenfalls die starken PSL-Operatoren behandeln. Die Synthese f ¨ ur die Hardware- Verifikation ist in [54] dargestellt. Verschiedene kommerzielle Werkzeuge unterst ¨ utzen Zusicherungssprachen als Eingabe f ¨ ur funktionale Eigenschaftspr ¨ ufung: RuleBase von der Firma IBM ist ein Modellpr ¨ ufer, welcher PSL unterst ¨ utzt [384]. Incisive Formal Verifier von der Fir- ma Cadence unterst ¨ utzt neben PSL auch SystemVerilog Assertions [238]. Solidify, ein Produkt der Firma Averant, unterst ¨ utzt ebenfalls PSL und SVA [404]. Dane- ben unterst ¨ utzen viele RTL-Simulatoren ebenfalls Zusicherungssprachen zur simu- lativen ¨ Uberpr ¨ ufung von Zusicherungen. VCS, ein Simulator der Firma Synopsys, unterst ¨ utzt SVA als Eingabesprache [450]. ModelSim von der Firma Mentor Gra- phics [328] unterst ¨ utzt PSL. Incisive Design Team Simulator von der Firma Cadence wiederum unterst ¨ utzt beide M ¨ oglichkeiten [237]. Schließlich erlaubt das Werkzeug FoCs [167] von der Firma IBM die automatische Generierung von Monitoren in VHDL, Verilog oder SystemC aus PSL-Zusicherungen. Die SAT-basierte Modellpr ¨ ufung wurde erstmals im Jahr 1999 von Biere et al. vorgestellt [49, 48]. Deren Anwendung auf Schaltungen ist ausf ¨ uhrlich in [174] dargestellt. Darin werden im Wesentlichen drei Verfahren vorgeschlagen, um die Ef- fizienz des Standard-Verfahrens zu verbessern: 1) Dynamische Schaltungsvereinfa- chungen helfen, das iterative Schaltungsmodell m ¨ oglichst klein zu halten und somit die Variablenanzahl bei der ¨ Ubersetzung in eine aussagenlogische Formel zu verkleinern [52, 465, 173]. 2) Iterative Lernverfahren verk ¨ urzen die Zeit zur Ve- rifikation durch Wiederverwendung von Ergebnissen von vorherigen L ¨ aufen des SAT-Solvers f ¨ ur kleinere Schranken [401, 463]. 3) Die ¨ Ubersetzung von Schal- tung und temporaler Formel in eine aussagenlogische Formel erfolgt typischerweise monolithisch, d. h. die gesamte aussagenlogische Formel wird f ¨ ur eine gegebene Schranke k erzeugt und auf Erf ¨ ullbarkeit unter Verwendung eines Standard-SAT- 6.6 Literaturhinweise 359 Solvers ¨ uberpr ¨ uft. Die inkrementelle ¨ Ubersetzung von LTL-Formeln hilft, Teile der bereits erstellten aussagenlogischen Formel wiederzuverwenden [176]. Eine Erwei- terung der SAT-basierten Modellpr ¨ ufung zur Behandlung von Speichermodulen ist in [175, 177] beschrieben. Dort werden neben den eingebetteten Speichern mit einem Lese-/Schreibport auch Erweiterungen f ¨ ur Speicher mit mehreren Lese-/Schreibports vorgestellt. Der vorgestellte Ansatz zur effizienten Behandlung von Wortbreiten basiert auf den Arbeiten von Bryant et al. [60]. Eine Vielzahl weiterer Ans ¨ atze f ¨ ur Entschei- dungsprozeduren f ¨ ur Bitvektor-Arithmetik sind in der Literatur bekannt. Das engl. bit blasting ist das weit verbreitetste, bei dem die Bitvektor-Operationen durch Boo- lesche Formeln ersetzt werden. Ein Beispiel hierf ¨ ur ist der Cogent-Ansatz [114]. Verbesserungen werden in CVC-Lite erzielt, indem vor dem eigentlichen bit blasting eine Normalisierungsschritt erfolgt [179]. Ein analoger Ansatz wird in [460, 459] beschrieben, bei dem Schaltungen normalisiert mittels Partialproduktgeneratoren, Ad- ditionsnetzwerken und Komparatoren repr ¨ asentiert werden. Der Normalisierungs- schritt hilft dabei, die sp ¨ ater zu generierende SAT-Instanz m ¨ oglichst kein zu halten. STP [ 82] verwendet Array-Optimierung in Kombination mit logischen und arith- metischen Vereinfachungen. Fr ¨ uhere Arbeiten basieren auf dem Ansatz von Sho- stak. Beispiele hierf ¨ ur sind [124, 31]. Ans ¨ atze, welche die Behandlung von Modulo- Arithmetik betrachten, finden sich in [230, 59, 353]. Die Zeitanalyse f ¨ ur synchrone Schaltungen erfolgt auf der Logikebene typischerweise durch eine statische Zeitanalyse. Aufgrund der technologiebedingten Asym- metrien bei Verz ¨ ogerungszeiten beim Wechsel der Ausg ¨ ange von Flip-Flops und Lo- gikgattern von logisch T zu F bzw. umgekehrt, kann eine genauere Absch ¨ atzung auf Basis einer Simulation erfolgen, die als dynamische Zeitanalyse bezeichnet wird. Diese liefert allerdings keinerlei Garantien f ¨ ur harte Echtzeitanforderungen und ist dar ¨ uber hinaus auch sehr zeitintensiv. Diskussionen technologiespezifischer Verz ¨ ogerungszeiten finden sich z. B. in [438, 311]. Die Zeitanalyse auf Architekturebene besteht im Wesentlichen darin, den imple- mentierten statischen Ablaufplan im Steuerwerk der Schaltung zu analysieren. Ver- fahren zur Optimierung der Ablaufpl ¨ ane bez ¨ uglich Latenz und Durchsatz kann man in [426] finden. Eine spezielle Klasse synchroner Schaltungen auf Architekturebe- ne sind sog. latenzinsensitive Systeme. Ein erstes latenzinsensitives Systeme wurde unter diesem Namen in [83] vorgestellt. Die Theorie zu latenzinsensitiven Syste- men wurde erstmals in [84] vorgestellt. Um ein latenzinsensitives System zu reali- sieren, werden f ¨ ur jeden Kommunikationskanal zwischen Hardware-Komponenten zwei neue Verbindungen zwischen diesen Komponenten eingef ¨ ugt. Eine Verbindung besitzt die selbe Richtung wie der Kommunikationskanal und dient zur Anzeige, ob die Daten im Kanal informativ oder nichtinformativ sind. Die zweite Verbindung verl ¨ auft in entgegengesetzter Richtung und zeigt back pressure an. Eine erste Zeit- analyse f ¨ ur latenzinsensitive Systeme wurde in [85] vorgestellt, vernachl ¨ assigte aber back pressure. Eine Erweiterung zur Ber ¨ ucksichtigung dieser Effekte ist in [309] vorgestellt. 7 Software-Verifikation System Logik Software Hardware Implementierung Spezifikation ArchitekturModul Block Abb. 7.1. Software-Verifikation In diesem Kapitel werden wichtige Methoden zur Verifikation von Software beschrieben. Zun ¨ achst werden Verfahren zur ¨ Aquivalenzpr ¨ ufung auf Blockebene pr ¨ asentiert. Dabei wird die Verifikation sowohl von Assembler- als auch von C- Programmen, die typischen Einschr ¨ ankungen f ¨ ur eingebettete Software unterliegen, betrachtet. Danach werden Verfahren zur Testfallgenerierung f ¨ ur simulative Verifi- kationsmethoden f ¨ ur Software zusammen mit den zugeh ¨ origen ¨ Uberdeckungsma- ßen vorgestellt. Anschließend werden formale Methoden zur funktionalen Eigen- schaftspr ¨ ufung von Software pr ¨ asentiert. Schließlich folgen Verfahren zur Verifikati- on des Zeitverhaltens eingebetteter Software. Dabei wird zun ¨ achst die Absch ¨ atzung des Zeitverhaltens auf Blockebene und anschließend der Einfluss dynamischer Ab- laufplanungsverfahren auf die Antwortzeit von Prozessen betrachtet. C. Haubelt, J. Teich, Digitale Hardware/Software-Systeme, eXamen.press, DOI 10.1007/978-3-642-05356-6 7, c  Springer-Verlag Berlin Heidelberg 2010 362 7 Software-Verifikation 7.1 Formale ¨ Aquivalenzpr ¨ ufung eingebetteter Software Das Problem der ¨ Aquivalenzpr ¨ ufung von zwei Programmen ist im Allgemeinen nicht entscheidbar. Aus diesem Grund wird ein Großteil der ¨ Aquivalenzpr ¨ ufung von Soft- ware simulativ durchgef ¨ uhrt, wobei ein Programm, welches durch Transformation aus einem Referenzprogramm entstanden ist, mit dem Referenzprogramm vergli- chen wird. Simulative ¨ Aquivalenzpr ¨ ufung ist allerdings unvollst ¨ andig, weshalb im Allgemeinen lediglich die Anwesenheit von Fehlern, nicht aber deren Abwesenheit gezeigt werden kann. Die Erzeugung geeigneter Testf ¨ alle wird in Kapitel 7.2 diskutiert. W ¨ ahrend die ¨ Aquivalenz von Programmen im Allgemeinen nicht gezeigt werden kann, kann durch Einschr ¨ ankungen eine Klasse an Programmen definiert werden, f ¨ ur welche dies noch formal m ¨ oglich ist. Eingebettete Software unterliegt oftmals ge- nau solchen Einschr ¨ ankungen, weshalb die formale ¨ Aquivalenzpr ¨ ufung eingebetteter Software in den letzten Jahren neue Aufmerksamkeit erhalten hat. Einige wichtige Ans ¨ atze werden im Folgenden betrachtet. ¨ Ahnlich wie Hardware, wird eingebettete Software starken Optimierungen unterzogen. Dabei muss die Software Anforderungen an ihr Laufzeitverhalten entspre- chen, aber auch weitere nichtfunktionale Eigenschaften, z. B. bez ¨ uglich der maximalen Leistungsaufnahme und ihres Speicherbedarfs, erf ¨ ullen. Ein Programm, welches lediglich ein paar Bytes mehr an Speicher ben ¨ otigt als eine Alternative, erfordert eventuell die Verwendung eines gr ¨ oßeren und teureren Speichers. Auch ein Pro- gramm, welches nur ein bisschen langsamer ist als die Vorgabe, kann inakzeptabel sein. Aus diesem Grund wird eingebettete Software h ¨ aufig einer sehr starken Op- timierung unterzogen. Das kann soweit gehen, dass sogar compilierte Programme nochmals manuell verbessert werden. Daneben wird eingebettete Software h ¨ aufig f ¨ ur Spezialprozessoren ¨ ubersetzt. Diese wiederum sind selbst ebenfalls hoch optimiert, z. B. im Hinblick auf Leis- tungsaufnahme, Kosten und Geschwindigkeit. Spezialprozessoren besitzen dabei meist Spezialinstruktionen und mehrere parallel arbeitende funktionale Einheiten im Datenpfad. Die I mplementierungsdetails sind dabei nicht immer vor dem Program- mierer verborgen und m ¨ ussen ber ¨ ucksichtigt werden. Dies bedeutet einerseits, dass eingebettete Software stark optimiert werden kann, andererseits bedeutet dies große Herausforderungen bei der Codegenerierung, -optimierung und -verifikation. Schließlich sei noch erw ¨ ahnt, dass Fehler in eingebetteter Software weniger tole- riert werden als in Desktop-Software. Dies liegt zum einen daran, dass das Einspielen einer neuen Software-Version im Betrieb sehr kostspielig oder auch unm ¨ oglich sein kann. Zum anderen k ¨ onnen die Folgen eines Fehlers bei eingebetteten Systemen, die stark mit ihrer Umwelt interagieren, katastrophale Folgen haben. Aus diesen Gr ¨ unden gewinnt die Verifikation eingebetteter Software zunehmend an Bedeutung. 7.1.1 ¨ Aquivalenzpr ¨ ufung von Assemblerprogrammen Im Folgenden wird ein Ansatz zur ¨ Aquivalenzpr ¨ ufung von Assemblerprogrammen von Currie et al. [122] basierend auf symbolischer Simulation vorgestellt. Das Ver- 7.1 Formale ¨ Aquivalenzpr ¨ ufung eingebetteter Software 363 fahren eignet sich lediglich dazu, kleinere Programmsegmente miteinander zu ver- gleichen. Aber selbst f ¨ ur kleinere Programmsegmente gilt, dass deren ¨ Aquivalenz nicht offensichtlich sein muss, weshalb sich eine entsprechende Pr ¨ ufung und deren Automatisierung an dieser Stelle lohnt. Beispiel 7.1.1. Betrachtet wird das folgende Assemblerprogramm f ¨ ur einen digitalen Signalprozessor aus [123]: 1 msm dx, a0, a1 2 bge OK 3 add dx, cx 4 OK: mov (x0++1), dx Die erste Instruktion multipliziert den Inhalt von Register a0 mit dem Inhalt des Registers a1. Das Ergebnis wird zu dem Inhalt in Register dx addiert und dort ge- speichert. Die Instruktion setzt dabei Status-Register. Damit verzweigt die folgende Instruktion (bge) zu der Marke OK, wenn die vorherige Multiplikation zu einem nichtnegativen Ergebnis gef ¨ uhrt hat. Die add-Instruktion addiert den Inhalt von Re- gister cx zu dem Inhalt in Register dx. Das Ergebnis steht anschließend im Regis- ter dx. Schließlich wird der Inhalt des Registers dx in den Speicher geschrieben. Die verwendete Adresse ergibt sich dabei aus dem Inhalt des Indexregisters x0, der inkrementiert wird, um auf die n ¨ achste Speicheradresse zu zeigen. Der Kontroll- Datenflussgraph des Assemblerprogramms ist in Abb. 7.2 zu sehen. Symbolische Simulation und uninterpretierte Funktionen Das hier vorgestellte Verfahren basiert auf symbolischer Simulation. Ausgehend von zwei Programmsegmenten, werden durch symbolische Simulation f ¨ ur diese Re- pr ¨ asentanten erstellt. Basierend auf den beiden resultierenden Repr ¨ asentanten wird anschließend die ¨ Aquivalenz gepr ¨ uft. Wie bei der symbolischen Simulation von Hardware (Boolesche Netzwerke) kann auch Software symbolisch simuliert werden. Anstatt jedes Signal der Mikroar- chitektur, die das Assemblerprogramm ausf ¨ uhrt, mit einem Wert zu belegen, werden bei der symbolischen Simulation von Assemblerprogrammen in jeder Programmzei- le die neuen Werte der Register und Speicher der Mikroarchitektur bestimmt. Um die aus der ¨ Aquivalenzpr ¨ ufung f ¨ ur Hardware bekannte symbolische Simulation verwenden zu k ¨ onnen, ist es m ¨ oglich, die Registerinhalte durch symbolische Bitvektoren zu repr ¨ asentieren. Der Vorteil hierbei w ¨ are, dass der Datenpfad des verwendeten Pro- zessors mit in der Verifikation ber ¨ ucksichtigt wird. Der Nachteil ergibt sich aus der exponentiell wachsenden Gr ¨ oße der Repr ¨ asentation, die hierbei f ¨ ur die Booleschen Funktionen entsteht. Dies gilt insbesondere f ¨ ur Software, die intensiv Operationen wie Multiplikation und Division durchf ¨ uhrt. Aus diesem Grund erfolgt die symbolische Simulation auf Basis beliebiger Da- tentypen. Dies erfolgt mit Hilfe eines symbolischen ISA-Simulators (engl Instructi- on Set Architecture). Einige Funktionen, wie Addition oder Sprungbefehle, k ¨ onnen durch arithmetische und logische Operatoren erfasst werden. Kommen komplexere Funktionen hinzu, so bietet es sich an, Symbole f ¨ ur sog. uninterpretierte Funktionen . Ab- laufplanungsverfahren auf die Antwortzeit von Prozessen betrachtet. C. Haubelt, J. Teich, Digitale Hardware/Software-Systeme, eXamen.press, DOI 10.1007/978-3-642-05356-6 7, c  Springer-Verlag. dieser Stelle lohnt. Beispiel 7.1.1. Betrachtet wird das folgende Assemblerprogramm f ¨ ur einen digitalen Signalprozessor aus [123]: 1 msm dx, a0, a1 2 bge OK 3 add dx, cx 4 OK: mov (x0++1), dx Die