El Margen de Operación del Canal, o COM, por sus siglas en inglés, no es bien entendido. Dado que no es bien comprendido, muchas personas dudan de que realmente signifique algo. Después de todo, ¿cómo puede la calidad de un canal estar representada por solo un número en decibelios? Resulta que el COM es en realidad el último paso evolutivo en una larga progresión de técnicas de validación de canal utilizando patrones de ojo. Este blog rastreará la evolución del COM hasta sus raíces y dará significado a la infame métrica COM.
Comencemos con los patrones de ojo. Los patrones de ojo son una forma de observar una larga secuencia de datos seriales. Antes de Keysight ADS y PyBERT [1] [2], un patrón de ojo se medía con un osciloscopio de muestreo digital o un osciloscopio en tiempo real. En la ventana del patrón de ojo, las unidades del eje y son voltaje y las unidades del eje x son tiempo abarcando dos intervalos de unidad. Un intervalo de unidad, o UI, es la cantidad de tiempo que tarda en pasar un bit. Así, dentro de dos UI de tiempo, puedes centrar un dato de bit en la pantalla con medio bit de margen a cada lado. Sin embargo, en lugar de visualizar solo un bit, todos los bits se superponen, uno a la vez, hasta que toda la secuencia de datos seriales está en la pantalla. La calidad de la señal se cuantifica por el tamaño del agujero en el medio. Si el patrón de ojo se ve realmente bien, podrías escuchar a un ingeniero decir, “¡Podrías conducir un camión a través de ese ojo!” Las formas más comunes de cuantificar la apertura son ancho, altura o área. El cruce del ojo en el punto de CC es el jitter, y el jitter se mide típicamente de manera estadística con un histograma.
Figura 1. Ejemplo de una secuencia de bits serial.
Las especificaciones de canales tempranos, y en algunos casos las especificaciones de componentes pasivos, utilizaban algo llamado una máscara de ojo para los criterios de aprobación/reprobación. Una máscara de ojo es usualmente un área con forma de diamante definida por un ancho y una altura de ojo. Un ojo que pasa la prueba tiene solo tantas muestras detectadas o impactos, dentro de la máscara de ojo. Los patrones de unos y ceros están dictados por el estándar y usualmente son secuencias de bits pseudoaleatorias o patrón PRBS. Básicamente puedes clasificar los patrones en dos categorías: antes de 10 Gb/s y después de 10 Gb/s. Antes de 10 Gb/s, la codificación 8b10b se usaba en la mayoría de los sistemas y PRBS 7 era el patrón apropiado. Cuando los 10 Gb/s fueron introducidos por el IEEE en 802.3ba, la codificación cambió a un mezclador 64b66b y PRBS 31 tomó el mando. Incluso hoy en día a 112 Gb/s, PRBS 31, o QPRBS 31, sigue siendo el patrón estándar que la mayoría utiliza.
Cronológicamente después de medir patrones de ojo, StatEye es el siguiente método para calificar canales pasivos, y fue ampliamente utilizado por el OIF. La idea detrás de StatEye se explica en detalle aquí: [3] En resumen, StatEye predice patrones de ojo utilizando una respuesta de pulso de un sistema. Una respuesta de pulso es la respuesta en el dominio del tiempo de un sistema excitado con un pulso cuadrado de una UI, y el sistema es un canal pasivo que incluye ecualización. Las tecnologías de ecualización disponibles en StatEye son FFE, CTLA y DFE. La función de transferencia de un sistema se obtiene de los parámetros-S. Dado que los parámetros-S del canal pueden ser simulados, StatEye es una manera eficiente de probar muchos canales y configuraciones de ecualización para ver qué funciona. Todo el tiempo, la máscara de ojo es el criterio de aprobación/reprobación usando la apertura de ojo predicha estadísticamente.
En algún punto entre StatEye y COM, el análisis de distorsión pico (PDA por sus siglas en inglés) se volvió algo común. El método está bien documentado por Heck y Hall en Advanced Signal Integrity for High Speed Digital Designs [4]. En resumen, utiliza la misma respuesta de pulso que StatEye, pero su salida es simplemente la apertura de ojo en el peor caso, llamada así. PDA no inventa ningún dato, y esa es la razón por la que personalmente me gusta. Lo he implementado yo mismo y encontré que PDA predice patrones de ojo en el peor caso con alta confianza. Sin embargo, PDA y StatEye no incluyen el impacto del transmisor y receptor en el canal, y necesitas encontrar la mejor configuración de ecualización manualmente.
Figura 2: Ejemplo de un Patrón de Ojo en azul y PDA en negro punteado.
COM fue desarrollado como parte de IEEE 802.3bj, Ethernet 100GBASE, y añadió las imperfecciones del IC al canal simulado. Es más fácil de usar y más ampliamente adoptado que StatEye, y es hoy en día la herramienta de predicción de calidad de canal de facto. Como ya mencioné, COM se basa en StatEye y añade varias nuevas fuentes de ruido. Específicamente, las fuentes de ruido son pérdida del IC, reflexiones del paquete del IC, jitter relacionado con el IC y una fuente de ruido gaussiano agrupado para todo lo demás que sucede en el IC, como el diafonía. La implementación de COM se encuentra en IEEE 802.3 Anexo 93A [5].
La mayoría de las matemáticas detrás de COM son simplificadas por el organismo de normas tanto como sea posible. Por ejemplo, la concatenación de parámetros S se reduce a álgebra en lugar de conversiones de parámetros S a parámetros ABCD o T y multiplicación de matrices. La ecuación más difícil es calcular la función de densidad de probabilidad (PDF) del ruido relacionado con ISI, pero después de unos pocos intentos realmente no es tan malo. Hay algunas omisiones que se consideran específicas de la implementación, como cómo asegurar 32 puntos de muestra dentro de cada UI de datos, pero estos detalles se pueden encontrar dentro del código de fuente abierta proporcionado gratuitamente por el IEEE [5].
COM encuentra el mejor escenario posible para un canal dado utilizando un conjunto de posibles configuraciones de ecualización. Esto se logra barriendo todas las configuraciones de ecualización y calculando algo llamado la Figura de Mérito (FOM, por sus siglas en inglés). La configuración de ecualización que produce el mejor FOM se utiliza para el resto de los cálculos. Una vez que se calculan los PDFs de todas las fuentes de ruido, se identifica el ruido en una tasa de error detectada (DER, por sus siglas en inglés). La DER es la tasa de error de bits (BER, por sus siglas en inglés) deseada para el sistema, y se determina según qué técnica de Correcciones de Error Adelantado (FEC, por sus siglas en inglés), si la hay, se está considerando. La señal disponible se determina por el voltaje de respuesta de pulso en un punto de muestreo específico. La señal disponible se divide por el ruido en la tasa de error detectada (relación señal a ruido), y este número se convierte en decibelios. ¡Voilà! ¡COM! Verás, en realidad sí tiene significado.
Las configuraciones utilizadas para COM son determinadas por la tecnología IC disponible. El nivel de tecnología IC es acordado por líderes de la industria como Intel, Broadcom, Mellanox, Fujitsu, y muchos otros. En otras palabras, un IC utilizando tecnología implementada en COM debería ser capaz de funcionar en canales de trabajo como lo predice COM. Obviamente, esto es muy poderoso ya que el estándar ha puesto (finalmente) parte de la propiedad del canal en manos de los vendedores de IC.
Aunque suene como si COM fuera esta utopía de predicción de canales, tiene sus limitaciones. Dado que es un conjunto de configuraciones para todos los sistemas considerados por el estándar, no predice el rendimiento de ningún IC por sí mismo. Para obtener correlación de mediciones, necesitas ajustar las configuraciones de COM para cada IC individualmente. Además, COM ignora cualquier contribución de ruido proveniente de la desviación. Afortunadamente, un documento de DesignCon por Jason Chan aborda esta deficiencia, y espero ver scripts COM actualizados utilizando sus ideas en el futuro [6].
Para resumir, COM no es tan malo. Es un paso lógico muy coherente en la evolución del análisis de canales, y hace que la evaluación de canales sea relativamente fácil. Estoy muy agradecido de que los autores de COM hayan tenido la amabilidad de liberar y apoyar el código de MATLAB gratuitamente. Espero ver COM implementado y mejorado por otros ingenieros de integridad de señal en el futuro. Quién sabe, tal vez veamos una implementación en Python o Octave algún día.
Todas las figuras fueron creadas con GNU Octave, https://www.gnu.org/software/octave/.
[1] Página de inicio de Keysight ADS, https://www.keysight.com/en/pc-1297113/advanced-design-system-ads?&cc=US&lc=eng
[2] Página de inicio de PyBERT, https://pypi.org/project/PyBERT/
[3] A. Sanders, M. Resso, J. Ambrosia, Pruebas de Cumplimiento de Canal Utilizando una Nueva Metodología Estadística de Ojo, DesignCon 2004, http://www.ece.tamu.edu/~spalermo/ecen689/stateye_theory_sanders_designcon_2004.pdf
[4] S. Hall, H. Heck, Diseño Avanzado de Integridad de Señal para Diseños Digitales de Alta Velocidad, Wiley 2011
[5] Página de inicio del Grupo de Trabajo de Ethernet IEEE 802.3, http://www.ieee802.org/3/
[6] J. Chan, G. Zheoff, Conversión de Modo y su Impacto en Sistemas PAM4 de 112-Gbps, DesignCon 2019.