Como evitar que projetos baseados em FPGA se desviem

Durante o curso da minha carreira, estive envolvido no desenvolvimento de uma série de designs de FPGA para alguns projetos realmente interessantes. Infelizmente, também estive envolvido no resgate de vários projetos de FPGA que se perderam. Conforme eu trabalhava nesses designs de problemas, tornou-se aparente que - embora os aplicativos-alvo e os membros das equipes de desenvolvimento fossem diferentes - os designs compartilhavam alguns pontos comuns que os condenavam ao fracasso antes mesmo que o primeiro engenheiro sentasse para escrever a primeira linha do código HDL.

(Fonte:pixabay.com)
Com isso em mente, pensei em passar por cinco problemas comuns que observei como parte do resgate desses projetos. Esses problemas são os seguintes:

nº 1: A primeira preocupação não se refere apenas ao desenvolvimento baseado em FPGA, mas à engenharia em geral. O problema é não ter uma linha de base de requisitos estável ao iniciar. Sempre há um desejo de iniciar o projeto enquanto os requisitos ainda estão amadurecendo, com base no progresso que precisa ser demonstrado. No entanto, se pularmos e começarmos a desenvolver sem entender totalmente os requisitos, então - com muita frequência - qualquer progresso inicial acabará sendo falso e a execução de correções posteriores introduzirá atrasos e custos adicionais. O que começar cedo demais realmente faz é introduzir riscos no desenvolvimento, e esse risco precisa ser mitigado. Agradeço que, dependendo da aplicação em questão, a profundidade e os detalhes dos requisitos podem ser escalonados. Eu esperaria muito mais requisitos, e mais detalhados, para um sistema SIL4 do que para um sistema comercial. No entanto, o resumo é que, se os requisitos não forem acordados e definidos desde o início, haverá aumento do escopo. Embora o design possa ter começado com uma arquitetura sensível para os requisitos conforme entendidos, ele se tornará cada vez mais complicado quando os desenvolvedores tentarem usar uma nova funcionalidade conforme a linha de base amadurece. Em pouco tempo, algo vai quebrar.

nº 2: Tendo compreendido a situação dos requisitos, cada membro da equipe precisa entender o plano para desenvolver o FPGA. Portanto, é uma boa ideia ter um plano que defina a abordagem que será seguida desde o início até a entrega, identificando as principais etapas envolvidas e as portas de revisão de engenharia que serão aplicadas durante o processo de desenvolvimento. Junto com o plano, também precisamos documentar a arquitetura e o design, identificando cada uma das principais funções, decidindo quais funções devem ser desenvolvidas recentemente e quais devem alavancar IP de terceiros ou reutilizar IP existente (mais sobre este mais tarde). Esta documentação combinada de plano, arquitetura e descrição do projeto permitirá que a equipe de engenharia entenda claramente a tarefa em questão. Também podemos rastrear todas as funções até o conjunto de requisitos para garantir que a abordagem proposta atenda a todos os requisitos de alto nível.

# 3: O projeto dos módulos e do FPGA geral levará tempo; o que vai demorar mais, entretanto, é verificar o projeto e garantir que ele atenda aos seus requisitos. Essa verificação deve abranger não apenas a funcionalidade lógica, mas também deve ser realizada em todas as condições operacionais possíveis do dispositivo. Por sua vez, isso significa que é necessário desenvolver uma estratégia de verificação clara para o projeto; não é mais o caso de apenas escrever o código, realizar algumas simulações e, em seguida, jogar o design no hardware.

nº 4: Às vezes, todos nós chegamos tão perto das coisas e nos fixamos em nosso pensamento que se torna difícil ver quando perdemos alguma coisa. É para isso que as revisões de projeto de engenharia foram inventadas. Ao realizar essas análises, podemos garantir que estamos seguindo as boas práticas de engenharia e cumprindo os padrões internos de desenvolvimento. Significativamente, eles também fornecem a capacidade para engenheiros independentes examinarem o projeto - sua arquitetura e implementação - para garantir que ele fornecerá a funcionalidade necessária. Se não revisarmos o design à medida que ele progride, não conseguiremos aumentar a qualidade e aumentaremos quaisquer problemas de integração downstream.

# 5: Até agora, você deve ter notado que a maioria dos pontos que levantei está relacionada ao processo e a aspectos mais amplos de engenharia, em oposição à codificação do próprio projeto. Obviamente, desenvolver o código é importante, mas também é importante garantir que estamos aproveitando o IP de terceiros e reutilizando o IP interno. Idealmente, devemos reutilizar o máximo possível de blocos de IP existentes em nossa biblioteca. Onde isso não for possível, iremos - é claro - precisar desenvolver novos módulos. Nesse caso, a criação desses novos módulos de forma que possam ser reutilizados em projetos futuros deve estar em primeiro lugar em nossas mentes. Para nos ajudar a criar esses novos blocos, devemos considerar o uso de ferramentas de síntese de alto nível (HLS). Ao nos permitir trabalhar em um nível mais alto de abstração, essas ferramentas fornecem a capacidade de explorar mais facilmente o espaço da solução e reduzir o risco, o tempo de desenvolvimento e os custos.

Os pontos apresentados acima são apenas algumas das coisas que observei ao resgatar projetos de FPGA. Eu ficaria muito interessado em ouvir sua opinião sobre projetos que deram errado.