CLHS IP Core permite que produtos de 25 Gbps cheguem rapidamente ao mercado

blog

LarLar / blog / CLHS IP Core permite que produtos de 25 Gbps cheguem rapidamente ao mercado

Mar 10, 2023

CLHS IP Core permite que produtos de 25 Gbps cheguem rapidamente ao mercado

Os aplicativos de teste de colisão podem se beneficiar da interface de fibra óptica de 25 G do

Os aplicativos de teste de colisão podem se beneficiar da interface de fibra óptica de 25 G do Camera Link HS (CLHS). A imagem é capturada por uma câmera Excelitas PCO. | Imagem cortesia de Excelitas PCO GmbH

O núcleo IP de 25 Gbps do protocolo CLHS X é o mesmo núcleo IP encontrado em todos os produtos CLHS de 10 Gbps do mercado e está disponível no A3 desde o lançamento original da especificação CLHS em 2012. Esse núcleo comprovado apresenta fácil usar interfaces paralelas para vídeo, disparo bidirecional, comandos de câmera, GPIO bidirecional e a mensagem de revisão CLHS. Cumprindo todos os requisitos de codificação de prioridade listados na especificação CLHS, o núcleo simplifica o desenvolvimento de produtos CLHS. O módulo PCS associado faz a codificação 64/66b com correção de erros de encaminhamento, garantindo transmissões sem erros e permitindo que o núcleo seja usado com transceptores FPGA que oferecem serializadores/desserializadores 64 para 1 simples. Nenhum outro IP é necessário.

A especificação CLHS 1.2 introduziu recentemente a velocidade de 25 Gbps juntamente com os conectores QSFP28, SFP28 e MPO. A boa notícia é que os mecanismos ópticos de 25 Gbps são compatíveis com os mecanismos ópticos de 10 Gbps em que ocorre a descoberta de CLHS. O CLHS usa um processo de negociação à prova de falhas para mudar para 25 Gbps. Vários desenvolvedores já desenvolveram sistemas de 25 Gbps usando hardware comprovado de 10 Gbps para depurar o produto de 25 Gbps. O comitê tem uma prova de conceito para atingir 50 Gbps usando o mesmo núcleo IP, garantindo uma transição fácil para velocidades futuras.

Este artigo descreve as etapas para criar uma solução CLHS 25 Gbps em um FPGA para uma câmera contendo um sensor de imagem monocromático com 2048H x 1024V pixels com saída de 12 bits rodando a 950 quadros por segundo. Deseja-se enviar esses dados de 2,99 GByte/s para o host para processamento; 2,99 GByte/s está dentro da capacidade de 3 GByte/s de uma única via CLHS em 25 G. Uma solução SFP28 é escolhida.

O núcleo VHDL aberto adquirido da A3 por US$ 1.000 (Camera Link HS Standard: The High-Speed ​​Interface for the Future of Imaging and Machine Vision (automate.org)) inclui a câmera CLHS e os módulos de captura de quadros e o CLHS PCS, tornando sistema como mostrado abaixo.

Fonte da imagem: Teledyne DALSA

O núcleo não é específico de nenhum fornecedor e foi implementado em FPGAs AMD (Xilinx), Intel (Altera) e MicroChip (PolarFire). O desenvolvedor precisa configurar a função do transceptor, a distribuição do clock e a lógica que alimenta/recebe mensagens para/do núcleo. A figura abaixo mostra os canais de mensagens virtuais do núcleo IP de Pulse (trigger), GPIO, Video Data, Command e Revision. A configuração do transceptor e a distribuição do relógio são definidas pelos usuários do núcleo. Todas as regras de construção, codificação e prioridade de pacotes são tratadas pelo núcleo CLHS. Durante a descoberta, o frame grabber lê os registros obrigatórios na câmera e decide iniciar a transferência para a operação de 25 Gbps, o que requer que os transceptores sejam reconfigurados e quaisquer PLLs associados sejam redefinidos.

Fonte da imagem: Teledyne DALSA

O núcleo apresenta interfaces paralelas fáceis de usar. Como exemplo, a mensagem de pulso é enviada definindo o modo de pulso desejado e os bytes associados na interface paralela e, em seguida, um pulso de um relógio é aplicado ao pino de entrada de solicitação de envio. A mensagem Pulse é então transmitida pelo link, onde o receptor CLHS decodifica o tipo de mensagem e sinaliza a disponibilidade de dados paralelos para o sistema do usuário com um pulso PulseMsgValidStrobe de um relógio. As mensagens GPIO e de revisão usam metodologias idênticas. Os pacotes de vídeo e comando podem ter até 8k e 1k bytes, respectivamente. O usuário grava os dados de 64 bits ou 32 bits, respectivamente, no buffer CLHS com um pulso de habilitação de gravação e, quando terminar de gravar os dados do pacote e definir o conteúdo do byte de cabeçalho paralelo, emite uma solicitação de envio de um relógio na mensagem porta que faz com que o núcleo IP envie a mensagem para o link. No receptor, o pacote recebido é decodificado e armazenado corretamente no buffer de recebimento de vídeo ou comando e ativa um pulso de um relógio, como VidMsgValidStrobe, para sinalizar que o buffer está pronto para ser lido.