DE102005009542A1 - Virtuelle-Busschnittstelle-Herstellung von Anfangsblock-Typ-Feldern aus Daten-Typ-Feldern - Google Patents

Virtuelle-Busschnittstelle-Herstellung von Anfangsblock-Typ-Feldern aus Daten-Typ-Feldern Download PDF

Info

Publication number
DE102005009542A1
DE102005009542A1 DE102005009542A DE102005009542A DE102005009542A1 DE 102005009542 A1 DE102005009542 A1 DE 102005009542A1 DE 102005009542 A DE102005009542 A DE 102005009542A DE 102005009542 A DE102005009542 A DE 102005009542A DE 102005009542 A1 DE102005009542 A1 DE 102005009542A1
Authority
DE
Germany
Prior art keywords
point
transaction
type
data
bus
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102005009542A
Other languages
English (en)
Inventor
Zachary Steven Fort Collins Smith
John Warren Laporte Maly
Ryan Clarence Loveland Thompson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of DE102005009542A1 publication Critical patent/DE102005009542A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/42Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4265Bus transfer protocol, e.g. handshake; Synchronisation on a point to point bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Information Transfer Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Systeme, Methoden, Medien und andere Ausführungsbeispiele, die einem System zum Erzeugen eines Bus-Typ-Anfangsblock-Typ-Feldes aus einem Punkt-zu-Punkt-Datentyp-Feld zugeordnet sind, werden beschrieben. Ein beispielhaftes Systemausführungsbeispiel umfasst eine Logik, die konfiguriert ist, um zu identifizieren, dass eine Punkt-zu-Punkt-Transaktion Nichtspeicherdateninformationen, die in einem Daten-Flit codiert sind, eine Logik, die konfiguriert ist, um die Nichtspeicherdateninformationen aus dem Daten-Flit zu extrahieren, und eine Logik umfasst, die konfiguriert ist, um ein Anfangsblock-Typ-Feld für eine Bus-Typ-Transaktion zu erzeugen, die durch die virtuelle Busschnittstelle aus der Punkt-zu-Punkt-Transaktion erzeugt wird.

Description

  • Computersysteme können Computerkomponenten umfassen, die wirksam miteinander z. B. durch einen Bus und/oder ein Tor(e) in Punkt-zu-Punkt-Verknüpfungen (P2P-Verknüpfungen) verbunden sind. Komponenten, die wirksam durch einen Bus verbunden sind, „hören" im Wesentlichen auf jede Anforderung, die auf dem Bus platziert wird, und „hören" im Wesentlichen jede Antwort auf dem Bus. Um das Hören, Zuhören und ähnliches zu erleichtern, sind verschiedene Buskommunikationstechniken, Zeitgebungen, Protokolle, Transaktionsformate, Paketformate usw. entstanden. Somit kann eine Transaktion, wie z. B. Daten, die in ein Busmodellsystem gelesen werden, das Erzeugen und Überwachen verschiedener Phasen (z. B. Zuteilung, Anforderungen, Schnüffeln, Daten) und das Senden/Empfangen verschiedener Pakete aus Informationen während dieser Phasen umfassen. Die Pakete können z. B. Anfangsblockabschnitte und Datenabschnitte umfassen.
  • Systeme, deren Computerkomponenten wirksam durch P2P-Verknüpfungen verbunden sind, können wesentlich unterschiedlich zu jenen wirken, deren Komponenten durch einen Bus verbunden sind. Es können Pakete vorliegen, die P2P-Verknüpfungsnetzwerken zugeordnet sind, die nicht direkt Paketen entsprechen, die Bus-Typ-Systemen zugeordnet sind. Auf ähnliche Weise können Informationen, die als Daten in einem System übertragen werden können (z. B. P2P), als Anfangsblockinformationen in dem anderen System (z. B. Bus) behandelt werden. Bei einem P2P-System kann eine Transaktion (z. B. Daten lesen) durchgeführt werden, durch Senden und Empfangen von Paketen und/oder Flits zwischen verschiedenen Quell- und Zielkomponenten. Üblicherweise umfasst ein P2P-Paket eines oder mehrere Anfangsblockflits und Datenflits. Die Datenflits speichern üblicherweise tatsächli che Datenwerte aus einem Computerspeicher, aber in manchen Fällen können andere Informationen als Datenwerte in einem oder mehreren Datenflits codiert sein. Zum Beispiel können Anfangsblockinformationen, die einen P2P-Paketanfangsblock überschwemmen können, in einem oder mehreren Datenflits gespeichert werden.
  • In Umgebungen, wie einer Prozessorverifikation und einer Hybridmultiverarbeitung, können einige Komponenten durch einen Bus verbunden sein, wie z. B. einen Front-Side-Bus (FSB), und andere Komponenten können durch P2P-Verknüpfungen verbunden sein. FSB-verbundene Systeme führen bestimmte Aktionen auf bestimmte Weisen aus. Zum Beispiel können Nachrichten, die für eine Komponente vorgesehen sind, auf dem FSB rundgesendet werden, durch alle Komponenten empfangen werden, die wirksam mit dem FSB verbunden sind, und durch Zielkomponenten bearbeitet werden. P2P-verknüpfungsverbundene Komponenten führen bestimmte Aktionen auf bestimmte andere Weisen aus. Zum Beispiel können Pakete zwischen spezifischen Komponenten mit einem Kreuzschienen-„Verkehrspolizisten" übertragen werden, der zum Leiten von Paketen/Flits verantwortlich ist. Da sowohl FSB-Verbindungen als auch P2P-Verbindungen Stärken und Schwächen aufweisen, ist es nicht überraschend, dass einige Computersysteme FSB-verbunden sind, während andere P2P-konfiguriert sind. Bei einigen Beispielen kann ein Mehrfachprozessorsystem oder ein anderes Rechensystem sogar Computerkomponenten umfassen, die unter Verwendung beider Verfahren verbunden sind.
  • Werkzeuge zum Entwerfen, Analysieren, Testen usw. von Systemen wurden entwickelt, die ein Busmodell zum Verbinden von Komponenten verwenden. Andere Werkzeuge zum Entwerfen, Analysieren, Testen usw. von Systemen wurden entwickelt, die ein P2P-Modell zum Verbinden von Komponenten verwenden. Da die zwei Systeme grundlegend unterschiedlich sind, wurde ein Werkzeug bzw. Tool, das als eine virtuelle Busschnittstelle (VBI; VBI = virtual bus interface) bekannt ist, entwickelt, um das Erzeugen von Bus-Typ-Transaktionen aus P2P-Transaktionen zu ermöglichen. Dies kann wiederum eine Kommunikation zwischen Systemen ermöglichen, die ein Busmodell verwenden, und Systemen, die ein P2P-Modell verwenden, und/oder das Korrelieren von Ergebnissen aus unterschiedlichen Werkzeugen. Aber, wie oben beschrieben wurde, unterscheidet sich die konzeptionelle und logische Struktur von P2P-Transaktionen grundlegend von der von Bustransaktionen. Zum Beispiel, was bei einem Modell ein Anfangsblockfeld ist, kann bei einem anderen Modell ein Datenfeld sein und umgekehrt. In manchen Fällen können Daten, die zu umfassend waren, um in einem Anfangsblock vorzuliegen, bei einer Transaktion von einem Modell bequem in einen Anfangsblock bei einer Transaktion von einem anderen Modell einpassen. In anderen Fällen werden Informationen, die in einem P2P-System (z. B. Nichtspeicherdatenbitfelder) in einem Daten-Flit gespeichert sind, in einem Bussystem vielleicht nicht als Daten betrachtet.
  • Es ist die Aufgabe der vorliegenden Erfindung, ein System, das konfiguriert ist, um mit einer virtuellen Busschnittstelle zu interagieren, ein Virtuelle-Busschnittstelle-System, einen Computer, der mit einem Virtuelle-Busschnittstelle-System konfiguriert ist, ein Verfahren, ein computerlesbares Medium, ein System und einen Satz von Anwendungsprogrammierungsschnittstellen mit verbesserten Charakteristika zu schaffen.
  • Diese Aufgabe wird durch ein System gemäß Anspruch 1, ein Virtuelle-Busschnittstelle-System gemäß Anspruch 6, einen Computer gemäß Anspruch 11, ein Verfahren gemäß Anspruch 12, ein computerlesbares Medium gemäß Anspruch 16, ein System gemäß Anspruch 17 und einen Satz von Anwendungsprogrammierungsschnittstellen gemäß Anspruch 18 gelöst.
  • Die beiliegenden Zeichnungen, die umfasst sind und einen Teil der Beschreibung bilden, stellen verschiedene Beispielssysteme, Verfahren usw. dar, die verschiedene Ausfüh rungsbeispiele von Aspekten der Erfindung darstellen. Es wird darauf hingewiesen, dass die dargestellten Elementgrenzen (z. B. Kästen, Gruppen von Kästen oder andere Formen) in den Figuren ein Beispiel der Grenzen darstellen. Ein Durchschnittsfachmann auf dem Gebiet wird erkennen, dass ein Element als mehrere Elemente entworfen werden kann oder dass mehrere Elemente als ein Element entworfen werden können. Ein Element, das als eine interne Komponente eines anderen Elements gezeigt ist, kann als eine externe Komponente implementiert werden und umgekehrt. Ferner sind die Elemente möglicherweise nicht maßstabsgetreu.
  • Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
  • 1 ein System basierend auf einer beispielhaften virtuellen Busschnittstelle, zum Erzeugen eines Busmodell-Anfangsblocktyp-Feldes von einem Punkt-zu-Punkt-Modell-Datentypfeld;
  • 2 ein anderes Beispiel eines Systems basierend auf einer virtuellen Busschnittstelle zum Erzeugen eines Busmodell-Anfangsblocktyp-Feldes von einem Punkt-zu-Punkt-Modell-Datentypfeld;
  • 3 ein Beispielverfahren zum Erzeugen eines Busmodell-Anfangsblocktyp-Feldes von einem Punkt-zu-Punkt-Modell-Datentypfeld;
  • 4 ein anderes Beispielverfahren zum Erzeugen eines Busmodell-Anfangsblocktyp-Feldes aus einem Punkt-zu-Punkt-Modell-Datentypfeld;
  • 5 zwei Beispielsätze eines P2P-Transaktionsanfangsblocks und Daten-Flits, die in Busmodelltransaktionen verarbeitet werden;
  • 6 eine Beispielrechenumgebung, in der Beispielsysteme und Verfahren arbeiten können, die hierin dargestellt sind;
  • 7 eine beispielhafte Anwendungsprogrammierungsschnittstelle (API; API = application programming interface); und
  • 8 ein beispielhaftes Mehrfachverarbeitungssystem.
  • Beispiel-Systeme und -Verfahren, die hierin beschrieben sind, beziehen sich auf eine virtuelle Busschnittstelle (VBI; VBI = virtual bus interface), die konfiguriert ist, um Punkt-zu-Punkt-Transaktionen (P2P-Transaktionen) in Bus-Typ-Transaktionen zu verarbeiten, wobei die VBI selektiv Busmodell-Anfangsblocktyp-Felder aus Daten erzeugen kann, die in einem oder mehreren P2P-Transaktionsdatentypfeldern gespeichert sind.
  • Ein P2P-Transaktionspaket umfasst üblicherweise eines oder mehrere Anfangsblock-Flits und Daten-Flits. Die Daten-Flits speichern allgemein Datenwerte, die aus einem computerlesbaren Speicher gelesen werden. In manchen Fällen können jedoch andere Informationen in einem oder mehreren Daten-Flits gespeichert und/oder codiert werden. Zum Beispiel können einige P2P-Transaktionen Anfangsblockdaten verwenden, die die typische feste Größe überschreiten, die einem oder mehreren P2P-Transaktionsanfangsblock-Flits zugeordnet ist. In diesen Fällen können zusätzliche Anfangsblocktypdaten als ein Datenwert z. B. in einem oder mehreren Daten-Flits codiert werden. Somit kann eine beispielhafte virtuelle Busschnittstelle konfiguriert sein, um ein P2P-Paket zu erfassen, das Anfangsblock-Typ-Daten (z. B. Nichtspeicherdateninformationen, die in Bitfeldern gespeichert sind) in eines oder mehrere Daten-Flits codiert. Nach dem Erfassen des P2P-Pakets mit einem oder mehreren Daten-Flits, die Anfangsblocktypinformationen codieren, kann die VBI die Transaktion und/oder die Daten-Flit(s) zu einer Decodie rungsfunktion befördern, die für den Pakettyp spezifisch ist. Bei einem Beispiel kann eine VBI eine Decodierungsfunktion für jeden Transaktionstypen verfügbar haben, der für das P2P-Verknüpfungsnetzwerk verfügbar ist, und somit können die Decodierungsfunktionen Nichtspeicherdaten-decodierungsspezifisch gemacht werden. Ein Nichtspeicherdaten-decodierungsspezifisches Modul kann z. B. Nichtspeicherdateninformationen auf eine bitfeldmäßige Art und Weise von einem oder mehreren Daten-Flits extrahieren, um das Erzeugen von Busmodell-Anfangsblocktyp-Informationen zu ermöglichen.
  • Das Nachfolgende umfasst Definitionen von ausgewählten Ausdrücken, die hierin verwendet werden. Die Definitionen umfassen verschiedene Beispiele und/oder Formen von Komponenten, die in den Schutzbereich eines Ausdrucks fallen und die für eine Implementierung verwendet werden können. Die Beispiele sollen nicht einschränkend sein. Sowohl Singularals auch Pluralformen von Ausdrücken können innerhalb der Definitionen liegen.
  • Wie in dieser Anmeldung verwendet, bezieht sich der Ausdruck „Computerkomponente" auf eine computerverwandte Entität, entweder Hardware, Firmware, Software oder eine Kombination derselben, oder eine Software in Ausführung. Zum Beispiel kann eine Computerkomponente folgendes sein, ist jedoch nicht darauf beschränkt: ein Prozess, der auf einem Prozessor läuft, ein Prozessor, ein Objekt, ein Ausführelement, ein Teilprozess einer Ausführung, ein Programm und ein Computer. Auf darstellende Weise können sowohl eine Anwendung, die auf einem Server läuft, als auch der Server Computerkomponenten sein. Eine oder mehrere Computerkomponenten können innerhalb eines Prozesses und/oder eines Teilprozesses zur Ausführung vorliegen, und eine Computerkomponente kann auf einem Computer angeordnet sein und/oder zwischen zwei oder mehr Computern verteilt sein.
  • „Computerlesbares Medium", wie es hierin verwendet wird, bezieht sich auf ein Medium, das am direkten oder indirekten Liefern von Signalen, Anweisungen und/oder Daten teilnimmt. Ein computerlesbares Medium kann Formen annehmen, die folgende umfassen, ist jedoch nicht darauf beschränkt: ein nichtflüchtiges Medium, ein flüchtiges Medium und ein Übertragungsmedium. Ein nichtflüchtiges Medium kann z. B. optische oder magnetische Platten usw. umfassen. Ein flüchtiges Medium kann z. B. optische oder magnetische Platten, einen dynamischen Speicher und ähnliches umfassen. Ein Übertragungsmedium kann Koaxialkabel, Kupferdraht, Faseroptikkabel und ähnliches umfassen. Ein Übertragungsmedium kann ferner die Form elektromagnetischer Strahlung annehmen, wie der, die während Funkwellen- und Infrarotdaten-Kommunikationen erzeugt werden, oder kann die Form von einer oder mehreren Gruppen von Signalen annehmen. Übliche Formen eines computerlesbaren Mediums umfassen, sind jedoch nicht beschränkt auf: eine Diskette, einen flexiblen Datenträger, eine Festplatte, ein Magnetband, ein anderes magnetisches Medium, eine CD-ROM, ein anderes optisches Medium, Lochkarten, Papierband, ein anderes physisches Medium mit Mustern aus Löchern, einen RAM, einen ROM, einen EPROM, einen FLASH-EPROM oder einen anderen Speicherchip oder eine Karte, einen Speicherstab, eine Träger-Welle/Puls und ein anderes Medium, von dem ein Computer, ein Prozessor oder eine andere elektronische Vorrichtung lesen kann. Signale, die zum Verbreiten von Anweisungen oder anderer Software über ein Netz verwendet werden, wie z. B. das Internet, können als ein „computerlesbares Medium" betrachtet werden.
  • Ein „Datenspeicher", wie er hierin verwendet wird, bezieht sich auf eine physische und/oder logische Entität, die Daten speichern kann. Ein Datenspeicher kann z. B. eine Datenbank, eine Tabelle, eine Datei, eine Liste, eine Warteschlange, ein Freispeicher, ein Speicher, ein Register usw. sein. Ein Datenspeicher kann in einer logischen und/oder physischen Entität vorliegen und/oder kann zwi schen zwei oder mehr lokalen und/oder physischen Entitäten verteilt sein.
  • Eine „Logik", wie sie hierin verwendet wird, umfasst, ist jedoch nicht beschränkt auf: Hardware, Firmware, Software und/oder Kombinationen von jedem derselben, um eine oder mehrere Funktionen oder eine oder mehrere Aktionen auszuführen und/oder eine Funktion oder Aktion von einer anderen Logik, einem Verfahren und/oder einem System zu verursachen. Zum Beispiel, basierend auf einer gewünschten Anwendung oder einem Bedarf, kann eine Logik einen softwaregesteuerten Mikroprozessor, eine einzelne Logik, wie z. B. eine anwendungsspezifische integrierte Schaltung (ASIC), eine programmierte Logikvorrichtung, eine Speichervorrichtung, die Anweisungen enthält, oder ähnliches umfassen. Die Logik kann eines oder mehrere Gatter, eine Kombination aus Gattern oder andere Schaltungskomponenten umfassen. Die Logik kann ferner vollständig als Software verkörpert sein. Wenn mehrere logische Logiken beschrieben sind, kann es möglich sein, die mehreren logischen Logiken in eine physische Logik zu integrieren. Auf ähnliche Weise, wenn eine einzelne logische Logik beschrieben ist, kann es möglich sein, diese einzelne logische Logik zwischen mehreren physischen Logiken zu verteilen.
  • Eine „wirksame Verbindung" oder eine Verbindung, durch die Entitäten „wirksam verbunden" sind, ist eine, bei der Signale, physische Kommunikationen und/oder logische Kommunikationen gesendet und/oder empfangen werden können. Üblicherweise umfasst eine wirksame Verbindung eine physische Schnittstelle, eine elektrische Schnittstelle und/oder eine Datenschnittstelle, aber es wird darauf hingewiesen, dass eine wirksame Verbindung unterschiedliche Kombinationen dieser oder anderer Typen von Verbindungen umfassen kann, die ausreichend sind, um eine wirksame Steuerung zu ermöglichen. Zum Beispiel können zwei Entitäten wirksam dadurch verbunden sein, dass sie in der Lage sind, Signale zueinander direkt oder durch eine oder mehrere Zwischenen titäten zu kommunizieren, wie z. B. einen Prozessor, ein Betriebssystem, eine Logik, eine Software oder eine andere Entität. Logische und/oder physische Kommunikationskanäle können verwendet werden, um eine wirksame Verbindung zu erzeugen.
  • Ein „Signal", wie es hierin verwendet wird, umfasst, ist jedoch nicht beschränkt auf eines oder mehrere elektrische oder optische Signale, analoge oder digitale Signale, Daten, eine oder mehrere Computer- oder Prozessoranweisungen, Nachrichten, ein Bit oder einen Bitstrom oder eine andere Einrichtung, die empfangen, übertragen und/oder erfasst werden kann.
  • „Software", wie sie hierin verwendet wird, umfasst, ist jedoch nicht beschränkt auf, eine oder mehrere Computer- oder Prozessoranweisungen, die gelesen, interpretiert, kompiliert und/oder ausgeführt werden können und die verursachen können, dass ein Computer, ein Prozessor oder eine andere elektronische Vorrichtung Funktionen, Aktionen und/oder Verhalten auf eine gewünschte Weise ausführt. Die Anweisungen können in verschiedenen Formen verkörpert sein, wie z. B. Routinen, Algorithmen, Modulen, Verfahren, Teilprozessen und/oder Programmen, die separate Anwendungen oder einen Code aus dynamisch verknüpften Bibliotheken umfassen. Software kann ferner in einer Vielzahl von ausführbaren und/oder ladbaren Formen implementiert sein, einschließlich, aber nicht beschränkt auf ein alleinstehendes Programm, einen Funktionsruf (lokal und/oder entfernt), ein Servelet, ein Applet, Anweisungen, die in einem Speicher gespeichert sind, einen Teil eines Betriebssystems oder andere Typen von ausführbaren Anweisungen. Ein Durchschnittsfachmann auf dem Gebiet wird erkennen, dass die Form der Software z. B. abhängig von Anforderungen einer gewünschten Anwendung sein kann, von der Umgebung, in der sie läuft und/oder den Wünschen des Entwerfers/Programmierers oder ähnlichem. Es wird ferner darauf hingewiesen, dass computerlesbare und/oder ausführbare Anweisungen in einer Logik und/oder verteilt zwischen zwei oder mehr Kommunikations-, Kooperations- und/oder Parallelverarbeitungslogiken angeordnet sein können und somit seriell, parallel, massiv parallel und auf andere Weisen geladen und/oder ausgeführt werden können.
  • Eine geeignete Software zum Implementieren der verschiedenen Komponenten der Beispielsysteme und -verfahren, die hierin beschrieben sind, umfasst Programmierungssprachen und Tools bzw. Werkzeuge wie Java, Pascal, C#, C++, C, CGI, Perl, SQL, APIs, SDKs, Anordnung, Firmware, Mikrocode und/oder andere Sprachen und Tools. Software, egal ob ein gesamtes System oder eine Komponente eines Systems, kann als ein Herstellungsartikel verkörpert sein und beibehalten werden oder als Teil eines computerlesbaren Mediums geliefert werden, wie vorangehend beschrieben wurde. Eine andere Form der Software kann Signale umfassen, die einen Programmcode der Software zu einem Empfänger über ein Netzwerk oder ein anderes Kommunikationsmedium übertragen. Somit weist bei einem Beispiel ein computerlesbares Medium eine Form von Signalen auf, die die Software/Firmware darstellen, wie sie von einem Webserver zu einem Benutzer heruntergeladen wird. Bei einem anderen Beispiel weist das computerlesbare Medium eine Form der Software/Firmware auf, wie sie auf dem Webserver beibehalten wird. Andere Formen können ebenfalls verwendet werden.
  • Einige Abschnitte der detaillierten Beschreibungen, die folgen, werden im Hinblick auf Algorithmen und symbolische Darstellungen von Operationen an Datenbits innerhalb eines Speichers präsentiert. Diese algorithmischen Beschreibungen und Darstellungen sind die Einrichtungen, die von Fachleuten auf dem Gebiet verwendet werden, um die Substanz ihrer Arbeit anderen zu übermitteln. Ein Algorithmus wird hier und allgemein als eine Sequenz von Operationen betrachtet, die ein Ergebnis erzeugen. Die Operationen können physische Manipulationen von physischen Quantitäten umfassen. Üblicherweise, aber nicht notwendigerweise, nehmen die physi schen Quantitäten die Form von elektrischen oder magnetischen Signalen an, die in der Lage sind, in einer Logik und ähnlichem gespeichert, übertragen, kompiliert, verglichen und anderweitig manipuliert zu werden.
  • Es hat sich zeitweilig als bequem herausgestellt, im Prinzip aus Gründen der allgemeinen Verwendung, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Ausdrücke, Zahlen oder ähnliches zu bezeichnen. Es sollte jedoch darauf hingewiesen werden, dass diese und ähnliche Ausdrücke den geeigneten physischen Quantitäten zugeordnet werden müssen und ausschließlich bequeme Bezeichnungen sind, die an diese Quantitäten angewendet werden. Außer anderweitig spezifisch angegeben, wird darauf hingewiesen, dass in der gesamten Beschreibung Ausdrücke wie Verarbeitung, Berechnung, Computerberechnung, Bestimmung, Anzeige oder ähnliches sich auf Aktionen und Prozesse eines Computersystems, einer Logik, eines Prozessors oder einer ähnlichen elektronischen Vorrichtung beziehen, die Daten manipuliert und transformiert, die als physische (elektronische) Quantitäten dargestellt sind.
  • 1 stellt ein beispielhaftes, auf einer virtuellen Busschnittstelle basierendes System 100 zum Erzeugen eines Busmodell-Anfangsblocktyp-Feldes aus einem P2P-Modelldatentypfeld dar. Das System 100 kann konfiguriert sein, um das Verhalten einer virtuellen Busschnittstelle 110 zu ändern, die konfiguriert ist, um eine Bus-Typ-Transaktion 120 aus einer Punkt-zu-Punkt-Typ-Transaktion 130 zu erzeugen. Das System 100 kann eine Erfassungslogik 140 umfassen, die konfiguriert ist, um zu erfassen, dass die Punkt-zu-Punkt-Transaktion 130 ein Datentypfeld umfasst, das Daten speichert, aus denen ein Wert für ein Anfangsblock-Typ-Feld in der Bus-Typ-Transaktion 120 erzeugt werden kann. Bei einem Beispiel kann die Erfassungslogik 140 konfiguriert sein, um zu erfassen, dass die Punkt-zu-Punkt-Typ-Transaktion 130 das Datentypfeld umfasst, das Anfangsblocktypdaten speichert, durch Untersuchen eines Transaktionstyps, der der Punkt-zu-Punkt-Typ-Transaktion 130 zugeordnet ist. Nach dem Erfassen, dass die Punkt-zu-Punkt-Typ-Transaktion 130 ein Datentypfeld umfasst, das Anfangsblocktypdaten speichert, kann die Erfassungslogik 140 ein Signal erzeugen, das zu der Decodierlogik 150 und/oder der virtuellen Busschnittstelle 110 verteilt wird.
  • Das System 100 kann ferner eine Decodierlogik 150 umfassen, die wirksam mit der Erfassungslogik 140 verbunden ist. Die Decodierlogik 150 kann konfiguriert sein, um die Daten aus dem Datentypfeld zu extrahieren, die Daten in den Wert zu verarbeiten und selektiv den Wert in dem Anfangsblock-Typ-Feld zu speichern. Während das Speichern des Werts in dem Anfangsblock-Typ-Feld beschrieben wird, wird darauf hingewiesen, dass die Decodierlogik 150 andere Aktionen übernehmen kann, wie das Liefern des Werts zu der VBI 110. Bei einem Beispiel extrahiert die Decodierlogik 150 die Daten aus dem Datentypfeld auf eine bitfeldmäßige Art und Weise. Die Daten in dem Datentypfeld können z. B. in einem oder mehreren Daten-Flits gespeichert werden. Bei einem Beispiel kann die Decodierlogik 150 konfiguriert sein, um zu ermöglichen, dass die virtuelle Busschnittstelle 110 eine Front-Side-Bus-Typ-Transaktion erzeugt.
  • Bei einem Beispiel kann ein P2P-Transaktionspaket, das einem assoziativen Übersetzungspufferspeicherlöschen (TLB-Löschen) zugeordnet ist, mehr Anfangsblockraum benötigen, als üblicherweise in einem standardmäßigen P2P-Transaktionsanfangsblock verfügbar ist. Zum Beispiel können Anfangsblockinformationen eine oder mehrere Leitungsadressen, Spitzengrößen, Zeitgebungsdaten und andere Informationen umfassen. Somit, um das Verlieren der Anfangsblockinformationen zu vermeiden, können einige Anfangsblockinformationen in einem oder mehreren Daten-Flits enden. Während die P2P-Transaktionsanfangsblockgröße den verfügbaren Datenbetrag vielleicht nicht unterbringen kann, kann ein entsprechender Busmodelltransaktionsanfangsblock die Daten vielleicht unterbringen. Somit können Werte, die in einem Daten-Flit in der P2P-Transaktion gespeichert sind, aus dem einen oder den mehreren Daten-Flits wiedergewonnen werden und in dem Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion gespeichert werden.
  • 2 stellt ein anderes Beispiel eines auf einer virtuellen Busschnittstelle basierenden Systems 200 dar, das konfiguriert ist, um ein Busmodell-Anfangsblock-Typ-Feld aus einem P2P-Modelldaten-Typ-Feld zu erzeugen. Das System 200 kann eine Punkt-zu-Punkt-Transaktionslogik 210 umfassen, die konfiguriert ist, um Pakete zu empfangen, die einer Punkt-zu-Punkt-Typ-Transaktion 220 zugeordnet sind. Die Pakete, die der P2P-Typ-Transaktion 220 zugeordnet sind, können z. B. von einem P2P-verknüpften System, einem Tool, das mit einem P2P-verknüpften System interagiert, einem Abschnitt eines hybriden Mehrfachverarbeitungssystems usw. empfangen werden.
  • Das System 200 kann ferner eine Bus-Typ-Transaktionslogik 230 umfassen, die wirksam mit der Punkt-zu-Punkt-Transaktionslogik 210 verbunden ist. Die Bus-Typ-Transaktionslogik 230 kann konfiguriert sein, um Pakete und/oder Datenstrukturen zu erzeugen, die einer Bus-Typ-Transaktion 240 zugeordnet sind, aus den Paketen, die der Punkt-zu-Punkt-Typ-Transaktion 220 zugeordnet sind. Während einige P2P-Transaktionsformate eine relativ einfache Eins-zu-Eins-Korrespondenz mit einigen Bus-Typ-Transaktionsformaten aufweisen können, können andere P2P-Transaktionsformate nicht so einfach in Bus-Typ-Transaktionsformate verarbeitet werden. Zum Beispiel können einige Punkt-zu-Punkt-Transaktionen Anfangsblockinformationen aufweisen, die in Daten-Flits gespeichert sind, während die entsprechende Bus-Typ-Transaktion ähnliche und/oder verwandte (z. B. hergeleitete) Informationen in ihrem Anfangsblock speichert. Zum Beispiel kann eine Bus-Typ-Transaktion in ihrem Anfangsblock Informationen speichern, die aus einem Datenfeld in einer P2P-Transaktion hergeleitet wurden. Daher kann das System 200 eine Erfassungslogik 250 umfassen, die wirksam mit der Punkt-zu-Punkt-Transaktionslogik 210 und/oder der Bus-Typ-Transaktionslogik 230 verbunden ist. Die Erfassungslogik 250 kann konfiguriert sein, um zu erfassen, dass die Punkt-zu-Punkt-Typ-Transaktion 220 ein Daten-Flit umfasst, das einen Nichtspeicherdatenwert codiert. Bei einem Beispiel kann die Erfassungslogik 250 erfassen, dass die Punkt-zu-Punkt-Typ-Transaktion 220 ein Daten-Flit umfasst, das einen Nichtspeicherdatenwert codiert, durch Untersuchen eines Transaktionstyps, der der Punkt-zu-Punkt-Typ-Transaktion 220 zugeordnet ist. Bei einem anderen Beispiel kann die Erfassungslogik 250 erfassen, dass die Punkt-zu-Punkt-Typ-Transaktion 220 ein Daten-Flit umfasst, das einen Nichtspeicherdatenwert codiert, durch Untersuchen eines Anforderungstyps, der der Punkt-zu-Punkt-Typ-Transaktion 220 zugeordnet ist. Nach dem Erfassen, dass ein Daten-Flit einen Nichtspeicherdatenwert codiert, kann die Erfassungslogik 250 ein Signal erzeugen, das z. B. zu der Punkt-zu-Punkt-Transaktionslogik 210, der Decodierlogik 260 und/oder der Bus-Typ-Transaktionslogik 230 verteilt wird.
  • Das System 200 kann ferner eine Decodierlogik 260 umfassen, die wirksam mit der Erfassungslogik 250 und der Bus-Typ-Transaktionslogik 230 verbunden ist. Die Decodierlogik 260 kann konfiguriert sein, um den Nichtspeicherdatenwert aus dem Daten-Flit zu extrahieren, um den Nichtspeicherdatenwert zu decodieren und um selektiv den decodierten Nichtspeicherdatenwert zu der Bus-Typ-Transaktionslogik 230 zu liefern. Bei einem Beispiel kann die Decodierlogik 260 den Nichtspeicherdatenwert aus dem Daten-Flit auf eine bitfeldmäßige Art und Weise extrahieren. Die Decodierlogik 260 kann konfiguriert sein, um eine Punkt-zu-Punkt-Typ-Transaktion zu verarbeiten, die einen Nichtspeicherdatenwert umfasst, der in zwei oder mehr Daten-Flits gespeichert ist. Bei einem Beispiel kann das System 200 eine Bus-Typ-Transaktion für einen Front-Side-Bus erzeugen. Zum Beispiel stellt 8 ein Mehrfachverarbeitungssystem dar, das Komponenten umfasst, die durch einen Front-Side-Bus 810 verbunden sind. Somit kann ein System, wie das System 200, Transaktionen zu dem Mehrfachverarbeitungssystem liefern, wo die Transaktionen in einem Front-Side-Bus-Format sind und aus Paketen erzeugt wurden, die einer P2P-Transaktion zugeordnet sind.
  • Beispielverfahren sind besser verständlich Bezug nehmend auf die Flussdiagramme der 3 und 4. Während zu Zwecken der Einfachheit der Erklärung halber die dargestellten Methoden als eine Reihe von Blöcken gezeigt und beschrieben sind, wird darauf hingewiesen, dass die Methoden nicht durch die Reihenfolge der Blöcke eingeschränkt sind, da einige Blöcke in unterschiedlichen Reihenfolgen und/oder gleichzeitig mit anderen Blöcken von denen auftreten können, die gezeigt und beschrieben sind. Ferner können weniger als die dargestellten Blöcke erforderlich sein, um eine Beispielmethode zu implementieren. Weiterhin können zusätzliche und/oder alternative Methoden zusätzliche, nicht dargestellte Blöcke verwenden.
  • In den Flussdiagrammen bezeichnen Blöcke „Verarbeitungsblöcke", die mit einer Logik implementiert sein können. Ein Flussdiagramm zeigt keine Syntax für eine bestimmte Programmiersprache, eine Methode oder einen Stil (z. B. verfahrensorientiert, objektorientiert). Statt dessen stellt ein Flussdiagramm Funktionsinformationen dar, die ein Fachmann auf dem Gebiet verwenden kann, um eine Logik zu entwickeln, um die dargestellte Verarbeitung durchzuführen. Es wird darauf hingewiesen, dass bei einigen Beispielen Programmelemente wie temporäre Variablen, Routineschleifen usw. nicht gezeigt sind. Es wird ferner darauf hingewiesen, dass elektronische und Softwareanwendungen dynamische und flexible Prozesse umfassen können, so dass die dargestellten Blöcke in anderen Sequenzen durchgeführt werden können, die sich von jenen unterscheiden, die gezeigt sind, und/oder dass Blöcke kombiniert oder in mehrere Komponenten unterteilt werden können. Es wird darauf hingewiesen, dass die Prozesse unter Verwendung verschiedener Programmierungslösungsansätze implementiert werden können, wie z. B.
  • einer Maschinensprache, verfahrensorientiert, objektorientiert und/oder Künstliche-Intelligenz-Techniken.
  • 3 stellt ein Beispielverfahren 300 zum Erzeugen eines Busmodell-Anfangsblock-Typ-Feldes aus einem P2P-Modell-Datentypfeld dar. Das Verfahren 300 kann durchgeführt werden, z. B. bei einer virtuellen Busschnittstelle. Das Verfahren 300 kann bei 310 das Erfassen eines Fertigstellungsereignisses umfassen, das dem Empfangen einer Punkt-zu-Punkt-Transaktion zugeordnet sein kann, die in eine Bus-Typ-Transaktion verarbeitet werden soll, durch die virtuelle Busschnittstelle. Das Erfassen eines Fertigstellungsereignisses kann z. B. das Bestimmen umfassen, dass der letzte Flit in einem Anfangsblock angekommen ist, das Bestimmen, dass der letzte Flit in einem Paket angekommen ist, usw.
  • Das Verfahren 300 umfasst ferner bei 320 das Durchführen einer Bestimmung, ob die Punkt-zu-Punkt-Transaktion einen Daten-Flit umfasst, der einen Wert speichert, der in ein Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion verarbeitet werden soll. Das Bestimmen, ob die Punkt-zu-Punkt-Transaktion solche Daten umfasst, kann z. B. das Untersuchen eines Transaktionstyps umfassen, der der Punkt-zu-Punkt-Transaktion zugeordnet ist.
  • Wenn die Bestimmung bei 320 Ja ist, dann kann das Verfahren 300 fortfahren, bei 330, um selektiv den Wert aus dem Daten-Flit zu extrahieren, und bei 340, um einen Anfangsblock-Typ-Wert aus dem extrahierten Wert zu erzeugen. Bei einem Beispiel kann der Wert auf eine bitfeldmäßige Art und Weise aus einem oder mehreren Daten-Flits extrahiert werden. Das Erzeugen des Anfangsblock-Typ-Werts kann z. B. das Ändern des Formats eines Werts (z. B. Bitfeld zu Ganzzahl), das Ändern der Reihenfolge eines Werts (z. B. großendig zu kleinendig), das Ausführen einer Nachschlagtabelle zum Wiedergewinnen eines Anfangsblockwerts, der einem Bitfeldcode zugeordnet ist, usw. umfassen. Das Erzeugen des An fangsblock-Typ-Feldes umfasst das Manipulieren von einem oder mehreren elektrischen Signalen in einem Computerspeicher.
  • Bei 350 kann eine Bestimmung darüber durchgeführt werden, ob eine andere P2P-Transaktion verarbeitet werden soll. Wenn die Bestimmung Ja ist, dann kann das Verarbeiten zu 310 zurückkehren, ansonsten kann das Verarbeiten abgeschlossen werden.
  • 4 stellt ein Beispielverfahren 400 zum Erzeugen eines Busmodell-Anfangsblock-Typ-Feldes aus einem P2P-Modell-Datentypfeld dar. Das Verfahren 400 kann bei 410 das Einrichten einer Decodierfunktion für einen Punkt-zu-Punkt-Transaktionstyp umfassen, bei dem ein Daten-Flit einen Nichtspeicherdatenwert codiert. Das Einrichten einer Decodierfunktion kann z. B. das Verursachen umfassen, dass ein Satz von prozessorausführbaren Anweisungen in einen Computerspeicher geladen wird und eine Abbildung zwischen den Anweisungen und einem Pakettyp erzeugt. Während eine Decodierfunktion beschrieben ist, wird darauf hingewiesen, dass das Decodieren durch Entitäten durchgeführt werden kann, einschließlich, aber nicht beschränkt auf eine Teilroutine, ein Objektverfahren, eine Funktion, ein Programm, ein Applet, eine Logik usw. Die Decodierfunktion kann mit dem Extrahieren eines Anfangsblock-Typ-Werts aus einem Daten-Flit, dem Verarbeiten desselben zu Anfangsblock-Typ-Daten und dem Verfügbarmachen desselben für andere Prozesse oder Logiken beauftragt werden.
  • Wenn die eine oder die mehreren Decodierfunktionen eingerichtet sind, kann das Verfahren 400 fortschreiten, bei 420, um ein Fertigstellungsereignis zu erfassen, das dem Empfangen von Paketen zugeordnet ist, die einer Punkt-zu-Punkt-Transaktion zugeordnet sind, um in eine Bus-Typ-Transaktion verarbeitet zu werden, durch eine virtuelle Busschnittstelle. Nachdem die Punkt-zu-Punkt-Transaktion empfangen wurde, kann das Verfahren 400 das Bestimmen umfassen, bei 430, ob die Punkt-zu-Punkt-Transaktion einen Daten-Flit umfasst, der einen Wert speichert, der in ein Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion verarbeitet werden soll. Die Erfassung kann z. B. durchgeführt werden, durch Untersuchen eines Transaktionstyps, der der Punkt-zu-Punkt-Transaktion zugeordnet ist.
  • Nach dem Bestimmen, dass ein Daten-Flit einen Wert speichert, der in ein Anfangsblock-Typ-Feld bei einer Bus-Typ-Transaktion verarbeitet werden soll, kann das Verfahren 400 bei 440 fortschreiten, das eine oder die mehreren Daten-Flits und/oder eine P2P-Transaktion zu einer Decodierfunktion weiterzuleiten. Die Decodierfunktion kann das eine oder die mehreren Daten-Flits verarbeiten und einen Wert zurücksenden, der geeignet zur Integration in einem Bus-Typ-Transaktionsanfangsblock ist. Somit kann das Verfahren 400 bei 450 eine Bus-Typ-Transaktion unter Verwendung der Pakete erzeugen, die der P2P-Transaktion zugeordnete sind, und einen Wert, der durch die Decodierfunktion geliefert wird. Bei 460 kann eine Bestimmung durchgeführt werden, dahingehend, ob eine andere P2P-Transaktion verarbeitet werden soll. Wenn die Bestimmung Ja lautet, kann die Verarbeitung zu 420 zurückkehren, anderweitig kann das Verarbeiten abgeschlossen werden.
  • Während 4 verschiedene Aktionen darstellt, die in Serie auftreten, wird darauf hingewiesen, dass verschiedene Aktionen, die in 4 dargestellt sind, im Wesentlichen parallel auftreten könnten. Auf darstellende Weise könnte ein erster Prozess Fertigstellungsereignisse erfassen, ein zweiter Prozess könnte bestimmen, ob eine P2P-Transaktion ein Typ ist, der Decodierfunktionen verwendet, um Anfangsblock-Typ-Werte aus Daten-Typ-Feldern zu extrahieren und/oder zu decodieren, und ein dritter Prozess könnte Bus-Typ-Transaktionen aus P2P-Transaktionen erzeugen und Daten, die von Decodierfunktionen zurückgesendet werden. Während drei Prozesse beschrieben sind, wird darauf hingewiesen, dass eine größere und/oder kleinere Anzahl von Prozessen verwendet werden könnte, und dass leichte Prozesse, regelmäßige Prozesse, Teilprozesse und andere Lösungsansätze verwendet werden könnten. Es wird darauf hingewiesen, dass andere Beispielverfahren, die hierin beschrieben sind, in manchen Fällen ferner Aktionen umfassen können, die im Wesentlichen parallel auftreten.
  • Beispielmethoden können als prozessorausführbare Anweisungen und/oder Operationen implementiert sein, die auf einem computerlesbaren Medium gespeichert sind. Somit kann bei einem Beispiel ein computerlesbares Medium prozessorausführbare Anweisungen speichern, die wirksam sind, um ein Verfahren auszuführen, dass das Einrichten einer Decodierfunktion für einen Punkt-zu-Punkt-Transaktionstyp umfasst, bei dem ein Daten-Flit einen Nichtspeicherdatenwert codiert. Das Einrichten einer Decodierfunktion kann z. B. das Erzeugen einer Abbildung zwischen einem bestimmten Transaktionstyp und einer bestimmten Funktion umfassen, um das Aufrufen dieser Funktion zu ermöglichen, wenn eine Transaktion dieses Typs erfasst wird. Wenn die Decodierfunktionen eingerichtet sind, kann das Verfahren fortschreiten mit dem Erfassen eines Fertigstellungsereignisses, das dem Empfangen einer Punkt-zu-Punkt-Transaktion zugeordnet ist, die in eine Bus-Typ-Transaktion verarbeitet werden soll, durch eine virtuelle Busschnittstelle. Das Erfassen eines Fertigstellungsereignisses kann das Empfangen und Interpretieren eines elektrischen Signals umfassen. Nachdem die Punkt-zu-Punkt-Transaktion empfangen wird, kann das Verfahren das Bestimmen umfassen, ob die Punkt-zu-Punkt-Transaktion einen Daten-Flit umfasst, der einen Wert speichert, der in ein Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion verarbeitet werden soll, durch Untersuchen eines Transaktionstyps, der der Punkt-zu-Punkt-Transaktion zugeordnet ist. Nach dem Bestimmen, dass ein Daten-Flit einen Wert speichert, der in ein Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion verarbeitet werden soll, kann das Verfahren das Weiterleiten des Daten-Flits zu einer eingerichteten Decodierfunktion und das Speichern eines decodierten Werts umfassen, der von der Decodierfunktion zurückgesendet wird. Während das obige Verfahren derart beschrieben ist, dass es auf einem computerlesbaren Medium gespeichert ist, wird darauf hingewiesen, dass andere Beispielverfahren, die hierin beschrieben sind, ebenfalls auf einem computerlesbaren Medium gespeichert sein können.
  • 5 stellt zwei Beispielssätze aus P2P-Transaktionsanfangsblock und Daten-Flits dar, die in Busmodelltransaktionskomponenten verarbeitet werden. Eine erste P2P-Transaktion 500 kann Anfangsblock-Flits und Daten-Flits umfassen. Zum Beispiel kann die Transaktion 500 die Anfangsblock-Flits H1 und H2 umfassen. Auf ähnliche Weise kann die Transaktion 500 die Daten-Flits D1 und D2 bis Dn umfassen, wobei n eine ganze Zahl ist. Die P2P-Transaktion 500 kann durch eine virtuelle Busschnittstelle in eine Bustransaktion 510 verarbeitet werden. Die Verarbeitung der Transaktion 500 in die Transaktion 510 kann Aktionen umfassen, wie z. B. Übersetzen, Neuordnen, Neuformatieren usw. Somit können die Anfangsblock-Flits H1 und H2 in einen einzelnen Anfangsblockabschnitt H1' bei der Bustransaktion 510 verarbeitet werden. Bei einigen Beispielen können Daten direkt zwischen Transaktionen verarbeitet werden, und somit kann das Daten-Flit D1 in einen Datenabschnitt D1' verarbeitet werden, das Daten-Flit D2 kann in einen Datenabschnitt D2' verarbeitet werden, usw.
  • Es wird darauf hingewiesen, dass beim Verarbeiten der Transaktion 500 in die Transaktion 510 keine Daten aus den Daten-Flits D1 bis Dn in den Anfangsblockabschnitt H1' verarbeitet wurden. Beim Verarbeiten einer zweiten P2P-Transaktion 520 in eine zweite Bus-Typ-Transaktion 530 werden jedoch einige Daten aus den Daten-Flits bei der Transaktion 520 in einen Anfangsblockabschnitt der Bus-Typ-Transaktion 530 verarbeitet. Bei dem Beispiel, das durch Verarbeiten der Transaktion 520 zu Transaktion 530 dargestellt ist, werden im Wesentlichen alle Anfangsblock- und Daten-Informationen zu dem Anfangsblockabschnitt H3' verar beitet. Zum Beispiel werden Anfangsblock-Flits H3 und H4 verarbeitet und tragen zu dem Anfangsblockabschnitt H3' bei. Auf ähnliche Weise werden Daten-Flits, die Anfangsblockinformationen codieren, wie z. B. HD1 und HD2 bis HDm (wobei m eine ganze Zahl ist), verarbeitet und tragen zu dem Anfangsblockabschnitt H3' bei.
  • 6 stellt einen Computer 600 dar, der einen Prozessor 602, einen Speicher 604 und Eingangs-/Ausgangstore 610 umfasst, die wirksam durch einen Bus 608 verbunden sind. Bei einem Beispiel kann der Computer 600 eine VBI 630 umfassen, die konfiguriert ist, um das Erzeugen von Busmodell-Anfangsblock-Typ-Feldern aus P2P-Modell-Datenfeldern zu ermöglichen. Die VBI 630, egal ob sie in Hardware, Software, Firmware und/oder einer Kombination derselben implementiert ist, kann eine Einrichtung zum Bestimmen bereitstellen, ob eine Punkt-zu-Punkt-Transaktion, die für eine virtuelle Busschnittstelle verfügbar ist, einen Daten-Flit umfasst, der Nichtspeicherdateninformationen speichert, die in einem Bus-Typ-Anfangsblockdatentyp-Feld gespeichert sind. Auf ähnliche Weise kann die VBI 630, egal ob sie in Hardware, Software, Firmware und/oder einer Kombination derselben implementiert ist, eine Einrichtung zum Extrahieren der Nichtspeicherdateninformationen aus dem Daten-Flit und eine Einrichtung zum Decodieren der extrahierten Nichtspeicherdateninformationen und zum Verfügbarmachen der decodierten Nichtspeicherdateninformationen für eine Virtuelle-Busschnittstelle-Logik bereitstellen, die konfiguriert ist, um ein Anfangsblock-Typ-Feld für eine Bus-Typ-Transaktion zu erzeugen.
  • Der Prozessor 602 kann eine Vielzahl von verschiedenen Prozessoren sein, einschließlich einem dualen Mikroprozessor und anderer Mehrfachprozessorarchitekturen. Der Speicher 604 kann einen flüchtigen Speicher und/oder einen nichtflüchtigen Speicher umfassen. Der nichtflüchtige Speicher kann folgendes umfassen, ist jedoch nicht darauf beschränkt: ROM, PROM, EPROM, EEPROM und ähnliches. Der flüchtige Speicher kann z. B. einen RAM, einen synchronen RAM (SRAM), einen dynamischen RAM (DRAM), einen synchronen DRAM (SDRAM), einen Doppeldatenraten-SDRAM (DDR SDRAM) und einen Direkt-RAM-Bus-RAM (DRRAM) umfassen.
  • Eine Platte 606 kann wirksam mit dem Computer 600 verbunden sein, z. B. über eine Eingangs-/Ausgangsschnittstelle (z. B. Karte, Vorrichtung) 618 und ein Eingangs-/Ausgangstor 610. Die Platte 606 kann folgendes umfassen, ist jedoch nicht darauf beschränkt: Vorrichtungen wie ein Magnetplattenlaufwerk, ein Festkörper-Plattenlaufwerk, ein Diskettenlaufwerk, ein Bandlaufwerk, ein Zip-Laufwerk, eine Flash-Speicherkarte und/oder einen Speicherstab. Ferner kann die Platte 606 optische Laufwerke umfassen, wie z. B. eine CD-ROM, ein CD-aufzeichenbares Laufwerk (CD-R-Laufwerk), ein CD-überschreibbares Laufwerk (CD-RW-Laufwerk) und/oder ein digitales Video-ROM-Laufwerk (DVD ROM). Der Speicher 604 kann Prozesse 614 und/oder Daten 616 speichern. Die Platte 606 und/oder der Speicher 604 können ein Betriebssystem speichern, das Ressourcen des Computers 600 steuert und zuordnet.
  • Der Bus 608 kann eine einzelne interne Busverbindungsarchitektur und/oder andere Bus- oder Maschenarchitekturen sein. Während ein einzelner Bus dargestellt ist, wird darauf hingewiesen, dass der Computer 600 mit verschiedenen Vorrichtungen, Logiken und Peripheriegeräten unter Verwendung anderer Busse kommunizieren kann, die nicht dargestellt sind (z. B. PCIE, SATA, Infiniband, 1394, USB, Ethernet). Der Bus 608 kann von einer Vielzahl von Typen sein, einschließlich, aber nicht beschränkt auf einen Speicherbus oder eine Speichersteuerung, einen Peripheriegerätebus oder einen externen Bus, einen Kreuzschienenschalter und/oder einen lokalen Bus. Der lokale Bus kann von einer Vielzahl von Arten sein, einschließlich, aber nicht beschränkt auf einen Industriestandardarchitekturbus (ISA-Bus), einen Mikrokanalarchitekturbus (MSA-Bus), einen erweiterten ISA-Bus (EISA-Bus), einen Peripheriekomponentenverbindungsbus (PCI-Bus), einen universellen seriellen Bus (USB) und einen Kleincomputerschnittstellenbus (SCSI-Bus).
  • Der Computer 600 kann mit Eingabe-/Ausgabevorrichtungen über I/O-Schnittstellen 618 und Eingangs-/Ausgangstore 610 interagieren. Die Eingabe-/Ausgabevorrichtungen können folgende umfassen, sind jedoch nicht auf dieselben beschränkt: eine Tastatur, ein Mikrophon, eine Zeige- und Auswahlvorrichtung, Kameras, Videokarten, Anzeigeeinrichtungen, Platten 606, Netzwerkvorrichtungen 620 und ähnliches. Die Eingangs-/Ausgangstore 610 können folgende umfassen, sind jedoch nicht auf dieselben beschränkt: serielle Tore, parallele Tore und USB-Tore.
  • Der Computer 600 kann in einer Netzwerkumgebung wirksam sein und kann somit mit Netzwerkvorrichtungen 620 über die I/O-Vorrichtungen 618 und/oder die I/O-Tore 610 verbunden sein. Durch die Netzwerkvorrichtungen 620 kann der Computer 600 mit einem Netzwerk interagieren. Durch das Netzwerk kann der Computer 600 logisch mit entfernten Computern verbunden sein. Die Netzwerke, mit denen der Computer 600 interagieren kann, umfassen, sind jedoch nicht beschränkt auf ein lokales Netz (LAN), ein weites Netz (WAN) und andere Netze. Die Netzwerkvorrichtungen 620 können mit LAN-Techniken verbunden sein, einschließlich, aber nicht beschränkt auf eine faserverteilte Datenschnittstelle (FDDI), eine kupferverteilte Datenschnittstelle (CDDI), Ethernet (IEEE 802.3), Token-Ring (IEEE 802.5), drahtlose Computerkommunikation (IEEE 802.11), Bluetooth (IEEE 802.15.1) und ähnliches. Auf ähnliche Weise können die Netzwerkvorrichtungen 620 mit WAN-Techniken verbunden sein, einschließlich, aber nicht beschränkt auf Punkt-zu-Punkt-Verknüpfungen, Schaltungsschaltnetzwerke, wie z. B. das integrierte digitale Fernmeldenetz (ISDN), Paketschaltnetzwerke und digitale Teilnehmeranschlussleitungen (DSL).
  • Bei einem Beispiel kann der Computer 600 ein virtuelles Busschnittstellensystem 630 umfassen, das eine Punkt-zu- Punkt-Transaktionslogik umfasst, die konfiguriert ist, um Pakete zu empfangen, die einer Punkt-zu-Punkt-Transaktion zugeordnet sind. Die VBI 630 kann ferner eine Bus-Typ-Transaktionslogik umfassen, die wirksam mit der Punkt-zu-Punkt-Transaktionslogik verbunden ist, wobei die Bus-Typ-Transaktionslogik konfiguriert ist, um eine Bus-Typ-Transaktion zu erzeugen, die der Punkt-zu-Punkt-Transaktion aus den Paketen entspricht, die der Punkt-zu-Punkt-Transaktion zugeordnet sind. Die VBI 630 kann ferner eine Erfassungslogik umfassen, die wirksam mit der Punkt-zu-Punkt-Transaktionslogik verbunden ist, wobei die Erfassungslogik konfiguriert ist, um zu erfassen, dass die Punkt-zu-Punkt-Transaktion einen Daten-Flit umfasst, der einen Nichtspeicherdatenwert codiert. Die VBI 630 kann ferner eine Decodierlogik umfassen, die wirksam mit der Erfassungslogik und der Bus-Typ-Transaktionslogik verbunden ist, wobei die Decodierlogik konfiguriert ist, um den Nichtspeicherdatenwert aus dem Daten-Flit zu extrahieren, den Nichtspeicherdatenwert zu decodieren und den decodierten Nichtspeicherdatenwert selektiv zu der Bus-Typ-Transaktionslogik zu liefern.
  • Bezug nehmend nun auf 7 ist eine Anwendungsprogrammierungsschnittstelle (API) 700 dargestellt, die Zugriff auf eine VBI 710 liefert, die konfiguriert ist, um Bus-Modell-Anfangsblocktyp-Felder aus P2P-Modell-Datentyp-Feldern zu erzeugen. Die API 700 kann z. B. durch einen Programmierer 720 und/oder einen Prozess 730 verwendet werden, um Zugriff auf die Verarbeitung zu gewinnen, die durch die VBI 710 durchgeführt wird. Zum Beispiel kann ein Programmierer 720 ein Programm schreiben, um auf die VBI 710 zuzugreifen (z. B. seine Operation auszulösen, seine Operation zu überwachen, seine Operation zu steuern), wobei das Schreiben des Programms durch das Vorhandensein der API 700 ermöglicht wird. Der Programmierer 720 muss die Einbauten der VBI 710 nicht verstehen, sondern der Programmierer 720 muss nur die Schnittstelle zu der VBI 710 lernen. Dies ermöglicht das Einkapseln der Funktionalität der VBI 710, während diese Funktionalität freigelegt wird.
  • Auf ähnliche Weise kann die API 700 verwendet werden, um Datenwerte zu der VBI 710 zu liefern und/oder Datenwerte von der VBI 710 wiederzugewinnen. Zum Beispiel kann ein Prozess 730, der P2P-Transaktionen syntaktisch analysiert, einen P2P-Transaktions-Daten-Flit zu der VBI 710 über die API 700 liefern, z. B. durch Verwenden eines Rufs, der in der API 700 geliefert wird. Somit kann bei einem Beispiel der API 700 ein Satz von Anwendungsprogrammierungsschnittstellen auf einem computerlesbaren Medium gespeichert sein. Die Schnittstellen können durch einen Programmierer, eine Computerkomponente, eine Logik usw. verwendet werden, um Zugriff auf eine VBI 710 zu gewinnen, die konfiguriert ist, um Busmodell-Anfangsblocktyp-Felder aus den P2P-Modell-Datentyp-Feldern zu erzeugen. Die Schnittstellen können umfassen, sind jedoch nicht beschränkt auf: eine erste Schnittstelle 740, die einen Daten-Flit kommuniziert, der einen Nichtspeicherdatenwert speichert (z. B. Anfangsblock-Typ-Daten), eine zweite Schnittstelle 750, die einen Wert kommuniziert, der bitweise feldmäßig aus dem Daten-Flit extrahiert wurde, und eine dritte Schnittstelle 760, die ein Anfangsblock-Typ-Feld für eine Bus-Typ-Transaktion kommuniziert, wobei das Anfangsblock-Typ-Feld aus den Daten hergeleitet ist, die von dem Daten-Flit wiedergewonnen wurden.
  • 8 stellt ein Beispielsystem dar, das einen Front-Side-Bus 810 verwendet. Das System kann einen Satz von CPUs umfassen (z. B. CPU 824 bis CPU 834). Während zwei CPUs dargestellt sind, wird darauf hingewiesen, dass eine größere und/oder kleinere Anzahl von CPUs verwendet werden kann. Die CPUs können einen L1-Cache umfassen, der z. B. Anweisungen und Daten speichert. Auf ähnliche Weise können die CPUs einen L2-Cache umfassen (z. B. L2-Cachespeicher 822 bis 832). Daten und/oder Anweisungen können zwischen den L1-Caches und den L2-Caches übertragen werden.
  • Bei einem Beispiel können die CPU 824 und die CPU 834 kommunizieren. Dies kann eine oder mehrere Operationen umfassen, die den Front-Side-Bus 810 umfassen. Auf ähnliche Weise kann die CPU 824 mit einer Speichersteuerung 840 interagieren, die ferner eine oder mehrere Operationen auf dem Front-Side-Bus 810 umfassen kann. Die Speichersteuerung 840 kann z. B. Zugriff auf einen dynamischen RAM 850, eine I/O-Steuerung 860, eine Graphikkarte 870 usw. bereitstellen. Die I/O-Steuerung 860 kann ihrerseits Zugriff auf einen Satz von PCI-Vorrichtungen (z. B. PCI-Vorrichtungen 882, 884) über einen PCI-Bus 870 bereitstellen.
  • Das System, das in 8 dargestellt ist, kann ein System sein, für das eine Komponente (z. B. CPU 824, CPU 834) simuliert ist. Zum Beispiel kann die CPU 824 durch Werkzeuge simuliert werden, wie z. B. ein RTL-Werkzeug, einen goldenen Simulator, usw. Die Werkzeuge umfassen vielleicht keinen Bus, wie z. B. einen Front-Side-Bus 810, sondern sind vielleicht statt dessen durch ein Netzwerkmodell verbunden. Somit kann eine virtuelle Busschnittstelle, wie z. B. jene, die oben beschrieben wurden, Front-Side-Bus-Operationen aus Netzwerkmodelltransaktionen erzeugen, um das Vergleichen von Ergebnissen zwischen dem Simulationswerkzeug und der simulierten Komponente zu ermöglichen. Eine Aktion, die bei einer solchen Herstellung umfasst ist, kann das Erzeugen von Anfangsblock-Typ-Feldern aus Daten umfassen, die in einem Netzwerk-Typ-Datenfeld codiert sind.
  • Während Beispiel-Systeme, -Verfahren usw. durch Beschreiben von Beispielen in beträchtlichem Detail dargestellt wurden, ist es nicht die Absicht der Anwendungen, den Schutzbereich der beiliegenden Ansprüche oder der Erfindung auf solche Details einzuschränken oder zu begrenzen. Es ist natürlich nicht möglich, jede denkbare Kombination von Komponenten oder Methoden zu Zwecken der Beschreibung der Beispiel-Systeme, -Verfahren usw. zu beschreiben, die hierin erläutert sind. Daher ist die Erfindung nicht auf die spezifi schen Details, die dargestellte Vorrichtung und darstellende Beispiele beschränkt. Somit soll diese Anmeldung Änderungen, Modifikationen und Variationen einschließen, die in den Schutzbereich der beiliegenden Ansprüche fallen. Der Schutzbereich soll durch die beiliegenden Ansprüche und ihre Entsprechungen bestimmt sein.
  • Zu dem Ausmaß, dass der Ausdruck „umfasst" oder „umfassend" in der detaillierten Beschreibung oder den Ansprüchen verwendet wird, soll derselbe umfassend sein, ähnlich zu dem Ausdruck „aufweisen", so wie dieser Ausdruck interpretiert wird, wenn er als traditionelles Wort in einem Anspruch verwendet wird. Ferner, zu dem Ausmaß, dass der Ausdruck „oder" in der detaillierten Beschreibung oder den Ansprüchen verwendet wird (z. B. A oder B), soll derselbe bedeuten „A oder B oder beides". Wenn die Anmelder beabsichtigen, „nur A oder B, aber nicht beides" anzuzeigen, dann wird der Ausdruck „nur A oder B, aber nicht beides" verwendet. Somit ist die Verwendung des Ausdrucks „oder" hierin einschließend und nicht ausschließend in seiner Verwendung. Siehe Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2. Aufl. 1995).

Claims (18)

  1. System (100), das konfiguriert ist, um mit einer virtuellen Busschnittstelle (110) zu interagieren, die konfiguriert ist, um eine Bus-Typ-Transaktion (120) aus einer Punkt-zu-Punkt-Typ-Transaktion (130) zu erzeugen, wobei das System (100) folgende Merkmale aufweist: eine Erfassungslogik (140), die konfiguriert ist, um zu erfassen, ob die Punkt-zu-Punkt-Transaktion (130), die durch die virtuelle Busschnittstelle (110) verarbeitet werden soll, ein Datentypfeld umfasst, das Daten speichert, aus denen ein Wert für ein Anfangsblock-Typ-Feld bei einer Bus-Typ-Transaktion (120) erzeugt werden kann; und eine Decodierlogik (150), die wirksam mit der Erfassungslogik (140) verbunden ist, wobei die Decodierlogik (150) konfiguriert ist, um die Daten aus dem Datentypfeld zu extrahieren, um die Daten in den Wert zu verarbeiten, und um selektiv den Wert in dem Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion (120) zu speichern.
  2. System (100) gemäß Anspruch 1, bei dem die Erfassungslogik (140) erfasst, ob die Punkt-zu-Punkt-Transaktion (130) ein Datentypfeld umfasst, das Daten speichert, aus denen ein Wert für ein Anfangsblock-Typ-Feld erzeugt werden kann, durch Untersuchen eines Transaktionstyps, der der Punkt-zu-Punkt-Transaktion (130) zugeordnet ist.
  3. System (100) gemäß Anspruch 1 oder 2, bei dem die Decodierlogik die Daten aus dem Datentypfeld auf bitfeldmäßige Art und Weise extrahiert.
  4. System (100) gemäß Anspruch 3, bei dem nach dem Erfassen, dass eine Punkt-zu-Punkt-Transaktion Daten speichert, aus denen ein Wert für ein Anfangsblock-Typ-Feld erzeugt werden kann, die Erfassungslogik ein Signal erzeugt, das zu einer oder mehreren der Decodierlogik und der virtuellen Busschnittstelle verteilt wird.
  5. System (100) gemäß einem der Ansprüche 1 bis 4, bei dem die Bus-Typ-Transaktion eine Front-Side-Bus-Transaktion aufweist.
  6. Virtuelles Busschnittstellensystem (200), das folgende Merkmale aufweist: eine Punkt-zu-Punkt-Transaktionslogik (210), die konfiguriert ist, um ein Paket zu empfangen, das einer Punkt-zu-Punkt-Typ-Transaktion (220) zugeordnet ist; eine Bus-Typ-Transaktionslogik (230), die wirksam mit der Punkt-zu-Punkt-Transaktionslogik (210) verbunden ist, wobei die Bus-Typ-Transaktionslogik (230) konfiguriert ist, um eine Bus-Typ-Transaktion (240) zu erzeugen, die der Punkt-zu-Punkt-Transaktion (220) aus dem Paket entspricht, das der Punkt-zu-Punkt-Transaktion (220) zugeordnet ist; eine Erfassungslogik (250), die wirksam mit der Punkt-zu-Punkt-Transaktionslogik (210) verbunden ist, wobei die Erfassungslogik (250) konfiguriert ist, um zu erfassen, ob das Paket, das der Punkt-zu-Punkt-Typ-Transaktion (220) zugeordnet ist, einen Daten-Flit umfasst, der einen Nichtspeicherdatenwert codiert; und eine Decodierlogik (260), die wirksam mit der Erfassungslogik (250) und der Bus-Typ-Transaktionslogik (230) verbunden ist, wobei die Decodierlogik (260) konfiguriert ist, um den Nichtspeicherdatenwert aus dem Daten-Flit zu extrahieren, um den Nichtspeicherdatenwert zu decodieren, und um selektiv den decodierten Nichtspeicherdatenwert zu der Bus-Typ-Transaktionslogik (230) zu liefern.
  7. System (200) gemäß Anspruch 6, bei dem die Erfassungslogik erfasst, ob das Paket, das der Punkt-zu-Punkt-Transaktion zugeordnet ist, einen Daten-Flit umfasst, der einen Nichtspeicherdatenwert codiert, durch Untersuchen eines Transaktionstyps, der der Punkt-zu-Punkt-Transaktion zugeordnet ist.
  8. System (200) gemäß Anspruch 7, bei dem die Decodierlogik den Nichtspeicherdatenwert aus dem Daten-Flit auf bitfeldmäßige Art und Weise extrahiert.
  9. System (200) gemäß einem der Ansprüche 6 bis 8, bei dem nach dem Erfassen, dass das Paket, das der Punkt-zu-Punkt-Transaktion zugeordnet ist, einen Daten-Flit umfasst, der einen Nichtspeicherdatenwert codiert, die Erfassungslogik ein Signal erzeugt, das zu einem oder mehreren aus der Punkt-zu-Punkt-Transaktionslogik, der Bus-Typ-Transaktionslogik und der Decodierlogik verteilt wird.
  10. System (200) gemäß einem der Ansprüche 6 bis 9, bei dem die virtuelle Busschnittstelle eine Bustransaktion für einen Front-Side-Bus erzeugt.
  11. Computer, der mit einem virtuellen Busschnittstellensystem konfiguriert ist, wobei das virtuelle Busschnittstellensystem folgende Merkmale aufweist: eine Punkt-zu-Punkt-Transaktionslogik (210), die konfiguriert ist, um ein Paket zu empfangen, das einer Punkt-zu-Punkt-Typ-Transaktion (220) zugeordnet ist; eine Bus-Typ-Transaktionslogik (230), die wirksam mit der Punkt-zu-Punkt-Transaktionslogik (210) verbunden ist, wobei die Bus-Typ-Transaktionslogik (230) konfiguriert ist, um eine Bus-Typ-Transaktion (240) zu erzeugen, die der Punkt-zu-Punkt-Transaktion (220) aus dem Paket entspricht, das der Punkt-zu-Punkt-Transaktion (220) zugeordnet ist; eine Erfassungslogik (250), die wirksam mit der Punkt-zu-Punkt-Transaktionslogik (210) verbunden ist, wobei die Erfassungslogik (250) konfiguriert ist, um zu bestimmen, ob das Paket, das der Punkt-zu-Punkt-Transaktion (220) zugeordnet ist, einen Daten-Flit umfasst, der einen Nichtspeicherdatenwert codiert; und eine Decodierlogik (260), die wirksam mit der Erfassungslogik (250) und der Bus-Typ-Transaktionslogik (230) verbunden ist, wobei die Decodierlogik (260) konfiguriert ist, um den Nichtspeicherdatenwert aus dem Daten-Flit zu extrahieren, um den Nichtspeicherdatenwert zu decodieren und um selektiv den decodierten Nichtspeicherdatenwert zu der Bus-Typ-Transaktionlogik (230) zu liefern.
  12. Verfahren (300), das folgende Schritte aufweist: bei einer virtuellen Busschnittstelle, Erfassen (310) eines Fertigstellungsereignisses, das dem Empfangen einer Punkt-zu-Punkt-Transaktion zugeordnet ist, die in eine Bus-Typ-Transaktion durch die virtuelle Busschnittstelle verarbeitet werden soll; Bestimmen (320), ob die Punkt-zu-Punkt-Transaktion einen Daten-Flit umfasst, der einen Wert speichert, der in ein Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion verarbeitet werden soll; und nach dem Bestimmen, dass ein Daten-Flit einen Wert speichert, der in ein Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion verarbeitet werden soll: selektives Extrahieren (330) des Werts aus dem Daten-Flit; und Erzeugen (340) eines Anfangsblock-Typ-Werts aus dem extrahierten Wert.
  13. Verfahren (300) gemäß Anspruch 12, bei dem das Bestimmen, ob die Punkt-zu-Punkt-Transaktion einen Daten-Flit umfasst, der einen Wert speichert, der in ein Anfangsblock-Typ-Feld verarbeitet werden soll, das Untersuchen eines Transaktionstyps umfasst, der der Punkt-zu-Punkt-Transaktion zugeordnet ist.
  14. Verfahren (300) gemäß Anspruch 13, bei dem der Wert auf eine bitfeldmäßige Art und Weise aus dem Daten-Flit extrahiert (330) wird.
  15. Verfahren (300) gemäß Anspruch 14, das ferner folgende Schritte umfasst: Einrichten (410) einer Decodierfunktion für einen Punkt-zu-Punkt-Transaktionstyp, bei dem ein Daten-Flit einen Nichtspeicherdatenwert codiert; und nach dem Bestimmen, dass ein Daten-Flit einen Nichtspeicherdatenwert codiert, Weiterleiten (440) des Daten-Flits zu einer eingerichteten Decodierfunktion.
  16. Computerlesbares Medium, das prozessorausführbare Anweisungen speichert, die wirksam zum Durchführen eines Verfahrens sind, wobei das Verfahren folgende Schritte aufweist: bei einer virtuellen Busschnittstelle, Einrichten einer Decodierfunktion für einen Punkt-zu-Punkt-Transaktionstyp, bei der ein Daten-Flit einen Nichtspeicherdatenwert codiert; Erfassen eines Fertigstellungsereignisses, das dem Empfangen einer Punkt-zu-Punkt-Transaktion zugeordnet ist, die bei einer Bus-Typ-Transaktion durch die virtuelle Busschnittstelle verarbeitet werden soll; Bestimmen, ob die Punkt-zu-Punkt-Transaktion einen Daten-Flit umfasst, der einen Wert speichert, der in einem Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion verarbeitet werden soll, durch Untersuchen eines Transaktionstyps, der der Punkt-zu-Punkt-Transaktion zugeordnet ist; nach dem Bestimmen, dass ein Daten-Flit einen Wert speichert, der in ein Anfangsblock-Typ-Feld bei der Bus-Typ-Transaktion verarbeitet werden soll, Weiterleiten des Daten-Flits zu einer eingerichteten Decodierfunktion und Speichern eines decodierten Werts, der von der Decodierfunktion zurückgesendet wird.
  17. System, das folgende Merkmale aufweist: eine Einrichtung zum Bestimmen, ob eine Punkt-zu-Punkt-Transaktion, die für eine virtuelle Busschnittstelle verfügbar ist, einen Daten-Flit umfasst, der Nichtspeicherdateninformationen speichert, die in einem Bus-Typ-Anfangsblock-Typ-Feld gespeichert werden; eine Einrichtung zum bitweisen feldmäßigen Extrahieren der Nichtspeicherdateninformationen aus dem Daten-Flit; und eine Einrichtung zum Decodieren der extrahierten Nichtspeicherdateninformationen und Verfügbarmachen der decodierten Nichtspeicherdateninformationen für eine virtuelle Busschnittstellenlogik, die konfiguriert ist, um ein Anfangsblock-Typ-Feld für eine Bus-Typ-Transaktion zu erzeugen.
  18. Satz von Anwendungsprogrammierungsschnittstellen, verkörpert auf einem computerlesbaren Medium, zur Ausführung durch eine Computerkomponente in Verbindung mit dem Erzeugen eines Anfangsblock-Typ-Feldes für eine Bus-Typ-Transaktion aus Nichtspeicherdateninformationen, die in einem Daten-Flit gespeichert sind, bei einer Punkt-zu-Punkt-Typ-Transaktion, der folgende Merkmale aufweist: eine erste Schnittstelle zum Kommunizieren des Daten-Flits, der die Nichtspeicherdateninformationen codiert; eine zweite Schnittstelle zum Kommunizieren eines Nichtspeicherdatenwerts, der aus dem Daten-Flit extrahiert wird; und eine dritte Schnittstelle zum Kommunizieren eines Anfangsblock-Typ-Datenwerts für die Bus-Typ-Transaktion, wobei der Anfangsblock-Typ-Datenwert aus dem Nichtspeicherdatenwert erzeugt wird, der aus dem Daten-Flit extrahiert wird.
