DE3856389T2

DE3856389T2 - Eingabe-Ausgabe-Steuerung, die Eingabe/Ausgabe-Fenster mit Adressbereichen aufweist und die Fähigkeit zum vorherigen Lesen und späteren Schreiben besitzt

Info

Publication number: DE3856389T2
Application number: DE3856389T
Authority: DE
Inventors: William Michael Johnson
Original assignee: Advanced Micro Devices Inc
Current assignee: Advanced Micro Devices Inc
Priority date: 1988-10-05
Filing date: 1988-10-05
Publication date: 2000-09-07
Anticipated expiration: 2008-10-06
Also published as: EP0362425A1; DE3856389D1; ATE188788T1; EP0362425B1

Description

HINTERGRUND DER ERFINDUNG

1. Gebiet der Erfindung

Die Erfindung bezieht sich im allgemeinen auf Verfahren und Vorrichtungen, die zum Übertragen von Daten zu und von einem ersten Bus, dem ein erster Satz von Hochleistungsvorrichtungen, einschließlich einem Zentralprozessor ("CPU") angefügt ist, und einem zweiten Bus verwendet werden, dem ein zweiter Satz von Vorrichtungen relativ niedrigerer Leistung angefügt ist, auf eine Weise, die die Leistungsfähigkeit der CPUs nicht einschränkt. Die Erfindung bezieht sich insbesondere auf einen neuartigen Eingabe/Ausgabe-Controller ("IOC") oder eine Gruppe von IOCs, die zum Durchführen der zuvor genannten Datentransferfunktion zwischen einem Hochleistungskanal, von dem nachfolgend als dem "Ortsbus" gesprochen wird, dem eine CPU, der ein Teil eines Reduzierter-Befehlssatz- Computer-(RISC)-Systems bildet, angefügt ist, und einem oder mehreren peripheren Bussen, typischerweise niedrigerer Leistungsfähigkeit, von denen im folgenden als "Fern-Bus" gesprochen wird, geeignet sind. Der neuartige IOC kann als Teil eines Datentransfer-Controllers ("DTC") mit weiteren Komponenten, wie z. B. einem Direkt-Speicher-Zugriff-Mittel, verwendet werden, oder kann unabhängig zum Transferieren von Daten zwischen nicht angepaßten Bussen in z. B. RISC- und Non-RISC-Systemen, Datenübertragungssystemen und dergleichen verwendet werden.

2. Beschreibung des Standes der Technik

Verfahren und Vorrichtungen zum Erzielen einer Hochleistungs-System- Schnittstelle zwischen einem RISC-Prozessor und einem Satz von Vorrichtungen, einschließlich von Speichermitteln intern im RISC-System, werden in der Anmeldung EP-A-0 283 115, der Advanced Micro Devices, Inc. übertragen. Die in der Anmeldung EP-A-0 283 115 offenbarte System-Schnittstelle beinhaltet zwei 32 Bit breite Busse, auf die als der "Adress-Bus" und "Daten-Bus" verwiesen wird, die gemeinsam den Ortsbus darstellen.
Um es einem RISC-System zu ermöglichen, eine große Auswahl von kommerziell verfügbaren peripheren Vorrichtungen zu benutzen und Zugriff darauf zu haben, die typischerweise bei niedrigeren Geschwindigkeiten als ein RISC-Prozessor arbeiten, muß der Ortsbus auf eine gewisse Weise mit einem Fern-Bus gekoppelt werden, mit dem ein oder mehrere der peripheren Vorrichtungen verbunden sind. Der Fern-Bus könnte auch ein vollständiges I/O-Untersystem mit seinem eigenen Prozessor sein.
Eine Zwischenverbindungseinheit für unabhängig betriebsfähige Datenverarbeitungssysteme ist in dem Patent US-A-3 940 743 offenbart. Wenn ein einzelnes Datenverarbeitungssystem die Zwischenverbindungseinheit adressiert, reagiert die Einheit wie eine periphere Vorrichtung. Sie konvertiert die Adresse in eine physische Speicheradresse für das andere Datenverarbeitungssystem. Sie unterbricht auch das andere System, um einen Datentransfer entweder zu oder von dem anderen System zu bewirken. Das erste System ist durch einen Bereich von Speicheradressen gekennzeichnet, die keine physikalischen Orte in den Speichern oder peripheren Einheiten in dem System haben. Die Zwischenverbindungseinheit spricht an auf Adressen in dem unbenutzten Bereich. Sie konvertiert eine Adresse in diesem Bereich in eine Adresse in einem zweiten System, die einem physikalischen Speicherort entspricht. Die Zwischenverbindungseinheit empfängt Daten von dem ersten System auf dieselbe Weise wie eine periphere Vorrichtung. Sie tauscht dann Transfer-Steuersignale mit dem zweiten System aus, um als eine unterbrechende periphere Einheit für dieses System zu wirken. Auf ähnliche Weise kann die Zwischenverbindungseinheit auch Daten von dem zweiten System unter Steuerung des ersten übertragen. Zusätzlich kann die Zwischenverbindungs einheit Daten aus dem ersten System herausholen oder Daten in dasselbe unter Steuerung des zweiten Systems liefern.
Derzeit sind keine Vorrichtungen oder Verfahren bekannt, die Datentransfers zwischen Bussen mit unterschiedlichen Leistungsmerkmalen (wie der zuvor genannte Ortsbus oder Fern-Bus) zwischenverbinden und gestatten, während sie zur gleichen Zeit wünschenswertersweise keine Beeinflussung der Leistung der Vorrichtungen, die den Bussen angefügt sind, haben. Beim Ansprechen dieses Problems wäre es ein besonders wünschenswertes Merkmal, die Leistung irgendeines Hochgeschwindigkeitsprozessors, z. B. eines RISC-Prozessors, der dem Ortsbus angefügt ist, von der vergleichsweise niedrigeren Leistungsfähigkeit von Periphergeräten und/oder irgendwelcher I/O-Subsyteme, verbunden mit dem Fern- Bus, zu isolieren. Idealerweise muß die Bandbreite und Latenz von Zugriffen auf den Ortsbus von der Bandbreite und Latenz von Zugriffen auf den Fern-Bus mit Konkurrenz zwischen Zugriffen auf beide Busse entkoppelt werden.
Ein weiteres zu lösendes Problem ist es, Verfahren und Vorrichtungen vorzusehen, die I/O-Port- und Direktspeicher-Zugriff-("DMA")-Operationen zulassen, um mit an den Ortsbus angefügten Vorrichtungen zu überlappen (z. B. parallel mit diesen zu arbeiten). Ein derartiges Parallelitäts-Merkmal würde die Leistungsfähigkeit des Gesamtsystems, von dem der DTC einen Teil bildet, erhöhen und würde insbesondere in einem RISC-System, den RISC-Prozessor davon befreien, eine I/O-Beendigung abwarten zu müssen.
I/O-Controller-Funktionen und DMA-Funktionen an sich und von denselben sind im Stand der Technik gut bekannt. Jedoch wird keine Kombination dieser Funktionen durch irgendwelche bekannte Verfahren oder Vorrichtungen durchgeführt, die (1) einen Ortsbus und einen Fern-Bus des zuvor beschriebenen Typs für ein Hochleistung-RISC-System zwischenverbinden und Puffern; (2) das zuvor genannte Problem des Zwischenverbindens von Bussen mit unterschiedlichen Lei stungsfähigkeitsmerkmalen lösen und (3) die Parallelität, auf die zuvor Bezug genommen wurde, bereitstellen.
Darüber hinaus ist kein DMA-Kanal an sich bekannt, der eine Bus-zu-Bus- Schnittstelle des hier zuvor beschriebenen Typs unterstützt, z. B. ein DMA-Kanal, der sich unterscheidenden Bus-Charakteristika und einer Parallelität gegenüber einem DMA-Kanal Rechnung trägt, der nur ein Direkt-Adresssequenzieren durchführt.
Schließlich, obwohl Systeme wie der IBM 370 (ein großer Hauptrechner) bekannt sind, ist kein Stand der Technik auf dem Gebiet der Mikroprozessoren bekannt, die ein Kanal-Controller-Netzwerk beinhalten mit Direkt-Speicher- Zugriffsmerkmalen, insbesondere in Kombination mit einem RISC- Verarbeitungssystem, das sowohl DMA- als auch I/O-Controller-Funktionen auf einem einzigen Chip liefert. Derartige Merkmale wären ein wünschenswerter Zusatz zu RISC-Verarbeitungssystemen, die ihrerseits momentan auf der Chip- Ebene hergestellt werden.
Es ist eine Aufgabe der Erfindung, Verfahren und Vorrichtungen zu schaffen, die Datentransfers zwischen Bussen mit unterschiedlichen Leistungscharakeristiken (wie der zuvor genannte Ortsbus und der Fern-Bus) miteinander verbinden, während sie gleichzeitig keine merkliche Beeinflussung der Leistungsfähigkeit der Vorrichtungen haben, die den Bussen angefügt sind.
Es ist eine weitere Aufgabe der Erfindung, Verfahren und Vorrichtungen zu schaffen, die es einem RISC-System ermöglichen, eine große Auswahl von kommerziell verfügbaren peripheren Vorrichtungen zu benutzen und darauf Zugriff zu haben, die typischerweise bei niedrigeren Geschwindigkeiten als ein RISC- Prozessor arbeiten.
Es ist noch eine weitere Aufgabe der Erfindung, die Leistungsfähigkeit irgendeines Hochgeschwindkeitsprozessors, z. B. eines RISC-Prozessors, der einem Ortsbus angefügt ist, von der vergleichsweise niedrigeren Leistungsfähigkeit von Periphergeräten und/oder von irgendeinem I/O-Subsystem zu isolieren, das mit einem Fern-Bus auf eine Weise verbunden ist, in welcher die Bandbreite und Latenz von Zugriffen auf den Ortsbus von der Bandbreite und Latenz von Zugriffen auf den Fern-Bus entkoppelt werden kann, mit Konkurrenz zwischen Zugriffen auf beide Busse.
Darüber hinaus ist es eine weitere Aufgabe der Erfindung, eine Vorrichtung und ein Verfahren zu schaffen, die es ermöglichen, daß Operationen sich mit Vorrichtungen, die dem Ortsbus zugeordnet sind, überlappen (z. B. mit diesen parallel arbeiten), um die Gesamtsystem-Leistungsfähigkeit zu erhöhen.
Die obigen und weitere Aufgaben des I/O-Controllers, welcher Adress- abgebildete I/O-Fenster und Lese-Davor/Schreibe-Dahinter-Fähigkeiten inkorporiert, werden durch eine Vorrichtung gemäß den Merkmalen von Anspruch 1 und durch ein Verfahren gemäß den Schritten von Anspruch 19 erreicht. Weitere vorteilhafte Ausführungsformen können den jeweiligen abhängigen Ansprüchen entnommen werden.

ZUSAMMENFASSUNG DER ERFINDUNG

Gemäß der Erfindung sind Verfahren und Vorrichtungen zum Transferieren von Daten zu und von einem ersten Bus, dem ein erster Satz von Hochleistungsvorrichtungen, welche zumindest eine Zentraleinheit ("CPU") beinhalten, angefügt ist, sowie einem zweiten Bus offenbart, dem ein zweiter Satz von Vorrichtungen von relativ niedrigerer Leistung angefügt ist. Insbesondere verrichtet die Erfindung die zuvor genannte Transferfunktion auf eine Weise, die eine Kommunikation zwischen dem ersten und zweiten Satz von Vorrichtungen erleichtert, während sie die Leistung des ersten Satzes von Vorrichtungen von der vergleichsweise niedrigeren Leistung des zweiten Satzes von Vorrichtungen isoliert.
Gemäß der bevorzugten Ausführungsform ist ein Ein-/Ausgabe-Controller, d. h. ein ("IOC") offenbart, welcher einen Satz Adress-abgebildete I/O-Ports beinhaltet. I/O-Ports können benutzt werden, um Daten zwischen dem Hochleistungskanal (im nachfolgenden als "Ortsbus" bezeichnet, der mit der CPU in einem Reduzierter-Befehlssatz-Computer-(RISC)-System gekoppelt ist) und einem typischen peripheren Bus niedrigerer Leistung (im folgenden als "Fern-Bus" bezeichnet) zu übertragen. Die resultierende IOC-Schnittstelle zwischen dem Ortsbus und einem Fern-Bus läßt es zu, dem RISC einen breiten Leistungsbereich von Standard- Peripheren-Vorrichtungen anzufügen, auf eine Weise, welche die Systemleistung nicht beschränkt.
Die bevorzugte Ausführungsform der Erfindung erfüllt die zuvor genannten Aufgaben im Kontext einer RISC-Verarbeitungsumgebung, wobei sowohl der RISC- Prozessor als auch der IOC auf der Chip-Ebene hergestellt sind.
Die Erfindung legt besonderes Gewicht auf eine Reduzierung der Menge an Hardware, die erforderlich ist, um Periphergeräte auf dem Fern-Bus mit dem Ortsbus zu verbinden. Zusätzliche Merkmale der Erfindung beinhalten die Flexibilität, eine Bus-Größenanpassung, ein Datenpacken und -entpacken und Umwandlungen zwischen Byte- und Halbwort-Daten, in Worte gepackt und umgekehrt, d. h. Pack- und "Kanalisier"-Operationen, durchzuführen.
Diese und weitere Aufgaben und Merkmale der Erfindung werden Fachleuten nach Erwägung der folgenden detaillierten Beschreibung und der begleitenden Zeichnungen verständlich werden, in welchen gleiche Bezugszeichen gleiche Merkmale in allen Figuren darstellen.

KURZE BESCHREIBUNG DER ZEICHNUNG

Fig. 1 stellt die neuartige DTC-Schnittstellenbildung mit einem RISC-System über einen Ortsbus in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung dar, und die Schnittstellenbildung mit einem Fern-Bus, dem ein Satz von Periphergeräten; ein I/O-Subsystem, etc., angefügt werden kann.
Fig. 2 bildet ein Pin-Anordnungsdiagramm für ein Integrierte-Schaltung-Paket ab, welches den neuen DTC beinhaltet und vereinfacht seine Zwischenverbindung in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung sowohl zu einem RISC-System über einen Ortsbus als auch zu einem Satz von Periphergeräten über einen Fern-Bus.
Fig. 3 ist ein Funktionsblockdiagramm eines DTCs, aufgebaut in Übereinstimmung mit der Lehre der Erfindung mit vier I/O-Ports und vier DMA- Kanälen.
Fig. 4 bildet die geltenden Konventionen für den Ort für Bytes und Halbworte innerhalb von Halbworten und Worten ab, die durch den hier mitgeteilten neuen DTC, unterstützt werden.
Fig. 5 veranschaulicht das Umlagern von Bytes innerhalb von Halbworten und Worten, wenn der DTC verwendet wird, um zwischen den Adressierkonventionen, die in Fig. 4 abgebildet sind, zu konvertieren.
Fig. 6 ist ein Blockdiagramm, welches den I/O-Port-Datenfluß für einen I/O-Port veranschaulicht.
Fig. 7 ist ein Flußdiagramm, welches veranschaulicht, wie der DTC überlappte I/Os unterstützt.
Fig. 8 ist ein Blockdiagramm, welches einen DMA-Kanal-Datenfluß für einen einzelnen DMA-Kanal veranschaulicht.
Fig. 9 veranschaulicht leere, teilweise volle und volle DMA-Warteschlangen.
Fig. 10 ist ein Beispiel, wie die kommerziell erhältlichen Vorrichtungen benutzt werden können, um den neuen DTC mit dem Fern-Bus zu verbinden.
Fig. 11 veranschaulicht einen Datenort für Ortsbus-Datentransfers, auf D0-D31, sowohl zum als auch vom neuen DTC.
Fig. 12 veranschaulicht einen Datenort für Fern-Bus-Datentransfers, auf RAD0- RAD31, sowohl zum als auch vom neuen DTC.

DETAILLIERTE BESCHREIBUNG

