Fluxo de design de CPU mais FPGA para desenvolvedores de software:Uma nova realidade tangível

Recentemente, Brian Bailey organizou uma mesa redonda que resultou em um artigo de duas partes chamado Supporting CPUs Plus FPGAs . Os especialistas discutiram a realidade em evolução do design de sistemas baseados em FPGAs e CPUs. Esta discussão aborda os desenvolvimentos recentes no fluxo de design e como o uso de novas tecnologias pode ajudar os desenvolvedores de software a alcançar um tempo de colocação no mercado mais rápido para CPU mais plataformas FPGA.

Introdução
Olhando para o crescente interesse em inteligência artificial (IA), o surgimento de objetos conectados (IoT) e a tendência de aceleração do data center, tudo nos leva a perguntar:qual é o denominador comum entre os três?

Os desenvolvedores de software estão no centro de todas essas tendências e procuram acelerar sua programação e cálculos. Os avanços tecnológicos mais recentes, incluindo baixa latência de comunicação entre FPGAs e CPUs, juntamente com o consumo de energia relativamente baixo dos FPGAs atuais, tornam os sistemas baseados em FPGA e CPU a escolha certa para atingir o desempenho desejado. No centro dessa convergência, entretanto, os desenvolvedores de software são prejudicados pela complexidade subjacente da tecnologia FPGA.

Nos últimos anos, as ferramentas de síntese de alto nível (HLS) melhoraram muito em relação à complexidade do sistema atual e à redução do tempo de colocação no mercado. No entanto, as ferramentas HLS se concentram principalmente em blocos de IP (ou seja, eles são centrados em IP). Há uma ampla gama de decisões / otimizações no nível do sistema que não podem ser suportadas pelas ferramentas HLS para satisfazer os requisitos. Alguns desses requisitos incluem encontrar o equilíbrio certo entre tarefas de software e aceleradores de hardware, comparar pipeline e execução paralela, alcançar a granularidade de dados desejada, avaliar mecanismos de comunicação e muito mais.

Para construir esses sistemas complexos, os desenvolvedores de software exigem um fluxo de design que ofereça suporte conjunto de hardware e software. Esse fluxo deve ser simples o suficiente para garantir seu uso (como o fluxo de desenvolvedor de software) e adoção pelos desenvolvedores de software. O fluxo também deve fornecer feedback perspicaz sobre as opções de otimização disponíveis para atingir os objetivos de desempenho necessários. Algumas empresas abriram recentemente o caminho para facilitar a tarefa para desenvolvedores de software, abstraindo os detalhes tecnológicos do fluxo de design de hardware. Essas empresas são inspiradas pelas abordagens de design de nível de sistema descritas em Modelos ESL e sua aplicação:design de nível de sistema eletrônico e verificação na prática .

Compreendendo a metodologia de fluxo de projeto em nível de sistema
O Design de Nível de Sistema é focado em questões de nível de abstração mais alto. Embora seja necessário concentrar-se no quadro mais amplo, vários níveis de abstrações são usados ​​para validar, verificar, refinar e integrar diferentes partes do sistema antes que ele seja realmente desenvolvido. Mesmo que a comunidade de engenheiros não concorde com uma linguagem comum a ser usada, a maioria dos engenheiros de projeto começa no nível algorítmico. Os designers validam as especificações não funcionais e funcionais do sistema criando modelos de execução escritos em ambientes C / C ++ / SystemC, MATLAB, Simulink e LabVIEW. Essas linguagens de alto nível são usadas para modelar o comportamento de todo o sistema.

Para os fins desta discussão, nos concentramos em um fluxo de design em nível de sistema com base nas especificações C / C ++ (Figura 1). O primeiro bloco é dividido em três etapas. A primeira dessas etapas representa o perfil do aplicativo (ou seja, particionamento de hardware-software), onde pedaços de código C / C ++ (funções, loops, etc.) estão sendo considerados para serem movidos para o hardware (FPGA). A próxima etapa é a especificação da plataforma CPU / FPGA (por exemplo, ARM53 / FPGA, POWER8 / FPGA) e configuração dos elementos da plataforma de hardware (relógio do sistema, cache do processador, interconexões, etc.). A etapa a seguir é mapear as tarefas do aplicativo (com base no aplicativo perfilado) entre hardware e software (ou seja, CPU dura e / ou soft) e - no final - a geração de uma arquitetura executável.

Figura 1. Fluxo de projeto de nível de sistema típico para CPU / FPGA
(Fonte:Space Codesign Systems, Inc.)
O segundo bloco da Figura 1 envolve a otimização da arquitetura (também conhecida como exploração arquitetônica ou verificação de desempenho). Isso é descrito com mais detalhes na Figura 2.

Figura 2. O processo de otimização da arquitetura
(Fonte:Space Codesign Systems, Inc.)
O processo de otimização da arquitetura aborda os seguintes estimadores:

• Estimativa de hardware avalia métricas de particionamento de hardware (ou seja, código C / C ++ movido no FPGA). Ele pode ser dividido por recursos, desempenho (por exemplo, latência de loop) e estimativas de energia. A estimativa de hardware é conduzida por ferramentas HLS (High-Level Synthesis).
• Estimativa de software avalia as métricas para o código de partição C / C ++ em execução na CPU (ou seja, CPU rígida e / ou flexível). Este processo é complementar à etapa de estimativa de hardware. Exemplos de métricas de desempenho são carga do processador, troca de tarefas e perda de cache.
• Estimativa de transferência de dados consiste na modelagem das interfaces (ou seja, interfaces de memória mapeada e streaming) pelas quais o hardware e o software se comunicam. Exemplos de métricas coletadas são o desempenho do barramento (por exemplo, latência e taxa de transferência), fila e uso de memória.

Essas estimativas são agregadas em um banco de dados e uma análise de desempenho do sistema é apresentada ao desenvolvedor para avaliar se os requisitos do sistema estão sendo atendidos. As arquiteturas que atendem aos requisitos seguem para o processo de implementação da arquitetura; caso contrário, tentativas adicionais de otimização no nível do sistema serão processadas.

O último bloco da Figura 1 refere-se à implementação da arquitetura onde as arquiteturas do sistema são convertidas em bitstream (para implementação FPGA) usando ferramentas de implementação como Xilinx Vivado ou Intel Quartus Prime para a geração final e completa do sistema a ser executada na plataforma física específica. Esta etapa deve produzir código de qualidade e deve ser transparente para o desenvolvedor de software.

Otimização em nível de sistema
A falta de ferramentas automatizadas para otimização arquitetônica há muito tempo é percebida como uma das principais fraquezas da computação baseada em FPGA. O desenvolvimento de tais ferramentas foi difícil devido à complexidade e aos desafios envolvidos.

Para ilustrar esses desafios, a Figura 3 mostra um processo típico de otimização em nível de sistema durante uma exploração arquitetônica para um aplicativo de processamento de imagem composto por seis funções (partes de código C / C ++) a serem implementadas em uma plataforma Zynq-7000. Aqui, listamos oito arquiteturas potenciais que podem ser implementadas na plataforma. Como o time-to-market não permite a implementação de cada arquitetura, a melhor a ser implementada deve ser determinada rapidamente. Essa sequência de otimizações pode ser desafiadora, mesmo para designers de hardware experientes.

Figura 3. Exploração da arquitetura com decisões no nível do sistema mostradas em azul
(Fonte:Space Codesign Systems, Inc.)
As ferramentas de desenvolvimento de software FPGA como SDSoC / SDAccel (Xilinx), Merlin Compiler (Falcon Computing Solutions) e SpaceStudio (Space Codesign Systems) são soluções comerciais que auxiliam os desenvolvedores de software no projeto de sistemas FPGA / CPU ao mesmo tempo em que alcançam a otimização no nível do sistema. Essas ferramentas adotam um fluxo semelhante ao descrito nas Figuras 1 e 2 e, com isso, demonstram a existência de uma nova geração de ferramentas em nível de sistema com diferentes abordagens.

O SDSoC estima o desempenho do sistema em uma abordagem de duas etapas. Inicialmente, o SDSoC estima as latências para as funções de hardware (de ferramentas HLS) e caracterização interna (ou seja, transferência de dados) da plataforma física alvo e suas interfaces de comunicação. Posteriormente, essa estimativa é comparada com uma versão somente de software do aplicativo em execução na plataforma física.

