FPGA OS

Um tempo de execução do sistema operacional para aplicativos FPGA

Copyright (c) 2018-2020, Wuklab, UCSD.

Este é um sistema operacional (SO) em execução dentro do FPGA, fornecendo abstrações familiares (por exemplo, mm, agendamento, rede) para aplicativos FPGA. Este é um protótipo de pesquisa em estágio inicial. A maior parte do código é escrita em Xilinx HLS. Foi testado no VCU118 e VCU108.

É tornado público para fins educacionais. Espero que você ache isso útil.

Princípios da organização da base de código

• Faça com que cada subpasta seja um IP por si só. Isso significa que ele deve ter seus próprios scripts, código RTL ou HLS e TestBench.
• A hierarquia IPS terá dependência. Precisamos expressar a ordem explicitamente nos scripts de construção correspondentes.
• O grande projeto final deve ser expresso em um diagrama ou código RTL estático que definindo pequenos núcleos de IP.
• No geral, este projeto consistirá em muitos pequenos IPs e eles serão usados ​​internamente para construir grandes. Nosso objetivo é poder reutilizar o IPS o máximo possível e poder construir novos IPs facilmente.

Diretórios de base de código

• Lado do anfitrião:
  • host/ : pilha de rede lateral do host e drivers DMA
• Lado fpga:
  • alocador alloc/ : memória
  • mm/ : Gerenciamento de memória
  • net/ : subsistema de rede
  • kernel/ : algum código relacionado ao PR
  • system/ : grandes sistemas integrados finais
• Ambos o mundo:
  • app/ : Aplicativo pode ter o código FPGA e o host.
  • include/ : Arquivos de cabeçalho usados ​​pelo código FPGA e do host. Por exemplo, cabeçalhos de rede.
    • include/fpga : Cabeçalhos usados ​​apenas pelo HLS
    • include/uapi : cabeçalhos usados ​​por HLS e código de host
• Ajudantes
  • tools/ : vários ajudantes
  • scripts/ : arquivos de script de modelo
• Gerado
  • generated_ip/ : todos os IPs gerados dormem aqui
  • generated_hls_project/ : Vivado HLS Project
  • generated_vivado_project/ : Projeto Vivado

Formatar:

• Em geral
  • Torne o seu legível para os outros.
  • Remova os espaços e as guias finais.
  • Tente usar o estilo de codificação do kernel Linux.
• Vivado HLS
  • All Vivado HLS Script Use run_hls.tcl Nome.
• Verilog
• IP
  • Nome IP de forma consistente. Use o nome do subsistema como prefixo. Por exemplo, mm_axi_wrapper é o IP do Wrapper Axi no subsistema MM.

Tutoriais

Como construir

• Tipo make help para ver explicações detalhadas.
• O tipo make no nível superior compilará todo o projeto usando a placa padrão.
  • O kernel IPS será compilado primeiro
  • Grande sistema reside em system/ pasta
• Tipo make em cada subpasta compilará apenas essa pasta.

Fluxo de trabalho: você deve compilar o projeto quando baixar o código -fonte pela primeira vez. Todos os IPs pequenos e médios e grandes projetos estarão prontos para uso. Depois disso, você pode se concentrar no IPS que está construindo. As alterações serão refletidas automaticamente no Vivado.

Além disso, preste atenção a qual quadro você está segmentando.

Como usar o script Vivado

O objetivo de usar scripts é duplo

• Facilitar o processo de construção
• Use o Git para rastrear apenas os arquivos de origem. Porque, por padrão, o Vivado criará arquivos de grupo e todos eles não devem ser rastreados pelo Git. Neste projeto, todos os arquivos relacionados ao modo de projeto Vivado são colocados em generated_vivado_project/ Pasta, na mesma pasta em que estão o script correspondente e o código-fonte.

Esses scripts de modo de projeto Vivado são gerados pelo próprio Vivado. E esses scripts podem ser usados ​​para reconstruir todo o projeto como está.

Essas são minhas etapas não formais para criar e hackear esses scripts:

Correr:

• Execute o script:
  • vivado -mode tcl -source run_vivado.tcl
    • Um novo generated_vivado_project/ será criado na pasta atual
    • Um novo IP será embalado e exportado para generated_ip/ Pasta.
  • Se você não quiser digitá -lo toda vez, use um modelo Makefile.

Criação:

