DE69133444T2

DE69133444T2 - Kommunikationsschnittstelle

Info

Publication number: DE69133444T2
Application number: DE69133444T
Authority: DE
Inventors: Robert J. Simpson
Original assignee: STMicroelectronics Ltd Great Britain; SGS Thomson Microelectronics Ltd
Current assignee: STMicroelectronics Ltd Great Britain
Priority date: 1990-05-25
Filing date: 1991-05-22
Publication date: 2006-05-11
Anticipated expiration: 2011-05-23
Also published as: EP0971501B1; EP0458648A2; EP0971502A2; DE69133444D1; US5341371A; JP3359346B2; DE69132131T2; EP0971501A2; DE69133518D1; EP0971502A3; EP0971501A3; JPH04232553A; DE69132131D1; EP0971502B1; EP0971503B1; GB9011700D0; EP0458648A3; DE69133505D1; DE69133518T2; EP0458648B1

Description

Die Erfindung bezieht sich auf Kommunikationsinterfaces bzw. Kommunikationsschnittstellen und ist vor allem auf Kommunikationsinterfaces, die mit Computern benutzt werden, und für die Übermittlung von Nachrichten zwischen Computern oder Computern und anderen Vorrichtungen, die damit verbunden sind, anwendbar.
Computervorrichtungen und andere Vorrichtungen mit integrierten Schaltkreisen können es brauchen, Nachrichten zu übermitteln oder Nachrichten von anderen Vorrichtungen zu empfangen. In einigen Fällen kann die Nachrichtenübermittlung zwischen zwei miteinander verbundenen Vorrichtungen oder zwischen einer größeren Zahl von Vorrichtungen, die ein Netzwerk bilden, auftreten. In solch einem Netzwerk können eine oder mehrere Vorrichtungen in der Form eines Computers sein bzw. vorliegen, und andere Vorrichtungen können eine Vielzahl von peripherer Ausrüstung bzw. Peripheriegeräten umfassen. Solche Netzwerke können Routing- bzw. Leit-Schalter beinhalten, um einen weiten Bereich von Verbindungen über das Netzwerk zu erlauben. Die Übermittlung von Daten zwischen solchen verbundenen Vorrichtungen kann durch Benutzen von parallelen Datenbussen oder von seriellen Kommunikationsdrähten bzw. Kommunikationsleitungen erreicht werden. Komplikationen treten auf beim Kontrollieren von Bussen in solchen Netzwerkverbindungen, und darüber hinaus ist die Geschwindigkeit einer Operation insbesondere dann beschränkt, wenn eine Vielzahl von Vorrichtungen in dem Netzwerk verbunden sind.
Die US 4,397,020 bezieht sich auf das Überwachen von Fehlern bei digitaler Übermittlung in einem schaltkreisgeschalteten drahtlosen Kommunikationsnetzwerk durch Einsetzen einer zyklischen Redundanzüberprüfung (CRC). Ein CRC-Kodewort, das eine vorbestimmte Anzahl von Bits hat, wird von einem Block aus Bits eines gegenwärtig übermittelten Zeitmultiplexsignals generiert. Die Bits des Kodewortes werden in vorbestimmte Bitpositionen des nächsten Blocks von Bits eingefügt, und ein Emp fänger vergleicht die empfangenen Zeitmultiplexsignale mit Bits eines CRC-Kodewortes, die von dem zuletzt empfangenen Block von Bits erzeugt worden sind, um Fehler in der Übermittlung anzuzeigen.
Die EP-A-0 257 816 bezieht sich auf einen N-Eingabe-, N-Ausgabe-Knockout-Paket- bzw. N-Ausgabe-Auswurf-Datenpaket-Schalter, der eine dezentralisierte Kontrolle und verteiltes Routing bzw. Leiten zum Routing bzw. Leiten von zeitmultiplexten Hochgeschwindigkeits-Paketen bzw. -Datenpaketen mit variabler Länge von Information von den N-Eingaben zu den N-Ausgaben benutzt.
Es ist eine Aufgabe der vorliegenden Erfindung, ein einfaches Hochgeschwindigkeitsinterface zwischen Kommunikationsvorrichtungen bereitzustellen, die Pakete bzw. Datenpakete benutzen. Es ist eine Aufgabe, eine Hochgeschwindigkeitsoperation ohne Datenverlust zu ermöglichen und es zu erlauben, dass Nachrichten variabler Länge in einer Multipaketform bzw. in Form von mehreren Paketen bzw. Datenpaketen übermittelt werden. Dies ist vorteilhaft, weil es jedem Interface erlaubt, Pakete bzw. Datenpakete von unterschiedlichen Nachrichten sukzessive zu behandeln, bevor die Übermittlung aller Pakete bzw. Datenpakete einer jeden Nachricht vollständig ist.
Es ist eine Aufgabe der Erfindung, ein bidirektionales Kommunikationsinterface bereitzustellen, wobei vier unidirektionale bzw. einseitig gerichtete Signalleitungen benutzt werden.
Die Erfindung stellt ein Kommunikationsinterface zur Benutzung in einem Kommunikationssystem bereit, wobei das Interface umfasst: einen Ausgabeschaltkreis zum Ausgeben von Nachrichten, wobei der Ausgabeschaltkreis einen Kontrollschaltkreis und einen Kodierungsschaltkreis zum Kodieren und Ausgeben einer Folge von Tokens, die jeweils eine fortlaufende Bitzeichenkette umfassen, umfasst; einen Eingabeschaltkreis zum Eingeben von Nachrichten, wobei der Eingabeschaltkreis einen Dekodierungsschaltkreis zum Eingeben und Dekodieren von Daten, die in jedem seriellen Token empfangen worden sind, beinhaltet; dadurch gekennzeichnet, dass das Kommunikationsinterface so angepasst ist, dass ein Computer mit mindestens einem anderen Gerät verbunden wird, wobei jede Nachricht eine Folge von Tokens variabler Bitlänge umfasst, wobei jeder Token ein Paritätsbit und wenigstens ein anderes Bit hat, das einen Bitlängenindikator für den Token formt; der Ausgabeschaltkreis umfasst einen Paritätsbiterzeuger, der auf die nachfolgenden Bits nach dem Bitlängenindikator in einem ersten Token bis einschließlich eines Bitlängenindikators in einem zweiten Token anspricht, und der so eingerichtet ist, das Paritätsbit zur Aufnahme jeden Token zu erzeugen; und der Eingabeschaltkreis umfasst einen Paritätsprüfungsschaltkreis zum Detektieren des Paritätsbits in jedem Token und zum Vergleichen besagten Paritätsbits mit einem Bitmustern nach einem Bitlängenindikator in einem Token bis einschließlich zum nächsten Bitlängenindikator.
Bevorzugt ist der Kontrollschaltkreis arrangiert, um Daten in dem Datensignal in Tokens einer vorbestimmten Bitlänge auszugeben.
Bevorzugt ist der Kontrollschaltkreis betriebsfähig, Token von mehr als einer vordefinierten Bitlänge auszugeben.
Bevorzugt beinhaltet der Kontrollschaltkreis einen Paritätsbiterzeuger, um ein Paritätsbit zum Einschluss bzw. zur Einfügung in jeden Token zu erzeugen.
Bevorzugt beinhaltet der Kontrollschaltkreis einen Flaggenbiterzeuger zum Erzeugen eines Flaggenbits zum Einschluss bzw. zur Einfügung in jeden Token zur Identifizierung jedes Tokens als Datentoken oder als Kontrolltoken.
Bevorzugt stellt das Flaggenbit eine Anzeige der Tokenlänge in dem vorhergehenden Token bis einschließlich zum Flaggenbit des einen Tokens bereit.
Bevorzugt ist der Kontrollschaltkreis arrangiert, um Kontrolltoken und Datentoken bereitzustellen, wobei jedes eine entsprechende vordefinierte Bitlänge hat, jeder Datentoken hat eine größere Bitlänge als ein Kontrolltoken.
Bevorzugt beinhaltet der Eingabeschaltkreis einen Verzögerungsschaltkreis, der zwischen jedem der zwei Eingaben bzw. Inputs und dem Entschlüsseler angeschlossen ist, und Mittel zum Variieren der Verzögerung auf einem oder beiden der Eingaben bzw. Inputs vor dem Dekodieren.
Bevorzugt beinhaltet der Ausgabeschaltkreis Flusskontrollmittel zum Erzeugen von Flusskontrolltokens zum Ausgeben an ein angeschlossenes Kommunikationsinterface und besagter Eingabeschaltkreis beinhaltet Mittel, die auf die Eingabe eines Flusskontrolltokens durch Ausgeben weiterer Datensignale ansprechen, um den Betrieb des Ausgabeschaltkreises zu kontrollieren.
Bevorzugt beinhaltet der Eingabeschaltkreis Speichermittel zum Vorhalten einer Vielzahl von Datensignalen, und die Flusskontrollmittel sprechen auf die Inhalte besagter Registermittel an.
Bevorzugt ist der Kodierungsschaltkreis arrangiert, um einen Header bzw. eine Überschrift für jeden kodierten Token bereitzustellen, wobei der Header bzw. die Überschrift sowohl das Paritätsbit als auch das Flaggenbit umfasst.
Bevorzugt ist der Paritätsbiterzeuger mit dem Dekodierer so gekoppelt, dass er auf die Anzahl des Bits, die in einem ersten Token nach einem Flaggenbit in dem ersten Token kodiert sind, anspricht, und dass er ein Paritätsbit an einer ersten Stelle eines zweiten Tokens bereitstellt, das den Gesamtwert der Anzahl von Bits von dem ersten Token zusammen mit dem Paritäts- und Flaggenbit des zweiten Tokens anzeigt.
Die Erfindung stellt auch ein Verfahren zum Bewirken einer bidirektionalen Kommunikation zwischen wenigstens zwei miteinander verbundenen Vorrichtungen bereit, wobei wenigstens eine der Vorrichtungen einen Computer umfasst, das Verfahren umfasst das Aufbauen von parallelen Datensignal- und Abtastsignal-Kommunikationspfaden zwischen zwei Linkinterfaces, wobei jedes mit der jeweiligen Vorrichtung verbunden ist, das Kodieren eines seriellen Bitmusters, um ein Datensignal als wenigstens einen Teil einer Ausgabenachricht zu bilden, und das Ausgeben besagten Datensignals auf dem Datensignalpfad von einem Linkinterface und das Ausgeben von einem Abtastsignal auf dem Abtastsignalpfad von besagtem einen Linkinterface, wobei das Abtastsignal, wenn Daten in dem Datensignal ausgegeben sind, Signalübertragungen nur an Bitgrenzen hat, wo dort keine Übermittlung bzw. Übertragung auf dem parallelen Datensignal ist, das parallele Eingeben besagter Daten und Abtastsignale an dem anderen Linkinterface und das Antworten bzw. Ansprechen auf beide, besagte Daten- und Abtastsignale, zum Dekodieren von Daten, die in dem Datensignal kodiert sind.
Die Erfindung stellt auch ein Verfahren zum Ausführen einer bidirektionalen Kommunikation zwischen wenigstens zwei miteinander verbundenen Vorrichtungen bereit, wobei wenigstens eine der Vorrichtungen einen Computer umfasst, das Verfahren umfasst das Aufbauen eines unidirektionalen Kommunikationspfades zwischen zwei Linkinterfaces, wobei jedes mit einer entsprechenden der Vorrichtungen verbunden ist, das Verschlüsseln einer Abfolge von Token, wobei jedes Token einen seriellen Bitstring bzw. eine serielle Bitzeichenkette umfasst, das Erzeugen eines Paritätsbits als Antwort auf aufeinander folgende bzw. nachfolgende Bits eines ersten Tokens, das Aufnehmen des Paritätsbits in einen zweiten Token, der dem ersten Token folgt, um eine Überprüfung der Nummer der Bits in dem ersten Token bereitzustellen, das serielle Übertragen des ersten und zweiten Tokens von dem einen Linkinterface zu dem anderen Linkinterface, Dekodieren der Token an dem anderen Linkinterface, Detektieren des Paritätsbits in dem zweiten Token und Vergleichen des Paritätsbits mit dem dekodierten Bitmuster des ersten Tokens.
Die Erfindung stellt auch ein Verfahren zum Ausführen einer Kommunikation zwischen wenigstens zwei miteinander verbundenen Vorrichtungen bereit, das Verfahren umfasst das Aufbauen von unidirektionalen Kommunikationspfaden zwischen zwei Linkinterfaces, wobei jedes mit einer der entsprechenden Vorrichtungen verbunden ist, dadurch gekennzeichnet, dass wenigstens eine der Vorrichtungen einen Computer umfasst, und durch Kodieren einer Abfolge von Token variabler Länge, wobei jedes Token eine serielle Bitzeichenkette umfasst, die ein Paritätsbit und wenigstens ein anderes Bit beinhaltet, das einen Bitlängenanzeiger für den Token bildet, das Erzeu gen eines Paritätsbits in Antwort auf aufeinanderfolgende bzw. nachfolgende Bits eines ersten Tokens, die einem ersten Bitlängenindikator für den ersten Token folgen, bis einschließlich einem Bitlängenindikator für einen nächsten Token, das Aufnehmen des Paritätsbits in einen Token, um eine Überprüfung von Bits in dem ersten Token und dem Bitlängenanzeiger besagten nächstens Tokens bereitzustellen, serielle Übertragung der Token von dem einen Linkinterface zu dem anderen Linkinterface, Dekodieren der Token an dem anderen Linkinterface, das Detektieren des Paritätsbits und Vergleichen des Paritätsbits mit dem dekodierten Bitmuster.
Bevorzugt beinhaltet das Verfahren das Aufbauen von vier unidirektionalen Kommunikationspfaden zwischen jedem Paar von Linkinterfaces, die vier Pfade umfassen ein erstes paralleles Paar von Daten- und Signalpfaden in einer Richtung und ein zweites paralleles Paar von Daten- und Signalpfaden in der entgegengesetzten Richtung.
Bevorzugt werden Daten durch ein Linkinterface in Form von Token einer vorbestimmten Bitlänge ausgegeben.
Bevorzugt werden Daten durch ein Linkinterface in Form von Token ausgegeben, die länger als eine vorbestimmte Bitlänge sind.
Bevorzugt umfasst das Verfahren das Erzeugen eines Flaggenbits zur Aufnahme in jeden Token, um das Token als ein Datentoken oder als ein Kontrolltoken zu identifizieren.
Bevorzugt befinden sich das Paritätsbit und das Flaggenbit jeweils in ersten und zweiten Bitpositionen in jedem Token.
Bevorzugt beinhaltet das Verfahren das Bilden von zwei aufeinander folgenden Kontrolltoken zum Bilden eines Verbundtokens, wobei das erste der Kontrolltoken ein Bitmuster aufweist, das anzeigt, dass ein weiterer Token erforderlich ist, um die Kontrolle zu bestimmen, die durch das Verbundtoken angezeigt wird.
Bevorzugt werden Nachrichten zwischen verbundenen Linkinterfaces in Form von Paketen bzw. Datenpaketen variabler Länge übermittelt, wobei jedes Paket bzw. Datenpaket eine Mehrzahl von Token umfasst, jeder Token ist von vorbestimmter Bitlänge und stellt ein Paket-Ende-Token am Ende jedes Paketes bereit.
Bevorzugt ist ein Ende-der-Nachricht-Token an dem Ende eines letzten Paketes bzw. Datenpaketes in einer Nachricht beinhaltet.
Bevorzugt beinhaltet das Verfahren das Bereitstellen eines Abgleichtokens, um gleichzeitige Übertragung in den Daten- und Abtastpfaden zu bewirken, wenn keine Daten auf dem Datenpfad übermittelt werden, und das Benutzen der gleichzeitigen Übertragungen zum Erzielen eines Abgleichs der Signale auf den Daten- und Abtastpfaden, wenn diese durch ein Linkinterface eingegeben werden.
Bevorzugt umfasst das Verfahren das Bilden von Flusskontrolltoken zum Ausgeben durch ein Linkinterface, das Ausgeben von Daten von einem ersten Interface zu einem zweiten Interface, das Ausgeben eines Flusskontrolltokens von dem zweiten Interface zu dem ersten Interface, um dem ersten Interface anzuzeigen, dass weitere Datentoken an das zweite Interface ausgegeben werden können.
Bevorzugt beinhaltet das Verfahren das Erhalten eines Zählwertes, welcher durch Ausgabe von Token durch ein ausgebendes Linkinterface bzw. Ausgabeverbindungsinterface angepasst wird, das Verhindern von weiterer Ausgabe von Datentoken von besagtem Linkinterface, wenn der Zählwert eine vordefinierte Zahl erreicht, und das Anpassen des Zählwertes in Erwiderung auf die Eingabe von Flusskontrolltoken von einem verbundenen Interface, um die Ausgabe von weiteren Datentoken zu erlauben.
Bevorzugt ist jedes Linkinterface arrangiert, Datentoken einer vordefinierten Bitlänge auszugeben, die länger ist als eine zweite vordefinierte Bitlänge für Kontrolltoken.
Bevorzugt ist jedes Linkinterface arrangiert, Kontrolltoken von zwei Typen auszugeben, eines zum Kontrollieren des Betriebs eines ersten verbundenen Linkinter faces und ein zweites zum Benutzen durch die Vorrichtung, die mit dem zweiten Linkinterface verbunden ist.
Bevorzugt ist jedes Linkinterface arrangiert, in seinem Eingabeschaltkreis Datentoken und Kontrolltoken des zweiten Typs zu speichern.
Bevorzugt beinhaltet das Verfahren das Transferieren bzw. Übertragen von Datentoken und Kontrolltoken des zweiten Typs von einem Speicher in dem Linkinterface zu der Vorrichtung, die mit dem Linkinterface verbunden ist, durch Benutzen eines synchronisierten Handshakes.
Bevorzugt ist ein Linkinterface arrangiert, ein Paket bzw. Datenpaket auszugeben, welches in einem oder mehreren Datentoken eine Adresse eines Kommunikationskanals, der in besagter einen Vorrichtung, die mit dem Linkinterface verbunden ist, benutzt werden soll beinhaltet und ist arrangiert, um das Paket bzw. Datenpaket zu empfangen.
Das Verfahren kann das Bewirken einer bidirektionalen Kommunikation zwischen einer Vielzahl von Vorrichtungen, die in einem Netzwerk beinhaltet sind, das eine Vielzahl von Mikrocomputern und wenigstens einen Routing-Schalter hat, beinhalten.
Eine Ausführungsform der Erfindung wird nun beispielhaft und mit Bezugnahme auf die begleitenden Zeichnungen beschrieben, in denen:
1 ist ein Blockdiagramm eines Netzwerkes, das eine Vielzahl von Linkinterfaces gemäß der vorliegenden Erfindung hat,
2 ist eine schematische Ansicht eines Linkinterfaces gemäß der Erfindung,
3 zeigt detaillierter die Linkausgabe der Anordnung, die in 2 gezeigt ist,
4 zeigt detaillierter die Linkeingabe der Anordnung, die in 2 gezeigt ist,
5 zeigt das Bitmuster auf Daten- und Abtastleitungen für zwei aufeinander folgende Token, die durch Benutzung des Apparates, wie er in 2 gezeigt ist, erhalten werden,
6 zeigt eine Ausgabe auf den Daten- und Abtastleitungen während der letzten vier Bits eines Datenabgleichtokens,
7 zeigt eine Eingabe in die Daten- und Abtastleitungen, die einer Ausgabe, wie in 6 gezeigt, folgt, und
8 zeigt eine alternative Eingabe in die Daten- und Abtastleitungen, die einer Ausgabe, wie in 6 gezeigt, folgt.
Das Netzwerk, das in 1 gezeigt ist, umfasst eine Vielzahl von Mikrocomputern 11, 12, 13 und 14, welche jeweils einen einzelnen Mikrocomputer mit integriertem Schaltkreis umfassen können, so wie der, der in unserem US-Patent 4,680,698 gezeigt ist. Das Netzwerk kann auch andere Ausrüstung umfassen, wie einen Mikroprozessor 15, periphere Einheiten 16 und 17 und einen Disketten-Controller 18, der eine Diskette 19 kontrolliert. Das Netzwerk beinhaltet auch einen Routing-Schalter 20, der wie in unserer europäischen Patentanmeldungs-Veröffentlichung Nr. 0 405 990 sein kann. Jeder der Mikrocomputer 11 bis 14 hat eine Vielzahl von Linkeinheiten 21, wobei jeder ein Kommunikationsinterface, das mit vier unidirektionalen Signaldrähten bzw. Signalleitungen 23, die eine bidirektionale Kommunikation mit einer verbundenen Linkeinheit 21 auf einer anderen Vorrichtung in dem Netzwerk bilden, bereitstellen. In dem gezeigten Beispiel ist der Mikroprozessor 15 mit einem Bus 22 verbunden, der mit einer Linkeinheit 21 verbunden ist. Einige der Vorrichtungen, wie der Mikrocomputer 12 und der Disketten-Controller 18, sind direkt durch vier Signalleitungen 23 verbunden, wobei andere Vorrichtungen durch den Routing-Schalter 20 verbunden sind. Jeder der Mikrocomputer 11, 12, 13, 14, Mikroprozessor 15 und die peripheren Einheiten 16 und 17 und der Disketten-Controller 18 dienen als eine Hostvorrichtung, bezogen auf die Linkeinheit 21, die Eingaben in und Ausgaben von der Hostvorrichtung ermöglicht. Jede der Linkeinheiten 21 ist ähnlich, und ihre Konstruktion und ihr Betrieb werden detaillierter unten beschrieben werden. Jede ist eingerichtet, um bidirektionale Kommunikation zwischen Paaren von Vorrichtungen in dem Netzwerk zu ermöglichen. Die Kommunikation ist derart, dass Nachrichten variabler Länge übermittelt werden, die in eine Abfolge von Paketen bzw. Datenpaketen unterteilt werden können. Jeder Satz von Signalleitungen 23 beinhaltet ein erstes paralleles Paar von Leitungen 25 und 26, die jeweils einen Datensignalpfad und einen parallelen Abtast signalpfad in einer Richtung zwischen einem Paar von verbundenen Linkeinheiten 21 bilden. Das zweite Paar von Leitungen bildet einen Datensignalpfad und einen parallelen Abtastsignalpfad in der entgegengesetzten Richtung zwischen demselben Paar von Linkeinheiten 21. Nachrichten werden zwischen den verbundenen Linkeinheiten 21 verschickt bzw. ausgetauscht durch serielle Bitzeichenketten bzw. serielle Bitstrings, welche auf dem Datensignalpfad 25 kodiert sind, und parallele Signale in dem Abtastsignalpfad 26 werden benutzt, um die Nachrichten, die auf dem Datensignalpfad 25 empfangen werden, zu dekodieren. Die Bitzeichenketten werden in Token übertragen, wobei jedes Token von einer vordefinierten Bitlänge ist. In diesem speziellen Beispiel werden zwei unterschiedliche Tokenlängen benutzt. Der erste, der Datentoken genannt wird, ist jeweils 10 Bits lang, und der zweite Typ sind Kontrolltoken, welche jeweils vier Bits lang sind. Beispiele sind jeweils in 5 gezeigt, wo Token N ein Beispiel für ein Datentoken ist, und das nächstfolgende Token N + 1 ein Beispiel für ein Kontrolltoken ist. Für beide Typen von Token ist die erste Bitstelle bzw. Bitposition, die auf der linken Seite des Tokens in 5 gezeigt ist, ein Paritätsbit für den Token. Die zweite Bitstelle bzw. Bitposition ist eine Flagge, um anzuzeigen, ob das Token ein Datentoken oder ein Kontrolltoken ist. Im Falle eines Datentokens können die nächsten acht Bitstellen irgendwelche Daten, die in der Nachricht erforderlich sind, enthalten. Im Falle eines Kontrolltokens sind die ersten beiden Bits dieselben wie bereits für einen Datentoken beschrieben, und die letzten beiden Bits enthalten eine Kontrollanzeige. Das Abtastsignal, welches parallel mit dem Datensignal übermittelt wird, ist ebenfalls in 5 gezeigt, und dieses ist so arrangiert bzw. eingerichtet, dass, wenn Token auf dem Datenkanal 25, die einen Teil einer Nachricht bilden, übermittelt werden, der Abtastkanal 26 einen Signalübergang nur an den Bitgrenzen hat, wenn dort keine Übermittlung auf dem parallelen Datensignal ist. Obwohl beide Typen von Token jeweils eine vordefinierte Bitlänge besitzen, kann jede gewünschte Anzahl von Token als Abfolge übermittelt werden, um ein einzelnes Paket bzw. Datenpaket zu bilden. Das Ende eines Paketes bzw. Datenpaketes kann durch die Übermittlung eines Kontrolltokens markiert werden, das das Ende des Paketes bzw. Datenpaketes anzeigt. Es kann in einigen Fällen wünschenswert für einen Link oder einen Routing-Schalter sein, Pakete bzw. Datenpakete von verschiedenen Nachrichten (möglicherweise übermittelt zwischen unterschiedlichen Paaren von Vorrichtungen) zu behandeln, bevor eine Übermittlung einer ersten Nachricht abgeschlossen ist. Durch das Einrichten einer Nachricht, die übermittelt werden soll, in Paketen bzw. Datenpaketen ist es möglich, die Übermittlung einer Nachricht am Ende eines Paketes zu stoppen und die Übermittlung dieser Nachricht zu einem späteren Zeitpunkt durch ein oder mehrere nachfolgende Pakete bzw. Datenpakete wiederaufzunehmen, die mit einem Ende der Nachricht Tokenenden, wenn die Nachricht komplett ist. Dies erlaubt das Multiplexen einer Vielzahl von Nachrichten durch einen einzelnen Link.
Das Protokoll, das für die Ausgabe der Token auf dem Datensignalpfad 25 gemäß dieses Beispiels benutzt wird, ist wie folgt:
Die obige Tabelle zeigt die Bitmuster für ein Datentoken an, um ein Datenbyte und nachfolgend vier Kontrolltoken in der Form eines Flusskontrolltokens, eines Paket-Ende-Tokens, eines Nachricht-Ende-Tokens und eines Escape-Tokens zu übermitteln. P zeigt ein Paritätsbit in jedem Token an. Das Datentoken hat die zweite Bitposition mit einer Flagge, die auf 0 gesetzt ist, wohingegen die Kontrolltoken die zweite Bitflagge auf 1 gesetzt haben. Der Zweck des Escape-Tokens ist es, ein Verbundtoken zu formen, das aus zwei aufeinander folgenden Vier-Bit-Token besteht. Das Escape-Token ist deutlich durch seine Flagge als ein Kontrolltoken markiert und die dritten und vierten Bitstellen des Escape-Tokens zeigen an, dass das Token, das folgt, ein Vier-Bit-Token sein wird, das für Kontrollzwecke eingesetzt wird, und keine Daten. Das nachfolgende Token, welches benutzt wird, um ein Verbundtoken mit dem Escape-Token zu formen, kann entweder ein Datenabgleich-Token oder ein Null-Token oder ein Frei-Token sein. In der obigen Tabelle bilden die Kontrolltoken zwei unterschiedliche Typen. Flusskontrolltoken und Verbundtoken, die durch Benutzer des Escapetokens gebildet werden, bilden jeweils einen ersten Typ. Diese Kontrolltoken des ersten Typs werden nur durch das Linkinterface selbst für Kontrollzwecke benutzt. Das Flusskontrolltoken wird benutzt, um die Ausgaberate von Token durch einen Link zu kontrollieren, um sicherzustellen, dass ein Speicher in einem empfangenen Link nicht überfüllt wird. Die Datenabgleich-Token werden benutzt, um den Abgleich der Daten- und Abtastsignale anzupassen, wenn sie durch einen Link eingegeben werden. Null-Token werden normalerweise übermittelt, wenn gerade keine anderen Token gesendet werden. Kontrolltoken des zweiten Typs bestehen aus dem Paket-Ende-Token und dem Nachricht-Ende-Token, und diese werden gemeinsam mit den Datentoken von der Hostvorrichtung benötigt, welche mit dem Linkinterface verbunden ist, und diese werden folglich in einem Speicher in dem Link gespeichert, bis sie mit einem synchronisierten Handshake-System zu dem Host transferiert werden. Ähnlich werden Kontrolltoken des ersten Typs durch das Linkinterface selbst erzeugt, wohingegen Datentoken und Kontrolltoken des zweiten Typs durch die Hostvorrichtung erzeugt und an den Link durch ein synchronisiertes Handshake-System übermittelt werden.
Wenn irgendeiner der Token (mit Ausnahme des DAT-Tokens), die in der obigen Tabelle aufgelistet sind, auf den Datensignalpfad 25 ausgegeben werden, wird der Abtastsignalpfad 26 ein Signal ausgeben, das aus Signalübergängen an jedem Bitrand in dem Datensignal besteht, wo dort kein Wechsel im Signallevel in dem Datensignal ist. Wenn ein DAT-Token ausgegeben worden ist, folgt das Abtastsignal der normalen Prozedur für Bitgrenzen bzw. Bitgrenzbereiche nach Bitpositionen 1, 2, 3, 4 und 5 des DAT-Tokens, aber an den Bitgrenzbereichen nach den Bitpositionen 6 und 7 folgt das Inverse des Normalwerts, dadurch dass es gleichzeitige Übergänge 140a und 140b auf beiden, dem Daten- und Abtastpfaden, nach Bit 6 und auch kein Übergang auf jedem Pfad nach Bit 7 hervorruft. Dies stellt eine einzelne identifizierbare Kante auf beiden Signalpfaden nach Bit 6 bereit, welche für Abgleich bzw. Angleichungszwecke benutzt wird. Dies ist in 6 gezeigt, welche die letzten vier Bitpositionen eines Verbundtokens, das ein DAT-Token bildet, illustriert.
Die Einrichtung der Linkinterfaces wird nun unter Bezugnahme auf 2, 3 und 4 beschrieben.
Jede Linkeinheit 21 hat eine Ausgabeeinheit 30, eine Eingabeeinheit 31, eine Flusskontrolleinheit 32 und einen Kontrollschaltkreis 33. Die Ausgabeeinheit 30 ist detaillierter in 3 gezeigt. Ein Hostinterface 34 ist vorgesehen, um die Ausgabeeinheit mit der Hostvorrichtung, wie dem Mikrocomputer 11 in 1, zu verbinden. Das Interface 34 ist mit dem Host durch einen Datenbus 35 verbunden, der arrangiert ist, um acht parallele Datenbits bereitzustellen. Um synchronisierte Handshake-Kommunikation mit dem Host zu erlauben, hat das Interface 34 auch eine Eingabe 36, um ein gültiges Datensignal von dem Host zu erhalten, und eine Ausgabe 37, um ein Bestätigungssignal bereitzustellen, wenn es ein Byte von Daten von dem Host erhalten hat. Das Interface 34 hat eine Uhrsignal- bzw. Zeitsignaleingabe 38 und eine Rücksetzeingabe 39. Das Interface 34 hat auch eine Eingabe 40 von der Flusskontrolleinheit 32, um Datenausgabe zu verhindern, wenn genügend Token bereits ausgegeben worden sind, ohne dass ein Flusskontrolltoken an der entsprechenden Eingabe empfangen worden ist. Das Interface 34 stellt auch eine Token-Gesendet-Ausgabe 41 zu der Flusskontrolleinheit 32 bereit. Daten werden dem Interface 34 gemeinsam mit einem Date-gültig-Signal von dem Host präsentiert. Wenn die Ausgabelogik 30 bereit ist, diese Daten zu akzeptieren, sendet sie Signale in Form eines Bestätigungssignals auf der Leitung 37 zu dem Host. Wenn der Host und die Ausgabeeinheit 30 in unterschiedlichen Uhr- bzw. Zeitsystemen arbeiten, ist es notwendig, das Date-gültig-Signal 36 und das Bestätigungssignal 37 zu synchronisieren. Daten, die von dem Interface 34 empfangen worden sind, werden in ein paralleles Register 42 geladen, und es wird verstanden werden, dass die Daten in diesem Register entweder ein Datento ken des Typs, der vorhergehend beschrieben worden ist, oder ein Kontrolltoken EOP oder EOM ist. Um ein Token auszugeben, muss einer der Vielzahl von Tokenanforderungs-Latches 43 gesetzt sein, und um irgendeines der Token, welche durch das Interface 34 empfangen worden sind, zu senden, ist eine Eingabe auf Leitung 44 als eine Eingabe zu den Tokenanforderungs-Latches 43 vorgesehen. Die Latches 43 stellen auch eine Ausgabe auf Leitung 43a zu dem Interface 34 bereit, um anzuzeigen, wann ein Datentoken gesendet worden ist. Die Tokenanforderungs-Latches 43 haben auch drei Eingaben 45, 46 und 47 zum jeweiligen Senden eines DAT-, FCT- und NULL-Tokens. Eingaben 45 und 47 kommen von dem Kontrollschaltkreis 33, wohingegen Eingabe 46 von der Flusskontrolleinheit 32 kommt. Die Latches 43 stellen auch eine Ausgabe 48 zu der Flusskontrolleinheit 32 bereit, um anzuzeigen, wann ein FCT gesendet worden ist. Um ein Token zu senden, wird die passende Eingabe in die Latches 43 festgestellt bzw. erklärt und, falls das Signal an der abfallenden Kante bzw. Flanke des Uhrsignals, die auch in die Latches eingegeben bzw. eingefüttert worden ist, gültig ist, dann wird der passende Riegel gesetzt und wird zurückgesetzt durch eine Eingabe 49, wenn der Token gesendet worden ist. Die NULL-Anfrage 47 wird während normalen Betriebes hoch gehalten, so dass ein NULL-Token gesendet wird, wenn kein anderer Token zum Senden angefordert wird. Der Latch-Schaltkreis 43 ist durch acht Leitungen verbunden (vier Token-Anforderungs-Leitungen zu dem Priorisierer 50 und vier Token-priorisiert-Leitungen zu den Latches 43), zu einem Token-Priorisierer 50, und es ist auch ein Signal auf Leitung 51 zu einem Token-Sequenzierer 52 vorgesehen, jedes Mal wenn ein Latch gesetzt ist. Der Token-Priorisierer 50 empfängt die Ausgaben von den Token-Anforderungs-Latches 43 und enthält logische Schaltkreise zur Priorisierung der Anfragen von den Latches 43 in der Reihenfolge DAT, FCT, DATA, NULL. Dies erlaubt Kontrolle, wenn mehr als eine Latchanfrage zur selben Zeit gemacht worden ist. Der Token-Priorisierer 50 stellt vier getrennte Ausgaben (Token priorisiert) bereit, abhängig davon, welcher Latch gesetzt worden ist, und sie sind mit einem Kontrollkode-ROM 53 verbunden, welches auch als Datenmultiplexer agiert. Das ROM 53 ist mit Bitmustern für die Kontrollkodes ESC, DAT, FCT und NULL programmiert. Diese sind Kontrolltoken, welche allein innerhalb der Link-Logik erzeugt werden, wohingegen alle anderen Token von dem Host durch das Interface 34 eingegeben werden. Wenn der Latch 43 gesetzt worden ist, um anzuzeigen, dass ein Datentoken (das ist ein Token, das durch das Interface 34 eingefüttert wird) gesendet werden soll, dann werden die Inhalte des Datenregisters 43 zu den Ausgaben des ROM-Schaltkreises 53 geleitet, welches mit einem Ausgabeverschieberegister 54 verbunden ist. Die Ausgabe besteht aus acht Bits (nur zwei davon werden für die Token EOP und EOM benutzt) und einem Kontroll- oder Datenflaggensignal auf Leitung 55. Dies wird auch als eine Eingabe 56 in dem Sequenzierer 57 eingespeist. Das Register 54 empfängt die Daten parallel und gibt sie in serieller Form aus, wobei die Kontroll- oder Datenflaggen den acht Datenbits vorausgehen. Die Ausgabe wird in Leitung 58 zu einem Paritätserzeuger 59 eingefüttert. Der Paritätserzeuger enthält einen rücksetzbaren Latch mit einer Ausgabe, die in die Eingabe über ein ausschließliches ODER-Gatter zurückgespeist wird. Der Paritätserzeuger 59 hat eine Paritätsrücksetzeingabe 60 von dem Sequenzierer 57 und eine Eingabe zum Ermöglichen der Ausschaltung der Parität auf Leitung 61 von dem Sequenzierer 57. Dies hat den Effekt, dass auf jedes Bit in einem Token, das von dem Register 54 in den Erzeuger 59 eingespeist wird, geantwortet wird. Das Paritätssignal wird ausgegeben, nachdem die Kontroll- oder Datenflagge des nächsten Tokens in den Paritätserzeuger eingegeben worden ist. Das Paritätsbit stellt dadurch eine Anzeige der Anzahl von Os oder Is bzw. Nullen oder Eingaben bereit, die seit der letzten Kontroll- oder Datenflagge bis einschließlich der nächsten Kontroll- oder Datenflagge ausgegeben worden sind.
Es wird gesehen werden, dass jedes Paritätsbit eine Überprüfung der Bits, die einer Kontroll- oder Datenflagge in einem Token bis hin zu einschließlich der Kontroll- oder Datenflagge des nächsten Tokensfolgens bereitstellt. In dem beschriebenen System, welches Token variabler Länge benutzt, ist die Kontroll- oder Datenflagge das Mittel zum Anzeigen der Bitlänge des Tokens. Es ist deshalb wichtig, eine Paritätsüberprüfung zu haben, welche eine Überprüfung auf der Kontroll- oder Datenflagge selbst durchführt, ohne Datenbits zu beinhalten, die der Kontroll- oder Datenflagge folgen. Auf diese Weise, falls die Paritätsüberprüfung auf der Bitzeichenkette, die die Kontroll- oder Datenflagge beinhaltet, keinen Fehler anzeigt, dann wird die Kontroll- oder Datenflagge akzeptiert als die Bitlänge des nächsten Tokens korrekt identifizierend. Im Gegenzug resultiert dies in der korrekten Anzahl von Bits, die berücksichtigt werden, wenn die nächste Paritätsüberprüfung ausgeführt wird. Mit anderen Worten muss das Bit, welches die Tokenlänge anzeigt, vor den Datenbits dieses Tokens überprüft werden, so dass dort keine Unsicherheit besteht, wie viele Bits beim Durchführen der nächsten Paritätsüberprüfung untersucht werden sollten. Nachdem die Paritätsüberprüfung ausgeführt worden ist, ist es wichtig für das Paritätsbit, dass es in einer bekannten Position in jedem Token sich befindet. Jene bekannte Position muss konstant gehalten werden, unabhängig von der Länge der Token, und muss deshalb innerhalb der kürzesten Bitlänge jedes beliebigen benutzten Tokens positioniert sein. Aus diesem Grund lokalisiert das beschriebene Beispiel das Paritätsbit in der ersten Bitposition jedes Tokens, obwohl es eine Paritätsüberprüfung bereitstellt auf der Kontroll- oder Datenflagge, welche in der zweiten Bitposition dieses Tokens ist, und auf allen Bits in dem vorhergehenden Token, welche der Kontroll- oder Datenflagge des vorhergehenden Tokens gefolgt sind.
Die Ausgabe des Paritätserzeugers 59 seit der letzten Kontroll- oder Datenflagge und einschließlich der Kontroll- oder Datenflagge des nächsten Tokens. Der Paritätserzeuger wird durch ein Signal auf Leitung 61 freigegeben, um eine Ausgabe mit dem Paritätsbit bereitzustellen, das auf das letzte Datenbit folgend ausgegeben worden ist. Dieses Paritätsbit bildet dadurch das erste Bit eines nachfolgenden Tokens. Die Ausgabe des Paritätserzeugers 59 wird in einen Daten-/Abtastkodierer 62 (data/stobe encoder) eingespeist. Dies ist eine Zustandsmaschine, welche den folgenden Gleichungen gehorcht:
On reset Data(0) = 0, Strobe(0) = 0
Strobe(n + 1) = Strobe(n) EXOR NOT(Data(n + a) EXOR Data(n) EXOR InvertStrobe)
The InvertStrobe ist normalerweise bei der Logischen 0. Es wird nur geltend gemacht bzw. angeführt während des speziellen Bits in dem Datenangleichungstoken.
Der Kodierer 62 wird durch eine Eingabe auf Leitung 63 von dem Sequenzierer 57 freigegeben, und er empfängt eine invertierte Abtasteingabe 64 von einem DAT-Erzeuger 65, wenn ein DAT-Token gesendet werden soll. Im normalen Betrieb ant wortet der Kodierer 62 auf die Bitzeichenkette, die er von dem Paritätserzeuger 59 empfangen hat, und erzeugt eine Abtastsignalausgabe 26 (strobe signal output) in paralleler Weise mit der Datensignalausgabe 25 (data signal output). Diese Ausgaben werden jeweils durch Ausgabetreiber 67 und 68 gespeist, welche durch die Uhr bzw. Zeit des Ausgabelinks getaktet werden. Die Ausgabetreiber 67 und 68 sind identisch und sind gleichzeitig getaktet, um Fehlabgleiche zwischen den Daten- und Abtastsignalen zu minimieren. Der Effekt des Kodierers 62 ist es, ein Abtastsignal parallel mit dem Datensignal bereitzustellen, derart, dass, wenn irgendwelche Token, die andere als DAT-Token sind, ausgegeben werden, Signalübergänge auf der Abtastleitung 26 nur an Bitgrenzen auftreten, wenn dort kein Übergang auf dem parallelen Datensignal 25 ist. Eine typische Signal- und Abtastsignalkette ist in 5 illustriert. Der Sequenzierer 57 ist eine Zustandsmaschine, welche Abtastsignale an das Ausgabeverschieberegister 54, den Paritätserzeuger 59, den Kodierer 62 und den Token-Sequenzierer 52 bereitstellt. Wenn es durch ein Startsignal auf einem Eingang 70 von einem Token-Sequenzierer 52 in Antwort auf einen Latch 43, der gesetzt worden ist, initiiert wird, veranlasst er, dass ein Token in das Ausgabeverschieberegister 54 über ein Eingabesignal auf Leitung 71 eingeklingt wird. Wenn der Token in das Register eingeklinkt ist, stellt der Sequenzierer eine Eingabe auf Leitung 72 bereit, um das Register 54 zu veranlassen, die Flaggen- und Datenbits seriell entlang Leitung 58 durch den Paritätserzeuger 59 zu verschieben. Der Sequenzierer empfängt eine Eingabe auf Leitung 56, die anzeigt, ob das Token ein vier- oder zehn-Bit-Token ist, um so die Anzahl der Bits, die aus dem Register 54 verschoben werden, zu kontrollieren. Wenn die passende Zahl der Bits für den Token gesendet worden ist, stellt der Sequenzierer 57 eine Ausgabe auf Leitung 74 an den Token-Sequenzierer 52 bereit, um zu signalisieren, dass ein weiterer Token jetzt gesendet werden kann. Der Token-Sequenzierer 52 stellt ein Freigabesignal auf Leitung 75 zu dem Token-Priorisierer 50 nach einem Signal auf Leitung 74 bereit, so dass der Token-Priorisierer 50 dann den Token mit der höchsten Priorität berechnen kann, und gleichzeitig signalisiert der Token-Anforderungs-Latch 43 dem Token-Sequenzierer über Leitung 51, dass dort ein Token zu senden ist. Dies veranlasst den Token-Sequenzierer 52, dem Token-Priorisierer auf Leitung 75 (Freigabe) zu signalisieren, seine Ausgaben in der Reihenfolge zu halten, dass die Token gesendet werden können. Der Sequenzierer 52 ist eine Zustandsmaschine, die das Senden von jedem Token kontrolliert. Ein Zyklus einer Operation für den Sequenzierer 52 wird durch irgendeine Eingabe auf Leitung 51 von den Latches 43 initiiert. Wenn der Token-Priorisierer 50 anzeigt, dass der gesetzte Latch ein ESC-Token anfordert, dann wird ein Signal auf Leitung 76 zu dem Token-Sequenzierer 52 bereitgestellt, welches eine Ausgabe auf Leitung 77 zu dem ROM 53 bereitstellt. Der Token-Sequenzierer 52 signalisiert dann an den Sequenzierer 57 auf Leitung 70, welcher den Escape-Token sendet. Der Sequenzierer 57 signalisiert dann an den Token-Sequenzierer 52 auf Leitung 74 zurück, dass das Token gesendet worden ist. Der Token-Sequenzierer entfernt dann das gesendete ESC-Token-Signal 77 und signalisiert dem Sequenzierer 57, zweite Vier-Bit-Token zu senden. Der Sequenzierer 57 sendet dann das zweite Vier-Bit-Token und signalisiert an den Token-Sequenzierer dann zurück. Der Token-Sequenzierer 52 setzt dann den Latch durch ein Signal auf Leitung 49 zurück. Um eine Angleichung der Daten- und Abtastsignale in einer Link-Eingabe zu erlauben, können DAT-Token gesendet werden, und diese erzeugen spezielle Ausgaben auf Leitungen 25 und 26 durch Benutzen des DAT-Erzeugers 65. Der Sequenzierer 57 empfängt eine Eingabe 79 von dem ROM 53, wenn der Token, der gesendet werden soll, ein DAT-Token ist. Das Signal auf Leitung 79 wird durch den Sequenzierer 57 benutzt, um DAT-Token von anderen Token zu unterscheiden. Für DATs wird der Sequenzierer 57 ein Vier-Bit-Token anstelle eines Zehn-Bit-Tokens senden, wenn die C/D-Flagge 56 null ist, und wird dem DAT-Erzeuger 65 auf Leitung 73 zu Beginn des zweiten Vier-Bit-Tokens signalisieren. Der Sequenzierer 57 wird dann auf eine Antwort von dem DAT-Erzeuger auf Leitung 80 warten, bevor er mit dem nächsten Token weiter macht. Der DAT-Erzeuger 65 invertiert dann das Abtastsignal während dem dritten Bit des Tokens, das dem ESC-Token folgt, als ein Ergebnis eines invertierten Abtastsignals auf Leitung 54, das in den Kodierer 62 eingespeist worden ist. Darüber hinaus stellt der Erzeuger 65 ein Wartesignal (WAIT Signal) auf Leitung 80 an den Sequenzierer 57 bereit, um einen Betrieb des Sequenzierers 57 für eine Anzahl von Bitperioden, die dem Token folgen, zu verhindern, so dass die Ausgabe auf den Daten- und Abtastleitungen in einem konstanten Zustand gehalten wird.
Wann immer ein Datentoken, EOP-Token oder EOM-Token durch einen Link ausgegeben wird, wird ein Signal auf Leitung 41 durch eine Einheit 81 die durch 8 divi diert, an einen Ausgabe-Tokenzähler 82 in der Flusskontrolleinheit 32 eingespeist. Der Zähler 82 hat die Funktion, die Anzahl von Token, die durch einen Link ausgegeben werden können, bis ein FCT-Token durch eine Linkeingabe von dem Linkinterface, das die Ausgabe empfängt, empfangen worden ist, zu begrenzen. Dies verhindert eine Speicherung in dem empfangenden Linkinterface, das überfließt auf Grund des Empfangs von zu vielen Ausgabetoken. Wann immer ein FCT-Token in der Linkeingabe empfangen worden ist, wird der Zähler 82 inkrementiert, und nach acht Token, die durch die Linkausgabe gesendet worden sind, veranlasst das Signal auf Leitung 41 eine Erniedrigung des Zählstandes in dem Zähler 82. Wann immer der Zähler null erreicht, wird eine Ausgabe auf Leitung 40 durch einen Synchronisierer 83 bereitgestellt, um eine weitere Ausgabe von Daten von dem Interface 34 zu verhindern. Auf diese Weise stellt der Zähler 82 eine Anzeige des Pufferraumes, der in einer Linkeingabe an dem anderen Ende des Links verfügbar ist, bereit und die Anzahl von Räumen wird mit jedem Token, das ausgegeben wird, herunter gezählt und um acht bei Empfang eines FCT-Tokens erhöht.
Alle Einheiten in den Linkausgaben, die in 3 gezeigt sind, haben Rücksetzeingaben und empfangen Taktpulse von einer Uhr, die für den Ausgabeschaltkreis des Linkinterfaces vorgesehen ist.
Der Eingabeschaltkreis und die Flusskontrolleinheit 32 sind vollständiger in 4 gezeigt. Die Linkeingabe 31 ist gänzlich getaktet durch die Daten- und Abtastsignale auf Leitungen 25 und 26. Die Signale werden jeweils durch Verzögerungseinheiten 90 und 91 eingegeben, deren Verzögerung durch einen Verzögerungs-Anpassungsschaltkreis 92 angepasst werden kann. Die Daten- und Abtastsignale werden dann durch Verwendung eines Datenanstiegsflankendetektors bzw. Datenanstiegsranddetektors 95, eines Datenabfallflankendetektors bzw. Datenabfallranddetektors 96, eines Abtastanstiegsflankendetektors bzw. Abtastaustiegsranddetektors 97, eines Abtastabfallflankendetektors bzw. Abtastabfallranddetektors 98 detektiert. Wenn Flanken bzw. Ränder detektiert worden sind, werden Ausgaben auf Leitungen, die an einen Schiedsschaltkreis (arbiter circuit) 99 angeschlossen sind, betätigt. Die Detektoren werden durch vier Signale, die entsprechend in die Detektoren von einem Bitverzögerungsschaltkreis eingespeist werden, zurückgesetzt. Der Bitverzögerungsschaltkreis antwortet auf Ausgaben von dem Arbiter-Schaltkreis 99 und setzt die Rand- bzw. Flankendetektoren nach einer geforderten Bitverzögerung zurück. Die Arbiter 99 geben die Ausgabe von den vier Randdetektoren bzw. Flankendetektoren ein und reihen die Eingaben auf, um sie zu einer Zeit, das heißt gleichzeitig, auszugeben. Der Schiedsschaltkreis 99 hat vier Ausgaben, die zu einem Daten-/Taktextrahierer (data/clock extractor) 101 führen, und die vier Ausgaben werden derart kontrolliert, dass nur eine Ausgabe hoch bzw. aktiv zu irgendeiner Zeit ist, und dies entspricht der ersten Eingabe, die betätigt bzw. getätigt worden war. Der Extrahierer 101 in Verbindung mit den Arbiter 99 und die Randdetektoren bzw. Flankendetektoren arbeiten, um die Signale in den Daten- und Abtastleitungen 25 und 26 zu vergleichen, und dekodieren die Daten derart, dass eine Datenausgabe 102 und ein Taktsignal 103 bereitgestellt werden. Der Extrahierer 101 beinhaltet einen Latch, welcher durch die ansteigenden und fallenden Datenausgaben von dem Arbiter 99 zurückgesetzt wird. Die Ausgabe des Latches ist das zurückerlangte Datensignal, und um das Zurücksetzen der Eingabelogik zu takten, arbeitet das Taktsignal auf 103 bei der halben Bitrate, welche bei dem Dekodieren zurückerlangt worden ist. Jedes Mal, wenn eine neue Ausgabe von dem Arbiter 99 empfangen worden ist, wird die Ausgabe eines Latches in dem Extrahierer 101 umgeschaltet bzw. geflippt. Die Verzögerungsleitungen 90 und 91 sind bereitgestellt, damit der Dekodierer korrekt funktioniert, und erlauben, dass die Daten- und Abtastsignale innerhalb einer Bitperiode ausgerichtet bzw. angeglichen werden. Um dieses Ausrichten bzw. Angleichenh zu erlauben, werden DAT-Token durch den Ausgabeschaltkreis eines verbundenen Linkinterfaces gesendet. Dies ruft gleichzeitige Übergänge auf beiden Leitungen, den Daten- und Abtastleitungen 25 und 26, hervor. Die Token werden bei der Eingabe dekodiert und erzeugen ein oder zwei Ergebnisse, abhängig davon, ob das Datensignal vor oder nach dem Abtastsignal ist. Der Datentoken wird als P011 ausgegeben, aber jede relative Verzögerung zwischen den Daten- und Abtastsignalen kann veranlassen, dass der Token als P011 eingegeben wird, falls das Abtastsignal vor dem Datensignal ist (Delay Strobe) oder als POO1, falls das Datensignal vor dem Abtastsignal ist (Delay Data). 7 zeigt die Position für die letzten vier Bits eines Datentokens, wobei das Datensignal bezogen auf das Abtastsignal spät eingegeben worden ist, und so eilt der Rand 104b dem Rand 104a voraus. Dies wird als P011 durch Bestimmen der Signalhöhe auf dem Datenkanal nach Übergänge auf jeder Leitung bestimmt. 8 zeigt die äquivalente Position, wenn das Abtastsignal bezogen auf das Datensignal spät eingegeben wird. Der Rand 104b folgt dem Rand 104a. Dies wird als P001 durch Bestimmen der Signalhöhe auf der Datenleitung nach Übergängen auf jeder Leitung bestimmt. Beim Zurücksetzen der Verzögerungseinheiten 90 und 91 werden beide auf eine minimale Verzögerung gesetzt. Der Empfang eines Delay Strobe-Tokens veranlasst die Verzögerung 91 in dem Abtastsignalpfad, um einen kleinen festen Betrag abzufallen, bis es bereits null ist, in welchem Fall die Verzögerung in dem Datensignalpfad 90 erhöht wird. Der Empfang eines Delay Data-Signals bewirkt den entgegengesetzten Effekt. Auf diese Weise ist zu allen Zeiten wenigstens eine der Verzögerungsleitungen bei minimaler Verzögerung.
Die Daten- und Taktsignale 102 und 103 werden jeweils mit einem Paritätsüberprüfer 105, einem Token-Synchronisierer 106 und einem Eingabeverschieberegister 107 verbunden. Das Register 107 besteht aus zwei Ketten von Master-Slave-Latches. Eine Kette wird bei dem aufsteigenden Rand der Uhr getaktet und die andere auf dem abfallenden Rand. Der Token-Synchronisierer 106 extrahiert die Kontroll-/Datenflagge in der zweiten Bitposition von jedem Token und zählt die passende Anzahl von Bits für diesen Token aus, welche entweder vier oder zehn sein wird, abhängig davon, ob der Token ein Daten- oder Kontrolltoken ist. Er erstellt Abtastsignale auf Leitung 108a bereit, um 4-Bit-Token von Register 107 in ein Tokeneingaberegister 109 einzuklinken, und auf 108b bereit, um 10-Bit-Token vom Register 107 in das Tokeneingaberegister 109 einzuklinken, desgleichen stellt er ein Abtastsignal auf Leitung 110 für den Paritätsüberprüfer 105 bereit, so dass der Paritätsüberprüfer 105 das Paritätsbit zu Beginn jedes Tokens identifiziert und dieses mit der Anzahl von Bits vergleicht, welche auf Leitung 102 von der letzten Kontrolle der Datenflagge in dem vorhergehenden Token übertragen worden sind. Falls ein Paritätsfehler auftritt, wird eine Ausgabe auf Leitung 111 bereitgestellt. Diese wird durch eine Eingabe 112 in den Token-Synchronisierer 106 zurück eingespeist, um die Eingabe anzuhalten. Die Detektion eines Paritätsfehlers kann dazu benutzt werden, ein Warnlicht anzuschalten oder das System anzuhalten oder das System zu aktivieren, den Fehler durch Rebooten oder auf andere Weise zu entdecken.
Wenn ein vollständiger Token in das Register 107 hinein verschoben worden ist, wird der Token-Synchronisierer die richtige Anzahl von Bits für diesen Token gezählt haben und wird dann die Inhalte in das Register 109 einklinken. Ein Token-Gültig-Signal wird dann auf Leitung 112 von dem Token-Synchronisierer 106 bereitgestellt, um den Kodedetektor 113 zu kontrollieren, welcher den Token von dem Register 109 empfängt, und das Bitmuster derjenigen Token, welche Kontrolltoken zur Benutzung innerhalb des Links sind, identifiziert. Diese Token sind NULL, FCT, DAT und ESC. Alle anderen Token, solche wie Datentoken, EOP oder EOM, werden von dem Detektor 113 auf Leitung 115 ausgegeben und in das FIFO 116 und der Kontrolle eines Signals 113a von dem Detektor 113 beschrieben. Ein Signal 113b von dem Detektor 113 zu dem Token-Synchronisierer 106 zeigt an, wann ein ESC-Token empfangen worden ist. Dies wird von dem Token-Synchronisierer benötigt, um die Länge des folgenden Tokens zu bestimmen. Wenn der Detektor 113 ein FCT-Token detektiert, stellt er auf Leitung 117 eine Ausgabe an den Ausgabetokenzähler 82 bereit. Dies zeigt an, dass der empfangende Link jetzt bereit ist, mehr Token zu empfangen (in diesem Beispiel zeigt jeder Flusskontrolltoken an, dass der empfangende Link nun acht weitere Token nehmen bzw. empfangen kann). Das Signal auf Leitung 117 inkrementiert deshalb den Zähler 82 und stellt sicher, dass keine Verhinderungsausgabe auf Leitung 40 bereitgestellt wird.
Der FIFO 116 ist ein Speicher, der in diesem Beispiel das Puffern von acht Token erlaubt. Um die Bandbreite zu verbessern, kann dieses Puffern in diesem Beispiel auf 16 Token erhöht werden. Der FIFO 116 stellt ein Interface mit dem Host bereit, der die Nachricht empfängt, und gibt Daten auf einen Bus 124 an den Host aus sowie ein Daten-Gültig-Signal auf Leitung 125. Die Übermittlung von Daten von dem FIFO 116 an den Host wird in einer synchronisierten Handshake-Operation ausgeführt, und ein Bestätigungssignal wird auf Leitung 126 zu dem FIFO 116 bereitgestellt, wenn der Host die Daten empfangen hat. Wenn der Host den Empfang eines Tokens auf Leitung 116 bestätigt, bestätigt dies, dass der FIFO 116 nun weiteren Platz durch das Entfer nen dieses Tokens hat, und ein Signal wird auf Leitung 127 an die Flusskontrolleinheit 32 bereitgestellt. Das Signal auf Leitung 127 passiert eine Einheit 128 zur Division durch acht und wird in einen Eingabetokenzähler 129 eingespeist. Dieser Zähler 129 zählt Token, wenn sie in den Host von dem Link eingegeben werden. Wenn acht Token durch die Einheit 128 gezählt worden sind, wird der Zähler 129 inkrementiert. Dieser Zähler 129 hat einen Zählwert gleich null, welcher mit dem Linkausgabeuhr bzw. -Zeit über eine Einheit 130 synchronisiert ist und stellt ein Signal auf Leitung 46 bereit, das anfordert, dass ein FCT-Token gesendet werden soll. Der Zähler 129 empfängt auch eine Eingabe auf Leitung 41 von dem Ausgabeinterface 34, um zu bestätigen, dass ein FCT-Token gesendet worden ist, wodurch der Zählwert in dem Zähler 129 vermindert wird.
Das Signal auf Leitung 125 von dem FIFO 116 wird benutzt, um anzuzeigen, dass der FIFO nicht leer ist, und dieses Signal wird synchronisiert mit dem Hosttakt durch einen Synchronisationsschaltkreis 131. Das Bestätigungssignal auf Leitung 126 braucht nicht mit der Linkeingabe 31 synchronisiert zu sein.
Falls der Detektor 113 ein Datentoken als P001 detektiert, was auftreten wird, falls die Daten vor dem Abtastsignal sind, wird der Detektor 113 ein invertiertes Paritätssignal auf Leitung 104 an den Paritätsüberprüfer 105 bereitstellen. Dies ist deshalb, weil der Wechsel in der Eingabe des DAT-Tokens einen Paritätsfehler relativ zu der Ausgabe des Tokens hervorrufen würde, und diese Paritätsinversion erlaubt immer noch, dass die Paritätsüberprüfung gültig ist.
Es wird verstanden sein, dass die obige Anordnung ein einfaches Hochgeschwindigkeitsinterface zwischen Kommunizierender Vorrichtungen in einem Netzwerk bereitstellt. Es erlaubt die Übersendung von Nachrichten in Paketen bzw. Datenpaketen variabler Länge und hat die Fähigkeit, Kontrolltoken sowie Datentoken zu senden, diese Kontrolltoken werden benutzt, um den Fluss zwischen zwei verbundenen Links sowie das Arbeiten innerhalb der Links selbst zu kontrollieren. Die Benutzung von Daten- und Abtastsignalen, wobei das Abtastsignal Übergänge nur an den Bitgrenzen bzw. Randbereichen hat, wo kein Übergang auf dem Datensignal auftritt, stellt verbes serten Betrieb bei hohen Bitfrequenzen bereit, ohne Datenverlust, wenn die Token dekodiert werden. Automatische Ausrichtung bzw. Angleichung der Daten- und Abtastsignale kann durch Benutzung von DAT-Token erreicht werden und, um sich um große Fehlausrichtungen bzw. Fehlangleichungen zu kümmern, die größer als eine Bitperiode sind, kann das System durch Senden einer Anzahl von Ausrichtungstoken bei einer geringeren Geschwindigkeit betrieben werden, und nach vorläufiger Ausrichtung kann auf die Betriebsgeschwindigkeit umgeschaltet und weitere DAT-Token können zur Ausführung der Ausrichtung mit hoher Betriebsgeschwindigkeit gesendet werden. Des Weiteren ist das Vorsehen eines Paritätsbits in jedem Token insbesondere beim Bereitstellen angemessener Überprüfungen vorteilhaft, wenn bei hoher Geschwindigkeit gearbeitet wird. Jedes Paritätsbit ist an einer festen Position in jedem Token, welches in diesem Beispiel das erste Bit in jedem Token ist. Das Paritätsbit in jedem Token stellt eine Überprüfung auf den vorhergehenden Token bereit, dadurch dass es eine Anzeige der Anzahl von Bits bereitstellt, welche seitdem und einschließlich der letzten Daten- oder Kontrollflagge übermittelt worden sind.
Die Erfindung ist nicht auf die Details des vorangehenden Beispiels beschränkt. In dem obigen Beispiel ist jede Daten- oder Kontrollflagge ein einzelnes Bit, das einen Bitlängenanzeiger für die variable Länge des Tokens bildet, aber jeder Token kann mehr als ein Bit beinhalten, um die Tokenlänge anzuzeigen.
Das oben beschriebene Interface kann in einem Computernetzwerk mit adressierbaren Kommunikationskanälen, die virtuelle Kanäle einschließen, benutzt werden, wie es in unserer anhängigen UK-Patentanmeldung Nr. 8915136.9 beschrieben worden ist. In solchen Fällen kann ein Paket bzw. Datenpaket in einem oder mehreren Token die Adresse einer Leitung oder virtuellen Leitung beinhalten, die benutzt wird, um die Kommunikation auszuführen.
Die Zustandstabellen, die die Übergangszustände der obigen Zustandsmaschine darstellen, sind wie folgt:
In den folgenden Zustandstabellen werden die folgenden Konventionen benutzt.
Ausgaben bzw. Outputs sind eine Funktion des Zustandes und keine Funktion von Eingaben bzw. Inputs, sofern nicht explizit etwas anderes gesagt wird (z. B. Strobe = InvertStrobe).
Wenn ein Zustand keine gültigen Eingaben bzw. Inputs hat, verbleibt die Zustandsmaschine in dem gegenwärtigen Zustand.
Wo ein Zustand als "Any" spezifiziert ist und dort keine gültige Eingabe bzw. kein gültiger Input ist, dann überwindet der spezifizierte Zustandsübergang alle anderen Übergänge, z. B. falls in der folgenden Tabelle "Reset" gesetzt ist, dann wird die Zustandsmaschine einen Übergang zum Zustand "00" machen, unabhängig von den anderen Eingaben bzw. Inputs.
Schlüssel (Key)

