DE4413459C2 - Programmierbares Interrupt-Controller-System - Google Patents

Programmierbares Interrupt-Controller-System

Info

Publication number
DE4413459C2
DE4413459C2 DE4413459A DE4413459A DE4413459C2 DE 4413459 C2 DE4413459 C2 DE 4413459C2 DE 4413459 A DE4413459 A DE 4413459A DE 4413459 A DE4413459 A DE 4413459A DE 4413459 C2 DE4413459 C2 DE 4413459C2
Authority
DE
Germany
Prior art keywords
interrupt
mpic
local
bus
processor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE4413459A
Other languages
English (en)
Other versions
DE4413459A1 (de
Inventor
P K Nizar
David Carson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE4413459A1 publication Critical patent/DE4413459A1/de
Application granted granted Critical
Publication of DE4413459C2 publication Critical patent/DE4413459C2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4812Task transfer initiation or dispatching by interrupt, e.g. masked
    • G06F9/4818Priority circuits therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/20Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/24Handling requests for interconnection or transfer for access to input/output bus using interrupt
    • G06F13/26Handling requests for interconnection or transfer for access to input/output bus using interrupt with priority control
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163Interprocessor communication
    • G06F15/17Interprocessor communication using an input/output type connection, e.g. channel, I/O port

Description

Die vorliegende Erfindung bezieht sich auf ein Inter­ rupt-Controller-System nach dem Oberbegriff des Patentan­ spruchs 1.
Eingabe/Ausgabe-Peripheriegeräte erfordern eine inter­ mittierende Bedienung durch einen Wirtsprozessor, um ein korrektes Funktionieren sicherzustellen. Bedienungen können beispielsweise Datenausgabe, Datenübernahme und/oder Steuer­ signale beinhalten. Jedes Peripheriegerät hat typischerweise einen unterschiedlichen Bedienungsablaufplan, der nicht nur von der Art des Gerätes sondern auch von seiner programmier­ ten Verwendung abhängig ist. Von dem Wirtsprozessor wird ge­ fordert, daß er seine Bedienungsaktivitäten unter diesen Ge­ räten in Übereinstimmung mit deren individuellen Bedürfnis­ sen im Multiplex-Betrieb aufteilt, während er Hintergrund­ programme abarbeitet. Es werden zwei Verfahren zum Benach­ richtigen des Wirts verwendet: Verfahren mit zyklisch abge­ fragten Geräten und Geräte-Interrupt-Verfahren. Bei dem erstgenannten Verfahren wird jedes Peripheriegerät peri­ odisch überprüft, um zu sehen, ob ein Flag gesetzt worden ist, das eine Bedienungsanforderung anzeigt, während bei dem letztgenannten Verfahren die Gerätebedienungsanforderung zu einem Interrupt-Controller weitergeleitet wird, der den Wirt unterbrechen kann, wobei eine Verzweigung von dessen aktuel­ lem Programm zu einer speziellen Interrupt-Bedienungsroutine erzwungen wird. Das Interrupt-Verfahren ist vorteilhaft, weil der Wirt nicht unnötige Taktzyklen zum Abfragen opfern muß. Die vorliegende Erfindung richtet sich auf dieses letz­ tere Verfahren. Das von der Erfindung angesprochene spezi­ elle Problem ist die Handhabung von Interrupts in einer Mul­ tiprozessor-Systemumgebung.
Ein System mit den Merkmalen des Oberbegriffs des Pa­ tentanspruchs 1 ist z. B. aus dem US-Patent Nr. 4,495,569 bekannt. Dieses bekannte System verwendet einen Interrupt- Controller, der zentral die Interrupt-Anforderungen von Pe­ ripheriegeräten empfängt und an jeweils einen Prozessor der mehreren Prozessoren weiterleitet.
Multiprozessor-Systeme, oftmals ein Satz von vernetzten Computern mit gemeinsamen Peripheriegeräten, stellen eine Herausforderung bei der Entwicklung von Interrupt-Steuerver­ fahren dar. Beispielsweise wäre es im Falle eines Computer­ netzwerks, das eine Anzahl von Benutzern bedient, höchst wünschenswert, die Interrupt-Behandlungslast in einer opti­ malen Weise zu verteilen. Prozessoren, die Jobs hoher Prio­ rität verarbeiten, sollten von dieser Verpflichtung entla­ stet werden, wenn Prozessoren mit Jobs geringerer Priorität verfügbar sind. Auf der niedrigsten Priorität arbeitende Prozessoren sollten gleichmäßig durch die Interrupt-Bedie­ nungsanforderungen belastet werden. Auch können spezielle Umstände erfordern, daß ein spezielles I/O-Gerät ausschließ­ lich von einem vorausgewählten Prozessor (oder Focus-Prozes­ sor) bedient wird. Folglich betrifft die Erfindung das Pro­ blem der optimalen dynamischen und statischen Interrupt-Be­ dienung in Multiprozessor-Systemen.
Bekannte, an Ein-Prozessor-Systeme angepaßte program­ mierbare Interrupt-Controller (PICs), beispielsweise Intel's 82C59A und 82380, sind so konstruiert, daß sie eine Anzahl von externen Interrupt-Anforderungseingangssignalen anneh­ men. Die wesentliche Struktur solcher Controller besteht, wie in Fig. 1 gezeigt, aus sechs Hauptblöcken:
IRR - das Interrupt-Anforderungsregister 11 (Interrupt Request Register) speichert sämtliche Interrupt-Pegel (IRQx) auf den Leitungen 16, die eine Bedienung anfordern;
ISR - das Interrupt-Bedienungsregister 12 (Interrupt Service Register) speichert sämtliche Interruptpegel, welche gerade bedient werden, wobei der Status bei Empfang eines Ende­ des-Interrupt-Signals (EOI) aktualisiert wird;
IMR - das Interrupt-Masken-Register 13 speichert die Bits, die anzeigen, welche IRQ-Leitungen 16 beim Betrieb auf dem IRR 11 maskiert oder gesperrt werden sollen;
VR - die Vektor-Register 19, ein Satz von Registern, jeweils eines für jede IRQ-Leitung 16, speichern die vorprogrammierte Interrupt-Vektor- Nummer, die auf dem Datenbus 17 an den Wirtsprozessor angelegt wird und die sämtliche für den Wirt notwendigen Informationen zum Bedienen der Anforderung enthält;
PR - der Prioritäts-Resolver 15 ist ein Logikblock, der die Priorität der in dem IRR 11 gesetzten Bits bestimmt, wobei während eines Interrupt-Bestätigungszyklus (INTA - Interrupt Acknowledge) von dem Wirtsprozessor die höchste Priorität ausgewählt und in das Bit des ISR 12 eingeblendet wird;
Steuerlogik - diese koordiniert den Gesamtbetrieb der anderen internen Blöcke innerhalb des gleichen PIC, aktiviert die Wirts-Eingabe- Interrupt-Leitung (INT) 21, wenn ein oder mehrere Bits des IRR 11 aktiv sind, gibt das VR 19 frei, um während eines INTA-Zyklus den Interrupt-Vektor auf den Datenbus 17 zu treiben, und verhindert sämtliche Interrupts mit einer Priorität, die gleich oder kleiner der des gegenwärtig bedienten ist.
Verschiedene unterschiedliche Verfahren werden verwen­ det, um den verschiedenen IRQ-Leitungen 16 jeweils eine Priorität zuzuweisen; diese umfassen:
  • 1. den vollständig verschachtelten bzw. festgesetzten (nested) Modus,
  • 2. den Modus der automatischen Rotation bei gleichrangigen Geräten und
  • 3. den Modus der spezifischen Rotation und der spezifischen Priorität.
Der vollständig verschachtelte Modus unterstützt eine Mehrebenen-Interrupt-Struktur, in welcher sämtliche der IRQ- Eingangsleitungen 16 von der höchsten zur niedrigsten Prio­ rität geordnet sind: Typischerweise wird IRQ0 die höchste Priorität zugewiesen, während IRQ7 die niedrigste hat.
Die automatische Rotation bei unterbrechenden Geräten gleicher Priorität wird durch Rotation der zugewiesenen Prioritäten derart ausgeführt, daß der jeweils zuletzt be­ dienten IRQ-Leitung die geringste Priorität zugewiesen wird. Auf diese Weise ist die Zugreifbarkeit auf die Interrupt-Be­ dienung darauf gerichtet, für jedes der konkurrierenden Ge­ räte statistisch ausgeglichen zu sein.
Das spezifische Rotationsverfahren gibt dem Benutzer da­ durch eine Beweglichkeit, daß dem Benutzer gestattet wird, auszuwählen, welche IRQ-Leitung die geringste Priorität er­ halten soll, wobei sämtlichen anderen IRQ-Leitungen dann se­ quentiell (kreisförmig) höhere Prioritäten zugewiesen wer­ den.
Aus der vorangegangenen Beschreibung ist ersichtlich, daß PIC-Strukturen der beschriebenen Art an Ein-Prozessor- Systeme mit mehreren Peripheriegeräten angepaßt sind, aber nicht an Multiprozessor-Systeme mit mehreren geteilten Peri­ pheriegeräten, auf welche die vorliegende Erfindung gerich­ tet ist.
Aufgabe der Erfindung ist es, für ein Multiprozessor-Sy­ stem ein flexibles Interrupt-Steuersystem zur Verfügung zu stellen.
Diese Aufgabe wird erfindungsgemäß durch ein Interrupt- Controller-System mit den Merkmalen des Patentanspruchs 1 gelöst.
Dabei soll bei einem bevorzugten Ausführungsbeispiel ein programmierbares Multiprozessor-Interrupt-Controller(NIPIC)- System geschaffen werden, das eine integrierte Schaltung verwendet, die sowohl einen lokalen Prozessor als auch einen zugeordneten lokalen Prozessor-Interrupt-Controller in einer Einheit verkörpert.
Die erfindungsgemäße MPIC-Systemstruktur enthält vor­ zugsweise drei Haupt-Untersysteme:
  • 1. eine I/O-MPIC-Einheit zum Erfassen von Interrupt-An­ forderungs(IRQ)-Signalen von den ihr zugeordneten I/O-Peripheriegeräten, die eine Umadressier-Tabelle für eine Prozessorauswahl und Vektor/Prioritäts-In­ formationen hat;
  • 2. lokale MPIC-Einheiten, welche mit dem zugeordneten Prozessor verbundene, separate Hilfseinheiten oder teilweise oder vollständig in den zugeordneten Pro­ zessor integrierte Einheiten sein können und welche jeweils Interrupt-Anforderungen für einen speziellen Systemprozessor handhaben, einschließlich Erwar­ tungs(pending)-, Verschachtelungs- und Maskieropera­ tionen ebenso wie eine Zwischen-Prozessor-Interrupt- Erzeugung; und
  • 3. ein spezieller von jedem beliebigen System- oder Speicherbus getrennter I/O-Bus zur Kommunikation zwi­ schen der I/O- und den lokalen MPIC-Einheiten ebenso wie zwischen den lokalen MPIC-Einheiten.
Im folgenden wird die Erfindung anhand von in der Zeich­ nung dargestellten bevorzugten Ausführungsbeispielen erläu­ tert. In der Zeichnung zeigt:
Fig. 1 ein Blockschaltbild eines üblichen bekannten programmierten Einprozessor-Interrupt-Control­ lers (PTC);
Fig. 2 ein Blockschaltbild des gegenwärtig bevorzug­ ten programmierbaren Multiprozessor-Interrupt- Controller(MPIC)-Systems;
Fig. 3 ein Blockschaltbild der gegenwärtig bevorzug­ ten I/O-MPIC-Einheit;
Fig. 4 die verschiedenen Felder, die einen 64-Bit- Eintrag einer Umadressiertabelle bilden;
Fig. 5 ein Blockschaltbild der gegenwärtig bevorzugten lokalen MPIC-Einheit;
Fig. 6 die verschiedenen Felder, die die Einträge der lokalen Vektortabelle einer lokalen MPIC-Einheit bilden;
Fig. 7 die verschiedenen Feldzuweisungen des Interrupt- Kommandoregisters,
Fig. 8 das Verfolgen des Fern-Bits durch das Ziel-IRR- Bit;
Fig. 9 ein Flußdiagramm, das den Interrupt-Akzeptanz- Prozeß einer lokalen MPIC-Einheit zeigt;
Fig. 10 die MPIC-ID-Registerkonfiguration
Fig. 11 die nicht-isolierten MPIC-Busverbindungen;
Fig. 12 eine Tri-State-gepufferte MPIC-Busanordnung
Fig. 13 den in der Busentscheidung verwendeten 2-Bit- Dekodierprozeß für den MPIC-ID;
Fig. 14 die Arten der MPIC-Kurznachrichten;
Fig. 15 die MPIC-Nachrichtenkodierung des Abgabemodus
Fig. 16 eine Definition der Steuerbits der MPIC- Nachricht;
Fig. 17 eine Definition der Steuerbitkodierung des erweiterten Abgabemodus;
Fig. 18 die Mittel- und Langnachrichtenformate des MPIC- Bus;
Fig. 19 den Basis-0-, -1- und -2-Zeitgenerator;
Fig. 20 die Dividier(Basis-2)-Konfigurationsregister- Bitzuweisungen; und
Fig. 21 die Inhalte der drei Zeitgeber der lokalen Vektortabelle.
Es wird ein programmierbares Multiprozessor-Interrupt- Controller(MPIC)-System beschrieben. In der folgenden Beschreibung werden zahlreiche spezielle Details, wie beispielsweise eine spezielle Anzahl von Eingangs-Pins, Bits und Geräten usw. beschrieben, um ein besseres Verständnis des bevorzugten Ausführungsbeispiels der Erfindung zu erreichen. Für den Fachmann ist es jedoch klar, daß die vorliegende Erfindung auch ohne diese speziellen Details ausgeführt werden kann. An anderen Stellen werden gut bekannte Schaltungen nicht im Detail gezeigt bzw. nur in Blockdiagrammform gezeigt, um die Beschreibung nicht mit unnötigen Angaben zu belasten.
Zusätzlich wird beim Beschreiben der Erfindung auf Signalnamen Bezug genommen, die speziell für das bevorzugte Ausführungsbeispiel gelten. Die Bezugnahme auf diese speziellen Namen ist nicht im Sinne einer Einschränkung der Reichweite der Erfindung auszulegen.
A. ÜBERBLICK ÜBER DIE MPIC ARCHITEKTUR
Das programmierbare Multiprozessor-Interrupt- Controller(MPIC)-System ist an eine Interrupt-Bedienung in einer Mehrprozessor-Umgebung angepaßt. Die gegenwärtige Praxis betrifft hauptsächlich Einprozessor-Systeme, in welchen die Interrupts einer Anzahl von Peripherieeinheiten von einem einzelnen Prozessor bedient werden, der von einem programmierbaren Interrupt-Controller (PIC) unterstützt wird.
Bei einem Multiprozessor-System ist es oftmals wünschenswert, die Last der Bedienung der Interrupts auf eine Gruppe von ähnlichen Prozessoren zu verteilen. Dies beinhaltet die Fähigkeit, Interrupt-Serviceanforderungen zu der passenden Gruppe von Prozessoren auszusenden, und einen Mechanismus zum Bestimmen der gerechten Zuweisung der Aufgaben zu den Prozessoren. Das Einprozessor-Konstruktionsproblem ist bedeutsam einfacher: der dem Prozessor zugeordnete PIC weist jeder Interrupt-Anforderungsleitung (IRQ) eine Priorität zu, ordnet die Anforderungen entsprechend den zugewiesenen Prioritäten und liefert dem Prozessor die notwendigen Informationen, um zeitgerecht die geeignete Dienst-Subroutine zu initiieren.
Das MPIC-System schafft sowohl statische als auch dynamische Interrupt-Aufgabenzuweisungen zu den verschiedenen Prozessoren. Wenn es in einem rein statischen Modus betrieben wird, funktioniert es im wesentlichen wie ein PIC in einem Einprozessor-System, der jedes Interrupt entsprechend einem vorgeschriebenen Ablaufplan zuweist.
Wenn es in einem dynamischen Modus betrieben wird, handhabt das MPIC-System Interrupt-Aufgabenzuweisungen, indem es die relative Aufgabenpriorität zwischen den Prozessoren in Betracht zieht.
Es ist zu erwarten, daß eine typischere Verwendung sowohl Elemente der statischen als auch der dynamischen Interrupt- Handhabung erfordern dürfte. Statische Zuweisungen könnten beispielsweise dann ausgeführt werden, wenn Lizenzerwägungen die geteilte Verwendung von Dienstsoftware ausschließen. Unter anderen Umständen kann es wünschenswert sein, die Interrupt- Bedienungsaufgabe auf eine Untermenge von Prozessoren einzugrenzen, die ein gemeinsames Peripherie-Subsystem teilen. Im Extremfall sind sämtliche Prozessoren Interrupt- Anforderungen von sämtlichen peripheren Subsystemen ausgesetzt.
Fig. 2 ist ein Blockschaltbild des gegenwärtig bevorzugten programmierbaren Multiprozessor-Interrupt-Controller(MPIC)- Systems. Der MPIC 100 besteht aus drei Haupteinheiten: Einer I/O-MPIC-Einheit 102, einem MPIC-Bus 103 und mehreren lokalen MPIC-Einheiten, von denen eine mit 104 gekennzeichnet ist. Jeder I/O-MPIC 102 nimmt Interrupt-Leitungen 107 von dem ihm zugeordneten I/O-Subsystem 101 (typischerweise eine Ansammlung von Peripheriegeräten) an, wobei jede Leitung einem speziellen IRQ entspricht. Der Ausgang des I/O-MPIC ist mit dem MPIC-Bus 103 gekoppelt, welcher an sämtliche lokale MPIC-Einheiten 104 geeignet formatierte IRQ-Nachrichten aussendet, die alle notwendigen Identifizierungs- und Prioritätsinformationen enthalten. Jede lokale MPIC-Einheit 104 untersucht die Nachricht und entscheidet, ob sie sie annimmt bzw. akzeptiert. Wenn sie versuchsweise von mehr als einer lokalen MPIC-Einheit 104 angenommen wurde, wird eine Entscheidungsprozedur zwischen den konkurrierenden Einheiten aufgerufen. Die lokale MPIC- Einheit 104 mit der geringsten Priorität gewinnt den Entscheidungswettstreit, nimmt die IRQ an und verteilt sie zeitgerecht an den ihr zugeordneten Prozessor 105.
Der Systembus 30 ist das übliche Mittel zum Nachrichtenaustausch zwischen den Prozessoren, dem Speicher, und anderen Peripherieeinheiten des Multiprozessor-Systems. Jeder Prozessor und jedes Peripheriegerät bildet eine Schnittstelle zu dem Systembus 30 mit Hilfe einer Speicherbus- Steuereinrichtung (MBC - Memory Bus Controller) 31. Bei bekannten Systemen trägt der Systembus 30 den Interrupt- Anforderungsverkehr, den Interrupt-Bedienungsverkehr und den gesamten anderen Systemverkehr zwischen den Einheiten. Die vorliegende Erfindung verweist den Interrupt- Anforderungsverkehr auf den MPIC-Bus 103, wodurch die gesamte Systemeffizienz erhöht wird.
B. INTERRUPT STEUERUNG
Die Interrupt-Steuerfunktionen sowohl der I/O-MPIC-Einheit als auch der lokalen MPIC-Einheiten sind gemeinsam für die Lieferung von Interrupts von den Interrupt-Quellen an einen das Interrupt bedienenden Prozessor in einem Multiprozessor-System verantwortlich.
Jedes Interrupt hat eine Kennung, den Interrupt-Vektor, der das Interrupt eindeutig von anderen Interrupts in dem System unterscheidet. Wenn ein Prozessor ein Interrupt (IRQ) annimmt, verwendet er den Vektor, um den Eintragspunkt des geeigneten Software-Interrupt-Handlers in seiner Interrupt-Tabelle zu lokalisieren. Das bevorzugte Ausführungsbeispiel unterstützt 256 (8-Bit) unterschiedliche Vektoren im Bereich von 0 bis 255.
Jedes Interrupt hat eine Interrupt-Priorität, die von den fünf am höchsten bewerteten Bits des 8-Bit-Interrupt-Vektors dargestellt wird, d. h. 16 Prioritätsebenen, wobei 0 die niedrigste und 15 die höchste Priorität hat. Dies bedeutet, daß 16 verschiedene Vektoren sich eine einzelne Interrupt- Prioritätsebene teilen können.
Interrupts werden von einer Anzahl unterschiedlicher Quellen erzeugt, welche enthalten können:
  • 1. mit I/O-MPIC-Einheit verbundene externe I/O-Geräte, wobei die Interrupts entweder von Flanken (Pegelübergängen) oder Pegeln auf den Interrupt- Eingangspins dargestellt und zu einem beliebigen Prozessor umadressiert werden können;
  • 2. Interrupts lokal angekoppelter Geräte, die stets nur an den lokalen Prozessor gerichtet werden und Flanken- oder Pegelsignale darstellen;
  • 3. MPIC-Zeitgeber-Interrupts, die innerhalb der lokalen MPIC-Einheit durch irgendeinen der drei programmierbaren Zeitgeber erzeugt werden;
  • 4. Zwischen-Prozessor-Interrupts, die an irgendeinen einzelnen Prozessor oder Gruppen von Prozessoren adressiert werden, bei der Unterstützung von Software-Selbstunterbrechungen, bevorzugte Ablaufplanungen (pre-emptive scheduling), Cashe- Speichertabellen-Vorgriff-Puffer(TLB)-Flushing und Interrupt-Weiterleitungen; und
  • 5. Bus-Paritätsfehler-Interrupts, die von irgendeiner lokalen MPIC-Einheit erzeugt werden, die einen Paritätsfehler auf dem Datenbus erfaßt, der ihren Wirtsprozessor veranlaßt, unterbrochen zu werden.
Das Ziel bzw. der Bestimmungsort eines Interrupts kann kein Prozessor, ein Prozessor oder einer Gruppe von Prozessoren in dem System sein. Für jedes Interrupt kann ein unterschiedliches Ziel spezifiziert werden. Der Sender spezifiziert das Ziel eines Interrupts in einem von zwei Zielmoden: dem physischem bzw. physikalischen Modus und dem logischen Modus.
Im physischen Modus wird der Zielprozessor durch einen speziellen 8-Bit-MPIC-ID spezifiziert. Im physischen Zielmodus kann nur ein einzelnes Ziel oder eine Sendung an sämtliche Ziele (MPIC-ID von nur Einsen) spezifiziert werden.
Jede MPIC-Einheit hat ein Register, das den 8-Bit-MPIC-ID der Einheit enthält. Der MPIC-ID dient als ein physischer Name der MPIC-Einheit. Er kann beim Spezifizieren der Zielinformationen verwendet werden und wird außerdem zum Zugreifen auf den MPIC-Bus verwendet. Der Mechanismus, durch welchen ein MPIC seinen MPIC-ID erstellt, ist implementierungsabhängig. Einige Implementierungen können den MPIC-ID über einige ihrer Pins von der Steckplatznummer zum Rücksetzzeitpunkt einspeichern. Der MPIC-ID ist durch Software les- und schreibbar.
Der MPIC-ID dient als der physische "Name" der MPIC- Einheit, der zum Adressieren des MPIC im physischen Ziel-Modus und für MPIC-Bus-Verwendungen benutzt wird.
Im logischen Modus werden die Ziele mit Hilfe eines 32-Bit- Zielfeldes spezifiziert. Sämtliche lokalen MPIC-Einheiten enthalten ein 32-Bit breites logisches Ziel-Register 223, mit welchem das Zielfeld des Interrupts verglichen wird, um festzustellen, ob der Empfänger Ziel des Interrupts ist. Ein zusätzliches 32-Bit breites Ziel-Format-Register 221 in jeder lokalen MPIC-Einheit definiert exakt, wie das Zielfeld mit dem Ziel-Register verglichen werden soll. Mit anderen Worten definiert das Ziel-Format-Register 221 die Interpretation der logischen Zielinformation.
Das Ziel-Format-Register 221 teilt die 32-Bit- Zielinformation in zwei Felder auf:
  • 1. ein kodiertes Feld, das verwendet werden kann, um einen skalaren ID darzustellen. Eine Übereinstimmung bei dem kodierten Feld erfordert eine exakte Übereinstimmung des Wertes dieses Feldes. Um eine Sendung an sämtliche Ziele im logischen Modus zu unterstützen, wird ein Wert des kodierten Feldes von nur Einsen speziell derart behandelt, daß er mit jedem beliebigen Wert übereinstimmt.
  • 2. ein dekodiertes Feld (oder Bit-Matrix), das verwendet werden kann um einen Satz von Elementen darzustellen. Eine Übereinstimmung bei dem dekodierten Feld erfordert, daß zumindest eines der entsprechenden Bit- Paare des dekodierten Feldes zwei Einsen sind.
Das Ziel-Format-Register 221 wird von Software gesteuert und legt fest, welche Bits in der Zielinformation Teil des kodierten Feldes und welche Bits Teil des dekodierten Feldes sind. Um eine Übereinstimmung bei dem Ziel zu erhalten, müssen beide Felder übereinstimmen.
Die auf der logischen Ebene stattfindende Interpretation dessen, was jedes Feld tatsächlich darstellt, wird vollständig von dem Betriebssystem definiert. Zu beachten ist, daß diese Felder nicht aufeinanderfolgende Bits zu verwenden brauchen und daß die Länge jedes der beiden Felder gleich null sein kann. Ein Feld der Länge null stimmt stets überein. Da die Zielinterpretation lokal durch jede MPIC-Einheit ausgeführt wird, müssen die Ziel-Format-Register sämtlicher MPIC-Einheiten in einem System identisch eingerichtet sein.
Im folgenden werden drei beispielhafte Verwendungsmodelle beschrieben, die unterschiedliche Interpretationen verwenden, um den Zielspezifikationsmechanismus weiter zu veranschaulichen. Dies sind wahrscheinlich die in der Praxis häufigsten Modelle.
Beispiel 1 Einzelebenen-Modell
Bei diesem Modell werden sämtliche 32 Bits der Zielinformation als dekodiertes Feld interpretiert. Jede Bitposition entspricht einer einzelnen lokalen MPIC-Einheit. Eine Bitposition könnte einem physischen MPIC-ID entsprechen, aber dies muß nicht der Fall sein. Dieses Schema gestattet die Spezifikation von beliebigen Gruppen von MPIC-Einheiten, indem einfach die Bits der Mitglieder auf Eins gesetzt werden. Es gestattet aber maximal 32 Prozessoren (oder lokale MPIC-Einheiten) pro System. Bei diesem Schema wird eine MPIC-Einheit adressiert, wenn ihr Bit in der Zielmatrix gesetzt ist. Eine Sendung an sämtliche Ziele wird erreicht, indem sämtliche 32 Zielbits auf Eins gesetzt werden. Dies wählt sämtliche MPIC-Einheiten in dem System aus.
Beispiel 2 Hierarchisches Modell
Dieses Modell verwendet kodierte und dekodierte Felder von Längen ungleich Null. Das kodierte Feld repräsentiert eine statische Anhäufung (Cluster) von lokalen MPIC-Einheiten, während eine Bitposition in dem dekodierten Feld eine einzelne lokale MPIC-Einheit innerhalb des Clusters identifiziert. Beliebige Sätze von Prozessoren innerhalb eines Clusters können spezifiziert werden, indem das Cluster benannt wird und die Bits in dem dekodierten Feld für die ausgewählten Mitglieder in dem Cluster gesetzt werden. Dies unterstützt Systeme mit mehr als 32 Prozessoren und entspricht einer stoß(DASH)-artigen Cluster- Architektur. Ein Senden an sämtliche Ziele wird durch Setzen sämtlicher 32 Zielbits auf Eins erreicht. Dies garantiert eine Übereinstimmung bei sämtlichen Clustern und wählt sämtliche MPICs in jedem Cluster aus.
Beispiel 3 Bimodales Modell
Jeder Wert des kodierten Feldes ist der ID eines einzelnen lokalen MPIC. Dieser ID kann mit dem physischen MPIC-ID des MPIC identisch sein, aber dies muß nicht der Fall sein. Jedes Bit in dem dekodierten Feld stellt eine vordefinierte Gruppe dar. Dieses Schema gestattet die Adressierung einer einzelnen MPIC- Einheit durch Verwendung ihres ID in dem kodierten Feld (und die Auswahl keiner Gruppe) oder die Adressierung einer Gruppe (oder einer Vereinigung von Gruppen) von MPICs durch Setzen des kodierten Feldes auf eine Reihe von Einsen und Auswahl der Gruppen in dem dekodierten Feld. Jede MPIC-Einheit kann Mitglied mehrerer Gruppen sein. Das Unterstützen einer Aussendung an sämtliche Ziele erfordert in dem bimodalen Modell, daß Software eine Gruppe definiert, die sämtliche lokalen MPICs in dem System enthält. Eine Aussendung wird dann durch Setzen sämtlicher 32 Zielbits auf Eins erreicht. Dies führt zu einer Übereinstimmung mit sämtlichen einzelnen IDs und außerdem mit der Gruppe, die sämtliche lokale Einheiten enthält.
Jeder Prozessor hat eine Prozessorpriorität, die die relative Bedeutung der Task oder des Befehlscodes anzeigt, den der Prozessor gerade ausführt. Dieser Code kann Teil eines Prozesses oder einer Reihe (Thread) sein oder er kann ein Interrupt-Handler sein. Die Priorität wird mit dem Wechseln der Tasks dynamisch angehoben oder abgesenkt, wobei Interrupts geringerer Priorität unterdrückt (herausmaskiert) werden. Nach Bedienen eines IRQ kehrt der Prozessor zu einer zuvor unterbrochenen Aktivität zurück.
Ein Prozessor hat die geringste Priorität innerhalb einer gegebenen Gruppe von Prozessoren, wenn seine Prozessorpriorität die geringste sämtlicher Prozessoren in der Gruppe ist. Da innerhalb einer gegebenen Gruppe ein oder mehrere Prozessoren gleichzeitig die geringste Priorität haben können, ist deren Verfügbarkeit Gegenstand des Prozesses der Entscheidung.
Ein Prozessor ist der Focus eines Interrupts, wenn er gegenwärtig dieses Interrupt bedient oder wenn bei ihm gerade eine Anforderung für dieses Interrupt anhängig ist.
Ein wichtiges Merkmal der Erfindung ist das Garantieren einer Semantik des exakt-einmaligen Lieferns von Interrupts an das spezifizierte Ziel, welche die folgenden Attribute des Interrupt-Systems einschließt:
  • 1. Die Einspeisung eines Interrupts wird niemals zurückgewiesen;
  • 2. Interrupts (IRQs) gehen niemals verloren;
  • 3. im Falle der flankengetriggerten Interrupts wird das Auftreten des gleichen IRQ niemals mehr als einmal abgegeben, d. h., indem ein Interrupt zuerst an seinen Focus-Prozessor (wenn es gegenwärtig einen hat) geliefert wird, wird ein mehrfaches Auftreten des gleichen Interrupts, während das erste anhängig ist (seine Bedienung nicht abgeschlossen ist) jeweils als anhängig in dem Anhängigkeitsbit des lokalen MPIC- Interrupt-Anforderungs-Register (IRR's) aufgezeichnet, das der speziellen Interruptanforderung entspricht;
  • 4. für pegelaktivierte Interrupts wird der Zustand des Interrupt-Pins des I/O-MPIC an dem Anhängigkeitsbit des lokalen Ziel-MPIC-IRR jedesmal neu hergestellt, wenn sein Zustand von dem Zustand des I/O-MPIC-Interrupt- Eingangspins abweicht, wobei der lokale Ziel-MPIC nur dann das gleiche IRQ bei Ausführung eines Ende-des- Interrupt(EOI)-Signals initiiert, wenn der Prozessor nicht explizit seine Aufgabenpriorität erhöht.
Das bevorzugte Ausführungsbeispiel unterstützt zwei Moden für die Umadressierung dieses eingehenden IRQ und für die Auswahl des Zielprozessors: den festen statischen Modus und den dynamischen Modus der geringsten Priorität. Diese und andere mögliche von Betriebssystem unterstützte Moden werden von den folgenden Informationen gestützt:
  • 1. MPIC-ID's, die bei jeder MPIC-Einheit bekannt sind,
  • 2. Ziel-Adreßfeld von der Umadressiertabelle des I/O-MPIC,
  • 3. die MPIC-Einheit-Adresse; jede MPIC-Einheit kennt ihre eigene Adresse,
  • 4. ob eine MPIC-Einheit gegenwärtig der Focus des Interrupts ist und
  • 5. die Priorität sämtlicher Prozessoren.
Der feste Modus ist das einfachste Verfahren. Das Interrupt wird von dem I/O-MPIC unbedingt an sämtliche MPICs ausgesendet, die in dem Zieladressfeld für das spezielle IRQ kodiert sind, wobei typischerweise ein einzelner lokaler MPIC benannt ist. Prioritätsinformationen werden ignoriert. Wenn der Zielprozessor nicht verfügbar ist, wird das Interrupt an dem lokalen MPIC des Zielprozessors anhängig gehalten, bis die Priorität des Prozessors niedrig genug ist, daß der lokale MPIC das Interrupt an den Prozessor verteilen kann. Eine feste Umadressierung führt zu:
  • 1. einer statischen Verteilung über sämtliche Prozessoren; und
  • 2. einer Zuweisung eines speziellen lokalen MPIC zu einem gegebenen Interrupt.
Eine feste Umadressierung erlaubt existierenden gereihten (single threaded) Gerätetreibern, in einer Multiprozessorumgebung zu funktionieren, vorausgesetzt daß die Software den Treibercode bindet, auf einem Prozessor zu laufen, und daß die MPIC-Einheit für einen festen Abgabe-Modus programmiert ist, so daß das Interrupt des Geräts an denselben Prozessor gerichtet wird, auf welchem der Treiber abgearbeitet wird.
Der Umadressier-Modus der geringsten Priorität veranlaßt den in einer Gruppe verfügbaren Prozessor der geringsten Priorität, der von dem Umadressier-Adreßfeld spezifiziert ist, das Interrupt zu bedienen. Da jeder dieser lokalen MPIC dieser Prozessoren der geringsten Priorität die Priorität der ihnen zugeordneten Prozessoren kennt, wird ein Entscheidungsprotokoll auf dem MPIC-Bus ausgeführt, um die geringste Priorität zu bestimmen.
Wenn mehr als ein Prozessor auf der geringsten Priorität betrieben wird, dann kann einer von ihnen zufällig (statistisch) ausgewählt werden. Ein zusätzlicher Prozessor- Auswahl-Algorithmus wird auf die verbliebenen Kandidaten der Prozessoren der geringsten Priorität zur zufälligen Auswahl eines Prozessors angewendet mit der Aufgabe der gleichförmigen Verteilung der Interrupt-Bedienungstask unter diesen Prozessoren der geringsten Priorität.
C. STRUKTURBESCHREIBUNG
Die I/O-MPIC-Einheit 102 gemäß Fig. 2 ist detaillierter in Fig. 3 dargestellt. Die Interrupt-Eingabeleitungen 107 stellen für die I/O-Geräte das Mittel zum Einspeisen ihrer Interrupts zur Verfügung. Ein Flankenfilter 108 wird verwendet, um an den Eingabepins saubere Pegelübergänge herzustellen. Die Umadressiertabelle 109 hat für jedes Interrupt-Eingabepin (Leitung) 107 einen speziellen 64-Bit-Eintrag. Im Unterschied zu den bekannten IRQ-Pins des zuvor erörterten 82C59A/82380-PIC steht der Begriff der Interrupt-Priorität in keinem Zusammenhang zu der Position des physischen Interrupt-Eingabe- Pins an der I/O-MPIC-Einheit gemäß der Erfindung. Die Priorität jedes Eingabepins 107 ist durch Software programmierbar, indem ein 8-Bit-Vektor in dem entsprechenden Eintrag der Umadressier- Tabelle 109 zugewiesen wird.
Fig. 4 zeigt das Format jedes 64-Bit-Eintrags der Umadressiertabelle. Jeder Eintrag läßt sich folgendermaßen beschreiben:
Vektor (0 : 7): Ein den Interrupt-Vektor enthaltendes 8-Bit-Feld.
Abgabe-Modus (8 : 10): Ein 3-Bit-Feld, das angibt, wie sich die in dem Zielfeld aufgelisteten lokalen MPICs bei Empfang dieses Signals verhalten sollen und was folgende Bedeutungen haben kann:
000 - fest - Abgabe an sämtliche am Ziel aufgelistete Prozessoren.
001 - geringste Priorität - Abgabe an den Prozessor mit der geringsten Priorität von sämtlichen in dem Ziel aufgelisteten Prozessoren.
011 - Fern-Lesen - Anfordern des Inhalts eines MPIC-Einheit- Registers, dessen Adresse sich in dem Vektorfeld befindet und der in dem Fern-Register für einen Zugriff durch den lokalen Prozessor gespeichert werden soll; flanken-getriggerter Modus.
100 - NMI - Abgabe an das nicht maskierbare-Interrupt (NMI)-Pin sämtlicher aufgelisteter Prozessoren, wobei die Vektor- Information ignoriert wird; Behandlung als flanken­ sensitives Signal.
101 - Rücksetzen - Abgabe an sämtliche aufgelisteten Prozessoren durch Anlegen/Wegnahme des Rücksetz- Pins der Prozessoren; Setzen sämtlicher adressierter Pins lokal.
110 - Fehlerbeseitigung (Debug) - Abgabe an alle aufgelisteten Prozessoren durch Anlegen/Wegnahme des Fehlerbeseitigungs-Pins der lokalen MPICs; wird als ein pegelsensitives Signal behandelt.
111 - Ext.INT - Abgabe an die INT- Pins sämtlicher aufgelisteter Prozessoren als ein von einem extern angekoppelten 8259A- kompatiblen Interrupt- Controller ausgehendes Interrupt; wird als ein pegelsensitives Signal behandelt.
(Zu beachten ist, daß die Abgabe-Moden des Rücksetzens, der Fehlerbeseitigung und des externen Interrupts (Ext.INT) sich nicht auf I/O-Geräte-Interrupts beziehen. Rücksetzen und Fehlerbeseitigung sind Zwischen-Prozessor-Interrupts, während der Ext.INT-Modus enthalten ist, um die Kompabilität mit dem existierenden de-facto-Standard des 8259A-PIC herzustellen.)
Zielmodus (11): Interpretiert das Zielfeld:
0 - Physischer Modus - verwendet MPIC-ID in den Bits 56 : 63
1 - Logischer Modus - das 32- Bit-Feld ist das logische Ziel, das durch das Betriebssystem definiert wird.
Abgabe-Status (12): Ein durch Software nur-lesbares 2-Bit-Feld, das den aktuellen Abgabe-Status des Interrupts enthält.
0 - untätig - keine aktuelle Aktivität,
1 - Senden anhängig - Interrupt eingespeist in den lokalen MPIC; aufrechterhalten durch andere eingespeiste Interrupts. Dieses Bit ist durch Software nur lesbar, d. h. 32-Bit- Software-Schreiboperationen in die Umadressiertabelle 109 beeinflussen dieses Bit nicht.
Fern-IRR (14): Spiegelt das Interrupt- Anforderungs-Register(IRR)-Bit des lokalen Ziel-MPIC nur für pegelsensitive Interrupts, und wenn der Status des Bits nicht mit dem Zustand der entsprechenden Interrupt- Eingabeleitung 107 übereinstimmt, wird eine I/O- MPIC-Nachricht gesendet, um das IRR-Bit des Ziels den neuen Zustand reflektieren zu lassen, was das Fern-IRR-Bit (lokaler MPIC) zum Verfolgen veranlaßt. Dieses Bit ist durch Software nur lesbar.
Trigger-Modus (15): Zeigt das Format des Interrupt- Signals an.
0 - flankensensitiv
1 - pegelsensitiv
Maskierung (16): Zeigt den Maskierungszustand an:
0 - nicht maskiertes Interrupt (NMI)
1 - maskiertes Interrupt, was durch Aufgaben (Tasks) höherer Priorität blockiert werden kann.
Ziel (32:63) 32-Bit-Feld, das das durch das Betriebssystem definierte Interrupt-Ziel repräsentiert. Der untere Teil der Fig. 4 zeigt die zwei zuvor erörterten möglichen Formate: Ein physisches (dekodiertes) 32- Bit-Format, das ein Bit pro Ziel-Prozessor verwendet, und ein logisches 8/24-Bit-Format mit 8 kodierten Bits und 24 dekodierten Bits, das einen zweidimensionalen 256 × 24- Ziel-Raum definiert.
Die 64-Bit breite Umadressier-Tabelle 109 ist lese- /schreib-zugreifbar über die 32-Bit-Adreß- und 32 Datenleitungen, DATEN/ADR. 106, eines Wirtsprozessors mit Ausnahme der Abgabe-Status- und der Fern-IRR-Bits, welche - wie oben angemerkt wurde - durch Hardware geschrieben und durch Software nur gelesen werden können.
Von der MPIC-Bus-Sende/Empfangs-Einheit 110 werden die Umadressiertabellen-Einträge formatiert und an sämtliche lokale MPIC-Einheiten 104 ausgesendet. Das MPIC-Bus(103)-Protokoll spezifiziert einen 5-adrigen synchronen Bus, 4 Leitungen für Daten und eine Leitung für seinen Takt. Spezielle Details des Nachrichtenformats werden im Abschnitt über das MPIC-Bus- Protokoll offenbart. Eine Annahme resultiert im Rücksetzen des Abgabe-Status auf untätig bzw. leer.
Die lokale MPIC-Einheit 104 ist verantwortlich für die Interrupt-Aufnahme, das Verteilen der Interrupts an den Prozessor und das Senden von Zwischen-Prozessor-Interrupts.
In Abhängigkeit von dem in dem Umadressiertabellen-Eintrag des Interrupts spezifizierten Interrupt-Abgabe-Modus können mehrere, eine oder keine MPIC-Einheiten ein Interrupt annehmen. Eine lokale MPIC nimmt ein Interrupt nur dann an, wenn sie es an ihren zugeordneten Prozessor weitergeben kann. Das Annehmen eines Interrupts ist allein eine Sache des I/O-MPIC 102 und des lokalen MPIC 104, während das Verteilen eines Interrupts an einen Prozessor nur einen lokalen MPIC 104 und seinen lokalen Prozessor 105 involviert.
Die Umadressier-Tabelle 109 der I/O-MPIC-Einheit 102 dient zum Lenken der Interrupts, die von dem I/O-Subsystem 101 ausgehen und durch Senden des einem gegebenen Interrupt entsprechenden Eintrags der Umadressier-Tabelle über den MPIC- Bus 103 vielleicht an einen Prozessor gerichtet werden sollen.
Fig. 5 zeigt im Detail die Strukturelemente der lokalen MPIC-Einheit 104. Die lokale Vektor-Tabelle 210 ist in ihrer Funktion ähnlich der I/O-MPIC-Umadressiertabelle 109; im Unterschied zu dieser ist sie jedoch nur auf solche Interrupts beschränkt, die sich auf den zugeordneten lokalen Prozessor beziehen. Die lokale Vektor-Tabelle 210 enthält sechs 32-Bit- Einträge. Die Einträge 200 bis 202 entsprechen den Zeitgebern 0 bis 2; die Einträge 203 und 204 entsprechen den lokalen Interrupt-Eingabepins und der Eintrag 205 steuert die Interrupt-Erzeugung für Daten-Paritätsfehler. Die Bits höherer Ordnung in den Zeitgeber-Einträgen 200 bis 202 enthalten zeitgeberspezifische Felder, die in den anderen Einträgen nicht vorhanden sind (wie detaillierter bei der späteren Erörterung über die Zeitgeber dargelegt wird).
Obwohl die Fig. 2 und 5 die lokale MPIC-Einheit 104 als eine separate Einheit zeigen, kann sie teilweise oder insgesamt in den zugeordneten Prozessor bzw. das Prozessorchip 105 integriert sein. Dies kann der Fall sein, um die Effizienz der Kommunikation zwischen der lokalen MPIC-Einheit 104 und dem zugeordneten Prozessor 105 zu verbessern. Beispielsweise kann die Integration der die Einheiten 203 und 204 enthaltenden lokalen Interrupt-Vektor-Tabelle der lokalen MPIC-Einheit einen direkteren Pfad zum Cache-Speicher schaffen und somit das Flushing eines Cache-Speicher-Übersetzungs-Nachschlag-Puffers beschleunigen.
Fig. 6 definiert die verschiedenen Felder, die den Einträgen 200 bis 205 der lokalen Vektor-Tabelle zugeordnet sind.
Vektor (0:7): Ein den Interrupt-Vektor enthaltendes Bit-Feld
Abgabe-Modus (DELV)(8:10): Ein 3-Bit-Feld, das die gleiche Bedeutung wie in der Umadressier-Tabelle 109 hat mit dem Unterschied, daß geringste Priorität (001) synonym mit fest (000) ist.
Fern-IRR (R)(14): Dieses Bit spiegelt das IRR-Bit des Interrupts dieser lokalen MPIC-Einheit. Es wird ausschließlich für pegelgetriggerte lokale Interrupts verwendet, ist für flankengetriggerte Interrupts undefiniert und ist durch Software nur lesbar.
Trigger-Modus (TM)(15): 0 zeigt ein flankensensitives Triggern an. 1 zeigt ein pegelsensitives Interrupt an. Die lokalen Interrupt-Pins (203, 204) können wie andere flanken- oder pegelgetriggert programmiert sein, während dagegen die Zeitgeber (200 : 202) und die Parität (205) stets flankensensitiv sind.
Maskierung (MS)(16): 0 gibt Interrupt frei, 1 maskiert Interrupt.
Modus (M)(17): Wählt den Modus des Zeitgebers aus; 0 bedeutet monostabil, 1 bedeutet periodisch.
Basis (18:19): Wählt eine von drei Zeitbasen für die Zähler aus.
(Modus und Basisparameter werden an späterer Stelle im Abschnitt über die Zeitgeber-Architektur näher erörtert werden.)
Ein Prozessor erzeugt Zwischen-Prozessor-Interrupts, indem er in das 64-Bit-Interrupt-Befehlsregister 220 schreibt, dessen Layout ähnlich dem der I/O-MPIC-Umadressier-Tabelle 109 ist. Das programmierbare Format, das sehr ähnlich dem eines Eintrags in der Umadressier-Tabelle 109 ist, ist in Fig. 7 gezeigt. Es gestattet jedem Prozessor, ein beliebiges Interrupt zu erzeugen, wobei einem Prozessor gestattet wird, ein von ihm ursprünglich angenommenes Interrupt an andere Prozessoren weiterzuleiten. Dieses Merkmal ist außerdem für die Fehlerbeseitigung nützlich. Das Interrupt-Befehlsregister 220 ist durch Software schreib-/lesbar.
Vektor (0:7): Identifiziert das gerade gesendete Interrupt.
Abgabe-Modus (8:10): Gleiche Interpretation wie bei der Umadressier-Tabelle 109.
Ziel-Modus (11): Gleiche Interpretation wie bei der Umadressier-Tabelle 109.
Abgabe-Status (12): Gleiche Interpretation wie bei der Umadressier-Tabelle 109. Der lokale Prozessor setzt den Status, der den lokalen MPIC aktualisiert. Software kann dieses Feld lesen, um herauszufinden, ob das Interrupt gesendet worden ist, und wenn dies der Fall ist, ist das Interrupt Befehlsregister 220 zum Annehmen eines neuen Interrupts bereit. Wenn das Register 220 überschrieben wird, bevor der Abgabe-Status untätig (0) ist, dann ist der Status dieses Interrupts undefiniert (kann oder kann nicht angenommen worden sein).
Pegel-Wegnahme (14): Ein Bit wird in Verbindung mit dem Trigger-Modus (15) verwendet, um das Anlege/Wegnehmen des pegelsensitiven Interrupts (0 - Wegnehmen, 1 - Anlegen) zu simulieren. Ein Abgabe-Modus bei Rücksetzen, ein Trigger- Modus bei Pegel und eine Pegel- Wegnahme bei 1 ergibt beispielsweise ein Wegnehmen des Rücksetzen von dem Prozessor des adressierten MPIC. Diese Bedingung veranlaßt außerdem sämtliche MPICs, ihren Entscheidungs-ID (der zum Tie- Break bei der Entscheidung der geringsten Priorität verwendet wird) auf den MPIC-ID zurückzusetzen.
Trigger-Modus (15): Gleich dem der Umadressier- Tabelle 109.
Fern-Lese-Status (16:17): Zeigt den Status der in dem Fern-Leseregister 224 enthaltenen Daten an:
00 - ungültig - Inhalt des Fern-Leseregisters 224 ist ungültig, Fern-MPIC- Einheit ist nicht in der Lage auszugeben.
01 - voranschreitend - Fern- Lesen läuft ab und erwartet Daten.
10 - gültig - Fern-Lesen ist abgeschlossen, gültige Daten.
Ziel-Kurzcharakterisierung (18:19) Ein 2-Bit-Feld, das verwendet wird, um ein Ziel anzugeben ohne die Notwendigkeit, das 32- Bit-Ziel-Feld zur Verfügung zu stellen. Dies reduziert den Software-Mehraufwand, indem eine dem Bit-Feld 32:63 entsprechende zweite 32-Bit- Schreiboperation für die folgenden allgemeinen Fälle nicht erforderlich ist:
  • a) Software-Selbst-Interrupt,
  • b) Interrupt zu einem einzelnen festen Ziel,
  • c) Interrupt zu sämtlichen Prozessoren, die im Ziel- Feld (32:63) benannt werden können, einschließlich dem sendenden Prozessor.
Der 2-Bit-Code wird wie folgt interpretiert:
00 - keine Kurzform, verwendet das Ziel-Feld (32 : 63).
01 - selbst, der aktuelle MPIC ist das einzige Ziel (das für Software- Interrupts verwendet wird).
10 - alle einschließlich selbst.
11 - alle außer selbst, wird während des Rücksetzens und der Fehlerbe­ seitigung verwendet.
Ziel (32:63): Durch das Betriebssystem definiert; das gleiche wie für Umadressier-Tabelle 109. Wird nur dann verwendet, wenn Ziel- Kurzform auf Ziel-Feld (00) gesetzt ist.
Die I/O-MPIC-Einheit 102 und sämtliche lokalen MPIC- Einheiten 104 empfangen Nachrichten über den MPIC-Bus 103. Die MPIC-Einheit überprüft zuerst, ob sie zu dem Ziel in der Nachricht gehört. Beispielsweise in dem Fall des zuvor zitierten 32-Bit-Zielformats verwendet jede MPIC-Einheit mit einem ID-Wert im MPIC-ID-Register 222, der kleiner als 32 ist, ihren MPIC-ID, um in die 32-Bit-Ziel-Matrix zu indexieren. Wenn sie ihr Bit gesetzt vorfindet, dann ist die MPIC-Einheit von dieser Nachricht adressiert. Im Fall des 8 × 24-Formats überprüft jede MPIC-Einheit, ob ihr MPIC-ID gleich dem MPIC-ID in dem 32- Bit-Zielfeld ist, oder wenn sie ein Mitglied der Gruppenliste ist (wie es in Fig. 7 gezeigt ist) durch bitweise UND-Operation ihres 24-Bit-Gruppenlistenregisters (32 : 55) mit der Gruppenliste in der Nachricht und eine ODER-Operation sämtlicher resultierender Bits. Wenn der MPIC-ID in der Nachricht einen Wert von 255 hat, dann ist die MPIC-Einheit von der Nachricht ebenso adressiert.
Die MPIC-Bus-Sende/Empfangs- und Entscheidungseinheit 226 (Fig. 5) richtet die Ziel und die Modus-Informationen auf dem Ausgang 267 an die Annahme bzw. Akzeptanz-Logikeinheit 248, welche die logischen Operationen in Verbindung mit dem Inhalt des MPIC-ID-Registers 222 ausführt. Wenn die Nachricht akzeptiert wird, wird die am Ausgang 266 der Einheit 226 verfügbare Vektor-Information dekodiert und zusammen mit der Modus-Information von der Vektor-Dekodiereinheit 228 zu der 3 × 256-Bit-Vektormatrix 230 weitergeleitet. Wenn der 8-Bit- Interrupt-Vektor von dem Vektor-Dekodierer 228 dekodiert worden ist, bestimmt er, welche Bit-Position von 256 möglichen Bit- Positionen gesetzt wird, um die Interrupt-Priorität anzuzeigen. Wenn ein Interrupt bedient wird, werden alle Interrupts gleicher oder geringerer Priorität automatisch von der Prioritätseinheit 240 maskiert.
Die 3 × 256-Bit-Vektormatrix 230 besteht aus 256-Bit- Vektoren, die zum Speichern Interrupt-bezogener Informationen verwendet werden. Jedes Register ist durch Software nur lesbar und durch Hardware les-/schreibbar. Die Register sind wie folgt definiert:
ISR, Interrupt-Bedienungsregister 231; zeigt Interrupts, die gegenwärtig bedient werden und für welche kein Ende-des- Interrupt(EOI)-Signal von dem Prozessor gesendet worden ist;
IRR, Interrupt-Anforderungsregister 232; enthält die von der lokalen MPIC-Einheit angenommen aber noch nicht an den Prozessor ausgeteilten Interrupts;
TMR, Trigger-Modus-Register 234; zeigt an, ob das Interrupt zur pegel- oder flankensensitiven Art gehört, wie dies von dem Trigger-Modus-Bit in dem Umadressier-Tabelleneintrag der sendenden MPIC-I/O-Einheit übertragen wurde.
Wenn begonnen wird, ein Interrupt zu bedienen, und das TMR- Bit 0 ist, was den Flankentyp anzeigt, dann wird das entsprechennde IRR-Bit gelöscht und das entsprechende ISR-Bit gesetzt. Wenn das TMR-Bit 1 ist, was den Pegeltyp anzeigt, dann wird das IRR-Bit nicht gelöscht, wenn begonnen wird, das Interrupt zu bedienen (ISR-Bit gesetzt). Statt dessen spiegelt das IRR-Bit den Zustand des Eingabepins des Interrupts. Wie zuvor erörtert, erfaßt der Quell-I/O-MPIC die Diskrepanz und sendet eine Nachricht an die lokale Ziel-MPIC-Einheit, um deren IRR-Bit zu löschen, wenn das pegelgetriggerte Interrupt weggenommen wird.
Fig. 8 zeigt anhand eines Beispiels, wie das Fern-IRR und das IRR-Bit an der lokalen Ziel-MPIC-Einheit den Zustand des Interrupt-Eingangssignals (INTIN) verfolgen. Es wird außerdem veranschaulicht, wie einem EOI sofort ein Neuanlegen des Interrupts folgt, solange das INTIN noch von irgendeinem Gerät angelegt ist. Bei diesem Beispiel wird angenommen, daß zwei Geräte, A und B, sich einen pegelgetriggerten Interrupt-Eingang zu dem I/O-MPIC teilen. Gerät A erhebt ein Pegel-Interrupt, wie im Signalverlauf (a) gezeigt ist, gefolgt von einem Interrupt des Gerätes B, wie im Signalverlauf (b) gezeigt ist. Das resultierende Signal INTIN ist die ODER-Kombination der Signalverläufe (a) und (b) und ist im Signalverlauf (c) gezeigt. Die MPIC-Bus-Sende/Empfangs-Einheit 110 gemäß Fig. 3 bildet eine Exklusiv-ODER-Verknüpfung (XOR) des Signals INTIN mit dem als Signalverlauf (e) gezeigten Fern-IRR-Bit, dem Bit 14 der Umadressier-Tabelle 104, was das im Signalverlauf (d) gezeigte "Pegel-angelegt" und "Pegel-weggenommen" ergibt. Das IRR-Bit des lokalen MPIC verfolgt, wie im Signalverlauf (f) gezeigt, den Zustand des Signalverlaufs (e). Der Signalverlauf (g) demonstriert, wie auf ein EOI unmittelbar ein erneutes Anlegen des Interrupts folgt, solange das Signal INTIN noch von einem der Geräte angelegt ist.
Fig. 9 ist ein Flußdiagramm, das den Interrupt- Annahmeprozess einer lokalen MPIC-Einheit darstellt. Bei Empfang einer Nachricht ist eine lokale MPIC-Einheit der aktuelle Focus, d. h., das zugehörige IRR- oder ISR-Bit ist anhängig; sie akzeptiert das Interrupt unabhängig von der Priorität und signalisiert den anderen lokalen MPICs, die Prioritäts-Entscheidung abzubrechen. Dies verhindert das Auftreten einer mehrfachen Abgabe des gleichen Interrupts an unterschiedliche Prozessoren, was konsistent mit der bekannten Interrupt-Abgabe-Semantik in Einprozessor-Systemen ist. Wenn eine lokale MPIC-Einheit gegenwärtig nicht der Focus ist, wartet sie auf die Akzeptanz durch einen anderen lokalen MPIC. Wenn mehr als ein MPIC verfügbar ist, wird eine Entscheidung aufgerufen, wie sie unter dem Abschnitt mit dem Titel MPIC-Bus- Protokoll beschrieben ist, um die Gewinner-Einheit (geringste Priorität) festzustellen.
Wenn eine Nachricht als NMI, Fehlerbeseitigung (Debug) oder Rücksetzen gesendet wird, dann erfolgt durch sämtliche in dem Ziel aufgelistete Einheiten ein unbedingtes Anlegen/Wegnehmen des NMI-Ausgabepins 263, des Fehlerbeseitigungspins 263 bzw. des Rücksetz-Pins 265 ihres Prozessors gemäß Fig. 5. ISR 231 und IRR 232 werden umgangen und die Vektor-Information ist undefiniert.
Das Task-Prioritäts-Register (TPR) 242 gemäß Fig. 5 speichert die aktuelle Priorität der Task seines Prozessors, welche dynamisch aufgrund von expliziter Software-Aktivitäten einer Änderung unterworfen ist, so beispielsweise wenn Tasks umgeschaltet werden und bei Eintreten oder Rückkehren aus einem Interrupt-Handler. TPR 242 ist ein 32-Bit-Register, das mit Hilfe eines 8-Bit-Feldes (0:7) bis zu 256 Prioritätsebenen unterstützt. Die vier am höchsten bewerteten Bits (4:7) entsprechen den 16 Interrupt-Prioritäten, während die vier am geringsten bewerteten Bits (0:3) eine zusätzliche Auflösung zur Verfügung stellen. Beispielsweise kann ein TPR-Wert mit Nullen in den fünf am höchsten bewerteten Bits und ungleich Null in den drei am geringsten bewerteten Bits verwendet werden, um eine Task-Ablaufplan-Klasse zwischen 0 (untätig) und 1 zum Zwecke des Zuweisens eines Interrupts zu beschreiben. Dies ist insbesondere dann nützlich, wenn eine Anzahl von Prozessoren auf der gleichen niedrigsten Ebene der Priorität arbeitet.
Die Priorität eines Prozessors wird gewonnen aus dem TPR 242, dem ISR 231 und dem IRR 232. Das Maximum seiner Task- Priorität, die Priorität des ISR-Bits höchster Ordnung und die Priorität des höchsten IRR-Bits werden alle unter Verwendung der vier am höchsten bewerteten Bits ihrer kodierten 8-Bit- Darstellung bewertet. Dieser Wert, der bei der Bestimmung der Verfügbarkeit eines lokalen MPIC zum Akzeptieren eines Interrupts und bei der Bestimmung der lokalen MPIC-Einheit mit der geringsten Priorität verwendet wird, wird in Echtzeit berechnet, wenn erforderlich.
Sobald ein lokaler MPIC ein Interrupt akzeptiert hat, garantiert er die Weitergabe des Interrupts an seinen lokalen Prozessor. Die Weitergabe eines markierbaren Interrupts wird von dem INT/INTA-Protokoll gesteuert, welches mit dem Anlegen des INT-Pins 262 durch die lokale MPIC-Einheit beginnt, wobei das INT-Pin 262 mit dem Prozessor-INT-Pin verbunden ist. Wenn der Prozessor Interrupts freigegeben hat, antwortet er durch Ausgabe eines INTA-Zyklus auf Leitung 261, was den lokalen MPIC veranlaßt, seinen interen Prioritätszustand einzufrieren und den 8-Bit-Vektor des Interrupts der höchsten Priorität auf den Prozessor-Datenbus 106 auszugeben. Der Prozessor liest den Vektor und verwendet ihn, um die Einsprungstelle des Interrupt- Handlers zu finden. Außerdem setzt der lokale MPIC das ISR-Bit des Interrupts. Das entsprechende IRR-Bit wird nur dann gelöscht, wenn das TMR 234 ein flankengetriggertes Interrupt anzeigt, wie zuvor erörtert wurde.
Wenn ein pegelgetriggertes Interrupt unmittelbar vor seinem INTA-Zyklus weggenommen wurde, kann es sein, daß sämtliche IRR- Bits gelöscht sind und die Prioritätseinheit 240 keinen Vektor zur Abgabe an den Prozessor über den Datenbus 106 findet. Statt dessen gibt die Prioritätseinheit 240 einen Unerwünscht- Interrupt-Vektor(SIV) zurück. Die Weitergabe des (SIV) beeinflußt ISR 231 nicht, so daß der Interrupt-Handler ohne Ausgabe eines EOI zurückkehren sollte. Der SIV ist über das SIV-Register innerhalb der Prioritätseinheit 240 programmierbar.
Es ist möglich, daß lokale MPIC-Einheiten in dem System existieren, die keinen Prozessor haben, zu welchem sie Interrupts weiterleiten können. Die einzige Gefahr, die dies in dem System darstellt, besteht darin, daß es eine Möglichkeit gibt, daß eine lokale MPIC-Einheit ohne Prozessor das Interrupt akzeptieren kann, wenn ein Interrupt zu sämtlichen Prozessoren unter Verwendung des Abgabe-Modus der geringsten Priorität ausgesendet wird, sämtliche Prozessoren auf der geringsten Priorität sind und wenn die betreffende MPIC-Einheit zu dem Zeitpunkt den geringsten Entscheidungs-ID hat. Um zu vermeiden, daß dies auftritt, werden sämtliche lokale Einheiten in dem gesperrten Zustand initialisiert und müssen explizit freigegeben werden, bevor sie damit beginnen können, MPIC- Nachrichten von dem MPIC-Bus anzunehmen. Eine gesperrte lokale MPIC-Einheit antwortet nur auf Nachrichten, bei denen der Abgabe-Modus auf "Rücksetzen" gesetzt ist.
Rücksetzen/Wegnehmen-Nachrichten sollten im physischen Ziel- Modus unter Verwendung des MPIC-ID des Ziels gesendet werden, weil die logische Ziel-Information in dem lokalen MPIC undefiniert ist (alles Nullen), wenn der lokale MPIC aus dem Rücksetzvorgang herauskommt.
Bevor die Software aus einem Interrupt-Handler zurückkehrt, muß sie durch Schreiben in das EOI-Register 246 einen Ende-des- Interrupt(EOI)-Befehl an ihren lokalen MPIC ausgeben, wobei das höchste Prioritäts-Bit im ISR 231 gelöscht wird, wodurch angezeigt wird, daß das Interrupt nicht länger bedient wird, und was den MPIC veranlaßt zur Aktivität der nächsthöheren Priorität zurückzukehren.
Das MPIC-System wird in der folgenden Weise initialisiert:
  • a) Jede MPIC-Einheit hat ein Rücksetz-Eingangspin, das mit einer gemeinsamen Rücksetzleitung verbunden ist und von dem System-Rücksetzsignal aktiviert wird.
  • b) Die acht am geringsten bewerteten Bits des Datenbus 106 werden in dem MPIC-ID-Register 222 zwischengespeichert.
  • c) Jedes lokale MPIC legt sein Prozessor-Rücksetz-Pin 265 (RST) an und setzt sämtliche internen MPIC Register auf ihren Anfangszustand zurück, d. h., daß die Umadresser- Tabelle 109 und die lokale Vektortabelle 210 so gesetzt werden, daß sie die Interrupt-Akzeptanz markieren, und anderenfalls den Registerzustand auf Null setzen.
  • d) Jeder lokale MPIC nimmt sein Rücksetz-Pin des Prozessors weg, um dem Prozessor zu gestatten, einen Selbsttest durchzuführen und einen Initialisierungscode auszuführen:
  • e) Der erste auf den MPIC-Bus 103 gelangte Prozessor zwingt andere Prozessoren in das Rücksetzen, indem er ihnen das Zwischen-Prozessor-Interrupt sendet mit
    Abgabe-Modus = Rücksetzen
    Trigger-Modus = Pegel
    Pegel-Wegnahme = 0
    Ziel-Kurzform = Alle Außer Selbst
    sämtliche anderen Prozessoren werden im Rücksetz-Modus gehalten bis das Betriebssystem des arbeitenden Prozessors ihnen erlaubt, aktiv zu werden.
  • f) Der einzige arbeitende Prozessor führt den größten Teil der Systeminitialisierung und -Konfiguration aus und lädt (bootet) ggf. ein Betriebssystem, welches ein Wegnahme/Rücksetz-Signal aussendet, um die anderen Prozessoren zu aktivieren.
D. MPIC-Bus-Protokoll
Der MPIC-Bus 103 ist ein synchroner 5-Draht-Bus, der den I/O-MPIC und die lokalen MPIC-Einheiten verbindet. Vier dieser Drähte dienen der Datenübertragung und der Zuteilungsentscheidung, während einer eine Taktleitung ist.
Elektrisch ist der Bus durch ein verdrahtetes ODER verbunden, was sowohl die Bus-Verwendungsentscheidung als auch die Geringste-Priorität-Entscheidung ermöglicht. Aufgrund der verdrahteten ODER-Verbindung arbeitet der Bus auf einer hinreichend geringen Geschwindigkeit, so daß eine entwurfsspezifische Abschluß-Abstimmung nicht erforderlich ist. Außerdem muß die Bus-Geschwindigkeit eine ausreichende Zeit bei einem einzelnen Bus-Zyklus zur Verfügung stellen, um den Bus zwischenzuspeichern und einige einfache logische Operationen an der zwischengespeicherten Information auszuführen, um zu bestimmen, ob der nächste Antriebs-Zyklus verhindert werden muß. Bei einer Busgeschwindigkeit von 10 MHz könnte ein Interrupt, das keine Entscheidung erfordert, in ungefähr 2,3 µs abgegeben werden und eines mit Prioritäts-Entscheidung in ungefähr 3,4 µs.
Die MPIC-Einheiten 102 und 104 haben separate MPIC-Bus- Eingangs- und -Ausgangspins, welche in einer nicht-entkoppelten Konfiguration, wie sie in Fig. 11 gezeigt ist, direkt verbunden sein können. Tri-State-Eingangspuffer 301 und Ausgangspuffer 302 können verwendet werden, um eine hierarchische Verbindung zu solchen MPIC-Bussen zur Verfügung zu stellen, von denen verlangt wird, daß sie eine große Anzahl von Prozessoren unterstützen (s. Fig. 12).
Die Entscheidung für eine Verwendung des MPIC-Bus 103 und zur Bestimmung der MPIC-Einheit geringster Priorität hängt von sämtlichen synchron arbeitenden MPIC-Nachrichteneinheiten ab. Eine verteilte Busentscheidung wird verwendet, um dem Fall zu behandeln, wenn mehrere Teilnehmer die Übertragung gleichzeitig starten. Die Busentscheidung verwendet eine geringe Anzahl von Entscheidungszyklen auf dem MPIC-Bus. Während dieser Zyklen fallen die Verlierer des Entscheidungswettbewerbs zunehmend vom Bus weg, bis nur ein "Gewinner" weiter sendet. Sobald das Senden einer Nachricht (einschließlich der Bus-Entscheidung) gestartet wurde, muß jeder mögliche Konkurrent die Übertragung unterdrücken, bis genug Zyklen vergangen sind, so daß die Nachricht vollständig gesendet werden konnte. Die Anzahl der verwendeten Buszyklen hängt von der Art der gesendeten Nachricht ab.
Ein Busentscheidungszyklus startet damit, daß der Teilnehmer seinen MPIC-ID auf den MPIC-Bus treibt, beginnend mit den Bits höherer Ordnung. Genauer gesagt wird der 8-Bit- MPIC-ID (0:7) in aufeinanderfolgende Gruppen von 2 Bits (I7:I6)(I5:I4)(I3:I2)(I1:I0) zerhackt. Diese Tupels I(i + 1):I(i) werden dann sequenziell dekodiert um ein 4-Bit-Muster (B0:B3) zu erzeugen, wie es in Fig. 13 gezeigt ist. Die Bits (B0:B3) werden, 1 Bit pro Leitung, auf die vier MPIC-Busleitungen aufgeprägt. Aufgrund der verdrahteten ODER-Verbindung zu dem MPIC-Bus wird jedes Tupel des ID nur an einen einzigen Draht angelegt, was es für einen Teilnehmer möglich macht, mit Sicherheit festzustellen, ob er wegfallen ("verlieren") oder den Entscheidungswettbewerb im nächsten Zyklus für die folgenden 2 Bits des MPIC-ID fortsetzen soll, indem er einfach überprüft, ob der Busleitungs-Teilnehmer, der den Bus antreibt, ebenfalls der der höchsten Ordnung 1 auf dem Bus ist. Auf diese Weise entscheidet jeder MPIC-Buszyklus 2 Bits.
Der Entscheidungswettbewerb wird außerdem verwendet, um die lokale MPIC-Einheit mit der geringsten Prozessor-Priorität zu finden. Die Geringste-Priorität-Entscheidung verwendet den Wert des Prozessor-Prioritäts-Registers des MPIC, dem ein 8-Bit- Entscheidungs-ID (Arb ID) beigefügt ist, um in dem Falle, wenn es mehrere bei der geringsten Priorität ausführende MPICs gibt, den Gleichstand zu brechen.
Die Verwendung des konstanten 8-Bit-MPIC-ID als Arb-ID weist eine Tendenz zur Asymmetrie auf, da sie MPICs mit geringen ID-Werten favorisieren würde. Ein Arb-ID eines MPIC ist folglich nicht der MPIC selbst, sondern wird aus diesem gewonnen. Beim Rücksetzen ist der Arb-ID des MPIC gleich seinem MPIC-ID. Jedesmal, wenn eine Nachricht über den MPIC-Bus ausgesendet wird, inkrementieren sämtliche MPICs ihren Arb-ID um Eins, was ihnen für den nächsten Entscheidungswettbewerb einen anderen Arb-ID-Wert gibt. Der Arb-ID (Entscheidungs-ID) wird dann endian-umgekehrt (am geringsten bewerteten Bits (LSB) werden zu am höchsten bewertete Bits (MSB), usw.), um eine zufälligere Auswahl des MPIC zu sichern, der in der nächsten Runde den geringsten Arb-ID hat. Der umgekehrte Arb-ID wird dann dekodiert, um Entscheidungs-Signale auf dem MPIC-Bus zu erzeugen, wie oben beschrieben wurde.
Nach der Bus-Entscheidung treibt der Gewinner seine aktuelle Nachricht auf den Bus, 4 Bits pro Takt in einer Halbbyte-seriellen Weise. Die MPIC-Nachrichten kommen in zwei Längen: kurze Nachrichten mit 21 Zyklen und lange mit 30 Zyklen. Die Interpretation der ersten 19 Zyklen ist für sämtliche Nachrichtenlängen die gleiche. Der lange Nachrichtentyp hängt für die Prioritätsentscheidung Zyklen an die ersten 19 Zyklen an. Der mittlere Nachrichtentyp tritt nur dann auf, wenn eine vollständige Entscheidung nicht erforderlich ist, wie beispielsweise in dem Fall, wenn der Gewinner vor Entscheidung bekannt ist.
Das kurze Nachrichtenformat ist in Fig. 14 gezeigt, wo die erste Spalte den Nachrichtenzyklus-Index (1 : 19) darstellt, während die nächsten vier Spalten die vier Datenleitungen des MPIC-Bus repräsentieren.
Die ersten vier Zeilen (1 : 4) stellen den MPIC-Bus- Entscheidungszyklus dar, wobei jede Zeile 4 Einträge hat, die das dekodierte Tupel des MPIC-ID, wie zuvor erörtert, darstellen, d. h. i76 . . . i76 stellen das Tupel (7:6) dar, i54 . . . i54 das Tupel (5:4), usw..
Zyklus 5 stellt den erweiterten Abgabe-Modus der Nachricht dar und wird gemäß Fig. 15 interpretiert. Das mit DM gekennzeichnete Bit stellt das Ziel-Modusbit dar, welches 0 beim physischen Modus und 1 beim logischen Modus ist. Die Bits M0, M1, M2 sind zuvor zugewiesen in der Umadressier-Tabelle gemäß Fig. 4.
Zyklus 6 enthält die Steuerbits, wie sie in Fig. 16 definiert sind. Der erweiterte Abgabe-Modus und Steuerbits, die Zyklen 5 und 6, bestimmen gemeinsam die erforderliche Länge der Nachricht und die Interpretation der verbleibenden Felder der Nachricht, wie es in Fig. 17 gezeigt ist.
Die Zyklen 7 und 8 bilden den 8-Bit-Interrupt-Vektor.
Zyklen 9 bis 16 sind das 32-Bit-Ziel-Feld.
Zyklus 17 enthält eine Prüfsumme über die Daten in den Zyklen 5 bis 16. Die Prüfsumme schützt die Daten in diesen Zyklen gegen Übertragungsfehler. Die sendende MPIC-Einheit stellt diese Prüfsumme zur Verfügung.
Zyklus 18 stellt einen Postamble-Zyklus dar, der als 1111 von dem sendenden MPIC getrieben wird und sämtlichen MPICs gestattet, verschiedene interne Berechnungen auf der Grundlage der in der empfangenen Nachricht enthaltenden Informationen auszuführen. Eine der Berechnungen nimmt die berechnete Prüfsumme der in den Zyklen 5 bis 16 empfangenen Daten und vergleicht sie mit dem Wert von Zyklus 17. Wenn irgendeine MPIC-Einheit eine andere Prüfsumme als die in Zyklus 17 weitergeleiteten Prüfsumme berechnet, dann signalisiert dieser MPIC im Zyklus 19 einen Fehler auf dem MPIC-Bus, indem er ihn als 1111 treibt. Wenn dies geschieht, nehmen sämtliche MPIC- Einheiten an, daß die Nachricht niemals gesendet wurde, und der Sender muß erneut versuchen, die Nachricht zu senden, wobei dies einen erneuten Entscheidungswettstreit für den Zugriff auf den MPIC-Bus einschließt. Bei einer Geringste-Priorität-Abgabe, wenn das Interrupt einen Focus-Prozessor hat, signalisiert dies der Focus-Prozessor durch Treiben einer 1110 während des Zyklus 19. Dies teilt sämtlichen anderen MPIC-Einheiten mit, daß das Interrupt angenommen worden ist, die Zuteilungsentscheidung erworben ist und das kurze Nachrichtenformat verwendet wird. Sämtliche (Nicht-Focus-) MPIC-Einheiten treiben eine 1000 im Zyklus 19. Unter dem Geringste-Priorität-Abgabe-Modus bedeutet 1000, daß das Interrupt gegenwärtig keinen Focus-Prozessor hat und daß eine Prioritäts-Entscheidung erforderlich ist, um die Abgabe abzuschließen. In diesem Fall wird ein langes Nachrichtenformat verwendet. Wenn der Zyklus 19 eine 1000 für einen Nicht-Geringste-Priorität-Modus ist, dann wurde die Nachricht akzeptiert und wird als gesendet angesehen.
Wenn eine MPIC-Einheit während des Fehlerzyklus einen Fehler erfaßt und berichtet, so lauscht diese MPIC-Einheit einfach am Bus, bis sie auf zwei aufeinanderfolgende Leer- Zyklen (0000) trifft. Diese zwei Leer-Zyklen zeigen an, daß die Nachricht weitergeleitet worden ist und durch einen beliebigen Teilnehmer eine neue Nachricht gestartet werden kann. Dies gestattet einem MPIC, der sich selbst aus dem Zyklus auf dem MPIC-Bus herausgebracht hat, sich in Synchronisation mit den anderen MPIC-Einheiten zurückzubringen.
Die Zyklen 1 bis 19 des langen Nachrichtenformats sind identisch mit den Zyklen 1 bis 19 des kurzen Nachrichtenformats.
Wie bereits erwähnt, wird das lange Nachrichtenformat in zwei Fällen verwendet:
  • 1. Geringste-Priorität-Abgabe, wenn das Interrupt keinen Focus hat. Die Zyklen 20 bis 27 sind acht Entscheidungszyklen, in denen die Ziel-MPIC-Einheit die eine MPIC-Einheit mit der geringsten Prozessor-Priorität/dem geringsten Arb-ID-Wert feststellt.
  • 2. Fern-Lese-Nachrichten. Die Zyklen 20 bis 27 sind der 32-Bit-Inhalt des Fern-Lese-Registers. Diese Informationen werden auf den Bus von der Fern-MPIC-Einheit getrieben.
