Title:
Einchipsystem
Kind Code:
B4


Abstract:

Einchipsystem (10) mit mehreren Subsystemen (12, 14, 16), die zum Austausch von Programmbefehlen und/oder Parametern und über Datenleitungen miteinander verbunden und auf einem gemeinsamen Substrat angeordnet sind, wobei den Subsystemen (12, 14, 16) jeweils wenigstens eine Datenschnittstelle zugeordnet ist, über die ein jeweiliges Subsystem (12, 14, 16) mit wenigstens einer Datenleitung und über diese Datenleitung mit wenigstens einem anderen Subsystem (12, 14, 16) verbunden ist, dadurch gekennzeichnet, dass jede Datenschnittstelle eines Subsystems (12, 14, 16) eine Anzahl von Befehlsregistern (30, 32, 34, 36) aufweist, die der Zahl der weiteren Subsysteme (12, 14, 16) entspricht, mit der das eine Subsystem (12, 14, 16) zum Empfangen von Befehlen verbunden ist, wobei jedes Befehlsregister (30, 32, 34, 36) des einen Subsystems (12, 14, 16) jeweils genau einem der weiteren Subsysteme (12, 14, 16) zugeordnet ist.




Inventors:
METHFESSEL MICHAEL (DE)
PETER STEFFEN (DE)
ZESSACK MARIO (DE)
Application Number:
DE102007037064
Publication Date:
06/10/2009
Filing Date:
08/03/2007
Assignee:
IHP GMBH (DE)
International Classes:
Domestic Patent References:
DE19952272A1N/A2000-05-04



Foreign References:
200500218712005-01-27
EP12862592003-02-26
Attorney, Agent or Firm:
Eisenführ, Speiser & Partner (Berlin)
Claims:
1. Einchipsystem (10) mit mehreren Subsystemen (12, 14, 16), die zum Austausch von Programmbefehlen und/oder Parametern und über Datenleitungen miteinander verbunden und auf einem gemeinsamen Substrat angeordnet sind, wobei den Subsystemen (12, 14, 16) jeweils wenigstens eine Datenschnittstelle zugeordnet ist, über die ein jeweiliges Subsystem (12, 14, 16) mit wenigstens einer Datenleitung und über diese Datenleitung mit wenigstens einem anderen Subsystem (12, 14, 16) verbunden ist, dadurch gekennzeichnet, dass jede Datenschnittstelle eines Subsystems (12, 14, 16) eine Anzahl von Befehlsregistern (30, 32, 34, 36) aufweist, die der Zahl der weiteren Subsysteme (12, 14, 16) entspricht, mit der das eine Subsystem (12, 14, 16) zum Empfangen von Befehlen verbunden ist, wobei jedes Befehlsregister (30, 32, 34, 36) des einen Subsystems (12, 14, 16) jeweils genau einem der weiteren Subsysteme (12, 14, 16) zugeordnet ist.

2. Einchipsystem nach Anspruch 1, dadurch gekennzeichnet, dass jedes Befehlsregister (30, 32, 34, 36) an das Format der Daten angepasst ist, die dasjenige Subsystem (12, 14,16) dem das Befehlsregister (30, 32, 34, 36) zugeordnet ist, an das Subsystem (12, 14, 16), dessen Bestandteil das Befehlsregister (30, 32, 34, 36) ist, übertragen kann.

3. Einchipsystem nach Anspruch 2, dadurch gekennzeichnet, dass wenigstens einzelne der Befehlsregister mehrere Registerabschnitte für unterschiedliche Daten aufweisen.

4. Einchipsystem nach Anspruch 3, dadurch gekennzeichnet, dass die Befehlsregister unterschiedliche Registerabschnitte für Steuerbefehle und Programmbefehle aufweisen.

5. Einchipsystem nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass das Einchipsystem eine Datenaustauschsteuereinheit aufweist und der Registerabschnitt für Steuerbefehle einen 1 Bit langen Unterabschnitt für ein Busy Bit aufweist, wobei die Datenaustauschsteuereinheit ausgebildet ist, ein Busy-Bit eines Befehlsregisters des eigenen Subsystems zu löschen, nachdem dieses Befehlsregister ausgelesen ist.

6. Einchipsystem nach Anspruch 5, dadurch gekennzeichnet, dass die Datenaustauschsteuereinheit ausgebildet ist, ein Befehlsregister eines anderen Subsystems nur zu beschreiben, wenn dessen Busy-Bit gelöscht ist und mit dem Beschreiben des Befehlsregisters des anderen Subsystems das Busy-Bit dieses Subsystems zu setzen.

7. Einchipsystem nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass der Registerabschnitt für Steuerbefehle einen 1 Bit langen Unterabschnitt für ein Notify-Bit aufweist.

8. Einchipsystem nach Anspruch 7, dadurch gekennzeichnet, dass das Einchipsystem eine Datenaustauschsteuereinheit aufweist, 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.

9. Einchipsystem nach Anspruch 3, dadurch gekennzeichnet, dass die Befehlsregister zusätzlich Registerabschnitte für Parameter zu Programmbefehlen aufweisen.

10. Einchipsystem nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Datenleitungen einen Systembus (20) bilden.

11. Einchipsystem nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass eines der Subsysteme (12, 14, 16) eine zentrale Recheneinheit (12) ist und ein anderes der Subsysteme eine Speicherverwaltungseinheit (14).

Description:

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 Anspruch 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 Aufgaben 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 Kommandos 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 zugeordnetes 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.