~

NOT

∧

AND

∨

OR

=

Bezeichnung, z. B. A = B bedeutet, dass Ausgabe bzw. Output A den Wert von Eingabe bzw. Input B annimmt; A = 0 bedeutet, dass die Ausgabe bzw. der Output A auf 0 gesetzt ist.

Takten (clocking)
In diesem Beispiel sind alle Ausgabezustandsmaschinen synchronisiert. Die Linkeingabe enthält synchrone und asynchrone Zustandsmaschinen. Die synchronen Zustandsmaschinen in der Linkeingabe antworten auf bzw. reagieren auf beide Ränder bzw. Flanken der Uhr bzw. des Taktes.
Daten/Abtast-Kodierer (Data/Strobe-Encoder) (62)
Token-Sequenzierer (52) (Token Sequencer)
Datenausrichtungstokenerzeuger (Data Alignment Token Generator) (65)
Paritätserzeuger (59) (Parity Generator)
Tokenanforderungs-Latches (43) (Token Request Latches)
Dies ist tatsächlich eine Maschine mit vier identischen, getrennten Zustandsmaschinen, eine für jedes der DAT, FCT, Data und Null. Die Zustandstabelle für eine von diesen ist unten gezeigt. "Send" entspricht SendDAT, SendFCT etc., TokenRequest entspricht DATRequest etc. (Eingaben an den Token-Priorisierer), TokenSent entspricht FCTSent etc. und TokenPrioritised entspricht zu DATPrioritised, FCTPrioritised etc. (Ausgaben von dem Token-Priorisierer). Dort ist ein zusätzliches Stück von Logik zum Erzeugen des "AnyRequest"-Signals.

AnyRequest = NullRequest∨FCTRequest∨DATRequest∨DataRequest

Sequenzierer (Sequencer) (57)
Host I/F (34)
Control Code Rom & Mux (53)
Ausgabeschieberegister (54) (Output Shift Register)
In der folgenden Zustandstabelle sind d0-7 und "Control" boolsche Variablen, die abgetastet werden, wenn sie als Eingaben in die Zustandsmaschine spezifiziert sind, das heißt deren Werte sind in den Zuständen "C" bis "7" unverändert.
Token-Priorisierer (50) (Token Prioritiser)
Die Randdetektoren, Arbiter und Daten-/Taktextraktoren sind asynchrone Zustandsmaschinen und ändern deshalb ihren Zustand, sobald eine Eingabe bzw. ein Input sich verändert. Die anderen Zustandsmaschinen sind mit der halben Baud-Rate (das heißt 50 MHz für 1000 MBaud) getaktet und sind synchron.
Randdetektoren (Edge Detector) (asynchron) (95–98)
In der folgenden Tabelle, Reset = Main Reset ∨ ResetEdgeDetector. Dieser Randdetektor detektiert steigende Ränder. Abfallende Randdetektoren haben die Eingabe von den Verzögerungsleitungen invertiert.
(Arbiters)-(asynchron) (99)
Dort sind 6 Vermittler, einer zwischen jedem Paar von Eingaben bzw. Inputs.
Die Zustandstabelle für einen der Vermittler ist unten gezeigt:
Die Ausgaben bzw. Outputs von den individuellen Arbiters werden wie folgt kombiniert, um die vier Ausgaben bzw. Outputs von dem Arbitermodul in dem Diagramm zu ergeben.
DataRisingArbitrated = DataRising1∧DataRising2∧DataRising3
DataFallingArbitrated = DataFalling1∧DataFalling2∧DataFalling3
StrobeRisingArbitrated = StrobeRising1∧StrobeRising2∧StrobeRising3
StrobeFallingArbitrated = StrobeFalling1∧StrobeFalling2∧StrobeFalling3
Daten-/Taktextrahierer (Data/Clock Extractor) (asynchron) (101)
Die Uhr- bzw. Taktausgabe bzw. der Output wird bezüglich der Datenausgabe bzw. des Datenoutputs relativ verzögert, um die Zeit des Schieberegisters, des Paritätsüberprüfers und des Token-Sequenzierers zu setzen.
Die folgenden Zustandsmaschinen sind synchronisiert und können den Zustand sowohl bei anfallenden als auch bei abfallenden Takträndern ändern.
Paritätsüberprüfer (Parity Checker) (synchron) (105)
Das Rücksetzparitätssignal (ResetParity signal) wird während des letzten Bits von jedem Token gesetzt. Wenn dies auftritt, wird der Zustand (gemeinsam mit den Daten und den InvertParity-Eingaben bzw. InvertParity inputs) benutzt, um festzustellen, ob dort ein Paritätsfehler ist.
Tokensynchronisierer (Token Synchroniser) (synchron) (106)
Kontrollkodedetektor (Control Code Detector) (synchron) (113)
KONTROLLZUSTANDSTABELLE (CONTROL STATE TABLE) (33)
Dies ist ein Beispiel eines Typs von einer Kontrollzustandsmaschine, die benutzt werden könnte. Der Link wird zuerst zu einer langsamen Uhr geschaltet, und eine Anzahl (in diesem Fall 100) Datenausrichtungstoken (Data Alignment Tokens) werden gesendet. Der Link wird dann zu einer höheren Geschwindigkeit geschaltet. Datenausrichtungstoken (Data Alignment Tokens) werden dann periodisch gesendet.

