Scrambler frente a codificador 8b/10b

Estaba pasando por la especificación SATA3. Según las especificaciones, en su diseño se utilizan codificadores 8b/10b y codificadores. Scrambler ayuda a aleatorizar los datos, mientras que el codificador 8b/10 crea suficiente transición para el balance de CC y la recuperación de datos del reloj.

Mi duda es que si el codificador aleatoriza los datos, entonces debería resolver el propósito del equilibrio de CC y la recuperación de datos del reloj, porque el codificador está creando transiciones de '1' y '0'. Entonces, ¿cuál es la necesidad de un codificador 8b/10b?

@HervéGrabas Ok, entiendo tu punto. Pero supongamos un escenario en el que no necesitamos mantener el equilibrio de CC. En ese caso, ¿sería suficiente un codificador? Porque esta vez solo necesitamos crear suficiente transición en línea para la recuperación de datos del reloj y no es necesario mantener el equilibrio de CC.
Codificar una larga serie de 1 produciría una mezcla de 1 y 0. Pero del mismo modo, hay secuencias de 1 y 0 que, cuando se revuelven, producen una larga serie de 1.
@HervéGrabas, estadísticamente no es cierto, las transmisiones de todos los 1 o todos los 0 lo suficientemente largas como para causar un problema surgen increíblemente raramente. Los PCIe, Ethernet y USB más nuevos usan codificación 64b/66b, 128b/130b y 128b/132b. Esas codificaciones usan codificación solo para agregar transiciones y un equilibrio cercano a DC en su flujo de bits. Eche un vistazo a sus especificaciones y a estas codificaciones. El estilo de 'tabla de consulta' 8b/10b se ha ido.
Hola, @HervéGrabas, nuevamente, mire las especificaciones/información, no puedo copiarlas en una sucesión de comentarios como me pregunta :-) 64b/66b no son solo las ideas de 8b/10b sino más largas. Son completamente diferentes, usan un marcador de 2..4 bits y luego XORing el resto de bits con LFSR. Tienes toda la razón en que codificar no tiene sentido si vas a 8b/10b. No he mirado SATA3, así que no puedo comentar sobre la pregunta. De todos modos, eche un vistazo, hágame saber lo que concluyó de mirar si lo desea.

Respuestas (2)

Estoy discutiendo esto en base a mi conocimiento de Ethernet, en lugar de SATA. No conozco el estándar SATA, pero si usa codificación LFSR y codificación 8b10b o 64b66b, debería tener los mismos beneficios que tiene en Ethernet.

La codificación 8b10b o 64b66b proporciona dos funciones que no están disponibles con una simple codificación:

límites de bloque La codificación introduce límites de bloque que permiten la sincronización entre el transmisor y el receptor. Sin estos límites, el receptor no sabría dónde termina un octeto y comienza el siguiente, y mucho menos dónde están los límites entre tramas o paquetes en protocolos de nivel superior.

detección de errores La codificación permite detectar cualquier error de un solo bit en una trama y, estadísticamente, puede detectar errores de varios bits. Esto permite que el protocolo reaccione adecuadamente cuando se recibe un bloque con errores.

Ok, no sabía de estas dos funciones proporcionadas por los codificadores. Tengo más dudas: - 1) Aunque la codificación introduce límites de bloque. Pero, ¿es necesario si enviamos caracteres COMMA y el receptor tiene implementada una lógica de alineación de palabras? En ese caso, no necesitaríamos un codificador para introducir límites de bloque, ¿verdad? 2) En la mayoría de los protocolos enviamos CRC para detección de errores. Estudié que los decodificadores pueden detectar errores cada vez que llega un patrón de bits no detectable al detector. Pero, ¿y si el CRC hace el trabajo de detectar el error? En ese caso, ¿sigue siendo necesario el codificador?
En los protocolos con los que estoy familiarizado, el carácter COMMA es una característica de la codificación. Por ejemplo, el COMMA en la codificación 8b10b es 111 11100. Si no tiene codificación, ¿cómo diferencia entre un COMMA y los datos ordinarios que tienen el mismo patrón de bits?
En cuanto a CRC, AFAIK se realiza principalmente en capas de protocolo más altas y en bloques de datos más grandes. Eso significa una latencia más larga antes de que se detecte un error. Tener un mecanismo de detección de errores en el entramado PCS (como se llama en Ethernet) significa la posibilidad de detectar errores cada 64 bits de datos que pasan.
De acuerdo. Gracias por la explicación detallada. Aclarado muchas dudas.

Algunos protocolos de comunicaciones envían cada octeto de datos utilizando ocho bits de datos más algunos bits de trama. Cuando se envían datos a través del protocolo asíncrono típico, puede haber hasta nueve bits "0" consecutivos y un número arbitrario de bits "1" consecutivos. Un codificador simple puede mapear diez bits de los cuales se garantiza que los dos primeros sean 10, en diez bits que se garantiza que no tendrán más de seis valores coincidentes consecutivos.

El uso de un codificador 8b/10b más complicado hará posible reducir el número de bits coincidentes consecutivos en el peor de los casos más de lo que sería posible usando un codificador simple, y también ofrecerá garantías sobre el equilibrio de línea (asegurando que el número total de ceros y unos transmitidos permanezcan cerca uno del otro). Obtener estos beneficios requiere un circuito más complicado y también requiere renunciar a parte de la flexibilidad de tiempo que ofrecía un protocolo asíncrono. Por ejemplo, un protocolo asíncrono podría entregar 100 bytes en 1100 tiempos de bit, a una velocidad continua "suave" de un byte cada once tiempos de bit. Usando una codificación 8b/10b, sería necesario enviar un byte, luego un carácter inactivo, luego diez bytes, luego otro carácter inactivo, etc. Para muchos propósitos eso no importaría, pero para algunos propósitos podría. Si un receptor asíncrono estuviera conectado a un DAC que emitiera inmediatamente cada muestra tal como se recibió, pasar la señal a través de un sincronizador de bits y codificar agregaría 0,5 bits de fluctuación. Pasarlo a través de un codificador 8b/10b agregaría 5 bits de fluctuación.

Scrambler frente a codificador 8b/10b
RespuestasAquíPolítica de privacidad1y, 0v