Gemäß der bevorzugten Ausführungsform der Erfindung implementiert der DTC vier Adress-abgebildete Eingabe/Ausgabe-Ports auf dem Ortsbus. Diese Ports schaffen eine Überleiteinrichtung von dem Ortsbus zum Fern-Bus, so daß ein dem Ortsbus angefügte Prozessor direkt auf Vorrichtungen und Speicher auf dem Fern- Bus zugreifen kann.
Jeder I/O-Port ist gemäß der bevorzugten Ausführungsform der Erfindung eine Anzahl von Bytes mit der Größe einer Zweierpotenz und kann an irgendeiner entsprechenden Zweierpotenz-Adressgrenze auf dem Ortsbus beginnen. Die Ports können auf dem Ortsbus entweder in dem Datenspeicher-Adressraum oder dem I/O-Adressraum erscheinen. Diese Adressräume sind in der zugehörigen anhängigen Anmeldung definiert. Die Ports sind Adress-abgebildet, so daß ein Adressieren auf dem Ortsbus unabhängig von einem Adressieren auf dem Fern-Bus ist. Optionale Lese-Davor/Schreibe-Dahinter-Merkmale auf diesen Ports lassen zu, daß Fern-Bus-Zugriffe sich mit Ortsbus-Zugriffen überlappen. Diese Merkmale werden in Einzelheiten im folgenden beschrieben.
Der DTC implementiert auch vier gepufferte DMA-Kanäle, die DMA-Transfers von dem Fern-Bus zu dem Ortsbus und von dem Ortsbus zu dem Fern-Bus unterstützen. Für DMA-Zugriffe werden Daten, gemäß der bevorzugten Ausführungsform der Erfindung, in einer der vier 64-Wort-Warteschlangen gepuffert. Es gibt eine einzelne Warteschlange pro DMA-Kanal.
Die DMA-Wartenschlangen reduzieren den Überschuß von DMA-Transfers auf dem Ortsbus durch das Zulassen der Transfers großer Mengen von Daten für jede Ortsbus-Akquisition. Das ist besonders effektiv, wenn die Burst-Mode-Fähigkeit des Ortsbusses verwendet wird. Die Warteschlangen können direkt durch Software manipuliert werden, welche auf z. B. dem RISC-Prozessor ausgeführt wird.
Wie oben angezeigt, bildet Fig. 1 in Blockdiagrammform den DTC ab, welcher einen Ortsbus eines RISC-Systems mit einem Fern-Bus verbindet.
Insbesondere ist die DTC-Einheit 104 gezeigt, die mit einem 32-Bit-Adress-Bus 111 und einem 32-Bit-Daten-Bus 112 über ein Link 111a bzw. 112a verbunden ist.
Es sei bemerkt, daß der Ortsbus, auf den hier Bezug genommen wird und der als Ortsbus 110 in Fig. 1 gezeigt ist, aus einem Adress-Bus 111 und einem Daten-Bus 112 besteht.
Der RISC-Prozessor 101, ein Programmspeicher 102, ein Datenspeicher 103, die Zwischenverbindungen zwischen diesen Vorrichtungen, d. h. 111b, 111c, 111d und 112b, ein Adress-Bus 111 und ein Daten-Bus 112 sind im Detail in der Anmeldung EP-A 0 283 115, auf die oben Bezug genommen wird, beschrieben. Der neue DTC wird hier im Kontext mit dem RISC-System, das in der genannten EP- Anmeldung dargelegt ist, nur zum Zwecke einer Veranschaulichung beschrieben.
In der EP-Anmeldung, auf die oben Bezug genommen wird, sind ein DTC 104 und eine Schnittstelleneinheit 105 nicht gezeigt. Die Schnittstelleneinheit 105 kann, muß jedoch nicht verwendet werden, um den DTC 104 mit dem Fern-Bus 120 zu verbinden. Beide Einheiten 104 und 105 werden im Detail im folgenden beschrieben.
Gemäß der bevorzugten Ausführungsform der Erfindung ist der DTC 104 in 1.2 um CMOS-Chip-Technologie realisiert und ist in einem 169-Pin-Raster-Array- (BGA)-Gehäuse verpackt, wobei 184 Signal-Pins, 20 Leistungs- und Erdungs- Pins und ein einzelner Einstellungs-Pin verwendet werden.
Fig. 2 bildet ein Pin-Ausgangsdiagramm für den DTC 104 ab. Ein IC-Package 204 von Fig. 2 beinhaltet den neuen DTC und erleichtert seine Verbindung, in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung, sowohl zum RISC-System, abgebildet in Fig. 1, über den Ortsbus 110, als auch zu einem Satz von Periphergeräten über den Fern-Bus 120. Die Ortsbus-Verbindungen zum und vom DTC sind auf der linken Seite der gepunkteten Linie A-A in Fig. 2 gezeigt und die Fern-Bus-Verbindungen zum und vom DTC sind auf der rechten Seite der gepunkteten Linie A-A in Fig. 2 gezeigt.
Bevor mit der Beschreibung darüber begonnen wird, wie die Schnittstelle benutzt werden kann, wurde ein Satz von DTC-Eingabe- und Ausgabesignalen in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung definiert, um die Kommunikation sowohl von Substanz- als auch Steuerinformation zwischen dem DTC 104 und den Vorrichtungen, die mit ihm über Busse 110 und 120 verbunden sind, zu erleichtern. Diese Signale sind in eins-zu-eins Übereinstimmung mit den Pins, die im in Fig. 2 abgebildeten Pin-Ausgangsblock gezeigt sind.
Eine Beschreibung der Signale, die über die in Fig. 2 abgebildete integrierte Schaltung in den DTC 104 eingegeben und von ihm ausgegeben werden, zusammen mit der Beschreibung, wie der DTC verwendet werden kann, um Kommunikationen zwischen dem Ortsbus 110 und dem Fern-Bus 120 (der in Einzelheiten nachfolgend beschrieben ist) zu unterstützen, wird die Funktionstüchtigkeit und Nützlichkeit des DTC veranschaulichen. Ein Durchschnittsfachmann wird leicht erkennen, daß dieselbe Lehre, wie der DTC als eine Schnittstelle zwischen einem RISC-Prozessor, der dem Ortsbus 110 angefügt ist, und Vorrichtungen, die dem Fern-Bus 120 angefügt sind, zu verwenden und zu steuern ist, darauf ausgedehnt werden kann, wie der DTC zu verwenden und zu steuern ist, um die Kommunikation zwischen Sätzen von Vorrichtungen mit unterschiedlichen Leistungsmerkmalen zu erleichtern, die Bussen, die über den DTC verbunden sind, angefügt sind.
Im Interesse einer Veranschaulichung und Stimmigkeit mit der EP-Anmeldung, auf die oben Bezug genommen ist, sei eine 32-Bit-Befehls- und Daten-Wort- Architektur für das RISC-System angenommen. Für einen Durchschnitts- Fachmann ist es verständlich, daß die veranschaulichte Ausführungsform die Realisierung oder den Umfang der Erfindung mit Bezug auf Computersysteme mit unterschiedlichen Wortlängen in keiner Weise einschränkt.
Im folgenden wird auf Fig. 2 Bezug genommen, die jeden Eingang und Ausgang zu und von dem DTC 104 der bevorzugten Ausführungsform der Erfindung in Form des Pin-Ausgangsblocks abbildet.
Mit Blickrichtung zuerst auf die Ortsbus-Eingänge und Ausgänge (linke Seite von Fig. 2) sind der Adress-Bus 111 und der Datenbus 112 von Fig. 1 mit Block 104 von Fig. 2 über eine 64-Pin-Bus-Zwischenverbindung verbunden, welche zwei Sätze von jeweils 32 Pins aufweist. Der erste Satz von 32 Pins dient dazu, den Bus 111 von Fig. 1 mit dem DTC 104 zu verbinden und ist mit "A0-A31"in Fig. 2 markiert. Der zweite Satz von 32 Pins für den separaten und unabhängigen Datenbus, Bus 112 von Fig. 1, ist mit "D0-D31" in Fig. 2 markiert.
Ehe mit der Pin-Beschreibung von Fig. 2 begonnen wird sei angemerkt, daß der Ausdruck "Drei-Status" im nachfolgenden dazu verwendet wird, Signale zu be schreiben, die während eines normalen Betriebes in den Hoch-Impedanz-Status gesetzt werden können. Alle Ausgänge (Ausnahme MSERR) können durch die *TEST-Eingabe in den Hoch-Impedanz-Status gesetzt werden. Sowohl MSERR als auch *TEST werden nachfolgend mit Bezugnahme auf die Pin-Beschreibung von Fig. 2 beschrieben.
Zur Beschreibung der Ortsbus-Signale zurückkehrend, sei bemerkt, daß alle Ortsbus-Signale synchron zu SYSCLK sind. SYSCLK ist in der EP-Anmeldung, auf die oben Bezug genommen wird, beschrieben.
Die A0-A31-(Adress-Bus)-Pins sind bidirektional, synchron und vom Drei-Status- Typ. Der Adress-Bus transferiert die Byte-Adresse für alle Ortsbus-Zugriffe, mit Ausnahme der Burst-Mode-Zugriffe. Bei Burst-Mode-Zugriffen transferiert er die Adresse für den ersten Zugriff in der Sequenz.
Die D0-D31-(Daten-Bus)-Pins sind bidirektional, synchron und vom Drei-Status- Typ. Der Daten-Bus transferiert Daten zu und von dem DTC 104 auf der Ortsbus- Seite des DTC.
Alle der anderen Pins und Signale auf der Ortsbus-Seite der Linie A-A von Fig. 2 sind mit Ausnahme von *CSEL, DP0-DP3 und *INTR in der EP-Anmeldung, auf die oben Bezug genommen wird, beschrieben. Jedoch wird im folgenden aufgrund der Klarheit und Vollständigkeit ein Rückblick auf den Zweck eines jeden dieser Pins und der Signale im Kontext mit dem DTC 104, zusätzlich zur Beschreibung der Pins und Signale, die nicht anderweitig beschrieben sind, gegeben. Alle Pin- und Signalbeschreibungen, die folgen, befinden sich in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung.
SYSCLK (system clock) ist eine Eingabe zum DTC 104. Die Eingabe ist ein Taktsignal, welches mit der Frequenz des Ortsbusses betrieben wird. Der DTC 104 benutzt dieses Signal, um alle Ortsbus-Zugriffe zu synchronisieren.
*BREQ (bus request) ist eine synchrone Aktiv-LOW, DTC 104-Ausgabe, die benutzt wird, um für den Ortsbus zu entscheiden.
*BGRT (bus grant) ist eine synchrone Aktiv-LOW, DTC 104-Eingabe, welche den DTC 104 darüber informiert, daß er den Ortsbus steuert. Dies kann bestätigt werden, selbst wenn *BERQ inaktiv ist. Falls der DTC 104 einen zugeordneten Ortsbus nicht benutzen kann, bestätigt er *BINV (nachfolgend beschrieben), um einen leeren Ortsbus-Zyklus zu erzeugen.
*CSEL (chip select) ist eine synchrone Aktiv-LOW, DTC 104-Eingabe. Der DTC 104 kann, gemäß der bevorzugten Ausführungsform der Erfindung so konfiguriert sein, daß er eine Ortsbus-Anforderung entweder als das Ergebnis einer Adress- Dekodierung oder als das Ergebnis eines aktiven Pegels auf *CSEL erkennt. Diese Eingabe ist nur für Zugriffe auf interne DTC-104-Register relevant, die im nachfolgenden im Umfang, der erforderlich ist, um die Erfindung zu erläutern, beschrieben werden.
*BINV (bus invalid) ist eine synchrone Aktiv-LOW, DTC 104-Ausgabe, die angibt, daß der Adress-Bus 111 und darauf bezogene Steuerungen ungültig sind. Sie definiert einen Leerzyklus für den Ortsbus. Der Pin selbst ist bidirektional.
*DREQ (data request) ist ein bidirektionaler Pin. Das Signal auf diesem Pin ist synchron, vom Drei-Status-Typ und Aktiv-LOW. Dieses Signal gibt einen aktiven Daten-Zugriff auf den Ortsbus an. Wenn sie bestimmt ist, erscheint die Adresse für den Zugriff auf dem Adress-Bus 111.
Die DREQT0-DREQT1 (data request type)-Signale sind synchron und vom- Drei-Status-Typ. Diese Signale spezifizieren den Adressraum für einen Datenzugriff auf den Ortsbus wie folgt (der Wert "x" ist ein kümmere-dich-nicht):
R/*W (read/write) ist ein bidirektionales, synchrones Drei-Status-Signal. Wenn der DTC 104 ein untergeordneter Ortsbus ist, zeigt dieses Signal an, ob Daten vom Ortsbus-Prozessor zum DTC 104 (R/*W LOW) oder vom DTC 104 zum Prozessor (R/*W HIGH) transferiert werden. Wenn DTC 104 der übergeordnete Ortsbus ist, zeigt dieses Signal an, ob Daten vom DTC 104 zum Ortsbus-Speicher (R/*W LOW), oder vom Ortsbus-Speicher zum DTC 104 (R/*W HIGH) transferiert werden.
SUP/*US (supervisor/user mode) ist ein bidirektionaler Pin. Die Signalausgabe auf diesem Pin ist synchron und vom Drei-Status-Typ. Diese Ausgabe zeigt den Programm-Modus des Ortsbus-Prozessors (Supervisor-Modus oder Benutzer- Modus) während eines Zugriffs an. Diese Modi sind in der einbezogenen, anhängigen Anmeldung definiert. Die internen Register von DTC 104 sind vor einem Benutzer-Modus-Zugriff geschützt (entweder lesen oder schreiben). DTC 104- I/O-Ports können vor Benutzer-Modus-Zugriff als eine Option geschützt sein.
Die OPT0-OPT1-(option control)-Signale sind synchron und vom Drei-Status- Typ. Die Signale spezifizieren die Datenlänge für Ortsbus-Zugriffe. Byte- und Halbwort-Zugriffe sind nur für Zugriffe gültig, die auf dem Fern-Bus 120 über einen I/O-Port reflektiert werden. Gemäß der Ausführungsform der Erfindung, die für veranschaulichende Zwecke verwendet wird, unterstützt der DTC 104 nur 32- Bit-Transfers auf dem Fern-Bus 120. Die Kodierung dieser Signale ist wie folgt:
*LOCK (lock) ist ein bidirektionales, synchrones Aktiv-LOW-Signal, das verwendet wird, um anzuzeigen, daß ein elementarer Lese-Modifizier-Schreibe- Zyklus auf dem Fern-Bus 120 durchzuführen ist. Es ist nur für einen I/O-Port- Zugriff signifikant. Der DCT 104 bringt dieses Signal auf HIGH, wenn es sich um einen übergeordneten Ortsbus handelt.
DP0-DP3 (data parity) sind synchrone, Drei-Status-, ungerade-Byte-Parität- Signale für Daten, die in dem Ortsbus-Speicher gespeichert sind. Das DP0-Signal ist die Byte-Priorität für D0-D7, das DP1-Signal ist die Byte-Parität für D8-D15, usw. Während der DMA-Transfers ermöglicht der DTC 104 die Übertragung der Priorität zum Ortsbus 110 vom Fern-Bus 120 und umgekehrt. Der DTC 104 kann auf eine gültige Parität während entweder einem DMA-Transfer oder einem Fernzu-Lokal-Transfer über ein an I/O-Port prüfen.
*DRDY (data ready) ist ein bidirektionales Signal, das synchron und Aktiv-LOW ist. Für Lesen des Busses zeigt diese Eingabe an, daß gültige Daten auf dem Daten-Bus 111 sind. Für Schreiben gibt es an, daß der Zugriff abgeschlossen ist und daß Daten nicht länger auf dem Daten-Bus 112 getrieben werden müssen. Wenn der DCT 104 für einen Ortsbus-Zugriff untergeordnet ist, bestimmt er *DRDY um anzuzeigen, daß er erfolgreich den Zugriff abgeschlossen hat (sofern nicht *DERR auch bestimmt ist). Wenn der DTC 104 für einen Ortsbus-Zugriff übergeordnet ist, zeigt DRDY an, daß der Ortsbus-Speicher den Zugriff erfolgreich abgeschlossen hat (sofern *DERR ebenfalls bestimmt ist).
Die *DERR-(data error)-Eingabe ist synchron, aktiv-LOW und zeigt an, daß ein Fehler während des laufenden Ortsbus-Zugriffs aufgetreten ist.
*DBREQ (data burst request) ist ein bidirektionales, synchrones, Drei-Status-, Aktiv-LOW-Signal, das verwendet wird, um einen Burst-Mode-Zugriff auf dem Ortsbus einzurichten und um Daten-Transfers während eines Burst-Mode-Daten- Zugriffs anzufordern.
*DBACK (data burst acknowledge) ist ein bidirektionales, synchrones, Aktiv- LOW-Signal, das aktiv ist, wann immer ein Burst-Mode-Daten-Zugriff auf dem Ortsbus hergestellt worden ist (mit DTC 104 entweder übergeordnet oder untergeordnet für den Zugriff). Es kann aktiv sein, selbst wenn gerade auf keine Daten zugegriffen wird.
Die *INTR-(interrupt request)-Ausgabe ist synchron, Aktiv-LOW und kann durch den DTC 104 verwendet werden, um Interrupt- oder Trap-Anforderungen zu signalisieren.
Die *TEST (test mode)-Eingabe ist synchron, Aktiv-LOW und setzt, wenn aktiviert, den DTC 104 in einen Testmodus. Alle Ausgänge und bidirektionalen Leitungen, mit Ausnahme von MSERR, werden in diesem Modus in den Hoch- Impedanz-Status versetzt.
Die MSERR-(master/slave error)-Ausgabe ist synchron, Aktiv-HIGH und zeigt das Ergebnis des Vergleichs von DTC-104-Ausgaben mit den Signalen an, die intern zu Off-Chip-Treibern geliefert werden. Wenn es einen Unterschied für irgendeinen freigegebenen Treiber gibt, wird dieses Signal bestätigt.
Schließlich ist für die Ortsbus-Verbindungen zum DTC 104 die *RESET-(reset)- Eingabe ein synchrones Aktiv-LOW-Signal, das den DTC 104 zurücksetzt.
Auf der Fern-Bus-Seite der A-A-Linie, die in Fig. 2 gezeigt ist, sind die Pins und Signale für die folgenden Zwecke vorgesehen.
Es sei bemerkt, daß alle Fern-Bus-Signale gemäß der bevorzugten Ausführungsform der Erfindung synchron zu RCLK sind, welches ein Takt mit der Betriebsfrequenz der Fern-Bus-Schnittstelle des DTC 104 ist. RCLK ist entweder eine Ausgabe, die mit der halben Frequenz der ROSC-Eingabe (im nachfolgenden erklärt) erzeugt wird oder eine Eingabe von einem externen Taktgenerator. Fern- Bus-Signale können entweder synchron oder asynchron zu diesem Takt sein.
Die ROSC-(remote oszillator)-Eingabe ist, wenn DTC 104 RCLK für den Fern- Bus erzeugt, eine Oszillator-Eingabe mit doppelter Frequenz von RCLK. Wenn RCLK durch einen externen Taktgenerator erzeugt ist, sollte ROSC entweder HIGH- oder LOW-gebunden sein.
Die *RBREQ-(remote bus request)-Ausgabe ist synchron, aktiv-LOW und wird benutzt, um für den Fern-Bus 120 zu entscheiden.
Die *RBGRT-(remote bus grant)-Eingabe kann entweder asynchron oder synchron sein, ist aktiv-LOW und signalisiert, daß der DTC 104 die Steuerung des Fern-Busses 120 hat. Sie kann aktiv sein, selbst wenn *RBREQ inaktiv ist. Falls der DTC 104 die Steuerung des Fern-Busses hat, aber noch keinen Zugriff durchzuführen hat, hält er *ASTB (nachfolgend beschrieben) inaktiv.
RAD0-RAD31 (remote address/data bus) ist ein bidirektionaler Eingabe/Ausgabe-; asynchroner/synchroner Drei-Status-Bus. Die Signale auf diesem Bus sind multiplexierte Adress-/Daten-Signale für den Fern-Bus 120. Wenn *ASTB bestätigt, hält dieser Bus die Byte-Adresse des Fern-Bus-Zugriffs. Wenn *DSTB bestätigt ist, wird dieser Bus benutzt, um Daten zu und von dem DTC 104 und Fern-Bus 120 zu transferieren.
RADP0-RADP3 (remote address/data parity) ist ein Satz bidirektionaler, Drei- Status, asynchroner/synchroner ungeradzahliger Byte-Parität-Signale für RAD0- RAD31. Das RADP0-Signal ist die Byte-Parität für RAD0-RAD7, das DP1- Signal ist die Byte-Parität für RAD8-RAD15, usw. Während des DMA- Transfers ermöglicht der DTC 104 den Transfer des Ortsbus 110 vom Fern-Bus 120 und umgekehrt. Der DTC 104 kann auf gültige Parität während entweder einem DMA-Transfer oder einem Fern-zu-Lokal-Transfer über einen I/O-Port prüfen.
Das *ASTB-(adress strobe)-Signal ist ein Drei-Status, synchrones Aktiv-LOW- Ausgabe-Signal, das dazu bestätigt wird, um anzuzeigen, daß der DTC 104 eine Byte-Adresse für einen Zugriff auf die RAD0-RAD31-Leitungen unterstützt.
Die M/*I/O-(memory/I/O)-Ausgabe ist vom Drei-Status-Typ, synchron und zeigt an, ob der momentane Transfer im Speicher-Adress-Raum oder dem Eingabe/Ausgabe-(I/O)-Adress-Raum des Fern-Busses auftritt.
Die *RMW-(read-modify-write)-Ausgabe ist vom Drei-Status-Typ, synchron und zeigt an, daß der momentane Fern-Bus-Zugriff ein elementares Lese-Modifiziere- Schreibe-Signal ist. Es wird als Antwort auf einen I/O-Port-Zugriff auf den Ortsbus, für welchen das *LOCK-Signal aktiv ist, aktiviert. *RMW ist für die Dauer der Lese-Modifizier-Schreibe-Sequenz bestimmt. Weil dieses Signal für eine Synchronisierung und einen Ausschluß benutzt werden kann, muß der Fern-Bus Untrennbarkeit garantieren.
Die RR/*RW-(remote-read/remote-Write)-Ausgabe ist vom Drei-Status-Typ, synchron und bestimmt die Richtung eines Daten-Transfers. Ein HIGH-Pegel zeigt einen Transfer vom Fern-Bus 120 zum DTC 104 (ein Lesen) und ein LOW-Pegel zeigt einen Transfer vom DTC 104 zum Fern-System (ein Schreiben) an.
Die DSIZE0-DSIZE1-(data size request)-Signale sind vom Drei-Status-Typ, synchron und sind Ausgaben, welche die Datenbreite des angeforderten Transfers reflektieren. Das Kodieren dieser Signale gemäß der bevorzugten Ausführungsform der Erfindung ist wie folgt:
*DSTB (data strobe) ist eine Drei-Status-, synchrone, Aktiv-LOW-Ausgabe, welche anzeigt, daß die RAD0-RAD31-Leitungen für einen Daten-Transfer (ein Lesen) verfügbar sind, oder daß die RAD0-RAD31-Leitungen gültige Daten für ein Schreiben enthalten.
Die DSACK0-DSACK1-(data size acknowledge)-Signale sind asynchrone/synchrone Eingabe-Signale, die anzeigen, daß ein angeforderter Zugriff abgeschlossen ist, und zeigen die Datenbreite, die durch die Vorrichtung, auf die zugegriffen ist, unterstützt wird (8, 16 oder 32 Bits). Falls die angezeigte Datenbreite ist für den durch DSIZE0-DSIZE1 angeforderten Transfer nicht ausreichend ist, tritt eine Datenbreite-Ausnahme auf. Das Kodieren dieser Signale ist wie folgt:
Es sei angemerkt, daß *RBRR und *EOP (im folgenden beschrieben) ein alternatives Mittel für ein Beenden eines Zugriffs liefern, wenn es dort keine DSACK0- DSACK1-Antwort gibt.
*RBERR (remote bus error) ist eine asynchrone/synchrone Aktiv-LOW-Eingabe, welche während des Datenzyklus eines Fern-Bus-Transfers, wenn aktiv, einen Fehlerzustand auf dem Fern-Bus für den momentanen Transfer anzeigt.
*EOP (end of process) ist eine asynchrone/synchrone DTC-Eingabe, aktiv-LOW, welche eine Fern-Bus-Vorrichtung benutzen kann, um das Ende eines DMA- Transfers zu signalisieren, ohne Rücksicht auf irgendeinen Beendigungszustand in dem DTC, während des letzten DMA-Transfers. *EOP beendet den Daten-Zyklus eines DMA-Transfers, ohne Rücksicht auf DSACK0-DSACK3.
Die *DRQ0-DRQ3-(DMA request)-Eingaben sind asynchron/synchron, aktiv- LOW und werden durch Fern-Bus-Vorrichtungen benutzt, um DMA-Transfers anzufordern. Die Eingaben *DRQ0-*DRQ3 fordern DMA-Transfers jeweils für DMA-Kanäle 0 bis 3 an. Gemäß der bevorzugten Ausführungsform der Erfindung ist die relative Priorität der Anforderung so programmierbar, daß sie entweder fest oder rotierend ist. DTC 104 bestätigt die entsprechende DMA-Bestätigung, wenn der DMA-Transfer auftritt. Diese Eingaben müssen aktiv gehalten werden, bis die entsprechende DMA-Bestätigungs-Ausgabe bestätigt ist.
Schließlich sind Ausgaben *DAK0-*DAK3 (DMA acknowledge) synchron, Aktiv-LOW und werden verwendet, um zu bestätigen, daß der DTC 104 einen DMA-Transfer auf dem Fern-Bus 120 durchführt. Die Ausgaben *DACK0- *DACK3 bestätigen DMA-Transfers jeweils für DMA-Kanäle 0 bis 3.
Nachdem ein Satz von DTC-Eingabe- und Ausgabe-Signalen, die zum Steuern der Schnittstelle zwischen dem Ortsbus 110 und dem Fern-Bus 120 nützlich sind, beschrieben wurde, wird nun eine detaillierte Funktionsbeschreibung des DTC selbst und wie er eine Vielzahl von Daten- und Adress-Transfers unterstützt, dargelegt. Diese Beschreibung wird die Demonstration sowohl des Betriebs als auch der Nützlichkeit der Erfindung vervollständigen.
Nun sollte auf Fig. 3 Bezug genommen werden, die ein Funktions- Blockdiagramm eines DTC bildet, der in Übereinstimmung mit der Lehre der Erfindung aufgebaut ist, vier I/O-Ports und vier DMA-Kanäle aufweist. Die Beschreibung von Fig. 3 wird einen Überblick der DTC-Betriebsweise liefern.
Der DTC ist durch eine gestrichelte Linie umrissen und durch das Bezugszeichen 310 bezeichnet, entsprechend zu Block 104 in Fig. 1.
Nur ein untergeordneter Satz der zuvor beschriebenen DTC-Eingabe- und Ausgabesignale, mit einem Kennzeichnen einer möglichen Signalrichtung, angezeigt durch Pfeilspitzen, ist in Fig. 3 gezeigt. Insbesondere die Signale A0-A31, *CSEL, D0-D31, DP1-DP3, RAD0-RAD31 und RADP0-RADP3 sind, als an dem DTC 310 gekoppelt, dargestellt.
Nur diese Signale sind notwendig, um einen Überblick darzulegen, wie Daten- und Adress-Informationen durch den DTC 310 kanalisiert sind.
Für Fachleute wird verständlich, daß der DTC 310 interne Register (in Fig. 3 nicht gezeigt) hat, die verwendet werden, um verschiedene Signale, Zähler, Eingaben, Ausgaben, etc. zu halten und zu steuern, die in, aus oder durch den DTC 310 fließen. Die besondere Registerstruktur, die verwendet wird, um den DTC 310 zu implementieren, ist instruktiv, obwohl sie nicht die einzige Struktur zum Betreiben und Steuern eines I/O-Controllers ist. Entsprechend wird ein allgemeiner Ab riß der in der bevorzugten Ausführungsform der Erfindung verwendeten internen DTC-Register, zusammen mit einer kurzen Beschreibung der Funktion eines jeden dieser Register zum Zweck der Vollständigkeit dargelegt. Auch wird, immer wenn ein besonderes internes Register von Bedeutung beim Erklären der Funktionsweise des DTC 310 nützlich ist, darauf besonders verwiesen.
Es sei angemerkt, daß die internen DTC-Register gemäß der bevorzugten Ausführungsform der Erfindung über einen Adress-Bus 111 adressiert werden können. Zum Beispiel kann vor einem Benutzen der I/O-Ports ein Bereich von Adressen in interne DTC-Register geladen werden, um Zugriffs-Fenster zu erstellen, in welche (oder von welchen) Daten geschrieben und von den Ports ausgelesen werden. Diese Initialisierungsfunktion kann gemäß der bevorzugten Ausführungsform der Erfindung durch Adress-, Vergleich- und Steuer-Dekoder-Mittel 301 von Fig. 3 durchgeführt werden, welche durch allgemein bekannte Hardware- und/oder Software-Techniken zum Laden von Registern, die keinen teil der Erfindung darstellen, implementiert werden können. Zusätzlich zum Erstellen von Port-Fenstern werden die *CSEL-Eingabe und A0-A31-Eingaben zum Block 301 und die Steuerungsausgabe vom Block 301 (zu DTC-310-internen-Registern) verwendet, um gemäß der bevorzugten Ausführungsform den DTC 310 zu konfigurieren, um Ortsbus-Anforderungen entweder als ein Ergebnis einer Adress-Dekodierung oder als das Ergebnis des *CSEL zu erkennen, der aktiv ist (LOW).
Fig. 3 bildet zusätzlich zum Mittel 301 ab: I/O-Ports 0-3 (Mittel 302), DMA- Kanäle 0-3 (Mittel 303), ein Pack- und Kanalisier-Netzwerk (Mittel 302), Multiplexier- und Transceiver-Vorrichtungen (Transfer-Mittel 305) und verschiedene Paritäts-Prüf-Mittel. Auch sind in Fig. 3 A0-A31 (Adress-Bus 111), D0-D31 (Daten-Bus 112) und der *CSEL-Eingang, die alle auf der Ortsbus-Seite des DTC 310 liegen, gezeigt. Auf der Fern-Bus-Seite des DTC 310 sind die Schnittstellen RAD0-RAD31 und RADP0-RADP3 gezeigt.
Wie oben angezeigt, kann das Mittel 301 benutzt werden, um die zuvor genannte Fenster-Erstellung, d. h. ein Öffnen von I/O-Ports, etc., durchzuführen. Gemäß der bevorzugten Ausführungsform der Erfindung haben diese Fenster Zweierpotenz- Bereiche, die auf einer Ortsbus-Wort-Grenze beginnen.
Die 4 I/O-Ports im Mittel 302 werden über Lade- und Speicherbefehle adressiert, die durch den RISC-Prozessor der veranschaulichten Ausführungsform ausgeführt werden. Die 4 DMA-Kanäle in dem Mittel 303 sind auf allgemein bekannte Weise für eine Verwendung von DMA-Kanälen, um eine Startadresse für einen Daten-Transfer zu bestimmen, vorprogrammiert. Typischerweise wird ein sequentielles Adressieren für DMA-Transfers verwendet, obwohl die Erfindung durch begrenzte, nicht-sequentielle Transfers, z. B. durch 2, 4, etc. gekennzeichnet ist, basierend auf der Verwendung interner DTC-Zähler, welche ein Basis-Adress- Register inkrementieren. Wieder können Mittel 301 verwendet werden, um die Register und Zähler in den Mitteln 302 und 303 zu initialisieren.
Falls während des Betriebs des DTC eine auf A0-A31 dargestellte Adresse durch den I/O-Controller als innerhalb eines I/O-Port-Fensters liegend erkannt ist, dann wird die Adresse innerhalb des Mittels 302 in den Fern-Bus-Adressraum übertragen. Wenn die Adresse nicht erkannt wird, tritt keine Translation auf.
Eine Adress-Translation für I/O-Ports wird gemäß der bevorzugten Ausführungsform der Erfindung durch Ersetzen der Adress-Eingabe zum DTC mit einer entsprechenden Fern-Bus-Adresse innerhalb eines Bereichs von Fern-Bus-Adressen durchgeführt, die während einer Initialisierung in die I/O-Port-Register geladen werden. Diese Fern-Bus-Adressen stimmen 1 zu 1 mit dem Ortsbus-Adress- Fenster, erstellt für einen angegebenen Port, überein und entsprechen auch diskreten Vorrichtungsadressen für Vorrichtungen, die mit dem Fern-Bus verbunden sind.
Der DTC 310 führt dann den Fern-Bus-Zugriff unter Verwendung der übertragenen Adresse durch, d. h., er führt das geeignete Lesen oder Schreiben in Übereinstimmung jeweils entsprechend mit der Ausführung von RISC-Prozessor-Lade- und Speicherbefehlen durch.
Mit Bezugnahme auf das DMA-Kanalmittel 303 bestimmt jeder Kanal die Adresse, von welcher (oder zu welcher) Daten zu übertragen sind. Das Mittel 303 ist vorprogrammiert, um diese Bestimmung durchzuführen und arbeitet unabhängig von dem RISC-Prozessor, außer um initialisiert zu werden. Wie zuvor angezeigt, haben die DMA-Kanäle gemäß der bevorzugten Ausführungsform der Erfindung die Flexibilität, begrenzte nicht-sequentielle Transfers durchzuführen.
Fig. 3 fährt fort, Multiplexer- Transceiver-Schaltungen in einem Mittel 305 zu zeigen, um anzuzeigen, daß Adressen und Daten verschachtelt sind, wenn sie vom Fern-Bus über die Transceiver und die RAD0-RAD31-(und 4-Parität-Bit)- Schnittstelle ausgegeben oder davon empfangen sind.
Mit Bezugnahme auf Fig. 3 sei auch angemerkt, daß alle Daten zu und von dem Mittel 305 und entweder einem I/O-Port oder DMA-Kanal durch eine Spezialschaltung 304 hindurchgehen müssen, der eine Datenbreitenumwandlung liefert, d. h. eine Operation, um Umwandlungen zwischen Byte- und Halbwort-Daten, gepackt in Worte und umgekehrt auszuführen, die im nachfolgenden "Pack"- und "Kanalisier"-Operationen genannt werden. Um mit diesen so definierten technischen Ausdrücken konsistent zu sein, wird die Schaltung 304 nachfolgend "Datenbreitenumwandlung-Netzwerk" oder "Pack-/Kanalisier-Netzwerk-Mittel" bezeichnet.
Falls z. B. Bits D8-D15 aus dem Daten-Bus-Abschnitt des Ortsbusses zu nehmen sind und auf den Fern-Bus (ein Schreiben) zu transferieren sind, "kanalisiert" das Datenbreitenumwandlung-Netzwerk oder das Pack-/Kanalisier-Netzwerk-Mittel 304 gemäß der bevorzugten Ausführungsform der Erfindung, das im nachfolgen den in weiteren Einzelheiten zu beschreiben ist, 4 Kopien der 8 Bits, nebeneinandergestellt in einem Wort, zu dem Fern-Bus, d. h. allgemein gesagt, ein erstes Datenelement (Wort) mit einer ersten (breiteren) Breite auf dem Ortsbus wird in mehrere (hier 4) Transfers eines zweiten Datenelements (Byte) mit einer zweiten Breite, die geringer ist als die erste Breite, für eine Kommunikation auf dem Fern- Bus transferiert.
Für Halbwort-Transfers vom Ortsbus zum Fern-Bus konvertiert das Netzwerk- Mittel 304 ein 32-Bit-Wort, das auf dem Ortsbus mitgeteilt wird, in zwei Sätze der geeigneten 16 Bits (= Halbwort), nebeneinandergestellt zum Ausgeben in zwei Transfers durch den DTC zum Fern-Bus.
Zum Lesen kommen Daten normalerweise vom Fern-Bus in denselben Speicherzyklus spät zurück, wenn das Lesen ausgeführt wird. Normalerweise sind die Daten (8, 16 oder 32 Bits) rechts ausgerichtet und durch das Mittel 304 in ein 32-Bit- Wort "gepackt", da alle Transfers zum Ortsbus 32 Bit breit sind. Wieder werden die Einzelheiten der Betriebsweise des Mittels 304 im nachfolgenden dargestellt.
Nachdem die Beschreibung der Übersicht über den DTC 310 abgeschlossen ist, wird nun eine verallgemeinerte Beschreibung interner Register zusammen mit einer Beschreibung der durch den neuen DTC unterstützten Datenformate dargelegt. Dies wird Fachleute in die Lage versetzen, zu verstehen, wie die Erfindung herzustellen und zu verwenden ist. Auch werden eine spezielle Erklärung des I/O- Ports und der implementierten DMA-Funktionen im Kontext eines Benutzens der Erfindung dargelegt werden, um ein RISC-System zu unterstützen.
Die meisten Software-Interaktionen mit dem DTC 310 treten über Zugriffe auf die internen DTC-Register auf. Diese Register werden geschrieben und gelesen durch Wortlängenzugriffe (d. h. 32-Bit) auf den Ortsbus. Keine sind direkt über den Fern-Bus zugänglich.
Die Register sind in 4 Klassen gruppiert:
1. globale Steuerregister
2. DMA-Kanal-Register
3. I/O-Port-Register
4. Warteschlangen-Register.
Ein RISC-Prozessor auf dem Ortsbus greift auf DTC-Register unter Verwendung von Lade- und Speicherbefehlen zu. Jedem Register ist eine eindeutige Adresse entweder im Datenspeicher oder im I/O-Adress-Raum des RISC-Systems zugeordnet. Diese Adresse ist gemäß der vorliegenden Ausführungsform der Erfindung in Form einer Wort-Versetzung von der Basis-Adresse spezifiziert. Die Basis-Adresse ist allen DTC-Registern gemeinsam. Ein Chip-Select-Mapping- Register in dem DTC spezifiziert die Basis-Adresse für DTC-Register und spezifiziert, ob diese Adresse sich in dem Daten-Speicher oder im I/O-Adress-Raum des RISC-Systems befindet, dem der DTC zugeordnet ist, in Übereinstimmung mit dem Beispiel, das verwendet wird, um die Betriebsweise des DTC zu illustrieren.
Alternativ kann der DTC, wie zuvor angezeigt, über ein Mittel 301 von Fig. 3 konfiguriert werden, um den Ortsbus zu ignorieren und auf irgendeinen Registerzugriff, für welchen der *CSEL-Eingang aktiv ist, zu antworten. In diesem Fall wird ein besonderes Register nur durch den Offset-Teil der Adresse ausgewählt.
Die globalen Steuerregister, von welchen 5 für die bevorzugte Ausführungsform der Erfindung bestimmt sind, beinhalten Steuerungs- und Status-Informationen für den DTC als eine Gesamtheit. Die 5 definierten Register sind ein Global- Mode-, Global-Status-, Local-Burst/Dwell-, Remote-Burst/Dwell- und Chip- Select-Mapping-Register.
Das Global-Mode-Register kann verwendet werden, um DTC-Optionen, die nicht Port- oder Kanal-spezifisch sind, zu konfigurieren.
In Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung sind Bits in dem Global-Control-Register reserviert, um DMA-Kanäle und I/O-Ports freizugeben oder zu sperren, um zu bestimmen, ob Fern-Bus-Operationen synchron oder asynchron mit RCLK sind, um den Adressraum (Daten-Speicher- oder I/O-Adressraum auf dem Ortsbus) für die internen Register des DTC zu spezifizieren, um zu bestimmen, ob der DTC für die *CSEL-Eingabe oder das Chip- Select-Mapping-Register zu verwenden ist, um Zugriffe auf interne Register zu detektieren, um die relativen Prioritäten für eine DMA-Kanal-Anforderung (diese können fest oder rotierend sein) zu bestimmen, um die Byte-Reihenfolge (auf die nachfolgend als "LBO" oder Local-Byte-Order Bezug genommen wird) für alle Ortsbus-Transfers zu spezifizieren (d. h., ob Bytes innerhalb von Worten und Halbworten von links nach rechts oder umgekehrt zu adressieren sind), um eine Paritätsprüfung freizugeben oder zu sperren und um DTC-Interrupts freizugeben oder zu sperren.
Es sollte zur Kenntnis genommen werden, daß die LBO-Information gemäß der bevorzugten Ausführungsform der Erfindung dazu verwendet wird, die Reihenfolge für Pack- und Kanalisier-Operationen zu bestimmen, und wird in Verbindung mit den Remote-Byte-Ordner-("RBO")-Bits in dem Channel-Mode und Port-Mode-Registern, die nachfolgend zu beschreiben sind, dazu verwendet, zu bestimmen, ob ein Byte-Umlagern auf einem Lokal-zu-Fern- oder Fern-zu-Lokal- Transfer ausgeführt wird oder nicht.
Die in dem Global-Status-Register gespeicherte Information ist, in Übereinstimmung mit der bevorzugten Ausführungsform der Erfindung, wie folgt:
Ein Protection-Violation-Bit zeigt an, ob eine Schutz-Verletzung bei einem Zugriff auf ein internes Register aufgetreten ist. Falls ein Benutzer-Modus-Zugriff (angezeigt durch SUP/*US) auf ein internes DTC-Register versucht worden ist, antwortet der DTC mit *DERR. Dieses Bit wird gesetzt, um den Grund für die *DERR-Antwort anzuzeigen.
Ein Data-Width-Exception-Bit zeigt eine Datenbreite-Ausnahme bei Zugriff auf ein internes Register an. Der DTC antwortet auf einen versuchten Byte- oder Halbwort-Zugriff auf ein internes Register mit *DERR. Dieses Bit wird gesetzt, um den Grund für die *DERR-Antwort anzuzeigen.
Ein Adressierfehler zeigt einen Versuch an, auf ein nicht implementiertes DTC- Register zuzugreifen. Wenn ein derartiger Zugriff versucht wird, antwortet der DTC mit *DERR. Dieses Bit wird gesetzt, um den Grund für die *DERR-Antwort anzuzeigen.
Port-Trap-Bits werden verwendet, um anzuzeigen, welcher der I/O-Ports eine *DERR-Antwort erzeugt hat. Wenn ein Port-Trap-Bit gesetzt ist, gibt das Port- Status-Register, das im nachfolgenden zu beschreiben ist, des angezeigten Ports den Grund für die *DERR-Antwort an.
Channel-Interrups-Pending-Bits werden verwendet, um den Unterbrechungs- Status der DMA-Kanäle zu reflektieren. Wenn eines dieser Bits gesetzt ist, ist ein Unterbrechungszustand auf dem Kanal vorhanden, der dem Bit zugeordnet ist. Der Grund für den Zustand kann durch Ausführen des geeigneten Channel-Status- Registers (eines für jeden Kanal, nachfolgend zu beschreiben) bestimmt werden.
Gemäß der bevorzugten Ausführungsform der Erfindung sind Bits ebenso in dem Global-Status-Register reserviert, um den Vorrichtungs-Freigabe-Pegel für den DTC anzuzeigen.
Das Local-Burst/Dwell-Register übt eine globale Steuerung der Ortsbus- Benutzung aus. Gemäß der bevorzugten Ausführungsform der Erfindung enthält dieses Register ein Local-Burst-Count-Feld, das, um Burst-Mode-Operationen zu unterstützen, die in der einbezogenen anhängigen Anmeldung beschrieben sind, die maximale Anzahl von benachbarten Ortsbus-Takt-Zyklen, die der DTC für einen Daten-Transfer benutzen kann, spezifiziert. Falls die Beschränkung für einen Transfer überschritten ist, vervollständigt der DTC irgendeinen Zugriff, der im Ablauf ist, bevor er den Ortsbus aufgibt. Ein Local-Dwell Count-Feld spezifiziert die Anzahl von Ortsbus-Takt-Zyklen, während derer der DTC nach einem erfolgreichen Ortsbus-Transfer auf dem Ortsbus untätig sein muß.
Das Remote-Burst/Dwell-Register übt eine globale Steuerung einer DTC-Fern- Bus-Benutzung aus. Ein Remote-Burst-Count-Feld spezifiziert die maximale Anzahl aufeinanderfolgender Fern-Bus-Takt-Zyklen, die der DTC für einen Daten- Transfer benutzen kann. Falls die Begrenzung für einen Transfer überschritten ist, vervollständigt der DTC jeden Zugriff, der im Ablauf ist, bevor er den Fern-Bus aufgibt. Ein Remote-Dwell-Count-Feld spezifiziert die Anzahl von Fern-Bus- Takt-Zyklen, während derer der DTC auf dem Fern-Bus untätig sein muß, nach einem erfolgreichen Fern-Bus-Transfer.
Das gerade zuletzt definierte Global-Control-Register ist ein Chip-Select- Mapping-Register, welches das Adressieren von DTC-internen Registern in gewissen Fällen steuert, wie zuvor mit Bezugnahme auf das Global-Mode-Register angezeigt wurde. Das Gobal-Control-Register hat auch ein Chip-Select-Address- Feld, welches die Basisadresse für DTC-inteme Register spezifiziert.
Die DMA-Channel-Register beinhalten Steuerungs- und Statusinformationen für die vier DMA-Kanäle, die in der bevorzugten Ausführungsform des DTC erforderlich sind. Dort gibt es vier identische Sätze von Registern, einen Satz pro DMA-Kanal. Elf Register wurden für jeden Kanal definiert. Jedes wird unmittelbar nachfolgend beschrieben.
Ein Channel-Mode-Register steuert DMA-Kanal-Transfers. Es muß verwendet werden, bevor ein DMA-Transfer durchgeführt werden kann.
Dieses Register beinhaltet gemäß der bevorzugten Ausführungsform der Erfindung: ein Remote-Wait-Count-Feld, das die Anzahl von Zyklen (oberhalb von einem) spezifiziert, die *DSTB während eines Fern-Bus-Transfers aktiv bleiben muß; und ein Remote-Recovery Count-Feld, welches die Anzahl von Zyklen spezifiziert, die ein Kanal nachdem ein Fern-Bus-Transfer abgeschlossen ist, untätig bleiben muß. Der Wert dieses Feldes gibt die minimale Anzahl von Zyklen an, die erforderlich sind zwischen dem Ende eines Datenzyklus und dem Beginn des nächsten Datenzyklus für den DMA-Kanal; ein Data-Location-Feld, welches den Ort von Bytes und Halbwort-Daten auf dem Fern-Bus spezifiziert, gemäß der folgenden Tabelle:

Feldwert Ort

00 mittels Adresse
01 hoch fixiert
10 niedrig fixiert
11 niedrig fixiert/Bytes mittels Adresse;
ein Interrupt-Enable-Bit; ein Local-Alarm-Enable-Bit, welches den DMA-Kanal dazu veranlaßt, eine Alarmunterbrechung zu erzeugen, wenn es gesetzt ist und wenn das Local-Byte-Count-Register (nachfolgend zu beschreiben) den Wert in dem Local-Alarm-Count-Register (ebenfalls nachfolgend zu beschreiben) überschreitet; ein Remote-Alarm-Enable-Bit, welches den DMA-Kanal dazu veranlaßt, einen Alarm zu erzeugen, wenn es gesetzt ist und wenn der Wert in dem Remote-Byte-Count-Register den Wert in dem Remote-Alarm-Count-Register übersteigt (sowohl das Remote-Byte-Count- als auch das Remote-Alarm-Count- Register sind nachfolgend zu beschreiben); und ein Local-Transfer-Disable-Bit. Dieses Bit ist 0, wenn Transfers zu oder von dem Ortsbus-Speicher durchgeführt werden. Wenn das Bit 1 ist, sind Transfers zu oder von dem Ortsbus-Speicher gesperrt, und DMA-Warteschlangen werden durch den Ortsbus-Prozessor direkt gelesen und geschrieben; ein DMA-Request-Response-Mode-Feld, in welchem die Bits das Verhalten des DMA-Kanals für eine Bestätigung der folgenden entsprechenden *DRQ0-*DRQ3-Eingabe spezifizieren:

FELDWERT ANTWORTMODUS

00 ignoriere DMA-Anforderung
01 Einzeltransfer
10 fordere Transfer an
11 reserviert;
Ein Block-Mode-Bit, welches bestimmt, ob Block-Mode-Transfers auf dem Fern- Bus durchgeführt werden; ein Remote-Address-Direction-Bit, welches spezifiziert, ob das Remote-Address-Register nach einem DMA-Transfer auf dem Fern- Bus inkrementiert oder dekrementiert ist; ein Remote-Address-Hold-Bit, welches, wenn es 0 ist, zuläßt, daß das Remote-Address-Register inkrementiert oder dekrementiert wird, gemäß dem Remote-Address-Direction-Bit, und welches das Remote-Address-Register konstant hält, wenn es gesetzt ist; ein Queue-Pattern- Bit, welches auswählt, ob die DMA-Warteschlange, die dem Kanal zugeordnet ist, als ein Datenpuffer oder als eine Muster-Quelle verwendet wird; und ein Transfer- Direction-Bit, welches die Richtung von DMA-Kanal-Transfers steuert. Wenn dieses Bit 0 ist, werden Lokal-zu-Fern-Transfers durchgeführt. Wenn dieses Bit 1 ist, werden Fern-zu-Lokal-Transfers durchgeführt; ein Remote-Address-Space- Bit, welches den Adress-Raum des Fern-Transfers spezifiziert. Wenn das Bit 0 ist, werden Transfers zum Speicher-Adress-Raum (IO/*MEM LOW) gerichtet. Wenn es 1 ist, werden Transfers zum I/O-Adress-Raum (IO/*MEM HIGH) gerichtet; ein Data-Size-Acknowledge-Disable-Bit, welches die DMA-Kanal-Antwort zu den DSACK0-DSACK1-Eingäben freigibt oder sperrt; ein Remote-Byte-Order-Bit, welches die Fern-Bus-Byte-Reihenfolge für den DMA-Kanal spezifiziert. Wenn das RBO-Bit 0 ist, werden Bytes und Halbworte sequentiell von links nach rechts innerhalb von Halbworten und Worten adressiert. Wenn es 1 ist, werden sie sequentiell rechts-nach-links adressiert; und schließlich ein Data-Width-Feld, in welchem die Bits die Fern-Bus-Datenbreite für den DMA-Kanal wie folgt spezifizieren:

FELDWERT DATENBREITE

00 32 Bits
01 8 Bits
10 16 Bits
11 ungültig.
Ein Channel-Status-Register hält den momentanen Status des Kanals. Es wird durch den DTC aktualisiert, wenn ein DMA-Transfer beendet ist oder eine Ausnahme auftritt.
Dieses Register enthält gemäß der bevorzugten Ausführungsform der Erfindung ein Parity-Error-Bit, das gesetzt ist, falls eine Prüfung durch das Parity-Check- Enable-Bit des Global-Mode-Registers freigegeben ist, ein Paritätsfehler während eines DMA-Transfers detektiert ist; ein Remote-Bus-Error-Bit, das gesetzt ist, wenn *RBERR während eines Fern-Bus-DMA-Transfers bestätigt wird; ein Data- Width-Exception-Bit, welches gesetzt wird, falls die DSACK0-DSACK1- Antwort auf einen Fern-Bus-DMA-Transfer anzeigt, daß die Fern-Bus- Vorrichtung oder -Speicher einen Transfer der angeforderten Breite nicht bearbeiten kann; ein Address-Conflict-Bit, das gesetzt wird, falls ein Adresskonflikt während eines DMA-Transfers detektiert wird (d. h. ein Transfer zu einem DTC- internen-Register oder I/O-Port); ein Local-Bus-Error-Bit, das gesetzt wird, falls *DERR während eines Ortsbus-DMA-Transfers bestätigt wird; ein End-Of- Process-Bit, das gesetzt wird, falls die *EOP-Eingabe während eines Fern-Bus- DMA-Transfers bestätigt wird; ein Channel-Terminated-Bit, welches die Beendigung des DMA-Transfers spezifiziert; ein Local-Alarm-Count-Reached-Bit, welches gesetzt wird, falls der Wert in dem Local-Byte-Count-Register den Wert in dem Local-Alarm-Count-Register übersteigt, falls durch das Local-Alarm-Enable- Bit des Channel-Mode-Registers freigegeben; ein Remote-Alarm-Count-Reached- Bit, das gesetzt wird, falls der Wert in dem Remote-Byte-Count-Register den Wert in dem Remote-Alarm-Count-Register übersteigt, falls durch das Remote- Alarm-Enable-Bit des Channel-Mode-Registers freigegeben; und ein Data-Size- Acknowledge-Feld, welches den Wert der neuesten DSACK0-DSACK1- Antwort für den DMA-Kanal hält. Wenn eine Datenbreite-Ausnahme auftritt, zeigt dieses Feld an: die Fern-Bus-Antwort, welche die Ausnahme hervorgerufen hat, ein Channel-Aktive-Bit, das 0 ist, wenn der Kanal inaktiv ist, und keine DMA-Transfers durchgeführt werden. Falls das Bit 1 ist, ist der Kanal aktiv. Dieses Bit wird durch den DTC auf 0 gesetzt, wenn der Endzählung erreicht ist oder eine Ausnahme auftritt. Es kann durch den Ortsbus-Prozessor auf 0 gesetzt werden, um zeitweise Transfers auf dem DMA-Kanal auszusetzen; und schließlich ein Channel-Reset-Bit. Dieses Bit ist ein "Nur-Schreibe"-Bit, welches den Wert 0 hat, wenn es gelesen wird. Wenn eine 1 in diesem Bit durch den Ortsbus- Prozessor gespeichert wird, wird der DMA-Kanal zurückgesetzt und das Local- Byte-Count-Register, das Remote-Byte-Count-Register und die Queue-Head- und Queue-Tail-Felder des Queue-Status-Registers (nachfolgend zu beschreiben) sind auf 0 gesetzt.
Ein Local-Address-Register hält die Adresse eines momentanen oder schwebenden Ortsbus-Transfers. Es wird um 4 (Bytes) erhöht nach jedem erfolgreichen Ortsbus-Transfer.
Ein Fern-Adress-Register hält die Adresse von irgendeinem momentanen oder schwebenden Fern-Bus-Transfer. Falls das Remote-Address-Hold-Feld des Channel-Mode-Registers 0 ist, wird es nach jedem erfolgreichen Fern-Bus-Transfer gemäß dem Remote-Address-Direction-Bit in dem Channel-Mode-Register inkrementiert oder dekrementiert. Der Inkrement- oder Dekrement-Betrag ist durch das Data-Width-Feld in dem Channel-Mode-Register spezifiziert:

FELDWERT INKREMENT-DEKREMENT-BETRAG

00 4
01 1
10 2
11 undefiniert
Ein Local-Byte-Count-Register hält die Anzahl von Bytes, die erfolgreich auf dem Ortsbus transferiert sind. Wenn diese Zählung dem Wert in dem Terminate- Count-Register (nachfolgend zu beschreiben) gleich ist oder ihn übersteigt, sind die DMA-Kanal-Ortsbus-Transfers abgeschlossen. Nach jedem erfolgreichen Transfer wird der Wert in dem Local-Byte-Count-Register um 4 (Bytes) erhöht.
Ein Local-Alarm-Count-Register spezifiziert die Anzahl von zu transferierenden Bytes auf dem Ortsbus, bevor eine Alarmunterbrechung erzeugt wird (wenn freigegeben).
Ein Remote-Byte-Count-Register hält die Anzahl von Bytes, die erfolgreich auf dem Fern-Bus transferiert worden sind. Wenn diese Zählung dem Wert in dem Terminate-Count-Register gleich ist oder ihn übersteigt, sind die DMA-Kanal- Fern-Bus-Transfers abgeschlossen. Nach jedem erfolgreichen Transfer wird der Wert in dem Remote-Byte-Count-Register um den Betrag inkrementiert, der durch das Data-Width-Feld in dem Channel-Mode-Register bestimmt ist.

FELDWERT INKREMENT/DEKREMENT-BETRAG

00 4
01 1
10 2
11 undefiniert
Ein Remote-Alarm-Count-Register spezifiziert die Anzahl von auf dem Fern-Bus zu transferierenden Bytes, bevor eine Alarmunterbrechung erzeugt wird (falls freigegeben).
Ein Terminate-Count-Register spezifiziert die durch den DMA-Kanal zu übertragende Anzahl von Bytes.
Ein Pack/Funnel-Register puffert die gerade zu oder vom Fern-Bus übertragenen Daten. Es dient als eine Daten-Bestimmung oder Daten-Quelle für Daten während Pack- und Kanalisieroperationen auf dem DMA-Kanal.
Das definierte letzte DMA-Kanal-Register ist ein Queue-Status-Register, welches Wort-Adress-Zeiger für den momentanen Kopf und Schwanz der DMA- Warteschlänge hält.
Gemäß der bevorzugten Ausführungsform der Erfindung enthält dieses Register ein Queue-Head-Feld, welches die Adresse des nächsten Queue-Registers enthält, das für eine Entnahme aus einer Warteschlange verfügbar ist. Der Wert des Feldes wird, nachdem jedes Wort entnommen ist, um 1 inkrementiert und ein Queue- Tail-Feld, welches die Adresse des nächsten Queue-Registers enthält, das für eine Wiederaufnahme in eine Warteschlange verfügbar ist. Der Wert des Feldes wird, nachdem jedes Wort wieder aufgenommen worden ist, um 1 inkrementiert.
Der nächste Satz zu beschreibender interner Register sind die I/O-Port-Register. Diese Register enthalten Steuerungs- und Statusinformationen für die vier I/O- Ports in dem DTC. Es gibt vier identische Gruppen von Registern, nämlich eine einzelne Gruppe pro I/O-Port. Die Gruppe beinhaltet sechs Register, ein Port- Mode-Register, ein Port-Status-Register, ein Local-Base-Address-Register, ein Remote-Base-Address-Register, ein Local-Port-Address-Register und ein Port- Pack-/Funnel-Register.
Das Port-Mode-Register steuert fernprogrammierte I/O-Transfers (nachfolgend zu beschreiben). Es muß initialisiert werden, bevor ein fernprogrammierter I/O- Transfer durchgeführt wird. Das Port-Mode-Register beinhaltet gemäß der bevorzugten Ausführungsform der Erfindung ein Remote-Wait-Count-Feld. Wenn der DTC eine Fern-Bus-Zeitgabe für I/O-Port-Transfers erzeugt, spezifiziert das Feld: die Anzahl von Zyklen (oberhalb von eins), in denen *DSTB während eines Fern- Bus-Transfers aktiv bleiben muß; und ein Remote-Recovery-Count-Feld. Wenn der DTC eine Fern-Bus-Zeitgabe für I/O-Port-Transfers erzeugt, spezifiziert dieses Feld die Anzahl von Zyklen, die ein I/O-Port, nachdem ein Fern-Bus-Transfer abgeschlossen worden ist, untätig bleiben muß. Der Wert dieses Feldes gibt an: die minimale Anzahl von Zyklen, die zwischen dem Ende eines Datenzyklus und dem Beginn des nächsten Datenzyklus für den I/O-Port erforderlich sind, ein Data-Location-Feld, welches den Ort von Byte- und Halbwort-Daten auf dem Fern- Bus gemäß der folgenden Tabelle spezifiziert:

FELDWERT ORT

00 durch Adresse
01 hoch fixiert
10 niedrig fixiert
11 niedrig fixiert/Bytes durch Adresse
Ein Window-Size-Feld, welches die Größe des I/O-Port-Adressraumes kodiert durch Spezifizieren des Logarithmus (Basis 2) der Portgröße in Bytes. Wenn z. B. der Wert des Window-Size-Feldes 8 ist, ist die Portgröße 256 Bytes. Ähnlich ist, wenn das Window-Size-Feld 17 ist, die Portgröße 128K Bytes; ein Supervisor- Access-Only-Bit, das, wenn es gesetzt ist, nur die Supervisor-Modus-Zugriffe, (wie gekennzeichnet durch das SUP/*US-Signal) über dem I/O-Port erlaubt. Wenn dieses Bit auf 0 gesetzt ist, sind entweder Benutzer-Modus- oder Supervisor-Modus-Zugriffe erlaubt; und ein überlapptes I/O-Bit, welches bestimmt, ob Port-Zugriffe direkt oder entkoppelt sind. Wenn das Bit 0 ist, sind Port- Transaktionen direkt; der Fern-Bus-Zugriff muß abschließen, bevor der Ortsbus- Zugriff abschließen kann.
Wenn das Bit 1 ist, werden Port-Zugriffe entkoppelt und ein Ortsbus-Zugriff kann abschließen, bevor der Fern-Bus-Zugriff durchgeführt ist. Dieses Bit wird gesetzt, um es einem I/O-Port zu ermöglichen, Lese-Davor- oder Schreibe-Dahinter- Operationen durchzuführen und die Parallelität mit Bezug zu Wort-Transaktionen, auf die zuvor Bezug genommen wurde, zu schaffen; einen Local-Address-Space- Bit, das den Addressraum des I/O-Ports auf dem Ortsbus spezifiziert. Falls das Bit 0 ist, ist der I/O-Port in dem Datenspeicher-Adressraum des Ortsbusses. Falls das Bit 1 ist, ist der I/O-Port in dem I/O-Adressraum des Ortsbusses; ein Remote- Address-Space-Bit, das den Adressraum des Fern-Transfers spezifiziert. Falls das Bit 0 ist, sind Transfers zu dem Speicher-Adressraum (IO/*MEM LOW) gerichtet. Falls es 1 ist, sind Transfers zu dem 110-Adressraum (IO/*MEM HIGH) gerichtet; ein Data-Size-Acknowledge-Disable-Bit, das die I/O-Port-Antwort zu den DSACK0-DSACK1-Eingaben freigibt oder sperrt; ein Remote-Byte-Order-Bit, das die Fern-Bus-Byte-Reihenfolge für den I/O-Port spezifiziert. Wenn das Bit 0 ist, werden Bytes und Halbworte sequentiell von links nach rechts innerhalb von Halbworten und Worten adressiert. Wenn es 1 ist, werden sie sequentiell rechts- nach-links adressiert; und schließlich ein Data-Width-Feld, das die Fern-Bus- Datenbreite für den I/O-Port spezifiziert, wie folgt:

FELDWERT DATENBREITE

00 32 Bits
01 8 Bits
10 16 Bits
11 ungültig
Das Port-Status-Register hält den aktuellen Status des I/O-Ports. Es wird durch den DTC aktualisiert, wenn ein I/O-Port-Transfer auf eine Ausnahme trifft und mit *DERR antwortet. Gemäß der bevorzugten Ausführungsform der Erfindung beinhaltet dieses Register ein Protection-Violation-Bit, das anzeigt, ob eine Schutzverletzung an dem I/O-Port aufgetreten ist. Falls ein Benutzer-Modus- Zugriff, (angezeigt durch SUP/*US) zu einem I/O-Port versucht wird, für den das Supervisor-Access-Only-Bit in dem Port-Mode-Register 1 ist, antwortet der DTC mit *DERR. Das Bit wird gesetzt, um den Grund für die *DERR-Antwort anzuzeigen; ein Parity-Error-Bit. Falls eine Paritätsprüfung durch das Parity-Check- Enable-Bit des Globale-Mode-Registers freigegeben ist, wird das Parity-Error-Bit gesetzt, wenn immer ein Paritätsfehler während eines I/O-Port-Transfers detektiert wird. Paritätseingaben für Signale, die "kümmere-dich-nicht" sind (wegen Byte- oder Halbwort-Datenbreiten), werden ignoriert. Die Parität wird nur für Lesen auf dem Fern-Bus geprüft. Es gibt dort keine Paritätsprüfung bei Daten für Schreiben über den I/O-Port; ein Fern-Bus-Fehler, der gesetzt wird, falls *RBERR während eines I/O-Port-Transfers bestätigt wird; ein Data-Width-Exception-Bit, das gesetzt wird, falls die DSACK0-DSACK1-Antwort zu einem Fern-Bus-I/O-Port- Transfer anzeigt, daß die Fern-Bus-Vorrichtung oder -Speicher einen Transfer der angeforderten Breite nicht bearbeiten kann; und schließlich ein Data-Size- Acknowledge-Feld, das den Wert der jüngsten DSACK0-DSACK1-Antwort für den I/O-Port hält. Falls eine Datenbreite-Ausnahme auftritt, zeigt dieses Feld die Fern-Bus-Antwort an, welche die Ausnahme verursacht hat.
Das Local-Base-Address-Register spezifiziert die Ortsbus-Basis-Adresse des I/O- Ports. Der Adressraum für diesen Port ist durch das Local-Address-Space-Bit des Port-Mode-Registers spezifiziert.
Das Remote-Base-Adress-Register spezifiziert die Remote-Bus-Basis-Adresse des I/O-Ports. Der Adressraum für diesen Port ist durch das Remote-Address-Space- Bit des Port-Mode-Registers spezifiziert.
Das Local-Port-Address-Register hält den Ortsbus für den aktuellen I/O-Port- Zugriff (der ein Lese-Davor-oder-Schreibe-Dahinter sein kann). Diese Adresse kann durch Software benutzt werden, um einen Zugriff, der auf eine Ausnahme trifft, wieder zu starten.
Das Pack-/Funnel-Register puffert Daten, die gerade zu oder vom Fern-Bus transferiert werden. Es dient als eine Daten-Bestimmung oder Daten-Quelle während Pack- und Kanalisier-Operationen auf dem I/O-Port. Für Lese-Davor-und Schreibe-Dahinter dient das Pack-/Funnel-Register als ein Datenpuffer. Für ein Schreiben über den I/O-Port, der auf eine Ausnahme trifft, hält das Pack-/Funnel- Register Daten, die durch Software benutzt werden können, um das Schreiben wieder zu starten.
Der letzte Satz interner Register sind die Queue-Register. Die Queue-Register puffern Daten für DMA-Transfers. Auf diese Register kann durch den Ortsbus- Prozessor zugegriffen werden, um direkt die Inhalte der Warteschlange zu lesen oder zu schreiben. Die Warteschlange-Funktionsweise für jeden Kanal wird im Detail nachfolgend beschrieben.
Dies schließt die detaillierte Beschreibung der Funktion der internen DTC- Register ab. Soweit eine Register-Initialisierung betroffen ist, nachdem der DTC zurückgesetzt ist, haben dessen Register unbestimmte Werte, ausgenommen, daß das Global-Mode-Register auf null gesetzt ist. Dies sperrt alle I/O-Ports und DMA-Kanäle, sperrt Interrupts aus und gibt die *CSEL-Eingabe frei.
Gemäß der bevorzugten Ausführungsform der Erfindung, ist beim Betrieb im Kontext eines RISC-Systems eine Initialisierungsroutine, die auf dem RISC- Prozessor arbeitet, verantwortlich für das Initialisieren der DTC-Register, wie durch das System gefordert. Der Aufbau einer prozessorgetriebenen Initialisierungsroutine liegt ohne weiteres im Rahmen der Kenntnisse von Fachleuten, und entsprechend bildet die Initialisierungsroutine keinen Teil der Erfindung.
Man beachte, daß, bis das Chip-Select-Mapping-Register richtig initialisiert worden ist, auf die internen DTC-Register nur durch Bestätigen der *CSEL-Eingabe zugegriffen werden kann.
Zu diesem Zweck kann *CSEL auf irgendeine systemabhängige Weise bestätigt werden, wie z. B. durch Anschließen eines der A31 - A11-Signale direkt an *CSEL (man beachte, daß dies effektiv ein Bit-signifikantes Adress-Dekodieren zum Zweck eines Initialisierens von DTC-Registern implementiert). Sobald das Chip-Select-Mapping-Register richtig initialisiert ist, kann der DTC für *CSEL unempfindlich gemacht werden und auf Register kann dann unter Verwendung der normalen, durch das System definierten Adressen zugegriffen werden.
Als nächstes werden die durch den neuen DTC unterstützten Datenformate und wie sie bearbeitet werden im Detail dargelegt.
Wie zuvor angezeigt, unterstützt die bevorzugte Ausführungsform des DTC- Wort-(32 Bits), Halbwort-(16 Bits) und Byte-(8 Bit)-Transfers auf dem Fern-Bus.
Datentransfers auf dem Ortsbus sind wortorientiert, obwohl ein Ortsbus-Zugriff, gerichtet an einen I/O-Port, ein Halbwort eines Byte-Zugriffs sein kann.
Es gibt zwei Defacto-Standards zum Adressieren von Bytes und Halbworten innerhalb von Halbworten und Worten. Der DTC unterstützt Peripher- Vorrichtungen beider Standards, unter Verwendung von Konfigurationsoptionen, die nachfolgend beschrieben sind.
Zusätzlich inkorporiert der DTC Vorkehrungen zum Konvertieren von Transfers einer gegebenen Datenbreite auf dem Fern-Bus zu und von Transfers einer größeren Datenbreite auf dem Ortsbus. Für irgendeinen Transfer zwischen den Fern- und Ortsbussen muß die Datenbreite auf dem Ortsbus größer sein oder gleich der Breite von Daten auf dem Fern-Bus. Datenbreite-Konversionen werden durch das zuvor erwähnte Pack- und Kanalisier-Mittel, in Fig. 3 als 304 angegeben, ausgeführt.
Betrachtet man Datenbreiten, speichern die DMA-Warteschlangen von DTCs immer Wortlängendaten, und alle Transfers zwischen dem Ortsbus und DMA- Warteschlangen sind 32-Bit-Transfers. Andererseits können Transfers zwischen dem Fern-Bus und DMA-Warteschlangen Byte-, Halbwort- oder Wort-Transfers sein; Byte- und Halbwort-Transfers schließen die Pack- und Kanalisier-Operationen ein, die in Einzelheiten nachfolgend beschrieben sind.
Transfers zu und von internen DTC-Registern sind immer Wortlängen-Transfers. Byte- und Halbwort-Zugriffe auf DTC-Register werden nicht unterstützt und der DTC antwortet auf einen versuchten Byte- oder Halbwort-Zugriff auf ein internes Register mit einer *DERR-Meldung. Wie vorher angezeigt, wird ein Data-Width- Exception-Bit in das Global-Status-Register durch den DTC gesetzt, um den Grund für die Ausnahme anzuzeigen.
Der DTC erlaubt einen Byte-, Wort- oder Halbwort-Zugriff über einen I/O-Port. Wenn die angeforderte Datenbreite größer ist als die Datenbreite, die durch das geeignete Port-Mode-Register angezeigt ist, behandelt der DTC die Größen- Fehleranpassung unter Verwendung der Pack- und Kanalisier-Operationen, die nachfolgend beschrieben sind.
Betrachtet man zuerst die Ortsbus-Schnittstelle mit dem DTC, wenn der DTC dem Ortsbus untergeordnet ist, wird die Datenbreite des zugeordneten Daten-Transfers durch die OPT0-OPT1-Signale angezeigt. Diese Signale reflektieren das OPT- Feld des RISC-Prozessor-Lade-oder-Speicher-Befehls, definiert in der einbezogenen anhängigen Anmeldung, welcher den Transfer durchführt. Das Kodieren der OPT0-OPT1-Signale wurde zuvor dargelegt.
Falls der DTC einen Zugriff auf eine gegebene Breite nicht unterstützen kann (möglicherweise, weil der Fern-Bus den Zugriff nicht unterstützten kann), antwortet er auf den Zugriff mit einer *DERR-Meldung. Das Data-Width-Exception- Bit entweder des Global-Status-Registers oder des Port-Status-Registers, je nach Eignung, wird gesetzt, um den Grund für die Ausnahme anzuzeigen.
Mit Bezugnahme auf Fern-Bus-Datenbreiten für einen DMA-Transfer auf dem Fern-Bus wird die Datenbreite des Transfers durch das Data-Width-Feld des zugeordneten Channel-Mode-Registers (zuvor beschrieben) spezifiziert.
Für einen I/O-Port-Transfer ist die Datenbreite des Transfers gemäß der bevorzugten Ausführungsform der Erfindung durch eine Kombination des Data-Width- Feldes des zugeordneten Port-Mode-Registers und der OPT0-OPT1-Eingaben auf dem Ortsbus spezifiziert.
Die Datenbreite für einen Fern-Bus-Transfer wird auf den DSIZE0-DSIZE1- Ausgaben reflektiert, wenn der Transfer auftritt. Wenn der angeforderte Transfer durch den Fern-Bus nicht unterstützt ist (weil die Vorrichtung oder der Speicher auf dem Fern-Bus nicht ausreichend breit ist), antwortet der Fern-Bus eine DSACK0-DSACK1-Antwort, welche die gerade unterstützte Datenbreite anzeigt. Dies bewirkt eine Datenbreite-Ausnahme. (Das *RBERR-Signal kann ebenso verwendet werden, um eine Ausnahme zu erzeugen, wird jedoch den Grund nicht isolieren.)
Wenn ein DMA-Transfer auf eine Datenbreite-Ausnahme trifft, wird der Transfer gestrichen und *INTR wird angegeben, wenn Interrupts freigegeben sind.
Wenn ein I/O-Zugriff auf eine Datenbreite-Ausnahme trifft, antwortet der DTC auf dem Ortsbus mit einer *DERR-Meldung. Im Fall von Lese-Davor und- Schreibe-Dahinter signalisiert *DERR, daß eine Ausnahme auf dem jüngsten Zugriff durch den korrespondierenden I/O-Port aufgetreten ist.
Wenn eine Ausnahme durch eine DSACK0-DSACK1-Antwort verursacht ist, wird der Status der DSACK0-DSACK1-Eingaben, die mit der Ausnahme verbunden sind, in dem Data-Size-Acknowledge-Feld des Channel-Status- oder Port- Status-Registers, das dem Transfer zugeordnet ist, gespeichert (die DSACK0- DSACK1-Antwort wird für jede Ausnahme gespeichert). Dies kann es dem Inerrupt- oder Trap-handler ermöglichen, den Zugriff mit der richtigen Datenbreite erneut zu versuchen:
Für eine Fern-Bus-Vorrichtung oder -Speicher ist es möglich, eine DSACK0- DSACK1-Antwort zu geben, die anzeigt, daß er eine breitere Datenbreite als angefordert, unterstützt. In diesem Fall behandelt der DTC den Zugriff immer noch als einen mit der angeforderten Breite.
Im folgenden wenden wir uns Betrachtungen der Daten-Ausrichtung zu. Adressen sowohl auf den Orts- und Fern-Bussen sind dadurch Byte-Adressen, daß sie ausreichend sind ein Byte in einer Vorrichtung oder in einem Speicher, die irgendeinem der Busse angefügt sind, auszuwählen. Wenn auf ein Halbwort oder ein Wort zugegriffen wird, wird die entsprechende Adresse normalerweise so ausgerichtet, daß sie auf das erste Byte in dem Halbwort oder Wort zeigt. Eine ausgerichtete Halbwort-Adresse hat eine 0 in dem niederstwertigen Bit und eine ausgerichtete Wortadresse hat 00 in den zwei niederstwertigen Bits.
Der DTC erzwingt eine Ausrichtung für alle Halbwort- und Wort-Zugriffe durch Interpretieren des einzigen oder der zwei niederstwertigen Bits einer Adresse als 0 (wie geeignet), ohne Rücksicht auf die momentanen Werte. Dies ist im Gegensatz zu einigen Systemen, die derartige Zugriffe als nicht ausgerichtete Zugriffe interpretieren, welche Mehrfach-Datenzugriffe mit Verschieben, Ausrichten und Verketten erfordern. Wenn derartige Zugriffe unterstützt werden müssen, müssen sie durch den Non-Aligned-Access-Trap in dem RISC-System, dem der hier beschriebene DTC angefügt ist, abgeschnitten werden.
In Fällen, in welchen auf ein Byte als Teil eines Halbwortes oder Wortes zugegriffen wird, oder in welchen auf ein Halbwort als Teil eines Wortes zugegriffen wird, ist der Ort des Bytes oder Halbwortes innerhalb des Halbwortes oder Wortes durch eine von zwei etablierten Konventionen bestimmt. Diese Konventionen verbinden den Ort des Bytes oder Halbwortes mit seiner entsprechenden Adresse und sind in Fig. 4 gezeigt.
In Fig. 4 werden die folgenden Numerierungskonventionen benutzt:
1. Bytes innerhalb von Halbworten sind entsprechend den niederstwertigen Bits der entsprechenden Adresse numeriert.
2. Bytes innerhalb von Worten sind entsprechend den zwei niederstwertigen Bits der entsprechenden Adresse numeriert.
3. Halbworte sind entsprechend dem Bit, das am nächsten zum niederstwertigen Bit der entsprechenden Adresse ist, numeriert.
In einem RISC-System kann eine der in Fig. 4 gezeigten Konventionen auf den Ortsbus angewandt werden und eine oder beide können auf den Fern-Bus angewandt werden. Daher unterstützt der DTC beide Konventionen mit Umwandlungen zwischen diesen.
Das Local-Byte-Order-("LBO")-Bit des Global-Mode-Registers spezifiziert, welche der ordnenden Konventionen für den Ortsbus zutrifft, wie in Fig. 4 gezeigt. Falls das LBO-Bit 0 ist, werden Bytes und Halbworte sequentiell links-nach- rechts innerhalb von Halbworten und Worten adressiert. Falls das LBO-Bit 1 ist, sind sie sequentiell rechts-nach-links adressiert. Man beachte, daß nur eine Konvention für alle Transfers auf dem Ortsbus möglich ist.
Das Remote-Byte-Order-("RBO")-Bit der Channel-Mode- oder Port-Mode- Register spezifiziert, welche der ordnenden Konventionen auf den Fern-Bus anwendbar ist, auf einer Kanal-für-Kanal- oder einer Port-für-Port-Basis. Wenn das RBO-Bit 0 ist, werden Bytes und Halbworte sequentiell links nach rechts innerhalb von Halbworten und Worten adressiert. Wenn das RBO-Bit 1 ist, werden sie sequentiell rechts-nach-links adressiert.
Im allgemeinen steuert das LBO-Bit die Byte- und Halbwort-Auswahl während der Pack- und Kanalisier-Operationen. Wenn das LBO-Bit 0 ist, schreiten Packen und Kanalisieren links-nach-rechts für sequentiell ansteigende Adressen fort. Wenn das LBO-Bit 1 ist, schreiten Packen und Kanalisieren rechts-nach-links für sequentiell ansteigende Adressen fort. Man beachte, daß die Reihenfolge für sequentiell abnehmende Adressen umgekehrt ist.
Das RBO-Bit steuert die Ortung von Daten auf dem Fern-Bus für jene Fälle, in welchen der Byte- und Halbwort-Ort von der Adresse abhängen. Zusätzlich, wenn ein DMA-Kanal- oder I/O-Port an einem Transfer beteiligt ist, wird das RBO-Bit für das zugeordnete Channel-Mode- oder Port-Mode-Register mit dem LBO-Bit verglichen. Wenn das ausgewählte RBO-Bit mit dem LBO-Bit nicht zusammenpaßt und die transferierten Daten breiter sind als ein Byte, werden Bytes innerhalb des Halbwortes oder Wortes umgelagert, um zwischen den zwei Adressier- Konventionen zu konvertieren. Dieses Umlagern ist graphisch in Fig. 5 dargestellt.
In Fig. 5 sind Bytes mit Buchstaben gekennzeichnet (anstelle von Nummern), um zu verdeutlichen, daß ein Umlagern von einer Adressier-Konvention in die andere konvertiert.
Die Art und Weise, auf welche Pack- und Kanalisier-Operationen durch den DTC unterstützt werden, wird nun beschrieben.
Unter Bezugnahme auf ein Packen bei einem Fern-zu-Lokal-Transfer kann der DTC eine Anzahl von Byte- oder Halbwort-Transfers auf dem Fern-Bus in eine kleinere Anzahl von Halbwort- oder Wort-Transfers auf dem Ortsbus konvertieren. Dies wird durch ein Packen von Bytes oder Halbwörtern in Halbworte oder Worte erreicht. Man sollte sich daran erinnern, daß Bytes nur für einen I/O-Port- Zugriff in ein Halbwort gepackt werden können.
Jeder DTC-DMA-Kanal und -I/O-Port hat, wie zuvor angezeigt, ein zugeordnetes 32-Bit-Pack-/Funnel-Register. Dieses Register unterstützt die Pack-Operation durch ein Sammeln von Bytes oder Halbworten, bis die erforderliche Menge von Daten gesammelt wurde (die erforderliche Datenbreite ist normalerweise ein Wort, kann aber ein Halbwort im Fall eines I/O-Port-Zugriffs sein). Wenn die Daten in dem Pack-/Funnel-Register die erforderliche Breite erreichen, werden sie von dem Pack-/Funnel-Register zur richtigen DMA-Warteschlange (für einen DMA-Kanal) oder dem Ortsbus (für einen I/O-Port) übertragen. Wenn die Daten einmal aus dem Pack-/Funnel-Register entfernt sind, können weitere Pack- Operationen fortschreiten.
Orts- und Fern-Bus-Transfers während Pack-Operationen treten auf, wie in der folgenden Tabelle dargelegt:
Man beachte, daß alle Daten, die von dem Fern-Bus zu dem Ortsbus transferiert werden, in dem geeigneten Pack-/Funnel-Register gepuffert sind, selbst in Fällen, in welchen die Datenbreite auf dem Fernbus mit der Datenbreite auf dem Ortsbus zusammenpaßt.
In Ausnahmefällen kann die Pack-Operation gestrichen werden, bevor die erforderliche Datenbreite erreicht ist. Diese Fälle treten auf, wenn es eine Ausnahme während eines Transfers gibt (z. B. ein Partitätsfehler), oder wenn der Fern-Bus- Transfer endet, bevor die Pack-Operation ein Wort erzeugt hat (z. B. wenn eine ungerade Anzahl von Bytes auf einem DMA-Kanal übertragen wird). Wenn die Pack-Operation eine Dateneinheit der erforderlichen Breite nicht erzeugen kann, wird der Rest des Halbwortes oder Wortes gemäß der bevorzugten Ausführungsform der Erfindung mit Nullen aufgefüllt.
Mit Bezugnahme auf ein Kanalisieren für einen Lokal-zu-Fern-Transfer, kann der DTC eine Anzahl von Wort- oder Halbwort-Transfers auf dem Ortsbus in eine größere Anzahl von Halbwort- oder Byte-Transfers auf dem Fern-Bus konventieren. Dies wird durch Kanalisieren von Daten innerhalb eines Wortes oder Halbwortes in eine Sequenz von Halbwort- oder Byte-Transfers erreicht. Man beachte, daß ein Halbwort nur für einen I/O-Port-Zugriff in Bytes kanalisiert wird).
Das Pack-/Funnel-Register akzeptiert Daten von einer DMA-Warteschlange (für einen DMA-Kanal) oder von dem Ortsbus (für einen I/O-Port) und puffert sie während der Kanalisier-Operation. Kanalisieren extrahiert Halbworte oder Bytes, eines nach dem anderen, aus dem Pack-/Funnel-Register und transferiert sie individuell auf den Fern-Bus. Wenn alle Daten in dem Pack-/Funnel-Register transferiert worden sind, kann das Pack-/Funnel-Register mit mehr zu transferierenden Daten beschrieben werden.
Orts- und Fern-Bus-Transfers während Kanalisier-Operationen treten auf dieselbe Art, wie während eines Packens, mit der Tabelle von Datenbreiten und Anzahl von Transfers, wie zuvor dargelegt, auf.
Man beachte auch, daß alle von dem Ortsbus zu dem Fern-Bus transferierten Daten in dem geeigneten Pack-/Funnel-Register gepuffert sind, selbst in Fällen, wo die Datenbreite des Ortsbusses mit der Datenbreite auf dem Fern-Bus zusammenpaßt.
In Ausnahmefällen kann die Kanalisier-Operation abgebrochen werden, bevor die Daten in dem Pack-/Funnel-Register ausgeschöpft worden sind. Diese Fälle treten auf, wenn es einen Fehler während eines Transfers (z. B. einen Paritätsfehler) gibt, oder wenn der Fern-Bus-Transfer endet, bevor die Kanalisier-Operation alle Halbworte oder Worte von dem Pack-/Funnel-Register übertragen hat (z. B. wenn eine ungerade Anzahl von Bytes auf einem DMA-Kanal transferiert wird). In je dem dieser Fälle werden gemäß der bevorzugten Ausführungsform der Erfindung irgendwelche nicht transferierte Daten in dem Pack-/Funnel-Register ignoriert.
Nachdem beschrieben wurde, wie der DTC Daten und die unterstützten Formate handhabt, wendet sich die Beschreibung des DTC jetzt dazu, wie er programmierte I/Os unterstützt.
Der Ausdruck "programmierte I/O", wie er hier verwendet wird, beschreibt irgendeinen DTC-Zugriff oder Daten-Transfer, der das direkte Ergebnis einer Ausführung eines Lade- oder Speicherbefehls durch den RISC-Prozessor ist. Dieser Ausdruck sollte nicht mit einem Zugriff auf den RISC-System-I/O-Adressraum verwechselt werden, weil der DTC programmierte I/Os entweder in dem Datenspeicher oder dem I/O-Adressraum des RISC-Systems unterstützt.
Der DTC unterstützt zwei Typen programmierter I/Os: interne und entfernte. Ein intern programmierter I/O wird benutzt, um auf DTC-interne Register zuzugreifen. Fern-I/O wird benutzt, um auf Daten auf dem Fern-Bus zuzugreifen, auf eine Weise, die mit der Programmausführung gekoppelt ist (im Gegensatz zu DMA, die normalerweise entkoppelt ist).
Wie zuvor angemerkt, werden Zugriffe auf interne DTC-Register durch das Chip- Select-Mapping-Register gesteuert. Dieses Register spezifiziert die Basisadresse für interne Register und ob diese Adresse in dem Datenspeicher- oder I/O- Adressraum des RISC-Systems ist. Es gibt auch die *CSEL-Eingabe frei und sperrt sie; die Basisadresse ist irrelevant, immer wenn *CSEL freigegeben ist.
Wenn *CSEL freigegeben ist, antwortet der DTC auf irgendeinen internen Zugriff, für den die *CSEL-Eingabe aktiv ist. Dieser Zugriff kann entweder im Datenspeicher- oder I/O-Adressraum des Ortsbusses sein. Wenn *CSEL gesperrt ist, antwortet der DTC auf einen Zugriff, der die folgenden Kriterien erfüllt:
1. Bit 31 - 11 der Adresse für den Zugriff passen mit entsprechenden Bits des Chip-Select-Address-Feldes des Chip-Select-Mapping-Registers zusammen.
2. Der Adressraum (Datenspeicher oder I/O) für den Zugriff paßt mit dem zusammen, der durch das Local-Address-Space-Bit des Chip-Select- Mapping-Registers spezifiziert ist.
Wenn die obigen Kriterien erfüllt sind, benutzt der DTC den Offset-Teil der Adresse (Bits 10 - 2), um ein internes Register auszuwählen. Alle Zugriffe auf DTC-interne Register sind Wortlänge-Zugriffe und der DTC antwortet mit *DERR, wenn die OPT0-OPT1-Signale nicht 00 für einen internen Registerzugriff sind (das Data-Width-Exception-Bit oder das Global-Status-Register zeigt den Grund für die Ausnahme an). In jedem Fall werden die A1-A0-Signale ignoriert.
Für ein Laden (R/*W HIGH) werden die Inhalte des ausgewählten Registers an den Ortsbus gesandt. Ein nicht implementiertes Register-Bit wird als 0 gelesen. Für ein Speichern (R/*W LOW) werden in das ausgewählte Register die Inhalte der D31-D0-Zeilen geschrieben. Jede der D31-D0-Zeilen entsprechend einem nicht implementierten Register-Bit wird ignoriert, jedoch gemäß der bevorzugten Ausführungsform sollte sie mit Rücksicht auf eine Aufwärts-Kompatibilität 0 sein.
Der DTC schließt einen Zugriff nicht erfolgreich ab, obwohl er auf den Zugriff antwortet, wenn irgendeine der folgenden Bedingungen zutrifft:
1. Der DTC ist in dem Benutzer-Modus, wie durch eine SUP/*US-Ausgabe, die LOW ist, angezeigt ist.
2. Die Adresse für den Zugriff ist innerhalb des Bereichs von Adressen, die durch den DTC erkannt sind, jedoch wählt der Offset nicht ein implementiertes Register aus.
In jedem der obigen Fälle antwortet der DTC auf den Zugriff mit einem *DERR- Anzeige. Das Protection-Violation- oder Access-Error-Bit (je nach dem) des Global-Status-Registers wird gesetzt, um den Grund für die *DERR-Antwort anzuzeigen.
Wo passend, kann der DTC einen Burst-Mode-Zugriff in Antwort auf einen RISC-Prozessor-Lade-Mehrfach oder Speichere-Mehrfach-Befehl ausführen. Der DTC beinhaltet die geeignete Adress-Inkrementier-Logik, um den Burst-Mode- Zugriff richtig zu unterstützen. Jedoch können Burst-Mode-Zugriffe nur benutzt werden, um auf Register mit aneinandergrenzenden Offset-Werten zuzugreifen. Wenn in der Burst-Mode-Sequenz irgendein nicht implementiertes Register angetroffen wird, antwortet der DTC mit einer *DERR-Meldung, die den Zugriff streicht.
Es ist möglich, einen DMA-Kanal so zu konfigurieren, daß sein Bereich von Ortsbus-Adressen den Bereich von Adressen für DTC-interne Register überlappt. Jedoch unterstützt der DTC keine internen Register-Zugriffe durch DMA-Kanäle. Wenn ein derartiger Zugriff versucht wird, tritt ein Adress-Konflikt auf und der DMA-Transfer wird gestrichen. Das Address-Conflict-Bit des geeigneten Channel-Status-Registers wird gesetzt, um den Grund für die Ausnahme anzuzeigen.
Der Überblick über die Erfindung, mit Bezugnahme auf Fig. 3, legte dar, daß ein fern-programmmierter I/O über einen DTC-I/O-Port es einem RISC-Prozessor, der dem Ortsbus angefügt ist, ermöglicht, auf Vorrichtungen und Speicher auf dem Fern-Bus zuzugreifen. Die Details, wie ein fernprogrammierter I/O unter Verwendung des DTC erreicht wird, werden nun dargelegt.
Der DTC inkorporiert vier unabhängige I/O-Ports für Fern-Bus-Zugriffe. Jeder I/O-Port:
1. bildet einen Zweierpotenz-Bereich der Ortsbus-Adressen auf einen unabhängigen Bereich von Fern-Bus-Adressen ab;
2. unterstützt Bytes-, Halbwort- und Wort-Zugriffe, und
3. beinhaltet Einrichtungen für Fern-Bus-Zugriffe, die mit anderen RISC- Prozessor-Operationen überlappen.
Fern-programmierte I/O-Zugriffe werden durch die I/O-Port-Register gesteuert. Es gibt vier identische Sätze von Registern (einen Satz pro I/O-Port), die zuvor beschrieben wurden.
Wie zuvor angezeigt, akzeptieren die I/O-Ports Zugriffe von dem Ortsbus und geben sie zum Fern-Bus weiter. Eine Adress-Übersetzung wird zwischen den Orts- und Fern-Bussen durchgeführt. Die Pack- und Kanalisiser-Operationen ermöglichen es, daß die Datenbreite für die Ortsbus-Anforderung größer ist als die Datenbreite für die Fern-Bus-Anforderung.
Die Verbindung zwischen den Orts- und Fern-Bussen kann direkt oder entkoppelt sein. In dem Fall einer direkten Verbindung muß der Fern-Bus-Zugriff abschließen, bevor der Ortsbus-Zugriff abschließen kann. In dem Fall eines entkoppelten Zugriffs werden Daten gepuffert, so daß der Ortsbus-Zugriff die Ergebnisse eines vorherigen Fern-Bus-Lesens liest, oder Daten für das nächste Fern-Bus-Schreiben schreibt, unabhängig von der Fern-Bus-Operation. Wenn eine Anforderung von einem I/O-Port für den Fern-Bus gleichzeitig mit einer Anforderung von einem DMA-Kanal, hat der I/O-Port Priorität.
Zugriffe über I/O-Ports werden durch das Local-Base-Address-Register, das jedem I/O-Port zugeordnet ist, gesteuert. Dieses Register spezifiziert die Ortsbus- Basis-Adresse des jeweiligen I/O-Ports und ob diese Adresse in dem Datenspeicher- oder I/O-Adress-Raum des RISC-Systems ist.
Ein I/O-Port wird aktiv, immer wenn die folgenden Bedingungen zutreffen:
1. Das richtige Port-Enable-Bit in dem Global-Mode-Register ist gesetzt.
2. Die richtigen Bits hoher Ordnung der Ortsbus-Adresse passen mit entsprechenden Bits des Local-Base-Address-Registers zusammen.
3. Der Adress-Raum (Datenspeicher oder I/O für den Zugriff paßt mit jenem zusammen, der durch das Local-Address-Space-Bit des Port-Mode- Registers spezifiziert ist.
Man erinnere sich daran, daß die *CSEL-Eingabe keine Wirkung auf I/O-Port- Zugriffe hat.
Wenn die obigen Kriterien zutreffen, ersetzt der DTC die Bits hoher Ordnung der lokalen Adresse, die in dem obigen Bit-Vergleich benutzt wurde, mit entsprechenden Bits des Remote-Base-Address-Registers; die Bits niedriger Ordnung (d. h. der Port-Offset) sind unverändert. Die resultierende Adresse für den Fern- Bus-Zugriff wird entweder im Speicher oder im I/O-Raum des Fern-Busses benutzt, wie durch das Remote-Address-Space-Bit des Remote-Base-Address- Registers bestimmt ist. Fig. 6 veranschaulicht den Adress-Übersetzungsprozeß und zeigt den Datenfluß für einen I/O-Port an.
Fig. 6 zeigt eine 32-Bit-Ortsbus-Adresse, die auf Leitung 601 zum Local-Port- Address-Register 602 eingegeben ist. Daten von D0-D31 (und Parität-Bits D0- D3) können entweder zu oder von dem Pack/Kanalisier-Netzwerk-Mittel (Mittel 304, wie in Fig. 3 gezeigt) über einen MUX 603 und ein Pack/Funnel-Register 604 fließen, die beide Teil I/O-Ports mit Bezug zur Fig. 6 sind.
Eine Adress-Übersetzung findet statt, durch zuerst Bestimmen, ob der Zugriff innerhalb des Adress-Raumes des Ports ist (über Block 605) und, wenn dem so ist, durch Übersetzen der Adresse (über Block 606).
In Block 605 werden die Inhalte des Local-Base-Address-Registers 620 mit den Inhalten des Local-Port-Address-Registers 602 (über einen Komperator 625) verglichen, nachdem Bits für den Vergleich, basierend auf der Größe des Ports, ausgewählt sind (über Block 623 und 624). Zum Beispiel für einen 1 Kilo-Byte-Port werden die Bits hoher Ordnung 22 von Registern 602 und 620 verglichen. Die Fenstergröße-Information stammt, wie zuvor angemerkt, von dem Window-Size- Feld des Port-Mode-Registers.
Wenn der I/O-Port tatsächlich adressiert ist, tritt eine Adress-Übersetzung über Block 606 durch Ausmaskieren (wiederholtes Benutzen der Fenster-Größe- Information), über Block 680, der geeigneten Bits hoher Ordnung von der Ortsbus-Adresse und schließlich durch vereinigen der restlichen Bits niedriger Ordnung mit den Bits hoher Ordnung auf, durch Ausmarkieren derselben Anzahl von Bits niedriger Ordnung von der Fern-Basis-Adresse in Register 688. Diese zweite Maske wird durch Block 689 ausgeführt.
Als ein Ergebnis des Vereinigens, das durch Block 690 durchgeführt gezeigt ist (in Fig. 6), wird die Fern-Bus-Adresse entwickelt. Für das 1 Kilo-Byte-Fenster- Beispiel, auf das oben Bezug genommen wird, wird die übersetzte Adresse ihre Bits hoher Ordnung 22 aus den Inhalten des Remote-Base-Address-Registers haben und Bits niedriger Ordnung 10 von dem Local-Port-Address-Register, wobei tatsächlich der geeignete Port-Offset bei dem Adress-Übersetzungsprozess beibehalten wird.
Es ist möglich, daß der Bereich lokaler Adressen für einen gegebenen I/O-Port den Bereich von Adressen für einen anderen Port überlappt. Wenn dies geschieht, hat der I/O-Port mit der niedrigsten Nummer Priorität bei der bevorzugten Ausführungsform der Erfindung. Zum Beispiel, wenn der Adress-Bereich für I/O-Port 0 den Adress-Breich für I/O-Port 2 überlappt, hat der I/O-Port 0 Priorität. Der Bereich von Fern-Adressen für einen I/O-Port kann ebenso jenen eines weiteren I/O-Ports überlappen. Doch gibt es dort keine Konkurrenz, da nur ein I/O-Port auf dem Fern-Bus zu irgendeiner Zeit aktiv sein kann.
Das Supervisor-Access-Only-("SUP")-Bit des Port-Mode-Registers, das jedem Port zugeordnet ist, bestimmt, ob auf den Port durch ein Benutzer-Modus- Programm zugegriffen werden kann oder nicht. Wenn ein Benutzer-Modus- Zugriff (wie durch das SUP/*US-Signal angezeigt ist) auf einen I/O-Port versucht ist, dessen SUP-Bit 1 ist, führt der DTC den angeforderten Fern-Bus-Zugriff nicht durch. Er antwortet auf den Zugriff mit einer *DERR-Anzeige. Das Protection- Violation-Bit des relevanten Port-Status-Registers ist gesetzt, um den Grund für die *DERR-Antwort anzuzeigen.
Es ist möglich, einen DMA-Kanal so zu konfigurieren, daß sein Bereich von Ortsbus-Adressen den Bereich von Adressen für einen I/O-Port überlappt. Jedoch unterstützt der DTC keine I/O-Port-Zugriffe über DMA-Kanäle. Wenn ein derartiger Zugriff versucht wird, tritt ein Adress-Konflikt auf und der DMA-Transfer wird gestrichen. Das Address-Conflict-Bit des geeigneten Channel-Status- Registers wird gesetzt, um den Grund für die Ausnahme anzuzeigen.
Die normale Betriebsweise eines jeden I/O-Ports ist wie folgt:
Für ein Laden (R/*W HIGH), das an einen I/O-Port gerichtet ist, führt der DTC einen Lese-Zugriff auf dem Fern-Bus aus (Mehrfach-Lesen kann auftreten, wenn ein Packen erforderlich ist) und die zugegriffenen Daten werden in Antwort auf das Laden zurückgeben. Wenn eine Ausnahme während des Fern-Bus-Zugriffs auftritt (z. B. wegen einer *RBERR-Antwort oder eines Paritätsfehlers) antwortet der DTC mit *DERR auf dem Ortsbus. Im Fall einer *DERR-Antwort zeigt das relevante Port-Status-Register den Grund an.
Für ein Speichern (R/*W LOW), das an einen I/O-Port gerichtet ist, führt der DTC einen Schreibe-Zugriff auf dem Fern-Bus unter Benutzung von Daten aus, die für das Speichern geliefert sind (Mehrfach-Schreiben kann auftreten, wenn ein Kanalisieren erforderlich ist). Wenn eine Ausnahme während des Fern-Bus- Zugriffs auftritt, antwortet der DTC mit einer *DERR auf dem Ortsbus. Im Fall einer *DERR-Antwort gibt das relevante Port-Status-Register den Grund an.
Dort, wo es geeignet ist, kann der DTC einen Burst-Mode-Zugriff über einen I/O- Port durchführen, in Antwort auf einen RISC-Prozessor-Lade-Mehrfach- oder Speichere-Mehrfach-Befehl. Der DTC beinhaltet die geeignete Adress- Inkrementier-Logik, um den Burst-Mode-Zugriff richtig zu unterstützen. Auf dem Fern-Bus wird dieser Transfer als ein Block-Modus durchgeführt.
Burst-Mode-Zugriffe können nur dazu benutzt werden, um auf Daten mit aneinander grenzenden Wort-Adressen auf dem Ortsbus zuzugreifen. Die Datenbreite auf dem Ortsbus sollte 32 Bit sein. Packen und Kanalisieren kann diese Wort- Zugriffe auf oder von Zugriffen einer schmäleren Breite auf dem Fern-Bus konvertieren, mit der Einschränkung, daß ein geradzahliges Vielfaches von 4 Bytes, oder 2 Halb-Worten übertragen werden muß (entsprechend der bevorzugten Ausführungsform der Erfindung).
Wenn das *LOCK-Signal für ein I/O-Port-Lesen aktiv ist, führt der DTC einen Lese-Modifizier-Schreibe-Zugriff auf dem Fern-Bus durch. Dieser Zugriff wird von anderen Fern-Bus-Zugriffen dadurch unterschieden, daß die *RMW-Ausgabe am Anfang des Lese-Zugriffs bestätigt ist. *RMW wird aktiv gehalten, bis der Schreibe-Zugriff die Lese-Modifizier-Schreibe-Sequenz abschließt.
Der DTC führt kein spezielles implizites Sequenzieren als das Ergebnis des *LOCK-Signals durch, sondern handelt einfach dadurch, so daß er das durch den RISC-Prozessor-Lade- und Einstell-Befehl durchgeführte Sequenzieren zum Fern- Bus durchleitet. Somit tritt das Schreiben, das die Lese-Modifizier-Schreibe- Sequenz abschließt, als das Ergebnis eines Schreibens auf dem Ortsbus auf.
Obwohl andere Synchronisier-Protokolle durch Fachleute konzipiert werden können, kann die bevorzugte Ausführungsform der Erfindung, beschrieben mit Bezugnahme auf das RISC-System in der hier enthaltenen anhängigen Anmeldung, nur die Lade- und Setz-Semantik des RISC-Prozessors implementieren und unterstützt nicht ausdrücklich irgendein anderes Synchronisier-/Ausschluß-Protokoll.
Wenn das Overlapped-I/O-(OIO)-Bit des Port-Mode-Registers gesetzt ist, führt der zugeordnete I/O-Port Lese-Davor und Schreibe-Danach-Operationen aus, anstelle von direkten Lesen und Schreiben zu dem Fern-Bus. Diese speziellen Operationen ermöglichen es dem Fern-Bus-Prozessor andere Operationen mit Fern- Bus-Zugriffen zu überlappen.
Fig. 7 zeigt ein Fluß-Diagramm für Lese-Davor und Schreibe-Danach- Operationen. Beim Darlegen der Beschreibung überlappender I/Os wird auf Blöcke 701-709 von Fig. 7 Bezug genommen.
Wenn das OIO-Bit eines Port-Mode-Registers zuerst gesetzt ist (Block 701 in Fig. 7) wird der zugeordnete I/O-Port in einen solchen Status gesetzt, daß er unmittelbar auf den nächsten Zugriff antworten wird, anstelle von auf den durchzuführenden Fern-Bus-Zugriff (Block 702) zu warten. Wenn der nächste Zugriff ein Laden (Lesen) ist, antwortet der I/O-Port (Block 703) mit den Inhalten seines Pack/Funnel-Registers (die sehr wahrscheinlich nicht definiert sind). Wenn der nächste Zugriff ein Speichern (Schreiben) ist, speichert der I/O-Port die zugeordneten Daten in dem Pack/Funnel-Register (Block 704). Sowohl für Laden als auch für Speichern puffert der I/O-Port die Adressen für den Zugriff in dem Local-Port- Address-Register (Block 709).
Der Ortsbus-Zugriff schließt dann ab (*DRDY zurückgesandt, siehe Blocks 703 und 705), unabhängig von irgendeinem Zugriff auf den Fern-Bus. Jedoch ist der I/O-Port in einem derartigen Zustand, daß er den erforderlichen Fern-Bus-Zugriff bei der frühesten Gelegenheit durchführt (die von einer Fern-Bus-Entscheidung oder einer anderen DTC-Aktivität abhängen kann).
Um Lese-Davor oder Schreibe-Danach durchzuführen, übersetzt der I/O-Port die Adresse in dem Local-Port-Address-Register (dieses Register enthält eine nicht übersetzte Adresse, um ein Wiedergewinnen im Fall einer Ausnahme zu ermöglichen, ohne eine wiederholte Übersetzung zu erfordern). Dann führt der I/O-Port für ein Lese-Davor ein Fern-Bus-Lesen (Block 706) unter Benutzung der übersetzten Adresse durch. Die Daten für dieses Lesen sind in dem Pack/Funnel- Register (Block 707) gespeichert, wenn das Lesen abschließt (man beachte, daß ein Packen durchgeführt werden kann). Für ein Schreibe-Danach, führt der I/O- Port ein Fern-Bus-Schreiben (Block 708) unter Benutzung der übersetzten Adresse durch. Die Daten für dieses Schreiben werden durch das Pack/Funnel-Register geliefert (und ein Kanalisieren kann durchgeführt werden).
Während der I/O-Port ein Lese-Davor oder Schreibe-Danach auf dem Fern-Bus durchführt, akzeptiert er keinen zweiten Zugriff von dem Ortsbus (obwohl er DTC-Zugriffe auf andere I/O-Ports interner Register akzeptieren kann). Der I/O- Port akzeptiert einen zweiten Ortsbus-Zugriff nur nachdem der Fern-Bus-Zugriff abgeschlossen ist. Normalerweise ist der zweite Zugriff von demselben Typ (Lesen oder Schreiben) wie der erste. Wenn ein Zugriff auf einen anderen I/O-Port aktiv wird, bevor das Lese-Davor oder Schreibe-Danach begonnen hat (d. h. wenn es dort einen weiteren Zugriff gibt, der um den Fern-Bus konkurriert), wird der zweite Zugriff aufgehalten, bis der erste abgeschlossen ist.
In dem Fall von Lese-Davor erhält das zweite Lesen zu demselben I/O-Port die Daten von dem ersten Lesen und liefert eine Adresse für ein zweites Fern-Bus- Lesen. In dem Fall von Schreibe-Danach puffert das zweite Schreiben zu demselben I/O-Port zusätzliche Daten und eine zweite Adresse für ein zweites Fern-Bus- Schreiben. In beiden Fällen, falls eine Ausnahme während des ersten Fern-Bus- Zugriffs aufgetreten ist, antwortet der DTC auf den zweiten Ortsbus-Zugriff mit einer *DERR-Meldung (das relevante Port-Status-Register zeigt den Grund für die Ausnahme an).
Die Sequenz von Lese-Davor und Schreibe-Danach-Operationen schreitet fort, bis alle Zugriffe abgeschlossen worden sind. Man beachte, daß, während ein Schreibe-Danach ein relativ einfaches Verhalten zeigt, ein Lese-Davor einen zusätzlichen Zugriff am Anfang und am Ende der Sequenz erfordert, um alle Daten zu transferieren. Lese-Davor erfordert ein anfängliches Ortsbus-Lesen, um die Daten für das erste Fern-Bus-Lesen zu liefern. Darüber hinaus erzeugt das letzte Ortsbus-Lesen in der Sequenz einen Zugriff auf den Fern-Bus, obwohl dieser Zugriff nicht notwendig ist.
Lesen und Schreiben kann nicht effektiv während Lese-Davor und Schreibe- Danach vermischt werden. Wenn ein Lesen zu einem Port durchgeführt wird, der davor ein Schreibe-Danach durchgeführt hat, sind die erhaltenen Daten undefiniert. Wenn ein Schreiben zu einem Port durchgeführt wird, der davor ein Lese- Davor durchgeführt hat, sind die in dem Pack/Funnel-Register gehaltenen Daten zerstört. Gemäß der bevorzugten Ausführungsform der Erfindung ist Software für ein Erzeugen der korrekten Sequenz von Lesen und Schreiben für die gewünschte Operation verantwortlich. Man beachte insbesondere, daß eine Lese-Modifizier- Schreibe-Sequenz nicht richtig durch einen Port durchgeführt werden kann, der konfiguriert ist, Lese-Davor oder Schreibe-Danach durchzuführen.
Wenn es erwünscht ist Lesen und Schreiben zu vermischen, unter Benutzung von Lese-Davor und Schreibe-Danach, müssen zwei I/O-Ports benutzt werden. Ein I/O-Port wird für Lese-Davor benutzt und ein weiterer für Schreibe-Danach. Man beachte jedoch, daß die Höchstleistung durch die Kapazität des Fern-Busses begrenzt sein kann.
Um die Beschreibung des programmierten I/Os, der durch den DTC unterstützt ist, abzuschließen, sei angemerkt, daß eine Anzahl von Ausnahmen während eines programmierten I/O-Transfers auftreten kann, die ein erfolgreiches Abschließen des Transfers verhindern. Wenn eine Ausnahme während eines programmierten I/O-Transfers auftritt, antwortet der DTC auf dem Ortsbus mit einer *DERR- Anzeige.
Die folgenden Ausnahmen, wo anwendbar in Reihenfolge mit Priorität, können während eines programmierten I/O-Transfers auftreten:
1. Protection Violation. Ein Benutzer-Modus-Programm (gekennzeichnet durch das SUP/*US-Signal) versucht einen Zugriff auf einen I/O-Port, der nur für Supervisor-Modus-Zugriffe gesetzt ist, oder versucht auf ein internes DTC-Register zuzugreifen.
2. Addressing-Error. Der Offset für einen Internen-Register-Zugriff entspricht einem nicht implementierten Register.
3. Parity-Error. Der DTC detektiert während eines Transfers eine ungültige Parität. Die Parität wird unmittelbar nachdem Daten von dem Fern-Bus empfangen worden sind, geprüft. Die Parität wird nicht für ein programmiertes I/O-Schreiben von dem Ortsbus geprüft.
4. Remote-Bus-Error. Eine *RBERR-Antwort wird zu einem Fern-Bus- Transfer empfangen.
5. Data-Width-Exception. Die DSACK0-DSACK1-Antwort auf einen I/O- Port-Transfer zeigt an, daß die Fern-Bus-Vorrichtung oder -Speicher einen Transfer der angeforderten Breite nicht behandeln kann, oder es wird ein Byte- oder Halb-Wort-Zugriff auf ein DTC-Internes-Register versucht.
Wenn die Ausnahme mit *DERR gemeldet wird, wird das Global-Status-Register gesetzt, um anzuzeigen, welcher der I/O-Ports auf die Ausnahme gestoßen ist, oder zeigt an, daß die Ausnahme bei einem Internes-Register-Zugriff aufgetreten ist. Wenn die Ausnahme für einen I/O-Port-Zugriff aufgetreten ist, zeigt das Port- Status-Register des angezeigten I/O-Ports den Grund für die Ausnahme an.
In dem Fall eines I/O-Ports, der Lese-Davor oder Schreibe-Danach implementiert, trat die gemeldete Ausnahme bei dem jüngsten Fern-Bus-Zugriff auf. Das Local- Port-Address-Register beinhaltet die nicht übersetzte Adresse für diesen Zugriff und kann von Software benutzt werden, falls den Zugriff erneut zu starten, falls möglich. Für Schreiben, werden die Daten, die benutzt werden, um den Zugriff erneut zu starten, durch das Pack/Funnel-Register gehalten. In allen weiteren Fällen ist die Information, betreffend den programmierten I/O-Zugriff, in den RISC- Prozessor-Channel-Address-, Channel-Data- und Channel-Control-Registern enthalten und kann durch diese Register erneut gestartet werden.
Es werden nun DMA-Transfers, wie sie durch den DTC unterstützt sind, in Einzelheiten beschrieben.
Wie in der folgenden Beschreibung verwendet, beschreibt der Ausdruck (oder die Abkürzung) "Direkt-Speicher-Zugriff" (DMA) irgendeinen Zugriff oder. Daten- Transfer, der unabhängig von einer Befehlsausführung in dem RISC-Prozessor ist. Der Ausdruck ist etwas ungenau, da DMA-Transfers nicht notwendigerweise auf einen Speicher auf dem Ortsbus zugreifen. In einigen Fällen werden Fern-Bus- Daten zu und von den DMA-Warteschlangen der DTCs übertragen, wobei der RISC-Prozessor direkt Daten in der Warteschlange manipuliert. Jedoch beschreiben die weit verbreitet verwendeten Ausdrücke "Direkt-Speicher-Zugriff" und "DMA" am besten die durch den DTC implizierte Funktion.
Wie hier zuvor angemerkt, treten DMA-Transfers über vier DMA-Kanäle auf, die durch den DTC implementiert sind. Jeder dieser Kanäle wird durch den RISC- Prozessor initialisiert, um einen besonderen Daten-Transfer durchzuführen und der momentane Transfer findet ohne Eingriff durch den Prozessor statt. Wenn dafür freigegeben, kann der Kanal einen Prozessor-Interrupt erzeugen (durch Bestätigen von *INTR), wenn der Transfer normal endet, oder wenn er wegen einer Ausnahme gestrichen wird.
Da DMA-Transfers wenig Prozessor-Eingriff erfordern, kann eine große Datenmenge gleichzeitig mit einem Ausführungsbetrieb des Prozessors übertragen werden. Z. B. können in Multiprogrammier- oder Mehrprogramm-Betrieb- Umgebungen weitere Prozesse ausgeführt werden, während ein gegebener Prozeß auf einen DMA-Kanal wartet, um einen Daten-Transfer abzuschließen.
Die DMA-Kanäle des DTCs sind so entworfen, daß sie ein hohes Maß an Flexibilität unterstützen. Die Leistungsfähigkeit von DMA-Transfers ist sowohl auf den Orts- als auch Fern-Bussen maximiert, mit der Absicht die Konkurrenz um Ortsbus-Resourcen zwischen dem DTC- und dem RSIC-Prozessor zu beschränken.
DMA-Transfers auf dem Ortsbus sind von Transfers auf dem Fern-Bus wegen des hohen Maßes des Pufferns, das zwischen den DMA-Warteschlangen vorgesehen ist, relativ unabhängig. Dies wird in der Organisation der DMA-Kanal-Register reflektiert; viele Register betreffen nur die Ortsbus-Seite oder die Fern-Bus-Seite des DMA-Kanals. Fig. 8 zeigt das Datenfluß-Diagramm eines DMA-Kanals.
Fig. 8 bildet Daten auf D0-D31 (und Parität-Bits) ab, die in (Leitung 801) den abgebildeten DMA-Kanal hineingehen, oder daraus hervorkommen (Verbindung 802).
Hineinkommende Daten werden über einen MUX 803 in die 64-Wort- Warteschlange 804 für den Kanal multiplexiert. Offensichtlich könnten größere oder kleinere Warteschlangen bei der Herstellung des DTC verwendet werden. Daten fließen über ein Pack-Funnel-Register 805 und den MUX 806 aus der Warteschlange von und zu dem Pack/Funnel-Netzwerk. Der MUX 806 dient dazu, Daten von dem Pack/Funnel-Netzwerk in die Warteschlange 804 über ein Regi ster 805 und den MUIX 803 zu kanalisieren, zusätzlich zum Ermöglichen, daß Daten von der Warteschlange 804 zu dem Pack/Funnel-Netzwerk ausgegeben werden. Man beachte, daß auf dem Ortsbus DMA-Transfers nur zu dem Datenspeicher-Adressraum des RISC-Systems auftreten.
Für Fern-zu-Lokal-DMA-Transfers werden Daten von dem Fern-Bus mit einem Adressier-Muster, das durch das Channel-Mode-Register spezifiziert ist und das durch das Remote-Address-Register verfolgt ist, gelesen. Diese Daten werden in der geeigneten DMA-Warteschlange (möglichst nach einem Packen) plaziert und nachfolgend zu dem Ortsbus transferiert, außer wenn der Ortsbus-Transfer gesperrt ist, in welchem Fall die Daten durch den Prozessor auf dem Ortsbus transferiert oder inspiziert werden.
Die Adressen für Ortsbus-Transfers erhöhen immer sequenziell Wort-Adressen und werden durch das Local-Address-Register verfolgt. Die Anzahl transferierter Bytes wird durch das Local-Byte-Count-Register verfolgt.
Fern-Bus-Transfers dauern an, bis die Fern-Byte-Zählung mit dem Wert in dem Terminate-Count-Register übereinstimmt. Demzufolge dauern Ortsbus-Transfers an, bis die lokale Byte-Zählung mit dem Wert in dem Terminate-Count-Register übereinstimmt (wegen Daten, die in der DMA-Warteschlange gepuffert sind). Wenn die lokale Byte-Zählung mit der End-Zählung übereinstimmt, ist der Transfer abgeschlossen und *INTR wird bestätigt, wenn freigegeben.
Für Lokal-zu-Fern-DMA-Transfers werden Daten von dem Ortsbus gelesen (außer wenn der Ortsbus-Transfer gesperrt ist, in welchem Falle die Daten durch den Prozessor auf den Ortsbus geladen werden), mit einem sequenziell ansteigenden Adressier-Muster, das durch das Local-Address-Register verfolgt wird. Die Anzahl transferierter Bytes wird durch eine geeignete DMA-Warteschlange verfolgt und darauffolgend zum Fern-Bus (möglichst mit Kanalisieren) übertragen.
Die Adressen für Remote-Bus-Transfers haben ein Adressier-Muster, das durch das Channel-Mode-Register spezifiziert ist und durch das Remote-Address- Register verfolgt wird. Die Anzahl transferierter Bytes wird durch das Remote- Byte-Count-Register verfolgt.
Ortsbus-Transfers dauern an, bis die Local-Byte-Zählung mit dem Wert des Terminate-Count-Registers zusammenpaßt. Demzufolge dauern Fern-Bus-Transfers an, bis die Fern-Byte-Zählung mit dem Wert in dem Terminate-Count-Register übereinstimmt (wegen Daten, die in der DMA-Warteschlange gepuffert sind). Wenn die Fern-Byte-Zählung mit der End-Zählung übereinstimmt, ist der Transfer abgeschlossen und *INTR wird bestätigt, wenn freigegeben.
Jeder DMA-Kanal weist eine zugeordnete DMA-Warteschlange auf, die Daten puffert, während sie zwischen den Orts- und Fern-Bussen transferiert werden. Gemäß der bevorzugten Ausführungsform der Erfindung ist jede dieser Warteschlangen 256 Bytes groß und ist als 64 Worte organisiert. Wiederum werden nur Worte zu und von den Warteschlangen auf dem Ortsbus transferiert. Auf dem Fern-Bus können wegen der Pack- und Kanalisier-Operationen Worte, Halb- Worte und Bytes transferiert werden. Die DMA-Warteschlangen dienen zwei Zwecken, die nachfolgend diskutiert werden.
Für wirkliche DMA-Transfers (d. h. die Transfers, die momentan auf den Ortsbus- Speicher zugreifen) ermöglicht es, das durch die DMA-Warteschlangen vorgesehene Puffern dem Ortsbus-DMA-Transfer mit einer Rate von bis zu 100 Mbyte/Sek. unter Verwendung der Burst-Mode-Fähigkeit des Ortsbusses fortzuschreiten. Die Inhalte der gesamten Warteschlange können durch ein einziges Burst-Mode-Speichern transferiert werden, oder die Warteschlange kann durch ein Burst-Mode-Laden vollkommen gefüllt werden.
Zusätzlich zur Unterstützung von Burst-Mode-Zugriffen reduzieren die DMA- Warteschlangen die Wirkung einer Ortsbus-Akquisition für DMA-Transfers.
Normalerweise sind zwei Zyklen für den DTC erforderlich, um den Ortsbus zu erfassen und aufzugeben und der Ortsbus kann während dieser Zyklen nicht benutzt werden. Würde nur ein einziges Wort für jede Akquisition übertragen, wäre · der Überhang, der durch diese Zyklen dargestellt werden würde, relativ hoch. Durch das Ermöglichen, so viele wie 64 Worte mit einer Akquisition zu übertragen, helfen die DMA-Warteschlangen diesen Überhang zu minimieren.
Ein zweiter Zweck der DMA-Warteschlangen ist es, einen Puffer-Bereich für eine direkte Manipulation durch den RISC-Prozessor zu schaffen. In einigen Systemen ist es vorteilhaft für den Prozessor zum Fern-Bus zu übertragende Daten direkt in der DMA-Warteschlange zusammenzusetzen. In diesem Fall ist die DMA- Warteschlange konfiguriert, als eine Erweiterung des Ortsbus-Speichers zu erscheinen. Dies verhindert die Latenz, die an dem zusätzlichen Transfer zu oder von einem Ortsbus-Speicher beteiligt ist. Jedoch sind Direkt-Transfers nur geeignet, wenn die daran beteiligten Daten in den 64-Wort-Bereich passen, der durch die DMA-Warteschlange vorgesehen ist.
Die DMA-Warteschlangen sind bei der bevorzugten Ausführungsform der Erfindung durch ein 256-Wort-Array implementiert, das in 4, 64-Wort-Abteilungen unterteilt ist. Die Warteschlangen sind als DTC-Interne-Register auf dem Ortsbus sichtbar. Queue-Status-Register (zuvor beschrieben), die mit jedem DMA-Kanal zugeordnet sind, geben den Status der zugeordneten DMA-Warteschlange an. Das Queue-Status-Register beinhaltet das Queue-Head-(QH)-Feld, welches die Adresse des Worte auf der Vorderseite der Warteschlange hält, und das Queue-Tail- (QT)-Feld, das die Adresse des (leeren) Wortes am Ende der Schlange enthält.
Wenn ein DMA-Kanal initialisiert ist, um einen DMA-Transfer durchzuführen (durch Ersetzen des RST-Bits in dem Channel-Status-Register) ist sowohl das QH-als auch das QT-Feld auf Null gesetzt. Während des DMA-Transfers werden Daten in die Warteschlange an einem durch das QT-Feld identifizierten Ort gesetzt und das QT-Feld wird um eins inkrementiert, nachdem die Daten geschrie ben wurden. Das QT-Feld deutet somit immer auf den nächsten leeren Ort in der Warteschlange. Daten werden in der Warteschlange an einem durch das QH-Feld identifizierten Ort entfernt und das QH-Feld wird um eins inkrementiert, nachdem die Daten gelesen wurden. Das QH-Feld zeigt somit immer auf den nächsten gültigen Ort der Warteschlange, außer wenn die Warteschlange leer ist. Der Wert des QH-Feldes ist nur für eine leere DMA-Warteschlange äquivalent zu dem Wert des QT-Feldes. Eine volle Warteschlange wird durch ein QT-Feld identifiziert, dessen Wert um eins niedriger ist (Modulo 64) als der Wert des QH-Feldes. Die Beziehung der QH- und QT-Zeiger für eine leere, teilweise volle und eine volle Warteschlange sind in Fig. 9 gezeigt.
Wenn eine DMA-Warteschlange benutzt wird, um Muster zu transferieren (d. h. das Queue-Pattern-Bit des Channel-Mode-Registers ist gesetzt) identifiziert das QH-Feld den Warteschlange-Ort, der das Muster enthält (der Ort muß explizit mit dem Muster geschrieben sein). Das QH-Feld wird nicht verändert, wenn das Muster transferiert wird. In dieser Konfiguration ist der Wert des QT-Feldes unwichtig.
Das Queue-Status-Register kann geschrieben sein, um den Status der. Warteschlange zu ändern; jedoch kann dies eine unvorhersehbare Wirkung haben, wenn ein DMA-Transfer im Ablauf ist.
DMA-Transfers sind verschiedenen Steuerungsbedingungen und Konfigurationen unterworfen. Diese Bedingungen und Konfigurationen, und wie sie sowohl auf dem Orts- als auch dem Fern-Bus mit DMA-Transfers verbunden sind, werden nachfolgend beschrieben.
Ein DMA-Kanal wird durch Setzen des geeigneten Channel-Bits des Global- Mode-Registers freigegeben und gesperrt. Ein gesperrter DMA-Kanal ist daran gehindert irgendeinen Transfer ohne Rücksicht auf eine andere Freigabe- Bedingung durchzuführen. Ein freigegebener DMA-Kanal kann Transfers nur durchführen, wenn andere Bedingungen so sind, daß der Transfer stattfinden kann. Diese sind nachfolgend erläutert. Es wird angenommen, daß ein freigegebener DMA-Kanal für einen gültigen Transfer konfiguriert wurde.
Ein DMA-Transfer auf einem freigegebenen DMA-Kanal kann zu irgendeinem gegebenen Zeitpunkt in einem der folgenden Betriebs-Zustände sein:
1. Schwebend. Der DMA-Kanal ist vorbereitet, um einen Transfer auf dem Orts- oder Fern-Bus durchzuführen, jedoch findet der Transfer momentan nicht statt. Ein DMA-Transfer kann wegen einer Bus-Entscheidung-Latenz oder wegen einer DMA-Anforderung höherer Priorität schwebend sein.
2. Aktiv. Der DMA-Kanal führt momentan einen DMA-Transfer entweder auf dem Orts- oder dem Fern-Bus durch.
3. Nicht aktiv. DMA-Transfers sind durch das Channel-Aktiv-(CA)-Bit des Channel-Status-Registers ausgesetzt. Dieses Bit kann durch Software zurückgesetzt und gesetzt werden, um zeitweise Transfers auf dem DMA- Kanal auszusetzen und wiederaufzunehmen.
4. Abgeschlossen. Der DMA-Kanal hat alle erforderten Zugriffe durchgeführt. Das CA-Bit des Channel-Status-Registers wird zurückgesetzt, wenn ein DMA-Transfer endet.
5. Unterbrochen. Der DMA-Kanal hat nicht alle Transfers ausgeführt, sondern die Sequenz von Transfers ist zeitweise ausgesetzt. In vielen Fällen tritt dieser Zustand wegen einer Datenfluß-Steuerung auf. Jedoch kann ein Daten-Transfer durch eine Bus-Entscheidung, eine DMA-Anforderung höherer Priorität oder durch irgendeine andere Bedingung, die nicht direkt mit dem Transfer verbunden ist, unterbrochen werden.
6. Gestrichen. DMA-Transfers werden verhindert, selbst wenn weitere Transfers wegen eines außergewöhnlichen Vorkommnisses wie z. B. eines Paritätsfehlers übrigbleiben. Das CA-Bit des Channel-Status-Registers wird zurückgesetzt, wenn ein DMA-Transfer gestrichen wird.
Wenn ein DMA-Transfer abgeschlossen ist oder gestrichen ist, wird die entsprechende DMA-Warteschlange geleert (wenn möglich) und der CA des zugeordneten Channel-Status-Registers wird zurückgesetzt, was bewirkt, daß der DMA- Kanal inaktiv wird. Zu diesem Zeitpunkt, wenn das Interrupt-Enable-Bit des Chanel-Mode-Registers gesetzt ist und das Global-Interrupt-Enable-Bit des Global- Mode-Registers gesetzt ist, bestätigt der DTC die *INTR-Ausgabe. Dies ermöglicht einen Interrupt (oder Trap) zu dem RISC-Prozessor.
DMA-Transfers zwischen den Orts- und Fern-Bussen sind einer Fluß-Steuerung (d. h. Transfer-Rate-Steuerung) an verschiedenen Punkten im Pfad zwischen den Orts- und Fern-Bussen unterworfen:
1. Ortsbus-Speicher. Das Ortsbus-Speicher kann zu verschiedenen Zeitpunkten nicht genug Kapazität haben, um die gesammente Nachfrage aller DMA-Kanäle zufrieden zu stellen.
2. Local-Burst/Dwell-Zählungen. Das Local Burst/Dwell-Register begrenzt die Datenmenge, die auf dem Ortsbus transferiert werden kann, und kann eine stärkere Beschränkung auf den Datenfluß darstellen als die Kapazität des Ortsbus-Speichers. Burst/Dwell-Zählungen sind vorgesehen, um die Konkurrenz um einen Ortsbus, erzeugt durch den DTC, zu beschränken.
3. Remote-Burst/Dwell-Zählungen. Das Remote-Burst/Dwell-Register begrenzt die Menge von Daten, die auf dem Fern-Bus transferiert werden kann, um die Konkurrenz für den Fern-Bus, erzeugt durch den DTC, zu begrenzen. Dies gilt nur für bestimmte Transfer-Modi (z. B. Nachfrage- Modus), bei denen große Mengen von Daten mit einer einzigen Anforderung übertragen werden können.
4. Fern-Bus-Vorrichtungen oder -Speicher. Vorrichtungen oder Speicher auf dem Fern-Bus können den Fluß von Daten unter Verwendung der geeigneten *DRQ0-DRQ3-Eingabe beschränken. Zusätzlich kann der Datenfluß sofort durch DSACK0-DSACK1, oder durch die Remote-Wait- Zählung und Remote-Recovery-Zählung des Channel-Mode-Registers beschränkt werden.
Für obige Fälle 1 und 2 muß der DTC eine Flußsteuerung auf der Fern-Bus-Seite eines oder mehrerer DMA-Kanäle ausüben, welche die Ortsbus-Beschränkung auf die Fern-Seite reflektiert. Wenn eine DMA-Warteschlange keine Daten hat, um ein Fern-Bus-Schreiben zufrieden zu stellen; oder wenn die DMA-Warteschlange keinen Ort hat, um die Daten eines Fern-Bus-Lesens zu empfangen (d. h. sie hat nur einen einzigen leeren Ort) führt der DTC keinen DMA-Transfer, angefordert durch *DRQ0-*DRQ3, durch (und bestätigt die Anforderung nicht) bis der Zustand nicht länger existiert.
Im allgemeinen kann irgendeiner der obigen Fluß-Steuerungs-Mechanismen den Fluß von Daten beschränken. Jedoch können die Burst/Dwell-Zählungen auf entweder dem Orts- oder dem Fern-Bus einen Zugriff, der im Fortschreiten ist, nicht unterbrechen. Wenn eine Burst/Verweil-Beschränkung erforderlich ist, ist sie dem Transfer auferlegt, der irgendeinem Transfer, der im Fortschreiten ist, nachfolgt.
DMA-Transfers zu und von dem Ortsbus, wenn sie durch das Local-Transfer- Disable-Bit des Channel-Mode-Registers freigegeben sind, werden nicht auf dem Ortsbus angefordert (da sie auf dem Fern-Bus sind). Ortsbus-DMA-Transfers sind durch den Zustand der DMA-Warteschlange und die Betriebs-Bedingung des DMA-Kanals aktiviert.
Für einen Fern-zu-Lokal-DMA-Transfer wird der Ortsbus-Transfer immer dann schwebend, wenn es ein einzelnes verbleibendes, nicht benutztes Wort in der DMA-Warteschlange gibt. Dieses Wort kann nicht gefüllt werden, da nicht zugelassen werden kann, daß die Queue-Head- und Queue-Tail-Zeiger für eine volle Warteschlange gleich sind. Unter normalen Bedingungen bleibt der DMA- Transfer aktiv, bis die Warteschlange geleert ist (man beachte, daß die DMA- Warteschlange gleichzeitig von dem Fern-Bus gefüllt werden kann). Jedoch ist der Transfer irgendeiner anderen Bedingung, die oben erläutert wurde, unterworfen (wie z. B. Vorbelegung, Burst-/Dwell-Zählung etc.).
Für einen Lokal-zu-Fern-Transfer wird der Ortsbus-Transfer schwebend, wenn die DMA-Warteschlange ein einzelnes nicht übertragenes Wort enthält, oder wenn die Warteschlange leer ist. Unter einer normalen Bedingung bleibt der DMA-Transfer aktiv bis die Warteschlange voll ist (man beachte, daß die DMA- Warteschlange gleichzeitig von dem Fern-Bus geleert wird). Jedoch ist der Transfer jeder anderen oben erläuterten Bedingung unterworfen.
Wenn ein Fern-zu-Lokal-Transfer abschließt oder gestrichen ist, muß die zugeordnete DMA-Warteschlange geleert werden (wenn die Ausnahme nicht durch den Ortsbus, z. B. *DERR verursacht ist). Wenn irgendeine dieser Bedingungen auftritt, wird der Ortsbus-Transfer sofort schwebend und die DMA-Warteschlange wird geleert, bevor *INTR bestätigt ist (*INTR wird nur bestätigt, wenn freigegeben).
Jeder DMA-Kanal hat mehrere Register zum Steuern und Verfolgen der Menge übertragender Daten, die alle zuvor hier erläutert wurden. Dies sind die Folgenden:
1. Local-Byte-Count-Register
2. Local-Alarm-Count-Register
3. Remote-Byte-Count-Register
4. Remote-Alarm-Count-Register
5. Terminate-Count-Register
Wenn ein DMA-Transfer initiiert ist, sind sowohl das Local-Byte-Count-Register als auch das Remote-Byte-Count-Register auf Null gesetzt. Wenn DMA-Transfers auftreten, zählt jedes Register individuell die Anzahl der auf dem jeweiligen Bus übertragenen Bytes. Das Local-Bit-Count-Register zählt in Einheiten von 4 Bytes und das Remote-Byte-Count-Register zählt in Einheiten, die durch das Data- Width-Feld des Channel-Mode-Registers bestimmt sind.
Während DMA-Transfers wird der Wert des Local-Byte-Count-Registers verglichen mit dem Wert des Local-Alarm-Count-Registers und der Wert des Remote- Byte-Count-Registers wird mit dem Wert Ihr das Remote-Alarm-Count-Register verglichen. Die Werte sowohl des Local-Byte-Count-Registers als auch das Remote-Byte-Count-Registers werden mit dem Wert des Terminate-Count-Registers verglichen.
Die Local-Alarm-Enable- und Remote-Alarm-Enable-Bits des Channel-Mode- Registers schalten den DTC ein, um einen Interrupt zu erzeugen (wenn anderweitig freigegeben), wenn die Lokal- bzw. Remote-Byte-Zählung mit der entsprechenden Alarm-Zählung zusammenpaßt oder diese übersteigt. Das Local-Alarm- Reached oder Remote-Alarm-Reached-Bit des Channel-Status-Registers ist gesetzt, um den Interrupt zu bewirken.
Die Alarm-Interrupts sehen ein Mittel vor, um den RISC-Prozessor zu unterbrechen, wenn ein besonderer Punkt in dem DMA-Transfer erreicht worden ist, unabhängig von irgendeiner Beendigungs-Bedingung. Zum Beispiel kann dies dem RISC-Prozessor anzeigen, daß der Kopf-Teil des Kommunikationspaketes empfangen wurde, was es ermöglicht, den Kopf zu untersuchen, während der Rest des Paketes übertragen wird.
Die Vergleiche mit dem Wert des Terminate-Count-Registers zeigen an, daß der DMA-Kanal die Beendigungs-Bedingung erreicht hat. Wegen des durch die DMA-Warteschlange vorgesehenen Pufferns erreichen die Fern-Bus- und Ortsbus-Seiten des DMA-Kanals sehr wahrscheinlich die Beendigungs-Zählung nicht zur selben Zeit.
Wenn irgendeine Seite die Beendigungs-Zählung erreicht, wird die DMA- Aktivität auf dem jeweiligen Bus beendet. Darüber hinaus, wenn die Fern-Bus- Seite die Beendigungs-Zähung auf einem Fern-zu-Lokal-Transfer erreicht, werden die Inhalte der DMA-Warteschlange zu dem Ortsbus übertragen (falls freigegeben dies zu tun), ohne Rücksicht auf die Menge von Daten in der Warteschlange (d. h., die Warteschlange wird leergeräumt).
Die gesamte Anzahl von auf dem Orts- oder Fern-Bus für einen DMA-Transfer transferierten Bits kann etwas größer sein, als die Anzahl die durch das Terminate-Count-Register spezifiziert ist, abhängig von der Beziehung des Wertes in diesem Register zu den Datenbreiten auf dem Ortsbus und Fern-Bussen. Der Beendigungs-Zählungswert ist in Einheiten von Bytes. Wenn diese Zahl von Bytes nicht durch eine ganzzahlige Zahl von Transfers auf jedem Bus übertragen werden kann, werden Daten übertragen, bis die Zählung überschritten ist.
Zum Beispiel sei betrachtet, daß das Terminate-Count-Register auf den Wert 41 gesetzt ist, wenn ein DMA-Transfer intitialisiert ist, und daß die Fern-Bus- Datenbreite 16 Bits ist. In diesem Fall werden 44 Bytes (11 Worte) auf den Ortsbus transferiert werden und 42 Bytes (21 Halb-Worte) werden auf den Fern-Bus transferiert werden.
Wenn das Local-Transfer-Disable-Bit des Channel-Mode-Registers gesetzt ist, wobei DMA-Transfers zu dem Ortsbus gesperrt werden, ändern sich das Local- Address-Register und das Local-Byte-Count-Register nicht. Die Wirkungen aller Vergleiche, die bezüglich des Wertes des Local-Byte-Count-Registers gemacht sind, sind gesperrt und die Beendigungs-Bedingung hängt von dem Remote-Byte- Count-Register ab.
Wenn mehr als eine DMA-Anforderung zu einem bestimmten Zeitpunkt schwebend ist, wird die widersprüchliche DMA-Anforderung durch eine Priorität setzende DMA-Anforderung gelöst. Prioritäten unter den DMA-Kanälen können entweder fest oder rotierend sein, gesteuert durch das Channel-Priority-Rotating- Bit des Global-Mode-Registers.
Wenn die DMA-Kanal-Prioritäten fest sind, sind die Prioritäten gemäß der vorliegenden Ausführungsform der Erfindung von DMA-Kanälen in numerischer Reihenfolge fest, wobei DMA-Kanal 0 die höchste Priorität hat. Somit hat eine Anforderung an DMA-Kanal 0 Priorität über eine Anforderung an DMA-Kanal 1 usw.
Wenn DMA-Kanal-Prioritäten rotieren, sind die Prioritäten der DMA-Kanäle durch die Länge der Zeit seit dem jüngsten Transfer geordnet, wobei dem Kanal mit der längsten inaktiven Periode die höchste Priorität gegeben wird. Man beachte, daß die Rotation nicht durch Scannen der Anforderung eines jeden Kanals mit einem Zyklus-um-Zyklus implementiert wird, wie man schließen könnte. Vielmehr wird einem gegebenen DMA-Kanal sofort, nachdem er einen DMA- Transfer beginnt, die niedrigste Priorität zugeordnet und Kanäle rotieren durch die niedrigste Priorität, wie ihren Anforderungen genüge getan wird.
Man beachte, daß ein Prioritätensetzen die End-Stadien einer Entscheidung, eine spezielle DMA-Anforderung zu bedienen, beeinflußt. Zum Beispiel wird eine Anforderung für ein DMA-Lesen auf dem Fern-Bus an einem Prioritätensetzen nicht Teil haben sein, wenn die zugeordnete DMA-Warteschlange voll ist, selbst wenn der Kanal eine hohe Priorität hat.
In Fällen, in welchen mehr als ein DMA-Kanal einen Ortsbus-Transfer zu einem gegebenen Zeitpunkt durchführen kann, wird der Konflikt gemäß den Kanal- Prioritäten gelöst, die zu diesem Zeitpunkt gültig sind.
Wenn ein I/O-Port-Zugriff zur selben Zeit wie ein DMA-Transfer schwebend wird, hat der I/O-Port Priorität bei der Benutzung des Fern-Busses. Des weiteren kann er den Transfer unterbrechen, wenn ein I/O-Port-Zugriff schwebend wird während ein DMA-Transfer aktiv ist.
Es gibt mehrere Ausnahmen, die während eines DMA-Transfers auftreten können. Jede dieser Ausnahmen bewirkt das Streichen eines DMA-Transfers, wobei die *INTR-Ausgabe bestätigt wird (wenn freigegeben). Für einen Fern-zu-Lokal- Transfer wird die DMA-Warteschlange geräumt, bevor *INTR bestätigt wird.
Die folgenden Ausnahmen können während eines DMA-Transfers, wo geeignet, in der nach Priorität bei der bevorzugten Ausführungsform gesetzten Reihenfolge auftreten:
1. Paritäts-Fehler. Der DTC detektiert unzulässig während eines Transfers. Die Parität wird sofort nachdem Daten von einem der Busse empfangen sind geprüft, so daß Daten in DMA-Warteschlangen immer eine zulässige Parität haben.
2. Fern-Bus-Fehler. Eine *RBERR-Antwort wird zu einem Fern-Bus- Transfer empfangen.
3. Datenbreite-Ausnahme. Die DSACK0-DSACK1-Antwort zu einem DMA- Transfer zeigt an, daß die Fern-Bus-Vorrichtung oder -Speicher einen Transfer der angeforderten Breite nicht behandeln kann.
4. Adreß-Konflikt. Die Adresse für einen Ortsbus-Transfer überlappt die Adresse für einen I/O-Port, oder sie ist eine Adresse, erkannt aufgrund des Chip-Select-Mapping-Registers (man beachte, daß dies einfach eine aktive *CSEL-Eingabe sein kann). Dies verhindert irgendwelche weiteren Ortsbus-Transfers durch den entsprechenden DMA-Kanal, bis die Ausnahme bedient ist.
5. Ortsbus-Fehler. Eine *DERR-Antwort wird zu einem Ortsbus-Transfer empfangen. Dies verhindert irgendwelche weiteren Ortsbus-Transfers durch den entsprechenden DMA-Kanal, bis die Ausnahme bedient ist.
6. Ende des Prozesses. Die *EOP-Eingabe ist während eines Fern-Bus- Transfers bestätigt. Dies kann einen Fehler abhängig von dem System signalisieren oder nicht.
Wenn *INTR bestätigt ist, zeigt das Global-Status-Register an, welcher der DMA- Kanäle auf die Ausnahme gestoßen ist. Das Channel-Status-Register des angezeigten DMA-Kanals gibt den Grund für die Ausnahme an. Wenn Interrupts freigegeben sind, verursachen die Bits dieses Registers, das Ausnahmen meldet, daß *INTR bestätigt wird. Sie können durch Software zurückgesetzt werden, um den Interrupt zu deaktivieren. Man beachte, daß Software ebenso veranlassen kann, das *INTR durch Setzen eines oder mehrerer dieser Bits bestätigt wird.
Nun wird eine Beschreibung, wie eine Fern-Bus-Vorrichtung oder -Speicher einen DMA-Transfer anfordert, dargelegt.
Eine Fern-Bus-Vorrichtung oder -Speicher fordert einen DMA-Transfer, durch Betätigen einer einzelnen der *DRQ0-*DRQ3-Eingaben an, abhängig von dem DMA-Kanal, dem sie zugeordnet ist (DRQ0 korrespondiert mit DMA-Kanal 0, usw.) Der DTC führt den angeforderten Transfer auf dem Fern-Bus durch, wobei er eine der *DACK0-*DACK3-Ausgaben, geeigneterweise am Anfang des Transfers angibt.
Vorrichtungen und Speicher müssen den Datenfluß nicht mit *DRQ0-*DRQ3 steuern. In diesem Fall kann ein DMA-Kanal so konfiguriert werden, daß er die entsprechende *DRQ0-DRQ3-Eingabe ignoriert und Daten mit einer Rate transferiert, die durch den DTC-Betriebssstatus und andere Beschränkungen für Fern- Bus-Transfers, wie z. B. DSACK0-DSACK1 bestimmt ist.
Ein DMA-Kanal antwortet auf die entsprechende *DRQ0-*DRQ3-Eingabe in einer von drei Modi, wie sie durch das DMA-Request-Answer-Mode-(DRM)-Feld des entsprechenden Channel-Mode-Registers gesteuert sind. Diese Modi definieren das Verhalten des DMA-Kanals für eine Bestätigung der entsprechenden *DRQ0-*DRQ3-Eingabe.
Wenn das DRM-Feld des Channel-Mode-Registers 00 ist, ignoriert der DMA- Kanal die entsprechende *DRQ0-*DRQ3-Eingabe. Wenn der Kanal für einen Transfer durch das entsprechende Channel-Enable-Bit des Global-Mode-Registers und das CA-Bit des Channel-Status-Registers für einen Transfer freigegeben ist, transferiert der Kanal Daten, immer wenn der Transfer anderweitig möglich ist (wie es durch den Status der DMA-Warteschlange, die Priorität des Kanals, etc. bestimmt ist).
In diesem Modus ist der einzige Datenfluß-Steuermechanismus, der für die Fern- Bus-Vorrichtung oder -Speicher zur Verfügung steht, derjenige, welcher durch DSACK0-DSACK1 oder durch die Wait/Recovery-Zählung in dem Channel- Mode-Register vorgesehen ist. Da diese Mechanismen die Fern-Bus-Kapazität verwenden, können sie uneffizient sein.
Der DTC bestätigt die entsprechende *DACK0-DACK3-Ausgabe, wenn er einen DMA-Transfer auf dem Fern-Bus beginnt, selbst wenn die entsprechende DMA-Anforderung ignoriert wird.
Wenn das DRM-Feld des Channel-Mode-Registers 01 ist, führt der DMA-Kanal einen einzigen Fern-Bus-Transfer für jeden HIGH-zu-LOW-Übergang der entsprechenden *DRQ0-*DRQ3-Eingabe durch. Die entsprechende *DACK0- *DACK3-Ausgabe wird am Anfang des Transfers bestätigt (d. h. während des Adress-Zyklus). Die DMA-Anforderung-Eingabe muß für zumindest einen Zyklus für einen synchronen Fern-Bus inaktiv sein, oder zwei Zyklen für einen asynchronen Fern-Bus, bevor sie einen weiteren HIGH-zu-LOW-Übergang ausführen kann. Für einen maximalen Durchsatz muß daher die DMA-Anforderung- Eingabe verneint werden, bevor ein angeforderter Transfer abgeschlossen ist.
Wenn das DRM-Feld des Channel-Mode-Registers 10 ist, führt der DMA-Kanal Fern-Bus-Transfers so lange durch, wie die entsprechende *DRQ0-*DRQ3- Eingabe aktiv ist und so lange, wie es andere Bedingungen zulassen, daß der Transfer stattfindet (z. B. Prioritäten anderer Kanäle etc.). Die *DACK0- *DACK3-Ausgabe wird während des Adress-Zyklus des ersten Transfers bestätigt und bleibt aktiv während aller Transfers, mit der möglichen Ausnahme des letzten Transfers. Die Fern-Bus-Vorrichtung oder -Speicher kann einen Nachfrage- Transfer durch Verneinen von *DRQ0-*DRQ3 vor dem LOW-zu-HIGH- Übergang von *DSTB für den letzten Transfer zuvorkommen. Weitere Transfers können durch Wiederbestätigen von *DRQ0-*DRQ3 zu einem späteren Zeitpunkt angefordert werden.
Wenn der DTC den Transfer während eines aktiven Nachfrage-Transfers beendet oder ihm zuvorkommt, wird die entsprechende *DACK0-*DACK3-Ausgabe während des letzten Datentransfers verneint (gleichzeitig mit der Bestätigung von *DSTB). Jedoch, wenn die Beendigung in Antwort zu einem *EOP von dem Fern-Bus ist, bleibt die entsprechende *DACK0-*DACK3-Ausgabe während des letzten Transfers aktiv.
Man beachte, daß ein DMA-Kanal, der in einem Nachfrage-Modus-Transfer ausführt, einen DMA-Dienst auf anderen Kanälen verhindern kann, wenn er eine hohe Priorität hat.
Für rotierende Prioritäten wird dem Kanal die niedrigste Priorität zugeordnet, sobald er den Transfer beginnt und er kann nicht einen Dienst zu anderen Kanälen verhindern.
Die bevorzugte Ausführungsform der Erfindung, wie sie oben dargelegt ist, ist flexibel genug, daß individuelle DMA-Kanäle für spezielle Operationen, wie z. B. "Block-Transfers" konfiguriert werden können, d. h. derart, daß eine Adresse einmal für eine beliebige Anzahl von Datentransfers übertragen wird; und "Muster- Transfers", d. h. bei welchen ein DMA-Kanal programmiert ist, feste Muster zu dem Fern- oder Ortsbus zu transferieren.
Bevor diese detaillierte Beschreibung des neuen DTC abgeschlossen wird, bleiben verschiedene Details und Betrachtungen des Gesamtsystems zu berücksichtigen.
Zuerst kann optional, um den Fern-Bus an dem DTC anzuschließen, eine Schnittstelle, wie hier vorher mit Bezugnahme auf Fig. 1 (Einheit 105) kurz beschrieben wurde, benutzt werden.
Fig. 10 bildet eine typische Fern-Bus-Verbindung mit kommerziell verfügbaren Signalspeichern, Treibern, Transceivern und einer Steuerschnittstelle ab, um Fern- Daten und Adresssignale und Steuersignale mit Fern-Systemadressen, Daten und Steuerbussen zu koppeln. Jedoch kann es in einigen Fällen (z. B. um kostengünstige Zusätze zu dem Fern-Bus vorzusehen) vorteilhaft sein, die Bus-Schnittstellen- Logik zwischen dem Fern-Bus und Periphergeräten zu entfernen und das Peri phergerät direkt zu steuern. Der DTC vereinfacht die Planung eines derartigen Systems, durch ein Unterstützen einer programmierbaren Bus-Zeitgabe für jeden I/O-Port oder DMA-Kanal. Dies beseitigt die Notwendigkeit für jegliche durch Schnittstellen-Schaltungen implementierte Zeitgabe.
Eine DTC gesteuerte Bus-Zeitgabe ist über die Remote-Wait-Count (RWC) und Remote-Recovery-Count-(RRC)-Felder eines Channel-Mode-Registers oder eines Port-Mode-Registers programmiert. Das RWC-Feld spezifiziert (wie hier zuvor erläutert) die Anzahl von Zyklen (oberhalb eines einzelnen Zyklus) in dem Datenzyklus für einen Transfer. Der RRC spezifiziert die Anzahl von Zyklen (möglichst 0) zwischen den Ende des Datenzyklus und dem Beginn des nächsten Datenzyklus (man beachte, daß ein Adress-Zyklus dem Datenzyklus für Nicht-Block- Modus-Transfers vorangeht). Die durch diese Felder gesteuerte Zeitgabe ist durch das Data-Size-Acknowledge-Disable-(DAD)-Bit des Channel-Mode-Registers oder Port-Mode-Registers freigegeben.
Wenn eine DTC gesteuerte Bus-Zeitgabe für einen speziellen I/O-Port oder einen DMA-Kanal freigegeben ist, ignoriert der DTC DSACK0-DSACK1 für jeden Fern-Bus-Zugriff über den I/O-Port oder -Kanal und verläßt sich auf die Werte der RWC- und RRC-Felder, um den Zugriff auf den Fern-Bus zeitlich abzustimmen. Da DSACK0-DSACK1 ignoriert werden, muß die richtige Datenbreite in dem entsprechenden Channel-Mode-Register oder Port-Mode-Register programmiert sein.
Der DTC antwortet noch auf *RBERR-*EOP, sofern freigegeben, um eine Bus- Zeitgabe zu erzeugen. Die Bestätigung eines dieser Signale beendet den Datenzyklus unbeachtet des Wertes des RWC-Feldes und hat ansonsten den üblichen Effekt.
Als nächstes sei verständlich, daß die logische Operation des Fern-Busses nicht davon abhängt, ob der Bus eine synchrone oder eine asynchrone Betriebsweise hat. Die Signale, die verwendet werden, um einen Zugriff zu steuern, haben in jedem Fall dieselbe Interpretation. Jedoch gibt es zwei wesentliche Unterschiede in der physischen Implementierung des asynchronen Busses, verglichen mit dem synchronen Bus:
1. Die Eingaben zu dem DTC, die den asynchronen Bus steuern, haben einen Schutz gegen metastabile Zustände. Der Schutz erfordert eine interne Synchronisation, die sich zu der Zeit addiert, die für einen Buszugriff erforderlich ist.
2. Auf dem asynchronen Bus müssen alle Übergänge auf den primären Handshake-Signalen DSACK0-DSACK1, *RBERR und *EOP durch den DTC erkannt und synchronisiert werden. Im Gegensatz dazu, werden diese Signale auf dem synchronen Bus abgetastet und es ist keine zusätzliche Zeit für ein Synchronisieren von Übergängen erforderlich.
Die Erfordernisse auf dem asynchronen Bus veranlassen diesen im allgemeinen mit einer geringeren Rate zu arbeiten, als der synchrone Bus. Das ist das Ergebnis einer metastabilen Synchronisationszeit und der Tatsache, daß beide Übergänge von Handshake-Signalen synchronisiert werden müssen. Entweder für den synchronen oder den asynchronen Bus ist der Adress-Zyklus synchron. Der DTC verläßt sich auf die Tatsache, daß eine Adresse in einem einzigen RCLK-Zyklus übertragen werden kann. Dieser synchrone Transfer ist durch den externen Adress-Signalspeicher verdeckt.
Den Signalen DSACK0-DSACK1 ist es erlaubt, auf dem asynchronen Bus versetzt zu sein. Ein Übergang auf einem dieser Signale veranlaßt einen Datenzyklus nach der Synchronisationsperiode zu enden. Jedoch, wenn sich das andere Signal während der Synchronisationsperiode ändert, akzeptiert der DTC die Änderung, solange sie in Bezug zu RCLK mit einer gültigen Einstell-Zeit stattfindet. Andere Signale, welche einen Datenzyklus (IRBERR, *EOP) beenden, können ähnlich versetzt sein.
Eine zusätzliche Systembetrachtung ist das "Davor"- und "Danach"-Sichten von Daten, die über den DTC übertragen werden. Fig. 11 und 12 sind dargestellt, um einen Datenort sowohl für Ortsbus- als auch Fern-Bus-Datentransfers zu und von dem neuen DTC zu veranschaulichen.
Fig. 11 faßt die verschiedenen Möglichkeiten für den Ort von Daten auf dem Ortsbus zusammen.
Wenn ein Byte oder Halb-Wort von Daten von dem DTC auf dem Ortsbus transferiert wird, ist es relativ zum Ortsbus rechts gebunden. Somit erscheint ein Byte auf D7-D0 und ein Halb-Wort erscheint auf D15-D0. Die restlichen Bus- Signale werden gemäß der bevorzugten Ausführungsform der Erfindung LOW getrieben.
Falls ein Daten-Byte oder Halbwort zum DTC vom Ortsbus transferiert ist, ist es relativ zu diesem Bus rechts gebunden. So erscheint ein Byte auf D7-D0 und ein Halbwort erscheint auf D15-D0. Die restlichen Signale werden ignoriert.
Fig. 12 faßt die verschiedenen Möglichkeiten für den Ort von Daten auf dem Fern-Bus zusammen.
Wenn ein Daten-Byte oder -Halb-Wort zum DTC zu einer Vorrichtung oder einem Speicher auf dem Fern-Bus transferiert wird, wird es an jeder Byte- oder Halbwort-Position auf dem Fern-Bus repliziert. Somit erscheint ein Byte auf RAD31 - RAD24, RAD23 - RAD16, RAD15 - RAD8 und RAD7 - RAD0. Ein Halb-Wort erscheint auf RAD31 - RAD16 und RAD15 - RAD0.
Wenn ein Daten-Byte oder Halb-Wort von dem Fern-Bus zum DTC transferiert wird, erscheint es auf dem Bus an einer Position, die durch das Data-Location- Feld des Channal-Mode-Registers oder des Port-Mode-Registers, das dem Transfer zugeordnet ist, bestimmt ist. Vier mögliche Ausrichtungen werden unterstützt:
1. Nach Adresse. Ein Byte oder Halb-Wort erscheint auf dem Bus an einer Position, die durch seine Adresse bestimmt ist.
2. Hochfixiert. Ein Byte oder Halb-Wort ist linksbündig relativ zum Bus.
3. Niedrigfixiert. Ein Byte oder Halbwort ist rechts-bündig relativ zum Bus.
4. Niedrigfixiert/Bytes nach Adresse. Ein Halb-Wort ist rechts-bündig relativ zum Bus und Bytes erscheinen innerhalb der 16 Bits niedriger Ordnung des Busses, wie durch ihre Adressen bestimmt ist.
Man beachte, daß wenn die Position eines Bytes oder Halb-Wortes von seiner Adresse abhängt (Optionen 1 und 4), daß die momentane Position eines speziellen Byte oder Halb-Wortes nicht nur durch die Adresse bestimmt ist, sondern auch durch die Byte- und Halb-Wort-Reihenfolge, wie sie durch das Remote-Byte- Order-(RBO)-Bit des entsprechenden Channel-Mode- oder Port-Mode-Register spezifiziert ist. Man beachte auch, daß mit Bezug auf jede der obigen Optionen jegliche Bus-Signale, die an einem Transfer nicht beteiligt sind, ignoriert werden.
Es sollte nun verständlich sein, daß der DTC zwei primäre Schnittstellen zu dem System enthält; den Ortsbus und den Fern-Bus. Diese Schnittstellen lassen eine Vielzahl verschiedener Systemkonfigurationen zu. Jede Schnittstelle arbeitet typischerweise mit einem unabhängigen Takt.
Gemäß der bevorzugten Ausführungsform der Erfindung, die im Kontext eines Betriebs mit (oder innerhalb) eines RISC-Systems beschrieben wurde, ist der Ortsbus-Betrieb synchron mit dem SYSCLK-Eingang. Dieser Eingang wird entweder durch den SYSCLK-Ausgang des RISC-Prozessors getrieben oder wird durch einen getrennten Takt-GeneraPort angetrieben, der ebenso den SYSCLK- Eingang des RISC-Prozessors treibt.
Ein Fern-Bus-Betrieb wird zeitlich mit dem RCLK-Signal abgestimmt (ein Fern- Bus-Betrieb kann entweder synchron oder asynchron zu RCLK sein). Der DTC unterstützt zwei Verfahren einer System-Takt-Erzeugung und -Verteilung.
In einer Taktgeber-Anordnung erzeugt der DTC einen RCLK-Takt für den Fern- Bus: dieser Takt erscheint auf dem RCLK-Pin und kann extern an weitere Fern- Bus-Komponenten verteilt werden. In der zweiten Anordnung gibt es eine unabhängige Takterzeugung für den Fern-Bus; in diesem Fall empfängt der DTC einen extern erzeugten Takt auf dem RCLK-Pin. In beiden Anordnungen sind die beiden Schaltungen, die RCLK erzeugen und puffern so aufgebaut, daß sie den offensichtlichen Versatz zwischen internen DTC-Takten und externen Fern-Bus- Takten minimieren.
Der DTC stellt einen Stromversorgungs-Pin für den RCLK-Treiber zur Verfügung, der unabhängig von der gesamten weiteren Chip-Stromversorgung ist. Das isoliert elektrisch weitere DTC-Schaltungen vom Rauschen, welches durch den RCLK-Treiber auf die Stromversorgung induziert sein könnte. Die getrennte Stromversorgung wird auch verwendet, um zwischen den zwei möglichen Taktgeber-Anordnungen zu entscheiden.
Falls Spannung (d. h. +5 Volt) an dem RCLK-Stromversorgungs-Pin angelegt ist, ist der DTC so konfiguriert, daß er Takte für den Fern-Bus erzeugt. In diesem Fall ist der RCLK-Pin ein Ausgang und das Signal auf ROSC wird verwendet, um den Fern-Bus-Takt zu erzeugen. Der DTC teilt das ROSC-Signal bei der Erzeugung von RCLK durch zwei, so daß ROSC mit der doppelten Betriebsfrequenz des Fern-Busses angetrieben sein sollte.
Wenn der RCLK-Stromversorgungs-Pin geerdet ist, ist der DTC konfiguriert, einen extern erzeugten Takt zu empfangen. In diesem Fall ist der RCLK-Pin ein Eingang, der direkt als DTC-Taktgeber benutzt wird. Der RCLK sollte mit der Betriebsfrequenz des Fern-Busses angetrieben sein. In dieser Konfiguration sollte der ROSC-Eingang auf HIGH-oder-LOW festgelegt sein, mit Ausnahme von bestimmten Übergeordnet/Untergeordnet-Konfigurationen, wie nachfolgend dargestellt.
Der RCLK-Pin ist während der ersten Hälfte des Fern-Bus-Taktzyklus HIGH und während der zweiten Hälfte des Fern-Bus-Zyklus LOW. Somit beginnt ein Zyklus bei einem LOW-zu-HIGH-Übergang von RCLK. Die Definition des Beginns des Fern-Bus-Taktzyklus ist unabhängig von der Taktgeber-Anordnung, die für ein spezielles System gewählt wurde.
In einigen Systemen könnte es wünschenswert sein, zwei oder mehr DTCs zu haben, die in einer verriegelten Stufensynchronisation arbeiten, wobei jeder durch ein gemeinsames ROSC-Signal angetrieben ist. In diesem Fall wird eine Synchronisation durch die *RESET-Eingabe erreicht. Wenn das Verneinen von *RESET mit einer spezifizierten Einstell-Zeit mit Bezug zu dem LOW-zu-HIGH-Übergang von ROSC zusammenpaßt, ist garantiert, daß die RCLK-Ausgabe in dem nächsten Halbzyklus LOW ist. Somit können alle DTCs, wie erfordert, synchronisiert werden.
Soweit DTC-elektrische Spezifikationen betroffen sind, (mit Bezugnahme zu RCLK) sind diese von den Spezifikationen für die meisten anderen DTC- Eingänge und -Ausgänge verschieden. Um Takt-Versatz-Effekte zu reduzieren, ist der RCLK-Pin eher mit CMOS-Schaltungen elektrisch kompatibel, als mit TTL-Schaltungen kompatibel, die verwendet werden, um einen DTC-Chip herzustellen.
Man beachte, daß der RCLK-Pin durch den Testmodus (nachfolgend zu beschreiben) in den Hoch-Impedanz-Status gesetzt ist. Wenn ein extern erzeugter Takt in diesem Fall nicht geliefert wird, kann der DTC-Status verloren gehen.
Der Testmodus ermöglicht es, daß DTC-Ausgänge direkt für ein DTC-Testen oder diagnostische Zwecke angetrieben werden. Der Testmodus setzt alle Ausgänge (mit Ausnahme von MSERR) in den Hoch-Impedanz-Status, so daß sie elektrisch nicht mit extern gelieferten Signalen interferieren. In jeder anderen Hinsicht ist der DTC-Betrieb unverändert.
Der Testmodus wird durch einen aktiven Pegel an der *TEST-Eingabe aufgerufen. Das Sperren von DTC-Ausgängen wird kombinatorisch durchgeführt. Es findet statt, selbst wenn keine Takte an den DTC angelegt sind.
Für einige Ausgänge kann der Übergang zu dem Hoch-Impedanz-Status, der aus dem Testmodus resultiert, mit einer viel geringeren Rate stattfinden, als sie während eines normalen DTC-Betriebes zutrifft (z. B. wenn der DTC auf den Ortsbus verzichtet). Aus diesem Grund kann der Testmodus für spezielle, Benutzerdefinierte Zwecke nicht geeignet sein. Eine weitere Betrachtung des Systems ist, daß jeder DTC-Ausgang eine zugeordnete Logik hat, die das Signal an dem Ausgang mit dem Signal, das der DTC intern zu dem Ausgangstreiber liefert, vergleicht. Der Vergleich zwischen den zwei Signalen wird zu jedem Zeitpunkt gemacht, wenn ein gegebener Treiber freigegeben ist und zu jedem Zeitpunkt, wenn der Treiber nur wegen des Testmodus gesperrt ist. Wenn der Vergleich gemacht ist und wenn der Ausgangstreiber nicht mit seinem Eingang übereinstimmt, bestätigt der DTC die MSERR-Ausgabe auf dem nächsten von SYSCK oder RCLK, abhängig davon ob der Fehler auf dem Ortsbus oder dem Fern-Bus detektiert worden ist.
Wenn der DTC MSERR bestätigt, nimmt er keine weiteren Aktionen mit Bezug auf den detektierten Miß-Vergleich vor. Jedoch kann MSERR extern verwendet werden, um irgendeine Systemfunktion durchzuführen, einschließlich der Erzeugung eines Traps.
Wenn es einen einzigen DTC in dem System gibt, zeigt die MSERR-Ausgabe an, daß ein DTC-Treiber fehlerhaft ist, oder daß es einen Kurzschluß in einem DTC- Ausgang gibt. Jedoch ist ein viel höheres Niveau einer Fehlerdetektion möglich, wenn ein zweiter DTC ("Slave" genannt) parallel mit dem ersten ("Master" genannt) verbunden ist, wobei der untergeordnete DTC Ausgänge hat, die durch den Testmodus gesperrt sind.
Der untergeordnete DTC führt durch Vergleichen seiner Ausgaben mit den Ausgaben des Übergeordneten eine vergleichende Prüfung des Betriebs des Übergeordneten durch. Zusätzlich kann der Untergeordnete offene Schaltungen oder andere Fehler in den elektrischen Pfaden detektieren, die durch den Übergeordneten benutzt werden, um mit dem System zu kommunizieren. Man beachte, daß der Übergeordnete in dieser Konfiguration noch den Vergleich auf seine Ausgaben durchführt.
Wenn zwei DTCs in einer Übergeordnet/Untergeordnet-Konfiguration verbunden sind, ist es notwendig, falsche Bestätigungen des MSERR zu verhindern. Diese resultieren aus Situationen, wo die Ausgaben des untergeordneten DTCs nicht mit den Ausgaben des Übergeordneten übereinstimmen, jedoch beide korrekt arbeiten.
Eine Quelle falscher Fehler können unvorhersehbare Werte für nicht implementierte Bits in DTC-Registern sein. Dieses potentielle Problem wurde durch die bevorzugte DTC-Architektur vermieden, bei der alle nicht implementierten Bits als 0 gelesen werden.
Eine zweite Quelle für falsche Fehler betrifft Daten, die von dem Fern-Bus zu dem Ortsbus transferiert werden. In speziellen Fällen transferiert der DTC Daten, die ein "kümmere-dich-nicht" sind; z. B. wenn ein einzelnes Byte von dem Ortsbus über einen I/O-Port übertragen wird. Wenn die ignorierten Dateneingaben nicht bei einem gültigen logischen Pegel sind und wenn sie schließlich auf einen anderen Bus reflektiert werden, können zwei DTC's in dem Wert für die Daten, wegen des ungültigen logischen Pegels, nicht übereinstimmen. Der DTC vermeidet dieses Problem durch ein Auffüllen von Daten mit Nullen und durch Wiederholen von Daten, um "kümmere-dich-nicht" zu maskieren.
Eine weitere Quelle falscher Fehler ist ein Mangel an Synchronisation zwischen den übergeordneten und untergeordneten DTCs. Um eine Synchronisation zwischen dem Übergeordneten und dem Untergeordneten aufrecht zu erhalten ist es zunächst notwendig, daß sie mit identischen Takten arbeiten. Dies wird erreicht, indem der übergeordnete RCLK antreibt, wobei der untergeordnete RCLK als eine Eingabe empfängt, oder durch ein Treiben sowohl des Übergeordneten als auch des Untergeordneten mit demselben extern erzeugten RCLK.
Jedoch ist die Tatsache, daß sowohl übergeordnete als auch untergeordnete DTCs mit demselben Takt arbeiten nicht ausreichend, um eine Synchronisation zu garantieren. Asynchrone Eingaben können den Übergeordneten einen Zyklus eher oder später beeinflussen, als sie den Untergeordneten beeinflussen. Aus diesem Grund muß der Fern-Bus eine synchrone Betriebsweise in einer Übergeordnet/Untergeordnet-Konfiguration haben, oder extern an einem gemeinsamen Punkt synchronisiert sein. Man beachte auch, daß der Aktiv-zu-Inaktiv-Übergang des *RESET synchronisiert sein muß.
In einigen Übergeordnet/Untergeordnet-Konfigurationen könnte es wünschenswert sein, dem untergeordneten DTC die Steuerung über das System zu geben, wenn ein Fehler auf den übergeordneten DTC isoliert ist. Es ist möglich, dem Untergeordneten die Steuerung zu erteilen, indem man ihn aus dem Testmodus herausnimmt und den Übergeordneten in den Testmodus setzt. Eine Synchronisation muß aufrecht erhalten werden, wenn dies erreicht ist.
Wenn der ursprüngliche Übergeordnete so konfiguriert ist, in diesem Fall RCLK zu erzeugen, muß der Untergeordnete ebenfalls RCLK erzeugen, wenn er ein Übergeordneter wird. Deshalb muß das ROSC-Signal sowohl zu dem Übergeordneten als auch dem Untergeordneten zugeführt werden, wobei beide so konfiguriert sind, Takte zu erzeugen.
In dieser Übergeordnet/Untergeordnet-Konfiguration empfängt der Untergeordnete immernoch RCLK von dem Übergeordneten, wie zuvor beschrieben wurde. Der Untergeordnete treibt wegen des Testmodus nicht RCLK an. Jedoch ist er in der Lage, wie erforderlich, RCLK anzutreiben, wenn der Untergeordnete aus dem Testmodus herausgenommen ist. Ein Fachmann wird bestätigen, daß das Schaltschema, das hier zuvor beschrieben wurde auf mehr als 2 DTCs verallgemeinert werden kann.
Als eine abschließende Betrachtung des Systems, sollte betont werden, daß einige Standard-Busse eine Operation für eine dynamische Bus-Größenanpassung unterstützen, wobei die Datenbreite für einen Transfer dynamisch während des Transfers bestimmt wird. Der DTC unterstützt diese Funktion nicht direkt, liefert jedoch die Merkmale, die notwendig sind, um sie auf einem höheren Niveau zu unterstützen.
Wenn der DTC eine Antwort auf einen Transfer empfängt, die anzeigt, daß der angeforderte Transfer nicht durchgeführt werden kann (entweder durch DSACK0 -DSACK1 von *RBERR) verursacht er einen Trap oder Interrupt zu dem RISC- Prozessor. Für einen I/O-Port-Zugriff antwortet der DTC mit *DERR und für einen DMA-Kanal bestätigt der DTC *INTR (wenn Interrupts freigegeben sind).
Der antwortende Interrupt- oder Trap-Handler hat die Option, die Datenbreite auf dem angezeigten I/O-Port oder DMA-Kanal zu reduzieren, oder einen weiteren I/O-Port oder DMA-Kanal zuzuteilen, um die kleinere Datenbreite zu behandeln. Das Data-Size-Acknowledge-Feld des entsprechenden Port-Status-Registers oder Channel-Status-Registers zeigt die DASCK0-DASCK1-Antwort an, die den Fehler verursacht hat. Der ursprüngliche Transfer kann erneut gestartet werden.
Man beachte, daß, wenn die Datenbreite eines I/O-Ports oder DMA-Kanals reduziert ist, alle Transfers über diesen I/O-Port oder DMA-Kanal so behandelt werden, als hätten sie die spezifizierte Breite. Zum Beispiel werden Transfers zu einer Wort-Vorrichtung mit einem Byte zu einem Zeitpunkt durchgeführt, falls die Breite des I/O-Ports oder DMA-Kanals als 8 Bit spezifiziert ist. Dies wird als eine gültige Operation betrachtet und verursacht keine Ausnahme. Somit unterstützt der DTC eine dynamische Reduzierung in der Datenbreite, jedoch keine dynamische Zunahme in der Datenbreite.
Für einen I/O-Port, der ein Lese-Davor oder Schreibe-Danach durchführt, wird die Datenbreite-Ausnahme gemeldet, nachdem sie auf dem Fern-Bus aufgetreten ist und sowohl dieser Zugriff als auch der Zugriff, der die *DERR-Antwort empfängt, müssen erneut gestartet werden. In diesem Fall muß der erste Zugriff explizit durch ein Laden oder Speichern erneut gestartet werden, unter Verwendung der nicht übersetzten I/O-Port-Adresse in dem Local-Port-Address-Register. Der zweite Zugriff wird durch die Channel-Address, Channel-Data- und Channel- Control-Register in dem RISC-Prozessor erneut gestartet. Man beachte, daß der erste Zugriff entweder in dem Benutzer- oder Supervisor-Modus erneut gestartet werden kann, da irgendeine Schutzverletzung vorher erfaßt worden wäre.
Nachdem der neue DTC in Einzelheiten bezüglich seiner Funktion, seiner internen Register, Eingaben und Ausgaben, Datenformate und unterstützten Transfers, etc. beschrieben worden ist, wird ein Fachmann bescheinigen, daß die Ziele der Erfindung, die hier zuvor dargelegt wurden, erreicht worden sind.
Die vorhergehende Beschreibung einer bevorzugten Ausführungsform und veranschaulichender Beispiele der neuen Verfahren und der Vorrichtung wurden ausschließlich für Veranschaulichungszwecke und Beschreibungszwecke dargelegt. Es ist nicht beabsichtigt, erschöpfend zu sein oder die Erfindung auf die genaue offenbarte Form zu beschränken und offensichtlicherweise sind viele Modifikationen und Abänderungen im Lichte der obigen Lehre möglich.
Die Ausführungsform und zuvor dargelegte Beispiele wurden in einer Reihenfolge dargestellt, um die Grundlagen der unmittelbaren Erfindung und ihrer praktischen Anwendung zu erläutern, um dadurch andere Fachleute in die Lage zu versetzen die unmittelbare Erfindung in verschiedenen Ausführungsformen und mit verschiedenen Modifikationen bestmöglich zu benutzen, wie sie für die spezielle in Erwägung gezogene Verwendung geeignet sind.
Es ist beabsichtigt, daß der Umfang der unmittelbaren Erfindung durch die hieran angefügten Ansprüche definiert ist.

Claims

1. Ein-/Ausgabe-Controller zum Transferieren von Daten zu und von einem ersten Bus (110), dem ein erster Satz von Hochleistungs-Vorrichtungen, welche mindestens eine CPU (101) beinhalten, zugeordnet ist, und einem zweiten Bus (120), dem ein zweiter Satz von Vorrichtungen mit relativ niedrigerer Leistung zugeordnet ist, wobei das Transferieren von Daten zu und von den ersten (110) und zweiten (120) Bussen Kommunikation zwischen den Hoch- und Nieder-Leistungs-Vorrichtungen zuläßt, aufweisend:

(a) Ein-/Ausgabe-Controller-Einrichtungen (104, 105), welche mit dem ersten Bus (110) und dem zweiten Bus (120) gekoppelt sind, welche mindestens eine Adress-abgebildete Ein-/Ausgabe-Port- Einrichtung (302) beinhalten, um einen direkten Zugang zum zweiten Satz von Vorrichtungen durch die CPU (101) zu schaffen, wobei jede der Ein-/Ausgabe-Port-Einrichtungen (302) Adress- Übersetzungs-Einrichtungen aufweist zum Durchführen einer Adress-Übersetzung zwischen einer ersten Bus-Adress-Eingabe an den Port und einer zweiten vom Port auszugebenden Bus-Adresse, immer wenn der Port durch den ersten Bus adressiert ist;

(b) erste Verbindungseinrichtungen (301) zum Verbinden des ersten Busses (110) mit den Ein-/Ausgabe-Controller-Einrichtungen (104, 105);

(c) zweite Verbindungseinrichtungen (305) zum Verbinden des zweiten Busses (120) mit den Ein-/Ausgabe-Controller- Einrichtungen (104, 105) und

(d) ein Daten-Breite-Umwandlungsnetz (304), um einen Transfer von Daten, welche eine größere Breite auf dem ersten Bus (110) haben in mehrere Transfers von Daten, welche eine kleinere Breite auf dem zweiten Bus (120) haben, umzuwandeln und um eine Verdichtungs-Operation auf Daten durchzuführen, welche eine kleinere Breite auf dem zweiten Bus (120) haben, welche in mehreren Transfers erhalten wurden, in einen gebündelten Transfer derselben Daten, welche eine größere Breite auf dem ersten Bus (110) haben.

2. Ein-/Ausgabe-Controller nach Anspruch 1, welcher des weiteren Einrichtungen zum Priorität-Setzen für den Zugang zu den Port-Einrichtungen (302) aufweist, immer wenn eine Vielzahl von Port-Einrichtungen existiert.

3. Ein-/Ausgabe-Controller nach Anspruch 1, welcher des weiteren einen Satz von internen Registern zum Steuern und Aufrechterhalten des Status der Port- Einrichtungen (302) aufweist.

4. Ein-/Ausgabe-Controller nach Anspruch 3, wobei die ersten Verbindungseinrichtungen (301) des weiteren Einrichtungen aufweisen zum Initialisieren des Satzes von internen Registern.

5. Ein-/Ausgabe-Controller nach Anspruch 1, welcher des weiteren Einrichtungen aufweist zur Überlappungsoperation von Port-Einrichtungen des Satzes von Hochleistungs-Vorrichtungen (101), welche dem ersten Bus (110) zugeordnet sind.

6. Ein-/Ausgabe-Controller nach Anspruch 1, welcher des weiteren Einrichtungen aufweist zum Umlagern von Datenpaketorten in Worte, welche über den Controller transferiert werden.

7. Ein-/Ausgabe-Controller nach Anspruch 4, welcher des weiteren aufweist eine Vielzahl von Signalpfaden, welche benutzt werden, um von einer Hochleistungs-Vorrichtung erzeugte Signale zu und von dem Satz von internen Registern zu tragen, wobei die Vielzahl von Signalpfaden die Pins eines integrierten Schaltungspaktes (204) aufweist.

8. Ein-/Ausgabe-Controller nach Anspruch 1, welcher Entkopplungseinrichtungen aufweist zum Entkoppeln der Operation der Port- Einrichtungen (302) von der Programmausführung durch die CPU (101).

9. Ein-/Ausgabe-Controller nach Anspruch 8, wobei das Entkoppeln durch Vorrichtungen zum Durchführen einer überlappten Eingabe/Ausgabe über die Ausführung einer Lese-Davor/Schreibe-Dahinter-Operation ausgeführt wird.

10. Ein-/Ausgabe-Controller nach Anspruch 1, welcher des weiteren Einrichtungen aufweist zum Bestimmen, ob eine erste Bus-Adress-Eingabe an die Port-Einrichtungen (302) innerhalb eines vorgewählten Port-Einrichtungs- Adress-Raumes ist.

11. Ein-/Ausgabe-Controller nach Anspruch 10, wobei jede der Port- Einrichtungen (302) aufweist:

(a) Einrichtungen zum Durchführen einer Adress-Übersetzung zwischen einer ersten Bus-Adress-Eingabe an den Port und einer zweiten vom Port auszugebenden Bus-Adresse, immer wenn der Port durch den ersten Bus (110) adressiert ist, und wobei die Adress-Übersetzung über einen Adressenbereich einer Potenz von zwei (des ersten Busses) durchgeführt wird zu einem unabhängigen Bereich von Adressen des zweiten Busses (120); und

(b) wobei die Adress-Übersetzungs-Einrichtungen Maskier- Einrichtungen aufweisen, um eine vorgewählte Anzahl von höherrangigen Bits von der ersten Bus-Adresse auszumaskieren und die Bits mit derselben Anzahl von höherrangigen Bits einer zweiten Bus-Adresse zu ersetzen.

12. Ein-/Ausgabe-Controller nach Anspruch 1, wobei jede der Port-Einrichtungen (302) eine Multiplexer-Einrichtung (603, 803, 806) aufweist, um Daten zu und von dem Daten-Breite-Konvertier-Netz (304) zu multiplexieren.

13. Ein-/Ausgabe-Controller nach Anspruch 9, wobei jede der Port-Einrichtungen (302) des weiteren ein Pufferregister (604, 805) aufweist zum Zwischenspeichern von Daten, welche zu und von dem Daten-Breite- Konvertier-Netz (304) überragen werden.

14. Ein-/Ausgabe-Controller nach Anspruch 13, dadurch gekennzeichnet, daß verdichtete Daten von dem Daten-Breite-Konvertier-Netz (304) erhalten werden zum Speichern im Pufferregister und ein nachfolgender Zugriff auf einen gegebenen Port über den ersten Bus (110) verhindert wird, während der Port eine Lese-Davor/Schreibe-Dahinter-Operation durchführt.

15. Ein-/Ausgabe-Controller nach Anspruch 13, wobei im Pufferregister gespeicherte Daten über das Daten-Breite-Konvertier-Netz (304) in mehreren Transfers zum zweiten Bus (120) gesendet werden.

16. Ein-/Ausgabe-Controller nach Anspruch 9, welcher des weiteren Einrichtungen aufweist zum Durchführen der Lese-Davor/Schreibe-Dahinter- Operationen parallel, wobei eine erste der Port-Einrichtungen benutzt wird, um die Lese-Davor-Funktion durchzuführen, während eine zweite der Port- Einrichtungen benutzt wird, um die Schreibe-Dahinter-Funktion parallel durchzuführen.

17. Ein-/Ausgabe-Controller nach Anspruch 1, welcher des weiteren aufweist:

(a) Einrichtungen zum Unterstützen einer intern programmierten Eingabe/Ausgabe; und

(b) Einrichtungen zum Unterstützen einer entfernt programmierten Eingabe/Ausgabe.

18. Ein-/Ausgabe-Controller nach Anspruch 1, welcher des weiteren Einrichtungen aufweist zum Entkoppeln der Latenz und Bandbreite von Zugriffen auf den ersten Bus (110) von der Latenz und Bandbreite von Zugriffen auf den zweiten Bus (120), mit Gleichzeitigkeit zwischen den Zugriffen auf beide Busse.

19. Verfahren zum Transferieren von Daten zu und von einem ersten Bus (110), dem ein erster Satz von Hochleistungsvorrichtungen zugeordnet ist, welche mindestens eine CPU (101) beinhalten, und einem zweiten Bus (120), dem ein zweiter Satz von Vorrichtungen mit relativ niedrigerer Leistung zugeordnet ist, gekennzeichnet durch die Schritte:

(a) Transferieren von Daten zwischen dem ersten Bus (110) und dem zweiten Bus (120), wobei Eingabe-/Ausgabe-Controller- Einrichtungen (104, 105) benutzt werden, welche mindestens eine Adress-abgebildete Ein-/Ausgabe-Port-Einrichtung (302) beinhalten, welche an die Busse gekoppelt ist;

(b) Verbinden des ersten Busses (110) mit den Ein-/Ausgabe- Controller-Einrichtungen (104, 105);

(c) Verbinden des zweiten Busses (120) mit den Ein-/Ausgabe- Controller-Einrichtungen (104, 105);

(d1) Konvertieren eines Transfers eines ersten Datenelements, welches eine erste Breite hat, in mehrere Transfers eines zweiten Datenelements, welches eine zweite Breite hat, welche kleiner ist als die erste Breite, wenn das erste Datenelement vom ersten Bus (110) zum zweiten Bus (120) transferiert wird; und

(d2) Konvertieren mehrerer Transfers des zweiten Datenelements, welches die zweite Breite hat, in eine kleinere Menge von Transfers des ersten Datenelements, welches die erste Breite hat, wenn das zweite Datenelement vom zweiten Bus (120) zum ersten Bus (110) transferiert wird.

20. Verfahren nach Anspruch 19, gekennzeichnet durch den weiteren Schritt des Multiplexierens von Adresssignalen und Datensignalen, wenn diese zum zweiten Bus (120) durch die Controller-Einrichtungen (104, 105) transferiert werden.

21. Verfahren nach Anspruch 19, gekennzeichnet durch den weiteren Schritt zur Überlappungs-Operation von Port-Einrichtungen mit der Operation des Satzes von Hochleistungsvorrichtungen, welche dem ersten Bus (110) zugeordnet sind.

22. Verfahren nach Anspruch 19 oder 21, gekennzeichnet durch den weiteren Schritt des Entkoppelns der Operation der Port-Einrichtungen innerhalb der Controller-Einrichtungen (104, 105) von der Programm-Ausführung durch die CPU (101).

23. Verfahren nach Anspruch 19, welches des weiteren den Schritt des Bestimmens aufweist, ob eine erste Bus-Adress-Eingabe in die Port- Einrichtungen (302) innerhalb eines vorgewählten Port-Einrichtung-Adress- Raumes ist und immer wenn der Port durch den ersten Bus (110) adressiert ist, Übersetzen der ersten eingegebenen Bus-Adresse in eine zweite von dem Port auszugebende Bus-Adresse.

24. Verfahren nach Anspruch 23, wobei der Schritt des Übersetzens durchgeführt wird durch Ausmaskieren einer vorgewählten Anzahl von hochrangigen Bits von der ersten Bus-Adresse und Ersetzen der Bits mit derselben Anzahl von hochrangigen Bits einer zweiten Bus-Adresse.

25. Verfahren nach Anspruch 22, wobei das Entkoppeln über das Durchführen einer überlappten Eingabe/Ausgabe ausgeführt wird, durch die Implementierung von Lese-Davor/Schreibe-Danach-Operationen und über einen weiteren Schritt eines Zwischenspeicherns von durch die Port- Einrichtungen (302) zu und von dem zweiten Bus (120) transferierten Daten.

26. Verfahren nach Anspruch 25, welches des weiteren den Schritt aufweist des Verhinderns eines nachfolgenden Zugriffs auf einen gegeben Port über den ersten. Bus (110), während der Port eine Lese-Davor/Schreibe-Danach- Operation durchführt.