Digitale Hardware/ Software-Systeme- P12 pot

30 290 0
Digitale Hardware/ Software-Systeme- P12 pot

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

6.4 Funktionale Eigenschaftspr ¨ ufung 323 6.4 Funktionale Eigenschaftspr ¨ ufung F ¨ ur die funktionale Eigenschaftspr ¨ ufung von Hardware-Komponenten werden heut- zutage im Wesentlichen zusicherungsbasierte oder SAT-basierte Verfahren einge- setzt. Beide Ans ¨ atze werden im Folgenden n ¨ aher betrachtet. 6.4.1 Zusicherungsbasierte Eigenschaftspr ¨ ufung F ¨ ur die zusicherungsbasierte, simulative Eigenschaftspr ¨ ufung werden Zusicherun- gen (engl. assertions) zun ¨ achst in Monitore ¨ ubersetzt (siehe Abschnitt 5.2.3). F ¨ ur die funktionale Eigenschaftspr ¨ ufung von Hardware-Komponenten werden diese Mo- nitore in Schaltungen synthetisiert. Die resultierenden Monitorschaltungen k ¨ onnen anschließend zusammen mit dem Modell der Schaltung simuliert werden oder zur ¨ Uberpr ¨ ufung der Schaltung im sp ¨ ateren Betrieb auch mit gefertigt werden. Im Fol- genden wird gezeigt, wie Monitore f ¨ ur PSL-Zusicherungen generiert werden k ¨ onnen. Synthese von Monitoren Um Monitore zur simulativen Pr ¨ ufung von Zusicherungen im Hardware-Entwurf einsetzen zu k ¨ onnen, m ¨ ussen Monitore synthetisiert werden. Somit werden Monitore als Komponenten implementiert, die als Eingang das Taktsignal, das R ¨ ucksetzsignal, weitere Synchronisationssignale und Signale des SUV (engl. System Under Verifi- cation), welche f ¨ ur die ¨ Uberpr ¨ ufung der Zusicherung beobachtet werden m ¨ ussen, erhalten. Die Ausgabe der Monitorkomponente zeigt dann an, inwieweit die zu ¨ uber- pr ¨ ufende Zusicherung momentan erf ¨ ullt ist. Eine Zusicherung kann in einer Simula- tion entweder: 1. stark erf ¨ ullt sein, wenn die Zusicherung bereits erf ¨ ullt ist und unter jedem erdenklichen Ausf ¨ uhrungspfad (auch bei Beendigung der Simulation) weiter erf ¨ ullt sein wird, 2. erf ¨ ullt sein , wenn die Zusicherung bereits erf ¨ ullt wurde, aber Ausf ¨ uhrungspfade denkbar sind, welche die Zusicherung widerlegen, 3. ausstehend sein, wenn die Zusicherung bisher weder erf ¨ ullt wurde noch wi- derlegt wurde, aber Ausf ¨ uhrungspfade m ¨ oglich sind, welche die Zusicherung erf ¨ ullen oder widerlegen, oder 4. nicht erf ¨ ullt sein, wenn die Zusicherung bereits widerlegt wurde und weiter keine Vervollst ¨ andigung des Ausf ¨ uhrungspfad m ¨ oglich ist, auf dem die Zusicherung erf ¨ ullt ist. Die Ausgabe der Monitorkomponenten besteht aus drei Signalen checking, valid und pending,f ¨ ur die folgende Eigenschaften gelten: • checking = T zeigt an, dass das Signal valid im n ¨ achsten Takt g ¨ ultig wird. • valid zeigt das Ergebnis der ¨ Uberpr ¨ ufung der Zusicherung an, wobei T die G ¨ ultigkeit der Zusicherung und F die Verletzung der Zusicherung signalisiert. 324 6 Hardware-Verifikation • pending = T zeigt an, dass der Monitor gestartet wurde, ein endg ¨ ultiges Ergebnis allerdings noch aussteht. Dieses Signal wird f ¨ ur die starken Operatoren in PSL ben ¨ otigt. Die Schnittstelle eines PSL-Monitors ist in Abb. 6.64 zu sehen. Monitor checkingclk reset start operands valid pending Abb. 6.64. Schnittstelle eines PSL-Monitors [335] Da komplexe Zusicherungen als Kombinationen von elementaren Zusicherun- gen aufgebaut werden k ¨ onnen, k ¨ onnen Monitore f ¨ ur komplexe Zusicherungen auch durch Verschalten von Monitoren f ¨ ur elementare Zusicherungen gewonnen werden. Die Struktur der Verschaltung dieser Monitore entspricht der Struktur der PSL- Formel, die es zu pr ¨ ufen gilt. Das folgende Beispiel stammt aus [335]. Beispiel 6.4.1. Es soll f ¨ ur die folgende Zusicherung ein Monitor synthetisiert wer- den. assert always a -> next![2](b before! c)@(posedge clk); Diese Zusicherung beschreibt eine Invariante, die garantiert, dass jedes Mal, wenn das Signal a den Wert T annimmt, nach zwei Takten gelten muss, dass das Signal b vor dem Signal c den Wert T annimmt. Ein zugeh ¨ origer Monitor hat also eine Schnittstelle, die zu den immer notwendigen Signalen (clk, reset, start. checking, valid und pending) die Signale a, b und c enth ¨ alt. Abbildung 6.65 zeigt zwei m ¨ ogliche Signalverl ¨ aufe f ¨ ur den Monitor, wobei die PSL-Zusicherung in Abb. 6.65a) nicht erf ¨ ullt ist. In Takt 1 wechselt das Signal a von F nach T. Somit muss, um die Zusicherung zu erf ¨ ullen, das Signal b ab Takt 3 vor dem Signal c den Wert T annehmen. In Takt 5 wechselt jedoch Signal c von F nach T, ohne dass zuvor Signal b auf T gewechselt hat. Im selben Takt wechselt das Signal checking auf T, womit signalisiert wird, dass das Signal valid im n ¨ achsten Takt das Ergebnis liefert. Im Takt 6 zeigt das Signal valid schließlich die Verletzung der Zusicherung an. In Abb. 6.65b) ist die Zusicherung auf dem dargestellten endlichen Signalverlauf erf ¨ ullt. In Takt 2 nimmt das Signal a f ¨ ur einen Takt den Wert T an. Somit muss, um die Zusicherung zu erf ¨ ullen, Signal b ab Takt 4 vor Signal c den Wert T anneh- men. In Takt 6 wechselt Signal b von F nach T. Da Signal c vorher keinen Wechsel durchgef ¨ uhrt hat, ist die Zusicherung erf ¨ ullt, was in Takt 7 mittels des jetzt g ¨ ultigen Signals valid angezeigt wird. Das dieser Wert g ¨ ultig ist, wird durch den Wechsel 6.4 Funktionale Eigenschaftspr ¨ ufung 325 012345678 012345678 a) b) clk reset start a b c checking valid pending clk reset start a b c checking valid pending Abb. 6.65. Signalverl ¨ aufe: a) verletzt die Zusicherung b) erf ¨ ullt die Zusicherung [335] von Signal checking im Takt 6 von F nach T signalisiert. Man muss beachten, dass wenn die Beobachtung durch den Monitor in Takt 5 beendet worden w ¨ are, der starke before!-Operator fehlgeschlagen w ¨ are, was durch das Signal pending mit dem Wert T angezeigt ist. Generierung komplexer Monitore durch Komposition Um komplexe Zusicherungen zu ¨ uberpr ¨ ufen, werden Monitore, die elementare Zu- sicherungen implementieren, zusammen geschaltet. Die Verschaltung erfolgt da- bei entsprechend dem Syntaxbaum der PSL-Formel. Der Syntaxbaum zu der PSL- 326 6 Hardware-Verifikation Zusicherung aus Beispiel 6.4.1 ist in Abb. 6.66 dargestellt. Dabei ist ein Knoten im Syntaxbaum ein PSL-Operator und die Bl ¨ atter sind Operanden (Signale). cb a 2 before! next! - > always Abb. 6.66. Syntaxbaum f ¨ ur die Zusicherung always a -> next![2](b before! c) Die Verschaltung erfolgt, indem Operanden mit den einzelnen Operatoren nach- folgender Regeln verbunden werden: • F ¨ ur jeden Knoten im Syntaxbaum wird ein entsprechender Monitor instantiiert. • Die Ergebnisse Boolescher Ausdr ¨ ucke aus der Schaltung werden direkt mit den Eing ¨ angen der Monitore verbunden. Falls ein Operand eine Formel mit tempo- ralen Operatoren ist, so wird der entsprechende Eingang mit einer konstanten T verbunden. Sonst wird der Boolesche Ausdruck direkt mit den Eing ¨ angen der Monitore verbunden. • F ¨ ur zwei Operatoren op1 und op2, wobei op2 Operand von op1 ist, werden die Monitore wie folgt verschaltet: – Der Ausgang checking vom Monitor f ¨ ur op1 wird mit dem Eingang start des Monitors f ¨ ur op2 verbunden. – Der Ausgang valid vom Monitor f ¨ ur op1 wird nicht verwendet. – Die Signale clk und reset werden von beiden Monitoren gemeinsam verwen- det. • Ein Komponente init wird erzeugt, welche das Startsignal f ¨ ur den ersten Monitor liefert. Das Startsignal wird einen Takt nachdem das reset-Signal von T nach F gewechselt ist generiert. 6.4 Funktionale Eigenschaftspr ¨ ufung 327 • Die prim ¨ aren Ausg ¨ ange des zusammengesetzten Monitors zeigen an, inwieweit die gesamte PSL-Zusicherung erf ¨ ullt ist, wobei das pending-Signal als Disjunk- tion aller pending-Signale der starken PSL-Operatoren gebildet wird. Der komplexe Monitor f ¨ ur die PSL-Zusicherung aus Beispiel 6.4.1 ist in Abb. 6.67 dargestellt. checking ≥ 1 a b c clk reset clk reset start always clk reset start init checking clk reset start - > clk reset start checking pending clk reset start checking valid pending pending valid checking before! operandoperandoperand operand operand operand TTT next![2] Abb. 6.67. Monitor f ¨ ur die Zusicherung always a -> next![2](b before! c) [335] Generierung der elementarer Monitore Die einzelnen primitiven Monitore k ¨ onnen entsprechend dem Vorgehen aus Ab- schnitt 5.2.3 generiert werden. Ein alternativer Ansatz ist in [334] f ¨ ur sequentiell erweitere regul ¨ are Ausdr ¨ ucke (SEREs) beschrieben. F ¨ ur die Generierung der Signa- le checking, valid und pending wird in [333, 335] ein Struktur aus einem Block zur Zeitfenstergenerierung und einem Block zur Evaluierung vorgeschlagen. Der Block zur Zeitfenstergenerierung setzt entsprechend der temporalen Opera- toren und in Abh ¨ angigkeit des Signals start das Signal pending und checking sowie ein internes Signal check. Ein Schieberegister kann verwendet werden, wenn die Operatoren eine ¨ Uberlappung von Zeitfenstern erlauben. Der Block zur Evaluierung beginnt mit der Verarbeitung der Operanden, sobald das interne Signal check ge- setzt ist und setzt das Ausgangssignal valid = F. Ist das Signal check = F,sowird das Signal val id auf den Wert T gesetzt. Die Verschaltung der beiden Bl ¨ ocke ist in Abb. 6.68 zu sehen. Aufstellen von Zusicherungen f ¨ ur die PCI-Spezifikation Im Folgenden wird anhand der PCI-Spezifikation [356] gezeigt, wie Zusicherungen aus einer umgangssprachlichen Spezifikation abgeleitet werden k ¨ onnen. Das Bei- spiel s tammt aus [111]. Peripheral Component Interconnect (PCI) Local Bus ist ein Industriestandard f ¨ ur 32- oder 64-Bit Bus Architekturen mit gemultiplexten Adress- und Datenleitungen. Der Bus wurde im Wesentlichen als kosteng ¨ unstige aber schnelle Verbindungstech- nik f ¨ ur integrierte Peripherie-Controller mit Speicher- und Prozessorsubsystemen entwickelt. Die Schnittstelle eines PCI-Busses ist in Abb. 6.69 zu sehen. 328 6 Hardware-Verifikation pending valid checking operands Monitor start clk reset check Zeitfenster- generierung Evaluierung Abb. 6.68. Struktur eines primitiven PSL-Monitors [333] PCI-kompatibles Ger ¨ at steuerung Fehler- anzeige Arbitrierung ad cbe n par f rame n trdy n irdy n sto p n idsel devsel n perr n serr n req n gnt n clk rst n 32 4 Schnittstellen- und Daten Adressierung Abb. 6.69. PCI-Bus-Schnittstelle [111] Eine Transaktion auf dem PCI-Bus besteht aus aus einer Adressierungs- und ei- ner oder mehreren folgenden Datenphasen. Die Art der Transaktion wird w ¨ ahrend der Adressierungsphase mittels der Signale cbe n[3:0] angezeigt. W ¨ ahrend der Da- tenphase dienen diese Signale als Auswahlsignale (engl. byte enable). Man beachte, dass das Suffix n ein invers aktives Signal kennzeichnet. Die weiteren Signale wer- den w ¨ ahrend der Aufstellung von Zusicherungen nach Bedarf eingef ¨ uhrt. Beispiel 6.4.2. Die Anforderung an das Zur ¨ ucksetzen des Busses aus der PCI-Spezi- fikation soll in einer Zusicherung formuliert werden. Die PCI-Spezifikation gibt vor: Um zu verhindern, dass die Signale ad[31 : 0], Signal cbe n[3:0] und Signal par beim Zur ¨ ucksetzen unbestimmte Pegel annehmen, d ¨ urfen diese, w ¨ ahrend das R ¨ uck- setzsignal rst n den Wert F besitzt, nicht den Wert T annehmen. In PSL heißt dies: assert always(rst n == F)->!({ad}|{cbe e}|{par})@(posedge clk); 6.4 Funktionale Eigenschaftspr ¨ ufung 329 Die Adresse, auf die ¨ uber den PCI-Bus zugegriffen werden soll, ist durch die Adresssignale ad[31 : 2] w ¨ ahlbar. Die beiden niederwertigsten Bits ad[1:0] werden vom Bus-Master verwendet, um f ¨ ur einen Burst-Zugriff anzuzeigen, in welcher Rei- henfolge Daten ¨ ubertragen werden. Dabei zeigt die Belegung ad[1:0]=(F, F) eine lineare Inkrementierung der Adresse an. Die Belegung ad[1:0]=(T,F) steht f ¨ ur den sog. cache wrap mode. Die Belegungen ad[1:0]=(F, T) und ad[1:0]=(T,T) sind ungenutzt (reserviert). Beispiel 6.4.3. Aus der obigen Darstellung folgt, dass Signal ad[0] niemals den Wert T w ¨ ahrend der Adressierungsphase annehmen darf. Um dies in einer Zusicherung zu formulieren, muss zun ¨ achst die Adressierungsphase identifiziert werden. Dies er- folgt ¨ uber einen sequentiell erweiterten regul ¨ aren Ausdruck (SERE), der beschreibt, dass das Signal frame n zu Beginn der Adressierungsphase von T nach F wech- selt. Die Signale cbe n[3:0] zeigen zu diesem Zeitpunkt die Transaktionsart an. Die Definition dieser Transaktionsarten kann in PSL mit dem  define-Befehl erfolgen.  define mem cmd ((cbe n ==  ME M READ) || \ (cbe n ==  ME M WRITE) || \ (cbe n ==  ME M RD MU LT IP) || \ (cbe n ==  ME M RD LINE) || \ (cbe n ==  ME M WR AND INV )) Man beachte, dass anstelle der logischen Werte der Signale cbe n[3:0] Makros ver- wendet wurden. Mit der Variablen mem cmd kann nun der Beginn einer Adressierungsphase als SERE formuliert werden. Dies erfolgt in PSL mittels der sequence-Anweisung. sequence SERE ME M ADDR PHASE = { frame n;!frame n && mem cmd}; Nun kann die Eigenschaft, dass Signal ad[0] in einer Adressierungsphase niemals den Wert F annimmt, formuliert werden: property PCI VALID ME M BU RST ENC = always SERE ME M ADDR PHASE |-> {!ad[0]} abort!rst n@(posedge clk); Schließlich wird diese Eigenschaft als Zusicherung formuliert: assert PCI VALID ME M BU RST ENC; Beispiel 6.4.4. Eine einfache Lesetransaktion auf dem PCI-Bus besteht aus zwei Phasen: Der Adressierungsphase, bei der eine Adresse innerhalb eines Taktes ¨ uber- tragen wird, und einer Datenphase, die aus einem Datentransfer und keinem, einem oder mehreren Wartezyklen besteht. Die Adressierungsphase beginnt mit dem Wech- sel des Signals frame n von T nach F,d.h. 330 6 Hardware-Verifikation sequence SERE RD ADDR PHAS E = { frame n;!frame n&&mem cmd}; wobei mem cmd wie folgt spezifiziert ist:  define mem cmd ((cbe n ==  IO READ) || \ (cbe n ==  ME M READ) || \ (cbe n ==  CONFIG RD) || \ (cbe n ==  ME M RD MU LT IP) || \ (cbe n ==  ME M RD LINE)) Zwischen Adressierungs- und Datenphase muss ein Taktzyklus liegen. Dieser kann durch die folgende SERE erkannt werden:  define ad turn around (trdy n &!irdy n) sequence SERE TURN AROU ND = {ad turn around}; Der Datentransport wird durch die Signale irdy n = F, trdy n = F und frame n = F angezeigt. Die Wartezyklen werden durch die Signale irdy n = T oder trdy n = T angezeigt. Somit kann der der Datentransport als SERE wie folgt modelliert werden:  define dat a trans f er (!trdy n && !irdy n && ! frame n)  define wait state (trdy n || irdy n) sequence SERE DAT A T RANSFER = {{wait state[∗];data trans f er}[1:in f ]}; Die Datenphase endet entweder, wenn Signal trdy n = F oder Signal st o p n = F und gleichzeitig Signal irdy n = F ist. Die Lesetransaktion endet sobald das Signal frame n den Wert T annimmt. Damit kann das Ende des Datentransfers als SERE definiert werden:  define dat a complete ((!trdy n || stop n) && !irdy n) sequence SERE END OF T RANSFER = {dat a complete && frame n}; W ¨ ahrend der gesamten Datenphase bleiben die Signale cbe n[3:0] stabil, d. h.  define cbe stable (cbe n == prev(cbe n)) Die Datenphase kann wie folgt als SERE formuliert werden: sequence SERE DAT A PHASE = { {SERE DAT A T RANSFER; SERE END OF T RANSFER} && {cbe stable}}; Die funktionale Eigenschaft einer g ¨ ultigen Lesetransaktion sieht dann wie folgt aus: 6.4 Funktionale Eigenschaftspr ¨ ufung 331 property PCI READ T RANSACT ION = always SERE RD ADDR PHASE |=> {SERE TURN AROUND; SERE DATA PHASE} abort!rst n@(posedge clk); Dies kann als Zusicherung ebenfalls formuliert werden: assert PCI READ T RANSACT I ON; 6.4.2 SAT-basierte Modellpr ¨ ufung SAT-basierte Modellpr ¨ ufung hat sich als formales Pr ¨ ufverfahren f ¨ ur funktionale Ei- genschaften im Hardware-Entwurf etabliert. Dies liegt im Wesentlichen an der guten Skalierbarkeit des Verfahren f ¨ ur die Falsifikation von Eigenschaften. Dabei ist das Finden von Gegenbeispielen einer beschr ¨ ankten L ¨ ange von k Zeitschritten im Fo- kus des Verfahrens. Die zugrundeliegende Idee ist die effiziente ¨ Ubersetzung der Schaltung und der funktionalen Eigenschaft f ¨ ur eine gegebene Schranke k in eine Instanz des Booleschen Erf ¨ ullbarkeitsproblems. Die resultierende Formel ist genau dann erf ¨ ullbar, wenn ein Gegenbeispiel der L ¨ ange k existiert (siehe Abschnitt 5.3.2). Die ¨ Ubersetzung erfordert u. a. das Abrollen der Schaltung ¨ uber k Zeitschritte. Das Ergebnis ist ein iteratives Schaltungsmodell, wie es bereits in Abschnitt 6.1.3 f ¨ ur die ¨ Aquivalenzpr ¨ ufung zweier Schaltwerke definiert wurde. Solch ein Modell ist nochmals in Abb. 6.70 f ¨ ur das Schaltwerk aus Abb. 6.15 auf Seite 258 gezeigt. Der jeweilige Zeitschritt ist hinter den Signalnamen in den eckigen Klammern angege- ben. g f i[0] o[0] g f g f o[1]i[1] s[1] i[2] o[2] s[2]s[0] Zeitschritt Zeitschritt Zeitschritt Abb. 6.70. Iteratives Schaltungsmodell des Schaltwerks aus Abb. 6.15 Das Abrollen der Schaltung beschr ¨ ankt die m ¨ oglichen Ausf ¨ uhrungspfade, so dass bei der sp ¨ ateren Modellpr ¨ ufung lediglich g ¨ ultige Pfade, also solche die im An- fangszustand des Systems beginnen, betrachtet werden. Neben dem Abrollen der 332 6 Hardware-Verifikation Schaltung ¨ uber k Zeitschritte wird die temporallogische Formel, die eine geforderte funktionale Eigenschaft spezifiziert, auf eine Art ¨ ubersetzt, so dass f ¨ ur jeden Zeit- schritt spezielle Bedingungen entstehen. Das iterative Schaltungsmodell wird mit- tels symbolischer Simulation ebenfalls in eine aussagenlogische Formel ¨ ubersetzt. Die Konjunktion beider aussagenlogischer Formeln wird mittels eines SAT-Solvers (siehe Anhang C.2) auf Erf ¨ ullbarkeit ¨ uberpr ¨ uft. Kann keine erf ¨ ullende Variablenbe- legung f ¨ ur die aussagenlogische Formel f ¨ ur k Zeitschritte gefunden werden, muss die Schranke k gegebenenfalls inkrementiert werden, um nach Gegenbeispielen gr ¨ oßerer L ¨ ange zu suchen. Dabei wird mit wachsendem k die Pr ¨ ufung auf Erf ¨ ullbarkeit immer schwieriger. Das folgende Beispiel stammt aus [316]. Beispiel 6.4.5. Ein synchroner, skalierbarer Bus-Arbitrierer hat n Eing ¨ ange (req 0 , , req n−1 ) und n Ausg ¨ ange (ack 0 , ,ack n−1 ) wie in Abb. 6.71b) dargestellt. In je- dem Takt k ¨ onnen mehrere Bus-Anforderungen req i = T gestellt werden. Die Aufga- be des Arbitrierers ist es, genau einem anfragenden Teilnehmer den Bus zuzuteilen ack i = T. Der Aufbau einer einzelnen Arbitriererzelle ist in Abb. 6.71a) dargestellt. Hier wird derjenige Teilnehmer mit h ¨ oherer Priorit ¨ at (kleinerer Index i) den Bus zugeteilt bekommen. Hierzu erh ¨ alt jede Arbitriererzelle i − 1 von der h ¨ oherprioren Arbitriererzelle i das Signal grant in. Sind sowohl Signal grant in i als auch Signal req i auf den Wert T gesetzt, so wird Signal ack i auf T gesetzt. Gleichzeitig wird Si- gnal grant out i auf F gesetzt. Trotz dieser priorit ¨ atsbasierten Arbitrierung garantiert der Arbitrierer, dass jede Bus-Anforderung irgendwann bedient wird und niederprio- re Anfragen nicht aushungern. Dies wird mittels einer Marke bewerkstelligt. Diese Marke wird von der Zelle i zur Zelle i + 1 zyklisch weitergereicht. Hierzu besitzt jede Arbitriererzelle ein Flip-Flop T . Das Flip-Flop T 0 wird zu Beginn auf den Wert T initialisiert, alle anderen Flip-Flops T 1 , ,T n−1 erhalten den Wert F. Wenn eine Arbitriererzelle i die Marke erh ¨ alt, d. h. T i = T und eine Busanforderung (req i = T) vorliegt, wird ein spezielles Bit im Flip-Flop W gesetzt. Dies versetzt die Arbitrierer- zelle in den Zustand ” wartend“. Die Zelle verbleibt in diesem Zustand, so lange die Bus-Anforderung nicht zur ¨ uckgenommen wird. Alle Flip-Flops W i werden zu Be- ginn mit F initialisiert. Wenn die Marke zu dieser Arbitriererzelle zur ¨ uckkehrt, und diese sich weiter im Zustand ” wartend“ befindet, erh ¨ alt diese Zelle unverz ¨ uglich die h ¨ ochste Priorit ¨ at. Dies geschieht, indem die Zelle den Ausgang overrid e out = T setzt. Dies sorgt daf ¨ ur, dass in der h ¨ ochstprioren Arbitriererzelle das grant in-Signal negiert wird. Eigenschaften, die f ¨ ur den skalierbaren Arbitrierer gezeigt werden sollen, sind u. a. [206]: 1. Wechselseitiger Ausschluss: Keine zwei Ausg ¨ ange ack i und ack j mit i = j d ¨ urfen gleichzeitig den Wert T annehmen: G  n  i= j ¬(ack i ∧ ack j )  2. Konservativit ¨ at: Signal ack i wird nur gesetzt, wenn eine Bus-Anforderung req i erfolgte:

Ngày đăng: 02/07/2014, 14:20

Mục lục

    ISBN 978-3-642-05355-9

    1.2.2 Das Doppeldachmodell des Entwurfsprozesses

    1.2.3 Das Doppeldachmodell des Verifikationsprozesses

    1.3 Eine kurze Geschichte der Verifikation

    2.1 Wie spezifiziert man ein System?

    2.4 Formale Spezifikation funktionaler Anforderungen

    2.5 Formale Spezifikation nichtfunktionaler Anforderungen

    3.1 Verifikationsaufgabe, -ziel und -methode

    3.3 Gesteuerte zufällige Simulation

    4.1.3 Reduktion und Normalisierung von TEDs

Tài liệu cùng người dùng

Tài liệu liên quan