O Merlin Compiler propõe a transformação de fonte em fonte. O objetivo da transformação de fonte para fonte é reduzir ou eliminar a lacuna de abstração de design entre o desenvolvimento de software / algoritmo e os fluxos de design HLS existentes. O Compilador Merlin conta com quatro pragmas para inferir projetos FPGA específicos. Além das quatro principais otimizações acionadas por pragmas explícitos, o Merlin Compiler também contém várias otimizações implícitas (ou seja, transformações do compilador) que são realizadas junto com os pragmas para ajudar a melhorar os resultados do pipeline e da paralelização.

O SpaceStudio gera perfeitamente uma plataforma virtual executável (VP) para cada candidato à arquitetura (mapeamento). Um VP típico é composto de simuladores de núcleo de processador conectados a vários modelos de barramentos, controladores de memória e outros modelos de periféricos de dados. Ele modela a plataforma de destino junto com as transferências de dados em um ambiente cossimulado que é adaptado especificamente para o aplicativo. Isso significa que o VP executável permite uma previsão de desempenho mais precisa e validação de algoritmo do aplicativo. Ele também integra recursos de monitoramento e análise para perfis de desempenho não intrusivos de funções de hardware e tarefas de software. VP depende de ferramentas HLS para estimadores de hardware, enquanto atrasos (por exemplo, latências) de funções mapeadas de hardware são anotados automaticamente para aumentar a precisão do processo de simulação. O VP pode ser inspecionado pelo desenvolvedor de software para entender como as tarefas de otimização são implementadas. Esse feedback ajuda o desenvolvedor de software a alcançar o design pretendido para as otimizações específicas aplicadas.

Uma maneira de ver o ecossistema comercial
A Figura 4 propõe uma visão do ecossistema comercial gravitando ao redor do mundo de projetos baseados em plataformas de CPUs e FPGAs. A primeira caixa (superior) apresenta a entrada principal do projeto no nível do algoritmo. A segunda caixa contém ambientes que suportam a síntese algorítmica (ou seja, do algoritmo à implementação). As ferramentas marcadas em negrito suportam a entrada de design C / C ++ e executam otimizações no nível do sistema. A terceira caixa representa as ferramentas usadas para alcançar a implementação arquitetônica, principalmente ferramentas de fornecedores de FPGA que realizam a síntese de baixo nível e a geração de fluxo de bits. Na parte inferior da figura, exemplos de plataformas CPU / FPGA são ilustrados.

Figura 4. Ecossistema comercial para plataformas CPU / FPGA
(Fonte:Space Codesign Systems, Inc.)
Além disso, a Tabela 1 lista algumas das principais ferramentas comerciais usadas no design da plataforma CPU / FPGA.

Tabela 1. Ferramentas de automação comercial (* Observação:uma lista é proposta nesta revisão)
Conclusão
O objetivo final é democratizar o desenvolvimento de plataformas CPU mais FPGA para uma população mais ampla de usuários, como a comunidade de desenvolvedores de software. Olhando para a analogia das linguagens de programação, o setor de TI levou mais de 50 anos para que as linguagens de programação evoluíssem para linguagens amigáveis, como Python ou, mais recentemente, Swift. Um processo de evolução semelhante está acontecendo na indústria de programação FPGA. A aceitação das ferramentas HLS levou algum tempo para ser endossada pelos projetistas do sistema. Hoje, com o advento das soluções em nível de sistema para desenvolvedores de software, estamos entrando em uma nova fase. Ferramentas comerciais como SpaceStudio, SDSoC e Merlin Compiler são o testemunho desse processo de aceitação. Ainda assim, ainda há muito trabalho a ser feito para ter um processo totalmente automatizado e otimizado entre os compiladores voltados para a CPU mais as plataformas FPGA.

Guy Bois, Ing., PhD é o fundador da Space Codesign Systems e professor do Departamento de Engenharia de Software e Computação da Politécnica de Montreal. Guy participou de muitos projetos de P&D em colaboração com líderes da indústria, como STMicroelectronics, Grass Valley, PMC Sierra, Design Workshops Technologies e Cadabra Systems. A experiência de pesquisa de Guy no campo de codesign de hardware / software levou à comercialização da solução e ao início do SpaceStudio da Space Codesign Systems Inc.