cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
nunu
Contributor
Contributor
2,198 Views
Registered: ‎06-08-2017

Vivado 2020.2 Source Control

Hello and Happy new year,

I want set up a new Zynq 7000 Project and going to use GIT with Team Foundation Server (TFS) for source control. 

There is an approach with the write_project_tcl command, but it seems to me not really handy. Maybe someone can share his experience from everyday work.

My approach is to use an external source control tool (e.g. sourcetree or visualstudio) and control the changes on this way. 

Is there anything to watch out for? Or are there disadvantages with this approach?

Thanks in advance

 

 

 

 

 

 
14 Replies
drjohnsmith
Teacher
Teacher
2,154 Views
Registered: ‎07-09-2009

Historicaly

Xilinx has been terrible at embracing source control tools.

   At one point, the best they could offer was to zip up the project and archive that !

The normal I see, 

   if you want to have a version controlled design flow, Xilinx assume you are totally TCL / batch file based,

        and never use the GUI.

Sorry,

https://www.xilinx.com/support/documentation/application_notes/xapp1165.pdf

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_4/ug1198-vivado-revision-control-tutorial.pdf

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
nunu
Contributor
Contributor
2,101 Views
Registered: ‎06-08-2017

Hi drjohnsmith, 

Thx for reply. 

 

The links to which you reference are from August 5, 2013 / November 18, 2015.

Since this time there were no improvements to the topic of source control?

 

My question was: What were the disadvantages to control the project from outside Vivado 2020.2?

One drawback, could be to manage the gitignore file by hand, if Git is used.

 

Thx 

 

 

 

 

0 Kudos
drjohnsmith
Teacher
Teacher
2,089 Views
Registered: ‎07-09-2009

IMHO. No change to source control in Vivado that I know of.

may be some new versions of the documents referred to , 

    

Search the web for Xilinx and source control,  

    you will get lots of hits, all saying abut the same as far as I know.

 

Bottom line, you either do the project entirely from the GUI, or entirely form the TCL / batch file.

    The GUI is a ** to source control,

         The TCL / batch file method is totally under your control, if you can work out what needs to be saved for your project . You will find out when you can not re make a project.

 

  

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
nunu
Contributor
Contributor
2,034 Views
Registered: ‎06-08-2017

You describe the "Project Mode" and "Non-Project Mode"

