-
GEBIET DER ERFINDUNG
-
Die Erfindung betrifft allgemein System-on-Chip(SoC)- und Network-on-Chip(NoC)-Architekturen und betrifft insbesondere, jedoch nicht ausschließlich, Techniken zum Ermöglichen einer Laufzeitrekonfiguration von Fabrics, die von Systemen, SoCs und NoCs genutzt werden.
-
INFORMATIONEN ZUM STAND DER TECHNIK
-
Seit der Einführung des Mikroprozessors sind Computersysteme immer schneller geworden. In ungefährem Einklang mit dem Mooreschen Gesetz (das auf der Veröffentlichung von Gordon Moore, eines Mitgründers der Intel® Corporation, von 1965 mit der Prognose beruht, dass sich die Anzahl von Transistoren in integrierten Schaltungen alle zwei Jahre verdoppeln würde) ist die Geschwindigkeitserhöhung fast drei Jahrzehnte lang mit ziemlich gleichmäßiger Schnelligkeit rapide angestiegen. Gleichzeitig sind sowohl Arbeitsspeicher als auch nichtflüchtige Speicher auch stetig größer geworden, sodass viele der heutigen Arbeitsplatzcomputer leistungsfähiger sind als Supercomputer vor gerade einmal 10–15 Jahren.
-
Ehemals nutzten Computerarchitekturen diskrete Komponenten wie zentrale Verarbeitungseinheiten (CPUs, auch bekannt als Prozessoren), Speichercontroller oder Hubs, E/A(Eingang/Ausgang)-Controller oder -Hubs etc., die Zwischenverbindungen über einen Bus und/oder Verdrahtungen waren, die auf einer Platine eingebettet waren, auf welcher die diskreten Komponenten eingebaut wurden. In den letzten Jahren wurden diese herkömmlichen Architekturen ersetzt durch System-on-Chip(SoC)-Architekturen, in denen verschiedene Intellectual-Property(IP)-Blöcke über eine oder Interconnect-Fabrics untereinander verbunden sind. Wie hierin verwendet, steht ein IP-Block repräsentativ für einen Block oder eine logische Gruppe von Schaltungen, der bzw. die in der Regel einer oder mehreren zielgerichteten Funktionen dient und Logik umfassen kann, die entweder unternehmensintern entwickelt oder im Rahmen einer Lizenz von einem Dritten erworben wurde. IP-Blöcke werden gemeinhin auch als Funktionsblöcke oder mit „IP” bezeichnet. Die Interconnect-Fabrics umfassen in der Regel möglicherweise mehrere Punkt-zu-Punkt-Zwischenverbindungen zwischen verschiedenen IP-Block-Endpunkten, eine kreuzschienenartige Zwischenverbindung (die beide gemeinhin als auf Vermaschung basierende Fabrics bezeichnet werden) oder eine ringartige Zwischenverbindung, die mehrere Zwischenverbindungssegmente enthält, welche zwischen Knoten im Ring gekoppelt sind, die an die verschiedenen IP-Blöcke gekoppelt sind.
-
Auf einer Ebene arbeiten Fabric-Zwischenverbindungen so ähnlich wie ein Computernetz, wobei ein Mehrschichtenprotokoll zum Übertragen von Daten zwischen Endpunkten genutzt wird. Zum Beispiel sind mehrere IP-Blöcke möglicherweise, entweder direkt oder indirekt (z. B. über eine Brücke oder eine andere Zwischenkomponente), mit einer Fabric verbunden, ungefähr analog zu mehreren mit einem Local Area Network (LAN) verbundenen Computern. Um Daten zwischen einem Paar von IP-Blöcken zu übertragen, wird ein Mehrschichtenprotokoll genutzt, das Adressinformationen wie die Quell- und die Zieladresse enthält, analog zu einem IP-Netz (wobei darauf hingewiesen wird, dass neben anderen Unterschieden das Adressformat anders ist). Wie ein LAN enthält die Fabric eine Schnittstelle (d. h. Fabric-Ports), mit der die IP-Blöcke verbunden sind, und ermöglicht das Vermitteln/Routing/Weiterleiten von Daten zwischen sendenden und empfangenden IP-Blöcken, die auch als (Netz-)Knoten bezeichnet werden können. In Anbetracht dieser Ähnlichkeiten werden integrierte Schaltungen, die diese Architekturen nutzen, manchmal als Network-on-Chip(NoC)-Architekturen bezeichnet, und die Fabric-Zwischenverbindungen können als Fabric-Switches bezeichnet werden, die Datenübertragungen zwischen IP-Blöcken ermöglichen, die an die Fabric gekoppelte Knoten umfassen.
-
Gemäß einer Standardimplementierung einer On-Chip-Fabric sind die Routingtabellen oder die Routinglogik der Fabric statisch konfiguriert, wobei das Paketziel basierend darauf, dass ein bestimmtes Feld oder bestimmte Felder des Pakets in die Fabric eintreten (z. B. die Zieladresse), ein bestimmter Knoten oder bestimmte Knoten ist. In Fällen, in denen der Zielknoten ausgeschaltet ist, die Daten aufgrund von Sicherheitsüberlegungen nicht empfangen soll oder den Typ des an ihn weitergeleiteten Verkehrs nicht unterstützt, wird das Paket entweder verworfen oder eine Benachrichtigung an den Absender darüber gesendet, dass die Transaktion fehlgeschlagen ist, sodass ein Softwareeingriff erforderlich wird. Solche Vorkommnisse führen häufig zu Systemabstürzen und/oder Ereignissen eines „Blue Screen of Death” (BSoD).
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Die vorstehenden Aspekte und viele der damit einhergehenden Vorteile dieser Erfindung werden noch klarer erkennbar, wenn zu ihrer besseren Verständlichkeit auf die folgende ausführliche Beschreibung in Verbindung mit den beiliegenden Zeichnungen Bezug genommen wird, wobei sich gleiche Bezugszeichen in den verschiedenen Ansichten je auf gleiche Teile beziehen, sofern nicht anders angegeben:
-
1 ist eine schematische Darstellung, die eine Architektur eines beispielhaften SoC, das eine Fabric nutzt, die eine Laufzeitrekonfiguration unterstützt, gemäß einer Ausführungsform veranschaulicht;
-
1a ist eine schematische Darstellung, die eine abstrahierte Ansicht der SoC-Architektur von 1 zeigt, die den Network-on-Chip-Aspekt der Architektur veranschaulicht;
-
1b ist eine schematische Darstellung, die eine alternative Konfiguration für die SoC-Architektur von 1 veranschaulicht, gemäß der die Endpunkt-Fabric-Schnittstellen in die Fabric integriert sind;
-
1c ist eine schematische Darstellung, die Paketflüsse veranschaulicht, welche einer von einer CPU ausgehenden Transaktion entsprechen, die an eine Fabric-Steuereinheit zur Unterstützung bei der Abwicklung der Transaktion umgeleitet wird;
-
2 ist eine Kombination aus einem Ablaufschaubild und einer schematischen Darstellung, die von der EPC-, der EMP- und der EPR-Einheit eines Endpunkts durchgeführte Vorgänge veranschaulicht;
-
3 ist ein Ablaufschaubild, das Vorgänge, die durchgeführt werden, um die Laufzeitrekonfiguration einer Fabric unter Verwendung der Architektur der 1 und 1b zu ermöglichen, gemäß einer Ausführungsform veranschaulicht; und
-
4 ist eine schematische Darstellung einer beispielhaften Computergerätarchitektur, die ein SoC nutzt, das konfiguriert ist, um die Laufzeitrekonfiguration zu unterstützen.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Hierin werden Ausführungsformen von Verfahren, Vorrichtungen und Systemen zum Implementieren einer Laufzeit-Fabric-Rekonfiguration beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein eingehendes Verständnis von Ausführungsformen der Erfindung zu vermitteln. Der Fachmann auf dem einschlägigen Gebiet erkennt jedoch, dass die Erfindung auch ohne eines oder mehrere der spezifischen Details oder mit noch anderen Verfahren, Komponenten, Materialien etc. praktisch umgesetzt werden kann. In anderen Fällen werden wohl bekannte Strukturen, Materialien oder Vorgänge nicht gezeigt oder ausführlich beschrieben, um die Verständlichkeit von Aspekten der Erfindung nicht zu beeinträchtigen.
-
Bezugnahmen in dieser Patentbeschreibung auf „eine Ausführungsform” bedeuten jeweils, dass ein spezielles Merkmal, eine spezielle Struktur oder eine spezielle Eigenschaft, das bzw. die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Daher bezieht sich die an verschiedenen Stellen in dieser Patentbeschreibung vorzufindende Wortverbindung „in einer Ausführungsform” nicht zwangsläufig jeweils auf dieselbe Ausführungsform. Des Weiteren lassen sich die speziellen Merkmale, Strukturen oder Eigenschaften in einer oder mehreren Ausführungsformen in beliebiger Weise kombinieren.
-
Gemäß Aspekten der hierin beschriebenen Ausführungsformen werden Techniken zum Implementieren von SoC-Architekturen offenbart, welche die Laufzeit-Fabric-Rekonfiguration unterstützen. Mithin kann das SoC beständig und sicher auf verschiedenartige Ereignisse wie Systemzustandsänderungen, Sicherheitsereignisse, Entwicklungsfehler, Knotenausfälle etc. reagieren. Zum Beispiel ist eine Fabric-Controller-Einheit, die Kenntnis von Systemzuständen besitzt, etwa davon, welche Knoten ausgeschaltet sind, welcher Verkehrstyp auf bestimmten Knoten unterstützt wird, welche potenziellen Sicherheitsbedrohungen in der Fabric bestehen und welche Fehler in mit der Fabric verbundenen IPs vorliegen, gemäß einem Aspekt konfiguriert, um den Verkehr dynamisch an Elemente in der Fabric wie Sicherheitsengines und Mikrocontroller, die den Verkehr richtig verarbeiten können, umzuleiten, statt zu veranlassen, dass die Pakete verworfen werden, oder es zu Systemabstürzen oder BSoD-Ereignissen kommen zu lassen.
-
Beispielhaft und ohne Einschränkung zeigt 1 eine Architektur 100, die eine Fabric 102 enthält, an die mehrere Komponenten an jeweiligen Fabric-Ports 104 gekoppelt sind. Zu den Komponenten gehören eine Energieverwaltungsengine 106, eine Sicherheitsengine 108, eine Fabric Control Unit (FCU) 110 und eine Vielzahl von IP-Blöcken 112. Der Zweckmäßigkeit und der Einfachheit halber wird auf einen IP-Block in den Zeichnungsfiguren hierin möglicherweise auch anhand seiner IP-Blocknummer Bezug genommen, z. B. mit IP-Block 1, IP-Block 2 etc. Die Architektur 100 enthält auch eine zweite Fabric 114, an die eine CPU 116 und ein Speicherbaustein 117 gekoppelt sind und die auch kommunikativ über eine Fabric-Fabric-Brücke 118 und einen Agent-Port 120 an die Fabric 102 gekoppelt ist.
-
Wie zur Ecke oben rechts in 1 hin detaillierter gezeigt, enthalten sowohl die Fabric-Fabric-Brücke 118 als auch die IP-Blöcke 112 eine Endpunkt-Fabric-Schnittstelle 122 (mit den Bezugszeichen 122-0, 122-1, 122-2 ... 122-N für die Brücke 118 bzw. die IP-Blöcke 1, 2, ... N), die konfiguriert ist, um als Schnittstelle zur Fabric 102 über einen entsprechenden Fabric-Port 104 zu fungieren. Zum Beispiel enthält eine Endpunkt-Fabric-Schnittstelle Eingangs- und Ausgangswarteschlangen zum Puffer von ausgehenden und eingehenden Paketdaten sowie eine assoziierte Logik zum Ermöglichen von Fabric-Schnittstellenvorgängen. Diese herkömmlichen Aspekte von Fabric-Schnittstellen sind dem Fachmann bekannt, und demzufolge werden hierin keine weiteren Details dieser Aspekte erörtert.
-
Zusätzlich zu den herkömmlichen Aspekten enthält jede Endpunkt-Fabric-Schnittstelle 122 weiter eine Endpoint-Classifier(EPC)-Einheit 124, eine Endpoint-Measurement(EPM)-Einheit 126 und eine Endpoint-Routing(EPR)-Einheit 128. Diese Komponenten erweitern die herkömmliche Fabric-Schnittstellenfunktionalität so, dass die Laufzeit-Fabric-Rekonfiguration und die Bearbeitung von Paketen unter Berücksichtigung verschiedener Kriterien unterstützt werden, wie unten ausführlich beschrieben.
-
Wie in 1 weiter gezeigt, ist die FCU 110 über eine Seitenbandkanalverbindung 134-0 134-N kommunikativ an jede der Endpunkt-Fabric-Schnittstellen 122-0 ... 122-N gekoppelt. Die FCU 110 ist auch über jeweilige Verbindungen 136 und 138 kommunikativ sowohl an die Energieverwaltungsengine 106 als auch an die Sicherheitsengine 108 gekoppelt. Optional wird die Kommunikation zwischen der FCU 110 und einer oder mehreren der Endpunkt-Fabric-Schnittstellen, der Sicherheitsengine oder der Energieverwaltungsengine über Nachrichten implementiert, die über die Fabric 102 gesendet werden.
-
Weiter unter Bezug auf 1a und 2 arbeiten die Energieverwaltungsengine 106, die Sicherheitsengine 108, die Fabric Control Unit (FCU) 110 und die IP-Blöcke 112 jeweils als Endpunkt 202, der an einen jeweiligen Knoten 200 in einem Network-on-Chip gekoppelt ist, das eine Fabric 102 als Switch-Fabric nutzt, die ein Routing von Daten zwischen Endpunkten 202 ermöglicht. Es versteht sich, dass die Knoten 200 keine getrennten Komponenten, sondern vielmehr logische Darstellungen von Endpunkten aus dem Blickwinkel von für Computernetze gemeinhin verwendeter Terminologie sind, wobei eine Vielzahl von Knoten als Kabel- oder Funknetz kommunikativ zusammengekoppelt ist. Zusätzlich sind alle Endpunkt-Fabric-Schnittstellen 122-0 ... 122-N in 1a direkt an ihre assoziierten Brücken oder IP-Blöcke gekoppelt oder darin integriert. Demzufolge wird eine Endpunkt-Fabric-Schnittstelle hierin möglicherweise auch einfach als „Endpunkt” bezeichnet. In manchen Ausführungsformen nutzt die Fabric 102 ein Mehrschichtenprotokoll, das dem von einem Computernetz wie einem LAN genutzten ähnlich ist, und es werden Daten mittels eines Modells für paketbasierte Datentransaktionen zwischen Endpunkten übertragen. Um das Routing der Pakete zu ermöglichen, führt die FCU 110 in einer Ausführungsform eine Routingtabelle 130, die verschiedene Routing- und Weiterleitungspfade, Routingregeln etc. enthält, um das Routing zwischen den Knoten 200 zu ermöglichen. Indessen enthalten die Fabric-Ports 104 und der Agent-Port 120 je eine lokale Routingtabelle 132, welche das Paketrouting/die Weiterleitung von Daten und Regeln, die für diesen speziellen Port gelten, definiert. In manchen Ausführungsformen tauschen die FCU 110, die Fabric-Ports 104 und der Agent-Port 120 (und optional andere SoC-Komponenten) während Initialisierungsvorgängen Nachrichten aus, die Konfigurationsdaten zum Inhalt haben, sodass die FCU 110 Netztopologie-Informationen sammeln kann, um eine globale Netzübersicht für das System zu erstellen, in anderen Ausführungsformen ist die globale Netzübersicht des Systems möglicherweise vorkonfiguriert. Die FCU 110 generiert basierend auf der globalen Netzübersicht lokale Routingtabellendaten für jeden Fabric-Port 104 und jeden Agent-Port 120 und überträgt die lokalen Routingdaten über die Fabric 102 an die Fabric-Ports und den Agent-Port.
-
Bei der herkömmlichen Switch-Fabric-Verwendung würden die Endpunkte, die den verschiedenen Netzknoten entsprechen, paketbasierte Daten generieren, um Datentransaktionen mit anvisierten Zielendpunkten im Netz zu ermöglichen. Ausgehende Datenpakete (d. h. Datenpakete, die von einem Endpunkt ausgesendet werden) werden in die Warteschlange der Fabric-Schnittstelle eines Endpunkts aufgenommen und danach in den Fabric-Port 104 eingegeben, an den die Fabric-Schnittstelle gekoppelt ist. Jedes Paket hat einen Kopf, der Daten enthält, die eine Netzadresse des Zielendpunkts identifizieren. Der Fabric-Port 104 führt basierend auf dieser Zieladresse (und gegebenenfalls anderen Kopfinformationen) eine Suche in seiner lokalen Routingtabelle 132 durch, um zu bestimmen, über welchen anderen Fabric-Port oder Agent-Port das Paket geroutet werden muss, damit die Fabric den der Zieladresse entsprechenden Endpunkt erreichen kann (die Routingtabelle definiert z. B. den nächsten Hop zum Routen des Pakets). Die Kombination aus den Fabric-Ports 104, dem Agent-Port 120 und der Verdrahtung und der Logik in der Fabric 102 ermöglicht einen Paketvermittlungsvorgang ähnlich wie bei einem Netzswitch oder -router, bei dem die Paketdaten intern zwischen betreffenden Fabric-/Agent-Ports geroutet werden. Demnach kann die Fabric 102 auch als Switch-Fabric bezeichnet werden. Sobald die Paketdaten, die an einen gegebenen Fabric-Port oder Agent-Port vermittelt werden, empfangen sind, werden sie gepuffert und danach an die Fabric-Schnittstelle des Zielendpunkts weitergeleitet.
-
Gemäß Aspekten der Ausführungsformen der 1 und 2 wird die herkömmliche Switch-Verwendung insofern weiterentwickelt, als eine Laufzeit-Fabric-Rekonfiguration und eine Umleitung von Datenpaketen als Reaktion auf bestimmte Ereignisse wie Sicherheitsereignisse, Knotenausfälle und andere detektierte Fehler unterstützt werden. Unter Bezugnahme auf 2 wird diese erweiterte Funktionalität unterstützt, teilweise über Vorgänge, die von der EPC 124, der EPM 126 und der EPR 128 in den Endpunkt-Fabric-Schnittstellen 122-0 ... 122-N durchgeführt werden, wie durch die Vorgangsblöcke 204, 206 und 208 abgebildet.
-
Der Block 204 bildet Vorgänge ab, die von einer Endpoint-Classifier-Einheit 124 durchgeführt werden. Die Endpoint-Classifier-Einheit parst eingehende Daten vom Knoten (d. h. vom assoziierten Endpunkt des Knotens) und gibt Paketeigenschaften wie die Größe, den Typ, die Sicherheitsstufe und die Zieladresse an die Endpoint-Measurement-Einheit 126 und die Endpoint-Routing-Einheit 128 aus.
-
Gemäß Vorgängen, die in Block 206 abgebildet sind, misst eine Endpoint-Measurement-Einheit 126 Vorkommnisse von bestimmten Ereignissen und Paketeigenschaften in eingehendem Verkehr und ausgehendem Verkehr. Allgemein können Typen von Paketeigenschaften, die gemessen werden müssen, und Ereignisse, die infolge dieser Messungen generiert werden können, durch die FCU 110 programmiert oder bei der Initialisierung aus dem Speicherbaustein geladen werden. Diese Informationen können als statistische Informationen für die Fabric-Verwaltung verwendet werden, die durch die FCU 110 gelesen werden können, welche von der EPR-Einheit 128 verwendet werden, um Fabric-Ereignisse (z. B. Interrupts für die FCU oder eine andere Einheit) zu generieren, oder als Eingabe für eine Routingentscheidung (z. B. verdächtiger Verkehr, der an einen Sicherheitscontroller weitergeleitet werden soll) verwendet werden.
-
Wie in Block 208 gezeigt, wird eine EPR-Einheit 128 zum Routen von Paketen genutzt. Um dies zu ermöglichen, enthält die EPR-Einheit 128 in einer Ausführungsform Routingtabellen und Routingregeln 210, die basierend auf anwendbaren Kriterien Ausnahmen zum (ursprünglichen) Ziel jedes Pakets definieren, das in die Fabric 102 von dem Knoten her eintritt, zu dem der Endpunkt gehört. Allgemein können die EPR-Routingtabellen und -regeln durch die FCU 110 programmiert oder während der Initialisierung aus dem Speicherbaustein geladen werden und können während der Laufzeit basierend auf Änderungen des Systemzustands aktualisiert werden, wie unten beschrieben. Wie hierin verwendet, umfasst die Kombination aus Routingtabellen- und/oder Routingregeldaten und Logik zum Implementieren der Routingtabelle und der Routingregeln eine Routinglogik. Demzufolge umfassen Änderungen der Routingtabelle und/oder der Routingregeln eine Änderung der Routinglogik.
-
Während Laufzeitvorgängen lassen sich Änderungen von Energiezuständen verschiedener Komponenten implementieren, etwa indem ein IP-Block in einen Zustand mit geringem Energieverbrauch oder in den Standby-Zustand versetzt wird. In einer Ausführungsform wird dies, zumindest teilweise, durch die Energieverwaltungsengine 106 ermöglicht. Beim Ändern des Energiezustands einer Komponente werden entsprechende Daten in Form einer Konfigurationsaktualisierung für die FCU 110 bereitgestellt. Abhängig von der Implementierung können Konfigurationsaktualisierungen von einer Energieverwaltungsengine oder einer ähnlichen Komponente als Reaktion auf Energiezustandsänderungen von Komponenten erzeugt werden, oder optional kann eine FCU eine Energieverwaltungsengine hinsichtlich Energiezustandsänderungen periodisch abfragen. Die FCU 110 führt basierend auf den Energiezustandskonfigurationsaktualisierungen eine lokale Übersicht über den Energiezustand jeder Komponente, die möglicherweise eine Schnittstelle zur Fabric 102 hat, einschließlich der IP-Blöcke 112.
-
In manchen Ausführungsformen empfängt die FCU 110 möglicherweise auch Laufzeitaktualisierungen von der Sicherheitsengine 108. Zum Beispiel detektiert die Sicherheitsengine möglicherweise ein Sicherheitsproblem basierend auf Informationen, die sie von anderen Systemkomponenten erhält oder von diesen erfasst, sowie basierend auf Informationen, die von der FCU 110 an die Sicherheitsengine 108 weitergeleitet werden, etwa Informationen, die durch eine EPM-Einheit 126 generiert werden.
-
In Anbetracht von Änderungen der Energiezustände verschiedener Komponenten und Laufzeitaktualisierungen von der Sicherheitsengine 108 sendet die FCU 110 Laufzeitaktualisierungen der EPR-Routingtabelle und der EPR-Routingregeln für die Endpunkt-Fabric-Schnittstellen 122-0 ... 122-N über jeweilige Seitenbandkanalverbindungen 134-0 ... 134-N. Zusätzlich sendet die FCU 110 aktualisierte Konfigurationsinformationen an die EPM-Einheiten 126.
-
Bei der Initialisierung oder nach Systemzustandsänderungen konfiguriert die FCU 110 die EPM-Einheit 126 und die EPR-Einheiten 128 von allen an die Fabric 102 gekoppelten Endpunkten. Dadurch wird definiert, welche langsamen Pfadzugriffe an die FCU 110, die Sicherheitsengine 108, die Energieverwaltungsengine 106 oder andere Engines geroutet werden und welche für den Endpunkt direkt an den IP-Block gesendet werden. Zu Systemzustandsänderungen zählen zum Beispiel möglicherweise die Ausschaltung eines IP, die Detektion eines Sicherheitsereignisses, das Erfordernis der Unterstützung eines anderen Betriebssystems, der Ausfall eines Knotens etc. Die EPR-Einheiten 128 leiten in die Fabric 102 eintretenden Verkehr gemäß EPR-Routingtabellen und -Routingregeln 210 um; falls die Umleitung für ein Paket nicht anwendbar ist, wird das Paket auf normale Weise über die Fabric geroutet. Die FCU 110 oder ein anderer Knoten (die Sicherheitsengine 108, die Energieverwaltungsengine 106 etc.) reagiert auf Zugriffe, die an sie bzw. ihn geroutet werden. Eine Reaktion geht zum Beispiel eventuell einher mit dem Antworten auf einen Zugriff und nicht auf einen ausgeschalteten IP, der Aktivierung eines IP, der Weiterleitung des Zugriffs (entweder modifiziert oder nicht), dem Verwerfen des Zugriffs, dem Laden des Kontextes eines IP vor der Ausschaltung, dem Emulieren eines IP, der nicht vorhanden ist, etc.
-
3 zeigt ein Ablaufschaubild, das vom System der Architektur 100 während der Initialisierung und Laufzeitvorgängen durchgeführte Vorgänge und Logik gemäß einer Ausführungsform veranschaulicht. In einem Block 300 werden die Endpunkte initialisiert. Beim Starten werden EPR-Routingtabellen und -Routingregeln 210 für alle Endpunkte in der Fabric 102 geladen. Allgemein können diese Informationen von der FCU 110 über eine Seitenbandkanalverbindung 134 empfangen oder aus dem Speicherbaustein 117 heruntergeladen werden. Zusätzlich werden Verkehrseigenschaften aus Messungen der EPM-Einheit 126 und Ereignisangabegenerierungsregeln in betreffende Endpunkte in der Fabric 102 geladen. Wie zuvor können diese Informationen von der FCU 110 empfangen oder aus dem Speicherbaustein 117 heruntergeladen werden.
-
Nach der Initialisierung der Endpunkte werden fortdauernd Laufzeitvorgänge durchgeführt, wie durch die übrigen Blöcke und die übrige Logik in 3 veranschaulicht, was dem Vorgang eines gegebenen Endpunkts entspricht. Während Laufzeitvorgängen werden verschiedene ausgehende Datenpakete von einem Endpunkt aus gesendet und eingehende Datenpakete an einem Endpunkt empfangen. Wie durch einen Entscheidungsblock 302 abgebildet, fließt die Logik als Reaktion auf die Detektion eines ausgehenden Pakets zu einem Block 304, in dem Routingdaten in EPR-Routingtabellen und -regeln 210 genutzt werden, um das Paket zu routen (umzuleiten). Wie oben erörtert, wird ein Paket auf die für es normale Weise (z. B. an seinen ursprünglichen Zielendpunkt) geroutet, falls kein Routingtabelleneintrag oder keine Routingregel anwendbar ist. Falls hingegen ein Routingtabelleneintrag oder eine Routingregel anwendbar ist, wird das Paket gemäß dem Tabelleneintrag oder der Regel umgeleitet. Die Logik fließt dann zu einem Block 306, wo die statistischen EPM-Zähler aktualisiert werden. Falls das Paket unter erneuter Bezugnahme auf den Entscheidungsblock 302 einem eingehenden Paket entspricht, fließt die Logik direkt zum Block 306, um die statistischen EPM-Zähler zu aktualisieren.
-
Während der fortdauernden Vorgänge können Systemzustandsänderungen als Reaktion auf verschiedene Ereignisse detektiert werden, etwa die Ausschaltung eines Knotens, die Detektion eines Sicherheitsereignisses, wenn spezifischer Dateninhalt gesendet oder empfangen wird etc., wie durch einen Entscheidungsblock 308 abgebildet. Als Reaktion auf die Detektion einer Systemzustandsänderung fließt die Logik zu einem Block 310, in dem die Fabric rekonfiguriert wird. Während der Rekonfiguration der Fabric werden Routingtabellen und Routingregeln in EPR-Einheiten der relevanten Endpunkte rekonfiguriert, um auf die Systemzustandsänderung einzugehen. In einer Ausführungsform wird möglicherweise ein Doppelpufferschema verwendet, um Änderungen von Routingregeln oder -tabellen zu vermeiden, während ein Paket in einer EPR-Einheit geroutet wird. Mehrere Routingtabellen können in Situationen verwendet werden, in denen die Fabric erwartungsgemäß rasch und wiederholt zwischen unterschiedlichen Modi zu rekonfigurieren ist (zum Beispiel in Fällen, in denen mehrere Betriebssysteme zeitgleich ausgeführt werden).
-
Zusätzlich dazu, dass Endpunkt-Fabric-Schnittstellen 122 in assoziierte Komponenten wie IP-Blöcke und -Brücken integriert werden, lassen sich Endpunkt-Fabric-Schnittstellen auch in der Fabric implementieren. 1b zeigt zum Beispiel eine Architektur 100a, die der Architektur 100 ähnelt, außer dass in diesem Fall die Endpunkt-Fabric-Schnittstellen 122a in Fabric-Ports 104a und einen Agent-Port 120a einer Fabric 102a integriert sind. Die allgemeine Funktionsweise der Architekturen 100 und 100a ist ähnlich, wobei die Hauptunterschiede die Stellen der Endpunkt-Fabric-Schnittstellen sind. Ein Unterschied besteht darin, dass die lokale Routingtabelle und die EPR-Routingtabelle und die EPR-Routingregeln in der veranschaulichten Ausführungsform von 1a kombiniert werden können, wie durch einen Block 132a abgebildet. Wenn zusätzlich die Endpunkt-Fabric-Schnittstellen in die Fabric integriert werden, können Konfigurationsinformationen durch die Fabric selbst übertragen werden, ohne dass getrennte Seitenbandkanäle genutzt werden. Optional lassen sich Seitenbandkanäle in der Fabric-Konfiguration der Architektur 100b (nicht gezeigt) implementieren.
-
Die hierin offenbarten Prinzipien und Lehren lassen sich in Systemen, SoCs und NoCs und anderen integrierten Geräten implementieren, um eine Laufzeit-Fabric-Rekonfiguration als Systemzustandsfunktion zu ermöglichen. Zum Beispiel lässt sich eine Fabric über eine Fabric-Controller-Einheit rekonfigurieren, die Kenntnis von Systemzuständen besitzt, etwa davon, welche Knoten ausgeschaltet sind, welcher Verkehrstyp auf bestimmten Knoten unterstützt wird, welche potenziellen Sicherheitsbedrohungen in der Fabric bestehen und welche Fehler in mit der Fabric verbundenen IPs vorliegen, um den Verkehr dynamisch an Elemente in der Fabric wie Sicherheitsengines und Mikrocontroller, die den Verkehr richtig verarbeiten können, umzuleiten. Die folgenden, nicht ausschließlichen Beispiele veranschaulichen beispielhafte Anwendungsfälle für solche Implementierungen.
-
In einem ersten beispielhaften Anwendungsfall ist Verkehr bestimmt für Knoten in der Fabric, die ausgeschaltet sind, wobei der Verkehr an einen Fabric-Mikrocontroller weitergeleitet wird, der als Proxy für den ausgeschalteten Knoten genutzt wird und den gesamten erforderlichen IP-Kontext beinhaltet. Der Controller entscheidet, dass entweder der Knoten eingeschaltet oder die Transaktion autonom durchgeführt wird. Mittels dieses Schemas können die verschiedenen IPs im Ruhezustand ganz ausgeschaltet werden, wenn nur ein geringer Anteil der aktiven Schaltung übrig ist, um eine IP-Einschaltung bei Bedarf möglich zu machen. Dies begünstigt ein systematisches Energieverwaltungsschema für alle IPs, das zu einer verbesserten Einsparung von SoC-Blindleistung verhelfen kann.
-
Mit Bezug auf 1c wird eine Implementierung des vorstehenden Anwendungsfalls anhand der Architektur 100 veranschaulicht. Bei diesem Beispiel ist ein Paket, das einer Transaktion entspricht, die von der CPU 116 ausgeht, ursprünglich für einen IP-Block 5 bestimmt, der von der Energieverwaltungsengine 106 in einen Zustand mit reduziertem Energieverbrauch versetzt wurde. Als Reaktion darauf, dass der IP-Block 5 in den Zustand mit reduziertem Energieverbrauch versetzt wurde, liefert die Energieverwaltungsengine eine entsprechende Energiezustandskonfigurationsaktualisierung an die FCU 110. Daraufhin sendet die FCU 110 eine Aktualisierung an die EPR-Einheit der mit der Fabric-Fabric-Brücke 118 assoziierten Endpunkt-Fabric-Schnittstelle 122-0, um die EPR-Routingtabelle und die EPR-Routingregeln so zu aktualisieren, dass für den IP-Block 5 bestimmte Pakete an die FCU 110 umgeleitet werden. Diese Umleitung wird in 1c durch den Pfad 1 gezeigt (der durch eine eingekreiste ‚1' abgebildet ist).
-
Nach dem Empfangen des Pakets kann die FCU 110 abhängig von der betreffenden Situation dafür konfiguriert sein, um es auf verschiedene Weisen zu bearbeiten. Zum Beispiel kann die FCU 110 dafür konfiguriert sein, um bestimmte Transaktionen als Proxy für den IP-Block 5 autonom zu bearbeiten, wobei eine Transaktionsabschlussreaktion über den Pfad 2 an die CPU 116 zurückgesendet wird. In anderen Situationen gibt die Logik zur Bearbeitung der Transaktion möglicherweise vor, dass sie vom IP-Block 5 abzuwickeln ist. In diesem Szenario sendet die FCU 110 nach dem Empfangen des Pakets eine Aufforderung zur Einschaltung des IP-Blocks 5 an die Energieverwaltungsengine 106. Nach dem Empfang der Bestätigung von der Energieverwaltungsengine 106, dass der IP-Block 5 eingeschaltet ist (und daher für die Bearbeitung der Transaktion verfügbar ist), wird das Paket von der FCU 110 über einen Pfad 3 an den IP-Block 5 weitergeleitet, um die Transaktion zu bearbeiten. Der IP-Block 5 kann dann etwaige anwendbare Transaktionsdaten oder Abschlussdaten an die CPU 116 entweder direkt über einen Pfad 4 oder über die FCU 110 über die Pfade 3 und 2 zurücksenden.
-
In einem anderen Anwendungsfall lässt sich Verkehr, der verdächtig ist oder Sicherheitsregeln verletzt, weiterleiten an eine zuständige Sicherheitsengine/einen zuständigen Controller, statt einfach verworfen zu werden und gegebenenfalls ein BSoD-Ereignis auszulösen. Mittels anwendbarer Filter/Regeln in den EPR-Regeln und -Routingtabellen lässt sich solcher Verkehr identifizieren und für eine angemessene Bearbeitung umleiten. Zum Beispiel könnte Verkehr, der als Sicherheits- oder Stabilitätsrisiko identifiziert wird, an ein Sicherheitsmodul wie die Sicherheitsengine 108 umgeleitet werden.
-
In manchen Fällen können vorher entwickelte IPs (z. B. aus einer IP-Bibliothek oder dergleichen), die bestimmte Typen von Nachrichten oder anderen Transaktionen nicht unterstützen, welche in der Fabric unterstützt werden müssen, in einem SoC implementiert werden. Solcher Verkehr kann an einen Fabric-Mikrocontroller weitergeleitet werden, der die für die Nachricht erforderliche Funktionalität implementieren wird, sodass sich das Vornehmen von Hardware-Änderungen für solche IPs erübrigt. Auch werden Entwicklungsfehler möglicherweise nach dem Hinzukommen von Silicium detektiert, bei der es möglich sein könnte, die Fabric zu rekonfigurieren, um bestimmte Transaktionen an den Fabric-Controller zu routen und das Problem zu mindern.
-
Bei manchen Entwürfen nutzen SoCs redundante IP-Blöcke oder enthalten ansonsten IP-Blöcke, die genutzt werden sollen, wenn andere IP-Blöcke ausgeschaltet werden oder ausgefallen sind. Demzufolge kann auf Ausfälle von Knoten in der Fabric, die Redundanz aufweisen, eingegangen werden, indem ein Ausfall detektiert und die Fabric derart rekonfiguriert wird, dass für einen ausgefallenen Knoten bestimmter Verkehr an einen entsprechenden redundanten Knoten geroutet wird.
-
Ein anderer Anwendungsfall betrifft das Prototyping und die Entwicklung von Merkmalen. In diesem Szenario beruhen frühe Implementierungen darauf, dass der Fabric-Controller die erwartete Schnittstelle für die Software bereitstellt, doch dies kann nahtlos an den IP übertragen werden, da der IP auf der Silicium-/Firmware-Ebene reift.
-
Die Laufzeit-Fabric-Rekonfiguration kann auch verwendet werden, um Virtualisierungsimplementierungen zu verbessern. Eine Virtualisierung lässt sich zum Beispiel verbessern mittels einer Erzeugung von Semaphoren zwischen einem in Echtzeit gemeinsam verwendeten IP, strukturierten Zurücksetzungen und/oder Verbergen von Zurücksetzungs-/Rekonfigurationsverzögerungen, wenn ein IP von einem Besitzer an einen anderen übertragen wird.
-
Zusätzliche Vorzüge können durch die Verwendung der hierin offenbarten Laufzeit-Fabric-Rekonfigurationstechniken bereitgestellt werden. Zum Beispiel können die Techniken verwendet werden, um zu einer verbesserten systematischen Energieverwaltung und/oder Sicherheit auf der Chipebene zu verhelfen. Die Techniken vereinfachen möglicherweise auch die Integration der IPs von Dritten in derzeitige und künftige SoC-Entwürfe für einen gegebenen Hersteller, indem Firmware-Unterstützung von eindeutigen herstellerspezifischen Fabric-Nachrichten und Fabric-Fähigkeiten möglich gemacht wird.
-
Die Techniken können potenziell die Chancen erhöhen, funktionsfähiges A0-SoC-Silicium über ein systematisches Vorgehen zum Implementieren von Post-Silicon-Firmwarepatches zu erhalten, um auf Hardwarefehler einzugehen und somit die Notwendigkeit einer weiteren Chipkorrektur (d. h. Design/Build Iteration) zu umgehen. Die Techniken bewirken möglicherweise auch eine verkürzte Fertigstellungszeit von SoC-Software über ein systematisches Vorgehen zum Implementieren von Post-Silicon-Firmwarepatches, um auf Software-Abwärtskompatibilitätsprobleme einzugehen. Dadurch können sich auch die Chancen erhöhen, dass ein aufwärtskompatibler Treiber entwickelt werden kann, der noch bevor Silicium letztlich hinzukommt an Erstausrüster geliefert werden kann, wobei Hardware-Inkompatibilitäten mit der Software durch Implementieren von Firmwarenachbesserungen behoben werden können.
-
Die Techniken lassen sich auch vorteilhaft verwenden, um Tablet-Merkmale der nächsten Generation wie den Betrieb von mehreren Betriebssystemen in sicherer und beständiger Weise möglich zu machen. Indem Unterstützung zur Behandlung von Sicherheitsproblemen und Hardwarefehlern und/oder einer Nichtverfügbarkeit auf der Hardwareebene implementiert wird, kann auf solche Probleme in einer Weise eingegangen werden, die nicht zu Betriebssystemabstürzen führt oder keine Sicherheitsrisiken auf der Betriebssystemebene nach sich zieht.
-
Es wird angestrebt, dass Aspekte der Ausführungsformen, die hierin offenbart werden, in verschiedenartigen Computergeräten implementiert werden können, unter anderem in mobilen Geräten wie Smartphones und Tablets, Notebook-, Laptop- und Ultrabook-Computern, Desktop-Computer und Servern. Gemäß manchen Ausführungsformen kann die Laufzeit-Fabric-Rekonfiguration in SoCs implementiert werden, die in diesen Computergeräten genutzt werden. Die Laufzeit-Fabric-Rekonfiguration kann nicht nur in SoCs, sondern auch in anderen integrierten Geräten implementiert werden.
-
4 bildet zur Veranschaulichung ausgewählte Komponenten für ein beispielhaftes Computergerät 400 ab, das die Laufzeit-Fabric-Rekonfiguration unterstützt. Das Computergerät 400 enthält ein SoC 402, das an einer innerhalb eines Rahmens 406 untergebrachten Hauptplatine 404 montiert oder ansonst betriebsfähig an sie gekoppelt ist. Das SoC 402 enthält einen CPU-Teilabschnitt 408, der einen oder mehrere Prozessorkerne 410 mit jeweiligen L2-Caches 412 enthält, die an eine Speicher-Fabric 414 gekoppelt sind. Die Speicher-Fabric 414, die manchmal möglicherweise auch als kohärente Fabric bezeichnet wird (die z. B. konfiguriert ist, um kohärente Speichercachevorgänge zu unterstützen), ist über eine Fabric-Fabric-Brücke 418 mit einer Switch-Fabric 416 verbunden. Auch mit der Switch-Fabric 416 verbunden sind eine Energieverwaltungsengine 420, eine Sicherheitsengine 422, eine FCU 424 und eine Vielzahl von IP-Blöcken, die einen universellen Asynchron-Empfänger/Sender (Universal Asynchronous Receiver/Transmitter, UART) 426, eine Allzweckeingabe/-ausgabe (General Purpose Input-Output, GPIO) 428, einen Secure-Digital-Input-Output(SDIO)-Baustein 430, eine Peripheral-Component-Interconnect-Express(PCIe)-x4-Schnittstelle 432 und einen Real-time Interrupt Controller (RTIC) 434 enthalten. Eine Double-Data-rate-RAM-Schnittstelle (DDR-SST) 436 ist auch mit der Switch-Fabric 416, der Speicher-Fabric 414 und dem Speicherbaustein 438, der auf der Hauptplatine 404 montiert ist, verbunden. Die PCIe-x4-Schnittstelle ist auch an ein auf der Hauptplatine 404 montiertes PCIe-Gerät 440 gekoppelt.
-
Zu zusätzlichen Komponenten, die für das SoC 402 veranschaulicht werden, gehören ein Taktgeber 442, ein Spannungsregler (SR) 444 und ein HF(Hochfrequenz)-Sendeempfänger 446. Der Taktgeber 442 liefert verschiedene Taktsignale an betreffende Komponenten im SoC. Ähnlich liefert der SR 444 Regelspannungen an betreffende SoC-Komponenten. Der HF-Sendeempfänger 446 ist betriebsfähig an eine Antenne 448 gekoppelt und kann allgemein konfiguriert sein, um einen oder mehrere Drahtlosstandards zu unterstützen, etwa unter anderem jegliche derzeitigen oder künftigen Funkkommunikationsstandards (UMTS, CDMA, WCDMA, LTE etc.), IEEE-802.11-basierte Standards und andere Drahtlosstandards wie WIMAX. Allgemein kann die Antenne 448 an einen Rahmen 406 gekoppelt oder darin montiert sein und kann über eine Verdrahtung in der Hauptplatine 404 (falls sie an der Hauptplatine montiert ist) betriebsfähig an den HF-Sendeempfänger 446 gekoppelt oder über ein Kabel oder eine flexible Schaltung oder dergleichen gekoppelt sein.
-
Wie der Durchschnittsfachmann erkennen würde, würde das SoC 402 verschiedene zusätzliche Komponenten enthalten, die in 4 nicht veranschaulicht werden, um die Verständlichkeit der erfinderischen Aspekte der Ausführungsform nicht zu erschweren.
-
In der veranschaulichten Ausführungsform enthält das SoC 402 eine Endpunkt-Fabric-Schnittstelle 122 pro Fabric-Fabric-Brücke 418, UART 426, GPIO 428, SDIO 430, PCIe-x4-Schnittstelle 432 und RTIC 434. Optional kann eine Endpunkt-Fabric-Schnittstelle für eine oder mehrere der FCU 424, der Energieverwaltungsengine 420 und der Sicherheitsengine 422 implementiert sein. Als weitere Option können eine oder mehrere der Endpunkt-Fabric-Schnittstellen in die Switch-Fabric 416 integriert sein oder ein oder mehrere der mit der Fabric verbundenen IPs haben möglicherweise keine Endpunkt-Fabric-Schnittstelle. Zusätzlich ist das SoC 402 möglicherweise konfiguriert, um Seitenkanalkommunikation zwischen der FCU 424 und einem oder mehreren der SoC-IP-Blöcke zu unterstützen.
-
Im Allgemeinen kann die FCU 424 als Mikrocontroller oder dergleichen implementiert sein. Ein solcher Mikrocontroller umfasst zum Beispiel möglicherweise eingebettete Logik zum Ermöglichen der Vorgänge, die für die hierin erörterten FCUs beschrieben werden, wofür verschiedenartige Mikrocontrollerarchitekturen verwendet werden, die auf dem Gebiet der Prozessortechnik wohl bekannt sind.
-
Ähnlich lässt sich eine Switch-Fabric 416 unter Verwendung einer derzeitigen oder künftigen Switch-Fabric-Architektur implementieren. Solche Switch-Fabric-Architekturen enthalten zum Beispiel unter anderem Open-Core-Protocol(OCP)-, ARM-basierte Fabrics wie Fabrics, welche die Advanced Microcontroller Bus Architecture (AMBA) (z. B. Advanced Highperformance Bus (AHB)) und Basic-Virtual-Component-Interface(BVCI)-Zwischenverbindungen nutzen. In einer Ausführungsform umfasst die Switch-Fabric 416 eine Intel-On-Chip-System-Fabric(IOSF)-Zwischenverbindung, die kürzlich von der Intel® Corporation eingeführt wurde.
-
Wenngleich manche Ausführungsformen in Bezug auf spezielle Implementierungen beschrieben wurden, sind noch andere Implementierungen gemäß manchen Ausführungsformen möglich. Zusätzlich müssen die Anordnung und/oder die Reihenfolge von Elementen oder anderen Merkmalen, die in den Zeichnungen veranschaulicht und/oder hierin beschrieben werden, nicht in der speziellen Weise angeordnet sein, die veranschaulicht und beschrieben wird. Es sind noch viele andere Anordnungen gemäß manchen Ausführungsformen möglich.
-
In jedem System, das in einer Figur gezeigt wird, können die Elemente in manchen Fällen je ein selbes Bezugszeichen oder ein anderes Bezugszeichen aufweisen, um darauf hinzuweisen, dass die dargestellten Elemente anders und/oder ähnlich sein könnten. Jedoch ist ein Element möglicherweise so flexibel, dass es unterschiedliche Implementierungen aufweisen und mit einigen oder allen der hierin gezeigten oder beschriebenen Systeme zusammenwirken kann. Die verschiedenen Elemente, die in den Figuren gezeigt werden, können gleich oder unterschiedlich sein. Welches davon als erstes Element bezeichnet und welches zweites Element genannt wird, ist willkürlich.
-
In der Beschreibung und den Ansprüchen werden möglicherweise die Begriffe „gekoppelt” und „verbunden” nebst Ableitungen davon verwendet. Es versteht sich, dass diese Begriffe keine Synonyme füreinander sein sollen. Vielmehr wird „verbunden” in speziellen Ausführungsformen möglicherweise verwendet, um anzugeben, dass zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt miteinander sind. „Gekoppelt” kann bedeuten, dass zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt sind. „Gekoppelt” kann aber auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander sind, doch trotzdem zusammenarbeiten oder miteinander interagieren.
-
Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Eine Bezugnahme in der Patentbeschreibung auf „eine Ausführungsform”, „manche Ausführungsformen” oder „andere Ausführungsformen” bedeutet, dass ein spezielles Merkmal, eine spezielle Struktur oder eine spezielle Eigenschaft, das bzw. die in Verbindung mit den Ausführungsformen beschrieben wird, mindestens in manchen Ausführungsformen, jedoch nicht zwangsläufig in allen Ausführungsformen der Erfindungen enthalten ist. Die verschiedenen Erwähnungen von „eine Ausführungsform” oder „manche Ausführungsformen” beziehen sich nicht zwangsläufig alle auf dieselben Ausführungsformen.
-
Nicht alle Komponenten, Merkmale, Strukturen, Eigenschaften etc., die hierin beschrieben und veranschaulicht werden, müssen in einer speziellen Ausführungsform oder speziellen Ausführungsformen enthalten sein. Falls in der Patentbeschreibung steht, dass Komponenten, Merkmale, Strukturen oder Eigenschaften zum Beispiel „möglicherweise” enthalten sind, enthalten sein „können” oder „könnten”, müssen diese speziellen Komponenten, Merkmale, Strukturen oder Eigenschaften nicht enthalten sein. Falls die Patentbeschreibung oder ein Anspruch Bezug auf „ein” Element nimmt, bedeutet dies nicht, dass nur ein solches Element vorhanden ist. Falls die Patentbeschreibung oder die Ansprüche Bezug auf „ein zusätzliches” Element nehmen, wird dadurch nicht ausgeschlossen, dass auch mehr als ein solches zusätzliches Element vorhanden sein kann.
-
Die obige Beschreibung von veranschaulichten Ausführungsformen der Erfindung, einschließlich der Beschreibung in der Zusammenfassung, erhebt keinen Anspruch auf Vollständigkeit oder soll die Erfindung nicht genau auf die Ausbildungen einschränken, die offenbart werden. Wenngleich hierin zu Veranschaulichungszwecken spezifische Ausführungsformen der Erfindung und Beispiele für sie beschrieben werden, sind verschiedene äquivalente Modifikationen im Schutzbereich der Erfindung möglich, wie der Fachmann auf dem einschlägigen Gebiet erkennt.
-
Diese Modifikationen können vor dem Hintergrund der obigen ausführlichen Beschreibung an der Erfindung vorgenommen werden. Die in den folgenden Ansprüchen verwendeten Begriffe sollten nicht so ausgelegt werden, dass sie die Erfindung auf die spezifischen Ausführungsformen einschränken, die in der Patentbeschreibung und den Zeichnungen offenbart werden. Vielmehr ist der Schutzbereich der Erfindung vollständig durch die folgenden Ansprüche zu bestimmen, die gemäß anerkannten Regelungen zur Anspruchsinterpretation auszulegen sind.
