Digitale Hardware/ Software-Systeme- P25 ppsx

474 8 Systemverifikation Die ¨ Ubergangsmarkierungsfunktion L R : R → 2 V R gibt an, f ¨ ur welchen Zustands ¨ uber- gang welches Ereignis v ∈ V R gilt. Dies ist gleichbedeutend mit: ” Das Ereignis ˆ L R (s,s  ) gilt beim Zustands ¨ ubergang (s,s  )“, wobei ˆ L R (s,s  ) :=  v∈L R (s,s  ) v ∧  v∈(V R \L R (s,s  )) ¬v Daneben kann jede SE-LTL-Formel ϕ ¨ uber V S und V R auch als LTL-Formel ϕ LT L ¨ uber V S ∪V R interpretiert werden. Dabei sind ϕ und ϕ LT L syntaktisch identisch, un- terscheiden sich aber semantisch. Da jede LTS mit Definition 8.1.18 als B ¨ uchi-Automat interpretiert werden kann, kann, wie im Fall der LTL-Modellpr ¨ ufung, der Produktautomat aus einer LTS und ei- nem B ¨ uchi-Automaten gebildet werden. Sei B =(S B ,R B ,L B ,A B ) ein B ¨ uchi-Automat mit Anfangszust ¨ anden S B,0 und M =(S,R,L S ,L R ) eine attributierte temporale Struk- tur mit Anfangszust ¨ anden S 0 .DerB ¨ uchi-Automat verwendet die atomaren Aussagen V B = V S ∪V R . Der Produktautomat M p := M ⊗B =(S p ,R p ,L p ,A p ) ist definiert durch: • S p = {(s, s B ) ∈ S×S B | ˆ L S (s) ⇒∃V R : L B (s B )} (dies beschreibt die Formel L B (s B ), in der alle Variablen v ∈ V R existentiell quantifiziert wurden), • ((s,s B ),(s  ,s  B )) ∈ R p , genau dann, wenn ∃v ∈ V R : s v −→ s  ∧ (s B ,s  B ) ∈ R B ∧ ( ˆ L S (s) ∧ ˆ L R (s,s  )) ⇒ L B (s B ) und • (s,s B ) ∈ A p , genau dann, wenn s B ∈ A B . Die Anfangszust ¨ ande ergebenen sich aus den Paaren der Anfangszust ¨ ande beider Automaten. Da SE-LTL-Formeln syntaktisch identisch mit LTL-Formeln sind, lassen sich SE-LTL-Formeln als B ¨ uchi-Automaten modellieren. Somit kann nun die SE-LTL- Modellpr ¨ ufung, wie die LTL-Modellpr ¨ ufung, als Test auf eine leere Sprache des Produktautomaten umformuliert werden. Theorem 8.1.1. F ¨ ur eine LTS M und eine SE-LTL-Formel ϕ gilt: M |= ϕ ⇔L(M ⊗ B ¬ ϕ LT L )=∅ Die Sprache des Produktautomaten ist definiert, wie in Abschnitt 5.2.2 beschrie- ben. Abstraktion Neben der oben beschriebenen Abbildung von SystemC-Modellen auf parallele Kompositionen von LTS lassen sich weitere Abstraktionen durchf ¨ uhren, welche die Verifikationszeit verk ¨ urzen k ¨ onnen. Hardware/Software-Partitionierung Durch Hardware/Software-Partitionierung kann die Modellkomplexit ¨ at deutlich re- duziert werden. Hierzu werden die SystemC-Prozesse in kombinatorische, getaktete und uneingeschr ¨ ankte Threads klassifiziert und bei der Generierung der LTS geson- dert behandelt. Kombinatorische Threads besitzen die Eigenschaft, dass diese 8.1 Funktionale Eigenschaftspr ¨ ufung von SystemC-Modellen 475 • Sensitiv auf alle Eing ¨ ange sind, • nicht mit dem Taktsignal verbunden sind, • keine wait-Anweisung enthalten und • keine Schleifen ohne konstante Grenzen enthalten. Kombinatorische Threads werden in eine Formel f ¨ ubersetzt und aus dem Modell entfernt. Jedes Mal, wenn Ausgangsvariablen des kombinatorischen Threads gelesen werden, werden diese mit der Formel f beschr ¨ ankt. Getaktete Threads besitzen die Eigenschaft, dass diese • Sensitiv auf eine positive oder negative Taktflanke sind, • keine wait-Anweisung mit Argumenten enthalten und • jede Schleife ohne konstante Grenze mindestens eine wait-Anweisung enth ¨ alt. Getaktete Threads k ¨ onnen in endliche Automaten ¨ ubersetzt werden. Hierf ¨ ur wird f ¨ ur den Start, das Ende und jede wait-Anweisung ein Zustand generiert. Die Zu- stands ¨ uberg ¨ ange werden entsprechend aus den Pfaden im Kontroll-Datenflussgra- phen des Prozesses erzeugt. Jede τ -Transition der LTS, die diesen Prozess repr ¨ asen- tiert, entspricht einem Zustands ¨ ubergang in dem endlichen Automaten. W ¨ ahrend kombinatorische und getaktete Threads als ungetaktete und getaktete Hardware-Komponenten angesehen werden k ¨ onnen, modellieren uneingeschr ¨ ank- te Threads Software-Prozesse. Uneingeschr ¨ ankte Threads unterliegen erwartungs- gem ¨ aß keinen Einschr ¨ ankungen und lassen somit bei der Abbildung auf LTS auch keine Optimierungen zu. SAT-basierte Pr ¨ adikatenabstraktion SystemC unterst ¨ utzt unterschiedliche Datentypen. Um einen Zugang zum Hardware- Entwurf zu erleichtern, werden auch Bitvektoren unterst ¨ utzt. Die Operationen, die auf Bitvektoren arbeiten, vergr ¨ oßern allerdings den Zustandsraum. Eine m ¨ ogliche Abstraktion kann in diesem Fall durch den Einsatz von arithmetischen Operationen erreicht werden. Erfolgt die Pr ¨ adikatenabstraktion durch SAT-Solver (siehe Abschnitt 7.3.3), so kann die Abstraktion nach folgender Formeln realisiert werden: ˆs A −→ ˆs  ⇔∃s,s  ∈ S : s A −→ s  ∧ α (s)= ˆs ∧ α (s  )= ˆs  Dabei ist α die Funktion zur Zustandsabstraktion und S der globale Zustand der par- allelen Komposition der LTS. Die Formel sagt aus, dass ein abstrakter Zustands ¨ uber- gang (ˆs, ˆs  ) unter den Ereignissen a ∈ A existiert, sofern im konkreten Modell ein Zustands ¨ ubergang (s,s  ) unter den selben Ereignissen existiert und der Start- und Endzustand Abstraktionen der konkreten Start- und Endzust ¨ ande sind. Thread-modulare Abstraktion Die Repr ¨ asentation von SystemC-Modellen durch LTS erfolgt, indem f ¨ ur jeden SystemC-Prozess eine LTS generiert wird und diese anschließend parallel kompo- niert werden. Es kann nun eine Abstraktion des gesamten Modells dadurch erreicht 476 8 Systemverifikation werden, dass zun ¨ achst die einzelnen LTS abstrahiert und anschließend parallel kom- poniert werden. Formal bedeutet dies: Theorem 8.1.2. Sei M  die parallele Komposition von n LTS, d. h. M  = M 1 ··· M n . Sei weiterhin ˆ M i die Abstraktion von M i und ˆ M  die Abstraktion von M  . Dann gilt: ˆ M  ≡ ˆ M 1 ··· ˆ M n Mit anderen Worten: Die Abstraktion der parallelen Komposition der konkreten LTS M 1 bis M n ist ¨ aquivalent zur parallelen Komposition der abstrakten LTS ˆ M 1 bis ˆ M n . Dies bedeutet aber auch, dass die Projektion ˜s|M i eines Pfades ˜s = s 0 ,e 0 ,s 1 ,e 1 ,  in der parallelen Komposition M  der LTS M 1 bis M n auf eine einzelne LTS M i eine Abstraktion von M  ist, d. h. ( ˜s|M i )  M  Dabei gilt die Projektion ˜s|M i einer Teilsequenz ˆ ˜s von ˜s, die man durch Entfernen der Paare (a j ,s j+1 ) erh ¨ alt, f ¨ ur alle a j ∈ V r,i . Die beschriebenen Abstraktionen k ¨ onnen zu falschnegativen Ergebnissen f ¨ uhren, weshalb f ¨ ur die Verifikation von SystemC-Modellen eine Abstraktionsverfeinerung eingesetzt wird [271]. Die Abstraktionsverfeinerung wird dabei durch die Gegenbei- spiele gesteuert, d. h., ergibt die Modellpr ¨ ufung einer funktionalen Eigenschaft ein Negativergebnis, wird ein Gegenbeispiel generiert. L ¨ asst sich dieses Gegenbeispiel im urspr ¨ unglichen SystemC-Modell jedoch nicht simulieren, so muss das Modell geeignet verfeinert werden. 8.1.3 Formale Modellpr ¨ ufung von Transaktionsebenenmodellen Transaktionsebenenmodelle (engl. Transaction Level Model, TLM) werden zuneh- mend als Strukturmodell auf Systemebene eingesetzt. Dabei handelt es sich um eine Netzliste von Prozessoren, Hardware-Beschleunigern, Bussen und Speichern. Die Umsetzung erfolgt dabei h ¨ aufig in SystemC [352]. Transaktionen In TLMs werden Transaktionen als Abstraktion der Kommunikation zwischen ne- benl ¨ aufigen Prozessen verwendet. Transaktionen k ¨ onnen entweder atomar oder un- terbrechbar sein. Atomare Transaktionen werden in SystemC-TLM als blockierend, unterbrechbare als nichtblockierend bezeichnet. Basierend auf blockierenden und nichtblockierenden Transaktionen definiert SystemC-TLM unterschiedliche Codie- rungsrichtlinien, die als schwach zeitbehaftet (engl. Loosely Timed, LT), approxi- miert zeitbehaftet (engl. Approximately Timed, AT) und zyklenakkurat (engl. Cycle Accurate, CA) bezeichnet werden. In einem LT-TLM werden ausschließlich blockierende Transaktionen (die Sys- temC-Methode b transport) verwendet, die durch einen Start- und einen Endzeit- punkt charakterisiert sind. Diese beiden Zeitpunkte k ¨ onnen aber durchaus identisch 8.1 Funktionale Eigenschaftspr ¨ ufung von SystemC-Modellen 477 sein, d. h. die Transaktion hat keine Zeit ben ¨ otigt. Ein AT-TLM kann mehrere Trans- aktionsphasen enthalten und erlaubt somit eine detailliertere Modellierung, etwa von Ressourcenbeschr ¨ ankungen. Dies wird durch nichtblockierende Transaktionen (die SystemC-Methode nb transport) erreicht, f ¨ ur die SystemC-TLM vier cha- rakteristische Zeitpunkte definiert: begin request, end request, begin response und end response. Die Definition eigener Zeitpunkte f ¨ ur Protokolle mit anderen Phasen ist aber auch m ¨ oglich. CA-TLMs sind vergleichbar mit Hardware-Beschreibungen auf der Registertransferebene und verfeinern AT-TLM mittels eines Taktsignals. AT- und CA-TLMs stellen also Verfeinerungen von LT-TLMs dar und werden aufgrund der h ¨ oheren Genauigkeit vor allem bei der Verifikation des Zeitverhaltens eingesetzt. F ¨ ur die Verifikation funktionaler Eigenschaften werden im Folgenden lediglich LT- TLMs betrachtet, die mit blockierenden Transaktionen auskommen, was die Notati- on vereinfacht. Außerdem soll die Kommunikation zeitfrei erfolgen. Schwach zeitbehaftete Transaktionsebenenmodelle bestehen aus nebenl ¨ aufigen Prozessen, die ¨ uber blockierende Transaktionen miteinander kommunizieren. Die Prozesse k ¨ onnen dabei an den Transaktionen blockieren, z. B. aufgrund nicht vor- handener Daten. Zentral f ¨ ur die Verifikation von TLMs ist die korrekte Zusammen- arbeit (Kommunikation) dieser Prozesse. Um funktionale Eigenschaften eines TLM als Anforderungen zu formulieren, m ¨ ussen also die zeitlichen Zusammenh ¨ ange der Transaktionen spezifiziert werden. Da es in LT-TLMs im Allgemeinen kein Takt- signal gibt, m ¨ ussen diese zeitlichen Zusammenh ¨ ange relativ zueinander spezifiziert werden. Beispiel 8.1.8. Abbildung 8.11 zeigt m ¨ ogliche relative zeitliche Zusammenh ¨ ange zwischen drei blockierenden Transaktionen t 1 , t 2 und t 3 . start bezeichnet dabei den Startzeitpunkt einer Transaktion, end den Endzeitpunkt. Man sieht, dass Transakti- on t 3 nach Transaktion t 2 und Transaktion t 1 startet, da t 3 .start > t 2 .start > t 1 .start. Obwohl Transaktion t 2 nach Transaktion t 1 startet, wird diese fr ¨ uher beendet. F ¨ ur die Formulierung von funktionalen Eigenschaften ist es manchmal notwendig, den Abstand zweier Ereignisse zu bestimmen. Ohne Taktsignal kann dies nur relativ zu- einander erfolgen. Beispielsweise ist der Abstand zwischen den Ereignissen t 1 .start und t 1 .end vier, da drei Ereignisse zwischen diesen liegen. Zeit t 1 .start t 1 .end t 3 .endt 2 .endt 3 .startt 2 .start t 1 t 2 t 3 Abb. 8.11. Drei blockierende Transaktionen in einem LT-TLM [143] 478 8 Systemverifikation M ¨ oglichen Relationen zwischen zwei Transaktionen in einem LT-TLM sind in Abb. 8.12 zu sehen. Diese k ¨ onnen lediglich anhand der Position eines Start- oder Endeereignisses einer Transaktion bez ¨ uglich anderer Ereignisse definiert werden. Abbildung 8.12a) zeigt, dass Transaktion t 1 und Transaktion t 2 gleichzeitig statt- finden, da t 1 .start = t 2 .start und t 1 .end = t 2 .end. In Abb. 8.12b) ist der Fall zu se- hen, dass die Transaktion t 2 nach t 1 startet, beide aber gleichzeitig beendet werden. Abbildung 8.12c) zeigt den Fall, dass die Transaktionen t 1 und t 2 gleichzeitig star- ten, t 1 aber fr ¨ uher beendet wird, d. h. t 1 .start = t 2 .start ∧ t 1 .end < t 2 .end. Schließ- lich zeigt Abb. 8.12d), dass Transaktion t 1 und t 2 direkt aufeinander folgen, d. h. t 1 .end = t 2 .start. t 1 .end t 2 .start t 2 .end a) Zeit b) t 1 .end t 2 .end t 1 .start t 2 .start t 1 .end c) d) t 1 .start t 1 .end t 2 .start t 1 .start t 2 .start t 2 .end t 1 .start t 2 .end t 1 t 2 t 1 t 2 t 2 t 1 t 1 t 2 Abb. 8.12. Beziehungen zwischen Transaktionen in LT-TLMs [143] Formalisierung von LT-TLMs Die Formalisierung eines SystemC-TLMs erfolgt ¨ ahnlich dem in Abschnitt 8.1.2 be- schriebenen Ansatz f ¨ ur SystemC-Modelle. Da die Synchronisation jetzt nicht mehr ausschließlich ¨ uber Ereignisse, sondern ¨ uber blockierende Transaktionen erfolgt, wird die Kommunikation ebenfalls formal modelliert. Um den Zustandsraum eines TLM effizient zu modellieren, wird in [345, 347] ein Modell kommunizierender end- licher Automaten vorgestellt. Definition 8.1.19 (Transaktionsebenenmodell). Ein Transaktionsebenenmodell ist ein Tripel (TM I ,TM T ,T ), wobei • TM I dieMengeansog.Initiatormodulen, • TM T dieMengeansog.Targetmodulen, und • T ⊆ M I × M T die Menge an Transaktionen SystemC-Module werden in einem TLM als Initiator- oder Targetmodul klassi- fiziert. Dabei kann ein Modul tm auch beides sein, d. h. tm ∈ TM I ∧tm ∈ TM T .Ein Initiatormodul enth ¨ alt einen SystemC-Prozess, wobei die Diskussion auf SystemC- Threads reduziert werden kann. Targetmodule implementieren die Transaktionen 8.1 Funktionale Eigenschaftspr ¨ ufung von SystemC-Modellen 479 b transport, weshalb Transaktionen mit Targetmodulen assoziiert werden. An- dererseits k ¨ onnen Transaktionen lediglich von Initiatormodulen aufgerufen wer- den. Welches Initiatormodul welche Transaktion auf welchem Targetmodul aufrufen kann, ist als Paar in der Transaktion gespeichert. Targetmodule, die keine Initiator- module sind, enthalten keinen SystemC-Thread. Beispiel 8.1.9. Ein Beispiel f ¨ ur ein SystemC-TLM ist in Abb. 8.13 dargestellt. Es besteht aus sechs Modulen (zwei CPUs, zwei Speicher, ein Bus und ein Arbiter). Die Menge der Initiatormodule TM I besteht aus den beiden CPUs und dem Bus. Die Menge der Targetmodule TM T besteht aus den beiden Speichern, dem Bus und dem Arbiter. Da die beiden Speichermodule und der Arbiter keine Initiatormodule sind, besitzen sie auch keinen SystemC-Thread. Module mit SystemC-Thread sind eingef ¨ arbt. Speicher 1 Speicher 2 CPU 1 CPU 2 Bus Arbiter Target Target Initiator Initiator Target Target Initiator Initiator Initiator Target Abb. 8.13. SystemC-TLM [346] Zur Konstruktion des formalen Modells wird jedes Modul tm i einzeln betrach- tet und in einem kommunizierenden endlichen Automaten ¨ ubersetzt. Analog zu dem Ansatz in Abschnitt 8.1.2 muss der Zustandsraum modelliert werden, in- dem die Variablenbelegungen, die Programmz ¨ ahler der Prozesse und die Prozess- zust ¨ ande erfasst werden. Die Programmz ¨ ahler der Prozesse sowie die Variablen- belegungen lassen sich als endliche Automaten M PC,i und M PV,i modellieren (sie- he Abschnitt 2.2.2). Enth ¨ alt ein Modul keinen SystemC-Thread, wird kein endli- cher Automat f ¨ ur den Programmz ¨ ahler ben ¨ otigt. Weiterhin wird f ¨ ur jede Transaktion t ∈{t  =(tm,tm  ) ∈ T | tm = tm i } ein Initiator-Automat M I,t und f ¨ ur jede Transakti- on t ∈{t  =(tm,tm  ) ∈ T | tm  = tm i } ein Target-Automat M T,t gebildet. Dies ist in Abb. 8.14 zu sehen. Weiterhin zeigt Abb. 8.14 das Zusammenspiel der kommunizierenden endlichen Automaten. Der Automat M PC,1 , der einen SystemC-Thread modelliert, kann somit ¨ Anderungen an der Variablenbelegung vornehmen, indem er mit dem Automaten 480 8 Systemverifikation t 1 t 2 tm 2 tm 1 M I,t 1 M T,t 2 M T,t 1 M I,t 2 M PV,1 M PC,1 Abb. 8.14. Formales Modell eines SystemC-TLM [346] M PV,1 kommuniziert. Auch kann der SystemC-Thread Transaktionen vom Typ t 1 in- itiieren, indem er ein Signal an den Automaten M I,t 1 schickt. Das Ergebnis der Trans- aktion teilt M I,t 1 ebenfalls ¨ uber ein Signal dem Automaten M PC,1 mit. Die Target- Automat M T,t 2 reagiert auf Transaktionen vom Typ t 2 .Diesek ¨ onnen ¨ Anderungen an der Variablenbelegung zur Folge haben. Definition 8.1.20 (Kommunizierende endliche Automaten). Gegeben seien zwei endliche Automaten M 1 =(I 1 ,O 1 ,S 1 ,s 0,1 , f 1 ,g 1 ) und M 2 =(I 2 ,O 2 ,S 2 ,s 0,2 , f 2 ,g 2 ) nach Definition 2.2.13 auf Seite 47 mit Anfangszustand s 0,1 bzw. s 0,2 . Die beiden Automaten k ¨ onnen miteinander kommunizieren, wenn O 1 ⊆ I 2 und O 2 ⊆ I 1 ist. Sei beispielsweise M 1 im Zustand s 1,1 und M 2 im Zustand s 1,2 .F ¨ uhre M 1 den Zustands ¨ ubergang s 1,1 /e −→ s 2,1 durch, so w ¨ urde M 1 in dem Automaten M 2 einen Zustands ¨ ubergang aktivieren, wenn ein Zustands ¨ ubergang mit Eingangssymbol e im Zustand s 1,2 existiert, d. h. s 1,2 e −→ s 2,2 . Im Folgenden werden die einzelnen endli- chen Automaten zur formalen Modellierung von TLMs genauer beschrieben. Prozess- und Variablen-Automat Prozess-Automaten modellieren das Verhalten der SystemC-Prozesse, dies ist ver- gleichbar mit dem Programmz ¨ ahler in dem in Abschnitt 8.1.2 beschriebenen Ansatz. Hier wird kurz auf die Besonderheiten bei der Modellierung der Kommunikation eingegangen. Beispiel 8.1.10. Gegeben ist ein Initiatormodul mit Port init socket vom Typ tlm initiator socket. Der Prozess ist wie folgt definiert: 1 void process() { 2 while(1) { 3 init_socket.b_transport(data); 4 d++; 5} 6} 8.1 Funktionale Eigenschaftspr ¨ ufung von SystemC-Modellen 481 Die durch b transport ausgel ¨ oste Transaktion ¨ ubertr ¨ agt dabei ein Datum data vom Typ tlm generic payload. Das Datenfeld von data enth ¨ alt den Wert der Variablen d vom Typ sc uint<2>, einen Bitvektor der Breite zwei. Somit wird der Wert, der in d gespeichert ist, durch die Transaktion ¨ ubertragen. Der resul- tierende Prozess-Automat M PC ist in Abb. 8.15a) zu sehen. Im Anfangszustand s 0 wartet der Prozess-Automat auf das Startsignal run, welches vom SystemC- Simulator erzeugt wird. Der Simulator wird sp ¨ ater ebenfalls formal modelliert. Hat der Prozess-Automat das run-Signal empfangen, beginnt die Transaktion durch Er- zeugung des Signals transport start. Erst wenn die Kommunikation beendet wurde (transport end), wird die eigentliche Berechnung des Moduls ausgef ¨ uhrt, also das Inkrement der Variable d berechnet. Da hierdurch die Variablenbelegung ge ¨ andert wird, erfolgt die ¨ Anderung in dem Variablen-Automaten M PV , welcher durch das Signal calculate aktiviert wird. Abbildung 8.15b) zeigt den Variablen-Automaten. s 1 a) b) calculate calculate calculate calculate 0 1 2 3 s 2 run transport end / calculate s 0 / transport start Abb. 8.15. a) Prozess-Automat und b) Variablen-Automat [347] Initiator- und Target-Automat Die Modellierung einer Transaktion erfolgt als Paar von Initiator- und Target-Auto- mat. Der Initiator-Automat reagiert auf das Signal transport start des Prozess- Automaten und initiiert die Kommunikation mittels des Signals request. Der Initiator- Automat wiederholt die Anfrage mit dem selben Signal solange, bis der Target- Automat mit dem Signal response das Ende der Transaktion signalisiert. Der Initiator- Automat ist in Abb. 8.16a) dargestellt. Der korrespondierende Target-Automat ist in Abb. 8.16b) dargestellt. Der Target- Automat verbleibt im Anfangszustand s 0 solange, bis das Signal request eine Trans- aktion initiiert. Ob die Transaktion direkt durchgef ¨ uhrt werden kann, h ¨ angt vom Zustand des Targetmoduls ab, dies wird ¨ uber die Variable f signalisiert. Kann die Transaktion momentan nicht durchgef ¨ uhrt werden (¬ f ), so wird dies dem SystemC- Simulator mittels des wait-Signals mitgeteilt. Als Argument wird dem SystemC- Simulator ein Ereignis e ¨ ubergeben, welches die Blockierung aufheben kann. Dies veranlasst den SystemC-Simulator, den SystemC-Prozess des Initiatormodul, der die Transaktion initiiert hat, zu blockieren. Die Transaktion kann erst fortgef ¨ uhrt wer- den, wenn der SystemC-Simulator das Signal run erzeugt. Ist die Bedingung zur 482 8 Systemverifikation s 1 s 1 b) / request/ request response ¬ response / request a) run ∧¬ f request request ∧ f responsetransport start / wait(e) s 2 s 0 s 0 Abb. 8.16. a) Initiator-Automat und b) Target-Automat [347] Abarbeitung der Transaktion direkt gegeben ( f ), wird die Transaktion durchgef ¨ uhrt. Die Beendigung der Transaktion wird durch das Signal response angezeigt. Man beachte, dass durch den Zustand s 1 das Blockieren eines SystemC-Prozesses modelliert wird. Dieser Mechanismus kann auch f ¨ ur wait-Anweisungen im Sys- temC-Prozess angewendet werden. Modellierung des SystemC-Simulators Schließlich muss noch der SystemC-Simulator selbst modelliert werden. Der im Fol- genden vorgestellte Ansatz unterscheidet sich von dem in Abschnitt 8.1.2 dadurch, dass dynamische Sensitivit ¨ atslisten unterst ¨ utzt werden und Zeitbetrachtungen mit aufgenommen werden k ¨ onnen. Der SystemC-Simulator wird ebenfalls als endlicher Automat modelliert und realisiert die Ablaufplanung nach dem SystemC-Standard [236]. Ein SystemC- Simulator f ¨ ur n SystemC-Prozesse p 1 , ,p n ist ein endlicher Automat, wobei die Zust ¨ ande mit Trippeln ( σ , π , φ ) markiert sind. Dabei ist • σ ∈{⊥, p 1 , ,p n } die Prozessauswahl , die eventuell leer ist (⊥), • π :=( π 1 , , π n ) der Zustandsvektor aller n Prozesse, mit dem Prozesszustand π i ∈{bereit, lau f end, blockiert} f ¨ ur jeden SystemC-Prozess p i , und • φ ∈{evaluate,update,delta noti f y,timed noti f y} zeigt die Ablaufplanungs- phase an. Die Initialisierung des Simulators erfolgt als s 0 =(⊥,bereit, ,bereit, evaluate) Somit startet der Simulator in der Evaluierungsphase, in der alle Prozesse bereit sind. Der SystemC-Simulator wird im n ¨ achsten Schritt einen Prozess p i ausw ¨ ahlen und ausf ¨ uhren, d. h. die Prozessauswahl wird auf σ = p i aktualisiert und p i geht in den Prozesszustand π i = lau f end ¨ uber. Prozess p i wird ausgef ¨ uhrt, bis er die n ¨ achste wait-Anweisung erreicht. Dabei geht er in den Prozess-Zustand π i = blockiert ¨ uber und die Prozessauswahl wird auf σ =⊥ gesetzt. Der Simulator w ¨ ahlt so lange Prozesse aus und f ¨ uhrt diese aus, bis kein Prozess mehr im Prozesszustand bereit ist, d. h. 8.1 Funktionale Eigenschaftspr ¨ ufung von SystemC-Modellen 483 σ =⊥∧∀1 ≤ i ≤ n : π i = blockiert Daraufhin schaltet der SystemC-Simulator in die Ablaufplanungsphase φ = update. In dieser Phase werden die SystemC-Kan ¨ ale aktualisiert, dies bedeutet, dass die Va- riablen f in Abb. 8.16b) neu bewertet werden. Anschließend wechselt der SystemC- Simulator in die Ablaufplanungsphase φ = delta noti f y. Dies hat zur Folge, dass alle Ereignisse, die w ¨ ahrend der Evaluierungsphase f ¨ ur den n ¨ achsten Delta-Zyklus erzeugt wurden, nun sichtbar werden. Damit werden alle Prozesse p i mit π i = blockiert, die auf ein solches Ereignis warten, auf π i = bereit gesetzt werden. Schließlich erfolgt der Wechsel des SystemC-Simulators in die Ablaufplanungspha- se φ = evaluate. Wird allerdings kein Prozess laufbereit, so wechselt der SystemC- Simulator zun ¨ achst in den Zustand timed notify und die Simulationszeit wird auf den n ¨ achste Zeitpunkt gesetzt, zu dem ein Ereignis auftritt. Beispiel 8.1.11. Abbildung 8.17 zeigt die Prozesszustands ¨ uberg ¨ ange f ¨ ur den Prozess aus Beispiel 8.1.10. Der Prozesszustand π i wird von bereit auf laufend gesetzt, so- bald der Prozess p i ausgew ¨ ahlt wurde ( σ = p i ) und Signal run erzeugt wird. Beim Erreichen einer wait-Anweisung blockiert der Prozess an dem zugeh ¨ origen Ereignis e. Erst das Auftreten von e kann den Prozess wieder in den Zustand bereit versetzen. bereit blockiert e laufend / run σ = p i wait(e) Abb. 8.17. Prozesszustands ¨ uberg ¨ ange f ¨ ur den Prozess p i aus Beispiel 8.1.10 [347] Modellierung von Kan ¨ alen Die Ber ¨ ucksichtigung von Kan ¨ alen verlangt, dass der in SystemC verwendete re- quest/update-Mechanismus umgesetzt wird. Dies erfolgt wiederum in einem endli- chen Automaten (siehe Abb. 8.18a)) und zwar f ¨ ur jeden Kanal einzeln. Der Automat startet im Zustand s 0 . Wird eine Kanalaktualisierung angezeigt, d. h. ein Prozess hat eine Transaktion auf dem Kanal durchgef ¨ uhrt, geht der jeweilige Automat in den Zustand s 1 ¨ uber. Wechselt der SystemC-Simulator in die Ablaufplanungsphase φ = update, so wechseln alle Automaten von ge ¨ anderten Kan ¨ alen in den Zustand s 2 , in welchem die eigentliche Aktualisierung stattfindet. Diese Aktualisierung ist kanalspezifisch und deshalb nicht in Abb. 8.18a) dargestellt. Die Beendigung der Aktualisierung erfolgt durch ¨ Uberg ¨ ange nach s 0 und senden von done-Signalen. . Abstraktionen durchf ¨ uhren, welche die Verifikationszeit verk ¨ urzen k ¨ onnen. Hardware/Software-Partitionierung Durch Hardware/Software-Partitionierung kann die Modellkomplexit ¨ at deutlich re- duziert