Zyklus 28 ist ein Akzeptier- bzw. Annahme-Zyklus. Bei einer Geringste-Priorität-Abgabe geben sämtliche MPIC-Einheiten die den Entscheidungswettstreit nicht gewannen (einschließlich solchen, die nicht an der Entscheidung teilnahmen), im Antriebs-Zyklus 28 eine 1100 (kein Akzeptieren) aus, während die gewinnende MPIC-Einheit 1111 ausgibt. Wenn im Zyklus 28 1111 gelesen wird, dann wissen sämtliche MPIC-Einheiten, daß das Interrupt akzeptiert worden ist, und die Nachricht wird als abgegeben angesehen. Wenn im Zyklus 28 1000 gelesen wird (oder irgendetwas anderes außer 1111 für diese Sache), dann nehmen sämtliche MPIC-Einheiten an, daß die Nachricht nicht akzeptiert wurde oder daß während der Entscheidung ein Fehler auftrat. Die Nachricht wird als nicht abgegeben angesehen und die sendende MPIC-Einheit versucht, die Nachricht erneut abzugeben.
Bei Fern-Lese-Nachrichten wird der Zyklus 28 als 1100 von sämtlichen MPICs ausgegeben mit Ausnahme der antwortenden Fern- MPIC-Einheit, welche den Bus mit 1111 antreibt, wenn sie in der Lage war, die angeforderten Daten in den Zyklen 20 bis 27 erfolgreich anzulegen. Sofern im Zyklus 28 1111 gelesen wird, werden die Daten in Zyklen 20 bis 27 als gültig angesehen; andernfalls werden die Daten als ungültig angesehen. Die Quell- MPIC-Einheit, die das Fern-Lesen ausgegeben hat, verwendet den Zyklus 28, um den Zustand des Fern-Lese-Statusfeldes in dem Interrupt-Befehlsregister (gültig oder ungültig) festzustellen. Auf jeden Fall ist eine Fern-Lese-Anforderung derart stets erfolgreich (obwohl die Daten gültig oder ungültig sein können), daß ein Fern-Lesen niemals erneut versucht wird. Der Grund dafür ist, daß das Fern-Lesen ein Merkmal der Fehlerbeseitigung ist und das ein "aufgehängter" Fern-MPIC, der nicht in der Lage ist zu antworten, nicht ein Aufhängen der Fehlerbeseitigungsprozedur veranlassen soll.
Zyklen 28 und 30 sind zwei Leer-Zyklen. Der MPIC-Bus ist zum Senden der nächsten Nachricht beim Zyklus 31 verfügbar. Die zwei Leer-Zyklen am Ende sowohl der kurzen als auch der langen Nachrichten zusammen mit den keine Nullen enthaltenden (d. h. nicht leeren) Kodierungen für bestimmte andere Buszyklen gestatten einem MPIC-Busteilnehmer, der aus der Phase um einen Zyklus herausgerät, innerhalb einer Nachricht die Synchronisation zurückzugewinnen, indem er einfach auf zwei aufeinanderfolgende Leerzyklen nach dem Berichten seines Prüfsummenfehlers wartet. Dabei wird die Tatsache ausgenutzt, daß gültige Entscheidungszyklen niemals 0000 sind.
E. Zeitgeber
Die lokale Vektor-Tabelle 210 der lokalen MPIC-Einheit 104 enthält drei unabhängig arbeitende 32-Bit breite programmierbare Zeitgeber 200, 201 und 202. Jeder Zeitgeber kann seine Taktbasis von einem von drei Takteingängen auswählen. Jeder Zeitgeber kann entweder im monostabilen Modus oder in einem periodischen Modus arbeiten und jeder kann so konfiguriert werden, daß er den lokalen Prozessor mit einem beliebigen programmierbaren Vektor unterbricht.
Die lokale MPIC-Einheit 104 hat zwei unabhängige Takt- Eingangspins: das CLOCK-Pin stellt den internen Takt des MPIC zur Verfügung, TMBASE ist für einen externen Takt vorgesehen. Die Frequenz von TMBASE ist durch die MPIC-Architektur auf 28,636 MHz festgelegt. Zusätzlich enthält der lokale MPIC einen Teiler, der so konfiguriert werden kann, daß er jedes Taktsignal durch 2, 4, 8 oder 16 teilt, wie es in Fig. 19 gezeigt ist. Die Basis 0 ist stets gleich CLOCK; die Basis 1 ist stets gleich TMBASE und die Basis 2 kann entweder gleich CLOCK oder TMBASE dividiert durch 2, 4, 8 oder 16 sein. Das Teiler(Basis-2)-Konfigurationsregister ist in Fig. 20 gezeigt.
Die Software startet einen Zeitgeber, indem sie sein 32-Bit breites Anfangszählregister programmiert. Der Zeitgeber kopiert diesen Wert in sein aktuelles Zählregister und startet das Herunterzählen mit einer Rate von einer Zählung für jeden Zeitbasisimpuls (Basis 0, 1 oder 2). Jeder Zeitgeber kann als Monoflop oder periodisch betrieben werden. Wenn er ein Monoflop darstellt, zählt der Zeitgeber einmal herunter und verbleibt bei 0, bis er erneut programmiert wird. Im periodischen Modus lädt der Zeitgeber automatisch erneut den Inhalt des Anfangszählregisters in das aktuelle Zählregister.
Die drei Zeitgeber werden mit Hilfe ihrer lokalen Vektor- Tabellen-Einträge konfiguriert, wie es in Fig. 21 gezeigt ist. Das Vektor-Feld (0 : 7) wurde bereits beschrieben. Die Maskierung i, das Bit (16), dient zum Maskieren (1) oder Nicht-Maskieren (0) des vom i-ten Zeitgeber erzeugten Interrupts, wenn die Zählung 0 erreicht. Das Basis-i-Feld (18:19) ist der von dem i- ten Zeitgeber verwendete Basiseingang: 00 - Basis 0, 01 - Basis 1 und 10 - Basis 2. Das Modus-i-Bit (17) zeigt den Modus des i- ten Zeitgebers an: 0 - Monoflop, 1 - periodisch.
F. Privatspeicher des Prozessors
Jede lokale MPIC-Einheit stellt einen Prozessor- Privatspeicher 250, wie er in Fig. 5 gezeigt ist, mit vier 32- Bit-Registern zu Verfügung, auf die nur von dem lokalen Prozessor zugegriffen werden kann. Da jeder Prozessor seine Register in der gleichen Weise (über die gleiche Adresse) adressiert, schaffen die Register einen geeigneten und von der Prozessorarchitektur unabhängigen Weg, "prozessoreigene" Daten zur Verfügung zu stellen. Der Inhalt dieser Register wird von dem MPIC in keiner Weise interpretiert. Diese Register sind in der gleichen physischen Adreßseite angeordnet, wie die anderen lokalen MPIC-Register; ein Zugriff auf diese Register kann folglich nur auf ein Hauptsteuerprogramm (Supervisor) beschränkt bleiben. Das auf dem Prozessor ablaufende Betriebssystem kann diese Register verwenden, wie es ihm beliebt.

