DE102009032581B4

DE102009032581B4 - Management der Zeitsteuerung eines Protokollstapels

Info

Publication number: DE102009032581B4
Application number: DE102009032581A
Authority: DE
Inventors: David J. Harriman
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2008-07-15
Filing date: 2009-07-10
Publication date: 2012-05-31
Anticipated expiration: 2029-07-11
Also published as: GB0912137D0; GB2461802A; JP2012105344A; US8218580B2; CN101630301A; JP5422005B2; TW201009585A; JP2010088106A; US20100014541A1; GB2461802B; JP4909384B2; CN101630301B; TWI424317B; DE102009032581A1

Abstract

Bei einer Ausführungsform umfasst die vorliegende Erfindung ein Verfahren zum Empfangen einer Kommunikation in einem Protokollstapel, der an eine Tunneling-Kopplungsstruktur gekoppelt ist, wobei bestimmt wird, ob ein Kommunikationstyp einer geänderten Zeitsteuerung unterliegt, um eine Verzögerung in Verbindung mit der Tunneling-Kopplungsstruktur zu ermöglichen, wobei eine Zeitsteuerung von mindestens einer Stapellogik zum Ermöglichen der Verzögerung justiert wird, und die Kommunikation unter Verwendung der justierten Zeitsteuerung behandelt wird. Weitere Ausführungsformen sind beschrieben und werden beansprucht.

Description

Hintergrund
Computerplattformen enthalten normalerweise eine Reihe von Halbleiterkomponenten, die über verschiedene Kopplungsstrukturen gekoppelt sind. Diese Kopplungsstrukturen oder Links gehören oft zu verschiedenen Protokollen, so dass die Kommunikation auf den verschiedenen Links entsprechend den verschiedenen Protokollen mit unterschiedlichen Geschwindigkeiten erfolgt. Bei einigen Systemen kann die Kommunikation eines Ein-/Ausgangs-(I/O – Input/Output)-Protokolls über eine andere Kopplungsstruktur getunnelt werden. Tunneling betrifft generell die Kommunikation gemäß eines ersten Protokolls und Zustellung dieser durch eine Kopplungsstruktur, die gemäß eines zweiten Protokolls arbeitet, so dass die Pakete des ersten Protokolls getunnelt werden, z. B. durch Anwenden eines Headers des zweiten Protokolls auf die Pakete des ersten Protokolls und deren Senden durch die Kopplungsstruktur. Dieses Protokoll-Tunneling erfolgt normalerweise auf einem sehr hohen Level, so dass die zwei Protokolle zwar die gleiche Softwareabstraktion haben können, jedoch keinerlei Hardware zwischen den Protokollen geteilt wird. Somit ist der Vorteil dieser Art von Tunneling in Bezug auf Softwarekompatibilität, Leistung und Markteinführungszeit minimal.
Die US 2005/0060470 A1 offenbart eine Vorrichtung, die einen ersten Protokollstapel zum Behandeln der Daten gemäß einem ersten Protokoll aufweist. Eine Low Pin Code (LPC)-Busschnittstelle entspricht dem ersten Protokoll und enthält eine Busschnittstelle und einen Tunnelmaster, der wiederum mit einem hybriden PCI-Express-Port koppelt. Der LPC-Bus soll mit einer viel geringeren Geschwindigkeit als der PCI-Bus arbeiten. Mit anderen Worten arbeitet der LPC-Bus gemäß einer Zeitsteuerung und der PCIe-Bus gemäß einer anderen Zeitsteuerung. In dem PCIe-Bus steht ausreichend Bandbreite zur Verfügung, um langsame LPC-Bus-Kommunikation zu handhaben.
Aus der US 2006/0101178 A1 ist eine Vorrichtung bekannt, die einen ersten Protokollstapel zum Behandeln der Daten gemäß einem ersten Protokoll aufweist, wobei eine Tunneling-Kopplungsstruktur möglich sein soll. Eine Warteschlangenstruktur weist untersehiedliche Pointer auf, nämlich einen Schreib-Pointer, der gemäß einer Host-Domain-Zeitsteuerung übergeht, während ein Lese-Pointer gemäß einer Link-Domain-Zeitsteuerung übergeht. Es sind somit unterschiedliche Zeitsteuerungen vorhanden und es werden Pakete gemäß unterschiedlichen Zeitsteuerungen in Warteschlangen eingereiht und dort herausgenommen.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm einer Verbindung eines Protokollstapels über eine geteilte (shared) physikalische Schicht gemäß einer Ausführungsform der vorliegenden Erfindung.
2 ist ein Blockdiagramm eines Systems mit mehreren Kommunikationsstapeln, die gemäß einer Ausführungsform der vorliegenden Erfindung mit einer geteilten (shared) physikalischen Schicht gekoppelt sind.
3 ist ein Ablaufdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist ein Ablaufdiagramm eines Verfahrens zum Betrieb einer Schnittstelle eines Protokollstapels gemäß einer weiteren Ausführungsform der vorliegenden Erfindung.
5 ist ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung.
Detaillierte Beschreibung
Bei verschiedenen Ausführungsformen können eines oder mehrere vorhandene I/O-Protokolle auf relativ niedrigem Level über eine andere Kopplungsstruktur, die hiernach als Tunneling-Kopplungsstruktur beschrieben wird, getunnelt werden. Bei einer Ausführungsform kann eine solche Kopplungsstruktur z. B. ein Converged I/O (konvergierter Eingang/Ausgang, CIO) sein, der für das Tunneling der Kommunikation eines Peripheral Component Interconnect Express (PCIe)-Protokolls gemäß PCI Express^TM-Spezifikation (Base Specification Version 2.0, herausgegeben am 17. Januar 2007) (hiernach als PCIe^TM-Spezifikation beschrieben) oder eines anderen Protokolls sowie anderer Protokolle verwendet werden kann. Für den CIO wird ein Großteil des PCIe-Hardwarestapels direkt implementiert, was Vorteile in Bezug auf Softwarekompatibilität, Leistung und Markteinführungszeit bringt. Das heißt, dass beim Low-Level-Tunneling der Großteil des getunnelten Protokollstapels implementiert wird. Beim High-Level-Tunneling dagegen wird die Softwarearchitektur erhalten, jedoch nicht unbedingt unter Verwendung des Paket-, Verschlüsselungs- oder Wire-Protokollmechanismus vom getunnelten Protokoll. Durch dieses Low-Level-Tunneling können Pakete des PCIe-Protokollstapels durch die CIO-Kopplungsstruktur getunnelt werden, z. B. durch Anpassung eines CIO-Headers an die Tunneling-Pakete. Wenn ein solches gesendetes, getunneltes Paket in einem Empfänger empfangen wird, kann der CIO-Protokollstapel des Empfängers den Header entschlüsseln und die PCIe-Pakete an einen entsprechenden PCIe-Protokollstapel des Empfängers weiterleiten.
Ein solcher Ansatz für eine konvergierte Kopplungsstruktur führt jedoch über dieses Low-Level-Tunneling zu einem Problem, im Gegensatz zu Tunneling-Protokollen, die auf höheren Levels der Abstraktion stattfinden. Dabei handelt es sich oft um Einschränkungen, zum Teil auch implizite Einschränkungen, der Protokollzeitsteuerung, die in einer nicht-getunnelten nativen Instanzierung des Kopplungsstrukturprotokolls trivial gelöst werden, aber beim Tunneling des Kopplungsstrukturprotokolls schwieriger zu handhaben sein können, da durch die für das Tunneling verwendete Kopplungsstruktur Verzögerungen eingeleitet werden. Diese Verzögerungen können von der Tunneling-Kopplungsstruktur selbst oder durch den Verkehr von anderen getunnelten Protokollen verursacht werden.
Ausführungsformen bieten einen Mechanismus für das Management expliziter und impliziter Zeitgeber eines getunnelten Protokolls beim Tunneling über eine Tunneling-Kopplungsstruktur. Während in einer hier beschriebenen Ausführungsform ein Beispiel eines getunnelten PCIe-Protokolls über einem CIO verwendet wird, ist es offenbar, dass der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt ist, und dass die gleichen Grundsätze auf andere getunnelte Kopplungsstrukturen sowie andere zum Tunneling verwendete Kopplungsstrukturen, einschließlich festverdrahtete und drahtlose Kopplungsstrukturen, anwendbar sind.
Die Zeitsteuerungsanforderungen einer Kopplungsstruktur, sowohl explizit als auch implizit, können in zwei Hauptkategorien unterteilt werden, die hiernach als Link- und Wallclock-Zeitanforderungen beschrieben werden. Link-Zeitsteuerungsanforderungen sind mit niedrigeren Levels verbunden, z. B. mit Linkprotokollen, und sie existieren generell, um reibungslose Linkoperationen zu gewährleisten und manuell definierte Spezialfalle (sog. Corner Cases) bei der Validierung minimal zu halten. Wallclock-Zeitsteuerungsanforderungen stehen mit Ereignissen in Verbindung, die auf höheren Levels zu beobachten sind, z. B. auf Ebene des Betriebssystems (OS) und der Anwendungssoftware. Link-Zeitsteuerungsanforderungen können durch die durch das Protokoll-Tunneling verursachten Verzögerungen direkt beeinflusst werden und diese Anforderungen werden bei den Ausführungsformen angesprochen. Link-Zeitsteuerungsanforderungen können sich in der Größenordnung von weniger als ca. 10 Mikrosekunden (μs) bewegen, während Wallclock-Zeitsteuerungsanforderungen mehr als ca. 10 Mikrosekunden (μs) sind. Wallclock-Anforderungen werden durch Protokoll-Tunneling nicht fundamental beeinflusst, da sie generell mit Zeitwerten in Verbindung stehen, die lang genug sind (z. B. Millisekunden, ms), um von den durch das Protokoll-Tunneling verursachten relativ kurzen Verzögerungen (z. B. Mikrosekunden) nicht betroffen zu werden, und weiter sind diese Anforderungen mit Eigenschaften verbunden, wie z. B. das Verhindern von für den Benutzer sichtbaren Verzögerungen der Anwendungssoftware, was gleichermaßen wünschenswert ist, unabhängig von den Hardwaremechanismen (nativ gegenüber getunnelt), die zum Vermitteln eines bestimmten Kopplungsstrukturprotokolls verwendet werden.

