DE69825372T2

DE69825372T2 - Kommunikationsbussystem

Info

Publication number: DE69825372T2
Application number: DE69825372T
Authority: DE
Inventors: Henricus Rudolf BLOKS; Calto Wong
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 1997-01-10
Filing date: 1998-01-07
Publication date: 2005-07-21
Anticipated expiration: 2018-01-08
Also published as: WO1998031121A2; WO1998031121A3; US6249829B1; JP2000508147A; JP3793238B2; EP0898819B1; DE69825372D1; KR100516538B1; EP0898819A2; KR20000064575A

Description

Die vorliegende Erfindung bezieht sich auf ein Kommunikationsbussystem nach dem Oberbegriff des Anspruchs 1.
Die vorliegende Erfindung bezieht sich ebenfalls auf eine Durchführungsstation zur Verwendung in einem derartigen Kommunikationsbussystem.
Das IEEE 1394 Bussystem ist ein Kommunikationsbussystem (das als ein 1394-System bezeichnet wird) das angewandt werden kann zum Verbinden von Stationen wie Fernsehgeräten und Videorecordern. Abschnitt 8 der IEEE 1394 Norm beschreibt, dass eine Durchführungsstation eine Anzahl Register (CSR) hat. Der Inhalt einiger dieser Register kann in Reaktion auf Beantragungspakete von allen Beantragungsstationen modifiziert werden.
Zur Vermeidung von Fehlern sollte die Beantragungsstation, die ein Beantragungspaket sendet, imstande sein, auf zuverlässige Weise zu bestimmen, ob der Befehl wirklich durchgeführt worden ist, insbesondere, wenn der Effekt einer wiederholten Durchführung des Befehls von dem Effekt eines einzigen Befehls abweicht (beispielsweise im Fall eines Befehls: "Fernsehkanalnummer erhöhen" oder eines Befehls "Kapazität reservieren"). Wenn die Durchführungsstation ein Zustandsregister enthält, das von der Durchführung des Befehls betroffen ist und das von einem Befehl von der Beantragungsstation gelesen werden kann, ist es im Grunde möglich, zu bestimmen, ob der Befehl durchgeführt worden ist, indem der Inhalt des Zustandsregisters überprüft wird. Überprüfung des Inhaltes des Zustandsregisters zum Detektieren der Durchführung wirkt aber nicht zuverlässig, wenn das Bussystem mehr als nur eine Beantragungsstation enthält, die ein Beantragungspaket mit einem Befehl senden kann, der dasselbe Zustandsregister betrifft.
In 1394 sendet die Durchführungsstation nach der Durchführung eines Befehls ein Antwortpaket zu derjenigen Beantragungsstation zurück, die das Beantragungspaket herausgab, worauf der Befehl durchgeführt wurde. Dies ermöglicht es, dass die Beantragungsstation ermittelt, ob der Befehl durchgeführt worden ist, es wirkt aber nicht, wenn die Beantragungsstation das Antwortpaket nicht empfängt.
Es ist nun u. a. eine Aufgabe der vorliegenden Erfindung eine zuverlässigere Art und Weise zu schaffen um zu ermitteln, ob der Befehl auch wirklich durchgeführt worden ist.
Nach der vorliegenden Erfindung wird das Kommunikationsbussystem nach der vorliegenden Erfindung gekennzeichnet durch den kennzeichnenden Teil des Anspruchs 1. Durch Auslesung der Befehlsdurchführungsinformation kann jede einzelne Beantragungsstation überprüfen, ob ein von ihr beantragter Befehl durchgeführt worden ist. Eine spätere Durchführung beantragter Befehle durch andere Beantragungsstationen beeinträchtigt nicht die Befehlsdurchführungsinformation für die betreffende Beantragungsstation und deswegen wird die Zuverlässigkeit der Überprüfung nicht beeinträchtigt.
Das Kommunikationsbussystem nach der vorliegenden Erfindung hat eine Ausführungsform, wie diese in Anspruch 6 beschrieben worden ist. Bei dieser Ausführungsform kann eine bestimmte Beantragungsstation mehrere Beantragungspakete, die Durchführung verschiedener Befehlstypen beantragen ausgeben und überprüfen, ob die entsprechenden Befehle durchgeführt worden sind, nachdem alle Beantragungspakete ausgegeben worden sind. Dies bedeutet, dass die Beantragungspakete schnell nacheinander als ein kohärenter Vorgang ausgegeben werden können, ohne Unterbrechung zur Überprüfung. In einem 1394 System beeinträchtigt jeder Befehlstyp beispielsweise ein anderes CSR und das Kommunikationsbussystem behält Information für jede betreffende Beantragungsstation über die zuletzt durchgeführte Modifikation der CSR, welche diese betreffende Beantragungsstation beantragt hat.
Es können verschiedene Formen von Befehlsdurchführungsinformation gespeichert werden. Wenn die Beantragungsstation in jedem Paket eine betreffende Paketidentifikation enthält, kann die gespeicherte Befehlsdurchführungsinformation diese Paketidentifikation enthalten. Dies ermöglicht es, die Durchführung jedes Befehls zu jeder Zeit zu überprüfen. Die gespeicherte Befehlsdurchführungsinformation kann Information über den Zustand der Durchführungsstation unmittelbar nach der Durchführung oder Information über die Ergebnisse der Durchführung enthalten. Dies ermöglicht es, dass die Beantragungsstation die Durchführung des Befehls so detailliert wie nur erwünscht, beispielsweise detaillierter als in einer Standardantwort von der Durchführungsstation, analysieren kann. Diese Befehlsdurchführungsinformation kann für alle Beantragungspakete, die von der Durchführungsstation empfangen werden, gespeichert gehalten werden, oder sie kann für eine vorbestimmte Anzahl Beantragungspakete gespeichert gehalten werden, für welche die Befehle erste gerade durchgeführt worden sind. Auf diese Weise können ältere Befehle analysiert werden.
Die Befehlsdurchführungsinformation kann verschiedenartig gespeichert werden. Jeder Beantragungsstation kann ein betreffendes vorbestimmtes Speichergebiet in der Durchführungsstation zugeordnet werden. Wenn ein Befehl in Reaktion auf ein Beantragungspaket von einer bestimmten Beantragungsstation durchgeführt wird, kann die Durchführungsstation die Befehlsdurchführungsinformation für diese Durchführung verwenden um Befehlsdurchführungsinformation zu überschreiben, die in dem Speichergebiet gespeichert ist, das der betreffenden Beantragungsstation zugeordnet wurde. Auf diese Weise enthält das Speichergebiet immer die Befehlsdurchführungsinformation für den jüngsten durchgeführten Befehl für diese betreffende Station (oder Initialisierungsinformation, gespeichert durch die Durchführungsstation vor dem Empfang eines Beantragungspaketes). Das jeder betreffenden Station zugeordnete Speichergebiet kann in Speicherteilgebiete für verschiedene Befehlstypen aufgeteilt sein, wobei die Durchführungsstation nur das Speicherteilgebiet für den Befehl, der durchgeführt wird, überschreibt.
In einer bevorzugten Ausführungsform wird nur ein einziges logisches Bit je Befehlstyp für jede Beantragungsstation gespeichert. Wenn die Durchführungsstation in Reaktion auf den Beantragungspaket von einer bestimmten Beantragungsstation erfolgreich einen Befehl durchgeführt hat, setzt die Durchführungsstation das logische Bit für diese betreffende Beantragungsstation (und für den Befehlstyp, wenn mehr als nur ein Befehlstyp aufgezeichnet wird). In diesem Fall muss die Durchführungsstation auch imstande sein, das logische Bit zurückzusetzen, vorzugsweise in Reaktion auf ein Signal von der betreffenden Beantragungsstation. In dem 1394 System kann dieses Signal beispielsweise erzeugt werden, wenn die betreffende Beantragungsstation das CSR ausliest, dessen Modifikation durch das logische Bit aufgezeichnet wird.
Das Auslesen der Befehlsdurchführungsinformation wird vorzugsweise durch ein Auslesepaket ausgelöst, das von der Beantragungsstation über die Busverbindung der Durchführungsstation zugeführt worden ist. In Reaktion auf dieses Auslesepaket ermittelt die Durchführungsstation, von welcher Beantragungsstation das Auslesepaket geliefert worden ist, liest die Befehlsdurchführungsinformation, die für diese Beantragungsstation gespeichert worden ist und sendet unter Ansteuerung dieser Befehlssteuerinformation über den Verbindungsbus der Beantragungsstation ein Zustandspaket zu.
Vorzugsweise wird die Speicherung von Befehlsdurchführungsinformation kombiniert mit der Übertragung von Antwortpaketen durch die Durchführungseinheit. Dies bietet der Beantragungsstation die Möglichkeit, bei kritischer Durchführung von Befehlen zu überprüfen, wenn kein Antwortpaket empfangen wird.
Diese und andere vorteilhafte Aspekte der vorliegenden Erfindung sind auf eine nicht begrenzende Weise unter Verwendung einer einzigen Figur, die ein Kommunikationsbussystem nach der vorliegenden Erfindung zeigt, beschrieben.
Die Figur zeigt ein Kommunikationsbussystem nach der vorliegenden Erfindung. Das Kommunikationsbussystem enthält eine Durchführungsstation B, Beantragungsstationen A, 14 und einen Verbindungsbus 12. Die Durchführungsstation B enthält eine Paketempfangs/Interpretationseinheit 102, eine Befehlsdurchführungseinheit 104, einen Befehlsdurchführungsinformationsspeicher 106 und eine Paketerzeugungs/Sendeeinheit 108.
Das Kommunikationsbussystem benutzt beispielsweise das in der IEEE 1394 Norm spezifizierte Protokoll. Der IEEE-1394 serielle Hochgeschwindigkeitsbus benutzt einen Transaktionsmechanismus, der es ermöglicht, dass jede Anordnung (Station) A, B, 14 am Bus 12 automatisch Lese-Modifizier-Schreibvorgänge au jeder beliebigen Speicherstelle schreiben, lesen oder durchführen kann oder in jeder anderen Station A, B, 14 steuern und den Zustand registrieren kann. Es gibt keinen Unterschied zwischen CSRn und dem Speicher in 1394, da CSR speicherorientiert sind.
Um die Station eine Transaktion zu der Station B durchführen zu lassen, ist die typische Sequenz, dass die Station A der Station B ein Beantragungspaket zusendet, dass B eine Empfangsbestätigung zurücksendet, danach die beantragte Funktion durchführt (nimmt Zeit), dann ein Antwortpaket mit dem Funktionsergebnis oder mit einem Zustand über die Durchführung sendet, wonach A eine Empfangsbestätigung für das Antwortpaket zu B zurücksendet.
Die Beantragungs- und Antwortpakete enthalten Identifikationen des Senders (A in dem Antrag, B in der Antwort), des bestimmten Empfängers (B in dem Antrag, A in der Antwort), eine Folgenummer für diese Transaktion von A nach B und Daten (Funktion, Ergebnisse, Zustand, usw.). Diese Pakete werden ebenfalls durch einen CRC Fehlerdetektionscode geschützt, wodurch der Empfänger Paketverfälschung detektieren kann.
Die Bestätigungspakete enthalten keinen der oben genannten Kennzeichen, nur die Zustandsinformation und einen sehr einfachen Fehlerdetektionscode.
Es wurde ein Problem entdeckt bei Transaktionen, die CSR ändern, wenn die Pakete (Antrag/Antwort/Bestätigung) verfälscht oder aus irgendeinem Grund an dem Bus verloren gehen können. Dieses Problem führt zu Inkonsistenz in der Information über den Zustand des CSRs (und der Nebeneffekte desselben) für den Beantragungsteller (A) und den Beantworter (B).
Beispiel 1:
Die Station enthält eine allgemeinen Busquelle, die verfügbare Bandbreite für isochrone Datenübertragung angibt. Die Station A möchte einen Teil dieser Bandbreite zuordnen und sendet ein Beantragungspaket zu B, das eine sog. Vergleich-Tauasch-Verriegelungsfunktion enthält, die versucht, den Betrag an verfügbarer Bandbreite um den beantragten Betrag zu reduzieren. Ein Antwortpaket, das B zu A zurücksendet, gibt an, ob die Zuordnung erfolgreich war und folglich, ob ggf. A nun die Bandbreite besitzt und diese benutzen kann. Es wird nun vorausgesetzt, dass der Antrag ohne Fehler bei B eintrifft und durchgeführ wird und erfolgreich ist (Bandbreite wird A zugeordnet). Das Antwortpaket wird zu A zurückgesendet, erreicht sie aber nie, sogar nicht nach etwaiger Neuübertragung durch B. A weiß nicht, ob sie Bandbreite erhalten hat und wird nie die Zuordnung aufheben: der beantragte Betrag ist einfach für isochrone Daten nicht länger verfügbar.
Beispiel 2:
Station B ist ein Fernsehgerät, das ein CSR implementiert, das, wenn dorthin geschrieben wird, den nächsten Kanal selektiert. Wenn A eine Schreibtransaktion zu B sendet um den nächsten Kanal zu schalten, aber wird nie klug daraus, ob der Befehl auch wirklich durchgeführt worden ist, denn sie könnte entscheiden den Befehl zu wiederholen, wenn vorausgesetzt wird, dass etwas daneben gegangen ist. Es ist möglich, dass das Fernsehgerät B eine Funktion "Kanal aufwärts" zweimal durchgeführ hat und nun den falschen Kanal zeigt.
Transaktionen, die ein CSR nicht ändern und die überhaupt keine Nebeneffekte haben, leiden nicht an diesem Problem, da diese auf sichere Weise neu versucht werden können, wenn der Beantragungsteller erwartet, dass etwas daneben gegangen ist. Transaktionen, die CSR ändern und/oder Nebeneffekte haben, können für einige Anord nungen (Beispiel 2) zu unerwünschten Ergebnissen führen oder sogar zu einem Fehlverhalten des ganzen Busses (Beispiel 1).
Das Problem wird vorwiegend verursacht durch die Tatsache, dass die einzige Möglichkeit für einen Beantragungsteller die Ergebnisse seines Beantragungs herauszufinden, ist, dass er die Antwort erhält. Wenn die Antwort verloren gegangen ist, gibt es keine Möglichkeit, die Information nachher von der antwortenden Station abzufragen. Das Auslesen des CSRs, von dem angenommen wurde, dass es geändert ist, ist nicht eine Lösung, weil andere Stationen es inzwischen haben ändern können, oder das Auslesen kann Nebeneffekte haben, die unerwünscht sind.
Durch Fehler im Netzwerk gibt es nach der Transaktion die nachfolgenden Zustände:
S1: die Transaktion ist durchgeführt und der Beantragungsteller weiß es.
S2: die Transaktion ist nicht durchgeführt und der Beantragungsteller weiß es.
S3: die Transaktion ist durchgeführt aber der Beantragungsteller weiß es nicht.
S4: die Transaktion ist nicht durchgeführt aber der Beantragungsteller weiß es
nicht.
Der Ausdruck "durchgeführ" bedeutet in dem vorliegenden Fall, dass die Funktion entsprechend der Transaktion durchgeführt wurde, ungeachtet, ob dies zu einer Änderung des CSR-Wertes geführt hat.
Für den Beantragungsteller sind S3 und S4 nicht unterscheidbar: er weiß ganz einfach nicht, ob der Antrag durchgeführt wurde. Dies sind die Problemfälle wenn die Transaktion von einem Typ war, der zu einer Änderung in dem CSR-Wert hätte führen können oder wenn es Nebeneffekte gegeben hat. S1 und S2 können unmittelbar von dem Beantragungsteller behandelt werden und bilden kein Problem.
Die Lösung dieses Problems ist der folgende Konzept:
Jede beliebige Durchführungsstation, die ein CSR implementiert, das vor dem oben genannten Problem geschützt werden soll, speichert vorzugsweise das Ergebnis oder den Zustand von Transaktionen, die empfangen und durchgeführt wurden (ob erfolgreich oder nicht) von einer externen Station, so dass sie nachher von dieser Station abgefragt werden können. Dazu enthält die Durchführungsstation 10 einen Befehlsdurchführungsinformationsspeicher 106. Im Betrieb empfängt die Paketempfangs/Übersetzungseinheit 102 Pakete von dem Bus 12 und interpretiert sie wie folgt. Zunächst bestimmt die Ein heit 102 ob das Paket die Durchführungsstation 10 als bezeichneter Empfänger spezifiziert. Sollt dies der Fall sein, so extrahiert die Einheit 102 Information aus dem Paket, die bestimmt, welcher Befehl durchgeführt werden soll und liefert diese Information zu der Befehlsdurchführungseinheit 104, die den Befehl durchführt. Ein Ergebnis der Durchführung wird dem Befehlsdurchführungsinformationsspeicher 106 zugeführt und darin gepeichert, wenn die Einheit 102 signalisiert, dass der Befehl durchgeführt worden ist.
Die Durchführungsstation 10 definiert vorzugsweise ein "Error Status Register" (ESR) in dem CSR Raum, auf den mit einer LeseBeantragungstransaktion von jeder Beantragungsstation zugegriffen werden kann und auf Information in dem Befehlsdurchführungsspeicher 106 zugreift. Eine derartige Station kann auf diese Weise den Zustand eine der vorhergehend beantragten Transaktionen auslesen. Das Auslesen des ESRs an sich hat keine Nebeneffekte. Der Zustand der Beantragungsstation kann dadurch gelöscht werden, dass die Beantragungsstation dem ESR (ungeachtet der geschriebenen Daten) unter Anwendung einer SchreibBeantragungstransaktion schreibt. Eine Beantragungsstation kann unter Anwendung dieses Mechanismus nur Zustandsinformation über die eigenen Transaktionen löschen.
In dem 1394 System ermöglicht die Tatsache, dass jeder Antrag die Bezeichnung der Beantragungsstation enthält, dass ein Responder einer derartigen Transaktion die Zustandsinformation zusammen mit einem Kennzeichen, das einzigartig die Transaktion identifiziert (d.h. das Adresskennzeichen der Beantragungsstation und die Transaktionsfolgenummer). Diese Information kann auch in dem Antwortpaket zurückgesendet werden.
Der Unterschied zwischen den oben genannten Zuständen S3 und S4 ist an der antwortenden Station verfügbar und erinnert dort für eine spätere Suche durch den Beantragungsteller im Falle es in einem dieser Zustände endet.
Da alle Stationen an dem Bus unabhängig voneinander Transaktionen zu einem einzigen CSR in einer bestimmten Station durchführen können, muss sich diese Station den Zustand von Transaktionen für jede Station erinnern können. Wenn eine Station später das ESR liest, wird sie nur den Zustand für die eigenen Transaktionen erhalten, nicht von denen, die von anderen Stationen beantragt wurden.
Ausführungsformen
A. Speicherung des Zustandes (wie oft zu speichern)

A1. In der meist allgemeinen Implementierung erinnert sich die Station alle einzigartig identifizierbaren Transaktionen aller Stationen. In IEEE 1394 ist eine Stationsadresse 16 Bits und die Transaktionsfolgenummer ist 6 Bits. Dies führt zu einer "schlimmsten-Fall"-Situation, in der 2^22 Zustandswerte gespeichert werden sollen.
A2. Es ist nicht notwendig eine derartige Speichermöglichkeit auch wirklich zu implementieren. Nut Daten für wirkliche Transaktionen sollen gespeichert werden, was, wie erwartet, viel weniger ist (Indikation: bis einige Tausend für "very high end" Implementierungen).
A3. Eine einfachere Methode ist, nur den Zustand der letzten je Station durchgeführten Transaktion zu speichern und dies nur für Stationen an dem Ortsbus zu unterstützen, nicht aber für andere Stationen, die durch Brücken verbunden sind. Dies reduziert die Speicheranforderungen auf nicht mehr als 62 Stellen.

B. Darstellung des Zustandes (was muss gespeichert werden)

B1. Die meist allgemeine Implementierung würde den ganzen Ergebniszustand einer Transaktion speichern, d.h. wenn das ursprüngliche Beantragungspaket empfangen wurde, dann ist Information über die nachfolgenden Ereignisse verfügbar: durchgeführt oder nicht, warum nicht durchgeführt, Fehler bei der Lieferung eines Antwortpakets, usw. Für IEEE 1394 würde es ausreichen, den ursprünglichen Antwortcode aufzuzeichnen, der in einem Antwortpaket zu dem Beantragungsteller geliefert werden sollte, zusammen mit zusätzlicher Information, wesentlich für den Beantragungsteller um eine Entscheidung zu treffen: beispielsweise CSR modifiziert in einer Verriegelungstransaktion (nicht in dem Antwortcode dargestellt) oder Nebeneffekt des Beantragungs auf CSR durchgeführt.
B2. Eine einfachere Implementierung kann ausreichen durch Aufzeichnung nur der Information über den Konzeptzustand des Responders, wenn er startet, ein Antwortpaket zurückzusenden (S3 oder S4, wie oben angegeben), und nichts anderes. Dies kostet nur 1 Speicherbit je Transaktion. Insbesondere in Kombination mit Option A3 sind die Speicheranforderungen minimal. Da aber das ursprüngliche Merkmal, das einzigartig die Transaktion identifiziert, nicht erinnert wird, ist es nicht klar, ob der wirklich erinnerte Zustand für eine Station X zu dem letzten übertragenen Beantragungspaket der Station X gehört (wenn dieses Paket verloren gegangen ist, dann wird der Zustand dennoch das Ergebnis des vorher empfangenen Beantragungs von der Station X reflektieren). Für diese Implementierung muss der Fehlerzustand zu einem sicheren Wert gelöscht werden (ent sprechend dem Konzeptzustand S4) bevor die unsichere neue Transaktion versucht wird (nur wenn es noch nicht in diesem Zustand ist). Eine Art und Weise dies mit minimalen Kosten zu tun, ist zu definieren, dass jede Transaktion ohne Nebeneffekte auf das geschützte CSR zu einer Änderung des aufgezeichneten Zustandes zu S4 führt, was als "keine Nebeneffekte aus der letzten empfangenen Transaktion". In IEEE 1394 würde eine ausgelesene Transaktion typischerweise keine Nebeneffekte haben. Gleichzeitig ist es die Standartart einen der Datenwerte, erforderlich für eine Vergleiche-Tausche-Verriegelungstransaktion, zu erhalten. Dies ist was diese Mechanismen sehr geeignet macht für Implementierung in IEEE 1394 zum Schützen dieser Art von CSR.

C. Zugriff auf den Zustand (wie soll es verfügbar gemacht werden)
Implementierungen um den Zustand verfügbar zu machen kann jede beliebige Form haben, soll aber standardisiert werden (das Verfahren darauf zuzugreifen, das Format, in dem die Information zurückkehrt und möglicherweise die Offsetadresse der Station, assoziiert mit jedem ESR).

C1. Die meist universelle Lösung ist, wobei jede Station den Transaktionszustand jeder beliebigen Station herausfinden kann, und zwar unter Verwendung von Auslesetransaktionen (ohne Nebeneffekte) auf ein speziell eingeführtes Zustandsregister, das als "Error Status Register" (ESRR) Fehlerzustandsregister bezeichnet wird, das an sich ein CSR ist, wie in der IEEE 1212 und der IEEE 1394 Architektur definiert. Daten in der ausgelesenen Transaktion müssen verwendet werden zum Indizieren in dem Speicher zum Zugreifen auf den erwünschten Zustand. Dies ist nicht leicht zu implementieren mit den aktuellen 1394 Transaktionen.
C2. Da C1 unnötig komplex ist, ist es besser Lösungen zu erforschen, wobei jede beliebige Station nur auf die Ergebnisse der eigenen Transaktionen zugreifen kann. Dadurch, dass eine Lesetransaktion in dem ESR durchgeführt wird, kann der Responder die Stationsadresse des Senders (Beantragungstellers) in dem Transaktionspaket verwenden um den richtigen Zustandswert zu selektieren und diesen als gelesene Antwort zurückzusenden. Information darüber, von welcher Transaktion aus der Vergangenheit der Zustand zurückgesendet werden soll kann nicht in dem Lesetransaktionspaket eingeschlossen sein, es sei denn, dass das ESR eine Reihe von Adressen hat und die Adresse als Index verwendet wird. Dies ist nicht erwünscht, da es viele ESR geben kann, die je nur ein anderes CSR (Adresse) schützen. Eine Option ist, den Zustand für alle (bis zu 63) vorhergehen den Transaktionen zurückzusenden und den Beantragungsteller die richtige selektieren zu lassen.
C3. Eine weitere Vereinfachung ist in Kombination mit A3 möglich. Wenn nur der Zustand der letzten Transaktion gespeichert wird, wird das in C2 genannte Problem vermieden und eine einzige Adresse ESR reicht. Paketgrößen und Gemeinkosten werden in dem Fall minimal sein.
C4. In Kombination mit B2 und A3 wäre eine sehr einfache Implementierung zum Implementieren des ESRs als ein 63 Bit Register, wobei das Bit k den Zustand der letzten von der örtlichen Station durchgeführten Transaktion darstellt. Eine logische 0 könnte benutzt werden um anzugeben "kein Nebeneffekt/nicht durchgeführt" und eine logische 1 um anzugeben "CSR modifiziert/Nebeneffekt". Dies ist der einfachste und wahrscheinlich der aussichtsreichster Kandidat zur Implementierung.