For my requirements the "Project Mode" is sufficient  ( for the moment  

 

In the following document on site 90: 

Section: Recreating Projects with only the .xpr file

The xpr-file is enough to rebuild the Vivado project. 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/ug892-vivado-design-flows-overview.pdf

 

The further question that comes up, which files of the Vitis Projects (Platform and Application) are necessary for source control?

 

Thx

0 Kudos
maxdz8
Adventurer
Adventurer
2,016 Views
Registered: ‎01-08-2018

Hello,

I have no words to describe the situation of source control and those tools. I have given up on fully understanding the thing but every once in a while I try a full recover and... it almost never worked. Last time I tried it complained about some missing TCL file... I would expect those to be fully auto-generated.

Interesting idea about 'external files'. Last time I tried I ended up with the IP packager producing invalid paths... lovely!

What I am trying to figure out is a .gitignore from which I can maybe derive a template.

Vitis is a completely different and woefully new story. I am almost tempted to play dirty with hardlinks and everything. I will try the TCL approach.

Considering this issue comes up periodically, I post mostly to bump!

 

drjohnsmith
Teacher
Teacher
2,014 Views
Registered: ‎07-09-2009

Re the files to store,

   be careful, 

     over the years xilinx constantly improve the software, and change file extensions,

         qed. 

    You need to constantly make from the checked in files, to prove that you have all the files you need.

        I see at places that use source control, they have a constant process running that makes "top of tree" or what ever its called.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
markramona
Explorer
Explorer
1,774 Views
Registered: ‎12-12-2018

Visual Programming (i.e. block designs) isn't stable enough to enable you to version the files.

The command write_bd_tcl is a good start. That is how we started.

Learning TCL goes a LONG way. It is really simple, and for this high level stuff, where you are putting together blocks, it is rather straightforward.

The way I would recommend moving is (which is what we did over the course of 2 years):

  1. Keep an eye on the tcl console
  2. Start a new project.
  3. Copy all commands to a new tlc file
  4. Build up your project.
  5. Update that TCL in an organized fashion that makes sense to you.

You can checkin that TCL file to the source control system you use.

Before you merge into the main branch, rerun the TCL file to ensure there aren't typos.

drjohnsmith
Teacher
Teacher
1,767 Views
Registered: ‎07-09-2009

I think what your suggesting is move to a TCL based design flow from the GUI based design flow.

 

If using, TCL, it implies you know the file folder directory structure and what you need,

    which is then able to be source controled.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
markramona
Explorer
Explorer
1,759 Views
Registered: ‎12-12-2018

I guess I'm suggesting a hybrid design process.

Many of the important aspects of the GUI, making connections, instantiating IP, and starting the compilation process, can be scripted in the TLC command line.

What we had a hard time doing was "organizing" visually the block diagram. Creating hierarchical blocks and "auto-organizing" did help.

We used the TCL script as "written documentation of how to attain the best working block diagram".

We had TCL scripts creating basic projects with block diagrams for us to elaborate on for a year before we fully dove into the "non-project" mode.

https://www.guru99.com/tcl-tutorial.html seems like a good place to start. I forget where I learned tcl.

 

We did continue to "zip the whole project" (could be a few GBs), and upload it as a snapshot.

 

Eventually, we took the IP instantiation parts of the block diagram TCL generation script and made them into our IP instantiation scripts.

Even now that we have automated builds, they still upload GBs of artifacts as snapshots, so I don't think the idea of "zipping up results" has gone away.

Zipping the results of a multi hour procedure is a good idea when you want to look back at checkpoints to see what went wrong.

 

richardhead
Scholar
Scholar
1,702 Views
Registered: ‎08-01-2012

@nunu 

I just wanted to clear something up. Both "Project" mode and "Non-project mode" are independent of the GUI. You can run a "project mode" design entirly from tcl, and in batch mode if you want. You can also open checkpoints from non-project mode in the GUI for inspection. (project mode also generates the same checkpoints)

We run our designs as "project mode" but have a fully automated build process. I think this has become a bit of a comform blanket now, the design used to be built entirely from the GUI but we're at the point where it is no longer needed.

Project mode actually behaves far better when you have a lot of IPs to build. Using the "launch_runs" command, you can simply launch the synthesis and it will automatically rebuild any IPs that need it, and queue and thread them nicely. In non-project mode you will need to handle this manually, which is quite annoying when you're running the build on different machines that can handle building a different number of IPs in parrallel.

If you ever actually look at how Vivado is running, Project mode is nothing more than wrappers around non-project mode.

drjohnsmith
Teacher
Teacher
1,694 Views
Registered: ‎07-09-2009

Good point @richardhead

Project and none project mode , script and GUI all very "confusing" to users i think , who either use GUI or TCL, 

     Esoterica question, but I wonder why Xilinx made project and non project mode, when one is a sub set of the other ?

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
richardhead
Scholar
Scholar
1,679 Views
Registered: ‎08-01-2012

@drjohnsmith 

It is a good question. if you let Vivado manage any of your scipts you'll quickly move away from allowing vivado to touch your files as it tends to really mess them up. Quartus always ran very efficiently with a "project" simply being a tcl file you can just edit, and any GUI additions just get added to the end of the project files, rather than garble them like vivado.

Once you've moved away from the Vivado GUI, and you have a project rebuild script, if things get messed up its just far easier to rebuild the project than try and fix it in the GUI.

jdabbs003
Observer
Observer
1,089 Views
Registered: ‎10-05-2016

At 2:20, this video says Vivado 2020.2 only requires the {project}.srcs directory sructure to be placed into revision control. However, in my experience, this seems to not actually be true. At the least, RTL modules have their ports renamed and the address map disappears.

https://youtu.be/zjBnMMKtygg

This video highlights the new enhancements in the Vivado Design Suite 2020.2 release including OS and device support, high-level enhancements, and various im...
0 Kudos
avrumw
Expert
Expert
1,069 Views
Registered: ‎01-23-2009

So I want to clarify a couple of things..

If using, TCL, it implies you know the file folder directory structure and what you need,

Almost everything in Vivado is actually done via Tcl. When you do things in the GUI, the GUI is just generating the correct Tcl command to actually do what you wanted. Whether you do an operation through the GUI or using the resulting Tcl command results in exactly the same thing.

Just like you don't need to know the underlying directory structure for using the GUI in project mode, you don't need to know it for the Tcl commands. In fact, that's one of the main features of the project mode - to hide the complexity of the directory structure and the build management stuff from the user.

So what @markramona is suggesting is a good way of doing scripted project mode. Do your first pass using the GUI and capture all the resulting commands. This can be done a number of ways:

  • Manually, as @markramona suggested
  • By extracting the commands from the vivado.jou file (which is a journal of all Tcl commands executed during the session)
  • By extracting the commands from the vivado.log file (which is a bit more cumbersome)
  • By executing the write_project_tcl command (for the non IPI stuff) and write_bd_tcl (for the IPI stuff)

These Tcl scripts (generally separate ones for the project and the bd) should be able to completely recreate a project from scratch in a new directory. If you get this right then revision control becomes relatively easy - you just need to revision control all your source (your RTL, your constraints, and your simulation files if there are any), and the Tcl scripts. We have successfully used this methodology.

The disadvantage of this is that it results in a slower build. Every time you rebuild a project from the Tcl scripts, it needs to run everything; the generation of the IPs and BDs, the synthesis of the IPs and BDs, the synthesis of your main design, and the implementation. This is slower than a "normal" project, where only things that have changed need to be rebuilt. But, on the flip side it has the advantages of controllability, repeatability and compatibility with source control.

I just wanted to clear something up. Both "Project" mode and "Non-project mode" are independent of the GUI. You can run a "project mode" design entirly from tcl, and in batch mode if you want. You can also open checkpoints from non-project mode in the GUI for inspection. (project mode also generates the same checkpoints)

This is a VERY important (and correct) point. The choice of "Project" vs. "Non-Project" and "GUI" vs. "Scripted" are orthogonal - all 4 combinations work and are useful. Fully scripted project mode (which is being described in most of this thread) is a valid and powerful mechanism. The best thing about it is that after your script is finished running you have a fully compliant project on disk - this can be opened with the GUI for analysis (and other things). This makes it a great choice for a team that has users with different levels of expertise - the main flow can be built by the more experienced engineers using the scripted project mode flow, but the less experienced engineer simply needs to write the RTL and run the scripts. When stuck, one can just open the project in the GUI to figure out what went wrong, and you can always open the GUI to take advantage of all the visualization tools (the reports, the different view, ...)

Esoterica question, but I wonder why Xilinx made project and non project mode, when one is a sub set of the other ?

The native mode of Vivado is really the non-project mode. It is a pure in-memory flow where the design is created at synthesis and stays in memory throughout the flow. This flow is based heavily on the ASIC style synthesis flow, and has the potential to be faster than project mode (when built from scratch) due to less reading/writing to disk. There were also some flows (like full out-of-context flow, the PR flow, the reentrant router, and the ECO operations) that, at least originally, could only be used in non-project mode. Oh, and non-project mode is fundamentally compatible with source control!

The project flow was originally built to allow for easier adoption of Vivado. The non-project mode can be very powerful, but quite hard to learn. With the project mode a user can open the GUI, not worry about a good deal of the complexity of the underlying processes, add sources, set some properties through the menus and then push some buttons to get a bitfile out the other end. It also was built to bridge the gap between the ISE "Project Navigator" which was also built for the same purpose. Now to return to what was said before, project mode is not the same as the GUI, but much of the GUI automation (the simple menus to do things, the helper wizards like the constraint wizard, the buttons for controlling the flow), are enabled by project mode.

But, as new features were added to Vivado - particularly the use if IP and IPI - these fit into project mode "better". They can be used in non-project mode, but it is somewhat cumbersome. So, while at the beginning, there was some intent for "power users" to use non-project mode, that has faded somewhat with time. 

So there are needs for both modes; clearly there are a lot of users for project mode, but there are also users of non-project mode. And since non-project mode is the native mode (project mode is a "wrapper" around non-project mode), both will continue to coexist.

Avrum