-
Die
Erfindung betrifft ein Einchipsystem (system an a chip) mit mehreren Subsystemen,
die autarke Systemeinheiten darstellen. Die Subsysteme sind zum
Austausch von Programmbefehlen und/oder Parametern und Daten über Datenleitungen
miteinander verbunden und weisen Datenschnittstellen auf, um Daten
und/oder Programmbefehle und/oder Parameter untereinander austauschen
zu können.
-
Ein
Charakteristikum eines Einchipsystems besteht darin, dass verschiedene
Systemeinheiten, die einzelne Subsysteme darstellen, auf einem gemeinsamen
Substrat implementiert sind, typischerweise auf einem Siliziumsubstrat.
Ein Ein – chipsystem
ist somit ein monolithisch integriertes System. Typische Anwendungsfelder
sind embedded systems (eingebettete Systeme).
-
Typische
Systembestandteile (Subsysteme) sind beispielsweise ein Mikroprozessor
oder ein Mikrocontroller, eine Datenverwaltungseinheit, eine Ein/Ausgabeeinheit
und Speicher in Form von Festspeicher (ROM: read only memory) oder
veränderlichen
Speicher (RAM: random access memory).
-
Mit
fortschreitender Integration bestehen Einchipsysteme zunehmend aus
mehreren größeren, weitgehend
autarken Einheiten oder Blöcken, welche
zusammenarbeiten, um die Aufgabe des Einchipsystems zu erfüllen. Jede
Systemeinheit, also jedes Subsystem erfüllt dabei eine selbständige Funktion.
Dazu stellen die Subsysteme anderen Subsystemen ihre spezifischen
Dienste – im
Falle der Speicherverwaltungseinheit beispielsweise die Speicherverwaltung – zur Verfügung und
nehmen ihrerseits die Dienste anderer Subsysteme in Anspruch. Ein Einchipsystem,
welches beispielsweise solche Subsysteme wie eine on-chip CPU in
Form eines Mikroprozessors oder Mikrocontrollers, eine Speicherverwaltungseinheit,
eine Verschlüsselungseinheit,
eine Ein/Ausgabeeinheit zur Kontrolle I/O Ports, diverse Hardwarebeschleunigungseinheiten
und Ähnliches umfasst,
ermöglicht
eine „event-driven" Architektur, die
für komplizierte
Aufgaben effizienter ist, als eine klassische CPU-zentrische Architektur.
Bei einer CPU-zentrischen Architektur steuert ein zentraler (Hardware
oder Software) Prozessor die Funktion des gesamten Systems, indem
dieser die Funktion aller beteiligten Subsysteme festlegt. Das wesentliche
Merkmal einer event-driven Architektur ist, dass die übergeordnete
Aufgabe durch Austausch von Kommandos und Daten zwischen gleichgestellten Subsystemen
gelöst
wird. Der Basisablauf ist, dass ein Subsystem (1) einem anderen
Subsystem ein Kommando zustellt, (2) wartet, bis dieses Kommando
ausgeführt
wurde, und (3) das Resultat der Ausführung in Empfang nimmt. Das
Resultat besteht beispielsweise aus ein oder mehreren berechneten Werten,
aus einer Statusmeldung, oder aus der Botschaft, dass die Bearbeitung
im beauftragten Subsystem abgeschlossen ist. Dabei besteht das Zustellen
eines Kommandos in dem Schreiben eines Kommandowortes in ein dafür vorgesehenes
Register.
-
Ein
solches Einchipsystem ist insbesondere dann effizient, wenn möglichst
viele Subsysteme (Systemeinheiten) parallel arbeiten können. Die
stellt insbesondere an den Austausch von Programmbefehlen und dazugehöriger Parameter
sowie an den Austausch von Daten zwischen den einzelnen Subsystemen
hohe Anforderungen. Bei einem komplexen System ist zu berücksichtigen,
dass ein Subsystem (hier genannt „Server-Subsystem") oftmals einen Dienst
anbietet, welcher von mehreren anderen Subsystemen (genannt „Clienten-Subsysteme") in An spruch genommen
werden kann. Dabei kann ein Subsystem sowohl in der Rolle eines
Servers als auch in der Rolle eines Clienten im Gesamtsystem auftreten.
Es muss also gewährleistet
sein, dass die autark und parallel arbeitenden Clienten-Subsysteme
nach Bedarf Kommandos an die benötigten
Server-Subsysteme verschicken können,
ohne dass Kommandos überschrieben
werden oder auf andere Weise verloren gehen. Dabei soll eine höchstmögliche Parallelität unterstützt werden,
indem Subsysteme nur soweit wie nötig auf die Beendigung eines Vorgang
in einem anderen Subsystem warten müssen.
-
Aus
EP 1 286 259 A1 ist
ein modulares Rechnersystem bekannt, das eine integrierte Schaltung
auf einem Chip zur Verfügung
stellt, die einen Prozessor und mindestens ein Modul enthält und für vorhandene
Module benötigte
Register sowie einen Zugriff auf diese Register bereitstellt. Dabei
erfolgt eine Konzentrierung der benötigten Register in einer zentralen
Registerbank, die wie der Prozessor und die Module an einen schnellen
AMBA-AHB Bus angeschlossen ist.
-
Weiterhin
sind aus
DE 199 52
272 A1 ein Verfahren und ein System zum Prüfen von
auf eingebetteten Bausteinen basierenden integrierten Systemchipschaltungen,
insbesondere von Großintegrationsschaltungen
auf einem Chip bekannt.
-
Des
weiteren ist aus
US
2005/0021871 A1 ein eigenständiges Multi-Prozessor-Subsystem mit Subprozessorkernen
als Baugruppe für
ein System-an-Chip-(SoC)
Design bekannt. Dabei enthält
jeder Subprozessor lokal jeweils eine Speichereinheit, beispielsweise
einen statischen oder dynamischen RAM.
-
Ziel
der hier beschriebenen Erfindung ist es, ein Einchipsystem zu schaffen,
welches einen effizienten Austausch von Programmbefehlen und gegebenenfalls
zugehöriger
Parameter sowie von Daten zwischen einzelnen Subsystemen erlaubt.
Eine mögliche
Lösung
ist, dass jedem Server-Subsystem ein einziges Eingangsregister (genannt „Kommandoregister") sowie zusätzliche
Register für
Daten und Rückgabewerte
zugeordnet werden, welche gleichermaßen von allen Clienten zur
Erteilung eines Kommandos sowie zum Transfer von Parametern und
Daten benutzt werden. Der Nachteil dieser Lösung ist, dass ein Client warten
muss, bis ein von einem anderen Clienten an das selbe Server-Subsystem
gesendetes Kommando vollständig
abgearbeitet ist, bevor das Kommando geschrieben werden kann. Dadurch
wird eine parallele Abarbeitung anderer Aufga ben im betrachteten
Clienten erschwert, da dieser die Bereitschaft des zu beauftragenden
Servers ständig überwachen
muss und bei Verfügbarkeit
die parallel abgearbeitete Aufgabe unterbrechen muss, um das Kommando
zu schreiben. Dieses kann in der Tat durchgeführt werden, führt aber
zu einer unerwünschten
Komplexität
im Clienten. Als weiterer Nachteil kann eintreten, dass verschiedene
Clienten auf die Bereitschaft des selben Server-Subsystems warten
können.
Es besteht damit die Notwendigkeit, eine Arbitrierung durchzuführen, welche
einem der wartenden Clienten das Recht zum Schreiben des Kommandos
erteilt.
-
Eine
andere mögliche
Lösung
ist, dass jedem Server-Subsystem eine Warteschlange von Kommandoregistern
zugeordnet wird. Zur Erteilung eines Kommandos schreibt ein Client
dieses Kommando an das Ende der Warteschlange und kann in vorteilhafter
Weise unmittelbar danach mit der parallelen Abarbeitung anderer
Aufgaben fortfahren. Das Server-Subsystem arbeitet die Komman dos
der Warteschlange nacheinander ab und geht in einen Ruhezustand,
sobald die Warteschlange leer ist. Die Nachteile dieser Lösung sind,
dass in einer Hardwarelösung
die Länge
der Warteschlange festgelegt ist, dass die Verwaltung der Warteschlange
aufwendig ist, dass eine Buchführung
für die
Quellen der Kommandos in der Warteschlange nötig ist, und dass eine Priorisierung
der Kommandos von verschiedenen Clienten schwierig ist.
-
Die
hier vorgestellte Lösung
beruht auf der Beobachtung, dass ohne großen Aufwand und in natürlicher
Weise der bilaterale Austausch von Kommandos und Rückgabedaten
zwischen jeweils zwei Subsystemen keine Warteschlange benötigt. Bei
den meisten Abläufen
erteilt der Client ein Kommando, d. h. sendet einen Programmbefehl
in einem gewissen Zusammenhang und arbeitet in diesem Zusammenhang
erst weiter, wenn die Resultate hierfür verfügbar sind. Es besteht i. A.
also nicht die Notwendigkeit, mehrere Kommandos von diesem Clienten
an dasselbe Server-Subsystem zu schicken. Dieses schließt aber
nicht aus, dass der betrachtete Client verschiedene Zusammenhänge gleichzeitig
bearbeitet, indem Kommandos an andere Server geschickt werden, bevor
das erste Resultat verfügbar
ist. In dieser Vorgehensweise besteht gerade das erwünschte parallele
Abarbeiten verschiedener Aufgaben auf dem betrachteten Clienten.
Bei Einhaltung der vorgestellten Bilateralität folgt, dass die Warteschlange
des Servers genau so groß dimensionert
werden muss, wie es „"interessierte" Clienten im System
gibt, welche auf diesen Server zugreifen wollen. Anderseits wäre eine
Verletzung der vorgestellten Bilateralität sowieso ungünstig, weil
eine geeignete Länge
der Warteschlange dann nicht festgelegt werden kann. Da also die
vorgeschlagene Warteschlange sinnvollerweise genau ein Kommandoregister
pro interessiertem Clienten hat, ist es vorteilhaft und ohne Nachteil,
diese Kommandoregister den Clienten direkt zuzuordnen.
-
Erfindungsgemäß wird das
Ziel, den effizienten Austausch von Kommandos und Daten zwischen autark
und parallel arbeitenden Subsystemen in einem Einchipsystem der
eingangs genannten Art erreicht, indem jedem Subsystem eine Datenschnittstelle
mit einer Anzahl von Befehlsregistern zugeordnet ist, wobei diese
Anzahl von Befehlsregistern einer jeweiligen Datenschnittstelle
eines jeweiligen Subsystems der Zahl von weiteren Subsystemen entspricht,
mit der das jeweilige Subsystem zum Datenaustausch verbunden ist.
Jedes der Register einer Datenschnittstelle eines Subsystems ist
hierbei jeweils genau einem der weiteren Subsysteme dauerhaft zugeordnet,
so dass für
den Programmbefehl- oder Datenaustausch zwischen zwei Subsystemen jeweils
ein genau zugeordnetes Register vorgesehen ist.
-
Anders
ausgedrückt:
immer wenn ein Subsystem Steuerbefehle an ein anderes Subsystem übermitteln
können
soll ist hierfür
ein gerichteter Kommandopfad vorzusehen. Erfindungsgemäß ist jedem
Kommandopfad ein Befehlsregister eindeutig und dauerhaft zugeordnet.
-
Auf
diese Weise kann jedes Subsystem Programmbefehle oder Daten von
einem anderen Subsystem empfangen, und den Programmbefehl oder die
Daten ausführen
beziehungsweise verarbeiten und das Ergebnis beispielsweise an das
andere Subsystem zurückschicken.
Der Austausch von Daten oder Programmbefehlen ist in jedem Falle
ein uni- oder bilateraler Austausch zwischen zwei Subsystemen, so
dass beispielsweise keine Datenqueue erforderlich ist, auf die gleich
mehrere Subsysteme gleichzeitig Zugriff haben. Vielmehr sendet ein
auftraggebendes Subsystem einen Programmbefehl gegebenenfalls mit
zugehörigen
Parametern an ein anderes Subsystem, welches den Programmbefehl dann
verarbeitet und das Ergebnis der Bearbeitung an das auftraggebende
Subsystem zurücksendet.
In der Regel wird das auftraggebende Subsystem keinen weiteren Programmbefehl
an jenes Subsystem absenden, bevor es das Ergebnis der Bearbeitung des
vorangegangenen Programmbefehls von jenem Subsystem zurückerhalten
hat.
-
Hieraus
ergeben sich eine Reihe von Vorteilen:
- – Es ist
keine Arbitrierung von miteinander konkurrierenden Programmbefehlen
erforderlich, wie es bei der Verwendung eines einzigen Kommandoregisters
pro Server-Subsystem nötig
wäre.
- – Es
sind genau so viele Register vorhanden, wie für eine parallele Funktion der
Subsysteme erforderlich ist.
- – Es
entfällt
das komplizierte Verwalten einer Warteschlange (Queue).
- – Ein
Subsystem kann in einfacher Art und Weise Programmbefehle parallel
an verschiedene Subsysteme absetzen (jedoch nicht an ein und dasselbe
Subsystem), da für
jedes andere Subsystem jeweils ein separates Register vorgesehen ist.
- – Ein
jeweils nur einen Programmbefehl empfangendes Subsystem kann für die Abarbeitung
der eingehenden der ggf. von verschiedenen anderen Subsystemen parallel
eingehenden Programmbefehle in einfacher Weise eine Priorisierung
durchführen.
-
Vorteilhafterweise
ist jedes Register genau an das Format der Programmbefehle oder
Daten angepasst, die dasjenige Subsystem, dem das Register zugeordnet
ist, an das Subsystem, dessen Bestandteil das Register ist, übertragen
kann. Durch die eindeutige Zuordnung von Befehlsregistern zu jeweiligen
Subsystemen ist es somit möglich,
die Register Maßzuschneidern.
-
Vorzugsweise
weisen wenigstens einzelne der Befehlsregister mehrere Registerabschnitte
für unterschiedliche
Daten auf, z. B. für
Steuerbefehle und Programmbefehle. Zusätzliche Registerabschnitte
können
für Parameter
zu Programmbefehlen vorgesehen sein.
-
Das
Einchipsystem weist darüber
hinaus vorzugsweise eine Datenaustauschsteuereinheit auf, während gleichzeitig
der Registerabschnitt für
Steuerbefehle einen 1 Bit langen Unterabschnitt für ein Busy
Bit aufweist. Die Datenaustauschsteuereinheit ist hierbei ausgebildet,
ein Busy-Bit eines Befehlsregisters des eigenen Subsystems zu löschen, nachdem
dieses Befehlsregister ausgelesen ist.
-
Vorteilhafterweise
ist hierbei die Datenaustauschsteuereinheit so ausgebildet, dass
sie ein Befehlsregister eines anderen Subsystems nur dann beschreibt,
wenn dessen Busy-Bit gelöscht
ist und mit dem Beschreiben des Befehlsregisters des anderen Subsystems
das Busy-Bit dieses Subsystems zu setzen.
-
Der
Registerabschnitt für
Steuerbefehle besitzt vorzugsweise einen 1 Bit langen Unterabschnitt für ein Notify-Bit.
Dann kann gemäß einer
besonders bevorzugten Ausführungsvariante
eine Datenaustauschsteuereinheit vorgesehen sein, die ausgebildet
ist, eine Rückmeldung
an jenes Subsystem zu senden, welchem das jeweilige Befehlsregister
zugeordnet ist, sobald ein jeweiliger Programmbefehl aus diesem
Befehlsregister abgearbeitet ist.
-
Die
Datenleitungen zwischen einzelnen Subsystemen können von direkten Datenpfaden
gebildet sein, sie können
jedoch auch in Form eines Systembusses verwirklicht sein. Letzteres
ist bevorzugt.
-
Vorzugsweise
ist wenigstens ein Subsystem des Einchipsystems eine zentrale Recheneinheit (CPU),
die von einem Mikroprozessor oder einem Mikrocontroller gebildet
wird, während
ein anderes Subsystem eine Speicherverwaltungseinheit (MMU: memory
management unit) ist.
-
Weitere
vorteilhafte Bestandteile des Einchipsystems sind beispielsweise
eine parallele Ein-/Ausgabeeinheit (PIO: parallel input/output),
ein universeller asynchroner Sender/Empfänger (UART) oder eine Hardware
Verschlüsselungseinheit
für beispielsweise
die Eliptische-Kurven-Kryptographie (ECC).
-
Weitere
vorteilhafte Merkmale der Erfindung ergeben sich aus der nachfolgenden
Beschreibung eines Ausführungsbeispiels
und dies wird mit Bezug auf die Figuren erläutert. Von diesen zeigen
-
1 ein
schematisches Blockschaltbild eines Einchipsystems,
-
2 ein
komplexeres Ein-Chip-System; und
-
3 eine
abstraktere Darstellung des Ein-Chip-Systems aus 2,
welche die Subsyteme und die Verbindungen zwischen diesen deutlich macht.
-
Das
in der Figur dargestellte Einchipsystem 10 umfasst insgesamt
vier Subsysteme, nämlich
eine von einem Mikroprozessor gebildete zentrale Recheneinheit CPU 12,
eine Speicherverwaltungseinheit MMU 14, eine parallele
Ein-/Ausgabeeinheit PIO 16 und einen flüchtigen Speicher RAM 18.
Die zentrale Recheneinheit CPU 12, die Speicherverwaltungseinheit
MMU 14 und die parallele Ein-/Ausgabeeinheit 16 sind über einen
Systembus 20 miteinander verbunden.
-
Die
Speicherverwaltungseinheit MMU 14 ist darüber hinaus
mit dem flüchtigen
Speicher RAM 18 des Einchipsystems sowie mit einer Schnittstelle 22 für externen
Speicher verbunden.
-
Die
parallele Ein-/Ausgabeeinheit PIO 16 ist mit einer Anschlussschnittstelle 24 für den Anschluss externer
Geräte
verbunden.
-
Das
recht einfache Einchipsystem gemäß 1 besitzt
somit drei Subsysteme, die über
den Bus 20 miteinander Programmbefehle nebst gegebenenfalls
zugehöriger
Parameter und/oder Daten austauschen können, nämlich die zentrale Recheneinheit
CPU 12, die Speicherverwaltungseinheit MMU 14 und
die parallele Ein-/Ausgabeeinheit PIO 16.
-
Für diesen
Programmbefehl- beziehungsweise Datenaustausch weist jedes Subsystem
eine Datenschnittstelle auf, die von einem oder mehreren Registern
gebildet ist. Die Anzahl der Register richtet sich dabei danach,
von welchem weiteren Subsystemen ein jeweiliges Subsystem Programmbefehle oder
Daten erhalten können
soll. In diesem Falle soll die Speicherverwaltungseinheit MMU 14 Daten
ausschließlich
mit der zentralen Recheneinheit CPU 12 austauschen. Gleiches
gilt für
die parallele Ein-/Ausgabeeinheit 16. Nur die zentrale
Recheneinheit CPU 12 soll Programmbefehle beziehungsweise
Daten sowohl mit der Speicherverwaltungseinheit MMU 14 als
auch mit der parallelen Ein-/Ausgabeeinheit PIO 16 austauschen
können.
-
Dementsprechend
besitzt die zentrale Recheneinheit CPU 12 eine Datenschnittstelle
mit zwei Registern, von denen ein erstes Register R-MMU 30 dem
Datenaustausch mit der Speicherverwaltungseinheit MMU 14 zugeordnet
ist, während ein
zweites Register 32 dem Datenaustausch mit der zentralen Ein-/Ausgabeeinheit PIO 16 zugeordnet
ist. Die Datenschnittstelle der Speicherverwaltungseinheit MMU 14 umfasst
nur ein einziges Register für
den R-CPU 34 für
den Austausch von Programmbefehlen und Daten mit der zentralen Recheneinheit
CPU 12. Auch die parallele Ein-/Ausgabeeinheit PIO 16 umfasst
eine Datenschnittstelle mit nur einem Register R-CPU 36 für einen
Datenaustausch mit der zentralen Recheneinheit CPU 12.
-
Jedes
der Register der jeweiligen Datenschnittstellen ist somit dem Datenaustausch
mit genau einem jeweiligen anderen Subsystem eindeutig zugeordnet.
Dabei versteht es sich von selbst, dass die jeweilige Datenschnittstelle
eines jeweiligen Subsystems weit mehr als die beispielhaften ein
oder zwei Register umfassen kann, falls ein jeweiliges Subsystem
dazu ausgebildet sein sollte, mit entsprechend mehreren anderen
Subsystemen Daten oder Programmbefehle auszutauschen. Dabei kann
ein jeweiliges Subsystem die verschiedenen Register seiner Datenschnittstelle
parallel bedienen und somit einen parallelen Datenaustausch mit
unterschiedlichen Subsystemen durchführen. Dabei ist jeder Datenaustausch
ein bilateraler Datenaustausch und jedes Subsystem kann erst dann
wieder Daten oder Programmbefehle an ein anders Subsystem weiterleiten, wenn
das andere Subsystem das dem jeweiligem Subsystem zugeordnete Register
(wieder) freigibt. Dabei kann es nicht dazu kommen, dass der Datenaustausch
zwischen zwei Subsystemen durch ein drittes Subsystem behindert
ist, weil die entsprechenden Register nicht freigegeben sind, so
wie dies bei herkömmlichen
Einchipsystemen gemäß dem Stand
der Technik vorkommen könnte.
-
Im
dargestellten Ausführungsbeispiel
ist beispielsweise das Register 36 ein Befehlsregister, über welches
die parallele Ein-/Ausgabeeinheit PIO 16 Steuerbefehle
seitens der zentralen Recheneinheit CPU 12 empfangen kann.
-
Die
Befehlsregister sind so ausgebildet, dass sie entweder einen Registerabschnitt
oder mehrere Registerabschnitte für unterschiedliche Daten aufweisen,
nämlich
beispielsweise für
Steuerbefehle, Programmbefehle und Parameter. Ein typisches Befehlsregister
weist einen ersten, vorzugsweise 8 Bit langen Abschnitt für Steuerbefehle
auf, einen zweiten, ebenfalls 8 Bit langen Abschnitt für Programmbefehle
sowie zwei weitere, jeweils 8 Bit lange Abschnitte für Parameter.
-
Der
Registerabschnitt für
Steuerbefehle weist einen 1 Bit langen Unterabschnitt für ein Busy Bit
auf. Ein zweiter, 1 Bit langer Unterabschnitt des Registerabschnitts
für Steuerbefehle
ist für
Notify Bit vorgesehen. Ein dritter, 1 Bit langer Unterabschnitt
ist für
ein Respond Bit vorgesehen. Weitere, jeweils 1 Bit lange Unterabschnitte
können
beispielsweise für Statusbits
vorgesehen sein.
-
Jedes
Subsystem ist so ausgebildet, dass es beim Versenden eines Befehls
(genauer gesagt: eines Programmbefehls) an ein anderes Subsystem
in das entsprechende Befehlsregister des anderen Subsystems zum
einen den Programmbefehl selbst und gegebenenfalls die zur Ausführung des
Programmbefehls notwendigen Parameter hineinschreibt. Außerdem setzt
das sendende Subsystem im Befehlsregister des empfangenden Subsystems das
Busy Bit auf 1. Das empfangende Subsystem ist so ausgebildet, dass
es das Busy Bit wieder auf 0 zurücksetzt,
sobald das empfangende Subsystem sein entsprechendes Befehlsregister
ausgelesen hat.
-
Außerdem kann
das sendende Subsystem in dem für
Steuerbefehle vorgesehenen Registerabschnitt des Befehlsregisters
des empfangenden Subsystems ein zweites Bit, nämlich das Notify Bit auf 1 setzen,
um dem empfangenden Subsystem anzuzeigen, dass das empfangende Subsystem
an das sendende Subsystem eine Rückmeldung
sendet, wenn es den vom sendenden Subsystem übermittelten Programmbefehl
ausgeführt
hat.
-
Jener
Bestandteil eines jeweiligen Subsystems, der je nach Art des Subsystems
das Versenden von Programmbefehlen und ggf. Parametern, das Setzen
des Busy-Bits und ggf. des Notify-Bits sowie das Löschen des
Busy-Bits und des Notify-Bits und das Versenden einer Rückmeldung
veranlasst wird im Rahmen dieser Beschreibung mit Datenaustauschsteuereinheit
bezeichnet.
-
Ein
Datenaustausch zwischen einem sendenden Subsystem und einem empfangenden
Subsystem weist – gesteuert
durch die Datenaustauschsteuereinheit – somit typischerweise die
folgenden Schritte auf:
- 1. Das sendende Subsystem
schreibt einen Befehl in das Befehlsregister des empfangenden Subsystems
und setzt das Busy Bit in dem für Steuerbefehle
vorgesehenen Registerabschnitt des Registers auf 1. Vorher fragt
das Sendesubsystem den Status des Busy Bits in dem Befehlsregister
des empfangenden Subsystems ab und schreibt den zu versendenden
Befehl nur dann in das Befehlsregister des empfangenen Subsystems,
wenn das Busy Bit zunächst
auf 0 gesetzt ist.
- 2. Das empfangene Subsystem beginnt daraufhin, sein Befehlsregister
auszulesen und den ihm übersandten
Programmbefehl auszuführen.
-
Nachdem
das empfangende Subsystem sein entsprechendes Befehlsregister ausgelesen
hat, setzt es das Busy Bit dieses Befehlsregisters auf 0.
-
Das
Notify-Bit zusammen mit einem weiteren Bit, nämlich einem Respond-Bit erlauben
es, dass ein Untersystem automatisch benachrichtigt wird, wenn ein
Steuernbefehl von einem anderen Subsystem fertig bearbeitet wurde.
Dadurch wird eingespart, dass das Subsystem ständig das Busy Bit abfragen muss.
Außerdem
wird Energie gespart, da Subsysteme "einschlafen" können.
Die Benachrichtigung wird von der Datenaustauschsteuereinheit ausgelöst und durch
das Notify-Bit und das Respond-Bit gesteuert. Das Respond Bit wird
seitens des empfangenden Subsystems im Befehlsregister des ursprünglich sendenden
Subsystems auf 1 gesetzt, sobald das empfangende Subsystem die mit
dem Notify Bit angeforderte Rückmeldung
an das ursprünglich
sendende Subsystem übermittelt
hat.
-
2 und 3 zeigen
die Architektur eines beispielhaften Singlechipsystems. 2 zeigt
alle Details und Schnittstellen. 3 zeigt
die Subsysteme. Das Singlechipsystem weist Verschlüsselungssubsysteme
ECC für
die elliptische-Kurven-Kryptographie
und AES für
die Verschlüsselung
gemäß dem Advanced Encryption
Standard in separaten Hardwareblöcken
auf. Es gibt hier die folgenden Blöcke:
- • Registers & Control ist ein
Register File, das auch die Datenaustauschsteuereinheit enthält. In dem
Register File sind alle Befehlsregister (sowie benötigte Parameterregister)
gebündelt.
Das ist also kein Subsystem im Sinne des Patentes.
- • CPU
ist die zentrale Recheneinheit in dem Singlechipsystem, auf welchem
in einem Subsystem eine TCP/IP Firmware läuft. CPU stellt ein eigenes
Subsystem dar.
- • Cardbus
ist ein Hardware-Controller, welcher die obere Schnittstelle zu
einem Host bedient. Cardbus ist ebenfalls ein Subsystem. Funktionell
sind die Befehlsregister, welche diesem Block zugeordnet sind, für die Kommunikation
zum Host zuständig.
- • Data
I/O ist ein ähnliches
Subsystem, welches eine untere Schnittstelle etwa zur Network Card (WLAN,
Ethernet usw.) bedient.
- • ECC
ist das Subsystem, welches die Ver-/Entschlüsselung nach dem ECC Algorithmus
in Hardware durchführt.
- • AES/MD5
ist das Subsystem, welches Ver-/Entschlüsselung nach AES durchführt, außerdem kann
eine MD5 Checksumme berechnet werden.
-
Die
Blöcke
sind alle (zusammen mit einem externen Speicher) über einen
Systembus miteinander verbunden. Für den Austausch von Steuerbefehlen
und Daten zwischen den 5 Subsystemen sind entsprechende Befehlsregister
vorgesehen:
Cardbus und CPU weisen jeweils ein dem jeweils
anderen Subsystem zugeordnetes Befehlsregister für eine Datenkommunikation in
beide Richtungen auf. CPU und Data-IO weisen ebenfalls ein dem jeweils anderen
Subsystem zuge ordnetes Befehlsregister für eine Kommunikation in beide
Richtungen auf. ECC und AES weisen jeweils nur ein Befehlsregister für den Empfang
von Steuerbefehlen und Daten seitens der CPU auf.
-
Im
Folgenden wird knapp anhand zweier Beispiele die Kommunikation zwischen
CPU und ECC sowie zwischen CPU und Data-IO erläutert:
ECC ist ein sehr
aufwendiger Algorithmus, welcher auch in seiner Implementierung
in Hardware lange dauert. Das CPU Subsystem erteilt dem ECC Subsystem
das entsprechende Befehlsregister den Befehl zum Verschlüsseln von
Daten. Die zu verschlüsselnden
Daten werden in Parameter-Registern durchgegeben. Während dass
ECC Subsystem arbeitet, kann das CPU etwas anderes berechnen oder alternativ
einschlafen. Wenn der ECC schließlich fertig ist, wird das
CPU Subsystem über
das Response-Bit benachrichtigt und holt die verschlüsselten
Daten ab. Hier gibt es nur den Kommandopfad vom CPU Subsystem zum
ECC Subsystem, also ECC spielt die Rolle eines "Slave" Systems.
-
Das
Data-IC Subsystem macht eine relativ weitgehende Verarbeitung eingehender
Daten über die
untere Schnittstelle wie z. B. Daten in den Speicher schreiben,
TCP/IP Header auseinander nehmen, Checksum prüfen usw. Wenn ein Datenpaket fertig
bearbeitet wurde, erteilt das Data-IC Subsystem den Steuerbefehl "Bearbeite die Daten
an Stelle XXX im Speicher" an
das CPU Subsystem. Deswegen gibt es einen Kommandopfad vom Data-IC
Subsystem zum CPU Subsystem. Wenn dagegen Datenpakete verschickt
werden sollen, stellt das CPU Subsystem zuerst die zu verschickenden
Daten im Speicher zusammen und erteilt dann den Steuerbefehl "verschicke Daten-Paket" an das Data-IC Subsystem.
Deshalb gibt es auch den Kommandopfad vom CPU zum Data-IC. Diese
Pfade haben sehr wenig mit einander zu tun und werden durch getrennte
Befehlsregister verwaltet.
-
Zwischen
dem CPU Subsystem und dem Cardbus Subsystem (also eigentlich zwischen
CPU und Host) gibt es Kommandopfade in beide Richtungen, weil Daten
in beide Richtungen ausgetauscht werden. Außerdem wird die gesamte Steuerung/Konfiguration
des TCP Chips vom Host aus so durchgeführt.
-
In
dem dargestellten Singlechipsystem kommt eine getrennte Einheit
zur Speicherverwaltung ("malloc") nicht vor. Ein
solches Speicherverwaltungs-Subsystem könnte jedoch vorgesehen werden.
Dieses Subsystem würde
als "slave" funktionieren und
von CPU und Data-IC (evtl. auch vom Host über Cardbus) in Anspruch genommen
werden, so dass entsprechende Befehlsregister für die dann erforderlichen Kommandopfade
vorzusehen wären.