Co-Simulação para Designs Zynq SoC: Acelerando Verificação Hardware-Software

Dispositivos System-on-Chip (SoC) heterogêneos como Xilinx Zynq-7000 e Zynq UltraScale+ MPSoC fundem um processing system de alto desempenho com programmable logic de ponta. Essa integração permite que designers construam sistemas que equilibram controle CPU-driven com pipelines de baixa latência baseados em PL — ideais para processamento de imagem, automação industrial e processamento de sinal em tempo real.

A conexão PS-para-PL é construída sobre uma suíte de links Advanced eXtensible Interface (AXI) memory-mapped que suportam papéis master e slave, permitindo comunicação bidirecional robusta entre software rodando nos cores ARM e lógica customizada no tecido FPGA.

Figura 1. Arquitetura Zynq Mostrando AXI Interconnect entre PS e PL (Fonte: Xilinx)

Quando o PS lida com configuração ou controle, um AXI Master de propósito geral no processador escreve em registradores dentro de IP cores PL, direcionando seu comportamento. Para tarefas data-intensive — como streaming de frames de vídeo de PL para memória PS — interfaces AXI de alta performance são usadas, demandando software mais sofisticado para configurar transferências DMA e gerenciar coerência de buffer.

Verificar interações PS-PL é notoriamente difícil. Uma Embedded Markets Survey de 2015 destacou debugging como um dos principais desafios de design e ressaltou a necessidade de melhores ferramentas de verificação. Enquanto bus-functional models podem fornecer verificação inicial de sanidade, eles frequentemente carecem da profundidade necessária para validar drivers de software reais e aplicações. Modelos funcionais completos existem mas podem ser proibitivamente caros.

Verificação tradicional divide o fluxo: cada bloco é validado isoladamente, e apenas após o primeiro hardware chegar, PS e PL são costurados juntos. A equipe de software tipicamente verifica se o kernel Linux carrega os drivers necessários e entradas de device-tree rodando QEMU, um hypervisor open-source que emula a arquitetura ARM. Inversamente, a equipe de lógica sequencia comandos que mimam transações iniciadas por software para confirmar funcionalidade PL.

Ambas abordagens perdem o verdadeiro handshake PS-PL, tornando bugs sutis de integração difíceis de detectar e caros para corrigir mais tarde no ciclo. Embora uma development board possa fornecer um stop-gap, debugging em hardware real demanda inserir lógica de instrumentação, regenerar o bitstream, e arriscar drift comportamental.

Co-simulação de hardware e software oferece solução proativa: permite verificação concorrente antes de placas de produção existirem, cortando dramaticamente tempo e custo de debug. Também dá aos designers visibilidade total em estados de registradores e tráfego inter-domínio, acelerando detecção de defeitos.

Co-simulação HW & SW

Co-simulação requer que o simulador de lógica comunique com uma plataforma de emulação de software. O Riviera-PRO da Aldec (2017.10) introduziu uma bridge que conecta Riviera-PRO ao QEMU, permitindo que software Linux-based Zynq rode dentro do mesmo ciclo de simulação que o HDL.

Figura 2. Conectando ambientes de verificação HW e SW (Fonte: Aldec)

A bridge alavanca SystemC Transaction-Level Modelling (TLM) para expor canais AXI entre QEMU e Riviera-PRO, permitindo troca de dados bidirecional. Engenheiros podem então empregar técnicas avançadas de debugging como breakpoints HDL, data-flow tracing e análise de code-coverage dentro do Riviera-PRO, enquanto o lado software usa GDB para step through de código de kernel e driver no QEMU.

Como o mesmo kernel Linux que rodará no dispositivo alvo é exercitado no QEMU, desenvolvedores confirmam cedo que todos módulos necessários e arquivos de configuração estão presentes, reduzindo surpresas de estágio tardio.

Exemplo PWM

Para ilustrar o fluxo de trabalho, considere um IP core PWM colocado em PL e conectado ao PS via interface AXI de propósito geral. Software configura um registrador para definir duty cycle entre 0% e 100%, então dispara o core. Verificar o core isoladamente perde o caminho de controle iniciado pelo PS; co-simulação completa garante que a largura de pulso é gerada corretamente quando a aplicação Linux roda.