DE60130836T2

DE60130836T2 - Architektur und Verfahren zur Kontextumschaltung

Info

Publication number: DE60130836T2
Application number: DE60130836T
Authority: DE
Inventors: Sherman Irvine Lee; John H. Irvine Lin; Vivian Y. Irvine Chou
Original assignee: Broadcom Corp
Current assignee: Broadcom Corp
Priority date: 2000-06-12
Filing date: 2001-06-12
Publication date: 2008-07-17
Anticipated expiration: 2021-06-13
Also published as: DE60130836D1; EP1168158A2; US20060101164A1; EP1168158B1; EP1168158A3

Description

Teile der vorliegenden Patentanmeldung enthalten durch Copyright geschütztes Material. Der Copyright-Inhaber hat keine Einwände gegen eine Faksimile-Wiedergabe des Patentdokumentes bzw. des Offenlegungsgehaltes des Patentes in der Form, in der es in den Aufzeichnungen oder Registern des Patent- und Markenamtes vorliegt, behält sich jedoch ansonsten jegliche Copyright-Rechte vor.
HINTERGRUND
Gebiet der Erfindung
Die vorliegende Erfindung betrifft Rechensysteme und insbesondere eine Architektur und ein System zum Umschalten von Kontexten, bei denen die Kontextumschaltung durch die Verwendung von Hardware-Registern zum Speichern von Kontextdaten beschleunigt ist.
Beschreibung des einschlägigen Standes der Technik
Die Bluetooth-Spezifikation ist eine offene technische Spezifikation und ein de facto-Standard für eine drahtlose (Funk-)Kommunikationstechnologie. Die Bluetooth-Technologie ist eine Nahbereichs-Niedrigleistungsfunkverbindung für die Übertragung von digitalen Daten und analogen Stimmdaten. Bluetooth ermöglicht es, die zahlreichen und vielfältigen herstellerspezifischen Kabel, die einen Computer oder eine Kommunikationsvorrichtung mit einem bzw. einer Anderen verbinden, durch eine universelle Nahbereichs-Funkverbindung zu ersetzen. Anwender können daher eine große Auswahl von Rechen- und Telekommunikationsvorrichtungen verbinden, ohne Kabel kaufen, tragen oder anschließen zu müssen. Beispielsweise kann ein Computer mit einem Drucker statt eines Kabels über eine Funkverbindung kommunizieren. Bluetooth ermöglicht auch die Verbindung von Rechenvorrichtungen mit einer Kommunikationsvorrichtung über eine Funkverbindung. Beispielsweise kann ein Computer mit einem Mobiltelefon über eine Funkverbindung kommunizieren, um auf das Internet zuzugreifen.
Bluetooth-Systeme schließen sich in Piconetze zusammen, die von einem Master-System gebildet werden, das sich mit zumindest einem anderen System verbindet, mit dem es sich den gleichen Kanal teilt. Die meisten Bluetooth-Systeme können entweder als ein Master oder als ein Slave agieren; die Begriffe "Master" und "Slave" beziehen sich hierbei lediglich auf die Rollen, die von jeder Vorrichtung innerhalb eines bestimmten Piconetzes erfüllt werden. Ein Bluetooth-System dient als der Master des Piconetzes. Zusätzlich zu dem Master kann ein Piconetz eine zusätzliche Anzahl von Bluetooth-Systemen aufweisen, die als Slaves dienen. Für weitere Einzelheiten möge man auf die "Specification of the Bluetooth System-Core v1.0b" Bezug nehmen, die von der Bluetooth Special Interest Group auf deren Website verfügbar ist: Part B, "Baseband Specification", von Vol. I ("Core") Ver. 1.0b der Bluetooth-Spezifikation.
Jeder Master eines Bluetooth-Piconetzes kann Kontexte von einem Slave zu einem Anderen umschalten. Da ein Slave darüber hinaus an mehr als einem Piconetz teilnehmen kann, kann ein Slave Kontexte zwischen Master umschalten. Herkömmliche Ansätze machen den Kontext-Umschaltevorgang langsam und kompliziert. Es wird ein System und Verfahren benötigt, um relativ schnelle Kontextumschaltungen vornehmen und gleichzeitig ein annehmbares Niveau an Netzwerkdurchsatz aufrecht erhalten zu können.
Die Schrift US-A-5 655 132 beschreibt ein mit einem Datenspeicher verbundenes Register-File und eine arithmetische Logikeinheit zum vorübergehenden Speichern von Operanden, sowie ein Verfahren zum Verwalten solcher Register-Files. Bei diesem Verfahren besitzt jedes Register eine eindeutige absolute Adresse.
Die Schrift US-A-5 659 749 beschreibt ein System und ein Verfahren zur Durchführung von Hardware-Kontextumschaltungen in einem computergesteuerten Instrumentierungssystem.
Die Schrift US-A-5 903 919 beschreibt ein Verfahren zum Auswählen von einer aus einer Mehrzahl von Registerbänken in einem Register-File eines Datenprozessors.
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zum Durchführen einer Kontextumschalte-Operation zur Verfügung zu stellen, um über die Fähigkeit zu verfügen, Kontexte schnell umzuschalten und dadurch eine schnelle und einfache Kommunikation zwischen drahtlosen Vorrichtungen in einem Netz zu erleichtern.
Diese Aufgabe wird durch ein Verfahren gemäß den Angaben in dem nebengeordneten Anspruch 1 und ein System gemäß den Angaben in dem nebengeordneten Anspruch 7 gelöst.
Diese Aufgabe wird insbesondere dadurch gelöst, dass die Notwendigkeit beseitigt wird, bei jeder Kontextumschaltung Kontextinformationen von einem Host-Computer zu einem peripheren System zu übertragen, da ein solcher Transfer die Kontextumschalte-Operation verlangsamt und das Netz mit der Übertragung von Kontextinformationen belastet.
Vorteilhafte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen definiert.
Ein beispielhaftes Verfahren zum Durchführen einer Kontextumschalte-Operation beinhaltet das Zugreifen auf Kontextdaten in einem ersten Register eines peripheren Systems, wobei das erste Register einem ersten Indexregister zugeordnet ist. Das Verfahren umfasst ferner das Empfangen eines zweiten Indexwertes von einem Host-Computer, der dem peripheren System zugeordnet ist. Dadurch, dass der Host-Computer beim Zugreifen des peripheren Systems auf das erste Register den zweiten Indexwert zur Verfügung stellte, wird eine Kontextumschaltung von dem ersten Register auf das zweite Register veranlasst. Daher umfasst das Verfahren ferner ein Zugreifen auf Kontextdaten in einem zweiten Register des peripheren Systems, wobei das zweite Register dem zweiten Indexwert zugeordnet ist. Bei zumindest einer Ausführungsform des Verfahrens sind das erste und das zweite Register keine architektonisch ausgeführten Register.
Bei zumindest einer beispielhaften Ausführungsform umfasst das Zugreifen auf die Kontextdaten in dem zweiten Register ferner das Durchführen einer Funktion des Schreibens an eine identifizierte Adresse in dem zweiten Register. Bei zumindest einer anderen Ausführungsform umfasst das Zugreifen auf die Kontextdaten in dem zweiten Register ferner das Liefern des Inhaltes einer identifizierten Adresse in dem zweiten Register an den Host-Computer. Bei zumindest einer anderen Ausführungsform umfasst das Zugreifen auf die Kontextdaten in dem zweiten Register ferner das Durchführen einer Leseoperation in Abhängigkeit von dem Wert eines Steuereingangs. Bei zumindest einer anderen Ausführungsform umfasst das Zugreifen auf die Kontextdaten in dem zweiten Register ferner das Durchführen einer Schreiboperation in Abhängigkeit von dem Wert eines Steuereingangs.
Zumindest eine beispielhafte Ausführungsform eines Systems weist auf: einen Host-Computer, der einen Mikroprozessor aufweist, zumindest ein mit dem Host-Computer gekoppeltes peripheres System, eine Schnittstelle zwischen dem Host-Computer und dem peripheren System, und eine mit dem peripheren System gekoppelte Registerzugriffschaltung. Das periphere System weist ein erstes Register auf, das einem ersten Indexwert zugeordnet ist, und weist auch ein zweites Register auf, das einem zweiten Indexwert zugeordnet ist. Die Schnittstelle ist dazu konfiguriert, den ersten und den zweiten Indexwert vom Host-Computer an das periphere System zu liefern. Die Registerzugriffschaltung ist dazu konfiguriert, auf Daten in dem ersten Register zuzugreifen, falls der erste Indexwert von dem Host-Computer geliefert wird, und ist ferner dazu konfiguriert, auf Daten in dem zweiten Register zuzugreifen, falls der zweite Indexwert von dem Host-Computer geliefert wird. Bei zumindest einer Ausführungsform des Systems sind das erste und das zweite Register keine architektonisch ausgeführten Register.
Zumindest eine beispielhafte Ausführungsform des peripheren Systems weist ferner eine Zustandsmaschine auf, wobei die Zustandsmaschine einen Adressenabschnitt, einen Steuerabschnitt und einen Datenabschnitt aufweist, wobei das erste und das zweite Register in dem Datenabschnitt enthalten sind. Zumindest eine Ausführungsform des Adressenabschnitts weist eine Registerzugriffschaltung auf. Zumindest eine andere Ausführungsform des peripheren Systems weist ferner einen Mikroprozessor auf. Zumindest eine andere Ausführungsform des peripheren Systems weist mindestens ein Indexregister auf. Zumindest eine andere Ausführungsform des peripheren Systems weist eine Mehrzahl von Kontextregistern auf, wobei jedes der Mehrzahl von Kontextregistern einem von einer Mehrzahl von Indexwerten zugeordnet ist.
KURZBESCHREIBUNG DER ZEICHNUNG
1 veranschaulicht als Blockdiagramm ein Punkt-zu-Punkt-Netz zwischen zwei Rechenvorrichtungen.
2 veranschaulicht als Blockdiagramm ein Punkt-zu-Mehrpunkt-Netz zwischen einer Mehrzahl von Rechenvorrichtungen.
3 ist ein Blockdiagramm zur Veranschaulichung eines Scatter-Netzes, das mehrere Piconetze mit überlappender Abdeckung umfasst.
4 ist ein Blockdiagramm zur Veranschaulichung einer Registerarchitektur zum Führen von Master- und Slave-Kontextinformationen in einer peripheren Vorrichtung.
5 ist ein Blockdiagramm zur Veranschaulichung zumindest einer Ausführungsform des Formats eines Slave-Indexes und Slave-Registers.
6 ist ein Blockdiagramm zur Veranschaulichung zumindest einer Ausführungsform des Formats eines Master-Indexes und Master-Registers.
7 ist ein Datenflussdiagramm zur Veranschaulichung zumindest einer Ausführungsform des Datenflusses während der Verwendung eines Master-Indexes zur Durchführung einer Kontextumschaltung für eine Slave-Vorrichtung.
8 veranschaulicht ein Datenflussdiagramm zur Veranschaulichung zumindest einer Ausführungsform des Datenflusses während der Verwendung eines Slave-Indexes zur Durchführung einer Kontextumschaltung für eine Master-Vorrichtung.
9 veranschaulicht zumindest eine Ausführungsform eines Systems, das die Kontextumschalte-Architektur der vorliegenden Erfindung verkörpert.
10, die 10a und 10b umfasst, ist ein Zustandsübergangsdiagramm zur Veranschaulichung einer Zustandsmaschine gemäß einer Ausführungsform der vorliegenden Erfindung.
11 ist ein Ablaufdiagramm zur Veranschaulichung zumindest einer Ausführungsform eines Master-Parameterzugriffmoduls.
12 ist ein Ablaufdiagramm zur Veranschaulichung zumindest einer Ausführungsform eines Slave-Parameterzugriffmoduls.
AUSFÜHRLICHE BESCHREIBUNG
1 veranschaulicht ein Netz 10 mit zwei Rechenvorrichtungen 102-1, 102-2. Das Netz 10 ist beispielsweise ein drahtloses Bluetooth Punkt-zu-Punkt-Piconetz, bei dem eine drahtlose Vorrichtung bzw. Funkvorrichtung 102-1 ein Master-Bluetooth-System ist, und eine Funkvorrichtung 102-2 ein Slave-Bluetooth-System ist, wobei der Master 102-1 und der Slave 102-2 sich den gleichen Kanal teilen. Für den Fachmann dürfte ersichtlich sein, dass ein Punkt-zu-Punkt-Netz keine Bluetooth-Vorrichtungen 102-1, 102-2 enthalten muss, sondern hingegen einen beliebigen Typ von Rechenvorrichtung aufweisen kann.
2 veranschaulicht ein Netz 20, das eine Mehrzahl von Funkvorrichtungen 102-1, 102-2, 102-i, ... 102-n enthält (2 ≤ i ≤ n). Das Funknetz 20 ist beispielsweise ein Punkt-zu-Mehrpunkt-Bluetooth-Piconetz, bei dem eine Funkvorrichtung 102-1 ein Master-Bluetooth-System ist und die Funkvorrichtungen 102-2 bis 102-n Slave-Bluetooth-Systeme sind. Wie bei allen Piconetzen kommunizieren der Master 102-1 und alle Slaves 102-2 bis 102-n über den gleichen Kanal. Bei zumindest einer Ausführungsform können bis zu sieben Slaves in dem Piconetz 102 aktiv sein. Für den Fachmann dürfte ersichtlich sein, dass die Anzahl von aktiven Slaves, die in einem Piconetz unterstützt werden, von vielen Variablen und Entwurfserwägungen abhängt. Es kann eine beliebige Anzahl von Slaves unterstützt werden. Der Fachmann wird ferner erkennen, dass ein Punkt-zu-Punkt-Netz keine Bluetooth-Vorrichtungen 102-1, 102-2 aufzuweisen braucht, sondern hingegen eine beliebige Art von Rechenvorrichtung aufweisen kann.
Zusätzlich zu den in 2 dargestellten aktiven Slaves 102-2, 102-i bis 102-n kann ein Punkt-zu-Mehrpunkt-Piconetz 20 viele zusätzliche Slaves enthalten, die in einem so genannten "geparkten" Zustand mit dem Master 102-1 verriegelt bleiben können. Wenn ein Slave nicht an dem Piconetz-Kanal teilzunehmen braucht, aber dennoch mit dem Kanal synchronisiert bleiben muss, kann er in den geparkten Zustand mit einer geringeren Leistung eintreten. Diese geparkten Slaves können nicht auf dem Piconetz-Kanal aktiv sein, bleiben aber mit dem Master synchronisiert. Bei zumindest einer Ausführungsform können bis zu 256 geparkte Slaves mit dem Master verriegelt bleiben. Für zusätzliche Informationen hinsichtlich einer Implementierung der Synchronisierung von Master- und Slave-Bluetooth-Systemen möge man sich auf die Anmeldung der gleichen Anmelderin mit der US-Patentnummer 6,650,880 und der Bezeichnung "Wireless Data Communications Using FIFO For Synchronization Memory" der Erfinder Sherman Lee, Vivian Y. Chou, und John H. Lin beziehen, die am 12.07.2000 hinterlegt wurde.
Für sowohl aktive als auch geparkte Slaves in einem einzelnen Piconetz 10, 20 steuert der Master 102-1 den Kanalzugriff. Dies führt zu der Notwendigkeit, dass der Master 102-1 die Steuerung von einem Slave zu einem anderen umschalten muss, wenn er den Kanalzugriff innerhalb des Piconetzes steuert. Der Master 102-1 identifiziert jeden Slave durch eine eindeutige Netzadresse, die jedem Slave zugewiesen ist. Wenn ein Transfer von Informationen zwischen zwei Slaves in einem Piconetz 10, 20 gewünscht wird, koordiniert der Master 102-1 die Übertragung zwischen zwei Slaves.
Unter Bezugnahme auf 2 könnte z. B. der Slave 102-2 eine drahtlose Personal Digital Assistant ("PDA")-Vorrichtung sein, die mit einem Bluetooth-System ausgerüstet ist, und der Slave 102-i könnte ein drahtloses Mobiltelefon sein, das mit einem Bluetooth-System ausgerüstet ist. In einem solchen Fall kann der Master 102-1 Kommunikationen zwischen den zwei Slaves 102-2, 102-i über den Piconetz-Kanal koordinieren, um beispielsweise Telefonnummerinformationen auszutauschen. Hierzu muss der Master 102-1 den Fokus zwischen dem ersten Slave 102-2, den er anweist, Telefonnummerdaten an den Master 102-1 zu übertragen, und dem zweiten Slave 102-i, den er anweist, Telefonnummerdaten von dem Master 102-1 zu empfangen, umschalten Dieses Umschalten des Fokus, das vorliegend als eine "Kontextumschaltung" bezeichnet wird, verlangt von dem Master die Fähigkeit, Kontextinformationen in Bezug auf jeden Slave in relativ schneller Abfolge zu speichern und auf sie zuzugreifen.
3 veranschaulicht, dass eine Kontextumschalte-Fähigkeit auch für Slaves erforderlich ist, die an mehr als einem Piconetz teilnehmen. 3 veranschaulicht z. B. ein "Scatter-Netz" 30, das aus mehreren Netzen mit überlappender Abdeckung gebildet ist. Ein Bluetooth Piconetz 31, 33, 20 (2) kann Teil eines größeren Bluetooth Scatter-Netzes 30 darstellen. Jedes Piconetz 31, 33, 20 (2) kann nur einen einzigen Master 36, 34 bzw. 102-1 aufweisen. 3 zeigt jedoch, dass Slaves auf einer Zeitmultiplexbasis an mehreren Piconetzen teilnehmen können. Beispielsweise nimmt der Slave 32 in 3 an zwei Piconetzen teil: dem Piconetz 20 mit dem Master 102-1 und dem Piconetz 31 mit dem Master 36. Außerdem kann ein Master 34 in einem Piconetz 33 ein Slave in einem anderen Piconetz 37 sein.
Die vorstehende Erörterung veranschaulicht die Notwendigkeit, dass in einer Netzumgebung wie etwa einem Funknetz gemäß den Angaben in der Bluetooth-Spezifikation sowohl Master als auch Slaves die Fähigkeit besitzen, Kontexte schnell umzuschalten, um eine geordnete, annehmbar schnelle Kommunikation zwischen Funkvorrichtungen zu erleichtern. In einem anderen Kontext gibt es mehrere Methoden zum Umschalten von Kontexten zwischen Software-Anwendungsprogrammen. Diese Methoden umfassen für gewöhnlich das Speichern von Kontextinformationen in einem Speicher und daraufhin, während einer Kontextumschaltung, das Laden der In formationen aus dem Speicher in ein bestimmtes Register oder in einen bestimmten Registersatz. Solche Software-basierten Kontext-Umschaltemethoden sind beispielsweise in dem für Song et al. erteilten US-Patent Nr. 6,061,711 mit der Bezeichnung "Efficient Context Saving and Restoring in a Multi-Tasking Computing System Environment" beschrieben, sowie in dem für Kahle et al. erteilten US-Patent Nr. 5,812,823 mit der Bezeichnung "Method and System for Performing an Emulation Context Save and Restore That is Transparent to the Operating System"; Song '711 und Kahle '823.
Bei einer Software-basierten Kontext-Umschaltemethode wird ein Satz von Hardware-Registern verwendet, das aktuelle Kontextinformationen enthalten soll. Wenn eine Kontextumschaltung stattfindet, werden die Informationen in den Register für abgehenden Kontext aus den Register an eine Speicherstelle wie etwa eine Stelle im Hauptspeicher oder in einem Cache gespeichert. Die Kontextinformationen für ankommenden Kontext werden dann aus einer anderen Speicherstelle in die Register geladen. Dieses Speichern in und Laden aus Speicher für den Transfer von Daten über eine Software zwischen Speicher und Hardware-Registern ist zeitraubend und prozessorintensiv. Die Verwendung eines solchen Lösungsansatzes zum Umschalten von Kontexten zwischen Master und Slaves in einem Netz von Rechenvorrichtungen wie etwa einem Netz von Bluetooth-Systemen würde in einem stark eingeschränkten Netzdurchsatz während des Kontext-Umschaltevorgangs resultieren.
4 ist ein verallgemeinertes Blockdiagramm zur Veranschaulichung einer Kontextumschaltungs-Registerarchitektur gemäß zumindest einer Ausführungsform der vorliegenden Erfindung. Eine vorläufige Erörterung allgemeiner Registerarchitekturen ist hierbei vor einer Erörterung der besonderen Aspekte der Registerarchitektur der vorliegenden Erfindung angebracht. Computersysteme wie etwa der in 9 dargestellte Host-Computer 970 haben typischerweise einen vergleichsweise großen, vergleichsweise langsamen Hauptspeicher. Typischerweise weist das Hauptspeichersystem mehrere dynamische Direktzugriffspeicher (Dynamic Random Access Memory; DRAM)-Module auf. Die Zeit, die für den Transfer eines Satzes von Informations-Bytes vom Hauptspeicher zum Mikroprozessor moderner DRAMs benötigt wird ("Zugriffszeit"), ist länger als die Taktzykluslänge moderner Mikroprozessoren.
Um ein schnelleres Mittel für den Mikroprozessor zum Zugreifen auf gespeicherte Informationen zur Verfügung zu stellen, wird üblicherweise ein Satz von Register im Mikroprozessor vorgesehen. Gemäß der vorliegenden Verwendung ist ein Register eine in dem Mikroprozessor oder in einer peripheren Vorrichtung vorgesehene Speicherstelle, wobei die Speicherstelle durch einen Befehl wie das Speichern eines Operanden identifiziert ist. Mit anderen Worten, ein Register ist "für den Programmierer sichtbar"; der Programmierer kann einen Befehl codieren, der das Register als Operanden-Identifikation aufweist. Da Register in dem Mikroprozessor oder in der peripheren Vorrichtung enthalten sind, und da die Registeradresse direkt in einen Befehl codiert ist, kann auf Register schnell zugegriffen werden.
4 veranschaulicht, dass die Architekturmethode gemäß zumindest einer Ausführungsform der vorliegenden Erfindung eine Mehrzahl von Hardware-Registern 40, 42, 44a–44n, 46a–46m umfasst, die Kontextinformationen führen. Bei zumindest einer Ausführungsform sind die Hardware-Register 40, 42, 44a–44n, 46a–46m in einem peripheren System 972 (9) statt in dem Mikroprozessor eines Host-Computers 970 vorgesehen (9). Bei zumindest einer Ausführungsform sind n = 8 und m = 8, so dass acht Master-Register 44a-44n und acht Slave-Register 46a–46m vorgesehen sind. Bei zumindest einer anderen Ausführungsform, die in 4 dargestellt ist, sind vier Master-Register 44a-44n und vier Slave-Register 46a-46n vorgesehen. Die in 4 dargestellte Architektur enthält auch einen Master-Index 40 und ein Slave-Indexregister 42. Da viele Vorrichtungen entweder als Master oder Slaves agieren können, umfasst zumindest eine Ausführungsform der vorliegenden Erfindung Master-Register 44a-44n und ein Master-Indexregister 40 sowie Slave-Register 46a–46m und ein Slave-Indexregister 42 in jeder Netzwerkvorrichtung, die in einer Master/Slave-Umgebung arbeitet. Für den Fachmann dürfte ersichtlich sein, dass zumindest eine Ausführungsform der vorliegenden Erfindung nur die Slave-Register 46a–46m und das Slave-Indexregister 42, aber nicht die Master-Register 44a-44n oder das Master-Indexregister 40 in Vorrichtungen zu enthalten braucht, die nur als Master agieren. Auf ähnliche Weise braucht zumindest eine Ausführungsform der vorliegenden Erfindung nur die Master-Register 44a-44n und das Master-Indexregister 40, aber nicht die Slave-Register 46a–46m oder das Slave-Indexregister 42 in Vorrichtungen zu enthalten, die nur als Slaves agieren.
Für den Fachmann dürfte ferner ersichtlich sein, dass sich zahlreiche Entwurfserwägungen auf die Anzahl, Größe und Organisation der Master-Register 44a-44n und der Slave-Register 46a–46m auswirken. Die vorliegende Architektur ist daher so skalierbar, dass sie eine beliebige Anzahl von Master-Register 44a-44n und Slave- Registern 46a–46m bewältigen kann. Während beispielsweise eine Rechenvorrichtung, die als Master dient, vier Slave-Register 46a–46m führen kann, ist die Anzahl von Slave-Registern46a–46m natürlich skalierbar. Da beispielsweise ein Master 102-1 (1), 36 (3) bis zu sieben Slaves 102-2–102-n gemäß Ver. 1.0b der Bluetooth-Spezifikation steuern kann, umfasst zumindest eine Ausführungsform der vorliegenden Erfindung sieben Slave-Register 46a–46m in jedem Bluetooth-System 102-1 (1), 36 (3), das in der Lage ist, als Master zu agieren. Bei zumindest einer anderen Ausführungsform umfasst ein Bluetooth-Master-System 102-1 (1), 36 (3) 256 Slave-Register 46a–46m, um Kontextinformationen für 256 geparkte Slaves zu führen.

5 und Tabelle 1 stellen ein beispielhaftes Format der in jedem Slave-Register 46 gespeicherten Informationen dar. Für den Fachmann dürfte ersichtlich sein, dass das Format der Slave-Register 46 von konkreten Entwurfserwägungen abhängt. Im Allgemeinen enthalten die Slave-Register 46 alle Kontextinformationen und Parameter, die nötig sind, um es dem Master-System 102-1 (1), 36 (3) zu ermöglichen, Kontexte schnell zwischen Slave-Systemen umzuschalten. Das Format und die Adressen der in 5 und Tabelle 1 dargestellten Informationen sollten nur als eine beispielhafte Format- und Adressenmethode aufgefasst werden. Für den Fachmann dürfte ersichtlich sein, dass die Felder in einer beliebigen Reihenfolge an jeder beliebigen Registerstelle gespeichert sein können. Tabelle 1

Adresse	Name	Reset	lese-/schreibbar	Bit-Stelle	Verbindungsfeld	Beschreibung	# von Bits	Default
0xC1	NAP_hi	s	R/W	[7:0]	NAP[15:8]	0xc1	8	x00
	NAP_lo	s	R/Wa	[7:0]	NAP[7:0]	0xc2	8	x00
	UAP	s	R/W	[7:0]	UAP[7:0]	0xc3	8	x00
	LAP_hi	s	R/W	[7:0]	LAP[23:16]	0xc4	8	x00
	LAP_md	s	R/W	[7:0]	LAP[15:8]	0xc5	8	x00
	LAP_lo	s	R/W	[7:0]	LAP[7:0]	0xc6	8	x00
0xC7	Class_hi	s	R/W	[7:0]	class[23:16]	0xc7	8	x00
	Class_md	s	R/W	[7:0]	class[15:8]	0xc8	8	x00
	Class_lo	s	R/W	[7:0]	class[7:0]	0xc9	8	x00
0xCA	clock offset upper	s	R/W	[7:0]	clock[27:24]	0xca	8	x00
	clock offset hi	s	R/W	[7:0]	clock[23:16]	0xcb	8	x00
	clock offset md	s	R/W	[7:0]	clock[15:8]	0xcc	8	x00
	clock offset lo	s	R/W	[7:6]	clock[7:0]	0xcd	2	0
0xCE	AM_ADDR	s	R/W	[2:0]	AM_ADDR	0xce	3	0
0xCF	FHS_misc	s	R/W	[7:6]	Scan Repetition	0xcf	2	0
		s	R/W	[5:4]	Scan Period		2	0
		s	R/W	[3:1]	Page Scan-Modus		3	0

Die Felder für den nicht-signifikanten Adressteil NAP (Non-significant Address Part), oberen Adressteil UAP (Upper Address Part) und unteren Adressteil LAP (Lower Address Part), die in Tabelle 1 aufgeführt sind, umfassen zusammen die Netzadresse der Bluetoth-Vorrichtung (vorliegend manchmal als die "BD [Bluetooth Device]-Adresse" bezeichnet) für das Slave-System, die in dem jeweiligen Register 46 verfolgt wird. Die BD-Adresse ist bei zumindest einer Ausführungsform 48 Bits lang.
Die Klassenfelder (Class_hi, Class_md, Class_lo), die in Tabelle 1 aufgeführt sind, beziehen sich auf die jeweilige Klasse des Bluetooth-Slave-Systems, das in dem jeweiligen Register 46 verfolgt wird. Beispielsweise stellen PC-Rechner, Mobiltelefone und Personal Digital Assistants unterschiedliche Klassen von Bluetooth-Slave-Vorrichtungen dar.
Die Taktversatz-Felder (clock offset upper, clock offset hi, clock offset md, clock offset lo), die in Tabelle 1 aufgeführt sind, beziehen sich auf einen Delta-Wert zwischen dem Master-Takt und dem Slave-Takt, den das Slave-System führt, um seine Kommunikationen mit dem Master-System zu synchronisieren. Diese Synchronisierung ist für die Hopping-Methode nötig, die in der Bluetooth-Spezifikation zur Verfügung gestellt wird. Die Hopping-Methode sieht vor, dass der Kanal, auf dem die Bluetooth-Systeme in einem Piconetz arbeiten, durch eine pseudozufällige Hopping- Sequenz durch die verfügbaren Kanäle im 2,4 GHz ISM-Band dargestellt ist. Die Hopping-Sequenz ist für ein Piconetz eindeutig und wird durch die BD-Adresse des Masters bestimmt. Die Phase in der Hopping-Sequenz wird durch den Bluetooth-Takt des Master-Systems bestimmt. Aus diesem Grund führt der Slave die Taktversatzfelder, um Hopping entsprechend dem Takt des Masters auszuführen.
Das in Tabelle 1 dargestellte Feld AM_ADDR ist ein Active Member-Adressfeld, das die jeweilige Adresse des aktiven Slaves in dem Piconetz enthält. Es wird dazu verwendet, die aktiven Teilnehmer eines Piconetzes zu unterscheiden. Beispielsweise muss ein Piconetz, das in der Lage ist, bis zu sieben aktive Slaves zu enthalten, eine eindeutige Piconetz-Adresse für jeden der aktiven Slaves zur Verfügung stellen. Tabelle 1 veranschaulicht, dass bei zumindest einer Ausführungsform das AM_ADDR-Feld drei Bits lang ist, weil drei Bits nötig sind, um eine binäre Darstellung der Zahl 7 zu generieren (d. h. 1b'111').
Das in Tabelle 1 dargestellte Feld FHS_misc ist ein Feld, das die folgenden Unterfelder enthält: Scan Repetition, Scan Period, und Page Scan-Modus. Diese Felder beziehen sich auf Zeitperioden, Intervalle und Modus für die Paging (Funkruf)-Prozedur, mit der Verbindungen in Bluetooth-Piconetzen erstellt werden.
Eine Master-Vorrichtung sendet eine Page-Nachricht an eine Slave-Vorrichtung aus, mit der der Master eine Verbindung zu erstellen versucht. Ein Slave, der noch nicht verbunden ist, erwacht periodisch zu einem Page Scan-Status und sucht nach Pages, die an ihn gesendet worden sein könnten. Im Page Scan-Status scannt der Slave nach, und empfängt, Page-Nachrichten. Wenn eine Page-Nachricht erfolgreich von dem Slave empfangen wurde, findet eine Synchronisierung zwischen dem Master und dem Slave statt, wodurch eine Verbindung zwischen dem Master und dem Slave erstellt wird.

6 und die nachfolgende Tabelle 2 stellen ein beispielhaftes Format der Informationen dar, die in jedem Master-Register 44 gespeichert sind. Für den Fachmann dürfte ersichtlich sein, dass das Format der Master-Register 44 von konkreten Entwurfserwägungen abhängt. Im Allgemeinen enthalten die Master-Register 44 jegliche Kontextinformationen und Parameter, die nötig sind, um es dem Slave-System 102-2–102-n (2) zu ermöglichen, Kontexte zwischen Master-Systemen schnell umzuschalten. Das Format und die Adressen der Informationen, die in 6 und Ta belle 2 dargestellt sind, sollten nur als eine beispielhafte Format- und Adressenmethode aufgefasst werden. Für den Fachmann dürfte ersichtlich sein, dass die Felder in einer beliebigen Reihenfolge in einer beliebigen Registerstelle gespeichert sein können. Tabelle 2

Adresse	Name	Reset	lese-/schreibbar	Bit-Stelle	Verbindungsfeld	Beschreibung	# von Bits	Default
0x82	NAP_hi	s	R/W	[7:0]	NAP[15:8]	0x82	8	x00
	NAP_lo	s	R/W	[7:0]	NAP [7:0]	0x83	8	x00
	UAP	s	R/W	[7:0]	UAP[7:0]	0x84	8	x00
	LAP_hi	s	R/W	[7:0]	LAP[23:16]	0x85	8	x00
	LAP_md	s	R/W	[7:0]	LAP[15:8]	0x86	8	x00
	LAP_lo	s	R/W	[7:0]	LAP[7:0]	0x87	8	x00
0x88	Class_hi	s	R/W	[7:0]	class[23:16]	0x88	8	x00
	Class_md	s	R/W	[7:0]	class[15:8]	0x89	8	x00
	Class_lo	s	R/W	[7:0]	class[7:0]	0x8a	8	x00
0x8B	clock offset upper	s	R/W	[7:0]	clock[27:24]	0x8b	8	x00
	clock offset hi	s	R/W	[7:0]	clock[23:16]	0x8c	8	x00
	clock offset md	s		[7:0]	clock[15:8]	0x8d	8	x00
	clock offset lo	s	R/W	[7:6]	clock[7:0]	0x8e	2	0
0x8F	AM_ADD R	s	R/W	[2:0]	AM_ADDR	0x8f	3	0
0x90	FHS_misc	s	R/W	[7:6]	Scan Repetition	0x90	2	0
			R/W	[5:4]	Scan Period		2	0
			R/W	[3:1]	Page Scan Mode		3	0
0x91	PM_ADDR	s	R/W	[2:0]	PM_ADDR vom Master zugewiesen	0x91	8	0
0x92	AR_ADDR	s	R/W	[2:0]	AR_ADDR vom Master zugewiesen	0x92	8	0
0x93	Dsniff_hi	s	R/W	[7:0]	verbindungsspezifisch Dsniff	0x93	8	x00
	Dsniff_lo	s	R/W	[7:0]		0x94	S	x00
0x95	Tsniff_hi	s	R/W	[7:0]	Tsniff	0x95.	8	x00
	Tsniff_lo	s	R/W	[7:0]		0x96	8	x00
0x97	N sniff attempt hi	s	R/W	[7:0]	N Sniff Attempt	0x97	8	x00
	N sniff attempt lo	s	R/W	[7:0]		0x98	8	x00