Claims (10)

1. Programmierbares Interrupt-Controller(PIC)-System für ein Multiprozessor-Computersystem mit mehreren Prozessoren (105) und wenigstens einer Peripherieeinrichtung (101), die mit einem gemeinsamen Bus (30) gekoppelt sind,
wobei wenigstens ein I/O-Interrupt-Controller (102) mit der wenigstens einen Periphexieeinrichtung (101) gekoppelt ist, um Interrupt-Anforderungssignale zu empfangen und in Abhängigkeit davon Interrupt-Anforderungen auszugeben,
dadurch gekennzeichnet,
daß der I/O-Interrupt-Controller (102) mit einem Inter­ rupt-Bus (103) gekoppelt ist und formatierte Interrupt-An­ forderungsnachrichten (Fig. 14, Fig. 18) auf den Interrupt- Bus (103) aussendet, und
das mehrere lokale Interrupt-Controller (104) mit dem Interrupt-Bus (103) gekoppelt sind, wobei jedem Prozessor (105) einer der lokalen Interrupt-Controller (104) zugeord­ net ist,
wobei jeder lokale Interrupt-Controller (104) so ausge­ bildet ist,
daß er die formatierten Interrupt-Anforderungsnach­ richten von dem Interrupt-Bus (103) empfangen kann, von denen er diejenigen akzeptiert, für deren Bedienung der zugeordnete Prozessor (105) geeignet ist,
daß er beim Akzeptieren einer Interrupt-Anforderung ein Akzeptanzsignal (Zyklus 19 oder 28) an den Interrupt- Bus (103) anlegt und
daß er eine Entscheidungssequenz (Zyklen 20-27) für eine Entscheidung zwischen mehreren möglichen Prozesso­ ren (105), die gleichzeitig für eine Bedienung der In­ terrupt-Anforderung zur Verfügung stehen, erzeugen kann.
2. Programmierbares Interrupt-Controller-System nach An­ spruch 1, dadurch gekennzeichnet, daß die lokalen Interrupt- Controller (104) so ausgebildet sind, daß sie die akzeptier­ ten Interrupt-Anforderungen in eine Warteschlange (230) ein­ reihen und zur Bedienung an den zugeordneten Prozessor (105) weitergeben können.
3. Programmierbares Interrupt-Controller-System nach An­ spruch 2, dadurch gekennzeichnet, daß die lokalen Interrupt- Controller (104) Einrichtungen (230, 240, 242) aufweisen, mit deren Hilfe die eingereihten Interrupt-Anforderungen in der Reihenfolge ihrer Priorität an den zugeordneten Prozes­ sor (105) weitergegeben werden.
4. Programmierbares Interrupt-Controller-System nach ei­ nem der Ansprüche 1-3, dadurch gekennzeichnet,
daß die lokalen Interrupt-Controller die Entscheidungs­ sequenz (Zyklen 20-27) auf der Grundlage der aktuellen Prio­ rität des ihnen jeweils zugeordneten Prozessors derart er­ zeugen, daß dabei die Entscheidungssequenz von dem- bzw. denjenigen lokalen Interrupt-Controller(n) (104) gewonnen wird, dessen Prozessor bzw. deren Prozessoren gegenwärtig die geringste Priorität aufweisen, und
daß anschließend gegebenenfalls die Entscheidungssequenz unter diesen verbliebenen Interrupt-Controllern (104) auf eine zufällige Weise entschieden wird, so daß einer der lo­ kalen Interrupt-Controller mit einem Prozessor der gering­ sten Priorität die Entscheidungssequenz gewinnt.
5. Programmierbares Interrupt-Controller-System nach An­ spruch 4, dadurch gekennzeichnet, daß die Entscheidungsse­ quenz auf der Grundlage eines auf den Interrupt-Bus (103) ausgegebenen Wertes durchgeführt wird, der dem Wert der Pro­ zessorpriorität entspricht, wobei dem Wert ein Entschei­ dungs-ID angefügt ist, wobei der Entscheidungs-ID aus einem ID des lokalen Interrupt-Controllers gebildet ist.
6. Programmierbares Interrupt-Controller-System nach An­ spruch 5, dadurch gekennzeichnet, daß der Entscheidungs-ID aus dem ID des lokalen Interrupt-Controllers (104) gebildet wird, indem zunächst bei einem Rücksetzen der Entscheidungs- ID auf den ID des lokalen Interrupt-Controllers gesetzt und jedesmal dann, wenn eine Nachricht über den Interrupt-Bus (103) ausgesendet wird, um Eins inkrementiert und anschlie­ ßend endian-umgekehrt wird.
7. Programmierbares Interrupt-Controller-System nach ei­ nem der Ansprüche 1-6, dadurch gekennzeichnet, daß der I/O-Interrupt-Controller (102) die auf den In­ terrupt-Bus (103) auszusendenden Interrupt-Anforderungsnach­ richten (Fig. 14, Fig. 18) derart formatiert, daß sie Infor­ mationen über die Art und die Priorität des aus der wenig­ stens einen Peripherieeinrichtung (101) empfangenen Inter­ rupt-Anforderungssignals und über eine Gruppe von Prozesso­ ren (105), die für die Bedienung des Interrupt-Signals ge­ eignet sind, enthalten.
8. Programmierbares Interrupt-Controller-System nach ei­ nem der Ansprüche 1-7, dadurch gekennzeichnet, daß die for­ matierten Interrupt-Anforderungsnachrichten umfassen:
eine Interrupt-Busentscheidungssequenz;
einen Abgabe-Modus-Abschnitt, der die Grundlage der Zu­ lieferung anzeigt;
einen Steuerabschnitt, der das Ziel und den Abgabe-Modus anzeigt;
einen Zielabschnitt, der die geeigneten Prozessoren an­ zeigt, und
einen Prüfsummenwert.
9. Programmierbares Interrupt-Controller-System nach ei­ nem der Ansprüche 1-8, dadurch gekennzeichnet, daß der In­ terrupt-Bus (103) ein synchroner Bus ist, an dessen Buslei­ tungen die lokalen Interrupt-Controller derart angekoppelt sind, daß das Signal auf den Busleitungen eine ODER-Verknüp­ fung der Ausgabesignale der Interrupt-Controller darstellt.
10. Programmierbares Interrupt-Controller-System nach einem der Ansprüche 1-9, dadurch gekennzeichnet, daß die lo­ kalen Interrupt-Controller jeweils auf dem Chip der zugeord­ neten Prozessoren integriert sind.
DE4413459A 1993-04-19 1994-04-18 Programmierbares Interrupt-Controller-System Expired - Fee Related DE4413459C2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US4951593A 1993-04-19 1993-04-19

