F¨ur eine LTS M und eine SE-LTL-Formelϕgilt: Hardware/Software-Partitionierung Durch Hardware/SoftwaPartitionierung kann die Modellkomplexit¨at deutlich re-duziert werden.. Thread-modula
Trang 1Die ¨ Ubergangsmarkierungsfunktion LR : R → 2 V R gibt an, f¨ur welchen gang welches Ereignis v ∈ V R gilt Dies ist gleichbedeutend mit:
Daneben kann jede SE-LTL-Formelϕ¨uber VS und VRauch als LTL-FormelϕLT L
¨uber VS ∪V Rinterpretiert werden Dabei sindϕundϕLT Lsyntaktisch identisch, terscheiden sich aber semantisch
un-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 SB ,0 und M = (S,R,L S ,L R) eine attributierte temporale
Struk-tur mit Anfangszust¨anden S0 Der B¨uchi-Automat verwendet die atomaren Aussagen
VB = V S ∪V R Der Produktautomat Mp:= 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 : LB (s B )} (dies beschreibt die Formel L B (s B),
in der alle Variablen v ∈ V Rexistentiell quantifiziert wurden),
• ((s,s B ),(s ,s
B )) ∈ R p, genau dann, wenn ∃v ∈ V R : s −→ s v ∧ (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 sB ∈ A B.
Die Anfangszust¨ande ergebenen sich aus den Paaren der Anfangszust¨ande beiderAutomaten
Da SE-LTL-Formeln syntaktisch identisch mit LTL-Formeln sind, lassen sichSE-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 desProduktautomaten umformuliert werden
Theorem 8.1.1 F¨ur eine LTS M und eine SE-LTL-Formelϕgilt:
Hardware/Software-Partitionierung
Durch Hardware/SoftwaPartitionierung 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
Trang 2• 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 wirdf¨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¨ankuneingeschr¨ank-te Threads ununeingeschr¨ank-terliegen
erwartungs-gem¨aß keinen Einschr¨ankungen und lassen somit bei der Abbildung auf LTS auchkeine Optimierungen zu
SAT-basierte Pr¨adikatenabstraktion
SystemC unterst¨utzt unterschiedliche Datentypen Um einen Zugang zum Entwurf zu erleichtern, werden auch Bitvektoren unterst¨utzt Die Operationen, dieauf Bitvektoren arbeiten, vergr¨oßern allerdings den Zustandsraum Eine m¨oglicheAbstraktion kann in diesem Fall durch den Einsatz von arithmetischen Operationenerreicht werden
Hardware-Erfolgt die Pr¨adikatenabstraktion durch SAT-Solver (siehe Abschnitt 7.3.3), sokann die Abstraktion nach folgender Formeln realisiert werden:
ˆ
s −→ ˆs A ⇔ ∃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 gang (ˆs, ˆs ) unter den Ereignissen a ∈ A existiert, sofern im konkreten Modell ein
Zustands¨uber-Zustands¨ubergang(s,s ) unter den selben Ereignissen existiert und der Start- undEndzustand Abstraktionen der konkreten Start- und Endzust¨ande sind
Thread-modulare Abstraktion
Die Repr¨asentation von SystemC-Modellen durch LTS erfolgt, indem f¨ur jedenSystemC-Prozess eine LTS generiert wird und diese anschließend parallel kompo-niert werden Es kann nun eine Abstraktion des gesamten Modells dadurch erreicht
Trang 3werden, dass zun¨achst die einzelnen LTS abstrahiert und anschließend parallel poniert werden.
kom-Formal bedeutet dies:
Theorem 8.1.2 Sei M die parallele Komposition von n LTS, d h M = M1 # ··· #
Mn Sei weiterhin ˆ Mi die Abstraktion von Mi und ˆ M die Abstraktion von M Dann gilt:
ˆ
M ≡ ˆ M1# ··· # ˆ Mn
Mit anderen Worten: Die Abstraktion der parallelen Komposition der konkreten LTS
M1bis Mnist ¨aquivalent zur parallelen Komposition der abstrakten LTS ˆM1bis ˆMn Dies bedeutet aber auch, dass die Projektion ˜s |M ieines Pfades ˜s = s0 ,e0,s1,e1, in der parallelen Komposition M der LTS M1bis Mn auf eine einzelne LTS Mi eine Abstraktion von M ist, d h
(˜s|M i ) " M
Dabei gilt die Projektion ˜s |M ieiner 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 spiele gesteuert, d h., ergibt die Modellpr¨ufung einer funktionalen Eigenschaft einNegativergebnis, wird ein Gegenbeispiel generiert L¨asst sich dieses Gegenbeispiel
Gegenbei-im urspr¨unglichen SystemC-Modell jedoch nicht sGegenbei-imulieren, so muss das Modellgeeignet 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 eineNetzliste von Prozessoren, Hardware-Beschleunigern, Bussen und Speichern DieUmsetzung erfolgt dabei h¨aufig in SystemC [352]
nichtblockierenden Transaktionen definiert SystemC-TLM unterschiedliche
Codie-rungsrichtlinien, die als schwach zeitbehaftet (engl Loosely Timed, LT), miert zeitbehaftet (engl Approximately Timed, AT) und zyklenakkurat (engl Cycle Accurate, CA) bezeichnet werden.
approxi-In einem LT-TLM werden ausschließlich blockierende Transaktionen (die temC-Methode b transport) verwendet, die durch einen Start- und einen Endzeit-punkt charakterisiert sind Diese beiden Zeitpunkte k¨onnen aber durchaus identisch
Trang 4Sys-sein, d h die Transaktion hat keine Zeit ben¨otigt Ein AT-TLM kann mehrere aktionsphasen enthalten und erlaubt somit eine detailliertere Modellierung, etwavon Ressourcenbeschr¨ankungen Dies wird durch nichtblockierende Transaktionen(die SystemC-Methode nb transport) erreicht, f¨ur die SystemC-TLM vier cha-
Trans-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-Beschreibungenauf der Registertransferebene und verfeinern AT-TLM mittels eines Taktsignals AT-und CA-TLMs stellen also Verfeinerungen von LT-TLMs dar und werden aufgrundder 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¨aufigenProzessen, die ¨uber blockierende Transaktionen miteinander kommunizieren DieProzesse 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 TLMals Anforderungen zu formulieren, m¨ussen also die zeitlichen Zusammenh¨ange derTransaktionen spezifiziert werden Da es in LT-TLMs im Allgemeinen kein Takt-signal gibt, m¨ussen diese zeitlichen Zusammenh¨ange relativ zueinander spezifiziertwerden
Beispiel 8.1.8 Abbildung 8.11 zeigt m¨ogliche relative zeitliche Zusammenh¨ange zwischen drei blockierenden Transaktionen t1, t2und t3 start bezeichnet dabei den Startzeitpunkt einer Transaktion, end den Endzeitpunkt Man sieht, dass Transakti-
on t3nach Transaktion t2und Transaktion t1startet, da t3.start > t2.start > t1.start Obwohl Transaktion t2nach Transaktion t1startet, wird diese fr¨uher beendet F¨urdie Formulierung von funktionalen Eigenschaften ist es manchmal notwendig, denAbstand zweier Ereignisse zu bestimmen Ohne Taktsignal kann dies nur relativ zu-
einander erfolgen Beispielsweise ist der Abstand zwischen den Ereignissen t1.start und t1.end vier, da drei Ereignisse zwischen diesen liegen.
Trang 5M¨oglichen Relationen zwischen zwei Transaktionen in einem LT-TLM sind inAbb 8.12 zu sehen Diese k¨onnen lediglich anhand der Position eines Start- oderEndeereignisses einer Transaktion bez¨uglich anderer Ereignisse definiert werden.
Abbildung 8.12a) zeigt, dass Transaktion t1 und Transaktion t2 gleichzeitig
statt-finden, da t1.start = t2.start und t1.end = t2.end In Abb 8.12b) ist der Fall zu hen, dass die Transaktion t2nach t1startet, beide aber gleichzeitig beendet werden
se-Abbildung 8.12c) zeigt den Fall, dass die Transaktionen t1und t2gleichzeitig
star-ten, t1aber fr¨uher beendet wird, d h t1.start = t2.start ∧ t1.end < t2.end lich zeigt Abb 8.12d), dass Transaktion t1 und t2direkt aufeinander folgen, d h
be-Definition 8.1.19 (Transaktionsebenenmodell) Ein Transaktionsebenenmodell ist
ein Tripel (TM I ,TM T ,T), wobei
• TM I die Menge an sog Initiatormodulen,
• TM T die Menge an sog 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 EinInitiatormodul enth¨alt einen SystemC-Prozess, wobei die Diskussion auf SystemC-Threads reduziert werden kann Targetmodule implementieren die Transaktionen
Trang 6b transport, weshalb Transaktionen mit Targetmodulen assoziiert werden dererseits k¨onnen Transaktionen lediglich von Initiatormodulen aufgerufen wer-den Welches Initiatormodul welche Transaktion auf welchem Targetmodul aufrufenkann, ist als Paar in der Transaktion gespeichert Targetmodule, die keine Initiator-module sind, enthalten keinen SystemC-Thread.
An-Beispiel 8.1.9 Ein An-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 T MI besteht aus den beiden CPUs und dem Bus
Die Menge der Targetmodule T MT besteht aus den beiden Speichern, dem Bus unddem Arbiter Da die beiden Speichermodule und der Arbiter keine Initiatormodulesind, besitzen sie auch keinen SystemC-Thread Module mit SystemC-Thread sindeingef¨arbt
betrach-belegungen lassen sich als endliche Automaten MPC ,i und MPV ,i modellieren
(sie-he Abschnitt 2.2.2) Enth¨alt ein Modul keinen SystemC-Thread, wird kein cher Automat f¨ur den Programmz¨ahler ben¨otigt Weiterhin wird f¨ur jede Transaktion
endli-t ∈ {t = (tm,tm ) ∈ T | tm = tm i } ein Initiator-Automat M I ,tund f¨ur jede
Transakti-on t ∈ {t = (tm,tm ) ∈ T | tm = tm i } ein Target-Automat M T ,tgebildet Dies ist in
Abb 8.14 zu sehen
Weiterhin zeigt Abb 8.14 das Zusammenspiel der kommunizierenden endlichen
Automaten Der Automat MPC ,1, der einen SystemC-Thread modelliert, kann somit
¨
Anderungen an der Variablenbelegung vornehmen, indem er mit dem Automaten
Trang 7Abb 8.14 Formales Modell eines SystemC-TLM [346]
MPV ,1 kommuniziert Auch kann der SystemC-Thread Transaktionen vom Typ t1
in-itiieren, indem er ein Signal an den Automaten MI ,t1 schickt Das Ergebnis der
Trans-aktion teilt MI ,t1 ebenfalls ¨uber ein Signal dem Automaten MPC ,1 mit Die
Target-Automat MT ,t2 reagiert auf Transaktionen vom Typ t2 Diese k¨onnen ¨Anderungen ander Variablenbelegung zur Folge haben
Definition 8.1.20 (Kommunizierende endliche Automaten) Gegeben seien zwei
endliche Automaten M1 = (I1 ,O1,S1,s0,1, f1,g1) und M2= (I2 ,O2,S2,s0,2, f2,g2)
nach Definition 2.2.13 auf Seite 47 mit Anfangszustand s0,1 bzw s0,2 Die beiden Automaten k¨onnen miteinander kommunizieren, wenn O1⊆ I2und O2⊆ I1ist Sei beispielsweise M1im Zustand s1,1 und M2 im Zustand s1,2 F¨uhre M1den
Zustands¨ubergang s1,1−→ s /e 2,1 durch, so w¨urde M1 in dem Automaten M2 einen
Zustands¨ubergang aktivieren, wenn ein Zustands¨ubergang mit Eingangssymbol e im Zustand s1,2 existiert, d h s1,2 −→ s e 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 gleichbar mit dem Programmz¨ahler in dem in Abschnitt 8.1.2 beschriebenen Ansatz.Hier wird kurz auf die Besonderheiten bei der Modellierung der Kommunikationeingegangen
ver-Beispiel 8.1.10 Gegeben ist ein Initiatormodul mit Port init socket vom Typ
tlm initiator socket Der Prozess ist wie folgt definiert:
Trang 8Die durch b transport ausgel¨oste Transaktion ¨ubertr¨agt dabei ein Datum datavom Typ tlm generic payload Das Datenfeld von data enth¨alt den Wert derVariablen d vom Typ sc uint<2>, einen Bitvektor der Breite zwei Somit wirdder Wert, der in d gespeichert ist, durch die Transaktion ¨ubertragen Der resul-
tierende Prozess-Automat MPC ist in Abb 8.15a) zu sehen Im Anfangszustand
s0 wartet der Prozess-Automat auf das Startsignal run, welches vom
SystemC-Simulator erzeugt wird Der SystemC-Simulator wird sp¨ater ebenfalls formal modelliert Hat
der Prozess-Automat das run-Signal empfangen, beginnt die Transaktion durch zeugung des Signals transport start Erst wenn die Kommunikation beendet wurde (transport end), wird die eigentliche Berechnung des Moduls ausgef¨uhrt, also das
Er-Inkrement der Variable d berechnet Da hierdurch die Variablenbelegung ge¨andertwird, erfolgt die ¨Anderung in dem Variablen-Automaten MPV, welcher durch das
Signal calculate aktiviert wird Abbildung 8.15b) zeigt den Variablen-Automaten.
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 Automaten und initiiert die Kommunikation mittels des Signals request Der Initiator-
Prozess-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 Automat ist in Abb 8.16b) dargestellt Der
Target-Automat verbleibt im Anfangszustand s0solange, bis das Signal request eine
Trans-aktion initiiert Ob die TransTrans-aktion 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 Simulator mittels des wait-Signals mitgeteilt Als Argument wird dem SystemC- Simulator ein Ereignis e ¨ubergeben, welches die Blockierung aufheben kann Dies
SystemC-veranlasst den SystemC-Simulator, den SystemC-Prozess des Initiatormodul, der dieTransaktion initiiert hat, zu blockieren Die Transaktion kann erst fortgef¨uhrt wer-
den, wenn der SystemC-Simulator das Signal run erzeugt Ist die Bedingung zur
Trang 9s1 s1
b)
/ request / request
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 s1das Blockieren eines SystemC-Prozessesmodelliert 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 genden vorgestellte Ansatz unterscheidet sich von dem in Abschnitt 8.1.2 dadurch,dass dynamische Sensitivit¨atslisten unterst¨utzt werden und Zeitbetrachtungen mitaufgenommen werden k¨onnen
Fol-Der SystemC-Simulator wird ebenfalls als endlicher Automat modelliert undrealisiert die Ablaufplanung nach dem SystemC-Standard [236] Ein SystemC-
Simulator f¨ur n SystemC-Prozesse p1, , p nist ein endlicher Automat, wobei dieZust¨ande mit Trippeln(σ,π,φ) markiert sind Dabei ist
• σ∈ {⊥, p1, , 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
s0= (⊥,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 pi ausw¨ahlenund ausf¨uhren, d h die Prozessauswahl wird aufσ= p i aktualisiert und pigeht inden Prozesszustandπi = lau f end ¨uber Prozess p iwird ausgef¨uhrt, bis er die n¨achstewait-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.
Trang 10σ=⊥ ∧∀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 pi 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 Simulator zun¨achst in den Zustand timed notify und die Simulationszeit wird auf den
SystemC-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, bald der Prozess pi ausgew¨ahlt wurde (σ= p i) und Signal run erzeugt wird Beim
so-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.
Abb 8.17 Prozesszustands¨uberg¨ange f¨ur den Prozess p iaus Beispiel 8.1.10 [347]
Modellierung von Kan¨alen
Die Ber¨ucksichtigung von Kan¨alen verlangt, dass der in SystemC verwendete quest/update-Mechanismus umgesetzt wird Dies erfolgt wiederum in einem endli-
re-chen Automaten (siehe Abb 8.18a)) und zwar f¨ur jeden Kanal einzeln Der Automat
startet im Zustand s0 Wird eine Kanalaktualisierung angezeigt, d h ein Prozesshat eine Transaktion auf dem Kanal durchgef¨uhrt, geht der jeweilige Automat in
den Zustand s1 ¨uber Wechselt der SystemC-Simulator in die Ablaufplanungsphase
φ= update, so wechseln alle Automaten von ge¨anderten Kan¨alen in den Zustand
s2, in welchem die eigentliche Aktualisierung stattfindet Diese Aktualisierung istkanalspezifisch und deshalb nicht in Abb 8.18a) dargestellt Die Beendigung derAktualisierung erfolgt durch ¨Uberg¨ange nach s und senden von done-Signalen.
Trang 11Modellierung von Ereignissen
Jedes SystemC-Ereignis wird ebenfalls als endlicher Automat modelliert Dieser ist
in Abb 8.18b) dargestellt Bei der Erzeugung eines Ereignisses durch eine
notify-Anweisung wird das Ereignis notify erzeugt, was den Zustands¨ubergang nach s1ursacht Dieser Zustand zeigt an, dass ein Ereignis sp¨ater sichtbar werden soll Durch
ver-Aufruf einer cancel-Anweisung kann dieser Zustand wieder verlassen werden, bevor
der Simulator das Ereignis ber¨ucksichtigt
Dieses formale Modell kommunizierender Automaten erfasst das Verhalten liebiger SystemC-TLMs F¨ur die Modellpr¨ufung kann die ¨Ubersetzung eines Mo-dells eines SystemC-TLMs in eine temporale Struktur erfolgen [347] Alternativ isteine ¨Ubersetzung auf attributierte temporale Strukturen denkbar
be-8.1.4 Zusicherungsbasierte Eigenschaftspr ¨ufung f ¨ur
im Daten- oder Kontrollfluss kommen kann, werden Ereignisse zur Synchronisationeingesetzt Dies hat aber auch zu Folge, dass in der Regel kein Taktsignal verf¨ugbarist, um die Zeitpunkte zur Evaluierung zu bestimmen Aus diesem Grund ist es not-wendig, geeignete Ereignisse im TLM zu generieren
In [361] ist ein Ansatz beschrieben der auf dem sog engl Observer Pattern siert Jeder Monitor verwendet einen Observer, um diejenigen Kan¨ale und Signale im
ba-SUV zu beobachten, die er zur ¨Uberpr¨ufung der Zusicherung ben¨otigt Dabei kannein Observer-Objekt von mehreren Monitoren verwendet werden Weiterhin kann einKanal oder ein Signal von mehreren Observern beobachtet werden Damit die Ob-server ¨uber relevante Ereignisse (hierzu geh¨oren auch ¨Anderungen am Status eines
Trang 12Kanals) informiert werden, ist es notwendig, die verwendeten
Kommunikationsme-thoden (nb transport, b transport etc.) zu ¨uberladen Dies wird an dem Beispiel aus
[361] f¨ur einen einfachen FIFO-Kanal illustriert
Beispiel 8.1.12 Es wird lediglich die Leseoperation read betrachtet Der
FIFO-Kanal ist vom Typ fifo Ohne die genaue Implementierung des FIFO-FIFO-Kanals zukennen, kann die Leseoperation beobachtbar gemacht werden, indem von fifo einneuer Typ observable fifo abgeleitet wird
1 class observable_fifo : public fifo, observer {
Ab-Beispiel 8.1.13 Es soll ein elementarer Monitor zur ¨Uberpr¨ufung der PSL-Formel
always expr gebaut werden Eine Implementierung in C++ kann dann wie folgt
aus-sehen:
1 class monitor_always : public monitor {
Trang 13Die Variable start t wird verwendet, um ein einmal gegebenes Startsignal biszum n¨achsten Zur¨ucksetzen zu speichern Somit zeigt die in Zeile 11 berechnete Va-riable start always an, ob ¨uberhaupt eine ¨Uberpr¨ufung bei dem aktuellen Aufrufvon update() durchgef¨uhrt wird Falls dies nicht der Fall ist oder gerade ein akti-ves R¨ucksetzsignal (reset) anliegt, wird die Variable valid t auf den Default-Werttrue gesetzt (Zeile 12 und 13) Andernfalls wird in den Zeilen 15 bis 18 ¨uberpr¨uft,
ob expr erf¨ullt ist Die Ausgabe wird erst in den Zeilen 24 und 25 erzeugt
Man sieht, dass die Monitore als C++-Klassen implementiert werden k¨onnen
Da diese ¨uber den Observer gesteuert werden, finden keine Kontextwechsel durchMonitore statt, was ansonsten einen enormen Overhead an Simulationszeit w¨ahrendder Verifikation zur Folge h¨atte
Die Konstruktion komplexer Monitore f¨ur PSL-Zusicherungen erfolgt mit dem
in [361] beschriebenen Ansatz durch Verschaltung elementarer Monitore (siehe auchAbschnitt 6.4.1) Dies wird anhand eines Beispiels aus [361] illustriert
Beispiel 8.1.14 Abbildung 8.19a) zeigt ein Transaktionsebenenmodell eines cer/Consumer-Systems Der Produzent (engl producer) erzeugt Nachrichten, wel-
Produ-che aus einzelnen ZeiProdu-chen bestehen, und schreibt diese in einen FIFO-Kanal EineNachricht beginnt stets mit dem Symbol
”%“ und endet mit dem Zeichen”$“ Der
Konsument (engl consumer) liest die Nachrichten als Sequenz von Zeichen aus dem
FIFO-Kanal Es soll nun gezeigt werden, dass die ¨Ubertragung einer neuen richt erst beginnt, nachdem die vorherige Nachricht vollst¨andig geschrieben wurde
Nach-Mit Hilfe des in Beispiel 8.1.12 eingef¨uhrten Monitors, kann dies als Zusicherung formuliert werden
PSL-assert always((char == % ) -> next((not(char == % )) until! (char == $)))
Trang 14start checking
start checking
1 Wrapper
operand operand operand
until!
Consumer
Abb 8.19 PSL-Monitor f¨ur ein TLM eines Producer/Consumer-System [361]
Die Methode read des FIFO-Kanals mit beobachtbarer Leseoperation kann mittels
einer C++-Klasse das gelesene Zeichen char zur¨uckliefern Da PSL neben VHDL
und SystemVerilog ebenfalls SystemC unterst¨utzt, kann dieses Zeichen direkt zumVergleich gegen das Start- und Endezeichen einer Nachricht innerhalb einer PSL-Zusicherung verwendet werden Die Umsetzung der PSL-Zusicherung erfolgt durchVerschaltung elementarer Monitore [361]:
4 mnt_always = new monitor_always("always");
5 mnt_imply = new monitor_imply("->");
6 mnt_next = new monitor_next("next", WEAK, 1);
7 mnt_until = new monitor_until("until!", STRONG);
Trang 15Im Konstruktor monitor msg seq werden die elementaren Monitore instantiiert.Hierbei wird auch der Always-Monitor aus Beispiel 8.1.13 verwendet Der Until-und Next-Monitor erhalten zus¨atzliche Argumente, die anzeigen, ob es sich um einenschwachen oder einen starken Operator handelt Der Next-Operator bekommt zus¨atz-lich die Anzahl an Zeitschritten mitgeteilt, nach denen die zugeh¨orige Teilformelausgewertet werden soll Die Zeitschritte ergeben sich aus dem Ereignis, welches inder read-Methode des FIFO erzeugt wird In der Methode update werden die aus-zuwertenden Ausdr¨ucke gesetzt Anschließen wird die Auswertung des am weitestenrechts stehenden Until-Monitors gestartet (Zeile 14), der wiederum die angeschlosse-nen Monitore startet Die Ausgabe des Until-Monitors (valid i und checking i)wird mit den Ausg¨angen valid und checking des zusammengesetzten Monitorsverbunden.
Ein weiteres Beispiel [361] soll die zusicherungsbasierte Eigenschaftspr¨ufungvon Transaktionsebenenmodellen verdeutlichen
Beispiel 8.1.15 Abbildung 8.20 zeigt ein System bestehend aus einer CPU, einem DMA-Controller (engl direct memory access), zwei Speicher-Modulen und einem
Bus In dem DMA-Controller gibt es vier Register, die ¨uber bestimmte Adressen gesprochen werden k¨onnen F¨ur Kopieroperationen zwischen den beiden Speicher-modulen wird der DMA-Controller von der CPU wie folgt programmiert:
an-1 Zun¨achst schreibt die CPU die Quelladresse in das zugeh¨orige DMA-Registersource
2 In einem zweiten Schritt wird die Zieladresse von der CPU in das DMA-Registersink geschrieben
3 Anschließend speichert die CPU die L¨ange des zu kopierenden Blocks in dasDMA-Register length
4 Schließlich initiiert die CPU den Transfer durch setzten des gisters control
DMA-Kontrollre-Alle Kopieroperationen werden von der CPU initiiert und mittels b Aufrufen realisiert Das eigentliche Kopieren der Daten f¨uhrt der DMA-Controllerdabei selbst¨andig durch alternierende Lese- und Schreiboperationen aus Die Been-digung des Kopiervorgangs signalisiert der DMA-Controller der CPU mittels eines
transport-Interrupt-Signals dma irq Dieses Interrupt-Signal ist im TLM als ein Signal
imple-mentiert Das Interrupt-Signal wird von der CPU gel¨oscht, indem das ter im DMA-Kontroller zur¨uckgesetzt wird
Kontrollregis-Im Folgenden werden vier PSL-Zusicherungen f¨ur dieses Modell vorgestellt bei wird einfachheitshalber davon ausgegangen, dass Kopieroperationen stets vomSpeicher 1 (mem1) in den Speicher 2 (mem2) erfolgen Die erste Zusicherung besagt,dass nach der ¨Ubertragung der Quelladresse als n¨achste Transaktion die ¨Ubertragungder Zieladresse erfolgt Hierzu muss der Initiator-Socket cpu init socket der CPU
Da-¨uberwacht werden Dies erfolgt durch ¨Uberladen der b transport-Implementierungund die Verwendung eines Wrapper-Moduls Die PSL-Zusicherung kann dann wiefolgt formuliert werden: