Acabo de decir que uso Vivado en un nuevo proyecto y me gustaría poner los archivos del proyecto en SVN.

Vivado parece crear todos los archivos del proyecto bajo el nombre del proyecto (por ejemplo, proj1):

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

Mi pregunta es ¿cuáles son los archivos que necesito poner bajo SVN además del XDC y el archivo XPR?

Xilinx crea un video de YouTube (suspiro) para lidiar con esto. Aquí está el enlace al video.

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

Aquí está mi resumen del video (8 minutos)

Antes de que empieces

Si realmente te gusta el control total, Xilinx sugiere que renuncies a la GUI por completo y hagas todo en la línea de comando, y luego sabes qué es la fuente y qué no.

De lo contrario, Xilinx se da cuenta de que los proyectos de Vivado no están diseñados para el control de versiones. NO CHECK EN TODO EL PROYECTO. Pero sigue leyendo para obtener pistas ...

Base

Por supuesto, cualquier cosa que escriba fuera de la herramienta Vivado debe registrarse.

Consulte los siguientes archivos

*.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

Bloques de IP

Si usa bloques de IP, genere la IP en una carpeta única y registre todo.

Puntos de control

Si desea poder volver a ejecutar partes del flujo sin ejecutar todo, verifique los archivos de puntos de control.

*.dcp - Design Checkpoints

Mi anexo

Si las herramientas de Xilinx fueran eficientes, no recomendaría revisar los archivos dcp, pero tardan tantas horas en ejecutarse, podría valer la pena a costa de un sistema de control de versiones feo.

El video no dice en cuclillas sobre los archivos del proyecto Vivado (* .xpr), así que aquí está mi sugerencia:

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

La alternativa que recomienda Xilinx (que en realidad es un truco, no es adecuado para el control de versiones) es ejecutar el File -> Write Project Tclcomando cada vez que desee confirmar y luego enviar ese archivo TCL al control de versiones. Cuando actualiza su carpeta local, debe volver a ejecutar ese archivo TCL para crear todos los archivos del proyecto. Yuck

Vivado 2014.1 permite el uso de scripts .tcl para regenerar proyectos.

Para hacer esto, con su proyecto abierto, vaya a Archivo -> Escribir proyecto tcl.

Proyectos basicos

Por lo general, almaceno mis fuentes y el script .tcl en una ubicación fuera del directorio del proyecto. Los núcleos IP de xilinx generados dentro del proyecto pueden copiarse en otro lugar haciendo clic derecho en el núcleo y seleccionando "Copiar IP". Y borrando el original. Cuando se genera el script tcl, crea enlaces relativos a estos archivos. Esto suele ser el aspecto de mi estructura de directorios:

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

Solo se deben confirmar los archivos IP .xml y .xci. (E incluso esto no es necesario, técnicamente, vea las notas al final).

Esto es lo que se compromete con git, tenga en cuenta la falta de project.xpr o directorios de proyectos.

Cuando ejecuto genproject.tcl, crea otro directorio para el proyecto.

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

Esta nueva carpeta es completamente desechable. Para crear esta estructura, modifico el script tcl de la siguiente manera.

Cambio las primeras 3 líneas de la siguiente manera:

# 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

Esto crea un nuevo directorio de proyecto y el nuevo proyecto en ese directorio.

Luego modifico los caminos para señalar los lugares correctos. Es posible que deba cambiar estas rutas en otros lugares del 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

También modifico las ejecuciones de diseño para núcleos IP como se ve en esta respuesta .

Los archivos .wcfg se pueden incluir de manera similar a la ip y srcs.

Aquí es donde termina el procesamiento para proyectos más simples (que contienen solo fuentes e IP, sin diagramas de bloques). También se debe hacer lo siguiente para almacenar los datos del diagrama de bloques.

Proyectos de diagrama de bloques

Para guardar el diagrama de bloques, con el diagrama de bloques abierto, vaya Archivo -> Exportar -> Diagrama de bloques a Tcl, y guárdelo en el mismo directorio que el otro archivo tcl.

Luego hice un Generate_Wrapper.tclscript que crea los archivos de envoltura del diagrama de bloques para que no tenga que hacerlo manualmente. La carpeta project / project.srcs se usa para almacenar los datos de bd, pero aún es completamente desechable, ya que el bd se almacena en el script tcl. Guarda esto con los otros dos.

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

Al final de mi genproject.tclagrego las siguientes líneas para generar el diagrama de bloques y los contenedores:

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

Para proyectos sin fuente (solo diagrama de bloques), mi git commit es solo el siguiente:

base_project/
 Generate_Wrapper.tcl
 Create_Bd.tcl
 genproject.tcl

Para generar todo, ejecuta genproject.tcl.

Incluso puedes combinar todo esto en uno si eres particularmente eficiente, todavía no lo he hecho.

Componentes personalizados: el proyecto componente

Otra nota rápida sobre la creación de un componente personalizado. Si tiene un component.xml, agréguelo a su lista de fuentes tcl:

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

Y luego también agregue la siguiente sección:

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

Esto incluye el diseño de componentes en el proyecto para una fácil personalización.

Componentes personalizados: referencia a su componente

Puede espaciar su ruta de repositorio de componentes personalizados de esta manera:

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

En mi carpeta de repos, hay carpetas individuales que contienen archivos .xml. Entonces, no está haciendo referencia a la carpeta que contiene el .xml, sino al padre de esa. P.ej:

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

¿Cómo ejecutamos estos scripts tcl?

Abra Vivado y, sin abrir ningún proyecto, seleccione Herramientas -> Ejecutar script TCL y navegue hasta su script.

Notas TCL adicionales

Cada comando que ejecuta en Vivado se muestra en la consola tcl como un comando tcl. Por ejemplo, cuando generé una nueva IP de Xilinx usando la GUI, esto apareció en la consola 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]

Esto significa un par de cosas:

• Realmente ni siquiera necesita guardar los núcleos ip de xilinx: una vez que estén como los desea, copie los comandos en el script tcl y ya no necesita confirmar ip /.

• especifique el directorio IP con el argumento -dir después de -module_name para colocarlo donde desee (por defecto está en project.srcs).

• Casi todo lo que haces en la GUI se puede hacer en tcl, la forma más fácil de ver cómo xilinx hace las cosas es hacerlo en la GUI y luego ver qué hay en la consola TCL después.

• Este enorme pdf detalla todos los comandos de vivado tcl.

Hay un video de entrenamiento de Xilinx que explica cómo usar los sistemas de control de versiones con Vivado. Básicamente, la lista de archivos depende de las características que esté utilizando.

Si utiliza un enfoque con secuencia de comandos (como lo hace vermaete), puede hacer que Vivado escriba todos los archivos intermedios / temporales en un directorio separado ( consulte aquí ), para que pueda separarlos fácilmente.

De lo contrario, puede limpiar la carpeta de compilación por Vivado, y todo lo que quede podría ponerse bajo control de versión.

Eche un vistazo a este hilo en los foros de Xilinx:

http://forums.xilinx.com/t5/Implementation/What-files-to-put-under-revision-control-for-consistent-build/td-p/174232