• Crie o script de nível superior:
  • Use a GUI Vivado para criar um novo projeto, adicione fontes existentes/TB/XDC, defina parte.
  • Use write_project_tcl para gerar o script. Você deve informar o novo script que o projeto que será enviado para ser computado deve ser colocado sob a pasta generated_vivado_project . E você deve nomear o script para run_vivado.tcl .
  • Se não houver diagrama de bloco (BD) no projeto, use: write_project_tcl -force -no_copy_sources -target_proj_dir ./generated_vivado_project ./run_vivado.tcl
  • Se houver projetos BD no Projeto, Use: write_project_tcl -force -target_proj_dir ./generated_vivado_project ./run_vivado.tcl

Hacker:

• Adicione os caminhos IP ao script de nível superior:

  • Isso deve ser adicionado a todos os scripts.
  • Todos os nossos IPs gerados estão em generated_ip/ Pasta. Isso facilita o rastreamento IP. Você pode adicionar poucas linhas ao script para que o Vivado saiba onde procurar novos IPs. Confira scripts/template_vivado_ip.tcl para essas linhas.

• IP do pacote automaticamente:

  • Isso deve ser adicionado a todos os scripts.
  • Queremos deixar o script empacotar IP automaticamente. Isso pode ser alcançado adicionando poucas linhas no final do script. Observe que você precisa especificar o local de destino, o nome do IP e assim por diante. Todos os nossos IPs gerados estão em generated_ip/ . Por exemplo, ipx::package_project -root_dir ../../generated_ip/mm_axi_wrapper -vendor wuklab -library user -taxonomy UserIP -import_files -set_current false -force
  • Pacote A BD como um IP: ipx::package_project -root_dir ../../generated_ip/mm_axi_rab_vcu118 -vendor wuklab -library user -taxonomy UserIP -module THE_BD_NAME -import_files

• Adicione mais arquivos de origem/xdc/simulação:

  • Primeira solução, altere manualmente o script gerado. Tente descobrir como esses arquivos existentes são adicionados, você pode modificar o script de maneira semelhante. Dicas: Pesquise top.v , add_files etc.
  • Segunda solução, adicione arquivos via Vivado GUI e use write_project_tcl novamente para gerar outro script. Em seguida, confira as diferenças.

• Invólucro bd autogererado

  • Isso deve ser adicionado se o design de nível superior for um BD
  • O motivo é: se o BD tiver interface AXI, esse axi precisará ter uma propriedade de frequência predefinida (não significa que ele deve ser executado nisso, apenas uma propriedade.). Por padrão, são 100 MHz. Se um IP for gerado a partir deste BD e usado por um IP maior, essa frequência não poderá ser alterada, o que é muito inútil. No entanto, se criarmos um invólucro para o BD e empacotarmos todo o projeto como um IP, a propriedade de frequência poderá ser atualizada automaticamente durante a integração IP.

• Outras configurações:

  • IMPORTANTE!
  • Quaisquer que sejam as alterações que você fez via GUI da Vivado (por exemplo, ordem de compilação, ordem XDC, arquivo superior da simulação) e, se você deseja salvá -lo para que outras pessoas usem, precisará usar write_project_tcl para gerar um novo script e salvar as alterações correspondentes. Depois de se familiarizar com os comandos Vivado, você poderá fazer manualmente alterando o script.

Advertências:

• Revise o script gerado
  • Verifique se algum arquivo de origem na pasta gerada automática do Vivado é usada no script. Isso acontece se o write_project_tcl não for usado corretamente. Ter arquivos gerados automaticamente é essencialmente igual a um problema de galinha e ovo.

Por enquanto, você pode encontrar scripts de exemplo no mm/axi_wrapper/run_vivado.tcl e mm/sys/run_vivado.tcl .

Como lidar com a versão IP

Vivado suporta apenas uma versão IP em cada versão. É super anonoso se usarmos o script gerado. Felizmente, há uma maneira de alternar a solução. O código a seguir substitui a sequência IP por uma variável. No entanto, tenha cuidado se o IP atualizado tiver portas diferentes.

 set axis_data_fifo [get_ipdefs -filter NAME==axis_data_fifo]
Replace all `xilinx.com:ip:axis_data_fifo:1.1` with `$axis_data_fifo

Como usar o script Vivado HLS

O script Vivado HLS é relativamente mais fácil do que o Script Vivado. Você pode encontrar o script de modelo em scripts/template_run_hls.tcl . Você deve personalizar as peças, arquivos adicionados, frequência e, portanto. Se você deseja construir automaticamente vários HLs sob a mesma pasta, use os scripts/template_generate_hls.sh

Referências

• UG1118 Vivado criando e embalando IP personalizado