DE112011105543T5

DE112011105543T5 - Verfahren zur Verbesserung des Datendurchsatzes in Open-Core-Protokoll-basierten Verbindungsnetzen unter Verwendung von dynamisch wählbaren redundanten physischen Pfaden mit gemeinsamem Link

Info

Publication number: DE112011105543T5
Application number: DE112011105543.9T
Authority: DE
Inventors: Kerry S. Lowe; Peter M. Ewert
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2011-08-22
Filing date: 2011-08-22
Publication date: 2014-04-30
Also published as: US20130268710A1; KR20140043940A; KR101687273B1; KR101762779B1; CN103748837B; US9384161B2; KR20150055084A; CN103748837A; WO2013028170A1

Abstract

Verfahren und Vorrichtung zur Erleichterung von Datendurchsatzverbesserungen in Interconnect-Fabrics, die Punkt-zu-Punkt-Links verwenden, unter Verwendung von dynamisch wählbarem Routing. Initiatoren und Ziele sind mit ersten und zweiten Fabrics operativ gekoppelt. Die ersten und zweiten Fabrics enthalten mehrere interne Punkt-zu-Punkt-Links und sind miteinander über mehrere Fabric-zu-Fabric-Links, die erste und zweite Links von der ersten Fabric zur zweiten Fabric einschließen, kommunikativ gekoppelt. Während des Betriebs wird Verkehr auf dem ersten Fabric-zu-Fabric-Link detektiert, um zu ermitteln, ob er beschäftigt ist, und in Abhängigkeit von der Feststellung werden Datentransfers von einem Initiator, der mit der ersten Fabric gekoppelt ist, die für ein Ziel vorgesehen sind, das mit der zweiten Fabric gekoppelt ist, über entweder den ersten oder den zweiten Fabric-zu-Fabric-Link wahlweise geroutet.

Description

