Digitale Hardware/ Software-Systeme- P12 pot

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@(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 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 [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: