Blog

Mar 10, 2023

CLHS IP Core permite que los productos de 25 Gbps lleguen rápidamente al mercado

Las aplicaciones de prueba de choque pueden beneficiarse de la interfaz de fibra óptica de 25 G de

Las aplicaciones de prueba de choque pueden beneficiarse de la interfaz de fibra óptica de 25 G de Camera Link HS (CLHS). La imagen es capturada por una cámara Excelitas PCO. | Imagen cortesía de Excelitas PCO GmbH

El núcleo IP de 25 Gbps del protocolo CLHS X es el mismo núcleo IP que se encuentra en todos los productos CLHS de 10 Gbps en el mercado y ha estado disponible en el A3 desde el lanzamiento original de la especificación CLHS en 2012. Este núcleo probado presenta fácil- para usar interfaces paralelas para video, disparador bidireccional, comandos de cámara, GPIO bidireccional y el mensaje de revisión CLHS. Al realizar todos los requisitos de codificación prioritarios enumerados en la especificación CLHS, el núcleo simplifica el desarrollo de productos CLHS. El módulo PCS asociado realiza una codificación 64/66b con corrección de errores hacia adelante, lo que garantiza transmisiones sin errores y permite que el núcleo se use con transceptores FPGA que ofrecen serializadores/deserializadores 64 a 1 simples. No se necesita otra IP.

La especificación 1.2 de CLHS introdujo recientemente la velocidad de 25 Gbps junto con los conectores QSFP28, SFP28 y MPO. La buena noticia es que los motores ópticos de 25 Gbps son compatibles con los motores ópticos de 10 Gbps en los que se produce el descubrimiento de CLHS. CLHS utiliza un proceso de negociación a prueba de fallas para cambiar a 25 Gbps. Varios desarrolladores ya han desarrollado sistemas de 25 Gbps utilizando hardware probado de 10 Gbps para depurar el producto de 25 Gbps. El comité tiene una prueba de concepto para lograr 50 Gbps utilizando el mismo núcleo de IP, lo que garantiza una transición fácil a velocidades futuras.

Este artículo describe los pasos para crear una solución CLHS de 25 Gbps en una FPGA para una cámara que contiene un sensor de imagen monocromática con píxeles de 2048H x 1024V con una salida de 12 bits que se ejecuta a 950 fotogramas por segundo. Se desea enviar estos datos de 2,99 GByte/s al host para su procesamiento; 2,99 GByte/s está dentro de la capacidad de 3 GByte/s de un solo carril CLHS a 25 G. Se elige una solución SFP28.

El núcleo VHDL abierto comprado a A3 por $1000 (Camera Link HS Standard: The High-Speed ​​Interface for the Future of Imaging and Machine Vision (automate.org)) incluye la cámara CLHS y los módulos de captura de fotogramas y el CLHS PCS que hacen un completo sistema como se muestra a continuación.

Fuente de la imagen: Teledyne DALSA

El núcleo no es específico de ningún proveedor y se ha implementado en FPGA de AMD (Xilinx), Intel (Altera) y MicroChip (PolarFire). El desarrollador necesita configurar la función del transceptor, la distribución del reloj y la lógica que alimenta/recibe mensajes hacia/desde el núcleo. La siguiente figura muestra los canales de mensajes virtuales del núcleo IP de Pulse (disparador), GPIO, Datos de video, Comando y Revisión. La configuración del transceptor y la distribución del reloj son configuradas por los usuarios del núcleo. Todas las reglas de creación, codificación y prioridad de paquetes son manejadas por el núcleo CLHS. Durante el descubrimiento, el capturador de fotogramas lee los registros obligatorios en la cámara y decide iniciar la transferencia a la operación de 25 Gbps, lo que requiere que se reconfiguren los transceptores y que se restablezcan los PLL asociados.

Fuente de la imagen: Teledyne DALSA

El núcleo presenta interfaces paralelas fáciles de usar. Como ejemplo, el mensaje de pulso se envía configurando el modo de pulso deseado y los bytes asociados en la interfaz paralela, y luego se aplica un pulso de un reloj de ancho al pin de entrada de solicitud de envío. Luego, el mensaje Pulse se transmite a través del enlace, donde el receptor CLHS decodifica el tipo de mensaje y señala la disponibilidad de datos paralelos al sistema del usuario con un pulso PulseMsgValidStrobe de un reloj de ancho. Los mensajes de revisión y GPIO utilizan metodologías idénticas. Los paquetes de video y comando pueden tener un tamaño de hasta 8k y 1k bytes, respectivamente. El usuario escribe los datos de 64 bits o 32 bits, respectivamente, en el búfer CLHS con un pulso de activación de escritura y, cuando termina de escribir los datos del paquete y establece el contenido del byte del encabezado paralelo, emite una solicitud de envío de un reloj en el mensaje. puerto que hace que el núcleo IP envíe el mensaje al enlace. En el receptor, el paquete entrante se decodifica y se almacena correctamente en el búfer de recepción de video o comando y afirma un pulso de un reloj, como VidMsgValidStrobe, para indicar que el búfer está listo para ser leído.

Consideremos el mensaje de video como un ejemplo para configurar la información del encabezado. CLHS es un paquete de estilo DMA remoto que utiliza RowID y ColumID para definir la ubicación del píxel del primer píxel en el paquete. El sensor en consideración tiene 2k píxeles de ancho y los datos de 12 bits están concatenados, lo que da como resultado 3kbytes para una sola fila de datos. Esto cabe fácilmente en el máximo de 8k bytes. Si la velocidad de datos del sensor fuera más rápida, entonces se podría agregar un segundo carril y enviar datos de filas pares en el carril 0 y datos de filas impares en el carril 1 o elegir enviar píxeles 0 a 1023 en el carril 0 y píxeles 1024 a 2047 en el carril 1. La elección depende del usuario y cómo el usuario elige llenar los búferes de datos CLHS. Con este ejemplo, solo se necesita un carril y el primer píxel de cada fila es la columna 0. Por convención, la primera fila de un cuadro es la fila 0 y se incrementa para cada salida de fila de la cámara. Si el sensor es de lectura superior/inferior, la fila 0 es la primera fila del marco y la fila 1023 es la segunda fila de la cámara, configurando el ID de fila en 0 y luego 1023 como entrada al núcleo CLHS. CLHS es un modelo de inserción de datos, por lo que las cámaras no necesitan almacenar en búfer los datos de imagen. El desarrollador decide admitir capturadores de fotogramas más antiguos con capacidad 10G y diseños en 2 conexiones de fibra, logrando 2,8 GByte/seg de ancho de banda y la capacidad de configurar la cámara para usar un solo carril de 25 G para la velocidad de fotogramas completa. Las configuraciones que el desarrollador decide admitir en la cámara se enumeran a continuación y se documentan en los registros CLHS obligatorios para que el capturador de fotogramas pueda negociar automáticamente la configuración.

Los valores aplicados al núcleo IP de video de la cámara CLHS se muestran en la siguiente tabla. El prefijo v pequeño en los nombres de los puertos indica que el reloj utilizado para esta interfaz es un reloj de video proporcionado por el cliente y todas las señales están sincronizadas con este reloj. El núcleo del capturador de fotogramas tiene señales correspondientes, excepto cuando se necesita la función inversa, como la entrada vRdEn y vVidDataAvailable, vVidMsgValidStrb y vVidDataValid.

CLHS utiliza un núcleo probado que es fácil de usar, funciona a 10G, 25G y tiene una hoja de ruta para 50G. Los productos se pueden desarrollar a 10 G utilizando productos de socios probados y, cuando se depuran, se puede pasar a 25 G. Para los clientes que no necesitan la velocidad de 25 G, pueden usar motores ópticos de 10 G que son más económicos y se conectan a 10 G. capturadores de fotogramas que se anticipa que tendrán un costo más bajo que los productos 25G de mayor rendimiento.