GEBIET DER ERFINDUNG
Das Gebiet der Erfindung betrifft allgemein Computersystemschnittstellen und insbesondere, aber nicht ausschließlich, Techniken zur Verbesserung der Datendurchsatzleistung von Verbindungen auf System-on-Chips (SoC) und dergleichen.
HINTERGRUNDINFORAMTION
Computersysteme verwenden typischerweise eine oder mehrere Verbindungen (Interconnects), um die Kommunikation zwischen Systemkomponenten, wie zum Beispiel zwischen Prozessoren und Speicher, zu erleichtern. Verbindungen (Interconnects) und/oder Erweiterungsschnittstellen können auch verwendet werden, um eingebaute und zusätzliche Einrichtungen bzw. Geräte, wie zum Beispiel IO(Input/Output)(Eingabe/Ausgabe)-Einrichtungen und Erweiterungskarten und dergleichen, zu unterstützen. Für viele Jahre, nachdem der Personalcomputer eingeführt wurde, war die primäre Form von Interconnect ein paralleler Bus. Parallelbusstrukturen wurden für sowohl interne Datentransfers als auch Erweiterungsbusse, wie zum Beispiel ISA (Industry Standard Architecture), MCA (Micro Channel Architecture), EISA (Extended Industry Standard Architecture) und VESA Local Bus, verwendet. In den frühen 1990er Jahren führte Intel Corporation den PCI(Peripheral Component Interconnect)-Computerbus ein. PCI verbesserte frühere Bustechnologien, indem es nicht nur die Busgeschwindigkeit erhöhte, sondern auch eine automatische Konfiguration und transaktionsbasierte Datentransfers unter Verwendung von gemeinsamen Adress- und Datenleitungen einführte.
Im Laufe der Zeit nahmen die Computerprozessor-Taktraten in einem schnelleren Tempo als Parallelbus-Taktraten zu. Als Ergebnis wurden die Computerarbeitsbelastungen häufig durch Interconnect-Engpässe anstatt Prozessorgeschwindigkeit begrenzt. Obwohl Parallelbusse den Transfer einer großen Datenmenge (zum Beispiel 32 oder sogar 64 Bits unter PCI-X) mit jedem Zyklus unterstützen, sind deren Taktraten durch Zeitverschiebungsüberlegungen begrenzt, was zu einer praktischen Grenze für die maximale Busgeschwindigkeit führt. Zur Überwindung dieses Problems wurden serielle Hochgeschwindigkeits-Interconnects (Verbindungen) entwickelt. Beispiele für frühe serielle Verbindungen schließen Serial ATA, USB (Universal Serial Bus), FireWire und RapidIO ein.
Eine weitere serielle Standardverbindung, die allgemein verwendet wird, ist PCI Express, auch PCIe genannt, der im Jahr 2004 unter dem PCIe 1.0-Standard eingeführt wurde. PCIe wurde entwickelt, um ältere PCI- und PCI-X-Standards zu ersetzen, und bietet Legacy-Unterstützung. PCIe verwendet serielle Punkt-zu-Punkt-Links anstelle einer Architektur mit gemeinsamem parallelem Bus. Jeder Link unterstützt einen Punkt-zu-Punkt-Kommunikationskanal zwischen zwei PCIe-Ports unter Verwendung von einer oder mehreren Leitungen, wobei jede Leitung eine bidirektionale serielle Verbindung (Link) umfasst. Die Leitungen werden unter Verwendung einer Crossbar-Switch-Architektur physisch geroutet, die Kommunikation zwischen mehreren Geräten zur selben Zeit unterstützt. Als Ergebnis seiner inhärenten Vorteile hat PCIe PCI als die häufigste Verbindung in heutigen PCs ersetzt. PCIe ist ein Industriestandard, der von der PCI-SIG (Special Interest Group) verwaltet wird. Als solche sind PCIe-Pads von vielen ASIC- und Siliziumherstellern erhältlich.
Vor kurzem hat Intel die QuickPath Interconnect^® (QPI) eingeführt. QPI wurde ursprünglich als eine Punkt-zu-Punkt-Prozessorverbindung implementiert, die den Front Side Bus auf Plattformen ersetzt, die Hochleistungsprozessoren, wie zum Beispiel Intel^® Xeon^®- und Itanium^®-Prozessoren, verwenden. QPI ist skalierbar und bei Systemen mit mehreren Prozessoren, die gemeinsame Speicherresourcen verwenden, besonders vorteilhaft. QPI-Transaktionen verwenden Paket-basierte Transfers unter Verwendung einer Mehrschicht-Protokoll-Architektur. Zu ihren Merkmalen gehört die Unterstützung von kohärenter Transaktion (zum Beispiel Speicherkohärenz).
Vor kurzem wurde auch das Open Core-Protokoll eingeführt, das ein offen lizensiertes, kernzentrisches Protokoll ist, das dafür vorgesehen ist, gegenwärtige Systemebenenintegrationsanforderungen zu erfüllen. OCP definiert eine busunabhängige, konfigurierbare und skalierbare Schnittstelle für On-Chip-Subsystemkommunikationen. Die aktuelle Version der OCP-Spezifikation ist die OCP 3.0-Spezifikation (aktualisiert Vorversion OCP 2.2), die beide für Download unter ocpip.org. zur Verfügung stehen.
Andere jüngste Fortschritte schließen Mehrkernprozessoren, Multi-Funktions-SoCs und Kerne und Chips mit höherer Dichte ein. Zur gleichen Zeit werden Beiträge geleistet, um den Energieverbrauch, insbesondere für mobile Plattformen, zu verringern. Um den Vorteil, der durch diese Fortschritte gebotenen Skalierbarkeit zu nutzen, müssen die zahlreichen und manchmal kollidierenden Zwänge angegangen werden. Zum Beispiel, wenn Crossbar-Verbindungen (aka, fabrics) in einem SoC implementiert werden, steigen Latenz und Energieverbrauch als eine Funktion der Anzahl von mit dem Fabric verbundenen IP-Blöcken an. Gleichzeitig können virtuelle Punkt-zu-Punkt-Links, die durch derartige Crossbar-Verbindungen erleichtert werden, für einen erheblichen Inter-IP-Block-Kommunikationsdurchsatz sorgen. Dementsprechend wäre es vorteilhaft, skalierbare Architekturen zu implementieren, die verbesserte Durchsätze unterstützen, ohne dass der korrespondierende Energieverbrauch zunimmt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorstehenden Aspekte und viele der begleitenden Vorteile dieser Erfindung werden leichter erkennbar, da diese durch Bezugnahme auf die folgende ausführliche Beschreibung in Verbindung mit den beigefügten Zeichnungen verständlicher wird, wobei sich gleiche Bezugszahlen auf gleiche Teile in allen der zahlreichen Ansichten beziehen, sofern nicht anders angegeben ist:
1a zeigt eine SoC-Architektur, die eine Menge von Fabrics und korrespondierenden Fabric-zu-Fabric-Links enthält;
1b zeigt eine Implementierung der SoC-Architektur von 1a, ferner eine Vielzahl von gemeinsam genutzten Fabric-zu-Fabric-Links zeigend;
1c zeigt eine Implementierung der SoC-Architektur von 1a, ferner eine Vielzahl von redundanten Fabric-zu-Fabric-Links zeigend, die dynamisches Routing von Daten zwischen Fabrics unterstützen;
2 zeigt ein Blockdiagramm, das die Verwendung von Basisobjekten von dem Open Core-Protokoll veranschaulicht;
3a zeigt verschiedene unidirektionale Links in einem Paar OCP-Fabrics, und ein Paar Fabric-zu-Fabric-Links zwischen den OCP-Fabrics, und zeigt ferner Adresszuordnungen für jede der OCP-Fabrics;
3b zeigt die Fabric-Konfiguration von 3a, ferner enthaltend einen redundanten Fabric-zu-Fabric-Link zwischen den OCP-Fabrics;
3c zeigt eine Variation der Konfiguration von 3b, ferner enthaltend Auswahllogik zum dynamischen Routing von Daten von Initiatoren zu Zielen, und ferner korrespondierende Modifikationen an den Fabric-Adresszuordnungen zeigend;
4 ist ein Diagramm, das Details einer Implementierung der Auswähler (Selektoren) von 3c, gemäß einer Ausführungsform veranschaulicht; und
5 ist ein Blockdiagramm eines beispielhaften SoC, bei dem eine Bridge-Hierarchie in einem South-Komplex implementiert ist.
AUSFÜHRLICHE BESCHREIBUNG
Hierin werden Ausführungsformen von Verfahren und Vorrichtungen zur Erleichterung von Datendurchsatzverbesserungen in Verbindungs(Interconnect)-Fabrics unter Verwendung von dynamisch wählbaren redundanten gemeinsam genutzten Verbindungen beschrieben. In der folgenden Beschreibung werden zahlreiche spezielle Details, wie zum Beispiel Implementierungen, die OCP-Verbindungen verwenden, dargelegt, um für ein gründliches Verständnis von Ausführungsformen der Erfindung zu sorgen. Ein Fachmann auf dem Gebiet wird jedoch erkennen, dass die Erfindung ohne eines oder mehrerer der speziellen Details oder mit anderen Verfahren, Komponenten, Materialien etc. ausgeführt werden kann. In anderen Fällen werden allgemein bekannte Strukturen, Materialien oder Operationen nicht im Detail gezeigt oder beschrieben, um ein Verschleiern von Aspekten der Erfindung zu vermeiden.
Die Bezugnahme in der gesamten Beschreibung auf „eine (1) Ausführungsform” oder „eine Ausführungsform” bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Charakteristik, das/die in Verbindung mit der Ausführungsform beschrieben ist, in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit bezieht sich das Auftreten der Phrase „in einer (1) Ausführungsform” oder „in einer Ausführungsform” an verschiedenen Stellen in der gesamten Beschreibung nicht notwendigerweise immer auf dieselbe Ausführungsform. Weiterhin können die bestimmten Merkmale, Strukturen oder Charakteristiken in jeder geeigneten Weise in einer oder mehreren Ausführungsformen kombiniert werden.
Der Klarheit halber können einzelne Komponenten in den Figuren hierin auch durch deren Bezeichnungen bzw. Kennzeichnungen anstelle durch deren bestimmte Bezugszahl bezeichnet sein. Zum Beispiel stellt die Kennzeichnung der Knoten oder Blöcke in verschiedenen Figuren Information zur Identifizierung des Knotens/Blocks und/oder seiner Funktion bereit; solche Information kann nicht allein mit separaten Bezugszahlen vermittelt werden. Zusätzlich können Bezugszahlen, die sich auf einen bestimmten Typ von Komponente (im Gegensatz zu einer speziellen Komponente) beziehen, mit einer Bezugszahl, gefolgt von „(typ)”, „typisch” bedeutend, dargestellt werden. Es versteht sich, dass die Konfiguration dieser Komponenten typischerweise aus ähnlichen Komponenten sein wird, die existieren, aber der Einfachheit und Klarheit halber in den Zeichnungen nicht gezeigt sind.
Wie oben diskutiert, bewegen sich Computerarchitekturen von Architekturen mit diskreten Komponenten in Richtung zu SoC-basierten Architekturen. Modularität ist auch ein wichtiger Aspekt von SoC-Architekturen. Typischerweise wird der Systemdesigner zahlreiche Funktionsblöcke integrieren, einschließlich Funktionsblöcken, die üblicherweise in der Industrie als Intellectual Property(IP)-Kerne, IP-Blöcke oder einfach IP bezeichnet werden. Für die Zwecke hierin werden diese Funktionsblöcke allgemein als IP-Blöcke oder einfach „IP” bezeichnet; es versteht sich, dass die Terminologie IP-Blöcke oder IP auch IP-Kerne und jede andere Komponente oder jeden anderen Block, allgemein als IP bekannt, abdeckt, wie dies für Leute in der SoC-Entwicklungs- und Fertigungsindustrie verständlich wäre. Diese IP-Blöcke dienen allgemein einer oder mehreren dedizierten Funktionen und umfassen oft bestehende Schaltungsdesign-Blöcke, die von zahlreichen Anbietern lizenziert oder im eigenen Haus entwickelt sind. Zur Integration dieser IP-Blöcke sind zahlreiche Schnittstellen in dem SoC gestaltet.
1a zeigt eine beispielhafte SoC-Architektur 100, die mehrere Verbindungs-Fabrics (Interconnect Fabrics) 102 verwendet, die in einer hierarchischen Art konfiguriert sind. Der Ausdruck „hierarchisch” bedeutet, dass das Verbindungsnetzwerk eine verbundene Gruppe von Teilnetzwerken umfasst, die üblicherweise als Verbindungs-Fabrics oder einfach Fabrics bezeichnet werden. Zur Vereinfachung werden die Fabrics hierin allgemein durch deren Kennzeichnungen (zum Beispiel Fabric 1, Fabric 2 etc.) statt einer separaten Bezugszahl für jede Fabric bezeichnet. Dementsprechend enthält die SoC-Architektur Fabrics 1–5, wobei jede als ein unabhängiges Teilnetz arbeitet, das mit den anderen Fabrics verbunden ist, um eine Kommunikation über mehrere Teilnetze, wie unten erläutert, zu erleichtern. Zahlreiche IP-Blöcke 104 (auch durch die OCP-Spezifikation als IP-Kerne bezeichnet) sind mit entsprechenden Fabrics in SoC-Architektur 100 verbunden gezeigt; diese IP-Blöcke sind als A–V gekennzeichnet und auf diese wird hierin der Einfachheit halber über deren Buchstabenbezeichnung Bezug genommen. Die zahlreichen IP-Blöcke sind für Komponenten oder Funktionseinheiten (d. h. Funktionsblöcke) repräsentativ, die typischerweise in SoC-Designs verwendet werden, einschließlich, aber nicht einschränkend auf, Prozessorkerne, Speicher-Cache-Komponenten und Agenten, Speichercontroller, E/A-Steuerungen und -Schnittstellen, Peripheriegeräte und Peripherieschnittstellen, Video- und Audiokomponenten und -Schnittstellen, Plattform-Management-Komponenten, etc.
Interconnect Fabrics, wie beispielsweise durch Fabrics 1–5 in 1a gezeigt, unterstützen Kommunikation zwischen den IP-Blöcken unter Verwendung von korrespondierenden Verdrahtungen und Protokollen. Allgemein kann die Struktur einer bestimmten Interconnect Fabric ein vollständiges Crossbar „Mesh”, eine locker besiedelte Fabric, die eine Vielzahl von Punkt-zu-Punkt-Links umfasst, eine Architektur vom Typ mit gemeinsamem Bus oder eine Ring-Topologie umfassen. In einer Ausführungsform ist die SoC-Architektur 100 so verallgemeinert, dass jede der Fabrics 1–5 in jeder dieser Topologien konfiguriert sein kann. Außerdem sind die bestimmte Verbindungsstruktur und bestimmten Protokolle auch in der SoC-Architektur 100 so verallgemeinert, dass die verschiedenen Fabrics dieselben oder andere Verbindungsstrukturen und Protokolle verwenden können. Zum Beispiel kann es wünschenswert sein, eine Verbindung (Interconnect), die ein Cache-Kohärenz-Protokoll (zum Beispiel QPI) unterstützt, für Kommunikation zwischen Prozessorkernen und Speicher-Cache-bezogenen IP-Blöcken zu verwenden, während andere Strukturen und Protokolle, wie zum Beispiel OCP, für andere Fabrics in der Architektur verwendet werden können. Optional kann ein einziges Protokoll für die gesamte Architektur verwendet werden oder können die in der 1a dargestellten Fabric-Strukturen einen Teil eines SoC darstellen. Zum Beispiel entspricht in einer Ausführungsform die SoC-Architektur 100 einem South-Komplex in einer SoC-Architektur, wie in 5 gezeigt und nachfolgend beschrieben.
In einer Ausführungsform umfasst jede der Fabrics 1–5 eine OCP-Fabric. Unter dem Open Core-Protokoll werden Kommunikationen von einem Initiator (I) initiiert und über die Fabric zu einem Ziel (T) gerichtet, wie im Detail unten beschrieben ist. Dementsprechend sind Initiatorblöcke 106 (I) und Zielblöcke 108 (T) innerhalb jeweiliger IP-Blöcke A–V in 1 dargestellt. Im Allgemeinen stellt ein Initiatorblock I oder Zielblock T eine Schnittstellenschaltung zur Erleichterung der Kommunikation zwischen einem IP-Block und der Fabric, mit der er gekoppelt ist, dar und können sich dementsprechend Initiator- und Zielblöcke auch auf Initiator- und Zielschnittstellen in den hier dargestellten IP-Blöcken beziehen.
In der SoC-Architektur 100 ist auch eine Vielzahl von Fabric-zu-Fabric-Links 110 dargestellt, die zur Koppelung von Paaren von Fabrics bei der Kommunikation verwendet werden. Diese sind als FF n-m gekennzeichnet, wobei n eine der gekoppelten Fabrics kennzeichnet und m die andere repräsentiert. Zum Beispiel erleichtert der Fabric-zu-Fabric-Link FF 1-2 eine Kommunikation zwischen Fabric 1 und Fabric 2. Obwohl als Fabric-zu-Fabric-Links bezeichnet, können diese Links auch als Fabric-zu-Fabric-Brücken (Bridges) in Fällen fungieren, in denen die verbundenen Fabrics unterschiedliche Strukturen und Protokolle verwenden (zum Beispiel eine QPI-zu-OCP-Brücke), oder in Fällen, in denen die Taktgeschwindigkeiten eines Paares von verbundenen Fabrics, die dasselbe Protokoll verwenden, unterschiedlich sind.
In 1a sind zahlreiche IP-Blöcke 104 so dargestellt, dass sie einen Initiatorblock I und/oder einen Zielblock T enthalten, was darauf hinweist, dass sich die Schnittstellenfähigkeit mit der OCP-Fabric für die zahlreichen IP-Blöcke unterscheiden kann. Zum Beispiel können Peripheriegeräte, wie zum Beispiel Audioeingänge (Mikrofone) und -ausgänge (Lautsprecher) nur unidirektionale Kommunikation mit anderen IP-Blöcken erfordern, wobei darauf hinzuweisen ist, dass korrespondierende Audioschnittstellenkomponenten entweder bidirektionale oder unidirektionale Kommunikation unterstützen können. In ähnlicher Weise ist jeder der Fabric-zu-Fabric-Links 110 als ein Doppelpfeil dargestellt, um Unterstützung von bidirektionaler Kommunikation über die Links anzuzeigen. Die Bezugnahme hier auf bidirektionale Kommunikation verlangt jedoch keine bidirektionalen physischen Links (Verbindungen) (d. h., eine physische Verbindung, die bidirektionale Kommunikation über ihre Drähte bzw. Leitungen unterstützt). Vielmehr kann bidirektionale Kommunikation zwischen IP-Blöcken oder Fabrics, wie weiter unten näher erläutert wird, durch Verwendung von unidirektionalen Links, die in entgegengesetzten Richtungen arbeiten, erleichtert werden. Alternativ können bidirektionale Datentransfers über einzelne unidirektionale Links erfolgen (d. h., dass korrespondierende Sätze von Drähten bzw. Leitungen verwendet werden, um bidirektionale Datentransfers zu unterstützen), beispielsweise wenn ein Initiator Lese- und Schreiboperationen mit einem Ziel durchführt.
Aspekte der hierin offenbarten Ausführungsformen können vorteilhafterweise in mobilen Plattformen, wie Smartphones und Tablets, eingesetzt werden. Der Stromverbrauch spielt eine große Rolle bei diesen Typen von Plattformen und somit ist jede Verringerung des Stromverbrauchs von Vorteil. In Übereinstimmung mit den Lehren hierin kann der Stromverbrauch durch die Verwendung einer hierarchischen Interconnect-Fabric-Architektur und durch die Verwendung von dynamisch wählbarem Routing über redundante gemeinsame physische Links (Verbindungen) reduziert werden.
Verglichen mit einem gemeinsamen Bus oder vollständig bestückten Crossbar-Interconnects, haben in der Regel hierarchische Netzwerke einen Vorteil [1] in der Energieeffizienz, da ausgewählte Fabrics leistungsgeschaltet (power gated) werden können, wenn sie nicht benötigt werden, und [2] in der Siliziumfläche, da die Komplexität einer Fabric (als ein Kreuzpunkt implementiert) mit dem Quadrat der Anzahl von verbundenen Einheiten wächst. Allgemein führt die Verwendung irgendeiner aktiven Transistoroperation oder einer Operation, die zu einer elektrischen Last auf eine SoC-Schaltung führt, zum Verbrauch von Energie. Außerdem gilt, dass, je höher die Betriebsfrequenz (zum Beispiel Taktzyklus oder Frequenz), die für eine Schaltung, wie zum Beispiel Interconnects, verwendet wird, ist, desto höher der Energieverbrauch ist. Im Hinblick darauf kann die Energie durch Verwendung von weniger physischer Interconnect-Struktur (d. h., weniger „Drähten” und korrespondierender Schnittstellenschaltung, wie zum Beispiel Puffer und Schaltlogik) und/oder Betrieb bei niedrigeren Frequenzen reduziert werden. In beiden Fällen gibt es jedoch einen Kompromiss zwischen Energieverbrauch und Durchsatzleistung.
Eine Möglichkeit, dem Kompromiss Rechnung zu tragen, besteht darin, niedrigere Frequenztaktraten für Teile der SoC-Architektur zu verwenden, die keine höheren Raten, die allgemein mit Prozessor- und Speicheroperationen oder Videooperationen verbunden sind, verlangen. Zum Beispiel können Audiokomponenten und Peripheriegeräte und E/A-Komponenten, die allgemein als langsam klassifiziert sind, konfiguriert werden, um mit korrespondierenden Interconnect-Fabric-Blöcken, die mit niedrigen Taktraten arbeiten, eine Verbindung einzugehen. Da die hierarchische Art der SoC-Architektur 100 die Implementierung von separaten Fabrics unterstützt, können einzelne Fabrics mit niedrigeren Frequenzen betrieben oder in einen Bereitschaftszustand oder in einen ausgeschalteten Zustand versetzt werden. Wenn zum Beispiel Audio-IP-Blöcke mit einer separaten Fabric gekoppelt werden, kann die Fabric ausgeschaltet oder in einen Bereitschaftszustand gebracht werden, wenn keine Audiofunktionen erforderlich sind, wodurch die Batterie geschont wird.
Ein weiterer erfinderischer Aspekt der vorliegenden Erfindung stellt die Verwendung von redundanten physischen Links (Verbindungen) dar, die dynamisch konfiguriert werden können, um höhere Transferraten unter bestimmten Betriebsbedingungen zu unterstützen, während gleichzeitig die Energieverbräuche unter Betriebsbedingungen reduziert werden, die niedrigere Transferraten erfordern. In den folgenden Ausführungsformen werden Open Core-Protokoll-konforme Fabrics verwendet, um Aspekte der Implementierung dieser Merkmale zu demonstrieren. Es wird jedoch darauf hingewiesen, dass Fabric-Implementierungen, die andere Protokolle verwenden, auch benutzt werden können, um ähnliche Verbesserungen im Datendurchsatz und in der Leistungsreduzierung zu erhalten.
Das Open Core-Protokoll definiert eine Punkt-zu-Punkt-Schnittstelle zwischen zwei kommunizierenden Einheiten, wie zum Beispiel IP-Kernen und Busschnittstellenmodulen (Bus Wrappers), hier auch als Agenten bezeichnet. Eine Einheit agiert als der Master der OCP-Instanz und die andere als der Slave. Nur der Master kann Befehle präsentieren und ist die Steuer- bzw. Kontrolleinheit. Der Slave antwortet auf ihm vorgelegte Befehle entweder durch Akzeptieren von Daten vom Master oder dem Master Präsentieren von Daten. Damit die zwei Einheiten in einer Peer-zu-Peer-Art kommunizieren, müssen zwei Instanzen des OCP, das sie verbindet, vorhanden sein, eine, wo die erste Instanz ein Master ist, und eine, wo die erste Instanz ein Slave ist.
2 zeigt ein einfaches System, das einen eingehüllten Bus (wrapped bus) und drei IP-Kerneinheiten enthält: eine, die ein Systemziel ist, eine, die ein Systeminitiator ist, und eine Einheit, die sowohl ein Initiator als auch ein Ziel ist. Es versteht sich, dass allgemein ein „Master” und „Initiator” synonym sind und als solches diese Begriffe hier austauschbar verwendet werden können. In ähnlicher Weise sind „Slave” und „Ziel (Target)” synonym und können austauschbar verwendet werden.
Die Eigenschaften des IP-Kerns bestimmen, ob der Kern Master, Slave oder beide Seiten des OCP benötigt; die Wrapper-Interface-Module müssen als die komplementäre Seite des OCP für jede verbundene Einheit agieren. Ein Transfer über dieses System erfolgt wie folgt. Ein Systeminitiator (wie der OCP-Master) präsentiert Befehl, Steuerung und möglicherweise Daten seinem verbundenen Slave (ein Bus-Wrapper-Interface-Modul). Das Interface-Modul (Schnittstellenmodul) spielt die Anforderung über das On-Chip-Bussystem. Das OCP spezifiziert nicht die eingebettete Busfunktionalität. Stattdessen wandelt der Interface-Designer die OCP-Anforderung in einen eingebetteten Bustransfer um. Das empfangende Bus-Wrapper-Interface-Modul (als der OCP-Master) wandelt die eingebettete Busoperation in einen legalen OCP-Befehl um. Das Systemziel (OCP-Slave) empfängt den Befehl und führt die geforderte Aktion durch.
Jede Instanz des OCP ist basierend auf den Anforderungen der verbundenen Einheiten konfiguriert (durch Auswählen von Signalen oder Bitbreiten eines bestimmten Signals) und ist von den anderen unabhängig. Zum Beispiel können Systeminitiatoren mehr Adressbits in deren OCP-Instanzen als die Systemziele erfordern; die zusätzlichen Adressbits könnten vom eingebetteten Bus verwendet werden, um auszuwählen, welches Busziel von dem Systeminitiator adressiert wird.
Das OCP ist flexibel. Es gibt mehrere nützliche Modelle dafür, wie existierende IP-Kerne miteinander kommunizieren. Einige verwenden Pipelining, um Bandbreiten- und Latenzeigenschaften zu verbessern. Andere verwenden Multizyklus-Zugriffsmodelle, bei denen Signale über mehrere Taktzyklen statisch gehalten werden, um eine Timing-Analyse zu vereinfachen und die Implementierungsfläche zu reduzieren. Unterstützung für dieses große Spektrum von Verhalten ist durch die Verwendung von synchronen Handshaking-Signalen möglich, die ermöglichen, dass sowohl der Master als auch der Slave steuern, wann sich Signale ändern dürfen.

