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

2

Tengo una pregunta que busca aclarar EXACTAMENTE qué sucede durante un intercambio GMII entre MAC y PHY. Específicamente, respecto a la señal TX_ER.

IEEE 802.3 Sección 3:

  

TX_ER está controlado por la subcapa de reconciliación y debe realizar una transición sincrónica con respecto a la GTX_CLK. Cuando se afirma TX_ER durante uno o más periodos TX_CLK, mientras que también se afirma TX_EN, el PHY emitirá uno o más grupos de código que no forman parte de los datos válidos o delimitador establecido en algún lugar de la trama que se transmite. La posición relativa del error dentro del marco no necesita ser preservada. La figura 35-4 muestra   el comportamiento de TX_ER durante la transmisión de una trama que propaga un error.

     

Mipregunta:cuandoTX_EResconfirmadoporelMAC(mientrasTX_ENsemantienealto),¿elcuadroaúndejaelPHYcontodoslosdemásbytesdelcuadroaúnintactos,ySOLAMENTElosbytestransmitidosmientraselTX_EResaltoseconfunden?¿OlaPHYdejadetransmitirelcuadroporcompletounavezquesedetectaunaseñaldeerror?

EstoytrabajandoenundiseñodeFPGAquedeberíapodersoltaropasarunatramaenfuncióndesucontenido,ymepreguntosilaafirmacióndelaseñalGMIITX_ERaPHYseconsideraría"abandonar la trama" o no.

En el caso de que los bytes sigan saliendo de la 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 de la trama 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 confirma TX_ER. Sin embargo, wireshark parece decirme que todavía hay paquetes TCP válidos que se están recibiendo, 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!

    
pregunta Brett

1 respuesta

1

Del extracto de IEEE 802.3 que publicaste:

  

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

El paquete aún se envía en el cable por el PHY. El PHY no incluye un FIFO lo suficientemente grande para un paquete completo, por lo que no hay forma de que el PHY suelte el marco 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 invá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 al código de error, todo lo demás se recibirá correctamente. No parece que se requiera que la PHY produzca un error en los bytes exactos que corresponden a la afirmación de TX_ER, siempre que se inserte un error en algún lugar del marco. El MAC de recepción debe tirar el marco si se afirma RX_ER durante la recepción (igual que si el FCS es malo), pero podría ser posible recuperar una parte del marco.

Si realmente desea asegurarse de que el paquete nunca se envíe, lo que recomendaría es almacenar el paquete en un FIFO y liberarlo solo del FIFO una vez que haya revisado 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; eliminar cuadros que están marcados como no válidos con una señal de colmillo afirmada: enlace .

    
respondido por el alex.forencich

Lea otras preguntas en las etiquetas