DE112007001991T5

DE112007001991T5 - Verfahren und System zum Validieren eines Schreibvorgangs für eine Baugruppe auf einem seriellen Bus

Info

Publication number: DE112007001991T5
Application number: DE112007001991T
Authority: DE
Inventors: Robert Forest Grove Dunstan; John Mountain View Horigan
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2006-09-29
Filing date: 2007-09-28
Publication date: 2009-06-10
Also published as: US20080082544A1; GB2454439A; GB2454439A8; CN101512990B; GB2454439B; CN101512990A; WO2008042808A1; GB0904298D0; US8165160B2

Abstract

Verfahren, das aufweist:
Berechnen eines ersten Prüfsummenbytes durch einen Absender einer Nachricht;
Anhängen des ersten Prüfsummenbytes an eine Nachricht;
Senden der Nachricht von dem Absender an einen Client über einen seriellen Eindraht-Bus;
Bestimmen, durch den Client, einer Gültigkeit der Nachricht von dem Absender, indem das erste Prüfsummenbyte mit einer zweiten Prüfsumme, die von dem Client berechnet wird, verglichen wird.

Description

HINTERGRUND
Ein Eindraht-Bus kann verwendet werden, um Daten zwischen Host- und Client-Baugruppen zu kommunizieren. Befehle, die zwischen den Host- und den Client-Baugruppen kommuniziert werden, können in manchen Fällen einen wesentlichen betrieblichen Einfluss auf den Host, die Client-Baugruppen und zugeordnete Baugruppen, Systeme, Plattformen und Betriebsumgebungen haben. Im Allgemeinen können Daten zwischen den Host- und den Client-Baugruppen geschrieben und gelesen werden. In manchen Fällen kann eine Nachricht, die einen Befehl enthält, von dem Host an eine oder mehrere der Client-Baugruppen gesendet werden, um eine Tätigkeit durch die Client-Baugruppen aufzurufen. Aufgrund von Fehlern in der Kommunikation kann es sein, dass eine Nachricht, die über den Eindraht-Bus verschickt wird, nicht richtig von einer Client-Baugruppe erhalten wird, und/oder Daten, die von der Client-Baugruppe zurückgegeben werden, können unrichtig sein.
Gemäß einigen Schreib-Lese-Protokollen kann ein Absender einer Nachricht (z. B. ein Host) eine Angabe erhalten, dass eine ins Ziel gefasste Client-Baugruppe die Nachricht richtig empfangen hat und Daten, die von der Client-Baugruppe zurückgegeben werden, richtig sind. Jedoch kann die Client-Baugruppe weiterhin eine ungültige Nachricht akzeptieren und nach ihr handeln, basierend auf einem Kommunikationsfehler, den die Client-Baugruppe selbst nicht erfassen kann.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist eine beispielhafte Veranschaulichung eines Systems gemäß einigen Ausführungsformen hierin;
2 ist eine beispielhafte Veranschaulichung einer Nachricht in Bezug auf einige Ausführungsformen hierin;
3 ist ein Ablaufdiagramm eines Prozesses gemäß einigen Ausführungsform hierin;
4 ist eine beispielhafte Veranschaulichung einer Nachricht, die sich auf einige Ausführungsformen hierin bezieht;
5 ist ein Ablaufdiagramm eines Prozesses gemäß einigen Ausführungsformen hierin; und
6 ist eine beispielhafte Veranschaulichung eines Systems gemäß einigen Ausführungsformen hierin
GENAUE BESCHREIBUNG
Die verschiedenen Ausführungsformen, die hierin beschrieben sind, dienen lediglich dem Zweck der Veranschaulichung. Ausführungsformen können jedwede gegenwärtig verfügbaren oder hiernach bekannten Versionen der Elemente, die hierin beschrieben sind, umfassen. Daher werden Fachleute aus dieser Beschreibung erkennen, dass andere Ausführungsformen mit verschiedenen Modifikationen und Abänderungen in die Praxis umgesetzt werden können.
Mit Bezug auf 1 ist dort ein beispielhaftes schematisches Schaubild eines Kommunikationssystems 100 gemäß einigen Ausführungsformen hierin mit einem Eindraht-Bus gezeigt. Bei manchen Ausführungsformen kann ein Bus 130 einen seriellen Eindraht-Bus umfassen. Ein Host 105 ist mit dem Bus 130 verbunden. Eine Vielzahl von Client-Baugruppen 110, 115, 120 und 125 ist ebenfalls mit dem Bus 130 verbunden. Der Host 105 und die Client-Baugruppen 110, 115, 120 und 125 können digitale Daten zwischen dem Host und den Client-Baugruppen über den Bus 130 transportieren. Eine oder mehrere Client-Baugruppen, so wie zum Beispiel die Client-Baugruppen 110 und 115, können feste Adressen haben. Eine oder mehrere Client-Baugruppen, so wie zum Beispiel die Client-Baugruppen 120 und 125, können dynamisch zugewiesene Adressen haben. Somit können manche Ausführungsformen des Systems 100 eine Kombination von Client-Baugruppen mit festen und dynamisch zugeordneten Adressen umfassen.
Obwohl das System mit einem Eindraht-Bus, das in der 1 gezeigt ist, einen Host und mehrere Client-Baugruppen umfasst, können einige Ausführungsformen eines Systems 100 einen Host und eine Client-Baugruppe umfassen. Bei manchen Ausführungsformen kann das System 100 einen Absender von Nachrichten umfassen und bei anderen Ausführungsformen kann das System 100 mehrere Absender von Nachrichten umfassen.
Bei manchen Ausführungsformen entspricht eine Nachricht für den Bus 130 des Systems 100 einem Protokoll, das einen Nachrichtenkopf und Daten umfasst. Das Nachrichtenprotokoll kann die Datengeschwindigkeit der Nachricht einstellen, Information im Hinblick auf die Nachricht zur Verfügung stellen und die Datenintegrität sicherstellen. Zum Beispiel kann eine Zeitverhandlung verwendet werden, um eine Bitrate für die Nachricht einzurichten, eine Adresse einer Ziel-Client-Baugruppe kann festgelegt werden und weitere Eigenschaften der Nachrichten können in dem Nachrichtenkopf der Nachricht zur Verfügung gestellt werden.
2 zeigt ein beispielhaftes Schreib-Lese-Protokoll 200 gemäß einigen Ausführungsformen hierin. Insbesondere sorgt das Schreib-Lese-Protokoll 200 für den Nachrichtentransport zwischen den Baugruppen auf dem Bus 130. Das Schreib-Lese-Protokoll 200 schreibt zunächst Daten zwischen einem Absender einer Nachricht (z. B. dem Host 105) und einem Ziel-Client (z. B. einem oder mehreren der Clients 110, 115, 120 und 125).
Entsprechend dem Schreib-Lese-Protokoll 200 umfasst eine Nachricht einen Nachrichtenkopf und Datenkomponenten. Der Nachrichtenkopf umfasst Zeitverhandlungs(TN – Timing Negotiation)-Bits 205 für die Adresse, die die Bitrate für den Adressteil der Nachricht einstellen (2 Bit); eine Ziel-Adresse 210, die die Adresse der Zielbaugruppe festlegt (8 Bit); ein Nachrichtenzeit(MT – Message Timing)-Verhandlungsbit 215, das verwendet wird, um die Zeitplanung zwischen dem Absender der Nachricht und den ins Ziel gefassten (z. B. adressierten) Client-Baugruppe(n) für den verbleibenden Teil der Nachricht zu behandeln (1 Bit); eine Schreiblänge 220, das N Bytes der Daten festlegt, die der Absender plant abzusenden (8 Bit); und eine Leselänge 225, die M Bytes aus Daten festlegt, die der Absender erwartet zu empfangen (8 Bit). Die N Bytes der Schreibdaten 230–240 sollen in die Ziel-Baugruppe geschrieben werden und die M Bytes der Lesedaten 250–255 sollen von dem Ziel-Client zurückgelesen werden.
Bei manchen Ausführungsformen kann sowohl die Schreiblänge als auch die Leselänge Null sein. In einem solchen Fall wird die Nachricht als eine Nullnachricht bezeichnet und definiert einen Baugruppen-'Ping', der von allen Baugruppen unterstützt wird, die mit dem Bus 130 verbunden sind.
Die Schreibdaten, die N Bytes mit Daten aufweisen, können als Option einen Befehl enthalten. Bei manchen Ausführungsformen ist der Befehl das erste Byte 230 der Schreibdaten.
Bei manchen Ausführungsformen erfordert jede Nachricht wenigstens ein Prüfsummenbyte für einen Frame. Das Prüfsummenbyte stellt einen Mechanismus zur Verfügung, um ein zuverlässiges Austauschen von Daten zwischen dem Absender und dem/den ins Ziel gefassten Client(s) sicherzustellen. Der Absender der Nachricht und die Client-Baugruppe(n) führen beide Prüfsummenberechnungen durch. Bei manchen Ausführungsformen können die Prüfsummenbytes hierin als ein Ergebnis einer Frame-Prüfsequenz (FCS – Frame Check Sequence) in einer zyklischen Redundanzprüfung (CRC – Cyclic Redundancy Check) für 8 Bit bei jedem Datenblock, die der CRC vorangeht, erhalten werden.
Bei manchen Ausführungsformen kann die zyklische Redundanzprüfung für 8 Bit, die von der Schreib-FCS und der Lese-FCS verwendet wird, hierin durch das Polynom C(x) = x⁸ + x² + x + 1 dargestellt werden. Es sollte verstanden werden, dass die CRC, die bei der Berechnung der Prüfsummen hierin verwendet wird, andere CRCs als das Polynom CRC-8 enthalten kann.
Die Schreib-FSC in der Nachricht schließt bei manchen Ausführungsformen die TN-Bits 205 oder die MT-Bits 215 nicht ein. Die Schreib-FCS 245 schließt jedoch das Adressbyte 210, ein Schreiblängenbyte 220 und ein Leselängenbyte 225 bei ihrer Berechnung ein.
Bei manchen Ausführungsformen wird ein Byte 245 für die Schreib-FCS an den Absender 105 der Nachricht von dem ins Ziel gefassten Client zurückgegeben, nachdem der Nachrichtenkopf und die N Datenbytes (z. B. 230–240) geschrieben sind. Das Schreiblängenbyte in dem Nachrichtenkopf wird von dem ins Ziel gefassten Client verwendet, um zu bestimmen, wann der ins Ziel gefasste Client die Schreib-FCS zurückgeben sollte. Der ins Ziel gefasste Client (z. B. der Client 110) ist aufgefordert, die Schreib-FCS über den Nachrichtenkopf zurückzugeben, selbst wenn das Schreiblängenfeld Null ist (d. h. keine zusätzlichen Datenbytes geschrieben sind).
Wenn Daten von dem/den Ziel-Client(s) gelesen werden, folgt den gelesenen Daten (z. B. den Bytes 250–255) eine Lese-FCS 260. Das Byte 260 der Lese-FCS wird von dem Ziel-Client getrieben. Das Byte 225 für die Leselänge wird von dem Ziel-Client verwendet, um die Anzahl der Datenbytes zu bestimmen, die der Client an den Absender der Nachricht liefern muss, bevor die Lese-FCS 260 über diese Daten zurückgegeben wird. Die Schreib-FCS 245 und die Lese-FCS 260 sind nicht als ein Teil der Leselänge enthalten.
Die Schreib-FCS 245 und die Lese-FCS 260 werden von dem/den Ziel-Client(s) geliefert und getrieben. Diese FCSs, die von dem Ziel-Client an den Absender geliefert werden, versorgen den Absender 105 mit Mechanismen, um festzustellen, ob ein Schreibvorgang erfolgreich ist und ob Lesedaten richtig empfangen worden sind.
Bei manchen Ausführungsformen hierin wird eine Prüfsumme 240 über ein gesichertes Schreiben (AW – Assured Write) der FCS an den Nachrichtenkopf und die Schreibdaten angehängt. Die Prüfsumme 240 kann von dem Ziel-Client verwendet werden, um die Inhalte der Nachricht zu validieren, der Ziel-Client kann somit die AW FCS 240 verwenden, um Inhalte der Nachricht zu verifizieren, bevor die Client-Baugruppe aufgrund der Nachricht tätig wird.
Bei manchen Ausführungsformen ist die AW (Assured Write) FCS 240 das Ergebnis einer zyklischen Redundanzprüfung (CRC) für 8 Bit. Bei manchen Ausführungsformen kann die AW FCS 240 dasselbe Polynom C(x) = x⁸ + x² + x + 1 bei der zyklische Redundanzprüfung für 8 Bit verwenden, das bei der Berechnung der Schreib-FCS 245 und der Lese-FCS 260 verwendet wurde.
Es wird angemerkt, dass die CRC, die bei der Berechnung der AW FCS 240 verwendet wird, andere CRCs als das Polynom CRC-8 verwendet kann. Es wird auch angemerkt, dass das Anhängen einer CRC-8 und dann das Neuberechnen einer CRC-8 eine Tautologie ist, die, in dem Fall, dass ein einziger CRC-Generator in der Client-Baugruppe verwendet wird, immer zu einer Null führt. Bei manchen Ausführungsformen hierin kann die Client-Baugruppe zum Beispiel für Zwecke der einfachen Implementierung und/oder von Kostenbeschränkungen einen CRC-Generator enthalten. Bei manchen beispielhaften Fällen kann eine Nachricht von dem Absender 105 der Ziel-Baugruppe für die Nachricht befehlen, eine Tätigkeit auszuführen, so wie zum Beispiel das Konfigurieren des Ziel-Client, über eine Zeitdauer abzuschalten. Ohne irgendein Verfahren, einen Mechanismus oder ein System, um die Inhalte der Nachricht zu verifizieren, kann der Ziel-Client irreversible oder möglicherweise schädliche Tätigkeiten als Antwort auf nicht korrekte oder ungültige Nachrichten ausführen. Die AW FCS 240 vereinfacht es dem Ziel-Client, die Gültigkeit der Nachricht zu verfizieren, bevor der Ziel-Client auf die Nachricht reagiert. Auf diese Weise kann der Ziel-Client des vorangegangenen Beispiels zum Beispiel vermeiden, dass er sich fälschlich selbst vom Bus nimmt.
Noch mit Bezug auf die 2 ist die AW FCS 240 in der Nachricht als das Nte Schreibdatenbyte innerhalb der Schreibdaten enthalten. Bei manchen Ausführungsformen wird nach der FCS-Berechnung des (N – 1)ten Schreibdatenbytes eine vorläufige FCS-Berechnung der AW FCS von dem Absender modifiziert. Die vorläufige FCS-Berechnung der AW FCS wird so modifiziert, dass die Schreib-FCS 245, die von der Ziel-Client-Baugruppe in dem nächsten Byte zurückgegeben wird, von Null verschieden ist. Bei Ausführungsformen wird dieselbe CRC-Berechnung sowohl für die AW FCS als auch für die Schreib-FCS verwendet, wobei die Schreib-FCS 245, die von der Ziel-Client-Baugruppe zurückgegeben wird, immer Null sein würde (z. B. 0x00).
Bei manchen Ausführungsformen wird die Modifikation der vorläufigen FCS bewerkstelligt, indem das höchstwertige Bit, msb (most significant bit), der FCS-Berechnung des (N – 1)ten Schreibdatenbytes invertiert wird. Auf diese Weise würde, wenn die FCS-Berechnung des (N – 1)ten Datenbytes 0xc4 ist, dann dessen invertiertes msb eine AW FCS gleich 0x44 liefern.
Bei manchen Ausführungsformen vermeidet die Verwendung unterschiedlicher CRC-8 Algorithmen, um die AW FCS- und die Schreib-FCS-Werte bei dem Client zu berechnen, das Problem, dass eine Prüfsumme modifiziert werden müsste, um einen anschließenden Prüfsummenwert von Null zu vermeiden. Das heißt, bei manchen Ausführungsformen kann der Client zwei CRC-Generatoren haben, die unterschiedliche CRC-Algorithmen verwenden.
Als ein Beispiel kann eine Nachricht mit einem Befehls/Datensatz aus 3 Bytes, 0x(10 e2 39) eine daran angehängte AW FCS haben, um eine vollständige geschriebene Sequenz 0x(20 04 00 10 e2 39 50) zu erhalten, wobei 0x(20 04 00) den Nachrichtenkopf der Nachricht aufweist. Die Ziel-Client-Baugruppe antwortet mit einem Schreib-FCS-Byte 0x89. Die AW FCS erhöht die Schreiblänge der Nachricht um 1, und die AW FCS wird als die CRC-8 des vorigen Bytes (0xd0) hinzugefügt, wobei das msb invertiert wird, so dass sich 0x50 ergibt.
3 veranschaulicht ein beispielhaftes Ablaufdiagramm eines Verfahrens 300 gemäß einigen Ausführungsformen hierin. Im Arbeitsschritt 305 wird ein erstes Prüfsummenbyte von einem Absender einer Nachricht berechnet. Die erste Prüfsumme entspricht der AW FCS 240, die in der 2 veranschaulicht ist. Die erste Prüfsumme wird im Arbeitsschritt 310 an eine Nachricht von dem Absender der Nachricht angehängt. Die Nachricht, einschließlich der ersten Prüfsumme, kann dem Nachrichtenprotokoll entsprechen, das hierin mit Bezug auf die 2 gezeigt und diskutiert worden ist.
Im Arbeitsschritt 315 wird die Nachricht von dem Absender an einen Client über einen seriellen Eindraht-Bus verschickt. Der Bus sorgt für die Kommunikation zwischen dem Absender und dem Client. Die Nachricht umfasst einen Nachrichtenkopf und Daten. Bei manchen Ausführungsformen umfassen die Daten N Bytes Schreibdaten, wobei das Nte Schreibdatenbyte die erste Prüfsumme ist.
Bei manchen Ausführungsformen kann eine vorläufige Prüfsummenberechnung in einem Prozess des Berechnens der ersten Prüfsumme modifiziert werden. Die Modifikation kann vorgenommen werden, um für eine unmittelbar nachfolgende Prüfsummenberechnung einen von Null verschiedenen Wert zu erhalten. Der Modifikationsprozess kann als ein Teil von oder getrennt von anderen Arbeitsschritten des Prozesses 300 vorgenommen werden, einschließlich des Arbeitsschrittes 305.
Im Arbeitsschritt 320 kann eine Feststellung von dem Client im Hinblick auf die Gültigkeit der Nachricht von dem Absender getroffen werden. Die Feststellung kann auf einem Vergleich der ersten Prüfsumme und einer zweiten Prüfsumme, die intern von dem Client erzeugt worden ist, basieren. Eine Übereinstimmung zwischen der ersten Prüfsumme und der zweiten Prüfsumme, die intern von dem Client erzeugt worden ist, kann angeben, dass die Inhalte der Nachricht gültig sind, während eine Nichtübereinstimmung zwischen der ersten Prüfsumme und der zweiten Prüfsumme, die von dem Client erzeugt worden ist, angeben kann, dass die Inhalte der Nachricht ungültig sind. In dem Fall, dass für die Nachricht von dem Client festgestellt wird, dass sie ungültig ist, wobei die erste Prüfsumme verwendet wird, kann der Client antworten, indem er nicht auf die Nachricht hin handelt.
Die Verwendung der AW FCS in dem Schreibprotokoll der Nachricht sorgt für einen Mechanismus für den Ziel-Client der Nachricht, ein Maß der Sicherheit zu haben, dass die Daten, die von dem Ziel-Client erhalten worden sind, korrekt/gültig sind, bevor er sich verpflichtet, die Daten zu verwenden.
4 zeigt ein beispielhaftes Schreib-Lese-Protokoll 400 gemäß einigen Ausführungsformen hierin. Insbesondere kann das Schreib-Lese-Protokoll 400 einen Mechanismus zur Verfügung stellen, durch den ein Client folgern kann, ob eine Nachricht nicht korrekt/ungültig ist, basierend auf einem Verhalten des Absenders der Nachricht in einem System mit einem Eindraht-Bus. Das Schreib-Lese-Protokoll 400 kann zunächst Daten zwischen dem Absender einer Nachricht (z. B. dem Host 105) und einem Ziel-Client (z. B. den Clients 110, 115, 120 und 125) schreiben.
Gemäß dem Schreib-Lese-Protokoll 400 umfasst eine Nachricht einen Nachrichtenkopf und Datenkomponenten. Der Nachrichtenkopf umfasst TN-Bits 405, eine Zieladresse 410, ein MT-Verhandlungsbit 415, eine Schreiblänge 420, die N Bytes der Daten festlegt, die der Absender zu senden plant; und eine Leselänge 425, die die M Bits der Daten festlegt, die der Absender zu empfangen erwartet. Die N Bytes der Schreibdaten 430–440 sollen an die Ziel-Baugruppe geschrieben werden, und die M Bytes der Lesedaten 450–455 sollen von der Ziel-Baugruppe zurückgelesen werden.
Bei manchen Ausführungsformen, die dem Schreib-Lese-Protokoll 400 entsprechen, kann die Schreiblänge Null sein, jedoch ist die Leselänge wenigstens ein Byte lang.
Aspekte des Nachrichtenkopfes und der Datenkomponenten des Nachrichtenprotokolls 400 können ähnlich dem Nachrichtenkopf und den Datenkomponenten sein, die hierin mit Bezug auf die 2 diskutiert worden sind. Demgemäß wird eine Diskussion von ähnlichen Aspekten des Protokolls 400, die bereits an andere Stelle hierin mit Bezug auf die 2 diskutiert worden sind, nicht wieder in Einzelheiten geführt werden. Ein Bezug wird stattdessen hergestellt, indem auf die 2 verwiesen wird.
Bei manchen Ausführungsformen, wie sie in dem beispielhaften Ablaufdiagramm 500 der 5 veranschaulicht sind, kann eine Nachricht, die dem Schreib-Lese-Protokoll 400 anhaftet, im Arbeitsschritt 505 von dem Absender an einen Client über einen Eindraht-Bus geschickt werden. Im Arbeitsschritt 510 kann der Absender 105 eine Rückgabe eines nicht gültigen Prüfsummenbytes von dem Client in Erwiderung auf das Abschicken der Nachricht von dem Absender erfassen. Bei manchen Ausführungsformen entspricht die zurückgegebene Prüfsumme der Schreib-Bus FCS 340.
Ein gefordertes Verhalten für den Absender beim Empfang einer ungültigen zurückgegebenen Prüfsumme (d. h. der Schreib-FCS) kann sein, eine Master-Abbruchoperation aufzurufen, mit der die Nachricht abgebrochen wird. Weitere Anforderungen können diktieren, dass der Abbruch innerhalb einer vorbestimmten Zeitdauer geschieht. Bei manchen Ausführungsformen entspricht die vorbestimmte Zeitdauer einem unmittelbar nächsten Bytezyklus. Das Abbruchverhalten des Absenders, der mit dem Bus verbunden ist, kann von einem Client, der mit dem Bus verbunden ist, verwendet werden, um daraus zu schließen, dass die Nachricht nicht korrekt/ungültig ist. Umgekehrt kann das Fehlen der Abbruchoperation so ausgelegt werden, dass die Nachricht von dem Absender richtig oder gültig ist.
Die vorbestimmte Dauer, während der der Absender feststellen muss, ob die zurückgegebene Prüfsumme (d. h. die Schreib-FCS) gültig ist und die Abbruchoperation aufrufen muss, kann einem Lesebytezyklus entsprechen. Demgemäß wird eine Nachricht von dem Absender versendet und die Prüfsumme wird von der Ziel-Client-Baugruppe zurückgegeben. Während des Lesens des ersten Lese-Datenbytes 345 bestimmt der Absender, ob die zurückgegebene Prüfsumme gültig ist, und ruft die Abbruchoperation auf, wenn sie nicht gültig ist. Somit ist ge zeigt worden, warum bei manchen Ausführungsformen die Schreiblänge wenigstens ein Byte beträgt.
5 veranschaulicht ein beispielhaftes Ablaufdiagramm eines Verfahrens 500 gemäß einigen Ausführungsformen hierin. Im Arbeitsschritt 505 wird eine Nachricht von einem Absender der Nachricht an einen Client über einen seriellen Eindraht-Bus geschickt. Im Arbeitsschritt 510 erfasst der Absender ein ungültiges Prüfsummenbyte (z. B. die Schreib-FCS), das von dem Client in Erwiderung auf die Nachricht, die von dem Absender verschickt worden ist, zurückgegeben worden ist.
Nach dem Bestimmen, dass die zurückgegebene Prüfsumme ungültig oder ansonsten nicht richtig ist, bricht der Absender die Nachricht im Arbeitsschritt 515 ab. Der Absender trifft die Feststellung, dass die Nachricht abzubrechen ist, innerhalb einer vorbestimmten Zeitdauer. Basierend auf den Abbruchtätigkeiten für die Nachricht durch den Absender kann die Client-Baugruppe schließen, ob die Schreib-FCS gültig oder ungültig war.
6 ist ein beispielhaftes schematisches Schaubild eines Kommunikationssystems 600 mit einem seriellen Eindraht-Bus gemäß einigen Ausführungsformen hierin. Ein Host 605 ist mit einem Bus 630 verbunden. Eine Vielzahl von Client-Baugruppen 610, 615, 620 und 625 ist ebenfalls mit dem Bus 630 verbunden. Der Host 605 und die Client-Baugruppen 610, 615, 620 und 625 übermitteln Daten zwischen dem Host und den Client-Baugruppen über den Bus 630. Die Client-Baugruppen des Systems 600 können feste oder dynamische Adressen haben. Das System 600 kann in vieler Hinsicht dem System 100 ähnlich sein. Jedoch umfasst das System 600 ein Speichermodul 675, das mit dem Bus 630 verbunden ist. Der Bus 630 kann verwendet werden, um Konfigurationsinformation in das Speichermodul 675 zu schreiben, nicht als ein primärer Kanal zum Lesen/Schreiben von Daten aus/in den Speicher. Das Speichermodul 675 kann zum Beispiel Daten umfassen, aufgrund derer gearbeitet werden kann, in Abhängigkeit von den Tätigkeiten des Host und des Client, und/oder die in einer Nachricht von dem Absender enthalten sind.
Bei manchen Ausführungsformen kann das System 600 mit den hierin offenbarten Schreib/Lese-Protokollen kompatibel sein, einschließlich denjenigen, die im Hinblick auf die 2 und 4 diskutiert worden sind.
Obwohl das System mit Eindraht-Bus, das in der 1 gezeigt ist, einen Host und mehrere Client-Baugruppen umfasst, können einige Ausführungsformen eines Systems mit Eindraht-Bus hierin einen Host und eine Client-Baugruppe umfassen. Bei manchen Ausführungsformen kann ein System mit Eindraht-Bus einen Absender einer Nachricht umfassen und bei anderen Ausführungsformen kann ein System mit einem Eindraht-Bus mehrere Absender von Nachrichten umfassen.
Die voranstehende Offenbarung ist mit Bezug auf bestimmte beispielhafte Ausführungsformen beschrieben worden. Es wird jedoch offensichtlich sein, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne dass man sich von dem breiteren Gedanken und Umfang entfernt, der in den angefügten Ansprüchen definiert ist.
ZUSAMMENFASSUNG
Verfahren und System, wobei das Verfahren bei manchen Ausführungsformen das Berechnen eines ersten Prüfsummenbytes durch einen Absender einer Nachricht, das Anhängen des ersten Prüfsummenbytes an die Nachricht, das Senden der Nachricht von dem Absender an einen Client über einen eindrahtigen seriellen Bus und das Feststellen, durch den Client, einer Gültigkeit der Nachricht von dem Absender durch Vergleichen des ersten Prüfsummenbytes mit einer zweiten Prüfsumme, die von dem Client berechnet worden ist.

Claims

Verfahren, das aufweist: Berechnen eines ersten Prüfsummenbytes durch einen Absender einer Nachricht; Anhängen des ersten Prüfsummenbytes an eine Nachricht; Senden der Nachricht von dem Absender an einen Client über einen seriellen Eindraht-Bus; Bestimmen, durch den Client, einer Gültigkeit der Nachricht von dem Absender, indem das erste Prüfsummenbyte mit einer zweiten Prüfsumme, die von dem Client berechnet wird, verglichen wird.
Verfahren nach Anspruch 1, bei dem der Client feststellt, dass die Nachricht gültig ist, wenn das erste Prüfsummenbyte gleich dem zweiten Prüfsummenbyte ist, und dass die Nachricht ungültig ist, wenn das erste Prüfsummenbyte nicht gleich dem zweiten Byte ist.
Verfahren nach Anspruch 1, bei dem das erste Prüfsummenbyte und das zweite Prüfsummenbyte eine Frame-Prüfsequenz (FCS – Frame Check Sequence) einer zyklischen Redundanzprüfung (CRC – Cyclic Redundancy Check) für 8 Bit von jedem von wenigstens einem Datenbyte, aufweist, die den jeweiligen Prüfsummen vorangeht.
Verfahren nach Anspruch 1, bei dem die Nachricht N Byte Schreibdaten aufweist, in denen das erste Prüfsummenbyte enthalten ist.
Verfahren nach Anspruch 4, bei dem die Nachricht weiter eine Adresse, eine Leselänge und eine Schreiblänge aufweist.
Verfahren nach Anspruch 4, bei dem das erste Prüfsummenbyte berechnet wird, indem ein Ergebnis einer Berechnung des Prüfsummenbytes nach dem (N – 1)ten Schreibdaten byte abgeändert wird und an die Nachricht als das Nte Schreibdatenbyte angehängt wird.
Verfahren nach Anspruch 6, bei dem das Abändern das Invertieren eines höchstwertigen Bits des Ergebnisses der Berechnung der Prüfsummenbytes nach dem (N – 1)ten Schreibbyte aufweist.
Verfahren nach Anspruch 6, bei dem das Modifizieren sicherstellt, dass ein erstes Prüfsummenbyte, das von dem Client an den Absender unmittelbar nach dem Senden der ersten Prüfsumme zurückgegeben wird, einen von Null verschiedenen Wert hat.
Verfahren, das aufweist: Schicken einer Nachricht von einem Absender einer Nachricht an einen Client über einen seriellen Eindraht-Bus; Erfassen, durch den Absender, eines ungültigen Prüfsummenbytes, das von dem Client in Erwiderung auf die Nachricht, die von dem Absender verschickt worden ist, zurückgegeben wird; Abbrechen, durch den Absender, der Nachricht innerhalb eines vorbestimmten Zeitrahmens; und Feststellen, durch den Client, dass die Nachricht ungültig ist, basierend auf dem Abbruch der Nachricht durch den Absender innerhalb des vorbestimmten Zeitrahmens.
Verfahren nach Anspruch 9, bei dem das Prüfsummenbyte eine Frame-Prüfsequenz (FCS) einer zyklischen Redundanzprüfung (CRC) für 8 Bit für jedes aus wenigstens einem Datenbyte, die dem Prüfsummenbyte vorangeht, aufweist.
Verfahren nach Anspruch 9, bei dem die vorbestimmte Zeit eine innerhalb eines ersten Lesedatenbytes ist.
System, das aufweist: einen seriellen Eindraht-Bus; eine Absender-Baugruppe für eine Nachricht, die mit dem Bus verbunden ist, wobei der Absender ein erstes Prüfsummenbyte berechnet, das erste Prüfsummenbyte an eine Nachricht anhängt und die Nachricht von dem Absender an einen Client über den Bus verschickt; und eine Client-Baugruppe, die mit dem Bus verbunden ist, wobei die Client-Baugruppe die Nachricht von dem Absender über den Bus empfangt und eine Gültigkeit der Nachricht von dem Absender feststellt, indem das erste Prüfsummenbyte mit einer zweiten Prüfsumme, die von dem Client berechnet wird, verglichen wird.
System nach Anspruch 11, bei dem der Client feststellt, dass die Nachricht gültig ist, wenn das erste Prüfsummenbyte gleich dem zweiten Prüfsummenbyte ist, und dass die Nachricht ungültig ist, wenn das erste Prüfsummenbyte nicht gleich dem zweiten Prüfsummenbyte ist.
System nach Anspruch 12, bei dem das erste Byte und das zweite Byte eine zyklische Redundanzprüfung (CRC) mit 8 Bit von jedem von wenigstens einem Datenbyte aufweist, die den jeweiligen Prüfsummen vorangeht, aufweist.
System nach Anspruch 12, bei dem die Nachricht N Byte Schreibdaten aufweist, in denen das erste Prüfsummenbyte enthalten ist.
System nach Anspruch 15, bei dem die Nachricht weiter eine Adresse, eine Leselänge und eine Schreiblänge aufweist.
System nach Anspruch 15, bei dem das erste Prüfsummenbyte berechnet wird, indem ein Ergebnis einer Berechnung des Prüfsummenbytes nach dem (N – 1)ten Schreibdatenbyte abgeändert wird und an die Nachricht als das Nte Schreibdatenbyte angehängt wird.
System nach Anspruch 17, bei dem das Abändern das Invertieren eines höchstwertigen Bits des Ergebnisses der Berechnung des Prüfsummenbytes nach dem (N – 1)ten Schreibbyte aufweist.
System nach Anspruch 17, bei dem das Abändern sicherstellt, dass ein erstes Prüfsummenbyte, das von dem Client an den Absender unmittelbar nach dem Senden der Prüfsumme zurückgegeben wird, einen von Null verschiedenen Wert hat.
System, das aufweist: einen seriellen Eindraht-Bus; einen Client, der mit dem Bus verbunden ist; und einen Absender einer Nachricht, der mit dem Bus verbunden ist, wobei der Absender eine Nachricht an einen Client über den Bus sendet und die Nachricht innerhalb eines vorbestimmten Zeitrahmens nach dem Erfassen, dass ein ungültiges Prüfsummenbyte von dem Client in Erwiderung auf die Nachricht, die von dem Absender verschickt worden ist, zurückgegeben wird, abbricht, und wobei der Client basierend auf dem Abbruch der Nachricht durch den Absender innerhalb des vorbestimmten Zeitrahmens feststellt, dass die Nachricht ungültig ist.
System nach Anspruch 20, bei dem das Prüfsummenbyte eine Frame-Prüfsequenz (FCS) in einer zyklischen Redundanzprüfung (CRC) für 8 Bit von jedem von wenigstens einem Datenbyte aufweist, die dem Prüfsummenbyte vorangeht.
System nach Anspruch 20, bei dem die vorbestimmte Zeit innerhalb eines ersten Lesedatenbytes liegt.
System, das aufweist: einen seriellen Eindraht-Bus; eine Absender-Baugruppe für eine Nachricht, die mit dem Bus verbunden ist, wobei der Absender ein erstes Prüfsummenbyte berechnet, das erste Prüfsummenbyte an eine Nachricht anhängt und die Nachricht von dem Absender an einen Client über den Bus verschickt; eine Client-Baugruppe, die mit dem Bus verbunden ist, wobei die Client-Baugruppe die Nachricht von dem Absender über den Bus empfängt und eine Gültigkeit der Nachricht von dem Absender feststellt, indem das erste Prüfsummenbyte mit einer zweiten Prüfsumme, die von dem Client berechnet wird, verglichen wird; und ein Speichermodul in Verbindung mit der Client-Baugruppe.
System nach Anspruch 23, bei dem der Client feststellt, dass die Nachricht gültig ist, wenn das erste Prüfsummenbyte gleich dem zweiten Prüfsummenbyte ist, und dass die Nachricht ungültig ist, wenn das erste Prüfsummenbyte nicht gleich dem zweiten Prüfsummenbyte ist.