Señal GMII/RGMII TX_ER: ¿funcionalidad garantizada?

Tengo una pregunta que busca aclarar EXACTAMENTE qué sucede durante un intercambio GMII entre MAC y PHY. En concreto, en lo que respecta a la señal TX_ER.

IEEE 802.3 Sección 3:

TX_ER es impulsado por la subcapa de reconciliación y realizará la transición sincrónicamente con respecto a GTX_CLK. Cuando se afirma TX_ER durante uno o más períodos TX_CLK mientras también se afirma TX_EN, el PHY emitirá uno o más grupos de códigos que no forman parte de los datos válidos o del delimitador establecido en algún lugar de la trama que se transmite. No es necesario conservar la posición relativa del error dentro de la trama. La figura 35-4 muestra el comportamiento de TX_ER durante la transmisión de una trama que propaga un error.

ingrese la descripción de la imagen aquí

Mi pregunta: cuando el MAC afirma TX_ER (mientras que TX_EN permanece alto), ¿el marco aún deja el PHY con todos los demás bytes de marco intactos, y SOLO los bytes transmitidos mientras TX_ER es alto se mezclan? ¿O el PHY deja de transmitir la trama por completo una vez que se detecta una señal de error?

Estoy trabajando en un diseño de FPGA que debería poder descartar o pasar un marco en función de su contenido, y me pregunto si la afirmación de la señal GMII TX_ER al PHY se consideraría "eliminar el marco" o no.

En el caso de que los bytes sigan saliendo del PHY, parecería que el paquete solo se "eliminaría" porque el Ethernet FCS no coincidiría con el contenido del paquete. Pero el contenido del marco aún sería recibido por el PHY en el otro extremo, por lo que si el lado del receptor tuviera acceso a la capa física, los datos podrían recuperarse potencialmente (lo que no es aceptable en mi caso).

He probado esto usando la utilidad de red iperf, y parece que los datos de la aplicación no pasan si se afirma TX_ER. Sin embargo, Wireshark parece decirme que todavía se reciben paquetes TCP válidos, y no entiendo cómo es posible si el CRC de la capa física no coincide con el contenido del marco.

Cualquier idea muy apreciada.

¡Gracias!

Respuestas (1)

Del extracto de IEEE 802.3 que publicaste:

Cuando se afirma TX_ER durante uno o más períodos TX_CLK mientras también se afirma TX_EN, el PHY emitirá uno o más grupos de códigos que no forman parte de los datos válidos o del delimitador establecido en algún lugar de la trama que se transmite.

El PHY aún envía el paquete por cable. El PHY no incluye un FIFO lo suficientemente grande para un paquete completo, por lo que no hay forma de que el PHY descarte la trama en una afirmación de TX_ER. Lo que hace el PHY es insertar una condición de error fuera de banda, generalmente en forma de palabras de código de indicación de error o no válidas, que el PHY en el lado de recepción interpretará y afirmará RX_ER. Creo que solo se cambiarán los bytes de datos que corresponden a las palabras clave de error, todo lo demás se recibirá correctamente. No parece que se requiera que PHY emita errores en los bytes exactos que corresponden a la afirmación TX_ER siempre que se inserte un error en algún lugar del marco. El MAC de recepción debe descartar la trama si se afirma RX_ER durante la recepción (lo mismo que si el FCS es malo), pero bien podría ser posible recuperar una parte de la trama.

Si realmente desea asegurarse de que el paquete nunca se envíe, lo que recomendaría es almacenar el paquete en un FIFO y solo liberarlo del FIFO una vez que haya verificado el marco y haya determinado que realmente desea enviarlo. Sin embargo, esto agregará una latencia dependiente de la longitud del paquete, que puede o no ser aceptable.

Aquí hay una implementación de un FIFO que hace exactamente eso; descartar fotogramas que están marcados como no válidos con una señal de usuario confirmada: https://github.com/alexforencich/verilog-ethernet/blob/master/lib/axis/rtl/axis_frame_fifo.v .

Muchas gracias, esa era mi sospecha. Podría terminar manteniendo alta la señal de error durante el marco, ya que ya hay suficientes FIFO en mi diseño (para otros fines) para permitir que todo el ejército ruso cruce correctamente los dominios de reloj. ¡Y +1 puntos por el código, que viene de moda con una interfaz AXIS y todo!
Bueno, también hay una versión asíncrona del mismo módulo FIFO. Así como un módulo MAC simplificado. Si tiene los datos en formato AXI, ¿por qué está jugando con ellos en formato GMII?
Señal GMII/RGMII TX_ER: ¿funcionalidad garantizada?
RespuestasAquíPolítica de privacidad1y, 0v