Co-simulação para designs baseados em Zynq

Dispositivos Heterogêneos System-on-Chip (SoC) como o Xilinx Zynq 7000 e Zynq UltraScale + MPSoC combinam sistemas de processamento de alto desempenho com lógica programável de última geração. Essa combinação permite que o sistema seja arquitetado para fornecer uma solução ideal. Interfaces de usuário, comunicação, controle e configuração do sistema podem ser endereçados pelo Sistema do Processador (PS). Enquanto isso, a Lógica Programável (PL) pode ser usada para implementar funções determinísticas de baixa latência e pipelines de processamento que exploram sua natureza paralela, como aquelas usadas por processamento de imagens e aplicações industriais.

A comunicação entre o PS e o PL é fornecida por várias interfaces mapeadas na memória. Essas interfaces usam a Interface eXtensível Avançada (AXI) para fornecer comunicações Mestre e Escravo em cada direção.

Figura 1. Arquitetura Zynq mostrando a interconexão AXI entre o PS e o PL (Fonte:Xilinx)

Nos casos em que as funções de configuração e controle são realizadas pelo PS, a interface mestre AXI de uso geral é usada do PS para o PL. Isso permite que o software (SW) configure os registros e, portanto, o comportamento desejado dos núcleos IP no PL. Em operações mais complexas, pode haver um desejo de transferir grandes quantidades de dados do PL para o espaço de memória PS para posterior processamento ou comunicação. Essas transferências utilizarão interfaces de alto desempenho, que exigirão um software consideravelmente mais complexo para configurar e usar.

Verificar as interações entre o PS e o PL apresenta desafios para a equipe de design. A Pesquisa de Mercados Incorporados de 2015 identificou a depuração como um dos principais desafios de design enfrentados pelas equipes de engenharia e também identificou a necessidade de ferramentas de depuração aprimoradas. Embora os modelos funcionais de barramento possam ser usados ​​inicialmente, esses modelos são frequentemente simplificados e não permitem a verificação dos drivers SW desenvolvidos e do aplicativo ao mesmo tempo. Modelos totalmente funcionais estão disponíveis, mas podem ser proibitivamente caros. Ao implementar um projeto SoC heterogêneo, deve haver uma estratégia de verificação que permita que os elementos PL e PS sejam verificados juntos o mais cedo possível.

Tradicionalmente, a verificação foi realizada inicialmente para cada elemento (bloco funcional) no projeto de forma isolada; verificar todos os blocos juntos ocorre quando o primeiro hardware chega. A equipe de engenharia de software que desenvolve os aplicativos para rodar no PS precisa garantir que o kernel do Linux contenha todos os módulos necessários para suportar seu uso e tenha o blob de árvore de dispositivo correto; isso normalmente é verificado usando QEMU (abreviação de Quick Emulator), que é um hipervisor hospedado de código aberto e gratuito que executa a virtualização de hardware.

Enquanto isso, para verificar corretamente o projeto do PL, a equipe de verificação de lógica deve gerar e sequenciar comandos como aqueles emitidos pelo software aplicativo para verificar se a lógica funciona conforme necessário. Ambas as abordagens, no entanto, não capturam a verdadeira interação do software com o hardware, tornando os erros associados a essa interação muito difíceis de detectar. Isso atrasa o cronograma de desenvolvimento e aumenta os custos de desenvolvimento, pois os problemas levantados posteriormente no processo de desenvolvimento são sempre mais caros de tratar e corrigir.

É possível usar uma placa de desenvolvimento como uma etapa intermediária para verificar a interação HW e SW antes da chegada do hardware final. No entanto, a depuração em hardware real pode ser complicada, exigindo que lógica de instrumentação adicional seja inserida no hardware. Essa inserção leva mais tempo, pois o arquivo de bits precisa ser regenerado para incluir a lógica de instrumentação. Claro, essa mudança na implementação também pode impactar o comportamento subjacente do design, mascarando problemas ou introduzindo novos problemas que se tornam aparentes apenas nas compilações de depuração.

Ser capaz de verificar os projetos SW e HW usando co-simulação, portanto, fornece vários benefícios significativos. Ele pode ser executado no início do ciclo de desenvolvimento e não requer a espera pela chegada do hardware de desenvolvimento, reduzindo assim o custo e os impactos da depuração. Além disso, tal abordagem também fornece mais visibilidade com relação aos registros e interações entre o PS e o PL, o que ajuda na descoberta e remoção de bugs no início do processo.

Co-simulação de HW e SW

A co-simulação entre SW e HW requer que a ferramenta de simulação lógica usada para verificar o projeto de HW seja capaz de interagir com um ambiente de emulação de simulação SW.

O lançamento do Riviera-PRO da Aldec (2017.10) permite apenas esta co-simulação de HW e SW, fornecendo uma ponte entre o Riviera-PRO e o QEMU, permitindo assim a execução do software desenvolvido para desenvolvimentos Zynq baseados em Linux.

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

Esta ponte foi criada usando SystemC Transaction Level Modeling (TLM) para definir os canais de comunicação entre o QEMU e o Riviera-PRO. A verificação simultânea de SW e HW é facilitada pela capacidade da ponte de transferir informações em ambas as direções.

Nesse ambiente de simulação integrado, a equipe de engenharia é capaz de usar metodologias de depuração padrão e avançadas para resolver quaisquer problemas que possam surgir à medida que a verificação prossegue. No caso do Riviera-PRO, isso inclui recursos como definir pontos de interrupção no HDL, examinar o fluxo de dados e até mesmo analisar a cobertura de código e os caminhos que são exercidos pelo aplicativo SW em execução no QEMU. No caso do QEMU, a equipe SW pode usar o Gnu DeBugger (GDB) para instrumentar o kernel e o driver para percorrer o código usando pontos de interrupção.

Essa abordagem de co-simulação tem o benefício de não apenas fornecer maior visibilidade e capacidade de depuração dentro do ambiente de simulação de hardware, mas também permite que o mesmo kernel Linux desenvolvido para o hardware de destino seja usado no QEMU. Novamente, isso fornece uma verificação anterior de que o Kernel contém corretamente todos os pacotes e elementos necessários para suportar o aplicativo em desenvolvimento.

Exemplo de PWM

Para demonstrar este ambiente de co-simulação, um exemplo simples foi criado. Este exemplo coloca um núcleo IP dentro do PL e o conecta ao Zynq PS por meio de uma interface AXI de uso geral. Quando habilitado por um acesso AXI ao seu espaço de registro, o núcleo IP irá gerar uma saída de sinal modulada por largura de pulso (PWM). A duração do sinal PWM é selecionável dentro de uma faixa de 0 a 100% e é novamente definida por um registro dentro do espaço de registro do núcleo IP. Um caso de uso típico para este núcleo, portanto, requer software em execução no Zynq PS para habilitar e configurar o núcleo IP. A simples simulação do núcleo IP isoladamente não resultará na demonstração adequada da operação desejada do núcleo. Para verificar corretamente o núcleo de IP, precisamos habilitar e exercitar a largura de pulso de saída do PS ao executar um sistema operacional Linux.