DE19756885A1 - Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie Vorrichtung zur Durchführung des Verfahrens - Google Patents
Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie Vorrichtung zur Durchführung des VerfahrensInfo
- Publication number
- DE19756885A1 DE19756885A1 DE19756885A DE19756885A DE19756885A1 DE 19756885 A1 DE19756885 A1 DE 19756885A1 DE 19756885 A DE19756885 A DE 19756885A DE 19756885 A DE19756885 A DE 19756885A DE 19756885 A1 DE19756885 A1 DE 19756885A1
- Authority
- DE
- Germany
- Prior art keywords
- bus
- module
- cycle
- line
- signal
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
- G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
- G06F13/364—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Bus Control (AREA)
- Small-Scale Networks (AREA)
Description
Die Erfindung bezieht sich auf ein Verfahren zum Austausch
von Signalen zwischen über einen Bus verbundenen Modulen
sowie auf eine Vorrichtung zur Durchführung des Verfahrens.
Herkömmliche Computer haben mehrere Hardware-Module, die
an einen gemeinsamen Bus, wie z. B. den bekannten ISA-Bus
oder PCI-Bus, angeschlossen sind. Zum Austausch bestimmter
Signale zwischen den einzelnen Bus-Teilnehmern sind dort
jedoch zusätzliche Leitungen für spezielle Zwecke vorgesehen,
wie z. B. spezielle Interrupt-Leitungen, über die einzelne
Module einen Interrupt der CPU anfordern können. Je nach
Anzahl der Module, die einen Interrupt anfordern können,
steigt die Anzahl der entsprechenden Leitungen. Je komplexer
die Systeme werden, desto mehr Leitungen werden benötigt,
was den Verdrahtungsaufwand enorm ansteigen läßt. Neben
den genannten Interrupt-Leitungen sind bei komplizierteren
Systemen noch weitere Leitungen für spezielle Zwecke und
zum direkten Informationsaustausch zwischen einzelnen Modulen
vorgesehen. Diese Leitungen sind fest verdrahtet und können
später nicht mehr geändert oder erweitert werden. Damit
ist die Anzahl der zwischen einzelnen Modulen übertragbaren
Informationen bei diesen bekannten Systemen begrenzt.
Aufgabe der vorliegenden Erfindung ist es, Verfahren und
Vorrichtung der eingangs genannten Art dahingehend zu verbes
sern, daß ohne zusätzlichen Aufwand für Leitungen beliebige
Mengen von Informationen zwischen einzelnen Modulen ausge
tauscht werden können.
Diese Aufgabe wird für das Verfahren durch die im Anspruch 1
und für die Vorrichtung für die im Anspruch 7 angegebenen
Merkmale gelöst. Vorteilhafte Ausgestaltungen und Weiterbil
dungen der Erfindung sind den Unteransprüchen zu entnehmen.
Das Grundprinzip der Erfindung liegt darin, daß die Informa
tionen über den gemeinsamen Bus ausgetauscht werden. Für
den Informationsaustausch zwischen Modulen sind keine für
bestimmte Signale vorgesehene Leitungen notwendig, wie
z. B. für Interrupt, DMA (direkter Speicherzugriff; Direkt
Memory Access), etc. Derjenige Bus-Teilnehmer (Modul),
der eine Information zu senden hat, fordert auf einer ein
zigen, gemeinsamen Leitung den Bus an (Bus-Request), worauf
hin ein taktgesteuerter Zyklus gestartet wird. Dieser Zyklus
wird z. B. als Befehl (RAK-Befehl) abgewickelt und besteht
aus einem RAK-Kommando, das den Zyklus einleitet und aus
einem oder mehreren RAK-Zyklen, die je die Länge eines
Taktes haben. Jedem Modul ist ein vordefinierter Zeitraum
von vorzugsweise der Länge eines Taktes zugeordnet, innerhalb
dessen er seine Information an mindestens eine Bus-Leitung
sendet. Während eines solchen vordefinierten Zeitraumes
können auch mehrere Module gleichzeitig angesprochen werden,
wenn ihnen unterschiedliche Bus-Leitungen zugeordnet sind.
Auch ist es möglich, einem Modul innerhalb eines RAK-Befehles
mehrere Bus-Leitungen zuzuordnen. Die einzelnen Bus-Teil
nehmer können auch zeitlich nacheinander angesprochen werden.
Derjenige Bus-Teilnehmer, der das Request-Signal abgesandt
hat, sendet seine Informationen also innerhalb des ihm
zugewiesenen Zeitfensters des Zyklus über eine vorher defi
nierte Leitung. Jeder Bus-Teilnehmer ist dabei so konfi
guriert, daß er zu einem oder mehreren festgelegten Zeit
fenstern Signale senden oder empfangen kann. Mehrere Bus-
Teilnehmer können in ihrer Funktion als Empfänger auch
bei ein und demselben Takt bzw. Zeitfenster angesprochen
werden. Umgekehrt kann ein Bus-Teilnehmer, der an unter
schiedliche andere Bus-Teilnehmer unterschiedliche Nach
richten zu senden hat, diese innerhalb eines vollen Zyklus
zu verschiedenen Zeitfenstern, auf die die Empfänger-Module
konfiguriert sind, Nachrichten absenden.
Allgemein sei noch angemerkt, daß der Begriff "Modul" all
gemein einzelne Bus-Teilnehmer bezeichnet, die sowohl als
steckbare Baugruppe als auch als IC (Chip) ausgebildet
sein können. Die Erfindung ist also auch auf den Informa
tionsaustausch zwischen einzelnen Chips anwendbar, die
in einer Baugruppe integriert sind, wobei dann diese Chips
über den Bus miteinander kommunizieren.
Hat ein Bus-Teilnehmer ein Request-Signal abgesetzt, so
unterbricht bzw. beendet der aktuelle Bus-Master (z. B.
die CPU oder ein sonstiges Modul, das aktueller Bus-Master
ist) die laufende Bus-Aktivität und gibt den Bus für kurze
Zeit frei, damit der oder die Bus-Teilnehmer, die den Bus-Re
quest abgesetzt haben, ihre Signale übertragen können.
Danach kann der Bus-Master oder ein anderes Modul wieder
den Bus nutzen.
Während eines solchen Zyklus können beliebig viele Bus-Teil
nehmer innerhalb ihres Zeitfensters bzw. ihrer Zeitfenster
Signale senden und während der übrigen Zeitabschnitte des
Zyklus Signale von anderen Bus-Teilnehmern empfangen. Mit
der Erfindung erreicht man unter anderem folgende Vorteile:
- - Es sind keine zusätzlichen Bus-Leitungen erforderlich außer der Request-Leitung und ggf. noch einer Steuerleitung (RAK).
- - Es können beliebig viele Signale übertragen werden.
- - Es können alle Arten von Signalen übertragen werden und nicht nur beispielsweise Interrupt-Anforderungen oder DMA-Übertragungen (Direct Memory Access).
- - Alle Bus-Teilnehmer können Signale an alle anderen übertragen.
- - Ein Bus-Teilnehmer kann z. B. ein Signal senden, alle anderen können es empfangen. So können z. B. auch systemübergreifende Signale, wie drohender Spannungs ausfall oder aufgetretener Busfehler, an alle Bus-Teil nehmer signalisiert werden.
- - Die Verbindungen zwischen den Bus-Teilnehmern können per Software konfiguriert und jederzeit neu konfigu riert werden. Erweiterungen, wie z. B. Anzahl der Signale, erfordern lediglich eine neue Software-Konfi guration.
- - Bei Bus-Systemen, die DMA- oder Bus-masterfähig sind, kann dasselbe Verfahren verwendet werden. Die geringfü gige zusätzliche Belastung des Bus durch diese Übertra gung oder Übertragungen fällt demgegenüber nicht weiter ins Gewicht.
- - Alle Bus-Teilnehmer sind somit einzig und allein über den Bus miteinander verbunden. Es gibt keine Funktions- oder Teilnehmer-spezifischen Leitungen oder irgendwel che Zusatzleitungen (mit Ausnahme einer Request-Leitung und ggf. der RAK-Leitung).
Jeder Bus-Teilnehmer besteht aus einem Funktionsteil und
einer Bus-Schnittstelle, im folgenden BIU (für Bus-Interface-
Unit) genannt. Die BIU ist eine Schaltung, mit der der
Bus-Teilnehmer an den Bus angeschlossen ist. Sie übernimmt
bestimmte Aktivitäten, die den Bus betreffen, ohne daß
der Funktionsteil involviert ist. Stellt beispielsweise
ein Bus-Teilnehmer A bzw. dessen Funktionsteil fest, daß
sich der Zustand eines bestimmten Signals geändert hat,
so meldet er dies seiner BIU. Diese wurde zuvor so konfigu
riert, daß sie diese Änderung an einen anderen oder mehrere
Bus-Teilnehmer mitteilen soll (Takt und Leitung). Nun setzt
die BIU des Bus-Teilnehmers A das Bus-Anforderungssignal
(Bus-Request) aktiv. Der Bus-Teilnehmer B, der den Bus
gerade nutzt oder nutzen darf, ist der sog. aktuelle Bus-
Master. Er erkennt den Bus-Request, beendet bzw. unterbricht
seine laufende Bus-Aktivität und führt folgende Bus-Aktivitä
ten durch, wobei der Funktionsteil des Bus-Masters davon
nichts "merkt", außer daß er für einen Moment den Bus nicht
nutzen kann. Die BIU des aktuellen Bus-Masters B legt ein
RAK-Kommando (sogenanntes RAK für Request Acknowledge)
auf den Bus oder signalisiert das über eine zusätzliche
Bus-Leitung. Alle angeschlossenen BIU's erkennen dieses
Kommando, auch die BIU des Bus-Teilnehmers A. Sodann werden
entsprechend der Konfiguration ein oder mehrere sog. RAK-
Zyklen (für Request Acknowledge) durchgeführt. Ist der
RAK-Zyklus an der Reihe, für den der Bus-Teilnehmer A kon
figuriert wurde, so legt dessen BIU den Zustand des Signals
an die Bus-Leitung, für die die BIU von A konfiguriert
wurde. Diese Bus-Leitung wird dann zu diesem Zeitpunkt
als virtuelle Verbindungsleitung (VIL) zwischen Modulen
angesehen. Alle anderen Leitungen läßt sie unbeeinflußt
(Tri-State). Bei jedem RAK-Zyklus können somit eine Anzahl
Signale entsprechend der Bus-Breite übertragen werden.
Die Anzahl der RAK-Zyklen in einen RAK-Befehl ist dann
Anzahl der definierten Leitungen (VIL) geteilt durch die
Bus-Breite. Der Bus-Teilnehmer A erkennt auch, daß die
Änderung des Signals übertragen wurde und beendet dann
den Vorgang. Alle übrigen Bus-Teilnehmer, wenn entsprechend
konfiguriert, beobachten diese RAK-Zyklen und stellen so
fest, ob für sie ein Signal dabei ist. Ist dies der Fall,
so speichern sie die übertragene Information. Damit ist
der Vorgang beendet.
Prinzipiell sind zwei Typen von Signalen zu übertragen:
Bei jeder Änderung des Zustands des Signals wird ein
Bus-Request mit nachfolgendem RAK-Befehl ausgelöst.
Über die Bus-Leitungen wird in diesem Fall der aktuelle
Zustand des Signals gemeldet.
Wenn eine positive Flanke an einem Signal auftritt,
wird ein Bus-Request mit nachfolgendem RAK-Befehl
ausgelöst. Über die Bus-Leitungen wird in diesem Fall
gemeldet, ob die Flanke aufgetreten ist (= 1) oder
nicht (= 0).
Bei jedem Bus-Request mit nachfolgendem RAK-Befehl
werden immer alle Signale übertragen. Es ist aber
auch möglich, die Anzahl der RAK-Zyklen dynamisch
anzupassen, also abzubrechen, nachdem das gewünschte
Signal übertragen wurde. Wenn ein Bus-Request mit
nachfolgendem RAK-Zyklus durch einen dritten Bus-Teil
nehmer ausgelöst wird, so wird bei den übrigen Signa
len, die für "Zustand" konfiguriert sind, auch der
jeweils aktuelle Zustand übertragen. Bei den Signalen,
die für "Flanke" konfiguriert sind, wird eine logische
"0" übertragen, d. h. es ist keine Flanke aufgetreten.
Auch können mehrere Signale von unterschiedlichen
Bus-Teilnehmern gleichzeitig einen Bus-Request anfor
dern. Dann werden sie in einem einzigen RAK-Befehl
bedient.
Für die RAK-Zyklen gilt, daß ein und derselbe RAK-Zyklus
innerhalb eines RAK-Befehls entsprechend der Konfiguration
und der Bus-Breite von mehreren Bus-Teilnehmern genutzt
werden kann. Im RAK-Zyklus eines Bus-Teilnehmers können
eine oder mehrere Leitungen zugeordnet werden, bis hin zum
Extremfall, daß der entsprechende Bus-Teilnehmer in seinem
RAK-Zyklus alle Bus-Leitungen nutzt, wobei in diesem Fall
dann nur dieser eine Bus-Teilnehmer den RAK-Zyklus für
sich alleine hat. Im anderen Extremfall, bei dem in einem
RAK-Zyklus jedem für diesen konfigurierten Bus-Teilnehmer
nur eine Leitung zugeordnet ist, können so viele Bus-Teil
nehmer in diesem Zyklus senden, wie Bus-Leitungen vorhanden
sind.
Mit der Erfindung ist es auch möglich, einen Multi-Master
fähigen Bus zu betreiben. Die Ermittlung des jeweiligen
Masters wird nach demselben Prinzip vorgenommen. Ein Bus-
Teilnehmer, der neuer Bus-Master werden will, muß sich
zunächst den Bus holen. Hierfür setzt er ebenfalls die
Bus-Request-Leitung aktiv und die BIU des noch aktuellen
Masters führt einen RAK-Befehl durch. Der neue Bus-Master
sendet dann während des ihm zugeordneten Zyklus ein entspre
chendes Signal auf der ihm zugeordneten Leitung. Falls
mehrere Bus-Teilnehmer neuer Bus-Master werden wollen,
so legen sie alle während des ihnen zugeordneten Zyklus
diesen Wunsch auf die entsprechenden Bus-Leitungen. Die
BIU des aktuellen Bus-Masters ermittelt dann daraus denjeni
gen, der den Bus bekommt. Der Algorithmus hierzu ist
programmiert und wird vom Konfigurationsmaster in der
Initialisierungsphase festgelegt.
Im folgenden wird die Erfindung anhand eines Ausführungsbei
spiels im Zusammenhang mit der Zeichnung ausführlicher
erläutert. Es zeigt:
Fig. 1 ein Blockschaltbild mehrerer Module und einiger
Verbindungsleitungen;
Fig. 2 ein Zeitdiagramm eines Zyklus;
Fig. 3 ein Zeitdiagramm eines vollen Zyklus sowie ver
schiedener weiterer Signale;
Fig. 4-6 Zeitdiagramme von Signalfolgen, die durch unter
schiedliche Ereignisse ausgelöst werden (Zustands
änderung Fig. 4; Signalflanke Fig. 5; Interrupt-
Request Fig. 6); und
Fig. 7 ein Prinzipschaltbild einer Bus-Schnittstellen
einheit (BIU) für einen Empfänger;
Fig. 8 ein Prinzipschaltbild einer Bus-Schnittstel
leneinheit (BIU) für einen Master; und
Fig. 9 ein Prinzipschaltbild einer Bus-Schnittstel
leneinheit (BIU) für einen Sender.
BIU = Bus-Schnittstellen-Einheit (Bus Interface Unit)
CAD = Kommando/Adressen/Daten (Commando/Adressen/Daten)
CLK = Takt(Clock)
DMA = Direkter Speicherzugriff (Direct Memory Access)
IRQ = Interrupt Anforderung (Interrupt Request)
MAK = Master Bestätigung (Master Acknowledge)
MRQ = Master Anforderung (Master Request)
RAK = Bestätigung auf Anforderung (Request Acknowledge)
SP-Nr. = Steckplatz-Nummer (Steckplatz-Nr.)
VAK = Virtuelle Bestätigung (Virtual Acknowledge)
VIL = Virtuelle Schnittstellen-Leitung (Virtual Interconnection Line)
VRQ = Anforderung einer VIL (Virtual Interconnection Line Request)
RQ = Anforderungs-Leitung (Request Leitung).
CAD = Kommando/Adressen/Daten (Commando/Adressen/Daten)
CLK = Takt(Clock)
DMA = Direkter Speicherzugriff (Direct Memory Access)
IRQ = Interrupt Anforderung (Interrupt Request)
MAK = Master Bestätigung (Master Acknowledge)
MRQ = Master Anforderung (Master Request)
RAK = Bestätigung auf Anforderung (Request Acknowledge)
SP-Nr. = Steckplatz-Nummer (Steckplatz-Nr.)
VAK = Virtuelle Bestätigung (Virtual Acknowledge)
VIL = Virtuelle Schnittstellen-Leitung (Virtual Interconnection Line)
VRQ = Anforderung einer VIL (Virtual Interconnection Line Request)
RQ = Anforderungs-Leitung (Request Leitung).
In Fig. 1 sind mehrere Module M0, M1 . . . Mn dargestellt,
die an Steckplätzen SP0, SP1 . . . SPn an einen Bus mit den
Leitungen B0 bis Bn angeschlossen sind. Zusätzlich ist
eine Leitung RQ (im folgenden Requestleitung) vorgesehen,
die durch einen Pull-Up-Widerstand R1 auf positives Potential
(logischen Pegel 1) gesetzt ist und an die alle Module
über entsprechende Leitungen BRQ0, BRQ1 . . . BRQn angeschlos
sen sind. Weiter sind hier noch eine Taktleitung CLK, eine
Resetleitung RESET und eine Bus-Zyklusleitung AS gezeigt.
Weitere Leitungen können vorhanden sein, sind für die Erfin
dung aber ohne Bedeutung. Der Bus kann eine beliebige Anzahl
von Leitungen haben. Prinzipiell kann auch eine beliebige
Anzahl von Modulen angeschlossen sein.
Während des normalen Betriebes (nach der Initialisierungs
phase) ist eines der Module der sogenannte Bus-Master,
der in üblicher Weise Signale über die einzelnen Bus-Leitun
gen sendet oder von ihnen empfängt. Will jetzt ein anderes
Modul, das nicht Bus-Master ist, eine Information an eines,
mehrere oder alle Module übermitteln, so sendet es zu einem
beliebigen Zeitpunkt über seine Leitung BRQ ein Bus-Anforde
rungssignal (Bus-Request-Signal) zur Bus-Requestleitung RQ,
indem es einen logischen Pegel "0" auf diese ansonsten
durch den Pull-Up-Widerstand R1 auf logisch "1" stehende
Leitung RQ legt. Das Signal BRQ ist also "aktiv Low". Dies
kann auch asynchron zum Takt auf der Leitung CLK erfolgen.
Nach Ablauf der gerade laufenden Bus-Aktivität erkennt
der aktuelle Bus-Master diese Anforderung und löst einen
Anforderungs-Bestätigungs-Befehl (im folgenden RAK-Befehl
für Request-Acknowledge) aus, auch wenn er mit der aktuellen
Anforderung nichts zu tun hat.
Dieser in Fig. 2 dargestellte Zyklus beginnt mit einem
Bus-Kommando RAK (für Request-Acknowledge), das auf beliebig
vielen Bus-Leitungen B0 . . . Bn ausgegeben wird und damit
allen anderen Bus-Teilnehmern signalisiert, daß jetzt ein
oder mehrere RAK-Zyklen folgen. Alle Module erkennen dieses
Bus-Kommando und reagieren darauf. Nach dem Kommando RAK,
das aktiv vom aktuellen Bus-Master auf den Bus übertragen
wird, folgen virtuelle Bestätigungszyklen (im folgenden
VAK genannt, für Virtual Acknowledge) VAK0, VAK1 . . . VAKn,
die durch den Takt auf der Leitung CLK definierte Zeiträume
sind, wobei die einzelnen VAK's jeweils durch einen Takt
Pause - sofern erforderlich - getrennt sind. In diesen
virtuellen Acknowledge-Zyklen können dann die einzelnen
Module Informationen über den Bus übertragen, dessen
Leitungen dann nicht mehr die Funktion von normalen Bus-
Leitungen haben sondern als virtuelle Verbindungsleitungen
VIL (für Virtual Interconnection Line) wirken.
Jedes durch ein individuelles VAK definierte Zeitfenster
VAK0, . . . VAK1 . . . VAKn ist einem oder mehreren Modulen zugeordnet.
Beispielsweise kann das VAKn dem Modul Mn auf dem Steckplatz
Spn zugeordnet sein, das dann, wenn es an der Reihe ist,
auf einigen oder allen Bus-Leitungen B0 bis Bn für einen
Zeittakt ein Signal auf den Bus liefert. Während eines
RAK-Befehles zählen also alle Module den Takt und damit
auch die Abfolge der einzelnen VAK's mit und wissen daher
entsprechend der Initialisierungsphase, wann sie an der
Reihe sind, Signale auf den Bus zu senden und auch, von
welchem Modul diese Signale ausgesandt wurden. Die für
sie bestimmten Signale können sie dann während des
entsprechenden VAK lesen.
Es ist möglich, daß mehrere oder sogar alle Module zu einem
Zeitpunkt gleichzeitig einen Bus-Request absetzen. Der
aktuelle Bus-Master löst dann einen vollen RAK-Befehl aus
und jedes Modul, das einen Bus-Request abgesetzt hat, kann
dann während des ihm zugeordneten Zeitfensters bzw. Zyklus,
also während des entsprechenden VAK's, seine Mitteilung
auf die ihm zugeordnete Leitung des Bus legen.
Bei der nachfolgenden Beschreibung handelt es sich um den
Sonderfall der Bus-Verteilung bei mehreren Bus-Mastern,
die über denselben Mechanismus durchgeführt werden kann.
Wie aus Fig. 2 ersichtlich, sind vorzugsweise die beiden
ersten VAK's (hier VAK0 und VAK1) für Master-Requests,
sog. MAK's, z. B. MAK0, MAK1, reserviert. Es handelt sich
dabei um einen Sonderfall der VAK's. Allgemein formuliert
ist ein MAK ein Sonderfall eines Group-VIL. Es sind also
alle VIL's eines RAK zusammengefaßt. Die Sender und Empfänger
sind vordefiniert. Bezogen auf die Sender wird jedem Master
die seiner Steckplatznummer entsprechende Bus-Leitung
zugeordnet, wobei er über diese Leitung gegebenenfalls
das Signal "ich möchte Master werden" absetzt. Bezogen
auf die Empfänger gilt, daß alle Bus-Teilnehmer, die den
neuen Master ermitteln wollen oder müssen, alle VIL's dieses
RAK-Zyklus auswerten müssen. Die VIL's, die nicht von einem
Master belegt sind (z. B. weil kein Master auf dem Steckplatz
sitzt), werden in den Empfängern als ungültig - bezogen
auf MAK - maskiert. Sie könnten aber auch als "normale"
VIL's benutzt werden.
In einer Konfigurationsphase stellt der sogenannte Kon
figurationsmaster fest, auf welchen Steckplätzen Mastermodule
sitzen. Bei dem Fall von z. B. einem 8 Bit breiten Bus und
16 Bus-Teilnehmern gilt folgendes: Sitzt ein Master auf
Steckplatz-Nummer 0 bis 7, so wird die entsprechende Leitung
B0 in VAK0 für ein Master-Acknowledge MAK0 freigehalten;
sitzt ein Master auf Steckplatznummer 8 bis 15, so wird
die entsprechende Leitung B0 in VAK1 für MAK1 freigehalten.
Alle nicht durch ein MAK besetzte Leitungen können dann
durch virtuelle Verbindungsleitungen VIL belegt werden.
Entsprechend der Anzahl der möglichen Master werden ein
oder zwei unmittelbar auf das RAK-Kommando folgende Zyklen
als sog. Master Acknowledge (MAK-Zyklen) durchgeführt.
Diese werden in den Zyklen VAK0 und VAK1 abgebildet. Alle
masterfähigen Module schalten während der MAK-Zyklen die
ihnen zugeordnete Bus-Leitung RAKx aktiv und legen sie
auf "0", wenn sie einen Master Request (MRQ) angefordert
haben bzw. auf "1", wenn sie keinen MRQ angefordert haben
(x = 0 für Master auf Slot 0, x = 1 für Slot 1 bis x = 15
für Slot 15). Auf jedem Modul werden die nicht belegten
Leitungen maskiert. Leitungen können auch offen sein, da
eventuell auf einem Steckplatz kein Modul oder kein masterfä
higes Modul vorhanden ist. Wenn eine der nicht maskierten
Leitungen auf "0" liegt, wird in jedem Modul ermittelt,
wer neuer Master wird. Der alte Master gibt die Kontrolle
ab und der nächste Master übernimmt die Kontrolle, die
aber erst ab dem nächsten Bus-Command wirksam wird. Während
des laufenden RAK-Befehls gilt noch dem alte Master. Alle
Mastermodule können den neuen Master aus dem Code, der
während VAK0 (MAK0) und VAK1 (MAK1) auf dem Bus liegt,
ermitteln und speichern, falls sie dies wollen oder brauchen.
Es genügt, wenn die masterfähigen Module die Informationen
während der MAK-Zyklen verarbeiten und auswerten. Nach
einem Masterwechsel muß dem neuen Master in jedem Fall
eine Bus-Aktion zugestanden werden. Es wird auf jeden Fall
ein Befehl durchgeführt. Der alte Master kann somit nicht
sofort wieder Master werden. Der aktuelle Master kann ohne
Verzögerung durch die Bus-Arbitrierung sofort auf den Bus
zugreifen, sofern kein anderer Master den Bus angefordert
hat.
Da auf einem Bus mehrere Master liegen können und alle
Module den aktuellen Master ermitteln können, ist vorgesehen,
daß man in der Initialisierungsphase in den Modulen vorgeben
kann, auf welchen Masters sie überhaupt reagieren. In
der Initialisierungsphase wird ja auch die Adresse festge
legt, unter der die Module angesprochen werden können.
Somit können also zwei Module auf dieselbe Adresse aber
unterschiedliche Master konfiguriert werden. Damit wirkt
die Angabe des Masters wie eine Erweiterung der Adresse.
Das hat zum Beispiel eine Bedeutung bei einem Bus-System
mit zwei Mastern. Jeder Master stellt einen PC dar, mit
dem für die PC-Architektur festgelegten Adressen für IO-
Einrichtungen, wie z. B. für die Druckerschnittstelle LPT
1. Wenn jeder dieser beiden PC's eine Druckerschnittstelle
LPT 1 haben soll, die jeweils auf einem Modul realisiert
ist, gäbe es ein Problem, weil die IO-Adresse der Drucker
schnittstelle dann im System zweimal vorkäme. Die Lösung
besteht darin, daß in der Initialisierungsphase jedem
Druckermodul zusätzlich zur selben IO-Adresse auch der
Master mitgeteilt wird, dem es zugeordnet ist, von dem
es also angesprochen werden kann. Damit können also in
einem System mehrere gleichartige Architekturen realisiert
werden, die parallel aber über denselben Bus arbeiten.
Über andere, von allen Mastern ansprechbare Module, z. B.
gemeinsame Speicherbereiche, können die Master untereinander
Daten austauschen.
Die Anzahl der VAK-Zyklen hängt von der Bus-Konfiguration
bzw. der Anzahl der Module und der Anzahl von VIL's ab.
Prinzipiell ist für jedes Modul ein VAK-Zyklus vorgesehen.
Ein kompletter RAK-Befehl muß nicht unbedingt alle VAK-Zyklen
enthalten sondern kann abgebrochen werden, wenn das letzte
Modul, das einen Bus-Request abgesetzt hat, an der Reihe
war und seine Informationen abgesetzt hat. Dies kann
beispielsweise dadurch signalisiert werden, daß jedes Modul,
das einen Bus-Request abgesetzt hat, die Leitung RQ so
lange auf dem Pegel logisch "0" hält, bis sein zugeordneter
VAK-Zyklus beendet ist. Haben noch weitere in der VAK-
Reihenfolge hinter ihm liegende Module einen Bus-Request
abgesetzt, so halten diese die Leitung RQ weiter auf logisch
"0". Hierdurch kann ein RAK-Befehl auch abgebrochen werden,
sobald die Leitung RQ wieder auf logisch "1" geht, da dann
alle Module wissen, daß kein weiterer VAK-Zyklus mehr folgen
kann. Durch diese Maßnahme kann Übertragungszeit gespart
werden und der Bus wird früher wieder für andere Bus-Teil
nehmer freigegeben. VIL's, die häufig sich ändernde Signale
übertragen, die also viele RAK-Befehle auslösen, sollten
vorzugsweise RAK-Zyklen unmittelbar am Anfang des RAK-Befehls
zugeordnet (konfiguriert) werden.
Zur Abwicklung der VIL-Funktionen hat jedes Modul eine
Einheit BIU (Bus-Interface-Unit), die die Kommunikation
zwischen dem Bus und dem Modul steuert. Jede BIU enthält
u. a. einen Speicher bzw. ein Register, in welches während
einer Konfigurationsphase eingeschrieben wird, welcher
VAK-Zyklus dem jeweiligen Modul zugeordnet ist, was z. B.
entsprechend dem Steckplatz der Module erfolgt. Weiter
ist in diesen Speichern für die einzelnen VIL's ein Register
satz enthalten, der die Funktion der VIL festlegt. Dabei
kann man zwei Typen von VIL's unterscheiden, nämlich "Single-
VIL" und "Group-VIL". Während bei der Single-VIL nur eine
Information auf einer Bus-Leitung übertragbar ist, können
bei der Group-VIL alle Bus-Leitungen verwendet werden.
Bei der Group-VIL darf es dann aber während des einzelnen
VAK-Zyklus nur einen Sender oder nur einen Empfänger geben.
Bei der Funktion Single-VIL kann jede Leitung über eine
beliebige virtuelle Leitung VIL (0 bis 7, bei 8 Bit Bus-
Breite) in einem beliebigen RAK-Zyklus (z. B. 0 bis 15)
übertragen werden.
Bei einer Group-VIL werden die Leitungen eines Moduls je
nach Bus-Breite zu einer Gruppe zusammengefaßt und in einem
RAK-Zyklus übertragen.
Für eine PC-Architektur ist es z. B. sinnvoll, daß ein
Mastermodul, das die PC-Zentraleinheit (PC-CPU) und den/die
Interrupt-Controller enthält, alle Interrupt-Anforderungen
gemeldet bekommt. Hierzu wird ein Spezialfall eines VAK
verwendet. Alle Interrupt-Quellen müssen dann im Falle
eines Bus-Request anschließend den Zustand ihrer Interrupt-
Leitung auf den Bus legen. Der Einfachheit halber kann
beispielsweise der Interrupt IRQ0 auf der Leitung B0 und
der Interrupt IRQn auf der Leitung Bn liegen. In der Konfi
gurationsphase kann trotzdem standardmäßig vorgegangen
werden. Im Sender, d. h. Modulen, die den Interrupt melden,
wird je Interrupt-Leitung die RAK-Nummer und die Bus-Leitung
angegeben. Beim Empfänger (bei PC-Architektur der PC-Master
mit Interrupt-Controller) muß nur die RAK-Nummer angegeben
werden, in der die Interrupts geliefert werden. In den
Konfigurationsregistern der einzelnen BIU's wird für die
virtuellen Verbindungsleitungen je VIL beispielsweise fest
gelegt:
VIL:
Bit0: enable/disable der VIL
Bit1: Single-/Group-VIL
Bit2: Input/Output
Bit3: Übertragung von Pegel oder Flanke
Bit4-7: RAK-Nummer, bei der VIL übertragen wird (4 Bit)
Bit8-13: Bus-Leitung-Nummer, auf der VIL übertragen wird (nur bei Single-VIL).
VIL:
Bit0: enable/disable der VIL
Bit1: Single-/Group-VIL
Bit2: Input/Output
Bit3: Übertragung von Pegel oder Flanke
Bit4-7: RAK-Nummer, bei der VIL übertragen wird (4 Bit)
Bit8-13: Bus-Leitung-Nummer, auf der VIL übertragen wird (nur bei Single-VIL).
Weitere Bits können reserviert bleiben.
Die genannten Sätze der Konfigurationsregister werden in
einer Konfigurationsphase beschrieben.
Bei dem RAK-Befehl nach einem Bus-Request wird die entspre
chende Information bei entsprechender RAK-Nummer auf die
entsprechende Bus-Leitung gelegt. Die übrigen Leitungen
bleiben in einem sogenannten Tri-state Zustand, wodurch
sie freigegeben sind und dann von einem anderen Bus-Teil
nehmer "getrieben" und dadurch auf logisch 0 oder 1 gelegt
werden können.
Im Konfigurationsbereich, z. B. eines EEPROM's, der Module
steht die Information, welche Art von RAK die Funktion
erfordert und welche die BIU des jeweiligen Moduls be
herrscht. Dabei ist dort auch festgehalten, ob Einschrän
kungen der Zuordnung einer VIL auf eine Bus-Leitung besteht.
So muß unter Umständen bei der Konfiguration auf den Wunsch
einer VIL, auf eine bestimmte Bus-Leitung gelegt zu werden,
Rücksicht genommen werden.
Fig. 3 zeigt noch einmal detaillierter den zeitlichen Ablauf.
Vor dem Zeitpunkt t1 werden die Bus-Leitungen als CAD-Leitun
gen (für Command/Adressen/Daten) verwendet. Zum Zeitpunkt t1
möchte eines der Module ein Signal an mindestens ein anderes
Modul senden. Es gibt daher zum Zeitpunkt t1 ein Request-Sig
nal auf die Leitung RQ, zieht diese also auf logisch "0".
Der Bus-Master beendet seine laufende Bus-Aktivität zum
Zeitpunkt t2 und gibt das RAK-Kommando (Request Acknowledge)
als Befehl im Zeitintervall t2-t3 auf den Bus. Darauf folgt
eine Pause t3-t4 von beispielsweise der Länge eines Taktes.
Gleichzeitig legt der Bus-Master die Leitung AS auf logisch
"0". Dieses Signal zeigt allen Bus-Teilnehmern an, daß
ein Kommando, hier das RAK-Kommando auf dem Bus liegt.
Alle Bus-Teilnehmer werten das Signal AS und das Kommando
aus und erkennen, daß ein RAK-Befehl eingeleitet ist.
Aufgrund ihrer Konfiguration kennen sie ebenfalls die Anzahl
der VAK's, wodurch es ihnen möglich wird, den kompletten
RAK-Befehl zu verfolgen. Ist für dasjenige Modul, das den
Bus-Request abgesetzt hat, die konfigurierte VAK-Nummer
erreicht, beispielsweise die VAK-Nummer VAKx zum Zeitpunkt
t6, so gibt dieses Modul im Zeitintervall t6-t7 seine Infor
mation auf die Bus-Leitung oder -Leitungen, die während
dieses Zeitintervalles die Funktion von VIL-Leitungen haben.
Zum Zeitpunkt t7 nimmt dann dasjenige Modul, das den Request
abgesetzt hat, dieses wiederum von der Leitung RQ weg.
Hat kein weiteres Modul ein Request-Signal abgesetzt, so
geht die Leitung RQ wieder auf logisch "1". Zu diesem Zeit
punkt kann der RAK-Befehl abgebrochen werden. Es ist aber
auch möglich, diesen Befehl vollständig zu Ende zu führen
bis zum VAKn im Zeitintervall t8-t9. Zum Zeitpunkt t9 über
nimmt der Bus-Master oder eventuell ein neuer Bus-Master
wieder den Bus und kann seine Aktivitäten starten.
Prinzipiell ist vorgesehen, daß nach jedem VAK innerhalb
eines RAK-Befehl ein Takt Pause vorgesehen ist, um eine
eventuelle Bus-Umkehrung zu ermöglichen. Es ist aber auch
denkbar, daß bei aufeinanderfolgenden VAK's keine Umkehrung
des Bus erforderlich ist. In diesem Fall kann die Pause
entfallen. Im Konfigurationsbereich jeder BIU kann daher
ein Register vorgesehen sein, das festhält, ob das entspre
chende Modul Pausen unterdrücken kann und vor welchen VAK's
keine Pausen vorhanden sein müssen. Können alle vorhandenen
Module diese Pausen unterdrücken, kann während der Konfigura
tion die Verteilung der VIL's auch unter diesem Gesichtspunkt
stattfinden. Der Konfigurationsmaster setzt die entsprechen
den Register in den BIU's. In diesem Falle kann ein RAK-
Befehl schneller ablaufen.
Die Anzahl der weiteren VAK-Zyklen kann frei definiert
werden und im Prinzip beliebig groß sein. In den Konfigura
tionsregistern der BIU's sind die einzelnen VIL festgelegt.
Selbstverständlich werden nur so viele VAK-Zyklen durchge
führt, wie nötig sind, um alle definierten VIL's abzuwickeln.
Während eines VAK-Zyklus schalten die Module, die für diesen
VAK-Zyklus eine oder mehrere Ausgangsleitungen definiert
haben, die dafür konfigurierte CAD-Leitung aktiv und legen
sie auf den aktuellen Pegel bzw. Flanke des Ausgangssignals.
Alle Module, die für diesen Zyklus und für diese CAD-Leitung
einen Eingang definiert haben, speichern den Zustand der
Leitung zwischen und legen sie an den entsprechenden Eingang.
Das Signal AS kann auch noch für einen anderen Zweck verwen
det werden. Es könnte, wie in Fig. 3 gezeigt, nach dem
RAK-Kommando sofort wieder inaktiv (HIGH) werden. Es kann
aber auch weiter dazu benutzt werden, um dem angesprochenen
Bus-Teilnehmer die Länge des Befehls bzw. die Anzahl der
Daten mitzuteilen. Es sei ein 8-Bit breiter Bus angenommen.
Bei einem Schreibbefehl ist dem Empfänger der Daten die
Anzahl der Daten nicht bekannt, was manchmal auch für einen
Sender zutrifft, der am Anfang noch nicht weiß, wie viele
Daten in einem Befehl geschrieben werden sollen. Der Bus-
Master (CPU) kann z. B. nur 1 Byte, 1 Wort (= 2 Byte), ein
Doppelwort (4 Byte) oder noch mehr Daten in einem Befehl
übertragen wollen. Deshalb läßt er das Signal AS aktiv
LOW, solange er noch Daten senden will. Vor dem letzten
zu schreibenden Byte setzt er AS dann inaktiv HIGH und
beendet damit den Befehl. Bei einem Lesezugriff zeigt der
Master über AS ebenfalls an, wie lange er Daten lesen will.
Bei einem 16-Bit breiten Bus, wenn die kleinste adressierbare
Einheit wie üblich 1 Byte ist, kann folgendermaßen vorgegan
gen werden. Der Bus liefert bei einem Schreibbefehl bei
jedem Takt 2 Byte an den Empfänger. Der Empfänger kennt
aber nicht die Anzahl der tatsächlich vom Sender als gültig
abgeschickten Byte, welche von beiden Byte oder ob beide
gültig sind. Dies wird dann so gelöst, daß z. B. bei einem
Schreibzugriff dem Empfänger der Daten zum einen die Em
pfangsadresse (gerade oder ungerade) und zum anderen die
Anzahl als Modulo im Kommando mitgeteilt wird. Bei einem
16-Bit Bus benötigt man dazu im Kommando 1 Bit. Der Empfänger
der Daten kann daraus dann ermitteln, ob er beim letzten
Takt eines Befehls nur 1 Byte (dann immer das untere) oder
beide Byte verwerten soll. Solange es noch nicht der letzte
Takt ist, was er an AS aktiv LOW erkennt, verwertet es
beide Byte. Wenn AS inaktiv HIGH wird, ist es der letzte
Takt. Bei einem noch breiteren Bus ist es prinzipiell genau
so, nur daß es dann bei 32 Bit z. B. 2 Bit bedarf, um die
Anzahl Modulo im Kommando zu übertragen.
Ansonsten kann das Signal AS auch vom Master benutzt werden,
um den Bus-Teilnehmern den vorzeitigen Abbruch eines Befehls
anzuzeigen. Wenn das Ende für einen Bus-Teilnehmer zu früh
gekommen ist, weil er erst bei einem späteren RAK-Zyklus
an der Reihe ist, muß er selbst noch einmal einen Bus-Request
absetzen.
Ein weiterer Sonderfall eines VAK-Zyklus wird durch einen
Interrupt-Request eines Moduls ausgelöst. Auch dies wird
auf der Leitung RQ angekündigt. Der entsprechende VAK-Zyklus
ist dann als PAK (für PC-Interrupt-Acknowledge) definiert.
Aus Vereinfachungsgründen werden alle VIL's eines VAK's
zusammengefaßt und vordefiniert. Alle VIL-Eingänge eines
PAK's sind auf einem einzigen Master lokalisiert. Die VIL-
Ausgänge können auf verschiedenen Modulen lokalisiert sein,
wie bei den sonstigen VIL's auch. Der Master ist z. B. ein
PC-Modul und für PC-Kompatibilität konfiguriert. Während
eines PAK-Zyklus schalten die Module, die eine PC-Interrupt-
Leitung für diesen Master haben, die entsprechende Leitung
aktiv und legen sie auf den gewünschten Pegel. Der Master
speichert den Pegel zwischen und gibt ihn an seinen PC-kompa
tiblen Interrupt-Controller weiter. Nicht benutzte Interrupts
werden im Interrupt-Controller des Masters maskiert. Die
nicht benutzten Leitungen bleiben im Tri-State-Zustand.
Die Bedingung für das Auslösen eines Request bei einem
VIL kann in der Konfigurationsphase festgelegt werden.
Dabei sind folgende Möglichkeiten gegeben:
Der Pegel bzw. Zustand wird übertragen, wobei positive
und negative Flanken einen Request auslösen können. Dies
ist in Fig. 4 dargestellt. Im definierten VAK-Zyklus wird
immer der Zustand des entsprechenden Kanals übermittelt.
Ein Request wird bei einer Änderung des Kanalwertes (Flanke)
ausgelöst. Der in Fig. 4 mit gestrichelten Linien dargestell
te Request stammt von einem anderen Modul, das dann in
dem laufenden RAK-Zyklus zu einem entsprechenden Zeitfenster
mit bedient wird.
Eine weitere Möglichkeit besteht im Auslösen des Requests
durch eine Flanke (vgl. Fig. 5). Beim Auftreten einer positi
ven Flanke wird im entsprechenden VAK-Zyklus einmal der
Wert logisch "1" übertragen, sonst logisch "0".
Auch die Auslösung eines PC-Interrupts ist mit Hilfe der
VIL's möglich. Für eine Interrupt-Leitung wird eine VIL-Lei
tung zum Versenden gewählt. Alle PC-Interrupts können so
von verschiedenen Sendern während eines VAK's zum Empfänger
(Group VIL) gelangen und zur Weiterverarbeitung durch einen
Interrupt-Controller bereit gehalten werden.
Der Interrupt-Controller bei PC-Architekturen verlangt
zur korrekten Ausführung des Interrupts eine positive Flanke
an der IRQ-Leitung mit anschließendem positiven Pegel.
Im Normalfall (PC) wird die IRQ-Leitung nach dem Abarbeiten
des IRQ wieder auf logisch "0" gesetzt. Bei den VIL's würde
dies zum Auslösen eines weiteren RAK-Zyklus führen, um
den IRQ zurückzusetzen. Um dies zu sparen, kann auf Seiten
des Empfängers ein IRQ gemäß Fig. 6 behandelt werden. Die
Auslösung eines IRQ's durch ein VIL veranlaßt den Empfänger,
sein entsprechendes IRQ-Register für eine bestimmte Dauer
auf "0" zu setzen und anschließend den IRQ durch eine
positive Flanke mit anschließendem hohen Pegel anzuzeigen.
Selbst wenn das Register vorher nicht zurückgesetzt wurde,
wird der IRQ korrekt erkannt. Ein Rücksetzen des ent
sprechenden IRQ's ist also nicht mehr nötig.
Während der Konfigurationsphase ermittelt der Konfigurations
master die Anforderungen und Fähigkeiten der einzelnen
Module. Dadurch ist es ihm möglich, die VIL-Register in
allen Konfigurationsbereichen der BIU's zu beschreiben.
Will beispielsweise ein Modul A über eine VIL einem Modul B
den Auftritt eines Ereignisses melden, so muß während der
Konfiguration die VAK- und CAD-Nummer des VIL's im Modul A
(Output) mit den Nummern des VIL's von Modul B (Input)
übereinstimmen. Damit ist gewährleistet, daß die Information
zum selben Zeitpunkt (VAK-Nummer) auf einer definierten
Leitung (CAD-Nummer) übertragen wird. Der Konfigurationsma
ster verteilt die VIL's so, daß zum einen kein Konflikt,
zum anderen eine möglichst geringe Anzahl von VAK's benötigt
wird. Die Anzahl der VAK's ist ebenfalls in jeder BIU festge
halten (vom Konfigurationsmaster konfiguriert).
Die Fig. 7 bis 9 zeigen schematische Blockschaltbilder
von Bus-Schnittstellen-Einheiten (BIU), die für einen
Empfänger (Fig. 7), einen Bus-Master (Fig. 8) und einen
Sender (Fig. 9) konfiguriert sind. Da jedes Modul im
Regelfall als Sender und Empfänger arbeiten kann, sind
selbstverständlich die Schaltungen der Fig. 7 und 9 in
jedem Modul enthalten, wobei einzelne Baugruppen, wie Zähler,
etc. natürlich für Sender und Empfänger gemeinsam genutzt
werden können. Soweit ein Modul auch als Master arbeiten
kann, ist zusätzlich auch die Schaltung der Fig. 8 enthalten.
Die Fig. 7 bis 9 dienen also ausschließlich zur Erläuterung
des Grundprinzips der Erfindung. Bei der folgenden Beschrei
bung wird davon ausgegangen, daß alle drei BIU's 1e, 1m
und 1s bereits konfiguriert wurden. Die folgende Beschreibung
ist an den zeitlichen Ablauf angepaßt. Möchte ein Modul
als Sender ein Signal senden, so wird dieses vom Funktions
teil des Moduls zu der BIU 1s (Fig. 9) auf einer Leitung
2 übermittelt, beispielsweise in Form einer Impulsflanke,
die ein Flip-Flop 3 setzt. Der Ausgang Q des Flip-Flops
3 aktiviert ein Tri-State-Gatter 4, dessen Ausgang mit
der Request-Leitung 5 verbunden ist. Diese Leitung hat
einen Pull-up-Widerstand 6 und ist "active Low" betrieben.
Dadurch können auch mehrere Busteilnehmer- ggf. gleichzeitig
diese Leitung 5 aktivieren. Alle BIU's aller Module sind
an diese gemeinsame Leitung 5 angeschlossen.
Die BIU 1m des aktuellen Bus-Masters (Fig. 8) erkennt dieses
Signal auf Leitung 5 und weiß damit, daß "jemand etwas
zu melden hat" und löst einen RAK-Befehl aus. Dieses Signal
auf der Request-Leitung 5 geht in der BIU 1m des Masters
an eine Arbitrierung 7, wo ermittelt wird, wann der Bus
frei ist, um den RAK-Befehl durchzuführen. Diese Prüfung
erfolgt über Signale "Request CPU" und "Grant CPU". Das
Signal "Request CPU" kommt von der CPU des Masters und
fordert den Bus für die CPU dieses Masters an. Das Signal
"Grant CPU" zeigt der CPU des Masters an, wann der Bus
frei ist. Ist der Bus frei, so setzt die Arbitrierung 7
ein Signal "Grant BIU" aktiv, wodurch eine Start/Stop-Einheit
8, die beispielsweise ein Flip-Flop sein kann, die RAK-
Leitung 13 aktiv setzt und die VIL-Zyklen startet. Mit
diesem Signal wird ein Zähler 9m im Master gestartet, der
entsprechend der Konfiguration in der BIU des Masters die
maximale Anzahl von RAK-Takten mitzählt. Während des RAK-
Befehls ist der Bus für die CPU des Masters blockiert.
Wenn der Master die RAK-Leitung 13 aktiv gesetzt hat, läuft
in den BIU's des Senders (Fig. 9) und des Empfängers (Fig. 7)
parallel in etwa dasselbe ab. In beiden BIUs wird jeweils
ein Zähler 9e bzw. 9s gestartet, der die Takte (CLK) auf
der Leitung 5 mitzählt. Der Takt wird hier von einem Takt
generator 14 in der BIU des Masters bereitgestellt und
allen BIUs über eine einzige gemeinsame Taktleitung 15
zugeführt. Das Mitzählen der Takte erfolgt solange, wie
die Leitung 13 aktiv ist. Die Ausgänge der Zähler 9e und
9s werden einem Vergleicher 10e, 10s zugeführt und mit
dem Inhalt eines konfigurierten Registers 16e bzw. 16s
verglichen. In diesen Registern 16e, 16s ist somit die
RAK-Nummer des entsprechenden Taktes gespeichert, für den
der Sender bzw. Empfänger konfiguriert ist. Sobald der
Vergleicher 10s in der BIU des Senders eine Übereinstimmung
feststellt, also "sein" VIL-Zyklus erreicht ist, meldet
er dies über eine Leitung 12s an einen Decoder 18s, der
damit aktiviert wird und aus einem Register 17s eine
vorprogrammierte Leitungsnummer für die VIL decodiert.
Dadurch wird eines der Ausgangssignale 0 . . . 7 des Decoders
aktiv und zwar das, das der konfigurierten Leitungsnummer
des Bus entspricht. Über ein diesem Ausgang zugeordnetem
Tri-State-Buffer 19 wird der Zustand des zu sendenden
Signales auf die ausgewählte Bus-Leitung D0 . . . D7 gelegt
und ist somit für alle anderen Bus-Teilnehmer verfügbar.
In der BIU des Empfängers wird über den Zähler 9e, den
Vergleicher 10e und das Konfigurationsregister 16e in
gleicher Weise die konfigurierte RAK-Nummer erkannt. Ein
Multiplexer 18e, an dessen Eingänge IN 0 . . . IN 7 die Bus-
Leitungen D0 . . . D7 angeschlossen sind, wählt die konfigurierte
Leitung aus, aufgrund des Inhaltes eines Konfigurations
registers 17e für die Leitungsnummer. Der Ausgang OUT des
Multiplexers 18e führt somit das Signal auf der konfigu
rierten Bus-Leitung. Dieses Signal wird einem Flip-Flop
19 zugeführt, das nach einer vorgegebenen Verzögerungszeit,
die durch ein Verzögerungsglied 20 bestimmt ist, das Flip-
Flop 19 taktet, an dessen Ausgang Q das empfangene Signal
auf einer Leitung 2e an das Modul des Empfängers leitet.
Um also ein Signal vom Sender zum Empfänger zu übertragen,
müssen in beiden BIU's die Angaben "Konfiguration RAK-Nr."
und "Konfiguration Leitung-Nr." übereinstimmen.
Die gesamte Abwicklung eines RAK-Zyklus wird durch die
BIU 1m des Masters gesteuert. In einem Register 11m ist
die maximale Anzahl der RAK-Zyklen bzw. RAK-Takte konfi
guriert und wird in einem Vergleicher 10m mit dem Inhalt
des Zählers 9m verglichen. Ist die konfigurierte Anzahl
von Takten erreicht, so wird dies von dem Vergleicher 10m
an die Arbitrierung 7 gemeldet, die damit das Signal "Grant
BIU" deaktiviert, die Start/Stop-Einheit 8 zurücksetzt,
den Zähler 9 stoppt und das RAK-Signal auf der Leitung
13 deaktiviert.
Im Ausführungsbeispiel der Fig. 7 bis 9 ist zusätzlich
zur Request-Leitung 5 noch die RAK-Leitung 13 gezeigt,
an die alle BIU's angeschlossen sind. Diese Leitung ist
solange aktiv, wie der RAK-Zyklus läuft.
Weiter oben wurde auch der Fall behandelt, den RAK-Zyklus
zu verkürzen, d. h. nur solange laufen zu lassen, bis der
jenige Zyklus erreicht ist, der dem Sender, der einen Bus-
Request abgesetzt hat, sein zu sendendes Signal abgesetzt
hat. Da bei der hier beschriebenen Konfiguration das Signal
auf der Leitung 5 nur zum Auslösen eines RAK-Befehls verwen
det wird, während des RAK-Befehls aber nicht mehr benötigt
wird, kann diese Leitung dazu verwendet werden, ein ggf.
vorzeitiges Ende des RAK-Befehls anzuzeigen. Hierzu kann
in der BIU des Senders zu Beginn des RAK-Befehls "einge
froren" werden, daß sie einen Request angefordert hat.
Beispielsweise könnte am Ausgang des Tri-State-Gatters
4 ein weiteres Flip-Flop vorhanden sein, das diesen Zustand
speichert und die Leitung 5 solange aktiv hält, bis vom
Vergleicher 10s die Meldung kommt, daß die konfigurierte
RAK-Nummer erreicht ist. Danach - ggf. mit einer Verzögerung
von einem oder mehreren Takten - kann dieses Flip-Flop
rückgesetzt werden und die Leitung 5 inaktiv geschaltet
werden. Dies kann von der Arbitrierung 7 in der BIU des
Masters erkannt werden, worauf über die Start/Stop-Einheit
8 der RAK-Zyklus vorzeitig abgebrochen wird. Wenn mehrere
Module gleichzeitig oder während eines RAK-Zyklus einen
Request absetzen, so hält die BIU desjenigen Senders, der
laut Konfiguration als letzter an der Reihe ist, die Leitung
5 aktiv, womit sichergestellt ist, daß alle Requests bedient
werden.
Claims (7)
1. Verfahren zum Austausch von Signalen zwischen an einen
gemeinsamen Bus angeschlossenen Modulen, dadurch ge
kennzeichnet,
daß dasjenige Modul, das ein Signal senden möchte, ein Bus-Anforderungssignal an eine gemeinsame Lei tung (RQ) legt,
daß dasjenige Modul (Bus-Master), das den Bus zu diesem Zeitpunkt steuert, auf das Bus-Anforderungssignal seine momentane Bus-Aktivität beendet oder unterbricht und anschließend über den Bus ein Bestätigungskomman do (RAK) an alle Bus-Teilnehmer sendet,
daß darauffolgend jedes Modul Taktsignale auf einer gemeinsamen Taktleitung (CLK) mitzählt, wobei jeder Takt einen Zyklus (VAK0 . . . VAKn) definiert und jedem Modul (Mx) ein vorbestimmter Zyklus (VAKx) zugewiesen ist, und
daß dasjenige Modul (Mx), das das Bus-Anforderungssig nal abgesetzt hat, während des ihm zugewiesenen Zyk lus (VAKx) ein Signal auf mindestens eine vordefinierte Bus-Leitung ausgibt.
daß dasjenige Modul, das ein Signal senden möchte, ein Bus-Anforderungssignal an eine gemeinsame Lei tung (RQ) legt,
daß dasjenige Modul (Bus-Master), das den Bus zu diesem Zeitpunkt steuert, auf das Bus-Anforderungssignal seine momentane Bus-Aktivität beendet oder unterbricht und anschließend über den Bus ein Bestätigungskomman do (RAK) an alle Bus-Teilnehmer sendet,
daß darauffolgend jedes Modul Taktsignale auf einer gemeinsamen Taktleitung (CLK) mitzählt, wobei jeder Takt einen Zyklus (VAK0 . . . VAKn) definiert und jedem Modul (Mx) ein vorbestimmter Zyklus (VAKx) zugewiesen ist, und
daß dasjenige Modul (Mx), das das Bus-Anforderungssig nal abgesetzt hat, während des ihm zugewiesenen Zyk lus (VAKx) ein Signal auf mindestens eine vordefinierte Bus-Leitung ausgibt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß einige oder alle der vorbestimmten Zyklen
(VAK0 . . . VAKn) durch mindestens einen Takt, der eine
Pause bestimmt, voneinander getrennt sind.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeich
net,
daß dasjenige Modul, das das Bus-Anforderungssignal
abgesetzt hat, nach Ablauf des ihm zugewiesenen Zyklus
das Bus-Anforderungssignal beendet.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch
gekennzeichnet,
daß auf ein Bus-Anforderungssignal eine Zyklusfolge
mit einer Anzahl n Zyklen abläuft, mit n gleich Anzahl
von vordefinierten Verbindungen (VIL) geteilt durch
die Bus-Breite.
5. Verfahren nach einem der Ansprüche 1 bis 3, dadurch
gekennzeichnet,
daß auf ein Bus-Anforderungssignal eines Moduls (Mx)
eine Zyklusfolge mit nur so vielen Zyklen (x) abläuft,
wie der dem anfordernden Modul (Mx) zugeordneten Anzahl
von Zyklen entspricht.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet,
daß bei gleichzeitigem Absetzen mehrerer Bus-Anforde
rungssignale von mehreren Modulen so viele Zyklen
ablaufen, wie dem Modul entspricht, dessen zugeordneter
Zyklus zeitlich als letzter folgt.
7. Schaltungsanordnung zum Austausch von Signalen zwischen
an einen gemeinsamen Bus angeschlossenen Modulen,
dadurch gekennzeichnet,
daß alle Module (M0 . . . Mn) an eine gemeinsame Bus-Anfor derungsleitung (RQ) angeschlossen sind,
daß jedes Modul (M0 . . . Mn) eine Bus-Schnittstellenschal tung (BIU0 . . . BIUn) aufweist,
daß jede Schnittstelleneinheit (BIU0 . . . BIUn) ein pro grammierbares Register und einen Zähler aufweist, der Taktimpulse auf einer gemeinsamen Taktleitung (CLK) mitzählt,
daß jede Schnittstelleneinheit eine Einrichtung auf weist, die die gemeinsame Bus-Anforderungsleitung (BQ) auf einen vordefinierten Pegel setzt, wenn das Modul ein Signal auf den Bus liefern will,
daß mindestens ein Modul (Bus-Master) eine Schaltungs einheit aufweist, die ständig den Zustand der Bus-An forderungsleitung (RQ) überwacht und bei Auftreten des vorbestimmten Signals ein vordefiniertes Kommando auf den Bus ausgibt,
daß die Bus-Schnittstelleneinheiten (BIU0 . . . BIUn) aller Module nach diesem Kommando die Takte mitzählen, daß in dem Register jeder Bus-Schnittstelleneinheit eine dem individuellen Modul zugewiesene Taktzahl gespeichert ist und
daß dasjenige Modul, das das Bus-Anforderungssignal abgesetzt hat, bei Erreichen der ihm zugewiesenen Taktzahl ein Signal auf einige oder alle Leitungen (B0 . . . Bn) des Bus gibt.
daß alle Module (M0 . . . Mn) an eine gemeinsame Bus-Anfor derungsleitung (RQ) angeschlossen sind,
daß jedes Modul (M0 . . . Mn) eine Bus-Schnittstellenschal tung (BIU0 . . . BIUn) aufweist,
daß jede Schnittstelleneinheit (BIU0 . . . BIUn) ein pro grammierbares Register und einen Zähler aufweist, der Taktimpulse auf einer gemeinsamen Taktleitung (CLK) mitzählt,
daß jede Schnittstelleneinheit eine Einrichtung auf weist, die die gemeinsame Bus-Anforderungsleitung (BQ) auf einen vordefinierten Pegel setzt, wenn das Modul ein Signal auf den Bus liefern will,
daß mindestens ein Modul (Bus-Master) eine Schaltungs einheit aufweist, die ständig den Zustand der Bus-An forderungsleitung (RQ) überwacht und bei Auftreten des vorbestimmten Signals ein vordefiniertes Kommando auf den Bus ausgibt,
daß die Bus-Schnittstelleneinheiten (BIU0 . . . BIUn) aller Module nach diesem Kommando die Takte mitzählen, daß in dem Register jeder Bus-Schnittstelleneinheit eine dem individuellen Modul zugewiesene Taktzahl gespeichert ist und
daß dasjenige Modul, das das Bus-Anforderungssignal abgesetzt hat, bei Erreichen der ihm zugewiesenen Taktzahl ein Signal auf einige oder alle Leitungen (B0 . . . Bn) des Bus gibt.
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19756885A DE19756885B4 (de) | 1997-12-19 | 1997-12-19 | Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie Vorrichtung zur Durchführung des Verfahrens |
US09/367,725 US6425031B1 (en) | 1997-12-19 | 1998-12-18 | Method for exchanging signals between modules connected via a bus, and a device for carrying out said method |
EP98965282A EP0961975A1 (de) | 1997-12-19 | 1998-12-18 | Verfahren zum austausch von signalen zwischen über einen bus verbundenen modulen sowie vorrichtung zur durchführung des verfahrens |
CA002281589A CA2281589C (en) | 1997-12-19 | 1998-12-18 | Method for exchanging signals between modules connected via a bus and a device for carrying out said method |
PCT/EP1998/008318 WO1999032983A1 (de) | 1997-12-19 | 1998-12-18 | Verfahren zum austausch von signalen zwischen über einen bus verbundenen modulen sowie vorrichtung zur durchführung des verfahrens |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19756885A DE19756885B4 (de) | 1997-12-19 | 1997-12-19 | Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie Vorrichtung zur Durchführung des Verfahrens |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19756885A1 true DE19756885A1 (de) | 1999-06-24 |
DE19756885B4 DE19756885B4 (de) | 2005-04-21 |
Family
ID=7852750
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19756885A Expired - Fee Related DE19756885B4 (de) | 1997-12-19 | 1997-12-19 | Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie Vorrichtung zur Durchführung des Verfahrens |
Country Status (5)
Country | Link |
---|---|
US (1) | US6425031B1 (de) |
EP (1) | EP0961975A1 (de) |
CA (1) | CA2281589C (de) |
DE (1) | DE19756885B4 (de) |
WO (1) | WO1999032983A1 (de) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6775328B1 (en) * | 1999-08-11 | 2004-08-10 | Rambus Inc. | High-speed communication system with a feedback synchronization loop |
DE10011934A1 (de) * | 2000-03-11 | 2001-09-13 | Tenovis Gmbh & Co Kg | Elektrisches Gerät |
EP1150467A1 (de) * | 2000-04-28 | 2001-10-31 | STMicroelectronics S.r.l. | Kodierstruktur für Parellelbusse |
DE102009027625A1 (de) * | 2009-07-10 | 2011-01-13 | Robert Bosch Gmbh | Elektrische Schaltung zur Übertragung von Signalen zwischen zwei Mastern und einem oder mehreren Slaves |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5088024A (en) * | 1989-01-31 | 1992-02-11 | Wisconsin Alumni Research Foundation | Round-robin protocol method for arbitrating access to a shared bus arbitration providing preference to lower priority units after bus access by a higher priority unit |
US5263163A (en) * | 1990-01-19 | 1993-11-16 | Codex Corporation | Arbitration among multiple users of a shared resource |
US5301283A (en) * | 1992-04-16 | 1994-04-05 | Digital Equipment Corporation | Dynamic arbitration for system bus control in multiprocessor data processing system |
US5623672A (en) | 1994-12-23 | 1997-04-22 | Cirrus Logic, Inc. | Arrangement and method of arbitration for a resource with shared user request signals and dynamic priority assignment |
US5907689A (en) * | 1996-12-31 | 1999-05-25 | Compaq Computer Corporation | Master-target based arbitration priority |
US6223237B1 (en) * | 1998-07-07 | 2001-04-24 | Adaptive Systems, Inc. | Expandable communications bus |
-
1997
- 1997-12-19 DE DE19756885A patent/DE19756885B4/de not_active Expired - Fee Related
-
1998
- 1998-12-18 EP EP98965282A patent/EP0961975A1/de not_active Withdrawn
- 1998-12-18 WO PCT/EP1998/008318 patent/WO1999032983A1/de active Application Filing
- 1998-12-18 US US09/367,725 patent/US6425031B1/en not_active Expired - Fee Related
- 1998-12-18 CA CA002281589A patent/CA2281589C/en not_active Expired - Fee Related
Non-Patent Citations (1)
Title |
---|
Färber, G.: Bussysteme, R. Oldenbourg Verlag, München, Wien, 1987, 2. Aufl., S. 55-58, 90-92 * |
Also Published As
Publication number | Publication date |
---|---|
DE19756885B4 (de) | 2005-04-21 |
WO1999032983A1 (de) | 1999-07-01 |
US6425031B1 (en) | 2002-07-23 |
CA2281589A1 (en) | 1999-07-01 |
CA2281589C (en) | 2005-02-08 |
EP0961975A1 (de) | 1999-12-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE68922784T2 (de) | Mehrfachbus-Mikrorechnersystem mit Busarbitrierung. | |
DE3300260C2 (de) | ||
DE3300262C2 (de) | ||
DE3853574T2 (de) | Steuerung von Benutzerantworten in einem Übertragungsbus. | |
DE3300261C2 (de) | ||
EP0179936B1 (de) | Verfahren und Einrichtung zur Steuerung einer Sammelleitung | |
DE3914265C2 (de) | ||
DE3204905C2 (de) | ||
EP0772832B1 (de) | Arbitrierung bei verzögernder buskopplung | |
EP0577919B1 (de) | Zugriffssteuerung für gekoppelte maskenprogrammierte Mikrocontroller | |
DE3704056A1 (de) | Peripherer dma-controller fuer datenerfassungssysteme | |
DE2015971C3 (de) | Datenverarbeitungsanlage mit einer Anzahl von zeitmultiplex von einem zentralen Rechenwerk bedienten virtuellen Prozessoren | |
DE3606211A1 (de) | Multiprozessor-computersystem | |
DE2746064A1 (de) | Datenspeicher mit auffrischung | |
DE3642324A1 (de) | Multiprozessoranlage mit prozessor-zugriffssteuerung | |
DE4214303C2 (de) | Kommunikationssystem | |
DE69128985T2 (de) | IEEE488-Schnittstelle | |
DE69230483T2 (de) | Quadraturbusprotokoll zum Ausführen von Transaktionen in einer Rechneranordnung | |
EP0185260B1 (de) | Schnittstelle für direkten Nachrichtenaustausch | |
EP0175095B1 (de) | Datenübertragungsverfahren über einen Multiprozessorbus | |
DE19756885A1 (de) | Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie Vorrichtung zur Durchführung des Verfahrens | |
DE3783384T2 (de) | Hochgeschwindigkeitsleitung zur verbindung demokratischer systeme. | |
EP1308846B1 (de) | Datenübertragungseinrichtung | |
EP1567938B1 (de) | Speichersystem mit mehreren speichercontrollern and verfahren zu deren synchronisierung | |
DE69625685T2 (de) | Verfahren und vorrichtung zur reduzierung der latenzzeit in einer schnittstelle mittels überlappender paketübertragung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8364 | No opposition during term of opposition | ||
R081 | Change of applicant/patentee |
Owner name: BRINKHUS, ILKA, DE Free format text: FORMER OWNER: BRINKHUS, HARTMUT B., DR., 69126 HEIDELBERG, DE Effective date: 20131212 |
|
R082 | Change of representative |
Representative=s name: BUELOW, TAM VON, DIPL.-ING.DIPL.-WIRTSCH.-ING., DE Effective date: 20131212 |
|
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |