Scrambler vs. 8b/10b-Encoder

Ich ging durch die SATA3-Spezifikation. Gemäß der Spezifikation werden sowohl Scrambler als auch 8b/10b-Encoder in seinem Design verwendet. Scrambler hilft bei der Randomisierung der Daten, während der 8b/10-Encoder genügend Übergänge für die DC-Balance und die Taktdatenwiederherstellung erzeugt.

Mein Zweifel ist, dass der Scrambler, wenn er die Daten randomisiert, den Zweck des DC-Ausgleichs und der Taktdatenwiederherstellung lösen sollte, da der Scrambler Übergänge von „1“ und „0“ erzeugt. Wozu braucht man dann 8b/10b Encoder?

@HervéGrabas Ok, ich verstehe deinen Punkt. Aber nehmen wir ein Szenario an, in dem wir kein DC-Gleichgewicht aufrechterhalten müssen. Würde in diesem Fall ein Scrambler ausreichen? Weil wir dieses Mal nur genügend Online-Übergänge für die Taktdatenwiederherstellung schaffen müssen und keine DC-Balance aufrechterhalten müssen.
Das Verwürfeln einer langen Reihe von Einsen würde eine Mischung aus Einsen und Nullen erzeugen. Aber aus dem gleichen Grund gibt es Folgen von Einsen und Nullen, die, wenn sie verschlüsselt werden, eine lange Reihe von Einsen erzeugen.
@HervéGrabas, statistisch nicht wahr, Streams von All-1 oder All-0, die lang genug sind, um ein Problem zu verursachen, treten unglaublich selten auf. Neueste PCIe, Ethernet und USB verwenden 64b/66b, 128b/130b und 128b/132b Codierung. Diese Codierungen verwenden Scrambling nur, um Übergänge und nahezu DC-Balance in ihren Bitstrom einzufügen. Werfen Sie einen Blick auf ihre Spezifikationen und auf diese Kodierungen. Der 8b/10b-Look-Up-Table-Stil ist verschwunden.
Hallo @HervéGrabas, bitte schau dir noch einmal die Spezifikationen/Infos an, ich kann sie nicht in eine Folge von Kommentaren kopieren, wie du mich fragst :-) 64b/66b sind nicht nur die 8b/10b-Ideen, sondern länger. Sie sind völlig anders, verwenden einen 2..4-Bit-Marker und verknüpfen dann die restlichen Bits mit LFSR per XOR. Sie haben absolut Recht, dass Scrambling sinnlos ist, wenn Sie zu 8b / 10b gehen. Ich habe mir SATA3 nicht angesehen und kann die Frage daher nicht kommentieren. Wie auch immer, schau es dir an, lass mich wissen, was du daraus geschlossen hast, wenn du magst.

Antworten (2)

Ich diskutiere dies basierend auf meinen Kenntnissen über Ethernet und nicht über SATA. Ich kenne den SATA-Standard nicht, aber wenn er LFSR-Scrambling und 8b10b- oder 64b66b-Codierung verwendet, sollte er dort die gleichen Vorteile haben wie bei Ethernet.

Die 8b10b- oder 64b66b-Codierung bietet zwei Funktionen, die beim einfachen Scrambling nicht verfügbar sind:

Blockgrenzen Die Codierung führt Blockgrenzen ein, die eine Synchronisation zwischen Sender und Empfänger ermöglichen. Ohne diese Grenzen würde der Empfänger nicht wissen, wo ein Oktett endet und das nächste beginnt, geschweige denn, wo die Grenzen zwischen Frames oder Paketen in Protokollen höherer Ebene sind.

Fehlererkennung Die Codierung ermöglicht die Erkennung eines beliebigen Einzelbitfehlers in einem Frame und kann statistisch mehrere Bitfehler erkennen. Dadurch kann das Protokoll angemessen reagieren, wenn ein fehlerhafter Block empfangen wird.

Ok, ich wusste nichts von diesen beiden Funktionen, die von Encodern bereitgestellt werden. Ich habe weitere Zweifel:- 1) Obwohl die Codierung Blockgrenzen einführt. Aber wird es benötigt, wenn wir COMMA-Zeichen senden und der Empfänger eine Word-Aligner-Logik implementiert hat? In diesem Fall bräuchten wir keinen Encoder, um Blockgrenzen einzuführen, richtig? 2) In den meisten Protokollen senden wir CRC zur Fehlererkennung. Ich habe untersucht, dass die Decoder Fehler erkennen können, wenn ein nicht erkennbares Bitmuster am Detektor ankommt. Aber was ist, wenn der CRC die Aufgabe übernimmt, Fehler zu erkennen? Wird in diesem Fall der Encoder noch benötigt?
In den mir bekannten Protokollen ist das Komma-Zeichen ein Merkmal der Kodierung. Zum Beispiel ist das Komma in der 8b10b-Codierung 111 11100. Wenn Sie keine Codierung haben, wie erkennen Sie den Unterschied zwischen einem Komma und gewöhnlichen Daten, die zufällig das gleiche Bitmuster haben?
Was CRC betrifft, wird AFAIK hauptsächlich auf höheren Protokollschichten und auf größeren Datenblöcken durchgeführt. Das bedeutet eine längere Latenz, bevor ein Fehler erkannt wird. Ein Fehlererkennungsmechanismus im PCS-Framing (wie es bei Ethernet genannt wird) bedeutet eine Chance, alle 64 Datenbits, die passieren, Fehler zu erkennen.
OK. Danke für die ausführliche Erklärung. Viele Zweifel ausgeräumt.

Einige Kommunikationsprotokolle senden jedes Datenoktett unter Verwendung von acht Datenbits plus einigen Rahmenbits. Beim Senden von Daten über ein typisches asynchrones Protokoll können bis zu neun aufeinanderfolgende "0"-Bits und eine beliebige Anzahl aufeinanderfolgender "1"-Bits vorhanden sein. Ein einfacher Scrambler kann zehn Bits, von denen die ersten beiden garantiert 10 sind, in zehn Bits abbilden, die garantiert nicht mehr als etwa sechs aufeinanderfolgende übereinstimmende Werte haben.

Die Verwendung eines komplizierteren 8b/10b-Encoders ermöglicht es, die Worst-Case-Anzahl aufeinanderfolgender übereinstimmender Bits weiter zu reduzieren, als dies mit einem einfachen Scrambler möglich wäre, und bietet auch Garantien für den Leitungsausgleich (wodurch sichergestellt wird, dass die Gesamtzahl der Nullen und Einsen übertragen bleiben nahe beieinander). Um diese Vorteile zu erzielen, sind kompliziertere Schaltungen erforderlich, und es muss auch ein Teil der Timing-Flexibilität aufgegeben werden, die ein asynchrones Protokoll bietet. Beispielsweise könnte ein asynchrones Protokoll 100 Bytes über 1100 Bitzeiten liefern, bei einer kontinuierlichen "glatten" Rate von einem Byte alle elf Bitzeiten. Bei Verwendung einer 8b/10b-Codierung wäre es notwendig, ein Byte, dann ein Leerzeichen, dann zehn Bytes, dann ein weiteres Leerzeichen usw. zu senden. Für viele Zwecke wäre das nicht wichtig, aber für einige Zwecke könnte es sein. Wenn ein asynchroner Empfänger mit einem DAC verdrahtet wäre, der jeden Abtastwert sofort ausgibt, wenn er empfangen wird, würde das Durchleiten des Signals durch einen Bit-Synchronisierer und Verwürfeln 0,5 Bitzeiten an Jitter hinzufügen. Das Durchleiten durch einen 8b/10b-Encoder würde 5 Bitzeiten an Jitter hinzufügen.

Scrambler vs. 8b/10b-Encoder
AntwortenHierDatenschutz-Bestimmungen1y, 0v