Usando o SVN com o Xilinx Vivado?


13

Acabei de declarar o uso do Vivado em um novo projeto e gostaria de colocar os arquivos do projeto no SVN.

O Vivado parece criar todos os arquivos do projeto sob o nome do projeto (por exemplo, proj1):

/<path to the project>/proj1/
                            proj1.xpr
                            proj1.srcs/
                                       constrs_1/
                                                new/
                                                    const1.xdc
                            proj1.runs/
                            proj1.data/
                            proj1.cache/

Minha pergunta é quais são os arquivos que eu preciso colocar no SVN que não sejam o XDC e o arquivo XPR?


1
Por que você acha que não precisa de todos, se eles?
Grady Player

6
Eu não entendo o que você quer dizer aqui. O Vivado cria um monte de arquivos que não precisam ser controlados desde que são gerados. Meus arquivos de origem estão em outro lugar, só preciso salvar os arquivos que são importantes para o Vivado.
precisa saber é o seguinte

Eu diria que, como a única entrada é o código-fonte, esse é o único arquivo a ser colocado no SVN. Mas eu nunca usei, apenas supondo
clabacchio

Existe uma opção limpa? Você pode limpar e verificar tudo.
Grady Player

2
Estou criando um script TCL para regenerar o projeto Vivado. E coloque esse sob controle de versão. Ao criar o projeto (com make), ele criará os arquivos que o Xilinx precisa. Isso me impede de verificar o diretório completo do projeto e os arquivos do Xilinx.
Vermaete #

Respostas:


6

O Xilinx cria um vídeo do YouTube (suspiro) para lidar com isso. Aqui está o link para o vídeo

http://www.xilinx.com/training/vivado/vivado-version-control-overview.htm

Aqui está o meu resumo do vídeo (8 minutos)

Antes que você comece

Se você realmente gosta de controle total, o Xilinx sugere que você renuncie inteiramente à GUI e faça tudo na linha de comando e saiba o que é fonte e o que não é.

Caso contrário, o Xilinx perceberá que os projetos do Vivado não foram projetados para controle de versão. NÃO VERIFIQUE TODO O PROJETO. Mas continue lendo para obter dicas ...

Linha de base

Obviamente, qualquer coisa que você escrever fora da ferramenta Vivado deve ser registrada.

Verifique nos seguintes arquivos

*.v, *.vh, *.vhdl, *.edif  - HDL and Netlist
*.xdc - Constraints
*.xci - IP Core
*.bd  - IP Integrator Block Diagram
*.xmp - Embedded Subsystem
*.sgp - System Generator Subsystem
*.bmm
*.cdc - Chipscope
*.elf
*.mem

Blocos IP

Se você usar blocos de IP, gere o IP em uma pasta exclusiva e faça check-in de tudo.

Pontos de verificação

Se você deseja executar novamente partes do fluxo sem executar tudo, verifique os arquivos do ponto de verificação.

*.dcp - Design Checkpoints

My Adendum

Se as ferramentas do Xilinx fossem eficientes, eu não recomendaria o check-in dos arquivos dcp, mas eles levam tantas horas para serem executados que pode valer a pena às custas de um feio sistema de controle de versão.

O vídeo não diz agachamento sobre os arquivos do projeto Vivado (* .xpr), então aqui está minha sugestão:

*.xpr
*.data/*/fileset.xml
*.data/*/runs.xml

A alternativa que o Xilinx recomenda (que é realmente um hack, não é adequado para controle de versão) é executar o File -> Write Project Tclcomando toda vez que você desejar confirmar e, em seguida, confirmar esse arquivo TCL no controle de versão. Quando você atualiza sua pasta local, é necessário executar novamente o arquivo TCL para criar todos os arquivos do projeto. Que nojo.


Ótimo, isso foi realmente útil. Eu não uso mais o SVN, mas o GIT, mas isso me ajuda a obter os arquivos corretos no repositório.
FarhadA

1
Eu uso os arquivos tcl e ele realmente funciona muito bem. Os scripts tcl só precisam ser atualizados quando um arquivo é adicionado a um projeto, e geralmente eu gero o tcl quando todos os arquivos estão inseridos. Eles não são tão nojentos ou hacky quanto você imagina.
Stanri 03/07/2014

A solução TCL seria ideal se o Vivado criasse automaticamente o arquivo TCL após cada alteração do projeto E lesse o arquivo TCL como o arquivo "project" em vez do arquivo xpr. Em outras palavras, se o Xilinx se livrou do arquivo xpr e o substituiu pelo arquivo tcl.
MarkLakata

Existe um pequeno problema com o envio do arquivo xpr: ele muda sempre, mesmo quando você abre apenas o Vivado ...
Piedone

3

O Vivado 2014.1 permite o uso de scripts .tcl para regenerar projetos.

Para fazer isso, com o seu projeto aberto, vá em Arquivo -> Escrever Projeto tcl.

Projetos Básicos

Eu costumo armazenar minhas fontes e o script .tcl em um local fora do diretório do projeto. Os núcleos IP xilinx gerados no projeto podem ser copiados em outro local clicando com o botão direito do mouse no núcleo e selecionando "Copiar IP". E excluindo o original. Quando o script tcl é gerado, ele cria links relativos para esses arquivos. Geralmente é assim que minha estrutura de diretórios se parece:

base_project/
 srcs/
  project.v
 ip/
  ip1/
   ip1.xml
   ip1.xci
 genproject.tcl

Apenas os arquivos .xml e .xci do IP precisam ser confirmados. (E mesmo isso não é necessário, tecnicamente, veja as notas no final).

É isso que se compromete com o git, observe a falta de project.xpr ou diretórios do projeto.

Quando executo genproject.tcl, ele cria outro diretório para o projeto.

base_project/
 srcs/
 ip/
 genproject.tcl
 projectdir/
  project.runs/
  project.cache/
  project.xpr

Esta nova pasta é completamente descartável. Para criar essa estrutura, modifico o script tcl da seguinte maneira.

Altero as 3 primeiras linhas da seguinte maneira:

# Set the reference directory for source file relative paths (by default the value is script directory path)
set origin_dir [file dirname [info script]]

# Set the directory path for the original project from where this script was exported
set orig_proj_dir "[file normalize "$origin_dir/projectdir"]"

# Create project
create_project project $projectdir/project

Isso cria um novo diretório de projeto e o novo projeto nesse diretório.

Depois modifico os caminhos para apontar para os lugares corretos. Pode ser necessário alterar esses caminhos em outros lugares do script.

# Set 'sources_1' fileset object
set obj [get_filesets sources_1]
set files [list \
 "[file normalize "$origin_dir/srcs/project.v"]"\
 "[file normalize "$origin_dir/ip/ip1/ip1.xci"]"\
]
add_files -norecurse -fileset $obj $files

Também modifico as execuções de design para núcleos IP, como visto nesta resposta .

Os arquivos .wcfg podem ser incluídos de maneira semelhante ao ip e srcs.

É aqui que o processamento termina para projetos mais simples (contendo apenas fontes e IP, sem diagramas de blocos). Também é necessário fazer o seguinte para armazenar os dados do diagrama de blocos.

Projetos de diagrama de blocos

Para salvar o diagrama de blocos, com o diagrama de blocos aberto, vá em Arquivo -> Exportar -> Diagrama de Blocos para Tcl e salve-o no mesmo diretório que o outro arquivo tcl.

Então eu criei um Generate_Wrapper.tclscript que cria os arquivos do wrapper do diagrama de blocos para que você não precise fazer isso manualmente. A pasta project / project.srcs é usada para armazenar os dados bd, mas ainda é completamente descartável, pois o bd é armazenado no script tcl. Salve isso com os outros dois.

set origin_dir [file dirname [info script]]

make_wrapper -files [get_files $origin_dir/project/project.srcs/sources_1/bd/design_1/design_1.bd] -top
add_files -norecurse -force $origin_dir/project/project.srcs/sources_1/bd/design_1/hdl/design_1_wrapper.v
update_compile_order -fileset sources_1
update_compile_order -fileset sim_1

No final, genproject.tcladiciono as seguintes linhas para gerar o diagrama de blocos e os invólucros:

source $origin_dir/Create_bd.tcl
source $origin_dir/Generate_Wrapper.tcl
regenerate_bd_layout

Para projetos sem fonte (apenas diagrama de blocos), meu commit do git é o seguinte:

base_project/
 Generate_Wrapper.tcl
 Create_Bd.tcl
 genproject.tcl

Para gerar tudo, execute genproject.tcl.

Você pode até combinar tudo isso em um, se for particularmente eficiente, ainda não cheguei a esse ponto.

