DE69032608T2

DE69032608T2 - Übertragung zwischen Prozessoren

Info

Publication number: DE69032608T2
Application number: DE69032608T
Authority: DE
Inventors: Ernest Dysart Raleigh North Carolina 27614 Baker; John Monroe Jr. West Palm Beach Fl 33414 Dinwiddie; Lonnie Edward Boca Raton Fl 33431 Grice; James Maurice Boca Raton Fl 33486 Joyce; John Mario Deerfield Beach Fl 33414 Loffredo; Kenneth Russell West Palm Beach Fl 33414 Sanderson
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1989-05-17
Filing date: 1990-05-16
Publication date: 1999-05-27
Anticipated expiration: 2010-05-17
Also published as: CN1047931A; EP0398697A3; KR900018832A; BR9002305A; AU628548B2; JP2618074B2; AU5487090A; KR940002340B1; EP0398697B1; CA2009780C; SG45152A1; CN1040480C; ATE170644T1; CA2009780A1; JPH03171250A; EP0398697A2; DE69032608D1; PE34490A1

Description

Einführung

Beschreibung einer bevorzugten Ausführungsform

Einleitung

1. Betrieb eines normalerweise nicht fehlertoleranten Prozessors in einer fehlertoleranten Umgebung
2. Abkoppeln eines Prozessors von seiner zugeordneten Hardware, um Befehle und Daten von einem anderen Prozessor selbst zu übernehmen
3. Für das Betriebssystem transparente Übernahme von Interrupts durch ein System
4. Aufteilen eines Realspeichers zwischen zwei oder mehr Prozessoren, die unterschiedliche Betriebssysteme mit virtuellen Speichern ausführen
5. Einzelsystembild
6. Zusammenfassung
System/88 auf dem Stand der Technik, Einzelheiten
Fehlertolerantes S/370 Modul 9, zusammengeschaltet über Verbindungsglieder, Netzwerke
Allgemeine Beschreibung von Duplex-Prozessor-Partnereinheiten 21, 23
Kopplung von S/370 und S/88 Prozessorelementen 85, 62
Prozessor/Prozessor-Schnittstelle 89
1. E/A-Adapter 154 (Anm.: Benutzt Fig. 18 für IOA)
2. E/A-Adapterkanal 0 und -kanal 1 Bus
3. Bus-Steuereinheit 156 - allgemeine Beschreibung
4. Direktspeicherzugriff-Controller 209
5. Bussteuereinheit 156 - Detaillierte Beschreibung
(a) Schnittstellenregister für Hochgeschwindigkeits-Datenübertragung
(b) BCU Abkopplungs- und Unterbrechungslogik 215, 216
(c) BCU Adressenabbildung
(d) Örtliche Adressen- und Datenbusoperationen
(e) S/88 Prozessor 62 und DMAC209
Adressieren zum/vom örtlichen Speicher 210
(f) BCU Basisspeichermodul (BSM) RD/WR Bytezähleroperation
(g) Handshake-Sequenz BCU 156/Adapter 154
S/370 Prozessorelement 85
Prozessorbus 170 und Prozessorbus-Befehle
S/370 Speicherverwaltungseinheit 81
1. Cache-Controller 153
2. STCI 155
(a) Einleitung
(b) Systembusphasen
(c) STCI-Merkmale
(d) Datenspeicheroperationen
(e) Datenabrufoperationen
S/370 E/A-Unterstützung
S/370 E/A-Operationen, Firmware-Übersicht
System-Mikrocodeaufbau
1. Einleitung
2. ETIO/EXEC370 Programmschnittstelle
3. EXEC370, S/370 Mikrocode-Protokoll
4. Anweisungsflüsse zwischen S/370 Mikrocode und EXEC370
Operation der Bussteuereinheit (BCU) 156
1. Einleitung
2. S/370 Start E/A-Sequenzfluß, allgemeine und detaillierte Beschreibung
3. S/370 E/A-Datentransfersequenzfluß, allgemeine Beschreibung
(a) E/A-Schreiboperationen:
(b) E/A-Leseoperation:
(c) S/370 Hochprioritäts-Meldungstransfersequenzfluß
(d) BCU-Statusbefehl
(e) Programmierter BCU-Reset
Zähler-, Schlüssel- und Datenspurformat-Emulation
1. Objektsystem
2. Zielsystem
3. Emulationsformat
4. Emulationsfunktionen
Gemeinsames Benutzen von Realspeicher 16 durch S/88 und S/370
1. Einleitung
2. Abbilden des S/88 Speichers 16
3. Inbetriebnahme
4. Start des S/370 Dienstprogramms
5. Gewählte Kette MMC's von Freiliste holen
6. Schreiben von Speicherbasis und -größe in die STCI
Einleiten von Funktionen zum Abkoppeln von S/88 Interrupts eingeleitet vom S/370
Freiheit gewinnen ohne Verändern des S/88 Betriebssystems
Speicherraum stehlen ohne Verändern des S/88 OS
Einschalten und Synchronisieren der Simplex- und Partnereinheiten 21, 23
(S/88 Prozessoreinheit als Dienstprozessor für S/370 Prozessoreinheit)
1. Einleitung
2. Fehlertolerante Hardware-Synchronisierung
3. Eine Simplex-Prozessoreinheit 21 wird hochgefahren
(a) Hardware-Implementierung
(b) Nur-Mikrocode-Implementierung
4. Duplex-Prozessoreinheiten 21, 23 werden hochgefahren
(a) Hardware-Implementierung
(b) Nur-Mikrocode-Implementierung
5. Ein Partner 23 wird zugeschaltet während die andere Einheit 21 normal arbeitet
(a) Hardware-Implementierung
(b) nur Mikrocode-Implementierung
6. Ein Partner erfaßt einen Vergleichsfehler
(a) Hardware-Implementierung
(b) nur Mikrocode-Implementierung

Alternative Ausführungsformen

1. Anwendung in anderen (Nicht-S/88) fehlertoleranten Systemen
2. Direkte Datenübertragungen zwischen S/88 E/A- Controllern und S/370 Hauptspeicher
3. Abkoppeln der beiden Prozessoren eines direkt verbundenen Paars

ÜBERTRAGUNG ZWISCHEN PROZESSOREN

Die vorliegende Erfindung betrifft die Datenübertragung zwischen Prozessoren.
Die Übertragung von Daten zwischen Anwendungsprogrammen ist bekannt und erfordert in der Regel eine komplexe Verschaltung und die Verwendung eines Netzwerkprotokolls. Eine Möglichkeit zur Kopplung verschiedener Prozessoren und der zugehörigen Betriebssysteme ist die Verwendung von DFV-Steuereinheiten in beiden Systemen. Gewöhnlich werden Einheitentreiber hinzugefügt, auf die die Betriebssysteme zugreifen können, und zur Übertragung der Daten wird ein gemeinsamer Übertragungscode oder ein gemeinsames Protokoll benutzt. Um beispielsweise Daten zwischen Endknotenrechnern in einem Netzwerk zu übertragen, müssen alle beteiligten Endknoten einen konsistenten Satz von Diensten für die zu übertragenden Daten verstehen und anwenden.
Um die Komplexität des Systems zu verringern und eine Austauschbarkeit zu ermöglichen, sind die meisten Übertragungsnetzwerke in Form mehrerer Schichten oder Ebenen organisiert, wobei jede Schicht oder Ebene auf die darunterliegende aufbaut. Die Anzahl der Schichten sowie Namen und Funktionen der einzelnen Schichten unterscheiden sich von Netzwerk zu Netzwerk. Der Zweck jeder Schicht besteht jedoch in allen Netzwerken darin, Dienste für die höheren Schichten zu leisten und diese von den Einzelheiten der tatsächlichen Implementierung dieser Dienste abzuschirmen. Telefonleitungen beispielsweise können in einer entsprechenden Schicht leicht durch Funkkanäle ersetzt werden.
In Wirklichkeit werden von der Schicht n auf einer Maschine zur Schicht n einer anderen Maschine keine Daten direkt übertragen (mit Ausnahme der untersten Schicht, d. h. der physika lischen Schicht). Das heißt, es kann kein direktes Ankoppeln von Applikationsprogrammen geben, die auf unterschiedlichen oder unabhängigen Systemen arbeiten. Statt dessen überträgt jede Schicht Daten- und Steuerinformationen auf die unmittelbar unter ihr liegende Schicht, bis die unterste Schicht erreicht ist. Auf der untersten Schicht gibt es eine physikalische Kommunikation mit der anderen Maschine, anders als bei der virtuellen Kommunikation, die von höheren Schichten einschließlich der Anwendungsschicht benutzt wird.
Mit der vorliegenden Erfindung wurde deshalb eine Datenverarbeitungsvorrichtung zur Übertragung von Daten zwischen verschiedenen Prozessoren entwickelt. Diese Vorrichtung besteht aus: einem ersten Prozessor, der durch ein unter einem ersten Betriebssytem laufendes Anwendungsprogramm gesteuert wird; und einem zweiten Prozessor, der durch ein unter einem zweiten Betriebssystem laufendes Anwendungsprogramm gesteuert wird, wobei das zweite Betriebssystem die Ressourceneinheitendienste für die Datenverarbeitungsvorrichtung zur Verfügung stellt, wobei Konfigurationstabellen, in denen die Systemressourcen für das zweite Betriebssystem angegeben sind, keine Daten enthalten, welche das erste Betriebssystem identifizieren. Die Verbesserung umfaßt dabei Mittel zum Abkoppeln des zweiten Prozessors vom zweiten Betriebssystem und ein zwischen die Prozessoren gekoppeltes Informationsübertragungsmittel, das die direkte Übertragung von Informationen zwischen dem ersten und dem zweiten Anwendungsprogramm ermöglicht, während der zweite Prozessor von zweiten Betriebssystem abgekoppelt ist.
Die vorliegende Erfindung liefert Mittel zur Direktübertragung von Daten zwischen auf verschiedenen Prozessoren laufenden Anwendungsprogrammen, ohne daß die Dienste von einem oder beiden der beteiligten Betriebssysteme benutzt werden.
Ein Computersystem mit mehreren verschiedenen Betriebssystemen besteht aus einem ersten Prozessor, der durch ein unter einem ersten Betriebssytem laufendes Anwendungsprogramm gesteuert wird einem zweiten Prozessor, der durch ein unter einem zweiten Betriebssystem laufendes Anwendungsprogramm gesteuert wird, wobei das zweite Betriebssystem die Ressourceneinheitendienste für die Datenverarbeitungsvorrichtung zur Verfügung stellt; sowie einer zwischen die Prozessoren geschaltete Datenübertragungsvorrichtung, die die direkte Übertragung von Daten zwischen dem ersten und dem zweiten Anwendungsprogramm ohne Verwendung der Dienste des zweiten Betriebssystems ermöglicht.
In einem Computersystem mit einem ersten und einem zweiten Anwendungsprogramm, die einen unter einem ersten Betriebssystem arbeitenden ersten Prozessor und einen unter einem zweiten Betriebssystem arbeitenden zweiten Prozessor steuern, wobei das zweite Betriebssystem Dienste wie Ressourcenzuteilung, Zeitaufteilung auf die einzelnen Programme, Ein-/Ausgabesteuerung und Datenverwaltung für das Computersystem leistet, umfaßt die Verbesserung Logikmittel, die die direkte Übertragung von Daten zwischen dem ersten und dem zweiten Anwendungsprogramm übernehmen, ohne auf die Dienste eines der Betriebssysteme oder beider Betriebssysteme zurückzugreifen.
Die Namen IBM und System/370, auf die im folgenden Bezug genommen wird, sind Warenzeichen der International Business Machines Corporation.
Damit die Erfindung voll verstanden wird, soll nachstehend beispielhaft eine Ausführungsform derselben anhand der begleitenden Zeichnungen beschrieben werden.
Fig. 1 ist ein Diagramm zur Darstellung von zusammengeschalteten Standardrechnern, die eine gemeinsame Kommunikationsleitung benutzen;
Fig. 2 ist ein Diagramm zur Darstellung der Zusammenschaltung von S/88 Prozessoren in einer fehlertoleranten Umgebung;
Fig. 3 ist ein Diagramm zur Darstellung der Zusammenschaltung von S/370 Prozessoren mit S/88 Prozessoren in der bevorzugten Ausführungsform;
Fig. 4 ist ein Diagramm zur Darstellung eines S/370 Systems, das in der Art der bevorzugten Ausführungsform an ein S/88 System gekoppelt ist;
Fig. 5 zeigt als Diagramm das Abkoppeln eines S/88 Prozessors, um den Datenaustausch zwischen dem S/370 und dem S/88 der bevorzugten Ausführungsform darzustellen;
Fig. 6A, 6B und 6C zeigen als Diagramm das Modul IBM System/88 auf dem Stand der Technik, mehrere Module, die über Hochgeschwindigkeits-Datenverbindungen (HSDIs) zusammengeschlossen sind, und eine Vielzahl Module, die über ein Netz in einer fehlertoleranten Umgebung mit einem einzigen Systembild zusammengeschlossen sind;
Fig. 7 zeigt als Diagramm eine Form des verbesserten Moduls der vorliegenden Erfindung, die vorsieht, daß S/370 Prozessoren S/370 Applikationsprogramme unter der Steuerung eines S/370 Betriebssystems abarbeiten, die fehlertolerant gemacht wurden aufgrund der Art und Weise, wie die Prozessoren miteinander und mit S/88 Prozessoren, mit E/A und Hauptspeicher verschaltet sind;
Fig. 8 ist ein Diagramm, das in näheren Einzelheiten die Verschaltung von gepaarten S/370- und S/88-Einheiten miteinander zu einer Prozessoreinheit zeigt und ihren Anschluß an eine identische Partnerprozessoreinheit zum fehlertoleranten Betrieb illustriert;
Fig. 9A und 9B illustrieren eine Form des physikalischen Packens gepaarter S/370- und S/88-Einheiten auf zwei Platinen zum Einschieben in der Rückwand eines Verarbeitungssystemgehäuses;
Fig. 10 zeigt im Konzept den S/88 Hauptspeicher und Abschnitte dieses Speichers, die den S/370 Prozessoreinheiten zugewiesen sind, ohne daß das S/88 Betriebssystem Kenntnis davon hat;
Fig. 11 zeigt als Blockschaltbild bestimmte Komponenten der bevorzugten Ausführungsform eines S/370 Prozessors und Mittel zum Anschließen desselben an einen S/88 Prozessor und Speicher;
Fig. 12 zeigt die Komponenten der Fig. 11 in näheren Einzelheiten und verschiedene Komponenten einer bevorzugten Ausführungsform eines S/88 Prozessors;
Fig. 13 zeigt als Blockschaltbild den S/370 Busadapter;
Fig. 14A, 14B und 15A-C zeigen als Konzept die Taktung und die Bewegung von Daten durch die Ausgabekanäle des S/370 Busadapters;
Fig. 16 zeigt als Blockschaltbild die direkte Verschaltung zwischen einem S/370 und einem S/88 Prozessor in näheren Einzelheiten;
Fig. 17 zeigt im Konzept den Datenfluß zwischen einem S/370 Busadapter und einem DMA-Controller der Zusammenschaltung der Fig. 16;
Fig. 18 zeigt DMAC-Register für einen seiner vier Kanäle;
Fig. 19A, 19B und 19C (mit Layout in Fig. 19) sind eine schematisch-diagrammatische Illustration, die genauer als in Fig. 16 in näheren Einzelheiten eine bevorzugte Form der Bussteuereinheit zeigt, die einen S/370 Prozessor mit einem S/88 Prozessor und mit dem Hauptspeicher zusammenschaltet;
Fig. 20 ist ein Blockschaltbild einer bevorzugten Form der Logik, die den S/88 Prozessor von seiner zugeordneten Systemhardware abkoppelt, und der Logik zum Bedienen der Interrupt- Anforderungen vom außenstehenden S/370 Prozessor an den S/88 Prozessor;
Fig. 21 illustriert im Konzept die Modifizierung der vorhandenen S/88 Interrupt-Struktur für ein Modul mit einer Vielzahl von verschalteten S/370 - S/88 Prozessoren gemäß der Lehre der vorliegenden Anwendung;
Fig. 22, 23 und 24 sind Zeitablaufdiagramme (Impulsfahrpläne) für Lese-, Schreib- und Interrupt-Acknowledge-Zyklen der bevorzugten Ausbildungsform der S/88 Prozessoren;
Fig. 25 und 26 zeigen Handshake-Zeitablaufdiagramme für Adapterbus-Kanäle 0, 1 während der Mailbox-Lesebefehle, 'Q Select Up'-Befehle, BSM-Lesebefehle und BSM-Schreibbefehle;
Fig. 27 ist ein Blockschaltbild einer bevorzugten Form eines S/370 Zentralprozessorelements;
Fig. 28 und 29 illustrieren gewisse Bereiche des S/370 Hauptspeichers und Steuerspeichers;
Fig. 30 zeigt eine bevorzugte Form der Schnittstellenbusse zwischen dem S/370 Zentralprozessorelement, dem E/A-Adapter, dem Cache-Controller, der Speichersteuerungs-Schnittstelle und dem S/88 Systembus und dem Prozessor;
Fig. 31 ist ein Blockschaltbild einer bevorzugten Form eines A/370 Cache-Controllers;
Fig. 32A und 32B (mit Layout Fig. 32) illustrieren schematisch eine bevorzugte Form der Speichersteuerungs- Schnittstelle in näheren Einzelheiten;
Fig. 33 ist ein Zeitablaufdiagramm, das die S/88 Systembusphasen für die Datenübertragung zwischen Einheiten auf dem Bus illustriert;
Fig. 34 ist ein fragmentarisches Schaltbild, das die "Daten- Ein"-Register einer gepaarten Speichersteuer-Schnittstelle zeigt;
Fig. 35 zeigt Formate der Befehls- und Speicherdatenwörter, die im FIFO der Fig. 32B abgespeichert sind;
Fig. 36A-D illustrieren Speicher- und Abrufbefehle vom S/370 Prozessor und Adapter, die in der Speichersteuer-Schnittstelle ausgeführt werden;
Fig. 37 illustriert das Konzept der bevorzugten Ausführungsform des ganzen Systems der vorliegenden Applikation unter dem Gesichtspunkt eines Programmierers;
Fig. 38, 39 und 40 illustrieren in Diagrammform bevorzugte Formen der Mikrocode-Konstruktion für die S/370 und S/88 Schnittstelle, die S/370 E/A-Befehlausführung und die Partitionierung der Schnittstelle zwischen EXEC 370 Software und dem S/370 E/A-Treiber (d. i. ETIO + BCU + S/370 Mikrocode);
Fig. 41A und 41B illustrieren im Konzept Schnittstellen und Protokolle zwischen EXEC370 Software und S/370 Mikrocode sowie zwischen ETIO Mikrocode und EXEC370 Software;
Fig. 41C-H illustrieren den Inhalt des örtlichen Speichers der BCU einschließlich Datenpuffer, Arbeitswarteschlangen- Puffer, Warteschlangen, Warteschlangenkommunikationsbereiche und Hardware-Kommunikationsbereiche, einschließlich einer Verbindungsgliedliste und der Bewegungen der Arbeitswarteschlangenpuffer durch die Warteschlangen, wobei diese Elemente das Protokoll umfassen, über das der S/370 Mikrocode und die EXEC 370 Software miteinander kommunizieren;
Fig. 42 illustriert im Konzept die Bewegung der Arbeitswarteschlangenpuffer durch die Verbindungsgliedliste und die Warteschlangen im Zusammenhang mit den Protokollen zwischen den EXEC 370, ETIO, S/270 Mikrocode und der S/370 - S/88 Ankopplungshardware;
Fig. 43 illustriert im Konzept die Durchführung einer typischen S/370 Start-E/A-Anweisung;
Fig. 44A-L illustrieren in Diagrammform die Steuer/Datenflüsse für S/370 Mikrocode und EXEC 370, wenn sie miteinander kommunizieren zwecks Ausführung von S/370 E/A-Anweisungen jeden Typs;
Fig. 45A-AG illustrieren Daten, Befehls- und Statusinformationen auf den örtlichen Adressen- und Datenbussen in der BCU während der Datenübertragungsoperationen innerhalb der BCU;
Fig. 46A-K illustrieren das Konzept einer bevorzugten Ausführungsform eines Speicherplattenemulationsprozesses, wobei die S/88 (über die BCU, ETIO und EXEC 370) als Reaktion auf S/370 E/A-Anweisungen Informationen von einer S/88 Platte im S/370 Format abruft;
Fig. 47 illustriert im Konzept die Speicherabbildung der Fig. 10 zusammen mit einer Ansicht der S/88 Speicherabbildungs einträge, von denen bestimmte herausgezogen werden, um einen S/370 Speicherbereich einzurichten;
Fig. 48A-K illustrieren eine bevorzugte Form eines virtuellen/physikalischen Speicherverwaltung für S/88, die während des Systemanlaufs mit neu vorgesehenen Subroutinen und Konfigurationsroutinen zusammenwirkt, um innerhalb des physikalischen S/88 Speichers S/370 Speicherbereiche zu erzeugen;
Fig. 49 und 50 sind fragmentarische Blockschaltbilder, die eine gewisse Logik illustrieren, die zum Synchronisieren der S/370 - S/88 Prozessorpaare und der Partnereinheiten benutzt werden; und
Fig. 51 und 52 illustrieren alternative Ausführungsformen der vorliegenden Verbesserung.

Einführung

Eine bevorzugte Ausführungsform zum Implementieren der vorliegenden Erfindung arbeitet mit einem fehlertoleranten System. Fehlertolerante Systeme sind in der Regel von Grund auf für fehlertoleranten Betrieb konstruiert. Die Prozessoren, Speicher, E/A-Vorrichtungen und Betriebssysteme wurden spezifisch maßgeschneidert, um eine fehlertolerante Umgebung vorzusehen. Die Breite ihrer Kundenbasis, die Ausgereiftheit ihrer Betriebssysteme und die Anzahl und das Ausmaß ihrer verfügbaren Applikationsprogramme sind jedoch nicht so groß wie die der beträchtlich älteren Großrechnersysteme verschiedener Hersteller wie z. B. das System System/370 (S/370), das von der International Business Machines Corporation vermarktet wird.
Die heutigen fehlertoleranten Datenverarbeitungssysteme bieten viele fortgeschrittene Merkmale, die üblicherweise auf den älteren, nichtfehlertoleranten Großrechnersystemen nicht laufen oder von den Großrechner-Betriebssystemen nicht unterstützt werden. Einige dieser Merkmale beinhalten: Ein Einzelsystembild, das über ein verteiltes Rechnernetzwerk dargestellt wird; die Möglichkeit, Prozessoren und E/A-Controller unter Spannung einzubauen (Ausbau und Einbau von Leiterplatten unter Spannung); augenblickliche Fehlererfassung, Fehlerausgrenzung und elektrische Abschaltung fehlerbehafteter Bauteile ohne Unterbrechung für den Rechneranwender; vom Kunden austauschbare Einheiten, die von Ferndiensten identifiziert wurden; und dynamische Neukonfigurierung, die durch Bauteilausfall bedingt war oder Einbauen zusätzlicher Vorrichtungen in das System während das System kontinuierlich weiterarbeitet. Ein Beispiel für ein solches fehlertolerantes System ist das System System/88 (S/88), das von der International Business Machines Corporation vermarktet wird.
Vorschläge, die obigen Merkmale in die S/370 Umgebung und Architektur einzuführen, betreffen in der Regel ein größeres Umschreiben des Betriebssystems (der Betriebssysteme) und der Anwenderapplikationsprogramme und/oder neue Hardware, die von Grund auf neu entwickelt werden muß. Jedoch wird das größere Umschreiben eines Betriebssystems, wie z. B. VM, VSE, IX370 usw. von vielen als eine riesengroße Aufgabe empfunden, die beträchtliche Zeit verschlingt. Es dauert in der Regel über fünf Jahre, bis ein komplexes Betriebssystem, wie das IBM S/370 VM oder MVS, ausgereift ist. Bis heute sind die meisten Systemabstürze das Ergebnis von Betriebssystemfehlern. Auch vergehen viele Jahre, bis die Anwender sich an das neue Betriebssystem gewöhnt. Sobald aber ein Betriebssystem ausgereift ist und eine große Anwenderbasis gefunden hat, ist es nicht gerade einfach, den Code zu modifizieren, um neue Anwendungen, wie z. B. Fehlertoleranz, dynamische Neukonfigurierung, Einzelsystembild usw. einzuführen.
Wegen der Komplexität und der Kosten für das Umstellen eines ausgereiften Betriebssystems auf eine neue Maschinenarchitektur werden sich die Konstrukteure meistens dafür entscheiden, ein neues Betriebssystem zu entwickeln, das von der Benutzergemeinde nicht ohne weiteres akzeptiert wird. Es ist möglicherweise unpraktisch, das ausgereifte Betriebssystem zu modifizieren, um die neuen Merkmale einzubauen, die vom neu entwickelten Betriebssystem beispielhaft gezeigt werden; jedoch wird möglicherweise das neue Betriebssystem nie eine größere Anwenderbasis finden und es wird lange Jahre mit Feldversuchen erfordern, bevor die meisten Probleme gelost sind.
Dementsprechend ist beabsichtigt, daß die vorliegende Verbesserung eine fehlertolerante Umgebung und Architektur für ein normalerweise nicht fehlertolerantes Verarbeitungssystem und Betriebssystem ohne größere Umschreiboperation des Betriebssystems vorsieht. In der bevorzugten Ausführungsform wird ein IBM System/88-Baumuster an ein IBM S/370-Baumuster gekoppelt.
Eine gängige Methode zum Zusammenkoppeln unterschiedlicher Prozessoren und Betriebssysteme ist eine Art Kommunikations- Controller, der jedem System beigefügt wird, Anhängen von Vorrichtungstreibern an das Betriebssystem und Benutzen einer Art Kommunikationscode, wie z. B. die System-Netzarchitektur (System Network Architecture - SNA) oder OSI zum Übertragen der Daten. In der Regel ist es zum Herstellen der Datenkommunikation zwischen Endknoten-Rechnern in einem Netz erforderlich, daß die Endknoten jeweils einen konsistenten Dienstleistungssatz verstehen und auf die auszutauschenden Daten anwenden.
Um ihre Entwurfskomplexität zu reduzieren sind die meisten Netze in einer Reihe Schichten oder Ebenen organisiert, deren jede auf ihrem Vorgänger aufbaut. Die Anzahl der Schichten, die Namen der einzelnen Schichten und die Funktion jeder Schicht unterscheiden sich von Netz zu Netz. Jedoch ist in allen Netzen der Zweck jeder Schicht, den höheren Schichten jeweils bestimmte Dienste zu leisten, unter Abschirmung dieser Schichten von Einzelheiten, wie die angebotenen Dienste wirklich implementiert sind. Schicht n einer Maschine führt mit Schicht n einer anderen Maschine eine Konversation. Die Regeln und Konventionen, die in diesem Gespräch befolgt werden, sind kollektiv als Schicht-n-Protokoll bekannt. Die Einheiten, die die entsprechenden Schichten auf unterschiedlichen Maschinen enthalten, heißen Partner-(Peer)-Prozesse, und es sind die Partner-(Peer)-Prozesse, die laut Protokoll miteinander kommunizieren.
In Wirklichkeit werden von der Schicht n auf einer Maschine zur Schicht n einer anderen Maschine keine Daten direkt übertragen (mit Ausnahme der untersten Schicht, d. h. der physikalischen Schicht). Das heißt, es kann kein direktes Ankoppeln von Applikationsprogrammen geben, die auf unterschiedlichen oder unabhängigen Systemen arbeiten. Statt dessen überträgt jede Schicht Daten- und Steuerinformationen auf die unmittelbar unter ihr liegende Schicht, bis die unterste Schicht erreicht ist. Auf der untersten Schicht gibt es eine physikalische Kommunikation mit der anderen Maschine, anders als bei der virtuellen Kommunikation, die von höheren Schichten benutzt wird.
Definitionen dieser Dienstleistungssätze gibt es in einer Reihe unterschiedlicher Netze, wie oben erwähnt, und seit kurzem richtet sich das Interesse auf das Erstellen von Protokollen zur Erleichterung von Zusammenschaltung von Systemen unterschiedlicher Hersteller. Eine Struktur zur Entwicklung dieser Protokolle ist die DÜ-Block-Struktur, die vom Siebenschichten-OSI-(Open Systems Interconnect)-Modell der Interna tional Standards Organization (ISO) definiert wird. Jede Schicht in diesem Modell ist eigenverantwortlich für das Leisten eines Netz-Service für die Schichten über ihr, während sie Dienstleistungen von der unter ihr liegenden Schicht anfordert. Die in jeder Schicht geleisteten Dienste sind genau definiert, so daß sie konsistent von jeder Station im Netz angefordert werden können. Das soll ein gegenseitiges Verschalten von Geräten unterschiedlicher Hersteller zulassen. Die Implementierung von Schicht-zu-Schicht-Dienstleistungen innerhalb eines Knotens ist implementierungsspezifisch und ermöglicht die herstellerspezifische Differenzierung auf der Grundlage der innerhalb einer Station vorgesehenen Dienste.
Hier muß man unbedingt berücksichtigen, daß der ganze Zweck des Implementierens eines so strukturierten Protokollsatzes die Durchführung eines Ende-zu-Ende-Datentransfers ist. Die Hauptunterteilungen im OSI-Modell lassen sich besser verstehen, wenn man sich klar macht, daß der Anwenderknoten mit der Zulieferung von Daten aus dem Quellapplikationsprogramm an das Empfängerapplikationsprogramm befaßt ist. Um diese Daten zu übertragen wirken die OSI-Protokolle auf die Daten auf jeder Ebene ein, um DÜ-Blöcke an das Netzwerk zu schicken. Die DÜ-Blöcke werden beim Koppeln der Daten mit den entsprechenden Kopfzeilen auf den einzelnen OSI-Ebenen aufgebaut. Diese DÜ-Blöcke werden dann als Bitsatz an das physikalische Medium gegeben, der durch das Medium übertragen wird. Jetzt werden sie einem umgekehrten Verfahrenssatz unterworfen, um die Daten für die Applikationsprogramme der Empfangsstation zu liefern.
Wie bereits früher angegeben, besteht eine gängige Methode zum Koppeln unterschiedlicher Prozessoren und Betriebssysteme durch eine Art Kommunikations-Controller, der jedem System beigegeben wird, Anhängen von Vorrichtungstreibern an die Betriebssysteme und Anwenden einer Art Kommunikationscode, wie die System Network Architecture (SNA) oder OSI zum Befördern von Daten. Fig. 1 zeigt eine Standard-Zusammenschaltung von zwei Rechnersystemen mittels eines Local Area Network (LAN). Im einzelnen wird ein IBM S/370 Architektursystem gezeigt, das mit einer IBM System/88 Architektur verbunden ist. Hier wird beobachtet, daß in jeder Architektur ein Applikationsprogramm Über eine Schnittstelle mit dem Betriebssystem arbeitet, um einen Prozessor zu steuern und auf einen E/A-Kanal oder -Bus zuzugreifen. Jede Architekturvorrichtung hat einen Kommunikations-Controller zum Austauschen von Daten. Um zu kommunizieren muß ein Vielschichten-Protokoll angewandt werden, damit Daten zwischen entsprechenden Applikationsprogrammen ausgetauscht werden.
Eine alternative Methode zum Datenaustausch ware eine Coprozessor-Methode, bei der der Coprozessor auf dem Systembus sitzt, für den Systembus als Verwalter arbeitet und die gleichen E/A benutzt wie der Zentralprozessor. Der Nachteil der Coprozessor-Methode ist die Menge der Code-Umschreibungen, die zur Unterstützung des nicht-eigenen (unabhängigen) Zentralrechner-E/A erforderlich ist. Ein weiterer Nachteil ist, daß der Anwender mit beiden Systemarchitekturen vertraut sein muß, um zwischen dem Coprozessor- und dem Zentralrechner- Betriebssystem umzuschalten - eine anwenderunfreundliche Umgebung.
Ein fehlertolerantes Rechnersystem auf dem Stand der Technik hat in der Regel ein Prozessor-Modul, das eine Prozessoreinheit, einen Speicher mit wahlfreiem Zugriff, Peripherie- Steuereinheiten, und eine Ein-Bus-Struktur aufweist, die alle Informationsübertragungen zwischen verschiedenen Einheiten des Moduls besorgt. Die Systembusstruktur innerhalb jedes Prozessor-Moduls beinhaltet Duplikat-Partnerbusse, und jede funktionelle Einheit innerhalb eines Prozessor-Moduls hat auch eine Duplikat-Partnereinheit. Die Busstruktur sieht Be triebsfähigkeit für die Moduleinheiten und System-Ablaufsteuerungssignale von einem Haupttaktgeber vor.
Fig. 2 zeigt in Form eines Funktionsschaltbilds die Struktur des Prozessoreinheitsteils eines Prozessormoduls. Durch Verwenden identischer gepaarter Prozessoren, die auf einer gemeinsamen Austauschplatine montiert sind und identische Operationen bei der Synchronisierung ausüben, lassen sich Vergleiche machen, um Prozessorfehler zu erfassen. Jede Platine hat im Regelfall eine redundante Partnereinheit mit identischer Struktur.
Das Rechnersystem sieht Fehlererfassung auf der Ebene jeder Funktionseinheit im ganzen Prozessormodul vor. Fehlerdetektoren überwachen Hardwareoperationen innerhalb jeder Einheit und prüfen Informationsübertragungen zwischen den Einheiten. Die Erfassung eines Fehlers bewirkt, daß das Prozessormodul die Einheit isoliert, die den Fehler verursacht hat, und verhindert, daß sie Informationen an andere Einheiten weitergibt, und das Modul arbeitet weiter durch Benutzen des Partners der fehlerhaften Einheit.
Bei Erfassen eins Fehlers in einer Einheit wird diese Einheit isoliert und off-line geschaltet, so daß sie keine falschen Informationen an andere Einheiten weitergeben kann. Der Partner der jetzt off-line gesetzten Einheit arbeitet weiter und ermöglicht es somit, daß das ganze Modul weiter in Betrieb bleibt. Ein Anwender bemerkt eine solche Fehlererfassung mit Übergang in den Off-line-Status nur selten, abgesehen von der Bildschirmanzeige oder einem sonstigen Aufruf einer Instandsetzungsanforderung, um die Off-line-Einheit wieder instandzusetzen. Die Platinenanordnung ermöglicht einen einfachen Ausbau und Austausch.
Der Speichereinheit ist auch die Aufgabe der Kontrolle des Systembusses zugeordnet. Zu diesem Zweck hat die Einheit Paritätsprüfer, die die Adressensignale und die Datensignale auf der Busstruktur überprüfen. Beim Feststellen, daß einer der Busse fehlerhaft arbeitet, signalisiert die Speichereinheit anderen Einheiten des Moduls, nur dem nicht-fehlerhaften Bus zu gehorchen. Die Energieversorgungseinheit für das Prozessormodul benützt zwei Energiequellen, deren jede die Betriebsenergie nur für eine einzige Einheit in jedem Paar Partnereinheiten liefert. Bei Feststellen einer ausgefallenen Versorgungsspannung werden alle Ausgangsleitungen von der betroffenen Einheit zur Busstruktur an Erdpotential gelegt, damit verhindert wird, daß ein Energieausfall die Übertragung fehlerhafter Daten auf die Busstruktur verursacht.
Fig. 3 zeigt in der Form eines Funktionsschaltbilds den Zusammenschluß gepaarter S/370 Prozessoren mit gepaarten S/88 Prozessoren auf die Art einer fehlertoleranten Struktur, um den direkten Datenaustausch zu ermöglichen. Die Ähnlichkeit mit der S/88-Struktur auf dem Stand der Technik (Fig. 2) ist beabsichtigt, aber es ist der einzigartige Zusammenschluß sowohl über die Hardware als auch über die Software, die den Betrieb der bevorzugten Ausführungsform bewirkt. Man sieht hier, daß die S/370 Prozessoren mit der Speichersteuerlogik und der Busschnittstellenlogik gekoppelt sind, zusätzlich zur Vergleichslogik vom Typ S/88. Wie noch beschrieben wird, funktioniert die Vergleichslogik auf gleiche Weise wie die Vergleichslogik für die S/88 Prozessoren. Ferner sind die S/370 Prozessoren direkt und über den Systembus mit den entsprechenden 3/88 Prozessoren gekoppelt. Wie bei dem S/88 Prozessor sind die S/370 Prozessoren paarweise gekoppelt es ist beabsichtigt, die Paare auf im Feld austauschbare, unter Spannung einsteckbare Leiterplatten zu montieren. Die de taillierte Verschaltung der verschiedenen Treiber wird später noch in näheren Einzelheiten beschrieben.
Die bevorzugte Ausführungsform schaltet Mehrfach-S/370- Prozessoren zur gleichzeitigen Ausführung der gleichen S/370 Befehle unter der Steuerung eines S/370 Betriebssystems zusammen. Diese sind mit entsprechenden Mehrfach-S/88- Prozessoren, E/A-Vorrichtungen und Hauptspeicher gekoppelt, die alle die gleichen S/88 Anweisungen unter der Steuerung eines S/88 Betriebssystems gleichzeitig ausführen. Wie später noch beschrieben wird, sind Mittel eingeschlossen, um die S/88 Prozessoren asynchron von ihrer E/A-Vorrichtung und ihrem Speicher abzukoppeln, die S/370 E/A-Befehle und Daten von den S/370 Prozessoren zu den S/88 Prozessoren zu leiten, während die letzteren abgekoppelt sind, und die Befehle und Daten in eine Form umzuwandeln, die vom S/88 für spätere Bearbeitung durch die S/88 Prozessoren benutzt werden kann, wenn diese wieder an ihre E/A-Vorrichtung und an den Hauptspeicher angekoppelt werden.

1. Betreiben eines normalerweise nicht-fehlertoleranten Prozessors in einer fehlertoleranten Umgebung

Die oben aufgelisteten fehlertoleranten Merkmale werden in einer bevorzugten Ausführungsform erreicht durch Koppeln von im Normalfall nicht fehlertoleranten Prozessoren, wie z. B. S/370 Prozessoren, zu einem ersten Paar, das die gleichen S/370 Anweisungen gleichzeitig unter der Steuerung eines der S/370 Betriebssysteme ausführt. Mittel sind vorgesehen zum Vergleichen der Zustände verschiedener Signale in einem Prozessor mit denen im anderen Prozessor zum augenblicklichen Erfassen von Fehlern in einem oder in beiden Prozessoren.
Ein zweites Partnerpaar von S/370 Prozessoren mit Vergleichsmitteln ist vorgesehen zum Ausführen der gleichen S/370 An weisungen gleichzeitig mit dem ersten Paar und zum Erfassen von Fehlern im zweiten Paar. Jeder S/370 Prozessor ist an einen entsprechenden S/88 Prozessor eines fehlertoleranten Systems wie das S/88 Datenverarbeitungssystem mit ersten und zweiten Partner-Prozessorpaaren, einer S/88 E/A-Vorrichtung und einem S/88 Hauptspeicher gekoppelt. Jedem S/88 Prozessor ist Hardware zugeordnet, die ihn an die E/A-Vorrichtung und an den Hauptspeicher koppelt.
Die entsprechenden S/370 und S/88 Prozessoren haben ihre jeweiligen Prozessorbusse durch Mittel, einschließlich einer Bussteuereinheit, miteinander gekoppelt. Jede Bussteuereinheit beinhaltet Mittel, die mit einem Applikationsprogramm zusammenwirken, das auf dem entsprechenden S/88 Prozessor läuft, um den entsprechenden S/88 Prozessor von seiner zugeordneten Hardware asynchron abzukoppeln und ihn an die Bussteuereinheit (1) zur Übertragung der S/370 Befehle und der Daten vom S/370 Prozessor zum S/88 Prozessor anzukoppeln, und (2) zur Umwandlung der S/370 Befehle und Daten in Befehle, die vom S/88 ausgeführt und Daten, die vom S/88 benutzt werden können.
Das S/88 Datenverarbeitungssystem verarbeitet anschließend die Befehle und Daten unter der Steuerung des S/88 Betriebssystems. Das S/88 Datenverarbeitungssystem reagiert auch auf Fehlersignale in jedem der S/370 Prozessorpaare oder in ihrem entsprechend angekoppelten S/88 Prozessorpaar, um die gekoppelten Paare von der Dienstleistung abzuschalten und einen fortgesetzten fehlertoleranten Betrieb mit den anderen gekoppelten S/370, S/88 Paaren durchzuführen. Mit dieser Anordnung werden von den S/370 Prozessoren S/370 Programme (mit Unterstützung des S/88 Systems für die E/A-Operationen) in einer fehlertoleranten (FT) Umgebung mit den vorteilhaften Merkmalen des S/88 ausgeführt, jeweils ohne signifikanten Änderungen am S/370 und S/88 Betriebssystem.
Zusätzlich wird die Speicherverwaltungseinheit des S/88 so gesteuert, daß sie jedem der Duplex S/370 Prozessor-Paare und ihrem Betriebssystem reservierte Bereiche im S/88 Hauptspeicher zuordnet, ohne daß das S/88 Betriebssystem davon weiß. Die Duplex S/370 Prozessorpaare sind zum Abrufen und Speichern von S/370 Anweisungen und Daten aus ihrem entsprechenden, zugewiesenen Speicherbereich über die Speicherverwaltungsvorrichtung und die S/88 Busschnittstelle individuell mit der gemeinsamen Busstruktur des S/88 gekoppelt.
Die bevorzugte Ausführungsform sieht vor ein Verfahren und Mittel zum Implementieren der Fehlertoleranz in der S/370 Hardware ohne Umschreiben des S/370 Betriebssystems oder der S/370 Applikationen. Volle S/370 CPU-Hardware-Redundanz und -Synchronisation ist vorgesehen ohne kundenspezifische Prozessorkonstruktion zur Unterstützung der Fehlertoleranz. Ein S/370 Betriebssystem und ein fehlertolerantes Betriebssystem (beide virtuelle Speichersysteme) laufen gleichzeitig ohne größeres Umschreiben der beiden Betriebssysteme. Eine Hardware/Mikrocode-Schnittstelle ist in der bevorzugten Ausführungsform vorgesehen zwischen den gleichgestellten Prozessorpaaren, wobei jeder Prozessor ein anderes Betriebssystem abarbeitet. Ein Prozessor ist eine Microcode-gesteuerte IBM S/370 Maschine, die ein IBM Betriebssystem abarbeitet (z. B. VM, VSE, IX370, usw.). Der zweite Prozessor der bevorzugten Ausführungsform ist eine hardwarefehlertolerante Maschine, die ein Betriebssystem abarbeitet, das in der Lage ist, eine hardwarefehlertolerante Umgebung zu steuern (z. B. IBM System/88) unter Abarbeiten eines S/88 VOS (Virtual Operating System - virtuelles Betriebssystem).
Die Hardware/Mikrocode-Schnittstelle zwischen den Prozessorpaaren ermöglicht es, daß die beiden Betriebssysteme gleichzeitig existieren in einer Umgebung, die der Anwender als eine einzige Systemumgebung empfindet. Die Hardware/Mikrocode- Betriebsteile (Speicher, Systembusse, Laufwerk-E/A, Kommunikations-E/A-Terminals, Stromversorgung und Anlagen arbeiten unabhängig voneinander, wobei jedes Betriebssystem seinen Teil der Systemfunktionen behandelt. Die Wörter für Speicher (Memory, Storage und Store) sind für diese Betrachtung frei austauschbar. Der/die FT-Prozessor(en) und das Betriebssystem behandeln Fehlererfassung, Isolierung und Behebung, dynamische Rekonfiguration und E/A-Operationen. Der/die NFT Prozessor(en) führen systemeigen Anweisungen durch ohne Kenntnis vom FT-Prozessor. Der FT-Prozessor erscheint dem NFT-Prozessor wie Mehrfach-E/A-Kanäle.
Die Hardware/Mikrocode-Schnittstelle erlaubt beiden virtuellen Speicherprozessoren die gemeinsame Nutzung eines fehlertoleranten Speichers. Ein kontinuierlicher Speicherblock von der Speicherzuordnungstabelle des FT-Prozessors wird jedem NFT-Prozessor zugeteilt. Das dynamische Adressenübersetzungsmerkmal des NFT-Prozessors steuert den Speicherblock, der ihm vom FT-Prozessor zugeteilt wurde. Der NFT-Prozessor merkt durch Benutzen eines Offsetregisters, daß sein Speicher bei der Adresse Null beginnt. Eine Grenzkontrolle wird ausgeführt, um den NFT-Prozessor innerhalb seiner eigenen Speichergrenzen zu halten. Der FT-Prozessor kann auf den NFT- Speicher zugreifen und DMA-E/A-Datenblöcke in bzw. aus dem NFT-Adressenraum aufzugreifen, während der NFT-Prozessor am Zugriff auf Speicher außerhalb seines ihm zugewiesenen Adressenraums gehindert wird. Die NFT Speichergröße läßt sich durch Andern der Konfigurationstabelle verändern.

2. Abkoppeln eines Prozessors von seiner ihm zugeordneten Hardware, um Befehle und Daten aus einem anderen Prozessor auf ihn zu übertragen

Das Anschließen einer neuen Vorrichtung an einen vorhandenen Prozessor und Betriebssystem setzt in der Regel einen Hardwa reanschluß über einen Bus oder einen Kanal und das Schreiben einer neuen Vorrichtungstreibersoftware für das Betriebssystem Voraus. Das verbesserte "Abkopplungs"-Merkmal läßt zu, daß zwei unterschiedliche Prozessoren miteinander kommunizieren ohne Anschließen eines der Prozessoren an einen Bus oder einen Kanal und ohne über die Buskontrolle entscheiden zu müssen. Die Prozessoren kommunizieren ohne signifikante Betriebssystemveränderung oder die Forderung nach einem herkömmlichen Vorrichtungstreiber. Das kann einem Anwender den Anschein eines einzigen Systems vermitteln, wenn zwei unterschiedliche und unähnliche Prozessoren verschaltet werden, obwohl jeder Prozessor nach seinem eigenen Betriebssystem arbeitet.
Dieses Merkmal sieht vor ein Verfahren und Mittel zum Kombinieren der besonderen Merkmale, die ein später entwickeltes Betriebssystem aufweist mit der im Bewußtsein des Anwenders verankerten Zuverlässigkeit eines ausgereiften Betriebssystems. Es koppelt die zwei Systeme (Hardware und Software) zusammen um ein neues, drittes zu bilden. Dem Fachmann ist hierbei bewußt, daß zwar die bevorzugte Ausführungsform das Ankoppeln eines S/370 Systems an ein S/88 System zeigt, daß aber zwei beliebige Systeme zusammengekoppelt werden können. Die Konstruktionskriterien dieses Konzepts sind: Wenig oder keine Veränderung am ausgereiften Betriebssystem, so daß es seine Zuverlässigkeit und minimale Auswirkung auf das wegen der Entwicklungszeit für einen Code später entwickelte Betriebssystem beibehält.
Dieses Merkmal beinhaltet ein Verfahren zur Kombination von zwei unähnlichen Systemen, jedes mit seinen eigenen Merkmalen, zu einem dritten System, das die Merkmale von beiden aufweist. Eine bevorzugte Ausführungsform des Verfahrens erfordert eine Kopplungslogik zwischen dem System, das vorherrschend als Direktspeicherzugriffs-Controller (Direct Memory Access Controller - DMAC) arbeitet. Das Hauptziel dieses Merkmals ist, einem Applikationsprogramm, das in einem fehlertoleranten Prozessor (z. B. S/88 in der bevorzugten Ausführungsform) und eingebaut in das fehlertolerante Betriebssystem läuft, ein Verfahren zum Einholen von Daten und Befehlen aus einem unabhängig operierenden Prozessor (z. B. S/370 in der bevorzugten Ausführungsform) und seinem Betriebssystem zu geben. Auf jedem Prozessor existieren sowohl Hardware- als auch Software-Abwehrmechanismen, damit das Eindringen (Z. B. Überwachungsprogramm gegen Anwenderzustand, Speicherabbildungskontrolle usw.) verhindert wird. In der Regel tendieren Betriebssysteme dahin, alle Systemressourcen, wie Interrupts, DMA-Kanäle, und E/A-Vorrichtungen und -Controller zu kontrollieren. Daher wird das Zusammenkoppeln von zwei unterschiedlichen Architekturen und Übertragen von Befehlen und Daten zwischen diesen Maschinen, ohne daß man diese Funktion von Grund auf neu entworfen hat, von vielen als eine monumentale Aufgabe und/oder als unpraktisch angesehen.
Fig. 4 zeigt als Blockschaltbild einen S/370 Prozessor, der mit einem S/88 Prozessor gekoppelt ist, in der Umgebung der bevorzugten Ausführungsform. In Gegensatz zum S/370 Prozessor, der in Fig. 1 gezeigt wird, wurde der Speicher ersetzt durch eine S/88 Bus-Schnittstellenlogik, und der S/370 Kanalprozessor wurde durch den Busadapter und die Bussteuereinheit ersetzt. Besondere Aufmerksamkeit wird auf die Verbindung zwischen der S/370 Steuereinheit und dem S/88 Prozessor gelegt, die durch eine strichpunktierte Doppellinie angezeigt wird.
Dieses Merkmal beinhaltet das Verknüpfen der Prozessor- Ankopplungslogik mit der virtuellen Adressenbus-, Datenbus-, Steuerbus- und Interruptbus-Struktur des fehlertoleranten S/88 und nicht an den Systembus oder Kanal, an den die meisten Vorrichtungen angehängt sind. Die Strobe-Leitung, die anzeigt, daß eine gültige Adresse auf dem virtuellen Adressenbus des fehlertoleranten Prozessors liegt, wird einige Nanosekunden nach dem Aktivieren der Adressensignale aktiviert. Die Kopplungslogik, die den Busadapter und die Bussteuereinheit enthält, bestimmt, ob ein vorgewählter Adressenbereich von einem S/88 Applikationsprogramm angeboten wird, bevor das Strobe-Signal erscheint. Wenn dieser Adressenbereich gefunden wird, wird das Adressenstrobesignal blockiert und kann nicht mehr in die S/88 fehlertolerante Prozessorhardware gelangen. Das Fehlen des Signals verhindert, daß die fehlertolerante Hardware und das Betriebssystem weiß, daß ein Maschinenzyklus abgelaufen ist. Die fehlertolerante Prüflogik in der Hardware wird während dieses Zyklus isoliert und verpaßt voll jede Aktivität, die sich während dieser Zeit abspielt. Alle Cache-, virtuellen Adressenabbildungslogik- und Fließkommaprozessoren auf dem Prozessorbus erkennen nicht, daß ein Maschinenzyklus abgelaufen ist. D. h., alle S/88 CPU- Funktionen sind 'eingefroren' und erwarten das Auflegen des Adreß-Strobe-Signals vom S/88 Prozessor.
Das Adreß-Strobe-Signal, das von der fehlertoleranten Prozessorlogik abgekoppelt war, wird zur Kopplungslogik geschickt. Das gibt dem S/88 fehlertoleranten Prozessor die gesamte Kontrolle über die Kopplungslogik, die die Schnittstelle zwischen dem fehlertoleranten speziellen Applikationsprogramm und dem angeschlossenen S/370 Prozessor ist. Das Adreß- Strobe-Signal und die virtuelle Adresse werden benutzt, um den örtlichen Speicher, Register und DMAC anzuwählen, die Komponenten der Kopplungslogik sind. Fig. 5 zeigt in Blockschaltbildform das Ergebnis der Erfassung eines Interrupts von der S/370 Bussteuerlogik her, von der jetzt festgestellt wird, daß sie auf der richtigen Ebene liegt und einer echten Adresse entspricht. In seiner breitesten Auswirkung trennt also der Abkopplungsmechanismus einen Prozessor von der ihm zugeordneten Hardware und verbindet den Prozessor mit einer fremden Einheit zwecks effizienter Datenübertragung mit dieser Einheit.
Die Kopplungslogik weist einen örtlichen Speicher auf, der benutzt wird, um ankommende S/370 Befehle in Warteschlange zu setzen und Daten zu speichern, die zum und vom S/370 laufen. Die Daten und Befehle werden Über Mehrfach-DMA-Kanäle in der Kopplungslogik in den örtlichen Speicher befördert. Das fehlertolerante Applikationsprogramm initialisiert den DMAC und bedient Interrupts vom DMAC, was dazu dient, das Applikationsprogramm zu unterrichten, wenn ein Befehl angekommen ist oder wenn ein Datenblock empfangen oder gesendet wurde. Um eine Operation zu vervollständigen, muß die Kopplungslogik die Daten-Strobe-Quittierungsleitungen vor der Taktflanke des Prozessors zurückgeben, um sicherzustellen, daß beide Seiten des fehlertoleranten Prozessors synchron bleiben.
Das Applikationsprogramm erhält S/370 Kanaltyp-Befehle wie z. B. Start-E/A, Test-E/A, usw. Das Applikationsprogramm konvertiert dann jeden S/370 E/A-Befehl in einen fehlertoleranten E/A-Befehl und laßt eine normale fehlertolerante E/A- Befehlssequenz anlaufen.
Unserer Meinung nach ist das ein neues Verfahren, einen Datenblock um ein Betriebssystem herum und zu einer Applikation zu bringen. Es ist auch eine Möglichkeit, zu veranlassen, daß eine Applikation einen Interrupt behandelt, der eine Funktion ist, die in der Regel von einem Betriebssystem ausgeführt wird. Das Applikationsprogramm kann den fehlertoleranten Prozessor von seiner normalen Prozessorfunktion nach Belieben und auf Zyklusbasis zur E/A-Controller-Funktion umschalten, nur durch die virtuelle Adresse, die es anwählt.
Auf diese Weise werden zwei Prozessorsysteme mit unähnlichen Anweisungs- und Speicheradressierungs-Architekturen eng gekoppelt, so daß es möglich ist, daß ein System effektiv auf jeden Teil des virtuellen Speicherraums des anderen Systems zugreift, ohne daß das andere System das Vorhandensein des einen Systems merkt. Ein spezieller Applikationscode im anderen System kommuniziert mit dem einen System über Hardware durch Legen bestimmter Adressen auf den Bus. Die Hardware stellt fest, ob die Adresse eine Spezialadresse ist. Wenn ja, wird der Strobe blockiert und kann von der Schaltung des anderen Systems nicht erkannt werden, und wird so umgeleitet, daß die CPU des anderen Systems spezielle Hardware und einen Speicherraum ansteuern kann, der für beide Systeme zugänglich ist.
Das andere System kann das eine System nötigenfalls vollständig steuern, wie bei der Initialisierung und der Konfigurierung. Das eine System kann das andere System in keiner Weise steuern, kann jedoch Dienstleistungen vom anderen System auf die folgende Weise anfordern:
Das eine System zwischenspeichert E/A-Befehle und/oder Daten im Format des einen Systems im gemeinsam zugängigen Speicherraum und, durch Anwenden spezieller Hardware, schickt es einen Interrupt auf einer speziellen Ebene an das andere System, der das spezielle Applikationsprogramm aufruft.
Dieses letztere ist auf den Speicherraum gerichtet, der die zwischengespeicherte Information enthält, und verarbeitet diese, um ihr Format in die systemeigene Form des anderen Systems umzuwandeln. Dann weist das Applikationsprogramm das systemeigene Betriebssystem des anderen Systems an, die systemeigenen E/A-Operationen an den umgewandelten Befehlen und Daten auszuführen. Somit geschieht das alles komplett trans parent und ohne signifikante Änderung in den systemeigenen Betriebssystemen beider Systeme.

3. Vorlage von Interrupts an ein System, das transparent für das Betriebssystem ist

Die meisten gängigen Programme arbeiten in einem von zwei (oder mehr) Zuständen, in einem Überwachungszustand oder in einem Anwendungszustand. Applikationsprogramme laufen im Anwendungszustand und Funktionen, wie z. B. Interrupts, laufen im Überwachungszustand.
Eine Anwendung schließt einen E/A-Port an und öffnet dann den Port, gibt eine E/A-Anforderung in der Form eines Lese-, Schreib- oder Steuerbefehls aus. Zu diesem Zeitpunkt nimmt der Prozessor eine Aufgabenumschaltung vor. Wenn das Betriebssystem einen Interrupt erhält, der einen E/A-Abschluß anzeigt, legt das Betriebssystem diese Information in eine bereite Warteschlange ab und sortiert nach Priorität für die Systembetriebsmittel.
Das Betriebssystem reserviert alle Interrupt-Vektoren für seinen eigenen Gebrauch; keine stehen für neue Merkmale zur Verfügung, wie z. B. für einen externen Interrupt, der eine E/A-Anforderung von einer anderen Maschine bedeutet.
Im S/88 der bevorzugten Ausführungsform bleibt eine Mehrheit der verfügbaren Interrupt-Vektoren in Wirklichkeit ungenutzt, und diese werden eingestellt, um das Vektorisieren zu einem gemeinsamen Störungsbearbeitungsprogramm für 'nicht initialisierte' oder 'falsche' Interrupts zu bewirken, wie es in Betriebssystemen allgemein üblich ist. Die bevorzugte Ausführungsform dieser Verbesserung ersetzt eine Teilmenge dieser sonst unbenutzten Vektoren durch geeignete Vektoren auf spezielle Interrupt-Bearbeitungsprogramme für die S/370 Kopplungslogik-Interrupts. Das modifizierte S/88 Betriebssystem wird dann mit den neu integrierten Vektoren an Ort und Stelle wiederangefahren.
Das System/88 der bevorzugten Ausführungsform hat acht Interrupt-Ebenen und benutzt Autovektoren auf alle Ebenen außer Ebene 4. Die Verbesserung der vorliegenden Anmeldung benutzt eine dieser Autovektorebenen, Ebene 6, die die zweithöchste Priorität hat. Diese Ebene 6 wird im Normalfall vom System/88 für A/C-Stromstörungs-Interrupts benutzt.
Die Logik, die das System/370 an das System/88 koppelt, legt Interrupts auf Ebene 6 durch ODER-Verknüpfung ihrer Interrupt-Requests mit denen der A/C-Stromstörung. Während der Systeminitialisierung werden geeignete Vektor-Nummern auf die speziellen Interrupt-Bearbeitungsprogramme für die Kopplungslogik-Interrupts in die Kopplungslogik geladen (davon einige, z. B., in die DMAC-Register) durch ein Applikationsprogramm, das für das S/88 Betriebssystem transparent ist.
Wenn ein Interrupt beim System/88 eingeht, initiiert er einen Interrupt-Quittierungszyklus (Interrupt Acknowledge - IACK) unter Verwendung von ausschließlich Hardware und internen Operationen des S/88 Prozessors, um den Interrupt zu bearbeiten und die erste Interrupt-Bearbeitungsprogramm-Anweisung abzurufen. Keine Programmanweisungsausführung ist erforderlich. Aber es muß auch die Vektor-Nummer erzeugt und transparent dargestellt werden. Das wird in der bevorzugten Ausführungsform durch Abkoppeln des S/88 Prozessors von seiner zugeordneten Hardware (einschließlich des Interrupt-Anzeige- Mechanismus für A/C-Stromstörungen) und Ankoppeln des S/88 Prozessors an die S/370-S/88 Kopplungslogik erreicht, wenn von der Kopplungslogik ein Interrupt der Ebene 6 geschickt wird.
In weiteren Einzelheiten setzt der S/88 Prozessor den Funktionscode und die Interrupt-Ebene an seine Ausgänge und setzt auch den Adreß-Strobe (AS) und den Data-Strobe (DS) zu Beginn des IACK-Zyklus. Der Adreß-Strobe wird von der S/88 Hardware abgesperrt, einschließlich des A/C-Stromstörungs-Interrupt- Mechanismus, wenn das den Kopplungslogik-Interrupt zeigende Signal aktiv ist; und der AS wird an die Kopplungslogik geschickt, um die richtige Vektornummer auszulesen, die durch den Data-Strobe in den S/88 Prozessor eingesteuert wird. Weil der Data-Strobe von der S/88 Hardware abgeschnitten ist, ist der Maschinenzyklus (IACK) relativ zum Einholen der Kopplungslogik-Interrupt-Vektornummer transparent für das S/88 Betriebssystem.
Wenn das Kopplungslogik-Interruptsignal zu Beginn des IACK- Zyklus nicht aktiviert gewesen wäre, wäre ein normaler S/88 Interrupt der Ebene 6 ausgeführt worden.

4. Aufteilen eines Realspeichers zwischen zwei oder mehr Prozessoren, die unterschiedliche mit virtuellem Speicher arbeitende Betriebssysteme abarbeiten

Dieses Merkmal koppelt ein fehlertolerantes System an einen Fremdprozessor und -betriebssystem, das keinen Code zur Unterstützung einer fehlertoleranten Speicherung aufweist, d.i. einen Code zum Unterstützen von Ausbau und Einsetzen von Speicherkarten unter Spannung, augenblickliches Erfassen von verstümmelten Daten und ihre Wiedergewinnung, falls erforderlich, usw.
Dieses Merkmal sieht ein Verfahren und Mittel vor, mit dem zwei oder mehr Prozessoren, die jeder nach einem anderen virtuellen Betriebssystem arbeitet, dazu gebracht werden können, daß sie einen einzigen Realspeicher gemeinsam nutzen auf eine Weise, die für beide Betriebssysteme transparent ist, und durch das ein Prozessor auf den Speicherraum des anderen Prozessors zugreifen kann, so daß es zum Datenaustausch zwischen diesen multiplen Prozessoren kommt.
Dieses Merkmal kombiniert zwei anwenderersichtliche Betriebssystemumgebungen, um dem Anwender den Anschein eines einzigen Betriebssystems zu geben. Jedes Betriebssystem ist ein virtuelles Betriebssystem, das im Normalfall seinen eigenen vollständigen Realspeicherraum steuert. Die vorliegende Erfindung hat nur einen einzigen Realspeicherraum, in den sich beide Prozessoren über einen gemeinsamen Systembus teilen. Keines der Betriebssysteme wird im wesentlichen umgeschrieben und keines der Betriebssysteme weiß, daß das andere existiert oder daß der Realspeicher gemeinsam benutzt wird. Das Merkmal benutzt ein Applikationsprogramm, das auf einem ersten Prozessor läuft, um die Speicherzuteilungs-Warteschlange des ersten Betriebssystems zu durchsuchen. Wenn ein zusammenhängender Speicherraum gefunden wird, der groß genug ist, den Forderungen des zweiten Betriebssystems zu genügen, dann wird dieser Speicherraum durch Manipulierungszeiger aus der Speicherzuteilungstabelle des ersten Betriebssystems herausgenommen. Das erste Betriebssystem kann diesen herausgenommenen Speicher nicht mehr benutzen (z. B. durch die Fähigkeit der Neuzuteilung), falls nicht die Applikation den Speicher wieder dem ersten Operationssystem zuteilt.
Das erste Betriebssystem ist dem zweiten Betriebssystem aus der E/A-Perspektive untergeordnet und spricht auf das zweite Betriebssystem als E/A-Controller an. Das erste Betriebssystem ist der Master aller Systembetriebsmittel, und in der bevorzugten Ausführungsform ist es ein hardwarefehler-tolerantes Betriebssystem. Das erste Betriebssystem weist anfänglich Speicherraum zu und schließt ihn wieder aus (abgesehen von der Speicherung, die für das zweite Betriebssystem "gestohlen" wurde), und behandelt alle zugeordneten Hardware- Fehler und -berichtigungen. Das Ziel ist die Kombinierung der zwei Betriebssysteme ohne Verändern des Betriebssystemcode in größerem Umfang. Jedes Betriebssystem muß glauben, daß es alle Systemspeicher steuert, da dieses ein einziges Betriebsmittel ist, das von beiden Prozessoren benutzt wird.
Wenn das System beim Einschalten hochfährt, übernehmen das erste Betriebssystem und sein Prozessor die Steuerung des Systems, und die Hardware hält den zweiten Prozessor in einem Reset-Zustand. Das erste Betriebssystem bootet das System und bestimmt, wie viel Realspeicherraum existiert. Das Betriebssystem organisiert schließlich den ganzen Speicher in 4kB (4096 Bytes) Blöcke und listet jeden verfügbaren Block in einer Speicherzuteilungs-Warteschlange. Jeder 4kB Block, der in der Warteschlange aufgelistet ist, zeigt auf den nächsten verfügbaren 4kB Block. Jeder vom ersten System benutzte Speicher wird entweder herausgezogen oder in 4kB-Blöcken Von oben in der Warteschlange her eingefügt; und die Blockzeiger sind entsprechend eingestellt. Wenn Anwender Speicherraum vom Betriebssystem fordern, werden die Anforderungen erfüllt durch Zuweisen einer geforderten Anzahl 4kB Blöcke realer Speicherraum aus der Warteschlange. Wenn der Speicher nicht mehr gebraucht wird, werden die Blöcke an die Warteschlange zurückgegeben.
Als nächstes führt das erste Betriebssystem eine Reihe von Funktionen durch, genannt Modulhochfahren, die das System konfigurieren. Eine Applikation, die vom Modulhochfahren ausgeführt wird, ist eine neue Applikation, die benutzt wird, um Speicher aus dem ersten Betriebssystem zu erfassen und diesen Speicher dem zweiten Betriebssystem zuzuordnen. Das Programm durchsucht die ganze Speicherzuteilungsliste und findet eine zusammenhängende Reihe von 4kB-Speicherblöcken. Dann verändert das Applikationsprogramm die Zeiger in dem Teil der Warteschlange, die dieser fortlaufenden Blockreihe entspricht, und nimmt somit eine zusammenhängenden Speicherblockreihe aus der Speicherzuordnungsliste des ersten Betriebssystems heraus. In der bevorzugten Ausführungsform wird der Zeiger des 4kB-Blocks vor dem ersten herausgenommenen 4kB-Block so geändert, daß er auf den 4kB-Block zeigt, der der herausgenommenen zusammenhängenden Blockreihe unmittelbar folgt.
Das erste Betriebssystem hat zu diesem Zeitpunkt keine Kontrolle oder Kenntnis von diesem Realspeicherraum, falls das System nicht neu gebootet wird oder die Anwendung die Speicherzeiger nicht zurückstellt. Es ist so, als ob das erste Betriebssystem ein Segment des Realspeichers einem unabhängig ablaufenden Prozeß zugeordnet und nicht neu zuordenbar erachte, weil die Blöcke aus der Tabelle herausgenommen und nicht nur einfach einem Anwender zugeordnet sind.
Dann wird der herausgenommene Adressenraum dem zweiten Betriebssystem übergeben. Dort gibt es eine Hardware-Offsetlogik, die den Adressenblock, der vom ersten Betriebssystem gestohlen und dem zweiten Betriebssystem zugeordnet wurde, mit der Anfangsadresse Null des zweiten Betriebssystems anfangen läßt. Das zweite Betriebssystem kontrolliert dann den dem ersten Betriebssystem gestohlenen Speicherraum so, als ob er sein eigener Realspeicher sei, und steuert den Speicherraum durch seinen eigenen Virtuellspeicher-Manager, d. h. es übersetzt die vom zweiten System ausgegebenen virtuellen Adressen in reale Adressen innerhalb des zugeordneten Realspeicher-Adressenraums.
Ein Applikationsprogramm, das auf dem ersten Betriebssystem läuft, kann E/A-Daten in den und aus dem Speicherraum des zweiten Prozessors bewegen, jedoch kann der zweite Prozessor nicht außerhalb seines ihm zugeordneten Raums lesen oder schreiben, weil das zweite Betriebssystem nichts von diesem zusätzlichen Speicher weiß. Wenn es eine Betriebssystem störung im zweiten Betriebssystem gibt, verhindert eine Hardware-Falle, daß das zweite Betriebssystem unbeabsichtigt in den Raum des ersten Betriebssystems schreibt.
Die Menge Speicherraum, die dem zweiten Betriebssystem zugeordnet ist, wird durch den Anwender in einer Tabelle im Modulhochfahrprogramm definiert. Wenn der Anwender will, daß der zweite Prozessor 16 Megabytes zur Verfügung hat, dann wird er das in der Modulhochfahrtabelle definieren und die Applikation wird so viel Speicherraum aus dem ersten Betriebssystem entnehmen. Ein spezieller SVC (Service-Aufruf) ermöglicht es dem Applikationsprogramm, Zugriff zum Überwacherbereich des ersten Betriebssystems zu nehmen, so daß die Zeiger modifiziert werden können.
Ein wichtiger Grund, warum es erwünscht ist, daß beide Betriebssysteme sich in den gleichen Speicherraum teilen, ist, daß der Speicher fehlertolerant für den ersten Prozessor ist; und der zweite Prozessor fehlertoleranten Speicherraum und E/A vom ersten Prozessor benutzen kann. Der zweite Prozessor wird fehlertolerant gemacht durch Wiederholung bestimmter Hardware und Vergleichen bestimmter Adressen-, Daten- und Steuerleitungen. Durch Anwendung dieser Techniken ist der zweite Prozessor in Wirklichkeit eine fehlertolerante Maschine, auch wenn das zweite Betriebssystem keine fehlertoleranten Fähigkeiten hat. Es können auch mehr als ein Fremdprozessor und -betriebssystem des zweiten Typs an das erste Betriebssystem angekoppelt werden, wobei für jeden Fremdprozessor ein gesonderter Realspeicherbereich vorgesehen wird.
In der bevorzugten Ausführungsform ist das erste Betriebssystem das des fehlertoleranten S/88 und das zweite Betriebssystem eines der S/370 Betriebssysteme, und der ersten und der zweite Prozessor sind entsprechend S/88 und S/370 Prozessoren. Dieses Merkmal läßt es nicht nur zu, daß ein normaler weise nicht fehlertolerantes System einen fehlertoleranten Speicher benutzt, der von einem fehlertoleranten System unterhalten wird, sondern läßt es auch zu, daß das nicht fehlertolerante System (1) einen gemeinsamen Zugriff auf das fehlertolerante E/A-Gerät, das vom fehlertoleranten System unterhalten wird, hat, und (2) Daten zwischen den Systemen ohne die signifikanten Verzögerungen einer Kanal-an-Kanal- Ankopplung in einer effizienteren Weise ausgetauscht werden.

5. Einzelsystembild

Der Ausdruck Einzelsystembild wird benutzt zur Charakterisierung von Rechnernetzwerken, in denen der Anwender-Zugriff auf Ferndaten und -betriebsmittel (z. B. Drucker, Festplattendatei usw.) dem Anwender genau so erscheint, wie ein Zugriff auf Daten und Betriebsmittel der örtlichen Datenendstation, mit der die Tastatur des Anwenders verbunden ist. Auf diese Weise kann der Anwender auf eine Datei oder ein Betriebsmittel einfach über den Namen zugreifen, ohne daß er wissen muß, wo das betreffende Objekt im Netz sitzt.
Hier wird der neue Begriff "Abgeleitetes Einzelsystembild" (Derived Single System Image) als neuer Ausdruck eingeführt und soll sich auf Rechnerelemente eines Netzwerks beziehen, die keine Vorrichtungen zum Direktanschluß an ein Netz mit Einzelsystembild aufweisen, die aber Hardware- und Software- Systemelemente dieses Netzes benutzen, um sich direkt an dieses mit einem effektiven Einzelsystembild anzuschließen.
Für die Zwecke dieser Diskussion kann ein Direktanschluß eines Rechnersystems zum Entwickeln der Effekte der "Abgeleiteten Einzelsystemabbildung" mit unterschiedlichem Kopplungsgrad zwischen diesem System und den Elementen des Netzwerks durchgeführt werden. Der Ausdruck "lockeres Ankoppeln" (loose coupling), wie er hier gebraucht wird, bedeutet ein Ankoppeln über E/A-Kanäle des Ableitungsrechners und des "systemeigenen" Rechners, der Teil des Netzwerks ist. "Enges Ankoppeln" (tight coupling) ist ein derzeit benutzter Ausdruck zum Beschreiben einer Beziehung zwischen dem Ableitungsrechner und dem systemeigenen Rechner, die über besondere Hardware erfolgt, die ermöglicht, daß jeder mit dem anderen auf Direktbasis kommuniziert (d. h. ohne die vorhandenen E/A-Kanäle der beiden zu benutzen).
Ein besonderer Typ des hier betrachteten engen Koppelns, genannt "transparentes enges Koppeln" (transparent tight coupling) beinhaltet die Anpassung der Kopplungshardware, so daß jeder Rechner (der Ableitungsrechner und der systemeigene Rechner) in der Lage ist, die Betriebsmittel des jeweils anderen Rechners so zu nutzen, daß die Betriebssysteme der beiden Rechner nichts von dieser Benutzung merken. Transparentes enges Koppeln, wie eben definiert, bildet die Grundlage zum Erzielen von Kosten- und Leistungsvorteilen im gekoppelten Netzwerk. Die Kosten für die Kopplungshardware sollten, ungeachtet der Komplexität der Konstruktion, mehr als ausgeglichen werden durch Einsparungen, die realisiert werden durch Vermeiden der aufwendigen Modifizierungen der Betriebssystem- Software, die sonst notwendig würden. Leistungsvorteile ergeben sich aus dem Fluß durch schnellere Verbindungen infolge der Direktkopplung und der reduzierten Bandbreiteninterferenz an der Kopplungsschnittstelle.
Der Ausdruck "Netzwerk", der im folgenden Abschnitt gebraucht wird, ist stärker eingeschränkt zu verstehen als das derzeitige vorherrschende Konzept eines Netzwerks, das ein größeres, internationales Fernverarbeitungs/Satelliten-Verbindungsprojekt betrifft, in das sich viele ungleiche Maschinentypen einklinken können, wenn sie nur einem besonderen Protokoll entsprechen. "Netzwerk" betrifft im vorliegenden Abschnitt vielmehr einen verbundenen Komplex von System/88- Prozessoren oder, alternativ, einen Verbundkomplex anderer Prozessoren, der die Merkmale einer Einzelsystemabbildung aufweist.
Zwecks weiterer Erklärung des Konzepts einer Einzelsystemabbildung im hier verwendeten Sinn werden verschiedene sorgfältig definierte Begriffe verwendet; es wird angenommen, daß die spezifische, bevorzugte Ausführungsform der Verbesserung als Grundlage für die Klarstellungen benutzt wird:
a. Hochgeschwindigkeits-Datenverbindung (High Speed Data Interconnection - HSDI) bezieht sich auf ein Hardware- Teilsystem (mit Kabel) zur Datenübertragung zwischen einzelnen getrennten Hardware-Einheiten.
b. Verbindungsglied (Link) bezieht sich auf ein Softwarekonstrukt oder -objekt, das ganz aus einem Mehrfachzeiger auf ein anderes Software-Objekt besteht und das viel vom Charakter eines Alternativnamens hat.
c. MODUL betrifft eine freistehende Prozessoreinheit bestehend mindestens aus jeweils einem der folgenden Teile: Gehäuse, Stromversorgung, CPU, Speicher und E/A-Vorrichtung. Ein MODUL kann erweitert werden durch Zusammenschrauben mehrerer Gehäuse zur Aufnahme zusätzlicher Peripheriegeräte, um so ein größeres einzelnes Modul zu schaffen. Einige E/A-Einheiten (Bildschirme, Drucker) können extern und mit dem Gehäuse durch Kabel verbunden sein; sie gelten als Teil des einzelnen MODULS. Ein MODUL kann nur immer einen CPU-Komplex aufweisen.
d. CPU-KOMPLEX bezieht sich auf eine oder mehrere Einzel- oder Dualprozessorboards innerhalb des gleichen Gehäuses, verwaltet und gesteuert von der Betriebssystem-Software um als einzelne CPU zu arbeiten. Unabhängig von der wahren Anzahl der installierten Prozessorboards wird jedes Benutzerprogramm d.i. Applikation so geschrieben und ausgeführt, als ob nur eine einzige CPU vorhanden wäre. Die Prozessor-Auslastung wird grob auf die vorhandenen CPU-Boards verteilt, und Mehrfachaufgaben können gleichzeitig laufen, aber jedes Applikationsprogramm stellt sich mit einer 'EINZEL-CPU- ABBILDUNG' dar.
e. OBJEKT betrifft eine Sammlung von Daten (einschließlich ausführbarer Programme), die im System (Platte, Band) gespeichert sind und die durch einen hierarchischen Namen eindeutig identifiziert werden können. Ein LINK ist ein eindeutig benannter Zeiger auf ein anderes OBJEKT und wird selbst als OBJEKT angesehen. Der E/A-PORT ist ein eindeutig benanntes Software-Konstrukt, das auf eine spezifische E/A-Vorrichtung (Datenquelle oder -ziel) zeigt und so ebenfalls ein OBJEKT ist. Das Betriebssystem verhindert auf diese Weise effektiv die Duplizierung von OBJEKT-NAMEN.
Weil der Ausdruck 'Einzelsystemabbildung' in der Literatur nicht konsequent benutzt wird, soll es hier zwecks Klarstellung der "Abgeleiteten Einzelsystemabbildung" genauer beschrieben werden. Beim Definieren und Beschreiben des Ausdrucks 'EINZELSYSTEMABBILDUNG' bezieht sich die 'Abbildung' auf die Sicht des Applikationsprogramms auf das System mit Umgebung. 'System' in diesem Zusammenhang bedeutet die kombinierte Hardware (CPU-Komplex) und Software (Betriebssystem und seine Dienstprogramme), an die der Applikations-Programmierer seine Anweisungen richtet. 'Umgebung' bedeutet alle E/A-Vorrichtungen und sonstige angeschlossene Einrichtungen, die vom Betriebssystem angesprochen werden können und so über Dienstleistungsanforderungen an das Betriebssystem indirekt für den Programmierer zugänglich sind.
Ein echter, freistehender Einzelrechner mit seinem Betriebssystem muß dem Programmierer eine EINZELSYSTEMABBILDUNG bieten: Nur wenn wir Mehrfachsysteme zusammenschließen wollen, um E/A-Vorrichtungen gemeinsam zu benutzen und die Verarbeitung zu verteilen, beginnt sich diese vom Programmierer gesehene 'Abbildung' zu verändern; der gewöhnliche Zusammenschluß zweier Maschinen über Datenfernverarbeitungsleitungen (oder auch Kabel) zwingt den Programmierer, die duale Umgebung zu verstehen - und behandeln zu lernen - um die erweiterten Einrichtungen vorteilhaft zu nutzen.
Im allgemeinen muß er, um auf Einrichtungen in der anderen Umgebung zugreifen zu können, sein örtliches Betriebssystem anweisen, seine Anforderungen an das 'andere' Betriebssystem weiterzuleiten, und muß diese Anforderungen detailliert spezifizieren. Er muß dann in der Lage sein, die Ergebnisse seiner Anforderung asynchron (und in der richtigen Reihenfolge) nach einer willkürlich langen Verzögerung zu akzeptieren. Das Behandeln und die Steuerung der vielfachen Meldungs- und Datenübertragungen zwischen den Maschinen stellt einen signifikanten Aufwand in beiden Maschinen dar: Es kann unhandlich, ineffizient und schwierig für den Programmierer in einer solchen DUAL-SYSTEM-Umgebung werden. Und wenn die Anzahl der herkömmlicherweise angeschlossenen Maschinen zunimmt, kann sich die Komplexität für den Programmierer schnell steigern.
Die ursprüngliche Konstruktion des System/88 beinhaltete die Mittel zum Vereinfachen dieser Situation und zum Darstellen der EINZELSYSTEMABBILDUNG für den Programmierer, d.i. die HSDI-Verbindung zwischen den MODULen und der HSDI-Treibersoftware innerhalb des Betriebssystems in jedem MODUL. Hier, z. B. in einem Zwei-MODUL-System, 'weiß' jedes der zwei Betriebssysteme 'um' die ganze Umgebung, und kann über die HSDI ohne die aktive Intervention des 'anderen' Betriebssystems auf Vorrichtungen zugreifen. Die Verminderung des Kommunikationsaufwands ist beträchtlich.
Eine große Anzahl MODULE verschiedener Größen und Modelltypen lassen sich Über die HSDI zu einem Systemkomplex verschalten, der dem Programmierer als eine einzige (erweiterbare) Umgebung erscheint. Dieses Produkt, ein Applikationsprogramm, kann auf einer einzigen Festplatte in diesem Systemkomplex gespeichert und in einer der CPUs in dem Komplex ausgeführt werden, gesteuert oder überwacht von im wesentlichem einem beliebigen der Terminals des Komplexes, und kann Daten von und zu einer beliebigen E/A-Vorrichtung des Komplexes Übertragen, alles ohne besondere Programmierungsüberlegungen und mit verbesserter Ausführungseffizienz im Vergleich zu den älteren Verfahren.
Das Betriebssystem mit seinen verschiedenen Merkmalen und Einrichtungen ist so geschrieben, daß es ursprünglich die verteilte Umgebung übernimmt und in dieser Umgebung arbeitet, ohne daß sich der Anwender darum kümmern oder berücksichtigen muß, wo die verschiedenen Einheiten (Dienstprogramme, Anwendungen, Daten, Sprachprozessoren usw.) sitzen. Der Schlüssel, um das alles möglich zu machen, ist die erzwungene Regel, daß jedes OBJEKT einen eindeutigen Namen haben muß; und diese Regel erstreckt sich leicht auf den ganzen Systemkomplex, da der am meisten grundlegende Namenqualifikator der MODUL-Name ist, der innerhalb des Komplexes selbst eindeutig sein muß. Das Auffinden eines OBJEKTS im gesamten Komplex ist daher so einfach wie seine korrekte Namensgebung. Die Namensgebung eines OBJEKTS wird ihrerseits für den Programmierer vereinfacht durch das Vorsehen von LINKS, die die Anwendung sehr kurzer Alternativzeiger auf (Ersatznamen für) OBJEKTE mit sehr langen und komplizierten Namen zuläßt.
Um das Konzept einer "Abgeleiteten Einzelsystemabbildung" innerhalb des Komplexes der verschalteten S/88 Module zu erreichen, werden eine Vielzahl S/370 Prozessoren so mit S/88 Prozessoren gekoppelt, daß sie für die S/370 Anwender wenigstens einige Aspekte der S/88 Einzelsystemabbildungs-Merkmale vorsehen, und zwar sogar, wenn die S/370 Prozessoren und Betriebssysteme diese Merkmale gar nicht vorsehen.
Im S/88 MODUL sind einer oder mehr S/370 Prozessoren vorgesehen. Ein S/88 Prozessor ist eindeutig mit jeweils einem S/370 Prozessor gekoppelt. Wie man noch sehen wird, ist jeder S/370 Prozessor durch S/88 Software auf fehlertolerante Operation repliziert und gesteuert. Die eindeutige Direktankopplung der S/88 und S/370 Prozessoren, vorzugsweise durch die oben beschriebenen Abkopplungs- und Interruptfunktions-Mechanismen, macht die Datenübertragung sowohl für die S/370- als auch S/88-Betriebssysteme transparent. Keines der Betriebssysteme weiß etwas von der Existenz des anderen Prozessors oder Betriebssystems.
Jeder S/370 Prozessor benutzt den fehlertoleranten S/88 Systemkomplex, um den kompletten S/370 Hauptspeicher und die emulierten S/370 E/A-Kanäle und E/A-Vorrichtungen vorzusehen. Die S/370 haben keinen Hauptspeicher, Kanal oder E/A-Vorrichtungen, die nicht Teil des S/88 sind, und alle diese Geräte sind fehlertolerant konstruiert.
Zum Zeitpunkt der Systemkonfiguration wird jedem 3/370 Prozessor ein zweckbestimmter zusammenhängender Block von 1 bis 16 Megabytes Hauptspeicher aus dem S/88 Registerspeicher zugewiesen: Dieser Block wird aus den Konfigurationstabellen des S/88 herausgenommen, so daß das S/88 Betriebssystem keinen Zugriff darauf hat, nicht einmal unbeabsichtigt. Fehlertolerante Hardwareregister enthalten den Speicherblockzeiger für jeden S/370, so daß der S/370 keine Möglichkeit hat, auf einen anderen Hauptspeicher zuzugreifen als auf den, der ihm zugeordnet ist. Das Ergebnis ist eine vollständig herkömmliche Einzelsystemsicht seines Hauptspeichers durch den S/370; der fehlertolerante Aspekt des Speichers ist vollständig transparent. Ein Applikationsprogramm (EXEC370) im S/88 emuliert einen S/370 Kanal/Kanäle und E/A-Vorrichtung(en), die eigentlich S/88 Vorrichtungen und S/88 Betriebssystem-Aufrufe benutzen. Es hat das EINZELSYSTEMABBILDUNGS-Aussehen des S/88 Komplexes, weil es ein Applikationsprogramm ist; somit wird diese Sicht auf den gesamten S/370 'Pseudo-Kanal' erweitert.
Unter dem entgegengesetzten Gesichtspunkt, dem des S/370 Betriebssystems (und erweitert auf das Applikationsprogram), kann es hilfreich sein, sich ein 'Fenster' (den Kanal) vorzustellen, durch das alle E/A-Operationen ausgeführt werden. Das Fenster bleibt seinem Charakter nach unverändert - kein S/370 Programm muß geändert werden - aber die 'Sicht' durch das Fenster wird erweitert und schließt jetzt auch die EINZELSYSTEMABBILDUNGS-Attribute ein. Ein kleiner konzeptioneller Schritt bildet dann eine große Anzahl S/370 Systeme ab, die sich effizient in eine einzige Datenbank teilen, die vom S/88 verwaltet wird.
Eine Konsequenz dieser Verbindungstechnik ist die verhältnismäßig einfache und schnelle dynamische Umkonfigurationsfähigkeit jedes S/370. Das Kanal-'Fenster' funktioniert in beiden Richtungen, und das S/88 Steuerprogramm EXEC370 steht auf der anderen Seite; das EXEC370 hat die volle Fähigkeit zum Stoppen, Rückstellen, Neuinitialisieren, Neukonfigurieren und Neustarten der 8/370 CPU. Somit wird durch transparente Emulierung der S/370 E/A-Vorrichtungen, die andere Vorrichtungen benutzen, die das EINZELSYSTEMABBILDUNGS-Attribut aufweisen (S/88 EA- und Betriebssystem), dieses Attribut erweitert und dem S/370 zur Verfügung gestellt.
Daher wird das S/370 mit Objektlokalisierungs-Unabhängigkeit ausgestattet. Seine Anwender können über den Namen auf eine Datei oder ein anderes Betriebsmittel zugreifen, einen Namen, der ihm im S/88 Betriebssystem-Dateiverzeichnis zugewiesen ist. Der Anwender braucht den Ort der Datei im Komplex der S/370-S/88-Module gar nicht zu kennen.
Über eine S/370 Prozessoreinheit in einem Modul 9 ausgegebene S/370 E/A-Befehle werden von einer zugeordneten S/88 Prozessoreinheit abgearbeitet, die eng an die S/370 Prozessoreinheit im gleichen Modul gekoppelt ist (oder durch andere S/88 Prozessoreinheiten, die im Modul 9 verschaltet sind und von der gleichen Kopie des virtuellen S/88 Betriebssystem gesteuert werden wie das virtuelle S/88 Betriebssystem, das das Mehrfachprozessor-Arbeiten unterstützt), um auf Dateien und dergl. zuzugreifen, die im gleichen oder in anderen damit Verbundenen Modulen resident sind. Sie kann die aufgegriffenen Dateien an die anfordernde S/370 Prozessoreinheit zurückgeben oder sie auch an andere Module schicken, z. B. um sie mit anderen Dateien zusammenzulegen.

6. Zusammenfassung

So werden die Funktionen von zwei virtuellen Betriebssystemen (z. B. S/370 VM, VSE oder IX370 und S/88 OS) in einem physikalischen System zusammengelegt. Der S/88 Prozessor fährt das S/88 OS und behandelt die fehlertoleranten Aspekte des Systems. Gleichzeitig sind ein oder mehrere S/370 Prozessoren in den S/88 Einschub gesteckt und ihnen wird vom S/88 OS irgendwo zwischen 1 und 16 Megabyte zusammenhängender Speicherraum je S/370 Prozessor zugewiesen. Jedes virtuelle S/370 Betriebssystem glaubt, daß sein ihm zugeordneter Speicherraum mit der Adresse 0 beginnt und verwaltet seinen Speicher durch eine normale dynamische S/370 Zuordnungs- und Paging-Technik. Das S/370 ist grenzkontrolliert, damit verhindert wird, daß das S/370 auf S/88 Speicherraum zugreift. Das S/88 muß auf den S/370 Adressenraum zugreifen, weil das S/88 E/A-Daten in die S/370 E/A-Puffer schieben können muß. Das S/88 Betriebssystem ist Master über die gesamte System-Hardware und E/A- Vorrichtungen. Die gleichgestellten Partnerprozessorpaare arbeiten ihre entsprechenden Betriebssysteme in einer Einzelsystemumgebung ab ohne signifikantes Umschreiben eines Betriebssystems.

Einführung - System/88 auf dem Stand der Technik

Die Verbesserungen der vorliegenden Anwendung werden beschrieben im Hinblick auf eine bevorzugte Form, in der IBM System/370 (S/370) Prozessoreinheiten (die S/370 Anweisungen unter Steuerung eines S/370 Betriebssystems wie z. B. VM, VSE, IX370 und dergl. abarbeiten) eng gekoppelt sind mit IBM System/88 (S/88) Prozessoreinheiten (die S/88 Anweisungen fehlertolerant unter der Steuerung eines S/88 Betriebssystems in einer fehlertoleranten Umgebung abarbeiten) auf eine Weise, die den fehlertoleranten Betrieb der S/370 Prozessoreinheiten mit System/88 Merkmalen einer Einzelsystemabbildung, Einstecken unter Spannung, sofortige Fehlererkennung, E/A-Lastverteilung und Fehlerisolierung und dynamischer Umkonfigurationsfähigkeit zuläßt.
Das von der International Business Machine Corp. vermarktete IBM System/88 wird allgemein im IBM System/88 Digest, 2. Auflage, veröffentlicht 1986, und in anderen verfügbaren S/88 Kundenveröffentlichungen beschrieben. Das System/88 Rechnersystem, einschließlich Modul 10, Fig. 6A, ist ein vielseitig einsetzbares System, das konstruiert wurde, um die Bedürfnisse von Kunden zu befriedigen, die eine hoch-zuverlässige Online-Verarbeitung benötigen. System/88 kombiniert eine Duplex-Hardware-Architektur mit ausgefeilter Betriebssystem- Software, um ein fehlertolerantes System zu bilden. System/88 sieht auch ein horizontales Wachstum durch Anschluß multipler System/88-Module 10a, 10b, 10c über System/88 Hochgeschwindigkeits-Datenverbindungen (HSDIs), Fig. 6B, und Module 10d-g im System/88-Netz vor.
Das System/88 ist so konstruiert, daß es einen Komponentenausfall sofort erfaßt, wann und wo er auftritt, und verhindert, daß durch einen solchen Ausfall verursachte Fehler und Unterbrechungen auf das System übergreifen. Da Fehlertoleranz Teil der System/88-Hardwarekonstruktion ist, muß diese nicht durch den Applikationsentwickler programmiert werden. Fehlertoleranz wird erreicht ohne Softwareaufwand oder Leistungsminderung. Das System/88 erreicht Fehlertoleranz durch die Duplizierung von Hauptkomponenten, einschließlich Prozessoren, Direktzugriffsspeichervorrichtungen (DASDs) oder Platten, Speicher und Controller. Wenn eine Duplex-Komponente ausfällt, übernimmt automatisch ihr Duplexpartner die Abarbeitung und das System bleibt für den Anwender weiter zugänglich. Duplikatstromversorgung mit Batteriepufferung zur Speicherkonservierung während eines kurzen Stromausfalls ist ebenfalls vorgesehen. Das System/88 und seine Software-Produkte bieten eine erleichterte Erweiterung, gemeinsame Betriebsmittelnutzung und Lösungen für komplexe Forderungen unter Wahrung einer Einzelsystemabbildung für den Endanwender.
Eine Einzelsystemabbildung ist eine verteilte Bearbeitungsumgebung, bestehend aus vielen Prozessoren, jeder mit seinen eigenen Dateien und E/A, verschaltet über ein Netzwerk oder LAN, die dem Anwender den Eindruck verschafft, daß er in eine einzige Maschine eingeloggt ist. Das Betriebssystem ermöglicht es dem Anwender, von einer Maschine aus mit einer anderen zu sprechen, nur durch Aufrufen eines anderen Verzeichnisses.
Mit geeigneter Planung kann die System/88 Bearbeitungskapazität erweitert werden, während das System/88 läuft und unter Beibehaltung der Einzelsystemabbildung für den Endanwender. Horizontales Wachstum wird erreicht durch Kombinieren von Mehrfachprozessormodule in Systemen, die die System/88 HSDI benutzten, und Kombinieren von Mehrfachsystemen in einem Netzwerk, das das System/88-Netzwerk benutzt.
Ein System/88-Prozessormodul ist ein kompletter, eigenständiger Rechner, wie in Fig. 6A der Zeichnungen dargestellt ist. Ein System/88-System ist entweder ein einziges Modul oder eine Modulgruppe, die in einem logischen Netzwerk mit dem IBM HSDI der Fig. 6B verschaltet sind. Das System/88-Netzwerk unter Benutzung von Fernübertragungsvorrichtungen ist das Gerät, das zum Zusammenschalten von Mehrfachsystemen zu einer Einzelsystemabbildung für den Endanwender benutzt wird. Zwei oder mehr Systeme können Über Kommunikationsleitungen zu einem Fernleitungs-Netzwerk verschaltet werden. Diese Verbindung kann Über ein Direktkabel, eine gemietete Telefonleitung oder ein X.25 Netzwerk erfolgen. Das System/88-Netzwerk erfaßt Hinweise auf Fernbetriebsmittel und leitet Meldungen zwischen Modulen und Systemen völlig transparent für den Anwender weiter.
Die Einsteckbarkeit unter Spannung ermöglicht das Auswechseln vieler Hardwareaustauschteile, ohne den Systembetrieb unterbrechen zu müssen. Das System/88 schaltet eine ausgefallene Komponente ab unter Fortführung der Dienste mit ihrem Duplex- Partner, und laßt eine Leuchte an der ausgefallenen Komponente aufleuchten - alles ohne Eingriff des Bedieners. Der Kunde bzw. das Wartungspersonal kann ein ausgefallenes Duplex-Board ausbauen und ersetzen, wahrend die Verarbeitung weitergeht. Die Vorteile für einen Kunden sind zeitige Instandsetzung und reduzierte Wartungskosten.
Zwar ist das System/88 eine fehlertolerante Maschine für kontinuierlichen Betrieb, es gibt jedoch Zeiten, in denen der Maschinenbetrieb angehalten werden muß. Beispiele dafür sind die Qualitätsverbesserung des System/88-Betriebssystems (Upgrade), verändern der Hardware-Konfiguration (zusätzlicher Hauptspeicher) oder Ausführen bestimmter Dienstleistungsverfahren.
Die Duplex-System/88-Komponenten und die System/88-Software tragen zur Wahrung der Datenintegrität bei. Das System/88 entdeckt einen Ausfall oder vorübergehenden Fehler am Strörungspunkt und führt ihn nicht in die Anwendung oder die Daten ein. Die Daten sind geschützt gegen Datenverfälschung und die Systemintegrität wird gewahrt. Jede Komponente enthält ihre eigene Datenerfassungslogik und Diagnostik. Die Datenerfassungslogik vergleicht die Ergebnisse paralleler Operationen in jedem Maschinenzyklus.
Wenn das System eine Komponentenfunktionsstörung entdeckt, wird diese Komponente automatisch aus dem Betrieb gezogen. Die Verarbeitung geht auf dem Duplex-Partner weiter während die ausgefallene Komponente durch interne Diagnostik überprüft wird. Die Fehlererfassungsfunktion führt automatisch die Diagnostik an der aus dem Dienst gezogenen ausgefallenen Komponente durch während die Verarbeitung auf ihrem Duplex- Partner weiterläuft. Wenn die Diagnostik feststellt, daß bestimmte Komponenten ausgetauscht werden müssen, kann das System/88 automatisch eine Instandsetzungsabteilung anrufen, um das Problem zu berichten. Dem Kunden kommt eine schnelle Instandsetzung und geringe Wartungskosten zugute.
Das System/88 gründet sich im allgemeinen auf Prozessorsysteme des Typs, der in US-Patent 4,453,215, betitelt "Central Processing Apparatus for Fault Tolerant Computing", erteilt am 5. Juni 1984 an Robert Reid, und im Zusammenhang mit den US-Patenten Nr. 4,486,826, 4,597,084, 4,654,857, 4,750,177 und 4,816,990 beschrieben wird. Teile des Patents 4,453,215 sind als Diagramm in den Fig. 7 und 8 der vorliegenden Anmeldung dargestellt.
Das Rechnersystem der Fig. 7 und 8 der vorliegenden Anmeldung hat ein Prozessormodul 10 mit einer Prozessoreinheit 12, einer Speichereinheit mit wahlfreiem Zugriff 16, Peripherie- Steuereinheiten 20, 24, 32 und einer Ein-Bus-Struktur 30, die alle Informationsübertragungen zwischen den verschiedenen Einheiten dieses Moduls besorgt. Die Busstruktur innerhalb jedes Prozessormoduls beinhaltet Duplikat-Partnerbusse A, B und jede Funktionseinheit 12, 16, 20, 24, 32 hat eine identische Partnereinheit. Jede Einheit - abgesehen von den Steuereinheiten, die mit asynchronen Peripherievorrichtungen arbeiten - arbeitet in der Regel schrittsynchronverriegelt mit ihrer Partnereinheit. Z. B. treiben die zwei Partnerspeichereinheiten 16, 18 eines Prozessormoduls in der Regel beide die zwei Partnerbusse A, B und werden beide von der Busstruktur 30 voll synchron getrieben.
Das Rechnersystem sieht Fehlererfassung auf der Ebene jeder Funktionseinheit innerhalb eines Prozessormoduls vor. Um dieses Merkmal erreichen, verfolgen Fehlerdetektoren die Hardwareoperationen in jeder Einheit und überprüfen die Informationsübertragungen zwischen den Einheiten. Die Erfassung eines Fehlers bewirkt, daß das Prozessormodul den Bus bzw. die Einheit, die den Fehler verursacht hat, gegen die Informationsübertragung zu anderen Einheiten isoliert wird, und das Modul fährt mit dem Betrieb fort. Die fortgesetzte Operation benutzt den Partner des fehlerhaften Busses bzw. der Einheit. Soweit die Fehlererfassung einer Informationsübertragung vorangeht, kann die fortgesetzte Operation die Übertragung in der gleichen Zeit fortsetzen, in der sie ohne Auftreten eines Fehlers stattgefunden hätte. Soweit die Fehlererfassung mit einer Informationsübertragung einhergeht, kann die fortgesetzte Operation die Übertragung wiederholen.
Das Rechnersystem kann die folgende Fehlererfassung und Fehlerbehebungsaktion schnell durchführen, d. h. innerhalb einer Fraktion eines Operationszyklus. Das Rechnersystem hat höchstens eine einzige Informationsübertragung durchgeführt, deren Gültigkeit fraglich ist und die wiederholt werden muß, um die Gültigkeit aller Daten zu sichern.
Die Redundanz der Funktionseinheit versetzt das Modul in die Lage, die Operation im Falle des Auftreten eines Fehlers in einer beliebigen Einheit fortzusetzen. Im allgemeinen arbeiten alle Einheiten eines Moduls kontinuierlich und in ausgewählter Synchronitat, wenn kein Fehler festgestellt wird. Bei Auftreten einer fehleranzeigenden Störung in irgendeiner Einheit wird diese Einheit isoliert und off-line gesetzt, so daß sie keine Informationen an andere Einheiten des Moduls schicken kann. Der Partner der off-line gesetzten Einheit fahrt mit dem Betrieb fort, in der Regel ohne wesentliche Unterbrechung.
Zusätzlich zu der Partnerverdopplung der Funktionseinheiten in einem Modul zwecks Sicherstellens der fehlertoleranten Operation hat im allgemeinen jede Einheit in einem Prozessormodul eine Duplikathardware, die mit der Datenübertragung befaßt ist. Zweck dieser Verdopplung in einer Funktionseinheit ist die Prüfung, unabhängig von den anderen Einheiten, auf Fehler innerhalb jeder Einheit. Andere Strukturen innerhalb jeder Einheit eines Moduls, einschließlich der Fehlererfassungsstruktur, sind im allgemeinen nicht verdoppelt.
Die gemeinsame Busstruktur, die alle Einheiten eines Prozessormoduls bedient, benutzt vorzugsweise eine Kombination der obigen Zwei-Ebenen-Duplikationsstufe und weist drei Leitersätze auf, die einen A-Bus, einen B-Bus, der den A-Bus dupliziert, und einen X-Bus bilden. Der A-Bus und der B-Bus führen jeweils einen identischen Satz Zyklus-Definitions-, Adressen- Daten-, Paritäts- und sonstige Signale, die verglichen werden können, um vor einer fehlerhaften Informationsübertragung zwischen den Einheiten zu warnen. Die Leiter des X-Busses, der nicht dupliziert ist, tragen im allgemeinen modulweite und sonstige Betriebssignale wie Takt, Fehlerbedingungen und elektrische Energie. Ein zusätzlicher C-Bus ist vorgesehen zur örtlichen Kommunikation zwischen den Partnereinheiten.
Ein Prozessormodul erfaßt und grenzt einen Fehler ein durch eine kombinierte Technik innerhalb jeder Funktionseinheit, einschließlich Vergleichen der Operation der gedoppelten Sektionen der Einheit, Anwendung der Parität und weiterer fehlerüberprüfender und -korrigierender Codes, und durch Überwachen von Betriebsparametern wie Speisespannungen. Jede zentrale Prozessoreinheit weist zwei redundante Prozessorsektionen auf, und wenn der Vergleich ungültig ist, isoliert sie die Prozessoreinheit gegen das Übertragen von Informationen auf die Busstruktur. Das isoliert andere Funktionseinheiten des Prozessormoduls gegen fehlerhafte Informationen, die von der fraglichen Prozessoreinheit stammen könnten. Jede Prozessoreinheit hat auch eine Stufe zum Vorsehen einer virtuellen Speicheroperation, die nicht dupliziert ist. Die Prozessoreinheit wendet hier statt dessen Paritätstechniken an, um einen Fehler auf dieser Stufe zu erkennen.
Die Speichereinheit mit wahlfreiem Zugriff 16 liegt zwischen zwei nicht-redundanten Speichersektionen, deren jede zum Abspeichern unterschiedlicher Bytes eines Speicherworts eingerichtet ist. Die Einheit entdeckt einen Fehler sowohl in jeder Speichersektion als auch in der Zusammensetzung der zwei Sektionen, mit einem Fehlerberichtigungs-Code. Wieder verhindert der Fehlerdetektor, daß die Speichereinheit potentiell fehlerhafte Informationen auf die Busstruktur und damit auf andere Einheiten überträgt.
Der Speichereinheit 16 ist auch die Aufgabe übertragen, die duplizierten Busleiter, d.i. den A-Bus und den B-Bus, zu prü fen. Zu diesem Zweck hat die Einheit Paritätsprüfer, die die Adressensignale und die Datensignale auf der Busstruktur überprüfen. Zusätzlich vergleicht ein Komparator alle Signale auf dem A-Bus mit allen Signalen auf dem B-Bus. Wenn auf diese Weise festgestellt wird, daß einer der Busse fehlerhaft ist, signalisiert die Speichereinheit den anderen Einheiten des Moduls über den X-Bus, nur dem nicht-fehlerhaften Bus zu gehorchen.
Periphere Steuereinheiten für ein Prozessormodul benützen eine Bus-Schnittstellensektion zum Anschluß an die gemeinsame Busstruktur, Duplikat-Steuersektionen, die als "drive" und "check" bezeichnet werden, und eine periphere Schnittstellensektion, die zwischen den Steuersektionen und peripheren Ein/Aus-Vorrichtungen kommuniziert, die die Einheit bedienen. Das sind Plattensteuereinheiten 20, 22 zum Betrieb mit Magnetplattenspeicher 52a, 52b, eine Kommunikationssteuereinheit 24, 26 zum Betrieb durch Kommunikationsplatten 50 mit Kommunikationsvorrichtungen einschließlich Terminals, Druckern und Modems, und HSDI Steuereinheiten 32, 34 zum Verschalten eines Prozessormoduls mit einem anderen in einem Mehrfachprozessorsystem. In jedem Fall schickt die Bus- Schnittstellensektion Eingangssignale an die Treiber- und Prüfsteuerabschnitte vom A-Bus und/oder B-Bus, prüft auf logische Fehler in bestimmten Eingangssignalen von der Busstruktur, und überprüft die Identität von Signalen, die von den Antriebs- und Prüfkanälen ausgegeben werden. Die Treibersteuersektion in jeder peripheren Steuereinheit sieht vor Steuerung, Adresse, Status und Datenmanipulationsfunktionen, die zu der E/A-Vorrichtung passen, die die Einheit bedient. Die Prüfsteuersektion der Einheit ist im wesentlichen identisch für die Zwecke der Kontrolle der Treibersteuersektion. Die periphere Schnittstellensektion jeder Steuereinheit beinhaltet eine Kombination von Paritäts- und Komparator- Vorrichtungen zum Überprüfen von Signalen, die zwischen der Steuereinheit und den peripheren Vorrichtungen Übertragen werden, auf Fehler.
Eine periphere Steuereinheit, die mit einer synchronen E/A- Vorrichtung, z. B. einer Kommunikationssteuereinheit 24 zusammenarbeitet, arbeitet schrittsynchronverriegelt mit ihrer Partnereinheit. Jedoch arbeiten die Partner-Plattensteuereinheiten 20, 22 mit unterschiedlichen, nicht-synchronen Magnetplattenspeichern zusammen und arbeiten dementsprechend mit begrenzter Synchronitat. Die Partnerplattensteuereinheiten 20, 22 fuhren Schreiboperationen gleichzeitig, jedoch nicht in präziser Synchronitat durch, insofern als die Magnetplattenspeicher asynchron miteinander arbeiten. Die Steuereinheit 32 und ihr Partner arbeiten in der Regel ebenfalls mit diesem eingeschränkten Synchronitätsgrad.
Die Stromversorgungseinheit für ein Modul benutzt zwei Gesamtenergieversorgungsleitungen, von denen jede die Betriebsenergie für eine Einheit in jedem Partnereinheiten- Paar liefert. Somit versorgt eine Gesamtenergieversorgung einen duplizierten Teil der Busstruktur, eine eines Paars Zentraleinheiten, eine zweier Speichereinheiten und eine Einheit je Paar peripherer Steuereinheiten. Die Gesamtenergieversorgungen liefern elektrische Energie auch an nichtduplizierte Einheiten des Prozessormoduls. Jede Einheit des Moduls hat eine Energiezufuhrstufe, die die Betriebsenergie von einer Gesamtenergieversorgung erhält und die ihrerseits die Betriebsspannungen entwickelt, die diese Einheit braucht. Diese Energieversorgungsstufe überwacht zusätzlich die Versorgungsspannungen. Beim Erfassen eines Versorgungsspannungsausfalls erzeugt die Energieversorgungsstufe ein Signal, das alle Ausgangsleitungen von dieser Einheit zur Busstruktur an Masse legt. Diese Aktion verhindert, daß ein Stromausfall in einer beliebigen Einheit die Übertragung fehlerhafter Informationen auf die Busstruktur bewirkt.
Einige Einheiten des Prozessormoduls fuhren jede Informationsübertragung mit einem Betriebszyklus aus, der eine Fehlererfassungstaktphase vor dem eigentlichen Informationstransfer enthält. Eine Einheit, die diese Operation vorsieht, z. B. eine Steuereinheit für eine Peripherievorrichtung, fuhrt also vor dem Informationstransfer eine Prüfung auf einen Fehlerzustand durch. Die Einheit verhindert die Informationsübertragung im Fall, daß ein Fehler gefunden wird. Das Modul kann jedoch - ohne Unterbrechung oder Verspätung - weiterarbeiten und den Informationstransfer von der nicht gesperrten Partnereinheit her durchfuhren.
Weitere Einheiten des Prozessormoduls, im allgemeinen einschließlich mindestens der Zentralprozessoreinheit und der Speichereinheit, für die die Betriebszeit wichtiger ist, fuhren jeden Informationstransfer gleichzeitig mit der für diese Übertragung relevante Fehlererfassung durch. Falls ein Fehler entdeckt wird, erzeugt die Einheit unverzüglich ein Signal, das andere Prozessoreinheiten in Alarmzustand versetzt, den unmittelbar davorliegenden Informationstransfer nicht zu beachten. Das Prozessormodul kann den Informationstransfer vom Partner der als fehlerhaft erkannten Einheit her wiederholen. Diese Betriebsart erzeugt eine optimale Betriebsgeschwindigkeit, weil jeder Informationstransfer unverzüglich ausgeführt wird, ohne Verzögerung für die Zwecke der Fehlererfassung. Es kommt nur in den vergleichsweise wenigen Augenblicken zur Verzögerung, in denen ein Fehler entdeckt wird. Ein Bus- Prioritätsverteiler ist vorgesehen, der bestimmt, welche Einheit Zugriff auf den Systembus bekommt, wenn mehrere Einheiten Zugriff fordern.

Das fehlertolerante S/370 Modul 9, verschaltet über HSDIs, Netzwerke

Fig. 7 illustriert im Teil über dem Modul 10 auf dem Stand der Technik die Verschaltung der Duplex-Prozessorpaare S/370 und S/88 (Partnereinheiten) 21, 23, wodurch, wenn sie durch S/88 Duplexeinheiten 12, 14 in Modul 10 ersetzt werden, ein neues und eindeutiges S/370 Modul 9 erzeugt wird. Wenn solche einzigen Module 9 durch S/88 HSDIs und Netze auf ähnliche Weise verschaltet werden, wie in den Fig. 6B, 6C für Module 10 gezeigt wird, ergeben sie einen S/370 Komplex (anstatt eines S/88 Komplexes) mit den S/88 Merkmalen Fehlertoleranz, Einzelsystemabbildung, Möglichkeit des Einsetzens unter Spannung, E/A-Lastverteilung auf mehrfache S/88 Prozessoreinheiten innerhalb des gleichen Moduls usw.
Spezifisch führen S/370 Prozessoren in Partnereinheiten 21, 23 der eindeutigen Module 9 S/370-Anweisungen unter der Steuerung ihres entsprechenden S/370 Betriebssystems aus; die verschalteten S/88 Prozessoren führen alle S/370 E/A-Operationen zusammen mit ihren entsprechenden S/88 Speicher- und S/88 Peripherieeinheiten unter der Steuerung des S/88 Betriebssystems in Verbindung mit einem S/88 Applikationsprogramm durch.
Zusätzlich können weitere S/370-S/88 Prozessorpartnereinheiten 25, 27 und 29, 31 in das neue Modul 9 eingebaut werden, um eine S/370-Mehrfachprozessorumgebung innerhalb des einzigen Moduls 9 zuzulassen. Zusätzlich können die S/370 Prozessoren innerhalb der Partnereinheiten 21, 23 und 25, 27 und 29, 31 jeweils unter einem anderen S/370 Betriebssystem je Paar arbeiten.

Allgemeine Beschreibung der Duplex-Prozessorpartner-Einheiten 21, 23

Fig. 8 illustriert eine bevorzugte Form der Verschaltung von S/370 und S/88 Prozessoren innerhalb der Einheit 21. Der untere Teil der Einheit 21 enthält einen Zentralprozessor 12, der im wesentlichen identisch mit dem Prozessor 12 des US- Patents Nr. 4,453,215 ist, abgesehen von der Anwendung eines Einzel-Prozessorelements in jedem der Prozessorelementpaare 60, 62. Im obigen Patent waren Dualprozessoren bei 60 und 62 zur Durchführung des Anwendercodes bzw. des Betriebssystemcodes vorgesehen.
In der vorliegenden Applikation werden beide Funktionen durch einen einzigen Mikroprozessor ausgeführt, vorzugsweise durch einen Mikroprozessor Motorola MC68020, beschrieben im MC68020 Anwendermanual, 3. Auflage (ISBN-0-13-567017-9), herausgegeben von Motorola, Copyright 1989, 1988.
Somit beinhaltet jedes Prozessorelement (PE) 60 und 62 vorzugsweise einen Motorola 6802 Mikroprozessor. Multipexer 61, 63 verbinden die Prozessorelemente 60, 62 mit der Bus-Struktur 30 über Adressen/Daten-Steuerbusse A und B und Sender/ Empfänger 12e wie im oben genannten Patent genauer beschrieben ist. Für die Elemente 60, 62 ist örtliche Steuerung 64, 66 und eine virtuelle Speicherorganisation 12c vorgesehen. Ein Komparator 12f sucht nach fehlererzeugenden Störungen durch Vergleichen von Signalen auf den Steuer-, Daten- und Adressenleitungen zu und vom Bus 30 und den Prozessorelementen 60, 62. Fehlende Signalübereinstimmungen bewirken ein Fehlersignal vom Komparator 12f zur gemeinsamen Steuerschaltung 86, die Fehlersignale auf den X-Bus der Bus-Struktur 30 legt und (nicht dargestellte) Treiber in den Sender/Empfängern 12e abschaltet, um die Prozessoreinheit 12 off-line zu setzen. Klemmschaltungen 88, 90 sprechen auf einen Stromausfall an der Einheit 12 an, um alle Ausgangsleitungen aus der Einheit 12 zur Bus-Struktur 30 an Masse zu legen. Auch diese Komponenten sind im obengenannten Patent in näheren Einzelheiten beschrieben.
Der obere Teil der Fig. 8 illustriert eine bevorzugte Form der Verbindung eines Paars S/370 Prozessorelemente 85, 87 mit der S/88 Bus-Struktur 30 und mit den S/88 Prozessorelementen 60, 62. Die Prozessorelemente 85, 87 sind verbunden mit der Bus-Struktur 30 Über die Multiplexer 71, 73 und die Sender/ Empfänger 13 auf eine Weise, die logisch ähnlich der ist, in der die Elemente 60, 62 mit der Bus-Struktur 30 gekoppelt sind.
Eine Vergleichsschaltung 15 (die in den Fig. 32A, B naher beschrieben ist), Klemmschaltungen 77 und 79 und gemeinsame Steuerungen 75 sind vorgesehen und arbeiten auf ähnliche Weise wie die entsprechenden Komponenten der Einheit 12. Die Steuerschaltung 86 ist an den S/88 Interrupt-Mechanismus der Prozessorelemente 60, 62 gekoppelt. Die S/370 Prozessoren 85, 87 und die zugehörige Hardware benutzen die S/88 zum Abarbeiten der Fehlerbehandlung und -behebung. Somit ist die gemeinsame Steuerschaltung 75 Über die Leitung 95 an die gemeinsamen Steuerschaltung 86 gekoppelt, um diese letztere in die Lage zu versetzen, von der Vergleichsschaltung 15 gefundene Fehler zu behandeln. Diese Kopplungsleitung 95 ermöglicht auch, daß die gemeinsamen Steuerungen 75 und 86 ihre jeweiligen entsprechenden Prozessorpaare 85, 87 und 60, 62 im Falle eines Fehlers in irgendeinem Prozessor Prozessorpaars offline nehmen.
Eine bevorzugte Form der S/370 Prozessoreinheiten in Einheit 21 beinhaltet zentrale Speicherverwaltungseinheiten 81, 83 für Prozessorelemente 85, 87 und (z. B. S/370 und S/88) Prozessor/Prozessor-Schnittstellen 89, 91. Die Speicherverwaltungseinheiten 81, 83 koppeln Prozessorelemente 85, 87 über Multiplexer 71, 73, Sender/Empfänger 13 und Bus-Struktur 30 an den Hauptspeicher 16.
Schnittstellen 89, 91 koppeln die Prozessor-Busse der S/370 Prozessorelemente 85, 87 entsprechend an die Prozessorbusse der S/88 Prozessorelemente 62, 60.
Die Partnerprozessoreinheit 23 ist identisch mit der Prozessoreinheit 21. Hinsichtlich der obigen Beschreibung wird daran erinnert, daß die zwei Prozessorelemente 60, 62 in Einheit 21 und die entsprechenden zwei Elemente (nicht dargestellt) in Einheit 23 in der Regel schrittsynchronverriegelt miteinander arbeiten um identische Anweisungen unter der Steuerung des gleichen S/88 Betriebssystems gleichzeitig auszuführen.
Auf ähnliche Weise arbeiten auch die Prozessorelemente 85, 87 in Einheit 21 und ihre entsprechenden Elemente (nicht dargestellt) in Einheit 23 schrittsynchronverriegelt, um identische Anweisungen unter der Steuerung des gleichen S/370 Betriebssystems gleichzeitig auszuführen.
Für den Fall, daß in der Einheit 21 oder 23 ein Fehler auftritt, wird diese Einheit abgeschaltet, damit die andere Einheit die fehlertolerante Operation weiter ausführen kann.
Zwar werden einige Einzelheiten einer spezifischen Implementierung einer S/370 Prozessoreinheit nachstehend eingehend beschrieben, es ist jedoch anzumerken, daß auch andere Implementierungen benutzt werden können, die kompatibel mit den Forderungen gemäß Beschreibung im IBM System/370 'Principles of Operation' (veröffentlicht unter der Nr. GA22-7000-10, 11. Auflage, Sept. 1987), verlegt von und erhältlich bei International Business Machines Corporation, sind.
Die Fig. 9A und 9B zeigen eine Form des physikalischen Packens der S/370 und S/88 Komponenten für die Prozessoreinheit 21 der Fig. 8. Die S/370 Komponenten einschließlich der gepaarten Prozessorelemente 85, 87 sind auf einer Leiterplatte 101 montiert, und die S/88 Komponenten einschließlich der gepaarten Prozessorelemente 60, 62 sind auf einer anderen Leiterplatte 102 montiert. Die zwei Leiterplatten 101 und 102 sind starr aneinander befestigt und bilden ein Sandwich-Paar 103 und sind ausgelegt für das Einschieben in zwei Schlitze der Rückwandkonsole (nicht dargestellt) des Moduls 9, herkömmliche Rückwandkonsolenverdrahtung koppelt die Komponenten auf den Leiterplatten 101 und 102 miteinander und mit der Bus-Struktur 30, wie in Fig. 8 gezeigt und im US-Patent 4,453,215 beschrieben ist.
Bevor die Einzelheiten des Direktkoppelns eines S/370 Prozessors mit einem S/88 Prozessor beschrieben werden, ist es hilfreich, einen kurzen Hinweis auf den Mechanismus zu geben, der es zuläßt, daß der S/370 (1) einen Teil des S/88 Hauptspeichers benutzt und (2) Befehle und Daten mit dem S/88 austauscht unter Verwendung eines bestimmten Teils des virtuellen Speicherraums des S/88. Diese Mechanismen werden später noch eingehender beschrieben.
Anhand der Fig. 10 wird eine bevorzugte Form der Abbildung des S/88 virtuellen Speichers auf den realen Speicher 16 durch eine Speicherverwaltungseinheit 105 für nur ein Modul 9 gezeigt. Der virtuelle Speicherraum 106 ist unterteilt in S/88 Betriebssystemraum 107 und Anwenderapplikationsraum 108. Innerhalb des Raums 107 ist ein Bereich 109 (Adressen 007E0000 bis 007EFFFF), der für Hardware und Code zum Koppeln jedes S/370 Prozessorelements an ein entsprechendes S/88 Prozessorelement in einer Prozessoreinheit wie z. B. 21 benutzt wird. Während der normalen Systembearbeitung wird der Adressenraum 109 transparent für das S/88 Betriebssystem gemacht. Die Benutzung dieses Raums 109 wird nachstehend in Einzelheiten beschrieben.
Bei der Systeminitialisierung ordnet die Speicherverwaltungseinheit 105 jedem Satz von vier S/370 Prozessorelementen und Partnereinheiten, wie z. B. 21 und 23, jeweils einen S/370 Hauptspeicherraum innerhalb der S/88 Hauptspeichereinheit 16 zu. So werden also drei S/370 Hauptspeicherbereiche 162, 163 und 164 für die Partnereinheiten 21, 23 und 25, 27 und 29, 31 entsprechend vorgesehen. Die S/88 Prozessorelemente innerhalb der Partnereinheiten greifen auf die restlichen Teile der Speichereinheit 16 auf die in US-Patent 4,453,215 beschriebene Weise zu.
Die S/370 Speicherbereiche 162-164 werden zugewiesen, wie noch gezeigt wird, auf eine Weise, daß das S/88 Betriebssystem nicht weiß, daß diese Bereiche "gestohlen" wurden und durch die Speicherverwaltungseinheit den S/88 Anwendern nicht wieder zugewiesen werden können, es sein denn, sie werden dem S/88 Raum wieder zurückgegeben. Da die S/370 Systeme virtuelle Systeme sind, greifen sie auf ihre entsprechenden Hauptspeicherbereiche über eine Adreßumrechnung zu. Die Partner S/88 Hauptspeichereinheit 18 bedarf identischer S/370 Hauptspeicherbereiche (nicht dargestellt). Jedes S/370 Prozessorelement kann nur auf seinen entsprechenden S/370 Hauptspeicherbereich zugreifen und erzeugt ein Fehlersignal, wenn es versucht, auf den S/88 Hauptspeicherraum zuzugreifen. Jedes S/88 Prozessorelement kann jedoch bei E/A-Operationen auf den S/370 Hauptspeicherraum seines entsprechenden S/370 Prozessorelements zugreifen (bzw. seinen Zugriff umlenken), wenn das S/88 Prozessorelement als E/A-Controller für sein S/370 Prozessorelement arbeitet.

Koppeln von S/370 und S/88 Prozessorelementen 85, 62 (Fig. 11, 12)

Fig. 8 zeigt als Blockschaltbild das Vorsehen von vier S/370 Prozessorelementen 85, jeweils zwei in jeder Partnereinheit 21, 23, und vier S/88 Prozessorelemente 62, jeweils zwei in jeder Einheit 21, 23, so gekoppelt, daß alle S/370 Prozessorelemente gleichzeitig identische S/370 Anweisungen, und alle S/88 Prozessorelemente gleichzeitig identische S/88 Anweisungen ausführen. Somit arbeiten alle vier S/370 Prozessorelemente wie eine einzige S/370 Prozessoreinheit, soweit es sich um das Abarbeiten von Programmen handelt. Auf ähnliche Weise arbeiten alle vier S/88 Prozessoreinheiten als eine einzige S/88 Prozessoreinheit.
Aus diesem Grund werden zwecks leichterer Darstellung und Erklärung die nachstehenden Teile der Zeichnungen und Spezifizierungen in erster Linie nur ein S/380 Prozessorelement 85 und ein S/88 Prozessorelement 62 und ihre zugeordnete Hardware mit Programmcode ansprechen, abgesehen von Fällen, in denen die Komponentenverdopplung weiterer Erklärungen bedarf.
Auf ähnliche Weise wird das Ankoppeln von Prozessorelementen an die Busstruktur 30, z. B. über Multiplexer 61, 63, 71, 73 und Sender/Empfänger 12e, 11 in der folgenden Beschreibung zwecks Erleichterung der Darstellung und Erklärung im wesentlichen übergangen. Kurze Hinweise auf dieses Ankoppeln werden im Hinblick auf Fig. 32 gemacht.
Aus diesem Grund zeigt Fig. 11 das Prozessorelement 85, das an den Systembus 30 und den S/88 Speicher 16 über einen ersten Pfad einschließlich seines Prozessorbusses 170 angekoppelt ist, und eine S/370 Speicherverwaltungseinheit 81. PE85 wird über einen zweiten Pfad, einschließlich Prozessorelement/Prozessorelement-Schnittstelle 89, an den Prozessorbus 161 des PE62 angekoppelt gezeigt. PE85 benutzt während der S/370 Programmabarbeitung den ersten Pfad, um Daten und Anweisungen von dem ihm zugewiesenen S/370 Hauptspeicherbereich 162 im Speicher 16 zu holen (und abzuspeichern). PE62 führt S/370 E/A-Operationen für PE85 über den zweiten Pfad einschließlich der Schnittstelle 89 aus.
In einer bevorzugten Ausführungsform beinhaltet ein S/370 Chip-Satz 150 (Fig. 11) individuelle Funktions-Chips für das Prozessorelement 85, einen Taktgeber 152, einen Cache- Controller 153 mit einer Verzeichnis-Seitenzugriffstabelle (Directory Look Aside Table - DLAT) 341, Busadapter 154, ein optionales Fließkomma-Coprozessorelement 151 und einen Steuerspeicher 171 zum Abspeichern eines Mikrocode-Satzes, der die S/370 Architektur unterstützt. Dieser S/370 Chip-Satz kann so ausgelegt sein, daß er durch jedes der existierenden S/370 Betriebssysteme (wie z. B. VSE/SP, VM/SP, IX/370 usw.) betrieben wird, die von der International Business Machines Corporation vertrieben werden.
Der Cache-Controller 153 zusammen mit der Speichersteuer- Schnittstelle (STCI) 155 bilden die S/370 Speicherverwaltungseinheit 81. Der Busadapter 154 und eine Bussteuereinheit (BCU) 156 beinhalten die PE/PE-Schnittstelle 89.
In der bevorzugten Ausführungsform ist jede der S/370 CPUs, wie das PE85, ein 32-Bit-Mikroprozessor mit einem 32-Bit- Datenfluß, einer 32-Bit-Arithmetik/Logik-Einheit (ALU), 32- Bit-Registern in einem örtlichen Drei-Port-Datenspeicher, und einem 8-Byte-S/370-Anweisungspuffer. Die S/370-Anweisungen werden entweder als Hardware ausgeführt oder durch Mikroanweisungen interpretiert. Der Chip 153 sieht eine Cache- Speicherung für S/370-Programmanweisungen und -daten zusammen mit zugeordneten Speichersteuerfunktionen vor. Der Chip 153 handhabt alle Speicheranforderungen, die vom PE85 her ausgegeben werden, wenn es seine Programmanweisungen ausführt. Der Chip 153 handhabt auch Anforderungen vom Busadapter 154 beim Übertragen der E/A-Daten.
Der Busadapter 154 und die BCU 156 liefern die Logik und die Steuerung, um den internen S/370-Prozessorbus 170 mit dem S/88 Prozessorbus 161 während Eingangs/Ausgangs-Operationen direkt (oder eng) zu verbinden. Die BCU 156 ist der primäre Mechanismus zum Direktankoppeln der Prozessorbusse des PE85 und des PE62. Es ist der Hardware-Mechanismus, der mit dem S/88 Prozessorelement 62 zusammenarbeitet, wenn das PE62 von seiner ihm zugeordneten Systemhardware für die Übertragung von Daten und Befehlen zwischen PE65 und PE85 "abgekoppelt" wird, wie später noch beschrieben wird.
Der Taktgeber-Chip 152 (Fig. 12) benutzt zentralisierte Logik für Taktsignalgenerierung und legt geeignete Taktsignale individuell auf jeden der anderen Chips 85, 151, 153 und 154. Der Taktgeber 152 wird seinerseits über Taktsignale vom System/88-Bus 30 gesteuert, um sowohl das S/370 PE85 als auch das S/88-PE62 zu synchronisieren.
Ein integrierter Teil zum Verschmelzen der zwei unterschiedlichen S/370 und S/88 Hardware-Architekturen, neben der Prozessor-Kopplungs/Abkopplungs-Hardware ist ein Mittel zum synchronen Zusammenhängen der vorhergehenden nicht-fehlertoleranten Hardware mit der fehlertoleranten Busstruktur 30. In der bevorzugten Ausführungsform wird diese Schnittstelle von der STCI-Logik 155 gehandhabt, die zwischen dem S/370 Cache- Controller 153 und dem S/88 Systembus 30 kommunizieren muß. Ferner muß die nicht fehlertolerante Hardware auf dem Board repliziert werden, wie in Fig. 8 gezeigt wird, um eine 'Check' (Prüf)- und 'Drive' (Treiber)-Logik zu erzeugen, die in der Lage sind, schrittsynchronverriegelt miteinander und mit einer Partnereinheit zu laufen. So muß die 'einzige' CPU, die aus den Systemkomponenten auf den Boards 101 und 102 besteht, schrittsynchronverriegelt mit ihrer entsprechenden Duplex-Partnereinheit laufen. Die Aufgabe des Implementierens der obigen Forderungen unter Wahrung einer optimalen Leistung und Funktionalität beinhaltet die Synchronisierung getrennter Taktquellen.
In der bevorzugten Ausführungsform wird der S/88 Systemtaktgeber 38 (Fig. 7) von allen an die gemeinsame Busstruktur 30 angeschlossenen Vorrichtungen empfangen, und je Buszyklus 30 werden zwei S/88 Taktzyklen definiert. Dieser Systemtaktgeber 38 sichert die synchrone Kommunikation auf dem Bus und kann von den einzelnen Prozessoren/Controllern benutzt werden, interne Taktfrequenzquellen auf der Grundlage des Systemtaktgebers zu entwickeln. Die S/370 Hardware benutzt einen Oszillatoreingang in den S/370 Takt-Chip 152, der dann einen Satz einziger Takte für jeden der anderen S/370-Chips 85, 151, 153, 154, 155 generiert. Dieser Takt-Chip 152 hat eine inhärente Verzögerung, die sich auf der Grundlage verschiedener Parameter wie Betriebstemperatur, Fertigungsvariationen usw. verändern kann. Diese Verzögerungsveränderung kann sowohl für die Schrittverriegelungssynchronisation zwischen redundanter Check- und Drive-Logik, als auch für das Beibehalten der vollen Warteschlangenfähigkeit zwischen der STCI 155 und der Busstruktur 30 unannehmbar sein.
Wie in den Fig. 12 und 19c gezeigt wird, benutzt die bevorzugte Ausführungsform eine redundante Taktgeber-Synchronisierungslogik 158 (sync) (und 158a, nicht dargestellt, für die gepaarte S/370 Prozessoreinheit), damit ermöglicht wird, daß beide Prozessor-Check-and-Drive-Seiten eines Boards 101 nach einem Reset (d.i. Einschalt-Reset oder ein anderer Reset) schrittsynchronverriegelt laufen, während der S/370 Prozessorzyklus mit dem S/88 Bus-30-Zyklus synchronisiert wird. Taktsignale vom S/88 Taktgeber 38 werden über die Bus-Struktur 30 an die Sync-Logik 158 und an die STCI 155 gelegt zur S/88-S/370-Synchronisierung und zum Zugriff auf den Hauptspeicher über den Systembus 30.
Diese Synchronisierung wird in der Takt-Sync-Logik 158 erreicht durch zunächst Vervielfachen des S/88 Takts, um die gewünschte S/370 Oszillatoreingangsfrequenz zum S/370 Taktgeber-Chip 152 zu erreichen. In diesem Fall ist das das Doppelte der Frequenz der S/88 und S/370 Taktzyklen. Zweitens wird ein Rückkopplungsimpuls auf Leitung 150, der den Anfang des S/370 Zyklus kennzeichnet, mit S/88 Takten abgetastet, die die Anstiegsflanke und Abfallflanke einer Einperioden- Registerzwischenspeicherverzögerung repräsentiert, die größer ist als die S/370 Oszillatoreingangstaktperiode, die selbst gleich einer S/88 Halbzyklusperiode ist. Im Falle eines Reset, in dem der abgetastete S/370 Taktrückkopplungsimpuls auf Leitung 159 außerhalb des Abtastfensters fällt, oder der den Anfang des S/88 Takts überlappt, wird der S/370 Oszillatoreingang für einen S/370 Zyklus negiert. Das dient zum "Erweitern" des augenblicklichen S/370 Zyklus, so daß in der bevorzugten Ausführungsform der nächste abgetastete S/370 Taktrückkopplungsimpuls (auf Leitung 159) mit Sicherheit in das gewünschte Fenster fällt. Die gesamte Komparatorlogik 15 (Fig. 8), die in Fig. 32 (z. B. 402 a-g) in näheren Einzelheiten dargestellt wird, wird während dieser Zeit ignoriert, damit sich die Check- und Drive-Hardware synchronisieren kann.
Somit ist sichergestellt, daß der S/370 Prozessorzyklus innerhalb eines S/88 Halbzyklus-Periode ab dem Anlaufen der S/88 Taktperiode anfängt. Die gesamte Transfertaktung zwischen der Bus-Struktur 30 und dem S/370 Cache-Controller 153 übernimmt für diesen Halbzyklus die Verzögerung des schlechtesten Falls. Zusätzlich wird die Komparatorlogik 15 nur über Leitungen gespeist, die mit den S/88 Takten abgetastet wurden, und stellt so die Synchronisierung einer "gebrochenen" Logik 403 (Fig. 32) mit dem zugehörigen S/88 Prozessorboard 102 sicher. Daher wird, obwohl die Check-and-Drive S/370- Hardware in Wirklichkeit infolge der Verzögerungsveränderun gen in ihrer entsprechenden Taktgenerierungslogik etwas aus der Synchronisation laufen kann, sichergestellt, daß beide Seiten in Schrittsynchronverriegelung mit dem augenblicklichen S/88 Takt 38 gemeinsam mit der Bus-Struktur 30 laufen und nie mehr als einen Halbzyklus hinter dem Anlaufen des S/88 Taktzyklus zurückbleiben. Die Sync-Logik 158 überwacht kontinuierlich die S/370 Taktrückkopplung auf Leitung 159, um sicherzustellen, daß kein Driften über die Halbzyklusperiode hinaus vorkommt. Maximal ein Bus-30-Zyklus ist in der bevorzugten Ausführungsform nötig, um beide Seiten bei einem System-Reset in Synchronisation zu bringen; jedoch wird jede Drift in der Gesamtverzögerung außerhalb des Reset, die bewirkt, daß eine Seite ihre S/370 Takte 'erweitert', zu einem "gebrochenen" Zustand in einem Board, d. h. zu einem Fehler führen.
Fig. 12 zeigt die Anordnung der Fig. 11 in näheren Einzelheiten. Der S/370 Steuerspeicher 171 wird an das PE85 angeschlossen gezeigt. Der Steuerspeicher 171 in der bevorzugten Ausführungsform besteht aus 16kB Speicher mit wahlfreiem Zugriff zum Speichern von Mikroanweisungen, die die Ausführung der Programmanweisungen und E/A-Operationen im PE85 steuern. Der Steuerspeicher 171 beinhaltet auch darin einen 64B Block 186 (Fig. 29), der als Puffer benutzt wird, um vorübergehend einen Mikrocode aufzunehmen, der auf Anforderung aus einem internen Objektbereich (Internal Object Area - IOA) 187 (Fig. 28) geladen wird, der Teil des S/370 zugeordneten Speichers 162 innerhalb der Hauptspeichereinheit 16 ist. In dieser Figur wird die Bus-Struktur 161 des PE62 unterteilt in seinen virtuellen Adressenbus 161A und in den Datenbus 161D dargestellt. Das PE62 hat ihm zugeordnete Hardware einschließlich eines Fließkommaprozessors 172, einen Cache 173, eine Mikrocode-Speichereinheit 174, die benutzt wird, um den Kopplungsmikrocode zu speichern, der hier ETIO genannt wird. Sowohl der Mikrocode als auch ein im Cache 173 gespeichertes Applikationsprogramm werden, wie nachstehend gezeigt ist, zur Steuerung des PE62 und der BCU-Logik 156 zum Ausführen der E/A-Operationen für das PE85 benutzt.
Die PE62 Hardware beinhaltet ferner einen Adressenübersetzungsmechanismus 175. Eine Write-Pipe 176 zwischenspeichert Daten während eines Schreibzyklus zum Legen dieser Daten auf den Systembus 30 während des nächsten Zyklus, um den Betrieb des Systems/88 zu beschleunigen. Die System/SB- Buslogik 177 des im US-Patent 4,453,215 beschriebenen Typs koppelt die Übersetzungseinheit 175 und die Write-Pipe 176 an den Systembus 30 auf eine Weise, wie sie im obengenannten Patent allgemein beschrieben wird. Eine ähnliche System/88- Buslogikeinheit 178 koppelt die Speichersteuer-Schnittstelle 155 an den Systembus 30.
Ein Puffer 180, ein programmierbarer Festwertspeicher 181, ein Speicher 182 und eine Registersatz 183 sind an das PE62 gekoppelt zur Verwendung während der Initialisierung des System/88 und des System/370. Der PROM 181 enthält den Systemtestcode und den IDCODE, die zum Urladen des Systems von einer Einschaltsequenz erforderlich sind. PROM 181 enthält den Synchronisationscode für S/88. Das Register 183 enthält den System-Status und das Steuerregister.
Zwei S/370 Chip-Sätze sind auf der gleichen physikalischen Leiterplatte montiert, werden in Synchronisation gebracht, und führen Programme schrittsynchronverriegelt aus, um die Board-Eigenkontrolle durchzuführen. Der STC-Bus 157 und ein Kanal-Bus 0, 1 wird auf potentielle Fehler überwacht, so daß das S/370 keinen Fehler auf eine andere, im Feld austauschbare Einheit weiterübertragen kann.
Die BCU 156 und der Adapter 154 der Schnittstelle 89 ermöglichen, daß jeder Prozessor (PE62, PE85) eine geeignete Kontrolle über den anderen Prozessor ausübt, so daß kein Betriebssystem die volle Kontrolle über das System hat. Jede Prozessorfunktion wird teilweise kontrolliert von der Schnittstelle 89 und vom Mikrocode, der in jedem Prozessor läuft.

Prozessor/Prozessor-Schnittstelle 89

1. E/A-Adapter 154

Der Adapter 154 (Fig. 13) steht in Schnittstellenverbindung mit dem S/370 Prozessor 85 zur BCU 156 über seine Ausgangskanäle 0, 1. Die Kanäle beinhalten ein Paar asynchroner zwei Byte breite Datenbusse 250, 251. Die Busse 250, 251 sind über ein Paar 64-Byte-Puffer 259, 260 an den synchronen vier Byte breiten Datenpfad im Prozessorbus 170 gekoppelt. Daten werden von der BCU 156 zum Adapter 154 (und S/370 Hauptspeicher 162) über den Bus 251, und vom Adapter 154 zur BCU 156 über den Bus 250 übertragen.
Der Adapter 154 beinhaltet die folgenden Register:
1. das Basisregister 110 enthält die Basisadresse und die Warteschlangenlänge, die für die Warteschlangen- und Mailbox-Adressierung verwendet wird.
2. Die Lesezeiger- (Readpointer - RPNTR) und Schreibzeiger- (Writepointer - WPNTR) -Register 111 und 112 enthalten den Adressenoffset von der Basisadresse zum nächsten Warteschlangeneintrag, auf den zum Lesen bzw. Schreiben zugegriffen werden muß. Ihre Werte werden zusammen mit dem Befehl in das Bus-Senderegister (BSR) 116 geladen, wenn der Befehl/Adresse zum Cache-Controller 153 über den Bus 170 übertragen werden müssen.
3. Das Status-Register (IOSR) 118 enthält alle PU/BCU und BCU/PU-Anforderungen, den Status der eingehenden Mitteilungswarteschlange, und den Status der BCU-Schnittstelle.
4. Wenn ein Bit im Ausnahmeaktivierungsregister (Exception enable Register - ER) 119 auf 1 steht und das entsprechende IOSR-Bit 1 ist, dann wird eine Ausnahme im PE85 hoch gestellt.
5. Das Steuerwortregister (CW) 120 steuert das Setzen/Neusetzen einiger IOSR-Bits.
6. Das Adressen-Grenzprüfregister (Adress Check Boundary Register - ACBR) 121 enthält die Startseitenadresse des internen Objektbereichs (Internal Object Area - IOA) 187.
7. Die Adressenschlüsselregister (ADDR/KEY) 122, 123 werden in der Regel von der BCU 156 über die Adressen/Datenbusse 250 und 251 geladen, um auf eine Speicherstelle 162 zugreifen zu können. Diese Register können vom PE85 für Testzwecke geladen werden.
8. Die Befehlsregister (CMD0,1) 124, 125 werden in der Regel von der BCU 156 mit einer Befehls- und Byte-Zählung geladen. Die Register können vom PE85 für Testzwecke geladen werden.
Der Adapter 154 ist die Schnittstelle zwischen dem PE85 und der BCU 156. Logisch sieht der Adapter 154 die folgenden Dienstleistungen an die BCU 156 vor:
- Zugriff auf den S/370 Hauptspeicher 162
- Zugriff auf eine Mailbox und eine Meldungs-Warteschlange im S/370 Speicher 162
- Anforderungs/Anwort-Mechanismus zwischen PE85 und BCU 156.
Die BCU 156 hat Zugriff auf den kompletten Speicher 162, einschließlich seines IOA-Bereichs 187 (Fig. 28). Der Adapter 154 führt die Adressengrenzenprüfung (ACB-Check) zwischen dem IOA-Bereich 187 und dem Anwenderbereich 165 durch, während die Schlüsselprüfung vom Cache-Controller 153 nach Eingang des Schlüssels, des Befehls und der Speicher-162-Adressendaten über den Prozessorbus 170 vom Adapter 154 erfolgt ist. Wenn die angesprochene zu speichernde Datenleitung im Cache enthalten ist, dann werden die Daten im Cache gespeichert. Wenn nicht, überträgt der Controller 153 die Daten in den Hauptspeicher 162. Beim Datenabruf funktioniert der gleiche Mechanismus im Cache-Controller 153.
E/A-Befehls- und Meldungsübertragungen zwischen dem PE85 und der BCU 156 laufen über vordefinierte Speicher-162-Stellen (Mailbox-Bereich 188 und Eingangs-Meldungswarteschlange 189), gezeigt in Fig. 28.
Die BCU 156 holt E/A-Befehle aus dem Mailbox-Bereich 188 mit 16 Bytes. Die Adresse für Zugriffe auf den Mailbox-Bereich errechnet sich wie folgt:
Basisadresse + Meldungswarteschlangenlänge + Offset in Mailbox.
Die ersten beiden Terme werden vom Basisregister 110 des Adapters 154, der letzte von der BCU 156 geliefert. Die Warteschlangenlänge wird von zwei Bits im Basisregister 110 auf 1, 2, 4 oder 8kE (d.i. 64 bis 512 Einträge) gesetzt. Die Basis wird im Basisregister 110 auf eine Grenze von zwei Mal die Puffergröße (d. i. 2-16 kE) eingestellt.
Die Eingangs-Meldungswarteschlange 189 speichert alle über die BCU 154 eingegangenen Meldungen in chronologischer Reihenfolge. Jeder Eintrag ist 16 Bytes lang.
Der Lesezeiger (RPNTR) und der Schreibzeiger (WPNTR) in den Registern 111, 112 werden von der BCU 156 zum Lesen der Einträge aus, und Schreiben der Einträge in die Warteschlange 189 benutzt. Das PE85 greift auf den Lesezeiger über eine Abtastoperation zu. Die Basisadresse im Register 110 plus WPNTR zeigt auf den nächsten zu schreibenden Warteschlangeneintrag, und die Basisadresse plus RPNTR zeigt auf den nächsten zu lesenden Warteschlangeneintrag.
Diese Zeiger werden nach jeder Warteschlangenoperation aktualisiert:
WPNTR + 16 = WPNTR nach einem Schreiben
RPNTR + 16 = RPNTR nach einem Lesen
Aus einem Vergleich der Zeiger ergeben sich die folgenden Zustände:
RPNTR = WPNTR Warteschlange ist leer
RPNTR = WPNTR + 16 Warteschlange ist voll; wenn die BCU 156 Schreiben in die Warteschlange fordert, wird Puffer nicht frei (BNA) über den Statusbus an die BCU geschickt.
Die Gültigkeit der im Mailboxbereich 188 gespeicherten Daten wird vom PE85 an die BCU 156 und umgekehrt über den nachstehenden Mechanismus signalisiert:
Die PU-Anforderung an BCU über Leitung 256a (Fig. 16) wird vom PE85 mit einer Steuer-Mikroanweisung gestellt. Sie weist die BCU 156 an, einen Befehl von der Mailbox 188 zu holen und auszuführen. Die Anforderung wird von der BCU nach Ausführen des Befehls rückgestellt. Der Zustand der Anforderung kann vom PE85 abgetastet werden.
Die BCU 156 macht eine Anforderung, wenn ein Problem auftritt, entweder während der Ausführung eines Befehls, der vom PE85 eingeleitet wird, oder zu einem beliebigen anderen Zeitpunkt. Sie bewirkt einen Ausnahmezustand im PE85, falls sie nicht selektiv maskiert wird.
Der Adapter 154 stimmt mit der Übertragungsgeschwindigkeit der asynchronen Adapterkanäle 0, 1 zum Synchronen Prozessorbus 170 überein. Daher wird die BCU 156 von 64-Byte-Datenpuffern 259, 260 im Adapter 154 zum Datentransfer zu und von der BCU 156 unterstützt. Die Anordnung hat einen 4-Byte-Port zum Kanal-0,1-Bus und zum Prozessorbus 170.
Synchrone Register 113, 114 puffern Daten, die zwischen der BCU 156 und den Pufferanordnungen 260, 259 übertragen werden. Busempfangs- und -senderegister 116 und 116 speichern die vom Prozessorbus 170 her eingehenden bzw. an ihn zu sendenden Daten entsprechend ab.
Eine Speicheroperation (E/A-Datenspeicher, Warteschlangenoperation) wird gestartet von der BCU 156, die die Befehls/Byte- Zählung, Schutzschlüssel und Speicheradresse über den Kanal- 1-Bus an den Adapter 154 schickt. Die Befehls/Byte-Zählung wird auf dem Befehlsbus 252 (Fig. 13) aufgenommen und im Befehlsregister 125 gespeichert. Schlüssel- und Adressendaten werden von der BCU 156 über den Adressen/Datenbus 251 (Fig. 13) empfangen und im Schlüssel/Adressenregister 123 gespeichert. Die Matrixschreib- und -leseadressenzeiger werden im Register 128 auf ihre Anfangswerte gesetzt. Die Anzahl der Datenübertragungen (gleichzeitig 2 Bytes) auf dem Bus 251 werden von der Byte-Zählung bestimmt. Mit einer Speicheroperation können bis zu 64 Datenbytes übertragen werden. Die Speicheradresse eines Byte innerhalb einer Speicheroperation darf die 64 Byte-Speichergrenze nicht überschreiten.
Dem Befehl/Adresse folgen Datenzyklen auf dem Bus 251. Alle Daten werden im 64-Byte-Puffer 260 aufgenommen. Nachdem die letzten Daten vom BCU-Bus 156 her aufgenommen sind, führt der Adapter 154 zunächst eine interne Prioritätsprüfung (nicht dargestellt) für die zwei Datenpuffer 259, 260 durch, und fordert dann die Herrschaft (nicht dargestellt) über den Prozessorbus 170 an, wo Adapter 154 die höchste Anforderungspriorität hat.
Im Fall, daß beide Puffer 259, 260 gleichzeitig eine Übertragung anfordern, gibt die interne Prioritätssteuerung die Priorität zunächst dem Puffer 259 und dann ohne einen Prioritätsverteilungszyklus dem Puffer 260 für den Bus 170, d. h. Lesen hat Vorrang vor Schreiben.
Wenn die Busherrschaft zugeteilt ist, werden Befehls/Byte- Zählung, Schutzschlüssel und Anfangsadresse zum Cache- Controller 153 übertragen. Dem Befehlsübertragungszyklus folgen dann Datenübertragungsszyklen.
Der Cache-Controller 153 führt die Schutzschlüsselprüfung durch. Eine Schlüsselverletzung wird im Bus-170-Status an den Adapter 154 berichtet. Weitere Prüfbedingungen, die vom Cache-Controller 153 und vom Hauptspeicher 162 gefunden werden, werden im ANY-CHECK-Status berichtet. Eine Schlüsselverletzung und Statuszustände, die vom Adapter 154 festgestellt werden, werden in einem Status-Transferzyklus an die BCU 156 geschickt.
Es gibt zwei mögliche vom Adapter 154 entdeckte Statusbedingungen, die an die BCU 156 berichtet werden können. Für beide Prüfbedingungen wird der Zugriff auf den Speicher 162 unterdrückt.
Jede Hauptspeicheradresse, die von der BCU 156 her eingeht, wird mit der im ACB-Register enthaltenen Adresse verglichen, um zu bestimmen, ob der Zugriff auf den IOA 187 oder auf den Kundenbereich 165 des Speichers 162 geht. Ein "Kunden"-Bit, das zusammen mit jedem Befehl von der BCU 156 eingeht, legt fest, ob der Hauptspeicherzugriff auf den IOA-Bereich 187 oder auf den Kundenbereich 165 gemeint ist, und prüft auf unrichtige Zugriffe.
Ein Puffer nicht verfügbar (Buffer Not Available - BNA) Zustand, der nachstehend beschrieben wird, wird nur für Warteschlangenoperationen berichtet.
Leseoperationen (E/A-Lesen, Mailbox-Lesen) werden von der BCU 156 auf im wesentlichen die gleiche Weise gestartet wie die Speicheroperationen. Sobald die Befehls/Byte-Zählung, der Schutzschlüssel und die Adresse von der BCU 156 her eingehen, wird der Adapter-154-interne Prioritäts-Check durchgeführt und die Prozessor-170-Herrschaft wird angefordert. Wenn die Busherrschaft erteilt ist, werden Befehls/Byte-Zählung, Schutzschlüssel und die Hauptspeicher-Anfangsadresse zum Cache-Controller 153 übertragen, um den Lesezyklus anlaufen zu lassen. Adapter 154 lädt die abgerufenen Daten zunächst in einen Puffer 259 und dann, auf Anforderung der BCU über den Bus 250, zur BCU 156. Mit jedem Datentransfer wird der Status berichtet.
Die Statusbedingungen und der Berichtsmechanismus für Speicheroperationen gelten für Leseoperationen.
PE85 kann über den Bus 170 auf die meisten Register im Adapter 154 sowohl mit Abtast-(Lese)- als auch Steuer-(Schreib)- Operationen zugreifen.
Für Abtastoperationen wird der Befehl auf den Adapter 154 übertragen und in das Register 129 zwischengespeichert. Im nächsten Zyklus wird der Abtast-Multiplexer 126 gemäß dem Befehl angewählt, und der Befehl wird in das BSR 116 geladen, um die erwarteten Daten gültig im nachfolgenden Bus-170- Zyklus zu haben.
Wenn ein interner Paritätsfehler auf dem abzutastenden Register bemerkt wird, sendet der Adapter 154 Daten mit richtiger Parität zurück an das PE85, legt jedoch eine Prüfbedingung auf den Schlüssel/Statusbus. Diese Funktion kann mit einem spezifischen Abtast-Codepunkt getestet werden.
Für Steueroperationen folgen dem BUS-170-Befehl Daten, die im nächsten Zyklus in das Zielregister geladen werden.
Wenn im Bus 170 im Befehlszyklus für Abtast- oder Steueroperationen oder im Datenzyklus für Steueroperationen ein Paritätsfehler entdeckt wird, erzwingt der Adapter 154 einen Taktstop.
Das Basisregister 110 enthält die Basisadresse, die für Warteschlangen- und Mailbox-Adressierung und für den Warteschlangenlängencode benutzt wird. Die Warteschlange fängt an der Basisadresse an, der Mailbox-Bereich an der Adresse Basis + Warteschlangenlänge.
Die RPNTR- und WPNTR-Register 111 und 112 enthalten den Offset von der Basisadresse zum nächsten Warteschlangeneintrag, auf die beim Lesen bzw. Schreiben zugegriffen werden muß.
Beim Abtasten werden die Lese- und Schreibzeiger durch den Abtast-Multiplexer 126 im Adapter 154 mit der Basisadresse verkettet. Daher ist das von der abgetasteten Operation er faßte Wort die komplette Adresse des nächsten Warteschlangeneintrags, auf den zugegriffen werden soll.
Das E/A-Statusregister enthält die folgenden Bits (zusätzlich zu noch weiteren, die hier nicht beschrieben werden):
Jeder Check (Bit O) - Auf 1 gesetzt, wenn eine Check-Bedingung in CHSR< 0..24> und entsprechend CHER-Bit 1 ist. Jeder Check bewirkt ATTN-REQ. Wenn MODE-REQ< 1> = 1, dann wird signal Clock_Stop_Diana aktiviert.
BNA gesendet (Bit 6) - Puffer nicht verfügbar (BNA)-Bit ist 1, wenn BCU 156 das Abspeichern einer eingehenden Meldung in die Warteschlange versucht und die Warteschlange voll ist, d.i. RPNTR ist gleich WPNTR + 16. Dieses Bit kann nur rückgestellt werden durch Schreiben einer 1 in das CW-Register 120, Bit 6.
Warteschlange nicht leer (Bit 7). Dieses Bit ist 1, wenn RPNTR nicht gleich WPNTR ist. Es ist 0, wenn RPNTR = WPNTR. Das ist das Mittel, das benutzt wird, dem Prozessor 85 mitzuteilen, daß eine neue Meldung eingegangen ist.
BCU an PU Anforderung (Bits 10 und 14) - Gesetzt von der BCU 156 über das Signal auf der 'BCU to PU Request'-Leitung 256c für Kanal 0 und 1. Das Rückstellen der Bits 10 und 14 durch PE85 erzeugt ein 'BCU to PU acknowledge' auf Leitung 256d für Kanäle 0 und 1.
PU to BCU Req. (Bit 11) - Gelegt auf Leitung 256a durch PE85 durch Setzen des Bit 11 des CW-Registers 120 für Kanal 0, und Bit 15 CW Register 120 für Kanal 1. Rückstellen durch 'PU to BCU acknowledge'-Signal auf Leitung 256b.
BCU Strom-aus (Bit 13) - Dieses Bit wird durch die BCU 156 auf 1 gesetzt, wenn sie ohne Strom ist oder wenn ein 'Poweron Reset' vorkommt. Es wird auf 0 rückgestellt, wenn eine 1 in das 'Reset BCU Powerloss'-Bit des CW-Registers 120 geschrieben wird und die BCU nicht mehr länger im stromlosen Zustand ist.
Allow Arbitration (Bit 28) - Dieses Bit aktiviert das Kanalbussignal 'Allow Arbitration', wenn Bit 3 des Adaptermodusregisters nicht aktiviert ist.
Das Kundenzugriffs-Bit, das Teil des Befehls/ Adresse ist, der von der BCU 156 her eingeht, bestimmt, ob der Speicherzugriff im IOA oder im Kundenspeicherbereich liegt. Wenn das Kundenzugriffs-Bit '0' ist, muß die Seitenadresse für den Speicherzugriff innerhalb des IOA-Bereichs 187 liegen. Für diese Zugriffe gibt es keine Schlüsselprüfung, daher setzt die Adapter-Hardware den Schlüssel auf Null (stimmt mit allen Schlüsseleinträgen überein).
Wenn das Kundenzugriffs-Bit '1' ist, muß die Seitenadresse für den Speicherzugriff innerhalb des Kundenspeicherbereichs 165 liegen. Ansonsten wird für den Zugriff eine ACB- Prüfbedingung hoch gesetzt.
Das PE85 benutzt Meldungsbefehle zum Lesen (Abtasten) oder Schreiben (Steuern) der Adapter-154-Register.
Das Format dieser Befehle ist wie folgt:
Bits 0-7 CMD = Befehlstyp
8-11 SRC = fordert Buseinheitadresse an
12-15 DST = erhält Buseinheitadresse
16-23 MSG = im cmd Zyklus zu übertragende Daten
24-27 REG1 = Registernummer für CONTROL
28-31 REG2 = Registernummer für SENSE
Das DST-Feld für die PU-BCU-Schnittstelle ist X'8'. Der Adapter 154 decodiert das SRC und MSG-Feld nicht weil dort keine Informationen für die Befehlsausführung enthalten sind. Während der Steuer- und Abtastoperationen definieren die Reg1- und Reg2-Bits entsprechend die Register im Adapter 154, in die eingeschrieben bzw. aus denen ausgelesen werden muß.
2. E/A-ADAPTERKANAL 0 UND -KANAL 1 BUS (Fig. 16) Der Adapterkanal 0 und der Adapterkanal 1 sind Hochgeschwindigkeitsverbindungen vom E/A-Adapter 154 zur Bussteuereinheit 156.
Kanal 0 beinhaltet:
Adressen/Datenbus 250 (Bits 0-16, P0, P1)
Befehls/Status-Bus 249 (Bits 0-3, P)
Tag Up (BCU an Puffer) Leitung 262a
Tag Down (Puffer an BCU) Leitung 262b
PU an BCU Anforderungsleitung 256a
BCU an PU Quittierungsleitung 256b
Kanal 1 beinhaltet einen Adressen/Datenbus 251, einen Befehls/Statusbus 252 und Tag Up und Tag Down Leitungen 262c und 262d.
Kanal 0 wird benutzt für Datenübertragungen aus dem S/370- Speicher 162 (und PE 85) zur BCU 156, und Kanal 1 wird benutzt für Datenübertragungen von der BCU 156 an den Speicher 162 (und PE85).
Die Kanalbusse 249, 250, 251 und 252 nehmen ihren Ausgang im E/A-Adapter 154, der im wesentlichen ein Paar Datenpuffer mit Steuerlogik ist, die jeder bis zu 64 Bytes Daten speichern können. Die Busse enden in der BCU 165. Der E/A-Adapter dient als Schnellvergleich zwischen dem S/370 internen Prozessorbus 170 mit seinem Vollwortformat (32 Bits) und den langsameren Bussen 249-252 mit ihrem Halbwortformat (16 Bits).
Jeder Kanal ist in zwei Teile organisiert, der Zwei-Bytebreite (Halbwort) Datenbus (250, 251) und der Halb-Bytebreite (4-Bit) Befehls/Statusbus (249, 252). Tag-(Kennzeichen)-Signale sehen Mittel vor zum Steuern der Operationen über Anforderungs/Antwort- und Sondersignale.
Der Datentransfer über jeden Kanal erfolgt immer in zwei Zyklen (um vier Bytes über den Zwei-Byte-Bus zu übertragen). Logisch erfolgt jeder Datentransfer zwischen dem S/370 Hauptspeicher 162 und dem E/A-Teilsystem einschließlich der BCU 156. Die BCU 156 ist der Master, d. h., sie läßt jede Transferoperation anlaufen sobald das PE58 den entsprechenden Bedarf signalisiert hat.
Der Befehls/Statusbus (249, 252) wird während eines Ansteuerzyklus benutzt, um die Übertragungsrichtung (Abrufen/Speichern) und die zu übertragende Datenmenge zu definieren. Der Adressen/Daten-Bus (250, 251) dient zum Übertragen der Hauptspeicheradresse während des Ansteuerzyklus und liefert die Daten während des Übertragungszyklus. Er wird auch benutzt, um spezifische Bereiche 188, 189 im Speicher 162 anzusprechen, die als "Mailbox" und "Meldungswarteschlange" bezeichnet werden. Diese Bereiche ermöglichen es, daß das PE85 bestimmte Informationen mit der BCU 156 austauscht.
Während einer Abrufoperation (aus dem Speicher 162) wird der Status über den Befehls/Status-Bus 249 zusammen mit den ersten zwei Bytes auf dem Bus 250 übertragen. Dieser Status zeigt jede Adressenprüfung, Schlüsselprüfung usw., oder ist Null, um eine erfolgreiche Operation anzuzeigen.
Wenn eine Speicheroperation (in den Speicher 162) ausgeführt wird, folgt ein Statuszyklus, nachdem alle Daten in den Hauptspeicher 162 gesendet wurden.
Die Fig. 14A und 14B zeigen die logische Verwendung des Busteils während des Unterzyklus 1 und des Unterzyklus 2 bei Abruf- und Speicheroperation, wobei bedeutet:
aaa... Adresse des ersten (links außen) stehenden Byte im Datenfeld
A: 1 = Adressenprüfung
B: 1 = Puffer nicht frei
c: 1 für Kundenspeicher-(165)-Zugriff, 0 für Mikrocodebereich-Zugriff (IOA 187)
ddd.. 4 Bytes Daten zum/vom Speicher
fff.. Feldlänge minus 1 in Bytes (0..63 dezimal)
kkkk Speicherschlüssel (0..15 dezimal)
K 1 = Schlüsselprüfung
ooooo: Offset innerhalb des 32 Byte Mailboxbereichs
pp Priorität (0..3, 3 ist die höchste)
... nicht zu beachten
///: Bus ist veränderlich (nicht definiert) in einwärts (BCU zu Puffer)
out auswärts (Puffer zu BCU)
Die folgenden Tag-Leitungen (Kennzeichnung) werden bei den Datenübertragungs-Operationen benutzt:
1. PU-to-BCU-Request-Leitung 256a vom Bus-Adapter 154 zur BCU 156 wird vom PE85 benutzt, um den Bedarf nach einer E/A- Operation anzumelden. Nach dem Setzen bleibt das Signal aktiv, bis es von der BCU 156 rückgestellt wird.
2. Tag-Up-Leitung 262a von der BCU 156 zum Adapter 154 wird benutzt, um ausgehende Daten vom Adapter 154 abzurufen oder um anzuzeigen, daß auf dem Bus Eingangsdaten stehen. Die Tag-Up-Leitung 262c arbeitet auf die gleiche Weise.
3. Tag-Down-Leitung 262b vom Adapter 154 zur BCU 156 wird benutzt, um anzuzeigen, daß zeitweilig keine Daten zur BCU 156 gesendet werden, wenn diese Situation vorkommt. Die abfallende Flanke des Tag-Down zeigt dann an, daß ausgehende Daten auf dem Bus stehen. Tag-Down-Leitung 262d arbeitet auf die gleiche Weise.
4. BCU-to-PU-Acknowledge-Leitung 256b von der BCU 156 zum Adapter 154 wird benutzt zum Rücksetzen des PU-to-BCU- Request-Signals. Dieser Reset wird ausgeführt, wenn eine E/A-Mailbox-Operation abgeschlossen ist.
Wenn das PE85 eine Start-E/A-Anweisung (Start I/O-510) im Anweisungsstrom entdeckt, alarmiert es das E/A-Teilsystem, d. h. die BCU 156, über den Bedarf nach einer E/A-Operation durch Aktivieren der "PU-to-BCU-Request"-Leitung 256a. Dieses Kennzeichnen bewirkt, daß die BCU 156 in die "Mailbox" 188 im Speicher 162 schaut, um herauszufinden, ob diese Operation eine Abruf- oder eine Speicheroperation ist, wie viele Bytes übertragen werden müssen, usw. Die Mailbox enthält die Kanal- SIO, CUA, CAW und das Befehlswort (CCW) der einschlägigen E/A-Operation.
Speicheroperationen sind im allgemeinen solche, in denen die BCU 156 Daten an das PE85 schickt. Diese "Daten" sind entweder Befehl/Schlüssel/Adresse, die im Anwahlzyklus gesendet werden, oder die "realen" E/A-Daten, die im Hauptspeicher 162 abgespeichert werden müssen. In beiden Fällen ist die Reihenfolge der Ereignisse die gleiche.
Die Fig. 15A-C zeigen in verallgemeinernder Diagrammform für die Zwecke der nachstehende Beschreibung die Art und Weise, wie Daten- und Statusinformationen in die und aus den Zwei- unddreißig-Bit-Puffern/Registern im Adapter 154 und in die BCU 156 geschleust werden und wie die höherwertigen (links) und niederwertigen (rechts) Bits der Information auf die Achtzehn-Bit-Kanal-0,1-Busse des Adapters 154 gelegt werden.
Die Fig. 25 und 26 sehen einen spezifischen Signalsatz für Datenübertragungen zwischen der BCU 156 und dem Adapter 154 vor.
Mit Beginn eines BCU-Taktzyklus während einer Speicheroperation, Fig. 15A, legt die BCU 156 die Daten für den ersten Zyklus auf den Bus 251. Wenn das ein Anwahlzyklus für eine Hauptspeicher-Datenoperation ist, wird ein Befehl, eine Byte- Zählung, ein Zugriffsschlüssel und das erste Byte der Hauptspeicheradresse auf den Befehls/Statusbus 252 bzw. auf den Adressen/Datenbus gelegt. Wenn das der Anwahlzyklus für das Nachschauen in der Mailbox ist, wird keine Hauptspeicheradresse aufgelegt, weil der Befehl die Mailbox angibt, die an einem festgelegten Ort steht. Der erste Teilzyklus wird auf dem Bus für zwei Teilzyklustakte gültig gehalten.
Einen BCU-Zyklus nachdem die Daten während eines Anwahlzyklus auf den Bus 251 gelegt wurden, setzt die BCU 156 die "Tag up"-Signalleitung hoch. Die Tag-up Leitung 262a bewirkt, daß der Adapter 154 die ersten zwei Bytes in der linken Hälfte des Registers 113 speichert. Mit dem Anfang des nächsten Taktzyklus legt die BCU 156 die Daten (die zweiten zwei Bytes) für den nächsten Teilzyklus auf den Adressen/Daten-Bus 251 zum Speichern in der anderen Hälfte des Registers 113 Adapters 154. Diese Daten sind entweder der Rest einer Hauptspeicheradresse, oder ein Offset (wenn der Schuß zu einem Mailbox-Nachschauzyklus gehört). Die BCU 156 hält die zweiten zwei Bytes drei BCU-Taktzyklen lang, dann setzt sie das "Tag- up"-Signal tief.
Abrufoperationen sind im allgemeinen solche, in denen die BCU 156 Daten aus dem Hauptspeicher-Datenraum 162, aus dem Mikrocode-Bereich im Hauptspeicher 162, oder aus der Mailbox oder von der Meldungswarteschlange abruft. In jedem dieser Fälle muß ein Anwahlzyklus dieser Abrufoperation vorangehen, um die Logik des Adapters 154 von der Operation, die sie ausführen soll, in Kenntnis zu setzen. Der Anwahlzyklus wird ausgeführt durch Legen des Befehls/Schlüssels/Adresse auf den Bus 249 in einer Art und Weise, die der Speicheroperation über den Bus 252 ähnlich ist, abgesehen davon, daß der Befehl auf dem Befehls/Status-Bus 249 ein "Abrufbefehl" ist.
Mit Anfang des nächsten Taktzyklus (nach Abschluß des Anwahlzyklus) setzt die BCU 156 das "Tag Up"-Signal hoch und hält es drei BCU-Taktzyklen lang hoch (Fig. 15B). Tag up verlangt Daten aus dem Puffer. Die Daten sind einen Zyklus später verfügbar, wenn der Puffer die Daten liefern kann. Da die Operation halbsynchron ist, nimmt die BCU 156 an, daß die ersten zwei Daten-Bytes auf dem Bus zwei Zyklen lang gültig gehalten werden, dann gibt es einen Umschalttakt auf einen Zyklus, und anschließend können die zweiten zwei Daten-Bytes auf die BCU 156 gelegt werden.
Es gibt jedoch Situationen, in denen der Adapter 154 in dem Augenblick, wenn "Tag Up" hoch geht, keine Daten bereit hat.
Das geschieht in der Regel auf einem "Erstdatenabruf" hin, d. h., wenn Daten von einer neuen Adresse abgerufen werden, wobei es eine gewisse Zeit dauert, bis die Abrufanforderung über den Cache-Controller 153 und den Speicher-Controller 155 bearbeitet wird, und dann wieder an den Adapter 154 zurückgeht. Ein neuer Versuch im Hauptspeicher 162 kann ebenfalls eine zeitliche Verzögerung verursachen.
Wenn immer der Adapter 154 Daten nicht liefern kann (Fig. 15C), setzt er die "Tag-Down"-Leitung hoch, sobald "Tag-Up" erfaßt wird. Die BCU 156 muß die "Tag-Down"-Leitung abtasten, und zwar nicht später als fünf Zyklen nachdem sie "Tag-Up" gesetzt hat.
Der Adapter 154 behält "Tag-Down" bei, bis das erste Datenwort (vier Bytes) greifbar ist. In diesem Augenblick legt der Adapter 154 die ersten zwei Bytes auf den Bus 250 und setzt "Tag-Down" tief. Die abfallende Flanke des "Tag-Down"-Signals läßt die Logik der BCU 253 anlaufen.
Die BCU 156 nimmt an, daß die ersten Bytes nach dem Tiefsetzen des "Tag-Down" zwei Zyklen lang gültig sind und danach sind die nächsten zwei Bytes greifbar. In Abhängigkeit von der Zählung, die während des Anwählens des Zyklus eingestellt wird, können bis zu 60 Bytes folgen, jeweils zwei Bytes auf einmal.
Wenn alle Mailboxdaten, die in einem Anwahlzyklus geordnet wurden, eingegangen sind, setzt die BCU 156 das "BCU to PU Acknowledge"-Signal auf Leitung 256b an den Adapter 154 hoch, um den PU-to-BCU-Request auf Leitung 256a, die die Operation eingeleitet hat, rückzustellen.
Die meisten Informationsübertragungen zwischen PE85 und BCU 156 erfolgen über vorgegebene Speicherstellen 188, 189 unter Verwendung der Basisadresse und der Warteschlangenlänge, die im Basisregister 110 im Adapter 154 gespeichert ist. Die Meldungswarteschlange für eingehende Meldungen 189 speichert alle Meldungen, die von der BCU geschickt werden, in chronologischer Reihenfolge.

3. Die Bussteuereinheit 156 - Allgemeine Beschreibung (Fig. 16, 17)

Die Bussteuereinheit (BCU) 156 ist die Hauptankopplungs- Hardware zwischen dem S/370 Prozessor 85 und seinem zugeordneten S/88 Prozessor 62, der zur Durchführung der S/370 E/A- Operationen benutzt wird.
Die BCU 156 beinhaltet Mittel, die mit einem Applikationsprogramm (EXEC370) und einem Mikrocode (ETIO), der auf dem S/88 Prozessor 62 läuft, zusammenwirken, um Interrupts auf den Prozessor 62 zu legen und den Prozessor 62 asynchron vom seiner zugeordneten Hardware ab-, und an die BCU 156 anzukoppeln, die alle für das S/88 Operationssystem transparent sind. Die transparenten Interrupt- und Abkopplungsfunktionen werden benutzt, um das Direktkoppeln der S/370 und S/88 Prozessoren für den effizienten Transfer der S/370 E/A-Befehle und -daten vom S/370 Prozessor 85 auf den S/88 Prozessor 62 zum Umwandeln der Befehle und Daten in eine Form zu ermöglichen, die für den S/88 Prozessor 62 brauchbar ist, damit er die gewünschten S/370 E/A-Operationen durchführt.
Hier sieht man, daß EXEC370 und ETIO beide entweder ein Mikrocode oder ein Applikationsprogramm sein können und entweder im Speicher 174 oder im Cache 173 abgespeichert sind.
Die BCU 156, Fig. 16, beinhaltet Bussteuerungseinheitsschnittstellenlogik und Register 205, einen Direktspeicherzugriffs-Controller (DMAC) 209 und einen örtlichen Speicher 210. Örtliche Adressen- und Datenbusse 247, 223 koppeln den Speicher 210 über Treiber/Empfängerschaltungen 217, 218 an die PE62-Adressen, Datenbusse 161A, 161D und an die Schnittstellenlogik 205. Der DMAC 209 ist über Zwischenspeicher 233 an den Adressenbus 247, und über Treiber/Empfänger 234 an den Datenbus 223 gekoppelt.
Der DMAC 209 der bevorzugten Ausführungsform ist ein 68450 DMA Controller, der nachstehend in weiteren Einzelheiten beschrieben wird.
Der DMAC 209 hat vier Kanäle 0-3, die an die Schnittstellenlogik 205 (Fig. 17) über entsprechende Request- und Achnowledge-Pfade gekoppelt sind, die jeweils einer bestimmten Funktion zugeordnet sind Kanal 0 überträgt S/370 E/A-Befehle aus einem Mailboxbereich 188 (Fig. 28) im S/370 Speicher 162 zum örtlichen Speicher 210 (MAILBOX READ). Kanal 1 überträgt S/370 Daten aus Speicher 162 zum Speicher 210 (S370 I/O WRITE). Kanal 2 überträgt Daten aus Speicher 210 zum Speicher 162 (S/370 I/O Read). Kanal 3 überträgt Hochprioritäts-S/88- Meldungen aus Speicher 210 zu einem Meldungswarteschlangenbereich 189 (Fig. 28) im Speicher 162 (Q Message WRITE).
Der Busadapter 154 hat zwei Kanäle 0 und 1. Adapterkanal 0 behandelt die MAILBOX READ und S/370 I/O WRITE Funktionen der DMAC-Kanäle 0, 1 (d. i. Datenfluß vom S/370 zur BCU 156). Adapter-Kanal 1 behandelt die S/370 I/O READ und Q MESSAGE WRITE Funktionen der DMAC-Kanäle 2, 3 (d.i. Datenfluß von der BCU 156 zum S/370).

4. Direktspeicherzugriffs-Controller 209

Der DMAC 209 ist vorzugsweise von einem Typ (MC68450), der im M68000 Family Reference Manual, FR68K/D, Copyright Motorola, Inc., 1988, beschrieben ist. Der DMAC 209 ist so ausgelegt, daß er die Leistungen und Architekturmöglichkeiten der Motorola Mikroprozessoren der M68000-Familie (wie z. B. das M68020 Prozessorelement 62 der vorliegenden Applikation) komplet tiert durch Bewegen von Datenblöcken auf schnelle, effiziente Weise mit minimalem Eingriff von einem Prozessor. Der DMAC 209 führt Speicher-zu-Speicher-, Speicher-zu-Vorrichtung-, und Vorrichtung-zu-Speicher-Datenübertragungen durch.
Er beinhaltet vier unabhängige DMA-Kanäle mit programmierbarer Priorität und benutzt die asynchrone M68000 Bus-Struktur mit einem 24-Bit-Adressenbus und einem 16-Bit-Datenbus. Er kann explizit oder implizit adressiert werden.
Der Hauptzweck eines DMAC, wie der 209, in einem System ist die Übertragung von Daten mit hoher Geschwindigkeit, üblicherweise viel schneller, als sie ein Mikroprozessor unter Software-Steuerung handhaben kann. Der Ausdruck Direktspeicherzugriff (DMA) wird benutzt, um die Fähigkeit einer Peripherievorrichtung anzusprechen, in einem System wie ein Mikroprozessor auf einen Speicher zuzugreifen. Der Speicher in der vorliegenden Applikation ist der örtliche Speicher 210. Der DMA-Betrieb kann gleichzeitig mit anderen Operationen stattfinden, die der Systemprozessor durchführen muß, wodurch die allgemeine Systemleistung stark erhöht wird.
Der DMAC 209 bewegt Datenblöcke mit Geschwindigkeiten, die an die Grenzen des örtlichen Busses 223 heranreichen. Ein Datenblock besteht aus einer Byte-Folge, Wort- oder Langwort- Operanden, anfangend mit einer spezifischen Speicheradresse, wobei die Länge des Blocks bestimmt wird durch eine Transfer- Zählung. Eine einzige Kanaloperation kann die Übertragung mehrerer Datenblöcke zum oder vom Speicher 210 beinhalten.
Jede Operation, die den DMAC 209 betrifft, folgt den gleichen grundlegenden Schritten: Kanalinitialisierung durch das PE62, Datenübertragung und Blockbeendigung. In der Initialisierungsphase lädt der Prozessor PE62 die Register des DMAC mit Steuerinformationen, Adressenzeigern und Transfer-Zählungen und läßt dann den Kanal anlaufen. Während der Übertragungsphase akzeptiert der DMAC 209 Anforderungen auf Operandenübertragungen und sieht Adressierungs- und Bus-Steuerung für die Übertragungen vor. Die Beendigungsphase läuft nach Abschluß der Operation, wenn der DMAC den Status der Operation im Statusregister CSR anzeigt. Während aller Phasen einer Datenübertragungsoperation ist der DMAC 209 in einer von drei Betriebs-Modi:
1. LEERLAUF - Das ist der Zustand, den der DMAC 209 annimmt, wenn er von einer externen Vorrichtung rückgestellt wird und auf die Initialisierung durch den Systemprozessor 62 oder auf eine Operandenübertragunsanforderung von einem Peripheriegerät wartet.
2. MPU - Das ist der Zustand, in den der DMAC 209 eintritt, wenn er vom Chip eines anderen Bus-Masters im System angesteuert wird (in der Regel vom Hauptsystemprozessor 62). In diesem Modus wird auf die internen Register des DMAC geschrieben bzw. von ihnen gelesen, um den Kanalbetrieb zu steuern oder den Status einer Blockübertragung zu überprüfen.
3. DMA - Das ist der Zustand, in den der DMAC 209 eintritt, wenn er als Bus-Master handelt, um einen Operanden- Transfer durchzuführen.
Der DMAC kann implizite oder explizite Adreßdatenübertragungen durchführen. Für explizite Übertragungen werden Daten von einer Quelle auf ein internes DMAC-Halteregister übertragen und dann im nächsten Bus-Zyklus werden sie vom Halteregister zum Ziel befördert. Implizite Übertragungen erfordern nur einen einzigen Bus-Zyklus, weil die Daten ohne internes DMAC-Puffern direkt von der Quelle zum Ziel befördert werden.
Es gibt drei Typen von Kanaloperationen: 1) Einzelblock- Übertragungen, 2) kontinuierliche Operationen, und 3) verkettete Operationen. Beim Einzel-Datenblock-Übertragen werden die Speicheradressen- und Vorrichtungsadressenregister MAR bzw. DAR vom Anwender initialisiert, um die Quelle und das Ziel der Datenübertragung zu spezifizieren. Ebenso wird das Speicherübertragungs-Zählregister initialisiert, um die Anzahl der in einem Block übertragenen Operanden zu zählen.
Die zwei Verkettungs-Modi sind Matrixverkettung und verbundene Matrixverkettung. Der Martrixverkettungs-Modus arbeitet von einer kontinuierlichen Matrix im Speicher 210 aus, bestehend aus Speicheradressen und Übertragungszählungen. Das Basisadressenregister BAR und das Basisübertragungs-Zählregister BTC werden initialisiert, um auf die Anfangsadresse der Matrix bzw. auf die Anzahl der Matrixeinträge zu zeigen. Mit Abschluß jeder Blockübertragung wird der nächste Eintrag aus der Matrix geholt, der Basisübertragungszähler wird dekrementiert, und die Basisadresse wird inkrementiert, um auf den nächsten Matrixeintrag zu zeigen. Wenn der Basisübertragungszähler Null erreicht, ist der eben abgerufene Eintrag der letzte in der Matrix definierte Blocktransfer.
Der verbundene Matrixverkettungs-Modus ist ähnlich dem Matrixverkettungs-Modus, mit dem Unterschied, daß jeder Eintrag in die Speichermatrix auch eine Verbindungsadresse enthält, die auf den nächsten Eintrag in der Matrix zeigt. Das ermöglicht eine nichtkontinuierliche Speichermatrix. Der letzte Eintrag enthält eine Verbindungsadresse, die auf Null gesetzt ist. Das Basiszählregister BTC wird in diesem Modus nicht benötigt. Das Basisadressenregister BAR wird auf die Adresse des ersten Matrixeintrags initialisiert. Die Verbindungsadresse wird benutzt, um das Basisadressenregister zu Beginn jedes Blocktransfers zu aktualisieren. Dieser Verkettungs- Modus ermöglicht, daß Matrixeinträge leicht verschoben und eingefügt werden, ohne die Matrix in eine aufeinanderfolgende Ordnung umorganisieren zu müssen. Auch braucht die Anzahl der Einträge in der Matrix dem DMAC 209 nicht angegeben zu werden. Dieser Adressierungs-Modus wird vom DMAC 209 der vorliegenden Applikation benutzt, um auf freie Arbeitswarteschlangenblöcke (WQB) aus einer Verbindungsgliedliste zugreifen zu müssen, wie später noch beschrieben wird.
Der DMAC 209 unterbricht das PE62 für eine Anzahl Vorkommnisse wie Abschluß einer DMA-Operation oder auf Anforderung einer Vorrichtung, die eine PCL-Leitung 57a-d benutzt. Der DMAC 209 beinhaltet Interrupt-Vektoren in acht chip-integrierten Vektorregistern zur Verwendung in das PE62 vektorierten Interrupt-Struktur. Zwei Vektorregister, ein normaler Interrupt-Vektor (NIV) und ein Fehler-Interrupt-Vektor (EIV) stehen für jeden Kanal zur Verfügung.
Jeder Kanal bekommt eine Prioritätshöhe 0, 1, 2 oder 3 zugeteilt, d. h., den Kanälen 0, 1, 2, 3 werden entsprechend Prioritätshöhen 0, 2, 2, 1 zugeteilt (Prioritätshöhe 0 ist die höchste).
Anforderungen werden extern von einer Vorrichtung generiert, oder intern vom Auto-Request-Mechanismus des DMAC 209. Auto- Requests können generiert werden entweder mit der Maximumrate, wo im Kanal immer eine Anforderung ansteht, oder mit einer begrenzten Rate, die bestimmt wird durch Wählen eines Teils der Bus-Bandbreite, die für DMA-Aktivität zur Verfügung steht. Externe Anforderungen können entweder Bündelanforderungen oder Zyklus-Stehl-Anforderungen sein, die vom Anforderungssignal, das jedem Kanal zugeordnet ist, generiert werden.
Der DMAC 209 enthält 17 Register (Fig. 18) für jeden der vier Kanäle plus ein allgemeines Steuerregister GCR, die alle softwaregesteuert sind.
Die DMAC Register beinhalten Informationen Über die Datenübertragungen wie z. B. Quell- und Zieladresse und Funktionscodes, Übertragungszahlung, Operandengröße, Vorrichtungs- Port-Größe, Kanalpriorität, Fortsetzungsadresse und Übertragungszahlung, und die Funktion der Peripheriesteuerleitung. Ein Register CSR liefert auch Status- und Fehlerinformationen Über Kanalaktivitat, Peripherieeingaben und verschiedene Vorkommnisse, die wahrend eines DMA-Transfers aufgetreten sein können. Das allgemeine Steuerregister GCR wählt den Busbenutzungsfaktor, der in Auto-Request-DMA-Operationen mit beschränkter Rate eingesetzt werden muß.
Die Eingangs- und Ausgangssignale sind funktionell in Gruppen organisiert, wie nachstehend beschrieben wird (siehe Fig. 19A).
Der Adressen/Daten-Bus (A8-A23, D0-D15) 248, ein 16-Bit-Bus, ist taktmultiplext, um wahrend des DMA-Betriebsmodus Adressenausgänge zu liefern, und wird als bidirektionaler Datenbus eingesetzt, um Daten von einer externen Vorrichtung (wahrend eines PE62-Schreibens oder DMAC-Lesens) einzugeben, oder um Daten an eine externe Vorrichtung (wahrend eines PE62-Lesens oder DMAC-Schreibens) auszugeben. Das ist ein Dreizustands- Bus und er wird demultiplext unter Verwendung externer Zwischenspeicher und Puffer 233, 234, die von den Multiplex- Steuerleitungen OWN und DDIR gesteuert werden.
Die niedrigen Adreßbusleitungen A1 bis A7 auf dem Bus 247 sind bidirektionale Drei-Zustand-Leitungen und werden benutzt, um die internen DMAC-Register im MPU-Modus anzuspre chen und die niedrigen sieben Adressenausgänge im DMA-Modus zu liefern.
Die Funktionscodeleitungen FC0 bis FC2 sind Dreizustands- Ausgangsleitungen und werden im DMA-Modus benutzt, um den Wert auf dem Adressenbus 247 weiter zu qualifizieren, um gesonderte Adressenstellen vorzusehen, die vom Anwender definiert werden können. Der auf diese Leitungen gelegte Wert wird aus den internen Funktionscoderegistern MFC, DFC, BFC genommen in Abhängigkeit von dem Register, das die während eines DMA-Bus-Zyklus benutzte Adresse liefert.
Asynchrone Bussteuerleitungen steuern asynchrone Datenübertragungen unter Verwendung der folgenden Steuersignale: Adreß-Strobe-Select, Lesen/Schreiben, obere und untere Daten- Strobes, und Datenübertragungs-Acknowledge. Diese Signale werden in den nachstehenden Absätzen beschrieben.
SELECT Eingangsleitung 296 wird benutzt zum Anwählen des DMAC 209 für einen MPU-Bus-Zyklus. Wenn sie angesteuert wird, wählen die Adresse auf A1-A7 und die Daten-Strobes (oder A0, wenn ein 8-Bit-Bus benutzt wird) das interne DMAC-Register an, das mit der Übertragung zu tun hat. SELECT sollte generiert werden durch Qualifizieren eines Adressendecodierungssignals mit dem Adreß- und Daten-Strobe.
ADDRESS STROBE (AS) auf Leitung 270b ist ein bidirektionales Signal, das im DMA-Modus als Ausgang benutzt wird, um anzuzeigen, daß auf dem Adressenbus 161 eine gültige Adresse liegt. Im MPU- oder IDLE-Modus wird er als Eingang benutzt, um festzulegen, wann der DMAC die Bussteuerung übernehmen kann (wenn der DMAC die Busbenutzung angefordert und erhalten hat).
READ/WRITE ist eine bidirektionales Signal (nicht dargestellt) das benutzt wird, um die Richtung eines Datentrans fers während eines Bus-Zyklus anzuzeigen. Im MPU-Modus zeigt ein Hochliegen, daß eine Übertragung vom DMAC 209 zum Datenbus 223 läuft, und ein Tiefliegen zeigt eine Übertragung vom Datenbus zum DMAC 209 an. Im DMA-Modus zeigt ein Hochliegen eine Übertragung vom adressierten Speicher 210 zum Datenbus 223, und ein Tiefliegen zeigt eine Übertragung vom Datenbus 223 zum adressierten Speicher 210 an.
UPPER und LOWER DATA STROBE bidirektionale Leitungen (nicht dargestellt) zeigen an, wenn Daten auf dem Bus gültig sind und welche Busteile an einer Übertragung D8-15 oder D0-7 beteiligt sein müssen.
DATA TRANSFER ACKNOWLEDGE (DTACK) bidirektionale Leitungen 265 werden benutzt zum Signalisieren, daß ein asynchroner Buszyklus beendet werden kann. Im MPU-Modus zeigt dieser Ausgang, daß der DMAC 209 Daten vom PE62 übernommen hat oder Daten auf den Bus für das PE62 gelegt hat. Im DMA-Modus wird dieser Eingang 265 vom DMAC überwacht, um festzustellen, wann ein Buszyklus beendet werden muß. Solange DTACK 265 negiert bleibt, wird der DMAC Wartezyklen in einen Buszyklus einschieben, und wenn DTACK 265 angesteuert wird, wird der Bus- Zyklus beendet (abgesehen davon, wenn PCL 257 als Bereit- Signal verwendet wird, in welchem Fall beide Signale angesteuert werden müssen, bevor der Zyklus beendet wird).
Multiplex-Steuersignale auf den Leitungen OWN und DDIR werden benutzt zum Steuern externer Multiplex/Demultiplex-Vorrichtungen 233, 234, um die Adressen- und Daten-Informationen auf Bus 248 zu trennen und Daten während bestimmter DMAC-Buszyklen zwischen der oberen und der unteren Hälfte des Datenbusses 223 zu übertragen. Die Leitung OWN ist ein Ausgang, der angibt, daß der DMAC 209 den Bus steuert. Sie wird als Aktivierungssignal zum Einschalten der externen Adressentreiber und Steuersignalpuffer benutzt.
BUS REQUEST (BR) Leitung 269 ist eine Ausgang, der vom DMAC angesteuert wird, um die Steuerung des örtlichen Busses 223, 247 anzufordern.
BUS GRANT (BG) Leitung 268 ist ein Eingang, der von einem externen Busverteiler 16 angesteuert wird, um den DMAC 209 zu informieren, daß er die Bus-Herrschaft übernehmen kann, sobald der gerade laufende Buszyklus abgeschlossen ist.
Die beiden Interrupt-Steuersignale IRQ und IACK auf den Leitungen 258a und 258b bilden eine Interrupt- Request/Acknowledge-Handshake-Sequenz mit dem PE62 über die Interrupt-Logik 212. INTERRUPT REQUEST (IRQ) auf Leitung 25% wird als Ausgang vom DMAC 209 angesteuert, um eine Dienstleistung vom PE62 anzufordern. INTERRUPT ACKNOWLEDGE (IACK) auf Leitung 258b wird vom PE62 über die Logik 216 angesteuert, um zu quittieren, daß es einen Interrupt vom DMAC 209 erhalten hat. Als Reaktion auf das Ansteuern des IACK legt der DMAC 209 einen Vektor auf D0-D7 im Bus 223, der vom PE62 benutzt wird, die Adresse der richtigen DMAC-Interrupt- Handhabungsroutine abzurufen.
Die Vorrichtungssteuerleitungen sind die Schnittstelle zwischen dem DMAC 209 und den Vorrichtungen, die an die vier DMAC-Kanäle gekoppelt sind. Vier Sätze zu drei Leitungen sind einem einzigen DMAC-Kanal und seiner zugeordneten Peripherie zugewiesen; die übrigen Leitungen sind globale Signale, in die sich alle Kanäle teilen.
REQUEST (REQ0 bis REQ3) Eingänge auf den Leitungen 263a-d werden von der Logik 253 angesteuert, um einen Operandentransfer zwischen dem Hauptspeicher 162 und dem Speicher 210 anzufordern.
ACKNOWLEDGE (ACK0 bis ACK3) auf den Leitungen 264a-d werden vom DMAC 209 angesteuert, um zu signalisieren, daß ein Ope rand als Reaktion auf eine vorangehende Übertragungsanforderung übertragen wird.
PERIPHERAL CONTROL LINES (PCL0 bis PCL3) 257a-d einschließlich, sind bidirektionale Leitungen zwischen der Schnittstellenlogik 253 und dem DMAC 209, die gesetzt werden, damit sie als Bereit, Abbrechen, Neuladen, Status, Interrupt, oder Aktivieren von Takteingängen oder als Startimpulsausgänge funktionieren.
DATA TRANSFER COMPLETE (DTC) Leitung 267 ist ein Ausgang, der vom DMAC während eines DMAC-Buszyklus angesteuert wird, um anzuzeigen, daß Daten erfolgreich übertragen wurden.
DONE (DONE). Dieses bidirektionale Signal wird vom DMAC 209 oder von der Peripherievorrichtung während eines DMA-Buszyklus angesteuert, um anzuzeigen, daß das gerade übertragene Datum das letzte Element in einem Block ist. Der DMAC wird dieses Signal während eines Buszyklus ansteuern, sobald das Speicherübertragungs-Zählregister auf Null dekrementiert ist.

5. Bussteuereinheit 156 - Detaillierte Beschreibung (Fig. 19A-C, 20)

(a) Schnittstellenregister für Hochgeschwindigkeits-Datenübertragung.

Die BCU Schnittstellenlogik 205 (Fig. 16) wurde zwecks leichterer Darstellung und Beschreibung in den Fig. 19A-C in verschiedene Funktionseinheiten aufgeteilt. So umfaßt die Logik 205 eine Vielzahl von Schnittstellenregistern, die zwecks Erhöhung der Geschwindigkeit und Leistung der Datenübertragungen zwischen dem Adapter 154 und der BCU 156 zwischen den örtlichen Datenbus 223 und die Adapterkanäle 0, 1 gelegt sind. Die Hardwarelogik 253 der Schnittstelle 205 zusammen mit dem DMAC 209, die Adressendecodier- und Verteilungslogik 216 und die Adreß-Strobe-Logik 215 steuern die Operationen der BCU 156.
Die Schnittstellenregister beinhalten ein Kanal 0 Lesestatusregister 229 und ein Kanal 1 Schreibstatusregister 230, gekoppelt an die Kanal 0 und 1 Befehlsstatusbusse 249, 252 zum Halten des Status der Datenübertragungen zwischen dem Adapter 154 und der BCU 156.
Die Kanal 0 und 1 Befehls-Register 214, 225 speichern zeitweilig die Befehle zur Datenübertragung von der BCU 156 zum Adapter 154, S/370, ab.
Die Kanal 0, 1 Adressen/Datenregister 219, 227 halten während der S/370 E/A-Datenübertragungen die S/370 Adresse für die Übertragung zum Adapter 154. Register 227 hält ferner nach jedem Adreßdatentransfer nachgeschaltete E/A-Datenwörter (bis zu 4 Bytes) der Datenübertragungen (bis zu 64 Bytes per Adressenübertragung) zum Adapter 154.
Der Kanal 0 Lesepuffer erhält E/A-Daten, die vom Adapter 154 her während BCU Mailbox Lese- und S/370 E/A-Schreiboperationen übertragen werden.
Kanal 0, 1 BSM Lese/Schreib-Ansteuerungsbytezähler 220, 222 und BSM Lese-Schreib-Grenzenzähler 221, 224 halten Byte- Zählungen zur Datenübertragung von der BCU 156 zum Adapter 154. Beide Zähler sind für jeden Kanal erforderlich, um das Überschreiten der S/370 Vierundsechzig-Byte-Adressengrenze durch Datenübertragungen zu vermeiden. Wie später in weiteren Einzelheiten beschrieben wird, speichern die Zähler 220, 222 anfänglich die gesamte Byte-Zählung zum Übertragen für eine E/A-Operation (bis zu 4 kE), und werden zum Übertragen der Zählwerte an die Register 214, 225 benutzt, um teilweise eine S/370 Anfangsadresse nur für die letzen Blockübertragung (64 Bytes) zu bilden, d. h. die letzte Befehls/Daten-Übertragungs operation. Die Grenzenzähler 221, 224 werden benutzt, um (teilweise) eine Anfangsadresse S/370 vorzubringen, wenn von der BCU 156 für jede einzelne Befehlsdatenübertragungsoperation eine Grenzüberschreitung entdeckt wird oder wenn die Byte-Zählung größer wird als 64 Bytes.
Die Zähler 220, 221, 222 und 224 werden nach jeder Datenübertragung über die Kanäle 0 oder 1 auf geeignete Weise dekrementiert.
Ein Warteschlangenzähler 254 sieht eine ähnliche Funktion für Meldungsübertragungen (bis zu 16 Bytes) an den S/370 Speicher über den Adapter 154 vor.
Die Adressen zur Anwahl der obigen Schnittstellenregister sind im Speicher 210 Adressenraum, Fig. 23C, und werden angewählt durch Decodierung der Adresse auf Bus 247 auf bekannte Art und Weise.
Ein Signal auf der PU-an-BCU Anforderungsleitung 256a vom Adapter 154 zur Logik 253 meldet der BCU 156, daß eine S/370 Leseanforderung bereit ist. Dieses Signal wird erst dann von einem BCU PU Acknowledge-Signal auf Leitung 256b rückgestellt, wenn die Mailbox-Information im örtlichen Speicher 210 abgespeichert ist.
Tag-up und Tag-down Leitungen 262a-d werden benutzt zum Eintakten von Daten zwischen der BCU 156 und dem Adapter 154 über die Adapter-Kanäle 0, 1.
Zwischen der BCU-Logik 253 und dem DMAC 209 sind Handshake- Signale vorgesehen. Die BCU-Logik legt Dienstleistungsanforderungen auf die Leitungen 263a-d, jeweils eine für jeden DMAC-Kanal. Der DMAC antwortet mit Acknowledge-Signalen auf den Leitungen 264a-d. Andere Leitungen wie Anwahl 270, Datenübertragungs-Acknowledge 265, Peripheriesteuerleitungen 257a-d, Datenübertragung-komplett 267 wurden oben im Hinblick auf DMAC 209 bereits beschrieben.

(b) BCU Abkopplungs- und Interrupt-Logik 215, 216 (Fig. 20, 21)

Bereits früher wurde gesagt, daß zwei Merkmale für das Erreichen des engen Koppelns der S/370 und S/88 Prozessoren kritisch sind, um für das S/370 System viele der eindeutigen Charakteristiken des S/88-Systems, wie z. B. fehlertoleranter Betrieb und Einzelsystembild-Umgebung, vorzusehen. Diese Merkmale werden hier als "Abkoppeln" des S/88 Prozessors von seiner ihm zugeordneten Hardware und als "eindeutiger Interupt"-Mechanismus bezeichnet. Beide Merkmale arbeiten auf eine Weise, die für das S/88 Betriebssystem transparent ist. Die Abkopplungs- und die Interruptlogik 215, 216 sind in der BCU 156 vorgesehen.
Die "Abkopplungs"-Logik decodiert die virtuelle Adresse, die während jedes Anweisungsausführungszyklus auf den S/88 Prozessoradressenbus 161A gelegt wird. Wenn eine der vorgewählten virtuellen S/88-Adressen im Block, die der BCU 156 und ihrem Speicher 210 zugeordnet sind, erfaßt wird, wird das Adreß-Strobe-(AS)-Signal vom S/88 Prozessor 62 in die BCU 156 eingespeist anstatt in die zugeordnete S/88 Hardware. Diese Aktion verhindert daß das S/88 Betriebssystem und die Hardware weiß, daß ein Maschinenzyklus abgelaufen ist, d. h., die Aktion ist für das S/88 transparent.
Der S/88 Prozessor 62 ist jedoch so gekoppelt, daß er die BCU 156 während dieses Maschinenzyklus steuert, wobei das AS- Signal und die vorgewählte Adresse dazu benutzt wird, verschiedene Komponenten in der BCU 156 anzuwählen und zu steuern, um eine Funktion auszuführen, die mit den S/370 E/A- Operationen zu tun hat.
Ein besonderer Applikationscode (EXEC370), der auf dem S/88 Prozessor 62 läuft, beginnt die Kommunikation mit dem S/370 Prozessor 85 durch Legen dieser vorgewählten virtuellen Adressen auf den S/88 Bus 161A, um die BCU 156 anzuweisen, Operationen zum Bewirken dieser Kommunikation durchzuführen.
Der DMAC 209 und weitere Logik in der BCU 156 schicken Interrupts auf einer vorgegebenen Ebene (6) zum S/88 durch Aktivieren dieses besonderen Applikationscode, falls erforderlich. Das Schicken der einzelnen Interrupts ist für das S/88 Betriebssystem transparent.
Eine Kurzbeschreibung der Funktionstypen, die von ein paar der Interruptbehandlungsroutinen als Reaktion auf diese Interrupts vorgenommen werden, wird später noch anhand eines Beispiels in einer Firmware-Übersicht der S/370 E/A-Operationen gegeben.
Die Mechanismus- und S/88 Betriebssystemveränderungen zum Behandeln der S/370 Interrupts zum S/88 über DMACs wie z. B. 209, sowohl auf der Basis der Partnerschaftseinheiten als auch in einem Modul mit mehreren Partnerschaftseinheiten sollen jetzt beschrieben werden.
Wie man sich erinnert, ist eine Partnereinheit eine verbundene Sandwichstruktur eines modifizierten Dual-S/88-Prozessorboards mit einem Dual-S/370-Prozessorboard, das duale örtliche Speicher, DMACs und Kundenlogik enthält. Die jeweils gleichen Elemente dieses dualen Sandwichboards arbeiten parallel, in voller Synchronisation (schrittsynchronverriegelt) aus Gründen der Fehlererkennung.
Dieses gesamte Sandwich hat in der Regel ein identisches Partnersandwich, und die Partner laufen schrittsynchronverriegelt und erscheinen so als einzige, fehlertolerante Einheit. Für die folgende Diskussion genügt es, diese doppelt replizierte Betriebseinheit als einzige Betriebseinheit anzusehen, wie sie in Fig. 21 gezeigt wird.
In einer bevorzugten Ausführungsform können bis zu acht dieser Betriebseinheiten 295 bis 295-8 in einem einzigen Modulgehäuse sitzen und Hauptspeicher, E/A-Geräte und Stromversorgung gemeinsam nutzen unter der Steuerung einer einzigen Kopie des S/88 Betriebssystems. Die Einheit 295 (und jede weitere Einheit 295-2 bis 295-8) entspricht einem Paar Partnerboards, wie z. B. den Boards 21, 23 in Fig. 7. In dieser multiplen CPU-Konfiguration arbeiten auf bedeutsame Weise die S/88 Prozessoreinheiten 62 bis 62-8 als Mehrfachprozessoren und teilen sich die S/88 Arbeitslast, aber die S/370 Einheiten 85 bis 85-8 arbeiten getrennt und unabhängig und kommunizieren nicht miteinander. Jede S/370-Einheit läuft unter der Steuerung ihres eigenen Betriebssystems und hat keine 'Kenntnis' von einer anderen CPU im Gehäuse (sei es S/370 oder S/88).
Infolge der Mehrfach-Prozessor-Umgebung und der S/88 Architektur wird das Behandeln der Interrupts im normalen S/88- System unter die CPU-Einheiten 62 bis 62-8 aufgeteilt. In einer vereinfachten Ansicht wird jeder Interrupt (vom E/A, Taktgebern, Programmfallen, usw.) auf den gemeinsamen Bus 30 parallel an alle S/88 Prozessoreinheiten geschickt; eine Einheit übernimmt die Verantwortung für seine Bedienung und bewirkt, daß ihn die anderen Einheiten ignorieren. Unabhängig davon, welche die bedienende CPU-Einheit ist, gibt es eine einzige Vektortabelle, einen einzigen Eintragspunkt (je Vektor) innerhalb des Betriebssystems für den Bearbeitungscode, und die Erledigung des Interrupts wird vom (einzigen) Betriebssystem entschieden und behandelt.
In einer multiplen S/370 Konfiguration arbeiten alle normalen S/88 Interrupts wie oben beschrieben; kein S/88 Interrupt bearbeitungscode wird geändert. Kleinere Hardwareänderungen, um dem DMAC 209 bis 209-8 die Interruptausgabe zu erlauben, sind für den normalen S/88 Interruptmechanismus und zugeordnete Software voll transparent.
Dabei besteht die Forderung, daß ein DMAC-Interrupt nur von dem S/88 Prozessor 62 behandelt werden darf, an den der DMAC, die BCU und S/370 angeschlossen ist, so daß die multiplen S/370-Einheiten 85 bis 85-8 sich untereinander nicht stören können. Zu diesem Zweck wird die DMAC IRQ Leitung 258a direkt an den S/88 Prozessor 62 gelegt, an den der DMAC 209 angehängt ist, und tritt nicht im gemeinsamen S/88 Bus 30 auf, wie die normalen S/88 Interrupt-Request-Leitungen. Während der Zeitabschnitte, die vom S/88 für die S/370 Unterstützung übernommen wurden, ist ein gegebener S/88 Prozessor dem S/370 fest zugeordnet, mit dem er direkt verbunden ist.
Acht Anwendervektorstellen in der S/88 Hauptvektortabelle sind für die Anwendung durch die DMACs reserviert, und diese Vektoren sind hartcodierte Adressen von acht DMAC-Interruptbehandlern, die am S/88 Betriebssystem angeschlossen sind. Diese acht Interruptbehandler werden von allem S/88 Prozessoren benutzt, um die Interrupts zu bearbeiten, die für die zugeordneten S/370 Prozessoren von allen DMACs geschickt werden.
Jeder DMAC, wie z. B. der 209, hat ein einziges Interrupt- Request-(IRQ)-Ausgangssignal und acht interne Vektorregister (zwei je Kanal, jeweils eines für normale Operationen und für DMAC-erfaßte Fehler). Beim Initialisieren (wie später beschrieben) werden diese DMAC-Vektorregisterwerte so programmiert, daß sie den acht obengenannten reservierten Hauptvektortabellenstellen entsprechen. Somit kann ein DMAC eine von acht Bearbeitungsroutinen anfordern, wenn er einen IRQ schickt. Diese Bearbeitungen greifen auf DMAC, BCU-Hardware, Warteschlangen, Verbindungsgliedlisten und alle Steuerparameter zu durch Angeben virtueller Adressen, die im Adressenbereich des 'verborgenen' örtlichen Speichers 210 liegen. Die Hardwarekonstruktion stellt sicher, daß jeder S/88 Prozessor, z. B. 62, auf seinen eigenen Speicher, z. B. 210, zugreifen kann und auf keinen anderen, auch wenn ein gemeinsames, virtuelles-Adressen-abkoppelndes 'Fenster' unter multiplen S/370 Einheiten geteilt wird. Das heißt, der S/88 virtuelle Adressenraum 007EXXXX wird von allen S/88-S/370 Multiprozessoren in einem Modul benutzt, auch wenn jede Partnereinheit, wie 21, 23, ihren ihr zugewiesenen S/88 physikalischen Speicher aufweist, wie in Fig. 10 gezeigt wird.
In den multiplen S/370-Konfigurationen sind alle DMACs 209 bis 209-8 identisch programmiert soweit diese acht Vektorregister betroffen sind, und alle teilen sich in die acht reservierten Vektoren in der Hauptvektortabelle, sowie auch in die Bearbeitungsprogrammroutinen. Die Differenzierung sowie das Abkoppeln tritt bei jedem Zugriff auf den Speicher, z. B. 210, ein.
Das Schicken des DMAC IRQ an seinen eigenen S/88 Prozessor 62 über die Hartverdrahtung, zusammen mit dem Abkoppeln, sichert die Trennung und die Integrität der S/370 Prozessoreinheiten und die Störfreiheit mit dem S/88 Normalbetrieb. Abgesehen von der 'verlorenen' S/88 CPU-Zeit ist das Bedienen dieser Interrupts transparent für das S/88 Betriebssystem.
Die komplette Interrupt-Konstruktion bewirkt somit eine intermittierende 'Zuordnung auf Anforderung'-Bedienung der S/370 DMAC-Interrupts, mit Isolierung und Schutz für multiple S/370 Einheiten, durch Übernehmen individueller Prozessorvorrichtungen aus einer Multiprozessorsystemumgebung, die eine andere Interrupt-Behandlungsphilosophie benutzt, mit im wesentlichen keiner Auswirkung auf die Multiprozessorsystem operation und ohne bedeutsame Veränderungen im Multiprozessor-Betriebssystem.
Für eine stärker detaillierte Operation jedes DMAC-Interrupt- Mechanismus wird die Aufmerksamkeit auf die Fig. 19A und 20 gelenkt. Wenn eine Peripherievorrichtung, wie der DMAC 209, der mit Anwahlvektoren arbeitet, eine Interrupt-Anforderung (IRQ) an den S/88 Prozessor 62 richtet, wird eine einzige IRQ-Leitung 258a von der Vorrichtung aktiviert. Diese IRQ- Leitung wird auf eine Weise, die von der S/88 Prozessor- Architektur spezifiziert wird, an eine Codierschaltung 293 angeschlossen, um über Eingabekontaktstifte IPL0-IPL2 eine codierte Interrupt-Anforderung auf einer spezifischen Prioritätshöhe 6 an den S/88 Prozessor 62 zu legen.
Der Prozessor 62 entscheidet effektiv, wann er den Interrupt bedienen kann, unter Verwendung von Prioritätsmaskierungs- Bits, die im internen Statusregister gespeichert sind. Sobald der Prozessor 62 bereit ist, läßt er einen besonderen 'Interrupt Acknowledge' (IACK) Zyklus anlaufen.
Im IACK-Zyklus, der intern vom Prozessor 62 gesteuert wird, wird eine eindeutige Adressenkonfiguration auf den Adressenbus 161A gelegt, um den Zyklustyp und die Prioritätshöhe, die gerade bearbeitet werden, zu identifizieren. Das bedeutet effektiv auch eine Anforderung einer Vektornummer von der unterbrechenden Vorrichtung. Alle anfordernden Vorrichtungen vergleichen die gerade bediente Prioritätshöhe mit ihrer eigenen, und die Vorrichtung mit übereinstimmender Priorität legt eine Ein-Byte-Vektornummer auf den Datenbus 161D, damit sie der Prozessor 62 liest.
Sobald die Vektornummer eingeht, legt der Prozessor 62 den internen Grundstatus auf einen Supervisor-Stapel und generiert dann die Adresse des zu benutzenden Ablaufunterbre chungsvektors. Das geschieht durch internes Multiplizieren der Vorrichtungsvektornummer mit vier und Addieren dieses Ergebnisses zum Inhalt des internen Vektor-Basisregisters, was die Speicheradresse des Ablaufunterbrechungsvektors ergibt. Dieser Vektor ist der neue Programm-Zählwert für den Interrupt-Bearbeitungscode.
Unter Benutzung dieses neuen Programmzählwerts wird die erste Anweisung abgerufen und die normale Anweisungsdecodierung und -ausführung wird im Überwachungszustand wieder aufgenommen, wobei das Prozessor-62-Statusregister auf die jetzt gültige Prioritätshöhe gesetzt wird.
Die obigen Schritte, vom Anlaufen des IACK-Zyklus bis zum Abrufen der ersten Interrupt-Bearbeitungsprogramm-Anweisung, werden durch eine Kombination von Hardware- und Prozessor-62- internen Operationen gemacht und erfordern keine Programmanweisungsausführung. Der Nettoeffekt ist ein transparentes Vorbelegen des vorher ablaufenden Programms (geringere Priorität), um die Interrupt-Bearbeitung mit höherer Priorität auszuführen.
Die DMAC-209-Interrupts in der bevorzugten Ausführungsform sind auf Prioritätshöhe sechs geschaltet und sind absolut konform mit der Architektur des Prozessors 62. Der DMAC 209 hat acht Vektornummern intern programmiert und acht gesonderte Bearbeitungsroutinen werden benutzt.
Die Decodier- und Prioritätsverteilungslogik 216 (Fig. 19A) und AS-Steuerlogik 215 steuern diese Interruptfunktion während des IACK-Zyklus zusätzlich zum Vorsehen der Abkopplungsfunktion des S/88 Prozessors 62.
Jetzt sollen diese beiden detaillierten Hardware-Funktionen anhand der Fig. 20 beschrieben werden, die Einzelheiten der Logik 215 und 216 der Fig. 19A zeigt. Die Adreß-Strobe- Leitung 270 vom PE62 ist an einen Eingang der Steuerlogik 215 gekoppelt. Die Logik 216 weist ein Paar Decodierschaltungen 280, 281 auf. Der Ausgang 282 der Schaltung 280 ist an die Logik 215 gekoppelt; der Ausgang 283 der Schaltung 281 ist auch über das UND-Gatter 291 und die Leitung 287 an die Logik 215 gekoppelt. Im Normalfall ermöglichen während der Befehlsabarbeitung die Decodierschaltungen 280, 281, daß das Adreß- Strobe-Signal (AS) auf Leitung 270 durch die Logik 215 zur Leitung 270a läuft, die das normale Adreß-Strobe zur S/88 Hardware ist, die dem PE62 zugeordnet ist.
Wenn jedoch eine vom S/88 Prozessor 62 ausgeführte Anweisung eine virtuelle Adresse auf den Adressenbus 161A legt, deren vier höherwertige Hex-Stellen gleich "007E" sind (was auf das Abkoppeln des PE62 von seiner S/88 Hardware und Ankoppeln des PE62 and die BCU 156 für eine Funktion hinweist, die mit einer S/370 E/A-Operation in Beziehung steht), legt die Decodierlogik 280 ein Signal auf Leitung 282, um das AS-Signal auf der Leitung 270a zu blockieren, und sendet das AS über die Leitung 270b an die BCU 156. Die Decodierlogik 280 kann auch ausgelegt sein, um einen geeigneten Funktionscode auf den Leitungen FC0-2 zu erfassen; das ist jedoch nur eine Konstruktionsfrage. Die Fig. 22, 23 und 24 zeigen die Verzögerung zwischen den Adressensignalen auf dem Bus 161A und dem Adreß-Strobe auf Leitung 270, die das Blockieren des AS auf der Leitung 270a vor dem Zeitpunkt ermöglicht, an dem das AS- Signal hochgesetzt wird. Man sieht hier, daß auch andere Mittel als eine spezielle Gruppe von virtuellen S/88 Adressen, die auf den Adressenbus gelegt werden, zum Decodieren einer Bedingung benutzt werden können, die das Abkoppeln des PE62 von seiner zugeordneten Hardware und das Ankoppeln das PE62 an die BCU 156 anzeigt.
Das Blockiersignal auf Leitung 282 wird an die ODER-Schaltung 284 gelegt, um ein Anforderungssignal für den örtlichen PE62- Bus auf die Leitung 190 zur Verteilerlogik 285 zu legen. Die Logik 285 wird die Zulassung der Anforderung an das PE62 nur dann gewähren, wenn der DMAC 209 noch keine Anforderung auf die Leitung 269 gelegt hat. Die PE62-Buszulassungsleitung 191 wird aktiviert, wenn keine DMAC Anforderung vorliegt. Das PE62-Buszulassungssignal auf Leitung 191 setzt die ENABLE Leitungen 286a, b (Fig. 19A) über die Logik 253 hoch, um die PE62 Busse 161A, D über die Treiber 217 und Treiber/Empfänger 218 als Vorbereitung für eine PE62 Operation mit der BCU 156 an die örtlichen Busse 247, 223 anzukoppeln. Daten und Befehle können unter der Steuerung der Anweisungen, die vom PE62 ausgeführt werden zwischen dem PE62 und Elementen der BCU übertragen werden während die Prozessorbusse 161A, D an die örtlichen Busse 247, 223 gekoppelt sind. Das Applikationsprogramm EXEC370 und die ETIO-Firmware enthalten solche Anweisungen.
Wenn eine DMAC-Anforderung auf der Leitung 269 liegt, gibt die Logik 285 dem DMAC 209 Priorität über die PE62- Anforderung auf Leitung 190; das DMAC-Bus-Zulassungssignal auf Leitung 268 wird an den DMAC 209 zurückgegeben; und der örtliche Bus 247, 223 wird als Vorbereitung für eine DMAC Operation mit der BCU 156 entweder zwischen den örtlichen Speicher 210 und die Adapterkanäle 0, 1 über die Hochgeschwindigkeits-Schnittstellenregister, oder zwischen den DMAC 209 und den örtlichen Speicher 210 geschaltet.
Man sieht also, daß die Logik 215, 216 den A/88 Prozessor 62 von der zugeordneten Hardware (z. B. 175, 176, 177) abkoppelt und an die BCU 156 ankoppelt, wenn eine Adresse 007EXXXX von der Logik 280 decodiert wird. Dieses Abkoppeln ist für das S/88 Betriebssystem transparent.
Auf ähnliche Weise blockiert die Decodierlogik 281 (und die zugeordnete Hardware) den Adreß-Strobe AS von der Leitung 270a und läßt während einer DMAC 209 Interruptsequenz eine örtliche Bus-Anforderung an die Verteilerlogik 285 anlaufen.
Genauer gesagt, wenn der DMAC 209 ein Interruptsignal auf die Leitung 258a legt, wird es über die ODER-Schaltungen 292a und 292, den Höhe-6-Eingang der S/88 Interrupt-Prioritätslogik 293 und die Leitungen IPL0-2 an das PE62 gelegt. Das PE62 antwortet mit einem Interrupt-Acknowledge-Zyklus. Vorgegebene logische Bits (einschließlich des Werts der Interrupthöhe) werden auf den Ausgang FC0-2 und den Adressenbus 161A (Bits A1-3, A16-19) gelegt, wobei die Bits von der Logik 281 codiert werden, um einen Ausgang auf die Leitung 283 zu legen. Dieser Ausgang und das Interruptsignal auf Leitung 258c bewirken, daß das UND-Gatter 291 ein Signal auf die Leitung 287 legt und damit bewirkt, daß die Logik 215 das AS über die Leitung 270b auf die BCU Logik 253 legt.
Das Signal auf der Leitung 287 blockiert das AS von der Leitung 270a und legt über eine ODER-Schaltung 284 eine PE62 Busanforderung auf die Leitung 190 zur Verteilerlogik 285. Weil das Adreß-Strobe (AS) Signal blockiert wird und so nicht zur S/88 Hardware gelangt, ist dieser Interrupt für das S/88 Betriebssystem transparent.
Sobald die speziellen IACK-Bits auf Bus 161A und FC0-2 eingehen wie oben beschrieben ist, erzeugt die Decodierlogik 281 ein Ausgangssignal auf Leitung 283, um das Addreß-Strobe- Signal auf Leitung 270a zu blockieren und eine PE62 Anforderung über die ODER-Schaltung 284 und Leitung 190 an die Verteilerlogik 285 zu schicken. Wenn es auf Leitung 269 keine DMAC-Anforderung gibt, wird das PEE2 Busfreigabesignal auf der Leitung 191 zum UND-Gatter 294-1 hochgesetzt. Das UND- Gatter 294 erzeugt ein IACK-Signal auf der Leitung 258b an den DMAC 209. Das alarmiert den DMAC 209, seinen Interruptvektor auszusenden. Der DMAC legt dann den Vektor auf den örtlichen Bus und setzt 'DTACK' auf Leitung 265 zur Logik 253 hoch. Die Logik 253 setzt als Reaktion auf das AS-Signal auf Leitung 270b die ENABLE-Signale auf den Leitungen 286a, 286b hoch, um die Prozessorbusse 161A und D über die Schaltungen 217, 218 an die örtlichen Busse 248 und 223 zu koppeln, um den richtigen Vektor vom DMAC 209 in das PE62 einzulesen. Der DMAC 209 legt Interrupt-Vektoren vom niedrigstwertigen Byte seines Datenbusses 248 (Fig. 19A) auf den S/88 Prozessor- Datenbus 161D, Bits 23-16, über den Treiber/Empfänger 234, und die Bits 23-16 des örtlichen Datenbusses 223.
Die vom DMAC 209 ausgegebene Vektornummer wird vom S/88 Prozessor 62 dazu benutzt, auf eines der acht Interrupt-Bearbeitungsprogramme im S/88 Schnittstellenmikrocode ETIO zu springen.
DTACK auf Leitung 265, und Logik 253 aktiviert DSACK 0, 1 auf den Leitungen 266a, b, um den PE62-Zyklus über ein ODER- Schaltungs-Paar 288 zu beenden. Die Leitungen 266a, b werden mit den Standard-S/88-DSACK-Leitungen 266c, d ODER-verbunden, um die letztendlichen DSACK-Eingänge 266e, f zum PE62 zu bilden.
Interrupt Requests, die über die Leitungen 562, 563 von der integrierten Dienstleistungsvorrichtung (Fig. 49) an die ODER-Schaltungen 292a gehen, bewirken eine Reihe von Operationen ähnlich denen, die oben im Hinblick auf einen DMAC Interrupt Request beschrieben wurden. Ein Paar UND-Gatter 294-2 und 294-3 (Fig. 20) setzen IACK-Signale auf Leitungen 258d, e hoch, um den Transfer der geeigneten Vektornummern aus der BCU156 auf die S/88 Prozessoreinheit 62 über die Logik 564, 565 der Fig. 49 und den örtlichen Datenbus 223 einzuleiten.
Hier ersieht man, daß dem S/88 Höhe-6-Interrupt-Request Priorität über DMAC- oder BCU-Interrupt-Requests gegeben werden kann (falls sie gleichzeitig auftreten) durch eine kleinere Abänderung der Logikschaltung. In derzeitiger Sicht jedoch ist die Zeit zum Erkennen von Stromausfällen als Sekundär- Interrupt-Quellen mehr als ausreichend.

(c) BCU Adressenabbildung

Der örtliche Speicher 210 (Fig. 41C) hat eine feste Größe und wird auf den S/88 PE62 virtuellen Adressenspeicherraum abgebildet. Der örtliche Speicher 210 unterteilt sich in drei Adressenregister, um drei Zwecke unterscheiden zu können:
1. S/88 PE62 liest/schreibt direkt aus/in die örtlichen Datenpuffer und Steuerstrukturen enschließlich Verbindungsgliedlisten;
2. S/88 PE62 liest/schreibt Befehle, liest den Status aus/in die BCU 156; Befehle von spezifischen Adressen werden decodiert; und
3. S/88 PE62 liest/schreibt DMAC-Register (sowohl zur Initialisierung als auch für den normalen Betrieb); Registernummern von spezifischen Adressen werden decodiert.
Der örtliche Adressenspeicherraum beinhaltet:
1. DATENPUFFER und STEUERSTRUKTUREN (64kBytes weniger 512 beinhalten Verbindungsgliedlisten im physikalischem Speicher (219);
2. BCU BEFEHLSBEREICH (256 Bytes Befehl, decodiert von spezifischer Adresse); und
3. DMAC ZUGRIFFSBEREICH (256 Bytes Registernummer decodiert von spezifischer Adresse).
Die örtliche Adressendecodier- und Busprioritäts-Verteilereinheit 216 erfaßt alle Adressen innerhalb dieses örtlichen Speicherraums. Der DMAC 209 kann gleichzeitig eine Adresse in den obigen Bereich 1 legen. Der DMAC darf die obigen Adressenbereiche 2 oder 3 NICHT ansprechen; das wird gewährleistet durch den Initialisierungs-Mikrocode.
Die BCU 156 überwacht alle Adressen auf dem örtlichen Bus und lenkt über Steuer-Tags Operationen mit Adressen innerhalb der Bereiche 2 und 3 auf die richtige Einheit (BCU oder DMAC) um anstatt auf den örtlichen Speicher 210. Somit wird der Adressenbereich des örtlichen Speichers 210, der von den obigen Bereichen 2 und 3 dargestellt wird, falls vorhanden, nie zur Speicherung benutzt.
In der bevorzugten Ausführungsform wird nach ein vierter Operationstyp über die örtliche Adressendecodierungs- und Busverteilereinheit 215 gehandhabt:
Der S/88 Prozessor 62 quittiert DMAC 209 Interrupts an das S/88 PE62 und schließt jeden Interrupt gemäß der MC 68020 Architektur ab, wie oben beschrieben.
Diese besondere Operation wird erfaßt durch Adressen- und Funktionscode-Bits, die das S/88 PE62 schickt, mit dem Unterschied, daß die (architekturgemäße spezielle) Decodierung keine Adresse im Bereich des örtlichen Speichers 210 ist.
Die örtliche Busverteilereinheit 216 hat daher für diesen Fall einen besonderen Decodierer und eine Hilfslogik, um dem DMAC zu signalisieren, seinen vorprogrammierten Interruptvektor zu schicken. Ansonsten ist die Operation ähnlich dem S/88 Prozessor 62, der ein DMAC-Register liest.
Der Adressenbus 247 wird vom PE62 angewählt, wenn die höherwertigen Stellen mit hexadezimal (H) 007E decodiert werden.
Die restlichen vier Hex-Stellen liefern den örtlichen Speicheradressenbereich von 64kB, die wie folgt zugeteilt werden:
E/A-Vorrichtung Adressen-Decodierung
(oder Befehl)
DMAC register select 007E0000-007E00FF (obiger Bereich 3)
BCU Reset 007E0100 (obiger Bereich 2)
BSM We Sel Up 007E0104 (obiger Bereich 2)
BSM Rd Sel Up 007E0108 (obiger Bereich 2)
Read BCU Status 007E010C (obiger Bereich 2)
local storage select 007E0200-007EFFFF (obiger Bereich 1)
Die folgenden Daten werden vom S/88 Prozessor 62 auf den örtlichen Datenbus 223 gelegt für ein angewähltes DMAC Speichertransfer-Zählregister und für die BCU 156, um in einem nachfolgenden BSM-Lese/Schreib-Anwahlbefehl benutzt zu werden:
Bits 31-16 (0000 Oqbb bbbb bbbb) der Byte-Transfer-Zählung werden in den Transfer-Zähler des DMAC-Speichers gesetzt:
26 = Höherwertiges Byte-Zähl-Bit ( = 1 für max. Bytezählung (nur 4096))
26-16 = Niedrigerwertige Byte-Zähl-Bits. Bits 26-16 stellen 1/4 der wahren Bytezählung dar
(db1Wortübertragungen).
Die BCU 156 erfaßt die Daten für einen anschließenden BSM Read/Write Select Up Befehl wie folgt:
31-27 = Von der BCU ignoriert
26 = Höherwertiges Byte-Zählbit. Dieses Bit ist nur dann 1, wenn die Maximum-Byte-Zählung übertragen wird.
26-14 = Transfer-Byte-Zählbits (max. 4096) an Register 220 oder 222 Adapter erfordern eine Zählung von 1111 1111 1111 um 4096 Bytes zu übertragen (Byte-Zählung 1). Daher dekrementiert die BCU 156 die Doppelwort- Grenzbits 26-16 einmal, bevor sie sie zusammen mit den Byte-Offset-Bits 15-14 (in 64-Byte-Blöcken) auf den Busadapter 154 legt.
15-14 = Niederwertig-Byte-Zählbits. Diese Bits stellen den Byte-Offset minus 1 (für Busadapter-Forderungen) von einer Doppelwortgrenze dar. Diese Bits werden vom DMAC 209 oder von der BCU 156 nicht benutzt, weil sie nur Doppelwörter übertragen. Sie werden in der BCU 156 zwischengespeichert, bis sie auf den Busadapter 154 gelegt werden, um an die S/370 BSM 162 geschickt zu werden.
13-12 = Adapterbuskanal-Priorität an Register 219 oder 227.
11-08 = Speicherschlüssel an Register 219 oder 227.
07 = Kunden/IOA-Raumbit an Register 219 oder 227.
06 = Der S/88-Prozessor aktiviert dieses Bit für BSM Write Select Up, um anzuzeigen, daß ein zusätzlicher Zugriff auf den örtlichen Speicher erforderlich ist. Das geschieht, wenn eine Anfangsadresse des örtlichen Speichers keine Doppelwortgrenze ist. Da alle BCU-Zugriffe mit einer Doppelwortgrenze an fangen müssen, enthält der erste Zugriff das/die Byte(s) an der angegebenen Anfangsadresse sowie auch das/die vorangehenden Byte(s), die in dieser Doppelwortadresse enthalten sind. Das/die vorhergehenden Byte(s) werden nicht berücksichtigt.
05-00 = Reserviert.
Das Folgende wird vom S/88 Prozessor 62 für das DMAC- Speichertransfer-Zählregister, und von der BCU 156 für einen nachfolgenden Q Select Up Befehl auf den örtlichen Datenbus 223 gelegt:
Die Bytetransfer-Zählung, (Bits 31-16) werden in das DMAC- Kanal-3-Speichertransfer-Zählregister MTC gesetzt.
Die BCU 156 erfaßt die Daten für einen anschließenden Q Select Up Befehl wie folgt:
31-20 = Von der BCU ignoriert.
19-16 = Byte-Zählung (max. 64 Bytes) an Register 220 oder 222.
15-12 = Von der BCU ignoriert.
11-08 = Speicherschlüssel an Register 227.
07 = Kunden/IOA-Raumbit an Register 227.
06-00 = Von der BCU ignoriert.

(d) Örtliche Adressen und Datenbus-Operation

Alle örtlichen Busoperationen werden vom S/88 Prozessor 62 oder vom DMAC 209 über Bus-Requests eingeleitet. Örtliche Bus-Operationen des S/88 Prozessors 62 beinhalten:
Örtliche Lese/Schreib-Speicherung (32 Bits)
Lese/Schreib-DMAC-Register (8, 16, 32 Bits)
Interrupt-Acknowledge-Zyklus an DMAC (8-Bit-Interruptvektor gelesen)
Programmierter BCU-Reset
DMAC 209 örtliche Busoperationen beinhalten:
Verbindungsgliedlisten auffüllen (16 Bits)
DMAC-Operationen (32 Bits)
Bringt nur örtliche Speicheradressen
Bringt örtlichen Bus-Request

Interrupts

Liefert normalen Interruptvektor für 4 Kanäle an PE62 (8 Bits)
Liefert Fehlerinterruptvektor für unzulässige DMAC Operationen und weitere erfaßte DMAC-Fehler an PE62 (8 Bits)
Örtliche BCU 156 Bus-Operationen beinhalten:
Liefern der Lese/Schreib-Daten (32 Bits) während DMA-Operationen
Einleiten des Daten-Request an DMAC 209
Einleiten des Interrupt-Request über DMAC-Leitung PCLO 257a
Jedesmal, wenn der S/88 Prozessor 62 seinen Adressenbus mit einer gültigen örtlichen Busdecodierung (007EXXXX) oder mit einem DMAC gerichteten Interrupt-Acknowledge-Zyklus aktiviert, führt die BCU 156 Logik durch wie folgt:
Blockiert die ADRESS STROBE Leitung zum S/88
Aktiviert einen Bus-Request zur Konkurrenz-Logik 216.
Wenn der örtliche Bus nicht im Gebrauch ist, wird der S/88 Prozessor Adressen-Bus 161A und der Datenbus 161D über die Treiber/Empfänger 217, 218 an den örtlichen Bus 247, 223 gekoppelt. Die Lese-, Schreib- oder IACK- Operation wird ausgeführt.
Die DSACK-Leitungen 266a, b werden von der BCU-Logik aktiviert, um den Zyklus abzuschließen:
32 Bit DSACK für alle an den örtlichen Speicher und an die BCU gerichteten Befehle.
16 Bit DSACK für alle an das DMAC Register gerichteten Befehle.
16 Bit DSACK für IACK Zyklen.
Die DMAC Bus-Request-(BR)-Leitung 269 vom DMAC 209 wird für eine DMAC- oder Verbindungsgliedlisten-Ladesequenz aktiviert. Wenn das eintritt, führt die BCU 156 die folgenden Aufgaben durch:
Wenn der örtliche Bus nicht im Gebrauch ist, wird die DMAC-Adresse (während DMAC-Lesen/Schreiben oder Verbindungsgliedlisten-Laden) auf den örtlichen Adressen-Bus 247 gelegt. Die BCU 156 Logik legt ihre Daten (DMAC Schreiben in den örtlichen Speicher 210) von einem DMAC- Register auf den örtlichen Datenbus 223. Der örtliche Speicher 210 legt seine Daten (DMAC Lesen oder Verbindungsgliedliste-Laden) auf den örtlichen Bus 223. Die Lese/Schreib-Operation wird ausgeführt. Die DTACK-Leitung wird von der BCU-Logik 253 zum DMAC 209 aktiviert, um den Zyklus abzuschließen.

(e) S/88 Prozessor 62 und DMAC 209 Adressieren zum/vom örtlichen Speicher 210

Die Adressenbits-Zuordnungen vom S/88 Prozessor 62 zum örtlichen Speicher 210 sind wie folgt: Niederwertige Bits 0, 1 (und SIZ0, 1 von PE62, nicht gezeigt) bestimmen die Nummer und die Busausrichtung der zu übertragenden Bytes (1-4). Bits 2-15 einschließlich sind die Adressenbits für den Speicherraum 210.
Im Verbindungsgliedlisten-Modus wird das DMAC Adressenbit A2 als niederwertiges Adressenbit (Doppelwortgrenze) an den örtlichen Speicher 210 geschickt. Da das DMAC 209 eine wortorientierte (16-Bit) Vorrichtung ist (A1 ist ihr niederwertiges Adressenbit) und da auf den örtliche Speicher vom Doppelwort (32 Bits) zugegriffen wird, müssen einige Mittel in der Hardware vorgesehen sein, daß der DMAC 209 Daten in seine interne Verbindungungsglied-Liste von zusammenhängenden örtlichen Speicherstellen einlesen kann. Das wird erreicht durch zweimaliges Lesen der gleichen Doppelwortstelle im Speicher 210, unter Verwendung von A2 als niederwertiges Adressen-Bit. Bit A1 wird dann benutzt, um das Hoch/Niedrig-Wort vom örtlichen Bus zu wählen. Das Verschieben des Adressenbits zum örtlichen Speicher 210 wird in der Hardware über die DMAC-Funktionscode-Bits erreicht. Jeder Funktionscode, mit Ausnahme der "7" vom DMAC 209, bewirkt, daß die Adreßbits A15 - A02 auf den örtlichen Speicher 210 gelegt werden. Dieses Schema ermöglicht das Abspeichern der örtlichen Speicherverbindungs glied-Listen-Daten für den DMAC 209 in aneinanderliegenden Stellen im Speicher 210.
Im Lese/Schreib-Modus zum örtlichen Speicher wird das DMAC- Bit A1 als niederwertiges Adressen-Bit für den örtlichen Speicher 210 benutzt. Die Lesedaten werden vom Lesepuffer 226 des Adapterbuskanals 0 an den Speicher 210 gegeben. Daten werden aus dem Speicher 210 in den Schreibpuffer 228 des Adapterbuskanals 1 geschrieben. Da der DMAC eine 16-Bit-Vorrichtung ist, wird das niederwertige Adressen-Bit dazu bestimmt, eine Wortgrenze darzustellen. Jedoch greift jede DMAC-Operation auf ein Doppelwort zu. Um Doppelwortzugriffe mit einem Einwortzugriffs-Adressiermechanismus zuzulassen, wird eine Adressenverschiebung benötigt.
Die Adreßbitverschiebung zum örtlichen Speicher 210 wird in der Hardware über die DMAC-Funktionscodebits bewirkt. Ein Funktionscode 7 vom DMAC 209 bewirkt, daß die Adressenbits A14 - A01 auf den örtlichen Speicher 210 gelegt werden. Um einen korrekten Betrieb zuzulassen, wird der DMAC mit 1/4 der aktuellen Bytezählung (1/2 der aktuellen Wortzählung) geladen. Für eine DMAC-Schreiboperation sind Vorkehrungen getroffen, Wortschreiben durch Steuerung der UDS- und LDS-Leitungen (nicht dargestellt) vom DMAC 209 zu ermöglichen, obwohl alle DMAC-Operationen in Normalfall Doppelwortzugriffe sind. Die UDS- und LDS-Signale bewirken den Zugriff auf hoch- (D31-D16) und niederwertige (D15-D0) Teile des örtlichen Speichers 210.
3 m PE62-zum-DMAC 209-Modus schreibt der S/88 Prozessor PE62 die DMAC Register in jeden der vier DMAC-Kanäle 0-3, um die internen Steuerungen für die DMAC Operation einzustellen. Das PE62 hat auch die Fähigkeit, alle DMAC-Register zu lesen. Der DMAC 209 gibt ein Wort (16 Bit) DSACK auf einen Bus 266 zurück, der zwei Leitungen DASCK 0, DSACK 1 aufweist, die die Portgrößen 8, 16 oder 32 Bits zulassen. Das ermöglicht es dem DMAC 209, so viele Zyklen aufzunehmen, als nötig sind, um das DMAC-Laden ordentlich auszuführen.
Der S/88 Prozessor SIZ0 und SIZ1 (nicht gezeigt) und die A0 Leitungen werden benutzt, um die UDS (Oberes Daten-Strobe) und LDS (Unteres DATEN-Strobe)-Eingänge (nicht gezeigt) zum DMAC 209 zu generieren. Das ist erforderlich, um auf Bytebreite Register im DMAC 209 zuzugreifen, wie in näheren Einzelheiten in der obigen DMAC-Veröffentlichung beschrieben ist. Die LDS-Leitung wird generiert vom logischen ODER der NICHT-SIZ0 oder SIZ1 oder A0 des Adressenbus 161D. Die UDS- Leitung wird generiert vom logischen NICHT der A0. Die SIZ0 Leitung wird benutzt, um auf das niederwertige Byte zuzugreifen, wenn auf ein Wort-breites Register zugegriffen wird (NICHT SIZ0). Die SIZ1-Leitung wird benutzt, um auf das niederwertige Byte zuzugreifen, wenn über eine "Drei-Byte-bleibende" S/88 Prozessoroperation auf ein Wort-breites Register zugegriffen wird. Das geschieht nur, wenn der S/88 Prozessor eine Doppelwort (32 Bit) Lese/Schreiboperation zum DMAC auf einer ungeradzahligen Byte-Grenze ausführt. Bit A0 wird benutzt, um das Hoch- oder Tief-Byte in einem zwei-Byte-Register anzuwählen. Die Bits A0, A1 werden benutzt, um Bytes in einem Vier-Byte-DMAC-Register anzuwählen. Die Bits A6, A7 des PEG2 Adressenbusses 161D wählen einen der vier DMC Kanäle an.

(f) BCU BSM RD/WR Byte-Zähleroperation

Die BCU 156 ist in der Lage, einen Einzelbefehl vom DMAC 209 aufzunehmen, der bis zu 4kB Daten über jeden Adapterbus 250, 251 überträgt. Jedoch kann jeder Bus nur 64-Byteblocks je Datentransferoperation behandeln. Es gibt noch weitere Busadaptereinschränkungen, die von der Hardware zu beachten sind, um die Protokoll-Forderungen zu erfüllen. Nachfolgend wird eine detaillierte Beschreibung der BCU-156-Hardware gegeben, die dieser Forderung genügt.
Die BCU 156 enthält zwei Vollwort-(11 Bit)-Zähler 220, 222 und zwei Grenzen-(4 Bit)-Zähler 221, 224, die für Adapterbus- BSM-Lese- und -BSM-Schreib-Operationen benutzt werden. Die Grenzenzähler 221, 224 werden benutzt, um eine Anfangsadresse zum Busadapter vorzusehen, wenn eine 64-Byte-Grenzüberschreitung von der BCU 156 für eine Einzelbefehls/Datentransferoperation erfaßt wird oder wenn die Byte-Zählung größer als 64 Bytes ist. Die Grenzenzählerinhalte werden auf den Busadapter 154 gelegt für alle außer der letzten Blockübertragung. Der Vollwortzählerinhalt wird nur für den letzten Blocktransfer gegeben (letzte Befehls/Datentransferoperation).
Der S/88 Prozessor 62 legt Byte-Zählung, Schlüssel und Prioritätsbits auf den örtlichen Bus 223 (Fig. 45F) zur Übertragung zum Register 222 bzw. 220. Das r-Bit (Zählbit 1) zeigt die Wort-(2 Byte)-Grenzen und das s-Bit (Zählbit 0) zeigt die Byte-Grenzen. Vollwortzähler-Bits zeigen eine 2kB-1 Doppelwort-Transferfähigkeit an. Da alle Übertragungen auf Doppelwortbasis durchgeführt werden, ist Bit 2 das niederwertige Dekremetierungs-Bit. Die Bits r und s werden von der BCU eingespeist und beim End-64B-Transfer auf den Busadapter 154 gelegt.
Infolge der nachfolgenden Busadapter-Restriktionen und der Tatsache, daß nur Doppelwort-Übertragungen auf den örtlichen Bus 223 vorkommen, müssen die Byte- und Wortzähl-Bits manipuliert werden. Das läßt ungeradzahlige Bytes/Wörter zur Übertragung auf das S/370 PE85 zu, und ermöglicht auch eine Anfangsadresse, die nicht auf einer Doppelwortgrenze liegt. Der Bytezählung, die auf den Bus-Adapter 154 gelegt wird, kann nicht größerer sein als 64 Bytes. Die Zählung muß in Bytes-1 dargestellt werden. Keine Blockübertragung darf eine 64 Byte- Grenze überschreiten. Wenn die Bytezählung gleich oder kleiner als 64 Bytes ist und es nicht zur Grenzüberschreitung kommt und die Anfangsadresse nicht auf einer Doppelwortgrenze liegt, kann eine Extraabgleichung mit der Doppelwortzählung erforderlich werden.
Wenn es eine 64-Byte-Grenzüberschreitung gibt, sind mindestens zwei Adapterbus-Befehls/Datentransferoperationen erforderlich, ungeachtet des Zählwerts. Der S/88 Prozessor wird die Doppelwort-Zählung und die r-, s- und i-Bits auf der Grundlage einer Prüfung der oben beschriebenen Faktoren und die Gesamtbyte-Übertragungszählung berechnen. Die r- und s- Bits werden bis zur letzten Befehls/Datentransferoperation nicht auf den Busadapter 154 gelegt.
Wenn das S/88 PE62 den Zählwert auf den örtlichen Bus 223 legt (Fig. 45F), erfaßt der DMAC 209 die Bits 31-16, und die BCU 156 erfaßt Bits 26-6. BCU 156 speichert die Bits 26-14 in Register 220 oder 222. Die Bits 26-16 stellen das Doppelwortzählfeld dar. Der Zähler 220 oder 222 wird von einer Doppelwortgrenze (Bit 2) dekrementiert. Der S/88 Prozessor PE62 legt einen BSM Lese/Schreib Select Up Befehl auf den örtlichen Adressenbus 247, und die BSM Anfangsadresse auf den örtlichen Datenbus 223.
Der DMAC 209 ist eine 16-Bit-Vorrichtung, die an einen 32- Bit-Bus angeschlossen ist. Er ist so programmiert, daß er Übertragungswörter (2 Bytes) während der DMA-Operationen auf allen Kanälen überträgt, und jedes interne Speicheradressenregister MAR um ein Wort (2 Bytes) je Übertragung inkrementiert. Jedoch ist ein Doppelwort-(4 Byte)-Inkrement erforderlich, weil jede Übertragung in Wirklichkeit 32 Bits betrifft. Um das zu erreichen initialisiert der S/88 Prozessor PE62 immer das MAR auf die Hälfte der gewünschten Anfangsadressen (im Speicher 210). Die BCU 156 kompensiert das dann durch Verdoppelung der Adressen vom MAR, bevor sie sie auf den ört lichen Bus 223 legt, was zur korrekten Adressenfolge führt, wie man am Speicher 210 sieht.
Die BCU 156 arbeitet wie folgt:
1. Der Grenzenzähler 221 oder 224 wird geladen von den invertierten Bits 2-5 des örtlichen Datenbusses 223 gleichzeitig mit dem Laden des BSM Adressenregisters 228 oder 231;
2. Dekrementiert den Vollwortzähler 220 oder 222 von einer Doppelwortgrenze (Bit 2); und
3. Inkrementiert das BSM Adressenregister 228 oder 231 von einer Doppelwortgrenze (Bit 2).
Wenn mehr als 64 Bytes übrig bleiben oder bei einer Datenblockübertragung eine Grenzüberschreitung vorkommen, legt die BCU 156 die BSM Lese/Schreib-Befehlsbytezählung aus dem Grenzenzähler 221 oder 224 auf den Befehls/Statusbus 249 oder 252 und die Bits 1,0 (invertiert) in das BSM-Adressenregister 231 oder 228. Dann wird eine Lese/Schreib-Operation durchgeführt. Die BCU 156 wird dann die Grenzenzählungsregister 221 oder 224 und die Vollwortzählungsregister 220 oder 222 von einer Doppelwortgrenze dekrementieren; zusätzlich inkrementiert sie die BSM Adressenregister 231 oder 228 auf eine Doppelwortgrenze. Die BCU 156 stoppt, wenn das BCM-Adressen-Register 231 oder 228, Bits 5-2 = 0000, eine 64-Byte-Grenze ist. Die Grenzenzählungsbits sollten jetzt = 1111 sein.
Wenn nun 64 Bytes oder weniger übrig sind und es während einer Datenblockübertragung keine Grenzüberschreitung gibt, legt die BCU 156 die BSM Lese/Schreib-Befehlsbytezählung, den Befehls/Status-Bus 249 oder 252 von den Bits 5-2 des Zählers 220 oder 222, und die r-, s-Bits auf den Adapterbus. Dann führt die BCU 156 eine Lese/Schreiboperation durch, während der sie die Register 220 oder 222 von einer Doppelwort-Grenze dekrementiert, die BSM Adressenregister 231 oder 228 auf einer Doppelwortgrenze inkrementiert, und stoppt, wenn die Register 220 oder 222 Bits 12-2 alle Eins sind. Eine Grenzüberschreitung wird gefunden durch Vergleichen der Bits 2-5 des Zählregisters 220 oder 222 mit seinem Grenzenregister 221 oder 224. Wenn der Zählregister-220, 222-Wert größer ist als der der Grenzregister 221, 224, dann wird eine Grenzüberschreitung festgestellt.

(g) Handshake-Sequenzen BCU 156/Adapter 154

Der Impulsfahrplan der Fig. 25 zeigt die Handshake-Sequenzen zwischen der BCU 156 und dem Adapter 154 für Mailbox-Lesebefehle und Speicherlesebefehle einschließlich der Übertragung von zwei Zweiunddreißig-Bit-Wörtern in einen Arbeitswarteschlangenpuffer im örtlichen Speicher 210.
Wenn ein Mailbox-Lese- oder Speicherlesebefehl auf den Bus 290 (Fig. 19A) gelegt wird, steuern ein paar Signale 'Gate Left' und 'Gate Right' sequentiell den linken und den rechten Teil des Befehls und der Adresse in den Registern 214 und 219 (Fig. 19B) zum Adapter 154, um die richtigen Daten aus dem S/370 Speicher 162 zu holen. Der Befehl 'Tag-Up' auf Leitung 262a wird hoch gesetzt, gefolgt von periodischen Datenlesesignalen. 'Tag-Down' auf Leitung 262 wird hochgesetzt, bis die abgerufenen Daten im Puffer 259 gespeichert sind. Wenn das nächste das periodischen Signale 'Takt-Links' und 'Takt- Rechts' hoch gesetzt wird, werden der linke und der rechte Teil des ersten geholten Worts über den Bus 250 in den Puffer 226 eingespeist.
Bus Request wird auf Leitung 263a oder b für DMAC-Kanal 0 oder 1 hoch gesetzt. DMAC setzt die Priorität für die Steuerung des örtlichen Kanals über Leitung 269 fest. Wenn diese Anforderung von der Logik 216 genehmigt wird, wird Bus Grant auf Leitung 268 hoch gesetzt. DMAC 209 setzt das Signal Acknowledge auf Leitung 264a oder 264b hoch, was bewirkt, daß die BCU die Daten in Puffer 226 auf den örtlichen Bus 223 legt, während DMAC 209 die angewählte örtliche Speicheradresse auf den örtlichen Adressenbus 247 legt. Der DMAC 209 gibt dann DTC auf Leitung 267 aus, um die Logik 253 zu veranlassen, Store Select auf Leitung 210a hoch zu setzen; und die Daten auf Bus 223 werden in den richtigen Puffer im örtlichen Speicher 210 gelegt.
Nach periodischem Tag-Up, Clock Left und Right, speichert DMAC Request die nachfolgenden Datenwörter in Puffer 226; und diese Wörter werden zum entsprechenden Puffer im Speicher 210 übertragen, sobald DMAC 209 auf die örtlichen Busse 247, 223 über die Prioritätslogik 216 zugreifen kann, und gibt die Signale Acknowledge und DTC aus.
Fig. 26 zeigt auf ähnliche Weise die Handshake-Sequenzen für Queue Select Up und Speicher-Schreibbefehle. Wenn einer dieser Befehle auf den Bus 190 ausgegeben wird, übertragen die Signale Gate Left und Right den Befehl und die Adresse (die vorher in den Registern 225 und 227 gespeichert wurden) an den Adapter 154. Ein Befehl Tag Up, gefolgt von periodischen Datensignalen, werden auf Leitung 262a hoch gesetzt. DMAC Request wird auf Leitung 263c oder d hoch gesetzt. Der DMAC 209 setzt die Priorität für den örtlichen Bus 247, 223 über die Leitung 269 und die Logik 216. Wenn die Anforderung über die Leitung 268 genehmigt wird, setzt DMAC 209 Acknowledge auf Leitung 264c oder d hoch, gefolgt von DTC auf Leitung 267, um das erste Datenwort vom Speicher 210 ins Register 227 zu übertragen. Die nächsten periodischen Signale Gate Left und Right übertragen das erste Datenwort aus Register 227 zum Puffer 260 des Adapters 154.
Die nachfolgenden Signale DMAC Request auf Leitung 263c oder d und die Signale DMAC Acknowledge und DTC übertragen die nachfolgenden Datenwörter zum Register 227 wenn der DMAC 209 die Priorität für die Steuerung der örtlichen Busse 247, 223 festlegt. Nachfolgende periodische Signale Gate Left und Right übertragen jedes Datenwort aus dem Register 227 zum Puffer 260.

S/370 PROZESSORELEMENT PE85

Jedes Prozessorelement, wie z. B. PE85 der bevorzugten Ausführungsform enthält die grundlegenden Einrichtungen zum Abarbeiten der S/370 Befehle und enthält die folgenden Einrichtungen
Basis 32-Bit-Datenfluß;
32-Bit arithmetisch/logische Einheit (ALU) 306;
32-Bit Verschiebeeinheit 307;
48 Register (jeweils 32 Bits) örtlicher Datenspeicher;
303 mit 3-Port-Adressierbarkeit;
8-Byte S/370 Anweisungspuffer 309; und
Taktvorrichtungen (CPU Taktgeber, Komparator usw.) 315.
Der vereinfachte Datenstrom einer bevorzugten Form des PE85 wird in Fig. 27 gezeigt; dabei muß berücksichtigt werden, daß es viele S/370 Prozessor-Implementierungen gibt, die auf dem Stand der Technik wohlbekannt sind. Die bevorzugte Form jedes Prozessorelements 85 der bevorzugten Ausführungsform ist ein Prozessor, der in der Lage ist, Anweisungen der System/370- Architektur auszuführen. Der Prozessor holt Anweisungen und Daten aus einem realen Speicherbereich 162 des Speichers 16 über den Prozessorbus 170. Dieser bidirektionale Bus 170 ist die universelle Verbindung zwischen dem PE85 und den anderen Einheiten des S/370 Chipsatzes 150. PE85 handelt als Master, hat aber die niedrigste Priorität im System. Die Anweisungen werden ausgeführt durch Hardware und Mikroinstruktionen, die der Prozessor ausführt wenn er im Mikromodus steht.
PE85 hat vier Hauptfunktionsgruppen:
- Die "Busgruppe", bestehend aus den Sende- und Empfangsregistern 300, 301, und die Adressenregister 302 für Speicheroperanden und Anweisungen.
- Die "arithmetisch/logische Gruppe" bestehend aus dem örtlichen Datenspeicher (DLS) 303, den A und B Operandenregistern 304, 305, der ALU 306 und der Verschiebeeinheit 307.
- Die "Operations-Decodier"-Gruppe bestehend aus dem Steuerspeicheradressenregister (CSAR) 308, dem S/370 Anweisungspuffer (I-Puffer) 309, den OP-Registern 310 und den Zykluszählern 311 mit Fallen- und Ausnahmesteuerung.
- Die "Taktgruppe", die eine kleine, verhältnismäßig unabhängige Einheit 315 ist, die aus dem Intervall-Taktgeber 315, Tageszeitgeber, Takt-Komparator und CPU-Taktgeber besteht.
Die nachstehende kurze Beschreibung wird die Anwendung dieser logischen Einheiten kurz umreißen.
Der I-Puffer 309 macht die S/370 Anweisungen möglichst schnell für den Decodierer verfügbar. Das erste Halbwort, das den OP-Code enthält, wird über das Operationsregister 310 in den Decodierer 312 geschickt, um die 3/370 I-Phase anlaufen zu lassen. Das zweite und das dritte Halbwort (falls vorhanden) werden zwecks Adressenberechnung zur ALU geschickt. Der I-Puffer 309 ist ein Doppelwortregister, das von Operationen wie IPL, LOAD PSW oder PSW-Swap über eine erzwungene Operation (FOP) vor dem Anlaufen einer S/370 Anweisungs-Sequenz in Register 313 geladen wird. Der I-Puffer 309 wird Wort um Wort nachgefüllt, wenn die Anweisungen in das Operationsregister 310 (und zur Adressenberechnung in die ALU 306) eingespeist werden, und wird bei jeder erfolgreichen Verzweigung komplett nachgefüllt. Der Operationsdecodierer 312 wählt aus, welche Operation auszuführen ist. Der Decodierer wird von der Operation und vom Mikrocode-Operationsregister 310 gespeist. Modus-Bits entscheiden, welcher (oder keiner im Falle einer erzwungenen Operation) das Decodieren steuert.
Die Inhalte des I-Puffers 309 werden in das Operationsregister 310 eingespeist und parallel dazu in das CSAR 308, um eine OP-Code-Tabelle im Steuerspeicher 171 anzusprechen. Jeder Eintrag in dieser Tabelle dient für zwei Zwecke: Er gibt an, ob eine Mikrocode-Routine existiert und spricht die erste Anweisung dieser Routine an. Mikrocode-Routinen existieren zur Ausführung der komplexeren Anweisungen, wie veränderbare Feldlängenanweisungen und alle anderen, die nicht direkt von der Hardware ausgeführt werden. Spezielle Funktionscodes in den Mikroanweisungen aktivieren die unterstützende Hardware, so daß es möglich wird, den 32-Bit-Datenfluß unter Verwendung von hauptsächlich 16-Bit-Mikroanweisungen zu steuern.
Das Verarbeiten geschieht in einer Dreistufen-Pipeline wie folgt:
- Die erste Stufe liest die Anweisung in das OP-Register 310.
- Die zweite Stufe liest die Daten und/oder Adressen in die A/B-Register 304, 305 und in das Bus-Senderegister 300. Das OP-Register 310 wird frei für eine andere erste Stufe durch Weitergeben seines Inhalts an den OP-Decodierer 312, der die dritte Stufe steuert.
- Die dritte Stufe führt je nach Fall die ALU, Schiebe- oder Bus-Operation durch. DLS Schreiboperationen werden ebenfalls auf der dritten Stufe durchgeführt.
Die effektive Verarbeitung wird weiter verstärkt durch Implementieren des Decodierers in verschiedenen Gruppen (nicht dargestellt), von denen eine besonders der ALU zugewiesen ist, eine andere der Busgruppe, usw. Byte-anwählbare Multiplexer (nicht dargestellt) am A/B-Registereingang und am ALU- Ausgang verstärken weiter die Operationen. Somit gibt es S/370 RR Anweisungen, die jede Pipline-Stufe jeweils nur für einen einzigen Zyklus besetzen.
Die Register für erzwungene Operationen (FOPs) 313 werden zur internen Steuerung benutzt. Sie erhalten ihre Eingaben von Fallen und Aufnahmebedingungen und erzwingen einen anderen Modus im Decodierer 312. Typische Operationen sind I-Puffer- Laden, Übergang zur Fallen-Ebene und das Anlaufen von Ausnahmeroutinen.
Jedes Operationsregister 310 hat selbst einen Zykluszähler 311. Die Mikrocode-Zykluszähler werden auch von einigen erzwungenen Operationen (FOPs) gemeinsam benutzt. Die arithmetischen Operationen und die meisten anderen Mikroanweisungen brauchen nur einen Zyklus. Die meisten Mikroanweisungen, die Prozessorbusoperationen ausführen, benötigen zwei Zyklen.
Der örtliche Datenspeicher 303 enthält 48 Vollwort-(4-Byte)- Register, die über drei Ports zugänglich sind, von denen zwei Ausgangports und einer der Eingangsport ist. Über Register 314 kann jedes Register als Eingang angesprochen werden, und das gleiche Register oder auch zwei unterschiedliche Register können gleichzeitig zur Ausgabe angesprochen werden. Diese Dreifachadressierung ermöglicht, daß sich das Operandenabrufen mit der Verarbeitung überlappt. Aufgrund einer Vergleicherlogik und Dateneinspeichern (nicht dargestellt) kann ein Register, das gerade für eine Schreiboperation angesprochen wurde, noch im gleichen Zyklus auch als Eingang benutzt werden. Das erleichtert die Pipeline-Aktionen.
Die ALU 306 ist vorzugsweise eine Vollwort-Logikeinheit, die in der Lage ist UND-, ODER-, XOR-, und ADD-Operationen in Echtform oder in invertierter Form mit zwei Vollwort-Operanden durchzuführen. Auch Dezimaladditionen werden unterstützt. Paritätsvoraussagen und -generierung sowie Übertrags-Schnellfortpflanzung ist eingeschlossen. Das Speicherregister 320 unterstützt Teilungsoperationen. Die Statuslogik 321 generiert und speichert verschiedene Bedingungen für Verzweigungsentscheidungen, Zeichenauswertung usw.
Das Steuerspeicheradressierungsregister (CSAR) 308 adressiert Mikroanweisungen und Tabellen im Steuerspeicher 171. Der Eingang zum CSAR 308 ist entweder eine aktualisierte Adresse aus dem zugeordneten Modifikator 322 oder eine Verzweigungsadresse von einem erfolgreichen Zweig, oder eine erzwungene Adresse für einen Tabellendurchsuchbefehl. Eine Tabellendurchsuchung ist Voraussetzung zu Beginn jeder S/370 Anweisung und für einige erzwungene Operationen (FOPs). Das CSAR 308 erfaßt das OP-Code-Muster als Adresse zum Zugriff auf die OP-Code-Tabelle (Fig. 29). Der Ausgang dieser OP-Code-Tabelle definiert die Ausführungsform, die direktes Decodieren aus dem Operationsregister 310 sein kann. Wenn indirekte Ausführung erforderlich ist, wird der OP-Code-Tabellenausgang in das CSAR zurückgeführt, um die richtige Mikroroutine anzusprechen.
Das Speicheradressenregister 302 ist für 24-Bit-Adressen ausgelegt. Ein zugeordneter Modifikator 323 aktualisiert die Adresse nach der Größe des abgerufenen Datenblocks. Anweisungen werden im vorhinein in Ein-Wort-Inkrementen (4 Bytes) abgerufen, wenn der I-Puffer 309 geleert wird. Der Eingang zum Speicheradressenregister 302 kommt vom Anweisungsoperanden- Adressenregister 324. Er wird ferner aus Beschleunigungsgründen parallel zum Anweisungsadressenregister 324 gesetzt.
Der CPU-Datenfluß ermöglicht das überlappende Bearbeiten von bis zu drei S/370 Anweisungen gleichzeitig. S/370 Anweisungen werden entweder in Hardware oder durch Mikroanweisungen interpretiert ausgeführt. Der Grundzyklustakt der bevorzugten Ausführungsform ist 80 ns. Die Anweisungsabarbeitung wird in einem oder mehreren 80-ns-Schritten ausgeführt. Eine Hochgeschwindigkeitsvorrichtung PE151 beschleunigt binäre und Fließkomma-Multiplikationsoperationen. Mikroanweisungen vom Steuerspeicher 171 werden nur für die Ausführung solcher S/370 Anweisungen verwendet, die zu komplex und damit zu aufwendig sind, als daß sie ganz in Hardware ausgeführt werden könnten. Die Mikroanweisungen werden, falls erforderlich, mit einer Geschwindigkeit von 60 ns je Anweisung geliefert. Der Mikroanweisungssatz ist für die Interpretation der S/370 Anweisungen optimiert. Mikroanweisungen haben Halbwort-Format und können zwei Operanden ansprechen.
Der nicht im Steuerspeicher 171 enthaltene Mikrocode sitzt im IOA-Bereich 187, der ein reservierte Bereich im S/370 Speicher 162 ist (siehe Fig. 28, 29). Dieser Mikrocode enthält den weniger leistungsempfindlichen Code für Ausnahmen, nicht oft ausgeführte S/370 Anweisungen usw. Diese Mikroroutinen werden auf Anforderung in einen 64B-Puffer 186 im RAM-Teil des Steuerspeichers 171 geholt. Wenn immer das PE85 auf eine Adresse stößt, die größer ist als im Steuerspeicher 171 implementiert, läßt es eine 64B Blockabrufoperation zum Cache- Controller 153 und zur Speicher-Controller-Schnittstelle 155 anlaufen. Die Einheiten 153, 155 rufen den 64B-Block vom IOA 187 ab und senden ihn in das PE85, das ihn in den Puffer 186 speichert. Die Mikroanweisungen werden zur Ausführung vom PE85 aus dem Puffer 186 geholt. Jeder Mikrocode wird beim Mikrocode-Urladen (IML) in den Speicher geladen. Das System sieht eine IML-Unterstützung vor, um das Mikrocode-Laden vom S/88 in den Speicher zu ermöglichen.
S/370 Anweisungen und Anwenderdaten werden von einem 8kB- Hochgeschwindigkeits-Cache-Speicher 340 (Fig. 31) geholt. Die Daten werden auf Vollwortbasis aus/in den Cache 340 gelesen/geschrieben. Die Zeit zum Lesen/Schreiben eines vollen Worts aus/in den Cache beträgt 120 Nanosekunden. Der Cache 340 wird automatisch mit 64-Byte-Blöcken aus dem Speicher 162 aufgefüllt sobald das erforderlich wird. Das PE85 kommuniziert mit dem Cache 240 über Prozessorbus-Befehle. Die vom PE85 gelieferten virtuellen Adressen werden dazu verwendet, die entsprechenden vor-übersetzten Seitenadressen in der Verzeichnisseiten-Nachschlagtabelle (DLAT) 341 nachzuschlagen.
Der örtliche Datenspeicher 303 im PE85 beinhaltet 16 allgemeine Register, 4 Gleitkommaregister und 24 Arbeitsregister. Alle Register können über drei gesondert ansprechbare Ports individuell adressiert werden. So kann der Speicher 303 zwei Operanden parallel in die ALU 306 einspeisen und gleichzeitig ein volles Wort von der ALU 306 oder vom Cache 340 innerhalb des gleichen 80 ns Zyklus aufnehmen. Da es keine Serialisierung wie bei herkömmlichen örtlichen Datenspeichern gibt, können arithmetische und logische Operationen mit der Vorbereitung für die nächsten Anweisungen überlappend durchgeführt werden.
Die CPU unterhält einen 8-Byte-Anweisungspuffer (I-Puffer) 309 für S/370 Anweisungen. Dieser Puffer wird durch eine erfolgreiche S/370 Sprunganweisung initialisiert. Das PE85 holt ein Daten-Doppelwort aus dem S/370 Anweisungsstrom vom Cache 340 und lädt es in den I-Puffer 309. Wenn das erste Vollwort in den I-Puffer 309 geladen ist, startet das PE85 die Anweisungsabarbeitung erneut. I-Pufferdaten werden vom Cache 340 gleichzeitig mit der Abarbeitung der S/370-Anweisung geholt. Da der erste Zyklus in jeder S/370 Anweisungsausführung ein Nicht-Cache-Zyklus ist, benutzt die CPU diesen Zyklus zum Vorabholen eines Vollworts aus dem Cache 340 in den I-Puffer 309.
Ein zweiter Nicht-Cache-Zyklus mit S/370 Anweisungen steht zur Verfügung, die während der effektiven Adressenberechnung indexiert werden müssen oder durch Mikroroutinen ausgeführt werden. In solchen Fällen kann sich das Holen der S/370- Anweisungen mit der Ausführung von S/370 Anweisungen voll überlappen.
In der bevorzugten Ausführungsform kommuniziert der S/370 Chipsatz über einen Interrupt-Mechanismus, der voraussetzt, daß der Chip ein Interrupt erhält, um ihn durch Rückstellen des Interruptzwischenspeichers des sendenden Chips zu quittieren.
Wenn immer das System (z. B. über die BCU 156) ein oder mehr Bits in ein Status-Register (STR) (nachstehend beschrieben) des Adapters 154 setzt (aktiviert), muß das System auch die Leitung N_ATTN_REQ aktivieren. Das bewirkt eine Ausnahmebedingung im Prozessorelement 85, wenn die augenblickliche S/370 Anweisung ausgeführt wurde, und zwingt somit das Prozessorelement 85, im Statusregister "nachzuschauen". Ein Ausnahmebedingung-Bearbeitungsprogramm tastet dann den STR- Inhalt ab, befragt den/die "Interrupt-Typ(en)" und setzt die richtige(n) System-Mikroroutine(n) in Gang. Wenn immer das Prozessorelement 85 ein Bit im STR aktiviert, muß das System darauf entsprechend reagieren. Grundlegend gibt es zwei Typen von Interrupt Requests:
1. System-Requests (SYSREQs) sind Abrufe (über die BCU 156) an das S/370 Prozessorelement 85. Das System setzt den(die) Interrupt-Typ(en) in das STR, um seine Anforderung zu spezifizieren. Das bewirkt eine Ausnahmebedingung im Prozessorelement 85, das die Steuerung auf das Ausnahmebedingungs-Bearbeitungsprogramm überträgt. Das Ausnahmebedingungs-Bearbeitungsprogramm sendet die richtige Mikroroutine ab, die einen PROC-Bus-Befehl an den Adapter 154 ausgibt, um den richtigen Interrupt-Typ im STR rückzustellen, die vom Interrupt-Typ definierte Funktion in Gang zu setzen, und die Ausführung der nächsten S/370- Anweisung anlaufen zu lassen.
2. Übertragungsanforderungen können entweder vom System oder vom PE85 aufgerufen werden und beinhalten einen zusätzlichen Datentransfer zur Systemschnittstelle. Zu diesem Zweck werden zwei Interrupt-Zwischenspeicher im STR angenommen: Einer ist der Prozessor-Communication- Request (PCR), der andere ist der System-Communication- Request (SCR). Der PCR wird vom PE85 gesetzt und vom System rückgestellt; der SCR wird vom System gesetzt und vom PE85 rückgestellt.
Für schnelle Datentransferoperationen wird das Vorhandensein von zwei zusätzlichen Registern angenommen, das BR Register 115 (Fig. 13), das vom PE85 gesetzt und vom System gelesen wird, und das BS-Register 116, das vom System gesetzt und vom PE85 gelesen wird.
Hier nachstehend folgt ein Beispiel für eine Anforderung einer Übertragung vom PE85 zum System. Das PE85 legt die an das System zu übertragenden Daten in das Register 115 und setzt den PCR1 Zwischenspeicher auf ein. Das System liest die Daten aus dem Register 115 und stellt den PCR-Zwischenspeicher zurück.
Der Prozessor 85 kann den PCR Zwischenspeicher abtasten um festzustellen, ob er rückgestellt wurde oder nicht. Durch Wiederholen der obigen Folge kann das PE85 weitere Daten auf das System übertragen.
Auf ähnliche Weise kann das System Daten auf das PE85 übertragen wie folgt. Das System setzt die auf das PE85 zu übertragenden Daten in das Register 116, und stellt den Zwischenspeicher auf Ein. Das PE85 wird unterbrochen, tastet das STR ab, findet den SCR Zwischenspeicher auf Ein, liest die Daten aus dem Register 116 und stellt den SCR Zwischenspeicher zurück. Das System kann den SCR-Zwischenspeicher abfragen, um herauszufinden, ob er rückgestellt wurde oder nicht.
3. Durch Wiederholen der obigen Sequenz kann das System noch weitere Daten auf das PE85 übertragen.
Daten lassen sich auch über den IOA-Speicherbereich 187 übertragen. Es gibt PROCBUS Befehle für das PE85 und den Adapter 154, die beiden das Speichern/Abrufen von Daten in/aus dem IOA-Bereich 187 ermöglichen.
Dem PE85 ist einen Puffersatz im IOA-Bereich 187 zugeordnet, in den es Daten setzt, die vom System geholt werden. Dementsprechend ist dem System ein anderer Puffersatz im IOA- Bereich 187 zugeordnet, in den es Daten setzt, die vom PE85 abgerufen werden müssen. Die Interrupt-Typen IOASYS/IOAPU können in den SYSREQs benutzt werden, um gegenseitig anzuzeigen, daß Daten in IOA-Puffer gesetzt wurden.
Bestimmte Maschinencheck- und externe Abbruchbedingungen werden vom Anwendersystem hoch gesetzt. Das System übermittelt einen Unterbrechungszustand an das PE durch Ausgabe eines SYSREQ oder XFERREQ Kommunikations-Requests. PE85 führt die folgenden Funktionen durch:
a. Es fühlt das Register STR ab und fragt nach seinen Inhalten.
b. Es ruft die im System vorgesehenen Mikroroutinen ab. Das System-Interrupt-Request-Bearbeitungsprogramm führt die spezifische Interrupt-Abarbeitung aus. Zum richtigen Zeitpunkt gibt die Mikroroutine einen PROCBUS Befehl an den Adapter 154, um die entsprechenden SYSREQ oder XFERREQ rückzustellen. Schließlich gibt sie die Steuerung wieder an den S/370 Mikrocode zurück.
c. PE58 führt den PSW-Austausch für die richtige S/370 Interrupt-Klasse durch und führt die NSI-Funktion aus.
E/A-Interrupt-Anforderungen werden vom System generiert durch Setzen der E/A-Bits im STR. Jedesmal, wenn die laufende S/370 Anweisung abgeschlossen wird, wird das Ausnahmebearbeitungsprogramm aufgerufen. In dieser Routine liest das PE85 das STR, um die E/A-Interruptanforderung zu erkennen. Das PE85 stellt das STR-Bit zurück und setzt den PE85-internen Interruptrequest-Zwischenspeicher. Dieser Zwischenspeicher wird mit der E/A-Maske des laufenden PSW maskiert. Wenn die Maske 1 ist und keine Interruptanforderungen höherer Priorität anhängig sind, gibt das Ausnahmebehandlungsprogramm die Steuerung an ein systemeigenes E/A-Interuptrequest-Behandlungsprogramm, das die E/A-Interruptanforderung behandelt.

Prozessorbus 170 (Fig. 11 und 30) und Prozessorbus-Befehle

Der Prozessorbus 170 ist die gemeinsame Verbindung zwischen allen S/370 Chip-Setzkomponenten. Logisch gehören alle nachstehend aufgelisteten Leitungen zu diesem Bus:
1. Prozessorbusleitungen (0-31 + 4 Parität) werden allgemein benutzt zum Übertragen eines Befehls zusammen mit einer Adresse in einem Zyklus, dann Übertragen der zugehörigen Daten im nächsten Zyklus. Die Genehmigung zum Benutzen des Busses wird gegeben von einem Prioritätsverteiler, der vorzugsweise im Busadapter 154 sitzt. Das PE85 hat die niedrigste Priorität. Wenn die Erlaubnis über den Bus-Grant PE85 gegeben wird, legt das PE85 vier Datenwörter auf die richtigen Busleitungen in den nächsten Zyklus. Für eine Speicherzugriffsoperation wird der Befehl auf die PROC BUS Leitungen 0-7 gelegt, die Adresse wird auf die PROC BUS Leitungen 8-31 gelegt, ein Zugriffsschlüssel wird auf den Schlüsselstatus-Bus gelegt und gleichzeitig wird ein 'N-Befehl-Gültig' Signal hochgesetzt.
2. Der Schlüssel/Status-Bus (0-4 + Parität) wird für zwei Zwecke benutzt: Senden eines Zugriffsschlüssels an den Speicher und Zurückbekommen eines Statusberichts. Vier Bits des S/370 PSW-Zugriffsschlüssels plus ein fünftes Bit, das das UND-Ergebnis des PSW Steuermodusbits (BC oder EC) repräsentiert, und das dynamische Adressenübersetzungsbit, werden übertragen.
Der zurückgegebene Status sollte für eine gute Operation gleich Null sein. Ein Nicht-Null-Status bewirkt in den meisten Fällen eine Falle im PE85. Für Befehle des Typs "Meldung", die Steuerzwischenspeicher in der angesprochenen Buseinheit setzen, wird kein Status erwartet.
3. Die N-Bus-Busy-Leitung liefert eine Busy-Anzeige, wenn immer eine Operation nicht im gleichen Zyklus abgeschlossen werden kann, in dem sie gestartet wurde. N-Bus- Busy wird durch das PE85 gleichzeitig mit N-CMD-Valid für alle Befehle aktiviert, die zum Abschluß mehr als einen Zyklus brauchen.
Es obliegt der angesprochenen Bus-Einheit, N-Bus-Busy auf die aktivierte Höhe zu ziehen, wenn die Ausführung des Befehls zwei Zyklen oder mehr in Anspruch nimmt. N-Bus- Busy wird auch zur aktiven Höhe gezogen, wenn die angesprochene Buseinheit den nächsten Befehl für ein paar Zyklen nicht aufnehmen kann. Zu dieser Regel gibt es eine Ausnahme: PE85 aktiviert N-BUS-BUSY für drei Zyklen, wenn es Speicheroperationsbefehle an den BSM-Matrizen-Hauptspeicher 162 ausgibt. Im allgemeinen steht N-Bus-Busy um mindestens einen Zyklus weniger auf der aktivierten Höhe, als die Ausführung eines Befehls dauert.
4. Das Speicherverwaltungseinheit-(MMU)-BUSY-Signal entsteht am Cache-Controller 153. Es wird zum Anzeigen der Ankunft des Status und der Daten für alle Speicherzugriffsoperationen, die zur Ausführung mehr als einen Zyklus brauchen, an das PE58 benutzt.
Abrufoperationen liefern grundsätzlich Daten im nächsten Zyklus (nach dem Anlaufen) oder später. Wenn Daten und Status im nächsten Zyklus geliefert werden, bleibt das MMU-Busy-Signal inaktiv tief (0). Wenn Daten und Status nicht im nächsten Zyklus geliefert werden können, wird MMU-Busy auf 1 hoch gesetzt und geht erst in dem Zyklus wieder auf 0, in dem Daten und Status wirklich auf den Bus gelegt werden.
Bei Speicheroperationen erwartet PE85 den Status auf dem Key Status Bus im nächsten Zyklus (nachdem die Speicheroperation angelaufen ist). Wenn der Status im nächsten Zyklus geliefert werden kann, bleibt MMU-Busy inaktiv (0); sonst wird es auf 1 hochgesetzt und geht in dem Zyklus, in dem der Status wirklich geliefert wird, wieder auf 0 zurück.
5. Der Cache-Fehlt-Indikator auf Leitung MISS IND wird vom Cache-Controller 153 benutzt, um dem PE85 ein DLAT-fehlt, ein Key-fehlt oder eine Adressierungsverletzung anzuzeigen. Die Anzeige ist eine Duplizierung von Informationen, die auch im Status verfügbar sind. Die Leitung ist gültig im gleichen Zyklus, in dem der Status auf den Key-Status-Bus gelegt wird, aber die Fehlt-Anzeige- Leitung wird ein paar Nanosekunden früher aktiviert. Die Fehlt-Anzeige erzwingt über das PE85 im nächsten Zyklus eine Falle.
6. Das Signal auf Leitung Bus-Grant-PE85 gibt die Erlaubnis zum Benutzten des Busses an das PE85. Das Signal geht vom Prioritätsverteiler aus. Das PE85 legt dann Befehl und Adresse für die gewünschte Operation auf den Bus im Zyklus, der auf denjenigen folgt, in dem das Bewilligungssignal aktiv wird und N-Bus-Busy nicht aktiv ist.
7. Verwendung: Das Signal Achtung Request auf Leitung N- ATTN-REQ kommt von einer anderen Buseinheit (wie z. B. vom Bus-Adapter 154), um das PE85 aufzufordern, eine 'Abfrage'-Operation auszuführen. PE85 kommt dieser Aufforderung nach, sobald die augenblicklich gerade abgearbeitete Operation (z. B. Anweisungsausführung) abgeschlossen ist.
8. Das Befehl-gültig-Signal auf Leitung N-CMD-VALID wird vom PE85 benutzt, um anzuzeigen, daß das Bit-Muster auf den PROCBUS-Leitungen 0-31 und Key-Status-Bus-Leitungen 0-4 (einschließlich aller Paritätsleitungen) gültig ist. Die Leitung kann aktiviert werden (tief) im Zyklus, der auf denjenigen folgt, in dem Bus-Grant-PE85 aktiv und N-Bus- Busy inaktiv wird.
9. Die Leitung ADDR-DECREMENT wird vom PE85 benutzt für Speicherzugriffsoperationen, die von der Anfangsadresse abwärts zu absteigenden Stellen führt (wie sie für Dezimaldaten-Bearbeitungsdatenübertragung erforderlich sind). Das Signal kann im gleichen Zyklus aktiviert werden, in dem N-CMD-VALID aktiviert wird.
10. Das Befehl-Abbrechen-Signal auf Leitung CMD-CANCEL wird vom PE85 benutzt, einen bereits anlaufenden Abrufzugriff auf den Speicher abzubrechen. Das kann vorkommen im Zyklus, nach dem N-CMD-VALID aktiv wurde, wenn PE85 Bedingungen findet, die den unmittelbaren Gebrauch der angeforderten Daten verbieten.
In der bevorzugten Auführungsform gibt es fünf Gruppen von PROCBUS-Befehlen allgemein wohlbekannter Typen:
CPU-Speicherung; E/A-Speicherung; MMU-Operation; Meldungsaustausch; und Fließkomma.
Die Buseinheit (PE85, Adapter 154 oder Cache-Controller 153), die die Steuerung des Busses 171 anfordert, legt den Befehl auf den Bus. Für CPU-Speicher- und E/A-Speicher-Befehle legt die Buseinheit auch das Zugriffs-Schlüssel- und das dynamische Adressenübersetzungs-Bit auf den Key-Status-Bus. Nach Abschluß des Befehls wird der Status auf dem gleichen Bus an die anfordernde Buseinheit zurückgegeben.
Der Adapter 154 gibt CPU-Speicher-Befehle und E/A-Speicher- Befehle aus während PE85 nur CPU-Speicher-Befehle ausgeben kann. Diese Befehlsgruppen sind wie folgt:
E/A-Speicherbefehle werden im Cache-Controller 153 ausgeführt ohne Überprüfen der S/370 Hauptspeicheradresse. Diese Prüfung wird in STCI 155 durchgeführt. CPU Speicherbefehle werden zur Ausführung an den Controller 153 gerichtet und haben ein Ein- Byte-Befehlsfeld und ein Drei-Byte-Feld für reale oder virtuelle Adressen. Die Befehlsfeld-Bits sind wie folgt:

CMD-Bit Bedeutung

0-1 = 10 CPU-Speicher-Befehl
2 = 1 Abrufoperation
2 = 0 Speicheroperation
3 = 1 Cache-Bypass, keine Adressenprüfung
3 = 0 Cache-Zugriff mit Adresse/Prüfung:
- S/370 Adresse vergleichen
- ACB-Prüfung
4 = 1 kein DLAT-Zugriff; d. h.
- keine Key-gesteuerte Schutzprüfung
- keine Bezugs- und Änderungs-Bit-Handhabung
DLAT-Zugriff; d. h.
- Key-gesteuerte Schutzprüfung
- Bezugs- und Änderungs-Bit-Handhabung
5-7 = nnn Bytelängenzählung:
0 0 0 = 1 Byte
0 0 1 = 2 Bytes
0 1 0 = 3 Bytes
0 1 1 = 8 Bytes
1 0 0 = 8 Bytes
1 0 1 = 64 Bytes
1 1 0 = 64 Bytes HOLEN! langsam vom BSM
1 1 1 = 64 Bytes HOLEN! langsam vom Adapter
Beispiele für CPU Speicherbefehle sind:
1. Holen (10111nnn)/speichern (10011nnn) Real N Byte, holen oder speichern bis zu 64 Byte aus/in Speicher 162 mit einer realen Adresse.
2. Holen (101010nn)/speichern (100010nn) Cache Real N Byte zum Lesen/Schreiben bis zu 4 Bytes aus/in Cache mit einer realen Adresse.
3. Holen (101011nn)/speichern (100011nn) Cache Real N Byte zum Lesen/Schreiben bis zu 4 Bytes aus/in IOA mit einer realen Adresse (100000nn).
4. Holen (101000nn)/speichern (100000nn) Cache Virtual N Byte zum Lesen/Schreiben bis zu 4 Bytes aus/in Cache mit einer virtuellen Adresse.
E/A-Speicherbefehle werden vom Adapter 154 eingeleitet und an den Cache-Controller 153 gerichtet. Sie übertragen Datenketten von 1-64 Bytes Länge in absteigender Adressenfolge. Das 32-Bit Befehlsformat beinhaltet eine reale Byte-Adresse in den drei niederwertigen Bytes, und das höherwertige Byte beinhaltet ein höchstwertiges Bit "0", das nächsthöchste Bit definiert eine Abruf- bzw. Speicheroperation, und die restlichen sechs Bits definieren die Länge der Datenübertragung (1-64 Bytes). Datenketten werden auf Wortgrenzen übertragen, abgesehen von der ersten und der letzten Übertragung, die eine Positionsausrichtung auf dem Bus erforderlich machen können.
MMU Befehle werden zur Steuerung des Cache-Controllers 153 und seiner Register, einschließlich DLAT, ACB, Verzeichnis und dergl. benutzt.
Mit Meldungsbefehlen werden Meldungen zwischen den Buseinheiten übertragen, die an den Bus 151 angeschlossen sind.

S/370 Speicher-Verwaltungseinheit 81

1. Cache-Controller 153 (Fig. 31)

Der Cache-Controller 153 (Fig. 31) beinhaltet den Cache- Speicher 340 und die Adressierungs- und Vergleichs-Logik 347, 348, einen Abruf-Ausrichter 343 sowie die Verzeichnisnachschlagtabelle (Directory Look-Aside Table -DLAT) 341 zur schnellen Adressenübersetzung. Der Controller 153 akzeptiert virtuelle Adressen und Speicherbefehle vom Prozessorbus 170 und überträgt Abruf- oder Speicherbefehle zur Speichersteuerungs-Schnittstelle 155 (Fig. 11) über den Multiplexer 349 und den STC-Bus 157, wenn er die Anforderung nicht über den Cache-Speicher 340 ausführen kann.
Die DLAT 341 übernimmt die schnelle Übersetzung der virtuellen Seitenadressen in reale Seitenadressen. Ihre 2 · 32 Einträge enthalten 64 vor-übersetzte Seitenadressen. Die DLAT 341 wird angesprochen über ein 2-Weg-Satz assoziatives Adressenschema. Die virtuelle Seitengröße ist vorzugsweise 4ER. Im Falle keines Eintrags in der DLAT wird PE85 unterbrochen und die virtuelle Adressenübersetzung wird von einem Mikroprogramm unter Verwendung von Segment- und Seitentabellen (nicht gezeigt) im S/370 Hauptspeicher 162 auf wohlbekannte Weise vorgenommen. Die DLAT 341 wird dann aktualisiert, um die neue virtuelle und reale Seitenadresse der aus dem Speicher geholten und in den Cache gelegten Information wiederzugeben. Eine Kopie des Speicherschlüssels wird aus dem S/370 Schlüsselspeicher geholt und in den DLAT Eintrag aufgenommen.
Der 8kB Cache 340 mit seinem zugeordneten Cacheverzeichnis 342 sieht einen Hochgeschwindigkeitspuffer vor, um die Prozessorleistung signifikant zu verbessern. Daten und Verzeichnismatrizen sind in vier Fächer aufgeteilt. Jedes Fach im Cache ist in 256 · 8B (Bytes) organisiert. Zum Abrufen von Daten aus dem Cache 340 wird der Byte-Offset in der virtuellen Adresse benutzt, um gleichzeitig die DLAT 341, das Cache- Verzeichnis 342 und den Cache 340 anzusprechen. Schlüsselgesteuerte Schutzüberprüfung wird ausgeführt vom Vergleichsschaltkreis 345, der den Speicherschlüssel im angewählten DLAT-Eintrag benutzt. 4 · 8B Daten werden am Ausgang 340a des Cache 340 zwischengespeichert. Wenn die angeforderten Daten im Cache 340 sind, wird ein Spätanwahlsignal benutzt, um die richtigen Bytes in den Abrufausricher 343 einzuspeisen.
Für Speicheroperationen wird eine Teilspeicherung auf Bytebasis ausgeführt.
Im Falle keines Eintrags im Cache gibt der Cache-Controller 153 automatisch einen BSM-Befehl aus, um die angeforderte 64B Cachezeile im Blockbetrieb abzurufen. Wenn die durch die neue Cachezeile zu ersetzende Cachezeile seit ihrem Laden verändert wurde, wird eine Cachezeilen-Auswurfoperation zum Speicher 162 eingeleitet, bevor die neue Cachezeile geladen wird. E/A-Daten bewirken nie Cache-Zeilen-Ausgabe- und Ladeoperationen. E/A-Daten, die vom Speicher 162 abgerufen werden, werden sowohl im Hauptspeicher 162 als auch im Cache-Speicher 340 durch Zugriff auf beide Vorrichtungen gesucht. Wenn die Daten im Cache gefunden werden, wird die Speicheroperation abgebrochen, und der Cache-Speicher liefert die Daten. Wenn die E/A-Daten nicht im Cache sind, werden sie direkt aus dem Speicher geholt, aber keine Cache-Zeile wird ersetzt. E/A- Daten, die im Speicher gespeichert werden sollen, werden im Cache 340 gespeichert, wenn die adressierte Zeile bereits im Cache ist; ansonsten werden sie direkt im Speicher 162 abgespeichert.
Der 4kB Schlüsselspeicher 344 enthält die Speicherschlüssel für 16 MB Speicher. Der Schlüsselspeicher ist eine Matrix, die 4K · 8 organisiert ist. Jedes Byte enthält einen Speicherschlüssel. Jeder DLAT-Eintrag enthält eine Kopie des Speicherschlüssels mit einer ihm zugeordneten 4kB-Block- Adresse. Das reduziert signifikant die Anzahl der Zugriffe auf den Schlüsselspeicher, wenn sich der Seitenzugriff wiederholt. Änderungen in der Speicherschlüsselzuordnung betreffen sowohl den Schlüsselspeicher als auch jede Kopie im Cache-Speicher.
Befehle, Daten und Adressen, die vom Prozessor-Bus 170 her über die Empfängerschaltung 355 beim Cache-Controller 153 an kommen, werden in den Befehls-, Daten- und Adressenregistern 250, 351 und 352 gespeichert. Adressenregister 347 speichert den Bereich gültiger Adressen für das zugehörige S/370 Prozessorelement PE85. Die Vergleicher-Logik 348 überprüft die Gültigkeit der eingegangenen Adresse. Die S/370 Adressenvergleichsfunktion, die vom Adressenregister 347 und von ihm zugehörigen Vergleichslogik 348 eingehende Adressen vergleicht, behandelt Adressen sowohl vom PE85 als auch vom E/A-Bus- Adapter 154.
Die Vergleichsfunktion für das Adressen-Vergleichs-Grenz- Register 353 (Address Compare Boundary - ACB) stellt sicher, daß S/370 Hauptspeicher Hinweise, die für den Kundenbereich bestimmt sind, nicht den IOA-Bereich adressieren. Das ACB- Register 353 speichert die Teilerlinie (Grenze) zwischen dem reservierten IOA-Bereich und dem nichtreservierten Bereich im S/370 Speicher 162. Jeder Zugriff auf den S/370 Speicher führt in der Vergleichslogik 354 dazu, daß die eingegangene Adresse mit dem ACB-Wert verglichen wird.

2. STCI 155 (Fig. 32A, B)

(a) Einführung

Die Speichersteuerungs-Schnittstelle (Storage Control Interface - STCI) 155 verbindet den S/370 Chip-Satz 150 mit dem S/88 Duplex-fehlertoleranten Speicher 16, 18 über die Bus- Logik 178 und den Systembus 30 (Fig. 1). Sie unterstützt alle S/370 Prozessor- und E/A-Speicher/Abruf-Befehle, die Datenübertragungen von 1-64 Bytes je Befehl definieren. Alle ECC, Auffrischungen, Speicher-Initialisierungen und -konfigurierungen, Wiederholungen usw. werden vom S/88 Prozessor 62 und vom Speicher 16, 18 gehandhabt. Ein detaillierter Datenfluß der STCI 155 wird in Fig. 32A, B gezeigt.
Die STCI 155, ihre gepaarte STCI 155a (nicht dargestellt) in einer Speicherverwaltungseinheit 83 und ihr entsprechendes STCI-Paar (nicht dargestellt) in der Partnereinheit 23 (Fig. 8), verteilen zusammen die Steuerung der Systembusstruktur 30 über die Prioritätsbestimmung, wie z. B. durch die Logik 408 (Fig. 32B) in jeder STCI. Nicht nur entscheidet die STCI gegen E/A-Controller und andere CPUs 25, 27 und 29, 31 des Moduls 9, wie in Fig. 7 dargestellt ist, sondern die STCI muß auch gegen ihren zugeordneten S/88 Prozessor 62 (und die gepaarten Partnerprozessoren des Prozessors in den CPUs 21, 23 der Fig. 8) entscheiden, die möglicherweise die Bussteuerung für S/370 E/A-Funktionen oder herkömmliche S/88 Funktionen anfordern.
Andererseits ist die Prioritätsverteilerlogik im allgemeinen ähnlich derjenigen, die in US-Patent Nr. 4, 453,215 beschrieben ist und die sich hauptsächlich auf Modulrückwand- Schlitzpositionen der Prozessor- und E/A-Boards gründet, und diese Logik soll jetzt beschrieben werden. Während einer Prioritätsverteilungsphase legt jede Einheit des Prozessormoduls 9, die in der Lage ist, ein Bus-Master zu sein, und die bereit ist, einen Buszyklus einzuleiten, die Priorität für die Anwendung der Busstruktur fest. Die Einheit tut das durch Ansteuern eines Bus-Zyklus-Request-Signals und gleichzeitig Überprüfen, über ein Prioritätsfestlegungs-Netzwerk, ob es Einheiten mit einer höheren Priorität gibt, die ebenfalls eine Bus-Zyklus-Request ansteuern. Die Einheit, bzw. das Paar der Partnereinheiten, das erfolgreich ist beim Gewinnen des Zugriffs auf die Busstruktur während der Prioritätsfestlegungsphase, heißt Bus-Master und beginnt während der nächsten Taktphase einen Übertragungszyklus. Eine Speichereinheit 16, 18 ist nie ein Master und legt keine Prioritäten fest.
Während der Definitionsphase eines Zyklus definiert diejenige Einheit, die als Bus-Master für diesen Zyklus bestimmt wurde, den Zyklustyp durch Erzeugen eines Satzes Zyklusdefinitionen oder Funktionssignalen. Der Bus-Master steuert auch die Adressensignale an und legt gerader Parität auf die Adressenparitätsleitung für die Adressen und Funktionssignale. Alle Einheiten des Prozessormoduls nehmen, ungeachtet ihres internen Betriebszustands, immer die Signale auf den Busleitern auf, die die Funktions- und Adressensignale tragen, obwohl periphere Steuereinheiten auch ohne den Eingang von Prioritätssignalen arbeiten können. Der zu definierende Zyklus wird abgebrochen, wenn während dieser Zeit ein Signal 'Bus-Wait' gesetzt wird.
Während der Antwortphase kann jede angesprochene Einheit des Systems, die gerade 'busy' ist, das Signal Bus-Busy auflegen, um den Zyklus zu unterbrechen. Eine Speichereinheit kann z. B. ein Bus-Busy-Signal auflegen, wenn sie angesteuert wird, während sie besetzt ist oder gerade einen Wiederauffrischzyklus durchführt. Ein Bus-Fehler-Signal, das während der Antwortphase aufgelegt wird, unterbricht den Zyklus, weil der Fehler in der Adresse vorkommen kann, die in der Definitionsphase des Zyklus angesprochen wurde. Daten werden während der Datenübertragungsphase sowohl über den A-Bus als auch über den B-Bus, sowohl für Lese- als auch Schreibzyklen übertragen. Das setzt das System in die Lage, eine Mischung aus Lesezyklen und Schreibzyklen in Warteschlange auf die Busstruktur zu legen, ohne Rückgriff auf neue Prioritätsfestlegung zur Verwendung der Datenleitungen und ohne Daten nach Quelleneinheit oder Zieleinheit 'Tag'-kennzeichnen zu müssen.
Vollwort-Übertragungen werden begleitet vom Auflegen sowohl von UDS- als auch LDS-Signalen (obere und untere Daten- Strobes). Halbwort- oder Byte-Übertragungen werden definiert als Übertragungen, die vom Auflegen nur eines dieser Strobe- Signale definiert sind. Schreibübertragungen können durch den Bus-Master schon früh im Zyklus abgebrochen werden, nur durch Auflegen keines der Strobe-Signale. Slave-Einheiten, die gelesen werden, müssen mit den Daten die Strobe-Signale auflegen. Die Strobe-Signale sind in der Berechnung der Bus- Datenparität enthalten.
Während der Datenübertragungsphase entdeckte Fehler bewirken, daß die Einheit, die den Fehler entdeckt, eines oder beide Bus-Fehler-Signale in der nächsten Taktphase, die die erste Nach-Daten-Phase ist, auflegt. Die peripheren Steuereinheiten warten, ob ein Fehler auftritt, bevor sie die Daten benutzen. Die zentrale Prozessoreinheit 21 und die Hauptspeichereinheit 16 des Systems benutzen jedoch die Daten sobald sie eingehen, und im Falle eines Fehlers machen sie eine Sicherungsspeicherung und warten auf die richtigen Daten. Das Auflegen eines Bus-Fehler-Signals während der Nach-Daten-Phase bewirkt, daß die Übertragungsphase in der nächsten, der sechsten Phase des Übertragungszyklus wiederholt wird. Das bricht den Zyklus ggf. ab, der sonst während der zweiten Nach-Daten-Phase, d.i. der sechsten Phase, Daten auf der Busstruktur übermittelt hätte.
Der normale Rückwandplatinen-Betriebsmodus des gezeigten Systems ist, wenn alle Einheiten im 'Ausführung-Beide'-Modus stehen, in dem sowohl der A-Bus als auch der B-Bus offensichtlich fehlerfrei sind. Als Antwort auf einen Fehler auf dem A-Bus, z. B., schalten alle Einheiten synchron auf den 'Ausführung-B'-Modus um. Das Modul 9 schaltet mittels einer Überwachungs-Software, die in einer S/88 Zentralprozessoreinheit läuft, wieder auf den 'Ausführung-Beide'-Betriebsmodus um.
Sowohl im 'Ausführung-B'- als auch im 'Ausführungs-A'- Betriebsmodus werden sowohl der A-Bus als auch der B-Bus von Systemeinheiten getrieben, und alle Einheiten führen noch immer eine volle Fehlerprüfung durch. Der einzige Unterschied zum Betrieb im 'Ausführung-Beide'-Modus ist, daß die Einheiten weitere Fehler nur mehr auf einem Bus auflisten, der nicht befolgt wird, ohne daß Daten wiederholt werden müssen und ohne Abbruch eines Zyklus. Ein Bus-Fehler-Signal auf dem befolgten Bus jedoch wird wie oben gehandhabt und bewirkt, daß alle Einheiten auf Befolgen des anderen Busses umschalten.

(b) Systembusphasen

Fig. 33 zeigt die obige Operation mit vier Pipeline-Multiple- Phasen-Transferzyklen auf der Busstruktur 30 für das Modul 9. Wellenformen 56a und 56b zeigen die S/88 Master-Takt- und Master Synchronisations-Signale, die der Taktgeber 38 für einundzwanzig aufeinanderfolgenden Taktphasen, beziffert (1) bis (21), wie oben in der Zeichnung angegeben ist, auf den X- Bus 46 legt. Die Verteilersignale auf der Busstruktur, die durch die Wellenformen 58a dargestellt sind, verändern sich beim Anlaufen jeder Taktphase, um in jeder der dargestellten einundzwanzig Phasen die Prioritätsverteilung für einen neuen Zyklus, dargestellt durch die Zyklusnumerierungslegende #1, #2, #3 ... #21 einzuleiten. Fig. 33 repräsentiert die Zyklus- Definitionssignale mit Wellenform 58b. Die Zyklusdefinitionssignale für die einzelnen Zyklen kommen eine Taktphase später als die Prioritätszuteilungssignale für diesen Zyklus, wie mit den Zyklusnummern auf der Wellenform 58b ersichtlich wird. Die Zeichnung stellt ferner die Busy-, Wait-, Daten-, A-Bus-Fehler- und B-Bus-Fehler-Signale dar. Die unterste Reihe in der Zeichnung zeigt den Rückwandplatinen-Modus, in dem das System arbeitet, und zeigt die Übergänge zwischen den unterschiedlichen Modi an.
Unter weiterer Bezugnahme auf Fig. 33 erzeugt das Modul 9 während der Taktphasen-Zahl (1) die Zyklus-Prioritätsverteilungs-Signale für Zyklus #1. Das System arbeitet im 'Ausführung-Beide'-Modus wie gezeigt. Die während der Zyklusprioritäts-Verteilungs-Phase (1) bestimmte Bus-Master- Einheit definiert den während der Taktphase (2) durchzuführenden Zyklus, wie mit Legende #1 auf der Zyklus definitionssignal-Wellenform 58b gekennzeichnet ist. Auch in der Taktphase (2) wird die Prioritätsbestimmung für einen zweiten Zyklus, Zyklus #2, durchgeführt.
Während der Taktphase (3) liegt kein Anwortsignal auf der Busstruktur für Zyklus #1, was anzeigt, daß dieser Zyklus für eine Datenübertragung bereit ist, wie sie während der Taktphase (4) auftritt und wie mit Legende #1 auf der Daten- Wellenform 58e gekennzeichnet ist. Auch während der Taktphase (3) wird die Zyklusdefinition für Zyklus #2 und auch die Prioritätszuteilung für einen weiteren Zyklus #3 durchgeführt.
In der Taktphase (4) werden die Daten für den Zyklus #1 übertragen, und die Definition für Zyklus #3 wird ausgeführt. Auch wird während dieser Taktphase ein Bus-A-Fehler aufgelegt, wie mit Wellenform 58f angezeigt wird. Ein Fehlersignal bricht Zyklus #2 ab und schaltet alle Einheiten im Modul auf den 'Ausführung-B'-Modus um. Das Bus-A-Fehlersignal der Taktphase (4) zeigt an, daß in der vorhergehenden Taktphase (3) mindestens eine Systemeinheit einen Fehler betreffend die Signale vom A-Bus 42 entdeckt hat. Der Fehler erfolgte, während keine Daten auf der Bus-Struktur lagen, wie durch das Fehlen von Daten in der Wellenform 58e während der Taktphase (3) angezeigt wird, und daher gibt es auch keine Notwendigkeit, den Datentransfer zu wiederholen.
Während der Taktphase (5), wobei das System im 'Ausführen-B'- Modus arbeitet, wird ein fünfter Zyklus prioritätsverteilt, die Funktion für Zyklus #4 wird definiert, und kein Antwortsignal liegt auf der Busstruktur für Zyklus #3. Dementsprechend fährt dieser Zyklus während der Taktphase (6) mit der Datenübertragung fort. Auch in Taktphase (6) wird ein Bus-Wait aufgelegt, wie aus Wellenform 58d ersichtlich ist; das steht im Zusammenhang mit Zyklus #4. Die Wirkung ist, das dieser Zyklus für eine weitere Taktphase verlängert und Zyklus #5 abgebrochen wird.
Ein neuer Zyklus #7 wird in der Taktphase (7) prioritätsverteilt und die Definitionsoperation geht auf Zyklus #6 über. In Taktphase (8) werden die Daten für den Zyklus #4 auf die Busstruktur zur Übertragung gelegt. Auch in der Taktphase (8) wird ein Busy-Signal aufgelegt. Dieses Signal ist Teil der Antwort für Zyklus #6 und bricht diesen Zyklus ab.
Die Verteilungs- und Definitionsoperationen in der Taktphase (9) folgen dem gleichen Muster, wodurch ein anderer Bus-A- Fehler aufgelegt wird. Das System arbeitet bereits im 'Ausführen-B'-Modus und daher ist die Antwort auf dieses Signal ganz einfach das Auflisten des Fehlers.
Das Signal Bus Wait, das in der ersten Phase (10) aufgelegt wird und in die Taktphase (11) übergeht, erweitert den Zyklus #8 um zwei weitere Taktphasen, so daß die Daten für diesen Zyklus während der Taktphase (13) übertragen werden, wie angegeben. Das während dieser Phase aufgelegte Signal 'Bus Wait' bricht auch die Zyklen #9 und #10 ab, wie gezeigt. Jedes Busy Signal, das während der Phasen (10), (11) oder (12) im Hinblick auf die Erweiterung des Zyklus #8 vom Wait Signal aufgelegt wird, würde Zyklus #8 abbrechen. Hier ist anzumerken, daß die Datenübertragung für den Zyklus #7 in der Takt phase (10) stattfindet, unabhängig von den Signalen auf den Wait- und Busy-Leitungen während dieser Taktphase.
Weitere Bus-A-Fehlersignale, die während der Taktphasen (11), (12) und (14) auftreten, haben wiederum keine Auswirkung auf das System, abgesehen davon, daß sie aufgezeichnet werden, weil das Systeme bereits im 'Ausführen-B'-Modus arbeitet. Das während der Taktphase (14) aufgelegte Signal bricht Zyklus #13 ab. Es erweitert ferner Zyklus #12, der jedoch vom Busy Signal abgebrochen wird, das während der Taktphase (14) aufgelegt wird. Die Daten für den Zyklus #11 werden in normaler Sequenz während der Taktphase (14) übertragen. Ferner erfolgt der Datentransfer für den Zyklus # 14 in der Taktphase (17).
In der Taktphase (19), unmittelbar nach dem Datentransfer der Taktphase (18), wird ein Bus-B-Fehler aufgelegt. Dieses Fehler-Signal bricht Zyklus #17 ab, der in der Antwortphase liegt, und initiiert eine Wiederholung des Datentransfers für den Zyklus #15. Dieser Wiederholtransfer erfolgt während des Zyklus #20. Ferner schaltet dieses Fehlersignal das Modul auf den 'Ausführen-A'-Modus um.
Hier ist anzumerken, daß das Bus-Wait-Signal nur von Slave- Einheiten getrieben wird, die von einer Bus-Mastereinheit angesprochen wurden und die nicht zur Datenübertragung bereit sind. Da die STCI 155 nie eine Slave-Einheit ist und nur Speicher anspricht und keine E/A-Vorrichtungen, wird diese Leitung von der STCI 155 nicht benutzt.
Die Systembus-Logik 178 (Fig. 19C) bildet das Verbindungsglied von der STCI 155 zu den S/88 Speicherboards 16, 18 und beinhaltet die Prioritätsverteilerlogik 408 (Fig. 32B). Die gleichen, oben für den Bus 30 definierten Basisübertragungszyklen werden von der Logik 178 benutzt:
1. Prioritätsverteilerphase - Diese Phase läuft in jedem Zyklus ab, wenn die Bus-Controller um die Busherrschaft streiten. In der Regel basiert die Verteilerpriorität auf der Rückwandschlitz-ID der Verteilervorrichtungen. Für die bevorzugte Form der STCI-Konstruktion gründet sich die Verteilungspriorität auf die Schlitz-ID für Einzel-CPUs unter Verwendung der FIFO-Fast-voll/Fast-leer-(AFE)-Flag- und der Halbvoll-(HF)-Flag-Leitungen 409 auf jeder CPU (PE 85 und ihrer gepaarten Einheit), um Prioritäten auf der Grundlage der realen Aufgabenanforderung in Mehrfach-CPU-Implementierungen zuzuweisen.
2. Zyklusdefinitionsphase - Diese Phase folgt einer Buszuteilung im vorherigen Zyklus. Sie beinhaltet einen 4- Bit-Funktionscode auf den Bus Fn Code A und B des Busses 30, um 16-, 32- oder 64-Bit-R/W-Transfers zusammen mit der 27-Bit physikalischen Anfangsadresse im Speicher 16 zu spezifizieren. Speicher 16 hat für die bevorzugte Ausführungsform 256MB. Alle Speicherzugriffe sind auf 16-, 32- oder 64-Bit- Grenzen, so daß die Adresse 0 nicht benutzt wird. Vielmehr werden Byte- und Wort-Zugriffe von den UDS, LDS Signalen, die in Fig. 14 dargestellt sind, zusammen mit der Bus FN-Code- Definition angezeigt.
3. Zyklus-Antwortphase - Diese Phase kann einen Bus- Fehler- oder Bus-Busy-Zustand auf Bus 30 vom Speicher beinhalten, der die STCI 155 zwingt, die Prioritäten neu festzulegen und die frühere Zyklusdefinitionsphase neu auszugeben.
4. Datenphase - Sobald die Speicheranforderung akzeptiert ist (nach der Zyklusantwortphase), tritt im Zyklus nach der Zyklusantwortphase (2 Zyklen nach der Zyklusdefinitionsphase) die Datenphase auf. 16-, 32- oder 64-Datenbits können innerhalb einer 125 ns Phase zum Lesen oder Schreiben übertragen werden.
5. Nach-Datenphase - Diese ist erforderlich, um nach Busfehlern zu suchen, die eine Wiederholung der Daten (entweder von der STCI 155 oder vom Speicher 16) auf dem Systembus 30 erzwingen würden, zwei Zyklen nach der ersten Datenübertragung. Da Bus A und Bus B identische Daten tragen, können während der Nach-Datenphasen A- oder B-Bus-Fehler auftreten.
Ein bedeutsamer Unterschied zwischen dem S/88 Prozessor 62 bei Festlegung der Priorität für den Bus 30, und der STCI 155 bei Festlegung der Priorität für den Bus 30 soll jetzt beschrieben werden. In der Regel wird ein S/88 Prozessor 62 zu einem bestimmten Zeitpunkt in nur einer der fünf Phasen betrieben. Aber infolge der (nachstehend beschriebenen) Abruf- und Speicher-Pipeline-Kapazität in der STCI 155 kann die STCI in bis zu allen 5 Phasen gleichzeitig arbeiten. Z. B. kann während einer 64-Byte-Leseoperation die STCI 155 gleichzeitig in allen fünf Phasen betrieben werden, wenn keine Fehler vorliegen und die STCI die Prioritätssteuerung des Busses 30 in jedem der fünf aufeinanderfolgenden Zyklen hat. Das verbessert die Systemleistung, besonders in einer Einprozessorversion eines Moduls 9.

(c) STCI Merkmale

Nachstehend werden einige der STCI-Merkmale beschrieben:
1. FIFO 400 - Vier (64 · 9 Bit) First-In-First-Out schnelle RAMs bilden einen Puffer, damit bis zu 64-Byte- Speicherbefehle festgehalten werden können, bevor die Einheit 155 busy geht. Er trägt auch die ankommende Parität für alle Daten zu den Ausgängen. Der S/370 Taktgeber 152 taktet Befehle und Daten in den FIFO 400; der S/88 Taktgeber 38 taktet Befehle und Daten aus dem FIFO 400. Eine bevorzugte Ausführungsform des FIFO 400 ist der CY7C409, der im Produkt- Informationshandbuch, veröffentlicht am 15. Januar 1988 von der Cypress Semiconductor Corp., ab der Seite 5-34 näher beschrieben ist.
Zusätzlich zu den gewerblichen Standard-Handshake-Signalen sind Fast-voll/Fast-leer (AFE) sowie Halbvoll (HF) Flags vorgesehen. AFE liegt hoch, wenn der FIFO nahezu voll oder nahezu leer ist. Sonst liegt AFE tief. HF liegt hoch, wenn der FIFO halb voll ist, sonst liegt HF tief.
Der Speicher akzeptiert 9-Bit Parallelwörter an seinen Eingängen unter der Steuerung des Shift-In (SI) Eingangs, wenn das Input-Ready (IR) Steuersignal hoch liegt. Die Daten werden in der gleichen Reihenfolge ausgegeben, in der sie unter der Steuerung des Shift-Out (SO) Eingangs gespeichert wurden, wenn das Output-Ready (OR) Steuersignal hoch liegt. Wenn der FIFO voll ist (IR tief), werden Impulse am SI-Eingang ignoriert; wenn der FIFO leer ist (OR tief), werden Impulse am SO-Eingang ignoriert.
Parallel-Erweiterung für breitere Wörter wird implementiert durch logische UND-Verbindung des IR- und des OR-Ausgangs (entsprechend) der einzelnen FIFOs zusammen. Die UND-Operation stellt sicher, daß alle FIFOs entweder bereit zur Aufnahme weiterer Daten (IR hoch) oder zur Ausgabe von Daten (OR hoch) sind, und kompensieren auf diese Weise Veränderungen in den Fortpflanzungsverzögerungszeiten zwischen den Vorrichtungen.
Lese und Schreiboperationen laufen völlig asynchron, und ermöglichen, daß der FIFO als Puffer zwischen zwei digitalen Maschinen weitgehend unterschiedlicher Betriebstaktfrequenzen oder Taktphasen benutzt wird. Der FIFO 400 beinhaltet einen Schreibzeiger, einen Lesezeiger und die Steuerlogik, die erforderlich ist, um bekannte Handshake (SI/IR, SO/OR) Signale sowie auch die Fast-voll/Fast-leer (AFE) und Halbvoll (HF) Flags zu generieren. Bei leerem FIFO hält die STCI-Logik SO hoch, so daß, wenn ein Wort geschrieben wird, es direkt durch zum Ausgang läuft. Das OR-Signal geht für einen internen Zyklus hoch und wird dann wieder tief. Wenn mehr Wörter in den FIFO geschrieben werden, reihen sie sich hinter dem erste Wort ein und erscheinen nicht an den Ausgängen, bis SO tief gesetzt wird.
Die Daten werden nicht physikalisch durch den Speicher geschoben. Der Lese- und der Schreib-Zeiger werden inkrementiert anstatt die Daten zu verschieben. Die Zeit, die zum Inkrementieren des Schreibzeigers und ein Signal vom SI Eingang zum OR Ausgang eines leeren FIFO (Durchfallzeit) zu verschieben, bzw. die Zeit, die zum Inkrementieren des Lesezeigers und ein Signal vom SO Eingang zum IR Ausgang eines vollen FIFO zu verschieben (Durchblubberzeit) erforderlich ist, bestimmt die Geschwindigkeit, mit der Daten durch den FIFO 4300 transportiert werden können.
Beim Einschalten wird der FIFO mit einem Master-Reset-Signal rückgestellt. Das bewirkt, daß die Vorrichtung den Leerzustand einnimmt, der dadurch gekennzeichnet ist, daß das OR- Signal tief und gleichzeitig das IR-Signal hoch liegt. In diesem Zustand liegen die Daten-Ausgänge (D00-D08) tief. Das AFE-Flag liegt hoch und das HF-Flag liegt tief.
Die Verfügbarkeit eines leeren Platzes wird angezeigt durch den Hoch-Zustand des Input-Ready (IR) Signals, wenn IR hoch liegt wird ein Tief-nach-Hoch-Übergang auf dem Shift-In (SI) Kontakt die Daten auf die Eingänge in den FIFO 400 laden. Der IR-Ausgang geht dann tief und zeigt an, daß die Daten in Abschnitte zerlegt sind. Der Hoch-Tief-Übergang des SI Signals leitet den Tief-Hoch-Übergang des IR Signals ein sowie auch den Tief-Hoch-Übergang des AFE-Flag, wenn der FIFO 400 fast voll oder fast leer ist.
Die Verfügbarkeit von Daten an den Ausgängen des FIFO 400 wird angezeigt durch Hochliegen des Output Ready (OR) Signals. Nach Rückstellen des FIFO liegen auch alle Datenausgänge (D00-D08) tief. Solange der FIFO leer bleibt, bleibt das OR Signal tief und alle Shift Out (SO) Impulse werden ignoriert. Nach Einschieben von Daten in den FIFO geht das OR Signal hoch.
Zwei Flags, Fast-voll/Fast-leer (AFE) und Halbvoll (FH), zeigen, wie viele Wärter im FIFO gespeichert sind. AFE liegt hoch, wenn nicht mehr als 8 bzw. nicht weniger als 56 Wörter im FIFO gespeichert sind. Sonst liegt das AFE Flag tief. HF liegt hoch, wenn mindestens 32 Wörter im FIFO gespeichert sind, sonst liegt das HF Flag tief. Die Flagübergänge erfolgen bei abfallenden Flanken des SI und SO.
2. SBI Logik - System/88-Bus-Schnittstellen-(SBI)- Logik 178 ermöglicht es, daß der S/370 Prozessor 85 Lese/Schreibvorgänge zum S/88 Speicher 16 initiiert. Sie beinhaltet die Logik 408 zum Verteilen der Priorität für jeden Zyklus beim Zugriff auf den Bus 30, um 16, 32 oder 64-Bit- Übertragungen einzuleiten. Die Logik-178-Schnittstellen- Leitungen und die Verteilungslogik sind vorzugsweise von dem Typ, wie er im Reid-Patent beschrieben ist, soweit sie nicht verändert werden, wie hier beschrieben wird.
3. Fehlertoleranz - Alle STCI-Logik, einschließlich FIFO-Puffer 400, wird gedoppelt, um eine Selbstkontrolle auf dem S/370 Prozessor-Board vorzusehen. Die einzige Einfach- Logik beinhaltet die Vergleicherlogik 402 a-g, die gebrochene Logik 403, und die Taktgenerierungslogik (nicht dargestellt). So hat die STCI 155 eine im wesentlichen gepaarte STCI 155a (nicht dargestellt), die ein Teil der Speicherverwaltungseinheit 83 in Fig. 8 ist.
Die Vergleicherlogik 402 a-g bildet die Vergleichslogik 15 in Figur, und die gebrochene Logik 403 bildet einen Teil der allgemeinen Steuerlogik 75 in Fig. 8. In der bevorzugten Ausführungsform wird die S/370 Vergleichsprüfung nur an den gepaarten STCIs 155, 155a durchgeführt, um gegen die Weiterverbreitung fehlerhaften Daten über die Busstruktur 30 geschutzt zu sein. Jedoch werden S/370 Maschinenprüfungen und Paritatsfehler über den Bus 460 an die Logik 403 gegeben. Einige Fehler auf den BCU-Bussen 247, 223 werden von den S/88 Vergleichsschaltungen 12f (Fig. 8) erfaßt.
4. Adressenprüfung - Zwei im Speicher abgebildete Register 404, 405 (MEM Base & MEM Size) sind vorgesehen, um sicherzustellen, daß die Große jedes S/370 Prozessorspeicherplatzes, wie 162, wahrend der Anwendung eines Basis-Offsets (Fig. 10), um eine gültige physikalischen S/370 Anwenderadresse im System/88-Speicher 16 zu generieren, nicht verletzt wird.
5. Synchronoperationen - S/370 Takte 152 werden vom 16 MHz Eingang des S/88 Taktgebers 38 (Fig. 7) über den Bus 30 und die Synchronisierlogik 158 (Fig. 19C) abgeleitet, um die Synchronisierung zwischen den Takten innerhalb einer S/370 Oszillator-Eingangstaktperiode vom Start des S/88 Taktgebers 38 zu ermöglichen. Das laßt zu, daß aufeinanderfolgende Lesevorgänge (z. B. ein 64-Byte-Lesebefehl) vom Speicher 162 zum S/370 Chipsatz ohne Wartezustand dazwischen (unter der Annahme, daß aufeinanderfolgende Zyklen zur STCI 155 auf dem Systembus 30 zugelassen wurden) in die Pipeline gesetzt werden.
6. STC Busschnittstelle - Alle Standard-S/370- Abruf/Speicher-Befehle werden zusammen mit Befehlsabbruch ausgeführt. Paritätsfehler und/oder ECC Fehler werden nicht an das S/370 Betriebssystem berichtet, sondern vielmehr als erneute Versuche behandelt (ECC oder Bus-Paritätsfehler) oder gehen zu Bruch (interne Board-Paritätsfehler). Überschreitungen der 64-Byte-Grenzlinie führen zu einem Adressenüberlauf auf die erste Zeile.
Wie in Fig. 11 gezeigt wird, bildet die STCI 155 die Schnittstelle zum S/370 Prozessor 85 über die Cache-Controller- Einheit 153, die die S/370 dynamische (virtuelle) Adressenübersetzung unter Verwendung eines 8kB Anweisungs-Daten-Cache 340 und einer 64-Eintrag-DLAT 341 (Verzeichnis-Nachschlagtabelle) vornimmt. Auf diese Weise führt jeder reale/virtuelle E/A- oder Prozessor-Tranfer zu einer 'realen' Adresse, die von der Einheit 153 auf dem STC-Bus 157 ausgegeben wird. In der Regel wirkt die Einheit 153, wenn der Bus-Adapter 154 oder der S/370 Prozessor 85 'reale' Speicheroperationen durchführt, einfach als Übergangsstufe vom Prozessor-Bus 170 zum STC-Bus 157, abgesehen von Cache-Treffern, die dazu führen können, daß ein Befehl abgebrochen wird nachdem er auf den STC-Bus 157 gelegt wurde.
Eine kurze Beschreibung der 41 STC-Busleitungen (Fig. 32A und 30) soll jetzt vorgestellt werden. Der STC Daten/Adressen/Befehls-Bus 406 weist 32 bidirektionale Datenbusleitungen plus ungerade Parität je Byte auf. Dieser Bus wird benutzt, um Befehl und Adresse in einem einzigen Zyklus, und bis zu 32 Datenbits in jedem darauffolgenden Zyklus der Speicheroperationen zu übermitteln. Die STC-Valid-Leitung wird getrieben von der Einheit 153 zur STCI 155, um zu signalisieren, daß ein Befehl/Adresse auf dem STC-Bus im gleichen Zyklus gültig ist. Die STC-Abbruchsleitung wird getrieben von Einheit 153 zur STCI 155, um einen vorher ausgegebenen Befehl abzubrechen. Er kann bis zu 2 Zyklen nach Ausgabe des STC Valid erscheinen. Er wird mit dem PE85 Befehlsabbruchseingang ODER-verknüpft. Die STC-Busy Leitung 440 wird getrieben von STCI 155 zur Einheit 153, einen Zyklus nachdem ein 'STC- Valid' ausgegeben wird, um anzuzeigen, daß die Einheit busy ist und keine neuen Befehle aufnehmen kann. Sie wird freigegeben 1 Zyklus bevor die Einheit 155 in der Lage ist, einen neuen Befehl aufzunehmen.
Ein STC Data Invalid auf Leitung 433 kann von der STCI 155 an die Einheit 153 im gleichen Zyklus ausgegeben werden, in dem auf einen Datenabruf Daten zurückgegeben werden, um die Datenübertragung ungültig zu machen. Die Einheit 153 ignoriert den Datenzyklus, wenn die Leitung aktiviert ist. Diese Leitung wird zusammen mit den Daten gesendet, wenn ein Schnell- ECC-Fehler auf Bus 30 aufgetreten ist, die Daten beim Vergleich zwischen der Logik der gepaarten STCI Einheiten 155, 155a nicht übereinstimmen oder während eines Bus-30-Lesezyklus eine falsche Parität festgestellt wurde.
Die STC-Datenübertragungsleitung 441 wird von der STCI 155 zur Einheit 153 getrieben, um einen Datentransfer auf dem STC-Bus 157 im nachfolgenden Zyklus zu signalisieren. Zum Speichern diktiert sie, daß Einheit 153 das nächste 32-Bit- Wort auf den nächsten Zyklus liefert. Zum Abrufen alarmiert sie Einheit 153, daß der nächste Zyklus gültige Daten enthält, falls er nicht durch ein STC Data Invalid im nächsten Zyklus überschrieben wird. Die STCI 155 Konstruktion ist voll mit Pipeline ausgerüstet, damit alle obigen Zustände innerhalb einer S/370 CPU gleichzeitig aktiv sein können. Auf diese Weise kann unter der Annahme einer kontinuierlichen Buszuteilung und ohne Bus-Fehler die STCI 155 Pipelinedaten auf Aufruf ohne Wartezustände unterhalten unter Verwendung von 64-Bit-Lesevorgängen (je 125 ns System Bus-30-Zyklen) auf dem 32 Bit, 62,5 ns STC-Bus 157.
Die System/88 Schnittstelle 410 wird in der STCI 155 verwendet, um den Zugang zum MEM Size/MEM Basisregister 405 und 404 innerhalb des örtlichen, virtuellen BCU-Adressenspeicherraums zu unterstützen. Auch werden 'Broken' 403 und 'Bus Interrupt Req' (IRQ) Fehler mit denen auf dem S/88 Prozessor-Board 102 zusammengelegt, um einen Wartungs-Interrupt niedriger Priorität auf dem Bus 30 als einzige CPU anzutreiben.
Bus-IRQ-Fehler unterscheiden sich von Broken dadurch, daß diese Fehler, in der Regel verursacht von ungeschützten Signalen vom Bus 30, die von diesen oder vom Partner-Board als abweichend erfaßt werden, ein Board nicht vom Bus 30 abschalten wie es Broken tut. Diese Fehler sind nur aktiv, wenn das Board im 'Ausführen-Beide'-Modus steht.
Zusätzlich werden 'Ausführen-A', 'Ausführen-B' und 'Duplex'- Signale auf den Leitungen 411, 412, 413 von der S/88 Prozessor-Board-Logik 415 hoch gefahren anstatt Neu-Impelementieren innerhalb der S/370 Prozessoren. Ausführen A/Ausführen-B Signale werden benutzt, um die Eingangs-Multiplexer 71, 73 (Fig. 8) für den prüf- und treibseitigen Eingangsmultiplexer entsprechend zu steuern sowie um Busfehlerzustände einzuspeisen. Das Duplex-Signal auf der Leitung 413 wird zum Signalisieren benutzt, wenn Boards gepartnert werden (d. h. in der Busverteilerlogik 408 benutzt, um sicherzustellen, daß beide Partner zusammen verteilen, wenn sie in aufeinanderfolgenden Schlitzen stecken).
Ausführen-A- und -B-Signale werden invertiert, um sowohl +Ausführen-A, -Ausführen-A, +Ausführen-B, als auch -Ausführen-B vorzusehen. Die Signale +Ausführen-A und -Ausführen-A Signale werden an die Register 428 bzw. 429 gelegt. Die Register 428 und 429 werden entsprechend an die A- und B-Busse der Busstruktur 30 gekoppelt. S/88 Taktsignale (nicht dargestellt) takten Daten von den A- und B-Bussen zu den Registern 428 bzw. 429 für alle drei Takt-Modi, A, B und Beide. Daten in Register 428 werden auf die Busse 435, 436 gelegt, wenn der Bus in einem Ausführen-A- oder Ausführen- Beide-Modus arbeitet, und Register 429 wird nur im Ausführen- B-Modus auf die Busse 435, 436 gelegt. Auf ähnliche Weise, wie in Fig. 34 ersichtlich, werden die Inhalte der Register 428a der STCI 155a während der Ausführen-B- oder Ausführen- Beide-Modi herausgezogen. Die Inhalte des Registers 429a werden während des Ausführen-A-Modus ausgegeben. Die Ausgänge der Register 428, 429 und 428a, 429a werden DOT-ODER- verbunden und führen die entsprechenden Dateneingangs- Multiplexer-Funktionen 71, 73 (Fig. 3) aus.
Die MEM-Size/MEM-Basis-Werte in den Registern 405, 404 sind im S/88-Prozessor 62 über den BCU örtlichen Adressenraum Speicher-abgebildeter virtueller Adressenraum. Sie müssen beim S/88 Boot-Prozeß gesetzt werden, sobald der gegebene S/370 CPU-Raum 162 definiert ist. Sie können vom S/88 verändert werden, solange keine STCI-Speicher/Abruf-Operationen im Gang sind.
Auf die Register 404, 405 wird von der Adressen-Decodierlogik 216 in Fig. 19A über eine örtliche Adresse (007E01FC) zugegriffen und sie beinhalten die folgenden Daten: PA-Bits 20-23 und PA-Bits 20-27, die entsprechend gleich sind mit der S/370 Speicher-162-Größe (MEM Size) und Speicher-Basisadresse (MEM Base), wobei:
MEM Size = Megabytes (1 bis 16) des Hauptspeichers, der vom S/88 Speicher 16 dem Speicherbereich 162 zugeteilt wird.
MEM Base = Megabytes Offset von der Adresse Null im physikalischen Adressenraum des Speichers 16, der dem Speicherbereich 162 zugewiesen ist.
PA = S/88 übersetzte virtuelle Adresse (d. i. die physikalische Adresse).
Wenn die Logik 216 die Adresse 007E01FC decodiert, werden die Größe und die Basis-Adressen-Bits vom Prozessor 62 über seinen Bus 161D in die Register 405, 404 gesetzt. Wahrend dieser Operation koppelt die Logik 216 den Prozessor 62 von seiner zugeordneten Hardware ab, wobei das Laden der Register 404, 405 für das S/88 Betriebssystem transparent ist. Zusätzlich bemerkt das S/370 Betriebssystem nichts von ihrer Existenz oder ihrer Anwendung beim Zugriff auf den S/370 Speicher 162.
Die Fig. 32A, B und 30 illustrieren auch die Signal E/A- Leitungen, die von der Speichersteuerungs-Schnittstelle 155 benutzt werden. Das beinhaltet zusätzlich zum STC-Bus 157 alle Leitungen, die zum Verbinden des S/88 Systembusses 30, des S/88 Prozessors 62 und der Logik 415 auf dem CPU-Board 102 über eine Schnittstelle erforderlich sind. Zwecks leichterer Beschreibung werden die Sender/Empfänger 13 in Fig. 8 in den Fig. 32A, B nicht dargestellt.

(d) Datenspeicheroperationen

Auf einen Speicherbefehl von der Cache-Controller-Einheit 153 taktet die STCI 155 den Befehl auf den Adressen/Datenbus 406 (der Teil des STC-Busses 157 ist) auf die Bits 0-7 und speichert ihn in den Befehlspuffer 416 zusammen mit dem STC- Valid-Bit und in den Puffer 417. STC-Busy auf Leitung 440 wird beim nächsten Zyklus von der Logik 401 hoch gesetzt, um anzuzeigen, daß die Einheit 155 busy ist. Inzwischen wird auch die 24-Bit Realadresse auf Bus 406 in das A/D Register 417 getaktet.
Solange der FIFO 400 nicht voll ist und die gesamte Datenübertragungslänge (bis zu 64 Bytes), die im Befehl (kein FIFO-Überlauf) spezifiziert ist, aufnehmen kann, wird der STC Datentransfer von der Logik 401 hoch gesetzt und bleibt für jeden Zyklus aktiv, bis alle STC-Bus-Datenübertragungen für diesen Befehl abgeschlossen sind. Im Speicher wird kein STC- Datentransfer ausgegeben (und daher wird der Befehl nicht in den FIFO geschoben), bis sicher ist, daß kein Abbruch ausgegeben wurde (bis zu 2 Zyklen nach STC-Valid). Während dieser Zeit jedoch schiebt die Logik 401 die 24-Bit-Adresse vom Register 417 ins Register 442 und die ersten vier Daten-Bytes werden von der Einheit 153 zum Register 417 übertragen. Zusätzlich werden die FIFO HF- und AFE-Flags 409 mit der Byte- Übertragungslänge verglichen, die vom Befehlspuffer 416 decodiert wurde. Die FIFO-Flags zeigen, daß 1 bis 4 Bereiche Puffertiefe in Gebrauch sind. Wenn die Byteübertragungslänge plus die 4 Bytes für die Befehlswortdaten die Wortkapazität des FIFO 64 übersteigen, wenn sie zur Puffertiefe im schlechtesten Fall addiert werden, wie von den FIFO Flags angezeigt wird, dann werden alle STC Datenübertragungsaktivierungen verzögert, bis diese Überlaufbedingung verschwindet. Das geschieht, sobald genügend Wörter aus dem FIFO geschoben sind, um den Flag-Status zu verändern.
Wenn kein Abbruch vorkommt und kein FIFO-Überlauf existiert, werden die Befehlsdecodierungen von Block 401, die mit den 24-Bit-Adresse aus Register 442 über den Multiplexer 447 verkettet sind, in den FIFO 400 gespeichert. Anschließend werden 32-Bit-Datenblöcke aus dem A/D-Register 417 in konsekutiven Zyklen über das Register 442 in den FIFO 400 gespeichert, sobald der ursprüngliche Speicherbefehl in den FIFO geschoben wird. Gate 423 wird benutzt, um die unteren 16 Bits für die 16-Bit-Übertragungen zum Bus 30 auf die oberen 16 Bits zu multiplexen.
Das S-Bit wird benutzt, um Speichern von Abrufen zu unterscheiden, und das C/A-Bit wird benutzt, um zwischen Befehlswörtern und Datenwörtern im FIFO 400 zu unterscheiden, wie in Fig. 35 gezeigt wird. Die Parität wird durch den FIFO beibehalten.
Die FIFO-Eingänge und FIFO-Ausgänge sind unterschiedlich getaktet. Daten werden mit S/370 Takten in den FIFO 400 geschoben, während sie mit S/68 Takten herausgeschoben werden. Dabei ist die Taktsteuerung so eingestellt, daß für die FIFOs schlimmstenfalls die Durchfallzeit (60 ns) gesetzt wird, wenn der FIFO 400 leer ist. Die FIFO Befehls- und Datenwörter werden in Fig. 35 gezeigt, dabei gilt:
S = (1 = Speichern, 0 = Abrufen)
C/A = (1 = Cmd/Add, 0 = Daten)
P01 = Bytes 0, 1 gerade Parität
P23 = Bytes 2, 3 gerade Parität
LDW = Lower Data Word Select (unteres Datenwort wird auf oberes Wort gemultiplext; in diesem Fall P01 = P23)
64B OVFL = 16-Wort-Transfer überschritten wegen ungerader Adressenausrichtung; erfordert zusätzlichen 32-Bit-Daten-Übertragungszyklus.
32B, 16B, 8B, 4B = Gewichtete Byte-Transfer-Zählung
TRL1,0 = Codieren für gültige Bytes im 'Trailing' Wort (Nachlaufwort - letzte 32 Bits Datentransfer).
Individuelle Sortierer im Block 401 eingangs- und ausgangsseitig am FIFO 400 verfolgen Transfers in/aus dem FIFO. Der Ausgangssortierer überwacht in Wirklichkeit die Anzahl der Bus-30-Datentransfers, die zum augenblicklichen Abruf- oder Speicherbefehl anstehen. Sobald das Befehlswort zum FIFO- Ausgang kommt, wird C/A Bit = 1 in der Logik 401 decodiert; und solange kein früherer Befehl auf seinen Abschluß wartet, wird die S/370 Realadresse aus dem FIFO 400 über die Logik 422 und 423 mit dem Basisregister 404 zusammengelegt, die dann als 'physikalische' Anfangsadresse in den Adressenpuffer 420 geladen wird, während die Übertragungszählung in den Ausgangssortierer 401 geladen wird. Auch die Verteilerlogik 408 wird auf Anfahren der Verteilung gesetzt.
Die Zyklussteuerlogik in 408 verfolgt alle aktiven STCI-155 Bus-30 Phasen, sowohl für Abruf- als auch für Speicheroperationen. Zusammen mit Bus 30 Statusleitungen (d. i. Bus- Busy, Bus-Error) wird diese Logik innerhalb der STCI 155 benutzt, um normale Bus-30-Phasenoperationen sowie Fehlerbedingungen zu behandeln, die zum Abbruch von Zyklusdefinitionen oder Datenphasen führen.
Die physikalische Adresse wird gebildet durch zunächst Vergleichen der oberen vier Bits der S/37024-Bit-Realadresse vom FIFO 400 mit dem S/370 Speichergrößenwert in Register 405 in der Logik 422. Wenn die S/370-Adressenbits den dem S/370 Prozessor 85 zugeteilten Größenbereich nicht überschreiten, werden die oberen vier Bits von der Logik 423 zum S/370 Speicher-Basiswert im Register 404 addiert und mit den unteren Bits 19-1 im Puffer 420 verkettet, um eine 27-Bit-Wortadresse zu bilden, die als S/88 Anfangsadresse im S/370 Bereich 162 benutzt wird. Sonst wird ein weicher Programmcheck berichtet. Jede 64-Byte-Adressengrenzüberschreitung führt zu einem zyklischen Überlauf auf die Anfangsadresse.
Der Adressen-U/D-Zähler wird benutzt, um Bits 5-2 der ausgehenden physikalischen Adresse zu halten. Sie wird synchron mit dem Augangssortierer getaktet, und während sie normalerweise inkrementiert wird, kann sie dekrementiert werden als Reaktion auf Bus-Busy- oder Bus-Error-Zustände einer Zyklus- Antwortphase. Sobald der Ausgangssortierer geladen ist, initiiert die zugehörige Logik über die Logik 408 Speicherzyklen auf der Grundlage der Busverteilerzuteilungen während sie auf die Bus-Error- und Bus-Busy-Bedingungen reagiert. Ein geeigneter S/88 Funktionscode wird von der Logik 401 entsprechend dem S/88 Speicherbefehl erzeugt; und der Funktionscode wird in Register 443 gelegt zur Anwendung auf die A-, B-Busse der Busstruktur 30, wenn eine Verteilerzuteilungszyklus-Anforderung erteilt wird.
Der Ausgangssortierer wird im Normalfall bei jeder Zuteilung dekrementiert, für eine 32-Bit Übertragung um 1, und für eine 64-Bit-Übertragung auf den Bus 30 um 2, bis die Null erreicht ist, was anzeigt, daß vom augenblicklichen Befehl keine weiteren Bytes übertragen werden müssen.
Im Falle eines Bus-Busy oder Bus-Error während einer Zyklus- Ansprechphase, die sich mit einer Zyklus-Definitionsphase (Rücken-an-Rücken Zuteilungen) überschneidet, wird der Ausgangssortierer um Eins für abgebrochene 32-Bit-Datentransfers, und um Zwei für 64-Bit-Transfers (nur Abrufen) inkrementiert. Simultan dazu wird der Adressen-U/D-Zähler 421 um Eins für abgebrochene 32-Bit-Übertragungen und um Zwei für 64-Bit-Transfers (nur abrufen) dekrementiert.
Das Datenausgaberegister 425 wird benutzt, um ausgehende Daten zu puffern. Das Ausgabedaten-Halteregister 426 wird benötigt in dem Fall, daß Daten neu getrieben werden müssen wegen eines nachfolgenden Busfehlers (A- oder B-Bus). In diesem Fall können nachfolgende Daten (an eine höhere Adresse) aufgenommen und im Speicher 16, 18 früher gespeichert werden als die Daten des vorausgehenden Zyklus, die mit dem Busfehler zusammenhängen, weil dieser Datentransfer 2 Zyklen nach seiner ersten Übertragung wiederholt werden muß. (Anders als beim Speichern können geholte Daten außerhalb der Reihenfolge nicht aufgenommen werden. Inzwischen verteilt die Bus- Verteilerlogik 408 kontinuierlich Prioritäten für die Zyklen, bis alle Übertragungen angelassen und auf dem Bus 30 aufgenommen sind. Die Verteilung und die Datenübertragung auf den Systembus 30 und Speicher 16, 18 sind ähnlich wie sie bereits in Abschnitt (b) beschrieben wurden.
Hier ist schließlich anzumerken, daß die Konstruktion des FIFO die Speicherung von bis zu 64 Wörtern zuläßt (fast 4 Gruppen 64-Byte-Speicherübertragungen) bevor er busy geht. Für Speicherungen, solange der FIFO nicht voll ist und Befehls- und Datenwörter aufnehmen kann, die mit dem Speicher zu tun haben, wird der FIFO kontinuierlich geladen bis er fertig ist. Daher geht STC-Busy tief nach dem Ausführen jedes Speicherbefehls, gibt damit Einheit 153 frei und ermöglicht das Weiterarbeiten des S/370 Prozessors 85. Unter der Annahme eines hohen Cache-Trefferverhältnisses in der Einheit 153, verbessert sich die Leistung signifikant durch Puffern des Äquivalents von fast 64-Byte-Speicher im FIFO- oder 32 1-4 Bytespeichers.
Hier soll angenommen werden, daß die STCI 155 die "Treiber"- Seite des STCI-Paars 155, 155a ist und daß STCI 155a die "Prüf"-Seite ist. Daher treibt nur die STCI 155 Signale (Steuerung, Adressen, Daten) auf die Busstruktur 30, wie in Fig. 32B dargestellt wird. Sowie Signale für beide Busse, A und B, vorgesehen sind, werden die STCI-155-Treiberleitungen so dargestellt, daß sie (über die in Fig. 32B nicht gezeigten Sender/Empfänger) an beide Busse angekoppelt sind. In der STCI 155a werden die entsprechenden Leitungen nicht mit der Busstruktur 30 gekoppelt; nur mit der Vergleicherlogik 402a- g.
Die Vergleicherlogik 402g vergleicht Adressen-Bits 27-6 vom Puffer 420, Adressen-Bits 5-2 vom Adressen-U/D-Zähler 421, das modifizierte Adressen-Bit 1 und das Paritäts-Bit von der Paritätsgeneratorlogik 445, und den Funktionscode aus Register 443 mit den entsprechenden Bits von der STCI 155a. Bei Nichtübereinstimmung legt die Logik 402g Fehlersignale auf die gebrochene Logik 403 und auf die Bus-Error-Leitungen A und B.
Die Logik 402e vergleicht Daten-aus-Bits aus dem Register 425 mit den entsprechenden Bits von der STCI 155a und legt Vergleichsfehlersignale an die Logik 103 und an die Bus-A-und B- Error-Leitungen. Die Logik 402d vergleicht Bits aus der FIFO- Logik 401 mit entsprechenden Bits aus der STCI 155a. Ein UND- Gatter 446 gibt ein Fehlersignal an die Logik 403, wenn das STC-Valid-Signal hoch gesetzt ist, während das STC Busy- Signal auf Leitung 440 aktiv ist.

(e) Datenabrufoperationen

Ein Datenabrufbefehl folgt dem gleichen Pfad wie die Speicherbefehle durch die Register 416, 417, 442 und den FIFO 400 wie oben beschrieben. Ein Unterschied besteht darin, daß das STC Datenübertragungssignal auf der STC Buslogik 408 nicht hochgesetzt wird, bis bekannt ist, daß die Daten im Register 428 und 429 aus dem Speicher 162 über den Bus 30 eingegangen sind. Ein Abrufbefehl und ein STC-Valid-Signal werden in Register 416 aufgenommen und gespeichert. Der Befehl und seine Anfangsspeicheradresse werden in Register 417 gespeichert. Die STC-Buslogik gibt in 401 während des nächsten STC-Buszyklus ein STC-Busy-Signal aus, damit verhindert wird, daß der Cache-Controller 153 einen weiteren Befehl sendet, bis der STC-Busy-Befehl entfernt ist.
Wenn also ein Abrufbefehl empfangen wird, wird das STC-Busy- Signal von der Logik 401 beibehalten bis der Abrufbefehl voll ausgeführt ist, weil der Cache-Controller 153 darauf wartet, daß die Abrufdaten eingehen. (Während der Speicherzyklen wurde STC-Busy entfernt, sobald alle Speicherdaten vom Controller 153 auf den FIFO 400 übertragen sind.) Während eines Abrufbefehlszyklus muß STC-Busy beibehalten werden bis restlos alle Speicherbefehle im FIFO 400 ausgeführt sind, dann wird der Abrufbefehl ausgeführt. Erst dann kann STC-Busy entfernt werden, um die Übertragung des nächsten Befehls an die STCI 155 zu ermöglichen.
In den auf die Speicherung des Befehls in den Registern 416, 417 folgenden Zyklen werden der Befehl und die Adresse in die Register 442 und dann in den FIFO 400 übertragen.
Wenn der S/370 Abrufbefehl auf der letzten Stufe des FIFO 400 eingeht (und output-ready hoch liegt, wie oben beschrieben), werden der C/A und andere Befehls-Bits in der Logik 401 decodiert. Ein S/88 Funktionscode entsprechend den decodierten S/370 Befehls-Bits wird ins Register 443 zum Legen auf die Busstruktur 30 geschickt, sobald eine Verteilerzyklus- Anforderung erfüllt wird.
Nach einer Erteilung- und der anschließenden Zyklusdefinitionsphase und Zyklusantwortphase tritt unter der Annahme, daß kein Bus-Busy oder Bus-Error während der Zyklusantwortphase gemeldet wurde, die STCI 155 in die Datenphase ein. Die ersten 32 Bits zusammen mit den Bits DP, UDS und LDS werden auf den A- und B-Bus der Struktur 30 von der richtigen Speicherstelle im Bereich 162 des Speichers 16 und Partner aufgenommen, und werden in die Register 428 bzw. 429 eingespeichert, wobei der S/88 Takt die zweite Hälfte des Bus-30- Zyklus beginnt. Unter der Annahme, daß der Ausführen-Beide- Modus oder Ausführen-A-Modus aktiv sind, werden Daten von dem Register 428 im nächsten S/88 Taktzyklus (Start des nächsten Bus-30-Zyklus) in den Puffer 430 eingespeichert. Für 64-Bit- Übertragungen werden die nächsten 32 Bits in die Register 428 und 429 gleichzeitig mit der Übertragung vorhergehender Daten in den Puffer 430 gespeichert. Ein Paritätsgenerator 431 fügt ungerade Parität zu dem in 430 gespeicherten Datenwort hinzu. Diese Daten- und Paritäts-Bits werden zusammen mit den aufgenommenen UDS-, LDS- und DP-Bits über die Busse 435 und 436 an die Logik 402c gelegt. Die Logik 402c vergleicht diese Bits mit den entsprechenden, in der gepaarten STCI 155a erzeugten Bits. Der Puffer 430 legt jetzt das erste Datenwort plus Parität in den Puffer 432, damit sie während des nächsten STC- Buszyklus zum Übertragen an den Cache-Controller 153 über den Bus 406 des STC-Busses 157 übertragen werden. Puffer 432 wird mit S/370-Takten getaktet, die mit den S/88-Takten synchronisiert sind, so daß der Beginn des STC-Bustaktzyklus nach der Aktivierung des S/88-Takts erfolgt. Da sowohl für S/88- als auch für S/370-Takte identische 62,5 ns Perioden definiert sind, ermöglicht das den Pipeline-Aufbau aufeinanderfolgender Lesevorgänge von Bus 30 zum STC-Bus. So werden in der bevorzugten Ausführungsform für jeden Bus-30-Zyklus von 125 ns zwei STCI-Zyklen ausgeführt.
Unter der Annahme aufeinanderfolgender Zuteilungen an die STCI 155 folgt jetzt eine zweite Datenphase auf die erste, oben beschriebene Datenphase (unter der Annahme, daß es keine Busfehler usw. gibt). Nehmen wir 64-Bit-Übertragungen an, dann werden jetzt Daten in die Register 428 und 429 eingetaktet gleichzeitig mit Daten, die vom Puffer 428 (bzw. 429 beim Ausführen-B-Modus) in den Puffer 430 getaktet werden. Dann legen Puffer-430-Daten die nächsten 32 Bits an den Puffer 432 zum Transfer zum Cache-Controller 153, wie oben beschrieben. Man sieht also hier, wie aufeinanderfolgende 54-Bit-Über tragungen dazu benutzt werden können, in der bevorzugten Ausführungsform einen Pipeline-Datenfluß aufrechtzuerhalten.
Wenn während der Datenphase ein 'Fast-ECC'-Fehler oder ein Datenvergleichsfehler oder Paritätsfehler auftritt, wird ein STC-Data-Invalid durch die Logik 402c auf Leitung 433 gelegt, gleichzeitig mit den Daten auf dem STC-Adressen/Daten-Bus 406. Wenn ferner nachfolgende Daten im Zyklus nach dem Zyklus, in dem Daten ungültig gemacht wurden, eingeht, wird von der STCI SBI Logik auf beiden Bussen, dem A-Bus und dem B- Bus, nach diesem Datenzyklus ein Busfehlerzustand erzwungen. Das stellt sicher, daß die Daten 2 Zyklen später wieder getrieben werden (d. h. einen Zyklus nachdem der Busfehler gemeldet wird), um auf diese Weise die Datenvollständigkeit und -funktionalität auf dem STC-Bus durch Übertragen der abgerufenen Daten in der richtigen Folge zu wahren. Das Treiben von Busfehlern sowohl auf dem A-Bus als auch auf dem B-Bus ist gleichbedeutend mit dem Melden eines ECC-Fehlerzustands gegenüber einem 'echten' Busfehler durch den Speicher 16, und bewirkt auf diese Weise keine Veränderung in der Bus- Ausführen-Logik über alle Controller auf dem Systembus 30.
Auf ähnliche Weise wird die gleiche Logik 402c, die zum Vergleich eingehender Daten und Prüfparität über die Busse 435, 436 benutzt wird, auch für Speicheroperationen zum Überprüfen der Ergebnisse des Ausgangsdatenvergleichs in 402e durch Durchführen eines 'Rückschleife'-Datenvergleichs vom Systembus 30 über Register 428 oder 429 benutzt. Das trägt bei zur schnelleren Identifizierung der Sender/Empfänger-13-Probleme auf dem Board 101, und wird die gebrochene Logik 403 des Boards auf die Speicher setzen, wenn kein Vergleichsfehler und Busfehler im nächsten Buszyklus gemeldet wird. Zusätzlich werden alle Vergleicherausgänge 402a-g, die einen Störungszustand auf gültige Fehlvergleiche für Abruf- und Speicheroperationen produzieren, einen gebrochenen Zustand in der Logik 403 generieren. Das anfängliche Setzen von Gebrochen wird Busfehlersignale auf beiden Bussen, dem A- und dem B-Bus, generieren und auf diese Weise sicherstellen, daß eine Datenübertragung im vorherigen Zyklus wiederholt wird, während jede Zyklusdefinitionsphase im vorherigen Zyklus abgebrochen wird.
Anders als beim Speichern müssen beim Abrufen alle vorher im FIFO stehenden Befehle sowie auch das gerade laufende Abrufen abgearbeitet sein, bevor die Einheit die STC-Busy-Leitung 440 tiefsetzen und einen weiteren Befehl annehmen kann. Der Cache-Controller 153 muß die Daten für einen Abrufbefehl erhalten, bevor ein anderer Speicherbefehl ausgegeben werden kann.
Die Definition der verfügbaren Lese/Schreibzyklustypen wird in Fig. 36 A-D gezeigt, dabei bedeuten:
UU = Upper Byte of upper word (Oberes Byte des oberen Worts)
UM = Upper Byte of middle word (Oberes Byte des mittleren Worts)
LM = Lower byte of middle word (Unteres Byte des mittleren Worts)
LL = Lower byte of lower word (Unteres Byte des unteren Worts)
MEM 16 = 16-Bit memory cycle (16-Bit Speicherzyklus)
MEM 32 = 32-Bit memory cycle (32-Bit Speicherzyklus)
MEM 64 = 64-Bit memory cycle (64-Bit Speicherzyklus)
LW = Longword (32 Bits) (Langwort (32 Bits))
UDS = Upper Data Strobe (Oberer Daten-Strobe)
LDS = Lower Data Strobe (Untere Daten-Strobe)
In der bevorzugten Ausführungsform der Einheit 155 stehen keine 64-Bit-Schreibvorgänge zur Verfügung aufgrund der Be deutung, die einer Hardware-Minimalisierung zugeschrieben wurde. Ein 64 · 36 FIFO reicht aus, 32-Bit Speicherübertragungen vom S/370 zu unterstützen. Eine Einschränkung beim Benutzen von nur 32-Bit Schreibvorgängen entsteht dadurch, daß, da jedes S/88 Speicherkarten-'Blatt' in verschachtelter Speicherung 16 zweiundsiebzig Bits lang ist (64 Bits plus 8 ECC-Bits), weitere drei (3) zusätzliche (125 ns) Zyklen 'busy' bleibt, sobald bei Schreibvorgängen darauf zugegriffen wird. Das heißt, daß auf das gleiche Blatt nur einmal alle 5 Zyklen (625 ns) bei aufeinanderfolgenden Schreibvorgängen zugegriffen werden kann. Da alle S/37032-Bit-Schreibvorgänge für aufeinanderfolgende Adressen definiert sind, heißt das, daß aufeinanderfolgende Übertragungen innerhalb der gleichen 64-Bit-Grenze nicht schneller als jeweils nach 5 Zyklen (625 ns) durchgeführt werden können, während aufeinanderfolgende Übertragungen auf unterschiedliche 64-Bit-Grenzen in aufeinanderfolgenden 125 ns Zyklen (unter der Annahme, daß sie Zuteilung haben) ausgegeben werden können.
Vierundsechzig-Bit-Lesezyklen werden unterstützt, und in diesem Fall können sie, solange die aufeinanderfolgenden Lesevorgänge nicht auf das gleiche Blatt zugreifen, in aufeinanderfolgenden Zyklen ausgeführt werden. Sonst können sie alle zwei Zyklen (250 ns) ausgeführt werden. Weil jeweils 32 Bits vom Bus 30 in 64-Bit-Lesevorgängen alle 62,5 ns empfangen werden (d. h., zweimal jeden 125 ns Bus-30-Zyklus), stimmen die STC-Bus-Zykluszeiten und die Systembus 30 Zykluszeiten überein, so daß die Daten vom Systembus 30 nach Eingang in den STC-Bus 157 in die Pipeline geschoben werden können. Zwei Extraebenen für das Puffern (Puffer 430 und 432) werden mit den Registern 428 und 429 benutzt, um die richtige Synchronisierung der Zyklen zu unterstützen und die Paritätsgenerierung für jedes Datenbyte zu ermöglichen.
Jede 27-Bit-Adresse und jeder 4-Bit-Funktionscode werden zusammen mit einem begleitenden Paritätsbit während der Bus-30- Zyklusdefinitionsphasen gesendet. Die 32-Bit-Daten transportieren während der Bus-30-Datenphase auch ein ihnen zugeordnetes Paritätsbit. Ein grundlegender 125 ns Zyklus auf Bus 30 läßt normale 16 und 32-Bit-Übertragungen sowie auch 64-Bit- Leseübertragungen innerhalb des 125 ns Fensters zu. Wahlweise kann auch zusätzliche Hardware benutzt werden, um aufeinanderfolgende 64-Bit-Schreibübertragungen in die STCI 155 zu unterstützen.

S/370 E/A-Unterstützung (Fig. 37)

Fig. 37 illustriert in der Form eines Blockschaltbilds eine Übersicht über die S/88 Hardware und den Applikationscode, der zum Unterstützen der S/370 E/A-Funktionen benutzt wird. Die Hardwarevorrichtungen sind 601, 602, 615-619, 621 und 623-625. Die Software- (oder Firmware-) Routinen sind 603- 614, 620, 622 und 626.
Anschließend sollen die Funktionen dieser verschiedenen Elemente beschrieben werden. Block 606 ist die Hauptsteuerung für den S/88 Applikationscode, der aus Block 606 bis einschl. Block 614 besteht. Dieser Satz Blöcke, der unter der Bezeichnung EXEC370 bekannt ist, führt alle S/88 Applikationscode- Funktionen durch, die zur Emulation und Unterstützung der S/370 externen Vorrichtungen, Dienstleistungen, Konfiguration, Bedienerkonsole usw. gehören.
Block 603 ist der Mikrocode, der im S/370 Mikroprozessor läuft. Er unterstützt die S/370 Funktionen. Ein Protokoll zwischen Block 603 und Block 606 setzt sie in die Lage, Anforderungen und Anworten miteinander auszutauschen, die die Initialisierung von S/370 E/A-Operationen, ihren Abschluß und S/370 E/A-Vorrichtungs- und Kanalstatus-Informationen betref fen. Sie setzen auch Block 606 in die Lage, vom Block 603 die Durchführung spezifischer S/370 CPU-Funktionen zu verlangen. Block 605 ist die S/370 Speicherung und ist direkt zugänglich sowohl für Block 603 als auch für Block 606. Block 606 sieht die geeignete S/370 Konfiguration über die in Block 602 enthaltenen Daten vor, in dem eine S/88 Daten-Datei enthalten ist.
Block 604 ist eine gesondert ablaufende Aufgabe, die die S/730 Bedienerkonsole über ein S/88 Datenendgerät vorsieht. Diese Aufgabe kann jederzeit gestartet oder angehalten werden, ohne das logische Arbeiten des S/370 Prozesses zu unterbrechen. Block 607 ist Teil des EXEC370 und sieht eine Schnittstellenemulationsfunktion zwischen dem S/370 Prozeß und Block 604 vor.
Block 601 ist ein Satz S/88 Daten-"Korrektur-Dateien", der einen S/370 Maschinencode enthält, der besonders für den Zweck der Fehlerbeseitigung im S/370 einschließlich seiner BCU 156 geschrieben wurde. Es gibt eine vom Block 604 vorgesehene Entstör-Bildschirmanzeige, die das Anwählen und Laden einer dieser "Korrektur-Dateien" in den Block 605 ermöglicht.
Block 608-1 besteht aus dem Code, der für die Emulation des S/370 Kanals zuständig ist. Er führt das Abrufen der S/370 CCWs, die Bewegung von Daten zum und vom Block 603, das Melden von S/370 E/A-Interrupt-Informationen an Block 603, und die Anwahl des richtigen Steuereinheitscode-Emulators durch. Es kann mehr als einen S/370-Kanal geben (z. B. 608-2), es wird jedoch der gleiche Code benutzt.
Block 609-1 ist der S/370 Steuereinheit-Emulatorcode. System 370 weist viele unterschiedliche Typen von Steuereinheiten auf, d.i. DASD-Controller, Band-Controller, Kommunikations- Controller usw. Die S/370 Controller-Funktion ist aufgeteilt zwischen Block 609-1 und dem eigentlichen Vorrichtungsemulator, Block 610 bis einschl. Block 614. Der Hauptzweck des Blocks 609-1 sind Adressentrennfunktionen, jedoch können auch andere Steuereinheits-spezifische Funktionen im Block 609-1 sitzen. Daher gibt es mehr als einen Block dieses Typs (z. B. Block 609-2) d.i. DASD-Controller-Emulator, Kommunikations- Controller-Emulator usw.; es gibt jedoch keine Eins-zu-eins- Entsprechung mit diesen unterstützten 3/370 Steuer-Einheiten.
Block 610 stellt den Code dar, der für das Emulieren einer S/370-Konsole erforderlich ist. Block 611 stellt den Code dar, der zum Emulieren eines S/370 Terminals erforderlich ist. Block 612 stellt den Code dar, der zum Emulieren eines S/370-Lesers erforderlich ist. Das ist eine virtuelle Eingabevorrichtung, die nach dem Muster des Standard-VM-Lesers ausgelegt ist. Sie besorgt die Eingabe sequentieller Dateien, die aus einer anderen Quelle generiert werden, in der Regel ein Band oder eine Diskette.
Block 613 stellt den Code dar, der erforderlich ist zum Emulieren eines A/370 Druckers. Ein wirklicher S/88 Drucker kann angetrieben werden oder die S/370 Daten können in eine S/88 Datei geschrieben werden für späteres Spool-Drucken. Block 614 stellt den Code dar, der erforderlich ist zum Emulieren einer S/370 Platte. Die zwei Formate: Count, Key and Data, und Fixed Block werden von zwei unterschiedlichen Code-Sätzen unterstützt.
Block 615 stellt ein S/88 Terminal dar, in der Regel die S/88 Konsolen-Ausgabevorrichtung. Die System/88 Konsole zeigt sowohl S/88 Bedienermeldungen als auch S/370 Bedienermeldungen, zusätzlich zum Protokollieren der Meldungen in ein Protokoll auf einer Platte, die dem S/370 als ein 3278 oder 3279 Terminal erscheint.
Block 616 stellt ein S/88 Terminal dar. Block 617 stellt eine S/88 sequentielle Daten-Datei auf einer S/88 Platte dar. Block 618 stellt einen S/88 Drucker oder eine sequentielle Daten-Datei auf einer S/88 Platte dar. Block 619 stellt eine S/88 Daten-Datei auf einer S/88 Platte dar. Block 620 ist der Code, der ein System/370 Band liest, das in eine S/88 Bandvorrichtung eingelegt ist, und formatiert es in Block 617 so, wie es auf dem ursprünglichen S/370 Band erscheint. Block 621 stellt ein S/88 Bandlaufwerk dar, in das ein beschriebenes Band eingelegt ist.
Block 622 ist der Code, der eine Datei liest, die von einem Personalcomputer in das S/88 eingegeben ist, und formatiert sie in Block 617 so, wie sie ursprünglich ausgesehen hat, als sie von einem S/370 System generiert wurde.
Block 623 ist ein Personalcomputer, der konfiguriert ist, um Daten sowohl an ein S/88- als auch an ein S/370-System zu senden und von ihnen zu empfangen. Block 624 ist ein S/370 System. Block 625 stellt einen S/88 Spool-Drucker dar. Block 626 ist der Code, der eine S/88 Datei in eine emulierte System/370 DASD-Vorrichtung formatiert. Das ist ein gesondert abgearbeiteter S/88 Task, der die Datei auf jeden der gewünschten unterstützten S/370 DASDs formatiert.

S/370 E/A-OPERATIONEN, FIRMWARE-ÜBERSICHT

Eine vereinfachte und verallgemeinernde Ansicht der System/370 Ein/Ausgabe soll jetzt dargestellt werden. Die S/370 Architektur sieht verschiedene Typen von E/A-Anweisungen, ein über Programm prüfbares Betriebszustands-(CC)-Schema und einen Programm-Interrupt-Mechanismus vor. Begrifflich ist eine E/A-Anweisung auf einen 'E/A-Kanal' gerichtet, der die Arbeit der E/A-Operation parallel zu anderen CPU-Prozessen ausrichtet und steuert und den Status an die CPU meldet, wenn die E/A-Anweisung ausgeführt wird (über den Betriebszustandscode), und/oder wenn die E/A-Operation abgeschlossen ist (über den Programm-Interrupt).
S/370 Anweisungen, Betriebszustandscodes, Interrupts und E/A- Vorrichtungen (DASD, Band, Terminals usw.) sind eng architekturiert. Der E/A-Kanal ist hingegen locker architekturiert, um große Konstruktionsbreite vorzusehen, und es gibt viele unterschiedliche Implementierungen.
Die breite Sicht einer Verbesserung des fehlertoleranten Systems/370 ist dann eine S/370 CPU (Chipsatz mit anwenderspezifischer Firmware) und ein 'Pseudo-E/A-Kanal', bestehend aus Zeitscheiben einer S/88 CPU und eines Betriebssystems (OS) mit Zusatz spezifischer Firmware und Software auf Applikationsebene (EXEC370), die sowohl S/370 E/A-Vorrichtungsemulation als auch allgemeine Steuerung des Systemkomplexes vorsehen. Der S/88 Teil dieses Komplexes sieht fehlertolerante CPU, OS, E/A-Vorrichtungen, Stromversorgungs-Paketierung, Busse und Speicher vor; die S/370 CPU wird fehlertolerant gemacht durch Hardware-Redundanz und zusätzliche Vergleichslogik.
Die erforderliche kundenspezifische Firmware (d. i. Mikrocode) zerfällt in zwei Gruppen:
a. S/88 BCU-Treiber-Firmware (ETIO), die auf dem S/88 Prozessor 62 läuft - Dienstleistungs-Routinen zur Initialisierung und Steuerung der BCU/DMAC-Hardware, DMAC-Interrupt- Bedienung und Status- und Fehlerbehandlung.
b. S/370 (Prozessor 85) Mikrocode - E/A-Anweisungen, E/A- Interrupt-Behandlung und einige spezifische Steuerungen wie Aufruf von Reset, IPL, Halt usw.
Als Hilfe zum Verständnis des Zusammenhangs der verschiedenen Firmware-Operationen betrachte man die folgende vereinfachte Ereignisfolge, die in einer typischen E/A-Operation vorkommt: Das S/370 Schreiben einer 80-Byte-Meldung in ein emuliertes S/370 Anzeigeterminal 3278.
Nehmen wir für dieses Beispiel an, daß die Initialisierung bereits stattgefunden hat, das S/370 und das S/88 arbeiten normal und keine andere S/370 E/A-Operation ist im Gang, unter Bezugnahme auf Fig. 43 und die Fig. 19A-C. Jede Daten-/ Befehlsübertragung zwischen PE62 und Elementen der BCU wird unter Benutzten des "Abkopplungs"-Mechanismus ausgeführt, der oben anhand der Fig. 20 beschrieben ist. Das Flußdiagramm der Fig. 43 zeigt ein Schaubild dieser typischen Anlauf-E/A- Operation.
a. Der S/370 Prozessor 85 stößt auf eine Start-E/A-(SIO)- Anweisung. (Alle E/A-Anweisungen im Chipsatz 150 in der bevorzugten Anwendungsform sind mikrocodiert).
b. Kundenspezifische Firmware für SIO wird aufgerufen; sie bewegt verschiedene Parameter in den festen Mailbox- Bereich 188 (im IOA-Bereich des S/370 Hauptspeichers), schickt einen Bedienaufruf an die BCU 156 (PU-BCU-Request) und wartet auf Antwort.
c. Die BCU-Hardware entdeckt den Aufruf und generiert einen Befehl zum Lesen der 16-Byte-Mailbox vom festen S/370 IOA- Bereich, antwortet dann auf den S/370 Prozessor 85 durch Rückstellen des Aufrufs über BCU-PU ACK (das bedeutet: 'Aufruf wurde bedient').
d. Im S/370 Prozessor 85 wird die SIO-Firmware freigegeben, um die SIO-Anweisung zu beenden und die Bearbeitung an der nächsten sequentiellen Anweisung fortzusetzen.
e. Gleichzeitig mit Ereignis 'd' als Ergebnis von 'c', hat die S/370 Hardware die 16 Bytes der Mailbox-Daten über den Bus 170 auf den BCU-Schnittstellenpuffer 259 im Adapter 154 übertragen.
f. Beim Puffern der Daten (in 4-Byte-Blöcken) signalisiert die BCU-Hardware wiederholt dem DMAC 209 (Kanal 0), die Mailboxdaten (in 4-Byte-Blöcken) an einen WORK QUEUE Block im örtlichen Speicher 120 zu übertragen.
g. Nach Abschluß des 16-Byte-Transfers legt der DMAC 209 einen Interrupt (NOTIFY, Fig. 43) an den S/88 Prozessor 62 und bereitet sich dann selbst auf eine spätere Mailbox- Operation vor durch Laden der nächsten Position der Verbindungsgliedliste. Dieser Interrupt ist einer der acht (8) DMAC-Interrupts zum Prozessor 62, d.i. ein "normaler" DMAC-Kanal-0-Interrupt.
h. Sobald der S/88 den DMAC-Interrupt aufnimmt (vorbehaltlich möglicher Verzögerungen wegen Maskierung) wird eine kundenspezifische Firmware-Dienstroutine (in ETIO) abgearbeitet; sie prüft den Status des DMAC 209, findet den gerade eingegangenen WORK QUEUE Block durch Bezugnahme auf die Verbindungsgliedliste, und hinterlegt diesen Block zum Übertragen auf das EXEC370 Applikationsprogramm.
i. EXEC370 prüft die WORK QUEUE, holt den WORK QUEUE Block aus der Warteschlange, bildet einen Daten-Request im WORK QUEUE Block und ruft eine Firmware-Routine auf, um die 80 Daten-Bytes an das Terminal 3278 schicken zu lassen.
j. Die Firmware erzeugt und startet den DMAC 209 (Kanal 1), schickt dann einen Befehl an die BCU-Hardware, um über Adapter 154, Bus 170 und Speicher-Controller 155 mit dem Lesen der 80 Bytes aus einer spezifischen S/370 Speicherstelle zu beginnen.
k. Die BCU-Hardware 156, der Adapter 154 und der DMAC 209 übertragen die 80 Bytes in den WORK QUEUE Block, und der DMAC 209 schickt einen Interrupt an den S/88; das ist ähnlich den obigen Operationen in f. und g. Dieser Interrupt, ein "normaler" DMAC-Kanal-1-Interupt, ist einer der oben beschriebenen acht DMAC-Interrupts.
l. Ein Firmware-Interruptservice-Routine prüft wieder den DMAC-Status und hinterlegt einen WORK QUEUE Block-Zeiger für EXEC370.
m. EXEC370 besorgt jede erforderliche Datenumwandlung, schreibt dann die Daten in das emulierte Terminal 3278 unter Verwendung der Dienstleistungsprogramme des S/88 OS. Nach einiger Zeit erhält es die Mitteilung vom Ende (normal oder Fehler) dieser Operation. Es bildet dann, im WORK QUEUE Block, eine geeignete S/370 Interrupt-Meldung, einschließlich Status, und ruft wieder eine Firmware- Routine auf, um sie in die S/370 Meldungswarteschlange zu schreiben.
n. Die Firmware bildet und startet den DMAC (Kanal 3), schickt dann einen Befehl an die BCU-Hardware zum Schreiben von 16 Bytes in die S/370 Meldungswarteschlange. Das ist ähnlich wie ein Mailbox-Lesen in umgekehrter Richtung, mit dem Unterschied, daß in diesem Fall der Adapter 154 auf Mikrocode-Ebene am Ende der Operation einen Ausnahme- Interrupt im S/370 Prozessor 85 generiert (auch vorbehaltlich einer Verzögerung wegen Maskierung). Der DMAC 209 unterbricht auch (NOTIFY, Fig. 43) den S/88 Prozessor 62, wie oben in g. und k. Dieser Interrupt, ein "normaler" DMAC-Kanal-3-Interrupt, ist einer der acht DMAC- Interrupts.
o. Im S/370 Prozessor 85 behandelt die kundenspezifische Firmware die Ausnahme und muß die Kanalmasken auf die Verzögerungsmöglichkeit testen; wenn maskiert, so daß ein Interrupt nicht auf das laufende Programm angewandt werden kann, werden die wesentlichen Daten aus dem Meldungs- Warteschlangenbereich 189 in eine Warteschlange mit schwebendem Interrupt geschoben; ein anderes kundenspezifisches Firmware Steuerprogramm bedient es, wenn der Kanal das nächste Mal für Interrupts aktiviert wird. Wenn nicht maskiert, schaltet diese Firmware den Kontext der S/370 sofort auf die Interrupt-Routine des Programms um.
Eine breite Aussicht auf das verbesserte FT-System führt zur Auffassung der Rolle des S/88 als angehängter Slave-E/A- Prozessor - d.i. ein E/A-Steuerprogramm oder ein Pseudokanal für das S/370. In Wirklichkeit muß die gesamte grundlegende Kommunikation zwischen den Prozessoren vom S/88 initialisiert werden (konstruktionsbedingt). Auch kann der S/88 über EXEC370 auf den gesamten S/370 Speicher- und Mikrocode-Raum zugreifen, während das Umgekehrte nicht der Fall ist - der S/370 Prozessor 85 kann überhaupt nicht auf den Speicherraum des S/88 zugreifen, auch nicht zufällig. Somit ist das richtigere Bild, daß der S/370 der Slave des S/88 ist, jedoch mit dem internen Bild eines normalen unabhängigen S/370 mit S/370- E/A. Das S/370 'weiß' überhaupt nicht, daß das S/88 vorhanden ist.
Da aber die S/370 Programme asynchron zum S/88 laufen und nicht behindert werden dürfen, müssen die S/370 E/A- Anweisungen in der Lage sein, eine Aktion zu INITIATE, und diese Möglichkeit ist vorgesehen in der PU-BCU-Anforderungsleitung 256a, die eine einzige singuläre Bedeutung hat: S/370 hat eine Hoch-Prioritäts-Meldung, die auf das S/88 wartet (in der Regel eine E/A-hnweisung). Die Prioritätsnatur dieser Serviceanforderung ist der Grund für das automatische Mail box-Schema und die Verbindungsgliedlisten-Programmierung des DMAC-Kanals 0.
Der DMAC 209 ist ein integrierender Bestandteil der BCU- Hardwarekonstruktion. Er wird initialisiert und grundlegend gesteuert von der S/88 Firmware, und Datenübertragungen werden von der BCU-Logik getaktet, die die vier Request-REQ- Eingabe-Leitungen 263a-d, jeweils eine je Kanal, treibt. Zusätzlich aktiviert die externe BCU-Logik die Kanal-0-PCL- Leitung 257a sobald jede Mailbox-Übertragung abgeschlossen ist, und bewirkt somit, daß der DMAC 209 einen Interrupt- Request auf den S/88 Prozessor 62 legt.
Es gibt vier grundlegende Datenübertragungsoperationen zwischen S/370 und S/88:
Die Initialisierung und Programmierung des DMAC 209 ist ausschließlich standardmäßig und vorzugsweise in Übereinstimmung mit der Architektur MC68450.
Kurz:
Alle 4 Kanäle - Wort-(16 Bits)-Übertragungsgröße; REQ Leitungssteuerungsübertragung; Speicheradresse in Speicher 210 wird hochgezählt; Vorrichtungsadresse (BCU Datenpufferregister) wird nicht gezählt
Interrupts aktiviert; Zyklusstehlen ohne Halten; Vorrichtung mit Quittung/Implizit-Adressierungs/Einadreß-Modus; 16-Bit-Vorrichtings-Port; PCL = Status-Eingabe
Zusätzlich -
CH0: Vorrichtung-zu-Speicher (Speicher 210) Übertragung; verbundene Matrizen-Verkettung; PCL = Status-Eingang mit Interrupt
CH1: Vorrichtung-zu-Speicher (Speicher 210) Übertragung; kein Verketten
CH2 & 3: Speicher-zu-Vorrichtung (Speicher 210) Übertragung; kein Verketten
Der DMAC 'denkt', die Vorrichtung habe 16-Bit-Daten, aber die externe Logik bewirkt 32-Bit-Übertragungen. Der im CH0 (Kanal 0 des DMAC 209) benutzte Verbundene-Matrizen-Modus impliziert, daß eine Verbindungsgliedliste vorhanden ist, und von der ETIO-Initialisierungsroutine gesetzt wurde. Sobald CH0 anläuft, stoppt er nur bei einem Fehlerzustand oder durch Antreffen des letzten gültigen Eintrags in der Verbindungsgliedliste. Im Normalbetrieb tritt jedesmal ein Interrupt zum.
S/88 auf, wenn der DMAC 209 ein Mailbox-Lesen abschließt, und die Firmware die Verbindungsgliedliste in Echtzeit überwacht und wiederauffüllt; auf diese Weise wird der letzte gültige Eintrag der Liste nie erreicht und CH0 läuft (im Leerlauf) kontinuierlich.
Jeder DMAC-Kanal weist zwei Interruptvektor-Register, NIV, EIV, auf (Fig. 18), eines für ein normales Operationsende und eines für ein durch einen gefundenen Fehler erzwungenes Ende. Die vorliegende Erfindung benutzt alle acht Vektoren, mit acht gesonderten ETIO-Interrupt-Routinen im Mikrocode-Speicher 174. Auf ähnliche Weise hat der normale Interrupt im Kanal 0 zwei mögliche Bedeutungen: Ein PCL-bewirkter 'Mailbox empfangen (Mailbox received)' und das weniger-allgemeine 'Kanal angehalten wegen Ende der Verbindungsgliedliste (Channel stopped due to the end of linked-list)'. Die Unterbrechungs- Routine unterscheidet diese durch Testen eines DMAC- Statusbits.
Die S/88 Firmware sieht auch vier Dienstleistungseinträge für das EXEC370-Applikationsprogramm vor: Initialisierung, und Starten der drei Grunddatenübertragungen, wie oben diskutiert - Data Read, Data Write, und Message-Q Write.
Der Eintrag ETIO-INITIALIZE wird gewöhnlich bald nach dem Einschalten aufgerufen, kann aber auch zur Neuinitialisierung wegen Fehlerbehebungsversuchen benutzt werden. Er stellt die BCU-Hardware und den DMAC 209 zurück, programmiert dann die DMAC-Register in allen vier Kanälen mit Konfigurations- und Steuerwerten. Es baut auch die erforderliche Verbindungsgliedliste auf und startet Kanal 0, wodurch der DMAC 209 zum Selbstladen des ersten Verbindungsgliedlisten-Parametersatzes und dann zum Warten auf eine Übertragungsanforderung von der BCU-Hardware über Leitung 263a gezwungen wird.
Die anderen drei Dienstleistungseinträge werden beim Starten des DMAC-Kanals 1, (Data read), 2 (Data write) und 3 (Message-Q write) aufgerufen. Das aufrufende Programm (EXEC370) liefert einen Zeiger auf einen WORK QUEUE Block, der mit Datenadressen, Zähler usw. voreingestellt wurde. Diese Routinen starten entweder die DMAC209 und BCU-Hardware sofort, oder setzten die Operation in Warteschlange, wenn der angeforderte DMAC-Kanal busy ist. (Eine gesonderte 'Schwebende Arbeit'-Warteschlange, gezeigt in Fig. 41E, wird für jeden dieser drei Kanäle bereitgehalten). Sobald die angeforderte Dienstleistung entweder angelaufen oder auf Warteschlange gesetzt ist, wird die Steuerung wieder an das aufrufende Programm zurückgegeben, und die Unterbrechungsroutinen setzen die Operation bis zum Abschluß fort.
Ein dritter, kleiner, aber entscheidend wichtiger Bereich der S/88 kundenspezifischen Firmware ist eine Modifikation des S/88 OS (Betriebssystems), um die acht DMAC Interrupts abzufangen und als Vektor in die kundenspezifischen Bearbeitungsprogramme einzufügen, jedoch transparent für das S/88 OS. Das beinhaltet Modifikationen an der Vektortabelle im OS in Standard-Architektur MC68020 für Ebene 6 (die im Normalfall für Stromausfall selbstvektoriert ist) und Setzten der kundenspezifischen Interrupt-Bearbeitungsprogramme in das OS. Das ist eine bevorzugte Implementierung; jedoch, wie man nachstehend im Abschnitt bezüglich der Initialisierungsroutinen für Interrupts noch sehen wird, kann die Logik in der BCU 156 so eingerichtet werden, daß sie einen Vektor auf den örtlichen Bus 223 legt und damit die Notwendigkeit einer Vektormodifikation ausschließt.
Die gesamte S/88 Firmware für die bevorzugte Ausführungsform ist in MC68020 Assemblersprache geschrieben und kann so nicht ordentlich in Mikrocode ausgedrückt werden. Sie gilt als Firmware wegen der Art ihrer Funktionen.
Für den S/370 Prozessor 85 gibt es vier Kategorien der kundenspezifischen Firmware:
1. Mikrocodierte E/A-Anweisungen, die zum S/88 Pseudokanal gehen.
2. Behandlung asynchroner Meldungen, die vom S/88 kommen, einschließlich E/A-Interrupts.
3. Pflege der Konfigurationsdaten und des Status von allen (emulierten) S/370 E/A-Vorrichtungen, und
4. Implementierung einer Teilmenge von Anwenderhandbuch- Operationen.
Die gesamte obige Spezialfirmware ist in S/370 Mikrocode geschrieben und benutzt vorher bestehende Funktions-Subroutinen wenn immer möglich.
Es gibt im S/370 zehn Anweisungen vom E/A-Typ, die im Hinblick auf die Beschreibung in den Fig. 44 A-I näher diskutiert werden sollen.
CLRCH - clear channel (nur Kanal-Operation)
CLRIO - clear E/A
HDV - halt device
HIO - halt I/O
RIO - resume I/O
SIO - resume I/O
SIOF - start I/O fast
STIDC - store channel ID (nur Kanal-Operation)
TCH - test channel (nur Kanal-Operation)
TIO - test I/O
Jede dieser Anweisungen ist in Mikrocode implementiert, so daß alle wesentlichen Informationen in S/88 über den Mailbox- Mechanismus an EXEC370 geschickt werden, wobei die Übereinstimmung mit der S/370 Architektur gewahrt bleibt.
Verschiedene unterschiedliche Hardware-Zustände im Adapter 154 führen zur Aktivierung des 'Adapter Attention' Request, der seinerseits eine der möglichen Ursachen einer 'Forced exception' auf Mikrocode-Ebene im S/370 Prozessor 85 ist. Die Bedienung dieser Ausnahme durch den Mikrocode geschieht zwischen S/370 Anweisungen (sofort, wenn das PE 85 im Wartezustand ist). Die häufigste und allgemeine Ursache des 'Adapter Attention' ist der Eingang einer Meldung vom E/A-Pseudo-Kanal S/88 beim PE 85 in den festen Message-Q-Bereich 189 der IOA- Sektion des S/370 Hauptspeichers.
Das existierende S/370 Mikrocode-Ausnahmebearbeitungsprogramm wird für den Fall 'Adapter Attention' modifiziert. Der Code testet den Adapter-154-Status, um die Ursache für den Request zu bestimmen, und paßt nur das Behandeln des 'Q-not-empty' (was Message Received bedeutet) den Kundenwünschen an; jede sonstige Ursache führt zum unmodifizierten Code zur Behandlung zurück.
Die definierten Kategorien der eingegangenen Meldungen sind:
0000 NOP: No Operation.
0001 RESET: Ruft die existierende S/370 Programmrückstellungs-Routine auf.
0002 CLEAR RESET: Ruft die existierende S/370 Clear Reset Routine auf.
0003 HALT: Hält die S/370 Programmausführung an, schaltet ISTEP-Modus ein.
0004 STEP: Anweisungsschritt; eine Anweisung wird ausgeführt, dann HALT.
0005 RUN: Stellt ISTEP Modus zurück; nimmt Programmausführung wieder auf.
0006 LPSW: Führt S/370 Funktion 'Load PSW' aus unter Verwendung eines PSW, das innerhalb der Meldung vorgesehen ist. Verläßt HALTED Zustand.
0007 SMSG: Statusmeldung - aktualisiert Status-Bits, für eine oder mehr konfigurierte E/A- Vorrichtungen in der örtlichen (IOA) Vorrichtungs-Status-Tabelle.
0008 IMSG: Interrupt Meldung - setzt einen S/370 E/A-Interrupt entweder in Warteschlange oder gibt ihn direkt an den S/370, je nach Zustand der Kanalmaske.
Die obigen Meldungstypen 0001-0006 sind manuelle S/370 Operationen zur Zustandskontrolle, die sich aus der Anwendereingabe an der (emulierten) S/370 Systemkonsole ergeben. Sie können auch von EXEC370 direkt erzwungen werden, je nachdem, ob sie für eine Fehlerberichtigung oder für eine Synchronisation benötigt werden. Meldungstyp 0007 wird benutzt zum Informieren des S/370 Systems über asynchrone Statusveränderungen der E/A-Vorrichtungen, wie Stromverlust, EIN/AUS-LEITUNGS- Veränderungen, von der Vorrichtung gefundene Fehler usw. Es kann auch erweitert werden auf Allgemeinzweck-Kommunikation vom S/88 zum S/370. Meldungstyp 0008 ist der Träger zum Melden eines End-of-I/O-Betriebsstatus an den S/370 - entweder normal oder durch Fehler-Ende-Bedingungen. Es führt immer zu einem letztendlichen Programm-Interrupt und einer Vorrichtungsstatus-Tabellen-Modifizierung im S/370.
Jetzt sollen bestimmte Details der Funktionen, Schnittstelle, Protokolle und Anweisungsflüsse der ETIO und EXEC370 diskutiert werden.

System-Mikrocode-Entwurf

1. Einführung

Fig. 38 illustriert den Mikrocodeentwurf für eine bevorzugte Anwendungsform der vorliegenden Verbesserung. Der auf der S/370 Prozessoreinheit (jedes Prozessorelement, wie z. B. 85) laufende Code wird im Steuerspeicher 171 gehalten und interpretiert S/370 Anweisungen, wenn sie vom PE 85 ausgeführt werden. Die mikrocodierten Anweisungen für die Start-E/A, Interrupt-Bearbeitung, Bedienerfunktionen, Maschinenprüfung und Mikroprogramm-Erstladen/Programmladen (IML/IPL) sind spezifisch dazu entworfen, über die Schnittstelle mit dem S/88 Mikrocode zusammenzuwirken, wie in der Figur angegeben ist. Die Schnittstelle beinhaltet die gemeinsamen Hardwareeinrichtungen der Schnittstellenlogik 81, einschließlich des örtlichen Speichers 210, S/370 Cache 340 und S/370 Realspeicherraum 162 mit Interrupt-Fähigkeit für den Mikrocode beider Prozessoren 85 und 62. Im S/88 Code beinhaltet der S/370 Mikrocodetreiber CCW-Umwandlung, Interruptbearbeitungsprogramm, Fehlerbearbeitungsprogramm, IML/IPL und Synchronisierungscode, die mit einer S/88 Applikationsschnittstelle (EXEC/370) und dem S/88 OS zusammenarbeiten.
Der fehlertolerante Prozessor 62 führt alle E/A, Diagnostik, Fehlerisolierung, IPL/IML und Synchronisation für das System durch. Dieses System wird nicht als Coprozessorsystem angesehen, weil unter dem Gesichtspunkt des Anwenders S/370 Pro gramme die einzigen laufenden Programme sind. Der Systemverwalter kann die Systemattribute über das S/88 fehlertolerante Betriebssystem steuern. Die Primärfunktion des S/88 OS und das Applikations-EXEC/370 ist eine E/A-Umwandlung mit einem multiplen 370 Kanal-Aussehen. Alle Systemfehler- und Behebungsfunktionen und dynamischen Einsatzmittelzuteilungsfunktionen werden vom S/88 OS gehandhabt. Maschinenprüf- und Bedienerfunktionen, die vorher vom S/370 OS gehandhabt wurden, werden jetzt an das S/88 OS weitergeben, so daß die Funktionen jetzt auf fehlertolerante Weise gehandhabt werden können.
Fig. 39 illustriert die Ausführung eines S/370 E/A-Befehls, in diesem Beispiel ein Befehl 'Start-E/A'. Die von der S/370 Anweisung, dem S/370 Mikrocode, der Kopplungshardware (PE85 an PE62), dem Kopplungs-Mikrocode ETIO (abgearbeitet auf dem PE62) und dem S/88 Programm EXEC 370 vorgenommenen Aktionen werden kurz gezeigt, wobei der Endschritt die Ausführung des S/370 SIO auf dem S/88 Prozessor PE62 ist.
Fig. 40 ist eine vereinfachte Übersicht, die kurz bestimmte Komponenten und Funktionen des verbesserten Systems im Verhältnis zum EXEC 370 und dem Mikrocodetreiber zeigt, der bei der SIO Ausführung benutzt wurde, zusammen mit dem Steuerfluß, Datenfluß, den Signalen und der Hardware/Code- Partitionierung.

2. ETIO/EXEC 370 PROGRAMMSCHNITTSTELLE - Fig. 41A-H, 42

In diesem Abschnitt werden die folgenden Ausdrücke gebraucht:
EXEC370 - Alle auf dem PE62 laufende S/88 Software, die zur Emulierung und Unterstützung der externen S/270 Vorrichtungen, Dienstleistungen, Konfiguration, Bedienerkonsole usw. gehört und im Mikrocode-Speicher 174 gespeichert sind. Weniger häufig benutzte EXEC370 kann auch im Cache 173 gespeichert werden.
S/370 MIKROCODE - Dieser Mikrocode läuft auf dem S/370 Prozessor 85, unterstützt die S/370 Prozessoroperationen und ist im Speicher 171 gespeichert.
ETIO - Die Mikrocode-Schnittstelle zwischen EXEC370 und der BCU 156-Hardware, wird im Speicher 174 gehalten.
S/370 PE85 Mikrocode und EXEC360 kommunizieren miteinander über ein "Protokoll", Fig. 41A. Das PE 85 Mikrocode sendet eine Meldung an EXEC370 und fordert die Ausführung von Funktionen wie E/A an, EXEC370 sendet Meldungen, die den Abschluß der E/A-Funktionen, Meldungen betreffend die E/A-Vorrichtung und Kanalstatusänderungen angeben, sowie Meldungen, die das PE85 Mikrocode zum Ausführen spezifischer S/370 CPU-Funktionen betreffen. Diese Meldungen (die später noch detailliert beschrieben werden) werden zwischen PE85 Mikrocode und EXEC370 über Hardware übertragen, die Cache-Controller 153, Adapter 154, BCU 156 und seinen DMAC 209 usw. beinhaltet. Diese Meldungssübertragungsdienstleistung wird durch den ETIO dem EXEC370 zur Verfügung gestellt.
Jetzt wird die Schnittstelle zwischen ETIO und EXEXC370 sowie das Protokoll zwischen PE85 Mikrocode und EXEC370 beschrieben.
Die Interface Fig. 41B zwischen EXEC370, der S/370 externen Unterstützungssoftware, die vom S/88 ausgeführt wird, und dem BCU Mikrocodetreiber (ETIO), der auf dem PE 62 läuft, besteht aus einem Satz Warteschlangen und Puffern, die im Speicher 210 resident sind, einer Ereignis-ID, einer Variablen EXBUSY und einer Subroutine-Aufrufsequenz. Die Subroutine CALL Interface initiiert Datentransferoperationen zwischen S/88 und S/370 und initialisiert den DMAC 209 und die BCU 150 beim S/88-Neubooten. Die Warteschlangen-Schnittstelle wird benutzt, um Arbeitselemente zu verfolgen, bis sie verarbeitet werden können, und die Ereignis-ID-Schnittstelle (ein Interrupt an S/88) benachrichtigt EXEC370, wenn Arbeit auf Warteschlange gesetzt wurde.
Im Speicher 210 gibt es sechzehn 4kB Blöcke 500, Fig. 41C. Vierzehn (500-0 bis 500-13) werden als 4kB Blockpuffer benutzt. Die restlichen zwei unterteilen sich in zweiunddreißig 256-Byte-Blöcke 501-0 bis 501-31. Vier Blöcke 501-0 bis 501-3 werden benutzt zur Hardware-Kommunikation, einer 501-4 für Warteschlangen (Qs) und sonstige Variable, die EXEC370 und ETIO gemeinsam sind. Die restlichen 27 werden benutzt als Arbeits-Warteschlangenpuffer (WQB) 501-5 bis 501-31. Im Adressenraum, der gleichbedeutend mit den Blöcken 501-0 und 501-1 ist, werden den BCU 156 Befehlen (ausgeführt vom PE 62) 256 Bytes zugeteilt und den DMAC-Register-Adressen werden 256 Bytes zugeteilt zum Zugriff durch das PE62, wie im Hinblick auf BCU-Operationen bereits beschrieben wurde. Jeder dieser siebenundzwanzig Arbeitswarteschlangenpuffer hält Daten, die einer spezifischen Aufgabe oder Dienstleistungsanforderung zugehörig sind. Sechsundzwanzig WQBs werden benutzt, um die PE85 Mikrocode-initiierten Requests zu bedienen. Der restliche WQB (EXWQB) 501-31 ist reserviert für Dienstleistungsanforderungen, die vom S/88 eingeleitet werden und an das PE85 Mikrocode geschickt werden; er tritt nie am freeQ, Fig. 41E, in Erscheinung. Jeder WQB wird durch eine Basisadresse und einen Offset-Wert, der im DMAC 109 gespeichert ist, adressiert.
Jeder WQB, Fig. 41D, enthält einen 16-Byte Mailblock 505, einen 16-Byte-Parameterblock 506, und einen 224-Byte vorrichtungsspezifischen Arbeitsbereich 507. Der Mailblock 505 enthält Daten, die zwischen dem EXEC370 und dem PE85 Mikrocode weitergereicht werden. Sein Inhalt ist durch die ETIO Schnittstelle transparent. Der Parameterblock 506 enthält Parameter, die zwischen ETIO und EXEC370 weitergereicht werden, in der Regel im Hinblick auf die Übertragung von Daten zwischen dem örtlichen Speicher 210 und dem Hauptspeicher 162. Der Arbeitsbereich 507 gehört dem EXEC370. Er enthält Informationen über den Fortschritt der angeforderten Operation, den augenblicklichen S/370 Vorrichtungsstatus, mögliche Anwenderdaten, Typ der S/88 Vorrichtung, Zeiger auf andere EXEC370 Steuerblöcke, Fehlerauftrittsinformationen usw.
Der Mail-Block 505 umfaßt vier Felder, enthaltend S/370 E/A- Informationen, die zwischen dem PE85 Mikrocode und dem EXEC370 weitergereicht werden:
OP - Dieses Feld enthält einen Request entweder vom EXEC370 oder vom PE85 Mikrocode.
CUA - 16-Bit Kanaleinheits-Adresse.
CAW - 32-Bit S/370 Kanaladreßwort des Hex-Orts 48 im S/370 Speicher 162, als die zugehörige E/A-Anweisung ausgegeben wurde.
CCW - S/370 Kanalbefehlswort, das vom obigen CAW adressiert wurde. Wenn EXEC370 eine Interruptangabe zurückgibt, enthält dieses Feld das CSW, das S/370-Kanalstatuswort.
Der Parameterblock 506 enthält sechs Parameter, die benutzt werden, wenn vom EXEC370 ein Datentransfer zwischen dem Speicher 210 und dem Hauptspeicher 162 angefordert wird.
1. req - ETIO Anforderungsfeld:
0 no operation
1 Schreibt Inhalt des Mailblocks in die PE85 Meldungswarteschlange 189 in Speicher 162 und gibt dann auf Leitung 256a einen BCU Request an PU aus.
2 Liest Daten vom S/370 Speicher.
3 Schreibt Daten in den S/370 Speicher.
2. ret - Ergebnisse des vom "req"-Feld gemachten Requests. EXEC370 garantiert, daß dieses Feld ursprünglich Null ist. Wenn bei Rückgabe nicht Null, zeigt ETIO einen Fehler irgend eines Typs an.
3. COUNT - Anzahl der zu übertragenden Bytes.
4. S/370 ADDR - Ort im S/370 Speicher, mit dem der Datenbereich beginnt. Das ist nicht notwendigerweise ein CCW Adressenfeldwert.
5. key - Dieses 16-Bit Feld enthält wie folgt:

Bitmuster

ppkkkk10 00000000
dabei ist pp (Priorität) = 00 und kkkk = der richtige S/370 Speicherschutzschlüssel.
Buff Addr - der Ort im Speicher 210 an dem der Datenbereich beginnt. Er kann innerhalb eines 4k Puffers liegen oder ein WQB sein. EXEC370 stellt die folgende Beziehung sicher: (S/370 ADDR modulo 4) = (Buff Addr modulo 4).
EXEC370 benutzt Warteschlangen zum Beibehalten der WQBs. Der Warteschlangen-Kommunikationsbereich 501-4 ist 256 Bytes lang und sitzt am Offset 400 (hex) im Speicher 210. Fig. 41E zeigt die Warteschlangen, die zwischen ETIO und EXEC370 definiert sind, zum Halten der Zeigereinträge auf die WQBs:
freeQ 510 hält Zeiger auf die augenblicklich nicht gebrauchten WQBs.
workQ 511 hält Zeiger auf WQBs, die auf Abarbeiten durch EXEC370 warten.
S/3701Q 512 hält Zeiger auf WQBs, die auf Meldungsübertragung von EXEC370 auf PE85 warten.
S/3702Q 513 hält Zeiger auf WQBs, die auf Datentransfer vom Cache-Controller 153 auf S/88 warten.
S/3703Q 514 hält Zeiger auf WQBs, die auf Datentransfer vom S/88 auf Cache-Controller 153 warten.
S88Q 515 hält Zeiger auf WQBs nach Abschluß der ETIO Dienstleistung.
Fig. 41E zeigt den Pfad der WQBs durch die Warteschlangen. Alle Warteschlangen werden durch EXEC370 beim Reboot initialisiert. Leere WQBs werden auf freeQ gehalten. ETIO nimmt sie aus nach Bedarf dem freeQ, um die Verbindungsgliedliste 516 zu füllen. Der DMAC 209 legt S/370 Mailbox-Einträge über die Verbindungsgliedliste 516 aus dem Mailbox-Bereich 188 des Speichers 162 in die Mailbox-Bereiche leerer WQBs. WQBs auf der Verbindungsgliedliste, die gefüllt wurden, werden von ETIO zum workQ 511 verschoben. Wenn ETIO einen (oder mehrere) WQBs auf workQ 511 legt und EXEC370 nicht busy ist, teilt ETIO die EX370-Ereignis-ID mit. EXEC370 zieht den WQB aus workQ heraus, bevor es die Anforderung bedient.
Während der Bearbeitung der Anforderung können Daten zwischen dem Cache-Controller 153 und dem Puffer (WQB oder Block- Puffer) übertragen werden müssen oder eine Meldung kann an das PE85 Mikrocode geschickt werden müssen. ETIO übernimmt diese Dienstleistung für das EXEC370. EXEC370 ruft ETIO auf, das die richtige BCU-Operation einleitet, oder, wenn das Hardware-Betriebsmittel busy ist, den WQB auf die richtigen S/370 Q legt. Jede der drei Dienstleistungen (Meldungen an S/370 schicken, Daten zum S/370 übertragen, und Daten vom S/370 übertragen) hat ihre eigenen Warteschlangen 512, 513, 514. WQBs werden vom ETIO Code zu einer der S/370 Warteschlangen hinzugefügt während sie am EXEC370-Faden hängen. Wenn die E/A-Dienstleistung abgeschlossen ist, setzt die ETIO Interrupt-Routine den WQB auf die S88 Q 515; und, wenn EXEC370 nicht busy ist, übermittelt sie die EX370 Ereignis- ID.
Fig. 42 illustriert die Bewegung der WQBs durch die Warteschlangen zusammen mit den Schnittstellen zwischen EXEC370, ETIO, Schnittstellen-Hardware 89 und S/370 Mikrocode. Wenn der ursprüngliche Work-Request vollständig abgearbeitet ist, d.i. die Datenübertragungen abgeschlossen sind, wird (ggf.) der E/A-Interrupt zum PE85 geschickt; und EXEC 370 gibt den WQB an freeQ zurück. EXEC370 bekommt dann seine nächste Aufgabe durch Prüfen zunächst des S88 Q 515 und dann der workQ 511. Wenn beide leer sind, setzt EXEC370 eine EXBUSY-Variable auf Null und wartet darauf, daß das EX370 Ereignis gemeldet wird. Sobald es gemeldet wird setzt EXEC370 EXBUSY auf 1, noch bevor es mit dem Verarbeiten anfängt.
Alle Warteschlangen, die EX370 Ereignis-ID und die EXBUSY- Variable residieren im Queue comm Bereich 501-4 in Speicher 210, wie in Fig. 41F gezeigt wird. Jede Warteschlange ist von Natur aus kreisförmig, wie in Fig. 41G gezeigt wird, mit zwei Indextypzeigern: Ein Füllindex 517 und ein Leerindex 518. Der Füllindex 517 zeigt auf den nächsten einzufüllenden Warteschlangeneintrag, und der Leerindex 518 zeigt auf den nächsten auszuleerenden Eintrag. Wenn der Leerindex gleich dem Füllindex ist, ist die Warteschlange leer. Alle sechs Warteschlangen laufen nie über, da jede 32 Einträge aufnehmen kann und nur 27 WQBs vorkommen.
Jede Warteschlange beinhaltet ferner:
qid Identifiziert diese Warteschlange.
QSIZE Anzahl der Einträge in dieser Warteschlange (n)
Q(i) Adresseneinträge, die in der Warteschlange auf WQB deuten.
Der Hardware-Kommunikationsbereich enthält 1024 Bytes. Der BCU-Kommunikationsbereich benutzt 512 Bytes Adressenraum. Die Verbindungsgliedlisten 516 verbrauchen 480 Bytes. 32 Bytes sind reserviert für andere Hardware-Kommunikationsnutzung. Die Verbindungsgliedliste 316, Fig. 41H, wird vom DMAC 209 benutzt, um Mailblock-Datenwörter aus dem Mailboxbereich 188 des Speichers 162 hereinzubringen. WQBs aus der freeQ 510 werden benutzt, um Einträge in die Verbindungsgliedliste 516 einzusetzen. Jeder Verbindungsgliedlisteneintrag enthält 10 Bytes und identifiziert die Adresse des WQB in Speicher 210, an die die Daten, die Byte-Zählung der zu übertragenden Daten (16) und die Adresse des nächsten Verbindungsgliedeintrags in der Liste geschickt werden müssen. Der DMAC 209 (Kanal 0) unterbricht S/88, wenn ein Verbindungsgliedeintrag aufgerufen wird, der als nächste Verbindungsadresse Null enthält. Die augenblickliche Position des DMAC 209 (Kanal 0) in der Liste ist jederzeit für die Software greifbar.
Zusätzlich zu seinen Interrupt-Eintragspunkten hat ETIO zwei extern aufrufbare Eintragspunkte:
etio init
etio(wbn)
EXEC370 ruft etio init einmal je S/88 Reboot auf, während EXEC370 die Initialisierung durchführt. Die Warteschlangen wurden bereits initialisiert und das Ereignis-ID-Feld ist gültig. Das PE85 Mikrocode ist noch nicht operativ, jedoch kann er im IML-Prozeß (Initial Microprogram Load) stehen.
EXEC370 ruft etio(wbn) auf, wenn immer es wünscht, Daten oder Meldungen von/zu S/370 übertragen zu lassen.
Der Parameter wbn ist eine ganzzahlige Zwei-Byte Arbeitswarteschlangenpuffer-Zahl (Work Queue Buffer Number), die den WQB identifiziert, der die Dienstleistungsanforderung enthält. Wbn ist ein Indexwert zwischen 0 und 27. Die Dienstleistungsanforderung wird identifiziert durch das req-Feld im Parameterblock. Die req-Feld-Werte sind: 1 = Schreibe den Inhalt dieses Mailblocks in die S/370 Meldungswarteschlange 189 im Speicher 162 und gib dann einen Request BCU an PU aus; 2 = Lese Daten vom S/370 Speicher 162 in den spezifizierten Bereich des Speichers 210; und 3 = Schreibe Daten in den S/370 Speicher aus dem spezifizierten Bereich des Speichers 210.
Das Subroutine-ETIO setzt diesen WQB in die Warteschlange des S/3701Q, S/37002Q oder S/37003Q, wenn die angeforderte E/A- Funktion nicht sofort anlaufen kann. Die ETIO Interrupt- Routine zieht den nächsten WQB aus der richtigen S/370 Q Warteschlange heraus, sobald die vorangehende Operation beendet ist.
Wenn das req-Feld eine 1 enthält, darf das PE85 Mikrocode nicht benachrichtigt werden (z. B. durch einen Interrupt) bis der Mailbox-Eintrag im S/370 Meldungswarteschlangenbereich 189 des Speichers 162 steht.
Wenn die S/370 Meldungswarteschlange 189 voll ist, identifiziert ein Fehler im ret-Feld des Parm-Blocks das Problem gegenüber dem EXEC370. Falls erforderlich, kann EXEC370 eine Backup-Warteschlangen-Unterstützung vorsehen.

3. EXEC370, S/370 MIKROCODE-PROTOKOLL

Die Kommunikation zwischen EXEC370 und dem S/370 Mikrocode benötigt eine Vorrichtungs-Status-Tabelle (DST - Device Status Table) mit einem Eintrag für jede E/A-Vorrichtung im S/370 Speicher 162. EXEC370 und S/370. Mikrocode kommunizieren miteinander über 16-Byte-Meldungen (siehe Mailblock 505 Fig. 41D), die hin- und hergeschickt werden. Es gibt eine Warteschlange, die die Meldungen in FIFO-Ordnung für den Empfänger an jedem Ende hält. Es gibt auch einen Mitteilungsmechanismus (PU an BCU- und BCU an PU-Leitungen). Im Mailblock 505 enthält das 16-Bit-S/360-Opcode-Feld "op" eine Anforderung oder Antwort entweder von EXEC370 oder S/370 Mikrocode. Die 16-Bit Kanaleinheitsadresse (CUA - Channel Unit Address) ist die Operandenadresse einer S/370 E/A-Anweisung. CAW ist ein 32- Bit Inhalt der Hex-Ortsstellen 48 im S/370 Speicher 162, wenn die E/A-Anweisung ausgegeben wurde, und beinhaltet den Speicherschlüssel. Das 8-Byte CCW wird vom obigen CAW adressiert. Wenn EXEC370 eine Interrupt-Anweisung zurückgibt, enthält dieses Feld das CSW. PE 85 speichert das CSW an der S/370 Hex-Ortsstelle 40 wenn es den E/A-Interrupt bewirkt. Das CUA- Feld bleibt unverändert.
Die OPERATION-Meldung wird vom S/370 Mikrocode an EXEC370 gesendet, wenn immer eine S/370 Anweisung auftritt, die teilweise oder vollständig von EXEC370 abgearbeitet werden muß. Die OPERATION-Meldung enthält die oben beschriebene Information im Hinblick auf den Mailblock 505 der Fig. 41D.
Die an den S/370 Mikrocode geschickten EXEC370-Meldungen beinhalten:
1. Die Meldung RESET (OP = 1) fordert, daß der S/370 Mikrocode einen S/370-Reset durchführt.
2. Die Meldung CLEAR RESET (OP = 2) fordert einen S/370 Reset und Clear Storage (Speicher löschen).
3. Die Meldung HALT fordert, daß der S/370 keine S/370 Anweisung abruft und auf weitere Anweisungen wartet. Die Meldung HALT beinhaltet ein OP-Feld = 3.
4. Die Meldung STEP (OP = 4) fordert, daß der S/370 Mikrocode eine S/370 Anweisung abruft und ausführt und dann in den HALT-Modus geht.
5. Die Meldung RUN (OP = 5) fordert, daß der S/370 Mikrocode in seinen Normalmodus eintritt, um S/370 Anweisungen abzurufen und auszuführen.
6. Die Meldung LPSW (OP = 6) fordert, daß der S/370 Mikrocode eine S/370 Anweisung LPSW (Load Program Status Word - Programmstatuswort laden) unter Verwendung der im Feld ADDRESS der Meldung LPSW spezifizierten Adresse durchführt. Sie kann benutzt werden, um den S/370 Mikrocode aus dem Zustand HALT herauszubringen.
7. Die Meldung SMSG (OP = 7) zeigt Statusänderungen für eine oder mehrere konfigurierte S/370 E/A-Vorrichtungen an.
8. Die Meldung IOINTR (OP = 8) zeigt den Abschluß einer E/A- Operation. Wenn der Kanal nicht mit OFF maskiert ist, wird der S/370 Mikrocode einen E/A-Interrupt einleiten. Wenn der Kanal mit OFF maskiert ist, wird der S/370 Mikrocode das CSW in der Vorrichtungsstatustabelle speichern und den Vorrichtungsstatus auf 01 (CSW gespeichert) setzen. Die Meldung IOINTR beinhaltet auch CUA und NC (gesetzt in DST CUA) im nächsten Feld.
Zwei Meldungen, FETCH und STORE, vom S/88 Cache-Controller 153 sind eher Logikfunktionen als Meldungen. Es muß ein gerader oder ungerader Wert für die Felder CNT und ADDRESS zugelassen werden. Ihre Felder sind:
BUF - 2 Bytes Pufferadresse im Speicher 210
CNT - 2 Bytes Byte-Zählung
ADDR - 4 Bytes S/370 Speicheradresse mit Schlüssel
Der S/370 Mikrocode unterhält eine Tabelle, die Informationen über den Status jeder adressierbaren S/370 Vorrichtung enthält. Die Hauptinformationsstücke sind:
Device Condition (Vorrichtungszustand) - erlaubt das unmittelbare Einstellen des CR (S/370 Zustandsregister) nach einem TI0, SI0 usw.
Device next (Vorrichtung nächster Zustand) - der nächste Zustand, der nach einem E/A-Interrupt benutzt werden soll.
Device CSW - beibehalten für maskierte S/370 E/A- Interrupts.
Für eine S/370 Vorrichtung sind vier unterschiedliche Vorrichtungszustände im DST (CUA) möglich:
00 Device Ready (Vorrichtung betriebsbereit)
01 Device not ready (Vorrichtung nicht betriebsbereit, CSW gespeichert
10 Device Busy (Vorrichtung beschäftigt)
11 Device not Operational (Vorrichtung nicht operativ)
Bei Abschluß einer E/A-Operation auf einer S/370 Vorrichtung wird ein CSW (Channel Status Word - Kanalstatuswort) vom Kanal an die CPU geschickt. Wenn der Kanal mit OFF maskiert ist, akzeptiert die CPU das CSW nicht.
In der vorliegenden Anwendung, wenn der Kanal maskiert ist, zwischenspeichert der S/370 Mikrocode das CSW und setzt den DST (CUA) Zustand auf 01. Ein nachfolgendes TI0 oder SI0 führt dazu, daß das zwischengespeicherte CSW abgespeichert wird und der Zustandscode 01 (CSW gespeichert) in das CR gesetzt wird. Wenn der S/370 Mikrocode initialisiert wird, nimmt er an, daß alle Vorrichtungen nicht operativ sind. S/88 schickt eine ONLINE Meldung an jede zu unterstützende Vorrichtung. Die Vorrichtung wird durch ihre CUA (Control Unit Address - Steuereinheitsadresse) identifiziert.

4. Anweisungsflüsse zwischen S/370 Mikrocode und EXEC370

Wenn das PE85 S/370 Programmanweisungsketten ausführt, trifft es von Zeit zu Zeit auf eine E/A-Anweisung, die in der vorliegenden Anwendung vom S/88 Prozessor 62, zugehöriger Hardware, Firmware und Software ausgeführt wird. Die Fig. 44A-L (und die oben genannte Fig. 43) illustrieren Mikrocode- Sequenzflüsse, die zur Ausführung dieser S/370 E/A-Anweisungen benutzt werden. Die BCU 156 (und Adapter 154) sind der primäre Hardware-Kopplungsmechanismus zur Durchführung der letztendlichen S/370 E/A-Anweisungsausführung durch die S/88 Hardware. Innerhalb der BCU 156 ist der DMAC 209 der Haupt- "Verkehrspolizist", der den Operations- und Datenfluß lenkt. Kanal 0 des DMAC 209 nimmt E/A-Befehle vom S/370 auf, Kanal 1 regelt den Datenfluß vom S/370, Kanal 2 regelt den Datenfluß zum S/370, und Kanal 3 schickt Interrupt- (und andere) Mel dungen an S/370. Der örtliche Speicher 210 in der BCU 156 bildet den Kommunikationsbereich zwischen S/370 und S/88.
Der örtliche Bus 223/247 koppelt den S/88 Prozessor 62 an den DMAC 209 und an den örtlichen Speicher 210. Der örtliche Bus 223/247 koppelt den DMAC 209 und den Speicher 210 mit dem S/370 über Beschleunigungs-Hardware in der BCU 156 und im Adapter 154.
S/370 E/A-Anweisungen werden den S/370 Mikrocode-Routinen zum Abarbeiten innerhalb des S/370 zugeteilt, und ein S/88 Applikationsprogramm EXEC 370 (zusammen mit seinem zugehörigen S/88 ETIO Mikrocode) bewirken die letztendliche E/A- Ausführung. Der Adapter 154 und die BCU 156 bilden die Hardwareverbindung zwischen dem S/370 und dem S/88 Code. Die E/A- Mikrocode-Anlaufroutine weist eine Tabelle DST auf, die den Status jeder Vorrichtung verfolgt, z. B., ist sie augenblicklich verfügbar, hat sie bereits einen DSIO ausgegeben, ist sie busy, hat sie einen Interrupt zurückbekommen. Diese Information ist im Zustandscode CC enthalten.
Der vorliegende Abschnitt beschreibt den Anweisungsfluß für verschiedene S/370 E/A-Operationen. Bestimmte spezifische Prozesse und Termini, die in diesem Abschnitt benutzt werden, werden am Ende des Abschnitts definiert. Die Operationen sind wie folgt:
1. Clear Channel Fig. 44A - Diese Anweisung bewirkt das Durchführen eines E/A-System-Resets im angesprochenen Kanal mit Signalisierung eines System-Resets an alle Vorrichtungen des angesprochenen Kanals. Der S/370 Mikrocode weiß nicht, welche Vorrichtungen in Wirklichkeit auf diesem Kanal liegen. Daher setzt er CC = 3 für alle DST- Einträge auf diesem Kanal. Anschließend sendet EXEC370 SMSG(s) zur Neudefinierung der Konfiguration auf diesem Kanal.
Der freizumachende Kanal wird mit den Bits 16 bis einschl. 23 der Anweisungsadresse angesprochen. Sobald der S/370 Mikrocode die Steuerung von der Verteilerroutine erhält, beginnt er mit dem Prüfen der Kanaladresse. Die Kanaladresse ist entweder gültig oder ungültig. Wenn die Kanaladresse ungültig ist, wird das Zustandsregister (CR) auf 3 gesetzt und S/370 kehrt zur nächsten sequentiellen Anweisung zurück. Ein Kanal, der vom S/370 Mikrocode unterstützt wird, wird als gültige Kanaladresse führend angesehen. Für 'Kanaladresse gültig' schickt der S/370 Mikrocode eine den Kanal freimachen Meldung an EXEC370. Dann geht er durch alle Einträge in der Vorrichtungs-Status-Tabelle (DST) für diesen Kanal. Alle Zustandscode-Felder werden auf 3 gesetzt, was bedeutet 'Nicht verfügbar', und alle gefundenen schwebenden Einträge für die Interrupt-Tabelle (PIT) werden für eine Liste der freien PITs freigegeben. Dann setzt der S/370 Mikrocode das Zustandsregister auf 0 und geht zur nächsten sequentiellen Anweisung über. Inzwischen führt EXEC370, sobald es die Meldung Kanal Freimachen erhält, einen E/A-System-Reset für alle Vorrichtungen auf dem angesprochenen Kanal durch. Dann stellt es fest, welche Vorrichtungen online sind und sendet eine Statusmeldung an den S/370 Mikrocode, um die Konfiguration auf diesem Kanal neu zu definieren. Sobald der S/370 Mikrocode die Statusmeldung erhält, modifiziert er den Zustandscode in der Vorrichtungsstatustabelle für jede in der Statusmeldung angesprochene Vorrichuung.
2. Clear I/O Fig. 44B - diese Anweisung unterbricht die Ausführung einer S/370 Anweisung, die im PE85 läuft, bis IMSG für die angesprochene CUA vom EXEC370 zurückgegeben wird.
Wenn der S/370 Mikrocode die Steuerung von der Verteilerroutine erhält, holt er die Steuereinheitadresse CUA von der Adresse am oberen Ende der Anweisung. Unter Verwendung der Steuereinheitadresse findet er den richtigen Eintrag in der Vorrichtungsstatustabelle DST für diese Vorrichtung. Er überprüft den Wert des Zustandscodes CC. Es gibt hier drei Optionen: (1) CC ist Null oder 3, (2) CC ist 2 oder CC ist 1 und der nächste Zustand NC ist 2, und (3) CC ist 2 oder CC ist 1.
In der ersten Option, CC ist Null oder 3, setzt der S/370 Mikrocode das Zustandsregister nur auf den Wert CC und geht zur nächsten sequentiellen Anweisung über.
Wenn CC gleich 1 ist, gibt es einen anhängigen Interrupt in der Tabelle der schwebenden Interrupts (PIT). In diesem Fall geht der S/370 Mikrocode zur Tabelle der eingetragenen anhängigen Interrupts und überprüft den Wert von NC.
Im Fall, daß CC gleich 2 oder CC gleich 1 und NC gleich 2 ist, schickt der S/370 eine Meldung E/A Freimachen an EXEC 370. Er wartet auf die Quittung und leert alle anhängigen Interrupt-Einträge, die dieser Vorrichtung zugeteilt sind. Dann wartet er darauf, daß die Interrupt- Meldung vom EXEC370 zurückgegeben wird. Inzwischen, wenn EXEC370 die Meldung E/A Freimachen erhält, führt es einen selektiven Reset der angesprochenen Vorrichtung durch, bildet ein Steuer-Status-Wort für die Vorrichtung, und gibt eine Interrupt-Meldung an den S/370 Mikrocode zurück. Wenn der S/370 Mikrocode die Interruptmeldung erhält, generiert er den PIT-Eintrag und trägt den NC und das CSW aus der Meldung ein. Der PIT-Eintrag wird dann mit dem DST-Eintrag verbunden.
Damit kommen wir zur dritten Option: CC ist gleich 2 oder CC ist gleich 1. Zu diesem Punkt gelangen wir auf einem von zwei Wegen. Der erste Weg ist, die Vorrichtung ist busy oder die Vorrichtung hat einen schwebenden Interrupt gesendet, bleibt aber busy. Das ist der Fall, in dem ein selektiver Reset ausgegeben wird. Der zweite Weg ist, daß die Vorrichtung einen schwebenden Interrupt hat, aber nicht mehr busy ist. Für beide Wege ist CC entweder 2 oder 1. Das ist die dritte Option. S/370 Mikrocode holt einen Interrupt, legt das CSW in den S/370-Speicher, setzt das Zustandsregister auf 1 und geht zur nächsten sequentiellen Anweisung über.
3. Halt Device (Fig. 44C) - Wenn der S/370 Mikrocode von der Zuteilungsroutine die Steuerung für eine Halt-Vorrichtung erhält, überprüft er den Zustandscode für den Eintrag der Statustabelle für die angesprochene Vorrichtung. Es gibt drei Optionen, ein Zustandscode ist 0 oder 2, Zustandscode ist 1, oder Zustandscode ist 3. In der ersten Option ist der Zustandscode 0 oder 2, der S/370 Mikrocode schickt eine Meldung 'Vorrichtung Halt' an das EXEC370. Dann setzt er die 16 Statusbits im S/370 CSW auf Null, setzt das Zustandsregister auf 1 und kehrt zur nächsten sequentiellen Anweisung zurück. Wenn inzwischen EXEC370 die Meldung 'Vorrichtung Halt' erhält, führt es die geeignete Funktion auf der angesprochenen Vorrichtung durch und gibt eine normale Interrupt-Meldung zurück. Wenn CC = 1, holt der S/370 Mikrocode den Interrupt aus der PIT- Tabelle, setzt ein CSW an die richtige Stelle in den S/370 Speicher, setzt das Zustandsregister auf 1 und geht zur nächsten sequentiellen Anweisung über. Für die dritte Option, CC ist gleich 3, setzt der S/370 Mikrocode nur das Zustandsregister gleich 3 und geht zur nächsten sequentiellen Anweisung über.
4. Halt I/O (Fig. 44C) - Auf dieser Beschreibungsstufe ist die Funktion für I/O Halt identisch mit der Funktion Vorrichtung Halt.
5. Resume I/O (Fig. 44D) - In einem S/370-System überprüft die RIO-Anweisung nur, ob der Kanal operativ ist, bevor die Anweisung akzeptiert wird. Der S/370 Mikrocode muß den CC auf die spezifische CUA überprüfen wie bei anderen E/A-Anweisungen. Das CAW wird nicht angezogen und kein CCW wird für diese Anweisung geholt.
Wenn der S/370 Mikrocode von der Verteilerroutine die Steuerung für eine Anweisung 'Resume I/O' erhält, überprüft er den Zustandscode für den Statuseintrag der angesprochenen Vorrichtung. Es gibt zwei Optionen: CC ist gleich 0, 1 oder 2 und CC ist gleich 3. Bei CC ist gleich 0, 1 oder 2 sendet der S/370 Mikrocode eine Meldung Resume I/O an das EXEC 370, setzt den Zustandscode auf 2 und setzt das Zustandsregister auf 0 und geht zur nächsten sequentiellen Anweisung über. Inzwischen, wenn EXEC370 die Meldung Resume I/O erhält, schaut es die Steuereinheitsadresse nach und fährt mit der vorher unterbrochenen E/A-Operation fort. Für die zweite Option, CC ist gleich 3, setzt der S/370 Mikrocode nur das Zustandsregister auf 3 und geht zur nächsten sequentiellen Anweisung über.
6. Start I/O (Fig. 44E) - Wenn der S/370 Mikrocode von der Verteilerroutine die Steuerung für eine Start-E/A- Anweisung erhält, benutzt er die Adresse der Steuereinheit, um den Eintrag in der Vorrichtungs-Status-Tabelle zu finden. Dann überprüft er den Zustandscode und da gibt es vier Optionen: CC ist gleich 0, CC ist gleich 1, CC ist gleich 2 und CC ist gleich 3. Bei CC ist gleich 0 ist die Vorrichtung bereit und der S/370 Mikrocode sendet eine Meldung 'Start E/A' an EXEC370, setzt CC gleich 2 in der Bedeutung 'Vorrichtung busy', setzt das Zustandsregister auf 0 in der Bedeutung 'akzeptiert', und geht zur nächsten sequentiellen Anweisung über. Inzwischen, wenn EXEC 370 die Meldung Start E/A erhält, benutzt es die Adresse der Steuereinheit, um die spezifische Vorrichtung zu finden, und läßt eine normale E/A-Operation an dieser Vorrichtung anlaufen. Für die zweite Option, CC ist gleich 1, holt der S/370 Mikrocode den Interrupt, setzt das CSW in den S/370 Speicher, setzt das CSW-Busy-Bit "an", setzt das Zustandsregister gleich 1 und geht zur nächsten Anweisung über. Bei der dritten Option, CC ist gleich 2, setzt der S/370 Mikrocode das CSW und die S/370 Speicherstelle 40X auf Null, schaltet das CSW-Busy-Bit ein, setzt das Zustandsregister gleich 1, und geht zur nächsten sequentiellen Anweisung über. Für die vierte Option, CC ist gleich 3, setzt der S/370 Mikrocode nur das Zustandsregister auf 3 (in der Bedeutung 'Vorrichtung nicht operativ'), und geht zur nächsten sequentiellen Anweisung über.
7. Start I/O Fast Release (Fig. 44F) - Wenn der S/370 Mikrocode von der Verteilerroutine die Steuerung für eine Anweisung 'Start I/O Fast' (E/A-Schnellstart) erhält, überprüft er den Zustandscode auf den angesprochenen DST- Eintrag. Da gibt es zwei Optionen, CC ist gleich 0, 1 oder 2, und CC ist gleich 3. Bei der ersten Option, CC ist gleich 0, 1 oder 2, sendet der S/370 Mikrocode eine Meldung 'Start I/O Fast' an das EXEC370, setzt CC gleich 2, das Zustandsregister auf 0, und geht zur nächsten sequentiellen Anweisung über. Sobald inzwischen EXEC370 eine E/A-Schnellstart-Anweisung erhält, läßt es die E/A- Operation anlaufen, wenn es kann; sonst gibt es eine Interrupt-Meldung mit einem CSW zurück, das einen Code 'verzögerter Zustand' enthält, der als normaler Interrupt wirkt, wenn er vom S/370 Mikrocode aufgenommen wird. Für die zweite Option, Zustandscode gleich 3, setzt der S/370 Mikrocode nur das Zustandsregister auf 3 und geht zur nächsten sequentiellen Anweisung über.
8. Test I/O (Fig. 44G) - Wenn der S/370 Mikrocode vom Verteilerroutine die Steuerung für eine Anweisung 'Test E/A' erhält, überprüft er den Zustandscode. Es gibt drei Optionen: CC ist gleich 0 oder 3, CC ist gleich 1, oder CC ist gleich 2. Bei CC ist gleich 0 oder 3 setzt der Mikrocode das Zustandsregister auf den CC-Wert, und geht zur nächsten sequentiellen Anweisung über. Bei der zweiten Option, CC ist gleich 1, holt der Mikrocode den Interrupt und setzt das CSW in den S/370-Speicher, setzt das Zustandsregister auf 1 in der Bedeutung CSW gespeichert, und geht zur nächsten sequentiellen Anweisung über. Für die dritte Option, CC ist gleich 2, setzt der Mikrocode den CSW-Bereich (40X) im S/370-Speicher auf Null, setzt das CSW-Busy-Bit auf "an", setzt das Zustandsregister auf 1, und geht zur nächsten sequentiellen Anweisung über.
9. Store Channel ID (Fig. 44H) - Wenn der S/370 Mikrocode von der Verteilerroutine die Steuerung für eine Anweisung 'Store Channel ID' erhält, überprüft er die Kanaladresse. Es gibt zwei Optionen, Kanaladresse gültig und Kanaladresse ungültig. Für die Option 'Kanal ungültig' setzt der Mikrocode das Zustandsregister auf 3, und geht zur nächsten sequentiellen Anweisung über. Für die Option Kanaladresse gültig, setzt der Mikrocode die S/370- Speicherstelle hexadezimal A8 auf hexadezimal 20000000. Dann setzt er das Zustandsregister auf 0, und geht zur nächsten sequentiellen Anweisung über.
10. Test Channel (Fig. 44I) - Wenn der S/370 Mikrocode von der Verteilerroutine die Steuerung für eine Anweisung 'Test Channel' erhält, überprüft er die Kanaladresse. Hier ist anzumerken, daß es für diesen Fluß zwei Hauptoptionen und drei Nebenoptionen gibt. Für die erste Hauptoption 'Kanaladresse ungültig', setzt der Mikrocode das Zustandsregister auf 3 und geht zur nächsten sequentiellen Anweisung über. Für die zweite Option, Kanaladresse gültig, überprüft der Mikrocode weiter alle DST- Einträge für diesen Kanal. Die erste Nebenoption tritt ein, wenn der Mikrocode einen DST-Eintrag für eine spezifische Vorrichtung mit CC ist gleich 1 findet, in der Bedeutung, daß diese Vorrichtung einen schwebenden Interrupt hat. Für diesen Fall setzt der Mikrocode das Zustandsregister auf 1 und geht zur nächsten sequentiellen Anweisung über. Wenn der Mikrocode keinen Eintrag CC ist gleich 1 gefunden hat, wenn er zum Ende der Liste der DST-Einträge kommt, dann überprüft er, ob es wenigstens einen Eintrag CC ist gleich 2 gibt. Wenn er einen findet, ist das die zweite Nebenoption; und in diesem Fall setzt der Mikrocode das Zustandsregister gleich 2 und geht zur nächsten sequentiellen Anweisung über. Ansonsten tritt die Nebenoption 3 ein und der Mikrocode setzt das Zustandsregister gleich 0 und geht zur nächsten sequentiellen Anweisung über.
11. Primary and Secondary Interrupts (Fig. 44J, 44K) - Die Ausdrücke Primär- und Sekundär-Interrupts sind S/370 Ausdrücke. Ein Primärinterrupt enthält wenigstens das Kanalende (CE) Status-Bit im CSW, das sich aus einer E/A- Operation ergibt. Ein Sekundärinterrupt ist entweder ein zweiter Interrupt, der Device End (DE) für die E/A- Operation enthält, oder er ist ein asynchroner Interrupt, der von der Vorrichtung-anfordernden Dienstleistung eingeleitet wurde.
In diesem Stadium der vorliegenden Beschreibung gibt es keinen Unterschied zwischen Primär- und Sekundär- Interrupts; daher soll hier nur der Primär-Interrupt beschrieben werden. Der Unterschied zwischen den E/A- maskierten und E/A-aktivierten Interrupts der Fig. 44J und K liegt darin, ob der E/A maskiert ist. D. h., ob der S/370 Prozessor einen Interrupt, der vom Kanal kommt, akzeptiert oder nicht. Wenn ein Interrupt vom S/370 Prozessor nicht akzeptiert wird, legt der Kanal den Interrupt auf Stapel, und er ist jetzt ein schwebender Interrupt, bis der S/370 Prozessor aktiviert wird. Wenn ein Interruptzustand auftritt während das EXEC370 eine spezifische Vorrichtungsoperation emuliert, baut es ein CSW auf und setzt es in eine Meldung, die es dann an den S/370 Mikrocode sendet. Wenn der Mikrocode diese Interrupt-Meldung erhält, überprüft er die S/370 Maske, ob der E/A maskiert oder aktiviert ist. Wenn der E/A maskiert ist (Fig. 44J), legt er den Interrupt auf Stapel. Eine Beschreibung des Interrupt-Stapel-Prozesses wird nachstehend gegeben. Wenn der S/370 Mikrocode die Maske überprüft und der E/A aktiviert ist (Fig. 44K), wird das Zustandscodefeld im DST- Eintrag für die unterbrechende Vorrichtung in der Interrupt-Meldung auf den nächsten Zustand (NC) gesetzt, das CSW aus der Meldung wird in den S/370 Speicher gesetzt und der Mikrocode bewirkt die Ausführung eines E/A- Interrupts.
12. S/370 I/O Masking Events (Fig. 44L) - Wenn der E/A maskiert ist, wenn das EXEC370 eine Interrupt-Meldung an den S/370 Mikrocode schickt, wird der Interrupt in einem Eintrag in einer Tabelle für schwebende Interrupts (PIT) auf Stapel gelegt. Zu einem nachfolgenden Zeitpunkt wird ir gend ein S/370 Ereignis auftreten, das zur Aktivierung der E/A-Interrupts führt. Das könnte sein infolge einer PSW-Ladeanweisung, einer Systemmaskierungssetzanweisung oder irgend eines Interrupts, für den die Maske die E/A aktiviert. Zu irgendeinem Zeitpunkt, wenn die PSW- Systemmaske so verändert wird, daß vorher maskierte E/A aktiviert werden, muß der S/370 Mikrocode prüfen, ob irgendwelche schwebenden Interrupts für diese Kanäle anhängig sind. Wenn keine gefunden werden, steigt der Mikrocode einfach zur nächsten sequentiellen Anweisung aus. Wenn jedoch einer gefunden wird, holt der Mikrocode den Interrupt aus der Tabelle, setzt das CSW in den S/370 Speicher und führt einen E/A-Interrupt durch.
Hier nachstehend werden nun diejenigen Prozesse beschrieben, die oben angezogen wurden.
1. Stacked Interrupt - Der Ausdruck 'gestapelter Interrupt' wird zusammen mit Interrupt-Meldungen benutzt, die beim S/370 Mikrocode eingehen wenn der S/370 E/A demaskiert wird. Interrupts sind in dem Vorrichtungs-Status-Bereich in einer Tabelle für schwebende Interrupts (Pending Interrupt Table - PIT) gestapelt. PIT-Einträge sind in FIFO-Ordnung verkettet mit dem DST Eintrag, der die S/370 Vorrichtung repräsentiert, die den Interrupt bewirkt. Stapeln eines Interrupts beinhaltet das Nehmen eines PIT- Eintrags von der freien Liste, Verketten desselben mit dem Ende der PIT-Liste für diesen DST-Eintrag, Setzen des CSW in das Statusfeld des PIT-Eintrags und des NC-Werts in das NC-Feld des PIT-Eintrags, und Setzen des CCW-Felds des DST auf "1". Setzen des CC auf "1" zeigt an, daß es einen anhängigen Interrupt für diese Vorrichtung gibt.
2. Pop Interrupt - Holen eines Interrupts beinhaltet Entketten des PIT-Eintrags oben auf der DST/PIT-Liste, Setzen des DST-Zustandscodes auf den Wert, der im NC-Feld des PIT-Eintrags gefunden wird, Beibehaltung des Statusfelds des PIT-Eintrags, der ein S/370 CSW enthält, und Zurückgeben des PIT-Eintrags an die freie Liste.
3. Send Message to EXEC370 - Fig. 43 kann beispielhaft für diese Beschreibung angezogen werden. Zu dem Zeitpunkt, wenn die Option CC gleich 0 ist, hat der S/370 Mikrocode entschieden, daß er eine Meldung an das EXEC370 schicken muß. Die Meldung ist in der Regel eine Start-E/A-Meldung. Für diese Meldung oder für jeden anderen Meldungstyp, den der S/370 Mikrocode aussendet, ist das Verfahren das gleiche. Der S/370 Mikrocode füllt das Datenfeld in einem Mailbox-Eintrag im Speicher 162 mit dem Inhalt der Meldung. Dann gibt er einen PU-an-BCU Request aus, der von der BCU-Logik 253 aufgenommen wird. Dann wartet der S/370 Mikrocode auf eine Rückquittierung. Inzwischen startet die BCU-Logik, wenn sie eine PU-an-CBU Anzeige erhalten hat, einen Speicherzugriff und eine DMA-Operation, um die Daten aus der Mailbox an den BCU-Speicher 210 zu schicken. Wenn die DMA komplett ist, gibt sie ein Quittungssignal an den S/370 Mikrocode, der dann mit der nächsten sequentiellen Programmanweisung fortfährt. Gleichzeitig unterbricht die DMAC-Logik das System 88. Die Software- Routine erhält die Steuerung, überprüft die Gültigkeit der Operation, und sendet dann eine Nachricht an den EXEC370, der dann die Meldung aus der Arbeitswarteschlange herauszieht.
4. Send message to S/370 Mikrocode - Es gibt mehrere unterschiedliche Meldungstypen, die das EXEC370 an den S/370 Mikrocode schickt. S/370 I/O Masking Events (Fig. 44L) ist ein Beispiel für eine solche Interrupt-Meldung. EXEC370 ruft den ETIO Mikrocode auf, der über Schnittstelle mit der BCU-Logik verbunden ist. ETIO läßt eine DMA-Operation anlaufen, die die Meldung vom BCU-Speicher 210 auf den S/370 Speicher überträgt. Wenn die DMA abgeschlossen ist, wird eine BCU-an-PU-Meldung an den S/370 Mikrocode geschickt und ein Interrupt wird ins System 88 geschickt, das bewirkt, daß die ETIO-Schnittstellen- Routine eine Nachricht an das EXEC370 schickt.

OPERATION DER BUSSTEUEREINHEIT (BCU) 156

1. EINLEITUNG

Bestimmte vorstehend beschriebene Systemkomponenten und ihre Funktionen werden hier kurz zusammengefaßt. Die BCU 156 führt die E/A-Schnittstellen-Funktion zwischen dem S/370 Chipsatz 150 und dem E/A-Teilsystem aus, das aus dem S/88 PE62 und einem zugeordneten System und dem E/A-Komponenten in Modul 10 besteht. Der S/370 Chipsatz 150 und das E/A-Teilsystem kommunizieren über den Busadapter 154. Der S/370 Speicherbereich 162 innerhalb des S/88 Hauptspeichers 16 wird hier manchmal als Basisspeichermodul (Basic Storage Module - BSM) 162 angezogen. Es gibt zwei Sätze Adapter-Bus-Schnittstellenleitungen 249, 250 (Kanal 0) und 251, 252 (Kanal 1), die die BCU 156 und den Busadapter 154 zusammenkoppeln.
Die BCU 156 beinhaltet einen 64 kB örtlichen Speicher 210, einen Speicherdirektzugriffs-Controller (DMAC) 209, einen 32- Bit örtlichen Adressenbus 247, einen 32-Bit örtlichen Datenbus 223 und die Schnittstellenlogik 205.
Wie oben in näheren Einzelheiten beschrieben, beinhaltet der DMAC 209 vier Datenübertragungskanäle:
Kanal 0 - Mailboxbefehle werden vom PE85 auf die BCU 156 übertragen. Meldungen werden aus dem S/370 Speicherbereich 162 in den örtlichen Speicher 210 gelesen.
Kanal 1 - S/370 PE85 schreibt Daten. Die Daten werden aus dem S/370 Speicherbereich 162 in den örtlichen Speicher 210 gelesen.
Kanal 2 - S/370 PE85 liest Daten. Die Daten werden in den örtlichen Speicher 210 zum S/370 Speicherbereich 162 übertragen.
Kanal 3 - Hochprioritäts-Meldungsübertragungen von der BCU 156 zum S/370 PE 85. Meldungen werden vom örtlichen Speicher 210 zum S/370 Speicherbereich 162 übertragen.
Der DMAC 209 überträgt Doppelwörter (32 Bits) zwischen dem Busadapter 154 und dem örtlichen Speicher 210. Er unterbricht auch das E/A-Teilsystem (S/88 PE62) wenn die E/A-Daten komplett sind. Der örtliche Speicher 210 enthält E/A- und Meldungsdatenpuffer-WQBs und Verbindungsgliedlistendaten für Auto-Mailboxladen über den DMAC 209.
Die BCU-Logik 205 beinhaltet eine Prioritätszuteilungseinheit 216 für den örtlichen Bus, in der sich das S/88 PE62 und der DMAC 209 um den Zugriff auf den örtlichen Bus bemühen, d.i. Datenbus 223 und Adressenbus 247. Die PE62 "Bus Request"- Leitung 190 ist aktiv, wenn immer die folgenden Adressen (siehe Fig. 41C) vom Adressendecodierer und der Prioritätszuteilungseinheit 216 gefunden werden:
Eine beliebige Speicheradresse; ein beliebiger, an die BCU gerichteter Befehl einschließlich programmierter BCU-Reset, BSM write select up, BSM read select up, und Read BCU Status; Local Bus Interrupt Quittierungszyklus, und jeder an den DMAC gerichteter Lese- oder Schreibregister-Befehl.
Die DMAC-Leitung 'Bus Request' 269 ist aktiv, wenn sie die Steuerung des örtlichen Busses 223, 247 für eine DMAC-Sequenz (Lesen oder Schreiben im örtlichen Speicher 210) oder eine Verbindungsgliedlisten-Lade-Sequenz (gelesen aus dem örtlichen Speicher) übernehmen will. Die Buszuteilungsleitung 268 wird hoch gesetzt, wenn die Steuerung des örtlichen Busses von der Logik 216 an den DMAC 209 gegeben wird; Leitung 191 geht hoch, wenn die Steuerung an das PE62 gegeben wird.
Die BCU-Logik 205 steuert den DMAC 209 Übertragungs-Takt zwischen dem Busadapter 154 und dem E/A-Teilsystem und konvertiert bis zu 4kB E/A-Übertragungen in 64-Byte Block-Übertragungen für den Busadapter 154 auf den Kanälen 0 und 1.
Die BCU-Logik 205 entdeckt eine 64-Byte Grenzüberschreitung für jede beliebige Blockübertragung. Wenn das eintritt, wird der Block in zwei getrennte Übertragungen aufgeteilt. Die BCU 156 berechnet die Anzahl Wörter bis zur 64-Byte-Grenze für die erste Übertragung. Das wird zusammen mit der Anfangsadresse an den Busadapter 154 gegeben. Die restlichen Wörter werden zusammen mit einer neuen Adresse durch einen nachfolgenden Befehl (BSM read/BSM write) an den Busadapter 154 gegeben. Die BCU-Logik 205 sieht ferner eine Vorbelegung für E/A-Datenübertragungen (auf eine 64-Byte Grenze) vor, sobald eine Hochprioritätsmeldungs- oder Mailbox-Lese-Anforderung auftritt. Eine Hochprioritätsmeldungs-Anforderung und eine Mailboxanforderung können in der BCU 156 gleichzeitig behandelt werden. Eine 'BSM Read' und eine "BSM Write" Operation können in der BCU 156 gleichzeitig behandelt werden.
Die BCU 156 führt die folgenden vier E/A-Operationen durch:
Mailbox Read Operation: Eingeleitet vom S/370 I/O INSTRUCTION MICROCODE über die 'PU to BCU REQ' Leitung 256a. Die Mailbox 188 liegt im S/370 BSM 162. Sie wird benutzt zum Speichern von E/A-Befehlen, die vom E/A-Teilsystem ausgeführt werden (Start E/A usw.). Sie kann auch Status- und sonstige Infor mationen enthalten, die das E/A-Teilsystem vom PE85 erhält. Ein Befehl 'Mailbox Select Up' wird von der BCU 156 eingeleitet, wenn die 'PU to BCU Select line 210' über den Adapterbuskanal 0 aktiviert wird. S/370 E/A Schreiboperationen (Adapterbuskanal 0) werden auf einer 64-Byte-Grenze vorbelegt, wenn 'PU to BCU Request' vom S/370 PE85 aktiviert wird.
S/370 E/A-Lese- und Schreiboperationen: Sie besorgen die Datenübertragungen (max. 4kB-Blöcke) zwischen dem S/370 Speicher 162 und den E/A-Vorrichtungen über die Adapterbuskanäle 0 und 1. Alle Datenübertragungen werden vom E/A-Teilsystem (S/88 PE62) eingeleitet über einen Adapterbus-Befehl 'BSM SELECT UP'.
Hochprioritäts-Meldungs-Übertragungen: Interrupts, Status-, Fehler- usw. -meldungen mit Hochprioritätsnatur, die vom E/A- Teilsystem an das S/370 gegeben werden. Alle Übertragungen werden von der BCU 156 über einen Befehl 'Q SELECT UP' eingeleitet. S/370 E/A-Leseoperationen (Adapterbuskanal 1) werden auf eine 64-Bytegrenze vorbelegt, sobald eine Hochprioritätsmeldungs-Anforderung auftritt.

2. S/370 START-E/A-SEQUENZFLUSS, ALLGEMEINE UND DETAILLIERTE BESCHREIBUNG.

Die 'Start I/O instruction' SIO, das 'Channel Address Word' CAW und das erste 'Channel Control Word' CCW werden an vorgegebenen 'Mailbox'-Stellen im S/370 Speicher 162 gespeichert. Diese Informationen werden an den örtlichen Speicher 210 über die BCU Schnittstellenlogik 205 und den Busadapter 154 weitergegeben.
Die in Fig. 18 gezeigten DMAC Kanal 0 Register werden für Mailbox-Leseoperationen benutzt. Sie werden vom S/88 PE62 programmiert, um in einem 'Linked Array Chaining Mode' zu arbeiten. Das PE62 initialisiert diesen Modus durch Aufstellen einer Reihe von 'linked lists' (Tabellen) im örtlichen Speicher 210, Fig. 41H. Dann setzt er die erste 'top linked list address' in das DMAC-Kanal-0-Basisadressenregister (32 Bits) BAR. Diese Adresse zeigt auf die erste Stelle im Speicher 210 der Verbindungsgliedliste-Daten.
Die DMAC 'PCL' (Peripherie-Steuerleitung) 257a wird vom PE62 so programmiert, daß der DMAC 209 seine IRQ Interrupt- Ausgabeleitung 258 aktiviert, wenn die PCL-Leitung 257a aktiviert wird. Die 'PCL'-Leitung 257a wird aktiviert nach Abschluß einer Mailbox-Datenübertragung vom Hauptspeicher 162 zum örtlichen Speicher 210 über den Adapterpuffer 259. Der Interrupt informiert den S/88 Prozessor PE62, daß eine Mailbox-Ladeoperation eben abgeschlossen wurde.
Die Daten der Verbindungsgliedliste (Fig. 41H) sind wie folgt: Anfangsspeicheradresse eines Datenblocks; Speicherübertragungszählung; und Verbindungsgliedadresse zum nächsten Tabelleneintrag. Die letzte Verbindungsgliedadresse in der Tabelle ist Null.
Der S/388 Prozessor 162 setzt die oberste Adresse der Verbindungsgliedliste in das Basisadressenregister auf dem DMAC Kanal 0.
Der S/88 Prozessor PE62 aktiviert den DMAC 209 durch Schreiben einer "1" in Bit 7 ('START' Bit) des Kanalsteuerregisters CCR seines Kanals 0. Der DMAC 209 liest dann die erste Verbindungsgliedliste in seine Kanal 0 Register wie folgt:
Anfangsadresse des Datenblock-WQB des Speichers 210 in das Speicheradressenregister MAR (32 Bits);
Übertragungszählung (Bytes der Mailbox-Daten) in das Speicherübertragungszählungsregister MTC; und Verbindungsglied-Adresse in das nächste Datenblock- Adressenregister BAR.
In näheren Einzelheiten, während der Anweisungsausführung decodiert das S/370 PE85 eine 'START I/O' Anweisung, legt den 'START I/O' Befehl, das Kanaladressenwort und das erste Kanalsteuerwort in aufeinanderfolgende 'Mailbox'-Stellen, die im S/370 Speicher 162 enthalten sind. Die Anfangsadresse der Mailbox (Basis + Warteschlangenlänge) wird bei der Initialisierung im Basisregister des Busadapters 154 gespeichert.
Das S/370 PE85 gibt eine 'LD OSCW'-Steuer-OP auf den Prozessorbus mit aktivem Bit 11. Das setzt das 'PU to BCU REQUEST'- Bit im Steuerwort des Busadapters 154 auf an. OSCW-Bit 11 bewirkt einen 'PU to BCU Request' auf dem Adapterbus (Kanal 0). Wenn während einer E/A-Daten-Übertragung ein 'PU to BCU REQ' auftritt, wird die BCU 156 die E/A-Übertragung auf eine 64- Byte Grenze vorbelegen, damit ein Mailbox-Laden stattfinden kann.
Dann generiert die BCU 156 auf dem Bus 290 einen Befehl 'Read Mailbox Select Up' im Format, das in Fig. 45A gezeigt wird, wo die Bits 0, 1 die Befehlsbits, und die Bits 2-7 die Byte- Zählung sind, und speichert es im Befehlsregister 214 des Kanal 0 ab. Die Mailboxadressenbits werden über den Bus 290 im Register 219 gespeichert in einem Format, das in Fig. 45B gezeigt wird, wo Bit 7 den IOA-Bereich im Speicher 162; Bits 24-26 die BCU-Kanalnummer, und Bits 27-31 den Mailbox-Offset identifiziert.
Nachdem die BCU 156 den COMMAND/STATUS Bus 249 und den ADDR/DATA Bus 250 durch Füllen der Register 214 und 219 aktiviert hat, setzt sie einen 'TAG UP' Befehl auf die Leitung 262a und wartet auf Daten vom Busadapter. Das tut sie durch Abtasten der 'TAG DOWN' Leitung 262b. 'TAG DOWN' ist aktiv solange die Daten nicht bereit sind. Sobald 'TAG DOWN' vom Busadapter 154 deaktiviert wird (Daten bereit) werden die ersten vier Bytes der Mailbox-Daten durch zwei Kanal 0 Unterzyklen in den Kanal 0 Lesepuffer 226 zwischengespeichert.
Die BCU-Logik 253 setzt dann die 'REQUEST' Leitung 263a auf Kanal 0 des DMAC 209 hoch. Dann setzt der DMAC 209 den 'BUS REQEST' (BR) auf Leitung 269 zur LOCAL BUS Verteilerschaltung 216. Wenn der örtliche Bus vom S/88 Prozessor 62 gerade nicht benutzt wird, wird der Buszugriff über die Buszuteilungsleitung (BG) 268 an den DMAC 209 gewährt. Der DMAC 209 überträgt dann die Anfangsadresse des WQB der örtlichen Mailbox (im Speicher 210) vom MAR auf den Adressenbus 247 und setzt die 'ACK0' (DMAC Kanal 0 Acknowledge) Leitung 264 hoch. Das 'ACK0' Signal läßt die Datenübertragung vom Puffer 226 über den Datenbus 223 an den örtlichen Mailboxteil des WQB im Speicher 210 anlaufen. Die 'DTACK' Leitung 265 wird aktiviert, um den DMAC 209 zu informieren, daß die Operation abgeschlossen ist.
Die BCU-Taktsignale (Fig. 25) übertragen weiterhin Mailboxdaten vom Puffer 259 zum Register 226. Die BCU 156 führt zwei Adapterbus-Sequenzen ('TAG UP'/'TAG DOWN') mit jeweils 16 Bits für jede örtliche Speicher 210/DMAC 209 Sequenz (32 Bits) durch.
Wenn der DMAC Zyklus abgeschlossen ist (DTACK aktiv), setzt der DMAC 209 die 'Data Transfer Complete' (DTC) Leitung 267 zur CBU-Logik 253 hoch, die dann über Leitung 263a einen weiteren 'REQUEST' an den DMAC 109 ausgibt, um die zweiten vier Bytes vom Register 226 in die WQB Mailbox zu lesen. Die DMAC- Zyklen wiederholen sich, bis die gesamten Mailboxdaten (16 Bytes) übertragen sind (4 örtliche Busy-Zyklen). Die 'PCL' Leitung 257a wird dann von der BCU-Logik 253 an den DMAC 209 aktiviert. Das bewirkt, daß die 'IRQ' Leitung 258 vom DMAC 209 zur Prioritätscodierung-/Interrupt-Logik 212 des S/88 Prozessors aktiviert wird. Das PE62 bearbeitet dann die Mailbox-Anforderung.
Wenn der DMAC 209 seine Kanal 0 Register Ladevorgänge von der Verbindungsgliedliste abgeschlossen hat, wartet er auf ein Signal auf der 'REQ' Leitung 263a auf Kanal 0 von der BCU- Logik 253, um das nächste Mailbox-Laden zu beginnen. Nach dem Anlaufen bleibt der DMAC Kanal 0 ständig aktiv, wobei der S/88 Prozessor 62 die Ringverbindungsgliedliste steuert, und die BCU 156 Datenübertragungen aufschiebt durch Inaktivhalten der 'REQ' Leitung 263a. Wenn Kanal 0 infolge einer 'End-of- list' Bedingung stoppt, erhält der S/88 Prozessor einen Beendigungs-Interrupt und startet ggf. Kanal 0 erneut.

3. S/370 E/A-DATENÜBERTRAGUNGSSEQUENZFLUSS, ALLGEMEINE BESCHREIBUNG.

Alle E/A-Lese- und Schreibübertragungen gehen vom S/88 Prozessor 62 über Adapterbus-architekturierte Befehle 'BSM READ SELECT UP' und 'BSM WRITE SELECT UP' aus. Der S/370 CCW Befehl und die Anfangsadresse (im S/370 Speicher 162) leitet sich vom CCW für ein 'START I/O' ab. Die Daten werden durch den S/88 Prozessor 62 zwischen der jeweiligen E/A-Vorrichtung und einem örtlichen Puffer im örtlichen Speicher 210 verschoben.
Der örtliche Speicher 210 beinhaltet eine Speicherblock- Warteschlange für E/A-Schreiboperationen, die vom S/88 Prozessor 62 verwaltet wird. Wenn die Warteschlange wenigstens einen Eintrag enthält, ist sie bereit zum Anlaufenlassen einer E/A-Schreiboperation. Die Anfangsadresse für einen angewählten dieser Blöcke wird vom S/88 Prozessor 62 vor dem Anlaufen einer Schreiboperation im DMA Kanal 1 Register im DMAC 209 gespeichert. Die DMA Kanal 1 Register sind reserviert für S/370 E/A-Schreiboperationen (S/370 Speicher 162 zum E/A) über den örtlichen Speicher 210. Der Adapterdatenpuffer 259 (64 Bytes) ist reserviert für Mailbox-Lese- und S/370 E/A- Schreiboperationen (Datenübertragungen vom S/370 Speicher 162 auf den örtlichen Speicher 210). Dieser Puffer ist dem Kanal 0 Adapterbus 249, 250 zugeordnet. Der Puffer 260 (64 Bytes) ist reserviert für Meldungen-Schreiben (an S/370) und S/370 E/A-Leseoperationen (Datenübertragungen vom örtlichen Speicher 210 in den S/370 Speicher 162). Dieser Puffer ist dem Kanal 1 Adapterbus 251, 252 zugeordnet. Der S/88 Prozessor 62 initialisiert die höherwertigen Wörter des DMAC Kanal 1 und 2 Speicheradressenregisters auf Null (0). Das erspart einen Extrabuszyklus, wenn diese Register während Operationssequenzen geladen werden, weil der örtliche Speicher 210 nicht mehr als 16 Bits Adressen braucht.

(a) E/A Schreiboperationen: (vom S370 Speicher 162 zum örtlichen Speicher 210)

Der S88 Prozessor 62 setzt die Anfangsadresse des örtlichen Puffers im Speicheradressenregister MAR des DMAC Kanal 1, durch Legen von Informationen auf den DMAC Adressen- und Datenbus 248 (VIA BUS 161a, DRIVER 217, BUS 247 und LATCH 233) wie in Fig. 45C gezeigt wird, worin Bits 31-08 = 007E00 = DMAC Register Select' Befehl und Bits 07-00 = DMAC Kanal 1 Speicheradressenregister (tief) Select Befehl sind. Hier ist anzumerken, daß S/88 die höchstwertigen und niedrigstwertigen Bits auf dem Bus als "31" bzw. "0" identifiziert, umgekehrt wie im S/370 Protokoll.
Der in Fig. 45D gezeigte Inhalt (bestimmt für MAR) wird auf den Datenbus 223 gelegt, wobei Bits 31-16 = Anfangsadresse des örtlichen Puffers im Speicher 210 für die E/A-Schreibdaten sind. Die höherwertigen Datenbus-Bits (31-16) werden in den niederwertigen (15-00) Teil des Kanal 1 Speicheradressen registers geladen. Die höherwertigen Bits (31-16) des MAR wurden bei der Initialisierung auf 0 gesetzt. Der DMAC 209 antwortet mit einem 16-Bit-Port 'DSACK'-Signalleitungen 266a, b über die BCU-Logik 253 an die S/88 Prozessor-CPU. Der S/88 Prozessor 62 legt die BCU-Daten (Byte-Zählung, Speicherschlüssel, Adapterbus-Priorität und kundenspezifische/IOA- Raumdaten) und die DMAC Kanal 1 Speicherübertragungs- Zählungsdaten auf den örtlichen Adressenbus 247. Fig. 45E zeigt den Befehl auf dem Adressenbus, wobei die Bits
31-08 = 007E00 = 'DMAC Register Select' Befehl; und
07-00 = BCU Select und DMAC Channel 1 Select.
Byte-Zählung, Speicherschlüssel (abgeleitet aus dem CCW), Adapterbus-Priorität und Kunden/IOA-Raum-Bits werden vom S/88 Prozessor 62 auf den Datenbus 223 gelegt in einem Format, das in Fig. 45F gezeigt wird, wobei die Bedeutung der Bits ist wie folgt:
31-27 = Reserviert
26 = Höherwertiges Byte-Zählungsbit. Dieses Bit = 1 nur dann, wenn die maximale Bytezählung (4 kBytes) übertragen wird.
26-16 = Bytezählung, geladen in das MTC Register des DMAC- Kanals 1.
26-14 = In das BCU-Register 220 geladene Byte-Zählung (max. 4096), und wenigstens ein Teil der Zählung wird in das Register 221 geladen, wie nachstehend in den Byte-Zählungsoperationen beschrieben wird. Der Busadapter 154 verlangt eine Zählung von 1111 1111 1111, um die 4096 Bytes zu übertragen (Byte-Zählung -1). Daher dekrementiert die BCU 156 die Doppelwort- Grenzbits 26-16 einmal, bevor sie zusammen mit den Byte-Offset-Bits 15-14 (in 64-Byte-Blöcken) an den Busadapter 154 gegeben werden.
15-24 = Niederwertige Byte-Zählungsbits BCU 156. Diese Bits stellen den Byte-Offset minus 1 (wegen der Busadapterbedingungen) von einer Doppelwortgrenze dar. Diese Bits werden vom DMAC 209 oder der BCU 156 nicht benutzt, weil sie nur Doppelwörter übertragen. Sie werden an den Busadapter 154 gegeben um an den S/370 BSM geschickt zu werden.
13-12 = Adapterbus-Kanal-Priorität
11-08 = Speicherschlüssel
07 = Kunden/IOA Raum-Bit
06 = Der S/88 Prozessor aktiviert dieses Bit (1), um anzuzeigen, daß ein zusätzlicher Speicherzugriff erforderlich ist. Das geschieht, wenn eine S/370 Speicher-Anfangsadresse keine Doppelwort (32 Bits) Grenze ist. Da alle BCU Zugriffe mit einer Doppelwortgrenze angehen müssen, enthält der erste Zugriff das/die Byte(s) an der angegebenen Anfangsadresse sowie das/die vorangehende(n) Byte(s), die an dieser Doppelwortadresse stehen. Das/die vorangehende(n) Byte(s) wird/werden nicht berücksichtigt.
05-00 = Reserviert.
Der DMC 209 lädt das höherwertige Wort (d. i. Byte-Zählung) des Datenbusses in das MTC-Register des Kanals 1. Die BCU übernimmt den Datenbusinhalt wie folgt:
Bits 26-14 - zum BSM Read Select Up Byte Counter 220; und Bits 13-06 - zum 0 A/D-Register 219 des Adapterbuskanals, aber umgeschichtet.
Damit eine Doppelwortübertragung in einem S/88 Prozessor- Maschinenzyklus stattfinden kann, muß die Adresse auf eine Doppelwortgrenze gestellt werden. Da die Adresse des DMAC- Kanal 1-MTC keine Doppelwortgrenze ist, (Bits 07-00 = 01001010), tritt die folgenden Aktion ein, um die BCU 156 und den DMAC 209 mit einem einzigen S/88 Prozessor-Befehl zu laden. Die BCU 156 invertiert das Adressenbit 1 und gibt es an den DMAC 209 zusammen mit den anderen Registeranwahlbits. Das ermöglicht es, daß das MTC-Register für Kanal 1 richtig gewählt wird (Adressenbits 07-00 = 01001010). Diese Anordnung gilt auch für die Wahl des MTC-Registers für E/A-Leseoperationen im Kanal 2. Der DMAC 209 antwortet mit einem 'DTACK'-Signal auf Leitung 265 an die BCU-Logik 253. Die BCU- Logik 253 wandelt das 'DTACK'-Signal zu einer 32-Bit-Port 'DSACK'-Antwort auf den Leitungen 266a, b an den S/88 Prozessor 62. Die Übertragungsbytezählung wird zusammen mit den restlichen Datenbusdaten während des nachfolgenden Befehls 'BSM READ SELECT UP' an den Busadapter 154 gegeben. Der BSM Grenzenlesezähler 221 oder der BSM Leseanwahl-Byte-Zähler 220 werden in das Lesebefehlsregister 214 des Kanals 0 geladen.
Der S/88 Prozessor 62 generiert dann einen Befehl 'BSM READ SELECT UP' auf dem Bus 247 im Format gemäß Fig. 45 G, worin die Bits 31-00 = 007E0108 = 'BSM Read Select Up' Befehl sind.
Der S/88 Prozessor 62 legt auch die BSM-Anfangsadresse auf den Datenbus 223 im Format gemäß Fig. 45H, worin die Bits 23- 0 = die Anfangsadresse im Speicher 162 sind.
Die BSM Anfangsadresse auf dem Bus 223 wird im A/D-Register 219 und im BSM Leseadressenregister 231 gespeichert. Sie wird anschließend an den Busadapter 154 zur Weitergabe an den S/370 Speicher 162 geschickt. Die BCU 156 aktiviert dann die 'DSACK'-Leitungen 266a, d zum S/88 Prozessor 62. Jetzt wird der S/88 Prozessor freigegeben und ist mit dieser Operation nicht weiter befaßt.
Die BCU 156 legt den Befehl 'BSM SELECT UP' (Lesen) über den Bus 290 in das Register 214 und auf den Befehls/Status-Bus 249, wie in Fig. 451 gezeigt wird; dabei haben die Bits die folgende Bedeutung:
0-1 = 11 Befehl 'BSM Select Up' (Lesen); und
2-7 = Feldlänge minus 1 (max. 64 Bytes).
Die Feldlänge war vorher vom Register 220 oder 221 in Register 214 übertragen worden. Das Register 219 legt Adresseninformationen auf den Bus 250 im Format gemäß Fig. 45J; dabei haben die Bits folgende Bedeutung:
0-3 = Speicherschlüssel
4 = 1;
5-6 = Priorität (Busadapter 154 zum Prozessorbus 170); = 1 = Zugriff auf Kundenbereich
0 = Zugriff auf Mikrocodebereich;
8-31 = Adresse des ersten Datenfeld-Bytes im Speicher 162.
Die BCU-Logik 253 setzt dann die TAG UP Leitung 262a zum Busadapter 154 hoch, um Befehl, Feldlängendaten in das Adapterbefehlsregister 124 (Fig. 13), und die Schlüsseladressendaten in Register 122 zwischenzuspeichern. Der Busadapter 154 setzt TAG DOWN an die BCU-Logik 253 hoch, wenn die Daten nicht gültig sind. Die BCU-Logik 253 wartet bis TAG DOWN tief geht. Der Busadapter 154 wandelt den Adapterbusbefehl BSM SELECT UP in einen Prozessorbus-E/A-Speicherbefehl um, wie in Fig. 45K und 45L dargestellt wird, in der die Bits auf dem Adressen/Datenbus 170 bedeuten:
0 = 0 = E/A-Speicherbefehl
1 = 1 = Abrufoperation
2-7 = Feldlänge
8-31 = Wahre Byte-Adresse
und in der die Prozessor-Schlüssel/Status-Bits bedeuten:
0-3 = Speicherschlüssel
4 = 0 = keine dynamische Übersetzung.
Wenn die adressierten Daten vom S/370 Speicher 162 zurückgegeben werden, werden sie in den Busadapter-Datenpuffer 259 (Kanal 0) zwischengespeichert. Der Busadapter 154 deaktiviert dann die TAG DOWN Leitung 262b auf dem Adapterbuskanal 0. Dieser Zustand alarmiert die BCU 156, zwei Bytes (16 Bits) Daten, unmittelbar gefolgt von weiteren zwei Bytes, in den Kanal 0 Lesepuffer 226 (4 Bytes) über Links-Takt- und Rechts- Takt-Signale zwischenzuspeichern. Die BCU 156 aktiviert dann ihre 'REQ1'-Leitung 263b (DMAC Kanal 1 Request) an den DMAC 209. Der DMAC 209 gibt einen 'BUS REQ' auf Leitung 269 an die örtliche BCU Busverteilerlogik 216, um einen örtlichen Buszyklus durchzuführen.
Wenn das Buszuteilungssignal auf Leitung 268 von der BCU- Verteilerlogik 216 zurückgegeben wird, läßt der DMAC 209 eine Operation über Kanal 0 zum Lesen des Puffers 259 in den örtlichen Speicher 210 anlaufen. Das geschieht durch Rückgabe von ACK1 (DMA Kanal 1 Acknowledge) auf Leitung 264b an die BCU-Logik 253, und durch Eingeben der örtlichen Speicheradresse in das Register MAR des DMAC Kanals 1 zu den Speicher-210-Adressierschaltungen (nicht dargestellt) über den Bus 248, Zwischenspeicher 233, Adressenbus 247 und Multiplexer 232. Die BCU-Logik 253 benutzt das ACK1 Signal auf Leitung 264b und das RAM-Select-Signal auf Leitung 210a, um die ersten Daten (4 Bytes) aus dem Puffer 226 auf den Datenbus 223 zum Speichern im Speicher 210 an der vom MAR Register spezifizierten Adresse zu legen. Wenn DTACK von der BCU-Logik 253 auf der Leitung 265 zurückgegeben wird, setzt der DMAC 209 DTC (Datentransfer abgeschlossen) auf Leitung 267 hoch.
Die BCU 156 dekrementiert die Byte-Zählung MTC, die in den Registern 220 gespeichert wurde; inkrementiert das Kanal 1 MAR; und dekrementiert das Adressenregister 231 für jedes Daten-Doppelwort (4 Bytes), das vom Busadapter 154 her aufgenommen wird, bis zu 64 Bytes. Die oben beschriebene Sequenz wird wiederholt für jeweils vier Bytes (bis zu 64) des BCU- Befehls. Wenn die Transfer-Byte-Zählung größer ist als vierundsechzig, dann schickt die BCU 156 über die Register 231, 219 eine neue BSM-Anfangsadresse an den Busadapter 154, um die nächsten 64 Bytes abzurufen. Das Register 231 wurde für jede 4-Byte-Übertragung dekrementiert, wie oben beschrieben, und hat somit die richtige nächste Anfangsadresse bereit. Der Busadapter 154 puffert 64 Datenbytes für jede Anfangsadresse, bis der ganze vom Befehl angeforderte Datentransfer (bis zu 4 kE) abgeschlossen ist.
Die BCU 156 läßt den DMAC 209 im Leerlauf (durch Nicht- Hochsetzen des REQ), wenn der Busadapterpuffer 259 leer ist, und bis das nächste gültige Datenwort eingeht der Zustand 'tag down' reflektiert die Verfügbarkeit gültiger Daten im Puffer 259. Die REQ/ACK-Zyklen werden fortgesetzt bis die Byte-Zählung auf Null geht, zu welchem Zeitpunkt der DMAC 209 IRQ auf Leitung 258 an den S/88 Prozessor 62 hoch setzt. Das alarmiert den S/88 Prozessor 62, den örtlichen Speicherpuffer, der die vom S/370 Speicher 162 ausgelesenen Daten enthält, zur richtigen Verarbeitung zu lesen.

(b) E/A-Leseoperationen: (Örtlicher Speicher 210 an S/370 Speicher 162)

E/A-Leseoperationen (gesteuert vom EXEC370) laufen dann an, wenn mindestens ein Eintrag in der E/A-Lesewarteschlange im Speicher 210 steht. Der S/88 Prozessor 62 übernimmt die Steuerung des örtlichen Busses, wenn er nicht vom DMAC 209 benutzt wird. Der S/88 Prozessor 62 setzt die E/A- Leseanlaufadresse im örtlichen Puffer in das Speicheradressenregister (MAR) im DMAC-Kanal 2 durch Legen der Information gemäß Fig. 45M auf den Bus 247, wobei die Bits folgende Bedeutung haben:
31-08 = 007E00 = Befehl DMAC Register Select
07-00 = DMAC Kanal 2 Memory Address Reg (Low) Select;
und durch Setzen der Anfangsadresse (des Puffers im Speicher 210) auf den Datenbus 223, wie in Fig. 45N gezeigt wird, wobei die Bits folgende Bedeutung haben:
31-16 Anfangsadresse der E/A-Lesedaten des örtlichen Puffers
15-00 Reserviert.
Die höherwertigen Datenbus-Bits 31-16 werden in die niedrigerwertigen Bits (15-00) des Kanal 2-Speicheradressenregisters geladen. Die höherwertigen Bits 31-16 des MAR wurden bei der Initialisierung auf Null gesetzt. Der DMAC 209 antwortet mit einem DTACK Signal auf Leitung 265, das in DSACK Signale auf Leitungen 266a, b zum S/88 Prozessor 62 umgewandelt wird. Der S/88 Prozessor 62 schiebt dann die Daten (bis zu 4 kB) von einem E/A-Controller, wie z. B. 20 oder 24, über eine S/88 Programmsteuerung in den örtlichen Speicher 210, unter Verwendung der Anfangsadresse des angewählten E/A- Lesepuffers des örtlichen Speichers.
Sobald die Datenübertragung abgeschlossen ist, legt der S/88 Prozessor 62 den Speichertransfer-Count-Select des DMAC Kanal 2 auf den Adressenbus 247 im Format, das in Fig. 450 gezeigt wird, wobei die Bits die folgende Bedeutung haben:
31-08 = 007E00 = Befehl DMAC Register Select
07-00 = BCU und DMAC Kanal 2 MTC Select.
Byte-Zählung, Speicherschlüssel (abgeleitet aus dem CCW), Adapterbus-Priorität und Kunden/IOA-Raum-Bits werden vom S/88 Prozessor 62 auf den Datenbus 223 gelegt in einem Format, das in Fig. 45P gezeigt wird, wobei die Bedeutung der Bits ist wie folgt:
31-27 = Reserviert
26 = Höherwertiges Byte-Zählungsbit. Dieses Bit = 1 nur dann, wenn die maximale Bytezählung übertragen wird.
26-16 = Bytezählung des MTC Registers des DMAC-Kanals 2.
26-14 = In die BCU 156 geladenen Byte-Zählung (max. 4096). Der Busadapter verlangt eine Zählung von 1111 1111 1111, um die 4096 Bytes zu übertragen (Byte-Zählung -1). Daher dekrementiert die BCU die Doppelwort- Grenzbits 26-16 einmal, bevor sie zusammen mit den Byte-Offset-Bits 15-14 (in 64-Byte-Blöcken) an den Busadapter 154 gegeben werden.
15-14 = Niederwertige Byte-Zählungsbits. Diese Bits stellen den Byte-Offset minus 1 (wegen der Voraussetzungen des Busadapters) von einer Doppelwortgrenze (32 Bits) dar. Diese Bits werden vom DMAC 209 oder von der BCU 156 nicht benutzt, weil sie nur Doppelwörter übertragen. Die Bits werden an den Busadapter 154 geschickt um an den S/370 BSM 162 gegeben zu werden.
13-12 = Adapterbus-Kanal Priorität
11-08 = Speicherschlüssel
07 = Kunden/IOA Raum-Bit
06-00 = Reserviert.
Der DMAC 209 lädt den (Byte Count) des Datenbusses 223 in das MTC Register des Kanals 2. Die BCU 156 erfaßt den auf dem Datenbus liegenden Inhalt, wenn der obige Befehl auf dem Adressenbus 247 erscheint. Bits 26-16 werden in den BSM 'write select up'-Bytezähler 222 gespeichert. Bits 13-07 werden in das höherwertige Byte des A/D Registers 227 Adapterbuskanals 1 gespeichert. Der DMAC antwortet mit einem DTACK-Signal auf Leitung 265 an die BCU-Logik 253. Die Logik 253 wandelt das DTACK-Signal in eine 32 Bit Port SDACK Anwort auf den Leitungen 266a, b zum S/88 Prozessor 62 um. Die Übertragungsbyte- Zählung wird zusammen mit den restlichen Datenbusdaten während des nachfolgenden BSM 'Write select up'-Befehls zum Busadapter 154 geschickt. Die Zählung im BSM Schreibgrenzenzähler 224 (ohne den letzten Transfer) bzw. im BSM Schreibbytezähler 222 (letzter Transfer) wird in das Schreibbefehlsregister 225 des Adapterkanals 1 geladen.
Der S/88 Prozessor 62 generiert dann einen BSM 'write select up'-Befehl auf dem örtlichen Adressenbus 247 in Format gemäß Fig. 45Q, in dem die Bits die folgende Bedeutung haben:
31-00 = 007E0104 = BSM 'write select up' Befehl
Der S/88 Prozessor legt auch die BSM-Anfangsadresse auf den Datenbus 223 im Format gemäß Fig. 45R, in dem die Bits die folgende Bedeutung haben:
31-24 = Reserviert
23-00 = BSM Anfangsadresse.
Die BSM Anfangsadresse auf dem Datenbus 223 wird von den niederwertigen Bytes des A/D-Registers des Kanals 1 und dem BSM Schreibadressenregister 228 erfaßt. Sie wird anschließend an den Busadapter 154 zur Weitergabe an den S/370 Speicher 162 geschickt (wie man nachstehend sieht). Die BCU 156 aktiviert dann die 'DSACK'-Leitungen 266a, b (32-Bit-Port) an den S/88 Prozessor 62. Jetzt wird der S/88 Prozessor 62 freigegeben und ist mit dieser Operation nicht weiter befaßt.
Die BCU-Logik gibt einen BSM 'select up'-Befehl aus durch Einspeichern von "01" Bits in die höherwertigen Bits des Befehlsregisters 225 über den Bus 290, und legt den Befehl und die Feldlänge des Registers 225 auf den Bus 252 im Format gemäß Fig. 45S, wobei die Bits die folgende Bedeutung haben:
0-1 = BSM 'select up'-Befehl (Schreiben),
2-7 = Feldlänge minus 1 (max. 64 Bytes).
Der Inhalt des Registers 227 wird auf den Adressen/Datenbus 251 (in zwei Teilzyklen) gelegt im Format gemäß Fig. 45T, worin die Bits folgende Bedeutung haben:
0-3 = Speicherschlüssel
4 = 1
5-6 = Priorität (Busadapter zum Prozessorbus);
7 = 1 = Zugriff auf Kundenbereich
0 = Zugriff auf Mikrocodebereich;
8-31 = S/370 Adresse des ersten Byte im Datenfeld.
Der Befehl und die Feldlänge werden in Register 125 des Adapters 154 gespeichert. Die Schlüssel/Adressendaten werden über das SYNC-Register 113 im Register 123 des Adapters 154 gespeichert. Die BCU-Logik 253 aktiviert das Signal REQ2 auf der Leitung 263c zum DMAC-Kanal 2. Der DMAC 209 schickt die E/A-Pufferanfangsadresse vom MAR über den Bus 248, den Zwischenspeicher 233, den Bus 247, den Multiplexer 232 zum Speicher 210, um ein Datendoppelwort vom Speicher 210 zum A/D- Register 227 zu übertragen. ACK2 (DMA-Kanal 2 Acknowledge) auf Leitung 264c wird hoch gesetzt. Das bewirkt ein 'Tag Up' auf Leitung 262a zum Adapter 154.
Dann überträgt der Adapter 154 ein Datendoppelwort vom Register 227 zum Busadapterpuffer 260 in zwei Teilzyklen über das Register 113. Eine Schreibsequenz von REQ/ACK-Signalen, gefolgt von einem 'Tag Up'-Befehl wird wiederholt, um jedes Datendoppelwort zu übertragen. Die BCU 156 dekrementiert die Bytezählung in den Registern 222, 224 und die Adresse im Register 228 und die MTC des DMAC-Kanals 2 für jedes Doppelwort (32 Bits), das vom Busadapter 154 geschickt wird, bis zu 64 Bytes.
Wenn die Übertragungsbyte-Zählung größer ist als 64, wird (wie vorstehend bei der Schreiboperation bereits beschrieben) die BCU 156 eine neue Anfangsadresse für die nächsten 64 Bytes vorlegen. Der Busadapter puffert 64 Datenbytes für jede Anfangsadresse. Diese Sequenz wiederholt sich, bis die Bytezählung in Register 222 (max. 4kB) nach Null geht.
Sobald der Busadapterpuffer 260 voll ist, unterbricht die BCU 156 die Schreibsequenz, bis der Busadapter ein Zeichen 'Puffer frei' über die 'Tag down'-Leitung 262c gibt.
Der Busadapter 154 wandelt den Adapterbus-Befehl 'BSM Select Up' in einen S/370 Prozessorbus-E/A-Speicher-Befehl auf dem Prozessorbus 170 und dem Schlüssel/Status-Bus um in ein Format, das in Fig. 45U und V gezeigt wird, wobei die Bits folgende Bedeutung haben:
0 = 0 = E/A-Speicherbefehl
1 = 0 = Speicheroperation
2-7 = Feldlänge
8-31 = Wahre Byte-Adresse
Schlüssel/Status-Bus-Bits
0-3 = Speicherschlüssel
4 = 0 = keine dynamische Übersetzung.
Wenn alle Daten übertragen sind (Byte-Zählung = 0) aktiviert der DMAC 209 die Interrupt-Leitung 258a zum S/88 Prozessor- Prioritäts-Codierer 212.

(c) S/370 HOCHPRIORITÄTSMELDUNGS-ÜBERTRAGUNGSSEQUENZFLUSS

Alle Hochprioritätsmeldungs-Übertragungen nehmen im E/A- Teilsystem (S/88 Prozessor 62) ihren Ausgang. Der DMAC-Kanal 3 wird vom S/88 Prozessor 62 eingestellt zur Durchführung der Datenübertragung (16 Bytes). Die BCU 156 benutzt den Adapterbuskanal 1 zur Datenkommunikation (Befehl 'Q Select Up').
Die BCU 156 findet eine Hochprioritäts-Meldungsanforderung, wenn der S/88 Prozessor PE62 das Laden einer Speicherübertragungszählung in das Register MTC auf dem Kanal 3 vornimmt. Als Ergebnis daraus generiert die BCU 156 einen Befehl 'Q Select Up' an das S/370 PE85 auf dem Adapterbus 252 des Kanals 1. Wenn gerade eine S/370 E/A-Lesedatenübertragung (Adapterbus Kanal 1) abläuft wenn die Anforderung gefunden wird, dann wartet die BCU 156 bis die augenblickliche 64- Byte-Block-Übertragung abgeschlossen ist, bevor sie die Anforderung erfüllt.
Wenn auf dem Adapterbuskanal 1 keine E/A-Aktivität stattfindet, wird die Anforderung unverzüglich erfüllt.
Jetzt soll diese Hochprioritäts-Meldungsübertragung in näheren Einzelheiten beschrieben werden. PE62 übernimmt die Steuerung des örtlichen Busses 223, 247, wenn dieser nicht gerade vom DMAC 209 benutzt wird. PE62 speichert dann die Meldungsdaten über die Programmsteuerung in den örtlichen Speicher 210. PE62 setzt die örtliche Puffermeldungs- Anfangsadresse in das Speicheradressenregister MAR des DMAC Kanals 3 durch Legen der Information auf den örtlichen Adressenbus 247 im Format gemäß Fig. 45W, worin die Bits die folgende Bedeutung haben:
31-08 = 007E00 = Befehl 'DMAC Register Select'.
07-00 = DMAC Kanal 3 'Memory Address Reg (Low) Select'.
Die Anfangsadresse der für das Speicheradressenregister bestimmten örtlichen Puffermeldungsdaten wird auf den Datenbus 223 im Format der Fig. 45X gelegt, wobei die Bits die folgende Bedeutung haben:
31-16 = Anfangsadresse der örtlichen Puffermeldungsdaten im Speicher 210,
15-00 = Reserviert.
Der höherwertige Datenbus (Bits 31-16) wird in den niederwertigen (Bits 15-0) Teil des Speicheradressenregisters MAR auf dem DMAC Kanal 3 geladen. Die höherwertigen Bits (31-16) des MAR wurden beim Initialisieren auf Null gesetzt. Der DMAC 209 antwortet mit einem Signal DTACK auf der Leitung 265, das über die BCU-Logik 253 in ein 16 Bit Port Signal DSACK auf den Leitungen 266a, b zum S/88 Prozessor 62 umgewandelt wird.
Der S/88 Prozessor 62 legt dann einen Befehl auf den örtlichen Adressenbus 247 im Format gemäß Fig. 45Y, worin die Bits die folgende Bedeutung haben:
31-08 = 007E00 = Befehl 'DMAC Register Select'
07-00 = BCU und DMAC Kanal 3 MTC Select.
Die Byte-Zählung, Speicherschlüssel und Kunden/IOA Raum-Bits werden vom S/88 Prozessor 62 auf den Datenbus gelegt im Format gemäß Fig. 45Z, worin die Bits folgende Bedeutung haben:
31-20 = Reserviert
19-16 = Übertragungs-Byte-Zählbits. Diese Bits werden in den DMAC 209 und in die BCU 156 geladen. Sie stellen eine Doppelwortzählung an den DMAC 209 und die BCU 156 dar (max. 64 Bytes).
15-12 = Null
11-08 = Speicherschlüssel
07 = Kunden/IOA Raumbit
06-00 = Reserviert.
Der DMAC 209 lädt das höherwertige Wort (Byte-Zählung) des Datenbusses 223 in das Speicherübertragungs-Zählregister MTC auf Kanal 3. Die BCU 156 erfaßt den Datenbusinhalt, wenn dieser bestimmte Befehl auf dem Adressenbus 247 erscheint, durch Speichern der Bits 19-16 in den 'Q Select Up'-Zähler 254 und der Bits 11-07 in das A/D-Register 227 des Kanals 1.
Der DMAC 209 antwortet mit einem Signal DTACK an die Logik 253, die es in eine 32-Bit-Port DSACK Antwort auf den Leitungen 266a, b an das PE62 umwandelt. Diese Aktion alarmiert die BCU 156, eine Hochprioritätsmeldungs-Übertragung vom örtlichen Speicher 210 auf den S/370 BSM 162 einzuleiten. Die Übertragungsbytezählung, zusammen mit den zusätzlichen Daten gemäß Fig. 452 werden während eines BCU-generierten Befehls 'Q Select Up' an den Busadapter 154 geschickt. Der Q Select Zähler 254 wird in die Bits 4-7 des Schreibbefehlsregisters 225 des Kanals 1 geladen. Die BCU legt den Befehl 'Q Select Up' über den Bus 290 in das Register 225 (Kanal 1); und die Daten im Register 225 werden auf den Adapterbus 252 (Kanal 1) im Format gemäß Fig. 45AA gelegt, worin die Bits die folgende Bedeutung haben:
0-1 = BSM 'Select up'-Befehl (Schreiben),
2-7 = Feldlänge minus 1 (16 Bytes).
Informationen, die über Register 227 auf den Adressen/Datenbus 251 gelegt werden, sind in Fig. 45AB dargestellt, wobei die Bits die folgende Bedeutung haben:
0-3 = Speicherschlüssel
4-6 = Null
7 = 1 = Zugriff auf Kundenbereich
0 = Zugriff auf Mikrocodebereich;
8-31 = Gleichgültig.
Die Daten auf den Bussen 252 und 251 werden in die Adapterregister 125 bzw. 123 übertragen. Dann aktiviert die BCU- Logik 253 die REQ-Leitung 263d (DMA-Kanal-3-Anforderung). Der DMAC 209 legt die E/A-Puffer-Anfangsadresse (vom MAR) auf den örtlichen Bus 247 und setzt die ACK-Leitung (DMAC-Kanal-3- Acknowledge) 264d hoch. Die BCU 156 überträgt dann in zwei Teilzyklen über das SYNC-Register 113 die ersten vier Datenbytes vom angesprochenen E/A-Puffer im örtlichen Speicher 210 auf den Adapterpuffer 260. Die nachfolgenden vier Byte- Datenblöcke werden durch Sequenzen, die vom Befehl 'Tag Up' geleitet werden, an den Busadapter 154, und über die REQ/ACK Leitungen 263d, 264d zum DMAC übertragen. Die BCU 156 dekrementiert die Byte-Zählung für jedes Doppelwort (32 Bits), das an den Busadapter 154 geschickt wird.
Der Busadapter 154 wandelt den Befehl 'Q Select Up' in einen S/370 Prozessorbus E/A-Speicher-Befehl zum Senden der Meldung an den Bereich 189 des Speichers 162 um: das Format des Befehls wird in Fig. 45AC dargestellt, worin die PROC BUS 170 Bits folgende Bedeutung haben:
0 = 0 = E/A-Speicherbefehl
1 = 0 = Speicheroperation
2-7 = Feldlänge (max. 64 Bytes)
8-31 = Reale Byte-Adresse (aus den Adapterregistern 110, 112).
Der Prozessor 85 SCHLÜSSEL/STATUS-Bus hat Daten im Format gemäß Fig. 45AD, worin die Bits folgende Bedeutung haben:
0-3 = Speicherschlüssel,
4 = Keine dynamische Übersetzung.
Wenn alle Meldungsdaten auf den Busadapter 154 (Byte-Zählung = 0) übertragen sind, aktiviert der DMAC 209 seine Interrupt- Leitung 258a an den S/88 Prozessor-Prioritätscodierer 212. Der DMAC 209 legt Interrupt-Vektoren vom niedrigstwertigen Byte seines Datenbusses 248 auf den S/88 Prozessordatenbus 161D, Bits 23-16 über den Treiberempfänger 234 und Bits 23-16 des örtlichen Datenbusses 223. Der DMAC gibt ein 16-Bit DSACK an PE 62 zurück.

(d) BCU Status-Befehl

Ein Befehl 'Read BCU Status' kann vom S/88 Prozessor 62 ausgegeben werden, um den augenblicklichen Status der BCU 156 zu lesen. Der Befehl wird vom S/88 Prozessor 62 im Format gemäß Fig. 45AE auf den Adressenbus 247 gelegt, wobei die Bits folgende Bedeutung haben:
31-00 = 007E010C - Befehl BCU Status lesen.
Die BCU legt dann den in Fig. 45AF gezeigten Status auf den Datenbus und gibt DSACK (32 Bit Port) auf den Bus 266 PE62. Die Bits in Fig. 45AF haben die folgende Bedeutung:
31-29 = Adapterbus Kanal 0 Status - Schlüsselprüfung, Adressenprüfung
28 = 1 = Letzter Datenzyklus
0 = Alle sonstigen Datenzyklen
27-26 = Adapterbus Kanal 1 Status Schlüsselprüfung, Adressenprüfung
25 = Puffer nicht frei (Befehl Q Select Up)
24 = 1 = Letzter Datenzyklus
0 = alle sonstigen Datenzyklen
23 = Adapterbus Kanal 0 'Tag Down'
22 = Adapterbus Kanal 1 'Tag Down'
21 = BSM Read Sync Check
20 = BSM Read Select Up Request/Pending Latch
19 = BSM Write Select Up Request/Pending Latch
18 = Q Select Up Request/Pending Latch
17 = Mailbox-Lesen im Gang
16 = BSM Lesen im Gang
15 = BSM Schreiben im Gang
14 = Q Select Up im Gang
Das BCU Status Bit 21 (BSM Read Sync Check - BSM Gleichlaufprüfung lesen) wird rückgestellt, nachdem es vom S/88 Prozessor 62 gelesen wurde. Dieses Bit zeigt an, daß die Busadapter 154- und BCU 156-Bytezählung nicht übereinstimmen, wenn eine BSM-Leseoperation endet; daher ist ein Fehler aufgetreten, der eine Neu-Synchronisierung erfordert.
Für eine BSM-Schreiboperation aktiviert der Busadapter 154 'Tag Down' 262b, um anzuzeigen, daß alle Daten eingegangen sind. Dann wird 'Tag down' 262b von Busadapter 154 deaktiviert und zu diesem Zeitpunkt werden die Status-Indikatoren an die BCU 156 gegeben und von ihr aufgenommen. Wenn 'Tag Down' nicht innerhalb 100 us deaktiviert wird, aktiviert die BCU 156 eine Löschleitung (nicht dargestellt) zum Busadapter 154. Das bewirkt dann, daß sich der Busadapter 154 selbst von der BCU 156 abkoppelt. 'Tag Down' 262b wird auch von Busadapter 154 benutzt, um einen Fehler anzuzeigen, der nicht über den Befehls/Status-Bus 252 an die BCU 156 gemeldet werden kann.

(e) Programmierter BCU Reset

Ein vom PE62 ausgegebener programmierter BCU-Reset führt an der BCU 156 die gleichen Funktionen durch wie ein Einschalt- Reset. Er kann jederzeit abgerufen werden, um die BCU von jedem unnormalen Zustand zu befreien. Jedoch muß die Hardware zum Durchführen dieses Befehls einen örtlichen Bus-Zyklus erkennen (007EXXXX decodieren). '
Der Befehl wird vom S/88 Prozessor auf den örtlichen Adressenbus 247 im Format gemäß Fig. 45AG gelegt, wobei die Bits folgende Bedeutung haben:
31-00 = 007E0000 - Befehl Reset BCU
Der Datenbusinhalt wird von der BCU 156 ignoriert. Die BCU 156 gibt DSACK (32 Bit Port) über die Leitungen 266a, b an den S/88 Prozessor 62 zurück.

ZÄHLUNG, SCHLÜSSEL UND DATENSPURFORMAT-EMULATION (Fig. 46A-K)

Die Emulation eines S/370 DASD auf S/88 wird beispielhaft beschrieben, um eine bevorzugte Art und Weise zu illustrieren, auf die S/370 E/A-Programme von einem S/88 und von E/A- Vorrichtungen ausgeführt werden können. Das S/370 wird als Objektsystem, und das S/88 als Zielsystem bezeichnet. DASD- (Direct Access Storage Device - Direktzugriffsspeicher)-Daten für das Objektsystem werden vom Zielsystem in einem Emulationsformat bewahrt. Der S/370 Code, der auf dem S/370 Prozessor läuft, wird als Objektsystem-Software bezeichnet. Die Diskussion ist in vier Teile gegliedert:
1) Das Objektsystem - eine Kurzbeschreibung des Zählungs-, Schlüssel- und Datenspeicherformats, das von vorhandenen S/370 Direktspeichererzeugnissen benutzt wird.
2) Das Zielsystem - Beschreibung des DASD-Programm- Schnittstellenmodells.
3) Das Emulationsformat - Beschreibung der Abbildung des Objektsystemfelds auf die benutzten Emulationsformate.
4) Die Emulationsfunktion - Beschreibung der Abbildung der Objektsystemfunktionen auf die benutzten Emulationsfunktionen.

1. DAS OBJEKTSYSTEM

Das physikalische Medium DASD wird in Zylinder, und die Zylinder werden in Spuren partitioniert. Die jeweilige Anzahl und ihre Kapazität ist unterschiedlich je nach verschiedenen DASD-Typen und -Modellen. Jeder Zylinder ist durch eine Zwei- Byte-Zylindernummer (CC) programmadressierbar, und auf die einzelnen Spuren in einem Zylinder wird zugegriffen durch gesonderte Lese/Schreibköpfe, deren jeder durch eine Zwei-Byte- Kopfnummer (HH) adressiert werden kann. Der physikalische Ort einer Spur wird angegeben durch seine Zylinder- und Kopfnummer und wird daher durch die Vier-Byte-Spuradresse (CCHH) spezifiziert. Jede Spur enthält eine Spuradresse, einen Spur- Deskriptor (Satz 0) und einen oder mehrere Datensätze. Die Größe der einzelnen Datensätze ist programmierbar; und wenn die Spuradresse und die Datensatzgrößen auf eine Spur geschrieben sind, gilt diese Spur als formatiert. Alle Spuren werden von ihrem Spurindex auf den nachfolgenden Spurindex formatiert. Fig. 46A stellt eine solche Spur dar.
Die Basisinformationseinheit, die auf dem physikalischen Medium aufgezeichnet wird, ist ein Daten-Byte bestehend aus acht Bits. Ein Gruppe Daten-Bytes ergeben einen Bereich und die Vorrichtung trennt die Bereiche durch Schreiben von Lücken zwischen die einzelnen Bereiche. Jeder Datensatz besteht aus zwei (Zählung, Daten) oder drei (Zählung, Schlüssel, Daten) Bereichen, während die Spuradresse nur aus einem einzi gen Bereich besteht. Die drei Bereiche, die einen Objektsystem-Satz ergeben, sind: Zählung, Schlüssel (wahlweise) und Daten.
Der Zählbereich enthält die folgenden Felder:
Datensatz 0 (Spur-Deskriptor) ist immer der erste Satz nach der Spuradresse. Im bevorzugten Programmiersystem definiert der Satz 0 CCHH die alternative Spur, wenn die Spur als gestört geflaggt war. Die Schlüssellänge ist im Normalfall Null für Satz 0. Satz 0 kann von einem oder mehreren Datensätzen gefolgt sein. Der Schlüsselbereich ist optional, und falls vorhanden, kann er 1 bis 255 Bytes enthalten. Die Nummer eines Satzes wird bestimmt, wenn ein CCW-Befehl 'Format Schreiben' Zählung, Schlüssel und Datenbereiche schreibt. Nach dem Formatieren des Satzes können die Anwenderbereiche gelesen und/oder geschrieben werden (unter Verwendung weiterer CCW- Befehle), ohne benachbarte Sätze auf dieser Spur zu zerstören. Wenn ein Satz umformatiert wird, werden die ihm auf der gleichen Spur folgenden Sätze zerstört.

2. DAS ZIELSYSTEM

DASD (Fig. 46B) wird an den S/88 Mikrocode geschickt in der Form von Dateien, die 4096-Byte-Blöcke enthalten, die sequentiell ab Eins numeriert sind. Der Emulationsmechanismus bildet Objektsystemformat und -funktion in eine geeignete Zielsystemformat- und Funktionskombination ab.

3. DAS EMULATIONSFORMAT

Die physikalischen Parameter der verschiedenen DASD-Typen und -Modelle im Objektsystem sind unterschiedlich. Die DASD-Typ- und -modellnummer zusammen mit den verschiedenen Parametern werden im ersten Datenblock, INFO, der Zielsystemdatei gehalten, Fig. 46C. Der Rest der Datei enthält die emulierten Objektspurdaten Fig. 46C. Die Daten für jede Spur werden in einer ganzzahligen Datenblocknummer bewahrt. Die Anzahl der Zielsystemdatenblöcke, die für jede Spur erforderlich sind, ist ein Parameter, der im ersten Datenblock gespeichert ist. Jede Spur im Objektsystem, die mit CCHH=0000 beginnt, wird in sequentieller Reihenfolge in der Zielsystemdatei gespeichert. Ihre Anfangsblocknummer kann aufgrund der CCHH und der im INFO-Block enthaltenen Objektplatten-Dimensionen berechnet werden.
Jede emulierte Spur (Fig. 46D) enthält ein Unterverzeichnis der augenblicklich auf dieser Spur liegenden Sätze, eine Unterverzeichnis-Kopfzeile, sowie die Anwenderdaten (Schlüssel, Daten) für jeden Satz. Das Unterverzeichnis wird benutzt, um die Daten eines spezifischen Satzes zu finden, eine Suche nach einem Datensatz oder nach Schlüsseloperationen durchzuführen, auf den letzten Datensatz einer Spur zuzugreifen, und den Spurüberlauf zu behandeln.
Objektsystemdaten werden in der Emulationsumgebung auf eine von drei Arten behandelt: Beibehalten, implizit behalten oder nicht behalten.
Alle Lücken sind unnötig und werden nicht beibehalten. ECC- Daten werden weder geschaffen noch beibehalten, weil die Datenintegrität vom Zielsystem gewahrt bleibt. Da das vom Zielsystem vorgesehene Programmodell alle fehlerhaften physikalischen Oberflächenbereiche ausschließt, werden Alternativspu ren im Objektsystem in fehlerfreier Weise implementiert. Das heißt, daß der Teil des Flag-Byte (E), der den Spurzustand angibt, nicht beibehalten bleibt, und Flag-Bytes, die von der Objektsystemsoftware geschrieben werden, auf Gültigkeit geprüft und ausgeschlossen werden.
Die von der System-Software durchgegebene CCHH (Spuradresse) wird benutzt, um den Ort der emulierten Spur in der Zielsystem-DASD-Datei zu berechnen. Sie steht in der Spurkopfzeile der nachstehenden Beschreibung, wird aber nicht durch den Zähl- und Spuradressenbereich der emulierten Spur weitergegeben. Die Spuradresse wird nicht als ausdrücklicher Bereich beibehalten. Die Datensatzzahl (R), die auch von der Objektsystem-Software durchgegeben wird, wird implizit beibehalten und erscheint nicht als explizites Datum.
Anwenderdaten, wahlweise KEY- und DATA-Felder für jeden Datensatz, werden sequentiell in der emulierten Spur unmittelbar nach dem Spurverzeichnis beibehalten, Fig. 46D.
Die restlichen Objektsystemdaten [F (logischer Datensatz- Spurüberlauf), KL und DL] sind im Spurverzeichnis, Fig. 46E, enthalten. Ein Verzeichniseintrag enthält F, KL und DL sowie einen Zeiger p auf die Anwenderdaten (KEY und DATA) für jeden Datensatz. R ist implizit beibehalten als Verzeichnis- Eintragsnummer. Fig. 46E zeigt die Kopfzeile, Verzeichnis- und Anwenderdatengestaltung sowie die Abbildung einer emulierten Spur auf die Zielsystem-4kB-Blöcke. Zeiger p0-p2 zeigen auf die Anfangsadressen (innerhalb der 4kB-Blöcke) der Anwenderdatensätze 0-2.

4. EMULATIONSFUNKTIONEN

Dieser Abschnitt spricht die Anwendung des oben beschriebenen Emulationsformats an durch Bereitstellen einiger der Objektsystem-DASD-CCW-Befehle. Die Fig. 46F-K einschließlich, stel len Daten dar, die von der Objektsystem-Software während der Lese- und Schreiboperationen übertragen werden. Für CCW- Operationen (Ops), die die Spuradresse betreffen, werden die F- und CCHH-Werte der Fig. 46F berechnet und/oder geprüft, aber nichts wird auf die emulierte Spur geschrieben.
Für CCW-Ops, die den Datensatz 0, Fig. 46G, betreffen, werden die Felder CCHH und R geprüft, aber nichts wird geschrieben. Die Felder KL und DL werden zum/vom geeigneten Verzeichniseintrag übertragen. Datensatz Null steht mit Offset Null am Anwenderdatenbereich. Der Lese/Schreib-Datensatz 0 richtet seinen Kopf immer auf den ersten Datensatz in der Spur.
CCW-Ops, die die Zählung betreffen, richten den Kopf auf den nächsten Datensatz in der Spur, Fig. 46H. Für CCW-Ops, die Schlüssel und Daten betreffen, werden Ort und Größe der Anwenderdaten im Verzeichnis gefunden, Fig. 46I. CCW-Ops, die Zählung, Schlüssel und Daten betreffen, richten den Lese/Schreibkopf auf den nächsten Datensatz in der Spur, Fig. 46J. Für CCW-Ops, die multiple Zählung, Schlüssel und Daten betreffen, beginnt die Bearbeitung mit dem nächsten Verzeichniseintrag und fährt fort bis zum letzten gültigen Verzeichniseintrag, Fig. 46K.

Gemeinsame Benutzung des Realen Speichers 16 durch S/88 und S/370

1. Einführung

Jetzt wird das "Stehlen" einer oder mehrerer Bereiche im realen (physikalischen) Speicher 16 für einen oder mehrere S/370 Prozessoren und die Verwaltung und Abbildung des Speichers 16 in weiteren Einzelheiten beschrieben, dabei wird Bezug genommen auf:
Fig. 10, die konzeptionell den virtuellen Speicher 106 und den physikalischen Speicher 16 sowie die Zuteilung von S/370 physikalischen Speicherbereichen 162-164 für S/370 Prozessoren 21, 23 und 25, 27 und 29, 31 illustriert;
Fig. 47, die in Diagrammform das Verfahrten zum Erfassen eines S/370 Speicherbereichs aus dem physikalischen S/88 Speicher 16 illustriert; und
Fig. 48 A-K, die bekannte virtuelle/physikalische Softwareabbildung illustrieren, wie sie in der S/88 Speicherverwaltung gezeigt werden, wobei das Abbilden so gesteuert wird, daß es das Erfassen des S/370 Speicherbereichs zuläßt.
Der Speicher 16 unterteilt sich in 4kB Seiten und eine Vielzahl von Speicherorganisationseinträgen (mme), jeweils einer je 4kB Seite, sind in mme-Anordnungen (Fig. 48A) enthalten, die zusammen den gesamten Speicher 16 abbilden. Die Einträge, die den nicht für die Anwendung zugeteilten Seiten entsprechen, sind in einer "Freiliste" (d. i. die Speicherzuweisungs- Warteschlange) zusammengefaßt durch Einschließen der physikalischen Speicherzuteilungsnummern (Zeiger) der vorherigen und der nächsten Einträge in die Liste. Ein Software-Zeiger im S/88 Betriebssystem zeigt immer auf den Anfang der Freiliste. Physikalische Speicherseiten werden verschiedenen Prozessen vom Anfang dieser Freiliste zugewiesen, und der Freiliste zurückgegebene Seiten werden vorzugsweise an den Anfang der Freiliste gesetzt. Die "vorherige und nächste" Seitennummern und der Softwarezeiger auf den Anfang der Freiliste werden jeweils richtig aktualisiert.
Beim Booten des Systems/88 werden diese Einträge in sequentieller Adressenfolge auf die Freiliste gesetzt; nur wenige Seiten werden zu diesem Zeitpunkt zur Anwendung zugeteilt. Daher sind große, zusammenhängende Bereiche des Speichers 16 für die Zuweisung von der Freiliste verfügbar. Dabei müssen beim Booten die Speicherbereiche (z. B. 162, 163, 164) für die S/370 Prozessoren "gestohlen" werden. Anschließend, wenn Seiten aus der Freiliste zugewiesen und erforderlichenfalls wieder zurückgegeben werden, werden die großen zusammenhängenden Blöcke in der Freiliste fraktioniert und sind nicht mehr länger verfügbar. Wenn ein Versuch gemacht würde, einen zusammenhängenden S/370 Bereich zu schaffen, müßten alle Prozesse aufgehalten werden und komplexe Routinen müßten ausgeführt werden, um bereits verschiedenen Prozessen zugeteilte Speicherblöcke neu zuzuweisen, bis ein genügend großer zusammenhängender Speicher verfügbar würde.
Nachstehend beschriebene Service-Routinen im Applikationsprogramm EXEC370 sehen die Funktionen zum Stehlen von S/370 Speicherbereichen aus dem S/88 Betriebssystem vor.

2. Abbilden des S/88 Speichers 16

Zunächst wird jedoch eine bevorzugte Form der Verwaltung/Abbildung des S/88 Hauptspeichers 16 beschrieben unter Bezugnahme auf die Fig. 48 A-K einschließlich. Fig. 48A ist eine einfache Übersicht der Softwarestruktur, die vom S/88 Betriebssystem (S/88 OS) zum Beibehalten eines virtuellen Adressenraums eines Prozesses aufgebaut wird. Die Softwarestruktur beinhaltet die folgenden Elemente:
pte - process table entry. (Stellt einen Prozeß dar)
pmb - process map block(s). Verkettet enthalten sie Zeiger (pme's) auf die apte's für den virtuellen Adressenraum dieses Prozesses.
pmbp - ein Zeiger im pte auf den ersten pmb der Kette.
pme - process map entries (Zeiger auf die apte's) enthalten in den pmb's.
mme - physikalische Speicheraufzeichnungseinträge. Enthalten in den mme-Anordnungen gibt es einen mme je 4kB Seite physikalischen Speicher im System, d.i. im Speicher 16.
apte - active page table entry. Enthalten in apt-Blöcken gibt es jeweils einen apte je einzige virtuelle Seite im System.
vpn - virtual page number innerhalb eines virtuellen Adreßraums eines Prozesses.
pmt - process management table. Es gibt einen Zeiger ptep in der pmt für jeden Prozeß (pte) im System.
ptep - process table entry pointer auf einen Prozeß.
Die Speicherabbildungsstruktur in Fig. 48A wird von der Speicherverwaltungseinheit 105 (Fig. 10 und 47) benutzt. Sie besteht aus einem oder mehreren mme Anordnungen (Fig. 48C), die in der bevorzugten Ausführungsform jeweils 512 geordnete mme's enthalten. Jeder mme repräsentiert eine 4kB Seite realen Speicher 16, und daher repräsentiert eine mme-Anordnung 512 · 4kB = 2 MB zusammenhängenden Speicherplatz.
Der 'Storage Map Array' bezeichnete Kasten in Fig. 47 illustriert begrifflich alle mme-Anordnungen, die in sequentieller Adressenordungsreihenfolge angeordnet sind.
Mme's sind gewöhnlich in eine von drei Listen eingereiht:
1.) Benutzt-Liste, mme, der einem Prozeß zugeordnet ist.
2.) Rückgewinnungsliste, mme, der wieder einer Freiliste zuzuordnen ist.
3.) Freiliste, mme, der frei für die Zuordnung zu einem Prozeß ist. Wenn mme's von einer Liste zu einer anderen bewegt werden, werden ihre Zeiger entsprechend aktualisiert.
Wenn sie nicht auf einer Liste sind, repräsentieren sie entweder eine festverdrahtete Seite oder sind in einem Übergangszustand. Die mme-Datenstruktur, die von der Speicherverwaltungseinheit 105 benutzt wird, enthält drei Listenzeiger, gezeigt in Fig. 48B, worin:
flags wired Seite ist verdrahtet
I/O in progress write Platten-E/A läuft augenblicklich zeigt, daß der letzte (oder augenblickliche) E/A für diesen Datenübertragungsblock ein Schreiben auf die Platte war
connected Seite hat ein PTW (physikalisches Tabellenwort) in den Hardware-Registern
modified letzter Blick auf modifiziertes Bit nicht benutzt (2)
evict cleanup benachrichtigt Stelle zum Löschen unbenutzt (1)
evict free benachrichtigt Stelle zum Löschen und freisetzen dieser Seite
page fault irgend ein pf wartet auf dieser Seite
next mme ppn (physikalische Seiten-Nummer) auf nächsten mme
prev mme ppn auf vorhergehenden mme
address Plattenadresse solange im Speicher aptep Zeiger auf apte für diese Seite
Das "nächste" und das "vorherige" mme-Feld wird benutzt, um die verketteten Listen (benutzt, rückgewinnen, Freiliste) zu erstellen.
Es sind die physikalischen Seitenzahlen zum nächsten mme und zum vorhergehenden mme, die geändert werden, wie nachstehend beschrieben wird, wenn der physikalische Speicher des D/88 für den S/370 Speicherbereich erfaßt wird. In der bevorzugten Ausführungsform ist jede mmep Anordnung (Fig. 48C) eine Liste von 128 Zeigern, deren jeder eine virtuelle Adresse einer mme-Anordnung ist. Die ersten n Zeiger sind eine geordnete Liste aller mme-Anordnungen. Die restlichen 128-n Zeiger sind NULL. Das gibt die Fähigkeit, 128 · 2 MB = 256 MB reellen Speicher zu überwachen. Jeder dieser Zeiger enthält die 16 höherwertigen (höhere Ordnung) Bits einer physikalischen Adresse, genannt eine physikalische Seitennummer (ppn), und werden als Zeiger auf einen spezifischen mme benutzt. Die sieben höherwertigen Bits der ppn wählen die mme Anordnung, und die neun niederwertigen Bits wählen den ppn der mme innerhalb der Anordnung. Die zwölf niederwertigen Bits der physikalischen Adresse sind ein Offset auf die reale (physikalische) Seite des Speichers 16.
Eine Speicherabbildungsinformations-Struktur (mem map info) (Fig. 48D) wird benutzt, um den für die Abbildung benutzten Speicher zu verfolgen, darin ist:
mem map infop-1 Zeiger auf die erste mem map Informationsstruktur
next mem map infop Zeiger auf die nächste mem map Informationsstruktur
n pages Anzahl von 4K Seiten realer Speicher, der von dieser Abbildung benutzt wird (max. 16)
per page (16) der Rest der Struktur ist eine Anordnung Informationen per Seite
ppn physikalische Seitenzahl auf mme für diese Seite
Die aktiven Seiten-Tabelleneinträge (apte) werden benutzt, um die virtuelle Speicherung zu verfolgen. Es gibt einen apte je 4kB Seiten virtueller Speicher in allen virtuellen Speicherräumen des Systems. Die apte-Struktur (Fig. 48E) zeigt den/die Eigner des virtuellen Raums, die virtuelle Adresse der Seite und die reale Speicheradresse der Plattenadressen, wenn sie seitenweise ausgelagert werden.
Wenn mehr als ein Prozeß sich in den gleichen virtuellen Adressenraum teilen, werden alle Prozesse über einen apte- Nachsatz (Fig. 48 G) identifiziert; und der apte für jede virtuelle Seite zeigt auf den Nachsatz.
Jeder apte ist 12 Bytes lang, und 256 Einträge sind in jedem aktiven Seitentabellen-(apt)-Block enthalten (Fig. 48F). Die relative Position der apte's in einem Block hat keine Bedeutung. Alle unbenutzten apte's sind auf einer freien aptep- Liste aufgereiht. Wenn zusätzliche apte's benötigt werden und die Liste Null ist, wird eine neuer apt-Block im verdrahteten Arbeitsspeicher zugewiesen; und die gesamten 256 apte's werden auf der freien aptep-Liste aufgereiht.
Der apt-Nachsatz (Fig. 48 G) wird für gemeinsam benutzte Programmbereiche hergenommen, er wird im verdrahteten System- Arbeitsspeicher zugewiesen, und durch einen EITE (Executable Image Table Entry - ausführbarer Bildtabelleneintrag) oder einen apte wird darauf zugegriffen. Es gibt vier Nachsätze je Programm (einen je Programmbereich). Die Nachsätze ermöglichen es, daß das System alle PTWs findet, die auf eine Seite zeigen wenn sie herausgenommen wird.
Die apt-Nachsatzstruktur umfaßt:
n procs Anzahl der Prozesse, die diesen Nachsatz benutzen
v base (Bereichsbasis vpn) erste virtuelle Seite dieses Bereichs
n pages Anzahl Seiten im Bereich
users Bitmap der Nachsatzbenutzer
pp info(o:nnp) der Rest der Struktur ist eine Anordnung prozeßgebundener Informationen
npp Größe der Anordnung
n ptws Anzahl der PTWs, die zu diesem Zeitpunkt angeschlossen sind
aptep Zeiger auf APTE für diese Seite
Der Prozeßtabelleneintrag (pte) (Fig. 48H) enthält die Informationen, die benötigt werden, um einen Prozeß zu verwalten; sie enthält Informationen über den virtuellen Adressenspeicher des Prozesses. Jeder Tabelleneintrag beinhaltet:
first pmb ptr Zeiger auf den ersten pmb in einer pmb-Liste für diesen Prozeß
map root tbl phys addr physikalische Adresse der physikalischen Abbildung
map root ptr phys virtuelle Adresse der physikalischen Abbildung
map root ptr virt virtuelle Abbildung
pdr ptr Adresse des prozeßzugeordneten Datenbereichs
Die Prozeßabbildungs-Blockstruktur (Fig. 48I) wird benutzt zum Abbilden eines virtuellen Prozeßspeicherraums auf einen realen Speicherraum und beinhaltet:
nextp Zeiger auf den nächsten pmb für diesen Prozeß
base vpn virtuelle Basis-Seitenzahl, die erste virtuelle Seitenzahl dieses pmb
(die sechs niedrigstwertigen Bits sind Null.)
map addr physikalische Adresse der Abbildung
pme Prozeßabbildungseinträge 0-63, der Rest der Struktur ist eine Anordnung von Informationen je Seite. Der Index für diese Anordnung sind die sechs niedrigstwertigen Bits der vpn.
Die Prozeßverwaltungstabelle (Fig. 48 J) enthält Informationen, die vom Scheduler benutzt werden, einschließlich einer Liste von Zeigern ptep auf alle Prozesse im System, Anzahl der im System verfügbaren Seiten und die Seitenzahl der zweckgebundenen Seiten.
Das physikalische Tabellenwort (ptw) der Fig. 48K beinhaltet:
ac1 ptw Zugriffscode.
ppn physikalische Seitennummer der gewünschten Seite
ac2 ptw Zugriffscode.
u dieses ptw wird benutzt

3. Anlaufprozedur

Das System/88 beinhaltet eine Anlaufprozedur, die das System hochfährt und Programm- und Datenmodule bootet, die in einer Anlaufdatei eingeschlossen sind.
Beim automatischen Anlaufen fährt der programmierbare Festwertspeicher (prom) 181 (Fig. 12) die Diagnose- und Selbsttests sowohl für die System/88- als auch die System/370- Komponenten. Nach Durchführung dieser Tests liest der PROM 181 ein Dienstprogramm, das das S/88 Betriebssystem von einer Stammplatte lädt (nicht dargestellt).
Der Modulanlaufcode initialisiert alle konfigurierten Vorrichtungen und Platten und stellt den internen Taktgeber nach der System-Kalenderuhr. Diese Datei enthält Befehle, die das Betriebssystem als Teil der Prozedur zum Anlaufenlassen eines Moduls ausführt. Diese Prozedur beinhaltet Funktionen:
Lesen der Tabellendateien, die die Konfigurationen der Boards, Platten und Vorrichtungen spezifizieren, die mit dem Modul verbunden sind;
Identifizieren der Module im System; und
Starten verschiedener Systemdienstprozesse.
Die Moduldatei liefert ausreichend Daten, um ein neues System hochzufahren, und kann vom Anwender gemäß seinen Bedürfnissen modifiziert werden. Um einen S/370 Bereich 162-164 aus dem S/88 Hauptspeicher 16 abzurufen, sind verschiedene Anweisungen in die Befehlsdatei des Modulanlaufcodes eingefügt. Wenn wir z. B. die Konfiguration der Fig. 10 mit drei S/370 Prozessoren 21, 23 und 25, 27 und 29, 31, und drei S/370 Speicherbereiche 162, 163 und 164 für diese Prozessoren annehmen, werden die folgenden Anweisungen in die Befehlsdatei des Modulanlaufcodes eingefügt:
Start S/370 processor #1 VM 8 megabytes
Start S/370 processor #2 AIX 4 megabytes
Start S/370 processor #3 VSE 16 megabytes

4. S/370 Dienstprogramm anlaufen lassen

Jeder Befehl 'Start S/370' läßt eine Software-Routine ablaufen, die ausgeführt wird, um einen Block mit realem Speicherraum aus dem Speicher 16 für die besonderen S/370 Prozessoren #1, #2 oder #3 zu "stehlen". Dann wird das geeignete S/370 Betriebssystem in den "gestohlenen" realen Speicherplatz IPLurgeladen. Die Funktionen der Software-Routine sind, Speicherbereiche aus dem S/88 Speicher zu erfassen und diese Bereiche ggf. zu "ersetzen". Zur Durchführung dieser Funktionen werden fünf Subroutinen benutzt:
a) Die Subroutine S/370 Displace Storage zieht einen physikalischen Speicherblock aus den S/88 Betriebssystemtabellen heraus. Die Anfangsadresse des Blocks liegt auf einer Megabyte-Grenze und seine Größe wird in Megabyte-Ganzzahlen angegeben.
Die physikalische Seitennummer der ersten niedrigsten oder höchsten 4k Seite realer Speicher im Block. Die acht niedrigstwertigen Bits des ppn sind Null, und die reale Anfangsadresse des Blocks ist 4096*ppn.
Error_code (output)
insufficient_free - Es gibt nicht genug aufeinanderfolgende freie Blöcke, die zur Verfügung stehen, um mindestens 1 MB zu verschieben.
provided_less - Die Anzahl der verschobenen MB ist geringer als angefordert.
b) Die Subroutine S/370 Replace Storage gibt einen physikalischen Speicherblock an die S/88 Betriebssystem-Tabellen zurück.

Arguments

n_blks (input)
Die Anzahl der zusammenhängenden Megabytes, die zurückgegeben werden.
ppn_(input)
Die physikalische Seitennummer des Blockanfangs. Die acht niedrigstwertigen Bits des ppn müssen Null sein.
Error_code (output)
cannot_free_connected - Muß S/370 Close Storage benutzen vor dem Versuch, Speicher an VOS zurückzugeben.
c) Die Subroutine S/370 Open Storage verbindet einen Teil oder den ganzen vorher verschobenen physikalischen Speicherraum mit dem virtuellen Speicherraum des Aufrufers und liefert die virtuelle Seitennumer. Jede geeignete apte und pme wird gemacht und die Abbildung 'virtuell auf physikalisch' wird ausgeführt. Der Zugriffscode ist "Read/Write" und der Speicher wird verdrahtet.

Arguments

n_blks (input)
Die Anzahl der angeforderten zusammenhängenden Megabytes.
ppn (output)
Die physikalische Seitennummer der ersten 4k Seite im Bereich. Die acht niedrigstwertigen Bits des ppn sind Null.
vpn (output)
Die virtuelle Seitennummer der ersten 4k Seite im Bereich. Die acht niedrigstwertigen Bits von vpn sind Null, und die virtuelle Adresse ist 4096*vpn.
error_code (output)
ein zurückgegebener Fehlercode.

d) S/370 Close Storage

Die Subroutine S/370 Close Storage schaltet den vorher geöffneten physikalischen Speicher vom virtuellen Adressenraum des Aufrufers ab. Die richtigen APTEs und PNEs werden an das S/88 Betriebssystem zurückgegeben und die Abbildung 'virtuell auf physikalisch' ist gestört. Der physikalische Speicher wird an die S/370 Routine displace storage zurückgegeben.

Arguments

n_blks (input)
Die Anzahl der zurückgegebenen zusammenhängenden Megabytes.
vpn (input)
Die virtuelle Seitennummer der ersten 4k Seite im Bereich wird zurückgegeben.
Error_code (output)
Ein zurückgegebener Fehlercode.
e) Gain Freedom ist eine Subroutine, die vom Programm START_370 aufgerufen wird. Sie setzt das Programm START_370 in den S/88-Administratormodus, so daß die obigen vier Subroutinen ausgeführt werden können. Sobald START_370 im Administratormodus steht, können die Vektorzeiger modifiziert werden zum Entfernen der Speicherblöcke aus dem S/88-Betriebssystem und Neuzuweisung der Speicher an jeden S/370 Prozessor.
Diese Subroutine wird benutzt, um die Speicherzuteilungen zu ändern und die manuellen Vektoren auf die Interrupt-Ebene 6 der S/88 Prozessoren zu setzen. Anwender bekommen aus Systemsicherheitsgründen keine Kenntnis von, oder Zugriff auf diesen Aufruf.

Arguments

give_take (input)
Ein Wert 0 setzt den Aufrufer in den Applikationsanwenderzustand, jeder andere Wert setzt den Anwender in den Administrator-Zustand.
Error_code (output)
Ein zurückgegebener Fehlercode.
Die Funktionsschritte der obigen Subroutinen sind wie folgt:
S/370 Displace Storage
1) Freimachen und mme-Anordnungsfreiliste verriegeln
2) Freiliste nach längster Kette aneinanderliegender freier mme's durchsuchen
3) Beide Enden auf MB-Grenzen runden und nblks berechnen, Anzahl der 4kB-Blöcke in der Kette
4) Wenn nblks > n_blks, dann setze nblks auf n_blks (Anzahl der angeforderten 4kB) und verändere Anfangs-ppn-Grenze
5) Gewählte Kette mme's aus Freiliste holen
6) npages von freien Systemzählungen abziehen
7) mme_arrays Freiliste entriegeln und Freiheit aufgeben
8) Setzen: ppn = base ppn
rc=error if nblks< n_blks
rc=error if nbls< = 0
rc=0 if no error

S/370 Replace Storage

1) Überprüfen, daß alle Einträge nicht verbunden sind, Flags auf Null setzen, und mme's richtig zusammenhängen. Error zurückgeben, falls ein Problem auftritt.
2) Gain_freedom, und mme_arrays Freiliste verriegeln
3) Freiliste nach gutem Platz zum Aufreihen der mme's durchsuchen
a. Erster Kandidat an Anfangs-ppn,
b. Zweiter Kandidat an Listenende.
4) Ganzen Block auf Freiliste aufreihen
5) npages zurück auf freie Systemzählung adieren
6) mme_arrays Freiliste entriegeln und Freiheit aufgeben

S/370 Open Storage

1) Tabelleneintrag dieses Prozesses finden und in seinem virtuellen Speicher auf pmb Grenze ein genügend großes Loch finden für n_blks MB. Sicherstellen, daß genug verschobene mme's vorhanden sind, um die Anforderung auszuführen. Error zurückgeben, falls es ein Problem gibt.
2) Erforderlichenfalls verdrahteten Raum für pmb's und apte's zuweisen
3) Ganze Struktur installieren:
mme's verdrahtet und verbunden
mme.aptep-> apte
pme.aptep-> apte
alle Flags richtig gesetzt
apte.ptep-> pte
4) Verbinde neu konstruierte pmb-Kette mit Aufgaben-pmb-Kette

Speicher schließen

1) Tabelleneintrag dieses Prozesses finden und von s$open_storage konstruierten pmb finden. Zurück, wenn keiner gefunden wird.
2) Diese pmb's von der Prozeß-pmb-Kette abkoppeln.
3) Für jeden apte, setup_ptw aufrufen um die reale Abbildung fehlzusetzen
4) verdrahteten Raum für pmb's und apte's an OS zurückgeben.
5) mme's an Routine Displace Storage zurückgeben

Freiheit gewinnen

1) Adresse des Arguments give_take holen
2) Gehe nach Schritt 7 wenn auf Freiheit verzichtet wird
Die folgenden Schritte gewinnen Freiheit
3) Falle 13 einfügen, die bewirkt, daß das OS zum Aufrufer zurückkehrt während er im Administatorzustand ist
4) Anwender-Stapeladresse holen und mit System-Stapelzeiger austauschen.
5) Systemstapeladresse im Anwender-Stapelzeiger abspeichern
6) zum Aufrufer im Administratorzustand auf dem Anwenderstapel zurückkehren.
Die folgenden Schritte geben die Freiheit auf
7) abgespeicherte Systemstapeladresse zurückholen und gegen Systemstapelzeiger austauschen.
8) Anwenderstapeladresse im Anwender Stapelzeiger ersetzen
9) Stapel modifizieren, so daß Fallenbearbeiter zu Schritt 11 zurückkehrt
10) zum Fallenbearbeiter zurückkehren
11) Fallenbearbeiter kehrt zu uns zurück
12) zum Aufrufer im Anwenderzustand auf Anwenderstapel zurückkehren.

5. Angewählte Zeichenkette der mme's aus Freiliste nehmen

FIRST MME gehört zum den ersten mme in der Kette, die herausgezogen werden soll, und die Anfangs-ppn enthält seine ppn (physical page number - physikalische Seitennummer). LAST MME gehört zum letzen mme in der Zeichenkette. Wenn FIRST MME am Kopf der Freiliste steht (vorangehendes mme-Feld ist gleich Null), wird der Freilistenzeiger auf das next_mme-Feld des LAST HUF gesetzt; so ist jetzt das auf LAST MME folgende mme am Kopf der Freiliste. Sonst wird das next mme-Feld des mme vor FIRST MM4E gleich dem LAST MME nach dem next_mme gesetzt. Wenn mehrere mme's nach dem LAST MME folgen (next_mme-Feld nicht Null) wird das vorhergehende mme-Feld des mme, das auf LAST MME folgt, gleich dem prev mme-Feld des FIRST MME gesetzt.

6. Storage Base und Size in STCI schreiben

Nachdem Speicheraum vom S/88 OS "Gestohlen" wurde, wird er partitioniert zwischen den S/370 Prozessoren gemäß den Forderungen, die in der Konfigurationsdatei angegeben sind. Die Konfigurationsanordnung wird im S/88 Kernspeicher aufgebaut, die die Anfangs-ppn und n blks je S/370 Prozessor enthält. Der Term n blks bedeutet die Anzahl der zusammenhängenden Megabytes Speicherstellen. Die ist gleich der Anzahl der gestohlenen (nicht aufgereihten) mme's geteilt durch 256. Wenn der EXEC370-Task für jeden 3/370 Prozessor in seinem entsprechenden S/88 Prozessor anläuft, benutzt er die entsprechenden Anfangs-ppn- und n blks-Werte, um ein STCI-Wort zusammenzusetzen. Dieses Wort wird dann in die virtuelle Adresse 007E01FC (in den Adressenraum des örtlichen Speichers 210) geschrieben und bewirkt die Initialisierung der STCI-Register 404 und 405 (Fig. 32B), die transparent für das S/88 Betriebssystem sind.
Der Abkopplungsmechanismus 216 und die BCU-Schnittstellenlogik 253, die oben bereits unter Bezugnahme auf die Fig. 19A, 20 beschrieben wurde, wird zur Initialisierung der Register 404, 405 benutzt.
Jedoch sind in der bevorzugten Ausführungsform, wie bereits in Fig. 32B gezeigt wurde, die Register 404, 405 direkt an den S/88 Prozessordatenbus 161D gekoppelt (anstatt an den BCU örtlichen Datenbus 223). Die Decodierlogik 280 der Logik 216 decodiert die obige virtuelle Adresse an Block AS aus der S/88 Hardware und gibt DSACK an den Prozessor 62 zurück. Die Register 404, 405 werden eingeschaltet über die STCI Select Leitung 458 aus der Logik 253. Die Bits 27-20 des STCI-Worts bilden die STCI-"Anfangs"-Adresse, und die Bits 23-20 bilden den S/370 Speicher-"Größen"-Wert. Die Bits 19-0 sind Null.

Initialisierungsfunktionen für S/88-Interrupts, die vom S/370 initiiert werden

Es gibt verschiedene Szenarien zum Senden von S/370 Interrupts an den Mikrocode des/der S/370 Interrupt-Steuerprogramm(e), die im S/88 resident sind, ohne Wissen des S/88 Betriebssystems. Drei davon werden hier beschrieben.
Ein erstes Verfahren beinhaltet die Modifizierung des S/88 Betriebssystemkerns durch Einschieben des S/370 Interrupt- Steuerprogrammcodes in das S/88 Betriebssystems auf der ersten Ebene des Interrupt-Steuerprogramms, so daß es als Teil dieses Objektmoduls zusammengebaut wird. Die Tabelle der Interruptvektoren ist enthalten in der Interrupt-Steuerprogramm-Quelle, und die vom S/370 benutzten Vektoren werden in der Quelle modifiziert, so daß sie auf den S/370 Interrupt- Steuerprogrammcode zeigen.
Diese Methode unterscheidet sich weitgehend von der Methode nach der S/88 Architektur, die wie folgt ist:
1) Jede Interrupt-Vorrichtung sollte in die Datei eingetragen werden, die sie, ihren Pfadname, die Board Adresse usw. dem S/88 Betriebssystem identifiziert.
2) Wenn das Interrupt-Steuerprogramm auf der ersten Ebene den Interrupt erhält, setzt es die geeignet formatierten Stapel, speichert alle Maschinen-Status und - Register ab, überprüft die Gültigkeit des Interrupts, und gibt den Interrupt auf ein Interrupt-Steuerprogramm der "Zweiten Ebene" weiter, das den spezifisch geschriebenen Vorrichtungs-Interruptcode des Entwicklers aufruft.
3) Wenn der Interruptcode abgespult ist, gibt er die Steuerung wieder an das betriebssystem-eigene Interrupt-Steuerprogramm zurück, das dafür sorgt, daß die Umgebung wiederhergestellt wird.
Die obige erste Methode umgeht das alles. Durch den Aufbau von S/370 Interruptvektoren, um auf die S/370 Intrerrupt- Routine zeigen, haben wir die ganze normale Interrupt- Bearbeitung vermieden, die vom S/88 Betriebssystem ausgeführt wird, und müssen S/370 nicht über die Vorrichtungsdatei identifizieren. Das ist ein echtes Software-Abkoppeln, da der Code anstatt der Hardware modifiziert wurde. Diese erste Methode ist am schnellsten und am wenigsten aufwendig, um die gewünschte, Interruptfunktion durchzuführen. Jedoch unterliegt diese Methode zusätzlicher Verwaltung für jede nachfolgende Freigabe des S/88 Betriebssystems. Sie erfordert wenigstens eine Kernbindung; und wenn das Interrupt-Steuerprogramm geändert wurde, muß der S/370 Interruptcode neu eingesetzt und das Interrupt-Steuerprogramm muß neu zusammengesetzt werden.
Ein zweites Verfahren betrifft die Modifizierung des Betriebssystem-Interruptvektors nach dem System-Boot und es ist diese Methode, auf die bei der Beschreibung des Hardware- Interruptmechanismus der Fig. 20 bezug genommen wird.
Diese zweite Methode erfordert, daß der S/370 Interruptcode in den virtuellen Adressenbereich des S/88 Betriebssystems (in der bevorzugten Auführungsform genau unter 007E0000) und die Modifikation des geeigneten Interruptvektors in das Interrupt-Steuerprogramms des Betriebssystemkerns gesetzt wird Diese Arbeit wird von der S/370 Initialisierungsroutine gemacht, nachdem das Betriebssystem initialisiert ist, (gleichzeitig mit dem Vorgang, in dem die S/370 Initialisierungsroutine Speicher "stiehlt"). Da die Initialisierungsroutine den S/88 Betriebssystemkern-Speicherbereich modifiziert, muß sie "Freiheit gewinnen" auf gleiche Weise, wie schon beim "Stehlen" von Speicherraum in der obigen Beschreibung erklärt wird. Diese zweite Methode erfordert keine Modifizierung der Verwaltung der einzelnen freigegebenen S/88 Betriebssystem kerne. Jedoch sind die S/370 Interrupts nicht funktional bis nach dem Hochfahren und Laufen des S/88 Betriebssystems.
Eine dritte Methode betrifft die Hardware-Darstellung des Interrupt-Vektorinhalts; und diese ist eine bevorzugte Alternative, weil keine Veränderung im S/88 Betriebssystemkern erforderlich ist, d. h. in der Vektortabelle wird keine Änderung vorgenommen.
Diese dritte Methode erfordert das Einlegen der S/370 Interruptroutine in den virtuellen Adressenspeicher des S/88 Betriebssystems und/oder den örtlichen Speicher der BCU als bekannte Festwertspeicher-(ROS)-Adresse. Die Interrupt-Routinen-Adresse(n) muß/müssen für die S/370-Hardware zugänglich gemacht werden, vorzugsweise im ROS. Das folgende Szenario wird zum Illustrieren dieser Methode angegeben:
1) S/370 (z. B. DMAC 209 in BCU 156) aktiviert den Interrupt-Request.
2) Die S/88 Prozessoreinheit 62 aktiviert Interrupt- Acknowledge, Data Strobe und Adreß-Strobe.
3) Die BCU legt eine Interrupt-Vektorzahl (das könnte zur leichteren Erkennung durchwegs Null, oder ein Offset auf unseren ROS-Vektorraum sein) auf den Datenbus 223 und aktiviert Data Strobe Acknowledge. Diese Vektorzahl ist, abgesehen von der gültigen Parität, ohne Konsequenz für den Prozessor 62.
4) Schließlich führt der Prozessor 62 einen Speicherlesezyklus durch, um den 4-Byte Interrupt-Vektor zu erhalten.
5) Die BCU erkennt diesen spezifischen Speicherzugriff (durch die virtuelle Adresse), koppelt den Prozessor 62 vom Zugriff auf den Speicher ab, und legt ihren eigenen 4-Byte Interrupt-Vektor auf (geholt vom S/370 ROS). Der S/370 ROS enthält so viele Vektoren wie nötig, mehrere für den DMAC, einen für die ROS-Board-Synchronisierung usw.
Dieses dritte Verfahren ermöglicht das Abkoppeln während der Board-Synchronisierung zum Zwecke der Synchronisierung der S/370 Hardware usw. Jedoch macht dieses Verfahren mehr Hardware erforderlich.

Freiheit gewinnen ohne das S/88 Betriebssystem zu modifizieren

Ein Verfahren ist vorstehend unter "S/370 Dienstprogramm anlaufen lassen" angegeben, das beschreibt, wie das Applikationsprogramm Freiheit gewinnen kann, d. h. einen Administratorstatus erhalten kann. Es beinhaltet das Schreiben einer speziellen OS Dienstaufrufroutine "trap 13 instruction", die in den S/88 OS-Kern eingefügt wird.
Dieser "Trap 13 Interrupt" tut nichts anderes, als das Programm "aufzurufen", das die Falle unmittelbar hinter der Fallen-Anweisung ausgibt. Da die Fallen-interrupt-Routine im Administratorzustand steht, wechselt das betreffende Programm in den Administratorzustand über. Um den Applikationsprogrammzustand wiederzugewinnen, modifiziert das Applikationsprogramm die Interrupt-Stapelrückkehradresse und kehrt vom Trap 13 "Aufruf" zum Trap 13 Interruptcode zurück, der unter Anwendung der modifizierten Interruptstapeladresse aus dem Interrupt aussteigt. Dieses Verfahren beinhaltet die Zugabe einer Interrupt-Routine zum S/88 OS.
Eine zweite Methode eliminiert die Modifizierung des betroffenen OS. Ein spezielles Register (nicht gezeigt) wird im BCU Stuerspeicher-Adressenraum definiert, das, sobald es vom Applikationsprogramm geschrieben wird, einen neuen BCU-Inter rupt bewirkt, der diese dritte oben angegebene Methode zum Implementieren von Interrupts anwendet. Die Applikations- Interrupt-Routine wird im BCU-Festwertspeicher (nicht dargestellt) resident gemacht und funktioniert genau so wie der Trap 13 Code. Die vorher beschriebene Gain Freedom Routine arbeitet genau so, mit dem Unterschied, daß sie in das spezielle BCU-Register schreibt anstatt eine Trap 13 Anweisung auszugeben.

Speicher stehlen ohne das S/88 OS zu modifizieren

Durch Verwenden dieser zweiten 'Freiheit-Gewinnen' Implementierung erfordert das "Speicherstehlen" keine Umordnung eines S/88 Quellcodes oder das Binden des S/88 OS-Kerns. Die Adresse im Kopf der Freiliste ist für das Applikationsprogramm zugänglich.

1. Einführung

Der hier folgende Abschnitt beschreibt kurz unter Bezugnahme auf Fig. 49 und 50 bestimmte Hardware-Register, Zwischenspeicher und Logik, die den Status und die Steuerung bestimmen und die Umgebung für Partnereinheiten wie z. B. 21, 23 in Fig. 7 und deren Synchronisierung einstellen.
Zusätzlich werden bestimmte Mikrocodefunktionen zur Durchführung der Initialisierung, Synchronisierung und Nachsynchronisierung von Einfach-Datenübertragungs- und Partnereinheiten beschrieben. Zunächst wird auf das System/88 (die bevorzugte Ausführungsform) aufmerksam gemacht, die im wesentlichen ohne Änderung gegenüber der Initialisierung und Synchronisierung der S/88 Prozessoreinheit funktioniert, sowohl in Einfach- als auch in Partnereinheits-Umgebung. Diese Betriebsmethode soll nur kurz beschrieben werden. Zusätzlich sind gewisse einschlägige Beschreibungen in US-Patent Nr. 4,453,215 gegeben, die hier wiederholt werden.
Eine Fehlerprüfung wird gleichzeitig mit dem Treiben des A Busses 42 und des B Busses 44 durch die beiden S/88 Prozessorelemente 60, 62 (Fig. 8) der Einheit 21 ausgeführt. Diese gleichzeitige Operation steht im Gegensatz zu den E/A-Einheiten im Prozessormodul 9, das eine Fehlerprüfung vor dem Treiben der Busstruktur implementiert. Die Prozessoreinheit 21 arbeitet auf diese Weise, weil die Taktung darin hinreichend bedeutsam ist, daß jede Verzögerung der Operation für den Systemdurchsatz unerwünscht ist. Ein von der Prüflogik während der Zeit, in der die Prozessoreinheit die Busstruktur treibt, erfaßter Fehler bewirkt, daß die Logik sowohl ein A- Bus-Fehlersignal als auch ein B-Bus-Fehlersignal während der nächsten Phase des Systemtakts auf den X-Bus 46 legt.
Während der gleichen Taktphase legt die gestörte zentrale Prozessoreinheit (z. B. 21) einen Wartungs-Interrupt der Ebene 1 auf den X-Bus 46, die der Partner-Zentralprozessoreinheit (z. B. 23) aufnimmt. Am Ende dieser Taktphase geht die gestörte Einheit off-line, ist nicht mehr in der Lage, weitere Signale auf die Busstruktur 30 zu legen, abgesehen von Antworten auf Fragen von der Partner-Zentraleinheit. Diese automatische Off-line-Operation stellt sicher, daß jeder Lese- oder Schreibzyklus durch eine Steuereinheit abgebrochen wird, unabhängig davon, ob er an die Speichereinheit 16, 18 oder an eine Peripherievorrichtung gerichtet ist, während dem ein Fehler entweder in den Adressen oder in den Daten auf dem A- Bus oder auf dem B-Bus erfaßt wurde. Ferner wird jeder Datentransfer während des gleichen Operationszyklus unter Verwendung ausschließlich der zentralen Prozessoreinheit wiederholt.
Genauer gesagt, der Komparator 12f vergleicht die Eingangsdaten, die der Prozessorabschnitt 12a vom A-Bus 42 erhält, mit den Eingangsdaten, die der Prozessorabschnitt 12b auf dem B-Bus 44 erhält. Er vergleicht ferner Funktion, Adresse und Datensignale (einschließlich Parität), die der Bearbeitungsabschnitt 12a auf den Sender/Empfänger legt, mit entsprechenden Signalen, die der Bearbeitungsabschnitt 12b erzeugt. Takt- und Steuersignale des Abschnitts 12a werden mit entsprechenden Signalen aus Abschnitt 12b verglichen. Dieser Vergleich der internen Steuersignale überprüft interne Operationen der Prozessorelemente 60, 62, und ermöglicht eine prompte Fehlererfassung und ist nützlich bei der Diagnose und Wartung der Prozessoreinheit.
Zu beliebiger Zeit, wenn sich ein oder mehrere entsprechende Eingangssignale zum Komparator 12f unterscheiden, produziert der Komparator ein Vergleichsfehler-Signal, das auf die Steuerstufe 86 angewandt wird. Der Fehler kann als Ergebnis eines Dateneingangsfehlers, eines Datenausgangsfehlers, eines Funktionsfehlers oder eines Adressenfehlers entstanden sein. Er kann auch entweder ein Zyklusfehler oder ein Steuerfehler aufgrund sich unterscheidender Takt- oder Steuersignale sein. Das Erfassen eines Fehlers durch die Paritätsprüfungsschaltkreise produziert ein Paritätsfehlersignal, das an die Steuerstufe 86 gelegt wird. Die Steuerstufe 86 antwortet auf das Vergleich-ungültig-Signal und das Parität-ungültig-Signal, durch Erzeugen eines Prozessor-Fehlersignals in der nächsten Taktphase (N + 1). Eine Ausnahme zu dieser Operation tritt auf, wenn das Vergleich-ungültig-Signal auf einen ungültigen Vergleich der Dateneigangssignale während einer Leseoperation zurückgeht. In diesem Fall produziert die Steuerstufe 86 das Prozessorfehlersignal nur dann, wenn mit der nächsten Taktphase kein Busfehlersignal produziert wird. Ein Busfehlersignal zeigt einen Fehlerzustand in der Busstruktur 30 an und identifiziert damit, daß der ungültige Vergleich der Eingangsdaten das Ergebnis eines Fehlers im A-Bus- oder im B- Bus-Teil der Busstruktur 30 war, und nicht entweder im Prozessorabschnitt 12a oder 12b aufgetreten ist.
Eine Funktion des Prozessor-Fehlersignals ist das Deaktivieren der Logikschaltkreise um so alle Operationen im Prozessorabschnitt 12 der Einheit 21 anzuhalten. Zusätzlich werden das A-Bus-Fehlersignal und das B-Bus-Fehlersignal auf den X- Bus 46 gelegt, um allen Einheiten im Modul 9 zu signalisieren, Informationen, die während der unmittelbar vorhergehenden Phase auf den Bus gelegt wurden, z. B. die CPU Busübertragung, zu ignorieren. Ein Interrupt-Signal auf Ebene 1 wird an den X-Bus 46 gelegt, um die Partnerprozessoreinheiten 23 zu informieren, daß irgendeine Einheit im Modul einen störungerzeugenden Fehler entdeckt hat.
Beim Anlaufen der Phase (N + 2) beendet die Stufe 86, immer noch als Reaktion auf das Fehlersignal, das Ansteuern des Busmasterstatus. Diese Aktion wird begleitet von der Beendigung des Busfehlersignals. Wenn der Prozessorabschnitt 12 den Masterzustand abschaltet, schaltet er auch alle Bustreiber in den Sender/Empfängern 12e aus. Die S/370 Sender/Empfänger 13 Treiber werden auch über die gemeinsame Steuerung 75 ausgeschaltet, wenn die der Sender/Empfänger 12e ausgeschaltet werden. Auf ähnliche Weise, wenn ein Prozessorfehlersignal von der Steuerstufe 75 der Einheit 21 erzeugt wird, werden auch die Sender/Empfänger 12e über die Steuerstufe 86 und auch die Sender/Empfänger 13 ausgeschaltet.
So können also die Prozessoreinheiten 21, 23 die Busstruktur nur dann treiben, wenn sie im Masterzustand steht, wie verlangt ist, um das Busaktivierungssignal zu erzeugen, das an die Treiber gelegt wird. Das Prozessorfehlersignal schaltet prompt, das heißt am Ende der nächsten Taktphase, den Masterstatus ab. Für den Fall, daß der Prozessorabschnitt 12 der Einheit 21 ein Prozessorfehlersignal produziert, fährt der S/88 Prozessorabschnitt der Partnereinheit 23 mit dem Betrieb fort und arbeitet im wesentlichen ohne Unterbrechung. Wenn das Prozessorfehlersignal während einer Schreiboperation auf tritt, wiederholt die Partnerprozessoreinheit 23 den Datentransfer. Wenn der Prozessorfehler während einer Leseoperation auftritt, liest die Partnereinheit die wiederholten Daten ein, die der Speicher für eine nachfolgende Taktphase auf die Busstruktur legt.
Ferner reagiert die Partnerprozessoreinheit 23 auf den Interrupt der Ebene 1, der ein Interrupt niederer Priorität ist, um eine Diagnoseroutine durchzuführen. Falls die Ursache des Prozessorfehlers offensichtlich ein Übergangsphänomen ist, d. h., die Diagnoseroutine identifiziert oder findet keinen gestörten oder fehlerhaften Zustand, kann die Prozessoreinheit 21 ohne Wartung wieder in betriebsbereiten Zustand versetzt werden. In einer bevorzugten Ausführungsform wird das Auftreten einer vorübergehenden Störung aufgezeichnet, und wenn sich das willkürlich-einstellbar oft wiederholt, wird die Prozessoreinheit ohne weitere Diagnose elektrisch aus dem Dienst oder aus dem Betrieb genommen.
Jeder Prozessorabschnitt 12 der Einheiten 21, 23 beinhaltet logische Schaltkreise, in der Regel im Prozessorstatus und auf Steuerstufe 86, um die zwei Partnereinheiten in Schrittsynchronverriegelung zu bringen. Der Abschnitt 12 erreicht die Schrittsynchronverriegelung mit dem Übergang zum Masterstatus. Jeder Abschnitt 12 muß im Masterzustand stehen, damit er Treibersignale auf die Busstruktur legen kann. Die Initialisierungssequenz, die in jedem PROM 181 gespeichert ist, enthält in der Regel Anweisungen zum Synchronisieren der Partnerabschnitte und um sicherzustellen, daß kein Prozessorabschnitt anfänglich im Masterzustand ist, d. h., beim Einschalten.
Die Prozessorsektionen 12 der Einheiten 21, 23 sind anfänglich in der Initialisierungssequenz nicht synchron und eine Einheit erreicht den Master-Zustand während eines Multi phasen-Zyklus früher als die andere. Diejenige Einheit, die den Masterstatus erreicht, steuert die weitere Initialisierungsoperation der anderen Einheit, um sie zu einem vorgewählten Zeitpunkt in den Masterzustand zu bringen.
Wenn die Prozessorsektion 12 der Einheit 21 initialisiert wird, negiert sie ein internes Error Check Signal und verhindert somit, daß ein Parity Invalid Signal oder ein Compare Invalid Signal ein Processor Halt Signal generiert. Statt dessen führt die Sektion 12 eine in der Regel im PROM 181 gespeicherte Testroutine durch, die alle Zustände ausführt, die ein Processor Error Signal produzieren können. Beim Erzeugen jedes möglichen Fehlerzustands prüft die Prozessorsektion, ob wirklich das entsprechende Fehlermeldesignal erzeugt wird. Das Fehlen des Error Check Signals verhindert somit, daß die Prozessoreinheit den Masterzustand erreicht, mit dem Ergebnis, daß während dieser Logikausführungsroutine erzeugte Fehler die Prozessoreinheit nicht stoppen können und nicht an die Busstruktur 30 berichtet werden. Die Testroutine im PROM 181 steuert das Error Check Signal an und bewirkt, daß der Prozessor erst nach erfolgreichem Abschluß dieser Prüfroutine den Master-Zustand annehmen kann.
Die S/370 Prozessoreinheiten (in der bevorzugten Ausführungsform) haben in der Regel Hardware, die zur Initialisierung und für Dienstleistungsprozessor-Funktionen über einen "Hintertür"-Zugriff auf die verschiedenen Komponenten und Logik in jedem Chip eingerichtet ist. Da diese wohlbekannt sind, werden sie hier nur kurz beschrieben.
Auf ähnliche Weise sind auch Programmroutinen für Selbsttests und Initialisierung wohlbekannt und brauchen nicht näher beschrieben zu werden. Was im vorliegenden Abschnitt besonders betont werden soll, ist der Mechanismus, durch den der typische S/370 Selbsttest und die Initialisierung über den S/88 erreicht wird, ohne daß das S/370 oder das S/88 Betriebssystem diese Änderung merken. Die Selbsttest- und -Initialisierungsroutine (STIR) für den S/370 stehen in der bevorzugten Auführungsform im PROM 181 (Fig. 19C), zusammen mit Routinen zur Synchronisierung der S/370 Prozessorelemente in gepaarten Einheiten. Das S/88 arbeitet somit als S/370 Dienstleistungsprozessor. Die speicherabgebildeten E/A-Zuordnungen des S/88 Code im PROM 181 sind vorgesehen für den Fall, daß bestimmte S/88 Status- oder sonstige Registerinhalte zur Implementierung des S/370 Code erforderlich sind.
Die Art und Weise, wie dieser Code an die Synchronisierung herangeht, ist das Übertragen einer speicherabgebildeten Kopie des Registers, das in einer primären (d. i. Master) Partnerprozessoreinheit, wie 21 (eine, die ordentlich arbeitet) eingerichtet ist, auf das Register, das in einer sekundären (d. i. Slave) Partnerprozessoreinheit, wie 23 (die noch nicht ordentlich arbeitet) eingerichtet ist.
Bevor nun der Ankopplungspfad für den Synchronisierungsmechanismus vom S/88 zum S/370 in Einzelheiten beschrieben wird, soll eine kurze Übersicht über die Struktur und Umgebung des Moduls 9 der Fig. 7 gegeben werden. Die Merkmale des Betriebssystems S/88, wie Fehlertoleranz und Einzelsystemabbildung, werden sowohl für die S/88- als auch für die S/370-Struktur beibehalten. Das Modul 9 besteht aus einem oder mehreren Einzel-S/370-Prozessoreinheiten wie 21, oder Paaren von Partner-S370-Prozessoreinheiten wie 21, 23. S/88 Einzel- oder Partnereinheiten wie 12 bzw. 12, 14 können im Modul zur Ausführung von nur S/88 Programmen enthalten sein.
Jede S/370 Prozessoreinheit beinhaltet ein Paar S/370 Prozessorelemente wie 85, 87, und ein Paar S/88 Prozessorelemente wie 62, 64, wie in Fig. 7 dargestellt wird; diese Prozessorelement-Paare werden schrittsynchronverriegelt als einzige lo gische Prozessoreinheit betrieben. Die Partnereinheiten bilden eine redundante Konstruktion, die miteinander schrittsynchronverriegelt betrieben wird, um eine voll fehlertolerante, selbstkontrollierende logische Prozessoreinheit zu bilden.
Jedes der S/370 Prozessorelemente 85, 87 eines Paars ist teilweise ein S/370 Chip-Satz wie 150 (Fig. 11). Die S/370 Chip-Sätze und die ihnen zugeordnete Hardware sind auf ein Board im S/88 Stil, wie 101 (Fig. 9A), montiert zum Ankoppeln an die S/88 Busstruktur 30; und sie sind über die Schnittstellenlogikschaltungen 89 und 91 (Fig. 8) mit den entsprechenden S/88 Prozessorelementen gekoppelt. Im vorliegenden Abschnitt werden die S/370 Chipsatzpaare und die ihnen zugeordnete Hardware in einer Prozessoreinheit, wie 21, als S/370-Einheit bezeichnet; und ihre entsprechenden S/88 Prozessorelemente, wie 60, 62, und die ihnen zugeordnete Hardware werden als S/88 Einheit bezeichnet. Die S/370 Einheiten führen S/370 Applikationsprogramme durch und rufen die S/88 Einheiten auf, im Bedarfsfall S/370 E/A-Operationen auszuführen unter Verwendung der S/88 E/A-Vorrichtungen und -programme, so daß weder das S/88 Betriebssystem noch das S/370 Betriebssystem etwas vom anderen merkt.

2. FEHLERTOLERANTE HARDWARE-SYNCHRONISATION

Eines der einzigartigen und signifikanten Merkmale der S/88- S/370 Prozessoreinheiten ist die selbstbestimmte Synchronisierung einer Prozessoreinheit, wie 21, durch einen augenblicklich arbeitenden Prozessor-Partner 23. Die S/88 Einheit jeder Gesamteinheit hat die Fähigkeit und die Verantwortung für die Synchronisierung eines neuen oder fehlerproduzierenden Partners. Wenn eine S/88 Einheit einer Gesamteinheit diese Verantwortung übernimmt, wird sie als "Master" bezeichnet. Ihr Partner, der die Synchronisierung durchmacht, wird als "Slave" bezeichnet.
Die S/88 Hardware/Firmware-Struktur bestimmt, wann die Synchronisierung erforderlich ist und wer wen synchronisiert. Die zusammengeschaltete S/88-S/370 Hardware/Firmware benutzt die gleiche Intelligenz, um der Anleitung des S/88 bei Synchronisierungsentscheidungen zu folgen. D. h. jedesmal wenn das S/88 entscheidet, daß eine S/88-(Slave)-Einheit einer Synchronisierung mit ihrem Partner (Master) bedarf, wird diese Synchronisierung bis zu einem geeigneten Punkt zugelassen, nachdem die S/88 Slave Einheit "angelassen" wurde; dann wird die Ausführung auf die entsprechende S/370-Einheit umgeleitet. Die S/370-Einheiten werden dadurch synchronisiert, daß die S/88 PEs den Code vom PROM 181 ausführen, um den S/370- Masterzustand abzuziehen und diesen Zustand in den beiden S/370 Partnern wieder einzurichten.
Jeder der beiden Partner des Paares kann die Rolle des Master oder des Slave bei der Synchronisierung von Prozessoreinheiten übernehmen, ob die Anforderung nun durch Einschalten, das Auftreten eines neuen Partners oder die Behebung eines Fehlerzustands, der bewirkt hat, daß die beiden vorhanden Partner außer Tritt gekommen sind, aufgerufen wird (jeder Fall erzwingt einen Wartungs-Interrupt). In jedem Fall erkennt die S/88 Slave-Einheit ihren Status und wird von der S/88 Mastereinheit zur Synchronisierung abhängig.
Die S/88 Master- und Slave-Einheiten übernehmen ihre entsprechenden Rollen als Ergebnis ihrer entsprechenden Zustände zum Zeitpunkt, an dem der Wartungs-Interrupt auftritt. Die S/88-Einheiten aller Prozessorgesamteinheiten finden und verarbeiten den Interrupt, wobei jede annimmt, daß sie ein Slave ist, bis ein voreingestellter Master eingerichtet ist. Dieser Master läßt dann jeden haltenden Slave in Schrittsynchronverriegelung an, wobei jeder (bei Rückkehr vom Interrupt) die voreingestellte Umgebung des Masters wiederannimmt.
Ebenso koppeln die S/88 Einheiten die Prozessoren vom Rest der Logik ab, benutzen diese Prozessoren zum Emulieren der S/370 SP-Funktion, um einen identischen vorgegebenen Zustand innerhalb des S/370 Partner-Paares herzustellen, nehmen dann wieder die normale Ausführungsumgebung auf und bewirken, daß das S/370 Partner-Paar die Ausführung schrittsynchronverriegelt beginnt.
Die eine Situation, die keiner Synchronisierung bedarf, ist:
Eine vereinzelte Prozessoreinheit wird eingeschaltet, d. h. eine Einzeleinheit wie 21;
Die Situationen, die der Synchronisierung bedürfen, sind:
Duplex-Prozessoreinheiten (z. B. 21, 23) werden eingeschaltet;
Eine Einheit 21 wird eingefügt während ihr Partner 23 normal arbeitet; und
Eine Prozessoreinheit, wie 21, erfaßt einen Vergleichsfehler in ihrem Partner 23 und versucht Behebung des Fehlers.
Die S/88 Einheit verfügt über geeignete Hardwareausrüstung zum Durchführen der Synchronisierung. Der S/370 Prozessorabschnitt hat genügend Hardware und Softwareunterstützung, die es ermöglicht, eine Slave-Einheit zu auf genau den gleichen Zustand wie die Master-Einheit zu initialisieren. Das beinhaltet solche Merkmale wie Lesen/Schreiben in Statusregister, lesbare Modus-Register, löschbare Cache-Speicher, unterbrechungsfähige Taktgeber und Zählringe usw.
Wenn eine normal operierende S/370 Einheit in der Gesamteinheit 21 in SYNC mit ihrer entsprechenden S/370 Einheit in einer gepaarten Gesamteinheit 23 gebracht werden soll, ist es erforderlich, die gepaarte S/370 Einheit in den gleichen Zustand zu bringen wie die normal operierende Einheit. Dieser Prozeß wird in der bevorzugten Ausführungsform vereinfacht durch Senden einer Meldung Queue Select Up von den S/88 Prozessoren 60, 62 (unter Steuerung des S/370 Initialisierungs- und Synchronisierungs-Mikrocode im PROM 181) zu den S/370 Prozessoren 85, 87. Diese Meldung stoppt die Anwenderapplikationen, so daß sie während der Synchronisierungszeit keine weiteren Dienstleistungs-Requests über das Betriebsprogramm an die BCUs, wie 156, senden können. Sie ermöglicht auch den Abschluß der Ausführung aller nichtabgeschlossenen E/A-Operationen.
Das bringt die normal operierende S/370 Einheiten in einen Zustand, der zur Anwendung durch beide S/370 Einheiten nach dem "Anlaufen" in den Speicher 162 kopiert wird. Zu diesem Zeitpunkt werden alle Register, Zähler, Zeiger und Puffer (Kontext) im S/370 Prozessor, S/370 Cache, DLAT, und S/370 Busadapter in einem geordneten Stapel in den Speicher (162) kopiert. Wenn der Sync-Prozeß anläuft, wird in allen vier physikalischen Prozessoren der S/370 Kontext wiederhergestellt durch Laden dieses Kontexts vom gemeinsamen Stapel in alle vier Prozessoren. Beide Prozessoren werden für ihre Register, Zähler und Puffer mit identischen Daten geladen.
Dann beginnt die Programmausführung schrittsynchronverriegelt d.i. in voller Synchronisation.
Die S/370 Prozessoreinheit sieht zwei Methoden zum Zugriff auf die verschiedenen Register und Caches zur Synchronisierung vor. Die eine ist die normale, Anwender-programmierte Lese/Schreib-Methode mit Benutzung der Register 560, 561 (Fig. 49), die den örtlichen BCU-Datenbus 223 an die Kanäle 0, 1 des Adapters 154 koppelt. Die andere ist ein serielles Integrated Support Facility (ISF)/Universal Support Interface (USI) 540, 541 "Hintertür"-Verfahren. Durch Emulieren des seriellen Schnittstellen/Protokolls (ISF/USI) des S/370 Chipsatz-Dienstleistungsprozessors kann der Synchronisierungsmechanismus der S/88 Einheit auf jede beliebige, den S/370 Einheiten zugeordnete Vorrichtung zugreifen. Wenn die Synchronisierung eines oder mehrerer S/370 Einheiten verlangt ist, werden beide Methoden eingesetzt. Der normale Pfad wird benutzt, soweit er existiert, sonst wird der USI Pfad benutzt.
Hier muß darauf hingewiesen werden, daß dieser Teil des Synchronisierungs- und Initialisierungsprozesses (d. i. für S/370 Einheiten) für das S/88 Betriebssystem transparent sein muß, das das Vorkommen bzw. die Verbindung mit der S/370 Einheit nicht merkt. Diese Transparenz wird erzielt auf eine Weise, die im allgemeinen der oben bereits im Hinblick auf S/370 E/A-Operationen beschriebenen ähnlich ist. D. h., die Adressendecodierlogik 280, die im Hinblick auf Fig. 20 beschrieben wurde, erfaßt eine Adresse 007EXXXX jedesmal wenn Daten zwischen dem S/88 Prozessor 62 und der Logik der Fig. 49 übertragen werden sollen. Wenn diese Adresse von der Logik 280 dekodiert wird, koppelt sie den S/88 Prozessorbus 161A, 161D an die örtliche BCU Adresse und Datenbusse 247, 223 über die Schaltkreise 217, 218 wie oben beschrieben. Die Registeradressen-Decodierlogik 562 decodiert die niederwertigen Bits der Adressen auf dem Bus 247, um eine der Logikschaltungen 549, 550 oder Register 560, 561 zum Datentransfer mit dem Prozessor 62 anzuwählen.
Zusätzlich werden Interrupts auf den Leitungen 562, 563 über die ODER-Schaltung 292a zu der S/88 Interrupt-Logik 212 in Fig. 20 gelenkt. Das Interrupt-Anforderungssignal wird auf Leitung 562 aktiviert, wenn Daten in der Logik 549 über einen der S/370 Chips zur Übertragung zum Prozessor 62 eingegangen sind. Ein Interrupt-Request-Signal auf der Leitung 563 unter richtet den Prozessor 62 über den Abschluß der Datenübertragung von der Logik 550 zu einem S/370 Chip. Ein Interrupt- Request auf Leitung 562 unterrichtet den Prozessor 62, daß von einem S/370 Chip Daten zur Übertragung auf Prozessoren 62 bei der Logik 549 eingegangen sind. Die Interrupt-Requests werden auf den Leitungen 562 und 563 gehalten bis ein IACK Signal auf den Leitungen 258d bzw. 258c erscheint. Die Vektornummern für diese Interrupts werden von der Logik 564, 565 abgeleitet, wenn sie von IACK Signalen 258d und 258e in Fig. 20 entsprechend aktiviert werden. Die Vektornummern werden vom Prozessorelement 62 benutzt, um auf die entsprechenden Interrupt-Steuerprogrammroutinen zuzugreifen.
Die S/370 integrierte Unterstützungseinrichtung (ISF - Integrated Support Facility) 540 in Fig. 49 stellt einen "Hintertür"-Eingang zur Logik auf dem Chip-Satz 150 dar. Die ISF besteht aus einem 5-Leitungs-Unterstützungsbus 541, der die Einheits-Unterstützungs-Schnittstellen (USI - Unit Support Interface), die auf den Chips 85 und 151-154 integriert sind, verbindet. Ein Teil der USI 542 auf Chip 85 wird in Fig. 49 gezeigt.
Der Unterstützungsbus 541 ist eine serielle Schnittstelle mit den folgenden fünf Leitungen:
BIT OUT (Daten auf Chip-Satz) Leitung 543
BIT IN (Daten vom Chip-Satz) Leitung 544
ADDRESS MODE (Steuer)-Leitung 545
SHIFT GATE (Steuer)-Leitung 546
SET PULSE (Steuer)-Leitung 547
Die ADDR_MODE Leitung 545 signalisiert den seriellen Transfer (shift) entweder von Adressenbits (hoch) oder Datenbits (tief) auf den BIT OUT/BIT IN Leitungen 543, 544. Die BIT OUT und BIT IN Leitungen 543, 544 sind die Zusammenschaltung zwischen den Schieberegistern wie 548 in einem Chip und den externen Schieberegistern in der Logik 549, 550. Die zwischen einem internen Register 548 und einem der zwei externen Register 549, 550 verschobenen Bits wird durch die Anzahl der Impulse bestimmt, die auf die Verschiebungsgatterleitung 546 gelegt werden.
SET PULSE wird benutzt zum Synchronisieren der Chip-internen Aktivitäten auf der Grundlage der Adresse oder des Datenmusters, das eben in den Chip geschoben wurde. SET PULSE wird nach Abschluß des Verschiebens aktiviert zum Signalisieren der Chip-seitigen Verfügbarkeit der Informationen, d.i. in Register 548. Das heißt, daß von diesem Augenblick an Aktivitäten auf der Grundlage der Informationen anlaufen können.
Das nachfolgende Beispiel illustriert die Operation. Eine Start-Funktion wird einem spezifischen Adressenmuster zugeordnet. Diese Adresse wird in die Register, wie 548, auf jedem Chip geschoben. Wenn alle Adressenbits übertragen sind, entdeckt der Adressendecodierer 551 in einem der Chips seine Adresse. Der SET PULSE folgt dem Adressentransfer. Der Adressendecodierer und der SET PULSE bilden einen Chip-internen Startimpuls am Ausgang des Gatters 552.
Der Chip-spezifische Teil einer USI enthält Steuerungen und Datenketten, die von der spezifischen Chip-Konstruktion abgeleitet werden. Um den augenblicklichen Status der Elementspeicherung, die nicht von einer Schiebeoperation betroffen sind, beizubehalten, müssen die funktionellen Takte vor der Einleitung von USI-Aktivitäten gestoppt werden. USI-Zugriffe, die das Anhalten der Takte als Voraussetzung fordern, werden als 'statisch' bezeichnet. Dynamische Zugriffe oder Funktio nen sind solche Operationen, die ausgeführt werden können, während die Chips im Betrieb sind.
SET PULSE wird benutzt zum Synchronisieren von Funktionen auf die Chip-interne Taktung. Die aus dem Adressenmuster oder Datenmuster im SERDES Register decodierten Funktionen, die zusätzlich von der ADDR MODE Leitung (Adressen- oder Daten- Modus) eingespeist werden, sind:
Set chip modus into SERDES
Set mode register into SERDES
Load mode register from SERDES
Set Support transfer Request latch (SPR)
Reset Processor Controlled Request latch (PCR)
Zusätzliche dynamische Funktionen nach Bedarf zum Unterstützen der einzelnen Chips.
Der serielle Fünfdraht-Bus 541 des ISF, der einen Zugriff }ber die Hintert}r' auf die verschiedenen adressierbaren Einheiten innerhalb des S/370 Chipsatzes 150 bietet, ist an die Unit Support Interface (USI) jedes Chips gekoppelt, z. B. an USI 542 des Chips 85. Die USI 542 liefert ein 8-Bit Adressenregister 566 und einen 8-Bit Serializer/Deserializer (SERDES) 548. Das USI Adressenregister 566 erhält die Adresse des Chips und die Adresse der Zieleinheit innerhalb des Chips während der SERDES 548 der wahre Sende/Empfangsmechanismus ist. Die USI liefert auch die Synchronisierungslogik für den shift-in/shift-out-Mechanismus.
Jedem Chip im S/370 Chipsatz 150 wird eine 4-Bit (höherwertig) ISF/USI Adresse z. B. PE85, Cache-Controller 153, Takt 152, Adapter 154, Fließkomma-Coprozessor 151 und STCI 155 zu geordnet, die entsprechend die Hexadezimalwerte 2, 4, 6, 8 und A und B enthalten. Die niederwertigen 4 Bits der ISF/USI Adresse definieren die interne Chipeinheit (z. B. Register, Funktion oder Kette), die von den 4 niederwertigen Bits adressiert werden.
Das Kommunikationsschema besteht aus Shift Chains (auch als Funktionsketten bezeichnet), die ihrerseits aus Feldern bestehen, die Befehl, Quellchip, Zielchip, Daten und Zieleinheit innerhalb der Chips identifizieren. Die Shiftketten sind wie folgt:
Bits 0-7 - Funktion/Befehl
8-11 - Quelleinheit (steuernd)
12-15 - Zieleinheit (abgetastet/gesteuert)
16-23 - Meldung/Daten
24-27 - Gesteuertes (geschriebenes) Register
28-31 - Abgetastetes (gelesenes) Register
Diese Funktionsketten werden als Shift Chains bezeichnet wegen der seriellen Natur der ISF/USI und der Tatsache, daß die Ketten in/aus die/der Logik 549, 550 und die SERDES Register, wie 548, 'geshiftet' werden müssen.
Das Befehlsfeld der Funktionskette kann einen Schreib/Steuerbefehl (E61) oder einen Lese/Abtastbefehl (F61) enthalten. Ein Beispiel für eine Funktionskette ist wie folgt:
E602XX10 = Schreibe in Modus-Register des Prozessors 85
dabei ist E6 = Befehl = Schreiben
0 = Quelladresse - PE62 für Testen
2 = Ziel - PE85
XX = Meldung (Daten)
1 = Gesteuertes Register (Modus-Register)
0 = Abtastregister (keines weil Befehl "Schreiben" ist)
Die Lösungen zum Einleiten der Synchronisation in nachfolgender Beschreibung benutzen den S/88 Programmcode, der im PROM 181 gespeichert ist. Der Code legt Bestimmungen fest, die jeder der obigen vier Situationen zugeordnet sind, und setzt die Flags entsprechend. Die Synchronisationsroutinen benutzen dann diese Flags, um den Codeleitweg zur Durchführung der geeigneten Synchronisierung/Initialisierung zu steuern. Ein paar Beispiele sind wie folgt:
Festlegen, ob der Speicher auf einem bestimmten S/88 Board von einem Stromausfall betroffen war und von seinem Partner neu initialisiert werden sollte.
Festlegen, ob ein bestimmtes S/88 Board die Rolle der Vorgegebenen Master-Prozessor-Einheit (DMPU - Defaulted Master Processing Unit) übernehmen sollte.
Die folgenden Unterabschnitte 3-6 zeigen zwei unterschiedliche Implementierungen des Synchronisierungsmechanismus. Einer ist Hardware-unterstützt und ermöglicht einen schnelleren 'Zeit bis Bereit' Prozeß. Natürlich erfordert er zusätzliche Steuerschaltungseinheiten, wenigstens in der S/370-Einheit, und kann über die definierte Fähigkeit hinaus durch physikalisches Ansteuern bestimmter S/88 Steuerschaltungen auf die S/370-'Schnittstelle' erhöht werden. Diese 'Schnittstelle' ist in Wahrheit das 'parasitäre Anhängsel' S/370-Schaltung an die S/88 Schaltung.
Die andere hier definierte Implementierung betrifft nur den Mikrocode, sie ermöglicht das Handhaben der S/370 Synchronisierung durch die S/88 Prozessoreinheiten bei der Emulation eines S/370 Dienstprozessors. Diese Technik kann benutzt werden, wo Leistung und 'Zeit bis Bereit' nicht kritisch sind.

3. Eine Simplex-Prozessor-Einheit 21 wird hochgefahren (Hardware-Implementierung)

Diese Situation kann durch jeden der zwei Zustände bewirkt werden:
1. Die Einheit geht online bei Einschalten/Booten
2. Die Einheit geht online bei Beendigung eines Stromausfalls.
Für beide Zustände ist der Codezugriffspfad der gleiche:
Die S/88 Einheit der Gesamteinheit 21 führt einen Teil ihres Selbsttests und ihrer Initialisierungsroutine (STIR) durch und versucht dann zu bestimmen, ob der Inhalt ihres zugeordneten Speichers 16 beschädigt wurde (Stromausfall) oder nicht. Wenn ja, kehrt sie zum normalen Einschalt-STIR-Pfad zurück. Wenn nicht, versucht sie herauszufinden, ob sie einen Partner oder eine co-residente Prozessoreinheit hat, die die DMPU sein könnte. Wenn sie keine findet, übernimmt sie die DMPU-Aufgaben und versucht, andere Prozessoreinheiten zu synchronisieren.
Die S/370 Einheit der Gesamteinheit 21 folgt nur der Anleitung der S/88 Einheit. Das wird vom S/88 Prozessor 62 bewirkt, der den Code ausführt, der im S/88 PROM 181 resident ist, unter Abschließen des Selbsttests, dann Bestimmen, ob es sich um einen Einschaltvorgang oder um eine Beendigung eines Stromausfalls handelt. Wenn es ein Einschaltvorgang ist, wird die normale Initialisierung fortgesetzt; dann, wenn wir an nehmen, daß sie die DMPU ist, versucht sie, ein SYNC-Signal auszugeben. Das Signal wird von der S/370 Logik in einer Falle gefangen, die den S/88 Prozessor 62 zu einem Interrupt auf Ebene 6 zwingt. Der Interrupt 6 wird auf den S/370 Synchronisierungs-Mikrocode im S/88 PROM 181 vektorisiert (Fig. 19A), (der auf den S/88 Adreßraum abgebildet ist).
Inzwischen hat, vom Power-On/Boot, das S/370 PE 85 seine eigene STIR ausgeführt und dann die Ausführung an diesem SYNC- Punkt unterbrochen. Während dieser Zeit hat sich der S/370 Taktgeber 152 selbst initialisiert. Die S/88 Interruptservice-Subroutine (ISS) auf Ebene 6 (d. i. der S/370 Synchronisations-Mikrocode) benutzt die USF/USI-Schnittstelle der Fig. 44 um den S/370 Dienstprozessor zu emulieren. Dieser SP- Emulator wird Funktionsketten ausgeben, um die IML-Funktion des S/370 Steuerspeichers 171 aufzurufen, obwohl kein wirklicher Code-Transfer stattfindet, (der Mikrocode ist im S/88 PROM 181). Der nächste Schritt der EML-Emulation ist das Senden des SYNC an die S/370 Einheit (Prozessoren 85 und 87), was bewirkt, daß die Prozessoreinheit 21 in die Bearbeitung aussteigt. Der letzte Schritt im ISS ist die Rückkehr-vom- Interrupt, die bewirkt, daß die Prozessoreinheit die Ausführung des IPL-gebildeten Zustands beginnt.
Als Teil der Ausführung des 'module_start_up.cm' durch die S/88 Prozessoreinheit wird eine emulierte Dienstprozessor- 'IPL Button Pushed'-Funktionskette an die S/370 Prozessoreinheit geschickt, um die IPL Funktion 'Laden des S/370 Hauptspeichers' von der Platte durchzuführen. Der letzte Schritt des IPL ist dann, die Steuerung an die Adresse zu übergeben, die Ort 0 spezifiziert ist.

B. Nur-Mikrocode Implementierung

Die S/88 Einheit der Gesamteinheit 21 führt ihre Selbsttest- und Initialisierungsroutine (STIR) durch und bestimmt dann, ob es ein Einschalthochfahrvorgang (IPO - Initial Power On) oder ein Stromausfall-Fehlerbeseitigungsvorgang (PFR - Power Fail Recovery) ist. Wenn es sich um einen IPO handelt, bestimmt der Code, daß die Einheit 21 eine Simplex-Einheit ist und geht zum Laden des Betriebssystems und Ausführen seiner 'Start-up' Routine über.
Wenn es sich um einen PFR handelt, bestimmt der Code, ob die Integrität seines zugeordneten Speichers beeinträchtigt ist oder nicht. Wenn ja, fährt der Code fort, so als ob es sich um einen IPO handelte. Wenn der Speicherinhalt intakt befunden wird, fährt der PFR-Code mit den normalen Wiederanlaufaufgaben fort.
In jedem der beiden obigen Fälle wird die Synchronisationsfunktion eine 'Dummy'-Operation, weil es keinen zugeordneten Partner gibt, der synchronisiert werden müßte.

4. Duplex-Prozessoreinheiten 21, 23 werden eingeschaltet - Hardware-Implementierung

Diese Situation kann von jedem der beiden Zustände verursacht werden:
1. Die Einheiten gehen online bei Einschalten/Booten.
2. Die Einheiten gehen online bei Beendigung eines Stromausfalls.
Die S/88 Einheit der einzelnen Prozessoreinheiten 21, 23 führt einen Teil ihrer Selbsttest- und Initialisierungsroutine (STIR) durch und versucht dann zu bestimmen, ob der Inhalt ihres zugeordneten Speichers 16 beeinträchtigt wurde (bei Stromausfall) oder nicht. Wenn ja, geht sie auf den nor malen Einschalt-STIR-Pfad zurück. Wenn nein, versucht sie zu bestimmen, ob sie eine Partner- oder co-residente Prozessoreinheit hat, die die DMPU sein kann, oder ob sie die DMPU ist oder nicht. Wenn ja, übernimmt sie die DMPU-Verantwortung und versucht, andere Prozessoreinheiten zu synchronisieren. Wenn sie nicht die DMPU ist, geht sie auf den Sync-Punkt über und erwartet SYNC.
Jede S/370 Einheit folgt lediglich der Führung der S/88 Einheit. Die S/88 Einheit schließt durch Ausführung des im PROM 181 residenten Codes den normalen Selbsttest ab und bestimmt dann, ob es sich um einen Einschaltvorgang oder eine Stromausfall-Datenwiederherstellung handelt. Wenn es ein Einschaltvorgang ist, fährt sie mit der normalen Initialisierung fort und geht dann auf den Sync-Punkt über. Wenn es sich um eine Datenwiederherstellung nach Stromausfall handelt, wird der Cache geprüft, ob er gültig ist oder nicht. Wenn ja, kann er den Speicher seines Partners aufstandbringen müssen, sollte der Cache dieses Partners ungültig sein. Wenn ihr eigener Cache ungültig ist, hängt es von ihrem Partner ab, daß er mit gültigen Cache-Daten aufstandgebracht wird. Wenn keiner der Partner einen gültigen Speicher zusichern kann, müssen sie, als Paar, mit der normalen Einschalt-Initialisierung weitermachen. Wenn die S/88 Einheiten des Prozessoreinheitspaars sich dem Sync-Punkt nähern, bestimmt jede S/88 Einheitsgruppe, ob sie die DMPU-Verantwortung übernehmen muß. Wenn sie findet, daß sie die DMPU ist, versucht sie, den SYNC auszugeben.
Das Sync-Signal wird von der S/370 Logik in der Falle gefangen und erzwingt einen Interrupt auf Ebene 6 für die S/88 Einheit. Der Interrupt wird zum S/370 Synchronisierungs- Mikrocode im PROM 181 (der auf den S/88 Adreßraum abgebildet ist) vektoriert. Inzwischen hat die S/370 Einheit (z. B. die Prozessorelemente 85, 87) vom Power-On/Boot, ihre eigene STIR durchgeführt, dann die Ausführung an ihrem Sync-Punkt unterbrochen. Wenn es sich um eine Datenwiederherstellung nach Stromausfall handelt, durchläuft die S/370 Einheit einen Prozeß, der ähnlich dem Prozeß der S/88 Einheitsgruppe ist, zum Bestimmen, wie weit sie in der Initialisierungsroutine zurückgehen muß, um die Speicherintegrität und Synchronisierung zu sichern. Inzwischen hat sich der S/370 Taktgeber 152 selbst initialisiert.
Jetzt folgt eine kurze Beschreibung des bevorzugten Mechanismus zum Einfangen des S/88 SYNC-Impulses durch die S/370 Prozessoren unter Bezugnahme auf die Fig. 20, 49, 50.
Die S/88 Prozessoren erreichen die Synchronisierung durch eines der S/88 Prozessorpaare der Einheit 23, die ein SYNC OUT Signal auf die Leitung 570, Fig. 50, legen. Wenn die Partnereinheit initialisiert und selbstgetestet ist und bestimmt hat, daß sie nicht BROKEN wird, legt sie ein Signal auf die BROKEN-Leitung 571, das durch Schaltung 572 invertiert wird, um das SYNC OUT Signal durch das AND INVERT Gatter 573 zu schleusen.
Im Originalsystem 88 (z. B. Modul 10) wurde das SYNC Signal auf die SYNC IN Leitung 580 des S/88 Treiberprozessors (d) einer Einheit 14 über Leitung 577 und Inverter 574 gelegt. Es wird auch auf die SYNC IN Leitung 575 zum Einleiten des schrittsynchronverriegelten "Anlaufs" aller vier S/88 Prozessoren der Einheiten 12, 14 gelegt.
In den verbesserten S/370 - S/88 Einheiten, wie 21, 23, wird der Ausgang 577 der Schaltung 573 von den SYNC IN Leitungen 580 und 575 abgeschaltet, damit das Anlaufen der S/88 Prozessoren verhindert wird. Statt dessen wird er über die Leitung 581 angeschlossen, um in der BCU 156 der Partnereinheit 21, Fig. 49, ein Flipflop 582 einzurichten. Er setzt auch ein entsprechendes Flipflop in die gepaarte BCU (nicht dargestellt) in der Einheit 21. Die nachfolgende Beschreibung richtet sich nur an eine S/370 und zugeordnete Hardware in Einheit 21, dabei muß berücksichtigt werden, daß beide S/370 Einheiten auf gleiche Weise arbeiten.
Das Flipflop 582 legt über die Leitung 583, ODER-Schaltungen 292a und 292 (siehe Fig. 20), Interrupt-Logik 293 und die Leitungen IPO-2 ein Interruptsignal der Ebene 6 auf den S/88 Prozessor. Diese Aktion wird als "Einfangen" des S/88 SYNC- Signals durch das S/370 bezeichnet.
Es wird nun angenommen, daß die S/370 Einheiten der Gesamteinheit 21 erfolgreich ihre Selbsttest- und Initialisierungsroutinen (STIR) durchgeführt haben und bereit zum Anlaufen sind.
Wie oben in Fig. 20 im Hinblick auf andere DMAC- und BCU- Interrupts der Ebene 6 beschrieben wurde, initiiert der S/88 Prozessor 62 einen Interrupt Acknowledge Zyklus als Reaktion auf ein SYNC Signal auf der Leitung 583. Die Funktionscode- und Prioritäsebenensignale vom Prozessor 62 werden in der Logik 281 decodiert, ein örtlicher BCU Request wird über den Ausgang 283 der Decodierlogik 281, Gatter 291, Leitung 287 und ODER-Schaltung 284 auf Leitung 190 gelegt.
Wenn der Prozessor 62 auf Leitung 191 einen Bus-Zyklus bekommt, aktiviert er (zusammen mit Signalen auf der SYNC- Leitung 583, AS Leitung 270 und Deocdierleitung 283) das AND Gatter 294-4, um ein Signal auf die IACK Leitung 258f zu legen. Dieses Signal wird an die Vektor-Bit-Logik 584 (Fig. 49) gelegt, um eine geeignete Vektornummer über den örtlichen BCU-Bus 223, den Treiber-Empfänger 218 und den Prozessor-Bus 161D an den S/88 Prozessor 62 zu schicken. Das Signal auf Leitung 258f stellt auch das Flipflop 582 zurück.
Wenn die S/370 STIR-Funktion bereits abgeschlossen ist, wie angenommen wird, führt der S/88 Prozessor 62 einen Lesezyklus durch, um die Vektornummer zu erhalten, die dann vom Prozessor 62 zum Zugriff auf die erste Anweisung einer Interrupt- Routine zur S/370 Synchronisierung benutzt wird.
Die letzte Anweisung der Synchronisierungsroutine generiert einen SYNC-Befehl, der ein SYNC-Signal auf die Leitung 586 (Fig. 50) legt.
Dieses Signal wird auf die SYNC-Leitungen 580 und 575 gelegt, um die S/88 (sowie den S/370) Prozessoren der Partnereinheiten 21, 23 schrittsynchronverriegelt anlaufen zu lassen.
Als Teil der S/88 'modul start up. cm' Ausführung wird eine emulierte SP 'IML Button Pushed' Funktionskette an die S/370 Einheiten in den Gesamteinheiten 21, 23 geschickt. Anstatt die ganze IML Funktion der DASD-Zugriffe usw. auszuführen, wird diese IML die E/A-Prozesse umgehen und vom S/88 Hauptspeicher laden. Der EXEC370-Code hat in Erwartung der IPL bereits den IPL-Code vom DASD geholt und in den S/88 Hauptspeicher gelegt. Der letzte Schritt der IPL ist dann die Übergabe der Steuerung an die durch Steile 0 spezifizierte Adresse.

B. Nur-Mikrocode Implementierung

Entweder werden die PU-Boards hochgefahren als Ergebnis eines ersten Einschaltvorgangs (IPO - Initial Power On) oder als Ergebnis einer Wiederherstellung bei Stromausfall (PFR - Power Fail Recovery).
Nehmen wir zunächst den Fall IPO:
Als Ergebnis des vom IPO aufgerufenen Signals Power Good ruft ein Maintenance Interrupt den 8/88 PROM 181 Code ab.
Dieser Code synchronisiert die S/88 Einheit der Gesamteinheit 21, ruft dann die S/370 STIR auf, die auch im PROM 181 resident ist. Die S/370 STIR findet, daß nicht genügend Einrichtungen geladen wurden, die sie initialisieren und synchronisieren könnte, da es sich hier um einen IPO handelt, der die Einrichtungen des S/88 und seines Betriebssystems benötigt. Als Ergebnis kehrt die S/370 STIR ohne weitere Aktion zum S/88 PROM 181 Code zurück, der zum Laden des O/S übergeht. Als Teil der O/S Initialisierung wird ein 'Start Up'-Modul aufgerufen Auch dieses Modul ruft die S/370 STIR auf, die im PROM 181 resident ist. Dieses Mal jedoch entscheidet die STIR, daß die notwendigen Vorrichtungen verfügbar sind, und benutzt sie zum Synchronisieren des Initial Microcode Load (IML) selbst.
Zweitens, Falle PFR,
Als Ergebnis des vom IPO aufgerufenen S/88 Signals Power_Good ruft ein Maintenance Interrupt den S/88 PROM 181 Code ab. Dieser Code synchronisiert die S/88 Einheit der Gesamteinheit 21, ruft dann die S/370 STIR auf, die auch im PROM 181 resident ist. Die S/370 STIR findet, daß die erforderlichen Vorrichtungen bereit stehen weil es sich hier um ein PFR handelt, und geht zum Synchronisieren und Initialisieren der S/370 Einheiten d.i. der Gesamteinheit 21 über.
5. Ein Partner 23 wird eingefügt, während die andere Einheit 21 normal arbeitet.

A. Hardware Implementierung

Ein Interrupt auf Ebene 6 wird beim Einschieben des neuen Board auf die S/88 Einheitsgruppe der laufenden Gesamteinheit 21 geschoben. Während die neue Prozessoreinheit ihre STIR abarbeitet, erkennt die laufende Prozessoreinheit den Interrupt auf Ebene 6. Ebene 6 führt den Prozeß des Archivierens der vorbelegten Angabenumgebung durch, entscheidet, ob die neue Bearbeitungseinheit online ist, und wenn so, vom Interrupt zurückgekehrt ist. Als Funktion des Return-from-Interrupt werden die zwei Einheiten schrittsynchronverriegelt aussteigen und die vorgegebene Aufgabe wiederaufnehmen.

B. Nur-Mikrocode Implementierung

Als Ergebnis des Einschiebens des neuen Board ruft ein Maintenance Interrupt den S/88 PROM 181 Code auf. Dieser Code resynchronisiert die S/88 Einheit der Gesamteinheit 21, ruft dann die S/370 STIR auf, die ebenfalls im PROM 181 resident ist. Die S/370 STIR entscheidet, da das ähnlich wie ein PFR ist, daß die erforderlichen Vorrichtungen verfügbar sind, und geht zum Synchronisieren und Initialisieren der S/370 Einheit der Gesamteinheit 21 über.

6. Ein Partner erfaßt einen Vergleichsfehler.

A. Hardware-Implementierung

Die ausgefallene Prozessoreinheit wird in ihre STIR gezwungen während die normalarbeitende Prozessoreinheit durch einen erzwungenen Interrupt der Ebene 6 unterbrochen wird. Die Dienstleistungs-Subroutine des Interrupt der Ebene 6 nimmt den Prozeß des Archivierens der vorgegebenen Aufgabenumgebung vor, und bestimmt, ob die neue Prozessoreinheit online ist; und wenn ja, kehrt sie vom Interrupt zurück. Als eine Funktion des Return-from- Interrupt werden die zwei Einheiten schrittsynchronverriegelt aussteigen und die vorgegebene Aufgabe wieder aufnehmen. Sollte die ausgefallene Prozessoreinheit nicht korrekt aus ihrer STIR aussteigen (z. B. einmal oder in einer vorgegeben Anzahl von Versuchen) wird die normalarbeitende Prozessoreinheit nach geeigneter Zeit auf den S/88 Teil der ausgefallenen Prozessoreinheit und ihre verschiedenen Statusmeldevorrichtungen auf BROKEN setzen.

B. Nur-Mikrocode-Implementierung

Als Ergebnis des erfaßten Vergleichsfehlers und des Off- Line-Gehen des Board ruft ein Maintenance Interrupt den S/88 PROM 181 Code auf. Dieser Code synchronisiert die S/88 Einheit der Gesamteinheit 21 und ruft dann die S/370 STIR auf, die ebenfalls im PROM 181 resident ist. Die S/370 STIR legt fest, daß das ähnlich einem PFR ist, und die erforderlichen Vorrichtungen verfügbar sind, und geht zur Synchronisierung und Initialisierung der S/370 Einheit der Gesamteinheit 21 über. Ein weiterer Vergleichsfehler führt dahin, daß die gleiche Aktion wiederholt wird. Nach einer vorgegebenen Anzahl Wiederholungen geht das Board für immer offline und eine Störung wird gemeldet.

Alternative Ausführungsformen

1. Anwendung in anderen, (nicht-S/88) fehlertoleranten Systemen

In der bevorzugten Ausführungsform wird gezeigt, daß Hardware-Fehlertoleranz wenigstens drei Merkmale aufweist. Da ist eine sofortige elektrische Isolierung einer gestörten, im Feld austauschbaren Einheit ohne Weitergabe von Datenfehlern an ein anderes Element des Systems. Ein dynamischer Neukonfigurierungscode ist vorgesehen, um Komponenten bei Störung bzw. bei Bedarf auszubauen bzw. einzusetzen. Die Fähigkeit zum Abschalten der Energie von bzw. zum Anlegen von Energie an ein Teilsystem oder eine im Feld austauschbare Einheit oh ne Verlust des Systems - d.i. die Fähigkeit zum Einstecken unter Spannung (hot plug capability) ist vorgesehen. Der Bediener merkt keinen Verlust an Funktion oder Leistung.
Angemerkt wird hier auch, daß die vorliegenden Verbesserungen in verschiedenen fehlertoleranten Umgebungen eingesetzt werden können, wie z. B. in software-fehlertoleranten Systemen, die bestimmte der obigen strengen Forderungen nicht erfüllen.
Ein Beispiel für ein anderes Systems (dem einige der strengen Forderungen abgehen), mit denen die vorliegende Verbesserung benutzt werden kann, ist in US-Patent 4356550 mit dem Titel "Microprozessor System" geoffenbart. In Fig. 1 dieses Patents arbeiten drei Prozessor-Teilsysteme asynchron zusammen und sind an Duplikatbusse gekoppelt. Wenn ein Teilsystem ausfällt, können die beiden anderen die Programmausführung fortsetzten. Alle Fehler werden an Prüfpunkten im Programm erfaßt anstatt augenblicklich, wie in der bevorzugten Ausführungsform der vorliegenden Anmeldung.
Prozessoren, wie z. B. S/370 Prozessoren, die unabhängig von den Teilsystemen des Patents arbeiten, können an die Teilsysteme angehängt werden auf eine Weise, die ähnlich der in der vorliegenden Anmeldung für das S/88 ist. Durch Verwenden und Steuern der Anwahlleitungen im Teilsystem des Patents auf ähnliche Weise wie sie für die Adreß-Strobe-(AS)-Leitung der vorliegenden Anmeldung beschrieben ist, können die Prozessoren der Teilsysteme abgekoppelt werden, damit sie als E/A- Controller für die sekundären, angehängten Fremdprozessoren arbeiten.

2. Direktdatenübertragungen zwischen S/88 E/A-Controllern und S/370 Hauptspeicher

In der bevorzugten Ausführungsform wird angenommen, daß der Cache 340 der ausschließliche Speicher für einige gültige E/A-Daten ist (anstatt der Speicher 162, der alle gültigen E/A-Daten speichert), wie es in typischen S/370 Cache- Systemen heute der Fall ist. In der Ausführungsform der Fig. 51, in der angenommenerweise der Speicher 162 alle gültigen E/A-Daten abspeichert, können E/A-Datenübertragungen direkt zwischen einer S/88 E/A-Vorrichtung, wie z. B. ein Platten- Controller 20, und dem S/370 Speicher 162 in einer effizienteren Operation stattfinden.
In dieser alternativen Ausführungsform muß jedoch immer noch die BCU 156 zur Übertragung von S/370 E/A-Befehlen auf das S/88 benutzt werden. System 370 Speicheradressen, die den Befehlen zugeordnet sind, müssen vom EXEC370 Code in physikalische S/88 Adressen umgewandelt werden während die Befehle in S/88 Befehle umgewandelt werden.
Während der Datenübertragungen vom Speicher 162 zu E/A- Vorrichtungen ist es eine Methode, zuerst den Cache-Abschnitt der für die E/A-Operation zum Speicher 162 vorgesehen ist, vor Ausführung der E/A-Operation zu leeren.
Während der Datenübertragungen von E/A-Vorrichtungen zum Speicher 162 wird der von der E/A-Operation betroffene Cache- Abschnitt vor Ausführung der E/A-Operation ungültig gemacht.
Wenn eine Datenumwandlung erforderlich ist, kann die Funktion in dem/den E/A-Vorrichtungs-Controller(n) durch Routinen ausgeführt werden, die ähnlich denen sind, die vom EXEC370 im S/88 Prozessor 62 benutzt werden.
Auch läßt sich eine Datenumwandlung durch die EXEC370 Applikation ausführen, die Umwandlungsroutinen im S/88 OS ausführt, wie z. B. eine Umwandlung von ASCII zu EBCDIC.

3. Abkoppeln beider Prozessoren eines direkt gekoppelten Paars

Fig. 52 illustriert den Datenfluß für eine alternative Ausführungsform, in der beide Prozessoren eines direkt gekoppelten Paars von ihrer zugeordneten Hardware abgekoppelt werden, vorzugsweise auf eine Weise, die im allgemeinen ähnlich der in Bezug auf den S/88 Prozessor 62 der bevorzugten Ausführungsform zur Übertragung von Befehlen und/oder Daten zwischen den Prozessoren ist, und zwar so, daß das für ihre Betriebssysteme transparent ist.
Zwei Prozessoren 640, 641 sind über die Prozessorbusse 642, 643, Treiber/Empfängerschaltungen 644, 645 und eine gemeinsame örtlichen Speichereinheit 646 zusammengekoppelt. Die Prozessoren 640 und 641 können die gleiche oder auch unterschiedliche Architekturen und das gleiche oder auch unterschiedliche Betriebssysteme aufweisen. Jeder Prozessor 640 und 641 kann seine eigene Hardware (nicht dargestellt) haben, einschließlich Hauptspeicher und E/A-Vorrichtungen für normale Programmabarbeitung unter der Steuerung der entsprechenden Betriebssysteme. Keines der Betriebssysteme merkt die Existenz oder das Ankoppeln an der Prozessor, der dem anderen System zugeordnet ist.
Wenn jedoch der Prozessor 640 dieser alternativen Ausführungsform durch ein Applikationsprogramm gesteuert wird, um Befehle und/oder Daten an den Prozessor 641 zu schicken, legt er vorzugsweise eine vorgegebene Adresse auf den Prozessoradressenbus 647, die durch die Logik 648 decodiert wird, um die Schaltungen 644 zu veranlassen, den Bus 642 über den örtlichen Bus 652 für den Befehls- und Datentransfer vom Prozessor 640 zum Speicher 646 an den örtlichen Speicher 646 zu koppeln. Das Decodieren der Adresse koppelt auch den Prozessor 640 von seiner zugeordneten Hardware ab, um die Übertragung transparent für das Betriebssystem des Prozessors 640 zu machen.
Das Abkoppeln der Steuerlogik 649 unterbricht den Prozessor 641, wenn für den Prozessor 641 bestimmte E/A-Befehle und/oder Daten in den örtlichen Speicher 646 übertragen werden. Der Prozessor 641 wird (über sein Applikationsprogramm- Interrupt-Bearbeitungsprogramm) von seiner Hardware abgekoppelt und liest die Befehle und/oder Daten vom Speicher 646 in seinen Hauptspeicher (nicht dargestellt) auf eine Weise, die für sein Betriebssystem transparent ist. Wenn die Befehle und/oder Daten einer Umwandlung bedürfen, benutzt der Prozessor 641 den Emulationsmikrocode im Speicher 650, um die erforderliche Umwandlung auszuführen. Der Prozessor 641 verarbeitet dann die umgewandelten Befehle unter der Steuerung seines Betriebssystems.
Hier wird darauf hingewiesen, daß das "Abkoppeln" der Prozessoren 640 und 641 die kontinuierliche Übertragung eines wesentlichen Segments von Befehlen und/oder Daten zu und vom örtlichen Speicher 646 zulassen kann, bevor das "Wiederankoppeln" jedes Prozessors an seine Hardware zugelassen wird. Auf diese Weise lassen sich schnelle und effiziente Datenübertragungen erzielen.
Befehle und Daten können auf ähnliche Weise auch in umgekehrter Richtung vom Prozessor 641 zum Prozessor 640 übertragen werden. Die Befehle und/oder Daten können, soweit erforderlich, durch den Emulations-Mikrocode, der im Speicher 651 sitzt, umgewandelt werden; und die umgewandelten Befehle können im Prozessor 640 unter Steuerung durch sein Betriebssystem weiterbearbeitet werden.
Diese alternative Ausführungsform unterscheidet sich in einer signifikanten Hinsicht von der bevorzugten Ausführungsform; d. h. der Prozessor, der den Datentransfer "initiiert", wird von seiner Hardware abgekoppelt, um Daten an den "empfangenden" Prozessor zu schicken. Das erfordert die zusätzliche Funktion des Übertragens der Steuerung auf ein Applikationsprogramm ähnlich dem EXEC370/ETIO der bevorzugten Ausführungsform, wenn eine E/A-Funktion (Befehlsübertragung und/oder Datenübertragung auf einen anderen Prozessor) ausgeführt werden soll.
Die Mittel zur Ausführung der Übertragung der Steuerung für bestimmte E/A-Operationen von einem Betriebssystem auf ein Applikationsprogramm hängt ab von den Merkmalen des Systems.
Zum Beispiel führt in der bevorzugten Ausführungsform das S/370 eine Start-E/A-Anweisung aus, die vom Betriebssystem auf normale Weise ohne "Abkoppeln" des S/370 Prozessors von seiner zugeordneten Hardware bearbeitet wird.
In der alternativen Ausführungsform der Fig. 52, wenn z. B. ein S/370 Prozessor 640 Befehle und/oder Daten an den Prozessor 641 schickt, kann auch ein angewählter ungültiger OP CODE benutzt werden anstatt einer Start-E/A-Anweisung. Hardware- oder Mikrocode-Decodierung des angewählten ungültigen OP CODE überträgt die Steuerung auf ein spezielles Applikationsprogramm, das das S/370 für den Informations-Transfer mit dem Prozessor 641 über den Speicher 646 von seiner Hardware "abkoppelt".
Um das Überschreiben von Daten durch den einen Prozessor, die vom anderen Prozessor in den Speicher 646 übertragen wurden, zu verhindern, kann der Prozessor 640 so gesteuert werden, daß er nur in einen spezifischen Abschnitt des Speichers 646 schreibt; und Prozessor 641 wird so gesteuert, daß er nur aus diesem einen Abschnitt liest. Prozessor 641 darf nur in einen zweiten Abschnitt des Speichers 646 schreiben, und der Prozessor 640 darf nur aus diesem zweiten Abschnitt lesen. Die Prozessoren 640 und 641 dürfen entsprechend nicht in den zweiten bzw. in den einen Abschnitt schreiben.
Der Abkopplungs- und Interrupt-Mechanismus werden transparent für die Betriebssysteme beider Prozessoren 640 und 641 betrieben, wie im Hinblick auf S/88 Prozessor 62 der bevorzugten Ausführungsform beschrieben ist.
Die Emulationsfunktionen können auf diese Weise von Applikationsprogrammen (anstatt vom Mikrocode im örtlichen Speicher) ausgeführt werden, wie im Hinblick auf EXEC370 und die bevorzugte Ausführungsform beschrieben ist.
Anstatt des Interrupt-Mechanismus könnten zum Übertragen der Daten zwischen den Prozessoren 640, 641 auch Abrufverfahren eingesetzt werden; jedoch wären solche Techniken ineffizient.
Es wird ferner darauf hingewiesen, daß jeder der Prozessoren 640 und 641 E/A-Operationen für den anderen durchführen kann, und daher kann jeder der Prozessoren bestimmte E/A- Umgebungsmerkmale des anderen übernehmen.
Ebenso sieht man, daß eine Applikation in einem Prozessor mit einer gleichen oder unterschiedlichen Applikation in einem zweiten Prozessor kommunizieren kann, ohne die Dienstprogramme des Betriebssystems eines der beiden Prozessorsysteme in Anspruch zu nehmen.
Es ist klar, daß der Ausdruck "Applikationsprogramm oder -code" in seinem herkömmlichen Sinn gebraucht wird, wie ihn der Datenverarbeitungsfachmann versteht; d. h. er unterscheidet sich in der Regel auf die folgende Weise vom Betriebssystemcode:
1. Applikationsprogramme sitzen oben auf einem Betriebssystem, und müssen in der Regel Dienstprogramme des Betriebssystems wie Lesen, Schreiben und Steuerung der E/A, Tageszeit usw. aufrufen.
2. Der Applikationscode wird durch einen Anwender gestartet oder aufgerufen und wird über die Operationssystemdienstprogramme geladen.
3. Das Operationsprogramm steuert das Paging der Applikationsprogramme in den und aus dem Speicher.
4. Das Betriebssystem teilt den Applikationsprogrammen Hauptspeicherraum zu. Jedoch bekommt ein solcher "Applikations"-Code jetzt zusätzliche Funktionen zugeteilt, die er ausführen muß.
"Fremd" (alien) wird benutzt, um ein Gerät zu definieren, das dem Betriebssystem nicht bekannt ist, weil es in den Betriebssystem-Konfigurationstabellen nicht definiert ist, und daher hat das Betriebssystem auch keinen Vorrichtungstreiber für das Gerät und kann das Gerät auch nicht steuern. In der vorliegenden Ausführungsform jedoch kennt ein auf dem Betriebssystem laufendes besonderes Applikationsprogramm das Gerät und kann das Gerät im gewissen Sinne steuern.
"Unterscheiden" (discern) wird in dem Sinne benutzt, daß ein Betriebssystem das Fremdgerät, das an einen Prozessor angeschlossen ist, auf dem das Betriebssystem läuft, gar nicht bemerkt bzw. vom Prozessor gegen das Betriebssystem isolierte Aktionen unternommen werden, damit das Betriebssystem eine solche Aktion nicht zurückweisen kann.
In der Spezifikation wurde der Ausdruck "transparent" häufig in dieser gleichen Bedeutung benutzt.
Die Erfindung wurde insbesondere unter Bezugnahme auf eine bevorzugte Ausführungsform gezeigt und beschrieben; dem Fachmann ist jedoch bewußt, daß die oben vorgeschlagenen Änderungen und alternativen Formen sowie auch noch weitere Änderungen in Form und Detail vorgenommen werden können, ohne von den Lehren der vorliegenden Anmeldung abzuweichen. Die obige Beschreibung und die Zeichnungen müssen daher als hinweisend und keineswegs als einschränkend interpretiert werden.

Claims

1. Eine Datenverarbeitungsvorrichtung zum Austausch von Informationen zwischen zwei verschiedenen Prozessoren, bestehend aus:

einem ersten Prozessor 85, 87, gesteuert von einem ersten Anwendungsprogramm, das unter einem ersten Betriebssystem läuft; und

einem zweiten Prozessor 60, 62, gesteuert von einem zweiten Anwendungsprogramm, das unter einem zweiten Betriebssystem läuft, wobei das zweite Betriebssystem die Ressourceneinheitendienste für die Datenverarbeitungsvorrichtung zur Verfügung stellt, wobei Konfigurationstabellen, in denen die Systemressourcen für das zweite Betriebssystem angegeben sind, keine Daten enthalten, welche das erste Betriebssystem identifizieren;

gekennzeichnet durch:

Mittel 648 zum Abkoppeln des zweiten Prozessors 60, 62 vom zweiten Betriebssystem; und

ein zwischen die Prozessoren gekoppeltes Informationsübertragungsmittel 156, das die direkte Übertragung von Informationen zwischen dem ersten und dem zweiten Anwendungsprogramm ermöglicht während der zweite Prozessor von zweiten Betriebssystem abgekoppelt ist.

2. Eine Datenverarbeitungsvorrichtung gemäß Anspruch 1, in der das Informationsübertragungsmittel 156 in Kooperation mit dem zweiten Anwendungsprogramm Befehle vom ersten Prozessor 85, 87 erkennt, solche Befehle in entsprechende Ressourceneinheitenbefehle umwandelt, und dem ersten Datenverarbeitungssystem mit einem Bestätigungssignal antwortet, das mit dem ersten Betriebssystem für den ersten Prozessor konsistent ist.

3. Eine Datenverarbeitungsvorrichtung gemäß allen vorhergehenden Ansprüchen, in der das Informationsübertragungsmittel 156 Informationen zwischen den Ressourceneinheiten und dem ersten Prozessor 85, 87 unter der Steuerung durch das zweite Anwendungsprogramm überträgt.

4. Eine Datenverarbeitungsvorrichtung gemäß allen vorhergehenden Ansprüchen, in der das Informationsübertragungsmittel 156 Mittel enthält, um am Ende einer Datenübertragung Bestätigungssignale an den ersten Prozessor 85, 87 zu senden.

5. Eine Datenverarbeitungsvorrichtung gemäß allen vorhergehenden Ansprüchen, in der das Informationsübertragungsmittel Mittel enthält, um Informationen durch eine adressierbare Speicherzone 16 zu übertragen, auf welche sowohl das unter dem ersten Betriebssystem laufende erste Anwendungsprogramm als auch das unter dem zweiten Betriebssystem laufende zweite Anwendungsprogramm unabhängig von den Diensten des zweiten Betriebssystems zugreifen kann.

6. Eine Datenverarbeitungsvorrichtung gemäß allen vorhergehenden Ansprüchen, in der:

die vom ersten Anwendungsprogramm ausgehenden Befehle eine Ein-/Ausgabe-Startfunktion anfordern, die durch das erste Betriebssystem verarbeitet wird;

das Informationsübertragungsmittel 156 als Reaktion auf eine Befehlsinstruktion vom ersten Prozessor 85, 87 ein vorgegebenes Interrupt-Signal an den zweiten Prozessor 60, 62 sendet; und

das zweite Anwendungsprogramm 651 als Reaktion auf die Erkennung des vorgegebenen Interrupt-Signals die Befehlsinstruktion vom ersten Prozessor 85, 87 bedient und umwandelt.