FPGA da Alibaba Cloud: Kintex UltraScale+ por US$ 200
(essenceia.github.io)- Apresenta um experimento de comprar uma placa com FPGA Kintex UltraScale+ por US$ 200 e usá-la como plataforma de desenvolvimento
- A placa é vendida sem documentação oficial nem garantia, o que traz desafios para o debug via JTAG e a configuração inicial
- Explora a possibilidade de implementar por conta própria um ambiente de configuração e depuração de FPGA usando OpenOCD e Segger JLink
- Os objetivos do experimento incluem validar as interfaces PCIe/Ethernet do FPGA usado, verificar o pinout e monitorar o sistema
- Organiza os procedimentos passo a passo e a experiência de solução de problemas, desde a inicialização e conexão JTAG até a identificação da scan chain e o monitoramento de temperatura/tensão
Introdução
- O autor queria um FPGA potente para prototipagem de projetos grandes, especialmente um UltraScale+ da linha Xilinx Virtex, mas por causa do custo e do peso da licença Vivado Enterprise, restringiu a escolha aos chips Kintex UltraScale+ com suporte ao WebPack (XCKU3P, XCKU5P)
- Esses chips também oferecem especificações elevadas, acima do nível hobby, com muitos LUTs e transceptores GTY
- Era necessária uma placa de desenvolvimento que atendesse aos requisitos de pelo menos 2 SFP+ ou 1 QSFP, JTAG e PCIe x8 ou superior; entre projetar uma própria, comprar um produto da Alinx ou procurar no mercado de usados, acabou comprando no Ebay uma placa aceleradora FPGA da Alibaba Cloud por US$ 200
- A placa comprada não tinha nenhum suporte documental e nem havia certeza de que funcionava corretamente, mas a ideia de hackear uma placa Kintex UltraScale+ por um preço baixo pareceu atraente
Desafios com o depurador
- Segundo o documento UG908 da Xilinx, o normal é configurar e depurar o FPGA com uma sonda JTAG recomendada, mas em vez de uma sonda oficial cara, foi tentada uma alternativa open source, como OpenOCD
- Em troca de abrir mão da toolchain oficial da Xilinx (como ILA), é possível desenvolver uma lógica própria de depuração baseada em registradores JTAG USER
- O OpenOCD é usado principalmente com ARM/RISC-V, mas também pode ser aplicado a FPGA por suportar uma ampla variedade de sondas, controle fino de operações JTAG e o formato SVF
- Há pouca documentação sobre suporte à série UltraScale+, mas os padrões de JTAG e SVF, assim como a estrutura de scan, continuam válidos
Plano geral
- Trata-se de um plano experimental passo a passo para configurar e usar como plataforma de desenvolvimento uma placa FPGA usada, comprada barata no Ebay, com ferramentas open source/sondas não oficiais (OpenOCD, JLink etc.) sem suporte oficial
- As etapas seguem a ordem: verificar se os dispositivos da placa funcionam → conectar um depurador JTAG → descobrir o pinout → transferir o bitstream
Etapa 1 - Verificar se a placa funciona normalmente
- Se a memória Flash não tiver sido apagada, é possível fazer uma verificação inicial do funcionamento identificando um endpoint PCIe do bitstream do usuário anterior ou observando a presença de sinal Ethernet no PHY SFP
Etapa 2 - Conectar o depurador JTAG
- É necessário descobrir a posição dos pinos da interface JTAG, quantos dispositivos estão conectados e a situação da daisy chain
- Também é possível usar os registradores de sistema JTAG do FPGA (especialmente o SYSMON) para monitoramento em tempo real de temperatura/tensão, e espera-se ampliar o suporte do openOCD
Etapa 3 - Descobrir o pinout
- É preciso analisar o circuito físico para identificar tipo/frequência/pinos da fonte de clock externa, além das informações dos transceptores conectados a SFP e PCIe
Etapa 4 - Gravar o bitstream
- O plano é usar configuração temporária via JTAG (ignorando a Flash), o driver
virtex2+plddo openOCD, ou a reprodução de SVF gerado pelo Vivado - Está prevista a automação de todo o fluxo Vivado → SVF
Recebimento da placa e testes iniciais
- Foram recebidos a placa com FPGA Kintex UltraScale+ (XCKU3P-FFVB676), vinda de um acelerador da Alibaba Cloud, além de um transceptor Huawei SFP28 25G e um cabo patch OS2, entre outros itens
- A placa mostra algum uso, mas os componentes e o estado de PCIe/SFP estão bons
Verificação de energia em modo standalone
- Foi feita uma injeção simples de energia com um adaptador PCIe-USB e uma checagem inicial de alimentação pela presença de LEDs e aquecimento do hardware
Experimento com a interface PCIe
- Aproveitando a interface externa PCIe Gen2.0 x1 do Raspberry Pi 5 para testar o FPGA (com suporte a Gen3.0 x8), espera-se que ele seja reconhecido corretamente por retrocompatibilidade
- Nos logs
dmesgdo Linux, a placa foi reconhecida como PCIe Bridge e endpoint (tipo Ethernet); IDs de vendor/device proprietários evitam conflitos com o sistema operacional - Com o comando
lspci -vvv, foi verificado o estado completo do dispositivo PCIe: a placa declara suporte a Gen3.0 x8, mas quando conectada ao Pi a largura de banda/velocidade cai para Gen2.0 x1 (por causa das limitações da bridge e da conexão física real) - Com isso, foi confirmada a operação normal da interface PCIe da placa FPGA
Interface JTAG
- Em FPGAs da Xilinx, o JTAG pode atualizar/carregar em SRAM o CMOS Configuration Latch (CCL) interno
- Na placa física, a interface JTAG é composta pelos 4 sinais padrão (TCK/TMS/TDI/TDO) e sinais de alimentação/terra; o reset pode ser implementado via FSM da Xilinx
- O arranjo real dos pinos difere do padrão, exigindo cabeamento separado
Uso do Segger JLink
- Sem um programador JTAG oficial da AMD, foi usado um Segger JLink junto com o OpenOCD
- Como o JTAG pode ser montado com apenas 4 GPIOs, ele é adequado para experimentos improvisados
- Foi fornecido um diagrama de ligação entre o JLink e a placa FPGA, e considerando jumpers de protoboard e atrasos maiores de sinal, a velocidade de TCK (clock) foi limitada a 1~10 MHz
Ambiente OpenOCD
- O OpenOCD é um depurador open source on-chip com suporte a várias sondas e placas
- Como oferece suporte ao formato SVF padrão (integrando-se ao Vivado) e tem o circuito aberto, fica mais fácil analisar e corrigir problemas diretamente quando eles surgem
- Foi usada uma versão mais recente do OpenOCD (
0.12.0+dev) compilada manualmente junto com a biblioteca do JLink
Verificação da JTAG Scan Chain e checagem do IDCODE
- Sem conhecer o esquemático da placa, foi usado o recurso de varredura automática do OpenOCD para descobrir os dispositivos/IDCODEs na cadeia JTAG
- Foi confirmado que esta placa corresponde ao IDCODE do Xilinx KU3P (
0x04a63093) - A detecção correta só foi possível após definir manualmente também o comprimento do IR (registrador de instrução, 6 bits)
- Por fim, a JTAG scan chain da placa foi mapeada
Monitor de sistema SYSMON
- Nas gerações antigas da Xilinx, a medição de temperatura/tensão era feita por XADC; na linha UltraScale+, esse recurso está embutido no SYSMON4
- O openOCD padrão não oferece suporte à integração JTAG com o SYSMON, então foi necessário acrescentá-lo manualmente
- Foi possível hackear por script até a funcionalidade de envio de comandos SYSMON (DRP) e leitura em tempo real de temperatura/tensão via registradores de status
Por meio desse processo, foi registrado o aprendizado de obter barato uma antiga placa aceleradora FPGA da Alibaba Cloud sem suporte oficial e, usando apenas ferramentas open source, estabelecer a base para depuração e uso prático (interfaces PCIe/JTAG e monitoramento do sistema).
1 comentários
Comentários no Hacker News
Testei a interface PCIe da placa Lattice Certus-Pro NX "Versa" com um Raspberry Pi V e achei extremamente prático O Raspberry Pi V é rápido o suficiente para rodar software moderno de desktop, até Microsoft Teams! Consegui fazer uma demo ao vivo de um design em FPGA e compartilhar a tela do desktop durante uma chamada de conferência Só foi uma pena a falta de documentação do SoC da Broadcom A Intel fornecia toda a documentação dos chips mediante NDA, então foi possível montar um ótimo ambiente de FPGA PCIe em um Xeon Ivy Bridge Depois de salvar os registradores de configuração PCI, reconfigurar o FPGA e programar os registradores novamente, o chip aparecia no barramento sem precisar reiniciar o servidor nem fazer re-enumerate, o que era muito conveniente O segredo era definir temporariamente os bits de root complex durante a reconfiguração para desativar a detecção de erros PCIe (Na época eu usava um Altera Stratix-IIgx) Talvez exista outro jeito, então deixo uma referência: link do Stack Overflow No geral, quando a documentação é boa, o relatório de erros no processo de inicialização do PCIe é muito útil
Se você tiver um adaptador FT2232H (ou recomendo comprar um, caso não tenha), dá para gravá-lo para ser facilmente compatível com o Vivado Referência: guia de programação de dispositivos FTDI para o Vivado
Na nossa empresa, sempre mantemos de 20 a 30 FT2232H em estoque É realmente útil por suportar vários protocolos como GPIO, I2C, SPI, parallel FIFO etc. E a biblioteca Python pyFTDI é excelente
Tenho um desses adaptadores sobrando de outro projeto, mas nunca trabalhei com FPGA Fico curioso sobre o que significa, na prática, ser compatível com o Vivado Isso quer dizer que dá para configurar FPGA da AMD, ou significa outra coisa?
Isso me lembrou o caso inovador em que a Alibaba usou um cluster de FPGA para fazer LSM compaction na área de banco de dados com um mecanismo de armazenamento MySQL customizado Referência: PDF do artigo relacionado Em comparação com o RocksDB, o throughput e a latência melhoraram drasticamente, e em algumas cargas de trabalho foi um salto de outro nível Eles chegaram a oferecer essa tecnologia como serviço, mas acabaram encerrando-a Ainda não sei se continuam usando internamente, mas me surpreende que quase ninguém aproveite aceleração por hardware para tarefas repetitivas de banco de dados
Se você se interessa por FPGA PCIe ou placas PCI, também há bastante placa Gidel usada por aí Existem várias séries, como ProcSpark e ProcStar O software oficial é proprietário e, como há vários FPGAs, para usar direto no Quartus é preciso encontrar o pinout Eu consegui uma placa com um Stratix IV gigantesco Uma placa Kintex UltraScale+ é realmente de dar água na boca, então este post me impressionou bastante
Se você estiver na China, o mesmo produto está sendo vendido no idlefish por 480 yuans (cerca de 68 dólares) É barato a ponto de parecer inacreditável, então pretendo testar por conta própria
Não sei se já descobriram a informação de pinout do conector SFP na parte traseira Se isso estiver documentado e as linhas PCI-e também forem confirmadas, acho que seria divertido tentar montar equipamento de rede óptica customizado com isso Como transceptores SFP basicamente reproduzem a saída a partir da entrada, isso permitiria criar dispositivos ópticos customizados interessantes, tanto em um backplane PCIe quanto de forma independente
Alguém conhece exemplos de implementação de redes neurais ou outras arquiteturas conexionistas com FPGAs? O mais interessante em FPGAs é que até universidades ou indivíduos conseguem arcar com um chip "customizado" Num momento em que a IA está tão concentrada em LLMs, acho que pequenos grupos ou indivíduos têm a chance de experimentar abordagens de inteligência artificial bottom-up inspiradas em animais com FPGAs
No FNAL, usam redes neurais baseadas em FPGA para inferência nos resultados dos experimentos de física de altas energias do LHC/CMS Há também casos de controle de sistemas dinâmicos em escala de microssegundos Materiais de referência: HLS4ML PDF da apresentação CERN IRIS-HEP Whitepaper sobre deploy de tinyML em FPGAs PDF de caso no NeurIPS ML4PhysicalSciences
Fico curioso se "implementar redes neurais com FPGAs" significa usar como acelerador de hardware para inferência, ou sintetizar a rede inteira (incluindo os pesos) diretamente na arquitetura do FPGA Em qualquer um dos casos, o FPGA não implementa lógica completamente arbitrária; ele usa blocos limitados a partir do resultado da síntese de software Para casos como LLMs, que exigem muita memória de alta capacidade e alta largura de banda, não é adequado Até dá para conectar memória rápida ao FPGA, mas hoje as GPUs são muito superiores para esse tipo de uso
Vale a pena dar uma olhada em differentiable logic gate networks
Artigo de referência: arXiv:2404.10076
Fico me perguntando por que houve tantos downvotes Pelo que entendo, IA precisa de muita RAM e RAM rápida para os modelos, então FPGA não é a melhor opção FPGAs têm pinos para conectar RAM rápida, mas o design da placa e o roteamento das trilhas em camadas ficam extremamente complexos Por isso, placas de vídeo são muito mais adequadas
Quando vejo esse hype de IA, penso pessoalmente o seguinte
Ainda há bastante estoque no eBay link do eBay Não parece haver GPIO exposto em headers ou algo assim, então aceito sugestões de projetos interessantes para usar isso
Fiquei impressionado com o fato de que "a placa vem com uma maleta de viagem" Fiquei me perguntando o motivo: será que esse tipo de placa é removido e transportado com frequência em datacenters? Ou foi o vendedor do eBay que colocou por proteção?