Die nachstehende Tabelle 1 listet die grundlegenden OCP-Signale auf. Im Allgemeinen sind weitere Details betreffend zahlreiche Aspekte von OCP in Open Core Protocol-Spezifikation 2.2 (oder 3.0) dargelegt. Zusätzlich zu diesem grundsätzlichen OCP gibt es zahlreiche optionale Signale, die implementiert werden können, wie durch die OCP-Spezifikationen definiert.

Name	Breite	Treiber	Funktion
Clk	1	variiert	Takteingabe
EnableClk	1	variiert	aktiviere OCP-Takt
MAddr	konfigurierbar	Master	Transferadresse
MCmd	3	Master	Transferbefehl
MData	konfigurierbar	Master	Schreibdaten
MDataValid	1	Master	Schreibdaten gültig
MRespAccept	1	Master	Master akzeptiert Antwort
SCmdAccept	1	Slave	Slave akzeptiert Transfer
SData	konfigurierbar	Slave	Lesedaten
SDataAccept	1	Slave	Slave akzeptiert Schreibdaten
SResp	2	Slave	Transferantwort

TABELLE 1

Clk
Eingangstaktsignal für den OCP-Takt. Die steigende Flanke des OCP-Takts ist als eine ansteigende Flanke von Clk definiert, die den behaupteten EnableClk abtastet. Fallende Flanken von Clk und irgendeine ansteigende Flanke von Clk, die nicht den behaupteten EnableClk abtasten, bilden keine ansteigenden Flanken des OCP-Takts.
EnableClkEnableClk
gibt an, welche ansteigenden Flanken von Clk die ansteigenden Kanten des OCP-Takts sind, d. h., welche ansteigenden Flanken von Clk den Schnittstellenzustand abtasten und voranbringen. Verwende den enableclk-Parameter zum Konfigurieren dieses Signals. EnableClk wird von einer dritten Einheit angetrieben und dient als eine Eingabe für sowohl den Master als auch den Slave.
Wenn enableclk auf 0 (Voreinstellung) gesetzt ist, ist das Signal nicht vorhanden und verhält sich das OCP, als ob EnableClk als konstant angenommen wird. In dem Fall sind alle ansteigenden Flanken von Clk ansteigende Flanken des OCP-Takts.
MAddr
Die Transferadresse, MAddr, spezifiziert die Slave-abhängige Adresse der durch den aktuellen Transfer adressierten Resource. Verwende den Adressparameter zum Konfigurieren dieses Feldes in dem OCP. Verwende den Adressbreiten(addr_wdth)-Parameter zum Konfigurieren der Breite dieses Feldes. MAddr ist eine Byte-Adresse, die sich an der OCP-Wortlänge (data_wdth) orientiert. data_wdth definiert einen minimalen addr_wdth-Wert, der auf der Datenbus-Byte-Breite basiert und definiert ist als: min_addr_wdth = max(1, floor(log2(data_wdth)) – 2).
Wenn die OCP-Wortlänge größer als ein einzelnes Byte ist, wird das Aggregat an der OCP-Wort-orientierten Adresse adressiert und werden die niederwertigsten Adressbits auf 0 verdrahtet. Wenn die OCP-Wortlänge keine Zweierpotenz ist, ist die Adresse dieselbe, wie sie für eine OCP-Schnittstelle mit einer Wortlänge gleich der nächstgrößeren Zweierpotenz wäre.
MCmd
Transferbefehl. Dieses Signal gibt den Typ des OCP-Transfers an, den der Master anfordert. Jeder Nichtleerlaufbefehl ist entweder eine Lese- oder Schreibanforderung, in Abhängigkeit von der Richtung des Datenflusses.
MData
Schreibdaten. Dieses Feld enthält die Schreibdaten vom Master zum Slave. Das Feld ist in dem OCP unter Verwendung des mdata-Parameters konfiguriert und seine Breite ist unter Verwendung des data_wdth-Parameters konfiguriert. Die Breite ist nicht auf Vielfache von 8 beschränkt.
MDataValid
Schreibdaten gültig. Wenn auf 1 gesetzt, gibt dieses Bit an, dass die Daten in dem MData-Feld gültig sind. Verwende den Datahandshake-Parameter zum Konfigurieren dieses Feldes in dem OCP.
MRespAccept
Masterantwort akzeptieren. Der Master zeigt an, dass er die aktuelle Antwort vom Slave mit einem Wert von 1 in dem MRespAccept-Signal akzeptiert. Verwende den respaccept-Parameter zum Aktivieren dieses Feldes in dem OCP.
SCmdAccept
Slave akzeptiert Transfer. Ein Wert von 1 in dem SCmdAccept-Signal gibt an, dass der Slave die Transferanforderung des Masters akzeptiert. Verwende den cmdaccept-Parameter zum Konfigurieren dieses Feldes in dem OCP.
SData
Dieses Feld enthält die angeforderten Lesedaten vom Slave zum Master. Das Feld ist in dem OCP unter Verwendung des sdata-Parameters konfiguriert und seine Breite ist unter Verwendung des data_wdth-Parameters konfiguriert. Die Breite ist nicht auf Vielfache von 8 beschränkt.
SDataAccept
Slave akzeptiert Schreibdaten. Der Slave zeigt an, dass er gepipelinete Schreibdaten vom Master mit einem Wert von 1 in SDataAccept akzeptiert. Dieses Signal ist nur sinnvoll, wenn ein Datahandshake verwendet wird. Verwende den dataaccept-Parameter, um dieses Feld in dem OCP zu konfigurieren.
SResp
Antwortfeld vom Slave zu einer Transferanforderung vom Master. Das Feld ist in dem OCP unter Verwendung des resp-Parameters konfiguriert.
Wie anhand des Obigen zu sehen ist, kann ein bestimmter OCP-Link bidirektionalen Datenverkehr unterstützen (zum Beispiel Schreiben von einem Master zu einem Slave und Lesen von einem Slave durch einen Master). Der Übersichtlichkeit halber ist hier jedoch die Richtung eines bestimmten Links von ihrem Initiator (d. h. Master unter OCP) zu ihrem Ziel (d. h. Slave unter OCP) und wird als unidirektionaler Link bezeichnet.
1b zeigt ein Beispiel für die Verwendung von gemeinsamen physischen OCP-Links zwischen OCP-Fabrics. Jeder dieser Links umfasst einen Satz OCP-Drähte mit Datentransfers, die entsprechend anwendbarer OCP-Protokoll-Signalisierung implementiert sind. Jeder Fabric-zu-Fabric-Link ist gekennzeichnet als FF m-s, wobei m der als der Master operierenden Fabric entspricht und s der als der Slave operierende Fabric entspricht. Zum Beispiel ist das Paar Links zwischen Fabric 1 und Fabric 2 als FF 12 und FF 2-1 gekennzeichnet.
1b stellt auch zwei Datentransfers dar, die von IP-Blöcken IP-B und IP-D initiiert sind, die mit Fabric 1 verbunden und jeweils auf IP-Block IP-J abzielen, der mit Fabric 2 und IP-Block IP-O verbunden ist, der mit Fabric 4 verbunden ist. Wie ersichtlich ist, verwenden diese beiden Datentransfers denselben physischen Datenpfad, der von Fabric-zu-Fabric-Link FF 1-2 definiert ist und somit als „Shared Links” dargestellt ist. Während dies zur Erleichterung der Kommunikation zwischen IP-Blöcken, die mit zahlreichen Fabrics gekoppelt sind, von Vorteil ist, führt dies zu einem Verkehrsstau, der die Arbitrierung der gemeinsamen Links (shared Links) erfordert, was zu Bandbreitenengpässen führt und somit den Gesamtdurchsatz reduziert.
In Übereinstimmung mit der Lehre hier ist (sind) ein oder mehrere redundante Fabric-zu-Fabric-Link(s) implementiert, um Verkehrsstau zu reduzieren und den Gesamtdurchsatz zu verbessern. Details von beispielhaften Implementierungen derartiger redundanter Fabric-zu-Fabric-Links sind in den 1c, 3b und 3c gezeigt. Zum Beispiel ist in der SoC-Architektur 100C von 1c ein redundanter Satz Fabric-zu-Fabric-OCP-Links (einer in jeder Richtung) zur Architektur 100b von 1b hinzugefügt worden. Wie zuvor ist jeder Fabric-zu-Fabric-Link gekennzeichnet als FF m-s, unter Hinzufügung eines „R”, um anzuzeigen, dass der Link redundant ist. Es wird angemerkt, dass die Aufnahme einer Hinzufügung eines Paares unidirektionaler Links zwischen den Fabrics in 1c lediglich beispielhaft ist, da es nicht erforderlich ist, redundante Fabric-zu-Fabric-Links zwischen irgendeinem bestimmten Paar von Fabrics hinzuzufügen, und dass die Anzahl von Links, die in einer bestimmten Richtung hinzugefügt ist, nicht mit der Anzahl von Links übereinstimmen muss, die (falls vorhanden) in einer entgegengesetzten Richtung hinzugefügt sind. Außerdem kann das allgemeine Konzept erweitert werden, um ferner weitere Fabric-zu-Fabric-Links zwischen einem bestimmten Paar Fabrics hinzuzufügen, falls gewünscht.
Die 3a und 3b zeigen diverse OCP-Links innerhalb der Fabrics 1 und 2 und Fabric-zu-Fabric-Links 200 und 202 zwischen Fabrics 1 und 2. Der Einfachheit und Klarheit halber werden nur ausgewählte Initiatoren und Ziele von den in den 1a–c gezeigten in den 3a–c gezeigt. Die Initiatoren in den 3a–c sind als Ix–y gekennzeichnet, wobei x die Fabric identifiziert und y den bestimmten Initiator der Fabric identifiziert. In ähnlicher Weise sind Ziele mit Tx–y in den 3a–c gekennzeichnet. Um Unordnung zu vermeiden, sind auch die IP-Blöcke, die diesen Initiatoren und Zielen entsprechen, in den 3a–c nicht gezeigt; jedoch versteht es sich, dass diese IP-Blöcke mit den anwendbaren Fabrics in einer tatsächlichen Implementierung gekoppelt würden.
Sowohl die 3a als auch die 3b zeigen gemeinsame Initiatoren, Ziele und korrespondierende OCP-Punkt-zu-Punkt-Links. 3b zeigt ferner die Hinzufügung einer redundanten Fabric-zu-Fabric-OCP-Link 304 zwischen Zielagent (Target Agent (TA)) 306 und Initiatoragent (Initiator Agent (IA)) 308 der Fabric 1 bzw. 2. Der redundante Link (Verbindung) ist durch Implementierung einer zweiten Instanz der Link-Zielagent(als TA gekennzeichneter Kasten)-Logik in Fabric 1 und einer zweiten Instanz der Link-Initiatoragent(als IA gekennzeichneter Kasten)-Logik in Fabric 2 und Verbinden dieser Agenten mit (physischen) Drähten gemäß der zu implementierenden bestimmten OCP-Linkbreite realisiert. Die Eigenschaften des OCP-Busses des ursprünglichen und redundanten Links sind somit identisch, wenn die Konfiguration von sowohl der Fabric-zu-Fabric-Link 302 als auch der Fabric-zu-Fabric-Link 304 dieselbe ist. Weiterhin sind zusätzliche OCP-Links zwischen jedem der Initiatoren I1-1, I1-2 und I1-3 und Zielagent 306 und zwischen Initiatoragent 308 und Zielen T2-4 und T2-5 gezeigt. Wie dargestellt, liefert die Hinzufügung eines redundanten Fabric-zu-Fabric-OCP-Links 304 einen parallelen Datenpfad zum ursprünglichen gemeinsamen Fabric-zu-Fabric-OCP-Link 302.
Es ist auch eine Modifikation an der Adressenabbildung von beiden Fabrics vorgenommen worden. Die Modifikation wurde vorgenommen, um eine gerechte Aufteilung von Datenpfaden zwischen denen, die den ursprünglichen gemeinsamen Link verwenden, und denen, die den redundanten Link verwenden, zu ermöglichen. In 3b ist die Beispielpartitionierung so gezeigt, dass Pfade zu Zielen T2-1, T2-2 und T2-3 unverändert den ursprünglichen gemeinsamen Link verwenden, während Pfade zu Zielen T2-4 und T2-5 den redundanten gemeinsamen Link verwenden. (Es ist zu beachten, dass mit dieser Partitionierung die beiden in 3a gezeigten Beispielpfade jetzt unterschiedliche gemeinsame Links verwenden würden und einander keine Verzögerungen auferlegen.)
Der untere Teil jeder der 3a–c zeigt Zieladressenabbildungen bzw. -zuordnungen für die Ziele in Fabrics 1 und 2. Unter OCP werden unidirektionale Punkt-zu-Punkt-Links zwischen Initiatoren und Zielen geroutet und somit die Zieladressenbereiche der Ziele für jede Fabric vordefiniert. Jedem Ziel ist ein fester Adressenbereich zugeordnet, und da auf ein bestimmtes Ziel von mehreren Initiatoren zugegriffen werden kann, können die Adressenbereiche für einige Ziele größer sein und/oder mehrere Segmente einnehmen. Dies gilt besonders für Zieladressen, die gemeinsamen Fabric-zu-Fabric-OCP-Links entsprechen. Beispielsweise ist zu beachten, dass die Adressbereiche für Ziel T1-4 in Fabric 1 vier segmentierte Bereiche enthalten, einschließlich dreier Segmente mit einer Länge, die länger als vergleichbare Segmente für Ziele T1-1, T1-2 und T1-3 ist.
Das in 3a gezeigte Adressierungsschema entspricht der Verwendung von konventionellen gemeinsamen Fabric-zu-Fabric-OCP-Links, während das Adressierungsschema in 3b der Hinzufügung der hinzugefügten Fabric-zu-Fabric-Link 204 entspricht. Zur Unterbringung des neuen Ziels T1-5 sind die höchsten zwei Adressbereiche für T1-4 in 3a T1-5 in 3b neu zugeordnet worden, während der Rest der Adressbereichsabbildungen bzw. -zuordnungen dieselben bleiben. Es ist zu beachten, dass dies gleichzeitig eine Partitionierung von Pfaden zwischen Transfers über den ursprünglichen gemeinsamen Fabric-zu-Fabric-Link 202 und den hinzugefügten redundanten Fabric-zu-Fabric-Link 204 erzeugt. Beispielsweise werden Transfers von Initiatoren in Fabric 1, die Zielen T2-4 und T2-5 in Fabric 2 entsprechen, nun auf Fabric-zu-Fabric-Link 204 geroutet.
3c zeigt eine optionale Erweiterung, die implementiert werden kann, um den Datendurchsatz weiter zu verbessern. Die Erweiterung versucht, einen Pfad, der normalerweise den ursprünglichen gemeinsamen Link verwenden wird, opportunistisch neu zu routen, um stattdessen den redundanten Link in dem Fall zu verwenden, wo der ursprüngliche Link damit beschäftigt ist, frühere Befehle auszuführen, während der redundante Link im Leerlauf ist (wodurch die mit Löschen der vorherigen Befehle verbundene Wartezeit vermieden wird). Die Details der Erweiterung sind wie folgt: Ein Ziel, das der ursprüngliche Link (z. B. Fabric-zu-Fabric-Link 302) verwendet, wird ausgewählt. In diesem Fall Ziel T2-3. Die dem Ziel zugeordnete Adressabbildungsregion wird untersucht. Die Startadresse für die Region wird festgestellt. In diesem Fall ist die Adresse T2_3_StartAddr. Die Größe der Region wird festgestellt und daraus die effektive Anzahl von Adressbits als N abgeleitet. (N bedeutet, dass die Größe der Region kleiner als oder gleich 2^N Bytes ist.) Die Adressabbildung wird nach einer geeigneten Alias-Region abgesucht. Die Alias-Region muss in der Größe gleich der T2-3-Region sein und in (bisher) nicht verwendetem Raum liegen (graue Fläche in der Adressabbildung). In 2c ist eine solche Region als T2-3-Alias mit Startadresse T2_3_AliasStartAddr vorhanden. Die Adressabbildungen für die beiden Fabrics werden danach aktualisiert, so dass, wenn eine Adresse in der Alias-Region präsentiert wird (durch einen Fabric 1-Initiator), der Pfad durch den redundanten Link (Fabric-zu-Fabric-Link 304) zu Ziel T2-3 geroutet wird (unter Verwendung des mit einer gestrichelten Linie markierten dynamischen Pfads). Schließlich wird ein (Vollkombinations-)Logikblock, als Selektor 310 gekennzeichnet, hinzugefügt (für jeden Fabric-1-Initiator). Die Rolle, die dem Selektor zukommt, besteht darin, gegebenenfalls in der Alias-Version der T2-3-Adresse (die ursprünglich vom Initiator kommt) zu multiplexen.
Allgemein ist die Verwendung des Alias-Adressierungsschemas (und zugehörigem dynamischen Routing) für sowohl Initiatoren als auch Ziele transparent. Dementsprechend bleiben die von einer Initiatorschnittstelle IP-Blocks zum Transfer von Daten zwischen einem Initiator und einem Ziel verwendeten Zieladressen unverändert. Außerdem ist das Neu-Routing (Re-Routing) nicht auf Routen von einem ursprünglichen Link zu einem redundanten Link beschränkt. Vielmehr kann Neu-Routing auch auf einen Befehl angewendet werden, der durch Voreinstellung den redundanten Link nehmen würde, aber stattdessen auf den ursprünglichen Link dynamisch umgeschaltet werden könnte.
4 zeigt beispielhafte Implementierungsdetails des Selektors 310 gemäß einer Ausführungsform. Im Allgemeinen ist das meiste der von Selektor 310 durchgeführten Logik über einen Logikblock 400 implementiert, der die Logik zeigt, die verwendet wird, um festzustellen, ob eine Alias-Adresse oder eine ursprüngliche Adresse verwendet werden soll oder nicht. Die in 3 gezeigte beispielhafte Implementierung nimmt einen 32-Bit-Adressbereich für die Fabrics und verwendet allgemein Standard-OCP-Signale für die Mehrzahl der Eingaben, wie oben dargestellt. Es ist jedoch zu beachten, dass T1_4_active und T1_5_active nicht OCP-standardisierte Signale sind, sondern Signale sind, die im Allgemeinen in typischen Fabric-Implementierungen zur Verfügung stehen. Sie zeigen an, wenn der jeweilige Zielagent (innerhalb Fabric 1) damit beschäftigt ist, eine vorherige Anforderung zu erfüllen (d. h. immer noch auf einen vorherigen Befehl zum vollständigen Abschließen wartet). In Fällen, in denen das _active-Signal nicht verfügbar ist, aber das OCP-Signal SThreadBusy (und/oder SDataThreadBusy) verfügbar ist, kann dieses Besetztsignal stattdessen verwendet werden. Alternativ könnte das OCP-Signal SCmdAccept (invertiert) verwendet werden, falls verfügbar und falls der Ruhe-/Leerlaufzustand für das Signal hoch ist. Die in Logikblock 400 gezeigte Logik kann typischerweise unter Verwendung von Standard-Embedded Logic Design-Techniken, wie die Verwendung von ASIC- oder FPGA-Logikdesignwerkzeugen, programmierten Logikwerkzeugen, etc., implementiert sein.
Wie oben diskutiert, können die hier diskutierten Fabric-Architekturen für alle oder einen Teil der in einem SoC verwendeten Fabrics repräsentativ sein. Ein Beispiel des Letzteren ist in 5 dargestellt, die eine SoC-Architektur 500 mit einem North-Komplex 502 und einem South-Somplex 100d zeigt. Der North-Komplex kann typischerweise Prozessorkerne enthalten, die mit Cache- und Speicherkomponenten über eine kohärente Fabric gekoppelt sind. Dementsprechend ist North-Komplex 502 so dargestellt, dass er eine Zentralverarbeitungseinheit (CPU) 505 enthält, die eine Vielzahl von Prozessorkernen 506 enthält, von denen jeder mit einer kohärenten Fabric 508, wie zum Beispiel einer QPI-Fabric, gekoppelt ist. Es ist auch ein mit der kohärenten Fabric 508 gekoppelter Speicherblock 510 gezeigt – dieser Speicherblock soll allgemein zahlreiche speicherbezogene Komponenten darstellen, die in der Architektur vorhanden sein können, wie zum Beispiel Caches, Caching-Agenten, Speichercontroller, etc. Im Allgemeinen wird eine SoC-Architektur eine oder mehrere Ebenen von On-Chip-Caches enthalten und kann einige Speicher-On-Chip auf Massenspeicherebene oder eine oder mehrere Schnittstellen zu Chip-externem Speicher aufweisen; der Speicherblock 510 soll für alle diese Konfigurationen repräsentativ sein.
Der North-Komplex enthält auch eine andere Fabric, wie zum Beispiel eine INTEL On-Chip Scalable Fabric (IOSF) oder OCP-Fabric 512, die mit der kohärenten Fabric 508 über eine Fabric-zu-Fabric-Brücke 514 operativ gekoppelt ist. Eine Vielzahl von IP-Blöcken 516 ist mit der Fabric 512 kommunikativ gekoppelt. Zusätzlich zu den in 5 dargestellten Komponenten kann der North-Komplex 502 weitere Komponenten und Fabrics enthalten, wie es von Fachleuten auf dem Gebiet erkannt werden wird.
Der South-Komplex 100d dient allgemein zur Veranschaulichung der SoC-Architektur 100 und 100c, wie oben diskutiert. Im Vergleich zur SoC-Architektur 100c enthält der South-Komplex 100d nur einzelne unidirektionale Link-Paare zwischen Fabric 2 und Fabric 3 und zwischen Fabric 4 und Fabric 5. Wie oben diskutiert, ist dies lediglich beispielhaft für verschiedene Link-Konfigurationen in einer hierarchischen Fabric, die gemäß den Lehren hier implementiert werden kann.
In der Architektur 500 ist ebenfalls eine IOSF/OCP-zu-OCP-Brücke 518 dargestellt. Dies dient zur allgemeinen Veranschaulichung einer Brücke (Bridge), die zwischen Fabric 512 des North-Komplexes und Fabric 1 des South-Komplexes implementiert sein könnte, die in dieser Konfiguration eine OCP-Fabric (wobei Fabric 512 entweder eine IOSF- oder OCP-Fabric umfasst) umfassen würde. In Fällen, in denen die Fabric-Protokolle verschieden sind, wird eine Fabric-Protokoll-Brücke implementiert werden. Wenn sowohl Fabric 512 als auch Fabric 1 OCP-Fabrics sind, kann dann entweder eine OCP-Fabric-zu-Fabric-Brücke verwendet werden oder ein OCP-Fabric-zu-Fabric-Link verwendet werden, in Abhängigkeit von anwendbaren Designparametern. Wenn zum Beispiel die Taktrate von Fabric 512 wesentlich anders als die Taktrate von Fabric 1 ist, dann würde die Brücke eine Taktdomain-Crossing-Funktion unterstützen, während unverändert OCP-Signale an beiden Schnittstellen zur Brücke implementiert werden.
Ausführungsformen der vorliegenden Erfindung, die oben erläutert sind, können allgemein in einer integrierten Schaltung mit einem Halbleiterchip unter Verwendung von bekannten Design- und Herstelltechniken implementiert werden. In einer Ausführungsform können Fabric-Erzeugungswerkzeuge von Sonics, Inc., implementiert werden, um Designimplementierungen zu erleichtern. Obwohl als auf einem SoC implementiert dargestellt, kann auch die Verwendung von redundanten Fabric-zu-Fabric-Links mit optionalem dynamischem Routing auf anderen Typen von Komponenten, einschließlich E/A-Chips, Peripheriechips, Controllers und anderen Arten von integrierten Schaltungen, implementiert werden.
Zusätzlich können Ausführungsformen der vorliegenden Beschreibung nicht nur in einem Halbleiterchip, sondern auch in einem maschinenlesbaren Medium implementiert sein. Zum Beispiel können die oben beschriebenen Designs auf maschinenlesbaren Medien gespeichert und/oder darin eingebettet sein, die mit einem Designwerkzeug verbunden sind, das zum Entwerfen von Halbleiterbausteinen verwendet wird. Beispiele schließen eine Netzliste ein, die in der VHSIC Hardware Description Language(VHDL)-Sprache, Verilog-Sprache oder SPICE-Sprache formatiert ist. Einige Netzlistenbeispiele schließen ein: eine Verhaltensebene-Netzliste, eine Register Transfer Level(RTL)-Netzliste, eine Gateebene-Netzliste und eine Transistorebene-Netzliste. Maschinenlesbare Medien schließen auch Medien mit Layoutinformation, wie zum Beispiel eine GDS-II-Datei, ein. Ferner können Netzlistendateien oder andere maschinenlesbare Medien für Halbleiterchipdesign in einer Simulationsumgebung verwendet werden, um die Verfahren der oben beschriebenen Lehren durchzuführen.
Die obige Beschreibung von dargestellten Ausführungsformen der Erfindung, einschließlich, was in der Zusammenfassung beschrieben ist, soll nicht erschöpfend sein oder die Erfindung auf die offenbarten präzisen Ausführungsformen beschränken. Während spezifische Ausführungsformen der Erfindung und Beispiele für selbige hier zu Darstellungszwecken beschrieben werden, sind zahlreiche äquivalente Modifikationen innerhalb des Umfangs der Erfindung möglich, wie Fachleute auf dem relevanten Gebiet erkennen werden.
Diese Modifikationen können an der Erfindung im Licht der obigen ausführlichen Beschreibung vorgenommen werden. Die in den folgenden Ansprüchen verwendeten Begriffe sollten nicht so ausgelegt werden, dass sie die Erfindung auf die in der Beschreibung und in den Zeichnungen offenbarten spezifischen Ausführungsformen beschränkten. Vielmehr ist der Umfang der Erfindung vollständig durch die beigefügten Ansprüche zu bestimmen, die gemäß etablierten Lehren der Anspruchsinterpretation auszulegen sind.

