¿Usar SVN con Xilinx Vivado?

12

Acabo de indicar el uso de Vivado en un nuevo proyecto y me gustaría colocar los archivos del proyecto en SVN.

Parece que Vivado crea 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 colocar bajo SVN que no sean el XDC y el archivo XPR?

    
pregunta FarhadA

4 respuestas

6

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

enlace

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

Antes de empezar

Si realmente te gusta el control total, Xilinx sugiere que renuncies por completo a la GUI y hagas todo lo posible en la línea de comandos, 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 CHEQUE EL PROYECTO COMPLETO. Pero sigue leyendo para obtener sugerencias ...

Línea de base

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

Comprueba 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 verifique todo.

Puntos de control

Si desea poder ejecutar partes del flujo sin ejecutar todo, verifique los archivos del punto 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 al costo de una versión fea. sistema de control.

El video no dice nada 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 adecuada para el control de versiones) es ejecutar el comando File -> Write Project Tcl cada vez que quiera confirmar, y luego confirmar ese archivo TCL con el control de versiones. Cuando actualice su carpeta local, debe volver a ejecutar ese archivo TCL para crear todos los archivos del proyecto. Puaj.

    
respondido por el Mark Lakata
3

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 básicos

Generalmente guardo 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

Sólo se deben confirmar los archivos .xml y .xci de IP. (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 las rutas 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 los núcleos IP como se ve en esta respuesta .

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

Aquí es donde el procesamiento finaliza 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 a Archivo - > Exportar - > Block Diagram to Tcl, y guárdelo en el mismo directorio que el otro archivo tcl.

Luego hice un script Generate_Wrapper.tcl que crea los archivos de envoltorio del diagrama de bloques para que no tengas que hacerlo manualmente. La carpeta project / project.srcs se utiliza para almacenar los datos de bd, pero aún es completamente desechable, ya que 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.tcl agrego las siguientes líneas para generar el diagrama de bloques y las envolturas:

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 lo 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, aún no he llegado a eso.

Componentes personalizados: el proyecto componente

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

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

Y luego agrega también 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 del componente en el proyecto para una fácil personalización.

Componentes personalizados: referencia a su componente

Puedes espaciar tu ruta de repo de componentes personalizada 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 repositorio, hay carpetas individuales que contienen archivos .xml. Así que no estás haciendo referencia a la carpeta que contiene el archivo .xml, sino al padre de ese. Por ejemplo:

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

¿Cómo ejecutamos estos scripts tcl?

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

Notas TCL adicionales

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

  • En realidad, ni siquiera necesita guardar los núcleos ip de xilinx. Una vez que estén como lo desea, copie los comandos en el script tcl y no necesita cometer ip / more.

  • especifica el directorio IP con el argumento -dir después de -module_name para ponerlo donde quieras (de forma predeterminada, está en project.srcs).

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

  • Este pdf enorme detalla todo el Comandos tc de vivado.

respondido por el stanri
2

Hay un video de capacitación de Xilinx que explica cómo usarlo Sistemas de control de versiones con vivado. Básicamente, la lista de archivos depende de las características que está utilizando.

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

De lo contrario, puedes limpiar la carpeta de compilación de Vivado, y cualquier cosa que quede se puede poner bajo el control de versiones.

    
respondido por el hli
1

Por favor, vea este hilo en los foros de Xilinx:

enlace

    
respondido por el Greg

Lea otras preguntas en las etiquetas