In der Tabelle 1 unten sind mehrere mit PCIe verbundene Zeitsteuerungsanforderungen aufgeführt und sie zeigt die Relevanz jeder dieser Anforderungen in Bezug auf diese Beschreibung. Die unter „Beschreibung” aufgeführten Zitate wurden der PCI Express^TM-Spezifikation entnommen. Tabelle 1

Beschreibung	Typ	Anmerkungen
Zeitsteuerung für Übertragung und Wiedergabe der Bestätigung/Nichtbestätigung (Ack/Nak)	Link	Feste Anforderung – Wenn die Zeitanforderungen durch die Tunneling-Kopplungsstruktur nicht erfüllt werden, wird ein (Zufalls-) Fehler ausgelöst
Policy für den Aufruf des Linkzustands Null Standby (L0s): „Anschlüsse ... müssen ihre Senden-Lanes in den L0s-Zustand wechseln, wenn die definierten Ruhebedingungen (unten) für eine Zeitspanne von maximal 7 μs erfüllt sind.”	Link	Löst das Link-Leistungsmanagement aus, wenn der Link nicht gebraucht wird; hier handelt es sich z. B. um einen Fall, bei dem die Zeit entsprechend der Zuordnung der Tunneling-Kopplungsstruktur anstatt der tatsächlich gebrauchten Zeit gemessen wird
Verhandeln des Wechsels in den Linkzustand 1 (L1) – „Die vorgeschaltete Komponente sendet diese DLLP wiederholt mit maximal vier Symbolzeiten für Ruhe”	Link	Eine implizite Zeitsteuerungsanforderung. In diesem Fall wird das Erscheinungsbild des Verkehrs gegenüber dem PCIe-Stapel verwaltet, indem eingefügte Verzögerungen maskiert werden
Aktualisierungen der Flusssteuerung	Link	Richtlinie, keine Anforderung
PCI-Power Management (PM) und Active State Power Management (ASPM): „Beim Verlassen von L1 wird empfohlen, dass die nachgeschaltete Komponente innerhalb von 1 μs ab Verlassen von L1 beginnt, Daten-Link-Layer-Pakete (DLLP) zur Flusssteuerungs-Aktivierung für alle aktivierten virtuellen Kanäle (Virtual Channels, VC) und Flusssteuerungstypen (Flow Control, FC) zu senden.”	Link	Richtlinie, keine Anforderung
L0s/L1 Ausstiegslatenzzeiten	Wallclock	Diese Zeitsteuerungsparameter existieren, um eine Bestimmung der Auswirkung auf den Verkehr über PCIe zu ermöglichen und sind keine fundamentalen PCIe-Linkoperationen
Power-Management-Ereignis (PME) – „Wenn das PME_Status-Bit eines anfragenden Agent nach 100 ms (+50%/–5%) noch nicht geklärt ist, läuft der PME-Service-Timeout-Mechanismus ab und veranlasst dadurch, dass der auf ein PME anfragende Agent die temporär verloren gegangene PM_PME-Nachricht erneut sendet.”	Wallclock	Die Anforderung besteht zur Verhinderung des totalen Verlusts der PME; die bestimmte Zeit wurde gewählt, um zufällige Auslösungen minimal zu halten und sie ist zugleich kurz genug, dass das PME in relativ rechtzeitiger Weise verarbeitet werden kann
Annahmegrenze für gepostete Anfragen von 10 μs	Wallclock	Dient dem Begrenzen der auf Plattformebene beobachtbaren Verzögerungen, die durch einen Stau in der Netzwerkstruktur verursacht werden
Mindesthäufigkeit von Flusssteuerungsaktualisierungen von 30 μs und Aktualisieren der Flusssteuerungspaket-Zeitsteuerung –200 μs	Wallclock	Dient der Begrenzung von Verzögerungen, die durch den Verlust eines Flusssteuerungspakets verursacht werden

