-
Verfahren
zum Betreiben eines Kommunikationskanals in einer gemischten Master-/Slave-Teilnehmerumgebung
durch eine dynamische Schließ- und/oder Öffnungsoperation
und System zur Durchführung
des Verfahrens
-
HINTERGRUND DER ERFINDUNG
-
Die
vorliegende Erfindung bezieht sich auf ein Verfahren zum Betreiben
eines Kommunikationskanals in einer gemischten Master-/Slave-Teilnehmerumgebung
durch eine dynamische Schließ- und/oder Öffnungsoperation.
Der Kanal kann ein serieller oder paralleler Bus, ein Hardware-Netzwerk
in einer anderen Konfiguration oder sogar ein drahtloses Subsystem
sein. Ein Teilnehmer kann eine Hardware-Station sein, oder ein oder
eine Anzahl koexistenter und/oder interaktiver Prozesse, oder sogar
ein Gemisch aus Hardware- und Software-Entitäten sein. Bei zunehmender Systemkomplexität kann das Schließen und Öffnen eines
derartigen Kommunikationskanals zwischen gegenseitig verbundenen
Modulen immer schwerer werden. Der Hauptgrund ist, dass die Module,
auf denen das System gegründet ist,
eine derartige interne Komplexität
haben können, dass
Kommunikation, Beendigung und Anfang nicht immer zu jedem beliebigen
Zeitpunkt stattfinden kann.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Es
ist u. a. eine Aufgabe der vorliegenden Erfindung, eine unkomplizierte
und einfach implementierbare Lösung
des oben genannten Problems zu schaffen. Dazu wird ein Verfahren
beschrieben zum Vermeiden von Schließ- und Startproblemen von Kommunikationskanälen durch
Verwendung eines Handshake-Protokolls zwischen allen betreffenden Modulen
auf der einen Seite und einem zentralen Kommunikationsverwaltungsmodul
auf der anderen Seite. Dazu ist ein Aspekt der vorliegenden Erfindung in
Anspruch 1 definiert.
-
Zum
Organisieren einer Zusammenfassungssituation wird vielmehr die Umkehrsequenz des
Obenstehenden effektuiert, entsprechend einem zweiten Aspekt der
vorliegenden Erfindung, wie in Anspruch 2 definiert. Insbesondere
beziehen sich vorteilhafte Aspekte der vorliegenden Erfindung auf Einsparung
von Energie und auf die Handhabung einer Unterbrechungsroutine.
-
Die
vorliegende Erfindung bezieht sich ebenfalls auf ein System zum
Implementieren eines Verfahrens entsprechend dem Obenstehenden.
Weitere vorteilhafte Ausführungsformen
der vorliegenden Erfindung sind in den beiliegenden Unteransprüchen spezifiziert.
-
KURZE BESCHREIBUNG DER
ZEICHNUNG
-
Ausführungsbeispiele
der Erfindung sind in der Zeichnung dargestellt und werden im vorliegenden
Fall näher
beschrieben. Es zeigen:
-
1 eine
Gesamtarchitektur nach der vorliegenden Erfindung,
-
2 Ausführungsformen
der Schließ-
und Öffnungssequenzen,
-
3 Ausführungsformen
zum Unterbrechen von Handhabungssequenzen.
-
DETAILLIERTE BESCHREIBUNG
BEVORZUGTER AUSFÜHRUNGSFORMEN
-
Die
Ausführungsform,
die das Verhalten dieses Kommunikationsumschaltprotokolls illustriert, besteht
aus Hardware-Modulen mit einer Komplexität, wie man sie in Prozessorarchitektur
sieht, beispielsweise CPUs, UARTs, Speichercontrollern und DMA-Maschinen. Diese
Module sind über
einen Kommunikationskanal, beispielsweise ein On-Chip-Bussystem miteinander verbunden
und kann in diesem Kanal als Master, als Slave oder als Master/Slage-Agent
wirksam sein. Das Kommunikationsschaltprotokoll ist aber nicht auf
eine Hardware-Implementierung begrenzt und kann beispielsweise auch
in einer Software-Modulumgebung verwendet werden, u. a. zum Organisieren
von Interprozesskommunikation.
-
Problembeschreibung:
Für die
heutigen komplexen Gebäudeblöcke, wie
oben beschrieben, ist es nicht immer möglich, Kommunikation zu jedem beliebigen
Zeitpunkt rechtzeitig zu bilden. Es kann beispielsweise notwendig
sein, dass ein Software-Prozess
zunächst
einen internen Puffer oder eine interne Pipeline reinigt, bevor
ein Kommunikationskanal geschlossen werden kann, oder dass ein Hardware-Speichercontrollermodul
intern die Daten zu einem langsamen dynamischen Speicher aktualisieren muss.
Um es zu ermöglichen,
dass es zu einem normalen Betrieb kommt, wenn der Kanal wieder geöffnet wird,
müssen
alle Module (Master und Slaves) sich in einem gut definierten Zustand
befinden, wenn die Kommunikation abgeschaltet wird. Es wird oft versucht,
einen derartigen Zustand mit Hilfe einer Abschluss-Software-Routine
zu erreichen. Wenn es sich dabei um viele Master handelt, kann es
sein, dass dies nicht immer durch Software völlig steuerbar ist und dass
es ein langwieriger Prozess wird. So kann beispielsweise eine CPU
eine Stilllegungssequenz durchführen,
wenn ein unabhängiger
Master autonom Fehlerbeseitigungsbefehle durchführt oder eine IO-Anordnung
plötzlich
externe Daten empfängt.
Es kann auch eine Startsequenz erforderlich sein, damit Module wieder
völlig
funktionell arbeiten, wie das Zurückschalten des Erneuerungsprozesses eines
eingebetteten dynamischen Speichers zu dem Systemtaktgeber oder
einem Controller, der die interne Pipeline füllt.
-
Als
Lösung
zur Verringerung der Belastung um Software zu schreiben (oft komplexer
Echtzeit-Software) für
solche Stilllegungs- und Startsequenzen, wird vorgeschlagen, mit
Hilfe zweier Signale einen Handshaking-Mechanismus zu implementieren,
wobei diese Signale jeden Bus-Agenten, der sich in einem derart
definierten Zustand befindet, mit einem weiteren Bus-Agenten zu
verbinden, als ein zentrales Kommunikationsverwaltungsmodul "cmm" 20 in 1.
-
Das
Abschließen
des Kommunikationskanals geschieht wie folgt. Wenn der Kanal geschlossen
werden muss, beispielsweise vorgegeben durch Software, die in einer
CPU läuft,
wird das cmm mit Hilfe eines Befehls 32 zum Abschließen der
Kommunikation instruiert, wobei dieser Befehl an ein internes Stilllegungssteuerregister
gerichtet ist, eine Stilllegungssequenz auszulösen. Daraufhin sendet das cmm
jedem Master 22, 26 zunächst ein betreffendes master_halt
Signal (Halt_M1 und Halt_M2) um zu signalisieren, dass sie die aktuellen
Kommunikationsaktivitäten
beenden sollen und dass sie ihren Kommunikationsteil in einen definierten
Zustand bringen sollen, aus dem ein einwandfreier Start gewährleistet sein
wird. Das Zuführen
dieser vielen master_halt Signale kann gleichzeitig oder sequentiell
erfolgen, je nach den Entwurfsaspekte des Systems. Wenn ein Master
bereit ist und wenn der Kommunikationsteil oder der Prozess sich
in einem definierten Stilllegungszustand befindet, sendet er sein
master halted Signal (M1_halted und M2_halted) zur Information an
das cmm. Von dem Zeitpunkt, an dem alle Master ihr master halted
Signal gesendet haben, ist gewährleistet,
dass es überhaupt
keine Kommunikation über
den Kanal mehr gibt und das cmm sendet dann die halt_slaves Signale
(Halt_S1 und Halt_S2) zu den Slaves 24, 28 um
sie zu steuern, eine Stillegungsmode anzunehmen. Auch dies kann
wieder gleichzeitig oder sequentiell erfolgen. Wenn die Slaves ihren
Kommunikationsteil oder den Prozess in einen definierten Stilllegungszustand
gebracht haben, senden sie ihre slave_halted Signale (1_halted und S2_halted).
Das cmm 20 kann nun ggf. einen Zustand schaffen "Kommunikationen abgeschaltet", und zwar über eine
nicht dargestellte Verbindung zu einem höheren Item.
-
Das Öffnen des
Kommunikationskanals geschieht wie folgt. Je nach den System- und
Implementierungsumständen
kann eine bestimmte Begebenheit dafür sorgen, dass der Kommunikationskanal
geöffnet
wird. Diese Begebenheit führt
dazu, dass das cmm über
dieselben Signale, die verwendet werden um Kommunikation still zu
legen, eine Startsequenz auslöst.
Bei der Ausführungsform
wird für
jedes Signal eine Einrichtungs-Ein-Bit-Leitung verwendet. Diese Sequenz kann
notwendig sein, wenn Module etwas Zeit brauchen um wieder völlig operationell
zu sein. Im Vergleich zu "Schließen des
Kommunikationskanals" wird
die umgekehrte Reihenfolge angewandt, weil, wenn die Slaves normal
funktionieren, gewährleistet
ist, dass wenn ein Master damit anfängt, über den Kommunikationskanal
zu wirken, dieser einen normalen Zugriff auf jeden Slave erhält. Deswegen
werden nach diesem Startvorgang die halt_slaves Signale nicht mehr
aufrecht erhalten und wenn alle Slaves ihre begleitenden slave_halted
Signale beendet haben, wird das cmm die halt_master Signale beenden
und wird darauf warten, dass alle master_halted Signale inaktiv
werden. Von diesem Zeitpunkt an ist das System wieder völlig operationell. 2 illustriert
diesen Mechanismus mit Hilfe von Zeitdiagrammen. Halt_M(x) und Halt_S(x)
sind die einzelnen Signale Halt_M1, Halt_M2, Halt_S1, usw., wie
in 1 beschrieben. Unter bestimmten Umständen könnten die
letzten Zeilen über
mehr als einen einzigen Master oder über mehr als nur einen Slave
geteilt werden.
-
In
Reaktion auf die Ausgabe eines Befehls zum Schließen der
Kommunikationen zu dem ccm sendet das Modul die Halt_M(x) Signale.
Zu dem Zeitpunkt 1 startet die Stilllegungssequenz der
Master. Zu dem Zeitpunkt 2 haben alle Master signalisiert, dass
sie mit den internen Aktivitäten
fertig sind und dass gewährleistet
wird, dass überhaupt
keine Kommunikation mehr stattfindet. Dadurch sendet das ccm die
Halt_S(x) Signale und die Stilllegungssequenz für die Slaves startet. Zu dem
Zeitpunkt 3 sind alle Slaves fertig mit deren internen
Aktivitäten
und der Kommunikationskanal wird geschlossen, dargestellt durch
das Signal Chan_off. Zwischen den Zeitpunkten 3 und 4 ist
der Kommunikationskanal geschlossen. Wenn das Bedürfnis nach
Kommunikation über den
Kanal zu dem Zeitpunkt 4 auftritt, beispielsweise durch
ein nicht dargestelltes externes Ereignis, sendet das cmm 20 Halt_S(x).
Wenn als Reaktion darauf alle slave_halted Signale von den Slaves
zu dem Zeitpunkt 5 beendet werden, können die Halt_M(x) Signale
von dem ccm beendet werden und die Master gelangen in ihre Startsequenz.
Sie signalisieren einen Fertig-Zustand
zu dem ccm mit Hilfe deren betreffenden master_halted Signale. Alle
werden zu dem Zeitpunkt 6 beendet und das ganze System
und der Kommunikationskanal ist wieder völlig funktionell.
-
Ein
open_event kann auftreten während
der Schließvorgang
des Kommunikationskanals stattfindet, beispielsweise durch eine
externe oder interne Unterbrechung. Wenn ein derartiges open_event auftritt,
während
das System in einer Stilllegungssequenz begriffen ist, tritt eine
Art von "touch and
go" Verhalten auf:
Master und Slaves, die ihre Kommunikation bereits beendet haben,
fassen die Kommunikation wieder auf, als wären sie in einer Startsequenz begriffen
zu einem Zeitpunkt, der gegenüber
dem geschlossenen Zustand zwischen den Zeitpunkten 3 und 4 in
einem symmetrischen Intervall liegt. Dies ist in 3 dargestellt,
wo die vertikalen Pfeile A und B einen Sprung innerhalb des Handshake-Protokolls angeben,
wenn ein open_event auftritt. Auf diese Weise springt, wenn das
Ereignis zwischen den Zeitpunkten 2 und 3 auftritt,
das System zu dem Intervall zwischen den Zeitpunkten 4 und 5.
-
Wenn
ein open_event auftritt, wenn das System sich bereits in der Startsequenz
befindet oder wenn der Kanal offen ist, wird das Ereignis ignoriert. Dies
ist durch die Punkte C und D illustriert, wo kein Pfeil gezeichnet
ist und das System das Startverhalten fortsetzt.
-
Das
Protokoll schreibt nicht vorm ob das System autonom in die Stilllegungsmode
zurückgeht nach
dem Auftritt und nach der Abfertigung des open_events, oder ob es
auf einen weiteren Stilllegungsbefehl wartet. Dies kann entsprechend
Systemanforderungen definiert werden.
-
Anwendungsbeispiel.
Zum Reduzieren von Leistungsverlust in integrierten Schaltungen
ist es sehr effektiv, einen oder mehrere Globaltaktgeber auszuschalten,
die einen Oszillator und/oder eine PLL enthalten können, wenn
innerhalb dieser Taktgeberdomänen
keine Systemaktivität
erforderlich ist. So dient beispielsweise in einem on-chip busorientierten
System das Chan_off Signal als Taktschalthinweissignal. Es dürfte einleuchten,
dass ein globaler Systemtaktgeber nur dann abgeschaltet werden darf, wenn
alle Module sich in einem gut definierten internen Zustand befinden,
so dass das Abschalten des Taktgebers keine Fehler verursacht, weder
in dem Kommunikationskanal, noch in dem internen Verhalten des Moduls.
Deswegen können
die master_halted und slave_halted Signale mit dem internen Zustand
des Moduls kombiniert werden. In dieser Applikation schaltet das
cmm den Taktgeber ein bevor die Startsequenz ausgelöst wird
um einen normalen Betrieb ggf. wieder aufzunehmen.
-
Folgerungen.
Wenn dieses Öffnungs-
und Schließprotokoll
für Kommunikationskanäle mit Hilfe des
beschriebenen Handshake-Mechanismus implementiert wird, wird die
Stilllegungs- und Startsequenz die Belastung, komplexe Software
für komplexe
Module und komplexe funktionelle Master-Slave-Abhängigkeiten
innerhalb einer Umgebung auf Basis eines modularen Kommunikationskanals
zu schreiben, verringert. Wenn es sich um einfache Kommunikationskanalagenten
handelt, brauchen sie nicht in dem Handshake-Protokoll integriert zu sein, so dass
Optimierungen für
einfachere Systemarchitekturen gemacht werden können. Auch in einer Situation,
in der es keine funktionellen Abhängigkeiten zwischen Mastern
gibt, können
verschiedene halt master Signale zu einem einzigen Signal kombiniert
werden, was auch für
Slaves gilt. Mit Hilfe dieses Protokolls kann ein sicherer globaler
Taktschaltmechanismus auf einem Systempegel geschaffen werden.
-
Text in der Zeichnung
-
1
-