Claims

Ein Kommunikationsinterface (21) zur Benutzung in einem Kommunikationssystem, wobei das Interface umfasst: einen Ausgabeschaltkreis (30) zum Ausgeben von Nachrichten, wobei der Ausgabeschaltkreis einen Kontrollschaltkreis (33) und einen Kodierungsschaltkreis (62) zum Kodieren und Ausgeben einer Folge von Tokens, die jeweils eine fortlaufende Bitzeichenkette umfassen, umfasst; einen Eingabeschaltkreis (31) zum Eingeben von Nachrichten, wobei der Eingabeschaltkreis einen Dekodierungsschaltkreis (113) zum Eingeben und Dekodieren von Daten, die in jedem seriellen Token empfangen worden sind, beinhaltet; dadurch gekennzeichnet, dass das Kommunikationsinterface so angepasst ist, dass ein Computer mit mindestens einem anderen Gerät verbunden wird, wobei jede Nachricht eine Folge von Tokens variabler Bitlänge umfasst, wobei jeder Token ein Paritätsbit und wenigstens ein anderes Bit hat, das einen Bitlängenindikator für den Token formt; der Ausgabeschaltkreis umfasst einen Paritätsbiterzeuger (59), der auf die nachfolgenden Bits nach dem Bitlängenindikator in einem ersten Token bis einschließlich eines Bitlängenindikators in einem zweiten Token anspricht, und der so eingerichtet ist, das Paritätsbit zur Aufnahme in jeden Token zu erzeugen; und der Eingabeschaltkreis umfasst einen Paritätsprüfungsschaltkreis (105) zum Detektieren des Paritätsbits in jedem Token und zum Vergleichen besagten Paritätsbits mit einem Bitmuster nach einem Bitlängenindikator in einem Token bis einschließlich zum nächsten Bitlängenindikator.
Ein Kommunikationsinterface gemäß Anspruch 1, in welchem der Kontrollschaltkreis einen Flaggenbiterzeuger zum Erzeugen eines Flaggenbits zur Aufnahme in jeden Token zur Identifizierung jedes Tokens als Datentoken oder als Kontrolltoken beinhaltet.
Ein Kommunikationsinterface gemäß Anspruch 1 oder 2, wobei der Eingabeschaltkreis einen Verzögerungsschaltkreis beinhaltet, der zwischen jedem der zwei Inputs und dem Entschlüsseler angeschlossen ist, und Mittel zum Variieren der Verzögerung auf einem oder beiden der Inputs vor dem Dekodieren.
Ein Kommunikationsinterface gemäß einem der vorhergehenden Ansprüche, in welchem der Ausgabeschaltkreis Flusskontrollmittel zum Erzeugen von Flusskontrolltokens zum Ausgeben an ein angeschlossenes Kommunikationsinterface beinhaltet, und in welchem der Eingabeschaltkreis Mittel beinhaltet, die auf die Eingabe eines Flusskontrolltokens durch Ausgeben weiterer Datensignale ansprechen, um den Betrieb des Ausgabeschaltkreises zu kontrollieren.
Ein Kommunikationsinterface gemäß einem der vorhergehenden Ansprüche, in welchem der Paritätsbiterzeuger mit dem Dekodierer so gekoppelt ist, dass er auf die Nummer des Bits, die in einem ersten Token nach einem Flaggenbit in dem ersten Token kodiert ist, anspricht, und dass er ein Paritätsbit an einer ersten Stelle eines zweiten Tokens bereitstellt, die den Gesamtwert der Anzahl von Bits von dem ersten Token zusammen mit dem Paritäts- und Flaggenbit des zweiten Tokens anzeigt.
Ein Verfahren zum Bewirken einer Kommunikation zwischen mindestens zwei miteinander verbundenen Geräten, wobei das Verfahren das Aufbauen eines unidirektionalen Kommunikationspfades zwischen zwei Linkinterfaces umfasst, wobei jedes mit dem jeweiligen Gerät verbunden ist, dadurch gekennzeichnet, dass wenigstens eines der Geräte einen Computer umfasst, und durch Kodieren einer Folge von Tokens variabler Länge, wobei jeder eine serielle Bitzeichenkette, die ein Paritätsbit und mindestens ein anderes Bit beinhaltet, umfasst, das einen Bitlängenindikator für den Token formt, Erzeugen eines Paritätsbits als Antwort auf nachfolgende Bits eines ersten Tokens, die einem ersten Bitlängenindikator für den ersten Token folgen, bis einschließlich einem Bitlängenindikator für einen nächsten Token, Aufnehmen des Paritätsbits in einen To ken, um eine Bitüberprüfung in dem ersten Token und den Bitlängenindikator des nächsten Tokens bereitzustellen, serielle Übertragung der Tokens von dem einen Linkinterface zu dem anderen Linkinterface, Dekodieren der Tokens an dem anderen Linkinterface, Detektieren des Paritätsbits und Vergleichen des Paritätsbits mit dem dekodierten Bitmuster.
Ein Verfahren gemäß Anspruch 6, in welchem jedes Paritätsbit ein erstes Bit in einem Token formt und der Bitlängenindikator ein zweites Bit formt.
Ein Verfahren gemäß Anspruch 6 oder Anspruch 7, das des Weiteren das Aufbauen von vier unidirektionalen Kommunikationspfaden zwischen jedem Paar von Linkinterfaces umfasst, wobei die vier Pfade ein erstes paralleles Paar von Daten und Signalpfaden in einer Richtung und ein zweites paralleles Paar von Daten und Signalpfaden in der entgegengesetzten Richtung umfassen.
Ein Verfahren gemäß einem der Ansprüche 6 bis 8, wobei Daten durch ein Linkinterface in Form von Tokens ausgegeben werden, die länger als eine vorbestimmte Bittlänge sind.
Ein Verfahren gemäß einem der Ansprüche 6 bis 9, das ferner das Erzeugen eines Flaggenbits zur Aufnahme in jeden Token zur Identifizierung des Tokens als ein Datentoken oder als ein Kontrolltoken beinhaltet.
Ein Verfahren gemäß Anspruch 10, wobei das Paritätsbit und das Flaggenbit sich in einer ersten bzw. zweiten Bitposition in jedem Token befinden.
Ein Verfahren gemäß Anspruch 10 oder Anspruch 11, das ferner das Formen von zwei aufeinander folgenden Kontrolltokens zum Bilden eines Verbundtokens umfasst, wobei das erste der Kontrolltoken ein Bitmuster aufweist, das anzeigt, dass ein weiterer Token erforderlich ist, um die Kontrolle zu bestimmen, die durch das Verbundtoken angezeigt wird.
Ein Verfahren gemäß einem der Ansprüche 6 bis 12, worin Nachrichten zwischen verbundenen Linkinterfaces in Form von Paketen variabler Länge übermittelt werden, jedes Paket umfasst eine Mehrzahl von Tokens, wobei jeder Token von einer vordefinierten Bitlänge ist, und stellt einen Paket-Ende-Token am Ende jedes Paketes bereit.
Ein Verfahren gemäß einem der Ansprüche 6 bis 13, das das Bilden von Flusskontrolltokens zum Ausgeben durch ein Linkinterface, das Ausgeben von Daten von einem ersten Interface zu einem zweiten Interface, das Ausgeben eines Flusskontrolltokens von dem zweiten Interface zu dem ersten Interface, um dem ersten Interface anzuzeigen, dass weitere Datentokens an das zweite Interface ausgegeben werden können, beinhaltet.
Ein Verfahren gemäß Anspruch 14, das ferner umfasst: Erhalten eines Zählwertes, welcher durch die Ausgabe von Tokens durch ein Ausgabeverbindungsinterface angepasst wird, Verhindern von weiterer Ausgabe von Datentokens von besagtem Linkinterface, wenn der Zählwert eine vordefinierte Zahl erreicht, und Anpassen des Zählwertes in Erwiderung auf die Eingabe von Flusskontrolltokens von einem verbundenen Interface, um die Ausgabe von weiteren Datentokens zu erlauben.
Ein Verfahren gemäß einem der Ansprüche 6 bis 15, wobei jedes Verbindungsinterface so eingerichtet ist, dass es Ausgabekontrolltokens von zwei Typen ausgibt, einen ersten Typ zum Kontrollieren des Betriebes eines angeschlossenen Linkinterfaces und einen zweiten Typ zur Benutzung durch das Gerät, das mit dem zweiten Linkinterface verbunden ist.
Ein Verfahren gemäß Anspruch 16, das das Transferieren von Datentokens und Kontrolltokens des zweiten Typs von einem Speicher in dem Linkinterface zu dem Gerät, das mit dem Linkinterface verbunden ist, durch Verwendung eines synchronisierten Handshakes beinhaltet.