0x99	N sniff timeout hi	s	R/W	[7:0]	N Sniff Timeout	0x99	8	x00
	N sniff timeout lo	s	R/W	[7:0]		0x9a	8	x00
0x9B	holdTO_hi	s	R/W	[7:0]	holdTO	0x9b	8	x00
	holdTO_lo	s	R/W	[7:0]		0x9c	8	x00
0x9D	Tbeacon_hi	s	R/W	[7:0]	Park Beacon-Intervall	0x9d	8	x00
0x9D	Tbeacon_lo	s	R/W	[7:0]		0x9e	8	x00
0x9F	NB_hi	s	R/W	[7:0]	NB	0x9f	8	x00
	NB_lo	s	R/W	[7:0]		0xa0	8	x00
0xA1	DB_hi	s	R/W	[7:0]	DB	0xa1	8	x00
	DB_lo	s	R/W	[7:0]		0xa2	8	x00
0xA3	TB_hi	s	R/W	[7:0]	TB	0xa3	8	x00
	TB_lo	s	R/W	[7:0]		0xa4	8	x00
0xA5	Maccess_hi	s	R/W	[7:0]	Maccess	0xa5	8	x00
	Maccess_lo	s	R/W	[7:0]		0xa6	8	x00
0xA7	Taccess_hi	s	R/W	[7:0]	Taccess	0xa7	8	x00
	Taccess_lo	s	R/W	[7:0]		0xa8	8	x00
0xA9	Daccess_hi	s	R/W	[7:0]	Daccess	0xa9	8	x00
	Daccess_lo	s	R/W	[7:0]		0xaa	8	x00
0xAB	Nacc_slot hi	s	R/W	[7:0]	Nacc_slot	0xab	8	x00
	Nacc_slot lo	s	R/W	[7:0]		0xac	8	x00
0xAD	NB_sleep hi	s	R/W	[7:0]	NB_sleep	0xad	8	x00
	NB_sleep lo	s	R/W	[7:0]		0xae	8	x00
0xAF	DB_sleep hi	s	R/W	[7:0]	DB_sleep	0xaf	8	x00
	DB_sleep lo	s	R/W	[7:0]		0xb0	8	x00
0xB1	Npoll hi	s	R/W	[7:0]	Npoll	0xb1	8	x00
	Npoll lo	s	R/W	[7:0]		0xb2	8	x00

Die in Tabelle 2 aufgeführten Felder NAP (Non-significant Address Part), UAP (Upper Address Part) und LAP (Lower Address Part) umfassen zusammen die BD-Adresse für das Master-System, die in dem jeweiligen Register 44 verfolgt wird. Die BD-Adresse ist zumindest bei einer Ausführungsform 48 Bits lang.
Die in Tabelle 2 dargestellten Klassenfelder (Class_hi, Class_md, Class_lo) beziehen sich auf die jeweilige Klasse des Bluetooth Master-Systems, die in dem jeweiligen Register 44 verfolgt wird.
Die in Tabelle 2 aufgeführten Master Clock Offset Felder (clock offset upper, clock offset hi, clock offset md, clock offset lo) stellen einen Delta-Wert zwischen dem Slave-Takt und dem Master-Takt dar. Der Master kann diesen Wert berücksichtigen, wenn er mit einem Slave kommuniziert, um eine effizientere Übertragung zu planen.
Das in Tabelle 2 aufgeführte Feld AM_ADDR ist ein Active Member-Adressfeld, das die jeweilige Adresse des Masters in dem Piconetz enthält. Es wird von dem Slave verwendet, wenn dieser Kommunikationspakete an den Master adressiert. Das Feld AM_ADDR im Master-Register 44 ist ein 3Bit-Feld gemäß der oben stehenden Erläuterung in Verbindung mit Tabelle 1.
Das in Tabelle 2 aufgeführte Feld FHS_misc ist ein Feld, das die folgenden Unterfelder enthält: Scan Repetition, Scan Period, und Page Scan-Modus, wie vorstehend in Verbindung mit Tabelle 1 erläutert ist.
Die Felder PM_ADDR und AR_ADDR betreffen den Park-Modus. Mit anderen Worten, selbst wenn ein Slave geparkt ist, behält der Slave Master-Kontextdaten in seinen Master-Registern 44. Wenn eine Slave-Vorrichtung von einem Park-Modus zu einem Slave-Modus übergeht, gibt der Slave seinen Active Member-Adresswert AM_ADDR auf. Statt dessen erhält der geparkte Slave zwei neue Adressen, die von dem Master zugewiesen werden, damit sie im Park-Modus verwendet werden: PM_ADDR (Parked Member-Adresse) und AR_ADDR (Access Request-Adresse). PM_ADDR unterscheidet einen geparkten Slave von anderen geparkten Slaves. Beim Verfolgen von Kontextdaten für einen oder mehr Master merkt sich der geparkte Slave seine PM_ADDR für jeden Master – die PM_ADDR wird von dem Master in einer vom Master initiierten Entparken-Prozedur verwendet. AR_ADDR ist eine vom Master zugewiesene Adresse zur Verwendung durch den Slave in einer vom Slave initiierten Entparken-Prozedur.
Die nächsten mehreren Felder, die in Tabelle 2 dargestellt sind, beziehen sich auf einen "Sniff-Modus. Diese Felder umfassen die Dsniff-Felder (Dsniff_hi, Dsniff_lo), die Tsniff-Felder (Tsniff_hi, Tsniff_lo), die Nsniff attempt-Felder (Nsniff attempt hi, Nsniff attempt lo), und die Nsniff Timeout-Felder (N sniff timeout hi, N sniff timeout lo). Im Sniff-Modus ist die Austastrate der Horchaktivität eines aktiven Slave verringert, weil die Zeitschlitze, in denen der Master eine Übertragung an einen bestimmten Slave beginnen kann, auf bestimmte Zeitschlitze reduziert sind. Wenn sich daher ein aktiver Slave im Sniff-Modus befindet, braucht er nur während seiner zugewiesenen Sniff-Schlitze zu horchen. Diese so genannten Sniff-Schlitze sind gleichmäßig innerhalb eines Intervalls Tsniff beabstandet. Der Slave muss an dem Dsniff-Schlitz bei jeder Sniff-Periode, Tsniff, eine Anzahl N_{sniff
attempt} von Malen lang horchen. Falls der Slave während seiner Sniff-Periode ein Paket empfängt, sollte er so lange weiter horchen, wie er weiter Pakete empfängt. Sobald der Slave das Empfangen von Paketen beendet, sollte er N_{sniff Timeout} weitere Schlitze oder die verbleibende N_{sniff attempt}-Anzahl von Schlitzen lang weiter horchen, je nachdem, welche Anzahl größer ist.
Die Hold Timeout-Felder (holdTO_hi, holdTO_lo) beziehen sich auf einen Haltemodus (Hold-Modus). Ein Slave kann in einen Hold-Modus versetzt werden, in dem der Slave noch aktiv ist, aber in dem seine Kommunikationsfähigkeiten auf dem Kanal vorübergehend beschränkt sind. Während des Hold-Modus behält der Slave seine Active Member-Adresse (AM_ADDR). Bevor der Slave in den Hold-Modus eintritt, einigen sich der Slave und der Master auf die Zeitdauer, während der der Slave im Hold-Modus verbleiben soll. Dieser Zeitwert wird in den Hold Timeout-Feldern gespeichert.
Die übrigen Felder, die in Tabelle 2 aufgeführt sind, beziehen sich auf den Beacon-Kanal. Um geparkte Slaves zu unterstützen, erstellt der Master einen Beacon-Kanal, wenn ein oder mehr Slaves geparkt sind. Der Beacon-Kanal wird dazu verwendet, Informationen von dem Master an den geparkten Slave zu übertragen, die der Slave für eine Neusynchronisierung verwenden kann. Der Beacon-Kanal wird auch dazu verwendet, Nachrichten an die geparkten Slaves zu übertragen, um die Beacon-Parameter zu verändern und allgemeine Broadcast-Nachrichten an die geparkten Slaves zu übertragen. Schließlich wird der Beacon-Kanal für das Entparken von einem oder mehreren geparkten Slaves verwendet.
9 veranschaulicht die Organisation von zumindest einer Ausführungsform eines Bluetooth-Systems 900, die für die nachfolgende Erörterung von Bedeutung ist. 9 veranschaulicht, dass ein Bluetooth-System 900 wie etwa ein Mobiltelefon oder ein PDA aus einem Host-Computer 970 und einem peripheren System 972 besteht. Das periphere System 972 umfasst eine analoge Komponente und eine digitale Komponente. Die analoge Komponente ist eine Funkeinheit 910. Für zusätzliche Details im Hinblick auf zumindest einen Aspekt von zumindest einer Ausführungsform der Funkeinheit 910 möge auf die ebenfalls anhängige und am 12.07.2000 eingereichte Anmeldung, US-Patent 6,560,449, des Erfinders Albert Liu mit der Bezeichnung "Image-Rejection I/Q Demodulators", Bezug genommen werden. Für zusätzliche Details im Hinblick auf den Betrieb von zumindest einem Aspekt von zumindest einer anderen Ausführungsform der Funkeinheit 910 möge auf die ebenfalls anhängige und am 12.07.2000 eingereichte Anmeldung, US-Patent Nr. 6,778,594, des Erfinders Albert Liu mit der Bezeichnung "Receiver Architecture Employing Low Intermediate Frequency And Complex Filtering", Bezug genommen werden.
Die digitale Komponente des peripheren Systems 972 ist der Host-Controller 930. Eine Rechenvorrichtung wie etwa 102-1, 102-2 bis 102-n, die in den 1 und 2 dargestellt sind, müssen nicht unbedingt alle der in 9 dargestellten Bestandteile aufweisen, um die vorliegende Erfindung auszuführen.
Der Host-Controller 930 umfasst Hardware-Komponenten (Schaltungsanordnungen) 920, 940, 930 und Software-Komponenten 960, 980. Die externe Schnittstelle 950 führt die Link-Verwaltung durch und stellt Schnittstellenfunktionen mit einem Host-Computer 970 zur Verfügung. Der Host 970 kommuniziert mit dem Host-Controller 930 über die Software der Host-Schnittstelle 980, während sie auf der externen Schnittstellen-Hardware 950 in Betrieb ist. Der Host 970 empfängt asynchrone Ereignis-Benachrichtungen, wenn ein signifikantes Ereignis eingetreten ist. Der Host 970 parst die Benachrichtung, um zu bestimmen, welches Ereignis eingetreten ist. Eine ausführlichere Erörterung der Host-Schnittstelle 980 ist in Part H:1, "Host Cont roller Interface Functional Spezifikation" von Ver. 1.0b der Bluetooth-Spezifikation zu finden.
Der Link-Controller 920 führt eine Bluetooth-Basisbandverarbeitung durch und behandelt PHY-Schicht-Protokolle. Die Link Manager-Software 960 entdeckt andere Remote Link Manager-Programme und nutzt die Dienste des Link-Controllers 920, um mit ihnen zu kommunizieren.
9 zeigt, dass die Link Manager-Software 960 auf der Zustandsmaschine 940 läuft. Die Zustandsmaschine 940 stellt Hardware-Schaltungen zur Verfügung, die einen Zugriff auf die vorausgehend in Verbindung mit 4 erörterte Registerarchitektur zur Verfügung stellen.
Die 7, 8 und 9 zeigen, dass die Zustandsmaschine 940 einen Steuerabschnitt 944, einen Datenabschnitt 946 und einen Adressenabschnitt 942 aufweist. Der Datenabschnitt der Zustandsmaschine 940 umfasst die Master-Register 44a-44n, das Master-Indexregister 40, die Slave-Register 46a–46m und das Slave-Indexregister 42. Der Adressenabschnitt 942 der Zustandsmaschine 940 umfasst Schaltungen, die als Corereg-Schaltung 970 und Regmux-Schaltung 972 bezeichnet werden.
7 ist ein Blockdiagramm, das die Verwendung des Master-Indexes zur Durchführung einer Kontextumschaltung für eine Slave-Vorrichtung darstellt. 7 veranschaulicht, dass die Inhalte des Master-Indexregisters 40 dazu verwendet werden, auszuwählen, auf welches der Master-Register 44 der Slave zugreifen möchte. Falls der Slave z. B. auf ein erstes Master-Register 44a zugreifen möchte, wird ein Wert 1b'00000000' von dem Host 970 in das Master-Indexregister 40 geladen. Für jedes der übrigen Master-Register 44b-44n wird ein entsprechender Indexwert in das Master-Indexregister 40 geladen, wenn der Slave Kontextdaten auffinden muss, die in diesem bestimmten Master-Register 44b-44n gespeichert sind. Sobald der geeignete Wert in das Master-Indexregister 40 geladen ist, führen die Corereg-Schaltung 70 und die Regmux-Schaltung 72 eine nachstehend beschriebene Logik durch, um aus dem betreffenden Master-Register 44 auszulesen oder in dieses zu schreiben. Eine Kontextumschaltung, wenn ein Slave Kontexte zwischen Master umschalten möchte, wird somit einfach dadurch durchgeführt, dass der Host-Computer 970 den Wert im Master-Indexregister 40 ändert.
8 ist ein Blockdiagramm, das die Verwendung des Slave-Indexes zur Durchführung einer Kontextumschaltung für eine Master-Vorrichtung darstellt. 8 veranschaulicht, dass die Inhalte des Slave-Indexregisters 42 dazu verwendet werden, auszuwählen, auf welches der Slave-Register 46 der Master zugreifen möchte. Falls der Master z. B. auf ein drittes Master-Register 46c zugreifen möchte, wird ein Wert 1b'00000011' in das Slave-Indexregister 42 geladen. Für jedes der übrigen Slave-Register wird ein entsprechender Indexwert in das Slave-Indexregister 42 geladen, wenn der Master Kontextdaten auffinden möchte, die in diesem bestimmten Master-Register gespeichert sind.
Die 8 und 9 zeigen, dass, sobald der Host-Computer 970 den geeigneten Wert in das Slave-Indexregister 42 lädt, die Corereg-Schaltung 70 und die Regmux-Schaltung 72 dann eine nachfolgend beschriebene Logik durchführen, um aus dem betreffenden Slave-Register 46 auszulesen oder in es zu schreiben. Eine Kontextumschaltung, wenn ein Master Kontexte zwischen Slaves umschalten möchte, wird daher einfach dadurch durchgeführt, dass der Host-Computer 970 den Wert in dem Slave-Indexregister 42 ändert, so dass die Schaltungen Corereg 70 und Regmux 72 arbeiten können, um die bestimmten Inhalte des betreffenden Slave-Registers 46 wieder zu gewinnen und/oder zu modifizieren.
Die vorausgegangene Erörterung zeigt, dass ein Master-System mit einem Slave-Index 42 und einem oder mehreren Slave-Registern 46 eine Kontextumschaltung zwischen Slaves schnell durchführen kann. Auf ähnliche Weise zeigt 7, dass ein Slave-System mit einem Master-Index 40 und einem oder mehreren Master-Registern 44 eine Kontextumschaltung zwischen Master schnell durchführen kann. Da die vorstehend in Tabelle 1 beschriebenen Informationen in den Slave-Registern 46 gespeichert sind, und die vorstehend in Tabelle 2 beschriebenen Informationen in den Master-Registern 44 gespeichert sind, brauchen die Kontextinformationen weder in Software-Datenstrukturen noch auf dem Mikroprozessor des Host-Computers 970 gespeichert zu werden brauchen. Dies macht es möglich, schneller auf die Kontextdaten zuzugreifen, als wenn sie bei einer Kontextumschaltung vom Speicher auf Register übertragen würden.
Auch wenn eine auf dem Host-Computer 970 laufende Software die Kontextinformationen nicht zu speichern braucht, muss sie dennoch in der Lage sein, die jeweiligen Kontextdaten für den ankommenden Slave, auf den ein Master umschalten möchte, zu identifizieren und auf diese zuzugreifen, und muss in der Lage sein, die jeweiligen Kontextdaten für den ankommenden Master, auf den ein Slave umschalten möchte, zu identifizieren und auf diese zuzugreifen. Diese Funktion des Identifizierens und Zugreifens auf die Kontextinformationen für den ankommenden Slave oder Master wird durch die Verwendung eines Slave-Indexes 42 bzw. Master-Indexes 40 bewerkstelligt. Bei zumindest einer Ausführungsform befindet sich der Slave-Index 42 an der Register-Speicherstelle 0xC0, und der Master-Index 40 befindet sich an der Register-Speicherstelle 0x81.
Wie die vorausgegangene Erörterung zeigt, ist es wichtig festzuhalten, dass die vorliegenden Kontext-Umschalteregister 40, 42, 44a–44n, 46a–46m in dem peripheren System 972 und nicht in dem Host-Computer 970 einer Rechenvorrichtung 900 vorgesehen sind. Mit einer solchen Methode ist es nicht erforderlich, die Kontextinformationen von dem Host-Computer 970 auf das periphere System 972 zu übertragen. Dies steht in unmittelbarem Kontrast zu und bietet viele Vorteile gegenüber Systemen, die Kontextdaten im Host-System behalten. Ein solches System ist in US-Patent Nr. 5,926,646 mit der Bezeichnung "Context-Dependent Memory-Mapped Registers for Transparent Expansion of Register File" für Pickett et al. (im Nachfolgenden als "Pickett '646a" bezeichnet) beschrieben. Pickett '646 sieht in einem Mikroprozessor einen erweiterten Satz von Registern zusätzlich zu dem architektonisch ausgeführten Satz von Registern vor. Im Gegensatz zu dem Lösungsansatz von Pickett '646 erfordert es die vorliegende Architektur nicht, die Kontextinformationen aus (architektonisch ausgeführten oder sonstigen) Registern in dem Host-Computer 970 jedes Mal auf das periphere System 972 zu verschieben, wenn eine Kontextumschaltung stattfindet. Ein solcher Transfer verlangsamt die Kontextumschalte-Operation und belastet das Netz mit der Übertragung von Kontextinformationen. Die vorliegende Architektur stellt daher Flexibilität in Netzsystemen zur Verfügung, indem sie die Verwendung von langsameren Host-Computern 970 mit einer geringeren Leistungsfähigkeit zulässt und dennoch vergleichsweise schnelle Kontextumschaltungen unterstützt.
7, 8 und 9 zeigen, dass die Corereg-Schaltung 700 eine Logikschaltung ist, die in dem Adressenabschnitt 942 der Zustandsmaschine 940 enthalten ist. Die Corereg-Schaltung 700 führt eine Logik aus, um auf die gewünschte Stelle in einem Master-Register 44 oder Slave-Register 46 zuzugreifen. Mindestens eine Ausfüh rungsform der Corereg-Registerzugriffschaltung 70 kann beispielsweise mit Verilog-Sourcecode implementiert werden, der in Appendix A aufgelistet ist.
Die Corereg-Registerzugriffschaltung 70 empfängt verschiedene Eingangswerte, die von Software geliefert werden, die auf dem Host-System 970 läuft. Ein solcher Eingangswert ist ein Addr_in-Wert, der für die jeweilige Adresse des gewünschten Feldes in dem betreffenden Master-Register 44 oder Slave-Register 46 steht. Ein anderer Eingangswert ist der Indexwert entweder im Master-Indexregister 40 oder im Slave-Indexregister 42. Zu Veranschaulichungszwecken wird auf die 3 und 7 und die Tabellen 1 und 2 verwiesen. Ein Slave-System 32 kann beispielsweise Kontexte von einem ersten Master 102-1 (dessen Kontextinformationen etwa in dem Master-Register 44a verfolgt werden) auf einen zweiten Master 36 (dessen Kontextinformationen etwa in dem Master-Register 44b verfolgt werden) umschalten. Bei zumindest einer Ausführungsform steht ein Indexwert 4b'0000' für das erste Master-Register 44a, während ein Indexwert 4b'0001' für das zweite Master-Register 44b steht. Um die Kontexte umzuschalten, ersetzt daher der Link-Controller 920 (9) den Indexwert 4b'000' im Master-Indexregister 40 mit einem Indexwert 4b'0001'. Auf diese Weise hat eine Kontextumschaltung stattgefunden.
Die Eingabeadresse Addr_in ist die Adresse des bestimmten Feldes in einem Slave-Register 46 oder Master-Register 44. Tabelle 1 gibt beispielsweise an, dass der Link-Controller 920 (9) Addr_in auf einen Wert 4b'0xCE' setzen würde, falls ein Master das AM_ADDR-Feld für einen bestimmten aktiven Slave lesen oder modifizieren müsste.
7 und 8 zeigen, dass das Corereg-Modul 70 eine Logik umfasst, die von der Regmux-Schaltung 72 zur Verfügung gestellt wird. Bei zumindest einer Ausführungsform ist die Regmux-Schaltung 72 eine Schaltung, die durch den in Appendix B aufgeführten Verilog-Sourcecode definiert ist, und ist eine mux-Schaltung, die bei Vorhandensein des korrekten Indexwertes und Addr_in-Wertes die betreffende spezifische Registerstelle zur Verfügung stellt.
Für den Fachmann dürfte ersichtlich sein, dass die von den Schaltungen Corereg 70 und Regmux 72 ausgeführte Logik von Hardware-Modulen durchgeführt werden kann, oder als Software-Module, Firmware-Module oder jegliche Kombination aus diesen implementiert sein kann. Der Fachmann dürfte ferner erkennen, dass eine sol che Verarbeitung auch nicht als separate Module, sondern als ein einzelnes Hardware- oder Software-Module implementiert sein kann, das verschiedene logische Funktionen umfasst. Wenn die Software in Software-Modulen implementiert ist, kann sie beispielsweise von einer eingebetteten CPU ausgeführt werden, die an Stelle der Zustandsmaschine 940 verwendet wird.
11 ist ein Ablaufdiagramm zur Veranschaulichung eines Master-Parameterzugriff-Softwaremoduls 1100, das die Logik der Zustandsmaschine 940 aufruft, um auf Informationen in einem Master-Register 44 zuzugreifen. Das Master-Parameterzugriffmodul 1100 enthält von einer Maschine ausführbare Anweisungen, die beispielsweise auf dem Host-Computer 970 ausgeführt werden.
11 veranschaulicht, dass der Host 970 zum Ausführen der Operation 1102 den geeigneten Indexwert in das Master-Indexregister 40 lädt. Falls das betreffende Master-Register 44 beispielsweise ein zweites Master-Register ist (bei dem der Indexwert für ein erstes Master-Register Null ist), wird ein Wert 4b'01' bei der Operation 1102 von dem Host 970 in das Master-Indexregister 40 geladen. Der Host-Computer 970 führt dann die Operation 1104 aus. Die Operation 1104 ruft die Corereg-Logikschaltung 70 (7) auf, um in das betreffende Register 44 zu schreiben oder aus ihm auszulesen. Die Operation 1104 umfasst einen Lesepfad und einen Schreibpfad.
Die 9 und 11 veranschaulichen, dass der Host-Computer 970 während des Lesepfades der Operation 1104 die folgenden Eingänge liefert und daraufhin die Corereg-Logikschaltung 70 aufruft:

• Liefern des Adresswertes Addr_in, der die Adresse des betreffenden Feldes in dem betreffenden Register identifiziert, und
• Liefern eines Lese-Steuereingangs, bei dem es sich um einen Lese-Strobe handelt, der anzeigt, dass die Inhalte des angegebenen Registerfeldes auf die Datenleitungen 948 gesetzt werden sollen.

Während des Schreibpfades der Operation 1104 liefert der Host-Computer 970 die folgenden Eingänge und ruft daraufhin die Logik der Corereg-Logikschaltung 70 auf:

• Liefern des Adresswertes Addr_in, der die Adresse des betreffenden Feldes in dem betreffenden Register identifiziert,
• Liefern eines in das angegebene Registerfeld zu schreibenden Datenwertes, und
• Liefern eines Schreib-Steuereingangs, bei dem es sich um einen Schreib-Strobe handelt, der anzeigt, dass der Datenwert zu den Inhalten des angegebenen Registerfeldes geschrieben werden soll.

12 ist ein Ablaufdiagramm zur Veranschaulichung eines Slave-Parameterzugriff-Softwaremoduls 1200, das die Logik der Zustandsmaschine 940 aufruft, um auf Informationen in einem Slave-Register 46 zuzugreifen. Das Slave-Parameterzugriffmodul 1200 enthält von einer Maschine ausführbare Anweisungen, die beispielsweise auf dem Host-Computer 970 ausgeführt werden.
12 veranschaulicht, dass der Host-Computer 970 bei der Ausführung der Operation 1202 den geeigneten Indexwert in das Slave-Indexregister 42 lädt. Wenn das betreffende Slave-Register 46 beispielsweise ein zweites Slave-Register ist (wobei der Indexwert für ein erstes Slave-Register Null ist), wird ein Wert 4b'01' bei der Operation 1202 von dem Host 970 in das Slave-Indexregister 42 geladen. Der Host-Computer 970 führt dann die Operation 1204 aus. Die Operation 1204 ruft die Corereg-Logikschaltung 70 (7), um in das betreffende Register 46 zu schreiben oder aus diesem auszulesen. Die Operation 1204 umfasst einen Lesepfad und eine Schreibpfad.
Die 9 und 12 zeigen, dass der Host-Computer 970 während des Lesepfades der Operation 1204 die folgenden Eingänge liefert und daraufhin die Corereg-Logikschaltung 70 aufruft:

Während des Schreibpfades der Operation 1204 liefert der Host-Computer 970 die folgenden Eingänge und ruft daraufhin die Logik der Corereg-Logikschaltung 70 auf

Der Fachmann wird erkennen, dass das Master-Parameterzugriffmodul 1100 und das Slave-Parameterzugriffmodul 1200 zwar als eine Reihe von sequenziellen Operationen beschrieben wurde, dass die Operationen jedoch nicht unbedingt in der erörterten Reihenfolge durchgeführt zu werden brauchen. Statt dessen können die Operationen in einer beliebigen Reihenfolge durchgeführt werden, welche die vorliegend beschriebene Funktionalität bewahrt. Beispielsweise können die jeweiligen Eingänge des Lese- und Schreibpfades in den Operationen 1104 und 1204 in einer beliebigen Reihenfolge vorgesehen werden. Der Fachmann wird ferner erkennen, dass Operationen, die als separate Operationen gezeigt sind, in der gleichen logischen Gruppe auf Anweisungen durchgeführt werden können.
Die von der vorliegenden Erfindung umfassten computerlesbaren Anweisungen können als Software-Anweisungen auf einem computerlesbaren physischen Medium implementiert werden, wie etwa einem beliebigen magnetischen Speichermedium einschließlich Disk- und Bandspeichermedium; einem optischen Speichermedium einschließlich Kompaktdisk-Speicher und einem digitalen Videodisk-Speichermedium; einem nicht-flüchtigen Speicher; einem flüchtigen Speichermedium; oder Datenübertragungsmedium mit Paketen von elektronischen Daten und elektromagnetischen Wellen, die gemäß den Anweisungen moduliert werden.
Zusätzliche Informationen hinsichtlich eines Typs von Mikroarchitektur, der bei der vorliegend beschriebenen Architektur angewendet werden kann, sind in dem US-Patent Nr. 6,804,772 der Erfinder Sherman Lee, Vivian Y. Chou und John H. Lin mit der Bezeichnung "Dynamic Field Patchable MicroArchitecture" beschrieben.
Obgleich die Erfindung unter Bezugnahme auf bestimmte Ausführungsformen beschrieben wurde, ist die Beschreibung nur ein Beispiel für die Anwendung der Erfindung und sollte nicht einschränkend aufgefasst werden. Obgleich sich die vorstehende Beschreibung beispielsweise auf die Bluetooth-Spezifikation bezieht, kann die vorliegend beschriebene Kontextumschalte-Architektur in einer beliebigen Netzumgebung verwendet werden, in der eine Kontextumschaltung zwischen Rechenvorrichtungen durchgeführt wird. Beispielsweise kann die vorliegende Erfindung in ei nem beliebigen Netz wie etwa einem Client/Server-Netz verwendet werden und braucht nicht unbedingt in einer Master/Slave-Netzumgebung verwendet werden. Auf ähnliche Weise brauchen die vorliegend beschriebenen Register keine Master- und Slave-Daten enthalten, sondern können statt dessen beliebige Kontextdaten enthalten. Verschiedene andere Adaptationen und Kombinationen von Merkmalen der beschriebenen Ausführungsformen liegen innerhalb des Schutzumfanges der Erfindung, wie er in den nachfolgenden Patentansprüchen definiert ist.
APPENDIX A
APPENDIX B

Claims

Verfahren zum Durchführen einer Kontextumschalte-Operation, gekennzeichnet durch: Zugreifen auf Kontextdaten in einem ersten Register (46a) eines peripheren Systems (972) durch den Host-Computer, wobei das erste Register (46a) einem ersten Indexwert zugeordnet ist, wenn ein Kontextindex-Register (42) auf den ersten Indexwert gesetzt ist; Empfangen eines zweiten Indexwertes von dem Host-Computer (970), der dem peripheren System (972) zugeordnet ist, durch das periphere System (972); Setzen des Kontextindex-Registers (42) auf den zweiten Indexwert, um eine Kontextumschaltung durchzuführen mittels Zugreifen auf Kontextdaten in einem zweiten Register (46b) des peripheren Systems (972), wobei das zweite Register (46b) dem zweiten Indexwert zugeordnet ist, wenn das Kontextindex-Register (42) auf den zweiten Indexwert gesetzt ist, wobei das erste (46a) und das zweite (46b) Register zusammen mit dem peripheren System (972) angeordnet sind.
Verfahren nach Anspruch 1, wobei die Kontextdaten ferner gekennzeichnet sind durch: eine Vorrichtungsadresse für eine von einer Mehrzahl von Netzwerkvorrichtungen; einen Klassenwert; einen Taktversatzwert; und eine Active Member Address.
Verfahren nach Anspruch 1, wobei der Schritt des Zugreifens auf Kontextdaten in einem zweiten Register (46b) ferner gekennzeichnet ist durch: Empfangen eines Adresswertes, der eine Adresse in dem zweiten Register (46b) identifiziert, durch das periphere System (972); Empfangen eines Steuereingangs, der zumindest eine von einer Mehrzahl von Funktionen identifiziert, durch das periphere System (972), wobei die Mehrzahl von Funktionen eine Lesefunktion und eine Schreibfunktion umfasst; Empfangen eines Datenwertes durch das periphere System (972), falls der Steuereingang die Schreibfunktion identifiziert; und falls der Steuereingang die Schreibfunktion identifiziert, Schreiben des Datenwertes in das zweite Register (46b) an der durch den Adresswert identifizierten Adresse.
Verfahren nach Anspruch 1, wobei der Schritt des Zugreifens auf Kontextdaten in einem zweiten Register (46b) ferner gekennzeichnet ist durch: Empfangen eines Adresswertes, der eine Adresse in dem zweiten Register (46b) identifiziert, durch das periphere System (972); Empfangen eines Lese-Steuereingangs durch das periphere System (972); und Bereitstellen der Inhalte des zweiten Registers an der durch den Adresswert identifizierten Adresse für den Host-Computer (970).
Verfahren nach Anspruch 1, wobei der Schritt des Zugreifens auf Kontextdaten in einem zweiten Register (46b) ferner gekennzeichnet ist durch: Empfangen eines Adresswertes, der eine Adresse in dem zweiten Register (46b) identifiziert, durch das periphere System (972); Empfangen eines Datenwertes durch das periphere System (972); Empfangen eines Schreib-Steuereingangs durch das periphere System (972); und Schreiben des Datenwertes in das zweite Register (46b) an der durch den Adresswert identifizierten Adresse.
Verfahren nach Anspruch 1, wobei der Schritt des Zugreifens auf Kontextdaten in einem zweiten Register (46b) ferner gekennzeichnet ist durch: Empfangen eines Adresswertes, der eine Adresse in dem zweiten Register (46b) identifiziert, durch das periphere System (972); Empfangen eines Steuereingangs, der eine von einer Mehrzahl von Funktionen identifiziert, durch das periphere System (972), wobei die Mehrzahl von Funktionen eine Lesefunktion und eine Schreibfunktion umfasst; und falls der Steuereingang die Lesefunktion identifiziert, Bereitstellen des Inhalts des zweiten Registers an der durch den Adresswert identifizierten Adresse für den Host-Computer (970).
System, gekennzeichnet durch: einen Host-Computer (970), wobei der Host-Computer (970) einen Mikroprozessor aufweist; zumindest ein mit dem Host-Prozessor gekoppeltes peripheres System (972), wobei das periphere System (972) aufweist: ein erstes Register (46a), wobei das erste Register (46a) einem ersten Indexwert zugeordnet ist, ein zweites Register (46b), wobei das zweite Register (46b) einem zweiten Indexwert zugeordnet ist, wobei das erste (46a) und das zweite (46b) Register zusammen mit dem peripheren System (972) angeordnet sind, und ein Kontextindex-Register (42); wobei eine Empfangsschaltung in dem zumindest einen peripheren System (972) enthalten ist, wobei die Empfangsschaltung dafür konfiguriert ist, den zweiten Indexwert von dem Host-Computer (970) zu empfangen, eine Einstellschaltung, die dafür konfiguriert ist, das Kontextindex-Register (42) auf den zweiten Indexwert zu setzen, um eine Kontextumschaltung durchzuführen; eine mit dem Host-Computer gekoppelte Registerzugriffschaltung, wobei die Registerzugriffschaltung dafür konfiguriert ist, die Kontextumschaltung durch Zugreifen auf Kontextdaten in dem ersten Register (46a) durchzuführen, wenn das Kontextindex-Register (42) auf den ersten Indexwert gesetzt ist, und durch Zugreifen auf Kontextdaten in dem zweiten Register (46b) durchzuführen, wenn das Kontextindex-Register (42) auf den zweiten Indexwert gesetzt ist.
System nach Anspruch 7, wobei das periphere System (972) ein Zustandsmaschinen-Modul aufweist, wobei das Zustandsmaschinen-Modul gekennzeichnet ist durch: einen Adressenabschnitt; einen Steuerabschnitt; und einen Datenabschnitt, wobei das erste Register (46a) und das zweite Register (46b) in dem Datenabschnitt enthalten sind.
System nach Anspruch 8, wobei der Adressenabschnitt durch die Registerzugriffschaltung gekennzeichnet ist.
System nach Anspruch 7, wobei das periphere System (972) durch eine Mehrzahl von Kontextregistern gekennzeichnet ist, wobei jedes der Mehrzahl von Kontextregistern einem von einer Mehrzahl von Indexwerten zugeordnet ist.