Claims

Integrierte Schaltung, umfassend: eine erste Fabric, mit der eine Vielzahl von Initiatoren kommunikativ gekoppelt ist; eine zweite Fabric, mit der eine Vielzahl von Zielen kommunikativ gekoppelt ist; erste und zweite Fabric-zu-Fabric-Links, wobei jeder Kommunikation zwischen den ersten und zweiten Fabrics unterstützt; und eine Routing-Schaltung und zugehörige Logik, die mit den ersten und zweiten Fabric-zu-Fabric-Links operativ gekoppelt sind, wobei die Routing-Schaltung und Logik konfiguriert sind, um Daten, die von mindestens einem Initiator stammen und für ein Ziel bestimmt sind, durch selektive Verwendung von einem der ersten oder zweiten Fabric-zu-Fabric-Links zum Routen der Daten von dem mindestens einen Initiator zum Ziel dynamisch zu routen.
Integrierte Schaltung nach Anspruch 1, wobei die Routing-Schaltung konfiguriert ist, um Daten zwischen Initiatoren, die mit der ersten Fabric kommunikativ gekoppelt sind, zu Zielen, die mit der zweiten Fabric kommunikativ gekoppelt sind, unter Verwendung des ersten Fabric-zu-Fabric-Links durch Voreinstellung zu routen, und ferner wobei die Routing-Schaltung konfiguriert ist, um die Nutzung des ersten Fabric-zu-Fabric-Links zu detektieren, und bei Detektion der Nutzung des ersten Fabric-zu-Fabric-Links gleichzeitig mit einem Initiator, der einen Datentransfer zu einem mit der zweiten Fabric kommunikativ gekoppeltem Ziel initiiert, der Datentransfer zwischen den ersten und zweiten Fabrics unter Verwendung des zweiten Fabric-zu-Fabric-Links geroutet wird.
Integrierte Schaltung nach Anspruch 1, wobei die Routing-Schaltung mit mindestens einer Initiator-Fabric-Schnittstelle operativ gekoppelt ist, mit der ein korrespondierender Initiator kommunikativ gekoppelt ist, und wobei dynamisches Routing unter Verwendung der ersten oder zweiten Fabric-zu-Interconnect-Fabric durch Auswählen einer Adresse bewirkt wird, die verursacht, dass die Daten über einen der ersten und zweiten Fabric-zu-Fabric-Links geroutet werden.
Integrierte Schaltung nach Anspruch 3, wobei die Adresse einer Alias-Adresse einer Zielagentschnittstelle der ersten Fabric entspricht.
Integrierte Schaltung nach Anspruch 1, wobei jede der ersten und zweiten Fabrics eine Vielzahl von unidirektionalen Punkt-zu-Punkt-Interconnects aufweist und wobei jeder der ersten und zweiten Fabric-zu-Fabric-Links unidirektionale Punkt-zu-Punkt-Interconnects aufweist.
Integrierte Schaltung nach Anspruch 5, wobei die ersten und zweiten Fabrics Open Core Protocol(OCP)-Fabrics aufweisen und jeder der ersten und zweiten Fabric-zu-Fabric-Links OCP-Links aufweist.
Integrierte Schaltung nach Anspruch 1, ferner umfassend: eine dritte Fabric, mit der mindestens ein Ziel kommunikativ gekoppelt ist; und einen dritten Fabric-zu-Fabric-Link, der Kommunikation zwischen den zweiten und dritten Fabrics unterstützt, wobei die Routing-Schaltung konfiguriert ist, um Daten, die von einem Initiator stammen, der mit der ersten Fabric kommunikativ gekoppelt ist, selektiv zu einem Ziel, das mit der dritten Fabric kommunikativ gekoppelt ist, über einen der ersten und zweiten Fabric-zu-Fabric-Links zu routen.
Verfahren, umfassend: Initiieren eines Datentransfers an einem Initiator, der mit einer ersten Fabric kommunikativ gekoppelt ist, wobei der Datentransfer für ein Ziel bestimmt ist, das mit einer zweiten Fabric kommunikativ gekoppelt ist, wobei die ersten und zweiten Fabrics über erste und zweite Fabric-zu-Fabric-Links kommunikativ gekoppelt sind; und selektives Routen von Daten, die dem Datentransfer entsprechen, vom Initiator zum Ziel über einen der ersten und zweiten Fabric-zu-Fabric-Links.
Verfahren nach Anspruch 8, wobei die Fabrics Open Core Protocol(OCP)-Fabrics aufweisen und die Fabric-zu-Fabric-Links OCP-Links aufweisen.
Verfahren nach Anspruch 8, wobei die Fabrics unidirektionale Punkt-zu-Punkt-Links benutzen und jeder der Fabric-zu-Fabric-Links einen unidirektionalen Punkt-zu-Punkt-Link aufweist.
Verfahren nach Anspruch 8, wobei die selektiven Routingoperationen, die zum Transferieren von Daten vom Initiator zum Ziel verwendet werden, für den Initiator transparent sind.
Verfahren nach Anspruch 8, ferner umfassend Implementieren des selektiven Routings unter Verwendung von eingebetteter Logik mit einer Vielzahl von Logikgattern.
Verfahren nach Anspruch 8, ferner umfassend: Empfangen einer Datentransferanforderung an einem Initiatoragenten der ersten Fabric, wobei die Datentransferanforderung eine Adresse für das Ziel identifiziert; Bestimmen einer Adresse eines Alias-Zielagenten in der ersten Fabric, der mit dem zweiten Fabric-zu-Fabric-Link gekoppelt ist, basierend auf der Adresse für das Ziel; und Routen des Datentransfers innerhalb der ersten Fabric vom Initiatoragenten zum Zielagenten entsprechend der Alias-Adresse.
Verfahren nach Anspruch 8, ferner umfassend: Detektieren, ob der erste Fabric-zu-Fabric-Link beschäftigt ist; und wenn der erste Fabric-zu-Fabric-Link beschäftigt ist, Routen des Datentransfers über den zweiten Fabric-zu-Fabric-Link, anderenfalls Routen des Datentransfers über den ersten Fabric-zu-Fabric-Link.
System-auf-einem-Chip (SoC), umfassend: eine Vielzahl von Open Core Protocol(OCP)-Fabrics, die Schnittstellen aufweisen, die zum Open Core Protocol konform sind, einschließlich mindestens einer ersten und zweiten OCP-Fabric; eine Vielzahl von Intellectual Property(IP)-Blöcken, wobei jeder mit einer der Vielzahl von OCP-Fabrics kommunikativ gekoppelt ist, wobei zumindest ein Teil der IP-Blöcke eine Schnittstelle zum Kommunizieren mit anderen IP-Blöcken über die OCP-Fabric, mit der er kommunikativ gekoppelt ist, enthält, wobei die Schnittstelle für jeden von diesen IP-Blöcken eine Initiatorschnittstelle oder eine Zielschnittstelle oder sowohl eine Initiator- als auch eine Zielschnittstelle enthält; erste und zweite Fabric-zu-Fabric-OCP-Links, wobei jeder Kommunikation zwischen den ersten und zweiten OCP-Fabrics unterstützt; Routing-Schaltung und zugehörige Logik, die mit den ersten und zweiten Fabric-zu-Fabric-OCP-Links operativ gekoppelt sind, wobei die Routing-Schaltung und Logik konfiguriert sind, um Daten, die von einem Initiator eines ersten IP-Blocks stammen, der mit der ersten OCP-Fabric kommunikativ gekoppelt ist, und für eine Zielschnittstelle eines zweiten IP-Blocks bestimmt sind, der mit der zweiten OCP-Fabric kommunikativ gekoppelt ist, durch selektive Verwendung von einem der ersten und zweiten Fabric-zu-Fabric-OCP-Links zum Routen der Daten vom ersten IP-Block zum zweiten IP-Block zu routen.
SoC nach Anspruch 15, wobei die Vielzahl von Fabrics unter Verwendung einer Vielzahl von Links zur Bildung einer hierarchischen Fabric-Struktur miteinander verbunden ist.
SoC nach Anspruch 15, wobei jede der ersten und zweiten OCP-Fabrics eine Vielzahl von unidirektionalen Punkt-zu-Punkt-Interconnects aufweist und wobei jeder der ersten und zweiten Fabric-zu-Fabric-OCP-Links unidirektionale Punkt-zu-Punkt-Interconnects aufweist.
SoC nach Anspruch 15, wobei der SoC einen North-Komplex und einen South-Komplex enthält und die Vielzahl von OCP-Fabrics in dem South-Komplex implementiert ist.
SoC nach Anspruch 15, wobei die Routing-Schaltung konfiguriert ist, um Daten zwischen IP-Blöcken, die eine Initiatorschnittstelle enthalten, die mit der ersten Fabric kommunikativ gekoppelt ist, und IP-Blöcken, die eine Zielschnittstelle enthalten, die mit der zweiten Fabric kommunikativ gekoppelt ist, unter Verwendung des ersten Fabric-zu-Fabric-OCP-Links durch Voreinstellung zu routen, und ferner wobei die Routing-Schaltung konfiguriert ist, um die Daten unter Verwendung des zweiten Fabric-zu-Fabric-OCP-Links zu routen, wenn festgestellt wird, dass der erste Fabric-zu-Fabric-OCP-Link beschäftigt ist.
SoC nach Anspruch 15, wobei die Routing-Schaltung mit mindestens einer Initiator-Fabric-Schnittstelle operativ gekoppelt ist, mit der eine korrespondierende Initiatorschnittstelle eines IP-Blocks kommunikativ gekoppelt ist, und wobei dynamisches Routing unter Verwendung des ersten oder zweiten Fabric-zu-Fabric-OCP-Links durch Auswählen einer Adresse bewirkt wird, die bewirkt, dass die Daten über einen der ersten und zweiten Fabric-zu-Fabric-OCP-Links geroutet werden.