Tabelle 1 soll lediglich einige Bespiele von Interesse darstellen, sie ist jedoch in keiner Weise als vollständige Liste aller verwandten Anforderungen im PCIe vorgesehen.
Die Link-Zeitsteuerungsanforderungen werden vom PCIe-Stapel selbst „gemessen”, und wenn sich somit die Zeitansicht des PCIe-Stapels ändert, kann auch die Art, wie diese Zeiten wahrgenommen werden, geändert werden. Um dies zu erreichen, kann ein Mechanismus für die Zeitänderung bereitgestellt werden zusammen mit Hardware, Software oder Firmware, um festzustellen, wann und wie die Stapelzeitsteuerung zu ändern ist.
Der Mechanismus für das Ändern der Zeitansicht des PCI-Stapels kann auf mehrere Weisen ausgeführt werden. Es kann z. B. durch Gating oder Ausschalten der Taktgeber an verschiedene Elemente in der PCIe-Stapellogik geschehen, wobei ein effektiver Zeitstillstand für diese Logik erzielt wird. Dieser Ansatz bietet den zusätzlichen Vorteil einer Reduzierung der Leistungsaufnahme durch die PCIe-Stapellogik, wenn diese nicht gebraucht wird. Bei anderen Ausführungsformen kann ein explizites Steuersignal an die PCIe-Stapellogik hinzugefügt werden, um anzuzeigen, wann die Zeit gemessen werden soll. Generell reicht es jedoch nicht aus, den gesamten Stapel als eine Einheit zu steuern, sondern die Subelemente des Stapels können teilweise unabhängig gesteuert werden, da verschiedene Protokollmechanismen sich unterschiedlich auf verschiedene Logikblöcke auswirken können. Auf ähnliche Weise erfordern nicht alle Kommunikationen eine geänderte Zeitsteuerung, um mit den Link-Zeitsteuerungsanforderungen konform zu sein. Bei einer Ausführungsform kann die Steuerlogik verwendet werden, um zu bestimmen, wann und wie die Zeitansicht des PCIe-Stapels geändert werden soll, und diese Logik kann Teil eines PCIe-Stapels sein.
Es wird Bezug genommen auf 1, in der ein Blockdiagramm zeigt, wie der PCIe-Stapel (und andere getunnelte Protokolle) mit einem geteilten (shared) Tunneling-Link verbunden sind, welcher in einer Ausführungsform ein CIO-Link sein kann. Wie in 1 gezeigt, umfasst ein System 10 einen ersten Stapel 20a und einen zweiten Stapel 20b (allgemein als Protokollstapel 20 bezeichnet). Bei einer Ausführungsform kann der erste Protokollstapel 20a ein PCIe-Stapel sein, während der zweite Protokollstapel 20b ein Universal Serial Bus (USB), eine Display-Kopplungsstruktur oder ein anderer solcher Protokollstapel sein kann. Zur vereinfachten Darstellung werden nur Details des PCIe-Protokollstapels gezeigt. Insbesondere umfasst der Protokollstapel 20a eine Transaktionsschicht 22, eine Datenlinkschicht 24 und eine Schnittstellen- oder Dichtungsschicht 26, welche als Schnittstelle zwischen dem PCIe-Protokoll und dem Tunneling-Protokoll dient. Details zum Betrieb einer solchen Schnittstellenlogik werden unten ausführlicher beschrieben.
Wie weiter in 1 gezeigt, kann eine konvergierte I/O-Schicht zwischen dem ersten und zweiten Protokollstapel 20 und einem Link 70 gekoppelt sein, welcher in einer Ausführungsform ein optischer Link, ein elektrischer Link oder ein anderer solcher Link sein kann. Wie in 1 gezeigt, kann der CIO-Protokollstapel eine CIO-Protokoll-Transportschicht 30, einen logischen Block 40 einer physikalischen Schicht, einen elektrischen Block 50 der physikalischen Schicht und einen optischen Block 60 der physikalischen Schicht umfassen. Auf diese Weise wirken die Blöcke 40–60 als eine geteilte (shared) physikalische Schicht, die von mehreren Protokollen bei der Kommunikation mit der physikalischen Schicht gemeinsam genutzt werden kann, um somit Informationen dieser mehreren Protokolle entlang des Links 70 zu tunneln.
Es wird Bezug genommen auf 2, in der ein System dargestellt ist, das mehrere Kommunikationsstapel aufweist, die an eine geteilte (shared) physikalische Schicht gekoppelt sind. Insbesondere können in 2 neben den PCIe-Senden-(TX)- und Empfangen-(RX)-Stapeln 20a auch mehrere andere Senden- und Empfangen-Stapel 20b–20d vorhanden sein. Wie gezeigt, können zwei Multiplexer 35a und 35b (allgemein als Multiplexer 35 bezeichnet) zwischen diesen Stapeln und einer geteilten (shared) physikalischen Schicht 40–60 gekoppelt sein. Die Multiplexer 35 können unter der Steuerung einer Protokolltransportschicht-Steuerung 30 betrieben werden. Wie in 2 gezeigt, sind in die CIO-Protokolltransport-(PT)-Schicht 30 Multiplexing (über die Multiplexer 35a und 35b) und Regelmechanismen für das Tunneling von PCIe und anderer Protokolle implementiert. Die PT-Schichtregelung 30 implementiert Zugriffsregelung (Arbitration) für den Sender und Lenkung für den Empfänger, welcher vom Sender unabhängig ist. Während diese Art von Struktur für den Rest der Beschreibung verwendet wird, ist es offenbar, dass Ausführungsformen auch auf andere Arten von Kopplungsstrukturen angewandt werden können, die den Sender und Empfänger anders regeln, z. B. durch Arbitration beider gleichzeitig oder durch Verwendung einer einzelnen bidirektionalen Verbindung.
Bei verschiedenen Ausführungsformen kann die Zeitsteuerung einer Kopplungsstruktur auf verschiedene Weisen verwirklicht werden. Bei verschiedenen Implementierungen kann z. B. eine dynamische späte Bindung eintreten, so dass eine solche Schnittstellenlogik eine Tunneling-Kopplungsstruktur, an die sie gekoppelt wird, dynamisch bestimmen kann, und alle Zeitsteuerungsanforderungen des Protokolls dynamisch regeln kann, um der Tunneling-Kopplungsstruktur zu entsprechen. Bei anderen Ausführungsformen kann ein Designer während der Systementwicklung eine von einem oder mehreren Protokollstapeln verwendete Tunneling-Kopplungsstruktur festlegen, so dass die Link-Zeitsteuerungsanforderungen, die von der Tunneling-Kopplungsstruktur betroffen sind, während des Systemdesigns bestimmt werden können. Somit kann die Logik, z. B. Schnittstellenlogik, zwischen dem Protokollstapel und der Tunneling-Kopplungsstruktur eingebunden werden, um die Zeitsteuerung des Protokollstapels zu regeln, z. B. durch Ändern der Zeitansicht des Protokollstapels, um allen über die Tunneling-Kopplungsstruktur entstehenden zusätzlichen Verzögerungen zu entsprechen.
Es wird Bezug genommen auf 3, die eine Implementierung der früheren Behandlung von Link-Zeitsteuerungsanforderungen zeigt, nämlich eine dynamische späte Bindung, die über die Schnittstellenlogik selbst implementiert werden kann, so dass der Protokollstapel dynamisch an eine geteilte (shared) physikalische Schicht oder andere physikalische Schicht gekoppelt werden kann. Insbesondere zeigt 3 ein Ablaufdiagramm eines Verfahrens 100, das implementiert werden kann z. B. in der Schnittstellenlogik eines Protokollstapels für die Kommunikation zwischen dem Protokollstapel (welcher ein Standardstapel eines gegebenen Protokolls sein kann) und einer gemeinsamen physikalischen Schicht, wie eine konvergierte Kopplungsstruktur, welche Pakete verschiedener Protokolle tunneln kann. Wie in 3 gezeigt, kann das Verfahren 100 mit dem Einholen der Zeitverzögerungsdaten für die Tunneling-Kopplungsstruktur beginnen (Block 110). Es können verschiedene Weisen des Einholen dieser Informationen verwirklicht werden. Bei einer Ausführungsform kann z. B. eine geteilte (shared) physikalische Schicht eine vorbestimmte Liste von Verzögerungsdaten der Schnittstellenlogik bereitstellen. Alternativ kann die Schnittstellenlogik die mit der geteilten (shared) physikalischen Schicht auftretenden Paketkommunikationen analysieren, um die Zeitverzögerungsdaten zu bestimmen. Generell können einige Ausführungsformen die Zeitsteuerungsdaten auf eine vorbestimmte Weise einholen, während diese Daten bei anderen Implementierungen dynamisch berechnet werden können. Für jede Weise sind mehrere Variationen möglich, z. B. Vorbestimmung durch Mensch oder Maschine, oder im berechneten Fall kann die Prüfung einmal durchgeführt oder periodisch wiederholt werden. Es können verschiedene Instanzen solcher Informationen existieren, wobei verschiedene Verzögerungen für verschiedene Arten von Kommunikationen eintreten, ja nachdem welche Kommunikation und Logikeinheiten beteiligt sind.
Unter der weiteren Bezugnahme auf 3 wird die Regelung an Block 120 übergeben, wo die Zeitverzögerungsdaten den Zeitsteuerungsanforderungen des ersten Protokollstapels zugeordnet werden. In einem Beispiel kann ein Protokollstapel variierende Zeitsteuerungsanforderungen in Bezug auf die Linkschicht-Kommunikationen haben, wie oben in Tabelle 1 dargestellt. Die Regelung geht an die Raute 130 weiter, wo bestimmt werden kann, ob eine Zeitsteuerungsansicht oder Ansichten des ersten Protokollstapels aufgrund der Zuordnung geändert werden müssen. Das heißt, dass aufgrund von Latenzzeiten, die in der gemeinsamen physikalischen Schicht vorhanden sein können, einer oder mehrere mit der gegebenen Logik des Protokollstapels verbundene Zeitgeber geregelt werden können, z. B. durch Beschleunigen, Verlangsamen, Deaktivieren usw. Wenn keine solche Änderung der Zeitsteuerungsansicht notwendig ist, wird die Regelung an Block 135 übergeben, wo die Daten unter Verwendung der Standardzeitsteuerung des Protokollstapels gesendet und/oder empfangen werden können.
Unter der weiteren Bezugnahme auf 3 wird stattdessen bei der Feststellung, dass die Zeitsteuerungsansicht geändert werden sollte, die Regelung an Block 140 übergeben, wo die Zeitsteuerung von mindestens einer Stapellogik geregelt werden kann, um die Zeitsteuerung des ersten Protokollstapels zu ändern. Wie erwähnt, kann diese Änderung der Zeitsteuerung durch die Regelung von Zeitgebern, Steuerung der Logik zum Zählen (oder Nicht-Zählen) eines gegebenen Intervalls usw. erfolgen. Nach der Durchführung einer solchen Zeitsteuerungsregelung können die gewünschten Daten unter Verwendung dieser geänderten Protokollstapel-Zeitsteuerung gesendet/empfangen werden (Block 150). Wie weiter in 3 gezeigt, kann dann festgestellt werden, ob eine Kommunikation, d. h. eine gegebene Transaktion durchgeführt wurde (Raute 160). Wenn ja, kann das Verfahren beendet werden. Andernfalls wird die Regelung für mehrere Wiederholungen an die Blöcke 140 und 150 zurückgeführt. Während diese bestimmte Implementierung bei der Ausführungsform nach 3 gezeigt ist, wird jedoch der Umfang der vorliegenden Erfindung in dieser Hinsicht in keiner Weise eingeschränkt.
Bei anderen Implementierungen kann z. B. ein Systemdesign so festgelegt sein, dass ein gegebener Protokollstapel über eine bekannte Tunneling-Kopplungsstruktur, die bekannte Verzögerungen enthält, getunnelt wird. Demgemäß kann im Rahmen des Systemdesigns Logik implementiert werden, welche die Regelung der Zeitsteuerung von verschiedenen Protokolltransaktionen je nach Bedarf behandelt, um jeglichen inhärenten Verzögerungen der Tunneling-Kopplungsstruktur zu entsprechen. Tabelle 1 oben zeigt Beispiele solcher Linkschicht-Zeitsteuerungsanforderungen.
Es wird Bezug genommen auf 4, die ein Ablaufdiagramm eines Verfahrens zum Betrieb einer Schnittstelle eines Protokollstapels gemäß einer weiteren Ausführungsform der vorliegenden Erfindung zeigt. Wie in 4 gezeigt, kann das Verfahren 200 durch eine Schnittstellenlogik, welche die Zeitsteuerungsansicht eines Protokollstapels je nach Bedarf auf Basis von statischen Designparametern ändern kann, implementiert werden. Wie in 4 gezeigt, kann das Verfahren 200 durch das Empfangen einer Kommunikation an/von einer Tunneling-Kopplungsstruktur (Block 205) beginnen. Diese Kommunikation wird somit in der Schnittstellenlogik des Protokollstapels in abgehender oder ankommender Richtung empfangen. Verschiedene Kommunikationsarten können in der Schnittstellenlogik behandelt werden, u. a. das Senden und Empfangen von Datenpaketen sowie von verschiedenen Protokollpaketen, wie z. B. Bestätigungen, Steuerpakete wie z. B. für das Leistungsmanagement, die Flusssteuerung usw.
Basierend auf dem Pakettyp kann in der Schnittstellenlogik bestimmt werden, ob eine gegebene Kommunikationsart einer geänderten Zeitsteuerung unterliegt (Raute 210). Die Schnittstellenlogik kann z. B. eine Tabelle enthalten oder mit ihr verbunden sein (z. B. in einem nichtflüchtigen Speicher), in der Transaktionstypen identifiziert werden und festgestellt wird, ob eine Zeitsteuerungsansicht des Protokollstapels für diesen Kommunikationstyp geändert werden sollte, und die anzeigt, welche Verzögerung anwendbar ist sowie eine Anweisung oder eine andere Kennung der Art der Regelungsmaßnahme, die von der Schnittstellenlogik angewandt werden soll, um die Zeitsteuerung entsprechend zu ändern. Dabei können mehrere Teile in der Tabelle vorhanden sein, wobei jeder Teil mit einem gegebenen Stapel verbunden ist, so dass jeder Teil die Zuordnungen für eine dedizierte Stapel-Tunneling-Kopplungsstruktur-Beziehung bietet.
Unter der weiteren Bezugnahme auf 4, kann, wenn keine Änderung notwendig ist, die normale Zeitsteuerung des Protokollstapels zum Behandeln der Kommunikation verwendet werden, und die Daten können somit unter Verwendung der normalen Zeitsteuerung des Protokollstapels gesendet/empfangen werden (Block 220). Wird stattdessen festgestellt, dass die Zeitsteuerungsansicht geändert werden sollte, wird die Regelung an Block 230 übergeben, wo die Zeitsteuerung von mindestens einer Stapellogik geregelt werden kann, um deren Zeitsteuerung zu ändern. Dann können die gewünschten Daten unter Verwendung der geänderten Protokollstapel-Zeitsteuerung gesendet/empfangen werden (Block 240). Wie weiter in 4 gezeigt, kann dann festgestellt werden, ob eine Kommunikation, d. h. eine gegebene Transaktion durchgeführt wurde (Raute 260). Wenn ja, kann das Verfahren beendet werden. Andernfalls wird die Regelung für mehrere Wiederholungen an die Blöcke 230 und 240 zurückgeführt. Damit kann die statische Regelung der Behandlung von Link-Zeitsteuerungsanforderungen umgesetzt werden.
Wie in den obigen 3 und 4 gezeigt, kann die Zeitsteuerungsregelung für bestimmte Kommunikationstypen geändert werden, während andere Kommunikationstypen gemäß ihrer normalen Protokollzeitsteuerung ohne jegliche Änderungen fortfahren können. In der folgenden Beschreibung sind einige Beispiele von Situationen aufgeführt, bei denen die Zeitsteuerung eines Protokollstapels geändert werden kann, um den Link-Zeitsteuerungsanforderungen zu entsprechen.
Bei einer Ausführungsform kann die PT-Schichtsteuerung 30 Sender-„Slots” bereitstellen, die der PCIe zugeordnet werden, die jedoch für andere Verkehrstypen verwendet werden können, wenn kein PCIe-Verkehr zum Senden vorhanden ist. Somit kann ein für einen ersten Protokollstapel zugeordneter Slot von einem anderen Protokollstapel verwendet werden, wenn der erste Protokollstapel nichts zu senden hat. Auf gleiche Weise kann es an einem Empfänger Zeiten geben, wo PCIe-Verkehr empfangen würde, aber die andere Komponente hat entweder keinen zu versendenden PCIe-Verkehr oder eine andere Art von Verkehr hoher Priorität, und der Empfänger empfängt in dieser Zeit keinen PCIe-Verkehr.
Für ein korrektes Vermitteln des Begriffs „PCIe-Zeit” zum PCIe-Stapel können die Empfangs- und Sendezeiten eher unabhängig betrachtet werden. In einigen Fällen, die in Tabelle 1 beschrieben sind, wie L0s Aufruf-Policy und die „Beim Verlassen von L1...”-Anforderungen, wird die Zeit nur aus einer Sicht (in diesen Fällen aus Sicht des Senders) gemessen.
Jedoch beim Ack/Nak-Protokoll müssen beide Ansichten, die des Empfängen und des Senders, in Betracht gezogen werden. Die Ansicht des PCIe-Senders der Sendezeit eines Transaktionsschichtpakets (TLP) kann falsch sein, wenn eine bestimmte Latenzzeit für den Transport durch die Übertragungspipeline angenommen wird, die auf einem physikalischen PCIe-Anschluss basiert, wenn die CIO-Sendepipeline eine andere Verzögerung hat. Die andere Komponente (d. h. der Empfänger) kann nur reagieren, wenn seinem PCIe-Stapel auf dem geteilten Link PCIe-Zeit zugeordnet wurde, was vom Empfänger so gesehen wird, dass seine Zeitansicht (die des Empfängers) justiert werden muss. Angenommen der PCIe-Stapel erwartet eine Verzögerung in der Übertragungspipeline von 50 Nanosekunden (ns), doch der CIO-Link stellt eine Verzögerung in der Übertragungspipeline von 70 ns bereit. In diesem Fall wäre es notwendig, die Zeitansicht des Senders zu verzögern oder anderweitig um 20 ns zu justieren (für Protokollaspekte, die von der Kenntnis dieser Verzögerung abhängen), um den Unterschied auszugleichen. Somit wartet ein Sender ein entsprechendes Zeitintervall auf ein ACK-Signal von einem Empfänger (welches durch die geteilte physikalische Schicht verzögert werden kann), damit kein unrichtiges Fehlersignal erhoben wird.
Für einen Empfänger muss die zugeordnete Zeit (nicht die gebrauchte Zeit) berücksichtigt werden, die der Sender der anderen Komponente für den PCIe bereitgestellt hat. In einigen Fällen ist dies dem Empfänger direkt bekannt, doch in anderen Fällen kann ein Tunneling-Protokollmechanismus bereitgestellt werden, z. B. eine Nachricht, um anzugeben, wie weit der Empfänger der anderen Komponente seine Zeitansicht für jedes getunnelte Protokoll vorrücken sollte. Wenn z. B. zwei 100-ns-Slots einem PCIe-Sender zugeordnet sind, doch wegen fehlendem PCIe-Sendeverkehr nur einer vom Sender verwendet wird, muss der Empfänger 200 ns der Zeit berücksichtigen. Wenn somit die andere Komponente eine Zeitsteuerungsregel verletzt, indem sie einen zum Senden verfügbaren Slot nicht benutzt, ist diese Verletzung für den Empfänger sichtbar. Das wäre jedoch nicht der Fall, wenn nur die verwendeten (gegenüber den zugeordneten) Sende-Slots berücksichtigt werden.
Es ist zu beachten, dass für bestimmte Protokolle viele verschiedene Optimierungen möglich sein könnten. Bekannter Bandbreitenverkehr könnte z. B. unter Verwendung eines Zählermechanismus berücksichtigt werden, ohne Rücksicht auf die tatsächlich gewährte Link-Arbitration. Wenn ein Protokoll Empfangen- und Senden-Zuordnungen bat, die garantiert gleich sind, ist es möglich nur eine zu berücksichtigen (z. B. den Sender) mit dem Verständnis, dass die andere Zeitansicht (die des Empfängers) übereinstimmen muss.
Wie bereits erwähnt, sind die Ausführungsformen in keiner Weise von den Besonderheiten des CIO oder PCIe abhängig und können für andere getunnelte Protokolle gelten, z. B. für Display, USB, Netzwerk usw. Ausführungsformen gelten auch für andere Tunneling-Protokolle/-Umfelder, z. B. Tunneling-PCIe über eine drahtgebundene oder drahtlose USB-Kopplungsstruktur.
Durch die Ausführung des Tunneling gemäß einer Ausführungsform der vorliegenden Erfindung kann eine größere Anzahl bestimmter I/O-Anwendungen von einem gemeinsamen Satz einer generischeren Hardware erfüllt werden. Eine Plattform kann z. B. 12 USB-Anschlüsse, 8 PCIe-Anschlüsse und verschiedene Anschlüsse für einen speziellen Zweck (z. B. Display) umfassen. Durch Tunneling können diese Anschlüsse konvergiert werden, z. B. in einen Satz 16 konvergierter Anschlüsse, von denen jeder als einer (oder mehrere) der älteren Anschlüsse verwendet werden kann.
Ausführungsformen können in vielen verschiedenen Arten von Systemen implementiert werden. Es wird Bezug genommen auf 5, die ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung zeigt, das Einheiten umfasst, die über eine Tunneling-Kopplungsstruktur, die ein serieller Link ist, an einen Controller-Hub gekoppelt sind. Das System 300 umfasst einen Prozessor 305 und einen Systemspeicher 310, die an einen Controller-Hub 315 gekoppelt sind. Der Prozessor 305 enthält beliebige Verarbeitungselemente, wie z. B. einen Mikroprozessor, einen Hostprozessor, einen eingebetteten Prozessor, einen Koprozessor oder anderen Prozessor. Der Prozessor 305 ist über einen Front-Side-Bus (FSB) 306 an den Controller-Hub 315 gekoppelt. Bei einer Ausführungsform ist der FSB 306 eine serielle Punkt-zu-Punkt-(PtP)-Kopplungsstruktur.
Der Systemspeicher 310 umfasst eine beliebige Speichereinheit, wie einen Raudom Access Memory (RAM), nichtflüchtigen (Non-Volatile, NV) Speicher oder anderen Speicher, der für die Komponenten des Systems 300 zugänglich ist. Der Systemspeicher 310 ist über eine Speicherschnittstelle 316 an den Controller-Hub 315 gekoppelt.
Bei einer Ausführungsform ist der Controller-Hub 315 ein Root-Hub oder Root-Controller in einer PCIe-Kopplungsstrukturhierarchie. Beispiele eines Controller-Hubs 315 sind u. a. ein Chipsatz, ein Memory-Controller-Hub (MCH), ein Northbridge, ein Input/Output-Controller-Hub (ICH), ein Southbridge und ein Root-Controller/Hub. Hier ist der Controller-Hub 315 durch einen seriellen Link 319 an einen Switch/eine Brücke 320 gekoppelt. Die I/O-Module 317 und 321, die auch als Schnittstellen/Anschlüsse 317 und 321 bezeichnet werden können, umfassen/implementieren einen mehrschichtigen Protokollstapel zum Bereitstellen der Kommunikation zwischen Controller-Hub 315 und Switch 320. Bei einer Ausführungsform können mehrere Einheiten an den Switch 320 gekoppelt werden.
Der Switch 320 leitet Pakete/Nachrichten von einer Einheit 325 stromaufwärts, d. h. in einer Hierarchie nach oben zum Controller-Hub 315, und stromabwärts, d. h. in einer Hierarchie nach unten vom Controller-Hub 315 weg zur Einheit 325. I/O-Module 322 und 326 implementieren einen mehrschichtigen Protokollstapel zum Kommunizieren zwischen Switch 320 und Einheit 325. Bei einer Ausführungsform kann das I/O-Modul 326 eine tunnelnde physikalische Schicht zum Tunneln der Pakete von mehreren Protokollstapeln, namentlich Stapel 327 und 328, sein. Die Einheit 325 umfasst eine interne oder externe Einheit oder Komponente, die an ein elektronisches System gekoppelt wird, z. B. an ein I/O-Gerät, einen Netzwerk-Interface-Controller (NIC), eine Add-in-Karte, einen Audioprozessor, einen Netzwerkprozessor, ein Festplattenlaufwerk, ein Speichergerät, einen Monitor, einen Drucker, eine Maus, eine Tastatur, einen Router, ein tragbares Speichergerät, ein Firewire, einen Universal Serial Bus (USB), einen Scanner und andere Eingabe-/Ausgabegeräte.
Ein Grafikbeschleuniger 330 ist ebenfalls durch einen seriellen Link 332 an den Controller-Hub 315 gekoppelt. Bei einer Ausführungsform ist der Grafikbeschleuniger 330 an einen MCH gekoppelt, der an einen ICH gekoppelt ist. Switch 320 und demgemäß I/O-Gerät 325 sind dann an den ICH gekoppelt. Die I/O-Module 331 und 318 implementieren auch einen mehrschichtigen Protokollstapel zum Kommunizieren zwischen dem Grafikbeschleuniger 330 und dem Controller-Hub 315.
Ausführungsformen können als Code implementiert und auf einem Speichermedium gespeichert werden, das Anweisungen enthält, die zum Programmieren eines Systems für die Ausführung der Anweisungen verwendet werden können. Das Speichermedium kann u. a. ohne Einschränkung jede Art von Disks umfassen, u. a. Floppy Disks, Optische Disks, Compact Disk Read-Only Memories (CD-ROMs), Compact Disk Rewritables (CD-RWs) und magnetoptische Disks (MO), elektronische Baugruppen wie Read-Only Memories (ROMs), Random Access Memories (RAMs) wie dynamische Random Access Memories (DRAMs), statische Random Access Memories (SRAMs), Erasable Programmable Read-Only Memories (EPROMs), Flash Memories, Electrically Erasable Programmable Read-Only Memories (EEPROMs), magnetische oder optische Karten oder jede andere Art von Speichermedium, das sich für die Speicherung von elektronischen Anweisungen eignet.
Während die vorliegende Erfindung unter Verwendung einer begrenzten Anzahl von Ausführungsformen beschrieben wird, sind sich fachkundige Personen bewusst, dass viele weitere Modifizierungen und Varianten möglich sind. Die beigefügten Ansprüche sollen alle Modifizierungen und Varianten im Rahmen des wahren Gedankens und Umfangs der vorliegenden Erfindung abdecken.

