-
Diese
Erfindung bezieht sich auf eine Kommunikation zwischen Einrichtungen,
die an ein Datenkommunikationssystem angeschlossen sind. Insbesondere
bezieht sich diese Erfindung auf eine Kommunikationssteuerung, die
Datenpakete von einem seriellen Hochgeschwindigkeitsbus empfängt und
Funktionen veranlasst, die an Knoten des Busses durchzuführen sind,
basierend auf den Inhalten der Datenpakete.
-
In
Allgemeinen gibt es zwei Arten von Datenbussen: serielle und parallele.
Ein paralleler Bus wird typischerweise an seiner Kapazität und Geschwindigkeit
gemessen. Eine Breitenkapazität
eines parallelen Busses wird in Bytes gemessen und seine Geschwindigkeit
wird üblicherweise
in Megahertz oder Bytes/Sekunde gemessen. Zum Beispiel ist der bekannte
Peripherkomponenten-Zwischenverbindungsbus (Peripheral Component
Interconnect: PCI-Bus) ein paralleler Bus, der 32 Bit breit ist
und bis zu 33 MHz betrieben werden kann. Bei dieser Frequenz kann
er Daten bei einer Rate von über
1 Gigabit pro Sekunde (1 Gbps) tragen bzw. transportieren. Ein Definitionsmerkmal
eines parallelen Busses ist, dass sämtliche der Bits in seiner
Breite gleichzeitig gesendet werden, wobei z.B. in dem PCI-Bus sämtliche
32 Bits zur gleichen Zeit während
eines Zyklus gesendet werden. Dies erfordert zumindest so viele
Signalleitungen in dem Bus, wie seine Breite ist, und zusätzliche
Leitungen für
Adressierungssignale, eine Leistungszufuhr und andere Signale. Der
PCI-Bus hat nahezu 50 Signalleitungen. Signalleitungen werden üblicherweise
als Spuren bzw. Leiter auf einer gedruckten Schaltungsplatine oder
als Drähte
ausgebildet. Die große
Anzahl an Signalleitungen in einem parallelen Bus macht die Realisierung
teuer. Zusätzlich
ist die Anzahl von Einrichtungen auf einen PCI-Bus begrenzt und
jede Einrichtung fordert eine Karte und einen offenen entsprechenden
Kartenschlitz bzw. -anschluss, um in den Bus eingesteckt zu werden.
-
Umgekehrt überträgt ein serieller
Bus Daten mit einem Bit zu einer Zeit. Obwohl dies die Anzahl von Leitungen,
die für
den seriellen Bus nötig
sind, verringert, dehnt dies die zur Übertragung von Daten erforderliche
Zeit, verglichen mit einem parallelen Bus, aus. Zum Beispiel überträgt, wenn
ein Betrieb oder dergleichen Frequenz vorliegt, ein serieller Bus
nur ein Datenbit in der gleichen Zeit, in der ein PCI-Bus Bit überträgt. Ein Beispiel
eines seriellen Busses ist der universelle serielle Bus (USB). Dieser
Bus enthält
vier Drähte
bzw. Leitungen und hat eine maximale Datenrate von 12 Megabit pro
Sekunde (Mbps). Die geringe Anzahl an Drähten machen einen seriellen
Bus ideal zur Zwischenverbindung von Einrichtungen über ein
Kabel, da das Kabel kostengünstig
hergestellt werden kann. Weil jedoch datenintensive Anwendungen
erfordern, dass ein hohes Datenvolumen schnell bewegt werden kann,
haben sich Hersteller allgemein eher auf parallele als auf serielle Busse
für die
Zwischenverbindung von datenintensiven Einrichtungen verlassen.
Anwendungen, die solche datenintensiven Einrichtungen verwenden,
enthalten die Video- und Audiowiedergabe, Hochgeschwindigkeitsspeichereinrichtungen,
wie etwa Festplattenlaufwerke, u. a.
-
Bis
jetzt mussten Konstrukteure von Systemen, die Daten über einen
Bus bewegen, zwischen dem schnellen und teuren parallelen Bus oder
dem langsamen und kostengünstigen
seriellen Bus wählen.
Kürzlich sind
Spezifikationen für
einen seriellen Hochgeschwindigkeitsbus durch das Institute of Electrical
and Electronics Engineers angepasst worden. Die Spezifikation IEEE
1394-1995 ist als "FireWire" oder einfach 1394
bekannt. Die 1394-Spezifikation enthält Standards für Datenübertragungsraten
von bis zu 400 Mbps, wobei nur 2 Paare von Datenleitungen bzw. -dähten und
ein Paar von Leitungen bzw. Drähten
für die
Leistung verwendet werden. Diese Datenrate ist schnell genug, um
die datenintensiven Bedürfnisse
von Video, Audio und Hochgeschwindigkeitsspeicherung unterzubringen.
Weitere Bedürfnisse
werden durch einen anderen vorgeschlagenen 1394-Standard befriedigt,
der eine Datenrate von über
1 Gbps hat. Deshalb können
durch Verwendung eines 1394-Standardbusses datenintensive Aufgaben
kostengünstig
auf einem seriellen Bus ohne die Nachteile der Verwendung eines
parallelen Busses implementiert werden.
-
Der
1394-Bus verwendet eine Gleich-zu-Gleich-Architektur. Physikalische
und logische Knoten sind an den 1394-Bus mittels eines Kabels mit
sechs Leitern angeschlossen. Bis zu 63 Knoten können an jede unabhängige Busbrücke angeschlossen
werden und 1023 Brücken
sind in dem System erlaubt für
eine Gesamtanzahl von über
65.000 Einrichtungen an einem 1394-System. Es ist wahrscheinlich,
dass eine 1394-zu-PCI-Schnittstelle, die wahrscheinlich den Open-Host-Controller-Schnittstellenstandard
(OHCI-Standard) verwendet werden wird, wenn ein 1394-Bus in einem
Computer verwendet wird. Strikt ausgedrückt, kann jedoch der 1394-Bus
unabhängig
von einem Computer betrieben werden, indem Einrichtungen, die einen Bezug
haben, über
das Anschlusskabel zusammengekoppelt werden. Zusätzlich zu einer Kabelspezifikation
wird eine Rückwandspezifikation
für den
1394-Bus zur Verfügung
gestellt. Eine Rückwandspezifikation
wird am wahrscheinlichsten für
einen Bus innerhalb eines Computers oder einige andere vollständig aufgenommene Systeme
verwendet. Die Kommunikationssteuerung, die hierin beschrieben wird,
arbeitet entweder in der Kabel- oder der Rückwandumgebung.
-
Der
1394-Standard spezifiziert drei "Schichten", die physikalische,
die verbindungsmäßige und
die übertragungsmäßige. Die
physikalische Schicht überträgt elektrische
Signale entlang des seriellen Busses, vermittelt den Bus, indem
sichergestellt wird, dass nur ein Knoten zu einer Zeit sendet, und übersetzt
elektrische Signale, die von dem Bus erfasst worden sind, in Datensignale
für die
Verbindungsschicht. Die Verbindungsschicht ordnet die Datensignale,
die von dem Bus gewonnen worden sind, in Datenpaketen an und stellt Services
bzw. Dienste zur Verfügung,
wie etwa Adressierung, Datenprüfung
und die Erzeugung eines "Zyklus"-Signals, das für die zeitliche Steuerung bzw.
Taktung und Synchronisation verwendet wird. Die Übertragungsschicht akzeptiert
die Datenpakete von der Verbindungsschicht und enthält Busübertragungen,
die erforderlich sind, um eine Befehls- und Statusregisterarchitektur
(CSR-Architektur) zu unterstützen,
einschließlich
Lesen, Schreiben und Datensperre. Verschiedene andere Busse verwenden
den CSR-Standard und spezifizieren, dass 1394 auch zu dem CSR-Standard
passen muss, was es einfach macht, einen 1394-Bus an diese anderen
Busse anzupassen oder anzuschließen. Allgemein erscheinen die
physikalische Schicht und die Verbindungsschicht wie auch eine begrenzte
Anzahl von Abwicklungsfunktionen in der Hardware. Der Rest der Abwicklungsschichtfunktionen
wird mit Software durchgeführt.
-
Um
zweckmäßig zu sein,
müssen
zusätzliche
Kommunikationsschichten mit den 1394-Schichten kommunizieren und oberhalb
dieser arbeiten. Zum Beispiel ist direkt oberhalb der Abwicklungsschicht
eine Übertragungsschicht,
die z.B. ein serielles Busprotokoll-2 (SBP-2) oder funktionales
Steuerprotokoll (FCP) verwendet. Diese Standards definieren ein
Protokoll für
den Transport von Befehlen und Daten über serielle Busse mit hoher
Funktionsfähigkeit.
Zusätzlich
ist über
der Transportschicht eine Anwendungsschicht, die solche Protokollstandards
verwendet, wie etwa mit reduziertem Block (RBC), Druckerarbeitsgruppe
(PWG) oder Internetprotokoll (IP). Die Zwischenwirkung dieser Schichten
miteinander und mit den Schichten der 1394-Spezifikation werden
hierin weiter beschrieben.
-
Es
ist folglich wünschenswert,
eine Kommunikationssteuerung zu haben, die sämtliche der Tätigkeiten durchführt, die
in der 1394-Spezifikation in einer zweckentsprechenden Weise ausgeführt sind.
Es ist auch für die
Kommunikationssteuerung wünschenswert,
leicht skalierbar zu sein, um neue Dienste und Aufgaben zu enthalten.
Es ist auch ein Vorteil, eine Kommunikationssteuerungsarchitektur
zu entwickeln, die leicht für
eine Vielzahl von Rollen und Funktionen modifiziert werden kann.
-
Die "High Performance
Transport"-Überarbeitung
0,3e durch Shigeru Ueda und Akihiro Shimura (Canon Inc.) definiert
ein Protokoll mit einem kleinen Befehlssatz und ein Verhaltensmodell
zum Transportieren bzw. Übermitteln
von Daten zwischen einem Computersystem und einer peripheren Einrichtung über ein
serielles Busprotokoll 2 (SBP-2). Der HPT stellt eine vollständige Duplex-Kommunikationsfähigkeit
zwischen einer Initiatoreinrichtung und einer Zieleinrichtung zur
Verfügung.
-
In
einem Datenkommunikationssystem, z.B. einem 1394-Bussystem, arbeitet
eine Abwicklungsschnittstelle an einem logischen Knoten auf dem
Bus. Da Pakete entlang dem Bus gerichtet in Richtung des spezifischen
Knotens, auf dem die Abwicklungsschnittstelle sitzt, gesendet werden,
dekodiert die Abwicklungsschnittstelle den Paketinhalt in Steuerblöcke für einen
weiteren Betrieb. Der weitere Betrieb kann die Ausführung durch
eine Anwendung enthalten, die auch auf dem lokalen Knoten arbeitet.
Zusätzlich
kann die Anwendung erfordern, dass Daten zu einem anderen Knoten
in dem Bus übertragen
werden. In diesem Fall kommuniziert die Anwendung mit der Abwicklungsschnittstelle über Nachrichtensteuerblöcke, welche
dann in Datensignale gewandelt werden und auf dem Bus angeordnet
werden, um an dem Zielknoten empfangen zu werden.
-
Die
Erfindung wird in den Ansprüchen
1, 11 und 15 hervorgehoben.
-
Einige
Ausführungsformen
der Erfindung werden nun im Wege eines Beispiels und unter Bezugnahme auf
die begleitenden Darstellungen beschrieben, in welchen:
-
1 eine Darstellung ist,
die eine mögliche
1394-Buskonfiguration zeigt.
-
2 ist eine Darstellung,
die Schichten des 1394-Standards wie auch Schichten zeigt, die mit
den Schichten des 1394-Standards wechselwirken.
-
3 ist eine Darstellung,
die Dienste und Aufgaben gemäß einer
Ausführungsform
der vorliegenden Erfindung zeigt.
-
4 ist ein Diagramm, das
eine Struktur eines Nachrichtensteuerblockes zeigt.
-
5 ist ein Diagramm, das
Dienste und Aufgaben gemäß einer
anderen Ausführungsform
der vorliegenden Erfindung zeigt.
-
6 ist ein Diagramm, das
Anwendungen und Protokolle zeigt, die mit einem 1394-Bus verwendet werden
können.
-
Die 1 zeigt ein Verfahren zur
Realisierung einer 1394-Busarchitektur. Ein Bus 100 wird
in drei lokale Busse A, B und C unterteilt. Sowohl der lokale Bus
A als auch der lokale Bus C verwendet eine Busbrücke 110, um an den
lokalen Bus B angeschlossen zu sein. Die Einrichtungen sitzen als
Knoten an den lokalen Bussen. Eine Schichtstruktur 2, die
unten beschrieben wird, ist innerhalb sämtlicher der Knoten auf dem
Bus enthalten. Die Einrichtungen können irgendeine Einrichtung
sein, die verwendet wird, um Daten zu erzeugen, anzunehmen oder
zu übertragen,
wie etwa ein erstes Festplattenlaufwerk 120, ein zweites
Festplattenlaufwerk 122 oder einen Druck 124.
Jeder lokale Bus kann ein Maximum von 63 Knoten haben, wobei jedoch
durch Verwendung von Busbrücken
ein 1394-Bussystem über
65.000 Knoten haben kann. Typischerweise ist der Datenverkehr auf
einen lokalen Bus begrenzt, so dass z.B. Einrichtungen an dem lokalen
Bus C keine Daten erkennen können,
die auf dem lokalen Bus A durchgelaufen sind. Dies erhöht die Bandbreite
des Bussystems, indem nur Daten auf einem lokalen Bus durchlaufen,
der auf den lokalen Bus gerichtet ist. Die Busbrücke 110 überwacht
den Busverkehr auf dem lokalen Bus, an den sie angeschlossen ist,
wobei sie nach Daten sucht, die für einen Knoten an einem anderen
lokalen Bus gedacht sind. Wenn solche Daten erfasst werden, überträgt die Busbrücke 110 die
Daten zu dem gewünschten
Bus. Deshalb kann der Drucker 124 auf dem lokalen Bus A
Daten entweder von dem Festplattenlaufwerk 120 (auf dem
lokalen Bus A) oder von dem Festplattenlaufwerk 122 über die
lokale Busbrücke 110 (an
dem lokalen Bus B) empfangen. Zusätzlich könnte die Busbrücke 110 an
den 1394-Bus zu einem Bus angekoppelt sein, der typischerweise in
einem Computer verwendet wird, wie etwa ein PCI-Bus (nicht gezeigt).
-
Die 2 zeigt einen allgemeinen Überblick
der Schichtstruktur 2 von 1394, einschließlich des
Managements des seriellen Busses. Diese Schichtstruktur erscheint
in jedem Knoten, der an einen lokalen 1394-Bus angesetzt ist. Die
Schichtstruktur 2 enthält
eine Abwicklungs- bzw.
Transaktionsschicht 10, eine Verbindungsschicht 20,
eine physikalische Schicht 30 und ein Management 40 eines
seriellen Busses. In Verbindung mit den 1394-Schichten werden auch
eine Transportschicht 80 und eine Anwendungsschicht 90,
wie oben beschrieben, verwendet. Die Kommunikation zwischen den
Schichten 10, 20, 30 und dem Management 40 des
seriellen Busses wie auch mit den Schichten 80 und 90 geschieht über eine
bidirektionale Zwischenschichtkommunikation 50, die mehr
als einen Kommunikationspfad enthalten kann. Die Kommunikation 50 muss
kein Datenbus sein, kann aber irgendeine einer Anzahl von Kommunikationsverfahren
sein, wie etwa Signaldrähte,
aufgeteilte Speicherressourcen oder andere Mittel. Wie in 2 gezeigt, kommuniziert
die Transaktions- bzw. Abwicklungsschicht 10 unmittelbar
mit der Verbindungsschicht 20, einem Busmanager 55 und gibt
isochrone Signale zu einem isochronen Ressourcenmanager 65,
der innerhalb der Managementeinrichtung 40 des seriellen
Busses enthalten ist.
-
Schichten
in einem Kommunikationssystem, wie etwa dem 1394-Bus, sind vorgesehen
bzw. angeordnet, um unabhängig
von Schichten um sie herum, aber in Verknüpfung bzw. Verbindung mit diesen
zu arbeiten. Im Allgemeinen ist die Ordnung eine Schicht um so höher, je
ferner eine Schicht von der Hardware, wie etwa den Datendrähten bzw.
-leitungen eines 1394-Busses,
ist. Schichten höherer
Ordnung können
Funktionen höherer
Ordnung durchführen.
Zum Beispiel führt
die Transaktions- bzw. Abwicklungsschicht 10 der 1394-Spezifikation
nur Lese-, Schreib- und Haltefunktionen durch. Eine Transportschicht 80 kommuniziert
mit der Transaktionsschicht bzw. Abwicklungsschicht 10 und
hat Befehle höherer
Ordnung. Der bestimmte Standrad der verwendeten Transportschicht
bestimmt seine Befehle. Zum Beispiel sind in der SBP-2-Transportsschicht
Befehle verfügbar,
wie etwa Einloggen, wieder Verbinden und Einstell- bzw. Ansteuerungspasswort. Über der Transportschicht 80 ist
eine Anwendungsschicht 90, die Protokolle verwendet, wie
etwa RBC, PWG oder IP. Die Anwendungsschicht 90 arbeitet
in Verbindung mit Software, um die gewünschte Anwendung durchzuführen.
-
Die
1394-Spezifikation enthält
zwei grundlegende Datenübertragungsdienste,
die isochrone Datenübertragung
und die asynchrone Datenübertragung.
Die isochrone Datenübertragungsspezifikation
ermöglicht es,
Pakete entlang des seriellen Hochgeschwindigkeitsbusses mit regelmäßigen Intervallen
zu senden. Typischerweise werden die isochronen Datenübertragungsdienste
für große Volumen
von Daten verwendet, die zwischen einem Datengenerator und einem
Datenempfänger
getragen werden, z.B. einer digitalen Videokamera und einer Multimediaelektronik,
wie etwa einem Videodisplay oder einem Videoeditor. Eine isochrone
Datenübertragung
kommuniziert unmittelbar mit der Verbindungsschicht 20 und
umgeht die Transaktionsschicht bzw. die Abwicklungsschicht 10.
Die Transaktions- bzw. Abwicklungsschicht wird nur für eine asynchrone
Datenübertragung
verwendet. Der Hauptanteil der Bandbreite innerhalb der 1394-Spezifikation
ist für
die isochrone Datenübertragung
reserviert, wobei 20% der Bandbreite für eine asynchrone Datenübertragung
ist.
-
Eine
Knotensteuerung 75 ist unmittelbar an die Verbindungsschicht
und die physikalische Schicht angeschlossen. Der Busmanager 55,
der isochrone Quellen- bzw. Ressourcenmanager 65 und die
Knotensteuerung 75 werden jeweils gemäß dem CSR-Standard, IEEE 1212-1991,
angesteuert bzw. betrieben. Andere Arten von Bussen verwenden auch
diesen CSR-Standard, wobei die Anschließbarkeit eines 1394-Busses
ausgedehnt wird. Die CSRs sind innerhalb des seriellen Busmanagers 40 angeordnet
und werden als ein Management- bzw. Verwaltungs-CSR 57, ein isochroner CSR 67 und
ein Standard-CSR 77 dargestellt.
-
Die
Schichtstruktur 2, die ein serielles Busmanagement 40 enthält, ist
in jedem Knoten entlang des Busses vorhanden. Jedoch ist nur ein
Busmanager 55 und ein isochroner Quellen- bzw. Ressourcenmanager 65 an
dem lokalen Bus aktiv. Diese Manager üben Managementverantwortlichkeiten über den
gesamten lokalen Bus aus. Weil jeder lokale Bus nur einen Busmanager 55 (und
nur einen haben kann) und nur einen isochronen Quellen- bzw. Ressourcenmanager 65 benötigt, sperren
die anderen Knoten ihre jeweiligen Busmanager und isochronen Quellen-
bzw. Ressourcenmanager. Die Knotensteuerung 75 ist für sämtliche
operativen Knoten aktiv.
-
Wie
oben bemerkt, werden die Verbindungsschicht 20 und die
physikalische Schicht 30 im Allgemeinen durch Hardware
verkörpert,
z.B. einen von Silicon System Design, Inc. oder auch von Texas Instruments, Inc.
verfügbaren
Chip. Die Transaktions- bzw. Abwicklungsschicht 10, die
Transportschicht 80, die Anwendungsschicht 90 und
andere Funktionen der Transportschnittstelle werden allgemein in
einer Softwareform verwirklicht, das heißt einem Softwareprogramm,
das ausgeführt
wird, sobald es in einen Speicher geladen ist. Bei einer bevorzugten
Ausführungsform
werden die Schichten und Funktionen in Firmware gespeichert, z.B. Kodes,
die in einer programmierbare Speichereinrichtung gespeichert werden,
wie etwa einem Festspeicher (ROM), einer programmierbaren logischen
Anordnung (PLA) oder einem auf einer Festplatte gespeicherten Programmteil
bzw. Programmpunkt. Ferner könnten
die Schichten und Funktionen in eine anwendungsspezifische integrierte
Schaltung (ASIC) mittels Verfahren, die im Stand der Technik wohl
bekannt sind, programmiert werden. Allgemein arbeitet eine Auswahl
von Operationen wie jene, die oben aufgelistet sind, schneller in
Hardware als in Software, wobei jedoch ein Softwareprogramm leichter
zu ändern,
zu korrigieren und zu aktualisieren ist. Die bevorzugte Ausführungsform
von Firmware kombiniert Vorteile sowohl der Hardware als auch der
Software.
-
3 zeigt eine Ausführungsform
der vorliegenden Erfindung. Eine Kommunikationssteuerung 200 erscheint
in jedem Knoten auf dem Bus, wie etwa in den Festplattenlaufwerken 120, 122 oder
in dem Drucker 124, die in 1 gezeigt
sind. Die Transaktions- bzw. Abwechslungsschnittstelle 210 verkörpert einige
der in 2 gezeigten Bestandteile.
Unter Bezugnahme auf die in 3 gezeigten
Bestandteile könnte
ein Chip, der die Transaktions- bzw. Abwicklungshardware 205 verkörpert, die
zuvor aufgezeigten Chips von Silicon System Design oder Texas Instruments
sein. Die Abwicklungsschnittstelle 210 verwirklicht die
1394-Abwicklungsschicht.
Das Managementunterprogramm 235 des seriellen Busses implementiert
Funktionen des Busmanagements, wie etwa eine Rücksetzung oder eine Rücksetzung
beim Einschalten. Der Rest der in 3 gezeigten
Darstellungen implementiert Funktionen und Befehle, die durch die
Transportschicht bestimmt werden, wie etwa SBP-2, in Verbindung
mit der Anwendungsschicht, wie etwa RBC.
-
Mit
der Ausnahme der Abwicklungshardware 205 können die
Darstellungen in 3 in
zwei Klassifikationen, Dienste und Unterprogramme bzw. Aufgaben
aufgeteilt werden. Ein Task bzw. ein Unterprogramm kann andere Tasks
oder Dienste aufrufen. Ein Service bzw. ein Dienst kann nur antworten,
wenn er durch ein Unterprogramm bzw. einen Task aufgerufen worden
ist, und wenn er fertigt ist, er zu dem aufrufenden Unterprogramm
bzw. Task zurückkehrt.
Die Abwicklungsschnittstelle 210 ist ein Dienst bzw. Service
zusammen mit einem Kern (Anwendungssystem)/Scheduler (Steuerprogramm)/Dispatcher
(Zuteiler) 220. Der Rest der Darstellungen, die in 3 gezeigt sind, sind Unterprogramme
bzw. Tasks, wie unten beschrieben wird.
-
Die
Abwicklungshardware 205 überwacht den 1394-Bus und wandelt
elektrische Signale, die von dem Bus in Datenpaketen erfasst worden
sind. Die Abwicklungsschnittstelle 210 dekodiert die Datenpakete,
die von der Abwicklungshardware 205 empfangen worden sind.
Diese Datenpakete werden analysiert, um zu bestimmen, falls ein
Unterprogramm bzw. Task oder ein Dienst bzw. Service aufgerufen
werden sollte oder falls keine Aktion bzw. Tätigkeit erforderlich ist. Falls
ein Task oder ein Dienst aufgerufen werden muss, erzeugt das Abwicklungsinterface 210 einen
Nachrichtensteuerblock (MCB) auf der Grundlage der Inhalte des Datenpakets und
ruft den gewünschten
Task oder Service auf. Nachrichtensteuerblöcke werden für sämtliche
Kommunikationen zwischen Tasks bzw. Unterprogrammen oder Diensten
verwendet und werden unten weiter beschrieben.
-
Die
kleinste Dateneinheit, auf deren Grundlage die Abwicklungsschnittstelle 210 arbeiten
kann, ist ein Datenpaket. Ein Datenpaket ist eine Gruppe von Daten.
In ihrem kleinsten Element ist ein digitales Datum entweder eine
1 oder eine 0. Jedes individuelle Stück eines Datums wird Bit genannt.
Eine Sammlung von 8 Bits wird als ein Byte bezeichnet und eine Sammlung
von 4 Bytes (32 Bits) wird als ein Quadlet bzw. eine Vierergruppe
bezeichnet. Ein asynchrones Paket muss zumindest vier Quadlets enthalten
oder 128 Bits lang sein. Die ersten 128 Bits werden als ein Paketkopfteil
bzw. eine Paketüberschrift
bezeichnet. Ein asynchrones Paket kann auch einen Datenblock enthalten.
Die Größe des Datenblocks
variiert, ist aber auf ein absolutes Maximum basierend auf der Geschwindigkeit,
bei welcher der 1394-Bus betrieben wird, beschränkt. Der 1394-Bus enthält Spezifikationen,
um bei 98,304 Mbps, 196,608 Mbps oder 393,216 Mbps zu arbeiten.
Diese Geschwindigkeiten werden häufig
gerundet auf 100, 200 bzw. 400 Mbps und werden mit S100, S200 und
S400 benannt. Wenn bei der Geschwindigkeit S100 gearbeitet wird,
ist die maximale Blockgröße 512 Bytes
(oder 128 Quadlets). Wenn bei S200 bzw. S400 gearbeitet wird, beträgt die maximale
Blockgröße 1024
Bytes bzw. 2048 Bytes. Wenn höhere
Busgeschwindigkeitsstandards bevorzugt werden, wird die maximale
Blockgröße vermutlich ebenfalls
anwachsen.
-
Das
Abwicklungs- bzw. Durchführungsinterface 210 empfängt Daten
von dem 1394-Bus und überträgt Daten
zu diesem Punkt. In Bezug auf die Abwicklungsschicht 10 nach 2 gibt es drei Hauptfunktionen,
die in Paketen zusammen mit dem Bus gesendet werden und durch die
Abwicklungsschnittstelle 210 verarbeitet werden. Dieses
sind Lese-, Schreib- und Sperr- bzw. Haltefunktionen. Für jede dieser
Funktionen gibt es zwei Hauptoperationen, die Anfrage bzw. den Aufruf
und die Antwort. Ein Aufruf fragt danach, dass ein Lesen, Schreiben
oder Sperren bzw. Halten stattfindet, und eine Antwort zeigt an,
dass das Lesen, Schreiben oder Sperren bzw. Halten versucht wurde
und enthält
ein Ergebnis.
-
Pakete,
die für
den Zielknoten bestimmt sind, auf dem die Abwicklungsschnittstelle 210 sitzt,
werden durch einen Initiator auf dem 1394-Bus angeordnet. Pakete,
die zu der bestimmten Knotenadresse geleitet werden, werden in einer
Empfangsnische in der Abwicklungshardware 205 empfangen
und eine Unterbrechung wird für
die Abwicklungsschnittstelle 210 erzeugt. Sobald die Abwicklungsschnittstelle 210 ihren
gegenwärtigen
Task vervollständigt
hat, wird eine Unterbrechungsserviceroutine bzw. wird ein Unterbrechungsserviceprogramm
eingegeben. Bei einer Ausführungsform
werden die sieben Arten von Paketen, die die Unterbrechung verursachen,
durch einen Abwicklungskode mit 4 Bit identifiziert, der in der
Kopfzeile des Pakets bzw. der Überschrift
des Pakets enthalten ist. Die Abwicklungskodes für diese Ausführungsform
der Erfindung werden wie folgt definiert:
-
-
Wie
oben beschrieben, beträgt
ein Quadlet 4 Bytes und ein Block ist entweder 512, 1024 oder 2048 Bytes,
abhängig
von der Geschwindigkeit, bei welcher der Bus betrieben wird. Ein
Schreibaufruf bzw. eine Schreibanfrage für einen Datenblock fordert
auf, dass ein Datenblock in eine spezifizierte Zielspeicheradresse bei
einem bestimmten Knoten geschrieben wird. Ein Schreibaufruf für ein Daten-Quadlet
ist identisch zu einem Schreibaufruf für einen Datenblock, wobei jedoch
die Menge der Daten, die in die spezifizierte Zieladresse geschrieben
werden, in einen Daten-Quadlet passen. Eine Leseanfrage bzw. ein
Leseaufruf für
einen Datenblock und ein Leseaufruf für ein Daten-Quadlet sind Aufrufe,
um Daten von der spezifizierten Zielspeicheradresse an dem spezifizierten
Knoten zurück
zu gewinnen.
-
Schreib-
und Leseaufrufe werden beantwortet, indem Antworten gesendet werden,
die sowohl Lese- als auch Schreibantworten sowohl für Daten-Quadlets
als auch für
Datenblocks enthalten. Eine Leseantwort für ein Daten-Quadlet wird in
Antwort zu einer Leseanfrage für
ein Daten-Quadlet gesendet, wobei die angeforderten Daten innerhalb
der Paketkopfzeile zurückgegeben
werden. Eine Leseantwort für
einen Datenblock ist gleich bzw. ähnlich zu einer Leseanfrage
für ein
Daten-Quadlet, wobei jedoch viel mehr Daten zurückgeleitet werden. Falls aus
irgendeinem Grund die Leseanfrage nicht durchgeführt werden könnte, werden
keine Daten zurückgesandt,
sondern ein Fehlerstatus kann zu dem aufrufenden bzw. anfragenden
Knoten gesandt werden. Schreibantworten werden in Antwort auf eine
Schreibanfrage für
entweder ein Daten-Quadlet oder einen Datenblock gesandt. Die Antworten
senden einen Antwortkode zurück,
der anzeigt, ob das Schreiben erfolgreich war und, falls nicht,
wird der bestimmte Grund weitergegeben, warum es fehlschlug. In
der Schreibantwort enthält
die Paketkopfzeile diesen Antwortkode.
-
Sperr-
bzw. Halteanfragen und Antworten arbeiten auf die gleiche Weise,
ausgenommen, dass eher nur eine Adresse als tatsächliche Daten gesendet werden
müssen.
-
Unter
Bezugnahme auf 3 werden
die Abwicklungsschnittstelle 210 und der Kern/Scheduler/Dispatcher
in sämtlichen
Ausführungsformen
der Erfindung zugegen sein. Zusätzlich
werden ein oder mehrere Tasks abhängig davon, welches Protokoll
für die
Transportsschicht 80 und die Anwendungsschicht 90,
die in 2 gezeigt sind,
verwendet wird, zugegen sein. Bei der in 3 gezeigten Ausführungsform sind sieben Tasks
gezeigt. Diese Tasks sind aufgebaut, um Funktionen durchzuführen, die
erforderlich sind, wenn das SBP-2-Protokoll für die Transportschicht 80 verwendet
wird. Die Erfindung ist folglich skalierbar, um irgendein verwendetes
Protokoll unterzubringen. Zum Beispiel zeigt die in 5 gezeigte Ausführungsform Tasks bzw. Unterprogramme,
die für
das FCP optimiert sind. Folglich können ein oder mehrere Tasks
verwendet werden, um irgendein gewünschtes Protokoll zu verwirklichen.
-
Zurückgehend
zu 3, ermöglichen
es die sieben gezeigten Tasks der Erfindung, mit dem SBP-2-Protokoll
zu arbeiten. Die Abwicklungsschnittstelle 210 ergreift
verschiedene Maßnahmen,
abhängig von
dem empfangenen Abwicklungskode. Wenn z.B. eine Schreibanfrage für ein Daten-Quadlet
oder einen Datenblock oder eine Leseanfrage für ein Daten-Quadlet oder einen
Datenblock durch die Abwicklungs- bzw. Durchführungsschnittstelle 210 empfangen
wird, führt
die Abwicklungsschnittstelle einen geordneten Satz von Operationen
durch, der das Aufrufen von einem oder mehreren Tasks bzw. Unterprogrammen
einbezieht.
-
Die
in 3 gezeigten Dienste
und Tasks kommunizieren miteinander über Nachrichtensteuerblöcke (MCB),
die in Warteschlangen angeordnet sind, die sich auf die aufgerufenen
Dienste und Tasks beziehen. Jeder in 3 gezeigte
Task hat zumindest eine jeweilige verbundene Warteschlange. Informationen,
die zwischen den Tasks übertragen
werden, sind nur über
MCBs. Jeder spezifische Task hat seine eigene Art von Steuerblock,
der Daten enthält,
die speziell von dem Task benötigt
werden, um zu arbeiten. In 3 sind
sieben Tasks gezeigt, ein Befehls-ORB-Ausführungstask 245, der
einen Befehlsnachrichtensteuerblock (CMC-Block) verwendet, einen
Hol-Managementtask 215, der einen Hol-Managementnachrichtensteuerblock (FMC-Block)
verwendet, einen ORB-Hol-Task 255, der einen ORB-Hol-Nachrichtensteuerblock
(OMC-Block) verwendet, einen frei laufenden Statustask 265,
der einen frei laufenden Statusnachrichtensteuerblock (UMC-Block)
verwendet, einen Management-Mittel-Task 225, der Management-Mittel-Nachrichtensteuerblock (MMC-Block) verwendet,
einen seriellen Busmanagementtask, der einen seriellen Busnachrichtensteuerblock (SMC-Block)
verwendet, und einen Anwendungstask 275, der einen Anwendungsnachrichtensteuerblock (AMC-Block)
verwendet. Die Dienste haben auch spezifisch für sie vorgesehene MCBs. Der
Dispatcher 220 verwendet Zuteiler-Nachrichtensteuerblöcke (DMC-Blöcke) und
die Abwicklungsschnittstelle 210 verwendet Abwicklungsnachrichtensteuerblöcke (TMC-Blöcke). Zusätzlich hat
jeder Task und jeder Dienst zumindest eine Warteschlange, in welcher
der jeweilige MCB angeordnet ist. Zum Beispiel hat der Management-Mittel-Task 225 eine
Management-Mittel-Task-Warteschlange, die aufgebaut ist, um MMC-Blöcke zu empfangen. Nichts
in der Architektur beschränkt
die Verknüpfung
bzw. Verbindung von Tasks und Warteschlangen. Zum Beispiel kann
ein Task mehrere Warteschlangen haben oder eine Warteschlange kann
mit mehreren Tasks verknüpft
sein. Jeder Grad der Verknüpfung
zwischen Tasks und Warteschlangen ist möglich.
-
Als
ein Beispiel von einer Art von MCB zeigt 4 einen Management-Mittelnachrichtensteuerblock (MMC-Block).
Da jeder MCB unterschiedlich ist, gibt es kein solches Ding wie
einen Standardnachrichtensteuerblock, wobei jedoch der MMC-Block
repräsentativ
für die
Arten von Daten ist, die in MCBs enthalten sind. Wenn ein Task den
Management-Mittel-Task 225 einplanen will, baut der aufrufende
Task einen MMC-Block auf und ordnet ihn in einer MMC-Warteschlange
an. Ein MMC-Block 300, der in 4 gezeigt ist, enthält 44 Daten-Bytes. Jedes Byte
ist entlang der linken Seite zur Bezugnahme nummeriert und ein Byte-Versatz,
der 0–15
nummeriert ist, zeigt die individuellen Bits an, die die zwei Bytes
von jeder Zeile ausmachen. Daten, die für den Task nützlich sind,
werden in dem MCB, wie in 4 beschrieben,
angeordnet. Zum Beispiel besetzt die Geschwindigkeit, mit der der
Bus arbeitet, Bits 8, 9 und 10 (die einen Versatz von 7, 8 und 9
haben) der ersten zwei Bytes des MMC-Blocks. Eine Adresse für einen
Managementbetriebsanfrageblock (ORB) ist 6 Bytes lang und enthält Bytes
4–9. Diese
Daten sind nötig
und werden durch den Management-Mittel-Task 225 während Operationen
verwendet.
-
Um
einen Task oder einen Dienst von einem anderen Task aufzurufen,
müssen
verschiedene Schritte eingehalten werden. Zunächst wird ein MCB für den bestimmten
Task oder Service bzw. Dienst, der aufzurufen ist, erzeugt. Dann
wird der MCB in der Warteschlange platziert, die mit dem bestimmten
Task oder Dienst verknüpft
ist, und ein Rückkehrkode
wird zurück
zu dem erzeugenden Task geschickt. Dann prüft der erzeugende Task den
Rückkehrkode.
Falls der Rückkehrkode
anzeigt, dass der MCB nicht an der Spitze der Warteschlange ist,
bedeutet dies, dass der Task momentan läuft und der erzeugende Task
unternimmt nichts mehr. Keine Aktion wird unternommen, weil ein
Task, der einmal gestartet ist, an sämtlichen der MCBs in seiner
Warteschlange arbeitet, bis die Warteschlange leer ist. Folglich
wird an dem MCB, der kürzlich
in der Warteschlange des Tasks angeordnet worden ist, eventuell
gearbeitet, wenn er an die Spitze der Warteschlange vorrückt. Falls jedoch
der Rückkehrkode
anzeigt, dass der MCB, der gerade in der Warteschlange des Tasks
platziert worden ist, bereits an der Spitze der Warteschlange ist,
das heißt,
es gibt keine anderen MCBs in der Warteschlange des Tasks, erläutert dies
dem erzeugenden Task, dass der aufgerufene Task nicht bereits läuft und
gestartet werden muss.
-
Um
einen Task zu starten, erzeugt der erzeugende Task einen Zuteiler-Nachrichtensteuerblock
(DMC) für
den Dispatcher 220. Der DMC-Block zeigt an, welcher Task
zu starten ist und welche Priorität dem DMC-Block zu geben ist.
Der Dispatcher 220 enthält
eine darauf bezogene Warteschlange, die kontinuierlich nach Einträgen bzw.
Eintritten geprüft
wird. Wenn Einträge
durch den Scheduler 220 empfangen werden, um die gewünschten
Tasks zu starten, werden sie in der Dispatcher- bzw. Zuteiler-Warteschlange
gemäß der Priorität angeordnet,
wobei die höchste
Priorität
am höchsten
in der Warteschlange angeordnet wird. Wie bei sämtlichen der Warteschlangen
wird der Dispatcher oder Tasks nicht in seiner Bearbeitung an seinem
gegenwärtigen
MCB unterbrochen, selbst wenn ein MCB, der eine höhere Priorität hat, in
seiner Warteschlange platziert wird. Statt dessen ordnet der Scheduler 220 DMC-Blöcke auf
der Grundlage der Priorität
des neuen Blocks und die gegenwärtig
in der DMC-Warteschlange anhängigen
Blöcke,
jedoch nicht dem DMC-Block, an dem gegenwärtig gearbeitet wird. Wenn
der DMC-Block die Spitze der DMC-Warteschlange
erreicht, schaut der Dispatcher 220 in dem DMC-Block nach,
um zu sehen, welcher Task oder Dienst aufzurufen ist, und informiert
dann den aufgerufenen Task, dass dort ein MCB in seiner eigenen
Warteschlange sitzt, der darauf wartet, betrieben zu werden. Dies
veranlasst den aufgerufenen Task, mit dem Betrieb zu beginnen. So
müssen,
damit ein Task einen anderen Task oder Dienst zum Betrieb einplanen
kann, entweder ein oder zwei MCBs erzeugt werden. Zuerst wird ein
MCB spezifisch für
den aufgerufenen Task erzeugt und in der mit ihm verknüpften Warteschlange
angeordnet. Ein Rückkehrkode
wird dann durch den erzeugenden Task geprüft. Falls der Rückkehrkode
anzeigt, dass der MCB in der Warteschlange angeordnet wurde, jedoch
nicht an dem Kopf der Warteschlange, tut der initiierende Task nichts
mehr, weil der aufgerufene Task bereits läuft und an dem MCB arbeiten
wird, wenn er in den Kopf der Warteschlange bewegt wird. Falls jedoch
der Rückkehrkode anzeigt,
dass der MCB an dem Kopf der Warteschlange für den aufgerufenen Task oder
Dienst angeordnet wurde, wird ein DMC-Block durch den erzeugenden
Task erzeugt, der anzeigt, welcher Task oder Dienst aufzurufen ist
und welche Priorität
dem DMC-Block gegeben wird. Der Scheduler 220 ordnet dann
den DMC-Block an dem passenden Ort in der DMC-Warteschlange an,
geordnet durch die Priorität.
Wenn der DMC-Block den Kopf der DMC-Warteschlange erreicht, wird
der aufgerufene Task oder Dienst alarmiert, dass ein MCB in seiner
Warteschlange ist und der Betrieb zu beginnen ist. Der aufgerufene
Task oder Dienst oder Service beginnt dann, gibt den DMC-Block zu
einem freien Nachrichtenblockpool bzw. -reservoir und arbeitet dann
an dem MCB an dem Kopf seiner eigenen Warteschlange.
-
Ein
gemeinsamer Pool bzw. ein gemeinsames Reservoir für Ressourcen
existiert für
sämtliche
MCBs. Der Nachrichtenblockpool bzw. das Nachrichtenblockreservoir
wird durch den Kern 220 verwaltet. Der Pool besteht aus
einem endlichen Speicherplatz, aus dem MCBs erzeugt werden können. Wenn
mehr MCBs erzeugt werden, nimmt die Menge an Speicherplatz, die
in dem Pool bzw. Reservoir zurückgeblieben
ist, ab. Wenn kein Speicherplatz in dem Reservoir freier Blöcke verbleibt,
können
keine weiteren MCBs mehr erzeugt werden, bis mehr Ressourcen zugeführt werden.
Ressourcen werden zugeführt,
indem MCBs zurück
zu dem Pool bzw. Reservoir geführt
werden, nachdem an ihnen gearbeitet worden ist und sie nicht mehr
benötigt
werden, das heißt,
wenn sie aus der Warteschlange entfernt sind. Wenn ein Task oder
Dienst bzw. Service beendet wird, der ein MCB verwendet, das zuvor
in seiner Warteschlange war, ruft er den Kern 220 auf und
fordert an, dass der MCB zurück
in dem Pool freier Blocks angeordnet wird. Er bewegt dann den nächsten freien
MCB zu dem Kopf seiner Warteschlange. Falls zusätzlich ein DMC-Block nötig ist,
um den Task oder Dienst bzw. Service zu starten, gibt der aufgerufene
Task oder Dienst den DMC-Block sofort an den Pool bzw. das Reservoir
freier Steuerblöcke
zurück,
bevor sein eigener MCB betrieben wird. Die Größe des Pools bzw. des Reservoirs
der freien Speicherblocks wird durch die Menge an verfügbarem Speicher
bestimmt und ist festgelegt, bevor irgendwelche MCBs zugeteilt werden.
-
Zusätzlich zu
der Verwaltung der Zuteilungswarteschlange und der Verwaltung des
Pools freier Nachrichtenblöcke
führt der
Kern/Scheduler/Dispatcher 220 auch andere Funktionen in 1394-Busabwicklungen durch.
Der Kern 220 initialisiert die Datenstrukturen, die zeitlichen
Steuerungen bzw. Taktgeber und Unterbrechungsvektoren. Sämtliche
Tasks, die gesteuert bzw. getaktet werden, erfordern einen Taktgeber
bzw. eine zeitliche Steuerung. Der Kern 220 stellt einen
derartigen Zeitsteuerungs- bzw. Taktgeberverwaltungsdienst zur Verfügung, wie
etwa Starten, Stoppen, neu Starten, Prüfen, Löschen und Zurverfügungstellung
einer Unterbrechung auf der Grundlage der Taktgeber bzw. der Zeitsteuerungen.
Die Taktgeber werden zugewiesen, wenn dies durch eine Task über einen
Aufruf zu den Kerndiensten gefordert wird. Jeder Taktgeber bzw.
jede Zeitsteuerung, die gegenwärtig
aktiv ist, wird in jedem Taktzyklus eingestellt. Bei einer Ausführungsform
wird ein Taktgeber bzw. eine Zeitsteuerung mit einer gegebenen Zahl
initialisiert bzw. in einen Anfangszustand versetzt, der bei jedem
Taktzyklus dekrementiert wird. Wenn der Zeitgeber bzw. Taktwert
Null erreicht, wird eine Mitteilung zu dem Task gesandt, der mit
dem Taktgeber bzw. dem Zeitgeber verknüpft ist.
-
Wie
oben ausgeführt,
hängen
der bestimmte Task, der ausgewählt
ist, um mit der Abwicklungsschnittstelle 210 und dem Kern/Scheduler/Dispatcher 220 zu
arbeiten, von der Transportschicht 80 ab, die in dem bestimmten
System verwendet wird. In der in 3 gezeigten
Ausführungsform
sind die Tasks ausgewählt, um
mit dem SBP-2-Protokoll für
die Transportschicht zu arbeiten. Wenn andere Transportschichtprotokolle
verwendet werden, können
andere Tasks zugegen sein oder einige der in 3 gezeigten Tasks können nicht zugegeben sein.
Auf diese Weise ist die Kommunikationssteuerung 200 äußerst flexibel
und skalierbar, wobei so viel individuelle Aufmachung wie gewünscht ermöglicht wird.
-
Wie
in der Ausführungsform,
die in 3 zu sehen ist,
gezeigt ist, arbeitet der Befehls-ORB-Ausführungstask 245 auf
der Grundlage von Daten und Statusabwicklungen zwischen dem Anwendungstask 275 und einem
Initiator, der typischerweise an einem anderen Knoten platziert
ist. Im Betrieb wird der Initiator Daten zu dem Anwendungstask 275 senden
oder davon empfangen. Der Befehls-ORB-Ausführungstask 245 ist
der prinzipielle Durchgang für
die Daten und Statusnachrichten zwischen ihnen. Der Poolverwaltungstask 215 stellt
sicher, dass ein Betrieb, der an einem bestimmten Knoten empfangen
worden ist, für
diesen Knoten bestimmt war. Falls der Betrieb an dem korrekten Knoten
ist, aktualisiert der Hol-Verwaltungstask 215 eine
Variable, die verwendet wird, um einen gegenwärtigen Zustand eines Mittels
anzuzeigen. Der ORB-Hol-Task 255 empfängt mehrere ORBs, die Befehle
von einem Initiator enthalten, und lässt sie zu dem Anwendungstask 275,
um ausgeführt
zu werden. Der Freilaufstatustask 265 sendet eine Statusnachricht
an den Initiator, wenn dies von einem der anderen Tasks gefordert
wird. Der Management- bzw. Verwaltungs-Mittel-Task 225 führt verwaltungsartige
Funktionen durch, die durch den Initiator angefordert werden, einschließlich Zugriffsaufforderungen,
Einloggen, Einstellen von Passworten usw. Der serielle Busmanagement-
bzw. -verwaltungstask 235 funktioniert wie eine Schnittstelle
zwischen dem seriellen Busmanagement bzw. -verwaltung 40 und
dem Anwendungstask 275 für die gleichen Knoten. Schließlich arbeitet
der Anwendungstask 275, um obere Protokollbefehle auszuführen, die
in der Anwendungsschicht 90 nach 1 gefunden worden sind. Der Anwendungstask 275 ist
der letzte Ursprung oder die letzte Bestimmung des Hauptteils von
Daten, die entlang dem 1394-Bus übertragen
werden.
-
Wendet
man sich nun den spezifischen Umständen der Tasks, die in 3 gezeigt sind, zu, reagiert der
Management-Mittel-Task bzw. Verwaltungs-Mittel-Task 225 auf
Arten von Verwaltungsanfragen bzw. -aufrufen von einem Initiator.
In Reaktion auf eine Management-Mittel-CSR-Einschreibung,
die durch den Initiatorknoten gesendet ist, holt der Management-Mittel-Task 225 ein
Management-OBR von dem Initiator und führt dann die ORB-Funktion aus.
Beispiele von ORB-Funktionen enthalten das Login, das Einstellen
bzw. Setzen eines Passworts, das wieder Anschließen und einen Beendigungstask.
Falls der Management-Mittel-Task 225 zurück mit dem
Initiator kommunizieren muss, benutzt er den Übertragungsabschnitt der Abwicklungsschnittstelle 210.
-
Die
Abwicklungsschnittstelle 210 bereitet auch zusätzlich zum
Empfangen von Paketen, die für
den lokalen Knoten, wie oben beschrieben, bestimmt sind, Pakete
vor, die für
andere Knoten bestimmt sind. Sobald es vorbereitet ist, überträgt die Abwicklungsschnittstelle 210 die
Pakete zu der Verbindungsschicht 20, wo sie synchronisiert
werden, und zu der physikalischen Schicht 10 zur Umwandlung
in elektrische Signale gesendet werden, um auf dem Bus platziert
zu werden. Abhängig
von der Art und der Menge von Daten, die von der Abwicklungsschnittstelle 210 zu
senden sind, können
eine Übertragungsnische,
eine Nutzlastdatenübertragungsnische
und/oder ein Direktspeicheradresskanal (DMA-Kanal) verwendet werden.
Falls die Menge an Daten, die von der Abwicklungsschnittstelle 210 zu
senden sind, groß ist, kann
sie in mehrere Pakete aufgebrochen werden, die an dem Bus zu platzieren
sind. Jedes Paket wird vorbereitet und dann den Bus entlang gesandt.
-
Tasks,
die Daten zu einem anderen Knoten als dem senden wollen, an dem
sie sind, senden die Daten über
einen Übertragungsabschnitt
der Abwicklungsschnittstelle 210. Die Abwicklungsschnittstelle 210 enthält zumindest
zwei Warteschlangen, um TMC-Blöcke
zu halten, einen für
zeitkritische Abwicklungen und einen für zeitlich unkritische Abwicklungen.
Daten, die entlang dem Bus zu senden sind, werden in TMC-Blöcke verpackt und
in der zeitkritischen oder zeitlich nicht kritischen Warteschlange,
wie gewünscht,
angeordnet. Die nicht zeitkritische TMC-Warteschlange wird für Datenblockübertragungsanfragen
verwendet, während
die zeitkritische TMC-Warteschlange für Abwicklungen verwendet wird,
die in Subtätigkeiten
unterteilt werden müssen. Es
kann mehrere Abwicklungen erfordern, um eine nicht zeitkritische
TMC-Blockanfrage zu vervollständigen. Sobald
die Abwicklungen fertig sind, sendet die Abwicklungsschnittstelle 210 eine
Mitteilung zu dem Task, der die Daten sendet, dass der Task fertig
ist.
-
Jede
Abwicklung, die durch die Abwicklungsschnittstelle 210 eingeleitet
worden ist, hat einen Softwaretaktgeber bzw. -zeitgeber, der damit
verknüpft
ist. Diese Softwarezeitgeberdienste werden durch den Kern 220,
wie zuvor erörtert,
zur Verfügung
gestellt. Ein Wiederversuchszählfeld
des TMC-Blocks wird inkrementiert, falls die Datenübertragung
nicht erfolgreich ist. Solange die Wiederversuchszählung unterhalb
der programmierbaren maximalen Zahl von Wiederversuchen ist, wird
die Abwicklungsschnittstelle 210 versuchen, Daten wieder
zu senden. Falls die maximale Wiederversuchszählung bzw. -zahl überschritten
worden ist, wird eine Statusnachricht zurück zu dem aufrufenden Task
gesandt, um ihn von dem Fehlschlag zu informieren. Bei der Vervollständigung
einer Abwicklung, das heißt
die Abwicklungsschnittstelle 210 empfing eine Bestätigung von
dem Knoten, zu dem die Daten gesendet werden, plant die Abwicklungsschnittstelle 210 einen
Abwicklungsvervollständigungsstatus
oder ein anderes Antwortsignal ein, um es dem aufrufenden Task zurück zu senden.
Die Daten werden in einem DMC-Block platziert und durch den Dispatcher 220 zu
dem aufrufenden Task gesandt.
-
Zurückkehrend
zu dem Management- bzw. Verwaltungs-Mittel-Task 225, wird
der Task, nachdem der Task bzw. das Unterprogramm die Daten zu dem
Initiator sendet, dann ausgesetzt, wobei eine Mitteilung von der
Abwicklungsschnittstelle 210 anhängig ist. Wenn die Abwicklungsschnittstelle 210 die
Datenabwicklung mit dem Initiator vervollständigt, weckt die Abwicklungsschnittstelle
den Management-Mittel-Task 225 auf, indem ein Systemaufruf
bzw. -anruf zu dem Scheduler 220 durchgeführt wird.
Der Management-Mittel-Task 225 setzt dann seine Ausführung des
Management- bzw. Verwaltungs-ORB für diesen Task fort. Sobald
fertig, verwirft der Management-Mittel-Task 225 den MMC-Block
von dem Kopf seiner Warteschlange, ruft den Kern auf, um den MMC-Block
zu dem Pool freien Speicherblockes zurückzugeben, und beginnt den
Betrieb an dem nächsten
MMC-Block in seiner Warteschlange, falls vorhanden. Falls der Management-ORB
einen Login-Befehl enthält,
erzeugt der Management-Mittel-Task 225 einen OMC-Block
und eine Login-Deskriptorliste. Der OMC-Block und die Login-Deskriptorliste
werden entfernt, nachdem der Initiator ausgeloggt hat.
-
Der
Anwendungstask 275 stellt die Anwendung dar, die an einem
der Knoten an dem 1394-Bus
arbeiten würde,
z.B. Hochgeschwindigkeitsdrucker, Hochgeschwindigkeitsspeicher oder
audiovisuelle Anwendungen. Die Anwendungen kommunizieren über ihre
ursprünglichen
Protokolle, wobei spezifische Anwendungsprotokolle verwendet werden,
wie etwa reduzierte Blockbefehle (RBC) für Festplattenlaufwerke, Druckerarbeitsgruppen
(PWG) für
Drucker oder Internetprotokolle (IP) für Netzwerke. Verschiedene Anwendungen
können
zu einer Zeit an einem gegebenen Knoten arbeiten. Jede Anwendung
dekodiert Befehle, validiert Befehle und führt Befehle aus, die ihr übergeben
wurden. Jede getrennte Anwendung hat eine getrennte Warteschlange,
die durch eine Zahl auf der Grundlage, wie viele Anwendungen am
laufen sind, identifiziert wird.
-
Der
ORB-Hol-Task 255 funktioniert, um mehrere Befehls-ORBs
von einem Initiator zu einer Zeit zurück zu gewinnen, wobei die verkapselten
Befehle zu dem Anwendungstask 275 zur Ausführung durchgegeben werden.
Für jedes
neue Holen wird ein Systemaufruf durchgeführt, um die AMC-Blockadresse
zu bestimmen, die das Holen anfordert. Diese Blockadresse wird dann
in dem OMC-Block entsprechend zu dem veranlassenden Task gespeichert.
Die ORB-Adresse
wird von dem OMC-Block zurückgewonnen.
Dann wird das Abwicklungsinterface 210 vorgesehen, um die
Befehls-ORBs zu lesen und zurückzugeben.
Falls die Daten ohne Fehler zurück
kommen, wird ein AMC-Block erzeugt und in der AMC-Warteschlange
platziert, wobei die zurückgewonnenen
Daten zu dem passenden Anwendungstask gesendet werden. Abhängig davon,
wie viele Initiatoren zugegen sind, kann der ORB-Hol-Task 255 die
Gesamtzahl von ORBs in jedem Holen beschränken, um eine faire Schlichtung
zur Verfügung
zu stellen.
-
Der
Befehls-ORB-Ausführungstask 245 stellt
Datenübertragungsanfragen
und Statusüberlieferungen im
Namen des Anwendungstasks 275 zur Verfügung. Der Befehls-ORB-Ausführungstask 245 gewinnt
den Befehl, den er auszuführen
hat, von dem Befehlsnachrichtensteuerblock (CMC) wieder, der in
einer CMC-Warteschlange durch die Abwicklungsschnittstelle 210 platziert
wurde. Der Befehls-ORB-Ausführungstask 245 sieht die
Abwicklungsschnittstelle 210 vor, um die Daten oder den
Status, wie gerichtet, zu senden oder wieder zu gewinnen. Sobald
fertig, weckt die Abwicklungsschnittstelle 210 den Befehls-ORB-Ausführungstask 245,
der dann den bestimmten Anwendungstask 275, für welchen
er arbeitet, den Status der ORB-Ausführung mitteilt oder die angeforderten
Daten zur Verfügung
stellt.
-
Der
Hol-Managementtask 215 verarbeitet zwei spezielle Schreibanfragen.
In beiden Fällen
aktualisiert der Hol-Managementtask 215 ein Feld in einem
OMC-Block.
-
Schließlich arbeitet
der frei laufende Statustask 265, um ein Statussignal zu
den Initiatoren an anderen Knoten zu senden, selbst wenn dies nicht
gefordert wird. Dieser Task würde
arbeiten, um z.B. die Initiatoren mitzuteilen, die vor der Rücksetzung
des Knotens eingeloggt waren.
-
Ein
Beispiel der 1394-Busarchitektur im Betrieb stellt ein weiteres
Verständnis
der Zusammenwirkung der Dienste und der Tasks zur Verfügung. Ein
Beispiel, das mehrere bzw. verschiedene der Tasks verwendet, ist
eine Tätigkeit
zum Einloggen in Host bzw. Datenanbieter über einen Management-Login-ORB.
Dies würde z.B.
auftreten, wenn ein Drucker an den 1394-Bus angeschlossen wird.
Unter Bezugnahme auf 3 beginnt das
Login mit einem Initiator an einem nicht lokalen Knoten. Der Initiator
sendet oder eines oder mehrere Datenpakete zu der Abwicklungsschnittstelle 210 an
dem lokalen Knoten, wo er durch die Hardware empfangende Nische
empfangen und dekodiert wird. Die Abwicklungsschnittstelle 210 dekodiert
einen Abwicklungskode von dem Paket und dekodiert es, um zu sehen,
dass der initiierende Task Daten anfordert, die bei einer Zieladresse
einzuschreiben sind, die auf dem lokalen Knoten gefunden worden
ist (Einloggen in den Host bzw. Datenanbieter). Dieser bestimmte
Betrieb ist eine Schreib-Management-Mittel-Operation und verwendet
zunächst
den Management-Mittel-Task 225.
-
Die
Abwicklungsschnittstelle 210 fragt einen freien MMC-Block
von dem Kern 220 an, initialisiert den MMC-Block mit Daten,
die aus dem empfangenen Datenpaket gelesen worden sind, und befördert sie
in die Arbeitswarteschlange des Management-Mittel-Tasks 225.
Falls ein Rückkehrkode,
der zu der Abwicklungsschnittstelle 210 zurückgesandt
wird, zeigt, dass dieser MMC-Block gegenwärtig an dem Kopf der Warteschlange
ist, ist der Management-Mittel-Task 225 gegenwärtig nicht
in Betrieb und muss gestartet werden. Die Abwicklungsschnittstelle 210 baut
einen DMC-Block auf und ruft den Dispatcher 220 auf, um
den Management-Mittel-Task 225 zu starten. Der Dispatcher 220 teilt
dem Management-Mittel-Task 225 dann mit, dass er einen
Eingang in seiner Warteschlange hat. Der Management-Mittel-Task 225 dekodiert
den MMC-Block in seiner Warteschlange und die darin enthaltene Operation.
Die Operation bzw. der Betrieb, der dekodiert wurde, teilt dem Management-Mittel-Task 225 mit,
dass er den Management-ORB von dem Host bzw. dem Datenanbieter lesen
muss. Dies enthält
die Übermittlung
von der Abwicklungsschnittstelle 210. Ein TMC-Block wird
erzeugt, mit der Management-ORB-Adresse oder anderen Parametern
initialisiert und in einer TMC-Warteschlangen angestellt. Der Management-Mittel-Task 225 aktualisiert
einen Taskzustand in dem MMC-Block, wobei vorgetragen wird, dass
er auf ein Management-ORB-Holen
wartet. Falls ein Rückkehrkode
anzeigt, dass der TMC-Block an dem Kopf der Warteschlange ist, muss
die Abwicklungsschnittstelle 210 über den Dispatcher 220 gestartet
werden. Nachdem sie die Ausführung
beginnt, dekodiert die Abwicklungsschnittstelle 210 den
TMC-Block, um zu erkennen, dass sie eine Übertragung vorsehen muss. Sie
wird vorgesehen und ausgeführt.
-
Die
Abwicklungsschnittstelle 210 empfängt den Management-ORB von
dem Initiator. Die Abwicklungsschnittstelle 210 ruft dann
den Management-Mittel-Task 225 mit dem Login-Befehl auf. Der Management-Mittel-Task 225 versucht,
für den
Initiator einzuloggen. Falls sämtliche
Login-Kriterien erfüllt
sind, fordert der Management-Mittel-Task 225 einen neuen OMC-Block
an. Der OMC-Block wird dann mit passenden Daten initialisiert und
eine Login-Antwort
wird aufgebaut. Die Login-Antwort wird mit der Abwicklungsschnittstelle 210 vorgesehen,
indem ein TMC-Block in einer der TMC-Warteschlangen angestellt wird,
wobei dem Initiator mitgeteilt wird, dass das Einloggen erfolgreich
war. Später
wird ein Statusblock zu dem Initiator zurückgesandt, indem ein TMC-Block
in einer der TMC-Warteschlangen angestellt wird. Nachdem der Statusblock
gesandt ist, wird der ursprüngliche
MMC-Block abgewiesen, zu dem Pool freier Speicherblöcke zurückgebracht
und der Management-Mittel-Task 225 arbeitet
an dem nächsthöchsten MMC-Block
in seiner Warteschlange. Wie ein Fachmann im Stand der Technik erkennen
wird, können
beliebige Funktionen für
ein beliebiges Protokoll, das als die Transportschicht 80 verwendet
wird, in Tasks ausgebildet werden, die die Abwicklungsschnittstelle 210 aufrufen
kann.
-
Als
ein weiteres Beispiel zeigt 5 eine
Ausführungsform
nach der Erfindung, die ein Funktionssteuerprotokoll als ihre Transportschicht 80 verwendet.
Man bemerke, dass die Abwicklungshardware 205, die Abwicklungsschnittstelle 210 und
der Kern 220 die gleiche Funktion wie die in 3 gezeigte Ausführungsform haben.
Ferner sind der serielle Busmanagementtask 235 und der
Anwendungstask 275 auch ähnlich bzw. gleich zu der in 3 gezeigten Ausführungsform.
Jedoch werden einige Tasks, wie etwa der Anwendungs-/FCP-Befehlsausführungstask 295 spezifisch
für das
verwendete Protokoll, in diesem Fall FCP, erzeugt. Der CSR-Managementtask 285 ist
ein alternatives Verfahren, um die CSR-Dienste zu enthalten, die
erforderlich sind, um einen 1394-Bus zu verwirklichen. In der in 3 gezeigten Ausführungsform
werden diese Dienste durch den seriellen Busmanagementtask 235 gehandhabt.
-
Einige
der möglichen
Anwendungen und Protokolle zur Verwendung mit einem 1394-Bus sind
in 6 gezeigt. Der 1394-Bus,
der die Kommunikationssteuerung 200, wie hierin beschrieben,
verwendet, ermöglicht es,
nahezu beliebige Arten von peripheren Einrichtungen aneinander anzuschließen. In
der 6 wird der 1394-Bus
an dem unteren Teil bzw. Boden der Figur dargestellt und zeigt,
dass er sowohl asynchrone als auch isochrone Fähigkeiten enthält. Die
nächste
Schicht über
dem 1394-Bus zeigt Beispiele der Transportschicht 80, die
in 2 gezeigt ist. Gezeigt
sind ein SBP-2, FCP und SBP-2 gemeinsames isochrones Paketformat. Die
nächste
Schicht oberhalb der Transportschicht zeigt Beispiele der Anwendungs schicht 90,
wie in 2 gezeigt. Gezeigt
sind Protokolle eines oberen Niveaus, wie etwa MMC-2, das für Festplattenlaufwerke
und digitale Videoplattenlaufwerke verwendet wird, PWG, ein Protokoll
zur Verwendung mit Druckern, RBC, ein anderes Protokoll, das häufig mit
Festplattenlaufwerken verwendet wird, und ein AV-Abwicklungssatz,
der für
Unterhaltungselektronikeinrichtungen verwendet wird. Als Nächstes werden
oberhalb der Anwendungsschicht 90 die Einrichtungen gezeigt,
die die Protokolle verwenden, die unterhalb von diesen aufgelistet
sind, einschließlich
Druckern, Festplattenlaufwerken, DVD-Spielern usw. Natürlich können andere
periphere Einrichtungen als die hier aufgeführten peripheren Einrichtungen
zu ihrem Vorteil den 1394-Bus verwenden, mit verschiedenen Anwendungen
oder Transportprotokollen. Wie oben bemerkt, dehnt dies die Kompatibilität des 1394-Busses mit
anderen Bussen aus.
-
Aus
dem Voranstehenden ist es zu erkennen, dass, obwohl spezifische
Ausführungsformen
der Erfindung hierin zu Zwecken der Darstellung beschrieben worden
sind, verschiedene Modifikationen vorgenommen werden können, ohne
den Bereich der Erfindung zu verlassen. Demgemäß ist die Erfindung, ausgenommen durch
die beigefügten
Ansprüche,
nicht beschränkt.
-
In
dem obigen Verfahren kann mehr als ein Dienst oder Task zur gleichen
Zeit an dem gleichen Knoten betrieben werden und die Services bzw.
Dienste und Tasks arbeiten unabhängig
voneinander. Ein Satz von Tasks bzw. Unterprogrammen kann so ausgewählt werden,
dass irgendwelche Anforderungen eines Transportschichtprotokolls
erfüllt
werden können.
Die Warteschlange, die formatierte Daten akzeptiert, ist mit mehr als
einem der mehreren Dienste oder Tasks verknüpft.