Componentes personalizados: O projeto do componente

Outra observação rápida sobre a criação de um componente personalizado. Se você possui um component.xml, adicione-o à sua lista de fontes tcl:

  "[file normalize "$origin_dir/component.xml"]"\

E adicione também a seguinte seção:

set file "$origin_dir/component.xml"
set file [file normalize $file]
set file_obj [get_files -of_objects [get_filesets sources_1] [list "*$file"]]
set_property "file_type" "IP-XACT" $file_obj

Isso inclui o design do componente no projeto para facilitar a personalização.

Componentes personalizados: referenciando seu componente

Você pode espaçar seu caminho de repo de componente personalizado assim:

# Set IP repository paths
set obj [get_filesets sources_1]
set_property "ip_repo_paths" "[file normalize "$origin_dir/path/to/repository"]" $obj

Na minha pasta de repositório, há pastas individuais contendo arquivos .xml. Portanto, você não está referenciando a pasta que contém o arquivo .xml, mas o pai dela. Por exemplo:

repository/
 component1/component1.xml
 component2/component2.xml

Como executamos esses scripts tcl?

Abra o Vivado e, sem abrir nenhum projeto, selecione Ferramentas -> Executar script TCL e navegue até seu script.

Notas extras sobre TCL

Todo comando que você executa no Vivado é mostrado no console tcl como um comando tcl. Por exemplo, quando eu gerei um novo IP Xilinx usando a GUI, isso surgiu no console tcl:

create_ip -name floating_point -vendor xilinx.com -library ip -module_name floating_point_0
set_property -dict [list CONFIG.Operation_Type {Fixed_to_float} CONFIG.A_Precision_Type {Custom} CONFIG.C_A_Exponent_Width {38} CONFIG.C_A_Fraction_Width {0} CONFIG.Result_Precision_Type {Custom} CONFIG.C_Result_Exponent_Width {8} CONFIG.C_Result_Fraction_Width {16} CONFIG.Flow_Control {NonBlocking} CONFIG.Has_ARESETn {true}] [get_ips floating_point_0]

Isso significa algumas coisas:

  • Você nem precisa salvar os núcleos ip do xilinx - assim que quiser, copie os comandos para o script tcl e não precisará mais confirmar o ip /.

  • especifique o diretório IP com o argumento -dir após -module_name para colocá-lo onde quiser (no padrão, é em project.srcs).

  • Principalmente tudo o que você faz na GUI pode ser feito no tcl, a maneira mais fácil de ver como o xilinx faz as coisas é fazê-lo na GUI e depois ver o que está no console do TCL posteriormente.

  • Este pdf imenso detalha todos os comandos do vivado tcl.


2

Há um vídeo de treinamento do Xilinx que explica como usar os sistemas de controle de versão com o Vivado. Basicamente, a lista de arquivos depende dos recursos que você está usando.

Se você usar uma abordagem com script (como o vermaete faz), poderá fazer com que o Vivado grave todos os arquivos intermediários / temporários em um diretório separado ( veja aqui ), para poder separá-los facilmente.

Caso contrário, você pode limpar a pasta de compilação do Vivado, e tudo o que resta pode ser colocado sob controle de versão.


1
Obrigado, vou dar uma olhada, é simplesmente surpreendente que o Xilinx possa apresentar uma ferramenta tão cara, mas nem se dê ao trabalho de dar suporte adequado ao controle de revisão.
precisa saber é o seguinte

1
Houve um comentário interessante nos fóruns do Xilinx (de 2009 IIRC): as ferramentas foram projetadas para engenheiros de hardware. E os engenheiros de hardware não conhecem e não se importam com o controle de revisões. Mas suponho que essa atitude tenha mudado, e há cada vez mais engenheiros de software usando essas ferramentas. Portanto, agora o controle de revisão é mais importante do que no passado.
Hl 06/04

2
Bem, isso é um insulto puro que já disse essas palavras. Os engenheiros da HW usam vários tipos de controle de revisão, muitas ferramentas suportam isso, muitos engenheiros fazem isso usando o RC padrão e outros usam ferramentas como o Mentor HDL designer com o RC incorporado. Infelizmente, fornecedores de FPGA como Xilinx e Altera parecem não se importar com esses problemas, e é aí que está o principal problema.
precisa saber é o seguinte

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.