Claims

Kommunikationsbussystem, das die nachfolgenden Elemente umfasst: – einen Bus (12) – Beantragungsstationen (A, 14) die mit dem Bus gekoppelt sind, und die je imstande sind, ein betreffendes Beantragungspaket über den Bus auszusenden, – eine Durchführungsstation (B), die mit dem Bus gekoppelt ist zum Empfangen der betreffenden Beantragungspakete, wobei die Durchführungsstation bei Empfang jedes der genannten betreffenden Beantragungspakete einen betreffenden Befehl ausführt, wobei die betreffenden Befehle blichen Aspekt eines Zustandes der Durchführungsstation modifiziert, wobei die Durchführungsstation Information in Bezug auf den üblichen Aspekt enthält, wobei die Beantragungsstationen imstande sind, aus der genannten Information in Bezug auf den üblichen Aspekt zu lesen; dadurch gekennzeichnet, dass die Information in Bezug auf den üblichen Aspekt auch Information für wenigstens zwei verschiedne Stationen der Beantragungsstationen enthält, und zwar in Bezug auf die Durchführung der betreffenden Befehle, die in Reaktion auf die betreffenden Beantragungspakete von den zwei verschiednen Stationen der Beantragungsstationen zuletzt durchgeführt wurden.
Kommunikationsbussystem nach Anspruch 1, wobei die Beantragungsstationen imstande sind, betreffende ausgelesene Pakete zu der Durchführungsstation weiter zu leiten, wobei jedes ausgelesene Paket Information enthält, welche die betreffende Beantragungsstation identifiziert, die das ausgelesene Paket gesendet hat, wobei die Durchführungsstation auf das ausgelesene Paket reagiert, durch – Selektion der Information in Bezug auf die Durchführung des Befehls, der als letzter in Reaktion auf das Beantragungspaket von dieser betreffenden Beantragungsstation durchgeführt wurde, – Konstruktion eines Zustandspakets unter Verwendung der selektierten Information, – Zurückführung des Zustandspakets.
Kommunikationsbussystem nach Anspruch 1, wobei die Durchführungsstation die Information in Bezug auf die Durchführung eines Befehls, der in Reaktion auf ein vorhergehendes Paket der betreffenden Beantragungspakete von einer betreffenden Beantragungsstation durchgeführt worden ist, mit Information in Bezug auf die Durchführung eines Befehls überschreibt, der in Reaktion auf einen späteren Antrag der betreffenden Anträge von dieser betreffenden Beantragungsstation durchgeführt worden ist.
Kommunikationsbussystem nach Anspruch 1, wobei die Information in Bezug auf die Durchführung der betreffenden Befehle ein Informationsbit enthält für jede Station der genannten wenigstens zwei verschiedene Stationen der Beantragungsstationen, wobei die Durchführungsstation das Bit setzt, wenn ein Befehl in Reaktion auf ein Beantragungspaket herrührend von der entsprechenden Beantragungsstation, erfolgreich durchgeführt wurde.
Kommunikationsbussystem nach Anspruch 4, wobei die genannten Befehle einen Inhalt eines Registers modifizieren, wobei das Informationsbit zurückgesetzt wird, wenn der genannte Inhalt von der betreffenden Beantragungsstation ausgelesen wird.
Kommunikationsbussystem nach Anspruch 1, wobei die Durchführungsstation imstande ist, verschiedene Befehlstypen durchzuführen, wobei jeder Befehlstyp eignen eigenen Aspekt des Zustandes der Durchführungsstation modifiziert, wobei jede Beantragungsstation imstande ist, verschiedene Beantragungspakettypen zu liefern, wobei jeder Beantragungspakettyp die Durchführung eines betreffenden Typs der verschiedenen Befehlstypen beantragt, wobei die Durchführungsstation einen Befehl von dem Typ durchführt, der bei Empfang dieses bestimmten Beantragungspakets von einem bestimmten Beantragungspaket beantragt wird, wobei die antwortende Station gleichzeitig Befehlsdurchführungsinformation für jeden Befehlstyp in Bezug auf die Durchführung betreffender Beantragungspakete von den wenigstens zwei verschiedenen Stationen der Beantragungsstationen beibehält.
Durchführungsstation (B) zur Verbindung mit einem Bus (12), wobei diese Durchführungsstation zum Empfangen der betreffenden Beantragungspakete von den ver schiedenen Beantragungsstationen (A, 14) über den Bus vorgesehen sind, wobei die Durchführungsstation bei Empfang jedes der genannten betreffenden Beantragungspakete einen betreffenden Befehl durchführt, wobei die betreffenden Befehle einen allgemeinen Aspekt eines Zustandes der Durchführungsstation modifiziert, wobei die Durchführungsstation In Formation in Bezug auf den allgemeinen Aspekt beibehält, wobei die Beantragungsstationen imstande sind, aus der genannten Information Information in Bezug auf den allgemeinen Aspekt zu lesen; dadurch gekennzeichnet, dass die Information in Bezug auf den allgemeinen Aspekt gleichzeitig Information für wenigstens zwei verschiedene Stationen der Beantragungsstationen in Bezug auf Durchführung betreffender Befehle enthält, die als letzte in Reaktion auf betreffende Beantragungspakete von den zwei verschiedenen Stationen der Beantragungsstationen durchgeführt wurden.
Durchführungsstation nach Anspruch 7, wobei die Beantragungsstationen imstande sind, betreffende ausgelesene Pakete zu der Durchführungsstation zu schicken, wobei jedes ausgelesene Paket Information enthält, welche die betreffende Beantragungsstation identifiziert, die dieses ausgelesene Paket gesendet hat, wobei die Durchführungsstation das ausgelesene Paket beantwortet durch: – Selektion der Information in Bezug auf die Durchführung des als letzter durchgeführten Befehls in Reaktion auf das Beantragungspaket von dieser betreffenden Beantragungsstation, – Konstruktion eines Zustandspakets unter Verwendung der selektierten Information, – das Zurückführen des Zustandspakets.
Durchführungsstation nach Anspruch 7, wobei die Durchführungsstation die Information in Bezug auf die Durchführung eines Befehls, der in Reaktion auf ein vorhergehendes Paket der betreffenden Beantragungspakete von der betreffenden Beantragungsstation durchgeführt wurde, mit Information in Bezug auf die Durchführung eines Befehls überschreibt, der in Reaktion auf einen späteren Antrag der betreffenden Anträge von dieser betreffenden Beantragungsstation durchgeführt wurde.
Durchführungsstation nach Anspruch 7, wobei die Information in Bezug auf die Durchführung der betreffenden Befehle ein Informationsbit für jede der genannten wenigstens zwei verschiedene Stationen der Beantragungsstationen enthält, wobei die Durchführungsstation das Bit setzt, wenn in Reaktion auf ein Beantragungspaket, herrührend von der betreffenden Beantragungsstation ein Befehl erfolgreich durchgeführt wurde.