Publications (2)

Publication Number Publication Date
DE4413459A1 DE4413459A1 (de) 1994-10-20
DE4413459C2 true DE4413459C2 (de) 2000-04-06

Family

ID=21960233

Family Applications (1)

Application Number Title Priority Date Filing Date
DE4413459A Expired - Fee Related DE4413459C2 (de) 1993-04-19 1994-04-18 Programmierbares Interrupt-Controller-System

Country Status (6)

Country Link
JP (1) JPH06324996A (de)
DE (1) DE4413459C2 (de)
GB (1) GB2277388B (de)
HK (1) HK1001011A1 (de)
IT (1) IT1270035B (de)
SG (1) SG48803A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG67906A1 (en) * 1993-12-16 1999-10-19 Intel Corp Multiple programmable interrupt controllers in a multi-processor system
US7689747B2 (en) * 2005-03-28 2010-03-30 Microsoft Corporation Systems and methods for an augmented interrupt controller and synthetic interrupt sources
JP5243711B2 (ja) 2006-11-10 2013-07-24 セイコーエプソン株式会社 プロセッサ
US7627706B2 (en) * 2007-09-06 2009-12-01 Intel Corporation Creation of logical APIC ID with cluster ID and intra-cluster ID
JP5322567B2 (ja) * 2008-10-02 2013-10-23 ルネサスエレクトロニクス株式会社 データ処理システム及び半導体集積回路
JP5169731B2 (ja) * 2008-10-24 2013-03-27 富士通セミコンダクター株式会社 マルチプロセッサシステムlsi
US8103816B2 (en) * 2008-10-28 2012-01-24 Intel Corporation Technique for communicating interrupts in a computer system
US8234431B2 (en) * 2009-10-13 2012-07-31 Empire Technology Development Llc Interrupt masking for multi-core processors
CN117294538B (zh) * 2023-11-27 2024-04-02 华信咨询设计研究院有限公司 一种数据安全风险行为的旁路检测与阻断方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4495569A (en) * 1982-06-28 1985-01-22 Mitsubishi Denki Kabushiki Kaisha Interrupt control for multiprocessor system with storage data controlling processor interrupted by devices
US5125093A (en) * 1990-08-14 1992-06-23 Nexgen Microsystems Interrupt control for multiprocessor computer system
US5179707A (en) * 1990-06-01 1993-01-12 At&T Bell Laboratories Interrupt processing allocation in a multiprocessor system
US5193187A (en) * 1989-12-29 1993-03-09 Supercomputer Systems Limited Partnership Fast interrupt mechanism for interrupting processors in parallel in a multiprocessor system wherein processors are assigned process ID numbers
US5201051A (en) * 1989-10-05 1993-04-06 Oki Electric Industry Co., Ltd. Apparatus for interrupt detection and arbitration

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3676861A (en) * 1970-12-30 1972-07-11 Honeywell Inf Systems Multiple mask registers for servicing interrupts in a multiprocessor system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4495569A (en) * 1982-06-28 1985-01-22 Mitsubishi Denki Kabushiki Kaisha Interrupt control for multiprocessor system with storage data controlling processor interrupted by devices
US5201051A (en) * 1989-10-05 1993-04-06 Oki Electric Industry Co., Ltd. Apparatus for interrupt detection and arbitration
US5193187A (en) * 1989-12-29 1993-03-09 Supercomputer Systems Limited Partnership Fast interrupt mechanism for interrupting processors in parallel in a multiprocessor system wherein processors are assigned process ID numbers
US5179707A (en) * 1990-06-01 1993-01-12 At&T Bell Laboratories Interrupt processing allocation in a multiprocessor system
US5125093A (en) * 1990-08-14 1992-06-23 Nexgen Microsystems Interrupt control for multiprocessor computer system