DE102005009542A 2004-03-29 2005-03-02 Virtuelle-Busschnittstelle-Herstellung von Anfangsblock-Typ-Feldern aus Daten-Typ-Feldern Withdrawn DE102005009542A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/812,150 2004-03-29
US10/812,150 US7065603B2 (en) 2004-03-29 2004-03-29 Virtual bus interface production of header-type fields from data-type fields

Publications (1)

Publication Number Publication Date
DE102005009542A1 true DE102005009542A1 (de) 2005-10-27

Family

ID=34991493

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102005009542A Withdrawn DE102005009542A1 (de) 2004-03-29 2005-03-02 Virtuelle-Busschnittstelle-Herstellung von Anfangsblock-Typ-Feldern aus Daten-Typ-Feldern

Country Status (2)

Country Link
US (1) US7065603B2 (de)
DE (1) DE102005009542A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050138330A1 (en) 2003-12-23 2005-06-23 Maxim Integrated Products, Inc. MAXQ microcontroller
US20050228926A1 (en) * 2004-04-05 2005-10-13 Smith Zachary S Virtual-bus interface and associated system and method
US8325768B2 (en) * 2005-08-24 2012-12-04 Intel Corporation Interleaving data packets in a packet-based communication system
US9047421B2 (en) * 2008-04-30 2015-06-02 Alcatel Lucent Serial link buffer fill-level compensation using multi-purpose start of protocol data unit timing characters
WO2010050969A1 (en) * 2008-10-31 2010-05-06 Hewlett-Packard Development Company, L.P. Sata/esata port configuration
US9507746B2 (en) * 2012-10-22 2016-11-29 Intel Corporation Control messaging in multislot link layer flit
US9176973B1 (en) * 2013-06-14 2015-11-03 Timmes, Inc. Recursive-capable lossless compression mechanism
US11558296B2 (en) * 2020-09-18 2023-01-17 Serialtek, Llc Transaction analyzer for peripheral bus traffic

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6516442B1 (en) * 1997-12-07 2003-02-04 Conexant Systems, Inc. Channel interface and protocols for cache coherency in a scalable symmetric multiprocessor system
EP0975123A1 (de) * 1998-07-15 2000-01-26 Telefonaktiebolaget L M Ericsson (Publ) Vorrichtung und Verfahren zur zuverlässichen Paketübertragung mit niedriger Verzögerung
US6591310B1 (en) * 2000-05-11 2003-07-08 Lsi Logic Corporation Method of responding to I/O request and associated reply descriptor
US20020071450A1 (en) * 2000-12-08 2002-06-13 Gasbarro Dominic J. Host-fabric adapter having bandwidth-optimizing, area-minimal, vertical sliced memory architecture and method of connecting a host system to a channel-based switched fabric in a data network
US6665742B2 (en) * 2001-01-31 2003-12-16 Advanced Micro Devices, Inc. System for reconfiguring a first device and/or a second device to use a maximum compatible communication parameters based on transmitting a communication to the first and second devices of a point-to-point link
US7401126B2 (en) * 2001-03-23 2008-07-15 Neteffect, Inc. Transaction switch and network interface adapter incorporating same
US20030110338A1 (en) * 2001-12-06 2003-06-12 Yuanlong Wang Method and apparatus for emulating computer buses using point-to-point techniues
US6857033B1 (en) * 2001-12-27 2005-02-15 Advanced Micro Devices, Inc. I/O node for a computer system including an integrated graphics engine and an integrated I/O hub

