why-i-use-scripts

When I started with FPGA, like probably all of us, the first thing I did when I arrived at my job position was to start Vivado (or ISE), and start coding, and once the code was write, cross my fingers, and Generate Bitsream. If all works fine, after some minutes (or hours), we had my bitstream on vivado_project/vivado_project.runs/impl_1/. One we are in this folder, we notice that bitstream file, share room with other files. Thanksfully, Linux, or Windows have a search box, and searching *.bit, we have our bitstream file ready to anything. If we want to program the FPGA from Vivado, this process is easiest, due to when we open the Hardware Manager, and click into Program Device, Vivado knows where are the bitstream, and the text box is autocompleted. Maybe we want to make a Release, and we need generate the memory file. Then, we have to navigate to the correct option, select the memory we want to use, select some other options and generate it. Probably, our design have any little bug, and we have to repeat the process from the beginning.

If we work with any version control like git, and work with this methods, we need ensure that all necesary files for the designs are in the repository, and the best way to achieve that is upload all the project. This have a big cost of space, and an extra effort for the testers or project managers to find the correct files they have to use, because they don’t have to know the extensions of the files they have to upload, or share with clients.

This way to work, may be valid for students or hobbiest, but when there are some developers working on the same design, or the design has to be shared, and implemented in some different machines, maybe running different operating systems, this way are not valid.

In these cases, we need in first place, a file directory that allow us to know where are every file, with 0 dependencies of the operating system, vivado version, or manners of the developers. In second place, we need to optimize the size of the files, and the best way to do this, is share only text files. Third, we need to avoid the human error avoiding to the user copy and paste files. All files have to be created automatically, with the correct name, and on the right folder, and, of course, be repetitive. The only way that I know to achieve these goals is using scripting, and Vivado allow us to do it.

Vivado are a TCL interpreter, and allow us to write our scripts in this language. Moreover the standard commands of TCL, Vivado has its own command collection, documented on UG835. From this interpreter we can sinthesize, implement, generate memory files, and manage the file directory.

The next code shows how to generate project, add files and open and generate a block design.

## Shared memory between microblaze and hdl for share parameters.
## Digital tav

set projectDir ../project

## Delete log and journal
file delete {*}[glob vivado*.backup.jou]
file delete {*}[glob vivado*.backup.log]
file delete -force .Xil/

## Create project in ../project
create_project -force $projectDir/zynq_shared_memory.xpr

## Set verilog as default language
set_property target_language Verilog [current_project]

## Adding verilog files
add_file ../src/bram_filler.v

## Set current board. Microzed
set_property BOARD_PART em.avnet.com:microzed_7020:part0:1.1 [current_project]

## Create block design
create_bd_design zynq_shared_mem_bd

## Configure block design through external file
source ./zynq_shared_memory_bd_2018.3.tcl

## Regenerate block design layout
regenerate_bd_layout

## Validate block design design
validate_bd_design

## Generate and add wrapper file for synthesis
make_wrapper -files [get_files $projectDir/zynq_shared_memory.srcs/sources_1/bd/zynq_shared_mem_bd/zynq_shared_mem_bd.bd] -top
add_files -norecurse $projectDir/zynq_shared_memory.srcs/sources_1/bd/zynq_shared_mem_bd/hdl/zynq_shared_mem_bd_wrapper.v

## Open vivado for verify
start_gui