Claims

Vorrichtung, die aufweist: einen ersten Protokollstapel zum Behandeln der Daten gemäß einem ersten Protokoll, wobei der erste Protokollstapel eine Schnittstellenlogik für das Verbinden des ersten Protokollstapels mit einer Tunneling-Kopplungsstruktur umfasst; und die Tunneling-Kopplungsstruktur den ersten Protokollstapel an einen Link koppelt und eine damit verbundene Zeitverzögerung aufweist, wobei die Schnittstellenlogik die mit der Zeitverzögerung verbundenen Zeitverzögerungsdaten von der Tunneling-Kopplungsstruktur erhält, die Zeitverzögerungsdaten einer Zeitsteuerungsanforderung von mindestens einer Stapellogik des ersten Protokollstapels zuordnet, bestimmt, ob eine Zeitsteuerungsansicht des ersten Protokollstapels auf Basis von mindestens einem Teil der Zuordnung geändert werden soll und mindestens einen Zeitgeber des ersten Protokollstapels basierend auf mindestens einem Teil der Bestimmung ändert.
Vorrichtung nach Anspruch 1, bei der die Schnittstellenlogik die Zeitverzögerungsdaten dynamisch der Zeitanforderung zuordnet, wobei der erste Protokollstapel dynamisch an die Tunneling-Kopplungsstruktur oder an eine zweite physikalische Schicht gebunden werden kann.
Vorrichtung nach Anspruch 1, bei der die Schnittstellenlogik einen ersten Taktgeber des ersten Protokollstapels für eine vorbestimmte Zeit deaktiviert und der erste Taktgeber ein erstes Taktsignal an eine erste Stapellogik liefert, so dass die erste Stapellogik eine Link-Zeitsteuerungsanforderung des ersten Protokolls erfüllt.
Vorrichtung nach Anspruch 3, bei der die Tunneling-Kopplungsstruktur Pakete des ersten Protokolls über ein Protokoll der Tunneling-Kopplungsstruktur an den Link tunnelt.
Vorrichtung nach Anspruch 1, bei der der Link eine konvergierte Kopplungsstruktur ist, die vom ersten Protokollstapel und einem zweiten Protokollstapel geteilt wird, wobei der erste Protokollstapel ein Peripheral Component Interconnect Express^TM-(PCIe)-Stapel ist.
Vorrichtung nach Anspruch 5, bei der die Tunneling-Kopplungsstruktur den ersten und zweiten Slot dem ersten Protokollstapel und einen dritten Slot dem zweiten Protokollstapel zuordnet.
Vorrichtung nach Anspruch 6, die weiter einen Empfänger umfasst, der an den Link gekoppelt ist, um die getunnelten Pakete zu empfangen, wobei der Empfänger den zugeordneten ersten und zweiten Slots über eine an den Link gekoppelte Schnittstellenlogik berücksichtigt.
Verfahren, das umfasst: Empfangen einer Kommunikation in einer Schnittstellenlogik eines ersten Protokollstapels, der an eine Tunneling-Kopplungsstruktur gekoppelt ist; Bestimmen, ob ein Kommunikationstyp der Kommunikation einer geänderten Zeitsteuerung unterliegt, um eine mit der Tunneling-Kopplungsstruktur verbundene Verzögerung zu ermöglichen; Justieren der Zeitsteuerung von mindestens einer Stapellogik des ersten Protokollstapels, um die Verzögerung zu ermöglichen; und Behandeln der Kommunikation im ersten Protokollstapel unter Verwendung der justierten Zeitsteuerung.
Verfahren nach Anspruch 8, das weiter den Zugriff auf eine Tabelle basierend auf dem Kommunikationstyp umfasst, um Zeitverzögerungsdaten für die mit dem Kommunikationstyp verbundene Tunneling-Kopplungsstruktur zu erhalten.
Verfahren nach Anspruch 9, bei dem die Tabelle in einem nichtflüchtigen Speicher gespeichert ist und einen ersten Teil umfasst, der Zuordnungen zwischen der Tunneling-Kopplungsstruktur und dem ersten Protokollstapel enthält, und einen zweiten Teil, der Zuordnungen zwischen der Tunneling-Kopplungsstruktur und einem zweiten an die Tunneling-Kopplungsstruktur gekoppelten Protokollstapel enthält.
Verfahren nach Anspruch 10, das weiter das Teilen (Sharing) der Tunneling-Kopplungsstruktur zwischen dem ersten Protokollstapel und dem zweiten Protokollstapel umfasst, und das einen Slot des ersten Protokollstapels dem zweiten Protokollstapel bereitstellt, wenn der erste Protokollstapel während des Slots keine zu kommunizierenden Daten hat.
Verfahren nach Anspruch 8, bei dem die Zeitsteuerung von mindestens einer Stapellogik durch Ausschalten eines Taktgebers, der mindestens an eine Stapellogik gekoppelt ist, justiert wird.
Verfahren nach Anspruch 12, das weiter das Verzögern eines Taktgebers für eine zweite Stapellogik umfasst, das zumindest teilweise auf der Verzögerung basiert.
Verfahren nach Anspruch 13, das weiter ein Verzögern des Taktgebers umfasst, um zu verhindern, dass ein Fehlersignal den Nicht-Empfang einer Bestätigung von einem Empfänger anzeigt, bis eine vorbestimmte Zeit abgelaufen ist.
System, das aufweist: einen Sender, der eine physikalische Schicht enthält, die an einen Link gekoppelt ist, und einen Protokollstapel, der an die physikalische Schicht gekoppelt ist; einen Empfänger, der über den Link an den Sender gekoppelt ist und einen ersten Protokollstapel umfasst zum Behandeln der Daten gemäß einem ersten Protokoll, wobei der erste Protokollstapel eine erste Schnittstellenlogik umfasst zum Verbinden des ersten Protokollstapels mit dem Link über eine tunnelnde physikalische Schicht, mit der eine Zeitverzögerung verbunden ist, wobei die erste Schnittstellenlogik mindestens eine erste Stapellogik des ersten Protokollstapels zumindest teilweise basierend auf der Zeitverzögerung ändert; und einen dynamischen Random Access Memory (DRAM), der an den Empfänger gekoppelt ist.
System nach Anspruch 15, bei dem der Empfänger weiter einen zweiten Protokollstapel zum Behandeln der Daten gemäß einem zweiten Protokoll umfasst, wobei der zweite Protokollstapel eine zweite Schnittstellenlogik zum Ändern der Zeitsteuerung von mindestens einer zweiten Stapellogik des zweiten Protokollstapels zumindest teilweise basierend auf der Zeitverzögerung enthält.
System nach Anspruch 16, bei dem die tunnelnde physikalische Schicht einen Controller enthält, um den ersten Protokollstapel oder den zweiten Protokollstapel zum Empfangen der vom Sender empfangenen Pakete zu wählen.
System nach Anspruch 15, bei dem die erste Schnittstellenlogik bestimmt, ob ein Kommunikationstyp eines über die tunnelnde physikalische Schicht vom Sender empfangenen Pakets einer geänderten Zeitsteuerung unterliegt, basierend zumindest teilweise auf einer Tabelle zum Einholen der Zeitverzögerungsdaten für die mit dem Kommunikationstyp verbundene tunnelnde physikalische Schicht.