Also Published As

Publication number Publication date
US20050216638A1 (en) 2005-09-29
US7065603B2 (en) 2006-06-20

Similar Documents

Publication Publication Date Title
DE102005009542A1 (de) Virtuelle-Busschnittstelle-Herstellung von Anfangsblock-Typ-Feldern aus Daten-Typ-Feldern
DE102005010900A1 (de) Modellspezifische Registeroperationen
DE202017106613U1 (de) Verfolgung verteilter Hardware
DE112013000752T5 (de) Verwalten von Verarbeitungselementen in einem Streaming-Datensystem
DE112010003595T5 (de) Verfahren, System und maschinenverarbeitbares Medium zur Bereitstellung einer verteiltenPrädikatvorhersage
DE102005053715A1 (de) Trapmodusregister
DE112013005090T5 (de) Steuernachrichtenübermittlung in einem mehrfach-Slot-Verbindungsschicht-Flit
DE102020132716A1 (de) System zum analysieren und verbessern von software auf der basis von graph attention netzen
DE102019218259A1 (de) Ultraschallangriffsdetektion unter Verwendung von tiefem Lernen
DE112019002981T5 (de) Parallelberechnungsarchitektur mit rekonfigurierbarer kernebenen- und vektorebenen-parallelität
DE3508291A1 (de) Realzeit-datenverarbeitungssystem
WO2007082730A1 (de) Hardwaredefinitionsverfahren
DE112018004382T5 (de) Speicherbezogene Schnittstelle für Nachrichtenübergabe-Datenverarbeitungssysteme
DE102013014778A1 (de) System und verfahren zur synchronisierung von strängen in einem divergenten codegebiet
DE69130513T2 (de) Verfahren zur Durchführung boolescher Operationen zwischen zwei beliebigen Bits von zwei beliebigen Registern
WO2019025155A1 (de) Verfahren zur erzeugung von quellcode
DE112010004809T5 (de) Mehrfachgranulare Datenstromverarbeitung
DE102020121075A1 (de) Einrichtung und Verfahren zur Authentifizierung von Software
EP4315090A1 (de) Verfahren zum laufzeitbasierten konfigurieren einer geräteinternen signalübertragung in einem steuergerät sowie entsprechend betreibbares steuergerät und kraftfahrzeug
DE3138698A1 (de) Verfahren zur potenzierung grosser binaerzahlen in einer restklasse modulo n, insbesondere zur verschluesselung und entschluesselung digital dargestellter nachrichten
DE102022130856A1 (de) Eingabe-ausgabe-vorrichtung mit debug-steuerung
DE112004002178B4 (de) Stream-Unterlauf/Überlauf Recovery
DE102021130397A1 (de) Aspektorientiertes streams-computing
DE112008003630T5 (de) Shared secret, das zwischen Tastatur und Anwendung verwendet wird
DE10361059A1 (de) Verfahren und Vorrichtung zum Steuern eines Speicherzugriffs

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8139 Disposal/non-payment of the annual fee