Also Published As

Publication number Publication date
HK1001011A1 (en) 1998-05-15
GB9402811D0 (en) 1994-04-06
GB2277388B (en) 1997-08-13
GB2277388A (en) 1994-10-26
JPH06324996A (ja) 1994-11-25
ITMI940730A0 (it) 1994-04-15
DE4413459A1 (de) 1994-10-20
ITMI940730A1 (it) 1995-10-15
IT1270035B (it) 1997-04-28
SG48803A1 (en) 1998-05-18

Similar Documents

Publication Publication Date Title
DE69634182T2 (de) Direktspeicherzugriffssteuerung mit programmierbarer Zeitsteuerung
DE19580990C2 (de) Verfahren und Einrichtung zum Ausführen verzögerter Transaktionen
DE3606211A1 (de) Multiprozessor-computersystem
DE19983737B3 (de) System zum Neuordnen von Befehlen, die von einer Speichersteuerung zu Speichervorrichtungen ausgegeben werden, unter Verhinderung von Kollision
DE60036465T2 (de) Rechneradapterkarte für die kombinierung von eingang-/ausgangfertigstellungsberichten und verwendung derselben
DE69531933T2 (de) Busarchitektur in hochgradiger pipeline-ausführung
DE3914265C2 (de)
DE69233655T2 (de) Mikroprozessorarchitektur mit der Möglichkeit zur Unterstützung mehrerer verschiedenartiger Prozessoren
DE602004012563T2 (de) Mehrfädiges DMA
DE3909948C2 (de)
DE3134428C2 (de)
DE69727856T2 (de) Multiprozessorsystem mit Konsistenzfehler-Registrierung mit entsprechendem Verfahren
DE602004012106T2 (de) Multikanal-DMA mit gemeinsamem FIFO-Puffer
DE69735575T2 (de) Verfahren und Vorrichtung zur Unterbrechungsverteilung in einem skalierbaren symmetrischen Mehrprozessorsystem ohne die Busbreite oder das Busprotokoll zu verändern
DE60108911T2 (de) Prozessorschnittstelle mit geringem overhead
DE69725687T2 (de) Transaktionsübertragung zwischen Datenbussen in einem Rechnersystem
DE19983745B9 (de) Verwendung von Seitenetikettregistern um einen Zustand von physikalischen Seiten in einer Speichervorrichtung zu verfolgen
DE3642324C2 (de) Multiprozessoranlage mit Prozessor-Zugriffssteuerung
DE69531270T2 (de) Unterbrechungssteuerungsgeräte in symmetrischen Mehrprozessorsystemen
EP0006164B1 (de) Multiprozessorsystem mit gemeinsam benutzbaren Speichern
DE3704056A1 (de) Peripherer dma-controller fuer datenerfassungssysteme
DE3114961A1 (de) Datenverarbeitungssystem
DE2847216A1 (de) Datenverarbeitungssystem mit mehrprogrammbetrieb
DE2243956A1 (de) Speicherprogrammierte datenverarbeitungsanlage
DE102013113262B4 (de) Auslöser-Leitwegeinheit

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
D2 Grant after examination
8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20131101