DE112006003298T5

DE112006003298T5 - Durchführen einer auf einen Befehl auf Benutzerebene reagierenden zyklischen Redundanz-Prüfsummenoperation

Info

Publication number: DE112006003298T5
Application number: DE112006003298T
Authority: DE
Inventors: Steven R. Portland King; Frank Cornelius Berry; Michael E. Hillsboro Kounavis
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2005-12-23
Filing date: 2006-12-07
Publication date: 2009-01-08
Anticipated expiration: 2026-12-08
Also published as: TW200809488A; CN102708022A; CN102708022B; US20150155883A1; US20170242746A1; US20120240016A1; US9645884B2; US9262159B2; US20130191614A1; US20130305011A1; US20220091926A1; WO2007078672A3; US20130305118A1; US8225184B2; JP2009521059A; US11048579B2; US8775911B2; US9116684B2; US7958436B2; US8775912B2

Abstract

Verfahren, umfassend:
Empfangen ankommender Daten in einem Prozessor,
und
Durchführen einer Prüfsummenoperation an den ankommenden Daten in dem Prozessor als Reaktion auf einem Befehl auf Benutzerebene für die Prüfsummenoperation.

Description

Hintergrund
Die erfindungsgemäßen Ausführungformen beziehen sich auf die Datenverarbeitung und insbesondere auf die Bestimmung von Prüfsummen wie z. B. zyklische Redundanzprüfungen (Cyclic redundancy checks (CRC)).
Bei Datenverarbeitungssystemen ist erwünscht, dass die zwischen einer ersten und einer zweiten Stelle übertragenen Daten korrekt empfangen werden, damit die zusätzliche Verarbeitung der Daten auch an der zweiten Stelle korrekt durchgeführt werden kann. Zur Fehlererkennung in der Datenübertragung wird darüber hinaus häufig ein Datenpaket zusammen mit einer Prüfsumme übertragen. Zum Beispiel kann eine CRC-Summe durch eine Sendequelle erzeugt und an die zu übertragenden Daten angehängt werden. Diese Prüfsumme, die entsprechend einer von vielen verschiedenen Algorithmen berechnet werden kann, kann dann mit einer ähnlichen Prüfsumme, die an der Empfangsstelle aus den angekommenen Daten berechnet wird, verglichen werden. Falls die beiden Prüfsummen identisch sind, sind die übertragenen Daten korrekt. Wenn sich jedoch die erzeuge Prüfsumme von der übertragenen Prüfsumme unterscheidet, wird ein Fehler angezeigt. Derartige Prüfsummen kommen in allen Netzwerktechnologien zur Erkennung von Übertragungsfehlern zur Anwendung.
Bei verschiedenen Anwendungen gibt es für CRC-Informationen unterschiedliche Implementierungsarten. Die CRC-Berechnungen können zum Beispiel in Hardware oder in Software realisiert werden. Zur Durchführung einer CRC-Berechnung in Hardware ist typischerweise zum Ausführen der CRC-Berechnung in einem System eine dedizierte Hardwaremaschine vorgesehen. Dementsprechend werden Daten, an denen diese CRC- Berechnung vorzunehmen ist, an die Hardwaremaschine zur Berechnung der Prüfsumme, die dann an die Daten, z. B. zur Übertragung durch das System angehängt wird, gesandt. Die Benutzung einer derartigen Offload-Maschine bringt verschiedene Nachteile einschließlich des Overheads der Datensendung an die Maschine mit sich. Weiters ist es schwierig, ein zustandsloses Hardware-Offload durchzuführen. Das heißt, typischerweise sind auch zusätzliche zustandsbasierte Overhead-Daten zu übertragen, wodurch die Komplexität erhöht und der nutzbringende Arbeitsverlauf verlangsamt werden.
Da viele Systeme keine derartige Offload-Maschine aufweisen, werden CRC-Berechnungen häufig in Software durchgeführt. Zur Implementierung von CRC-Berechnungen in Software werden typischerweise Verweistabellenschemen angewandt. Derartige Software-Berechnungen von CRC-Werten sind jedoch bekanntlich langsame, rechenintensive Operationen. Darüber hinaus kann die Speicherfläche der Verweistabelle groß sein und sich dadurch auf die Leistung auswirken. Folglich können diese langsamen Berechnungen die Netzwerkleistung beeinträchtigen und weitere Verarbeitungsressourcen verbrauchen. So sind beispielsweise 5 bis 15 Zyklen erforderlich, um eine CRC-Berechnung pro Datenbyte auszuführen. Daraus ergibt sich eine zu niedrige CRC-Leistung der Software für eine allgemeine Anwendung in schnellen Netzwerken.
Kurzbeschreibung der Zeichnungen
1 zeigt ein Flussdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
2 zeigt ein Blockschaltbild eines Prozessors gemäß einer Ausführungsform der vorliegenden Erfindung.
3 zeigt ein Blockschaltbild von einem Teil eines Prozessors zur Durchführung einer Prüfsummenoperation gemäß einer Ausführungsform der vorliegenden Erfindung.
4 zeigt ein Blockschaltbild von einem anderen Teil eines Prozessors gemäß einer Ausführungsform der vorliegenden Erfindung.
5 zeigt ein Blockschaltbild eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung.
Ausführliche Beschreibung
In verschiedenen Ausführungsformen können Prüfsummenoperation durch Anwendung einer Erweiterung der Befehlssatzarchitektur (ISA) zur Berechnung der Prüfsummenwerte durchgeführt werden. Insbesondere kann ein Befehl auf Benutzerebene innerhalb einer ISA vorgesehen werden, um einem Programmierer die unmittelbare Ausführung einer erwünschten Prüfsummenoperation, wie z. B. einer CRC-Operation in einem Universalprozessor (z. B. einer Zentraleinheit (CPU)) über den Befehl zu ermöglichen. Bei der CRC-Operation kann es sich um eine 32-Bit-CRC-Operation (d. h. eine CRC32-Operation, die einen im Folgenden besprochenen 32-Bit aktiven Rest erzeugt) handeln; sie kann in verschiedenen Ausführungsformen z. B. der in einem Ethernet 802.3-Ethernet-Protokoll (herausgegeben im Jahr 2002) des Institute of Electrical and Electronics Engineers (IEEE) oder in anderen Protokollen angewandten CRC entsprechen.
In verschiedenen Implementierungen können unterschiedliche Operationscodebefehle zur Durchführung von CRC-Berechnungen an verschiedenen Datengruppen vorgesehen sein. Zum Beispiel können in bestimmten Ausführungsformen die CRC-Berechnungen auf Gruppen von 8, 16, 32 und 64 Bits unter Anwendung verschiedener Operationscodes gestützt sein, obschon der Schutzbereich der vorliegenden Erfindung nicht darauf begrenzt ist. So können CRC-Berechnungen schnell in Hardware durchgeführt werden, ohne dass es Verweistabellen oder dergleichen bedarf. Auch sind die Berechnungen unter Anwendung von generischen, architektonisch sichtbaren Prozessorregistern durch ganzzahlige Operationen durchführbar, die nach verschiedenen Operationscodes ausgeführt werden. Daraus ergibt sich, dass CRCs in einem Prozessor ohne das Erfordernis des Overheads und der Komplexität von Offload-Hardware wie z. B. Netzwerkoffload-Hardware berechnet werden können. Daher ist eine größere Anzahl an Datenübertragungen (z. B. was die Eingaben/Ausgaben (E/A) pro Sekunde betrifft) möglich. Dabei ist zu beachten, dass die Ausführungsformen der vorliegenden Erfindung hier zwar hauptsächlich im Zusammenhang mit CRC-Operationen beschrieben werden, jedoch auch auf die Ausführung anderer Prüfsummenoperation anwendbar sind.
Mit Bezug nun auf die 1 wird darin ein Flussdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das Verfahren 100 kann dazu benutzt werden, eine Prüfsumme mittels eines auf der Prozessor-Hardware, z. B. auf einem Ausführungsbauteil einer Zentraleinheit (CPU), durchgeführten Benutzerbefehls zu ermitteln. Wie in der 1 dargestellt, kann das Verfahren 100 damit beginnen, eine Reihe von Exklusiv-ODER (XOR)-Operationen an Daten in Quell- oder Zielregistern (Block 110) auszuführen. Es ist zu beachten, dass die XOR-Operationen einer polynomischen arithmetischen Operation und insbesondere einer polynomischen Teilung entsprechen können. Die Daten im Quellregister können z. B. den in einer Prozessorpipeline vorhandenen Daten, die vom Prozessor empfangen wurden oder davon zu übertragen sind, entsprechen. Beispielsweise kann eine Datengruppe in einem Puffer, die einer erwünschten Gruppengröße (z. B. 16 Bit, 32 Bit oder dergleichen) entsprechen, dem Quellregister, das ein Universalregister des Prozessors sein kann, zur Verfügung gestellt werden. Als Alternative sind in bestimmten Ausführungsformen die Quelldaten von einem Speicher erhältlich. Das Zielregister kann einer Speicherstelle für einen durch die XOR-Operationen ermittelten aktiven Rest entsprechen. Das Zielregister kann auch ein Universalregister des Prozessors sein.
Bei unterschiedlichen Ausführungsformen können die XOR-Operationen mittels dedizierter Hardware in einer Prozessorpipeline ausgeführt werden. Es kann zum Beispiel ein Ausführungsbauteil eines Prozessors, etwa ein ganzzahliges Ausführungsbauteil, durch Schaltungsbauteile erweitert werden, um eine Reihe von XOR-Operationen auszuführen. Beispielsweise können diese Schaltungsbauteile bzw. kann diese Schaltung einem XOR-Baum zur Bearbeitung einer polynomischen Teilung durch ein erwünschtes Polynom entsprechen. Bei verschiedenen Ausführungsformen kann ein Polynom zur Anwendung in den XOR-Operationen mit den logischen Gattern des XOR-Baums fest verdrahtet sein. Darüber hinaus kann der XOR-Baum zur Implementierung der erwünschten Vorverarbeitung und Nachverarbeitung über die XOR-Operationen, z. B. Bitreflexionen und dergleichen, konfiguriert werden. Auch kann die XOR-Baumlogik mehrfache Partitionen umfassen, die jeweils zur Bearbeitung von Operationen an verschiedenen Datengrößen konfiguriert sind.
Weiterhin in Bezug auf die 1 kann dann ein Resultat, das einem sich aus den XOR-Operationen ergebenden aktiven Rest entspricht, in einem Zielregister (Block 120) gespeichert werden. Es ist zu beachten, dass das Zielregister nach Initialisierung eines Systems auf einen vorbestimmten Wert, beispielsweise nur Einsen, Nullen oder auf einen anderen derartigen Wert, eingestellt werden kann. Bei der Ausführung von Prüfsummenoperationen wird dieser aktive Rest mit dem Ergebnis der laufenden Prüfsummenoperation ständig aktualisiert. Im Besonderen kann der Rest, der durch die laufende Prüfsummenoperation implementierten polynomischen Teilung im Zielregister gespeichert werden.
Danach kann bestimmt werden, ob zusätzliche Quelldaten vorhanden sind (Raute 130). In bestimmten Ausführungsformen kann zum Beispiel ein Puffer Daten enthalten, die von einem System empfangen wurden und deren Prüfsumme nachzuweisen ist. Die Daten können segmentweise in das Quellregister zur Durchführung der Prüfsummenoperation eingespeist werden. Dementsprechend kann in der Raute 130 bestimmt werden, ob sich zusätzliche Quelldaten in diesem Puffer befinden. Wenn dies der Fall ist, kann das nächste Datensegment an das Quellregister geliefert werden, und die Steuerung geht zum oben behandelten Block 110 zurück.
Wenn dagegen bei der Raute 130 bestimmt wird, dass keine zusätzlichen Quelldaten vorhanden sind, geht die Steuerung zum Block 140 weiter. Dort ist dann das Resultat der Prüfsummenoperation als der im Zielregister (Block 140) gespeicherte aktuelle Wert (z. B. aktiver Rest) lieferbar. Wie oben diskutiert, kann dieser Prüfsummenwert auf viele verschiedene Weisen gebraucht werden. Beispielsweise kann im Fall von eingegangenen Daten die berechnete Prüfsumme mit einer eingegangenen Prüfsumme verglichen werden, um den korrekten Empfang der Daten zu bestätigen. Bei einer Übertragung kann die Prüfsumme an die zu übertragenden Daten angehängt werden, so dass die Daten auf einer Empfangsseite nachgeprüft werden können. Natürlich können auch andere Anwendungen von Prüfsummen vorkommen, wie z. B. für Hash-Funktionen oder die Erzeugung von Nummern gemäß eines pseudo-zufälligen Nummerierungsschemas.
Ein Prozessor zur Durchführung von Prüfsummenoperationen nach einer erfindungsgemäßen Ausführung kann je nach der erwünschten Architektur viele verschiedene Formen annehmen. Auf die 2 verweisend, wird dort ein Blockschaltbild eines Prozessors gemäß einer Ausführung der vorliegenden Erfindung gezeigt. Wie in der 2 dargestellt, umfasst der Prozessor 200 einen Datenweg 205. Der Datenweg 205 kann durch Vorsteuerstufen gesteuert sein, die eine zum Empfang dekodierter Befehle von einem Front-End des Prozessors (nicht in der 2 gezeigt) befähigte Registerpseudonymtabelle (Register alias table (RAT)) 270 umfassen kann. Die RAT 270 kann zum Empfang von Mikrooperationen (μops) vom Front-End und zur Umbenennung der Mikrooperationen für die Ressourcen des Datenwegs eingesetzt werden. Die umbenannten Mikrooperationen können dann auf dem Datenweg 205 an einen Neuordnungspuffer (Reorder buffer (ROB)) 250 geliefert werden. Der ROB 250 kann als eine Registerdatei fungieren, um Mikrooperationen und die entsprechenden Quelloperanden zu speichern, bis die Mikrooperation für die Weitergabe an eine Reservation-Station (RS) 230 bereit ist. Ähnlich kann der ROB 250 auch die entsprechenden Resultate von schon ausgeführten Mikrooperationen speichern. Diese Ergebnisse können im ROB 250 zurückbehalten werden, bis die Mikrooperationen zurückgezogen sind (zu diesem Zeitpunkt wird die ROB-Eintrittsstelle frei).
Die Reservation-Station 230 kann zum Speichern der Mikrooperationen benutzt werden, bis deren entsprechende Quelloperanden vorhanden sind und/oder bis die Mikrooperation zur Ausführung in einer Mehrzahl von Ausführungsbauteilen des Datenwegs 205 bereit ist. Die Reservation-Station 230 kann eine Mehrzahl an Abfertigungsanschlüssen umfassen, um Befehle und Daten mit bestimmten Ausführungsbauteilen des Datenwegs 205 zu koppeln. Bei bestimmten Ausführungsformen können in jedem Zyklus vielfache Abfertigungsanschlüsse eingesetzt werden.
Wie in 2 dargestellt, umfassen die Ausführungsbauteile im Datenweg 205 ein Adressgenerationsbauteil (Address generation unit (AGU)) 220, ein Integer (INT)-Ausführungsbauteil 222, ein Speicherdaten (STD)-Bauteil 224, ein Gleitkomma (FP)-Ausführungsbauteil 226 und ein Einzelbefehl-Mehrfachdaten (SIMD)-Ausführungsbauteil 228. Wie die 2 zeigt, umfasst das Integer-Ausführungsbauteil 222 weiterhin Logik 221. Die Logik 221 kann zur Durchführung von Prüfsummenoperationen entsprechend einer erfindungsgemäßen Ausführungsform eine oder mehrere Hardwaremaschinen umfassen. Insbesondere kann die Logik 221 zur Durchführung polynomischer arithmetischer und ähnlicher Datenbehandlungen eine Vielzahl von Exklusiv-ODER (XOR)-Logikbäumen umfassen. Bei verschiedenen Ausführungsformen kann die Logik 221 unterschiedliche Hardwaremaschinen umfassen, um CRC-Operationen an Datensegmenten verschiedener Größe vorzunehmen. Beispielsweise kann eine Vielfalt von Befehlen auf Benutzerebene einer ISA jeweils eine CRC-Operation für eine gewisse Datengröße bestimmen. Bei einigen Ausführungsformen kann die Logik 221 zur Durchführung dieser verschiedenen CRC-Operationen eine entsprechende Anzahl getrennter Hardwaremaschinen, die hier auch XOR-Bäume genannt werden, umfassen.
Obschon nicht in der 2 gezeigt, können in verschiedenen Ausführungsformen zusätzliche oder verschiedene Ausführungsbauteile vorhanden sein. Nach der Ausführung einer Mikrooperation in einem der Ausführungsbauteile können die Ergebnisdaten an die RS 230 und den ROB 250 zum Speichern, beispielsweise bis zur Zurückziehung, zurückgegeben werden. Daher können sich in einer Ausführungsform die Quell- und Datenregister zur Durchführung einer CRC-Operation in der RS 230 oder im ROB 250 befinden. Obschon nicht in der 2 dargestellt, ist vorauszusetzen, dass zusätzliche Puffer, wie beispielsweise ein Speicherbefehlspuffer (MOB) und weitere Ressourcen im Prozessor 200 vorhanden sein können.
Des Weiteren ist vorauszusetzen, dass die Darstellung in der 2 zur Erleichterung der Diskussion bestimmt ist und in unterschiedlichen Ausführungsformen viel mehr Stufen oder unterschiedlich benannte Stufen in einem bestimmten Prozessor vorhanden sein können. Beispielweise kann zum Empfang von Ergebnis für die spätere Lieferung an eine Speicherhierarchie eine Write-Back-Stufe an die Ausführungsbauteile gekoppelt sein. Als Alternative kann bzw. können an die RS 230 ein bzw. mehrere weitere Puffer wie z. B. Speicherpuffer, Ladepuffer und dergleichen gekoppelt sein. Ein Beispiel davon ist die Kopplungsmöglichkeit eines oder mehrer Zurückziehungspuffer an die RS 230 zwecks Speicherung von Mikrooperationen und der damit verbundene Ergebnisdaten bis zur Zurückziehung des zugehörigen Befehls.
Es gibt natürlich auch andere Umsetzungsmöglichkeiten. Auf die 3 Bezug nehmend, wird dort ein Blockschaltbild von einem Teil eines Prozessors zur Durchführung einer Prüfsummenoperation gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie aus der 3 zu ersehen ist, wird ein Teil eines Prozessors 300 gezeigt. Insbesondere umfasst der Prozessor 300 einen XOR-Baum 310, ein erstes Register 320 und ein zweites Register 330, von denen alle ein Teil einer Prozessorpipeline sein können. Der XOR-Baum 310 kann in verschiedenen Ausführungsformen unterschiedlich konfiguriert sein. Der XOR-Baum 310 kann zum Beispiel mittels einer Vielzahl von Dreieingangs-XOR-Gattern auf einem ersten Niveau, deren Ausgänge an ähnliche XOR-Gatter auf einem zweiten Niveau u. s. w. gekoppelt sind, implementiert werden. Bei einer derartigen Ausführungsform kann jedes Niveau des XOR-Baums ein Drittel so groß wie das vorhergehende Niveau sein. Es sind natürlich auch andere Konfigurationen möglich.
Wie in der 3 weiter gezeigt wird, weist der Prozessor 300 einen Puffer 340 auf, der auch in der Prozessorpipeline sein kann (z. B. als ein Puffer, eine Warteschlange oder dergleichen). Als Alternative kann der Puffer 340 ein zum Prozessor 300 gehörender Cache-Speicher sein. In der Ausführungsform der 3 kann das erste Register 320 einem Quellregister entsprechen, während das zweite Register 330 ein Zielregister sein kann. In verschiedenen Ausführungsformen können diese Register Universalregister im Innern des Prozessors 300 sein. Der Prozessor 300 kann natürlich viele andere Register, eine Logik, Funktionseinheiten und dergleichen beinhalten, und der in der 3 gezeigte Abschnitt dient zur Erleichterung der Darstellung.
Wie in der 3 gezeigt, wird zur Durchführung einer Prüfsumme nach einer erfindungsgemäßen Ausführungsform mindestens ein erster Abschnitt des ersten Registers 320 zusammen mit einem Abschnitt des zweiten Registers 330 dem XOR-Baum 310 zur Verfügung gestellt. Bei der in der 3 gezeigten Ausführungsform, welche eine 8-Bit-CRC-Aufsummierung darstellt, wird dem XOR-Baum 310 vom ersten Register 320 ein einzelnes Datenbyte (B₀) geliefert, während ein 4-Byte-Abschnitt des zweiten Registers 330 an den XOR-Baum 310 geliefert wird. Dieser 4-Byte-Abschnitt des zweiten Registers 330 kann dem aktiven Rest einer CRC32-Operation entsprechen. Mit diesen Daten kann der XOR-Baum 310 über XOR-Operationen Datenbehandlungen durchführen, um ein einen Restabschnitt beinhaltendes Resultat zu erzeugen. Dieser Restabschnitt kann, wie in 3 gezeigt, der im zweiten Register 330 wieder gespeicherte aktive Rest sein. So können CRC-Operationen effizient in minimaler Zykluszeit und unter Einsatz minimaler Prozessorressourcen durchgeführt werden. In der Ausführungsform der 3 können für 8-Bit-Aufsummierungen dem XOR-Baum 310 zusätzliche Abschnitte des ersten Registers 320 zusammen mit dem aktuellen Inhalt des zweiten Registers (330) (d. h. der 32-Bit aktive Rest) schrittweise geliefert werden. Folglich können zur Ermittlung einer CRC-Prüfsumme an 64 Bits Daten im ersten Register 320 acht Iterationen der XOR-Operationen im XOR-Baum 310 durchgeführt werden, wobei jede ein einziges Datenbyte vom ersten Register 320 zusammen mit dem aktuellen aktiven Rest im zweiten Register 330 nimmt. Falls sich im Puffer 340 zusätzliche durch eine Prüfsumme nachzuprüfende Daten befinden, können die zusätzlichen Daten in das erste Register 320 zur darauffolgenden Verarbeitung im XOR-Baum 310 geladen werden.
Es ist zu beachten, dass zur Handhabung von CRC-Berechnungen verschiedener Bitbreiten eine unterschiedliche Hardware vorhanden sein kann. Folglich kann unter weiterem Verweis auf die 2 die Logik 221 andere XOR-Baumstrukturen zur Handhabung dieser CRC-Berechnungen umfassen. Mit Bezug nun auf die 4 wird ein Blockschaltbild von einem anderen Abschnitt eines Prozessors entsprechend einer erfindungsgemäßen Ausführungsform gezeigt. Wie die 4 zeigt, umfasst der Prozessor 300 einen anderen zum Datenempfang vom ersten und zweiten Register 320 bzw. 330 gekoppelten XOR-Baum 410 (z. B. zusätzlich zum XOR-Baum 310 der 3). Wie die 4 weiterhin zeigt, ist der Puffer 340 vorhanden und kann zur Datenlieferung für die CRC-Rechnungen benutzt werden. Zu bemerken ist, dass bei der Ausführungsform der 4 der XOR-Baum 410 für die Handhabung einer 64-Bit-CRC-Aufsummierung konfiguriert ist. Dementsprechend kann der gesamte Inhalt des ersten Registers 320 (d. h. die Bytes B₀–B₇) zu einem Zeitpunkt an den XOR-Baum 410 zum Bearbeiten in XOR-Operationen mit Daten im zweiten Register 330 gekoppelt sein. Die Ergebnisdaten, deren erwünschter Teil einem aktiven Rest entspricht, werden erneut im zweiten Register 330 gespeichert. Obschon die vorliegende Erfindung mit diesen speziellen Implementierungen in den 3 und 4 beschrieben wird, ist ihr Schutzbereich nicht darauf beschränkt, und in anderen Ausführungsformen können unterschiedliche Hardwarekonfigurationen zur Durchführung von CRC-Operationen vorhanden sein.
Mit Bezug nun auf die folgende Tabelle 1 wird eine Auflistung von Befehlsbeispielen einer Befehlssatzarchitektur (ISA) zum Stützen von CRC-Operationen entsprechend verschiedener erfindungsgemäßer Ausführungsformen gezeigt. Wie aus der Tabelle 1 zu ersehen ist, wird jeder Befehl, der mit einem Verweis auf einen Operationscode versehen sein kann, zur Durchführung einer CRC32-Operation unter Einsatz eines Quellregisters und eines Zielregisters benutzt. Wie gezeigt, sind unterschiedliche Varianten möglich, wobei jeder Befehl zum Durchführen der CRC-Operation an einer bestimmten Größe des Zieloperanden und des Quelloperanden dient. Somit wird Bezug nehmend auf die erste Zeile der Tabelle 1 dieser Befehl zum Durchführen einer CRC32-Operation an einem 8-Bit-Quelloperanden und einem 32-Bit-Zieloperanden benutzt. Ähnlich wird die zweite Zeile der Tabelle 1 benutzt, um eine CRC32-Operation an einem 16-Bit-Quelloperanden und einem 32-Bit-Zieloperanden durchzuführen. Ähnlicherweise zeigt die dritte Zeile der Tabelle 1 einen Befehl zur Durchführung einer CRC32-Operation an einem 32-Bit-Quelloperanden und einem 32-Bit-Zieloperanden.

Da diese ersten drei Befehle mit maximalen Datensegmenten von 32 Bits durchgeführt werden, ist zu bemerken, dass die Befehle in einer 64-Bit-Betriebsart sowie in einer Altbetriebsart (legacy mode) (d. h. 32-Bit) gültig sind. Dagegen bezeichnen die vierte und fünfte Zeile der Tabelle 1 CRC-Operationen, die an 8-Bit und 64-Bit-Quelloperanden bzw. mit einem 64-Bit-Zieloperanden durchzuführen sind. Daher können diese beiden letzen Befehle nur in einer 64-Bit-Betriebsart durchgeführt werden. Tabelle 1

Operationscode	Befehl	Beschreibung
Code 2	CRC32 r32, r/m8	CRC32 an r/m8 aufsummieren
Code 1	CRC32 r32, r/m16	CRC32 an r/m16 aufsummieren
Code 1	CRC32 r32, r/m32	CRC32 an r/m32 aufsummieren
Code 2	CRC32 r64, r/m8	CRC32 an r/m8 aufsummieren
Code 1	CRC32 r64, r/m64	CRC32 an r/m64 aufsummieren

Bei verschiedenen Ausführungsformen können diese Befehle auf Benutzerebene durch einen Programmierer z. B. als Intrinsics zur Implementierung einer CRC-Operation gemäß dem Flussdiagramm der 1 zum Beispiel angewandt werden.
Allgemein kann ein CRC-Befehl auf Benutzerebene folgendermaßen umgesetzt werden. Mit einem Anfangswert in einem ersten Operanden (d. h. einem Zieloperanden), kann ein CRC32-Wert für einen zweiten Operanden (d. h. einen Quelloperanden) aufsummiert und das Ergebnis erneut im Zieloperanden gespeichert werden. Bei unterschiedlichen Implementierungen kann der Quelloperand ein Register oder eine Speicherstelle sein. Der Zieloperand kann ein 32- oder 64-Bit-Register sein. Falls das Ziel ein 64-Bit-Register ist, kann das 32-Bit-Resultat im niedrigstwertigen Doppelwort und 00000000H im höchstwertigen Doppelwort des Registers gespeichert werden.
Zu beachten ist, dass der im Zieloperanden gelieferte Ausgangswert eine in einem 32-Bit-Register gespeicherte Doppelwortganzzahl oder das niedrigstwertige Doppelwort eines 64-Bit-Registers sein kann. Um einen CRC32-Wert schrittweise aufzusummieren behält die Software das Resultat der vorhergehenden CRC-Operation im Zieloperanden zurück und führt dann die CRC-Operation erneut mit neuen Eingabedaten im Quelloperanden aus. Folglich nimmt jeder Befehl einen laufenden CRC-Wert im ersten Operanden und aktualisiert den CRC-Wert auf Grundlage des zweiten Operanden. So kann eine CRC über jede erwünschte Datenmenge durch Ausführen der Operation in einer Schleife erzeugt werden, bis alle erwünschten Daten der CRC-Operation unterzogen sind.
Bei bestimmten Ausführungsformen werden die im Quelloperanden befindlichen Daten in reflektierter Bitreihenfolge verarbeitet. Das bedeutet, dass das höchstwertige Bit des Quelloperanden als das niedrigstwertige Bit des Quotienten, und so weiter, für alle Bits des Quelloperanden behandelt wird. Gleichermaßen kann das Resultat der CRC-Operation im Zielregister in reflektierter Bitreihenfolge gespeichert werden. Das bedeutet, dass das höchstwertige Bit der sich ergebenden CRC (d. h. Bit 31) im niederstwertigen Bit des Zielregisters (Bit 0) gespeichert wird, und so weiter für alle Bits der CRC.

Während verschiedene Implementierungsarten dieser Benutzerbefehle ausführbar sind, zeigen die folgenden Tabellen 2–6 Beispiele von Pseudocode-Darstellungen einer Hardware-Implementierung für einen jeden der Befehle auf Benutzerebene der Tabelle 1. Tabelle 2

CRC32-Befehl für 64-BIT-Quelloperand und 64-Bit-Zieloperand

TEMP1[63-0] ← BIT_REFLECT64 (SRC[63-0])

TEMP2[31-0] ← BIT_REFLECT32 DEST[31-0])

TEMP3[95-0] ← TEMP1[63-0]<<32

TEMP4[95-0] ← TEMP2[31-0]<<64

TEMP5[95-0] ← TEMP3[95-0]XOR TEMP4[95-0]

TEMP6[31-0] ← TEMP5[95-0]MOD2 11EDC6F41H

DEST[31-0] ← BIT_REFLECT (TEMP6[31-0])

DEST[63-32] ← 00000000H

Tabelle 3

CRC32-Befehl für 32-BIT-Quelloperand und 32-Bit-Zieloperand

TEMP1[31-0] ← BIT_REFLECT32 (SRC[31-0])

TEMP2[31-0] ← BIT_REFLECT32 DEST[31-0])

TEMP3[63-0] ← TEMP1[31-0]<<32

TEMP4[63-0] ← TEMP2[31-0]<<32

TEMP5[63-0] ← TEMP3[63-0]XOR TEMP4[63-0]

TEMP6[31-0] ← TEMP5[63-0]MOD2 11EDC6F41H

DEST[31-0] ← BIT_REFLECT (TEMP6[31-0])

Tabelle 4

CRC32-Befehl für 16-BIT-Quelloperand und 32-Bit-Zieloperand

TEMP1[15-0] ← BIT_REFLECT16(SRC[15-0])

TEMP2[31-0] ← BIT_REFLECT32 DEST[31-0])

TEMP3[47-0] ← TEMP1[15-0]<<32

TEMP4[47-0] ← TEMP2[31-0]<<16

TEMP5[47-0] ← TEMP3[47-0]XOR TEMP4[47-0]

TEMP6[31-0] ← TEMP5[47-0]MOD2 11EDC6F41H

DEST[31-0] ← BIT_REFLECT (TEMP6[31-0])

Tabelle 5

CRC32-Befehl für 8-BIT-Quelloperand und 64-Bit-Zieloperand

TEMP1[7-0] ← BIT_REFLECT8 (SRC[7-0])

TEMP2[31-0] ← BIT_REFLECT32 (DEST[31-0])

TEMP3[39-0] ← TEMP1[7-0]<<32

TEMP4[39-0] ← TEMP2[31-0]<<8

TEMP5[39-0] ← TEMP3[39-0]XOR TEMP4[39-0]

TEMP6[31-0] ← TEMP5[39-0]MOD2 11EDC6F41H

DEST[31-0] ← BIT_REFLECT (TEMP6[31-0])

DEST[63-32] ← 00000000H

Tabelle 6

CRC32-Befehl für 8-BIT-Quelloperand und 32-Bit-Zieloperand

TEMP1[7-0] ← BIT_REFLECT8 (SRC[7-0])

TEMP2[31-0] ← BIT_REFLECT32 (DEST[31-0])

TEMP3[39-0] ← TEMP1[7-0]<<32

TEMP4[39-0] ← TEMP2[31-0]<<8

TEMP5[39-0] ← TEMP3[39-0]XOR TEMP4[39-0]

TEMP6[31-0] ← TEMP5[39-0]MOD2 11EDC6F41H

DEST[31-0] BIT_REFLECT (TEMP6[31-0])

Es ist zu beachten, dass die allgemeine Struktur dieser Pseudocode-Stücke die gleiche ist. Zuerst werden die Daten in einem Quellregister bitreflektiert (d. h. dass deren Bits in umgekehrter Bitreihenfolge in ein Temporärregister gegeben werden). Das Zielregister ist ähnlich bitreflektiert. Dann können Verschiebungen und insbesondere Linksschiebungen (shift left) an den bitreflektierten Quell- und Datenoperanden vorgenommen werden. Die sich ergebenden Werte können sodann einer XOR-Operation unterzogen werden. Diese Operation kann einer polynomischen Teilung durch einen gewählten Polynomwert entsprechen. Obschon dieser Wert viele verschiedene Formen in anderen Ausführungen, insbesondere Implementierungen zur Durchführung von CRC32-Operationen, annehmen kann, kann das Polynom 11EDC6F41H entsprechen, obschon der Schutzbereich dieser Erfindung nicht darauf beschränkt ist. Der Rest dieser polynomischen Teilung (d. h. der Rest aus diesem Divisionsmodul 2) wird erneut in den niedrigstwertigen Bits des Zieloperanden in einer bitreflektierten Reihenfolge (z. B. Bits 0–31 von einem 32-Bit- oder 64-Bitregister) gespeichert. Im Fall eines 64-Bit-Registers können die höchstwertigen Bits (MSBs) mit Nullen geladen werden. Es ist davon auszugehen, dass, obschon mit dieser spezifischen Implementierung in Bezug auf die Tabellen 2–6 dargelegt, es auch andere Möglichkeiten gibt, einen CRC-Befehl auf Benutzerebene vorzusehen.
Mit der Durchführung gemäß Befehl auf Benutzerebene von CRC-Operationen direkt in einer Prozessorpipeline erübrigt sich die Übersendung von Daten an eine Offload-Maschine. Ähnlich kann die Operation ohne die Vorgabe eines Zustands durchgeführt und somit das Overhead reduziert werden. So kann bei Implementierung in einem Dreizyklusweg eine CRC-Operation in weniger als etwa 0,4 Zyklen pro Byte durchgeführt werden. Dementsprechend ist die Leistung unter Verwendung von Benutzerbefehlen zusammen mit dedizierter Hardware in einer Prozessorpipeline optimierbar. Darüber hinaus kann die Dreizyklus-Wartezeit durch ein Minimum an Flächenbedarf und Energieverbrauch erreicht werden. Die Ausführungsformen der vorliegenden Erfindung können dazu genutzt werden, die Verarbeitung verschiedener Speicherprotokolle, beispielsweise eines Internet Small Computer System Interface (iSCSI)-Protokolls (Protokoll für Internet-Kleinrechner-Systemschnittstellen), bei Geschwindigkeiten von mehr als 10 Gigabits pro Sekunde zu ermöglichen. Weiterhin ermöglichen die Ausführungsformen der vorliegenden Erfindung die Anwendung im Prozessor vorhandener oder eng daran gekoppelter Daten, wodurch der Bedarf an On-Cache-Daten auf Cache verringert wird. So können Daten in einem Prozessorpuffer einem XOR-Baum zugeführt werden, um schnelle, unmittelbare (on-the-fly (OTF)) CRC-Berechnungen zu ermöglichen.
Die Ausführungsformen können in vielen verschiedenen Systemtypen implementiert werden. Mit Bezug auf die 5 wird dort ein Blockschaltbild eines Multiprozessorsystems entsprechend einer erfindungsgemäßen Ausführungsform gezeigt. Wie die 5 zeigt, handelt es sich bei dem Multiprozessorsystem um ein Punkt-zu-Punkt-Verbindungssystem, das einen ersten Prozessor 470 und einen mit einer Punkt-zu-Punkt-Verbindung 450 gekoppelten zweiten Prozessor 480 umfasst. Wie die 5 zeigt, kann jeder der beiden Prozessoren 470 und 480 ein Mehrkernprozessor mit ersten und zweiten Prozessorkernen (d. h. Prozessorkerne 474a und 474b und Prozessorkerne 484a und 484b) sein. Obschon sie zwecks Vereinfachung der Darstellung nicht gezeigt werden, können entsprechend einer erfindungsgemäßen Ausführungsform der erste Prozessor 470 und der zweite Prozessor 480 (und insbesondere deren Kerne) im Inneren ihrer Ausführungsbauteile eine XOR-Baumlogik zum Ausführen von CRC-Befehlen auf Benutzerebene aufweisen. Der erste Prozessor 470 umfasst weiterhin einen Speichersteuerungshub (MCH) 472 und Punkt-zu-Punkt(P-P)-Schnittstellen 476 und 478. Ähnlich umfasst ein zweiter Prozessor 480 einen MCH 482 und P-P-Schnittstellen 486 und 488. Wie die 5 zeigt, koppeln MCHs 472 und 482 die Prozessoren an die entsprechenden Speicher und zwar an einen Speicher 432 und einen Speicher 434, welche an die entsprechenden Prozessoren lokal angeschlossene Teilstücke des Hauptspeichers sein können.
Der erste Prozessor 470 und der zweite Prozessor 480 können an einen Chipsatz 490 über P-P-Verbindungen 452 bzw. 454 gekoppelt sein. Wie die 5 zeigt, umfasst der Chipsatz 490 die P-P-Schnittstellen 494 und 498. Darüber hinaus umfasst der Chipsatz 490 eine Schnittstelle 492, um den Chipsatz 490 mit einer hochwertigen Grafikmaschine 438 zu verbinden. Bei einer Ausführungsform kann der Advanced-Graphics-Port(AGP)-Bus 439 zum Anschluss der Grafikmaschine 438 an den Chipsatz 490 benutzt werden. Der AGP-Bus 439 kann der am 4. Mai 1998 durch Intel Corporation, Santa Clara, Kalifornien herausgegeben Accelerated Graphics Port Interface Specification, Revision 2.0 entsprechen. Als Alternative kann eine Punkt-zu-Punkt-Verbindung 439 diese Bauteile verbinden.
Der Chipsatz 490 kann dagegen auch an einen ersten Bus 416 über eine Schnittstelle 496 angeschlossen sein. In einer Ausführungsform kann der erste Bus 416 ein Peripheral Component Interconnect (PCI)-Bus sein, wie er durch die PCI Local Bus Specification, Production Version, Revision 2.1, vom Juni 1995 definiert ist, oder ein Bus wie der PCI-Express-Bus oder ein anderer Ein-/Ausgabe-Verbindungsbus (E/A) der dritten Generation, obschon der Schutzbereich der vorliegenden Erfindung nicht darauf beschränkt ist.
Wie aus der 5 zu sehen ist, können verschiedene E/A-Geräte 414 zusammen mit einer den ersten Bus 416 an den zweiten Bus 420 koppelnden Busbrücke 418 mit dem ersten Bus 416 verbunden werden. Bei einer Ausführungsform kann der zweite Bus 420 ein Bus mit niedriger Stiftzahl (LPC) sein. Verschiedene Geräte können bei einer Ausführungsform an den zweiten Bus 420 angeschlossen sein, darunter auch zum Beispiel eine Tastatur/Maus 422, Kommunikationsgeräte 426 und ein Datenspeicherbauteil 428, das einen Code 430 aufweisen kann. Des Weiteren kann ein Audio-E/A 424 an den zweiten Bus 420 gekoppelt sein. Es ist zu beachten, dass auch andere Architekturen möglich sind. Statt der Punkt-zu-Punkt-Architektur der 5 kann ein System zum Beispiel einen Gruppenbus oder eine andere derartige Architektur implementieren.
Ausführungsformen können in Code implementiert und auf einem Datenträger gespeichert werden, auf dem Befehle zum Programmieren eines Systems zur Durchführung der Befehle gespeichert sind. Der Datenträger kann jegliche Art von Disketten, einschließlich flexibler Platten, Bildplatten, CD-ROM-Platten, CD-RW-Platten sowie magneto-optische Platten, Halbleiterbauelemente wie Festwertspeicher (ROMs), Direktzugriffsspeicher (RAMs), wie zum Beispiel dynamische Direktzugriffsspeicher (DRAMs), statische Direktzugriffsspeicher (SRAMs), löschbare programmierbare Festwertspeicher (EPROMs), Flash-Speicher, elektrisch löschbare programmierbare Festwertspeicher (EEPROMs), magnetische oder optische Karten, oder jede andere Art von Medien, die zum Speichern elektronischer Befehle geeignet sind, umfassen, ist aber nicht darauf beschränkt.
Während die vorliegende Erfindung anhand einer begrenzten Anzahl an Ausführungsformen beschrieben wurde, werden sich Fachleute auf dem Gebiet der zahlreichen Modifikationen und Abweichungen davon bewusst sein. Es ist beabsichtigt, dass die beiliegenden Patentansprüche alle derartigen Modifikationen und Abweichungen, die im wahren Geist und Schutzbereich der vorliegenden Erfindung liegen, abdecken.
Zusammenfassung
In einer Ausführungsform enthält die vorliegende Erfindung ein Verfahren zum Empfangen ankommender Daten in einem Prozessor und Durchführen einer Prüfsummenoperation an den ankommenden Daten in dem Prozessor entsprechend einem Befehl auf Benutzerebene für die Prüfsummenoperation. Zum Beispiel kann eine zyklische Redundanzprüfung in dem Prozessor selbst als Reaktion auf den Befehl auf Benutzerebene berechnet werden. Es werden weitere Ausführungsformen beschrieben und beansprucht.

Claims

Verfahren, umfassend: Empfangen ankommender Daten in einem Prozessor, und Durchführen einer Prüfsummenoperation an den ankommenden Daten in dem Prozessor als Reaktion auf einem Befehl auf Benutzerebene für die Prüfsummenoperation.
Verfahren nach Anspruch 1, das ferner Durchführen der Prüfsummenoperation in einer Pipeline des Prozessors umfasst, wobei der Prozessor einen Universalprozessor aufweist und die Prüfsummenoperation eine zyklische Redundanzprüfung (CRC) umfasst.
Verfahren nach Anspruch 1, das ferner Durchführen der Prüfsummenoperation über eine Hardwaremaschine des Prozessors umfasst, wobei der Prozessor einen Universalprozessor umfaßt.
Verfahren nach Anspruch 3, das ferner Durchführen einer polynomischen Teilung in der Hardwaremaschine als Reaktion auf den Befehl auf Benutzerebene umfasst.
Verfahren nach Anspruch 3, bei dem die Hardwaremaschine einen Exklusiv-ODER (XOR)-Baum, der an ein Quellregister und ein Zielregister angeschlossen ist, umfasst.
Verfahren nach Anspruch 5, das ferner umfaßt: Eingeben in den XOR-Baum der vom Quellregister ankommenden Daten und eines aktuellen Werts, der mindestens in einem Abschnitt des Zielregisters gespeichert ist, Durchführen einer Prüfsummenoperation im XOR-Baum unter Einsatz der ankommenden Daten und des aktuellen Werts, sowie Speichern einer Ausgabe des XOR-Baums im Zielregister.
Verfahren nach Anspruch 6, bei dem die Ausgabe des XOR-Baums einem aktiven Rest der Prüfsummenoperation entspricht.
Verfahren nach Anspruch 7, das ferner den Einsatz eines aktiven Rests als Prüfsumme, wenn ein die ankommenden Daten an das Quellregister liefernder Puffer leer ist, umfasst.
Verfahren nach Anspruch 1, das ferner umfaßt: Laden der ankommenden Daten in ein Quellregister des Prozessors, Reflektieren der ankommenden Daten, und Durchführen mindestens einer Exklusiv-ODER (XOR)-Operation mit den reflektierten ankommenden Daten und den reflektierten Daten aus einem Zielregister, und Speichern in reflektierter Reihenfolge eines Ergebnisses mindestens einer XOR-Operation im Zielregister.
Verfahren nach Anspruch 1, das ferner Durchführen einer Prüfsummenoperation in einem Logikblock des Prozessors unter Einsatz der ankommenden Daten und eines Restwerts und ohne Verweistabelleninformationen umfasst.
Vorrichtung, umfassend: ein erstes Register zum Speichern von Quelldaten, ein zweites Register zum Speichern von Ergebnisdaten, und ein an das erste Register und das zweite Register angeschlossenes Ausführungsbauteil zur Durchführung einer zyklischen Redundanzprüfung (CRC) mit den Quelldaten und den Ergebnisdaten und zur Lieferung von mindestens einem Teil einer Ausgabe des Ausführungsbauteils entsprechend eines aktiven Rests der CRC-Operation an das zweite Register.
Vorrichtung nach Anspruch 11, bei der das Ausführungsbauteil zur Durchführung der CRC-Operation als Reaktion auf einen Befehl auf Benutzerebene dient.
Vorrichtung nach Anspruch 11, bei der das Ausführungsbauteil eine Exklusiv-ODER (XOR)-Baumlogik einer Universalprozessorpipeline umfasst.
Vorrichtung nach Anspruch 13, bei der die XOR-Baumlogik zur Durchführung einer polynomischen Teilung entsprechend eines festen Polynoms dient.
Vorrichtung nach Anspruch 11, bei der das Ausführungsbauteil ein Integerbauteil einer Prozessorpipeline umfasst, wobei das Integerbauteil eine Mehrzahl separater Logikblöcke je zur Durchführung der CRC-Operation an Daten verschiedener Größe umfasst.
Vorrichtung nach Anspruch 15, bei der der Befehl auf Benutzerebene zur Angabe der Größe der Daten, an denen eine CRC-Operation durchzuführen ist, dient.
Gegenstand, der einen maschinenlesbaren Datenträger mit Befehlen aufweist, die bei deren Ausführung durch eine Maschine letztere zur Durchführung eines Verfahrens freigeben, wobei das Verfahren Aufsummieren eines Werts einer zyklischen Redundanzprüfung (CRC-Wert) aus einem Quelloperanden eines ersten Registers und einem Zieloperanden eines zweiten Registers in einem dedizierten Ausführungsbauteil einer Pipeline eines Prozessors, Speichern des aufsummierten CRC-Werts im zweiten Register, und Bestimmen, ob zusätzliche Daten der CRC zu unterziehen sind, umfasst.
Gegenstand nach Anspruch 17, bei dem das Verfahren weiterhin schrittweises Aufsummieren des CRC-Werts und Speichern des schrittweise aufsummierten CRC-Werts im zweiten Register, bis keine Daten mehr der CRC zu unterziehen sind, umfasst.
Gegenstand nach Anspruch 17, bei dem das Verfahren ferner Aufsummieren des CRC-Werts als Reaktion auf einen Befehl einer Befehlssatzarchitektur des Prozessors für die CRC umfasst.
Gegenstand nach Anspruch 19, bei dem das Verfahren ferner Aufsummieren des CRC-Werts in einem von vielen Abschnitten des dedizierten Ausführungsbauteils auf Grundlage einer Größe des Quelloperanden umfasst, wobei der Befehl dazu dient, die Größe des Quelloperanden anzugeben.
System, umfassend: einen Prozessor mit einem ersten und einem zweiten Ausführungsbauteil zum Durchführen von Operationen als Reaktion auf Befehle einer Befehlssatzarchitektur (ISA) für den Prozessor, wobei das erste Ausführungsbauteil eine Hardwaremaschine zum Durchführen von Operationen der zyklischen Redundanzprüfung (CRC) aufweist, der Prozessor ferner ein erstes Register zum Liefern eines Quelloperanden an die Hardwaremaschine und ein zweites Register zum Liefern eines Zieloperanden an die Hardwaremaschine aufweist, und einen an den Prozessor angeschlossenen dynamischen Direktzugriffsspeicher (DRAM).
System nach Anspruch 21, bei dem das erste Ausführungsbauteil ein Integerbauteil und das zweite Ausführungsbauteil ein Gleitkommabauteil umfasst.
System nach Anspruch 21, bei dem der Prozessor einen Puffer aufweist, um Daten an das erste Register zu liefern.
System nach Anspruch 23, bei dem die Hardwaremaschine zur Durchführung einer CRC-Operation an Daten als Reaktion auf einen oder mehrere Befehle der ISA für die CRC-Operation, bis der Puffer leer ist, dient.
System nach Anspruch 24, bei dem die Hardwaremaschine zur Lieferung eines aktiven Rests der CRC-Operation an das zweite Register dient.
System nach Anspruch 21, bei dem die Hardwaremaschine eine Vielzahl von Logikblöcken umfasst, die jeweils eine CRC-Operation an Daten verschiedener Größe durchführen.
System nach Anspruch 26, bei dem die Hardwaremaschine zur Lieferung von Daten an einen von vielen Logikblöcken entsprechend einer bestimmten Datengröße dient, um die CRC-Operation als Reaktion auf einen Befehl der ISA für die CRC-Operation der bestimmten Datengröße durchzuführen.